diff --git a/en_US.ISO8859-1/articles/contributing/article.sgml b/en_US.ISO8859-1/articles/contributing/article.sgml index e5c3c3be2e..c7db1f849b 100644 --- a/en_US.ISO8859-1/articles/contributing/article.sgml +++ b/en_US.ISO8859-1/articles/contributing/article.sgml @@ -1,6208 +1,6208 @@ Contributing to FreeBSD Contributed by &a.jkh;. So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth! Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our TODO list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project! Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is Needed The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers; Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs; Clean up and document the nullfs filesystem code. Coordinator: &a.eivind; Fix the union file system. Coordinator: &a.dg; Implement Int13 vm86 disk driver. Coordinator: &a.hackers; New bus architecture. Coordinator: &a.newbus; Port existing ISA drivers to new architecture. Move all interrupt-management code to appropriate parts of the bus drivers. Port PCI subsystem to new architecture. Coordinator: &a.dfr; Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented. Resolve the probe/attach priority issue once and for all. Move any remaining buses over to the new architecture. Kernel issues. Overall coordination: &a.hackers; Add more pro-active security infrastructure. Overall coordination: &a.security; Build something like Tripwire(TM) into the kernel, with a remote and local part. There are a number of cryptographic issues to getting this right; contact the coordinator for details. Coordinator: &a.eivind; Make the entire kernel use suser() instead of comparing to 0. It is presently using about half of each. Coordinator: &a.eivind; Split securelevels into different parts, to allow an administrator to throw away those privileges he can throw away. Setting the overall securelevel needs to have the same effect as now, obviously. Coordinator: &a.eivind; Make it possible to upload a list of allowed program to BPF, and then block BPF from accepting other programs. This would allow BPF to be used e.g. for DHCP, without allowing an attacker to start snooping the local network. Update the security checker script. We should at least grab all the checks from the other BSD derivatives, and add checks that a system with securelevel increased also have reasonable flags on the relevant parts. Coordinator: &a.eivind; Add authorization infrastructure to the kernel, to allow different authorization policies. Part of this could be done by modifying suser(). Coordinator: &a.eivind; Add code to the NFS layer so that you cannot chdir("..") out of an NFS partition. E.g., /usr is a UFS partition with /usr/src NFS exported. Now it is possible to use the NFS filehandle for /usr/src to get access to /usr. Medium priority tasks The following tasks need to be done, but not with any particular urgency: Full KLD based driver support/Configuration Manager. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.imp; Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.msmith; and &a.phk; APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks 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: The first N items are from Terry Lambert terry@lambert.org NetWare Server (protected mode ODI driver) loader and sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting internal v.s.. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Smaller tasks 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. If you run FreeBSD-current and have a good Internet connection, there is a machine current.FreeBSD.org which builds a full release once a day — every now and again, try and install the latest release from it and report any failures in the process. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions). Help translate FreeBSD documentation into your native language (if not already available) — just send an email to &a.doc; asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this — in fact, the documentation most in need of translation is the installation instructions. Read the freebsd-questions mailing list and &ng.misc occasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on. If you know of any bug fixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder. Move contributed software to src/contrib in the source tree. Make sure code in src/contrib is up to date. Look for year 2000 bugs (and fix any you find!) Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings. Fix warnings for ports which do deprecated things like using gets() or including malloc.h. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version) Suggest further tasks for this list! Work through the PR database The FreeBSD PR list shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users. Look through the open PRs, and see if anything there takes your interest. Some of these might be very simple tasks, that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one. Others might be much more complex. Start with the PRs that have not been assigned to anyone else, but if one them is assigned to someone else, but it looks like something you can handle, e-mail the person it is assigned to and ask if you can work on it—they might already have a patch ready to be tested, or further ideas that you can discuss with them. How to Contribute Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information about this and other mailing lists. If you find a bug or are submitting a specific change, please report it using the &man.send-pr.1; program or its WEB-based equivalent. Try to fill-in each field of the bug report. Unless they exceed 65KB, include any patches directly in the report. When including patches, do not use cut-and-paste because cut-and-paste turns tabs into spaces and makes them unusable. Consider compressing patches and using &man.uuencode.1; if they exceed 20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/. After filing a report, you should receive confirmation along with a tracking number. Keep this tracking number so that you can update us with details about the problem by sending mail to bug-followup@FreeBSD.org. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the &man.send-pr.1; command, then you may ask someone to file it for you by sending mail to the &a.bugs;. Changes to the documentation Changes to the documentation are overseen by the &a.doc;. Send submissions and changes (even small ones are welcome!) using send-pr as described in Bug Reports and General Commentary. Changes to existing source code 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 Staying current with FreeBSD for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce; and the &a.current; lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the &man.diff.1; command, with the context diff form being preferred. For example: &prompt.user; diff -c oldfile newfile or &prompt.user; diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for &man.diff.1; for more details. Once you have a set of diffs (which you may test with the &man.patch.1; command), you should submit them for inclusion with FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary. Do not just send the diffs to the &a.hackers; or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the pr database until we do. If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a tar file and run the &man.uuencode.1; program on it. Shar archives are also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, then you should send it to &a.core; directly rather than submitting it with &man.send-pr.1;. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code. New code or major value-added packages In the 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 uuencoded tar files or upload them to a web or FTP site for other people to access. If you do not have access to a web or FTP site, ask on an appropriate FreeBSD mailing list for someone to host the changes for you. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its no strings attached nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or GPL. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem. Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a BSD-style copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the %% with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. Money, Hardware or Internet access 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. <anchor id="donations">Donating funds 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. FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(currently using the BSDi address until a PO box can be opened) Wire transfers may also be sent directly to:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to &a.jkh, either via email or to the FreeBSD, Inc. postal address given above. If you do not wish to be listed in our donors section, please specify this when making your donation. Thanks! Donating hardware Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.dg; for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of new hardware. Donating Internet access We can always use new mirror sites for FTP, WWW or cvsup. If you would like to be such a mirror, please contact the FreeBSD project administrators hubs@FreeBSD.org for more information. Donors Gallery The FreeBSD Project is indebted to the following donors and would like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine to eventually replace freefall.FreeBSD.org by donating the following items: &a.mbarkah and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200Mhz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Blue Mountain Arts Epilogue Technology Corporation &a.sef Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier Chris Silva Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: BSDi for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB - fileservers, twelve Ethernets, two routers and an ATM switch for + file servers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. &a.chuck; contributed his floppy tape streamer for experimental work. Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-) Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD/. Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! Christoph Kukulies kuku@FreeBSD.org donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Special contributors: BSDi (formerly Walnut Creek CDROM) has donated almost more than we can say (see the history document for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting &a.joerg; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. Core Team Alumni 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. In rough chronological order: &a.ache (1993 - 2000) &a.jmb (1993 - 2000) &a.bde (1992 - 2000) &a.gibbs (1993 - 2000) &a.rich (1994 - 2000) &a.phk (1992 - 2000) &a.gpalmer (1993 - 2000) &a.sos (1993 - 2000) &a.wollman (1993 - 2000) &a.joerg (1993 - 2000) &a.jdp (1997 - 2000) &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Development Team Alumni The following people were members of the FreeBSD development team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.tedm (???? - 2000) &a.karl (???? - 2000) &a.gclarkii (???? - 2000) &a.jraynard (???? - 2000) &a.jgreco (???? - 1999) &a.ats (???? - 1999) Jamil Weatherby (1997 - 1999) meganm (???? - 1998) &a.dyson (???? - 1998) Amancio Hasty (1997 - 1998) Drew Derbyshire (1997 - 1998) Derived Software Contributors 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. There are also portions of NetBSD and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com Adrian Colley aecolley@ois.ie Adrian Hall ahall@mirapoint.com Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex G. Bulushev bag@demos.su Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex Le Heux alexlh@funk.org Alex Kapranoff kappa@zombie.antar.bryansk.ru Alex Perel veers@disturbed.net Alex Varju varju@webct.com Alex Zepeda garbanzo@hooked.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andrey Tchoritch andy@venus.sympad.net Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Ask Bjoern Hansen ask@valueclick.com Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Chapman chapmanb@arches.uga.edu Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher N. Harrell cnh@ivmg.net Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@home.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Cyrille Lefevre clefevre@citeweb.net Cyrus Rahman cr@jcmax.com Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@eece.unm.edu David Borman dab@bsdi.com David W. Chapman Jr. dwcjr@inethouston.net David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Sugar dyfet@gnu.org David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Denis Shaposhnikov dsh@vlink.ru Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dirk Keunecke dk@panda.rhein-main.de Dirk Meyer dirk.meyer@dinoex.sub.org Dirk Nehrling nerle@pdv.de Dishanker Rajakulendren draj@oceanfree.net Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Domas Mituzas midom@dammit.lt Dominik Brettnacher domi@saargate.de Dominik Rothert dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us Donn Miller dmmiller@cvzoom.net Dan Pelleg dpelleg+unison@cs.cmu.edu &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp Eike Bernhardt eike.bernhardt@gmx.de ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eagriff@global2000.net Eric Melville eric@osd.bsdi.com Eric Blood eblood@cs.unr.edu Eric D. Futch efutch@nyct.net Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erich Zigler erich@tacni.net Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@coredumped.null.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp G. Adam Stanislavadam@whizkidtech.net Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Gene Raytsin pal@paladin7.net Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com George Reid services@nevernet.net Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giorgos Keramidas keramida@ceid.upatras.gr Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Lamm holger@eit.uni-kl.de Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilia Chipitsine ilia@jane.cgu.chel.su Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jay Krell jay.krell@cornell.edu Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer jeff@isni.net Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@noc.dfn.d Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Karlson karlj000@unbc.ca Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse McConnell jesse@cylant.com Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Sloan odinn@atlantabiker.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jimmy Olgeni olgeni@uli.it Jin Guojun jin@george.lbl.gov Joachim Kuebart kuebart@mathematik.uni-ulm.de Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Joseph Scott joseph.scott@owp.csus.edu Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jau@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv Justin Stanford jus@security.za.net K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kim Scarborough sluggo@unknown.nu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Herrmann klaus.herrmann@gmx.net Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Konstantin Chuguev Konstantin.Chuguev@dante.org.uk Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Leo Kim leo@florida.sarang.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M. L. Dodson bdodson@scms.utmb.EDU M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Makoto YAMAKURA makoto@pinpott.spnet.ne.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Knight markk@knigma.org Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk Markus Holmberg saska@acc.umu.se Martin Birgmeier Martin Blapp blapp@attic.ch Martin Hinner mhi@linux.gyarab.cz Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masahiro TAKEMURA mastake@msel.t.u-tokyo.ac.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Emmerton root@gabby.gsicomp.on.ca Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Maxime Henrion mhenrion@cybercable.fr Micha Class michael_class@hpbbse.bbn.hp.com Michael Lucas mwlucas@blackhelicopters.org Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Barcroft mike@q9media.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@mired.org Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.algebra.com Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW MITA Yoshio mita@jp.FreeBSD.org Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Ahlstrom nrahlstr@winternet.com Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nicholas Esborn nick@netdot.net Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net &a.nsayer; Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oddbjorn Steffenson oddbjorn@tricknology.org Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Helmling oliver.helmling@stud.uni-bayreuth.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Bihan-Faou patrick@mindstep.com Patrick Hausen unknown Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Per Wigren wigren@home.se Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Peter van Heusden pvh@egenetics.com Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Philippe Lefebvre nemesis@balistik.net Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Rasmus Kaj kaj@Raditex.se Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@enteract.com Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Rod Taylor rod@idiotswitch.org Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Ryuichiro IMURA imura@af.airnet.ne.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey Potapov sp@alkor.ru Sergey Samoyloff gonza@techline.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shinya FUJIE fujie@tk.elec.waseda.ac.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon Dick simond@irrelevant.org Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stijn Hoop stijn@win.tue.nl Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sungman Cho smcho@tsp.korea.ac.kr Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp TAKAHASHI Kaoru kaoru@kaisei.org Takahiro Yugawa yugawa@orleans.rim.or.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas Quinot thomas@cuivre.fr.eu.org Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Tobias Reifenberger treif@mayn.de Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher Tony.Maher@eBioinformatics.com Torbjorn Granlund tege@matematik.su.se Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko SARUMRU mistral@imasy.or.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall ahall@mirapoint.com Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Antony Halse guy@rucus.ru.ac.za Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml index 32c941bb80..56f2ee039b 100644 --- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,2746 +1,2746 @@ Advanced Networking Synopsis The following chapter will cover some of the more frequently used network services on UNIX systems. This, of course, will pertain to configuring said services on your FreeBSD system. Gateways and Routes Contributed by &a.gryphon;. 6 October 1995. For one machine to be able to find another, there must be a mechanism in place to describe how to get from one to the other. This is called Routing. A route is a defined pair of addresses: a destination and a gateway. The pair indicates that if you are trying to get to this destination, send along through this gateway. There are three types of destinations: individual hosts, subnets, and default. The default route is used if none of the other routes apply. We will talk a little bit more about default routes later on. There are also three types of gateways: individual hosts, interfaces (also called links), and ethernet hardware addresses. An example To illustrate different aspects of routing, we will use the following example which is the output of the command netstat -r: Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 foobar.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.foobar.com link#1 UC 0 0 224 link#1 UC 0 0 The first two lines specify the default route (which we will cover in the next section) and the localhost route. The interface (Netif column) that it specifies to use for localhost is lo0, also known as the loopback device. This says to keep all traffic for this destination internal, rather than sending it out over the LAN, since it will only end up back where it started anyway. The next thing that stands out are the 0:e0:... addresses. These are ethernet hardware addresses. FreeBSD will automatically identify any hosts (test0 in the example) on the local ethernet and add a route for that host, directly to it over the ethernet interface, ed0. There is also a timeout (Expire column) associated with this type of route, which is used if we fail to hear from the host in a specific amount of time. In this case the route will be automatically deleted. These hosts are identified using a mechanism known as RIP (Routing Information Protocol), which figures out routes to local hosts based upon a shortest path determination. FreeBSD will also add subnet routes for the local subnet (10.20.30.255 is the broadcast address for the subnet 10.20.30, and foobar.com is the domain name associated with that subnet). The designation link#1 refers to the first ethernet card in the machine. You will notice no additional interface is specified for those. Both of these groups (local network hosts and local subnets) have their routes automatically configured by a daemon called routed. If this is not run, then only routes which are statically defined (ie. entered explicitly) will exist. The host1 line refers to our host, which it knows by ethernet address. Since we are the sending host, FreeBSD knows to use the loopback interface (lo0) rather than sending it out over the ethernet interface. The two host2 lines are an example of what happens when we use an ifconfig alias (see the section of ethernet for reasons why we would do this). The => symbol after the lo0 interface says that not only are we using the loopback (since this is address also refers to the local host), but specifically it is an alias. Such routes only show up on the host that supports the alias; all other hosts on the local network will simply have a link#1 line for such. The final line (destination subnet 224) deals with MultiCasting, which will be covered in a another section. The other column that we should talk about are the Flags. Each route has different attributes that are described in the column. Below is a short table of some of these flags and their meanings: U Up: The route is active. H Host: The route destination is a single host. G Gateway: Send anything for this destination on to this remote system, which will figure out from there where to send it. S Static: This route was configured manually, not automatically generated by the system. C Clone: Generates a new route based upon this route for machines we connect to. This type of route is normally used for local networks. W WasCloned: Indicated a route that was auto-configured based upon a local area network (Clone) route. L Link: Route involves references to ethernet hardware. Default routes When the local system needs to make a connection to remote host, it checks the routing table to determine if a known path exists. If the remote host falls into a subnet that we know how to reach (Cloned routes), then the system checks to see if it can connect along that interface. If all known paths fail, the system has one last option: the default route. This route is a special type of gateway route (usually the only one present in the system), and is always marked with a c in the flags field. For hosts on a local area network, this gateway is set to whatever machine has a direct connection to the outside world (whether via PPP link, or your hardware device attached to a dedicated data line). If you are configuring the default route for a machine which itself is functioning as the gateway to the outside world, then the default route will be the gateway machine at your Internet Service Provider's (ISP) site. Let us look at an example of default routes. This is a common configuration: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] The hosts Local1 and Local2 are at your site, with the formed being your PPP connection to your ISP's Terminal Server. Your ISP has a local network at their site, which has, among other things, the server where you connect and a hardware device (T1-GW) attached to the ISP's Internet feed. The default routes for each of your machines will be: host default gateway interface Local2 Local1 ethernet Local1 T1-GW PPP A common question is Why (or how) would we set the T1-GW to be the default gateway for Local1, rather than the ISP server it is connected to?. Remember, since the PPP interface is using an address on the ISP's local network for your side of the connection, routes for any other machines on the ISP's local network will be automatically generated. Hence, you will already know how to reach the T1-GW machine, so there is no need for the intermediate step of sending traffic to the ISP server. As a final note, it is common to use the address ...1 as the gateway address for your local network. So (using the same example), if your local class-C address space was 10.20.30 and your ISP was using 10.9.9 then the default routes would be: Local2 (10.20.30.2) --> Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) Dual homed hosts There is one other type of configuration that we should cover, and that is a host that sits on two different networks. Technically, any machine functioning as a gateway (in the example above, using a PPP connection) counts as a dual-homed host. But the term is really only used to refer to a machine that sits on two local-area networks. In one case, the machine as two ethernet cards, each having an address on the separate subnets. Alternately, the machine may only have one ethernet card, and be using ifconfig aliasing. The former is used if two physically separate ethernet networks are in use, the latter if there is one physical network segment, but two logically separate subnets. Either way, routing tables are set up so that each subnet knows that this machine is the defined gateway (inbound route) to the other subnet. This configuration, with the machine acting as a Bridge between the two subnets, is often used when we need to implement packet filtering or firewall security in either or both directions. Routing propagation We have already talked about how we define our routes to the outside world, but not about how the outside world finds us. We already know that routing tables can be set up so that all traffic for a particular address space (in our examples, a class-C subnet) can be sent to a particular host on that network, which will forward the packets inbound. When you get an address space assigned to your site, your service provider will set up their routing tables so that all traffic for your subnet will be sent down your PPP link to your site. But how do sites across the country know to send to your ISP? There is a system (much like the distributed DNS information) that keeps track of all assigned address-spaces, and defines their point of connection to the Internet Backbone. The Backbone are the main trunk lines that carry Internet traffic across the country, and around the world. Each backbone machine has a copy of a master set of tables, which direct traffic for a particular network to a specific backbone carrier, and from there down the chain of service providers until it reaches your network. It is the task of your service provider to advertise to the backbone sites that they are the point of connection (and thus the path inward) for your site. This is known as route propagation. Troubleshooting Sometimes, there is a problem with routing propagation, and some sites are unable to connect to you. Perhaps the most useful command for trying to figure out where a routing is breaking down is the &man.traceroute.8; command. It is equally useful if you cannot seem to make a connection to a remote machine (i.e. &man.ping.8; fails). The &man.traceroute.8; command is run with the name of the remote host you are trying to connect to. It will show the gateway hosts along the path of the attempt, eventually either reaching the target host, or terminating because of a lack of connection. For more information, see the manual page for &man.traceroute.8;. Bridging Written by Steve Peterson steve@zpfe.com. Introduction It is sometimes useful to divide one physical network (i.e., an Ethernet segment) into two separate network segments, without having to create IP subnets and use a router to connect the segments together. A device that connects two networks together in this fashion is called a bridge. and a FreeBSD system with two network interface cards can act as a bridge. The bridge works by learning the MAC layer addresses (i.e., Ethernet addresses) of the devices on each of its network interfaces. It forwards traffic between two networks only when its source and destination are on different networks. In many respects, a bridge is like an Ethernet switch with very few ports. Situations where bridging is appropriate There are two common situations in which a bridge is used today. High traffic on a segment Situation one is where your physical network segment is overloaded with traffic, but you don't want for whatever reason to subnet the network and interconnect the subnets with a router. Let's consider an example of a newspaper where the Editorial and Production departments are on the same subnetwork. The Editorial users all use server A for file service, and the Production users are on server B. An Ethernet is used to connect all users together, and high loads on the network are slowing things down. If the Editorial users could be segregated on one network segment and the Production users on another, the two network segments could be connected with a bridge. Only the network traffic destined for interfaces on the "other" side of the bridge would be sent to the other network, reducing congestion on each network segment. Filtering/traffic shaping firewall The second common situation is where firewall functionality is needed without IP Masquerading (NAT). An example is a small company that is connected via DSL or ISDN to their ISP. They have a 13 address global IP allocation for their ISP and have 10 PCs on their network. In this situation, using a router-based firewall is difficult because of subnetting issues. A bridge-based firewall can be configured and dropped into the path just downstream of their DSL/ISDN router without any IP numbering issues. Configuring a bridge Network interface card selection A bridge requires at least two network cards to function. Unfortunately, not all network interface cards as of FreeBSD 4.0 support bridging. Read &man.bridge.4; for details on the cards that are supported. Install and test the two network cards before continuing. Kernel configuration changes To enable kernel support for bridging, add the options BRIDGE statement to your kernel configuration file, and rebuild your kernel. Firewall support If you are planning to use the bridge as a firewall, you will need to add the IPFIREWALL option as well. Read for general information on configuring the bridge as a firewall. If you need to allow non-IP packets (such as ARP) to flow through the bridge, there is an undocumented firewall option that must be set. This option is IPFIREWALL_DEFAULT_TO_ACCEPT. Note that this changes the default rule for the firewall to accept any packet. Make sure you know how this changes the meaning of your ruleset before you set it. Traffic shaping support If you want to use the bridge as a traffic shaper, you will need to add the DUMMYNET option to your kernel configuration. Read &man.dummynet.4; for further information. Enabling the bridge Add the line net.link.ether.bridge=1 to /etc/sysctl.conf to enable the bridge at runtime. If you want the bridged packets to be filtered by ipfw, you should also add net.link.ether.bridge_ipfw=1 as well. Performance My bridge/firewall is a Pentium 90 with one 3Com 3C900B and one 3C905B. The protected side of the network runs at 10mbps half duplex and the connection between the bridge and my router (a Cisco 675) runs at 100mbps full duplex. With no filtering enabled, I've found that the bridge adds about 0.4 milliseconds of latency to pings from the protected 10mbps network to the Cisco 675. Other information If you want to be able to telnet into the bridge from the network, it is OK to assign one of the network cards an IP address. The consensus is that assigning both cards an address is a bad idea. If you have multiple bridges on your network, there cannot be more than one path between any two workstations. Technically, this means that there is no support for spanning tree link management. NFS Written by &a.unfurl;, 4 March 2000. Among the many different file systems that FreeBSD supports is a very unique type, the Network File System or NFS. NFS allows you to share directories and files on one machine with one or more other machines via the network they are attached to. Using NFS, users and programs can access files on remote systems as if they were local files. NFS has several benefits: Local workstations dont need as much disk space because commonly used data can be stored on a single machine and still remain accessible to everyone on the network. There is no need for users to have unique home directories on every machine on your network. Once they have an established directory that is available via NFS it can be accessed from anywhere. Storage devices such as floppies and CD-ROM drives can be used by other machines on the network eliminating the need for extra hardware. How It Works NFS is composed of two sides – a client side and a server side. Think of it as a want/have relationship. The client wants the data that the server side has. The server shares its data with the client. In order for this system to function properly a few processes have to be configured and running properly. The server has to be running the following daemons: nfsd - The NFS Daemon which services requests from NFS clients. mountd - The NFS Mount Daemon which actually carries out requests that nfsd passes on to it. The client side only needs to run a single daemon: nfsiod - The NFS async I/O Daemon which services requests from its NFS server. Configuring NFS Luckily for us, on a FreeBSD system this setup is a snap. The processes that need to be running can all be run at boot time with a few modifications to your /etc/rc.conf file. On the NFS server make sure you have: nfs_server_enable="YES" nfs_server_flags="-u -t -n 4" mountd_flags="-r" mountd is automatically run whenever the NFS server is enabled. The and flags to nfsd tell it to serve UDP and TCP clients. The flag tells nfsd to start 4 copies of itself. On the client, make sure you have: nfs_client_enable="YES" nfs_client_flags="-n 4" Like nfsd, the tells nfsiod to start 4 copies of itself. The last configuration step requires that you create a file called /etc/exports. The exports file specifies which file systems on your server will be shared (a.k.a., exported) and with what clients they will be shared. Each line in the file specifies a file system to be shared. There are a handful of options that can be used in this file but I will only touch on a few of them. You can find out about the rest in the &man.exports.5; man page. Here are a few example /etc/exports entries: The following line exports /cdrom to three silly machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in your /etc/hosts file. The flag makes the shared file system read-only. With this flag, the remote system will not be able to make any changes to the the shared file system. /cdrom -ro moe larry curly The following line exports /home to three hosts by IP address. This is a useful setup if you have a private network but do not have DNS running. The flag allows all the directories below the specified file system to be exported as well. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 The following line exports /a to two machines that have different domain names than the server. The flag allows the root user on the remote system to write to the shared file system as root. Without the -maproot=0 flag even if someone has root access on the remote system they won't be able to modify files on the shared file system. /a -maproot=0 host.domain.com box.example.com In order for a client to share an exported file system it must have permission to do so. Make sure your client is listed in your /etc/exports file. Now that you have made all these changes you can just reboot and let FreeBSD start everything for you at boot time or you can run the following commands as root: On the NFS server: &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r On the NFS client: &prompt.root; nfsiod -n 4 Now you should be ready to actually mount a remote file system. This can be done one of two ways. In these examples the server's name will be server and the client's name will be client. If you just want to temporarily mount a remote file system or just want to test out your config you can run a command like this as root on the client: &prompt.root; mount server:/home /mnt This will mount /home on the server on /mnt on the client. If everything is setup correctly you should be able to go into /mnt on the client and see all the files that are on the server. If you want to permanently (each time you reboot) mount a remote file system you need to add it to your /etc/fstab file. Here is an example line: server:/home /mnt nfs rw 0 0 Read the &man.fstab.5; man page for more options. Practical Uses There are many very cool uses for NFS. I use it quite a bit on the LAN I admin. Here are a few ways I have found it to be useful. I have several machines on my network but only one of them has a CD-ROM drive. Why? Because I have that one CD-ROM drive shared with all the others via NFS. The same can be done with floppy drives. With so many machines on the network it gets old having your personal files strewn all over the place. I have a central NFS server that houses all user home directories and shares them with the rest of the machines on the LAN, so no matter where I login I have the same home directory. When you get to reinstalling FreeBSD on one of your machines, NFS is the way to go. Just pop your distribution CD into your file server and away you go. I have a common /usr/ports/distfiles directory that all my machines share. That way when I go to install a port that I already installed on a different machine I do not have to download the source all over again. Problems integrating with other systems Contributed by &a.jlind;. Certain Ethernet adapters for ISA PC systems have limitations which can lead to serious network problems, particularly with NFS. This difficulty is not specific to FreeBSD, but FreeBSD systems are affected by it. The problem nearly always occurs when (FreeBSD) PC systems are networked with high-performance workstations, such as those made by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some operations may succeed, but suddenly the server will seem to become unresponsive to the client, even though requests to and from other systems continue to be processed. This happens to the client system, whether the client is the FreeBSD system or the workstation. On many systems, there is no way to shut down the client gracefully once this problem has manifested itself. The only solution is often to reset the client, because the NFS situation cannot be resolved. Though the correct solution is to get a higher performance and capacity Ethernet adapter for the FreeBSD system, there is a simple workaround that will allow satisfactory operation. If the FreeBSD system is the server, include the option on the mount from the client. If the FreeBSD system is the client, then mount the NFS file system with the option . These options may be specified using the fourth field of the fstab entry on the client for automatic mounts, or by using the parameter of the mount command for manual mounts. It should be noted that there is a different problem, sometimes mistaken for this one, when the NFS servers and clients are on different networks. If that is the case, make certain that your routers are routing the necessary UDP information, or you will not get anywhere, no matter what else you are doing. In the following examples, fastws is the host (interface) name of a high-performance workstation, and freebox is the host (interface) name of a FreeBSD system with a lower-performance Ethernet adapter. Also, /sharedfs will be the exported NFS filesystem (see man exports), and /project will be the mount point on the client for the exported file system. In all cases, note that additional options, such as or and may be desirable in your application. Examples for the FreeBSD system (freebox) as the client: in /etc/fstab on freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 As a manual mount command on freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Examples for the FreeBSD system as the server: in /etc/fstab on fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 As a manual mount command on fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Nearly any 16-bit Ethernet adapter will allow operation without the above restrictions on the read or write size. For anyone who cares, here is what happens when the failure occurs, which also explains why it is unrecoverable. NFS typically works with a block size of 8k (though it may do fragments of smaller sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS block gets split into multiple Ethernet packets, even though it is still a single unit to the upper-level code, and must be received, assembled, and acknowledged as a unit. The high-performance workstations can pump out the packets which comprise the NFS unit one right after the other, just as close together as the standard allows. On the smaller, lower capacity cards, the later packets overrun the earlier packets of the same unit before they can be transferred to the host and the unit as a whole cannot be reconstructed or acknowledged. As a result, the workstation will time out and try again, but it will try again with the entire 8K unit, and the process will be repeated, ad infinitum. By keeping the unit size below the Ethernet packet size limitation, we ensure that any complete Ethernet packet received can be acknowledged individually, avoiding the deadlock situation. Overruns may still occur when a high-performance workstations is slamming data out to a PC system, but with the better cards, such overruns are not guaranteed on NFS units. When an overrun occurs, the units affected will be retransmitted, and there will be a fair chance that they will be received, assembled, and acknowledged. Diskless Operation Contributed by &a.martin;. netboot.com/netboot.rom allow you to boot your FreeBSD machine over the network and run FreeBSD without having a disk on your client. Under 2.0 it is now possible to have local swap. Swapping over NFS is also still supported. Supported Ethernet cards include: Western Digital/SMC 8003, 8013, 8216 and compatibles; NE1000/NE2000 and compatibles (requires recompile) Setup Instructions Find a machine that will be your server. This machine will require enough disk space to hold the FreeBSD 2.0 binaries and have bootp, tftp and NFS services available. Tested machines: HP9000/8xx running HP-UX 9.04 or later (pre 9.04 doesn't work) Sun/Solaris 2.3. (you may need to get bootp) Set up a bootp server to provide the client with IP, gateway, netmask. diskless:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: Set up a TFTP server (on same machine as bootp server) to provide booting information to client. The name of this file is cfg.X.X.X.X (or /tftpboot/cfg.X.X.X.X, it will try both) where X.X.X.X is the IP address of the client. The contents of this file can be any valid netboot commands. Under 2.0, netboot has the following commands: help print help list ip print/set client's IP address server print/set bootp/tftp server address netmask print/set netmask hostname name print/set hostname kernel print/set kernel name rootfs print/set root filesystem swapfs print/set swap filesystem swapsize set diskless swapsize in KBytes diskboot boot from disk autoboot continue boot process trans | turn transceiver on|off flags set boot flags A typical completely diskless cfg file might contain: rootfs 192.1.2.3:/rootfs/myclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname myclient.mydomain A cfg file for a machine with local swap might contain: rootfs 192.1.2.3:/rootfs/myclient hostname myclient.mydomain Ensure that your NFS server has exported the root (and swap if applicable) filesystems to your client, and that the client has root access to these filesystems A typical /etc/exports file on FreeBSD might look like: /rootfs/myclient -maproot=0:0 myclient.mydomain /swapfs -maproot=0:0 myclient.mydomain And on HP-UX: /rootfs/myclient -root=myclient.mydomain /swapfs -root=myclient.mydomain If you are swapping over NFS (completely diskless configuration) create a swap file for your client using dd. If your swapfs command has the arguments /swapfs and the size 20000 as in the example above, the swapfile for myclient will be called /swapfs/swap.X.X.X.X where X.X.X.X is the client's IP addr, e.g.: &prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 Also, the client's swap space might contain sensitive information once swapping starts, so make sure to restrict read and write access to this file to prevent unauthorized access: &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 Unpack the root filesystem in the directory the client will use for its root filesystem (/rootfs/myclient in the example above). On HP-UX systems: The server should be running HP-UX 9.04 or later for HP9000/800 series machines. Prior versions do not allow the creation of device files over NFS. When extracting /dev in /rootfs/myclient, beware that some systems (HPUX) will not create device files that FreeBSD is happy with. You may have to go to single user mode on the first bootup (press control-c during the bootup phase), cd /dev and do a sh ./MAKEDEV all from the client to fix this. Run netboot.com on the client or make an EPROM from the netboot.rom file Using Shared <filename>/</filename> and <filename>/usr</filename> filesystems At present there isn't an officially sanctioned way of doing this, although I have been using a shared /usr filesystem and individual / filesystems for each client. If anyone has any suggestions on how to do this cleanly, please let me and/or the &a.core; know. Compiling netboot for specific setups Netboot can be compiled to support NE1000/2000 cards by changing the configuration in /sys/i386/boot/netboot/Makefile. See the comments at the top of this file. ISDN Last modified by &a.wlloyd;. A good resource for information on ISDN technology and hardware is Dan Kegel's ISDN Page. A quick simple road map to ISDN follows: If you live in Europe I suggest you investigate the ISDN card section. If you are planning to use ISDN primarily to connect to the Internet with an Internet Provider on a dial-up non-dedicated basis, I suggest you look into Terminal Adapters. This will give you the most flexibility, with the fewest problems, if you change providers. If you are connecting two LANs together, or connecting to the Internet with a dedicated ISDN connection, I suggest you consider the stand alone router/bridge option. Cost is a significant factor in determining what solution you will choose. The following options are listed from least expensive to most expensive. ISDN Cards Contributed by &a.hm;. This section is really only relevant to ISDN users in countries where the DSS1/Q.931 ISDN standard is supported. Some growing number of PC ISDN cards are supported under FreeBSD 2.2.x and up by the isdn4bsd driver package. It is still under development but the reports show that it is successfully used all over Europe. The latest isdn4bsd version is available from ftp://isdn4bsd@ftp.consol.de/pub/, the main isdn4bsd ftp site (you have to log in as user isdn4bsd , give your mail address as the password and change to the pub directory. Anonymous ftp as user ftp or anonymous will not give the desired result). Isdn4bsd allows you to connect to other ISDN routers using either IP over raw HDLC or by using synchronous PPP. A telephone answering machine application is also available. Many ISDN PC cards are supported, mostly the ones with a Siemens ISDN chipset (ISAC/HSCX), support for other chipsets (from Motorola, Cologne Chip Designs) is currently under development. For an up-to-date list of supported cards, please have a look at the README file. In case you are interested in adding support for a different ISDN protocol, a currently unsupported ISDN PC card or otherwise enhancing isdn4bsd, please get in touch with hm@kts.org. A majordomo maintained mailing list is available. To join the list, send mail to &a.majordomo; and specify: subscribe freebsd-isdn in the body of your message. ISDN Terminal Adapters Terminal adapters(TA), are to ISDN what modems are to regular phone lines. Most TA's use the standard hayes modem AT command set, and can be used as a drop in replacement for a modem. A TA will operate basically the same as a modem except connection and throughput speeds will be much faster than your old modem. You will need to configure PPP exactly the same as for a modem setup. Make sure you set your serial speed as high as possible. The main advantage of using a TA to connect to an Internet Provider is that you can do Dynamic PPP. As IP address space becomes more and more scarce, most providers are not willing to provide you with a static IP anymore. Most stand-alone routers are not able to accommodate dynamic IP allocation. TA's completely rely on the PPP daemon that you are running for their features and stability of connection. This allows you to upgrade easily from using a modem to ISDN on a FreeBSD machine, if you already have PPP setup. However, at the same time any problems you experienced with the PPP program and are going to persist. If you want maximum stability, use the kernel PPP option, not the user-land iijPPP. The following TA's are know to work with FreeBSD. Motorola BitSurfer and Bitsurfer Pro Adtran Most other TA's will probably work as well, TA vendors try to make sure their product can accept most of the standard modem AT command set. The real problem with external TA's is like modems you need a good serial card in your computer. You should read the serial ports section in the handbook for a detailed understanding of serial devices, and the differences between asynchronous and synchronous serial ports. A TA running off a standard PC serial port (asynchronous) limits you to 115.2Kbs, even though you have a 128Kbs connection. To fully utilize the 128Kbs that ISDN is capable of, you must move the TA to a synchronous serial card. Do not be fooled into buying an internal TA and thinking you have avoided the synchronous/asynchronous issue. Internal TA's simply have a standard PC serial port chip built into them. All this will do, is save you having to buy another serial cable, and find another empty electrical socket. A synchronous card with a TA is at least as fast as a stand-alone router, and with a simple 386 FreeBSD box driving it, probably more flexible. The choice of sync/TA v.s. stand-alone router is largely a religious issue. There has been some discussion of this in the mailing lists. I suggest you search the archives for the complete discussion. Stand-alone ISDN Bridges/Routers ISDN bridges or routers are not at all specific to FreeBSD or any other operating system. For a more complete description of routing and bridging technology, please refer to a Networking reference book. In the context of this page, I will use router and bridge interchangeably. As the cost of low end ISDN routers/bridges comes down, it will likely become a more and more popular choice. An ISDN router is a small box that plugs directly into your local Ethernet network(or card), and manages its own connection to the other bridge/router. It has all the software to do PPP and other protocols built in. A router will allow you much faster throughput that a standard TA, since it will be using a full synchronous ISDN connection. The main problem with ISDN routers and bridges is that interoperability between manufacturers can still be a problem. If you are planning to connect to an Internet provider, I recommend that you discuss your needs with them. If you are planning to connect two lan segments together, ie: home lan to the office lan, this is the simplest lowest maintenance solution. Since you are buying the equipment for both sides of the connection you can be assured that the link will work. For example to connect a home computer or branch office network to a head office network the following setup could be used. Branch office or Home network Network is 10 Base T Ethernet. Connect router to network cable with AUI/10BT transceiver, if necessary. ---Sun workstation | ---FreeBSD box | ---Windows 95 (Do not admit to owning it) | Stand-alone router | ISDN BRI line If your home/branch office is only one computer you can use a twisted pair crossover cable to connect to the stand-alone router directly. Head office or other lan Network is Twisted Pair Ethernet. -------Novell Server | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | |___---Stand-alone router | ISDN BRI line One large advantage of most routers/bridges is that they allow you to have 2 separate independent PPP connections to 2 separate sites at the same time. This is not supported on most TA's, except for specific(expensive) models that have two serial ports. Do not confuse this with channel bonding, MPP etc. This can be very useful feature, for example if you have an dedicated ISDN connection at your office and would like to tap into it, but don't want to get another ISDN line at work. A router at the office location can manage a dedicated B channel connection (64Kbs) to the internet, as well as a use the other B channel for a separate data connection. The second B channel can be used for dial-in, dial-out or dynamically bond(MPP etc.) with the first B channel for more bandwidth. An Ethernet bridge will also allow you to transmit more than just IP traffic, you can also send IPX/SPX or whatever other protocols you use. NIS/YP Written by &a.unfurl;, 21 January 2000, enhanced with parts and comments from Eric Ogren eogren@earthlink.net and Udo Erdelhoff ue@nathan.ruhr.de in June 2000. What is it? NIS, which stands for Network Information Services, was - developed by Sun Microsystems to centralize adminstration of Unix + developed by Sun Microsystems to centralize administration of Unix (originally SunOS) systems. It has now essentially become an industry standard; all major Unices (Solaris, HP-UX, AIX, Linux, NetBSD, OpenBSD, FreeBSD, etc) support NIS. NIS was formerly known as Yellow Pages (or yp), but due to copyright violations, Sun was forced to change the name. It is a RPC-based client/server system that allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location. It is similar to Windows NT's domain system; although the internal implementation of the two aren't at all similar, the basic functionality can be compared. Terms/processes you should know There are several terms and several important user processes that you will come across when attempting to implement NIS on FreeBSD, whether you are trying to create an NIS server or act an NIS client: The NIS domainname. An NIS master server and all of its clients (including its slave servers) have a NIS domainname. Similar to an NT domain name, the NIS domainname does not have anything to do with DNS. portmap. portmap must be running in order to enable RPC (Remote Procedure Call, a network protocol used by NIS). If portmap is not running, it will be impossible to run an NIS server, or to act as an NIS client. ypbind. ypbind “binds” an NIS client to its NIS server. It will take the NIS domainname from the system, and using RPC, connect to the server. ypbind is the core of client-server communication in an NIS environment; if ypbind dies on a client machine, it will not be able to access the NIS server. ypserv. ypserv, which should only be running on NIS servers, is the NIS server process itself. If ypserv dies, then the server will no longer be able to respond to NIS requests (hopefully, there is a slave server to take over for it). There are some implementations of NIS (but not the FreeBSD one), that don't try to reconnect to another server if the server it used before dies. Often, the only thing that helps in this case is to restart the server process (or even the whole server) or the ypbind process on the client. rpc.yppasswdd. rpc.yppasswdd, another process that should only be running on NIS master servers, is a daemon that will allow NIS clients to change their NIS passwords. If this daemon is not running, users will have to login to the NIS master server and change their passwords there. How does it work? There are three types of hosts in an NIS environment; master servers, slave servers, and clients. Servers act as a central repository for host configuration information. Master servers hold the authoritative copy of this information, while slave servers mirror this information for redundancy. Clients rely on the servers to provide this information to them. Information in many files can be shared in this manner. The master.passwd, group, and hosts files are commonly shared via NIS. Whenever a process on a client needs information that would normally be found in these files locally, it makes a query to the server it is bound to, to get this information. Machine types A NIS master server. This server, analogous to a Windows NT primary domain controller, maintains the files used by all of the NIS clients. The passwd, group, and other various files used by the NIS clients live on the master server. It is possible for one machine to be an NIS master server for more than one NIS domain. However, this will not be covered in this introduction, which assumes a relatively small-scale NIS environment. NIS slave servers. Similar to NT's backup domain controllers, NIS slave servers maintain copies of the NIS master's data files. NIS slave servers provide the redundancy, - which is needed in important enviroments. They also help + which is needed in important environments. They also help to balance the load of the master server: NIS Clients always attach to the NIS server, whose response they get first, and this includes slave-server-replies. NIS clients. NIS clients, like most NT workstations, authenticate against the NIS server (or the NT - domain controller in the NT Workstation case) to logon. + domain controller in the NT Workstation case) to log on. Using NIS/YP This section will deal with setting up a sample NIS environment. This section assumes that you are running FreeBSD 3.3 or later. The instructions given here will probably work for any version of FreeBSD greater than 3.0, but there are no guarantees that this is true. Planning Let's assume that you are the administrator of a small university lab. This lab, which consists of 15 FreeBSD machines, - currently has no centralised point of administration; each machine + currently has no centralized point of administration; each machine has its own /etc/passwd and /etc/master.passwd. These files are kept in sync with each other only through manual intervention; currently, when you add a user to the lab, you must run adduser on all 15 machines. Clearly, this has to change, so you have decided to convert the lab to use NIS, using two of the machines as servers. Therefore, the configuration of the lab now looks something like: Machine name IP address Machine role ellington 10.0.0.2 NIS master coltrane 10.0.0.3 NIS slave basie 10.0.0.4 Faculty workstation bird 10.0.0.5 Client machine cli[1-11] 10.0.0.[6-17] Other client machines If you are setting up a NIS scheme for the first time, it is a good idea to think through how you want to go about it. No matter what the size of your network, there are a few decisions that need to be made. Choosing a NIS Domain Name This might not be the domainname that you are used to. It is more accurately called the NIS domainname. When a client broadcasts its requests for info, it includes the name of the NIS domain that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts that are related in someway way. Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can cause confusion when trying to debug network problems. The NIS domainname should be unique within your network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the "acme-art" NIS domain. For this example, assume you have chosen the name test-domain. However, some operating systems (notably SunOS) use their NIS domain name as their Internet domain name. If one or more machines on your network have this restriction, you must use the Internet domain name as your NIS domain name. Physical Server Requirements There are several things to keep in mind when choosing a machine to use as a NIS server. One of the unfortunate things about NIS is the level of dependency the clients have on the server. If a client cannot contact the server for its NIS domain, very often the machine becomes unusable. The lack of user and group information causes most systems to temporarily freeze up. With this in mind you should make sure to choose a machine that won't be prone to being rebooted regularly, or one that might be used for development. The NIS server should ideally be a stand alone machine whose sole purpose in life is to be an NIS server. If you have a network that is not very heavily used, it is acceptable to put the NIS server on a machine running other services, just keep in mind that if the NIS server becomes unavailable, it will affect all of your NIS clients adversely. NIS Servers The canonical copies of all NIS information are stored on a single machine called the NIS master server. The databases used to store the information are called NIS maps. In FreeBSD, these maps are stored in /var/yp/[domainname] where [domainname] is the name of the NIS domain being served. A single NIS server can support several domains at once, therefore it is possible to have several such directories, one for each supported domain. Each domain will have its own independent set of maps. NIS master and slave servers handle all NIS requests with the ypserv daemon. Ypserv is responsible for receiving incoming requests from NIS clients, translating the requested domain and map name to a path to the corresponding database file and transmitting data from the database back to the client. Setting up a NIS master server Setting up a master NIS server can be relatively straight forward, depending on your needs. FreeBSD comes with support for NIS out-of-the-box. All you need is to add the following lines to /etc/rc.conf, and FreeBSD will do the rest for you. nisdomainname="test-domain" This line will set the NIS domainname to test-domain upon network setup (e.g. after reboot). nis_server_enable="YES" This will tell FreeBSD to start up the NIS server processes when the networking is next brought up. nis_yppasswdd_enable="YES" This will enable the rpc.yppasswdd daemon, which, as mentioned above, will allow users to change their NIS password from a client machine. Now, everything you have to do is to run the command /etc/netstart as superuser. It will setup everything for you, using the values you defined in /etc/rc.conf. Initializing the NIS maps The NIS maps are database files, that are kept in the /var/yp directory. They are generated from configuration files in the /etc directory of the NIS master, with one exception: the /etc/master.passwd file. - This is for a good reason; you don't want to propogate + This is for a good reason; you don't want to propagate passwords to your root and other administrative accounts to all the servers in the NIS domain. Therefore, before we initialize the NIS maps, you should: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd You should remove all entries regarding system accounts (bin, tty, kmem, games, etc), as well as any accounts that you - don't want to be propogated to the NIS clients (for example + don't want to be propagated to the NIS clients (for example root and any other UID 0 (superuser) accounts). Make sure the /var/yp/master.passwd is neither group nor world readable (mode 600)! Use the chmod command, if appreciate. When you have finished, it's time to initialize the NIS maps! FreeBSD includes a script named ypinit to do this for you (see its man page for more information). Note that this script is available on most UNIX OSs, but not on all. On Digital Unix/Compaq Tru64 Unix it is called ypsetup. Because we are generating maps for an NIS master, we are going to pass the option to ypinit. To generate the NIS maps, assuming you already performed the steps above, run: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit should have created /var/yp/Makefile from /var/yp/Makefile.dist. When created, this file assumes that you are operating in a single server NIS environment with only FreeBSD machines. Since test-domain has a slave server as well, you must edit /var/yp/Makefile: ellington&prompt.root; vi /var/yp/Makefile You should comment out the line that says `NOPUSH = "True"' (if it is not commented out already). Setting up a NIS slave server Setting up an NIS slave server is even more simple than - setting up the master. Logon to the slave server and edit the + setting up the master. Log on to the slave server and edit the file /etc/rc.conf as you did before. The only difference is that we now must use the option when running ypinit. The option requires the name of the NIS master be passed to it as well, so our command line looks like: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. You should now have a directory called /var/yp/test-domain. Copies of the NIS master server's maps should be in this directory. You will need to make sure that these stay updated. The following /etc/crontab entries on your slave servers should do the job: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid These two lines force the slave to sync its maps with the maps on the master server. Although this is not mandatory, because the master server tries to make sure any changes to it's NIS maps are communicated to it's slaves, the password information is so vital to systems that depend on the server, that it is a good idea to force the updates. This is more important on busy networks where map updates might not always complete. Now, run the command /etc/netstart on the slave server as well, which again starts the NIS server. NIS Clients An NIS client establishes what is called a binding to a particular NIS server using the ypbind daemon. ypbind checks the system's default domain (as set by the domainname command), and begins broadcasting RPC requests on the local network. These requests specify the name of the domain for which ypbind is attempting to establish a binding. If a server that has been configured to serve the requested domain receives one of the broadcasts, it will respond to ypbind, which will record the server's address. If there are several servers available (a master and several slaves, for example), ypbind will use the address of the first one to respond. From that point on, the client system will direct all of its NIS requests to that server. Ypbind will occasionally ping the server to make sure it is still up and running. If it fails to receive a reply to one of its pings within a reasonable amount of time, ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server. Setting up an NIS client Setting up a FreeBSD machine to be a NIS client is fairly straight forward. Edit the file /etc/rc.conf and add the following lines in order to set the NIS domainname and start ypbind upon network startup: nisdomainname="test-domain" nis_client_enable="YES" To import all possible password entries from the NIS server, add this line to your /etc/master.passwd file, using vipw: +::::::::: This line will afford anyone with a valid account in the NIS server's password maps an account. There are many ways to configure your NIS client by changing this line. See the netgroups part below for more information. For more detailed reading see O'Reilly's book on Managing NFS and NIS. To import all possible group entries from the NIS server, add this line to your /etc/group file: +:*:: After completing these steps, you should be able to run ypcat passwd and see the NIS server's passwd map. NIS Security In general, any remote user can issue an RPC to ypserv and retrieve the contents of your NIS maps, provided the remote user knows your domainname. To prevent such unauthorized transactions, ypserv supports a feature called securenets which can be used to restrict access to a given set of hosts. At startup, ypserv will attempt to load the securenets information from a file called /var/yp/securenets. This path varies depending on the path specified with the option. This file contains entries that consist of a network specification and a network mask separated by white space. Lines starting with # are considered to be comments. A sample securenets file might look like this: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 If ypserv receives a request from an address that matches one of these rules, it will process the request normally. If the address fails to match a rule, the request will be ignored and a warning message will be logged. If the /var/yp/securenets file does not exist, ypserv will allow connections from any host. The ypserv program also has support for Wietse Venema's tcpwrapper package. This allows the administrator to use the tcpwrapper configuration files for access control instead of /var/yp/securenets. While both of these access control mechanisms provide some security, they, like the privileged port test, are vulnerable to IP spoofing attacks. All NIS-related traffic should be blocked at your firewall. Servers using /var/yp/securenets may fail to serve legitimate NIS clients with archaic TCP/IP implementations. Some of these implementations set all host bits to zero when doing broadcasts and/or fail to observe the subnet mask when calculating the broadcast address. While some of these problems can be fixed by changing the client configuration, other problems may force the retirement of the client systems in question or the abandonment of /var/yp/securenets. Using /var/yp/securenets on a server with such an archaic implementation of TCP/IP is a really bad idea and will lead to loss of NIS functionality for large parts of your network. The use of the tcpwrapper package increases the latency of your NIS server. The additional delay may be long enough to cause timeouts in client programs, especially in busy networks or with slow NIS servers. If one or more of your client systems suffers from these symptoms, you should convert the client systems in question into NIS slave servers and force them to bind to themselves. Barring some users from logging on In our lab, there is a machine basie that is supposed to be a faculty only workstation. We don't want to take this machine out of the NIS domain, yet the passwd file on the master NIS server contains accounts for both faculty and students. What can we do? There is a way to bar specific users from logging on to a machine, even if they are present in the NIS database. To do this, all you must do is add -username to the end of the /etc/master.passwd file on the client machine, where username is the username of the user you wish to bar from logging in. This should preferably be done using vipw, since vipw will sanity check your changes to /etc/master.passwd, as well as automatically rebuild the password database when you finish editing. For example, if we wanted to bar user bill from logging on to basie we would: basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Using netgroups The netgroups part was contributed by Udo Erdelhoff ue@nathan.ruhr.de in July 2000. The method shown in the previous chapter works reasonably well if you need special rules for a very small number of users and/or machines. On larger networks, you will forget to bar some users from logging onto sensitive machines, or you may even have to modify each machine separately, thus loosing the main benefit of NIS, - centralised administration. + centralized administration. The NIS developers' solution for this problem is called netgroups. Their purpose and semantics can be compared to the normal groups used by Unix file systems. The main differences are the lack of a numeric id and the ability to define a netgroup by including both user accounts and other netgroups. Netgroups were developed to handle large, complex networks with hundreds of users and machines. On one hand, this is a Good Thing if you are forced to deal with such a situation. On the other hand, this complexity makes it almost impossible to explain netgroups with really simple examples. The example used in the remainder of this chapter demonstrates this problem. Let us assume that your successful introduction of NIS in your laboratory caught your superiors' interest. Your next job is to extend your NIS domain to cover some of the other machines on campus. The two tables contain the names of the new users and new machines as well as brief descriptions of them. User Name(s) Description alpha, beta Normal employees of the IT department charlie, delta The new apprentices of the IT department echo, foxtrott, golf, ... Ordinary employees able, baker, ... The current interns Machine Name(s) Description - war, death, famine, polution + war, death, famine, pollution Your most important servers. Only the IT employees are allowed to log onto these machines. pride, greed, envy, wraith, lust, sloth Less important servers. All members of the IT department are allowed to login onto these machines. one, two, three, four, ... Ordinary workstations. Only the real employees are allowed to use these machines. trashcan - A very old machine without any critcal data. + A very old machine without any critical data. Even the intern is allowed to use this box. If you tried to implement these restrictions by separately blocking each user, you would have to add one -user line to each system's passwd for each user who is not allowed to login onto that system. If you forget just one entry, you could be in trouble. It may feasible to do this correctly during the initial setup, however you will eventually forget to add the lines for new users during day-to-day operations. After all, Murphy was an optimist. Handling this situation with netgroups offers several advantages. Each user need not be handled separately; you assign a user to one or netgroup and allow or forbid logins for all members of the netgroup. If you add a new machine, you will only have to define login restrictions for netgroups. If a new user is added, you will only have to add the user to one or more netgroups. Those changes are independent of each other; no more for each combination of user and machine do... If your NIS setup is planned carefully, you will only have to modify exactly one central configuration file to grant or deny access to machines. - The first step is the initialisation of the NIS map + The first step is the initialization of the NIS map netgroup. FreeBSD's ypinit does not create this map by default, but its NIS implementation will support it once it has been created. To create an empty map, simply type ellington&prompt.root; vi /var/yp/netgroup and start adding content. For our example, we need at least four netgroups: IT employees, IT apprentices, normal employees and interns. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP etc. are the names of the netgroups. Each bracketed group adds one or more user accounts to it. The three fields inside a group are: The name of the host(s) where the following items are valid. If you do not specify a hostname, the entry is valid on all hosts. If you do specify a hostname, you will a realm of darkness, horror and utter confusion. The name of the account that belongs to this netgroup. The NIS domain for the account. You can import accounts from other NIS domains into your netgroup if you are one of unlucky fellows with more than one NIS domain. - Each of this fields can contain wildcards, see + Each of these fields can contain wildcards. See &man.netgroup.5; for details. Netgroup names longer than 8 characters should not be used, especially if you have machines running other operating systems within your NIS domain. The names are case sensitive; using capital letters for your netgroup names is an easy way to distinguish between user, machine and netgroup names. Some NIS clients (other than FreeBSD) cannot handle netgroups with a large number of entries. For example, some older versions of SunOS start to cause trouble if a netgroup contains more than 15 entries. You can circumvent this limit by creating several sub-netgroups with 15 users or less and a real netgroup that consists of the sub-netgroups: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe32,domain) (,joe33,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 You can repeat this process if you need more than 225 users within a single netgroup. Activating and distributing your new NIS map is easy: ellington&prompt.root; cd /var/yp ellington&prompt.root; make This will generate the three NIS maps netgroup, netgroup.byhost and netgroup.byuser. Use &man.ypcat.1; to check if your new NIS map are available: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser The output of the first command should resemble the contents of /var/yp/netgroup. The second command will not produce output if you have not specified host-specific netgroups. The third command can be used to get the list of netgroups for a user. The client setup is quite simple. To configure the server war, you only have to start &man.vipw.8; and replace the line +::::::::: with +@IT_EMP::::::::: Now, only the data for the users defined in the netgroup IT_EMP is imported into war's password database and only these users are allowed to login. Unfortunately, this limitation also applies to the ~ function of the shell and all routines converting between user names and numerical user ids. In other words, cd ~user will not work, ls -l will show the numerical id instead of the username and find . -user joe -print will fail with No such user. To fix this, you will have to import all user entries without allowing them to login onto your servers. This can be achieved by adding another line to /etc/master.passwd. This line should contain +:::::::::/sbin/nologin, meaning Import all entries but replace the shell with /sbin/nologin in the imported entries. You can replace any field in the passwd entry by placing a default value in your /etc/master.passwd. Make sure that the line +:::::::::/sbin/nologin is placed after +@IT_EMP:::::::::. Otherwise, all user accounts imported from NIS will have /sbin/nologin as their login shell. After this change, you will only have to change one NIS map if a new employee joins the IT department. You could use a similar approach for the less important servers by replacing the old +::::::::: in their local version of /etc/master.passwd with something like this: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin The corresponding lines for the normal workstations could be: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin And everything would be fine until there is a policy change a few weeks later: The IT department starts hiring interns. The IT interns are allowed to use the normal workstations and the less important servers; and the IT apprentices are allowed to login onto the main servers. You add a new netgroup IT_INTERN, add the new IT interns to this netgroup and start to change the config on each and every machine... As the old saying goes: Errors in - centralised planning lead to global mess. + centralized planning lead to global mess. NIS' ability to create netgroups from other netgroups can be used to prevent situations like these. One possibility is the creation of role-based netgroups. For example, you could create a netgroup called BIGSRV to define the login restrictions for the important servers, another netgroup called SMALLSRV for the less important servers and a third netgroup called USERBOX for the normal workstations. Each of these netgroups contains the netgroups that are allowed to login onto these machines. The new entries for your NIS map netgroup should look like this: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS This method of defining login restrictions works reasonably well if you can define groups of machines with identical restrictions. Unfortunately, this is the exception and not the rule. Most of the time, you will need the ability to define login restrictions on a per-machine basis. Machine-specific netgroup definitions are the other possibility to deal with the policy change outlined above. In this scenario, the /etc/master.passwd of each box contains two lines starting with ``+''. The first of them adds a netgroup with the accounts allowed to login onto this machine, the second one adds all other accounts with /sbin/nologin as shell. It is a good idea to use the ALL-CAPS version of the machine name as the name of the netgroup. In other words, the lines should look like this: +@BOXNAME::::::::: +:::::::::/sbin/nologin Once you have completed this task for all your machines, you will not have to modify the local versions of /etc/master.passwd ever again. All further changes can be handled by modifying the NIS map. Here is an example of a possible netgroup map for this scenario with some additional goodies. # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks -# Allow echo und golf to access our anti-virus-machine +# Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server -POLUTION BIGSRV (,india,test-domain) +POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] If you are using some kind of database to manage your user accounts, you should be able to create the first part of the map with your database's report tools. This way, new users will automatically have access to the boxes. One last word of caution: It may not always be advisable to use machine-based netgroups. If you are deploying a couple dozen or even hundreds of identical machines for student labs, you should use role-based netgroups instead of machine-based netgroups to keep the size of the NIS map within reasonable limits. Important things to remember There are still a couple of things that you will need to do differently now that you are in an NIS environment. Every time you wish to add a user to the lab, you must add it to the master NIS server only, and you must remember to rebuild the NIS maps. If you forget to do this, the new user will not be able to login anywhere except on the NIS master. For example, if we needed to add a new user “jsmith” to the lab, we would: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain You could also run adduser jsmith instead of pw useradd jsmith. Keep the administration accounts out of the NIS - maps. You don't want to be propogating administrative + maps. You don't want to be propagating administrative accounts and passwords to machines that will have users that shouldn't have access to those accounts. Keep the NIS master and slave secure, and minimize their downtime. If somebody either hacks or simply turns off these machines, they have effectively rendered many people without the ability to login to the lab. - This is the chief weakness of any centralised administration + This is the chief weakness of any centralized administration system, and it is probably the most important weakness. If you do not protect your NIS servers, you will have a lot of angry users! NIS v1 compatibility FreeBSD's ypserv has some support for serving NIS v1 clients. FreeBSD's NIS implementation only uses the NIS v2 protocol, however other implementations include support for the v1 protocol for backwards compatibility with older systems. The ypbind daemons supplied with these systems will try to establish a binding to an NIS v1 server even though they may never actually need it (and they may persist in broadcasting in search of one even after they receive a response from a v2 server). Note that while support for normal client calls is provided, this version of ypserv does not handle v1 map transfer requests; consequently, it can not be used as a master or slave in conjunction with older NIS servers that only support the v1 protocol. Fortunately, there probably are not any such servers still in use today. NIS servers that are also NIS clients Care must be taken when running ypserv in a multi-server domain where the server machines are also NIS clients. It is generally a good idea to force the servers to bind to themselves rather than allowing them to broadcast bind requests and possibly become bound to each other. Strange failure modes can result if one server goes down and others are dependent upon on it. Eventually all the clients will time out and attempt to bind to other servers, but the delay involved can be considerable and the failure mode is still present since the servers might bind to each other all over again. You can force a host to bind to a particular server by running ypbind with the flag. libscrypt v.s. libdescrypt One of the most common issues that people run into when trying to implement NIS is crypt library compatibility. If your NIS server is using the DES crypt libraries, it will only support clients that are using DES as well. To check which one your server and clients are using look at the symlinks in /usr/lib. If the machine is configured to use the DES libraries, it will look something like this: &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a -r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 -r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a If the machine is configured to use the standard FreeBSD MD5 crypt libraries they will look something like this: &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a -r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 -r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a If you have trouble authenticating on an NIS client, this is a pretty good place to start looking for possible problems. If you want to deploy an NIS server for a heterogenous network, you will probably have to use DES on all systems because it is the lowest common standard. DHCP Written by &a.gsutter;, March 2000. What is DHCP? DHCP, the Dynamic Host Configuration Protocol, describes the means by which a system can connect to a network and obtain the necessary information for communication upon that network. FreeBSD uses the ISC (Internet Software Consortium) DHCP implementation, so all implementation-specific information here is for use with the ISC distribution. What This Section Covers This handbook section attempts to describe only the parts of the DHCP system that are integrated with FreeBSD; consequently, the server portions are not described. The DHCP manual pages, in addition to the references below, are useful resources. How it Works When dhclient, the DHCP client, is executed on the client machine, it begins broadcasting requests for configuration information. By default, these requests are on UDP port 68. The server replies on UDP 67, giving the client an IP address and other relevant network information such as netmask, router, and DNS servers. All of this information comes in the form of a DHCP "lease" and is only valid for a certain time (configured by the DHCP server maintainer). In this manner, stale IP addresses for clients no longer connected to the network can be automatically reclaimed. DHCP clients can obtain a great deal of information from the server. An exhaustive list may be found in &man.dhcp-options.5;. FreeBSD Integration FreeBSD fully integrates the ISC DHCP client, dhclient. DHCP client support is provided within both the installer and the base system, obviating the need for detailed knowledge of network configurations on any network that runs a DHCP server. dhclient has been included in all FreeBSD distributions since 3.2. DHCP is supported by sysinstall. When configuring a network interface within sysinstall, the first question asked is, "Do you want to try dhcp configuration of this interface?" Answering affirmatively will execute dhclient, and if successful, will fill in the network configuration information automatically. There are two things you must do to have your system use DHCP upon startup: Make sure that the bpf device is compiled into your kernel. To do this, add pseudo-device bpf to your kernel configuration file, and rebuild the kernel. For more information about building kernels, see . The bpf device is already part of the GENERIC kernel that is supplied with FreeBSD, so if you don't have a custom kernel, you shouldn't need to create one in order to get DHCP working. For those who are particularly security conscious, you should be warned that bpf is also the device that allows packet sniffers to work correctly (although they still have to be run as root). bpf is required to use DHCP, but if you are very sensitive about security, you probably shouldn't add bpf to your kernel in the expectation that at some point in the future you will be using DHCP. Edit your /etc/rc.conf to include the following: ifconfig_fxp0="DHCP" Be sure to replace fxp0 with the designation for the interface that you wish to dynamically configure. If you are using a different location for dhclient, or if you wish to pass additional flags to dhclient, also include the following (editing as necessary): dhcp_program="/sbin/dhclient" dhcp_flags="" The DHCP server, dhcpd, is included as part of the isc-dhcp2 port in the ports collection. This port contains the full ISC DHCP distribution, consisting of client, server, relay agent and documentation. Files /etc/dhclient.conf dhclient requires a configuration file, /etc/dhclient.conf. Typically the file contains only comments, the defaults being reasonably sane. This configuration file is described by the &man.dhclient.conf.5; man page. /sbin/dhclient dhclient is statically linked and resides in /sbin. The &man.dhclient.8; manual page gives more information about dhclient. /sbin/dhclient-script dhclient-script is the FreeBSD-specific DHCP client configuration script. It is described in &man.dhclient-script.8;, but should not need any user modification to function properly. /var/db/dhclient.leases The DHCP client keeps a database of valid leases in this file, which is written as a log. &man.dhclient.leases.5; gives a slightly longer description. Further Reading The DHCP protocol is fully described in RFC 2131. An informational resource has also been set up at dhcp.org. diff --git a/en_US.ISO8859-1/books/handbook/backups/chapter.sgml b/en_US.ISO8859-1/books/handbook/backups/chapter.sgml index 779564658b..e3bdd0a658 100644 --- a/en_US.ISO8859-1/books/handbook/backups/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/backups/chapter.sgml @@ -1,732 +1,732 @@ Backups Synopsis The following chapter will cover methods of backing up data, and the programs used to create those backups. If you would like to contribute something to this section, send it to the &a.doc;. Tape Media The major tape media are the 4mm, 8mm, QIC, mini-cartridge and DLT. 4mm (DDS: Digital Data Storage) 4mm tapes are replacing QIC as the workstation backup media of choice. This trend accelerated greatly when Conner purchased Archive, a leading manufacturer of QIC drives, and then stopped production of QIC drives. 4mm drives are small and quiet but do not have the reputation for reliability that is enjoyed by 8mm drives. The cartridges are less expensive and smaller (3 x 2 x 0.5 inches, 76 x 51 x 12 mm) than 8mm cartridges. 4mm, like 8mm, has comparatively short head life for the same reason, both use helical scan. Data throughput on these drives starts ~150kB/s, peaking at ~500kB/s. Data capacity starts at 1.3 GB and ends at 2.0 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. Multi-drive tape library units can have 6 drives in a single cabinet with automatic tape changing. Library capacities reach 240 GB. The DDS-3 standard now supports tape capacities up to 12GB (or 24GB compressed). 4mm drives, like 8mm drives, use helical-scan. All the benefits and drawbacks of helical-scan apply to both 4mm and 8mm drives. Tapes should be retired from use after 2,000 passes or 100 full backups. 8mm (Exabyte) 8mm tapes are the most common SCSI tape drives; they are the best choice of exchanging tapes. Nearly every site has an exabyte 2 GB 8mm tape drive. 8mm drives are reliable, convenient and quiet. Cartridges are inexpensive and small (4.8 x 3.3 x 0.6 inches; 122 x 84 x 15 mm). One downside of 8mm tape is relatively short head and tape life due to the high rate of relative motion of the tape across the heads. Data throughput ranges from ~250kB/s to ~500kB/s. Data sizes start at 300 MB and go up to 7 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. These drives are available as single units or multi-drive tape libraries with 6 drives and 120 tapes in a single cabinet. Tapes are changed automatically by the unit. Library capacities reach 840+ GB. The Exabyte Mammoth model supports 12GB on one tape (24GB with compression) and costs approximately twice as much as conventional tape drives. Data is recorded onto the tape using helical-scan, the heads are positioned at an angle to the media (approximately 6 degrees). The tape wraps around 270 degrees of the spool that holds the heads. The spool spins while the tape slides over the spool. The result is a high density of data and closely packed tracks that angle across the tape from one edge to the other. QIC QIC-150 tapes and drives are, perhaps, the most common tape drive and media around. QIC tape drives are the least expensive "serious" backup drives. The downside is the cost of media. QIC tapes are expensive compared to 8mm or 4mm tapes, up to 5 times the price per GB data storage. But, if your needs can be satisfied with a half-dozen tapes, QIC may be the correct choice. QIC is the most common tape drive. Every site has a QIC drive of some density or another. Therein lies the rub, QIC has a large number of densities on physically similar (sometimes identical) tapes. QIC drives are not quiet. These drives audibly seek before they begin to record data and are clearly audible whenever reading, writing or seeking. QIC tapes measure (6 x 4 x 0.7 inches; 15.2 x 10.2 x 1.7 mm). Mini-cartridges, which also use 1/4" wide tape are discussed separately. Tape libraries and changers are not available. Data throughput ranges from ~150kB/s to ~500kB/s. Data capacity ranges from 40 MB to 15 GB. Hardware compression is available on many of the newer QIC drives. QIC drives are less frequently installed; they are being supplanted by DAT drives. Data is recorded onto the tape in tracks. The tracks run along the long axis of the tape media from one end to the other. The number of tracks, and therefore the width of a track, varies with the tape's capacity. Most if not all newer drives provide backward-compatibility at least for reading (but often also for writing). QIC has a good reputation regarding the safety of the data (the mechanics are simpler and more robust than for helical scan drives). Tapes should be retired from use after 5,000 backups. * Mini-Cartridge ]]> DLT DLT has the fastest data transfer rate of all the drive types listed here. The 1/2" (12.5mm) tape is contained in a single spool cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a swinging gate along one entire side of the cartridge. The drive mechanism opens this gate to extract the tape leader. The tape leader has an oval hole in it which the drive uses to "hook" the tape. The take-up spool is located inside the tape drive. All the other tape cartridges listed here (9 track tapes are the only exception) have both the supply and take-up spools located inside the tape cartridge itself. Data throughput is approximately 1.5MB/s, three times the throughput of 4mm, 8mm, or QIC tape drives. Data capacities range from 10GB to 20GB for a single drive. Drives are available in both multi-tape changers and multi-tape, multi-drive tape libraries containing from 5 to 900 tapes over 1 to 20 drives, providing from 50GB to 9TB of storage. With compression, DLT Type IV format supports up to 70GB capacity. Data is recorded onto the tape in tracks parallel to the direction of travel (just like QIC tapes). Two tracks are written at once. Read/write head lifetimes are relatively long; once the tape stops moving, there is no relative motion between the heads and the tape. AIT AIT is a new format from Sony, and can hold up to 50GB (with compression) per tape. The tapes contain memory chips which retain an index of the tape's contents. This index can be rapidly read by the tape drive to determine the position of files on the tape, instead of the several minutes that would be required for other tapes. Software such as SAMS:Alexandria can operate forty or more AIT tape libraries, communicating directly with the tape's memory chip to display the contents on screen, determine what files where backed up to which tape, locate the correct tape, load it, and restore the data from the tape. Libraries like this cost in the region of $20,000, pricing them a little out of the hobbyist market. Using a New Tape for the First Time The first time that you try to read or write a new, completely blank tape, the operation will fail. The console messages should be similar to: sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready The tape does not contain an Identifier Block (block number 0). All QIC tape drives since the adoption of QIC-525 standard write an Identifier Block to the tape. There are two solutions: mt fsf 1 causes the tape drive to write an Identifier Block to the tape. Use the front panel button to eject the tape. Re-insert the tape and &man.dump.8; data to the tape. &man.dump.8; will report DUMP: End of tape detected and the console will show: HARDWARE FAILURE info:280 asc:80,96 rewind the tape using: mt rewind Subsequent tape operations are successful. Backup Programs The three major programs are &man.dump.8;, &man.tar.1;, and &man.cpio.1;. Dump and Restore &man.dump.8; and &man.restore.8; are the traditional Unix backup programs. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the filesystems. &man.dump.8; backs up devices, entire filesystems, not parts of a filesystem and not directory trees that span more than one filesystem, using either soft links &man.ln.1; or mounting one filesystem onto another. &man.dump.8; does not write files and directories to tape, but rather writes the data blocks that are the building blocks of files and directories. &man.dump.8; has quirks that remain from its early days in Version 6 of ATT Unix (circa 1975). The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives. &man.rdump.8; and &man.rrestore.8; backup data across the network to a tape drive attached to another computer. Both programs rely upon &man.rcmd.3; and &man.ruserok.3; to access the remote tape drive. Therefore, the user performing the backup must have rhosts access to the remote computer. The arguments to &man.rdump.8; and &man.rrestore.8; must suitable to use - on the remote computer. (e.g. When rdump'ing from + on the remote computer. (e.g. When rdumping from a FreeBSD computer to an Exabyte tape drive connected to a Sun called komodo, use: /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrsa8 /dev/rda0a 2>&1) Beware: there are security implications to allowing rhosts commands. Evaluate your situation carefully. Tar &man.tar.1; also dates back to Version 6 of ATT Unix (circa 1975). &man.tar.1; operates in cooperation with the filesystem; &man.tar.1; writes files and directories to tape. &man.tar.1; does not support the full range of options that are available from &man.cpio.1;, but &man.tar.1; does not require the unusual command pipeline that &man.cpio.1; uses. Most versions of &man.tar.1; do not support backups across the network. The GNU version of &man.tar.1;, which FreeBSD utilizes, supports remote devices using the same syntax as &man.rdump.8;. To &man.tar.1; to an Exabyte tape drive connected to a Sun called komodo, use: /usr/bin/tar cf komodo:/dev/nrsa8 . 2>&1. For versions without remote device support, you can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. &prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b If you're worried about the security of backing over a network you should use the &man.ssh.1; command instead of &man.rsh.1;. Cpio &man.cpio.1; is the original Unix file interchange tape program for magnetic media. &man.cpio.1; has options (among many others) to perform byte-swapping, write a number of different archives format, and pipe the data to other programs. This last feature makes &man.cpio.1; and excellent choice for installation media. &man.cpio.1; does not know how to walk the directory tree and a list of files must be provided through stdin. &man.cpio.1; does not support backups across the network. You can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. (XXX add an example command) Pax &man.pax.1; is IEEE/POSIX's answer to &man.tar.1; and &man.cpio.1;. Over the years the various versions of &man.tar.1; and &man.cpio.1; have gotten slightly incompatible. So rather than fight it out to fully standardize them, POSIX created a new archive utility. &man.pax.1; attempts to read and write many of the various &man.cpio.1; and &man.tar.1; formats, plus new formats of its own. Its command set more resembles &man.cpio.1; than &man.tar.1;. Amanda Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and network communications with the Amanda server. A common problem at locations with a number of large disks is the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem. Amanda can use a "holding disk" to backup several filesystems at the same time. Amanda creates "archive sets": a group of tapes used over a period of time to create full backups of all the filesystems listed in Amanda's configuration file. The "archive set" also contains nightly incremental (or differential) backups of all the filesystems. Restoring a damaged filesystem requires the most recent full backup and the incremental backups. The configuration file provides fine control backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is available as either a port or a package, it is not installed by default. Do Nothing Do nothing is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it! If your time and your data is worth little to nothing, then Do nothing is the most suitable backup program for your computer. But beware, Unix is a useful tool, you may find that within six months you have a collection of files that are valuable to you. Do nothing is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by your computer. An example is the files that comprise these handbook pages-they have been generated from SGML input files. Creating backups of these HTML files is not necessary. The SGML source files are backed up regularly. Which Backup Program is Best? &man.dump.8; Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of Unix filesystems is &man.dump.8;. Elizabeth created filesystems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by doing a backup and restore of that filesystems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See torture-testing Backup and Archive Programs. Emergency Restore Procedure Before the Disaster There are only four steps that you need to perform in preparation for any disaster that may occur. First, print the disklabel from each of your disks (e.g. disklabel da0 | lpr), your filesystem table (/etc/fstab) and all boot messages, two copies of each. Second, determine that the boot and fix-it floppies (boot.flp and fixit.flp) have all your devices. The easiest way to check is to reboot your machine with the boot floppy in the floppy drive and check the boot messages. If all your devices are listed and functional, skip on to step three. Otherwise, you have to create two custom bootable floppies which has a kernel that can mount your all of your disks and access your tape drive. These floppies must contain: &man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8;, and whichever backup program you use. These programs must be statically linked. If you use &man.dump.8;, the floppy must contain &man.restore.8;. Third, create backup tapes regularly. Any changes that you make after your last backup may be irretrievably lost. Write-protect the backup tapes. Fourth, test the floppies (either boot.flp and fixit.flp or the two custom bootable floppies you made in step two.) and backup tapes. Make notes of the procedure. Store these notes with the bootable floppy, the printouts and the backup tapes. You will be so distraught when restoring that the notes may prevent you from destroying your backup tapes (How? In place of tar xvf /dev/rsa0, you might accidently type tar cvf /dev/rsa0 and over-write your backup tape). For an added measure of security, make bootable floppies and two backup tapes each time. Store one of each at a remote location. A remote location is NOT the basement of the same office building. A number of firms in the World Trade Center learned this lesson the hard way. A remote location should be physically separated from your computers and disk drives by a significant distance. An example script for creating a bootable floppy: /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes # cd /mnt/dev ./MAKEDEV std ./MAKEDEV da0 ./MAKEDEV da1 ./MAKEDEV da2 ./MAKEDEV sa0 ./MAKEDEV pty0 cd / # # create minimum filesystem table # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < After the Disaster The key question is: did your hardware survive? You have been doing regular backups so there is no need to worry about the software. If the hardware has been damaged. First, replace those parts that have been damaged. If your hardware is okay, check your floppies. If you are using a custom boot floppy, boot single-user (type -s at the boot: prompt). Skip the following paragraph. If you are using the boot.flp and fixit.flp floppies, keep reading. Insert the boot.flp floppy in the first floppy drive and boot the computer. The original install menu will be displayed on the screen. Select the Fixit--Repair mode with CDROM or floppy. option. Insert the fixit.flp when prompted. restore and the other programs that you need are located in /mnt2/stand. Recover each filesystem separately. Try to &man.mount.8; (e.g. mount /dev/da0a /mnt) the root partition of your first disk. If the disklabel was damaged, use &man.disklabel.8; to re-partition and label the disk to match the label that your printed and saved. Use &man.newfs.8; to re-create the filesystems. Re-mount the root partition of the floppy read-write (mount -u -o rw /mnt). Use your backup program and backup tapes to recover the data for this filesystem (e.g. restore vrf /dev/sa0). Unmount the filesystem (e.g. umount /mnt) Repeat for each filesystem that was damaged. Once your system is running, backup your data onto new tapes. Whatever caused the crash or data loss may strike again. An another hour spent now, may save you from further distress later. * I did not prepare for the Disaster, What Now? ]]> What about Backups to Floppies? Can I use floppies for backing up my data? Floppy disks are not really a suitable media for making backups as: The media is unreliable, especially over long periods of time Backing up and restoring is very slow They have a very limited capacity (the days of backing up an entire hard disk onto a dozen or so floppies has long since passed). However, if you have no other method of backing up your data then floppy disks are better than no backup at all. If you do have to use floppy disks then ensure that you use good quality ones. Floppies that have been lying around the office for a couple of years are a bad choice. Ideally use new ones from a reputable manufacturer. So how do I backup my data to floppies? The best way to backup to floppy disk is to use &man.tar.1; with the (multi volume) option, which allows backups to span multiple floppies. To backup all the files in the current directory and sub-directory use this (as root): &prompt.root; tar Mcvf /dev/rfd0 * When the first floppy is full &man.tar.1; will prompt you to insert the next volume (because &man.tar.1; is media independent it refers to volumes. In this context it means floppy disk) Prepare volume #2 for /dev/rfd0 and hit return: This is repeated (with the volume number incrementing) until all the specified files have been archived. Can I compress my backups? Unfortunately, &man.tar.1; will not allow the option to be used for multi-volume archives. You could, of course, &man.gzip.1; all the files, &man.tar.1; them to the floppies, then &man.gunzip.1; the files again! How do I restore my backups? To restore the entire archive use: &prompt.root; tar Mxvf /dev/rfd0 To restore only specific files you can either start with the first floppy and use: &prompt.root; tar Mxvf /dev/rfd0 filename &man.tar.1; will prompt you to insert subsequent floppies until it finds the required file. Alternatively, if you know which floppy the file is on then you can simply insert that floppy and use the same command as above. Note that if the first file on the floppy is a continuation from the previous one then &man.tar.1; will warn you that it cannot restore it, even if you have not asked it to! diff --git a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml index 70569d401a..8fd4e94856 100644 --- a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml @@ -1,543 +1,543 @@ Unix Basics Synopsis Rewritten by Chris Shumway - cshumway@cdrom.com, 10 Mar 2000. + cshumway@osd.bsdi.com, 10 Mar 2000. The following chapter will cover the basic commands and functionality of the FreeBSD operating system. If you are new to FreeBSD, you will definitely want to read through this chapter before asking for help. Permissions FreeBSD, having its history rooted in BSD UNIX, has its fundamentals based on several key UNIX concepts. The first, and most pronounced, is that FreeBSD is a multi-user operating system. The system can handle several users all working simultaneously on completely unrelated tasks. The system is responsible for properly sharing and managing requests for hardware devices, peripherals, memory, and CPU time evenly to each user. Because the system is capable of supporting multiple users, everything the system manages has a set of permissions governing who can read, write, and execute the resource. These permissions are stored as an octet broken into three pieces, one for the owner of the file, one for the group that the file belongs to, and one for everyone else. This numerical representation works like this: Value Permission Directory Listing 0 No read, no write, no execute --- 1 No read, no write, execute --x 2 No read, write, no execute -w- 3 No read, write, execute -wx 4 Read, no write, no execute r-- 5 Read, no write, execute r-x 6 Read, write, no execute rw- 7 Read, write, execute rwx For the long directory listing by ls -l, a column will show a file's permissions for the owner, group, and everyone else. Here's how it is broken up: -rw-r--r-- The first character, from left to right, is a special character that tells if this is a regular file, a directory, a special character or block device, a socket, or any other special pseudo-file device. The next three characters, designated as rw- gives the permissions for the owner of the file. The next three characters, r-- gives the permissions for the group that the file belongs to. The final three characters, r--, gives the permissions for the rest of the world. A dash means that the permission is turned off. In the case of this file, the permissions are set so the owner can read and write to the file, the group can read the file, and the rest of the world can only read the file. According to the table above, the permissions for this file would be 644, where each digit represents the three parts of the file's permission. This is all well and good, but how does the system control permissions on devices? FreeBSD actually treats most hardware devices as a file that programs can open, read, and write data to just like any other file. These special device files are stored on the /dev directory. Directories are also treated as files. They have read, write, and execute permissions. The executable bit for a directory has a slightly different meaning than that of files. When a directory is marked executable, it means it can be searched into, for example, a directory listing can be done in that directory. There are more to permissions, but they are primarily used in special circumstances such as setuid binaries and sticky directories. If you want more information on file permissions and how to set them, be sure to look at the &man.chmod.1; man page. Directory Structures Since FreeBSD uses its file systems to determine many fundamental system operations, the hierarchy of the file system is extremely important. Due to the fact that the &man.hier.7; man page provides a complete description of the directory structure, it will not be duplicated here. Please read &man.hier.7; for more information. Of significant importance is the root of all directories, the / directory. This directory is the first directory mounted at boot time and it contains the base system necessary at boot time. The root directory also contains mount points for every other file system that you want to mount. A mount point is a directory where additional file systems can be grafted onto the root file system. Standard mount points include /usr, /var, /mnt, and /cdrom. These directories are usually referenced to entries in the file /etc/fstab. /etc/fstab is a table of various file systems and mount points for reference by the system. Most of the file systems in /etc/fstab are mounted automatically at boot time from the script &man.rc.8; unless they contain the option. Consult the &man.fstab.5; manual page for more information on the format of the /etc/fstab file and the options it contains. Shells In FreeBSD, a lot of everyday work is done in a command line interface called a shell. A shell's main job is to take commands from the input channel and execute them. A lot of shells also have built in functions to help everyday tasks such a file management, file globing, command line editing, command macros, and environment variables. FreeBSD comes with a set of shells, such as sh, the Bourne Shell, and csh, the C-shell. Many other shells are available from the FreeBSD Ports Collection that have much more power, such as tcsh and bash. Which shell do you use? It is really a matter of taste. If you are a C programmer you might feel more comfortable with a C-like shell such as tcsh. If you've come from Linux or are new to a UNIX command line interface you might try bash. The point is that each shell has unique properties that may or may not work with your preferred working environment, and that you have a choice of what shell to use. One common feature in a shell is file-name completion. Given the typing of the first few letters of a command or filename, you can usually have the shell automatically complete the rest of the command or filename by hitting the TAB key on the keyboard. Here is an example. I have two files called foobar and foo.bar. I want to delete foo.bar. So what I would type on the keyboard is: rm fo[TAB].[TAB]. The shell would print out rm foo[BEEP].bar. The [BEEP] is the console bell, which is the shell telling me it was unable to totally complete the filename because there is more than one match. Both foobar and foo.bar start with fo, but it was able to complete to foo. Once I typed in ., then hit TAB again, the shell was able to fill in the rest of the filename for me. Another function of the shell is environment variables. Environment variables are a variable key pair stored in the shell's environment space. This space can be read by any program invoked by the shell, and thus contains a lot of program configuration. Here is a list of common environment variables and what they mean: Variable Description USER Current logged in user's name. PATH Colon separated list of directories to search for binaries. DISPLAY Network name of the X11 display to connect to, if available. SHELL The current shell. TERM The name of the user's terminal. Used to determine the capabilities of the terminal. TERMCAP Database entry of the terminal escape codes to perform various terminal functions. OSTYPE Type of operating system. E.g., FreeBSD. MACHTYPE The CPU architecture that the system is running on. EDITOR The user's preferred text editor. PAGER The user's preferred text pager. MANPATH Colon separated list of directories to search for manual pages. To view or set an environment variable differs somewhat from shell to shell. For example, in the C-Style shells such as tcsh and csh, you would use setenv to set and view environment variables. Under Bourne shells such as sh and bash, you would use set and export to view and set your current environment variables. For example, to set or modify the EDITOR environment variable, under csh or tcsh a command like this would set EDITOR to /usr/local/bin/emacs: &prompt.user; setenv EDITOR /usr/local/bin/emacs Under Bourne shells: &prompt.user; export EDITOR="/usr/local/bin/emacs" You can also make most shells expand the environment variable by placing a $ character in front of it on the command line. For example, echo $TERM would print out whatever $TERM is set to, because the shell expands $TERM and passes it on to echo. Shells treat a lot of special characters, called meta-characters as special representations of data. The most common one is the * character, which represents any number of characters in a filename. These special meta-characters can be used to do file name globing. For example, typing in echo * is almost the same as typing in ls because the shell takes all the files that match * and puts them on the command line for echo to see. To prevent the shell from interpreting these special characters, they can be escaped from the shell by putting a backslash (\) character in front of them. echo $TERM prints whatever your terminal is set to. echo \$TERM prints $TERM as is. Changing your shell The easiest way to change your shell is to use the chsh command. Running chsh will place you into the editor that is in your EDITOR environment variable; if it is not set, you will be placed in vi. Change the Shell: line accordingly. You can also give chsh the option; this will set your shell for you, without requiring you to enter an editor. For example, if you wanted to change your shell to bash, the following should do the trick: &prompt.user; chsh -s /usr/local/bin/bash Running chsh with no parameters and editing the shell from there would work also. The shell that you wish to use must be present in the /etc/shells file. If you have installed a shell from the ports collection, then this should have been done for you already. If you installed the shell by hand, you must do this. For example, if you installed bash by hand and placed it into /usr/local/bin, you would want to: &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells Then rerun chsh. Text Editors A lot of configuration in FreeBSD is done by editing a text file. Because of this, it would be a good idea to become familiar with a text editor. FreeBSD comes with a few as part of the base system, and many more are available in the ports collection. The easiest and simplest editor to learn is an editor called ee, which stands for easy editor. To start ee, one would type at the command line ee filename where filename is the name of the file to be edited. For example, to edit /etc/rc.conf, type in ee /etc/rc.conf. Once inside of ee, all of the commands for manipulating the editor's functions are listed at the top of the display. The caret ^ character means the control key on the keyboard, so ^e expands to pressing the control key plus the letter e. To leave ee, hit the escape key, then choose leave editor. The editor will prompt you to save any changes if the file has been modified. FreeBSD also comes with more powerful text editors such as vi as part of the base system, and emacs and vim as part of the FreeBSD ports collection. These editors offer much more functionality and power at the expense of being a little more complicated to learn. However if you plan on doing a lot of text editing, learning a more powerful editor such as vim or emacs will save you much more time in the long run. For More Information... Manual pages The most comprehensive documentation on FreeBSD is in the form of man pages. Nearly every program on the system comes with a short reference manual explaining the basic operation and various arguments. These manuals can be viewed with the man command. Use of the man command is simple: &prompt.user; man command command is the name of the command you wish to learn about. For example, to learn more about ls command type: &prompt.user; man ls The online manual is divided up into numbered sections: User commands. System calls and error numbers. Functions in the C libraries. Device drivers. File formats. Games and other diversions. Miscellaneous information. System maintenance and operation commands. Kernel developers. In some cases, the same topic may appear in more than one section of the online manual. For example, there is a chmod user command and a chmod() system call. In this case, you can tell the man command which one you want by specifying the section: &prompt.user; man 1 chmod This will display the manual page for the user command chmod. References to a particular section of the online manual are traditionally placed in parenthesis in written documentation, so &man.chmod.1; refers to the chmod user command and &man.chmod.2; refers to the system call. This is fine if you know the name of the command and simply wish to know how to use it, but what if you cannot recall the command name? You can use man to search for keywords in the command descriptions by using the switch: &prompt.user; man -k mail With this command you will be presented with a list of commands that have the keyword mail in their descriptions. This is actually functionally equivalent to using the apropos command. So, you are looking at all those fancy commands in /usr/bin but do not have the faintest idea what most of them actually do? Simply do: &prompt.user; cd /usr/bin &prompt.user; man -f * or &prompt.user; cd /usr/bin &prompt.user; whatis * which does the same thing. GNU Info Files FreeBSD includes many applications and utilities produced by the Free Software Foundation (FSF). In addition to man pages, these programs come with more extensive hypertext documents called info files which can be viewed with the info command or, if you installed emacs, the info mode of emacs. To use the &man.info.1; command, simply type: &prompt.user; info For a brief introduction, type h. For a quick command reference, type ?. diff --git a/en_US.ISO8859-1/books/handbook/boot/chapter.sgml b/en_US.ISO8859-1/books/handbook/boot/chapter.sgml index 2d354a1f90..d1c2c988c8 100644 --- a/en_US.ISO8859-1/books/handbook/boot/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/boot/chapter.sgml @@ -1,549 +1,549 @@ The FreeBSD Booting Process Synopsis FreeBSD uses a three-stage bootstrap by default, which basically entails three programs which call each other in order (two boot blocks, and the loader). Each of these three build on the previous program's understanding and provide increasing amounts of sophistication. The kernel is then started, which will then probe for devices and initialize them for use. Once the kernel boot process is finished, the kernel passes control to the user process &man.init.8;, which then makes sure the disks are in a usable state. &man.init.8; then starts the user-level resource configuration which then mounts filesystems, sets up network cards to act on the network, and generally starts all the processes that usually are run on a FreeBSD system at startup. The Boot Blocks: Bootstrap Stages 1 and 2 Bootstrapping is the process whereby a computer probes and initializes its devices, and works out what programs it is supposed to run. This involves the use of special Read Only Memory chips, which determine what further operations to do, and these usually pass control to other chips that do consistency and memory tests, configure devices, and provide a mechanism for programs to determine what configuration details were determined. In standard personal computers, this involves the BIOS (which oversees the bootstrap), and CMOS (which stores configuration). BIOS and CMOS understand disks, and also understand where on the disk to find a program that will know how to load up an operating system. This chapter will not deal with this first part of the bootstrap process. Instead it will focus on what happens after control is passed to the program on the disk. The boot blocks are responsible for finding (usually) the loader, and running it, and thus need to understand how to find that program on the filesystem, how to run the program, and also allow minor configuration of how they work. boot0 There is actually a preceding bootblock, named boot0, which lives on the Master Boot Record, the special part of the disk that the system bootstrap looks for and runs, and it simply shows a list of possible slices to boot from. boot0 is very simple, since the program in the MBR can only be 512 bytes in size. It displays something like this: boot0 screenshot F1 DOS F2 FreeBSD F3 Linux F4 ?? F5 Drive 1 Default: F2 boot1 boot1 is found on the boot sector of the boot slice, which is where boot0, or any other program on the MBR expects to find the program to run to continue the boot process. boot1 is very simple, since it too can only be 512 bytes in size, and knows just enough about the FreeBSD disklabel, which stores information about the slice, to find and execute boot2. boot2 boot2 is slightly more sophisticated, and understands the FreeBSD filesystem enough to find files on it, and can provide a simple interface to choose the kernel or loader to run. Since the loader is much more sophisticated, and provides a nice easy-to-use boot configuration, boot2 usually runs it, but previously it was tasked to run the kernel directly. boot2 screenshot >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/kernel boot: Loader: Bootstrap Stage Three The loader is the final stage of the three-stage bootstrap, and is located on the filesystem, usually as /boot/loader. While /boot/boot0, /boot/boot1, and /boot/boot2 are files there, they are not the actual copies in the MBR, the boot sector, or the disklabel respectively. The loader is intended as a user-friendly method for configuration, using an easy-to-use built-in command set, backed up by a more powerful interpreter, with a more complex command set. Loader Program Flow During initialization, the loader will probe for a console and for disks, and figure out what disk it is booting from. It will set variables accordingly, and then the interpreter is started, and the easy-to-use commands are explained to it. loader will then read /boot/loader.rc, which by default reads in /boot/defaults/loader.conf which sets reasonable defaults for variables and reads /boot/loader.conf for local changes to those variables. loader.rc then acts on these variables, loading whichever modules and kernel are selected. Finally, by default, the loader issues a 10 second wait - for keypresses, and boots the kernel if it is not interrupted. + for key presses, and boots the kernel if it is not interrupted. If interrupted, the user is presented with a prompt which understands the easy-to-use command set, where the user may adjust variables, unload all modules, load modules, and then finally boot or reboot. A more technical discussion of the process is available in &man.loader.8; Loader Built-In Commands The easy-to-use command set comprises of: autoboot seconds Proceeds to boot the kernel if not interrupted within the time span given, in seconds. It displays a countdown, and the default timespan is 10 seconds. boot -options kernelname Immediately proceeds to boot the kernel, with the given options, if any, and with the kernel name given, if it is. boot-conf Goes through the same automatic configuration of modules based on variables as what happens at boot. This only makes sense if you use unload first, and change some variables, most commonly kernel. help topic Shows help messages read from /boot/loader.help. If the topic given is index, then the list of available topics is given. include filename … Processes the file with the given filename. The file is read in, and interpreted line by line. An error immediately stops the include command. load type filename Loads the kernel, kernel module, or file of the type given, with the filename given. Any arguments after filename are passed to the file. ls path Displays a listing of files in the given path, or the root directory, if the path is not specified. If is specified, file sizes will be shown too. lsdev Lists all of the devices from which it may be possible to load modules. If is specified, more details are printed. lsmod Displays loaded modules. If is specified, more details are shown. more filename Display the files specified, with a pause at each LINES displayed. reboot Immediately reboots the system. set variable set variable=value Set loader's environment variables. unload Removes all loaded modules. Loader Examples Here are some practical examples of loader usage. To simply boot your usual kernel, but in single-user mode: boot -s To unload your usual kernel and modules, and then load just your old (or another) kernel: unload load kernel.old You can use kernel.GENERIC to refer to the generic kernel that comes on the install disk, or kernel.old to refer to your previously installed kernel (when you've upgraded or configured your own kernel, for example). Use the following to load your usual modules with another kernel: unload set kernel="kernel.old" boot-conf To load a kernel configuration script (an automated script which does the things you'd normally do in the kernel boot-time configurator): load -t userconfig_script /boot/kernel.conf Kernel Interaction During Boot Once the kernel is loaded by either loader (as usual) or boot2 (bypassing the loader), it examines its boot flags, if any, and adjusts its behavior as necessary. Kernel Boot Flags Here are the more common boot flags: during kernel initialization, ask for the device to mount as as the root file system. boot from CDROM. run UserConfig, the boot-time kernel configurator boot into single-user mode be more verbose during kernel startup There are other boot flags, read &man.boot.8; for more information on them. Init: Process Control Initialization Once the kernel has finished booting, it passes control to the user process init, which is located at /sbin/init, or the program path specified in the init_path variable in loader. Automatic Reboot Sequence The automatic reboot sequence makes sure that the filesystems available on the system are consistent. If they are not, and fsck can not fix the inconsistencies, init drops the system into single-user mode for the system administrator to take care of the problems directly. Single-User Mode This mode can be reached through the automatic reboot sequence, or by the user booting with the or setting the boot_single variable in loader. It can also be reached by calling shutdown without the reboot () or halt () options, from multi-user mode. If the system console console is set to insecure in /etc/ttys, then the system prompts for the root password before initiating single-user mode. An insecure console in /etc/ttys # name getty type status comments # # This entry needed for asking password when init goes to single-user mode # If you want to be asked for password, change "secure" to "insecure" here console none unknown off insecure An insecure console means that you consider your physical security to the console to be insecure, and want to make sure only someone who knows the root password may use single-user mode, and it does not mean that you want to run your console insecurely. Thus, if you want security, choose insecure, not secure. Multi-User Mode If init finds your filesystems to be in order, or once the user has finished in single-user mode, the system enters multi-user mode, in which it starts the resource configuration of the system. Resource Configuration (rc) The resource configuration system reads in configuration defaults from /etc/defaults/rc.conf, and system-specific details from /etc/rc.conf, and then proceeds to mount the system filesystems mentioned in /etc/fstab, start up networking services, starts up miscellaneous system daemons, and finally runs the startup scripts of locally installed packages. &man.rc.8; is a good reference to the resource configuration system, as is examining the scripts themselves. Shutdown Sequence Upon controlled shutdown, via shutdown, init will attempt to run the script /etc/rc.shutdown, and then proceed to send all processes the terminate signal, and subsequently the kill signal to any that don't terminate timely. diff --git a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml index e5c3c3be2e..c7db1f849b 100644 --- a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml @@ -1,6208 +1,6208 @@ Contributing to FreeBSD Contributed by &a.jkh;. So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth! Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our TODO list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project! Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is Needed The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers; Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs; Clean up and document the nullfs filesystem code. Coordinator: &a.eivind; Fix the union file system. Coordinator: &a.dg; Implement Int13 vm86 disk driver. Coordinator: &a.hackers; New bus architecture. Coordinator: &a.newbus; Port existing ISA drivers to new architecture. Move all interrupt-management code to appropriate parts of the bus drivers. Port PCI subsystem to new architecture. Coordinator: &a.dfr; Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented. Resolve the probe/attach priority issue once and for all. Move any remaining buses over to the new architecture. Kernel issues. Overall coordination: &a.hackers; Add more pro-active security infrastructure. Overall coordination: &a.security; Build something like Tripwire(TM) into the kernel, with a remote and local part. There are a number of cryptographic issues to getting this right; contact the coordinator for details. Coordinator: &a.eivind; Make the entire kernel use suser() instead of comparing to 0. It is presently using about half of each. Coordinator: &a.eivind; Split securelevels into different parts, to allow an administrator to throw away those privileges he can throw away. Setting the overall securelevel needs to have the same effect as now, obviously. Coordinator: &a.eivind; Make it possible to upload a list of allowed program to BPF, and then block BPF from accepting other programs. This would allow BPF to be used e.g. for DHCP, without allowing an attacker to start snooping the local network. Update the security checker script. We should at least grab all the checks from the other BSD derivatives, and add checks that a system with securelevel increased also have reasonable flags on the relevant parts. Coordinator: &a.eivind; Add authorization infrastructure to the kernel, to allow different authorization policies. Part of this could be done by modifying suser(). Coordinator: &a.eivind; Add code to the NFS layer so that you cannot chdir("..") out of an NFS partition. E.g., /usr is a UFS partition with /usr/src NFS exported. Now it is possible to use the NFS filehandle for /usr/src to get access to /usr. Medium priority tasks The following tasks need to be done, but not with any particular urgency: Full KLD based driver support/Configuration Manager. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.imp; Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.msmith; and &a.phk; APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks 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: The first N items are from Terry Lambert terry@lambert.org NetWare Server (protected mode ODI driver) loader and sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting internal v.s.. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Smaller tasks 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. If you run FreeBSD-current and have a good Internet connection, there is a machine current.FreeBSD.org which builds a full release once a day — every now and again, try and install the latest release from it and report any failures in the process. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions). Help translate FreeBSD documentation into your native language (if not already available) — just send an email to &a.doc; asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this — in fact, the documentation most in need of translation is the installation instructions. Read the freebsd-questions mailing list and &ng.misc occasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on. If you know of any bug fixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder. Move contributed software to src/contrib in the source tree. Make sure code in src/contrib is up to date. Look for year 2000 bugs (and fix any you find!) Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings. Fix warnings for ports which do deprecated things like using gets() or including malloc.h. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version) Suggest further tasks for this list! Work through the PR database The FreeBSD PR list shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users. Look through the open PRs, and see if anything there takes your interest. Some of these might be very simple tasks, that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one. Others might be much more complex. Start with the PRs that have not been assigned to anyone else, but if one them is assigned to someone else, but it looks like something you can handle, e-mail the person it is assigned to and ask if you can work on it—they might already have a patch ready to be tested, or further ideas that you can discuss with them. How to Contribute Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information about this and other mailing lists. If you find a bug or are submitting a specific change, please report it using the &man.send-pr.1; program or its WEB-based equivalent. Try to fill-in each field of the bug report. Unless they exceed 65KB, include any patches directly in the report. When including patches, do not use cut-and-paste because cut-and-paste turns tabs into spaces and makes them unusable. Consider compressing patches and using &man.uuencode.1; if they exceed 20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/. After filing a report, you should receive confirmation along with a tracking number. Keep this tracking number so that you can update us with details about the problem by sending mail to bug-followup@FreeBSD.org. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the &man.send-pr.1; command, then you may ask someone to file it for you by sending mail to the &a.bugs;. Changes to the documentation Changes to the documentation are overseen by the &a.doc;. Send submissions and changes (even small ones are welcome!) using send-pr as described in Bug Reports and General Commentary. Changes to existing source code 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 Staying current with FreeBSD for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce; and the &a.current; lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the &man.diff.1; command, with the context diff form being preferred. For example: &prompt.user; diff -c oldfile newfile or &prompt.user; diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for &man.diff.1; for more details. Once you have a set of diffs (which you may test with the &man.patch.1; command), you should submit them for inclusion with FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary. Do not just send the diffs to the &a.hackers; or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the pr database until we do. If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a tar file and run the &man.uuencode.1; program on it. Shar archives are also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, then you should send it to &a.core; directly rather than submitting it with &man.send-pr.1;. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code. New code or major value-added packages In the 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 uuencoded tar files or upload them to a web or FTP site for other people to access. If you do not have access to a web or FTP site, ask on an appropriate FreeBSD mailing list for someone to host the changes for you. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its no strings attached nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or GPL. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem. Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a BSD-style copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the %% with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. Money, Hardware or Internet access 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. <anchor id="donations">Donating funds 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. FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(currently using the BSDi address until a PO box can be opened) Wire transfers may also be sent directly to:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to &a.jkh, either via email or to the FreeBSD, Inc. postal address given above. If you do not wish to be listed in our donors section, please specify this when making your donation. Thanks! Donating hardware Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.dg; for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of new hardware. Donating Internet access We can always use new mirror sites for FTP, WWW or cvsup. If you would like to be such a mirror, please contact the FreeBSD project administrators hubs@FreeBSD.org for more information. Donors Gallery The FreeBSD Project is indebted to the following donors and would like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine to eventually replace freefall.FreeBSD.org by donating the following items: &a.mbarkah and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200Mhz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Blue Mountain Arts Epilogue Technology Corporation &a.sef Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier Chris Silva Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: BSDi for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB - fileservers, twelve Ethernets, two routers and an ATM switch for + file servers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. &a.chuck; contributed his floppy tape streamer for experimental work. Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-) Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD/. Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! Christoph Kukulies kuku@FreeBSD.org donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Special contributors: BSDi (formerly Walnut Creek CDROM) has donated almost more than we can say (see the history document for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting &a.joerg; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. Core Team Alumni 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. In rough chronological order: &a.ache (1993 - 2000) &a.jmb (1993 - 2000) &a.bde (1992 - 2000) &a.gibbs (1993 - 2000) &a.rich (1994 - 2000) &a.phk (1992 - 2000) &a.gpalmer (1993 - 2000) &a.sos (1993 - 2000) &a.wollman (1993 - 2000) &a.joerg (1993 - 2000) &a.jdp (1997 - 2000) &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Development Team Alumni The following people were members of the FreeBSD development team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.tedm (???? - 2000) &a.karl (???? - 2000) &a.gclarkii (???? - 2000) &a.jraynard (???? - 2000) &a.jgreco (???? - 1999) &a.ats (???? - 1999) Jamil Weatherby (1997 - 1999) meganm (???? - 1998) &a.dyson (???? - 1998) Amancio Hasty (1997 - 1998) Drew Derbyshire (1997 - 1998) Derived Software Contributors 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. There are also portions of NetBSD and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com Adrian Colley aecolley@ois.ie Adrian Hall ahall@mirapoint.com Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex G. Bulushev bag@demos.su Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex Le Heux alexlh@funk.org Alex Kapranoff kappa@zombie.antar.bryansk.ru Alex Perel veers@disturbed.net Alex Varju varju@webct.com Alex Zepeda garbanzo@hooked.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andrey Tchoritch andy@venus.sympad.net Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Ask Bjoern Hansen ask@valueclick.com Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Chapman chapmanb@arches.uga.edu Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher N. Harrell cnh@ivmg.net Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@home.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Cyrille Lefevre clefevre@citeweb.net Cyrus Rahman cr@jcmax.com Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@eece.unm.edu David Borman dab@bsdi.com David W. Chapman Jr. dwcjr@inethouston.net David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Sugar dyfet@gnu.org David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Denis Shaposhnikov dsh@vlink.ru Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dirk Keunecke dk@panda.rhein-main.de Dirk Meyer dirk.meyer@dinoex.sub.org Dirk Nehrling nerle@pdv.de Dishanker Rajakulendren draj@oceanfree.net Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Domas Mituzas midom@dammit.lt Dominik Brettnacher domi@saargate.de Dominik Rothert dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us Donn Miller dmmiller@cvzoom.net Dan Pelleg dpelleg+unison@cs.cmu.edu &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp Eike Bernhardt eike.bernhardt@gmx.de ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eagriff@global2000.net Eric Melville eric@osd.bsdi.com Eric Blood eblood@cs.unr.edu Eric D. Futch efutch@nyct.net Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erich Zigler erich@tacni.net Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@coredumped.null.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp G. Adam Stanislavadam@whizkidtech.net Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Gene Raytsin pal@paladin7.net Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com George Reid services@nevernet.net Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giorgos Keramidas keramida@ceid.upatras.gr Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Lamm holger@eit.uni-kl.de Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilia Chipitsine ilia@jane.cgu.chel.su Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jay Krell jay.krell@cornell.edu Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer jeff@isni.net Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@noc.dfn.d Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Karlson karlj000@unbc.ca Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse McConnell jesse@cylant.com Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Sloan odinn@atlantabiker.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jimmy Olgeni olgeni@uli.it Jin Guojun jin@george.lbl.gov Joachim Kuebart kuebart@mathematik.uni-ulm.de Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Joseph Scott joseph.scott@owp.csus.edu Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jau@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv Justin Stanford jus@security.za.net K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kim Scarborough sluggo@unknown.nu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Herrmann klaus.herrmann@gmx.net Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Konstantin Chuguev Konstantin.Chuguev@dante.org.uk Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Leo Kim leo@florida.sarang.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M. L. Dodson bdodson@scms.utmb.EDU M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Makoto YAMAKURA makoto@pinpott.spnet.ne.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Knight markk@knigma.org Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk Markus Holmberg saska@acc.umu.se Martin Birgmeier Martin Blapp blapp@attic.ch Martin Hinner mhi@linux.gyarab.cz Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masahiro TAKEMURA mastake@msel.t.u-tokyo.ac.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Emmerton root@gabby.gsicomp.on.ca Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Maxime Henrion mhenrion@cybercable.fr Micha Class michael_class@hpbbse.bbn.hp.com Michael Lucas mwlucas@blackhelicopters.org Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Barcroft mike@q9media.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@mired.org Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.algebra.com Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW MITA Yoshio mita@jp.FreeBSD.org Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Ahlstrom nrahlstr@winternet.com Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nicholas Esborn nick@netdot.net Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net &a.nsayer; Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oddbjorn Steffenson oddbjorn@tricknology.org Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Helmling oliver.helmling@stud.uni-bayreuth.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Bihan-Faou patrick@mindstep.com Patrick Hausen unknown Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Per Wigren wigren@home.se Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Peter van Heusden pvh@egenetics.com Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Philippe Lefebvre nemesis@balistik.net Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Rasmus Kaj kaj@Raditex.se Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@enteract.com Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Rod Taylor rod@idiotswitch.org Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Ryuichiro IMURA imura@af.airnet.ne.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey Potapov sp@alkor.ru Sergey Samoyloff gonza@techline.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shinya FUJIE fujie@tk.elec.waseda.ac.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon Dick simond@irrelevant.org Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stijn Hoop stijn@win.tue.nl Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sungman Cho smcho@tsp.korea.ac.kr Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp TAKAHASHI Kaoru kaoru@kaisei.org Takahiro Yugawa yugawa@orleans.rim.or.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas Quinot thomas@cuivre.fr.eu.org Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Tobias Reifenberger treif@mayn.de Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher Tony.Maher@eBioinformatics.com Torbjorn Granlund tege@matematik.su.se Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko SARUMRU mistral@imasy.or.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall ahall@mirapoint.com Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Antony Halse guy@rucus.ru.ac.za Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il diff --git a/en_US.ISO8859-1/books/handbook/disks/chapter.sgml b/en_US.ISO8859-1/books/handbook/disks/chapter.sgml index 025a3d710f..d655eb0007 100644 --- a/en_US.ISO8859-1/books/handbook/disks/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/disks/chapter.sgml @@ -1,901 +1,901 @@ Disks Synopsis This chapter covers how to use disks, whether physical, memory, or networked, on FreeBSD. BIOS Drive Numbering Before you install and configure FreeBSD on your system, there is an important subject that you should be aware of if, especially if you have multiple hard drives. In a PC running DOS or any of the BIOS-dependent operating systems (WINxxx), the BIOS is able to abstract the normal disk drive order, and the operating system goes along with the change. This allows the user to boot from a disk drive other than the so-called primary master. This is especially convenient for some users who have found that the simplest and cheapest way to keep a system backup is to buy an identical second hard drive, and perform routine copies of the first drive to the second drive using Ghost or XCOPY. Then, if the first drive fails, or is attacked by a virus, or is scribbled upon by an operating system defect, he can easily recover by instructing the BIOS to logically swap the drives. It's like switching the cables on the drives, but without having to open the case. More expensive systems with SCSI controllers often include BIOS extensions which allow the SCSI drives to be re-ordered in a similar fashion for up to seven drives. A user who is accustomed to taking advantage of these features may become surprised when the results with FreeBSD are not as expected. FreeBSD does not use the BIOS, and does not know the logical BIOS drive mapping. This can lead to very perplexing situations, especially when drives are physically identical in geometry, and have also been made as data clones of one another. When using FreeBSD, always restore the BIOS to natural drive numbering before installing FreeBSD, and then leave it that way. If you need to switch drives around, then do so, but do it the hard way, and open the case and move the jumpers and cables. An illustration from the files of Bill and Fred's Exceptional Adventures: Bill breaks-down an older Wintel box to make another FreeBSD box for Fred. Bill installs a single SCSI drive as SCSI unit zero, and installs FreeBSD on it. Fred begins using the system, but after several days notices that the older SCSI drive is reporting numerous soft errors, and reports this fact to Bill. After several more days, Bill decides it's time to address the situation, so he grabs an identical SCSI drive from the disk drive "archive" in the back room. An initial surface scan indicates that this drive is functioning well, so Bill installs this drive as SCSI unit four, and makes an image copy from drive zero to drive four. Now that the new drive is installed and functioning nicely, Bill decides that it's a good idea to start using it, so he uses features in the SCSI BIOS to re-order the disk drives so that the system boots from SCSI unit four. FreeBSD boots and runs just fine. Fred continues his work for several days, and soon Bill and Fred decide that it's time for a new adventure -- time to upgrade to a newer version of FreeBSD. Bill removes SCSI unit zero because it was a bit flaky, and replaces it with another identical disk drive from the "archive." Bill then installs the new version of FreeBSD onto the new SCSI unit zero using Fred's magic internet FTP floppies. The installation goes well. Fred uses the new version of FreeBSD for a few days, and certifies that it is good enough for use in the engineering department...it's time to copy all of his work from the old version. So Fred mounts SCSI unit four (the latest copy of the older FreeBSD version). Fred is dismayed to find that none of his precious work is present on SCSI unit four. Where did the data go? When Bill made an image copy of the original SCSI unit zero onto SCSI unit four, unit four became the "new clone," When Bill re-ordered the SCSI BIOS so that he could boot from SCSI unit four, he was only fooling himself. FreeBSD was still running on SCSI unit zero. Making this kind of BIOS change will cause some or all of the Boot and Loader code to be fetched from the selected BIOS drive, but when the FreeBSD kernel drivers take-over, the BIOS drive numbering will be ignored, and FreeBSD will transition back to normal drive numbering. In the illustration at hand, the system continued to operate on the original SCSI unit zero, and all of Fred's data was there, not on SCSI unit four. The fact that the system appeared to be running on SCSI unit four was simply an artifact of human expectations. We are delighted to mention that no data bytes were killed or harmed in any way by our discovery of this phenomenon. The older SCSI unit zero was retrieved from the bone pile, and all of Fred's work was returned to him, (and now Bill knows that he can count as high as zero). Although SCSI drives were used in this illustration, the concepts apply equally to IDE drives. Disk Naming Physical drives come in two main flavors, IDE, or SCSI; but there are also drives backed by RAID controllers, flash memory, and so forth. Since these behave quite differently, they have their own drivers and devices. Physical Disk Naming Conventions Drive type Drive device name IDE hard drives ad in 4.0-RELEASE, wd before 4.0-RELEASE. IDE CDROM drives acd from 3.1-RELEASE, wcd before 4.0-RELEASE. SCSI hard drives da from 3.0-RELEASE, sd before 3.0-RELEASE. SCSI CDROM drives cd Assorted non-standard CDROM drives mcd for Mitsumi CD-ROM, scd for Sony CD-ROM, matcd for Matsushita/Panasonic CD-ROM Floppy drives fd SCSI tape drives sa from 3.0-RELEASE, st before 3.0-RELEASE. IDE tape drives ast from 4.0-RELEASE, wst before 4.0-RELEASE. Flash drives fla for DiskOnChip Flash device from 3.3-RELEASE. RAID drives myxd for Mylex, and amrd for AMI MegaRAID, idad for Compaq Smart RAID. from 4.0-RELEASE. id between 3.2-RELEASE and 4.0-RELEASE.
Slices and Partitions Physical disks usually contain slices, unless they are dangerously dedicated. Slice numbers follow the device name, prefixed with an s: da0s1. Slices, dangerously dedicated physical drives, and other drives contain partitions, which represented as letters from a to h. b is reserved for swap partitions, and c is an unused partition the size of the entire slice or drive. This is explained in . Mounting and Unmounting Filesystems The filesystem is best visualized as a tree, rooted, as it were, at /. /dev, /usr, and the other directories in the root directory are branches, which may have their own branches, such as /usr/local, and so on. There are various reasons to house certain of these directories on separate filesystems. /var contains log, spool, and various types of temporary files, and as such, may get filled up. Filling up the root filesystem isn't a good idea, so splitting /var from / is often a good idea. Another common reason to contain certain directory trees on other filesystems is if they are to be housed on separate physical disks, or are separate virtual disks, such as Network File System mounts, or CDROM drives. The fstab File During the boot process, filesystems listed in /etc/fstab are automatically mounted (unless they are listed with ). The /etc/fstab file contains a list of lines of the following format: device /mount-point fstype options dumpfreq passno device is a device name (which should exist), as explained in the Disk naming conventions above. mount-point is a directory (which should exist), on which to mount the filesystem. fstype is the filesystem type to pass to &man.mount.8;. The default FreeBSD filesystem is ufs. options is either for read-write filesystems, or for read-only filesystems, followed by any other options that may be needed. A common option is for filesystems not normally mounted during the boot sequence. Other options in the &man.mount.8; manual page. dumpfreq is the number of days the filesystem should be dumped, and passno is the pass number during which the filesystem is mounted during the boot sequence. The mount Command The &man.mount.8; command is what is ultimately used to mount filesystems. In its most basic form, you use: &prompt.root; mount device mountpoint There are plenty of options, as mentioned in the &man.mount.8; manual page, but the most common are: mount options Mount all filesystems in /etc/fstab, as modified by , if given. Do everything but actually mount the filesystem. Force the mounting the filesystem. Mount the filesystem read-only. fstype Mount the given filesystem as the given filesystem type, or mount only filesystems of the given type, if given the option. ufs is the default filesystem type. Update mount options on the filesystem. Be verbose. Mount the filesystem read-write. The takes a comma-separated list of the options, including the following: nodev Do not interpret special devices on the filesystem. Useful security option. noexec Do not allow execution of binaries on this filesystem. Useful security option. nosuid Do not interpret setuid or setgid flags on the filesystem. Useful security option. The umount Command The umount command takes, as a parameter, one of a mountpoint, a device name, or the or option. All forms take to force unmounting, and for verbosity. and are used to unmount all mounted filesystems, possibly modified by the filesystem types listed after . , however, doesn't attempt to unmount the root filesystem. Adding Disks Originally contributed by &a.obrien; 26 April 1998 Lets say we want to add a new SCSI disk to a machine that currently only has a single drive. First turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturer. Due the wide variations of procedures to do this, the details are beyond the scope of this document. Login as user root. After you've installed the drive, inspect /var/run/dmesg.boot to ensure the new disk was found. Continuing with our example, the newly added drive will be da1 and we want to mount it on /1 (if you are adding an IDE drive, it will be wd1 in pre-4.0 systems, or ad1 in most 4.X systems). Because FreeBSD runs on IBM-PC compatible computers, it must take into account the PC BIOS partitions. These are different from the traditional BSD partitions. A PC disk has up to four BIOS partition entries. If the disk is going to be truly dedicated to FreeBSD, you can use the dedicated mode. Otherwise, FreeBSD will have to live with in one of the PC BIOS partitions. FreeBSD calls the PC BIOS partitions, slices so as not to confuse them with traditional BSD partitions. You may also use slices on a disk that is dedicated to FreeBSD, but used in a computer that also has another operating system installed. This is to not confuse the fdisk utility of the other operating system. In the slice case the drive will be added as /dev/da1s1e. This is read as: SCSI disk, unit number 1 (second SCSI disk), slice 1 (PC BIOS partition 1), and e BSD partition. In the dedicated case, the drive will be added simply as /dev/da1e. Using sysinstall You may use /stand/sysinstall to partition and label a new disk using its easy to use menus. Either login as user root or use the su command. Run /stand/sysinstall and enter the Configure menu. With in the FreeBSD Configuration Menu, scroll down and select the Partition item. Next you should be presented with a list of hard drives installed in your system. If you do not see da1 listed, you need to recheck your physical installation and dmesg output in the file /var/run/dmesg.boot. Select da1 to enter the FDISK Partition Editor. Choose A to use the entire disk for FreeBSD. When asked if you want to remain cooperative with any future possible operating systems, answer YES. Write the changes to the disk using W. Now exit the FDISK editor using q. Next you will be asked about the Master Boot Record. Since you are adding a disk to an already running system, choose None. Next enter the Disk Label Editor. This is where you will create the traditional BSD partitions. A disk can have up to eight partitions, labeled a-h. A few of the partition labels have special uses. The a partition is used for the root partition (/). Thus only your system disk (e.g, the disk you boot from) should have an a partition. The b partition is used for swap partitions, and you may have many disks with swap partitions. The c partition addresses the entire disk in dedicated mode, or the entire FreeBSD slice in slice mode. The other partitions are for general use. Sysinstall's Label editor favors the e partition for non-root, non-swap partitions. With in the Label editor, create a single file system using C. When prompted if this will be a FS (file system) or swap, choose FS and give a mount point (e.g, /mnt). When adding a disk in post-install mode, Sysinstall will not create entries in /etc/fstab for you, so the mount point you specify isn't important. You are now ready to write the new label to the disk and create a file system on it. Do this by hitting W. Ignore any errors from Sysinstall that it could not mount the new partition. Exit the Label Editor and Sysinstall completely. The last step is to edit /etc/fstab to add an entry for your new disk. Using Command Line Utilities Using Slices This setup will allow your disk to work correctly with other operating systems that might be installed on your computer and will not confuse other operating systems' fdisk utilities. It is recommended to use this method for new disk installs. Only use dedicated mode if you have a good reason to do so! &prompt.root; dd if=/dev/zero of=/dev/rda1 bs=1k count=1 &prompt.root; fdisk -BI da1 #Initialize your new disk &prompt.root; disklabel -B -w -r da1s1 auto #Label it. &prompt.root; disklabel -e da1s1 # Now edit the disklabel you just created and add any partitions. &prompt.root; mkdir -p /1 &prompt.root; newfs /dev/da1s1e # Repeat this for every partition you created. &prompt.root; mount -t ufs /dev/da1s1e /1 # Mount the partition(s) &prompt.root; vi /etc/fstab # When satisfied, add the appropriate entry/entries to your /etc/fstab. - If you have an IDE disk, subsitute ad + If you have an IDE disk, substitute ad for da. On pre-4.x systems use wd. Dedicated If you will not be sharing the new drive with another operating system, you may use the dedicated mode. Remember this mode can confuse Microsoft operating systems; however, no damage will be done by them. IBM's OS/2 however, will appropriate any partition it finds which it doesn't understand. &prompt.root; dd if=/dev/zero of=/dev/rda1 bs=1k count=1 &prompt.root; disklabel -Brw da1 auto &prompt.root; disklabel -e da1 # create the `e' partition &prompt.root; newfs -d0 /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 An alternate method is: &prompt.root; dd if=/dev/zero of=/dev/rda1 count=2 &prompt.root; disklabel /dev/rda1 | disklabel -BrR da1 /dev/stdin &prompt.root; newfs /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 Virtual Disks: Network, Memory, and File-Based Filesystems Besides the disks you physically insert into your computer; floppies, CDs, hard drives, and so forth, other forms of disks are understood by FreeBSD - the virtual disks. These include network filesystems such as the Network Filesystem and Coda, memory-based filesystems such as md and file-backed filesystems created by vnconfig. vnconfig: file-backed filesystem &man.vnconfig.8; configures and enables vnode pseudo disk devices. A vnode is a representation of a file, and is the focus of file activity. This means that &man.vnconfig.8; uses files to create and operate a filesystem. One possible use is the mounting of floppy or CD images kept in files. To mount an existing filesystem image: Using vnconfig to mount an existing filesystem image &prompt.root; vnconfig vn0 diskimage &prompt.root; mount /dev/vn0c /mnt To create a new filesystem image with vnconfig: Creating a New File-Backed Disk with vnconfig &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; vnconfig -s labels -c vn0 newimage &prompt.root; disklabel -r -w vn0 auto &prompt.root; newfs vn0c Warning: 2048 sector(s) in last cylinder unallocated /dev/rvn0c: 10240 sectors in 3 cylinders of 1 tracks, 4096 sectors 5.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 1280 i/g) super-block backups (for fsck -b #) at: 32 &prompt.root; mount /dev/vn0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn0c 4927 1 4532 0% /mnt md: Memory Filesystem md is a simple, efficient means to do memory filesystems. Simply take a filesystem you've prepared with, for example, &man.vnconfig.8;, and: md memory disk &prompt.root; dd if=newimage of=/dev/md0 5120+0 records in 5120+0 records out &prompt.root; mount /dev/md0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0c 4927 1 4532 0% /mnt Disk Quotas Quotas are an optional feature of the operating system that allow you to limit the amount of disk space and/or the number of files a user, or members of a group, may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This will prevent one user from consuming all of the available disk space. Configuring Your System to Enable Disk Quotas Before attempting to use disk quotas it is necessary to make sure that quotas are configured in your kernel. This is done by adding the following line to your kernel configuration file: options QUOTA The stock GENERIC kernel does not have this enabled by default, so you will have to configure, build and install a custom kernel in order to use disk quotas. Please refer to the Configuring the FreeBSD Kernel section for more information on kernel configuration. Next you will need to enable disk quotas in /etc/rc.conf. This is done by adding the line: enable_quotas=YES For finer control over your quota startup, there is an additional configuration variable available. Normally on bootup, the quota integrity of each file system is checked by the quotacheck program. The quotacheck facility insures that the data in the quota database properly reflects the data on the file system. This is a very time consuming process that will significantly affect the time your system takes to boot. If you would like to skip this step, a variable is made available for the purpose: check_quotas=NO If you are running FreeBSD prior to 3.2-RELEASE, the configuration is simpler, and consists of only one variable. Set the following in your /etc/rc.conf: check_quotas=YES Finally you will need to edit /etc/fstab to enable disk quotas on a per-file system basis. This is where you can either enable user or group quotas or both for all of your file systems. To enable per-user quotas on a file system, add the userquota option to the options field in the /etc/fstab entry for the file system you want to to enable quotas on. For example: /dev/da1s2g /home ufs rw,userquota 1 2 Similarly, to enable group quotas, use the groupquota option instead of the userquota keyword. To enable both user and group quotas, change the entry as follows: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 By default the quota files are stored in the root directory of the file system with the names quota.user and quota.group for user and group quotas respectively. See man fstab for more information. Even though that man page says that you can specify an alternate location for the quota files, this is not recommended because the various quota utilities do not seem to handle this properly. At this point you should reboot your system with your new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas you enabled in /etc/fstab, so there is no need to manually create any zero length quota files. In the normal course of operations you should not be required to run the quotacheck, quotaon, or quotaoff commands manually. However, you may want to read their man pages just to be familiar with their operation. Setting Quota Limits Once you have configured your system to enable quotas, verify that they really are enabled. An easy way to do this is to run: &prompt.root; quota -v You should see a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. You are now ready to start assigning quota limits with the edquota command. You have several options on how to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. You may limit allocations based on disk space (block quotas) or number of files (inode quotas) or a combination of both. Each of these limits are further broken down into two categories; hard and soft limits. A hard limit may not be exceeded. Once a user reaches their hard limit they may not make any further allocations on the file system in question. For example, if the user has a hard limit of 500 blocks on a file system and is currently using 490 blocks, the user can only allocate an additional 10 blocks. Attempting to allocate an additional 11 blocks will fail. Soft limits on the other hand can be exceeded for a limited amount of time. This period of time is known as the grace period, which is one week by default. If a user stays over his or her soft limit longer than their grace period, the soft limit will turn into a hard limit and no further allocations will be allowed. When the user drops back below the soft limit, the grace period will be reset. The following is an example of what you might see when you run the edquota command. When the edquota command is invoked, you are placed into the editor specified by the EDITOR environment variable, or in the vi editor if the EDITOR variable is not set, to allow you to edit the quota limits. &prompt.root; edquota -u test Quotas for user test: /usr: blocks in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: blocks in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) You will normally see two lines for each file system that has quotas enabled. One line for the block limits, and one line for inode limits. Simply change the value you want updated to modify the quota limit. For example, to raise this users block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: /usr: blocks in use: 65, limits (soft = 50, hard = 75) to: /usr: blocks in use: 65, limits (soft = 500, hard = 600) The new quota limits will be in place when you exit the editor. Sometimes it is desirable to set quota limits on a range of uids. This can be done by use of the option on the edquota command. First, assign the desired quota limit to a user, and then run edquota -p protouser startuid-enduid. For example, if user test has the desired quota limits, the following command can be used to duplicate those quota limits for uids 10,000 through 19,999: &prompt.root; edquota -p test 10000-19999 See man edquota for more detailed information. Checking Quota Limits and Disk Usage You can use either the quota or the repquota commands to check quota limits and disk usage. The quota command can be used to check individual user and group quotas and disk usage. Only the super-user may examine quotas and usage for other users, or for groups that they are not a member of. The repquota command can be used to get a summary of all quotas and disk usage for file systems with quotas enabled. The following is some sample output from the quota -v command for a user that has quota limits on two file systems. Disk quotas for user test (uid 1002): Filesystem blocks quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 On the /usr file system in the above example this user is currently 15 blocks over their soft limit of 50 blocks and has 5 days of their grace period left. Note the asterisk * which indicates that the user is currently over their quota limit. Normally file systems that the user is not using any disk space on will not show up in the output from the quota command, even if they have a quota limit assigned for that file system. The option will display those file systems, such as the /usr/var file system in the above example. Quotas over NFS Quotas are enforced by the quota subsystem on the NFS server. The &man.rpc.rquotad.8; daemon makes quota information available to the &man.quota.1; command on NFS clients, allowing users on those machines to see their quota statistics. Enable rpc.rquotad in /etc/inetd.conf like so: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Now restart inetd: &prompt.root; kill -HUP `cat /var/run/inetd.pid` diff --git a/en_US.ISO8859-1/books/handbook/install/chapter.sgml b/en_US.ISO8859-1/books/handbook/install/chapter.sgml index 82603eb48b..150bce0340 100644 --- a/en_US.ISO8859-1/books/handbook/install/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/install/chapter.sgml @@ -1,1832 +1,1832 @@ Installing FreeBSD Restructured, updated, and parts rewritten by &a.jim;, January 2000. Synopsis The following chapter will attempt to guide you through the installation of FreeBSD on your system. It can be installed through a variety of methods, including anonymous FTP (assuming you have network connectivity via modem or local network), CDROM, floppy disk, tape, an MS-DOS partition, or even NFS. No matter which method you choose, you will need to get started by creating the installation disks as described in the next section. Booting into the FreeBSD installer, even if you are not planning on installing FreeBSD right away, will provide important information about compatibility with your hardware. This information may dictate which installation options are even possible for you. It can also provide clues early-on in the process to potential problems you may come across later. If you plan to install FreeBSD via anonymous FTP, the only things you will need are the installation floppies. The installation program itself will handle anything else that is required. For more information about obtaining FreeBSD, see the Obtaining FreeBSD section of the Appendix. By now, you are probably wondering what exactly it is you need to do. Continue on to the installation guide. Installation Guide The following sections will guide you through preparing for and actually installing FreeBSD. If you find something missing, please let us know about it by sending email to the &a.doc;. Preparing for the Installation There are various things you should do in preparation for the installation. The following describes what needs to be done prior to each type of installation. The first thing to do is to make sure your hardware is supported by FreeBSD. The list of supported hardware should come in handy here. ;-) It would also be a good idea to make a list of any special cards you have installed, such as SCSI controllers, ethernet cards, sound cards, etc.. The list should include their IRQs and IO port addresses. Creating the Installation Floppies You may need to prepare some floppy disks. These disks will be used to boot your computer in to the FreeBSD install process. This step is not necessary if you are installing from CD-ROM, and your computer supports booting from the CD-ROM. If you do not meet these requirements then you will need to create some floppies to boot from. If you are not sure whether your computer can boot from the CD-ROM it does not hurt to try. Just insert the CD-ROM as normal and restart your computer. You might need to adjust some options in your BIOS so that your computer will try and boot from the CD-ROM drive before the hard disk. Even if you have the CD-ROM it might make sense for you to download the files. There have been occasions where bugs in the FreeBSD installer have been discovered after the CDs have been released. When this happens the copies of the images on the FTP site will be fixed as soon as possible. Obviously, it is not possible to update the CDs after they have been pressed. Acquire the boot floppy images These are files with a .flp extension. If you have a CD-ROM release of FreeBSD then you will find the files in the floppies subdirectory. Alternatively, you can download the images from the floppies directory of the FreeBSD FTP site or your local mirror. The names of the files you will need varies between FreeBSD releases (sometimes) and the architecture you will be installing on. The installation boot image information on the FTP site provides up-to-the-minute information about the specific files you will need. Prepare the floppy disks You must prepare one floppy disk per image file you had to - download. It is imperitive that these disks are free from + download. It is imperative that these disks are free from defects. The easiest way to test this is to format the disks for yourself. Do not trust pre-formatted floppies. If you try to install FreeBSD and the installation program crashes, freezes, or otherwise misbehaves one of the first things to suspect is the floppies. Try writing the floppy image files to some other disks, and try again. Write the image files to the floppy disks. The image files, such as kern.flp, are not regular files you copy to the disk. Instead, they are images of the complete contents of the disk. This means that you can not use commands like DOS' copy to write the files. Instead, you must use specific tools to write the images directly to the disk. If you are creating the floppies on a computer running DOS then we provide a tool to do this called fdimage. If you are using the floppies from the CD-ROM, and your CD-ROM is the E: drive then you would run this: E:\> tools\fdimage floppies\kern.flp A: Repeat this command for each .flp file, replacing the floppy disk each time. Adjust the command line as necessary, depending on where you have placed the .flp files. If you do not have the CD-ROM then fdimage can be downloaded from the tools directory on the FreeBSD FTP site. If you are writing the floppies on a Unix system (such as another FreeBSD system) you can use the &man.dd.1; command to write the image files directly to disk. On FreeBSD you would run: &prompt.root; dd if=kern.flp of=/dev/rfd0 On FreeBSD /dev/rfd0 refers to the first floppy disk (the A: drive). /dev/rfd1 would be the B: drive, and so on. Other Unix variants might have different names for the floppy disk devices, and you will need to check the documentation for the system as necessary. Before Installing from CDROM If your CDROM is of an unsupported type, please skip ahead to the MS-DOS Preparation section. There is not a whole lot of preparation needed if you are installing from one of BSDi's FreeBSD CDROMs (other CDROM distributions may work as well, though we cannot say for certain as we have no hand or say in how they created). You can either boot into the CD installation directly from DOS using the install.bat or you can make floppies with the makeflp.bat command. If the CD has El Torito boot support and your system supports booting directly from the CDROM drive (many older systems do NOT), simply insert the first CD of the set into the drive and reboot your system. You will be put into the installation menu directly from the CD. If you are installing from an MS-DOS partition and have the proper drivers to access your CD, run the install.bat script provided on the CDROM. This will attempt to boot the FreeBSD installation directly from DOS. You must do this from actual DOS (i.e., boot in DOS mode) and not from a DOS window under Windows. For the easiest interface of all (from DOS), type view. This will bring up a DOS menu utility that leads you through all of the available options. If you are creating the boot floppies from a UNIX machine, see the Creating the Boot Floppies section of this guide for examples. Once you have booted from DOS or floppy, you should then be able to select CDROM as the media type during the install process and load the entire distribution from CDROM. No other types of installation media should be required. After your system is fully installed and you have rebooted (from the hard disk), you can mount the CDROM at any time by typing: &prompt.root; mount /cdrom Before removing the CD from the drive again, you must first unmount it. This is done with the following command: &prompt.root; umount /cdrom Do not just remove it from the drive! Before invoking the installation, be sure that the CDROM is in the drive so that the install probe can find it. This is also true if you wish the CDROM to be added to the default system configuration automatically during the installation (whether or not you actually use it as the installation media). Finally, if you would like people to be able to FTP install FreeBSD directly from the CDROM in your machine, you will find it quite easy. After the machine is fully installed, you simply need to add the following line to the password file (using the vipw command): ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent Anyone with network connectivity to your machine can now chose a media type of FTP and type in ftp://your machine after picking Other in the FTP sites menu during the install. If you choose to enable anonymous FTP during the installation of your system, the installation program will do the above for you. Before installing from Floppies If you must install from floppy disk (which we suggest you do NOT do), either due to unsupported hardware or simply because you insist on doing things the hard way, you must first prepare some floppies for the installation. At a minimum, you will need as many 1.44MB or 1.2MB floppies as it takes to hold all the files in the bin (binary distribution) directory. If you are preparing the floppies from DOS, then they MUST be formatted using the MS-DOS FORMAT command. If you are using Windows, use Explorer to format the disks (right-click on the A: drive, and select "Format". Do NOT trust factory pre-formatted floppies! Format them again yourself, just to be sure. Many problems reported by our users in the past have resulted from the use of improperly formatted media, which is why we are making a point of it now. If you are creating the floppies on another FreeBSD machine, a format is still not a bad idea, though you do not need to put a DOS filesystem on each floppy. You can use the disklabel and newfs commands to put a UFS filesystem on them instead, as the following sequence of commands (for a 3.5" 1.44MB floppy) illustrates: &prompt.root; fdformat -f 1440 fd0.1440 &prompt.root; disklabel -w -r fd0.1440 floppy3 &prompt.root; newfs -t 2 -u 18 -l 1 -i 65536 /dev/rfd0 Use fd0.1200 and floppy5 for 5.25" 1.2MB disks. Then you can mount and write to them like any other filesystem. After you have formatted the floppies, you will need to copy the files to them. The distribution files are split into chunks conveniently sized so that 5 of them will fit on a conventional 1.44MB floppy. Go through all your floppies, packing as many files as will fit on each one, until you have all of the distributions you want packed up in this fashion. Each distribution should go into a subdirectory on the floppy, e.g.: a:\bin\bin.aa, a:\bin\bin.ab, and so on. Once you come to the Media screen during the install process, select Floppy and you will be prompted for the rest. Before Installing from MS-DOS To prepare for an installation from an MS-DOS partition, copy the files from the distribution into a directory named, for example, c:\FreeBSD. The directory structure of the CDROM or FTP site must be partially reproduced within this directory, so we suggest using the DOS xcopy command if you are copying it from a CD. For example, to prepare for a minimal installation of FreeBSD: C:\> md c:\FreeBSD C:\> xcopy e:\bin c:\FreeBSD\bin\ /s C:\> xcopy e:\manpages c:\FreeBSD\manpages\ /s Assuming that C: is where you have free space and E: is where your CDROM is mounted. If you do not have a CDROM drive, you can download the distribution from ftp.FreeBSD.org. Each distribution is in its own directory; for example, the bin distribution can be found in the &rel.current;/bin directory. For as many distributions you wish to install from an MS-DOS partition (and you have the free space for), install each one under c:\FreeBSD — the BIN distribution is the only one required for a minimum installation. Before Installing from QIC/SCSI Tape Installing from tape is probably the easiest method, short of an online FTP install or CDROM install. The installation program expects the files to be simply tarred onto the tape, so after getting all of the distribution files you are interested in, simply tar them onto the tape like so: &prompt.root; cd /freebsd/distdir &prompt.root; tar cvf /dev/rwt0 dist1 ... dist2 When you go to do the installation, you should also make sure that you leave enough room in some temporary directory (which you will be allowed to choose) to accommodate the full contents of the tape you have created. Due to the non-random access nature of tapes, this method of installation requires quite a bit of temporary storage. You should expect to require as much temporary storage as you have stuff written on tape. When starting the installation, the tape must be in the drive before booting from the boot floppy. The installation probe may otherwise fail to find it. Before Installing over a Network There are three types of network installations you can do. Serial port (SLIP or PPP), Parallel port (PLIP (laplink cable)), or Ethernet (a standard ethernet controller (includes some PCMCIA)). The SLIP support is rather primitive, and limited primarily to hard-wired links, such as a serial cable running between a laptop computer and another computer. The link should be hard-wired as the SLIP installation does not currently offer a dialing capability; that facility is provided with the PPP utility, which should be used in preference to SLIP whenever possible. If you are using a modem, then PPP is almost certainly your only choice. Make sure that you have your service provider's information handy as you will need to know it fairly early in the installation process. If you use PAP or CHAP to connect your ISP (in other words, if you can connect to the ISP in Windows without using a script), then all you will need to do is type in dial at the ppp prompt. Otherwise, you will need to know how to dial your ISP using the AT commands specific to your modem, as the PPP dialer provides only a very simple terminal emulator. Please to the user-ppp handbook and FAQ entries for further information. If you have problems, logging can be directed to the screen using the command set log local .... If a hard-wired connection to another FreeBSD (2.0-R or later) machine is available, you might also consider installing over a laplink parallel port cable. The data rate over the parallel port is much higher than what is typically possible over a serial line (up to 50kbytes/sec), thus resulting in a quicker installation. Finally, for the fastest possible network installation, an ethernet adapter is always a good choice! FreeBSD supports most common PC ethernet cards; a table of supported cards (and their required settings) is provided in the Supported Hardware list. If you are using one of the supported PCMCIA ethernet cards, also be sure that it is plugged in before the laptop is powered on! FreeBSD does not, unfortunately, currently support hot insertion of PCMCIA cards during installation. You will also need to know your IP address on the network, the netmask value for your address class, and the name of your machine. If you are installing over a PPP connection and do not have a static IP, fear not, the IP address can be dynamically assigned by your ISP. Your system administrator can tell you which values to use for your particular network setup. If you will be referring to other hosts by name rather than IP address, you will also need a name server and possibly the address of a gateway (if you are using PPP, it is your provider's IP address) to use in talking to it. If you want to install by FTP via a HTTP proxy (see below), you will also need the proxy's address. If you do not know the answers to all or most of these questions, then you should really probably talk to your system administrator or ISP before trying this type of installation. Before Installing via NFS The NFS installation is fairly straight-forward. Simply copy the FreeBSD distribution files you want onto a server somewhere and then point the NFS media selection at it. If this server supports only privileged port (as is generally the default for Sun workstations), you will need to set this option in the Options menu before installation can proceed. If you have a poor quality ethernet card which suffers from very slow transfer rates, you may also wish to toggle the appropriate Options flag. In order for NFS installation to work, the server must support subdir mounts, e.g., if your FreeBSD 3.4 distribution directory lives on:ziggy:/usr/archive/stuff/FreeBSD, then ziggy will have to allow the direct mounting of /usr/archive/stuff/FreeBSD, not just /usr or /usr/archive/stuff. In FreeBSD's /etc/exports file, this is controlled by the . Other NFS servers may have different conventions. If you are getting permission denied messages from the server, then it is likely that you do not have this enabled properly. Before Installing via FTP FTP installation may be done from any FreeBSD mirror site containing a reasonably up-to-date version of FreeBSD. A full list of FTP mirrors located all over the world is provided during the install process. If you are installing from an FTP site not listed in this menu, or are having trouble getting your name server configured properly, you can also specify a URL to use by selecting the choice labeled Other in that menu. You can also use the IP address of a machine you wish to install from, so the following would work in the absence of a name server: ftp://209.55.82.20/pub/FreeBSD/&rel.current;-RELEASE There are three FTP installation modes you can choose from: active or passive FTP or via a HTTP proxy. FTP Active This option will make all FTP transfers use Active mode. This will not work through firewalls, but will often work with older FTP servers that do not support passive mode. If your connection hangs with passive mode (the default), try active! FTP Passive This option instructs FreeBSD to use Passive mode for all FTP operations. This allows the user to pass through firewalls that do not allow incoming connections on random port addresses. FTP via a HTTP proxy This option instructs FreeBSD to use the HTTP protocol (like a web browser) to connect to a proxy for all FTP operations. The proxy will translate the requests and send them to the FTP server. This allows the user to pass through firewalls that do not allow FTP at all, but offer a HTTP proxy. In this case, you have to specify the proxy in addition to the FTP server. There is another type of FTP proxy other tha HTTP proxies. This type is very uncommon, though. If you are not absolutely certain, you can assume that you have a HTTP proxy as described above. For a proxy FTP server, you should usually give the name of the server you really want as a part of the username, after an @ sign. The proxy server then fakes the real server. For example, assuming you want to install from ftp.FreeBSD.org, using the proxy FTP server foo.bar.com, listening on port 1024. In this case, you go to the options menu, set the FTP username to ftp@ftp.FreeBSD.org, and the password to your email address. As your installation media, you specify FTP (or passive FTP, if the proxy supports it), and the URL ftp://foo.bar.com:1234/pub/FreeBSD. Since /pub/FreeBSD from ftp.FreeBSD.org is proxied under foo.bar.com, you are able to install from that machine (which will fetch the files from ftp.FreeBSD.org as your installation requests them. Check your BIOS drive numbering If you have used features in your BIOS to renumber your disk - drives without recabling them then you should read first to avoid confusion. Installing FreeBSD Once you have completed the pre-installation step relevant to your situation, you are ready to install FreeBSD! Although you should not experience any difficulty, there is always the chance that you may, no matter how slight it is. If this is the case in your situation, then you may wish to go back and re-read the relevant preparation section or sections. Perhaps you will come across something you missed the first time. If you are having hardware problems, or FreeBSD refuses to boot at all, read the Hardware Guide for a list of possible solutions. The FreeBSD boot floppies contain all of the online documentation you should need to be able to navigate through an installation. If it does not, please let us know what you found to be the most confusing or most lacking. Send your comments to the &a.doc;. It is the objective of the installation program (sysinstall) to be self-documenting enough that painful step-by-step guides are no longer necessary. It may take us a little while to reach that objective, but nonetheless, it is still our objective :-) Meanwhile, you may also find the following typical installation sequence to be helpful: Boot the kern.flp floppy and when asked, remove it and insert the mfsroot.flp and hit return. After a boot sequence which can take anywhere from 30 seconds to 3 minutes, depending on your hardware, you should be presented with a menu of initial choices. If the kern.flp floppy does not boot at all or the boot hangs at some stage, read the Q&A section of the Hardware Guide for possible causes. Press F1. You should see some basic usage instructions on the menu screen and general navigation. If you have not used this menu system before then please read this thoroughly. Select the Options item and set any special preferences you may have. Select a Standard, Express, or Custom install, depending on whether or not you would like the installation to help you through a typical installation, give you a high degree of control over each step, or simply whiz through it (using reasonable defaults when possible) as fast as possible. If you have never used FreeBSD before, the Standard installation method is most recommended. The final configuration menu choice allows you to further configure your FreeBSD installation by giving you menu-driven access to various system defaults. Some items, like networking, may be especially important if you did a CDROM, tape, or floppy install and have not yet configured your network interfaces (assuming you have any). Properly configuring such interfaces here will allow FreeBSD to come up on the network when you first reboot from the hard disk. Supported Hardware FreeBSD currently runs on a wide variety of ISA, VLB, EISA, and PCI bus based PCs, ranging from the 386SX to Pentium class machines (though the 386SX is not recommended). Support for generic IDE or ESDI drive configurations, various SCSI controllers, and network and serial cards is also provided. FreeBSD also supports IBM's microchannel (MCA) bus. In order to run FreeBSD, a recommended minimum of eight megabytes of RAM is suggested. Sixteen megabytes is the preferred amount of RAM as you may have some trouble with anything less than sixteen depending on your hardware. What follows is a list of hardware currently known to work with FreeBSD. There may be other hardware that works as well, but we have simply not received any confirmation of it. Disk Controllers WD1003 (any generic MFM/RLL) WD1007 (any generic IDE/ESDI) IDE ATA Adaptec 1535 ISA SCSI controllers Adaptec 154X series ISA SCSI controllers Adaptec 174X series EISA SCSI controllers in standard and enhanced mode Adaptec 274X/284X/2920C/294X/2950/3940/3950 (Narrow/Wide/Twin) series EISA/VLB/PCI SCSI controllers Adaptec AIC-7850, AIC-7860, AIC-7880, AIC-789X on-board SCSI controllers Adaptec 1510 series ISA SCSI controllers (not for bootable devices) Adaptec 152X series ISA SCSI controllers Adaptec AIC-6260 and AIC-6360 based boards, which include the AHA-152X and SoundBlaster SCSI cards AdvanSys SCSI controllers (all models) BusLogic MultiMaster W Series Host Adapters including BT-948, BT-958, BT-9580 BusLogic MultiMaster C Series Host Adapters including BT-946C, BT-956C, BT-956CD, BT-445C, BT-747C, BT-757C, BT-757CD, BT-545C, BT-540CF BusLogic MultiMaster S Series Host Adapters including BT-445S, BT-747S, BT-747D, BT-757S, BT-757D, BT-545S, BT-542D, BT-742A, BT-542B BusLogic MultiMaster A Series Host Adapters including BT-742A, BT-542B AMI FastDisk controllers that are true BusLogic MultiMaster clones are also supported. BusLogic/Mylex Flashpoint adapters are NOT yet supported. DPT SmartCACHE Plus, SmartCACHE III, SmartRAID III, SmartCACHE IV, and SmartRAID IV SCSI/RAID are supported. The DPT SmartRAID/CACHE V is not yet supported. The DPT PM3754U2-16M SCSI RAID Controller is also supported. Compaq Intelligent Disk Array Controllers: IDA, IDA-2, IAES, SMART, SMART-2/E, Smart-2/P, SMART-2SL, Integrated Array, and Smart Arrays 3200, 3100ES, 221, 4200, 4200, 4250ES. SymBios (formerly NCR) 53C810, 53C810a, 53C815, 53C820, 53C825a, 53C860, 53C875, 53C875j, 53C885, and 53C896 PCI SCSI controllers including ASUS SC-200, Data Technology DTC3130 (all variants), Diamond FirePort (all), NCR cards (all), SymBios cards (all), Tekram DC390W, 390U, and 390F, and Tyan S1365 QLogic 1020, 1040, 1040B, and 2100 SCSI and Fibre Channel Adapters DTC 3290 EISA SCSI controller in 1542 evaluation mode With all supported SCSI controllers, full support is provided for SCSI-I and SCSI-II peripherals, including hard disks, optical disks, tape drives (including DAT and 8mm Exabyte), medium changers, processor target devices, and CDROM drives. WORM devices that support CDROM commands are supported for read-only access by the CDROM driver. WORM/CD-R/CD-RW writing support is provided by cdrecord, which is in the ports tree. The following CD-ROM type systems are supported at this time: cd - SCSI interface (includes ProAudio Spectrum and SoundBlaster SCSI) matcd - Matsushita/Panasonic - (Creative Soundblaster) proprietary interface (562/563 + (Creative SoundBlaster) proprietary interface (562/563 models) scd - Sony proprietary interface (all models) acd - ATAPI IDE interface The following drivers were supported under the old SCSI subsystem, but are NOT YET supported under the new CAM SCSI subsystem: NCR5380/NCR53400 (ProAudio Spectrum) SCSI controller UltraStor 14F, 24F, and 34F SCSI controllers Seagate ST01/02 SCSI controllers Future Domain 8XX/950 series SCSI controllers WD7000 SCSI controller There is work-in-progress to port the UltraStor driver to the new CAM framework, but no estimates on when or if it will be completed. Unmaintained drivers, which might or might not work for your hardware: Floppy tape interface (Colorado/Mountain/Insight) mcd - Mitsumi proprietary CD-ROM interface (all models) Network Cards Adaptec Duralink PCI fast ethernet adapters based on the Adaptec AIC-6195 fast ethernet controller chip, including the following: ANA-62011 64-bit single port 10/100baseTX adapter ANA-62022 64-bit dual port 10/100baseTX adapter ANA-62044 64-bit quad port 10/100baseTX adapter ANA-69011 32-bit single port 10/100baseTX adapter ANA-62020 64-bit single port 100baseFX adapter Allied-Telesyn AT1700 and RE2000 cards Alteon Networks PCI gigabit ethernet NICs based on the Tigon 1 and Tigon 2 chipsets including the Alteon AceNIC (Tigon 1 and 2), 3Com 3c985-SX (Tigon 1 and 2), Netgear GA620 (Tigon 2), Silicon Graphics Gigabit Ethernet, DEC/Compaq EtherWORKS 1000, NEC Gigabit Ethernet AMD PCnet/PCI (79c970 and 53c974 or 79c974) RealTek 8129/8139 fast ethernet NICs including the following: Allied-Telesyn AT2550 Allied-Telesyn AT2500TX Genius GF100TXR (RTL8139) NDC Communications NE100TX-E OvisLink LEF-8129TX OvisLink LEF-8139TX Netronix Inc. EA-1210 NetEther 10/100 KTX-9130TX 10/100 Fast Ethernet Accton Cheetah EN1207D (MPX 5030/5038; RealTek 8139 clone) SMC EZ Card 10/100 PCI 1211-TX Lite-On 98713, 98713A, 98715, and 98725 fast ethernet NICs, including the LinkSys EtherFast LNE100TX, NetGear FA310-TX Rev. D1, Matrox FastNIC 10/100, Kingston KNE110TX Macronix 98713, 98713A, 98715, 98715A, and 98725 fast ethernet NICs including the NDC Communications SFA100A (98713A), CNet Pro120A (98713 or 98713A), CNet Pro120B (98715), SVEC PN102TX (98713) Macronix/Lite-On PNIC II LC82C115 fast ethernet NICs including the LinkSys EtherFast LNE100TX version 2 Winbond W89C840F fast ethernet NICs including the Trendware TE100-PCIE VIA Technologies VT3043 Rhine I and VT86C100A Rhine II fast ethernet NICs including the Hawking Technologies PN102TX and D-Link DFE-530TX Silicon Integrated Systems SiS 900 and SiS 7016 PCI fast ethernet NICs Sundance Technologies ST201 PCI fast ethernet NICs including the D-Link DFE-550TX SysKonnect SK-984x PCI gigabit ethernet cards including the SK-9841 1000baseLX (single mode fiber, single port), the SK-9842 1000baseSX (multimode fiber, single port), the SK-9843 1000baseLX (single mode fiber, dual port), and the SK-9844 1000baseSX (multimode fiber, dual port). Texas Instruments ThunderLAN PCI NICs, including the Compaq Netelligent 10, 10/100, 10/100 Proliant, 10/100 Dual-Port, 10/100 TX Embedded UTP, 10 T PCI UTP/Coax, and 10/100 TX UTP, the Compaq NetFlex 3P, 3P Integrated, and 3P w/BNC, the Olicom OC-2135/2138, OC-2325, OC-2326 10/100 TX UTP, and the Racore 8165 10/100baseTX and 8148 10baseT/100baseTX/100baseFX multi-personality cards ADMtek AL981-based and AN985-based PCI fast ethernet NICs ASIX Electronics AX88140A PCI NICs including the Alfa Inc. GFC2204 and CNet Pro110B DEC EtherWORKS III NICs (DE203, DE204, and DE205) DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) DEC DC21040, DC21041, or DC21140 based NICs (SMC Etherpower 8432T, DE245, etc.) DEC FDDI (DEFPA/DEFEA) NICs Efficient ENI-155p ATM PCI FORE PCA-200E ATM PCI Fujitsu MB86960A/MB86965A HP PC Lan+ cards (model numbers: 27247B and 27252A) Intel EtherExpress ISA (not recommended due to driver instability) Intel EtherExpress Pro/10 Intel EtherExpress Pro/100B PCI Fast Ethernet Isolan AT 4141-0 (16 bit) Isolink 4110 (8 bit) Novell NE1000, NE2000, and NE2100 Ethernet interfaces PCI network cards emulating the NE2000, including the RealTek 8029, NetVin 5000, Winbond W89C940, Surecom NE-34, VIA VT86C926 3Com 3C501, 3C503 Etherlink II, 3C505 Etherlink/+, 3C507 Etherlink 16/TP, 3C509, 3C579, 3C589 (PCMCIA), 3C590/592/595/900/905/905B/905C PCI and EISA (Fast) Etherlink III / (Fast) Etherlink XL, 3C980/3C980B Fast Etherlink XL server adapter, 3CSOHO100-TX OfficeConnect adapter Toshiba ethernet cards PCMCIA ethernet cards from IBM and National Semiconductor are also supported USB Peripherals A wide range of USB peripherals are supported. Owing to the generic nature of most USB devices, with some exceptions any device of a given class will be supported even if not explicitly listed here. USB keyboards USB mice USB printers and USB to parallel printer conversion cables USB hubs Motherboard chipsets: ALi Aladdin-V Intel 82371SB (PIIX3) and 82371AB and EB (PIIX4) chipsets NEC uPD 9210 Host Controller VIA 83C572 USB Host Controller and any other UHCI or OHCI compliant motherboard chipset (no exceptions known). PCI plug-in USB host controllers ADS Electronics PCI plug-in card (2 ports) Entrega PCI plug-in card (4 ports) Specific USB devices reported to be working: Agiler Mouse 29UO Andromeda hub Apple iMac mouse and keyboard ATen parallel printer adapter Belkin F4U002 parallel printer adapter and Belkin mouse BTC BTC7935 keyboard with mouse port Cherry G81-3504 Chic mouse Cypress mouse Entrega USB-to-parallel printer adapter Genius Niche mouse Iomega USB Zip 100 MB Kensington Mouse-in-a-Box Logitech M2452 keyboard Logictech wheel mouse (3 buttons) Logitech PS/2 / USB mouse (3 buttons) MacAlly mouse (3 buttons) MacAlly self-powered hub (4 ports) Microsoft Intellimouse (3 buttons) Microsoft keyboard NEC hub Trust Ami Mouse (3 buttons) ISDN (European DSS1 [Q.921/Q.931] protocol) Asuscom I-IN100-ST-DV (experimental, may work) Asuscom ISDNlink 128K AVM A1 AVM Fritz!Card classic AVM Fritz!Card PCI AVM Fritz!Card PCMCIA (currently FreeBSD 3.x only) AVM Fritz!Card PnP (currently FreeBSD 3.x only) Creatix ISDN-S0/8 Creatix ISDN-S0/16 Creatix ISDN-S0 PnP Dr.Neuhaus Niccy 1008 Dr.Neuhaus Niccy 1016 Dr.Neuhaus Niccy GO@ (ISA PnP) Dynalink IS64PH (no longer maintained) ELSA 1000pro ISA ELSA 1000pro PCI ELSA PCC-16 ITK ix1 micro (currently FreeBSD 3.x only) ITK ix1 micro V.3 (currently FreeBSD 3.x only) Sagem Cybermod (ISA PnP, may work) Sedlbauer Win Speed Siemens I-Surf 2.0 Stollman Tina-pp (under development) Teles S0/8 Teles S0/16 Teles S0/16.3 (the c Versions - like 16.3c - are unsupported!) Teles S0 PnP (experimental, may work) 3Com/USRobotics Sportster ISDN TA intern (non-PnP version) Sound Devices The following soundcards or codecs are supported (devices marked 'experimental' are only supported in FreeBSD-CURRENT and might work only unstably): 16550 UART (Midi) (experimental, needs a trick in the hints file) Advance Asound 100, 110 and Logic ALS120 Aureal Vortex1/Vortex2 and Vortex Advantage based soundcards by a third party driver Creative Labs SB16, SB32, SB AWE64 (including Gold), Vibra16, SB PCI (experimental), SB Live! (experimental) and most SoundBlaster compatible cards Creative Labs SB Midi Port (experimental), SB OPL3 Synthesizer (experimental) Crystal Semiconductor CS461x/462x Audio Accelerator, the support for the CS461x Midi port is experimental Crystal Semiconductor CS428x Audio Controller CS4237, CS4236, CS4232, CS4231 (ISA) ENSONIQ AudioPCI ES1370/1371 ESS ES1868, ES1869, ES1879, ES1888 Gravis UltraSound PnP, MAX NeoMagic 256AV/ZX (PCI) OPTi931 (ISA) OSS-compatible sequencer (Midi) (experimental) Trident 4DWave DX/NX (PCI) Yahama OPL-SAx (ISA) Miscellaneous Devices AST 4 port serial card using shared IRQ ARNET 8 port serial card using shared IRQ ARNET (now Digiboard) Sync 570/i high-speed serial Boca BB1004 4-Port serial card (Modems NOT supported) Boca IOAT66 6-Port serial card (Modems supported) Boca BB1008 8-Port serial card (Modems NOT supported) Boca BB2016 16-Port serial card (Modems supported) Cyclades Cyclom-y Serial Board Moxa SmartIO CI-104J 4-Port serial card STB 4 port card using shared IRQ SDL Communications RISCom/8 Serial Board SDL Communications RISCom/N2 and N2pci high-speed sync serial boards Specialix SI/XIO/SX multiport serial cards, with both the older SIHOST2.x and the new enhanced (transputer based, aka JET) host cards; ISA, EISA and PCI are supported Stallion multiport serial boards: EasyIO, EasyConnection 8/32 & 8/64, ONboard 4/16 and Brumby Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound, and Roland MPU-401 sound cards Connectix QuickCam Matrox Meteor Video frame grabber Creative Labs Video Spigot frame grabber Cortex1 frame grabber Various frame grabbers based on the Brooktree Bt848 and Bt878 chip HP4020, HP6020, Philips CDD2000/CDD2660 and Plasmon CD-R drives Bus mice PS/2 mice Standard PC Joystick X-10 power controllers GPIB and Transputer drives Genius and Mustek hand scanners Floppy tape drives (some rather old models only, driver is rather stale) Lucent Technologies WaveLAN/IEEE 802.11 PCMCIA and ISA standard speed (2Mbps) and turbo speed (6Mbps) wireless network adapters and workalikes (NCR WaveLAN/IEEE 802.11, Cabletron RoamAbout 802.11 DS) The ISA versions of these adapters are actually PCMCIA cards combined with an ISA to PCMCIA bridge card, so both kinds of devices work with the same driver. Troubleshooting The following section covers basic installation troubleshooting, such as common problems people have reported. There are also a few questions and answers for people wishing to dual-boot FreeBSD with MS-DOS. What to do if something goes wrong... Due to various limitations of the PC architecture, it is impossible for probing to be 100% reliable, however, there are a few things you can do if it fails. Check the supported hardware list to make sure your hardware is supported. If your hardware is supported and you still experience lock-ups or other problems, reset your computer, and when the visual kernel configuration option is given, choose it. This will allow you to go through your hardware and supply information to the system about it. The kernel on the boot disks is configured assuming that most hardware devices are in their factory default configuration in terms of IRQs, IO addresses, and DMA channels. If your hardware has been reconfigured, you will most likely need to use the configuration editor to tell FreeBSD where to find things. It is also possible that a probe for a device not present will cause a later probe for another device that is present to fail. In that case, the probes for the conflicting driver(s) should be disabled. Do not disable any drivers you will need during the installation, such as your screen (sc0). If the installation wedges or fails mysteriously after leaving the configuration editor, you have probably removed or changed something you should not have. Reboot and try again. In configuration mode, you can: List the device drivers installed in the kernel. Change device drivers for hardware that is not present in your system. Change IRQs, DRQs, and IO port addresses used by a device driver. After adjusting the kernel to match your hardware configuration, type Q to boot with the new settings. Once the installation has completed, any changes you made in the configuration mode will be permanent so you do not have to reconfigure every time you boot. It is still highly likely that you will eventually want to build a custom kernel. MS-DOS User's Questions and Answers Many users wish to install FreeBSD on PCs inhabited by MS-DOS. Here are some commonly asked questions about installing FreeBSD on such systems. Help, I have no space! Do I need to delete everything first? If your machine is already running MS-DOS and has little or no free space available for the FreeBSD installation, all hope is not lost! You may find the FIPS utility, provided in the tools directory on the FreeBSD CDROM or various FreeBSD FTP sites to be quite useful. FIPS allows you to split an existing MS-DOS partition into two pieces, preserving the original partition and allowing you to install onto the second free piece. You first defragment your MS-DOS partition using the Windows DEFRAG utility (go into Explorer, right-click on the hard drive, and choose to defrag your hard drive), or Norton Disk Tools. You then must run FIPS. It will prompt you for the rest of the information it needs. Afterwards, you can reboot and install FreeBSD on the new free slice. See the Distributions menu for an estimate of how much free space you will need for the kind of installation you want. There is also a very useful product from PowerQuest called Partition Magic. This application has far more functionality than FIPS, and is highly recommended if you plan to often add/remove operating systems (like me). However, it does cost money, and if you plan to install FreeBSD once and then leave it there, FIPS will probably be fine for you. Can I use compressed MS-DOS filesystems from FreeBSD? No. If you are using a utility such as Stacker(tm) or DoubleSpace(tm), FreeBSD will only be able to use whatever portion of the filesystem you leave uncompressed. The rest of the filesystem will show up as one large file (the stacked/double spaced file!). Do not remove that file or you will probably regret it greatly! It is probably better to create another uncompressed primary MS-DOS partition and use this for communications between MS-DOS and FreeBSD. Can I mount my extended MS-DOS partition? Yes. DOS extended partitions are mapped in at the end of the other slices in FreeBSD, e.g., your D: drive might be /dev/da0s5, your E: drive, /dev/da0s6, and so on. This example assumes, of course, that your extended partition is on SCSI drive 0. For IDE drives, substitute ad for da appropriately if installing 4.0-RELEASE or later, and substitute wd for da if you are installing a version of FreeBSD prior to 4.0. You otherwise mount extended partitions exactly like you would any other DOS drive, for example: &prompt.root; mount -t msdos /dev/ad0s5 /dos_d diff --git a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml index 32c941bb80..56f2ee039b 100644 --- a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,2746 +1,2746 @@ Advanced Networking Synopsis The following chapter will cover some of the more frequently used network services on UNIX systems. This, of course, will pertain to configuring said services on your FreeBSD system. Gateways and Routes Contributed by &a.gryphon;. 6 October 1995. For one machine to be able to find another, there must be a mechanism in place to describe how to get from one to the other. This is called Routing. A route is a defined pair of addresses: a destination and a gateway. The pair indicates that if you are trying to get to this destination, send along through this gateway. There are three types of destinations: individual hosts, subnets, and default. The default route is used if none of the other routes apply. We will talk a little bit more about default routes later on. There are also three types of gateways: individual hosts, interfaces (also called links), and ethernet hardware addresses. An example To illustrate different aspects of routing, we will use the following example which is the output of the command netstat -r: Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 foobar.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.foobar.com link#1 UC 0 0 224 link#1 UC 0 0 The first two lines specify the default route (which we will cover in the next section) and the localhost route. The interface (Netif column) that it specifies to use for localhost is lo0, also known as the loopback device. This says to keep all traffic for this destination internal, rather than sending it out over the LAN, since it will only end up back where it started anyway. The next thing that stands out are the 0:e0:... addresses. These are ethernet hardware addresses. FreeBSD will automatically identify any hosts (test0 in the example) on the local ethernet and add a route for that host, directly to it over the ethernet interface, ed0. There is also a timeout (Expire column) associated with this type of route, which is used if we fail to hear from the host in a specific amount of time. In this case the route will be automatically deleted. These hosts are identified using a mechanism known as RIP (Routing Information Protocol), which figures out routes to local hosts based upon a shortest path determination. FreeBSD will also add subnet routes for the local subnet (10.20.30.255 is the broadcast address for the subnet 10.20.30, and foobar.com is the domain name associated with that subnet). The designation link#1 refers to the first ethernet card in the machine. You will notice no additional interface is specified for those. Both of these groups (local network hosts and local subnets) have their routes automatically configured by a daemon called routed. If this is not run, then only routes which are statically defined (ie. entered explicitly) will exist. The host1 line refers to our host, which it knows by ethernet address. Since we are the sending host, FreeBSD knows to use the loopback interface (lo0) rather than sending it out over the ethernet interface. The two host2 lines are an example of what happens when we use an ifconfig alias (see the section of ethernet for reasons why we would do this). The => symbol after the lo0 interface says that not only are we using the loopback (since this is address also refers to the local host), but specifically it is an alias. Such routes only show up on the host that supports the alias; all other hosts on the local network will simply have a link#1 line for such. The final line (destination subnet 224) deals with MultiCasting, which will be covered in a another section. The other column that we should talk about are the Flags. Each route has different attributes that are described in the column. Below is a short table of some of these flags and their meanings: U Up: The route is active. H Host: The route destination is a single host. G Gateway: Send anything for this destination on to this remote system, which will figure out from there where to send it. S Static: This route was configured manually, not automatically generated by the system. C Clone: Generates a new route based upon this route for machines we connect to. This type of route is normally used for local networks. W WasCloned: Indicated a route that was auto-configured based upon a local area network (Clone) route. L Link: Route involves references to ethernet hardware. Default routes When the local system needs to make a connection to remote host, it checks the routing table to determine if a known path exists. If the remote host falls into a subnet that we know how to reach (Cloned routes), then the system checks to see if it can connect along that interface. If all known paths fail, the system has one last option: the default route. This route is a special type of gateway route (usually the only one present in the system), and is always marked with a c in the flags field. For hosts on a local area network, this gateway is set to whatever machine has a direct connection to the outside world (whether via PPP link, or your hardware device attached to a dedicated data line). If you are configuring the default route for a machine which itself is functioning as the gateway to the outside world, then the default route will be the gateway machine at your Internet Service Provider's (ISP) site. Let us look at an example of default routes. This is a common configuration: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] The hosts Local1 and Local2 are at your site, with the formed being your PPP connection to your ISP's Terminal Server. Your ISP has a local network at their site, which has, among other things, the server where you connect and a hardware device (T1-GW) attached to the ISP's Internet feed. The default routes for each of your machines will be: host default gateway interface Local2 Local1 ethernet Local1 T1-GW PPP A common question is Why (or how) would we set the T1-GW to be the default gateway for Local1, rather than the ISP server it is connected to?. Remember, since the PPP interface is using an address on the ISP's local network for your side of the connection, routes for any other machines on the ISP's local network will be automatically generated. Hence, you will already know how to reach the T1-GW machine, so there is no need for the intermediate step of sending traffic to the ISP server. As a final note, it is common to use the address ...1 as the gateway address for your local network. So (using the same example), if your local class-C address space was 10.20.30 and your ISP was using 10.9.9 then the default routes would be: Local2 (10.20.30.2) --> Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) Dual homed hosts There is one other type of configuration that we should cover, and that is a host that sits on two different networks. Technically, any machine functioning as a gateway (in the example above, using a PPP connection) counts as a dual-homed host. But the term is really only used to refer to a machine that sits on two local-area networks. In one case, the machine as two ethernet cards, each having an address on the separate subnets. Alternately, the machine may only have one ethernet card, and be using ifconfig aliasing. The former is used if two physically separate ethernet networks are in use, the latter if there is one physical network segment, but two logically separate subnets. Either way, routing tables are set up so that each subnet knows that this machine is the defined gateway (inbound route) to the other subnet. This configuration, with the machine acting as a Bridge between the two subnets, is often used when we need to implement packet filtering or firewall security in either or both directions. Routing propagation We have already talked about how we define our routes to the outside world, but not about how the outside world finds us. We already know that routing tables can be set up so that all traffic for a particular address space (in our examples, a class-C subnet) can be sent to a particular host on that network, which will forward the packets inbound. When you get an address space assigned to your site, your service provider will set up their routing tables so that all traffic for your subnet will be sent down your PPP link to your site. But how do sites across the country know to send to your ISP? There is a system (much like the distributed DNS information) that keeps track of all assigned address-spaces, and defines their point of connection to the Internet Backbone. The Backbone are the main trunk lines that carry Internet traffic across the country, and around the world. Each backbone machine has a copy of a master set of tables, which direct traffic for a particular network to a specific backbone carrier, and from there down the chain of service providers until it reaches your network. It is the task of your service provider to advertise to the backbone sites that they are the point of connection (and thus the path inward) for your site. This is known as route propagation. Troubleshooting Sometimes, there is a problem with routing propagation, and some sites are unable to connect to you. Perhaps the most useful command for trying to figure out where a routing is breaking down is the &man.traceroute.8; command. It is equally useful if you cannot seem to make a connection to a remote machine (i.e. &man.ping.8; fails). The &man.traceroute.8; command is run with the name of the remote host you are trying to connect to. It will show the gateway hosts along the path of the attempt, eventually either reaching the target host, or terminating because of a lack of connection. For more information, see the manual page for &man.traceroute.8;. Bridging Written by Steve Peterson steve@zpfe.com. Introduction It is sometimes useful to divide one physical network (i.e., an Ethernet segment) into two separate network segments, without having to create IP subnets and use a router to connect the segments together. A device that connects two networks together in this fashion is called a bridge. and a FreeBSD system with two network interface cards can act as a bridge. The bridge works by learning the MAC layer addresses (i.e., Ethernet addresses) of the devices on each of its network interfaces. It forwards traffic between two networks only when its source and destination are on different networks. In many respects, a bridge is like an Ethernet switch with very few ports. Situations where bridging is appropriate There are two common situations in which a bridge is used today. High traffic on a segment Situation one is where your physical network segment is overloaded with traffic, but you don't want for whatever reason to subnet the network and interconnect the subnets with a router. Let's consider an example of a newspaper where the Editorial and Production departments are on the same subnetwork. The Editorial users all use server A for file service, and the Production users are on server B. An Ethernet is used to connect all users together, and high loads on the network are slowing things down. If the Editorial users could be segregated on one network segment and the Production users on another, the two network segments could be connected with a bridge. Only the network traffic destined for interfaces on the "other" side of the bridge would be sent to the other network, reducing congestion on each network segment. Filtering/traffic shaping firewall The second common situation is where firewall functionality is needed without IP Masquerading (NAT). An example is a small company that is connected via DSL or ISDN to their ISP. They have a 13 address global IP allocation for their ISP and have 10 PCs on their network. In this situation, using a router-based firewall is difficult because of subnetting issues. A bridge-based firewall can be configured and dropped into the path just downstream of their DSL/ISDN router without any IP numbering issues. Configuring a bridge Network interface card selection A bridge requires at least two network cards to function. Unfortunately, not all network interface cards as of FreeBSD 4.0 support bridging. Read &man.bridge.4; for details on the cards that are supported. Install and test the two network cards before continuing. Kernel configuration changes To enable kernel support for bridging, add the options BRIDGE statement to your kernel configuration file, and rebuild your kernel. Firewall support If you are planning to use the bridge as a firewall, you will need to add the IPFIREWALL option as well. Read for general information on configuring the bridge as a firewall. If you need to allow non-IP packets (such as ARP) to flow through the bridge, there is an undocumented firewall option that must be set. This option is IPFIREWALL_DEFAULT_TO_ACCEPT. Note that this changes the default rule for the firewall to accept any packet. Make sure you know how this changes the meaning of your ruleset before you set it. Traffic shaping support If you want to use the bridge as a traffic shaper, you will need to add the DUMMYNET option to your kernel configuration. Read &man.dummynet.4; for further information. Enabling the bridge Add the line net.link.ether.bridge=1 to /etc/sysctl.conf to enable the bridge at runtime. If you want the bridged packets to be filtered by ipfw, you should also add net.link.ether.bridge_ipfw=1 as well. Performance My bridge/firewall is a Pentium 90 with one 3Com 3C900B and one 3C905B. The protected side of the network runs at 10mbps half duplex and the connection between the bridge and my router (a Cisco 675) runs at 100mbps full duplex. With no filtering enabled, I've found that the bridge adds about 0.4 milliseconds of latency to pings from the protected 10mbps network to the Cisco 675. Other information If you want to be able to telnet into the bridge from the network, it is OK to assign one of the network cards an IP address. The consensus is that assigning both cards an address is a bad idea. If you have multiple bridges on your network, there cannot be more than one path between any two workstations. Technically, this means that there is no support for spanning tree link management. NFS Written by &a.unfurl;, 4 March 2000. Among the many different file systems that FreeBSD supports is a very unique type, the Network File System or NFS. NFS allows you to share directories and files on one machine with one or more other machines via the network they are attached to. Using NFS, users and programs can access files on remote systems as if they were local files. NFS has several benefits: Local workstations dont need as much disk space because commonly used data can be stored on a single machine and still remain accessible to everyone on the network. There is no need for users to have unique home directories on every machine on your network. Once they have an established directory that is available via NFS it can be accessed from anywhere. Storage devices such as floppies and CD-ROM drives can be used by other machines on the network eliminating the need for extra hardware. How It Works NFS is composed of two sides – a client side and a server side. Think of it as a want/have relationship. The client wants the data that the server side has. The server shares its data with the client. In order for this system to function properly a few processes have to be configured and running properly. The server has to be running the following daemons: nfsd - The NFS Daemon which services requests from NFS clients. mountd - The NFS Mount Daemon which actually carries out requests that nfsd passes on to it. The client side only needs to run a single daemon: nfsiod - The NFS async I/O Daemon which services requests from its NFS server. Configuring NFS Luckily for us, on a FreeBSD system this setup is a snap. The processes that need to be running can all be run at boot time with a few modifications to your /etc/rc.conf file. On the NFS server make sure you have: nfs_server_enable="YES" nfs_server_flags="-u -t -n 4" mountd_flags="-r" mountd is automatically run whenever the NFS server is enabled. The and flags to nfsd tell it to serve UDP and TCP clients. The flag tells nfsd to start 4 copies of itself. On the client, make sure you have: nfs_client_enable="YES" nfs_client_flags="-n 4" Like nfsd, the tells nfsiod to start 4 copies of itself. The last configuration step requires that you create a file called /etc/exports. The exports file specifies which file systems on your server will be shared (a.k.a., exported) and with what clients they will be shared. Each line in the file specifies a file system to be shared. There are a handful of options that can be used in this file but I will only touch on a few of them. You can find out about the rest in the &man.exports.5; man page. Here are a few example /etc/exports entries: The following line exports /cdrom to three silly machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in your /etc/hosts file. The flag makes the shared file system read-only. With this flag, the remote system will not be able to make any changes to the the shared file system. /cdrom -ro moe larry curly The following line exports /home to three hosts by IP address. This is a useful setup if you have a private network but do not have DNS running. The flag allows all the directories below the specified file system to be exported as well. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 The following line exports /a to two machines that have different domain names than the server. The flag allows the root user on the remote system to write to the shared file system as root. Without the -maproot=0 flag even if someone has root access on the remote system they won't be able to modify files on the shared file system. /a -maproot=0 host.domain.com box.example.com In order for a client to share an exported file system it must have permission to do so. Make sure your client is listed in your /etc/exports file. Now that you have made all these changes you can just reboot and let FreeBSD start everything for you at boot time or you can run the following commands as root: On the NFS server: &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r On the NFS client: &prompt.root; nfsiod -n 4 Now you should be ready to actually mount a remote file system. This can be done one of two ways. In these examples the server's name will be server and the client's name will be client. If you just want to temporarily mount a remote file system or just want to test out your config you can run a command like this as root on the client: &prompt.root; mount server:/home /mnt This will mount /home on the server on /mnt on the client. If everything is setup correctly you should be able to go into /mnt on the client and see all the files that are on the server. If you want to permanently (each time you reboot) mount a remote file system you need to add it to your /etc/fstab file. Here is an example line: server:/home /mnt nfs rw 0 0 Read the &man.fstab.5; man page for more options. Practical Uses There are many very cool uses for NFS. I use it quite a bit on the LAN I admin. Here are a few ways I have found it to be useful. I have several machines on my network but only one of them has a CD-ROM drive. Why? Because I have that one CD-ROM drive shared with all the others via NFS. The same can be done with floppy drives. With so many machines on the network it gets old having your personal files strewn all over the place. I have a central NFS server that houses all user home directories and shares them with the rest of the machines on the LAN, so no matter where I login I have the same home directory. When you get to reinstalling FreeBSD on one of your machines, NFS is the way to go. Just pop your distribution CD into your file server and away you go. I have a common /usr/ports/distfiles directory that all my machines share. That way when I go to install a port that I already installed on a different machine I do not have to download the source all over again. Problems integrating with other systems Contributed by &a.jlind;. Certain Ethernet adapters for ISA PC systems have limitations which can lead to serious network problems, particularly with NFS. This difficulty is not specific to FreeBSD, but FreeBSD systems are affected by it. The problem nearly always occurs when (FreeBSD) PC systems are networked with high-performance workstations, such as those made by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some operations may succeed, but suddenly the server will seem to become unresponsive to the client, even though requests to and from other systems continue to be processed. This happens to the client system, whether the client is the FreeBSD system or the workstation. On many systems, there is no way to shut down the client gracefully once this problem has manifested itself. The only solution is often to reset the client, because the NFS situation cannot be resolved. Though the correct solution is to get a higher performance and capacity Ethernet adapter for the FreeBSD system, there is a simple workaround that will allow satisfactory operation. If the FreeBSD system is the server, include the option on the mount from the client. If the FreeBSD system is the client, then mount the NFS file system with the option . These options may be specified using the fourth field of the fstab entry on the client for automatic mounts, or by using the parameter of the mount command for manual mounts. It should be noted that there is a different problem, sometimes mistaken for this one, when the NFS servers and clients are on different networks. If that is the case, make certain that your routers are routing the necessary UDP information, or you will not get anywhere, no matter what else you are doing. In the following examples, fastws is the host (interface) name of a high-performance workstation, and freebox is the host (interface) name of a FreeBSD system with a lower-performance Ethernet adapter. Also, /sharedfs will be the exported NFS filesystem (see man exports), and /project will be the mount point on the client for the exported file system. In all cases, note that additional options, such as or and may be desirable in your application. Examples for the FreeBSD system (freebox) as the client: in /etc/fstab on freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 As a manual mount command on freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Examples for the FreeBSD system as the server: in /etc/fstab on fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 As a manual mount command on fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Nearly any 16-bit Ethernet adapter will allow operation without the above restrictions on the read or write size. For anyone who cares, here is what happens when the failure occurs, which also explains why it is unrecoverable. NFS typically works with a block size of 8k (though it may do fragments of smaller sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS block gets split into multiple Ethernet packets, even though it is still a single unit to the upper-level code, and must be received, assembled, and acknowledged as a unit. The high-performance workstations can pump out the packets which comprise the NFS unit one right after the other, just as close together as the standard allows. On the smaller, lower capacity cards, the later packets overrun the earlier packets of the same unit before they can be transferred to the host and the unit as a whole cannot be reconstructed or acknowledged. As a result, the workstation will time out and try again, but it will try again with the entire 8K unit, and the process will be repeated, ad infinitum. By keeping the unit size below the Ethernet packet size limitation, we ensure that any complete Ethernet packet received can be acknowledged individually, avoiding the deadlock situation. Overruns may still occur when a high-performance workstations is slamming data out to a PC system, but with the better cards, such overruns are not guaranteed on NFS units. When an overrun occurs, the units affected will be retransmitted, and there will be a fair chance that they will be received, assembled, and acknowledged. Diskless Operation Contributed by &a.martin;. netboot.com/netboot.rom allow you to boot your FreeBSD machine over the network and run FreeBSD without having a disk on your client. Under 2.0 it is now possible to have local swap. Swapping over NFS is also still supported. Supported Ethernet cards include: Western Digital/SMC 8003, 8013, 8216 and compatibles; NE1000/NE2000 and compatibles (requires recompile) Setup Instructions Find a machine that will be your server. This machine will require enough disk space to hold the FreeBSD 2.0 binaries and have bootp, tftp and NFS services available. Tested machines: HP9000/8xx running HP-UX 9.04 or later (pre 9.04 doesn't work) Sun/Solaris 2.3. (you may need to get bootp) Set up a bootp server to provide the client with IP, gateway, netmask. diskless:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: Set up a TFTP server (on same machine as bootp server) to provide booting information to client. The name of this file is cfg.X.X.X.X (or /tftpboot/cfg.X.X.X.X, it will try both) where X.X.X.X is the IP address of the client. The contents of this file can be any valid netboot commands. Under 2.0, netboot has the following commands: help print help list ip print/set client's IP address server print/set bootp/tftp server address netmask print/set netmask hostname name print/set hostname kernel print/set kernel name rootfs print/set root filesystem swapfs print/set swap filesystem swapsize set diskless swapsize in KBytes diskboot boot from disk autoboot continue boot process trans | turn transceiver on|off flags set boot flags A typical completely diskless cfg file might contain: rootfs 192.1.2.3:/rootfs/myclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname myclient.mydomain A cfg file for a machine with local swap might contain: rootfs 192.1.2.3:/rootfs/myclient hostname myclient.mydomain Ensure that your NFS server has exported the root (and swap if applicable) filesystems to your client, and that the client has root access to these filesystems A typical /etc/exports file on FreeBSD might look like: /rootfs/myclient -maproot=0:0 myclient.mydomain /swapfs -maproot=0:0 myclient.mydomain And on HP-UX: /rootfs/myclient -root=myclient.mydomain /swapfs -root=myclient.mydomain If you are swapping over NFS (completely diskless configuration) create a swap file for your client using dd. If your swapfs command has the arguments /swapfs and the size 20000 as in the example above, the swapfile for myclient will be called /swapfs/swap.X.X.X.X where X.X.X.X is the client's IP addr, e.g.: &prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 Also, the client's swap space might contain sensitive information once swapping starts, so make sure to restrict read and write access to this file to prevent unauthorized access: &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 Unpack the root filesystem in the directory the client will use for its root filesystem (/rootfs/myclient in the example above). On HP-UX systems: The server should be running HP-UX 9.04 or later for HP9000/800 series machines. Prior versions do not allow the creation of device files over NFS. When extracting /dev in /rootfs/myclient, beware that some systems (HPUX) will not create device files that FreeBSD is happy with. You may have to go to single user mode on the first bootup (press control-c during the bootup phase), cd /dev and do a sh ./MAKEDEV all from the client to fix this. Run netboot.com on the client or make an EPROM from the netboot.rom file Using Shared <filename>/</filename> and <filename>/usr</filename> filesystems At present there isn't an officially sanctioned way of doing this, although I have been using a shared /usr filesystem and individual / filesystems for each client. If anyone has any suggestions on how to do this cleanly, please let me and/or the &a.core; know. Compiling netboot for specific setups Netboot can be compiled to support NE1000/2000 cards by changing the configuration in /sys/i386/boot/netboot/Makefile. See the comments at the top of this file. ISDN Last modified by &a.wlloyd;. A good resource for information on ISDN technology and hardware is Dan Kegel's ISDN Page. A quick simple road map to ISDN follows: If you live in Europe I suggest you investigate the ISDN card section. If you are planning to use ISDN primarily to connect to the Internet with an Internet Provider on a dial-up non-dedicated basis, I suggest you look into Terminal Adapters. This will give you the most flexibility, with the fewest problems, if you change providers. If you are connecting two LANs together, or connecting to the Internet with a dedicated ISDN connection, I suggest you consider the stand alone router/bridge option. Cost is a significant factor in determining what solution you will choose. The following options are listed from least expensive to most expensive. ISDN Cards Contributed by &a.hm;. This section is really only relevant to ISDN users in countries where the DSS1/Q.931 ISDN standard is supported. Some growing number of PC ISDN cards are supported under FreeBSD 2.2.x and up by the isdn4bsd driver package. It is still under development but the reports show that it is successfully used all over Europe. The latest isdn4bsd version is available from ftp://isdn4bsd@ftp.consol.de/pub/, the main isdn4bsd ftp site (you have to log in as user isdn4bsd , give your mail address as the password and change to the pub directory. Anonymous ftp as user ftp or anonymous will not give the desired result). Isdn4bsd allows you to connect to other ISDN routers using either IP over raw HDLC or by using synchronous PPP. A telephone answering machine application is also available. Many ISDN PC cards are supported, mostly the ones with a Siemens ISDN chipset (ISAC/HSCX), support for other chipsets (from Motorola, Cologne Chip Designs) is currently under development. For an up-to-date list of supported cards, please have a look at the README file. In case you are interested in adding support for a different ISDN protocol, a currently unsupported ISDN PC card or otherwise enhancing isdn4bsd, please get in touch with hm@kts.org. A majordomo maintained mailing list is available. To join the list, send mail to &a.majordomo; and specify: subscribe freebsd-isdn in the body of your message. ISDN Terminal Adapters Terminal adapters(TA), are to ISDN what modems are to regular phone lines. Most TA's use the standard hayes modem AT command set, and can be used as a drop in replacement for a modem. A TA will operate basically the same as a modem except connection and throughput speeds will be much faster than your old modem. You will need to configure PPP exactly the same as for a modem setup. Make sure you set your serial speed as high as possible. The main advantage of using a TA to connect to an Internet Provider is that you can do Dynamic PPP. As IP address space becomes more and more scarce, most providers are not willing to provide you with a static IP anymore. Most stand-alone routers are not able to accommodate dynamic IP allocation. TA's completely rely on the PPP daemon that you are running for their features and stability of connection. This allows you to upgrade easily from using a modem to ISDN on a FreeBSD machine, if you already have PPP setup. However, at the same time any problems you experienced with the PPP program and are going to persist. If you want maximum stability, use the kernel PPP option, not the user-land iijPPP. The following TA's are know to work with FreeBSD. Motorola BitSurfer and Bitsurfer Pro Adtran Most other TA's will probably work as well, TA vendors try to make sure their product can accept most of the standard modem AT command set. The real problem with external TA's is like modems you need a good serial card in your computer. You should read the serial ports section in the handbook for a detailed understanding of serial devices, and the differences between asynchronous and synchronous serial ports. A TA running off a standard PC serial port (asynchronous) limits you to 115.2Kbs, even though you have a 128Kbs connection. To fully utilize the 128Kbs that ISDN is capable of, you must move the TA to a synchronous serial card. Do not be fooled into buying an internal TA and thinking you have avoided the synchronous/asynchronous issue. Internal TA's simply have a standard PC serial port chip built into them. All this will do, is save you having to buy another serial cable, and find another empty electrical socket. A synchronous card with a TA is at least as fast as a stand-alone router, and with a simple 386 FreeBSD box driving it, probably more flexible. The choice of sync/TA v.s. stand-alone router is largely a religious issue. There has been some discussion of this in the mailing lists. I suggest you search the archives for the complete discussion. Stand-alone ISDN Bridges/Routers ISDN bridges or routers are not at all specific to FreeBSD or any other operating system. For a more complete description of routing and bridging technology, please refer to a Networking reference book. In the context of this page, I will use router and bridge interchangeably. As the cost of low end ISDN routers/bridges comes down, it will likely become a more and more popular choice. An ISDN router is a small box that plugs directly into your local Ethernet network(or card), and manages its own connection to the other bridge/router. It has all the software to do PPP and other protocols built in. A router will allow you much faster throughput that a standard TA, since it will be using a full synchronous ISDN connection. The main problem with ISDN routers and bridges is that interoperability between manufacturers can still be a problem. If you are planning to connect to an Internet provider, I recommend that you discuss your needs with them. If you are planning to connect two lan segments together, ie: home lan to the office lan, this is the simplest lowest maintenance solution. Since you are buying the equipment for both sides of the connection you can be assured that the link will work. For example to connect a home computer or branch office network to a head office network the following setup could be used. Branch office or Home network Network is 10 Base T Ethernet. Connect router to network cable with AUI/10BT transceiver, if necessary. ---Sun workstation | ---FreeBSD box | ---Windows 95 (Do not admit to owning it) | Stand-alone router | ISDN BRI line If your home/branch office is only one computer you can use a twisted pair crossover cable to connect to the stand-alone router directly. Head office or other lan Network is Twisted Pair Ethernet. -------Novell Server | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | |___---Stand-alone router | ISDN BRI line One large advantage of most routers/bridges is that they allow you to have 2 separate independent PPP connections to 2 separate sites at the same time. This is not supported on most TA's, except for specific(expensive) models that have two serial ports. Do not confuse this with channel bonding, MPP etc. This can be very useful feature, for example if you have an dedicated ISDN connection at your office and would like to tap into it, but don't want to get another ISDN line at work. A router at the office location can manage a dedicated B channel connection (64Kbs) to the internet, as well as a use the other B channel for a separate data connection. The second B channel can be used for dial-in, dial-out or dynamically bond(MPP etc.) with the first B channel for more bandwidth. An Ethernet bridge will also allow you to transmit more than just IP traffic, you can also send IPX/SPX or whatever other protocols you use. NIS/YP Written by &a.unfurl;, 21 January 2000, enhanced with parts and comments from Eric Ogren eogren@earthlink.net and Udo Erdelhoff ue@nathan.ruhr.de in June 2000. What is it? NIS, which stands for Network Information Services, was - developed by Sun Microsystems to centralize adminstration of Unix + developed by Sun Microsystems to centralize administration of Unix (originally SunOS) systems. It has now essentially become an industry standard; all major Unices (Solaris, HP-UX, AIX, Linux, NetBSD, OpenBSD, FreeBSD, etc) support NIS. NIS was formerly known as Yellow Pages (or yp), but due to copyright violations, Sun was forced to change the name. It is a RPC-based client/server system that allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location. It is similar to Windows NT's domain system; although the internal implementation of the two aren't at all similar, the basic functionality can be compared. Terms/processes you should know There are several terms and several important user processes that you will come across when attempting to implement NIS on FreeBSD, whether you are trying to create an NIS server or act an NIS client: The NIS domainname. An NIS master server and all of its clients (including its slave servers) have a NIS domainname. Similar to an NT domain name, the NIS domainname does not have anything to do with DNS. portmap. portmap must be running in order to enable RPC (Remote Procedure Call, a network protocol used by NIS). If portmap is not running, it will be impossible to run an NIS server, or to act as an NIS client. ypbind. ypbind “binds” an NIS client to its NIS server. It will take the NIS domainname from the system, and using RPC, connect to the server. ypbind is the core of client-server communication in an NIS environment; if ypbind dies on a client machine, it will not be able to access the NIS server. ypserv. ypserv, which should only be running on NIS servers, is the NIS server process itself. If ypserv dies, then the server will no longer be able to respond to NIS requests (hopefully, there is a slave server to take over for it). There are some implementations of NIS (but not the FreeBSD one), that don't try to reconnect to another server if the server it used before dies. Often, the only thing that helps in this case is to restart the server process (or even the whole server) or the ypbind process on the client. rpc.yppasswdd. rpc.yppasswdd, another process that should only be running on NIS master servers, is a daemon that will allow NIS clients to change their NIS passwords. If this daemon is not running, users will have to login to the NIS master server and change their passwords there. How does it work? There are three types of hosts in an NIS environment; master servers, slave servers, and clients. Servers act as a central repository for host configuration information. Master servers hold the authoritative copy of this information, while slave servers mirror this information for redundancy. Clients rely on the servers to provide this information to them. Information in many files can be shared in this manner. The master.passwd, group, and hosts files are commonly shared via NIS. Whenever a process on a client needs information that would normally be found in these files locally, it makes a query to the server it is bound to, to get this information. Machine types A NIS master server. This server, analogous to a Windows NT primary domain controller, maintains the files used by all of the NIS clients. The passwd, group, and other various files used by the NIS clients live on the master server. It is possible for one machine to be an NIS master server for more than one NIS domain. However, this will not be covered in this introduction, which assumes a relatively small-scale NIS environment. NIS slave servers. Similar to NT's backup domain controllers, NIS slave servers maintain copies of the NIS master's data files. NIS slave servers provide the redundancy, - which is needed in important enviroments. They also help + which is needed in important environments. They also help to balance the load of the master server: NIS Clients always attach to the NIS server, whose response they get first, and this includes slave-server-replies. NIS clients. NIS clients, like most NT workstations, authenticate against the NIS server (or the NT - domain controller in the NT Workstation case) to logon. + domain controller in the NT Workstation case) to log on. Using NIS/YP This section will deal with setting up a sample NIS environment. This section assumes that you are running FreeBSD 3.3 or later. The instructions given here will probably work for any version of FreeBSD greater than 3.0, but there are no guarantees that this is true. Planning Let's assume that you are the administrator of a small university lab. This lab, which consists of 15 FreeBSD machines, - currently has no centralised point of administration; each machine + currently has no centralized point of administration; each machine has its own /etc/passwd and /etc/master.passwd. These files are kept in sync with each other only through manual intervention; currently, when you add a user to the lab, you must run adduser on all 15 machines. Clearly, this has to change, so you have decided to convert the lab to use NIS, using two of the machines as servers. Therefore, the configuration of the lab now looks something like: Machine name IP address Machine role ellington 10.0.0.2 NIS master coltrane 10.0.0.3 NIS slave basie 10.0.0.4 Faculty workstation bird 10.0.0.5 Client machine cli[1-11] 10.0.0.[6-17] Other client machines If you are setting up a NIS scheme for the first time, it is a good idea to think through how you want to go about it. No matter what the size of your network, there are a few decisions that need to be made. Choosing a NIS Domain Name This might not be the domainname that you are used to. It is more accurately called the NIS domainname. When a client broadcasts its requests for info, it includes the name of the NIS domain that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts that are related in someway way. Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can cause confusion when trying to debug network problems. The NIS domainname should be unique within your network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the "acme-art" NIS domain. For this example, assume you have chosen the name test-domain. However, some operating systems (notably SunOS) use their NIS domain name as their Internet domain name. If one or more machines on your network have this restriction, you must use the Internet domain name as your NIS domain name. Physical Server Requirements There are several things to keep in mind when choosing a machine to use as a NIS server. One of the unfortunate things about NIS is the level of dependency the clients have on the server. If a client cannot contact the server for its NIS domain, very often the machine becomes unusable. The lack of user and group information causes most systems to temporarily freeze up. With this in mind you should make sure to choose a machine that won't be prone to being rebooted regularly, or one that might be used for development. The NIS server should ideally be a stand alone machine whose sole purpose in life is to be an NIS server. If you have a network that is not very heavily used, it is acceptable to put the NIS server on a machine running other services, just keep in mind that if the NIS server becomes unavailable, it will affect all of your NIS clients adversely. NIS Servers The canonical copies of all NIS information are stored on a single machine called the NIS master server. The databases used to store the information are called NIS maps. In FreeBSD, these maps are stored in /var/yp/[domainname] where [domainname] is the name of the NIS domain being served. A single NIS server can support several domains at once, therefore it is possible to have several such directories, one for each supported domain. Each domain will have its own independent set of maps. NIS master and slave servers handle all NIS requests with the ypserv daemon. Ypserv is responsible for receiving incoming requests from NIS clients, translating the requested domain and map name to a path to the corresponding database file and transmitting data from the database back to the client. Setting up a NIS master server Setting up a master NIS server can be relatively straight forward, depending on your needs. FreeBSD comes with support for NIS out-of-the-box. All you need is to add the following lines to /etc/rc.conf, and FreeBSD will do the rest for you. nisdomainname="test-domain" This line will set the NIS domainname to test-domain upon network setup (e.g. after reboot). nis_server_enable="YES" This will tell FreeBSD to start up the NIS server processes when the networking is next brought up. nis_yppasswdd_enable="YES" This will enable the rpc.yppasswdd daemon, which, as mentioned above, will allow users to change their NIS password from a client machine. Now, everything you have to do is to run the command /etc/netstart as superuser. It will setup everything for you, using the values you defined in /etc/rc.conf. Initializing the NIS maps The NIS maps are database files, that are kept in the /var/yp directory. They are generated from configuration files in the /etc directory of the NIS master, with one exception: the /etc/master.passwd file. - This is for a good reason; you don't want to propogate + This is for a good reason; you don't want to propagate passwords to your root and other administrative accounts to all the servers in the NIS domain. Therefore, before we initialize the NIS maps, you should: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd You should remove all entries regarding system accounts (bin, tty, kmem, games, etc), as well as any accounts that you - don't want to be propogated to the NIS clients (for example + don't want to be propagated to the NIS clients (for example root and any other UID 0 (superuser) accounts). Make sure the /var/yp/master.passwd is neither group nor world readable (mode 600)! Use the chmod command, if appreciate. When you have finished, it's time to initialize the NIS maps! FreeBSD includes a script named ypinit to do this for you (see its man page for more information). Note that this script is available on most UNIX OSs, but not on all. On Digital Unix/Compaq Tru64 Unix it is called ypsetup. Because we are generating maps for an NIS master, we are going to pass the option to ypinit. To generate the NIS maps, assuming you already performed the steps above, run: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit should have created /var/yp/Makefile from /var/yp/Makefile.dist. When created, this file assumes that you are operating in a single server NIS environment with only FreeBSD machines. Since test-domain has a slave server as well, you must edit /var/yp/Makefile: ellington&prompt.root; vi /var/yp/Makefile You should comment out the line that says `NOPUSH = "True"' (if it is not commented out already). Setting up a NIS slave server Setting up an NIS slave server is even more simple than - setting up the master. Logon to the slave server and edit the + setting up the master. Log on to the slave server and edit the file /etc/rc.conf as you did before. The only difference is that we now must use the option when running ypinit. The option requires the name of the NIS master be passed to it as well, so our command line looks like: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. You should now have a directory called /var/yp/test-domain. Copies of the NIS master server's maps should be in this directory. You will need to make sure that these stay updated. The following /etc/crontab entries on your slave servers should do the job: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid These two lines force the slave to sync its maps with the maps on the master server. Although this is not mandatory, because the master server tries to make sure any changes to it's NIS maps are communicated to it's slaves, the password information is so vital to systems that depend on the server, that it is a good idea to force the updates. This is more important on busy networks where map updates might not always complete. Now, run the command /etc/netstart on the slave server as well, which again starts the NIS server. NIS Clients An NIS client establishes what is called a binding to a particular NIS server using the ypbind daemon. ypbind checks the system's default domain (as set by the domainname command), and begins broadcasting RPC requests on the local network. These requests specify the name of the domain for which ypbind is attempting to establish a binding. If a server that has been configured to serve the requested domain receives one of the broadcasts, it will respond to ypbind, which will record the server's address. If there are several servers available (a master and several slaves, for example), ypbind will use the address of the first one to respond. From that point on, the client system will direct all of its NIS requests to that server. Ypbind will occasionally ping the server to make sure it is still up and running. If it fails to receive a reply to one of its pings within a reasonable amount of time, ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server. Setting up an NIS client Setting up a FreeBSD machine to be a NIS client is fairly straight forward. Edit the file /etc/rc.conf and add the following lines in order to set the NIS domainname and start ypbind upon network startup: nisdomainname="test-domain" nis_client_enable="YES" To import all possible password entries from the NIS server, add this line to your /etc/master.passwd file, using vipw: +::::::::: This line will afford anyone with a valid account in the NIS server's password maps an account. There are many ways to configure your NIS client by changing this line. See the netgroups part below for more information. For more detailed reading see O'Reilly's book on Managing NFS and NIS. To import all possible group entries from the NIS server, add this line to your /etc/group file: +:*:: After completing these steps, you should be able to run ypcat passwd and see the NIS server's passwd map. NIS Security In general, any remote user can issue an RPC to ypserv and retrieve the contents of your NIS maps, provided the remote user knows your domainname. To prevent such unauthorized transactions, ypserv supports a feature called securenets which can be used to restrict access to a given set of hosts. At startup, ypserv will attempt to load the securenets information from a file called /var/yp/securenets. This path varies depending on the path specified with the option. This file contains entries that consist of a network specification and a network mask separated by white space. Lines starting with # are considered to be comments. A sample securenets file might look like this: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 If ypserv receives a request from an address that matches one of these rules, it will process the request normally. If the address fails to match a rule, the request will be ignored and a warning message will be logged. If the /var/yp/securenets file does not exist, ypserv will allow connections from any host. The ypserv program also has support for Wietse Venema's tcpwrapper package. This allows the administrator to use the tcpwrapper configuration files for access control instead of /var/yp/securenets. While both of these access control mechanisms provide some security, they, like the privileged port test, are vulnerable to IP spoofing attacks. All NIS-related traffic should be blocked at your firewall. Servers using /var/yp/securenets may fail to serve legitimate NIS clients with archaic TCP/IP implementations. Some of these implementations set all host bits to zero when doing broadcasts and/or fail to observe the subnet mask when calculating the broadcast address. While some of these problems can be fixed by changing the client configuration, other problems may force the retirement of the client systems in question or the abandonment of /var/yp/securenets. Using /var/yp/securenets on a server with such an archaic implementation of TCP/IP is a really bad idea and will lead to loss of NIS functionality for large parts of your network. The use of the tcpwrapper package increases the latency of your NIS server. The additional delay may be long enough to cause timeouts in client programs, especially in busy networks or with slow NIS servers. If one or more of your client systems suffers from these symptoms, you should convert the client systems in question into NIS slave servers and force them to bind to themselves. Barring some users from logging on In our lab, there is a machine basie that is supposed to be a faculty only workstation. We don't want to take this machine out of the NIS domain, yet the passwd file on the master NIS server contains accounts for both faculty and students. What can we do? There is a way to bar specific users from logging on to a machine, even if they are present in the NIS database. To do this, all you must do is add -username to the end of the /etc/master.passwd file on the client machine, where username is the username of the user you wish to bar from logging in. This should preferably be done using vipw, since vipw will sanity check your changes to /etc/master.passwd, as well as automatically rebuild the password database when you finish editing. For example, if we wanted to bar user bill from logging on to basie we would: basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Using netgroups The netgroups part was contributed by Udo Erdelhoff ue@nathan.ruhr.de in July 2000. The method shown in the previous chapter works reasonably well if you need special rules for a very small number of users and/or machines. On larger networks, you will forget to bar some users from logging onto sensitive machines, or you may even have to modify each machine separately, thus loosing the main benefit of NIS, - centralised administration. + centralized administration. The NIS developers' solution for this problem is called netgroups. Their purpose and semantics can be compared to the normal groups used by Unix file systems. The main differences are the lack of a numeric id and the ability to define a netgroup by including both user accounts and other netgroups. Netgroups were developed to handle large, complex networks with hundreds of users and machines. On one hand, this is a Good Thing if you are forced to deal with such a situation. On the other hand, this complexity makes it almost impossible to explain netgroups with really simple examples. The example used in the remainder of this chapter demonstrates this problem. Let us assume that your successful introduction of NIS in your laboratory caught your superiors' interest. Your next job is to extend your NIS domain to cover some of the other machines on campus. The two tables contain the names of the new users and new machines as well as brief descriptions of them. User Name(s) Description alpha, beta Normal employees of the IT department charlie, delta The new apprentices of the IT department echo, foxtrott, golf, ... Ordinary employees able, baker, ... The current interns Machine Name(s) Description - war, death, famine, polution + war, death, famine, pollution Your most important servers. Only the IT employees are allowed to log onto these machines. pride, greed, envy, wraith, lust, sloth Less important servers. All members of the IT department are allowed to login onto these machines. one, two, three, four, ... Ordinary workstations. Only the real employees are allowed to use these machines. trashcan - A very old machine without any critcal data. + A very old machine without any critical data. Even the intern is allowed to use this box. If you tried to implement these restrictions by separately blocking each user, you would have to add one -user line to each system's passwd for each user who is not allowed to login onto that system. If you forget just one entry, you could be in trouble. It may feasible to do this correctly during the initial setup, however you will eventually forget to add the lines for new users during day-to-day operations. After all, Murphy was an optimist. Handling this situation with netgroups offers several advantages. Each user need not be handled separately; you assign a user to one or netgroup and allow or forbid logins for all members of the netgroup. If you add a new machine, you will only have to define login restrictions for netgroups. If a new user is added, you will only have to add the user to one or more netgroups. Those changes are independent of each other; no more for each combination of user and machine do... If your NIS setup is planned carefully, you will only have to modify exactly one central configuration file to grant or deny access to machines. - The first step is the initialisation of the NIS map + The first step is the initialization of the NIS map netgroup. FreeBSD's ypinit does not create this map by default, but its NIS implementation will support it once it has been created. To create an empty map, simply type ellington&prompt.root; vi /var/yp/netgroup and start adding content. For our example, we need at least four netgroups: IT employees, IT apprentices, normal employees and interns. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP etc. are the names of the netgroups. Each bracketed group adds one or more user accounts to it. The three fields inside a group are: The name of the host(s) where the following items are valid. If you do not specify a hostname, the entry is valid on all hosts. If you do specify a hostname, you will a realm of darkness, horror and utter confusion. The name of the account that belongs to this netgroup. The NIS domain for the account. You can import accounts from other NIS domains into your netgroup if you are one of unlucky fellows with more than one NIS domain. - Each of this fields can contain wildcards, see + Each of these fields can contain wildcards. See &man.netgroup.5; for details. Netgroup names longer than 8 characters should not be used, especially if you have machines running other operating systems within your NIS domain. The names are case sensitive; using capital letters for your netgroup names is an easy way to distinguish between user, machine and netgroup names. Some NIS clients (other than FreeBSD) cannot handle netgroups with a large number of entries. For example, some older versions of SunOS start to cause trouble if a netgroup contains more than 15 entries. You can circumvent this limit by creating several sub-netgroups with 15 users or less and a real netgroup that consists of the sub-netgroups: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe32,domain) (,joe33,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 You can repeat this process if you need more than 225 users within a single netgroup. Activating and distributing your new NIS map is easy: ellington&prompt.root; cd /var/yp ellington&prompt.root; make This will generate the three NIS maps netgroup, netgroup.byhost and netgroup.byuser. Use &man.ypcat.1; to check if your new NIS map are available: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser The output of the first command should resemble the contents of /var/yp/netgroup. The second command will not produce output if you have not specified host-specific netgroups. The third command can be used to get the list of netgroups for a user. The client setup is quite simple. To configure the server war, you only have to start &man.vipw.8; and replace the line +::::::::: with +@IT_EMP::::::::: Now, only the data for the users defined in the netgroup IT_EMP is imported into war's password database and only these users are allowed to login. Unfortunately, this limitation also applies to the ~ function of the shell and all routines converting between user names and numerical user ids. In other words, cd ~user will not work, ls -l will show the numerical id instead of the username and find . -user joe -print will fail with No such user. To fix this, you will have to import all user entries without allowing them to login onto your servers. This can be achieved by adding another line to /etc/master.passwd. This line should contain +:::::::::/sbin/nologin, meaning Import all entries but replace the shell with /sbin/nologin in the imported entries. You can replace any field in the passwd entry by placing a default value in your /etc/master.passwd. Make sure that the line +:::::::::/sbin/nologin is placed after +@IT_EMP:::::::::. Otherwise, all user accounts imported from NIS will have /sbin/nologin as their login shell. After this change, you will only have to change one NIS map if a new employee joins the IT department. You could use a similar approach for the less important servers by replacing the old +::::::::: in their local version of /etc/master.passwd with something like this: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin The corresponding lines for the normal workstations could be: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin And everything would be fine until there is a policy change a few weeks later: The IT department starts hiring interns. The IT interns are allowed to use the normal workstations and the less important servers; and the IT apprentices are allowed to login onto the main servers. You add a new netgroup IT_INTERN, add the new IT interns to this netgroup and start to change the config on each and every machine... As the old saying goes: Errors in - centralised planning lead to global mess. + centralized planning lead to global mess. NIS' ability to create netgroups from other netgroups can be used to prevent situations like these. One possibility is the creation of role-based netgroups. For example, you could create a netgroup called BIGSRV to define the login restrictions for the important servers, another netgroup called SMALLSRV for the less important servers and a third netgroup called USERBOX for the normal workstations. Each of these netgroups contains the netgroups that are allowed to login onto these machines. The new entries for your NIS map netgroup should look like this: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS This method of defining login restrictions works reasonably well if you can define groups of machines with identical restrictions. Unfortunately, this is the exception and not the rule. Most of the time, you will need the ability to define login restrictions on a per-machine basis. Machine-specific netgroup definitions are the other possibility to deal with the policy change outlined above. In this scenario, the /etc/master.passwd of each box contains two lines starting with ``+''. The first of them adds a netgroup with the accounts allowed to login onto this machine, the second one adds all other accounts with /sbin/nologin as shell. It is a good idea to use the ALL-CAPS version of the machine name as the name of the netgroup. In other words, the lines should look like this: +@BOXNAME::::::::: +:::::::::/sbin/nologin Once you have completed this task for all your machines, you will not have to modify the local versions of /etc/master.passwd ever again. All further changes can be handled by modifying the NIS map. Here is an example of a possible netgroup map for this scenario with some additional goodies. # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks -# Allow echo und golf to access our anti-virus-machine +# Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server -POLUTION BIGSRV (,india,test-domain) +POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] If you are using some kind of database to manage your user accounts, you should be able to create the first part of the map with your database's report tools. This way, new users will automatically have access to the boxes. One last word of caution: It may not always be advisable to use machine-based netgroups. If you are deploying a couple dozen or even hundreds of identical machines for student labs, you should use role-based netgroups instead of machine-based netgroups to keep the size of the NIS map within reasonable limits. Important things to remember There are still a couple of things that you will need to do differently now that you are in an NIS environment. Every time you wish to add a user to the lab, you must add it to the master NIS server only, and you must remember to rebuild the NIS maps. If you forget to do this, the new user will not be able to login anywhere except on the NIS master. For example, if we needed to add a new user “jsmith” to the lab, we would: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain You could also run adduser jsmith instead of pw useradd jsmith. Keep the administration accounts out of the NIS - maps. You don't want to be propogating administrative + maps. You don't want to be propagating administrative accounts and passwords to machines that will have users that shouldn't have access to those accounts. Keep the NIS master and slave secure, and minimize their downtime. If somebody either hacks or simply turns off these machines, they have effectively rendered many people without the ability to login to the lab. - This is the chief weakness of any centralised administration + This is the chief weakness of any centralized administration system, and it is probably the most important weakness. If you do not protect your NIS servers, you will have a lot of angry users! NIS v1 compatibility FreeBSD's ypserv has some support for serving NIS v1 clients. FreeBSD's NIS implementation only uses the NIS v2 protocol, however other implementations include support for the v1 protocol for backwards compatibility with older systems. The ypbind daemons supplied with these systems will try to establish a binding to an NIS v1 server even though they may never actually need it (and they may persist in broadcasting in search of one even after they receive a response from a v2 server). Note that while support for normal client calls is provided, this version of ypserv does not handle v1 map transfer requests; consequently, it can not be used as a master or slave in conjunction with older NIS servers that only support the v1 protocol. Fortunately, there probably are not any such servers still in use today. NIS servers that are also NIS clients Care must be taken when running ypserv in a multi-server domain where the server machines are also NIS clients. It is generally a good idea to force the servers to bind to themselves rather than allowing them to broadcast bind requests and possibly become bound to each other. Strange failure modes can result if one server goes down and others are dependent upon on it. Eventually all the clients will time out and attempt to bind to other servers, but the delay involved can be considerable and the failure mode is still present since the servers might bind to each other all over again. You can force a host to bind to a particular server by running ypbind with the flag. libscrypt v.s. libdescrypt One of the most common issues that people run into when trying to implement NIS is crypt library compatibility. If your NIS server is using the DES crypt libraries, it will only support clients that are using DES as well. To check which one your server and clients are using look at the symlinks in /usr/lib. If the machine is configured to use the DES libraries, it will look something like this: &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a -r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 -r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a If the machine is configured to use the standard FreeBSD MD5 crypt libraries they will look something like this: &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a -r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 -r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a If you have trouble authenticating on an NIS client, this is a pretty good place to start looking for possible problems. If you want to deploy an NIS server for a heterogenous network, you will probably have to use DES on all systems because it is the lowest common standard. DHCP Written by &a.gsutter;, March 2000. What is DHCP? DHCP, the Dynamic Host Configuration Protocol, describes the means by which a system can connect to a network and obtain the necessary information for communication upon that network. FreeBSD uses the ISC (Internet Software Consortium) DHCP implementation, so all implementation-specific information here is for use with the ISC distribution. What This Section Covers This handbook section attempts to describe only the parts of the DHCP system that are integrated with FreeBSD; consequently, the server portions are not described. The DHCP manual pages, in addition to the references below, are useful resources. How it Works When dhclient, the DHCP client, is executed on the client machine, it begins broadcasting requests for configuration information. By default, these requests are on UDP port 68. The server replies on UDP 67, giving the client an IP address and other relevant network information such as netmask, router, and DNS servers. All of this information comes in the form of a DHCP "lease" and is only valid for a certain time (configured by the DHCP server maintainer). In this manner, stale IP addresses for clients no longer connected to the network can be automatically reclaimed. DHCP clients can obtain a great deal of information from the server. An exhaustive list may be found in &man.dhcp-options.5;. FreeBSD Integration FreeBSD fully integrates the ISC DHCP client, dhclient. DHCP client support is provided within both the installer and the base system, obviating the need for detailed knowledge of network configurations on any network that runs a DHCP server. dhclient has been included in all FreeBSD distributions since 3.2. DHCP is supported by sysinstall. When configuring a network interface within sysinstall, the first question asked is, "Do you want to try dhcp configuration of this interface?" Answering affirmatively will execute dhclient, and if successful, will fill in the network configuration information automatically. There are two things you must do to have your system use DHCP upon startup: Make sure that the bpf device is compiled into your kernel. To do this, add pseudo-device bpf to your kernel configuration file, and rebuild the kernel. For more information about building kernels, see . The bpf device is already part of the GENERIC kernel that is supplied with FreeBSD, so if you don't have a custom kernel, you shouldn't need to create one in order to get DHCP working. For those who are particularly security conscious, you should be warned that bpf is also the device that allows packet sniffers to work correctly (although they still have to be run as root). bpf is required to use DHCP, but if you are very sensitive about security, you probably shouldn't add bpf to your kernel in the expectation that at some point in the future you will be using DHCP. Edit your /etc/rc.conf to include the following: ifconfig_fxp0="DHCP" Be sure to replace fxp0 with the designation for the interface that you wish to dynamically configure. If you are using a different location for dhclient, or if you wish to pass additional flags to dhclient, also include the following (editing as necessary): dhcp_program="/sbin/dhclient" dhcp_flags="" The DHCP server, dhcpd, is included as part of the isc-dhcp2 port in the ports collection. This port contains the full ISC DHCP distribution, consisting of client, server, relay agent and documentation. Files /etc/dhclient.conf dhclient requires a configuration file, /etc/dhclient.conf. Typically the file contains only comments, the defaults being reasonably sane. This configuration file is described by the &man.dhclient.conf.5; man page. /sbin/dhclient dhclient is statically linked and resides in /sbin. The &man.dhclient.8; manual page gives more information about dhclient. /sbin/dhclient-script dhclient-script is the FreeBSD-specific DHCP client configuration script. It is described in &man.dhclient-script.8;, but should not need any user modification to function properly. /var/db/dhclient.leases The DHCP client keeps a database of valid leases in this file, which is written as a log. &man.dhclient.leases.5; gives a slightly longer description. Further Reading The DHCP protocol is fully described in RFC 2131. An informational resource has also been set up at dhcp.org. diff --git a/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml b/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml index 779564658b..e3bdd0a658 100644 --- a/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml @@ -1,732 +1,732 @@ Backups Synopsis The following chapter will cover methods of backing up data, and the programs used to create those backups. If you would like to contribute something to this section, send it to the &a.doc;. Tape Media The major tape media are the 4mm, 8mm, QIC, mini-cartridge and DLT. 4mm (DDS: Digital Data Storage) 4mm tapes are replacing QIC as the workstation backup media of choice. This trend accelerated greatly when Conner purchased Archive, a leading manufacturer of QIC drives, and then stopped production of QIC drives. 4mm drives are small and quiet but do not have the reputation for reliability that is enjoyed by 8mm drives. The cartridges are less expensive and smaller (3 x 2 x 0.5 inches, 76 x 51 x 12 mm) than 8mm cartridges. 4mm, like 8mm, has comparatively short head life for the same reason, both use helical scan. Data throughput on these drives starts ~150kB/s, peaking at ~500kB/s. Data capacity starts at 1.3 GB and ends at 2.0 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. Multi-drive tape library units can have 6 drives in a single cabinet with automatic tape changing. Library capacities reach 240 GB. The DDS-3 standard now supports tape capacities up to 12GB (or 24GB compressed). 4mm drives, like 8mm drives, use helical-scan. All the benefits and drawbacks of helical-scan apply to both 4mm and 8mm drives. Tapes should be retired from use after 2,000 passes or 100 full backups. 8mm (Exabyte) 8mm tapes are the most common SCSI tape drives; they are the best choice of exchanging tapes. Nearly every site has an exabyte 2 GB 8mm tape drive. 8mm drives are reliable, convenient and quiet. Cartridges are inexpensive and small (4.8 x 3.3 x 0.6 inches; 122 x 84 x 15 mm). One downside of 8mm tape is relatively short head and tape life due to the high rate of relative motion of the tape across the heads. Data throughput ranges from ~250kB/s to ~500kB/s. Data sizes start at 300 MB and go up to 7 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. These drives are available as single units or multi-drive tape libraries with 6 drives and 120 tapes in a single cabinet. Tapes are changed automatically by the unit. Library capacities reach 840+ GB. The Exabyte Mammoth model supports 12GB on one tape (24GB with compression) and costs approximately twice as much as conventional tape drives. Data is recorded onto the tape using helical-scan, the heads are positioned at an angle to the media (approximately 6 degrees). The tape wraps around 270 degrees of the spool that holds the heads. The spool spins while the tape slides over the spool. The result is a high density of data and closely packed tracks that angle across the tape from one edge to the other. QIC QIC-150 tapes and drives are, perhaps, the most common tape drive and media around. QIC tape drives are the least expensive "serious" backup drives. The downside is the cost of media. QIC tapes are expensive compared to 8mm or 4mm tapes, up to 5 times the price per GB data storage. But, if your needs can be satisfied with a half-dozen tapes, QIC may be the correct choice. QIC is the most common tape drive. Every site has a QIC drive of some density or another. Therein lies the rub, QIC has a large number of densities on physically similar (sometimes identical) tapes. QIC drives are not quiet. These drives audibly seek before they begin to record data and are clearly audible whenever reading, writing or seeking. QIC tapes measure (6 x 4 x 0.7 inches; 15.2 x 10.2 x 1.7 mm). Mini-cartridges, which also use 1/4" wide tape are discussed separately. Tape libraries and changers are not available. Data throughput ranges from ~150kB/s to ~500kB/s. Data capacity ranges from 40 MB to 15 GB. Hardware compression is available on many of the newer QIC drives. QIC drives are less frequently installed; they are being supplanted by DAT drives. Data is recorded onto the tape in tracks. The tracks run along the long axis of the tape media from one end to the other. The number of tracks, and therefore the width of a track, varies with the tape's capacity. Most if not all newer drives provide backward-compatibility at least for reading (but often also for writing). QIC has a good reputation regarding the safety of the data (the mechanics are simpler and more robust than for helical scan drives). Tapes should be retired from use after 5,000 backups. * Mini-Cartridge ]]> DLT DLT has the fastest data transfer rate of all the drive types listed here. The 1/2" (12.5mm) tape is contained in a single spool cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a swinging gate along one entire side of the cartridge. The drive mechanism opens this gate to extract the tape leader. The tape leader has an oval hole in it which the drive uses to "hook" the tape. The take-up spool is located inside the tape drive. All the other tape cartridges listed here (9 track tapes are the only exception) have both the supply and take-up spools located inside the tape cartridge itself. Data throughput is approximately 1.5MB/s, three times the throughput of 4mm, 8mm, or QIC tape drives. Data capacities range from 10GB to 20GB for a single drive. Drives are available in both multi-tape changers and multi-tape, multi-drive tape libraries containing from 5 to 900 tapes over 1 to 20 drives, providing from 50GB to 9TB of storage. With compression, DLT Type IV format supports up to 70GB capacity. Data is recorded onto the tape in tracks parallel to the direction of travel (just like QIC tapes). Two tracks are written at once. Read/write head lifetimes are relatively long; once the tape stops moving, there is no relative motion between the heads and the tape. AIT AIT is a new format from Sony, and can hold up to 50GB (with compression) per tape. The tapes contain memory chips which retain an index of the tape's contents. This index can be rapidly read by the tape drive to determine the position of files on the tape, instead of the several minutes that would be required for other tapes. Software such as SAMS:Alexandria can operate forty or more AIT tape libraries, communicating directly with the tape's memory chip to display the contents on screen, determine what files where backed up to which tape, locate the correct tape, load it, and restore the data from the tape. Libraries like this cost in the region of $20,000, pricing them a little out of the hobbyist market. Using a New Tape for the First Time The first time that you try to read or write a new, completely blank tape, the operation will fail. The console messages should be similar to: sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready The tape does not contain an Identifier Block (block number 0). All QIC tape drives since the adoption of QIC-525 standard write an Identifier Block to the tape. There are two solutions: mt fsf 1 causes the tape drive to write an Identifier Block to the tape. Use the front panel button to eject the tape. Re-insert the tape and &man.dump.8; data to the tape. &man.dump.8; will report DUMP: End of tape detected and the console will show: HARDWARE FAILURE info:280 asc:80,96 rewind the tape using: mt rewind Subsequent tape operations are successful. Backup Programs The three major programs are &man.dump.8;, &man.tar.1;, and &man.cpio.1;. Dump and Restore &man.dump.8; and &man.restore.8; are the traditional Unix backup programs. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the filesystems. &man.dump.8; backs up devices, entire filesystems, not parts of a filesystem and not directory trees that span more than one filesystem, using either soft links &man.ln.1; or mounting one filesystem onto another. &man.dump.8; does not write files and directories to tape, but rather writes the data blocks that are the building blocks of files and directories. &man.dump.8; has quirks that remain from its early days in Version 6 of ATT Unix (circa 1975). The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives. &man.rdump.8; and &man.rrestore.8; backup data across the network to a tape drive attached to another computer. Both programs rely upon &man.rcmd.3; and &man.ruserok.3; to access the remote tape drive. Therefore, the user performing the backup must have rhosts access to the remote computer. The arguments to &man.rdump.8; and &man.rrestore.8; must suitable to use - on the remote computer. (e.g. When rdump'ing from + on the remote computer. (e.g. When rdumping from a FreeBSD computer to an Exabyte tape drive connected to a Sun called komodo, use: /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrsa8 /dev/rda0a 2>&1) Beware: there are security implications to allowing rhosts commands. Evaluate your situation carefully. Tar &man.tar.1; also dates back to Version 6 of ATT Unix (circa 1975). &man.tar.1; operates in cooperation with the filesystem; &man.tar.1; writes files and directories to tape. &man.tar.1; does not support the full range of options that are available from &man.cpio.1;, but &man.tar.1; does not require the unusual command pipeline that &man.cpio.1; uses. Most versions of &man.tar.1; do not support backups across the network. The GNU version of &man.tar.1;, which FreeBSD utilizes, supports remote devices using the same syntax as &man.rdump.8;. To &man.tar.1; to an Exabyte tape drive connected to a Sun called komodo, use: /usr/bin/tar cf komodo:/dev/nrsa8 . 2>&1. For versions without remote device support, you can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. &prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b If you're worried about the security of backing over a network you should use the &man.ssh.1; command instead of &man.rsh.1;. Cpio &man.cpio.1; is the original Unix file interchange tape program for magnetic media. &man.cpio.1; has options (among many others) to perform byte-swapping, write a number of different archives format, and pipe the data to other programs. This last feature makes &man.cpio.1; and excellent choice for installation media. &man.cpio.1; does not know how to walk the directory tree and a list of files must be provided through stdin. &man.cpio.1; does not support backups across the network. You can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. (XXX add an example command) Pax &man.pax.1; is IEEE/POSIX's answer to &man.tar.1; and &man.cpio.1;. Over the years the various versions of &man.tar.1; and &man.cpio.1; have gotten slightly incompatible. So rather than fight it out to fully standardize them, POSIX created a new archive utility. &man.pax.1; attempts to read and write many of the various &man.cpio.1; and &man.tar.1; formats, plus new formats of its own. Its command set more resembles &man.cpio.1; than &man.tar.1;. Amanda Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and network communications with the Amanda server. A common problem at locations with a number of large disks is the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem. Amanda can use a "holding disk" to backup several filesystems at the same time. Amanda creates "archive sets": a group of tapes used over a period of time to create full backups of all the filesystems listed in Amanda's configuration file. The "archive set" also contains nightly incremental (or differential) backups of all the filesystems. Restoring a damaged filesystem requires the most recent full backup and the incremental backups. The configuration file provides fine control backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is available as either a port or a package, it is not installed by default. Do Nothing Do nothing is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it! If your time and your data is worth little to nothing, then Do nothing is the most suitable backup program for your computer. But beware, Unix is a useful tool, you may find that within six months you have a collection of files that are valuable to you. Do nothing is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by your computer. An example is the files that comprise these handbook pages-they have been generated from SGML input files. Creating backups of these HTML files is not necessary. The SGML source files are backed up regularly. Which Backup Program is Best? &man.dump.8; Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of Unix filesystems is &man.dump.8;. Elizabeth created filesystems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by doing a backup and restore of that filesystems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See torture-testing Backup and Archive Programs. Emergency Restore Procedure Before the Disaster There are only four steps that you need to perform in preparation for any disaster that may occur. First, print the disklabel from each of your disks (e.g. disklabel da0 | lpr), your filesystem table (/etc/fstab) and all boot messages, two copies of each. Second, determine that the boot and fix-it floppies (boot.flp and fixit.flp) have all your devices. The easiest way to check is to reboot your machine with the boot floppy in the floppy drive and check the boot messages. If all your devices are listed and functional, skip on to step three. Otherwise, you have to create two custom bootable floppies which has a kernel that can mount your all of your disks and access your tape drive. These floppies must contain: &man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8;, and whichever backup program you use. These programs must be statically linked. If you use &man.dump.8;, the floppy must contain &man.restore.8;. Third, create backup tapes regularly. Any changes that you make after your last backup may be irretrievably lost. Write-protect the backup tapes. Fourth, test the floppies (either boot.flp and fixit.flp or the two custom bootable floppies you made in step two.) and backup tapes. Make notes of the procedure. Store these notes with the bootable floppy, the printouts and the backup tapes. You will be so distraught when restoring that the notes may prevent you from destroying your backup tapes (How? In place of tar xvf /dev/rsa0, you might accidently type tar cvf /dev/rsa0 and over-write your backup tape). For an added measure of security, make bootable floppies and two backup tapes each time. Store one of each at a remote location. A remote location is NOT the basement of the same office building. A number of firms in the World Trade Center learned this lesson the hard way. A remote location should be physically separated from your computers and disk drives by a significant distance. An example script for creating a bootable floppy: /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes # cd /mnt/dev ./MAKEDEV std ./MAKEDEV da0 ./MAKEDEV da1 ./MAKEDEV da2 ./MAKEDEV sa0 ./MAKEDEV pty0 cd / # # create minimum filesystem table # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < After the Disaster The key question is: did your hardware survive? You have been doing regular backups so there is no need to worry about the software. If the hardware has been damaged. First, replace those parts that have been damaged. If your hardware is okay, check your floppies. If you are using a custom boot floppy, boot single-user (type -s at the boot: prompt). Skip the following paragraph. If you are using the boot.flp and fixit.flp floppies, keep reading. Insert the boot.flp floppy in the first floppy drive and boot the computer. The original install menu will be displayed on the screen. Select the Fixit--Repair mode with CDROM or floppy. option. Insert the fixit.flp when prompted. restore and the other programs that you need are located in /mnt2/stand. Recover each filesystem separately. Try to &man.mount.8; (e.g. mount /dev/da0a /mnt) the root partition of your first disk. If the disklabel was damaged, use &man.disklabel.8; to re-partition and label the disk to match the label that your printed and saved. Use &man.newfs.8; to re-create the filesystems. Re-mount the root partition of the floppy read-write (mount -u -o rw /mnt). Use your backup program and backup tapes to recover the data for this filesystem (e.g. restore vrf /dev/sa0). Unmount the filesystem (e.g. umount /mnt) Repeat for each filesystem that was damaged. Once your system is running, backup your data onto new tapes. Whatever caused the crash or data loss may strike again. An another hour spent now, may save you from further distress later. * I did not prepare for the Disaster, What Now? ]]> What about Backups to Floppies? Can I use floppies for backing up my data? Floppy disks are not really a suitable media for making backups as: The media is unreliable, especially over long periods of time Backing up and restoring is very slow They have a very limited capacity (the days of backing up an entire hard disk onto a dozen or so floppies has long since passed). However, if you have no other method of backing up your data then floppy disks are better than no backup at all. If you do have to use floppy disks then ensure that you use good quality ones. Floppies that have been lying around the office for a couple of years are a bad choice. Ideally use new ones from a reputable manufacturer. So how do I backup my data to floppies? The best way to backup to floppy disk is to use &man.tar.1; with the (multi volume) option, which allows backups to span multiple floppies. To backup all the files in the current directory and sub-directory use this (as root): &prompt.root; tar Mcvf /dev/rfd0 * When the first floppy is full &man.tar.1; will prompt you to insert the next volume (because &man.tar.1; is media independent it refers to volumes. In this context it means floppy disk) Prepare volume #2 for /dev/rfd0 and hit return: This is repeated (with the volume number incrementing) until all the specified files have been archived. Can I compress my backups? Unfortunately, &man.tar.1; will not allow the option to be used for multi-volume archives. You could, of course, &man.gzip.1; all the files, &man.tar.1; them to the floppies, then &man.gunzip.1; the files again! How do I restore my backups? To restore the entire archive use: &prompt.root; tar Mxvf /dev/rfd0 To restore only specific files you can either start with the first floppy and use: &prompt.root; tar Mxvf /dev/rfd0 filename &man.tar.1; will prompt you to insert subsequent floppies until it finds the required file. Alternatively, if you know which floppy the file is on then you can simply insert that floppy and use the same command as above. Note that if the first file on the floppy is a continuation from the previous one then &man.tar.1; will warn you that it cannot restore it, even if you have not asked it to! diff --git a/en_US.ISO_8859-1/books/handbook/basics/chapter.sgml b/en_US.ISO_8859-1/books/handbook/basics/chapter.sgml index 70569d401a..8fd4e94856 100644 --- a/en_US.ISO_8859-1/books/handbook/basics/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/basics/chapter.sgml @@ -1,543 +1,543 @@ Unix Basics Synopsis Rewritten by Chris Shumway - cshumway@cdrom.com, 10 Mar 2000. + cshumway@osd.bsdi.com, 10 Mar 2000. The following chapter will cover the basic commands and functionality of the FreeBSD operating system. If you are new to FreeBSD, you will definitely want to read through this chapter before asking for help. Permissions FreeBSD, having its history rooted in BSD UNIX, has its fundamentals based on several key UNIX concepts. The first, and most pronounced, is that FreeBSD is a multi-user operating system. The system can handle several users all working simultaneously on completely unrelated tasks. The system is responsible for properly sharing and managing requests for hardware devices, peripherals, memory, and CPU time evenly to each user. Because the system is capable of supporting multiple users, everything the system manages has a set of permissions governing who can read, write, and execute the resource. These permissions are stored as an octet broken into three pieces, one for the owner of the file, one for the group that the file belongs to, and one for everyone else. This numerical representation works like this: Value Permission Directory Listing 0 No read, no write, no execute --- 1 No read, no write, execute --x 2 No read, write, no execute -w- 3 No read, write, execute -wx 4 Read, no write, no execute r-- 5 Read, no write, execute r-x 6 Read, write, no execute rw- 7 Read, write, execute rwx For the long directory listing by ls -l, a column will show a file's permissions for the owner, group, and everyone else. Here's how it is broken up: -rw-r--r-- The first character, from left to right, is a special character that tells if this is a regular file, a directory, a special character or block device, a socket, or any other special pseudo-file device. The next three characters, designated as rw- gives the permissions for the owner of the file. The next three characters, r-- gives the permissions for the group that the file belongs to. The final three characters, r--, gives the permissions for the rest of the world. A dash means that the permission is turned off. In the case of this file, the permissions are set so the owner can read and write to the file, the group can read the file, and the rest of the world can only read the file. According to the table above, the permissions for this file would be 644, where each digit represents the three parts of the file's permission. This is all well and good, but how does the system control permissions on devices? FreeBSD actually treats most hardware devices as a file that programs can open, read, and write data to just like any other file. These special device files are stored on the /dev directory. Directories are also treated as files. They have read, write, and execute permissions. The executable bit for a directory has a slightly different meaning than that of files. When a directory is marked executable, it means it can be searched into, for example, a directory listing can be done in that directory. There are more to permissions, but they are primarily used in special circumstances such as setuid binaries and sticky directories. If you want more information on file permissions and how to set them, be sure to look at the &man.chmod.1; man page. Directory Structures Since FreeBSD uses its file systems to determine many fundamental system operations, the hierarchy of the file system is extremely important. Due to the fact that the &man.hier.7; man page provides a complete description of the directory structure, it will not be duplicated here. Please read &man.hier.7; for more information. Of significant importance is the root of all directories, the / directory. This directory is the first directory mounted at boot time and it contains the base system necessary at boot time. The root directory also contains mount points for every other file system that you want to mount. A mount point is a directory where additional file systems can be grafted onto the root file system. Standard mount points include /usr, /var, /mnt, and /cdrom. These directories are usually referenced to entries in the file /etc/fstab. /etc/fstab is a table of various file systems and mount points for reference by the system. Most of the file systems in /etc/fstab are mounted automatically at boot time from the script &man.rc.8; unless they contain the option. Consult the &man.fstab.5; manual page for more information on the format of the /etc/fstab file and the options it contains. Shells In FreeBSD, a lot of everyday work is done in a command line interface called a shell. A shell's main job is to take commands from the input channel and execute them. A lot of shells also have built in functions to help everyday tasks such a file management, file globing, command line editing, command macros, and environment variables. FreeBSD comes with a set of shells, such as sh, the Bourne Shell, and csh, the C-shell. Many other shells are available from the FreeBSD Ports Collection that have much more power, such as tcsh and bash. Which shell do you use? It is really a matter of taste. If you are a C programmer you might feel more comfortable with a C-like shell such as tcsh. If you've come from Linux or are new to a UNIX command line interface you might try bash. The point is that each shell has unique properties that may or may not work with your preferred working environment, and that you have a choice of what shell to use. One common feature in a shell is file-name completion. Given the typing of the first few letters of a command or filename, you can usually have the shell automatically complete the rest of the command or filename by hitting the TAB key on the keyboard. Here is an example. I have two files called foobar and foo.bar. I want to delete foo.bar. So what I would type on the keyboard is: rm fo[TAB].[TAB]. The shell would print out rm foo[BEEP].bar. The [BEEP] is the console bell, which is the shell telling me it was unable to totally complete the filename because there is more than one match. Both foobar and foo.bar start with fo, but it was able to complete to foo. Once I typed in ., then hit TAB again, the shell was able to fill in the rest of the filename for me. Another function of the shell is environment variables. Environment variables are a variable key pair stored in the shell's environment space. This space can be read by any program invoked by the shell, and thus contains a lot of program configuration. Here is a list of common environment variables and what they mean: Variable Description USER Current logged in user's name. PATH Colon separated list of directories to search for binaries. DISPLAY Network name of the X11 display to connect to, if available. SHELL The current shell. TERM The name of the user's terminal. Used to determine the capabilities of the terminal. TERMCAP Database entry of the terminal escape codes to perform various terminal functions. OSTYPE Type of operating system. E.g., FreeBSD. MACHTYPE The CPU architecture that the system is running on. EDITOR The user's preferred text editor. PAGER The user's preferred text pager. MANPATH Colon separated list of directories to search for manual pages. To view or set an environment variable differs somewhat from shell to shell. For example, in the C-Style shells such as tcsh and csh, you would use setenv to set and view environment variables. Under Bourne shells such as sh and bash, you would use set and export to view and set your current environment variables. For example, to set or modify the EDITOR environment variable, under csh or tcsh a command like this would set EDITOR to /usr/local/bin/emacs: &prompt.user; setenv EDITOR /usr/local/bin/emacs Under Bourne shells: &prompt.user; export EDITOR="/usr/local/bin/emacs" You can also make most shells expand the environment variable by placing a $ character in front of it on the command line. For example, echo $TERM would print out whatever $TERM is set to, because the shell expands $TERM and passes it on to echo. Shells treat a lot of special characters, called meta-characters as special representations of data. The most common one is the * character, which represents any number of characters in a filename. These special meta-characters can be used to do file name globing. For example, typing in echo * is almost the same as typing in ls because the shell takes all the files that match * and puts them on the command line for echo to see. To prevent the shell from interpreting these special characters, they can be escaped from the shell by putting a backslash (\) character in front of them. echo $TERM prints whatever your terminal is set to. echo \$TERM prints $TERM as is. Changing your shell The easiest way to change your shell is to use the chsh command. Running chsh will place you into the editor that is in your EDITOR environment variable; if it is not set, you will be placed in vi. Change the Shell: line accordingly. You can also give chsh the option; this will set your shell for you, without requiring you to enter an editor. For example, if you wanted to change your shell to bash, the following should do the trick: &prompt.user; chsh -s /usr/local/bin/bash Running chsh with no parameters and editing the shell from there would work also. The shell that you wish to use must be present in the /etc/shells file. If you have installed a shell from the ports collection, then this should have been done for you already. If you installed the shell by hand, you must do this. For example, if you installed bash by hand and placed it into /usr/local/bin, you would want to: &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells Then rerun chsh. Text Editors A lot of configuration in FreeBSD is done by editing a text file. Because of this, it would be a good idea to become familiar with a text editor. FreeBSD comes with a few as part of the base system, and many more are available in the ports collection. The easiest and simplest editor to learn is an editor called ee, which stands for easy editor. To start ee, one would type at the command line ee filename where filename is the name of the file to be edited. For example, to edit /etc/rc.conf, type in ee /etc/rc.conf. Once inside of ee, all of the commands for manipulating the editor's functions are listed at the top of the display. The caret ^ character means the control key on the keyboard, so ^e expands to pressing the control key plus the letter e. To leave ee, hit the escape key, then choose leave editor. The editor will prompt you to save any changes if the file has been modified. FreeBSD also comes with more powerful text editors such as vi as part of the base system, and emacs and vim as part of the FreeBSD ports collection. These editors offer much more functionality and power at the expense of being a little more complicated to learn. However if you plan on doing a lot of text editing, learning a more powerful editor such as vim or emacs will save you much more time in the long run. For More Information... Manual pages The most comprehensive documentation on FreeBSD is in the form of man pages. Nearly every program on the system comes with a short reference manual explaining the basic operation and various arguments. These manuals can be viewed with the man command. Use of the man command is simple: &prompt.user; man command command is the name of the command you wish to learn about. For example, to learn more about ls command type: &prompt.user; man ls The online manual is divided up into numbered sections: User commands. System calls and error numbers. Functions in the C libraries. Device drivers. File formats. Games and other diversions. Miscellaneous information. System maintenance and operation commands. Kernel developers. In some cases, the same topic may appear in more than one section of the online manual. For example, there is a chmod user command and a chmod() system call. In this case, you can tell the man command which one you want by specifying the section: &prompt.user; man 1 chmod This will display the manual page for the user command chmod. References to a particular section of the online manual are traditionally placed in parenthesis in written documentation, so &man.chmod.1; refers to the chmod user command and &man.chmod.2; refers to the system call. This is fine if you know the name of the command and simply wish to know how to use it, but what if you cannot recall the command name? You can use man to search for keywords in the command descriptions by using the switch: &prompt.user; man -k mail With this command you will be presented with a list of commands that have the keyword mail in their descriptions. This is actually functionally equivalent to using the apropos command. So, you are looking at all those fancy commands in /usr/bin but do not have the faintest idea what most of them actually do? Simply do: &prompt.user; cd /usr/bin &prompt.user; man -f * or &prompt.user; cd /usr/bin &prompt.user; whatis * which does the same thing. GNU Info Files FreeBSD includes many applications and utilities produced by the Free Software Foundation (FSF). In addition to man pages, these programs come with more extensive hypertext documents called info files which can be viewed with the info command or, if you installed emacs, the info mode of emacs. To use the &man.info.1; command, simply type: &prompt.user; info For a brief introduction, type h. For a quick command reference, type ?. diff --git a/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml b/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml index 2d354a1f90..d1c2c988c8 100644 --- a/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/boot/chapter.sgml @@ -1,549 +1,549 @@ The FreeBSD Booting Process Synopsis FreeBSD uses a three-stage bootstrap by default, which basically entails three programs which call each other in order (two boot blocks, and the loader). Each of these three build on the previous program's understanding and provide increasing amounts of sophistication. The kernel is then started, which will then probe for devices and initialize them for use. Once the kernel boot process is finished, the kernel passes control to the user process &man.init.8;, which then makes sure the disks are in a usable state. &man.init.8; then starts the user-level resource configuration which then mounts filesystems, sets up network cards to act on the network, and generally starts all the processes that usually are run on a FreeBSD system at startup. The Boot Blocks: Bootstrap Stages 1 and 2 Bootstrapping is the process whereby a computer probes and initializes its devices, and works out what programs it is supposed to run. This involves the use of special Read Only Memory chips, which determine what further operations to do, and these usually pass control to other chips that do consistency and memory tests, configure devices, and provide a mechanism for programs to determine what configuration details were determined. In standard personal computers, this involves the BIOS (which oversees the bootstrap), and CMOS (which stores configuration). BIOS and CMOS understand disks, and also understand where on the disk to find a program that will know how to load up an operating system. This chapter will not deal with this first part of the bootstrap process. Instead it will focus on what happens after control is passed to the program on the disk. The boot blocks are responsible for finding (usually) the loader, and running it, and thus need to understand how to find that program on the filesystem, how to run the program, and also allow minor configuration of how they work. boot0 There is actually a preceding bootblock, named boot0, which lives on the Master Boot Record, the special part of the disk that the system bootstrap looks for and runs, and it simply shows a list of possible slices to boot from. boot0 is very simple, since the program in the MBR can only be 512 bytes in size. It displays something like this: boot0 screenshot F1 DOS F2 FreeBSD F3 Linux F4 ?? F5 Drive 1 Default: F2 boot1 boot1 is found on the boot sector of the boot slice, which is where boot0, or any other program on the MBR expects to find the program to run to continue the boot process. boot1 is very simple, since it too can only be 512 bytes in size, and knows just enough about the FreeBSD disklabel, which stores information about the slice, to find and execute boot2. boot2 boot2 is slightly more sophisticated, and understands the FreeBSD filesystem enough to find files on it, and can provide a simple interface to choose the kernel or loader to run. Since the loader is much more sophisticated, and provides a nice easy-to-use boot configuration, boot2 usually runs it, but previously it was tasked to run the kernel directly. boot2 screenshot >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/kernel boot: Loader: Bootstrap Stage Three The loader is the final stage of the three-stage bootstrap, and is located on the filesystem, usually as /boot/loader. While /boot/boot0, /boot/boot1, and /boot/boot2 are files there, they are not the actual copies in the MBR, the boot sector, or the disklabel respectively. The loader is intended as a user-friendly method for configuration, using an easy-to-use built-in command set, backed up by a more powerful interpreter, with a more complex command set. Loader Program Flow During initialization, the loader will probe for a console and for disks, and figure out what disk it is booting from. It will set variables accordingly, and then the interpreter is started, and the easy-to-use commands are explained to it. loader will then read /boot/loader.rc, which by default reads in /boot/defaults/loader.conf which sets reasonable defaults for variables and reads /boot/loader.conf for local changes to those variables. loader.rc then acts on these variables, loading whichever modules and kernel are selected. Finally, by default, the loader issues a 10 second wait - for keypresses, and boots the kernel if it is not interrupted. + for key presses, and boots the kernel if it is not interrupted. If interrupted, the user is presented with a prompt which understands the easy-to-use command set, where the user may adjust variables, unload all modules, load modules, and then finally boot or reboot. A more technical discussion of the process is available in &man.loader.8; Loader Built-In Commands The easy-to-use command set comprises of: autoboot seconds Proceeds to boot the kernel if not interrupted within the time span given, in seconds. It displays a countdown, and the default timespan is 10 seconds. boot -options kernelname Immediately proceeds to boot the kernel, with the given options, if any, and with the kernel name given, if it is. boot-conf Goes through the same automatic configuration of modules based on variables as what happens at boot. This only makes sense if you use unload first, and change some variables, most commonly kernel. help topic Shows help messages read from /boot/loader.help. If the topic given is index, then the list of available topics is given. include filename … Processes the file with the given filename. The file is read in, and interpreted line by line. An error immediately stops the include command. load type filename Loads the kernel, kernel module, or file of the type given, with the filename given. Any arguments after filename are passed to the file. ls path Displays a listing of files in the given path, or the root directory, if the path is not specified. If is specified, file sizes will be shown too. lsdev Lists all of the devices from which it may be possible to load modules. If is specified, more details are printed. lsmod Displays loaded modules. If is specified, more details are shown. more filename Display the files specified, with a pause at each LINES displayed. reboot Immediately reboots the system. set variable set variable=value Set loader's environment variables. unload Removes all loaded modules. Loader Examples Here are some practical examples of loader usage. To simply boot your usual kernel, but in single-user mode: boot -s To unload your usual kernel and modules, and then load just your old (or another) kernel: unload load kernel.old You can use kernel.GENERIC to refer to the generic kernel that comes on the install disk, or kernel.old to refer to your previously installed kernel (when you've upgraded or configured your own kernel, for example). Use the following to load your usual modules with another kernel: unload set kernel="kernel.old" boot-conf To load a kernel configuration script (an automated script which does the things you'd normally do in the kernel boot-time configurator): load -t userconfig_script /boot/kernel.conf Kernel Interaction During Boot Once the kernel is loaded by either loader (as usual) or boot2 (bypassing the loader), it examines its boot flags, if any, and adjusts its behavior as necessary. Kernel Boot Flags Here are the more common boot flags: during kernel initialization, ask for the device to mount as as the root file system. boot from CDROM. run UserConfig, the boot-time kernel configurator boot into single-user mode be more verbose during kernel startup There are other boot flags, read &man.boot.8; for more information on them. Init: Process Control Initialization Once the kernel has finished booting, it passes control to the user process init, which is located at /sbin/init, or the program path specified in the init_path variable in loader. Automatic Reboot Sequence The automatic reboot sequence makes sure that the filesystems available on the system are consistent. If they are not, and fsck can not fix the inconsistencies, init drops the system into single-user mode for the system administrator to take care of the problems directly. Single-User Mode This mode can be reached through the automatic reboot sequence, or by the user booting with the or setting the boot_single variable in loader. It can also be reached by calling shutdown without the reboot () or halt () options, from multi-user mode. If the system console console is set to insecure in /etc/ttys, then the system prompts for the root password before initiating single-user mode. An insecure console in /etc/ttys # name getty type status comments # # This entry needed for asking password when init goes to single-user mode # If you want to be asked for password, change "secure" to "insecure" here console none unknown off insecure An insecure console means that you consider your physical security to the console to be insecure, and want to make sure only someone who knows the root password may use single-user mode, and it does not mean that you want to run your console insecurely. Thus, if you want security, choose insecure, not secure. Multi-User Mode If init finds your filesystems to be in order, or once the user has finished in single-user mode, the system enters multi-user mode, in which it starts the resource configuration of the system. Resource Configuration (rc) The resource configuration system reads in configuration defaults from /etc/defaults/rc.conf, and system-specific details from /etc/rc.conf, and then proceeds to mount the system filesystems mentioned in /etc/fstab, start up networking services, starts up miscellaneous system daemons, and finally runs the startup scripts of locally installed packages. &man.rc.8; is a good reference to the resource configuration system, as is examining the scripts themselves. Shutdown Sequence Upon controlled shutdown, via shutdown, init will attempt to run the script /etc/rc.shutdown, and then proceed to send all processes the terminate signal, and subsequently the kill signal to any that don't terminate timely. diff --git a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml index e5c3c3be2e..c7db1f849b 100644 --- a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml @@ -1,6208 +1,6208 @@ Contributing to FreeBSD Contributed by &a.jkh;. So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth! Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our TODO list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project! Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is Needed The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers; Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs; Clean up and document the nullfs filesystem code. Coordinator: &a.eivind; Fix the union file system. Coordinator: &a.dg; Implement Int13 vm86 disk driver. Coordinator: &a.hackers; New bus architecture. Coordinator: &a.newbus; Port existing ISA drivers to new architecture. Move all interrupt-management code to appropriate parts of the bus drivers. Port PCI subsystem to new architecture. Coordinator: &a.dfr; Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented. Resolve the probe/attach priority issue once and for all. Move any remaining buses over to the new architecture. Kernel issues. Overall coordination: &a.hackers; Add more pro-active security infrastructure. Overall coordination: &a.security; Build something like Tripwire(TM) into the kernel, with a remote and local part. There are a number of cryptographic issues to getting this right; contact the coordinator for details. Coordinator: &a.eivind; Make the entire kernel use suser() instead of comparing to 0. It is presently using about half of each. Coordinator: &a.eivind; Split securelevels into different parts, to allow an administrator to throw away those privileges he can throw away. Setting the overall securelevel needs to have the same effect as now, obviously. Coordinator: &a.eivind; Make it possible to upload a list of allowed program to BPF, and then block BPF from accepting other programs. This would allow BPF to be used e.g. for DHCP, without allowing an attacker to start snooping the local network. Update the security checker script. We should at least grab all the checks from the other BSD derivatives, and add checks that a system with securelevel increased also have reasonable flags on the relevant parts. Coordinator: &a.eivind; Add authorization infrastructure to the kernel, to allow different authorization policies. Part of this could be done by modifying suser(). Coordinator: &a.eivind; Add code to the NFS layer so that you cannot chdir("..") out of an NFS partition. E.g., /usr is a UFS partition with /usr/src NFS exported. Now it is possible to use the NFS filehandle for /usr/src to get access to /usr. Medium priority tasks The following tasks need to be done, but not with any particular urgency: Full KLD based driver support/Configuration Manager. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.imp; Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.msmith; and &a.phk; APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks 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: The first N items are from Terry Lambert terry@lambert.org NetWare Server (protected mode ODI driver) loader and sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting internal v.s.. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Smaller tasks 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. If you run FreeBSD-current and have a good Internet connection, there is a machine current.FreeBSD.org which builds a full release once a day — every now and again, try and install the latest release from it and report any failures in the process. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions). Help translate FreeBSD documentation into your native language (if not already available) — just send an email to &a.doc; asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this — in fact, the documentation most in need of translation is the installation instructions. Read the freebsd-questions mailing list and &ng.misc occasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on. If you know of any bug fixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder. Move contributed software to src/contrib in the source tree. Make sure code in src/contrib is up to date. Look for year 2000 bugs (and fix any you find!) Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings. Fix warnings for ports which do deprecated things like using gets() or including malloc.h. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version) Suggest further tasks for this list! Work through the PR database The FreeBSD PR list shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users. Look through the open PRs, and see if anything there takes your interest. Some of these might be very simple tasks, that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one. Others might be much more complex. Start with the PRs that have not been assigned to anyone else, but if one them is assigned to someone else, but it looks like something you can handle, e-mail the person it is assigned to and ask if you can work on it—they might already have a patch ready to be tested, or further ideas that you can discuss with them. How to Contribute Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information about this and other mailing lists. If you find a bug or are submitting a specific change, please report it using the &man.send-pr.1; program or its WEB-based equivalent. Try to fill-in each field of the bug report. Unless they exceed 65KB, include any patches directly in the report. When including patches, do not use cut-and-paste because cut-and-paste turns tabs into spaces and makes them unusable. Consider compressing patches and using &man.uuencode.1; if they exceed 20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/. After filing a report, you should receive confirmation along with a tracking number. Keep this tracking number so that you can update us with details about the problem by sending mail to bug-followup@FreeBSD.org. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the &man.send-pr.1; command, then you may ask someone to file it for you by sending mail to the &a.bugs;. Changes to the documentation Changes to the documentation are overseen by the &a.doc;. Send submissions and changes (even small ones are welcome!) using send-pr as described in Bug Reports and General Commentary. Changes to existing source code 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 Staying current with FreeBSD for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce; and the &a.current; lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the &man.diff.1; command, with the context diff form being preferred. For example: &prompt.user; diff -c oldfile newfile or &prompt.user; diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for &man.diff.1; for more details. Once you have a set of diffs (which you may test with the &man.patch.1; command), you should submit them for inclusion with FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary. Do not just send the diffs to the &a.hackers; or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the pr database until we do. If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a tar file and run the &man.uuencode.1; program on it. Shar archives are also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, then you should send it to &a.core; directly rather than submitting it with &man.send-pr.1;. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code. New code or major value-added packages In the 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 uuencoded tar files or upload them to a web or FTP site for other people to access. If you do not have access to a web or FTP site, ask on an appropriate FreeBSD mailing list for someone to host the changes for you. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its no strings attached nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or GPL. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem. Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a BSD-style copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the %% with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. Money, Hardware or Internet access 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. <anchor id="donations">Donating funds 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. FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(currently using the BSDi address until a PO box can be opened) Wire transfers may also be sent directly to:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to &a.jkh, either via email or to the FreeBSD, Inc. postal address given above. If you do not wish to be listed in our donors section, please specify this when making your donation. Thanks! Donating hardware Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.dg; for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of new hardware. Donating Internet access We can always use new mirror sites for FTP, WWW or cvsup. If you would like to be such a mirror, please contact the FreeBSD project administrators hubs@FreeBSD.org for more information. Donors Gallery The FreeBSD Project is indebted to the following donors and would like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine to eventually replace freefall.FreeBSD.org by donating the following items: &a.mbarkah and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200Mhz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Blue Mountain Arts Epilogue Technology Corporation &a.sef Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier Chris Silva Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: BSDi for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB - fileservers, twelve Ethernets, two routers and an ATM switch for + file servers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. &a.chuck; contributed his floppy tape streamer for experimental work. Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-) Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD/. Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! Christoph Kukulies kuku@FreeBSD.org donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Special contributors: BSDi (formerly Walnut Creek CDROM) has donated almost more than we can say (see the history document for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting &a.joerg; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. Core Team Alumni 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. In rough chronological order: &a.ache (1993 - 2000) &a.jmb (1993 - 2000) &a.bde (1992 - 2000) &a.gibbs (1993 - 2000) &a.rich (1994 - 2000) &a.phk (1992 - 2000) &a.gpalmer (1993 - 2000) &a.sos (1993 - 2000) &a.wollman (1993 - 2000) &a.joerg (1993 - 2000) &a.jdp (1997 - 2000) &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Development Team Alumni The following people were members of the FreeBSD development team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.tedm (???? - 2000) &a.karl (???? - 2000) &a.gclarkii (???? - 2000) &a.jraynard (???? - 2000) &a.jgreco (???? - 1999) &a.ats (???? - 1999) Jamil Weatherby (1997 - 1999) meganm (???? - 1998) &a.dyson (???? - 1998) Amancio Hasty (1997 - 1998) Drew Derbyshire (1997 - 1998) Derived Software Contributors 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. There are also portions of NetBSD and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com Adrian Colley aecolley@ois.ie Adrian Hall ahall@mirapoint.com Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex G. Bulushev bag@demos.su Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex Le Heux alexlh@funk.org Alex Kapranoff kappa@zombie.antar.bryansk.ru Alex Perel veers@disturbed.net Alex Varju varju@webct.com Alex Zepeda garbanzo@hooked.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andrey Tchoritch andy@venus.sympad.net Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Ask Bjoern Hansen ask@valueclick.com Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Chapman chapmanb@arches.uga.edu Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher N. Harrell cnh@ivmg.net Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@home.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Cyrille Lefevre clefevre@citeweb.net Cyrus Rahman cr@jcmax.com Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@eece.unm.edu David Borman dab@bsdi.com David W. Chapman Jr. dwcjr@inethouston.net David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Sugar dyfet@gnu.org David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Denis Shaposhnikov dsh@vlink.ru Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dirk Keunecke dk@panda.rhein-main.de Dirk Meyer dirk.meyer@dinoex.sub.org Dirk Nehrling nerle@pdv.de Dishanker Rajakulendren draj@oceanfree.net Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Domas Mituzas midom@dammit.lt Dominik Brettnacher domi@saargate.de Dominik Rothert dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us Donn Miller dmmiller@cvzoom.net Dan Pelleg dpelleg+unison@cs.cmu.edu &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp Eike Bernhardt eike.bernhardt@gmx.de ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eagriff@global2000.net Eric Melville eric@osd.bsdi.com Eric Blood eblood@cs.unr.edu Eric D. Futch efutch@nyct.net Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erich Zigler erich@tacni.net Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@coredumped.null.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp G. Adam Stanislavadam@whizkidtech.net Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Gene Raytsin pal@paladin7.net Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com George Reid services@nevernet.net Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giorgos Keramidas keramida@ceid.upatras.gr Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Lamm holger@eit.uni-kl.de Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilia Chipitsine ilia@jane.cgu.chel.su Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jay Krell jay.krell@cornell.edu Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer jeff@isni.net Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@noc.dfn.d Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Karlson karlj000@unbc.ca Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse McConnell jesse@cylant.com Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Sloan odinn@atlantabiker.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jimmy Olgeni olgeni@uli.it Jin Guojun jin@george.lbl.gov Joachim Kuebart kuebart@mathematik.uni-ulm.de Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Joseph Scott joseph.scott@owp.csus.edu Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jau@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv Justin Stanford jus@security.za.net K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kim Scarborough sluggo@unknown.nu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Herrmann klaus.herrmann@gmx.net Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Konstantin Chuguev Konstantin.Chuguev@dante.org.uk Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Leo Kim leo@florida.sarang.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M. L. Dodson bdodson@scms.utmb.EDU M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Makoto YAMAKURA makoto@pinpott.spnet.ne.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Knight markk@knigma.org Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk Markus Holmberg saska@acc.umu.se Martin Birgmeier Martin Blapp blapp@attic.ch Martin Hinner mhi@linux.gyarab.cz Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masahiro TAKEMURA mastake@msel.t.u-tokyo.ac.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Emmerton root@gabby.gsicomp.on.ca Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Maxime Henrion mhenrion@cybercable.fr Micha Class michael_class@hpbbse.bbn.hp.com Michael Lucas mwlucas@blackhelicopters.org Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Barcroft mike@q9media.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@mired.org Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.algebra.com Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW MITA Yoshio mita@jp.FreeBSD.org Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Ahlstrom nrahlstr@winternet.com Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nicholas Esborn nick@netdot.net Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net &a.nsayer; Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oddbjorn Steffenson oddbjorn@tricknology.org Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Helmling oliver.helmling@stud.uni-bayreuth.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Bihan-Faou patrick@mindstep.com Patrick Hausen unknown Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Per Wigren wigren@home.se Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Peter van Heusden pvh@egenetics.com Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Philippe Lefebvre nemesis@balistik.net Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Rasmus Kaj kaj@Raditex.se Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@enteract.com Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Rod Taylor rod@idiotswitch.org Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Ryuichiro IMURA imura@af.airnet.ne.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey Potapov sp@alkor.ru Sergey Samoyloff gonza@techline.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shinya FUJIE fujie@tk.elec.waseda.ac.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon Dick simond@irrelevant.org Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stijn Hoop stijn@win.tue.nl Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sungman Cho smcho@tsp.korea.ac.kr Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp TAKAHASHI Kaoru kaoru@kaisei.org Takahiro Yugawa yugawa@orleans.rim.or.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas Quinot thomas@cuivre.fr.eu.org Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Tobias Reifenberger treif@mayn.de Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher Tony.Maher@eBioinformatics.com Torbjorn Granlund tege@matematik.su.se Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko SARUMRU mistral@imasy.or.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall ahall@mirapoint.com Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Antony Halse guy@rucus.ru.ac.za Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il diff --git a/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml b/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml index 025a3d710f..d655eb0007 100644 --- a/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml @@ -1,901 +1,901 @@ Disks Synopsis This chapter covers how to use disks, whether physical, memory, or networked, on FreeBSD. BIOS Drive Numbering Before you install and configure FreeBSD on your system, there is an important subject that you should be aware of if, especially if you have multiple hard drives. In a PC running DOS or any of the BIOS-dependent operating systems (WINxxx), the BIOS is able to abstract the normal disk drive order, and the operating system goes along with the change. This allows the user to boot from a disk drive other than the so-called primary master. This is especially convenient for some users who have found that the simplest and cheapest way to keep a system backup is to buy an identical second hard drive, and perform routine copies of the first drive to the second drive using Ghost or XCOPY. Then, if the first drive fails, or is attacked by a virus, or is scribbled upon by an operating system defect, he can easily recover by instructing the BIOS to logically swap the drives. It's like switching the cables on the drives, but without having to open the case. More expensive systems with SCSI controllers often include BIOS extensions which allow the SCSI drives to be re-ordered in a similar fashion for up to seven drives. A user who is accustomed to taking advantage of these features may become surprised when the results with FreeBSD are not as expected. FreeBSD does not use the BIOS, and does not know the logical BIOS drive mapping. This can lead to very perplexing situations, especially when drives are physically identical in geometry, and have also been made as data clones of one another. When using FreeBSD, always restore the BIOS to natural drive numbering before installing FreeBSD, and then leave it that way. If you need to switch drives around, then do so, but do it the hard way, and open the case and move the jumpers and cables. An illustration from the files of Bill and Fred's Exceptional Adventures: Bill breaks-down an older Wintel box to make another FreeBSD box for Fred. Bill installs a single SCSI drive as SCSI unit zero, and installs FreeBSD on it. Fred begins using the system, but after several days notices that the older SCSI drive is reporting numerous soft errors, and reports this fact to Bill. After several more days, Bill decides it's time to address the situation, so he grabs an identical SCSI drive from the disk drive "archive" in the back room. An initial surface scan indicates that this drive is functioning well, so Bill installs this drive as SCSI unit four, and makes an image copy from drive zero to drive four. Now that the new drive is installed and functioning nicely, Bill decides that it's a good idea to start using it, so he uses features in the SCSI BIOS to re-order the disk drives so that the system boots from SCSI unit four. FreeBSD boots and runs just fine. Fred continues his work for several days, and soon Bill and Fred decide that it's time for a new adventure -- time to upgrade to a newer version of FreeBSD. Bill removes SCSI unit zero because it was a bit flaky, and replaces it with another identical disk drive from the "archive." Bill then installs the new version of FreeBSD onto the new SCSI unit zero using Fred's magic internet FTP floppies. The installation goes well. Fred uses the new version of FreeBSD for a few days, and certifies that it is good enough for use in the engineering department...it's time to copy all of his work from the old version. So Fred mounts SCSI unit four (the latest copy of the older FreeBSD version). Fred is dismayed to find that none of his precious work is present on SCSI unit four. Where did the data go? When Bill made an image copy of the original SCSI unit zero onto SCSI unit four, unit four became the "new clone," When Bill re-ordered the SCSI BIOS so that he could boot from SCSI unit four, he was only fooling himself. FreeBSD was still running on SCSI unit zero. Making this kind of BIOS change will cause some or all of the Boot and Loader code to be fetched from the selected BIOS drive, but when the FreeBSD kernel drivers take-over, the BIOS drive numbering will be ignored, and FreeBSD will transition back to normal drive numbering. In the illustration at hand, the system continued to operate on the original SCSI unit zero, and all of Fred's data was there, not on SCSI unit four. The fact that the system appeared to be running on SCSI unit four was simply an artifact of human expectations. We are delighted to mention that no data bytes were killed or harmed in any way by our discovery of this phenomenon. The older SCSI unit zero was retrieved from the bone pile, and all of Fred's work was returned to him, (and now Bill knows that he can count as high as zero). Although SCSI drives were used in this illustration, the concepts apply equally to IDE drives. Disk Naming Physical drives come in two main flavors, IDE, or SCSI; but there are also drives backed by RAID controllers, flash memory, and so forth. Since these behave quite differently, they have their own drivers and devices. Physical Disk Naming Conventions Drive type Drive device name IDE hard drives ad in 4.0-RELEASE, wd before 4.0-RELEASE. IDE CDROM drives acd from 3.1-RELEASE, wcd before 4.0-RELEASE. SCSI hard drives da from 3.0-RELEASE, sd before 3.0-RELEASE. SCSI CDROM drives cd Assorted non-standard CDROM drives mcd for Mitsumi CD-ROM, scd for Sony CD-ROM, matcd for Matsushita/Panasonic CD-ROM Floppy drives fd SCSI tape drives sa from 3.0-RELEASE, st before 3.0-RELEASE. IDE tape drives ast from 4.0-RELEASE, wst before 4.0-RELEASE. Flash drives fla for DiskOnChip Flash device from 3.3-RELEASE. RAID drives myxd for Mylex, and amrd for AMI MegaRAID, idad for Compaq Smart RAID. from 4.0-RELEASE. id between 3.2-RELEASE and 4.0-RELEASE.
Slices and Partitions Physical disks usually contain slices, unless they are dangerously dedicated. Slice numbers follow the device name, prefixed with an s: da0s1. Slices, dangerously dedicated physical drives, and other drives contain partitions, which represented as letters from a to h. b is reserved for swap partitions, and c is an unused partition the size of the entire slice or drive. This is explained in . Mounting and Unmounting Filesystems The filesystem is best visualized as a tree, rooted, as it were, at /. /dev, /usr, and the other directories in the root directory are branches, which may have their own branches, such as /usr/local, and so on. There are various reasons to house certain of these directories on separate filesystems. /var contains log, spool, and various types of temporary files, and as such, may get filled up. Filling up the root filesystem isn't a good idea, so splitting /var from / is often a good idea. Another common reason to contain certain directory trees on other filesystems is if they are to be housed on separate physical disks, or are separate virtual disks, such as Network File System mounts, or CDROM drives. The fstab File During the boot process, filesystems listed in /etc/fstab are automatically mounted (unless they are listed with ). The /etc/fstab file contains a list of lines of the following format: device /mount-point fstype options dumpfreq passno device is a device name (which should exist), as explained in the Disk naming conventions above. mount-point is a directory (which should exist), on which to mount the filesystem. fstype is the filesystem type to pass to &man.mount.8;. The default FreeBSD filesystem is ufs. options is either for read-write filesystems, or for read-only filesystems, followed by any other options that may be needed. A common option is for filesystems not normally mounted during the boot sequence. Other options in the &man.mount.8; manual page. dumpfreq is the number of days the filesystem should be dumped, and passno is the pass number during which the filesystem is mounted during the boot sequence. The mount Command The &man.mount.8; command is what is ultimately used to mount filesystems. In its most basic form, you use: &prompt.root; mount device mountpoint There are plenty of options, as mentioned in the &man.mount.8; manual page, but the most common are: mount options Mount all filesystems in /etc/fstab, as modified by , if given. Do everything but actually mount the filesystem. Force the mounting the filesystem. Mount the filesystem read-only. fstype Mount the given filesystem as the given filesystem type, or mount only filesystems of the given type, if given the option. ufs is the default filesystem type. Update mount options on the filesystem. Be verbose. Mount the filesystem read-write. The takes a comma-separated list of the options, including the following: nodev Do not interpret special devices on the filesystem. Useful security option. noexec Do not allow execution of binaries on this filesystem. Useful security option. nosuid Do not interpret setuid or setgid flags on the filesystem. Useful security option. The umount Command The umount command takes, as a parameter, one of a mountpoint, a device name, or the or option. All forms take to force unmounting, and for verbosity. and are used to unmount all mounted filesystems, possibly modified by the filesystem types listed after . , however, doesn't attempt to unmount the root filesystem. Adding Disks Originally contributed by &a.obrien; 26 April 1998 Lets say we want to add a new SCSI disk to a machine that currently only has a single drive. First turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturer. Due the wide variations of procedures to do this, the details are beyond the scope of this document. Login as user root. After you've installed the drive, inspect /var/run/dmesg.boot to ensure the new disk was found. Continuing with our example, the newly added drive will be da1 and we want to mount it on /1 (if you are adding an IDE drive, it will be wd1 in pre-4.0 systems, or ad1 in most 4.X systems). Because FreeBSD runs on IBM-PC compatible computers, it must take into account the PC BIOS partitions. These are different from the traditional BSD partitions. A PC disk has up to four BIOS partition entries. If the disk is going to be truly dedicated to FreeBSD, you can use the dedicated mode. Otherwise, FreeBSD will have to live with in one of the PC BIOS partitions. FreeBSD calls the PC BIOS partitions, slices so as not to confuse them with traditional BSD partitions. You may also use slices on a disk that is dedicated to FreeBSD, but used in a computer that also has another operating system installed. This is to not confuse the fdisk utility of the other operating system. In the slice case the drive will be added as /dev/da1s1e. This is read as: SCSI disk, unit number 1 (second SCSI disk), slice 1 (PC BIOS partition 1), and e BSD partition. In the dedicated case, the drive will be added simply as /dev/da1e. Using sysinstall You may use /stand/sysinstall to partition and label a new disk using its easy to use menus. Either login as user root or use the su command. Run /stand/sysinstall and enter the Configure menu. With in the FreeBSD Configuration Menu, scroll down and select the Partition item. Next you should be presented with a list of hard drives installed in your system. If you do not see da1 listed, you need to recheck your physical installation and dmesg output in the file /var/run/dmesg.boot. Select da1 to enter the FDISK Partition Editor. Choose A to use the entire disk for FreeBSD. When asked if you want to remain cooperative with any future possible operating systems, answer YES. Write the changes to the disk using W. Now exit the FDISK editor using q. Next you will be asked about the Master Boot Record. Since you are adding a disk to an already running system, choose None. Next enter the Disk Label Editor. This is where you will create the traditional BSD partitions. A disk can have up to eight partitions, labeled a-h. A few of the partition labels have special uses. The a partition is used for the root partition (/). Thus only your system disk (e.g, the disk you boot from) should have an a partition. The b partition is used for swap partitions, and you may have many disks with swap partitions. The c partition addresses the entire disk in dedicated mode, or the entire FreeBSD slice in slice mode. The other partitions are for general use. Sysinstall's Label editor favors the e partition for non-root, non-swap partitions. With in the Label editor, create a single file system using C. When prompted if this will be a FS (file system) or swap, choose FS and give a mount point (e.g, /mnt). When adding a disk in post-install mode, Sysinstall will not create entries in /etc/fstab for you, so the mount point you specify isn't important. You are now ready to write the new label to the disk and create a file system on it. Do this by hitting W. Ignore any errors from Sysinstall that it could not mount the new partition. Exit the Label Editor and Sysinstall completely. The last step is to edit /etc/fstab to add an entry for your new disk. Using Command Line Utilities Using Slices This setup will allow your disk to work correctly with other operating systems that might be installed on your computer and will not confuse other operating systems' fdisk utilities. It is recommended to use this method for new disk installs. Only use dedicated mode if you have a good reason to do so! &prompt.root; dd if=/dev/zero of=/dev/rda1 bs=1k count=1 &prompt.root; fdisk -BI da1 #Initialize your new disk &prompt.root; disklabel -B -w -r da1s1 auto #Label it. &prompt.root; disklabel -e da1s1 # Now edit the disklabel you just created and add any partitions. &prompt.root; mkdir -p /1 &prompt.root; newfs /dev/da1s1e # Repeat this for every partition you created. &prompt.root; mount -t ufs /dev/da1s1e /1 # Mount the partition(s) &prompt.root; vi /etc/fstab # When satisfied, add the appropriate entry/entries to your /etc/fstab. - If you have an IDE disk, subsitute ad + If you have an IDE disk, substitute ad for da. On pre-4.x systems use wd. Dedicated If you will not be sharing the new drive with another operating system, you may use the dedicated mode. Remember this mode can confuse Microsoft operating systems; however, no damage will be done by them. IBM's OS/2 however, will appropriate any partition it finds which it doesn't understand. &prompt.root; dd if=/dev/zero of=/dev/rda1 bs=1k count=1 &prompt.root; disklabel -Brw da1 auto &prompt.root; disklabel -e da1 # create the `e' partition &prompt.root; newfs -d0 /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 An alternate method is: &prompt.root; dd if=/dev/zero of=/dev/rda1 count=2 &prompt.root; disklabel /dev/rda1 | disklabel -BrR da1 /dev/stdin &prompt.root; newfs /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 Virtual Disks: Network, Memory, and File-Based Filesystems Besides the disks you physically insert into your computer; floppies, CDs, hard drives, and so forth, other forms of disks are understood by FreeBSD - the virtual disks. These include network filesystems such as the Network Filesystem and Coda, memory-based filesystems such as md and file-backed filesystems created by vnconfig. vnconfig: file-backed filesystem &man.vnconfig.8; configures and enables vnode pseudo disk devices. A vnode is a representation of a file, and is the focus of file activity. This means that &man.vnconfig.8; uses files to create and operate a filesystem. One possible use is the mounting of floppy or CD images kept in files. To mount an existing filesystem image: Using vnconfig to mount an existing filesystem image &prompt.root; vnconfig vn0 diskimage &prompt.root; mount /dev/vn0c /mnt To create a new filesystem image with vnconfig: Creating a New File-Backed Disk with vnconfig &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; vnconfig -s labels -c vn0 newimage &prompt.root; disklabel -r -w vn0 auto &prompt.root; newfs vn0c Warning: 2048 sector(s) in last cylinder unallocated /dev/rvn0c: 10240 sectors in 3 cylinders of 1 tracks, 4096 sectors 5.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 1280 i/g) super-block backups (for fsck -b #) at: 32 &prompt.root; mount /dev/vn0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn0c 4927 1 4532 0% /mnt md: Memory Filesystem md is a simple, efficient means to do memory filesystems. Simply take a filesystem you've prepared with, for example, &man.vnconfig.8;, and: md memory disk &prompt.root; dd if=newimage of=/dev/md0 5120+0 records in 5120+0 records out &prompt.root; mount /dev/md0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0c 4927 1 4532 0% /mnt Disk Quotas Quotas are an optional feature of the operating system that allow you to limit the amount of disk space and/or the number of files a user, or members of a group, may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This will prevent one user from consuming all of the available disk space. Configuring Your System to Enable Disk Quotas Before attempting to use disk quotas it is necessary to make sure that quotas are configured in your kernel. This is done by adding the following line to your kernel configuration file: options QUOTA The stock GENERIC kernel does not have this enabled by default, so you will have to configure, build and install a custom kernel in order to use disk quotas. Please refer to the Configuring the FreeBSD Kernel section for more information on kernel configuration. Next you will need to enable disk quotas in /etc/rc.conf. This is done by adding the line: enable_quotas=YES For finer control over your quota startup, there is an additional configuration variable available. Normally on bootup, the quota integrity of each file system is checked by the quotacheck program. The quotacheck facility insures that the data in the quota database properly reflects the data on the file system. This is a very time consuming process that will significantly affect the time your system takes to boot. If you would like to skip this step, a variable is made available for the purpose: check_quotas=NO If you are running FreeBSD prior to 3.2-RELEASE, the configuration is simpler, and consists of only one variable. Set the following in your /etc/rc.conf: check_quotas=YES Finally you will need to edit /etc/fstab to enable disk quotas on a per-file system basis. This is where you can either enable user or group quotas or both for all of your file systems. To enable per-user quotas on a file system, add the userquota option to the options field in the /etc/fstab entry for the file system you want to to enable quotas on. For example: /dev/da1s2g /home ufs rw,userquota 1 2 Similarly, to enable group quotas, use the groupquota option instead of the userquota keyword. To enable both user and group quotas, change the entry as follows: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 By default the quota files are stored in the root directory of the file system with the names quota.user and quota.group for user and group quotas respectively. See man fstab for more information. Even though that man page says that you can specify an alternate location for the quota files, this is not recommended because the various quota utilities do not seem to handle this properly. At this point you should reboot your system with your new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas you enabled in /etc/fstab, so there is no need to manually create any zero length quota files. In the normal course of operations you should not be required to run the quotacheck, quotaon, or quotaoff commands manually. However, you may want to read their man pages just to be familiar with their operation. Setting Quota Limits Once you have configured your system to enable quotas, verify that they really are enabled. An easy way to do this is to run: &prompt.root; quota -v You should see a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. You are now ready to start assigning quota limits with the edquota command. You have several options on how to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. You may limit allocations based on disk space (block quotas) or number of files (inode quotas) or a combination of both. Each of these limits are further broken down into two categories; hard and soft limits. A hard limit may not be exceeded. Once a user reaches their hard limit they may not make any further allocations on the file system in question. For example, if the user has a hard limit of 500 blocks on a file system and is currently using 490 blocks, the user can only allocate an additional 10 blocks. Attempting to allocate an additional 11 blocks will fail. Soft limits on the other hand can be exceeded for a limited amount of time. This period of time is known as the grace period, which is one week by default. If a user stays over his or her soft limit longer than their grace period, the soft limit will turn into a hard limit and no further allocations will be allowed. When the user drops back below the soft limit, the grace period will be reset. The following is an example of what you might see when you run the edquota command. When the edquota command is invoked, you are placed into the editor specified by the EDITOR environment variable, or in the vi editor if the EDITOR variable is not set, to allow you to edit the quota limits. &prompt.root; edquota -u test Quotas for user test: /usr: blocks in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: blocks in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) You will normally see two lines for each file system that has quotas enabled. One line for the block limits, and one line for inode limits. Simply change the value you want updated to modify the quota limit. For example, to raise this users block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: /usr: blocks in use: 65, limits (soft = 50, hard = 75) to: /usr: blocks in use: 65, limits (soft = 500, hard = 600) The new quota limits will be in place when you exit the editor. Sometimes it is desirable to set quota limits on a range of uids. This can be done by use of the option on the edquota command. First, assign the desired quota limit to a user, and then run edquota -p protouser startuid-enduid. For example, if user test has the desired quota limits, the following command can be used to duplicate those quota limits for uids 10,000 through 19,999: &prompt.root; edquota -p test 10000-19999 See man edquota for more detailed information. Checking Quota Limits and Disk Usage You can use either the quota or the repquota commands to check quota limits and disk usage. The quota command can be used to check individual user and group quotas and disk usage. Only the super-user may examine quotas and usage for other users, or for groups that they are not a member of. The repquota command can be used to get a summary of all quotas and disk usage for file systems with quotas enabled. The following is some sample output from the quota -v command for a user that has quota limits on two file systems. Disk quotas for user test (uid 1002): Filesystem blocks quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 On the /usr file system in the above example this user is currently 15 blocks over their soft limit of 50 blocks and has 5 days of their grace period left. Note the asterisk * which indicates that the user is currently over their quota limit. Normally file systems that the user is not using any disk space on will not show up in the output from the quota command, even if they have a quota limit assigned for that file system. The option will display those file systems, such as the /usr/var file system in the above example. Quotas over NFS Quotas are enforced by the quota subsystem on the NFS server. The &man.rpc.rquotad.8; daemon makes quota information available to the &man.quota.1; command on NFS clients, allowing users on those machines to see their quota statistics. Enable rpc.rquotad in /etc/inetd.conf like so: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Now restart inetd: &prompt.root; kill -HUP `cat /var/run/inetd.pid` diff --git a/en_US.ISO_8859-1/books/handbook/install/chapter.sgml b/en_US.ISO_8859-1/books/handbook/install/chapter.sgml index 82603eb48b..150bce0340 100644 --- a/en_US.ISO_8859-1/books/handbook/install/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/install/chapter.sgml @@ -1,1832 +1,1832 @@ Installing FreeBSD Restructured, updated, and parts rewritten by &a.jim;, January 2000. Synopsis The following chapter will attempt to guide you through the installation of FreeBSD on your system. It can be installed through a variety of methods, including anonymous FTP (assuming you have network connectivity via modem or local network), CDROM, floppy disk, tape, an MS-DOS partition, or even NFS. No matter which method you choose, you will need to get started by creating the installation disks as described in the next section. Booting into the FreeBSD installer, even if you are not planning on installing FreeBSD right away, will provide important information about compatibility with your hardware. This information may dictate which installation options are even possible for you. It can also provide clues early-on in the process to potential problems you may come across later. If you plan to install FreeBSD via anonymous FTP, the only things you will need are the installation floppies. The installation program itself will handle anything else that is required. For more information about obtaining FreeBSD, see the Obtaining FreeBSD section of the Appendix. By now, you are probably wondering what exactly it is you need to do. Continue on to the installation guide. Installation Guide The following sections will guide you through preparing for and actually installing FreeBSD. If you find something missing, please let us know about it by sending email to the &a.doc;. Preparing for the Installation There are various things you should do in preparation for the installation. The following describes what needs to be done prior to each type of installation. The first thing to do is to make sure your hardware is supported by FreeBSD. The list of supported hardware should come in handy here. ;-) It would also be a good idea to make a list of any special cards you have installed, such as SCSI controllers, ethernet cards, sound cards, etc.. The list should include their IRQs and IO port addresses. Creating the Installation Floppies You may need to prepare some floppy disks. These disks will be used to boot your computer in to the FreeBSD install process. This step is not necessary if you are installing from CD-ROM, and your computer supports booting from the CD-ROM. If you do not meet these requirements then you will need to create some floppies to boot from. If you are not sure whether your computer can boot from the CD-ROM it does not hurt to try. Just insert the CD-ROM as normal and restart your computer. You might need to adjust some options in your BIOS so that your computer will try and boot from the CD-ROM drive before the hard disk. Even if you have the CD-ROM it might make sense for you to download the files. There have been occasions where bugs in the FreeBSD installer have been discovered after the CDs have been released. When this happens the copies of the images on the FTP site will be fixed as soon as possible. Obviously, it is not possible to update the CDs after they have been pressed. Acquire the boot floppy images These are files with a .flp extension. If you have a CD-ROM release of FreeBSD then you will find the files in the floppies subdirectory. Alternatively, you can download the images from the floppies directory of the FreeBSD FTP site or your local mirror. The names of the files you will need varies between FreeBSD releases (sometimes) and the architecture you will be installing on. The installation boot image information on the FTP site provides up-to-the-minute information about the specific files you will need. Prepare the floppy disks You must prepare one floppy disk per image file you had to - download. It is imperitive that these disks are free from + download. It is imperative that these disks are free from defects. The easiest way to test this is to format the disks for yourself. Do not trust pre-formatted floppies. If you try to install FreeBSD and the installation program crashes, freezes, or otherwise misbehaves one of the first things to suspect is the floppies. Try writing the floppy image files to some other disks, and try again. Write the image files to the floppy disks. The image files, such as kern.flp, are not regular files you copy to the disk. Instead, they are images of the complete contents of the disk. This means that you can not use commands like DOS' copy to write the files. Instead, you must use specific tools to write the images directly to the disk. If you are creating the floppies on a computer running DOS then we provide a tool to do this called fdimage. If you are using the floppies from the CD-ROM, and your CD-ROM is the E: drive then you would run this: E:\> tools\fdimage floppies\kern.flp A: Repeat this command for each .flp file, replacing the floppy disk each time. Adjust the command line as necessary, depending on where you have placed the .flp files. If you do not have the CD-ROM then fdimage can be downloaded from the tools directory on the FreeBSD FTP site. If you are writing the floppies on a Unix system (such as another FreeBSD system) you can use the &man.dd.1; command to write the image files directly to disk. On FreeBSD you would run: &prompt.root; dd if=kern.flp of=/dev/rfd0 On FreeBSD /dev/rfd0 refers to the first floppy disk (the A: drive). /dev/rfd1 would be the B: drive, and so on. Other Unix variants might have different names for the floppy disk devices, and you will need to check the documentation for the system as necessary. Before Installing from CDROM If your CDROM is of an unsupported type, please skip ahead to the MS-DOS Preparation section. There is not a whole lot of preparation needed if you are installing from one of BSDi's FreeBSD CDROMs (other CDROM distributions may work as well, though we cannot say for certain as we have no hand or say in how they created). You can either boot into the CD installation directly from DOS using the install.bat or you can make floppies with the makeflp.bat command. If the CD has El Torito boot support and your system supports booting directly from the CDROM drive (many older systems do NOT), simply insert the first CD of the set into the drive and reboot your system. You will be put into the installation menu directly from the CD. If you are installing from an MS-DOS partition and have the proper drivers to access your CD, run the install.bat script provided on the CDROM. This will attempt to boot the FreeBSD installation directly from DOS. You must do this from actual DOS (i.e., boot in DOS mode) and not from a DOS window under Windows. For the easiest interface of all (from DOS), type view. This will bring up a DOS menu utility that leads you through all of the available options. If you are creating the boot floppies from a UNIX machine, see the Creating the Boot Floppies section of this guide for examples. Once you have booted from DOS or floppy, you should then be able to select CDROM as the media type during the install process and load the entire distribution from CDROM. No other types of installation media should be required. After your system is fully installed and you have rebooted (from the hard disk), you can mount the CDROM at any time by typing: &prompt.root; mount /cdrom Before removing the CD from the drive again, you must first unmount it. This is done with the following command: &prompt.root; umount /cdrom Do not just remove it from the drive! Before invoking the installation, be sure that the CDROM is in the drive so that the install probe can find it. This is also true if you wish the CDROM to be added to the default system configuration automatically during the installation (whether or not you actually use it as the installation media). Finally, if you would like people to be able to FTP install FreeBSD directly from the CDROM in your machine, you will find it quite easy. After the machine is fully installed, you simply need to add the following line to the password file (using the vipw command): ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent Anyone with network connectivity to your machine can now chose a media type of FTP and type in ftp://your machine after picking Other in the FTP sites menu during the install. If you choose to enable anonymous FTP during the installation of your system, the installation program will do the above for you. Before installing from Floppies If you must install from floppy disk (which we suggest you do NOT do), either due to unsupported hardware or simply because you insist on doing things the hard way, you must first prepare some floppies for the installation. At a minimum, you will need as many 1.44MB or 1.2MB floppies as it takes to hold all the files in the bin (binary distribution) directory. If you are preparing the floppies from DOS, then they MUST be formatted using the MS-DOS FORMAT command. If you are using Windows, use Explorer to format the disks (right-click on the A: drive, and select "Format". Do NOT trust factory pre-formatted floppies! Format them again yourself, just to be sure. Many problems reported by our users in the past have resulted from the use of improperly formatted media, which is why we are making a point of it now. If you are creating the floppies on another FreeBSD machine, a format is still not a bad idea, though you do not need to put a DOS filesystem on each floppy. You can use the disklabel and newfs commands to put a UFS filesystem on them instead, as the following sequence of commands (for a 3.5" 1.44MB floppy) illustrates: &prompt.root; fdformat -f 1440 fd0.1440 &prompt.root; disklabel -w -r fd0.1440 floppy3 &prompt.root; newfs -t 2 -u 18 -l 1 -i 65536 /dev/rfd0 Use fd0.1200 and floppy5 for 5.25" 1.2MB disks. Then you can mount and write to them like any other filesystem. After you have formatted the floppies, you will need to copy the files to them. The distribution files are split into chunks conveniently sized so that 5 of them will fit on a conventional 1.44MB floppy. Go through all your floppies, packing as many files as will fit on each one, until you have all of the distributions you want packed up in this fashion. Each distribution should go into a subdirectory on the floppy, e.g.: a:\bin\bin.aa, a:\bin\bin.ab, and so on. Once you come to the Media screen during the install process, select Floppy and you will be prompted for the rest. Before Installing from MS-DOS To prepare for an installation from an MS-DOS partition, copy the files from the distribution into a directory named, for example, c:\FreeBSD. The directory structure of the CDROM or FTP site must be partially reproduced within this directory, so we suggest using the DOS xcopy command if you are copying it from a CD. For example, to prepare for a minimal installation of FreeBSD: C:\> md c:\FreeBSD C:\> xcopy e:\bin c:\FreeBSD\bin\ /s C:\> xcopy e:\manpages c:\FreeBSD\manpages\ /s Assuming that C: is where you have free space and E: is where your CDROM is mounted. If you do not have a CDROM drive, you can download the distribution from ftp.FreeBSD.org. Each distribution is in its own directory; for example, the bin distribution can be found in the &rel.current;/bin directory. For as many distributions you wish to install from an MS-DOS partition (and you have the free space for), install each one under c:\FreeBSD — the BIN distribution is the only one required for a minimum installation. Before Installing from QIC/SCSI Tape Installing from tape is probably the easiest method, short of an online FTP install or CDROM install. The installation program expects the files to be simply tarred onto the tape, so after getting all of the distribution files you are interested in, simply tar them onto the tape like so: &prompt.root; cd /freebsd/distdir &prompt.root; tar cvf /dev/rwt0 dist1 ... dist2 When you go to do the installation, you should also make sure that you leave enough room in some temporary directory (which you will be allowed to choose) to accommodate the full contents of the tape you have created. Due to the non-random access nature of tapes, this method of installation requires quite a bit of temporary storage. You should expect to require as much temporary storage as you have stuff written on tape. When starting the installation, the tape must be in the drive before booting from the boot floppy. The installation probe may otherwise fail to find it. Before Installing over a Network There are three types of network installations you can do. Serial port (SLIP or PPP), Parallel port (PLIP (laplink cable)), or Ethernet (a standard ethernet controller (includes some PCMCIA)). The SLIP support is rather primitive, and limited primarily to hard-wired links, such as a serial cable running between a laptop computer and another computer. The link should be hard-wired as the SLIP installation does not currently offer a dialing capability; that facility is provided with the PPP utility, which should be used in preference to SLIP whenever possible. If you are using a modem, then PPP is almost certainly your only choice. Make sure that you have your service provider's information handy as you will need to know it fairly early in the installation process. If you use PAP or CHAP to connect your ISP (in other words, if you can connect to the ISP in Windows without using a script), then all you will need to do is type in dial at the ppp prompt. Otherwise, you will need to know how to dial your ISP using the AT commands specific to your modem, as the PPP dialer provides only a very simple terminal emulator. Please to the user-ppp handbook and FAQ entries for further information. If you have problems, logging can be directed to the screen using the command set log local .... If a hard-wired connection to another FreeBSD (2.0-R or later) machine is available, you might also consider installing over a laplink parallel port cable. The data rate over the parallel port is much higher than what is typically possible over a serial line (up to 50kbytes/sec), thus resulting in a quicker installation. Finally, for the fastest possible network installation, an ethernet adapter is always a good choice! FreeBSD supports most common PC ethernet cards; a table of supported cards (and their required settings) is provided in the Supported Hardware list. If you are using one of the supported PCMCIA ethernet cards, also be sure that it is plugged in before the laptop is powered on! FreeBSD does not, unfortunately, currently support hot insertion of PCMCIA cards during installation. You will also need to know your IP address on the network, the netmask value for your address class, and the name of your machine. If you are installing over a PPP connection and do not have a static IP, fear not, the IP address can be dynamically assigned by your ISP. Your system administrator can tell you which values to use for your particular network setup. If you will be referring to other hosts by name rather than IP address, you will also need a name server and possibly the address of a gateway (if you are using PPP, it is your provider's IP address) to use in talking to it. If you want to install by FTP via a HTTP proxy (see below), you will also need the proxy's address. If you do not know the answers to all or most of these questions, then you should really probably talk to your system administrator or ISP before trying this type of installation. Before Installing via NFS The NFS installation is fairly straight-forward. Simply copy the FreeBSD distribution files you want onto a server somewhere and then point the NFS media selection at it. If this server supports only privileged port (as is generally the default for Sun workstations), you will need to set this option in the Options menu before installation can proceed. If you have a poor quality ethernet card which suffers from very slow transfer rates, you may also wish to toggle the appropriate Options flag. In order for NFS installation to work, the server must support subdir mounts, e.g., if your FreeBSD 3.4 distribution directory lives on:ziggy:/usr/archive/stuff/FreeBSD, then ziggy will have to allow the direct mounting of /usr/archive/stuff/FreeBSD, not just /usr or /usr/archive/stuff. In FreeBSD's /etc/exports file, this is controlled by the . Other NFS servers may have different conventions. If you are getting permission denied messages from the server, then it is likely that you do not have this enabled properly. Before Installing via FTP FTP installation may be done from any FreeBSD mirror site containing a reasonably up-to-date version of FreeBSD. A full list of FTP mirrors located all over the world is provided during the install process. If you are installing from an FTP site not listed in this menu, or are having trouble getting your name server configured properly, you can also specify a URL to use by selecting the choice labeled Other in that menu. You can also use the IP address of a machine you wish to install from, so the following would work in the absence of a name server: ftp://209.55.82.20/pub/FreeBSD/&rel.current;-RELEASE There are three FTP installation modes you can choose from: active or passive FTP or via a HTTP proxy. FTP Active This option will make all FTP transfers use Active mode. This will not work through firewalls, but will often work with older FTP servers that do not support passive mode. If your connection hangs with passive mode (the default), try active! FTP Passive This option instructs FreeBSD to use Passive mode for all FTP operations. This allows the user to pass through firewalls that do not allow incoming connections on random port addresses. FTP via a HTTP proxy This option instructs FreeBSD to use the HTTP protocol (like a web browser) to connect to a proxy for all FTP operations. The proxy will translate the requests and send them to the FTP server. This allows the user to pass through firewalls that do not allow FTP at all, but offer a HTTP proxy. In this case, you have to specify the proxy in addition to the FTP server. There is another type of FTP proxy other tha HTTP proxies. This type is very uncommon, though. If you are not absolutely certain, you can assume that you have a HTTP proxy as described above. For a proxy FTP server, you should usually give the name of the server you really want as a part of the username, after an @ sign. The proxy server then fakes the real server. For example, assuming you want to install from ftp.FreeBSD.org, using the proxy FTP server foo.bar.com, listening on port 1024. In this case, you go to the options menu, set the FTP username to ftp@ftp.FreeBSD.org, and the password to your email address. As your installation media, you specify FTP (or passive FTP, if the proxy supports it), and the URL ftp://foo.bar.com:1234/pub/FreeBSD. Since /pub/FreeBSD from ftp.FreeBSD.org is proxied under foo.bar.com, you are able to install from that machine (which will fetch the files from ftp.FreeBSD.org as your installation requests them. Check your BIOS drive numbering If you have used features in your BIOS to renumber your disk - drives without recabling them then you should read first to avoid confusion. Installing FreeBSD Once you have completed the pre-installation step relevant to your situation, you are ready to install FreeBSD! Although you should not experience any difficulty, there is always the chance that you may, no matter how slight it is. If this is the case in your situation, then you may wish to go back and re-read the relevant preparation section or sections. Perhaps you will come across something you missed the first time. If you are having hardware problems, or FreeBSD refuses to boot at all, read the Hardware Guide for a list of possible solutions. The FreeBSD boot floppies contain all of the online documentation you should need to be able to navigate through an installation. If it does not, please let us know what you found to be the most confusing or most lacking. Send your comments to the &a.doc;. It is the objective of the installation program (sysinstall) to be self-documenting enough that painful step-by-step guides are no longer necessary. It may take us a little while to reach that objective, but nonetheless, it is still our objective :-) Meanwhile, you may also find the following typical installation sequence to be helpful: Boot the kern.flp floppy and when asked, remove it and insert the mfsroot.flp and hit return. After a boot sequence which can take anywhere from 30 seconds to 3 minutes, depending on your hardware, you should be presented with a menu of initial choices. If the kern.flp floppy does not boot at all or the boot hangs at some stage, read the Q&A section of the Hardware Guide for possible causes. Press F1. You should see some basic usage instructions on the menu screen and general navigation. If you have not used this menu system before then please read this thoroughly. Select the Options item and set any special preferences you may have. Select a Standard, Express, or Custom install, depending on whether or not you would like the installation to help you through a typical installation, give you a high degree of control over each step, or simply whiz through it (using reasonable defaults when possible) as fast as possible. If you have never used FreeBSD before, the Standard installation method is most recommended. The final configuration menu choice allows you to further configure your FreeBSD installation by giving you menu-driven access to various system defaults. Some items, like networking, may be especially important if you did a CDROM, tape, or floppy install and have not yet configured your network interfaces (assuming you have any). Properly configuring such interfaces here will allow FreeBSD to come up on the network when you first reboot from the hard disk. Supported Hardware FreeBSD currently runs on a wide variety of ISA, VLB, EISA, and PCI bus based PCs, ranging from the 386SX to Pentium class machines (though the 386SX is not recommended). Support for generic IDE or ESDI drive configurations, various SCSI controllers, and network and serial cards is also provided. FreeBSD also supports IBM's microchannel (MCA) bus. In order to run FreeBSD, a recommended minimum of eight megabytes of RAM is suggested. Sixteen megabytes is the preferred amount of RAM as you may have some trouble with anything less than sixteen depending on your hardware. What follows is a list of hardware currently known to work with FreeBSD. There may be other hardware that works as well, but we have simply not received any confirmation of it. Disk Controllers WD1003 (any generic MFM/RLL) WD1007 (any generic IDE/ESDI) IDE ATA Adaptec 1535 ISA SCSI controllers Adaptec 154X series ISA SCSI controllers Adaptec 174X series EISA SCSI controllers in standard and enhanced mode Adaptec 274X/284X/2920C/294X/2950/3940/3950 (Narrow/Wide/Twin) series EISA/VLB/PCI SCSI controllers Adaptec AIC-7850, AIC-7860, AIC-7880, AIC-789X on-board SCSI controllers Adaptec 1510 series ISA SCSI controllers (not for bootable devices) Adaptec 152X series ISA SCSI controllers Adaptec AIC-6260 and AIC-6360 based boards, which include the AHA-152X and SoundBlaster SCSI cards AdvanSys SCSI controllers (all models) BusLogic MultiMaster W Series Host Adapters including BT-948, BT-958, BT-9580 BusLogic MultiMaster C Series Host Adapters including BT-946C, BT-956C, BT-956CD, BT-445C, BT-747C, BT-757C, BT-757CD, BT-545C, BT-540CF BusLogic MultiMaster S Series Host Adapters including BT-445S, BT-747S, BT-747D, BT-757S, BT-757D, BT-545S, BT-542D, BT-742A, BT-542B BusLogic MultiMaster A Series Host Adapters including BT-742A, BT-542B AMI FastDisk controllers that are true BusLogic MultiMaster clones are also supported. BusLogic/Mylex Flashpoint adapters are NOT yet supported. DPT SmartCACHE Plus, SmartCACHE III, SmartRAID III, SmartCACHE IV, and SmartRAID IV SCSI/RAID are supported. The DPT SmartRAID/CACHE V is not yet supported. The DPT PM3754U2-16M SCSI RAID Controller is also supported. Compaq Intelligent Disk Array Controllers: IDA, IDA-2, IAES, SMART, SMART-2/E, Smart-2/P, SMART-2SL, Integrated Array, and Smart Arrays 3200, 3100ES, 221, 4200, 4200, 4250ES. SymBios (formerly NCR) 53C810, 53C810a, 53C815, 53C820, 53C825a, 53C860, 53C875, 53C875j, 53C885, and 53C896 PCI SCSI controllers including ASUS SC-200, Data Technology DTC3130 (all variants), Diamond FirePort (all), NCR cards (all), SymBios cards (all), Tekram DC390W, 390U, and 390F, and Tyan S1365 QLogic 1020, 1040, 1040B, and 2100 SCSI and Fibre Channel Adapters DTC 3290 EISA SCSI controller in 1542 evaluation mode With all supported SCSI controllers, full support is provided for SCSI-I and SCSI-II peripherals, including hard disks, optical disks, tape drives (including DAT and 8mm Exabyte), medium changers, processor target devices, and CDROM drives. WORM devices that support CDROM commands are supported for read-only access by the CDROM driver. WORM/CD-R/CD-RW writing support is provided by cdrecord, which is in the ports tree. The following CD-ROM type systems are supported at this time: cd - SCSI interface (includes ProAudio Spectrum and SoundBlaster SCSI) matcd - Matsushita/Panasonic - (Creative Soundblaster) proprietary interface (562/563 + (Creative SoundBlaster) proprietary interface (562/563 models) scd - Sony proprietary interface (all models) acd - ATAPI IDE interface The following drivers were supported under the old SCSI subsystem, but are NOT YET supported under the new CAM SCSI subsystem: NCR5380/NCR53400 (ProAudio Spectrum) SCSI controller UltraStor 14F, 24F, and 34F SCSI controllers Seagate ST01/02 SCSI controllers Future Domain 8XX/950 series SCSI controllers WD7000 SCSI controller There is work-in-progress to port the UltraStor driver to the new CAM framework, but no estimates on when or if it will be completed. Unmaintained drivers, which might or might not work for your hardware: Floppy tape interface (Colorado/Mountain/Insight) mcd - Mitsumi proprietary CD-ROM interface (all models) Network Cards Adaptec Duralink PCI fast ethernet adapters based on the Adaptec AIC-6195 fast ethernet controller chip, including the following: ANA-62011 64-bit single port 10/100baseTX adapter ANA-62022 64-bit dual port 10/100baseTX adapter ANA-62044 64-bit quad port 10/100baseTX adapter ANA-69011 32-bit single port 10/100baseTX adapter ANA-62020 64-bit single port 100baseFX adapter Allied-Telesyn AT1700 and RE2000 cards Alteon Networks PCI gigabit ethernet NICs based on the Tigon 1 and Tigon 2 chipsets including the Alteon AceNIC (Tigon 1 and 2), 3Com 3c985-SX (Tigon 1 and 2), Netgear GA620 (Tigon 2), Silicon Graphics Gigabit Ethernet, DEC/Compaq EtherWORKS 1000, NEC Gigabit Ethernet AMD PCnet/PCI (79c970 and 53c974 or 79c974) RealTek 8129/8139 fast ethernet NICs including the following: Allied-Telesyn AT2550 Allied-Telesyn AT2500TX Genius GF100TXR (RTL8139) NDC Communications NE100TX-E OvisLink LEF-8129TX OvisLink LEF-8139TX Netronix Inc. EA-1210 NetEther 10/100 KTX-9130TX 10/100 Fast Ethernet Accton Cheetah EN1207D (MPX 5030/5038; RealTek 8139 clone) SMC EZ Card 10/100 PCI 1211-TX Lite-On 98713, 98713A, 98715, and 98725 fast ethernet NICs, including the LinkSys EtherFast LNE100TX, NetGear FA310-TX Rev. D1, Matrox FastNIC 10/100, Kingston KNE110TX Macronix 98713, 98713A, 98715, 98715A, and 98725 fast ethernet NICs including the NDC Communications SFA100A (98713A), CNet Pro120A (98713 or 98713A), CNet Pro120B (98715), SVEC PN102TX (98713) Macronix/Lite-On PNIC II LC82C115 fast ethernet NICs including the LinkSys EtherFast LNE100TX version 2 Winbond W89C840F fast ethernet NICs including the Trendware TE100-PCIE VIA Technologies VT3043 Rhine I and VT86C100A Rhine II fast ethernet NICs including the Hawking Technologies PN102TX and D-Link DFE-530TX Silicon Integrated Systems SiS 900 and SiS 7016 PCI fast ethernet NICs Sundance Technologies ST201 PCI fast ethernet NICs including the D-Link DFE-550TX SysKonnect SK-984x PCI gigabit ethernet cards including the SK-9841 1000baseLX (single mode fiber, single port), the SK-9842 1000baseSX (multimode fiber, single port), the SK-9843 1000baseLX (single mode fiber, dual port), and the SK-9844 1000baseSX (multimode fiber, dual port). Texas Instruments ThunderLAN PCI NICs, including the Compaq Netelligent 10, 10/100, 10/100 Proliant, 10/100 Dual-Port, 10/100 TX Embedded UTP, 10 T PCI UTP/Coax, and 10/100 TX UTP, the Compaq NetFlex 3P, 3P Integrated, and 3P w/BNC, the Olicom OC-2135/2138, OC-2325, OC-2326 10/100 TX UTP, and the Racore 8165 10/100baseTX and 8148 10baseT/100baseTX/100baseFX multi-personality cards ADMtek AL981-based and AN985-based PCI fast ethernet NICs ASIX Electronics AX88140A PCI NICs including the Alfa Inc. GFC2204 and CNet Pro110B DEC EtherWORKS III NICs (DE203, DE204, and DE205) DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) DEC DC21040, DC21041, or DC21140 based NICs (SMC Etherpower 8432T, DE245, etc.) DEC FDDI (DEFPA/DEFEA) NICs Efficient ENI-155p ATM PCI FORE PCA-200E ATM PCI Fujitsu MB86960A/MB86965A HP PC Lan+ cards (model numbers: 27247B and 27252A) Intel EtherExpress ISA (not recommended due to driver instability) Intel EtherExpress Pro/10 Intel EtherExpress Pro/100B PCI Fast Ethernet Isolan AT 4141-0 (16 bit) Isolink 4110 (8 bit) Novell NE1000, NE2000, and NE2100 Ethernet interfaces PCI network cards emulating the NE2000, including the RealTek 8029, NetVin 5000, Winbond W89C940, Surecom NE-34, VIA VT86C926 3Com 3C501, 3C503 Etherlink II, 3C505 Etherlink/+, 3C507 Etherlink 16/TP, 3C509, 3C579, 3C589 (PCMCIA), 3C590/592/595/900/905/905B/905C PCI and EISA (Fast) Etherlink III / (Fast) Etherlink XL, 3C980/3C980B Fast Etherlink XL server adapter, 3CSOHO100-TX OfficeConnect adapter Toshiba ethernet cards PCMCIA ethernet cards from IBM and National Semiconductor are also supported USB Peripherals A wide range of USB peripherals are supported. Owing to the generic nature of most USB devices, with some exceptions any device of a given class will be supported even if not explicitly listed here. USB keyboards USB mice USB printers and USB to parallel printer conversion cables USB hubs Motherboard chipsets: ALi Aladdin-V Intel 82371SB (PIIX3) and 82371AB and EB (PIIX4) chipsets NEC uPD 9210 Host Controller VIA 83C572 USB Host Controller and any other UHCI or OHCI compliant motherboard chipset (no exceptions known). PCI plug-in USB host controllers ADS Electronics PCI plug-in card (2 ports) Entrega PCI plug-in card (4 ports) Specific USB devices reported to be working: Agiler Mouse 29UO Andromeda hub Apple iMac mouse and keyboard ATen parallel printer adapter Belkin F4U002 parallel printer adapter and Belkin mouse BTC BTC7935 keyboard with mouse port Cherry G81-3504 Chic mouse Cypress mouse Entrega USB-to-parallel printer adapter Genius Niche mouse Iomega USB Zip 100 MB Kensington Mouse-in-a-Box Logitech M2452 keyboard Logictech wheel mouse (3 buttons) Logitech PS/2 / USB mouse (3 buttons) MacAlly mouse (3 buttons) MacAlly self-powered hub (4 ports) Microsoft Intellimouse (3 buttons) Microsoft keyboard NEC hub Trust Ami Mouse (3 buttons) ISDN (European DSS1 [Q.921/Q.931] protocol) Asuscom I-IN100-ST-DV (experimental, may work) Asuscom ISDNlink 128K AVM A1 AVM Fritz!Card classic AVM Fritz!Card PCI AVM Fritz!Card PCMCIA (currently FreeBSD 3.x only) AVM Fritz!Card PnP (currently FreeBSD 3.x only) Creatix ISDN-S0/8 Creatix ISDN-S0/16 Creatix ISDN-S0 PnP Dr.Neuhaus Niccy 1008 Dr.Neuhaus Niccy 1016 Dr.Neuhaus Niccy GO@ (ISA PnP) Dynalink IS64PH (no longer maintained) ELSA 1000pro ISA ELSA 1000pro PCI ELSA PCC-16 ITK ix1 micro (currently FreeBSD 3.x only) ITK ix1 micro V.3 (currently FreeBSD 3.x only) Sagem Cybermod (ISA PnP, may work) Sedlbauer Win Speed Siemens I-Surf 2.0 Stollman Tina-pp (under development) Teles S0/8 Teles S0/16 Teles S0/16.3 (the c Versions - like 16.3c - are unsupported!) Teles S0 PnP (experimental, may work) 3Com/USRobotics Sportster ISDN TA intern (non-PnP version) Sound Devices The following soundcards or codecs are supported (devices marked 'experimental' are only supported in FreeBSD-CURRENT and might work only unstably): 16550 UART (Midi) (experimental, needs a trick in the hints file) Advance Asound 100, 110 and Logic ALS120 Aureal Vortex1/Vortex2 and Vortex Advantage based soundcards by a third party driver Creative Labs SB16, SB32, SB AWE64 (including Gold), Vibra16, SB PCI (experimental), SB Live! (experimental) and most SoundBlaster compatible cards Creative Labs SB Midi Port (experimental), SB OPL3 Synthesizer (experimental) Crystal Semiconductor CS461x/462x Audio Accelerator, the support for the CS461x Midi port is experimental Crystal Semiconductor CS428x Audio Controller CS4237, CS4236, CS4232, CS4231 (ISA) ENSONIQ AudioPCI ES1370/1371 ESS ES1868, ES1869, ES1879, ES1888 Gravis UltraSound PnP, MAX NeoMagic 256AV/ZX (PCI) OPTi931 (ISA) OSS-compatible sequencer (Midi) (experimental) Trident 4DWave DX/NX (PCI) Yahama OPL-SAx (ISA) Miscellaneous Devices AST 4 port serial card using shared IRQ ARNET 8 port serial card using shared IRQ ARNET (now Digiboard) Sync 570/i high-speed serial Boca BB1004 4-Port serial card (Modems NOT supported) Boca IOAT66 6-Port serial card (Modems supported) Boca BB1008 8-Port serial card (Modems NOT supported) Boca BB2016 16-Port serial card (Modems supported) Cyclades Cyclom-y Serial Board Moxa SmartIO CI-104J 4-Port serial card STB 4 port card using shared IRQ SDL Communications RISCom/8 Serial Board SDL Communications RISCom/N2 and N2pci high-speed sync serial boards Specialix SI/XIO/SX multiport serial cards, with both the older SIHOST2.x and the new enhanced (transputer based, aka JET) host cards; ISA, EISA and PCI are supported Stallion multiport serial boards: EasyIO, EasyConnection 8/32 & 8/64, ONboard 4/16 and Brumby Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound, and Roland MPU-401 sound cards Connectix QuickCam Matrox Meteor Video frame grabber Creative Labs Video Spigot frame grabber Cortex1 frame grabber Various frame grabbers based on the Brooktree Bt848 and Bt878 chip HP4020, HP6020, Philips CDD2000/CDD2660 and Plasmon CD-R drives Bus mice PS/2 mice Standard PC Joystick X-10 power controllers GPIB and Transputer drives Genius and Mustek hand scanners Floppy tape drives (some rather old models only, driver is rather stale) Lucent Technologies WaveLAN/IEEE 802.11 PCMCIA and ISA standard speed (2Mbps) and turbo speed (6Mbps) wireless network adapters and workalikes (NCR WaveLAN/IEEE 802.11, Cabletron RoamAbout 802.11 DS) The ISA versions of these adapters are actually PCMCIA cards combined with an ISA to PCMCIA bridge card, so both kinds of devices work with the same driver. Troubleshooting The following section covers basic installation troubleshooting, such as common problems people have reported. There are also a few questions and answers for people wishing to dual-boot FreeBSD with MS-DOS. What to do if something goes wrong... Due to various limitations of the PC architecture, it is impossible for probing to be 100% reliable, however, there are a few things you can do if it fails. Check the supported hardware list to make sure your hardware is supported. If your hardware is supported and you still experience lock-ups or other problems, reset your computer, and when the visual kernel configuration option is given, choose it. This will allow you to go through your hardware and supply information to the system about it. The kernel on the boot disks is configured assuming that most hardware devices are in their factory default configuration in terms of IRQs, IO addresses, and DMA channels. If your hardware has been reconfigured, you will most likely need to use the configuration editor to tell FreeBSD where to find things. It is also possible that a probe for a device not present will cause a later probe for another device that is present to fail. In that case, the probes for the conflicting driver(s) should be disabled. Do not disable any drivers you will need during the installation, such as your screen (sc0). If the installation wedges or fails mysteriously after leaving the configuration editor, you have probably removed or changed something you should not have. Reboot and try again. In configuration mode, you can: List the device drivers installed in the kernel. Change device drivers for hardware that is not present in your system. Change IRQs, DRQs, and IO port addresses used by a device driver. After adjusting the kernel to match your hardware configuration, type Q to boot with the new settings. Once the installation has completed, any changes you made in the configuration mode will be permanent so you do not have to reconfigure every time you boot. It is still highly likely that you will eventually want to build a custom kernel. MS-DOS User's Questions and Answers Many users wish to install FreeBSD on PCs inhabited by MS-DOS. Here are some commonly asked questions about installing FreeBSD on such systems. Help, I have no space! Do I need to delete everything first? If your machine is already running MS-DOS and has little or no free space available for the FreeBSD installation, all hope is not lost! You may find the FIPS utility, provided in the tools directory on the FreeBSD CDROM or various FreeBSD FTP sites to be quite useful. FIPS allows you to split an existing MS-DOS partition into two pieces, preserving the original partition and allowing you to install onto the second free piece. You first defragment your MS-DOS partition using the Windows DEFRAG utility (go into Explorer, right-click on the hard drive, and choose to defrag your hard drive), or Norton Disk Tools. You then must run FIPS. It will prompt you for the rest of the information it needs. Afterwards, you can reboot and install FreeBSD on the new free slice. See the Distributions menu for an estimate of how much free space you will need for the kind of installation you want. There is also a very useful product from PowerQuest called Partition Magic. This application has far more functionality than FIPS, and is highly recommended if you plan to often add/remove operating systems (like me). However, it does cost money, and if you plan to install FreeBSD once and then leave it there, FIPS will probably be fine for you. Can I use compressed MS-DOS filesystems from FreeBSD? No. If you are using a utility such as Stacker(tm) or DoubleSpace(tm), FreeBSD will only be able to use whatever portion of the filesystem you leave uncompressed. The rest of the filesystem will show up as one large file (the stacked/double spaced file!). Do not remove that file or you will probably regret it greatly! It is probably better to create another uncompressed primary MS-DOS partition and use this for communications between MS-DOS and FreeBSD. Can I mount my extended MS-DOS partition? Yes. DOS extended partitions are mapped in at the end of the other slices in FreeBSD, e.g., your D: drive might be /dev/da0s5, your E: drive, /dev/da0s6, and so on. This example assumes, of course, that your extended partition is on SCSI drive 0. For IDE drives, substitute ad for da appropriately if installing 4.0-RELEASE or later, and substitute wd for da if you are installing a version of FreeBSD prior to 4.0. You otherwise mount extended partitions exactly like you would any other DOS drive, for example: &prompt.root; mount -t msdos /dev/ad0s5 /dos_d