Split the handbook into individual files. Each chapter is in a file called
chapter.sgml in a directory named according to the value the id attribute on that chapter. Added chapters.ent, which lists the entities for each chapter. Updated handbook.sgml to use these entities.
This commit is contained in:
Nik Clayton
parent
05dc329be3
commit
2207769022
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=3728
86 changed files with 118421 additions and 117435 deletions
en/handbook
README
advanced-networking
basics
bibliography
chapters.entcontrib
cutting-edge
eresources
handbook.sgmlhw
install
internals
introduction
kernelconfig
kerneldebug
kernelopts
l10n
linuxemu
mail
mirrors
pgpkeys
policies
ppp-and-slip
printing
quotas
security
serialcomms
staff
x11
en_US.ISO8859-1
articles/contributing
books
developers-handbook
handbook
advanced-networking
basics
bibliography
book.sgmlchapters.entcontrib
cutting-edge
eresources
hw
install
introduction
kernelconfig
kerneldebug
kernelopts
l10n
linuxemu
mail
mirrors
pgpkeys
policies
ppp-and-slip
printing
security
serialcomms
staff
x11
en_US.ISO_8859-1/books/handbook
advanced-networking
basics
bibliography
book.sgmlchapters.entcontrib
cutting-edge
eresources
hw
install
internals
introduction
kernelconfig
kerneldebug
kernelopts
l10n
linuxemu
mail
mirrors
pgpkeys
policies
ppp-and-slip
printing
quotas
security
serialcomms
staff
x11
|
|
@ -585,3 +585,12 @@ for example,
|
|||
|
||||
56. Add values for the 'id' attribute for those <chapters> that don't
|
||||
have them.
|
||||
|
||||
57. Split the Handbook into individual files, called chapter.sgml, stored
|
||||
in directories named after the value of the id attribute on the
|
||||
chapter.
|
||||
|
||||
Added chapters.ent, which lists the entities used to refer to the
|
||||
chapters. Update handbook.sgml to refer to this file and use entity
|
||||
references to pull everything in.
|
||||
|
||||
|
|
|
|||
1008
en/handbook/advanced-networking/chapter.sgml
Normal file
1008
en/handbook/advanced-networking/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
136
en/handbook/basics/chapter.sgml
Normal file
136
en/handbook/basics/chapter.sgml
Normal file
|
|
@ -0,0 +1,136 @@
|
|||
<chapter id="basics">
|
||||
<title>Unix Basics</title>
|
||||
|
||||
|
||||
<sect1 id="basics-man">
|
||||
<title>The Online Manual</title>
|
||||
|
||||
<para>The most comprehensive documentation on FreeBSD is in the form
|
||||
of <emphasis>man pages</emphasis>. 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
|
||||
<command>man</command>
|
||||
command. Use of the <command>man</command> command is simple:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man <replaceable>command</replaceable></userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><replaceable>command</replaceable> is
|
||||
the name of the command you wish to learn about. For example, to
|
||||
learn more about <command>ls</command> command type:</para>
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man ls</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The online manual is divided up into numbered sections:</para>
|
||||
|
||||
<orderedlist>
|
||||
|
||||
<listitem>
|
||||
<para>User commands</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>System calls and error numbers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Functions in the C libraries</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Device drivers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>File formats</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Games and other diversions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Miscellaneous information</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>System maintenance and operation commands</para>
|
||||
</listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
<para>In some cases, the same topic may appear in more than
|
||||
one section of the on-line manual. For example, there is a
|
||||
<command>chmod</command>
|
||||
user command and a <function>chmod()</function> system call. In
|
||||
this case, you can tell the <command>man</command> command which one you want by
|
||||
specifying the section:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man 1 chmod</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will display the manual page for the user
|
||||
command <command>chmod</command>. References to a
|
||||
particular section of the on-line manual are traditionally placed in
|
||||
parenthesis in written documentation, so <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry> refers to the
|
||||
<command>chmod</command>
|
||||
user command and <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>2</manvolnum></citerefentry> refers to the
|
||||
system call.</para>
|
||||
|
||||
<para>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 <command>man</command> to search for keywords in the
|
||||
command <emphasis>descriptions</emphasis> by using the
|
||||
<option>-k</option> switch:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man -k mail</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>With this command you will be presented with a
|
||||
list of commands that have the keyword “mail” in their descriptions.
|
||||
This is actually functionally equivalent to using the <command>apropos</command>
|
||||
command.</para>
|
||||
|
||||
<para>So, you are looking at all those fancy commands in
|
||||
<filename>/usr/bin</filename> but do not even have the faintest idea
|
||||
what most of them actually do? Simply do a
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>cd /usr/bin; man -f *</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
or
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>cd /usr/bin; whatis *</userinput></screen>
|
||||
</informalexample> which does the same thing.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="basics-info">
|
||||
<title>GNU Info Files</title>
|
||||
|
||||
<para>FreeBSD includes many applications and utilities produced by the
|
||||
Free Software Foundation (FSF). In addition to man pages, these
|
||||
programs come with more extensive hypertext documents called
|
||||
“info” files which can be viewed with the
|
||||
<command>info</command> command or, if you installed
|
||||
<command>emacs</command>, the info mode of <command>emacs</command>.</para>
|
||||
|
||||
<para>To use the <citerefentry><refentrytitle>info</refentrytitle><manvolnum>1</manvolnum></citerefentry> command, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>info</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>For a brief introduction, type <userinput>h</userinput>. For a quick
|
||||
command reference, type <userinput>?</userinput>.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
478
en/handbook/bibliography/chapter.sgml
Normal file
478
en/handbook/bibliography/chapter.sgml
Normal file
|
|
@ -0,0 +1,478 @@
|
|||
<chapter id="bibliography">
|
||||
<title>Bibliography</title>
|
||||
|
||||
<para>While 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.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Books & Magazines Specific to FreeBSD</title>
|
||||
|
||||
<para><emphasis>International books &
|
||||
Magazines:</emphasis></para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://freebsd.csie.nctu.edu.tw/~jdli/book.html">Using
|
||||
FreeBSD</ulink> (in Chinese).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD for PC 98'ers (in Japanese), published by SHUWA
|
||||
System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD (in Japanese), published by CUTT. ISBN
|
||||
4-906391-22-2 C3055 P2400E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.shoeisha.co.jp/pc/index/shinkan/97_05_06.htm">Complete Introduction to FreeBSD</ulink> (in Japanese), published by <ulink URL="http://www.shoeisha.co.jp/">Shoeisha Co., Ltd</ulink>. ISBN 4-88135-473-6 P3600E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.ascii.co.jp/pb/book1/shinkan/detail/1322785.html">Personal UNIX Starter Kit FreeBSD</ulink> (in Japanese), published by <ulink URL="http://www.ascii.co.jp/">ASCII</ulink>. ISBN 4-7561-1733-3 P3000E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD Handbook (Japanese translation), published by
|
||||
<ulink URL="http://www.ascii.co.jp/">ASCII</ulink>. ISBN
|
||||
4-7561-1580-2 P3800E.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para><emphasis>English language books &
|
||||
Magazines:</emphasis></para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.cdrom.com/titles/os/bsdbook2.htm">The
|
||||
Complete FreeBSD</ulink>, published by <ulink
|
||||
URL="http://www.cdrom.com">Walnut Creek
|
||||
CDROM</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Users' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD User's Reference Manual</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1994.<!-- <br> --> ISBN
|
||||
1-56592-075-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD User's Supplementary Documents</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1994.<!-- <br> --> ISBN
|
||||
1-56592-076-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>UNIX in a Nutshell</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1990.<!-- <br> --> ISBN
|
||||
093717520X</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Mui, Linda. <emphasis>What You Need To Know When You Can't
|
||||
Find Your UNIX System Administrator</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1995. <!-- <br> --> ISBN 1-56592-104-6</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink URL="http://www-wks.acs.ohio-state.edu/">Ohio State
|
||||
University</ulink> has written a <ulink
|
||||
URL="http://www-wks.acs.ohio-state.edu/unix_course/unix.html">UNIX Introductory Course</ulink> which is available online in HTML and postscript format.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Administrators' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Albitz, Paul and Liu, Cricket. <emphasis>DNS and
|
||||
BIND</emphasis>, 2nd Ed. O'Reilly & Associates, Inc.,
|
||||
1997. <!-- <br> --> ISBN 1-56592-236-0</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD System Manager's Manual</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1994. <!-- <br> --> ISBN
|
||||
1-56592-080-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Costales, Brian, et al. <emphasis>Sendmail</emphasis>, 2nd
|
||||
Ed. O'Reilly & Associates, Inc., 1997.<!-- <br> --> ISBN
|
||||
1-56592-222-0</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Frisch, Æleen. <emphasis>Essential System
|
||||
Administration</emphasis>, 2nd Ed. O'Reilly &
|
||||
Associates, Inc., 1995. <!-- <br> -->ISBN 1-56592-127-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hunt, Craig. <emphasis>TCP/IP Network
|
||||
Administration</emphasis>. O'Reilly & Associates, Inc.,
|
||||
1992. <!-- <br> --> ISBN 0-937175-82-X</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Nemeth, Evi. <emphasis>UNIX System Administration
|
||||
Handbook</emphasis>. 2nd ed. Prentice Hall, 1995. <!-- <br>
|
||||
--> ISBN 0131510517</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stern, Hal <emphasis>Managing NFS and NIS</emphasis>
|
||||
O'Reilly & Associates, Inc., 1991. <!-- <br> --> ISBN
|
||||
0-937175-75-7</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Programmers' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Asente, Paul. <emphasis>X Window System
|
||||
Toolkit</emphasis>. Digital Press. <!-- <br> --> ISBN
|
||||
1-55558-051-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD Programmer's Reference Manual</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1994. <!-- <br> --> ISBN
|
||||
1-56592-078-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD Programmer's Supplementary
|
||||
Documents</emphasis>. O'Reilly & Associates, Inc., 1994.
|
||||
<!-- <br> --> ISBN 1-56592-079-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ellis, Margaret A. and Stroustrup, Bjarne. <emphasis>The
|
||||
Annotated C++ Reference Manual</emphasis>. Addison-Wesley,
|
||||
1990. <!-- <br> --> ISBN 0-201-51459-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Harbison, Samuel P. and Steele, Guy L. Jr. <emphasis>C: A
|
||||
Reference Manual</emphasis>. 4rd ed. Prentice Hall, 1995.
|
||||
<!-- <br> -->ISBN 0-13-326224-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Kernighan, Brian and Dennis M. Ritchie. <emphasis>The C
|
||||
Programming Language.</emphasis>. PTR Prentice Hall, 1988.
|
||||
<!-- <br> --> ISBN 0-13-110362-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Lehey, Greg. <emphasis>Port UNIX Software</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1995.<!-- <br> --> ISBN
|
||||
1-56592-126-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Plauger, P. J. <emphasis>The Standard C
|
||||
Library</emphasis>. Prentice Hall, 1992. <!-- <br> --> ISBN
|
||||
0-13-131509-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>Advanced Programming in the
|
||||
UNIX Environment</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1992<!-- <br> --> ISBN 0-201-56317-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>UNIX Network
|
||||
Programming</emphasis>. PTR Prentice Hall, 1990. <!-- <br>
|
||||
--> ISBN 0-13-949876-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wells, Bill. “Writing Serial Drivers for UNIX”.
|
||||
<emphasis>Dr. Dobb's Journal</emphasis>. 19(15), December
|
||||
1994. pp68-71, 97-99.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Operating System Internals</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Andleigh, Prabhat K. <emphasis>UNIX System
|
||||
Architecture</emphasis>. Prentice-Hall, Inc., 1990.<!-- <br>
|
||||
--> ISBN 0-13-949843-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Jolitz, William. “Porting UNIX to the
|
||||
386”. <emphasis>Dr.
|
||||
Dobb's Journal</emphasis>. January 1991-July 1992.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Leffler, Samuel J., Marshall Kirk McKusick, Michael J
|
||||
Karels and John Quarterman <emphasis>The Design and
|
||||
Implementation of the 4.3BSD UNIX Operating
|
||||
System</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1989.<!-- <br> --> ISBN 0-201-06196-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Leffler, Samuel J., Marshall Kirk McKusick, <emphasis>The
|
||||
Design and Implementation of the 4.3BSD UNIX Operating
|
||||
System: Answer Book</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1991.<!-- <br> --> ISBN 0-201-54629-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
|
||||
and John Quarterman. <emphasis>The Design and Implementation
|
||||
of the 4.4BSD Operating System</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1996.<!-- <br> --> ISBN 0-201-54979-4</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume
|
||||
1: The Protocols</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1996.<!-- <br> --> ISBN 0-201-63346-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume
|
||||
3: TCP for Transactions, HTTP, NNTP and the UNIX Domain
|
||||
Protocols</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1996.<!-- <br> --> ISBN 0-201-63495-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Vahalia, Uresh. <emphasis>UNIX Internals -- The New
|
||||
Frontiers</emphasis>. Prentice Hall, 1996.<!-- <br> --> ISBN
|
||||
0-13-101908-2</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wright, Gary R. and W. Richard Stevens. <emphasis>TCP/IP
|
||||
Illustrated, Volume 2: The Implementation</emphasis>.
|
||||
Reading, Mass. : Addison-Wesley, 1995.<!-- <br> --> ISBN
|
||||
0-201-63354-X</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Security Reference</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Cheswick, William R. and Steven M. Bellovin.
|
||||
<emphasis>Firewalls and Internal Security: Repelling the Wily
|
||||
Hacker</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1995.<!-- <br> --> ISBN 0-201-63357-4</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Garfinkel, Simson and Gene Spafford. <emphasis>Practical
|
||||
UNIX Security</emphasis>. 2nd Ed. O'Reilly & Associates,
|
||||
Inc., 1996. <!-- <br> --> ISBN 1-56592-148-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Garfinkel, Simson. <emphasis>PGP Pretty Good
|
||||
Privacy</emphasis> O'Reilly & Associates, Inc., 1995.
|
||||
<!-- <br> --> ISBN 1-56592-098-8</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Hardware Reference</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Anderson, Don and Tom Shanley. <emphasis>Pentium Processor
|
||||
System Architecture</emphasis>. 2nd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995.<!-- <br> --> ISBN 0-201-40992-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ferraro, Richard F. <emphasis>Programmer's Guide to the
|
||||
EGA, VGA, and Super VGA Cards</emphasis>. 3rd ed. Reading,
|
||||
Mass. : Addison-Wesley, 1995.<!-- <br> --> ISBN
|
||||
0-201-62490-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>80486 System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <!-- <br> -->ISBN 0-201-40994-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>ISA System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995.<!-- <br> --> ISBN 0-201-40996-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>PCI System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <!-- <br> -->ISBN 0-201-40993-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Van Gilluwe, Frank. <emphasis>The Undocumented
|
||||
PC</emphasis>. Reading, Mass: Addison-Wesley Pub. Co.,
|
||||
1994.<!-- <br> --> ISBN 0-201-62277-7</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>UNIX History</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Lion, John <emphasis>Lion's Commentary on UNIX, 6th Ed.
|
||||
With Source Code</emphasis>. ITP Media Group, 1996.<!-- <br>
|
||||
--> ISBN 1573980137</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Raymond, Eric s. <emphasis>The New Hacker's Dictonary, 3rd
|
||||
edition</emphasis>. MIT Press, 1996.<!-- <br> --> ISBN
|
||||
0-262-68092-0<!-- <br> --> Also known as the <ulink
|
||||
URL="http://www.ccil.org/jargon/jargon.html">Jargon
|
||||
File</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Salus, Peter H. <emphasis>A quarter century of
|
||||
UNIX</emphasis>. Addison-Wesley Publishing Company, Inc.,
|
||||
1994.<!-- <br> --> ISBN 0-201-54777-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Simon Garfinkel, Daniel Weise, Steven Strassmann.
|
||||
<emphasis>The UNIX-HATERS Handbook</emphasis>. IDG Books
|
||||
Worldwide, Inc., 1994.<!-- <br> --> ISBN 1-56884-203-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don Libes, Sandy Ressler <emphasis>Life with
|
||||
UNIX</emphasis> — special edition. Prentice-Hall, Inc.,
|
||||
1989.<!-- <br> --> ISBN 0-13-536657-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The BSD family tree</emphasis>. 1997.<!-- <br>
|
||||
--> <ulink
|
||||
URL="http://www.de.freebsd.org/de/ftp/unix-stammbaum">http://www.de.freebsd.org/de/ftp/unix-stammbaum</ulink> or <ulink URL="file:/usr/share/misc/bsd-family-tree">local</ulink> on a FreeBSD-current machine.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The BSD Release Announcements
|
||||
collection</emphasis>. 1997.<!-- <br> --> <ulink
|
||||
URL="http://www.de.FreeBSD.ORG/de/ftp/releases/">http://www.de.FreeBSD.ORG/de/ftp/releases/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Networked Computer Science Technical Reports
|
||||
Library</emphasis>.<!-- <br> --> <ulink
|
||||
URL="http://www.ncstrl.org/">http://www.ncstrl.org/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Magazines and Journals</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The C/C++ Users Journal</emphasis>. R&D
|
||||
Publications Inc. ISSN 1075-2838</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Sys Admin — The Journal for UNIX System
|
||||
Administrators</emphasis> Miller Freeman, Inc., ISSN
|
||||
1061-2688</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
47
en/handbook/chapters.ent
Normal file
47
en/handbook/chapters.ent
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
<!--
|
||||
Creates entities for each chapter in the FreeBSD Handbook. Each entity
|
||||
is named chap.foo, where foo is the value of the id attribute on that
|
||||
chapter, and corresponds to the name of the directory in which that
|
||||
chapter's .sgml file is stored.
|
||||
|
||||
Chapters should be listed in the order in which they are referenced.
|
||||
|
||||
$Id: chapters.ent,v 1.1 1998-11-03 23:16:38 nik Exp $
|
||||
-->
|
||||
|
||||
<!-- Part one -->
|
||||
<!ENTITY chap.introduction SYSTEM "introduction/chapter.sgml">
|
||||
<!ENTITY chap.install SYSTEM "install/chapter.sgml">
|
||||
<!ENTITY chap.basics SYSTEM "basics/chapter.sgml">
|
||||
<!ENTITY chap.ports SYSTEM "ports/chapter.sgml">
|
||||
|
||||
<!-- Part two -->
|
||||
<!ENTITY chap.kernelconfig SYSTEM "kernelconfig/chapter.sgml">
|
||||
<!ENTITY chap.security SYSTEM "security/chapter.sgml">
|
||||
<!ENTITY chap.printing SYSTEM "printing/chapter.sgml">
|
||||
<!ENTITY chap.quotas SYSTEM "quotas/chapter.sgml">
|
||||
<!ENTITY chap.x11 SYSTEM "x11/chapter.sgml">
|
||||
<!ENTITY chap.hw SYSTEM "hw/chapter.sgml">
|
||||
<!ENTITY chap.l10n SYSTEM "l10n/chapter.sgml">
|
||||
|
||||
<!-- Part three -->
|
||||
<!ENTITY chap.serialcomms SYSTEM "serialcomms/chapter.sgml">
|
||||
<!ENTITY chap.ppp-and-slip SYSTEM "ppp-and-slip/chapter.sgml">
|
||||
<!ENTITY chap.advanced-networking SYSTEM "advanced-networking.sgml">
|
||||
<!ENTITY chap.mail SYSTEM "mail/chapter.sgml">
|
||||
|
||||
<!-- Part four -->
|
||||
<!ENTITY chap.cutting-edge SYSTEM "cutting-edge/chapter.sgml">
|
||||
<!ENTITY chap.contrib SYSTEM "contrib/chapter.sgml">
|
||||
<!ENTITY chap.policies SYSTEM "policies/chapter.sgml">
|
||||
<!ENTITY chap.kernelopts SYSTEM "kernelopts/chapter.sgml">
|
||||
<!ENTITY chap.kerneldebug SYSTEM "kerneldebug/chapter.sgml">
|
||||
<!ENTITY chap.linuxemu SYSTEM "linuxemu/chapter.sgml">
|
||||
<!ENTITY chap.internals SYSTEM "internals/chapter.sgml">
|
||||
|
||||
<!-- Part five (appendices) -->
|
||||
<!ENTITY chap.mirrors SYSTEM "mirrors/chapter.sgml">
|
||||
<!ENTITY chap.bibliography SYSTEM "bibliography/chapter.sgml">
|
||||
<!ENTITY chap.eresources SYSTEM "eresources/chapter.sgml">
|
||||
<!ENTITY chap.staff SYSTEM "staff/chapter.sgml">
|
||||
<!ENTITY chap.pgpkeys SYSTEM "pgpkeys/chapter.sgml">
|
||||
4901
en/handbook/contrib/chapter.sgml
Normal file
4901
en/handbook/contrib/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
2088
en/handbook/cutting-edge/chapter.sgml
Normal file
2088
en/handbook/cutting-edge/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1173
en/handbook/eresources/chapter.sgml
Normal file
1173
en/handbook/eresources/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
6323
en/handbook/hw/chapter.sgml
Normal file
6323
en/handbook/hw/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1212
en/handbook/install/chapter.sgml
Normal file
1212
en/handbook/install/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1652
en/handbook/internals/chapter.sgml
Normal file
1652
en/handbook/internals/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
611
en/handbook/introduction/chapter.sgml
Normal file
611
en/handbook/introduction/chapter.sgml
Normal file
|
|
@ -0,0 +1,611 @@
|
|||
<chapter id="introduction">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>FreeBSD is a 4.4BSD-Lite based operating system for Intel
|
||||
architecture (x86) based PCs. For an overview of FreeBSD, see
|
||||
<xref linkend="nutshell" remap="FreeBSD in a nutshell">. For a
|
||||
history of the project, read <xref linkend="history" remap="a brief
|
||||
history of FreeBSD">. To see a description of the latest release,
|
||||
read <xref linkend="relnotes" remap="about the current
|
||||
release">. If you're interested in contributing something to the
|
||||
FreeBSD project (code, equipment, sacks of unmarked bills), please see
|
||||
about <xref linkend="contrib"
|
||||
remap="contributing to FreeBSD">.</para>
|
||||
|
||||
|
||||
<sect1 id="nutshell">
|
||||
<title>FreeBSD in a Nutshell</title>
|
||||
|
||||
<para>FreeBSD is a state of the art operating system for personal
|
||||
computers based on the Intel CPU architecture, which includes the
|
||||
386, 486 and Pentium processors (both SX and DX versions). Intel
|
||||
compatible CPUs from AMD and Cyrix are supported as well. FreeBSD
|
||||
provides you with many advanced features previously available only
|
||||
on much more expensive computers. These features include:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Preemptive multitasking</emphasis> with
|
||||
dynamic priority adjustment to ensure smooth and fair sharing
|
||||
of the computer between applications and users.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Multiuser</emphasis> access means that
|
||||
many people can use a FreeBSD system simultaneously for a
|
||||
variety of things. System peripherals such as printers and
|
||||
tape drives are also properly SHARED BETWEEN ALL users on the
|
||||
system.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Complete <emphasis>TCP/IP networking</emphasis>
|
||||
including SLIP, PPP, NFS and NIS support. This means that
|
||||
your FreeBSD machine can inter-operate easily with other
|
||||
systems as well act as an enterprise server, providing vital
|
||||
functions such as NFS (remote file access) and e-mail services
|
||||
or putting your organization on the Internet with WWW, ftp,
|
||||
routing and firewall (security) services.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Memory protection</emphasis> ensures
|
||||
that applications (or users) cannot interfere with each other.
|
||||
One application crashing will not affect others in any
|
||||
way.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD is a <emphasis>32-bit</emphasis>
|
||||
operating system and was designed as such from the ground
|
||||
up.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The industry standard <emphasis>X Window
|
||||
System</emphasis> (X11R6) provides a graphical user
|
||||
interface (GUI) for the cost of a common VGA card and monitor
|
||||
and comes with full sources.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Binary compatibility</emphasis> with
|
||||
many programs built for SCO, BSDI, NetBSD, Linux and
|
||||
386BSD.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hundreds of <emphasis>ready-to-run</emphasis>
|
||||
applications are available from the FreeBSD <emphasis>ports</emphasis> and <emphasis>packages</emphasis> collection. Why search the net
|
||||
when you can find it all right here?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Thousands of additional and <emphasis>easy-to-port</emphasis> applications available on
|
||||
the Internet. FreeBSD is source code compatible with most
|
||||
popular commercial Unix systems and thus most applications
|
||||
require few, if any, changes to compile.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Demand paged <emphasis>virtual memory</emphasis>
|
||||
and “merged VM/buffer cache” design efficiently satisfies
|
||||
applications with large appetites for memory while still
|
||||
maintaining interactive response to other users.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Shared libraries</emphasis> (the Unix
|
||||
equivalent of MS-Windows DLLs) provide for efficient use of
|
||||
disk space and memory.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A full compliment of <emphasis>C</emphasis>,
|
||||
<emphasis>C++</emphasis> and <emphasis>Fortran</emphasis> development tools. Many
|
||||
additional languages for advanced research and development are
|
||||
also available in the ports and packages collection.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Source code</emphasis> for the entire
|
||||
system means you have the greatest degree of control over your
|
||||
environment. Why be locked into a proprietary solution and at
|
||||
the mercy of your vendor when you can have a truly Open
|
||||
System?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Extensive <emphasis>on-line
|
||||
documentation</emphasis>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>And many more!</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>FreeBSD is based on the 4.4BSD-Lite release from Computer
|
||||
Systems Research Group (CSRG) at the University of California at
|
||||
Berkeley, and carries on the distinguished tradition of BSD systems
|
||||
development. In addition to the fine work provided by CSRG, the
|
||||
FreeBSD Project has put in many thousands of hours in fine tuning
|
||||
the system for maximum performance and reliability in real-life load
|
||||
situations. As many of the commercial giants struggle to field PC
|
||||
operating systems with such features, performance and reliability,
|
||||
FreeBSD can offer them <emphasis>now</emphasis>!</para>
|
||||
|
||||
<para>The applications to which FreeBSD can be put are truly limited
|
||||
only by your own imagination. From software development to factory
|
||||
automation, inventory control to azimuth correction of remote
|
||||
satellite antennae; if it can be done with a commercial UNIX product
|
||||
then it is more than likely that you can do it with FreeBSD, too!
|
||||
FreeBSD also benefits significantly from the literally thousands of
|
||||
high quality applications developed by research centers and
|
||||
universities around the world, often available at little to no cost.
|
||||
Commercial applications are also available and appearing in greater
|
||||
numbers every day.</para>
|
||||
|
||||
<para>Because the source code for FreeBSD itself is generally
|
||||
available, the system can also be customized to an almost unheard of
|
||||
degree for special applications or projects, and in ways not
|
||||
generally possible with operating systems from most major commercial
|
||||
vendors. Here is just a sampling of some of the applications in
|
||||
which people are currently using FreeBSD:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Internet Services:</emphasis> The
|
||||
robust TCP/IP networking built into FreeBSD makes it an ideal
|
||||
platform for a variety of Internet services such as:</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>FTP servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>World Wide Web servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Gopher servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Electronic Mail servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>USENET News</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Bulletin Board Systems</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>And more...</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>You can easily start out small with an
|
||||
inexpensive 386 class PC and upgrade as your enterprise
|
||||
grows.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Education:</emphasis> Are you a student
|
||||
of computer science or a related engineering field? There is
|
||||
no better way of learning about operating systems, computer
|
||||
architecture and networking than the hands on, under the hood
|
||||
experience that FreeBSD can provide. A number of freely
|
||||
available CAD, mathematical and graphic design packages also
|
||||
make it highly useful to those whose primary interest in a
|
||||
computer is to get <emphasis>other</emphasis> work
|
||||
done!</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Research:</emphasis> With source code
|
||||
for the entire system available, FreeBSD is an excellent
|
||||
platform for research in operating systems as well as other
|
||||
branches of computer science. FreeBSD's freely available
|
||||
nature also makes it possible for remote groups to collaborate
|
||||
on ideas or shared development without having to worry about
|
||||
special licensing agreements or limitations on what may be
|
||||
discussed in open forums.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Networking:</emphasis> Need a new
|
||||
router? A name server (DNS)? A firewall to keep people out
|
||||
of your internal network? FreeBSD can easily turn that unused
|
||||
386 or 486 PC sitting in the corner into an advanced router
|
||||
with sophisticated packet filtering capabilities.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>X Window workstation:</emphasis>
|
||||
FreeBSD is a fine choice for an inexpensive X terminal
|
||||
solution, either using the freely available XFree86 server or
|
||||
one of the excellent commercial servers provided by X Inside.
|
||||
Unlike an X terminal, FreeBSD allows many applications to be
|
||||
run locally, if desired, thus relieving the burden on a
|
||||
central server. FreeBSD can even boot “diskless”, making
|
||||
individual workstations even cheaper and easier to
|
||||
administer.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Software Development:</emphasis> The
|
||||
basic FreeBSD system comes with a full compliment of
|
||||
development tools including the renowned GNU C/C++ compiler
|
||||
and debugger.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>FreeBSD is available in both source and binary form on CDROM and
|
||||
via anonymous ftp. See <xref linkend="mirrors" remap="Obtaining
|
||||
FreeBSD"> for more details.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="history">
|
||||
<title>A Brief History of FreeBSD</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jkh;</emphasis>.</para>
|
||||
|
||||
<para>The FreeBSD project had its genesis in the early part of 1993,
|
||||
partially as an outgrowth of the “Unofficial 386BSD Patchkit” by the
|
||||
patchkit's last 3 coordinators: Nate Williams, Rod Grimes and
|
||||
myself.</para>
|
||||
|
||||
<para>Our original goal was to produce an intermediate snapshot of
|
||||
386BSD in order to fix a number of problems with it that the
|
||||
patchkit mechanism just was not capable of solving. Some of you may
|
||||
remember the early working title for the project being “386BSD 0.5”
|
||||
or “386BSD Interim” in reference to that fact.</para>
|
||||
|
||||
<para>386BSD was Bill Jolitz's operating system, which had been up to
|
||||
that point suffering rather severely from almost a year's worth of
|
||||
neglect. As the patchkit swelled ever more uncomfortably with each
|
||||
passing day, we were in unanimous agreement that something had to be
|
||||
done and decided to try and assist Bill by providing this interim
|
||||
“cleanup” snapshot. Those plans came to a rude halt when Bill
|
||||
Jolitz suddenly decided to withdraw his sanction from the project
|
||||
and without any clear indication of what would be done
|
||||
instead.</para>
|
||||
|
||||
<para>It did not take us long to decide that the goal remained
|
||||
worthwhile, even without Bill's support, and so we adopted the name
|
||||
“FreeBSD”, coined by David Greenman. Our initial objectives were
|
||||
set after consulting with the system's current users and, once it
|
||||
became clear that the project was on the road to perhaps even
|
||||
becoming a reality, I contacted Walnut Creek CDROM with an eye
|
||||
towards improving FreeBSD's distribution channels for those many
|
||||
unfortunates without easy access to the Internet. Walnut Creek
|
||||
CDROM not only supported the idea of distributing FreeBSD on CD but
|
||||
went so far as to provide the project with a machine to work on and
|
||||
a fast Internet connection. Without Walnut Creek CDROM's almost
|
||||
unprecedented degree of faith in what was, at the time, a completely
|
||||
unknown project, it is quite unlikely that FreeBSD would have gotten
|
||||
as far, as fast, as it has today.</para>
|
||||
|
||||
<para>The first CDROM (and general net-wide) distribution was FreeBSD
|
||||
1.0, released in December of 1993. This was based on the
|
||||
4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components
|
||||
also provided by 386BSD and the Free Software Foundation. It was a
|
||||
fairly reasonable success for a first offering, and we followed it
|
||||
with the highly successful FreeBSD 1.1 release in May of
|
||||
1994.</para>
|
||||
|
||||
<para>Around this time, some rather unexpected storm clouds formed on
|
||||
the horizon as Novell and U.C. Berkeley settled their long-running
|
||||
lawsuit over the legal status of the Berkeley Net/2 tape. A
|
||||
condition of that settlement was U.C. Berkeley's concession that
|
||||
large parts of Net/2 were “encumbered” code and the property of
|
||||
Novell, who had in turn acquired it from AT&T some time
|
||||
previously. What Berkeley got in return was Novell's “blessing”
|
||||
that the 4.4BSD-Lite release, when it was finally released, would be
|
||||
declared unencumbered and all existing Net/2 users would be strongly
|
||||
encouraged to switch. This included FreeBSD, and the project was
|
||||
given until the end of July 1994 to stop shipping its own Net/2
|
||||
based product. Under the terms of that agreement, the project was
|
||||
allowed one last release before the deadline, that release being
|
||||
FreeBSD 1.1.5.1.</para>
|
||||
|
||||
<para>FreeBSD then set about the arduous task of literally
|
||||
re-inventing itself from a completely new and rather incomplete set
|
||||
of 4.4BSD-Lite bits. The “Lite” releases were light in part because
|
||||
Berkeley's CSRG had removed large chunks of code required for
|
||||
actually constructing a bootable running system (due to various
|
||||
legal requirements) and the fact that the Intel port of 4.4 was
|
||||
highly incomplete. It took the project until December of 1994 to
|
||||
make this transition, and in January of 1995 it released FreeBSD 2.0
|
||||
to the net and on CDROM. Despite being still more than a little
|
||||
rough around the edges, the release was a significant success and
|
||||
was followed by the more robust and easier to install FreeBSD 2.0.5
|
||||
release in June of 1995.</para>
|
||||
|
||||
<para>We released FreeBSD 2.1.5 in August of 1996, and it appeared to
|
||||
be popular enough among the ISP and commercial communities that
|
||||
another release along the 2.1-stable branch was merited. This was
|
||||
FreeBSD 2.1.7.1, released in February 1997 and capping the end of
|
||||
mainstream development on 2.1-stable. Now in maintenance mode, only
|
||||
security enhancements and other critical bug fixes will be done on
|
||||
this branch (RELENG_2_1_0).</para>
|
||||
|
||||
<para>FreeBSD 2.2 was branched from the development mainline
|
||||
(“-current”) in November 1996 as the RELENG_2_2 branch, and the
|
||||
first full release (2.2.1) was released in April, 1997. Further
|
||||
releases along the 2.2 branch were done in the Summer and Fall of
|
||||
'97, the latest being 2.2.6 which appeared in late March of '98.
|
||||
The first official 3.0 release will appear later in 1998.</para>
|
||||
|
||||
<para>Long term development projects for everything from SMP to DEC
|
||||
ALPHA support will continue to take place in the 3.0-current branch
|
||||
and SNAPshot releases of 3.0 on CDROM (and, of course, on the net).</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="goals">
|
||||
<title>FreeBSD Project Goals</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jkh;</emphasis>.</para>
|
||||
|
||||
<para>The goals of the FreeBSD Project are to provide software that
|
||||
may be used for any purpose and without strings attached. Many of
|
||||
us have a significant investment in the code (and project) and would
|
||||
certainly not mind a little financial compensation now and then, but
|
||||
we're definitely not prepared to insist on it. We believe that our
|
||||
first and foremost “mission” is to provide code to any and all
|
||||
comers, and for whatever purpose, so that the code gets the widest
|
||||
possible use and provides the widest possible benefit. This is, I
|
||||
believe, one of the most fundamental goals of Free Software and one
|
||||
that we enthusiastically support.</para>
|
||||
|
||||
<para>That code in our source tree which falls under the GNU Public
|
||||
License (GPL) or GNU Library Public License (GLPL) comes with
|
||||
slightly more strings attached, though at least on the side of
|
||||
enforced access rather than the usual opposite. Due to the
|
||||
additional complexities that can evolve in the commercial use of GPL
|
||||
software, we do, however, endeavor to replace such software with
|
||||
submissions under the more relaxed BSD copyright whenever possible.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="development">
|
||||
<title>The FreeBSD Development Model</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.asami;</emphasis>.</para>
|
||||
|
||||
<para>The development of FreeBSD is a very open and flexible process,
|
||||
FreeBSD being literally built from the contributions of hundreds of
|
||||
people around the world, as can be seen from our <xref
|
||||
linkend="staff" remap="list of contributors">. We are constantly
|
||||
on the lookout for new developers and ideas, and those interested in
|
||||
becoming more closely involved with the project need simply contact
|
||||
us at the &a.hackers;. Those who prefer to work more independently
|
||||
are also accommodated, and they are free to use our FTP facilities
|
||||
at <ulink
|
||||
URL="ftp://ftp.freebsd.org/pub/FreeBSD/incoming">ftp.freebsd.org</ulink> to distribute their own patches or work-in-progress sources. The &a.announce; is also available to those wishing to make other FreeBSD users aware of major areas of work.</para>
|
||||
|
||||
<para>Useful things to know about the FreeBSD project and its
|
||||
development process, whether working independently or in close
|
||||
cooperation:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>The CVS
|
||||
repository<anchor id="development-cvs-repository"></term>
|
||||
<listitem>
|
||||
<para>The central source tree for FreeBSD is maintained by
|
||||
<ulink
|
||||
URL="http://www.cyclic.com/cyclic-pages/CVS-sheet.html">CVS</ulink> (Concurrent Version System), a freely available source code control tool which comes bundled with FreeBSD. The primary <ulink URL="http://www.freebsd.org/cgi/cvsweb.cgi">CVS repository</ulink> resides on a machine in Concord CA, USA from where it is replicated to numerous mirror machines throughout the world. The CVS tree, as well as the <xref linkend="current" remap="-current"> and <xref
|
||||
linkend="stable" remap="-stable"> trees which are checked
|
||||
out of it, can be easily replicated to your own machine as
|
||||
well. Please refer to the
|
||||
<xref linkend="synching" remap="Synchronizing your source
|
||||
tree"> section for more information on doing this.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The committers
|
||||
list<anchor id="development-committers"></term>
|
||||
|
||||
<listitem>
|
||||
<para>The <xref linkend="staff-committers" remap="committers">
|
||||
are the people who have <emphasis>write</emphasis> access to
|
||||
the CVS tree, and are thus authorized to make modifications
|
||||
to the FreeBSD source (the term “committer” comes from the
|
||||
<citerefentry><refentrytitle>cvs</refentrytitle><manvolnum>1</manvolnum></citerefentry> <command>commit</command> command, which is used to
|
||||
bring new changes into the CVS repository). The best way of
|
||||
making submissions for review by the committers list is to
|
||||
use the <citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry> command, though if something appears to be jammed in the system then you may also reach them by sending mail to <email>committers@freebsd.org</email>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The FreeBSD core
|
||||
team<anchor id="development-core"></term>
|
||||
|
||||
<listitem>
|
||||
<para>The <xref linkend="staff-core" remap="FreeBSD core
|
||||
team"> would be equivalent to the board of directors if
|
||||
the FreeBSD Project were a company. The primary task of the
|
||||
core team is to make sure the project, as a whole, is in
|
||||
good shape and is heading in the right directions. Inviting
|
||||
dedicated and responsible developers to join our group of
|
||||
committers is one of the functions of the core team, as is
|
||||
the recruitment of new core team members as others move on.
|
||||
Most current members of the core team started as committers
|
||||
who's addiction to the project got the better of
|
||||
them.</para>
|
||||
|
||||
<para>Some core team members also have specific <xref
|
||||
linkend="staff-who" remap="areas of responsibility">,
|
||||
meaning that they are committed to ensuring that some large
|
||||
portion of the system works as advertised.</para>
|
||||
|
||||
<note>
|
||||
<para>Most members of the core team are volunteers when it
|
||||
comes to FreeBSD development and do not benefit from the
|
||||
project financially, so “commitment” should also not be
|
||||
misconstrued as meaning “guaranteed support.” The
|
||||
“board of directors” analogy above is not
|
||||
actually very accurate, and it may be more suitable to say
|
||||
that these are the people who gave up their lives in favor
|
||||
of FreeBSD against their better judgement! <!-- smiley --><emphasis>;)</emphasis></para>
|
||||
</note>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Outside
|
||||
contributors</term>
|
||||
|
||||
<listitem>
|
||||
<para>Last, but definitely not least, the largest group of
|
||||
developers are the users themselves who provide feedback and
|
||||
bug-fixes to us on an almost constant basis. The primary
|
||||
way of keeping in touch with FreeBSD's more non-centralized
|
||||
development is to subscribe to the &a.hackers; (see <xref
|
||||
linkend="eresources-mail" remap="mailing list
|
||||
info">) where such things are discussed.</para>
|
||||
|
||||
<para><xref linkend="contrib-additional" remap="The list"> of
|
||||
those who have contributed something which made its way into
|
||||
our source tree is a long and growing one, so why not join
|
||||
it by contributing something back to FreeBSD today?
|
||||
<!-- smiley --><emphasis>:-)</emphasis></para>
|
||||
|
||||
<para>Providing code is not the only way of contributing to
|
||||
the project; for a more complete list of things that need
|
||||
doing, please refer to the <xref linkend="contrib"
|
||||
remap="how to
|
||||
contribute"> section in this handbook.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
<para>In summary, our development model is organized as a loose set of
|
||||
concentric circles. The centralized model is designed for the
|
||||
convenience of the <emphasis>users</emphasis> of FreeBSD, who are
|
||||
thereby provided with an easy way of tracking one central code base,
|
||||
not to keep potential contributors out! Our desire is to present a
|
||||
stable operating system with a large set of coherent <xref
|
||||
linkend="ports"
|
||||
remap="application programs"> that the users can easily install
|
||||
and use, and this model works very well in accomplishing
|
||||
that.</para>
|
||||
|
||||
<para>All we ask of those who would join us as FreeBSD developers is
|
||||
some of the same dedication its current people have to its continued
|
||||
success!</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="relnotes">
|
||||
<title>About the Current Release</title>
|
||||
|
||||
<para>FreeBSD is a freely available, full source 4.4BSD-Lite based
|
||||
release for Intel i386/i486/Pentium/PentiumPro/Pentium II (or
|
||||
compatible) based PC's. It is based primarily on software from U.C.
|
||||
Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD,
|
||||
386BSD, and the Free Software Foundation.</para>
|
||||
|
||||
<para>Since our release of FreeBSD 2.0 in January of 95, the
|
||||
performance, feature set, and stability of FreeBSD has improved
|
||||
dramatically. The largest change is a revamped virtual memory
|
||||
system with a merged VM/file buffer cache that not only increases
|
||||
performance, but reduces FreeBSD's memory footprint, making a 5MB
|
||||
configuration a more acceptable minimum. Other enhancements include
|
||||
full NIS client and server support, transaction TCP support,
|
||||
dial-on-demand PPP, an improved SCSI subsystem, early ISDN support,
|
||||
support for FDDI and Fast Ethernet (100Mbit) adapters, improved
|
||||
support for the Adaptec 2940 (WIDE and narrow) and many hundreds of
|
||||
bug fixes.</para>
|
||||
|
||||
<para>We have also taken the comments and suggestions of many of our
|
||||
users to heart and have attempted to provide what we hope is a more
|
||||
sane and easily understood installation process. Your feedback on
|
||||
this (constantly evolving) process is especially welcome!</para>
|
||||
|
||||
<para>In addition to the base distributions, FreeBSD offers a new
|
||||
ported software collection with hundreds of commonly sought-after
|
||||
programs. At the end of March 1998 there were more than 1300 ports!
|
||||
The list of ports ranges from http (WWW) servers, to games,
|
||||
languages, editors and almost everything in between. The entire
|
||||
ports collection requires approximately 26MB of storage, all ports
|
||||
being expressed as “deltas” to their original sources. This
|
||||
makes it much easier for us to update ports, and greatly reduces
|
||||
the disk space demands made by the older 1.0 ports collection. To
|
||||
compile a port, you simply change to the directory of the program
|
||||
you wish to install, type <command>make all</command> followed by <command>make install</command>
|
||||
after successful compilation and let the system do the rest. The
|
||||
full original distribution for each port you build is retrieved
|
||||
dynamically off the CDROM or a local ftp site, so you need only
|
||||
enough disk space to build the ports you want. (Almost) every port
|
||||
is also provided as a pre-compiled “package” which can be installed
|
||||
with a simple command (pkg_add) by those who do not wish to compile
|
||||
their own ports from source.</para>
|
||||
|
||||
<para>A number of additional documents which you may find very helpful
|
||||
in the process of installing and using FreeBSD may now also be found
|
||||
in the <filename>/usr/share/doc</filename> directory on any machine
|
||||
running FreeBSD 2.1 or later. You may view the locally installed
|
||||
manuals with any HTML capable browser using the following
|
||||
URLs:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>The FreeBSD handbook</term>
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="file:/usr/share/doc/handbook/handbook.html">file:/usr/share/doc/handbook/handbook.html</ulink></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The FreeBSD FAQ</term>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="file:/usr/share/doc/FAQ/FAQ.html">file:/usr/share/doc/FAQ/FAQ.html</ulink></para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
<para>You can also visit the master (and most frequently updated)
|
||||
copies at <ulink
|
||||
URL="http://www.freebsd.org">http://www.freebsd.org</ulink>.</para>
|
||||
|
||||
<para>The core of FreeBSD does not contain DES code which would
|
||||
inhibit its being exported outside the United States. There is an
|
||||
add-on package to the core distribution, for use only in the United
|
||||
States, that contains the programs that normally use DES. The
|
||||
auxiliary packages provided separately can be used by anyone. A
|
||||
freely (from outside the U.S.) exportable European distribution of
|
||||
DES for our non-U.S. users also exists and is described in the
|
||||
<ulink URL="../FAQ/FAQ.html">FreeBSD FAQ</ulink>.</para>
|
||||
|
||||
<para>If password security for FreeBSD is all you need, and you have
|
||||
no requirement for copying encrypted passwords from different hosts
|
||||
(Suns, DEC machines, etc) into FreeBSD password entries, then
|
||||
FreeBSD's MD5 based security may be all you require! We feel that
|
||||
our default security model is more than a match for DES, and without
|
||||
any messy export issues to deal with. If you are outside (or even
|
||||
inside) the U.S., give it a try!</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
1711
en/handbook/kernelconfig/chapter.sgml
Normal file
1711
en/handbook/kernelconfig/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
634
en/handbook/kerneldebug/chapter.sgml
Normal file
634
en/handbook/kerneldebug/chapter.sgml
Normal file
|
|
@ -0,0 +1,634 @@
|
|||
<chapter id="kerneldebug">
|
||||
<title>Kernel Debugging</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.paul; and &a.joerg;</emphasis></para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Debugging a Kernel Crash Dump with <command>kgdb</command></title>
|
||||
|
||||
<para>Here 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 <literal>config
|
||||
kernel</literal> line), or you can specify an alternate using the
|
||||
<citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command. Dumps to non-swap devices, tapes for example,
|
||||
are currently not supported. Config your kernel using
|
||||
<command>config -g</command>. See <xref linkend="kernelconfig"
|
||||
remap="Kernel Configuration"> for
|
||||
details on configuring the FreeBSD kernel.</para>
|
||||
|
||||
<para>Use the <citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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
|
||||
<citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>). This is normally arranged via
|
||||
<filename>/etc/rc.conf</filename> and <filename>/etc/rc</filename>.
|
||||
Alternatively, you can hard-code the dump device via the <literal>dump</literal>
|
||||
clause in the <literal>config</literal> 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.</para>
|
||||
|
||||
<note>
|
||||
<para>In the following, the term <command>kgdb</command> refers to
|
||||
<command>gdb</command> run in “kernel debug mode”. This can be
|
||||
accomplished by either starting the <command>gdb</command> with
|
||||
the option <option>-k</option>, or by linking and starting it
|
||||
under the name <command>kgdb</command>. 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.</para>
|
||||
</note>
|
||||
|
||||
<para>When the kernel has been built make a copy of it, say
|
||||
<filename>kernel.debug</filename>, and then run <command>strip
|
||||
-d</command> 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.</para>
|
||||
|
||||
<para>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 <option>-s</option> flag at the boot
|
||||
prompt, and then perform the following steps:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>fsck -p</userinput>
|
||||
&prompt.root; <userinput>mount -a -t ufs</userinput> # so your file system for /var/crash is writable
|
||||
&prompt.root; <userinput>savecore -N /kernel.panicked /var/crash</userinput>
|
||||
&prompt.root; <userinput>exit</userinput> # ...to multi-user</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This instructs <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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.</para>
|
||||
|
||||
<para>Now, after a crash dump, go to
|
||||
<filename>/sys/compile/WHATEVER</filename> and run <command>kgdb</command>. From <command>kgdb</command>
|
||||
do:
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>symbol-file kernel.debug</userinput>
|
||||
<userinput>exec-file /var/crash/kernel.0</userinput>
|
||||
<userinput>core-file /var/crash/vmcore.0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
and voila, you can debug the crash dump using the
|
||||
kernel sources just like you can for any other program.</para>
|
||||
|
||||
<para>Here is a script log of a <command>kgdb</command>
|
||||
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.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen> 1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:&prompt.root; <userinput>cd /sys/compile/URIAH</userinput>
|
||||
3:&prompt.root; <userinput>kgdb kernel /var/crash/vmcore.1</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>where</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up 10</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>frame frame->tf_ebp frame->tf_eip</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>list</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>print tp</userinput>
|
||||
53:Reading in symbols for ../../i386/i386/cons.c...done.
|
||||
54:$1 = (struct tty *) 0x1bae
|
||||
55:<prompt>(kgdb)</prompt> <userinput>print tp->t_line</userinput>
|
||||
56:$2 = 1767990816
|
||||
57:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
62:#2 0xf0132c34 in spec_open ()
|
||||
63:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
64:#3 0xf012d014 in vn_open ()
|
||||
65:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
66:#4 0xf012a183 in open ()
|
||||
67:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
75:Initial frame selected; you cannot go up.
|
||||
76:<prompt>(kgdb)</prompt> <userinput>quit</userinput>
|
||||
77:&prompt.root; <userinput>exit</userinput>
|
||||
78:exit
|
||||
79:
|
||||
80:Script done on Fri Dec 30 23:18:04 1994</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Comments to the above script:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>line 6:</term>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 20:</term>
|
||||
|
||||
<listitem>
|
||||
<para>This is the location of function
|
||||
<function>trap()</function> in the stack trace.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 36:</term>
|
||||
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 52:</term>
|
||||
|
||||
<listitem>
|
||||
<para>The pointer looks suspicious, but happens to be a valid
|
||||
address.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 56:</term>
|
||||
|
||||
<listitem>
|
||||
<para>However, it obviously points to garbage, so we have
|
||||
found our error! (For those unfamiliar with that particular
|
||||
piece of code: <literal>tp->t_line</literal>
|
||||
refers to the line discipline of the console device here,
|
||||
which must be a rather small integer number.)</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Post-mortem Analysis of a Dump</title>
|
||||
|
||||
<para>What do you do if a kernel dumped core but you did not expect
|
||||
it, and it is therefore not compiled using <command>config
|
||||
-g</command>? Not everything is lost here. Do not panic!</para>
|
||||
|
||||
<para>Of course, you still need to enable crash dumps. See above on
|
||||
the options you have to specify in order to do this.</para>
|
||||
|
||||
<para>Go to your kernel compile directory, and edit the line
|
||||
containing <literal>COPTFLAGS?=-O</literal>. Add the
|
||||
<option>-g</option> option there (but <emphasis>do not</emphasis>
|
||||
change anything on the level of optimization). If you do already
|
||||
know roughly the probable location of the failing piece of code
|
||||
(e.g., the <devicename>pcvt</devicename> driver in the example
|
||||
above), remove all the object files for this code. Rebuild the
|
||||
kernel. Due to the time stamp change on the Makefile, there will be
|
||||
some other object files rebuild, for example
|
||||
<filename>trap.o</filename>. With a bit of luck, the added
|
||||
<option>-g</option> 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
|
||||
<citerefentry><refentrytitle>size</refentrytitle><manvolnum>1</manvolnum></citerefentry> command. If there is a mismatch, you
|
||||
probably need to give up here.</para>
|
||||
|
||||
<para>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
|
||||
<command>kgdb</command> session until you know
|
||||
enough.</para>
|
||||
|
||||
<para>All this is not guaranteed to work, but it will do it fine in
|
||||
most cases.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>On-line Kernel Debugging Using DDB</title>
|
||||
|
||||
<para>While <command>kgdb</command> 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.</para>
|
||||
|
||||
<para>If you need to do low-level debugging on your kernel, there is
|
||||
an on-line debugger available called DDB. It allows to setting
|
||||
breakpoints, single-steping kernel functions, examining and changing
|
||||
kernel variables, etc. However, it cannot access kernel source
|
||||
files, and only has access to the global and static symbols, not to
|
||||
the full debug information like <command>kgdb</command>.</para>
|
||||
|
||||
<para>To configure your kernel to include DDB, add the option line
|
||||
|
||||
<programlisting>
|
||||
options DDB</programlisting> to your config file, and rebuild. (See <xref
|
||||
linkend="kernelconfig"
|
||||
remap="Kernel Configuration"> for details on configuring the
|
||||
FreeBSD kernel.</para>
|
||||
|
||||
<note>
|
||||
<para>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.)</para>
|
||||
</note>
|
||||
|
||||
<para>Once your DDB kernel is running, there are several ways to enter
|
||||
DDB. The first, and earliest way is to type the boot flag
|
||||
<option>-d</option> 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.</para>
|
||||
|
||||
<para>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 (<literal>options
|
||||
BREAK_TO_DEBUGGER</literal> 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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The DDB commands roughly resemble some <command>gdb</command> commands. The first thing you probably
|
||||
need to do is to set a breakpoint:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>b function-name</userinput>
|
||||
<userinput>b address</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Numbers are taken hexadecimal by default, but to make them
|
||||
distinct from symbol names; hexadecimal numbers starting with the
|
||||
letters <literal>a-f</literal> need to be preceded with
|
||||
<literal>0x</literal> (this is optional for other numbers). Simple
|
||||
expressions are allowed, for example: <literal>function-name +
|
||||
0x103</literal>.</para>
|
||||
|
||||
<para>To continue the operation of an interrupted kernel, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>c</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To get a stack trace, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>trace</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>Note 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.</para>
|
||||
</note>
|
||||
|
||||
<para>If you want to remove a breakpoint, use</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>del</userinput>
|
||||
<userinput>del address-expression</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The first form will be accepted immediately after
|
||||
a breakpoint hit, and deletes the current breakpoint. The second
|
||||
form can remove any breakpoint, but you need to specify the exact
|
||||
address; this can be obtained from:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>show b</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To single-step the kernel, try:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>s</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will step into functions, but you can make
|
||||
DDB trace them until the matching return statement is reached by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>n</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>This is different from <command>gdb</command>'s <command>next</command>
|
||||
statement; it is like <command>gdb</command>'s <command>finish</command>.</para>
|
||||
</note>
|
||||
|
||||
<para>To examine data from memory, use (for example):
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x/wx 0xf0133fe0,40</userinput>
|
||||
<userinput>x/hd db_symtab_space</userinput>
|
||||
<userinput>x/bc termbuf,10</userinput>
|
||||
<userinput>x/s stringbuf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x ,10</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Similarly, use
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x/ia foofunc,10</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
to disassemble the first 0x10 instructions of
|
||||
<function>foofunc</function>, and display them along with
|
||||
their offset from the beginning of <function>foofunc</function>.</para>
|
||||
|
||||
<para>To modify memory, use the write command:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>w/b termbuf 0xa 0xb 0</userinput>
|
||||
<userinput>w/w 0xf0010030 0 0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The command modifier
|
||||
(<literal>b</literal>/<literal>h</literal>/<literal>w</literal>) 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.</para>
|
||||
|
||||
<para>If you need to know the current registers, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>show reg</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Alternatively, you can display a single register
|
||||
value by e.g.
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>p $eax</userinput></screen>
|
||||
</informalexample> and modify it by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>set $eax new-value</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Should you need to call some kernel functions from DDB, simply
|
||||
say:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call func(arg1, arg2, ...)</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The return value will be printed.</para>
|
||||
|
||||
<para>For a <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> style summary of all running
|
||||
processes, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>ps</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now 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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call diediedie()</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>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 <command>continue</command> statement. There is now an alias for
|
||||
this: <command>panic</command>.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call boot(0)</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Which might be a good way to cleanly shut down the
|
||||
running system, <function>sync()</function> 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.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call cpu_reset()</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>is the final way out of disaster and almost the
|
||||
same as hitting the Big Red Button.</para>
|
||||
|
||||
<para>If you need a short command summary, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>help</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>However, it is highly recommended to have a
|
||||
printed copy of the <citerefentry><refentrytitle>ddb</refentrytitle><manvolnum>4</manvolnum></citerefentry> manual page
|
||||
ready for a debugging session. Remember that it is hard to read the
|
||||
on-line manual while single-stepping the kernel.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>On-line Kernel Debugging Using Remote GDB</title>
|
||||
|
||||
<para>This feature has been supported since FreeBSD 2.2, and it's
|
||||
actually a very neat one.</para>
|
||||
|
||||
<para>GDB has already supported <emphasis>remote debugging</emphasis>
|
||||
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).</para>
|
||||
|
||||
<para>You should configure the kernel in question with <command>config
|
||||
-g</command>, include <option>DDB</option> 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 <command>strip
|
||||
-x</command>, and boot it using the <option>-d</option> 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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>gdb -k kernel</userinput>
|
||||
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...
|
||||
<prompt>(kgdb)</prompt> </screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Initialize the remote debugging session (assuming the first
|
||||
serial port is being used) by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>(kgdb)</prompt> <userinput>target remote /dev/cuaa0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now, on the target host (the one that entered DDB right before
|
||||
even starting the device probe), type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
<prompt>db></prompt> <userinput>gdb</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>DDB will respond with:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Next trap will enter GDB remote protocol mode</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Every time you type <command>gdb</command>, the mode will be toggled between
|
||||
remote GDB and local DDB. In order to force a next trap
|
||||
immediately, simply type <command>s</command> (step). Your hosting GDB will now
|
||||
gain control over the target kernel:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
at ../../i386/i386/db_interface.c:257
|
||||
<prompt>(kgdb)</prompt></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>Remote GDB can also be used to debug LKMs. First build the LKM
|
||||
with debugging symbols:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
|
||||
&prompt.root; <userinput>make clean; make COPTS=-g</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Then install this version of the module on the target machine,
|
||||
load it and use <command>modstat</command> to find out
|
||||
where it was loaded:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>linux</userinput>
|
||||
&prompt.root; <userinput>modstat</userinput>
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f5109000 001c f510f010 1 linux_mod</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Take 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 <command>add-symbol-file</command> command in GDB to tell the
|
||||
debugger about the module:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>(kgdb)</prompt> <userinput>add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020</userinput>
|
||||
add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
|
||||
text_addr = 0xf5109020? (y or n) <userinput>y</userinput>
|
||||
<prompt>(kgdb)</prompt></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You now have access to all the symbols in the LKM.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Debugging a Console Driver</title>
|
||||
|
||||
<para>Since 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 <option>-h</option> at the <prompt>Boot:</prompt> 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.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
161
en/handbook/kernelopts/chapter.sgml
Normal file
161
en/handbook/kernelopts/chapter.sgml
Normal file
|
|
@ -0,0 +1,161 @@
|
|||
<chapter id="kernelopts">
|
||||
<title>Adding New Kernel Configuration Options</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.joerg;</emphasis></para>
|
||||
|
||||
<note>
|
||||
<para>You should be familiar with the section about <xref
|
||||
linkend="kernelconfig" remap="kernel configuration">
|
||||
before reading here.</para>
|
||||
</note>
|
||||
|
||||
<sect1>
|
||||
<title>What's a <emphasis>Kernel Option</emphasis>, Anyway?</title>
|
||||
|
||||
<para>The use of kernel options is basically described in the <xref
|
||||
linkend="kernelconfig-options" remap="kernel configuration">
|
||||
section. There's also an explanation of “historic” and
|
||||
“new-style” options. The ultimate goal is to eventually turn all
|
||||
the supported options in the kernel into new-style ones, so for
|
||||
people who correctly did a <command>make depend</command>
|
||||
in their kernel compile directory after running
|
||||
<citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry>, the build process will automatically
|
||||
pick up modified options, and only recompile those files where it is
|
||||
necessary. Wiping out the old compile directory on each run of
|
||||
<citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> as it is still done now can then be
|
||||
eliminated again.</para>
|
||||
|
||||
<para>Basically, a kernel option is nothing else than the definition
|
||||
of a C preprocessor macro for the kernel compilation process. To
|
||||
make the build truly optional, the corresponding part of the kernel
|
||||
source (or kernel <filename>.h</filename> file) must be written with
|
||||
the option concept in mind, i.e. the default must have been made
|
||||
overridable by the config option. This is usually done with
|
||||
something like:</para>
|
||||
|
||||
<programlisting>
|
||||
#ifndef THIS_OPTION
|
||||
#define THIS_OPTION (some_default_value)
|
||||
#endif /* THIS_OPTION */</programlisting>
|
||||
|
||||
<para>This way, an administrator mentioning another value for the
|
||||
option in his config file will take the default out of effect, and
|
||||
replace it with his new value. Clearly, the new value will be
|
||||
substituted into the source code during the preprocessor run, so it
|
||||
must be a valid C expression in whatever context the default value
|
||||
would have been used.</para>
|
||||
|
||||
<para>It is also possible to create value-less options that simply
|
||||
enable or disable a particular piece of code by embracing it
|
||||
in</para>
|
||||
|
||||
<programlisting>
|
||||
#ifdef THAT_OPTION
|
||||
|
||||
[your code here]
|
||||
|
||||
#endif</programlisting>
|
||||
|
||||
<para>Simply mentioning <literal>THAT_OPTION</literal> in the config
|
||||
file (with or without any value) will then turn on the corresponding
|
||||
piece of code.</para>
|
||||
|
||||
<para>People familiar with the C language will immediately recognize
|
||||
that everything could be counted as a “config option” where there
|
||||
is at least a single <literal>#ifdef</literal>
|
||||
referencing it... However, it's unlikely that many people would
|
||||
put</para>
|
||||
|
||||
<programlisting>
|
||||
options notyet,notdef</programlisting>
|
||||
|
||||
<para>in their config file, and then wonder why the kernel compilation
|
||||
falls over. <!-- smiley -->:-)</para>
|
||||
|
||||
<para>Clearly, using arbitrary names for the options makes it very
|
||||
hard to track their usage throughout the kernel source tree. That
|
||||
is the rationale behind the <emphasis>new-style</emphasis> option
|
||||
scheme, where each option goes into a separate
|
||||
<filename>.h</filename> file in the kernel compile directory, which
|
||||
is by convention named
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename>. This way,
|
||||
the usual Makefile dependencies could be applied, and <command>make</command> can determine what needs to be recompiled
|
||||
once an option has been changed.</para>
|
||||
|
||||
<para>The old-style option mechanism still has one advantage for local
|
||||
options or maybe experimental options that have a short anticipated
|
||||
lifetime: since it is easy to add a new <literal>#ifdef</literal> to the kernel source, this has already
|
||||
made it a kernel config option. In this case, the administrator
|
||||
using such an option is responsible himself for knowing about its
|
||||
implications (and maybe manually forcing the recompilation of parts
|
||||
of his kernel). Once the transition of all supported options has
|
||||
been done, <citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> will warn whenever an
|
||||
unsupported option appears in the config file, but it will
|
||||
nevertheless include it into the kernel Makefile.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Now What Do I Have to Do for it?</title>
|
||||
|
||||
<para>First, edit <filename>sys/conf/options</filename> (or
|
||||
<filename>sys/i386/conf/options.<replaceable><arch></replaceable></filename>, e. g. <filename>sys/i386/conf/options.i386</filename>), and select an <filename>opt_<replaceable>foo</replaceable>.h</filename> file where your new option would best go into.</para>
|
||||
|
||||
<para>If there is already something that comes close to the purpose of
|
||||
the new option, pick this. For example, options modifying the
|
||||
overall behaviour of the SCSI subsystem can go into
|
||||
<filename>opt_scsi.h</filename>. By default, simply mentioning an
|
||||
option in the appropriate option file, say <literal>FOO</literal>,
|
||||
implies its value will go into the corresponding file
|
||||
<filename>opt_foo.h</filename>. This can be overridden on the
|
||||
right-hand side of a rule by specifying another filename.</para>
|
||||
|
||||
<para>If there is no
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> already
|
||||
available for the intended new option, invent a new name. Make it
|
||||
meaningful, and comment the new section in the
|
||||
<filename>options[<replaceable>.<arch></replaceable>]</filename> file. <citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> will automagically pick up the change, and create that file next time it is run. Most options should go in a header file by themselves..</para>
|
||||
|
||||
<para>Packing too many options into a single
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> will cause
|
||||
too many kernel files to be rebuilt when one of the options has been
|
||||
changed in the config file.</para>
|
||||
|
||||
<para>Finally, find out which kernel files depend on the new option.
|
||||
Unless you have just invented your option, and it does not exist
|
||||
anywhere yet,
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>find /usr/src/sys -name type f | xargs fgrep NEW_OPTION</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
is your friend in finding them. Go and edit all those files,
|
||||
and add
|
||||
|
||||
<programlisting>
|
||||
#include "opt_foo.h"</programlisting>
|
||||
|
||||
<emphasis>on top</emphasis>, before all the <literal>#include <xxx.h></literal> stuff. This sequence
|
||||
is most important as the options could override defaults from the
|
||||
regular include files, if the defaults are of the form
|
||||
|
||||
<programlisting>
|
||||
#ifndef NEW_OPTION
|
||||
#define NEW_OPTION (something)
|
||||
#endif</programlisting>
|
||||
|
||||
in the regular header.</para>
|
||||
|
||||
<para>Adding an option that overrides something in a system header
|
||||
file (i.e., a file sitting in
|
||||
<filename>/usr/include/sys/</filename>) is almost always a mistake.
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> cannot be
|
||||
included into those files since it would break the headers more
|
||||
seriously, but if it is not included, then places that include it
|
||||
may get an inconsistent value for the option. Yes, there are
|
||||
precedents for this right now, but that does not make them more
|
||||
correct.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
352
en/handbook/l10n/chapter.sgml
Normal file
352
en/handbook/l10n/chapter.sgml
Normal file
|
|
@ -0,0 +1,352 @@
|
|||
<chapter id="l10n">
|
||||
<title>Localization</title>
|
||||
|
||||
|
||||
<sect1 id="russian">
|
||||
<title>Russian Language (KOI8-R encoding)</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.ache;<!-- <br> --> 1 May
|
||||
1997</emphasis>.</para>
|
||||
|
||||
<para>See more info about KOI8-R encoding at <ulink
|
||||
URL="http://www.nagual.pp.ru/~ache/koi8.html">KOI8-R References
|
||||
(Russian Net Character Set)</ulink>.</para>
|
||||
|
||||
|
||||
<sect2 id="russian-console">
|
||||
<title>Console Setup</title>
|
||||
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Add following line to your kernel configuration file:
|
||||
|
||||
<programlisting>
|
||||
options "SC_MOUSE_CHAR=0x03"</programlisting> to move character
|
||||
codes used for mouse cursor off KOI8-R pseudographics
|
||||
range.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Russian console entry in
|
||||
<filename>/etc/rc.conf</filename> should looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
keymap=ru.koi8-r
|
||||
keychange="61 ^[[K"
|
||||
scrnmap=koi8-r2cp866
|
||||
font8x16=cp866b-8x16
|
||||
font8x14=cp866-8x14
|
||||
font8x8=cp866-8x8</programlisting>
|
||||
|
||||
<note>
|
||||
<para>^[ means that real ESC character must be entered into
|
||||
<filename>/etc/rc.conf</filename>, not just ^[
|
||||
string.</para>
|
||||
</note>
|
||||
|
||||
<para>This tuning means KOI8-R keyboard with Alternative
|
||||
screen font mapped to KOI8-R encoding to preserve
|
||||
pseudographics, <literal>Gray Delete</literal>
|
||||
key remapped to match Russian <citerefentry><refentrytitle>termcap</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry for FreeBSD
|
||||
console.</para>
|
||||
|
||||
<para>RUS/LAT switch will be <literal>CapsLock</literal>. Old CapsLock function still
|
||||
available via <literal>Shift+CapsLock</literal>.
|
||||
CapsLock LED will indicate RUS mode, not CapsLock
|
||||
mode.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>For each <literal>ttyv?</literal> entry in
|
||||
<filename>/etc/ttys</filename> change terminal type from
|
||||
<literal>cons25</literal> to <literal>cons25r</literal>, i.e. each entry should looks
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
ttyv0 "/usr/libexec/getty Pc" cons25r on secure</programlisting>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-locale">
|
||||
<title>Locale Setup</title>
|
||||
|
||||
<para><anchor id="russian-env"> There is two environment variables
|
||||
for locale setup:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><envar>LANG</envar> for POSIX
|
||||
<citerefentry><refentrytitle>setlocale</refentrytitle><manvolnum>3</manvolnum></citerefentry> family functions;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><envar>MM_CHARSET</envar> for applications MIME
|
||||
chararter set.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>The best way is using <filename>/etc/login.conf</filename>
|
||||
<literal>russian</literal> user's login class in
|
||||
<citerefentry><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry login class
|
||||
position. See <citerefentry><refentrytitle>login.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||||
details.</para>
|
||||
|
||||
|
||||
<sect3 id="russian-class">
|
||||
<title>Login Class Method</title>
|
||||
|
||||
<para>First of all check your <filename>/etc/login.conf</filename>
|
||||
have <literal>russian</literal> login class, this
|
||||
entry may looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
russian:Russian Users Accounts:\
|
||||
:charset=KOI8-R:\
|
||||
:lang=ru_RU.KOI8-R:\
|
||||
:tc=default:</programlisting>
|
||||
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>vipw</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>vipw</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new
|
||||
users, <filename>/etc/master.passwd</filename> entry should
|
||||
looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
user:password:1111:11:russian:0:0:User Name:/home/user:/bin/csh</programlisting>
|
||||
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new
|
||||
users:</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Set
|
||||
|
||||
<programlisting>
|
||||
defaultclass = russian</programlisting> in
|
||||
<filename>/etc/adduser.conf</filename> (you must enter
|
||||
<literal>default</literal> class for all
|
||||
non-Russian users in this case);</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Alternative variant will be answering <literal>russian</literal> each time when you see
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>Enter login class:</prompt> default []:</screen>
|
||||
</informalexample> prompt from
|
||||
<citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry>;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Another variant: call
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>adduser -class russian</userinput></screen>
|
||||
</informalexample> for each Russian user
|
||||
you want to add.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>pw</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>pw</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new users,
|
||||
call it in this form:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>pw useradd user_name -L russian</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect4>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Shell Startup Files Method</title>
|
||||
|
||||
<para>If you don't want to use
|
||||
<xref linkend="russian-class" remap="login class method"> for
|
||||
some reasons, just set this
|
||||
<xref linkend="russian-env" remap="two environment variables">
|
||||
in the following shell startup files:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/etc/profile</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
LANG=ru_RU.KOI8-R; export LANG
|
||||
MM_CHARSET=KOI8-R; export MM_CHARSET</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/etc/csh.login</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
setenv LANG ru_RU.KOI8-R
|
||||
setenv MM_CHARSET KOI8-R</programlisting>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>Alternatively you can add this instructions to</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/usr/share/skel/dot.profile</filename>:</para>
|
||||
|
||||
<para>(similar to <filename>/etc/profile</filename>
|
||||
above);</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/usr/share/skel/dot.login</filename>:</para>
|
||||
|
||||
<para>(similar to <filename>/etc/csh.login</filename>
|
||||
above).</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-printer">
|
||||
<title>Printer Setup</title>
|
||||
|
||||
<para>Since most printers with Russian characters comes with
|
||||
hardware code page CP866, special output filter needed for KOI8-R
|
||||
-> CP866 conversion. Such filter installed by default as
|
||||
<filename>/usr/libexec/lpr/ru/koi2alt</filename>. So, Russian
|
||||
printer <filename>/etc/printcap</filename> entry should looks
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
lp|Russian local line printer:\
|
||||
:sh:of=/usr/libexec/lpr/ru/koi2alt:\
|
||||
:lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:</programlisting>
|
||||
|
||||
<para>See <citerefentry><refentrytitle>printcap</refentrytitle><manvolnum>5</manvolnum></citerefentry> for detailed description.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-msdosfs">
|
||||
<title>MSDOS FS and Russian file names</title>
|
||||
|
||||
<para>Look at following example <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry to enable support for Russian
|
||||
file names in MSDOS FS:</para>
|
||||
|
||||
<programlisting>
|
||||
/dev/sd0s1 /dos/c msdos rw,-W=koi2dos,-L=ru_RU.KOI8-R 0 0</programlisting>
|
||||
|
||||
<para>See
|
||||
<citerefentry><refentrytitle>mount_msdos</refentrytitle><manvolnum>8</manvolnum></citerefentry>for detailed description of
|
||||
<option>-W</option> and <option>-L</option> options.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-xwindow">
|
||||
<title>X Window Setup</title>
|
||||
|
||||
<para>Step by step instructions:</para>
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Do
|
||||
<xref linkend="russian-locale" remap="non-X locale setup">
|
||||
first as described.</para>
|
||||
|
||||
<note>
|
||||
<para><anchor id="russian-note">Russian KOI8-R locale may
|
||||
not work with old XFree86 releases (lower than 3.3).
|
||||
XFree86 port from
|
||||
<filename>/usr/ports/x11/XFree86</filename> already have
|
||||
most recent XFree86 version, so it will work, if you
|
||||
install XFree86 from this port. XFree86 version shipped
|
||||
with the latest FreeBSD distribution should work too
|
||||
(check XFree86 version number not less than 3.3
|
||||
first).</para>
|
||||
</note>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Go to <filename>/usr/ports/russian/X.language</filename>
|
||||
directory and say
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample> there. This port install latest
|
||||
version of KOI8-R fonts. XFree86 3.3 already have some
|
||||
KOI8-R fonts, but this ones scaled better.</para>
|
||||
|
||||
<para>Check find <literal>"Files"</literal> section
|
||||
in your <filename>/etc/XF86Config</filename>, following
|
||||
lines must be before any other <literal>FontPath</literal>
|
||||
entries:</para>
|
||||
|
||||
<programlisting>
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/misc"
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/75dpi"
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/100dpi"</programlisting>
|
||||
|
||||
<para>If you use high resolution video mode, swap 75 dpi and
|
||||
100 dpi lines.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>To activate Russian keyboard add
|
||||
|
||||
<programlisting>
|
||||
XkbKeymap "xfree86(ru)"</programlisting> line into
|
||||
<literal>"Keyboard"</literal> section in your
|
||||
<filename>/etc/XF86Config</filename>, also make sure that
|
||||
<literal>XkbDisable</literal> is turned off
|
||||
(commented out) there.</para>
|
||||
|
||||
<para>RUS/LAT switch will be <literal>CapsLock</literal>. Old CapsLock function still
|
||||
available via <literal>Shift+CapsLock</literal>
|
||||
(in LAT mode only).</para>
|
||||
|
||||
<note>
|
||||
<para>Russian XKB keyboard may not work with old XFree86
|
||||
versions, see <xref
|
||||
linkend="russian-note" remap="locale note"> for more info.
|
||||
Russian XKB keyboard may not work with non-localized
|
||||
applications too, minimally localized application should
|
||||
call <literal>XtSetLanguageProc
|
||||
(NULL, NULL, NULL);</literal> function early in the program.</para>
|
||||
</note>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="german">
|
||||
<title>German Language (ISO 8859-1)</title>
|
||||
|
||||
<para>Slaven Rezic <email>eserte@cs.tu-berlin.de</email> wrote a tutorial how to use umlauts on a FreeBSD machine. The tutorial is written in German and available at <ulink URL="http://www.de.freebsd.org/de/umlaute/">http://www.de.freebsd.org/de/umlaute/</ulink>.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
827
en/handbook/linuxemu/chapter.sgml
Normal file
827
en/handbook/linuxemu/chapter.sgml
Normal file
|
|
@ -0,0 +1,827 @@
|
|||
<chapter id="linuxemu">
|
||||
<title>Linux Emulation</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.handy; and &a.rich;</emphasis></para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>How to Install the Linux Emulator</title>
|
||||
|
||||
<para>Linux emulation in FreeBSD has reached a point where it is
|
||||
possible to run a large fraction of Linux binaries in both a.out and
|
||||
ELF format. The linux emulation in the 2.1-STABLE branch is capable
|
||||
of running Linux DOOM and Mathematica; the version present in
|
||||
FreeBSD-2.2-RELEASE is vastly more capable and runs all these as
|
||||
well as Quake, Abuse, IDL, netrek for Linux and a whole host of
|
||||
other programs.</para>
|
||||
|
||||
<para>There are some Linux-specific operating system features that are
|
||||
not supported on FreeBSD. Linux binaries will not work on FreeBSD
|
||||
if they use the Linux <filename>/proc</filename> filesystem (which
|
||||
is different from the optional FreeBSD <filename>/proc</filename>
|
||||
filesystem) or i386-specific calls, such as enabling virtual 8086
|
||||
mode.</para>
|
||||
|
||||
<para>To tell whether your kernel is configured for Linux
|
||||
compatibility simply run any Linux binary. If it prints the error
|
||||
message <errorname>linux-executable: Exec format error. Wrong Architecture.</errorname> then you do not have linux compatibility support
|
||||
and you need to configure and install a new kernel.</para>
|
||||
|
||||
<para>Depending on which version of FreeBSD you are running, how you
|
||||
get Linux-emulation up will vary slightly:</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Emulation in 2.1-STABLE</title>
|
||||
|
||||
<para>The <filename>GENERIC</filename> kernel in 2.1-STABLE is not
|
||||
configured for linux compatibility so you must reconfigure your
|
||||
kernel for it. There are two ways to do this: 1. linking the
|
||||
emulator statically in the kernel itself and 2. configuring your
|
||||
kernel to dynamically load the linux loadable kernel module
|
||||
(LKM).</para>
|
||||
|
||||
<para>To enable the emulator, add the following to your
|
||||
configuration file (c.f.
|
||||
<filename>/sys/i386/conf/LINT</filename>):</para>
|
||||
|
||||
<programlisting>
|
||||
options COMPAT_LINUX</programlisting>
|
||||
|
||||
<para>If you want to run doom or other applications
|
||||
that need shared memory, also add the following.</para>
|
||||
|
||||
<programlisting>
|
||||
options SYSVSHM</programlisting>
|
||||
|
||||
<para>The linux system calls require 4.3BSD system
|
||||
call compatibility. So make sure you have the following.</para>
|
||||
|
||||
<programlisting>
|
||||
options "COMPAT_43"</programlisting>
|
||||
|
||||
<para>If you prefer to statically link the emulator in the kernel
|
||||
rather than use the loadable kernel module (LKM), then add</para>
|
||||
|
||||
<programlisting>
|
||||
options LINUX</programlisting>
|
||||
|
||||
<para>Then run config and install the new kernel as
|
||||
described in the
|
||||
<xref linkend="kernelconfig" remap="kernel configuration">
|
||||
section.</para>
|
||||
|
||||
<para>If you decide to use the LKM you must also install the
|
||||
loadable module. A mismatch of versions between the kernel and
|
||||
loadable module can cause the kernel to crash, so the safest thing
|
||||
to do is to reinstall the LKM when you install the kernel.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
|
||||
&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Once you have installed the kernel and the LKM,
|
||||
you can invoke `linux' as root to load the LKM.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>linux</userinput>
|
||||
Linux emulator installed
|
||||
Module loaded as ID 0</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To see whether the LKM is loaded, run
|
||||
<command>modstat</command>.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; modstat
|
||||
Type Id Off Loadaddr Size Info Rev
|
||||
Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You can cause the LKM to be loaded when the
|
||||
system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and
|
||||
2.1-STABLE enable it in <filename>/etc/sysconfig</filename>
|
||||
|
||||
<programlisting>
|
||||
linux=YES</programlisting> by changing it from NO to YES. FreeBSD 2.1
|
||||
RELEASE and earlier do not have such a line and on those you will
|
||||
need to edit <filename>/etc/rc.local</filename> to add the following line.</para>
|
||||
|
||||
<programlisting>
|
||||
linux</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Emulation in 2.2.2-RELEASE and later</title>
|
||||
|
||||
<para>It is no longer necessary to specify <literal>options LINUX</literal> or
|
||||
<literal>options COMPAT_LINUX</literal>. Linux emulation is done with an LKM
|
||||
(“Loadable Kernel Module”) so it can be installed on the fly
|
||||
without having to reboot. You will need the following things in
|
||||
your startup files, however:</para>
|
||||
<orderedlist>
|
||||
|
||||
<listitem>
|
||||
<para>In <filename>/etc/rc.conf</filename>, you need the
|
||||
following line:</para>
|
||||
|
||||
<programlisting>
|
||||
linux_enable=YES</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>This, in turn, triggers the following action in
|
||||
<filename>/etc/rc.i386</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
# Start the Linux binary emulation if requested.
|
||||
if [ "X${linux_enable}" = X"YES" ]; then echo -n '
|
||||
linux'; linux > /dev/null 2>&1
|
||||
fi</programlisting>
|
||||
</listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
|
||||
<para>If you want to verify it is running, modstat will do that:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>However, there have been reports that this
|
||||
fails on some 2.2-RELEASE and later systems. If for some reason
|
||||
you cannot load the linux LKM, then statically link the emulator
|
||||
in the kernel by adding
|
||||
|
||||
<programlisting>
|
||||
options LINUX</programlisting>
|
||||
|
||||
to your kernel config file. Then run config
|
||||
and install the new kernel as described in the <xref
|
||||
linkend="kernelconfig"
|
||||
remap="kernel configuration"> section.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Runtime Libraries</title>
|
||||
|
||||
|
||||
<sect3>
|
||||
<title>Installing using the linux_lib port</title>
|
||||
|
||||
<para>Most linux applications use shared libraries, so you are
|
||||
still not done until you install the shared libraries. It is
|
||||
possible to do this by hand, however, it is vastly simpler to
|
||||
just grab the linux_lib port:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/ports-current/emulators/linux_lib</userinput>
|
||||
&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>and you should have a working linux emulator. Legend (and
|
||||
the mail archives <!-- smiley -->:-) seems to hold that Linux emulation works
|
||||
best with linux binaries linked against the ZMAGIC libraries;
|
||||
QMAGIC libraries (such as those used in Slackware V2.0) may tend
|
||||
to give the Linuxulator heartburn. As of this writing (March
|
||||
1996) ELF emulation is still in the formulative stages but seems
|
||||
to work pretty well. Also, expect some programs to complain
|
||||
about incorrect minor versions. In general this does not seem
|
||||
to be a problem.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Installing libraries manually</title>
|
||||
|
||||
<para>If you do not have the “ports” distribution, you can
|
||||
install the libraries by hand instead. You will need the Linux
|
||||
shared libraries that the program depends on and the runtime
|
||||
linker. Also, you will need to create a "shadow root"
|
||||
directory, <filename>/compat/linux</filename>, for Linux
|
||||
libraries on your FreeBSD system. Any shared libraries opened
|
||||
by Linux programs run under FreeBSD will look in this tree
|
||||
first. So, if a Linux program loads, for example,
|
||||
<filename>/lib/libc.so</filename>, FreeBSD will first try to
|
||||
open <filename>/compat/linux/lib/libc.so</filename>, and if that
|
||||
does not exist then it will try
|
||||
<filename>/lib/libc.so</filename>. Shared libraries should be
|
||||
installed in the shadow tree
|
||||
<filename>/compat/linux/lib</filename> rather than the paths
|
||||
that the Linux <command>ld.so</command> reports.</para>
|
||||
|
||||
<para>FreeBSD-2.2-RELEASE and later works slightly differently
|
||||
with respect to <command>/compat/linux</command>. On -CURRENT, all files, not just
|
||||
libraries, are searched for from the “shadow root”
|
||||
<filename>/compat/linux</filename>.</para>
|
||||
|
||||
<para>Generally, you will need to look for the shared libraries
|
||||
that Linux binaries depend on only the first few times that you
|
||||
install a Linux program on your FreeBSD system. After a while,
|
||||
you will have a sufficient set of Linux shared libraries on your
|
||||
system to be able to run newly imported Linux binaries without
|
||||
any extra work.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>How to install additional shared libraries</title>
|
||||
|
||||
<para>What if you install the <filename>linux_lib</filename> port and your application
|
||||
still complains about missing shared libraries? How do you know
|
||||
which shared libraries Linux binaries need, and where to get
|
||||
them? Basically, there are 2 possibilities (when following these
|
||||
instructions: you will need to be root on your FreeBSD system to
|
||||
do the necessary installation steps).</para>
|
||||
|
||||
<para>If you have access to a Linux system, see what shared
|
||||
libraries it needs, and copy them to your FreeBSD system.
|
||||
Example: you have just ftp'ed the Linux binary of Doom. Put it
|
||||
on the Linux system you have access to, and check which shared
|
||||
libraries it needs by running <command>ldd linuxxdoom</command>:</para>
|
||||
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>ldd linuxxdoom</userinput>
|
||||
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
|
||||
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You would need to get all the files from the last column,
|
||||
and put them under <filename>/compat/linux</filename>, with the
|
||||
names in the first column as symbolic links pointing to them.
|
||||
This means you eventually have these files on your FreeBSD
|
||||
system:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/usr/X11/lib/libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
|
||||
/compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>Note that if you already have a Linux shared library with
|
||||
a matching major revision number to the first column of the
|
||||
<command>ldd</command> output, you will not need to copy the file named in the
|
||||
last column to your system, the one you already have should
|
||||
work. It is advisable to copy the shared library anyway if it
|
||||
is a newer version, though. You can remove the old one, as
|
||||
long as you make the symbolic link point to the new one. So,
|
||||
if you have these libraries on your system:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/libc.so.4.6.27
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>and you find a new binary that claims to require a later
|
||||
version according to the output of <command>ldd</command>:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If it is only one or two versions out of date in the in
|
||||
the trailing digit then do not worry about copying
|
||||
<filename>/lib/libc.so.4.6.29</filename> too, because the
|
||||
program should work fine with the slightly older version.
|
||||
However, if you like you can decide to replace the
|
||||
<filename>libc.so</filename> anyway, and that should leave you
|
||||
with:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/libc.so.4.6.29
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
<para>The symbolic link mechanism is <emphasis>only</emphasis>
|
||||
needed for Linux binaries. The FreeBSD runtime linker takes
|
||||
care of looking for matching major revision numbers itself and
|
||||
you do not need to worry about it.</para>
|
||||
</note>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Configuring the <filename>ld.so</filename> — for FreeBSD
|
||||
2.2-RELEASE only</title>
|
||||
|
||||
<para>This section applies only to FreeBSD 2.2-RELEASE and later.
|
||||
Those running 2.1-STABLE should skip this section.</para>
|
||||
|
||||
<para>Finally, if you run FreeBSD 2.2-RELEASE you must make sure
|
||||
that you have the Linux runtime linker and its config files on
|
||||
your system. You should copy these files from the Linux system
|
||||
to their appropriate place on your FreeBSD system (to the
|
||||
<filename>/compat/linux</filename> tree):</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/ld.so
|
||||
/compat/linux/etc/ld.so.config</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If you do not have access to a Linux system, you should get
|
||||
the extra files you need from various ftp sites. Information on
|
||||
where to look for the various files is appended below. For now,
|
||||
let us assume you know where to get the files.</para>
|
||||
|
||||
<para>Retrieve the following files (all from the same ftp site to
|
||||
avoid any version mismatches), and install them under
|
||||
<filename>/compat/linux</filename> (i.e.
|
||||
<filename>/foo/bar</filename> is installed as
|
||||
<filename>/compat/linux/foo/bar</filename>):</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/sbin/ldconfig
|
||||
/usr/bin/ldd
|
||||
/lib/libc.so.x.y.z
|
||||
/lib/ld.so</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><command>ldconfig</command> and <command>ldd</command> do not necessarily need to be under
|
||||
<filename>/compat/linux</filename>; you can install them
|
||||
elsewhere in the system too. Just make sure they do not conflict
|
||||
with their FreeBSD counterparts. A good idea would be to install
|
||||
them in <filename>/usr/local/bin</filename> as <command>ldconfig-linux</command>
|
||||
and <command>ldd-linux</command>.</para>
|
||||
|
||||
<para>Create the file
|
||||
<filename>/compat/linux/etc/ld.so.conf</filename>, containing
|
||||
the directories in which the Linux runtime linker should look
|
||||
for shared libs. It is a plain text file, containing a directory
|
||||
name on each line. <filename>/lib</filename> and
|
||||
<filename>/usr/lib</filename> are standard, you could add the
|
||||
following:</para>
|
||||
|
||||
<programlisting>
|
||||
/usr/X11/lib
|
||||
/usr/local/lib</programlisting>
|
||||
|
||||
<para>When a linux binary opens a library such as
|
||||
<filename>/lib/libc.so</filename> the emulator maps the name to
|
||||
<filename>/compat/linux/lib/libc.so</filename> internally. All
|
||||
linux libraries should be installed under /compat/linux (e.g.
|
||||
<filename>/compat/linux/lib/libc.so</filename>,
|
||||
<filename>/compat/linux/usr/X11/lib/libX11.so</filename>, etc.)
|
||||
in order for the emulator to find them.</para>
|
||||
|
||||
<para>Those running FreeBSD 2.2-RELEASE should run the Linux
|
||||
ldconfig program.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root <userinput>cd /compat/linux/lib</userinput>
|
||||
&prompt.root; <userinput>/compat/linux/sbin/ldconfig</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><command>ldconfig</command> is statically linked, so it does not need any
|
||||
shared libraries to run. It creates the file
|
||||
<filename>/compat/linux/etc/ld.so.cache</filename> which
|
||||
contains the names of all the shared libraries and should be
|
||||
rerun to recreate this file whenever you install additional
|
||||
shared libraries.</para>
|
||||
|
||||
<para>On 2.1-STABLE do not install
|
||||
<filename>/compat/linux/etc/ld.so.cache</filename> or run
|
||||
<command>ldconfig</command>; in 2.1-STABLE the syscalls are implemented differently
|
||||
and <command>ldconfig</command> is not needed or used.</para>
|
||||
|
||||
<para>You should now be set up for Linux binaries which only need
|
||||
a shared libc. You can test this by running the Linux <command>ldd</command> on
|
||||
itself. Supposing that you have it installed as <command>ldd-linux</command>, it
|
||||
should produce something like:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>ldd-linux `which ldd-linux`</userinput>
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This being done, you are ready to install new Linux
|
||||
binaries. Whenever you install a new Linux program, you should
|
||||
check if it needs shared libraries, and if so, whether you have
|
||||
them installed in the <filename>/compat/linux</filename> tree.
|
||||
To do this, you run the Linux version <command>ldd</command> on the new program,
|
||||
and watch its output. <command>ldd</command> (see also the manual page for <citerefentry><refentrytitle>ldd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
|
||||
will print a list of shared libraries that the program depends
|
||||
on, in the form <literal><replaceable>majorname</replaceable> (<replaceable>jumpversion</replaceable>) => <replaceable>fullname</replaceable></literal>.</para>
|
||||
|
||||
<para>If it prints <literal>not found</literal> instead of <replaceable>fullname</replaceable> it means that
|
||||
you need an extra library. The library needed is shown in
|
||||
majorname and will be of the form <literal>lib<replaceable>XXXX</replaceable>.so.<replaceable>N</replaceable></literal>. You will need to
|
||||
find a <filename>lib<replaceable>XXXX</replaceable>.so.N.mm</filename> on a Linux ftp site, and install it on
|
||||
your system. The <replaceable>XXXX</replaceable> (name) and <replaceable>N</replaceable> (major revision number)
|
||||
should match; the minor number(s) <replaceable>mm</replaceable> are less important, though
|
||||
it is advised to take the most recent version.</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring the host name resolver</title>
|
||||
|
||||
<para>If DNS does not work or you get the messages
|
||||
|
||||
<informalexample>
|
||||
<screen>resolv+: "bind" is an invalid keyword resolv+:
|
||||
"hosts" is an invalid keyword</screen>
|
||||
</informalexample>
|
||||
|
||||
then you need to configure a
|
||||
<filename>/compat/linux/etc/host.conf</filename> file containing:
|
||||
|
||||
<programlisting>
|
||||
order hosts, bind
|
||||
multi on</programlisting>
|
||||
|
||||
where the order here specifies that
|
||||
<filename>/etc/hosts</filename> is searched first and DNS is
|
||||
searched second. When
|
||||
<filename>/compat/linux/etc/host.conf</filename> is not installed
|
||||
linux applications find FreeBSD's
|
||||
<filename>/etc/host.conf</filename> and complain about the
|
||||
incompatible FreeBSD syntax. You should remove <literal>bind</literal> if you
|
||||
have not configured a name-server using the
|
||||
<filename>/etc/resolv.conf</filename> file.</para>
|
||||
|
||||
<para>Lastly, those who run 2.1-STABLE need to set an the
|
||||
<envar>RESOLV_HOST_CONF</envar> environment variable so that applications will
|
||||
know how to search the host tables. If you run FreeBSD
|
||||
2.2-RELEASE, you can skip this. For the
|
||||
<filename>/bin/csh</filename> shell use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>For <filename>/bin/sh</filename> use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Finding the necessary files</title>
|
||||
|
||||
<note>
|
||||
<para>The information below is valid as of the time this document
|
||||
was written, but certain details such as names of ftp sites,
|
||||
directories and distribution names may have changed by the time
|
||||
you read this.</para>
|
||||
</note>
|
||||
|
||||
<para>Linux is distributed by several groups that make their own set
|
||||
of binaries that they distribute. Each distribution has its own
|
||||
name, like “Slackware” or “Yggdrasil”. The distributions are
|
||||
available on a lot of ftp sites. Sometimes the files are unpacked,
|
||||
and you can get the individual files you need, but mostly they are
|
||||
stored in distribution sets, usually consisting of subdirectories
|
||||
with gzipped tar files in them. The primary ftp sites for the
|
||||
distributions are:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>sunsite.unc.edu:/pub/Linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>tsx-11.mit.edu:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>Some European mirrors:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>ftp.luth.se:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>ftp.demon.co.uk:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>src.doc.ic.ac.uk:/packages/linux/distributions</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
|
||||
<para>For simplicity, let us concentrate on Slackware here. This
|
||||
distribution consists of a number of subdirectories, containing
|
||||
separate packages. Normally, they are controlled by an install
|
||||
program, but you can retrieve files “by hand” too. First of all,
|
||||
you will need to look in the <filename>contents</filename> subdir of the
|
||||
distribution. You will find a lot of small text files here
|
||||
describing the contents of the separate packages. The fastest way
|
||||
to look something up is to retrieve all the files in the contents
|
||||
subdirectory, and grep through them for the file you need. Here is
|
||||
an example of a list of files that you might need, and in which
|
||||
contents-file you will find it by grepping through them:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Library</entry>
|
||||
<entry>Package</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row><entry><filename>ld.so</filename> </entry><entry>ldso
|
||||
</entry></row>
|
||||
<row><entry><filename>ldconfig</filename>
|
||||
</entry><entry>ldso </entry></row>
|
||||
<row><entry><filename>ldd</filename> </entry><entry>ldso
|
||||
</entry></row>
|
||||
<row><entry><filename>libc.so.4</filename>
|
||||
</entry><entry>shlibs </entry></row>
|
||||
<row><entry><filename>libX11.so.6.0</filename>
|
||||
</entry><entry>xf_lib
|
||||
</entry></row>
|
||||
<row><entry><filename>libXt.so.6.0</filename>
|
||||
</entry><entry>xf_lib
|
||||
</entry></row>
|
||||
<row><entry><filename>libX11.so.3</filename>
|
||||
</entry><entry>oldlibs
|
||||
</entry></row>
|
||||
<row><entry><filename>libXt.so.3</filename>
|
||||
</entry><entry>oldlibs
|
||||
</entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>So, in this case, you will need the packages ldso, shlibs,
|
||||
xf_lib and oldlibs. In each of the contents-files for these
|
||||
packages, look for a line saying <literal>PACKAGE LOCATION</literal>, it will
|
||||
tell you on which “disk” the package is, in our case it will tell
|
||||
us in which subdirectory we need to look. For our example, we
|
||||
would find the following locations:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<thead
|
||||
<row>
|
||||
<entry>Package</entry>
|
||||
<entry>Location</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row><entry>ldso </entry><entry>diska2 </entry></row>
|
||||
<row><entry>shlibs </entry><entry>diska2 </entry></row>
|
||||
<row><entry>oldlibs </entry><entry>diskx6 </entry></row>
|
||||
<row><entry>xf_lib </entry><entry>diskx9 </entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>The locations called “disk<replaceable>XX</replaceable>” refer to the <filename>slakware/<replaceable>XX</replaceable></filename>
|
||||
subdirectories of the distribution, others may be found in the
|
||||
<filename>contrib</filename> subdirectory. In this case, we
|
||||
could now retrieve the packages we need by retrieving the
|
||||
following files (relative to the root of the Slackware
|
||||
distribution tree):</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>slakware/a2/ldso.tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/a2/shlibs.tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/x6/oldlibs/tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/x9/xf_lib.tgz</filename></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>Extract the files from these gzipped tarfiles in your
|
||||
<filename>/compat/linux</filename> directory (possibly omitting or
|
||||
afterwards removing files you do not need), and you are
|
||||
done.</para>
|
||||
|
||||
<para><emphasis>See also:</emphasis>
|
||||
<filename>ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README</filename> and <filename>/usr/src/sys/i386/ibcs2/README.iBCS2</filename></para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mathematica">
|
||||
<title>How to Install Mathematica on FreeBSD</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.rich; and
|
||||
&a.chuck;</emphasis></para>
|
||||
|
||||
<para>This document shows how to install the Linux binary distribution
|
||||
of Mathematica 2.2 on FreeBSD 2.1.</para>
|
||||
|
||||
<para>Mathematica supports Linux but not FreeBSD as it stands. So
|
||||
once you have configured your system for Linux compatibility you
|
||||
have most of what you need to run Mathematica.</para>
|
||||
|
||||
<para>For those who already have the student edition of Mathematica
|
||||
for DOS the cost of upgrading to the Linux version at the time this
|
||||
was written, March 1996, was $45.00. It can be ordered directly
|
||||
from Wolfram at (217) 398-6500 and paid for by credit card.</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Unpacking the Mathematica distribution</title>
|
||||
|
||||
<para>The binaries are currently distributed by Wolfram on CDROM.
|
||||
The CDROM has about a dozen tar files, each of which is a binary
|
||||
distribution for one of the supported architectures. The one for
|
||||
Linux is named <filename>LINUX.TAR</filename>. You can, for
|
||||
example, unpack this into
|
||||
<filename>/usr/local/Mathematica</filename>:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local</userinput>
|
||||
&prompt.root; <userinput>mkdir Mathematica</userinput>
|
||||
&prompt.root; <userinput>cd Mathematica</userinput>
|
||||
&prompt.root; <userinput>tar -xvf /cdrom/LINUX.TAR</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Obtaining your Mathematica Password</title>
|
||||
|
||||
<para>Before you can run Mathematica you will have to obtain a
|
||||
password from Wolfram that corresponds to your “machine
|
||||
ID”.</para>
|
||||
|
||||
<para>Once you have installed the linux compatibility runtime
|
||||
libraries and unpacked the mathematica you can obtain the “machine
|
||||
ID” by running the program <command>mathinfo</command> in the Install directory.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local/Mathematica/Install</userinput>
|
||||
&prompt.root; <userinput>mathinfo</userinput>
|
||||
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
|
||||
richc.isdn.bcm.tmc.edu 9845-03452-90255</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>So, for example, the “machine ID” of <hostid>richc</hostid> is
|
||||
<literal>9845-03452-90255</literal>. You can ignore the message about the ioctl
|
||||
that is not implemented. It will not prevent Mathematica from
|
||||
running in any way and you can safely ignore it, though you will
|
||||
see the message every time you run Mathematica.</para>
|
||||
|
||||
<para>When you register with Wolfram, either by email, phone or fax,
|
||||
you will give them the “machine ID” and they will respond with a
|
||||
corresponding password consisting of groups of numbers. You need
|
||||
to add them both along with the machine name and license number in
|
||||
your mathpass file.</para>
|
||||
|
||||
<para>You can do this by invoking:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local/Mathematica/Install</userinput>
|
||||
&prompt.root; <userinput>math.install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>It will ask you to enter your license number
|
||||
and the Wolfram supplied password. If you get them mixed up or
|
||||
for some reason the math.install fails, that is OK; you can simply
|
||||
edit the file <filename>mathpass</filename> in this same directory to correct the
|
||||
info manually.</para>
|
||||
|
||||
<para>After getting past the password, math.install will ask you if
|
||||
you accept the install defaults provided, or if you want to use
|
||||
your own. If you are like us and distrust all install programs,
|
||||
you probably want to specify the actual directories. Beware.
|
||||
Although the math.install program asks you to specify directories,
|
||||
it will not create them for you, so you should perhaps have a
|
||||
second window open with another shell so that you can create them
|
||||
before you give them to the install program. Or, if it fails, you
|
||||
can create the directories and then restart the <command>math.install</command>
|
||||
program. The directories we chose to create beforehand and
|
||||
specify to <command>math.install</command> were:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>/usr/local/Mathematica/bin</filename></entry>
|
||||
<entry>for binaries</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>/usr/local/Mathematica/man/man1</filename></entry>
|
||||
<entry>for man pages</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>/usr/local/Mathematica/lib/X11</entry>
|
||||
<entry>for the XKeysymb file</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>You can also tell it to use
|
||||
<filename>/tmp/math.record</filename> for the system record file,
|
||||
where it puts logs of sessions. After this <command>math.install</command> will
|
||||
continue on to unpacking things and placing everything where it
|
||||
should go.</para>
|
||||
|
||||
<para>The Mathematica Notebook feature is included separately, as
|
||||
the X Front End, and you have to install it separately. To get the
|
||||
X Front End stuff correctly installed, cd into the
|
||||
<filename>/usr/local/Mathematica/FrontEnd</filename> directory and
|
||||
execute the <command>xfe.install</command> shell script. You will have to tell it
|
||||
where to put things, but you do not have to create any directories
|
||||
because it will use the same directories that had been created for
|
||||
math.install. When it finishes, there should be a new shell script
|
||||
in <filename>/usr/local/Mathematica/bin</filename> called
|
||||
<filename>mathematica</filename>.</para>
|
||||
|
||||
<para>Lastly, you need to modify each of the shell scripts that
|
||||
Mathematica has installed. At the beginning of every shell script
|
||||
in <filename>/usr/local/Mathematica/bin</filename> add the
|
||||
following line:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This tells Mathematica were to find its own
|
||||
version of the key mapping file <filename>XKeysymDB</filename>.
|
||||
Without this you will get pages of error messages about missing
|
||||
key mappings.</para>
|
||||
|
||||
<para>On 2.1-STABLE you need to add the following as well:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This tells Mathematica to use the linux version
|
||||
of host.conf. This file has a different syntax from FreeBSD's
|
||||
host.conf, so you will get an error message about
|
||||
<filename>/etc/host.conf</filename> if you leave this out.</para>
|
||||
|
||||
<para>You might also want to modify your
|
||||
<filename>/etc/manpath.config</filename> file to read the new man
|
||||
directory, and you may need to edit your
|
||||
<filename>~/.cshrc</filename> file to add
|
||||
<filename>/usr/local/Mathematica/bin</filename> to your
|
||||
path.</para>
|
||||
|
||||
<para>That is about all it takes. With this you should be able to
|
||||
type <command>mathematica</command> and get a really slick looking Mathematica
|
||||
Notebook screen up. Mathematica has included the Motif user
|
||||
interfaces, but it is compiled in statically, so you do not need
|
||||
the Motif libraries. Good luck doing this yourself!</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Bugs</title>
|
||||
|
||||
<para>The Notebook front end is known to hang sometimes when reading
|
||||
notebook files with an error messages similar to:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><errorname>File .../Untitled-1.mb appears to be broken for OMPR.257.0</errorname></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>We have not found the cause for this, but it only affects the
|
||||
Notebook's X Window front end, not the mathematica engine itself.
|
||||
So the command line interface invoked by 'math' is unaffected by
|
||||
this bug.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Acknowledgments</title>
|
||||
|
||||
<para>A well-deserved thanks should go to &a.sos; and &a.peter; who
|
||||
made linux emulation what it is today, and Michael Smith who drove
|
||||
these two guys like dogs to get it to the point where it runs
|
||||
Linux binaries better than linux! <!-- smiley -->:-)</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
581
en/handbook/mail/chapter.sgml
Normal file
581
en/handbook/mail/chapter.sgml
Normal file
|
|
@ -0,0 +1,581 @@
|
|||
<chapter id="mail">
|
||||
<title>Electronic Mail</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.wlloyd;.</emphasis></para>
|
||||
|
||||
<para>Electronic Mail configuration is the subject of many <xref
|
||||
linkend="bibliography" remap="System Administration"> books. If you
|
||||
plan on doing anything beyond setting up one mailhost for your
|
||||
network, you need industrial strength help.</para>
|
||||
|
||||
<para>Some parts of E-Mail configuration are controlled in the Domain
|
||||
Name System (DNS). If you are going to run your own own DNS server
|
||||
check out <filename>/etc/namedb</filename> and <command>man -k named</command> for more information.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Basic Information</title>
|
||||
|
||||
<para>These are the major programs involved in an E-Mail exchange. A
|
||||
“mailhost” is a server that is
|
||||
responsible for delivering and receiving all email for your host,
|
||||
and possibly your network.</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>User program</title>
|
||||
|
||||
<para>This is a program like <application >elm</application>, <application>pine</application>,
|
||||
<application>mail</application>, or something more sophisticated like a WWW
|
||||
browser. This program will simply pass off all e-mail
|
||||
transactions to the local “mailhost” ,
|
||||
either by calling <command>sendmail</command> or
|
||||
delivering it over TCP.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Mailhost Server Daemon</title>
|
||||
|
||||
<para>Usually this program is <command>sendmail</command> or
|
||||
<command>smail</command> running in the background. Turn it off or
|
||||
change the command line options in
|
||||
<filename>/etc/rc.conf</filename> (or, prior to FreeBSD 2.2.2,
|
||||
<filename>/etc/sysconfig</filename>). It is best to leave it on,
|
||||
unless you have a specific reason to want it off. Example: You
|
||||
are building a <xref
|
||||
linkend="firewalls" remap="Firewall">.</para>
|
||||
|
||||
<para>You should be aware that <command>sendmail</command> is a potential weak link in a
|
||||
secure site. Some versions of <command>sendmail</command> have known security
|
||||
problems.</para>
|
||||
|
||||
<para><command>sendmail</command> does two jobs. It looks after delivering
|
||||
and receiving mail.</para>
|
||||
|
||||
<para>If <command>sendmail</command>
|
||||
needs to deliver mail off your site it will look up in
|
||||
the DNS to determine the actual host that will receive mail for
|
||||
the destination.</para>
|
||||
|
||||
<para>If it is acting as a delivery agent <command>sendmail</command> will take the message from the
|
||||
local queue and deliver it across the Internet to another sendmail
|
||||
on the receivers computer.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>DNS — Name Service</title>
|
||||
|
||||
<para>The Domain Name System and its daemon <command>named</command>, contain the database mapping
|
||||
hostname to IP address, and hostname to mailhost. The IP address
|
||||
is specified in an A record. The MX record specifies the
|
||||
mailhost that will receive mail for you. If you do not have a
|
||||
MX record mail for your hostname, the mail will be delivered to
|
||||
your host directly.</para>
|
||||
|
||||
<para>Unless you are running your own DNS server, you will not be
|
||||
able to change any information in the DNS yourself. If you are
|
||||
using an Internet Provider, speak to them.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>POP Servers</title>
|
||||
|
||||
<para>This program gets the mail from your mailbox and gives it to
|
||||
your browser. If you want to run a POP server on your computer,
|
||||
you will need to do 2 things.</para>
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Get pop software from the <ulink
|
||||
URL="../ports/mail.html">Ports collection</ulink> that
|
||||
can be found in <filename>/usr/ports</filename> or packages
|
||||
collection. This handbook section has a complete reference
|
||||
on the <xref linkend="ports"
|
||||
remap="Ports"> system.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Modify <filename>/etc/inetd.conf</filename>
|
||||
to load the POP server.</para>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
<para>The pop program will have instructions with it. Read
|
||||
them.</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Configuration</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Basic</title>
|
||||
|
||||
<para>As your FreeBSD system comes “out of the box”[TM], you should
|
||||
be able to send E-mail to external hosts as long as you have
|
||||
<filename>/etc/resolv.conf</filename> setup or are running a name
|
||||
server. If you want to have mail for your host delivered to your
|
||||
specific host,there are two methods:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Run a name server (<command>man -k named</command>) and have your own domain
|
||||
<hostid role="domainname">smallminingco.com </hostid></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Get mail delivered to the current DNS name for your host.
|
||||
Ie: <hostid role="fqdn">dorm6.ahouse.school.edu </hostid></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>No matter what option you choose, to have mail delivered
|
||||
directly to your host, you must be a full Internet host. You must
|
||||
have a permanent IP address. IE: NO dynamic PPP. If you are
|
||||
behind a firewall, the firewall must be passing on smtp traffic to
|
||||
you. From <filename>/etc/services</filename>:</para>
|
||||
|
||||
<programlisting
|
||||
>smtp 25/tcp mail #Simple Mail Transfer</programlisting>
|
||||
|
||||
<para>If you
|
||||
want to receive mail at your host itself, you must make sure that
|
||||
the DNS MX entry points to your host address, or there is no MX
|
||||
entry for your DNS name.</para>
|
||||
|
||||
<para>Try this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>hostname</userinput>
|
||||
newbsdbox.freebsd.org
|
||||
&prompt.root; <userinput>host newbsdbox.freebsd.org</userinput>
|
||||
newbsdbox.freebsd.org has address 204.216.27.xx</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If that is all that comes out for your machine, mail directory
|
||||
to <email>root@newbsdbox.freebsd.org</email>
|
||||
will work no problems.</para>
|
||||
|
||||
<para>If instead, you have this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>host newbsdbox.freebsd.org</userinput>
|
||||
newbsdbox.FreeBSD.org has address 204.216.27.xx
|
||||
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.org</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>All mail sent to your host
|
||||
directly will end up on <hostid>freefall</hostid>, under the same username.</para>
|
||||
|
||||
<para>This information is setup in your domain name server. This
|
||||
should be the same host that is listed as your primary nameserver
|
||||
in <filename>/etc/resolv.conf</filename></para>
|
||||
|
||||
<para>The DNS record that carries mail routing information is the
|
||||
Mail eXchange entry. If no MX entry exists, mail will be
|
||||
delivered directly to the host by way of the Address
|
||||
record.</para>
|
||||
|
||||
<para>The MX entry for <hostid role="fqdn">freefall.freebsd.org</hostid> at one time.</para>
|
||||
|
||||
<programlisting>
|
||||
freefall MX 30 mail.crl.net
|
||||
freefall MX 40 agora.rdrop.com
|
||||
freefall HINFO Pentium FreeBSD
|
||||
freefall MX 10 freefall.FreeBSD.org
|
||||
freefall MX 20 who.cdrom.com
|
||||
freefall A 204.216.27.xx
|
||||
freefall CNAME www.FreeBSD.org</programlisting>
|
||||
|
||||
<para><hostid>freefall</hostid> has many MX entries. The lowest MX number gets the
|
||||
mail in the end. The others will queue mail temporarily, if
|
||||
<hostid>freefall</hostid> is busy or down.</para>
|
||||
|
||||
<para>Alternate MX sites should have separate connections to the
|
||||
Internet, to be most useful. An Internet Provider or other
|
||||
friendly site can provide this service.</para>
|
||||
|
||||
<para><command>dig</command>, <command>nslookup</command>,
|
||||
and <command>host</command> are your friends.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="mail-domain">
|
||||
<title>Mail for your Domain (Network).</title>
|
||||
|
||||
<para>To setup up a network mailhost, you need to direct the mail
|
||||
from arriving at all the workstations. In other words, you want to
|
||||
hijack all mail for <hostid role="domainname">*.smallminingco.com
|
||||
</hostid> and divert it to one machine, your “mailhost”.</para>
|
||||
|
||||
<para>The network users on their workstations will most likely pick
|
||||
up their mail over POP or telnet.</para>
|
||||
|
||||
<para>A user account with the <emphasis>same username</emphasis> should exist on both
|
||||
machines. Please use <command>adduser</command> to do
|
||||
this as required. If you set the <literal>shell</literal> to
|
||||
<literal>/nonexistent</literal>
|
||||
the user will not be allowed to login.</para>
|
||||
|
||||
<para>The mailhost that you will be using must be designated the
|
||||
Mail eXchange for each workstation. This must be arranged in DNS
|
||||
(ie BIND, named). Please refer to a Networking book for in-depth
|
||||
information.</para>
|
||||
|
||||
<para>You basically need to add these lines in your DNS server.</para>
|
||||
|
||||
<programlisting>
|
||||
pc24.smallminingco.com A <replaceable>xxx.xxx.xxx.xxx</replaceable> ; Workstation ip
|
||||
MX 10 smtp.smallminingco.com ; Your mailhost</programlisting>
|
||||
|
||||
<para>You cannot do this yourself unless you are running a DNS
|
||||
server. If you do not want to run a DNS server, get somebody else
|
||||
like your Internet Provider to do it.</para>
|
||||
|
||||
<para>This will redirect mail for the workstation to the Mail
|
||||
eXchange host. It does not matter what machine the A record
|
||||
points to, the mail will be sent to the MX host.</para>
|
||||
|
||||
<para>This feature is used to implement Virtual E-Mail Hosting.</para>
|
||||
|
||||
<para>Example</para>
|
||||
|
||||
<para>I have a customer with domain foo.bar and I want all mail for
|
||||
foo.bar to be sent to my machine smtp.smalliap.com. You must make
|
||||
an entry in your DNS server like:</para>
|
||||
|
||||
<programlisting>
|
||||
foo.bar MX 10 smtp.smalliap.com ; your mailhost</programlisting>
|
||||
|
||||
<para>The A record is not needed if you only
|
||||
want E-Mail for the domain. IE: Don't expect <command>ping foo.bar</command>
|
||||
to work unless an Address record for <filename>foo.bar</filename>
|
||||
exists as well.</para>
|
||||
|
||||
<para>On the mailhost that actually accepts mail for final delivery
|
||||
to a mailbox, <command>sendmail</command> must be told what hosts it will be
|
||||
accepting mail for.</para>
|
||||
|
||||
<para>Add <literal>pc24.smallminingco.com</literal> to <filename>/etc/sendmail.cw</filename> (if you are
|
||||
using <literal>FEATURE(use_cw_file)</literal>), or add a <literal>Cw myhost.smalliap.com</literal>
|
||||
line to <filename>/etc/sendmail.cf</filename></para>
|
||||
|
||||
<para>If you plan on doing anything serious with <command>sendmail</command> you should install the <command>sendmail</command>
|
||||
source. The source has plenty of documentation with it. You will
|
||||
find information on getting <command>sendmail</command>
|
||||
source from <xref linkend="sendmailuucp" remap="the UUCP
|
||||
information">.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sendmailuucp">
|
||||
<title>Setting up UUCP.</title>
|
||||
|
||||
<para><emphasis>Stolen from the FAQ.</emphasis></para>
|
||||
|
||||
<para>The sendmail configuration that ships with FreeBSD is suited
|
||||
for sites that connect directly to the Internet. Sites that wish
|
||||
to exchange their mail via UUCP must install another <command>sendmail</command>
|
||||
configuration file.</para>
|
||||
|
||||
<para>Tweaking <filename>/etc/sendmail.cf</filename> manually is
|
||||
considered something for purists. Sendmail version 8 comes with a
|
||||
new approach of generating config files via some <command>m4</command> preprocessing, where the actual
|
||||
hand-crafted configuration is on a higher abstraction level. You
|
||||
should use the configuration files under
|
||||
<filename>/usr/src/usr.sbin/sendmail/cf</filename>.</para>
|
||||
|
||||
<para>If you did not install your system with full sources, the
|
||||
<command>sendmail</command> config stuff has been broken out into a separate source
|
||||
distribution tarball just for you. Assuming you have your CD-ROM
|
||||
mounted, do:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
|
||||
&prompt.root; <userinput>tar -xvzf /cdrom/dists/src/ssmailcf.aa</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Do not panic, this is only a few hundred kilobytes in size.
|
||||
The file <filename>README</filename> in the <filename>cf</filename> directory can serve as a basic
|
||||
introduction to m4 configuration.</para>
|
||||
|
||||
<para>For UUCP delivery, you are best advised to use the
|
||||
<emphasis>mailertable</emphasis> feature. This constitutes a
|
||||
database that <command>sendmail</command> can use to base its routing decision
|
||||
upon.</para>
|
||||
|
||||
<para>First, you have to create your <filename>.mc</filename> file.
|
||||
The directory
|
||||
<filename>/usr/src/usr.sbin/sendmail/cf/cf</filename> is the home
|
||||
of these files. Look around, there are already a few examples.
|
||||
Assuming you have named your file <filename>foo.mc</filename>, all
|
||||
you need to do in order to convert it into a valid
|
||||
<filename>sendmail.cf</filename> is:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/sendmail/cf/cf</userinput>
|
||||
&prompt.root; <userinput>make foo.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If you don't have a <filename>/usr/obj</filename> hiearchy,
|
||||
then:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cp foo.cf /etc/sendmail.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Otherwise:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>A typical <filename>.mc</filename> file might look
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
include(`../m4/cf.m4')
|
||||
VERSIONID(`<replaceable>Your version number</replaceable>')
|
||||
OSTYPE(bsd4.4)
|
||||
|
||||
FEATURE(nodns)
|
||||
FEATURE(nocanonify)
|
||||
FEATURE(mailertable)
|
||||
|
||||
define(`UUCP_RELAY', <replaceable>your.uucp.relay</replaceable>)
|
||||
define(`UUCP_MAX_SIZE', 200000)
|
||||
|
||||
MAILER(local)
|
||||
MAILER(smtp)
|
||||
MAILER(uucp)
|
||||
|
||||
Cw <replaceable>your.alias.host.name</replaceable>
|
||||
Cw <replaceable>youruucpnodename.UUCP</replaceable></programlisting>
|
||||
|
||||
<para>The <literal>nodns</literal> and
|
||||
<literal>nocanonify</literal> features will prevent any usage of
|
||||
the DNS during mail delivery. The <literal>UUCP_RELAY</literal>
|
||||
clause is needed for bizarre reasons, do not ask. Simply put an
|
||||
Internet hostname there that is able to handle .UUCP pseudo-domain
|
||||
addresses; most likely, you will enter the mail relay of your ISP
|
||||
there.</para>
|
||||
|
||||
<para>Once you have this, you need this file called
|
||||
<filename>/etc/mailertable</filename>. A typical example of this
|
||||
gender again:</para>
|
||||
|
||||
<programlisting>
|
||||
#
|
||||
# makemap hash /etc/mailertable.db < /etc/mailertable
|
||||
#
|
||||
horus.interface-business.de uucp-dom:horus
|
||||
.interface-business.de uucp-dom:if-bus
|
||||
interface-business.de uucp-dom:if-bus
|
||||
.heep.sax.de smtp8:%1 horus.UUCP
|
||||
uucp-dom:horus if-bus.UUCP
|
||||
uucp-dom:if-bus . uucp-dom:sax</programlisting>
|
||||
|
||||
<para>As you can see, this is part of a real-life file. The first
|
||||
three lines handle special cases where domain-addressed mail
|
||||
should not be sent out to the default route, but instead to some
|
||||
UUCP neighbor in order to “shortcut” the delivery path. The
|
||||
next line handles mail to the local Ethernet domain that can be
|
||||
delivered using SMTP. Finally, the UUCP neighbors are mentioned
|
||||
in the .UUCP pseudo-domain notation, to allow for a
|
||||
<literal>uucp-neighbor!recipient</literal> override of the default rules. The
|
||||
last line is always a single dot, matching everything else, with
|
||||
UUCP delivery to a UUCP neighbor that serves as your universal
|
||||
mail gateway to the world. All of the node names behind the
|
||||
<literal>uucp-dom:</literal> keyword must be valid UUCP
|
||||
neighbors, as you can verify using the command <command>uuname</command>.</para>
|
||||
|
||||
<para>As a reminder that this file needs to be converted into a DBM
|
||||
database file before being usable, the command line to accomplish
|
||||
this is best placed as a comment at the top of the <filename>mailertable</filename>.
|
||||
You always have to execute this command each time you change your
|
||||
<filename>mailertable</filename>.</para>
|
||||
|
||||
<para>Final hint: if you are uncertain whether some particular mail
|
||||
routing would work, remember the <option>-bt</option> option to
|
||||
<command>sendmail</command>. It starts <command>sendmail</command>
|
||||
in “address test
|
||||
mode”; simply enter <literal>0</literal>, followed by the address
|
||||
you wish to test for the mail routing. The last line tells you
|
||||
the used internal mail agent, the destination host this agent will
|
||||
be called with, and the (possibly translated) address. Leave this
|
||||
mode by typing Control-D.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>sendmail -bt</userinput>
|
||||
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
|
||||
Enter <ruleset> <address>
|
||||
<prompt>></prompt> <userinput>0 foo@interface-business.de</userinput>
|
||||
rewrite: ruleset 0 input: foo @ interface-business . de
|
||||
…
|
||||
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ interface-business . de</screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mailfaq">
|
||||
<title>FAQ</title>
|
||||
|
||||
<para><emphasis>Migration from FAQ.</emphasis></para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Why do I have to use the FQDN for hosts on my site?</title>
|
||||
|
||||
<para>You will probably find that the host is actually in a
|
||||
different domain; for example, if you are in <hostid role="fqdn">foo.bar.edu</hostid> and you
|
||||
wish to reach a host called <hostid>mumble</hostid> in the <hostid
|
||||
role="domainname">bar.edu</hostid> domain, you
|
||||
will have to refer to it by the fully-qualified domain name,
|
||||
<hostid role="fqdn">mumble.bar.edu</hostid>, instead of just <hostid>mumble</hostid>.</para>
|
||||
|
||||
<para>Traditionally, this was allowed by BSD BIND resolvers. However
|
||||
the current version of <application>BIND</application> that ships with
|
||||
FreeBSD no longer provides default abbreviations for non-fully
|
||||
qualified domain names other than the domain you are in. So an
|
||||
unqualified host <hostid>mumble</hostid> must either
|
||||
be found as <hostid role="fqdn">mumble.foo.bar.edu</hostid>, or
|
||||
it will be searched for in the root domain.</para>
|
||||
|
||||
<para>This is different from the previous behavior, where the search
|
||||
continued across <hostid role="domainname">mumble.bar.edu</hostid>,
|
||||
and <hostid role="domainname">mumble.edu</hostid>. Have a look at
|
||||
RFC 1535 for why this was considered bad practice, or even a
|
||||
security hole.</para>
|
||||
|
||||
<para>As a good workaround, you can place the line
|
||||
|
||||
<programlisting>
|
||||
search foo.bar.edu bar.edu</programlisting>
|
||||
|
||||
instead of the previous
|
||||
|
||||
<programlisting>
|
||||
domain foo.bar.edu</programlisting>
|
||||
|
||||
into your <filename>/etc/resolv.conf</filename>. However,
|
||||
make sure that the search order does not go beyond the “boundary
|
||||
between local and public administration”, as RFC 1535 calls
|
||||
it.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Sendmail says <errorname>mail loops back to myself</errorname></title>
|
||||
|
||||
<para>This is answered in the sendmail FAQ as follows:</para>
|
||||
|
||||
<programlisting>
|
||||
* I am getting "Local configuration error" messages, such as:
|
||||
|
||||
553 relay.domain.net config error: mail loops back to myself
|
||||
554 <user@domain.net>... Local configuration error
|
||||
|
||||
How can I solve this problem?
|
||||
|
||||
You have asked mail to the domain (e.g., domain.net) to be
|
||||
forwarded to a specific host (in this case, relay.domain.net)
|
||||
by using an MX record, but the relay machine does not recognize
|
||||
itself as domain.net. Add domain.net to /etc/sendmail.cw
|
||||
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
|
||||
to /etc/sendmail.cf.</programlisting>
|
||||
|
||||
<para>The sendmail FAQ is in
|
||||
<filename>/usr/src/usr.sbin/sendmail</filename> and is recommended
|
||||
reading if you want to do any “tweaking” of your mail
|
||||
setup.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>How can I do E-Mail with a dialup PPP host?</title>
|
||||
|
||||
<para>You want to connect a FreeBSD box on a lan, to the Internet.
|
||||
The FreeBSD box will be a mail gateway for the lan. The PPP
|
||||
connection is non-dedicated.</para>
|
||||
|
||||
<para>There are at least two way to do this.</para>
|
||||
|
||||
<para>The other is to use UUCP.</para>
|
||||
|
||||
<para>The key is to get a Internet site to provide secondary MX
|
||||
services for your domain. For example:</para>
|
||||
|
||||
<programlisting>
|
||||
bigco.com. MX 10 bigco.com.
|
||||
MX 20 smalliap.com.</programlisting>
|
||||
|
||||
<para>Only one host should be specified as the final recipient ( add
|
||||
<literal>Cw bigco.com</literal> in <filename>/etc/sendmail.cf</filename> on
|
||||
bigco.com).</para>
|
||||
|
||||
<para>When the senders <command>sendmail</command> is trying to deliver the mail it
|
||||
will try to connect to you over the modem link. It will most
|
||||
likely time out because you are not online. <command>sendmail</command> will
|
||||
automatically deliver it to the secondary MX site, ie your
|
||||
Internet provider. The secondary MX site will try every
|
||||
(<literal>sendmail_flags = "-bd -q15m"</literal> in
|
||||
<filename>/etc/rc.conf</filename> ) 15 minutes to connect to your
|
||||
host to deliver the mail to the primary MX site.</para>
|
||||
|
||||
<para>You might wat to use something like this as a login script.</para>
|
||||
|
||||
<programlisting>
|
||||
#!/bin/sh
|
||||
# Put me in /usr/local/bin/pppbigco
|
||||
( sleep 60 ; /usr/sbin/sendmail -q ) &
|
||||
/usr/sbin/ppp -direct pppbigco</programlisting>
|
||||
|
||||
<para>If you are going to create a separate
|
||||
login script for a user you could use <command>sendmail
|
||||
-qRbigco.com</command> instead in the script above. This will
|
||||
force all mail in your queue for bigco.com to be processed
|
||||
immediately.</para>
|
||||
|
||||
<para>A further refinement of the situation is as follows.</para>
|
||||
|
||||
<para>Message stolen from the freebsd-isp mailing list.</para>
|
||||
|
||||
<programlisting>
|
||||
> we provide the secondary mx for a customer. The customer connects to
|
||||
> our services several times a day automatically to get the mails to
|
||||
> his primary mx (We do not call his site when a mail for his domains
|
||||
> arrived). Our sendmail sends the mailqueue every 30 minutes. At the
|
||||
> moment he has to stay 30 minutes online to be sure that all mail is
|
||||
> gone to the primary mx.
|
||||
>
|
||||
> Is there a command that would initiate sendmail to send all the mails
|
||||
> now? The user has not root-privileges on our machine of course.
|
||||
|
||||
In the 'privacy flags' section of sendmail.cf, there is a definition
|
||||
Opgoaway,restrictqrun
|
||||
|
||||
Remove restrictqrun to allow non-root users to start the queue processing.
|
||||
You might also like to rearrange the MXs. We are the 1st MX for our
|
||||
customers like this, and we have defined:
|
||||
|
||||
# If we are the best MX for a host, try directly instead of generating
|
||||
# local config error.
|
||||
OwTrue
|
||||
|
||||
That way a remote site will deliver straight to you, without trying
|
||||
the customer connection. You then send to your customer. Only works for
|
||||
"hosts", so you need to get your customer to name their mail machine
|
||||
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
|
||||
an A record in the DNS for "customer.com".</programlisting>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
1257
en/handbook/mirrors/chapter.sgml
Normal file
1257
en/handbook/mirrors/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
480
en/handbook/pgpkeys/chapter.sgml
Normal file
480
en/handbook/pgpkeys/chapter.sgml
Normal file
|
|
@ -0,0 +1,480 @@
|
|||
<chapter id="pgpkeys">
|
||||
<title>PGP keys</title>
|
||||
|
||||
<para>In case you need to verify a signature or send encrypted email to
|
||||
one of the officers or core team members a number of keys are
|
||||
provided here for your convenience.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Officers</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>FreeBSD Security Officer <email>security-officer@freebsd.org</email></title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.imp;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Core Team members</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>&a.asami;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jmb;</title>
|
||||
|
||||
<programlisting>
|
||||
Jonathan M. Bresler <jmb@FreeBSD.org>
|
||||
Key fingerprint = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2
|
||||
|
||||
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
|
||||
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
|
||||
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
|
||||
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNA3x
|
||||
ffUVW/uOVC1dAQHGdAQAgsnYklBtVUdGuQwXB3bYp9omTD7CVD0aibVrz+lXiPDh
|
||||
aTVkOC1uhEwL59+R8VdpAnEDMobdZDA/ihCc+6/FW/eE0uyrWZzb5Ng9V1MfC6HI
|
||||
+sXpeXPy585Z56ewadV2yY9rvzcwmmUNHmAXT/5O0S2AWB0EJZ+cewTrokSTVVOJ
|
||||
AJUDBRA0C3EoVS4eLnPSiKUBASb+A/95g6w9DDPRGDlbsl4pN1BlSPKrmDQPRK1X
|
||||
C3bddDY2HNelSNhzp2FYD0WoN1re1vMJV0oaaJHwv7wjbe3+SYEX/IdmtfzI0MbZ
|
||||
Q/uPybPJOxi2ud6C6J+mEGJN9iBCnsaCz8CETuC9gR1mtxsxySUj9mk0fxKfdP6S
|
||||
3QDrv6CQ1IkAlQMFEDKsi9CzWmLrWZ8yPQEBduUD/RhV4Qa89rYls9vtIFm6XBjZ
|
||||
8mW37FYxeqIxg3ZrIyTMlghsOPV0f7zymCCWPRGKOLePRiGo0ZCEkDTYiM9tnwQI
|
||||
09rmPWJb50yfTSZXjHx6+Hcm6O6BCmDFloo0Mxo6n9pvMH/TmmqHxCsAV+p8XEWy
|
||||
rMZvwVSynMxmJd17Y5HLtBNKb25hdGhhbiBNLiBCcmVzbGVyiQCVAwUQMbYtYQHb
|
||||
XdKX5jjdAQHEHwP/fEaQoTi7zKD1U/5kW2YPIBUyMTpLiO9QOr4stYjJvhHh4Ejw
|
||||
fGvMIhbFrPKtxSNH1s3m4jAXKXiQBDCz17IIzL4n8dlunxNGE5MHcsmpWzggyIg4
|
||||
zbPqPOcg4gLFEWsEkr2o0akwzIGa3tbCvC+ITaX/rdlWV1jaQjTqSNyPZBM=
|
||||
=RV56
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.ache;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jkh;</title>
|
||||
|
||||
<programlisting>
|
||||
Jordan K. Hubbard <jkh@FreeBSD.org>
|
||||
Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2i
|
||||
|
||||
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
|
||||
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
|
||||
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
|
||||
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokAlQMFEDF75D1r
|
||||
WmeNgbKneQEBXtcD+gJIv8JzZRKlDZyTCQanK8iRgE+zMhxptI0kDObaGxT1BrpY
|
||||
4/EPyiUN10G4k2Jb+DOc8Lg2xDQ3xmvgipFf9NMNV/ThaEuZ3wA31I6tW/arQEqB
|
||||
Tp8u6T3v20m62t7Afo9HaoE6MBpHQUk2TilxgAd5P57sporL3pgW9YojIO9ziQCV
|
||||
AwUQMXyV2h9/qQgDWPy9AQEMfgP/RmbSg2WlesATUQ4WuanjcdREduKPyfQatrXD
|
||||
2xt+jg9X78dTyiNN1YvLqvT6msfs04MKSC0hA2mou6ozw8Xak+1QmP0fBOZKp9pP
|
||||
8szO188Do9ByzJPvHF1eXT7jFMOXVq8ZIl9iwjxcIDLzlxOz49DC7LO6AT+LKQk7
|
||||
UGeP+lqJAJUDBRAxe+UG9RVb+45ULV0BAXZ9A/9F9gLpGukVNkeOjaqxQdJGTS+a
|
||||
xh/Abk0c/nKhAEyxpAl5JyQ3ifYk6BHhPvlTi9LrZoXGA8sk/eU4eRTZVzvGEC4G
|
||||
+xsavlE/xzku8855QTLPpkCunUpQeu1wzaIrUUE6Zjh05imFbJYyQOBgTFpuqWsC
|
||||
rsUpl+2mr8IGIxG5rA==
|
||||
=LW9i
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.phk;</title>
|
||||
|
||||
<programlisting>
|
||||
Poul-Henning Kamp <phk@FreeBSD.org>
|
||||
Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.3ia
|
||||
|
||||
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI
|
||||
ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA
|
||||
K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR
|
||||
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDMGK9qz
|
||||
WmLrWZ8yPQEB4iED/18bQVhV2gUYFSxIUTaUtO2HVPi7GRpSzmXoTfS+FJyRR0ED
|
||||
zTqTHstoBe2PeWgTsOf9cUub5UKcJkRQp7VrJv4Kncyuq7pX69a+QMveCzuUwAur
|
||||
nDbt/emOL6NU8g9Uk50QuOuipb5rULQLRRoF5TkViy/VES83ERXdYQ9Ml3fWiQCV
|
||||
AwUQMX6NfWtaZ42Bsqd5AQEKsgP+L+uLz95dRdEmnZ+omrO+tYZM/0jHU7i8yC5q
|
||||
H0gguKOCljI4liR7NkqKONUJWYtfsTB81d9iSosBZRrTx6i/hB8l8kOB975n/f9S
|
||||
hftFwmjLYCNMFlDM4j0kySvMV20UZjAyv9BeE51VWlIZ5n/oeSuzul3Znow02tF/
|
||||
zVnInJiJAJUDBRAxfJXn9RVb+45ULV0BAXJ8A/9K6NT6VLZZC5q3g7bBk5DWuzBS
|
||||
3oK2Ebww6xzsD2R9edltoz1J3GPngK0CWpHh4kw5iTaRWoC2YJYRNG6icnGvlMAl
|
||||
1/urqQHJVhxATINm8oljDKsj1RBJ6VKBzNbCJIHTVpX0AJoqUQX2Idi8goFr0fAm
|
||||
7cD2CBb1JhoAdzEfO4kAlQMFEDFLHlwff6kIA1j8vQEBj5MD/1hA8hJdhpL7mvQj
|
||||
rTAIn6Ldr08Lr1lqTaKSBMdCL3suGlW0Sw/dIBgicPDhgxLahT3DVfGiIst32FSl
|
||||
xmWY7wine80X4TZkJ9Hiw3Mpqtjl92j6zHNq0ZZE+CceNubpEdYLDqokAIMPdWlo
|
||||
WPHZcPxCs5PKI5udseFYF2gQAjI2iQCVAwUQMTlDoO9huekR1Y7VAQGy+AP/Rzp+
|
||||
UGtJavbSiPx5EnXOXxkA/+ulXQgQG9vdkWwewkvxDNOzHW3KkUWCGtPtIMENznbF
|
||||
j3QlYB+USIaf1ogvlD5EdXGPDfTINpE8CX2WXzajfgYFpYETDzduwjoWDZfEN9zZ
|
||||
fQqQS62VgAReOIz3k9BL708z/+WUO0++RLGCmImJAJUDBRAw5q8kAPLZCeu7G0EB
|
||||
AT3bBACwo+r9TgbiSyyU5cZpq5KgGT1c7eUHXjtxKmtrXD1nFNJ6j7x2DM2XGe6B
|
||||
YOfDWbFq4UkEAyAeXviuuUP4enQu1v2g7JGXeuI8bRM519pLdPzDq/DnbA4rNStn
|
||||
/SkH7awMfNSplcFuE6rc5ezVkw17eOHzDrYmwsFavL9gxZEycg==
|
||||
=Q45T
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.rich;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jdp;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.guido;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.peter;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.joerg;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
283
en/handbook/policies/chapter.sgml
Normal file
283
en/handbook/policies/chapter.sgml
Normal file
|
|
@ -0,0 +1,283 @@
|
|||
<chapter id="policies">
|
||||
<title>Source Tree Guidelines and Policies</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.phk;.</emphasis></para>
|
||||
|
||||
<para>This chapter documents various guidelines and policies in force
|
||||
for the FreeBSD source tree.</para>
|
||||
|
||||
|
||||
<sect1 id="policies-maintainer">
|
||||
<title><makevar>MAINTAINER</makevar> on Makefiles</title>
|
||||
|
||||
<para>June 1996.</para>
|
||||
|
||||
<para>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
|
||||
|
||||
<programlisting>
|
||||
MAINTAINER= email-addresses</programlisting>
|
||||
|
||||
line to the <filename>Makefile</filename>s covering this portion
|
||||
of the source tree.</para>
|
||||
|
||||
<para>The semantics of this are as follows:</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Contributed Software</title>
|
||||
|
||||
<para>June 1996.</para>
|
||||
|
||||
<para>Some parts of the FreeBSD distribution consist of software that
|
||||
is actively being maintained outside the FreeBSD project. For
|
||||
historical reasons, we call this <emphasis>contributed</emphasis>
|
||||
software. Some examples are perl, gcc and patch.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The <application>Tcl</application> embedded programming
|
||||
language will be used as example of how this model works:</para>
|
||||
|
||||
<para><filename>src/contrib/tcl</filename> 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 <filename>mac</filename>, <filename>win</filename> and
|
||||
<filename>compat</filename> subdirectories were eliminated before
|
||||
the import</para>
|
||||
|
||||
<para><filename>src/lib/libtcl</filename> contains only a "bmake style"
|
||||
<filename>Makefile</filename> that uses the standard
|
||||
<filename>bsd.lib.mk</filename> makefile rules to produce the
|
||||
library and install the documentation.</para>
|
||||
|
||||
<para><filename>src/usr.bin/tclsh</filename> contains only a bmake style
|
||||
<filename>Makefile</filename> which will produce and install the
|
||||
<command>tclsh</command> program and its associated man-pages using the standard
|
||||
<filename>bsd.prog.mk</filename> rules.</para>
|
||||
|
||||
<para><filename>src/tools/tools/tcl_bmake</filename> 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.</para>
|
||||
|
||||
<para>The important thing here is that the
|
||||
<filename>src/contrib/tcl</filename> directory is created according
|
||||
to the rules: It is supposed to contain the sources as distributed
|
||||
(on a proper CVS vendor-branch) with as few FreeBSD-specific changes
|
||||
as possible. The 'easy-import' tool on freefall will assist in
|
||||
doing the import, but if there are any doubts on how to go about it,
|
||||
it is imperative that you ask first and not blunder ahead and hope
|
||||
it “works out”. CVS is not forgiving of import accidents and a fair
|
||||
amount of effort is required to back out major mistakes.</para>
|
||||
|
||||
<para>Because of some unfortunate design limitations with CVS's vendor
|
||||
branches, it is required that “official” patches from the vendor be
|
||||
applied to the original distributed sources and the result
|
||||
re-imported onto the vendor branch again. Official patches should
|
||||
never be patched into the FreeBSD checked out version and
|
||||
"committed", as this destroys the vendor branch coherency and makes
|
||||
importing future versions rather difficult as there will be
|
||||
conflicts.</para>
|
||||
|
||||
<para>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 <emphasis>not</emphasis> be
|
||||
removed.</para>
|
||||
|
||||
<para>If it seems easier, the <command>bmake</command> <filename>Makefile</filename>s
|
||||
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 <filename>src/tools</filename> directory along
|
||||
with the port itself so that it is available to future
|
||||
maintainers.</para>
|
||||
|
||||
<para>In the <filename>src/contrib/tcl</filename> level directory, a
|
||||
file called <filename>FREEBSD-upgrade</filename> should be added and
|
||||
it should states things like:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Which files have been left out</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Where the original distribution was obtained from and/or
|
||||
the official master site.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Where to send patches back to the original authors</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Perhaps an overview of the FreeBSD-specific changes that
|
||||
have been made.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>However, please do not import
|
||||
<filename>FREEBSD-upgrade</filename> with the contributed source.
|
||||
Rather you should <command>cvs add FREEBSD-upgrade ; cvs ci</command> after the
|
||||
initial import. Example wording from
|
||||
<filename>src/contrib/cpio</filename> is below:</para>
|
||||
|
||||
<programlisting>
|
||||
This directory contains virgin sources of the original distribution files
|
||||
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
|
||||
the files in this directory via patches and a cvs commit. New versions or
|
||||
official-patch versions must be imported. Please remember to import with
|
||||
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
|
||||
|
||||
For the import of GNU cpio 2.4.2, the following files were removed:
|
||||
|
||||
INSTALL cpio.info mkdir.c
|
||||
Makefile.in cpio.texi mkinstalldirs
|
||||
|
||||
To upgrade to a newer version of cpio, when it is available:
|
||||
1. Unpack the new version into an empty directory.
|
||||
[Do not make ANY changes to the files.]
|
||||
|
||||
2. Remove the files listed above and any others that don't apply to
|
||||
FreeBSD.
|
||||
|
||||
3. Use the command:
|
||||
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
|
||||
src/contrib/cpio GNU cpio_<version>
|
||||
|
||||
For example, to do the import of version 2.4.2, I typed:
|
||||
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
|
||||
src/contrib/cpio GNU cpio_2_4_2
|
||||
|
||||
4. Follow the instructions printed out in step 3 to resolve any
|
||||
conflicts between local FreeBSD changes and the newer version.
|
||||
|
||||
Do not, under any circumstances, deviate from this procedure.
|
||||
|
||||
To make local changes to cpio, simply patch and commit to the main
|
||||
branch (aka HEAD). Never make local changes on the GNU branch.
|
||||
|
||||
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
|
||||
inclusion in the next vendor release.
|
||||
|
||||
obrien@freebsd.org - 30 March 1997</programlisting>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-shlib">
|
||||
<title>Shared Libraries</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.asami;, &a.peter;, and
|
||||
&a.obrien;.<!-- <br> --> 9 December 1996.</emphasis></para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The three principles of shared library building are:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Start from <literal>1.0</literal></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If there is a change that is backwards compatible, bump
|
||||
minor number</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If there is an incompatible change, bump major
|
||||
number</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>For instance, added functions and bugfixes result in the minor
|
||||
version number being bumped, while deleted functions, changed
|
||||
function call syntax etc. will force the major version number to
|
||||
change.</para>
|
||||
|
||||
<para>Stick to version numbers of the form major.minor (<replaceable>x</replaceable>.<replaceable>y</replaceable>). Our
|
||||
dynamic linker does not handle version numbers of the form <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
|
||||
well. Any version number after the <replaceable>y</replaceable> (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, <command>ld.so</command> will link with the higher one.
|
||||
Ie: if you link with <filename>libfoo.so.3.3.3</filename>, the
|
||||
linker only records <literal>3.3</literal> in the headers, and will link with anything
|
||||
starting with <replaceable>libfoo.so.3</replaceable>.<replaceable>(anything >=
|
||||
3)</replaceable>.<replaceable>(highest available)</replaceable>.</para>
|
||||
|
||||
<note>
|
||||
<para><command>ld.so</command> will always use the highest
|
||||
“minor” revision. Ie: it will use <filename>libc.so.2.2</filename>
|
||||
in preference to <filename>libc.so.2.0</filename>, even if the
|
||||
program was initially linked with
|
||||
<filename>libc.so.2.0</filename>.</para>
|
||||
</note>
|
||||
|
||||
<para>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 <filename>Makefile</filename>'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 <filename>Makefile</filename> to be updated,
|
||||
and any subsequent changes will not.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
2568
en/handbook/ppp-and-slip/chapter.sgml
Normal file
2568
en/handbook/ppp-and-slip/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
4938
en/handbook/printing/chapter.sgml
Normal file
4938
en/handbook/printing/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
234
en/handbook/quotas/chapter.sgml
Normal file
234
en/handbook/quotas/chapter.sgml
Normal file
|
|
@ -0,0 +1,234 @@
|
|||
<chapter id="quotas">
|
||||
<title>Disk Quotas</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.mpp;.<!-- <br> -->26 February
|
||||
1996</emphasis></para>
|
||||
|
||||
<para>Quotas are an optional feature of the operating system that allow
|
||||
you to limit the amount of disk space and/or the number of files a
|
||||
user, or members of a group, may allocate on a per-file system basis.
|
||||
This is used most often on timesharing systems where it is desirable
|
||||
to limit the amount of resources any one user or group of users may
|
||||
allocate. This will prevent one user from consuming all of the
|
||||
available disk space.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Configuring Your System to Enable Disk Quotas</title>
|
||||
|
||||
<para>Before attempting to use disk quotas it is necessary to make
|
||||
sure that quotas are configured in your kernel. This is done by
|
||||
adding the following line to your kernel configuration file:</para>
|
||||
|
||||
<programlisting>
|
||||
options QUOTA</programlisting>
|
||||
|
||||
<para>The
|
||||
stock <filename>GENERIC</filename> 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
|
||||
<xref linkend="kernelconfig" remap="Configuring the FreeBSD Kernel">
|
||||
section for more information on kernel configuration.</para>
|
||||
|
||||
<para>Next you will need to enable disk quotas in
|
||||
<filename>/etc/sysconfig</filename>. This is done by changing the
|
||||
line:
|
||||
|
||||
<programlisting>
|
||||
quotas=NO</programlisting>
|
||||
|
||||
to:
|
||||
|
||||
<programlisting>
|
||||
quotas=YES</programlisting></para>
|
||||
|
||||
<para>If you are running FreeBSD 2.2.2 or later, the configuration
|
||||
file will be <filename>/etc/rc.conf</filename> instead and the
|
||||
variable name changed to:</para>
|
||||
|
||||
<programlisting>
|
||||
check_quotas=YES</programlisting>
|
||||
|
||||
<para>Finally you will need to edit <filename>/etc/fstab</filename> 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.</para>
|
||||
|
||||
<para>To enable per-user quotas on a file system, add the <literal>userquota</literal> option to the options field in the
|
||||
<filename>/etc/fstab</filename> entry for the file system you want
|
||||
to to enable quotas on. For example:</para>
|
||||
|
||||
<programlisting>
|
||||
/dev/sd1s2g /home ufs rw,userquota 1 2</programlisting>
|
||||
|
||||
<para>Similarly, to enable group quotas, use the
|
||||
<literal>groupquota</literal> option instead of the <literal>userquota</literal> keyword. To enable both user and
|
||||
group quotas, change the entry as follows:</para>
|
||||
|
||||
<programlisting>
|
||||
/dev/sd1s2g /home ufs rw,userquota,groupquota 1 2</programlisting>
|
||||
|
||||
<para>By default the quota files are stored in the root directory of
|
||||
the file system with the names <filename>quota.user</filename> and
|
||||
<filename>quota.group</filename> for user and group quotas
|
||||
respectively. See <command>man fstab</command> 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.</para>
|
||||
|
||||
<para>At this point you should reboot your system with your new
|
||||
kernel. <filename>/etc/rc</filename> will automatically run the
|
||||
appropriate commands to create the initial quota files for all of
|
||||
the quotas you enabled in <filename>/etc/fstab</filename>, so there
|
||||
is no need to manually create any zero length quota files.</para>
|
||||
|
||||
<para>In the normal course of operations you should not be required to
|
||||
run the <command>quotacheck</command>, <command>quotaon</command>, or <command>quotaoff</command> commands manually. However, you may
|
||||
want to read their man pages just to be familiar with their
|
||||
operation.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Setting Quota Limits</title>
|
||||
|
||||
<para>Once you have configured your system to enable quotas, verify
|
||||
that they really are enabled. An easy way to do this is to run</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>quota -v</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You should see a one line summary of
|
||||
disk usage and current quota limits for each file system that quotas
|
||||
are enabled on.</para>
|
||||
|
||||
<para>You are now ready to start assigning quota limits with the
|
||||
<command>edquota</command> command.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The following is an example of what you might see when you run
|
||||
then <command>edquota</command> command. When the
|
||||
<command>edquota</command> command is invoked, you are
|
||||
placed into the editor specified by the <envar>EDITOR</envar>
|
||||
environment variable, or in the <command>vi</command>
|
||||
editor if the <envar>EDITOR</envar> variable is not set, to
|
||||
allow you to edit the quota limits.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>edquota -u test</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<programlisting>
|
||||
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)</programlisting>
|
||||
|
||||
<para>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:
|
||||
|
||||
<programlisting>
|
||||
/usr: blocks in use: 65, limits (soft = 50, hard = 75)</programlisting> to:
|
||||
|
||||
<programlisting>
|
||||
/usr: blocks in use: 65, limits (soft = 500, hard = 600)</programlisting></para>
|
||||
|
||||
<para>The new
|
||||
quota limits will be in place when you exit the editor.</para>
|
||||
|
||||
<para>Sometimes it is desirable to set quota limits on a range of
|
||||
uids. This can be done by use of the <option>-p</option> option on
|
||||
the <command>edquota</command> command. First, assign
|
||||
the desired quota limit to a user, and then run <command>edquota -p
|
||||
protouser startuid-enduid</command>. For example, if user
|
||||
<username>test</username> has the desired quota limits, the
|
||||
following command can be used to duplicate those quota limits for
|
||||
uids 10,000 through 19,999:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>edquota -p test 10000-19999</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The 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.</para>
|
||||
|
||||
<para>See <command>man edquota</command> for more detailed
|
||||
information.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Checking Quota Limits and Disk Usage</title>
|
||||
|
||||
<para>You can use either the <command>quota</command> or
|
||||
the <command>repquota</command> commands to check quota
|
||||
limits and disk usage. The <command>quota</command>
|
||||
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
|
||||
<command>repquota</command> command can be used to get a
|
||||
summary of all quotas and disk usage for file systems with quotas
|
||||
enabled.</para>
|
||||
|
||||
<para>The following is some sample output from the <command>quota
|
||||
-v</command> command for a user that has quota limits on two file
|
||||
systems.</para>
|
||||
|
||||
|
||||
<programlisting>
|
||||
Disk quotas for user test (uid 1002):
|
||||
Filesystem blocks quota limit grace files quota limit grace
|
||||
/usr 65* 50 75 5days 7 50 60
|
||||
/usr/var 0 50 75 0 50 60</programlisting>
|
||||
|
||||
<para>On the <filename>/usr</filename> 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 <literal>*</literal> which
|
||||
indicates that the user is currently over their quota limit.</para>
|
||||
|
||||
<para>Normally file systems that the user is not using any disk space
|
||||
on will not show up in the output from the <command>quota</command> command, even if they have a quota limit
|
||||
assigned for that file system. The <option>-v</option> option will
|
||||
display those file systems, such as the
|
||||
<filename>/usr/var</filename> file system in the above
|
||||
example.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>* Quotas over NFS</title>
|
||||
|
||||
<para>This section is still under development.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
1698
en/handbook/security/chapter.sgml
Normal file
1698
en/handbook/security/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
2088
en/handbook/serialcomms/chapter.sgml
Normal file
2088
en/handbook/serialcomms/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
683
en/handbook/staff/chapter.sgml
Normal file
683
en/handbook/staff/chapter.sgml
Normal file
|
|
@ -0,0 +1,683 @@
|
|||
<chapter id="staff">
|
||||
<title>FreeBSD Project Staff</title>
|
||||
|
||||
<para>The FreeBSD Project is managed and operated by the following
|
||||
groups of people:</para>
|
||||
|
||||
|
||||
<sect1 id="staff-core">
|
||||
<title>The FreeBSD Core Team</title>
|
||||
|
||||
<para>The FreeBSD core team constitutes the project's “Board of
|
||||
Directors”, responsible for deciding the project's overall goals
|
||||
and direction as well as managing <xref linkend="staff-who"
|
||||
remap="specific
|
||||
areas"> of the FreeBSD project landscape.</para>
|
||||
|
||||
<para>(in alphabetical order by last name):</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>&a.asami;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ache;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dyson;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.bde;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gibbs;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.davidg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.phk;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rich;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gpalmer;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jdp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.guido;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.sos;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.peter;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wollman;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.joerg;</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-committers">
|
||||
<title>The FreeBSD Developers</title>
|
||||
|
||||
<para>These are the people who have commit privileges and do the
|
||||
engineering work on the FreeBSD source tree. All core team members
|
||||
and most FreeBSD Documentation project personnel are also
|
||||
developers.</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mbarkah;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.stb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.torstenb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.danny;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.charnier;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.kjc;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gclarkii;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cracauer;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.adam;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dufault;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.uhclem;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tegge;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.eivind;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.julian;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rse;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.se;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.sef;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.fenner;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfitz;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.lars;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.scrappy;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.brandon;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.graichen;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jgreco;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rgrimes;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hanai;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ahasty;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jhay;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.helbig;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.erich;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hsu;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.itojun;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ugen;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gj;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ljo;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.kato;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.andreas;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.imp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.smace;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mckay;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jlemon;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tedm;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.amurai;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.markm;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.max;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.alex;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.davidn;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.obrien;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.fsmp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.smpatel;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wpaul;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmacd;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.steve;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mpp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dfr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jraynard;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.darrenr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.csgr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.martin;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.paul;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.roberto;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.chuckr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dima;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wosch;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ats;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jseger;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.vanilla;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.msmith;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.brian;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.stark;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.karl;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cwt;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.pst;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hoek;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.swallace;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nate;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.yokota;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmz;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hosokawa;</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-doc">
|
||||
<title>The FreeBSD Documentation Project</title>
|
||||
|
||||
<para>The <ulink URL="http://www.freebsd.org/docproj.html">FreeBSD
|
||||
Documentation Project</ulink> is responsible for a number of
|
||||
different services, each service being run by an individual and his
|
||||
<emphasis>deputies</emphasis> (if any):</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>Documentation Project Manager</term>
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Webmaster</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mbarkah;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.paul;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Handbook & FAQ Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.faq;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Build Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.paul;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.dave;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Mirror Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ulf;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.john;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>News Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.john;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Gallery and Commercial Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.cawimm;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Style Police & Art Director</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dave;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.opsys;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Database Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mayo;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.cracauer;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>CGI Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cracauer;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.stb;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Bottle Washing</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Drying plates:</emphasis> &a.nik;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-who">
|
||||
<title>Who Is Responsible for What</title>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>Principal Architect</term>
|
||||
<listitem>
|
||||
<para>&a.davidg;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Documentation Project Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Internationalization</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ache;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Networking</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wollman;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Postmaster</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmb;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Release Coordinator</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Public Relations & Corporate
|
||||
Liaison</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Security Officer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.guido;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Source Repository Managers</term>
|
||||
|
||||
<listitem>
|
||||
<para>Principal: &a.peter;</para>
|
||||
|
||||
<para>Assistant: &a.jdp;</para>
|
||||
|
||||
<para>International (Crypto): &a.markm;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Ports Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.asami;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>XFree86 Project, Inc. Liaison</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rich;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Usenet Support</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.joerg;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>GNATS Administrator</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.steve;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
8
en/handbook/x11/chapter.sgml
Normal file
8
en/handbook/x11/chapter.sgml
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
<chapter id="x11">
|
||||
<title>The X Window System</title>
|
||||
|
||||
<para>Pending the completion of this section, please refer to
|
||||
documentation supplied by the <ulink URL="http://www.xfree86.org/">The
|
||||
XFree86 Project, Inc</ulink>.</para>
|
||||
|
||||
</chapter>
|
||||
4901
en_US.ISO8859-1/articles/contributing/article.sgml
Normal file
4901
en_US.ISO8859-1/articles/contributing/article.sgml
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,634 @@
|
|||
<chapter id="kerneldebug">
|
||||
<title>Kernel Debugging</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.paul; and &a.joerg;</emphasis></para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Debugging a Kernel Crash Dump with <command>kgdb</command></title>
|
||||
|
||||
<para>Here 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 <literal>config
|
||||
kernel</literal> line), or you can specify an alternate using the
|
||||
<citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command. Dumps to non-swap devices, tapes for example,
|
||||
are currently not supported. Config your kernel using
|
||||
<command>config -g</command>. See <xref linkend="kernelconfig"
|
||||
remap="Kernel Configuration"> for
|
||||
details on configuring the FreeBSD kernel.</para>
|
||||
|
||||
<para>Use the <citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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
|
||||
<citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>). This is normally arranged via
|
||||
<filename>/etc/rc.conf</filename> and <filename>/etc/rc</filename>.
|
||||
Alternatively, you can hard-code the dump device via the <literal>dump</literal>
|
||||
clause in the <literal>config</literal> 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.</para>
|
||||
|
||||
<note>
|
||||
<para>In the following, the term <command>kgdb</command> refers to
|
||||
<command>gdb</command> run in “kernel debug mode”. This can be
|
||||
accomplished by either starting the <command>gdb</command> with
|
||||
the option <option>-k</option>, or by linking and starting it
|
||||
under the name <command>kgdb</command>. 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.</para>
|
||||
</note>
|
||||
|
||||
<para>When the kernel has been built make a copy of it, say
|
||||
<filename>kernel.debug</filename>, and then run <command>strip
|
||||
-d</command> 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.</para>
|
||||
|
||||
<para>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 <option>-s</option> flag at the boot
|
||||
prompt, and then perform the following steps:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>fsck -p</userinput>
|
||||
&prompt.root; <userinput>mount -a -t ufs</userinput> # so your file system for /var/crash is writable
|
||||
&prompt.root; <userinput>savecore -N /kernel.panicked /var/crash</userinput>
|
||||
&prompt.root; <userinput>exit</userinput> # ...to multi-user</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This instructs <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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.</para>
|
||||
|
||||
<para>Now, after a crash dump, go to
|
||||
<filename>/sys/compile/WHATEVER</filename> and run <command>kgdb</command>. From <command>kgdb</command>
|
||||
do:
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>symbol-file kernel.debug</userinput>
|
||||
<userinput>exec-file /var/crash/kernel.0</userinput>
|
||||
<userinput>core-file /var/crash/vmcore.0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
and voila, you can debug the crash dump using the
|
||||
kernel sources just like you can for any other program.</para>
|
||||
|
||||
<para>Here is a script log of a <command>kgdb</command>
|
||||
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.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen> 1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:&prompt.root; <userinput>cd /sys/compile/URIAH</userinput>
|
||||
3:&prompt.root; <userinput>kgdb kernel /var/crash/vmcore.1</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>where</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up 10</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>frame frame->tf_ebp frame->tf_eip</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>list</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>print tp</userinput>
|
||||
53:Reading in symbols for ../../i386/i386/cons.c...done.
|
||||
54:$1 = (struct tty *) 0x1bae
|
||||
55:<prompt>(kgdb)</prompt> <userinput>print tp->t_line</userinput>
|
||||
56:$2 = 1767990816
|
||||
57:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
62:#2 0xf0132c34 in spec_open ()
|
||||
63:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
64:#3 0xf012d014 in vn_open ()
|
||||
65:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
66:#4 0xf012a183 in open ()
|
||||
67:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
75:Initial frame selected; you cannot go up.
|
||||
76:<prompt>(kgdb)</prompt> <userinput>quit</userinput>
|
||||
77:&prompt.root; <userinput>exit</userinput>
|
||||
78:exit
|
||||
79:
|
||||
80:Script done on Fri Dec 30 23:18:04 1994</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Comments to the above script:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>line 6:</term>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 20:</term>
|
||||
|
||||
<listitem>
|
||||
<para>This is the location of function
|
||||
<function>trap()</function> in the stack trace.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 36:</term>
|
||||
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 52:</term>
|
||||
|
||||
<listitem>
|
||||
<para>The pointer looks suspicious, but happens to be a valid
|
||||
address.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 56:</term>
|
||||
|
||||
<listitem>
|
||||
<para>However, it obviously points to garbage, so we have
|
||||
found our error! (For those unfamiliar with that particular
|
||||
piece of code: <literal>tp->t_line</literal>
|
||||
refers to the line discipline of the console device here,
|
||||
which must be a rather small integer number.)</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Post-mortem Analysis of a Dump</title>
|
||||
|
||||
<para>What do you do if a kernel dumped core but you did not expect
|
||||
it, and it is therefore not compiled using <command>config
|
||||
-g</command>? Not everything is lost here. Do not panic!</para>
|
||||
|
||||
<para>Of course, you still need to enable crash dumps. See above on
|
||||
the options you have to specify in order to do this.</para>
|
||||
|
||||
<para>Go to your kernel compile directory, and edit the line
|
||||
containing <literal>COPTFLAGS?=-O</literal>. Add the
|
||||
<option>-g</option> option there (but <emphasis>do not</emphasis>
|
||||
change anything on the level of optimization). If you do already
|
||||
know roughly the probable location of the failing piece of code
|
||||
(e.g., the <devicename>pcvt</devicename> driver in the example
|
||||
above), remove all the object files for this code. Rebuild the
|
||||
kernel. Due to the time stamp change on the Makefile, there will be
|
||||
some other object files rebuild, for example
|
||||
<filename>trap.o</filename>. With a bit of luck, the added
|
||||
<option>-g</option> 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
|
||||
<citerefentry><refentrytitle>size</refentrytitle><manvolnum>1</manvolnum></citerefentry> command. If there is a mismatch, you
|
||||
probably need to give up here.</para>
|
||||
|
||||
<para>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
|
||||
<command>kgdb</command> session until you know
|
||||
enough.</para>
|
||||
|
||||
<para>All this is not guaranteed to work, but it will do it fine in
|
||||
most cases.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>On-line Kernel Debugging Using DDB</title>
|
||||
|
||||
<para>While <command>kgdb</command> 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.</para>
|
||||
|
||||
<para>If you need to do low-level debugging on your kernel, there is
|
||||
an on-line debugger available called DDB. It allows to setting
|
||||
breakpoints, single-steping kernel functions, examining and changing
|
||||
kernel variables, etc. However, it cannot access kernel source
|
||||
files, and only has access to the global and static symbols, not to
|
||||
the full debug information like <command>kgdb</command>.</para>
|
||||
|
||||
<para>To configure your kernel to include DDB, add the option line
|
||||
|
||||
<programlisting>
|
||||
options DDB</programlisting> to your config file, and rebuild. (See <xref
|
||||
linkend="kernelconfig"
|
||||
remap="Kernel Configuration"> for details on configuring the
|
||||
FreeBSD kernel.</para>
|
||||
|
||||
<note>
|
||||
<para>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.)</para>
|
||||
</note>
|
||||
|
||||
<para>Once your DDB kernel is running, there are several ways to enter
|
||||
DDB. The first, and earliest way is to type the boot flag
|
||||
<option>-d</option> 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.</para>
|
||||
|
||||
<para>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 (<literal>options
|
||||
BREAK_TO_DEBUGGER</literal> 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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The DDB commands roughly resemble some <command>gdb</command> commands. The first thing you probably
|
||||
need to do is to set a breakpoint:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>b function-name</userinput>
|
||||
<userinput>b address</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Numbers are taken hexadecimal by default, but to make them
|
||||
distinct from symbol names; hexadecimal numbers starting with the
|
||||
letters <literal>a-f</literal> need to be preceded with
|
||||
<literal>0x</literal> (this is optional for other numbers). Simple
|
||||
expressions are allowed, for example: <literal>function-name +
|
||||
0x103</literal>.</para>
|
||||
|
||||
<para>To continue the operation of an interrupted kernel, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>c</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To get a stack trace, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>trace</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>Note 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.</para>
|
||||
</note>
|
||||
|
||||
<para>If you want to remove a breakpoint, use</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>del</userinput>
|
||||
<userinput>del address-expression</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The first form will be accepted immediately after
|
||||
a breakpoint hit, and deletes the current breakpoint. The second
|
||||
form can remove any breakpoint, but you need to specify the exact
|
||||
address; this can be obtained from:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>show b</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To single-step the kernel, try:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>s</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will step into functions, but you can make
|
||||
DDB trace them until the matching return statement is reached by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>n</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>This is different from <command>gdb</command>'s <command>next</command>
|
||||
statement; it is like <command>gdb</command>'s <command>finish</command>.</para>
|
||||
</note>
|
||||
|
||||
<para>To examine data from memory, use (for example):
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x/wx 0xf0133fe0,40</userinput>
|
||||
<userinput>x/hd db_symtab_space</userinput>
|
||||
<userinput>x/bc termbuf,10</userinput>
|
||||
<userinput>x/s stringbuf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x ,10</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Similarly, use
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x/ia foofunc,10</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
to disassemble the first 0x10 instructions of
|
||||
<function>foofunc</function>, and display them along with
|
||||
their offset from the beginning of <function>foofunc</function>.</para>
|
||||
|
||||
<para>To modify memory, use the write command:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>w/b termbuf 0xa 0xb 0</userinput>
|
||||
<userinput>w/w 0xf0010030 0 0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The command modifier
|
||||
(<literal>b</literal>/<literal>h</literal>/<literal>w</literal>) 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.</para>
|
||||
|
||||
<para>If you need to know the current registers, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>show reg</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Alternatively, you can display a single register
|
||||
value by e.g.
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>p $eax</userinput></screen>
|
||||
</informalexample> and modify it by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>set $eax new-value</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Should you need to call some kernel functions from DDB, simply
|
||||
say:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call func(arg1, arg2, ...)</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The return value will be printed.</para>
|
||||
|
||||
<para>For a <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> style summary of all running
|
||||
processes, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>ps</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now 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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call diediedie()</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>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 <command>continue</command> statement. There is now an alias for
|
||||
this: <command>panic</command>.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call boot(0)</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Which might be a good way to cleanly shut down the
|
||||
running system, <function>sync()</function> 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.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call cpu_reset()</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>is the final way out of disaster and almost the
|
||||
same as hitting the Big Red Button.</para>
|
||||
|
||||
<para>If you need a short command summary, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>help</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>However, it is highly recommended to have a
|
||||
printed copy of the <citerefentry><refentrytitle>ddb</refentrytitle><manvolnum>4</manvolnum></citerefentry> manual page
|
||||
ready for a debugging session. Remember that it is hard to read the
|
||||
on-line manual while single-stepping the kernel.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>On-line Kernel Debugging Using Remote GDB</title>
|
||||
|
||||
<para>This feature has been supported since FreeBSD 2.2, and it's
|
||||
actually a very neat one.</para>
|
||||
|
||||
<para>GDB has already supported <emphasis>remote debugging</emphasis>
|
||||
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).</para>
|
||||
|
||||
<para>You should configure the kernel in question with <command>config
|
||||
-g</command>, include <option>DDB</option> 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 <command>strip
|
||||
-x</command>, and boot it using the <option>-d</option> 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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>gdb -k kernel</userinput>
|
||||
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...
|
||||
<prompt>(kgdb)</prompt> </screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Initialize the remote debugging session (assuming the first
|
||||
serial port is being used) by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>(kgdb)</prompt> <userinput>target remote /dev/cuaa0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now, on the target host (the one that entered DDB right before
|
||||
even starting the device probe), type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
<prompt>db></prompt> <userinput>gdb</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>DDB will respond with:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Next trap will enter GDB remote protocol mode</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Every time you type <command>gdb</command>, the mode will be toggled between
|
||||
remote GDB and local DDB. In order to force a next trap
|
||||
immediately, simply type <command>s</command> (step). Your hosting GDB will now
|
||||
gain control over the target kernel:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
at ../../i386/i386/db_interface.c:257
|
||||
<prompt>(kgdb)</prompt></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>Remote GDB can also be used to debug LKMs. First build the LKM
|
||||
with debugging symbols:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
|
||||
&prompt.root; <userinput>make clean; make COPTS=-g</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Then install this version of the module on the target machine,
|
||||
load it and use <command>modstat</command> to find out
|
||||
where it was loaded:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>linux</userinput>
|
||||
&prompt.root; <userinput>modstat</userinput>
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f5109000 001c f510f010 1 linux_mod</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Take 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 <command>add-symbol-file</command> command in GDB to tell the
|
||||
debugger about the module:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>(kgdb)</prompt> <userinput>add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020</userinput>
|
||||
add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
|
||||
text_addr = 0xf5109020? (y or n) <userinput>y</userinput>
|
||||
<prompt>(kgdb)</prompt></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You now have access to all the symbols in the LKM.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Debugging a Console Driver</title>
|
||||
|
||||
<para>Since 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 <option>-h</option> at the <prompt>Boot:</prompt> 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.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
283
en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml
Normal file
283
en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml
Normal file
|
|
@ -0,0 +1,283 @@
|
|||
<chapter id="policies">
|
||||
<title>Source Tree Guidelines and Policies</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.phk;.</emphasis></para>
|
||||
|
||||
<para>This chapter documents various guidelines and policies in force
|
||||
for the FreeBSD source tree.</para>
|
||||
|
||||
|
||||
<sect1 id="policies-maintainer">
|
||||
<title><makevar>MAINTAINER</makevar> on Makefiles</title>
|
||||
|
||||
<para>June 1996.</para>
|
||||
|
||||
<para>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
|
||||
|
||||
<programlisting>
|
||||
MAINTAINER= email-addresses</programlisting>
|
||||
|
||||
line to the <filename>Makefile</filename>s covering this portion
|
||||
of the source tree.</para>
|
||||
|
||||
<para>The semantics of this are as follows:</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Contributed Software</title>
|
||||
|
||||
<para>June 1996.</para>
|
||||
|
||||
<para>Some parts of the FreeBSD distribution consist of software that
|
||||
is actively being maintained outside the FreeBSD project. For
|
||||
historical reasons, we call this <emphasis>contributed</emphasis>
|
||||
software. Some examples are perl, gcc and patch.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The <application>Tcl</application> embedded programming
|
||||
language will be used as example of how this model works:</para>
|
||||
|
||||
<para><filename>src/contrib/tcl</filename> 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 <filename>mac</filename>, <filename>win</filename> and
|
||||
<filename>compat</filename> subdirectories were eliminated before
|
||||
the import</para>
|
||||
|
||||
<para><filename>src/lib/libtcl</filename> contains only a "bmake style"
|
||||
<filename>Makefile</filename> that uses the standard
|
||||
<filename>bsd.lib.mk</filename> makefile rules to produce the
|
||||
library and install the documentation.</para>
|
||||
|
||||
<para><filename>src/usr.bin/tclsh</filename> contains only a bmake style
|
||||
<filename>Makefile</filename> which will produce and install the
|
||||
<command>tclsh</command> program and its associated man-pages using the standard
|
||||
<filename>bsd.prog.mk</filename> rules.</para>
|
||||
|
||||
<para><filename>src/tools/tools/tcl_bmake</filename> 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.</para>
|
||||
|
||||
<para>The important thing here is that the
|
||||
<filename>src/contrib/tcl</filename> directory is created according
|
||||
to the rules: It is supposed to contain the sources as distributed
|
||||
(on a proper CVS vendor-branch) with as few FreeBSD-specific changes
|
||||
as possible. The 'easy-import' tool on freefall will assist in
|
||||
doing the import, but if there are any doubts on how to go about it,
|
||||
it is imperative that you ask first and not blunder ahead and hope
|
||||
it “works out”. CVS is not forgiving of import accidents and a fair
|
||||
amount of effort is required to back out major mistakes.</para>
|
||||
|
||||
<para>Because of some unfortunate design limitations with CVS's vendor
|
||||
branches, it is required that “official” patches from the vendor be
|
||||
applied to the original distributed sources and the result
|
||||
re-imported onto the vendor branch again. Official patches should
|
||||
never be patched into the FreeBSD checked out version and
|
||||
"committed", as this destroys the vendor branch coherency and makes
|
||||
importing future versions rather difficult as there will be
|
||||
conflicts.</para>
|
||||
|
||||
<para>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 <emphasis>not</emphasis> be
|
||||
removed.</para>
|
||||
|
||||
<para>If it seems easier, the <command>bmake</command> <filename>Makefile</filename>s
|
||||
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 <filename>src/tools</filename> directory along
|
||||
with the port itself so that it is available to future
|
||||
maintainers.</para>
|
||||
|
||||
<para>In the <filename>src/contrib/tcl</filename> level directory, a
|
||||
file called <filename>FREEBSD-upgrade</filename> should be added and
|
||||
it should states things like:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Which files have been left out</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Where the original distribution was obtained from and/or
|
||||
the official master site.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Where to send patches back to the original authors</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Perhaps an overview of the FreeBSD-specific changes that
|
||||
have been made.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>However, please do not import
|
||||
<filename>FREEBSD-upgrade</filename> with the contributed source.
|
||||
Rather you should <command>cvs add FREEBSD-upgrade ; cvs ci</command> after the
|
||||
initial import. Example wording from
|
||||
<filename>src/contrib/cpio</filename> is below:</para>
|
||||
|
||||
<programlisting>
|
||||
This directory contains virgin sources of the original distribution files
|
||||
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
|
||||
the files in this directory via patches and a cvs commit. New versions or
|
||||
official-patch versions must be imported. Please remember to import with
|
||||
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
|
||||
|
||||
For the import of GNU cpio 2.4.2, the following files were removed:
|
||||
|
||||
INSTALL cpio.info mkdir.c
|
||||
Makefile.in cpio.texi mkinstalldirs
|
||||
|
||||
To upgrade to a newer version of cpio, when it is available:
|
||||
1. Unpack the new version into an empty directory.
|
||||
[Do not make ANY changes to the files.]
|
||||
|
||||
2. Remove the files listed above and any others that don't apply to
|
||||
FreeBSD.
|
||||
|
||||
3. Use the command:
|
||||
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
|
||||
src/contrib/cpio GNU cpio_<version>
|
||||
|
||||
For example, to do the import of version 2.4.2, I typed:
|
||||
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
|
||||
src/contrib/cpio GNU cpio_2_4_2
|
||||
|
||||
4. Follow the instructions printed out in step 3 to resolve any
|
||||
conflicts between local FreeBSD changes and the newer version.
|
||||
|
||||
Do not, under any circumstances, deviate from this procedure.
|
||||
|
||||
To make local changes to cpio, simply patch and commit to the main
|
||||
branch (aka HEAD). Never make local changes on the GNU branch.
|
||||
|
||||
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
|
||||
inclusion in the next vendor release.
|
||||
|
||||
obrien@freebsd.org - 30 March 1997</programlisting>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-shlib">
|
||||
<title>Shared Libraries</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.asami;, &a.peter;, and
|
||||
&a.obrien;.<!-- <br> --> 9 December 1996.</emphasis></para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The three principles of shared library building are:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Start from <literal>1.0</literal></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If there is a change that is backwards compatible, bump
|
||||
minor number</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If there is an incompatible change, bump major
|
||||
number</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>For instance, added functions and bugfixes result in the minor
|
||||
version number being bumped, while deleted functions, changed
|
||||
function call syntax etc. will force the major version number to
|
||||
change.</para>
|
||||
|
||||
<para>Stick to version numbers of the form major.minor (<replaceable>x</replaceable>.<replaceable>y</replaceable>). Our
|
||||
dynamic linker does not handle version numbers of the form <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
|
||||
well. Any version number after the <replaceable>y</replaceable> (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, <command>ld.so</command> will link with the higher one.
|
||||
Ie: if you link with <filename>libfoo.so.3.3.3</filename>, the
|
||||
linker only records <literal>3.3</literal> in the headers, and will link with anything
|
||||
starting with <replaceable>libfoo.so.3</replaceable>.<replaceable>(anything >=
|
||||
3)</replaceable>.<replaceable>(highest available)</replaceable>.</para>
|
||||
|
||||
<note>
|
||||
<para><command>ld.so</command> will always use the highest
|
||||
“minor” revision. Ie: it will use <filename>libc.so.2.2</filename>
|
||||
in preference to <filename>libc.so.2.0</filename>, even if the
|
||||
program was initially linked with
|
||||
<filename>libc.so.2.0</filename>.</para>
|
||||
</note>
|
||||
|
||||
<para>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 <filename>Makefile</filename>'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 <filename>Makefile</filename> to be updated,
|
||||
and any subsequent changes will not.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
1008
en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
Normal file
1008
en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
136
en_US.ISO8859-1/books/handbook/basics/chapter.sgml
Normal file
136
en_US.ISO8859-1/books/handbook/basics/chapter.sgml
Normal file
|
|
@ -0,0 +1,136 @@
|
|||
<chapter id="basics">
|
||||
<title>Unix Basics</title>
|
||||
|
||||
|
||||
<sect1 id="basics-man">
|
||||
<title>The Online Manual</title>
|
||||
|
||||
<para>The most comprehensive documentation on FreeBSD is in the form
|
||||
of <emphasis>man pages</emphasis>. 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
|
||||
<command>man</command>
|
||||
command. Use of the <command>man</command> command is simple:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man <replaceable>command</replaceable></userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><replaceable>command</replaceable> is
|
||||
the name of the command you wish to learn about. For example, to
|
||||
learn more about <command>ls</command> command type:</para>
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man ls</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The online manual is divided up into numbered sections:</para>
|
||||
|
||||
<orderedlist>
|
||||
|
||||
<listitem>
|
||||
<para>User commands</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>System calls and error numbers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Functions in the C libraries</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Device drivers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>File formats</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Games and other diversions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Miscellaneous information</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>System maintenance and operation commands</para>
|
||||
</listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
<para>In some cases, the same topic may appear in more than
|
||||
one section of the on-line manual. For example, there is a
|
||||
<command>chmod</command>
|
||||
user command and a <function>chmod()</function> system call. In
|
||||
this case, you can tell the <command>man</command> command which one you want by
|
||||
specifying the section:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man 1 chmod</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will display the manual page for the user
|
||||
command <command>chmod</command>. References to a
|
||||
particular section of the on-line manual are traditionally placed in
|
||||
parenthesis in written documentation, so <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry> refers to the
|
||||
<command>chmod</command>
|
||||
user command and <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>2</manvolnum></citerefentry> refers to the
|
||||
system call.</para>
|
||||
|
||||
<para>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 <command>man</command> to search for keywords in the
|
||||
command <emphasis>descriptions</emphasis> by using the
|
||||
<option>-k</option> switch:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man -k mail</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>With this command you will be presented with a
|
||||
list of commands that have the keyword “mail” in their descriptions.
|
||||
This is actually functionally equivalent to using the <command>apropos</command>
|
||||
command.</para>
|
||||
|
||||
<para>So, you are looking at all those fancy commands in
|
||||
<filename>/usr/bin</filename> but do not even have the faintest idea
|
||||
what most of them actually do? Simply do a
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>cd /usr/bin; man -f *</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
or
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>cd /usr/bin; whatis *</userinput></screen>
|
||||
</informalexample> which does the same thing.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="basics-info">
|
||||
<title>GNU Info Files</title>
|
||||
|
||||
<para>FreeBSD includes many applications and utilities produced by the
|
||||
Free Software Foundation (FSF). In addition to man pages, these
|
||||
programs come with more extensive hypertext documents called
|
||||
“info” files which can be viewed with the
|
||||
<command>info</command> command or, if you installed
|
||||
<command>emacs</command>, the info mode of <command>emacs</command>.</para>
|
||||
|
||||
<para>To use the <citerefentry><refentrytitle>info</refentrytitle><manvolnum>1</manvolnum></citerefentry> command, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>info</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>For a brief introduction, type <userinput>h</userinput>. For a quick
|
||||
command reference, type <userinput>?</userinput>.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
478
en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
Normal file
478
en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
Normal file
|
|
@ -0,0 +1,478 @@
|
|||
<chapter id="bibliography">
|
||||
<title>Bibliography</title>
|
||||
|
||||
<para>While 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.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Books & Magazines Specific to FreeBSD</title>
|
||||
|
||||
<para><emphasis>International books &
|
||||
Magazines:</emphasis></para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://freebsd.csie.nctu.edu.tw/~jdli/book.html">Using
|
||||
FreeBSD</ulink> (in Chinese).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD for PC 98'ers (in Japanese), published by SHUWA
|
||||
System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD (in Japanese), published by CUTT. ISBN
|
||||
4-906391-22-2 C3055 P2400E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.shoeisha.co.jp/pc/index/shinkan/97_05_06.htm">Complete Introduction to FreeBSD</ulink> (in Japanese), published by <ulink URL="http://www.shoeisha.co.jp/">Shoeisha Co., Ltd</ulink>. ISBN 4-88135-473-6 P3600E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.ascii.co.jp/pb/book1/shinkan/detail/1322785.html">Personal UNIX Starter Kit FreeBSD</ulink> (in Japanese), published by <ulink URL="http://www.ascii.co.jp/">ASCII</ulink>. ISBN 4-7561-1733-3 P3000E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD Handbook (Japanese translation), published by
|
||||
<ulink URL="http://www.ascii.co.jp/">ASCII</ulink>. ISBN
|
||||
4-7561-1580-2 P3800E.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para><emphasis>English language books &
|
||||
Magazines:</emphasis></para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.cdrom.com/titles/os/bsdbook2.htm">The
|
||||
Complete FreeBSD</ulink>, published by <ulink
|
||||
URL="http://www.cdrom.com">Walnut Creek
|
||||
CDROM</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Users' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD User's Reference Manual</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1994.<!-- <br> --> ISBN
|
||||
1-56592-075-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD User's Supplementary Documents</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1994.<!-- <br> --> ISBN
|
||||
1-56592-076-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>UNIX in a Nutshell</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1990.<!-- <br> --> ISBN
|
||||
093717520X</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Mui, Linda. <emphasis>What You Need To Know When You Can't
|
||||
Find Your UNIX System Administrator</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1995. <!-- <br> --> ISBN 1-56592-104-6</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink URL="http://www-wks.acs.ohio-state.edu/">Ohio State
|
||||
University</ulink> has written a <ulink
|
||||
URL="http://www-wks.acs.ohio-state.edu/unix_course/unix.html">UNIX Introductory Course</ulink> which is available online in HTML and postscript format.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Administrators' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Albitz, Paul and Liu, Cricket. <emphasis>DNS and
|
||||
BIND</emphasis>, 2nd Ed. O'Reilly & Associates, Inc.,
|
||||
1997. <!-- <br> --> ISBN 1-56592-236-0</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD System Manager's Manual</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1994. <!-- <br> --> ISBN
|
||||
1-56592-080-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Costales, Brian, et al. <emphasis>Sendmail</emphasis>, 2nd
|
||||
Ed. O'Reilly & Associates, Inc., 1997.<!-- <br> --> ISBN
|
||||
1-56592-222-0</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Frisch, Æleen. <emphasis>Essential System
|
||||
Administration</emphasis>, 2nd Ed. O'Reilly &
|
||||
Associates, Inc., 1995. <!-- <br> -->ISBN 1-56592-127-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hunt, Craig. <emphasis>TCP/IP Network
|
||||
Administration</emphasis>. O'Reilly & Associates, Inc.,
|
||||
1992. <!-- <br> --> ISBN 0-937175-82-X</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Nemeth, Evi. <emphasis>UNIX System Administration
|
||||
Handbook</emphasis>. 2nd ed. Prentice Hall, 1995. <!-- <br>
|
||||
--> ISBN 0131510517</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stern, Hal <emphasis>Managing NFS and NIS</emphasis>
|
||||
O'Reilly & Associates, Inc., 1991. <!-- <br> --> ISBN
|
||||
0-937175-75-7</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Programmers' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Asente, Paul. <emphasis>X Window System
|
||||
Toolkit</emphasis>. Digital Press. <!-- <br> --> ISBN
|
||||
1-55558-051-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD Programmer's Reference Manual</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1994. <!-- <br> --> ISBN
|
||||
1-56592-078-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD Programmer's Supplementary
|
||||
Documents</emphasis>. O'Reilly & Associates, Inc., 1994.
|
||||
<!-- <br> --> ISBN 1-56592-079-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ellis, Margaret A. and Stroustrup, Bjarne. <emphasis>The
|
||||
Annotated C++ Reference Manual</emphasis>. Addison-Wesley,
|
||||
1990. <!-- <br> --> ISBN 0-201-51459-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Harbison, Samuel P. and Steele, Guy L. Jr. <emphasis>C: A
|
||||
Reference Manual</emphasis>. 4rd ed. Prentice Hall, 1995.
|
||||
<!-- <br> -->ISBN 0-13-326224-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Kernighan, Brian and Dennis M. Ritchie. <emphasis>The C
|
||||
Programming Language.</emphasis>. PTR Prentice Hall, 1988.
|
||||
<!-- <br> --> ISBN 0-13-110362-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Lehey, Greg. <emphasis>Port UNIX Software</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1995.<!-- <br> --> ISBN
|
||||
1-56592-126-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Plauger, P. J. <emphasis>The Standard C
|
||||
Library</emphasis>. Prentice Hall, 1992. <!-- <br> --> ISBN
|
||||
0-13-131509-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>Advanced Programming in the
|
||||
UNIX Environment</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1992<!-- <br> --> ISBN 0-201-56317-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>UNIX Network
|
||||
Programming</emphasis>. PTR Prentice Hall, 1990. <!-- <br>
|
||||
--> ISBN 0-13-949876-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wells, Bill. “Writing Serial Drivers for UNIX”.
|
||||
<emphasis>Dr. Dobb's Journal</emphasis>. 19(15), December
|
||||
1994. pp68-71, 97-99.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Operating System Internals</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Andleigh, Prabhat K. <emphasis>UNIX System
|
||||
Architecture</emphasis>. Prentice-Hall, Inc., 1990.<!-- <br>
|
||||
--> ISBN 0-13-949843-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Jolitz, William. “Porting UNIX to the
|
||||
386”. <emphasis>Dr.
|
||||
Dobb's Journal</emphasis>. January 1991-July 1992.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Leffler, Samuel J., Marshall Kirk McKusick, Michael J
|
||||
Karels and John Quarterman <emphasis>The Design and
|
||||
Implementation of the 4.3BSD UNIX Operating
|
||||
System</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1989.<!-- <br> --> ISBN 0-201-06196-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Leffler, Samuel J., Marshall Kirk McKusick, <emphasis>The
|
||||
Design and Implementation of the 4.3BSD UNIX Operating
|
||||
System: Answer Book</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1991.<!-- <br> --> ISBN 0-201-54629-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
|
||||
and John Quarterman. <emphasis>The Design and Implementation
|
||||
of the 4.4BSD Operating System</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1996.<!-- <br> --> ISBN 0-201-54979-4</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume
|
||||
1: The Protocols</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1996.<!-- <br> --> ISBN 0-201-63346-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume
|
||||
3: TCP for Transactions, HTTP, NNTP and the UNIX Domain
|
||||
Protocols</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1996.<!-- <br> --> ISBN 0-201-63495-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Vahalia, Uresh. <emphasis>UNIX Internals -- The New
|
||||
Frontiers</emphasis>. Prentice Hall, 1996.<!-- <br> --> ISBN
|
||||
0-13-101908-2</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wright, Gary R. and W. Richard Stevens. <emphasis>TCP/IP
|
||||
Illustrated, Volume 2: The Implementation</emphasis>.
|
||||
Reading, Mass. : Addison-Wesley, 1995.<!-- <br> --> ISBN
|
||||
0-201-63354-X</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Security Reference</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Cheswick, William R. and Steven M. Bellovin.
|
||||
<emphasis>Firewalls and Internal Security: Repelling the Wily
|
||||
Hacker</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1995.<!-- <br> --> ISBN 0-201-63357-4</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Garfinkel, Simson and Gene Spafford. <emphasis>Practical
|
||||
UNIX Security</emphasis>. 2nd Ed. O'Reilly & Associates,
|
||||
Inc., 1996. <!-- <br> --> ISBN 1-56592-148-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Garfinkel, Simson. <emphasis>PGP Pretty Good
|
||||
Privacy</emphasis> O'Reilly & Associates, Inc., 1995.
|
||||
<!-- <br> --> ISBN 1-56592-098-8</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Hardware Reference</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Anderson, Don and Tom Shanley. <emphasis>Pentium Processor
|
||||
System Architecture</emphasis>. 2nd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995.<!-- <br> --> ISBN 0-201-40992-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ferraro, Richard F. <emphasis>Programmer's Guide to the
|
||||
EGA, VGA, and Super VGA Cards</emphasis>. 3rd ed. Reading,
|
||||
Mass. : Addison-Wesley, 1995.<!-- <br> --> ISBN
|
||||
0-201-62490-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>80486 System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <!-- <br> -->ISBN 0-201-40994-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>ISA System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995.<!-- <br> --> ISBN 0-201-40996-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>PCI System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <!-- <br> -->ISBN 0-201-40993-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Van Gilluwe, Frank. <emphasis>The Undocumented
|
||||
PC</emphasis>. Reading, Mass: Addison-Wesley Pub. Co.,
|
||||
1994.<!-- <br> --> ISBN 0-201-62277-7</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>UNIX History</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Lion, John <emphasis>Lion's Commentary on UNIX, 6th Ed.
|
||||
With Source Code</emphasis>. ITP Media Group, 1996.<!-- <br>
|
||||
--> ISBN 1573980137</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Raymond, Eric s. <emphasis>The New Hacker's Dictonary, 3rd
|
||||
edition</emphasis>. MIT Press, 1996.<!-- <br> --> ISBN
|
||||
0-262-68092-0<!-- <br> --> Also known as the <ulink
|
||||
URL="http://www.ccil.org/jargon/jargon.html">Jargon
|
||||
File</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Salus, Peter H. <emphasis>A quarter century of
|
||||
UNIX</emphasis>. Addison-Wesley Publishing Company, Inc.,
|
||||
1994.<!-- <br> --> ISBN 0-201-54777-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Simon Garfinkel, Daniel Weise, Steven Strassmann.
|
||||
<emphasis>The UNIX-HATERS Handbook</emphasis>. IDG Books
|
||||
Worldwide, Inc., 1994.<!-- <br> --> ISBN 1-56884-203-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don Libes, Sandy Ressler <emphasis>Life with
|
||||
UNIX</emphasis> — special edition. Prentice-Hall, Inc.,
|
||||
1989.<!-- <br> --> ISBN 0-13-536657-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The BSD family tree</emphasis>. 1997.<!-- <br>
|
||||
--> <ulink
|
||||
URL="http://www.de.freebsd.org/de/ftp/unix-stammbaum">http://www.de.freebsd.org/de/ftp/unix-stammbaum</ulink> or <ulink URL="file:/usr/share/misc/bsd-family-tree">local</ulink> on a FreeBSD-current machine.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The BSD Release Announcements
|
||||
collection</emphasis>. 1997.<!-- <br> --> <ulink
|
||||
URL="http://www.de.FreeBSD.ORG/de/ftp/releases/">http://www.de.FreeBSD.ORG/de/ftp/releases/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Networked Computer Science Technical Reports
|
||||
Library</emphasis>.<!-- <br> --> <ulink
|
||||
URL="http://www.ncstrl.org/">http://www.ncstrl.org/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Magazines and Journals</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The C/C++ Users Journal</emphasis>. R&D
|
||||
Publications Inc. ISSN 1075-2838</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Sys Admin — The Journal for UNIX System
|
||||
Administrators</emphasis> Miller Freeman, Inc., ISSN
|
||||
1061-2688</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
File diff suppressed because it is too large
Load diff
47
en_US.ISO8859-1/books/handbook/chapters.ent
Normal file
47
en_US.ISO8859-1/books/handbook/chapters.ent
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
<!--
|
||||
Creates entities for each chapter in the FreeBSD Handbook. Each entity
|
||||
is named chap.foo, where foo is the value of the id attribute on that
|
||||
chapter, and corresponds to the name of the directory in which that
|
||||
chapter's .sgml file is stored.
|
||||
|
||||
Chapters should be listed in the order in which they are referenced.
|
||||
|
||||
$Id: chapters.ent,v 1.1 1998-11-03 23:16:38 nik Exp $
|
||||
-->
|
||||
|
||||
<!-- Part one -->
|
||||
<!ENTITY chap.introduction SYSTEM "introduction/chapter.sgml">
|
||||
<!ENTITY chap.install SYSTEM "install/chapter.sgml">
|
||||
<!ENTITY chap.basics SYSTEM "basics/chapter.sgml">
|
||||
<!ENTITY chap.ports SYSTEM "ports/chapter.sgml">
|
||||
|
||||
<!-- Part two -->
|
||||
<!ENTITY chap.kernelconfig SYSTEM "kernelconfig/chapter.sgml">
|
||||
<!ENTITY chap.security SYSTEM "security/chapter.sgml">
|
||||
<!ENTITY chap.printing SYSTEM "printing/chapter.sgml">
|
||||
<!ENTITY chap.quotas SYSTEM "quotas/chapter.sgml">
|
||||
<!ENTITY chap.x11 SYSTEM "x11/chapter.sgml">
|
||||
<!ENTITY chap.hw SYSTEM "hw/chapter.sgml">
|
||||
<!ENTITY chap.l10n SYSTEM "l10n/chapter.sgml">
|
||||
|
||||
<!-- Part three -->
|
||||
<!ENTITY chap.serialcomms SYSTEM "serialcomms/chapter.sgml">
|
||||
<!ENTITY chap.ppp-and-slip SYSTEM "ppp-and-slip/chapter.sgml">
|
||||
<!ENTITY chap.advanced-networking SYSTEM "advanced-networking.sgml">
|
||||
<!ENTITY chap.mail SYSTEM "mail/chapter.sgml">
|
||||
|
||||
<!-- Part four -->
|
||||
<!ENTITY chap.cutting-edge SYSTEM "cutting-edge/chapter.sgml">
|
||||
<!ENTITY chap.contrib SYSTEM "contrib/chapter.sgml">
|
||||
<!ENTITY chap.policies SYSTEM "policies/chapter.sgml">
|
||||
<!ENTITY chap.kernelopts SYSTEM "kernelopts/chapter.sgml">
|
||||
<!ENTITY chap.kerneldebug SYSTEM "kerneldebug/chapter.sgml">
|
||||
<!ENTITY chap.linuxemu SYSTEM "linuxemu/chapter.sgml">
|
||||
<!ENTITY chap.internals SYSTEM "internals/chapter.sgml">
|
||||
|
||||
<!-- Part five (appendices) -->
|
||||
<!ENTITY chap.mirrors SYSTEM "mirrors/chapter.sgml">
|
||||
<!ENTITY chap.bibliography SYSTEM "bibliography/chapter.sgml">
|
||||
<!ENTITY chap.eresources SYSTEM "eresources/chapter.sgml">
|
||||
<!ENTITY chap.staff SYSTEM "staff/chapter.sgml">
|
||||
<!ENTITY chap.pgpkeys SYSTEM "pgpkeys/chapter.sgml">
|
||||
4901
en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
Normal file
4901
en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
2088
en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
Normal file
2088
en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1173
en_US.ISO8859-1/books/handbook/eresources/chapter.sgml
Normal file
1173
en_US.ISO8859-1/books/handbook/eresources/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
6323
en_US.ISO8859-1/books/handbook/hw/chapter.sgml
Normal file
6323
en_US.ISO8859-1/books/handbook/hw/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1212
en_US.ISO8859-1/books/handbook/install/chapter.sgml
Normal file
1212
en_US.ISO8859-1/books/handbook/install/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
611
en_US.ISO8859-1/books/handbook/introduction/chapter.sgml
Normal file
611
en_US.ISO8859-1/books/handbook/introduction/chapter.sgml
Normal file
|
|
@ -0,0 +1,611 @@
|
|||
<chapter id="introduction">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>FreeBSD is a 4.4BSD-Lite based operating system for Intel
|
||||
architecture (x86) based PCs. For an overview of FreeBSD, see
|
||||
<xref linkend="nutshell" remap="FreeBSD in a nutshell">. For a
|
||||
history of the project, read <xref linkend="history" remap="a brief
|
||||
history of FreeBSD">. To see a description of the latest release,
|
||||
read <xref linkend="relnotes" remap="about the current
|
||||
release">. If you're interested in contributing something to the
|
||||
FreeBSD project (code, equipment, sacks of unmarked bills), please see
|
||||
about <xref linkend="contrib"
|
||||
remap="contributing to FreeBSD">.</para>
|
||||
|
||||
|
||||
<sect1 id="nutshell">
|
||||
<title>FreeBSD in a Nutshell</title>
|
||||
|
||||
<para>FreeBSD is a state of the art operating system for personal
|
||||
computers based on the Intel CPU architecture, which includes the
|
||||
386, 486 and Pentium processors (both SX and DX versions). Intel
|
||||
compatible CPUs from AMD and Cyrix are supported as well. FreeBSD
|
||||
provides you with many advanced features previously available only
|
||||
on much more expensive computers. These features include:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Preemptive multitasking</emphasis> with
|
||||
dynamic priority adjustment to ensure smooth and fair sharing
|
||||
of the computer between applications and users.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Multiuser</emphasis> access means that
|
||||
many people can use a FreeBSD system simultaneously for a
|
||||
variety of things. System peripherals such as printers and
|
||||
tape drives are also properly SHARED BETWEEN ALL users on the
|
||||
system.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Complete <emphasis>TCP/IP networking</emphasis>
|
||||
including SLIP, PPP, NFS and NIS support. This means that
|
||||
your FreeBSD machine can inter-operate easily with other
|
||||
systems as well act as an enterprise server, providing vital
|
||||
functions such as NFS (remote file access) and e-mail services
|
||||
or putting your organization on the Internet with WWW, ftp,
|
||||
routing and firewall (security) services.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Memory protection</emphasis> ensures
|
||||
that applications (or users) cannot interfere with each other.
|
||||
One application crashing will not affect others in any
|
||||
way.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD is a <emphasis>32-bit</emphasis>
|
||||
operating system and was designed as such from the ground
|
||||
up.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The industry standard <emphasis>X Window
|
||||
System</emphasis> (X11R6) provides a graphical user
|
||||
interface (GUI) for the cost of a common VGA card and monitor
|
||||
and comes with full sources.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Binary compatibility</emphasis> with
|
||||
many programs built for SCO, BSDI, NetBSD, Linux and
|
||||
386BSD.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hundreds of <emphasis>ready-to-run</emphasis>
|
||||
applications are available from the FreeBSD <emphasis>ports</emphasis> and <emphasis>packages</emphasis> collection. Why search the net
|
||||
when you can find it all right here?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Thousands of additional and <emphasis>easy-to-port</emphasis> applications available on
|
||||
the Internet. FreeBSD is source code compatible with most
|
||||
popular commercial Unix systems and thus most applications
|
||||
require few, if any, changes to compile.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Demand paged <emphasis>virtual memory</emphasis>
|
||||
and “merged VM/buffer cache” design efficiently satisfies
|
||||
applications with large appetites for memory while still
|
||||
maintaining interactive response to other users.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Shared libraries</emphasis> (the Unix
|
||||
equivalent of MS-Windows DLLs) provide for efficient use of
|
||||
disk space and memory.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A full compliment of <emphasis>C</emphasis>,
|
||||
<emphasis>C++</emphasis> and <emphasis>Fortran</emphasis> development tools. Many
|
||||
additional languages for advanced research and development are
|
||||
also available in the ports and packages collection.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Source code</emphasis> for the entire
|
||||
system means you have the greatest degree of control over your
|
||||
environment. Why be locked into a proprietary solution and at
|
||||
the mercy of your vendor when you can have a truly Open
|
||||
System?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Extensive <emphasis>on-line
|
||||
documentation</emphasis>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>And many more!</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>FreeBSD is based on the 4.4BSD-Lite release from Computer
|
||||
Systems Research Group (CSRG) at the University of California at
|
||||
Berkeley, and carries on the distinguished tradition of BSD systems
|
||||
development. In addition to the fine work provided by CSRG, the
|
||||
FreeBSD Project has put in many thousands of hours in fine tuning
|
||||
the system for maximum performance and reliability in real-life load
|
||||
situations. As many of the commercial giants struggle to field PC
|
||||
operating systems with such features, performance and reliability,
|
||||
FreeBSD can offer them <emphasis>now</emphasis>!</para>
|
||||
|
||||
<para>The applications to which FreeBSD can be put are truly limited
|
||||
only by your own imagination. From software development to factory
|
||||
automation, inventory control to azimuth correction of remote
|
||||
satellite antennae; if it can be done with a commercial UNIX product
|
||||
then it is more than likely that you can do it with FreeBSD, too!
|
||||
FreeBSD also benefits significantly from the literally thousands of
|
||||
high quality applications developed by research centers and
|
||||
universities around the world, often available at little to no cost.
|
||||
Commercial applications are also available and appearing in greater
|
||||
numbers every day.</para>
|
||||
|
||||
<para>Because the source code for FreeBSD itself is generally
|
||||
available, the system can also be customized to an almost unheard of
|
||||
degree for special applications or projects, and in ways not
|
||||
generally possible with operating systems from most major commercial
|
||||
vendors. Here is just a sampling of some of the applications in
|
||||
which people are currently using FreeBSD:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Internet Services:</emphasis> The
|
||||
robust TCP/IP networking built into FreeBSD makes it an ideal
|
||||
platform for a variety of Internet services such as:</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>FTP servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>World Wide Web servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Gopher servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Electronic Mail servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>USENET News</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Bulletin Board Systems</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>And more...</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>You can easily start out small with an
|
||||
inexpensive 386 class PC and upgrade as your enterprise
|
||||
grows.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Education:</emphasis> Are you a student
|
||||
of computer science or a related engineering field? There is
|
||||
no better way of learning about operating systems, computer
|
||||
architecture and networking than the hands on, under the hood
|
||||
experience that FreeBSD can provide. A number of freely
|
||||
available CAD, mathematical and graphic design packages also
|
||||
make it highly useful to those whose primary interest in a
|
||||
computer is to get <emphasis>other</emphasis> work
|
||||
done!</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Research:</emphasis> With source code
|
||||
for the entire system available, FreeBSD is an excellent
|
||||
platform for research in operating systems as well as other
|
||||
branches of computer science. FreeBSD's freely available
|
||||
nature also makes it possible for remote groups to collaborate
|
||||
on ideas or shared development without having to worry about
|
||||
special licensing agreements or limitations on what may be
|
||||
discussed in open forums.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Networking:</emphasis> Need a new
|
||||
router? A name server (DNS)? A firewall to keep people out
|
||||
of your internal network? FreeBSD can easily turn that unused
|
||||
386 or 486 PC sitting in the corner into an advanced router
|
||||
with sophisticated packet filtering capabilities.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>X Window workstation:</emphasis>
|
||||
FreeBSD is a fine choice for an inexpensive X terminal
|
||||
solution, either using the freely available XFree86 server or
|
||||
one of the excellent commercial servers provided by X Inside.
|
||||
Unlike an X terminal, FreeBSD allows many applications to be
|
||||
run locally, if desired, thus relieving the burden on a
|
||||
central server. FreeBSD can even boot “diskless”, making
|
||||
individual workstations even cheaper and easier to
|
||||
administer.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Software Development:</emphasis> The
|
||||
basic FreeBSD system comes with a full compliment of
|
||||
development tools including the renowned GNU C/C++ compiler
|
||||
and debugger.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>FreeBSD is available in both source and binary form on CDROM and
|
||||
via anonymous ftp. See <xref linkend="mirrors" remap="Obtaining
|
||||
FreeBSD"> for more details.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="history">
|
||||
<title>A Brief History of FreeBSD</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jkh;</emphasis>.</para>
|
||||
|
||||
<para>The FreeBSD project had its genesis in the early part of 1993,
|
||||
partially as an outgrowth of the “Unofficial 386BSD Patchkit” by the
|
||||
patchkit's last 3 coordinators: Nate Williams, Rod Grimes and
|
||||
myself.</para>
|
||||
|
||||
<para>Our original goal was to produce an intermediate snapshot of
|
||||
386BSD in order to fix a number of problems with it that the
|
||||
patchkit mechanism just was not capable of solving. Some of you may
|
||||
remember the early working title for the project being “386BSD 0.5”
|
||||
or “386BSD Interim” in reference to that fact.</para>
|
||||
|
||||
<para>386BSD was Bill Jolitz's operating system, which had been up to
|
||||
that point suffering rather severely from almost a year's worth of
|
||||
neglect. As the patchkit swelled ever more uncomfortably with each
|
||||
passing day, we were in unanimous agreement that something had to be
|
||||
done and decided to try and assist Bill by providing this interim
|
||||
“cleanup” snapshot. Those plans came to a rude halt when Bill
|
||||
Jolitz suddenly decided to withdraw his sanction from the project
|
||||
and without any clear indication of what would be done
|
||||
instead.</para>
|
||||
|
||||
<para>It did not take us long to decide that the goal remained
|
||||
worthwhile, even without Bill's support, and so we adopted the name
|
||||
“FreeBSD”, coined by David Greenman. Our initial objectives were
|
||||
set after consulting with the system's current users and, once it
|
||||
became clear that the project was on the road to perhaps even
|
||||
becoming a reality, I contacted Walnut Creek CDROM with an eye
|
||||
towards improving FreeBSD's distribution channels for those many
|
||||
unfortunates without easy access to the Internet. Walnut Creek
|
||||
CDROM not only supported the idea of distributing FreeBSD on CD but
|
||||
went so far as to provide the project with a machine to work on and
|
||||
a fast Internet connection. Without Walnut Creek CDROM's almost
|
||||
unprecedented degree of faith in what was, at the time, a completely
|
||||
unknown project, it is quite unlikely that FreeBSD would have gotten
|
||||
as far, as fast, as it has today.</para>
|
||||
|
||||
<para>The first CDROM (and general net-wide) distribution was FreeBSD
|
||||
1.0, released in December of 1993. This was based on the
|
||||
4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components
|
||||
also provided by 386BSD and the Free Software Foundation. It was a
|
||||
fairly reasonable success for a first offering, and we followed it
|
||||
with the highly successful FreeBSD 1.1 release in May of
|
||||
1994.</para>
|
||||
|
||||
<para>Around this time, some rather unexpected storm clouds formed on
|
||||
the horizon as Novell and U.C. Berkeley settled their long-running
|
||||
lawsuit over the legal status of the Berkeley Net/2 tape. A
|
||||
condition of that settlement was U.C. Berkeley's concession that
|
||||
large parts of Net/2 were “encumbered” code and the property of
|
||||
Novell, who had in turn acquired it from AT&T some time
|
||||
previously. What Berkeley got in return was Novell's “blessing”
|
||||
that the 4.4BSD-Lite release, when it was finally released, would be
|
||||
declared unencumbered and all existing Net/2 users would be strongly
|
||||
encouraged to switch. This included FreeBSD, and the project was
|
||||
given until the end of July 1994 to stop shipping its own Net/2
|
||||
based product. Under the terms of that agreement, the project was
|
||||
allowed one last release before the deadline, that release being
|
||||
FreeBSD 1.1.5.1.</para>
|
||||
|
||||
<para>FreeBSD then set about the arduous task of literally
|
||||
re-inventing itself from a completely new and rather incomplete set
|
||||
of 4.4BSD-Lite bits. The “Lite” releases were light in part because
|
||||
Berkeley's CSRG had removed large chunks of code required for
|
||||
actually constructing a bootable running system (due to various
|
||||
legal requirements) and the fact that the Intel port of 4.4 was
|
||||
highly incomplete. It took the project until December of 1994 to
|
||||
make this transition, and in January of 1995 it released FreeBSD 2.0
|
||||
to the net and on CDROM. Despite being still more than a little
|
||||
rough around the edges, the release was a significant success and
|
||||
was followed by the more robust and easier to install FreeBSD 2.0.5
|
||||
release in June of 1995.</para>
|
||||
|
||||
<para>We released FreeBSD 2.1.5 in August of 1996, and it appeared to
|
||||
be popular enough among the ISP and commercial communities that
|
||||
another release along the 2.1-stable branch was merited. This was
|
||||
FreeBSD 2.1.7.1, released in February 1997 and capping the end of
|
||||
mainstream development on 2.1-stable. Now in maintenance mode, only
|
||||
security enhancements and other critical bug fixes will be done on
|
||||
this branch (RELENG_2_1_0).</para>
|
||||
|
||||
<para>FreeBSD 2.2 was branched from the development mainline
|
||||
(“-current”) in November 1996 as the RELENG_2_2 branch, and the
|
||||
first full release (2.2.1) was released in April, 1997. Further
|
||||
releases along the 2.2 branch were done in the Summer and Fall of
|
||||
'97, the latest being 2.2.6 which appeared in late March of '98.
|
||||
The first official 3.0 release will appear later in 1998.</para>
|
||||
|
||||
<para>Long term development projects for everything from SMP to DEC
|
||||
ALPHA support will continue to take place in the 3.0-current branch
|
||||
and SNAPshot releases of 3.0 on CDROM (and, of course, on the net).</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="goals">
|
||||
<title>FreeBSD Project Goals</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jkh;</emphasis>.</para>
|
||||
|
||||
<para>The goals of the FreeBSD Project are to provide software that
|
||||
may be used for any purpose and without strings attached. Many of
|
||||
us have a significant investment in the code (and project) and would
|
||||
certainly not mind a little financial compensation now and then, but
|
||||
we're definitely not prepared to insist on it. We believe that our
|
||||
first and foremost “mission” is to provide code to any and all
|
||||
comers, and for whatever purpose, so that the code gets the widest
|
||||
possible use and provides the widest possible benefit. This is, I
|
||||
believe, one of the most fundamental goals of Free Software and one
|
||||
that we enthusiastically support.</para>
|
||||
|
||||
<para>That code in our source tree which falls under the GNU Public
|
||||
License (GPL) or GNU Library Public License (GLPL) comes with
|
||||
slightly more strings attached, though at least on the side of
|
||||
enforced access rather than the usual opposite. Due to the
|
||||
additional complexities that can evolve in the commercial use of GPL
|
||||
software, we do, however, endeavor to replace such software with
|
||||
submissions under the more relaxed BSD copyright whenever possible.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="development">
|
||||
<title>The FreeBSD Development Model</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.asami;</emphasis>.</para>
|
||||
|
||||
<para>The development of FreeBSD is a very open and flexible process,
|
||||
FreeBSD being literally built from the contributions of hundreds of
|
||||
people around the world, as can be seen from our <xref
|
||||
linkend="staff" remap="list of contributors">. We are constantly
|
||||
on the lookout for new developers and ideas, and those interested in
|
||||
becoming more closely involved with the project need simply contact
|
||||
us at the &a.hackers;. Those who prefer to work more independently
|
||||
are also accommodated, and they are free to use our FTP facilities
|
||||
at <ulink
|
||||
URL="ftp://ftp.freebsd.org/pub/FreeBSD/incoming">ftp.freebsd.org</ulink> to distribute their own patches or work-in-progress sources. The &a.announce; is also available to those wishing to make other FreeBSD users aware of major areas of work.</para>
|
||||
|
||||
<para>Useful things to know about the FreeBSD project and its
|
||||
development process, whether working independently or in close
|
||||
cooperation:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>The CVS
|
||||
repository<anchor id="development-cvs-repository"></term>
|
||||
<listitem>
|
||||
<para>The central source tree for FreeBSD is maintained by
|
||||
<ulink
|
||||
URL="http://www.cyclic.com/cyclic-pages/CVS-sheet.html">CVS</ulink> (Concurrent Version System), a freely available source code control tool which comes bundled with FreeBSD. The primary <ulink URL="http://www.freebsd.org/cgi/cvsweb.cgi">CVS repository</ulink> resides on a machine in Concord CA, USA from where it is replicated to numerous mirror machines throughout the world. The CVS tree, as well as the <xref linkend="current" remap="-current"> and <xref
|
||||
linkend="stable" remap="-stable"> trees which are checked
|
||||
out of it, can be easily replicated to your own machine as
|
||||
well. Please refer to the
|
||||
<xref linkend="synching" remap="Synchronizing your source
|
||||
tree"> section for more information on doing this.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The committers
|
||||
list<anchor id="development-committers"></term>
|
||||
|
||||
<listitem>
|
||||
<para>The <xref linkend="staff-committers" remap="committers">
|
||||
are the people who have <emphasis>write</emphasis> access to
|
||||
the CVS tree, and are thus authorized to make modifications
|
||||
to the FreeBSD source (the term “committer” comes from the
|
||||
<citerefentry><refentrytitle>cvs</refentrytitle><manvolnum>1</manvolnum></citerefentry> <command>commit</command> command, which is used to
|
||||
bring new changes into the CVS repository). The best way of
|
||||
making submissions for review by the committers list is to
|
||||
use the <citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry> command, though if something appears to be jammed in the system then you may also reach them by sending mail to <email>committers@freebsd.org</email>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The FreeBSD core
|
||||
team<anchor id="development-core"></term>
|
||||
|
||||
<listitem>
|
||||
<para>The <xref linkend="staff-core" remap="FreeBSD core
|
||||
team"> would be equivalent to the board of directors if
|
||||
the FreeBSD Project were a company. The primary task of the
|
||||
core team is to make sure the project, as a whole, is in
|
||||
good shape and is heading in the right directions. Inviting
|
||||
dedicated and responsible developers to join our group of
|
||||
committers is one of the functions of the core team, as is
|
||||
the recruitment of new core team members as others move on.
|
||||
Most current members of the core team started as committers
|
||||
who's addiction to the project got the better of
|
||||
them.</para>
|
||||
|
||||
<para>Some core team members also have specific <xref
|
||||
linkend="staff-who" remap="areas of responsibility">,
|
||||
meaning that they are committed to ensuring that some large
|
||||
portion of the system works as advertised.</para>
|
||||
|
||||
<note>
|
||||
<para>Most members of the core team are volunteers when it
|
||||
comes to FreeBSD development and do not benefit from the
|
||||
project financially, so “commitment” should also not be
|
||||
misconstrued as meaning “guaranteed support.” The
|
||||
“board of directors” analogy above is not
|
||||
actually very accurate, and it may be more suitable to say
|
||||
that these are the people who gave up their lives in favor
|
||||
of FreeBSD against their better judgement! <!-- smiley --><emphasis>;)</emphasis></para>
|
||||
</note>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Outside
|
||||
contributors</term>
|
||||
|
||||
<listitem>
|
||||
<para>Last, but definitely not least, the largest group of
|
||||
developers are the users themselves who provide feedback and
|
||||
bug-fixes to us on an almost constant basis. The primary
|
||||
way of keeping in touch with FreeBSD's more non-centralized
|
||||
development is to subscribe to the &a.hackers; (see <xref
|
||||
linkend="eresources-mail" remap="mailing list
|
||||
info">) where such things are discussed.</para>
|
||||
|
||||
<para><xref linkend="contrib-additional" remap="The list"> of
|
||||
those who have contributed something which made its way into
|
||||
our source tree is a long and growing one, so why not join
|
||||
it by contributing something back to FreeBSD today?
|
||||
<!-- smiley --><emphasis>:-)</emphasis></para>
|
||||
|
||||
<para>Providing code is not the only way of contributing to
|
||||
the project; for a more complete list of things that need
|
||||
doing, please refer to the <xref linkend="contrib"
|
||||
remap="how to
|
||||
contribute"> section in this handbook.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
<para>In summary, our development model is organized as a loose set of
|
||||
concentric circles. The centralized model is designed for the
|
||||
convenience of the <emphasis>users</emphasis> of FreeBSD, who are
|
||||
thereby provided with an easy way of tracking one central code base,
|
||||
not to keep potential contributors out! Our desire is to present a
|
||||
stable operating system with a large set of coherent <xref
|
||||
linkend="ports"
|
||||
remap="application programs"> that the users can easily install
|
||||
and use, and this model works very well in accomplishing
|
||||
that.</para>
|
||||
|
||||
<para>All we ask of those who would join us as FreeBSD developers is
|
||||
some of the same dedication its current people have to its continued
|
||||
success!</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="relnotes">
|
||||
<title>About the Current Release</title>
|
||||
|
||||
<para>FreeBSD is a freely available, full source 4.4BSD-Lite based
|
||||
release for Intel i386/i486/Pentium/PentiumPro/Pentium II (or
|
||||
compatible) based PC's. It is based primarily on software from U.C.
|
||||
Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD,
|
||||
386BSD, and the Free Software Foundation.</para>
|
||||
|
||||
<para>Since our release of FreeBSD 2.0 in January of 95, the
|
||||
performance, feature set, and stability of FreeBSD has improved
|
||||
dramatically. The largest change is a revamped virtual memory
|
||||
system with a merged VM/file buffer cache that not only increases
|
||||
performance, but reduces FreeBSD's memory footprint, making a 5MB
|
||||
configuration a more acceptable minimum. Other enhancements include
|
||||
full NIS client and server support, transaction TCP support,
|
||||
dial-on-demand PPP, an improved SCSI subsystem, early ISDN support,
|
||||
support for FDDI and Fast Ethernet (100Mbit) adapters, improved
|
||||
support for the Adaptec 2940 (WIDE and narrow) and many hundreds of
|
||||
bug fixes.</para>
|
||||
|
||||
<para>We have also taken the comments and suggestions of many of our
|
||||
users to heart and have attempted to provide what we hope is a more
|
||||
sane and easily understood installation process. Your feedback on
|
||||
this (constantly evolving) process is especially welcome!</para>
|
||||
|
||||
<para>In addition to the base distributions, FreeBSD offers a new
|
||||
ported software collection with hundreds of commonly sought-after
|
||||
programs. At the end of March 1998 there were more than 1300 ports!
|
||||
The list of ports ranges from http (WWW) servers, to games,
|
||||
languages, editors and almost everything in between. The entire
|
||||
ports collection requires approximately 26MB of storage, all ports
|
||||
being expressed as “deltas” to their original sources. This
|
||||
makes it much easier for us to update ports, and greatly reduces
|
||||
the disk space demands made by the older 1.0 ports collection. To
|
||||
compile a port, you simply change to the directory of the program
|
||||
you wish to install, type <command>make all</command> followed by <command>make install</command>
|
||||
after successful compilation and let the system do the rest. The
|
||||
full original distribution for each port you build is retrieved
|
||||
dynamically off the CDROM or a local ftp site, so you need only
|
||||
enough disk space to build the ports you want. (Almost) every port
|
||||
is also provided as a pre-compiled “package” which can be installed
|
||||
with a simple command (pkg_add) by those who do not wish to compile
|
||||
their own ports from source.</para>
|
||||
|
||||
<para>A number of additional documents which you may find very helpful
|
||||
in the process of installing and using FreeBSD may now also be found
|
||||
in the <filename>/usr/share/doc</filename> directory on any machine
|
||||
running FreeBSD 2.1 or later. You may view the locally installed
|
||||
manuals with any HTML capable browser using the following
|
||||
URLs:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>The FreeBSD handbook</term>
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="file:/usr/share/doc/handbook/handbook.html">file:/usr/share/doc/handbook/handbook.html</ulink></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The FreeBSD FAQ</term>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="file:/usr/share/doc/FAQ/FAQ.html">file:/usr/share/doc/FAQ/FAQ.html</ulink></para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
<para>You can also visit the master (and most frequently updated)
|
||||
copies at <ulink
|
||||
URL="http://www.freebsd.org">http://www.freebsd.org</ulink>.</para>
|
||||
|
||||
<para>The core of FreeBSD does not contain DES code which would
|
||||
inhibit its being exported outside the United States. There is an
|
||||
add-on package to the core distribution, for use only in the United
|
||||
States, that contains the programs that normally use DES. The
|
||||
auxiliary packages provided separately can be used by anyone. A
|
||||
freely (from outside the U.S.) exportable European distribution of
|
||||
DES for our non-U.S. users also exists and is described in the
|
||||
<ulink URL="../FAQ/FAQ.html">FreeBSD FAQ</ulink>.</para>
|
||||
|
||||
<para>If password security for FreeBSD is all you need, and you have
|
||||
no requirement for copying encrypted passwords from different hosts
|
||||
(Suns, DEC machines, etc) into FreeBSD password entries, then
|
||||
FreeBSD's MD5 based security may be all you require! We feel that
|
||||
our default security model is more than a match for DES, and without
|
||||
any messy export issues to deal with. If you are outside (or even
|
||||
inside) the U.S., give it a try!</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
1711
en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml
Normal file
1711
en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
634
en_US.ISO8859-1/books/handbook/kerneldebug/chapter.sgml
Normal file
634
en_US.ISO8859-1/books/handbook/kerneldebug/chapter.sgml
Normal file
|
|
@ -0,0 +1,634 @@
|
|||
<chapter id="kerneldebug">
|
||||
<title>Kernel Debugging</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.paul; and &a.joerg;</emphasis></para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Debugging a Kernel Crash Dump with <command>kgdb</command></title>
|
||||
|
||||
<para>Here 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 <literal>config
|
||||
kernel</literal> line), or you can specify an alternate using the
|
||||
<citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command. Dumps to non-swap devices, tapes for example,
|
||||
are currently not supported. Config your kernel using
|
||||
<command>config -g</command>. See <xref linkend="kernelconfig"
|
||||
remap="Kernel Configuration"> for
|
||||
details on configuring the FreeBSD kernel.</para>
|
||||
|
||||
<para>Use the <citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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
|
||||
<citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>). This is normally arranged via
|
||||
<filename>/etc/rc.conf</filename> and <filename>/etc/rc</filename>.
|
||||
Alternatively, you can hard-code the dump device via the <literal>dump</literal>
|
||||
clause in the <literal>config</literal> 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.</para>
|
||||
|
||||
<note>
|
||||
<para>In the following, the term <command>kgdb</command> refers to
|
||||
<command>gdb</command> run in “kernel debug mode”. This can be
|
||||
accomplished by either starting the <command>gdb</command> with
|
||||
the option <option>-k</option>, or by linking and starting it
|
||||
under the name <command>kgdb</command>. 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.</para>
|
||||
</note>
|
||||
|
||||
<para>When the kernel has been built make a copy of it, say
|
||||
<filename>kernel.debug</filename>, and then run <command>strip
|
||||
-d</command> 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.</para>
|
||||
|
||||
<para>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 <option>-s</option> flag at the boot
|
||||
prompt, and then perform the following steps:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>fsck -p</userinput>
|
||||
&prompt.root; <userinput>mount -a -t ufs</userinput> # so your file system for /var/crash is writable
|
||||
&prompt.root; <userinput>savecore -N /kernel.panicked /var/crash</userinput>
|
||||
&prompt.root; <userinput>exit</userinput> # ...to multi-user</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This instructs <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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.</para>
|
||||
|
||||
<para>Now, after a crash dump, go to
|
||||
<filename>/sys/compile/WHATEVER</filename> and run <command>kgdb</command>. From <command>kgdb</command>
|
||||
do:
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>symbol-file kernel.debug</userinput>
|
||||
<userinput>exec-file /var/crash/kernel.0</userinput>
|
||||
<userinput>core-file /var/crash/vmcore.0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
and voila, you can debug the crash dump using the
|
||||
kernel sources just like you can for any other program.</para>
|
||||
|
||||
<para>Here is a script log of a <command>kgdb</command>
|
||||
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.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen> 1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:&prompt.root; <userinput>cd /sys/compile/URIAH</userinput>
|
||||
3:&prompt.root; <userinput>kgdb kernel /var/crash/vmcore.1</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>where</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up 10</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>frame frame->tf_ebp frame->tf_eip</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>list</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>print tp</userinput>
|
||||
53:Reading in symbols for ../../i386/i386/cons.c...done.
|
||||
54:$1 = (struct tty *) 0x1bae
|
||||
55:<prompt>(kgdb)</prompt> <userinput>print tp->t_line</userinput>
|
||||
56:$2 = 1767990816
|
||||
57:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
62:#2 0xf0132c34 in spec_open ()
|
||||
63:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
64:#3 0xf012d014 in vn_open ()
|
||||
65:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
66:#4 0xf012a183 in open ()
|
||||
67:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
75:Initial frame selected; you cannot go up.
|
||||
76:<prompt>(kgdb)</prompt> <userinput>quit</userinput>
|
||||
77:&prompt.root; <userinput>exit</userinput>
|
||||
78:exit
|
||||
79:
|
||||
80:Script done on Fri Dec 30 23:18:04 1994</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Comments to the above script:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>line 6:</term>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 20:</term>
|
||||
|
||||
<listitem>
|
||||
<para>This is the location of function
|
||||
<function>trap()</function> in the stack trace.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 36:</term>
|
||||
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 52:</term>
|
||||
|
||||
<listitem>
|
||||
<para>The pointer looks suspicious, but happens to be a valid
|
||||
address.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 56:</term>
|
||||
|
||||
<listitem>
|
||||
<para>However, it obviously points to garbage, so we have
|
||||
found our error! (For those unfamiliar with that particular
|
||||
piece of code: <literal>tp->t_line</literal>
|
||||
refers to the line discipline of the console device here,
|
||||
which must be a rather small integer number.)</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Post-mortem Analysis of a Dump</title>
|
||||
|
||||
<para>What do you do if a kernel dumped core but you did not expect
|
||||
it, and it is therefore not compiled using <command>config
|
||||
-g</command>? Not everything is lost here. Do not panic!</para>
|
||||
|
||||
<para>Of course, you still need to enable crash dumps. See above on
|
||||
the options you have to specify in order to do this.</para>
|
||||
|
||||
<para>Go to your kernel compile directory, and edit the line
|
||||
containing <literal>COPTFLAGS?=-O</literal>. Add the
|
||||
<option>-g</option> option there (but <emphasis>do not</emphasis>
|
||||
change anything on the level of optimization). If you do already
|
||||
know roughly the probable location of the failing piece of code
|
||||
(e.g., the <devicename>pcvt</devicename> driver in the example
|
||||
above), remove all the object files for this code. Rebuild the
|
||||
kernel. Due to the time stamp change on the Makefile, there will be
|
||||
some other object files rebuild, for example
|
||||
<filename>trap.o</filename>. With a bit of luck, the added
|
||||
<option>-g</option> 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
|
||||
<citerefentry><refentrytitle>size</refentrytitle><manvolnum>1</manvolnum></citerefentry> command. If there is a mismatch, you
|
||||
probably need to give up here.</para>
|
||||
|
||||
<para>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
|
||||
<command>kgdb</command> session until you know
|
||||
enough.</para>
|
||||
|
||||
<para>All this is not guaranteed to work, but it will do it fine in
|
||||
most cases.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>On-line Kernel Debugging Using DDB</title>
|
||||
|
||||
<para>While <command>kgdb</command> 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.</para>
|
||||
|
||||
<para>If you need to do low-level debugging on your kernel, there is
|
||||
an on-line debugger available called DDB. It allows to setting
|
||||
breakpoints, single-steping kernel functions, examining and changing
|
||||
kernel variables, etc. However, it cannot access kernel source
|
||||
files, and only has access to the global and static symbols, not to
|
||||
the full debug information like <command>kgdb</command>.</para>
|
||||
|
||||
<para>To configure your kernel to include DDB, add the option line
|
||||
|
||||
<programlisting>
|
||||
options DDB</programlisting> to your config file, and rebuild. (See <xref
|
||||
linkend="kernelconfig"
|
||||
remap="Kernel Configuration"> for details on configuring the
|
||||
FreeBSD kernel.</para>
|
||||
|
||||
<note>
|
||||
<para>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.)</para>
|
||||
</note>
|
||||
|
||||
<para>Once your DDB kernel is running, there are several ways to enter
|
||||
DDB. The first, and earliest way is to type the boot flag
|
||||
<option>-d</option> 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.</para>
|
||||
|
||||
<para>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 (<literal>options
|
||||
BREAK_TO_DEBUGGER</literal> 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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The DDB commands roughly resemble some <command>gdb</command> commands. The first thing you probably
|
||||
need to do is to set a breakpoint:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>b function-name</userinput>
|
||||
<userinput>b address</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Numbers are taken hexadecimal by default, but to make them
|
||||
distinct from symbol names; hexadecimal numbers starting with the
|
||||
letters <literal>a-f</literal> need to be preceded with
|
||||
<literal>0x</literal> (this is optional for other numbers). Simple
|
||||
expressions are allowed, for example: <literal>function-name +
|
||||
0x103</literal>.</para>
|
||||
|
||||
<para>To continue the operation of an interrupted kernel, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>c</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To get a stack trace, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>trace</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>Note 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.</para>
|
||||
</note>
|
||||
|
||||
<para>If you want to remove a breakpoint, use</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>del</userinput>
|
||||
<userinput>del address-expression</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The first form will be accepted immediately after
|
||||
a breakpoint hit, and deletes the current breakpoint. The second
|
||||
form can remove any breakpoint, but you need to specify the exact
|
||||
address; this can be obtained from:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>show b</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To single-step the kernel, try:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>s</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will step into functions, but you can make
|
||||
DDB trace them until the matching return statement is reached by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>n</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>This is different from <command>gdb</command>'s <command>next</command>
|
||||
statement; it is like <command>gdb</command>'s <command>finish</command>.</para>
|
||||
</note>
|
||||
|
||||
<para>To examine data from memory, use (for example):
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x/wx 0xf0133fe0,40</userinput>
|
||||
<userinput>x/hd db_symtab_space</userinput>
|
||||
<userinput>x/bc termbuf,10</userinput>
|
||||
<userinput>x/s stringbuf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x ,10</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Similarly, use
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x/ia foofunc,10</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
to disassemble the first 0x10 instructions of
|
||||
<function>foofunc</function>, and display them along with
|
||||
their offset from the beginning of <function>foofunc</function>.</para>
|
||||
|
||||
<para>To modify memory, use the write command:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>w/b termbuf 0xa 0xb 0</userinput>
|
||||
<userinput>w/w 0xf0010030 0 0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The command modifier
|
||||
(<literal>b</literal>/<literal>h</literal>/<literal>w</literal>) 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.</para>
|
||||
|
||||
<para>If you need to know the current registers, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>show reg</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Alternatively, you can display a single register
|
||||
value by e.g.
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>p $eax</userinput></screen>
|
||||
</informalexample> and modify it by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>set $eax new-value</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Should you need to call some kernel functions from DDB, simply
|
||||
say:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call func(arg1, arg2, ...)</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The return value will be printed.</para>
|
||||
|
||||
<para>For a <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> style summary of all running
|
||||
processes, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>ps</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now 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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call diediedie()</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>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 <command>continue</command> statement. There is now an alias for
|
||||
this: <command>panic</command>.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call boot(0)</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Which might be a good way to cleanly shut down the
|
||||
running system, <function>sync()</function> 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.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call cpu_reset()</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>is the final way out of disaster and almost the
|
||||
same as hitting the Big Red Button.</para>
|
||||
|
||||
<para>If you need a short command summary, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>help</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>However, it is highly recommended to have a
|
||||
printed copy of the <citerefentry><refentrytitle>ddb</refentrytitle><manvolnum>4</manvolnum></citerefentry> manual page
|
||||
ready for a debugging session. Remember that it is hard to read the
|
||||
on-line manual while single-stepping the kernel.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>On-line Kernel Debugging Using Remote GDB</title>
|
||||
|
||||
<para>This feature has been supported since FreeBSD 2.2, and it's
|
||||
actually a very neat one.</para>
|
||||
|
||||
<para>GDB has already supported <emphasis>remote debugging</emphasis>
|
||||
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).</para>
|
||||
|
||||
<para>You should configure the kernel in question with <command>config
|
||||
-g</command>, include <option>DDB</option> 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 <command>strip
|
||||
-x</command>, and boot it using the <option>-d</option> 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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>gdb -k kernel</userinput>
|
||||
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...
|
||||
<prompt>(kgdb)</prompt> </screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Initialize the remote debugging session (assuming the first
|
||||
serial port is being used) by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>(kgdb)</prompt> <userinput>target remote /dev/cuaa0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now, on the target host (the one that entered DDB right before
|
||||
even starting the device probe), type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
<prompt>db></prompt> <userinput>gdb</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>DDB will respond with:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Next trap will enter GDB remote protocol mode</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Every time you type <command>gdb</command>, the mode will be toggled between
|
||||
remote GDB and local DDB. In order to force a next trap
|
||||
immediately, simply type <command>s</command> (step). Your hosting GDB will now
|
||||
gain control over the target kernel:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
at ../../i386/i386/db_interface.c:257
|
||||
<prompt>(kgdb)</prompt></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>Remote GDB can also be used to debug LKMs. First build the LKM
|
||||
with debugging symbols:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
|
||||
&prompt.root; <userinput>make clean; make COPTS=-g</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Then install this version of the module on the target machine,
|
||||
load it and use <command>modstat</command> to find out
|
||||
where it was loaded:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>linux</userinput>
|
||||
&prompt.root; <userinput>modstat</userinput>
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f5109000 001c f510f010 1 linux_mod</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Take 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 <command>add-symbol-file</command> command in GDB to tell the
|
||||
debugger about the module:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>(kgdb)</prompt> <userinput>add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020</userinput>
|
||||
add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
|
||||
text_addr = 0xf5109020? (y or n) <userinput>y</userinput>
|
||||
<prompt>(kgdb)</prompt></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You now have access to all the symbols in the LKM.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Debugging a Console Driver</title>
|
||||
|
||||
<para>Since 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 <option>-h</option> at the <prompt>Boot:</prompt> 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.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
161
en_US.ISO8859-1/books/handbook/kernelopts/chapter.sgml
Normal file
161
en_US.ISO8859-1/books/handbook/kernelopts/chapter.sgml
Normal file
|
|
@ -0,0 +1,161 @@
|
|||
<chapter id="kernelopts">
|
||||
<title>Adding New Kernel Configuration Options</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.joerg;</emphasis></para>
|
||||
|
||||
<note>
|
||||
<para>You should be familiar with the section about <xref
|
||||
linkend="kernelconfig" remap="kernel configuration">
|
||||
before reading here.</para>
|
||||
</note>
|
||||
|
||||
<sect1>
|
||||
<title>What's a <emphasis>Kernel Option</emphasis>, Anyway?</title>
|
||||
|
||||
<para>The use of kernel options is basically described in the <xref
|
||||
linkend="kernelconfig-options" remap="kernel configuration">
|
||||
section. There's also an explanation of “historic” and
|
||||
“new-style” options. The ultimate goal is to eventually turn all
|
||||
the supported options in the kernel into new-style ones, so for
|
||||
people who correctly did a <command>make depend</command>
|
||||
in their kernel compile directory after running
|
||||
<citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry>, the build process will automatically
|
||||
pick up modified options, and only recompile those files where it is
|
||||
necessary. Wiping out the old compile directory on each run of
|
||||
<citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> as it is still done now can then be
|
||||
eliminated again.</para>
|
||||
|
||||
<para>Basically, a kernel option is nothing else than the definition
|
||||
of a C preprocessor macro for the kernel compilation process. To
|
||||
make the build truly optional, the corresponding part of the kernel
|
||||
source (or kernel <filename>.h</filename> file) must be written with
|
||||
the option concept in mind, i.e. the default must have been made
|
||||
overridable by the config option. This is usually done with
|
||||
something like:</para>
|
||||
|
||||
<programlisting>
|
||||
#ifndef THIS_OPTION
|
||||
#define THIS_OPTION (some_default_value)
|
||||
#endif /* THIS_OPTION */</programlisting>
|
||||
|
||||
<para>This way, an administrator mentioning another value for the
|
||||
option in his config file will take the default out of effect, and
|
||||
replace it with his new value. Clearly, the new value will be
|
||||
substituted into the source code during the preprocessor run, so it
|
||||
must be a valid C expression in whatever context the default value
|
||||
would have been used.</para>
|
||||
|
||||
<para>It is also possible to create value-less options that simply
|
||||
enable or disable a particular piece of code by embracing it
|
||||
in</para>
|
||||
|
||||
<programlisting>
|
||||
#ifdef THAT_OPTION
|
||||
|
||||
[your code here]
|
||||
|
||||
#endif</programlisting>
|
||||
|
||||
<para>Simply mentioning <literal>THAT_OPTION</literal> in the config
|
||||
file (with or without any value) will then turn on the corresponding
|
||||
piece of code.</para>
|
||||
|
||||
<para>People familiar with the C language will immediately recognize
|
||||
that everything could be counted as a “config option” where there
|
||||
is at least a single <literal>#ifdef</literal>
|
||||
referencing it... However, it's unlikely that many people would
|
||||
put</para>
|
||||
|
||||
<programlisting>
|
||||
options notyet,notdef</programlisting>
|
||||
|
||||
<para>in their config file, and then wonder why the kernel compilation
|
||||
falls over. <!-- smiley -->:-)</para>
|
||||
|
||||
<para>Clearly, using arbitrary names for the options makes it very
|
||||
hard to track their usage throughout the kernel source tree. That
|
||||
is the rationale behind the <emphasis>new-style</emphasis> option
|
||||
scheme, where each option goes into a separate
|
||||
<filename>.h</filename> file in the kernel compile directory, which
|
||||
is by convention named
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename>. This way,
|
||||
the usual Makefile dependencies could be applied, and <command>make</command> can determine what needs to be recompiled
|
||||
once an option has been changed.</para>
|
||||
|
||||
<para>The old-style option mechanism still has one advantage for local
|
||||
options or maybe experimental options that have a short anticipated
|
||||
lifetime: since it is easy to add a new <literal>#ifdef</literal> to the kernel source, this has already
|
||||
made it a kernel config option. In this case, the administrator
|
||||
using such an option is responsible himself for knowing about its
|
||||
implications (and maybe manually forcing the recompilation of parts
|
||||
of his kernel). Once the transition of all supported options has
|
||||
been done, <citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> will warn whenever an
|
||||
unsupported option appears in the config file, but it will
|
||||
nevertheless include it into the kernel Makefile.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Now What Do I Have to Do for it?</title>
|
||||
|
||||
<para>First, edit <filename>sys/conf/options</filename> (or
|
||||
<filename>sys/i386/conf/options.<replaceable><arch></replaceable></filename>, e. g. <filename>sys/i386/conf/options.i386</filename>), and select an <filename>opt_<replaceable>foo</replaceable>.h</filename> file where your new option would best go into.</para>
|
||||
|
||||
<para>If there is already something that comes close to the purpose of
|
||||
the new option, pick this. For example, options modifying the
|
||||
overall behaviour of the SCSI subsystem can go into
|
||||
<filename>opt_scsi.h</filename>. By default, simply mentioning an
|
||||
option in the appropriate option file, say <literal>FOO</literal>,
|
||||
implies its value will go into the corresponding file
|
||||
<filename>opt_foo.h</filename>. This can be overridden on the
|
||||
right-hand side of a rule by specifying another filename.</para>
|
||||
|
||||
<para>If there is no
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> already
|
||||
available for the intended new option, invent a new name. Make it
|
||||
meaningful, and comment the new section in the
|
||||
<filename>options[<replaceable>.<arch></replaceable>]</filename> file. <citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> will automagically pick up the change, and create that file next time it is run. Most options should go in a header file by themselves..</para>
|
||||
|
||||
<para>Packing too many options into a single
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> will cause
|
||||
too many kernel files to be rebuilt when one of the options has been
|
||||
changed in the config file.</para>
|
||||
|
||||
<para>Finally, find out which kernel files depend on the new option.
|
||||
Unless you have just invented your option, and it does not exist
|
||||
anywhere yet,
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>find /usr/src/sys -name type f | xargs fgrep NEW_OPTION</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
is your friend in finding them. Go and edit all those files,
|
||||
and add
|
||||
|
||||
<programlisting>
|
||||
#include "opt_foo.h"</programlisting>
|
||||
|
||||
<emphasis>on top</emphasis>, before all the <literal>#include <xxx.h></literal> stuff. This sequence
|
||||
is most important as the options could override defaults from the
|
||||
regular include files, if the defaults are of the form
|
||||
|
||||
<programlisting>
|
||||
#ifndef NEW_OPTION
|
||||
#define NEW_OPTION (something)
|
||||
#endif</programlisting>
|
||||
|
||||
in the regular header.</para>
|
||||
|
||||
<para>Adding an option that overrides something in a system header
|
||||
file (i.e., a file sitting in
|
||||
<filename>/usr/include/sys/</filename>) is almost always a mistake.
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> cannot be
|
||||
included into those files since it would break the headers more
|
||||
seriously, but if it is not included, then places that include it
|
||||
may get an inconsistent value for the option. Yes, there are
|
||||
precedents for this right now, but that does not make them more
|
||||
correct.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
352
en_US.ISO8859-1/books/handbook/l10n/chapter.sgml
Normal file
352
en_US.ISO8859-1/books/handbook/l10n/chapter.sgml
Normal file
|
|
@ -0,0 +1,352 @@
|
|||
<chapter id="l10n">
|
||||
<title>Localization</title>
|
||||
|
||||
|
||||
<sect1 id="russian">
|
||||
<title>Russian Language (KOI8-R encoding)</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.ache;<!-- <br> --> 1 May
|
||||
1997</emphasis>.</para>
|
||||
|
||||
<para>See more info about KOI8-R encoding at <ulink
|
||||
URL="http://www.nagual.pp.ru/~ache/koi8.html">KOI8-R References
|
||||
(Russian Net Character Set)</ulink>.</para>
|
||||
|
||||
|
||||
<sect2 id="russian-console">
|
||||
<title>Console Setup</title>
|
||||
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Add following line to your kernel configuration file:
|
||||
|
||||
<programlisting>
|
||||
options "SC_MOUSE_CHAR=0x03"</programlisting> to move character
|
||||
codes used for mouse cursor off KOI8-R pseudographics
|
||||
range.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Russian console entry in
|
||||
<filename>/etc/rc.conf</filename> should looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
keymap=ru.koi8-r
|
||||
keychange="61 ^[[K"
|
||||
scrnmap=koi8-r2cp866
|
||||
font8x16=cp866b-8x16
|
||||
font8x14=cp866-8x14
|
||||
font8x8=cp866-8x8</programlisting>
|
||||
|
||||
<note>
|
||||
<para>^[ means that real ESC character must be entered into
|
||||
<filename>/etc/rc.conf</filename>, not just ^[
|
||||
string.</para>
|
||||
</note>
|
||||
|
||||
<para>This tuning means KOI8-R keyboard with Alternative
|
||||
screen font mapped to KOI8-R encoding to preserve
|
||||
pseudographics, <literal>Gray Delete</literal>
|
||||
key remapped to match Russian <citerefentry><refentrytitle>termcap</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry for FreeBSD
|
||||
console.</para>
|
||||
|
||||
<para>RUS/LAT switch will be <literal>CapsLock</literal>. Old CapsLock function still
|
||||
available via <literal>Shift+CapsLock</literal>.
|
||||
CapsLock LED will indicate RUS mode, not CapsLock
|
||||
mode.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>For each <literal>ttyv?</literal> entry in
|
||||
<filename>/etc/ttys</filename> change terminal type from
|
||||
<literal>cons25</literal> to <literal>cons25r</literal>, i.e. each entry should looks
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
ttyv0 "/usr/libexec/getty Pc" cons25r on secure</programlisting>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-locale">
|
||||
<title>Locale Setup</title>
|
||||
|
||||
<para><anchor id="russian-env"> There is two environment variables
|
||||
for locale setup:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><envar>LANG</envar> for POSIX
|
||||
<citerefentry><refentrytitle>setlocale</refentrytitle><manvolnum>3</manvolnum></citerefentry> family functions;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><envar>MM_CHARSET</envar> for applications MIME
|
||||
chararter set.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>The best way is using <filename>/etc/login.conf</filename>
|
||||
<literal>russian</literal> user's login class in
|
||||
<citerefentry><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry login class
|
||||
position. See <citerefentry><refentrytitle>login.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||||
details.</para>
|
||||
|
||||
|
||||
<sect3 id="russian-class">
|
||||
<title>Login Class Method</title>
|
||||
|
||||
<para>First of all check your <filename>/etc/login.conf</filename>
|
||||
have <literal>russian</literal> login class, this
|
||||
entry may looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
russian:Russian Users Accounts:\
|
||||
:charset=KOI8-R:\
|
||||
:lang=ru_RU.KOI8-R:\
|
||||
:tc=default:</programlisting>
|
||||
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>vipw</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>vipw</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new
|
||||
users, <filename>/etc/master.passwd</filename> entry should
|
||||
looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
user:password:1111:11:russian:0:0:User Name:/home/user:/bin/csh</programlisting>
|
||||
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new
|
||||
users:</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Set
|
||||
|
||||
<programlisting>
|
||||
defaultclass = russian</programlisting> in
|
||||
<filename>/etc/adduser.conf</filename> (you must enter
|
||||
<literal>default</literal> class for all
|
||||
non-Russian users in this case);</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Alternative variant will be answering <literal>russian</literal> each time when you see
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>Enter login class:</prompt> default []:</screen>
|
||||
</informalexample> prompt from
|
||||
<citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry>;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Another variant: call
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>adduser -class russian</userinput></screen>
|
||||
</informalexample> for each Russian user
|
||||
you want to add.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>pw</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>pw</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new users,
|
||||
call it in this form:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>pw useradd user_name -L russian</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect4>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Shell Startup Files Method</title>
|
||||
|
||||
<para>If you don't want to use
|
||||
<xref linkend="russian-class" remap="login class method"> for
|
||||
some reasons, just set this
|
||||
<xref linkend="russian-env" remap="two environment variables">
|
||||
in the following shell startup files:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/etc/profile</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
LANG=ru_RU.KOI8-R; export LANG
|
||||
MM_CHARSET=KOI8-R; export MM_CHARSET</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/etc/csh.login</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
setenv LANG ru_RU.KOI8-R
|
||||
setenv MM_CHARSET KOI8-R</programlisting>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>Alternatively you can add this instructions to</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/usr/share/skel/dot.profile</filename>:</para>
|
||||
|
||||
<para>(similar to <filename>/etc/profile</filename>
|
||||
above);</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/usr/share/skel/dot.login</filename>:</para>
|
||||
|
||||
<para>(similar to <filename>/etc/csh.login</filename>
|
||||
above).</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-printer">
|
||||
<title>Printer Setup</title>
|
||||
|
||||
<para>Since most printers with Russian characters comes with
|
||||
hardware code page CP866, special output filter needed for KOI8-R
|
||||
-> CP866 conversion. Such filter installed by default as
|
||||
<filename>/usr/libexec/lpr/ru/koi2alt</filename>. So, Russian
|
||||
printer <filename>/etc/printcap</filename> entry should looks
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
lp|Russian local line printer:\
|
||||
:sh:of=/usr/libexec/lpr/ru/koi2alt:\
|
||||
:lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:</programlisting>
|
||||
|
||||
<para>See <citerefentry><refentrytitle>printcap</refentrytitle><manvolnum>5</manvolnum></citerefentry> for detailed description.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-msdosfs">
|
||||
<title>MSDOS FS and Russian file names</title>
|
||||
|
||||
<para>Look at following example <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry to enable support for Russian
|
||||
file names in MSDOS FS:</para>
|
||||
|
||||
<programlisting>
|
||||
/dev/sd0s1 /dos/c msdos rw,-W=koi2dos,-L=ru_RU.KOI8-R 0 0</programlisting>
|
||||
|
||||
<para>See
|
||||
<citerefentry><refentrytitle>mount_msdos</refentrytitle><manvolnum>8</manvolnum></citerefentry>for detailed description of
|
||||
<option>-W</option> and <option>-L</option> options.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-xwindow">
|
||||
<title>X Window Setup</title>
|
||||
|
||||
<para>Step by step instructions:</para>
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Do
|
||||
<xref linkend="russian-locale" remap="non-X locale setup">
|
||||
first as described.</para>
|
||||
|
||||
<note>
|
||||
<para><anchor id="russian-note">Russian KOI8-R locale may
|
||||
not work with old XFree86 releases (lower than 3.3).
|
||||
XFree86 port from
|
||||
<filename>/usr/ports/x11/XFree86</filename> already have
|
||||
most recent XFree86 version, so it will work, if you
|
||||
install XFree86 from this port. XFree86 version shipped
|
||||
with the latest FreeBSD distribution should work too
|
||||
(check XFree86 version number not less than 3.3
|
||||
first).</para>
|
||||
</note>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Go to <filename>/usr/ports/russian/X.language</filename>
|
||||
directory and say
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample> there. This port install latest
|
||||
version of KOI8-R fonts. XFree86 3.3 already have some
|
||||
KOI8-R fonts, but this ones scaled better.</para>
|
||||
|
||||
<para>Check find <literal>"Files"</literal> section
|
||||
in your <filename>/etc/XF86Config</filename>, following
|
||||
lines must be before any other <literal>FontPath</literal>
|
||||
entries:</para>
|
||||
|
||||
<programlisting>
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/misc"
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/75dpi"
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/100dpi"</programlisting>
|
||||
|
||||
<para>If you use high resolution video mode, swap 75 dpi and
|
||||
100 dpi lines.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>To activate Russian keyboard add
|
||||
|
||||
<programlisting>
|
||||
XkbKeymap "xfree86(ru)"</programlisting> line into
|
||||
<literal>"Keyboard"</literal> section in your
|
||||
<filename>/etc/XF86Config</filename>, also make sure that
|
||||
<literal>XkbDisable</literal> is turned off
|
||||
(commented out) there.</para>
|
||||
|
||||
<para>RUS/LAT switch will be <literal>CapsLock</literal>. Old CapsLock function still
|
||||
available via <literal>Shift+CapsLock</literal>
|
||||
(in LAT mode only).</para>
|
||||
|
||||
<note>
|
||||
<para>Russian XKB keyboard may not work with old XFree86
|
||||
versions, see <xref
|
||||
linkend="russian-note" remap="locale note"> for more info.
|
||||
Russian XKB keyboard may not work with non-localized
|
||||
applications too, minimally localized application should
|
||||
call <literal>XtSetLanguageProc
|
||||
(NULL, NULL, NULL);</literal> function early in the program.</para>
|
||||
</note>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="german">
|
||||
<title>German Language (ISO 8859-1)</title>
|
||||
|
||||
<para>Slaven Rezic <email>eserte@cs.tu-berlin.de</email> wrote a tutorial how to use umlauts on a FreeBSD machine. The tutorial is written in German and available at <ulink URL="http://www.de.freebsd.org/de/umlaute/">http://www.de.freebsd.org/de/umlaute/</ulink>.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
827
en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml
Normal file
827
en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml
Normal file
|
|
@ -0,0 +1,827 @@
|
|||
<chapter id="linuxemu">
|
||||
<title>Linux Emulation</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.handy; and &a.rich;</emphasis></para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>How to Install the Linux Emulator</title>
|
||||
|
||||
<para>Linux emulation in FreeBSD has reached a point where it is
|
||||
possible to run a large fraction of Linux binaries in both a.out and
|
||||
ELF format. The linux emulation in the 2.1-STABLE branch is capable
|
||||
of running Linux DOOM and Mathematica; the version present in
|
||||
FreeBSD-2.2-RELEASE is vastly more capable and runs all these as
|
||||
well as Quake, Abuse, IDL, netrek for Linux and a whole host of
|
||||
other programs.</para>
|
||||
|
||||
<para>There are some Linux-specific operating system features that are
|
||||
not supported on FreeBSD. Linux binaries will not work on FreeBSD
|
||||
if they use the Linux <filename>/proc</filename> filesystem (which
|
||||
is different from the optional FreeBSD <filename>/proc</filename>
|
||||
filesystem) or i386-specific calls, such as enabling virtual 8086
|
||||
mode.</para>
|
||||
|
||||
<para>To tell whether your kernel is configured for Linux
|
||||
compatibility simply run any Linux binary. If it prints the error
|
||||
message <errorname>linux-executable: Exec format error. Wrong Architecture.</errorname> then you do not have linux compatibility support
|
||||
and you need to configure and install a new kernel.</para>
|
||||
|
||||
<para>Depending on which version of FreeBSD you are running, how you
|
||||
get Linux-emulation up will vary slightly:</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Emulation in 2.1-STABLE</title>
|
||||
|
||||
<para>The <filename>GENERIC</filename> kernel in 2.1-STABLE is not
|
||||
configured for linux compatibility so you must reconfigure your
|
||||
kernel for it. There are two ways to do this: 1. linking the
|
||||
emulator statically in the kernel itself and 2. configuring your
|
||||
kernel to dynamically load the linux loadable kernel module
|
||||
(LKM).</para>
|
||||
|
||||
<para>To enable the emulator, add the following to your
|
||||
configuration file (c.f.
|
||||
<filename>/sys/i386/conf/LINT</filename>):</para>
|
||||
|
||||
<programlisting>
|
||||
options COMPAT_LINUX</programlisting>
|
||||
|
||||
<para>If you want to run doom or other applications
|
||||
that need shared memory, also add the following.</para>
|
||||
|
||||
<programlisting>
|
||||
options SYSVSHM</programlisting>
|
||||
|
||||
<para>The linux system calls require 4.3BSD system
|
||||
call compatibility. So make sure you have the following.</para>
|
||||
|
||||
<programlisting>
|
||||
options "COMPAT_43"</programlisting>
|
||||
|
||||
<para>If you prefer to statically link the emulator in the kernel
|
||||
rather than use the loadable kernel module (LKM), then add</para>
|
||||
|
||||
<programlisting>
|
||||
options LINUX</programlisting>
|
||||
|
||||
<para>Then run config and install the new kernel as
|
||||
described in the
|
||||
<xref linkend="kernelconfig" remap="kernel configuration">
|
||||
section.</para>
|
||||
|
||||
<para>If you decide to use the LKM you must also install the
|
||||
loadable module. A mismatch of versions between the kernel and
|
||||
loadable module can cause the kernel to crash, so the safest thing
|
||||
to do is to reinstall the LKM when you install the kernel.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
|
||||
&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Once you have installed the kernel and the LKM,
|
||||
you can invoke `linux' as root to load the LKM.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>linux</userinput>
|
||||
Linux emulator installed
|
||||
Module loaded as ID 0</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To see whether the LKM is loaded, run
|
||||
<command>modstat</command>.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; modstat
|
||||
Type Id Off Loadaddr Size Info Rev
|
||||
Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You can cause the LKM to be loaded when the
|
||||
system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and
|
||||
2.1-STABLE enable it in <filename>/etc/sysconfig</filename>
|
||||
|
||||
<programlisting>
|
||||
linux=YES</programlisting> by changing it from NO to YES. FreeBSD 2.1
|
||||
RELEASE and earlier do not have such a line and on those you will
|
||||
need to edit <filename>/etc/rc.local</filename> to add the following line.</para>
|
||||
|
||||
<programlisting>
|
||||
linux</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Emulation in 2.2.2-RELEASE and later</title>
|
||||
|
||||
<para>It is no longer necessary to specify <literal>options LINUX</literal> or
|
||||
<literal>options COMPAT_LINUX</literal>. Linux emulation is done with an LKM
|
||||
(“Loadable Kernel Module”) so it can be installed on the fly
|
||||
without having to reboot. You will need the following things in
|
||||
your startup files, however:</para>
|
||||
<orderedlist>
|
||||
|
||||
<listitem>
|
||||
<para>In <filename>/etc/rc.conf</filename>, you need the
|
||||
following line:</para>
|
||||
|
||||
<programlisting>
|
||||
linux_enable=YES</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>This, in turn, triggers the following action in
|
||||
<filename>/etc/rc.i386</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
# Start the Linux binary emulation if requested.
|
||||
if [ "X${linux_enable}" = X"YES" ]; then echo -n '
|
||||
linux'; linux > /dev/null 2>&1
|
||||
fi</programlisting>
|
||||
</listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
|
||||
<para>If you want to verify it is running, modstat will do that:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>However, there have been reports that this
|
||||
fails on some 2.2-RELEASE and later systems. If for some reason
|
||||
you cannot load the linux LKM, then statically link the emulator
|
||||
in the kernel by adding
|
||||
|
||||
<programlisting>
|
||||
options LINUX</programlisting>
|
||||
|
||||
to your kernel config file. Then run config
|
||||
and install the new kernel as described in the <xref
|
||||
linkend="kernelconfig"
|
||||
remap="kernel configuration"> section.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Runtime Libraries</title>
|
||||
|
||||
|
||||
<sect3>
|
||||
<title>Installing using the linux_lib port</title>
|
||||
|
||||
<para>Most linux applications use shared libraries, so you are
|
||||
still not done until you install the shared libraries. It is
|
||||
possible to do this by hand, however, it is vastly simpler to
|
||||
just grab the linux_lib port:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/ports-current/emulators/linux_lib</userinput>
|
||||
&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>and you should have a working linux emulator. Legend (and
|
||||
the mail archives <!-- smiley -->:-) seems to hold that Linux emulation works
|
||||
best with linux binaries linked against the ZMAGIC libraries;
|
||||
QMAGIC libraries (such as those used in Slackware V2.0) may tend
|
||||
to give the Linuxulator heartburn. As of this writing (March
|
||||
1996) ELF emulation is still in the formulative stages but seems
|
||||
to work pretty well. Also, expect some programs to complain
|
||||
about incorrect minor versions. In general this does not seem
|
||||
to be a problem.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Installing libraries manually</title>
|
||||
|
||||
<para>If you do not have the “ports” distribution, you can
|
||||
install the libraries by hand instead. You will need the Linux
|
||||
shared libraries that the program depends on and the runtime
|
||||
linker. Also, you will need to create a "shadow root"
|
||||
directory, <filename>/compat/linux</filename>, for Linux
|
||||
libraries on your FreeBSD system. Any shared libraries opened
|
||||
by Linux programs run under FreeBSD will look in this tree
|
||||
first. So, if a Linux program loads, for example,
|
||||
<filename>/lib/libc.so</filename>, FreeBSD will first try to
|
||||
open <filename>/compat/linux/lib/libc.so</filename>, and if that
|
||||
does not exist then it will try
|
||||
<filename>/lib/libc.so</filename>. Shared libraries should be
|
||||
installed in the shadow tree
|
||||
<filename>/compat/linux/lib</filename> rather than the paths
|
||||
that the Linux <command>ld.so</command> reports.</para>
|
||||
|
||||
<para>FreeBSD-2.2-RELEASE and later works slightly differently
|
||||
with respect to <command>/compat/linux</command>. On -CURRENT, all files, not just
|
||||
libraries, are searched for from the “shadow root”
|
||||
<filename>/compat/linux</filename>.</para>
|
||||
|
||||
<para>Generally, you will need to look for the shared libraries
|
||||
that Linux binaries depend on only the first few times that you
|
||||
install a Linux program on your FreeBSD system. After a while,
|
||||
you will have a sufficient set of Linux shared libraries on your
|
||||
system to be able to run newly imported Linux binaries without
|
||||
any extra work.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>How to install additional shared libraries</title>
|
||||
|
||||
<para>What if you install the <filename>linux_lib</filename> port and your application
|
||||
still complains about missing shared libraries? How do you know
|
||||
which shared libraries Linux binaries need, and where to get
|
||||
them? Basically, there are 2 possibilities (when following these
|
||||
instructions: you will need to be root on your FreeBSD system to
|
||||
do the necessary installation steps).</para>
|
||||
|
||||
<para>If you have access to a Linux system, see what shared
|
||||
libraries it needs, and copy them to your FreeBSD system.
|
||||
Example: you have just ftp'ed the Linux binary of Doom. Put it
|
||||
on the Linux system you have access to, and check which shared
|
||||
libraries it needs by running <command>ldd linuxxdoom</command>:</para>
|
||||
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>ldd linuxxdoom</userinput>
|
||||
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
|
||||
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You would need to get all the files from the last column,
|
||||
and put them under <filename>/compat/linux</filename>, with the
|
||||
names in the first column as symbolic links pointing to them.
|
||||
This means you eventually have these files on your FreeBSD
|
||||
system:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/usr/X11/lib/libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
|
||||
/compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>Note that if you already have a Linux shared library with
|
||||
a matching major revision number to the first column of the
|
||||
<command>ldd</command> output, you will not need to copy the file named in the
|
||||
last column to your system, the one you already have should
|
||||
work. It is advisable to copy the shared library anyway if it
|
||||
is a newer version, though. You can remove the old one, as
|
||||
long as you make the symbolic link point to the new one. So,
|
||||
if you have these libraries on your system:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/libc.so.4.6.27
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>and you find a new binary that claims to require a later
|
||||
version according to the output of <command>ldd</command>:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If it is only one or two versions out of date in the in
|
||||
the trailing digit then do not worry about copying
|
||||
<filename>/lib/libc.so.4.6.29</filename> too, because the
|
||||
program should work fine with the slightly older version.
|
||||
However, if you like you can decide to replace the
|
||||
<filename>libc.so</filename> anyway, and that should leave you
|
||||
with:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/libc.so.4.6.29
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
<para>The symbolic link mechanism is <emphasis>only</emphasis>
|
||||
needed for Linux binaries. The FreeBSD runtime linker takes
|
||||
care of looking for matching major revision numbers itself and
|
||||
you do not need to worry about it.</para>
|
||||
</note>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Configuring the <filename>ld.so</filename> — for FreeBSD
|
||||
2.2-RELEASE only</title>
|
||||
|
||||
<para>This section applies only to FreeBSD 2.2-RELEASE and later.
|
||||
Those running 2.1-STABLE should skip this section.</para>
|
||||
|
||||
<para>Finally, if you run FreeBSD 2.2-RELEASE you must make sure
|
||||
that you have the Linux runtime linker and its config files on
|
||||
your system. You should copy these files from the Linux system
|
||||
to their appropriate place on your FreeBSD system (to the
|
||||
<filename>/compat/linux</filename> tree):</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/ld.so
|
||||
/compat/linux/etc/ld.so.config</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If you do not have access to a Linux system, you should get
|
||||
the extra files you need from various ftp sites. Information on
|
||||
where to look for the various files is appended below. For now,
|
||||
let us assume you know where to get the files.</para>
|
||||
|
||||
<para>Retrieve the following files (all from the same ftp site to
|
||||
avoid any version mismatches), and install them under
|
||||
<filename>/compat/linux</filename> (i.e.
|
||||
<filename>/foo/bar</filename> is installed as
|
||||
<filename>/compat/linux/foo/bar</filename>):</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/sbin/ldconfig
|
||||
/usr/bin/ldd
|
||||
/lib/libc.so.x.y.z
|
||||
/lib/ld.so</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><command>ldconfig</command> and <command>ldd</command> do not necessarily need to be under
|
||||
<filename>/compat/linux</filename>; you can install them
|
||||
elsewhere in the system too. Just make sure they do not conflict
|
||||
with their FreeBSD counterparts. A good idea would be to install
|
||||
them in <filename>/usr/local/bin</filename> as <command>ldconfig-linux</command>
|
||||
and <command>ldd-linux</command>.</para>
|
||||
|
||||
<para>Create the file
|
||||
<filename>/compat/linux/etc/ld.so.conf</filename>, containing
|
||||
the directories in which the Linux runtime linker should look
|
||||
for shared libs. It is a plain text file, containing a directory
|
||||
name on each line. <filename>/lib</filename> and
|
||||
<filename>/usr/lib</filename> are standard, you could add the
|
||||
following:</para>
|
||||
|
||||
<programlisting>
|
||||
/usr/X11/lib
|
||||
/usr/local/lib</programlisting>
|
||||
|
||||
<para>When a linux binary opens a library such as
|
||||
<filename>/lib/libc.so</filename> the emulator maps the name to
|
||||
<filename>/compat/linux/lib/libc.so</filename> internally. All
|
||||
linux libraries should be installed under /compat/linux (e.g.
|
||||
<filename>/compat/linux/lib/libc.so</filename>,
|
||||
<filename>/compat/linux/usr/X11/lib/libX11.so</filename>, etc.)
|
||||
in order for the emulator to find them.</para>
|
||||
|
||||
<para>Those running FreeBSD 2.2-RELEASE should run the Linux
|
||||
ldconfig program.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root <userinput>cd /compat/linux/lib</userinput>
|
||||
&prompt.root; <userinput>/compat/linux/sbin/ldconfig</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><command>ldconfig</command> is statically linked, so it does not need any
|
||||
shared libraries to run. It creates the file
|
||||
<filename>/compat/linux/etc/ld.so.cache</filename> which
|
||||
contains the names of all the shared libraries and should be
|
||||
rerun to recreate this file whenever you install additional
|
||||
shared libraries.</para>
|
||||
|
||||
<para>On 2.1-STABLE do not install
|
||||
<filename>/compat/linux/etc/ld.so.cache</filename> or run
|
||||
<command>ldconfig</command>; in 2.1-STABLE the syscalls are implemented differently
|
||||
and <command>ldconfig</command> is not needed or used.</para>
|
||||
|
||||
<para>You should now be set up for Linux binaries which only need
|
||||
a shared libc. You can test this by running the Linux <command>ldd</command> on
|
||||
itself. Supposing that you have it installed as <command>ldd-linux</command>, it
|
||||
should produce something like:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>ldd-linux `which ldd-linux`</userinput>
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This being done, you are ready to install new Linux
|
||||
binaries. Whenever you install a new Linux program, you should
|
||||
check if it needs shared libraries, and if so, whether you have
|
||||
them installed in the <filename>/compat/linux</filename> tree.
|
||||
To do this, you run the Linux version <command>ldd</command> on the new program,
|
||||
and watch its output. <command>ldd</command> (see also the manual page for <citerefentry><refentrytitle>ldd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
|
||||
will print a list of shared libraries that the program depends
|
||||
on, in the form <literal><replaceable>majorname</replaceable> (<replaceable>jumpversion</replaceable>) => <replaceable>fullname</replaceable></literal>.</para>
|
||||
|
||||
<para>If it prints <literal>not found</literal> instead of <replaceable>fullname</replaceable> it means that
|
||||
you need an extra library. The library needed is shown in
|
||||
majorname and will be of the form <literal>lib<replaceable>XXXX</replaceable>.so.<replaceable>N</replaceable></literal>. You will need to
|
||||
find a <filename>lib<replaceable>XXXX</replaceable>.so.N.mm</filename> on a Linux ftp site, and install it on
|
||||
your system. The <replaceable>XXXX</replaceable> (name) and <replaceable>N</replaceable> (major revision number)
|
||||
should match; the minor number(s) <replaceable>mm</replaceable> are less important, though
|
||||
it is advised to take the most recent version.</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring the host name resolver</title>
|
||||
|
||||
<para>If DNS does not work or you get the messages
|
||||
|
||||
<informalexample>
|
||||
<screen>resolv+: "bind" is an invalid keyword resolv+:
|
||||
"hosts" is an invalid keyword</screen>
|
||||
</informalexample>
|
||||
|
||||
then you need to configure a
|
||||
<filename>/compat/linux/etc/host.conf</filename> file containing:
|
||||
|
||||
<programlisting>
|
||||
order hosts, bind
|
||||
multi on</programlisting>
|
||||
|
||||
where the order here specifies that
|
||||
<filename>/etc/hosts</filename> is searched first and DNS is
|
||||
searched second. When
|
||||
<filename>/compat/linux/etc/host.conf</filename> is not installed
|
||||
linux applications find FreeBSD's
|
||||
<filename>/etc/host.conf</filename> and complain about the
|
||||
incompatible FreeBSD syntax. You should remove <literal>bind</literal> if you
|
||||
have not configured a name-server using the
|
||||
<filename>/etc/resolv.conf</filename> file.</para>
|
||||
|
||||
<para>Lastly, those who run 2.1-STABLE need to set an the
|
||||
<envar>RESOLV_HOST_CONF</envar> environment variable so that applications will
|
||||
know how to search the host tables. If you run FreeBSD
|
||||
2.2-RELEASE, you can skip this. For the
|
||||
<filename>/bin/csh</filename> shell use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>For <filename>/bin/sh</filename> use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Finding the necessary files</title>
|
||||
|
||||
<note>
|
||||
<para>The information below is valid as of the time this document
|
||||
was written, but certain details such as names of ftp sites,
|
||||
directories and distribution names may have changed by the time
|
||||
you read this.</para>
|
||||
</note>
|
||||
|
||||
<para>Linux is distributed by several groups that make their own set
|
||||
of binaries that they distribute. Each distribution has its own
|
||||
name, like “Slackware” or “Yggdrasil”. The distributions are
|
||||
available on a lot of ftp sites. Sometimes the files are unpacked,
|
||||
and you can get the individual files you need, but mostly they are
|
||||
stored in distribution sets, usually consisting of subdirectories
|
||||
with gzipped tar files in them. The primary ftp sites for the
|
||||
distributions are:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>sunsite.unc.edu:/pub/Linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>tsx-11.mit.edu:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>Some European mirrors:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>ftp.luth.se:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>ftp.demon.co.uk:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>src.doc.ic.ac.uk:/packages/linux/distributions</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
|
||||
<para>For simplicity, let us concentrate on Slackware here. This
|
||||
distribution consists of a number of subdirectories, containing
|
||||
separate packages. Normally, they are controlled by an install
|
||||
program, but you can retrieve files “by hand” too. First of all,
|
||||
you will need to look in the <filename>contents</filename> subdir of the
|
||||
distribution. You will find a lot of small text files here
|
||||
describing the contents of the separate packages. The fastest way
|
||||
to look something up is to retrieve all the files in the contents
|
||||
subdirectory, and grep through them for the file you need. Here is
|
||||
an example of a list of files that you might need, and in which
|
||||
contents-file you will find it by grepping through them:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Library</entry>
|
||||
<entry>Package</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row><entry><filename>ld.so</filename> </entry><entry>ldso
|
||||
</entry></row>
|
||||
<row><entry><filename>ldconfig</filename>
|
||||
</entry><entry>ldso </entry></row>
|
||||
<row><entry><filename>ldd</filename> </entry><entry>ldso
|
||||
</entry></row>
|
||||
<row><entry><filename>libc.so.4</filename>
|
||||
</entry><entry>shlibs </entry></row>
|
||||
<row><entry><filename>libX11.so.6.0</filename>
|
||||
</entry><entry>xf_lib
|
||||
</entry></row>
|
||||
<row><entry><filename>libXt.so.6.0</filename>
|
||||
</entry><entry>xf_lib
|
||||
</entry></row>
|
||||
<row><entry><filename>libX11.so.3</filename>
|
||||
</entry><entry>oldlibs
|
||||
</entry></row>
|
||||
<row><entry><filename>libXt.so.3</filename>
|
||||
</entry><entry>oldlibs
|
||||
</entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>So, in this case, you will need the packages ldso, shlibs,
|
||||
xf_lib and oldlibs. In each of the contents-files for these
|
||||
packages, look for a line saying <literal>PACKAGE LOCATION</literal>, it will
|
||||
tell you on which “disk” the package is, in our case it will tell
|
||||
us in which subdirectory we need to look. For our example, we
|
||||
would find the following locations:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<thead
|
||||
<row>
|
||||
<entry>Package</entry>
|
||||
<entry>Location</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row><entry>ldso </entry><entry>diska2 </entry></row>
|
||||
<row><entry>shlibs </entry><entry>diska2 </entry></row>
|
||||
<row><entry>oldlibs </entry><entry>diskx6 </entry></row>
|
||||
<row><entry>xf_lib </entry><entry>diskx9 </entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>The locations called “disk<replaceable>XX</replaceable>” refer to the <filename>slakware/<replaceable>XX</replaceable></filename>
|
||||
subdirectories of the distribution, others may be found in the
|
||||
<filename>contrib</filename> subdirectory. In this case, we
|
||||
could now retrieve the packages we need by retrieving the
|
||||
following files (relative to the root of the Slackware
|
||||
distribution tree):</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>slakware/a2/ldso.tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/a2/shlibs.tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/x6/oldlibs/tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/x9/xf_lib.tgz</filename></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>Extract the files from these gzipped tarfiles in your
|
||||
<filename>/compat/linux</filename> directory (possibly omitting or
|
||||
afterwards removing files you do not need), and you are
|
||||
done.</para>
|
||||
|
||||
<para><emphasis>See also:</emphasis>
|
||||
<filename>ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README</filename> and <filename>/usr/src/sys/i386/ibcs2/README.iBCS2</filename></para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mathematica">
|
||||
<title>How to Install Mathematica on FreeBSD</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.rich; and
|
||||
&a.chuck;</emphasis></para>
|
||||
|
||||
<para>This document shows how to install the Linux binary distribution
|
||||
of Mathematica 2.2 on FreeBSD 2.1.</para>
|
||||
|
||||
<para>Mathematica supports Linux but not FreeBSD as it stands. So
|
||||
once you have configured your system for Linux compatibility you
|
||||
have most of what you need to run Mathematica.</para>
|
||||
|
||||
<para>For those who already have the student edition of Mathematica
|
||||
for DOS the cost of upgrading to the Linux version at the time this
|
||||
was written, March 1996, was $45.00. It can be ordered directly
|
||||
from Wolfram at (217) 398-6500 and paid for by credit card.</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Unpacking the Mathematica distribution</title>
|
||||
|
||||
<para>The binaries are currently distributed by Wolfram on CDROM.
|
||||
The CDROM has about a dozen tar files, each of which is a binary
|
||||
distribution for one of the supported architectures. The one for
|
||||
Linux is named <filename>LINUX.TAR</filename>. You can, for
|
||||
example, unpack this into
|
||||
<filename>/usr/local/Mathematica</filename>:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local</userinput>
|
||||
&prompt.root; <userinput>mkdir Mathematica</userinput>
|
||||
&prompt.root; <userinput>cd Mathematica</userinput>
|
||||
&prompt.root; <userinput>tar -xvf /cdrom/LINUX.TAR</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Obtaining your Mathematica Password</title>
|
||||
|
||||
<para>Before you can run Mathematica you will have to obtain a
|
||||
password from Wolfram that corresponds to your “machine
|
||||
ID”.</para>
|
||||
|
||||
<para>Once you have installed the linux compatibility runtime
|
||||
libraries and unpacked the mathematica you can obtain the “machine
|
||||
ID” by running the program <command>mathinfo</command> in the Install directory.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local/Mathematica/Install</userinput>
|
||||
&prompt.root; <userinput>mathinfo</userinput>
|
||||
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
|
||||
richc.isdn.bcm.tmc.edu 9845-03452-90255</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>So, for example, the “machine ID” of <hostid>richc</hostid> is
|
||||
<literal>9845-03452-90255</literal>. You can ignore the message about the ioctl
|
||||
that is not implemented. It will not prevent Mathematica from
|
||||
running in any way and you can safely ignore it, though you will
|
||||
see the message every time you run Mathematica.</para>
|
||||
|
||||
<para>When you register with Wolfram, either by email, phone or fax,
|
||||
you will give them the “machine ID” and they will respond with a
|
||||
corresponding password consisting of groups of numbers. You need
|
||||
to add them both along with the machine name and license number in
|
||||
your mathpass file.</para>
|
||||
|
||||
<para>You can do this by invoking:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local/Mathematica/Install</userinput>
|
||||
&prompt.root; <userinput>math.install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>It will ask you to enter your license number
|
||||
and the Wolfram supplied password. If you get them mixed up or
|
||||
for some reason the math.install fails, that is OK; you can simply
|
||||
edit the file <filename>mathpass</filename> in this same directory to correct the
|
||||
info manually.</para>
|
||||
|
||||
<para>After getting past the password, math.install will ask you if
|
||||
you accept the install defaults provided, or if you want to use
|
||||
your own. If you are like us and distrust all install programs,
|
||||
you probably want to specify the actual directories. Beware.
|
||||
Although the math.install program asks you to specify directories,
|
||||
it will not create them for you, so you should perhaps have a
|
||||
second window open with another shell so that you can create them
|
||||
before you give them to the install program. Or, if it fails, you
|
||||
can create the directories and then restart the <command>math.install</command>
|
||||
program. The directories we chose to create beforehand and
|
||||
specify to <command>math.install</command> were:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>/usr/local/Mathematica/bin</filename></entry>
|
||||
<entry>for binaries</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>/usr/local/Mathematica/man/man1</filename></entry>
|
||||
<entry>for man pages</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>/usr/local/Mathematica/lib/X11</entry>
|
||||
<entry>for the XKeysymb file</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>You can also tell it to use
|
||||
<filename>/tmp/math.record</filename> for the system record file,
|
||||
where it puts logs of sessions. After this <command>math.install</command> will
|
||||
continue on to unpacking things and placing everything where it
|
||||
should go.</para>
|
||||
|
||||
<para>The Mathematica Notebook feature is included separately, as
|
||||
the X Front End, and you have to install it separately. To get the
|
||||
X Front End stuff correctly installed, cd into the
|
||||
<filename>/usr/local/Mathematica/FrontEnd</filename> directory and
|
||||
execute the <command>xfe.install</command> shell script. You will have to tell it
|
||||
where to put things, but you do not have to create any directories
|
||||
because it will use the same directories that had been created for
|
||||
math.install. When it finishes, there should be a new shell script
|
||||
in <filename>/usr/local/Mathematica/bin</filename> called
|
||||
<filename>mathematica</filename>.</para>
|
||||
|
||||
<para>Lastly, you need to modify each of the shell scripts that
|
||||
Mathematica has installed. At the beginning of every shell script
|
||||
in <filename>/usr/local/Mathematica/bin</filename> add the
|
||||
following line:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This tells Mathematica were to find its own
|
||||
version of the key mapping file <filename>XKeysymDB</filename>.
|
||||
Without this you will get pages of error messages about missing
|
||||
key mappings.</para>
|
||||
|
||||
<para>On 2.1-STABLE you need to add the following as well:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This tells Mathematica to use the linux version
|
||||
of host.conf. This file has a different syntax from FreeBSD's
|
||||
host.conf, so you will get an error message about
|
||||
<filename>/etc/host.conf</filename> if you leave this out.</para>
|
||||
|
||||
<para>You might also want to modify your
|
||||
<filename>/etc/manpath.config</filename> file to read the new man
|
||||
directory, and you may need to edit your
|
||||
<filename>~/.cshrc</filename> file to add
|
||||
<filename>/usr/local/Mathematica/bin</filename> to your
|
||||
path.</para>
|
||||
|
||||
<para>That is about all it takes. With this you should be able to
|
||||
type <command>mathematica</command> and get a really slick looking Mathematica
|
||||
Notebook screen up. Mathematica has included the Motif user
|
||||
interfaces, but it is compiled in statically, so you do not need
|
||||
the Motif libraries. Good luck doing this yourself!</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Bugs</title>
|
||||
|
||||
<para>The Notebook front end is known to hang sometimes when reading
|
||||
notebook files with an error messages similar to:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><errorname>File .../Untitled-1.mb appears to be broken for OMPR.257.0</errorname></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>We have not found the cause for this, but it only affects the
|
||||
Notebook's X Window front end, not the mathematica engine itself.
|
||||
So the command line interface invoked by 'math' is unaffected by
|
||||
this bug.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Acknowledgments</title>
|
||||
|
||||
<para>A well-deserved thanks should go to &a.sos; and &a.peter; who
|
||||
made linux emulation what it is today, and Michael Smith who drove
|
||||
these two guys like dogs to get it to the point where it runs
|
||||
Linux binaries better than linux! <!-- smiley -->:-)</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
581
en_US.ISO8859-1/books/handbook/mail/chapter.sgml
Normal file
581
en_US.ISO8859-1/books/handbook/mail/chapter.sgml
Normal file
|
|
@ -0,0 +1,581 @@
|
|||
<chapter id="mail">
|
||||
<title>Electronic Mail</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.wlloyd;.</emphasis></para>
|
||||
|
||||
<para>Electronic Mail configuration is the subject of many <xref
|
||||
linkend="bibliography" remap="System Administration"> books. If you
|
||||
plan on doing anything beyond setting up one mailhost for your
|
||||
network, you need industrial strength help.</para>
|
||||
|
||||
<para>Some parts of E-Mail configuration are controlled in the Domain
|
||||
Name System (DNS). If you are going to run your own own DNS server
|
||||
check out <filename>/etc/namedb</filename> and <command>man -k named</command> for more information.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Basic Information</title>
|
||||
|
||||
<para>These are the major programs involved in an E-Mail exchange. A
|
||||
“mailhost” is a server that is
|
||||
responsible for delivering and receiving all email for your host,
|
||||
and possibly your network.</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>User program</title>
|
||||
|
||||
<para>This is a program like <application >elm</application>, <application>pine</application>,
|
||||
<application>mail</application>, or something more sophisticated like a WWW
|
||||
browser. This program will simply pass off all e-mail
|
||||
transactions to the local “mailhost” ,
|
||||
either by calling <command>sendmail</command> or
|
||||
delivering it over TCP.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Mailhost Server Daemon</title>
|
||||
|
||||
<para>Usually this program is <command>sendmail</command> or
|
||||
<command>smail</command> running in the background. Turn it off or
|
||||
change the command line options in
|
||||
<filename>/etc/rc.conf</filename> (or, prior to FreeBSD 2.2.2,
|
||||
<filename>/etc/sysconfig</filename>). It is best to leave it on,
|
||||
unless you have a specific reason to want it off. Example: You
|
||||
are building a <xref
|
||||
linkend="firewalls" remap="Firewall">.</para>
|
||||
|
||||
<para>You should be aware that <command>sendmail</command> is a potential weak link in a
|
||||
secure site. Some versions of <command>sendmail</command> have known security
|
||||
problems.</para>
|
||||
|
||||
<para><command>sendmail</command> does two jobs. It looks after delivering
|
||||
and receiving mail.</para>
|
||||
|
||||
<para>If <command>sendmail</command>
|
||||
needs to deliver mail off your site it will look up in
|
||||
the DNS to determine the actual host that will receive mail for
|
||||
the destination.</para>
|
||||
|
||||
<para>If it is acting as a delivery agent <command>sendmail</command> will take the message from the
|
||||
local queue and deliver it across the Internet to another sendmail
|
||||
on the receivers computer.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>DNS — Name Service</title>
|
||||
|
||||
<para>The Domain Name System and its daemon <command>named</command>, contain the database mapping
|
||||
hostname to IP address, and hostname to mailhost. The IP address
|
||||
is specified in an A record. The MX record specifies the
|
||||
mailhost that will receive mail for you. If you do not have a
|
||||
MX record mail for your hostname, the mail will be delivered to
|
||||
your host directly.</para>
|
||||
|
||||
<para>Unless you are running your own DNS server, you will not be
|
||||
able to change any information in the DNS yourself. If you are
|
||||
using an Internet Provider, speak to them.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>POP Servers</title>
|
||||
|
||||
<para>This program gets the mail from your mailbox and gives it to
|
||||
your browser. If you want to run a POP server on your computer,
|
||||
you will need to do 2 things.</para>
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Get pop software from the <ulink
|
||||
URL="../ports/mail.html">Ports collection</ulink> that
|
||||
can be found in <filename>/usr/ports</filename> or packages
|
||||
collection. This handbook section has a complete reference
|
||||
on the <xref linkend="ports"
|
||||
remap="Ports"> system.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Modify <filename>/etc/inetd.conf</filename>
|
||||
to load the POP server.</para>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
<para>The pop program will have instructions with it. Read
|
||||
them.</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Configuration</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Basic</title>
|
||||
|
||||
<para>As your FreeBSD system comes “out of the box”[TM], you should
|
||||
be able to send E-mail to external hosts as long as you have
|
||||
<filename>/etc/resolv.conf</filename> setup or are running a name
|
||||
server. If you want to have mail for your host delivered to your
|
||||
specific host,there are two methods:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Run a name server (<command>man -k named</command>) and have your own domain
|
||||
<hostid role="domainname">smallminingco.com </hostid></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Get mail delivered to the current DNS name for your host.
|
||||
Ie: <hostid role="fqdn">dorm6.ahouse.school.edu </hostid></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>No matter what option you choose, to have mail delivered
|
||||
directly to your host, you must be a full Internet host. You must
|
||||
have a permanent IP address. IE: NO dynamic PPP. If you are
|
||||
behind a firewall, the firewall must be passing on smtp traffic to
|
||||
you. From <filename>/etc/services</filename>:</para>
|
||||
|
||||
<programlisting
|
||||
>smtp 25/tcp mail #Simple Mail Transfer</programlisting>
|
||||
|
||||
<para>If you
|
||||
want to receive mail at your host itself, you must make sure that
|
||||
the DNS MX entry points to your host address, or there is no MX
|
||||
entry for your DNS name.</para>
|
||||
|
||||
<para>Try this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>hostname</userinput>
|
||||
newbsdbox.freebsd.org
|
||||
&prompt.root; <userinput>host newbsdbox.freebsd.org</userinput>
|
||||
newbsdbox.freebsd.org has address 204.216.27.xx</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If that is all that comes out for your machine, mail directory
|
||||
to <email>root@newbsdbox.freebsd.org</email>
|
||||
will work no problems.</para>
|
||||
|
||||
<para>If instead, you have this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>host newbsdbox.freebsd.org</userinput>
|
||||
newbsdbox.FreeBSD.org has address 204.216.27.xx
|
||||
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.org</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>All mail sent to your host
|
||||
directly will end up on <hostid>freefall</hostid>, under the same username.</para>
|
||||
|
||||
<para>This information is setup in your domain name server. This
|
||||
should be the same host that is listed as your primary nameserver
|
||||
in <filename>/etc/resolv.conf</filename></para>
|
||||
|
||||
<para>The DNS record that carries mail routing information is the
|
||||
Mail eXchange entry. If no MX entry exists, mail will be
|
||||
delivered directly to the host by way of the Address
|
||||
record.</para>
|
||||
|
||||
<para>The MX entry for <hostid role="fqdn">freefall.freebsd.org</hostid> at one time.</para>
|
||||
|
||||
<programlisting>
|
||||
freefall MX 30 mail.crl.net
|
||||
freefall MX 40 agora.rdrop.com
|
||||
freefall HINFO Pentium FreeBSD
|
||||
freefall MX 10 freefall.FreeBSD.org
|
||||
freefall MX 20 who.cdrom.com
|
||||
freefall A 204.216.27.xx
|
||||
freefall CNAME www.FreeBSD.org</programlisting>
|
||||
|
||||
<para><hostid>freefall</hostid> has many MX entries. The lowest MX number gets the
|
||||
mail in the end. The others will queue mail temporarily, if
|
||||
<hostid>freefall</hostid> is busy or down.</para>
|
||||
|
||||
<para>Alternate MX sites should have separate connections to the
|
||||
Internet, to be most useful. An Internet Provider or other
|
||||
friendly site can provide this service.</para>
|
||||
|
||||
<para><command>dig</command>, <command>nslookup</command>,
|
||||
and <command>host</command> are your friends.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="mail-domain">
|
||||
<title>Mail for your Domain (Network).</title>
|
||||
|
||||
<para>To setup up a network mailhost, you need to direct the mail
|
||||
from arriving at all the workstations. In other words, you want to
|
||||
hijack all mail for <hostid role="domainname">*.smallminingco.com
|
||||
</hostid> and divert it to one machine, your “mailhost”.</para>
|
||||
|
||||
<para>The network users on their workstations will most likely pick
|
||||
up their mail over POP or telnet.</para>
|
||||
|
||||
<para>A user account with the <emphasis>same username</emphasis> should exist on both
|
||||
machines. Please use <command>adduser</command> to do
|
||||
this as required. If you set the <literal>shell</literal> to
|
||||
<literal>/nonexistent</literal>
|
||||
the user will not be allowed to login.</para>
|
||||
|
||||
<para>The mailhost that you will be using must be designated the
|
||||
Mail eXchange for each workstation. This must be arranged in DNS
|
||||
(ie BIND, named). Please refer to a Networking book for in-depth
|
||||
information.</para>
|
||||
|
||||
<para>You basically need to add these lines in your DNS server.</para>
|
||||
|
||||
<programlisting>
|
||||
pc24.smallminingco.com A <replaceable>xxx.xxx.xxx.xxx</replaceable> ; Workstation ip
|
||||
MX 10 smtp.smallminingco.com ; Your mailhost</programlisting>
|
||||
|
||||
<para>You cannot do this yourself unless you are running a DNS
|
||||
server. If you do not want to run a DNS server, get somebody else
|
||||
like your Internet Provider to do it.</para>
|
||||
|
||||
<para>This will redirect mail for the workstation to the Mail
|
||||
eXchange host. It does not matter what machine the A record
|
||||
points to, the mail will be sent to the MX host.</para>
|
||||
|
||||
<para>This feature is used to implement Virtual E-Mail Hosting.</para>
|
||||
|
||||
<para>Example</para>
|
||||
|
||||
<para>I have a customer with domain foo.bar and I want all mail for
|
||||
foo.bar to be sent to my machine smtp.smalliap.com. You must make
|
||||
an entry in your DNS server like:</para>
|
||||
|
||||
<programlisting>
|
||||
foo.bar MX 10 smtp.smalliap.com ; your mailhost</programlisting>
|
||||
|
||||
<para>The A record is not needed if you only
|
||||
want E-Mail for the domain. IE: Don't expect <command>ping foo.bar</command>
|
||||
to work unless an Address record for <filename>foo.bar</filename>
|
||||
exists as well.</para>
|
||||
|
||||
<para>On the mailhost that actually accepts mail for final delivery
|
||||
to a mailbox, <command>sendmail</command> must be told what hosts it will be
|
||||
accepting mail for.</para>
|
||||
|
||||
<para>Add <literal>pc24.smallminingco.com</literal> to <filename>/etc/sendmail.cw</filename> (if you are
|
||||
using <literal>FEATURE(use_cw_file)</literal>), or add a <literal>Cw myhost.smalliap.com</literal>
|
||||
line to <filename>/etc/sendmail.cf</filename></para>
|
||||
|
||||
<para>If you plan on doing anything serious with <command>sendmail</command> you should install the <command>sendmail</command>
|
||||
source. The source has plenty of documentation with it. You will
|
||||
find information on getting <command>sendmail</command>
|
||||
source from <xref linkend="sendmailuucp" remap="the UUCP
|
||||
information">.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sendmailuucp">
|
||||
<title>Setting up UUCP.</title>
|
||||
|
||||
<para><emphasis>Stolen from the FAQ.</emphasis></para>
|
||||
|
||||
<para>The sendmail configuration that ships with FreeBSD is suited
|
||||
for sites that connect directly to the Internet. Sites that wish
|
||||
to exchange their mail via UUCP must install another <command>sendmail</command>
|
||||
configuration file.</para>
|
||||
|
||||
<para>Tweaking <filename>/etc/sendmail.cf</filename> manually is
|
||||
considered something for purists. Sendmail version 8 comes with a
|
||||
new approach of generating config files via some <command>m4</command> preprocessing, where the actual
|
||||
hand-crafted configuration is on a higher abstraction level. You
|
||||
should use the configuration files under
|
||||
<filename>/usr/src/usr.sbin/sendmail/cf</filename>.</para>
|
||||
|
||||
<para>If you did not install your system with full sources, the
|
||||
<command>sendmail</command> config stuff has been broken out into a separate source
|
||||
distribution tarball just for you. Assuming you have your CD-ROM
|
||||
mounted, do:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
|
||||
&prompt.root; <userinput>tar -xvzf /cdrom/dists/src/ssmailcf.aa</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Do not panic, this is only a few hundred kilobytes in size.
|
||||
The file <filename>README</filename> in the <filename>cf</filename> directory can serve as a basic
|
||||
introduction to m4 configuration.</para>
|
||||
|
||||
<para>For UUCP delivery, you are best advised to use the
|
||||
<emphasis>mailertable</emphasis> feature. This constitutes a
|
||||
database that <command>sendmail</command> can use to base its routing decision
|
||||
upon.</para>
|
||||
|
||||
<para>First, you have to create your <filename>.mc</filename> file.
|
||||
The directory
|
||||
<filename>/usr/src/usr.sbin/sendmail/cf/cf</filename> is the home
|
||||
of these files. Look around, there are already a few examples.
|
||||
Assuming you have named your file <filename>foo.mc</filename>, all
|
||||
you need to do in order to convert it into a valid
|
||||
<filename>sendmail.cf</filename> is:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/sendmail/cf/cf</userinput>
|
||||
&prompt.root; <userinput>make foo.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If you don't have a <filename>/usr/obj</filename> hiearchy,
|
||||
then:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cp foo.cf /etc/sendmail.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Otherwise:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>A typical <filename>.mc</filename> file might look
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
include(`../m4/cf.m4')
|
||||
VERSIONID(`<replaceable>Your version number</replaceable>')
|
||||
OSTYPE(bsd4.4)
|
||||
|
||||
FEATURE(nodns)
|
||||
FEATURE(nocanonify)
|
||||
FEATURE(mailertable)
|
||||
|
||||
define(`UUCP_RELAY', <replaceable>your.uucp.relay</replaceable>)
|
||||
define(`UUCP_MAX_SIZE', 200000)
|
||||
|
||||
MAILER(local)
|
||||
MAILER(smtp)
|
||||
MAILER(uucp)
|
||||
|
||||
Cw <replaceable>your.alias.host.name</replaceable>
|
||||
Cw <replaceable>youruucpnodename.UUCP</replaceable></programlisting>
|
||||
|
||||
<para>The <literal>nodns</literal> and
|
||||
<literal>nocanonify</literal> features will prevent any usage of
|
||||
the DNS during mail delivery. The <literal>UUCP_RELAY</literal>
|
||||
clause is needed for bizarre reasons, do not ask. Simply put an
|
||||
Internet hostname there that is able to handle .UUCP pseudo-domain
|
||||
addresses; most likely, you will enter the mail relay of your ISP
|
||||
there.</para>
|
||||
|
||||
<para>Once you have this, you need this file called
|
||||
<filename>/etc/mailertable</filename>. A typical example of this
|
||||
gender again:</para>
|
||||
|
||||
<programlisting>
|
||||
#
|
||||
# makemap hash /etc/mailertable.db < /etc/mailertable
|
||||
#
|
||||
horus.interface-business.de uucp-dom:horus
|
||||
.interface-business.de uucp-dom:if-bus
|
||||
interface-business.de uucp-dom:if-bus
|
||||
.heep.sax.de smtp8:%1 horus.UUCP
|
||||
uucp-dom:horus if-bus.UUCP
|
||||
uucp-dom:if-bus . uucp-dom:sax</programlisting>
|
||||
|
||||
<para>As you can see, this is part of a real-life file. The first
|
||||
three lines handle special cases where domain-addressed mail
|
||||
should not be sent out to the default route, but instead to some
|
||||
UUCP neighbor in order to “shortcut” the delivery path. The
|
||||
next line handles mail to the local Ethernet domain that can be
|
||||
delivered using SMTP. Finally, the UUCP neighbors are mentioned
|
||||
in the .UUCP pseudo-domain notation, to allow for a
|
||||
<literal>uucp-neighbor!recipient</literal> override of the default rules. The
|
||||
last line is always a single dot, matching everything else, with
|
||||
UUCP delivery to a UUCP neighbor that serves as your universal
|
||||
mail gateway to the world. All of the node names behind the
|
||||
<literal>uucp-dom:</literal> keyword must be valid UUCP
|
||||
neighbors, as you can verify using the command <command>uuname</command>.</para>
|
||||
|
||||
<para>As a reminder that this file needs to be converted into a DBM
|
||||
database file before being usable, the command line to accomplish
|
||||
this is best placed as a comment at the top of the <filename>mailertable</filename>.
|
||||
You always have to execute this command each time you change your
|
||||
<filename>mailertable</filename>.</para>
|
||||
|
||||
<para>Final hint: if you are uncertain whether some particular mail
|
||||
routing would work, remember the <option>-bt</option> option to
|
||||
<command>sendmail</command>. It starts <command>sendmail</command>
|
||||
in “address test
|
||||
mode”; simply enter <literal>0</literal>, followed by the address
|
||||
you wish to test for the mail routing. The last line tells you
|
||||
the used internal mail agent, the destination host this agent will
|
||||
be called with, and the (possibly translated) address. Leave this
|
||||
mode by typing Control-D.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>sendmail -bt</userinput>
|
||||
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
|
||||
Enter <ruleset> <address>
|
||||
<prompt>></prompt> <userinput>0 foo@interface-business.de</userinput>
|
||||
rewrite: ruleset 0 input: foo @ interface-business . de
|
||||
…
|
||||
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ interface-business . de</screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mailfaq">
|
||||
<title>FAQ</title>
|
||||
|
||||
<para><emphasis>Migration from FAQ.</emphasis></para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Why do I have to use the FQDN for hosts on my site?</title>
|
||||
|
||||
<para>You will probably find that the host is actually in a
|
||||
different domain; for example, if you are in <hostid role="fqdn">foo.bar.edu</hostid> and you
|
||||
wish to reach a host called <hostid>mumble</hostid> in the <hostid
|
||||
role="domainname">bar.edu</hostid> domain, you
|
||||
will have to refer to it by the fully-qualified domain name,
|
||||
<hostid role="fqdn">mumble.bar.edu</hostid>, instead of just <hostid>mumble</hostid>.</para>
|
||||
|
||||
<para>Traditionally, this was allowed by BSD BIND resolvers. However
|
||||
the current version of <application>BIND</application> that ships with
|
||||
FreeBSD no longer provides default abbreviations for non-fully
|
||||
qualified domain names other than the domain you are in. So an
|
||||
unqualified host <hostid>mumble</hostid> must either
|
||||
be found as <hostid role="fqdn">mumble.foo.bar.edu</hostid>, or
|
||||
it will be searched for in the root domain.</para>
|
||||
|
||||
<para>This is different from the previous behavior, where the search
|
||||
continued across <hostid role="domainname">mumble.bar.edu</hostid>,
|
||||
and <hostid role="domainname">mumble.edu</hostid>. Have a look at
|
||||
RFC 1535 for why this was considered bad practice, or even a
|
||||
security hole.</para>
|
||||
|
||||
<para>As a good workaround, you can place the line
|
||||
|
||||
<programlisting>
|
||||
search foo.bar.edu bar.edu</programlisting>
|
||||
|
||||
instead of the previous
|
||||
|
||||
<programlisting>
|
||||
domain foo.bar.edu</programlisting>
|
||||
|
||||
into your <filename>/etc/resolv.conf</filename>. However,
|
||||
make sure that the search order does not go beyond the “boundary
|
||||
between local and public administration”, as RFC 1535 calls
|
||||
it.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Sendmail says <errorname>mail loops back to myself</errorname></title>
|
||||
|
||||
<para>This is answered in the sendmail FAQ as follows:</para>
|
||||
|
||||
<programlisting>
|
||||
* I am getting "Local configuration error" messages, such as:
|
||||
|
||||
553 relay.domain.net config error: mail loops back to myself
|
||||
554 <user@domain.net>... Local configuration error
|
||||
|
||||
How can I solve this problem?
|
||||
|
||||
You have asked mail to the domain (e.g., domain.net) to be
|
||||
forwarded to a specific host (in this case, relay.domain.net)
|
||||
by using an MX record, but the relay machine does not recognize
|
||||
itself as domain.net. Add domain.net to /etc/sendmail.cw
|
||||
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
|
||||
to /etc/sendmail.cf.</programlisting>
|
||||
|
||||
<para>The sendmail FAQ is in
|
||||
<filename>/usr/src/usr.sbin/sendmail</filename> and is recommended
|
||||
reading if you want to do any “tweaking” of your mail
|
||||
setup.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>How can I do E-Mail with a dialup PPP host?</title>
|
||||
|
||||
<para>You want to connect a FreeBSD box on a lan, to the Internet.
|
||||
The FreeBSD box will be a mail gateway for the lan. The PPP
|
||||
connection is non-dedicated.</para>
|
||||
|
||||
<para>There are at least two way to do this.</para>
|
||||
|
||||
<para>The other is to use UUCP.</para>
|
||||
|
||||
<para>The key is to get a Internet site to provide secondary MX
|
||||
services for your domain. For example:</para>
|
||||
|
||||
<programlisting>
|
||||
bigco.com. MX 10 bigco.com.
|
||||
MX 20 smalliap.com.</programlisting>
|
||||
|
||||
<para>Only one host should be specified as the final recipient ( add
|
||||
<literal>Cw bigco.com</literal> in <filename>/etc/sendmail.cf</filename> on
|
||||
bigco.com).</para>
|
||||
|
||||
<para>When the senders <command>sendmail</command> is trying to deliver the mail it
|
||||
will try to connect to you over the modem link. It will most
|
||||
likely time out because you are not online. <command>sendmail</command> will
|
||||
automatically deliver it to the secondary MX site, ie your
|
||||
Internet provider. The secondary MX site will try every
|
||||
(<literal>sendmail_flags = "-bd -q15m"</literal> in
|
||||
<filename>/etc/rc.conf</filename> ) 15 minutes to connect to your
|
||||
host to deliver the mail to the primary MX site.</para>
|
||||
|
||||
<para>You might wat to use something like this as a login script.</para>
|
||||
|
||||
<programlisting>
|
||||
#!/bin/sh
|
||||
# Put me in /usr/local/bin/pppbigco
|
||||
( sleep 60 ; /usr/sbin/sendmail -q ) &
|
||||
/usr/sbin/ppp -direct pppbigco</programlisting>
|
||||
|
||||
<para>If you are going to create a separate
|
||||
login script for a user you could use <command>sendmail
|
||||
-qRbigco.com</command> instead in the script above. This will
|
||||
force all mail in your queue for bigco.com to be processed
|
||||
immediately.</para>
|
||||
|
||||
<para>A further refinement of the situation is as follows.</para>
|
||||
|
||||
<para>Message stolen from the freebsd-isp mailing list.</para>
|
||||
|
||||
<programlisting>
|
||||
> we provide the secondary mx for a customer. The customer connects to
|
||||
> our services several times a day automatically to get the mails to
|
||||
> his primary mx (We do not call his site when a mail for his domains
|
||||
> arrived). Our sendmail sends the mailqueue every 30 minutes. At the
|
||||
> moment he has to stay 30 minutes online to be sure that all mail is
|
||||
> gone to the primary mx.
|
||||
>
|
||||
> Is there a command that would initiate sendmail to send all the mails
|
||||
> now? The user has not root-privileges on our machine of course.
|
||||
|
||||
In the 'privacy flags' section of sendmail.cf, there is a definition
|
||||
Opgoaway,restrictqrun
|
||||
|
||||
Remove restrictqrun to allow non-root users to start the queue processing.
|
||||
You might also like to rearrange the MXs. We are the 1st MX for our
|
||||
customers like this, and we have defined:
|
||||
|
||||
# If we are the best MX for a host, try directly instead of generating
|
||||
# local config error.
|
||||
OwTrue
|
||||
|
||||
That way a remote site will deliver straight to you, without trying
|
||||
the customer connection. You then send to your customer. Only works for
|
||||
"hosts", so you need to get your customer to name their mail machine
|
||||
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
|
||||
an A record in the DNS for "customer.com".</programlisting>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
1257
en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
Normal file
1257
en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
480
en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml
Normal file
480
en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml
Normal file
|
|
@ -0,0 +1,480 @@
|
|||
<chapter id="pgpkeys">
|
||||
<title>PGP keys</title>
|
||||
|
||||
<para>In case you need to verify a signature or send encrypted email to
|
||||
one of the officers or core team members a number of keys are
|
||||
provided here for your convenience.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Officers</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>FreeBSD Security Officer <email>security-officer@freebsd.org</email></title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.imp;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Core Team members</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>&a.asami;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jmb;</title>
|
||||
|
||||
<programlisting>
|
||||
Jonathan M. Bresler <jmb@FreeBSD.org>
|
||||
Key fingerprint = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2
|
||||
|
||||
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
|
||||
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
|
||||
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
|
||||
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNA3x
|
||||
ffUVW/uOVC1dAQHGdAQAgsnYklBtVUdGuQwXB3bYp9omTD7CVD0aibVrz+lXiPDh
|
||||
aTVkOC1uhEwL59+R8VdpAnEDMobdZDA/ihCc+6/FW/eE0uyrWZzb5Ng9V1MfC6HI
|
||||
+sXpeXPy585Z56ewadV2yY9rvzcwmmUNHmAXT/5O0S2AWB0EJZ+cewTrokSTVVOJ
|
||||
AJUDBRA0C3EoVS4eLnPSiKUBASb+A/95g6w9DDPRGDlbsl4pN1BlSPKrmDQPRK1X
|
||||
C3bddDY2HNelSNhzp2FYD0WoN1re1vMJV0oaaJHwv7wjbe3+SYEX/IdmtfzI0MbZ
|
||||
Q/uPybPJOxi2ud6C6J+mEGJN9iBCnsaCz8CETuC9gR1mtxsxySUj9mk0fxKfdP6S
|
||||
3QDrv6CQ1IkAlQMFEDKsi9CzWmLrWZ8yPQEBduUD/RhV4Qa89rYls9vtIFm6XBjZ
|
||||
8mW37FYxeqIxg3ZrIyTMlghsOPV0f7zymCCWPRGKOLePRiGo0ZCEkDTYiM9tnwQI
|
||||
09rmPWJb50yfTSZXjHx6+Hcm6O6BCmDFloo0Mxo6n9pvMH/TmmqHxCsAV+p8XEWy
|
||||
rMZvwVSynMxmJd17Y5HLtBNKb25hdGhhbiBNLiBCcmVzbGVyiQCVAwUQMbYtYQHb
|
||||
XdKX5jjdAQHEHwP/fEaQoTi7zKD1U/5kW2YPIBUyMTpLiO9QOr4stYjJvhHh4Ejw
|
||||
fGvMIhbFrPKtxSNH1s3m4jAXKXiQBDCz17IIzL4n8dlunxNGE5MHcsmpWzggyIg4
|
||||
zbPqPOcg4gLFEWsEkr2o0akwzIGa3tbCvC+ITaX/rdlWV1jaQjTqSNyPZBM=
|
||||
=RV56
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.ache;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jkh;</title>
|
||||
|
||||
<programlisting>
|
||||
Jordan K. Hubbard <jkh@FreeBSD.org>
|
||||
Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2i
|
||||
|
||||
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
|
||||
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
|
||||
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
|
||||
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokAlQMFEDF75D1r
|
||||
WmeNgbKneQEBXtcD+gJIv8JzZRKlDZyTCQanK8iRgE+zMhxptI0kDObaGxT1BrpY
|
||||
4/EPyiUN10G4k2Jb+DOc8Lg2xDQ3xmvgipFf9NMNV/ThaEuZ3wA31I6tW/arQEqB
|
||||
Tp8u6T3v20m62t7Afo9HaoE6MBpHQUk2TilxgAd5P57sporL3pgW9YojIO9ziQCV
|
||||
AwUQMXyV2h9/qQgDWPy9AQEMfgP/RmbSg2WlesATUQ4WuanjcdREduKPyfQatrXD
|
||||
2xt+jg9X78dTyiNN1YvLqvT6msfs04MKSC0hA2mou6ozw8Xak+1QmP0fBOZKp9pP
|
||||
8szO188Do9ByzJPvHF1eXT7jFMOXVq8ZIl9iwjxcIDLzlxOz49DC7LO6AT+LKQk7
|
||||
UGeP+lqJAJUDBRAxe+UG9RVb+45ULV0BAXZ9A/9F9gLpGukVNkeOjaqxQdJGTS+a
|
||||
xh/Abk0c/nKhAEyxpAl5JyQ3ifYk6BHhPvlTi9LrZoXGA8sk/eU4eRTZVzvGEC4G
|
||||
+xsavlE/xzku8855QTLPpkCunUpQeu1wzaIrUUE6Zjh05imFbJYyQOBgTFpuqWsC
|
||||
rsUpl+2mr8IGIxG5rA==
|
||||
=LW9i
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.phk;</title>
|
||||
|
||||
<programlisting>
|
||||
Poul-Henning Kamp <phk@FreeBSD.org>
|
||||
Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.3ia
|
||||
|
||||
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI
|
||||
ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA
|
||||
K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR
|
||||
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDMGK9qz
|
||||
WmLrWZ8yPQEB4iED/18bQVhV2gUYFSxIUTaUtO2HVPi7GRpSzmXoTfS+FJyRR0ED
|
||||
zTqTHstoBe2PeWgTsOf9cUub5UKcJkRQp7VrJv4Kncyuq7pX69a+QMveCzuUwAur
|
||||
nDbt/emOL6NU8g9Uk50QuOuipb5rULQLRRoF5TkViy/VES83ERXdYQ9Ml3fWiQCV
|
||||
AwUQMX6NfWtaZ42Bsqd5AQEKsgP+L+uLz95dRdEmnZ+omrO+tYZM/0jHU7i8yC5q
|
||||
H0gguKOCljI4liR7NkqKONUJWYtfsTB81d9iSosBZRrTx6i/hB8l8kOB975n/f9S
|
||||
hftFwmjLYCNMFlDM4j0kySvMV20UZjAyv9BeE51VWlIZ5n/oeSuzul3Znow02tF/
|
||||
zVnInJiJAJUDBRAxfJXn9RVb+45ULV0BAXJ8A/9K6NT6VLZZC5q3g7bBk5DWuzBS
|
||||
3oK2Ebww6xzsD2R9edltoz1J3GPngK0CWpHh4kw5iTaRWoC2YJYRNG6icnGvlMAl
|
||||
1/urqQHJVhxATINm8oljDKsj1RBJ6VKBzNbCJIHTVpX0AJoqUQX2Idi8goFr0fAm
|
||||
7cD2CBb1JhoAdzEfO4kAlQMFEDFLHlwff6kIA1j8vQEBj5MD/1hA8hJdhpL7mvQj
|
||||
rTAIn6Ldr08Lr1lqTaKSBMdCL3suGlW0Sw/dIBgicPDhgxLahT3DVfGiIst32FSl
|
||||
xmWY7wine80X4TZkJ9Hiw3Mpqtjl92j6zHNq0ZZE+CceNubpEdYLDqokAIMPdWlo
|
||||
WPHZcPxCs5PKI5udseFYF2gQAjI2iQCVAwUQMTlDoO9huekR1Y7VAQGy+AP/Rzp+
|
||||
UGtJavbSiPx5EnXOXxkA/+ulXQgQG9vdkWwewkvxDNOzHW3KkUWCGtPtIMENznbF
|
||||
j3QlYB+USIaf1ogvlD5EdXGPDfTINpE8CX2WXzajfgYFpYETDzduwjoWDZfEN9zZ
|
||||
fQqQS62VgAReOIz3k9BL708z/+WUO0++RLGCmImJAJUDBRAw5q8kAPLZCeu7G0EB
|
||||
AT3bBACwo+r9TgbiSyyU5cZpq5KgGT1c7eUHXjtxKmtrXD1nFNJ6j7x2DM2XGe6B
|
||||
YOfDWbFq4UkEAyAeXviuuUP4enQu1v2g7JGXeuI8bRM519pLdPzDq/DnbA4rNStn
|
||||
/SkH7awMfNSplcFuE6rc5ezVkw17eOHzDrYmwsFavL9gxZEycg==
|
||||
=Q45T
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.rich;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jdp;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.guido;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.peter;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.joerg;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
283
en_US.ISO8859-1/books/handbook/policies/chapter.sgml
Normal file
283
en_US.ISO8859-1/books/handbook/policies/chapter.sgml
Normal file
|
|
@ -0,0 +1,283 @@
|
|||
<chapter id="policies">
|
||||
<title>Source Tree Guidelines and Policies</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.phk;.</emphasis></para>
|
||||
|
||||
<para>This chapter documents various guidelines and policies in force
|
||||
for the FreeBSD source tree.</para>
|
||||
|
||||
|
||||
<sect1 id="policies-maintainer">
|
||||
<title><makevar>MAINTAINER</makevar> on Makefiles</title>
|
||||
|
||||
<para>June 1996.</para>
|
||||
|
||||
<para>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
|
||||
|
||||
<programlisting>
|
||||
MAINTAINER= email-addresses</programlisting>
|
||||
|
||||
line to the <filename>Makefile</filename>s covering this portion
|
||||
of the source tree.</para>
|
||||
|
||||
<para>The semantics of this are as follows:</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Contributed Software</title>
|
||||
|
||||
<para>June 1996.</para>
|
||||
|
||||
<para>Some parts of the FreeBSD distribution consist of software that
|
||||
is actively being maintained outside the FreeBSD project. For
|
||||
historical reasons, we call this <emphasis>contributed</emphasis>
|
||||
software. Some examples are perl, gcc and patch.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The <application>Tcl</application> embedded programming
|
||||
language will be used as example of how this model works:</para>
|
||||
|
||||
<para><filename>src/contrib/tcl</filename> 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 <filename>mac</filename>, <filename>win</filename> and
|
||||
<filename>compat</filename> subdirectories were eliminated before
|
||||
the import</para>
|
||||
|
||||
<para><filename>src/lib/libtcl</filename> contains only a "bmake style"
|
||||
<filename>Makefile</filename> that uses the standard
|
||||
<filename>bsd.lib.mk</filename> makefile rules to produce the
|
||||
library and install the documentation.</para>
|
||||
|
||||
<para><filename>src/usr.bin/tclsh</filename> contains only a bmake style
|
||||
<filename>Makefile</filename> which will produce and install the
|
||||
<command>tclsh</command> program and its associated man-pages using the standard
|
||||
<filename>bsd.prog.mk</filename> rules.</para>
|
||||
|
||||
<para><filename>src/tools/tools/tcl_bmake</filename> 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.</para>
|
||||
|
||||
<para>The important thing here is that the
|
||||
<filename>src/contrib/tcl</filename> directory is created according
|
||||
to the rules: It is supposed to contain the sources as distributed
|
||||
(on a proper CVS vendor-branch) with as few FreeBSD-specific changes
|
||||
as possible. The 'easy-import' tool on freefall will assist in
|
||||
doing the import, but if there are any doubts on how to go about it,
|
||||
it is imperative that you ask first and not blunder ahead and hope
|
||||
it “works out”. CVS is not forgiving of import accidents and a fair
|
||||
amount of effort is required to back out major mistakes.</para>
|
||||
|
||||
<para>Because of some unfortunate design limitations with CVS's vendor
|
||||
branches, it is required that “official” patches from the vendor be
|
||||
applied to the original distributed sources and the result
|
||||
re-imported onto the vendor branch again. Official patches should
|
||||
never be patched into the FreeBSD checked out version and
|
||||
"committed", as this destroys the vendor branch coherency and makes
|
||||
importing future versions rather difficult as there will be
|
||||
conflicts.</para>
|
||||
|
||||
<para>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 <emphasis>not</emphasis> be
|
||||
removed.</para>
|
||||
|
||||
<para>If it seems easier, the <command>bmake</command> <filename>Makefile</filename>s
|
||||
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 <filename>src/tools</filename> directory along
|
||||
with the port itself so that it is available to future
|
||||
maintainers.</para>
|
||||
|
||||
<para>In the <filename>src/contrib/tcl</filename> level directory, a
|
||||
file called <filename>FREEBSD-upgrade</filename> should be added and
|
||||
it should states things like:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Which files have been left out</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Where the original distribution was obtained from and/or
|
||||
the official master site.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Where to send patches back to the original authors</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Perhaps an overview of the FreeBSD-specific changes that
|
||||
have been made.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>However, please do not import
|
||||
<filename>FREEBSD-upgrade</filename> with the contributed source.
|
||||
Rather you should <command>cvs add FREEBSD-upgrade ; cvs ci</command> after the
|
||||
initial import. Example wording from
|
||||
<filename>src/contrib/cpio</filename> is below:</para>
|
||||
|
||||
<programlisting>
|
||||
This directory contains virgin sources of the original distribution files
|
||||
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
|
||||
the files in this directory via patches and a cvs commit. New versions or
|
||||
official-patch versions must be imported. Please remember to import with
|
||||
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
|
||||
|
||||
For the import of GNU cpio 2.4.2, the following files were removed:
|
||||
|
||||
INSTALL cpio.info mkdir.c
|
||||
Makefile.in cpio.texi mkinstalldirs
|
||||
|
||||
To upgrade to a newer version of cpio, when it is available:
|
||||
1. Unpack the new version into an empty directory.
|
||||
[Do not make ANY changes to the files.]
|
||||
|
||||
2. Remove the files listed above and any others that don't apply to
|
||||
FreeBSD.
|
||||
|
||||
3. Use the command:
|
||||
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
|
||||
src/contrib/cpio GNU cpio_<version>
|
||||
|
||||
For example, to do the import of version 2.4.2, I typed:
|
||||
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
|
||||
src/contrib/cpio GNU cpio_2_4_2
|
||||
|
||||
4. Follow the instructions printed out in step 3 to resolve any
|
||||
conflicts between local FreeBSD changes and the newer version.
|
||||
|
||||
Do not, under any circumstances, deviate from this procedure.
|
||||
|
||||
To make local changes to cpio, simply patch and commit to the main
|
||||
branch (aka HEAD). Never make local changes on the GNU branch.
|
||||
|
||||
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
|
||||
inclusion in the next vendor release.
|
||||
|
||||
obrien@freebsd.org - 30 March 1997</programlisting>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-shlib">
|
||||
<title>Shared Libraries</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.asami;, &a.peter;, and
|
||||
&a.obrien;.<!-- <br> --> 9 December 1996.</emphasis></para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The three principles of shared library building are:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Start from <literal>1.0</literal></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If there is a change that is backwards compatible, bump
|
||||
minor number</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If there is an incompatible change, bump major
|
||||
number</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>For instance, added functions and bugfixes result in the minor
|
||||
version number being bumped, while deleted functions, changed
|
||||
function call syntax etc. will force the major version number to
|
||||
change.</para>
|
||||
|
||||
<para>Stick to version numbers of the form major.minor (<replaceable>x</replaceable>.<replaceable>y</replaceable>). Our
|
||||
dynamic linker does not handle version numbers of the form <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
|
||||
well. Any version number after the <replaceable>y</replaceable> (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, <command>ld.so</command> will link with the higher one.
|
||||
Ie: if you link with <filename>libfoo.so.3.3.3</filename>, the
|
||||
linker only records <literal>3.3</literal> in the headers, and will link with anything
|
||||
starting with <replaceable>libfoo.so.3</replaceable>.<replaceable>(anything >=
|
||||
3)</replaceable>.<replaceable>(highest available)</replaceable>.</para>
|
||||
|
||||
<note>
|
||||
<para><command>ld.so</command> will always use the highest
|
||||
“minor” revision. Ie: it will use <filename>libc.so.2.2</filename>
|
||||
in preference to <filename>libc.so.2.0</filename>, even if the
|
||||
program was initially linked with
|
||||
<filename>libc.so.2.0</filename>.</para>
|
||||
</note>
|
||||
|
||||
<para>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 <filename>Makefile</filename>'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 <filename>Makefile</filename> to be updated,
|
||||
and any subsequent changes will not.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
2568
en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml
Normal file
2568
en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
4938
en_US.ISO8859-1/books/handbook/printing/chapter.sgml
Normal file
4938
en_US.ISO8859-1/books/handbook/printing/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1698
en_US.ISO8859-1/books/handbook/security/chapter.sgml
Normal file
1698
en_US.ISO8859-1/books/handbook/security/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
2088
en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
Normal file
2088
en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
683
en_US.ISO8859-1/books/handbook/staff/chapter.sgml
Normal file
683
en_US.ISO8859-1/books/handbook/staff/chapter.sgml
Normal file
|
|
@ -0,0 +1,683 @@
|
|||
<chapter id="staff">
|
||||
<title>FreeBSD Project Staff</title>
|
||||
|
||||
<para>The FreeBSD Project is managed and operated by the following
|
||||
groups of people:</para>
|
||||
|
||||
|
||||
<sect1 id="staff-core">
|
||||
<title>The FreeBSD Core Team</title>
|
||||
|
||||
<para>The FreeBSD core team constitutes the project's “Board of
|
||||
Directors”, responsible for deciding the project's overall goals
|
||||
and direction as well as managing <xref linkend="staff-who"
|
||||
remap="specific
|
||||
areas"> of the FreeBSD project landscape.</para>
|
||||
|
||||
<para>(in alphabetical order by last name):</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>&a.asami;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ache;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dyson;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.bde;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gibbs;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.davidg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.phk;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rich;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gpalmer;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jdp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.guido;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.sos;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.peter;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wollman;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.joerg;</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-committers">
|
||||
<title>The FreeBSD Developers</title>
|
||||
|
||||
<para>These are the people who have commit privileges and do the
|
||||
engineering work on the FreeBSD source tree. All core team members
|
||||
and most FreeBSD Documentation project personnel are also
|
||||
developers.</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mbarkah;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.stb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.torstenb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.danny;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.charnier;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.kjc;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gclarkii;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cracauer;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.adam;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dufault;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.uhclem;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tegge;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.eivind;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.julian;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rse;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.se;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.sef;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.fenner;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfitz;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.lars;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.scrappy;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.brandon;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.graichen;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jgreco;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rgrimes;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hanai;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ahasty;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jhay;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.helbig;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.erich;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hsu;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.itojun;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ugen;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gj;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ljo;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.kato;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.andreas;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.imp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.smace;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mckay;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jlemon;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tedm;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.amurai;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.markm;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.max;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.alex;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.davidn;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.obrien;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.fsmp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.smpatel;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wpaul;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmacd;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.steve;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mpp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dfr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jraynard;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.darrenr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.csgr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.martin;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.paul;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.roberto;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.chuckr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dima;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wosch;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ats;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jseger;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.vanilla;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.msmith;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.brian;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.stark;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.karl;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cwt;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.pst;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hoek;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.swallace;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nate;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.yokota;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmz;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hosokawa;</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-doc">
|
||||
<title>The FreeBSD Documentation Project</title>
|
||||
|
||||
<para>The <ulink URL="http://www.freebsd.org/docproj.html">FreeBSD
|
||||
Documentation Project</ulink> is responsible for a number of
|
||||
different services, each service being run by an individual and his
|
||||
<emphasis>deputies</emphasis> (if any):</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>Documentation Project Manager</term>
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Webmaster</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mbarkah;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.paul;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Handbook & FAQ Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.faq;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Build Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.paul;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.dave;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Mirror Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ulf;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.john;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>News Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.john;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Gallery and Commercial Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.cawimm;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Style Police & Art Director</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dave;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.opsys;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Database Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mayo;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.cracauer;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>CGI Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cracauer;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.stb;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Bottle Washing</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Drying plates:</emphasis> &a.nik;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-who">
|
||||
<title>Who Is Responsible for What</title>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>Principal Architect</term>
|
||||
<listitem>
|
||||
<para>&a.davidg;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Documentation Project Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Internationalization</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ache;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Networking</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wollman;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Postmaster</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmb;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Release Coordinator</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Public Relations & Corporate
|
||||
Liaison</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Security Officer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.guido;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Source Repository Managers</term>
|
||||
|
||||
<listitem>
|
||||
<para>Principal: &a.peter;</para>
|
||||
|
||||
<para>Assistant: &a.jdp;</para>
|
||||
|
||||
<para>International (Crypto): &a.markm;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Ports Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.asami;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>XFree86 Project, Inc. Liaison</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rich;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Usenet Support</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.joerg;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>GNATS Administrator</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.steve;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
8
en_US.ISO8859-1/books/handbook/x11/chapter.sgml
Normal file
8
en_US.ISO8859-1/books/handbook/x11/chapter.sgml
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
<chapter id="x11">
|
||||
<title>The X Window System</title>
|
||||
|
||||
<para>Pending the completion of this section, please refer to
|
||||
documentation supplied by the <ulink URL="http://www.xfree86.org/">The
|
||||
XFree86 Project, Inc</ulink>.</para>
|
||||
|
||||
</chapter>
|
||||
1008
en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml
Normal file
1008
en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
136
en_US.ISO_8859-1/books/handbook/basics/chapter.sgml
Normal file
136
en_US.ISO_8859-1/books/handbook/basics/chapter.sgml
Normal file
|
|
@ -0,0 +1,136 @@
|
|||
<chapter id="basics">
|
||||
<title>Unix Basics</title>
|
||||
|
||||
|
||||
<sect1 id="basics-man">
|
||||
<title>The Online Manual</title>
|
||||
|
||||
<para>The most comprehensive documentation on FreeBSD is in the form
|
||||
of <emphasis>man pages</emphasis>. 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
|
||||
<command>man</command>
|
||||
command. Use of the <command>man</command> command is simple:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man <replaceable>command</replaceable></userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><replaceable>command</replaceable> is
|
||||
the name of the command you wish to learn about. For example, to
|
||||
learn more about <command>ls</command> command type:</para>
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man ls</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The online manual is divided up into numbered sections:</para>
|
||||
|
||||
<orderedlist>
|
||||
|
||||
<listitem>
|
||||
<para>User commands</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>System calls and error numbers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Functions in the C libraries</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Device drivers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>File formats</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Games and other diversions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Miscellaneous information</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>System maintenance and operation commands</para>
|
||||
</listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
<para>In some cases, the same topic may appear in more than
|
||||
one section of the on-line manual. For example, there is a
|
||||
<command>chmod</command>
|
||||
user command and a <function>chmod()</function> system call. In
|
||||
this case, you can tell the <command>man</command> command which one you want by
|
||||
specifying the section:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man 1 chmod</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will display the manual page for the user
|
||||
command <command>chmod</command>. References to a
|
||||
particular section of the on-line manual are traditionally placed in
|
||||
parenthesis in written documentation, so <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry> refers to the
|
||||
<command>chmod</command>
|
||||
user command and <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>2</manvolnum></citerefentry> refers to the
|
||||
system call.</para>
|
||||
|
||||
<para>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 <command>man</command> to search for keywords in the
|
||||
command <emphasis>descriptions</emphasis> by using the
|
||||
<option>-k</option> switch:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>man -k mail</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>With this command you will be presented with a
|
||||
list of commands that have the keyword “mail” in their descriptions.
|
||||
This is actually functionally equivalent to using the <command>apropos</command>
|
||||
command.</para>
|
||||
|
||||
<para>So, you are looking at all those fancy commands in
|
||||
<filename>/usr/bin</filename> but do not even have the faintest idea
|
||||
what most of them actually do? Simply do a
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>cd /usr/bin; man -f *</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
or
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>cd /usr/bin; whatis *</userinput></screen>
|
||||
</informalexample> which does the same thing.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="basics-info">
|
||||
<title>GNU Info Files</title>
|
||||
|
||||
<para>FreeBSD includes many applications and utilities produced by the
|
||||
Free Software Foundation (FSF). In addition to man pages, these
|
||||
programs come with more extensive hypertext documents called
|
||||
“info” files which can be viewed with the
|
||||
<command>info</command> command or, if you installed
|
||||
<command>emacs</command>, the info mode of <command>emacs</command>.</para>
|
||||
|
||||
<para>To use the <citerefentry><refentrytitle>info</refentrytitle><manvolnum>1</manvolnum></citerefentry> command, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>info</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>For a brief introduction, type <userinput>h</userinput>. For a quick
|
||||
command reference, type <userinput>?</userinput>.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
478
en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml
Normal file
478
en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml
Normal file
|
|
@ -0,0 +1,478 @@
|
|||
<chapter id="bibliography">
|
||||
<title>Bibliography</title>
|
||||
|
||||
<para>While 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.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Books & Magazines Specific to FreeBSD</title>
|
||||
|
||||
<para><emphasis>International books &
|
||||
Magazines:</emphasis></para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://freebsd.csie.nctu.edu.tw/~jdli/book.html">Using
|
||||
FreeBSD</ulink> (in Chinese).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD for PC 98'ers (in Japanese), published by SHUWA
|
||||
System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD (in Japanese), published by CUTT. ISBN
|
||||
4-906391-22-2 C3055 P2400E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.shoeisha.co.jp/pc/index/shinkan/97_05_06.htm">Complete Introduction to FreeBSD</ulink> (in Japanese), published by <ulink URL="http://www.shoeisha.co.jp/">Shoeisha Co., Ltd</ulink>. ISBN 4-88135-473-6 P3600E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.ascii.co.jp/pb/book1/shinkan/detail/1322785.html">Personal UNIX Starter Kit FreeBSD</ulink> (in Japanese), published by <ulink URL="http://www.ascii.co.jp/">ASCII</ulink>. ISBN 4-7561-1733-3 P3000E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD Handbook (Japanese translation), published by
|
||||
<ulink URL="http://www.ascii.co.jp/">ASCII</ulink>. ISBN
|
||||
4-7561-1580-2 P3800E.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para><emphasis>English language books &
|
||||
Magazines:</emphasis></para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="http://www.cdrom.com/titles/os/bsdbook2.htm">The
|
||||
Complete FreeBSD</ulink>, published by <ulink
|
||||
URL="http://www.cdrom.com">Walnut Creek
|
||||
CDROM</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Users' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD User's Reference Manual</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1994.<!-- <br> --> ISBN
|
||||
1-56592-075-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD User's Supplementary Documents</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1994.<!-- <br> --> ISBN
|
||||
1-56592-076-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>UNIX in a Nutshell</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1990.<!-- <br> --> ISBN
|
||||
093717520X</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Mui, Linda. <emphasis>What You Need To Know When You Can't
|
||||
Find Your UNIX System Administrator</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1995. <!-- <br> --> ISBN 1-56592-104-6</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink URL="http://www-wks.acs.ohio-state.edu/">Ohio State
|
||||
University</ulink> has written a <ulink
|
||||
URL="http://www-wks.acs.ohio-state.edu/unix_course/unix.html">UNIX Introductory Course</ulink> which is available online in HTML and postscript format.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Administrators' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Albitz, Paul and Liu, Cricket. <emphasis>DNS and
|
||||
BIND</emphasis>, 2nd Ed. O'Reilly & Associates, Inc.,
|
||||
1997. <!-- <br> --> ISBN 1-56592-236-0</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD System Manager's Manual</emphasis>. O'Reilly
|
||||
& Associates, Inc., 1994. <!-- <br> --> ISBN
|
||||
1-56592-080-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Costales, Brian, et al. <emphasis>Sendmail</emphasis>, 2nd
|
||||
Ed. O'Reilly & Associates, Inc., 1997.<!-- <br> --> ISBN
|
||||
1-56592-222-0</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Frisch, Æleen. <emphasis>Essential System
|
||||
Administration</emphasis>, 2nd Ed. O'Reilly &
|
||||
Associates, Inc., 1995. <!-- <br> -->ISBN 1-56592-127-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hunt, Craig. <emphasis>TCP/IP Network
|
||||
Administration</emphasis>. O'Reilly & Associates, Inc.,
|
||||
1992. <!-- <br> --> ISBN 0-937175-82-X</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Nemeth, Evi. <emphasis>UNIX System Administration
|
||||
Handbook</emphasis>. 2nd ed. Prentice Hall, 1995. <!-- <br>
|
||||
--> ISBN 0131510517</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stern, Hal <emphasis>Managing NFS and NIS</emphasis>
|
||||
O'Reilly & Associates, Inc., 1991. <!-- <br> --> ISBN
|
||||
0-937175-75-7</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Programmers' Guides</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Asente, Paul. <emphasis>X Window System
|
||||
Toolkit</emphasis>. Digital Press. <!-- <br> --> ISBN
|
||||
1-55558-051-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD Programmer's Reference Manual</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1994. <!-- <br> --> ISBN
|
||||
1-56592-078-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD Programmer's Supplementary
|
||||
Documents</emphasis>. O'Reilly & Associates, Inc., 1994.
|
||||
<!-- <br> --> ISBN 1-56592-079-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ellis, Margaret A. and Stroustrup, Bjarne. <emphasis>The
|
||||
Annotated C++ Reference Manual</emphasis>. Addison-Wesley,
|
||||
1990. <!-- <br> --> ISBN 0-201-51459-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Harbison, Samuel P. and Steele, Guy L. Jr. <emphasis>C: A
|
||||
Reference Manual</emphasis>. 4rd ed. Prentice Hall, 1995.
|
||||
<!-- <br> -->ISBN 0-13-326224-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Kernighan, Brian and Dennis M. Ritchie. <emphasis>The C
|
||||
Programming Language.</emphasis>. PTR Prentice Hall, 1988.
|
||||
<!-- <br> --> ISBN 0-13-110362-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Lehey, Greg. <emphasis>Port UNIX Software</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1995.<!-- <br> --> ISBN
|
||||
1-56592-126-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Plauger, P. J. <emphasis>The Standard C
|
||||
Library</emphasis>. Prentice Hall, 1992. <!-- <br> --> ISBN
|
||||
0-13-131509-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>Advanced Programming in the
|
||||
UNIX Environment</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1992<!-- <br> --> ISBN 0-201-56317-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>UNIX Network
|
||||
Programming</emphasis>. PTR Prentice Hall, 1990. <!-- <br>
|
||||
--> ISBN 0-13-949876-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wells, Bill. “Writing Serial Drivers for UNIX”.
|
||||
<emphasis>Dr. Dobb's Journal</emphasis>. 19(15), December
|
||||
1994. pp68-71, 97-99.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Operating System Internals</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Andleigh, Prabhat K. <emphasis>UNIX System
|
||||
Architecture</emphasis>. Prentice-Hall, Inc., 1990.<!-- <br>
|
||||
--> ISBN 0-13-949843-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Jolitz, William. “Porting UNIX to the
|
||||
386”. <emphasis>Dr.
|
||||
Dobb's Journal</emphasis>. January 1991-July 1992.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Leffler, Samuel J., Marshall Kirk McKusick, Michael J
|
||||
Karels and John Quarterman <emphasis>The Design and
|
||||
Implementation of the 4.3BSD UNIX Operating
|
||||
System</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1989.<!-- <br> --> ISBN 0-201-06196-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Leffler, Samuel J., Marshall Kirk McKusick, <emphasis>The
|
||||
Design and Implementation of the 4.3BSD UNIX Operating
|
||||
System: Answer Book</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1991.<!-- <br> --> ISBN 0-201-54629-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
|
||||
and John Quarterman. <emphasis>The Design and Implementation
|
||||
of the 4.4BSD Operating System</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1996.<!-- <br> --> ISBN 0-201-54979-4</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume
|
||||
1: The Protocols</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1996.<!-- <br> --> ISBN 0-201-63346-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume
|
||||
3: TCP for Transactions, HTTP, NNTP and the UNIX Domain
|
||||
Protocols</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1996.<!-- <br> --> ISBN 0-201-63495-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Vahalia, Uresh. <emphasis>UNIX Internals -- The New
|
||||
Frontiers</emphasis>. Prentice Hall, 1996.<!-- <br> --> ISBN
|
||||
0-13-101908-2</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wright, Gary R. and W. Richard Stevens. <emphasis>TCP/IP
|
||||
Illustrated, Volume 2: The Implementation</emphasis>.
|
||||
Reading, Mass. : Addison-Wesley, 1995.<!-- <br> --> ISBN
|
||||
0-201-63354-X</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Security Reference</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Cheswick, William R. and Steven M. Bellovin.
|
||||
<emphasis>Firewalls and Internal Security: Repelling the Wily
|
||||
Hacker</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1995.<!-- <br> --> ISBN 0-201-63357-4</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Garfinkel, Simson and Gene Spafford. <emphasis>Practical
|
||||
UNIX Security</emphasis>. 2nd Ed. O'Reilly & Associates,
|
||||
Inc., 1996. <!-- <br> --> ISBN 1-56592-148-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Garfinkel, Simson. <emphasis>PGP Pretty Good
|
||||
Privacy</emphasis> O'Reilly & Associates, Inc., 1995.
|
||||
<!-- <br> --> ISBN 1-56592-098-8</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Hardware Reference</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Anderson, Don and Tom Shanley. <emphasis>Pentium Processor
|
||||
System Architecture</emphasis>. 2nd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995.<!-- <br> --> ISBN 0-201-40992-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ferraro, Richard F. <emphasis>Programmer's Guide to the
|
||||
EGA, VGA, and Super VGA Cards</emphasis>. 3rd ed. Reading,
|
||||
Mass. : Addison-Wesley, 1995.<!-- <br> --> ISBN
|
||||
0-201-62490-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>80486 System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <!-- <br> -->ISBN 0-201-40994-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>ISA System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995.<!-- <br> --> ISBN 0-201-40996-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>PCI System
|
||||
Architecture</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <!-- <br> -->ISBN 0-201-40993-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Van Gilluwe, Frank. <emphasis>The Undocumented
|
||||
PC</emphasis>. Reading, Mass: Addison-Wesley Pub. Co.,
|
||||
1994.<!-- <br> --> ISBN 0-201-62277-7</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>UNIX History</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Lion, John <emphasis>Lion's Commentary on UNIX, 6th Ed.
|
||||
With Source Code</emphasis>. ITP Media Group, 1996.<!-- <br>
|
||||
--> ISBN 1573980137</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Raymond, Eric s. <emphasis>The New Hacker's Dictonary, 3rd
|
||||
edition</emphasis>. MIT Press, 1996.<!-- <br> --> ISBN
|
||||
0-262-68092-0<!-- <br> --> Also known as the <ulink
|
||||
URL="http://www.ccil.org/jargon/jargon.html">Jargon
|
||||
File</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Salus, Peter H. <emphasis>A quarter century of
|
||||
UNIX</emphasis>. Addison-Wesley Publishing Company, Inc.,
|
||||
1994.<!-- <br> --> ISBN 0-201-54777-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Simon Garfinkel, Daniel Weise, Steven Strassmann.
|
||||
<emphasis>The UNIX-HATERS Handbook</emphasis>. IDG Books
|
||||
Worldwide, Inc., 1994.<!-- <br> --> ISBN 1-56884-203-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don Libes, Sandy Ressler <emphasis>Life with
|
||||
UNIX</emphasis> — special edition. Prentice-Hall, Inc.,
|
||||
1989.<!-- <br> --> ISBN 0-13-536657-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The BSD family tree</emphasis>. 1997.<!-- <br>
|
||||
--> <ulink
|
||||
URL="http://www.de.freebsd.org/de/ftp/unix-stammbaum">http://www.de.freebsd.org/de/ftp/unix-stammbaum</ulink> or <ulink URL="file:/usr/share/misc/bsd-family-tree">local</ulink> on a FreeBSD-current machine.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The BSD Release Announcements
|
||||
collection</emphasis>. 1997.<!-- <br> --> <ulink
|
||||
URL="http://www.de.FreeBSD.ORG/de/ftp/releases/">http://www.de.FreeBSD.ORG/de/ftp/releases/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Networked Computer Science Technical Reports
|
||||
Library</emphasis>.<!-- <br> --> <ulink
|
||||
URL="http://www.ncstrl.org/">http://www.ncstrl.org/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Magazines and Journals</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The C/C++ Users Journal</emphasis>. R&D
|
||||
Publications Inc. ISSN 1075-2838</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Sys Admin — The Journal for UNIX System
|
||||
Administrators</emphasis> Miller Freeman, Inc., ISSN
|
||||
1061-2688</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
File diff suppressed because it is too large
Load diff
47
en_US.ISO_8859-1/books/handbook/chapters.ent
Normal file
47
en_US.ISO_8859-1/books/handbook/chapters.ent
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
<!--
|
||||
Creates entities for each chapter in the FreeBSD Handbook. Each entity
|
||||
is named chap.foo, where foo is the value of the id attribute on that
|
||||
chapter, and corresponds to the name of the directory in which that
|
||||
chapter's .sgml file is stored.
|
||||
|
||||
Chapters should be listed in the order in which they are referenced.
|
||||
|
||||
$Id: chapters.ent,v 1.1 1998-11-03 23:16:38 nik Exp $
|
||||
-->
|
||||
|
||||
<!-- Part one -->
|
||||
<!ENTITY chap.introduction SYSTEM "introduction/chapter.sgml">
|
||||
<!ENTITY chap.install SYSTEM "install/chapter.sgml">
|
||||
<!ENTITY chap.basics SYSTEM "basics/chapter.sgml">
|
||||
<!ENTITY chap.ports SYSTEM "ports/chapter.sgml">
|
||||
|
||||
<!-- Part two -->
|
||||
<!ENTITY chap.kernelconfig SYSTEM "kernelconfig/chapter.sgml">
|
||||
<!ENTITY chap.security SYSTEM "security/chapter.sgml">
|
||||
<!ENTITY chap.printing SYSTEM "printing/chapter.sgml">
|
||||
<!ENTITY chap.quotas SYSTEM "quotas/chapter.sgml">
|
||||
<!ENTITY chap.x11 SYSTEM "x11/chapter.sgml">
|
||||
<!ENTITY chap.hw SYSTEM "hw/chapter.sgml">
|
||||
<!ENTITY chap.l10n SYSTEM "l10n/chapter.sgml">
|
||||
|
||||
<!-- Part three -->
|
||||
<!ENTITY chap.serialcomms SYSTEM "serialcomms/chapter.sgml">
|
||||
<!ENTITY chap.ppp-and-slip SYSTEM "ppp-and-slip/chapter.sgml">
|
||||
<!ENTITY chap.advanced-networking SYSTEM "advanced-networking.sgml">
|
||||
<!ENTITY chap.mail SYSTEM "mail/chapter.sgml">
|
||||
|
||||
<!-- Part four -->
|
||||
<!ENTITY chap.cutting-edge SYSTEM "cutting-edge/chapter.sgml">
|
||||
<!ENTITY chap.contrib SYSTEM "contrib/chapter.sgml">
|
||||
<!ENTITY chap.policies SYSTEM "policies/chapter.sgml">
|
||||
<!ENTITY chap.kernelopts SYSTEM "kernelopts/chapter.sgml">
|
||||
<!ENTITY chap.kerneldebug SYSTEM "kerneldebug/chapter.sgml">
|
||||
<!ENTITY chap.linuxemu SYSTEM "linuxemu/chapter.sgml">
|
||||
<!ENTITY chap.internals SYSTEM "internals/chapter.sgml">
|
||||
|
||||
<!-- Part five (appendices) -->
|
||||
<!ENTITY chap.mirrors SYSTEM "mirrors/chapter.sgml">
|
||||
<!ENTITY chap.bibliography SYSTEM "bibliography/chapter.sgml">
|
||||
<!ENTITY chap.eresources SYSTEM "eresources/chapter.sgml">
|
||||
<!ENTITY chap.staff SYSTEM "staff/chapter.sgml">
|
||||
<!ENTITY chap.pgpkeys SYSTEM "pgpkeys/chapter.sgml">
|
||||
4901
en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml
Normal file
4901
en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
2088
en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml
Normal file
2088
en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1173
en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml
Normal file
1173
en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
6323
en_US.ISO_8859-1/books/handbook/hw/chapter.sgml
Normal file
6323
en_US.ISO_8859-1/books/handbook/hw/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1212
en_US.ISO_8859-1/books/handbook/install/chapter.sgml
Normal file
1212
en_US.ISO_8859-1/books/handbook/install/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
1652
en_US.ISO_8859-1/books/handbook/internals/chapter.sgml
Normal file
1652
en_US.ISO_8859-1/books/handbook/internals/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
611
en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml
Normal file
611
en_US.ISO_8859-1/books/handbook/introduction/chapter.sgml
Normal file
|
|
@ -0,0 +1,611 @@
|
|||
<chapter id="introduction">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>FreeBSD is a 4.4BSD-Lite based operating system for Intel
|
||||
architecture (x86) based PCs. For an overview of FreeBSD, see
|
||||
<xref linkend="nutshell" remap="FreeBSD in a nutshell">. For a
|
||||
history of the project, read <xref linkend="history" remap="a brief
|
||||
history of FreeBSD">. To see a description of the latest release,
|
||||
read <xref linkend="relnotes" remap="about the current
|
||||
release">. If you're interested in contributing something to the
|
||||
FreeBSD project (code, equipment, sacks of unmarked bills), please see
|
||||
about <xref linkend="contrib"
|
||||
remap="contributing to FreeBSD">.</para>
|
||||
|
||||
|
||||
<sect1 id="nutshell">
|
||||
<title>FreeBSD in a Nutshell</title>
|
||||
|
||||
<para>FreeBSD is a state of the art operating system for personal
|
||||
computers based on the Intel CPU architecture, which includes the
|
||||
386, 486 and Pentium processors (both SX and DX versions). Intel
|
||||
compatible CPUs from AMD and Cyrix are supported as well. FreeBSD
|
||||
provides you with many advanced features previously available only
|
||||
on much more expensive computers. These features include:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Preemptive multitasking</emphasis> with
|
||||
dynamic priority adjustment to ensure smooth and fair sharing
|
||||
of the computer between applications and users.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Multiuser</emphasis> access means that
|
||||
many people can use a FreeBSD system simultaneously for a
|
||||
variety of things. System peripherals such as printers and
|
||||
tape drives are also properly SHARED BETWEEN ALL users on the
|
||||
system.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Complete <emphasis>TCP/IP networking</emphasis>
|
||||
including SLIP, PPP, NFS and NIS support. This means that
|
||||
your FreeBSD machine can inter-operate easily with other
|
||||
systems as well act as an enterprise server, providing vital
|
||||
functions such as NFS (remote file access) and e-mail services
|
||||
or putting your organization on the Internet with WWW, ftp,
|
||||
routing and firewall (security) services.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Memory protection</emphasis> ensures
|
||||
that applications (or users) cannot interfere with each other.
|
||||
One application crashing will not affect others in any
|
||||
way.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD is a <emphasis>32-bit</emphasis>
|
||||
operating system and was designed as such from the ground
|
||||
up.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The industry standard <emphasis>X Window
|
||||
System</emphasis> (X11R6) provides a graphical user
|
||||
interface (GUI) for the cost of a common VGA card and monitor
|
||||
and comes with full sources.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Binary compatibility</emphasis> with
|
||||
many programs built for SCO, BSDI, NetBSD, Linux and
|
||||
386BSD.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hundreds of <emphasis>ready-to-run</emphasis>
|
||||
applications are available from the FreeBSD <emphasis>ports</emphasis> and <emphasis>packages</emphasis> collection. Why search the net
|
||||
when you can find it all right here?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Thousands of additional and <emphasis>easy-to-port</emphasis> applications available on
|
||||
the Internet. FreeBSD is source code compatible with most
|
||||
popular commercial Unix systems and thus most applications
|
||||
require few, if any, changes to compile.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Demand paged <emphasis>virtual memory</emphasis>
|
||||
and “merged VM/buffer cache” design efficiently satisfies
|
||||
applications with large appetites for memory while still
|
||||
maintaining interactive response to other users.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Shared libraries</emphasis> (the Unix
|
||||
equivalent of MS-Windows DLLs) provide for efficient use of
|
||||
disk space and memory.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A full compliment of <emphasis>C</emphasis>,
|
||||
<emphasis>C++</emphasis> and <emphasis>Fortran</emphasis> development tools. Many
|
||||
additional languages for advanced research and development are
|
||||
also available in the ports and packages collection.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Source code</emphasis> for the entire
|
||||
system means you have the greatest degree of control over your
|
||||
environment. Why be locked into a proprietary solution and at
|
||||
the mercy of your vendor when you can have a truly Open
|
||||
System?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Extensive <emphasis>on-line
|
||||
documentation</emphasis>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>And many more!</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>FreeBSD is based on the 4.4BSD-Lite release from Computer
|
||||
Systems Research Group (CSRG) at the University of California at
|
||||
Berkeley, and carries on the distinguished tradition of BSD systems
|
||||
development. In addition to the fine work provided by CSRG, the
|
||||
FreeBSD Project has put in many thousands of hours in fine tuning
|
||||
the system for maximum performance and reliability in real-life load
|
||||
situations. As many of the commercial giants struggle to field PC
|
||||
operating systems with such features, performance and reliability,
|
||||
FreeBSD can offer them <emphasis>now</emphasis>!</para>
|
||||
|
||||
<para>The applications to which FreeBSD can be put are truly limited
|
||||
only by your own imagination. From software development to factory
|
||||
automation, inventory control to azimuth correction of remote
|
||||
satellite antennae; if it can be done with a commercial UNIX product
|
||||
then it is more than likely that you can do it with FreeBSD, too!
|
||||
FreeBSD also benefits significantly from the literally thousands of
|
||||
high quality applications developed by research centers and
|
||||
universities around the world, often available at little to no cost.
|
||||
Commercial applications are also available and appearing in greater
|
||||
numbers every day.</para>
|
||||
|
||||
<para>Because the source code for FreeBSD itself is generally
|
||||
available, the system can also be customized to an almost unheard of
|
||||
degree for special applications or projects, and in ways not
|
||||
generally possible with operating systems from most major commercial
|
||||
vendors. Here is just a sampling of some of the applications in
|
||||
which people are currently using FreeBSD:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Internet Services:</emphasis> The
|
||||
robust TCP/IP networking built into FreeBSD makes it an ideal
|
||||
platform for a variety of Internet services such as:</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>FTP servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>World Wide Web servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Gopher servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Electronic Mail servers</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>USENET News</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Bulletin Board Systems</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>And more...</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>You can easily start out small with an
|
||||
inexpensive 386 class PC and upgrade as your enterprise
|
||||
grows.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Education:</emphasis> Are you a student
|
||||
of computer science or a related engineering field? There is
|
||||
no better way of learning about operating systems, computer
|
||||
architecture and networking than the hands on, under the hood
|
||||
experience that FreeBSD can provide. A number of freely
|
||||
available CAD, mathematical and graphic design packages also
|
||||
make it highly useful to those whose primary interest in a
|
||||
computer is to get <emphasis>other</emphasis> work
|
||||
done!</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Research:</emphasis> With source code
|
||||
for the entire system available, FreeBSD is an excellent
|
||||
platform for research in operating systems as well as other
|
||||
branches of computer science. FreeBSD's freely available
|
||||
nature also makes it possible for remote groups to collaborate
|
||||
on ideas or shared development without having to worry about
|
||||
special licensing agreements or limitations on what may be
|
||||
discussed in open forums.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Networking:</emphasis> Need a new
|
||||
router? A name server (DNS)? A firewall to keep people out
|
||||
of your internal network? FreeBSD can easily turn that unused
|
||||
386 or 486 PC sitting in the corner into an advanced router
|
||||
with sophisticated packet filtering capabilities.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>X Window workstation:</emphasis>
|
||||
FreeBSD is a fine choice for an inexpensive X terminal
|
||||
solution, either using the freely available XFree86 server or
|
||||
one of the excellent commercial servers provided by X Inside.
|
||||
Unlike an X terminal, FreeBSD allows many applications to be
|
||||
run locally, if desired, thus relieving the burden on a
|
||||
central server. FreeBSD can even boot “diskless”, making
|
||||
individual workstations even cheaper and easier to
|
||||
administer.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Software Development:</emphasis> The
|
||||
basic FreeBSD system comes with a full compliment of
|
||||
development tools including the renowned GNU C/C++ compiler
|
||||
and debugger.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>FreeBSD is available in both source and binary form on CDROM and
|
||||
via anonymous ftp. See <xref linkend="mirrors" remap="Obtaining
|
||||
FreeBSD"> for more details.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="history">
|
||||
<title>A Brief History of FreeBSD</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jkh;</emphasis>.</para>
|
||||
|
||||
<para>The FreeBSD project had its genesis in the early part of 1993,
|
||||
partially as an outgrowth of the “Unofficial 386BSD Patchkit” by the
|
||||
patchkit's last 3 coordinators: Nate Williams, Rod Grimes and
|
||||
myself.</para>
|
||||
|
||||
<para>Our original goal was to produce an intermediate snapshot of
|
||||
386BSD in order to fix a number of problems with it that the
|
||||
patchkit mechanism just was not capable of solving. Some of you may
|
||||
remember the early working title for the project being “386BSD 0.5”
|
||||
or “386BSD Interim” in reference to that fact.</para>
|
||||
|
||||
<para>386BSD was Bill Jolitz's operating system, which had been up to
|
||||
that point suffering rather severely from almost a year's worth of
|
||||
neglect. As the patchkit swelled ever more uncomfortably with each
|
||||
passing day, we were in unanimous agreement that something had to be
|
||||
done and decided to try and assist Bill by providing this interim
|
||||
“cleanup” snapshot. Those plans came to a rude halt when Bill
|
||||
Jolitz suddenly decided to withdraw his sanction from the project
|
||||
and without any clear indication of what would be done
|
||||
instead.</para>
|
||||
|
||||
<para>It did not take us long to decide that the goal remained
|
||||
worthwhile, even without Bill's support, and so we adopted the name
|
||||
“FreeBSD”, coined by David Greenman. Our initial objectives were
|
||||
set after consulting with the system's current users and, once it
|
||||
became clear that the project was on the road to perhaps even
|
||||
becoming a reality, I contacted Walnut Creek CDROM with an eye
|
||||
towards improving FreeBSD's distribution channels for those many
|
||||
unfortunates without easy access to the Internet. Walnut Creek
|
||||
CDROM not only supported the idea of distributing FreeBSD on CD but
|
||||
went so far as to provide the project with a machine to work on and
|
||||
a fast Internet connection. Without Walnut Creek CDROM's almost
|
||||
unprecedented degree of faith in what was, at the time, a completely
|
||||
unknown project, it is quite unlikely that FreeBSD would have gotten
|
||||
as far, as fast, as it has today.</para>
|
||||
|
||||
<para>The first CDROM (and general net-wide) distribution was FreeBSD
|
||||
1.0, released in December of 1993. This was based on the
|
||||
4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components
|
||||
also provided by 386BSD and the Free Software Foundation. It was a
|
||||
fairly reasonable success for a first offering, and we followed it
|
||||
with the highly successful FreeBSD 1.1 release in May of
|
||||
1994.</para>
|
||||
|
||||
<para>Around this time, some rather unexpected storm clouds formed on
|
||||
the horizon as Novell and U.C. Berkeley settled their long-running
|
||||
lawsuit over the legal status of the Berkeley Net/2 tape. A
|
||||
condition of that settlement was U.C. Berkeley's concession that
|
||||
large parts of Net/2 were “encumbered” code and the property of
|
||||
Novell, who had in turn acquired it from AT&T some time
|
||||
previously. What Berkeley got in return was Novell's “blessing”
|
||||
that the 4.4BSD-Lite release, when it was finally released, would be
|
||||
declared unencumbered and all existing Net/2 users would be strongly
|
||||
encouraged to switch. This included FreeBSD, and the project was
|
||||
given until the end of July 1994 to stop shipping its own Net/2
|
||||
based product. Under the terms of that agreement, the project was
|
||||
allowed one last release before the deadline, that release being
|
||||
FreeBSD 1.1.5.1.</para>
|
||||
|
||||
<para>FreeBSD then set about the arduous task of literally
|
||||
re-inventing itself from a completely new and rather incomplete set
|
||||
of 4.4BSD-Lite bits. The “Lite” releases were light in part because
|
||||
Berkeley's CSRG had removed large chunks of code required for
|
||||
actually constructing a bootable running system (due to various
|
||||
legal requirements) and the fact that the Intel port of 4.4 was
|
||||
highly incomplete. It took the project until December of 1994 to
|
||||
make this transition, and in January of 1995 it released FreeBSD 2.0
|
||||
to the net and on CDROM. Despite being still more than a little
|
||||
rough around the edges, the release was a significant success and
|
||||
was followed by the more robust and easier to install FreeBSD 2.0.5
|
||||
release in June of 1995.</para>
|
||||
|
||||
<para>We released FreeBSD 2.1.5 in August of 1996, and it appeared to
|
||||
be popular enough among the ISP and commercial communities that
|
||||
another release along the 2.1-stable branch was merited. This was
|
||||
FreeBSD 2.1.7.1, released in February 1997 and capping the end of
|
||||
mainstream development on 2.1-stable. Now in maintenance mode, only
|
||||
security enhancements and other critical bug fixes will be done on
|
||||
this branch (RELENG_2_1_0).</para>
|
||||
|
||||
<para>FreeBSD 2.2 was branched from the development mainline
|
||||
(“-current”) in November 1996 as the RELENG_2_2 branch, and the
|
||||
first full release (2.2.1) was released in April, 1997. Further
|
||||
releases along the 2.2 branch were done in the Summer and Fall of
|
||||
'97, the latest being 2.2.6 which appeared in late March of '98.
|
||||
The first official 3.0 release will appear later in 1998.</para>
|
||||
|
||||
<para>Long term development projects for everything from SMP to DEC
|
||||
ALPHA support will continue to take place in the 3.0-current branch
|
||||
and SNAPshot releases of 3.0 on CDROM (and, of course, on the net).</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="goals">
|
||||
<title>FreeBSD Project Goals</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jkh;</emphasis>.</para>
|
||||
|
||||
<para>The goals of the FreeBSD Project are to provide software that
|
||||
may be used for any purpose and without strings attached. Many of
|
||||
us have a significant investment in the code (and project) and would
|
||||
certainly not mind a little financial compensation now and then, but
|
||||
we're definitely not prepared to insist on it. We believe that our
|
||||
first and foremost “mission” is to provide code to any and all
|
||||
comers, and for whatever purpose, so that the code gets the widest
|
||||
possible use and provides the widest possible benefit. This is, I
|
||||
believe, one of the most fundamental goals of Free Software and one
|
||||
that we enthusiastically support.</para>
|
||||
|
||||
<para>That code in our source tree which falls under the GNU Public
|
||||
License (GPL) or GNU Library Public License (GLPL) comes with
|
||||
slightly more strings attached, though at least on the side of
|
||||
enforced access rather than the usual opposite. Due to the
|
||||
additional complexities that can evolve in the commercial use of GPL
|
||||
software, we do, however, endeavor to replace such software with
|
||||
submissions under the more relaxed BSD copyright whenever possible.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="development">
|
||||
<title>The FreeBSD Development Model</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.asami;</emphasis>.</para>
|
||||
|
||||
<para>The development of FreeBSD is a very open and flexible process,
|
||||
FreeBSD being literally built from the contributions of hundreds of
|
||||
people around the world, as can be seen from our <xref
|
||||
linkend="staff" remap="list of contributors">. We are constantly
|
||||
on the lookout for new developers and ideas, and those interested in
|
||||
becoming more closely involved with the project need simply contact
|
||||
us at the &a.hackers;. Those who prefer to work more independently
|
||||
are also accommodated, and they are free to use our FTP facilities
|
||||
at <ulink
|
||||
URL="ftp://ftp.freebsd.org/pub/FreeBSD/incoming">ftp.freebsd.org</ulink> to distribute their own patches or work-in-progress sources. The &a.announce; is also available to those wishing to make other FreeBSD users aware of major areas of work.</para>
|
||||
|
||||
<para>Useful things to know about the FreeBSD project and its
|
||||
development process, whether working independently or in close
|
||||
cooperation:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>The CVS
|
||||
repository<anchor id="development-cvs-repository"></term>
|
||||
<listitem>
|
||||
<para>The central source tree for FreeBSD is maintained by
|
||||
<ulink
|
||||
URL="http://www.cyclic.com/cyclic-pages/CVS-sheet.html">CVS</ulink> (Concurrent Version System), a freely available source code control tool which comes bundled with FreeBSD. The primary <ulink URL="http://www.freebsd.org/cgi/cvsweb.cgi">CVS repository</ulink> resides on a machine in Concord CA, USA from where it is replicated to numerous mirror machines throughout the world. The CVS tree, as well as the <xref linkend="current" remap="-current"> and <xref
|
||||
linkend="stable" remap="-stable"> trees which are checked
|
||||
out of it, can be easily replicated to your own machine as
|
||||
well. Please refer to the
|
||||
<xref linkend="synching" remap="Synchronizing your source
|
||||
tree"> section for more information on doing this.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The committers
|
||||
list<anchor id="development-committers"></term>
|
||||
|
||||
<listitem>
|
||||
<para>The <xref linkend="staff-committers" remap="committers">
|
||||
are the people who have <emphasis>write</emphasis> access to
|
||||
the CVS tree, and are thus authorized to make modifications
|
||||
to the FreeBSD source (the term “committer” comes from the
|
||||
<citerefentry><refentrytitle>cvs</refentrytitle><manvolnum>1</manvolnum></citerefentry> <command>commit</command> command, which is used to
|
||||
bring new changes into the CVS repository). The best way of
|
||||
making submissions for review by the committers list is to
|
||||
use the <citerefentry><refentrytitle>send-pr</refentrytitle><manvolnum>1</manvolnum></citerefentry> command, though if something appears to be jammed in the system then you may also reach them by sending mail to <email>committers@freebsd.org</email>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The FreeBSD core
|
||||
team<anchor id="development-core"></term>
|
||||
|
||||
<listitem>
|
||||
<para>The <xref linkend="staff-core" remap="FreeBSD core
|
||||
team"> would be equivalent to the board of directors if
|
||||
the FreeBSD Project were a company. The primary task of the
|
||||
core team is to make sure the project, as a whole, is in
|
||||
good shape and is heading in the right directions. Inviting
|
||||
dedicated and responsible developers to join our group of
|
||||
committers is one of the functions of the core team, as is
|
||||
the recruitment of new core team members as others move on.
|
||||
Most current members of the core team started as committers
|
||||
who's addiction to the project got the better of
|
||||
them.</para>
|
||||
|
||||
<para>Some core team members also have specific <xref
|
||||
linkend="staff-who" remap="areas of responsibility">,
|
||||
meaning that they are committed to ensuring that some large
|
||||
portion of the system works as advertised.</para>
|
||||
|
||||
<note>
|
||||
<para>Most members of the core team are volunteers when it
|
||||
comes to FreeBSD development and do not benefit from the
|
||||
project financially, so “commitment” should also not be
|
||||
misconstrued as meaning “guaranteed support.” The
|
||||
“board of directors” analogy above is not
|
||||
actually very accurate, and it may be more suitable to say
|
||||
that these are the people who gave up their lives in favor
|
||||
of FreeBSD against their better judgement! <!-- smiley --><emphasis>;)</emphasis></para>
|
||||
</note>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Outside
|
||||
contributors</term>
|
||||
|
||||
<listitem>
|
||||
<para>Last, but definitely not least, the largest group of
|
||||
developers are the users themselves who provide feedback and
|
||||
bug-fixes to us on an almost constant basis. The primary
|
||||
way of keeping in touch with FreeBSD's more non-centralized
|
||||
development is to subscribe to the &a.hackers; (see <xref
|
||||
linkend="eresources-mail" remap="mailing list
|
||||
info">) where such things are discussed.</para>
|
||||
|
||||
<para><xref linkend="contrib-additional" remap="The list"> of
|
||||
those who have contributed something which made its way into
|
||||
our source tree is a long and growing one, so why not join
|
||||
it by contributing something back to FreeBSD today?
|
||||
<!-- smiley --><emphasis>:-)</emphasis></para>
|
||||
|
||||
<para>Providing code is not the only way of contributing to
|
||||
the project; for a more complete list of things that need
|
||||
doing, please refer to the <xref linkend="contrib"
|
||||
remap="how to
|
||||
contribute"> section in this handbook.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
<para>In summary, our development model is organized as a loose set of
|
||||
concentric circles. The centralized model is designed for the
|
||||
convenience of the <emphasis>users</emphasis> of FreeBSD, who are
|
||||
thereby provided with an easy way of tracking one central code base,
|
||||
not to keep potential contributors out! Our desire is to present a
|
||||
stable operating system with a large set of coherent <xref
|
||||
linkend="ports"
|
||||
remap="application programs"> that the users can easily install
|
||||
and use, and this model works very well in accomplishing
|
||||
that.</para>
|
||||
|
||||
<para>All we ask of those who would join us as FreeBSD developers is
|
||||
some of the same dedication its current people have to its continued
|
||||
success!</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="relnotes">
|
||||
<title>About the Current Release</title>
|
||||
|
||||
<para>FreeBSD is a freely available, full source 4.4BSD-Lite based
|
||||
release for Intel i386/i486/Pentium/PentiumPro/Pentium II (or
|
||||
compatible) based PC's. It is based primarily on software from U.C.
|
||||
Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD,
|
||||
386BSD, and the Free Software Foundation.</para>
|
||||
|
||||
<para>Since our release of FreeBSD 2.0 in January of 95, the
|
||||
performance, feature set, and stability of FreeBSD has improved
|
||||
dramatically. The largest change is a revamped virtual memory
|
||||
system with a merged VM/file buffer cache that not only increases
|
||||
performance, but reduces FreeBSD's memory footprint, making a 5MB
|
||||
configuration a more acceptable minimum. Other enhancements include
|
||||
full NIS client and server support, transaction TCP support,
|
||||
dial-on-demand PPP, an improved SCSI subsystem, early ISDN support,
|
||||
support for FDDI and Fast Ethernet (100Mbit) adapters, improved
|
||||
support for the Adaptec 2940 (WIDE and narrow) and many hundreds of
|
||||
bug fixes.</para>
|
||||
|
||||
<para>We have also taken the comments and suggestions of many of our
|
||||
users to heart and have attempted to provide what we hope is a more
|
||||
sane and easily understood installation process. Your feedback on
|
||||
this (constantly evolving) process is especially welcome!</para>
|
||||
|
||||
<para>In addition to the base distributions, FreeBSD offers a new
|
||||
ported software collection with hundreds of commonly sought-after
|
||||
programs. At the end of March 1998 there were more than 1300 ports!
|
||||
The list of ports ranges from http (WWW) servers, to games,
|
||||
languages, editors and almost everything in between. The entire
|
||||
ports collection requires approximately 26MB of storage, all ports
|
||||
being expressed as “deltas” to their original sources. This
|
||||
makes it much easier for us to update ports, and greatly reduces
|
||||
the disk space demands made by the older 1.0 ports collection. To
|
||||
compile a port, you simply change to the directory of the program
|
||||
you wish to install, type <command>make all</command> followed by <command>make install</command>
|
||||
after successful compilation and let the system do the rest. The
|
||||
full original distribution for each port you build is retrieved
|
||||
dynamically off the CDROM or a local ftp site, so you need only
|
||||
enough disk space to build the ports you want. (Almost) every port
|
||||
is also provided as a pre-compiled “package” which can be installed
|
||||
with a simple command (pkg_add) by those who do not wish to compile
|
||||
their own ports from source.</para>
|
||||
|
||||
<para>A number of additional documents which you may find very helpful
|
||||
in the process of installing and using FreeBSD may now also be found
|
||||
in the <filename>/usr/share/doc</filename> directory on any machine
|
||||
running FreeBSD 2.1 or later. You may view the locally installed
|
||||
manuals with any HTML capable browser using the following
|
||||
URLs:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>The FreeBSD handbook</term>
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="file:/usr/share/doc/handbook/handbook.html">file:/usr/share/doc/handbook/handbook.html</ulink></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>The FreeBSD FAQ</term>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
URL="file:/usr/share/doc/FAQ/FAQ.html">file:/usr/share/doc/FAQ/FAQ.html</ulink></para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
<para>You can also visit the master (and most frequently updated)
|
||||
copies at <ulink
|
||||
URL="http://www.freebsd.org">http://www.freebsd.org</ulink>.</para>
|
||||
|
||||
<para>The core of FreeBSD does not contain DES code which would
|
||||
inhibit its being exported outside the United States. There is an
|
||||
add-on package to the core distribution, for use only in the United
|
||||
States, that contains the programs that normally use DES. The
|
||||
auxiliary packages provided separately can be used by anyone. A
|
||||
freely (from outside the U.S.) exportable European distribution of
|
||||
DES for our non-U.S. users also exists and is described in the
|
||||
<ulink URL="../FAQ/FAQ.html">FreeBSD FAQ</ulink>.</para>
|
||||
|
||||
<para>If password security for FreeBSD is all you need, and you have
|
||||
no requirement for copying encrypted passwords from different hosts
|
||||
(Suns, DEC machines, etc) into FreeBSD password entries, then
|
||||
FreeBSD's MD5 based security may be all you require! We feel that
|
||||
our default security model is more than a match for DES, and without
|
||||
any messy export issues to deal with. If you are outside (or even
|
||||
inside) the U.S., give it a try!</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
1711
en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml
Normal file
1711
en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
634
en_US.ISO_8859-1/books/handbook/kerneldebug/chapter.sgml
Normal file
634
en_US.ISO_8859-1/books/handbook/kerneldebug/chapter.sgml
Normal file
|
|
@ -0,0 +1,634 @@
|
|||
<chapter id="kerneldebug">
|
||||
<title>Kernel Debugging</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.paul; and &a.joerg;</emphasis></para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Debugging a Kernel Crash Dump with <command>kgdb</command></title>
|
||||
|
||||
<para>Here 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 <literal>config
|
||||
kernel</literal> line), or you can specify an alternate using the
|
||||
<citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command. Dumps to non-swap devices, tapes for example,
|
||||
are currently not supported. Config your kernel using
|
||||
<command>config -g</command>. See <xref linkend="kernelconfig"
|
||||
remap="Kernel Configuration"> for
|
||||
details on configuring the FreeBSD kernel.</para>
|
||||
|
||||
<para>Use the <citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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
|
||||
<citerefentry><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>). This is normally arranged via
|
||||
<filename>/etc/rc.conf</filename> and <filename>/etc/rc</filename>.
|
||||
Alternatively, you can hard-code the dump device via the <literal>dump</literal>
|
||||
clause in the <literal>config</literal> 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.</para>
|
||||
|
||||
<note>
|
||||
<para>In the following, the term <command>kgdb</command> refers to
|
||||
<command>gdb</command> run in “kernel debug mode”. This can be
|
||||
accomplished by either starting the <command>gdb</command> with
|
||||
the option <option>-k</option>, or by linking and starting it
|
||||
under the name <command>kgdb</command>. 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.</para>
|
||||
</note>
|
||||
|
||||
<para>When the kernel has been built make a copy of it, say
|
||||
<filename>kernel.debug</filename>, and then run <command>strip
|
||||
-d</command> 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.</para>
|
||||
|
||||
<para>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 <option>-s</option> flag at the boot
|
||||
prompt, and then perform the following steps:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>fsck -p</userinput>
|
||||
&prompt.root; <userinput>mount -a -t ufs</userinput> # so your file system for /var/crash is writable
|
||||
&prompt.root; <userinput>savecore -N /kernel.panicked /var/crash</userinput>
|
||||
&prompt.root; <userinput>exit</userinput> # ...to multi-user</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This instructs <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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.</para>
|
||||
|
||||
<para>Now, after a crash dump, go to
|
||||
<filename>/sys/compile/WHATEVER</filename> and run <command>kgdb</command>. From <command>kgdb</command>
|
||||
do:
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>symbol-file kernel.debug</userinput>
|
||||
<userinput>exec-file /var/crash/kernel.0</userinput>
|
||||
<userinput>core-file /var/crash/vmcore.0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
and voila, you can debug the crash dump using the
|
||||
kernel sources just like you can for any other program.</para>
|
||||
|
||||
<para>Here is a script log of a <command>kgdb</command>
|
||||
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.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen> 1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:&prompt.root; <userinput>cd /sys/compile/URIAH</userinput>
|
||||
3:&prompt.root; <userinput>kgdb kernel /var/crash/vmcore.1</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>where</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up 10</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>frame frame->tf_ebp frame->tf_eip</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>list</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>print tp</userinput>
|
||||
53:Reading in symbols for ../../i386/i386/cons.c...done.
|
||||
54:$1 = (struct tty *) 0x1bae
|
||||
55:<prompt>(kgdb)</prompt> <userinput>print tp->t_line</userinput>
|
||||
56:$2 = 1767990816
|
||||
57:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
62:#2 0xf0132c34 in spec_open ()
|
||||
63:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
64:#3 0xf012d014 in vn_open ()
|
||||
65:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
66:#4 0xf012a183 in open ()
|
||||
67:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
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:<prompt>(kgdb)</prompt> <userinput>up</userinput>
|
||||
75:Initial frame selected; you cannot go up.
|
||||
76:<prompt>(kgdb)</prompt> <userinput>quit</userinput>
|
||||
77:&prompt.root; <userinput>exit</userinput>
|
||||
78:exit
|
||||
79:
|
||||
80:Script done on Fri Dec 30 23:18:04 1994</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Comments to the above script:</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>line 6:</term>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 20:</term>
|
||||
|
||||
<listitem>
|
||||
<para>This is the location of function
|
||||
<function>trap()</function> in the stack trace.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 36:</term>
|
||||
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 52:</term>
|
||||
|
||||
<listitem>
|
||||
<para>The pointer looks suspicious, but happens to be a valid
|
||||
address.</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>line 56:</term>
|
||||
|
||||
<listitem>
|
||||
<para>However, it obviously points to garbage, so we have
|
||||
found our error! (For those unfamiliar with that particular
|
||||
piece of code: <literal>tp->t_line</literal>
|
||||
refers to the line discipline of the console device here,
|
||||
which must be a rather small integer number.)</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Post-mortem Analysis of a Dump</title>
|
||||
|
||||
<para>What do you do if a kernel dumped core but you did not expect
|
||||
it, and it is therefore not compiled using <command>config
|
||||
-g</command>? Not everything is lost here. Do not panic!</para>
|
||||
|
||||
<para>Of course, you still need to enable crash dumps. See above on
|
||||
the options you have to specify in order to do this.</para>
|
||||
|
||||
<para>Go to your kernel compile directory, and edit the line
|
||||
containing <literal>COPTFLAGS?=-O</literal>. Add the
|
||||
<option>-g</option> option there (but <emphasis>do not</emphasis>
|
||||
change anything on the level of optimization). If you do already
|
||||
know roughly the probable location of the failing piece of code
|
||||
(e.g., the <devicename>pcvt</devicename> driver in the example
|
||||
above), remove all the object files for this code. Rebuild the
|
||||
kernel. Due to the time stamp change on the Makefile, there will be
|
||||
some other object files rebuild, for example
|
||||
<filename>trap.o</filename>. With a bit of luck, the added
|
||||
<option>-g</option> 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
|
||||
<citerefentry><refentrytitle>size</refentrytitle><manvolnum>1</manvolnum></citerefentry> command. If there is a mismatch, you
|
||||
probably need to give up here.</para>
|
||||
|
||||
<para>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
|
||||
<command>kgdb</command> session until you know
|
||||
enough.</para>
|
||||
|
||||
<para>All this is not guaranteed to work, but it will do it fine in
|
||||
most cases.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>On-line Kernel Debugging Using DDB</title>
|
||||
|
||||
<para>While <command>kgdb</command> 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.</para>
|
||||
|
||||
<para>If you need to do low-level debugging on your kernel, there is
|
||||
an on-line debugger available called DDB. It allows to setting
|
||||
breakpoints, single-steping kernel functions, examining and changing
|
||||
kernel variables, etc. However, it cannot access kernel source
|
||||
files, and only has access to the global and static symbols, not to
|
||||
the full debug information like <command>kgdb</command>.</para>
|
||||
|
||||
<para>To configure your kernel to include DDB, add the option line
|
||||
|
||||
<programlisting>
|
||||
options DDB</programlisting> to your config file, and rebuild. (See <xref
|
||||
linkend="kernelconfig"
|
||||
remap="Kernel Configuration"> for details on configuring the
|
||||
FreeBSD kernel.</para>
|
||||
|
||||
<note>
|
||||
<para>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.)</para>
|
||||
</note>
|
||||
|
||||
<para>Once your DDB kernel is running, there are several ways to enter
|
||||
DDB. The first, and earliest way is to type the boot flag
|
||||
<option>-d</option> 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.</para>
|
||||
|
||||
<para>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 (<literal>options
|
||||
BREAK_TO_DEBUGGER</literal> 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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The DDB commands roughly resemble some <command>gdb</command> commands. The first thing you probably
|
||||
need to do is to set a breakpoint:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>b function-name</userinput>
|
||||
<userinput>b address</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Numbers are taken hexadecimal by default, but to make them
|
||||
distinct from symbol names; hexadecimal numbers starting with the
|
||||
letters <literal>a-f</literal> need to be preceded with
|
||||
<literal>0x</literal> (this is optional for other numbers). Simple
|
||||
expressions are allowed, for example: <literal>function-name +
|
||||
0x103</literal>.</para>
|
||||
|
||||
<para>To continue the operation of an interrupted kernel, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>c</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To get a stack trace, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>trace</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>Note 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.</para>
|
||||
</note>
|
||||
|
||||
<para>If you want to remove a breakpoint, use</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>del</userinput>
|
||||
<userinput>del address-expression</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The first form will be accepted immediately after
|
||||
a breakpoint hit, and deletes the current breakpoint. The second
|
||||
form can remove any breakpoint, but you need to specify the exact
|
||||
address; this can be obtained from:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>show b</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To single-step the kernel, try:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>s</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will step into functions, but you can make
|
||||
DDB trace them until the matching return statement is reached by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>n</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>This is different from <command>gdb</command>'s <command>next</command>
|
||||
statement; it is like <command>gdb</command>'s <command>finish</command>.</para>
|
||||
</note>
|
||||
|
||||
<para>To examine data from memory, use (for example):
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x/wx 0xf0133fe0,40</userinput>
|
||||
<userinput>x/hd db_symtab_space</userinput>
|
||||
<userinput>x/bc termbuf,10</userinput>
|
||||
<userinput>x/s stringbuf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x ,10</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Similarly, use
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>x/ia foofunc,10</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
to disassemble the first 0x10 instructions of
|
||||
<function>foofunc</function>, and display them along with
|
||||
their offset from the beginning of <function>foofunc</function>.</para>
|
||||
|
||||
<para>To modify memory, use the write command:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>w/b termbuf 0xa 0xb 0</userinput>
|
||||
<userinput>w/w 0xf0010030 0 0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The command modifier
|
||||
(<literal>b</literal>/<literal>h</literal>/<literal>w</literal>) 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.</para>
|
||||
|
||||
<para>If you need to know the current registers, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>show reg</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Alternatively, you can display a single register
|
||||
value by e.g.
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>p $eax</userinput></screen>
|
||||
</informalexample> and modify it by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>set $eax new-value</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Should you need to call some kernel functions from DDB, simply
|
||||
say:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call func(arg1, arg2, ...)</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The return value will be printed.</para>
|
||||
|
||||
<para>For a <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> style summary of all running
|
||||
processes, use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>ps</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now 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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call diediedie()</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>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 <command>continue</command> statement. There is now an alias for
|
||||
this: <command>panic</command>.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call boot(0)</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Which might be a good way to cleanly shut down the
|
||||
running system, <function>sync()</function> 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.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>call cpu_reset()</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>is the final way out of disaster and almost the
|
||||
same as hitting the Big Red Button.</para>
|
||||
|
||||
<para>If you need a short command summary, simply type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><userinput>help</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>However, it is highly recommended to have a
|
||||
printed copy of the <citerefentry><refentrytitle>ddb</refentrytitle><manvolnum>4</manvolnum></citerefentry> manual page
|
||||
ready for a debugging session. Remember that it is hard to read the
|
||||
on-line manual while single-stepping the kernel.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>On-line Kernel Debugging Using Remote GDB</title>
|
||||
|
||||
<para>This feature has been supported since FreeBSD 2.2, and it's
|
||||
actually a very neat one.</para>
|
||||
|
||||
<para>GDB has already supported <emphasis>remote debugging</emphasis>
|
||||
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).</para>
|
||||
|
||||
<para>You should configure the kernel in question with <command>config
|
||||
-g</command>, include <option>DDB</option> 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 <command>strip
|
||||
-x</command>, and boot it using the <option>-d</option> 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:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>gdb -k kernel</userinput>
|
||||
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...
|
||||
<prompt>(kgdb)</prompt> </screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Initialize the remote debugging session (assuming the first
|
||||
serial port is being used) by:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>(kgdb)</prompt> <userinput>target remote /dev/cuaa0</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now, on the target host (the one that entered DDB right before
|
||||
even starting the device probe), type:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
<prompt>db></prompt> <userinput>gdb</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>DDB will respond with:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Next trap will enter GDB remote protocol mode</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Every time you type <command>gdb</command>, the mode will be toggled between
|
||||
remote GDB and local DDB. In order to force a next trap
|
||||
immediately, simply type <command>s</command> (step). Your hosting GDB will now
|
||||
gain control over the target kernel:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
at ../../i386/i386/db_interface.c:257
|
||||
<prompt>(kgdb)</prompt></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>Remote GDB can also be used to debug LKMs. First build the LKM
|
||||
with debugging symbols:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
|
||||
&prompt.root; <userinput>make clean; make COPTS=-g</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Then install this version of the module on the target machine,
|
||||
load it and use <command>modstat</command> to find out
|
||||
where it was loaded:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>linux</userinput>
|
||||
&prompt.root; <userinput>modstat</userinput>
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f5109000 001c f510f010 1 linux_mod</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Take 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 <command>add-symbol-file</command> command in GDB to tell the
|
||||
debugger about the module:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>(kgdb)</prompt> <userinput>add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020</userinput>
|
||||
add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
|
||||
text_addr = 0xf5109020? (y or n) <userinput>y</userinput>
|
||||
<prompt>(kgdb)</prompt></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You now have access to all the symbols in the LKM.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Debugging a Console Driver</title>
|
||||
|
||||
<para>Since 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 <option>-h</option> at the <prompt>Boot:</prompt> 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.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
161
en_US.ISO_8859-1/books/handbook/kernelopts/chapter.sgml
Normal file
161
en_US.ISO_8859-1/books/handbook/kernelopts/chapter.sgml
Normal file
|
|
@ -0,0 +1,161 @@
|
|||
<chapter id="kernelopts">
|
||||
<title>Adding New Kernel Configuration Options</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.joerg;</emphasis></para>
|
||||
|
||||
<note>
|
||||
<para>You should be familiar with the section about <xref
|
||||
linkend="kernelconfig" remap="kernel configuration">
|
||||
before reading here.</para>
|
||||
</note>
|
||||
|
||||
<sect1>
|
||||
<title>What's a <emphasis>Kernel Option</emphasis>, Anyway?</title>
|
||||
|
||||
<para>The use of kernel options is basically described in the <xref
|
||||
linkend="kernelconfig-options" remap="kernel configuration">
|
||||
section. There's also an explanation of “historic” and
|
||||
“new-style” options. The ultimate goal is to eventually turn all
|
||||
the supported options in the kernel into new-style ones, so for
|
||||
people who correctly did a <command>make depend</command>
|
||||
in their kernel compile directory after running
|
||||
<citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry>, the build process will automatically
|
||||
pick up modified options, and only recompile those files where it is
|
||||
necessary. Wiping out the old compile directory on each run of
|
||||
<citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> as it is still done now can then be
|
||||
eliminated again.</para>
|
||||
|
||||
<para>Basically, a kernel option is nothing else than the definition
|
||||
of a C preprocessor macro for the kernel compilation process. To
|
||||
make the build truly optional, the corresponding part of the kernel
|
||||
source (or kernel <filename>.h</filename> file) must be written with
|
||||
the option concept in mind, i.e. the default must have been made
|
||||
overridable by the config option. This is usually done with
|
||||
something like:</para>
|
||||
|
||||
<programlisting>
|
||||
#ifndef THIS_OPTION
|
||||
#define THIS_OPTION (some_default_value)
|
||||
#endif /* THIS_OPTION */</programlisting>
|
||||
|
||||
<para>This way, an administrator mentioning another value for the
|
||||
option in his config file will take the default out of effect, and
|
||||
replace it with his new value. Clearly, the new value will be
|
||||
substituted into the source code during the preprocessor run, so it
|
||||
must be a valid C expression in whatever context the default value
|
||||
would have been used.</para>
|
||||
|
||||
<para>It is also possible to create value-less options that simply
|
||||
enable or disable a particular piece of code by embracing it
|
||||
in</para>
|
||||
|
||||
<programlisting>
|
||||
#ifdef THAT_OPTION
|
||||
|
||||
[your code here]
|
||||
|
||||
#endif</programlisting>
|
||||
|
||||
<para>Simply mentioning <literal>THAT_OPTION</literal> in the config
|
||||
file (with or without any value) will then turn on the corresponding
|
||||
piece of code.</para>
|
||||
|
||||
<para>People familiar with the C language will immediately recognize
|
||||
that everything could be counted as a “config option” where there
|
||||
is at least a single <literal>#ifdef</literal>
|
||||
referencing it... However, it's unlikely that many people would
|
||||
put</para>
|
||||
|
||||
<programlisting>
|
||||
options notyet,notdef</programlisting>
|
||||
|
||||
<para>in their config file, and then wonder why the kernel compilation
|
||||
falls over. <!-- smiley -->:-)</para>
|
||||
|
||||
<para>Clearly, using arbitrary names for the options makes it very
|
||||
hard to track their usage throughout the kernel source tree. That
|
||||
is the rationale behind the <emphasis>new-style</emphasis> option
|
||||
scheme, where each option goes into a separate
|
||||
<filename>.h</filename> file in the kernel compile directory, which
|
||||
is by convention named
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename>. This way,
|
||||
the usual Makefile dependencies could be applied, and <command>make</command> can determine what needs to be recompiled
|
||||
once an option has been changed.</para>
|
||||
|
||||
<para>The old-style option mechanism still has one advantage for local
|
||||
options or maybe experimental options that have a short anticipated
|
||||
lifetime: since it is easy to add a new <literal>#ifdef</literal> to the kernel source, this has already
|
||||
made it a kernel config option. In this case, the administrator
|
||||
using such an option is responsible himself for knowing about its
|
||||
implications (and maybe manually forcing the recompilation of parts
|
||||
of his kernel). Once the transition of all supported options has
|
||||
been done, <citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> will warn whenever an
|
||||
unsupported option appears in the config file, but it will
|
||||
nevertheless include it into the kernel Makefile.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Now What Do I Have to Do for it?</title>
|
||||
|
||||
<para>First, edit <filename>sys/conf/options</filename> (or
|
||||
<filename>sys/i386/conf/options.<replaceable><arch></replaceable></filename>, e. g. <filename>sys/i386/conf/options.i386</filename>), and select an <filename>opt_<replaceable>foo</replaceable>.h</filename> file where your new option would best go into.</para>
|
||||
|
||||
<para>If there is already something that comes close to the purpose of
|
||||
the new option, pick this. For example, options modifying the
|
||||
overall behaviour of the SCSI subsystem can go into
|
||||
<filename>opt_scsi.h</filename>. By default, simply mentioning an
|
||||
option in the appropriate option file, say <literal>FOO</literal>,
|
||||
implies its value will go into the corresponding file
|
||||
<filename>opt_foo.h</filename>. This can be overridden on the
|
||||
right-hand side of a rule by specifying another filename.</para>
|
||||
|
||||
<para>If there is no
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> already
|
||||
available for the intended new option, invent a new name. Make it
|
||||
meaningful, and comment the new section in the
|
||||
<filename>options[<replaceable>.<arch></replaceable>]</filename> file. <citerefentry><refentrytitle>config</refentrytitle><manvolnum>8</manvolnum></citerefentry> will automagically pick up the change, and create that file next time it is run. Most options should go in a header file by themselves..</para>
|
||||
|
||||
<para>Packing too many options into a single
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> will cause
|
||||
too many kernel files to be rebuilt when one of the options has been
|
||||
changed in the config file.</para>
|
||||
|
||||
<para>Finally, find out which kernel files depend on the new option.
|
||||
Unless you have just invented your option, and it does not exist
|
||||
anywhere yet,
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>find /usr/src/sys -name type f | xargs fgrep NEW_OPTION</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
is your friend in finding them. Go and edit all those files,
|
||||
and add
|
||||
|
||||
<programlisting>
|
||||
#include "opt_foo.h"</programlisting>
|
||||
|
||||
<emphasis>on top</emphasis>, before all the <literal>#include <xxx.h></literal> stuff. This sequence
|
||||
is most important as the options could override defaults from the
|
||||
regular include files, if the defaults are of the form
|
||||
|
||||
<programlisting>
|
||||
#ifndef NEW_OPTION
|
||||
#define NEW_OPTION (something)
|
||||
#endif</programlisting>
|
||||
|
||||
in the regular header.</para>
|
||||
|
||||
<para>Adding an option that overrides something in a system header
|
||||
file (i.e., a file sitting in
|
||||
<filename>/usr/include/sys/</filename>) is almost always a mistake.
|
||||
<filename>opt_<replaceable>foo</replaceable>.h</filename> cannot be
|
||||
included into those files since it would break the headers more
|
||||
seriously, but if it is not included, then places that include it
|
||||
may get an inconsistent value for the option. Yes, there are
|
||||
precedents for this right now, but that does not make them more
|
||||
correct.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
352
en_US.ISO_8859-1/books/handbook/l10n/chapter.sgml
Normal file
352
en_US.ISO_8859-1/books/handbook/l10n/chapter.sgml
Normal file
|
|
@ -0,0 +1,352 @@
|
|||
<chapter id="l10n">
|
||||
<title>Localization</title>
|
||||
|
||||
|
||||
<sect1 id="russian">
|
||||
<title>Russian Language (KOI8-R encoding)</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.ache;<!-- <br> --> 1 May
|
||||
1997</emphasis>.</para>
|
||||
|
||||
<para>See more info about KOI8-R encoding at <ulink
|
||||
URL="http://www.nagual.pp.ru/~ache/koi8.html">KOI8-R References
|
||||
(Russian Net Character Set)</ulink>.</para>
|
||||
|
||||
|
||||
<sect2 id="russian-console">
|
||||
<title>Console Setup</title>
|
||||
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Add following line to your kernel configuration file:
|
||||
|
||||
<programlisting>
|
||||
options "SC_MOUSE_CHAR=0x03"</programlisting> to move character
|
||||
codes used for mouse cursor off KOI8-R pseudographics
|
||||
range.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Russian console entry in
|
||||
<filename>/etc/rc.conf</filename> should looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
keymap=ru.koi8-r
|
||||
keychange="61 ^[[K"
|
||||
scrnmap=koi8-r2cp866
|
||||
font8x16=cp866b-8x16
|
||||
font8x14=cp866-8x14
|
||||
font8x8=cp866-8x8</programlisting>
|
||||
|
||||
<note>
|
||||
<para>^[ means that real ESC character must be entered into
|
||||
<filename>/etc/rc.conf</filename>, not just ^[
|
||||
string.</para>
|
||||
</note>
|
||||
|
||||
<para>This tuning means KOI8-R keyboard with Alternative
|
||||
screen font mapped to KOI8-R encoding to preserve
|
||||
pseudographics, <literal>Gray Delete</literal>
|
||||
key remapped to match Russian <citerefentry><refentrytitle>termcap</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry for FreeBSD
|
||||
console.</para>
|
||||
|
||||
<para>RUS/LAT switch will be <literal>CapsLock</literal>. Old CapsLock function still
|
||||
available via <literal>Shift+CapsLock</literal>.
|
||||
CapsLock LED will indicate RUS mode, not CapsLock
|
||||
mode.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>For each <literal>ttyv?</literal> entry in
|
||||
<filename>/etc/ttys</filename> change terminal type from
|
||||
<literal>cons25</literal> to <literal>cons25r</literal>, i.e. each entry should looks
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
ttyv0 "/usr/libexec/getty Pc" cons25r on secure</programlisting>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-locale">
|
||||
<title>Locale Setup</title>
|
||||
|
||||
<para><anchor id="russian-env"> There is two environment variables
|
||||
for locale setup:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><envar>LANG</envar> for POSIX
|
||||
<citerefentry><refentrytitle>setlocale</refentrytitle><manvolnum>3</manvolnum></citerefentry> family functions;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><envar>MM_CHARSET</envar> for applications MIME
|
||||
chararter set.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>The best way is using <filename>/etc/login.conf</filename>
|
||||
<literal>russian</literal> user's login class in
|
||||
<citerefentry><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry login class
|
||||
position. See <citerefentry><refentrytitle>login.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
|
||||
details.</para>
|
||||
|
||||
|
||||
<sect3 id="russian-class">
|
||||
<title>Login Class Method</title>
|
||||
|
||||
<para>First of all check your <filename>/etc/login.conf</filename>
|
||||
have <literal>russian</literal> login class, this
|
||||
entry may looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
russian:Russian Users Accounts:\
|
||||
:charset=KOI8-R:\
|
||||
:lang=ru_RU.KOI8-R:\
|
||||
:tc=default:</programlisting>
|
||||
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>vipw</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>vipw</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new
|
||||
users, <filename>/etc/master.passwd</filename> entry should
|
||||
looks like:</para>
|
||||
|
||||
<programlisting>
|
||||
user:password:1111:11:russian:0:0:User Name:/home/user:/bin/csh</programlisting>
|
||||
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new
|
||||
users:</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Set
|
||||
|
||||
<programlisting>
|
||||
defaultclass = russian</programlisting> in
|
||||
<filename>/etc/adduser.conf</filename> (you must enter
|
||||
<literal>default</literal> class for all
|
||||
non-Russian users in this case);</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Alternative variant will be answering <literal>russian</literal> each time when you see
|
||||
|
||||
<informalexample>
|
||||
<screen><prompt>Enter login class:</prompt> default []:</screen>
|
||||
</informalexample> prompt from
|
||||
<citerefentry><refentrytitle>adduser</refentrytitle><manvolnum>8</manvolnum></citerefentry>;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Another variant: call
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>adduser -class russian</userinput></screen>
|
||||
</informalexample> for each Russian user
|
||||
you want to add.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>How to do it with <citerefentry><refentrytitle>pw</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
|
||||
|
||||
<para>If you use <citerefentry><refentrytitle>pw</refentrytitle><manvolnum>8</manvolnum></citerefentry> for adding new users,
|
||||
call it in this form:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>pw useradd user_name -L russian</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect4>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Shell Startup Files Method</title>
|
||||
|
||||
<para>If you don't want to use
|
||||
<xref linkend="russian-class" remap="login class method"> for
|
||||
some reasons, just set this
|
||||
<xref linkend="russian-env" remap="two environment variables">
|
||||
in the following shell startup files:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/etc/profile</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
LANG=ru_RU.KOI8-R; export LANG
|
||||
MM_CHARSET=KOI8-R; export MM_CHARSET</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/etc/csh.login</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
setenv LANG ru_RU.KOI8-R
|
||||
setenv MM_CHARSET KOI8-R</programlisting>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>Alternatively you can add this instructions to</para>
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/usr/share/skel/dot.profile</filename>:</para>
|
||||
|
||||
<para>(similar to <filename>/etc/profile</filename>
|
||||
above);</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/usr/share/skel/dot.login</filename>:</para>
|
||||
|
||||
<para>(similar to <filename>/etc/csh.login</filename>
|
||||
above).</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-printer">
|
||||
<title>Printer Setup</title>
|
||||
|
||||
<para>Since most printers with Russian characters comes with
|
||||
hardware code page CP866, special output filter needed for KOI8-R
|
||||
-> CP866 conversion. Such filter installed by default as
|
||||
<filename>/usr/libexec/lpr/ru/koi2alt</filename>. So, Russian
|
||||
printer <filename>/etc/printcap</filename> entry should looks
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
lp|Russian local line printer:\
|
||||
:sh:of=/usr/libexec/lpr/ru/koi2alt:\
|
||||
:lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:</programlisting>
|
||||
|
||||
<para>See <citerefentry><refentrytitle>printcap</refentrytitle><manvolnum>5</manvolnum></citerefentry> for detailed description.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-msdosfs">
|
||||
<title>MSDOS FS and Russian file names</title>
|
||||
|
||||
<para>Look at following example <citerefentry><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> entry to enable support for Russian
|
||||
file names in MSDOS FS:</para>
|
||||
|
||||
<programlisting>
|
||||
/dev/sd0s1 /dos/c msdos rw,-W=koi2dos,-L=ru_RU.KOI8-R 0 0</programlisting>
|
||||
|
||||
<para>See
|
||||
<citerefentry><refentrytitle>mount_msdos</refentrytitle><manvolnum>8</manvolnum></citerefentry>for detailed description of
|
||||
<option>-W</option> and <option>-L</option> options.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="russian-xwindow">
|
||||
<title>X Window Setup</title>
|
||||
|
||||
<para>Step by step instructions:</para>
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Do
|
||||
<xref linkend="russian-locale" remap="non-X locale setup">
|
||||
first as described.</para>
|
||||
|
||||
<note>
|
||||
<para><anchor id="russian-note">Russian KOI8-R locale may
|
||||
not work with old XFree86 releases (lower than 3.3).
|
||||
XFree86 port from
|
||||
<filename>/usr/ports/x11/XFree86</filename> already have
|
||||
most recent XFree86 version, so it will work, if you
|
||||
install XFree86 from this port. XFree86 version shipped
|
||||
with the latest FreeBSD distribution should work too
|
||||
(check XFree86 version number not less than 3.3
|
||||
first).</para>
|
||||
</note>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Go to <filename>/usr/ports/russian/X.language</filename>
|
||||
directory and say
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample> there. This port install latest
|
||||
version of KOI8-R fonts. XFree86 3.3 already have some
|
||||
KOI8-R fonts, but this ones scaled better.</para>
|
||||
|
||||
<para>Check find <literal>"Files"</literal> section
|
||||
in your <filename>/etc/XF86Config</filename>, following
|
||||
lines must be before any other <literal>FontPath</literal>
|
||||
entries:</para>
|
||||
|
||||
<programlisting>
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/misc"
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/75dpi"
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/100dpi"</programlisting>
|
||||
|
||||
<para>If you use high resolution video mode, swap 75 dpi and
|
||||
100 dpi lines.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>To activate Russian keyboard add
|
||||
|
||||
<programlisting>
|
||||
XkbKeymap "xfree86(ru)"</programlisting> line into
|
||||
<literal>"Keyboard"</literal> section in your
|
||||
<filename>/etc/XF86Config</filename>, also make sure that
|
||||
<literal>XkbDisable</literal> is turned off
|
||||
(commented out) there.</para>
|
||||
|
||||
<para>RUS/LAT switch will be <literal>CapsLock</literal>. Old CapsLock function still
|
||||
available via <literal>Shift+CapsLock</literal>
|
||||
(in LAT mode only).</para>
|
||||
|
||||
<note>
|
||||
<para>Russian XKB keyboard may not work with old XFree86
|
||||
versions, see <xref
|
||||
linkend="russian-note" remap="locale note"> for more info.
|
||||
Russian XKB keyboard may not work with non-localized
|
||||
applications too, minimally localized application should
|
||||
call <literal>XtSetLanguageProc
|
||||
(NULL, NULL, NULL);</literal> function early in the program.</para>
|
||||
</note>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="german">
|
||||
<title>German Language (ISO 8859-1)</title>
|
||||
|
||||
<para>Slaven Rezic <email>eserte@cs.tu-berlin.de</email> wrote a tutorial how to use umlauts on a FreeBSD machine. The tutorial is written in German and available at <ulink URL="http://www.de.freebsd.org/de/umlaute/">http://www.de.freebsd.org/de/umlaute/</ulink>.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
827
en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml
Normal file
827
en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml
Normal file
|
|
@ -0,0 +1,827 @@
|
|||
<chapter id="linuxemu">
|
||||
<title>Linux Emulation</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.handy; and &a.rich;</emphasis></para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>How to Install the Linux Emulator</title>
|
||||
|
||||
<para>Linux emulation in FreeBSD has reached a point where it is
|
||||
possible to run a large fraction of Linux binaries in both a.out and
|
||||
ELF format. The linux emulation in the 2.1-STABLE branch is capable
|
||||
of running Linux DOOM and Mathematica; the version present in
|
||||
FreeBSD-2.2-RELEASE is vastly more capable and runs all these as
|
||||
well as Quake, Abuse, IDL, netrek for Linux and a whole host of
|
||||
other programs.</para>
|
||||
|
||||
<para>There are some Linux-specific operating system features that are
|
||||
not supported on FreeBSD. Linux binaries will not work on FreeBSD
|
||||
if they use the Linux <filename>/proc</filename> filesystem (which
|
||||
is different from the optional FreeBSD <filename>/proc</filename>
|
||||
filesystem) or i386-specific calls, such as enabling virtual 8086
|
||||
mode.</para>
|
||||
|
||||
<para>To tell whether your kernel is configured for Linux
|
||||
compatibility simply run any Linux binary. If it prints the error
|
||||
message <errorname>linux-executable: Exec format error. Wrong Architecture.</errorname> then you do not have linux compatibility support
|
||||
and you need to configure and install a new kernel.</para>
|
||||
|
||||
<para>Depending on which version of FreeBSD you are running, how you
|
||||
get Linux-emulation up will vary slightly:</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Emulation in 2.1-STABLE</title>
|
||||
|
||||
<para>The <filename>GENERIC</filename> kernel in 2.1-STABLE is not
|
||||
configured for linux compatibility so you must reconfigure your
|
||||
kernel for it. There are two ways to do this: 1. linking the
|
||||
emulator statically in the kernel itself and 2. configuring your
|
||||
kernel to dynamically load the linux loadable kernel module
|
||||
(LKM).</para>
|
||||
|
||||
<para>To enable the emulator, add the following to your
|
||||
configuration file (c.f.
|
||||
<filename>/sys/i386/conf/LINT</filename>):</para>
|
||||
|
||||
<programlisting>
|
||||
options COMPAT_LINUX</programlisting>
|
||||
|
||||
<para>If you want to run doom or other applications
|
||||
that need shared memory, also add the following.</para>
|
||||
|
||||
<programlisting>
|
||||
options SYSVSHM</programlisting>
|
||||
|
||||
<para>The linux system calls require 4.3BSD system
|
||||
call compatibility. So make sure you have the following.</para>
|
||||
|
||||
<programlisting>
|
||||
options "COMPAT_43"</programlisting>
|
||||
|
||||
<para>If you prefer to statically link the emulator in the kernel
|
||||
rather than use the loadable kernel module (LKM), then add</para>
|
||||
|
||||
<programlisting>
|
||||
options LINUX</programlisting>
|
||||
|
||||
<para>Then run config and install the new kernel as
|
||||
described in the
|
||||
<xref linkend="kernelconfig" remap="kernel configuration">
|
||||
section.</para>
|
||||
|
||||
<para>If you decide to use the LKM you must also install the
|
||||
loadable module. A mismatch of versions between the kernel and
|
||||
loadable module can cause the kernel to crash, so the safest thing
|
||||
to do is to reinstall the LKM when you install the kernel.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/lkm/linux</userinput>
|
||||
&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Once you have installed the kernel and the LKM,
|
||||
you can invoke `linux' as root to load the LKM.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>linux</userinput>
|
||||
Linux emulator installed
|
||||
Module loaded as ID 0</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To see whether the LKM is loaded, run
|
||||
<command>modstat</command>.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; modstat
|
||||
Type Id Off Loadaddr Size Info Rev
|
||||
Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You can cause the LKM to be loaded when the
|
||||
system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and
|
||||
2.1-STABLE enable it in <filename>/etc/sysconfig</filename>
|
||||
|
||||
<programlisting>
|
||||
linux=YES</programlisting> by changing it from NO to YES. FreeBSD 2.1
|
||||
RELEASE and earlier do not have such a line and on those you will
|
||||
need to edit <filename>/etc/rc.local</filename> to add the following line.</para>
|
||||
|
||||
<programlisting>
|
||||
linux</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Emulation in 2.2.2-RELEASE and later</title>
|
||||
|
||||
<para>It is no longer necessary to specify <literal>options LINUX</literal> or
|
||||
<literal>options COMPAT_LINUX</literal>. Linux emulation is done with an LKM
|
||||
(“Loadable Kernel Module”) so it can be installed on the fly
|
||||
without having to reboot. You will need the following things in
|
||||
your startup files, however:</para>
|
||||
<orderedlist>
|
||||
|
||||
<listitem>
|
||||
<para>In <filename>/etc/rc.conf</filename>, you need the
|
||||
following line:</para>
|
||||
|
||||
<programlisting>
|
||||
linux_enable=YES</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>This, in turn, triggers the following action in
|
||||
<filename>/etc/rc.i386</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
# Start the Linux binary emulation if requested.
|
||||
if [ "X${linux_enable}" = X"YES" ]; then echo -n '
|
||||
linux'; linux > /dev/null 2>&1
|
||||
fi</programlisting>
|
||||
</listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
|
||||
<para>If you want to verify it is running, modstat will do that:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>However, there have been reports that this
|
||||
fails on some 2.2-RELEASE and later systems. If for some reason
|
||||
you cannot load the linux LKM, then statically link the emulator
|
||||
in the kernel by adding
|
||||
|
||||
<programlisting>
|
||||
options LINUX</programlisting>
|
||||
|
||||
to your kernel config file. Then run config
|
||||
and install the new kernel as described in the <xref
|
||||
linkend="kernelconfig"
|
||||
remap="kernel configuration"> section.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Installing Linux Runtime Libraries</title>
|
||||
|
||||
|
||||
<sect3>
|
||||
<title>Installing using the linux_lib port</title>
|
||||
|
||||
<para>Most linux applications use shared libraries, so you are
|
||||
still not done until you install the shared libraries. It is
|
||||
possible to do this by hand, however, it is vastly simpler to
|
||||
just grab the linux_lib port:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/ports-current/emulators/linux_lib</userinput>
|
||||
&prompt.root; <userinput>make all install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>and you should have a working linux emulator. Legend (and
|
||||
the mail archives <!-- smiley -->:-) seems to hold that Linux emulation works
|
||||
best with linux binaries linked against the ZMAGIC libraries;
|
||||
QMAGIC libraries (such as those used in Slackware V2.0) may tend
|
||||
to give the Linuxulator heartburn. As of this writing (March
|
||||
1996) ELF emulation is still in the formulative stages but seems
|
||||
to work pretty well. Also, expect some programs to complain
|
||||
about incorrect minor versions. In general this does not seem
|
||||
to be a problem.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Installing libraries manually</title>
|
||||
|
||||
<para>If you do not have the “ports” distribution, you can
|
||||
install the libraries by hand instead. You will need the Linux
|
||||
shared libraries that the program depends on and the runtime
|
||||
linker. Also, you will need to create a "shadow root"
|
||||
directory, <filename>/compat/linux</filename>, for Linux
|
||||
libraries on your FreeBSD system. Any shared libraries opened
|
||||
by Linux programs run under FreeBSD will look in this tree
|
||||
first. So, if a Linux program loads, for example,
|
||||
<filename>/lib/libc.so</filename>, FreeBSD will first try to
|
||||
open <filename>/compat/linux/lib/libc.so</filename>, and if that
|
||||
does not exist then it will try
|
||||
<filename>/lib/libc.so</filename>. Shared libraries should be
|
||||
installed in the shadow tree
|
||||
<filename>/compat/linux/lib</filename> rather than the paths
|
||||
that the Linux <command>ld.so</command> reports.</para>
|
||||
|
||||
<para>FreeBSD-2.2-RELEASE and later works slightly differently
|
||||
with respect to <command>/compat/linux</command>. On -CURRENT, all files, not just
|
||||
libraries, are searched for from the “shadow root”
|
||||
<filename>/compat/linux</filename>.</para>
|
||||
|
||||
<para>Generally, you will need to look for the shared libraries
|
||||
that Linux binaries depend on only the first few times that you
|
||||
install a Linux program on your FreeBSD system. After a while,
|
||||
you will have a sufficient set of Linux shared libraries on your
|
||||
system to be able to run newly imported Linux binaries without
|
||||
any extra work.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>How to install additional shared libraries</title>
|
||||
|
||||
<para>What if you install the <filename>linux_lib</filename> port and your application
|
||||
still complains about missing shared libraries? How do you know
|
||||
which shared libraries Linux binaries need, and where to get
|
||||
them? Basically, there are 2 possibilities (when following these
|
||||
instructions: you will need to be root on your FreeBSD system to
|
||||
do the necessary installation steps).</para>
|
||||
|
||||
<para>If you have access to a Linux system, see what shared
|
||||
libraries it needs, and copy them to your FreeBSD system.
|
||||
Example: you have just ftp'ed the Linux binary of Doom. Put it
|
||||
on the Linux system you have access to, and check which shared
|
||||
libraries it needs by running <command>ldd linuxxdoom</command>:</para>
|
||||
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>ldd linuxxdoom</userinput>
|
||||
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
|
||||
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You would need to get all the files from the last column,
|
||||
and put them under <filename>/compat/linux</filename>, with the
|
||||
names in the first column as symbolic links pointing to them.
|
||||
This means you eventually have these files on your FreeBSD
|
||||
system:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/usr/X11/lib/libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
|
||||
/compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<note>
|
||||
<para>Note that if you already have a Linux shared library with
|
||||
a matching major revision number to the first column of the
|
||||
<command>ldd</command> output, you will not need to copy the file named in the
|
||||
last column to your system, the one you already have should
|
||||
work. It is advisable to copy the shared library anyway if it
|
||||
is a newer version, though. You can remove the old one, as
|
||||
long as you make the symbolic link point to the new one. So,
|
||||
if you have these libraries on your system:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/libc.so.4.6.27
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>and you find a new binary that claims to require a later
|
||||
version according to the output of <command>ldd</command>:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If it is only one or two versions out of date in the in
|
||||
the trailing digit then do not worry about copying
|
||||
<filename>/lib/libc.so.4.6.29</filename> too, because the
|
||||
program should work fine with the slightly older version.
|
||||
However, if you like you can decide to replace the
|
||||
<filename>libc.so</filename> anyway, and that should leave you
|
||||
with:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/libc.so.4.6.29
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
<para>The symbolic link mechanism is <emphasis>only</emphasis>
|
||||
needed for Linux binaries. The FreeBSD runtime linker takes
|
||||
care of looking for matching major revision numbers itself and
|
||||
you do not need to worry about it.</para>
|
||||
</note>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Configuring the <filename>ld.so</filename> — for FreeBSD
|
||||
2.2-RELEASE only</title>
|
||||
|
||||
<para>This section applies only to FreeBSD 2.2-RELEASE and later.
|
||||
Those running 2.1-STABLE should skip this section.</para>
|
||||
|
||||
<para>Finally, if you run FreeBSD 2.2-RELEASE you must make sure
|
||||
that you have the Linux runtime linker and its config files on
|
||||
your system. You should copy these files from the Linux system
|
||||
to their appropriate place on your FreeBSD system (to the
|
||||
<filename>/compat/linux</filename> tree):</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/compat/linux/lib/ld.so
|
||||
/compat/linux/etc/ld.so.config</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If you do not have access to a Linux system, you should get
|
||||
the extra files you need from various ftp sites. Information on
|
||||
where to look for the various files is appended below. For now,
|
||||
let us assume you know where to get the files.</para>
|
||||
|
||||
<para>Retrieve the following files (all from the same ftp site to
|
||||
avoid any version mismatches), and install them under
|
||||
<filename>/compat/linux</filename> (i.e.
|
||||
<filename>/foo/bar</filename> is installed as
|
||||
<filename>/compat/linux/foo/bar</filename>):</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>/sbin/ldconfig
|
||||
/usr/bin/ldd
|
||||
/lib/libc.so.x.y.z
|
||||
/lib/ld.so</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><command>ldconfig</command> and <command>ldd</command> do not necessarily need to be under
|
||||
<filename>/compat/linux</filename>; you can install them
|
||||
elsewhere in the system too. Just make sure they do not conflict
|
||||
with their FreeBSD counterparts. A good idea would be to install
|
||||
them in <filename>/usr/local/bin</filename> as <command>ldconfig-linux</command>
|
||||
and <command>ldd-linux</command>.</para>
|
||||
|
||||
<para>Create the file
|
||||
<filename>/compat/linux/etc/ld.so.conf</filename>, containing
|
||||
the directories in which the Linux runtime linker should look
|
||||
for shared libs. It is a plain text file, containing a directory
|
||||
name on each line. <filename>/lib</filename> and
|
||||
<filename>/usr/lib</filename> are standard, you could add the
|
||||
following:</para>
|
||||
|
||||
<programlisting>
|
||||
/usr/X11/lib
|
||||
/usr/local/lib</programlisting>
|
||||
|
||||
<para>When a linux binary opens a library such as
|
||||
<filename>/lib/libc.so</filename> the emulator maps the name to
|
||||
<filename>/compat/linux/lib/libc.so</filename> internally. All
|
||||
linux libraries should be installed under /compat/linux (e.g.
|
||||
<filename>/compat/linux/lib/libc.so</filename>,
|
||||
<filename>/compat/linux/usr/X11/lib/libX11.so</filename>, etc.)
|
||||
in order for the emulator to find them.</para>
|
||||
|
||||
<para>Those running FreeBSD 2.2-RELEASE should run the Linux
|
||||
ldconfig program.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root <userinput>cd /compat/linux/lib</userinput>
|
||||
&prompt.root; <userinput>/compat/linux/sbin/ldconfig</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para><command>ldconfig</command> is statically linked, so it does not need any
|
||||
shared libraries to run. It creates the file
|
||||
<filename>/compat/linux/etc/ld.so.cache</filename> which
|
||||
contains the names of all the shared libraries and should be
|
||||
rerun to recreate this file whenever you install additional
|
||||
shared libraries.</para>
|
||||
|
||||
<para>On 2.1-STABLE do not install
|
||||
<filename>/compat/linux/etc/ld.so.cache</filename> or run
|
||||
<command>ldconfig</command>; in 2.1-STABLE the syscalls are implemented differently
|
||||
and <command>ldconfig</command> is not needed or used.</para>
|
||||
|
||||
<para>You should now be set up for Linux binaries which only need
|
||||
a shared libc. You can test this by running the Linux <command>ldd</command> on
|
||||
itself. Supposing that you have it installed as <command>ldd-linux</command>, it
|
||||
should produce something like:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>ldd-linux `which ldd-linux`</userinput>
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This being done, you are ready to install new Linux
|
||||
binaries. Whenever you install a new Linux program, you should
|
||||
check if it needs shared libraries, and if so, whether you have
|
||||
them installed in the <filename>/compat/linux</filename> tree.
|
||||
To do this, you run the Linux version <command>ldd</command> on the new program,
|
||||
and watch its output. <command>ldd</command> (see also the manual page for <citerefentry><refentrytitle>ldd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
|
||||
will print a list of shared libraries that the program depends
|
||||
on, in the form <literal><replaceable>majorname</replaceable> (<replaceable>jumpversion</replaceable>) => <replaceable>fullname</replaceable></literal>.</para>
|
||||
|
||||
<para>If it prints <literal>not found</literal> instead of <replaceable>fullname</replaceable> it means that
|
||||
you need an extra library. The library needed is shown in
|
||||
majorname and will be of the form <literal>lib<replaceable>XXXX</replaceable>.so.<replaceable>N</replaceable></literal>. You will need to
|
||||
find a <filename>lib<replaceable>XXXX</replaceable>.so.N.mm</filename> on a Linux ftp site, and install it on
|
||||
your system. The <replaceable>XXXX</replaceable> (name) and <replaceable>N</replaceable> (major revision number)
|
||||
should match; the minor number(s) <replaceable>mm</replaceable> are less important, though
|
||||
it is advised to take the most recent version.</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring the host name resolver</title>
|
||||
|
||||
<para>If DNS does not work or you get the messages
|
||||
|
||||
<informalexample>
|
||||
<screen>resolv+: "bind" is an invalid keyword resolv+:
|
||||
"hosts" is an invalid keyword</screen>
|
||||
</informalexample>
|
||||
|
||||
then you need to configure a
|
||||
<filename>/compat/linux/etc/host.conf</filename> file containing:
|
||||
|
||||
<programlisting>
|
||||
order hosts, bind
|
||||
multi on</programlisting>
|
||||
|
||||
where the order here specifies that
|
||||
<filename>/etc/hosts</filename> is searched first and DNS is
|
||||
searched second. When
|
||||
<filename>/compat/linux/etc/host.conf</filename> is not installed
|
||||
linux applications find FreeBSD's
|
||||
<filename>/etc/host.conf</filename> and complain about the
|
||||
incompatible FreeBSD syntax. You should remove <literal>bind</literal> if you
|
||||
have not configured a name-server using the
|
||||
<filename>/etc/resolv.conf</filename> file.</para>
|
||||
|
||||
<para>Lastly, those who run 2.1-STABLE need to set an the
|
||||
<envar>RESOLV_HOST_CONF</envar> environment variable so that applications will
|
||||
know how to search the host tables. If you run FreeBSD
|
||||
2.2-RELEASE, you can skip this. For the
|
||||
<filename>/bin/csh</filename> shell use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>For <filename>/bin/sh</filename> use:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Finding the necessary files</title>
|
||||
|
||||
<note>
|
||||
<para>The information below is valid as of the time this document
|
||||
was written, but certain details such as names of ftp sites,
|
||||
directories and distribution names may have changed by the time
|
||||
you read this.</para>
|
||||
</note>
|
||||
|
||||
<para>Linux is distributed by several groups that make their own set
|
||||
of binaries that they distribute. Each distribution has its own
|
||||
name, like “Slackware” or “Yggdrasil”. The distributions are
|
||||
available on a lot of ftp sites. Sometimes the files are unpacked,
|
||||
and you can get the individual files you need, but mostly they are
|
||||
stored in distribution sets, usually consisting of subdirectories
|
||||
with gzipped tar files in them. The primary ftp sites for the
|
||||
distributions are:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>sunsite.unc.edu:/pub/Linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>tsx-11.mit.edu:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>Some European mirrors:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>ftp.luth.se:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>ftp.demon.co.uk:/pub/linux/distributions</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>src.doc.ic.ac.uk:/packages/linux/distributions</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
|
||||
<para>For simplicity, let us concentrate on Slackware here. This
|
||||
distribution consists of a number of subdirectories, containing
|
||||
separate packages. Normally, they are controlled by an install
|
||||
program, but you can retrieve files “by hand” too. First of all,
|
||||
you will need to look in the <filename>contents</filename> subdir of the
|
||||
distribution. You will find a lot of small text files here
|
||||
describing the contents of the separate packages. The fastest way
|
||||
to look something up is to retrieve all the files in the contents
|
||||
subdirectory, and grep through them for the file you need. Here is
|
||||
an example of a list of files that you might need, and in which
|
||||
contents-file you will find it by grepping through them:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Library</entry>
|
||||
<entry>Package</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row><entry><filename>ld.so</filename> </entry><entry>ldso
|
||||
</entry></row>
|
||||
<row><entry><filename>ldconfig</filename>
|
||||
</entry><entry>ldso </entry></row>
|
||||
<row><entry><filename>ldd</filename> </entry><entry>ldso
|
||||
</entry></row>
|
||||
<row><entry><filename>libc.so.4</filename>
|
||||
</entry><entry>shlibs </entry></row>
|
||||
<row><entry><filename>libX11.so.6.0</filename>
|
||||
</entry><entry>xf_lib
|
||||
</entry></row>
|
||||
<row><entry><filename>libXt.so.6.0</filename>
|
||||
</entry><entry>xf_lib
|
||||
</entry></row>
|
||||
<row><entry><filename>libX11.so.3</filename>
|
||||
</entry><entry>oldlibs
|
||||
</entry></row>
|
||||
<row><entry><filename>libXt.so.3</filename>
|
||||
</entry><entry>oldlibs
|
||||
</entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>So, in this case, you will need the packages ldso, shlibs,
|
||||
xf_lib and oldlibs. In each of the contents-files for these
|
||||
packages, look for a line saying <literal>PACKAGE LOCATION</literal>, it will
|
||||
tell you on which “disk” the package is, in our case it will tell
|
||||
us in which subdirectory we need to look. For our example, we
|
||||
would find the following locations:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<thead
|
||||
<row>
|
||||
<entry>Package</entry>
|
||||
<entry>Location</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row><entry>ldso </entry><entry>diska2 </entry></row>
|
||||
<row><entry>shlibs </entry><entry>diska2 </entry></row>
|
||||
<row><entry>oldlibs </entry><entry>diskx6 </entry></row>
|
||||
<row><entry>xf_lib </entry><entry>diskx9 </entry></row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>The locations called “disk<replaceable>XX</replaceable>” refer to the <filename>slakware/<replaceable>XX</replaceable></filename>
|
||||
subdirectories of the distribution, others may be found in the
|
||||
<filename>contrib</filename> subdirectory. In this case, we
|
||||
could now retrieve the packages we need by retrieving the
|
||||
following files (relative to the root of the Slackware
|
||||
distribution tree):</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>slakware/a2/ldso.tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/a2/shlibs.tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/x6/oldlibs/tgz</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>slakware/x9/xf_lib.tgz</filename></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>Extract the files from these gzipped tarfiles in your
|
||||
<filename>/compat/linux</filename> directory (possibly omitting or
|
||||
afterwards removing files you do not need), and you are
|
||||
done.</para>
|
||||
|
||||
<para><emphasis>See also:</emphasis>
|
||||
<filename>ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README</filename> and <filename>/usr/src/sys/i386/ibcs2/README.iBCS2</filename></para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mathematica">
|
||||
<title>How to Install Mathematica on FreeBSD</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.rich; and
|
||||
&a.chuck;</emphasis></para>
|
||||
|
||||
<para>This document shows how to install the Linux binary distribution
|
||||
of Mathematica 2.2 on FreeBSD 2.1.</para>
|
||||
|
||||
<para>Mathematica supports Linux but not FreeBSD as it stands. So
|
||||
once you have configured your system for Linux compatibility you
|
||||
have most of what you need to run Mathematica.</para>
|
||||
|
||||
<para>For those who already have the student edition of Mathematica
|
||||
for DOS the cost of upgrading to the Linux version at the time this
|
||||
was written, March 1996, was $45.00. It can be ordered directly
|
||||
from Wolfram at (217) 398-6500 and paid for by credit card.</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Unpacking the Mathematica distribution</title>
|
||||
|
||||
<para>The binaries are currently distributed by Wolfram on CDROM.
|
||||
The CDROM has about a dozen tar files, each of which is a binary
|
||||
distribution for one of the supported architectures. The one for
|
||||
Linux is named <filename>LINUX.TAR</filename>. You can, for
|
||||
example, unpack this into
|
||||
<filename>/usr/local/Mathematica</filename>:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local</userinput>
|
||||
&prompt.root; <userinput>mkdir Mathematica</userinput>
|
||||
&prompt.root; <userinput>cd Mathematica</userinput>
|
||||
&prompt.root; <userinput>tar -xvf /cdrom/LINUX.TAR</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Obtaining your Mathematica Password</title>
|
||||
|
||||
<para>Before you can run Mathematica you will have to obtain a
|
||||
password from Wolfram that corresponds to your “machine
|
||||
ID”.</para>
|
||||
|
||||
<para>Once you have installed the linux compatibility runtime
|
||||
libraries and unpacked the mathematica you can obtain the “machine
|
||||
ID” by running the program <command>mathinfo</command> in the Install directory.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local/Mathematica/Install</userinput>
|
||||
&prompt.root; <userinput>mathinfo</userinput>
|
||||
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
|
||||
richc.isdn.bcm.tmc.edu 9845-03452-90255</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>So, for example, the “machine ID” of <hostid>richc</hostid> is
|
||||
<literal>9845-03452-90255</literal>. You can ignore the message about the ioctl
|
||||
that is not implemented. It will not prevent Mathematica from
|
||||
running in any way and you can safely ignore it, though you will
|
||||
see the message every time you run Mathematica.</para>
|
||||
|
||||
<para>When you register with Wolfram, either by email, phone or fax,
|
||||
you will give them the “machine ID” and they will respond with a
|
||||
corresponding password consisting of groups of numbers. You need
|
||||
to add them both along with the machine name and license number in
|
||||
your mathpass file.</para>
|
||||
|
||||
<para>You can do this by invoking:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/local/Mathematica/Install</userinput>
|
||||
&prompt.root; <userinput>math.install</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>It will ask you to enter your license number
|
||||
and the Wolfram supplied password. If you get them mixed up or
|
||||
for some reason the math.install fails, that is OK; you can simply
|
||||
edit the file <filename>mathpass</filename> in this same directory to correct the
|
||||
info manually.</para>
|
||||
|
||||
<para>After getting past the password, math.install will ask you if
|
||||
you accept the install defaults provided, or if you want to use
|
||||
your own. If you are like us and distrust all install programs,
|
||||
you probably want to specify the actual directories. Beware.
|
||||
Although the math.install program asks you to specify directories,
|
||||
it will not create them for you, so you should perhaps have a
|
||||
second window open with another shell so that you can create them
|
||||
before you give them to the install program. Or, if it fails, you
|
||||
can create the directories and then restart the <command>math.install</command>
|
||||
program. The directories we chose to create beforehand and
|
||||
specify to <command>math.install</command> were:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename>/usr/local/Mathematica/bin</filename></entry>
|
||||
<entry>for binaries</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename>/usr/local/Mathematica/man/man1</filename></entry>
|
||||
<entry>for man pages</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>/usr/local/Mathematica/lib/X11</entry>
|
||||
<entry>for the XKeysymb file</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>You can also tell it to use
|
||||
<filename>/tmp/math.record</filename> for the system record file,
|
||||
where it puts logs of sessions. After this <command>math.install</command> will
|
||||
continue on to unpacking things and placing everything where it
|
||||
should go.</para>
|
||||
|
||||
<para>The Mathematica Notebook feature is included separately, as
|
||||
the X Front End, and you have to install it separately. To get the
|
||||
X Front End stuff correctly installed, cd into the
|
||||
<filename>/usr/local/Mathematica/FrontEnd</filename> directory and
|
||||
execute the <command>xfe.install</command> shell script. You will have to tell it
|
||||
where to put things, but you do not have to create any directories
|
||||
because it will use the same directories that had been created for
|
||||
math.install. When it finishes, there should be a new shell script
|
||||
in <filename>/usr/local/Mathematica/bin</filename> called
|
||||
<filename>mathematica</filename>.</para>
|
||||
|
||||
<para>Lastly, you need to modify each of the shell scripts that
|
||||
Mathematica has installed. At the beginning of every shell script
|
||||
in <filename>/usr/local/Mathematica/bin</filename> add the
|
||||
following line:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This tells Mathematica were to find its own
|
||||
version of the key mapping file <filename>XKeysymDB</filename>.
|
||||
Without this you will get pages of error messages about missing
|
||||
key mappings.</para>
|
||||
|
||||
<para>On 2.1-STABLE you need to add the following as well:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This tells Mathematica to use the linux version
|
||||
of host.conf. This file has a different syntax from FreeBSD's
|
||||
host.conf, so you will get an error message about
|
||||
<filename>/etc/host.conf</filename> if you leave this out.</para>
|
||||
|
||||
<para>You might also want to modify your
|
||||
<filename>/etc/manpath.config</filename> file to read the new man
|
||||
directory, and you may need to edit your
|
||||
<filename>~/.cshrc</filename> file to add
|
||||
<filename>/usr/local/Mathematica/bin</filename> to your
|
||||
path.</para>
|
||||
|
||||
<para>That is about all it takes. With this you should be able to
|
||||
type <command>mathematica</command> and get a really slick looking Mathematica
|
||||
Notebook screen up. Mathematica has included the Motif user
|
||||
interfaces, but it is compiled in statically, so you do not need
|
||||
the Motif libraries. Good luck doing this yourself!</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Bugs</title>
|
||||
|
||||
<para>The Notebook front end is known to hang sometimes when reading
|
||||
notebook files with an error messages similar to:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><errorname>File .../Untitled-1.mb appears to be broken for OMPR.257.0</errorname></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>We have not found the cause for this, but it only affects the
|
||||
Notebook's X Window front end, not the mathematica engine itself.
|
||||
So the command line interface invoked by 'math' is unaffected by
|
||||
this bug.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Acknowledgments</title>
|
||||
|
||||
<para>A well-deserved thanks should go to &a.sos; and &a.peter; who
|
||||
made linux emulation what it is today, and Michael Smith who drove
|
||||
these two guys like dogs to get it to the point where it runs
|
||||
Linux binaries better than linux! <!-- smiley -->:-)</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
581
en_US.ISO_8859-1/books/handbook/mail/chapter.sgml
Normal file
581
en_US.ISO_8859-1/books/handbook/mail/chapter.sgml
Normal file
|
|
@ -0,0 +1,581 @@
|
|||
<chapter id="mail">
|
||||
<title>Electronic Mail</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.wlloyd;.</emphasis></para>
|
||||
|
||||
<para>Electronic Mail configuration is the subject of many <xref
|
||||
linkend="bibliography" remap="System Administration"> books. If you
|
||||
plan on doing anything beyond setting up one mailhost for your
|
||||
network, you need industrial strength help.</para>
|
||||
|
||||
<para>Some parts of E-Mail configuration are controlled in the Domain
|
||||
Name System (DNS). If you are going to run your own own DNS server
|
||||
check out <filename>/etc/namedb</filename> and <command>man -k named</command> for more information.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Basic Information</title>
|
||||
|
||||
<para>These are the major programs involved in an E-Mail exchange. A
|
||||
“mailhost” is a server that is
|
||||
responsible for delivering and receiving all email for your host,
|
||||
and possibly your network.</para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>User program</title>
|
||||
|
||||
<para>This is a program like <application >elm</application>, <application>pine</application>,
|
||||
<application>mail</application>, or something more sophisticated like a WWW
|
||||
browser. This program will simply pass off all e-mail
|
||||
transactions to the local “mailhost” ,
|
||||
either by calling <command>sendmail</command> or
|
||||
delivering it over TCP.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Mailhost Server Daemon</title>
|
||||
|
||||
<para>Usually this program is <command>sendmail</command> or
|
||||
<command>smail</command> running in the background. Turn it off or
|
||||
change the command line options in
|
||||
<filename>/etc/rc.conf</filename> (or, prior to FreeBSD 2.2.2,
|
||||
<filename>/etc/sysconfig</filename>). It is best to leave it on,
|
||||
unless you have a specific reason to want it off. Example: You
|
||||
are building a <xref
|
||||
linkend="firewalls" remap="Firewall">.</para>
|
||||
|
||||
<para>You should be aware that <command>sendmail</command> is a potential weak link in a
|
||||
secure site. Some versions of <command>sendmail</command> have known security
|
||||
problems.</para>
|
||||
|
||||
<para><command>sendmail</command> does two jobs. It looks after delivering
|
||||
and receiving mail.</para>
|
||||
|
||||
<para>If <command>sendmail</command>
|
||||
needs to deliver mail off your site it will look up in
|
||||
the DNS to determine the actual host that will receive mail for
|
||||
the destination.</para>
|
||||
|
||||
<para>If it is acting as a delivery agent <command>sendmail</command> will take the message from the
|
||||
local queue and deliver it across the Internet to another sendmail
|
||||
on the receivers computer.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>DNS — Name Service</title>
|
||||
|
||||
<para>The Domain Name System and its daemon <command>named</command>, contain the database mapping
|
||||
hostname to IP address, and hostname to mailhost. The IP address
|
||||
is specified in an A record. The MX record specifies the
|
||||
mailhost that will receive mail for you. If you do not have a
|
||||
MX record mail for your hostname, the mail will be delivered to
|
||||
your host directly.</para>
|
||||
|
||||
<para>Unless you are running your own DNS server, you will not be
|
||||
able to change any information in the DNS yourself. If you are
|
||||
using an Internet Provider, speak to them.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>POP Servers</title>
|
||||
|
||||
<para>This program gets the mail from your mailbox and gives it to
|
||||
your browser. If you want to run a POP server on your computer,
|
||||
you will need to do 2 things.</para>
|
||||
|
||||
<procedure>
|
||||
|
||||
<step>
|
||||
<para>Get pop software from the <ulink
|
||||
URL="../ports/mail.html">Ports collection</ulink> that
|
||||
can be found in <filename>/usr/ports</filename> or packages
|
||||
collection. This handbook section has a complete reference
|
||||
on the <xref linkend="ports"
|
||||
remap="Ports"> system.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Modify <filename>/etc/inetd.conf</filename>
|
||||
to load the POP server.</para>
|
||||
</step>
|
||||
|
||||
</procedure>
|
||||
|
||||
<para>The pop program will have instructions with it. Read
|
||||
them.</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Configuration</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Basic</title>
|
||||
|
||||
<para>As your FreeBSD system comes “out of the box”[TM], you should
|
||||
be able to send E-mail to external hosts as long as you have
|
||||
<filename>/etc/resolv.conf</filename> setup or are running a name
|
||||
server. If you want to have mail for your host delivered to your
|
||||
specific host,there are two methods:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Run a name server (<command>man -k named</command>) and have your own domain
|
||||
<hostid role="domainname">smallminingco.com </hostid></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Get mail delivered to the current DNS name for your host.
|
||||
Ie: <hostid role="fqdn">dorm6.ahouse.school.edu </hostid></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>No matter what option you choose, to have mail delivered
|
||||
directly to your host, you must be a full Internet host. You must
|
||||
have a permanent IP address. IE: NO dynamic PPP. If you are
|
||||
behind a firewall, the firewall must be passing on smtp traffic to
|
||||
you. From <filename>/etc/services</filename>:</para>
|
||||
|
||||
<programlisting
|
||||
>smtp 25/tcp mail #Simple Mail Transfer</programlisting>
|
||||
|
||||
<para>If you
|
||||
want to receive mail at your host itself, you must make sure that
|
||||
the DNS MX entry points to your host address, or there is no MX
|
||||
entry for your DNS name.</para>
|
||||
|
||||
<para>Try this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>hostname</userinput>
|
||||
newbsdbox.freebsd.org
|
||||
&prompt.root; <userinput>host newbsdbox.freebsd.org</userinput>
|
||||
newbsdbox.freebsd.org has address 204.216.27.xx</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If that is all that comes out for your machine, mail directory
|
||||
to <email>root@newbsdbox.freebsd.org</email>
|
||||
will work no problems.</para>
|
||||
|
||||
<para>If instead, you have this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>host newbsdbox.freebsd.org</userinput>
|
||||
newbsdbox.FreeBSD.org has address 204.216.27.xx
|
||||
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.org</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>All mail sent to your host
|
||||
directly will end up on <hostid>freefall</hostid>, under the same username.</para>
|
||||
|
||||
<para>This information is setup in your domain name server. This
|
||||
should be the same host that is listed as your primary nameserver
|
||||
in <filename>/etc/resolv.conf</filename></para>
|
||||
|
||||
<para>The DNS record that carries mail routing information is the
|
||||
Mail eXchange entry. If no MX entry exists, mail will be
|
||||
delivered directly to the host by way of the Address
|
||||
record.</para>
|
||||
|
||||
<para>The MX entry for <hostid role="fqdn">freefall.freebsd.org</hostid> at one time.</para>
|
||||
|
||||
<programlisting>
|
||||
freefall MX 30 mail.crl.net
|
||||
freefall MX 40 agora.rdrop.com
|
||||
freefall HINFO Pentium FreeBSD
|
||||
freefall MX 10 freefall.FreeBSD.org
|
||||
freefall MX 20 who.cdrom.com
|
||||
freefall A 204.216.27.xx
|
||||
freefall CNAME www.FreeBSD.org</programlisting>
|
||||
|
||||
<para><hostid>freefall</hostid> has many MX entries. The lowest MX number gets the
|
||||
mail in the end. The others will queue mail temporarily, if
|
||||
<hostid>freefall</hostid> is busy or down.</para>
|
||||
|
||||
<para>Alternate MX sites should have separate connections to the
|
||||
Internet, to be most useful. An Internet Provider or other
|
||||
friendly site can provide this service.</para>
|
||||
|
||||
<para><command>dig</command>, <command>nslookup</command>,
|
||||
and <command>host</command> are your friends.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="mail-domain">
|
||||
<title>Mail for your Domain (Network).</title>
|
||||
|
||||
<para>To setup up a network mailhost, you need to direct the mail
|
||||
from arriving at all the workstations. In other words, you want to
|
||||
hijack all mail for <hostid role="domainname">*.smallminingco.com
|
||||
</hostid> and divert it to one machine, your “mailhost”.</para>
|
||||
|
||||
<para>The network users on their workstations will most likely pick
|
||||
up their mail over POP or telnet.</para>
|
||||
|
||||
<para>A user account with the <emphasis>same username</emphasis> should exist on both
|
||||
machines. Please use <command>adduser</command> to do
|
||||
this as required. If you set the <literal>shell</literal> to
|
||||
<literal>/nonexistent</literal>
|
||||
the user will not be allowed to login.</para>
|
||||
|
||||
<para>The mailhost that you will be using must be designated the
|
||||
Mail eXchange for each workstation. This must be arranged in DNS
|
||||
(ie BIND, named). Please refer to a Networking book for in-depth
|
||||
information.</para>
|
||||
|
||||
<para>You basically need to add these lines in your DNS server.</para>
|
||||
|
||||
<programlisting>
|
||||
pc24.smallminingco.com A <replaceable>xxx.xxx.xxx.xxx</replaceable> ; Workstation ip
|
||||
MX 10 smtp.smallminingco.com ; Your mailhost</programlisting>
|
||||
|
||||
<para>You cannot do this yourself unless you are running a DNS
|
||||
server. If you do not want to run a DNS server, get somebody else
|
||||
like your Internet Provider to do it.</para>
|
||||
|
||||
<para>This will redirect mail for the workstation to the Mail
|
||||
eXchange host. It does not matter what machine the A record
|
||||
points to, the mail will be sent to the MX host.</para>
|
||||
|
||||
<para>This feature is used to implement Virtual E-Mail Hosting.</para>
|
||||
|
||||
<para>Example</para>
|
||||
|
||||
<para>I have a customer with domain foo.bar and I want all mail for
|
||||
foo.bar to be sent to my machine smtp.smalliap.com. You must make
|
||||
an entry in your DNS server like:</para>
|
||||
|
||||
<programlisting>
|
||||
foo.bar MX 10 smtp.smalliap.com ; your mailhost</programlisting>
|
||||
|
||||
<para>The A record is not needed if you only
|
||||
want E-Mail for the domain. IE: Don't expect <command>ping foo.bar</command>
|
||||
to work unless an Address record for <filename>foo.bar</filename>
|
||||
exists as well.</para>
|
||||
|
||||
<para>On the mailhost that actually accepts mail for final delivery
|
||||
to a mailbox, <command>sendmail</command> must be told what hosts it will be
|
||||
accepting mail for.</para>
|
||||
|
||||
<para>Add <literal>pc24.smallminingco.com</literal> to <filename>/etc/sendmail.cw</filename> (if you are
|
||||
using <literal>FEATURE(use_cw_file)</literal>), or add a <literal>Cw myhost.smalliap.com</literal>
|
||||
line to <filename>/etc/sendmail.cf</filename></para>
|
||||
|
||||
<para>If you plan on doing anything serious with <command>sendmail</command> you should install the <command>sendmail</command>
|
||||
source. The source has plenty of documentation with it. You will
|
||||
find information on getting <command>sendmail</command>
|
||||
source from <xref linkend="sendmailuucp" remap="the UUCP
|
||||
information">.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 id="sendmailuucp">
|
||||
<title>Setting up UUCP.</title>
|
||||
|
||||
<para><emphasis>Stolen from the FAQ.</emphasis></para>
|
||||
|
||||
<para>The sendmail configuration that ships with FreeBSD is suited
|
||||
for sites that connect directly to the Internet. Sites that wish
|
||||
to exchange their mail via UUCP must install another <command>sendmail</command>
|
||||
configuration file.</para>
|
||||
|
||||
<para>Tweaking <filename>/etc/sendmail.cf</filename> manually is
|
||||
considered something for purists. Sendmail version 8 comes with a
|
||||
new approach of generating config files via some <command>m4</command> preprocessing, where the actual
|
||||
hand-crafted configuration is on a higher abstraction level. You
|
||||
should use the configuration files under
|
||||
<filename>/usr/src/usr.sbin/sendmail/cf</filename>.</para>
|
||||
|
||||
<para>If you did not install your system with full sources, the
|
||||
<command>sendmail</command> config stuff has been broken out into a separate source
|
||||
distribution tarball just for you. Assuming you have your CD-ROM
|
||||
mounted, do:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
|
||||
&prompt.root; <userinput>tar -xvzf /cdrom/dists/src/ssmailcf.aa</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Do not panic, this is only a few hundred kilobytes in size.
|
||||
The file <filename>README</filename> in the <filename>cf</filename> directory can serve as a basic
|
||||
introduction to m4 configuration.</para>
|
||||
|
||||
<para>For UUCP delivery, you are best advised to use the
|
||||
<emphasis>mailertable</emphasis> feature. This constitutes a
|
||||
database that <command>sendmail</command> can use to base its routing decision
|
||||
upon.</para>
|
||||
|
||||
<para>First, you have to create your <filename>.mc</filename> file.
|
||||
The directory
|
||||
<filename>/usr/src/usr.sbin/sendmail/cf/cf</filename> is the home
|
||||
of these files. Look around, there are already a few examples.
|
||||
Assuming you have named your file <filename>foo.mc</filename>, all
|
||||
you need to do in order to convert it into a valid
|
||||
<filename>sendmail.cf</filename> is:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/sendmail/cf/cf</userinput>
|
||||
&prompt.root; <userinput>make foo.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If you don't have a <filename>/usr/obj</filename> hiearchy,
|
||||
then:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cp foo.cf /etc/sendmail.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Otherwise:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cp /usr/obj/`pwd`/foo.cf /etc/sendmail.cf</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>A typical <filename>.mc</filename> file might look
|
||||
like:</para>
|
||||
|
||||
<programlisting>
|
||||
include(`../m4/cf.m4')
|
||||
VERSIONID(`<replaceable>Your version number</replaceable>')
|
||||
OSTYPE(bsd4.4)
|
||||
|
||||
FEATURE(nodns)
|
||||
FEATURE(nocanonify)
|
||||
FEATURE(mailertable)
|
||||
|
||||
define(`UUCP_RELAY', <replaceable>your.uucp.relay</replaceable>)
|
||||
define(`UUCP_MAX_SIZE', 200000)
|
||||
|
||||
MAILER(local)
|
||||
MAILER(smtp)
|
||||
MAILER(uucp)
|
||||
|
||||
Cw <replaceable>your.alias.host.name</replaceable>
|
||||
Cw <replaceable>youruucpnodename.UUCP</replaceable></programlisting>
|
||||
|
||||
<para>The <literal>nodns</literal> and
|
||||
<literal>nocanonify</literal> features will prevent any usage of
|
||||
the DNS during mail delivery. The <literal>UUCP_RELAY</literal>
|
||||
clause is needed for bizarre reasons, do not ask. Simply put an
|
||||
Internet hostname there that is able to handle .UUCP pseudo-domain
|
||||
addresses; most likely, you will enter the mail relay of your ISP
|
||||
there.</para>
|
||||
|
||||
<para>Once you have this, you need this file called
|
||||
<filename>/etc/mailertable</filename>. A typical example of this
|
||||
gender again:</para>
|
||||
|
||||
<programlisting>
|
||||
#
|
||||
# makemap hash /etc/mailertable.db < /etc/mailertable
|
||||
#
|
||||
horus.interface-business.de uucp-dom:horus
|
||||
.interface-business.de uucp-dom:if-bus
|
||||
interface-business.de uucp-dom:if-bus
|
||||
.heep.sax.de smtp8:%1 horus.UUCP
|
||||
uucp-dom:horus if-bus.UUCP
|
||||
uucp-dom:if-bus . uucp-dom:sax</programlisting>
|
||||
|
||||
<para>As you can see, this is part of a real-life file. The first
|
||||
three lines handle special cases where domain-addressed mail
|
||||
should not be sent out to the default route, but instead to some
|
||||
UUCP neighbor in order to “shortcut” the delivery path. The
|
||||
next line handles mail to the local Ethernet domain that can be
|
||||
delivered using SMTP. Finally, the UUCP neighbors are mentioned
|
||||
in the .UUCP pseudo-domain notation, to allow for a
|
||||
<literal>uucp-neighbor!recipient</literal> override of the default rules. The
|
||||
last line is always a single dot, matching everything else, with
|
||||
UUCP delivery to a UUCP neighbor that serves as your universal
|
||||
mail gateway to the world. All of the node names behind the
|
||||
<literal>uucp-dom:</literal> keyword must be valid UUCP
|
||||
neighbors, as you can verify using the command <command>uuname</command>.</para>
|
||||
|
||||
<para>As a reminder that this file needs to be converted into a DBM
|
||||
database file before being usable, the command line to accomplish
|
||||
this is best placed as a comment at the top of the <filename>mailertable</filename>.
|
||||
You always have to execute this command each time you change your
|
||||
<filename>mailertable</filename>.</para>
|
||||
|
||||
<para>Final hint: if you are uncertain whether some particular mail
|
||||
routing would work, remember the <option>-bt</option> option to
|
||||
<command>sendmail</command>. It starts <command>sendmail</command>
|
||||
in “address test
|
||||
mode”; simply enter <literal>0</literal>, followed by the address
|
||||
you wish to test for the mail routing. The last line tells you
|
||||
the used internal mail agent, the destination host this agent will
|
||||
be called with, and the (possibly translated) address. Leave this
|
||||
mode by typing Control-D.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>sendmail -bt</userinput>
|
||||
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
|
||||
Enter <ruleset> <address>
|
||||
<prompt>></prompt> <userinput>0 foo@interface-business.de</userinput>
|
||||
rewrite: ruleset 0 input: foo @ interface-business . de
|
||||
…
|
||||
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo < @ interface-business . de</screen>
|
||||
</informalexample>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="mailfaq">
|
||||
<title>FAQ</title>
|
||||
|
||||
<para><emphasis>Migration from FAQ.</emphasis></para>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Why do I have to use the FQDN for hosts on my site?</title>
|
||||
|
||||
<para>You will probably find that the host is actually in a
|
||||
different domain; for example, if you are in <hostid role="fqdn">foo.bar.edu</hostid> and you
|
||||
wish to reach a host called <hostid>mumble</hostid> in the <hostid
|
||||
role="domainname">bar.edu</hostid> domain, you
|
||||
will have to refer to it by the fully-qualified domain name,
|
||||
<hostid role="fqdn">mumble.bar.edu</hostid>, instead of just <hostid>mumble</hostid>.</para>
|
||||
|
||||
<para>Traditionally, this was allowed by BSD BIND resolvers. However
|
||||
the current version of <application>BIND</application> that ships with
|
||||
FreeBSD no longer provides default abbreviations for non-fully
|
||||
qualified domain names other than the domain you are in. So an
|
||||
unqualified host <hostid>mumble</hostid> must either
|
||||
be found as <hostid role="fqdn">mumble.foo.bar.edu</hostid>, or
|
||||
it will be searched for in the root domain.</para>
|
||||
|
||||
<para>This is different from the previous behavior, where the search
|
||||
continued across <hostid role="domainname">mumble.bar.edu</hostid>,
|
||||
and <hostid role="domainname">mumble.edu</hostid>. Have a look at
|
||||
RFC 1535 for why this was considered bad practice, or even a
|
||||
security hole.</para>
|
||||
|
||||
<para>As a good workaround, you can place the line
|
||||
|
||||
<programlisting>
|
||||
search foo.bar.edu bar.edu</programlisting>
|
||||
|
||||
instead of the previous
|
||||
|
||||
<programlisting>
|
||||
domain foo.bar.edu</programlisting>
|
||||
|
||||
into your <filename>/etc/resolv.conf</filename>. However,
|
||||
make sure that the search order does not go beyond the “boundary
|
||||
between local and public administration”, as RFC 1535 calls
|
||||
it.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Sendmail says <errorname>mail loops back to myself</errorname></title>
|
||||
|
||||
<para>This is answered in the sendmail FAQ as follows:</para>
|
||||
|
||||
<programlisting>
|
||||
* I am getting "Local configuration error" messages, such as:
|
||||
|
||||
553 relay.domain.net config error: mail loops back to myself
|
||||
554 <user@domain.net>... Local configuration error
|
||||
|
||||
How can I solve this problem?
|
||||
|
||||
You have asked mail to the domain (e.g., domain.net) to be
|
||||
forwarded to a specific host (in this case, relay.domain.net)
|
||||
by using an MX record, but the relay machine does not recognize
|
||||
itself as domain.net. Add domain.net to /etc/sendmail.cw
|
||||
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
|
||||
to /etc/sendmail.cf.</programlisting>
|
||||
|
||||
<para>The sendmail FAQ is in
|
||||
<filename>/usr/src/usr.sbin/sendmail</filename> and is recommended
|
||||
reading if you want to do any “tweaking” of your mail
|
||||
setup.</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>How can I do E-Mail with a dialup PPP host?</title>
|
||||
|
||||
<para>You want to connect a FreeBSD box on a lan, to the Internet.
|
||||
The FreeBSD box will be a mail gateway for the lan. The PPP
|
||||
connection is non-dedicated.</para>
|
||||
|
||||
<para>There are at least two way to do this.</para>
|
||||
|
||||
<para>The other is to use UUCP.</para>
|
||||
|
||||
<para>The key is to get a Internet site to provide secondary MX
|
||||
services for your domain. For example:</para>
|
||||
|
||||
<programlisting>
|
||||
bigco.com. MX 10 bigco.com.
|
||||
MX 20 smalliap.com.</programlisting>
|
||||
|
||||
<para>Only one host should be specified as the final recipient ( add
|
||||
<literal>Cw bigco.com</literal> in <filename>/etc/sendmail.cf</filename> on
|
||||
bigco.com).</para>
|
||||
|
||||
<para>When the senders <command>sendmail</command> is trying to deliver the mail it
|
||||
will try to connect to you over the modem link. It will most
|
||||
likely time out because you are not online. <command>sendmail</command> will
|
||||
automatically deliver it to the secondary MX site, ie your
|
||||
Internet provider. The secondary MX site will try every
|
||||
(<literal>sendmail_flags = "-bd -q15m"</literal> in
|
||||
<filename>/etc/rc.conf</filename> ) 15 minutes to connect to your
|
||||
host to deliver the mail to the primary MX site.</para>
|
||||
|
||||
<para>You might wat to use something like this as a login script.</para>
|
||||
|
||||
<programlisting>
|
||||
#!/bin/sh
|
||||
# Put me in /usr/local/bin/pppbigco
|
||||
( sleep 60 ; /usr/sbin/sendmail -q ) &
|
||||
/usr/sbin/ppp -direct pppbigco</programlisting>
|
||||
|
||||
<para>If you are going to create a separate
|
||||
login script for a user you could use <command>sendmail
|
||||
-qRbigco.com</command> instead in the script above. This will
|
||||
force all mail in your queue for bigco.com to be processed
|
||||
immediately.</para>
|
||||
|
||||
<para>A further refinement of the situation is as follows.</para>
|
||||
|
||||
<para>Message stolen from the freebsd-isp mailing list.</para>
|
||||
|
||||
<programlisting>
|
||||
> we provide the secondary mx for a customer. The customer connects to
|
||||
> our services several times a day automatically to get the mails to
|
||||
> his primary mx (We do not call his site when a mail for his domains
|
||||
> arrived). Our sendmail sends the mailqueue every 30 minutes. At the
|
||||
> moment he has to stay 30 minutes online to be sure that all mail is
|
||||
> gone to the primary mx.
|
||||
>
|
||||
> Is there a command that would initiate sendmail to send all the mails
|
||||
> now? The user has not root-privileges on our machine of course.
|
||||
|
||||
In the 'privacy flags' section of sendmail.cf, there is a definition
|
||||
Opgoaway,restrictqrun
|
||||
|
||||
Remove restrictqrun to allow non-root users to start the queue processing.
|
||||
You might also like to rearrange the MXs. We are the 1st MX for our
|
||||
customers like this, and we have defined:
|
||||
|
||||
# If we are the best MX for a host, try directly instead of generating
|
||||
# local config error.
|
||||
OwTrue
|
||||
|
||||
That way a remote site will deliver straight to you, without trying
|
||||
the customer connection. You then send to your customer. Only works for
|
||||
"hosts", so you need to get your customer to name their mail machine
|
||||
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
|
||||
an A record in the DNS for "customer.com".</programlisting>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
1257
en_US.ISO_8859-1/books/handbook/mirrors/chapter.sgml
Normal file
1257
en_US.ISO_8859-1/books/handbook/mirrors/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
480
en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml
Normal file
480
en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml
Normal file
|
|
@ -0,0 +1,480 @@
|
|||
<chapter id="pgpkeys">
|
||||
<title>PGP keys</title>
|
||||
|
||||
<para>In case you need to verify a signature or send encrypted email to
|
||||
one of the officers or core team members a number of keys are
|
||||
provided here for your convenience.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Officers</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>FreeBSD Security Officer <email>security-officer@freebsd.org</email></title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.imp;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Core Team members</title>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>&a.asami;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jmb;</title>
|
||||
|
||||
<programlisting>
|
||||
Jonathan M. Bresler <jmb@FreeBSD.org>
|
||||
Key fingerprint = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2
|
||||
|
||||
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
|
||||
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
|
||||
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
|
||||
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNA3x
|
||||
ffUVW/uOVC1dAQHGdAQAgsnYklBtVUdGuQwXB3bYp9omTD7CVD0aibVrz+lXiPDh
|
||||
aTVkOC1uhEwL59+R8VdpAnEDMobdZDA/ihCc+6/FW/eE0uyrWZzb5Ng9V1MfC6HI
|
||||
+sXpeXPy585Z56ewadV2yY9rvzcwmmUNHmAXT/5O0S2AWB0EJZ+cewTrokSTVVOJ
|
||||
AJUDBRA0C3EoVS4eLnPSiKUBASb+A/95g6w9DDPRGDlbsl4pN1BlSPKrmDQPRK1X
|
||||
C3bddDY2HNelSNhzp2FYD0WoN1re1vMJV0oaaJHwv7wjbe3+SYEX/IdmtfzI0MbZ
|
||||
Q/uPybPJOxi2ud6C6J+mEGJN9iBCnsaCz8CETuC9gR1mtxsxySUj9mk0fxKfdP6S
|
||||
3QDrv6CQ1IkAlQMFEDKsi9CzWmLrWZ8yPQEBduUD/RhV4Qa89rYls9vtIFm6XBjZ
|
||||
8mW37FYxeqIxg3ZrIyTMlghsOPV0f7zymCCWPRGKOLePRiGo0ZCEkDTYiM9tnwQI
|
||||
09rmPWJb50yfTSZXjHx6+Hcm6O6BCmDFloo0Mxo6n9pvMH/TmmqHxCsAV+p8XEWy
|
||||
rMZvwVSynMxmJd17Y5HLtBNKb25hdGhhbiBNLiBCcmVzbGVyiQCVAwUQMbYtYQHb
|
||||
XdKX5jjdAQHEHwP/fEaQoTi7zKD1U/5kW2YPIBUyMTpLiO9QOr4stYjJvhHh4Ejw
|
||||
fGvMIhbFrPKtxSNH1s3m4jAXKXiQBDCz17IIzL4n8dlunxNGE5MHcsmpWzggyIg4
|
||||
zbPqPOcg4gLFEWsEkr2o0akwzIGa3tbCvC+ITaX/rdlWV1jaQjTqSNyPZBM=
|
||||
=RV56
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.ache;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jkh;</title>
|
||||
|
||||
<programlisting>
|
||||
Jordan K. Hubbard <jkh@FreeBSD.org>
|
||||
Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2i
|
||||
|
||||
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
|
||||
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
|
||||
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
|
||||
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokAlQMFEDF75D1r
|
||||
WmeNgbKneQEBXtcD+gJIv8JzZRKlDZyTCQanK8iRgE+zMhxptI0kDObaGxT1BrpY
|
||||
4/EPyiUN10G4k2Jb+DOc8Lg2xDQ3xmvgipFf9NMNV/ThaEuZ3wA31I6tW/arQEqB
|
||||
Tp8u6T3v20m62t7Afo9HaoE6MBpHQUk2TilxgAd5P57sporL3pgW9YojIO9ziQCV
|
||||
AwUQMXyV2h9/qQgDWPy9AQEMfgP/RmbSg2WlesATUQ4WuanjcdREduKPyfQatrXD
|
||||
2xt+jg9X78dTyiNN1YvLqvT6msfs04MKSC0hA2mou6ozw8Xak+1QmP0fBOZKp9pP
|
||||
8szO188Do9ByzJPvHF1eXT7jFMOXVq8ZIl9iwjxcIDLzlxOz49DC7LO6AT+LKQk7
|
||||
UGeP+lqJAJUDBRAxe+UG9RVb+45ULV0BAXZ9A/9F9gLpGukVNkeOjaqxQdJGTS+a
|
||||
xh/Abk0c/nKhAEyxpAl5JyQ3ifYk6BHhPvlTi9LrZoXGA8sk/eU4eRTZVzvGEC4G
|
||||
+xsavlE/xzku8855QTLPpkCunUpQeu1wzaIrUUE6Zjh05imFbJYyQOBgTFpuqWsC
|
||||
rsUpl+2mr8IGIxG5rA==
|
||||
=LW9i
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.phk;</title>
|
||||
|
||||
<programlisting>
|
||||
Poul-Henning Kamp <phk@FreeBSD.org>
|
||||
Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.3ia
|
||||
|
||||
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI
|
||||
ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA
|
||||
K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR
|
||||
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDMGK9qz
|
||||
WmLrWZ8yPQEB4iED/18bQVhV2gUYFSxIUTaUtO2HVPi7GRpSzmXoTfS+FJyRR0ED
|
||||
zTqTHstoBe2PeWgTsOf9cUub5UKcJkRQp7VrJv4Kncyuq7pX69a+QMveCzuUwAur
|
||||
nDbt/emOL6NU8g9Uk50QuOuipb5rULQLRRoF5TkViy/VES83ERXdYQ9Ml3fWiQCV
|
||||
AwUQMX6NfWtaZ42Bsqd5AQEKsgP+L+uLz95dRdEmnZ+omrO+tYZM/0jHU7i8yC5q
|
||||
H0gguKOCljI4liR7NkqKONUJWYtfsTB81d9iSosBZRrTx6i/hB8l8kOB975n/f9S
|
||||
hftFwmjLYCNMFlDM4j0kySvMV20UZjAyv9BeE51VWlIZ5n/oeSuzul3Znow02tF/
|
||||
zVnInJiJAJUDBRAxfJXn9RVb+45ULV0BAXJ8A/9K6NT6VLZZC5q3g7bBk5DWuzBS
|
||||
3oK2Ebww6xzsD2R9edltoz1J3GPngK0CWpHh4kw5iTaRWoC2YJYRNG6icnGvlMAl
|
||||
1/urqQHJVhxATINm8oljDKsj1RBJ6VKBzNbCJIHTVpX0AJoqUQX2Idi8goFr0fAm
|
||||
7cD2CBb1JhoAdzEfO4kAlQMFEDFLHlwff6kIA1j8vQEBj5MD/1hA8hJdhpL7mvQj
|
||||
rTAIn6Ldr08Lr1lqTaKSBMdCL3suGlW0Sw/dIBgicPDhgxLahT3DVfGiIst32FSl
|
||||
xmWY7wine80X4TZkJ9Hiw3Mpqtjl92j6zHNq0ZZE+CceNubpEdYLDqokAIMPdWlo
|
||||
WPHZcPxCs5PKI5udseFYF2gQAjI2iQCVAwUQMTlDoO9huekR1Y7VAQGy+AP/Rzp+
|
||||
UGtJavbSiPx5EnXOXxkA/+ulXQgQG9vdkWwewkvxDNOzHW3KkUWCGtPtIMENznbF
|
||||
j3QlYB+USIaf1ogvlD5EdXGPDfTINpE8CX2WXzajfgYFpYETDzduwjoWDZfEN9zZ
|
||||
fQqQS62VgAReOIz3k9BL708z/+WUO0++RLGCmImJAJUDBRAw5q8kAPLZCeu7G0EB
|
||||
AT3bBACwo+r9TgbiSyyU5cZpq5KgGT1c7eUHXjtxKmtrXD1nFNJ6j7x2DM2XGe6B
|
||||
YOfDWbFq4UkEAyAeXviuuUP4enQu1v2g7JGXeuI8bRM519pLdPzDq/DnbA4rNStn
|
||||
/SkH7awMfNSplcFuE6rc5ezVkw17eOHzDrYmwsFavL9gxZEycg==
|
||||
=Q45T
|
||||
-----END PGP PUBLIC KEY BLOCK-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.rich;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.jdp;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.guido;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.peter;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>&a.joerg;</title>
|
||||
|
||||
<programlisting>
|
||||
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-----</programlisting>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
283
en_US.ISO_8859-1/books/handbook/policies/chapter.sgml
Normal file
283
en_US.ISO_8859-1/books/handbook/policies/chapter.sgml
Normal file
|
|
@ -0,0 +1,283 @@
|
|||
<chapter id="policies">
|
||||
<title>Source Tree Guidelines and Policies</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.phk;.</emphasis></para>
|
||||
|
||||
<para>This chapter documents various guidelines and policies in force
|
||||
for the FreeBSD source tree.</para>
|
||||
|
||||
|
||||
<sect1 id="policies-maintainer">
|
||||
<title><makevar>MAINTAINER</makevar> on Makefiles</title>
|
||||
|
||||
<para>June 1996.</para>
|
||||
|
||||
<para>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
|
||||
|
||||
<programlisting>
|
||||
MAINTAINER= email-addresses</programlisting>
|
||||
|
||||
line to the <filename>Makefile</filename>s covering this portion
|
||||
of the source tree.</para>
|
||||
|
||||
<para>The semantics of this are as follows:</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Contributed Software</title>
|
||||
|
||||
<para>June 1996.</para>
|
||||
|
||||
<para>Some parts of the FreeBSD distribution consist of software that
|
||||
is actively being maintained outside the FreeBSD project. For
|
||||
historical reasons, we call this <emphasis>contributed</emphasis>
|
||||
software. Some examples are perl, gcc and patch.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The <application>Tcl</application> embedded programming
|
||||
language will be used as example of how this model works:</para>
|
||||
|
||||
<para><filename>src/contrib/tcl</filename> 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 <filename>mac</filename>, <filename>win</filename> and
|
||||
<filename>compat</filename> subdirectories were eliminated before
|
||||
the import</para>
|
||||
|
||||
<para><filename>src/lib/libtcl</filename> contains only a "bmake style"
|
||||
<filename>Makefile</filename> that uses the standard
|
||||
<filename>bsd.lib.mk</filename> makefile rules to produce the
|
||||
library and install the documentation.</para>
|
||||
|
||||
<para><filename>src/usr.bin/tclsh</filename> contains only a bmake style
|
||||
<filename>Makefile</filename> which will produce and install the
|
||||
<command>tclsh</command> program and its associated man-pages using the standard
|
||||
<filename>bsd.prog.mk</filename> rules.</para>
|
||||
|
||||
<para><filename>src/tools/tools/tcl_bmake</filename> 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.</para>
|
||||
|
||||
<para>The important thing here is that the
|
||||
<filename>src/contrib/tcl</filename> directory is created according
|
||||
to the rules: It is supposed to contain the sources as distributed
|
||||
(on a proper CVS vendor-branch) with as few FreeBSD-specific changes
|
||||
as possible. The 'easy-import' tool on freefall will assist in
|
||||
doing the import, but if there are any doubts on how to go about it,
|
||||
it is imperative that you ask first and not blunder ahead and hope
|
||||
it “works out”. CVS is not forgiving of import accidents and a fair
|
||||
amount of effort is required to back out major mistakes.</para>
|
||||
|
||||
<para>Because of some unfortunate design limitations with CVS's vendor
|
||||
branches, it is required that “official” patches from the vendor be
|
||||
applied to the original distributed sources and the result
|
||||
re-imported onto the vendor branch again. Official patches should
|
||||
never be patched into the FreeBSD checked out version and
|
||||
"committed", as this destroys the vendor branch coherency and makes
|
||||
importing future versions rather difficult as there will be
|
||||
conflicts.</para>
|
||||
|
||||
<para>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 <emphasis>not</emphasis> be
|
||||
removed.</para>
|
||||
|
||||
<para>If it seems easier, the <command>bmake</command> <filename>Makefile</filename>s
|
||||
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 <filename>src/tools</filename> directory along
|
||||
with the port itself so that it is available to future
|
||||
maintainers.</para>
|
||||
|
||||
<para>In the <filename>src/contrib/tcl</filename> level directory, a
|
||||
file called <filename>FREEBSD-upgrade</filename> should be added and
|
||||
it should states things like:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Which files have been left out</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Where the original distribution was obtained from and/or
|
||||
the official master site.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Where to send patches back to the original authors</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Perhaps an overview of the FreeBSD-specific changes that
|
||||
have been made.</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>However, please do not import
|
||||
<filename>FREEBSD-upgrade</filename> with the contributed source.
|
||||
Rather you should <command>cvs add FREEBSD-upgrade ; cvs ci</command> after the
|
||||
initial import. Example wording from
|
||||
<filename>src/contrib/cpio</filename> is below:</para>
|
||||
|
||||
<programlisting>
|
||||
This directory contains virgin sources of the original distribution files
|
||||
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
|
||||
the files in this directory via patches and a cvs commit. New versions or
|
||||
official-patch versions must be imported. Please remember to import with
|
||||
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
|
||||
|
||||
For the import of GNU cpio 2.4.2, the following files were removed:
|
||||
|
||||
INSTALL cpio.info mkdir.c
|
||||
Makefile.in cpio.texi mkinstalldirs
|
||||
|
||||
To upgrade to a newer version of cpio, when it is available:
|
||||
1. Unpack the new version into an empty directory.
|
||||
[Do not make ANY changes to the files.]
|
||||
|
||||
2. Remove the files listed above and any others that don't apply to
|
||||
FreeBSD.
|
||||
|
||||
3. Use the command:
|
||||
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
|
||||
src/contrib/cpio GNU cpio_<version>
|
||||
|
||||
For example, to do the import of version 2.4.2, I typed:
|
||||
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
|
||||
src/contrib/cpio GNU cpio_2_4_2
|
||||
|
||||
4. Follow the instructions printed out in step 3 to resolve any
|
||||
conflicts between local FreeBSD changes and the newer version.
|
||||
|
||||
Do not, under any circumstances, deviate from this procedure.
|
||||
|
||||
To make local changes to cpio, simply patch and commit to the main
|
||||
branch (aka HEAD). Never make local changes on the GNU branch.
|
||||
|
||||
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
|
||||
inclusion in the next vendor release.
|
||||
|
||||
obrien@freebsd.org - 30 March 1997</programlisting>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="policies-shlib">
|
||||
<title>Shared Libraries</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.asami;, &a.peter;, and
|
||||
&a.obrien;.<!-- <br> --> 9 December 1996.</emphasis></para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The three principles of shared library building are:</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>Start from <literal>1.0</literal></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If there is a change that is backwards compatible, bump
|
||||
minor number</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If there is an incompatible change, bump major
|
||||
number</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para>For instance, added functions and bugfixes result in the minor
|
||||
version number being bumped, while deleted functions, changed
|
||||
function call syntax etc. will force the major version number to
|
||||
change.</para>
|
||||
|
||||
<para>Stick to version numbers of the form major.minor (<replaceable>x</replaceable>.<replaceable>y</replaceable>). Our
|
||||
dynamic linker does not handle version numbers of the form <replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
|
||||
well. Any version number after the <replaceable>y</replaceable> (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, <command>ld.so</command> will link with the higher one.
|
||||
Ie: if you link with <filename>libfoo.so.3.3.3</filename>, the
|
||||
linker only records <literal>3.3</literal> in the headers, and will link with anything
|
||||
starting with <replaceable>libfoo.so.3</replaceable>.<replaceable>(anything >=
|
||||
3)</replaceable>.<replaceable>(highest available)</replaceable>.</para>
|
||||
|
||||
<note>
|
||||
<para><command>ld.so</command> will always use the highest
|
||||
“minor” revision. Ie: it will use <filename>libc.so.2.2</filename>
|
||||
in preference to <filename>libc.so.2.0</filename>, even if the
|
||||
program was initially linked with
|
||||
<filename>libc.so.2.0</filename>.</para>
|
||||
</note>
|
||||
|
||||
<para>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 <filename>Makefile</filename>'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 <filename>Makefile</filename> to be updated,
|
||||
and any subsequent changes will not.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
2568
en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml
Normal file
2568
en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
4938
en_US.ISO_8859-1/books/handbook/printing/chapter.sgml
Normal file
4938
en_US.ISO_8859-1/books/handbook/printing/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
234
en_US.ISO_8859-1/books/handbook/quotas/chapter.sgml
Normal file
234
en_US.ISO_8859-1/books/handbook/quotas/chapter.sgml
Normal file
|
|
@ -0,0 +1,234 @@
|
|||
<chapter id="quotas">
|
||||
<title>Disk Quotas</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.mpp;.<!-- <br> -->26 February
|
||||
1996</emphasis></para>
|
||||
|
||||
<para>Quotas are an optional feature of the operating system that allow
|
||||
you to limit the amount of disk space and/or the number of files a
|
||||
user, or members of a group, may allocate on a per-file system basis.
|
||||
This is used most often on timesharing systems where it is desirable
|
||||
to limit the amount of resources any one user or group of users may
|
||||
allocate. This will prevent one user from consuming all of the
|
||||
available disk space.</para>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Configuring Your System to Enable Disk Quotas</title>
|
||||
|
||||
<para>Before attempting to use disk quotas it is necessary to make
|
||||
sure that quotas are configured in your kernel. This is done by
|
||||
adding the following line to your kernel configuration file:</para>
|
||||
|
||||
<programlisting>
|
||||
options QUOTA</programlisting>
|
||||
|
||||
<para>The
|
||||
stock <filename>GENERIC</filename> 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
|
||||
<xref linkend="kernelconfig" remap="Configuring the FreeBSD Kernel">
|
||||
section for more information on kernel configuration.</para>
|
||||
|
||||
<para>Next you will need to enable disk quotas in
|
||||
<filename>/etc/sysconfig</filename>. This is done by changing the
|
||||
line:
|
||||
|
||||
<programlisting>
|
||||
quotas=NO</programlisting>
|
||||
|
||||
to:
|
||||
|
||||
<programlisting>
|
||||
quotas=YES</programlisting></para>
|
||||
|
||||
<para>If you are running FreeBSD 2.2.2 or later, the configuration
|
||||
file will be <filename>/etc/rc.conf</filename> instead and the
|
||||
variable name changed to:</para>
|
||||
|
||||
<programlisting>
|
||||
check_quotas=YES</programlisting>
|
||||
|
||||
<para>Finally you will need to edit <filename>/etc/fstab</filename> 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.</para>
|
||||
|
||||
<para>To enable per-user quotas on a file system, add the <literal>userquota</literal> option to the options field in the
|
||||
<filename>/etc/fstab</filename> entry for the file system you want
|
||||
to to enable quotas on. For example:</para>
|
||||
|
||||
<programlisting>
|
||||
/dev/sd1s2g /home ufs rw,userquota 1 2</programlisting>
|
||||
|
||||
<para>Similarly, to enable group quotas, use the
|
||||
<literal>groupquota</literal> option instead of the <literal>userquota</literal> keyword. To enable both user and
|
||||
group quotas, change the entry as follows:</para>
|
||||
|
||||
<programlisting>
|
||||
/dev/sd1s2g /home ufs rw,userquota,groupquota 1 2</programlisting>
|
||||
|
||||
<para>By default the quota files are stored in the root directory of
|
||||
the file system with the names <filename>quota.user</filename> and
|
||||
<filename>quota.group</filename> for user and group quotas
|
||||
respectively. See <command>man fstab</command> 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.</para>
|
||||
|
||||
<para>At this point you should reboot your system with your new
|
||||
kernel. <filename>/etc/rc</filename> will automatically run the
|
||||
appropriate commands to create the initial quota files for all of
|
||||
the quotas you enabled in <filename>/etc/fstab</filename>, so there
|
||||
is no need to manually create any zero length quota files.</para>
|
||||
|
||||
<para>In the normal course of operations you should not be required to
|
||||
run the <command>quotacheck</command>, <command>quotaon</command>, or <command>quotaoff</command> commands manually. However, you may
|
||||
want to read their man pages just to be familiar with their
|
||||
operation.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Setting Quota Limits</title>
|
||||
|
||||
<para>Once you have configured your system to enable quotas, verify
|
||||
that they really are enabled. An easy way to do this is to run</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>quota -v</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You should see a one line summary of
|
||||
disk usage and current quota limits for each file system that quotas
|
||||
are enabled on.</para>
|
||||
|
||||
<para>You are now ready to start assigning quota limits with the
|
||||
<command>edquota</command> command.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>The following is an example of what you might see when you run
|
||||
then <command>edquota</command> command. When the
|
||||
<command>edquota</command> command is invoked, you are
|
||||
placed into the editor specified by the <envar>EDITOR</envar>
|
||||
environment variable, or in the <command>vi</command>
|
||||
editor if the <envar>EDITOR</envar> variable is not set, to
|
||||
allow you to edit the quota limits.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>edquota -u test</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<programlisting>
|
||||
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)</programlisting>
|
||||
|
||||
<para>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:
|
||||
|
||||
<programlisting>
|
||||
/usr: blocks in use: 65, limits (soft = 50, hard = 75)</programlisting> to:
|
||||
|
||||
<programlisting>
|
||||
/usr: blocks in use: 65, limits (soft = 500, hard = 600)</programlisting></para>
|
||||
|
||||
<para>The new
|
||||
quota limits will be in place when you exit the editor.</para>
|
||||
|
||||
<para>Sometimes it is desirable to set quota limits on a range of
|
||||
uids. This can be done by use of the <option>-p</option> option on
|
||||
the <command>edquota</command> command. First, assign
|
||||
the desired quota limit to a user, and then run <command>edquota -p
|
||||
protouser startuid-enduid</command>. For example, if user
|
||||
<username>test</username> has the desired quota limits, the
|
||||
following command can be used to duplicate those quota limits for
|
||||
uids 10,000 through 19,999:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>edquota -p test 10000-19999</userinput></screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The 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.</para>
|
||||
|
||||
<para>See <command>man edquota</command> for more detailed
|
||||
information.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Checking Quota Limits and Disk Usage</title>
|
||||
|
||||
<para>You can use either the <command>quota</command> or
|
||||
the <command>repquota</command> commands to check quota
|
||||
limits and disk usage. The <command>quota</command>
|
||||
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
|
||||
<command>repquota</command> command can be used to get a
|
||||
summary of all quotas and disk usage for file systems with quotas
|
||||
enabled.</para>
|
||||
|
||||
<para>The following is some sample output from the <command>quota
|
||||
-v</command> command for a user that has quota limits on two file
|
||||
systems.</para>
|
||||
|
||||
|
||||
<programlisting>
|
||||
Disk quotas for user test (uid 1002):
|
||||
Filesystem blocks quota limit grace files quota limit grace
|
||||
/usr 65* 50 75 5days 7 50 60
|
||||
/usr/var 0 50 75 0 50 60</programlisting>
|
||||
|
||||
<para>On the <filename>/usr</filename> 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 <literal>*</literal> which
|
||||
indicates that the user is currently over their quota limit.</para>
|
||||
|
||||
<para>Normally file systems that the user is not using any disk space
|
||||
on will not show up in the output from the <command>quota</command> command, even if they have a quota limit
|
||||
assigned for that file system. The <option>-v</option> option will
|
||||
display those file systems, such as the
|
||||
<filename>/usr/var</filename> file system in the above
|
||||
example.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>* Quotas over NFS</title>
|
||||
|
||||
<para>This section is still under development.</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
1698
en_US.ISO_8859-1/books/handbook/security/chapter.sgml
Normal file
1698
en_US.ISO_8859-1/books/handbook/security/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
2088
en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml
Normal file
2088
en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml
Normal file
File diff suppressed because it is too large
Load diff
683
en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
Normal file
683
en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
Normal file
|
|
@ -0,0 +1,683 @@
|
|||
<chapter id="staff">
|
||||
<title>FreeBSD Project Staff</title>
|
||||
|
||||
<para>The FreeBSD Project is managed and operated by the following
|
||||
groups of people:</para>
|
||||
|
||||
|
||||
<sect1 id="staff-core">
|
||||
<title>The FreeBSD Core Team</title>
|
||||
|
||||
<para>The FreeBSD core team constitutes the project's “Board of
|
||||
Directors”, responsible for deciding the project's overall goals
|
||||
and direction as well as managing <xref linkend="staff-who"
|
||||
remap="specific
|
||||
areas"> of the FreeBSD project landscape.</para>
|
||||
|
||||
<para>(in alphabetical order by last name):</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>&a.asami;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ache;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dyson;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.bde;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gibbs;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.davidg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.phk;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rich;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gpalmer;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jdp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.guido;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.sos;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.peter;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wollman;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.joerg;</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-committers">
|
||||
<title>The FreeBSD Developers</title>
|
||||
|
||||
<para>These are the people who have commit privileges and do the
|
||||
engineering work on the FreeBSD source tree. All core team members
|
||||
and most FreeBSD Documentation project personnel are also
|
||||
developers.</para>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mbarkah;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.stb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.torstenb;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.danny;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.charnier;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.kjc;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gclarkii;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cracauer;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.adam;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dufault;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.uhclem;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tegge;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.eivind;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.julian;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rse;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.se;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.sef;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.fenner;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfitz;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.lars;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.scrappy;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.brandon;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.graichen;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jgreco;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rgrimes;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmg;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hanai;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ahasty;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jhay;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.helbig;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.erich;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hsu;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.itojun;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ugen;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.gj;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ljo;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.kato;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.andreas;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.imp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.smace;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mckay;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jlemon;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.tedm;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.amurai;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.markm;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.max;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.alex;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.davidn;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.obrien;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.fsmp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.smpatel;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wpaul;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmacd;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.steve;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mpp;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dfr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jraynard;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.darrenr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.csgr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.martin;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.paul;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.roberto;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.chuckr;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dima;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wosch;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ats;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jseger;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.vanilla;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.msmith;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.brian;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.stark;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.karl;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cwt;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.pst;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hoek;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.swallace;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nate;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.yokota;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmz;</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&a.hosokawa;</para>
|
||||
</listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-doc">
|
||||
<title>The FreeBSD Documentation Project</title>
|
||||
|
||||
<para>The <ulink URL="http://www.freebsd.org/docproj.html">FreeBSD
|
||||
Documentation Project</ulink> is responsible for a number of
|
||||
different services, each service being run by an individual and his
|
||||
<emphasis>deputies</emphasis> (if any):</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>Documentation Project Manager</term>
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Webmaster</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mbarkah;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.paul;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Handbook & FAQ Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.faq;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Build Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.paul;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.dave;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Mirror Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ulf;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.john;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>News Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.john;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Gallery and Commercial Editor</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.cawimm;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Style Police & Art Director</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.dave;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.opsys;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Database Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.mayo;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.cracauer;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>CGI Engineer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.cracauer;</para>
|
||||
|
||||
<para><emphasis>Deputy:</emphasis> &a.stb;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Bottle Washing</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.nsj;</para>
|
||||
|
||||
<para><emphasis>Drying plates:</emphasis> &a.nik;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="staff-who">
|
||||
<title>Who Is Responsible for What</title>
|
||||
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term>Principal Architect</term>
|
||||
<listitem>
|
||||
<para>&a.davidg;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Documentation Project Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jfieber;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Internationalization</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.ache;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Networking</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.wollman;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Postmaster</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jmb;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Release Coordinator</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Public Relations & Corporate
|
||||
Liaison</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.jkh;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Security Officer</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.guido;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Source Repository Managers</term>
|
||||
|
||||
<listitem>
|
||||
<para>Principal: &a.peter;</para>
|
||||
|
||||
<para>Assistant: &a.jdp;</para>
|
||||
|
||||
<para>International (Crypto): &a.markm;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Ports Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.asami;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>XFree86 Project, Inc. Liaison</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.rich;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>Usenet Support</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.joerg;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term>GNATS Administrator</term>
|
||||
|
||||
<listitem>
|
||||
<para>&a.steve;</para>
|
||||
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
8
en_US.ISO_8859-1/books/handbook/x11/chapter.sgml
Normal file
8
en_US.ISO_8859-1/books/handbook/x11/chapter.sgml
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
<chapter id="x11">
|
||||
<title>The X Window System</title>
|
||||
|
||||
<para>Pending the completion of this section, please refer to
|
||||
documentation supplied by the <ulink URL="http://www.xfree86.org/">The
|
||||
XFree86 Project, Inc</ulink>.</para>
|
||||
|
||||
</chapter>
|
||||
Loading…
Reference in a new issue