diff options
| author | Doc Manager <doceng@FreeBSD.org> | 2004-11-04 17:43:22 +0000 |
|---|---|---|
| committer | Doc Manager <doceng@FreeBSD.org> | 2004-11-04 17:43:22 +0000 |
| commit | 901c7b1529a30ff8836f7195d488ed44d45016a0 (patch) | |
| tree | f75ef784e2a5b650dfa51ce0748bfc2a7b9693ee | |
| parent | b23cb0c49c1fde5d324d34baf07ef9b32ecc3aa1 (diff) | |
| download | doc-release/5.3.0.tar.gz doc-release/5.3.0.zip | |
Create tag '5.3.0'.release/5.3.0
124 files changed, 10645 insertions, 14306 deletions
@@ -15,7 +15,6 @@ SUBDIR+= es_ES.ISO8859-1 SUBDIR+= fr_FR.ISO8859-1 SUBDIR+= it_IT.ISO8859-15 SUBDIR+= ja_JP.eucJP -SUBDIR+= nl_NL.ISO8859-1 SUBDIR+= pl_PL.ISO8859-2 SUBDIR+= pt_BR.ISO8859-1 SUBDIR+= ru_RU.KOI8-R diff --git a/en/handbook/contrib/chapter.sgml b/en/handbook/contrib/chapter.sgml deleted file mode 100644 index 9a41073467..0000000000 --- a/en/handbook/contrib/chapter.sgml +++ /dev/null @@ -1,5796 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $Id: chapter.sgml,v 1.92 2000-03-19 06:20:31 vanilla Exp $ ---> - -<chapter id="contrib"> - <title>Contributing to FreeBSD</title> - - <para><emphasis>Contributed by &a.jkh;.</emphasis></para> - - <para>So you want to contribute something to FreeBSD? That is great! We can - always use the help, and FreeBSD is one of those systems that - <emphasis>relies</emphasis> on the contributions of its user base in order - to survive. Your contributions are not only appreciated, they are vital - to FreeBSD's continued growth!</para> - - <para>Contrary to what some people might also have you believe, you do not - need to be a hot-shot programmer or a close personal friend of the FreeBSD - core team in order to have your contributions accepted. The FreeBSD - Project's development is done by a large and growing number of - international contributors whose ages and areas of technical expertise - vary greatly, and there is always more work to be done than there are - people available to do it.</para> - - <para>Since the FreeBSD project is responsible for an entire operating - system environment (and its installation) rather than just a kernel or a - few scattered utilities, our <filename>TODO</filename> list also spans a - very wide range of tasks, from documentation, beta testing and - presentation to highly specialized types of kernel development. No matter - what your skill level, there is almost certainly something you can do to - help the project!</para> - - <para>Commercial entities engaged in FreeBSD-related enterprises are also - encouraged to contact us. Need a special extension to make your product - work? You will find us receptive to your requests, given that they are not - too outlandish. Working on a value-added product? Please let us know! We - may be able to work cooperatively on some aspect of it. The free software - world is challenging a lot of existing assumptions about how software is - developed, sold, and maintained throughout its life cycle, and we urge you - to at least give it a second look.</para> - - <sect1> - <title>What Is Needed</title> - - <para>The following list of tasks and sub-projects represents something of - an amalgam of the various core team <filename>TODO</filename> lists and - user requests we have collected over the last couple of months. Where - possible, tasks have been ranked by degree of urgency. If you are - interested in working on one of the tasks you see here, send mail to the - coordinator listed by clicking on their names. If no coordinator has - been appointed, maybe you would like to volunteer?</para> - - <sect2> - <title>High priority tasks</title> - - <para>The following tasks are considered to be urgent, usually because - they represent something that is badly broken or sorely needed:</para> - - <orderedlist> - <listitem> - <para>3-stage boot issues. Overall coordination: &a.hackers;</para> - - <itemizedlist> - <listitem> - <para>Do WinNT compatible drive tagging so that the 3rd stage - can provide an accurate mapping of BIOS geometries for - disks.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>Filesystem problems. Overall coordination: &a.fs;</para> - - <itemizedlist> - <listitem> - <para>Fix the MSDOS file system.</para> - </listitem> - - <listitem> - <para>Clean up and document the nullfs filesystem code. - Coordinator: &a.eivind;</para> - </listitem> - - <listitem> - <para>Fix the union file system. Coordinator: &a.dg;</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>Implement Int13 vm86 disk driver. Coordinator: - &a.hackers;</para> - </listitem> - - <listitem> - <para>New bus architecture. Coordinator: &a.newbus;</para> - - <itemizedlist> - <listitem> - <para>Port existing ISA drivers to new architecture.</para> - </listitem> - - <listitem> - <para>Move all interrupt-management code to appropriate parts of - the bus drivers.</para> - </listitem> - - <listitem> - <para>Port PCI subsystem to new architecture. Coordinator: - &a.dfr;</para> - </listitem> - - <listitem> - <para>Figure out the right way to handle removable devices and - then use that as a substrate on which PC-Card and CardBus - support can be implemented.</para> - </listitem> - - <listitem> - <para>Resolve the probe/attach priority issue once and for - all.</para> - </listitem> - - <listitem> - <para>Move any remaining buses over to the new - architecture.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>Kernel issues. Overall coordination: &a.hackers;</para> - </listitem> - - <listitem> - <para>Add more pro-active security infrastructure. Overall - coordination: &a.security;</para> - - <itemizedlist> - <listitem> - <para>Build something like Tripwire(TM) into the kernel, with a - remote and local part. There are a number of cryptographic - issues to getting this right; contact the coordinator for - details. Coordinator: &a.eivind;</para> - </listitem> - - <listitem> - <para>Make the entire kernel use <literal>suser()</literal> - instead of comparing to 0. It is presently using about half - of each. Coordinator: &a.eivind;</para> - </listitem> - - <listitem> - <para>Split securelevels into different parts, to allow an - administrator to throw away those privileges he can throw - away. Setting the overall securelevel needs to have the same - effect as now, obviously. Coordinator: &a.eivind;</para> - </listitem> - - <listitem> - <para>Make it possible to upload a list of “allowed - program” to BPF, and then block BPF from accepting other - programs. This would allow BPF to be used e.g. for DHCP, - without allowing an attacker to start snooping the local - network.</para> - </listitem> - - <listitem> - <para>Update the security checker script. We should at least - grab all the checks from the other BSD derivatives, and add - checks that a system with securelevel increased also have - reasonable flags on the relevant parts. Coordinator: - &a.eivind;</para> - </listitem> - - <listitem> - <para>Add authorization infrastructure to the kernel, to allow - different authorization policies. Part of this could be done - by modifying <literal>suser()</literal>. Coordinator: - &a.eivind;</para> - </listitem> - - <listitem> - <para>Add code to the NFS layer so that you cannot - <literal>chdir("..")</literal> out of an NFS partition. E.g., - <filename>/usr</filename> is a UFS partition with - <filename>/usr/src</filename> NFS exported. Now it is - possible to use the NFS filehandle for - <filename>/usr/src</filename> to get access to - <filename>/usr</filename>.</para> - </listitem> - </itemizedlist> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>Medium priority tasks</title> - - <para>The following tasks need to be done, but not with any particular - urgency:</para> - - <orderedlist> - <listitem> - <para>Full KLD based driver support/Configuration Manager.</para> - - <itemizedlist> - <listitem> - <para>Write a configuration manager (in the 3rd stage boot?) - that probes your hardware in a sane manner, keeps only the - KLDs required for your hardware, etc.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.phk;</para> - - <itemizedlist> - <listitem> - <para>Documentation!</para> - </listitem> - - <listitem> - <para>Reliable operation of the pcic driver (needs - testing).</para> - </listitem> - - <listitem> - <para>Recognizer and handler for <filename>sio.c</filename> - (mostly done).</para> - </listitem> - - <listitem> - <para>Recognizer and handler for <filename>ed.c</filename> - (mostly done).</para> - </listitem> - - <listitem> - <para>Recognizer and handler for <filename>ep.c</filename> - (mostly done).</para> - </listitem> - - <listitem> - <para>User-mode recognizer and handler (partially done).</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para>Advanced Power Management. Coordinators: &a.msmith; and - &a.phk;</para> - - <itemizedlist> - <listitem> - <para>APM sub-driver (mostly done).</para> - </listitem> - - <listitem> - <para>IDE/ATA disk sub-driver (partially done).</para> - </listitem> - - <listitem> - <para>syscons/pcvt sub-driver.</para> - </listitem> - - <listitem> - <para>Integration with the PCMCIA/PCCARD drivers - (suspend/resume).</para> - </listitem> - </itemizedlist> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>Low priority tasks</title> - - <para>The following tasks are purely cosmetic or represent such an - investment of work that it is not likely that anyone will get them - done anytime soon:</para> - - <para>The first N items are from Terry Lambert - <email>terry@lambert.org</email></para> - - <orderedlist> - <listitem> - <para>NetWare Server (protected mode ODI driver) loader and - subservices to allow the use of ODI card drivers supplied with - network cards. The same thing for NDIS drivers and NetWare SCSI - drivers.</para> - </listitem> - - <listitem> - <para>An "upgrade system" option that works on Linux boxes instead - of just previous rev FreeBSD boxes.</para> - </listitem> - - <listitem> - <para>Symmetric Multiprocessing with kernel preemption (requires - kernel preemption).</para> - </listitem> - - <listitem> - <para>A concerted effort at support for portable computers. This is - somewhat handled by changing PCMCIA bridging rules and power - management event handling. But there are things like detecting - internal vs. external display and picking a different screen - resolution based on that fact, not spinning down the disk if the - machine is in dock, and allowing dock-based cards to disappear - without affecting the machines ability to boot (same issue for - PCMCIA).</para> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>Smaller tasks</title> - - <para>Most of the tasks listed in the previous sections require either a - considerable investment of time or an in-depth knowledge of the - FreeBSD kernel (or both). However, there are also many useful tasks - which are suitable for "weekend hackers", or people without - programming skills.</para> - - <orderedlist> - <listitem> - <para>If you run FreeBSD-current and have a good Internet - connection, there is a machine <hostid - role="fqdn">current.FreeBSD.org</hostid> which builds a full - release once a day — every now and again, try and install - the latest release from it and report any failures in the - process.</para> - </listitem> - - <listitem> - <para>Read the freebsd-bugs mailing list. There might be a - problem you can comment constructively on or with patches you - can test. Or you could even try to fix one of the problems - yourself.</para> - </listitem> - - <listitem> - <para>Read through the FAQ and Handbook periodically. If anything - is badly explained, out of date or even just completely wrong, let - us know. Even better, send us a fix (SGML is not difficult to - learn, but there is no objection to ASCII submissions).</para> - </listitem> - - <listitem> - <para>Help translate FreeBSD documentation into your native language - (if not already available) — just send an email to &a.doc; - asking if anyone is working on it. Note that you are not - committing yourself to translating every single FreeBSD document - by doing this — in fact, the documentation most in need of - translation is the installation instructions.</para> - </listitem> - - <listitem> - <para>Read the freebsd-questions mailing list and &ng.misc - occasionally (or even regularly). It can be very satisfying to - share your expertise and help people solve their problems; - sometimes you may even learn something new yourself! These forums - can also be a source of ideas for things to work on.</para> - </listitem> - - <listitem> - <para>If you know of any bugfixes which have been successfully - applied to -current but have not been merged into -stable after a - decent interval (normally a couple of weeks), send the committer a - polite reminder.</para> - </listitem> - - <listitem> - <para>Move contributed software to <filename>src/contrib</filename> - in the source tree.</para> - </listitem> - - <listitem> - <para>Make sure code in <filename>src/contrib</filename> is up to - date.</para> - </listitem> - - <listitem> - <para>Look for year 2000 bugs (and fix any you find!)</para> - </listitem> - - <listitem> - <para>Build the source tree (or just part of it) with extra warnings - enabled and clean up the warnings.</para> - </listitem> - - <listitem> - <para>Fix warnings for ports which do deprecated things like using - gets() or including malloc.h.</para> - </listitem> - - <listitem> - <para>If you have contributed any ports, send your patches back to - the original author (this will make your life easier when they - bring out the next version)</para> - </listitem> - - <listitem> - <para>Suggest further tasks for this list!</para> - </listitem> - </orderedlist> - </sect2> - - <sect2> - <title>Work through the PR database</title> - - <para>The <ulink - url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi">FreeBSD PR - list</ulink> shows all the current active problem reports and - requests for enhancement that have been submitted by FreeBSD users. - Look through the open PRs, and see if anything there takes your - interest. Some of these might be very simple tasks, that just need an - extra pair of eyes to look over them and confirm that the fix in the - PR is a good one. Others might be much more complex.</para> - - <para>Start with the PRs that have not been assigned to anyone else, but - if one them is assigned to someone else, but it looks like something - you can handle, e-mail the person it is assigned to and ask if you can - work on it—they might already have a patch ready to be tested, - or further ideas that you can discuss with them.</para> - </sect2> - </sect1> - - <sect1> - <title>How to Contribute</title> - - <para>Contributions to the system generally fall into one or more of the - following 6 categories:</para> - - <sect2 id="contrib-general"> - <title>Bug reports and general commentary</title> - - <para>An idea or suggestion of <emphasis>general</emphasis> technical - interest should be mailed to the &a.hackers;. Likewise, people with - an interest in such things (and a tolerance for a - <emphasis>high</emphasis> volume of mail!) may subscribe to the - hackers mailing list by sending mail to &a.majordomo;. See <link - linkend="eresources-mail">mailing lists</link> for more information - about this and other mailing lists.</para> - - <para>If you find a bug or are submitting a specific change, please - report it using the &man.send-pr.1; program or its <ulink - URL="http://www.FreeBSD.org/send-pr.html">WEB-based - equivalent</ulink>. Try to fill-in each field of the bug report. - Unless they exceed 65KB, include any patches directly in the report. - When including patches, <emphasis>do not</emphasis> use cut-and-paste - because cut-and-paste turns tabs into spaces and makes them unusable. - Consider compressing patches and using &man.uuencode.1; if they exceed - 20KB. Upload very large submissions to <ulink - url="ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/">ftp.FreeBSD.org:/pub/FreeBSD/incoming/</ulink>.</para> - - <para>After filing a report, you should receive confirmation along with - a tracking number. Keep this tracking number so that you can update - us with details about the problem by sending mail to - <email>bug-followup@FreeBSD.org</email>. Use the number as the - message subject, e.g. <literal>"Re: kern/3377"</literal>. Additional - information for any bug report should be submitted this way.</para> - - <para>If you do not receive confirmation in a timely fashion (3 days to - a week, depending on your email connection) or are, for some reason, - unable to use the &man.send-pr.1; command, then you may ask - someone to file it for you by sending mail to the &a.bugs;.</para> - </sect2> - - <sect2> - <title>Changes to the documentation</title> - - <para>Changes to the documentation are overseen by the &a.doc;. Send - submissions and changes (even small ones are welcome!) using - <command>send-pr</command> as described in <link - linkend="contrib-general">Bug Reports and General - Commentary</link>.</para> - </sect2> - - <sect2> - <title>Changes to existing source code</title> - - <para>An addition or change to the existing source code is a somewhat - trickier affair and depends a lot on how far out of date you are with - the current state of the core FreeBSD development. There is a special - on-going release of FreeBSD known as “FreeBSD-current” - which is made available in a variety of ways for the convenience of - developers working actively on the system. See <link - linkend="current">Staying current with FreeBSD</link> for more - information about getting and using FreeBSD-current.</para> - - <para>Working from older sources unfortunately means that your changes - may sometimes be too obsolete or too divergent for easy re-integration - into FreeBSD. Chances of this can be minimized somewhat by - subscribing to the &a.announce; and the &a.current; lists, where - discussions on the current state of the system take place.</para> - - <para>Assuming that you can manage to secure fairly up-to-date sources - to base your changes on, the next step is to produce a set of diffs to - send to the FreeBSD maintainers. This is done with the &man.diff.1; - command, with the “context diff” form - being preferred. For example:</para> - - <para> - <screen>&prompt.user; <userinput>diff -c oldfile newfile</userinput></screen> - - or - - <screen>&prompt.user; <userinput>diff -c -r olddir newdir</userinput></screen> - - would generate such a set of context diffs for the given source file - or directory hierarchy. See the man page for &man.diff.1; for more - details.</para> - - <para>Once you have a set of diffs (which you may test with the - &man.patch.1; command), you should submit them for inclusion with - FreeBSD. Use the &man.send-pr.1; program as described in <link - linkend="contrib-general">Bug Reports and General Commentary</link>. - <emphasis>Do not</emphasis> just send the diffs to the &a.hackers; or - they will get lost! We greatly appreciate your submission (this is a - volunteer project!); because we are busy, we may not be able to - address it immediately, but it will remain in the pr database until we - do.</para> - - <para>If you feel it appropriate (e.g. you have added, deleted, or - renamed files), bundle your changes into a <command>tar</command> file - and run the &man.uuencode.1; program on it. Shar archives are also - welcome.</para> - - <para>If your change is of a potentially sensitive nature, e.g. you are - unsure of copyright issues governing its further distribution or you - are simply not ready to release it without a tighter review first, - then you should send it to &a.core; directly rather than submitting it - with &man.send-pr.1;. The core mailing list reaches a much smaller - group of people who do much of the day-to-day work on FreeBSD. Note - that this group is also <emphasis>very busy</emphasis> and so you - should only send mail to them where it is truly necessary.</para> - - <para>Please refer to <command>man 9 intro</command> and <command>man 9 - style</command> for some information on coding style. We would - appreciate it if you were at least aware of this information before - submitting code.</para> - </sect2> - - <sect2> - <title>New code or major value-added packages</title> - - <para>In the rare case of a significant contribution of a large body - work, or the addition of an important new feature to FreeBSD, it - becomes almost always necessary to either send changes as uuencode'd - tar files or upload them to our ftp site <ulink - URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming">ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming</ulink>.</para> - - <para>When working with large amounts of code, the touchy subject of - copyrights also invariably comes up. Acceptable copyrights for code - included in FreeBSD are:</para> - - <orderedlist> - <listitem> - <para>The BSD copyright. This copyright is most preferred due to - its “no strings attached” nature and general - attractiveness to commercial enterprises. Far from discouraging - such commercial use, the FreeBSD Project actively encourages such - participation by commercial interests who might eventually be - inclined to invest something of their own into FreeBSD.</para> - </listitem> - - <listitem> - <para>The GNU Public License, or “GPL”. This license is - not quite as popular with us due to the amount of extra effort - demanded of anyone using the code for commercial purposes, but - given the sheer quantity of GPL'd code we currently require - (compiler, assembler, text formatter, etc) it would be silly to - refuse additional contributions under this license. Code under - the GPL also goes into a different part of the tree, that being - <filename>/sys/gnu</filename> or - <filename>/usr/src/gnu</filename>, and is therefore easily - identifiable to anyone for whom the GPL presents a problem.</para> - </listitem> - </orderedlist> - - <para>Contributions coming under any other type of copyright must be - carefully reviewed before their inclusion into FreeBSD will be - considered. Contributions for which particularly restrictive - commercial copyrights apply are generally rejected, though the authors - are always encouraged to make such changes available through their own - channels.</para> - - <para>To place a “BSD-style” copyright on your work, include - the following text at the very beginning of every source code file you - wish to protect, replacing the text between the <literal>%%</literal> - with the appropriate information.</para> - - <programlisting> -Copyright (c) %%proper_years_here%% - %%your_name_here%%, %%your_state%% %%your_zip%%. - All rights reserved. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions -are met: -1. Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer as - the first lines of this file unmodified. -2. Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - -THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR -IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES -OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. -IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, -INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT -NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF -THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - $Id$</programlisting> - - <para>For your convenience, a copy of this text can be found in - <filename>/usr/share/examples/etc/bsd-style-copyright</filename>.</para> - </sect2> - - <sect2> - <title>Money, Hardware or Internet access</title> - - <para>We are always very happy to accept donations to further the cause - of the FreeBSD Project and, in a volunteer effort like ours, a little - can go a long way! Donations of hardware are also very important to - expanding our list of supported peripherals since we generally lack - the funds to buy such items ourselves.</para> - - <sect3> - <title><anchor id="donations">Donating funds</title> - - <para>While the FreeBSD Project is not a 501(c)(3) (charitable) - corporation and hence cannot offer special tax incentives for any - donations made, any such donations will be gratefully accepted on - behalf of the project by FreeBSD, Inc.</para> - - <para>FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; - with the goal of furthering the aims of the FreeBSD Project and - giving it a minimal corporate presence. Any and all funds donated - (as well as any profits that may eventually be realized by FreeBSD, - Inc.) will be used exclusively to further the project's - goals.</para> - - <para>Please make any checks payable to FreeBSD, Inc., sent in care of - the following address:</para> - - <address> - <otheraddr>FreeBSD, Inc.</otheraddr> - <otheraddr>c/o Jordan Hubbard</otheraddr> - <street>4041 Pike Lane, Suite F</street> - <city>Concord</city> - <state>CA</state>, <postcode>94520</postcode> - </address> - - <para>(currently using the Walnut Creek CDROM address until a PO box - can be opened)</para> - - <para>Wire transfers may also be sent directly to:</para> - - <address> - <otheraddr>Bank Of America</otheraddr> - <otheraddr>Concord Main Office</otheraddr> - <pob>P.O. Box 37176</pob> - <city>San Francisco</city> - <state>CA</state>, <postcode>94137-5176</postcode> - - <otheraddr>Routing #: 121-000-358</otheraddr> - <otheraddr>Account #: 01411-07441 (FreeBSD, Inc.)</otheraddr> - </address> - - <para>Any correspondence related to donations should be sent to &a.jkh, - either via email or to the FreeBSD, Inc. postal address given above. - </para> - - <para>If you do not wish to be listed in our <link - linkend="donors">donors</link> section, please specify this when - making your donation. Thanks!</para> - </sect3> - - <sect3> - <title>Donating hardware</title> - - <para>Donations of hardware in any of the 3 following categories are - also gladly accepted by the FreeBSD Project:</para> - - <itemizedlist> - <listitem> - <para>General purpose hardware such as disk drives, memory or - complete systems should be sent to the FreeBSD, Inc. address - listed in the <emphasis>donating funds</emphasis> - section.</para> - </listitem> - - <listitem> - <para>Hardware for which ongoing compliance testing is desired. - We are currently trying to put together a testing lab of all - components that FreeBSD supports so that proper regression - testing can be done with each new release. We are still lacking - many important pieces (network cards, motherboards, etc) and if - you would like to make such a donation, please contact &a.dg; - for information on which items are still required.</para> - </listitem> - - <listitem> - <para>Hardware currently unsupported by FreeBSD for which you - would like to see such support added. Please contact the - &a.core; before sending such items as we will need to find a - developer willing to take on the task before we can accept - delivery of new hardware.</para> - </listitem> - </itemizedlist> - </sect3> - - <sect3> - <title>Donating Internet access</title> - - <para>We can always use new mirror sites for FTP, WWW or - <command>cvsup</command>. If you would like to be such a mirror, - please contact the FreeBSD project administrators - <email>admin@FreeBSD.org</email> for more information.</para> - </sect3> - </sect2> - </sect1> - - <sect1 id="donors"> - <title>Donors Gallery</title> - - <para>The FreeBSD Project is indebted to the following donors and would - like to publically thank them here!</para> - - <itemizedlist> - <listitem> - <para><emphasis>Contributors to the central server - project:</emphasis></para> - - <para>The following individuals and businesses made it possible for - the FreeBSD Project to build a new central server machine to - eventually replace <hostid role="fqdn">freefall.FreeBSD.org</hostid> - by donating the following items:</para> - - <itemizedlist> - <listitem> - <para>&a.mbarkah and his employer, <ulink URL="http://www.hemi.com"> - Hemisphere Online</ulink>, donated a <emphasis>Pentium Pro - (P6) 200Mhz CPU</emphasis></para> - </listitem> - - <listitem> - <para><ulink URL="http://www.asacomputers.com">ASA - Computers</ulink> donated a <emphasis>Tyan 1662 - motherboard</emphasis>.</para> - </listitem> - - <listitem> - <para>Joe McGuckin <email>joe@via.net</email> of <ulink - URL="http://www.via.net">ViaNet Communications</ulink> donated - a <emphasis>Kingston ethernet controller.</emphasis></para> - </listitem> - - <listitem> - <para>Jack O'Neill <email>jack@diamond.xtalwind.net</email> - donated an <emphasis>NCR 53C875 SCSI controller - card</emphasis>.</para> - </listitem> - - <listitem> - <para>Ulf Zimmermann <email>ulf@Alameda.net</email> of <ulink - URL="http://www.Alameda.net">Alameda Networks</ulink> donated - <emphasis>128MB of memory</emphasis>, a <emphasis>4 Gb disk - drive and the case.</emphasis></para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para><emphasis>Direct funding:</emphasis></para> - - <para>The following individuals and businesses have generously - contributed direct funding to the project:</para> - - <itemizedlist> - <listitem> - <para>Annelise Anderson - <email>ANDRSN@HOOVER.STANFORD.EDU</email></para> - </listitem> - - <listitem> - <para>&a.dillon</para> - </listitem> - - <listitem> - <para><ulink URL="http://www.epilogue.com/">Epilogue Technology - Corporation</ulink></para> - </listitem> - - <listitem> - <para>&a.sef</para> - </listitem> - - <listitem> - <para>Don Scott Wilde</para> - </listitem> - - <listitem> - <para>Gianmarco Giovannelli - <email>gmarco@masternet.it</email></para> - </listitem> - - <listitem> - <para>Josef C. Grosch <email>joeg@truenorth.org</email></para> - </listitem> - - <listitem> - <para>Robert T. Morris</para> - </listitem> - - <listitem> - <para>&a.chuckr</para> - </listitem> - - <listitem> - <para>Kenneth P. Stox <email>ken@stox.sa.enteract.com</email> of - <ulink URL="http://www.imagescape.com">Imaginary Landscape, - LLC.</ulink></para> - </listitem> - - <listitem> - <para>Dmitry S. Kohmanyuk <email>dk@dog.farm.org</email></para> - </listitem> - - <listitem> - <para><ulink URL="http://www.cdrom.co.jp/">Laser5</ulink> of Japan - (a portion of the profits from sales of their various FreeBSD - CD-ROMs.</para> - </listitem> - - <listitem> - <para><ulink URL="http://www.mmjp.or.jp/fuki/">Fuki Shuppan - Publishing Co.</ulink> donated a portion of their profits from - <emphasis>Hajimete no FreeBSD</emphasis> (FreeBSD, Getting - started) to the FreeBSD and XFree86 projects.</para> - </listitem> - - <listitem> - <para><ulink URL="http://www.ascii.co.jp/">ASCII Corp.</ulink> - donated a portion of their profits from several FreeBSD-related - books to the FreeBSD project.</para> - </listitem> - - <listitem> - <para><ulink URL="http://www.yokogawa.co.jp/">Yokogawa Electric - Corp</ulink> has generously donated significant funding to the - FreeBSD project.</para> - </listitem> - - <listitem> - <para><ulink URL="http://www.buffnet.net/">BuffNET</ulink></para> - </listitem> - - <listitem> - <para><ulink url="http://www.pacificsolutions.com/">Pacific - Solutions</ulink></para> - </listitem> - - <listitem> - <para><ulink url="http://www.siemens.de/">Siemens AG</ulink> - via <ulink url="mailto:andre.albsmeier@mchp.siemens.de">Andre - Albsmeier</ulink></para> - </listitem> - - <listitem> - <para><ulink url="mailto:ras@interaccess.com">Chris Silva</ulink> - </para> - </listitem> - - </itemizedlist> - </listitem> - - <listitem> - <para><emphasis>Hardware contributors:</emphasis></para> - - <para>The following individuals and businesses have generously - contributed hardware for testing and device driver - development/support:</para> - - <itemizedlist> - <listitem> - <para>Walnut Creek CDROM for providing the Pentium P5-90 and - 486/DX2-66 EISA/VL systems that are being used for our - development work, to say nothing of the network access and other - donations of hardware resources.</para> - </listitem> - - <listitem> - <para>TRW Financial Systems, Inc. provided 130 PCs, three 68 GB - fileservers, twelve Ethernets, two routers and an ATM switch for - debugging the diskless code.</para> - </listitem> - - <listitem> - <para>Dermot McDonnell donated the Toshiba XM3401B CDROM drive - currently used in freefall.</para> - </listitem> - - <listitem> - <para>&a.chuck; contributed his floppy tape streamer for - experimental work.</para> - </listitem> - - <listitem> - <para>Larry Altneu <email>larry@ALR.COM</email>, and &a.wilko;, - provided Wangtek and Archive QIC-02 tape drives in order to - improve the <devicename>wt</devicename> driver.</para> - </listitem> - - <listitem> - <para>Ernst Winter <email>ewinter@lobo.muc.de</email> contributed - a 2.88 MB floppy drive to the project. This will hopefully - increase the pressure for rewriting the floppy disk driver. - <!-- smiley -->;-)</para> - </listitem> - - <listitem> - <para><ulink URL="http://www.tekram.com">Tekram - Technologies</ulink> sent one each of their DC-390, DC-390U - and DC-390F FAST and ULTRA SCSI host adapter cards for - regression testing of the NCR and AMD drivers with their cards. - They are also to be applauded for making driver sources for free - operating systems available from their FTP server <ulink - URL="ftp://ftp.tekram.com/scsi/FreeBSD">ftp://ftp.tekram.com/scsi/FreeBSD</ulink>.</para> - </listitem> - - <listitem> - <para><email>Larry M. Augustin</email> contributed not only a - Symbios Sym8751S SCSI card, but also a set of data books, - including one about the forthcoming Sym53c895 chip with Ultra-2 - and LVD support, and the latest programming manual with - information on how to safely use the advanced features of the - latest Symbios SCSI chips. Thanks a lot!</para> - </listitem> - - <listitem> - <para>Christoph Kukulies <email>kuku@FreeBSD.org</email> donated - an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver - development.</para> - </listitem> - </itemizedlist> - </listitem> - - <listitem> - <para><emphasis>Special contributors:</emphasis></para> - - <itemizedlist> - <listitem> - <para><ulink URL="http://www.cdrom.com">Walnut Creek CDROM</ulink> - has donated almost more than we can say (see the <link - linkend="history">history</link> document for more details). - In particular, we would like to thank them for the original - hardware used for <hostid - role="fqdn">freefall.FreeBSD.org</hostid>, our primary - development machine, and for <hostid - role="fqdn">thud.FreeBSD.org</hostid>, a testing and build - box. We are also indebted to them for funding various - contributors over the years and providing us with unrestricted - use of their T1 connection to the Internet.</para> - </listitem> - - <listitem> - <para>The <ulink URL="http://www.interface-business.de">interface - business GmbH, Dresden</ulink> has been patiently supporting - &a.joerg; who has often preferred FreeBSD work over paywork, and - used to fall back to their (quite expensive) EUnet Internet - connection whenever his private connection became too slow or - flakey to work with it...</para> - </listitem> - - <listitem> - <para><ulink URL="http://www.bsdi.com">Berkeley Software Design, - Inc.</ulink> has contributed their DOS emulator code to the - remaining BSD world, which is used in the - <emphasis>doscmd</emphasis> command.</para> - </listitem> - </itemizedlist> - </listitem> - </itemizedlist> - </sect1> - - <sect1> - <title>Core Team Alumni</title> - - <para>The following people were members of the FreeBSD core team during - the periods indicated. We thank them for their past efforts in the - service of the FreeBSD project.</para> - - <para><emphasis>In rough chronological order:</emphasis></para> - - <itemizedlist> - <listitem> - <para>&a.guido (1995 - 1999)</para> - </listitem> - - <listitem> - <para>&a.dyson (1993 - 1998)</para> - </listitem> - - <listitem> - <para>&a.nate (1992 - 1996)</para> - </listitem> - - <listitem> - <para>&a.rgrimes (1992 - 1995)</para> - </listitem> - - <listitem> - <para>Andreas Schulz (1992 - 1995)</para> - </listitem> - - <listitem> - <para>&a.csgr (1993 - 1995)</para> - </listitem> - - <listitem> - <para>&a.paul (1992 - 1995)</para> - </listitem> - - <listitem> - <para>&a.smace (1993 - 1994)</para> - </listitem> - - <listitem> - <para>Andrew Moore (1993 - 1994)</para> - </listitem> - - <listitem> - <para>Christoph Robitschko (1993 - 1994)</para> - </listitem> - - <listitem> - <para>J. T. Conklin (1992 - 1993)</para> - </listitem> - </itemizedlist> - </sect1> - - <sect1> - <title>Derived Software Contributors</title> - - <para>This software was originally derived from William F. Jolitz's 386BSD - release 0.1, though almost none of the original 386BSD specific code - remains. This software has been essentially re-implemented from the - 4.4BSD-Lite release provided by the Computer Science Research Group - (CSRG) at the University of California, Berkeley and associated academic - contributors.</para> - - <para>There are also portions of NetBSD and OpenBSD that have been - integrated into FreeBSD as well, and we would therefore like to thank - all the contributors to NetBSD and OpenBSD for their work.</para> - </sect1> - - <sect1 id="contrib-additional"> - <title>Additional FreeBSD Contributors</title> - - <para>(in alphabetical order by first name):</para> - - <itemizedlist> - <listitem> - <para>ABURAYA Ryushirou <email>rewsirow@ff.iij4u.or.jp</email></para> - </listitem> - - <listitem> - <para>AMAGAI Yoshiji <email>amagai@nue.org</email></para> - </listitem> - - <listitem> - <para>Aaron Bornstein <email>aaronb@j51.com</email></para> - </listitem> - - <listitem> - <para>Aaron Smith <email>aaron@mutex.org</email></para> - </listitem> - - <listitem> - <para>Achim Patzner <email>ap@noses.com</email></para> - </listitem> - - <listitem> - <para>Ada T Lim <email>ada@bsd.org</email></para> - </listitem> - - <listitem> - <para>Adam Baran <email>badam@mw.mil.pl</email></para> - </listitem> - - <listitem> - <para>Adam Glass <email>glass@postgres.berkeley.edu</email></para> - </listitem> - - <listitem> - <para>Adam McDougall <email>mcdouga9@egr.msu.edu</email></para> - </listitem> - - <listitem> - <para>Adrian Colley <email>aecolley@ois.ie</email></para> - </listitem> - - <listitem> - <para>Adrian Hall <email>adrian@ibmpcug.co.uk</email></para> - </listitem> - - <listitem> - <para>Adrian Mariano <email>adrian@cam.cornell.edu</email></para> - </listitem> - - <listitem> - <para>Adrian Steinmann <email>ast@marabu.ch</email></para> - </listitem> - - <listitem> - <para>Adam Strohl <email>troll@digitalspark.net</email></para> - </listitem> - - <listitem> - <para>Adrian T. Filipi-Martin - <email>atf3r@agate.cs.virginia.edu</email></para> - </listitem> - - <listitem> - <para>Ajit Thyagarajan <email>unknown</email></para> - </listitem> - - <listitem> - <para>Akio Morita - <email>amorita@meadow.scphys.kyoto-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Akira SAWADA <email>unknown</email></para> - </listitem> - - <listitem> - <para>Akira Watanabe - <email>akira@myaw.ei.meisei-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Akito Fujita <email>fujita@zoo.ncl.omron.co.jp</email></para> - </listitem> - - <listitem> - <para>Alain Kalker - <email>A.C.P.M.Kalker@student.utwente.nl</email></para> - </listitem> - - <listitem> - <para>Alan Bawden <email>alan@curry.epilogue.com</email></para> - </listitem> - - <listitem> - <para>Alec Wolman <email>wolman@cs.washington.edu</email></para> - </listitem> - - <listitem> - <para>Aled Morris <email>aledm@routers.co.uk</email></para> - </listitem> - - <listitem> - <para>Alex <email>garbanzo@hooked.net</email></para> - </listitem> - - <listitem> - <para>Alex D. Chen - <email>dhchen@Canvas.dorm7.nccu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Alex G. Bulushev <email>bag@demos.su</email></para> - </listitem> - - <listitem> - <para>Alex Le Heux <email>alexlh@funk.org</email></para> - </listitem> - - <listitem> - <para>Alex Perel <email>veers@disturbed.net</email></para> - </listitem> - - <listitem> - <para>Alexander B. Povolotsky <email>tarkhil@mgt.msk.ru</email></para> - </listitem> - - <listitem> - <para>Alexander Leidinger - <email>netchild@wurzelausix.CS.Uni-SB.DE</email></para> - </listitem> - - <listitem> - <para>Alexander Langer <email>alex@cichlids.com</email></para> - </listitem> - - <listitem> - <para>Alexandre Snarskii <email>snar@paranoia.ru</email></para> - </listitem> - - <listitem> - <para>Alistair G. Crooks <email>agc@uts.amdahl.com</email></para> - </listitem> - - <listitem> - <para>Allan Saddi <email>asaddi@philosophysw.com</email></para> - </listitem> - - <listitem> - <para>Allen Campbell <email>allenc@verinet.com</email></para> - </listitem> - - <listitem> - <para>Amakawa Shuhei <email>amakawa@hoh.t.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>Amancio Hasty <email>hasty@star-gate.com</email></para> - </listitem> - - <listitem> - <para>Amir Farah <email>amir@comtrol.com</email></para> - </listitem> - - <listitem> - <para>Amy Baron <email>amee@beer.org</email></para> - </listitem> - - <listitem> - <para>Anatoly A. Orehovsky <email>tolik@mpeks.tomsk.su</email></para> - </listitem> - - <listitem> - <para>Anatoly Vorobey <email>mellon@pobox.com</email></para> - </listitem> - - <listitem> - <para>Anders Nordby <email>nickerne@nome.no</email></para> - </listitem> - - <listitem> - <para>Anders Thulin <email>Anders.X.Thulin@telia.se</email></para> - </listitem> - - <listitem> - <para>Andras Olah <email>olah@cs.utwente.nl</email></para> - </listitem> - - <listitem> - <para>Andre Albsmeier - <email>Andre.Albsmeier@mchp.siemens.de</email></para> - </listitem> - - <listitem> - <para>Andre Oppermann <email>andre@pipeline.ch</email></para> - </listitem> - - <listitem> - <para>Andreas Haakh <email>ah@alman.robin.de</email></para> - </listitem> - - <listitem> - <para>Andreas Kohout <email>shanee@rabbit.augusta.de</email></para> - </listitem> - - <listitem> - <para>Andreas Lohr <email>andreas@marvin.RoBIN.de</email></para> - </listitem> - - <listitem> - <para>Andreas Schulz <email>unknown</email></para> - </listitem> - - <listitem> - <para>Andreas Wetzel <email>mickey@deadline.snafu.de</email></para> - </listitem> - - <listitem> - <para>Andreas Wrede <email>andreas@planix.com</email></para> - </listitem> - - <listitem> - <para>Andres Vega Garcia <email>unknown</email></para> - </listitem> - - <listitem> - <para>Andrew Atrens <email>atreand@statcan.ca</email></para> - </listitem> - - <listitem> - <para>Andrew Boothman <email>andrew@cream.org</email></para> - </listitem> - - <listitem> - <para>Andrew Gillham <email>gillham@andrews.edu</email></para> - </listitem> - - <listitem> - <para>Andrew Gordon <email>andrew.gordon@net-tel.co.uk</email></para> - </listitem> - - <listitem> - <para>Andrew Herbert <email>andrew@werple.apana.org.au</email></para> - </listitem> - - <listitem> - <para>Andrew J. Korty <email>ajk@purdue.edu</email></para> - </listitem> - - <listitem> - <para>Andrew L. Moore <email>alm@mclink.com</email></para> - </listitem> - - <listitem> - <para>Andrew McRae <email>amcrae@cisco.com</email></para> - </listitem> - - <listitem> - <para>Andrew Stevenson <email>andrew@ugh.net.au</email></para> - </listitem> - - <listitem> - <para>Andrew Timonin <email>tim@pool1.convey.ru</email></para> - </listitem> - - <listitem> - <para>Andrew V. Stesin <email>stesin@elvisti.kiev.ua</email></para> - </listitem> - - <listitem> - <para>Andrew Webster <email>awebster@dataradio.com</email></para> - </listitem> - - <listitem> - <para>Andrey Zakhvatov <email>andy@icc.surw.chel.su</email></para> - </listitem> - - <listitem> - <para>Andy Farkas <email>andyf@speednet.com.au</email></para> - </listitem> - - <listitem> - <para>Andy Valencia <email>ajv@csd.mot.com</email></para> - </listitem> - - <listitem> - <para>Andy Whitcroft <email>andy@sarc.city.ac.uk</email></para> - </listitem> - - <listitem> - <para>Angelo Turetta <email>ATuretta@stylo.it</email></para> - </listitem> - - <listitem> - <para>Anthony C. Chavez <email>magus@xmission.com</email></para> - </listitem> - - <listitem> - <para>Anthony Yee-Hang Chan <email>yeehang@netcom.com</email></para> - </listitem> - - <listitem> - <para>Anton Berezin <email>tobez@plab.ku.dk</email></para> - </listitem> - - <listitem> - <para>Antti Kaipila <email>anttik@iki.fi</email></para> - </listitem> - - <listitem> - <para>Are Bryne <email>are.bryne@communique.no</email></para> - </listitem> - - <listitem> - <para>Ari Suutari <email>ari@suutari.iki.fi</email></para> - </listitem> - - <listitem> - <para>Arjan de Vet <email>devet@IAEhv.nl</email></para> - </listitem> - - <listitem> - <para>Arne Henrik Juul <email>arnej@Lise.Unit.NO</email></para> - </listitem> - - <listitem> - <para>Assar Westerlund <email>assar@sics.se</email></para> - </listitem> - - <listitem> - <para>Atsushi Furuta <email>furuta@sra.co.jp</email></para> - </listitem> - - <listitem> - <para>Atsushi Murai <email>amurai@spec.co.jp</email></para> - </listitem> - - <listitem> - <para>Bakul Shah <email>bvs@bitblocks.com</email></para> - </listitem> - - <listitem> - <para>Barry Bierbauch <email>pivrnec@vszbr.cz</email></para> - </listitem> - - <listitem> - <para>Barry Lustig <email>barry@ictv.com</email></para> - </listitem> - - <listitem> - <para>Ben Hutchinson <email>benhutch@xfiles.org.uk</email></para> - </listitem> - - <listitem> - <para>Ben Jackson <email>unknown</email></para> - </listitem> - - <listitem> - <para>Ben Smithurst <email>ben@scientia.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>Ben Walter <email>bwalter@itachi.swcp.com</email></para> - </listitem> - - <listitem> - <para>Benjamin Lewis <email>bhlewis@gte.net</email></para> - </listitem> - - <listitem> - <para>Bernd Rosauer <email>br@schiele-ct.de</email></para> - </listitem> - - <listitem> - <para>Bill Kish <email>kish@osf.org</email></para> - </listitem> - - <listitem> - <para>Bill Trost <email>trost@cloud.rain.com</email></para> - </listitem> - - <listitem> - <para>Blaz Zupan <email>blaz@amis.net</email></para> - </listitem> - - <listitem> - <para>Bob Van Valzah <email>Bob@whitebarn.com</email></para> - </listitem> - - <listitem> - <para>Bob Willcox <email>bob@luke.pmr.com</email></para> - </listitem> - - <listitem> - <para>Boris Staeblow <email>balu@dva.in-berlin.de</email></para> - </listitem> - - <listitem> - <para>Boyd R. Faulkner <email>faulkner@asgard.bga.com</email></para> - </listitem> - - <listitem> - <para>Brad Karp <email>karp@eecs.harvard.edu</email></para> - </listitem> - - <listitem> - <para>Bradley Dunn <email>bradley@dunn.org</email></para> - </listitem> - - <listitem> - <para>Brandon Fosdick <email>bfoz@glue.umd.edu</email></para> - </listitem> - - <listitem> - <para>Brandon Gillespie <email>brandon@roguetrader.com</email></para> - </listitem> - - <listitem> - <para>&a.wlloyd</para> - </listitem> - - <listitem> - <para>Bob Wilcox <email>bob@obiwan.uucp</email></para> - </listitem> - - <listitem> - <para>Boyd Faulkner <email>faulkner@mpd.tandem.com</email></para> - </listitem> - - <listitem> - <para>Brent J. Nordquist <email>bjn@visi.com</email></para> - </listitem> - - <listitem> - <para>Brett Lymn <email>blymn@mulga.awadi.com.AU</email></para> - </listitem> - - <listitem> - <para>Brett Taylor - <email>brett@peloton.physics.montana.edu</email></para> - </listitem> - - <listitem> - <para>Brian Campbell <email>brianc@pobox.com</email></para> - </listitem> - - <listitem> - <para>Brian Clapper <email>bmc@willscreek.com</email></para> - </listitem> - - <listitem> - <para>Brian Cully <email>shmit@kublai.com</email></para> - </listitem> - - <listitem> - <para>Brian Handy - <email>handy@lambic.space.lockheed.com</email></para> - </listitem> - - <listitem> - <para>Brian Litzinger <email>brian@MediaCity.com</email></para> - </listitem> - - <listitem> - <para>Brian McGovern <email>bmcgover@cisco.com</email></para> - </listitem> - - <listitem> - <para>Brian Moore <email>ziff@houdini.eecs.umich.edu</email></para> - </listitem> - - <listitem> - <para>Brian R. Haug <email>haug@conterra.com</email></para> - </listitem> - - <listitem> - <para>Brian Tao <email>taob@risc.org</email></para> - </listitem> - - <listitem> - <para>Brion Moss <email>brion@queeg.com</email></para> - </listitem> - - <listitem> - <para>Bruce A. Mah <email>bmah@ca.sandia.gov</email></para> - </listitem> - - <listitem> - <para>Bruce Albrecht <email>bruce@zuhause.mn.org</email></para> - </listitem> - - <listitem> - <para>Bruce Gingery <email>bgingery@gtcs.com</email></para> - </listitem> - - <listitem> - <para>Bruce J. Keeler <email>loodvrij@gridpoint.com</email></para> - </listitem> - - <listitem> - <para>Bruce Murphy <email>packrat@iinet.net.au</email></para> - </listitem> - - <listitem> - <para>Bruce Walter <email>walter@fortean.com</email></para> - </listitem> - - <listitem> - <para>Carey Jones <email>mcj@acquiesce.org</email></para> - </listitem> - - <listitem> - <para>Carl Fongheiser <email>cmf@netins.net</email></para> - </listitem> - - <listitem> - <para>Carl Mascott <email>cmascott@world.std.com</email></para> - </listitem> - - <listitem> - <para>Casper <email>casper@acc.am</email></para> - </listitem> - - <listitem> - <para>Castor Fu <email>castor@geocast.com</email></para> - </listitem> - - <listitem> - <para>Cejka Rudolf <email>cejkar@dcse.fee.vutbr.cz</email></para> - </listitem> - - <listitem> - <para>Chain Lee <email>chain@110.net</email></para> - </listitem> - - <listitem> - <para>Charles Hannum <email>mycroft@ai.mit.edu</email></para> - </listitem> - - <listitem> - <para>Charles Henrich <email>henrich@msu.edu</email></para> - </listitem> - - <listitem> - <para>Charles Mott <email>cmott@srv.net</email></para> - </listitem> - - <listitem> - <para>Charles Owens <email>owensc@enc.edu</email></para> - </listitem> - - <listitem> - <para>Chet Ramey <email>chet@odin.INS.CWRU.Edu</email></para> - </listitem> - - <listitem> - <para>Chia-liang Kao <email>clkao@CirX.ORG</email></para> - </listitem> - - <listitem> - <para>Chiharu Shibata <email>chi@bd.mbn.or.jp</email></para> - </listitem> - - <listitem> - <para>Chip Norkus <email>unknown</email></para> - </listitem> - - <listitem> - <para>Choi Jun Ho <email>junker@jazz.snu.ac.kr</email></para> - </listitem> - - <listitem> - <para>Chris Csanady <email>cc@tarsier.ca.sandia.gov</email></para> - </listitem> - - <listitem> - <para>Chris Dabrowski <email>chris@vader.org</email></para> - </listitem> - - <listitem> - <para>Chris Dillon <email>cdillon@wolves.k12.mo.us</email></para> - </listitem> - - <listitem> - <para>Chris Shenton - <email>cshenton@angst.it.hq.nasa.gov</email></para> - </listitem> - - <listitem> - <para>Chris Stenton <email>jacs@gnome.co.uk</email></para> - </listitem> - - <listitem> - <para>Chris Timmons <email>skynyrd@opus.cts.cwu.edu</email></para> - </listitem> - - <listitem> - <para>Chris Torek <email>torek@ee.lbl.gov</email></para> - </listitem> - - <listitem> - <para>Christian Gusenbauer - <email>cg@fimp01.fim.uni-linz.ac.at</email></para> - </listitem> - - <listitem> - <para>Christian Haury <email>Christian.Haury@sagem.fr</email></para> - </listitem> - - <listitem> - <para>Christian Weisgerber - <email>naddy@bigeye.rhein-neckar.de</email></para> - </listitem> - - <listitem> - <para>Christoph P. Kukulies <email>kuku@FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Christoph Robitschko - <email>chmr@edvz.tu-graz.ac.at</email></para> - </listitem> - - <listitem> - <para>Christoph Weber-Fahr - <email>wefa@callcenter.systemhaus.net</email></para> - </listitem> - - <listitem> - <para>Christopher G. Demetriou - <email>cgd@postgres.berkeley.edu</email></para> - </listitem> - - <listitem> - <para>Christopher T. Johnson - <email>cjohnson@neunacht.netgsi.com</email></para> - </listitem> - - <listitem> - <para>Chrisy Luke <email>chrisy@flix.net</email></para> - </listitem> - - <listitem> - <para>Chuck Hein <email>chein@cisco.com</email></para> - </listitem> - - <listitem> - <para>Clive Lin <email>clive@CiRX.ORG</email></para> - </listitem> - - <listitem> - <para>Colman Reilly <email>careilly@tcd.ie</email></para> - </listitem> - - <listitem> - <para>Conrad Sabatier <email>conrads@neosoft.com</email></para> - </listitem> - - <listitem> - <para>Coranth Gryphon <email>gryphon@healer.com</email></para> - </listitem> - - <listitem> - <para>Cornelis van der Laan - <email>nils@guru.ims.uni-stuttgart.de</email></para> - </listitem> - - <listitem> - <para>Cove Schneider <email>cove@brazil.nbn.com</email></para> - </listitem> - - <listitem> - <para>Craig Leres <email>leres@ee.lbl.gov</email></para> - </listitem> - - <listitem> - <para>Craig Loomis <email>unknown</email></para> - </listitem> - - <listitem> - <para>Craig Metz <email>cmetz@inner.net</email></para> - </listitem> - - <listitem> - <para>Craig Spannring <email>cts@internetcds.com</email></para> - </listitem> - - <listitem> - <para>Craig Struble <email>cstruble@vt.edu</email></para> - </listitem> - - <listitem> - <para>Cristian Ferretti <email>cfs@riemann.mat.puc.cl</email></para> - </listitem> - - <listitem> - <para>Curt Mayer <email>curt@toad.com</email></para> - </listitem> - - <listitem> - <para>Cy Schubert <email>cschuber@uumail.gov.bc.ca</email></para> - </listitem> - - <listitem> - <para>DI. Christian Gusenbauer - <email>cg@scotty.edvz.uni-linz.ac.at</email></para> - </listitem> - - <listitem> - <para>Dai Ishijima <email>ishijima@tri.pref.osaka.jp</email></para> - </listitem> - - <listitem> - <para>Damian Hamill <email>damian@cablenet.net</email></para> - </listitem> - - <listitem> - <para>Dan Cross <email>tenser@spitfire.ecsel.psu.edu</email></para> - </listitem> - - <listitem> - <para>Dan Lukes <email>dan@obluda.cz</email></para> - </listitem> - - <listitem> - <para>Dan Nelson <email>dnelson@emsphone.com</email></para> - </listitem> - - <listitem> - <para>Dan Walters <email>hannibal@cyberstation.net</email></para> - </listitem> - - <listitem> - <para>Daniel M. Eischen - <email>deischen@iworks.InterWorks.org</email></para> - </listitem> - - <listitem> - <para>Daniel O'Connor <email>doconnor@gsoft.com.au</email></para> - </listitem> - - <listitem> - <para>Daniel Poirot <email>poirot@aio.jsc.nasa.gov</email></para> - </listitem> - - <listitem> - <para>Daniel Rock <email>rock@cs.uni-sb.de</email></para> - </listitem> - - <listitem> - <para>Danny Egen <email>unknown</email></para> - </listitem> - - <listitem> - <para>Danny J. Zerkel <email>dzerkel@phofarm.com</email></para> - </listitem> - - <listitem> - <para>Darren Reed <email>avalon@coombs.anu.edu.au</email></para> - </listitem> - - <listitem> - <para>Dave Adkins <email>adkin003@tc.umn.edu</email></para> - </listitem> - - <listitem> - <para>Dave Andersen <email>angio@aros.net</email></para> - </listitem> - - <listitem> - <para>Dave Blizzard <email>dblizzar@sprynet.com</email></para> - </listitem> - - <listitem> - <para>Dave Bodenstab <email>imdave@synet.net</email></para> - </listitem> - - <listitem> - <para>Dave Burgess <email>burgess@hrd769.brooks.af.mil</email></para> - </listitem> - - <listitem> - <para>Dave Chapeskie <email>dchapes@ddm.on.ca</email></para> - </listitem> - - <listitem> - <para>Dave Cornejo <email>dave@dogwood.com</email></para> - </listitem> - - <listitem> - <para>Dave Edmondson <email>davided@sco.com</email></para> - </listitem> - - <listitem> - <para>Dave Glowacki <email>dglo@ssec.wisc.edu</email></para> - </listitem> - - <listitem> - <para>Dave Marquardt <email>marquard@austin.ibm.com</email></para> - </listitem> - - <listitem> - <para>Dave Tweten <email>tweten@FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>David A. Adkins <email>adkin003@tc.umn.edu</email></para> - </listitem> - - <listitem> - <para>David A. Bader <email>dbader@umiacs.umd.edu</email></para> - </listitem> - - <listitem> - <para>David Borman <email>dab@bsdi.com</email></para> - </listitem> - - <listitem> - <para>David Dawes <email>dawes@XFree86.org</email></para> - </listitem> - - <listitem> - <para>David Filo <email>filo@yahoo.com</email></para> - </listitem> - - <listitem> - <para>David Holland <email>dholland@eecs.harvard.edu</email></para> - </listitem> - - <listitem> - <para>David Holloway <email>daveh@gwythaint.tamis.com</email></para> - </listitem> - - <listitem> - <para>David Horwitt <email>dhorwitt@ucsd.edu</email></para> - </listitem> - - <listitem> - <para>David Hovemeyer <email>daveho@infocom.com</email></para> - </listitem> - - <listitem> - <para>David Jones <email>dej@qpoint.torfree.net</email></para> - </listitem> - - <listitem> - <para>David Kelly <email>dkelly@tomcat1.tbe.com</email></para> - </listitem> - - <listitem> - <para>David Kulp <email>dkulp@neomorphic.com</email></para> - </listitem> - - <listitem> - <para>David L. Nugent <email>davidn@blaze.net.au</email></para> - </listitem> - - <listitem> - <para>David Leonard <email>d@scry.dstc.edu.au</email></para> - </listitem> - - <listitem> - <para>David Malone <email>dwmalone@maths.tcd.ie</email></para> - </listitem> - - <listitem> - <para>David Muir Sharnoff <email>muir@idiom.com</email></para> - </listitem> - - <listitem> - <para>David S. Miller <email>davem@jenolan.rutgers.edu</email></para> - </listitem> - - <listitem> - <para>David Wolfskill <email>dhw@whistle.com</email></para> - </listitem> - - <listitem> - <para>Dean Gaudet <email>dgaudet@arctic.org</email></para> - </listitem> - - <listitem> - <para>Dean Huxley <email>dean@fsa.ca</email></para> - </listitem> - - <listitem> - <para>Denis Fortin <email>unknown</email></para> - </listitem> - - <listitem> - <para>Dennis Glatting - <email>dennis.glatting@software-munitions.com</email></para> - </listitem> - - <listitem> - <para>Denton Gentry <email>denny1@home.com</email></para> - </listitem> - - <listitem> - <para>Derek Inksetter <email>derek@saidev.com</email></para> - </listitem> - - <listitem> - <para>Dima Sivachenko <email>dima@Chg.RU</email></para> - </listitem> - - <listitem> - <para>Dirk Keunecke <email>dk@panda.rhein-main.de</email></para> - </listitem> - - <listitem> - <para>Dirk Nehrling <email>nerle@pdv.de</email></para> - </listitem> - - <listitem> - <para>Dmitry Khrustalev <email>dima@xyzzy.machaon.ru</email></para> - </listitem> - - <listitem> - <para>Dmitry Kohmanyuk <email>dk@farm.org</email></para> - </listitem> - - <listitem> - <para>Dom Mitchell <email>dom@myrddin.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>Dominik Brettnacher <email>domi@saargate.de</email></para> - </listitem> - - <listitem> - <para>Don Croyle <email>croyle@gelemna.ft-wayne.in.us</email></para> - </listitem> - - <listitem> - <para>&a.whiteside;</para> - </listitem> - - <listitem> - <para>Don Morrison <email>dmorrisn@u.washington.edu</email></para> - </listitem> - - <listitem> - <para>Don Yuniskis <email>dgy@rtd.com</email></para> - </listitem> - - <listitem> - <para>Donald Maddox <email>dmaddox@conterra.com</email></para> - </listitem> - - <listitem> - <para>Doug Barton <email>studded@dal.net</email></para> - </listitem> - - <listitem> - <para>Douglas Ambrisko <email>ambrisko@whistle.com</email></para> - </listitem> - - <listitem> - <para>Douglas Carmichael <email>dcarmich@mcs.com</email></para> - </listitem> - - <listitem> - <para>Douglas Crosher <email>dtc@scrooge.ee.swin.oz.au</email></para> - </listitem> - - <listitem> - <para>Drew Derbyshire <email>ahd@kew.com</email></para> - </listitem> - - <listitem> - <para>Duncan Barclay <email>dmlb@ragnet.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>Dustin Sallings <email>dustin@spy.net</email></para> - </listitem> - - <listitem> - <para>Eckart "Isegrim" Hofmann - <email>Isegrim@Wunder-Nett.org</email></para> - </listitem> - - <listitem> - <para>Ed Gold - <email>vegold01@starbase.spd.louisville.edu</email></para> - </listitem> - - <listitem> - <para>Ed Hudson <email>elh@p5.spnet.com</email></para> - </listitem> - - <listitem> - <para>Edward Wang <email>edward@edcom.com</email></para> - </listitem> - - <listitem> - <para>Edwin Groothus <email>edwin@nwm.wan.philips.com</email></para> - </listitem> - - <listitem> - <para>Eiji-usagi-MATSUmoto <email>usagi@clave.gr.jp</email></para> - </listitem> - - <listitem> - <para>ELISA Font Project</para> - </listitem> - - <listitem> - <para>Elmar Bartel - <email>bartel@informatik.tu-muenchen.de</email></para> - </listitem> - - <listitem> - <para>Eric A. Griff <email>eagriff@global2000.net</email></para> - </listitem> - - <listitem> - <para>Eric Blood <email>eblood@cs.unr.edu</email></para> - </listitem> - - <listitem> - <para>Eric J. Haug <email>ejh@slustl.slu.edu</email></para> - </listitem> - - <listitem> - <para>Eric J. Schwertfeger <email>eric@cybernut.com</email></para> - </listitem> - - <listitem> - <para>Eric L. Hernes <email>erich@lodgenet.com</email></para> - </listitem> - - <listitem> - <para>Eric P. Scott <email>eps@sirius.com</email></para> - </listitem> - - <listitem> - <para>Eric Sprinkle <email>eric@ennovatenetworks.com</email></para> - </listitem> - - <listitem> - <para>Erich Stefan Boleyn <email>erich@uruk.org</email></para> - </listitem> - - <listitem> - <para>Erik E. Rantapaa <email>rantapaa@math.umn.edu</email></para> - </listitem> - - <listitem> - <para>Erik H. Moe <email>ehm@cris.com</email></para> - </listitem> - - <listitem> - <para>Ernst Winter <email>ewinter@lobo.muc.de</email></para> - </listitem> - - <listitem> - <para>Espen Skoglund <email>espensk@stud.cs.uit.no></email></para> - </listitem> - - <listitem> - <para>Eugene M. Kim <email>astralblue@usa.net</email></para> - </listitem> - - <listitem> - <para>Eugene Radchenko <email>genie@qsar.chem.msu.su</email></para> - </listitem> - - <listitem> - <para>Evan Champion <email>evanc@synapse.net</email></para> - </listitem> - - <listitem> - <para>Faried Nawaz <email>fn@Hungry.COM</email></para> - </listitem> - - <listitem> - <para>Flemming Jacobsen <email>fj@tfs.com</email></para> - </listitem> - - <listitem> - <para>Fong-Ching Liaw <email>fong@juniper.net</email></para> - </listitem> - - <listitem> - <para>Francis M J Hsieh <email>mjshieh@life.nthu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Frank Bartels <email>knarf@camelot.de</email></para> - </listitem> - - <listitem> - <para>Frank Chen Hsiung Chan - <email>frankch@waru.life.nthu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Frank Durda IV <email>uhclem@nemesis.lonestar.org</email></para> - </listitem> - - <listitem> - <para>Frank MacLachlan <email>fpm@n2.net</email></para> - </listitem> - - <listitem> - <para>Frank Mayhar <email>frank@exit.com</email></para> - </listitem> - - <listitem> - <para>Frank Nobis <email>fn@Radio-do.de</email></para> - </listitem> - - <listitem> - <para>Frank Volf <email>volf@oasis.IAEhv.nl</email></para> - </listitem> - - <listitem> - <para>Frank ten Wolde <email>franky@pinewood.nl</email></para> - </listitem> - - <listitem> - <para>Frank van der Linden <email>frank@fwi.uva.nl</email></para> - </listitem> - - <listitem> - <para>Fred Cawthorne <email>fcawth@jjarray.umn.edu</email></para> - </listitem> - - <listitem> - <para>Fred Gilham <email>gilham@csl.sri.com</email></para> - </listitem> - - <listitem> - <para>Fred Templin <email>templin@erg.sri.com</email></para> - </listitem> - - <listitem> - <para>Frederick Earl Gray <email>fgray@rice.edu</email></para> - </listitem> - - <listitem> - <para>FUJIMOTO Kensaku - <email>fujimoto@oscar.elec.waseda.ac.jp</email></para> - </listitem> - - <listitem> - <para>FUJISHIMA Satsuki <email>k5@respo.or.jp</email></para> - </listitem> - - <listitem> - <para>FURUSAWA Kazuhisa - <email>furusawa@com.cs.osakafu-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Gabor Kincses <email>gabor@acm.org</email></para> - </listitem> - - <listitem> - <para>Gabor Zahemszky <email>zgabor@CoDe.hu</email></para> - </listitem> - - <listitem> - <para>G. Adam Stanislav<email>adam@whizkidtech.net</email></para> - </listitem> - - <listitem> - <para>Garance A Drosehn <email>gad@eclipse.its.rpi.edu</email></para> - </listitem> - - <listitem> - <para>Gareth McCaughan <email>gjm11@dpmms.cam.ac.uk</email></para> - </listitem> - - <listitem> - <para>Gary A. Browning <email>gab10@griffcd.amdahl.com</email></para> - </listitem> - - <listitem> - <para>Gary Howland <email>gary@hotlava.com</email></para> - </listitem> - - <listitem> - <para>Gary J. <email>garyj@rks32.pcs.dec.com</email></para> - </listitem> - - <listitem> - <para>Gary Kline <email>kline@thought.org</email></para> - </listitem> - - <listitem> - <para>Gaspar Chilingarov <email>nightmar@lemming.acc.am</email></para> - </listitem> - - <listitem> - <para>Gea-Suan Lin <email>gsl@tpts4.seed.net.tw</email></para> - </listitem> - - <listitem> - <para>Geoff Rehmet <email>csgr@alpha.ru.ac.za</email></para> - </listitem> - - <listitem> - <para>Georg Wagner <email>georg.wagner@ubs.com</email></para> - </listitem> - - <listitem> - <para>Gerard Roudier <email>groudier@club-internet.fr</email></para> - </listitem> - - <listitem> - <para>Gianmarco Giovannelli - <email>gmarco@giovannelli.it</email></para> - </listitem> - - <listitem> - <para>Gil Kloepfer Jr. <email>gil@limbic.ssdl.com</email></para> - </listitem> - - <listitem> - <para>Gilad Rom <email>rom_glsa@ein-hashofet.co.il</email></para> - </listitem> - - <listitem> - <para>Ginga Kawaguti - <email>ginga@amalthea.phys.s.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>Giles Lean <email>giles@nemeton.com.au</email></para> - </listitem> - - <listitem> - <para>Glen Foster <email>gfoster@gfoster.com</email></para> - </listitem> - - <listitem> - <para>Glenn Johnson <email>gljohns@bellsouth.net</email></para> - </listitem> - - <listitem> - <para>Godmar Back <email>gback@facility.cs.utah.edu</email></para> - </listitem> - - <listitem> - <para>Goran Hammarback <email>goran@astro.uu.se</email></para> - </listitem> - - <listitem> - <para>Gord Matzigkeit <email>gord@enci.ucalgary.ca</email></para> - </listitem> - - <listitem> - <para>Gordon Greeff <email>gvg@uunet.co.za</email></para> - </listitem> - - <listitem> - <para>Graham Wheeler <email>gram@cdsec.com</email></para> - </listitem> - - <listitem> - <para>Greg A. Woods <email>woods@zeus.leitch.com</email></para> - </listitem> - - <listitem> - <para>Greg Ansley <email>gja@ansley.com</email></para> - </listitem> - - <listitem> - <para>Greg Troxel <email>gdt@ir.bbn.com</email></para> - </listitem> - - <listitem> - <para>Greg Ungerer <email>gerg@stallion.oz.au</email></para> - </listitem> - - <listitem> - <para>Gregory Bond <email>gnb@itga.com.au</email></para> - </listitem> - - <listitem> - <para>Gregory D. Moncreaff - <email>moncrg@bt340707.res.ray.com</email></para> - </listitem> - - <listitem> - <para>Guy Harris <email>guy@netapp.com</email></para> - </listitem> - - <listitem> - <para>Guy Helmer <email>ghelmer@cs.iastate.edu</email></para> - </listitem> - - <listitem> - <para>HAMADA Naoki <email>hamada@astec.co.jp</email></para> - </listitem> - - <listitem> - <para>HONDA Yasuhiro - <email>honda@kashio.info.mie-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>HOSOBUCHI Noriyuki <email>hoso@buchi.tama.or.jp</email></para> - </listitem> - - <listitem> - <para>Hannu Savolainen <email>hannu@voxware.pp.fi</email></para> - </listitem> - - <listitem> - <para>Hans Huebner <email>hans@artcom.de</email></para> - </listitem> - - <listitem> - <para>Hans Petter Bieker <email>zerium@webindex.no</email></para> - </listitem> - - <listitem> - <para>Hans Zuidam <email>hans@brandinnovators.com</email></para> - </listitem> - - <listitem> - <para>Harlan Stenn <email>Harlan.Stenn@pfcs.com</email></para> - </listitem> - - <listitem> - <para>Harold Barker <email>hbarker@dsms.com</email></para> - </listitem> - - <listitem> - <para>Havard Eidnes - <email>Havard.Eidnes@runit.sintef.no</email></para> - </listitem> - - <listitem> - <para>Heikki Suonsivu <email>hsu@cs.hut.fi</email></para> - </listitem> - - <listitem> - <para>Heiko W. Rupp <email>unknown</email></para> - </listitem> - - <listitem> - <para>Helmut F. Wirth <email>hfwirth@ping.at</email></para> - </listitem> - - <listitem> - <para>Henrik Vestergaard Draboel - <email>hvd@terry.ping.dk</email></para> - </listitem> - - <listitem> - <para>Herb Peyerl <email>hpeyerl@NetBSD.org</email></para> - </listitem> - - <listitem> - <para>Hideaki Ohmon <email>ohmon@tom.sfc.keio.ac.jp</email></para> - </listitem> - - <listitem> - <para>Hidekazu Kuroki <email>hidekazu@cs.titech.ac.jp</email></para> - </listitem> - - <listitem> - <para>Hideki Yamamoto <email>hyama@acm.org</email></para> - </listitem> - - <listitem> - <para>Hideyuki Suzuki - <email>hideyuki@sat.t.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>Hirayama Issei <email>iss@mail.wbs.ne.jp</email></para> - </listitem> - - <listitem> - <para>Hiroaki Sakai <email>sakai@miya.ee.kagu.sut.ac.jp</email></para> - </listitem> - - <listitem> - <para>Hiroharu Tamaru <email>tamaru@ap.t.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>Hironori Ikura <email>hikura@kaisei.org</email></para> - </listitem> - - <listitem> - <para>Hiroshi Nishikawa <email>nis@pluto.dti.ne.jp</email></para> - </listitem> - - <listitem> - <para>Hiroya Tsubakimoto <email>unknown</email></para> - </listitem> - - <listitem> - <para>Holger Veit <email>Holger.Veit@gmd.de</email></para> - </listitem> - - <listitem> - <para>Holm Tiffe <email>holm@geophysik.tu-freiberg.de</email></para> - </listitem> - - <listitem> - <para>Horance Chou - <email>horance@freedom.ie.cycu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Horihiro Kumagai <email>kuma@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>HOTARU-YA <email>hotaru@tail.net</email></para> - </listitem> - - <listitem> - <para>Hr.Ladavac <email>lada@ws2301.gud.siemens.co.at</email></para> - </listitem> - - <listitem> - <para>Hubert Feyrer <email>hubertf@NetBSD.ORG</email></para> - </listitem> - - <listitem> - <para>Hugh F. Mahon <email>hugh@nsmdserv.cnd.hp.com</email></para> - </listitem> - - <listitem> - <para>Hugh Mahon <email>h_mahon@fc.hp.com</email></para> - </listitem> - - <listitem> - <para>Hung-Chi Chu <email>hcchu@r350.ee.ntu.edu.tw</email></para> - </listitem> - - <listitem> - <para>IMAI Takeshi <email>take-i@ceres.dti.ne.jp</email></para> - </listitem> - - <listitem> - <para>IMAMURA Tomoaki - <email>tomoak-i@is.aist-nara.ac.jp</email></para> - </listitem> - - <listitem> - <para>Ian Dowse <email>iedowse@maths.tcd.ie</email></para> - </listitem> - - <listitem> - <para>Ian Holland <email>ianh@tortuga.com.au</email></para> - </listitem> - - <listitem> - <para>Ian Struble <email>ian@broken.net</email></para> - </listitem> - - <listitem> - <para>Ian Vaudrey <email>i.vaudrey@bigfoot.com</email></para> - </listitem> - - <listitem> - <para>Igor Khasilev <email>igor@jabber.paco.odessa.ua</email></para> - </listitem> - - <listitem> - <para>Igor Roshchin <email>str@giganda.komkon.org</email></para> - </listitem> - - <listitem> - <para>Igor Sviridov <email>siac@ua.net</email></para> - </listitem> - - <listitem> - <para>Igor Vinokurov <email>igor@zynaps.ru</email></para> - </listitem> - - <listitem> - <para>Ikuo Nakagawa <email>ikuo@isl.intec.co.jp</email></para> - </listitem> - - <listitem> - <para>Ilya V. Komarov <email>mur@lynx.ru</email></para> - </listitem> - - <listitem> - <para>Issei Suzuki <email>issei@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Itsuro Saito <email>saito@miv.t.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>J. Bryant <email>jbryant@argus.flash.net</email></para> - </listitem> - - <listitem> - <para>J. David Lowe <email>lowe@saturn5.com</email></para> - </listitem> - - <listitem> - <para>J. Han <email>hjh@best.com</email></para> - </listitem> - - <listitem> - <para>J. Hawk <email>jhawk@MIT.EDU</email></para> - </listitem> - - <listitem> - <para>J.T. Conklin <email>jtc@cygnus.com</email></para> - </listitem> - - <listitem> - <para>J.T. Jang <email>keith@email.gcn.net.tw</email></para> - </listitem> - - <listitem> - <para>Jack <email>jack@zeus.xtalwind.net</email></para> - </listitem> - - <listitem> - <para>Jacob Bohn Lorensen <email>jacob@jblhome.ping.mk</email></para> - </listitem> - - <listitem> - <para>Jagane D Sundar <email>jagane@netcom.com</email></para> - </listitem> - - <listitem> - <para>Jake Burkholder <email>jake@checker.org</email></para> - </listitem> - - <listitem> - <para>Jake Hamby <email>jehamby@lightside.com</email></para> - </listitem> - - <listitem> - <para>James Clark <email>jjc@jclark.com</email></para> - </listitem> - - <listitem> - <para>James D. Stewart <email>jds@c4systm.com</email></para> - </listitem> - - <listitem> - <para>James Jegers <email>jimj@miller.cs.uwm.edu</email></para> - </listitem> - - <listitem> - <para>James Raynard - <email>fhackers@jraynard.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>James T. Liu <email>jtliu@phlebas.rockefeller.edu</email></para> - </listitem> - - <listitem> - <para>James da Silva <email>jds@cs.umd.edu</email></para> - </listitem> - - <listitem> - <para>Jan Conard - <email>charly@fachschaften.tu-muenchen.de</email></para> - </listitem> - - <listitem> - <para>Jan Koum <email>jkb@FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Janick Taillandier - <email>Janick.Taillandier@ratp.fr</email></para> - </listitem> - - <listitem> - <para>Janusz Kokot <email>janek@gaja.ipan.lublin.pl</email></para> - </listitem> - - <listitem> - <para>Jarle Greipsland <email>jarle@idt.unit.no</email></para> - </listitem> - - <listitem> - <para>Jason Garman <email>init@risen.org</email></para> - </listitem> - - <listitem> - <para>Jason Thorpe <email>thorpej@NetBSD.org</email></para> - </listitem> - - <listitem> - <para>Jason Wright <email>jason@OpenBSD.org</email></para> - </listitem> - - <listitem> - <para>Jason Young - <email>doogie@forbidden-donut.anet-stl.com</email></para> - </listitem> - - <listitem> - <para>Javier Martin Rueda <email>jmrueda@diatel.upm.es</email></para> - </listitem> - - <listitem> - <para>Jay Fenlason <email>hack@datacube.com</email></para> - </listitem> - - <listitem> - <para>Jaye Mathisen <email>mrcpu@cdsnet.net</email></para> - </listitem> - - <listitem> - <para>Jeff Bartig <email>jeffb@doit.wisc.edu</email></para> - </listitem> - - <listitem> - <para>Jeff Forys <email>jeff@forys.cranbury.nj.us</email></para> - </listitem> - - <listitem> - <para>Jeff Kletsky <email>Jeff@Wagsky.com</email></para> - </listitem> - - <listitem> - <para>Jeffrey Evans <email>evans@scnc.k12.mi.us</email></para> - </listitem> - - <listitem> - <para>Jeffrey Wheat <email>jeff@cetlink.net</email></para> - </listitem> - - <listitem> - <para>Jens Schweikhardt <email>schweikh@noc.dfn.d</email></para> - </listitem> - - <listitem> - <para>Jeremy Allison <email>jallison@whistle.com</email></para> - </listitem> - - <listitem> - <para>Jeremy Chatfield <email>jdc@xinside.com</email></para> - </listitem> - - <listitem> - <para>Jeremy Lea <email>reg@shale.csir.co.za</email></para> - </listitem> - - <listitem> - <para>Jeremy Prior <email>unknown</email></para> - </listitem> - - <listitem> - <para>Jeroen Ruigrok/Asmodai <email>asmodai@wxs.nl</email></para> - </listitem> - - <listitem> - <para>Jesse Rosenstock <email>jmr@ugcs.caltech.edu</email></para> - </listitem> - - <listitem> - <para>Jian-Da Li <email>jdli@csie.nctu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Jim Babb <email>babb@FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Jim Binkley <email>jrb@cs.pdx.edu</email></para> - </listitem> - - <listitem> - <para>Jim Carroll <email>jim@carroll.com</email></para> - </listitem> - - <listitem> - <para>Jim Flowers <email>jflowers@ezo.net</email></para> - </listitem> - - <listitem> - <para>Jim Leppek <email>jleppek@harris.com</email></para> - </listitem> - - <listitem> - <para>Jim Lowe <email>james@cs.uwm.edu</email></para> - </listitem> - - <listitem> - <para>Jim Mattson <email>jmattson@sonic.net</email></para> - </listitem> - - <listitem> - <para>Jim Mercer <email>jim@komodo.reptiles.org</email></para> - </listitem> - - <listitem> - <para>Jim Wilson <email>wilson@moria.cygnus.com</email></para> - </listitem> - - <listitem> - <para>Jimbo Bahooli - <email>griffin@blackhole.iceworld.org</email></para> - </listitem> - - <listitem> - <para>Jin Guojun <email>jin@george.lbl.gov</email></para> - </listitem> - - <listitem> - <para>Joachim Kuebart <email>unknown</email></para> - </listitem> - - <listitem> - <para>Joao Carlos Mendes Luis <email>jonny@jonny.eng.br</email></para> - </listitem> - - <listitem> - <para>Jochen Pohl <email>jpo.drs@sni.de</email></para> - </listitem> - - <listitem> - <para>Joe "Marcus" Clarke <email>marcus@miami.edu</email></para> - </listitem> - - <listitem> - <para>Joe Abley <email>jabley@clear.co.nz</email></para> - </listitem> - - <listitem> - <para>Joe Jih-Shian Lu <email>jslu@dns.ntu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Joe Orthoefer <email>j_orthoefer@tia.net</email></para> - </listitem> - - <listitem> - <para>Joe Traister <email>traister@mojozone.org</email></para> - </listitem> - - <listitem> - <para>Joel Faedi <email>Joel.Faedi@esial.u-nancy.fr</email></para> - </listitem> - - <listitem> - <para>Joel Ray Holveck <email>joelh@gnu.org</email></para> - </listitem> - - <listitem> - <para>Joel Sutton <email>sutton@aardvark.apana.org.au</email></para> - </listitem> - - <listitem> - <para>Johan Granlund <email>johan@granlund.nu</email></para> - </listitem> - - <listitem> - <para>Johan Karlsson <email>k@numeri.campus.luth.se</email></para> - </listitem> - - <listitem> - <para>Johan Larsson <email>johan@moon.campus.luth.se</email></para> - </listitem> - - <listitem> - <para>Johann Tonsing <email>jtonsing@mikom.csir.co.za</email></para> - </listitem> - - <listitem> - <para>Johannes Helander <email>unknown</email></para> - </listitem> - - <listitem> - <para>Johannes Stille <email>unknown</email></para> - </listitem> - - <listitem> - <para>John Baldwin <email>jobaldwi@vt.edu</email></para> - </listitem> - - <listitem> - <para>John Beckett <email>jbeckett@southern.edu</email></para> - </listitem> - - <listitem> - <para>John Beukema <email>jbeukema@hk.super.net</email></para> - </listitem> - - <listitem> - <para>John Brezak <email>unknown</email></para> - </listitem> - - <listitem> - <para>John Capo <email>jc@irbs.com</email></para> - </listitem> - - <listitem> - <para>John F. Woods <email>jfw@jfwhome.funhouse.com</email></para> - </listitem> - - <listitem> - <para>John Goerzen - <email>jgoerzen@alexanderwohl.complete.org</email></para> - </listitem> - - <listitem> - <para>John Hay <email>jhay@mikom.csir.co.za</email></para> - </listitem> - - <listitem> - <para>John Heidemann <email>johnh@isi.edu</email></para> - </listitem> - - <listitem> - <para>John Hood <email>cgull@owl.org</email></para> - </listitem> - - <listitem> - <para>John Kohl <email>unknown</email></para> - </listitem> - - <listitem> - <para>John Lind <email>john@starfire.mn.org</email></para> - </listitem> - - <listitem> - <para>John Mackin <email>john@physiol.su.oz.au</email></para> - </listitem> - - <listitem> - <para>John P <email>johnp@lodgenet.com</email></para> - </listitem> - - <listitem> - <para>John Perry <email>perry@vishnu.alias.net</email></para> - </listitem> - - <listitem> - <para>John Preisler <email>john@vapornet.com</email></para> - </listitem> - - <listitem> - <para>John Rochester <email>jr@cs.mun.ca</email></para> - </listitem> - - <listitem> - <para>John Sadler <email>john_sadler@alum.mit.edu</email></para> - </listitem> - - <listitem> - <para>John Saunders <email>john@pacer.nlc.net.au</email></para> - </listitem> - - <listitem> - <para>John W. DeBoskey <email>jwd@unx.sas.com</email></para> - </listitem> - - <listitem> - <para>John Wehle <email>john@feith.com</email></para> - </listitem> - - <listitem> - <para>John Woods <email>jfw@eddie.mit.edu</email></para> - </listitem> - - <listitem> - <para>Jon Morgan <email>morgan@terminus.trailblazer.com</email></para> - </listitem> - - <listitem> - <para>Jonathan H N Chin <email>jc254@newton.cam.ac.uk</email></para> - </listitem> - - <listitem> - <para>Jonathan Hanna - <email>jh@pc-21490.bc.rogers.wave.ca</email></para> - </listitem> - - <listitem> - <para>Jorge Goncalves <email>j@bug.fe.up.pt</email></para> - </listitem> - - <listitem> - <para>Jorge M. Goncalves <email>ee96199@tom.fe.up.pt</email></para> - </listitem> - - <listitem> - <para>Jos Backus <email>jbackus@plex.nl</email></para> - </listitem> - - <listitem> - <para>Jose M. Alcaide <email>jose@we.lc.ehu.es</email></para> - </listitem> - - <listitem> - <para>Jose Marques <email>jose@nobody.org</email></para> - </listitem> - - <listitem> - <para>Josef Grosch - <email>jgrosch@superior.mooseriver.com</email></para> - </listitem> - - <listitem> - <para>Josef Karthauser <email>joe@uk.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Joseph Stein <email>joes@wstein.com</email></para> - </listitem> - - <listitem> - <para>Josh Gilliam <email>josh@quick.net</email></para> - </listitem> - - <listitem> - <para>Josh Tiefenbach <email>josh@ican.net</email></para> - </listitem> - - <listitem> - <para>Juergen Lock <email>nox@jelal.hb.north.de</email></para> - </listitem> - - <listitem> - <para>Juha Inkari <email>inkari@cc.hut.fi</email></para> - </listitem> - - <listitem> - <para>Jukka A. Ukkonen <email>jua@iki.fi</email></para> - </listitem> - - <listitem> - <para>Julian Assange <email>proff@suburbia.net</email></para> - </listitem> - - <listitem> - <para>Julian Coleman <email>j.d.coleman@ncl.ac.uk</email></para> - </listitem> - - <listitem> - <para>&a.jhs</para> - </listitem> - - <listitem> - <para>Julian Jenkins <email>kaveman@magna.com.au</email></para> - </listitem> - - <listitem> - <para>Junichi Satoh <email>junichi@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Junji SAKAI <email>sakai@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Junya WATANABE <email>junya-w@remus.dti.ne.jp</email></para> - </listitem> - - <listitem> - <para>K.Higashino <email>a00303@cc.hc.keio.ac.jp</email></para> - </listitem> - - <listitem> - <para>KUNISHIMA Takeo <email>kunishi@c.oka-pu.ac.jp</email></para> - </listitem> - - <listitem> - <para>Kai Vorma <email>vode@snakemail.hut.fi</email></para> - </listitem> - - <listitem> - <para>Kaleb S. Keithley <email>kaleb@ics.com</email></para> - </listitem> - - <listitem> - <para>Kaneda Hiloshi <email>vanitas@ma3.seikyou.ne.jp</email></para> - </listitem> - - <listitem> - <para>Kapil Chowksey <email>kchowksey@hss.hns.com</email></para> - </listitem> - - <listitem> - <para>Karl Denninger <email>karl@mcs.com</email></para> - </listitem> - - <listitem> - <para>Karl Dietz <email>Karl.Dietz@triplan.com</email></para> - </listitem> - - <listitem> - <para>Karl Lehenbauer <email>karl@NeoSoft.com</email></para> - </listitem> - - <listitem> - <para>Kato Takenori - <email>kato@eclogite.eps.nagoya-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Kawanobe Koh <email>kawanobe@st.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Kazuhiko Kiriyama <email>kiri@kiri.toba-cmt.ac.jp</email></para> - </listitem> - - <listitem> - <para>Kazuo Horikawa <email>horikawa@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Kees Jan Koster <email>kjk1@ukc.ac.uk</email></para> - </listitem> - - <listitem> - <para>Keith Bostic <email>bostic@bostic.com</email></para> - </listitem> - - <listitem> - <para>Keith E. Walker <email>unknown</email></para> - </listitem> - - <listitem> - <para>Keith Moore <email>unknown</email></para> - </listitem> - - <listitem> - <para>Keith Sklower <email>unknown</email></para> - </listitem> - - <listitem> - <para>Kelly Yancey <email>kbyanc@posi.net</email></para> - </listitem> - - <listitem> - <para>Ken Hornstein <email>unknown</email></para> - </listitem> - - <listitem> - <para>Ken Key <email>key@cs.utk.edu</email></para> - </listitem> - - <listitem> - <para>Ken Mayer <email>kmayer@freegate.com</email></para> - </listitem> - - <listitem> - <para>Kenji Saito <email>marukun@mx2.nisiq.net</email></para> - </listitem> - - <listitem> - <para>Kenji Tomita <email>tommyk@da2.so-net.or.jp</email></para> - </listitem> - - <listitem> - <para>Kenneth Furge <email>kenneth.furge@us.endress.com</email></para> - </listitem> - - <listitem> - <para>Kenneth Monville <email>desmo@bandwidth.org</email></para> - </listitem> - - <listitem> - <para>Kenneth R. Westerback <email>krw@tcn.net</email></para> - </listitem> - - <listitem> - <para>Kenneth Stailey <email>kstailey@gnu.ai.mit.edu</email></para> - </listitem> - - <listitem> - <para>Kent Talarico <email>kent@shipwreck.tsoft.net</email></para> - </listitem> - - <listitem> - <para>Kent Vander Velden <email>graphix@iastate.edu</email></para> - </listitem> - - <listitem> - <para>Kentaro Inagaki <email>JBD01226@niftyserve.ne.jp</email></para> - </listitem> - - <listitem> - <para>Kevin Bracey <email>kbracey@art.acorn.co.uk</email></para> - </listitem> - - <listitem> - <para>Kevin Day <email>toasty@dragondata.com</email></para> - </listitem> - - <listitem> - <para>Kevin Lahey <email>kml@nas.nasa.gov</email></para> - </listitem> - - <listitem> - <para>Kevin Lo<email>kevlo@hello.com.tw</email></para> - </listitem> - - <listitem> - <para>Kevin Street <email>street@iname.com</email></para> - </listitem> - - <listitem> - <para>Kevin Van Maren <email>vanmaren@fast.cs.utah.edu</email></para> - </listitem> - - <listitem> - <para>Kiroh HARADA <email>kiroh@kh.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Klaus Klein <email>kleink@layla.inka.de</email></para> - </listitem> - - <listitem> - <para>Klaus-J. Wolf <email>Yanestra@t-online.de</email></para> - </listitem> - - <listitem> - <para>Koichi Sato <email>copan@ppp.fastnet.or.jp</email></para> - </listitem> - - <listitem> - <para>Kostya Lukin <email>lukin@okbmei.msk.su</email></para> - </listitem> - - <listitem> - <para>Kouichi Hirabayashi <email>kh@mogami-wire.co.jp</email></para> - </listitem> - - <listitem> - <para>Kurt D. Zeilenga <email>Kurt@Boolean.NET</email></para> - </listitem> - - <listitem> - <para>Kurt Olsen <email>kurto@tiny.mcs.usu.edu</email></para> - </listitem> - - <listitem> - <para>L. Jonas Olsson - <email>ljo@ljo-slip.DIALIN.CWRU.Edu</email></para> - </listitem> - - <listitem> - <para>Lars Köller - <email>Lars.Koeller@Uni-Bielefeld.DE</email></para> - </listitem> - - <listitem> - <para>Larry Altneu <email>larry@ALR.COM</email></para> - </listitem> - - <listitem> - <para>Laurence Lopez <email>lopez@mv.mv.com</email></para> - </listitem> - - <listitem> - <para>Lee Cremeans <email>lcremean@tidalwave.net</email></para> - </listitem> - - <listitem> - <para>Liang Tai-hwa - <email>avatar@www.mmlab.cse.yzu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Lon Willett <email>lon%softt.uucp@math.utah.edu</email></para> - </listitem> - - <listitem> - <para>Louis A. Mamakos <email>louie@TransSys.COM</email></para> - </listitem> - - <listitem> - <para>Louis Mamakos <email>loiue@TransSys.com</email></para> - </listitem> - - <listitem> - <para>Lucas James <email>Lucas.James@ldjpc.apana.org.au</email></para> - </listitem> - - <listitem> - <para>Lyndon Nerenberg <email>lyndon@orthanc.com</email></para> - </listitem> - - <listitem> - <para>M.C. Wong <email>unknown</email></para> - </listitem> - - <listitem> - <para>MANTANI Nobutaka <email>nobutaka@nobutaka.com</email></para> - </listitem> - - <listitem> - <para>MIHIRA Sanpei Yoshiro <email>sanpei@sanpei.org</email></para> - </listitem> - - <listitem> - <para>MITA Yoshio <email>mita@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>MITSUNAGA Noriaki - <email>mitchy@er.ams.eng.osaka-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>MOROHOSHI Akihiko <email>moro@race.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>Magnus Enbom <email>dot@tinto.campus.luth.se</email></para> - </listitem> - - <listitem> - <para>Mahesh Neelakanta <email>mahesh@gcomm.com</email></para> - </listitem> - - <listitem> - <para>Makoto MATSUSHITA <email>matusita@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Makoto WATANABE - <email>watanabe@zlab.phys.nagoya-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Malte Lance <email>malte.lance@gmx.net</email></para> - </listitem> - - <listitem> - <para>Manu Iyengar - <email>iyengar@grunthos.pscwa.psca.com</email></para> - </listitem> - - <listitem> - <para>Marc Frajola <email>marc@dev.com</email></para> - </listitem> - - <listitem> - <para>Marc Ramirez <email>mrami@mramirez.sy.yale.edu</email></para> - </listitem> - - <listitem> - <para>Marc Slemko <email>marcs@znep.com</email></para> - </listitem> - - <listitem> - <para>Marc van Kempen <email>wmbfmk@urc.tue.nl</email></para> - </listitem> - - <listitem> - <para>Marc van Woerkom <email>van.woerkom@netcologne.de</email></para> - </listitem> - - <listitem> - <para>Marcel Moolenaar <email>marcel@scc.nl</email></para> - </listitem> - - <listitem> - <para>Mario Sergio Fujikawa Ferreira - <email>lioux@gns.com.br</email></para> - </listitem> - - <listitem> - <para>Mark Andrews <email>unknown</email></para> - </listitem> - - <listitem> - <para>Mark Cammidge <email>mark@gmtunx.ee.uct.ac.za</email></para> - </listitem> - - <listitem> - <para>Mark Diekhans <email>markd@grizzly.com</email></para> - </listitem> - - <listitem> - <para>Mark Huizer <email>xaa@stack.nl</email></para> - </listitem> - - <listitem> - <para>Mark J. Taylor <email>mtaylor@cybernet.com</email></para> - </listitem> - - <listitem> - <para>Mark Krentel <email>krentel@rice.edu</email></para> - </listitem> - - <listitem> - <para>Mark Mayo <email>markm@vmunix.com</email></para> - </listitem> - - <listitem> - <para>Mark Thompson <email>thompson@tgsoft.com</email></para> - </listitem> - - <listitem> - <para>Mark Tinguely <email>tinguely@plains.nodak.edu</email></para> - </listitem> - - <listitem> - <para>Mark Treacy <email>unknown</email></para> - </listitem> - - <listitem> - <para>Mark Valentine <email>mark@linus.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>Martin Birgmeier</para> - </listitem> - - <listitem> - <para>Martin Ibert <email>mib@ppe.bb-data.de</email></para> - </listitem> - - <listitem> - <para>Martin Kammerhofer <email>dada@sbox.tu-graz.ac.at</email></para> - </listitem> - - <listitem> - <para>Martin Renters <email>martin@tdc.on.ca</email></para> - </listitem> - - <listitem> - <para>Martti Kuparinen - <email>martti.kuparinen@ericsson.com</email></para> - </listitem> - - <listitem> - <para>Masachika ISHIZUKA - <email>ishizuka@isis.min.ntt.jp</email></para> - </listitem> - - <listitem> - <para>Mas.TAKEMURA <email>unknown</email></para> - </listitem> - - <listitem> - <para>Masafumi NAKANE <email>max@wide.ad.jp</email></para> - </listitem> - - <listitem> - <para>Masahiro Sekiguchi - <email>seki@sysrap.cs.fujitsu.co.jp</email></para> - </listitem> - - <listitem> - <para>Masanobu Saitoh <email>msaitoh@spa.is.uec.ac.jp</email></para> - </listitem> - - <listitem> - <para>Masanori Kanaoka <email>kana@saijo.mke.mei.co.jp</email></para> - </listitem> - - <listitem> - <para>Masanori Kiriake <email>seiken@ARGV.AC</email></para> - </listitem> - - <listitem> - <para>Masatoshi TAMURA - <email>tamrin@shinzan.kuee.kyoto-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Mats Lofkvist <email>mal@algonet.se</email></para> - </listitem> - - <listitem> - <para>Matt Bartley <email>mbartley@lear35.cytex.com</email></para> - </listitem> - - <listitem> - <para>Matt Thomas <email>matt@3am-software.com</email></para> - </listitem> - - <listitem> - <para>Matt White <email>mwhite+@CMU.EDU</email></para> - </listitem> - - <listitem> - <para>Matthew C. Mead <email>mmead@Glock.COM</email></para> - </listitem> - - <listitem> - <para>Matthew Cashdollar <email>mattc@rfcnet.com</email></para> - </listitem> - - <listitem> - <para>Matthew Flatt <email>mflatt@cs.rice.edu</email></para> - </listitem> - - <listitem> - <para>Matthew Fuller <email>fullermd@futuresouth.com</email></para> - </listitem> - - <listitem> - <para>Matthew Stein <email>matt@bdd.net</email></para> - </listitem> - - <listitem> - <para>Matthias Pfaller <email>leo@dachau.marco.de</email></para> - </listitem> - - <listitem> - <para>Matthias Scheler <email>tron@netbsd.org</email></para> - </listitem> - - <listitem> - <para>Mattias Gronlund - <email>Mattias.Gronlund@sa.erisoft.se</email></para> - </listitem> - - <listitem> - <para>Mattias Pantzare <email>pantzer@ludd.luth.se</email></para> - </listitem> - - <listitem> - <para>Maurice Castro - <email>maurice@planet.serc.rmit.edu.au</email></para> - </listitem> - - <listitem> - <para>Max Euston <email>meuston@jmrodgers.com</email></para> - </listitem> - - <listitem> - <para>Max Khon <email>fjoe@husky.iclub.nsu.ru</email></para> - </listitem> - - <listitem> - <para>Maxim Bolotin <email>max@rsu.ru</email></para> - </listitem> - - <listitem> - <para>Maxim V. Sobolev <email>sobomax@altavista.net</email></para> - </listitem> - - <listitem> - <para>Micha Class - <email>michael_class@hpbbse.bbn.hp.com</email></para> - </listitem> - - <listitem> - <para>Michael Butler <email>imb@scgt.oz.au</email></para> - </listitem> - - <listitem> - <para>Michael Butschky <email>butsch@computi.erols.com</email></para> - </listitem> - - <listitem> - <para>Michael Clay <email>mclay@weareb.org</email></para> - </listitem> - - <listitem> - <para>Michael Elbel <email>me@FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Michael Galassi <email>nerd@percival.rain.com</email></para> - </listitem> - - <listitem> - <para>Michael Hancock <email>michaelh@cet.co.jp</email></para> - </listitem> - - <listitem> - <para>Michael Hohmuth <email>hohmuth@inf.tu-dresden.de</email></para> - </listitem> - - <listitem> - <para>Michael Perlman <email>canuck@caam.rice.edu</email></para> - </listitem> - - <listitem> - <para>Michael Petry <email>petry@netwolf.NetMasters.com</email></para> - </listitem> - - <listitem> - <para>Michael Reifenberger <email>root@totum.plaut.de</email></para> - </listitem> - - <listitem> - <para>Michael Sardo <email>jaeger16@yahoo.com</email></para> - </listitem> - - <listitem> - <para>Michael Searle <email>searle@longacre.demon.co.uk</email></para> - </listitem> - - <listitem> - <para>Michal Listos <email>mcl@Amnesiac.123.org</email></para> - </listitem> - - <listitem> - <para>Michio Karl Jinbo - <email>karl@marcer.nagaokaut.ac.jp</email></para> - </listitem> - - <listitem> - <para>Miguel Angel Sagreras - <email>msagre@cactus.fi.uba.ar</email></para> - </listitem> - - <listitem> - <para>Mihoko Tanaka <email>m_tonaka@pa.yokogawa.co.jp</email></para> - </listitem> - - <listitem> - <para>Mika Nystrom <email>mika@cs.caltech.edu</email></para> - </listitem> - - <listitem> - <para>Mikael Hybsch <email>micke@dynas.se</email></para> - </listitem> - - <listitem> - <para>Mikael Karpberg - <email>karpen@ocean.campus.luth.se</email></para> - </listitem> - - <listitem> - <para>Mike Del <email>repenting@hotmail.com</email></para> - </listitem> - - <listitem> - <para>Mike Durian <email>durian@plutotech.com</email></para> - </listitem> - - <listitem> - <para>Mike Durkin <email>mdurkin@tsoft.sf-bay.org</email></para> - </listitem> - - <listitem> - <para>Mike E. Matsnev <email>mike@azog.cs.msu.su</email></para> - </listitem> - - <listitem> - <para>Mike Evans <email>mevans@candle.com</email></para> - </listitem> - - <listitem> - <para>Mike Grupenhoff <email>kashmir@umiacs.umd.edu</email></para> - </listitem> - - <listitem> - <para>Mike Hibler <email>mike@marker.cs.utah.edu</email></para> - </listitem> - - <listitem> - <para>Mike Karels <email>unknown</email></para> - </listitem> - - <listitem> - <para>Mike McGaughey <email>mmcg@cs.monash.edu.au</email></para> - </listitem> - - <listitem> - <para>Mike Meyer <email>mwm@shiva.the-park.com</email></para> - </listitem> - - <listitem> - <para>Mike Mitchell <email>mitchell@ref.tfs.com</email></para> - </listitem> - - <listitem> - <para>Mike Murphy <email>mrm@alpharel.com</email></para> - </listitem> - - <listitem> - <para>Mike Peck <email>mike@binghamton.edu</email></para> - </listitem> - - <listitem> - <para>Mike Spengler <email>mks@msc.edu</email></para> - </listitem> - - <listitem> - <para>Mikhail A. Sokolov <email>mishania@demos.su</email></para> - </listitem> - - <listitem> - <para>Mikhail Teterin <email>mi@aldan.ziplink.net</email></para> - </listitem> - - <listitem> - <para>Ming-I Hseh <email>PA@FreeBSD.ee.Ntu.edu.TW</email></para> - </listitem> - - <listitem> - <para>Mitsuru IWASAKI <email>iwasaki@pc.jaring.my</email></para> - </listitem> - - <listitem> - <para>Mitsuru Yoshida <email>mitsuru@riken.go.jp</email></para> - </listitem> - - <listitem> - <para>Monte Mitzelfelt <email>monte@gonefishing.org</email></para> - </listitem> - - <listitem> - <para>Morgan Davis <email>root@io.cts.com</email></para> - </listitem> - - <listitem> - <para>Mostyn Lewis <email>mostyn@mrl.com</email></para> - </listitem> - - <listitem> - <para>Motomichi Matsuzaki <email>mzaki@e-mail.ne.jp</email></para> - </listitem> - - <listitem> - <para>Motoyuki Kasahara <email>m-kasahr@sra.co.jp</email></para> - </listitem> - - <listitem> - <para>Motoyuki Konno <email>motoyuki@snipe.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Murray Stokely <email>murray@cdrom.com</email></para> - </listitem> - - <listitem> - <para>N.G.Smith <email>ngs@sesame.hensa.ac.uk</email></para> - </listitem> - - <listitem> - <para>NAGAO Tadaaki <email>nagao@cs.titech.ac.jp</email></para> - </listitem> - - <listitem> - <para>NAKAJI Hiroyuki - <email>nakaji@tutrp.tut.ac.jp</email></para> - </listitem> - - <listitem> - <para>NAKAMURA Kazushi <email>nkazushi@highway.or.jp</email></para> - </listitem> - - <listitem> - <para>NAKAMURA Motonori - <email>motonori@econ.kyoto-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>NIIMI Satoshi <email>sa2c@and.or.jp</email></para> - </listitem> - - <listitem> - <para>NOKUBI Hirotaka <email>h-nokubi@yyy.or.jp</email></para> - </listitem> - - <listitem> - <para>Nadav Eiron <email>nadav@barcode.co.il</email></para> - </listitem> - - <listitem> - <para>Nanbor Wang <email>nw1@cs.wustl.edu</email></para> - </listitem> - - <listitem> - <para>Naofumi Honda - <email>honda@Kururu.math.sci.hokudai.ac.jp</email></para> - </listitem> - - <listitem> - <para>Naoki Hamada <email>nao@tom-yam.or.jp</email></para> - </listitem> - - <listitem> - <para>Narvi <email>narvi@haldjas.folklore.ee</email></para> - </listitem> - - <listitem> - <para>Nathan Ahlstrom <email>nrahlstr@winternet.com</email></para> - </listitem> - - <listitem> - <para>Nathan Dorfman <email>nathan@rtfm.net</email></para> - </listitem> - - <listitem> - <para>Neal Fachan <email>kneel@ishiboo.com</email></para> - </listitem> - - <listitem> - <para>Neil Blakey-Milner <email>nbm@rucus.ru.ac.za</email></para> - </listitem> - - <listitem> - <para>Niall Smart <email>rotel@indigo.ie</email></para> - </listitem> - - <listitem> - <para>Nick Barnes <email>Nick.Barnes@pobox.com</email></para> - </listitem> - - <listitem> - <para>Nick Handel <email>nhandel@NeoSoft.com</email></para> - </listitem> - - <listitem> - <para>Nick Hilliard <email>nick@foobar.org</email></para> - </listitem> - - <listitem> - <para>&a.nsayer;</para> - </listitem> - - <listitem> - <para>Nick Williams <email>njw@cs.city.ac.uk</email></para> - </listitem> - - <listitem> - <para>Nickolay N. Dudorov <email>nnd@itfs.nsk.su</email></para> - </listitem> - - <listitem> - <para>Niklas Hallqvist <email>niklas@filippa.appli.se</email></para> - </listitem> - - <listitem> - <para>Nisha Talagala <email>nisha@cs.berkeley.edu</email></para> - </listitem> - - <listitem> - <para>No Name <email>ZW6T-KND@j.asahi-net.or.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>adrian@virginia.edu</email></para> - </listitem> - - <listitem> - <para>No Name <email>alex@elvisti.kiev.ua</email></para> - </listitem> - - <listitem> - <para>No Name <email>anto@netscape.net</email></para> - </listitem> - - <listitem> - <para>No Name <email>bobson@egg.ics.nitch.ac.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>bovynf@awe.be</email></para> - </listitem> - - <listitem> - <para>No Name <email>burg@is.ge.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>chris@gnome.co.uk</email></para> - </listitem> - - <listitem> - <para>No Name <email>colsen@usa.net</email></para> - </listitem> - - <listitem> - <para>No Name <email>coredump@nervosa.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>dannyman@arh0300.urh.uiuc.edu</email></para> - </listitem> - - <listitem> - <para>No Name <email>davids@SECNET.COM</email></para> - </listitem> - - <listitem> - <para>No Name <email>derek@free.org</email></para> - </listitem> - - <listitem> - <para>No Name <email>devet@adv.IAEhv.nl</email></para> - </listitem> - - <listitem> - <para>No Name <email>djv@bedford.net</email></para> - </listitem> - - <listitem> - <para>No Name <email>dvv@sprint.net</email></para> - </listitem> - - <listitem> - <para>No Name <email>enami@ba2.so-net.or.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>flash@eru.tubank.msk.su</email></para> - </listitem> - - <listitem> - <para>No Name <email>flash@hway.ru</email></para> - </listitem> - - <listitem> - <para>No Name <email>fn@pain.csrv.uidaho.edu</email></para> - </listitem> - - <listitem> - <para>No Name <email>gclarkii@netport.neosoft.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>gordon@sheaky.lonestar.org</email></para> - </listitem> - - <listitem> - <para>No Name <email>graaf@iae.nl</email></para> - </listitem> - - <listitem> - <para>No Name <email>greg@greg.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>grossman@cygnus.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>gusw@fub46.zedat.fu-berlin.de</email></para> - </listitem> - - <listitem> - <para>No Name <email>hfir@math.rochester.edu</email></para> - </listitem> - - <listitem> - <para>No Name <email>hnokubi@yyy.or.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>iaint@css.tuu.utas.edu.au</email></para> - </listitem> - - <listitem> - <para>No Name <email>invis@visi.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>ishisone@sra.co.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>iverson@lionheart.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>jpt@magic.net</email></para> - </listitem> - - <listitem> - <para>No Name <email>junker@jazz.snu.ac.kr</email></para> - </listitem> - - <listitem> - <para>No Name <email>k-sugyou@ccs.mt.nec.co.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>kenji@reseau.toyonaka.osaka.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>kfurge@worldnet.att.net</email></para> - </listitem> - - <listitem> - <para>No Name <email>lh@aus.org</email></para> - </listitem> - - <listitem> - <para>No Name <email>lhecking@nmrc.ucc.ie</email></para> - </listitem> - - <listitem> - <para>No Name <email>mrgreen@mame.mu.oz.au</email></para> - </listitem> - - <listitem> - <para>No Name <email>nakagawa@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>No Name <email>ohki@gssm.otsuka.tsukuba.ac.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>owaki@st.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>pechter@shell.monmouth.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>pete@pelican.pelican.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>pritc003@maroon.tc.umn.edu</email></para> - </listitem> - - <listitem> - <para>No Name <email>risner@stdio.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>roman@rpd.univ.kiev.ua</email></para> - </listitem> - - <listitem> - <para>No Name <email>root@ns2.redline.ru</email></para> - </listitem> - - <listitem> - <para>No Name <email>root@uglabgw.ug.cs.sunysb.edu</email></para> - </listitem> - - <listitem> - <para>No Name <email>stephen.ma@jtec.com.au</email></para> - </listitem> - - <listitem> - <para>No Name <email>sumii@is.s.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>takas-su@is.aist-nara.ac.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>tamone@eig.unige.ch</email></para> - </listitem> - - <listitem> - <para>No Name <email>tjevans@raleigh.ibm.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>tony-o@iij.ad.jp amurai@spec.co.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>torii@tcd.hitachi.co.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>uenami@imasy.or.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>uhlar@netlab.sk</email></para> - </listitem> - - <listitem> - <para>No Name <email>vode@hut.fi</email></para> - </listitem> - - <listitem> - <para>No Name <email>wlloyd@mpd.ca</email></para> - </listitem> - - <listitem> - <para>No Name <email>wlr@furball.wellsfargo.com</email></para> - </listitem> - - <listitem> - <para>No Name <email>wmbfmk@urc.tue.nl</email></para> - </listitem> - - <listitem> - <para>No Name <email>yamagata@nwgpc.kek.jp</email></para> - </listitem> - - <listitem> - <para>No Name <email>ziggy@ryan.org</email></para> - </listitem> - - <listitem> - <para>Nobuhiro Yasutomi <email>nobu@psrc.isac.co.jp</email></para> - </listitem> - - <listitem> - <para>Nobuyuki Koganemaru - <email>kogane@koganemaru.co.jp</email></para> - </listitem> - - <listitem> - <para>Norio Suzuki <email>nosuzuki@e-mail.ne.jp</email></para> - </listitem> - - <listitem> - <para>Noritaka Ishizumi <email>graphite@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Noriyuki Soda <email>soda@sra.co.jp</email></para> - </listitem> - - <listitem> - <para>Oh Junseon <email>hollywar@mail.holywar.net</email></para> - </listitem> - - <listitem> - <para>Olaf Wagner <email>wagner@luthien.in-berlin.de</email></para> - </listitem> - - <listitem> - <para>Oleg Sharoiko <email>os@rsu.ru</email></para> - </listitem> - - <listitem> - <para>Oleg V. Volkov <email>rover@lglobus.ru</email></para> - </listitem> - - <listitem> - <para>Oliver Breuninger <email>ob@seicom.NET</email></para> - </listitem> - - <listitem> - <para>Oliver Friedrichs <email>oliver@secnet.com</email></para> - </listitem> - - <listitem> - <para>Oliver Fromme - <email>oliver.fromme@heim3.tu-clausthal.de</email></para> - </listitem> - - <listitem> - <para>Oliver Laumann - <email>net@informatik.uni-bremen.de</email></para> - </listitem> - - <listitem> - <para>Oliver Oberdorf <email>oly@world.std.com</email></para> - </listitem> - - <listitem> - <para>Olof Johansson <email>offe@ludd.luth.se</email></para> - </listitem> - - <listitem> - <para>Osokin Sergey aka oZZ <email>ozz@FreeBSD.org.ru</email></para> - </listitem> - - <listitem> - <para>Pace Willisson <email>pace@blitz.com</email></para> - </listitem> - - <listitem> - <para>Paco Rosich <email>rosich@modico.eleinf.uv.es</email></para> - </listitem> - - <listitem> - <para>Palle Girgensohn <email>girgen@partitur.se</email></para> - </listitem> - - <listitem> - <para>Parag Patel <email>parag@cgt.com</email></para> - </listitem> - - <listitem> - <para>Pascal Pederiva <email>pascal@zuo.dec.com</email></para> - </listitem> - - <listitem> - <para>Pasvorn Boonmark <email>boonmark@juniper.net</email></para> - </listitem> - - <listitem> - <para>Patrick Gardella <email>patrick@cre8tivegroup.com</email></para> - </listitem> - - <listitem> - <para>Patrick Hausen <email>unknown</email></para> - </listitem> - - <listitem> - <para>Paul Antonov <email>apg@demos.su</email></para> - </listitem> - - <listitem> - <para>Paul F. Werkowski <email>unknown</email></para> - </listitem> - - <listitem> - <para>Paul Fox <email>pgf@foxharp.boston.ma.us</email></para> - </listitem> - - <listitem> - <para>Paul Koch <email>koch@thehub.com.au</email></para> - </listitem> - - <listitem> - <para>Paul Kranenburg <email>pk@NetBSD.org</email></para> - </listitem> - - <listitem> - <para>Paul Mackerras <email>paulus@cs.anu.edu.au</email></para> - </listitem> - - <listitem> - <para>Paul Popelka <email>paulp@uts.amdahl.com</email></para> - </listitem> - - <listitem> - <para>Paul S. LaFollette, Jr. <email>unknown</email></para> - </listitem> - - <listitem> - <para>Paul Saab <email>paul@mu.org</email></para> - </listitem> - - <listitem> - <para>Paul Sandys <email>myj@nyct.net</email></para> - </listitem> - - <listitem> - <para>Paul T. Root <email>proot@horton.iaces.com</email></para> - </listitem> - - <listitem> - <para>Paul Vixie <email>paul@vix.com</email></para> - </listitem> - - <listitem> - <para>Paulo Menezes <email>paulo@isr.uc.pt</email></para> - </listitem> - - <listitem> - <para>Paulo Menezes <email>pm@dee.uc.pt</email></para> - </listitem> - - <listitem> - <para>Pedro A M Vazquez <email>vazquez@IQM.Unicamp.BR</email></para> - </listitem> - - <listitem> - <para>Pedro Giffuni <email>giffunip@asme.org</email></para> - </listitem> - - <listitem> - <para>Pete Bentley <email>pete@demon.net</email></para> - </listitem> - - <listitem> - <para>Peter Childs <email>pjchilds@imforei.apana.org.au</email></para> - </listitem> - - <listitem> - <para>Peter Cornelius <email>pc@inr.fzk.de</email></para> - </listitem> - - <listitem> - <para>Peter Haight <email>peterh@prognet.com</email></para> - </listitem> - - <listitem> - <para>Peter Jeremy <email>perer.jeremy@alcatel.com.au</email></para> - </listitem> - - <listitem> - <para>Peter M. Chen <email>pmchen@eecs.umich.edu</email></para> - </listitem> - - <listitem> - <para>Peter Much <email>peter@citylink.dinoex.sub.org</email></para> - </listitem> - - <listitem> - <para>Peter Olsson <email>unknown</email></para> - </listitem> - - <listitem> - <para>Peter Philipp <email>pjp@bsd-daemon.net</email></para> - </listitem> - - <listitem> - <para>Peter Stubbs <email>PETERS@staidan.qld.edu.au</email></para> - </listitem> - - <listitem> - <para>Phil Maker <email>pjm@cs.ntu.edu.au</email></para> - </listitem> - - <listitem> - <para>Phil Sutherland - <email>philsuth@mycroft.dialix.oz.au</email></para> - </listitem> - - <listitem> - <para>Phil Taylor <email>phil@zipmail.co.uk</email></para> - </listitem> - - <listitem> - <para>Philip Musumeci <email>philip@rmit.edu.au</email></para> - </listitem> - - <listitem> - <para>Pierre Y. Dampure <email>pierre.dampure@k2c.co.uk</email></para> - </listitem> - - <listitem> - <para>Pius Fischer <email>pius@ienet.com</email></para> - </listitem> - - <listitem> - <para>Pomegranate <email>daver@flag.blackened.net</email></para> - </listitem> - - <listitem> - <para>Powerdog Industries - <email>kevin.ruddy@powerdog.com</email></para> - </listitem> - - <listitem> - <para>R. Kym Horsell</para> - </listitem> - - <listitem> - <para>Rajesh Vaidheeswarran <email>rv@fore.com</email></para> - </listitem> - - <listitem> - <para>Ralf Friedl <email>friedl@informatik.uni-kl.de</email></para> - </listitem> - - <listitem> - <para>Randal S. Masutani <email>randal@comtest.com</email></para> - </listitem> - - <listitem> - <para>Randall Hopper <email>rhh@ct.picker.com</email></para> - </listitem> - - <listitem> - <para>Randall W. Dean <email>rwd@osf.org</email></para> - </listitem> - - <listitem> - <para>Randy Bush <email>rbush@bainbridge.verio.net</email></para> - </listitem> - - <listitem> - <para>Reinier Bezuidenhout - <email>rbezuide@mikom.csir.co.za</email></para> - </listitem> - - <listitem> - <para>Remy Card <email>Remy.Card@masi.ibp.fr</email></para> - </listitem> - - <listitem> - <para>Ricardas Cepas <email>rch@richard.eu.org</email></para> - </listitem> - - <listitem> - <para>Riccardo Veraldi <email>veraldi@cs.unibo.it</email></para> - </listitem> - - <listitem> - <para>Richard Henderson <email>richard@atheist.tamu.edu</email></para> - </listitem> - - <listitem> - <para>Richard Hwang <email>rhwang@bigpanda.com</email></para> - </listitem> - - <listitem> - <para>Richard Kiss <email>richard@homemail.com</email></para> - </listitem> - - <listitem> - <para>Richard J Kuhns <email>rjk@watson.grauel.com</email></para> - </listitem> - - <listitem> - <para>Richard M. Neswold - <email>rneswold@drmemory.fnal.gov</email></para> - </listitem> - - <listitem> - <para>Richard Seaman, Jr. <email>dick@tar.com</email></para> - </listitem> - - <listitem> - <para>Richard Stallman <email>rms@gnu.ai.mit.edu</email></para> - </listitem> - - <listitem> - <para>Richard Straka <email>straka@user1.inficad.com</email></para> - </listitem> - - <listitem> - <para>Richard Tobin <email>richard@cogsci.ed.ac.uk</email></para> - </listitem> - - <listitem> - <para>Richard Wackerbarth <email>rkw@Dataplex.NET</email></para> - </listitem> - - <listitem> - <para>Richard Winkel <email>rich@math.missouri.edu</email></para> - </listitem> - - <listitem> - <para>Richard Wiwatowski <email>rjwiwat@adelaide.on.net</email></para> - </listitem> - - <listitem> - <para>Rick Macklem <email>rick@snowhite.cis.uoguelph.ca</email></para> - </listitem> - - <listitem> - <para>Rick Macklin <email>unknown</email></para> - </listitem> - - <listitem> - <para>Rob Austein <email>sra@epilogue.com</email></para> - </listitem> - - <listitem> - <para>Rob Mallory <email>rmallory@qualcomm.com</email></para> - </listitem> - - <listitem> - <para>Rob Snow <email>rsnow@txdirect.net</email></para> - </listitem> - - <listitem> - <para>Robert Crowe <email>bob@speakez.com</email></para> - </listitem> - - <listitem> - <para>Robert D. Thrush <email>rd@phoenix.aii.com</email></para> - </listitem> - - <listitem> - <para>Robert Eckardt - <email>roberte@MEP.Ruhr-Uni-Bochum.de</email></para> - </listitem> - - <listitem> - <para>Robert Sanders <email>rsanders@mindspring.com</email></para> - </listitem> - - <listitem> - <para>Robert Sexton <email>robert@kudra.com</email></para> - </listitem> - - <listitem> - <para>Robert Shady <email>rls@id.net</email></para> - </listitem> - - <listitem> - <para>Robert Swindells <email>swindellsr@genrad.co.uk</email></para> - </listitem> - - <listitem> - <para>Robert Watson <email>robert@cyrus.watson.org</email></para> - </listitem> - - <listitem> - <para>Robert Withrow <email>witr@rwwa.com</email></para> - </listitem> - - <listitem> - <para>Robert Yoder <email>unknown</email></para> - </listitem> - - <listitem> - <para>Robin Carey - <email>robin@mailgate.dtc.rankxerox.co.uk</email></para> - </listitem> - - <listitem> - <para>Roger Hardiman <email>roger@cs.strath.ac.uk</email></para> - </listitem> - - <listitem> - <para>Roland Jesse <email>jesse@cs.uni-magdeburg.de</email></para> - </listitem> - - <listitem> - <para>Ron Bickers <email>rbickers@intercenter.net</email></para> - </listitem> - - <listitem> - <para>Ron Lenk <email>rlenk@widget.xmission.com</email></para> - </listitem> - - <listitem> - <para>Ronald Kuehn <email>kuehn@rz.tu-clausthal.de</email></para> - </listitem> - - <listitem> - <para>Rudolf Cejka <email>unknown</email></para> - </listitem> - - <listitem> - <para>Ruslan Belkin <email>rus@home2.UA.net</email></para> - </listitem> - - <listitem> - <para>Ruslan Ermilov <email>ru@ucb.crimea.ua</email></para> - </listitem> - - <listitem> - <para>Ruslan Shevchenko <email>rssh@cam.grad.kiev.ua</email></para> - </listitem> - - <listitem> - <para>Russell L. Carter <email>rcarter@pinyon.org</email></para> - </listitem> - - <listitem> - <para>Russell Vincent <email>rv@groa.uct.ac.za</email></para> - </listitem> - - <listitem> - <para>Ryan Younce <email>ryany@pobox.com</email></para> - </listitem> - - <listitem> - <para>Ryuichiro IMURA <email>imura@cs.titech.ac.jp</email></para> - </listitem> - - <listitem> - <para>SANETO Takanori <email>sanewo@strg.sony.co.jp</email></para> - </listitem> - - <listitem> - <para>SAWADA Mizuki <email>miz@qb3.so-net.ne.jp</email></para> - </listitem> - - <listitem> - <para>SUGIMURA Takashi <email>sugimura@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>SURANYI Peter - <email>suranyip@jks.is.tsukuba.ac.jp</email></para> - </listitem> - - <listitem> - <para>Sakai Hiroaki <email>sakai@miya.ee.kagu.sut.ac.jp</email></para> - </listitem> - - <listitem> - <para>Sakari Jalovaara <email>sja@tekla.fi</email></para> - </listitem> - - <listitem> - <para>Sam Hartman <email>hartmans@mit.edu</email></para> - </listitem> - - <listitem> - <para>Samuel Lam <email>skl@ScalableNetwork.com</email></para> - </listitem> - - <listitem> - <para>Samuele Zannoli <email>zannoli@cs.unibo.it</email></para> - </listitem> - - <listitem> - <para>Sander Vesik <email>sander@haldjas.folklore.ee</email></para> - </listitem> - - <listitem> - <para>Sandro Sigala <email>ssigala@globalnet.it</email></para> - </listitem> - - <listitem> - <para>Sascha Blank <email>blank@fox.uni-trier.de</email></para> - </listitem> - - <listitem> - <para>Sascha Wildner <email>swildner@channelz.GUN.de</email></para> - </listitem> - - <listitem> - <para>Satoh Junichi <email>junichi@astec.co.jp</email></para> - </listitem> - - <listitem> - <para>Scot Elliott <email>scot@poptart.org</email></para> - </listitem> - - <listitem> - <para>Scot W. Hetzel <email>hetzels@westbend.net</email></para> - </listitem> - - <listitem> - <para>Scott A. Kenney <email>saken@rmta.ml.org</email></para> - </listitem> - - <listitem> - <para>Scott Blachowicz - <email>scott.blachowicz@seaslug.org</email></para> - </listitem> - - <listitem> - <para>Scott Burris <email>scott@pita.cns.ucla.edu</email></para> - </listitem> - - <listitem> - <para>Scott Hazen Mueller <email>scott@zorch.sf-bay.org</email></para> - </listitem> - - <listitem> - <para>Scott Michel <email>scottm@cs.ucla.edu</email></para> - </listitem> - - <listitem> - <para>Scott Mitchel <email>scott@uk.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Scott Reynolds <email>scott@clmqt.marquette.mi.us</email></para> - </listitem> - - <listitem> - <para>Sebastian Strollo <email>seb@erix.ericsson.se</email></para> - </listitem> - - <listitem> - <para>Serge A. Babkin <email>babkin@hq.icb.chel.su</email></para> - </listitem> - - <listitem> - <para>Serge V. Vakulenko <email>vak@zebub.msk.su</email></para> - </listitem> - - <listitem> - <para>Sergei Chechetkin - <email>csl@whale.sunbay.crimea.ua</email></para> - </listitem> - - <listitem> - <para>Sergei S. Laskavy <email>laskavy@pc759.cs.msu.su</email></para> - </listitem> - - <listitem> - <para>Sergey Gershtein <email>sg@mplik.ru</email></para> - </listitem> - - <listitem> - <para>Sergey Kosyakov <email>ks@itp.ac.ru</email></para> - </listitem> - - <listitem> - <para>Sergey Potapov <email>sp@alkor.ru</email></para> - </listitem> - - <listitem> - <para>Sergey Shkonda <email>serg@bcs.zp.ua</email></para> - </listitem> - - <listitem> - <para>Sergey V.Dorokhov <email>svd@kbtelecom.nalnet.ru</email></para> - </listitem> - - <listitem> - <para>Sergio Lenzi <email>lenzi@bsi.com.br</email></para> - </listitem> - - <listitem> - <para>Shaun Courtney <email>shaun@emma.eng.uct.ac.za</email></para> - </listitem> - - <listitem> - <para>Shawn M. Carey <email>smcarey@mailbox.syr.edu</email></para> - </listitem> - - <listitem> - <para>Shigio Yamaguchi <email>shigio@tamacom.com</email></para> - </listitem> - - <listitem> - <para>Shinya Esu <email>esu@yk.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Shuichi Tanaka <email>stanaka@bb.mbn.or.jp</email></para> - </listitem> - - <listitem> - <para>Shunsuke Akiyama <email>akiyama@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Simon <email>simon@masi.ibp.fr</email></para> - </listitem> - - <listitem> - <para>Simon Burge <email>simonb@telstra.com.au</email></para> - </listitem> - - <listitem> - <para>Simon J Gerraty <email>sjg@melb.bull.oz.au</email></para> - </listitem> - - <listitem> - <para>Simon Marlow <email>simonm@dcs.gla.ac.uk</email></para> - </listitem> - - <listitem> - <para>Simon Shapiro <email>shimon@simon-shapiro.org</email></para> - </listitem> - - <listitem> - <para>Sin'ichiro MIYATANI <email>siu@phaseone.co.jp</email></para> - </listitem> - - <listitem> - <para>Slaven Rezic <email>eserte@cs.tu-berlin.de</email></para> - </listitem> - - <listitem> - <para>Soochon Radee <email>slr@mitre.org</email></para> - </listitem> - - <listitem> - <para>Soren Dayton <email>csdayton@midway.uchicago.edu</email></para> - </listitem> - - <listitem> - <para>Soren Dossing <email>sauber@netcom.com</email></para> - </listitem> - - <listitem> - <para>Soren S. Jorvang <email>soren@dt.dk</email></para> - </listitem> - - <listitem> - <para>Stefan Bethke <email>stb@hanse.de</email></para> - </listitem> - - <listitem> - <para>Stefan Eggers <email>seggers@semyam.dinoco.de</email></para> - </listitem> - - <listitem> - <para>Stefan Moeding <email>s.moeding@ndh.net</email></para> - </listitem> - - <listitem> - <para>Stefan Petri <email>unknown</email></para> - </listitem> - - <listitem> - <para>Stefan `Sec` Zehl <email>sec@42.org</email></para> - </listitem> - - <listitem> - <para>Steinar Haug <email>sthaug@nethelp.no</email></para> - </listitem> - - <listitem> - <para>Stephane E. Potvin <email>sepotvin@videotron.ca</email></para> - </listitem> - - <listitem> - <para>Stephane Legrand <email>stephane@lituus.fr</email></para> - </listitem> - - <listitem> - <para>Stephen Clawson - <email>sclawson@marker.cs.utah.edu</email></para> - </listitem> - - <listitem> - <para>Stephen F. Combs <email>combssf@salem.ge.com</email></para> - </listitem> - - <listitem> - <para>Stephen Farrell <email>stephen@farrell.org</email></para> - </listitem> - - <listitem> - <para>Stephen Hocking <email>sysseh@devetir.qld.gov.au</email></para> - </listitem> - - <listitem> - <para>Stephen J. Roznowski <email>sjr@home.net</email></para> - </listitem> - - <listitem> - <para>Stephen McKay <email>syssgm@devetir.qld.gov.au</email></para> - </listitem> - - <listitem> - <para>Stephen Melvin <email>melvin@zytek.com</email></para> - </listitem> - - <listitem> - <para>Steve Bauer <email>sbauer@rock.sdsmt.edu</email></para> - </listitem> - - <listitem> - <para>Steve Coltrin <email>spcoltri@io.com</email></para> - </listitem> - - <listitem> - <para>Steve Deering <email>unknown</email></para> - </listitem> - - <listitem> - <para>Steve Gerakines <email>steve2@genesis.tiac.net</email></para> - </listitem> - - <listitem> - <para>Steve Gericke <email>steveg@comtrol.com</email></para> - </listitem> - - <listitem> - <para>Steve Piette <email>steve@simon.chi.il.US</email></para> - </listitem> - - <listitem> - <para>Steve Schwarz <email>schwarz@alpharel.com</email></para> - </listitem> - - <listitem> - <para>Steven G. Kargl - <email>kargl@troutmask.apl.washington.edu</email></para> - </listitem> - - <listitem> - <para>Steven H. Samorodin <email>samorodi@NUXI.com</email></para> - </listitem> - - <listitem> - <para>Steven McCanne <email>mccanne@cs.berkeley.edu</email></para> - </listitem> - - <listitem> - <para>Steven Plite <email>splite@purdue.edu</email></para> - </listitem> - - <listitem> - <para>Steven Wallace <email>unknown</email></para> - </listitem> - - <listitem> - <para>Stuart Henderson - <email>stuart@internationalschool.co.uk</email></para> - </listitem> - - <listitem> - <para>Sue Blake <email>sue@welearn.com.au</email></para> - </listitem> - - <listitem> - <para>Sugimoto Sadahiro <email>ixtl@komaba.utmc.or.jp</email></para> - </listitem> - - <listitem> - <para>Sugiura Shiro <email>ssugiura@duo.co.jp</email></para> - </listitem> - - <listitem> - <para>Sujal Patel <email>smpatel@wam.umd.edu</email></para> - </listitem> - - <listitem> - <para>Sune Stjerneby <email>stjerneby@usa.net</email></para> - </listitem> - - <listitem> - <para>Suzuki Yoshiaki - <email>zensyo@ann.tama.kawasaki.jp</email></para> - </listitem> - - <listitem> - <para>Tadashi Kumano <email>kumano@strl.nhk.or.jp</email></para> - </listitem> - - <listitem> - <para>Taguchi Takeshi <email>taguchi@tohoku.iij.ad.jp</email></para> - </listitem> - - <listitem> - <para>Takahiro Yugawa <email>yugawa@orleans.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Takanori Watanabe - <email>takawata@shidahara1.planet.sci.kobe-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takashi Mega <email>mega@minz.org</email></para> - </listitem> - - <listitem> - <para>Takashi Uozu <email>j1594016@ed.kagu.sut.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takayuki Ariga <email>a00821@cc.hc.keio.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takeru NAIKI <email>naiki@bfd.es.hokudai.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takeshi Amaike <email>amaike@iri.co.jp</email></para> - </listitem> - - <listitem> - <para>Takeshi MUTOH <email>mutoh@info.nara-k.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takeshi Ohashi - <email>ohashi@mickey.ai.kyutech.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takeshi WATANABE - <email>watanabe@crayon.earth.s.kobe-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Takuya SHIOZAKI - <email>tshiozak@makino.ise.chuo-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Tatoku Ogaito <email>tacha@tera.fukui-med.ac.jp</email></para> - </listitem> - - <listitem> - <para>Tatsumi HOSOKAWA <email>hosokawa@jp.FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Ted Buswell <email>tbuswell@mediaone.net</email></para> - </listitem> - - <listitem> - <para>Ted Faber <email>faber@isi.edu</email></para> - </listitem> - - <listitem> - <para>Ted Lemon <email>mellon@isc.org</email></para> - </listitem> - - <listitem> - <para>Terry Lambert <email>terry@lambert.org</email></para> - </listitem> - - <listitem> - <para>Terry Lee <email>terry@uivlsi.csl.uiuc.edu</email></para> - </listitem> - - <listitem> - <para>Tetsuya Furukawa <email>tetsuya@secom-sis.co.jp</email></para> - </listitem> - - <listitem> - <para>Theo de Raadt <email>deraadt@OpenBSD.org</email></para> - </listitem> - - <listitem> - <para>Thomas <email>thomas@mathematik.uni-Bremen.de</email></para> - </listitem> - - <listitem> - <para>Thomas D. Dean <email>tomdean@ix.netcom.com</email></para> - </listitem> - - <listitem> - <para>Thomas David Rivers <email>rivers@dignus.com</email></para> - </listitem> - - <listitem> - <para>Thomas G. McWilliams <email>tgm@netcom.com</email></para> - </listitem> - - <listitem> - <para>Thomas Gellekum - <email>thomas@ghpc8.ihf.rwth-aachen.de</email></para> - </listitem> - - <listitem> - <para>Thomas Graichen - <email>graichen@omega.physik.fu-berlin.de</email></para> - </listitem> - - <listitem> - <para>Thomas König - <email>Thomas.Koenig@ciw.uni-karlsruhe.de</email></para> - </listitem> - - <listitem> - <para>Thomas Ptacek <email>unknown</email></para> - </listitem> - - <listitem> - <para>Thomas A. Stephens <email>tas@stephens.org</email></para> - </listitem> - - <listitem> - <para>Thomas Stromberg <email>tstrombe@rtci.com</email></para> - </listitem> - - <listitem> - <para>Thomas Valentino Crimi - <email>tcrimi+@andrew.cmu.edu</email></para> - </listitem> - - <listitem> - <para>Thomas Wintergerst <email>thomas@lemur.nord.de</email></para> - </listitem> - - <listitem> - <para>Þórður Ívarsson - <email>totii@est.is</email></para> - </listitem> - - <listitem> - <para>Tim Kientzle <email>kientzle@netcom.com</email></para> - </listitem> - - <listitem> - <para>Tim Singletary - <email>tsingle@sunland.gsfc.nasa.gov</email></para> - </listitem> - - <listitem> - <para>Tim Wilkinson <email>tim@sarc.city.ac.uk</email></para> - </listitem> - - <listitem> - <para>Timo J. Rinne <email>tri@iki.fi</email></para> - </listitem> - - <listitem> - <para>Todd Miller <email>millert@openbsd.org</email></para> - </listitem> - - <listitem> - <para>Tom <email>root@majestix.cmr.no</email></para> - </listitem> - - <listitem> - <para>Tom <email>tom@sdf.com</email></para> - </listitem> - - <listitem> - <para>Tom Gray - DCA <email>dcasba@rain.org</email></para> - </listitem> - - <listitem> - <para>Tom Jobbins <email>tom@tom.tj</email></para> - </listitem> - - <listitem> - <para>Tom Pusateri <email>pusateri@juniper.net</email></para> - </listitem> - - <listitem> - <para>Tom Rush <email>tarush@mindspring.com</email></para> - </listitem> - - <listitem> - <para>Tom Samplonius <email>tom@misery.sdf.com</email></para> - </listitem> - - <listitem> - <para>Tomohiko Kurahashi - <email>kura@melchior.q.t.u-tokyo.ac.jp</email></para> - </listitem> - - <listitem> - <para>Tony Kimball <email>alk@Think.COM</email></para> - </listitem> - - <listitem> - <para>Tony Li <email>tli@jnx.com</email></para> - </listitem> - - <listitem> - <para>Tony Lynn <email>wing@cc.nsysu.edu.tw</email></para> - </listitem> - - <listitem> - <para>Tony Maher <email>tonym@angis.org.au</email></para> - </listitem> - - <listitem> - <para>Torbjorn Granlund <email>tege@matematik.su.se</email></para> - </listitem> - - <listitem> - <para>Toshihiko ARAI <email>toshi@tenchi.ne.jp</email></para> - </listitem> - - <listitem> - <para>Toshihiko SHIMOKAWA <email>toshi@tea.forus.or.jp</email></para> - </listitem> - - <listitem> - <para>Toshihiro Kanda <email>candy@kgc.co.jp</email></para> - </listitem> - - <listitem> - <para>Toshiomi Moriki - <email>Toshiomi.Moriki@ma1.seikyou.ne.jp</email></para> - </listitem> - - <listitem> - <para>Trefor S. <email>trefor@flevel.co.uk</email></para> - </listitem> - - <listitem> - <para>Trevor Blackwell <email>tlb@viaweb.com</email></para> - </listitem> - - <listitem> - <para>URATA Shuichiro <email>s-urata@nmit.tmg.nec.co.jp</email></para> - </listitem> - - <listitem> - <para>Udo Schweigert <email>ust@cert.siemens.de</email></para> - </listitem> - - <listitem> - <para>Ugo Paternostro <email>paterno@dsi.unifi.it</email></para> - </listitem> - - <listitem> - <para>Ulf Kieber <email>kieber@sax.de</email></para> - </listitem> - - <listitem> - <para>Ulli Linzen <email>ulli@perceval.camelot.de</email></para> - </listitem> - - <listitem> - <para>Ustimenko Semen <email>semen@iclub.nsu.ru</email></para> - </listitem> - - <listitem> - <para>Uwe Arndt <email>arndt@mailhost.uni-koblenz.de</email></para> - </listitem> - - <listitem> - <para>Vadim Chekan <email>vadim@gc.lviv.ua</email></para> - </listitem> - - <listitem> - <para>Vadim Kolontsov <email>vadim@tversu.ac.ru</email></para> - </listitem> - - <listitem> - <para>Vadim Mikhailov <email>mvp@braz.ru</email></para> - </listitem> - - <listitem> - <para>Van Jacobson <email>van@ee.lbl.gov</email></para> - </listitem> - - <listitem> - <para>Vasily V. Grechishnikov - <email>bazilio@ns1.ied-vorstu.ac.ru</email></para> - </listitem> - - <listitem> - <para>Vasim Valejev <email>vasim@uddias.diaspro.com</email></para> - </listitem> - - <listitem> - <para>Vernon J. Schryver <email>vjs@mica.denver.sgi.com</email></para> - </listitem> - - <listitem> - <para>Vic Abell <email>abe@cc.purdue.edu</email></para> - </listitem> - - <listitem> - <para>Ville Eerola <email>ve@sci.fi</email></para> - </listitem> - - <listitem> - <para>Vincent Poy <email>vince@venus.gaianet.net</email></para> - </listitem> - - <listitem> - <para>Vincenzo Capuano - <email>VCAPUANO@vmprofs.esoc.esa.de</email></para> - </listitem> - - <listitem> - <para>Virgil Champlin <email>champlin@pa.dec.com</email></para> - </listitem> - - <listitem> - <para>Vladimir A. Jakovenko - <email>vovik@ntu-kpi.kiev.ua</email></para> - </listitem> - - <listitem> - <para>Vladimir Kushnir <email>kushn@mail.kar.net</email></para> - </listitem> - - <listitem> - <para>Vsevolod Lobko <email>seva@alex-ua.com</email></para> - </listitem> - - <listitem> - <para>W. Gerald Hicks <email>wghicks@bellsouth.net</email></para> - </listitem> - - <listitem> - <para>W. Richard Stevens <email>rstevens@noao.edu</email></para> - </listitem> - - <listitem> - <para>Walt Howard <email>howard@ee.utah.edu</email></para> - </listitem> - - <listitem> - <para>Warren Toomey <email>wkt@csadfa.cs.adfa.oz.au</email></para> - </listitem> - - <listitem> - <para>Wayne Scott <email>wscott@ichips.intel.com</email></para> - </listitem> - - <listitem> - <para>Werner Griessl - <email>werner@btp1da.phy.uni-bayreuth.de</email></para> - </listitem> - - <listitem> - <para>Wes Santee <email>wsantee@wsantee.oz.net</email></para> - </listitem> - - <listitem> - <para>Wietse Venema <email>wietse@wzv.win.tue.nl</email></para> - </listitem> - - <listitem> - <para>Wilfredo Sanchez <email>wsanchez@apple.com</email></para> - </listitem> - - <listitem> - <para>Wiljo Heinen <email>wiljo@freeside.ki.open.de</email></para> - </listitem> - - <listitem> - <para>Wilko Bulte <email>wilko@yedi.iaf.nl</email></para> - </listitem> - - <listitem> - <para>Will Andrews <email>andrews@technologist.com</email></para> - </listitem> - - <listitem> - <para>Willem Jan Withagen <email>wjw@surf.IAE.nl</email></para> - </listitem> - - <listitem> - <para>William Jolitz <email>withheld</email></para> - </listitem> - - <listitem> - <para>William Liao <email>william@tale.net</email></para> - </listitem> - - <listitem> - <para>Wojtek Pilorz - <email>wpilorz@celebris.bdk.lublin.pl</email></para> - </listitem> - - <listitem> - <para>Wolfgang Helbig <email>helbig@ba-stuttgart.de</email></para> - </listitem> - - <listitem> - <para>Wolfgang Solfrank <email>ws@tools.de</email></para> - </listitem> - - <listitem> - <para>Wolfgang Stanglmeier <email>wolf@FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Wu Ching-hong <email>woju@FreeBSD.ee.Ntu.edu.TW</email></para> - </listitem> - - <listitem> - <para>Yarema <email>yds@ingress.com</email></para> - </listitem> - - <listitem> - <para>Yaroslav Terletsky <email>ts@polynet.lviv.ua</email></para> - </listitem> - - <listitem> - <para>Yasuhito FUTATSUKI <email>futatuki@fureai.or.jp</email></para> - </listitem> - - <listitem> - <para>Yasuhiro Fukama <email>yasuf@big.or.jp</email></para> - </listitem> - - <listitem> - <para>Yen-Shuo Su <email>yssu@CCCA.NCTU.edu.tw</email></para> - </listitem> - - <listitem> - <para>Ying-Chieh Liao <email>ijliao@csie.NCTU.edu.tw</email></para> - </listitem> - - <listitem> - <para>Yixin Jin <email>yjin@rain.cs.ucla.edu</email></para> - </listitem> - - <listitem> - <para>Yoshiaki Uchikawa <email>yoshiaki@kt.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Yoshihiko OHTA <email>yohta@bres.tsukuba.ac.jp</email></para> - </listitem> - - <listitem> - <para>Yoshihisa NAKAGAWA - <email>y-nakaga@ccs.mt.nec.co.jp</email></para> - </listitem> - - <listitem> - <para>Yoshikazu Goto <email>gotoh@ae.anritsu.co.jp</email></para> - </listitem> - - <listitem> - <para>Yoshimasa Ohnishi - <email>ohnishi@isc.kyutech.ac.jp</email></para> - </listitem> - - <listitem> - <para>Yoshishige Arai <email>ryo2@on.rim.or.jp</email></para> - </listitem> - - <listitem> - <para>Yuichi MATSUTAKA <email>matutaka@osa.att.ne.jp</email></para> - </listitem> - - <listitem> - <para>Yujiro MIYATA - <email>miyata@bioele.nuee.nagoya-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Yukihiro Nakai <email>nacai@iname.com</email></para> - </listitem> - - <listitem> - <para>Yusuke Nawano <email>azuki@azkey.org</email></para> - </listitem> - - <listitem> - <para>Yuu Yashiki <email>s974123@cc.matsuyama-u.ac.jp</email></para> - </listitem> - - <listitem> - <para>Yuval Yarom <email>yval@cs.huji.ac.il</email></para> - </listitem> - - <listitem> - <para>Yves Fonk <email>yves@cpcoup5.tn.tudelft.nl</email></para> - </listitem> - - <listitem> - <para>Yves Fonk <email>yves@dutncp8.tn.tudelft.nl</email></para> - </listitem> - - <listitem> - <para>Zach Heilig <email>zach@gaffaneys.com</email></para> - </listitem> - - <listitem> - <para>Zahemszhky Gabor <email>zgabor@code.hu</email></para> - </listitem> - - <listitem> - <para>Zhong Ming-Xun <email>zmx@mail.CDPA.nsysu.edu.tw</email></para> - </listitem> - - <listitem> - <para>arci <email>vega@sophia.inria.fr</email></para> - </listitem> - - <listitem> - <para>der Mouse <email>mouse@Collatz.McRCIM.McGill.EDU</email></para> - </listitem> - - <listitem> - <para>frf <email>frf@xocolatl.com</email></para> - </listitem> - - <listitem> - <para>Ege Rekk <email>aagero@aage.priv.no</email></para> - </listitem> - </itemizedlist> - </sect1> - - <sect1> - <title>386BSD Patch Kit Patch Contributors</title> - - <para>(in alphabetical order by first name):</para> - - <itemizedlist> - <listitem> - <para>Adam Glass <email>glass@postgres.berkeley.edu</email></para> - </listitem> - - <listitem> - <para>Adrian Hall <email>adrian@ibmpcug.co.uk</email></para> - </listitem> - - <listitem> - <para>Andrey A. Chernov <email>ache@astral.msk.su</email></para> - </listitem> - - <listitem> - <para>Andrew Herbert <email>andrew@werple.apana.org.au</email></para> - </listitem> - - <listitem> - <para>Andrew Moore <email>alm@netcom.com</email></para> - </listitem> - - <listitem> - <para>Andy Valencia <email>ajv@csd.mot.com</email> - <email>jtk@netcom.com</email></para> - </listitem> - - <listitem> - <para>Arne Henrik Juul <email>arnej@Lise.Unit.NO</email></para> - </listitem> - - <listitem> - <para>Bakul Shah <email>bvs@bitblocks.com</email></para> - </listitem> - - <listitem> - <para>Barry Lustig <email>barry@ictv.com</email></para> - </listitem> - - <listitem> - <para>Bob Wilcox <email>bob@obiwan.uucp</email></para> - </listitem> - - <listitem> - <para>Branko Lankester</para> - </listitem> - - <listitem> - <para>Brett Lymn <email>blymn@mulga.awadi.com.AU</email></para> - </listitem> - - <listitem> - <para>Charles Hannum <email>mycroft@ai.mit.edu</email></para> - </listitem> - - <listitem> - <para>Chris G. Demetriou - <email>cgd@postgres.berkeley.edu</email></para> - </listitem> - - <listitem> - <para>Chris Torek <email>torek@ee.lbl.gov</email></para> - </listitem> - - <listitem> - <para>Christoph Robitschko - <email>chmr@edvz.tu-graz.ac.at</email></para> - </listitem> - - <listitem> - <para>Daniel Poirot <email>poirot@aio.jsc.nasa.gov</email></para> - </listitem> - - <listitem> - <para>Dave Burgess <email>burgess@hrd769.brooks.af.mil</email></para> - </listitem> - - <listitem> - <para>Dave Rivers <email>rivers@ponds.uucp</email></para> - </listitem> - - <listitem> - <para>David Dawes <email>dawes@physics.su.OZ.AU</email></para> - </listitem> - - <listitem> - <para>David Greenman <email>dg@Root.COM</email></para> - </listitem> - - <listitem> - <para>Eric J. Haug <email>ejh@slustl.slu.edu</email></para> - </listitem> - - <listitem> - <para>Felix Gaehtgens - <email>felix@escape.vsse.in-berlin.de</email></para> - </listitem> - - <listitem> - <para>Frank Maclachlan <email>fpm@crash.cts.com</email></para> - </listitem> - - <listitem> - <para>Gary A. Browning <email>gab10@griffcd.amdahl.com</email></para> - </listitem> - - <listitem> - <para>Gary Howland <email>gary@hotlava.com</email></para> - </listitem> - - <listitem> - <para>Geoff Rehmet <email>csgr@alpha.ru.ac.za</email></para> - </listitem> - - <listitem> - <para>Goran Hammarback <email>goran@astro.uu.se</email></para> - </listitem> - - <listitem> - <para>Guido van Rooij <email>guido@gvr.org</email></para> - </listitem> - - <listitem> - <para>Guy Harris <email>guy@auspex.com</email></para> - </listitem> - - <listitem> - <para>Havard Eidnes - <email>Havard.Eidnes@runit.sintef.no</email></para> - </listitem> - - <listitem> - <para>Herb Peyerl <email>hpeyerl@novatel.cuc.ab.ca</email></para> - </listitem> - - <listitem> - <para>Holger Veit <email>Holger.Veit@gmd.de</email></para> - </listitem> - - <listitem> - <para>Ishii Masahiro, R. Kym Horsell</para> - </listitem> - - <listitem> - <para>J.T. Conklin <email>jtc@cygnus.com</email></para> - </listitem> - - <listitem> - <para>Jagane D Sundar <email>jagane@netcom.com</email></para> - </listitem> - - <listitem> - <para>James Clark <email>jjc@jclark.com</email></para> - </listitem> - - <listitem> - <para>James Jegers <email>jimj@miller.cs.uwm.edu</email></para> - </listitem> - - <listitem> - <para>James W. Dolter</para> - </listitem> - - <listitem> - <para>James da Silva <email>jds@cs.umd.edu</email> et al</para> - </listitem> - - <listitem> - <para>Jay Fenlason <email>hack@datacube.com</email></para> - </listitem> - - <listitem> - <para>Jim Wilson <email>wilson@moria.cygnus.com</email></para> - </listitem> - - <listitem> - <para>Jörg Lohse - <email>lohse@tech7.informatik.uni-hamburg.de</email></para> - </listitem> - - <listitem> - <para>Jörg Wunsch - <email>joerg_wunsch@uriah.heep.sax.de</email></para> - </listitem> - - <listitem> - <para>John Dyson</para> - </listitem> - - <listitem> - <para>John Woods <email>jfw@eddie.mit.edu</email></para> - </listitem> - - <listitem> - <para>Jordan K. Hubbard <email>jkh@whisker.hubbard.ie</email></para> - </listitem> - - <listitem> - <para>Julian Elischer <email>julian@dialix.oz.au</email></para> - </listitem> - - <listitem> - <para>Julian Stacey <email>jhs@FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Karl Dietz <email>Karl.Dietz@triplan.com</email></para> - </listitem> - - <listitem> - <para>Karl Lehenbauer <email>karl@NeoSoft.com</email> - <email>karl@one.neosoft.com</email></para> - </listitem> - - <listitem> - <para>Keith Bostic <email>bostic@toe.CS.Berkeley.EDU</email></para> - </listitem> - - <listitem> - <para>Ken Hughes</para> - </listitem> - - <listitem> - <para>Kent Talarico <email>kent@shipwreck.tsoft.net</email></para> - </listitem> - - <listitem> - <para>Kevin Lahey <email>kml%rokkaku.UUCP@mathcs.emory.edu</email> - <email>kml@mosquito.cis.ufl.edu</email></para> - </listitem> - - <listitem> - <para>Marc Frajola <email>marc@dev.com</email></para> - </listitem> - - <listitem> - <para>Mark Tinguely <email>tinguely@plains.nodak.edu</email> - <email>tinguely@hookie.cs.ndsu.NoDak.edu</email></para> - </listitem> - - <listitem> - <para>Martin Renters <email>martin@tdc.on.ca</email></para> - </listitem> - - <listitem> - <para>Michael Clay <email>mclay@weareb.org</email></para> - </listitem> - - <listitem> - <para>Michael Galassi <email>nerd@percival.rain.com</email></para> - </listitem> - - <listitem> - <para>Mike Durkin <email>mdurkin@tsoft.sf-bay.org</email></para> - </listitem> - - <listitem> - <para>Naoki Hamada <email>nao@tom-yam.or.jp</email></para> - </listitem> - - <listitem> - <para>Nate Williams <email>nate@bsd.coe.montana.edu</email></para> - </listitem> - - <listitem> - <para>Nick Handel <email>nhandel@NeoSoft.com</email> - <email>nick@madhouse.neosoft.com</email></para> - </listitem> - - <listitem> - <para>Pace Willisson <email>pace@blitz.com</email></para> - </listitem> - - <listitem> - <para>Paul Kranenburg <email>pk@cs.few.eur.nl</email></para> - </listitem> - - <listitem> - <para>Paul Mackerras <email>paulus@cs.anu.edu.au</email></para> - </listitem> - - <listitem> - <para>Paul Popelka <email>paulp@uts.amdahl.com</email></para> - </listitem> - - <listitem> - <para>Peter da Silva <email>peter@NeoSoft.com</email></para> - </listitem> - - <listitem> - <para>Phil Sutherland - <email>philsuth@mycroft.dialix.oz.au</email></para> - </listitem> - - <listitem> - <para>Poul-Henning Kamp<email>phk@FreeBSD.org</email></para> - </listitem> - - <listitem> - <para>Ralf Friedl <email>friedl@informatik.uni-kl.de</email></para> - </listitem> - - <listitem> - <para>Rick Macklem <email>root@snowhite.cis.uoguelph.ca</email></para> - </listitem> - - <listitem> - <para>Robert D. Thrush <email>rd@phoenix.aii.com</email></para> - </listitem> - - <listitem> - <para>Rodney W. Grimes <email>rgrimes@cdrom.com</email></para> - </listitem> - - <listitem> - <para>Sascha Wildner <email>swildner@channelz.GUN.de</email></para> - </listitem> - - <listitem> - <para>Scott Burris <email>scott@pita.cns.ucla.edu</email></para> - </listitem> - - <listitem> - <para>Scott Reynolds <email>scott@clmqt.marquette.mi.us</email></para> - </listitem> - - <listitem> - <para>Sean Eric Fagan <email>sef@kithrup.com</email></para> - </listitem> - - <listitem> - <para>Simon J Gerraty <email>sjg@melb.bull.oz.au</email> - <email>sjg@zen.void.oz.au</email></para> - </listitem> - - <listitem> - <para>Stephen McKay <email>syssgm@devetir.qld.gov.au</email></para> - </listitem> - - <listitem> - <para>Terry Lambert <email>terry@icarus.weber.edu</email></para> - </listitem> - - <listitem> - <para>Terry Lee <email>terry@uivlsi.csl.uiuc.edu</email></para> - </listitem> - - <listitem> - <para>Tor Egge <email>Tor.Egge@idi.ntnu.no</email></para> - </listitem> - - <listitem> - <para>Warren Toomey <email>wkt@csadfa.cs.adfa.oz.au</email></para> - </listitem> - - <listitem> - <para>Wiljo Heinen <email>wiljo@freeside.ki.open.de</email></para> - </listitem> - - <listitem> - <para>William Jolitz <email>withheld</email></para> - </listitem> - - <listitem> - <para>Wolfgang Solfrank <email>ws@tools.de</email></para> - </listitem> - - <listitem> - <para>Wolfgang Stanglmeier <email>wolf@dentaro.GUN.de</email></para> - </listitem> - - <listitem> - <para>Yuval Yarom <email>yval@cs.huji.ac.il</email></para> - </listitem> - </itemizedlist> - </sect1> -</chapter> - -<!-- - Local Variables: - mode: sgml - sgml-declaration: "../chapter.decl" - sgml-indent-data: t - sgml-omittag: nil - sgml-always-quote-attributes: t - sgml-parent-document: ("../handbook.sgml" "part" "chapter") - End: ---> - diff --git a/en_US.ISO8859-1/articles/5-roadmap/article.sgml b/en_US.ISO8859-1/articles/5-roadmap/article.sgml index 596a39016f..5600d988b5 100644 --- a/en_US.ISO8859-1/articles/5-roadmap/article.sgml +++ b/en_US.ISO8859-1/articles/5-roadmap/article.sgml @@ -590,41 +590,6 @@ </sect2> </sect1> - <sect1 id="schedule"> - <title>Schedule</title> - - <para>The original schedule of releasing &os; 5.2 and branching - &t.releng.5; in September 2003 is being pushed back due to the - complexity of the remaining tasks. The new schedule follows:</para> - - <itemizedlist> - <listitem> - <para>Nov 18, 2003: 5.2-BETA, general code freeze</para> - </listitem> - <listitem> - <para>Dec 6, 2003: 5.2-RC1, &t.releng.5.2; branched</para> - </listitem> - <listitem> - <para>Dec 9, 2003: 5.2-RC2</para> - </listitem> - <listitem> - <para>Dec 16, 2003: 5.2-RELEASE</para> - </listitem> - <listitem> - <para>Mar 1, 2004: 5.3-BETA, general code freeze</para> - </listitem> - <listitem> - <para>Mar 15, 2004: 5.3-RC1, &t.releng.5; and &t.releng.5.3; branched</para> - </listitem> - <listitem> - <para>Mar 22, 2004: 5.3-RC2</para> - </listitem> - <listitem> - <para>Mar 29, 2004: 5.3-RELEASE</para> - </listitem> - </itemizedlist> - </sect1> - <sect1 id="future"> <title>Post &t.releng.5; direction</title> diff --git a/en_US.ISO8859-1/articles/committers-guide/article.sgml b/en_US.ISO8859-1/articles/committers-guide/article.sgml index e5a4baca1c..c69370c5f7 100644 --- a/en_US.ISO8859-1/articles/committers-guide/article.sgml +++ b/en_US.ISO8859-1/articles/committers-guide/article.sgml @@ -727,11 +727,11 @@ alias scvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@ncvs.FreeBSD.o </itemizedlist> <para>You will almost certainly get a conflict because - of the <literal>$Id: article.sgml,v 1.213 2004-09-20 11:04:00 marck Exp $</literal> (or in FreeBSD's case, + of the <literal>$Id: article.sgml,v 1.215 2004-10-11 17:06:14 keramida Exp $</literal> (or in FreeBSD's case, <literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>) lines, so you will have to edit the file to resolve the conflict - (remove the marker lines and the second <literal>$Id: article.sgml,v 1.213 2004-09-20 11:04:00 marck Exp $</literal> line, - leaving the original <literal>$Id: article.sgml,v 1.213 2004-09-20 11:04:00 marck Exp $</literal> line intact).</para> + (remove the marker lines and the second <literal>$Id: article.sgml,v 1.215 2004-10-11 17:06:14 keramida Exp $</literal> line, + leaving the original <literal>$Id: article.sgml,v 1.215 2004-10-11 17:06:14 keramida Exp $</literal> line intact).</para> </listitem> <listitem> @@ -1015,8 +1015,18 @@ checkout -P</programlisting> locks the directory you are working with and will prevent other developers from committing into the same directory. If you have to type a long commit message, type it before executing - <command>cvs commit</command>, and insert it into the commit - message.</para> + <command>cvs commit</command> and insert it into the commit + message or save it in a file before committing and use the + <option>-F</option> option of CVS to read the commit message from + that file, i.e.</para> + + <screen>&prompt.user; <userinput>vi logmsg</userinput> +&prompt.user; <userinput>cvs ci -F logmsg shazam</userinput></screen> + + <para>This is the fastest way of passing a commit message to CVS but + you should be careful when editing the <filename>logmsg</filename> + file before the commit, because CVS will not give you a chance to edit + the message when you do the actual commit.</para> </listitem> </orderedlist> diff --git a/en_US.ISO8859-1/articles/contributors/Makefile b/en_US.ISO8859-1/articles/contributors/Makefile index 23e6d0fff9..7e36f74b21 100644 --- a/en_US.ISO8859-1/articles/contributors/Makefile +++ b/en_US.ISO8859-1/articles/contributors/Makefile @@ -19,6 +19,7 @@ SRCS+= contrib.committers.sgml SRCS+= contrib.core.sgml SRCS+= contrib.corealumni.sgml SRCS+= contrib.develalumni.sgml +SRCS+= contrib.staff.sgml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. diff --git a/en_US.ISO8859-1/articles/contributors/article.sgml b/en_US.ISO8859-1/articles/contributors/article.sgml index 5ebfb57915..9ac6b29c9e 100644 --- a/en_US.ISO8859-1/articles/contributors/article.sgml +++ b/en_US.ISO8859-1/articles/contributors/article.sgml @@ -425,18 +425,10 @@ </varlistentry> <varlistentry> - <term>Gallery Editor</term> - - <listitem> - <para>&a.phantom;</para> - </listitem> - </varlistentry> - - <varlistentry> <term>Commercial Gallery Editor</term> <listitem> - <para>&a.josef;</para> + <para>&a.brueffer;</para> </listitem> </varlistentry> diff --git a/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml b/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml index caad675842..89767cb026 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml +++ b/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml @@ -6,6 +6,16 @@ <itemizedlist> <listitem> + <para>Aaron Straup Cope + <email>ascope@cpan.org</email></para> + </listitem> + + <listitem> + <para>Aaron Voisine + <email>voisine@gmail.com</email></para> + </listitem> + + <listitem> <para>ABURAYA Ryushirou <email>rewsirow@ff.iij4u.or.jp</email></para> </listitem> @@ -41,6 +51,11 @@ </listitem> <listitem> + <para>Aasmund Eikli + <email>inter@o12a.com</email></para> + </listitem> + + <listitem> <para>Achim Patzner <email>ap@noses.com</email></para> </listitem> @@ -56,6 +71,11 @@ </listitem> <listitem> + <para>Adam C. Migus + <email>adam@migus.org</email></para> + </listitem> + + <listitem> <para>Adam Glass <email>glass@postgres.berkeley.edu</email></para> </listitem> @@ -66,6 +86,11 @@ </listitem> <listitem> + <para>Adam Jette + <email>jettea46@yahoo.com</email></para> + </listitem> + + <listitem> <para>Adam Kranzel <email>adam@alameda.edu</email></para> </listitem> @@ -81,6 +106,11 @@ </listitem> <listitem> + <para>Adam Wight + <email>adamw@tulum.brsys.com</email></para> + </listitem> + + <listitem> <para>Adoal Xu <email>adoal@iname.com</email></para> </listitem> @@ -91,6 +121,11 @@ </listitem> <listitem> + <para>Adrian Filipi-Martin + <email>adrian@ubergeeks.com</email></para> + </listitem> + + <listitem> <para>Adrian Hall <email>ahall@mirapoint.com</email></para> </listitem> @@ -111,11 +146,31 @@ </listitem> <listitem> + <para>Aftab Jahan Subedar + <email>jahan@bol-online.com</email></para> + </listitem> + + <listitem> + <para>AIDA Shinra + <email>aida-s@jcom.home.ne.jp</email></para> + </listitem> + + <listitem> <para>Ajit Thyagarajan <email>unknown</email></para> </listitem> <listitem> + <para>Akinori YAMADA + <email>yamada-a@nextcom.co.jp</email></para> + </listitem> + + <listitem> + <para>Akira Ikeuchi + <email>a_ikeuchi@mic.mitsumi.co.jp</email></para> + </listitem> + + <listitem> <para>Akira SAWADA <email>unknown</email></para> </listitem> @@ -131,11 +186,21 @@ </listitem> <listitem> + <para>Al Hoang + <email>hoanga@mac.com</email></para> + </listitem> + + <listitem> <para>Alain Kalker <email>A.C.P.M.Kalker@student.utwente.nl</email></para> </listitem> <listitem> + <para>Alan Amesbury + <email>amesbury@indefi.net</email></para> + </listitem> + + <listitem> <para>Alan Bawden <email>alan@curry.epilogue.com</email></para> </listitem> @@ -177,7 +242,7 @@ <listitem> <para>Alex Kapranoff - <email>kappa@zombie.antar.bryansk.ru</email></para> + <email>alex@kapranoff.ru</email></para> </listitem> <listitem> @@ -191,6 +256,11 @@ </listitem> <listitem> + <para>Alex M + <email>alex@myzona.net</email></para> + </listitem> + + <listitem> <para>Alex Perel <email>veers@disturbed.net</email></para> </listitem> @@ -217,7 +287,17 @@ <listitem> <para>Alex Varju - <email>varju@webct.com</email></para> + <email>freebsd-ports@varju.ca</email></para> + </listitem> + + <listitem> + <para>Alex Vasylenko + <email>lxv@omut.org</email></para> + </listitem> + + <listitem> + <para>Alex Wilkinson + <email>alex.wilkinson@dsto.defence.gov.au</email></para> </listitem> <listitem> @@ -236,6 +316,11 @@ </listitem> <listitem> + <para>Alexander Haderer + <email>alexander.haderer@charite.de</email></para> + </listitem> + + <listitem> <para>Alexander Kovalenko <email>never@nevermind.kiev.ua</email></para> </listitem> @@ -246,11 +331,31 @@ </listitem> <listitem> + <para>Alexander Peresunko + <email>alex@freeman.org.ua</email></para> + </listitem> + + <listitem> + <para>Alexander Pohoyda + <email>alexander.pohoyda@gmx.net</email></para> + </listitem> + + <listitem> <para>Alexander Timoshenko <email>gonzo@univ.kiev.ua</email></para> </listitem> <listitem> + <para>Alexander Zagrebin + <email>alexz@visp.ru</email></para> + </listitem> + + <listitem> + <para>Alexander Zhuravlev + <email>zaa@zaa.pp.ru</email></para> + </listitem> + + <listitem> <para>Alexandre Peixoto <email>alexandref@tcoip.com.br</email></para> </listitem> @@ -346,11 +451,21 @@ </listitem> <listitem> + <para>Anatoly Zherdev + <email>tolyar@mx.ru</email></para> + </listitem> + + <listitem> <para>Anders Andersson <email>anders@codefactory.se</email></para> </listitem> <listitem> + <para>Anders Nor Berle + <email>debolaz@debolaz.com</email></para> + </listitem> + + <listitem> <para>Anders Thulin <email>Anders.X.Thulin@telia.se</email></para> </listitem> @@ -376,6 +491,11 @@ </listitem> <listitem> + <para>Andre Yelistratov + <email>andre@andre.net.ru</email></para> + </listitem> + + <listitem> <para>Andrea Venturoli <email>a.ventu@flashnet.it</email></para> </listitem> @@ -391,6 +511,16 @@ </listitem> <listitem> + <para>Andreas Fuchs + <email>asf@boinkor.net</email></para> + </listitem> + + <listitem> + <para>Andreas Gustafsson + <email>gson@araneus.fi</email></para> + </listitem> + + <listitem> <para>Andreas Haakh <email>ah@alman.robin.de</email></para> </listitem> @@ -401,6 +531,16 @@ </listitem> <listitem> + <para>Andreas K Foerster + <email>akf3@akfoerster.de</email></para> + </listitem> + + <listitem> + <para>Andreas Kasparz + <email>andy@interface-business.de</email></para> + </listitem> + + <listitem> <para>Andreas Kohout <email>shanee@rabbit.augusta.de</email></para> </listitem> @@ -411,6 +551,16 @@ </listitem> <listitem> + <para>Andreas Möller + <email>segfault@gmx.net</email></para> + </listitem> + + <listitem> + <para>Andreas Riedel + <email>rian@hrz.tu-chemnitz.de</email></para> + </listitem> + + <listitem> <para>Andreas Wetzel <email>mickey@deadline.snafu.de</email></para> </listitem> @@ -436,6 +586,11 @@ </listitem> <listitem> + <para>Andrew Arensburger + <email>arensb@ooblick.com</email></para> + </listitem> + + <listitem> <para>Andrew Atrens <email>atreand@statcan.ca</email></para> </listitem> @@ -467,7 +622,12 @@ <listitem> <para>Andrew J. Korty - <email>ajk@purdue.edu</email></para> + <email>ajk@iu.edu</email></para> + </listitem> + + <listitem> + <para>Andrew Kolchoogin + <email>andrew@rinet.ru</email></para> </listitem> <listitem> @@ -476,6 +636,11 @@ </listitem> <listitem> + <para>Andrew McKay + <email>andy@openirc.co.uk</email></para> + </listitem> + + <listitem> <para>Andrew McNaughton <email>andrew@scoop.co.nz</email></para> </listitem> @@ -486,11 +651,21 @@ </listitem> <listitem> + <para>Andrew Morton + <email>drewish@katherinehouse.com</email></para> + </listitem> + + <listitem> <para>Andrew P. Lentvorski <email>bsder@allcaps.org</email></para> </listitem> <listitem> + <para>Andrew Predoehl + <email>predoehl@mail.kg</email></para> + </listitem> + + <listitem> <para>Andrew S. Midthune <email>amidthune@cableone.net</email></para> </listitem> @@ -521,6 +696,11 @@ </listitem> <listitem> + <para>Andrew V. Stikheev + <email>sand@links.ru</email></para> + </listitem> + + <listitem> <para>Andrew Webster <email>awebster@dataradio.com</email></para> </listitem> @@ -537,7 +717,7 @@ <listitem> <para>Andrey Slusar - <email>vasallia@ukr.net</email></para> + <email>anray@inet.ua</email></para> </listitem> <listitem> @@ -556,6 +736,11 @@ </listitem> <listitem> + <para>Andy Fawcett + <email>andy@athame.co.uk</email></para> + </listitem> + + <listitem> <para>Andy Gilligan <email>andy@evo6.org</email></para> </listitem> @@ -566,6 +751,11 @@ </listitem> <listitem> + <para>Andy Newman + <email>atrn@zeta.org.au</email></para> + </listitem> + + <listitem> <para>Andy Pavlo <email>amp0928@rit.edu</email></para> </listitem> @@ -606,6 +796,11 @@ </listitem> <listitem> + <para>Anthony Ginepro + <email>anthony.ginepro@laposte.net</email></para> + </listitem> + + <listitem> <para>Anthony Yee-Hang Chan <email>yeehang@netcom.com</email></para> </listitem> @@ -626,6 +821,11 @@ </listitem> <listitem> + <para>Antonio Bonifati + <email>ant@monitor.deis.unical.it</email></para> + </listitem> + + <listitem> <para>Antonio Carlos Venancio Junior <email>antonio@php.net</email></para> </listitem> @@ -656,7 +856,7 @@ </listitem> <listitem> - <para>Arnaud S. Launay + <para>Arnaud Launay <email>asl@launay.org</email></para> </listitem> @@ -686,6 +886,11 @@ </listitem> <listitem> + <para>Attila Nagy + <email>bra@fsn.hu</email></para> + </listitem> + + <listitem> <para>Atushi Sakauchi <email>sakauchi@yamame.to</email></para> </listitem> @@ -701,6 +906,11 @@ </listitem> <listitem> + <para>Balázs Nagy + <email>js@iksz.hu</email></para> + </listitem> + + <listitem> <para>Barry Bierbauch <email>pivrnec@vszbr.cz</email></para> </listitem> @@ -736,16 +946,31 @@ </listitem> <listitem> + <para>Benjamin Lutz + <email>benlutz@datacomm.ch</email></para> + </listitem> + + <listitem> <para>Berend de Boer <email>berend@pobox.com</email></para> </listitem> <listitem> + <para>Bernd Luevelsmeyer + <email>bdluevel@heitec.net</email></para> + </listitem> + + <listitem> <para>Bernd Rosauer <email>br@schiele-ct.de</email></para> </listitem> <listitem> + <para>Bill Cadwallader + <email>hurbold@yahoo.com</email></para> + </listitem> + + <listitem> <para>Bill Kish <email>kish@osf.org</email></para> </listitem> @@ -776,6 +1001,11 @@ </listitem> <listitem> + <para>Boris Kovalenko + <email>boris@tagnet.ru</email></para> + </listitem> + + <listitem> <para>Boris Staeblow <email>balu@dva.in-berlin.de</email></para> </listitem> @@ -861,8 +1091,8 @@ </listitem> <listitem> - <para>Brian Clapper - <email>bmc@willscreek.com</email></para> + <para>Brian M. Clapper + <email>bmc@clapper.com</email></para> </listitem> <listitem> @@ -891,6 +1121,11 @@ </listitem> <listitem> + <para>Brian R. Gaeke + <email>brg@dgate.org</email></para> + </listitem> + + <listitem> <para>Brian R. Haug <email>haug@conterra.com</email></para> </listitem> @@ -941,6 +1176,11 @@ </listitem> <listitem> + <para>Bruno Schwander + <email>bruno@tinkerbox.org</email></para> + </listitem> + + <listitem> <para>Camson Huynh <email>chuynh@biolateral.com.au</email></para> </listitem> @@ -981,6 +1221,11 @@ </listitem> <listitem> + <para>Cédric Lamalle + <email>cedric@cedric.trix.net</email></para> + </listitem> + + <listitem> <para>Chain Lee <email>chain@110.net</email></para> </listitem> @@ -1006,16 +1251,31 @@ </listitem> <listitem> + <para>Charles Swiger + <email>chuck@pkix.net</email></para> + </listitem> + + <listitem> <para>Chet Ramey <email>chet@odin.INS.CWRU.Edu</email></para> </listitem> <listitem> + <para>Chia-Hsing Yu + <email>davidyu@ucsd.edu</email></para> + </listitem> + + <listitem> <para>Chia-liang Kao <email>clkao@CirX.ORG</email></para> </listitem> <listitem> + <para>Chiang Cheng-Hsiung + <email>elvis@sslab.cs.ccu.edu.tw</email></para> + </listitem> + + <listitem> <para>Chiharu Shibata <email>chi@bd.mbn.or.jp</email></para> </listitem> @@ -1131,13 +1391,13 @@ </listitem> <listitem> - <para>Christophe Juniet - <email>cjuniet@entreview.com</email></para> + <para>Christoph Weber-Fahr + <email>wefa@callcenter.systemhaus.net</email></para> </listitem> <listitem> - <para>Christoph Weber-Fahr - <email>wefa@callcenter.systemhaus.net</email></para> + <para>Christophe Juniet + <email>cjuniet@entreview.com</email></para> </listitem> <listitem> @@ -1161,6 +1421,11 @@ </listitem> <listitem> + <para>Christopher Nehren + <email>apeiron@comcast.net</email></para> + </listitem> + + <listitem> <para>Christopher Preston <email>rbg@gayteenresource.org</email></para> </listitem> @@ -1186,6 +1451,11 @@ </listitem> <listitem> + <para>Clayton Rollins + <email>crollins666@hotmail.com</email></para> + </listitem> + + <listitem> <para>Clement MOULIN <email>moeti-freebsd@ouestil.com</email></para> </listitem> @@ -1201,6 +1471,11 @@ </listitem> <listitem> + <para>Conor McDermottroe + <email>ports@mcdermottroe.com</email></para> + </listitem> + + <listitem> <para>Conrad Sabatier <email>conrads@cox.net</email></para> </listitem> @@ -1266,6 +1541,11 @@ </listitem> <listitem> + <para>Cyril Guibourg + <email>aragorn+ports@teaser.fr</email></para> + </listitem> + + <listitem> <para>Cyrille Lefevre <email>clefevre@citeweb.net</email></para> </listitem> @@ -1317,7 +1597,7 @@ <listitem> <para>Dan Nelson - <email>dnelson@emsphone.com</email></para> + <email>dnelson@allantgroup.com</email></para> </listitem> <listitem> @@ -1351,6 +1631,11 @@ </listitem> <listitem> + <para>Daniel Bryan + <email>sisko@bsdmail.com</email></para> + </listitem> + + <listitem> <para>Daniel Hagan <email>dhagan@acm.vt.edu</email></para> </listitem> @@ -1491,11 +1776,21 @@ </listitem> <listitem> + <para>David Gilbert + <email>dave@daveg.ca</email></para> + </listitem> + + <listitem> <para>David Magda <email>dmagda@magda.ca</email></para> </listitem> <listitem> + <para>David Gardner + <email>david@pinko.net</email></para> + </listitem> + + <listitem> <para>David H. Munro <email>munro1@llnl.gov</email></para> </listitem> @@ -1521,6 +1816,11 @@ </listitem> <listitem> + <para>David Johnson + <email>david@usermode.org</email></para> + </listitem> + + <listitem> <para>David Jones <email>dej@qpoint.torfree.net</email></para> </listitem> @@ -1541,6 +1841,11 @@ </listitem> <listitem> + <para>David Lay + <email>dsl@webize.com.au</email></para> + </listitem> + + <listitem> <para>David Le Brun <email>david@dyn-ns.net</email></para> </listitem> @@ -1556,11 +1861,21 @@ </listitem> <listitem> + <para>David Quattlebaum + <email>drq@drqware.com</email></para> + </listitem> + + <listitem> <para>David S. Miller <email>davem@jenolan.rutgers.edu</email></para> </listitem> <listitem> + <para>David Siebörger + <email>drs@rucus.ru.ac.za</email></para> + </listitem> + + <listitem> <para>David Sugar <email>dyfet@gnu.org</email></para> </listitem> @@ -1616,6 +1931,11 @@ </listitem> <listitem> + <para>Dennis Cabooter + <email>dennis@rootxs.org</email></para> + </listitem> + + <listitem> <para>Dennis Glatting <email>dennis.glatting@software-munitions.com</email></para> </listitem> @@ -1631,6 +1951,11 @@ </listitem> <listitem> + <para>Derik van Zuetphen + <email>dz@426.ch</email></para> + </listitem> + + <listitem> <para>Dermot Tynan <email>dtynan@kalopa.com</email></para> </listitem> @@ -1657,7 +1982,7 @@ <listitem> <para>Dirk-Willem van Gulik - <email>dirkx@skutsje.san.webweaving.org</email></para> + <email>dirkx@webweaving.org</email></para> </listitem> <listitem> @@ -1756,7 +2081,7 @@ <listitem> <para>Donald Maddox - <email>dmaddox@conterra.com</email></para> + <email>dmaddox099@yahoo.com</email></para> </listitem> <listitem> @@ -1785,6 +2110,11 @@ </listitem> <listitem> + <para>Douglas W. Thrift + <email>douglas@douglasthrift.net</email></para> + </listitem> + + <listitem> <para>Drew Derbyshire <email>ahd@kew.com</email></para> </listitem> @@ -1800,6 +2130,11 @@ </listitem> <listitem> + <para>Dylan Carlson + <email>absinthe@retrovertigo.com</email></para> + </listitem> + + <listitem> <para>Dylan Simon <email>dylan@dylex.net</email></para> </listitem> @@ -1899,6 +2234,11 @@ </listitem> <listitem> + <para>Eric Cronin + <email>ecronin@eecs.umich.edu</email></para> + </listitem> + + <listitem> <para>Eric D. Futch <email>efutch@nyct.net</email></para> </listitem> @@ -1919,11 +2259,31 @@ </listitem> <listitem> + <para>Eric Masson + <email>e-masson@kisoft-services.com</email></para> + </listitem> + + <listitem> + <para>Eric Ogren + <email>eogren@stanford.edu</email></para> + </listitem> + + <listitem> <para>Eric P. Scott <email>eps@sirius.com</email></para> </listitem> <listitem> + <para>Eric S. Van Gyzen + <email>esv@vangyzen.net</email></para> + </listitem> + + <listitem> + <para>Eric Schnoebelen + <email>eric@cirr.com</email></para> + </listitem> + + <listitem> <para>Eric Shao-yu Cheng <email>eric@fractal.csie.org</email></para> </listitem> @@ -1934,11 +2294,26 @@ </listitem> <listitem> + <para>Eric W. Bates + <email>ericx@vineyard.net</email></para> + </listitem> + + <listitem> <para>Erich Stefan Boleyn <email>erich@uruk.org</email></para> </listitem> <listitem> + <para>Eric van Gyzen + <email>vangyzen@stat.duke.edu</email></para> + </listitem> + + <listitem> + <para>Eric Yu + <email>ericyu@mail2000.com.tw</email></para> + </listitem> + + <listitem> <para>Erich Zigler <email>erich@tacni.net</email></para> </listitem> @@ -2029,6 +2404,11 @@ </listitem> <listitem> + <para>Fabien Devaux + <email>fab@gcu.info</email></para> + </listitem> + + <listitem> <para>Fanying Jen <email>fanying@fynet.com</email></para> </listitem> @@ -2099,13 +2479,18 @@ </listitem> <listitem> + <para>Frank Denis + <email>j@pureftpd.org</email></para> + </listitem> + + <listitem> <para>Frank Gründer <email>elwood@mc5sys.in-berlin.de</email></para> </listitem> <listitem> - <para>Frank J. Lazlo - <email>laszlof@freebsdmatrix.net</email></para> + <para>Frank J. Laszlo + <email>laszlof@vonostingroup.com</email></para> </listitem> <listitem> @@ -2114,6 +2499,11 @@ </listitem> <listitem> + <para>Frank Mayhar + <email>frank@exit.com</email></para> + </listitem> + + <listitem> <para>Frank Nobis <email>fn@Radio-do.de</email></para> </listitem> @@ -2139,6 +2529,11 @@ </listitem> <listitem> + <para>Frank W. Josellis + <email>frank@dynamical-systems.org</email></para> + </listitem> + + <listitem> <para>Franz Klammer <email>klammer@webonaut.com</email></para> </listitem> @@ -2198,6 +2593,11 @@ </listitem> <listitem> + <para>Ganael LAPLANCHE + <email>ganael.laplanche@martymac.com</email></para> + </listitem> + + <listitem> <para>Gareth McCaughan <email>gjm11@dpmms.cam.ac.uk</email></para> </listitem> @@ -2239,7 +2639,7 @@ <listitem> <para>Gavin Atkinson - <email>gavin@ury.york.ac.uk</email></para> + <email>gavin.atkinson@ury.york.ac.uk</email></para> </listitem> <listitem> @@ -2263,13 +2663,23 @@ </listitem> <listitem> + <para>Georg Graf + <email>georg@graf.priv.at</email></para> + </listitem> + + <listitem> <para>Georg Wagner <email>georg.wagner@ubs.com</email></para> </listitem> <listitem> + <para>George Hartzell + <email>hartzell@kestrel.alerce.com</email></para> + </listitem> + + <listitem> <para>Gerrit Beine - <email>gerrit@beine-computer.de</email></para> + <email>tux@pinguru.net</email></para> </listitem> <listitem> @@ -2378,16 +2788,41 @@ </listitem> <listitem> + <para>Guido Falsi + <email>mad@madpilot.net</email></para> + </listitem> + + <listitem> + <para>Guillaume Paquet + <email>amyfoub@videotron.ca</email></para> + </listitem> + + <listitem> <para>Gurkan Sengun <email>gurkan@linuks.mine.nu</email></para> </listitem> <listitem> + <para>Guy Coleman + <email>gtchask@mm.st</email></para> + </listitem> + + <listitem> <para>Guy Harris <email>guy@netapp.com</email></para> </listitem> <listitem> + <para>Guy Poizat + <email>guy@device.dyndns.org</email></para> + </listitem> + + <listitem> + <para>H. Wade Minter + <email>minter@lunenburg.org</email></para> + </listitem> + + <listitem> <para>HAMADA Naoki <email>hamada@astec.co.jp</email></para> </listitem> @@ -2478,6 +2913,11 @@ </listitem> <listitem> + <para>HATANOU Tomomi + <email>hatanou@infolab.ne.jp</email></para> + </listitem> + + <listitem> <para>Havard Eidnes <email>Havard.Eidnes@runit.sintef.no</email></para> </listitem> @@ -2523,6 +2963,11 @@ </listitem> <listitem> + <para>Henrik Nymann Jensen + <email>henriknj@0xmilk.org</email></para> + </listitem> + + <listitem> <para>Henrik Vestergaard Draboel <email>hvd@terry.ping.dk</email></para> </listitem> @@ -2538,6 +2983,11 @@ </listitem> <listitem> + <para>Herbert J. Skuhra + <email>herbert.skuhra@gmx.at</email></para> + </listitem> + + <listitem> <para>Hideaki Ohmon <email>ohmon@tom.sfc.keio.ac.jp</email></para> </listitem> @@ -2548,8 +2998,8 @@ </listitem> <listitem> - <para>Hideki Machida - <email>hido@neojapangz.com</email></para> + <para>Hideaki Machida + <email>hido@coreblack.com</email></para> </listitem> <listitem> @@ -2634,7 +3084,7 @@ <listitem> <para>Hubert Tournier - <email>hubert@tournier.org</email></para> + <email>hubert@frbsd.org</email></para> </listitem> <listitem> @@ -2663,6 +3113,11 @@ </listitem> <listitem> + <para>IWATSUKI Hiroyuki + <email>don@na.rim.or.jp</email></para> + </listitem> + + <listitem> <para>Ian Holland <email>ianh@tortuga.com.au</email></para> </listitem> @@ -2684,7 +3139,7 @@ <listitem> <para>Igor Pokrovsky - <email>tiamat@telegraph.spb.ru</email></para> + <email>ip@doom.homeunix.org</email></para> </listitem> <listitem> @@ -2714,7 +3169,12 @@ <listitem> <para>Ilia Chipitsine - <email>ilia@jane.cgu.chel.su</email></para> + <email>ilia@rediska.ru</email></para> + </listitem> + + <listitem> + <para>Ilya Khamushkin + <email>ilya@space.rootshell.ru</email></para> </listitem> <listitem> @@ -2723,6 +3183,11 @@ </listitem> <listitem> + <para>Ion-Mihai "IOnut" Tetcu + <email>itetcu@people.tecnik93.com</email></para> + </listitem> + + <listitem> <para>Ivan Sharov <email>ivan.sharov@iname.com</email></para> </listitem> @@ -2838,6 +3303,11 @@ </listitem> <listitem> + <para>Jamie Jones + <email>jamie@bishopston.net</email></para> + </listitem> + + <listitem> <para>Jan Conard <email>charly@fachschaften.tu-muenchen.de</email></para> </listitem> @@ -2863,6 +3333,11 @@ </listitem> <listitem> + <para>Jan Srzednicki + <email>w@wrzask.pl</email></para> + </listitem> + + <listitem> <para>Jan Stocker <email>jan.stocker@t-online.de</email></para> </listitem> @@ -2953,6 +3428,11 @@ </listitem> <listitem> + <para>Jean-Baptiste Quenot + <email>jb.quenot@caraldi.com</email></para> + </listitem> + + <listitem> <para>Jean-Sebastien Roy <email>js@jeannot.org</email></para> </listitem> @@ -3014,7 +3494,7 @@ <listitem> <para>Jeremy Chadwick - <email>yoshi@parodius.com</email></para> + <email>freebsd@jdc.parodius.com</email></para> </listitem> <listitem> @@ -3043,6 +3523,11 @@ </listitem> <listitem> + <para>Jerry Eriksson + <email>jerry@freebsd.se</email></para> + </listitem> + + <listitem> <para>Jesper Dalberg <email>jesper@jdn.dk</email></para> </listitem> @@ -3099,7 +3584,7 @@ <listitem> <para>Jim Geovedi - <email>negative@toxic.magnesium.net</email></para> + <email>jim@corebsd.or.id</email></para> </listitem> <listitem> @@ -3178,6 +3663,11 @@ </listitem> <listitem> + <para>Joe Barbish + <email>barbish@a1poweruser.com</email></para> + </listitem> + + <listitem> <para>Joe Halpin <email>joe.halpin@attbi.com</email></para> </listitem> @@ -3198,6 +3688,11 @@ </listitem> <listitem> + <para>Joe Smith + <email>inwap@best.com</email></para> + </listitem> + + <listitem> <para>Joe Traister <email>traister@mojozone.org</email></para> </listitem> @@ -3228,6 +3723,11 @@ </listitem> <listitem> + <para>Joerg Schilling + <email>schilling@fokus.gmd.de</email></para> + </listitem> + + <listitem> <para>Johan Granlund <email>johan@granlund.nu</email></para> </listitem> @@ -3248,11 +3748,16 @@ </listitem> <listitem> - <para>Johann van Selst + <para>Johan van Selst <email>johans@stack.nl</email></para> </listitem> <listitem> + <para>Johannes Grødem + <email>johs@copyleft.no</email></para> + </listitem> + + <listitem> <para>Johannes 5 Joemann <email>joemann@beefree.free.de</email></para> </listitem> @@ -3349,7 +3854,7 @@ <listitem> <para>John Reynolds - <email>jjreynold@home.com</email></para> + <email>johnjen@reynoldsnet.org</email></para> </listitem> <listitem> @@ -3373,6 +3878,11 @@ </listitem> <listitem> + <para>John Von Essen + <email>john@essenz.com</email></para> + </listitem> + + <listitem> <para>John Woods <email>jfw@eddie.mit.edu</email></para> </listitem> @@ -3403,6 +3913,11 @@ </listitem> <listitem> + <para>Jonathan Chen + <email>jonc@chen.org.nz</email></para> + </listitem> + + <listitem> <para>Jonathan Drews <email>j.e.drews@att.net</email></para> </listitem> @@ -3414,7 +3929,7 @@ <listitem> <para>Jonathan Hanna - <email>jh@pc-21490.bc.rogers.wave.ca</email></para> + <email>jhanna@shaw.ca</email></para> </listitem> <listitem> @@ -3423,6 +3938,11 @@ </listitem> <listitem> + <para>Jonathan McDowell + <email>noodles@earth.li</email></para> + </listitem> + + <listitem> <para>Jonathan Pennington <email>john@coastalgeology.org</email></para> </listitem> @@ -3443,6 +3963,11 @@ </listitem> <listitem> + <para>Joris Vandalon + <email>joris@vandalon.nl</email></para> + </listitem> + + <listitem> <para>Jos Backus <email>jos@catnook.com</email></para> </listitem> @@ -3453,11 +3978,21 @@ </listitem> <listitem> + <para>Jose Liang + <email>jose@jose.idv.tw</email></para> + </listitem> + + <listitem> <para>Jose Marques <email>jose@nobody.org</email></para> </listitem> <listitem> + <para>Jose Rodriguez + <email>king@v2project.com</email></para> + </listitem> + + <listitem> <para>Josef Grosch <email>jgrosch@superior.mooseriver.com</email></para> </listitem> @@ -3538,6 +4073,11 @@ </listitem> <listitem> + <para>Julian C. Dunn + <email>jdunn@aquezada.com</email></para> + </listitem> + + <listitem> <para>Julian Coleman <email>j.d.coleman@ncl.ac.uk</email></para> </listitem> @@ -3597,6 +4137,11 @@ </listitem> <listitem> + <para>KIMURA Yasuhiro + <email>yasu@utahime.org</email></para> + </listitem> + + <listitem> <para>KIMURA Shigekazu <email>zau50357@lion.zero.ad.jp</email></para> </listitem> @@ -3627,6 +4172,11 @@ </listitem> <listitem> + <para>Kang Liu + <email>liukang@bjut.edu.cn</email></para> + </listitem> + + <listitem> <para>Kang-ming Liu <email>gugod@gugod.org</email></para> </listitem> @@ -3657,6 +4207,11 @@ </listitem> <listitem> + <para>Katsura Matsumoto + <email>katsura@cc.osaka-kyoiku.ac.jp</email></para> + </listitem> + + <listitem> <para>Kawanobe Koh <email>kawanobe@st.rim.or.jp</email></para> </listitem> @@ -3667,6 +4222,11 @@ </listitem> <listitem> + <para>Kazami + <email>kazami@angels.vg</email></para> + </listitem> + + <listitem> <para>Kees Jan Koster <email>kjkoster@kjkoster.org</email></para> </listitem> @@ -3743,7 +4303,7 @@ <listitem> <para>Kenneth Stailey - <email>kstailey@gnu.ai.mit.edu</email></para> + <email>kstailey@yahoo.com</email></para> </listitem> <listitem> @@ -3772,6 +4332,11 @@ </listitem> <listitem> + <para>Kevin Golding + <email>kevin@caomhin.demon.co.uk</email></para> + </listitem> + + <listitem> <para>Kevin Lahey <email>kml@nas.nasa.gov</email></para> </listitem> @@ -3782,6 +4347,11 @@ </listitem> <listitem> + <para>Kevin Oberman + <email>oberman@es.net</email></para> + </listitem> + + <listitem> <para>Kevin Street <email>street@iname.com</email></para> </listitem> @@ -3792,6 +4362,11 @@ </listitem> <listitem> + <para>Key-Teck SIN + <email>ktsin@acm.org</email></para> + </listitem> + + <listitem> <para>Khairil Yusof <email>kaeru@inigo-tech.com</email></para> </listitem> @@ -3807,6 +4382,11 @@ </listitem> <listitem> + <para>Kirk Strauser + <email>kirk@strauser.com</email></para> + </listitem> + + <listitem> <para>Fumihiko Kimura <email>jfkimura@yahoo.co.jp</email></para> </listitem> @@ -3847,6 +4427,11 @@ </listitem> <listitem> + <para>Klaus Michael Indlekofer + <email>M.Indlekofer@gmx.de</email></para> + </listitem> + + <listitem> <para>Klaus-J. Wolf <email>Yanestra@t-online.de</email></para> </listitem> @@ -3887,6 +4472,11 @@ </listitem> <listitem> + <para>Kuang-che Wu + <email>kcwu@csie.org</email></para> + </listitem> + + <listitem> <para>Kurt D. Zeilenga <email>Kurt@Boolean.NET</email></para> </listitem> @@ -3972,8 +4562,8 @@ </listitem> <listitem> - <para>Leo Kim - <email>leo@florida.sarang.net</email></para> + <para>Leif Pedersen + <email>pedersen@meridian-enviro.com</email></para> </listitem> <listitem> @@ -3982,6 +4572,26 @@ </listitem> <listitem> + <para>Leo Kim + <email>leo@florida.sarang.net</email></para> + </listitem> + + <listitem> + <para>Leonardo Silveira de A. Martins + <email>lmartins@nepe.eee.ufg.br</email></para> + </listitem> + + <listitem> + <para>Leonid Zolotarev + <email>leoz@saunalahti.fi</email></para> + </listitem> + + <listitem> + <para>Lev Walking + <email>vlm@lionet.info</email></para> + </listitem> + + <listitem> <para>Lewis Thompson <email>purple@lewiz.net</email></para> </listitem> @@ -3998,7 +4608,12 @@ <listitem> <para>Liang Tai-hwa - <email>avatar@www.mmlab.cse.yzu.edu.tw</email></para> + <email>avatar@mmlab.cse.yzu.edu.tw</email></para> + </listitem> + + <listitem> + <para>Linh Pham + <email>question+freebsdpr@closedsrc.org</email></para> </listitem> <listitem> @@ -4007,6 +4622,11 @@ </listitem> <listitem> + <para>Loren J. Rittle + <email>ljrittle@acm.org</email></para> + </listitem> + + <listitem> <para>Louis A. Mamakos <email>loiue@TransSys.com</email></para> </listitem> @@ -4017,11 +4637,26 @@ </listitem> <listitem> + <para>Lubomir Metodiev Marinov + <email>lubomir.marinov@gmail.com</email></para> + </listitem> + + <listitem> <para>Lucas James <email>Lucas.James@ldjpc.apana.org.au</email></para> </listitem> <listitem> + <para>Luiz Eduardo Roncato Cordeiro + <email>cordeiro@nic.br</email></para> + </listitem> + + <listitem> + <para>Lupe Christoph + <email>lupe@lupe-christoph.de</email></para> + </listitem> + + <listitem> <para>Lyndon Nerenberg <email>lyndon@orthanc.ab.ca</email></para> </listitem> @@ -4038,7 +4673,7 @@ <listitem> <para>MOROHOSHI Akihiko - <email>moro@race.u-tokyo.ac.jp</email></para> + <email>moro@remus.dti.ne.jp</email></para> </listitem> <listitem> @@ -4077,11 +4712,26 @@ </listitem> <listitem> + <para>Manuel Rabade Garcia + <email>mig@mig-29.net</email></para> + </listitem> + + <listitem> + <para>Marc Blanchet + <email>marc.blanchet@viagenie.qc.ca</email></para> + </listitem> + + <listitem> <para>Marc Frajola <email>marc@dev.com</email></para> </listitem> <listitem> + <para>Marc Olzheim + <email>marcolz@stack.nl</email></para> + </listitem> + + <listitem> <para>Marc Ramirez <email>mrami@mramirez.sy.yale.edu</email></para> </listitem> @@ -4108,7 +4758,7 @@ <listitem> <para>Marc van Woerkom - <email>van.woerkom@netcologne.de</email></para> + <email>marc.vanwoerkom@fernuni-hagen.de</email></para> </listitem> <listitem> @@ -4117,11 +4767,21 @@ </listitem> <listitem> + <para>Marcin Jessa + <email>yazzy@yazzy.org</email></para> + </listitem> + + <listitem> <para>Marco Molteni <email>molter@tin.it</email></para> </listitem> <listitem> + <para>Marco van de Voort + <email>marcov@stack.nl</email></para> + </listitem> + + <listitem> <para>Marcus vA <email>mva121@gmx.net</email></para> </listitem> @@ -4132,18 +4792,33 @@ </listitem> <listitem> + <para>Mark Blackman + <email>freebsd-ports@blackmans.org</email></para> + </listitem> + + <listitem> <para>Mark Cammidge <email>mark@gmtunx.ee.uct.ac.za</email></para> </listitem> <listitem> + <para>Mark Daniel Reidel + <email>ports@mark.reidel.info</email></para> + </listitem> + + <listitem> <para>Mark Diekhans <email>markd@grizzly.com</email></para> </listitem> <listitem> + <para>Mark Hannon + <email>markhannon@optusnet.com.au</email></para> + </listitem> + + <listitem> <para>Mark Huizer - <email>xaa@stack.nl</email></para> + <email>xaa+freebsd@timewasters.nl</email></para> </listitem> <listitem> @@ -4152,6 +4827,16 @@ </listitem> <listitem> + <para>Mark J. Miller + <email>joup@bigfoot.com</email></para> + </listitem> + + <listitem> + <para>Mark Johnston + <email>mjohnston@skyweb.ca</email></para> + </listitem> + + <listitem> <para>Mark Knight <email>markk@knigma.org</email></para> </listitem> @@ -4167,6 +4852,11 @@ </listitem> <listitem> + <para>Mark Stosberg + <email>mark@summersault.com</email></para> + </listitem> + + <listitem> <para>Mark Thompson <email>thompson@tgsoft.com</email></para> </listitem> @@ -4197,6 +4887,11 @@ </listitem> <listitem> + <para>Martijn Lina + <email>martijn@pacno.net</email></para> + </listitem> + + <listitem> <para>Martin Birgmeier <email>unknown</email></para> </listitem> @@ -4213,7 +4908,7 @@ <listitem> <para>Martin Kammerhofer - <email>dada@sbox.tu-graz.ac.at</email></para> + <email>mkamm@gmx.net</email></para> </listitem> <listitem> @@ -4262,6 +4957,11 @@ </listitem> <listitem> + <para>Masafumi Otsune + <email>info@otsune.com</email></para> + </listitem> + + <listitem> <para>Masahiro Sekiguchi <email>seki@sysrap.cs.fujitsu.co.jp</email></para> </listitem> @@ -4317,6 +5017,11 @@ </listitem> <listitem> + <para>Matt Emmerton + <email>matt@gsicomp.on.ca</email></para> + </listitem> + + <listitem> <para>Matt Heckaman <email>matt@LUCIDA.QC.CA</email></para> </listitem> @@ -4328,7 +5033,7 @@ <listitem> <para>Matt Lancereau - <email>matt@rimasec.net</email></para> + <email>matt@bsdfly.org</email></para> </listitem> <listitem> @@ -4342,6 +5047,11 @@ </listitem> <listitem> + <para>Matt Smith + <email>matt@xtaz.net</email></para> + </listitem> + + <listitem> <para>Matt Thomas <email>matt@3am-software.com</email></para> </listitem> @@ -4552,11 +5262,6 @@ </listitem> <listitem> - <para>Michael Johnson - <email>ahze@ahze.net</email></para> - </listitem> - - <listitem> <para>Michael Lyngbøl <email>michael@lyngbol.dk</email></para> </listitem> @@ -4567,6 +5272,11 @@ </listitem> <listitem> + <para>Michael O. Boev + <email>mike@tric.tomsk.gov.ru</email></para> + </listitem> + + <listitem> <para>Michael Perlman <email>canuck@caam.rice.edu</email></para> </listitem> @@ -4617,6 +5327,11 @@ </listitem> <listitem> + <para>Michel Lavondés + <email>fox@vader.aacc.cc.md.us</email></para> + </listitem> + + <listitem> <para>Michele Possamai <email>possamai@xs4all.nl</email></para> </listitem> @@ -4633,7 +5348,7 @@ <listitem> <para>Miguel Mendez - <email>flynn@energyhq.homeip.net</email></para> + <email>flynn@energyhq.es.eu.org</email></para> </listitem> <listitem> @@ -4687,6 +5402,16 @@ </listitem> <listitem> + <para>Mike Edenfield + <email>kutulu@kutulu.org</email></para> + </listitem> + + <listitem> + <para>Mike Erickson + <email>mee@quidquam.com</email></para> + </listitem> + + <listitem> <para>Mike Evans <email>mevans@candle.com</email></para> </listitem> @@ -4717,6 +5442,11 @@ </listitem> <listitem> + <para>Mike Lockwood + <email>mike@mikelockwood.com</email></para> + </listitem> + + <listitem> <para>Mike McGaughey <email>mmcg@cs.monash.edu.au</email></para> </listitem> @@ -4737,6 +5467,11 @@ </listitem> <listitem> + <para>Mike Patterson + <email>mike.patterson@unb.ca</email></para> + </listitem> + + <listitem> <para>Mike Peck <email>mike@binghamton.edu</email></para> </listitem> @@ -4752,6 +5487,11 @@ </listitem> <listitem> + <para>Mike Tancsa + <email>mike@sentex.net</email></para> + </listitem> + + <listitem> <para>Mikhail A. Sokolov <email>mishania@demos.su</email></para> </listitem> @@ -4797,6 +5537,11 @@ </listitem> <listitem> + <para>Mustafa Arif + <email>ma499@doc.ic.ac.uk</email></para> + </listitem> + + <listitem> <para>Mykola Khotyaintsev <email>ko@irfu.se</email></para> </listitem> @@ -4813,12 +5558,12 @@ <listitem> <para>NAKAJI Hiroyuki - <email>nakaji@tutrp.tut.ac.jp</email></para> + <email>nakaji@jp.freebsd.org</email></para> </listitem> <listitem> <para>NAKAMURA Kazushi - <email>nkazushi@highway.or.jp</email></para> + <email>kaz@kobe1995.net</email></para> </listitem> <listitem> @@ -4857,6 +5602,11 @@ </listitem> <listitem> + <para>Narayan Namdev Newton + <email>narayannewton@gmail.com</email></para> + </listitem> + + <listitem> <para>Narvi <email>narvi@haldjas.folklore.ee</email></para> </listitem> @@ -4908,7 +5658,7 @@ <listitem> <para>Nick Leuta - <email>skynick@stu.lipetsk.ru</email></para> + <email>skynick@mail.sc.ru</email></para> </listitem> <listitem> @@ -5297,6 +6047,16 @@ </listitem> <listitem> + <para>Olafur Osvaldsson + <email>oli@isnic.is</email></para> + </listitem> + + <listitem> + <para>Oleg Kiselyov + <email>oleg@pobox.com</email></para> + </listitem> + + <listitem> <para>Oleg Semyonov <email>os@altavista.net</email></para> </listitem> @@ -5333,7 +6093,7 @@ <listitem> <para>Oliver Fromme - <email>oliver.fromme@heim3.tu-clausthal.de</email></para> + <email>olli@fromme.com</email></para> </listitem> <listitem> @@ -5352,6 +6112,11 @@ </listitem> <listitem> + <para>Olivier Beyssac + <email>obld@r14.freenix.org</email></para> + </listitem> + + <listitem> <para>Olivier Tharan <email>olive@oban.frmug.org</email></para> </listitem> @@ -5367,6 +6132,11 @@ </listitem> <listitem> + <para>Oscar Bonilla + <email>obonilla@galileo.edu</email></para> + </listitem> + + <listitem> <para>Ozkan KIRIK <email>ozkan@enderunix.org</email></para> </listitem> @@ -5427,6 +6197,11 @@ </listitem> <listitem> + <para>Patrick Dung + <email>patrick_dkt@yahoo.com.hk</email></para> + </listitem> + + <listitem> <para>Patrick Hausen <email>unknown</email></para> </listitem> @@ -5587,6 +6362,11 @@ </listitem> <listitem> + <para>Peter Holub + <email>hopet@ics.muni.cz</email></para> + </listitem> + + <listitem> <para>Peter Jeremy <email>peter.jeremy@alcatel.com.au</email></para> </listitem> @@ -5617,6 +6397,11 @@ </listitem> <listitem> + <para>Peter S. Housel + <email>housel@acm.org</email></para> + </listitem> + + <listitem> <para>Peter Stubbs <email>PETERS@staidan.qld.edu.au</email></para> </listitem> @@ -5627,13 +6412,18 @@ </listitem> <listitem> + <para>Peter van Dijk + <email>peter@dataloss.nl</email></para> + </listitem> + + <listitem> <para>Peter van Heusden <email>pvh@wfeet.za.net</email></para> </listitem> <listitem> <para>Phil Maker - <email>pjm@cs.ntu.edu.au</email></para> + <email>pjm@gnu.org</email></para> </listitem> <listitem> @@ -5657,6 +6447,11 @@ </listitem> <listitem> + <para>Philip Reynolds + <email>philip.reynolds@rfc-networks.ie</email></para> + </listitem> + + <listitem> <para>Philippe Lefebvre <email>nemesis@balistik.net</email></para> </listitem> @@ -5672,6 +6467,11 @@ </listitem> <listitem> + <para>Pieter Danhieux + <email>opr@bsdaemon.be</email></para> + </listitem> + + <listitem> <para>Piotr Smyrak <email>piotr.smyrak@heron.pl</email></para> </listitem> @@ -5711,6 +6511,11 @@ </listitem> <listitem> + <para>Radek Kozlowski + <email>radek@raadradd.com</email></para> + </listitem> + + <listitem> <para>Radim Kolar <email>hsn@netmag.cz</email></para> </listitem> @@ -5757,7 +6562,7 @@ <listitem> <para>Rasmus Kaj - <email>kaj@Raditex.se</email></para> + <email>rasmus@kaj.se</email></para> </listitem> <listitem> @@ -5781,6 +6586,11 @@ </listitem> <listitem> + <para>René C. Ladan + <email>r.c.ladan@student.tue.nl</email></para> + </listitem> + + <listitem> <para>Ricardas Cepas <email>rch@richard.eu.org</email></para> </listitem> @@ -5791,6 +6601,11 @@ </listitem> <listitem> + <para>Rich Morin + <email>rdm@cfcl.com</email></para> + </listitem> + + <listitem> <para>Rich Wood <email>rich@FreeBSD.org.uk</email></para> </listitem> @@ -5921,6 +6736,11 @@ </listitem> <listitem> + <para>Robert Schlotterbeck + <email>robert@rs.tarrant.tx.us</email></para> + </listitem> + + <listitem> <para>Robert Shady <email>rls@id.net</email></para> </listitem> @@ -5946,13 +6766,23 @@ </listitem> <listitem> + <para>Robin Elfrink + <email>elfrink@introweb.nl</email></para> + </listitem> + + <listitem> + <para>Robin Schilham + <email>co9@xs4all.nl</email></para> + </listitem> + + <listitem> <para>Robin Schoonover <email>end@endif.cjb.net</email></para> </listitem> <listitem> <para>Rod Taylor - <email>rod@idiotswitch.org</email></para> + <email>ports@rbt.ca</email></para> </listitem> <listitem> @@ -6006,11 +6836,21 @@ </listitem> <listitem> + <para>Ronald F. Guilmette + <email>rfg@monkeys.com</email></para> + </listitem> + + <listitem> <para>Ronald Kuehn <email>kuehn@rz.tu-clausthal.de</email></para> </listitem> <listitem> + <para>Rong-En Fan + <email>rafan@infor.org</email></para> + </listitem> + + <listitem> <para>Rostislav Krasny <email>rosti_bsd@yahoo.com</email></para> </listitem> @@ -6071,6 +6911,11 @@ </listitem> <listitem> + <para>Ryo MIYAMOTO + <email>rmiya@cc.hirosaki-u.ac.jp</email></para> + </listitem> + + <listitem> <para>Ryuichiro IMURA <email>imura@af.airnet.ne.jp</email></para> </listitem> @@ -6127,7 +6972,7 @@ <listitem> <para>Samuel Tardieu - <email>sam@inf.enst.fr</email></para> + <email>sam@rfc1149.net</email></para> </listitem> <listitem> @@ -6156,6 +7001,11 @@ </listitem> <listitem> + <para>Sarod Yatawatta + <email>sarod@users.sf.net</email></para> + </listitem> + + <listitem> <para>Sascha Blank <email>blank@fox.uni-trier.de</email></para> </listitem> @@ -6191,6 +7041,11 @@ </listitem> <listitem> + <para>Scott Lambert + <email>lambert@lambertfam.org</email></para> + </listitem> + + <listitem> <para>Scott A. Moberly <email>smoberly@xavier.dyndns.org</email></para> </listitem> @@ -6226,6 +7081,11 @@ </listitem> <listitem> + <para>SeaD + <email>sead@mail.ru</email></para> + </listitem> + + <listitem> <para>Seamus Venasse <email>svenasse@polaris.ca</email></para> </listitem> @@ -6306,11 +7166,21 @@ </listitem> <listitem> + <para>Sergey Velichkevych + <email>serg@cad.kiev.ua</email></para> + </listitem> + + <listitem> <para>Sergio Lenzi <email>lenzi@bsi.com.br</email></para> </listitem> <listitem> + <para>Shane Kinney + <email>mod6@freebsdhackers.net</email></para> + </listitem> + + <listitem> <para>Shaun Courtney <email>shaun@emma.eng.uct.ac.za</email></para> </listitem> @@ -6367,7 +7237,7 @@ <listitem> <para>Simon Barner - <email>barner@in.tum.de</email></para> + <email>barner@gmx.de</email></para> </listitem> <listitem> @@ -6392,7 +7262,12 @@ <listitem> <para>Simon Marlow - <email>simonm@dcs.gla.ac.uk</email></para> + <email>simonmar@microsoft.com</email></para> + </listitem> + + <listitem> + <para>Simon Mikecin + <email>sime@logos.hr</email></para> </listitem> <listitem> @@ -6412,7 +7287,7 @@ <listitem> <para>Slaven Rezic - <email>eserte@cs.tu-berlin.de</email></para> + <email>slaven@rezic.de</email></para> </listitem> <listitem> @@ -6451,6 +7326,11 @@ </listitem> <listitem> + <para>Stanislav Grozev + <email>tacho@daemonz.org</email></para> + </listitem> + + <listitem> <para>Stefan A. Deutscher <email>sad@mailaps.org</email></para> </listitem> @@ -6516,6 +7396,11 @@ </listitem> <listitem> + <para>Sten Poldma + <email>exile@chamber.ee</email></para> + </listitem> + + <listitem> <para>Stephane E. Potvin <email>sepotvin@videotron.ca</email></para> </listitem> @@ -6561,6 +7446,16 @@ </listitem> <listitem> + <para>Stephen Montgomery-Smith + <email>stephen@math.missouri.edu</email></para> + </listitem> + + <listitem> + <para>Steve Roome + <email>steve@pepcross.com</email></para> + </listitem> + + <listitem> <para>Stephen Weeks <email>sweeks@sweeks.com</email></para> </listitem> @@ -6592,7 +7487,12 @@ <listitem> <para>Steven Honson - <email>shonson@isoproplex.net</email></para> + <email>steven@honson.org</email></para> + </listitem> + + <listitem> + <para>Steve O'Hara-Smith + <email>steve@sohara.org</email></para> </listitem> <listitem> @@ -6686,6 +7586,11 @@ </listitem> <listitem> + <para>Sven Mohr + <email>svmohr@rm6.net</email></para> + </listitem> + + <listitem> <para>Sybolt de Boer <email>bolt@xs4all.nl</email></para> </listitem> @@ -6776,6 +7681,11 @@ </listitem> <listitem> + <para>Taylor Dondich + <email>tdondich@majiknetworks.com</email></para> + </listitem> + + <listitem> <para>Ted Buswell <email>tbuswell@mediaone.net</email></para> </listitem> @@ -6791,6 +7701,11 @@ </listitem> <listitem> + <para>TERAMOTO Masahiro + <email>markun@onohara.to</email></para> + </listitem> + + <listitem> <para>Terry Lambert <email>terry@lambert.org</email></para> </listitem> @@ -6902,7 +7817,7 @@ <listitem> <para>Thorsten Greiner - <email>thorsten.greiner@web.de</email></para> + <email>thorsten@tgreiner.net</email></para> </listitem> <listitem> @@ -6936,6 +7851,11 @@ </listitem> <listitem> + <para>Tim Pozar + <email>pozar@lns.com</email></para> + </listitem> + + <listitem> <para>Tim Singletary <email>tsingle@sunland.gsfc.nasa.gov</email></para> </listitem> @@ -6961,6 +7881,11 @@ </listitem> <listitem> + <para>Tobias Begalke + <email>tobega@spyz.org</email></para> + </listitem> + + <listitem> <para>Tobias Reifenberger <email>treif@mayn.de</email></para> </listitem> @@ -6981,11 +7906,21 @@ </listitem> <listitem> + <para>Todd Mortensen + <email>todd@thisisa.com</email></para> + </listitem> + + <listitem> <para>Tom <email>root@majestix.cmr.no</email></para> </listitem> <listitem> + <para>Tom Carrick + <email>knyghtmare@knyghtmare.com</email></para> + </listitem> + + <listitem> <para>Tom Gray - DCA <email>dcasba@rain.org</email></para> </listitem> @@ -6997,7 +7932,7 @@ <listitem> <para>Tom McLaughlin - <email>tom@tmclaugh@sdf.lonestar.org</email></para> + <email>tmclaugh@sdf.lonestar.org</email></para> </listitem> <listitem> @@ -7006,6 +7941,11 @@ </listitem> <listitem> + <para>Tom Mueller-Kortkamp + <email>tmueko@kommunity.net</email></para> + </listitem> + + <listitem> <para>Tom Pusateri <email>pusateri@juniper.net</email></para> </listitem> @@ -7026,6 +7966,11 @@ </listitem> <listitem> + <para>Toni Andjelkovic + <email>toni@soth.at</email></para> + </listitem> + + <listitem> <para>Toni Viemero <email>toni.viemero@iki.fi</email></para> </listitem> @@ -7101,6 +8046,11 @@ </listitem> <listitem> + <para>Trevor Cornpropst + <email>tcornpropst@cox.net</email></para> + </listitem> + + <listitem> <para>UMENO Takashi <email>umeno@rr.iij4u.or.jp</email></para> </listitem> @@ -7112,7 +8062,7 @@ <listitem> <para>Udo Schweigert - <email>ust@cert.siemens.de</email></para> + <email>udo.schweigert@siemens.com</email></para> </listitem> <listitem> @@ -7161,6 +8111,11 @@ </listitem> <listitem> + <para>Vadim Kurland + <email>vadim@fwbuilder.org</email></para> + </listitem> + + <listitem> <para>Vadim Mikhailov <email>mvp@braz.ru</email></para> </listitem> @@ -7270,6 +8225,11 @@ </listitem> <listitem> + <para>Vladimir Osintsev + <email>oc@nm.ru</email></para> + </listitem> + + <listitem> <para>Vladimir Savichev <email>vlad@ariel.phys.wesleyan.edu</email></para> </listitem> @@ -7340,6 +8300,11 @@ </listitem> <listitem> + <para>Wesley Shields + <email>wxs@csh.rit.edu</email></para> + </listitem> + + <listitem> <para>Wietse Venema <email>wietse@wzv.win.tue.nl</email></para> </listitem> @@ -7356,7 +8321,7 @@ <listitem> <para>Willem Jan Withagen - <email>wjw@surf.IAE.nl</email></para> + <email>wjw@withagen.nl</email></para> </listitem> <listitem> @@ -7419,6 +8384,11 @@ </listitem> <listitem> + <para>Yann Berthier + <email>yb@bachibouzouk.org</email></para> + </listitem> + + <listitem> <para>Yannis Kotsinos <email>zookie@med.auth.gr</email></para> </listitem> @@ -7474,11 +8444,21 @@ </listitem> <listitem> + <para>Yuan-Chung Hsiao + <email>ychsiao@ychsiao.idv.tw</email></para> + </listitem> + + <listitem> <para>Yuri Kurenkov <email>y.kurenkov@init.ru</email></para> </listitem> <listitem> + <para>Yuriy N. Shkandybin + <email>jura@netams.com</email></para> + </listitem> + + <listitem> <para>Yoshihiko SARUMRU <email>mistral@imasy.or.jp</email></para> </listitem> @@ -7579,6 +8559,11 @@ </listitem> <listitem> + <para>Zachariah Thompson + <email>lin-chi@lastamericanempire.com</email></para> + </listitem> + + <listitem> <para>Zahemszhky Gabor <email>zgabor@code.hu</email></para> </listitem> diff --git a/en_US.ISO8859-1/articles/contributors/contrib.committers.sgml b/en_US.ISO8859-1/articles/contributors/contrib.committers.sgml index b92a138a69..332a128920 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.committers.sgml +++ b/en_US.ISO8859-1/articles/contributors/contrib.committers.sgml @@ -531,6 +531,10 @@ </listitem> <listitem> + <para>&a.ahze;</para> + </listitem> + + <listitem> <para>&a.trevor;</para> </listitem> @@ -727,6 +731,10 @@ </listitem> <listitem> + <para>&a.remko;</para> + </listitem> + + <listitem> <para>&a.scottl;</para> </listitem> @@ -883,6 +891,10 @@ </listitem> <listitem> + <para>&a.gnn;</para> + </listitem> + + <listitem> <para>&a.simon;</para> </listitem> diff --git a/en_US.ISO8859-1/articles/contributors/contrib.staff.sgml b/en_US.ISO8859-1/articles/contributors/contrib.staff.sgml index acbb2da4b5..8d15e4e7bc 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.staff.sgml +++ b/en_US.ISO8859-1/articles/contributors/contrib.staff.sgml @@ -153,35 +153,35 @@ <itemizedlist> <listitem> - <para>&a.rwatson;</para> + <para>&a.josef;</para> </listitem> <listitem> - <para>&a.bms;</para> + <para>&a.imp;</para> </listitem> <listitem> - <para>&a.cperciva;</para> + <para>&a.simon;</para> </listitem> <listitem> - <para>&a.des;</para> + <para>&a.cperciva;</para> </listitem> <listitem> - <para>&a.gshapiro;</para> + <para>&a.trhodes;</para> </listitem> <listitem> - <para>&a.guido;</para> + <para>&a.gshapiro;</para> </listitem> <listitem> - <para>&a.imp;</para> + <para>&a.des;</para> </listitem> <listitem> - <para>&a.julian;</para> + <para>&a.guido;</para> </listitem> <listitem> @@ -189,7 +189,7 @@ </listitem> <listitem> - <para>&a.trhodes;</para> + <para>&a.rwatson;</para> </listitem> </itemizedlist> </sect2> diff --git a/en_US.ISO8859-1/articles/java-tomcat/article.sgml b/en_US.ISO8859-1/articles/java-tomcat/article.sgml index 62b421d349..70acdbce27 100644 --- a/en_US.ISO8859-1/articles/java-tomcat/article.sgml +++ b/en_US.ISO8859-1/articles/java-tomcat/article.sgml @@ -127,7 +127,7 @@ <para>The Tomcat portion of the install is very straight forward, but the difficulty I had was getting &java; Development Kit up and running for FreeBSD 4.X, as Sun Microsystems only supplies - Binaries for Linux, &solaris;, and &windowsnt;. This means that I + binaries for Linux, &solaris;, and &windowsnt;. This means that I had to compile my own &jdk; for FreeBSD. I began by searching for documentation on the Internet. I quickly found that there is more source code than I need along with patches to the source code, but diff --git a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml index b017856fae..95ccb7b43d 100644 --- a/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml +++ b/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml @@ -364,7 +364,6 @@ DEV_MODULE(echo,echo_loader,NULL);</programlisting> #include <sys/malloc.h> #define BUFFERSIZE 256 -#define CDEV_MAJOR 33 /* Function prototypes */ @@ -375,12 +374,12 @@ static d_write_t echo_write; /* Character device entry points */ static struct cdevsw echo_cdevsw = { + .d_version = D_VERSION, .d_open = echo_open, .d_close = echo_close, - .d_maj = CDEV_MAJOR, - .d_name = "echo", .d_read = echo_read, - .d_write = echo_write + .d_write = echo_write, + .d_name = "echo", }; typedef struct s_echo { @@ -389,7 +388,7 @@ typedef struct s_echo { } t_echo; /* vars */ -static dev_t echo_dev; +static struct cdev *echo_dev; static int count; static t_echo *echomsg; @@ -415,12 +414,12 @@ echo_loader(struct module *m, int what, void *arg) 0600, "echo"); /* kmalloc memory for use by this driver */ - MALLOC(echomsg, t_echo *, sizeof(t_echo), M_ECHOBUF, M_WAITOK); + echomsg = malloc(sizeof(t_echo), M_ECHOBUF, M_WAITOK); printf("Echo device loaded.\n"); break; case MOD_UNLOAD: destroy_dev(echo_dev); - FREE(echomsg,M_ECHOBUF); + free(echomsg, M_ECHOBUF); printf("Echo device unloaded.\n"); break; default: @@ -431,7 +430,7 @@ echo_loader(struct module *m, int what, void *arg) } static int -echo_open(dev_t dev, int oflags, int devtype, struct thread *p) +echo_open(struct cdev *dev, int oflags, int devtype, struct thread *p) { int err = 0; @@ -440,7 +439,7 @@ echo_open(dev_t dev, int oflags, int devtype, struct thread *p) } static int -echo_close(dev_t dev, int fflag, int devtype, struct thread *p) +echo_close(struct cdev *dev, int fflag, int devtype, struct thread *p) { uprintf("Closing device \"echo.\"\n"); return(0); @@ -453,7 +452,7 @@ echo_close(dev_t dev, int fflag, int devtype, struct thread *p) */ static int -echo_read(dev_t dev, struct uio *uio, int ioflag) +echo_read(struct cdev *dev, struct uio *uio, int ioflag) { int err = 0; int amt; @@ -476,7 +475,7 @@ echo_read(dev_t dev, struct uio *uio, int ioflag) */ static int -echo_write(dev_t dev, struct uio *uio, int ioflag) +echo_write(struct cdev *dev, struct uio *uio, int ioflag) { int err = 0; diff --git a/en_US.ISO8859-1/books/faq/book.sgml b/en_US.ISO8859-1/books/faq/book.sgml index 2385f10b37..f702f4e2fb 100644 --- a/en_US.ISO8859-1/books/faq/book.sgml +++ b/en_US.ISO8859-1/books/faq/book.sgml @@ -6,7 +6,7 @@ <book> <bookinfo> - <title>Frequently Asked Questions for FreeBSD 2.X, 3.X, 4.X and 5.X</title> + <title>Frequently Asked Questions for FreeBSD 2.X, 3.X, 4.X, 5.X, and 6.X</title> <corpauthor>The FreeBSD Documentation Project</corpauthor> @@ -53,7 +53,7 @@ </legalnotice> <abstract> - <para>This is the FAQ for FreeBSD versions 2.X, 3.X, 4.X and 5.X. + <para>This is the FAQ for FreeBSD versions 2.X, 3.X, 4.X, 5.X, and 6.X. All entries are assumed to be relevant to FreeBSD 2.0.5 and later, unless otherwise noted. If you are interested in helping with this project, send email to the &a.doc;. The @@ -73,7 +73,7 @@ <chapter id="introduction"> <title>Introduction</title> - <para>Welcome to the FreeBSD 2.X-5.X FAQ!</para> + <para>Welcome to the FreeBSD 2.X-6.X FAQ!</para> <para>As is usual with Usenet FAQs, this document aims to cover the most frequently asked questions concerning the FreeBSD operating @@ -278,17 +278,28 @@ </question> <!-- - This answer is a hack to deal with the fact that for now there are two - "latest" versions of FreeBSD. + This answer is a hack to deal with the fact that for now there are + multiple "latest" versions of FreeBSD. --> <answer> - <para>At this point in FreeBSD's development, there are two + <para>At this point in FreeBSD's development, there are three parallel development branches; releases are being made from - both branches. The 4.X series of releases - is being made from the <emphasis>-STABLE</emphasis> branch + two of the three branches. The 4.X series of releases + is being made from the <emphasis>4-STABLE</emphasis> branch and the 5.X series of releases is being made from - <emphasis>-CURRENT</emphasis>.</para> + <emphasis>5-STABLE</emphasis>. It will be some time yet + before any releases are made from the + <emphasis>6-CURRENT</emphasis> branch.</para> + + <para>Up until the release of 5.3, the 4.X series was the + one known as <emphasis>-STABLE</emphasis>. However, + as of 5.3, 5.X has been designated the new + <emphasis>-STABLE</emphasis> and 4.X will no longer see + much new development. Instead, it will be designated + for an "extended support" status and receive + only fixes for major problems (such as security-related + fixes.)</para> <para>Version <ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/&rel.current;-RELEASE/">&rel.current;</ulink> @@ -421,9 +432,9 @@ only well-tested bug fixes and other small incremental enhancements. FreeBSD-CURRENT, on the other hand, has been one unbroken line since 2.0 was released, leading - towards 5.2.1-RELEASE (and beyond). At 5.3-RELEASE, the - 5-STABLE branch is expected to be created, and - &os.current; will become 6-CURRENT. More detail information, + towards 5.3-RELEASE (and beyond). Just before 5.3-RELEASE, the + 5-STABLE branch was created, and + &os.current; became 6-CURRENT. More detail information, see <quote><ulink url="&url.articles.releng;/release-proc.html"> FreeBSD Release Engineering: 2.2.1 Creating the Release Branch</ulink></quote>.</para> @@ -432,15 +443,14 @@ The 3-STABLE branch has ended with the release of 3.5.1, the final 3.X release. The only changes made to either of these branches will be, for the most part, security-related bug - fixes.</para> + fixes. Support for the 4-STABLE branch will continue + for some time but focus primarily on security-related bug + fixes and other serious issues.</para> -<!-- temporarily commented out until 5.3R is released --> -<!-- <para>5-STABLE is the actively developed -STABLE branch. The latest release on the 5-STABLE branch is &rel2.current;-RELEASE, which was released in &rel2.current.date;.</para> ---> <para>The 6-CURRENT branch is the actively developed -CURRENT branch toward the next generation of &os;. @@ -513,7 +523,7 @@ <itemizedlist> <listitem> - <para>The latest 5.X release, &rel.current;-RELEASE can be + <para>The latest release, &rel.current;-RELEASE can be found in the <ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/&rel.current;-RELEASE/">&rel.current;-RELEASE directory</ulink>.</para> </listitem> @@ -521,21 +531,21 @@ <listitem> <para><ulink url="ftp://current.FreeBSD.org/pub/FreeBSD/"> - 5.X Snapshot</ulink> releases are made daily for the + Snapshot</ulink> releases are made daily for the <link linkend="current">-CURRENT</link> branch, these being of service purely to bleeding-edge testers and developers.</para> </listitem> <listitem> - <para>The latest 4-STABLE release, &rel2.current;-RELEASE can be + <para>The latest 5-STABLE release, &rel2.current;-RELEASE can be found in the <ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/&rel2.current;-RELEASE/">&rel2.current;-RELEASE directory</ulink>.</para> </listitem> <listitem> <para><ulink - url="ftp://current.FreeBSD.org/pub/FreeBSD/snapshots/">4.X + url="ftp://current.FreeBSD.org/pub/FreeBSD/snapshots/">5.X snapshots</ulink> are usually made daily.</para> </listitem> </itemizedlist> @@ -4406,7 +4416,7 @@ kern.timecounter.hardware: TSC -> i8254</screen> 2003</attribution> <para>These warnings are generated by Witness, a run-time lock - diagnostic system found in FreeBSD 5-CURRENT kernels (but + diagnostic system found in FreeBSD -CURRENT kernels (but removed in releases). You can read more about Witness in the &man.witness.4; man page, which talks about its capabilities. Among other things, Witness performs run-time lock order verification @@ -4816,7 +4826,7 @@ kern.timecounter.hardware: TSC -> i8254</screen> linkend="mailing">mailing list</link> for periodic updates on new entries.</para> - <para>Most ports should work on the 4.X and 5.X branches. + <para>Most ports should work on the 4.X, 5.X, and 6.X branches. Each time a FreeBSD release is made, a snapshot of the ports tree at the time of release in also included in the <filename>ports/</filename> directory.</para> @@ -4853,13 +4863,22 @@ kern.timecounter.hardware: TSC -> i8254</screen> </varlistentry> <varlistentry> - <term>for 5.X-CURRENT</term> + <term>for 5.X-RELEASE/5-STABLE</term> <listitem> <para><ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/"> ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current</ulink></para> </listitem> </varlistentry> + + <varlistentry> + <term>for 6-CURRENT</term> + <listitem> + <para><ulink + url="ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-current/"> + ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-current</ulink></para> + </listitem> + </varlistentry> </variablelist> <para>or your nearest local mirror site.</para> @@ -6209,8 +6228,8 @@ C:\="DOS"</programlisting> <para>Enabling <varname>vfs.usermount</varname>, however, has negative security implications. A better way to - access &ms-dos; formatted media is to use the <ulink - url="http://www.FreeBSD.org/cgi/ports.cgi?query=%5Emtools-&stype=name">mtools</ulink> + access &ms-dos; formatted media is to use the + <filename role="package">emulators/mtools</filename> package in the ports collection.</para> </answer> </qandaentry> @@ -6749,7 +6768,7 @@ options SYSVMSG # enable for messaging</programlisting> </question> <answer> - <para>FreeBSD 5.X uses the &man.devfs.8; device-on-demand + <para>FreeBSD 5.X and beyond use the &man.devfs.8; device-on-demand system. Device drivers automatically create new device nodes as they are needed, obsoleting <filename>/dev/MAKEDEV</filename>.</para> @@ -6863,7 +6882,7 @@ options SYSVMSG # enable for messaging</programlisting> <qandaentry> <question id="release-candidate"> <para>I tried to update my system to the latest -STABLE, but - got -RC or -PRERELEASE! What is going on?</para> + got -BETAx, -RC or -PRERELEASE! What is going on?</para> </question> <answer> @@ -7774,7 +7793,7 @@ ttyvb "/usr/libexec/getty Pc" cons25 off secure</programlisting> &prompt.root; <userinput>sh MAKEDEV vty12</userinput></screen> <note> - <para>On FreeBSD 5.X you do not have to create devices + <para>On FreeBSD 5.X and beyond you do not have to create devices manually if you are using <literal>DEVFS</literal>, since the proper device nodes will be automatically created under <filename @@ -7838,9 +7857,7 @@ ttyvb "/usr/libexec/getty Pc" cons25 off secure</programlisting> </question><answer> <para>There are two schools of thought on how to start - <ulink - url="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=xdm"> - xdm</ulink>. One school starts xdm from + &man.xdm.1;. One school starts xdm from <filename>/etc/ttys</filename> (see &man.ttys.5;) using the supplied example, while the other simply runs xdm from <filename>rc.local</filename> (see &man.rc.8;) or from a @@ -11796,19 +11813,19 @@ raisechar=^^</programlisting> <itemizedlist> <listitem> - <para><literal>RELENG_3</literal> AKA - <emphasis>3.X-STABLE</emphasis></para> + <para><literal>RELENG_4</literal> AKA + <emphasis>4-STABLE</emphasis></para> </listitem> <listitem> - <para><literal>RELENG_4</literal> AKA - <emphasis>4-STABLE</emphasis></para> + <para><literal>RELENG_5</literal> AKA + <emphasis>5-STABLE</emphasis></para> </listitem> <listitem> <para><literal>HEAD</literal> AKA <emphasis>-CURRENT</emphasis> AKA - <emphasis>5.X-CURRENT</emphasis></para> + <emphasis>6.X-CURRENT</emphasis></para> </listitem> </itemizedlist> @@ -11819,10 +11836,13 @@ raisechar=^^</programlisting> stream</emphasis></quote> which we simply refer to as <quote>-CURRENT</quote>.</para> - <para>Right now, <quote>-CURRENT</quote> is the 5.X development - stream and the <literal>4-STABLE</literal> branch, + <para>Right now, <quote>-CURRENT</quote> is the 6.X development + stream; the <literal>4-STABLE</literal> branch, <symbol>RELENG_4</symbol>, forked off from - <quote>-CURRENT</quote> in Mar 2000.</para> + <quote>-CURRENT</quote> in March 2000, and + the <literal>5-STABLE</literal> branch, + <symbol>RELENG_5</symbol>, forked off from + <quote>-CURRENT</quote> in October 2004.</para> </answer> </qandaentry> diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.sgml b/en_US.ISO8859-1/books/handbook/config/chapter.sgml index 1db6cec9df..8d396b81bc 100644 --- a/en_US.ISO8859-1/books/handbook/config/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/config/chapter.sgml @@ -341,21 +341,18 @@ such as <filename role="package">mail/postfix</filename> or <filename role="package">www/apache13</filename> are just two of the many software packages which may be started during system - initialization. Thus it is only fair that an explanation be - provided on the procedures available for working with third - party software, in the rare cases something goes wrong and the - application does not start up properly.</para> + initialization. This section explains the procedures available + for starting third party software.</para> <para>In &os;, most included services, such as &man.cron.8;, are started through the system start up scripts. These scripts may - different depending on &os; or vendor version; however, the most + differ depending on &os; or vendor version; however, the most important aspect to consider is that their start up configuration can be handled through simple startup scripts.</para> - <para>Since the advent of rcNG, it became clear that system - initialization for third party utilities could be simplified. - For years applications would drop a simple start up script into - the <filename role="directory">/usr/local/etc/rc.d</filename> + <para>Before the advent of rcNG, applications would drop a + simple start up script into the + <filename role="directory">/usr/local/etc/rc.d</filename> directory which would be read by the system initialization scripts. These scripts would then be executed during the latter stages of system start up.</para> @@ -364,17 +361,16 @@ old configuration style into the new system, the fact remains that some third party utilities still require a script simply dropped into the aforementioned directory. The subtle differences - in the scripts depend whether or not rcNG is being used. Any - version of &os; prior to 5.1 will not require the extra bit of - configuration; indeed, in almost all cases the soon to be - recognized script would do just fine.</para> + in the scripts depend whether or not rcNG is being used. Prior + to &os; 5.1 the old configuration style is used and in + almost all cases a new style script would do just fine.</para> <para>While every script must meet some minimal requirements, most of the time these requirements are &os; version agnostic. Each script must have a <filename>.sh</filename> extension appended to the end and every script must be executable by the system. The latter may be achieved by using - the <command>chmod</command> and setting the unique permissions + the <command>chmod</command> command and setting the unique permissions of <literal>755</literal>. There should also be, at minimal, an option to <literal>start</literal> the application and an option to <literal>stop</literal> the application.</para> @@ -490,14 +486,14 @@ run_rc_command "$1"</programlisting> utility from the ports collection with a configuration line appended to the <filename>/etc/inetd.conf</filename> file, or uncommenting one of the current configuration lines. Working - with <command>inetd</command> and its configuration is + with <application>inetd</application> and its configuration is described in depth in the <link linkend="network-inetd">inetd</link> section.</para> <para>In some cases, it may be more plausible to use the &man.cron.8; daemon to start system services. This approach has a number of advantages because <command>cron</command> runs - these processes as the <command>crontab</command>'s file + these processes as the <filename>crontab</filename>'s file owner. This allows regular users to start and maintain some applications.</para> @@ -546,13 +542,13 @@ run_rc_command "$1"</programlisting> <note> <para>User crontabs allow individual users to schedule tasks without the - need for root privileges. Commands in a user's crontab run with the + need for <username>root</username> privileges. Commands in a user's crontab run with the permissions of the user who owns the crontab.</para> <para>The <username>root</username> user can have a user crontab just like any other user. This one is different from <filename>/etc/crontab</filename> (the system crontab). Because of the - system crontab, there's usually no need to create a user crontab + system crontab, there is usually no need to create a user crontab for <username>root</username>.</para> </note> @@ -2512,19 +2508,19 @@ device_probe_and_attach: cbb0 attach returned 12</screen> </listitem> <listitem> - <para>The &man.dmesg.8; output after <quote>boot - <option>-v</option></quote>, including any error messages + <para>The &man.dmesg.8; output after <command>boot + -v</command>, including any error messages generated by you exercising the bug.</para> </listitem> <listitem> - <para>The &man.dmesg.8; output from <quote>boot - <option>-v</option></quote> with <acronym>ACPI</acronym> + <para>The &man.dmesg.8; output from <command>boot + -v</command> with <acronym>ACPI</acronym> disabled, if disabling it helps fix the problem.</para> </listitem> <listitem> - <para>Output from <quote>sysctl hw.acpi</quote>. This is also + <para>Output from <command>sysctl hw.acpi</command>. This is also a good way of figuring out what features your system offers.</para> </listitem> @@ -2626,27 +2622,27 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <literal>S4</literal><acronym>OS</acronym> is implemented entirely by the operating system.</para> - <para>Start by checking <command>sysctl</command> - <option>hw.acpi</option> for the suspend-related items. Here - are the results for my Thinkpad:</para> + <para>Start by checking <command>sysctl hw.acpi</command> + for the suspend-related items. Here + are the results for a Thinkpad:</para> - <screen>hw.acpi.supported_sleep_state: S3 S4 S5</screen> - <screen>hw.acpi.s4bios: 0</screen> + <screen>hw.acpi.supported_sleep_state: S3 S4 S5 +hw.acpi.s4bios: 0</screen> - <para>This means that I can use <command>acpiconf -s</command> + <para>This means that we can use <command>acpiconf -s</command> to test <literal>S3</literal>, <literal>S4</literal><acronym>OS</acronym>, and <literal>S5</literal>. If <option>s4bios</option> was one - (<literal>1</literal>), I would have + (<literal>1</literal>), we would have <literal>S4</literal><acronym>BIOS</acronym> support instead of <literal>S4</literal> <acronym>OS</acronym>.</para> <para>When testing suspend/resume, start with <literal>S1</literal>, if supported. This state is most - likely to work since it doesn't require much driver support. + likely to work since it does not require much driver support. No one has implemented <literal>S2</literal> but if you have - it, it's similar to <literal>S1</literal>. The next thing + it, it is similar to <literal>S1</literal>. The next thing to try is <literal>S3</literal>. This is the deepest <acronym>STR</acronym> state and requires a lot of driver support to properly reinitialize your hardware. If you have @@ -2658,15 +2654,15 @@ device_probe_and_attach: cbb0 attach returned 12</screen> your kernel as possible. If it works, you can narrow down which driver is the problem by loading drivers until it fails again. Typically binary drivers like - <filename>nvidia.ko</filename>, <application>X11</application> + <filename>nvidia.ko</filename>, X11 display drivers, and <acronym>USB</acronym> will have the most problems while Ethernet interfaces usually work fine. If you - can load/unload the drivers ok, you can automate this by + can properly load/unload the drivers, you can automate this by putting the appropriate commands in <filename>/etc/rc.suspend</filename> and <filename>/etc/rc.resume</filename>. There is a commented-out example for unloading and loading a driver. Try - setting <option>hw.acpi.reset_video</option> to zero (0) if + setting <option>hw.acpi.reset_video</option> to zero (<literal>0</literal>) if your display is messed up after resume. Try setting longer or shorter values for <option>hw.acpi.sleep_delay</option> to see if that helps.</para> @@ -2674,7 +2670,7 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <para>Another thing to try is load a recent Linux distribution with <acronym>ACPI</acronym> support and test their suspend/resume support on the same hardware. If it works - on Linux, it's likely a &os; driver problem and narrowing down + on Linux, it is likely a &os; driver problem and narrowing down which driver causes the problems will help us fix the problem. Note that the <acronym>ACPI</acronym> maintainers do not usually maintain other drivers (e.g sound, @@ -2715,7 +2711,7 @@ device_probe_and_attach: cbb0 attach returned 12</screen> system appears hung, try breaking to <acronym>DDB</acronym> (<keycombo action="simul"><keycap>CTRL</keycap> <keycap>ALT</keycap><keycap>ESC</keycap></keycombo> on - console) and type <option>show interrupts</option>.</para> + console) and type <literal>show interrupts</literal>.</para> <para>Your best hope when dealing with interrupt problems is to try disabling <acronym>APIC</acronym> support with @@ -2730,11 +2726,11 @@ device_probe_and_attach: cbb0 attach returned 12</screen> are the top priority to be fixed. The first step is to isolate the steps to reproduce the panic (if possible) and get a backtrace. Follow the advice for enabling - <option>options DDB</option> and setting up a serial console + <literal>options DDB</literal> and setting up a serial console (see <xref linkend="serialconsole-ddb">) or setting up a &man.dump.8; partition. You can get a backtrace in <acronym>DDB</acronym> with - <option>tr</option>. If you have to handwrite the + <literal>tr</literal>. If you have to handwrite the backtrace, be sure to at least get the lowest five (5) and top five (5) lines in the trace.</para> @@ -2748,10 +2744,10 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <sect3> <title>System Powers Up After Suspend or Shutdown</title> <para>First, try setting - <option>hw.acpi.disable_on_poweroff=</option><quote>0</quote> + <literal>hw.acpi.disable_on_poweroff="0"</literal> in &man.loader.conf.5;. This keeps <acronym>ACPI</acronym> from disabling various events during the shutdown process. - Some systems need this value set to <quote>1</quote> (the + Some systems need this value set to <literal>1</literal> (the default) for the same reason. This usually fixes the problem of a system powering up spontaneously after a suspend or poweroff.</para> @@ -2814,13 +2810,13 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <acronym>ACPI</acronym> work without any user intervention. At this point, however, we are still developing workarounds for common mistakes made by the <acronym>BIOS</acronym> vendors. - The Microsoft interpreter (<filename>acpi.sys</filename> and + The µsoft; interpreter (<filename>acpi.sys</filename> and <filename>acpiec.sys</filename>) does not strictly check for adherence to the standard, and thus many <acronym>BIOS</acronym> - vendors who only test <acronym>ACPI</acronym> under Windows + vendors who only test <acronym>ACPI</acronym> under &windows; never fix their <acronym>ASL</acronym>. We hope to continue to identify and document exactly what non-standard behavior is - allowed by Microsoft's interpreter and replicate it so &os; can + allowed by µsoft;'s interpreter and replicate it so &os; can work without forcing users to fix the <acronym>ASL</acronym>. As a workaround and to help us identify behavior, you can fix the <acronym>ASL</acronym> manually. If this works for you, @@ -2836,10 +2832,10 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <title>_OS dependencies</title> <para>Some <acronym>AML</acronym> assumes the world consists of - various Windows versions. You can tell &os; to claim it is + various &windows; versions. You can tell &os; to claim it is any <acronym>OS</acronym> to see if this fixes problems you may have. An easy way to override this is to set - <option>hw.acpi.osname</option>=<quote>Windows 2001</quote> + <literal>hw.acpi.osname="Windows 2001"</literal> in <filename>/boot/loader.conf</filename> or other similar strings you find in the <acronym>ASL</acronym>.</para> </sect3> @@ -2907,9 +2903,9 @@ acpi_dsdt_name="/boot/DSDT.aml"</programlisting> page.</para> <para>Debugging output is not enabled by default. To enable it, - add <option>options ACPI_DEBUG</option> to your kernel config + add <literal>options ACPI_DEBUG</literal> to your kernel configuration file if <acronym>ACPI</acronym> is compiled into the kernel. You can - add <option>ACPI_DEBUG=1</option> to your + add <literal>ACPI_DEBUG=1</literal> to your <filename>/etc/make.conf</filename> to enable it globally. If it is a module, you can recompile just your <filename>acpi.ko</filename> module as follows:</para> diff --git a/en_US.ISO8859-1/books/handbook/disks/chapter.sgml b/en_US.ISO8859-1/books/handbook/disks/chapter.sgml index 0238165d4d..72ffbb468d 100644 --- a/en_US.ISO8859-1/books/handbook/disks/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/disks/chapter.sgml @@ -173,7 +173,7 @@ be <devicename>da1</devicename> and we want to mount it on <filename>/1</filename> (if you are adding an IDE drive, the device name will be <devicename>wd1</devicename> in pre-4.0 systems, or - <devicename>ad1</devicename> in most 4.X systems).</para> + <devicename>ad1</devicename> in 4.X and 5.X systems).</para> <indexterm><primary>partitions</primary></indexterm> <indexterm><primary>slices</primary></indexterm> diff --git a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml index fe7a8300b9..57df59789a 100644 --- a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -457,6 +457,11 @@ </row> <row> + <entry>&a.usb.name;</entry> + <entry>Discussing &os; support for USB</entry> + </row> + + <row> <entry>&a.vuxml.name;</entry> <entry>Discussion on VuXML infrastructure</entry> </row> @@ -1263,6 +1268,18 @@ </varlistentry> <varlistentry> + <term>&a.usb.name;</term> + + <listitem> + <para><emphasis>Discussing &os; support for + USB</emphasis></para> + + <para>This is a mailing list for technical discussions + related to &os; support for USB.</para> + </listitem> + </varlistentry> + + <varlistentry> <term>&a.usergroups.name;</term> <listitem> diff --git a/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml b/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml index e0047bc751..df71a7246a 100644 --- a/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml @@ -1015,7 +1015,7 @@ device ses # SCSI Environmental Services (and SAF-TE)</programli you have only IDE hardware, you can remove them completely.</para> <note> - <para>The USB &man.umass.4; driver (and a few other drivers) use + <para>The USB &man.umass.4; driver and a few other drivers use the SCSI subsystem even though they are not real SCSI devices. Therefore make sure not to remove SCSI support, if any such drivers are included in the kernel configuration.</para> diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml index d055af3c84..b1619fd828 100644 --- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -43,6 +43,14 @@ <itemizedlist> <listitem> <address> + <otheraddr>BSD-Systems</otheraddr> + Email: <email>info@bsd-systems.co.uk</email> + WWW: <otheraddr><ulink url="http://www.bsd-systems.co.uk"></ulink></otheraddr> + </address> + </listitem> + + <listitem> + <address> <otheraddr>Daemon News Mall</otheraddr> <street>560 South State Street, Suite A2</street> <city>Orem</city>, <state>UT</state> <postcode>84058</postcode> @@ -381,6 +389,11 @@ freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs (ssh only - no password)</para> </listitem> + <listitem> + <para><emphasis>USA</emphasis>: + anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (ssh only - no + password)</para> + </listitem> </itemizedlist> <para>Since CVS allows one to <quote>check out</quote> virtually @@ -1139,10 +1152,6 @@ <programlisting>*default base=/var/db</programlisting> - <para>This setting is used by default if it is not specified - in the <filename>supfile</filename>, so we actually do not - need the above line.</para> - <para>If your base directory does not already exist, now would be a good time to create it. The <command>cvsup</command> client will refuse to run if the base directory does not @@ -1233,8 +1242,8 @@ src-all</programlisting> server. The <filename>refuse</filename> file can be found (or, if you do not yet have one, should be placed) in <filename><replaceable>base</replaceable>/sup/</filename>. - <replaceable>base</replaceable> is defined in your <filename>supfile</filename>; by - default, <replaceable>base</replaceable> is + <replaceable>base</replaceable> is defined in your <filename>supfile</filename>; + our defined <replaceable>base</replaceable> is <filename>/var/db</filename>, which means that by default the <filename>refuse</filename> file is <filename>/var/db/sup/refuse</filename>.</para> @@ -2282,6 +2291,15 @@ doc/zh_*</screen> </varlistentry> <varlistentry> + <term>RELENG_5_3</term> + + <listitem> + <para>The release branch for FreeBSD-5.3, used only + for security advisories and other critical fixes.</para> + </listitem> + </varlistentry> + + <varlistentry> <term>RELENG_5_2</term> <listitem> @@ -2430,6 +2448,14 @@ doc/zh_*</screen> <variablelist> <varlistentry> + <term>RELENG_5_3_0_RELEASE</term> + + <listitem> + <para>FreeBSD 5.3</para> + </listitem> + </varlistentry> + + <varlistentry> <term>RELENG_4_10_0_RELEASE</term> <listitem> diff --git a/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml b/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml index 398c83a282..4d8426a9a5 100644 --- a/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml @@ -209,7 +209,7 @@ supported by the &man.snd.emu10k1.4; driver. To add the support for this card, use the following:</para> - <programlisting>device snd_emu10k1</programlisting> + <programlisting>device "snd_emu10k1"</programlisting> <para>Be sure to read the manual page of the driver for the syntax to use. Information regarding the syntax of sound @@ -1815,7 +1815,27 @@ device `epson:/dev/uscanner0' is a Epson GT-8200 flatbed scanner</screen> <screen>&prompt.root; <userinput>pw groupmod operator -m <replaceable>joe</replaceable></userinput></screen> - <para>For more details read the &man.pw.8; manual page.</para> + <para>For more details read the &man.pw.8; manual page. You + also have to set the correct write permissions (0660 or 0664) + on the <filename>/dev/uscanner0</filename> device node, by + default the <groupname>operator</groupname> group can only + read the device node. This is done by adding the following + lines to the <filename>/etc/devfs.rules</filename> file:</para> + + <programlisting>[system=5] +add path uscanner0 mode 660</programlisting> + + <para>Then add the following to + <filename>/etc/rc.conf</filename> and reboot the + machine:</para> + + <programlisting>devfs_system_ruleset="system"</programlisting> + + <para>More information regarding these lines can be found in the + &man.devfs.8; manual page. Under &os; 4.X, the + <groupname>operator</groupname> group has, by default, read + and write permissions to + <filename>/dev/uscanner0</filename>.</para> <note> <para>Of course, for security reasons, you should think twice diff --git a/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml b/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml index ac42b388f6..1cb2826b08 100644 --- a/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml @@ -111,12 +111,12 @@ <para>&man.inetd.8; is referred to as the <quote>Internet Super-Server</quote> because it manages connections for - several daemons. Programs that provide network service are - commonly known as daemons. <application>inetd</application> - serves as a managing server for other daemons. When a + several services. When a connection is received by <application>inetd</application>, it - determines which daemon the connection is destined for, spawns - the particular daemon and delegates the socket to it. Running + determines which program the connection is destined for, spawns + the particular process and delegates the socket to it (the program + is invoked with the service socket as its standard input, output + and error descriptors). Running one instance of <application>inetd</application> reduces the overall system load as compared to running each daemon individually in stand-alone mode.</para> @@ -4891,7 +4891,7 @@ Starting smbd.</screen> administrator or ISP may have set up an NTP server for this purpose—check their documentation to see if this is the case. There is an <ulink - url="http://www.eecis.udel.edu/~mills/ntp/servers.html">online + url="http://ntp.isc.org/bin/view/Servers/WebHome">online list of publicly accessible NTP servers</ulink> which you can use to find an NTP server near to you. Make sure you are aware of the policy for any servers you choose, and ask for diff --git a/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml b/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml index 40b0a3f121..c77a1c074a 100644 --- a/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml @@ -191,6 +191,11 @@ &pgpkey.brooks; </sect2> + <sect2 id="pgpkey-gnn"> + <title>&a.gnn;</title> + &pgpkey.gnn; + </sect2> + <sect2 id="pgpkey-pjd"> <title>&a.pjd;</title> &pgpkey.pjd; @@ -351,6 +356,11 @@ &pgpkey.jkh; </sect2> + <sect2 id="pgpkey-ahze"> + <title>&a.ahze;</title> + &pgpkey.ahze; + </sect2> + <sect2 id="pgpkey-trevor"> <title>&a.trevor;</title> &pgpkey.trevor; @@ -481,6 +491,11 @@ &pgpkey.arved; </sect2> + <sect2 id="pgpkey-remko"> + <title>&a.remko;</title> + &pgpkey.remko; + </sect2> + <sect2 id="pgpkey-pav"> <title>&a.pav;</title> &pgpkey.pav; @@ -826,6 +841,11 @@ &pgpkey.viny; </sect2> + <sect2 id="pgpkey-ups"> + <title>&a.ups;</title> + &pgpkey.ups; + </sect2> + <sect2 id="pgpkey-nectar"> <title>&a.nectar;</title> &pgpkey.nectar; diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml index 5e5f7631fa..aacefe2df1 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml @@ -31,9 +31,8 @@ to protect your data, intellectual property, time, and much more from the hands of hackers and the like.</para> - <para>FreeBSD provides an array of utilities and mechanisms to - ensure the integrity and security of your system and - network.</para> + <para>&os; provides an array of utilities and mechanisms to ensure + the integrity and security of your system and network.</para> <para>After reading this chapter, you will know:</para> @@ -287,10 +286,10 @@ </sect1> <sect1 id="securing-freebsd"> - <title>Securing FreeBSD</title> + <title>Securing &os;</title> <indexterm> <primary>security</primary> - <secondary>securing FreeBSD</secondary> + <secondary>securing &os;</secondary> </indexterm> <note> @@ -305,7 +304,7 @@ </note> <para>The sections that follow will cover the methods of securing your - FreeBSD system that were mentioned in the <link + &os; system that were mentioned in the <link linkend="security-intro">last section</link> of this chapter.</para> <sect2 id="securing-root-and-staff"> @@ -502,7 +501,7 @@ <application>rlogind</application>, then turn off those services!</para> - <para>FreeBSD now defaults to running + <para>&os; now defaults to running <application>ntalkd</application>, <application>comsat</application>, and <application>finger</application> in a sandbox. Another program @@ -600,7 +599,7 @@ <para>If an attacker breaks <username>root</username> he can do just about anything, but there are certain conveniences. For example, most modern kernels - have a packet sniffing device driver built in. Under FreeBSD it + have a packet sniffing device driver built in. Under &os; it is called the <devicename>bpf</devicename> device. An intruder will commonly attempt to run a packet sniffer on a compromised machine. You do not need to give the intruder the capability and @@ -843,7 +842,7 @@ services, or that you will add a new internal service and forget to update the firewall. You can still open up the high-numbered port range on the firewall, to allow permissive-like operation, - without compromising your low ports. Also take note that FreeBSD + without compromising your low ports. Also take note that &os; allows you to control the range of port numbers used for dynamic binding, via the various <varname>net.inet.ip.portrange</varname> <command>sysctl</command>'s (<command>sysctl -a | fgrep @@ -876,7 +875,7 @@ server to saturate its outgoing network with ICMP responses. This type of attack can also crash the server by running it out of mbuf's, especially if the server cannot drain the ICMP responses - it generates fast enough. The FreeBSD kernel has a new kernel + it generates fast enough. The &os; kernel has a new kernel compile option called <option>ICMP_BANDLIM</option> which limits the effectiveness of these sorts of attacks. The last major class of springboard @@ -1011,14 +1010,14 @@ &unix; came into being was based on DES, the Data Encryption Standard. This was not such a problem for users resident in the US, but since the source code for DES could not be exported - outside the US, FreeBSD had to find a way to both comply with + outside the US, &os; had to find a way to both comply with US law and retain compatibility with all the other &unix; variants that still used DES.</para> <para>The solution was to divide up the encryption libraries so that US users could install the DES libraries and use DES but international users still had an encryption method - that could be exported abroad. This is how FreeBSD came to + that could be exported abroad. This is how &os; came to use MD5 as its default encryption method. MD5 is believed to be more secure than DES, so installing DES is offered primarily for compatibility reasons.</para> @@ -1026,16 +1025,16 @@ <sect2> <title>Recognizing Your Crypt Mechanism</title> - <para>Before FreeBSD 4.4 <filename>libcrypt.a</filename> was a + <para>Before &os; 4.4 <filename>libcrypt.a</filename> was a symbolic link pointing to the library which was used for - encryption. FreeBSD 4.4 changed <filename>libcrypt.a</filename> to + encryption. &os; 4.4 changed <filename>libcrypt.a</filename> to provide a configurable password authentication hash library. Currently the library supports DES, MD5 and Blowfish hash - functions. By default FreeBSD uses MD5 to encrypt + functions. By default &os; uses MD5 to encrypt passwords.</para> <para>It is pretty easy to identify which encryption method - FreeBSD is set up to use. Examining the encrypted passwords in + &os; is set up to use. Examining the encrypted passwords in the <filename>/etc/master.passwd</filename> file is one way. Passwords encrypted with the MD5 hash are longer than those encrypted with the DES hash and also begin with the characters @@ -1067,13 +1066,13 @@ </indexterm> <para>S/Key is a one-time password scheme based on a one-way hash - function. FreeBSD uses the MD4 hash for compatibility but other + function. &os; uses the MD4 hash for compatibility but other systems have used MD5 and DES-MAC. S/Key has been part of the - FreeBSD base system since version 1.1.5 and is also used on a + &os; base system since version 1.1.5 and is also used on a growing number of other operating systems. S/Key is a registered trademark of Bell Communications Research, Inc.</para> - <para>From version 5.0 of FreeBSD, S/Key has been replaced with + <para>From version 5.0 of &os;, S/Key has been replaced with the functionally equivalent OPIE (One-time Passwords In Everything). OPIE uses the MD5 hash by default.</para> @@ -1157,7 +1156,7 @@ <para>To initialize S/Key for the first time, change your password, or change your seed while logged in over a secure connection - (e.g., on the console of a machine or via <application>ssh</application>), use the + (e.g. on the console of a machine or via <application>ssh</application>), use the <command>keyinit</command> command without any parameters while logged in as yourself:</para> @@ -1398,7 +1397,7 @@ Enter secret pass phrase: <userinput><secret password></userinput> aware of before depending on this file for security.</para> <para>If there is no <filename>/etc/skey.access</filename> file - (this is the default on FreeBSD 4.X systems), then all users will + (this is the default on &os; 4.X systems), then all users will be allowed to use &unix; passwords. If the file exists, however, then all users will be required to use S/Key unless explicitly permitted to do otherwise by configuration statements in the @@ -1434,7 +1433,7 @@ permit port ttyd0</programlisting> <para>OPIE can restrict the use of &unix; passwords based on the IP address of a login session just like S/Key does. The relevant file is <filename>/etc/opieaccess</filename>, which is present by default - on FreeBSD 5.0 and newer systems. Please check &man.opieaccess.5; + on &os; 5.0 and newer systems. Please check &man.opieaccess.5; for more information on this file and which security considerations you should be aware of when using it.</para> @@ -1501,6 +1500,12 @@ permit port ttyd0</programlisting> read the <link linkend="network-inetd">inetd configuration</link> section.</para> + <note> + <para>While programs run by &man.inetd.8; are not exactly + <quote>daemons</quote>, they have traditionally been called + daemons. This is the term we will use in this section too.</para> + </note> + <sect2> <title>Initial Configuration</title> @@ -1703,7 +1708,7 @@ sendmail : PARANOID : deny</programlisting> controllable.</para> <para>The following instructions can be used as a guide on how to set up - Kerberos as distributed for FreeBSD. However, you should refer to the + Kerberos as distributed for &os;. However, you should refer to the relevant manual pages for a complete description.</para> <sect2> @@ -1717,7 +1722,7 @@ sendmail : PARANOID : deny</programlisting> <para>Kerberos is an optional component of &os;. The easiest way to install this software is by selecting the <literal>krb4</literal> or <literal>krb5</literal> distribution in <application>sysinstall</application> - during the initial installation of FreeBSD. This will install + during the initial installation of &os;. This will install the <quote>eBones</quote> (KerberosIV) or <quote>Heimdal</quote> (Kerberos5) implementation of Kerberos. These implementations are included because they are developed outside the USA/Canada and @@ -2337,6 +2342,7 @@ kerberos_stash="YES"</programlisting> [realms] EXAMPLE.ORG = { kdc = kerberos.example.org + admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG</programlisting> @@ -2365,6 +2371,15 @@ _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG.</programlisting></note> + <note> + <para>For clients to be able to find the + <application>Kerberos</application> services, you + <emphasis>must</emphasis> have either a fully configured + <filename>/etc/krb5.conf</filename> or a miminally configured + <filename>/etc/krb5.conf</filename> <emphasis>and</emphasis> a + properly configured DNS server.</para> + </note> + <para>Next we will create the <application>Kerberos</application> database. This database contains the keys of all principals encrypted with a master password. You are not @@ -2936,921 +2951,2771 @@ jdoe@example.org</screen> <sect1info> <authorgroup> <author> - <firstname>Gary</firstname> - <surname>Palmer</surname> + <firstname>Joseph J.</firstname> + <surname>Barbish</surname> <contrib>Contributed by </contrib> </author> - <author> - <firstname>Alex</firstname> - <surname>Nash</surname> - </author> + </authorgroup> + <authorgroup> + <author> + <firstname>Brad</firstname> + <surname>Davis</surname> + <contrib>Converted to SGML and updated by </contrib> + </author> </authorgroup> </sect1info> - <title>Firewalls</title> + <indexterm><primary>firewall</primary></indexterm> <indexterm> <primary>security</primary> - <secondary>firewalls</secondary> - </indexterm> + <secondary>firewalls</secondary> + </indexterm> + <sect2> + <title>Introduction</title> + <para>All software-based firewalls provide some way to filter + incoming and outgoing traffic that flows through your system. + The firewall uses one or more sets of <quote>rules</quote> to + inspect the network packets as they come in or go out of your + network connections and either allows the traffic through or + blocks it. The rules of the firewall can inspect one or more + characteristics of the packets, including but not limited to + the protocol type, the source or destination host address and + the source or destination port.</para> + + <para>Firewalls greatly enhance the security of your network, + your applications and services. They can be used to do one of + more of the following things:</para> - <para>Firewalls are an area of increasing interest for people who are - connected to the Internet, and are even finding applications on private - networks to provide enhanced security. This section will hopefully - explain what firewalls are, how to use them, and how to use the - facilities provided in the FreeBSD kernel to implement them.</para> + <itemizedlist> + <listitem> + <para>To protect and insulate the applications, services and + machines of your internal network from unwanted traffic + coming in from the public Internet.</para> + </listitem> - <note> - <para>People often think that having a firewall between your - internal network and the <quote>Big Bad Internet</quote> will solve all - your security problems. It may help, but a poorly set up firewall - system is more of a security risk than not having one at all. A - firewall can add another layer of security to your systems, but it - cannot stop a really determined cracker from penetrating your internal - network. If you let internal security lapse because you believe your - firewall to be impenetrable, you have just made the crackers job that - much easier.</para> - </note> + <listitem> + <para>To limit or disable access from hosts of the internal + network to services of the public Internet.</para> + </listitem> + + <listitem> + <para>To support network address translation (<acronym>NAT</acronym>), which + allows your internal network to use private <acronym>IP</acronym> addresses + and share a single connection to the public Internet + (either with a single <acronym>IP</acronym> address or by a shared pool of + automatically assigned public addresses).</para> + </listitem> + </itemizedlist> + </sect2> <sect2> - <title>What Is a Firewall?</title> - - <para>There are currently two distinct types of firewalls in common use - on the Internet today. The first type is more properly called a - <emphasis>packet filtering router</emphasis>. This type of - firewall utilizes a multi-homed machine and a set of rules to - determine whether to forward or block individual packets. A - multi-homed machine is simply a device with multiple network - interfaces. - The second type, known as a <emphasis>proxy - server</emphasis>, relies on daemons to provide authentication and to - forward packets, possibly on a multi-homed machine which has kernel - packet forwarding disabled.</para> - - <para>Sometimes sites combine the two types of firewalls, so that only a - certain machine (known as a <emphasis>bastion host</emphasis>) is - allowed to send packets through a packet filtering router onto an - internal network. Proxy services are run on the bastion host, which - are generally more secure than normal authentication - mechanisms.</para> - - <para>FreeBSD comes with a kernel packet filter (known as - IPFW), which is what the rest of this - section will concentrate on. Proxy servers can be built on FreeBSD - from third party software, but there is such a variety of proxy - servers available that it would be impossible to cover them in this - section.</para> - - <sect3 id="firewalls-packet-filters"> - <title>Packet Filtering Routers</title> - - <para>A router is a machine which forwards packets between two or more - networks. A packet filtering router is programmed to - compare each packet to a list of rules before - deciding if it should be forwarded or not. Most modern IP routing - software includes packet filtering functionality that defaults to - forwarding all packets. To enable the filters, you need to define a - set of rules.</para> - - <para>To decide whether a packet should be passed on, the firewall looks - through its set of rules for a rule which matches the contents of - the packet's headers. Once a match is found, the rule action is - obeyed. The rule action could be to drop the packet, to forward the - packet, or even to send an ICMP message back to the originator. - Only the first match counts, as the rules are searched in order. - Hence, the list of rules can be referred to as a <quote>rule - chain</quote>.</para> - - <para>The packet-matching criteria varies depending on the software - used, but typically you can specify rules which depend on the source - IP address of the packet, the destination IP address, the source - port number, the destination port number (for protocols which - support ports), or even the packet type (UDP, TCP, ICMP, - etc).</para> + <title>Firewall Rule Set Types</title> + <para>Constructing a software application firewall rule set may + seem to be trivial, but most people get it wrong. The most + common mistake is to create an <quote>exclusive</quote> firewall rather + than an <quote>inclusive</quote> firewall.</para> + + <para>An exclusive firewall allows all services through except + for those matching a set of rules that block certain + services.</para> + + <para>An inclusive firewall does the reverse. It only allows + services matching the rules through and blocks everything else. + This way you can control what services can originate behind the + firewall destined for the public Internet and also control which + services originating from the public Internet may access your + network. Inclusive firewalls are much, much safer than exclusive + firewalls.</para> + + <para>When you use your browser to access a web site there are + many internal functions that happen before your screen fills + with the data from the target web site. Your browser does not + receive one large file containing all the data and display + format instructions at one time. Each internal function accesses + the public Internet in multiple send/receive cycles of packets + of information. When all the packets containing the data finally + arrive, the data contained in the packets is combined together + to fill your screen. Each service (<acronym>DNS</acronym>, <acronym>HTTP</acronym>, etc) has its own + port number. The port number 80 is for <acronym>HTTP</acronym> services. So you + can code your firewall to only allow web page session start + requests originating from your <acronym>LAN</acronym> to pass through the firewall + out to the public Internet.</para> + + <para>Security can be tightened further by telling the firewall to + monitor the send/receive cycles of all the packets making up + that session until the session completes. These are called + stateful capabilities and provides the maximum level of + protection.</para> + + <para>A firewall rule set that does not implement stateful + capabilities on all the services being authorized is an insecure + firewall that is still open to many of the most common methods + of attack.</para> + </sect2> + + <sect2> + <title>Firewall Software Applications</title> + <para>&os; has two different firewall software products built + into the base system. They are IPFILTER (i.e. also known as IPF) + and IPFIREWALL (i.e. also known as IPFW). IPFIREWALL has the + built in DUMMYNET traffic shaper facilities for controlling + bandwidth usage. IPFILTER does not have a built in traffic + shaper facility for controlling bandwidth usage, but the ALTQ + port application can be used to accomplish the same function. + The DUMMYNET feature and <acronym>ALTQ</acronym> is generally useful only to large + ISPs or commercial users. Both IPF and IPFW use rules to control + the access of packets to and from your system, although they go + about it different ways and have different rule syntaxes.</para> + + <para>The IPFW sample rule set (found in + <filename>/etc/rc.firewall</filename>) delivered in the basic + install is outdated, complicated and does not use stateful + rules on the interface facing the public Internet. It + exclusively uses legacy stateless rules which only have the + ability to open or close the service ports. The IPFW example + stateful rules sets presented here supercede the + <filename>/etc/firewall.rc</filename> file distributed with the + system.</para> + + <para>Stateful rules have technically advanced interrogation + abilities capable of defending against the flood of different + methods currently employed by attackers.</para> + + <para>Both of these firewall software solutions IPF and IPFW still + maintain their legacy heritage of their original rule processing + order and reliance on non-stateful rules. These outdated + concepts are not covered here, only the new, modern stateful + rule construct and rule processing order is presented.</para> + + <para>You should read about both of them and make your own + decision on which one best fits your needs.</para> + + <para>The author prefers IPFILTER because its stateful rules are + much less complicated to use in a <acronym>NAT</acronym> environment and it has a + built in ftp proxy that simplifies the rules to allow secure + outbound FTP usage. If is also more appropriate to the knowledge + level of the inexperienced firewall user.</para> + + <para>Since all firewalls are based on interrogating the values + of selected packet control fields, the creator of the firewall + rules must have an understanding of how <acronym>TCP</acronym>/IP works, what the + different values in the packet control fields are and how these + values are used in a normal session conversation. For a good + explanation go to: + <ulink url="http://www.ipprimer.com/overview.cfm"></ulink>.</para> + </sect2> + + <sect2> + <title>The Packet Filter Firewall</title> + + <para>As of July 2003 the OpenBSD firewall software application + known as <acronym>PF</acronym> was ported to &os; 5.3. + <acronym>PF</acronym> is a complete, fully featured firewall + that contains <acronym>ALTQ</acronym> + for bandwidth usage management in a way similar to the dummynet + provides in <acronym>IPFW</acronym>. + The OpenBSD project does an outstanding job of maintaining the + PF users' guide that it will not be made part of this handbook + firewall section as that would just be duplicated effort.</para> + + <para>For older 5.X version of &os; you can find + <acronym>PF</acronym> in the &os; ports collection here: + <filename role="package">security/pf</filename>.</para> + + <para>More info can be found at the PF for &os; web site: + <ulink url="http://pf4freebsd.love2party.net/index.html"> + </ulink>.</para> + + <para>The OpenBSD PF user's guide is here: + <ulink url="http://www.openbsd.org/faq/pf/index.html"></ulink>. + </para> + + <warning> + <para>PF in &os; 5.X is at the level of OpenBSD version 3.5. The + port from the &os; ports collection at the level of OpenBSD + version 3.4. Keep that in mind when browsing the user's + guide.</para> + </warning> + + <sect3> + <title>Enabling PF</title> + <para>PF is included in the basic &os; install for versions newer than + 5.3 as a separate run time loadable module. PF will dynamically load + its kernel loadable module when the rc.conf statement + <literal>pf_enable="YES"</literal> is used. The + loadable module was created with &man.pflog.4; logging + enabled.</para> + </sect3> + + <sect3> + <title>Kernel options</title> + <para>It is not a mandatory requirement that you enable PF by + compiling the following options into the &os; kernel. It is only + presented here as background information. Compiling PF into the + kernel causes the loadable module to never be used.</para> + + <para>Sample kernel config PF option statements are in the + <filename>/usr/src/sys/conf/NOTES</filename> kernel source and are + reproduced here:</para> + + <programlisting>device pf +device pflog +device pfsync</programlisting> + + <para><literal>device pf</literal> tells the compile to include + Packet Filter as part of its core kernel.</para> + + <para><literal>device pflog</literal> enables the optional + &man.pflog.4; pseudo network device which can be used to log traffic + to a &man.bpf.4; descriptor. The &man.pflogd.8; daemon can be used to + store the logging information to disk.</para> + + <para><literal>device pfsync</literal> enables the optional + &man.pfsync.4; pseudo network device that is used to monitor + <quote>state changes</quote>. As this is not part of the loadable + module one has to build a custom kernel to use it.</para> + + <para>These settings will take affect only after you have built and + installed a kernel with them set.</para> + </sect3> + + <sect3> + <title>Available rc.conf Options</title> + + <para>You need the following statements in <filename>/etc/rc.conf + </filename> to activate PF at boot time:</para> + + <programlisting>pf_enable="YES" # Enable PF (load module if required) +pf_rules="/etc/pf.conf" # rules definition file for pf +pf_flags="" # additional flags for pfctl startup +pflog_enable="YES" # start pflogd(8) +pflog_logfile="/var/log/pflog" # where pflogd should store the logfile +pflog_flags="" # additional flags for pflogd startup</programlisting> + + <para>If you have a LAN behind this firewall and have to forward + packets for the computers in the LAN or want to do NAT you have to + enable the following option as well:</para> + + <programlisting>gateway_enable="YES" # Enable as Lan gateway</programlisting> + + </sect3> + </sect2> + + <sect2> + <title>The IPFILTER (IPF) Firewall</title> + <para>The author of IPFILTER is Darren Reed. IPFILTER is not + operating system dependent. IPFILTER is a open source + application and has been ported to &os;, NetBSD, OpenBSD, + SunOS, HP/UX, and Solaris operating systems. IPFILTER is + actively being supported and maintained, with updated versions + being released regularly.</para> + + <para>IPFILTER is based on a kernel-side firewall and <acronym>NAT</acronym> + mechanism that can be controlled and monitored by userland + interface programs. The firewall rules can be set or deleted + with the &man.ipf.8; utility. The <acronym>NAT</acronym> rules can be set or + deleted with the &man.ipnat.1; utility. The &man.ipfstat.8; + utility can print run-time statistics for the kernel parts of + IPFILTER. The &man.ipmon.8; program can log IPFILTER actions + to the system log files.</para> + + <para>IPF was originally written using a rule processing logic + of <quote>the last matching rule wins</quote> and used only + stateless type of rules. Over time IPF has been enhanced to + include a <quote>quick</quote> option and a stateful + <quote>keep state</quote> option which drastically modernized + the rules processing logic. IPF's official documentation covers + the legacy rule coding parameters and the legacy rule file + processing logic. the modernized functions are only included as + additional options, completely understating their benefits in + producing a far superior secure firewall.</para> + + <para>The instructions contained in this section are based on + using rules that contain the <quote>quick</quote> option and + the stateful <quote>keep state</quote> option. This is the + basic framework for coding an inclusive firewall rule set. + </para> + + <para>An inclusive firewall only allows packets matching the + rules to pass through. This way you can control what services + can originate behind the firewall destine for the public + Internet and also control the services which can originate from + the public Internet accessing your private network. Everything + else is blocked and logged by default design. Inclusive + firewalls are much, much more secure than exclusive firewall + rule sets and is the only rule set type covered here in.</para> + + <para>For detailed explanation of the legacy rules processing + method see: + <ulink url="http://www.obfuscation.org/ipf/ipf-howto.html#TOC_1"></ulink> + and + <ulink url="http://coombs.anu.edu.au/~avalon/ip-filter.html"></ulink> + .</para> + + <para>The IPF FAQ is at + <ulink url="http://www.phildev.net/ipf/index.html"></ulink>. + </para> + + <sect3> + <title>Enabling IPF</title> + <para>IPF is included in the basic &os; install as a separate + run time loadable module. IPF will dynamically load its kernel + loadable module when the rc.conf statement <literal> + ipfilter_enable="YES"</literal> is used. The loadable + module was created with logging enabled and the <literal>default + pass all</literal> options. You do not need to compile IPF into + the &os; kernel just to change the default to <literal>block all + </literal>, you can do that by just coding a block all rule at + the end of your rule set.</para> + </sect3> + + <sect3> + <title>Kernel options</title> + <para>It is not a mandatory requirement that you enable IPF by + compiling the following options into the &os; kernel. It is + only presented here as background information. Compiling IPF + into the kernel causes the loadable module to never be used. + </para> + + <para>Sample kernel config IPF option statements are in the + <filename>/usr/src/sys/i386/conf/LINT</filename> kernel source + and are reproduced here.</para> + + <programlisting>options IPFILTER +options IPFILTER_LOG +options IPFILTER_DEFAULT_BLOCK</programlisting> + + <para><literal>options IPFILTER</literal> tells the compile + to include IPFILTER as part of its core kernel.</para> + + <para><literal>options IPFILTER_LOG</literal> enables the + option to have IPF log traffic by writing to the ipl packet + logging pseudo—device for every rule that has the <literal>log + </literal> keyword.</para> + + <para><literal>options IPFILTER_DEFAULT_BLOCK</literal> + changes the default behavior so any packet not matching a + firewall <literal>pass</literal> rule gets blocked.</para> + + <para>These settings will take affect only after you have built + and installed a kernel with them set.</para> + </sect3> + + <sect3> + <title>Available rc.conf Options</title> + <para>You need the following statements in <filename>/etc/rc.conf + </filename> to activate IPF at boot time:</para> + + <programlisting>ipfilter_enable="YES" # Start ipf firewall +ipfilter_rules="/etc/ipf.rules" # loads rules definition text file +ipmon_enable="YES" # Start IP monitor log +ipmon_flags="-Ds" # D = start as daemon + # s = log to syslog + # v = log tcp window, ack, seq + # n = map IP & port to names</programlisting> + <para>If you have a LAN behind this firewall that uses the + reserved private IP address ranges, then you need to add the + following to enable <acronym>NAT</acronym> function.</para> + + <programlisting>gateway_enable="YES" # Enable as Lan gateway +ipnat_enable="YES" # Start ipnat function +ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat</programlisting> + + </sect3> + + <sect3> + <title>IPF</title> + <para>The ipf command is used to load your rules file. Normally + you create a file containing your custom rules and use this + command to replace in mass the currently running firewall + internal rules.</para> + + <programlisting><command>ipf -Fa -f /etc/ipf.rules</command></programlisting> + + <para>-Fa means flush all internal rules tables.</para> + <para>-f means this is the file to read for the rules to load.</para> + + <para>This gives you the ability to make changes to their custom + rules file, run the above IPF command thus updating the running + firewall with a fresh copy of all the rules without having to + reboot the system. This method is very convenient for testing new + rules as the procedure can be executed as many times as needed. + </para> + + <para>See the &man.ipf.8; man page for details on the other flags + available with this command.</para> + + <para>The &man.ipf.8; command expects the rules file to be a + standard text file. It will not accept a rules file written as a + script with symbolic substitution.</para> + + <para>There is a way to build IPF rules that utilities the power of + script symbolic substitution. See the Building Rule Script + section.</para> + + </sect3> + + <sect3> + <title>IPFSTAT</title> + <para>The default behavior of &man.ipfstat.8; is to retrieve and + display the totals of the accumulated statistics gathered as a + result of applying the user coded rules against packets going + in and out of the firewall since it was last started, or since + the last time the accumulators were reset to zero by + <command>ipf -Z</command> command.</para> + + <para>See the &man.ipfstat.8; manual page for details.</para> + + <para>The default &man.ipfstat.8; command output will look + something like this:</para> + + <screen>input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 + output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 + input packets logged: blocked 99286 passed 0 + output packets logged: blocked 0 passed 0 + packets logged: input 0 output 0 + log failures: input 3898 output 0 + fragment state(in): kept 0 lost 0 + fragment state(out): kept 0 lost 0 + packet state(in): kept 169364 lost 0 + packet state(out): kept 431395 lost 0 + ICMP replies: 0 <acronym>TCP</acronym> RSTs sent: 0 + Result cache hits(in): 1215208 (out): 1098963 + IN Pullups succeeded: 2 failed: 0 + OUT Pullups succeeded: 0 failed: 0 + Fastroute successes: 0 failures: 0 + <acronym>TCP</acronym> cksum fails(in): 0 (out): 0 + Packet log flags set: (0)</screen> + + <para>When supplied with either -i for inbound or -o for outbound, + it will retrieve and display the appropriate list of filter + rules currently installed and in use by the kernel.</para> + + <para><command>ipfstat -in</command> displays the inbound internal + rules table with rule number.</para> + + <para><command>ipfstat -on</command> displays the outbound + internal rules table with the rule number.<para> + + <para>The output will look something like this:</para> + + <screen>@1 pass out on xl0 from any to any +@2 block out on dc0 from any to any +@3 pass out quick on dc0 proto tcp/udp from any to any keep state</screen> + + <para><command>ipfstat -ih</command> displays the inbound internal + rules table prefixed each rule with count of how many times the + rule was matched.</para> + + <para><command>ipfstat -oh</command> displays the outbound + internal rules table prefixed each rule with count of how many + times the rule was matched.</para> + + <para>The output will look something like this:</para> + + <screen>2451423 pass out on xl0 from any to any +354727 block out on dc0 from any to any +430918 pass out quick on dc0 proto tcp/udp from any to any keep state</screen> + + <para>One of the most important functions of the ipfstat command + is the -T flag which activates the display state table in a way + similar to the way &man.top.1; shows the &os; running process + table. When your firewall is under attack this function gives + you the ability to identify, drill down to, and see the + attacking packets. The optional sub-flags give the ability to + select destination or source IP, port, protocol, you want to + monitor in real time. See the &man.ipfstat.8 man page for + details.<para> + + </sect3> + <sect3> + + <title>IPMON</title> + <para>In order for <command>ipmon</command> to properly work, the + kernel option IPFILTER_LOG must be turned on. This command has + 2 different modes it can be used in. Native mode is the default + mode when you type the command on the command line without the + -D flag.</para> + + <para>Daemon mode is for when you want to have a continuous + system log file available so you can review logging of past + events. This is how &os; and IPFILTER are configured to work + together. &os; has a built in facility to automatically + rotate syslogs. That is why outputting the log information to + syslogd is better than the default of outputting to a regular + file. In <filename>rc.conf</filename> file you see the + ipmon_flags statement uses the "-Ds" flags</para> + + <programlisting>ipmon_flags="-Ds" # D = start as daemon + # s = log to syslog + # v = log tcp window, ack, seq + # n = map IP & port to names</programlisting> + + <para>The benefits of logging are obvious. It provides the + ability to review, after the fact, information like: what + packets had been dropped, what addresses they came from and + where they were going. These all give you a significant edge in + tracking down attackers.</para> + + <para>Even with the logging facility enabled, IPF will not + generate any rule logging on its own. The firewall + administrator decides what rules in the rule set he wants to + log and adds the log keyword to those rules. Normally only + deny rules are logged.</para> + + <para>Its very customary to include a default deny everything + rule with the log keyword included as your last rule in the + rule set. This way you get to see all the packets that did not + match any of the rules in the rule set.</para> + </sect3> + + <sect3> + <title>IPMON Logging</title> + + <para>Syslogd uses its own special method for segregation of log + data. It uses special grouping called <quote>facility</quote> + and <quote>level.</quote> IPMON in -Ds mode uses Local0 as the + <quote>facility</quote> name. All IPMON logged data goes to + Local0. The following levels can be used to further segregate + the logged data if desired.</para> + + <screen>LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. +LOG_NOTICE - packets logged which are also passed +LOG_WARNING - packets logged which are also blocked +LOG_ERR - packets which have been logged and which can be considered short</screen> + + <para>To setup IPFILTER to log all data to <filename> + /var/log/ipfilter.log</filename>, you will need to create the + file. The following command will do that:</para> + + <programlisting><command>touch /var/log/ipfilter.log</command></programlisting> + + <para>The syslog function is controlled by definition statements + in the <filename>/etc/syslog.conf</filename> file. The <filename>syslog.conf</filename> file offers + considerable flexibility in how syslog will deal with system + messages issued by software applications like IPF.</para> + + <para>Add the following statement to <filename>/etc/syslog.conf + </filename>:</para> + + <programlisting>Local0.* /var/log/ipfilter.log</programlisting> + + <para>The <literal>Local0.*</literal> means to write all the logged messages to the + coded file location.</para> + + <para>To activate the changes to <filename>/etc/syslog.conf + </filename> you can reboot or bump the syslog task into + re-reading <filename>/etc/syslog.conf</filename> by <command> + kill -HUP <pid></command>. You get the pid (i.e. process + number) by listing the tasks with the <command>ps -ax</command> + command. Find syslog in the display and the pid is the number + in the left column.</para> + + <para>Do not forget to change <filename>/etc/newsyslog.conf + </filename> to rotate the new log you just created above. + </para> + + </sect3> + + <sect3> + <title>The Format of Logged Messages</title> + + <para>Messages generated by ipmon consist of data fields + separated by white space. Fields common to all messages are: + </para> + + <orderedlist> + <listitem> + <para>The date of packet receipt.</para> + </listitem> + + <listitem> + <para>The time of packet receipt. This is in the form + HH:MM:SS.F, for hours, minutes, seconds, and fractions of a + second (which can be several digits long).</para> + </listitem> + + <listitem> + <para>The name of the interface the packet was processed on, + e.g. <devicename>dc0</devicename>.</para> + </listitem> + + <listitem> + <para>The group and rule number of the rule, e.g. <literal>@0:17</literal>. + </para> + </listitem> + </orderedlist> + + <para>These can be viewed with ipfstat -in.<para> + + <orderedlist> + <listitem> + <para>The action: p for passed, b for blocked, S for a short + packet, n did not match any rules, L for a log rule. The + order of precedence in showing flags is: S, p, b, n, L. A + capital P or B means that the packet has been logged due to + a global logging setting, not a particular rule.</para> + </listitem> + + <listitem> + <para>The addresses. This is actually three fields: the + source address and port (separated by a comma), the -> + symbol, and the destination address and port. + 209.53.17.22,80 -> 198.73.220.17,1722.</para> + </listitem> + + <listitem> + <para>PR followed by the protocol name or number, e.g. PR + tcp.</para> + </listitem> + + <listitem> + <para>len followed by the header length and total length of + the packet, e.g. len 20 40.</para> + </listitem> + </orderedlist> + + <para>If the packet is a <acronym>TCP</acronym> packet, there will be an additional + field starting with a hyphen followed by letters corresponding + to any flags that were set. See the &man.ipmon.8; manual page + for a list of letters and their flags.</para> + + <para>If the packet is an ICMP packet, there will be two fields + at the end, the first always being <quote>ICMP</quote>, and + the next being the ICMP message and sub-message type, + separated by a slash, e.g. ICMP 3/3 for a port unreachable + message.</para> + + </sect3> + + <sect3> + <title>Building the Rule Script</title> + + <para>Some experienced IPF users create a file containing the + rules and code them in a manner compatible with running them + as a script with symbolic substitution. The major benefit of + doing this is you only have to change the value associated + with the symbolic name and when the script is run all the rules + containing the symbolic name will have the value substituted in + the rules. Being a script, you can use symbolic substitution to + code frequent used values and substitute them in multiple + rules. You will see this in the following example.</para> + + <para>The script syntax used here is compatible with the sh, csh, + and tcsh shells.</para> + + <para>Symbolic substitution fields are prefixed with a dollar + sign $.</para> + + <para>Symbolic fields do not have the $ prefix</para> + + <para>The value to populate the Symbolic field must be enclosed + with "double quotes".</para> + + <para>Start your rule file with something like this:</para> + + +<programlisting>############# Start of IPF rules script ######################## + +oif="dc0" # name of the outbound interface +odns="192.0.2.11" # ISP's dns server IP address Symbolic> +myip="192.0.2.7" # My Static IP address from ISP +ks="keep state" +fks="flags S keep state" + +# You can use this same to build the /etc/ipf.rules file +#cat >> /etc/ipf.rules << EOF + +# exec ipf command and read inline data, stop reading +# when word EOF is found. There has to be one line +# after the EOF line to work correctly. +/sbin/ipf -Fa -f - << EOF + +# Allow out access to my ISP's Domain name server. +pass out quick on $oif proto tcp from any to $odns port = 53 $fks +pass out quick on $oif proto udp from any to $odns port = 53 $ks + +# Allow out non-secure standard www function +pass out quick on $oif proto tcp from $myip to any port = 80 $fks + +# Allow out secure www function https over TLS SSL +pass out quick on $oif proto tcp from $myip to any port = 443 $fks +EOF +################## End of IPF rules script ########################</programlisting> + + <para>That is all there is to it. The rules are not important in + this example, how the Symbolic substitution field are populated + and used are. If the above example was in /etc/ipf.rules.script + file, you could reload these rules by entering on the command + line.</para> + + <programlisting><command>sh /etc/ipf.rules.script</command> + </programlisting> + + <para>There is one problem with using a rules file with embedded + symbolics. IPF has no problem with it, but the rc startup + scripts that read <filename>rc.conf</filename> will have + problems.</para> + + <para>To get around this limitation with a rc scripts, remove + the following line:</para> + + <programlisting><command>ipfilter_rules=</command> + </programlisting> + + <para>Add a script like the following to your <filename> + /usr/local/etc/rc.d/</filename> startup directory. The script + should have a obvious name like <filename>loadipfrules.sh + </filename>. The <filename>.sh</filename> extension is mandatory. + + <programlisting>#!/bin/sh +sh /etc/ipf.rules.script</programlisting> + + <para>The permission on this script file must be read, write, + exec for owner root.</para> + + <programlisting><command>chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh</command></programlisting> + + <para>Now when you system boots your IPF rules will be loaded + using the script.</para> + + </sect3> + + <sect3> + <title>IPF Rule Sets</title> + <para>A rule set is a group of ipf rules coded to pass or block + packets based on the values contained in the packet. The + bi-directional exchange of packets between hosts comprises a + session conversation. The firewall rule set processes the + packet 2 times, once on its arrival from the public Internet + host and again as it leaves for its return trip back to the + public Internet host. Each tcp/ip service (i.e. telnet, www, + mail, etc.) is predefined by its protocol, source and + destination IP address, or the source and destination port + number. This is the basic selection criteria used to create + rules which will pass or block services.</para> + + <para>IPF was originally written using a rules processing logic + of 'the last matching rule wins' and used only stateless + rules. Over time IPF has been enhanced to include a 'quick' + option and a stateful 'keep state' option which drastically + modernized the rules processing logic.</para> + + <para>The instructions contained in this section is based on + using rules that contain the 'quick' option. and the stateful + 'keep state' option. This is the basic framework for coding an + inclusive firewall rule set.</para> + + <para>An inclusive firewall only allows services matching the + rules through. This way you can control what services can + originate behind the firewall destined for the public Internet + and also control the services which can originate from the + public Internet accessing your private network. Everything + else is blocked and logged by default design. Inclusive + firewalls are much, much securer than exclusive firewall rule + sets and is the only rule set type covered herein.</para> + + <note> + <para>Warning, when working with the firewall rules, always, + always do it from the root console of the system running the + firewall or you can end up locking your self out.</para> + </note> + </sect3> + + <sect3> + <title>Rule Syntax</title> + <para>The rule syntax presented here has been simplified to only + address the modern stateful rule context and 'first matching + rule wins' logic. For the complete legacy rule syntax + description see the online ipf man page at &man.ipf.8</para> + + <para># is used to mark the start of a comment and may appear at + the end of a rule line or on its own lines. Blank lines are + ignored.</para> + + <para>Rules contain keywords, These keywords have to be coded in + a specific order from left to right on the line. Keywords are + identified in bold type. Some keywords have sub-options which + may be keywords them selves and also include more sub-options. + Each of the headings in the below syntax has a bold section + header which expands on the content.</para> + + <!-- This section is probably wrong.. See the OpenBSD flag --> + + <para><replaceable>ACTION IN-OUT OPTIONS SELECTION STATEFUL + PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG STATEFUL + </replaceable></para> + + <para><replaceable>ACTION</replaceable> = block | pass</para> + + <para><replaceable>IN-OUT</replaceable> = in | out</para> + + <para><replaceable>OPTIONS</replaceable> = log | quick | on + interface-name</para> + + <para><replaceable>SELECTION</replaceable> = proto value | + source/destination IP | port = number | flags flag-value</para> + + <para><replaceable>PROTO</replaceable> = tcp/udp | udp | tcp | + icmp</para> + + <para><replaceable>SRC_ADD,DST_ADDR</replaceable> = all | from + object to object</para> + + <para><replaceable>OBJECT</replaceable> = IP address | any</para> + + <para><replaceable>PORT_NUM</replaceable> = port number</para> + + <para><replaceable>TCP_FLAG</replaceable> = S</para> + + <para><replaceable>STATEFUL</replaceable> = keep state</para> + + <sect4> + <title>ACTION</title> + + <para>The action indicates what to do with the packet if it + matches the rest of the filter rule. Each rule <emphasis>must</emphasis> have a + action. The following actions are recognized:</para> + + <para>block indicates that the packet should be dropped if + the selection parameters match the packet.</para> + + <para>pass indicates that the packet should exit the firewall + if the selection parameters match the packet.</para> + </sect4> + + <sect4> + <title>IN-OUT</title> + <para>This is a mandatory requirement that each filter rule + explicitly state which side of the I/O it is to be used on. + The next keyword must be either in or out and one or the + other has to be coded or the rule will not pass syntax + check.</para> + + <para>in means this rule is being applied against an inbound + packet which has just been received on the interface + facing the public Internet.</para> + + <para>out means this rule is being applied against an + outbound packet destined for the interface facing the public + Internet.</para> + </sect4> + + <sect4> + <title>OPTIONS</title> + <note> + <para>These options must be used in the order shown here. + </para> + </note> + + <para>log indicates that the packet header will be written to + the ipl log (as described in the LOGGING section below) if + the selection parameters match the packet.</para> + + <para>quick indicates that if the selection parameters match + the packet, this rule will be the last rule checked, + allowing a "short-circuit" path to avoid processing any + following rules for this packet. This option is a mandatory + requirement for the modernized rules processing logic. + </para> + + <para>on indicates the interface name to be incorporated into + the selection parameters. Interface names are as displayed + by ifconfig. Using this option, the rule will only match if + the packet is going through that interface in the specified + direction (in/out). This option is a mandatory requirement + for the modernized rules processing logic.</para> + + <para>When a packet is logged, the headers of the packet are + written to the IPL packet logging pseudo-device. + Immediately following the log keyword, the following + qualifiers may be used (in this order):</para> + + <para>body indicates that the first 128 bytes of the packet + contents will be logged after the headers.</para> + + <para>first If the 'log' keyword is being used in conjunction + with a "keep state" option, it is recommended that this + option is also applied so that only the triggering packet + is logged and not every packet which there after matches + the 'keep state' information.</para> + </sect4> + + <sect4> + <title>SELECTION</title> + <para>The keywords described in this section are used to + describe attributes of the packet to be interrogated when + determining whether rules match or don't match. There is a + keyword subject, and it has sub-option keywords, one of + which has to be selected. The following general-purpose + attributes are provided for matching, and must be used in + this order:</para> + </sect4> + + <sect4> + <title>PROTO</title> + <para>Proto is the subject keyword, it must be coded along + with one of it.s corresponding keyword sub-option values. + The value allows a specific protocol to be matched against. + This option is a mandatory requirement for the modernized + rules processing logic.</para> + + <para>tcp/udp | udp | tcp | icmp or any protocol names found + in /etc/protocols are recognized and may be used. The + special protocol keyword tcp/udp may be used to match + either a <acronym>TCP</acronym> or a UDP packet, and has been added as a + convenience to save duplication of otherwise identical + rules.</para> + </sect4> + + <sect4> + <title>SRC_ADDR/DST_ADDR</title> + <para>The 'all' keyword is essentially a synonym for "from + any to any" with no other match parameters.</para> + + <para>from src to dst The from and to keywords are used to + match against IP addresses. Rules must specify BOTH source + and destination parameters. .any. is a special keyword that + matches any IP address. As in 'from any to any' or 'from + 0.0.0.0/0 to any' or 'from any to 0.0.0.0/0' or 'from + 0.0.0.0 to any' or 'from any to 0.0.0.0'</para> + + <para>IP addresses may be specified as a dotted IP address + numeric form/mask-length, or as single dotted IP address + numeric form.</para> + + <para>There isn't a way to match ranges of IP addresses which + do not express themselves easily as mask-length. See this + link for help on writing mask-length: + <ulink url="http://jodies.de/ipcalc"></ulink></para> + </sect4> + + <sect4> + <title>PORT</title> + <para>If a port match is included, for either or both of + source and destination, then it is only applied to <acronym>TCP</acronym> and + UDP packets. When composing port comparisons, either the + service name from /etc/services or an integer port number + may be used. When the port appears as part of the from + object, it matches the source port number, when it appears + as part of the to object, it matches the destination port + number. The use of the port option with the .to. object is + a mandatory requirement for the modernized rules processing + logic. As in 'from any to any port = 80'</para> + + <para>Port comparisons may be done in a number of forms, with + a number of comparison operators, or port ranges may be + specified.</para> + + <para>port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" + | "lt" | "gt" | "le" | "ge".</para> + + <para>To specify port ranges, port "<>" | "><"</para> + + <warning> + <para>Following the source and destination matching + parameters, the following two parameters are mandatory + requirements for the modernized rules processing logic. + </para> + </warning> + </sect4> + + <sect4> + <title><acronym>TCP</acronym>_FLAG</title> + <para>Flags are only effective for <acronym>TCP</acronym> filtering. The letters + represents one of the possible flags that can be + interrogated in the <acronym>TCP</acronym> packet header.</para> + + <para>The modernized rules processing logic uses the 'flags + S' parameter to identify the tcp session start request. + </para> + </sect4> + + <sect4> + <title>STATEFUL</title> + <para>'keep state' indicates that on a pass rule, any packets + that match the rules selection parameters is to activate + the stateful filtering facility.</para> + + <note> + <para>This option is a mandatory requirement for the + modernized rules processing logic.</para> + </note> + </sect4> + </sect3> + + <sect3> + <title>Stateful Filtering</title> + <para>Stateful filtering treats traffic as a bi-directional + exchange of packets comprising a session conversation. When + activated keep-state dynamically generates internal rules for + each anticipated packet being exchanged during the + bi-directional session conversation. It has the interrogation + abilities to determine if the session conversation between the + originating sender and the destination are following the valid + procedure of bi-directional packet exchange. Any packets that + do not properly fit the session conversation template are + automatically rejected as impostors.</para> + + <para>Keep state will also allow ICMP packets related to a <acronym>TCP</acronym> + or UDP session through. So if you get ICMP type 3 code 4 in + response to some web surfing allowed out by a keep state rule, + they will be automatically allowed in. Any packet that IPF can + be certain is part of a active session, even if it is a + different protocol, will be let in.</para> + + <para>What happens is:</para> + + <para>Packets destined to go out the interface connected to the + public Internet are first checked against the dynamic state + table, if the packet matches the next expected packet + comprising in a active session conversation, then it exits + the firewall and the state of the session conversation flow + is updated in the dynamic state table, the remaining packets + get checked against the outbound rule set.</para> + + <para>Packets coming in to the interface connected to the public + Internet are first checked against the dynamic state table, if + the packet matches the next expected packet comprising a + active session conversation, then it exits the firewall and + the state of the session conversation flow is updated in the + dynamic state table, the remaining packets get checked against + the inbound rule set.</para> + + <para>When the conversation completes it is removed from the + dynamic state table.</para> + + <para>Stateful filtering allows you to focus on blocking/passing + new sessions. If the new session is passed, all its subsequent + packets will be allowed through automatically and any + impostors automatically rejected. If a new session is blocked, + none of its subsequent packets will be allowed through. + Stateful filtering has technically advanced interrogation + abilities capable of defending against the flood of different + attack methods currently employed by attackers.</para> </sect3> - - <sect3 id="firewalls-proxy-servers"> - <title>Proxy Servers</title> - - <para>Proxy servers are machines which have had the normal system - daemons (<application>telnetd</application>, - <application>ftpd</application>, etc) replaced with special servers. - These - servers are called <emphasis>proxy servers</emphasis>, as they - normally only allow onward connections to be made. This enables you - to run (for example) a proxy <application>telnet</application> server on your firewall host, - and people can <application>telnet</application> in to your firewall from the outside, go - through some authentication mechanism, and then gain access to the - internal network (alternatively, proxy servers can be used for - signals coming from the internal network and heading out).</para> - - <para>Proxy servers are normally more secure than normal servers, and - often have a wider variety of authentication mechanisms available, - including <quote>one-shot</quote> password systems so that even if - someone manages to discover what password you used, they will not be - able to use it to gain access to your systems as the password - expires immediately after the first use. As they do not actually give users access to the - host machine, it becomes a lot more difficult for someone to install - backdoors around your security system.</para> - - <para>Proxy servers often have ways of restricting access further, so - that only certain hosts can gain access to the servers. - Most will also allow the administrator to specify which - users can talk to which destination machines. - Again, what facilities are available - depends largely on what proxy software you choose.</para> + + <sect3> + <title>Inclusive Rule set Example</title> + <para>The following rule set is an example of how to code a very + secure inclusive type of firewall. An inclusive firewall only + allows services matching pass rules through and blocks all + other by default. All firewalls have at the minimum two + interfaces which have to have rules to allow the firewall to + function.</para> + + <para>All Unix flavored systems including &os; are designed + to use interface l0 and IP address 127.0.0.1 for internal + communication with in the &os; operating system. The + firewall rules must contain rules to allow free unmolested + movement of these special internally used packets.</para> + + <para>The interface which faces the public Internet, is the one + which you code your rules to authorize and control access out + to the public Internet and access requests arriving from the + public Internet. This can be your .user ppp. tun0 interface + or your NIC card that is cabled to your DSL or cable modem. + </para> + + <para>In cases where one or more than one NICs are cabled to + Private LANs (local area networks) behind the firewall, those + interfaces must have a rule coded to allow free unmolested + movement of packets originating from those LAN interfaces. + </para> + + <para>The rules should be first organized into three major + sections, all the free unmolested interfaces, public interface + outbound, and the public interface inbound.</para> + + <para>The order of the rules in each of the public interface + sections should be in order of the most used rules being + placed before less often used rules with the last rule in the + section being a block log all packets on that interface and + direction.</para> + + <para>The Outbound section in the following rule set only + contains 'pass' rules which contain selection values that + uniquely identify the service that is authorized for public + Internet access. All the rules have the 'quick', 'on', + 'proto', 'port', and 'keep state' option coded. The 'proto + tcp' rules have the 'flag' option included to identify the + session start request as the triggering packet to activate the + stateful facility.</para> + + <para>The Inbound section has all the blocking of undesirable + packets first for two different reasons. First is these things + being blocked may be part of an otherwise valid packet which + may be allowed in by the later authorized service rules. + Second reason is that by having a rule that explicitly blocks + selected packets that I receive on an infrequent bases and + don't want to see in the log, this keeps them from being + caught by the last rule in the section which blocks and logs + all packets which have fallen through the rules. The last rule + in the section which blocks and logs all packets is how you + create the legal evidence needed to prosecute the people who + are attacking your system.</para> + + <para>Another thing you should take note of, is there is no + response returned for any of the undesirable stuff, their + packets just get dropped and vanish. This way the attackers + has no knowledge if his packets have reached your system. + The less the attackers can learn about your system the more + secure it is. The inbound 'nmap OS fingerprint' attempts + rule I log the first occurrence because this is something a + attacker would do.</para> + + <para>Any time you see log messages on a rule with .log first. + you should do an ipstat -h command to see the number of times + the rule has been matched so you know if your are being + flooded, i.e. under attack.</para> + + <para>When you log packets with port numbers you do not + recognize, go to + <ulink url="http://www.securitystats.com/tools/portsearch.php"></ulink> + and do a port number lookup to find what the purpose of that + port number is.</para> + + <para>Check out this link for port numbers used by Trojans + <ulink url="http://www.simovits.com/trojans/trojans.html"></ulink> + </para> + + <para>The following rule set is a complete very secure + 'inclusive' type of firewall rule set that I have used on my + system. You can not go wrong using this rule set for your own. + Just comment out any pass rules for services to don.t want to + authorize.</para> + + <para>If you see messages in your log that you want to stop + seeing just add a block rule in the inbound section.</para> + + <para>You have to change the <devicename>dc0</devicename> interface name in every rule + to the interface name of the Nic card that connects your + system to the public Internet. For user PPP it would be + <devicename>tun0</devicename>.</para> + + <para>Add the following statements to <filename>/etc/ipf.rules</filename>:</para> + + <programlisting>################################################################# +# No restrictions on Inside Lan Interface for private network +# Not needed unless you have Lan +################################################################# + +#pass out quick on xl0 all +#pass in quick on xl0 all + +################################################################# +# No restrictions on Loopback Interface +################################################################# +pass in quick on lo0 all +pass out quick on lo0 all + +################################################################# +# Interface facing Public Internet (Outbound Section) +# Interrogate session start requests originating from behind the +# firewall on the private network +# or from this gateway server destine for the public Internet. +################################################################# + +# Allow out access to my ISP's Domain name server. +# xxx must be the IP address of your ISP.s DNS. +# Dup these lines if your ISP has more than one DNS server +# Get the IP addresses from /etc/resolv.conf file +pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state +pass out quick on dc0 proto udp from any to xxx port = 53 keep state + +# Allow out access to my ISP's DHCP server for cable or DSL networks. +# This rule is not needed for .user ppp. type connection to the +# public Internet, so you can delete this whole group. +# Use the following rule and check log for IP address. +# Then put IP address in commented out rule & delete first rule +pass out log quick on dc0 proto udp from any to any port = 67 keep state +#pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state + + +# Allow out non-secure standard www function +pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state + +# Allow out secure www function https over TLS SSL +pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state + +# Allow out send & get email function +pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state +pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state + +# Allow out Time +pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state + +# Allow out nntp news +pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state + +# Allow out gateway & LAN users non-secure FTP ( both passive & active modes) +# This function uses the IP<acronym>NAT</acronym> built in FTP proxy function coded in +# the nat rules file to make this single rule function correctly. +# If you want to use the pkg_add command to install application packages +# on your gateway system you need this rule. +pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state + +# Allow out secure FTP, Telnet, and SCP +# This function is using SSH (secure shell) +pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state + +# Allow out non-secure Telnet +pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state + +# Allow out FBSD CVSUP function +pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state + +# Allow out ping to public Internet +pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state + +# Allow out whois for LAN PC to public Internet +pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state + +# Block and log only the first occurrence of everything +# else that.s trying to get out. +# This rule enforces the block all by default logic. +block out log first quick on dc0 all + +################################################################# +# Interface facing Public Internet (Inbound Section) +# Interrogate packets originating from the public Internet +# destine for this gateway server or the private network. +################################################################# + +# Block all inbound traffic from non-routable or reserved address spaces +block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP +block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP +block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 private IP +block in quick on dc0 from 127.0.0.0/8 to any #loopback +block in quick on dc0 from 0.0.0.0/8 to any #loopback +block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-config +block in quick on dc0 from 192.0.2.0/24 to any #reserved for docs +block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect +block in quick on dc0 from 224.0.0.0/3 to any #Class D & E multicast + +##### Block a bunch of different nasty things. ############ +# That I don't want to see in the log + +# Block frags +block in quick on dc0 all with frags + +# Block short tcp packets +block in quick on dc0 proto tcp all with short + +# block source routed packets +block in quick on dc0 all with opt lsrr +block in quick on dc0 all with opt ssrr + +# Block nmap OS fingerprint attempts +# Log first occurrence of these so I can get their IP address +block in log first quick on dc0 proto tcp from any to any flags FUP + +# Block anything with special options +block in quick on dc0 all with ipopts + +# Block public pings +block in quick on dc0 proto icmp all icmp-type 8 + +# Block ident +block in quick on dc0 proto tcp from any to any port = 113 + +# Block all Netbios service. 137=name, 138=datagram, 139=session +# Netbios is MS/Windows sharing services. +# Block MS/Windows hosts2 name server requests 81 +block in log first quick on dc0 proto tcp/udp from any to any port = 137 +block in log first quick on dc0 proto tcp/udp from any to any port = 138 +block in log first quick on dc0 proto tcp/udp from any to any port = 139 +block in log first quick on dc0 proto tcp/udp from any to any port = 81 + +# Allow traffic in from ISP's DHCP server. This rule must contain +# the IP address of your ISP.s DHCP server as it.s the only +# authorized source to send this packet type. Only necessary for +# cable or DSL configurations. This rule is not needed for +# .user ppp. type connection to the public Internet. +# This is the same IP address you captured and +# used in the outbound section. +pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state + +# Allow in standard www function because I have apache server +pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state + +# Allow in non-secure Telnet session from public Internet +# labeled non-secure because ID/PW passed over public Internet as clear text. +# Delete this sample group if you do not have telnet server enabled. +#pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state + +# Allow in secure FTP, Telnet, and SCP from public Internet +# This function is using SSH (secure shell) +pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state + +# Block and log only first occurrence of all remaining traffic +# coming into the firewall. The logging of only the first +# occurrence stops a .denial of service. attack targeted +# at filling up your log file space. +# This rule enforces the block all by default logic. +block in log first quick on dc0 all +################### End of rules file ##################################### + </programlisting> + </sect3> + + <sect3> + <title><acronym>NAT</acronym></title> + <para><acronym>NAT</acronym> stands for Network Address Translation. To those + familiar with Linux, this concept is called IP Masquerading, + <acronym>NAT</acronym> and IP Masquerading are the same thing. One of the many + things the IPF <acronym>NAT</acronym> function enables, is the ability to have a + private Local Area Network (LAN) behind the firewall sharing a + single ISP assigned IP address to the public Internet.</para> + + <para>You ask why would someone want to do this. ISPs normally + assign a dynamic IP address to their non-commercial users. + Dynamic means the IP address can be different each time you + dial in and logon to your ISP, or for cable and DSL modem + users when you power off and then power on your modems you can + get assigned a different IP address. This IP address is how + you are known to the public Internet.</para> + + <para>Now lets say you have 5 PCs at home and each one needs + Internet access. You would have to pay your ISP for an + individual Internet account for each PC and have 5 phone + lines.</para> + + <para>With <acronym>NAT</acronym> you only need a single account with your ISP, + then cable your other 4 PC.s to a switch and the switch to + the NIC in your &os; system which is going to service your + LAN as a gateway. <acronym>NAT</acronym> will automatically translate the private + LAN IP address for each separate PC on the LAN to the single + public IP address as it exits the firewall bound for the + public Internet. It also does the reverse translation for + returning packets.</para> + + <para><acronym>NAT</acronym> is most often accomplished without the approval, or + knowledge, of your ISP and in most cases is grounds for your + ISP terminating your account if found out. Commercial users + pay a lot more for their Internet connection and usually get + assigned a block of static IP address which never change. The + ISP also expects and consents to their Commercial customers + using <acronym>NAT</acronym> for their internal private LANs.</para> + + <para>There is a special range of IP addresses reserved for + <acronym>NAT</acronym>ed private LAN IP address. According to RFC 1918, you can + use the following IP ranges for private nets which will never + be routed directly to the public Internet.</para> + + <informaltable frame="none"> + <tgroup cols="2"> + <colspec colwidth="1*"> + <colspec colwidth="1*"> + <colspec colwidth="1*"> + <tbody> + <row> + <entry>Start IP <hostid role="ipaddr">10.0.0.0</hostid> + </entry> + <entry>-</entry> + <entry>Ending IP <hostid role="ipaddr">10.255.255.255 + </hostid></entry> + </row> + + <row> + <entry>Start IP <hostid role="ipaddr">172.16.0.0</hostid> + </entry> + <entry>-</entry> + <entry>Ending IP <hostid role="ipaddr">172.31.255.255 + </hostid></entry> + </row> + + <row> + <entry>Start IP <hostid role="ipaddr">192.168.0.0</hostid> + </entry> + <entry>-</entry> + <entry>Ending IP <hostid role="ipaddr">192.168.255.255 + </hostid></entry> + </row> + </tbody> + </tgroup> + </informaltable> </sect3> - </sect2> - <sect2> - <title>What Does IPFW Allow Me to Do?</title> - <indexterm><primary><command>ipfw</command></primary></indexterm> - - <para>IPFW, the software supplied with - FreeBSD, is a packet filtering and accounting system which resides in - the kernel, and has a user-land control utility, - &man.ipfw.8;. Together, they allow you to define and query the - rules used by the kernel in its routing decisions.</para> - - <para>There are two related parts to IPFW. - The firewall section performs packet filtering. There is - also an IP accounting section which tracks usage of the - router, based on rules similar to those used in the firewall - section. This allows - the administrator to monitor how much traffic the router is - getting from a certain machine, or how much WWW traffic it is - forwarding, for example.</para> - - <para>As a result of the way that IPFW is - designed, you can use IPFW on non-router - machines to perform packet filtering on incoming and outgoing - connections. This is a special case of the more general use of - IPFW, and the same commands and techniques - should be used in this situation.</para> - </sect2> + <sect3> + <title>IP<acronym>NAT</acronym></title> + <para><acronym>NAT</acronym> rules are loaded by using the ipnat command. Typically + the <acronym>NAT</acronym> rules are stored in <filename>/etc/ipnat.rules + </filename>. See &man.ipnat.1 for details.</para> - <sect2> - <title>Enabling IPFW on FreeBSD</title> - <indexterm> - <primary><command>ipfw</command></primary> - <secondary>enabling</secondary> - </indexterm> - - <para>As the main part of the IPFW system - lives in the kernel, you will need to add one or more options to your - kernel configuration file, depending on what facilities you want, and - recompile your kernel. See "Reconfiguring your Kernel" (<xref - linkend="kernelconfig">) - for more details on how to recompile your - kernel.</para> + <para>When changing the <acronym>NAT</acronym> rules after <acronym>NAT</acronym> has been started, + Make your changes to the file containing the nat rules, then + run ipnat command with the -CF flags to delete the internal + in use <acronym>NAT</acronym> rules and flush the contents of the translation + table of all active entries.</para> - <warning> - <para>IPFW defaults to a policy of <literal>deny ip from any to - any</literal>. If you do not add other rules during startup to - allow access, <emphasis>you will lock yourself out</emphasis> of the - server upon rebooting into a firewall-enabled kernel. We suggest - that you set <literal>firewall_type=open</literal> in your - <filename>/etc/rc.conf</filename> file when first enabling this - feature, then refining the firewall rules in - <filename>/etc/rc.firewall</filename> after you have tested that the - new kernel feature works properly. To be on the safe side, you may - wish to consider performing the initial firewall configuration from - the local console rather than via - <application>ssh</application>. Another option is to build a kernel - using both the <literal>IPFIREWALL</literal> and - <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal> options. This will - change the default rule of IPFW to <literal>allow ip from any to - any</literal> and avoid the possibility of a lockout.</para> - </warning> - - <para>There are currently four kernel configuration options relevant to - IPFW:</para> - - <variablelist> - <varlistentry> - <term><literal>options IPFIREWALL</literal></term> + <para>To reload the <acronym>NAT</acronym> rules issue a command like this:</para> - <listitem> - <para>Compiles into the kernel the code for packet - filtering.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term><literal>options IPFIREWALL_VERBOSE</literal></term> - - <listitem> - <para>Enables code to allow logging of packets through - &man.syslogd.8;. Without this option, even if you specify - that packets should be logged in the filter rules, nothing will - happen.</para> - </listitem> - </varlistentry> + <programlisting>ipnat -CF -f /etc/ipnat.rules</programlisting> - <varlistentry> - <term><literal>options IPFIREWALL_VERBOSE_LIMIT=10</literal></term> - - <listitem> - <para>Limits the number of packets logged through - &man.syslogd.8; on a per entry basis. You may wish to use - this option in hostile environments in which you want to log - firewall activity, but do not want to be open to a denial of - service attack via syslog flooding.</para> - - <para>When a chain entry reaches the packet limit specified, - logging is turned off for that particular entry. To resume - logging, you will need to reset the associated counter using the - &man.ipfw.8; utility:</para> - - <screen>&prompt.root; <userinput>ipfw zero 4500</userinput></screen> - <para>Where 4500 is the chain entry you wish to continue - logging.</para> - </listitem> - </varlistentry> + <para>To display some statistics about your <acronym>NAT</acronym>, use this + command:</para> - <varlistentry> - <term><literal>options IPFIREWALL_DEFAULT_TO_ACCEPT</literal></term> + <programlisting>ipnat -s</programlisting> - <listitem> - <para>This changes the default rule action from <quote>deny</quote> - to <quote>allow</quote>. This avoids the possibility of locking - yourself out if you happen to boot a kernel with - <literal>IPFIREWALL</literal> support but have not configured - your firewall yet. It is also very useful if you often use - &man.ipfw.8; as a filter for specific problems as they arise. - Use with care though, as this opens up the firewall and changes - the way it works.</para> - </listitem> - </varlistentry> - </variablelist> - - <note><para>Previous versions of FreeBSD contained an - <literal>IPFIREWALL_ACCT</literal> option. This is now obsolete as - the firewall code automatically includes accounting - facilities.</para> - </note> - </sect2> + <para>To list the <acronym>NAT</acronym> table's current mappings, use this + command:</para> + + <programlisting>ipnat -l</programlisting> + + <para>To turn verbose mode on, and display information relating + to rule processing and active rules/table entries:</para> + + <programlisting>ipnat -v</programlisting> + </sect3> - <sect2> - <title>Configuring IPFW</title> - <indexterm> - <primary><command>ipfw</command></primary> - <secondary>configuring</secondary> - </indexterm> - - <para>The configuration of the IPFW software - is done through the &man.ipfw.8; utility. The syntax for this - command looks quite complicated, but it is relatively simple once you - understand its structure.</para> - - <para>There are currently four different command categories used by the - utility: addition/deletion, listing, flushing, and clearing. - Addition/deletion is used to build the rules that control how packets - are accepted, rejected, and logged. Listing is used to examine the - contents of your rule set (otherwise known as the chain) and packet - counters (accounting). Flushing is used to remove all entries from - the chain. Clearing is used to zero out one or more accounting - entries.</para> - <sect3> - <title>Altering the IPFW Rules</title> - - <para>The syntax for this form of the command is: - <cmdsynopsis> - <command>ipfw</command> - <arg>-N</arg> - <arg choice="plain">command</arg> - <arg>index</arg> - <arg choice="plain">action</arg> - <arg>log</arg> - <arg choice="plain">protocol</arg> - <arg choice="plain">addresses</arg> - <arg>options</arg> - </cmdsynopsis></para> - - <para>There is one valid flag when using this form of the - command:</para> - - <variablelist> - <varlistentry> - <term>-N</term> - - <listitem> - <para>Resolve addresses and service names in output.</para> - </listitem> - </varlistentry> - </variablelist> + <title>IP<acronym>NAT</acronym> Rules</title> + <para><acronym>NAT</acronym> rules are very flexible and can accomplish many + different things to fit the needs of commercial and home + users.</para> - <para>The <emphasis>command</emphasis> given can be shortened to the - shortest unique form. The valid <emphasis>commands</emphasis> - are:</para> - - <variablelist> - <varlistentry> - <term>add</term> + <para>The rule syntax presented here has been simplified to + what is most commonly used in a non-commercial environment. + For a complete rule syntax description see the man ipf page + at &man.ipnat.5;.</para> - <listitem> - <para>Add an entry to the firewall/accounting rule list</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>delete</term> - - <listitem> - <para>Delete an entry from the firewall/accounting rule - list</para> - </listitem> - </varlistentry> - </variablelist> + <para>The syntax for a <acronym>NAT</acronym> rule looks something like this: + </para> - <para>Previous versions of IPFW used - separate firewall and accounting entries. The present version - provides packet accounting with each firewall entry.</para> - - <para>If an <emphasis>index</emphasis> value is supplied, it is used to - place the entry at a specific point in the chain. Otherwise, the - entry is placed at the end of the chain at an index 100 greater than - the last chain entry (this does not include the default policy, rule - 65535, deny).</para> - - <para>The <literal>log</literal> option causes matching rules to be - output to the system console if the kernel was compiled with - <literal>IPFIREWALL_VERBOSE</literal>.</para> - - <para>Valid <emphasis>actions</emphasis> are:</para> - - <variablelist> - <varlistentry> - <term>reject</term> - - <listitem> - <para>Drop the packet, and send an ICMP host or port unreachable - (as appropriate) packet to the source.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>allow</term> - - <listitem> - <para>Pass the packet on as normal. (aliases: - <literal>pass</literal>, <literal>permit</literal>, and - <literal>accept</literal>)</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>deny</term> - - <listitem> - <para>Drop the packet. The source is not notified via an - ICMP message (thus it appears that the packet never - arrived at the destination).</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>count</term> - - <listitem> - <para>Update packet counters but do not allow/deny the packet - based on this rule. The search continues with the next chain - entry.</para> - </listitem> - </varlistentry> - </variablelist> + <programlisting>map <replaceable>IF</replaceable> <replaceable>LAN_IP_RANGE</replaceable> -> <replaceable>PUBLIC_ADDRESS</replaceable></programlisting> - <para>Each <emphasis>action</emphasis> will be recognized by the - shortest unambiguous prefix.</para> - - <para>The <emphasis>protocols</emphasis> which can be specified - are:</para> - - <variablelist> - <varlistentry> - <term>all</term> + <para>The keyword `map' starts the rule.</para> - <listitem> - <para>Matches any IP packet</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>icmp</term> - - <listitem> - <para>Matches ICMP packets</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>tcp</term> - - <listitem> - <para>Matches TCP packets</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>udp</term> - - <listitem> - <para>Matches UDP packets</para> - </listitem> - </varlistentry> - </variablelist> + <para>Replace <replaceable>IF</replaceable> with the external + interface.</para> - <para>The <emphasis>address</emphasis> specification is:</para> + <para>The <replaceable>LAN_IP_RANGE</replaceable> is what your + internal clients use for IP Addressing, usually this is + something like <hostid role="ipaddr">192.168.1.0/24</hostid>. + </para> - <cmdsynopsis> - <arg choice="plain">from</arg> - <arg choice="plain"><replaceable>address/mask</replaceable></arg><arg><replaceable>port</replaceable></arg> - <arg choice="plain">to</arg> - <arg choice="plain"><replaceable>address/mask</replaceable></arg><arg><replaceable>port</replaceable></arg> - <arg>via <replaceable>interface</replaceable></arg> - </cmdsynopsis> - - <para>You can only specify <replaceable>port</replaceable> in - conjunction with <emphasis>protocols</emphasis> which support ports - (UDP and TCP).</para> - - <para>The <option>via</option> is optional and may specify the IP - address or domain name of a local IP interface, or an interface name - (e.g. <devicename>ed0</devicename>) to match only packets coming - through this interface. Interface unit numbers can be specified - with an optional wildcard. For example, <literal>ppp*</literal> - would match all kernel PPP interfaces.</para> - - <para>The syntax used to specify an - <replaceable>address/mask</replaceable> is: - - <screen><replaceable>address</replaceable></screen> - - or - - <screen><replaceable>address</replaceable>/<replaceable>mask-bits</replaceable></screen> - - or - - <screen><replaceable>address</replaceable>:<replaceable>mask-pattern</replaceable></screen> - </para> - - <para>A valid hostname may be specified in place of the IP address. - <option><replaceable>mask-bits</replaceable></option> is a decimal - number representing how many bits in the address mask should be set. - e.g. specifying <hostid role="netmask">192.216.222.1/24</hostid> - will create a - mask which will allow any address in a class C subnet (in this case, - <hostid role="ipaddr">192.216.222</hostid>) to be matched. - <option><replaceable>mask-pattern</replaceable></option> is an IP - address which will be logically AND'ed with the address given. The - keyword <literal>any</literal> may be used to specify <quote>any IP - address</quote>.</para> - - <para>The port numbers to be blocked are specified as: - - <cmdsynopsis> - <arg choice="plain"><replaceable>port</replaceable><arg>,<replaceable>port</replaceable><arg>,<replaceable>port</replaceable><arg>…</arg></arg></arg></arg> - </cmdsynopsis> + <para>The <replaceable>PUBLIC_ADDRESS</replaceable> can either + be the external IP address or the special keyword `0.32', + which means to use the IP address assigned to + <replaceable>IF</replaceable>.</para> + </sect3> - to specify either a single port or a list of ports, or - - <cmdsynopsis> - <arg choice="plain"><replaceable>port</replaceable>-<replaceable>port</replaceable></arg> - </cmdsynopsis> + <sect3> + <title>How <acronym>NAT</acronym> works</title> + <para>A packet arrives at the firewall from the LAN with a + public destination. It passes through the outbound filter + rules, <acronym>NAT</acronym> gets his turn at the packet and applies its rules + top down, first matching rule wins. <acronym>NAT</acronym> tests each of its + rules against the packets interface name and source IP + address. When a packets interface name matches a <acronym>NAT</acronym> rule then + the [source IP address, i.e. private Lan IP address] of the + packet is checked to see if it falls within the IP address + range specified to the left of the arrow symbol on the <acronym>NAT</acronym> + rule. On a match the packet has its source IP address + rewritten with the public IP address obtained by the `0.32' + keyword. <acronym>NAT</acronym> posts a entry in its internal <acronym>NAT</acronym> table so when + the packet returns from the public Internet it can be mapped + back to its original private IP address and then passed to + the filter rules for processing.</para> - to specify a range of ports. You may also combine a single range - with a list, but the range must always be specified first.</para> - - <para>The <emphasis>options</emphasis> available are:</para> + </sect3> - <variablelist> - <varlistentry> - <term>frag</term> + <sect3> + <title>Enabling IP<acronym>NAT</acronym></title> + <para>To enable IP<acronym>NAT</acronym> add these statements to + <filename>/etc/rc.conf</filename></para> - <listitem> - <para>Matches if the packet is not the first fragment of the - datagram.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>in</term> - - <listitem> - <para>Matches if the packet is on the way in.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>out</term> - - <listitem> - <para>Matches if the packet is on the way out.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ipoptions <replaceable>spec</replaceable></term> - - <listitem> - <para>Matches if the IP header contains the comma separated list - of options specified in <replaceable>spec</replaceable>. The - supported IP options are: <literal>ssrr</literal> - (strict source route), <literal>lsrr</literal> (loose source - route), <literal>rr</literal> (record packet route), and - <literal>ts</literal> (time stamp). The absence of a - particular option may be specified with a leading - <literal>!</literal>.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>established</term> - - <listitem> - <para>Matches if the packet is part of an already established - TCP connection (i.e. it has the RST or ACK bits set). You can - optimize the performance of the firewall by placing - <emphasis>established</emphasis> rules early in the - chain.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>setup</term> - - <listitem> - <para>Matches if the packet is an attempt to establish a TCP - connection (the SYN bit is set but the ACK bit is - not).</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>tcpflags <replaceable>flags</replaceable></term> - - <listitem> - <para>Matches if the TCP header contains the comma separated - list of <replaceable>flags</replaceable>. The supported flags - are <literal>fin</literal>, <literal>syn</literal>, - <literal>rst</literal>, <literal>psh</literal>, - <literal>ack</literal>, and <literal>urg</literal>. The - absence of a particular flag may be indicated by a leading - <literal>!</literal>.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>icmptypes <replaceable>types</replaceable></term> - - <listitem> - <para>Matches if the ICMP type is present in the list - <replaceable>types</replaceable>. The list may be specified - as any combination of ranges and/or individual types separated - by commas. Commonly used ICMP types are: <literal>0</literal> - echo reply (ping reply), <literal>3</literal> destination - unreachable, <literal>5</literal> redirect, - <literal>8</literal> echo request (ping request), and - <literal>11</literal> time exceeded (used to indicate TTL - expiration as with &man.traceroute.8;).</para> - </listitem> - </varlistentry> - </variablelist> + <para>To enable your machine to route traffic between + interfaces.</para> + + <programlisting>gateway_enable="YES"</programlisting> + + <para>To start IP<acronym>NAT</acronym> automatically each time:</para> + + <programlisting>ipnat_enable="YES"</programlisting> + + <para>To specify where to load the IP<acronym>NAT</acronym> rules from</para> + + <programlisting>ipnat_rules="/etc/ipnat.rules"</programlisting> </sect3> - + <sect3> - <title>Listing the IPFW Rules</title> - - <para>The syntax for this form of the command is: - <cmdsynopsis> - <command>ipfw</command> - <arg>-a</arg> - <arg>-c</arg> - <arg>-d</arg> - <arg>-e</arg> - <arg>-t</arg> - <arg>-N</arg> - <arg>-S</arg> - <arg choice="plain">list</arg> - </cmdsynopsis></para> - - <para>There are seven valid flags when using this form of the - command:</para> - - <variablelist> - <varlistentry> - <term>-a</term> - - <listitem> - <para>While listing, show counter values. This option is the - only way to see accounting counters.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>-c</term> + <title><acronym>NAT</acronym> for a very large LAN</title> + <para>For networks that have large numbers of PC's on the Lan or + networks with more that a single LAN the process of funneling + all those private IP address into a single public IP address + becomes a resource problem that may cause problems with same + port numbers being used many times across many <acronym>NAT</acronym>ed LAN PC's + causing collisions. There are 2 ways to relieve this resource + problem.</para> + + <sect4> + <title>Assigning Ports to Use</title> + <para>BLAH</para> + <programlisting>map dc0 192.168.1.0/24 -> 0.32</programlisting> + + <para>In the above rule the packet's source port is unchanged + as the packet passes through IP<acronym>NAT</acronym>. By adding the portmap + keyword you can tell IP<acronym>NAT</acronym> to only use source ports in a + range. For example the following rule will tell IP<acronym>NAT</acronym> to + modify the source port to be within that range. + + <programlisting>map dc0 192.168.1.0/24 -> 0.32 portmap tcp/udp 20000:60000</programlisting> + + <para>Additionally we can make things even easier by using + the `auto' keyword to tell IP<acronym>NAT</acronym> to determine by itself + which ports are available to use:</para> + + <programlisting>map dc0 192.168.1.0/24 -> 0.32 portmap tcp/udp auto</programlisting> + </sect4> - <listitem> - <para>List rules in compact form.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>-d</term> + <sect4> + <title>Using a pool of public addresses</title> + <para>In very large LANs there comes a point where there are + just too many LAN addresses to fit into a single public + address. By changing the following rule:</para> - <listitem> - <para>Show dynamic rules in addition to static rules.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>-e</term> + <programlisting>map dc0 192.168.1.0/24 -> 204.134.75.1</programlisting> - <listitem> - <para>If <option>-d</option> was specified, also show expired - dynamic rules.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>-t</term> - - <listitem> - <para>Display the last match times for each chain entry. The - time listing is incompatible with the input syntax used by the - &man.ipfw.8; utility.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>-N</term> - - <listitem> - <para>Attempt to resolve given addresses and service - names.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term>-S</term> - - <listitem> - <para>Show the set each rule belongs to. If this flag is not - specified, disabled rules will not be listed.</para> - </listitem> - </varlistentry> - </variablelist> + <para>Currently this rule maps all connections through + <hostid role="ipaddr">204.134.75.1</hostid>. This can be + changed to specify a range:</para> + + <programlisting>map dc0 192.168.1.0/24 -> 204.134.75.1-10</programlisting> + + <para>Or a subnet using CIDR notation such as:</para> + + <programlisting>map dc0 192.168.1.0/24 -> 204.134.75.0/24</programlisting> + </sect4> </sect3> - + <sect3> - <title>Flushing the IPFW Rules</title> - - <para>The syntax for flushing the chain is: - <cmdsynopsis> - <command>ipfw</command> - <arg choice="plain">flush</arg> - </cmdsynopsis></para> - - <para>This causes all entries in the firewall chain to be removed - except the fixed default policy enforced by the kernel (index - 65535). Use caution when flushing rules; the default deny policy - will leave your system cut off from the network until allow entries - are added to the chain.</para> + <title>Port Redirection</title> + <para>An very common practice is to have a web server, email + server, database server and DNS sever each segregated to a + different PC on the LAN. In this case the traffic from these + servers still have to be <acronym>NAT</acronym>ed, but there has to be some way + to direct the inbound traffic to the correct LAN PC's. IP<acronym>NAT</acronym> + has the redirection facilities of <acronym>NAT</acronym> to solve this problem. + Lets say you have your web server on LAN address + <hostid role="ipaddr">10.0.10.25</hostid> and your single + public IP address is <hostid role="ipaddr">20.20.20.5</hostid> + you would code the rule like this:</para> + + <programlisting>map dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80</programlisting> + + <para>or</para> + + <programlisting>map dc0 0/32 port 80 -> 10.0.10.25 port 80</programlisting> + + <para>or for a LAN DNS Server on LAN address of + <hostid role="ipaddr">10.0.10.33</hostid> that needs to + receive public DNS requests</para> + + <programlisting>map dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp</programlisting> </sect3> - + <sect3> - <title>Clearing the IPFW Packet Counters</title> - - <para>The syntax for clearing one or more packet counters is: - <cmdsynopsis> - <command>ipfw</command> - <arg choice="plain">zero</arg> - <arg choice="opt"><replaceable>index</replaceable></arg> - </cmdsynopsis></para> - - <para>When used without an <replaceable>index</replaceable> argument, - all packet counters are cleared. If an - <replaceable>index</replaceable> is supplied, the clearing operation - only affects a specific chain entry.</para> + <title>FTP and <acronym>NAT</acronym></title> + <para>FTP is a dinosaur left over from the time before the + Internet as it is know today, when research universities were + leased lined together and FTP was used to share files among + research Scientists. This was a time when data security was + not even an idea yet. Over the years the FTP protocol became + buried into the backbone of the emerging Internet and its + username and password being sent in clear text was never + changed to address new security concerns. FTP has two flavors, + it can run in active mode or passive mode. The difference is + in how the data channel is acquired. Passive mode is more + secure as the data channel is acquired be the ordinal ftp + session requester. For a real good explanation of FTP and the + different modes see + <ulink url="http://www.slacksite.com/other/ftp.html"></ulink> + </para> + + <sect4> + <title>IP<acronym>NAT</acronym> Rules</title> + + <para>IP<acronym>NAT</acronym> has a special built in FTP proxy option which can be + specified on the <acronym>NAT</acronym> map rule. It can monitor all outbound + packet traffic for FTP active or passive start session + requests and dynamically create temporary filter rules + containing only the port number really in use for the data + channel. This eliminates the security risk FTP normally + exposes the firewall to from having large ranges of high order + port numbers open.</para> + + <para>This rule will handle all the traffic for the internal + LAN:</para> + + <programlisting>map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp</programlisting> + + <para>This rule handles the FTP traffic from the gateway.</para> + + <programlisting>map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp</programlisting> + + <para>This rule handles all non-FTP traffic from the internal + LAN.</para> + + <programlisting>map dc0 10.0.10.0/29 -> 0/32</programlisting> + + <para>The FTP map rule goes before our regular map rule. All + packets are tested against the first rule from the top. + Matches on interface name, then private LAN source IP + address, and then is it a FTP packet. If all that matches + then the special FTP proxy creates temp filter rules to let + the FTP session packets pass in and out, in addition to also + <acronym>NAT</acronym>ing the FTP packets. All LAN packets that are not FTP do + not match the first rule and fall through to the third rule + and are tested, matching on interface and source IP, then + are <acronym>NAT</acronym>ed.</para> + </sect4> + <sect4> + <title>IP<acronym>NAT</acronym> FTP Filter Rules</title> + <para>Only one filter rule is needed for FTP if the <acronym>NAT</acronym> FTP + proxy is used.</para> + + <para>Without the FTP Proxy you will need the following three + rules</para> + + <programlisting># Allow out LAN PC client FTP to public Internet +# Active and passive modes +pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state + +# Allow out passive mode data channel high order port numbers +pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state + +# Active mode let data channel in from FTP server +pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state</programlisting> + </sect4> + <sect4> + <title>FTP <acronym>NAT</acronym> Proxy Bug</title> + <para>As of &os; 4.9 which includes IPFILTER version 3.4.31 + the FTP proxy works as documented during the FTP session + until the session is told to close. When the close happens + packets returning from the remote FTP server are blocked and + logged coming in on port 21. The <acronym>NAT</acronym> FTP/proxy appears to + remove its temp rules prematurely, before receiving the + response from the remote FTP server acknowledging the close. + Posted problem report to ipf mailing list.</para> + + <para>Solution is to add filter rule like this one to get rid + of these unwanted log messages or do nothing and ignore FTP + inbound error messages in your log. Not like you do FTP + session to the public Internet all the time, so this is not + a big deal.</para> + + <programlisting>Block in quick on rl0 proto tcp from any to any port = 21</programlisting> + </sect4> </sect3> </sect2> <sect2> - <title>Example Commands for <application>ipfw</application></title> - - <para>This command will deny all packets from the host <hostid - role="fqdn">evil.crackers.org</hostid> to the telnet port of the - host <hostid role="fqdn">nice.people.org</hostid>:</para> - - <screen>&prompt.root; <userinput>ipfw add deny tcp from evil.crackers.org to nice.people.org 23</userinput></screen> - - <para>The next example denies and logs any TCP traffic from the entire - <hostid role="domainname">crackers.org</hostid> network (a class C) to - the <hostid role="fqdn">nice.people.org</hostid> machine (any - port).</para> - - <screen>&prompt.root; <userinput>ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org</userinput></screen> - - <para>If you do not want people sending X sessions to your internal - network (a subnet of a class C), the following command will do the - necessary filtering:</para> - - <screen>&prompt.root; <userinput>ipfw add deny tcp from any to my.org/28 6000 setup</userinput></screen> - - <para>To see the accounting records: - - <screen>&prompt.root; <userinput>ipfw -a list</userinput></screen> + <title>IPFW</title> + <para>The IPFIREWALL (IPFW) is a &os; sponsored firewall + software application authored and maintained by &os; + volunteer staff members. It uses the legacy Stateless rules and + a legacy rule coding technique to achieve what is referred to as + Simple Stateful logic.</para> + + <para>The IPFW stateless rule syntax is empowered with technically + sophisticated selection capabilities which far surpasses the + knowledge level of the customary firewall installer. IPFW is + targeted at the professional user or the advanced technical + computer hobbyist who have advanced packet selection + requirements. A high degree of detailed knowledge into how + different protocols use and create their unique packet header + information is necessary before the power of the IPFW rules can + be unleashed. Providing that level of explanation is out of the + scope of this section of the handbook.</para> + + <para>IPFW is composed of 7 components, the primary component is + the kernel firewall filter rule processor and its integrated + packet accounting facility, the logging facility, the 'divert' + rule which triggers the <acronym>NAT</acronym> facility, and the advanced special + purpose facilities, the dummynet traffic shaper facilities, the + 'fwd rule' forward facility, the bridge facility, and the + ipstealth facility.</para> - or in the short form - - <screen>&prompt.root; <userinput>ipfw -a l</userinput></screen> - </para> + <sect3> + <title>Enabling IPFW</title> + <para>IPFW is included in the basic &os; install as a + separate run time loadable module. IPFW will dynamically load + the kernel module when the <filename>rc.conf</filename> + statement <literal>firewall_enable="YES"</literal> is used. You do not need to + compile IPFW into the &os; kernel unless you want <acronym>NAT</acronym> + function enabled.</para> + + <para>After rebooting your system with <literal>firewall_enable="YES"</literal> in + <filename>rc.conf</filename> the following white highlighted + message is displayed on the screen as part of the boot + process:</para> + + <screen>IP packet filtering initialized, divert disabled, rule-based forwarding +enabled, default to deny, logging disabled</screen> + + <para>You can disregard this message as it is out dated and no + longer is the true status of the IPFW loadable module. The + loadable module really does have logging ability compiled in. + </para> + + <para>To set the verbose logging limit, There is a knob you can + set in <filename>/etc/sysctl.conf</filename> by adding this + statement, logging will be enabled on future reboots.</para> + + <programlisting>net.inet.ip.fw.verbose_limit=5</programlisting> + </sect3> - <para>You can also see the last time a chain entry was matched - with:</para> - - <screen>&prompt.root; <userinput>ipfw -at l</userinput></screen> - </sect2> - - <sect2> - <title>Building a Packet Filtering Firewall</title> - - <note> - <para>The following suggestions are just that: suggestions. The - requirements of each firewall are different and we cannot tell you - how to build a firewall to meet your particular requirements.</para> - </note> - - <para>When initially setting up your firewall, unless you have a test - bench setup where you can configure your firewall host in a controlled - environment, it is strongly recommend you use the logging version of the - commands and enable logging in the kernel. This will allow you to - quickly identify problem areas and cure them without too much - disruption. Even after the initial setup phase is complete, I - recommend using the logging for `deny' as it allows tracing of - possible attacks and also modification of the firewall rules if your - requirements alter.</para> - - <note> - <para>If you use the logging versions of the <command>accept</command> - command, be aware that it can generate - <emphasis>large</emphasis> amounts of log data. One log - entry will be generated for every packet that passes - through the firewall, so large FTP/http transfers, etc, will really - slow the system down. It also increases the latencies on those - packets as it requires more work to be done by the kernel before the - packet can be passed on. <application>syslogd</application> will - also start using up a lot - more processor time as it logs all the extra data to disk, and it - could quite easily fill the partition <filename>/var/log</filename> - is located on.</para> - </note> - - <para>You should enable your firewall from - <filename>/etc/rc.conf.local</filename> or - <filename>/etc/rc.conf</filename>. The associated manual page explains - which knobs to fiddle and lists some preset firewall configurations. - If you do not use a preset configuration, <command>ipfw list</command> - will output the current ruleset into a file that you can - pass to <filename>rc.conf</filename>. If you do not use - <filename>/etc/rc.conf.local</filename> or - <filename>/etc/rc.conf</filename> to enable your firewall, - it is important to make sure your firewall is enabled before - any IP interfaces are configured.</para> - - <para>The next problem is what your firewall should actually - <emphasis>do</emphasis>! This is largely dependent on what access to - your network you want to allow from the outside, and how much access - to the outside world you want to allow from the inside. Some general - rules are:</para> - - <itemizedlist> - <listitem> - <para>Block all incoming access to ports below 1024 for TCP. This is - where most of the security sensitive services are, like finger, - SMTP (mail) and telnet.</para> - </listitem> + <sect3> + <title>Kernel Options</title> + <para>It is not a mandatory requirement that you enable IPFW by + compiling the following options into the &os; kernel unless + you need <acronym>NAT</acronym> function. It is presented here as background + information.</para> - <listitem> - <para>Block <emphasis>all</emphasis> incoming UDP traffic. There - are very few useful services that travel over UDP, and what useful - traffic there is, is normally a security threat (e.g. Suns RPC and - NFS protocols). This has its disadvantages also, since UDP is a - connectionless protocol, denying incoming UDP traffic also blocks - the replies to outgoing UDP traffic. This can cause a problem for - people (on the inside) using external archie (prospero) servers. - If you want to allow access to archie, you will have to allow - packets coming from ports 191 and 1525 to any internal UDP port - through the firewall. <application>ntp</application> is another - service you may consider allowing through, which comes from port - 123.</para> - </listitem> - - <listitem> - <para>Block traffic to port 6000 from the outside. Port 6000 is the - port used for access to X11 servers, and can be a security threat - (especially if people are in the habit of doing <command>xhost - +</command> on their workstations). X11 can actually use a - range of ports starting at 6000, the upper limit being how many X - displays you can run on the machine. The upper limit as defined - by RFC 1700 (Assigned Numbers) is 6063.</para> - </listitem> - - <listitem> - <para>Check what ports any internal servers use (e.g. SQL servers, - etc). It is probably a good idea to block those as well, as they - normally fall outside the 1-1024 range specified above.</para> - </listitem> - </itemizedlist> - - <para>Another checklist for firewall configuration is available from - CERT at <ulink - url="http://www.cert.org/tech_tips/packet_filtering.html"></ulink></para> - - <para>As stated above, these are only <emphasis>guidelines</emphasis>. - You will have to decide what filter rules you want to use on your - firewall yourself. We cannot accept ANY responsibility if someone - breaks into your network, even if you follow the advice given - above.</para> - </sect2> + <programlisting>options IPFIREWALL</programlisting> - <sect2 id="ipfw-overhead"> - <title>IPFW Overhead and Optimization</title> - - <para>Many people want to know how much overhead IPFW adds to a - system. The answer to this depends mostly on your rule set and - processor speed. For most applications dealing with Ethernet - and small rule sets, the answer is - <quote>negligible</quote>. For those of you that need actual - measurements to satisfy your curiosity, read on.</para> - - <para>The following measurements were made using 2.2.5-STABLE on - a 486-66. (While IPFW has changed slightly in later releases - of FreeBSD, it still performs with similar speed.) IPFW was - modified to measure the time spent within the - <literal>ip_fw_chk</literal> routine, displaying the results - to the console every 1000 packets.</para> - - <para>Two rule sets, each with 1000 rules, were tested. The - first set was designed to demonstrate a worst case scenario by - repeating the rule:</para> - - <screen>&prompt.root; <userinput>ipfw add deny tcp from any to any 55555</userinput></screen> - - <para>This demonstrates a worst case scenario by causing most of IPFW's - packet check routine to be executed before finally deciding - that the packet does not match the rule (by virtue of the port - number). Following the 999th iteration of this rule was an - <literal>allow ip from any to any</literal>.</para> - - <para>The second set of rules were designed to abort the rule - check quickly:</para> - - <screen>&prompt.root; <userinput>ipfw add deny ip from 1.2.3.4 to 1.2.3.4</userinput></screen> - - <para>The non-matching source IP address for the above rule - causes these rules to be skipped very quickly. As before, the - 1000th rule was an <literal>allow ip from any to - any</literal>.</para> - - <para>The per-packet processing overhead in the former case was - approximately 2.703 ms/packet, or roughly 2.7 microseconds per - rule. Thus the theoretical packet processing limit with these - rules is around 370 packets per second. Assuming 10 Mbps - Ethernet and a ~1500 byte packet size, we would only be able - to achieve 55.5% bandwidth utilization.</para> - - <para>For the latter case each packet was processed in - approximately 1.172 ms, or roughly 1.2 microseconds per rule. - The theoretical packet processing limit here would be about - 853 packets per second, which could consume 10 Mbps Ethernet - bandwidth.</para> - - <para>The excessive number of rules tested and the nature of - those rules do not provide a real-world scenario -- they were - used only to generate the timing information presented here. - Here are a few things to keep in mind when building an - efficient rule set:</para> + <para>This option enables IPFW as part of the kernel</para> - <itemizedlist> - <listitem> - <para>Place an <literal>established</literal> rule early on - to handle the majority of TCP traffic. Do not put any - <literal>allow tcp</literal> statements before this - rule.</para> - </listitem> + <programlisting>options IPFIREWALL_VERBOSE</programlisting> - <listitem> - <para>Place heavily triggered rules earlier in the rule set - than those rarely used (<emphasis>without changing the - permissiveness of the firewall</emphasis>, of course). - You can see which rules are used most often by examining - the packet counting statistics with <command>ipfw -a - l</command>.</para> - </listitem> - </itemizedlist> + <para>Enables logging of packets that pass through IPFW and + have the 'log' keyword specified in the rule set.</para> + + <programlisting>options IPFIREWALL_VERBOSE_LIMIT=5</programlisting> + + <para>This specifies the default number of packets from a + particular rule is to be logged. Without this option, each + repeated occurrences of the same packet will be logged, and + eventually consuming all the free disk space resulting in + services being denied do to lack of resources. The 5 is the + number of consecutive times to log evidence of this unique + occurrence.</para> + + <programlisting>options IPFIREWALL_DEFAULT_TO_ACCEPT</programlisting> + + <para>This option will allow everything to pass through the + firewall by default. Which is a good idea when you are first + setting up your firewall.</para> + + <programlisting>options IPV6FIREWALL +options IPV6FIREWALL_VERBOSE +options IPV6FIREWALL_VERBOSE_LIMIT +options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting> + + <para>These options are exactly the same as the IPv4 options + but they are for IPv6. If you don't use IPv6 you might want + to use IPV6FIREWALL without any rules to block all IPv6</para> + + <programlisting>options IPDIVERT</programlisting> + + <para>This enables the use of <acronym>NAT</acronym> functionality.</para> + + <note> + <para>If you don't include IPFIREWALL_DEFAULT_TO_ACCEPT or set + your rules to allow incoming packets you will block all + packets going to and from this machine.</para> + </note> + </sect3> + + <sect3> + <title><filename>/etc/rc.conf</filename> Options</title> + <para>If you don't have IPFW compliled into your kernel you will + need to load it with the following statement in your + <filename>/etc/rc.conf</filename>:</para> + + <programlisting>firewall_enable="YES"</programlisting> + + <para>Set the script to run to activate your rules:</para> + + <programlisting>firewall_script="/etc/ipfw.rules"</programlisting> + + <para>Enable logging:</para> + + <programlisting>firewall_logging="YES"</programlisting> + </sect3> + + <sect3> + <title>The IPFW Command</title> + <para>The ipfw command is the normal vehicle for making manual + single rule additions or deletions to the firewall active + internal rules while it is running. The problem with using this + method is once your system is shutdown or halted all the rules + you added or changed or deleted are lost. Writing all your + rules in a file and using that file to load the rules at boot + time, or to replace in mass the currently running firewall + rules with changes you made to the files content is the + recommended method used here.</para> + + <para>The IPFW command is still a very useful to display the + running firewall rules to the console screen. The IPFW + accounting facility dynamically creates a counter for each + rule that counts each packet that matches the rule. During the + process of testing a rule, listing the rule with its counter + is the only way of determining if the rule is functioning. + </para> + + <para>To list all the rules in sequence:</para> + + <programlisting><command>ipfw list</command></programlisting> + + <para>To list all the rules with a time stamp of when the last + time the rule was matched:</para> + + <programlisting><command>ipfw -t list</command></programlisting> + + <para>To list the accounting information, packet count for + matched rules along with the rules themselves. The first + column is the rule number, followed by the number of outgoing + matched packets, followed by the number of incoming matched + packets, and then the rule itself.</para> + + <programlisting><command>ipfw -a list</command></programlisting> + + <para>List the dynamic rules in addition to the static rules: + </para> + + <programlisting><command>ipfw -d list</command></programlisting> + + <para>Also show the expired dynamic rules:</para> + + <programlisting><command>ipfw -d -e list</command></programlisting> + + <para>Zero the counters:</para> + + <programlisting><command>ipfw zero</command></programlisting> + + <para>Zero the counters for just rule <replaceable>NUM + </replaceable>:</para> + + <programlisting><command>ipfw zero NUM</command></programlisting> + </sect3> + + <sect3> + <title>IPFW Rule Sets</title> + <para>A rule set is a group of ipfw rules coded to allow or deny + packets based on the values contained in the packet. The + bi-directional exchange of packets between hosts comprises a + session conversation. The firewall rule set processes the + packet 2 times, once on its arrival from the public Internet + host and again as it leaves for its return trip back to the + public Internet host. Each tcp/ip service (i.e. telnet, www, + mail, etc.) is predefined by its protocol, and port number. + This is the basic selection criteria used to create rules + which will allow or deny services.</para> + + <para>When a packet enters the firewall it is compared against + the first rule in the rule set and progress one rule at a + time moving from top to bottom of the set in ascending rule + number sequence order. When the packet matches a rule + selection parameters, the rules action field value is executed + and the search of the rule set terminates for that packet. + This is referred to as the 'first match wins' search method. + If the packet does not match any of the rules, it gets caught + by the mandatory ipfw default rule, number 65535 which denies + all packets and discards them without any reply back to the + originating destination.</para> + + <para>The instructions contained here are based on using rules + that contain the stateful 'keep state', 'limit', 'in'/'out', + and via options. This is the basic framework for coding an + inclusive type firewall rule set.</para> + + <para>An inclusive firewall only allows services matching the + rules through. This way you can control what services can + originate behind the firewall destine for the public Internet + and also control the services which can originate from the + public Internet accessing your private network. Everything + else is denied by default design. Inclusive firewalls are + much, much more secure than exclusive firewall rule sets and + is the only rule set type covered here in.</para> + + <warning> + <para>When working with the firewall rules be + careful, you can end up locking your self out.</para> + </warning> + + <sect4> + <title>Rule Syntax</title> + <para>The rule syntax presented here has been simplified to + what is necessary to create a standard inclusive type + firewall rule set. For a complete rule syntax description + see the online &man.ipfw.8; man page.</para> + + <para>Rules contain keywords, These keywords have to be coded + in a specific order from left to right on the line. Keywords + are identified in bold type. Some keywords have sub-options + which may be keywords them selves and also include more + sub-options.</para> + + <para># is used to mark the start of a comment and may appear + at the end of a rule line or on its own lines. Blank lines + are ignored.</para> + + <para><replaceable>CMD RULE# ACTION LOGGING SELECTION STATEFUL + </replaceable></para> + + <sect5> + <title>CMD</title> + <para>Each rule has to be prefixed with 'add' to add the + rule to the internal table.</para> + </sect5> + + <sect5> + <title>RULE#</title> + <para>Each rule has to have a rule number to go with it. + </para> + </sect5> + + <sect5> + <title>ACTION</title> + <para>A rule can be associated with one of the following + actions, which will be executed when the packet matches + the selection criterion of the rule.</para> + + <para><parameter>allow | accept | pass | permit</parameter> + </para> + + <para>These all mean the same thing which is to allow + packets that match the rule to exit the firewall rule + processing. The search terminates at this rule.</para> + + <para><parameter>check-state</parameter></para> + + <para>Checks the packet against the dynamic rules table. If + a match is found, execute the action associated with the + rule which generated this dynamic rule, otherwise move to + the next rule. The Check-state rule does not have + selection criterion. If no check-state rule is present in + the rule set, the dynamic rules table is checked at the + first keep-state or limit rule.</para> + + <para><parameter>deny | drop</parameter></para> + + <para>Both words mean the same thing which is to discard + packets that match this rule. The search terminates. + </para> + </sect5> + + <sect5> + <title>Logging</title> + <para><parameter>log</parameter> or <parameter>logamount + </parameter></para> + + <para> When a packet matches a rule with the log keyword, a + message will be logged to syslogd with a facility name of + SECURITY. The logging only occurs if the number of + packets logged so far for that particular rule does not + exceed the logamount parameter. If no logamount is + specified, the limit is taken from the sysctl variable + net.inet.ip.fw.verbose_limit. In both cases, a value of + zero removes the logging limit. Once the limit is + reached, logging can be re-enabled by clearing the + logging counter or the packet counter for that rule, see + the ipfw reset log command. Note: logging is done after + all other packet matching conditions have been + successfully verified, and before performing the final + action (accept, deny) on the packet. It is up to you to + decide which rules you want to enable logging on.</para> + </sect5> + + <sect5> + <title>Selection</title> + <para>The keywords described in this section are used to + describe attributes of the packet to be interrogated when + determining whether rules match or don't match the packet. + The following general-purpose attributes are provided for + matching, and must be used in this order:</para> + + <para><parameter>udp | tcp | icmp</parameter></para> + + <para>or any protocol names found in /etc/protocols are + recognized and may be used. The value specified is + protocol to be matched against. This is a mandatory + requirement.</para> + + <para><parameter>from src to dst</parameter></para> + + <para>The from and to keywords are used to match against IP + addresses. Rules must specify BOTH source and destination + parameters. any is a special keyword that matches any IP + address. me is a special keyword that matches any IP + address configured on an interface in your &os; system to + represent the PC the firewall is running on. (i.e. this + box) As in from me to any or from any to me or from + 0.0.0.0/0 to any or from any to 0.0.0.0/0 or from 0.0.0.0 + to any or from any to 0.0.0.0 or from me to 0.0.0.0. IP + addresses are specified as a dotted IP address numeric + form/mask-length, or as single dotted IP address numeric + form. This is a mandatory requirement. See this link for + help on writing mask-lengths. <ulink + url="http://jodies.de/ipcalc"></ulink></para> + + <para><parameter>port number</parameter></para> + + <para>For protocols which support port numbers (such as <acronym>TCP</acronym> + and UDP). It is mandatory that you code the port number of + the service you want to match on. Service names (from + <filename>/etc/services</filename>) may be used instead of + numeric port values.</para> + + <para><parameter>in | out</parameter></para> + + <para>Matches incoming or outgoing packets, respectively. The in + and out are keywords and it is mandatory that you code one + or the other as part of your rule matching criterion. + </para> + + <para><parameter>via IF</parameter></para> + + <para>Matches packets going through the interface specified + by exact name. The via keyword causes the interface to + always be checked as part of the match process.</para> + + <para><parameter>setup</parameter></para> + + <para>This is a mandatory keyword that identifies the + session start request for <acronym>TCP</acronym> packets.</para> + + <para><parameter>keep-state</parameter></para> + + <para>This is a mandatory> keyword. Upon a match, the + firewall will create a dynamic rule, whose default + behavior is to match bidirectional traffic between source + and destination IP/port using the same protocol.</para> + + <para><parameter>limit {src-addr | src-port | dst-addr | + dst-port}</parameter></para> + + <para>The firewall will only allow <replaceable>N</replaceable> connections with the + same set of parameters as specified in the rule. One or + more of source and destination addresses and ports can be + specified. The 'limit' and 'keep-state' can not be used on + same rule. Limit provides the same stateful function as + 'keep-state' plus its own functions.</para> + </sect5> + + </sect4> + + <sect4> + <title>Stateful Rule Option</title> + <para>Stateful filtering treats traffic as a bi-directional + exchange of packets comprising a session conversation. It + has the interrogation abilities to determine if the session + conversation between the originating sender and the + destination are following the valid procedure of + bi-directional packet exchange. Any packets that do not + properly fit the session conversation template are + automatically rejected as impostors.</para> + + <para>'check-state' is used to identify where in the IPFW + rules set the packet is to be tested against the dynamic + rules facility. On a match the packet exits the firewall to + continue on its way and a new rule is dynamic created for + the next anticipated packet being exchanged during this + bi-directional session conversation. On a no match the + packet advances to the next rule in the rule set for + testing.</para> + + <para>The dynamic rules facility is vulnerable to resource + depletion from a SYN-flood attack which would open a huge + number of dynamic rules. To counter this attack, &os; + version 4.5 added another new option named limit. This + option is used to limit the number of simultaneous session + conversations by interrogating the rules source or + destinations fields as directed by the limit option and + using the packet's IP address found there, in a search of + the open dynamic rules counting the number of times this + rule and IP address combination occurred, if this count is + greater that the value specified on the limit option, the + packet is discarded.</para> + </sect4> + + <sect4> + <title>Logging Firewall Messages</title> + <para>The benefits of logging are obvious, provides the + ability to review after the fact the rules you activated + logging on which provides information like, what packets had + been dropped, what addresses they came from, where they were + going, giving you a significant edge in tracking down + attackers.</para> + + <para>Even with the logging facility enabled, IPFW will not + generate any rule logging on it's own. The firewall + administrator decides what rules in the rule set he wants to + log and adds the log verb to those rules. Normally only deny + rules are logged. Like the deny rule for incoming <acronym>ICMP</acronym> + pings. It's very customary to duplicate the ipfw default + deny everything rule with the log verb included as your + last rule in the rule set. This way you get to see all the + packets that did not match any of the rules in the rule set.</para> + + <para>Logging is a two edged sword, if you're not careful, you + can lose yourself in the over abundance of log data and fill + your disk up with growing log files. DoS attacks that fill + up disk drives is one of the oldest attacks around. These + log message are not only written to syslogd, but also are + displayed on the root console screen and soon become very + annoying.</para> + + <para>The <literal>IPFIREWALL_VERBOSE_LIMIT=5</literal> kernel option limits the + number of consecutive messages sent to the system logger + syslogd, concerning the packet matching of a given rule. + When this option is enabled in the kernel, the number of + consecutive messages concerning a particular rule is capped + at the number specified. There is nothing to be gained from + 200 log messages saying the same identical thing. For + instance, 5 consecutive messages concerning a particular + rule would be logged to syslogd, the remainder identical + consecutive messages would be counted and posted to the + syslogd with a phrase like this:</para> + + <programlisting>last message repeated 45 times</programlisting> + + <para>All logged packets messages are written by default to + <filename>/var/log/security</filename> file, which is + defined in the <filename>/etc/syslog.conf</filename> file. + </para> + </sect4> + + <sect4> + <title>Building Rule Script</title> + <para>Most experienced IPFW users create a file containing the + rules and code them in a manner compatible with running them + as a script. The major benefit of doing this is the firewall + rules can be refreshed in mass without the need of + rebooting the system to activate the new rules. This method + is very convenient in testing new rules as the procedure can + be executed as many times as needed. Being a script, you can + use symbolic substitution to code frequent used values and + substitution them in multiple rules. You will see this in + the following example.</para> + + <para>The script syntax used here is compatible with the 'sh', + 'csh', 'tcsh' shells. Symbolic substitution fields are + prefixed with a dollar sign $. Symbolic fields do not have + the $ prefix. The value to populate the Symbolic field must + be enclosed to "double quotes".</para> + + <para>Start your rules file like this:</para> + + <programlisting>############### start of example ipfw rules script ############# +# +ipfw -q -f flush # Delete all rules +# Set defaults +oif="tun0" # out interface +odns="192.0.2.11" # ISP's dns server IP address +cmd="ipfw -q add " # build rule prefix +ks="keep-state" # just too lazy to key this each time +$cmd 00500 check-state +$cmd 00502 deny all from any to any frag +$cmd 00501 deny tcp from any to any established +$cmd 00600 allow tcp from any to any 80 out via $oif setup $ks + $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks + $cmd 00611 allow udp from any to $odns 53 out via $oif $ks +################### End of example ipfw rules script ############</programlisting> + + <para>That is all there is to it. The rules are not important + in this example, how the Symbolic substitution field are + populated and used are.</para> + + <para>If the above example was in + <filename>/etc/ipfw.rules</filename> file, you could reload + these rules by entering on the command line.</para> + + <programlisting><command>sh /etc/ipfw.rules</command> + </programlisting> + + <para>The <filename>/etc/ipfw.rules</filename> file could be + located any where you want and the file could be named any + thing you would like.</para> + + <para>The same thing could also be accomplished by running + these commands by hand:</para> + + <programlisting>ipfw -q -f flush +ipfw -q add check-state +ipfw -q add deny all from any to any frag +ipfw -q add deny tcp from any to any established +ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state +ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state +ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state</programlisting> + + </sect4> + <sect4> + <title>Stateful Ruleset</title> + <para>The following non-<acronym>NAT</acronym>ed rule set is a example of how to + code a very secure 'inclusive' type of firewall. An + inclusive firewall only allows services matching pass rules + through and blocks all other by default. All firewalls have + at the minimum two interfaces which have to have rules to + allow the firewall to function.</para> + + <para>All &unix; flavored operating systems, &os; included, are designed to + use interface lo and IP address + <hostid role="ipaddr">127.0.0.1</hostid> for internal + communication with in &os;. The firewall rules must contain + rules to allow free unmolested movement of these special + internally used packets.</para> + + <para>The interface which faces the public Internet, is the + one which you code your rules to authorize and control + access out to the public Internet and access requests + arriving from the public Internet. This can be your ppp tun0 + interface or your NIC that is connected to your DSL or cable + modem.</para> + + <para>In cases where one or more than one NIC are connected to + a private LANs behind the firewall, those interfaces must + have rules coded to allow free unmolested movement of + packets originating from those LAN interfaces.</para> + + <para>The rules should be first organized into three major + sections, all the free unmolested interfaces, public + interface outbound, and the public interface inbound. + </para> + + <para>The order of the rules in each of the public interface + sections should be in order of the most used rules being + placed before less often used rules with the last rule in + the section being a block log all packets on that interface + and direction.</para> + + <para>The Outbound section in the following rule set only + contains 'allow' rules which contain selection values that + uniquely identify the service that is authorized for public + Internet access. All the rules have the, proto, port, + in/out, via and keep state option coded. The 'proto tcp' + rules have the 'setup' option included to identify the start + session request as the trigger packet to be posted to the + keep state stateful table.</para> + + <para>The Inbound section has all the blocking of undesirable + packets first for 2 different reasons. First is these things + being blocked may be part of an otherwise valid packet which + may be allowed in by the later authorized service rules. + Second reason is that by having a rule that explicitly + blocks selected packets that I receive on an infrequent + bases and don't want to see in the log, this keeps them from + being caught by the last rule in the section which blocks + and logs all packets which have fallen through the rules. + The last rule in the section which blocks and logs all + packets is how you create the legal evidence needed to + prosecute the people who are attacking your system.</para> + + <para>Another thing you should take note of, is there is no + response returned for any of the undesirable stuff, their + packets just get dropped and vanish. This way the attackers + has no knowledge if his packets have reached your system. + The less the attackers can learn about your system the more + secure it is. When you log packets with port numbers you do + not recognize, go to + <ulink url="http://www.securitystats.com/tools/portsearch.php"></ulink> + and do a port number lookup to find what the purpose of that + port number is. Check out this link for port numbers used by + Trojans: + <ulink url="http://www.simovits.com/trojans/trojans.html"></ulink> + .</para> + </sect4> + <sect4> + <title>An Example Inclusive Ruleset</title> + <para>The following non-<acronym>NAT</acronym>ed rule set is a complete inclusive + type ruleset. You can not go wrong using this rule set for + you own. Just comment out any pass rules for services to + don't want. If you see messages in your log that you want to + stop seeing just add a deny rule in the inbound section. You + have to change the 'dc0' interface name in every rule to the + interface name of the NIC that connects your system to the + public Internet. For user ppp it would be 'tun0'.</para> + + <para>You will see a pattern in the usage of these rules. + </para> + + <itemizedlist> + <listitem> + <para>All statements that are a request to start a session + to the public Internet use keep-state.</para> + </listitem> + + <listitem> + <para>All the authorized services that originate from the + public Internet have the limit option to stop flooding. + </para> + </listitem> + + <listitem> + <para>All rules use in or out to clarify direction. + </para> + </listitem> + + <listitem> + <para>All rules use via interface name to specify the + interface the packet is traveling over.</para> + </listitem> + </itemizedlist> + + <para>The following rules go into + <filename>/etc/ipfw.rules</filename>.</para> + + <programlisting>################ Start of IPFW rules file ############################### +# Flush out the list before we begin. +ipfw -q -f flush + +# Set rules command prefix +cmd="ipfw -q add" +pif="dc0" # public interface name of Nic card + # facing the public Internet + +################################################################# +# No restrictions on Inside Lan Interface for private network +# Not needed unless you have Lan. +# Change xl0 to your Lan Nic card interface name +################################################################# +#$cmd 00005 allow all from any to any via xl0 + +################################################################# +# No restrictions on Loopback Interface +################################################################# +$cmd 00010 allow all from any to any via lo0 + +################################################################# +# Allow the packet through if it has previous been added to the +# the "dynamic" rules table by a allow keep-state statement. +################################################################# +$cmd 00015 check-state + +################################################################# +# Interface facing Public Internet (Outbound Section) +# Interrogate session start requests originating from behind the +# firewall on the private network or from this gateway server +# destine for the public Internet. +################################################################# + +# Allow out access to my ISP's Domain name server. +# x.x.x.x must be the IP address of your ISP.s DNS +# Dup these lines if your ISP has more than one DNS server +# Get the IP addresses from /etc/resolv.conf file +$cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state +$cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state + +# Allow out access to my ISP's DHCP server for cable/DSL configurations. +# This rule is not needed for .user ppp. connection to the public Internet. +# so you can delete this whole group. +# Use the following rule and check log for IP address. +# Then put IP address in commented out rule & delete first rule +$cmd 00120 allow log udp from any to any 67 out via $pif keep-state +#$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state + +# Allow out non-secure standard www function +$cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state + +# Allow out secure www function https over TLS SSL +$cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state + +# Allow out send & get email function +$cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state +$cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state + +# Allow out FBSD (make install & CVSUP) functions +# Basically give user root "GOD" privileges. +$cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root + +# Allow out ping +$cmd 00250 allow icmp from any to any out via $pif keep-state + +# Allow out Time +$cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state + +# Allow out nntp news (i.e. news groups) +$cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state + +# Allow out secure FTP, Telnet, and SCP +# This function is using SSH (secure shell) +$cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state + +# Allow out whois +$cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state + +# deny and log everything else that.s trying to get out. +# This rule enforces the block all by default logic. +$cmd 00299 deny log all from any to any out via $pif + +################################################################# +# Interface facing Public Internet (Inbound Section) +# Interrogate packets originating from the public Internet +# destine for this gateway server or the private network. +################################################################# + +# Deny all inbound traffic from non-routable reserved address spaces +$cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP +$cmd 00301 deny all from 172.16.0.0/12 to anyin via $pif #RFC 1918 private IP +$cmd 00302 deny all from 10.0.0.0/8 to anyin via $pif #RFC 1918 private IP +$cmd 00303 deny all from 127.0.0.0/8 to anyin via $pif #loopback +$cmd 00304 deny all from 0.0.0.0/8 to anyin via $pif #loopback +$cmd 00305 deny all from 169.254.0.0/16 to anyin via $pif #DHCP auto-config +$cmd 00306 deny all from 192.0.2.0/24 to anyin via $pif #reserved for docs +$cmd 00307 deny all from 204.152.64.0/23 to anyin via $pif #Sun cluster interconnect +$cmd 00308 deny all from 224.0.0.0/3 to anyin via $pif #Class D & E multicast + +# Deny public pings +$cmd 00310 deny icmp from any to anyin via $pif + +# Deny ident +$cmd 00315 deny tcp from any to any 113in via $pif + +# Deny all Netbios service. 137=name, 138=datagram, 139=session +# Netbios is MS/Windows sharing services. +# Block MS/Windows hosts2 name server requests 81 +$cmd 00320 deny tcp from any to any 137in via $pif +$cmd 00321 deny tcp from any to any 138in via $pif +$cmd 00322 deny tcp from any to any 139in via $pif +$cmd 00323 deny tcp from any to any 81 in via $pif + +# Deny any late arriving packets +$cmd 00330 deny all from any to any frag in via $pif + +# Deny ACK packets that did not match the dynamic rule table +$cmd 00332 deny tcp from any to any established in via $pif + +# Allow traffic in from ISP's DHCP server. This rule must contain +# the IP address of your ISP.s DHCP server as it.s the only +# authorized source to send this packet type. +# Only necessary for cable or DSL configurations. +# This rule is not needed for .user ppp. type connection to +# the public Internet. This is the same IP address you captured +# and used in the outbound section. +#$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state + +# Allow in standard www function because I have apache server +$cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 + +# Allow in secure FTP, Telnet, and SCP from public Internet +$cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 + +# Allow in non-secure Telnet session from public Internet +# labeled non-secure because ID & PW are passed over public +# Internet as clear text. +# Delete this sample group if you do not have telnet server enabled. +$cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 + +# Reject & Log all incoming connections from the outside +$cmd 00499 deny log all from any to any in via $pif + +# Everything else is denied by default +# deny and log all packets that fell through to see what they are +$cmd 00999 deny log all from any to any +################ End of IPFW rules file ############################### + </programlisting> + </sect4> + + <sect4> + <title>An Example <acronym>NAT</acronym> and Stateful Ruleset</title> + <para>There are some additional configuration statements that + need to be enabled to activate the <acronym>NAT</acronym> function of IPFW. The + kernel source needs 'option divert' statement added to the + other IPFIREWALL statements compiled into a custom kernel. + </para> + + <para>In addition to the normal IPFW options in + <filename>/etc/rc.conf</filename>, the following are needed. + </para> + + <programlisting>natd_enable="YES" # Enable <acronym>NAT</acronym>D function +natd_interface="rl0" # interface name of public Internet NIC +natd_flags="-dynamic -m" # -m = preserve port numbers if possible</programlisting> + + <para>Utilizing stateful rules with divert natd rule (Network + Address Translation) greatly complicates the rule set coding + logic. The positioning of the check-state, and 'divert natd' + rules in the rule set becomes very critical. This is no + longer a simple fall-through logic flow. A new action type + is used, called 'skipto'. To use the skipto command it is + mandatory that you number each rule so you know exactly + where the skipto rule number is you are really jumping to. + </para> + + <para>The following is an uncommented example of one coding + method, selected here to explain the sequence of the packet + flow through the rule sets.</para> + + <para>The processing flow starts with the first rule from the + top of the rule file and progress one rule at a time deeper + into the file until the end is reach or the packet being + tested to the selection criteria matches and the packet is + released out of the firewall. It's important to take notice + of the location of rule numbers 100 101, 450, 500, and 510. + These rules control the translation of the outbound and + inbound packets so their entries in the keep-state dynamic + table always register the private Lan IP address. Next + notice that all the allow and deny rules specified the + direction the packet is going (IE outbound or inbound) and + the interface. Also notice that all the start outbound + session requests all skipto rule 500 for the network address + translation.</para> + + <para>Lets say a LAN user uses their web browser to get a web + page. Web pages use port 80 to communicate over. So the + packet enters the firewall, It does not match 100 because + it is headed out not in. It passes rule 101 because this is + the first packet so it has not been posted to the keep-state + dynamic table yet. The packet finally comes to rule 125 a + matches. It's outbound through the NIC facing the public + Internet. The packet still has it's source IP address as a + private Lan IP address. On the match to this rule, two + action take place. The keep-state option will post this rule + into the keep-state dynamic rules table and the specified + action is executed. The action is part of the info posted to + the dynamic table. In this case it's "skipto rule 500". Rule + 500 <acronym>NAT</acronym>s the packet IP address and out it goes. Remember + this, this is very important. This packet makes it's way to + the destination and returns and enters the top of the rule + set. This time it does match rule 100 and has it destination + IP address mapped back to it's corresponding Lan IP address. + It then is processed by the check-state rule, it's found in + the table as an existing session conversation and released + to the LAN. It goes to the LAN PC that sent it and a new + packet is sent requesting another segment of the data from + the remote server. This time it gets checked by the + check-state rule and it's outbound entry is found, the + associated action, 'skipto 500', is executed. the packet + jumps to rule 500 gets <acronym>NAT</acronym>ed and released on it's way out. + </para> + + <para>On the inbound side, everything coming in that is part + of an existing session conversation is being automatically + handled by the check-state rule and the properly placed + divert natd rules. All we have to address is denying all the + bad packets and only allowing in the authorized services. + Lets say there is a apache server running on the firewall + box and we want people on the public Internet to be able to + access the local web site. The new inbound start request + packet matches rule 100 and its IP address is mapped to LAN + IP for the firewall box. The packet is them matched against + all the nasty things we want to check for and finally + matches against rule 425. On a match two things occur, the + limit option is an extension to keep-state. The packet rule + is posted to the keep-state dynamic table but this time any + new session requests originating from that source IP address + is limited to 2. This defends against DoS attacks of service + running on the specified port number. The action is allow so + the packet is released to the LAN. On return the check-state + rule recognizes the packet as belonging to an existing + session conversation sends it to rule 500 for <acronym>NAT</acronym>ing and + released to outbound interface.</para> + + <para>Example Ruleset #1:</para> + + <programlisting>#!/bin/sh +cmd="ipfw -q add" +skip="skipto 500" +pif=rl0 +ks="keep-state" +good_tcpo="22,25,37,43,53,80,443,110,119" + +ipfw -q -f flush + +$cmd 002 allow all from any to any via xl0 # exclude Lan traffic +$cmd 003 allow all from any to any via lo0 # exclude loopback traffic + +$cmd 100 divert natd ip from any to any in via $pif +$cmd 101 check-state + +# Authorized outbound packets +$cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks +$cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks +$cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks +$cmd 130 $skip icmp from any to any out via $pif $ks +$cmd 135 $skip udp from any to any 123 out via $pif $ks + + +# Deny all inbound traffic from non-routable reserved address spaces +$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP +$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP +$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP +$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback +$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback +$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config +$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs +$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster +$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast + +# Authorized inbound packets +$cmd 400 allow udp from xx.70.207.54 to any 68 in $ks +$cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 + + +$cmd 450 deny log ip from any to any + +# This is skipto location for outbound stateful rules +$cmd 500 divert natd ip from any to any out via $pif +$cmd 510 allow ip from any to any + +######################## end of rules ################## + </programlisting> + <para>The following is pretty much the same as above but, uses + a self documenting coding style full of description comments + to help the inexperienced IPFW rule writer to better + understand what the rules are doing.</para> + + <para>Example Ruleset #2:</para> + + <programlisting> +#!/bin/sh +################ Start of IPFW rules file ############################### +# Flush out the list before we begin. +ipfw -q -f flush + +# Set rules command prefix +cmd="ipfw -q add" +skip="skipto 800" +pif="rl0" # public interface name of Nic card + # facing the public Internet + +################################################################# +# No restrictions on Inside Lan Interface for private network +# Change xl0 to your Lan Nic card interface name +################################################################# +$cmd 005 allow all from any to any via xl0 + +################################################################# +# No restrictions on Loopback Interface +################################################################# +$cmd 010 allow all from any to any via lo0 + +################################################################# +# check if packet is inbound and nat address if it is +################################################################# +$cmd 014 divert natd ip from any to any in via $pif + +################################################################# +# Allow the packet through if it has previous been added to the +# the "dynamic" rules table by a allow keep-state statement. +################################################################# +$cmd 015 check-state + +################################################################# +# Interface facing Public Internet (Outbound Section) +# Interrogate session start requests originating from behind the +# firewall on the private network or from this gateway server +# destine for the public Internet. +################################################################# + +# Allow out access to my ISP's Domain name server. +# x.x.x.x must be the IP address of your ISP's DNS +# Dup these lines if your ISP has more than one DNS server +# Get the IP addresses from /etc/resolv.conf file +$cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state + + +# Allow out access to my ISP's DHCP server for cable/DSL configurations. +$cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state + +# Allow out non-secure standard www function +$cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state + +# Allow out secure www function https over TLS SSL +$cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state + +# Allow out send & get email function +$cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state +$cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state + +# Allow out FreeBSD (make install & CVSUP) functions +# Basically give user root "GOD" privileges. +$cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root + +# Allow out ping +$cmd 080 $skip icmp from any to any out via $pif keep-state + +# Allow out Time +$cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state + +# Allow out nntp news (i.e. news groups) +$cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state + +# Allow out secure FTP, Telnet, and SCP +# This function is using SSH (secure shell) +$cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state + +# Allow out whois +$cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state + +# Allow ntp time server +$cmd 130 $skip udp from any to any 123 out via $pif keep-state + +################################################################# +# Interface facing Public Internet (Inbound Section) +# Interrogate packets originating from the public Internet +# destine for this gateway server or the private network. +################################################################# + +# Deny all inbound traffic from non-routable reserved address spaces +$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP +$cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP +$cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP +$cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback +$cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback +$cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto-config +$cmd 306 deny all from 192.0.2.0/24 to any in via $pif #reserved for docs +$cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster +$cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast + +# Deny ident +$cmd 315 deny tcp from any to any 113 in via $pif + +# Deny all Netbios service. 137=name, 138=datagram, 139=session +# Netbios is MS/Windows sharing services. +# Block MS/Windows hosts2 name server requests 81 +$cmd 320 deny tcp from any to any 137 in via $pif +$cmd 321 deny tcp from any to any 138 in via $pif +$cmd 322 deny tcp from any to any 139 in via $pif +$cmd 323 deny tcp from any to any 81 in via $pif + +# Deny any late arriving packets +$cmd 330 deny all from any to any frag in via $pif + +# Deny ACK packets that did not match the dynamic rule table +$cmd 332 deny tcp from any to any established in via $pif + +# Allow traffic in from ISP's DHCP server. This rule must contain +# the IP address of your ISP's DHCP server as it's the only +# authorized source to send this packet type. +# Only necessary for cable or DSL configurations. +# This rule is not needed for 'user ppp' type connection to +# the public Internet. This is the same IP address you captured +# and used in the outbound section. +$cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state + +# Allow in standard www function because I have apache server +$cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2 + +# Allow in secure FTP, Telnet, and SCP from public Internet +$cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2 + +# Allow in non-secure Telnet session from public Internet +# labeled non-secure because ID & PW are passed over public +# Internet as clear text. +# Delete this sample group if you do not have telnet server enabled. +$cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2 + +# Reject & Log all unauthorized incoming connections from the public Internet +$cmd 400 deny log all from any to any in via $pif + +# Reject & Log all unauthorized out going connections to the public Internet +$cmd 450 deny log all from any to any out via $pif + +# This is skipto location for outbound stateful rules +$cmd 800 divert natd ip from any to any out via $pif +$cmd 801 allow ip from any to any + +# Everything else is denied by default +# deny and log all packets that fell through to see what they are +$cmd 999 deny log all from any to any +################ End of IPFW rules file ###############################</programlisting> + + </sect4> + </sect3> </sect2> </sect1> @@ -3988,7 +5853,7 @@ An optional company name []:<userinput><replaceable>Another Name</replaceable></ certificate itself, <filename>new.crt</filename>. These should be placed in a directory, preferably under <filename role="directory">/etc</filename>, which is readable - only by <username>root</username>. Permissions of 0600 should be fine for this and + only by <username>root</username>. Permissions of 0700 should be fine for this and they can be set with the <command>chmod</command> utility.</para> </sect2> @@ -4236,7 +6101,7 @@ options IPSEC_DEBUG #debug for IP security <para>If you find that you are trying to connect two networks, both of which, internally, use the same private IP address range - (e.g., both of them use <hostid + (e.g. both of them use <hostid role="ipaddr">192.168.1.x</hostid>), then one of the networks will have to be renumbered.</para> @@ -4380,7 +6245,7 @@ Network #2 [ Internal Hosts ] addresses.</para> <para>Support for the gif device must be compiled in to the - FreeBSD kernel on both machines. You can do this by adding the + &os; kernel on both machines. You can do this by adding the line:</para> <programlisting>pseudo-device gif</programlisting> @@ -4816,7 +6681,7 @@ ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; </programlisting> - <para>Put these commands in a file (e.g., + <para>Put these commands in a file (e.g. <filename>/etc/ipsec.conf</filename>) and then run</para> <screen>&prompt.root; <userinput>setkey -f /etc/ipsec.conf</userinput></screen> @@ -5138,9 +7003,9 @@ COPYRIGHT 100% |*****************************| 4735 <secondary>configuration</secondary> </indexterm> - <para>The system-wide configuration files for both the <application>OpenSSH</application> - daemon and client reside within the <filename>/etc/ssh</filename> - directory.</para> + <para>The system-wide configuration files for both the + <application>OpenSSH</application> daemon and client reside + within the <filename>/etc/ssh</filename> directory.</para> <para><filename>ssh_config</filename> configures the client settings, while <filename>sshd_config</filename> configures the @@ -5290,8 +7155,8 @@ Your identification has been saved in /home/user/.ssh/identity. of the remote machine. Since <replaceable>23</replaceable> is <application>telnet</application>, this would create a secure <application>telnet</application> session through an SSH tunnel.</para> - <para>This can be used to wrap any number of insecure TCP protocols - such as SMTP, POP3, FTP, etc.</para> + <para>This can be used to wrap any number of insecure TCP + protocols such as SMTP, POP3, FTP, etc.</para> <example> <title>Using SSH to Create a Secure Tunnel for SMTP</title> diff --git a/en_US.ISO8859-1/books/porters-handbook/book.sgml b/en_US.ISO8859-1/books/porters-handbook/book.sgml index 75ee6a7c71..13013c4ba4 100644 --- a/en_US.ISO8859-1/books/porters-handbook/book.sgml +++ b/en_US.ISO8859-1/books/porters-handbook/book.sgml @@ -5025,9 +5025,9 @@ ${PREFIX}/man/ja/man4/baz.4.gz</programlisting> <para> This script will be run twice by &man.pkg.delete.1;. - The first time as <literal>${SH} pkg-install ${PKGNAME} + The first time as <literal>${SH} pkg-deinstall ${PKGNAME} DEINSTALL</literal> and the second time as - <literal>${SH} pkg-install ${PKGNAME} POST-DEINSTALL</literal>. + <literal>${SH} pkg-deinstall ${PKGNAME} POST-DEINSTALL</literal>. </para> </sect1> @@ -7373,6 +7373,10 @@ Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-00 <entry>502128</entry> </row> <row> + <entry>5.3-RELEASE</entry> + <entry>503000</entry> + </row> + <row> <entry>6.0-CURRENT</entry> <entry>600000</entry> </row> @@ -7407,6 +7411,12 @@ Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-00 </entry> <entry>600005</entry> </row> + <row> + <entry>6.0-CURRENT after addition of glibc style + &man.strftime.3; padding options. + </entry> + <entry>600006</entry> + </row> </tbody> </tgroup> </table> @@ -7804,6 +7814,7 @@ courier:*:465: qtss:*:554: ircdru:*:555: messagebus:*:556: +realtime:*:557: bopm:*:717:</programlisting> <para>Please include a notice when you submit a port (or an upgrade) diff --git a/en_US.ISO8859-1/share/sgml/authors.ent b/en_US.ISO8859-1/share/sgml/authors.ent index 604f55f077..39a9c4e15e 100644 --- a/en_US.ISO8859-1/share/sgml/authors.ent +++ b/en_US.ISO8859-1/share/sgml/authors.ent @@ -28,6 +28,8 @@ <!ENTITY a.adrian "Adrian Chadd <email>adrian@FreeBSD.org</email>"> +<!ENTITY a.ahze "Michael Johnson <email>ahze@FreeBSD.org</email>"> + <!ENTITY a.akiyama "Shunsuke Akiyama <email>akiyama@FreeBSD.org</email>"> <!ENTITY a.alane "Alan Eldridge <email>alane@FreeBSD.org</email>"> @@ -282,6 +284,8 @@ <!ENTITY a.glewis "Greg Lewis <email>glewis@FreeBSD.org</email>"> +<!ENTITY a.gnn "George V. Neville-Neil <email>gnn@FreeBSD.org</email>"> + <!ENTITY a.gordon "Gordon Tetlow <email>gordon@FreeBSD.org</email>"> <!ENTITY a.gpalmer "Gary Palmer <email>gpalmer@FreeBSD.org</email>"> @@ -676,6 +680,8 @@ <!ENTITY a.reg "Jeremy Lea <email>reg@FreeBSD.org</email>"> +<!ENTITY a.remko "Remko Lodder <email>remko@FreeBSD.org</email>"> + <!ENTITY a.rgrimes "Rodney Grimes <email>rgrimes@FreeBSD.org</email>"> <!ENTITY a.ricardag "Ricardo AG <email>ricardag@FreeBSD.org</email>"> diff --git a/en_US.ISO8859-1/share/sgml/mailing-lists.ent b/en_US.ISO8859-1/share/sgml/mailing-lists.ent index 5c670031d7..a3622377bd 100644 --- a/en_US.ISO8859-1/share/sgml/mailing-lists.ent +++ b/en_US.ISO8859-1/share/sgml/mailing-lists.ent @@ -367,6 +367,10 @@ <!ENTITY a.tokenring "<ulink url='&a.tokenring.url;'>FreeBSD tokenring mailing list</ulink>"> <!ENTITY a.tokenring.name "<ulink url='&a.tokenring.url;'>freebsd-tokenring</ulink>"> +<!ENTITY a.usb.url "&a.mailman.listinfo;/freebsd-usb"> +<!ENTITY a.usb "<ulink url='&a.usb.url;'>FreeBSD USB mailing list</ulink>"> +<!ENTITY a.usb.name "<ulink url='&a.usb.url;'>freebsd-usb</ulink>"> + <!ENTITY a.usergroups.url "&a.mailman.listinfo;/freebsd-user-groups"> <!ENTITY a.usergroups "<ulink url='&a.usergroups.url;'>FreeBSD user group coordination mailing list</ulink>"> <!ENTITY a.usergroups.name "<ulink url='&a.usergroups.url;'>freebsd-user-groups</ulink>"> diff --git a/fr_FR.ISO8859-1/books/handbook/bibliography/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/bibliography/chapter.sgml index 5f868ba291..be6000221c 100644 --- a/fr_FR.ISO8859-1/books/handbook/bibliography/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/bibliography/chapter.sgml @@ -3,7 +3,7 @@ The FreeBSD French Documentation Project $FreeBSD$ - Original revision: 1.64 + Original revision: 1.69 --> <appendix id="bibliography"> @@ -27,7 +27,51 @@ <itemizedlist> <listitem> <para><ulink - url="http://jdli.tw.FreeBSD.org/publication/book/freebsd2/index.htm">Utiliser FreeBSD</ulink> (en Chinois).</para> + url="http://jdli.tw.FreeBSD.org/publication/book/freebsd2/index.htm">Utiliser FreeBSD</ulink> (en Chinois).</para> + </listitem> + + <listitem> + + <para>FreeBSD Unleashed (traduction Chinoise), publié par + <ulink url="http://www.hzbook.com/">China Machine + Press</ulink>. ISBN 7-111-10201-0. + </para> + </listitem> + + <listitem> + <para>FreeBSD From Scratch First Edition (en Chinois), + publié par China Machine Press. ISBN 7-111-07482-3. + </para> + </listitem> + + <listitem> + <para>FreeBSD From Scratch Second Edition (en Chinois), + publié par China Machine Press. ISBN 7-111-10286-X. + </para> + </listitem> + + <listitem> + <para>Manuel FreeBSD (traduction Chinoise), publié par + <ulink url="http://www.ptpress.com.cn/">Posts & Telecom + Press</ulink>. ISBN 7-115-10541-3. + </para> + </listitem> + + <listitem> + + <para>FreeBSD 3.x Internet (en Chinois), publié par + <ulink url="http://www.tup.tsinghua.edu.cn/">Tsinghua + University Press</ulink>. ISBN 7-900625-66-6.</para> + </listitem> + + <listitem> + <para>FreeBSD & Windows (en Chinois), ISBN + 7-113-03845-X</para> + </listitem> + + <listitem> + <para>FreeBSD Internet Services HOWTO (en Chinois), ISBN + 7-113-03423-3</para> </listitem> <listitem> @@ -200,7 +244,7 @@ formats HTML et PostScript.</para> <para>Une <ulink - url="../../../it_IT.ISO8859-15/books/unix-introduction/index.html">version</ulink> + url="&url.doc.base;/it_IT.ISO8859-15/books/unix-introduction/index.html">version</ulink> en Italien de ce document fait partie du projet de documentation &os; Italien.</para> </listitem> @@ -392,13 +436,20 @@ Addison-Wesley, 1996. ISBN 0-201-54979-4</para> <para>(Le chapitre 2 de ce livre est disponible <ulink - url="../design-44bsd/book.html">en ligne</ulink> en tant que + url="&url.books.design-44bsd;/book.html">en ligne</ulink> en tant que partie du Projet de Documentation de FreeBSD, et le chapitre 9 <ulink url="http://www.netapp.com/tech_library/nfsbook.print"> ici</ulink>.)</para> </listitem> <listitem> + <para>Marshall Kirk McKusick, George V. Neville-Neil + <emphasis>The Design and Implementation of the FreeBSD + Operating System</emphasis>. Boston, Mass. : Addison-Wesley, + 2004. ISBN 0-201-70245-2</para> + </listitem> + + <listitem> <para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume 1: The Protocols</emphasis>. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9</para> diff --git a/fr_FR.ISO8859-1/books/handbook/config/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/config/chapter.sgml index 6c0a35e9e3..92ec40718e 100644 --- a/fr_FR.ISO8859-1/books/handbook/config/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/config/chapter.sgml @@ -3,7 +3,7 @@ The FreeBSD French Documentation Project $FreeBSD$ - Original revision: 1.91 + Original revision: 1.189 --> <chapter id="config-tuning"> @@ -94,13 +94,12 @@ <itemizedlist> <listitem> - <para>Comprendre les fondements d'Unix et de FreeBSD (<xref + <para>Comprendre les fondements d'&unix; et de FreeBSD (<xref linkend="basics">).</para> </listitem> <listitem> - <para>Etre familier avec la mise à jour des sources - (<xref linkend="cutting-edge">), et - les bases de la configuration et la compilation du noyau + <para>Etre familier avec la configuration et la compilation du + noyau (<xref linkend="kernelconfig">).</para> </listitem> </itemizedlist> @@ -112,7 +111,7 @@ <sect2> <title>Organisation des partitions</title> - <indexterm><primary>Organisation des partitions</primary></indexterm> + <indexterm><primary>organisation des partitions</primary></indexterm> <indexterm> <primary><filename>/etc</filename></primary> </indexterm> @@ -144,37 +143,26 @@ <para>La taille de votre partition <filename>/var</filename> reflète l'utilisation prévue de votre machine. <filename>/var</filename> est principalement utilisée pour - héberger les boîtes aux lettres, les fichiers de traces, + héberger les boîtes aux lettres, les fichiers journaux, les queues d'impression. Les boîtes aux lettres et les fichiers - de traces, en particulier, peuvent croître dans des tailles + journaux, en particulier, peuvent croître vers des tailles inattendues en fonction du nombre d'utilisateurs de votre - système et de combien de temps sont conservés les - fichiers de traces. Si vous avez l'intention de faire fonctionner un + système et de combien de temps sont conservés ces + fichiers. Si vous avez l'intention de faire fonctionner un serveur de courrier électronique, une partition - <filename>/var</filename> de plus d'un gigaoctet pourra - convenir. De plus, <filename>/var/tmp</filename> doit être + La plupart des utilisateurs n'auront jamais besoin de plus d'un + gigaoctet, mais rappelez-vous que + <filename>/var/tmp</filename> doit être assez grand pour contenir tout logiciel pré-compilé que vous pourrez vouloir ajouter.</para> <para>La partition <filename>/usr</filename> contient la - majeure partie des fichiers nécessaires au système - et un sous-répertoire appelé - <filename>/usr/local</filename> - qui lui héberge la plupart des fichiers installés - par le catalogue des logiciels portés. Si vous n'employez - pas vraiment les logiciels portés et que vous n'avez pas - l'intention de conserver les sources du système sur - la machine (<filename>/usr/src</filename>), vous pouvez - utiliser une partition <filename>/usr</filename> d'un - gigaoctet. Cependant, si vous installez beaucoup de - logiciels portés (tout particulièrement des - gestionnaires de fenêtres et des binaires Linux), nous - recommandons au moins un <filename>/usr</filename> de deux - gigaoctets et si vous avez également l'intention d'avoir les - sources du système sur la machine nous recommandons un - <filename>/usr</filename> de trois gigaoctets. Ne - sous-estimez pas la quantité d'espace dont vous aurez besoin - sur cette partition, vous risquez d'être surpris!</para> + majeure partie des fichiers nécessaires au système, + le catalogue des logiciels portés (recommandé) + et le code source du système (optionnel). Les deux + étant optionnels à l'installation. Utiliser + au moins 2 gigaoctets pour cette partition est + recommandé.</para> <para>Quand vous dimensionnez vos partitions, gardez à l'esprit les besoins en espace pour permettre à votre @@ -189,7 +177,6 @@ <filename>/var</filename> étaient trop petites. Partitionnez généreusement et avec sagesse.</para></note> - </sect3> <sect3 id="swap-design"> @@ -389,51 +376,95 @@ -rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf -rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default</literallayout> - <para>La différence de taille des fichiers indique que seul le + <para>Les tailles des fichiers indiquent que seul le fichier <filename>srm.conf</filename> a été modifié. Une mise à - jour, plus tard, du logiciel apache ne devrait pas écraser le + jour, plus tard, du logiciel <application>Apache</application> ne devrait pas écraser le fichier modifié.</para> </sect1> <sect1 id="configtuning-starting-services"> + <sect1info> + <authorgroup> + <author> + <firstname>Tom</firstname> + <surname>Rhodes</surname> + <contrib>Contribution de </contrib> + </author> + </authorgroup> + </sect1info> + <title>Démarrer des services</title> <indexterm><primary>services</primary></indexterm> - <para>Il est assez courant qu'un système héberge - un certain nombre de services. Ces derniers peuvent être - démarrés de différentes façons, chacune - ayant différents avantages.</para> - - <indexterm><primary>/usr/local/etc/rc.d</primary></indexterm> - - <para>Un logiciel installé à partir du catalogue - des logiciels portés ou depuis une version - pré-compilée placera souvent une procédure dans - <filename>/usr/local/etc/rc.d</filename> qui sera invoquée - au démarrage du système avec un argument - <option>start</option>, et à l'arrêt du - système avec l'argument <option>stop</option>. C'est la - méthode recommandée pour démarrer des services - sur le système qui doivent fonctionner avec les privilèges - de <username>root</username>, ou s'attendent à fonctionner - avec ces privilèges. Ces procédures font partie - de l'installation du logiciel, et seront effacées quand le - logiciel sera désinstallé.</para> - - <para>Une procédure générique de démarrage dans - <filename>/usr/local/etc/rc.d</filename> ressemble à:</para> + <para>Nombreux sont les utilisateurs qui choisissent d'installer + des logiciels tierce partie sous &os; à partir du + catalogue des logiciels portés. Dans de nombreuses + situations, il peut être nécessaire de configurer + le logiciel de manière à ce qu'il soit + lancé au démarrage du système. Des + services comme <filename role="package">mail/postfix</filename> + ou <filename role="package">www/apache13</filename> sont deux + exemples de logiciels parmi tant d'autres qui peuvent être + lancés à l'initialisation du système. + Cette section explique les procédures disponibles pour + démarrer certains logiciels tierce partie.</para> + + <para>Sous &os;, la plupart des services offerts, comme + &man.cron.8;, sont lancés par l'intermédiaire des + procédures de démarrage du système. Ces + procédures peuvent varier en fonction de la version de + &os,; ou du fournisseur; cependant, l'aspect le plus important + à considérer est que leur configuration de + démarrage peut être gérée à + l'aide de procédures de démarrage simples.</para> + + <para>Avant l'avènement du système rcNG, les + applications plaçaient une procédure simple de + lancement dans le répertoire <filename + role="directory">/usr/local/etc/rc.d</filename> qui était + lue par les scripts d'initialisation du système. Ces + procédures étant alors exécutées + lors des dernières étapes du démarrage du + système.</para> + + <para>Bien que de nombreuses personnes aient passé des + heures à tenter de fusionner l'ancien mode de + configuration avec le nouveau, il reste que certains utilitaires + tierce partie ont toujours besoin d'un script placé dans + le répertoire précédemment + évoqué. Les différences subtiles dans les + scripts dépend de si le système rcNG est + utilisé ou non. Avant &os; 5.1 l'ancien style de + configuration était utilisé et dans presque tous + les cas la nouvelle procédure fonctionnera sans + problème.</para> + + <para>Bien que chaque procédure doit remplir certains + pré-requis minimum, la plupart du temps ils seront + indépendants de la version de &os;. Chaque + procédure doit avoir une extension + <filename>.sh</filename> et doit être exécutable + par le système. Ce dernier point peut être + réalisé en utilisant la commande + <command>chmod</command> et en fixant les permissions à + <literal>755</literal>. Il doit y avoir, au minimum, une option + pour démarrer (<literal>start</literal>) l'application et + une autre pour l'arrêter (<literal>stop</literal>).</para> + + <para>La procédure de démarrage la plus simple + ressemblera à celle-ci:</para> <programlisting>#!/bin/sh -echo -n ' FooBar' +echo -n ' utility' case "$1" in start) - /usr/local/bin/foobar + /usr/local/bin/utility ;; stop) - kill -9 `cat /var/run/foobar.pid` + kill -9 `cat /var/run/utility.pid` ;; *) echo "Usage: `basename $0` {start|stop}" >&2 @@ -441,72 +472,136 @@ stop) ;; esac -exit 0 - </programlisting> - - <para>Les procédures de démarrage de FreeBSD rechercheront - dans <filename>/usr/local/etc/rc.d</filename> les procédures - qui ont une extension <literal>.sh</literal> et qui sont - exécutables par <username>root</username>. Les - procédures trouvées seront lancées avec une - option <option>start</option> au démarrage, et - <option>stop</option> à l'arrêt pour leur permettre de - faire ce qu'elles ont à faire. Donc si vous aviez voulu que la - procédure précédente soit - exécutée au moment voulu pendant le démarrage - du système, vous auriez dû la sauver dans un fichier - appelé <filename>FooBar.sh</filename> dans le répertoire - <filename>/usr/local/etc/rc.d</filename> et en vérifiant qu'elle - soit exécutable. Vous pouvez rendre une procédure - d'interpréteur de commandes exécutable avec la commande - &man.chmod.1; comme montré ci-dessous:</para> - - <screen>&prompt.root; <userinput>chmod 755 <replaceable>FooBar.sh</replaceable></userinput></screen> - - <para>Certains services s'attendent à être invoqué - par &man.inetd.8; quand une demande de connexion est reçue - sur le bon port. Ceci est courant pour les serveurs de - récupération du courrier (POP et IMAP, etc...). - Ces services sont activés en éditant le fichier - <filename>/etc/inetd.conf</filename>. Voir la page de manuel - &man.inetd.8; pour plus de détails sur l'édition - de ce fichier.</para> - - <para>Certains services systèmes additionnels ne peuvent - pas être couverts par les options de - <filename>/etc/rc.conf</filename>. Ils sont traditionnellement - activés en plaçant la/les commande(s) pour les invoquer - dans le fichier <filename>/etc/rc.local</filename>. Depuis FreeBSD 3.1 - il n'y a plus de fichier <filename>/etc/rc.local</filename> par - défaut; s'il est créé par - l'administrateur il sera utilisé par le système de - façon habituelle. Notez que <filename>/etc/rc.local</filename> - est généralement vu comme l'emplacement de dernier recours; - s'il y a un meilleur emplacement pour démarrer un service, - utilisez-le.</para> - - <note><para>Ne placez <emphasis>aucune</emphasis> commande dans - <filename>/etc/rc.conf</filename>. Pour démarrer des - “daemons”, ou lancer tout autre commande au - démarrage, placez une procédure dans - <filename>/usr/local/etc/rc.d</filename> à la place.</para> - </note> +exit 0</programlisting> + + <para>Cette procédure offre des options + <literal>stop</literal> et <literal>start</literal> pour une + application appelée ici <literal>utility</literal>. + Cette application pourra alors avoir la ligne suivante la + concernant dans le fichier + <filename>/etc/rc.conf</filename>:</para> + + <programlisting>utility_enable="YES"</programlisting> + + <para>L'application pourra être lancée manuellement + avec:</para> + + <screen>&prompt.root; <userinput><filename>/usr/local/etc/rc.d/utility.sh</filename> start</userinput></screen> + + <para>Bien que toutes les applications tierce partie ne + nécessitent pas de ligne dans le fichier + <filename>rc.conf</filename>, chaque jour un nouveau logiciel + porté sera modifié pour accepter cette + configuration. Contrôlez l'affichage final lors de + l'installation de l'application pour plus d'information à + ce sujet. Certains logiciels fourniront des procédures + qui permettrons à l'application d'être + utilisée avec le système rcNG, cela sera + abordé dans la section suivante.</para> + + <sect2> + <title>Configuration étendue des applications</title> + + <para>Maintenant que &os; dispose du système rcNG, la + configuration du démarrage des applications est plus + aboutie, en effet elle propose plus de possibilités. + En utilisant les mots clés présentés dans + la section sur le système <link + linkend="configtuning-rcNG">rcNG</link>, les applications + peuvent désormais être paramétrées + pour démarrer après certains services, par + exemple le <acronym>DNS</acronym>, des paramètres + supplémentaires peuvent être passés par + l'intermédiaire de <filename>rc.conf</filename> au lieu + d'utiliser des paramètres fixes dans les + procédures de démarrage, etc. Une + procédure de base pourra ressembler à ce qui + suit:</para> + + <programlisting>#!/bin/sh +# +# PROVIDE: utility +# REQUIRE: DAEMON +# BEFORE: LOGIN +# KEYWORD: FreeBSD shutdown + +# +# DO NOT CHANGE THESE DEFAULT VALUES HERE +# SET THEM IN THE /etc/rc.conf FILE +# +utility_enable=${utility_enable-"NO"} +utility_flags=${utility_flags-""} +utility_pidfile=${utility_pidfile-"/var/run/utility.pid"} + +. /etc/rc.subr + +name="utility" +rcvar=`set_rcvar` +command="/usr/local/sbin/utility" + +load_rc_config $name + +pidfile="${utility_pidfile}" + +start_cmd="echo \"Starting ${name}.\"; /usr/bin/nice -5 ${command} ${utility_flags} ${command_args}" + +run_rc_command "$1"</programlisting> + + <para>Cette procédure s'assurera que l'application + <application>utility</application> sera lancée avant le + service <literal>login</literal> mais après le service + <literal>daemon</literal>. Elle fournie également une + méthode de suivi du <acronym>PID</acronym>, ou encore + <acronym>ID</acronym> (identifiant) de processus.</para> + + <para>Cette nouvelle méthode permet également une + manipulation plus aisée des arguments en ligne de + commande, l'inclusion des fonctions offertes par défaut + dans <filename>/etc/rc.subr</filename>, offre une + compatibilité avec l'utilitaire &man.rcorder.8; et + fournie une configuration plus aisée par + l'intermédiaire du fichier + <filename>rc.conf</filename>. Dans l'état actuel, + cette procédure pourrait même être + placée dans le répertoire <filename + role="directory">/etc/rc.d</filename>. Cependant, cela pourra + déranger l'utilitaire &man.mergemaster.8; lors de mise + à jour logicielles.</para> + </sect2> - <para>Il est également possible d'utiliser le “daemon” - &man.cron.8; pour démarrer des services système. Cette - approche présente un certain nombre d'avantages, et non des - moindres parce que &man.cron.8; exécute ces procédures - sous les privilèges du propriétaire de la table - <command>crontab</command>, les services pourront être - démarrés et maintenus par des utilisateurs - non-<username>root</username>.</para> - - <para>Cela peut utiliser avantageusement une des - caractéristiques de &man.cron.8;: la spécification - de la date d'exécution peut être remplacée - par <literal>@reboot</literal>, qui provoquera l'exécution - de la tâche quand &man.cron.8; est lancé, peu de temps - après le démarrage du système.</para> + <sect2> + <title>Utiliser des services pour démarrer d'autres + services</title> + + <para>Certains services, comme les serveurs + <acronym>POP</acronym>3, <acronym>IMAP</acronym>, etc., + peuvent être démarrés en utilisant + &man.inetd.8;. Cela implique d'installer le service à + partir du catalogue des logiciels portés et avec une + ligne de configuration ajoutée au fichier + <filename>/etc/inetd.conf</filename>, ou en + décommentant une des lignes de configuration + déjà présentes. L'utilisation + d'<application>inetd</application> et sa configuration sont + décrits en profondeur dans la section concernant <link + linkend="network-inetd">inetd</link>.</para> + + <para>Dans certains cas, il peut être plus + approprié d'utiliser le <quote>daemon</quote> + &man.cron.8; pour démarrer des services. Cette + approche présente un certain nombre d'avantages parce + que <command>cron</command> exécute ces processus sous + les privilèges du propriétaire de la table + <filename>crontab</filename>. Cela permet aux utilisateurs + normaux de lancer et maintenir certaines applications.</para> + + <para>L'utilitaire <command>cron</command> offre une fonction + unique, <literal>@reboot</literal>, qui peut être + utilisée en remplacement de la date d'exécution. + Cela provoquera l'exécution de la tâche quand + &man.cron.8; est lancé, normalement lors de + l'initialisation du système.</para> + </sect2> </sect1> <sect1 id="configtuning-cron"> @@ -539,8 +634,46 @@ exit 0 est censé exécuter à des moments donnés.</para> + <para>L'utilitaire <command>cron</command> utilise deux types + différents de fichiers de configuration, le fichier + <filename>crontab</filename> système et les + <filename>crontab</filename>s des utilisateurs. La seule + différence entre ces deux formats est le sixième + champ. Dans le fichier <filename>crontab</filename> + système, le sixième champ est le nom de + l'utilisateur sous lequel doit être exécutée + la commande. Cela donne la possibilité au fichier + <filename>crontab</filename> système d'exécuter les + commandes sous n'importe quel utilisateur. Dans le fichier + <filename>crontab</filename> d'un utilisateur, le sixième + champ est la commande a exécuter et toutes les commandes + sont exécutées sous l'utilisateur qui a + créé le fichier <filename>crontab</filename>; c'est + un aspect sécurité important.</para> + + <note> + <para>Les fichiers <filename>crontab</filename> utilisateur + permettent aux utilisateurs de planifier l'exécution de + tâches sans avoir besoin des privilèges du + super-utilisateur <username>root</username>. Les commandes + contenues dans le fichier <filename>crontab</filename> d'un + utilisateur s'exécutent avec les privilèges de + l'utilisateur auquel appartient ce fichier.</para> + + <para>Le super-utilisateur <username>root</username> peut + posséder un fichier <filename>crontab</filename> + utilisateur comme tout autre utilisateur. Ce fichier est + différent de <filename>/etc/crontab</filename> (le + <filename>crontab</filename> système). En raison de + l'existence du fichier <filename>crontab</filename> + système, il n'y a généralement pas besoin + d'un fichier <filename>crontab</filename> utilisateur pour + <username>root</username>.</para> + </note> + <para>Examinons le fichier - <filename>/etc/crontab</filename>:</para> + <filename>/etc/crontab</filename> (fichier + <filename>crontab</filename> système):</para> <programlisting># /etc/crontab - root's crontab for &os; @@ -655,12 +788,31 @@ HOME=/var/log <sect2 id="configtuning-installcrontab"> <title>Installer un fichier crontab</title> + <important> + <para>Vous ne devez pas utiliser la procédure + décrite ci-dessous pour éditer/installer le + fichier <filename>crontab</filename> système. Utilisez + directement votre éditeur: l'utilitaire + <command>cron</command> remarquera le changement au niveau de ce + fichier et utilisera immédiatement la nouvelle version. + Consultez <ulink + url="&url.books.faq;/admin.html#ROOT-NOT-FOUND-CRON-ERRORS">cette + entrée de la FAQ</ulink> pour plus d'information.</para> + </important> + <para>Pour installer un fichier <filename>crontab</filename> - fraichement rédigé, utilisez simplement + utilisateur fraichement rédigé, tout d'abord + utilisez votre éditeur favori pour créer un + fichier dans le bon format, ensuite utilisez l'utilitaire <command>crontab</command>. L'usage le plus typique est:</para> - <screen>&prompt.root; <userinput>crontab crontab</userinput></screen> + <screen>&prompt.root; <userinput>crontab fichier-crontab</userinput></screen> + + <para>Dans cet exemple, <filename>fichier-crontab</filename> est + le nom d'un fichier <filename>crontab</filename> qui a + été précédemment + créé.</para> <para>Il existe également une option pour afficher les fichiers <filename>crontab</filename> installés, passez @@ -675,6 +827,11 @@ HOME=/var/log avec un fichier vide. Quand le fichier est sauvegardé, il sera automatiquement installé par la commande <command>crontab</command>.</para> + + <para>Si vous désirez plus tard effacer votre + <filename>crontab</filename> utilisateur complètement, + utilisez la commande <command>crontab</command> avec l'option + <option>-r</option>.</para> </sect2> </sect1> @@ -863,7 +1020,7 @@ sshd is running as pid 433.</screen> <title>Configuration des cartes réseaux</title> - <indexterm><primary>Configuration des cartes réseaux</primary></indexterm> + <indexterm><primary>configuration des cartes réseaux</primary></indexterm> <para>De nos jours il est impossible de penser à un ordinateur sans penser connexion à un réseau. Installer et configurer @@ -875,8 +1032,8 @@ sshd is running as pid 433.</screen> périphérique</title> <indexterm> - <primary>Configuration des cartes réseaux</primary> - <secondary>Déterminer le pilote de + <primary>configuration des cartes réseaux</primary> + <secondary>déterminer le pilote de périphérique</secondary> </indexterm> @@ -945,7 +1102,7 @@ ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto</screen> <title>Configuration de la carte réseau</title> <indexterm> - <primary>Configuration des cartes réseaux</primary> + <primary>configuration des cartes réseaux</primary> <secondary>configuration</secondary> </indexterm> @@ -1148,8 +1305,8 @@ ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP"</programlis <title>Tester la carte Ethernet</title> <indexterm> - <primary>Configuration des cartes réseaux</primary> - <secondary>Test de la carte</secondary> + <primary>configuration des cartes réseaux</primary> + <secondary>test de la carte</secondary> </indexterm> <para>Pour vérifier qu'une carte Ethernet est @@ -1196,121 +1353,83 @@ round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms</screen> <title>Dépannage</title> <indexterm> - <primary>Configuration des cartes réseaux</primary> - <secondary>Dépannage</secondary> + <primary>configuration des cartes réseaux</primary> + <secondary>dépannage</secondary> </indexterm> - <qandaset> - <qandaentry> - <question> - <para>Où puis-je trouver de l'information au sujet des - possibles problèmes que je peux rencontrer avec ma - carte réseau.</para> - </question> - - <answer> - <para>La page de manuel du pilote de périphérique - est la première documentation à lire. Les archives - des listes de diffusion peuvent également - être utiles.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Quand j'essaye un “ping” vers une - machine du réseau, j'obtiens le message suivant: - <errorname>ping: sendto: Permission denied</errorname>.</para> - </question> - - <answer> - <para>Cela signifie que vous n'avez pas la permission - d'envoyer des paquets ICMP. Contrôlez si un coupe-feu - tourne sur la machine et s'il y a des règles bloquant - l'ICMP.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Je vois beaucoup de messages - <errorname>watchdog timeout</errorname> dans les - fichiers de trace du système, et quand je tente un - “ping” vers une autre machine sur le - réseau local, j'obtiens ce message: - <errorname>ping: sendto: No route to host</errorname>.</para> - </question> - - <answer> - <para>La première chose à contrôler - est votre câble réseau. De nombreuses cartes - réseaux demandent un slot PCI supportant - le “Bus Mastering”. Sur certaines cartes - mères anciennes, seul un slot PCI le permet (la - plupart du temps le slot 0). Consultez la - documentation de la carte réseau et de la carte mère - pour déterminer si cela peut être à - l'origine du problème.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Je vois beaucoup de messages - <errorname>device timeout</errorname> dans les - fichiers de trace du système, et ma carte réseau - ne fonctionne pas.</para> - </question> - - <answer> - <para>Avoir un ou deux de ces messages est parfois - normal avec certaines cartes. Cependant s'ils - persistent et que le réseau n'est pas utilisable, - assurez-vous que le câble réseau est - branché et qu'il n'y a aucun conflit d'IRQ entre la - carte réseau et un autre périphérique (ou - périphériques) sur le système.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Les performances de la carte sont mauvaises, que - puis-je faire?</para> - </question> - - <answer> - <para>Il est difficile de répondre à cette - question. Quelle est votre définition de - “mauvaises performances”? Revérifiez - l'ensemble de votre configuration, lisez la page - de manuel &man.tuning.7;, et essayez d'éviter les - cartes réseaux bon marché. De nombreux utilisateurs - ont remarqué que positionner la sélection du média - dans le mode <literal>autoselect</literal> peut - être à l'origine de mauvaises performances sur - certains matériels.</para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para>Y-a-t-il des cartes réseaux recommandées ou des - cartes que je devrais éviter?</para> - </question> - - <answer> - <para>Vous devriez éviter les cartes bon marché pour une - utilisation sérieuse. Les cartes bon marché utilisent - souvent des circuits bogués, et la plupart du temps ne - peuvent fournir de bonnes performances. De nombreux - utilisateurs de FreeBSD apprécient les cartes - utilisant le circuit &man.fxp.4;, cependant, cela ne - veut pas dire que les autres circuits sont - mauvais.</para> - </answer> - </qandaentry> - </qandaset> + <para>Le dépannage de matériels ou de logiciels + est toujours une tâche relativement pénible, mais + qui peut être rendue plus aisée en + vérifiant en premier lieu certaines choses + élémentaires. Votre câble réseau + est-il branché? Avez-vous correctement + configuré les services réseau? Le coupe-feu + est-il bien configuré? Est-ce que la carte + réseau est supportée par &os;? Consultez + toujours les notes concernant le matériel avant + d'envoyer un rapport de bogue. Mettez à jour votre + version de &os; vers la dernière version STABLE. + Consultez les archives des listes de diffusion, et faites + même des recherches sur l'Internet.</para> + + <para>Si la carte fonctionne mais les performances sont + mauvaises, une lecture de la page de manuel &man.tuning.7; + peut valoir la peine. Vous pouvez également + vérifier la configuration du réseau puisque des + paramétres réseau incorrects peuvent donner lieu + à des connexions lentes.</para> + + <para>Certains utilisateurs peuvent voir apparaître un ou + deux messages <errorname>device timeout</errorname>, ce qui + est normal pour certaines cartes. Si ces messages se + multiplient, assurez-vous que la carte n'est pas en conflit + avec un autre périphérique. Contrôlez + à deux fois les câbles de connexion. + Peut-être que vous avez juste besoin d'une autre + carte.</para> + + <para>Parfois, des utilisateurs sont confrontés à + des messages d'erreur <errorname>watchdog timeout</errorname>. + La première chose à faire dans ce cas est de + vérifier votre câble réseau. De + nombreuses cartes demandent un slot PCI supportant le + <quote>Bus Mastering</quote>. Sur certaines cartes + mère anciennes, seul un slot PCI le permet (la plupart + du temps le slot 0). Consultez la documentation de la carte + réseau et de la carte mère pour + déterminer si cela peut être à l'origine + du problème.</para> + + <para>Les messages <errorname>No route to host</errorname> + surviennent si le système est incapable de router un + paquet vers la machine de destination. Cela peut arriver s'il + n'y a pas de route par défaut de définie, ou si + le câble réseau est débranché. + Vérifiez la sortie de la commande <command>netstat + -nr</command> et assurez-vous qu'il y a une route valide en + direction de la machine que vous essayez d'atteindre. Si ce + n'est pas le cas, lisez la <xref + linkend="advanced-networking">.</para> + + <para>Les messages d'erreur <errorname>ping: sendto: Permission + denied</errorname> sont souvent dus à un coupe-feu mal + configuré. Si <command>ipfw</command> est + activé dans le noyau mais qu'aucune règle n'a + été définie, alors la politique par + défaut est de refuser tout trafic, même les + requêtes <quote>ping</quote>! Lisez <xref + linkend="firewalls"> pour plus d'informations.</para> + + <para>Parfois les performances de la carte ne sont pas bonnes, + ou en dessous de la moyenne. Dans ce cas il est + recommandé de passer la sélection du + média du mode <literal>autoselect</literal> au mode + adéquat. Alors que cela fonctionne + généralement pour la plupart du matériel, + il se peut que cela ne résolve pas le problème + pour tout de monde. Encore une fois, contrôlez les + paramétrages réseau et consultez la page de + manuel &man.tuning.7;.</para> </sect3> </sect2> </sect1> @@ -1349,7 +1468,9 @@ round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms</screen> avoir une adresse qui représente correctement le masque de réseau de votre réseau. Tout autre adresse appartenant à ce réseau devra avoir un masque de réseau - avec chaque bit à <literal>1</literal>.</para> + avec chaque bit à <literal>1</literal> (exprimé soit + sous la forme <hostid role="netmask">255.255.255.255</hostid> + soit <hostid role="netmask">0xffffffff</hostid>).</para> <para>Par exemple, considérez le cas où l'interface <devicename>fxp0</devicename> est connectée à @@ -1358,7 +1479,18 @@ round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms</screen> <hostid role="netmask">255.255.255.0</hostid> et le réseau <hostid role="ipaddr">202.0.75.16</hostid> avec un masque de <hostid role="netmask">255.255.255.240</hostid>. Nous voulons que le système apparaisse de <hostid role="ipaddr">10.1.1.1</hostid> jusqu'à <hostid role="ipaddr">10.1.1.5</hostid> et à <hostid role="ipaddr">202.0.75.17</hostid> jusqu'à - <hostid role="ipaddr">202.0.75.20</hostid>.</para> + <hostid role="ipaddr">202.0.75.20</hostid>. Comme noté + plus haut, seule la première adresse dans un intervalle + réseau donné (dans ce cas, <hostid + role="ipaddr">10.0.1.1</hostid> et <hostid + role="ipaddr">202.0.75.17</hostid>) devrait avoir un masque de + sous-réseau réel; toutes les autres adresses + (<hostid role="ipaddr">10.1.1.2</hostid> à <hostid + role="ipaddr">10.1.1.5</hostid> et <hostid + role="ipaddr">202.0.75.18</hostid> jusqu'à <hostid + role="ipaddr">202.0.75.20</hostid>) doivent être + configurées avec un masque de sous-réseau de <hostid + role="netmask">255.255.255.255</hostid>.</para> <para>Les entrées suivantes configurent la carte correctement pour cet arrangement:</para> @@ -1386,6 +1518,9 @@ round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms</screen> <informaltable frame="none"> <tgroup cols="2"> + <colspec colwidth="1*"> + <colspec colwidth="2*"> + <tbody> <row> <entry><filename>/etc</filename></entry> @@ -1462,6 +1597,9 @@ round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms</screen> <informaltable frame="none"> <tgroup cols="2"> + <colspec colwidth="1*"> + <colspec colwidth="2*"> + <tbody> <row> <entry><literal>nameserver</literal></entry> @@ -1667,7 +1805,7 @@ cron.* /var/log/cron </sect3> </sect2> - <sect2> + <sect2 id="configtuning-sysctlconf"> <title><filename>sysctl.conf</filename></title> <indexterm><primary>sysctl.conf</primary></indexterm> @@ -1695,7 +1833,10 @@ compat.linux.osrelease=4.3-STABLE</programlisting> <title>Optimisation avec sysctl</title> <indexterm><primary>sysctl</primary></indexterm> - <indexterm><primary>optimisation avec sysctl</primary></indexterm> + <indexterm> + <primary>optimisation</primary> + <secondary>avec sysctl</secondary> + </indexterm> <para>&man.sysctl.8; est une interface qui vous permet d'effectuer des changements de paramétrage sur un système @@ -1734,6 +1875,12 @@ kern.maxfiles: 2088 -> 5000</screen> <literal>1</literal> pour oui ou un <literal>0</literal> pour non).</para> + <para>Si vous voulez fixer automatiquement certaines variables + à chaque démarrage de la machine, ajoutez-les au fichier + <filename>/etc/sysctl.conf</filename>. Pour plus d'information + consultez la page de manuel &man.sysctl.conf.5; et la + <xref linkend="configtuning-sysctlconf">.</para> + <sect2 id="sysctl-readonly"> <sect2info> <authorgroup> @@ -1802,10 +1949,10 @@ device_probe_and_attach: cbb0 attach returned 12</screen> La plupart des répertoires sont petits, utilisant juste un simple fragment du système de fichiers (typiquement 1KO) et moins dans le cache en mémoire (typiquement 512 octets). - Cependant, quand on fonctionne dans le mode par défaut le + Avec cette variable désactivée (à 0), le cache en mémoire ne cachera qu'un nombre fixe de répertoires même si vous disposez d'une grande - quantité de mémoire. Activer cette variable sysctl + quantité de mémoire. Activée (à 1), cette variable sysctl permet au cache en mémoire d'utiliser le cache des pages de mémoire virtuelle pour cacher les répertoires, rendant toute la mémoire disponible pour cacher les @@ -1813,12 +1960,12 @@ device_probe_and_attach: cbb0 attach returned 12</screen> l'élément mémoire utilisé pour cacher un répertoire est une page physique (typiquement 4KO) plutôt que 512 octets. - Nous recommandons l'activation de cette option si + Nous recommandons de conserver de cette option activée si vous faites fonctionner des services qui manipulent un grand nombre de fichiers. De tels services peuvent être des caches web, d'importants systèmes de courrier électronique, et des systèmes serveurs de groupe - de discussion. Activer cette option ne réduira + de discussion. Conserver cette option activée ne réduira généralement pas les performances même avec la mémoire gaspillée mais vous devriez faire des expériences pour le déterminer.</para> @@ -2029,7 +2176,10 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <title>Plus de détails à propos des “Soft Updates”</title> - <indexterm><primary>Soft Updates (Détails)</primary></indexterm> + <indexterm> + <primary>Soft Updates</primary> + <secondary>détails</secondary> + </indexterm> <para>Il y a deux approches traditionnelles pour écrire les méta-données d'un système de fichiers sur le @@ -2237,9 +2387,12 @@ device_probe_and_attach: cbb0 attach returned 12</screen> </sect1> <sect1 id="configtuning-kernel-limits"> - <title>Paramétrer les limitations du noyau</title> + <title>Optimisation des limitations du noyau</title> - <indexterm><primary>Paramétrer les limitations du noyau</primary></indexterm> + <indexterm> + <primary>Optimisation</primary> + <secondary>limitations du noyau</secondary> + </indexterm> <sect2 id="file-process-limits"> <title>Limitations sur les fichiers et les processus</title> @@ -2520,10 +2673,8 @@ device_probe_and_attach: cbb0 attach returned 12</screen> bien sûr, est d'utiliser ceci comme excuse pour ajouter un autre disque dur. Vous pouvez toujours utiliser un autre disque après tout. Si vous pouvez faire cela, allez relire la - discussion sur <ulink - url="configtuning-initial.html#SWAP-DESIGN">l'espace de - pagination</ulink> dans la section <ulink - url="configtuning-initial.html">Configuration initiale</ulink> + discussion sur l'espace de pagination dans la <xref + linkend="configtuning-initial"> du Manuel pour des suggestions sur la meilleure façon d'arranger votre espace de pagination.</para> </sect2> @@ -2662,23 +2813,23 @@ device_probe_and_attach: cbb0 attach returned 12</screen> </authorgroup> </sect1info> - <title>ACPI et FreeBSD</title> + <title>Gestion de l'énergie et des ressources</title> <para>Il est vraiment important d'utiliser les ressources matérielles d'une manière efficace. Avant l'apparition de l'<acronym>ACPI</acronym>, il était très difficile pour les systèmes d'exploitation de gérer l'utilisation de l'alimentation et la température - d'un système. Le matériel était soit + d'un système. Le matériel était contrôlé par certaines interfaces du - <acronym>BIOS</acronym>, i.e.: le système + <acronym>BIOS</acronym>, comme le système <emphasis>Plug and Play BIOS (PNPBIOS)</emphasis>, l'<emphasis>Advanced Power Management (APM)</emphasis> et ainsi de suite. La gestion de l'énergie et des ressources est un des éléments clés d'un système d'exploitation moderne. Par exemple, vous pourrez vouloir qu'un système d'exploitation surveille certaines limites (et - prenne eventuellement des mesures), au cas où la + eventuellement vous alerte), au cas où la température de votre système augmente de façon inattendue.</para> @@ -2687,14 +2838,19 @@ device_probe_and_attach: cbb0 attach returned 12</screen> fait référence à des documents supplémentaires en fin de section pour plus de détails. Soyez conscient que l'<acronym>ACPI</acronym> - n'est disponible que sur les systèmes FreeBSD 5.X et - suivants.</para> + est disponible sur les systèmes FreeBSD 5.X et + suivants par défaut sous la forme d'un module noyau. + Sous &os; 4.9, l'<acronym>ACPI</acronym> peut être + activé en ajoutant la ligne <literal>device + acpica</literal> à la configuration du noyau et en le + recompilant.</para> <sect2 id="acpi-intro"> <title>Qu'est-ce que l'ACPI?</title> - <para>L'“Advanced Configuration and Power Interface” - (<acronym>ACPI</acronym>) est une norme créée + <para>L'<quote>interface de configuration et d'alimentation + avancée</quote> (<acronym>ACPI</acronym>, Advanced + Configuration and Power Interface) est une norme créée par un ensemble de constructeurs pour fournir une interface standard à la gestion des ressources et de l'énergie. C'est un élément clé dans le contrôle @@ -2709,9 +2865,59 @@ device_probe_and_attach: cbb0 attach returned 12</screen> l'<acronym>APM</acronym> (Advanced Power Management - gestion avancée de l'énergie).</para> + <sect2 id="acpi-old-spec"> + <title>Les imperfections de la gestion avancée de + l'énergie (APM)</title> + + <para>Le système de <emphasis>gestion avancée de + l'énergie (APM)</emphasis> gère l'utilisation de + l'énergie par un système en fonction de son + activité. Le BIOS APM est fourni par le fabricant (du + système) et est spécifique à la plateforme + matérielle. Un pilote APM au niveau du système + d'exploitation gère l'accès à + l'<emphasis>interface logicielle APM</emphasis> qui autorise la + gestion des niveaux de consommation.</para> + + <para>L'APM présente quatre problèmes majeurs. Tout + d'abord la gestion de l'énergie est effectuée par le + BIOS (spécifique au constructeur), et le système + d'exploitation n'en a aucune connaissance. Un exemple de ce + problème, est lorsque l'utilisateur fixe des valeurs pour + le temps d'inactivité d'un disque dur dans le BIOS APM, qui + une fois dépassé, provoque l'arrêt du disque + (par le BIOS) sans le consentement du système + d'exploitation. Deuxièmement, la logique de l'APM est + interne au BIOS, et agit indépendamment du système + d'exploitation. Cela signifie que les utilisateurs ne peuvent + corriger les problèmes de leur BIOS APM qu'en flashant un + nouveau BIOS; c'est une opération dangereuse, qui si elle + échoue peut laisser le système dans un état + irrécupérable. Troisièment, l'APM est une + technologie spécifique au constructeur, ce qui veut dire + qu'il y a beaucoup de redondances (duplication des efforts) et de + bogues qui peuvent être trouvées dans le BIOS d'un + constructeur, et qui peuvent ne pas être corrigées + dans d'autres BIOS. Et pour terminer, le dernier problème + est le fait que le BIOS APM n'a pas suffisament d'espace pour + implémenter une politique sophistiquée de gestion de + l'énergie, ou une politique qui peut s'adapter parfaitement + aux besoins de la machine.</para> + + <para>Le <emphasis>BIOS Plug and Play (PNPBIOS)</emphasis> + n'était pas fiable dans de nombreuses situations. Le + PNPBIOS est une technologie 16 bits, le système + d'exploitation doit utiliser une émulation 16 bits afin de + faire l'<quote>interface</quote> avec les méthodes + PNPBIOS.</para> + + <para>Le pilote <acronym>APM</acronym> &os; est documenté + dans la page de manuel &man.apm.4;.</para> + </sect2> + <sect2 id="acpi-config"> <title>Configurer l'<acronym>ACPI</acronym></title> - + <para>Le pilote <filename>acpi.ko</filename> est par défaut chargé par le &man.loader.8; au démarrage et ne devrait <emphasis>pas</emphasis> être compilé dans @@ -2756,16 +2962,669 @@ device_probe_and_attach: cbb0 attach returned 12</screen> <para>D'autres options sont disponibles. Consultez la page de manuel d'&man.acpiconf.8; pour plus d'informations.</para> </sect2> + </sect1> - <sect2 id="acpi-debug"> - <title>Déboguage de l'<acronym>ACPI</acronym></title> + <sect1 id="ACPI-debug"> + <sect1info> + <authorgroup> + <author> + <firstname>Nate</firstname> + <surname>Lawson</surname> + <contrib>Ecrit par </contrib> + </author> + </authorgroup> + <authorgroup> + <author> + <firstname>Peter</firstname> + <surname>Schultz</surname> + <contrib>Avec la collaboration de </contrib> + </author> + <author> + <firstname>Tom</firstname> + <surname>Rhodes</surname> + </author> + </authorgroup> + </sect1info> + + <title>Utiliser et déboguer l'<acronym>ACPI</acronym> + sous &os;</title> + + <para>L'<acronym>ACPI</acronym> est une nouvelle méthode de + recherche des périphériques, de gestion de + l'énergie, et fourni un accès standardisé + à différents matériels gérés + auparavant par le <acronym>BIOS</acronym>. Des progrès ont + été fait vers un fonctionnement de + l'<acronym>ACPI</acronym> sur tous les systèmes, mais des + bogues dans le <quote>bytecode</quote> du <firstterm>langage machine + <acronym>ACPI</acronym></firstterm> + (<firstterm><acronym>ACPI</acronym> Machine + Language</firstterm>—<acronym>AML</acronym>), des + imperfections dans les sous-systèmes du noyau &os;, et des + bogues dans l'interpréteur <acronym>ACPI-CA</acronym> + d'&intel; continuent d'apparaître.</para> + + <para>Ce document est destiné à vous permettre d'aider + les développeurs du système <acronym>ACPI</acronym> + sous &os; à identifier la cause originelle des + problèmes que vous observez et à déboguer et + développer une solution. Merci de lire ce document et nous + espérons pouvoir résoudre les problèmes de + votre système.</para> + + <sect2 id="ACPI-submitdebug"> + <title>Soumettre des informations de débogage</title> - <para>Presque tout dans l'<acronym>ACPI</acronym> est transparent, - jusqu'au moment où cela ne fonctionne plus. C'est en - général à ce moment où vous en tant - qu'utilisateur saurez que quelque chose ne fonctionne pas - correctement.</para> + <note> + <para>Avant de soumettre un problème, assurez-vous + d'utiliser la dernière version de votre + <acronym>BIOS</acronym>, et si elle est disponible, la + dernière version du firmware du contrôleur + utilisé.</para> + </note> + <para>Pour ceux désirant soumettre directement un + problème, veuillez faire parvenir les informations + suivantes à la liste <ulink + url="mailto:freebsd-acpi@FreeBSD.org">freebsd-acpi@FreeBSD.org</ulink>:</para> + + <itemizedlist> + <listitem> + <para>Description du comportement défectueux, en + ajoutant le type et le modèle du système et tout + ce qui peut causer l'apparition du bogue. Notez + également le plus précisément possible + quand le bogue a commencé à se manisfester s'il + est nouveau.</para> + </listitem> + + <listitem> + <para>La sortie de &man.dmesg.8; après un <command>boot + -v</command>, y compris tout message + généré lors de la manifestation du + bogue.</para> + </listitem> + + <listitem> + <para>La sortie de &man.dmesg.8; après un <command>boot + -v</command> avec + l'<acronym>ACPI</acronym> désactivé, si cette + désactivation corrige le problème.</para> + </listitem> + + <listitem> + <para>La sortie de <command>sysctl hw.acpi</command>. C'est + également un bon moyen de déterminer quelles + fonctionnalités sont offertes par votre + système.</para> + </listitem> + + <listitem> + <para>Une <acronym>URL</acronym> où peut être + trouvé votre <firstterm>code source + <acronym>ACPI</acronym></firstterm> (<acronym>ACPI</acronym> + Source Language—<acronym>ASL</acronym>). N'envoyez pas + directement l'<acronym>ASL</acronym> sur la liste de + diffusion, ce fichier peut être très gros. Vous + pouvez générer une copie de votre + <acronym>ASL</acronym> en exécutant la commande + suivante:</para> + + <screen>&prompt.root; <userinput>acpidump -t -d > <replaceable>name</replaceable>-<replaceable>system</replaceable>.asl</userinput></screen> + + <para>(Remplacez <replaceable>name</replaceable> par votre + nom d'utilisateur et <replaceable>system</replaceable> par + celui du constructeur/modèle. Par exemple: + <filename>njl-FooCo6000.asl</filename>)</para> + </listitem> + </itemizedlist> + + <para>La plupart des développeurs lisent la liste + &a.current; mais soumettez également les problèmes + rencontrés à la liste &a.acpi.name; afin + d'être sûr qu'ils seront vus. Soyez patient, nous + avons tous un travail à plein temps qui nous attend + ailleurs. Si votre bogue n'est pas immédiatement apparent, + nous vous demanderons probablement de soumettre un + <acronym>PR</acronym> par l'intermédiaire de + &man.send-pr.1;. Quand vous remplirez un <acronym>PR</acronym>, + veillez à inclure les mêmes informations que celles + précisées précedemment. Cela nous aidera + à cerner et à résoudre le problème. + N'envoyez pas de <acronym>PR</acronym> sans avoir contacté + auparavant la liste &a.acpi.name; étant donné que + nous utilisons les <acronym>PR</acronym>s comme pense-bêtes + de problèmes existants, et non pas comme mécanisme + de rapport. Il se peut que votre problème puisse avoir + déjà été signalé par quelqu'un + d'autre.</para> + </sect2> + + <sect2 id="ACPI-background"> + <title>Information de fond</title> + + <para>L'<acronym>ACPI</acronym> est présent sur tous les + ordinateurs modernes compatibles avec l'une des architectures ia32 + (x86), ia64 (Itanium), et amd64 (AMD). La norme complète + définit des fonctionnalités comme la gestion des + performances du <acronym>CPU</acronym>, des contrôles des + niveaux d'énergie, des zones de températures, divers + systèmes d'utilisation des batteries, des contrôleurs + intégrés, et l'énumération du bus. La + plupart des systèmes n'implémentent pas + l'intégralité des fonctionnalités de la + norme. Par exemple, un ordinateur de bureau n'implémentera + généralement que la partie énumération + de bus alors qu'un ordinateur portable aura également le + support de la gestion du refroidissement et de la batterie. Les + ordinateurs portables disposent également des modes de mise + en veille et de réveil, avec toute la complexité qui + en découle.</para> + + <para>Un système compatible <acronym>ACPI</acronym> dispose + de divers composants. Les fabricants de <acronym>BIOS</acronym> + et de circuits fournissent des tables de description + (<acronym>FADT</acronym>) fixes en mémoire qui + définissent des choses comme la table + <acronym>APIC</acronym> (utilisée par les systèmes + <acronym>SMP</acronym>), les registres de configuration, et des + valeurs de configuration simples. De plus, est fournie une table + de <quote>bytecode</quote> (la <firstterm>table + différenciée de description du + système</firstterm>—<firstterm>Differentiated System + Description Table</firstterm> <acronym>DSDT</acronym>) qui + spécifie sous forme d'une arborescence l'espace des noms + des périphériques et des méthodes.</para> + + <para>Le pilote <acronym>ACPI</acronym> doit analyser les + tables, implémenter un interpréteur pour le + <quote>bytecode</quote>, et modifier les pilotes de + périphériques et le noyau pour qu'ils + accèptent des informations en provenance du + sous-système <acronym>ACPI</acronym>. Pour &os;, &intel; + fourni un interpréteur (<acronym>ACPI-CA</acronym>) qui + est partagé avec Linux et NetBSD. L'emplacement du code + source de l'interpréteur <acronym>ACPI-CA</acronym> est + <filename + role="directory">src/sys/contrib/dev/acpica</filename>. Le code + <quote>glu</quote> permettant à + <acronym>ACPI-CA</acronym> de fonctionner sous &os; se trouve + dans <filename>src/sys/dev/acpica/Osd</filename>. Et enfin, les + pilotes qui gèrent les différents + périphériques <acronym>ACPI</acronym> se trouvent + dans <filename + role="directory">src/sys/dev/acpica</filename>.</para> + </sect2> + + <sect2 id="ACPI-comprob"> + <title>Problèmes courants</title> + + <para>Pour un fonctionnement correct de + l'<acronym>ACPI</acronym>, il faut que toutes les parties + fonctionnent correctement. Voici quelques problèmes + courants, par ordre de fréquence d'apparition, et + quelques contournements ou corrections possibles.</para> + + <sect3> + <title>Mise en veille/réveil</title> + + <para>L'<acronym>ACPI</acronym> dispose de trois modes + de mise en veille en <acronym>RAM</acronym> + (<acronym>STR</acronym>—Suspend To RAM), + <literal>S1</literal> à <literal>S3</literal>, et un + mode de mise en veille vers le disque dur + (<literal>STD</literal>—Suspend To Disk), appelé + <literal>S4</literal>. Le mode <literal>S5</literal> est un + arrêt <quote>soft</quote> et est le mode dans lequel se + trouve votre système quand il est branché mais + pas allumé. Le mode <literal>S4</literal> peut + être implémenté de deux manières + différentes. Le mode + <literal>S4</literal><acronym>BIOS</acronym> est une mise en + veille vers le disque assistée par le + <acronym>BIOS</acronym>. Le mode + <literal>S4</literal><acronym>OS</acronym> est + implémenté intégralement par le + système d'exploitation.</para> + + <para>Commencez par examiner la sortie de + <command>sysctl hw.acpi</command> à la recherche + d'éléments concernant les modes de mise en + veille. Voici les résultats pour un Thinkpad:</para> + + <screen>hw.acpi.supported_sleep_state: S3 S4 S5 +hw.acpi.s4bios: 0</screen> + + <para>Cela signifie que nous pouvons utiliser + <command>acpiconf -s</command> pour tester les modes + <literal>S3</literal>, + <literal>S4</literal><acronym>OS</acronym>, et + <literal>S5</literal>. Si <option>s4bios</option> + était égal à <literal>1</literal>, nous + disposerions d'un support + <literal>S4</literal><acronym>BIOS</acronym> à la place + de <literal>S4</literal><acronym>OS</acronym>.</para> + + <para>Quand vous testez la mise en veille et le réveil, + commencez avec le mode <literal>S1</literal>, pour voir s'il + est supporté. Ce mode doit fonctionner dans la plupart + des cas puisqu'il nécessite peu de support. Le mode + <literal>S2</literal> n'est pas implémenté, mais + si vous en disposez, il est similaire au mode + <literal>S1</literal>. La chose suivante à essayer est + le mode <literal>S3</literal>. C'est le mode + <acronym>STR</acronym> le plus avancé et il + nécessite un support du pilote important pour + réinitialiser correctement votre matériel. Si + vous avez des problèmes au réveil de la machine, + n'hésitez pas à contacter la liste &a.acpi.name; + mais ne vous attendez pas à ce que le problème + soit résolu puisqu'il y a de nombreux + pilotes/matériels qui nécessitent plus de tests + et de développement.</para> + + <para>Pour isoler le problème, retirez du noyau tous les + pilotes de périphériques possibles. Si cela + fonctionne, vous pouvez alors identifier le pilote fautif en + chargeant les pilotes un à un jusqu'à + l'apparition du problème. Généralement + les pilotes binaires comme <filename>nvidia.ko</filename>, les + pilotes d'affichage X11, ou les pilotes USB seront victimes de + la plupart des problèmes tandis que ceux concernant les + interfaces Ethernet fonctionneront normalement. Si vous + pouvez charger/décharger les pilotes de + périphériques correctement, vous pouvez + automatiser cela en ajoutant les commandes appropriées + dans les fichiers <filename>/etc/rc.suspend</filename> et + <filename>/etc/rc.resume</filename>. Il y a un exemple en + commentaire pour décharger ou charger un pilote. + Essayez de fixer <option>hw.acpi.reset_video</option> à + zéro (<literal>0</literal>) si votre affichage est + corrompu après un réveil de la machine. Essayez + des valeurs plus grandes ou plus faibles pour + <option>hw.acpi.sleep_delay</option> pour voir si cela + aide.</para> + + <para>Une autre méthode est d'essayer de charger une + distribution Linux récente avec le support + <acronym>ACPI</acronym> et tester la mise en veille et le + réveil sur le même matériel. Si cela + fonctionne sous Linux, c'est probablement donc un + problème de pilotes &os; et déterminer quel + pilote est responsable des disfonctionnements nous aidera + à corriger le problème. Notez que les personnes + qui maintiennent l'<acronym>ACPI</acronym> sous &os; ne + s'occupe pas généralement des autres pilotes de + périphériques (comme le son, le système + <acronym>ATA</acronym>, etc.), aussi tout rapport concernant + un problème de pilote devrait probablement en fin de + compte être posté sur la liste &a.current.name; + et communiqué au responsable du pilote. Si vous vous + sentez une âme d'aventurier, commencez à ajouter + des &man.printf.3;s de débogage dans un pilote + problématique pour déterminer à quel + moment dans sa fonction de réveil il se bloque.</para> + + <para>Enfin, essayez de désactiver + l'<acronym>ACPI</acronym> et d'activer l'<acronym>APM</acronym> + à la place, pour voir si la mise en veille et le + réveil fonctionnent avec l'<acronym>APM</acronym>, tout + particulièrement dans le cas de matériel ancien + (antérieur à 2000). Cela prend du temps aux + constructeurs de mettre en place le support + <acronym>ACPI</acronym> et le matériel ancien aura + sûrement des problèmes de <acronym>BIOS</acronym> + avec l'<acronym>ACPI</acronym>.</para> + </sect3> + + <sect3> + <title>Blocages du système (temporaires ou permanents)</title> + + <para>La plupart des blocages système sont le + résultat d'une perte d'interruptions ou d'une + tempête d'interruptions. Les circuits ont beaucoup de + problèmes en fonction de la manière dont le + <acronym>BIOS</acronym> configure les interruptions avant le + démarrage, l'exactitude de la table + <acronym>APIC</acronym> (<acronym>MADT</acronym>), et le routage + du <firstterm>System Control Interrupt</firstterm> + (<acronym>SCI</acronym>).</para> + + <para>Les tempêtes d'interruptions peuvent être + distinguées des pertes d'interruptions en + contrôlant la sortie de la commande <command>vmstat + -i</command> en examinant la ligne mentionnant + <literal>acpi0</literal>. Si le compteur s'incrémente + plusieurs fois par seconde, vous êtes victime d'une + tempête d'interruptions. Si le système semble + bloqué, essayez de basculer sous <acronym>DDB</acronym> + (<keycombo action="simul"><keycap>CTRL</keycap> + <keycap>ALT</keycap><keycap>ESC</keycap></keycombo> sous la + console) et tapez <literal>show interrupts</literal>.</para> + + <para>Votre plus grand espoir quand vous faites face à + des problèmes d'interruptions est d'essayer de + désactiver le support <acronym>APIC</acronym> avec la + ligne <literal>hint.apic.0.disabled="1"</literal> dans le + fichier <filename>loader.conf</filename>.</para> + </sect3> + + <sect3> + <title>Paniques</title> + + <para>Les paniques sont relativement rares dans le cas de + l'<acronym>ACPI</acronym> et sont au sommet des + priorités en matière de problèmes + à corriger. Le premier point est d'isoler les + étapes nécessaires à la reproduction de + la panique (si possible) et d'obtenir une trace de + débogage. Suivez l'aide sur l'activation de + <literal>options DDB</literal> et la configuration d'une + console série (lire la <xref + linkend="serialconsole-ddb">) ou la configuration d'une + partition &man.dump.8;. Vous pouvez obtenir une trace de + débogage sous <acronym>DDB</acronym> avec la commande + <literal>tr</literal>. Si vous devez recopier à la + main la trace de débogage, assurez-vous de relever les + cinq dernières lignes et les cinq premières + ligne de la trace.</para> + + <para>Ensuite essayez d'isoler le problème en + démarrant avec l'<acronym>ACPI</acronym> + désactivé. Si cela fonctionne, vous pouvez isoler + le sous-système <acronym>ACPI</acronym> en utilisant + différentes valeurs pour l'option + <option>debug.acpi.disable</option>. Consultez la page de + manuel &man.acpi.4; pour des exemples.</para> + </sect3> + + <sect3> + <title>Le système redémarre après une mise + en veille ou un arrêt</title> + + <para>Tout d'abord, essayez de fixer + <literal>hw.acpi.disable_on_poweroff="0"</literal> dans + &man.loader.conf.5;. Cela empêche + l'<acronym>ACPI</acronym> de désactiver divers + événements lors du processus d'arrêt. + Certains systèmes ont besoin d'avoir cette valeur + fixée à <literal>1</literal> (valeur par + défaut) pour la même raison. Cela corrige + généralement le problème d'un + système démarrant spontanément + après une mise en veille ou un arrêt.</para> + </sect3> + + <sect3> + <title>Autres problèmes</title> + + <para>Si vous rencontrez d'autres problèmes avec + l'<acronym>ACPI</acronym> (impossible de travailler avec une + station d'amarrage, périphériques non + détectés, etc.), veuillez envoyer un courrier + descriptif à la liste de diffusion; cependant, certains + de ces problèmes peuvent être relatifs à + des partie incomplètes du sous-système + <acronym>ACPI</acronym> et qui pourront prendre du temps + à être implémentées. Soyez patient + et prêt à tester les correctifs que nous pourront + éventuellement vous envoyer.</para> + </sect3> + </sect2> + + <sect2 id="ACPI-aslanddump"> + <title><acronym>ASL</acronym>, <command>acpidump</command>, et + <acronym>IASL</acronym></title> + + <para>Le problème le plus courant est le fait que les + constructeurs fournissent des <quote>bytecodes</quote> + erronés (ou plus simplement bogués!). Cela se + manifeste généralement sur la console par des + messages du noyau du type:</para> + + <screen>ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ +(Node 0xc3f6d160), AE_NOT_FOUND</screen> + + <para>La plupart du temps vous pouvez corriger ces problèmes en + mettant à jour votre <acronym>BIOS</acronym> avec la + dernière version disponible. La majorité des + messages sur la console sont innofensifs mais si vous avez + d'autres problèmes comme l'état de la batterie qui + ne fonctionne pas, ce sont de bonnes raisons pour commencer + à jeter un oeil à ces problèmes dans + l'<acronym>AML</acronym>. Le <quote>bytecode</quote>, connu + sous le nom d'<acronym>AML</acronym>, est compilé + à partir d'un langage source appelé + <acronym>ASL</acronym>. L'<acronym>AML</acronym> se trouve dans + une table appelée <acronym>DSDT</acronym>. Pour obtenir + une copie de votre <acronym>ASL</acronym>, utilisez + &man.acpidump.8;. Vous devriez utiliser de paire les options + <option>-t</option> (qui affiche le contenu des tables fixes) et + <option>-d</option> (qui désassemble + l'<acronym>AML</acronym> en <acronym>ASL</acronym>). Consultez + la section <link linkend="ACPI-submitdebug">Soumettre des + informations de déboguage</link> pour un exemple de + syntaxe.</para> + + <para>Le tout premier test que vous pouvez effectuer est + de recompiler votre <acronym>ASL</acronym> à la recherche + d'erreurs. Les avertissements peuvent être + généralement ignorés mais les erreurs sont + des bogues qui normalement empêchent + l'<acronym>ACPI</acronym> de fonctionner correctement. Pour + recompiler votre <acronym>ASL</acronym>, utilisez la commande + suivante:</para> + + <screen>&prompt.root; <userinput>iasl your.asl</userinput></screen> + </sect2> + + <sect2 id="ACPI-fixasl"> + <title>Correction de votre <acronym>ASL</acronym></title> + + <para>A long terme, notre objectif est que tout le monde puisse + avoir un système <acronym>ACPI</acronym> fonctionnant + sans aucune intervention de l'utilisateur. Actuellement, nous + sommes toujours en train de développer des solutions pour + contourner les erreurs courantes faites par les fabricants de + <acronym>BIOS</acronym>. L'interpréteur de µsoft; + (<filename>acpi.sys</filename> et + <filename>acpiec.sys</filename>) ne contrôle pas de + façon stricte la conformité avec la norme, et par + conséquent de nombreux fabricants de + <acronym>BIOS</acronym> qui testent l'<acronym>ACPI</acronym> + uniquement sous &windows; ne corrigent donc jamais leur + <acronym>ASL</acronym>. Nous espérons poursuivre + à identifier et documenter avec exactitude les + comportements non-standards autorisés par + l'interpréteur de µsoft; et les reproduire de + manière à permettre à &os; de fonctionner + sans obliger les utilisateurs à corriger leur + <acronym>ASL</acronym>. Comme solution et pour nous aider + à identifier ces comportements, vous pouvez corriger + manuellement votre <acronym>ASL</acronym>. Si cela fonctionne + pour vous, veuillez nous envoyer un &man.diff.1; de l'ancien et + du nouveau <acronym>ASL</acronym> de façon à ce + que nous puissions corriger le comportement incorrect dans + <acronym>ACPI-CA</acronym> et rendre donc inutile à + l'avenir votre correctif.</para> + + <para>Voici une liste des messages d'erreur courants, leur cause, + et comment les corriger:</para> + + <sect3> + <title>Dépendances _OS</title> + + <para>Certains <acronym>AML</acronym>s supposent que le monde + n'est fait de que différentes versions de &windows;. + Vous pouvez demander à &os; de s'annoncer comme + étant n'importe quel système d'exploitation pour + voir si cela corrige les problèmes que vous pouvez + rencontrer. Une manière simple de faire cela est de + fixer la variable <literal>hw.acpi.osname="Windows + 2001"</literal> dans <filename>/boot/loader.conf</filename> ou + avec une autre chaîne de caractères que vous + trouvez dans l'<acronym>ASL</acronym>.</para> + </sect3> + + <sect3> + <title><errorname>Missing Return statements</errorname></title> + + <para>Certaines méthodes ne renvoient pas explicitement + une valeur comme la norme le demande. Bien + qu'<acronym>ACPI-CA</acronym> ne gère pas cela, &os; + contourne ce problème en renvoyant implicitement la + valeur. Vous pouvez également ajouter des <quote>Return + statements</quote> explicites où cela est + nécessaire si vous connaissez la valeur à + renvoyer. Pour forcer <command>iasl</command> à compiler + l'<acronym>ASL</acronym>, utilisez l'option + <option>-f</option>.</para> + </sect3> + + <sect3> + <title>Remplacer l'<acronym>AML</acronym> par + défaut</title> + + <para>Après avoir personnalisé + <filename>votre.asl</filename>, vous voudrez le compiler, pour + cela exécutez:</para> + + <screen>&prompt.root; <userinput>iasl your.asl</userinput></screen> + + <para>Vous pouvez ajouter l'option <option>-f</option> pour + forcer la création de l'<acronym>AML</acronym>, + même s'il y a des erreurs lors de la compilation. + Rappelez-vous que certaines erreurs (e.g., <errorname>missing + Return statements</errorname>) sont automatiquement + contournées par l'interpréteur.</para> + + <para><filename>DSDT.aml</filename> est le fichier de sortie par + défaut pour <command>iasl</command>. Vous pouvez le + charger à la place de la version boguée de votre + <acronym>BIOS</acronym> (qui est toujours présent dans la + mémoire flash) en éditant le fichier + <filename>/boot/loader.conf</filename> comme suit:</para> + + <programlisting>acpi_dsdt_load="YES" +acpi_dsdt_name="/boot/DSDT.aml"</programlisting> + + <para>Assurez-vous de bien copier votre fichier + <filename>DSDT.aml</filename> dans le répertoire + <filename role="directory">/boot</filename>.</para> + </sect3> + </sect2> + + <sect2 id="ACPI-debugoutput"> + <title>Obtenir d'<acronym>ACPI</acronym> une sortie de + débogage</title> + + <para>Le pilote <acronym>ACPI</acronym> dispose d'une fonction + de débogage très flexible. Elle vous permet de + spécifier un ensemble de sous-systèmes ainsi que + le niveau de verbosité. Les sous-systèmes que + vous désirez déboguer sont indiqués sous la + forme de <quote>couches</quote> et sont divisés en + composants <acronym>ACPI-CA</acronym> (ACPI_ALL_COMPONENTS) et + en supports matériel <acronym>ACPI</acronym> + (ACPI_ALL_DRIVERS). La verbosité de la sortie de + débogage est spécifiée par un + <quote>niveau</quote> et des intervalles de ACPI_LV_ERROR + (rapporte juste les erreurs) à ACPI_LV_VERBOSE (tout). + Le <quote>niveau</quote> est un masque de bits + séparés par des espaces, aussi de nombreuses + options peuvent être fixées à la fois. Dans + la pratique, vous voudrez utiliser un console série pour + afficher la sortie si les informations de débogage sont + si importantes qu'elles dépassent le tampon des messages + de la console. Une liste complète des couches + individuelles et des niveaux peut être trouvée dans + la page de manuel &man.acpi.4;.</para> + + <para>L'affichage des informations de débogage n'est pas + activé par défaut. Pour l'activer, ajoutez la ligne + <literal>options ACPI_DEBUG</literal> à votre fichier de + configuration du noyau si l'<acronym>ACPI</acronym> est + compilé dans le noayu. Vous pouvez ajouter la ligne + <literal>ACPI_DEBUG=1</literal> à votre fichier + <filename>/etc/make.conf</filename> pour l'activer de façon + globale. Si l'<acronym>ACPI</acronym> est sous forme de module, + vous pouvez recompiler votre module <filename>acpi.ko</filename> + comme suit:</para> + + <screen>&prompt.root; <userinput>cd /sys/modules/acpi/acpi +&& make clean && +make ACPI_DEBUG=1</userinput></screen> + + <para>Installez <filename>acpi.ko</filename> dans le + répertoire <filename + role="directory">/boot/kernel</filename> et indiquez le niveau et + la couche désirée dans + <filename>loader.conf</filename>. L'exemple suivant active les + messages de débogage pour tous les composants + <acronym>ACPI-CA</acronym> et tous les pilotes de matériel + <acronym>ACPI</acronym> (<acronym>CPU</acronym>, + <acronym>LID</acronym>, etc.). Il n'affichera que les messages + d'erreur, c'est le niveau le moins verbeux.</para> + + <programlisting>debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" +debug.acpi.level="ACPI_LV_ERROR"</programlisting> + + <para>Si l'information que vous voulez est + déclenchée par un évenement particulier + (disons par exemple une mise en veille suivi d'un réveil), + vous pouvez abandonner les modifications dans + <filename>loader.conf</filename> et utiliser à la place + <command>sysctl</command> pour indiquer la couche et le niveau + après le démarrage et préparer votre + système pour cet événement particulier. Les + variables <command>sysctl</command> sont appelées de la + même manière que dans le fichier + <filename>loader.conf</filename>.</para> + </sect2> + + <sect2 id="ACPI-References"> + <title>Références</title> + + <para>Plus d'information au sujet de l'<acronym>ACPI</acronym> + peut être trouvé aux emplacements suivants:</para> + + <itemizedlist> + <listitem> + <para>La liste de diffusion &a.acpi;</para> + </listitem> + + <listitem> + <para>Les archives de la liste de diffusion + <acronym>ACPI</acronym> <ulink + url="http://lists.freebsd.org/pipermail/freebsd-acpi/"></ulink></para> + </listitem> + + <listitem> + <para>Les archives de l'ancienne liste de diffusion + <acronym>ACPI</acronym> <ulink + url="http://home.jp.FreeBSD.org/mail-list/acpi-jp/"></ulink></para> + </listitem> + + <listitem> + <para>La spécification <acronym>ACPI</acronym> 2.0 + <ulink url="http://acpi.info/spec.htm"></ulink></para> + </listitem> + + <listitem> + <para>Les pages de manuel: &man.acpi.4;, + &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;, + &man.acpidb.8;</para> + </listitem> + + <listitem> + <para><ulink + url="http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt"> + Ressource sur le débogage de la + <acronym>DSDT</acronym></ulink>. (Utilise un exemple + basé sur du matériel Compaq mais qui est en + général intéressant.)</para> + </listitem> + </itemizedlist> </sect2> </sect1> </chapter> diff --git a/fr_FR.ISO8859-1/books/handbook/multimedia/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/multimedia/chapter.sgml index a7dbcaa071..d253c23e12 100644 --- a/fr_FR.ISO8859-1/books/handbook/multimedia/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/multimedia/chapter.sgml @@ -3,7 +3,7 @@ The FreeBSD French Documentation Project $FreeBSD$ - Original revision: 1.98 + Original revision: 1.100 --> <chapter id="multimedia"> @@ -239,7 +239,7 @@ pilote &man.snd.emu10k1.4;. Pour ajouter le support pour cette carte, utilisez ce qui suit:</para> - <programlisting>device snd_emu10k1</programlisting> + <programlisting>device "snd_emu10k1"</programlisting> <para>Assurez-vous de lire la page de manuel du pilote pour la syntaxe à utiliser. Des informations concernants la @@ -2086,7 +2086,29 @@ device `epson:/dev/uscanner0' is a Epson GT-8200 flatbed scanner</screen> <screen>&prompt.root; <userinput>pw groupmod operator -m <replaceable>joe</replaceable></userinput></screen> <para>Pour plus de détails, consultez la page de manuel - de &man.pw.8;.</para> + de &man.pw.8;. Vous devez également fixer les + permissions d'écriture correctes (0660 or 0664) sur le + fichier spécial de périphérique + <filename>/dev/uscanner0</filename>, par défaut le + groupe <groupname>operator</groupname> n'a qu'un accès + en lecture. Cela se fait en ajoutant les lignes suivantes au + fichier <filename>/etc/devfs.rules</filename>:</para> + + <programlisting>[system=5] +add path uscanner0 mode 660</programlisting> + + <para>Ajoutez ensuite ce qui suit au fichier + <filename>/etc/rc.conf</filename> et redémarrez la + machine:</para> + + <programlisting>devfs_system_ruleset="system"</programlisting> + + <para>Plus d'information concernant ces lignes peut être + trouvée dans la page de manuel &man.devfs.8;. Sous + &os; 4.X, le groupe <groupname>operator</groupname> + dipose, par défaut, des droits de lecture et + d'écriture sur + <filename>/dev/uscanner0</filename>.</para> <note> <para>Bien sûr, pour des raisons de diff --git a/fr_FR.ISO8859-1/books/handbook/pgpkeys/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/pgpkeys/chapter.sgml index c95498b6cf..3026871fd1 100644 --- a/fr_FR.ISO8859-1/books/handbook/pgpkeys/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/pgpkeys/chapter.sgml @@ -3,7 +3,7 @@ The FreeBSD French Documentation Project $FreeBSD$ - Original revision: 1.237 + Original revision: 1.247 --> <appendix id="pgpkeys"> <title>Clés PGP</title> @@ -190,6 +190,11 @@ &pgpkey.brooks; </sect2> + <sect2 id="pgpkey-gnn"> + <title>&a.gnn;</title> + &pgpkey.gnn; + </sect2> + <sect2 id="pgpkey-pjd"> <title>&a.pjd;</title> &pgpkey.pjd; @@ -200,6 +205,11 @@ &pgpkey.bsd; </sect2> < |