diff options
| -rw-r--r-- | share/FAQ/Text/CONTRIB.FreeBSD | 245 | ||||
| -rw-r--r-- | share/FAQ/Text/FreeBSD.FAQ | 1304 | ||||
| -rw-r--r-- | share/FAQ/Text/HW.TROUBLE | 58 | ||||
| -rw-r--r-- | share/FAQ/Text/MIRROR.SITES | 107 | ||||
| -rw-r--r-- | share/FAQ/Text/README | 75 | ||||
| -rw-r--r-- | share/FAQ/Text/REGISTER.FreeBSD | 85 | ||||
| -rw-r--r-- | share/FAQ/Text/RELNOTES.FreeBSD | 624 | ||||
| -rw-r--r-- | share/FAQ/Text/ROADMAP | 55 | ||||
| -rw-r--r-- | share/FAQ/Text/TROUBLESHOOTING | 185 | ||||
| -rw-r--r-- | share/FAQ/Text/UUCP_Internals.FAQ | 1603 | ||||
| -rw-r--r-- | share/FAQ/Text/ctm.FAQ | 191 | ||||
| -rw-r--r-- | share/FAQ/Text/current-policy.FAQ | 170 | ||||
| -rw-r--r-- | share/FAQ/Text/diskspace.FAQ | 267 | ||||
| -rw-r--r-- | share/FAQ/Text/kernel-debug.FAQ | 417 | ||||
| -rw-r--r-- | share/FAQ/Text/mailing-list.FAQ | 105 | ||||
| -rw-r--r-- | share/FAQ/Text/nfs.FAQ | 79 | ||||
| -rw-r--r-- | share/FAQ/Text/ports.FAQ | 246 | ||||
| -rw-r--r-- | share/FAQ/Text/ppp.FAQ | 369 | ||||
| -rw-r--r-- | share/FAQ/Text/slip.FAQ | 192 | ||||
| -rw-r--r-- | share/FAQ/Text/slip_server.FAQ | 433 | ||||
| -rw-r--r-- | share/FAQ/Text/submitters.FAQ | 167 | ||||
| -rw-r--r-- | share/FAQ/Text/sup.FAQ | 90 | ||||
| -rw-r--r-- | share/FAQ/Text/systems.FAQ | 59 |
23 files changed, 7126 insertions, 0 deletions
diff --git a/share/FAQ/Text/CONTRIB.FreeBSD b/share/FAQ/Text/CONTRIB.FreeBSD new file mode 100644 index 0000000..d401fb4 --- /dev/null +++ b/share/FAQ/Text/CONTRIB.FreeBSD @@ -0,0 +1,245 @@ + FreeBSD 2.0 + Contributor List + + + +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 reimplemented from the +4.4 BSD Lite release provided by the Computer Science Research Group +(CSRG) at the University of California, Berkeley and associated academic +contributors. + +There are also portions of NetBSD that have been integrated into FreeBSD +as well, and we would therefore like to thank all the contributors +to NetBSD for their work. Despite some occasionally rocky moments in +relations between the two groups, we both want essentially the same +thing: More BSD based operating systems on people's computers! We +wish the NetBSD group every success in their endevors. + + +Hardware Contributors: + +A special thank-you to Walnut Creek CDROM for providing the Pentium P5-90 +and 486/DX2-66 EISA/VL systems that are being used for our development work, +to say nothing of the network access and other donations of hardware +resources. It would have been impossible to do this release without +their support. + +TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, +twelve ethernets, two routers and an ATM switch for debugging the diskless +code. They also keep a couple of FreeBSD hackers alive and busy. Thanks! + +Thanks also to Dermot McDonnell for his donation of a Toshiba XM3401B CDROM +drive. It's been most useful! + + +The FreeBSD Core Team [also the Board of Directors for The FreeBSD Project] +(in alphabetical order): + + Andreas Schulz <ats@FreeBSD.org> + Andrey A. Chernov <ache@FreeBSD.org> + Bruce Evans <bde@FreeBSD.org> + David Greenman <davidg@FreeBSD.org> + Garrett A. Wollman <wollman@FreeBSD.org> + Gary Palmer <gpalmer@FreeBSD.org> + Geoff Rehmet <csgr@FreeBSD.org> + Jack Vogel <jackv@FreeBSD.org> + John Dyson <dyson@FreeBSD.org> + Jordan K. Hubbard <jkh@FreeBSD.org> + Justin Gibbs <gibbs@FreeBSD.org> + Nate Williams <nate@FreeBSD.org> + Paul Richards <paul@FreeBSD.org> + Poul-Henning Kamp <phk@FreeBSD.org> + Rich Murphey <rich@FreeBSD.org> + Rodney W. Grimes <rgrimes@FreeBSD.org> + Søren Schmidt <sos@FreeBSD.org> + + +Officers, The FreeBSD Project: + + President: Jordan K. Hubbard <jkh@FreeBSD.org> + Principle Architect: David Greenman <davidg@FreeBSD.org> + + +Directors, The FreeBSD Project: + + Documentation: John Fieber <jfieber@FreeBSD.org> + Internationalization: Andrey A. Chernov <ache@FreeBSD.org> + Networking: Garrett A. Wollman <wollman@FreeBSD.org> + Postmaster: Jonathan M. Bresler <jmb@FreeBSD.org> + Release Coordinator: Poul-Henning Kamp <phk@FreeBSD.org> + System Administration: Gary Palmer <gpalmer@FreeBSD.org> + WEBMASTERS: John Fieber <jfieber@FreeBSD.org> and + James L. Robinson <jlrobin@FreeBSD.org> + XFree86 Project, Inc: (Liaison) Rich Murphey <rich@FreeBSD.org> + + +Additional FreeBSD Contributors +(in alphabetical order by first name, just to be different): + +Adam Glass <glass@postgres.berkeley.edu> +Andreas Klemm <andreas@knobel.GUN.de> +Andrew Herbert <andrew@werple.apana.org.au> +Andrew Moore <alm@FreeBSD.org> +Atsushi Murai <amurai@spec.co.jp> +Bill Paul <wpaul@FreeBSD.org> +Bob Wilcox <bob@obiwan.uucp> +Bruce Evans <bde@kralizec.zeta.org.au> +Charles Hannum <mycroft@ai.mit.edu> +Chris G. Demetriou <cgd@postgres.berkeley.edu> +Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> +Chris Torek <torek@ee.lbl.gov> +Christoph Robitschko <chmr@edvz.tu-graz.ac.at> +Curt Mayer <curt@toad.com> +Dave Burgess <burgess@hrd769.brooks.af.mil> +Dave Rivers <rivers@ponds.uucp> +David Dawes <dawes@physics.su.OZ.AU> +Frank Maclachlan <fpm@crash.cts.com> +Gary A. Browning <gab10@griffcd.amdahl.com> +Gary Clark II <gclarkii@radon.gbdata.com> +Gary Jennejohn <gj%pcs.dec.com@inet-gw-1.pa.dec.com> +Gene Stark <stark@cs.sunysb.edu> +Guido van Rooij <guido@gvr.win.tue.nl> +Havard Eidnes <Havard.Eidnes@runit.sintef.no> +Holger Veit <Holger.Veit@gmd.de> +Ishii Masahiro, R. Kym Horsell +J.T. Conklin <jtc@winsey.com> +James Clark <jjc@jclark.com> +James da Silva <jds@cs.umd.edu> et al +Jim Wilson <wilson@moria.cygnus.com> +Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> +Julian Elischer <julian@dialix.oz.au> +Julian Stacey <stacey@guug.de> <fallback: <julian@meepmeep.pcs.com>> +Keith Bostic <bostic@toe.CS.Berkeley.EDU> +Keith Moore <?> +L Jonas Olsson <ljo@po.cwru.edu> +Marc Frajola <marc@escargot.rain.com> +Mark Murray <mark@grondar.za> +Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> +Martin Birgmeier +Matt Thomas <thomas@lkg.dec.com> +Ollivier Robert <roberto@FreeBSD.org> +Paul Kranenburg <pk@cs.few.eur.nl> +Paul Mackerras <paulus@cs.anu.edu.au> +Paul Traina <pst@cisco.com> +Poul-Henning Kamp <phk@login.dkuug.dk> +Chris Provenzano <proven@athena.mit.edu> +Rob Shady <rls@id.net> +Sascha Wildner <swildner@channelz.GUN.de> +Satoshi Asami <asami@FreeBSD.org> +Scott Mace <smace@FreeBSD.org> +Sean Eric Fagan <sef@kithrup.com> +Serge V. Vakulenko <vak@zebub.msk.su> +Stefan Esser <se@MI.Uni-Koeln.DE> +Stephen McKay <syssgm@devetir.qld.gov.au> +Steven Wallace <swallace@ece.uci.edu> +Søren Schmidt <sos@login.dkuug.dk> +Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> +Terry Lee <terry@uivlsi.csl.uiuc.edu> +Theo Deraadt <deraadt@fsa.ca> +Ugen J.S.Antsilevich <ugen@NetVision.net.il> +Wolfgang Stanglmeier <wolf@kintaro.cologne.de> +Wolfram Schneider <wosch@cs.tu-berlin.de> +Yuval Yarom <yval@cs.huji.ac.il> +Yves Fonk <yves@cpcoup5.tn.tudelft.nl> + + +386BSD Patch kit patch contributors (in alphabetical order): + +Adam Glass <glass@postgres.berkeley.edu> +Adrian Hall <adrian@ibmpcug.co.uk> +Andrey A. Chernov <ache@astral.msk.su> +Andrew Herbert <andrew@werple.apana.org.au> +Andrew Moore <alm@netcom.com> +Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com> +Arne Henrik Juul <arnej@Lise.Unit.NO> +Bakul Shah <bvs@bitblocks.com> +Barry Lustig <barry@ictv.com> +Bob Wilcox <bob@obiwan.uucp> +Branko Lankester +Brett Lymn <blymn@mulga.awadi.com.AU> +Bruce Evans <bde@kralizec.zeta.org.au> +Charles Hannum <mycroft@ai.mit.edu> +Chris G. Demetriou <cgd@postgres.berkeley.edu> +Chris Torek <torek@ee.lbl.gov> +Christoph Robitschko <chmr@edvz.tu-graz.ac.at> +Daniel Poirot <poirot@aio.jsc.nasa.gov> +Dave Burgess <burgess@hrd769.brooks.af.mil> +Dave Rivers <rivers@ponds.uucp> +David Dawes <dawes@physics.su.OZ.AU> +David Greenman <davidg@Root.COM> +Eric J. Haug <ejh@slustl.slu.edu> +Felix Gaehtgens <felix@escape.vsse.in-berlin.de> +Frank Maclachlan <fpm@crash.cts.com> +Gary A. Browning <gab10@griffcd.amdahl.com> +Geoff Rehmet <csgr@alpha.ru.ac.za> +Goran Hammarback <goran@astro.uu.se> +Guido van Rooij <guido@gvr.win.tue.nl> +Guy Harris <guy@auspex.com> +Havard Eidnes <Havard.Eidnes@runit.sintef.no> +Herb Peyerl <hpeyerl@novatel.cuc.ab.ca +Holger Veit <Holger.Veit@gmd.de> +Ishii Masahiro, R. Kym Horsell +J.T. Conklin <jtc@winsey.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> +Joerg Lohse <lohse@tech7.informatik.uni-hamburg.de> +Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> +John Dyson - <formerly dyson@ref.tfs.com> +John Woods <jfw@eddie.mit.edu> +Jordan K. Hubbard <jkh@whisker.hubbard.ie> +Julian Elischer <julian@dialix.oz.au> +Julian Stacey <stacey@guug.de> <fallback: <julian@meepmeep.pcs.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@escargot.rain.com> +Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> +Martin Renters <martin@innovus.com> +Michael Galassi <nerd@percival.rain.com> +Mike Durkin <mdurkin@tsoft.sf-bay.org> +Nate Williams <nate@bsd.coe.montana.edu> +Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com> +Pace Willisson <pace@blitz.com> +Paul Kranenburg <pk@cs.few.eur.nl> +Paul Mackerras <paulus@cs.anu.edu.au> +Paul Popelka <paulp@uts.amdahl.com> +Peter da Silva <peter@NeoSoft.com> +Phil Sutherland <philsuth@mycroft.dialix.oz.au> +Poul-Henning Kamp <phk@login.dkuug.dk> +Ralf Friedl <friedl@informatik.uni-kl.de> +Rich Murphey <rich@lamprey.utmb.edu> +Rick Macklem <root@snowhite.cis.uoguelph.ca> +Robert D. Thrush <rd@phoenix.aii.com> +Rodney W. Grimes <rgrimes@cdrom.com> +Rog Egge <?> +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> +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> + +Last, but not least, the release engineer would like to thank: + His Wife, for chocolate chip cookies, and some other things. + The DGB project @ TFS, for patience and tolerance. + +$Id: CONTRIB.FreeBSD,v 1.25 1995/03/21 00:37:06 ache Exp $ diff --git a/share/FAQ/Text/FreeBSD.FAQ b/share/FAQ/Text/FreeBSD.FAQ new file mode 100644 index 0000000..ade51b5 --- /dev/null +++ b/share/FAQ/Text/FreeBSD.FAQ @@ -0,0 +1,1304 @@ + + FreeBSD + Frequently Asked Questions + For Version 2.0 + +Please mail all suggestions and additions to <FAQ@FreeBSD.ORG> + + +Revision: $Id: FreeBSD.FAQ,v 1.24 1995/03/11 19:13:26 gclarkii Exp $ + +All entries are assumed to be relevant to FreeBSD 2.0. +Any entries with a <XXX> are under construction. + + +Table of Contents +----------------- + +0 Preface +1 Installation +2 Hardware Compatibility +3 Commercial applications +4 User Applications +5 Miscellaneous Questions +6 Kernel Configuration +7 System Administration +8 Networking +9 Serial Communications + + + +0 Preface +--------- + +Welcome to the FreeBSD 2.0 FAQ! This document tries to answer some of +the most frequently asked questions about FreeBSD 2.0. +If there's something you're having trouble with and you do not see it +here, please send email to: + + <questions@FreeBSD.ORG> + + +Some of the instructions here will also refer to auxiliary utilities +in the /usr/src/share/FAQ directory. CDROM purchasers and net folks +who've grabbed the FreeBSD 2.0 `srcdist' will have these files. If +you don't have the source distribution, then you can either grab the +whole thing from: + + ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current + +Or you can grab only those files you're interested in straight out of +the FreeBSD-current distribution in: + + ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src + +0.1: What is FreeBSD? + +FreeBSD 2.0 is a UN*X type operating system based on U.C. Berkeley's +4.4BSD-lite release for the i386 platform. It is also based indirectly +on William Jolitz's port of U.C. Berkeley's Net/2 to the i386, 386BSD. +There have been many additions and bug fixes made throughout +the entire system, some of the highlights of which are: + + More robust and extensive PC device support + System V-style IPC, messaging and semaphores + Shared Libraries + Much improved virtual memory code + Better console driver support + Network booting (diskless) support + Yellow Pages support + Full support of the PCI bus + Loadable kernel modules + Too many additional utilities and applications to mention + +<2.X-Current> + Serial Console Support + Merged VM/Buffer Cache + On demand PPP + Sync PPP + Improved SCSI support + + +0.2: What are the FreeBSD mailing lists, and how can I get on them? + +The following mailing lists are provided for FreeBSD users and +developers. For more information, send to +<majordomo@FreeBSD.ORG> and include a single line saying +``help'' in the body of your message. + +announce: For announcements about or on FreeBSD. +hackers: Useful for persons wishing to work on the internals. +questions: General questions on FreeBSD. +bugs: Where bugs should be sent. +SCSI: Mailing list for SCSI developers. +current: This list is for persons wishing to run FreeBSD-current + and carries announcements and discussions on current. +security: For issues dealing with system security. +platforms: Deals with ports to non-Intel platforms +ports: Discussion of /usr/ports/??? +fs: Discussion of FreeBSD Filesystems +hardware: Discussion on hardware requirements for FreeBSD. + +The FreeBSD-commit list has been broken up into groups dealing with different +areas of interest. Please see the FreeBSD mailing list FAQ in: + + /usr/src/share/FAQ/mailing-list.FAQ + + +0.3: What are the various FreeBSD news groups? + +While there are no groups currently dedicated to FreeBSD, you may find +the following groups useful. + +comp.os.386bsd.announce: For announcements +comp.os.386bsd.apps: For applications +comp.os.386bsd.questions: For questions +comp.os.386bsd.development: For working on the internals +comp.os.386bsd.bugs: About bugs +comp.os.386bsd.misc: For items that don't fit anywhere else + +NOTE: These groups cover all the *BSDs (FreeBSD, NetBSD, 386BSD). + +comp.os.bsd: General BSD topics, maybe of intrest + +NOTE: As of the date of this writing, there is has been a break up of +newsgroups into groups for each OS. These groups can be found under +``comp.unix.bsd''. + + +1 Installation +-------------- + +1.1: I want to install FreeBSD onto a SCSI disk that has more than + 1024 cylinders. How do I do it? + +This depends. If you don't have DOS (or another operating system) on +the system, you can just keep the drive in native mode and simply make +sure that your root partition is below 1024 so the BIOS can boot the +kernel from it. It you also have DOS/some other OS on the drive then +your best bet is to find out what parameters that it thinks you have +before installing FreeBSD. When FreeBSD's installation procedure +prompts you for these values, you should then enter them rather than +simply going with the defaults. + +There is a freely available utility distributed with FreeBSD called +`pfdisk' (located in the tools/dos-tools subdirectory) which can be used for +this purpose. + + +1.2: When I boot FreeBSD it says ``Missing Operating System''. + +See question 1.2. This is classically a case of FreeBSD and DOS or +some other OS conflicting over their ideas of disk geometry. You will +have to reinstall FreeBSD, but obeying the instructions given above +will almost always get you going. + +1.3: When I install the boot manager and try to boot FreeBSD for the + first time, it just comes back with the boot manager prompt again. + +This is another symptom of the problem described in 1.2. Your +BIOS geometry and FreeBSD geometry settings do not agree! If your +controller or BIOS supports cylinder translation (often marked +as ">1GB drive support"), try toggling its setting and reinstalling +FreeBSD. + +1.4: I have an IDE drive with lots of bad blocks on it and FreeBSD doesn't + seem to install properly. + +FreeBSD's bad block (bad144) handling is still not 100% (to put it +charitably) and it must unfortunately be said that if you've got an +IDE or ESDI drive with lots of bad blocks, then FreeBSD is probably +not for you! That said, it does work on thousands of IDE based +systems, so you'd do well to try it first before simply giving up. + +IDE drives are *supposed* to come with built-in bad-block remapping; +if you have documentation for your drive, you may want to see if this +feature has been disabled on your drive. However, ESDI, RLL, and +ST-506 drives normally do not do this. + +1.5: I have 32MB of memory, should I expect any special problems? + +No. FreeBSD 2.0 comes with bounce buffers which allows your bus +mastering controller access to greater than 16MB. + +1.6: Do I need to install the complete sources? + +In general, no. However, we would strongly recommend that you +install, at a minimum, the `base' source kit, which includes several +of the files mentioned here, and the `sys' (kernel) source kit, which +includes sources for the kernel. There is nothing in the system which +requires the presence of the sources to operate, however, except for +the kernel-configuration program config(8). With the exception of the +kernel sources, our build structure is set up so that you can +read-only mount the sources from elsewhere via NFS and still be able +to make new binaries. (Because of the kernel-source restriction, we +recommend that you not mount this on /usr/src directly, but rather in +some other location with appropriate symbolic links to duplicate the +top-level structure of the source tree.) + +Having the sources on-line and knowing how to build a system with them +will make it much easier for you to upgrade to future releases of +FreeBSD. + +1.7: DES encryption software can not be exported from the United + States. If I live outside the US, how can I encrypt passwords? + +If it is not absolutely imperative that you use DES style encryption, +you can use FreeBSD's default encryption for even _better_ security, +and with no export restrictions. FreeBSD 2.0's password default +scrambler is now MD5 based, and is more CPU-intensive to crack +with an automated password cracker than DES. + +Since the DES encryption algorithm cannot legally be exported from the US, +non-US users should not download this software (as part of the secrdist) +from US FTP sites. + +There is however a replacement libcrypt available, based on sources +written in Australia by David Burren. This code is now available on +some non-US FreeBSD mirror sites. Sources for the unencumbered +libcrypt, and binaries of the programs which use it, can be obtained +from the following FTP sites: + + South Africa: braae.ru.ac.za:/pub/FreeBSD/securedist/ + owl.und.ac.za (currently uncertain) + Iceland: ftp.veda.is:/pub/crypt/FreeBSD/ + +The non-US securedist can be used as a direct replacement for the +encumbered US securedist. This securedist package is installed the +same way as the US package (see installation notes for details). If +you are going to install DES encryption, you should do so as soon as +possible, before installing other software. + +Non-US users should please not download any encryption software from +the USA. This can get the maintainers of the sites from which the +software is downloaded into severe legal difficulties. + +A non-US distribution of Kerberos is also being developed, and current +versions can generally be obtained by anonymous FTP from +braae.ru.ac.za. + +There is a mailing list for the discussion of non-US encryption +software. For more information, send an email message with a single +line saying ``help'' in the body of your message to +<majordomo@braae.ru.ac.za>. + + + +2 Hardware compatibility +------------------------ + +2.1: What kind of hard drives does FreeBSD run on? + +FreeBSD supports ST-506 (sometimes called ``MFM''), RLL, and ESDI +drives, which are usually connected to WD-1002, WD-1003, or WD-1006 +controllers (although clones should also work). + +FreeBSD also supports IDE and SCSI hard drives. + +2.2: What SCSI controllers are supported? + +FreeBSD supports the following SCSI controllers: + +Adaptec AH-154x Series <ISA> + AH-174x Series <EISA> + AH-152x Series <ISA> + Sound Blaster SCSI (AH-152x compat) <ISA> + AH-2742/2842 Series <ISA/EISA> + AH-2820/2822/2825 Series <VLB> +Buslogic BT-445 Series <VLB> (but see section 1.5) + BT-545 Series <ISA> + BT-742 Series <EISA> + BT-747 Series <EISA> + BT-964 Series <PCI> +Future Domain TMC-950 Series <ISA> +PCI Generic NCR 53C810 based controllers <PCI> +ProAudioSpectrum Zilog 5380 based controllers <ISA> +Seagate ST-01/02 Series <ISA> +UltraStor UH-14f Series <ISA> + UH-34f Series <EISA/VLB> + +<2.X-Current Only> +Western Digital WD7000 <ISA> <No scatter/gather> +Adaptec AH-294x and aic7870 MB controllers <PCI> +ProAudioSpectrum Trantor 130 based controllers <ISA> + +2.3: What CD-ROM drives are supported by FreeBSD? + +Any SCSI drive connected to a supported controller. +Mitsumi LU002(8bit), LU005(16bit) and FX001D(16bit 2x Speed). + +<2.X-Current> +Sound Blaster Non-SCSI CD-ROM + +FreeBSD does not support any of the ``IDE'' CD-ROM interfaces. +All non-SCSI cards are known to be extremely slow compared to SCSI +drives. + +2.4: What multi-port serial cards are supported by FreeBSD? + +AST/4 +BOCA 4/8/16 port cards. + +<2.X-Current> +Cyclades 8/16 port <Alpha> + +Some unnamed clone cards have also been known to work,, especially those +that claim to be AST compatible. +Check the sio(4) man page to get more information on configuring such +cards. + + +2.5: Does FreeBSD support the AHA-2742/2842 SCSI adapters from Adaptec? + +Yes, though portions of the sources are currently GPL'd (that is to say, +distributed under the GNU Public License), so be aware of the fact should +you wish to distribute kernel binaries compiled with it - you MUST also +provide the sources to the driver with the kernel image to stay legal +with the GPL! This is easily enough done by simply including the contents +of /usr/src/sys/gnu/{aic7770,misc} on whatever media you distribute the +kernel. + +We are working to get the GPL restriction removed, but for now you should +at least be aware of it. + + +2.6: I have a Mumbleco bus mouse. Is it supported and if so, how do I set + it up for XFree86? + +FreeBSD supports the Logitech and ATI Inport bus mice. You need to +add the following line to the kernel config file and recompile for the +Logitech and ATI mice: + + device mse0 at isa? port 0x23c tty irq6 vector mseintr + + +2.7: I have a PS/2 mouse (`keyboard' mouse) [Alternatively: I have a + laptop with a track-ball mouse]. How do I use it? + + + +2.8: What types of tape drives are supported under FreeBSD? + +FreeBSD supports SCSI, QIC-02 and QIC-40/80 (Floppy based) tape +drives. This includes 8-mm (aka Exabyte) and DAT drives. + + +2.9: What sound cards are supported by FreeBSD? + +FreeBSD supports the SoundBlaster, SoundBlaster Pro, Pro Audio +Spectrum 16, AdLib and Gravis UltraSound sound cards. There is also +limited support for MPU-401 and compatible MIDI cards. The +SoundBlaster 16 and SoundBlaster 16 ASP cards are not yet supported. +NOTE: This is only for sound! This driver does not support CD-ROMs, +SCSI or joysticks on these cards. + + +2.10: What network cards does FreeBSD support? + +There is support for the following cards: + +`ed' driver: + NE2000 and 1000 + WD/SMC 8003, 8013 and Elite Ultra (8216) + 3Com 3c503 + And clones of the above + +`de' driver: + DEC and compatible PCI controllers. + +`le' driver: + DEC LANCE ethernet based controllers. + +`ie' driver: + AT&T EN100/StarLAN 10 + 3Com 3c507 + +`is' driver: + Isolan AT 4141-0 + Isolink 4110 + +`ep' driver: + 3com 3c509 (*) + +`el' driver: + 3com 3c501 (*) + +`ze' driver: + IBM PCMCIA credit card adapter + +`lnc' driver: + Unknown Lance based (*) + +<2.X-Current> + +`cx' driver + Cronyx/Sigma multiport Sync/Async (Cisco and PPP framing) + +`zp' driver + 3Com PCMCIA Etherlink III + +Note: Drivers marked with (*) are known to have problems. + +Note: We also support TCP/IP over parallel lines. At this point we are + incompatiable with other versions, but we hope to correct this in + the near future. + +2.11: I have a 386/486sx/486SLC machine without a math co-processor. + Will this cause me any problems? + +Generally no, but there are circumstances where you will take a hit, +either in performance or accuracy of the math emulation code (see +section 4.1). In particular, drawing arcs in X will be VERY slow. It +is highly recommended that you lay out the $50 or so for a math +co-processor; it's well worth it. NOTE: Some math co-processors are +better than others. It pains us to say it, but nobody ever got fired +for buying Intel. Unless you're sure it works with FreeBSD, beware of +clones. + +2.12: What other devices does 2.X support? + +Here is a listing of drivers that do not fit into any of the above areas. + +b004.c Driver for B004 compatiable Transputer boards +ctx.c Driver for CORTEX-I Frame grabber +gpib.c Driver for National Instruments AT-GPIB and AT-GPIB/TNT boards +pcaudio.c Driver for PC speakers to allow the playing of audio files +tw.c Driver for the X-10 POWERHOUSE + +<2.X-Current> +spigot.c Driver for the Creative Labs Video Spigot +gsc.c Driver for the Genuis GS-4500 Hand scanner +joy.c Driver for a joystick + +2.13: I am about to buy a new machine to run FreeBSD on and + want an idea of what other people are running. Is there list + of other systems anywhere? + +Yes. Please look at the file Systems.FAQ. This file +is a listing of hardware that people are running in their machines. +Please note, this is a raw listing of equipment that other users +have sent in, and does not constitute any kind of endorsement by the +FreeBSD Project. + +2.14: I have a lap-top with power management. Can FreeBSD take advantage + of this? + +Yes it can on certain machines. Please look in the LINT kernel config +file under APM. + + + +3 Commercial Applications +------------------------- + +Note: This section is still very sparse, though we're hoping, of +course, that companies will add to it! :) The FreeBSD group has no +financial interest in any of the companies listed here but simply +lists them as a public service (and feels that commercial interest in +FreeBSD can have very positive effects on FreeBSD's long-term +viability). We encourage commercial software vendors to send their +entries here for inclusion. + + +3.1: Where can I get Motif for FreeBSD? + +You can purchase Motif 1.2.3 for FreeBSD (SWiM) from the ACC Bookstore, +P.O. Box 3364, Westport CT. 06880. 1-800-546-7274 or FAX: 1-203-454-2582 + +This software works flawlessly for for FreeBSD 1.1.5 but has shown +one problem with 2.0 in that the "uil" program core dumps. This is +apparently because of the way uil is installed, and it's quite possible +that ACC will have a fixed version by the time you read this. No +other compatibility problems with the programs or libraries have been +found, and ACC can hardly be blamed for failing to work perfectly with +a brand-new release they haven't even seen yet! :) + + +3.2: Are there any commercial X servers for some of the high-end + graphics cards like the Matrox or #9 I-128, or offering 8/16/24 + bit deep pallettes? + +Yes, X Inside Incorporated sells their Accelerated-X product for +FreeBSD and other Intel based systems. + +This high performance X Server offers easy configuration, support +for multiple concurrent video boards and is distributed in binary +form only. + +Price is $99.50 (promotional price for Linux/FreeBSD version) for +the 1.1 version, which is available now. + +This product is for FreeBSD 1.1 and runs under 2.0 with the FreeBSD 1.1 +compatibility libs (`compat1xdist'). + +More info: URL http://www.xinside.com/ + or URL ftp://ftp.xinside.com/accelx/1.1/prodinfo.txt + or email info@xinside.com + or phone +1(303)384-9999 + + +3.3: Any other applications I might be interested in? + +RenderMorphics, Ltd. sells a high-speed 3D rendering package for +FreeBSD called "Reality Lab" (tm). Send email to info@render.com +or call: +44(0)71-251-4411 / FAX: +44(0)71-251-0939 + +This package is also for FreeBSD 1.1.5 but has been tested and shown +to run under FreeBSD 2.0 with the compat1xdist installed. + +Thanks must be extended to all of these companies for showing enough faith +in FreeBSD to port their products to it. While we get no direct benefit +from the sales of these products, the indirect benefits of FreeBSD +proving itself to be a successful platform for such commercial interests +will be immense! We wish these companies every measure of success, and +can only hope that others are encouraged to follow suit. + + +4 User Applications +------------------- + +4.1: I want to run X, how do I go about it? + +First, get the XFree86 distribution of X11R6 from XFree86.cdrom.com. +The version you want for FreeBSD 2.X and later is XFree86 3.1.1. Follow +the instructions for installation carefully. You may then wish to read +the documentation for the ConfigXF86 tool, which assists you in +configuring XFree86 for your particular graphics card/mouse/etc. + +You may also wish to investigate the Xaccel server, which is available +at a very reasonable price. See section 3.2 for more details. + +4.2: I've been trying to run ghostscript on a 386 (or 486sx) with no + math co-processor and I keep getting errors. What's up? + +You will need to add the alternate math emulator to your kernel, you do this +by adding the following to your kernel config file and it will be compiled in. + +options GPL_MATH_EMULATE + +NOTE: You will need to remove the MATH_EMULATE option when you do this. + + +4.2: I want all this neat software, but I haven't got the space or + CPU power to compile it all myself. Is there any way of getting + binaries? + +Yes. We support the concept of a `package', which is essentially a +gzipped binary distribution with a little extra intelligence embedded +in it for doing any custom installation work required. Packages can +also be installed or deinstalled again easily without having to know +the gory details. CDROM people will have a packages/ directory on +their CD, others can get the currently available packages from: + + ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages + +Note that all ports may not be available as packages, and that new +packages are constantly being added. It is always a good idea to +check periodically to see which packages are available. A README file +in the packages directory provides more details on the care and +feeding of the package software, so no explicit details will be given +here. + + + + +5 Miscellaneous Questions +---------------- + +5.1: I've heard of something called FreeBSD-current. How do I run it, and + where can I get more information? + +Read the file /usr/src/share/FAQ/current-policy.FAQ, +it will tell you all you need to know. + + +5.2: What is this thing called `sup', and how do I use it? + +SUP stands for Software Update Protocol, and was developed by CMU for +keeping their development trees in sync. We use it to keep remote +sites in sync with our central development sources. + +Unless you have direct internet connectivity, and don't care too much +about the cost/duration of the sessions, you shouldn't use sup. For +those "low/expensive-bandwidth" applications, we have developed CTM, +see 5.6 for more about that. + +To use it, you need to have direct internet connectivity (not just +mail or news). First, pick up the sup.tgz package from: + + ftp://ftp.FreeBSD.ORG/pub/FreeBSD/packages/sup.tgz + +Second, read the file /usr/src/share/FAQ/sup.FAQ. + +This file describes how to setup sup on your machine. You may also +want to look at /usr/src/share/FAQ/extras/*.supfile, or you may grab updated +supfiles from: + + ftp://ftp.FreeBSD.ORG//pub/FreeBSD/FAQ/extras + +which are a set of supfiles for supping from FreeBSD.ORG. + + +5.3: How do I create customized installation disks that I can give + out to other people at my site? + +The entire process of creating installation disks and source and +binary archives is automated by various targets in +/usr/src/etc/Makefile. The information there should be enough to get +you started. + +5.4: How do I re-build my system without clobbering the existing + installed binaries? + +If you define the environment variable DESTDIR while running `make +world' or `make install', the newly-created binaries will be deposited +in a directory tree identical to the installed one, rooted at +${DESTDIR}. Some random combination of shared libraries modifications +and program rebuilds can cause this to fail in `make world', however. + + +5.5: When my system booted, it told me that ``(bus speed defaulted)''. + What does that mean? + +The Adaptec 1542 SCSI host adapters allow the user to configure their +bus access speed in software. Previous versions of the 1542 driver tried +to determine the fastest usable speed and set the adapter to that. We +found that this breaks some users' systems, so you now have to define +the ``TUNE_1542''' kernel configuration option in order to have this +take place. Using it on those systems where it works may make your +disks run faster, but on those systems where it doesn't, your data could +be corrupted. + +5.6: I would like to track changes to current and do not have net access. + Is there any way besides downloading the whole tree? + +Yes, you can use the CTM facility. Check out the ctm.FAQ file or + ftp://freefall.cdrom.com/pub/CTM/README +for more information. + +5.7: How do I split up large binary files into smaller 240k files + like the distribution does? + +Newer BSD based systems have a "-b" option to split that allows them to +split files on arbitary byte bondaries. + +Here is an example from /usr/src/Makefile. +bin-tarball: + (cd ${DISTDIR}; \ + tar cf - . \ + gzip --no-name -9 -c | \ + split -b 240640 - \ + ${RELEASEDIR}/tarballs/bindist/bin_tgz.) + + +<XXX> 5.8: I've had a couple of system panics and would like to be able + browse the system dumps. The normal kernel is stripped and + I don't want to run a bloated kernel. What can I do? + +5.9: I just got a Perl application and it's bombing looking for + *.ph. Where is it? + +There was a minor SNAFU in the 2.0-R bindist and they got left out. +If you have the source, you just have to do a "make install" from +/usr/src/gnu/usr.bin/perl/lib and everything will be fine. Or you +may ftp to phoenix-gw.gbdata.com and grab them from ~/pub/perl/libs.tar.gz. + +5.10: I've got this neato kernel extension I just know everyone will + will want. How do I get it included into the distribution? + +Please take a look at the FAQ for submiting code to FreeBSD at: + + ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FAQ/submitters.FAQ + +And thanks for the thought. + + +6 Kernel Configuration +---------------------- + +6.0: Ok, so how DO I compile my own kernel, anyway? + +Before you can compile a kernel, you need either the complete srcdist +or, at the minimum, the kerndist loaded on your system. This provides +the necessary sources for building the kernel, as we have a policy of +NOT shipping our kernels in linkable object form as most commercial +UNIX vendors do. Shipping the source takes a bit more space, but it also +means that you can refer to the actual kernel sources in case of difficulty +or to further your understanding of what's *actually* happening. + +Anyway, to answer the question, once you have the kerndist or srcdist +loaded, do this: + + 6.0.1: cd /usr/src/sys/i386/conf + 6.0.2: cp GENERIC MYKERNEL + 6.0.3: vi MYKERNEL + 6.0.4: config MYKERNEL + 6.0.5: cd ../../compile/MYKERNEL + 6.0.6: make all + 6.0.7: make install + 6.0.8: reboot + +Step 6.0.2 may not be necessary if you already have a kernel configuration +file from a previous release of FreeBSD 2.x. - simply bring your old one +over and check it carefully for any drivers that may have changed boot +syntax or been rendered obsolete. + +A good kernel config file to look into is LINT, which contains entries for +*all* possible kernel options and documents them fairly well. The GENERIC +kernel config file is used to build the initial release you probably loaded +(unless you upgraded in-place) and contains entries for the most common +configurations. It's a pretty good place to start from. + +If you don't need to make any changes to GENERIC, you can also skip step +6.0.3, where you customize the kernel for your configuration. Step 6.0.7 +should only be undertaken if step 6.0.6 succeeds. This will copy +the new kernel image to /kernel and BACK UP YOUR OLD ONE IN /kernel.old! +It's very important to remember this in case the new kernel fails to work +for some reason - you can still select /kernel.old at the boot prompt to +boot the old one. When you reboot, the new kernel will boot by default. + +If the compile in 6.0.6 falls over for some reason, then it's recommended +that you start from step 6.0.4 but substitute GENERIC for MYKERNEL. If you +can generate a GENERIC kernel, then it's likely something in your special +configuration file that's bad (or you've uncovered a bug!). If the build +of the GENERIC kernel does NOT succeed, then it's very likely that your +sources are somehow corrupted. + +Finally, if you need to see your original boot messages again to compile +a new kernel that's better tailored to your hardware, try the `dmesg' command. +It should print out all the boot-time messages printed by your old kernel, +some of which may be quite helpful in configuring the new one. + + +6.1: When I compile a kernel with multi-port serial code, it tells me + that only the first port is probed and the rest skipped due to + interrupt conflicts. How do I fix this? + +The problem here is that FreeBSD has code built-in to keep the kernel +from getting trashed due to hardware or software conflicts. The way +to fix this is to leave out the IRQ settings on other ports besides +the first. Here is a example: + +# +# Multiport high-speed serial line - 16550 UARTS +# +device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr +device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr +device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr +device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr + + +6.2: FreeBSD is supposed to come with support for QIC-40/80 drives but + when I look, I can't find it. + +You need to uncomment the following line in the generic config file +(or add it to your config file) and recompile. + +controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr +disk fd0 at fdc0 drive 0 +disk fd1 at fdc0 drive 1 +#tape ft0 at fdc0 drive 2 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You will have a device called /dev/ft0, which you can write to through +a special program to manage it called `ft' - see the man page on ft for +further details. Versions previous to -current also had some trouble dealing +wiht bad tape media; if you have trouble where ft seems to go back and forth +over the same spot, try grabbing the latest version of ft from /usr/src/sbin/ft +in current and try that. + + +6.3: Does FreeBSD support IPC primitives like those in System V? + +Yes, FreeBSD supports System V-style IPC. This includes shared +memory, messages and semaphores. You need to add the following lines +to your kernel config to enable them. + +options SYSVSHM +options "SHMMAXPGS=64" # 256Kb of sharable memory +options SYSVSEM # enable for semaphores +options SYSVMSG # enable for messaging + +Recompile and install. + + +6.4: Will FreeBSD ever support other architectures? + +Several different groups have expressed interest in working on +multi-architecture support for FreeBSD. If you are interested in +doing so, please contact the developers at +<FreeBSD-hackers@FreeBSD.ORG> for more information on our +strategy for porting. + + +6.5: I just wrote a device driver for a Foobar Systems, Inc. + Integrated Adaptive Gronkulator card. How do I get the + appropriate major numbers assigned? + +This depends on whether or not you plan on making the driver publicly +available. If you do, then please send us a copy of the driver source +code, plus the appropriate modifications to files.i386, a sample +configuration file entry, and the appropriate MAKEDEV code to create +any special files your device uses. If you do not, or are unable to +because of licensing restrictions, then character major number 32 and +block major number 8 have been reserved specifically for this purpose; +please use them. In any case, we'd appreciate hearing about your +driver on <FreeBSD-hackers@FreeBSD.ORG>. + + + +7 System Administration +----------------------- + +7.1: How do I add a user easily? I read the man page and am more confused + than ever! [Alternatively: I didn't read the man page, I never read + man pages! :-) ] + +Use the adduser command. + + +<XXX> 7.2: I'm trying to use my printer and keep running into problems. I tried + looking at /etc/printcap, but it's close to useless. Any ideas? + + + +8 Networking +------------ + + +8.2: I've heard that you can use a FreeBSD box as a dedicated network + router - is there any easy support for this? + +Internet standards and good engineering practice prohibit us from +providing packet forwarding by default in FreeBSD. You can enable +this support by adding `options GATEWAY' to your kernel configuration +file and recompiling. In most cases, you will also need to run a +routing process to tell other systems on your network about your +router; FreeBSD comes with the standard BSD routing daemon routed(8), +or for more complex situations you may want to try GateD (available by +FTP from gated.Cornell.edu) which supports FreeBSD as of 3_5Alpha7. + +It is our duty to warn you that, even when FreeBSD is configured in +this way, it does not completely comply with the Internet standard +requirements for routers; however, it comes close enough for ordinary +usage. + + +8.3: Does FreeBSD support SLIP and PPP? + +Yes. See the man pages for slattach(8) and/or pppd(8) if you're using +FreeBSD to connect to another site. If you're using FreeBSD as a +server for other machines, look at the man page for sliplogin(8). +You may also want to take a look at the slip FAQ in: + /usr/src/share/FAQ/Slip.FAQ + +8.4: How do I get my network set up? I don't see how to make my + /dev/ed0 device! + +In the Berkeley networking framework, network interfaces are only +directly accessible by kernel code. Please see the /etc/netstart file +and the manual pages for the various network programs mentioned there +for more information. If this leaves you totally confused, then you +should pick up a book describing network administration on another +BSD-related operating system; with few significant exceptions, +administering networking on FreeBSD is basically the same as on SunOS +4.0 or Ultrix. + +8.5: How do I get my 3C503 to use the other network port? + +Use `ifconfig ed0' to see whether the ALTPHYS flag is set, and then +use either `ifconfig ed0 altphys' if it was off, or `ifconfig ed0 +-altphys' if it was on. + +8.6: I'm having problems with NFS to/from FreeBSD and my Wuffotronics + Workstation / generic NFS appliance, where should I look first? + +Certain PC network cards are better than others (to put it mildly) and +can sometimes cause problems with network intensive applications like +NFS. See /usr/src/share/FAQ/NFS.FAQ for more information on this +topic. + +8.8: I want to enable IP multicast support on my FreeBSD box, how do I do it? + [Alternatively: What the heck IS multicasting and what applications + make use of it?] + +Multicast host operations are fully supported in FreeBSD 2.0 by default. +If you want your box to run as a multicast router, you will need to load +the ip_mroute_mod loadable kernel module and run mrouted. + +For more information: + +Product Description Where +--------------- ----------------------- --------------------------------------- +faq.txt Mbone FAQ ftp.isi.edu:/mbone/faq.txt +imm/immserv IMage Multicast ftp.hawaii.edu:/paccom/imm.src.tar.Z + for jpg/gif images. +nv Network Video. ftp.parc.xerox.com: + /pub/net-reseach/exp/nv3.3alpha.tar.Z +vat LBL Visual Audio Tool. ftp.ee.lbl.gov: + /conferencing/vat/i386-vat.tar.Z +wb LBL White Board. ftp.ee.lbl.gov: + /conferencing/wb/i386-wb.tar.Z +mmcc MultiMedia Conference ftp.isi.edu: + Control program /confctrl/mmcc/mmcc-intel.tar.Z +rtpqual Tools for testing the ftp.psc.edu:/pub/net_tools/rtpqual.c + quality of RTP packets. +vat_nv_record Recording tools for vat ftp.sics.se:archive/vat_nv_record.tar.Z + and nv. + + + +9 Serial Communications +----------------------- + +This section answers common questions about serial communications with +FreeBSD. + +9.1: How do I tell if FreeBSD found my serial ports or modem cards? + +As the FreeBSD kernel boots, it will probe for the serial ports in +your system for which the kernel was configured. You can either watch +your system closely for the messages it prints or run the command + + dmesg | grep sio + +after your system's up and running. + +Here's some example output from the above command: + + sio0 at 0x3f8-0x3ff irq 4 on isa + sio0: type 16550A + sio1 at 0x2f8-0x2ff irq 3 on isa + sio1: type 16550A + +This shows two serial ports. The first is on irq 4, is using port +address 0x3f8, and has a 16550A-type UART chip. The second uses the +same kind of chip but is on irq 3 and is at port address 0x2f8. +Internal modem cards are treated just like serial ports---except that +they always have a modem ``attached'' to the port. + +The GENERIC kernel includes support for two serial ports using the +same irq and port address settings in the above example. If these +settings aren't right for your system, or if you've added modem cards +or have more serial ports than your kernel is configured for, just +reconfigure your kernel. See section 7 of the FAQ for more details. + +9.2: How do I access the serial ports once FreeBSD is running? + +The third serial port, sio2 (known as COM3 in DOS), is on /dev/tty02 +for directly-connected devices, on /dev/cuaa2 for dial-out devices, +and on /dev/ttyd2 for dial-in devices. What's the difference between +these three classes of devices? + +You use ttyXX for directly-connected or hardwired devices, like +printers or terminals. + +In place of ttyXX, you can use the pair of devices cuaaX and ttydX. +You use ttydX for dial-ins. The ttydX device acts like the ttyXX +device, but it also uses the modem control lines. When opening +/dev/ttydX in blocking mode, a process will wait for the corresponding +cuaaX device to become inactive, and then wait for the carrier detect +line to go active. When you open the cuaaX device, it makes sure the +serial port isn't already in use by the ttydX device. If the port's +available, it ``steals'' it from the ttydX device. Also, the cuaaX +device doesn't care about carrier detect. With this scheme and an +auto-answer modem, you can have remote users log in and you can still +dialout with the same modem and the system will take care of all the +conflicts. + +9.3: How do I configure the kernel for my multiport serial card? + +Again, the section on kernel configuration provides information about +configuring your kernel. For a multiport serial card, place an sio +line for each serial port on the card in the kernel configuration +file. But place the irq and vector specifiers on only one of the +entries. All of the ports on the card should share one irq. For +consistency, use the last serial port to specify the irq. Also, +specify the COM_MULTIPORT option. + +The following example is for an AST 4-port serial card on irq 7: + + options "COM_MULTIPORT" + device sio4 at isa? port 0x2a0 tty flags 0x781 + device sio5 at isa? port 0x2a8 tty flags 0x781 + device sio6 at isa? port 0x2b0 tty flags 0x781 + device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr + +The flags indicate that the master port has minor number 7 (0x700), +diagnostics enabled during probe (0x080), and all the ports share an +irq (0x001). + +9.4: I have two multiport serial cards that can share irqs. Can + FreeBSD handle this? + +Not yet. You'll have to use a different irq for each card. + +9.5: What's the difference between tty01, ttyi01, and ttyl01? Or, + how can I set the default serial parameters for a port? + +The ttyXX (or cuaaX or ttydX) device is the regular device you'll want +to open for your applications. When a process opens the device, it'll +have a default set of terminal I/O settings. You can see these +settings with the command + + stty -a -f /dev/tty01 + +When you change the settings to this device, the settings are in +effect until the device is closed. When it's reopened, it goes back +to the default set. To make changes to the default set, you can open +and adjust the settings of the ``initial state'' device. For example, +to turn on CLOCAL mode, 8 bits, and XON/XOFF flow control by default +for tty05, do: + + stty -f /dev/ttyi05 clocal cs8 ixon ixoff + +A good place to do this is in /etc/rc.serial. Now, an application +will have these settings by default when it opens tty05. It can still +change these settings to its liking, though. + +You can also prevent certain settings from being changed by an +application by making adjustments to the ``lock state'' device. For +example, to lock the speed of tty05 to 57600 bps, do + + stty -f /dev/ttyl05 57600 + +Now, an application that opens tty05 and tries to change the speed of +the port will be stuck with 57600 bps. + +Naturally, you should make the initial state and lock state devices +writable only by root. The MAKEDEV script does NOT do this when it +creates the device entries. + +9.6: How can I enable dialup logins on my modem? + +So you want to become an Internet service provider, eh? First, you'll +need one or more modems that can autoanswer. Your modem will need to +assert carrier-detect when it detects a carrier and not assert it all +the time. It will need to hang up the phone and reset itself when the +data terminal ready (DTR) line goes from on to off. It should +probably use RTS/CTS flow control or no local flow control at all. +Finally, it must use a constant speed between the computer and itself, +but (to be nice to your callers) it should negotiate a speed between +itself and the remote modem. + +For many Hayes command-set--compatible modems, this command will +make these settings and store them in nonvolatile memory: + + AT &C1 &D3 &K3 &Q6 S0=1 &W + +See 9.10 below for information on how to make these settings without +resorting to an MS-DOS terminal program. + +Next, make an entry in /etc/ttys for the modem. This file lists all +the ports on which the operating system will await logins. Add a line +that looks something like this: + + ttyd1 "/usr/libexec/getty std.57600" dialup on insecure + +This line indicates that the second serial port (/dev/ttyd1) has a +modem connected running at 57600 bps and no parity (std.57600, which +comes from the file /etc/gettytab). The terminal type for this port +is ``dialup.'' The port is ``on'' and is ``insecure''---meaning root +logins on the port aren't allowed. For dialin ports like this one, +use the ttydX entry. + +It's common practice to use ``dialup'' as the terminal type. Many +users set up in their .profile or .login files a prompt for the actual +terminal type if the starting type is dialup. The example shows the +port as insecure. To become root on this port, you have to login as a +regular user, then ``su'' to root. If you use ``secure'' then root +can login in directly. + +After making modifications to /etc/ttys, you need to send a hangup or +HUP signal to the init process: + + kill -1 1 + +This forces the init process to reread /etc/ttys. The init process +will then start getty processes on all ``on'' ports. You can find out +if logins are available for your port by typing + + ps -ax | grep '[t]tyd1' + +You should see something like: + + 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 + +9.7: How can I make my spare computer a dumb terminal connected to my + FreeBSD box? + +If you're using another computer as a terminal into your FreeBSD +system, get a null modem cable to go between the two serial ports. If +you're using an actual terminal, see its accompanying instructions. + +Then, modify /etc/ttys, like above. For example, if you're hooking up +a WYSE-50 terminal to the fifth serial port, use an entry like this: + + tty04 "/usr/libexec/getty std.38400" wyse50 on secure + +This example shows that the port on /dev/tty04 has a wyse50 terminal +connected at 38400 bps with no parity (std.38400 from /etc/gettytab) +and root logins are allowed (secure). For directly-connected +terminals, use the ttyXX entry. + +9.8: Why can't I run tip or cu? + +On your system, the programs tip and cu are probably executable only +by uucp and group dialer. You can use the group dialer to control who +has access to your modem or remote systems. Just add yourself to +group dialer. + +Alternatively, you can let everyone on your system run tip and cu by +typing: + + chmod 4511 /usr/bin/tip + +You don't have to run this command for cu, since cu is just a hard +link to tip. + +9.9: My stock Hayes modem isn't supported---what should I do? + +Actually, the man page for tip is out of date. There is a generic +Hayes dialer already built in. Just use ``at=hayes'' in your +/etc/remote file. + +The Hayes driver isn't smart enough to recognize some of the advanced +features of newer modems---messages like BUSY, NO DIALTONE, or CONNECT +115200 will just confuse it. You should turn those messages off when +you use tip (using ATX0&W). + +Also, the dial timeout for tip is 60 seconds. Your modem should use +something less, or else tip will think there's a communication +problem. Try ATS7=45&W. + +9.10: How am I expected to enter these AT commands without + resorting to some DOS-based terminal program? + +Make what's called a ``direct'' entry in your /etc/remote file. For +example, if your modem's hooked up to the first serial port, +/dev/cuaa0, then put in the following line: + + cuaa0:dv=/dev/cuaa0:br#19200:pa=none + +Use the highest bps rate your modem supports in the br capability. +Then, type ``tip cuaa0'' and you'll be connected to your modem. + +If there is no /dev/cuaa0 on your system, do this: + + cd /dev + MAKEDEV cuaa0 + +9.11: Why doesn't the @ sign for the phone number capability work? + +The @ sign in the pn capability tells tip to look in /etc/phones for a +phone number. But the @ sign is also a special character in +capability files like /etc/remote. Escape it with a backslash: +``pn=\@''. + +9.12: How can I dial a phone number on the command line? + +Put what's called a ``generic'' entry in your /etc/remote file. For +example: + + tip115200|Dial any phone number at 115200 bps:\ + :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: + tip57600|Dial any phone number at 57600 bps:\ + :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: + +Then you can things like ``tip -115200 5551234''. If you prefer cu +over tip, use a generic cu entry: + + cu115200|Use cu to dial any number at 115200bps:\ + :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: + +and type ``cu 5551234 -s 115200''. + +9.13: Great---but how can I do that without having to specify the bps + rate on the command line? + +Put in an entry for tip1200 or cu1200, but go ahead and use whatever +bps rate is appropriate with the br capability. tip thinks a good +default is 1200 bps which is why it looks for a ``tip1200'' entry. +You don't have to use 1200 bps, though. + +9.14: I want separate entries for various hosts I access through a + terminal server, but I don't want to type ``CONNECT <host>'' + each time once I'm connected. Can tip do that for me? + +Yes. Use the cm capability. For example, these entries in +/etc/remote: + + pain|pain.deep13.com|Forrester's machine:\ + :cm=CONNECT pain\n:tc=deep13: + muffin|muffin.deep13.com|Frank's machine:\ + :cm=CONNECT muffin\n:tc=deep13: + deep13:Gizmonics Institute terminal server:\ + :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234: + +will let you type ``tip pain'' or ``tip muffin'' to connect to the +hosts pain or muffin; and ``tip deep13'' to get to the terminal +server. + +9.15: My university has 42 billion students but only 4 modem lines. + Can tip automatically try each line? + +Sure. Make an entry for your university in /etc/remote and use \@ for +the pn capability: + + big-university:\ + :pn=\@:tc=dialout + dialout:\ + :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: + +Then, list the phone numbers for the university in /etc/phones: + + big-university 5551111 + big-university 5551112 + big-university 5551113 + big-university 5551114 + +tip will try each one in the listed order, then give up. If you want +to keep retrying, run tip in a while loop. + +9.16: How come I have to hit CTRL+P twice to send CTRL+P once? + +CTRL+P is the default ``force'' character, used to tell tip that the +next character is literal data. You can set the force character to +any other character with the ~s escape, which means ``set a +variable.'' + +Type ``~sforce=<single-char>'' followed by a newline. <single-char> +is any single character. If you leave out <single-char>, then the +force character is the nul character, which you can get by typing +CTRL+2 or CTRL+SPACE. A pretty good value for <single-char> is +SHIFT+CTRL+6, which I've seen only used on some terminal servers. + +You can have the force character be whatever you want by specifying +the following in your $HOME/.tiprc file: + + force=<single-char> + +9.17: Suddenly everything I type is all UPPER CASE. What gives? + +You must've pressed CTRL+A, tip's ``raise character,'' specially +designed for people with broken caps-lock keys. Use ~s as above and +set the variable ``raisechar'' to something reasonable. In fact, you +can set it to the same as the force character, if you never expect to +use either of these features. + +Here's a sample .tiprc file perfect for Emacs users who need to type +CTRL+2 and CTRL+A a lot: + + force=^^ + raisechar=^^ + +The ^^ is SHIFT+CTRL+6. + +9.18: How can I do file transfers with tip? + +If you're talking to another UNIX system, you can send and receive +files with ~p (put) and ~t (take). These commands run ``cat'' and +``echo'' on the remote system to accept and send files. The syntax +is: + + ~p <local-file> [<remote-file>] + ~t <remote-file> [<local-file>] + +There's no error checking, so you probably should use another +protocol, like zmodem. + +9.19: Okay, how can I run zmodem with tip? + +To receive files, start the sending program on the remote end. Then, +type ``~C rz'' to begin receiving them locally. + +To send files, start the receiving program on the remote end. Then, +type ``~C sz <files>'' to send them to the remote system. + + + +NOTE: Anyone wishing to submit a FAQ entry on how to get tip and cu working + would have it much appreciated! We all use Kermit over here! :-) + +----------------------------------------------------------------------------- +If you see a problem with this FAQ, or wish to submit an entry, please +mail us at <FreeBSD-FAQ@FreeBSD.ORG>. We appreciate your +feedback, and cannot make this a better FAQ without your help! + + + FreeBSD Core Team + +----------------------------------------------------------------------------- + +ACKNOWLEDGMENTS: + +Ollivier Robert - FreeBSD FAQ maintenance man +Gary Clark II - Ex-FreeBSD FAQ maintenance man +Jordan Hubbard - Janitorial services (I don't do windows) +Garrett Wollman - Networking and formatting +Robert Oliver, Jr. - Ideas and dumb questions (That made me think) +Jim Lowe - Multicast information +The FreeBSD Team - Kvetching, moaning, submitting data + +And to any others we've forgotten, apologies and heartfelt thanks! + diff --git a/share/FAQ/Text/HW.TROUBLE b/share/FAQ/Text/HW.TROUBLE new file mode 100644 index 0000000..86e3e42 --- /dev/null +++ b/share/FAQ/Text/HW.TROUBLE @@ -0,0 +1,58 @@ +$Id: HW.TROUBLE,v 1.3 1995/03/01 06:43:12 phk Exp $ + +This file lists hardware, which doesn't do what it should do. + +Due to the nature of FreeBSD, we do not have the resources to test all +possible kinds of hardware. We do however every now and then find, buy +or hear about hardware which doesn't work with FreeBSD or in general. + +This is that list. + +To be added to this list, a piece of hardware has to: + A: not do what it claims. +or + B: not do what common sense would expect it to. + +Only if performance claims are wildly of the mark will it be listed here. + +All entries must have a date and a mail-address associated with them, to +reflect when and by whom they were added. +For multifunctional devices, please indicate if other parts of the device +work OK, or are untested. +For mutual incompabilities, list both devices. +For SCSI and IDE-devices, list the string seen on boot of FreeBSD, if +possible, and trade name. +Infer format from other entries, Keep sorted by first line. + +Thankyou. + +--- +Controller, Data Technology DTC2280, "PC/AT Super I/O Card" +IDE interface can be set to secondary address, but doesn't work there. Suspect +Interrupt isn't moved along. Works fine on primary address. Other parts of +card not tested. +19940828 phk@freefall.cdrom.com +--- +IDE-disk, <WDC AC2540H>, "Western Digital Caviar 2540" +IDE-disk, <Maxtor 7345 AT>, "Maxtor 7345" +Cannot coexist on the same IDE-controller. +Jumpers not exhaustively experimented with, as neither of the companies +make sufficient information available. Disk works fine when alone on +IDE-controller. +19940828 phk@freefall.cdrom.com +--- +IDE-disk, <AC31000> "Western Digital Caviar 31000" +IDE-disk, <ST3550A> "Seagate ST3550A" +Western Digital AC31000 (Caviar 31000) 1080 meg IDE drive will not +co-exist with a Seagate ST3550A. +The Seagate as master causes a constant drive light and system lockup, +The WD will work fine alone or as master, but the Seagate is inaccessable +if configured as slave in this config. +19950221 jbryant@server.iadfw.net + +On Packard Bell computers with a BIOS Reference ID of less than 25, Packard +Bell will replace the BIOS at no charge. I waited, I got the bios, popped +the case, popped the chip, put in the new, and plugged in the drives. It +works. WD as master, seagate as slave. +19950228 jbryant@server.iadfw.net +--- diff --git a/share/FAQ/Text/MIRROR.SITES b/share/FAQ/Text/MIRROR.SITES new file mode 100644 index 0000000..8c89c8f --- /dev/null +++ b/share/FAQ/Text/MIRROR.SITES @@ -0,0 +1,107 @@ + Mirror Sites + For FreeBSD 2.0 and later + +$Id: MIRROR.SITES,v 1.25 1995/03/12 22:34:05 roberto Exp $ + +The latest versions of FreeBSD (2.0 or later) are being mirrored at the +following locations: + +Country Site and Maintainer +======= ========================================================= +Australia ftp://ftp.physics.usyd.edu.au/FreeBSD + <dawes@xfree86.org> + +Finland ftp://nic.funet.fi/pub/unix/FreeBSD + <ftp@nic.funet.fi> + +France ftp://ftp.ibp.fr/pub/FreeBSD + <Remy.Card@ibp.fr> + +Germany ftp://ftp.fb9dv.uni-duisburg.de/pub/unix/FreeBSD + <ftp@ftp.fb9dv.uni-duisburg.de> + +Hong Kong ftp://ftp.hk.super.net/pub/FreeBSD + <ftp-admin@HK.Super.NET> + +Korea ftp://ftp.cau.ac.kr/pub/FreeBSD + <ftpadm@ftp.cau.ac.kr> + +Netherlands ftp://ftp.nl.net/pub/os/FreeBSD + <archive@nl.net> + +Russia ftp://ftp.kiae.su/FreeBSD + <ftp@ftp.kiae.su> + +Sweden ftp://ftp.luth.se/pub/FreeBSD + <ragge@ludd.luth.se> + +Taiwan ftp://netbsd.csie.nctu.edu.tw/pub/FreeBSD + <ftp@netbsd.csie.nctu.edu.tw> + +Thailand ftp://ftp.nectec.or.th/pub/FreeBSD + <ftpadmin@ftp.nectec.or.th> + +USA ftp://gatekeeper.dec.com/pub/BSD/FreeBSD + <hubbard@gatekeeper.dec.com> + +USA ftp://ftp.cybernetics.net/pub/FreeBSD + <michael@Cybernetics.NET> + +USA ftp://ftp.neosoft.com/systems/FreeBSD + <smace@NeoSoft.COM> + +USA ftp://kryten.atinc.com/pub/FreeBSD + <jmb@kryten.atinc.com> + +USA ftp://ftp.dataplex.net/pub/FreeBSD + <rkw@dataplex.net> + +Japan ftp://tutserver.tutcc.tut.ac.jp/FreeBSD + Ashida Hiroyuki <assie@bpel.tutics.tut.ac.jp> + +Japan ftp://ftp.sra.co.jp/pub/os/FreeBSD + <ftp-admin@sra.co.jp> + +Japan ftp://ftp.ee.uec.ac.jp/pub/os/FreeBSD.other + <ftp-admin@ftp.ee.uec.ac.jp> + +Japan ftp://ftp.mei.co.jp/free/PC-UNIX/FreeBSD + TANIGUCHI Syuuhei <tanig@isl.mei.co.jp> + +Japan ftp://ftp.waseda.ac.jp/pub/FreeBSD + <ftp-admin@waseda.ac.jp> + +Japan ftp://ftp.pu-toyama.ac.jp/pub/FreeBSD + Yoshihiko USUI <usui@pu-toyama.ac.jp> + +Japan ftp://ftpsv1.u-aizu.ac.jp/pub/os/FreeBSD + <ftp-admin@u-aizu.ac.jp> + +UK ftp://src.doc.ic.ac.uk/packages/unix/FreeBSD + <wizards@doc.ic.ac.uk> + +UK ftp://unix.hensa.ac.uk/pub/walnut.creek/FreeBSD + <archive-admin@unix.hensa.ac.uk> + +UK ftp://ftp.demon.co.uk/pub/BSD/FreeBSD + <uploads@demon.net> + +--- + +The latest versions of export-restricted code for FreeBSD (2.0C or later) +(eBones and secure) are being made available at the following locations. + +If you are outside the U.S. or Canada, please get secure (DES) and +eBones (Kerberos) from one of the following foreign distribution sites: + +Country Site and Maintainer +======= ======================================================== +South Africa ftp://skeleton.mikom.csir.co.za/pub/FreeBSD + Mark Murray <mark@grondar.za> + +South Africa ftp://storm.sea.uct.ac.za/pub/FreeBSD + Shaun Courtney <ftp@storm.sea.uct.ac.za> + +Brazil ftp://ftp.iqm.unicamp.br/pub/FreeBSD + Pedro A M Vazquez <vazquez@iqm.unicamp.br> + diff --git a/share/FAQ/Text/README b/share/FAQ/Text/README new file mode 100644 index 0000000..c9d81f9 --- /dev/null +++ b/share/FAQ/Text/README @@ -0,0 +1,75 @@ +Use PageUp, PageDown or Arrow keys to navigate this screen. + + ----------------------------------------- + FreeBSD 2.0 --- RELEASE Version , , + ----------------------------------------- /( )` + \ \___ / | +Welcome to the first public release of FreeBSD 2.0 /- _ `-/ ' +first public snapshot of our new 4.4BSD Lite based (/\/ \ \ /\ +operating system environment. Our installation / / | ` \ +procedure has been completely revamped, and should O O ) / | +now be much easier for both the novice and `-^--'`< ' +experienced user alike. We've also gone to some (_.) _ ) / +care to make the process of installing the `.___/` / +subsequent bindist and other miscellaneous `-----' / +distributions considerably more seamless <----. __ / __ \ +as well as offering a greater variety <----|====O)))==) \) /==== +of installation methods and options. <----' `--' `.__,' \ + | | +We hope you'll find this new process as enjoyable \ / /\ +to use as it was to write! (No, really, it ______( (_ / \______/ +was! :-) ,' ,-----' | + `--{__________) +Disclaimer: Please note that despite numerous +safeguards, it's still more than possible to WIPE OUT YOUR ENTIRE DISK +with this installation! Please do not proceed unless you've +adequately backed up any important data first! We really mean it! + +If any errors occur during this installation, you can see them +by toggling over to the alternate screen. Type ALT-F2 to switch +to the debugging screen and ALT-F1 to switch back to the install screen. +The debugging output on the second screen may be very valuable to us in +understanding your bug report, so please be sure to take note of it when +reporting any failures in the installation! Thanks! + +You may also wish to read the TROUBLESHOOTING document in _advance_ +and perhaps save yourself from making those sorts of errors in +the first place! :-) + +Menus and scrolling output windows may be traversed with the arrow, +PageUp/PageDown and TAB keys. To suspend the installation at any point, +hit ESC twice. If you've ever dealt with a DOS installation before, then +you'll probably know how to deal with this. + +For a more complete description of what's new in this release, please +see the release notes. + +For more documentation on this system, it is recommended that you purchase +the 4.4BSD Document Set from O'Reilly Associates and the USENIX Association. +ISBN 1-56592-082-1 We have no connection with O'Reilly, we're just +satisfied customers! + +Have fun, and please let us know of any problems you encounter with +this release! + +Comments should be sent to: + + hackers@FreeBSD.org + +Bug reports should be sent using the `send-pr' utility, if you +were able to get the system installed, otherwise to: + + bugs@FreeBSD.org + +And general questions to: + + questions@FreeBSD.org + + +Please have patience if your questions are not answered right away - +this is an especially busy time for us, and our volunteer resources +are often strained to the limit (if not somewhat past!). + +Thanks! + + The FreeBSD Project diff --git a/share/FAQ/Text/REGISTER.FreeBSD b/share/FAQ/Text/REGISTER.FreeBSD new file mode 100644 index 0000000..8501628 --- /dev/null +++ b/share/FAQ/Text/REGISTER.FreeBSD @@ -0,0 +1,85 @@ +In the absence of any other mechanism for counting the number of users +of FreeBSD, we like to kindly suggest that you take a few minutes to please +register with the counter set up by <Harald.T.Alvestrand@uninett.no>. + +The justification for such "registration" is twofold: First, we really would +like to know more about the size and demographics of our user-base in order +to better support its needs. Second, it's a sad fact of life that many +people rely on counters and statistics (even when highly dubious) rather +than on actual experience when chosing an operating system, and the best we +can hope to do in such circumstances is to at least try to provide some +indication of how popular we are (or are not). This is not how we recommend +that people go about chosing an operating system, but the necessity of +such "marketing" remains an undeniable fact. + +The FreeBSD team does not necessarily feel that Harald's counter represents +the best approach to such statistics gathering, and its accuracy can only +be as good as people's willingness to register with it (and may not reflect +the actual OS population at any single point in time), but in the total absence +of any other mechanism for providing such useful statistics, it's certainly a +start and we thank Harald for his efforts in providing this service. +It's a community service, and of potential benefit to everyone (all *BSD +users), so let's see if we can't make it work! + +Included below is the standard blurb from the counter. + +Thanks in advance, + + The FreeBSD team. + + +How to get registered +===================== + +In brief: + + [To register a running installation of FreeBSD] + Send E-mail to bsd-counter@uninett.no with the SUBJECT line + + "I use FreeBSD at <place>" + +Introduction +============ +The intention of this counting project is to count all users of UNIXes +that are: + + - BSD-derived + - Freely available + +The variants NetBSD, 386BSD and FreeBSD are currently distinguished. + +(NOTE: Linux is NOT BSD-derived. If you use that, send mail to +linux-counter@uninett.no instead!!!) + +The information is *not* used for any purpose but statistics, and unless +you request it, information about single persons are *never* made public. +(A list of users who have requested publication is available from the +FTP file ftp://aun.uninett.no/pub/misc/386bsd/persons) + +How to register +=============== +Send E-mail to bsd-counter@uninett.no + +The subject should be + + I use FreeBSD|NetBSD|386BSD at <place> + +Where FreeBSD, NetBSD or 386BSD is the particular variant you're using +and "place" can be school, work or home, or a combination of these. + +You will get back a letter with 3 things: + + - An acknowledgement + - A form that you can fill out and send in with more information + about yourself, your machine, and your 386bsd-using friends + - A report giving the current status of the counter + +You can update your "vote" at any time, by sending an E-mail message +from the same account. Duplicates will be weeded out. + +The current report, available by anonymous FTP to aun.uninett.no, +directory pub/misc/386bsd-counter, file "short", is given below. + +For all questions, contact Harald.T.Alvestrand@uninett.no! + +$Id: REGISTER.FreeBSD,v 1.2 1994/12/01 13:24:20 jkh Exp $ diff --git a/share/FAQ/Text/RELNOTES.FreeBSD b/share/FAQ/Text/RELNOTES.FreeBSD new file mode 100644 index 0000000..3b77f60 --- /dev/null +++ b/share/FAQ/Text/RELNOTES.FreeBSD @@ -0,0 +1,624 @@ + RELEASE NOTES + FreeBSD + Release 2.0 + +1. Technical overview +--------------------- + +FreeBSD is a freely available, full source 4.4 BSD Lite based release +for Intel i386/i486/Pentium (or compatible) based PC's. It is based +primarily on software from U.C. Berkeley's CSRG group, with some +enhancements from NetBSD, 386BSD, and the Free Software Foundation. + +Since our first release of FreeBSD 1.0 some 18 months ago, FreeBSD +has changed almost entirely. A new port from the Berkeley 4.4 code +base was done, which brought the legal status of the system out of the +shadows with the blessing of Novell (new owners of USL and UNIX). The +port to 4.4 has also brought in a host of new features, filesystems +and enhanced driver support. With our new unencumbered code base, we +have every reason to hope that we'll be able to release quality +operating systems without further legal encumbrance for some time to +come! + +FreeBSD 2.0 represents the culmination of almost 2 years of work and +many thousands of man hours put in by an international development team. +We hope you enjoy it! + +Many packages have also been upgraded or added, such as XFree86 3.1, +xview 3.2, elm, nntp, mh, InterViews and dozens of other miscellaneous +utilities have been ported and are now available as add-ons. See the +ports collection (or the package collection) for a complete summary. + +For a list of contributors and a general project description, please see +the file "CONTRIB.FreeBSD" which should be bundled with your binary +distribution. + +Also see the "REGISTER.FreeBSD" file for information on registering +with the "Free BSD user counter". This counter is for ALL freely +available variants of BSD, not just FreeBSD, and we urge you to register +yourself with it. + +The core of FreeBSD does not contain DES code which would inhibit its +being exported outside the United States. There is an add-on package +to the core distribution, for use only in the United States, that +contains the programs that normally use DES. The auxilliary packages +provided separately can be used by anyone. A freely (from outside the +U.S.) exportable European distribution of DES for our non U.S. users also +exists and is described in the FreeBSD FAQ. + +If password security for FreeBSD is all you need, and you have no +requirement for copying encrypted passwords from different hosts (Suns, +DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 +based security may be all you require! We feel that our default security +model is more than a match for DES, and without any messy export issues +to deal with. If you're outside (or even inside) the U.S., give it a try! + + +1.1 What's new in 2.0? +---------------------- + +4.4 Lite +-------- +As previously stated, this release is based entirely on CSRG's +latest (and last) BSD release - 4.4 Lite. This features a number +of improvements over 4.2BSD (Net/2), not least of which are: + +o Legal approval of Novell & U.C. Berkeley. After the settlement + of the longstanding lawsuit between USL/UCB/Novell/BSDI, all + parties were (strongly) encouraged to move to 4.4 Lite in order + to avoid future legal entanglements. The fact that we've now done + so should make this release much more attractive to potential + commercial users. + +o Many new filesystem types, such as stackable filesystems, union + filesystems, "portals", kernfs, a simple log-structured filesystem, a + new version of NFS (NQNFS), etc. While some of these new filesystems + are also rather unpolished and will require significant additional + work to be truly robust, they're a good start. + +o 64bit offsets, allowing filesystems of up to 2^63 bytes in size. + +o Further work towards full POSIX compliance. + +IP multicast support +-------------------- +The IP multicast support has been upgraded from the woefully ancient +1.x code in 4.4-Lite to the most current and up-to-date 3.3 release +from Steve D. and Ajit. The non-forwarding code is known to work (for +some limited test cases). The multicast forwarder and user-mode +multicast routing process are known to compile, but have not been +significantly tested (hopefully this will happen before 2.0 release). + +Owner: wollman +Sources involved: sys/netinet, usr.sbin/mrouted + +Loadable Kernel Modules +----------------------- +David Greenman incorporated NetBSD's port of Terry Lambert's loadable +kernel module support. Garrett Wollman wrote the support for loadable +file systems, and Søren Schmidt did the same for loadable execution +classes. + +Owner: core +Sources involved: sys/kern, sbin/modload, sbin/modunload, + usr.bin/modstat + + +Loadable filesystems +-------------------- +Most filesystems are now dynamically loadable on demand, with the +exception of the UFS family (FFS, LFS, and MFS). With the exception +of NFS, all such filesystems can be unloaded when all references are +unmounted. To support this functionality, the getvfsbyname(3) +family of functions has been added to the C library and the lsvfs(1) +command provides the same information at the shell level. Be aware of +the following current restrictions: + + - /usr/bin may not reside on a dynamically loaded filesystem. + - There must be a writable /tmp directory available + before filesystems are loaded (moving / to the top of your + /etc/fstab file will accomplish this). + - Some of the more esoteric filesystems simply don't work when loaded + dynamically (though they often don't work "static", either.) + +Owner: wollman +Sources involved: sys/*fs, lkm/*fs, usr.bin/lsvfs, lib/libc/gen + + +S/Key +----- +Since version 1.1.5, FreeBSD has supported the S/Key one time password +scheme. The version used is derived from the logdaemon package of Wietse +Venema. +Some of the features new in 2.0 are: + - New access control table format to impose the use of S/Keys + based on: hostname, ip address, port, username, group id. + - S/Key support can be disabled by not having the access control + table. +The second item explains the absence of skey.access in the installed /etc. +To enable S/Key support, create a file skey.access in /etc and fill it +according to your needs. See also skey.access(5) and the example in +/usr/share/examples/etc/skey.access. + +Owner: pst, guido +Sources involved: lib/libskey, usr.bin/key* (plus patches to others) + + +TCP/IP over parallel (printer) port +----------------------------------- +You can now run TCP/IP over a standard LapLink(tm) cable, if both ends +have an interrupt-driven printerport. The interface is named "lp0" +where '0' is the same as the lpt# unit number. This is not compatible +with PLIP. If you run NFS, try setting MTU to 9180, otherwise leave +it at 1500 unless you have a good reason to change it. Speed varies +with the CPU-type, with up to 70 kbyte/sec having been seen and 50 +kbyte/sec being the norm. + +Owner: phk +Sources involved: isa/lpt.c + + +ProAudioSpectrum SCSI driver +---------------------------- +If you have a PAS board with a CD-ROM, and the MS-DOS driver is called +TSLCDR.SYS, then the "pas" driver should work on your card. You can +attach disks, cdroms and tapes, but due to the nature of the hardware +involved, the transfer rate is limited to < 690 kbyte/sec. For CD-ROM +use, this is generally more than enough. + +Owner: phk +Sources involved: isa/pas.c + + +Adaptec 2742/2842 SCSI driver +----------------------------- +Despite the non-cooperation of Adaptec in providing technical +information, we now have a driver for the AHA-274x and AHA-284x +series SCSI controller family. This driver uses the GPL'd +Linux sequencer code, so until we find an alternative, this +will be part of the kernel that requires source code to be +distributed with it at all times. This shouldn't be a problem +for any of FreeBSD's current users. + +Owner: gibbs +Sources involved: isa/aic7770.c sys/gnu/misc/* + + +Gzip'd binaries +---------------- +We have an experimental implementation for direct execution of gzip'ed +binaries in this release. When enabled, it allows you to simply gzip +your binaries, remove the '.gz' extension and make the file +executable. There is a big speed and memory consumption penalty for +doing this, but for laptop users it may be worthwhile. The maximum +savings are generally around 10 Mb of disk space. + +Owner: phk +Sources involved: kern/imgact_gzip.c kern/inflate.c + + +Diskless booting +---------------- + +Diskless booting in 2.0 is much improved since 1.1.5. The +boot-program is in src/sys/i386/boot/netboot, and can be run from an +MSDOS system or burned into an EPROM. Local swapping is also +possible. WD, SMC, 3COM and Novell ethernet cards are currently +supported. + +Owner: Martin Renters & phk +Sources involved: i386/boot/netboot, sys/nfs/nfs_vfsops.h + + +Device configuration database +----------------------------- +The kernel now keeps better track of which device drivers are active and +where the devices are attached; this information is made available to +user programs via the new sysctl(3) management interface. Current +applications include lsdev(8), which lists the currently configured +devices. In the future, we expect to use this code to automatically +generate a configuration file for you at installation time. + +Owner: wollman +Sources involved: sys/i386, sys/scsi, sys/kern/kern_devconf.c, + sys/sys/devconf.h, usr.sbin/lsdev + + +Kernel management interface +--------------------------- +With 4.4-Lite, we now have a better management interface for the endless +series of kernel variables and parameters which were previously manipulated +by reading and writing /dev/kmem. Many programs have been rewritten to +use this interface, although many old-style programs still remain. Some +variables which were never accessible before are now available through +the sysctl(1) program. In addition to the standard 4.4BSD MIB variables, +we have added support for YP/NIS domains (kern.domainname), controlling +the update daemon (kern.update), retrieving the OS release date +(kern.osreldate), determining the name of the booted kernel (kern.bootfile), +and checking for hardware floating-point support (hw.floatingpoint). +We have also added support to make management queries of devices and +filesystems. + +Owner: core +Sources involved: sys, usr.bin/sysctl + + +iBCS2 support +------------- +FreeBSD now supports running iBCS2 compatible binaries (currently +SCO UNIX 3.2.2 & 3.2.4 and ISC 2.2 COFF format are supported). +The iBCS2 emulator is in its early stages, but it is functional, we +haven't been able to do exhaustive testing (lack of commercial apps), +but almost all of SCO's 3.2.2 binaries are working, so is an old +INFORMIX-2.10 for SCO. Further testing is nessesary to complete this +project. There is also work under way for ELF & XOUT loaders, and +most of the svr4 syscall wrappers have been written. + +Owner: Soren Schmidt (sos) & Sean Eric Fagan (sef) +Sources involved: sys/i386/ibcs2/* + misc kernel changes. + + +2. Supported Configurations +--------------------------- + +FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus +based PC's, ranging from 386sx to Pentium class machines (though the +386sx is not recommended). Support for generic IDE or ESDI drive +configurations, various SCSI controller, network and serial cards is +also provided. + +Following is a list of all currently known disk controllers and +ethernet cards known to work with FreeBSD. Other configurations may +very well work, and we have simply not received any indication of +this. + + +2.1. Disk Controllers + +WD1003 (any generic MFM/RLL) +WD1007 (any generic IDE/ESDI) +[Note: the new Extended IDE controllers in newer PC's work, although no +extended features are used.] + +Adaptec 152x series ISA SCSI controllers +Adaptec 154x series ISA SCSI controllers +Adaptec 174x series EISA SCSI controller in standard and enhanced mode. +Adaptec 2742/2842 series ISA/EISA SCSI controllers +Adaptec AIC-6260 and AIC-6360 based boards, which includes +the AHA-152x and SoundBlaster SCSI cards. + +** Note: You cannot boot from the Soundblaster cards +as they have no on-board BIOS, which is necessary for mapping +the boot device into the system BIOS I/O vectors. +They're perfectly usable for external tapes, CDROMs, etc, +however. The same goes for any other AIC-6x60 based card +without a boot ROM. Some systems DO have a boot ROM, which +is generally indicated by some sort of message when the system +is first powered up or reset. Check your system/board documentation +for more details. + +[Note that Buslogic was formerly known as "Bustec"] +Buslogic 545S & 545c +Buslogic 445S/445c VLB SCSI controller +Buslogic 742A, 747S, 747c EISA SCSI controller. +Buslogic 946c PCI SCSI controller + +NCR 53C810 and 53C825 PCI SCSI controller. + +DTC 3290 EISA SCSI controller in 1542 emulation mode. + +UltraStor 14F, 24F and 34F SCSI controllers. + +Seagate ST01/02 SCSI controllers. + +Future Domain 8xx/950 series SCSI controllers. + +With all supported SCSI controllers, full support is provided for +SCSI-I & SCSI-II peripherals, including Disks, tape drives (including +DAT) and CD ROM drives. Note: This and the mcd driver (Mitsumi CDROM +interface card) are the only way a CD ROM drive may be currently +attached to a FreeBSD system; we do not support SoundBlaster +(non-SCSI) CDROM interface, or other "non-SCSI" adapters. The +ProAudio Spectrum SCSI and SoundBlaster SCSI controllers are +supported. + +Some controllers have limitations with the way they deal with >16MB of +memory, due to the fact that the ISA bus only has a DMA address space of +24 bits. If you do your arithmetic, you'll see that this makes it +impossible to do direct DMA to any address >16MB. This limitation is +even true of some EISA controllers (which are normally 32 bit) when +they're configured to emulate an ISA card, which they then do in *all* +respects. This problem is avoided entirely by IDE controllers (which do +not use DMA), true EISA controllers (like the UltraStor or Adaptec +1742A) and most VLB (local bus) controllers. In the cases where it's +necessary, the system will use "bounce buffers" to talk to the +controller so that you can still use more than 16Mb of memory without +difficulty. + + +2.2. Ethernet cards + +SMC Elite 16 WD8013 ethernet interface, and most other WD8003E, +WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT +based clones. SMC Elite Ultra is also supported. + +DEC EtherWORKS III NICs (DE203, DE204, and DE205) +DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) + +Isolan AT 4141-0 (16 bit) +Isolink 4110 (8 bit) + +Novell NE1000, NE2000, and NE2100 ethernet interface. + +3Com 3C501 cards + +3Com 3C503 Etherlink II + +3Com 3C507 Etherlink 16/TP + +3Com 3C509 and 3C579 Etherlink III + +Toshiba ethernet cards + +PCMCIA ethernet cards from IBM and National Semiconductor are also +supported. + +2.3. Misc + +AST 4 port serial card using shared IRQ. + +ARNET 8 port serial card using shared IRQ. + +BOCA ATIO66 6 port serial card using shared IRQ. + +STB 4 port card using shared IRQ. + +Mitsumi (all models) CDROM interface and drive. + +Soundblaster SCSI and ProAudio Spectrum SCSI CDROM interface and drive. + +Adlib, Soundblaster, Soundblaster Pro, ProAudioSpectrum, Gravis UltraSound +and Roland MPU-401 sound cards. + +FreeBSD currently does NOT support IBM's microchannel (MCA) bus, but +support is apparently close to materializing. Details will be posted +as the situation develops. + + +3. Obtaining FreeBSD. +--------------------- + +You may obtain FreeBSD in a variety of ways: + +1. FTP/Mail + +You can ftp FreeBSD and any or all of its optional packages from +`freebsd.cdrom.com' - the offical FreeBSD release site. + +For other locations that mirror the FreeBSD software see the file +MIRROR.SITES. Please ftp the distribution from the nearest site +to you netwise. + +If you do not have access to the internet and electronic mail is your +only recourse, then you may still fetch the files by sending mail to +`ftpmail@decwrl.dec.com' - putting the keyword "help" in your message +to get more information on how to fetch files from freebsd.cdrom.com. +Note: This approach will end up sending many *tens of megabytes* +through the mail, and should only be employed as an absolute LAST +resort! + + +2. CDROM + +FreeBSD 2.0 may be ordered on CDROM from: + + Walnut Creek CDROM + 4041 Pike Lane, Suite D + Concord CA 94520 + 1-800-786-9907, +1-510-674-0783, +1-510-674-0821 (fax) + +Or via the internet from orders@cdrom.com. Their current catalog can +be obtained via ftp as ftp.cdrom.com:/cdrom/catalog. + +Cost is $39.95. Shipping (per order not per disc) is $5 in the US, Canada, +or Mexico and $10.00 overseas. They accept Visa, Mastercard, American +Express, and ship COD to the United States. California residents please +add 8.25% sales tax. + +Should you be dissatisfied for any reason, the CD comes with an +unconditional return policy. + +Note that Walnut Creek CDROM does NOT provide technical support for FreeBSD, +you need to contact the FreeBSD team for that. Please see section 5 for +more information. + + +4. Preparing for the installation. +---------------------------------- + +1. Floppy Installation + +If you must install from floppy disks, either due to space contraints +on your hard disk or just because you enjoy doing things the hard +way, you must first prepare some floppies for the install. + +You will need either 10 1.44MB floppies or 12 1.2MB floppies to +store just the bindist (binary distribution). These *must* be +formatted using MS-DOS, using either the FORMAT command in MS-DOS +or the File Manager in Microsoft Windows to prepare the floppies +(though factory preformatted floppies will also well well, provided +that they haven't been previously used for something else). + +After you've formatted the floppy disks, you'll need to copy the +files onto them. There are 56 total files for the bindist itself, +plus three small files (CKSUMS, do_cksum.sh, and extract.sh) for +the install program to use. ALL of these files must be copies onto +the floppies. Each of the bindist files are named "bindist.??", +where the "??" is replaced by the letter sequence aa through cd. +Copy these files onto the floppies, placing the three small install +files onto the final floppy. The order in which you copy the files +to floppy is not important, but it makes labelling the disks easier +if you go in some sort of alphabetical order. + +After you've done this, the floppy disks are ready for the install +program to use. + +Later on, after you get the binary distribution installed and everything +is going great, the same instructions will apply for the other +distributions, such as the manpages distribution or the XFree86 distribution. +The number of floppies required will, of course, change for bigger or +smaller distributions. + + +2. Hard Disk Installation + +To prepare for installation from an MS-DOS partition, you should simply +copy the files from the distribution into a directory with the same +name as the distribution. For example, if you are preparing to +install the bindist set, then make a directory on your C: drive named +C:\BINDIST and copy the files there. This will allow the installation +program to find the files automatically. + + +3. QIC/SCSI Tape Installation. + +Installing from tape is probably the easiest method, short of an +on-line install using ftp or installing from a CDROM. The installation +program expects the files to be simply tar'red onto the tape, so after +getting all of the files for distribution you're interested in, simply +tar them onto the tape with something like: + + cd <where the *.?? files are> + tar cvf /dev/rwt0 (or /dev/rst0) . + +from a directory with just the distribution files in it. Make sure +that you remember to put CKSUMS, do_cksum.sh, and extract.sh files +in this directory as well! + +If you wish to install multiple *dist releases from one tape, do the +following: + +1. cd to the parent directory of the distributions and put them on tape + like so: + tar cvf /dev/rwt0 (or /dev/rst0) bindist srcdist ... + +2. Install the first distribution on the tape using the tape installation + method as normal. Afterwards, *do not* erase the contents of the temporary + directory. Get a shell with ESC-ESC and cd to the temporary directory + yourself. For each additional *dist you want to load, cd to its + subdirectory and type `sh ./extract.sh'. + + +5. Reporting problems, making suggestions, submitting code. +----------------------------------------------------------- + +Your suggestions, bug reports and contributions of code are always +valued - please do not hesitate to report any problems you may find +(preferably with a fix attached if you can!). + +The preferred method to submit bug reports from a machine with internet +mail connectivity is to use the send-pr command. Bug reports will be +dutifully filed by our faithful bugfiler program and you can be sure +that we'll do our best to respond to all reported bugs as soon as +possible. + +If, for some reason, you are unable to use the send-pr command to +submit a bug report, you can try to send it to: + + bugs@FreeBSD.org + + +Otherwise, for any questions or suggestions, please send mail to: + + questions@FreeBSD.org + +Additionally, being a volunteer effort, we are always happy to have +extra hands willing to help - there are already far more enhancements +to be done than we can ever manage to do by ourselves! To contact us +on technical matters, or with offers of help, you may send mail to: + + hackers@FreeBSD.org + +Since these mailing lists can experience significant amounts of +traffic, if you've got slow or expensive mail access and you're +only interested in keeping up with significant FreeBSD events, you may +find it preferable to subscribe to: + + announce@FreeBSD.org + + +All but the FreeBSD-bugs groups can be freely joined by anyone wishing +to do so. Send mail to MajorDomo@FreeBSD.org and include the keyword +`help' on a line by itself somewhere in the body of the message. This +will give you more information on joining the various lists, accessing +archives, etc. There are a number of mailing lists targeted at +special interest groups not mentioned here, so send mail to majordomo +and ask about them! + + +6. Acknowledgements +------------------- + +FreeBSD represents the cumulative work of many dozens, if not +hundreds, of individuals from around the world who have worked very +hard to bring you this release. It would be very difficult, if not +impossible, to enumerate everyone who's contributed to FreeBSD, but +nonetheless we shall try (in alphabetical order, of course). If your +name is not mentioned, please be assured that its omission is entirely +accidental. + + +The Computer Systems Research Group (CSRG), U.C. Berkeley. + +Bill Jolitz, for his extensive work with 386BSD. + +The FreeBSD "core" team: + + Andrey A. Chernov + John Dyson + Bruce Evans + David Greenman + Rodney W. Grimes + Jordan K. Hubbard + Poul-Henning Kamp + Rich Murphey + Gary Palmer + Geoff Rehmet + Paul Richards + Soren Schmidt + Andreas Schulz + Jack Vogel + Garrett A. Wollman + + +Special mention to: + + Robert Bruce and Jack Velte of Walnut Creek CDROM, without + whose help (and continuing support) this release would never + have been possible. + + Dermot McDonnell for his donation of a Toshiba XM3401B CDROM + drive. + + The NetBSD group for their frequent assistance and commentary. + + Additional FreeBSD helpers and beta testers: + + J.T. Conklin Julian Elischer + Sean Eric Fagan Jeffrey Hsu + Terry Lambert L Jonas Olsson + Chris Provenzano Dave Rivers + Guido van Rooij Steven Wallace + Atsushi Murai Scott Mace + Andrew Moore Nate Williams + + And everyone at Montana State University for their initial support. + + +Thanks to everyone, especially those not mentioned, and we sincerely +hope you enjoy this release of FreeBSD! + + + The FreeBSD Core Team + +$Id: RELNOTES.FreeBSD,v 1.23 1995/03/21 00:37:07 ache Exp $ diff --git a/share/FAQ/Text/ROADMAP b/share/FAQ/Text/ROADMAP new file mode 100644 index 0000000..bf326c0 --- /dev/null +++ b/share/FAQ/Text/ROADMAP @@ -0,0 +1,55 @@ +This directory contains frequently asked questions, short user guides, +tutorials and other miscellaneous information that may be of help +to the beginning (or even advanced) FreeBSD user. Any submissions +to this directory should be sent to: + + FreeBSD-FAQ@FreeBSD.ORG + +For inclusion with the next release. Your contributions are not only +welcome, but often save new users from uncountable headaches! If you've +written something you think may help new users, please - by all means +send it to us! + +Thanks! + + The FreeBSD Project + +---- +ROADMAP: + +File Description +=============================================================================== +FreeBSD.FAQ The overall FreeBSD FAQ - posted regularly to + USENET. + +FreeBSD-1.1.FAQ FreeBSD FAQ for versions 1.1.5.1 and below. + +HW.TROUBLE User feedback on finicky or broken hardware. + +MIRROR.SITES A list of all sites mirroring FreeBSD 2.x. + +NFS.FAQ Tips for users using NFS between FreeBSD + and workstation hardware. + +Systems.FAQ Systems and configurations on which FreeBSD + is "known" to work. + +Systems-1.1.FAQ Systems for 1.1.5.1 and below + +current-policy.FAQ What you should know about running + FreeBSD-current. + +kernel-debug.FAQ How to debug kernels for 1.1.5.1 and below. + +mailing-list.FAQ All about the FreeBSD mailing lists. + +ports-supfile A sample supfile for the FreeBSD ports + collection. + +slip-dialup How to configure SLIP. + +standard-supfile A sample supfile for the FreeBSD source tree. + +sup.FAQ All about sup in general. + + diff --git a/share/FAQ/Text/TROUBLESHOOTING b/share/FAQ/Text/TROUBLESHOOTING new file mode 100644 index 0000000..d1cb25f --- /dev/null +++ b/share/FAQ/Text/TROUBLESHOOTING @@ -0,0 +1,185 @@ +Troubleshooting Tips - or "These are the times that try men's souls" +-------------------------------------------------------------------- + +The following tips and tricks may help you turn a failing (or failed) +installation attempt into a success. Please read them carefully. + +--- + +Symptom: Hardware conflict or misconfiguration. + Device not being found when it should be. + +Problem: A device is conflicting with another, or its settings + don't match the kernel's expected IRQ or address. + +Explanation: While most device drivers in FreeBSD are now smart + enough to match themselves to your hardware settings + dynamically, there are a few that still require fairly + rigid configuration parameters to be compiled in (and + matched by the hardware) before they'll work. We're + working hard to eliminate as many of these last + hold-outs as we can, but it's not always as easy as + it looks. + +Solution: There are several possible solutions. The first, + and easiest, is to boot the kernel with the -c flag. + When you see the initial boot prompt (from floppy or + hard disk), type: + + /kernel -c + + This will boot just past the memory sizing code and + then drop into a dynamic kernel configuration utility. + Type `?' at the prompt to see a list of commands. You + can use this utility to reset the IRQ, memory address, + IO address or a number of other device configuration + parameters. You can also disable a device entirely + if it's causing problems for other devices you'd much + rather have work. Note that this only affects the + kernel being booted temporarily, it does not "write out" + the information to the kernel so that these settings + are permanantly altered (this would be actually rather + hard). If you reboot, you'll have to make the same + changes again. The goal of the -c utility is to get + you up far enough to be able to download the appropriate + sources and configure and rebuild a kernel more specific + to your needs. + + Another solution is, obviously, to remove the offending + hardware or simply strip the system down to the bare + essentials until the problem (hopefully) goes away. + Once you're up, you can do the same thing mentioned + above - compile a kernel more suited to your hardware, + or incrementally try to figure out what it was about + your original hardware configuration that didn't work. + +--- +Symptom: My floppy-tape drive isn't probed. + +Problem: Last-minute problems with this driver caused it to be disabled + by default. + +Solution: Boot with -c (described above) and set the flags value of + fdc0 to 1. This will re-enable the floppy tape driver. + Sorry, but it was causing problems for people without floppy + tape drives! +--- + +Symptom: When I boot for the first time, it still looks for /386bsd! + +Problem: You still have the old FreeBSD 1.x boot blocks on your + boot partition. + +Solution: You should re-enter the installation process, invoke + the (F)disk editor and chose the (W)rite option. This + won't hurt an existing installation and will make sure + that the new boot blocks get written to the drive. + If you're installing for the first time, don't forget + to (W)rite out your new boot blocks! :-) + +--- + +Symptom: I want to boot FreeBSD off the second drive. It doesn't! + +Problem: FreeBSD will actually install just fine on a drive other + than 0 (the first drive), and the boot manager will even + allow you to select it, but the boot blocks rather + pathologically assume 0. This should be fixed in 2.1. + +Solution: Easy - follow these steps: + + 1. Select the first (0) drive from the (F)disk editor + and write out the boot manager with the (B) option. + This will enable the boot manager that allows you to + actually boot off the other drive. + + 2. Exit the fdisk editor for the first drive and and + re-enter it again for the drive you wish to install + on. Set up a partition on this drive, or select + (A)ll for the entire drive. + + 3. Enter the disklabel editor and allocate space on + your second drive as normal. Proceed with the + installation. + + 4. Once you've installed on the disk and are going to + reboot from the hard disk, enter the following at + the boot prompt: + + wd(1,a)/kernel + + [ If you're using a SCSI drive, substitute + `sd' for `wd' above ] + + This will ensure that you really boot from the second + drive. If you've actually installed on a drive other + than 1 (the 3rd or 4th drive?), substitute that number + in for the above. You will need to enter this EVERY + time you reboot from the hard disk. If you're feeling + brave and have a srcdist + the requisite experience, + you can hack the boot blocks in: + + /usr/src/sys/i386/boot/biosboot + + So that this drive you're booting from is hard-coded. + Recompile the boot blocks and reinstall them on your + drive with `disklabel -B ...' You can then have the + default Do The Right Thing. +--- + +Symptom: Newfs crashes, requesting that blocksize be 32K + +Problem: You have your disk controller configured to translate + to a some really large cylinder size because you're using + a drive with lots of cylinders. + +Solution: Turn such translation OFF in your controller's BIOS + setup if you can. If you must share the disk with other + Operating Systems, then this may not be possible and + you may simply be unable to install FreeBSD until we have + support for large translated geometries, sorry! + [ Hopefully in 2.1 ]. + +--- + +Symptom: FreeBSD won't boot off the hard disk + +Problem: Root partition does not start and end below cylinder 1024. + +Solution: See solution for newfs crashes, or move your root + partition. This limitation holds true for ANY operating + system you wish to boot from your hard drive. + +--- + +Symptom: FreeBSD still won't boot off the hard disk + +Problem: No boot code is installed in sector 1. + +Solution: Chose the Write MBR (B)oot code in the FDISK editor and + write out the boot manager so that you have a chance to + select operating systems. + + [ ** NOTE: If you are using the entire disk for FreeBSD, or + you have a Connor drive that does cylinder translation + from the MBR boot code, do NOT chose this option! ** ]. + +--- +Summary: Nope, FreeBSD's still not booting from the hard disk. + +Cause: BIOS disk geometry different from that used when + installing FreeBSD. + +Solution: With IDE drives, pay careful attention to the geometry + information that FreeBSD prints out when it's first + booting off the floppy. Use this geometry in your BIOS + setup or use the BIOS geometry when you install FreeBSD. + Either way, they have to match. + + With SCSI drives, the values they report is most often + bogus and cannot be used. In this situation, the SCSI + controller is performing geometry translation and + it's probably wise to assume a default of 64 heads, + 32 sectors and 1MB/cylinder. Use these values when + you install FreeBSD. See above comments concerning + newfs failures for more info. diff --git a/share/FAQ/Text/UUCP_Internals.FAQ b/share/FAQ/Text/UUCP_Internals.FAQ new file mode 100644 index 0000000..5a0702b --- /dev/null +++ b/share/FAQ/Text/UUCP_Internals.FAQ @@ -0,0 +1,1603 @@ +Path: bloom-beacon.mit.edu!cambridge-news.cygnus.com!comton.airs.com!ian +From: ian@airs.com (Ian Lance Taylor) +Newsgroups: comp.mail.uucp,comp.answers,news.answers +Subject: UUCP Internals Frequently Asked Questions +Keywords: UUCP, protocol, FAQ +Message-ID: <uucp-internals_787915801@airs.com> +Date: 20 Dec 94 09:30:02 GMT +Expires: 31 Jan 95 09:30:01 GMT +Reply-To: ian@airs.com (Ian Lance Taylor) +Followup-To: comp.mail.uucp +Organization: Infinity Development, Waltham, MA +Lines: 1587 +Approved: news-answers-request@MIT.Edu +Supersedes: <uucp-internals_785496601@airs.com> +Xref: bloom-beacon.mit.edu comp.mail.uucp:5270 comp.answers:9043 news.answers:31575 + +Archive-name: uucp-internals +Version: $Revision: 1.1 $ +Last-modified: $Date: 1995/01/04 01:53:38 $ + + This article was written by Ian Lance Taylor <ian@airs.com> and I may + even update it periodically. Please send me mail about suggestions + or inaccuracies. + + This article describes how the various UUCP protocols work, and + discusses some other internal UUCP issues. It does not describe how + to configure UUCP, nor how to solve UUCP connection problems, nor how + to deal with UUCP mail. I do not know of any FAQ postings on these + topics. There are some documents on the net describing UUCP + configuration, but I can not keep an up to date list here; try using + archie. + + If you haven't read the news.announce.newusers articles, read them. + + This article is in digest format. Some newsreaders will be able to + break it apart into separate articles. Please don't ask me how to do + this, though. + + This article answers the following questions. If one of these + questions is posted to comp.mail.uucp, please send mail to the poster + referring her or him to this FAQ. There is no reason to post a + followup, as most of us know the answer already. + +Sources +What does "alarm" mean in debugging output? +What are UUCP grades? +What is the format of a UUCP lock file? +What is the format of a UUCP X.* file? +What is the UUCP protocol? +What is the 'g' protocol? +What is the 'f' protocol? +What is the 't' protocol? +What is the 'e' protocol? +What is the 'G' protocol? +What is the 'i' protocol? +What is the 'j' protocol? +What is the 'x' protocol? +What is the 'y' protocol? +What is the 'd' protocol? +What is the 'h' protocol? +What is the 'v' protocol? +Thanks + +---------------------------------------------------------------------- + +From: Sources +Subject: Sources + +"Unix-to-Unix Copy Program," said PDP-1. "You will never find a more +wretched hive of bugs and flamers. We must be cautious." + --DECWars + +I took a lot of the information from Jamie E. Hanrahan's paper in the +Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim +O'Reilly and Grace Todino (with contributions by several other +people). The latter includes most of the former, and is published by + O'Reilly & Associates, Inc. + 103 Morris Street, Suite A + Sebastopol, CA 95472 +It is currently in its tenth edition. The ISBN number is +0-937175-93-5. + +Some information is originally due to a Usenet article by Chuck +Wegrzyn. The information on execution files comes partially from +Peter Honeyman. The information on the 'g' protocol comes partially +from a paper by G.L. Chesson of Bell Laboratories, partially from +Jamie E. Hanrahan's paper, and partially from source code by John +Gilmore. The information on the 'f' protocol comes from the source +code by Piet Berteema. The information on the 't' protocol comes from +the source code by Rick Adams. The information on the 'e' protocol +comes from a Usenet article by Matthias Urlichs. The information on +the 'd' protocol comes from Jonathan Clark, who also supplied +information about QFT. The FSUUCP information comes straight from +Christopher J. Ambler; it applies to version 1.4 and up. + +Although there are few books about UUCP, there are many about networks +and protocols in general. I recommend two non-technical books which +describe the sorts of things that are available on the network: ``The +Whole Internet,'' by Ed Krol, and ``Zen and the Art of the Internet,'' +by Brendan P. Kehoe. Good technical discussions of networking issues +can be found in ``Internetworking with TCP/IP,'' by Douglas E. Comer +and David L. Stevens and in ``Design and Validation of Computer +Protocols'' by Gerard J. Holzmann. + +------------------------------ + +From: alarm +Subject: What does "alarm" mean in debugging output? + +The debugging output of many versions of UUCP (but not Taylor UUCP) +will include messages like + alarm 1 +or + pkcget: alarm 1 + +This message means that the UUCP package has timed out while waiting +for some sort of response from the remote system. This normally +indicates some sort of connection problem. For example, the modems +might have lost their connection, or perhaps one of the modems will +not transmit the XON and XOFF characters, or perhaps one side or the +other is dropping characters. It can also mean that the packages +disagree about some aspect of the UUCP protocol, although this is less +common. + +Using the information in the rest of this posting, you should be able +to figure out what type of data your UUCP was expecting to receive. +This may give some indication as to exactly what the problem is. It +is difficult to be more specific, since there are many possiblities. + +------------------------------ + +From: UUCP-grades +Subject: What are UUCP grades? + +Modern UUCP packages support grades for each command. The grades +generally range from 'A' (the highest) to 'Z' followed by 'a' to 'z'. +Some UUCP packages also support '0' to '9' before 'A'. Some UUCP +packages may permit any ASCII character as a grade. + +On Unix, these grades are encoded in the name of the command file. A +command file name generally has the form + C.nnnngssss +where nnnn is the remote system name for which the command is queued, +g is a single character grade, and ssss is a four character sequence +number. For example, a command file created for the system ``airs'' +at grade 'Z' might be named + C.airsZ2551 + +The remote system name will be truncated to seven characters, to +ensure that the command file name will fit in the 14 character file +name limit of the traditional Unix file system. UUCP packages which +have no other means of distinguishing which command files are intended +for which systems thus require all systems they connect to to have +names that are unique in the first seven characters. Some UUCP +packages use a variant of this format which truncates the system name +to six characters. HDB and Taylor UUCP use a different spool +directory format, which allows up to fourteen characters to be used +for each system name. + +The sequence number in the command file name may be a decimal integer, +or it may be a hexadecimal integer, or it may contain any alphanumeric +character. Different UUCP packages are different. + +FSUUCP (a DOS based UUCP and news package) uses up to 8 characters for +file names in the spool (this is a DOS file name limitation; actually, +with the extension, 11 characters are available, but FSUUCP reserves +that for future use). FSUUCP defaults mail to grade D, and news to +grade N, except that when the grade of incoming mail can be +determined, that grade is preserved if the mail is forwarded to +another system. Mail and news are currently the only 2 types of +transfers supported. The default grades may be changed by editing +the MAIL.RC file for mail, or the FSUUCP.CFG file for news. + +UUPC/extended for DOS, OS/2 and Windows NT handles mail at grade 'C', +news at grade 'd', and file transfers at grade 'n'. The UUPC/extended +UUCP and RMAIL commands accept grades to override the default, the +others do not. + +I do not know how command grades are handled in other non-Unix UUCP +packages. + +Modern UUCP packages allow you to restrict file transfer by grade +depending on the time of day. Typically this is done with a line in +the Systems (or L.sys) file like this: + airs Any/Z,Any2305-0855 ... +This allows grades 'Z' and above to be transferred at any time. Lower +grades may only be transferred at night. I believe that this grade +restriction applies to local commands as well as to remote commands, +but I am not sure. It may only apply if the UUCP package places the +call, not if it is called by the remote system. + +Taylor UUCP can use the ``timegrade'' and ``call-timegrade'' commands +to achieve the same effect (and supports the above format when reading +Systems or L.sys). + +UUPC/extended provides the symmetricgrades option to announce the +current grade in effect when calling the remote system. + +This sort of grade restriction is most useful if you know what grades +are being used at the remote site. The default grades used depend on +the UUCP package. Generally uucp and uux have different defaults. A +particular grade can be specified with the -g option to uucp or uux. +For example, to request execution of rnews on airs with grade 'd', you +might use something like + uux -gd - airs!rnews <article + +Uunet queues up mail at grade 'C', but increases the grade based on +the size. News is queued at grade 'd', and file transfers at grade +'n'. The example above would allow mail (below some large size) to be +received at any time, but would only permit news to be transferred at +night. + +------------------------------ + +From: UUCP-lock-file +Subject: What is the format of a UUCP lock file? + +This discussion applies only to Unix. I have no idea how UUCP locks +ports on other systems. + +UUCP creates files to lock serial ports and systems. On most if not +all systems these same lock files are also used by cu to coordinate +access to serial ports. On some systems getty also uses these lock +files, often under the name uugetty. + +The lock file normally contains the process ID of the locking process. +This makes it easy to determine whether a lock is still valid. The +algorithm is to create a temporary file and then link it to the name +that must be locked. If the link fails because a file with that name +already exists, the existing file is read to get the process ID. If +the process still exists, the lock attempt fails. Otherwise the lock +file is deleted and the locking algorithm is retried. + +Older UUCP packages put the lock files in the main UUCP spool +directory, /usr/spool/uucp. HDB UUCP generally puts the lock files in +a directory of their own, usually /usr/spool/locks or /etc/locks. + +The original UUCP lock file format encodes the process ID as a four +byte binary number. The order of the bytes is host-dependent. HDB +UUCP stores the process ID as a ten byte ASCII decimal number, with a +trailing newline. For example, if process 1570 holds a lock file, it +would contain the eleven characters space, space, space, space, space, +space, one, five, seven, zero, newline. Some versions of UUCP add a +second line indicating which program created the lock (uucp, cu, or +getty/uugetty). I have also seen a third type of UUCP lock file which +does not contain the process ID at all. + +The name of the lock file is traditionally "LCK.." followed by the +base name of the device. For example, to lock /dev/ttyd0 the file +LCK..ttyd0 would be created. On SCO Unix, the lock file name is +always forced to lower case even if the device name has upper case +letters. + +System V Release 4 UUCP names the lock file using the major and minor +device numbers rather than the device name. The file is named +LK.XXX.YYY.ZZZ, where XXX, YYY and ZZZ are all three digit decimal +numbers. XXX is the major device number of the device holding the +directory holding the device file (e.g., /dev). YYY is the major +device number of the device file itself. ZZZ is the minor device +number of the device file itself. If s holds the result of passing +the device to the stat system call (e.g., stat ("/dev/ttyd0", &s)), +the following line of C code will print out the corresponding lock +file name: + printf ("LK.%03d.%03d.%03d", major (s.st_dev), + major (s.st_rdev), minor (s.st_rdev)); +The advantage of this system is that even if there are several links +to the same device, they will all use the same lock file name. + +------------------------------ + +From: X-file +Subject: What is the format of a UUCP X.* file? + +UUCP X.* files control program execution. They are created by uux. +They are transferred between computers just like any other file. The +uuxqt daemon reads them to figure out how to execute the job requested +by uux. + +An X.* file is simply a text file. The first character of each line +is a command, and the remainder of the line supplies arguments. The +following commands are defined: + C command + This gives the command to execute, including the program and + all arguments. For example, + C rmail ian@airs.com + U user system + This names the user who requested the command, and the system + from which the request came. + I standard-input + This names the file from which standard input is taken. If no + standard input file is given, the standard input will probably + be attached to /dev/null. If the standard input file is not + from the system on which the execution is to occur, it will + also appear in an F command. + O standard-output [ system ] + This names the standard output file. The optional second + argument names the system to which the file should be sent. + If there is no second argument, the file should be created on + the executing system. + F required-file [ filename-to-use ] + The F command can appear multiple times. Each F command names + a file which must exist before the execution can proceed. + This will usually be a file which is transferred from the + system on which uux was executed, but it can also be a file + from the local system or some other system. If the file is + not from the local system, then the command will usually name + a file in the spool directory. If the optional second + argument appears, then the file should be copied to the + execution directory under that name. This is necessary for + any file other than the standard input file. If the standard + input file is not from the local system, it will appear in + both an F command and an I command. + R requestor-address + This is the address to which mail about the job should be + sent. It is relative to the system named in the U command. + If the R command does not appear, then mail is sent to the + user named in the U command. + Z + This command takes no arguments. It means that a mail message + should be sent if the command failed. This is the default + behaviour for most modern UUCP packages, and for them the Z + command does not actually do anything. + N + This command takes no arguments. It means that no mail + message should be sent, even if the command failed. + n + This command takes no arguments. It means that a mail message + should be sent if the command succeeded. Normally a message + is sent only if the command failed. + B + This command takes no arguments. It means that the standard + input should be returned with any error message. This can be + useful in cases where the input would otherwise be lost. + e + This command takes no arguments. It means that the command + should be processed with /bin/sh. For some packages this is + the default anyhow. Most packages will refuse to execute + complex commands or commands containing wildcards, because of + the security holes this opens. + E + This command takes no arguments. It means that the command + should be processed with the execve system call. For some + packages this is the default anyhow. + M status-file + This command means that instead of mailing a message, the + message should be copied to the named file on the system named + by the U command. + # comment + This command is ignored, as is any other unrecognized command. + +Here is an example. Given the following command executed on system +test1 + uux - test2!cat - test2!~ian/bar !qux '>~/gorp' +(this is only an example, as most UUCP systems will not permit the cat +command to be executed) Taylor UUCP will produce the following X. +file: + U ian test1 + F D.test1N003r qux + O /usr/spool/uucppublic test1 + F D.test1N003s + I D.test1N003s + C cat - ~ian/bar qux +The standard input will be read into a file and then transferred to +the file D.test1N003s on system test2, and the file qux will be +transferred to D.test1N003r on system test2. When the command is +executed, the latter file will be copied to the execution directory +under the name qux. Note that since the file ~ian/bar is already on +the execution system, no action need be taken for it. The standard +output will be collected in a file, then copied to the directory +/usr/spool/uucppublic on the system test1. + +------------------------------ + +From: UUCP-protocol +Subject: What is the UUCP protocol? + +The UUCP protocol is a conversation between two UUCP packages. A UUCP +conversation consists of three parts: an initial handshake, a series +of file transfer requests, and a final handshake. + +Before the initial handshake, the caller will usually have logged in +the called machine and somehow started the UUCP package there. On +Unix this is normally done by setting the shell of the login name used +to /usr/lib/uucp/uucico. + +All messages in the initial handshake begin with a ^P (a byte with the +octal value \020) and end with a null byte (\000). A few systems end +these messages with a line feed character (\012) instead of a null +byte; the examples below assume a null byte is being used. + +Some options below are supported by QFT, which stands for Queued File +Transfer, and is (or was) an internal Bell Labs version of UUCP. + +Taylor UUCP size negotiation was introduced by Taylor UUCP, and is +also supported by DOS based FSUUCP and Amiga based wUUCP and +UUCP-1.17. + +The initial handshake goes as follows. It is begun by the called +machine. + +called: \020Shere=hostname\000 + The hostname is the UUCP name of the called machine. Older UUCP + packages do not output it, and simply send \020Shere\000. + +caller: \020Shostname options\000 + The hostname is the UUCP name of the calling machine. The + following options may appear (or there may be none): + -QSEQ + Report sequence number for this conversation. The + sequence number is stored at both sites, and incremented + after each call. If there is a sequence number mismatch, + something has gone wrong (somebody may have broken + security by pretending to be one of the machines) and the + call is denied. If the sequence number changes on one of + the machines, perhaps because of an attempted breakin or + because a disk backup was restored, the sequence numbers + on the two machines must be reconciled manually. This is + not supported by FSUUCP. + -xLEVEL + Requests the called system to set its debugging level to + the specified value. This is not supported by all + systems. + -pGRADE + -vgrade=GRADE + Requests the called system to only transfer files of the + specified grade or higher. This is not supported by all + systems. Some systems support -p, some support -vgrade=. + -R + Indicates that the calling UUCP understands how to restart + failed file transmissions. Supported only by System V + Release 4 UUCP and QFT. + -ULIMIT + Reports the ulimit value of the calling UUCP. The limit + is specified as a base 16 number in C notation (e.g., + -U0x1000000). This number is the number of 512 byte + blocks in the largest file which the calling UUCP can + create. The called UUCP may not transfer a file larger + than this. Supported only by System V Release 4 UUCP, QFT + and FSUUCP. FSUUCP reports the lesser of the + available disk space on the spool directory drive and the + ulimit variable in FSUUCP.CFG. + -N + Indicates that the calling UUCP understands the Taylor + UUCP size negotiation extension. Not supported by + traditional UUCP packages. + +called: \020ROK\000 + There are actually several possible responses. + ROK + The calling UUCP is acceptable, and the handshake proceeds + to the protocol negotiation. Some options may also + appear; see below. + ROKN + The calling UUCP is acceptable, it specified -N, and the + called UUCP also understands the Taylor UUCP size limiting + extensions. + RLCK + The called UUCP already has a lock for the calling UUCP, + which normally indicates the two machines are already + communicating. + RCB + The called UUCP will call back. This may be used to avoid + impostors (but only one machine out of each pair should + call back, or no conversation will ever begin). + RBADSEQ + The call sequence number is wrong (see the -Q discussion + above). + RLOGIN + The calling UUCP is using the wrong login name. + RYou are unknown to me + The calling UUCP is not known to the called UUCP, and the + called UUCP does not permit connections from unknown + systems. Some versions of UUCP just drop the line rather + than sending this message. + + If the response is ROK, the following options are supported by + System V Release 4 UUCP and QFT. + -R + The called UUCP knows how to restart failed file + transmissions. + -ULIMIT + Reports the ulimit value of the called UUCP. The limit is + specified as a base 16 number in C notation. This number + is the number of 512 byte blocks in the largest file which + the called UUCP can create. The calling UUCP may not send + a file larger than this. Also supported by FSUUCP. + -xLEVEL + I'm not sure just what this means. It may request the + calling UUCP to set its debugging level to the specified + value. + If the response is not ROK (or ROKN) both sides hang up the phone, + abandoning the call. + +called: \020Pprotocols\000 + Note that the called UUCP outputs two strings in a row. The + protocols string is a list of UUCP protocols supported by the + caller. Each UUCP protocol has a single character name. These + protocols are discussed in more detail later in this document. + For example, the called UUCP might send \020Pgf\000. + +caller: \020Uprotocol\000 + The calling UUCP selects which protocol to use out of the + protocols offered by the called UUCP. If there are no mutually + supported protocols, the calling UUCP sends \020UN\000 and both + sides hang up the phone. Otherwise the calling UUCP sends + something like \020Ug\000. + +Most UUCP packages will consider each locally supported protocol in +turn and select the first one supported by the called UUCP. With some +versions of HDB UUCP, this can be modified by giving a list of +protocols after the device name in the Devices file or the Systems +file. For example, to select the 'e' protocol in Systems, + airs Any ACU,e ... +or in Devices, + ACU,e ttyXX ... +Taylor UUCP provides the ``protocol'' command which may be used either +for a system or a port. + +After the protocol has been selected and the initial handshake has been +completed, both sides turn on the selected protocol. For some +protocols (notably 'g') a further handshake is done at this point. + +Each protocol supports a method for sending a command to the remote +system. This method is used to transmit a series of commands between +the two UUCP packages. At all times, one package is the master and +the other is the slave. Initially, the calling UUCP is the master. + +If a protocol error occurs during the exchange of commands, both sides +move immediately to the final handshake. + +The master will send one of four commands: S, R, X or H. + +Any file name referred to below is either an absolute pathname +beginning with "/", a public directory pathname beginning with "~/", a +pathname relative to a user's home directory beginning with "~USER/", +or a spool directory file name. File names in the spool directory are +not pathnames, but instead are converted to pathnames within the spool +directory by UUCP. They always begin with "C." (for a command file +created by uucp or uux), "D." (for a data file created by uucp, uux or +by an execution, or received from another system for an execution), or +"X." (for an execution file created by uux or received from another +system). + +master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE + The S and the - are literal characters. This is a request by the + master to send a file to the slave. + FROM + The name of the file to send. If the C option does not + appear in OPTIONS, the master will actually open and send + this file. Otherwise the file has been copied to the + spool directory, where it is named TEMP. The slave + ignores this field unless TO is a directory, in which case + the basename of FROM will be used as the file name. If + FROM is a spool directory filename, it must be a data file + created for or by an execution, and must begin with "D.". + TO + The name to give the file on the slave. If this field + names a directory the file is placed within that directory + with the basename of FROM. A name ending in `/' is taken + to be a directory even if one does not already exist with + that name. If TO begins with `X.', an execution file will + be created on the slave. Otherwise, if TO begins with + `D.' it names a data file to be used by some execution + file. Otherwise, TO should not be in the spool directory. + USER + The name of the user who requested the transfer. + OPTIONS + A list of options to control the transfer. The following + options are defined (all options are single characters): + C + The file has been copied to the spool directory + (the master should use TEMP rather than FROM). + c + The file has not been copied to the spool + directory (this is the default). + d + The slave should create directories as necessary + (this is the default). + f + The slave should not create directories if + necessary, but should fail the transfer instead. + m + The master should send mail to USER when the + transfer is complete (not supported by FSUUCP). + n + The slave should send mail to NOTIFY when the + transfer is complete (not supported by FSUUCP). + TEMP + If the C option appears in OPTIONS, this names the file to + be sent. Otherwise if FROM is in the spool directory, + TEMP is the same as FROM. Otherwise TEMP may be a dummy + string, such as "D.0". After the transfer has been + succesfully completed, the master will delete the file + TEMP. + MODE + This is an octal number giving the mode of the file on + MASTER. If the file is not in the spool directory, the + slave will always create it with mode 0666, except that if + (MODE & 0111) is not zero (the file is executable), the + slave will create the file with mode 0777. If the file is + in the spool directory, some UUCP packages will use the + algorithm above and some will always create the file with + mode 0600. This field is not used by FSUUCP, since it is + meaningless on DOS. + NOTIFY + This field may not be present, and in any case is only + meaningful if the n option appears in OPTIONS. If the n + option appears, then when the transfer is successfully + completed, the slave will send mail to NOTIFY, which must + be a legal mailing address on the slave. If a SIZE field + will appear but the n option does not appear, NOTIFY will + always be present, typically as the string "dummy" or + simply a pair of double quotes. + SIZE + This field is only present when doing Taylor UUCP or SVR4 + UUCP size negotiation, It is the size of the file in + bytes. Taylor UUCP version 1.03 sends the size as a + decimal integer, while versions 1.04 and up, and all other + UUCP packages that support size negotiation, send the size + in base 16 with a leading 0x. + + The slave then responds with an S command response. + SY START + The slave is willing to accept the file, and file transfer + begins. The START field will only be present when using + file restart. It specifies the byte offset into the file + at which to start sending. If this is a new file, START + will be 0x0. + SN2 + The slave denies permission to transfer the file. This + can mean that the destination directory may not be + accessed, or that no requests are permitted. It implies + that the file transfer will never succeed. + SN4 + The slave is unable to create the necessary temporary + file. This implies that the file transfer might succeed + later. + SN6 + This is only used by Taylor UUCP size negotiation. It + means that the slave considers the file too large to + transfer at the moment, but it may be possible to transfer + it at some other time. + SN7 + This is only used by Taylor UUCP size negotiation. It + means that the slave considers the file too large to ever + transfer. + SN8 + This is only used by Taylor UUCP. It means that the file + was already received in a previous conversation. This can + happen if the receive acknowledgement was lost after it + was sent by the receiver but before it was received by the + sender. + SN9 + This is only used by Taylor UUCP (versions 1.05 and up) + and FSUUCP (versions 1.5 and up). It means that the + remote system was unable to open another channel (see the + discussion of the 'i' protocol for more information about + channels). This implies that the file transfer might + succeed later. + SN10 + This is reportedly used by SVR4 UUCP to mean that the file + size is too large. + + If the slave responds with SY, a file transfer begins. When the + file transfer is complete, the slave sends a C command response. + CY + The file transfer was successful. + CYM + The file transfer was successful, and the slave wishes to + become the master; the master should send an H command, + described below. + CN5 + The temporary file could not be moved into the final + location. This implies that the file transfer will never + succeed. + + After the C command response has been received (in the SY case) or + immediately (in an SN case) the master will send another command. + +master: R FROM TO USER -OPTIONS SIZE + The R and the - are literal characters. This is a request by the + master to receive a file from the slave. I do not know how SVR4 + UUCP or QFT implement file transfer restart in this case. + FROM + This is the name of the file on the slave which the master + wishes to receive. It must not be in the spool directory, + and it may not contain any wildcards. + TO + This is the name of the file to create on the master. I + do not believe that it can be a directory. It may only be + in the spool directory if this file is being requested to + support an execution either on the master or on some + system other than the slave. + USER + The name of the user who requested the transfer. + OPTIONS + A list of options to control the transfer. The following + options are defined (all options are single characters): + d + The master should create directories as necessary + (this is the default). + f + The master should not create directories if + necessary, but should fail the transfer instead. + m + The master should send mail to USER when the + transfer is complete. + SIZE + This only appears if Taylor UUCP size negotiation is being + used. It specifies the largest file which the master is + prepared to accept (when using SVR4 UUCP or QFT, this was + specified in the -U option during the initial handshake). + + The slave then responds with an R command response. FSUUCP does + not support R requests, and always responds with RN2. + RY MODE [ SIZE ] + The slave is willing to send the file, and file transfer + begins. MODE is the octal mode of the file on the slave. + The master treats this just as the slave does the MODE + argument in the send command, q.v. I am told that SVR4 + UUCP sends a trailing SIZE argument. For some versions of + BSD UUCP, the MODE argument may have a trailing M + character (e.g., RY 0666M). This means that the slave + wishes to become the master. + RN2 + The slave is not willing to send the file, either because + it is not permitted or because the file does not exist. + This implies that the file request will never succeed. + RN6 + This is only used by Taylor UUCP size negotiation. It + means that the file is too large to send, either because + of the size limit specifies by the master or because the + slave considers it too large. The file transfer might + succeed later, or it might not (this will be cleared up in + a later release of Taylor UUCP). + RN9 + This is only used by Taylor UUCP (versions 1.05 and up) + and FSUUCP (versions 1.5 and up). It means that the + remote system was unable to open another channel (see the + discussion of the 'i' protocol for more information about + channels). This implies that the file transfer might + succeed later. + + If the slave responds with RY, a file transfer begins. When the + file transfer is complete, the master sends a C command. The + slave pretty much ignores this, although it may log it. + CY + The file transfer was successful. + CN5 + The temporary file could not be moved into the final + location. + + After the C command response has been sent (in the RY case) or + immediately (in an RN case) the master will send another command. + +master: X FROM TO USER -OPTIONS + The X and the - are literal characters. This is a request by the + master to, in essence, execute uucp on the slave. The slave + should execute "uucp FROM TO". + FROM + This is the name of the file or files on the slave which + the master wishes to transfer. Any wildcards are expanded + on the slave. If the master is requesting that the files + be transferred to itself, the request would normally + contain wildcard characters, since otherwise an `R' + command would suffice. The master can also use this + command to request that the slave transfer files to a + third system. + TO + This is the name of the file or directory to which the + files should be transferred. This will normally use a + UUCP name. For example, if the master wishes to receive + the files itself, it would use "master!path". + USER + The name of the user who requested the transfer. + OPTIONS + A list of options to control the transfer. It is not + clear which, if any, options are supported by most UUCP + packages. + + The slave then responds with an X command response. FSUUCP does + not support X requests, and always responds with XN. + XY + The request was accepted, and the appropriate file + transfer commands have been queued up for later + processing. + XN + The request was denied. No particular reason is given. + + In either case, the master will then send another command. + +master: H + This is used by the master to hang up the connection. The slave + will respond with an H command response. + HY + The slave agrees to hang up the connection. In this case + the master sends another HY command. In some UUCP + packages the slave will then send a third HY command. At + this point the protocol is shut down, and the final + handshake is begun. + HN + The slave does not agree to hang up. In this case the + master and the slave exchange roles. The next command + will be sent by the former slave, which is the new master. + The roles may be reversed several times during a single + connection. + +After the protocol has been shut down, the final handshake is +performed. This handshake has no real purpose, and some UUCP packages +simply drop the connection rather than do it (in fact, some will drop +the connection immediately after both sides agree to hangup, without +even closing down the protocol). + +caller: \020OOOOOO\000 +called: \020OOOOOOO\000 + +That is, the calling UUCP sends six O's and the called UUCP replies +with seven O's. Some UUCP packages always send six O's. + +------------------------------ + +From: UUCP-g +Subject: What is the 'g' protocol? + +The 'g' protocol is a packet based flow controlled error correcting +protocol that requires an eight bit clear connection. It is the +original UUCP protocol, and is supported by all UUCP implementations. +Many implementations of it are only able to support small window and +packet sizes, specifically a window size of 3 and a packet size of 64 +bytes, but the protocol itself can support up to a window size of 7 +and a packet size of 4096 bytes. Complaints about the inefficiency of +the 'g' protocol generally refer to specific implementations, rather +than to the correctly implemented protocol. + +The 'g' protocol was originally designed for general packet drivers, +and thus contains some features that are not used by UUCP, including +an alternate data channel and the ability to renegotiate packet and +window sizes during the communication session. + +The 'g' protocol is spoofed by many Telebit modems. When spoofing is +in effect, each Telebit modem uses the 'g' protocol to communicate +with the attached computer, but the data between the modems is sent +using a Telebit proprietary error correcting protocol. This allows +for very high throughput over the Telebit connection, which, because +it is half-duplex, would not normally be able to handle the 'g' +protocol very well at all. When a Telebit is spoofing the 'g' +protocol, it forces the packet size to be 64 bytes and the window size +to be 3. + +This discussion of the 'g' protocol explains how it works, but does +not discuss useful error handling techniques. Some discussion of this +can be found in Jamie E. Hanrahan's paper, cited above. + +All 'g' protocol communication is done with packets. Each packet +begins with a six byte header. Control packets consist only of the +header. Data packets contain additional data. + +The header is as follows: + + \020 + Every packet begins with a ^P. + k (1 <= k <= 9) + The k value is always 9 for a control packet. For a data + packet, the k value indicates how much data follows the six + byte header. The amount of data is 2 ** (k + 4), where ** + indicates exponentiation. Thus a k value of 1 means 32 data + bytes and a k value of 8 means 4096 data bytes. The k value + for a data packet must be between 1 and 8 inclusive. + checksum low byte + checksum high byte + The checksum value is described below. + control byte + The control byte indicates the type of packet, and is + described below. + xor byte + This byte is the xor of k, the checksum low byte, the checksum + high byte and the control byte (i.e., the second, third, + fourth and fifth header bytes). It is used to ensure that the + header data is valid. + +The control byte in the header is composed of three bit fields, +referred to here as TT (two bits), XXX (three bits) and YYY (three +bits). The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY. + +The TT field takes on the following values: + 0 + This is a control packet. In this case the k byte in the + header must be 9. The XXX field indicates the type of control + packet; these types are described below. + 1 + This is an alternate data channel packet. This is not used by + UUCP. + 2 + This is a data packet, and the entire contents of the attached + data field (whose length is given by the k byte in the header) + are valid. The XXX and YYY fields are described below. + 3 + This is a short data packet. Let the length of the data field + (as given by the k byte in the header) be L. Let the first + byte in the data field be B1. If B1 is less than 128 (if the + most significant bit of B1 is 0), then there are L - B1 valid + bytes of data in the data field, beginning with the second + byte. If B1 >= 128, let B2 be the second byte in the data + field. Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid + bytes of data in the data field, beginning with the third + byte. In all cases L bytes of data are sent (and all data + bytes participate in the checksum calculation) but some of the + trailing bytes may be dropped by the receiver. The XXX and + YYY fields are described below. + +In a data packet (short or not) the XXX field gives the sequence +number of the packet. Thus sequence numbers can range from 0 to 7, +inclusive. The YYY field gives the sequence number of the last +correctly received packet. + +Each communication direction uses a window which indicates how many +unacknowledged packets may be transmitted before waiting for an +acknowledgement. The window may range from 1 to 7, and may be +different in each direction. For example, if the window is 3 and the +last packet acknowledged was packet number 6, packet numbers 7, 0 and +1 may be sent but the sender must wait for an acknowledgement before +sending packet number 2. This acknowledgement could come as the YYY +field of a data packet or as the YYY field of a RJ or RR control +packet (described below). + +Each packet must be transmitted in order (the sender may not skip +sequence numbers). Each packet must be acknowledged, and each packet +must be acknowledged in order. + +In a control packet, the XXX field takes on the following values: + 1 CLOSE + The connection should be closed immediately. This is + typically sent when one side has seen too many errors and + wants to give up. It is also sent when shutting down the + protocol. If an unexpected CLOSE packet is received, a CLOSE + packet should be sent in reply and the 'g' protocol should + halt, causing UUCP to enter the final handshake. + 2 RJ or NAK + The last packet was not received correctly. The YYY field + contains the sequence number of the last correctly received + packet. + 3 SRJ + Selective reject. The YYY field contains the sequence number + of a packet that was not received correctly, and should be + retransmitted. This is not used by UUCP, and most + implementations will not recognize it. + 4 RR or ACK + Packet acknowledgement. The YYY field contains the sequence + number of the last correctly received packet. + 5 INITC + Third initialization packet. The YYY field contains the + maximum window size to use. + 6 INITB + Second initialization packet. The YYY field contains the + packet size to use. It requests a size of 2 ** (YYY + 5). + Note that this is not the same coding used for the k byte in + the packet header (it is 1 less). Most UUCP implementations + that request a packet size larger than 64 bytes can handle any + packet size up to that specified. + 7 INITA + First initialization packet. The YYY field contains the + maximum window size to use. + +The checksum of a control packet is simply 0xaaaa - the control byte. + +The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte), +where ^ denotes exclusive or, and CHECK is the result of the following +routine as run on the contents of the data field (every byte in the +data field participates in the checksum, even for a short data +packet). Below is the routine used by Taylor UUCP; it is a slightly +modified version of a routine which John Gilmore patched from G.L. +Chesson's original paper. The z argument points to the data and the c +argument indicates how much data there is. + +int +igchecksum (z, c) + register const char *z; + register int c; +{ + register unsigned int ichk1, ichk2; + + ichk1 = 0xffff; + ichk2 = 0; + + do + { + register unsigned int b; + + /* Rotate ichk1 left. */ + if ((ichk1 & 0x8000) == 0) + ichk1 <<= 1; + else + { + ichk1 <<= 1; + ++ichk1; + } + + /* Add the next character to ichk1. */ + b = *z++ & 0xff; + ichk1 += b; + + /* Add ichk1 xor the character position in the buffer counting from + the back to ichk2. */ + ichk2 += ichk1 ^ c; + + /* If the character was zero, or adding it to ichk1 caused an + overflow, xor ichk2 to ichk1. */ + if (b == 0 || (ichk1 & 0xffff) < b) + ichk1 ^= ichk2; + } + while (--c > 0); + + return ichk1 & 0xffff; +} + +When the 'g' protocol is started, the calling UUCP sends an INITA +control packet with the window size it wishes the called UUCP to use. +The called UUCP responds with an INITA packet with the window size it +wishes the calling UUCP to use. Pairs of INITB and INITC packets are +then similarly exchanged. When these exchanges are completed, the +protocol is considered to have been started. + +Note that the window and packet sizes are not a negotiation. Each +system announces the window and packet size which the other system +should use. It is possible that different window and packet sizes +will be used in each direction. The protocol works this way on the +theory that each system knows how much data it can accept without +getting overrun. Therefore, each system tells the other how much data +to send before waiting for an acknowledgement. + +When a UUCP package transmits a command, it sends one or more data +packets. All the data packets will normally be complete, although +some UUCP packages may send the last one as a short packet. The +command string is sent with a trailing null byte, to let the receiving +package know when the command is finished. Some UUCP packages require +the last byte of the last packet sent to be null, even if the command +ends earlier in the packet. Some packages may require all the +trailing bytes in the last packet to be null, but I have not confirmed +this. + +When a UUCP package sends a file, it will send a sequence of data +packets. The end of the file is signalled by a short data packet +containing zero valid bytes (it will normally be preceeded by a short +data packet containing the last few bytes in the file). + +Note that the sequence numbers cover the entire communication session, +including both command and file data. + +When the protocol is shut down, each UUCP package sends a CLOSE +control packet. + +------------------------------ + +From: UUCP-f +Subject: What is the 'f' protocol? + +The 'f' protocol is a seven bit protocol which checksums an entire +file at a time. It only uses the characters between \040 and \176 +(ASCII space and ~) inclusive as well as the carriage return +character. It can be very efficient for transferring text only data, +but it is very inefficient at transferring eight bit data (such as +compressed news). It is not flow controlled, and the checksum is +fairly insecure over large files, so using it over a serial connection +requires handshaking (XON/XOFF can be used) and error correcting +modems. Some people think it should not be used even under those +circumstances. + +I believe the 'f' protocol originated in BSD versions of UUCP. It was +originally intended for transmission over X.25 PAD links. + +The 'f' protocol has no startup or finish protocol. However, both +sides typically sleep for a couple of seconds before starting up, +because they switch the terminal into XON/XOFF mode and want to allow +the changes to settle before beginning transmission. + +When a UUCP package transmits a command, it simply sends a string +terminated by a carriage return. + +When a UUCP package transmits a file, each byte b of the file is +translated according to the following table: + + 0 <= b <= 037: 0172, b + 0100 (0100 to 0137) + 040 <= b <= 0171: b ( 040 to 0171) + 0172 <= b <= 0177: 0173, b - 0100 ( 072 to 077) + 0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137) + 0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171) + 0372 <= b <= 0377: 0176, b - 0300 ( 072 to 077) + +That is, a byte between \040 and \171 inclusive is transmitted as is, +and all other bytes are prefixed and modified as shown. + +When all the file data is sent, a seven byte sequence is sent: two +bytes of \176 followed by four ASCII bytes of the checksum as printed +in base 16 followed by a carriage return. For example, if the +checksum was 0x1234, this would be sent: "\176\1761234\r". + +The checksum is initialized to 0xffff. For each byte that is sent it +is modified as follows (where b is the byte before it has been +transformed as described above): + + /* Rotate the checksum left. */ + if ((ichk & 0x8000) == 0) + ichk <<= 1; + else + { + ichk <<= 1; + ++ichk; + } + + /* Add the next byte into the checksum. */ + ichk += b; + +When the receiving UUCP sees the checksum, it compares it against its +own calculated checksum and replies with a single character followed +by a carriage return. + G + The file was received correctly. + R + The checksum did not match, and the file should be resent from + the beginning. + Q + The checksum did not match, but too many retries have occurred + and the communication session should be abandoned. + +The sending UUCP checks the returned character and acts accordingly. + +------------------------------ + +From: UUCP-t +Subject: What is the 't' protocol? + +The 't' protocol is intended for use on links which provide reliable +end-to-end connections, such as TCP. It does no error checking or +flow control, and requires an eight bit clear channel. + +I believe the 't' protocol originated in BSD versions of UUCP. + +When a UUCP package transmits a command, it first gets the length of +the command string, C. It then sends ((C / 512) + 1) * 512 bytes (the +smallest multiple of 512 which can hold C bytes plus a null byte) +consisting of the command string itself followed by trailing null +bytes. + +When a UUCP package sends a file, it sends it in blocks. Each block +contains at most 1024 bytes of data. Each block consists of four +bytes containing the amount of data in binary (most significant byte +first, the same format as used by the Unix function htonl) followed by +that amount of data. The end of the file is signalled by a block +containing zero bytes of data. + +------------------------------ + +From: UUCP-e +Subject: What is the 'e' protocol? + +The 'e' protocol is similar to the 't' protocol. It does no flow +control or error checking and is intended for use over networks +providing reliable end-to-end connections, such as TCP. + +The 'e' protocol originated in versions of HDB UUCP. + +When a UUCP package transmits a command, it simply sends the command +as an ASCII string terminated by a null byte. + +When a UUCP package transmits a file, it sends the complete size of +the file as an ASCII decimal number. The ASCII string is padded out +to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it +sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"). It then sends the +entire file. + +------------------------------ + +From: UUCP-G +Subject: What is the 'G' protocol? + +The 'G' protocol is used by SVR4 UUCP. It is identical to the 'g' +protocol, except that it is possible to modify the window and packet +sizes. The SVR4 implementation of the 'g' protocol reportedly is +fixed at a packet size of 64 and a window size of 7. Supposedly SVR4 +chose to implement a new protocol using a new letter to avoid any +potential incompatibilities when using different packet or window +sizes. + +Most implementations of the 'g' protocol that accept packets larger +than 64 bytes will also accept packets smaller than whatever they +requested in the INITB packet. The SVR4 'G' implementation is an +exception; it will only accept packets of precisely the size it +requests in the INITB packet. + +------------------------------ + +From: UUCP-i +Subject: What is the 'i' protocol? + +The 'i' protocol was written by Ian Lance Taylor (who also wrote this +FAQ). It is used by Taylor UUCP version 1.04. + +It is a sliding window packet protocol, like the 'g' protocol, but it +supports bidirectional transfers (i.e., file transfers in both +directions simultaneously). It requires an eight bit clear +connection. Several ideas for the protocol were taken from the paper +``A High-Throughput Message Transport System'' by P. Lauder. I don't +know where the paper was published, but the author's e-mail address is +piers@cs.su.oz.au. The 'i' protocol does not adopt his main idea, +which is to dispense with windows entirely. This is because some +links still do require flow control and, more importantly, because +using windows sets a limit to the amount of data which the protocol +must be able to resend upon request. To reduce the costs of window +acknowledgements, the protocol uses a large window and only requires +an ack at the halfway point. + +Each packet starts with a six byte header, optionally followed by data +bytes with a four byte checksum. There are currently five defined +packet types (DATA, SYNC, ACK, NAK, SPOS, CLOSE) which are described +below. Although any packet type may include data, any data provided +with an ACK, NAK or CLOSE packet is ignored. + +Every DATA, SPOS and CLOSE packet has a sequence number. The sequence +numbers are independent for each side. The first packet sent by each +side is always number 1. Each packet is numbered one greater than the +previous packet, modulo 32. + +Every packet has a local channel number and a remote channel number. +For all packets at least one channel number is zero. When a UUCP +command is sent to the remote system, it is assigned a non-zero local +channel number. All packets associated with that UUCP command sent by +the local system are given the selected local channel number. All +associated packets sent by the remote system are given the selected +number as the remote channel number. This permits each UUCP command +to be uniquely identified by the channel number on the originating +system, and therefore each UUCP package can associate all file data +and UUCP command responses with the appropriate command. This is a +requirement for bidirectional UUCP transfers. + +The protocol maintains a single global file position, which starts at +0. For each incoming packet, any associated data is considered to +occur at the current file position, and the file position is +incremented by the amount of data contained. The exception is a +packet of type SPOS, which is used to change the file position. +The reason for keeping track of the file position is described below. + +The header is as follows: + + \007 + Every packet begins with ^G. + (PACKET << 3) + LOCCHAN + The five bit packet number combined with the three bit local + channel number. DATA, SPOS and CLOSE packets use the packet + sequence number for the PACKET field. NAK packet types use + the PACKET field for the sequence number to be resent. ACK + and SYNC do not use the PACKET field, and generally leave it + set to 0. Packets which are not associated with a UUCP + command from the local system use a local channel number of 0. + (ACK << 3) + REMCHAN + The five bit packet acknowledgement combined with the three + bit remote channel number. The packet acknowledgement is the + number of the last packet successfully received; it is used by + all packet types. Packets which are not sent in response to a + UUCP command from the remote system use a remote channel + number of 0. + (TYPE << 5) + (CALLER << 4) + LEN1 + The three bit packet type combined with the one bit packet + direction combined with the upper four bits of the data + length. The packet direction bit is always 1 for packets sent + by the calling UUCP, and 0 for packets sent by the called + UUCP. This prevents confusion caused by echoed packets. + LEN2 + The lower eight bits of the data length. The twelve bits of + data length permit packets ranging in size from 0 to 4095 + bytes. + CHECK + The exclusive or of the second through fifth bytes of the + header. This provides an additional check that the header is + valid. + +If the data length is non-zero, the packet is immediately followed by +the specified number of data bytes. The data bytes are followed by a +four byte CRC 32 checksum, with the most significant byte first. The +CRC is calculated over the contents of the data field. + +The defined packet types are as follows: + + 0 (DATA) + This is a plain data packet. + 1 (SYNC) + SYNC packets are exchanged when the protocol is initialized, + and are described further below. SYNC packets do not carry + sequence numbers (that is, the PACKET field is ignored). + 2 (ACK) + This is an acknowledgement packet. Since DATA packets also + carry packet acknowledgements, ACK packets are only used when + one side has no data to send. ACK packets do not carry + sequence numbers. + 3 (NAK) + This is a negative acknowledgement. This is sent when a + packet is received incorrectly, and means that the packet + number appearing in the PACKET field must be resent. NAK + packets do not carry sequence numbers (the PACKET field is + already used). + 4 (SPOS) + This packet changes the file position. The packet contains + four bytes of data holding the file position, most significant + byte first. The next packet received will be considered to be + at the named file position. + 5 (CLOSE) + When the protocol is shut down, each side sends a CLOSE + packet. This packet does have a sequence number, which could + be used to ensure that all packets were correctly received + (this is not needed by UUCP, however, which uses the higher + level H command with an HY response). + +When the protocol starts up, both systems send a SYNC packet. The +SYNC packet includes at least three bytes of data. The first two +bytes are the maximum packet size the remote system should send, most +significant byte first. The third byte is the window size the remote +system should use. The remote system may send packets of any size up +to the maximum. If there is a fourth byte, it is the number of +channels the remote system may use (this must be between 1 and 7, +inclusive). Additional data bytes may be defined in the future. + +The window size is the number of packets that may be sent before a +packet is acknowledged. There is no requirement that every packet be +acknowledged; any acknowledgement is considered to acknowledge all +packets through the number given. In the current implementation, if +one side has no data to send, it sends an ACK when half the window is +received. + +Note that the NAK packet corresponds to the unused 'g' protocol SRJ +packet type, rather than to the RJ packet type. When a NAK is +received, only the named packet should be resent, not any subsequent +packets. + +Note that if both sides have data to send, but a packet is lost, it is +perfectly reasonable for one side to continue sending packets, all of +which will acknowledge the last packet correctly received, while the +system whose packet was lost will be unable to send a new packet +because the send window will be full. In this circumstance, neither +side will time out and one side of the communication will be +effectively shut down for a while. Therefore, any system with +outstanding unacknowledged packets should arrange to time out and +resend a packet even if data is being received. + +Commands are sent as a sequence of data packets with a non-zero local +channel number. The last data packet for a command includes a +trailing null byte (normally a command will fit in a single data +packet). Files are sent as a sequence of data packets ending with one +of length zero. + +The channel numbers permit a more efficient implementation of the UUCP +file send command. Rather than send the command and then wait for the +SY response before sending the file, the file data is sent beginning +immediately after the S command is sent. If an SN response is +received, the file send is aborted, and a final data packet of length +zero is sent to indicate that the channel number may be reused. If an +SY reponse with a file position indicator is received, the file send +adjusts to the file position; this is why the protocol maintains a +global file position. + +Note that the use of channel numbers means that each UUCP system may +send commands and file data simultaneously. Moreover, each UUCP +system may send multiple files at the same time, using the channel +number to disambiguate the data. Sending a file before receiving an +acknowledgement for the previous file helps to eliminate the round +trip delays inherent in other UUCP protocols. + +------------------------------ + +From: UUCP-j +Subject: What is the 'j' protocol? + +The 'j' protocol is a variant of the 'i' protocol. It was also +written by Ian Lance Taylor, and first appeared in Taylor UUCP version +1.04. + +The 'j' protocol is a version of the 'i' protocol designed for +communication links which intercept a few characters, such as XON or +XOFF. It is not efficient to use it on a link which intercepts many +characters, such as a seven bit link. The 'j' protocol performs no +error correction or detection; that is presumed to be the +responsibility of the 'i' protocol. + +When the 'j' protocol starts up, each system sends a printable ASCII +string indicating which characters it wants to avoid using. The +string begins with the ASCII character '^' (octal 136) and ends with +the ASCII character '~' (octal 176). After sending this string, each +system looks for the corresponding string from the remote system. The +strings are composed of escape sequences: \ooo, where o is an octal +digit. For example, sending the string ^\021\023~ means that the +ASCII XON and XOFF characters should be avoided. The union of the +characters described in both strings (the string which is sent and the +string which is received) is the set of characters which must be +avoided in this conversation. Avoiding a printable ASCII character +(octal 040 to octal 176, inclusive) is not permitted. + +After the exchange of characters to avoid, the normal 'i' protocol +start up is done, and the rest of the conversation uses the normal 'i' +protocol. However, each 'i' protocol packet is wrapped to become a +'j' protocol packet. + +Each 'j' protocol packet consists of a seven byte header, followed by +data bytes, followed by index bytes, followed by a one byte trailer. +The packet header looks like this: + + ^ + Every packet begins with the ASCII character '^', octal 136. + HIGH + LOW + These two characters give the total number of bytes in the + packet. Both HIGH and LOW are printable ASCII characters. + The length of the packet is (HIGH - 040) * 0100 + (LOW - 040), + where 040 <= HIGH < 0177 and 040 <= LOW < 0140. This permits + a length of 6079 bytes, but there is a further restriction on + packet size described below. + = + The ASCII character '=', octal 075. + DATA-HIGH + DATA-LOW + These two characters give the total number of data bytes in + the packet. The encoding is as described for HIGH and LOW. + The number of data bytes is the size of the 'i' protocol + packet wrapped inside this 'j' protocol packet. + @ + The ASCII character '@', octal 100. + +The header is followed by the number of data bytes given in DATA-HIGH +and DATA-LOW. These data bytes are the 'i' protocol packet which is +being wrapped in the 'j' protocol packet. However, each character in +the 'i' protocol packet which the 'j' protocol must avoid is +transformed into a printable ASCII character (recall that avoiding a +printable ASCII character is not permitted). Two index bytes are used +for each character which must be transformed. + +The index bytes immediately follow the data bytes. The index bytes +are created in pairs. Each pair of index bytes encodes the location +of a character in the 'i' protocol packet which was transformed to +become a printable ASCII character. Each pair of index bytes also +encodes the precise transformation which was performed. + +When the sender finds a character which must be avoided, it will +transform it using one or two operations. If the character is 0200 or +greater, it will subtract 0200. If the resulting character is less +than 020, or is equal to 0177, it will xor by 020. The result is +a printable ASCII character. + +The zero based byte index of the character within the 'i' protocol +packet is determined. This index is turned into a two byte printable +ASCII index, INDEX-HIGH and INDEX-LOW, such that the index is +(INDEX-HIGH - 040) * 040 + (INDEX-LOW - 040). INDEX-LOW is restricted +such that 040 <= INDEX-LOW < 0100. INDEX-HIGH is not permitted to be +0176, so 040 <= INDEX-HIGH < 0176. INDEX-LOW is then modified to +encode the transformation: + + If the character transformation only had to subtract 0200, then + INDEX-LOW is used as is. + + If the character transformation only had to xor by 020, then 040 + is added to INDEX-LOW. + + If both operations had to be performed, then 0100 is added to + INDEX-LOW. However, if the value of INDEX-LOW were initially 077, + then adding 0100 would result in 0177, which is not a printable + ASCII character. For that special case, INDEX-HIGH is set to + 0176, and INDEX-LOW is set to the original value of INDEX-HIGH. + +The receiver decodes the index bytes as follows (this is the reverse +of the operations performed by the sender, presented here for +additional clarity): + + The first byte in the index is INDEX-HIGH, and the second is + INDEX-LOW. + + If 040 <= INDEX-HIGH < 0176, the index refers to the data byte at + position (INDEX-HIGH - 040) * 040 + INDEX-LOW % 040. + + If 040 <= INDEX-LOW < 0100, then 0200 must be added to indexed + byte. + + If 0100 <= INDEX-LOW < 0140, then 020 must be xor'ed to the + indexed byte. + + If 0140 <= INDEX-LOW < 0177, then 0200 must be added to the + indexed byte, and 020 must be xor'ed to the indexed byte. + + If INDEX-HIGH == 0176, the index refers to the data byte at + position (INDEX-LOW - 040) * 040 + 037. 0200 must be added to the + indexed byte, and 020 must be xor'ed to the indexed byte. + +This means the largest 'i' protocol packet which may be wrapped inside +a 'j' protocol packet is (0175 - 040) * 040 + (077 - 040) == 3007 +bytes. + +The final character in a 'j' protocol packet, following the index +bytes, is the ASCII character '~' (octal 176). + +The motivation behind using an indexing scheme, rather than escape +characters, is to avoid data movement. The sender may simply add a +header and a trailer to the 'i' protocol packet. Once the receiver +has loaded the 'j' protocol packet, it may scan the index bytes, +transforming the data bytes, and then pass the data bytes directly on +to the 'i' protocol routine. + +------------------------------ + +From: UUCP-x +Subject: What is the 'x' protocol? + +The 'x' protocol is used in Europe (and probably elsewhere) with +machines that contain an builtin X.25 card and can send eight bit data +transparently across X.25 circuits, without interference from the X.28 +or X.29 layers. The protocol sends packets of 512 bytes, and relies +on a write of zero bytes being read as zero bytes without stopping +communication. It first appeared in the original System V UUCP +implementation. + +------------------------------ + +From: UUCP-y +Subject: What is the 'y' protocol? + +The 'y' protocol was developed by Jorge Cwik for use in FX UUCICO, a +PC uucico program. It is designed for communication lines which +handle error correction and flow control. It is a streaming protocol, +like the 'f' protocol. It requires an eight bit clean connection. It +performs error detection, but not error correction; when an error is +detected, the line is dropped. I do not know the implementation +details. + +------------------------------ + +From: UUCP-d +Subject: What is the 'd' protocol? + +This is apparently used for DataKit muxhost (not RS-232) connections. +No file size is sent. When a file has been completely transferred, a +write of zero bytes is done; this must be read as zero bytes on the +other end. + +------------------------------ + +From: UUCP-h +Subject: What is the 'h' protocol? + +This is apparently used in some places with HST modems. It does no +error checking, and is not that different from the 't' protocol. I +don't know the details. + +------------------------------ + +From: UUCP-v +Subject: What is the 'v' protocol? + +The 'v' protocol is used by UUPC/extended, a PC UUCP program. It is +simply a version of the 'g' protocol which supports packets of any +size, and also supports sending packets of different sizes during the +same conversation. There are many 'g' protocol implementations which +support both, but there are also many which do not. Using 'v' ensures +that everything is supported. + +------------------------------ + +From: Thanks +Subject: Thanks + +Besides the papers and information acknowledged at the top of this +article, the following people have contributed help, advice, +suggestions and information: + Earle Ake 513-429-6500 <ake@Dayton.SAIC.COM> + cambler@nike.calpoly.edu (Christopher J. Ambler) + jhc@iscp.bellcore.com (Jonathan Clark) + jorge@laser.satlink.net (Jorge Cwik) + celit!billd@UCSD.EDU (Bill Davidson) + "Drew Derbyshire" <ahd@kew.com> + erik@pdnfido.fidonet.org + Matthew Farwell <dylan@ibmpcug.co.uk> + dgilbert@gamiga.guelphnet.dweomer.org (David Gilbert) + kherron@ms.uky.edu (Kenneth Herron) + Mike Ipatow <mip@fido.itc.e-burg.su> + Romain Kang <romain@pyramid.com> + "Jonathan I. Kamens" <jik@GZA.COM> + "David J. MacKenzie" <djm@eng.umd.edu> + jum@helios.de (Jens-Uwe Mager) + peter@xpoint.ruessel.sub.org (Peter Mandrella) + david nugent <david@csource.oz.au> + Stephen.Page@prg.oxford.ac.uk + joey@tessi.UUCP (Joey Pruett) + James Revell <revell@uunet.uu.net> + Larry Rosenman <ler@lerami.lerctr.org> + Rich Salz <rsalz@bbn.com> + evesg@etlrips.etl.go.jp (Gjoen Stein) + kls@ditka.Chicago.COM (Karl Swartz) + Dima Volodin <dvv@hq.demos.su> + jon@console.ais.org (Jon Zeeff) + Eric Ziegast <ziegast@uunet.uu.net> + +------------------------------ + +End of UUCP Internals Frequently Asked Questions +****************************** +-- +Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message: +``You don't have to sleep. That's just something *they* tell you to keep + *control* over you. Nobody has to sleep; you're *taught* to sleep when + you're a kid. If you're really determined, you can get over it.'' diff --git a/share/FAQ/Text/ctm.FAQ b/share/FAQ/Text/ctm.FAQ new file mode 100644 index 0000000..9dc0d05 --- /dev/null +++ b/share/FAQ/Text/ctm.FAQ @@ -0,0 +1,191 @@ +# ---------------------------------------------------------------------------- +# "THE BEER-WARE LICENSE" (Revision 42): +# <phk@login.dknet.dk> wrote this file. As long as you retain this notice you +# can do whatever you want with this stuff. If we meet some day, and you think +# this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp +# ---------------------------------------------------------------------------- +# +# $Id: ctm.FAQ,v 1.6 1995/03/16 22:03:09 phk Exp $ +# + + Obtaining FreeBSD-current sources using CTM. + ============================================ + +CTM is a method for keeping a remote directory tree in sync with a +central one. It has been developed for usage with FreeBSD's source +trees, though other people may find it useful for other purposes as +time goes by. Little, if any, documentation currently exists at this +time on the process of creating deltas so talk to phk@FreeBSD.org for +more information should you wish to use CTM for other things. + + +Why should I use CTM ? +---------------------- +CTM will give you a local copy of the "FreeBSD-current" sources. If +you are an active developer on FreeBSD, but have lousy or non-existent +TCP/IP connectivity, CTM was made for you. You will need to transfer +up to four deltas per day (or you can have them arrive in email +automatically), the sizes for which are always kept as small as +possible. This is typically less than 5K, with the occasional (one in +ten) being 10-50K and every now and then a biggie of 100K+ or more +coming around. + +You will also need to make yourself aware of the various caveats in +running "current" sources, and for this it is recommended that you +refer to the relevant FAQ: /usr/share/FAQ/current-policy.FAQ + + +What do I need to use CTM? +-------------------------- + +You will need two things: The "ctm" program and the initial deltas to +feed it (to get up to "current" levels). + +The ctm program is in the FreeBSD-current tree from version 2.0.0 and +forward (/usr/src/usr.sbin/ctm). If you are running an older version +of FreeBSD, you can fetch the current ctm sources directly from: + + ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/ + +The "deltas" you feed ctm can be had two ways, ftp or email. If you +have general ftp access to the Internet, then the following ftp sites +support access to CTM: + + ftp://freefall.cdrom.com/pub/CTM + +Ftp the the relevant directory and fetch the README file, starting +from there. + +If you only have access to electronic mail or are otherwise blocked +from using ftp, then you may wish to receive your deltas via email: + +Send email to majordomo@freebsd.org to subscribe to the list +"ctm-src-cur" (if you do not know how to subscribe yourself using +majordomo, send a message first containing the word `help' - it will +send you back usage instructions). + +When you begin receiving your CTM updates in the mail, you may use the +ctm_rmail program to unpack and apply them with. You can actually use +the ctm_rmail program directly from a entry in /etc/aliases if you +want. Check the "ctm_rmail" man page for more details. + +NOTE: +----- + +No matter what method you use to get the CTM deltas, you should subscribe +to the ctm-announce@freebsd.org mailing list. In the future this will be +the only place where announcements about the operation of the CTM system +will be posted. Send an email to majordomo@freebsd.org with a single +line of "subscribe ctm-announce" to get added to the list. + + +Starting off with CTM for the first time: +----------------------------------------- + +Before you can start using CTM deltas, you will need to get a special +"base" delta that provides a starting point for all deltas produced +subsequently to it. + +You can recognize a base delta by the 'A' appended to the number +(src-cur.0341A.gz for instance). As a rule a base delta is produced +every 100 deltas, the next one will be src-cur.0400A.gz. +By the way, they are large! 25 to 30 Megabytes of gzip'ed data is +common for a base delta. + +If you do have the 2.0-RELEASE srcdist, you can instead retreive the +src-cur.0372R20.gz file, it's only 4Mb and it will take you to current +from the 2.0-RELEASE sources. + +Once you've picked a base delta to start from, you will also need all +deltas with higher numbers following it. + + +Using CTM in your daily life: +----------------------------- + +To apply the deltas, simply say + + cd /where/ever/you/want/the/stuff + ctm -v -v /where/you/store/your/deltas/src-cur.* + +CTM understands deltas which have been put through gzip, so you don't +need to gunzip them first, this saves diskspace. + +Unless it feels very secure about the entire process, ctm will not +touch your tree. To check out a delta you can also use the "-c" flag +and CTM won't actually touch your tree, but only check the integrity +of the delta, and see if it would apply cleanly to the tree. + +There are other options to ctm as well, look in the sources. + +I would also be very happy if somebody could help with the "user +interface" portions, as I have realized that I can't make up my mind +on what options should do what, how and when... + +That's really all there is to it. Everytime you get a new delta, you +run it through ctm. + +Don't remove the deltas, if they are hard to download again. You just +might want to keep them around in case something bad happens. Even if +you only have floppy disks, consider using "fdwrite" to make a copy. + + +Plans: +------ + +Tons of them: + + - Make local modifications to the tree possible. One way to do it + could be this: + When CTM wants to edit the file "foo/bar.c", it would first check + for the existense of "foo/bar.c#ctm" If this file exists, the + delta is applied to it instead. This way the foo/bar.c file can + be edited to suit local needs. + - Make a "restore file(s)" option to ctm, something like: + ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.* + would restore wd.c to the current status from the files. + - Clean up the options to ctm, they became confusing and + counter intuitive. + +The bad news is that I am very busy, so any help in doing this will be +most welcome. And don't forget to tell me what you want also... + + +Misc. stuff: +------------ + +All the "DES infected" (e.g. export controlled) source is not included. +You will get the "international" version only. If sufficient interest +appears, we will set up a "sec-cur" sequence too. + +If you are a frequent or valuable contributor to FreeBSD, I will be +willing to arrange special services, one option is delivery via ftp or +rcp to a machine closer to you. You need to have earned this, since +it takes time to do, but I'll be all the more happy to do it for you +then. + +There is a sequence of deltas for the ports collection too, but interest +has not been all that high yet. Tell me if you want an email list for +that too and we'll consider setting it up. + +If you have commit priviledges or are similary authorized by the +FreeBSD core team, you can also get access to the CVS repository tree +by the same means. Contact me (phk@FreeBSD.org) for details. + + +Thanks! +------- + +Bruce Evans, for his pointed pen and invaluable comments. +Soren Schmidt, for patience. +Stephen McKay, wrote ctm_[rs]mail, much appreciated. +Jordan Hubbard, for being so stubborn that I had to make it better. +All the users, I hope you like it... + +Comments ? +---------- + +email phk@FreeBSD.org + + +Poul-Henning diff --git a/share/FAQ/Text/current-policy.FAQ b/share/FAQ/Text/current-policy.FAQ new file mode 100644 index 0000000..dd61dbd --- /dev/null +++ b/share/FAQ/Text/current-policy.FAQ @@ -0,0 +1,170 @@ + THE FREEBSD CURRENT POLICY + +Last updated: $Date: 1995/02/27 08:25:50 $ + +This document attempts to explain the rationale behind FreeBSD-current, +what you should expect should you decide to run it, and states some +prerequisites for making sure the process goes as smoothly as possible. + + +1. What is FreeBSD-current? + +FreeBSD-current is, quite literally, nothing more than a daily snapshot of +the working sources for FreeBSD. These include work in progress, experimental +changes, and transitional mechanisms that may or may not be present in +the next official release of the software. While many of us compile +almost daily from FreeBSD-current sources, there are periods of time when +the sources are literally uncompilable. These problems are generally resolved +as expeditiously as possible, but whether or not FreeBSD-current sources bring +disaster or greatly desired functionality can literally be a matter of which +part of any given 24 hour period you grabbed them in! Please read on.. + +Under certain circumstances we will sometimes make binaries for parts of +FreeBSD-current available, but only because we're interested in getting +something tested, not because we're in the business of providing binary +releases of current. If we don't offer, please don't ask! It takes far +too much time to do this as a general task. + + +2. Who needs FreeBSD-current? + +FreeBSD-current is made generally available for 3 primary interest groups: + + 1. Members of the FreeBSD group who are actively working on one + part or another of the source tree and for whom keeping `current' + is an absolute requirement. + + 2. Members of the FreeBSD group who are active ALPHA/BETA testers + and willing to spend time working through problems in order to + ensure that FreeBSD-current remains as sane as possible. These + are also people who wish to make topical suggestions on changes + and the general direction of FreeBSD. + + 3. Peripheral members of the FreeBSD (or some other) group who merely + wish to keep an eye on things and use the current sources for + reference purposes (e.g. for *reading*, not running). These + people also make the occasional comment or contribute code. + + +3. What is FreeBSD-current _NOT_? + + 1. A fast-track to getting pre-release bits because there's something + you heard was pretty cool in there and you want to be the first on + your block to have it. + + 2. A quick way of getting bug fixes. + + 3. In any way "officially supported" by us. + + We do our best to help people genuinely in one of the 3 + "legitimate" FreeBSD-current catagories, but we simply DO NOT + HAVE THE TIME to help every person who jumps into FreeBSD-current + with more enthusiasm than knowledge of how to deal with + experimental system software. This is not because we're mean and + nasty people who don't like helping people out (we wouldn't even be + doing FreeBSD if we were), it's literally because we can't answer + 400 messages a day AND actually work on FreeBSD! I'm sure if + given the choice between having us answer lots of questions or + continue to improve FreeBSD, most of you would vote for us + improving it (and so would we! :-). + + +4. Ok. I still think I "qualify" for FreeBSD-current, so what do I do? + + 1. Join the freebsd-hackers and freebsd-commit mailing lists. + This is not just a good idea, it's ESSENTIAL. If you aren't on + freebsd-hackers, you won't read the comments that people are + making about the current state of the system and thus will end + up stumbling over a lot of problems that others have already + found and solved. Even more importantly, you will miss out on + potentially critical information (e.g. "Yo, Everybody! Before you + rebuild /usr/src, you MUST rebuild the kernel or your system + will crash horribly!"). + + The freebsd-commit list will allow you to see the commit log + entry for each change as its made. This can also contain + important information, and will let you know what parts of the + system are being actively changed. + + To join these lists, send mail to `majordomo@FreeBSD.ORG' + and say: + + subscribe freebsd-hackers + subscribe freebsd-commit + + In the body of your message. Optionally, you can also say `help' + and MajorDomo will send you full help on how to subscribe and + unsubscribe to the various other mailing lists we support. + + 2. Grab the sources from ftp.FreeBSD.ORG. You can do this in + three ways: + + 1. Using the CTM facility. Read the ctm.FAQ file for more + information. Unless you have a good TCP/IP connection at + a flat rate, this is the way to do it. + + 2. Use the CMU `sup' program (Software Update Protocol). + This is the second most recommended method, since it allows + you to grab the entire collection once and then only what's + changed from then on. Many people run sup from cron + and keep their sources up-to-date automatically. + + The problem is that sup does not use the bandwidth efficient, + unless the round-trip is very fast. If the cost of connection + or the duration of the session is a concern, use CTM. + + To get a binary of the sup program for FreeBSD, as well + as the documentation and some sample configuration files, + look in: + + FreeBSD.ORG:~ftp/pub/sup + + 3. Use ftp. The source tree for FreeBSD-current is always + "exported" on: + + ftp.FreeBSD.ORG:~ftp/pub/FreeBSD/FreeBSD-current + + We use `wu-ftpd' which allows compressed/tar'd grabbing + of whole trees. e.g. you see: + + usr.bin/lex + + You can do: + + ftp> cd usr.bin + ftp> get lex.tar.Z + + And it will get the whole directory for you as a compressed + tar file. + + 3. If you're grabbing the sources to run, and not just look at, + then grab ALL of current, not just selected portions. The + reason for this is that various parts of the source depend on + updates elsewhere and trying to compile just a subset is almost + guaranteed to get you into trouble. + + 4. Before compiling current, read the Makefile in /usr/src + carefully. You'll see one-time targets like `bootstrapld' + which *MUST* be run as part of the upgrading process. Reading + freebsd-hackers will keep you up-to-date on other bootstrapping + procedures that sometimes become necessary as we move towards + the next release. + + 5. Be active! If you're running FreeBSD-current, we want to know + what you have to say about it, especially if you have suggestions + for enhancements or bug fixes. Suggestions with accompanying code + are received most enthusiastically! :-) + + +Thank you for taking the time to read this all the way through. We're +always very keen to remain "open" and share the fruits of our labor +with the widest possible audience, but sharing development sources has +always had certain pitfalls associated with it (which is why most +commercial organizations won't even consider it) and I want to make +sure that people at least come into this with their eyes open, and +don't make the leap unless they're good at working without a net! + + Jordan + + + diff --git a/share/FAQ/Text/diskspace.FAQ b/share/FAQ/Text/diskspace.FAQ new file mode 100644 index 0000000..b696f1c --- /dev/null +++ b/share/FAQ/Text/diskspace.FAQ @@ -0,0 +1,267 @@ + How to assign disk space to FreeBSD. + +$Id: diskspace.FAQ,v 1.2 1995/01/03 15:54:02 gclarkii Exp $ + +1.0 Getting started. +--------------------- + +After a general introduction, you will find some explanation on what you +need to do to assign space to FreeBSD on your disk(s). This is done +through the "sysinstall" program, which lives on the inital boot floppy. +Those already expert with PCs may wish to skip ahead to section 1.2, the +rest of you may (or may not) enjoy the brief history lesson. + + +1.1 The ins and outs of allocating disk storage on your PC. +------------------------------------------------------------ + +Modern hard disk drives are now getting big enough that people don't want +to allocate all of one to just one operating system anymore, especially +given the increasing size of disk drives (the latest 9.0 Gbyte models +holding the equivalent of some six thousand 1.44MB floppies!) and the +virtual explosion of operating system options available for the PC. To +solve this problem, IBM came up with a scheme for "slicing" the disks +into more manageable chunks, or partitions. It works, but only just. +To better understand why, first a brief bit of history: + +MS-DOS, when hard disk support was unceremoniously grafted on back in the +late eighties, didn't have such "slices". What it had was a way to install +Xenix and MS-DOS on the same disk (Remember when Microsoft were in the UNIX +business?). + +In the first sector on the disk was a piece of "primary boot code" and a +table with four entries. Each of those entries pointed at an arbitrary +slice of the disk, with one of them was marked "active". The machine would +boot by reading the first sector containing the boot code into RAM and then +jumping to it. The job of this small piece of boot code was to look at +the 4 entry table and decide which OS was to be booted by looking +for the "active" flag. It would go and load the first sector of that slice +of the disk into RAM and then and jump to it in turn. This bit of boot +code was called the "secondary boot", and could be specific to a given +operating system. The primary boot code and 4-entry table is known +as the Master Boot Record, or MBR, and is very important to the proper +operation of your PC! We will discuss the MBR in more detail later. + +It was later realized, with the hindsight that IBM is famous for, that disks +could be bigger than the 32Mb that the early DOS FAT-12 file system could +handle, so they added a kludge: They had two MSDOS slices, a "Primary" and +a "Secondary". The primary could still only be 32Mb, but the Secondary had +no size limit. And the trick was that the secondary had ANOTHER "table +entry" so that now suddenly up to 5 slices could be available to MS-DOS. +The Secondary boot record was later made recursive, thus effectively +avoiding any fixed limit. Of course, they were still stuck with a maximum +of 26 slices given the use of "drive letters" in DOS. They also reserved +only 10 bits for cylinder addressing, limiting DOS to being able to address +a maximum of 1024 cylinders (and cause of the dreaded "cylinder translation" +kludges, the misconfiguration of which many users have seen as the notorious +"Missing Operating System" message). Yes, truly DOS was and is an utterly +terrible operating system, which of course explains its amazing degree of +success. Anyway, this all brings us up to today, which is where FreeBSD +comes in: + + +1.2 What FreeBSD does +---------------------- +FreeBSD has, like any other UNIX-like operating system, the concept of +"partitions." Partitions are used to implement its own "slicing" +abstraction, and although there is no real difference between a slice and a +partition as such, we use the two words to distinguish between these two +different levels of slicing. + +The result is that we have a two-tier structure on the disk: + ++-----------+ +| MBR-table | ++-----------+ +---------+ +| Slice 1 | -----> | MSDOS | ++-----------+ +---------+ +| Slice 2 | ++-----------+ +-------------------+ +| Slice 3 | -----> | FreeBSD-disklabel | ++-----------+ +-------------------+ +-----------------+ +| Slice 4 | | Partition A | -----> | Root-filesystem | ++-----------+ +-------------------+ +-----------------+ + | Partition B | --- + +-------------------+ \ +----------------+ + | Partition C | --> | swap-partition | + +-------------------+ +----------------+ + | ... | + + +Here are the rules that FreeBSD plays by: + +A: FreeBSD always has an MBR slice with type 0xa5 (each of the 4 slices can + also have a unique integer identifier so you can tell your DOS slices + from your FreeBSD slices from your Linux slices, etc). This means that + there should always be an MBR record, even in the case where FreeBSD + occupies the entire disk. +B: The FreeBSD slice contains the FreeBSD disklabel in the second sector + (remember, the first sector contains the secondary boot code for FreeBSD, + which is what prints that FreeBSD prompt at you when you first boot + FreeBSD from a floppy or hard disk). +C: The 'C' partition in the FreeBSD disklabel corresponds to the entire + FreeBSD slice. +D: The 'D' partition corresponds to the entire physical disk. +E: Should a disk not have a FreeBSD slice (because there simply is no + FreeBSD on it anywhere), then the MBR slices are mapped into partitions + 'E' to 'H' of an artificially created FreeBSD disklabel. This is useful + for getting at DOS-only disks. + +Therefore, to get FreeBSD onto your disk, you need to do the following: + + Step FreeBSD utility + ------------------------------------------------------------ --------------- + 1. Make an MBR slice for FreeBSD (FDISK) + 2. Partition the diskspace in the MBR slice into partitions (DISKLABEL) + 3. Assign mountpoints to the partitions. (DISKLABEL) + + + +2. The sysinstall utility +-------------------------- + +The sysinstall utility is the program you first see when you boot +FreeBSD's install floppy. It is responsible for partitioning your +disk, creating an MBR slice for FreeBSD, setting up the disklabel +within that slice and creating filesystems for each FreeBSD partition +you create within that slice. It is composed of a number of screens. +These are described below. + + +2.1 The main screen +-------------------- +The main screen shows you the current status, It shows you which disks +FreeBSD has found, how big they are and how much of it is assigned to +FreeBSD in a FreeBSD MBR slice. It also shows the partitions which have +had a mountpoint assigned to them (not necessarily FreeBSD partitions; +FreeBSD is perfectly capable of mounting DOS disks directly). + +(H)elp -- shows you this file. + +(F)disk -- enters the Fdisk editor, where you can change the MBR record. + This is what you want to use to assign some part of the disk to FreeBSD. + +(D)isklabel -- enters the Disklabel editor, here you can change how the + FreeBSD slice is partitioned for FreeBSD. + +(P)rocede -- will continue the installation process. + +(Q)uit -- Go back to the entry screen. + + +2.2 FDISK - how to make an MBR slice +------------------------------------- +There are some rules to follow here since altering your MBR is a potential +minefield. There is really no way for the sysinstall program to genuinely +know that you have a valid MBR, so you have to be extra careful in what +you edit. Failure to do this properly can and will destroy your other +operating system entries! + +Even if you don't plan to have MSDOS on a disk, make an MSDOS slice +using the MSDOS's FDISK.COM program. The reason for this is that if you +do it that way, you are 100% sure that FreeBSD will use the same number +of heads, sectors and cylinders as MSDOS would use. If you really don't +plan to have MSDOS on the disk, just (D)elete the slice in the FreeBSD's +(F)disk editor. + +From the main screen press 'F' to enter the MBR editor. You have five +commands available: + +(H)elp -- Shows you this file. + +(D)elete -- Deletes a slice entirely. + +(E)dit -- Allows you to edit a slice. It will ask how many megabytes + you want to assign to the slice, and will suggest the maximum possible + as a default. It might say zero, even though there is disk space + available, in which case you will probably need to delete and recreate the + other partitions to get it to see where the free space is. + It will then ask you what type to give the slice, for which the default is + 0xa5 (a FreeBSD slice). You can enter any other number here too, which + can be useful as a placeholder for some other OS you plan to install + later. Finally, it will ask you about the "boot flag". 0x80 means "boot + from this" slice by default, and anything else means "don't". + + If you specified a FreeBSD slice, any existing slices with the 0xa5 + type will be reset to 0x00 "unused". FreeBSD only supports one slice + per disk for FreeBSD. + +(R)eread -- This is your "undo" function. It will read the data of the + disk again, disposing of any changes you may have made. + +(W)rite -- When you are satisfied with the data, this function will write + the new MBR to the disk. + +(Q)uit -- Go back to the main screen. + + +2.3 Disklabel - How to divide up the FreeBSD slice. +---------------------------------------------------- + +The disklabel screen provides the following commands: + +(H)elp -- Shows you this file. + +(S)ize -- Resizes a partition for you, it will suggest as a default the + maximum amount of diskspace it can find. This algorithm isn't too smart + and may say zero, even though there is diskspace available. If it + does, delete and resize the other partitions. + +(A)ssign -- Here you assign where the filesystem in a partition is to + be mounted. `b' partitions will always be made into "swap" partitions. + +(D)elete -- Delete a partition. + +(R)eread -- The undo function. It will reread the current disklabel from + the kernel. + +(W)rite -- This will write the disklabel to the disk. You must always write + before you quit, otherwise your changes will be lost. + +(Q)uit -- Exit back to the main screen. + + +2.4. Hints on partition sizing +------------------------------- + +While it's impossible to say how much space you're going to want to +make your various partitions without knowing more about your intended +applicatins, here are some good rules of thumb to follow: + +1. Root (/) should be at least 18MB, and probably no more than 50MB unless + you have some special reason for making your root partition really + large. Remember that the root filesystem is only supposed to contain + vital system files and little else. + +2. Swap should be at least 2*memory. That is to say if you have 8MB of + memory, then you probably want 16MB of swap. Even more swap space + certainly doesn't hurt, if you can afford to allocate it, and you should + also think ahead a little to any planned memory upgrades you may have + in mind since increasing this later can be very painful! + + If you're going to run the X Window System (XFree86), you should also + consider having a *minimum* of 16MB of swap, since X tends to really + use it up. + +3. /usr can take up the rest of your disk, though some people like to create + extra partitions for user home directories and the like. Be sure to make + your /usr big enough to contain the system software (about 50MB) and + perhaps some of your own, unless you're going to use symbolic links to + point things like /usr/local (or /usr/src) somewhere else. + + +Here are some suggested filesystem names and sizes, just for reference: + +Mountpoint Filesystem size +------------------------------- +/var 10Mb +/usr 50Mb +/ 16Mb + +/usr/src 120Mb If you want to have the sources online +/usr/obj 100Mb If you want to compile all of them at one time + +/usr/X11R6 50Mb If you load the entire XFree86 binary kit. + + +$Id: diskspace.FAQ,v 1.2 1995/01/03 15:54:02 gclarkii Exp $ diff --git a/share/FAQ/Text/kernel-debug.FAQ b/share/FAQ/Text/kernel-debug.FAQ new file mode 100644 index 0000000..9215b26 --- /dev/null +++ b/share/FAQ/Text/kernel-debug.FAQ @@ -0,0 +1,417 @@ + Kernel debugging FAQ for FreeBSD + +$Id: kernel-debug.FAQ,v 1.4 1995/01/03 15:54:03 gclarkii Exp $ + + +*** Debugging a kernel crash dump with kgdb *** + + Here are some instructions for getting kernel debugging working on a + crash dump, it assumes that you have enough swap space for a crash + dump. If you happen to have multiple swap partitions with the first + one being too small to keep the dump, you can configure your kernel to + use an alternate dump device (in the ``kernel'' line). Dumps to non- + swap devices (e.g. tapes) are currently not supported. + + Config your kernel using config -g + + Remember that you need to specify ``options DODUMP'' in your config + file in order to get kernel core dumps. + + When the kernel's been built make a copy of it, say kernel.debug, and + then run strip -x on the original. Install the original as normal. + You may also install the unstripped kernel, but symtab lookup time + for some programs might drastically increase. + + If you are testing a new kernel (e.g. by typing the new kernel's + name at the boot prompt), but need to boot a different one in order + to get your system up & running again, do boot it only into single + user state (the -s flag at the boot prompt), and then perform the + following steps: + + fsck -p + mount -a -t ufs # so your file system for /var/crash is writable + savecore -N /kernel.panicked /var/crash + exit # ...to multi-user + + This instructs savecore to use another kernel for symbol name + extraction; it would default to the currently running kernel + otherwise. + + Now, after a crash dump, go to /sys/compile/WHATEVER and run + kgdb. From kgdb do: + + symbol-file kernel.debug + exec-file /var/crash/system.0 + core-file /var/crash/ram.0 + + and voila, you can debug the crash dump using the kernel sources + just like you can for any other program. + + If your kernel panicked due to a trap (perhaps the most common case + for getting a core dump), the following trick might help you. Examine + the stack (`where') and look for the stack frame in the function + trap(). Go `up' to that frame, and then type: + + frame frame->tf_ebp frame->tf_eip + + This will tell kgdb to go to the stack frame explicitly named by a + frame pointer and instruction pointer, which is the location where + the trap occured. There are still some bugs in kgdb (you can go + `up' from there, but not `down'; the stack trace will still remain + as it was before going to here), but generally this method will lead + you much closer to the failing piece of code. + + Here's a script log of a kgdb session illustrating the above. Long + lines have been folded to improve readability, and the lines are + numbered for reference. Despite of this, it's a real-world error + trace taken during the development of the pcvt console driver. + + 1:Script started on Fri Dec 30 23:15:22 1994 + 2:uriah # cd /sys/compile/URIAH + 3:uriah # kgdb kernel /var/crash/vmcore.1 + 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done. + 5:IdlePTD 1f3000 + 6:panic: because you said to! + 7:current pcb at 1e3f70 + 8:Reading in symbols for ../../i386/i386/machdep.c...done. + 9:(kgdb) where + 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) + 11:#1 0xf0115159 in panic () + 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) + 13:#3 0xf010185e in db_fncall () + 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) + 15:#5 0xf0101711 in db_command_loop () + 16:#6 0xf01040a0 in db_trap () + 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) + 18:#8 0xf019d2eb in trap_fatal (...) + 19:#9 0xf019ce60 in trap_pfault (...) + 20:#10 0xf019cb2f in trap (...) + 21:#11 0xf01932a1 in exception:calltrap () + 22:#12 0xf0191503 in cnopen (...) + 23:#13 0xf0132c34 in spec_open () + 24:#14 0xf012d014 in vn_open () + 25:#15 0xf012a183 in open () + 26:#16 0xf019d4eb in syscall (...) + 27:(kgdb) up 10 + 28:Reading in symbols for ../../i386/i386/trap.c...done. + 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ + 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ + 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ + 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ + 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ + 34:ss = -266427884}) (../../i386/i386/trap.c line 283) + 35:283 (void) trap_pfault(&frame, FALSE); + 36:(kgdb) frame frame->tf_ebp frame->tf_eip + 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. + 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ + 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) + 40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); + 41:(kgdb) list + 42:398 + 43:399 tp->t_state |= TS_CARR_ON; + 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ + 45:401 + 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) + 47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); + 48:404 #else + 49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); + 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ + 51:407 } + 52:(kgdb) print tp + 53:Reading in symbols for ../../i386/i386/cons.c...done. + 54:$1 = (struct tty *) 0x1bae + 55:(kgdb) print tp->t_line + 56:$2 = 1767990816 + 57:(kgdb) up + 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ + 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) + 60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); + 61:(kgdb) up + 62:#2 0xf0132c34 in spec_open () + 63:(kgdb) up + 64:#3 0xf012d014 in vn_open () + 65:(kgdb) up + 66:#4 0xf012a183 in open () + 67:(kgdb) up + 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ + 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ + 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ + 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ + 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) + 73:673 error = (*callp->sy_call)(p, args, rval); + 74:(kgdb) up + 75:Initial frame selected; you cannot go up. + 76:(kgdb) quit + 77:uriah # exit + 78:exit + 79: + 80:Script done on Fri Dec 30 23:18:04 1994 + + Comments to the above script: + + line 6: this is a dump taken from within DDB (see below), hence the + panic comment ``because you said to!'', and a rather long + stack trace; the initial reason for going into DDB has been + a page fault trap though + + line 20: the location of function ``trap()'' in the stack trace + + line 36: force usage of a new stack frame, kgdb responds and displays + the source line where the trap happened; from looking at the + code, there's a high probability that either the pointer + access for ``tp'' was messed up, or the array access was + out of bounds + + line 52: the pointer looks suspicious, but happens to be a valid + address... + + line 56: ... but obviously points to garbage, so we have found our + error, sigh! [For those uncommon with that particular piece + of code: tp->t_line refers to the line discipline of the + console device here, which must be a rather small integer + number.] + + + +*** Post-mortem analysis of a dump *** + + What to do if a kernel dumped core but you didn't expect it, and it's + therefore not compiled using config -g? + + Not everything is lost here. Don't panic. :-) + + Of course, you still need to configure all your kernels with the + DODUMP option being set, otherwise you won't get a core dump at all. + (This is for safety reasons in the default kernels, to avoid them + trying to dump e.g. during system installation where there's no + FreeBSD partition at all and valuable data on the disk could be + destroyed.) + + Go to your kernel compile directory, and edit the line containing + COPTFLAGS?=-O. Add the `-g' option there (but DON'T change anything + on the level of optimization). If you do already know roughly the + probable location of the failing piece of code (e.g., the `pcvt' + driver in the example above), remove all the object files for this + code. Rebuild the kernel. Due to the time stamp change on the + Makefile, there will be some other object files rebuild, e.g. + trap.o. With a bit of luck, the added -g option won't change + anything for the generated code, so you'll finally get a new kernel + with similiar code to the faulting one but some debugging symbols. + You should at least verify the old and new sizes with the `size' + command; if they mismatch, you probably need to give up here. + + Go and examine the dump as described above. The debugging symbols + might be incomplete for some places (as can be seen in the stack trace + in the example above: some functions are displayed without line + numbers and argument lists). If you need more debugging symbols, + remove the appropriate object files and repeat the kgdb session until + you know enough. + + All this is not guaranteed to work, but most likely will do it fine. + + + +*** On-line kernel debugging using DDB *** + + While kgdb as an offline debugger provides a very high level of user + interface (e.g. it can lookup source files, display C structures + etc.), there are some things it cannot do. The most important ones + being breakpointing and single-stepping kernel code. + + If you need to do low-level debugging on your kernel, there's an on- + line debugger available called DDB. It allows to set breakpoints, + single-step kernel functions, examine and change kernel variables + etc. It can however not access kernel source files, and it does + only have access to the global and static symbols, but not to the + full debug information (including type and line number information) + like kgdb. + + To configure your kernel to include DDB, add the option lines + + options DDB + options "SYMTAB_SPACE=XXXX" + + to your config file, and rebuild. XXXX is the amount of space to be + reserved into a global array DDB examines to find its symbols at run + time. It must be large enough to hold all symbols, but not too + large at all to avoid wasting space. 100000 Bytes are a good first + bet for a ``normal'' kernel. The link stage will tell you about the + usage of the symtab space, you'll see something like: + + dbsym: need 98765; avail 100000 + + If the amount of allocated space has been too small, the above + message is accompanied by the following error message: + + not enough room in db_symtab array + + and the link stage fails. You then need to increase the number, + reconfig and recompile. If your config(8) has been compiled to not + remove the old compile directory before continuing (this is a + compile-time option [CONFIG_DONT_CLOBBER]), you need to remove + db_aout.o prior to recompilation; this is the only file being + affected by the SYMTAB_SPACE option. + + + Once your DDB kernel is running, there are several ways to enter + DDB. The first (and most early) way is to set the boot flag `-d' + (right at the boot prompt). The kernel will start up in debug mode + and enter DDB prior to any device probing. Hence you are able to + even debug the device probe/attach functions. + + The second scenario is a hot-key on the keyboard, usually Ctrl-Alt- + ESC. (For syscons, this can be remapped, and some of the + distributed maps do this, so watch out.) There are patches + available for a COMCONSOLE kernel, ask me (joerg@FreeBSD.org) for + them. + + The third way is that any panic condition will branch to DDB if the + kernel is configured to use it. (Thus it is not wise to configure a + kernel with DDB for a machine running unattended.) + + + The DDB commands roughly resemble some gdb commands. The first you + probably need is to set a breakpoint: + + b function-name + b address + + Numbers are taken hexadecimal by default, but to make them distinct + from symbol names, hex numbers starting with the letters `a' - `f' + need to be preceded with `0x' (for other numbers, this is optional). + Simple expressions are allowed, e.g. ``function-name + 0x103''. + + To continue the operation of an interrupted kernel, simply type + + c + + To get a stack trace, use + + trace + + Note that when entering DDB via a hot-key, the kernel is currently + servicing an interrupt, so the stack trace might be not of much use + for you. + + If you want to remove a breakpoint, use + + del + del address-expression + + The first form will be accepted immediately after a breakpoint hit, + and deletes the current breakpoint. The second form can remove any + breakpoint, but you need to specify the exact address, as it can be + obtained from + + show b + + To single-step the kernel, try + + s + + This will step into functions, but you can make DDB trace them until + the matching return statement is reached by + + n + + NOTE: this is different from gdb's ``next'' statement, it's like + gdb's ``finish''. + + To examine data from memory, use e.g. + + x/wx 0xf0133fe0,40 + x/hd db_symtab_space + x/bc termbuf,10 + x/s stringbuf + + for word/halfword/byte access, and hexadecimal/decimal/character/ + string display. The number after the comma is the object count. + To display the next 0x10 items, simply use + + x ,10 + + Similiarly, use + + x/ia foofunc,10 + + to disassemble the first 0x10 instructions of foofunc, and display + them along with their offset from the beginning of foofunc. + + To modify the memory, use the write command: + + w/b termbuf 0xa 0xb 0 + w/w 0xf0010030 0 0 + + The command modifier (b/h/w) specifies the size of the data to be + writtten, the first following expression is the address to write to, + the remainder is interpreted as data to write to successive memory + locations. + + If you need to know the current registers, use + + show reg + + Alternatively, you can display a single register value by e.g. + + print $eax + + and modify it by + + set $eax new-value + + + Should you need to call some kernel functions from DDB, simply + say + + call func(arg1, arg2, ...) + + The return value will be printed. + + For a ps-style summary of all running processes, use + + ps + + + + Well, you've now examined why your kernel failed, and you wish to + reboot. Remember that, depending on the severity of previous + malfunctioning, not all parts of the kernel might still be working + as expected. Perform one of the following actions to shut down and + reboot your system: + + + call diediedie() + + (must usually be followed by another ``c[ontinue]'' statement), + will cause your kernel to dump core and reboot, so you can later + analyze the core on a higher level with kgdb. + + + call boot(0) + + might be a good way to cleanly shut down the running system, sync() + all disks, and finally reboot. As long as the disk and file system + interfaces of the kernel are not damaged, this might be a good way + for an almost clean shutdown. + + + call cpu_reset() + + ...is the final way out of the desaster, almost similiar to hitting + the Big Red Button. + + + +*** What to do if i want to debug a console driver? *** + + Since you need a console driver to run DDB on, things are more + complicated if the console driver itself is flakey. You might + remember the ``options COMCONSOLE'' line, and hook up a standard + terminal onto your first serial port. DDB works on any configured + console driver, of course it also works on a COMCONSOLE. + + + + Paul Richards, FreeBSD core team member. (paul@FreeBSD.org) + J"org Wunsch (joerg@FreeBSD.org) + diff --git a/share/FAQ/Text/mailing-list.FAQ b/share/FAQ/Text/mailing-list.FAQ new file mode 100644 index 0000000..881890f --- /dev/null +++ b/share/FAQ/Text/mailing-list.FAQ @@ -0,0 +1,105 @@ + THE FREEBSD MAILING LIST FAQ + +$Id: mailing-list.FAQ,v 1.5 1995/01/03 15:54:04 gclarkii Exp $ + +-- +Though many of the FreeBSD development members read USENET, we cannot +always guarantee that we'll get to your questions in a timely fashion +(or at all) if you post them only to one of the comp.os.386bsd.* +groups. By addressing your questions to the appropriate mailing list +you will reach both us and a concentrated FreeBSD audience, invariably +assuring a better (or at least faster) response. + +The following is a summary of the mailing lists: + +List Purpose +----------------------------------------------------------------------------- +freebsd-admim Administrative issues (limited) +freebsd-arch Architecture and design discussions (limited) +freebsd-bugs Bug reports +freebsd-hackers Technical discussions and suggestions +freebsd-questions User questions +freebsd-announce Important events / milestones +freebsd-current Discussions about the use of FreeBSD-current +freebsd-commit Commit messages to source repository +freebsd-core FreeBSD core team (limited) +freebsd-security Security issues +freebsd-fs Filesystems +freebsd-ports Discussion of "ports" +freebsd-platforms Porting to Non-Intel platforms +freebsd-hardware General discussion of FreeBSD hardware +freebsd-install Installation issues (limited) + +----------------------------------------------------------------------------- + +The following lists are for people seeing the log messages for source changes +in specific areas: + +List name Source area Area Description (source for) +----------------------------------------------------------------------------- +cvs-CVSROOT /usr/src/[A-Z]* Top level /usr/src file changes +cvs-all /usr/src All changes to the tree (superset) +cvs-bin /usr/src/bin System binaries +cvs-etc /usr/src/etc System files +cvs-games /usr/src/games Games +cvs-gnu /usr/src/gnu GPL'd utilities +cvs-include /usr/src/include Include files +cvs-kerberosIV /usr/src/kerberosIV Kerberos encryption code +cvs-lib /usr/src/lib System libraries +cvs-libexec /usr/src/libexec System binaries +cvs-sbin /usr/src/sbin System binaries +cvs-share /usr/src/share System shared files +cvs-sys /usr/src/sys Kernel +cvs-usrbin /usr/src/usr.bin Use binaries +cvs-usrsbin /usr/src/usr.sbin System binaries +cvs-ports /usr/ports Ported software +----------------------------------------------------------------------------- + +Even though the lists freebsd-core, freebsd-admin, freebsd-install and +freebsd-arch are closed, anyone is free to send suggestions and comments +to them. All other lists are open. + +All mailing lists live on `FreeBSD.ORG', so to post to a list you +simply mail to `<listname>@FreeBSD.ORG'. It will then be redistributed +to mailing list members throughout the world. + +To subscribe to a list, send mail to: + + majordomo@FreeBSD.ORG + +And include the keyword + + subscribe <listname> [<optional address>] + +In the body of your message. For example, to subscribe yourself to +freebsd-hackers, you'd do: + + % mail majordomo@FreeBSD.ORG + subscribe freebsd-hackers + ^D + +If you want to subscribe yourself under a different name, or submit a +subscription request for a local mailing list (note: this is more efficient +if you have several interested parties at one site, and highly appreciated by +us!), you would do something like: + + % mail majordomo@FreeBSD.ORG + subscribe freebsd-hackers local-hackers@somesite.com + ^D + +Finally, it is also possible to unsubscribe yourself from a list, get a +list of other list members or see the list of mailing lists again by +sending other types of control messages to majordomo. For a complete +list of available commands, do this: + + % mail majordomo@FreeBSD.ORG + help + ^D + +Finally, it is suggested that you only join the freebsd-hackers or +freebsd-questions mailing lists if you're also willing to see upwards +of 100 messages a day (peak)! If you're only interested in the "high points", +then it's suggested that you join freebsd-announce, which will contain +only infrequent traffic. + + Thank you! diff --git a/share/FAQ/Text/nfs.FAQ b/share/FAQ/Text/nfs.FAQ new file mode 100644 index 0000000..88c5fc5 --- /dev/null +++ b/share/FAQ/Text/nfs.FAQ @@ -0,0 +1,79 @@ +FreeBSD and NFS [for a FAQ] + +$Id: nfs.FAQ,v 1.2 1995/01/03 15:54:05 gclarkii Exp $ + +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 "wsize=1024" on the mount from the client. If the +FreeBSD system is the CLIENT, then mount the NFS file system with the +option "rsize=1024". These options may be specified using the fourth +field of the fstab entry on the client for automatic mounts, or by using +the "-o" parameter of the mount command for manual mounts. + +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 "hard" or +"soft" and "bg" may be desireable in your application. + +Examples for the FreeBSD system ("freebox") as the client: + in /etc/fstab on freebox: +fastws:/sharedfs /project nfs rw,rsize=1024 0 0 + as a manual mount command on freebox: +mount -t nfs -o rsize=1024 fastws:/sharedfs /project + +Examples for the FreeBSD system as the server: + in /etc/fstab on fastws: +freebox:/sharedfs /project nfs rw,wsize=1024 0 0 + as a manual mount command on fastws: +mount -t nfs -o wsize=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 guarranteed 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. +-- + John Lind, Starfire Consulting Services +E-mail: john@starfire.MN.ORG USnail: PO Box 17247, Mpls MN 55417 diff --git a/share/FAQ/Text/ports.FAQ b/share/FAQ/Text/ports.FAQ new file mode 100644 index 0000000..2a447ad --- /dev/null +++ b/share/FAQ/Text/ports.FAQ @@ -0,0 +1,246 @@ + The FreeBSD Ports FAQ file + +Revision: $Id: ports.FAQ,v 1.2 1995/01/06 19:24:13 gpalmer Exp $ + +The ports system is kinda new, so there haven't been too many FAQ's to +date, but hopefully this document will pre-empt (some|most) of them!! +The ports system is constantly changing, but hopefully this document +will be kept reasonably up to date (and you never know, it might even +make sense!). + + - Gary Palmer + & jkh + +1) What is a port? + + Unfortunately, there are more variations of UN*X than most people +know of, and hence not all software for UN*X available on the Internet +will work on all versions of UN*X (in fact, I can guarantee it!). +Hence, some software needs modifications to work under some UN*Xs. The +process of making those modifications is known as ``porting'' and the +result known as a ``port'' (not to be confused with the sockets on the +back of your computer!). + + +2) What is the FreeBSD Ports Collection? + + People who (allegedly) know what they are doing have automated the +process of ``porting'' software to FreeBSD, and the result is the +Ports Collection. The general idea is that a combination of various +programming tools available in the base FreeBSD installation will +allow you to fetch the port from a FreeBSD mirror site, type ``make'' +and get the fully working program. + + The ports collection itself normally doesn't have any of the +original source code necessary for the compilation in the tree, just +those shell scripts, Makefiles and source code ``diffs'' that are +necessary to compile the program under FreeBSD. This is meant to keep +the entire system down to a manageable size, and the current system +has over 100 ports in the master source tree, and yet a compressed tar +file of that tree is about 2 megabytes (all the source code needed is +over 100Mb's!). + + +3) How does the system compile with no source code? + + A ports' Makefile automatically looks in a central location on +your system (usually /usr/ports/distfiles, though this value can be +customized) for the associated set of original distribution files that +have been ``ported''. These are generally provided at various places +on the Internet, though if you have a CDROM distribution of FreeBSD +then you've already got them available on your CD for ease of use. +See section 3.1 if you have such a CD distribution, otherwise skip to +section 3.2. + +3.1 Compiling ports from CD + + Type something profound here. + +3.2 Compiling ports using an Internet connection + + The ports collection can also use an auto-fetch system to keep +your ports collection source tree up to date, updating the central +``distfiles'' version for you the next time you compile the port. + + Of course, this always assumes you have a permanent network link, +or don't mind heavy usage of your telephone. If you don't want heavy +network usage when you compile your ports tree, you can pre-fetch the +necessary tarballs beforehand and put them into /usr/ports/distfiles +(or wherever DISTDIR points) by hand. A good way to see what files a +port is going to need is to cd to that port's directory and do a +``make -n fetch'' to see what it does. + + You can also chose to get the source files either from the master +FTP site as defined in the relevant Makefile (in the MASTER_SITES +line), or some FreeBSD mirror site also carrying a set of distfiles, +as does the master FTP site on ftp.FreeBSD.org (aka ftp.cdrom.com) in +the directory /pub/FreeBSD/ports/distfiles. Note that the files in +that directory are not guarenteed to be kept up to date - this is a +volunteer project! We can't make any guarantees about the mirror +sites either - they are obviously under independant control and don't +even have to mirror the distfiles directory. + + If you have a non-permanant link, you can fetch all the distfiles by +going to the top of the tree and typing ``make fetch''. + + +4) It doesn't work?! + +Oh. You can do one of four (4) things : + +a) Fix it yourself. Technical details can be found in the GUIDELINES file, + available from URL ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES + +b) Gripe. This is done by e-mail *ONLY*! The people at Walnut Creek are + in no way responsible for the functionality (or lack thereof) of the + FreeBSD system as a whole, and especially the ports system, which + is mainly contributed by 3rd parties. (If you don't believe me, check + the catalogue, especially the line saying "We cannot offer tech-support + on this product") + + The e-mail address is Ports@FreeBSD.org. Please include details of + the port, where you got both the port source & distfile(s) from, and + what the error was. + + Note: At time of writing, lang/Sather doesn't seem to work on Pentium + machines due to the Intel Curse (aka the Floating Point Division Bug). + Please don't tell us about this - gripe to Intel instead - it's their + bug! + +c) Forget it. This is the easiest for most - very few of the programs in + ports can be classed as `essential'! + +d) Grab the pre-compiled package from a ftp server. The ``master'' package + collection is in: + ftp://ftp.FreeBSD.org/pub/FreeBSD/packages/ + + though check your local mirror first, please! + + These are more likely to work (on the whole) than trying to compile from + source, and a lot faster! + + +5) I've ported a program and I want to make a port out of it. What now? + + See the file GUIDELINES, in: + ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/GUIDELINES + + This contains details of the procedure and structure involved. + + +6) I've got a good port, what now? + + Upload the fixed version to freefall.cdrom.com /pub/incoming or +ftp.FreeBSD.org /pub/FreeBSD/incoming and send e-mail to +ports@FreeBSD.org with the filename and details. Someone on the +all-volunteer `ports committee' will (hopefully) look it over and +commit it to the ports collection if they like the looks of it. + + +7) Things go funny during the fetch stage of compilation! + + We know. Please don't blame us. There is a program called `ncftp' +which is used instead of the normal ftp as it can do so-called +``background'' or ``batch'' transfers, ideal for this situation. +Unfortunately it can do strange things, and has crashed at least one +machine (during circumstances stranger than most, I'll admit, but it +was still responsible). Hopefully a future release of ncftp will fix +these problems (it is not maintained by the main FreeBSD team, but a +third party, who is I believe aware of its shortcomings) + + +8) I want to leave the compile going overnight, but some ports don't + like this. + + There is a way around this. Before starting the compilation, type: + setenv BATCH yes # (if you use csh/tcsh) or + BATCH=yes # (for sh/bash) + + This should miss out ports which need user interaction. Unfortunately, +ncftp doesn't know about this trick, and can often screw up and ask +stupid questions in unattended batch mode. See (7). + + To compile those ports left out by doing the above, using a +different login shell (or unsetting the above BATCH variable), set the +INTERACTIVE variable instead (you can use the same statements as above +except replace ``BATCH'' with ``INTERACTIVE'') and re-run make. This +should now compile only those ports which will definitely ask for user +interaction. + + +9) The ports collection is weak. What can I do to help? + + First read the bsd.port.mk file (which may be found in +/usr/share/mk/) and the associated bsd.port.subdir.mk file. A lot of +the weirdness can be explained properly in there (most of the current +weirdness is due to the lack of assumptions about anything, which is +necessary due to the generic nature of these files). Also check that +you have an up-to-date copy, as the file can change from minute to +minute. A reasonably up-to-date copy can be found in: + + ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port* + + If you find that you still need to go in there and alter things, +by all means do so, and then send the diffs to ports@FreeBSD.org if +you'd like them to be a part of the default distribution. Please also +remember that any changes must respect backwards-compatability with +any and all older Makefiles, unless you want a real nightmare of +/usr/ports munging ahead of you! Large scale changes will generally +not be warmly welcomed unless all the existing makefiles work without +alteration. Sorry! + + +10) This FAQ is weak. What can I do? + + Send changes to ports@FreeBSD.org. Changes are most welcome! +This FAQ is also very green and should be considered no more than +a `good start' for now. Authors? You can come out of hiding any +time now! :-) + + +11) How do I get more information on all the ports? + + One good method is to cd to the top of the ports tree (say /usr/ports) +and type something like: + + make describe | sed -e '/===/D' -e 's;/usr/ports/;;' | expand -40 + +The ``make describe'' will try to extract the one-line description from +each port, and the ``sed'' will delete the extraneous output. ``expand'' +just makes it a little more readable (sort of - you may want to season +the output of this more to taste). + + +12) I've heard of a new checksum system. What is this for? + + For various reasons, when using FTP over the Internet to obtain the +source code, you may not always end up with the same copy of the code +that the origional porter worked from, and this can lead to problems. +So a simple checksumming system has been employed to try and highlight +problems in this area. + + To check the entire system, go to the top of the ports tree +(defaults to /usr/ports) and type + + make checksum + +This will give a report on the validity of the files you have FTP'd. If some +are missing, the system will attempt to retrieve them before running the +checksum routine. The same technique can be applied to a single port. + + The system will complain if there is no pre-computed checksum available +for that port. Not all ports currently have checksums, but this should be +cured soon. + + Some older versions of the system don't recognise the ``checksum'' +target. In that case, try the command + + make check-md5 + +(``check-md5'' was the pre-cursor to the ``checksum'' target). If neither +work, get the latest copies of bsd.port.mk and bsd.port.subdir.mk from + + ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/mk/bsd.port* + +and install them in /usr/share/mk. This will get you the latest version +of the ports system. diff --git a/share/FAQ/Text/ppp.FAQ b/share/FAQ/Text/ppp.FAQ new file mode 100644 index 0000000..46cc8bc --- /dev/null +++ b/share/FAQ/Text/ppp.FAQ @@ -0,0 +1,369 @@ + Info about setting up pppd daemon on FreeBSD-2.0 + +$Id: ppp.FAQ,v 1.2 1995/01/03 15:54:05 gclarkii Exp $ + +Before you start setting up PPP on your machine make +sure that pppd is located in /usr/sbin and directory /etc/ppp +exists. + +pppd can work in two modes: + +i) as a "client" , i.e. you want to connect your machine to outside +world via PPP serial connection or modem line. + +ii) as a "server" , i.e. your machine is located on the network and +used to connect other computers using PPP. + +In both cases you will need to set up an options file ( /etc/ppp/options +or ~/.ppprc if you have more then one user on your machine that uses +PPP ). + +You also will need some modem/serial software ( preferably kermit ) +so you can dial and establish connection with remote host. + +1) Working as a PPP client + +I used the following options to connect to CISCO terminal server PPP +line. + +----/etc/ppp/options------- +crtscts # enable hardware flow control +modem # modem control line +noipdefault # remote PPP server must supply your IP address. + # if the remote host doesn't send your IP during IPCP + # negotiation , remove this option +passive # wait for LCP packets +domain ppp.foo.com # put your domain name here + +:<remote_ip> # put the IP of remote PPP host here + # it will be used to route packets via PPP link + # if you didn't specified the noipdefault option + # change this line to <local_ip>:<remote_ip> + +defaultroute # put this if you want that PPP server will be your + # default router +------------------------- + +To connect: +i) Dial to the remote host using kermit ( or other modem program ) +enter your user name and password ( or whatever is needed to enable PPP +ont the remote host ) + +ii) Exit kermit. ( without hanging up the line ) + +iii) enter: +/usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 +( put the appropriate speed and device name ) + +Now your computer is connected with PPP. If the connection fails for some +reasons you can add the "debug" option to the /etc/ppp/options file +and check messages on the console to track the problem + +Following script will make all 3 stages automatically: +-----/etc/ppp/pppup-------- +#!/bin/sh +ps ax |grep pppd |grep -v grep +pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` +if [ "X${pid}" != "X" ] ; then + echo 'killing pppd, PID=' ${pid} + kill ${pid} +fi +ps ax |grep kermit |grep -v grep +pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` +if [ "X${pid}" != "X" ] ; then + echo 'killing kermit, PID=' ${pid} + kill -9 ${pid} +fi + +ifconfig ppp0 down +ifconfig ppp0 delete + +kermit -y /etc/ppp/kermit.dial +pppd /dev/tty01 19200 +----------------------------- + +/etc/ppp/kermit.dial is kermit script that dials and makes all +necessary authorization on the remote host. +( Example of such script is attached to the end of this document ) + +Use the follwing script to disconnect the PPP line: +-----/etc/ppp/pppdown-------- +#!/bin/sh +pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` +if [ X${pid} != "X" ] ; then + echo 'killing pppd, PID=' ${pid} + kill -TERM ${pid} +fi + +ps ax |grep kermit |grep -v grep +pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` +if [ "X${pid}" != "X" ] ; then + echo 'killing kermit, PID=' ${pid} + kill -9 ${pid} +fi + +/sbin/ifconfig ppp0 down +/sbin/ifconfig ppp0 delete +kermit -y /etc/ppp/kermit.hup +/etc/ppp/ppptest +------------------------------ + +Check if PPP is still running: + +-----/etc/ppp/ppptest--------- +#!/bin/sh +pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` +if [ X${pid} != "X" ] ; then + echo 'pppd running: PID=' ${pid-NONE} +else + echo 'No pppd running.' +fi +set -x +netstat -n -I ppp0 +ifconfig ppp0 +----------------------------- + +Hangs up modem line: + +-----/etc/ppp/kermit.hup----- +set line /dev/tty01 ; put your modem device here +set speed 19200 +set file type binary +set file names literal +set win 8 +set rec pack 1024 +set send pack 1024 +set block 3 +set term bytesize 8 +set command bytesize 8 +set flow none + +pau 1 +out +++ +inp 5 OK +out ATH0\13 +echo \13 +exit +---------------------------- + +2) Working as a PPP server + +------/etc/ppp/options------ +crtscts # Hardware flow control +netmask 255.255.255.0 # netmask ( not required ) +192.114.208.20:192.114.208.165 # ip's of local and remote hosts + # local ip must be different from one + # you assigned to the ethernet ( or other ) + # interface on your machine. + # remote IP is ip address that will be + # assigned to the remote machine +domain ppp.foo.com # your domain +passive # wait for LCP +modem # modem line +---------------------------- + +Following script will enable ppp server on your machine + +-----/etc/ppp/pppserv------- +#!/bin/sh +ps ax |grep pppd |grep -v grep +pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` +if [ "X${pid}" != "X" ] ; then + echo 'killing pppd, PID=' ${pid} + kill ${pid} +fi +ps ax |grep kermit |grep -v grep +pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` +if [ "X${pid}" != "X" ] ; then + echo 'killing kermit, PID=' ${pid} + kill -9 ${pid} +fi + +# reset ppp interface +ifconfig ppp0 down +ifconfig ppp0 delete + +# enable autoanswer mode +kermit -y /etc/ppp/kermit.ans + +# run ppp +pppd /dev/tty01 19200 +---------------------------- + +Use this script to stop ppp server: + +-----/etc/ppp/pppservdown--- +#!/bin/sh +ps ax |grep pppd |grep -v grep +pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` +if [ "X${pid}" != "X" ] ; then + echo 'killing pppd, PID=' ${pid} + kill ${pid} +fi +ps ax |grep kermit |grep -v grep +pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` +if [ "X${pid}" != "X" ] ; then + echo 'killing kermit, PID=' ${pid} + kill -9 ${pid} +fi +ifconfig ppp0 down +ifconfig ppp0 delete + +kermit -y /etc/ppp/kermit.noans +---------------------------- + +Following kermit script will enable/disable autoanswer mode +on your modem: + +-----/etc/ppp/kermit.ans---- +set line /dev/tty01 +set speed 19200 +set file type binary +set file names literal +set win 8 +set rec pack 1024 +set send pack 1024 +set block 3 +set term bytesize 8 +set command bytesize 8 +set flow none + +pau 1 +out +++ +inp 5 OK +out ATH0\13 +inp 5 OK +echo \13 +out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable + ; autoanswer mod +inp 5 OK +echo \13 +exit +----------------------------- + +This script is used for dialing and authorizing on remote host. +You will need to customize it for your needs. +Put your login and password in this script , also you'll need +to change input statement depending on responces from your modem +and remote host. + +-----/etc/ppp/kermit.dial---- + +; +; put the com line attached to the modem here: +; +set line /dev/tty01 +; +; put the modem speed here: +; +set speed 19200 +set file type binary ; full 8 bit file xfer +set file names literal +set win 8 +set rec pack 1024 +set send pack 1024 +set block 3 +set term bytesize 8 +set command bytesize 8 +set flow none +set modem hayes +set dial hangup off +set carrier auto ; Then SET CARRIER if necessary, +set dial display on ; Then SET DIAL if necessary, +set input echo on +set input timeout proceed +set input case ignore +def \%x 0 ; login prompt counter +goto slhup + +:slcmd ; put the modem in command mode +echo Put the modem in command mode. +clear ; Clear unread characters from input buffer +pause 1 +output +++ ; hayes escape sequence +input 1 OK\13\10 ; wait for OK +if success goto slhup +output \13 +pause 1 +output at\13 +input 1 OK\13\10 +if fail goto slcmd ; if modem doesn't answer OK, try again + +:slhup ; hang up the phone +clear ; Clear unread characters from input buffer +pause 1 +echo Hanging up the phone. +output ath0\13 ; hayes command for on hook +input 2 OK\13\10 +if fail goto slcmd ; if no OK answer, put modem in command mode + +:sldial ; dial the number +pause 1 +echo Dialing. +output atdt9,550311\13\10 ; put phone number here +assign \%x 0 ; zero the time counter + +:look +clear ; Clear unread characters from input buffer +increment \%x ; Count the seconds +input 1 {CONNECT } +if success goto sllogin +reinput 1 {NO CARRIER\13\10} +if success goto sldial +reinput 1 {NO DIALTONE\13\10} +if success goto slnodial +reinput 1 {\255} +if success goto slhup +reinput 1 {\127} +if success goto slhup +if < \%x 60 goto look +else goto slhup + +:sllogin ; login +assign \%x 0 ; zero the time counter +pause 1 +echo Looking for login prompt. + +:slloop +increment \%x ; Count the seconds +clear ; Clear unread characters from input buffer +output \13 +; +; put your expected login prompt here: +; +input 1 {Username: } +if success goto sluid +reinput 1 {\255} +if success goto slhup +reinput 1 {\127} +if success goto slhup +if < \%x 10 goto slloop ; try 10 times to get a login prompt +else goto slhup ; hang up and start again if 10 failures + +:sluid +; +; put your userid here: +; +output ppp-login\13 +input 1 {Password: } +; +; put your password here: +; +output ppp-password\13 +input 1 {Entering SLIP mode.} +echo +quit + +:slnodial +echo \7No dialtone. Check the telephone line!\7 +exit 1 + +; local variables: +; mode: csh +; comment-start: "; " +; comment-start-skip: "; " +; end: +------------------------ + +################################################################### +Gennady B. Sorokopud ( gena@NetVision.net.il ) 24/10/94 12:00 diff --git a/share/FAQ/Text/slip.FAQ b/share/FAQ/Text/slip.FAQ new file mode 100644 index 0000000..4baf38c --- /dev/null +++ b/share/FAQ/Text/slip.FAQ @@ -0,0 +1,192 @@ +*********************************************************************** +*** How to Set Up SLIP on FreeBSD *** +*********************************************************************** + +$Id: slip.FAQ,v 1.2 1995/01/03 15:54:06 gclarkii Exp $ + +Updated for 1.1.5(.1) support by Satoshi Asami, 8/6/94. + +The following is I (asami) set up my FreeBSD machine for SLIP on a +static host network. For dynamic hostname assignments (i.e., your +address changes each time you dial up), you probably need to do +something much fancier. + +This is just "what I did, and it worked for me". I'm sharing this +just for your reference, I'm no expert in SLIP nor networking so your +mileage may vary. + +Note: for 1.1 systems (not 1.1.5), you need to use /dev/tty01 instead +of /dev/cua01. substitute all the occurences of "cua" in this document +with "tty". + +Note: the default 1.1.5(.1) system only comes with cua/ttyd pairs for +the last two ports (2 and 3), so if your modem is at sio0/sio1 +(COM1/COM2), you need to make the devices. Try "cd /dev; sh MAKEDEV +cua01" to make the new special files for sio1 (ditto for sio0). This +will delete tty01, but you shouldn't need it anymore...or you can make +a symbolic link /dev/tty01 -> ttyd1 if you don't want to hunt down all +occurences of tty01 in your setup files. + +I actually have a symbolic link /dev/modem -> cua01 (and /dev/mouse -> +ttyd0). I use only the modem/mouse names in my configuration files. +This helped a lot when I switched from 1.1 to 1.1.5.1 (tty01 => cua01) +and when I had to move my modem temporarily to sio2 to enable the +RS-232C port on the serial card. It can become quite cumbersome when +you need to fix a bunch of files in /etc and .kermrc's all over the +system! + +First, make sure you have + +pseudo-device sl 2 + +in your kernel's config file. It is included in the GENERIC, GENERICAH +and GENERICBT kernels, so this won't be a problem unless you deleted it. + +Things you have to do only once: + +(1) Add your home machine, the gateway and nameservers to your + /etc/hosts file. Mine looks like this: + +127.0.0.1 localhost loghost +136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia + +136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway +128.32.136.9 ns1.Berkeley.edu ns1 +128.32.136.12 ns2.Berkeley.edu ns2 + + By the way, silvia is the name of the car that I had when I was + back in Japan (it's called 2?0SX here in U.S.). + +(2) Make sure you have "hosts" before "bind" in your /etc/host.conf. + Otherwise, funny things may happen. + +(3) Edit the /etc/netstart and add this to the end of the file: + +# set up slip +gateway=slip-gateway +ifconfig sl0 inet $hostname $gateway netmask 0xffffff00 +route add default $gateway + + Note that because of the "slip-gateway" entry in /etc/hosts, there + is no local dependency in the netstart file. Also, you might want + to un-comment the "route add $hostname localhost" line. + +(3') Make a file /etc/resolv.conf which contains: + +domain HIP.Berkeley.EDU +nameserver 128.32.136.9 +nameserver 128.32.136.12 + + As you can see, these set up the nameserver hosts. Of course, the + actual addresses depend on your environment. + +(4) Set the password for root and toor (and any other accounts that + doesn't have a password). Use passwd, don't edit the passwd or + passwd.master files! + +(5) Edit /etc/myname and reboot the machine. + +How to set up the connection: + +(6) Dial up, type "slip" at the prompt, enter your machine name and + password. The things you need to enter depends on your + environment. I use kermit, with a script like this: + +# kermit setup +set modem hayes +set line /dev/cua01 +set speed 57600 +set parity none +set flow rts/cts +set terminal bytesize 8 +set file type binary +# The next macro will dial up and login +define slip dial 643-9600, input 10 =>, if failure stop, - +output slip\x0d, input 10 Username:, if failure stop, - +output silvia\x0d, input 10 Password:, if failure stop, - +output ***\x0d, echo \x0aCONNECTED\x0a + + (of course, you have to change the hostname and password to fit + yours). Then you can just type "slip" from the kermit prompt to + get connected. + + Note: leaving your password in plain text anywhere in the + filesystem is generally a BAD idea. Do it at your own risk. I'm + just too lazy. + + Note: If you have an 1.1 machine, and kermit doesn't give you a + prompt, try "stty -f /dev/tty01 clocal". I put this in + /etc/rc.local so that it works the first time I boot the machine. + This doesn't apply to 1.1.5(.1) systems, as cua0? are already + configured for dialouts. + +(7) Leave the kermit there (you can suspend it by "z") and as root, + type + +slattach -h -c -s 57600 /dev/cua01 + + if you are able to "ping" hosts on campus, you are connected! + + If it doesn't work, you might want to try "-a" instead of "-c". + +(8) Happy slipping! + +How to shutdown the connection: + +(9) Type "ps gx" (as root) to find out the PID of slattach, and use + "kill -INT" to kill it. + + Then go back to kermit ("fg" if you suspended it) and exit from it + ("q"). + + The slattach man page says you have to use "ifconfig sl0 down" to + mark the interface down, but this doesn't seem to make any + difference for me. ("ifconfig sl0" reports the same thing.) + + Some times, your modem might refuse to drop the carrier (mine + often does). In that case, simply start kermit and quit it again. + It usually goes out on the second try. + + When you want to connect again, go back to (6). You may have to + watch out for clocal mode. If "stty -f /dev/tty01" doesn't tell + you it's clocal, you need to re-set it before kermitting. Again, + this is only for 1.1 machines. + +TROUBLESHOOTING: + +If it doesn't work, feel free to ask me. The things that people +tripped over so far: + +* Not using "-c" or "-a" in slattach (I have no idea why this can be + fatal, but adding this flag solved the problem for at least one + person) + +* Using "s10" instead of "sl0" (might be hard to see the difference on + some fonts :) + +Try "ifconfig sl0" to see your interface status. I get: + +silvia# ifconfig sl0 +sl0: flags=10<POINTOPOINT> + inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 + +Also, "netstat -r" will give the routing table, in case you get the +"no route to host" messages from ping. Mine looks like: + +silvia# netstat -r +Routing tables +Destination Gateway Flags Refs Use IfaceMTU Rtt +Netmasks: +(root node) +(root node) + +Route Tree for Protocol Family inet: +(root node) => +default inr-3.Berkeley.EDU UG 8 224515 sl0 - - +localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 +inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - +silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 +(root node) + +(this is after transferring a bunch of files, your numbers should be +smaller). diff --git a/share/FAQ/Text/slip_server.FAQ b/share/FAQ/Text/slip_server.FAQ new file mode 100644 index 0000000..99b50a2 --- /dev/null +++ b/share/FAQ/Text/slip_server.FAQ @@ -0,0 +1,433 @@ + Slip Server + FAQ + For + FreeBSD + +$Id: slip_server.FAQ,v 1.2 1994/12/16 04:01:16 gclarkii Exp $ + +Help for setting up SLIP Server services on a FreeBSD system +------------------------------------------------------------ + +Written by Guy Helmer (ghelmer@alpha.dsu.edu) +Last Updated December 13, 1994 + +This document provides suggestions for setting up SLIP Server services +on a FreeBSD system, which typically means configuring your system to +automatically startup connections upon login for remote SLIP clients. +I've written this document based on my own experience; however, as +your system and needs may be different, this document may not answer +all of your questions, and I cannot be responsible if you damage your +system or lose data due to attempting to follow the suggestions here. + +I have only setup SLIP Server services on a FreeBSD 1.1 system, so if +you are running a different version (such as FreeBSD 2.0), your system +may be different. I've decided to write this document since I've +recently been asked for the umpteenth time how to setup a FreeBSD +machine as a SLIP server :-) + + +1. Prerequisites +---------------- + +This document is very technical in nature, so background knowledge is +required. I must assume that you are familiar with the TCP/IP network +protocol, and in particular, network and node addressing, network +address masks, subnetting, routing, and routing protocols, such as +RIP. Configuring SLIP services on a dial-up server requires a +knowledge of these concepts, and if you are not familiar with them, +please read a copy of either Craig Hunt's "TCP/IP Network +Administration" published by O'Reilly & Associates, Inc. (ISBN Number +0-937175-82-X), or Douglas Comer's book on the TCP/IP protocol. + +I will assume that you have already setup your modem(s) and configured +the appropriate system files to allow logins through your modems (see +the manual pages for sio(4) for information on the serial port device +driver and ttys(5), gettytab(5), getty(8), & init(8) for information +relevant to configuring the system to accept logins on modems, and +perhaps stty(1) for information on setting serial port parameters +[such as "clocal" for directly-connected serial interfaces]). + +2. Quick Overview +----------------- + +In its typical configuration, using FreeBSD as a SLIP server works as +follows: a SLIP user dials up your FreeBSD SLIP Server system and logs +in with a special SLIP login ID that uses "/usr/sbin/sliplogin" as the +special user's shell. The "sliplogin" program browses the file +"/etc/slip.hosts" to find a matching line for the special user, and if +it finds a match, connects the serial line to an available SLIP +interface and then runs /etc/slip.login to configure the SLIP +interface. + +2.1 An Example of a SLIP Server Login +------------------------------------- + +For example, if my SLIP user ID were "Shelmerg", that user's entry in +/etc/master.passwd would look something like this (except it would be +all on one line): + +Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP: + /usr/users/Shelmerg:/usr/sbin/sliplogin + +and, when I log in with that user ID, "sliplogin" will search +/etc/slip.hosts for a line that had a matching user ID; on my system, +I may have a line in /etc/slip.hosts that reads: + +Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp + +sliplogin will find that matching line, hook the serial line I'm on +into the next available SLIP interface, and then execute +/etc/slip.login like this: + +/etc/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp + +If all goes well, /etc/slip.login will issue an "ifconfig" for the +SLIP interface to which sliplogin attached itself (slip interface 0, +in the above example, which was the first parameter in the list given +to slip.login) to set the local IP address (dc-slip), remote IP +address (sl-helmer), network mask for the SLIP interface (0xfffffc00), +and any additional flags (autocomp). If something goes wrong, +sliplogin usually logs good informational messages via the daemon +syslog facility, which usually goes into /var/log/messages (see the +manual pages for syslogd(8) and syslog.conf(5), and perhaps check +/etc/syslog.conf to see to which files syslogd is logging). + +OK, enough of the examples -- let's dive into setting up the system. + +3. Kernel Configuration +----------------------- + +FreeBSD's default kernels usually come with two SLIP interfaces +defined (sl0 and sl1); you can use "netstat -i" to see whether these +interfaces are defined in your kernel. + +Sample output from "netstat -i": +Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll +ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 +ed0 1500 138.247.224 ivory 291311 0 174209 0 133 +lo0 65535 <Link> 79 0 79 0 0 +lo0 65535 loop localhost 79 0 79 0 0 +sl0* 296 <Link> 0 0 0 0 0 +sl1* 296 <Link> 0 0 0 0 0 + +The sl0 and sl1 interfaces shown in "netstat -i"'s output indicate +that there are two SLIP interfaces built into the kernel. (The +asterisks after the "sl0" and "sl1" indicate that the interfaces are +"down".) + +However, FreeBSD's default kernels do not come configured to forward +packets (ie, your FreeBSD machine will not act as a router) due to +Internet RFC requirements for Internet hosts (see RFC's 1009 +[Requirements for Internet Gateways], 1122 [Requirements for Internet +Hosts -- Communication Layers], and perhaps 1127 [A Perspective on the +Host Requirements RFCs]), so if you want your FreeBSD SLIP Server to +act as a router, you'll have to add the line "options GATEWAY" to your +machine's kernel configuration file and re-compile the kernel anyway. +(Trivia: "Gateways" are the Internet's old name for what are now +usually called "routers".) + +Please see the BSD System Manager's Manual chapter on "Building +Berkeley Kernels with Config" [the source for which is in +/usr/src/share/doc/smm] and the "FreeBSD Configuration Options" [in +/sys/doc/options.doc] for more information on configuring and building +kernels. You may have to unpack the kernel source distribution if +haven't installed the system sources already (srcdist/srcsys.?? in +FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source +distribution in FreeBSD 2.0-RELEASE) to be able to configure and build +kernels. + +You'll notice that near the end of the default kernel configuration +file (/sys/i386/conf/GENERICAH) is a line that reads: + +pseudo-device sl 2 + +which is the line that defines the number of SLIP devices available in +the kernel; the number at the end of the line is the maximum number of +SLIP connections that may be operating simultaneously. + +See the "Building Berkeley Kernels with Config" and the manual page +for config(8) to see how to configure and build kernels. + +4. Sliplogin Configuration +-------------------------- + +As mentioned earlier, there are three files in the /etc directory that +are part of the configuration for /usr/sbin/sliplogin (see +sliplogin(8) for the actual manual page for sliplogin): slip.hosts, +which lists the SLIP users & their associated IP addresses; +slip.login, which usually just configures the SLIP interface; and +slip.logout, which undoes slip.login's effects when the serial +connection is terminated. + +4.1 slip.hosts Configuration & Local and Remote Address Selection +----------------------------------------------------------------- + +/etc/slip.hosts contains lines which have at least four items listed: +a SLIP user's login ID, the local address (local to the SLIP server) +of the SLIP link, the remote address of the SLIP link, and the network +mask. The local and remote addresses may be host names (given in +/etc/hosts or by the domain name service, depending on your +specifications in /etc/host.conf), and I believe the network mask may +be a name that can be resolved by a lookup into /etc/networks. On one +of my systems, /etc/slip.hosts looks like this: + +----- begin /etc/slip.hosts ----- +# +# login local-addr remote-addr mask opt1 opt2 +# (normal,compress,noicmp) +# +Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp +----- end /etc/slip.hosts ------ + +At the end of the line is one or more of the options: + + "normal" - no header compression + "compress" - compress headers + "autocomp" - compress headers if the remote end allows it + "noicmp" - disable ICMP packets (so any "ping" packets won't use up + any of your bandwidth) + +Your choice of local and remote addresses for your SLIP links depends +on whether you are going to dedicate a TCP/IP subnet or if you are +going to use "proxy ARP" on your SLIP server (it's not "true" proxy +ARP, but that is the terminology that I will use in this document to +describe it). If you're not sure which method to select or how to +assign IP addresses, please refer to the TCP/IP books referenced in +the "Prerequisites" section and/or consult your IP network manager. + +If you are going to use a separate subnet for your SLIP clients, you +will need to allocate the subnet number out of your assigned IP +network number and assign each of your SLIP client's IP numbers out of +that subnet; then you will probably either need to configure a static +route to the SLIP subnet via your SLIP server on your nearest IP +router, or install "gated" on your FreeBSD SLIP server and configure +it to talk the appropriate routing protocols to your other routers to +inform them about your SLIP server's route to the SLIP subnet. + +Otherwise, if you will use the "proxy ARP" method, you will need to +assign your SLIP client's IP addresses out of your SLIP server's +Ethernet subnet, and you'll also need to adjust your /etc/slip.login +and /etc/slip.logout scripts to use arp(8) to manage the proxy-ARP +entries in the SLIP server's ARP table. + +4.2 slip.login Configuration +---------------------------- + +The typical /etc/slip.login file looks like this: + +----- begin /etc/slip.login ----- +#!/bin/sh - +# +# @(#)slip.login 5.1 (Berkeley) 7/1/90 + +# +# generic login file for a slip line. sliplogin invokes this with +# the parameters: +# 1 2 3 4 5 6 7-n +# slipunit ttyspeed loginname local-addr remote-addr mask opt-args +# +/sbin/ifconfig sl$1 inet $4 $5 netmask $6 +----- end /etc/slip.login ----- + +This slip.login file merely ifconfig's the appropriate SLIP interface +with the local and remote addresses and network mask of the SLIP +interface. + +If you have decided to use the "proxy ARP" method (instead of using a +separate subnet for your SLIP clients), your /etc/slip.login file will +need to look something like this: + +----- begin /etc/slip.login for "proxy ARP" ----- +#!/bin/sh - +# +# @(#)slip.login 5.1 (Berkeley) 7/1/90 + +# +# generic login file for a slip line. sliplogin invokes this with +# the parameters: +# 1 2 3 4 5 6 7-n +# slipunit ttyspeed loginname local-addr remote-addr mask opt-args +# +/sbin/ifconfig sl$1 inet $4 $5 netmask $6 +# Answer ARP requests for the SLIP client with our Ethernet addr +/usr/sbin/arp -s $5 00:11:22:33:44:55 pub +----- end /etc/slip.login for "proxy ARP" ----- + +The additional line in this slip.login, "arp -s...", creates an ARP +entry in the SLIP server's ARP table which asks the system to give out +the SLIP server's Ethernet MAC address whenever a another system or +router on the Ethernet asks to speak to the SLIP client's IP address. + +When using the example above, be sure to replace the Ethernet MAC +address (00:11:22:33:44:55) with the MAC address of your system's +Ethernet card, or your "proxy ARP" will definitely not work! You can +discover your SLIP server's Ethernet MAC address by looking at the +results of running "netstat -i"; the second line of the output should +look something like: + +ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 + ^^^^^^^^^^^^^^^ + +which indicates that this particular system's Ethernet MAC address is +"00:02:c1:28:5f:4a" -- the periods in the Ethernet MAC address given +by "netstat -i" must be changed to colons and leading zeros should be +added to each single-digit hexadecimal number to convert the address +into the form that arp(8) desires; see the manual page on arp(8) for +complete information on usage. + +Note that when you create /etc/slip.login and /etc/slip.logout, the +"execute" bit ("chmod 755 /etc/slip.login /etc/slip.logout") must be +set, or sliplogin will be unable to execute it. + +4.3 slip.logout Configuration +----------------------------- + +"/etc/slip.logout" isn't strictly needed, but if you decide to create +it, this is an example of a basic slip.logout script: + +----- begin /etc/slip.logout ----- +#!/bin/sh - +# +# slip.logout + +# +# logout file for a slip line. sliplogin invokes this with +# the parameters: +# 1 2 3 4 5 6 7-n +# slipunit ttyspeed loginname local-addr remote-addr mask opt-args +# +/sbin/ifconfig sl$1 down +----- end /etc/slip.logout ----- + +If you are using "proxy ARP", you'll want to have /etc/slip.logout +remove the ARP entry for the SLIP client: + +----- begin /etc/slip.logout for "proxy ARP" ----- +#!/bin/sh - +# +# @(#)slip.logout + +# +# logout file for a slip line. sliplogin invokes this with +# the parameters: +# 1 2 3 4 5 6 7-n +# slipunit ttyspeed loginname local-addr remote-addr mask opt-args +# +/sbin/ifconfig sl$1 down +# Quit answering ARP requests for the SLIP client +/usr/sbin/arp -d $5 +----- end /etc/slip.logout for "proxy ARP" ----- + +The "arp -d $5" removes the ARP entry that the "proxy ARP" slip.login +added when the SLIP client logged in. + +It bears repeating: make sure /etc/slip.logout has the execute bit set +for after you create it (e.g., "chmod 755 /etc/slip.logout"). + +5. Routing Considerations +------------------------- + +If you are not using the "proxy ARP" method for routing packets +between your SLIP clients and the rest of your network (and perhaps +the Internet), you will probably either have to add static routes to +your closest default router(s) to route your SLIP client subnet via +your SLIP server, or you will probably need to install and configure +gated on your FreeBSD SLIP server so that it will tell your routers +via appropriate routing protocols about your SLIP subnet. + +5.1 Static Routes +----------------- + +Adding static routes to your nearest default routers can be +troublesome (or impossible, if you don't have authority to do so...). +If you have a multiple-router network in your organization, some +routers, such as Cisco and Proteon, may not only need to be configured +with the static route to the SLIP subnet, but also need to be told +which static routes to tell other routers about, so some expertise and +troubleshooting/tweaking may be necessary to get static-route-based +routing to work... + +5.2 Running gated +----------------- + +An alternative to the headaches of static routes is to install gated +on your FreeBSD SLIP server and configure it to use the appropriate +routing protocols (RIP/OSPF/BGP/EGP) to tell other routers about your +SLIP subnet. gated is available from ftp.gated.cornell.edu in +/pub/gated; I believe the current version as of this writing is +"gated-R3_5Alpha_8.tar.Z", which should include support for FreeBSD +"out-of-the-box". Compile and install it, and then write a +/etc/gated.conf file to configure your gated; here's a sample, similar +to what I use on my FreeBSD SLIP server: + +----- begin sample /etc/gated.conf for gated version 3.5Alpha5 ----- +# +# gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 +# Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface +# +# +# tracing options +# +traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; + +rip yes { + interface sl noripout noripin ; + interface ed ripin ripout version 1 ; + traceoptions route ; +} ; + +# +# Turn on a bunch of tracing info for the interface to the kernel: +kernel { + traceoptions remnants request routes info interface ; +} ; + +# +# Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP +# + +export proto rip interface ed { + proto direct { + xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections + } ; +} ; + +# +# Accept routes from RIP via ed Ethernet interfaces + +import proto rip interface ed { + all ; +} ; + +----- end sample /etc/gated.conf ----- + +The above sample gated.conf file broadcasts routing information +regarding the SLIP subnet "xxx.xxx.yy" via RIP onto the Ethernet; if +you are using a different Ethernet driver than the "ed" driver, you'll +need to change the references to the "ed" interface appropriately. +This sample file also sets up tracing to /var/tmp/gated.output for +debugging gated; you can certainly turn off the tracing options if +gated works OK for you. I've changed my SLIP subnet's address to +"xxx.xxx.yy" throughout the above file; you'll need to change the +"xxx.xxx.yy"'s into the network address of your own SLIP subnet (be +sure to change the net mask in the "proto direct" clause as well). +Complete gated configuration information may be read through the Web +at "http://www.gated.cornell.edu/". + +When you get gated built and installed, and create a configuration +file for it, you'll need to run gated in place of routed on your +FreeBSD system; change the routed/gated startup parameters in +/etc/netstart as appropriate for your system. Please see the manual +page for gated for information on gated's command-line parameters. + +6. Acknowledgements +------------------- + +Thanks to these people for comments and advice regarding this FAQ: + + Wilko Bulte <wilko@yedi.iaf.nl> + Piero Serini <Piero@Strider.Inet.IT> + +<<< END OF SLIP SERVER FAQ >>> + + diff --git a/share/FAQ/Text/submitters.FAQ b/share/FAQ/Text/submitters.FAQ new file mode 100644 index 0000000..69a79f3 --- /dev/null +++ b/share/FAQ/Text/submitters.FAQ @@ -0,0 +1,167 @@ +-- A submitter's guide to FreeBSD -- + +This guide is intended for those who are moderately familar with FreeBSD +and are now to the point where they have some locally developed +customizations or fixes to the system which they'd like to incorporate +back into the mainstream sources, thus saving the work of having to +re-integrate the changes for each subsequent FreeBSD release. Submitting +something to the FreeBSD project is also an excellent way of getting your +code seriously *tested*! Many people have developed an original concept +far beyond what they might have envisioned at the start just due to the +flood of feedback and ideas generated by the many thousands of users of +FreeBSD. Contributions are also what FreeBSD lives and grows from, +and so your contributions are very important to the continued survival +of this communal effort of ours - we're very glad to see you reading this +documentation! :-) + +Submissions to FreeBSD can generally be classified into four catagories: + +1. Ideas, general suggestions, bug reports. +2. Addition, deletion, renaming or patching of existing sources. +3. Significant contribution of a large body of independant work. +4. Porting of freely available software. + +A submission in *any* of these catagories is highly welcomed as they +are each, in their own way, quite significant to the project. + + +1. An idea, suggestion or fix can be communicated in one of the following ways: + + o An idea or suggestion of general technical interest should be + mailed to <hackers@freebsd.org>. Likewise, people with an interest + in such things (and a tolerance for a HIGH volume of mail!) may + subscribe by sendimg mail to <majordomo@freebsd.org>. See also the + file /usr/share/FAQ/mailing-list.FAQ. + + o An actual bug report should be filed by using the send-pr(1) + command (``man send-pr'' for information). This will prompt + you for various fields to fill in. Simply go to the fields + surrounded by <>'s and fill in your own information in place of + what's suggested there. You should receive confirmation of your + bug report and a tracking number (which you should also reference in + any subsequent correspondence). + + If you do not receive confirmation in a timely fashion (3 days to + a week, depending on your email connection) or are, for some + reason, unable to use the send-pr command, then you may also + file a bug report (or follow-up to one) by sending mail to: + + <bugs@freebsd.org> + + +2. 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" and made available in a variety of + ways (see /usr/share/FAQ/current-policy.FAQ and /usr/share/FAQ/ctm.FAQ) for + the convenience of developers who wish to actively work on the system. + + Working from older sources unfortunately means that your changes may + sometimes be too obsolete to use, or too divergent to allow for easy + re-integration. This can be minimized somewhat by subscribing to the + <announce@freebsd.org> mailing list (among others) where periodic + announcements concerning the current state of the system are made. + If you see a change being proposed for which you have a better solution, + then please, by all means come forward with your contribution and we + will do our very best to evaluate it fairly and perhaps integrate it if + it is indeed a better (or easier :) solution. + + 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 for evaluation and possible adoption. This is done + with the diff(1) command, with the FreeBSD maintainers preferring to receive + diffs in `context diff' form. See the man page for diff for more details + on producing both context and recursive context diffs + (diff -c <oldfile> <newfile> or diff -c -r <olddir> <newdir>). + + Once you have a set of diffs that are capable of taking a copy of the + original code and bringing it to a state identical to the "new" sources + (you may test this with the patch(1) command - see patch man page), you + should bundle them up in an email message and send it, along with a brief + description of what the diffs are for, to <hackers@freebsd.org>. Someone + will very likely get back in touch with you in 24 hours or less, assuming + of course that your diffs are interesting! :-) + + If your changes don't express themselves well as diffs alone (e.g. you've + perhaps added, deleted or renamed files as well) then you may be better off + bundling any new files, diffs and instructions for deleting/renaming any + others into a tar file and running the `uuencode' program on it before + sending the output of that to <hackers@freebsd.org>. See the man pages + on tar and uuencode for more info on bundling files through the mail this + way. + + If your change is of a potentially sensitive nature, e.g. you're unsure + of copyright issues governing its further distribution, or you're simply + not ready to release it without a tighter review first, then you should + send it to <core@freebsd.org> rather than <hackers@freebsd.org>. 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 really only mail to them in cases where mailing to hackers + truly is impractical. + + +3. 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 (see above) + or upload them to our ftp site: + ftp://freefall.cdrom.com/pub/FreeBSD/incoming + + Users may log in anonymously and upload their work or download the + work-in-progress files left by others. + + When working with large amounts of code, the touchy subject of copyrights + also invariably comes up. The view of the FreeBSD project towards + acceptable copyrights (for code included in FreeBSD) are: + + 3a. Contributions under the BSD copyright (see the file + /usr/share/examples/etc/bsd-style-copyright for a template) + is greatly preferred due to its "no strings attached" + nature and general attractiveness to commercial enterprises + who might then be inclined to invest something of their own + into FreeBSD. + + 3b. Contributions under the GNU Public License, or "GPL". This is + not quite as popular a solution for us, due to (all religious + issues aside) the amount of extra effort demanded of anyone + using the code for commercial purposes. However, given the + sheer quantity of GPL'd code we currently require (compiler, + assembler, text formatter, etc), it would be silly to pretend + that we couldn't deal with the GPL at all and so we have become + more willing to accept code with either the BSD or the GPL + copyright. Code under the GPL also goes into a different part + of the tree, that being /sys/gnu or /usr/src/gnu. + + 3c. Contributions coming under any other type of copyright must be + carefully reviewed before their inclusion into FreeBSD will even + be considered. Contributions for which particularly restrictive + commercial copyrights apply are generally rejected, though the + authors are always free to make the changes available through + their own channels. + + +4. The porting of freely available software, while perhaps not as gratifying + as developing your own package from scratch, is still a vital part of + FreeBSD's growth and of great usefulness to those who wouldn't otherwise + know where to turn for it. All ported software is organized into a + hierarchy know as ``the ports collection''. This collection enables + a new user to get a complete overview of what's available in a short time, + and with a logical (we hope) framework. The ports collection also saves + considerable space by not actually containing the the majority of the + sources being ported. This can be confusing to the new user and the file + /usr/share/FAQ/ports.FAQ goes some way towards explaing how it all works. + + If you have the ports collection on your machine, the file + /usr/ports/GUIDELINES also helps to explain the process of creating + and contributing a port of your own. For more information on the ports + collection (that wasn't available in the FAQ), you may also send mail to + <ports@freebsd.org>. + + +Whichever way you decide to contribute, we hope you'll find it an enjoyable +process and also realize how valuable your contributions are to the project! +FreeBSD is one of those great projects where the more we all put in, the +more we all get back out of it again, and with enough steady contributions +it begins to aquire a momentum of its own. It is through such momentum +that mountains are moved! :-) + + Jordan diff --git a/share/FAQ/Text/sup.FAQ b/share/FAQ/Text/sup.FAQ new file mode 100644 index 0000000..db9ff7f --- /dev/null +++ b/share/FAQ/Text/sup.FAQ @@ -0,0 +1,90 @@ + FreeBSD + Sup FAQ + +$Id: sup.FAQ,v 1.4 1995/03/01 06:12:15 gclarkii Exp $ + + SUP is a network based software update tool developed at CMU. The +purpose of this document is get the beginner up and running with sup. + + First off you will need to pick up the sup binaries. The easiest +way of doing this is to grab the sup.tgz package from: + + ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/packages/sup.tgz + +Install the sup package using pkg_add and add the following line to +your /etc/services file: + + sup 871/tcp #sup + +SUP gets the information it needs to run from a configuration file +called a supfile. This file tells sup what collections it will be updating +and/or installing and where they go. The supfile in this directory will +sup both the source and ports collection - look for the blank line seperating +the two collections; if you don't want ports, you can simply delete all the +ports entries. If you're inside the United States, you may also uncomment +the `secure' collection line to grab the DES code. If you're outside the +U.S., you should NOT sup this code from FreeBSD.ORG as this will +violate U.S. export restrictions. Simply sup everything *but* the secure +collection and then go look on "braae.ru.ac.za", where it's available for +anonymous ftp for those outside the U.S. + +Any other distributions you do not wish to receive can be commented out +with a # at the begining of the distribution line. + +Once this is setup, you're ready to go. To start sup type: + + sup supfile + +If you wish to see what sup is doing "verbosely", give it the -v option, +like so: + + sup -v supfile + +Thats all there is to it! Remember that if you're running current, +which is what you will have if you sup, please join the freebsd-current +mailing list. You should also be sure to read: + + ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/FAQ/current-policy.FAQ + +For important information on just what we can and cannot do for you as +a -current user. + +Gary Clark II / Jordan Hubbard +FreeBSD maintainance persons. + +---- + +Description of FreeBSD SUP distributions: + +base: /usr/src/... misc files at the top of /usr/src +bin: /usr/src/bin system binaries +secure: /usr/src/secure DES Sources. U.S./Canada only! +etc: /usr/src/etc system files +games: /usr/src/games games +gnu: /usr/src/gnu sources under the GNU Public License +include: /usr/src/include include files +sys: /usr/src/sys kernel sources +lib: /usr/src/lib libraries +libexec: /usr/src/libexec more system binaries +share: /usr/src/share various shared resources +sbin: /usr/src/sbin even more system binaries +usrbin: /usr/src/usr.bin user binaries +usrsbin: /usr/src/usr.sbin that's it for the system binaries + +Ports: + +ports-base: /usr/ports/... misc files at the top of /usr/ports +ports-editors: /usr/ports/editors text editors +ports-game: /usr/ports/games games +ports-lang: /usr/ports/lang programming languages +ports-mail: /usr/ports/mail mail software +ports-math: /usr/ports/math math software +ports-net: /usr/ports/net networking software +ports-news: /usr/ports/news USENET news software +ports-print: /usr/ports/print printing software +ports-shells: /usr/ports/shells various UN*X shells +ports-utils: /usr/ports/utils miscellaneous utilities +ports-x11: /usr/ports/x11 X11 software + + + diff --git a/share/FAQ/Text/systems.FAQ b/share/FAQ/Text/systems.FAQ new file mode 100644 index 0000000..34c8e71 --- /dev/null +++ b/share/FAQ/Text/systems.FAQ @@ -0,0 +1,59 @@ + + Systems FAQ + for FreeBSD 2.0 + +This FAQ lists systems (and componets) known to work with FreeBSD 2.0. None +of these lists should be seen as a recomandation for a manufacture. + +$Id: systems.FAQ,v 1.2 1995/01/03 15:54:08 gclarkii Exp $ + + +i386: + + +Motherboard: Magitronics 386DX-40 +CPU: i386DX-40 +Busses: ISA and VLB (VLB not tested) +Ram: 20 Megs +Video: Generic 1MB Tseng 4000 (ISA) +Disks: + 2 - Segate ST1126 (SCSI) + 1 - Seagate ST1480 (SCSI) + 1 - Toshiba MK-234FC-C (IDE) +Controllers: + Generic IDE + Adaptec AH-1542CF + +Motherboard: Magitronics 386SX-40 +CPU: i386SX-40 +Busses: ISA +Ram: 4 Megs +Video: Monochrome +Disks: + 1-Seagate ST1126 (SCSI) +Controllers: + Future Domain 850 +Notes: Slow but useable + +i486: + +Motherboard: Gateway 2000 Handbook 486 HB486DX2-40 +CPU: i486SL DX2/40 +BUS(S): PCMCIA, one type II +Video Card: Monochrome VGA. +Are you running X on this?: no, havn't really tried. +Types of Disks (manufacture and bus): 130Mb builtin. <Areal A130 U> +If you wish to be credited: Poul-Henning Kamp phk@freefall.cdrom.com + +NOTES: +This is a 3 pound portable. Runs perfect. Suspend works great. Has one +serial and one parallel/floppy port, which can drive either a floppy or +a parallel port, but not at the same time. Builtin "EZ" mouse-thinge. +Highly recommended for people on the road. + + +Credits: + FreeBSD Core Team + Gary Clark II + Poul-Henning Kamp + |
