diff --git a/handbook/contrib.sgml b/handbook/contrib.sgml index d07f04a2a3..b535ea9b75 100644 --- a/handbook/contrib.sgml +++ b/handbook/contrib.sgml @@ -1,418 +1,416 @@ - + FreeBSD 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 re-implemented from the 4.4BSD-Lite release provided by the Computer Science Research Group (CSRG) at the University of California, Berkeley and associated academic contributors. There are also portions of NetBSD 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 endeavors. 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 has been most useful! - Thanks to Chuck Robey <chuckr@eng.umd.edu> who + Thanks to &a.chuck; who contributed his floppy tape streamer for experimental work. - Thanks to Larry Altneu <larry@ALR.COM>, and to Wilko Bulte - <wilko@yedi.iaf.nl>, for providing us with a Wangtek and + Thanks to Larry Altneu <larry@ALR.COM>, and to &a.wilko;, + for providing us with a Wangtek and an Archive QIC-02 tape drive, in order to give us the hardware to improve the wt driver. Thanks go to Ernst Winter <ewinter@lobo.muc.de>, for contributing a 2.88 MB floppy drive to the project. Hopefully, this will increase the pressure for rewriting the floppy disk driver. ;-) Also see for a list of people who have donated funding or services to the FreeBSD Project. The FreeBSD core team

(in alphabetical order by last name): &a.asami &a.ache &a.dyson &a.bde &a.gibbs &a.davidg &a.jkh &a.phk &a.rich &a.gpalmer &a.sos &a.peter &a.wollman &a.joerg The FreeBSD Developers

These are the people who have commit privileges and do the work on the FreeBSD source tree. All core team members are also developers. &a.torstenb; &a.gclarkii; &a.adam; &a.dufault; &a.uhclem; &a.julian; &a.sef; &a.se; &a.fenner; &a.jfieber; &a.jfitz; &a.scrappy; &a.jhay; &a.lars; &a.tg; &a.graichen; &a.rgrimes; &a.hsu; &a.ugen; &a.gj; &a.andreas; &a.imp; &a.ljo; &a.erich; &a.smace; &a.amurai; &a.markm; &a.max; &a.alex; &a.wpaul; &a.smpatel; &a.jmacd; &a.jdp; &a.mpp; &a.dfr; &a.csgr; &a.martin; &a.paul; &a.roberto; &a.jraynard; &a.chuckr; &a.dima; &a.wosch; &a.ats; &a.karl; &a.pst; &a.guido; &a.swallace; &a.nate; &a.jmz; &a.fsmp; &a.steve; Who is responsible for what

Additional FreeBSD contributors

(in alphabetical order by first name): A JOSEPH KOSHY <koshy@india.hp.com> ABURAYA Ryushirou <pcs51674@asciinet.or.jp> Adam Glass <glass@postgres.berkeley.edu> Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu> Akito Fujita <fujita@zoo.ncl.omron.co.jp> Alain Kalker <A.C.P.M.Kalker@student.utwente.nl> - Alex Nash <nash@mcs.com> Andy Whitcroft <andy@sarc.city.ac.uk> - Andreas Klemm <andreas@knobel.GUN.de> + &a.andreas; Andrew Gordon <andrew.gordon@net-tel.co.uk> Andrew Herbert <andrew@werple.apana.org.au> Andreas Kohout <shanee@rabbit.augusta.de> Andrew McRae <amcrae@cisco.com> Andrew Moore <alm@FreeBSD.org> Andrew V. Stesin <stesin@elvisti.kiev.ua> Andrey Zakhvatov <andy@cgu.chel.su> Anthony Yee-Hang Chan <yeehang@netcom.com> Bernd Rosauer <br@schiele-ct.de> Bill Kish <kish@osf.org> Bob Wilcox <bob@obiwan.uucp> Brent J. Nordquist <nordquist@platinum.com> Brian Clapper <bmc@telebase.com> Brian Tao <taob@io.org> Charles Hannum <mycroft@ai.mit.edu> Chet Ramey <chet@odin.INS.CWRU.Edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Stenton <jacs@gnome.co.uk> Chris Timmons <skynyrd@opus.cts.cwu.edu> Chris Torek <torek@ee.lbl.gov> Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> Christian Haury <Christian.Haury@sagem.fr> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Chuck Hein <chein@cisco.com> Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> Craig Struble <cstruble@vt.edu> Cristian Ferretti <cfs@riemann.mat.puc.cl> Curt Mayer <curt@toad.com> Daniel Baker <dbaker@crash.ops.neosoft.com> Daniel M. Eischen <deischen@iworks.InterWorks.org> Danny J. Zerkel <dzerkel@feephi.phofarm.com> Dave Bodenstab <imdave@synet.net> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Chapeskie <dchapes@zeus.leitch.com> Dave Edmondson <davided@sco.com> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Leonard <d@scry.dstc.edu.au> David O'Brien <obrien@cs.ucdavis.edu> Dean Huxley <dean@fsa.ca> Dirk Froemberg <dirk@hal.in-berlin.de> - Don Whiteside <dwhite@anshar.shadow.net> + &a.whiteside; Don Yuniskis <dgy@rtd.com> Donald Burr <d_burr@ix.netcom.com> Doug Ambrisko <ambrisko@ambrisko.roble.com> Eric Blood <eblood@cs.unr.edu> Frank Bartels <knarf@camelot.de> Frank Maclachlan <fpm@crash.cts.com> Frank Nobis <fn@trinity.radio-do.de> Gary A. Browning <gab10@griffcd.amdahl.com> Gene Stark <stark@cs.sunysb.edu> Greg Ungerer <gerg@stallion.oz.au> Harlan Stenn <Harlan.Stenn@pfcs.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Hideaki Ohmon <ohmon@sfc.keio.ac.jp> Hidekazu Kuroki <hidekazu@cs.titech.ac.jp> Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> Holger Veit <Holger.Veit@gmd.de> Ikuo Nakagawa <ikuo@isl.intec.co.jp> Ishii Masahiro <?> J.T. Conklin <jtc@cygnus.com> James Clark <jjc@jclark.com> James da Silva <jds@cs.umd.edu> et al Janusz Kokot <janek@gaja.ipan.lublin.pl> Jason Thorpe <thorpej@nas.nasa.gov> Javier Martin Rueda <jmrueda@diatel.upm.es> Jian-Da Li <jdli@FreeBSD.csie.NCTU.edu.tw> Jim Lowe <james@miller.cs.uwm.edu> Jim Wilson <wilson@moria.cygnus.com> Johann Tonsing <jtonsing@mikom.csir.co.za> John Capo <jc@irbs.com> John Perry <perry@vishnu.alias.net> Juergen Lock <nox@jelal.hb.north.de> Juha Inkari <inkari@cc.hut.fi> Julian Jenkins <kaveman@magna.com.au> Julian Stacey <jhs@freebsd.org> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Keith Moore <?> Kirk McKusick <mckusick@mckusick.com> Kostya Lukin <lukin@okbmei.msk.su> Kurt Olsen <kurto@tiny.mcs.usu.edu> Lucas James <Lucas.James@ldjpc.apana.org.au> Marc Frajola <marc@dev.com> Marc Ramirez <mrami@mramirez.sy.yale.edu Marc van Kempen <wmbfmk@urc.tue.nl> Mark Huizer <xaa@stack.urc.tue.nl> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Birgmeier Masachika ISHIZUKA <ishizuka@isis.min.ntt.jp> Matt Bartley <mbartley@lear35.cytex.com> Matt Thomas <thomas@lkg.dec.com> Matt White <mwhite+@CMU.EDU> Matthew N. Dodd <winter@jurai.net> Matthew Stein <matt@bdd.net> Michael Elbel <me@FreeBSD.ORG> Michael Smith <msmith@atrad.adelaide.edu.au> Mikael Hybsch <micke@dynas.se> Mike Peck <mike@binghamton.edu> MITA Yoshio <mita@jp.FreeBSD.ORG> NIIMI Satoshi <sa2c@and.or.jp> Nisha Talagala <nisha@cs.berkeley.edu> Nobuhiro Yasutomi <nobu@psrc.isac.co.jp> Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> Noritaka Ishizumi <graphite@taurus.bekkoame.or.jp> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Peter Stubbs <PETERS@staidan.qld.edu.au> Philippe Charnier <charnier@lirmm.fr> R. Kym Horsell <?> Randall Hopper <rhh@stealth.ct.picker.com> Richard Stallman <rms@gnu.ai.mit.edu> Richard Wiwatowski <rjwiwat@adelaide.on.neti> Rob Shady <rls@id.net> Rob Snow <rsnow@txdirect.net> Robert Sanders <rsanders@mindspring.com> Robert Withrow <witr@rwwa.com> Sascha Wildner <swildner@channelz.GUN.de> Scott Blachowicz <scott@sabami.seaslug.org> Serge V. Vakulenko <vak@zebub.msk.su> Soren Dayton <csdayton@midway.uchicago.edu> Stephen McKay <syssgm@devetir.qld.gov.au> Steve Gerakines <steve2@genesis.tiac.net> Taguchi Takeshi <taguchi@tohoku.iij.ad.jp> Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> Terry Lambert <terry@lambert.org> Terry Lee <terry@uivlsi.csl.uiuc.edu> Theo Deraadt <deraadt@fsa.ca> - Thomas Gellekum <thomas@ghpc8.ihf.rwth-aachen.de> Tim Kientzle <kientzle@netcom.com> Tim Vanderhoek <ac199@freenet.hamilton.on.ca> Tom Samplonius <tom@misery.sdf.com> Torbjorn Granlund <tege@matematik.su.se> Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> Wes Santee <wsantee@wsantee.oz.net> Wolfgang Stanglmeier <wolf@kintaro.cologne.de> Yoshiro Mihira <sanpei@yy.cs.keio.ac.jp> Yuval Yarom <yval@cs.huji.ac.il> Yves Fonk <yves@cpcoup5.tn.tudelft.nl> 386BSD Patch kit patch contributors

(in alphabetical order by first name): 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> 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@cygnus.com> Jagane D Sundar < jagane@netcom.com > James Clark <jjc@jclark.com> James Jegers <jimj@miller.cs.uwm.edu> James W. Dolter James da Silva <jds@cs.umd.edu> et al Jay Fenlason <hack@datacube.com> Jim Wilson <wilson@moria.cygnus.com> Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de> Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> John Dyson - <formerly dyson@ref.tfs.com> John Polstra <jdp@polstra.com> John Woods <jfw@eddie.mit.edu> Jordan K. Hubbard <jkh@whisker.hubbard.ie> Julian Elischer <julian@dialix.oz.au> Julian Stacey <jhs@freebsd.org> Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Ken Hughes Kent Talarico <kent@shipwreck.tsoft.net> Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu> Marc Frajola <marc@dev.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Renters <martin@tdc.on.ca> Michael Clay <mclay@weareb.org> Michael Galassi <nerd@percival.rain.com> Mike Durkin <mdurkin@tsoft.sf-bay.org> Naoki Hamada <nao@sbl.cl.nec.co.jp> Nate Williams <nate@bsd.coe.montana.edu> Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com> Pace Willisson <pace@blitz.com> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Popelka <paulp@uts.amdahl.com> Peter da Silva <peter@NeoSoft.com> Phil Sutherland <philsuth@mycroft.dialix.oz.au> Poul-Henning Kamp<phk@FreeBSD.ORG> Ralf Friedl <friedl@informatik.uni-kl.de> Rick Macklem <root@snowhite.cis.uoguelph.ca> Robert D. Thrush <rd@phoenix.aii.com> Rodney W. Grimes <rgrimes@cdrom.com> 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> diff --git a/handbook/ctm.sgml b/handbook/ctm.sgml index 088beeb7db..c66c4c4651 100644 --- a/handbook/ctm.sgml +++ b/handbook/ctm.sgml @@ -1,201 +1,201 @@ CTM

Contributed by &a.phk;. Updated 16-Mar-1995. Why should I use

. What do I need to use

You will need two things: The ``/usr/src/usr.sbin/ if you have a copy of the source online. If you are running a pre-2.0 version of FreeBSD, you can fetch the current The ``deltas'' you feed or see section . FTP the relevant directory and fetch the /etc/aliases if you want to have the process run in a fully automated fashion. Check the Starting off with

Before you can start using Using

To apply the deltas, simply say cd /where/ever/you/want/the/stuff ctm -v -v /where/you/store/your/deltas/src-cur.* Future plans for

Tons of them: Make local modifications to the tree possible. One way to do it could be this:

When foo/bar.c'', it would first check for the existence 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 -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.* would restore Clean up the options to The bad news is that I am very busy, so any help in doing this will be most welcome. And do not forget to tell me what you want also... Miscellaneous 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 ``Thanks!

- diff --git a/handbook/diskless.sgml b/handbook/diskless.sgml index d345160308..92ef602085 100644 --- a/handbook/diskless.sgml +++ b/handbook/diskless.sgml @@ -1,155 +1,155 @@ - + Diskless operation

Contributed by &a.martin;. netboot.com/netboot.rom allow you to boot your FreeBSD machine over the network and run FreeBSD without having a disk on your client. Under 2.0 it is now possible to have local swap. Swapping over NFS is also still supported. Supported Ethernet cards include: Western Digital/SMC 8003, 8013, 8216 and compatibles; NE1000/NE2000 and compatibles (requires recompile) Setup Instructions

Find a machine that will be your server. This machine will require enough disk space to hold the FreeBSD 2.0 binaries and have bootp, tftp and NFS services available. Tested machines: HP9000/8xx running HP-UX 9.04 or later (pre 9.04 doesn't work) Sun/Solaris 2.3. (you may need to get bootp) Set up a bootp server to provide the client with IP, gateway, netmask. diskless:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: Set up a TFTP server (on same machine as bootp server) to provide booting information to client. The name of this file is cfg.X.X.X.X (or /tftpboot/cfg.X.X.X.X, it will try both) where X.X.X.X is the IP address of the client. The contents of this file can be any valid netboot commands. Under 2.0, netboot has the following commands: help - print help list ip - print/set client's IP address server - print/set bootp/tftp server address netmask - print/set netmask hostname - print/set hostname kernel - print/set kernel name rootfs - print/set root filesystem swapfs - print/set swap filesystem swapsize - set diskless swapsize in Kbytes diskboot - boot from disk autoboot - continue boot process trans - turn transceiver on|off flags [bcdhsv] - set boot flags A typical completely diskless cfg file might contain: rootfs 192.1.2.3:/rootfs/myclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname myclient.mydomain A cfg file for a machine with local swap might contain: rootfs 192.1.2.3:/rootfs/myclient hostname myclient.mydomain Ensure that your NFS server has exported the root (and swap if applicable) filesystems to your client, and that the client has root access to these filesystems A typical /etc/exports file on FreeBSD might look like: /rootfs/myclient -maproot=0:0 myclient.mydomain /swapfs -maproot=0:0 myclient.mydomain And on HP-UX: /rootfs/myclient -root=myclient.mydomain /swapfs -root=myclient.mydomain If you are swapping over NFS (completely diskless configuration) create a swap file for your client using touch. If your swapfs command has the argument /swapfs as in the example above, the swapfile for myclient will be called /swapfs/swap.X.X.X.X where X.X.X.X is the client's IP addr, eg: # touch /swapfs/swap.192.1.2.4 Unpack the root filesystem in the directory the client will use for its root filesystem (/rootfs/myclient in the example above). On HP-UX systems: The server should be running HP-UX 9.04 or later for HP9000/800 series machines. Prior versions do not allow the creation of device files over NFS. When extracting /dev in /rootfs/myclient, beware that some systems (HPUX) will not create device files that FreeBSD is happy with. You may have to go to single user mode on the first bootup (press control-c during the bootup phase), cd /dev and do a "sh ./MAKEDEV all" from the client to fix this. Run netboot.com on the client or make an EPROM from the netboot.rom file Using Shared / and /usr filesystems

At present there isn't an officially sanctioned way of doing this, although I have been using a shared /usr filesystem and individual / filesystems for each client. If anyone has any suggestions on how to do this cleanly, - please let me and/or the core group know. + please let me and/or the &a.core; know. Compiling netboot for specific setups

Netboot can be compiled to support NE1000/2000 cards by changing the configuration in /sys/i386/boot/netboot/Makefile. See the comments at the top of this file. diff --git a/handbook/hw.sgml b/handbook/hw.sgml index 253450756e..86e0173e8e 100644 --- a/handbook/hw.sgml +++ b/handbook/hw.sgml @@ -1,1386 +1,1386 @@ - + PC Hardware compatibility

Issues of hardware compatibility are among the most troublesome in the computer industry today and FreeBSD is by no means immune to trouble. In this respect, FreeBSD's advantage of being able to run on inexpensive commodity PC hardware is also its liability when it comes to support for the amazing variety of components on the market. While it would be impossible to provide a exhaustive listing of hardware that FreeBSD supports, this section serves as a catalog of the device drivers included with FreeBSD and the hardware each drivers supports. Where possible and appropriate, notes about specific products are included. As FreeBSD is a volunteer project without a funded testing department, we depend on you, the user, for much of the information contained in this catalog. If you have direct experience of hardware that does or does not work with FreeBSD, please let us know by sending e-mail to doc@freebsd.org. Questions about supported hardware should be directed to questions@freebsd.org (see for more information). When submitting information or asking a question, please remember to specify exactly what version of FreeBSD you are using and include as many details of your hardware as possible. Resources on the Internet

The following links have proven useful in selecting hardware. Though some of what you see won't necessarily be specific (or even applicable) to FreeBSD, most of the hardware information out there is OS independant. Please check with the FreeBSD hardware guide to make sure that your chosen configuration is supported before making any purchases.

Sample Configurations

The following list of sample hardware configurations by no means constitutes an endorsement of a given hardware vendor or product by The FreeBSD Project. This information is provided only as a public service and merely catalogs some of the experiences that various individuals have had with different hardware combinations. Your mileage may vary. Slippery when wet. Beware of dog. Jordan's Picks

I have had fairly good luck building workstation and server configurations with the following components. I can't guarantee that you will too, nor that any of the companies here will remain "best buys" forever. I will try, when I can, to keep this list up-to-date but cannot obviously guarantee that it will be at any given time. Motherboards

The motherboard appears to be a good choice for mid-to-high range Pentium server and workstation systems. If you're really looking for performance, be also sure to get the . I feel that it's worth the extra cost. If you're looking for a 486 class motherboard, you might also investigate ASUS's offering (Note: These have become increasingly hard to get as ASUS apparently no longer manufactures them). NOTE: The Intel chip-set based motherboards do not offer memory parity logic, making it almost impossible to detect when a memory error has occurred. Those wishing to build more fault-tolerant systems should therefore buy one of the newer Triton II based motherboards, which offer both better performance and parity checking.

At the even higher end, the Intel/Venus Pro () motherboard appears to work very well with FreeBSD, as does its accompanying 200Mhz P6 (Pentium Pro) CPU. Recent price drops (plummets might be a more accurate term) have dropped P6 systems into a very affordable price bracket, at least in the United States, and for serious server applications you may wish to look no further than one of these. Disk Controllers

This one is a bit trickier, and while I used to recommend the controllers unilaterally for everything from ISA to PCI, now I tend to lean towards the 1542CF for ISA, Buslogic Bt747c for EISA and Adaptec 2940 for PCI.

If you should find that you need more than one SCSI controller in a PCI machine, you may wish to consider conserving your scarce PCI bus resources by buying the Adaptec 3940 card, which puts two SCSI controllers (and busses) in a single slot. Disk drives

In this particular game of Russian roulette, I'll make few specific recommendations except to say "SCSI over IDE whenever you can afford it." Even in small desktop configurations, SCSI often makes more sense since it allows you to easily migrate drives from server to desktop as falling drive prices make it economical to do so. If you have more than one machine to administer then think of it not simply as storage, think of it as a food chain!

I do not currently see SCSI WIDE drives as a necessary expense unless you're putting together an NFS or NEWS server that will be doing a lot of multiuser disk I/O. CDROM drives

My SCSI preferences extend to SCSI CDROM drives as well, and the XM-3501B (now released in a caddy-less model called the XM-5401B) drive has always performed well for me. Generally speaking, most SCSI CDROM drives I've seen have been of pretty solid construction (probably because they don't occupy the lower end of the market, due to their higher price) and you probably won't go wrong with an HP or NEC SCSI CDROM drive either. CD Recordable (WORM) drives

At the time of this writing, FreeBSD supports 3 types of CDR drives (though I believe they all ultimately come from Phillips anyway): The Phillips CDD 522 (Acts like a Plasmon), the PLASMON RF4100 and the HP 4020i. I myself use the HP 4020i for burning CDROMs (with 2.2-current - it does not work with 2.1.5 or earlier releases of the SCSI code) and it works very well. See on your 2.2 system for example scripts used to created ISO9660 filesystem images (with RockRidge extensions) and burn them onto an HP4020i CDR. Tape drives

I've had pretty good luck with both from and drives from .

For backup purposes, I'd have to give the higher recommendation to the Exabyte due to the more robust nature (and higher storage capacity) of 8mm tape. Video Cards

If you can also afford to buy a commercial X server for US$99 from then I can heartily recommend the card. If free X servers are more to your liking, you certainly can't go wrong with one of cards - their S3 Vision 868 and 968 based cards (the 9FX series) are pretty fast cards as well, and are supported by 's S3 server. Monitors

I have had very good luck with the , as have I with the Viewsonic offering in the same (trinitron) tube. For larger than 17", all I can recommend at the time of this writing is to not spend any less than U.S. $2,500 for a 21" monitor if that's what you really need. There are good monitors available in the >=20" range and there are also cheap monitors in the >=20" range. Unfortunately, none are both cheap and good! Networking

I can recommend the Ultra 16 controller for any ISA application and the SMC EtherPower or Compex ENET32 cards for any serious PCI based networking. Both of the PCI cards are based around DEC's DC21041 Ethernet controller chip and other cards using it, such as the Zynx ZX342 or DEC DE435, will generally work as well. For 100Mbit networking, either the SMC SMC9332DST 10/100MB or Intel EtherExpress Pro/100B cards will do a fine job. Serial

If you're looking for high-speed serial networking solutions, then makes the series, with drivers now in FreeBSD-current. also manufactures a board with T1/E1 capabilities, using software they provide.

Multiport card options are somewhat more numerous, though it has to be said that FreeBSD's support for 's products is probably the tightest, primarily as a result of that company's committment to making sure that we are adequately supplied with evaluation boards and technical specs. I've heard that the Cyclom-16Ye offers the best price/performance, though I've not checked the prices lately. Other multiport cards I've heard good things about are the BOCA and AST cards, and apparently offers an unofficial driver for their cards at location. Audio

I currently use the Ultrasound MAX due to its high sound quality and full-duplex audio capabilities (dual DMA channels). Support for Windows NT and OS/2 is fairly anemic, however, so I'm not sure that I can recommend it as an all-around card for a machine that will be running both FreeBSD and NT or OS/2. In such a scenario, I might recommend the AWE32 instead. Video

For video capture, there's really only once choice - the card. FreeBSD also supports the older video spigot card from Creative Labs, but those are getting somewhat difficult to find and the Meteor is a more current generation frame-grabber with a higher-speed PCI interface. I use one for broadcasting video on the MBONE and it works quite well! Core/Processing Motherboards, busses, and chipsets * ISA * EISA * VLB PCI

Contributed by &a.rgrimes;.25 April 1995.

Continuing updates by &a.jkh;.Last update on 26 August 1996.

Of the Intel PCI chip sets, the following list describes various types of known-brokenness and the degree of breakage, listed from worst to best.

Mercury: Cache coherency problems, especially if there are ISA bus masters behind the ISA to PCI bridge chip. Hardware flaw, only known work around is to turn the cache off. Saturn-I (ie, 82424ZX at rev 0, 1 or 2): Write back cache coherency problems. Hardware flaw, only known work around is to set the external cache to write-through mode. Upgrade to Saturn-II. Saturn-II (ie, 82424ZX at rev 3 or 4): Works fine, but many MB manufactures leave out the external dirty bit SRAM needed for write back operation. Work arounds are either run it in write through mode, or get the dirty bit SRAM installed. (I have these for the ASUS PCI/I-486SP3G rev 1.6 and later boards). Neptune: Can not run more than 2 bus master devices. Admitted Intel design flaw. Workarounds include do not run more than 2 bus masters, special hardware design to replace the PCI bus arbiter (appears on Intel Altair board and several other Intel server group MB's). And of course Intel's official answer, move to the Triton chip set, we ``fixed it there''. Triton: No known cache coherency or bus master problems, chip set does not implement parity checking. Workaround for parity issue. Use Triton-II based motherboards if you have the choice. Triton-II: All reports on motherboards using this chipset have been favorable so far. No known problems. Orion: Early versions of this chipset suffered from a PCI write-posting bug which can cause noticable performance degradation in applications where large amounts of PCI bus traffic is involved. B0 stepping or later revisions of the chipset fixed this problem. :This support chipset seems to work well, and does not suffer from any of the early Orion chipset problems. It also supports a wider variety of memory, including ECC and parity.

* CPUs/FPUs * Memory * BIOS Input/Output Devices * Video cards * Sound cards Serial ports and multiport cards &uart; &sio; &cy; * Parallel ports * Modems * Network cards * Keyboards * Mice * Other Storage Devices &esdi; &scsi; * Disk/tape controllers * SCSI * IDE * Floppy * Hard drives Tape drives

Contributed by &a.jmb;.2 July 1996.

General tape access commands

mt(1) provides generic access to the tape drives. Some of the more common commands are rewind, erase, and status. See the mt(1) manual page for a detailed description. Controller Interfaces

There are several different interfaces that support tape drives. The interfaces are SCSI, IDE, Floppy and Parallel Port. A wide variety of tape drives are available for these interfaces. Controllers are discussed in SCSI drives

The st(4) driver provides support for 8mm (Exabyte), 4mm (DAT: Digital Audio Tape), QIC (Quarter-Inch Cartridge), DLT (Digital Linear Tape), QIC Minicartridge and 9-track (remember the big reels that you see spinning in Hollywood computer rooms) tape drives. See the st(4) manual page for a detailed description.

The drives listed below are currently being used by members of the FreeBSD community. They are not the only drives that will work with FreeBSD. They just happen to be the ones that we use. 4mm (DAT: Digital Audio Tape)

8mm (Exabyte)

QIC (Quarter-Inch Cartridge)

DLT (Digital Linear Tape)

Mini-Cartridge

Autoloaders/Changers

* IDE drives Floppy drives

* Parallel port drives Detailed Information

The boot message identifier for this drive is "ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI 2"

This is a QIC tape drive.

Native capacity is 1.35GB when using QIC-1350 tapes. This drive will read and write QIC-150 (DC6150), QIC-250 (DC6250), and QIC-525 (DC6525) tapes as well.

Data transfer rate is 350kB/s using dump(8). Rates of 530kB/s have been reported when using

Production of this drive has been discontinued.

The SCSI bus connector on this tape drive is reversed from that on most other SCSI devices. Make sure that you have enough SCSI cable to twist the cable one-half turn before and after the Archive Anaconda tape drive, or turn your other SCSI devices upside-down.

Two kernel code changes are required to use this drive. This drive will not work as delivered.

If you have a SCSI-2 controller, short jumper 6. Otherwise, the drive behaves are a SCSI-1 device. When operating as a SCSI-1 device, this drive, "locks" the SCSI bus during some tape operations, including: fsf, rewind, and rewoffl.

If you are using the NCR SCSI controllers, patch the file /usr/src/sys/pci/ncr.c (as shown below). Build and install a new kernel. *** 4831,4835 **** }; ! if (np->latetime>4) { /* ** Although we tried to wake it up, --- 4831,4836 ---- }; ! if (np->latetime>1200) { /* ** Although we tried to wake it up, -

Reported by: Jonathan M. Bresler jmb@FreeBSD.ORG +

Reported by: &a.jmb;

The boot message identifier for this drive is "ARCHIVE Python 28454-XXX4ASB" "type 1 removable SCSI 2" "density code 0x8c, 512-byte blocks"

This is a DDS-1 tape drive.

Native capacity is 2.5GB on 90m tapes.

Data transfer rate is XXX.

This drive was repackaged by Sun Microsystems as model 411.

Reported by: Bob Bishop rb@gid.co.uk

The boot message identifier for this drive is "ARCHIVE VIPER 60 21116 -007" "type 1 removable SCSI 1"

This is a QIC tape drive.

Native capacity is 60MB.

Data transfer rate is XXX.

Production of this drive has been discontinued.

Reported by: Philippe Regnauld regnauld@hsc.fr

The boot message identifier for this drive is "ARCHIVE VIPER 150 21531 -004" "Archive Viper 150 is a known rogue" "type 1 removable SCSI 1". A multitude of firmware revisions exist for this drive. Your drive may report different numbers (e.g "21247 -005".

This is a QIC tape drive.

Native capacity is 150/250MB. Both 150MB (DC6150) and 250MB (DC6250) tapes have the recording format. The 250MB tapes are approximately 67% longer than the 150MB tapes. This drive can read 120MB tapes as well. It can not write 120MB tapes.

Data transfer rate is 100kB/s

This drive reads and writes DC6150 (6150MB) and DC6250 (250MB) tapes.

This drives quirks are known and pre-compiled into the scsi tape device driver (st(4)).

Under FreeBSD 2.2-current, use mt blocksize 512 to set the blocksize. (The particular drive had firmware revision 21247 -005. Other firmware revisions may behave differently) Previous versions of FreeBSD did not have this problem.

Production of this drive has been discontinued.

Reported by: Pedro A M Vazquez vazquez@IQM.Unicamp.BR

Mike Smith msmith@atrad.adelaide.edu.au

The boot message identifier for this drive is "ARCHIVE VIPER 2525 25462 -011" "type 1 removable SCSI 1"

This is a QIC tape drive.

Native capacity is 525MB.

Data transfer rate is 180kB/s at 90 inches/sec.

The drive reads QIC-525, QIC-150, QIC-120 and QIC-24 tapes. Writes QIC-525, QIC-150, and QIC-120.

Firmware revisions prior to "25462 -011" are bug ridden and will not function properly.

Production of this drive has been discontinued. -

Reported by: Hellmuth Michaelis hm@kts.org +

Reported by: &a.hm;

The boot message identifier for this drive is "Conner tape".

This is a floppy controller, minicartridge tape drive.

Native capacity is XXXX

Data transfer rate is XXX

The drive uses QIC-80 tape cartridges.

Reported by: Mark Hannon mark@seeware.DIALix.oz.au

The boot message identifier for this drive is "CONNER CTMS 3200 7.00" "type 1 removable SCSI 2".

This is a minicartridge tape drive.

Native capacity is XXXX

Data transfer rate is XXX

The drive uses QIC-3080 tape cartridges.

Reported by: Thomas S. Traylor tst@titan.cs.mci.com

The boot message identifier for this drive is "DEC TZ87 (C) DEC 9206" "type 1 removable SCSI 2" "density code 0x19"

This is a DLT tape drive.

Native capacity is 10GB.

This drive supports hardware data compression.

Data transfer rate is 1.2MB/s.

This drive is identical to the Quantum DLT2000. The drive firmware can be set to emulate several well-known drives, including an Exabyte 8mm drive. -

Reported by: Wilko Bulte wilko@yedi.iaf.nl +

Reported by: &a.wilko;

The boot message identifier for this drive is "EXABYTE EXB-2501"

This is a mini-cartridge tape drive.

Native capacity is 1GB when using MC3000XL minicartridges.

Data transfer rate is XXX

This drive can read and write DC2300 (550MB), DC2750 (750MB), MC3000 (750MB), and MC3000XL (1GB) minicartridges.

WARNING: This drive does not meet the SCSI-2 specifications. The drive locks up completely in response to a SCSI MODE_SELECT command unless there is a formatted tape in the drive. Before using this drive, set the tape blocksize with mt -f /dev/st0ctl.0 blocksize 1024 Before using a minicartridge for the first time, the minicartridge must be formated. FreeBSD 2.1.0-RELEASE and earlier: /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0" (Alternatively, fetch a copy of the scsiformat shell script from FreeBSD 2.1.5/2.2.) FreeBSD 2.1.5 and later: /sbin/scsiformat -q -w /dev/rst0.ctl

Right now, this drive cannot really be recommended for FreeBSD.

Reported by: Bob Beaulieu ez@eztravel.com

The boot message identifier for this drive is "EXABYTE EXB-8200 252X" "type 1 removable SCSI 1"

This is an 8mm tape drive.

Native capacity is 2.3GB.

Data transfer rate is 270kB/s.

This drive is fairly slow in responding to the SCSI bus during boot. A custom kernel may be required (set SCSI_DELAY to 10 seconds).

There are a large number of firmware configurations for this drive, some have been customized to a particular vendor's hardware. The firmware can be changed via EPROM replacement.

Production of this drive has been discontinued.

Reported by: Mike Smith msmith@atrad.adelaide.edu.au

The boot message identifier for this drive is "EXABYTE EXB-8500-85Qanx0 0415" "type 1 removable SCSI 2"

This is an 8mm tape drive.

Native capacity is 5GB.

Data transfer rate is 300kB/s.

Reported by: Greg Lehey grog@lemis.de

The boot message identifier for this drive is "EXABYTE EXB-85058SQANXR1 05B0" "type 1 removable SCSI 2"

This is an 8mm tape drive.

Native capacity is 2GB.

The drive supports hardware data compression.

Data transfer rate is 300kB/s.

Reported by: Glen Foster gfoster@gfoster.com

The boot message identifier for this drive is "HP C1533A 9503" "type 1 removable SCSI 2".

This is a DDS-2 tape drive. DDS-2 means hardware data compression and narrower tracks for increased data capacity.

Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression.

Data transfer rate is 510kB/s.

This drive is used in Hewlett-Packard's SureStore 6000eU and 6000i tape drives and C1533A DDS-2 DAT drive.

The drive has a block of 8 dip switches. The proper settings for FreeBSD are: 1 ON; 2 ON; 3 OFF; 4 ON; 5 ON; 6 ON; 7 ON; 8 ON. switch 1 2 Result ON ON Compression enabled at power-on, with host control ON OFF Compression enabled at power-on, no host control OFF ON Compression disabled at power-on; the host is allowed to control compression OFF OFF Compression disabled at power-on, no host control

Switch 3 controls MRS (Media Recognition System). MRS tapes have stripes on the transparent leader. These identify the tape as DDS (Digital Data Storage) grade media. Tapes that do not have the stripes will be treated as write-protected. Switch 3 OFF enables MRS. Switch 3 ON disables MRS.

Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 2 of these drives. Neither lasted more than 5 months. -

Reported by: Stefan Esser se@ZPR.Uni-Koeln.DE +

Reported by: &a.se;

The boot message identifier for this drive is "HP HP35470A T503" type 1 removable SCSI 2" "Sequential-Access density code 0x13, variable blocks".

This is a DDS-1 tape drive. DDS-1 is the original DAT tape format.

Native capacity is 2GB when using 90m tapes.

Data transfer rate is 183kB/s.

The same mechanism is used in Hewlett-Packard's SureStore tape drive, C35470A DDS format DAT drive, C1534A DDS format DAT drive and HP C1536A DDS format DAT drive.

The HP C1534A DDS format DAT drive has two indicator lights, one green and one amber. The green one indicates tape action: slow flash during load, steady when loaded, fast flash during read/write operations. The amber one indicates warnings: slow flash when cleaning is required or tape is nearing the end of its useful life, steady indicates an hard fault. (factory service required?)

Reported by Gary Crutcher gcrutchr@nightflight.com

The boot message identifier for this drive is "".

This is a DDS-2 tape drive. DDS-2 means hardware data compression and narrower tracks for increased data capacity.

Native capacity is 24GB when using 120m tapes. This drive supports hardware data compression.

Data transfer rate is 510kB/s (native).

This drive is used in Hewlett-Packard's SureStore tape drive.

The drive has two selectors on the rear panel. The selector closer to the fan is SCSI id. The other selector should be set to 7.

There are four internal switches. These should be set: 1 ON; 2 ON; 3 ON; 4 OFF.

At present the kernel drivers do not automatically change tapes at the end of a volume. This shell script can be used to change tapes: #!/bin/sh PATH="/sbin:/usr/sbin:/bin:/usr/bin"; export PATH usage() { echo "Usage: dds_changer [123456ne] raw-device-name echo "1..6 = Select cartridge" echo "next cartridge" echo "eject magazine" exit 2 } if [ $# -ne 2 ] ; then usage fi cdb3=0 cdb4=0 cdb5=0 case $1 in [123456]) cdb3=$1 cdb4=1 ;; n) ;; e) cdb5=0x80 ;; ?) usage ;; esac scsi -f $2 -s 100 -c "1b 0 0 $cdb3 $cdb4 $cdb5"

The boot message identifier for this drive is "HP HP35450A -A C620" "type 1 removable SCSI 2" "Sequential-Access density code 0x13"

This is a DDS-1 tape drive. DDS-1 is the original DAT tape format.

Native capacity is 1.2GB.

Data transfer rate is 160kB/s.

Reported by: mark thompson mark.a.thompson@pobox.com

The boot message identifier for this drive is "HP HP35470A 9 09" type 1 removable SCSI 2"

This is a DDS-1 tape drive. DDS-1 is the original DAT tape format.

Native capacity is 2GB when using 90m tapes.

Data transfer rate is 183kB/s.

The same mechanism is used in Hewlett-Packard's SureStore tape drive, C35470A DDS format DAT drive, C1534A DDS format DAT drive, and HP C1536A DDS format DAT drive.

Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 5 of these drives. None lasted more than 9 months.

Reported by: David Dawes dawes@rf900.physics.usyd.edu.au (9 09)

The boot message identifier for this drive is "HP HP35480A 1009" "type 1 removable SCSI 2" "Sequential-Access density code 0x13".

This is a DDS-DC tape drive. DDS-DC is DDS-1 with hardware data compression. DDS-1 is the original DAT tape format.

Native capacity is 2GB when using 90m tapes. This drive supports hardware data compression

Data transfer rate is 183kB/s.

This drive is used in Hewlett-Packard's SureStore and tape drives and C35480A DDS format DAT drive..

This drive will occasionally hang during a tape eject operation (mt offline). Pressing the front panel button will eject the tape and bring the tape drive back to life.

WARNING: HP 35480-03110 only. On at least two occasions this tape drive when used with FreeBSD 2.1.0, an IBM Server 320 and an 2940W SCSI controller resulted in all SCSI disk partitions being lost. The problem has not be analyzed or resolved at this time.

There are at least two significantly different models: one is a DDS-1 and the other DDS-2. The DDS-1 version is "SDT-5000 3.02". The DDS-2 version is "SONY SDT-5000 327M". The DDS-2 version has a 1MB cache. This cache is able to keep the tape streaming in almost any circumstances.

The boot message identifier for this drive is "SONY SDT-5000 3.02" "type 1 removable SCSI 2" "Sequential-Access density code 0x13"

Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression.

Data transfer rate is depends upon the model or the drive. The rate is 630kB/s for the "SONY SDT-5000 327M" while compressing the data. For the "SONY SDT-5000 3.02", the data transfer rate is 225kB/s.

In order to get this drive to stream, set the blocksize to 512 bytes (mt blocksize 512) reported by Kenneth Merry ken@ulc199.residence.gatech.edu"

"SONY SDT-5000 327M" information reported by Charles Henrich henrich@msu.edu -

Reported by: Jean-Marc Zucconi jmz@cabri.obs-besancon.fr +

Reported by: &a.jmz;

The boot message identifier for this drive is "TANDBERG TDC 3600 =08:" "type 1 removable SCSI 2"

This is a QIC tape drive.

Native capacity is 150/250MB.

This drive has quirks which are known and work around code is present in the scsi tape device driver (st(4)). Upgrading the firmware to XXX version will fix the quirks and provide SCSI 2 capabilities.

Data transfer rate is 80kB/s.

IBM and Emerald units will not work. Replacing the firmware EPROM of these units will solve the problem.

Reported by: Michael Smith msmith@atrad.adelaide.edu.au

This is very similar to the drive. -

Reported by: Jörg Wunsch joerg_wunsch@uriah.heep.sax.de +

Reported by: &a.joerg;

The boot message identifier for this drive is "TANDBERG TDC 4222 =07" "type 1 removable SCSI 2"

This is a QIC tape drive.

Native capacity is 2.5GB. The drive will read all cartridges from the 60 MB (DC600A) upwards, and write 150 MB (DC6150) upwards. Hardware compression is optionally supported for the 2.5 GB cartridges.

This drives quirks are known and pre-compiled into the scsi tape device driver (st(4)) beginning with FreeBSD 2.2-current. For previous versions of FreeBSD, use mt to read one block from the tape, rewind the tape, and then execute the backup program (mt fsr 1; mt rewind; dump ...)

Data transfer rate is 600kB/s (vendor claim with compression), 350 KB/s can even be reached in start/stop mode. The rate decreases for smaller cartridges. -

Reported by: Jörg Wunsch joerg_wunsch@uriah.heep.sax.de +

Reported by: &a.joerg;

The boot message identifier for this drive is "WANGTEK 5525ES SCSI REV7 3R1" "type 1 removable SCSI 1" "density code 0x11, 1024-byte blocks"

This is a QIC tape drive.

Native capacity is 525MB.

Data transfer rate is 180kB/s.

The drive reads 60, 120, 150, and 525MB tapes. The drive will not write 60MB (DC600 cartridge) tapes. In order to overwrite 120 and 150 tapes reliably, first erase (mt erase) the tape. 120 and 150 tapes used a wider track (fewer tracks per tape) than 525MB tapes. The "extra" width of the previous tracks is not overwritten, as a result the new data lies in a band surrounded on both sides by the previous data unless the tape have been erased.

This drives quirks are known and pre-compiled into the scsi tape device driver (st(4)).

Other firmware revisions that are known to work are: M75D

Reported by: Marc van Kempen marc@bowtie.nl "REV73R1" Andrew Gordon Andrew.Gordon@net-tel.co.uk "M75D"

The boot message identifier for this drive is "WANGTEK 6200-HS 4B18" "type 1 removable SCSI 2" "Sequential-Access density code 0x13"

This is a DDS-1 tape drive.

Native capacity is 2GB using 90m tapes.

Data transfer rate is 150kB/s.

Reported by: Tony Kimball alk@Think.COM * Problem drives * CD-ROM drives * Other * Adding and reconfiguring disks Tapes and backups * What about backups to floppies? Tape Media

4mm tapes are replacing QIC as the workstation backup media of choice. This trend accelerated greatly when Conner purchased Archive, a leading manufacturer of QIC drives, and then stopped production of QIC drives. 4mm drives are small and quiet but do not have the reputation for reliability that is enjoyed by 8mm drives. The cartridges are less expensive and smaller (3 x 2 x 0.5 inches, 76 x 51 x 12 mm) than 8mm cartridges. 4mm, like 8mm, has comparatively short head life for the same reason, both use helical scan.

Data thruput on these drives starts ~150kB/s, peaking at ~500kB/s. Data capacity starts at 1.3 GB and ends at 2.0 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. Multi-drive tape library units can have 6 drives in a single cabinet with automatic tape changing. Library capacities reach 240 GB.

4mm drives, like 8mm drives, use helical-scan. All the benefits and drawbacks of helical-scan apply to both 4mm and 8mm drives.

Tapes should be retired from use after 2,000 passes or 100 full backups.

8mm tapes are the most common SCSI tape drives; they are the best choice of exchanging tapes. Nearly every site has an exabyte 2 GB 8mm tape drive. 8mm drives are reliable, convienent and quiet. Cartidges are inexpensive and small (4.8 x 3.3 x 0.6 inches; 122 x 84 x 15 mm). One downside of 8mm tape is relatively short head and tape life due to the high rate of relative motion of the tape across the heads.

Data thruput ranges from ~250kB/s to ~500kB/s. Data sizes start at 300 MB and go up to 7 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. These drives are available as single units or multi-drive tape libraries with 6 drives and 120 tapes in a single cabinet. Tapes are changed automatically by the unit. Library capacities reach 840+ GB.

Data is recorded onto the tape using helical-scan, the heads are positioned at an angle to the media (approximately 6 degrees). The tape wraps around 270 degrees of the spool that holds the heads. The spool spins while the tape slides over the spool. The result is a high density of data and closely packed tracks that angle across the tape from one edge to the other.

QIC-150 tapes and drives are, perhaps, the most common tape drive and media around. QIC tape drives are the least expensive "serious" backup drives. The downside is the cost of media. QIC tapes are expensive compared to 8mm or 4mm tapes, up to 5 times the price per GB data storage. But, if your needs can be satisified with a half-dozen tapes, QIC may be the correct choice. QIC is the most common tape drive. Every site has a QIC drive of some density or another. Therein lies the rub, QIC has a large number of densities on physically similar (sometimes identical) tapes. QIC drives are not quiet. These drives audibly seek before they begin to record data and are clearly audible whenever reading, writing or seeking. QIC tapes measure (6 x 4 x 0.7 inches; 152 x 102 x 17 mm). , which also use 1/4" wide tape are discussed separately. Tape libraries and changers are not available.

Data thruput ranges from ~150kB/s to ~500kB/s. Data capacity ranges from 40 MB to 15 GB. Hardware compression is available on many of the newer QIC drives. QIC drives are less frequently installed; they are being supplanted by DAT drives.

Data is recorded onto the tape in tracks. The tracks run along the long axis of the tape media from one end to the other. The number of tracks, and therefore the width of a track, varies with the tape's capacity. Most if not all newer drives provide backward-compatibility at least for reading (but often also for writing). QIC has a good reputation regarding the safety of the data (the mechanics are simpler and more robust than for helical scan drives).

Tapes should be retired from use after 5,000 backups.

DLT has the fastest data transfer rate of all the drive types listed here. The 1/2" (12.5mm) tape is contained in a single spool cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a swinging gate along one entire side of the cartridge. The drive mechanism opens this gate to extract the tape leader. The tape leader has an oval hole in it which the drive uses to "hook" the tape. The take-up spool is located inside the tape drive. All the other tape cartridges listed here (9 track tapes are the only exception) have both the supply and take-up spools located inside the tape cartridge itself. Data thruput is approximately 1.5MB/s, three times the thruput of 4mm, 8mm, or QIC tape drives. Data capacities range from 10GB to 20GB for a single drive. Drives are available in both multi-tape changers and multi-tape, multi-drive tape libraries containing from 5 to 900 tapes over 1 to 20 drives, providing from 50GB to 9TB of storage. Data is recorded onto the tape in tracks parallel to the direction of travel (just like QIC tapes). Two tracks are written at once. Read/write head lifetimes are relatively long; once the tape stops moving, there is no relative motion between the heads and the tape. Using a new tape for the first time

The first time that you try to read or write a new, completely blank tape, the operation will fail. The console messages should be similar to: st0(ncr1:4:0): NOT READY asc:4,1 st0(ncr1:4:0): Logical unit is in process of becoming ready The tape does not contain an Identifier Block (block number 0). All QIC tape drives since the adoption of QIC-525 standard write an Identifier Block to the tape. There are two solutions:

mt fsf 1 causes the tape drive to write an Identifier Block to the tape.

Use the front panel button to eject the tape.

Re-insert the tape and dump(8) data to the tape.

dump(8) will report DUMP: End of tape detected and the console will show: HARDWARE FAILURE info:280 asc:80,96

rewind the tape using: mt rewind

Subsequent tape operations are successful. Backup Programs

The three major programs are dump(8), tar(1), and cpio(1). Dump and Restore

dump(8) and restore(8) are the traditional Unix backup programs. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the filesystems. dump(8) backs up devices, entire filesystems, not parts of a filesystem and not directory trees that span more than one filesystem, using either soft links ln(1) or mounting one filesystem onto another. dump(8) does not write files and directories to tape, but rather writes the data blocks that are the building blocks of files and directories. dump(8) has quirks that remain from its early days in Version 6 of ATT Unix (circa 1975). The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives.

rdump(8) and rrestore(8) backup data aross the network to a tape drive attached to another computer. Both programs rely upon rcmd(3) and ruserok(3) to access the remote tape drive. Therefore, the user performing the backup must have rhosts access to the remote computer. The arguments to rdump(8) and rrestore(8) must suitable to use on the remote computer. (e.g. When rdump'ing from a FreeBSD computer to an Exabyte tape drive connected to a Sun called komodo, use: /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrst8 /dev/rsd0a 2>&1) Beware: there are security implications to allowing rhosts commands. Evaluate your situation carefully. Tar

tar(1) also dates back to Version 6 of ATT Unix (circa 1975). tar(1) operates in cooperation with the filesystem; tar(1) writes files and directories to tape. tar(1) does not support the full range of options that are available from cpio(1), but tar(1) does not require the unusual command pipeline that cpio(1) uses.

tar(1) does not support backups across the network. You can use a pipeline and rsh(1) to send the data to a remote tape drive. (XXX add an example command) Cpio

cpio(1) is the original Unix file interchange tape program for magnetic media. cpio(1) has options (among many others) to perform byte-swapping, write a number of different archives format, and pipe the data to other programs. This last feature makes cpio(1) and excellent choice for installation media. cpio(1) does not know how to walk the directory tree and a list of files must be provided thru STDIN.

cpio(1) does not support backups across the network. You can use a pipeline and rsh(1) to send the data to a remote tape drive. (XXX add an example command)

Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and network communications with the Amanda server. A common problem at locations with a number of large disks is the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem. Amanda can use a "holding disk" to backup several filesystems at the same time. Amanda creates "archive sets": a group of tapes used over a period of time to create full backups of all the filesystems listed in Amanda's configuration file. The "archive set" also contains nightly incremental (or differential) backups of all the filesystems. Restoring a damaged filesystem requires the most recent full backup and the incremental backups.

The configuration file provides fine control backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is available as either a port or a package, it is not installed by default. Do nothing

"Do nothing" is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it!

If your time and your data is worth little to nothing, then "Do nothing" is the most suitable backup program for your computer. But beware, Unix is a useful tool, you may find that within six months you have a collection of files that are valuable to you.

"Do nothing" is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by your computer. An example is the files that comprise these handbook pages-they have been generated from SGML input files. Creating backups of these HTML files is not necessary. The SGML source files are backed up regularly. Which Backup Program is Best?

dump(8) Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of Unix filesystems is dump(8). Elizabeth created filesystems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by do a backup and restore of that filesystems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwriteable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. Emergency Restore Procedure Before the Disaster

There are only four steps that you need to perform in preparation for any disaster that may occur.

First, print the disklabel from each of your disks (e.g. disklabel sd0 | lpr), your filesystem table (/etc/fstab) and all boot messages, two copies of each.

Second, determine the boot and fixit floppies (boot.flp and fixit.flp) have all your devices. The easiest way to check is to reboot your machine with the boot floppy in the floppy drive and check the boot messages. If all your devices are listed and functional, skip on to step three.

Otherwise, you have to create two custom bootable floppies which has a kernel that can mount your all of your disks and access your tape drive. These floppies must contain: fdisk(8), disklabel(8), newfs(8), mount(8), and whichever backup program you use. These programs must be statically linked. If you use dump(8), the floppy must contain restore(8).

Third, create backup tapes regularly. Any changes that you make after your last backup may be irretrievably lost. Write-protect the backup tapes.

Fourth, test the floppies (either boot.flp and fixit.flp or the two custom bootable floppies you made in step two.) and backup tapes. Make notes of the procedure. Store these notes with the bootable floppy, the printouts and the backup tapes. You will be so distraught when restoring that the notes may prevent you from destroying your backup tapes (How? In place of tar xvf /dev/rst0, you might accidently type tar cvf /dev/rst0 and over-write your backup tape).

For an added measure of security, make bootable floppies and two backup tapes each time. Store one of each at a remote location. A remote location is NOT the basement of the same office building. A number of firms in the World Trade Center learned this lesson the hard way. A remote location should be physically separated from your computers and disk drives by a significant distance.

An example script for creating a bootable floppy: #!/bin/sh # # create a restore floppy # # format the floppy # PATH=/bin:/sbin:/usr/sbin:/usr/bin fdformat -q fd0 if [ $? -ne 0 ] then echo "Bad floppy, please use a new one" exit 1 fi # place boot blocks on the floppy # disklabel -w -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd /dev/rfd0c fd1440 # # newfs the one and only partition # newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/rfd0a # # mount the new floppy # mount /dev/fd0a /mnt # # create required directories # mkdir /mnt/dev mkdir /mnt/bin mkdir /mnt/sbin mkdir /mnt/etc mkdir /mnt/root mkdir /mnt/mnt # for the root partition mkdir /mnt/tmp mkdir /mnt/var # # populate the directories # if [ ! -x /sys/compile/MINI/kernel ] then cat << EOM The MINI kernel does not exist, please create one. Here is an example config file: # # MINI -- A kernel to get FreeBSD on onto a disk. # machine "i386" cpu "I486_CPU" ident MINI maxusers 5 options INET # needed for _tcp _icmpstat _ipstat # _udpstat _tcpstat _udb options FFS #Berkeley Fast File System options FAT_CURSOR #block cursor in syscons or pccons options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options NCONS=2 #1 virtual consoles options USERCONFIG #Allow user configuration with -c XXX config kernel root on sd0 swap on sd0 and sd1 dumps on sd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller ncr0 controller scbus0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sd0 device sd1 device sd2 device st0 pseudo-device loop # required by INET pseudo-device gzip # Exec gzipped a.out's EOM exit 1 fi cp -f /sys/compile/MINI/kernel /mnt gzip -c -best /sbin/init > /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes # cd /mnt/dev ./MAKEDEV std ./MAKEDEV sd0 ./MAKEDEV sd1 ./MAKEDEV sd2 ./MAKEDEV st0 ./MAKEDEV pty0 cd / # # create minimum filesystem table # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < After the Disaster

The key question is: did your hardware survive? You have been doing regular backups so there is no need to worry about the software.

If the hardware has been damaged. First, replace those parts that have been damaged.

If your hardware is okay, check your floppies. If you are using a custom boot floppy, boot single-user (type "-s" at the "boot:" prompt). Skip the following paragraph.

If you are using the boot.flp and fixit.flp floppies, keep reading. Insert the boot.flp floppy in the first floppy drive and boot the computer. The original install menu will be displayed on the screen. Select the "Fixit--Repair mode with CDROM or floppy." option. Insert the fixit.flp when prompted. restore and the other programs that you need are located in /mnt2/stand.

Recover each filesystem separately.

Try to mount(8) (e.g. mount /dev/sd0a /mnt) the root partition of your first disk. If the disklabel was damaged, use disklabel(8) to re-partition and label the disk to match the label that your printed and saved. Use newfs(8) to re-create the filesystems. Re-mount the root partition of the floppy read-write ("mount -u -o rw /mnt"). Use your backup program and backup tapes to recover the data for this filesystem (e.g. restore vrf /dev/st0). Unmount the filesystem (e.g. umount /mnt) Repeat for each filesystem that was damaged.

Once your system is running, backup your data onto new tapes. Whatever caused the crash or data loss may strike again. An another hour spent now, may save you from further distress later. * I did not prepare for the Disaster, What Now? * Serial ports * Sound cards * PCMCIA * Other diff --git a/handbook/lists.sgml b/handbook/lists.sgml index c5c31a243b..a06e5d5c41 100644 --- a/handbook/lists.sgml +++ b/handbook/lists.sgml @@ -1,61 +1,67 @@ - + "> "> "> "> "> "> "> "> "> "> "> "> "> + +"> + + diff --git a/handbook/mirrors.sgml b/handbook/mirrors.sgml index 11b49dd7b2..4f4cb769da 100644 --- a/handbook/mirrors.sgml +++ b/handbook/mirrors.sgml @@ -1,568 +1,566 @@ - + Obtaining FreeBSD

The official sources for FreeBSD available via anonymous FTP from: and on CD-ROM from Walnut Creek CDROM: Walnut Creek CDROM 1547 Palos Verdes Mall, Suite 260 Walnut Creek CA 94596 USA Phone: +1 510 674-0783 Fax: +1 510 674-0821 Email: WWW:

Additionally, FreeBSD is available via anonymous FTP from the following mirror sites. If you choose to obtain FreeBSD via anonymous FTP, please try to use a site near you. , , , , , , , , , , , , , , , , , , , , , , . In case of problems, please contact the for this domain. In case of problems, please contact the for this domain. In case of problems, please contact the for this domain. Contact: . In case of problems, please contact the for this domain. In case of problems, please contact the for this domain. Contact: . In case of problems, please contact the for this domain. Contact: . In case of problems, please contact the for this domain. Contact: . Contact: . In case of problems, please contact the for this domain. In case of problems, please contact the for this domain. In case of problems, please contact the for this domain. Contact: . Contact: . Contact: . In case of problems, please contact the for this domain. In case of problems, please contact the for this domain. In case of problems, please contact the for this domain. Contact: . In case of problems, please contact the for this domain. In case of problems, please contact the for this domain. 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: South Africa for this domain. Brazil for this domain. Finland Contact: .

CTM/FreeBSD is available via anonymous FTP from the following mirror sites. If you choose to obtain CTM via anonymous FTP, please try to use a site near you. -In case of problems, please contact Poul-Henning Kamp -. - +In case of problems, please contact &a.phk;. California Denmark Germany Taiwan If you did not find a mirror near to you or the mirror is incomplete, try at . FTP search is a great free archie server in Trondheim, Norway. diff --git a/handbook/printing.sgml b/handbook/printing.sgml index 3be5a13756..e234ff63c8 100644 --- a/handbook/printing.sgml +++ b/handbook/printing.sgml @@ -1,3876 +1,3876 @@ Printing

Contributed by &a.kelly;30 September 1995 In order to use printers with FreeBSD, you will need to set them up to work with the Berkeley line printer spooling system, also known as the LPD spooling system. It is the standard printer control system in FreeBSD. This section introduces the LPD spooling system, often simply called LPD. If you are already familiar with LPD or another printer spooling system, you may wish to skip to section . What the Spooler Does

LPD controls everything about a host's printers. It is responsible for a number of things: It controls access to attached printers and printers attached to other hosts on the network. It enables users to submit files to be printed; these submissions are known as It prevents multiple users from accessing a printer at the same time by maintaining a It can print It takes care of communications parameters for printers connected on serial ports. It can send jobs over the network to another LPD spooler on another host. It can run special filters to format jobs to be printed for various printer languages or printer capabilities. It can account for printer usage. Through a configuration file, and by providing the special filter programs, you can enable the LPD system to do all or some subset of the above for a great variety of printer hardware. Why You Should Use the Spooler

If you are the sole user of your system, you may be wondering why you should bother with the spooler when you don't need access control, header pages, or printer accounting. While it's possible to enable direct access to a printer, you should use the spooler anyway since LPD prints jobs in the background; you don't have to wait for data to be copied to the printer. LPD can conveniently run a job to be printed through filters to add date/time headers or convert a special file format (such as a TeX DVI file) into a format the printer will understand. You will not have to do these steps manually. Many free and commercial programs that provide a print feature usually expect to talk to the spooler on your system. By setting up the spooling system, you will more easily support other software you may later add or already have. Setting Up the Spooling System

To use printers with the LPD spooling system, you will need to set up both your printer hardware and the LPD software. This document describes two levels of setup: See section to learn how to connect a printer, tell LPD how to communicate with it, and print plain text files to the printer. See section to find out how to print a variety of special file formats, to print header pages, to print across a network, to control access to printers, and to do printer accounting. Simple Printer Setup

This section tells how to configure printer hardware and the LPD software to use the printer. It teaches the basics: Section gives some hints on connecting the printer to a port on your computer. Section shows how to setup the LPD spooler configuration file /etc/printcap. If you are setting up a printer that uses a network protocol to accept data to print instead of a serial or parallel interface, see . Although this section is called ``Simple Printer Setup,'' it is actually fairly complex. Getting the printer to work with your computer and the LPD spooler is the hardest part. The advanced options like header pages and accounting are fairly easy once you get the printer working. Hardware Setup

This section tells about the various ways you can connect a printer to your PC. It talks about the kinds of ports and cables, and also the kernel configuration you may need to enable FreeBSD to speak to the printer. If you have already connected your printer and have successfully printed with it under another operating system, you can probably skip to section . Ports and Cables

Nearly all printers you can get for a PC today support one or both of the following interfaces: Parallel interfaces are sometimes known as ``Centronics'' interfaces, named after the connector type on the printer. In general, serial interfaces are slower than parallel interfaces. Parallel interfaces usually offer just one-way communication (computer to printer) while serial gives you two-way. Many newer parallel ports can also receive data from the printer, but only few printers need to send data back to the computer. And FreeBSD does not support two-way parallel communication yet. Usually, the only time you need two-way communication with the printer is if the printer speaks PostScript. PostScript printers can be very verbose. In fact, PostScript jobs are actually programs sent to the printer; they need not produce paper at all and may return results directly to the computer. PostScript also uses two-way communication to tell the computer about problems, such as errors in the PostScript program or paper jams. Your users may be appreciative of such information. Furthermore, the best way to do effective accounting with a PostScript printer requires two-way communication: you ask the printer for its page count (how many pages it has printed in its lifetime), then send the user's job, then ask again for its page count. Subtract the two values and you know how much paper to charge the user. So, which interface should you use? If you need two-way communication, use a serial port. FreeBSD does not yet support two-way communication over a parallel port. If you do not need two-way communication and can pick parallel or serial, prefer the parallel interface. It keeps a serial port free for other peripherals---such as a terminal or a modem---and is faster most of the time. It is also easier to configure. Finally, use whatever works. Parallel Ports

To hook up a printer using a parallel interface, connect the Centronics cable between the printer and the computer. The instructions that came with the printer, the computer, or both should give you complete guidance. Remember which parallel port you used on the computer. The first parallel port is /dev/lpt0 to FreeBSD; the second is /dev/lpt1, and so on. Serial Ports

To hook up a printer using a serial interface, connect the proper serial cable between the printer and the computer. The instructions that came with the printer, the computer, or both should give you complete guidance. If you are unsure what the ``proper serial cable'' is, you may wish to try one of the following alternatives: A A A You should also set up the communications parameters for the printer, usually through front-panel controls or DIP switches on the printer. Choose the highest bps (bits per second, sometimes Software Setup

This section describes the software setup necessary to print with the LPD spooling system in FreeBSD. Here is an outline of the steps involved: Configure your kernel, if necessary, for the port you are using for the printer; section tells you what you need to do. Set the communications mode for the parallel port, if you are using a parallel port; section gives details. Test if the operating system can send data to the printer. Section gives some suggestions on how to do this. Set up LPD for the printer by modifying the file /etc/printcap. Section shows you how. Kernel Configuration

The operating system kernel is compiled to work with a specific set of devices. The serial or parallel interface for your printer is a part of that set. Therefore, it might be necessary to add support for an additional serial or parallel port if your kernel is not already configured for one. To find out if the kernel you are currently using supports a serial interface, type dmesg | grep sio where sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A then the kernel supports the port. To find out if the kernel supports a parallel interface, type dmesg | grep lpt where lpt0 at 0x378-0x37f on isa then the kernel supports the port. You might have to reconfigure your kernel in order for the operating system to recognize and use the parallel or serial port you are using for the printer. To add support for a serial port, see the section on kernel configuration. To add support for a parallel port, see that section Adding /dev Entries for the Ports

Even though the kernel may support communication along a serial or parallel port, you will still need a software interface through which programs running on the system can send and receive data. That is what entries in the /dev directory are for. To add a /dev entry for a port: Become root with the Change to the /dev directory: cd /dev Type ./MAKEDEV where Type ls -l to make sure the device entry got created. Setting the Communication Mode for the Parallel Port

When you are using the parallel interface, you can choose whether FreeBSD should use interrupt-driven or polled communication with the printer. The The The interrupt-driven method is somewhat faster but uses up a precious IRQ line. You should use whichever one works. You can set the communications mode in two ways: by configuring the kernel or by using the To set the communications mode by configuring the kernel: Edit your kernel configuration file. Look for or add an If you want interrupt-driven mode, add the device lpt0 at isa? port? tty irq where If you want polled mode, do not add the device lpt0 at isa? port? tty vector lptintr Save the file. Then configure, build, and install the kernel, then reboot. See for more details. To set the communications mode with Type lptcontrol -i -u to set interrupt-driven mode for Type lptcontrol -p -u to set polled-mode for You could put these commands in your /etc/rc.local file to set the mode each time your system boots. See lptcontrol(8) for more information. Checking Printer Communications

Before proceeding to configure the spooling system, you should make sure the operating system can successfully send data to your printer. It is a lot easier to debug printer communication and the spooling system separately. To test the printer, we will send some text to it. For printers that can immediately print characters sent to them, the program %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Is this thing working?) show showpage Checking a Parallel Printer

This section tells you how to check if FreeBSD can communicate with a printer connected to a parallel port. To test a printer on a parallel port: Become root with Send data to the printer. If the printer can print plain text, then use lptest > /dev/lpt where If the printer understands PostScript or other printer language, then send a small program to the printer. Type cat > /dev/lpt Then, line by line, type the program Alternatively, you can put the program in a file and type cat /dev/lpt where You should see something print. Do not worry if the text doesn't look right; we'll fix such things later. Checking a Serial Printer

This section tells you how to check if FreeBSD can communicate with a printer on a serial port. To test a printer on a serial port: Become root with Edit the file /etc/remote. Add the following entry: printer:dv=/dev/ where Here is a sample entry for a printer connected via a serial line to the third serial port at 19200 bps with no parity: printer:dv=/dev/ttyd2:br#19200:pa=none Connect to the printer with tip printer If this step does not work, edit the file /etc/remote again and try using /dev/cuaa instead of /dev/ttyd. Send data to the printer. If the printer can print plain text, then use ~$lptest If the printer understands PostScript or other printer language, then send a small program to the printer. Type the program, line by line, Alternatively, you can put the program in a file and type ˜> where You should see something print. Do not worry if the text does not look right; we will fix that later. Enabling the Spooler: The /etc/printcap File

At this point, your printer should be hooked up, your kernel configured to communicate with it (if necessary), and you have been able to send some simple data to the printer. Now, we are ready to configure LPD to control access to your printer. You configure LPD by editing the file /etc/printcap. The LPD spooling system reads this file each time the spooler is used, so updates to the file take immediate effect. The format of the /etc/printcap. The format is identical to other capability files like /usr/share/misc/termcap and /etc/remote. For complete information about the format, see the cgetent(3). The simple spooler configuration consists of the following steps: Pick a name (and a few convenient aliases) for the printer, and put them in the /etc/printcap file; see . Turn off header pages (which are on by default) by inserting the . Make a spooling directory, and specify its location with the . Set the /dev entry to use for the printer, and note it in /etc/printcap with the . Also, if the printer is on a serial port, set up the communication parameters with the . Install a plain text input filter; see Test the setup by printing something with the and . tells how to do this. Naming the Printer

The first (easy) step is to pick a name for your printer. It really does not matter whether you choose functional or whimsical names since you can also provide a number aliases for the printer. At least one of the printers specified in the /etc/printcap should have the alias /etc/printcap file. The name of the printer should start in the leftmost column. Separate each alias with a vertical bar and put a colon after the last alias. In the following example, we start with a skeletal /etc/printcap that defines two printers (a Diablo 630 line printer and a Panasonic KX-P4455 PostScript laser printer): # # /etc/printcap for host rose # rattan|line|diablo|lp|Diablo 630 Line Printer: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: In this example, the first printer is named Suppressing Header Pages

The LPD spooling system will by default print a /etc/printcap. Here is the example /etc/printcap with # # /etc/printcap for host rose - no header pages anywhere # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: Note how we used the correct format: the first line starts in the leftmost column, and subsequent lines are indented with a single TAB. Every line in an entry except the last ends in a backslash character. Making the Spooling Directory

The next step in the simple spooler setup is to make a /var/spool. It is not necessary to backup the contents of spooling directories, either. Recreating them is as simple as running mkdir /var/spool/printer-name However, if you have a lot of printers on your network, you might want to put the spooling directories under a single directory that you reserve just for printing with LPD. We will do this for our two example printers mkdir /var/spool/lpd mkdir /var/spool/lpd/rattan mkdir /var/spool/lpd/bamboo chown daemon.daemon /var/spool/lpd/rattan chown daemon.daemon /var/spool/lpd/bamboo chmod 770 /var/spool/lpd/rattan chmod 770 /var/spool/lpd/bamboo Finally, you need to tell LPD about these directories using the /etc/printcap file. You specify the pathname of the spooling directory with the # # /etc/printcap for host rose - added spooling directories # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: Note that the name of the printer starts in the first column but all other entries describing the printer should be indented with a tab and each line escaped with a backslash. If you do not specify a spooling directory with /var/spool/lpd as a default. Identifying the Printer Device

In section , we identified which entry in the /dev directory FreeBSD will use to communicate with the printer. Now, we tell LPD that information. When the spooling system has a job to print, it will open the specified device on behalf of the filter program (which is responsible for passing data to the printer). List the /dev entry pathname in the /etc/printcap file using the /etc/printcap: # # /etc/printcap for host rose - identified what devices to use # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: If you do not specify the /etc/printcap file, LPD uses /dev/lp as a default. /dev/lp currently does not exist in FreeBSD. If the printer you are installing is connected to a parallel port, skip to the section . Otherwise, be sure to follow the instructions in the next section. Configuring Spooler Communication Parameters

For printers on serial ports, LPD can set up the bps rate, parity, and other serial communication parameters on behalf of the filter program that sends data to the printer. This is advantageous since It lets you try different communication parameters by simply editing the /etc/printcap file; you do not have to recompile the filter program. It enables the spooling system to use the same filter program for multiple printers which may have different serial communication settings. The following /etc/printcap capabilities control serial communication parameters of the device listed in the br#/ Sets the communications speed of the device to fc#/ Clears the flag bits fs#/ Sets the flag bits xc#/ Clears local mode bits xs#/ Sets local mode bits For more information on the bits for the /usr/include/sys/ioctl_compat.h. When LPD opens the device specified by the bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000c1:xs#0x820: Installing the Text Filter

We are now ready to tell LPD what text filter to use to send jobs to the printer. A . For our simple printer setup, the text filter can be a small shell script that just executes /bin/cat to send the job to the printer. FreeBSD comes with another filter called . First, let uss make the shell script /usr/local/libexec/if-simple be a simple text filter. Put the following text into that file with your favorite text editor: #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. /bin/cat && exit 0 exit 2 Make the file executable: chmod 555 /usr/local/libexec/if-simple And then tell LPD to use it by specifying it with the /etc/printcap. We will add it to the two printers we have so far in the example /etc/printcap: # # /etc/printcap for host rose - added text filter # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\ :if=/usr/local/libexec/if-simple: Trying It Out

You have reached the end of the simple LPD setup. Unfortunately, congratulations are not quite yet in order, since we still have to test the setup and correct any problems. To test the setup, try printing something. To print with the LPD system, you use the command to generate some test text. To test the simple LPD setup:

Type: lptest 20 5 | lpr -P where /etc/printcap. To test the default printer, type !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678 To further test the printer, try downloading larger programs (for language-based printers) or running . Troubleshooting

After performing the simple test with /usr/local/libexec/if-simple prints a form feed after it sends the job to the printer: #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. # Writes a form feed character (\f) after printing job. /bin/cat && printf "\f" && exit 0 exit 2 !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 You have become another victim of the Printer received CR Printer prints CR Printer received LF Printer prints CR + LF Here are some ways to achieve this: Use the printer's configuration switches or control panel to alter its interpretation of these characters. Check your printer's manual to find out how to do this.

Have FreeBSD's serial line driver automatically convert LF to CR+LF. Of course, this works with printers on serial ports /etc/printcap file for the printer. Send an Here is an example text filter for printers that understand the Hewlett-Packard PCL escape codes. This filter makes the printer treat LF characters as a LF and CR; then it sends the job; then it sends a form feed to eject the last page of the job. It should work with nearly all Hewlett Packard printers. #!/bin/sh # # hpif - Simple text input filter for lpd for HP-PCL based printers # Installed in /usr/local/libexec/hpif # # Simply copies stdin to stdout. Ignores all filter arguments. # Tells printer to treat LF as CR+LF. Writes a form feed character # after printing job. printf "\033&k2G" && cat && printf "\f" && exit 0 exit 2 Here is an example /etc/printcap from a host called orchid. It has a single printer attached to its first parallel port, a Hewlett Packard LaserJet 3Si named # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: Printer received CR Printer prints CR Printer received LF Printer prints CR + LF If the printer supports XON/XOFF flow control, have FreeBSD use it by specifying the TANDEM bit in the If the printer supports carrier flow control, specify the MDMBUF bit in the If the printer does not support any flow control, use some combination of the NLDELAY, TBDELAY, CRDELAY, VTDELAY, and BSDELAY bits in the /etc/printcap file. /etc/printcap file. For example, here is the entry for rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log Then, try printing again. Check the log file (in our example, /var/log/rattan.log) to see any error messages that might appear. Based on the messages you see, try to correct the problem. If you do not specify a /dev/console as a default. Using Printers

This section tells you how to use printers you have setup with FreeBSD. Here's an overview of the user-level commands: There is also an administrative command, , used to control printers and their queues. All three of the commands /etc/printcap file. This enables you to submit, remove, and check on jobs for various printers. If you do not use the Printing Jobs

To print files, type lpr This prints each of the listed files to the default printer. If you list no files, lpr /etc/host.conf /etc/hosts.equiv To select a specific printer, type lpr -P This example prints a long listing of the current directory to the printer named ls -l | lpr -P rattan Because no files were listed for the . Checking Jobs

When you print with lpq -P bamboo shows the queue for the printer named bamboo is ready and printing Rank Owner Job Files Total Size active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes 2nd kelly 10 (standard input) 1635 bytes 3rd mary 11 ... 78519 bytes This shows three jobs in the queue for for details. Job number nine consists of two files; multiple files given on the waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes Removing Jobs

If you change your mind about printing a job, you can remove the job from the queue with the To remove the job from a specific printer, add the lprm -P bamboo 10 The Just use the lprm -P rattan - rose% lpr -P rattan myfile rose% rlogin orchid orchid% lpq -P rattan Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes orchid% lprm -P rattan 13 rose: Permission denied orchid% logout rose% lprm -P rattan 13 dfA013rose dequeued cfA013rose dequeued rose% Beyond Plain Text: Printing Options

The Formatting and Conversion Options

The following lpr -P bamboo -d fish-report.dvi These options apply to every file in the job, so you cannot mix (say) DVI and ditroff files together in a job. Instead, submit the files as separate jobs, using a different conversion option for each job. gives details. Here is an example: this command prints a nicely formatted version of the zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -t The Job Handling Options

The following options to .

This example prints three copies of lpr -#3 parser.c parser.h Header Page Options

These options to for information about setting up header pages. for details. Administrating Printers

As an administrator for your printers, you have had to install, set up, and test them. Using the Start and stop the printers Enable and disable their queues Rearrange the order of the jobs in each queue. First, a note about terminology: if a printer is /etc/printcap. Advanced Printer Setup

This section describes filters for printing specially formatted files, header pages, printing across networks, and restricting and accounting for printer usage. Filters

Although LPD handles network protocols, queuing, access control, and other aspects of printing, most of the ). However, in order to take advantage of format conversion, printer accounting, specific printer quirks, and so on, you should understand how filters work. It will ultimately be the filter's responsibility to handle these aspects. And the bad news is that most of the time /usr/libexec/lpr/lpf, that works with many printers that can print plain text. (It handles backspacing and tabs in the file, and does accounting, but that is about all it does.) There are also several filters and filter components in the FreeBSD ports collection. Here is what you will find in this section: Section , tries to give an overview of a filter's role in the printing process. You should read this section to get an understanding of what is happening ``under the hood'' when LPD uses filters. This knowledge could help you anticipate and debug problems you might encounter as you install more and more filters on each of your printers. LPD expects every printer to be able to print plain text by default. This presents a problem for PostScript (or other language-based printers) which cannot directly print plain text. Section tells you what you should do to overcome this problem. I recommend reading this section if you have a PostScript printer. PostScript is a popular output format for many programs. Even some people (myself included) write PostScript code directly. But PostScript printers are expensive. Section tells how you can further modify a printer's text filter to accept and print PostScript data on a Section tells about a way you can automate the conversion of specific file formats, such as graphic or typesetting data, into formats your printer can understand. After reading this section, you should be able to set up your printers such that users can type Section tells all about a not often used feature of LPD: output filters. Unless you are printing header pages (see ), you can probably skip that section altogether. Section describes How Filters Work

As mentioned before, a filter is an executable program started by LPD to handle the device-dependent part of communicating with the printer. When LPD wants to print a file in a job, it starts a filter program. It sets the filter's standard input to the file to print, its standard output to the printer, and its standard error to the error logging file (specified in the /etc/printcap, or /dev/console by default). Which filter LPD starts and the filter's arguments depend on what is listed in the /etc/printcap file and what arguments the user specified for the job on the for details). There are three kinds filters you can specify in /etc/printcap: The [-c] -w where /etc/printcap, default 132 A tells all about them. Conversion filters also need to do accounting, if you need printer accounting. Conversion filters are started with the following arguments: -x where The describe them. There are only two arguments to an output filter: -w which are identical to the text filters Filters should also The text filter that comes with the FreeBSD release, /usr/libexec/lpr/lpf, takes advantage of the page width and length arguments to determine when to send a form feed and how to account for printer usage. It uses the login, host, and accounting file arguments to make the accounting entries. If you are shopping for filters, see if they are LPD-compatible. If they are, they must support the argument lists described above. If you plan on writing filters for general use, then have them support the same argument lists and exit codes. Accommodating Plain Text Jobs on PostScript Printers

If you are the only user of your computer and PostScript (or other language-based) printer, and you promise to never send plain text to your printer and to never use features of various programs that will want to send plain text to your printer, then you do not need to worry about this section at all. But, if you would like to send both PostScript and plain text jobs to the printer, then you are urged to augment your printer setup. To do so, we have the text filter detect if the arriving job is plain text or PostScript. All PostScript jobs must start with ); if not, it should be shortly. You can fetch, build and install it yourself, of course. After installing /etc/printcap: :if=/usr/local/libexec/psif: You should also specify the #!/bin/sh # # psif - Print PostScript or plain text on a PostScript printer # Script version; NOT the version that comes with lprps # Installed in /usr/local/libexec/psif # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # PostScript job, print it. # echo $first_line && cat && printf "\004" && exit 0 exit 2 else # # Plain text, convert it, then print it. # ( echo $first_line; cat ) | /usr/local/bin/textps && printf "\004" && exit 0 exit 2 fi In the above script, ) includes a full featured text-to-PostScript program called Simulating PostScript on Non-PostScript Printers

PostScript is the #!/bin/sh # # ifhp - Print Ghostscript-simulated PostScript on a DesJet 500 # Installed in /usr/local/libexec/hpif # # Treat LF as CR+LF: # printf "\033&k2G" || exit 2 # # Read first two characters of the file # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # It is PostScript; use Ghostscript to scan-convert and print it # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \ && exit 0 else # # Plain text or HP/PCL, so just print it directly; print a form # at the end to eject the last page. # echo $first_line && cat && printf "\f" && exit 2 fi exit 2 Finally, you need to notify LPD of the filter via the :if=/usr/local/libexec/hpif: That is it. You can type Conversion Filters

After completing the simple setup described in , the first thing you will probably want to do is install conversion filters for your favorite file formats (besides plain ASCII text). Why Install Conversion Filters?

Conversion filters make printing various kinds of files easy. As an example, suppose we do a lot of work with the TeX typesetting system, and we have a PostScript printer. Every time we generate a DVI file from TeX, we cannot print it directly until we convert the DVI file into PostScript. The command sequence goes like this: dvips seaweed-analysis.dvi lpr seaweed-analysis.ps By installing a conversion filter for DVI files, we can skip the hand conversion step each time by having LPD do it for us. Now, each time we get a DVI file, we are just one step away from printing it: lpr -d seaweed-analysis.dvi We got LPD to do the DVI file conversion for us by specifying the lists the conversion options. For each of the conversion options you want a printer to support, install a /etc/printcap. A conversion filter is like the text filter for the simple printer setup (see section ) except that instead of printing plain text, the filter converts the file into a format the printer can understand. Which Conversions Filters Should I Install?

You should install the conversion filters you expect to use. If you print a lot of DVI data, then a DVI conversion filter is in order. If you have got plenty of troff to print out, then you probably want a troff filter. The following table summarizes the filters that LPD works with, their capability entries for the /etc/printcap file, and how to invoke them with the /etc/printcap File type Capability lpr option ------------ ------------- ---------- cifplot cf -c DVI df -d plot gf -g ditroff nf -n FORTRAN text rf -f troff tf -t raster vf -v plain text if none, -p, or -l In our example, using /etc/printcap. Despite what others might contend, formats like FORTRAN text and plot are probably obsolete. At your site, you can give new meanings to these or any of the formatting options just by installing custom filters. For example, suppose you would like to directly print Printerleaf files (files from the Interleaf desktop publishing program), but will never print plot files. You could install a Printerleaf conversion filter under the Installing Conversion Filters

Since conversion filters are programs you install outside of the base FreeBSD installation, they should probably go under /usr/local. The directory /usr/local/libexec is a popular location, since they they are specialized programs that only LPD will run; regular users should not ever need to run them. To enable a conversion filter, specify its pathname under the appropriate capability for the destination printer in /etc/printcap. In our example, we will add the DVI conversion filter to the entry for the printer named /etc/printcap file again, with the new # # /etc/printcap for host rose - added df filter for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: The DVI filter is a shell script named /usr/local/libexec/psdf. Here is that script: #!bin/sh # # DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" This script runs ) with the arguments LPD passed to this script. More Conversion Filter Examples

Since there is no fixed set of steps to install conversion filters, let me instead provide more examples. Use these as guidance to making your own filters. Use them directly, if appropriate. This example script is a raster (well, GIF file, actually) conversion filter for a Hewlett Packard LaserJet III-Si printer: #!/bin/sh # # hpvf - Convert GIF files into HP/PCL, then print # Installed in /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 It works by converting the GIF file into a portable anymap, converting that into a portable graymap, converting that into a portable bitmap, and converting that into LaserJet/PCL-compatible data. Here is the /etc/printcap file with an entry for a printer using the above filter: # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: The following script is a conversion filter for troff data from the groff typesetting system for the PostScript printer named #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" The above script makes use of #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops That is it. Here is the entry we need to add to /etc/printcap to enable the filter: :tf=/usr/local/libexec/pstf: Here is an example that might make old hands at FORTRAN blush. It is a FORTRAN-text filter for any printer that can directly print plain text. We will install it for the printer #!/bin/sh # # hprf - FORTRAN text filter for LaserJet 3si: # Installed in /usr/local/libexec/hprf # printf "\033&k2G" && fpr && printf "\f" && exit 0 exit 2 And we will add this line to the /etc/printcap for the printer :rf=/usr/local/libexec/hprf: Here is one final, somewhat complex example. We will add a DVI filter to the LaserJet printer /etc/printcap with the location of the DVI filter: :df=/usr/local/libexec/hpdf: Now, for the hard part: making the filter. For that, we need a DVI-to-LaserJet/PCL conversion program. The FreeBSD ports collection (see ) has one: /dev/fd/0 for standard input is problematic. We can get around that problem by linking (symbolically) a temporary file name (one that ends in /dev/fd/0, thereby forcing /tmp directory has the sticky bit set. The filter can create the link, but it will not be able clean up when done and remove it since the link will belong to a different user. Instead, the filter will make the symbolic link in the current working directory, which is the spooling directory (specified by the /etc/printcap). This is a perfect place for filters to do their work, especially since there is (sometimes) more free disk space in the spooling directory than under /tmp. Here, finally, is the filter: #!/bin/sh # # hpdf - Print DVI data on HP/PCL printer # Installed in /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Define a function to clean up our temporary files. These exist # in the current directory, which will be the spooling directory # for the printer. # cleanup() { rm -f hpdf$$.dvi } # # Define a function to handle fatal errors: print the given message # and exit 2. Exiting with 2 tells LPD to do not try to reprint the # job. # fatal() { echo "$@" 1>&2 cleanup exit 2 } # # If user removes the job, LPD will send SIGINT, so trap SIGINT # (and a few other signals) to clean up after ourselves. # trap cleanup 1 2 15 # # Make sure we are not colliding with any existing files. # cleanup # # Link the DVI input file to standard input (the file to print). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # Make LF = CR+LF # printf "\033&k2G" || fatal "Cannot initialize printer" # # Convert and print. Return value from dvilj2p does not seem to be # reliable, so we ignore it. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Clean up and exit # cleanup exit 0 Automated Conversion: An Alternative To Conversion Filters

All these conversion filters accomplish a lot for your printing environment, but at the cost forcing the user to specify (on the Output Filters

The LPD spooling system supports one other type of filter that we have not yet explored: an output filter. An output filter is intended for printing plain text only, like the text filter, but with many simplifications. If you are using an output filter but no text filter, then LPD starts an output filter once for the entire job instead of once for each file in the job. LPD does not make any provision to identify the start or the end of files within the job for the output filter. LPD does not pass the user's login or host to the filter, so it is not intended to do accounting. In fact, it gets only two arguments: -w where Do not be seduced by an output filter's simplicity. If you would like each file in a job to start on a different page an output filter . Furthermore, an output filter is actually ) only. LPD then expects the output filter to

The program /usr/libexec/lpr/lpf that comes with FreeBSD binary distribution is a text filter (input filter) that can indent output (job submitted with /etc/printcap file. It uses these values to determine how much text can fit on a page and how many pages were in a user's job. For more information on printer accounting, see . Header Pages

If you have . Enabling Header Pages

In the , we turned off header pages by specifying /etc/printcap file. To enable header pages for a printer, just remove the #!/bin/sh # # hpof - Output filter for Hewlett Packard PCL-compatible printers # Installed in /usr/local/libexec/hpof printf "\033&k2G" || exit 2 exec /usr/libexec/lpr/lpf Specify the path to the output filter in the for more information. Here is an example /etc/printcap file for the printer # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: Now, when users print jobs to for more /etc/printcap. Controlling Header Pages

By enabling header pages, LPD will produce a k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 LPD appends a form feed after this text so the job starts on a new page (unless you have /etc/printcap). If you prefer, LPD can make a /etc/printcap file. The header page will look like this: rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 Also by default, LPD prints the header page first, then the job. To reverse that, specify /etc/printcap. Accounting for Header Pages

Using LPD's built-in header pages enforces a particular paradigm when it comes to printer accounting: header pages must be Accept LPD's paradigm and make header pages free. Install an alternative to LPD, such as LPDng or PLP. Section tells more about other spooling software you can substitute for LPD. Write a /etc/printcap. Then again, all that might be too much trouble, and users will certainly appreciate the more generous system administrator who makes header pages free. Header Pages on PostScript Printers

As described above, LPD can generate a plain text header page suitable for many printers. Of course, PostScript cannot directly print plain text, so the header page feature of LPD is useless---or mostly so. One obvious way to get header pages is to have every conversion filter and the text filter generate the header page. The filters should should use the user and host arguments to generate a suitable header page. The drawback of this method is that users will always get a header page, even if they submit jobs with #!/bin/sh # # make-ps-header - make a PostScript header page on stdout # Installed in /usr/local/libexec/make-ps-header # # # These are PostScript units (72 to the inch). Modify for A4 or # whatever size paper you are using: # page_width=612 page_height=792 border=72 # # Check arguments # if [ $# -ne 3 ]; then echo "Usage: `basename $0` " 1>&2 exit 1 fi # # Save these, mostly for readability in the PostScript, below. # user=$1 host=$2 job=$3 date=`date` # # Send the PostScript code to stdout. # exec cat < Now, each of the conversion filters and the text filter can call this script to first generate the header page, and then print the user's job. Here is the DVI conversion filter from earlier in this document, modified to make a header page: #!/bin/sh # # DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # orig_args="$@" fail() { echo "$@" 1>&2 exit 2 } while getopts "x:y:n:h:" option; do case $option in x|y) ;; # Ignore n) login=$OPTARG ;; h) host=$OPTARG ;; *) echo "LPD started `basename $0` wrong." 1>&2 exit 2 ;; esac done [ "$login" ] || fail "No login name" [ "$host" ] || fail "No host name" ( /u/kelly/freebsd/printing/filters/make-ps-header $login $host "DVI File" /usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_args Notice how the filter has to parse the argument list in order to determine the user and host name. The parsing for the other conversion filters is identical. The text filter takes a slightly different set of arguments, though (see section ). As we have mentioned before, the above scheme, though fairly simple, disables the ``suppress header page'' option (the : write an output filter that parses the LPD-generated header page and produces a PostScript version. If the user submits the job with Networked Printing

FreeBSD supports networked printing: sending jobs to remote printers. Networked printing generally refers to two different things: Accessing a printer attached to a remote host. You install a printer that has a conventional serial or parallel interface on one host. Then, you set up LPD to enable access to the printer from other hosts on the network. Section tells how to do this. Accessing a printer attached directly to a network. The printer has a network interface in addition (or in place of) a more conventional serial or parallel interface. Such a printer might work as follows: It might understand the LPD protocol and can even queue jobs from remote hosts. In this case, it acts just like a regular host running LPD. Follow the same procedure in section to set up such a printer. It might support a data stream network connection. In this case, you ``attach'' the printer to one host on the network by making that host responsible for spooling jobs and sending them to the printer. Section gives some suggestions on installing such printers. Printers Installed on Remote Hosts

The LPD spooling system has built-in support for sending jobs to other hosts also running LPD (or are compatible with LPD). This feature enables you to install a printer on one host and make it accessible from other hosts. It also works with printers that have network interfaces that understand the LPD protocol. To enable this kind of remote printing, first install a printer on one host, the . Do any advanced setup in that you need. Make sure to test the printer and see if it works with the features of LPD you have enabled. If you are using a printer with a network interface that is compatible with LPD, then the /etc/printcap files with the following: Name the entry anything you want. For simplicity, though, you probably want to use the same name and aliases as on the printer host. Leave the Make a spooling directory and specify its location in the Place the name of the printer host in the Place the printer name on the That is it. You do not need to list conversion filters, page dimensions, or anything else in the /etc/printcap file. Here is an example. The host rose has two printers, /etc/printcap file for orchid (back from section ). It already had the entry for the printer # # /etc/printcap for host orchid - added (remote) printers on rose # # # teak is local; it is connected directly to orchid: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # rattan is connected to rose; send jobs for rattan to rose: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # bamboo is connected to rose as well: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: Then, we just need to make spooling directories on orchid: mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo chown daemon.daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo Now, users on orchid can print to lpr -P bamboo -d sushi-review.dvi the LPD system on orchid would copy the job to the spooling directory /var/spool/lpd/bamboo and note that it was a DVI job. As soon as the host rose has room in its Printers with Networked Data Stream Interfaces

Often, when you buy a network interface card for a printer, you can get two versions: one which emulates a spooler (the more expensive version), or one which just lets you send data to it as if you were using a serial or parallel port (the cheaper version). This section tells how to use the cheaper version. For the more expensive one, see the previous section . The format of the /etc/printcap file lets you specify what serial or parallel interface to use, and (if you are using a serial interface), what baud rate, whether to use flow control, delays for tabs, conversion of newlines, and more. But there is no way to specify a connection to a printer that is listening on a TCP/IP or other network port. To send data to a networked printer, you need to develop a communications program that can be called by the text and conversion filters. Here is one such example: the script #!/usr/bin/perl # # netprint - Text filter for printer attached to network # Installed in /usr/local/libexec/netprint # $#ARGV eq 1 || die "Usage: $0 "; $printer_host = $ARGV[0]; $printer_port = $ARGV[1]; require 'sys/socket.ph'; ($ignore, $ignore, $protocol) = getprotobyname('tcp'); ($ignore, $ignore, $ignore, $ignore, $address) = gethostbyname($printer_host); $sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address); socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol) || die "Can't create TCP/IP stream socket: $!"; connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!"; while () { print PRINTER; } exit 0; We can then use this script in various filters. Suppose we had a Diablo 750-N line printer connected to the network. The printer accepts data to print on port number 5100. The host name of the printer is scrivener. Here is the text filter for the printer: #!/bin/sh # # diablo-if-net - Text filter for Diablo printer `scrivener' listening # on port 5100. Installed in /usr/local/libexec/diablo-if-net # exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100 Restricting Printer Usage

This section gives information on restricting printer usage. The LPD system lets you control who can access a printer, both locally or remotely, whether they can print multiple copies, how large their jobs can be, and how large the printer queues can get. Restricting Multiple Copies

The LPD system makes it easy for users to print multiple copies of a file. Users can print jobs with /etc/printcap file. When users submit jobs with the lpr: multiple copies are not allowed Note that if you have set up access to a printer remotely (see section ), you need the /etc/printcap files as well, or else users will still be able to submit multiple-copy jobs by using another host. Here is an example. This is the /etc/printcap file for the host rose. The printer # # /etc/printcap for host rose - restrict multiple copies on bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Now, we also need to add the /etc/printcap (and while we are at it, let us disable multiple copies for the printer # # /etc/printcap for host orchid - no multiple copies for local # printer teak or remote printer bamboo teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: By using the lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign There are many ways to prevent this abuse (including ignoring it) which you are free to explore. Restricting Access To Printers

You can control who can print to what printers by using the UNIX group mechanism and the /etc/printcap. Just place the users you want to have access to a printer in a certain group, and then name that group in the lpr: Not a member of the restricted group if they try to print to the controlled printer. As with the ). For example, we will let anyone access the printer /etc/printcap for host rose: # # /etc/printcap for host rose - restricted group for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Let us leave the other example /etc/printcap file (for the host orchid) alone. Of course, anyone on orchid can print to Controlling Sizes of Jobs Submitted

If you have many users accessing the printers, you probably need to put an upper limit on the sizes of the files users can submit to print. After all, there is only so much free space on the filesystem that houses the spooling directories, and you also need to make sure there is room for the jobs of other users. LPD enables you to limit the maximum byte size a file in a job can be with the # # /etc/printcap for host rose # # # No limit on job size: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Limit of five megabytes: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Again, the limits apply to the local users only. If you have set up access to your printers remotely, remote users will not get those limits. You will need to specify the /etc/printcap files as well. See section for more information on remote printing. There is another specialized way to limit job sizes from remote printers; see section . Restricting Jobs from Remote Printers

The LPD spooling system provides several ways to restrict print jobs submitted from remote hosts: /etc/hosts.equiv and /etc/hosts.lpd. LPD checks to see if an incoming request is from a host listed in either one of these files. If not, LPD refuses the request. The format of these files is simple: one host name per line. Note that the file /etc/hosts.equiv is also used by the ruserok(3) protocol, and affects programs like /etc/hosts.lpd file on the host rose: orchid violet madrigal.fishbaum.de This means rose will accept requests from the hosts orchid, violet, and madrigal.fishbaum.de. If any other host tries to access rose's LPD, LPD will refuse them. /etc/printcap to find the spooling directory for this printer; here is bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: The spooling directory is the given in the echo 6144 > /var/spool/lpd/bamboo/minfree /etc/printcap. When /usr/bin/false. Accounting for Printer Usage

So, you need to charge for printouts. And why not? Paper and ink cost money. And then there are maintenance costs---printers are loaded with moving parts and tend to break down. You have examined your printers, usage patterns, and maintenance fees and have come up with a per-page (or per-foot, per-meter, or per-whatever) cost. Now, how do you actually start accounting for printouts? Well, the bad news is the LPD spooling system does not provide much help in this department. Accounting is highly dependent on the kind of printer in use, the formats being printed, and . Generally, there are two ways to do accounting: The LPD spooling system supports both methods easily: since you have to provide the filters (well, most of the time), you also have to provide the accounting code. But there is a bright side: you have enormous flexibility in your accounting methods. For example, you choose whether to use periodic or timely accounting. You choose what information to log: user names, host names, job types, pages printed, square footage of paper used, how long the job took to print, and so forth. And you do so by modifying the filters to save this information. Quick and Dirty Printer Accounting

FreeBSD comes with two programs that can get you set up with simple periodic accounting right away. They are the text filter , and ), LPD starts the text and the conversion filters with the name of the accounting file to use on the filter command line. The filters can use this argument to know where to write an accounting file entry. The name of this file comes from the /etc/printcap, and if not specified as an absolute path, is relative to the spooling directory. LPD starts 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang You should use a separate accounting file for each printer, as /etc/printcap. Then, each accounting file will be in the spooling directory for a printer, in a file named Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 These are the arguments /etc/printcap. /etc/printcap, or two cents (the default). You can specify In the default summary that Login pages/feet runs price andy 2.00 1 $ 0.04 kelly 182.00 105 $ 3.64 mary 118.00 35 $ 2.36 root 26.00 12 $ 0.52 zhang 9.00 1 $ 0.18 total 337.00 154 $ 6.74 To compute the dollar amount due, /etc/printcap file (default of 200, or 2 cents per page). Specify, in hundreths of cents, the price per page or per foot you want to charge for printouts in this capability. You can override this value when you run pac -p1.50 makes each page cost one dollar and fifty cents. You can really rake in the profits by using this option. Finally, running How Can You Count Pages Printed?

In order to perform even remotely accurate accounting, you need to be able to determine how much paper a job uses. This is the essential problem of printer accounting. For plain text jobs, the problem's not that hard to solve: you count how many lines are in a job and compare it to how many lines per page your printer supports. Do not forget to take into account backspaces in the file which overprint lines, or long logical lines that wrap onto one or more additional physical lines. The text filter ) takes into account these things when it does accounting. If you are writing a text filter which needs to do accounting, you might want to examine Alternatives to the Standard Spooler

If you have been reading straight through this manual, by now you have learned just about everything there is to know about the LPD spooling system that comes with FreeBSD. You can probably appreciate many of its shortcomings, which naturally leads to the question: ``What other spooling systems are out there (and work with FreeBSD)?'' Unfortunately, I have located only . There is also a . It is quite similar to the BSD LPD spooler, but boasts a host of features, including: Better network support, including built-in support for networked printers, NIS-maintained printcaps, and NFS-mounted spooling directories Sophisticated queue management, allowing multiple printers on a queue, transfer of jobs between queues, and queue redirection Remote printer control functions Prioritization of jobs Expansive security and access options . Acknowledgments

I would like to thank the following people who have assisted in the development of this document: diff --git a/handbook/relnotes.sgml b/handbook/relnotes.sgml index 57d451dc9a..d2f102c326 100644 --- a/handbook/relnotes.sgml +++ b/handbook/relnotes.sgml @@ -1,594 +1,585 @@ - + About the current release

FreeBSD is a freely available, full source 4.4BSD-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 release of FreeBSD 2.0 one year ago, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped VM system with a merged VM/file buffer cache that not only increases performance, but reduces FreeBSD's memory footprint, making a 5MB configuration a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial-on-demand PPP, an improved SCSI subsystem, early ISDN support, support for FDDI and Fast Ethernet (100Mbit) adapters, improved support for the Adaptec 2940 (WIDE and narrow) and many hundreds of bug fixes. We have also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this (constantly evolving) process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with some 350 commonly sought-after programs. The list of ports ranges from http (WWW) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 10MB of storage, all ports being expressed as ``deltas'' to their original sources. This makes it much easier for us to update ports, and greatly reduces the disk space demands made by the older 1.0 ports collection. To compile a port, you simply change to the directory of the program you wish to install, type make and let the system do the rest. The full original distribution for each port you build is retrieved dynamically off of CDROM or a local ftp site, so you need only enough disk space to build the ports you want. (Almost) every port is also provided as a pre-compiled "package" which can be installed with a simple command (pkg_add) by those who do not wish to compile their own ports from source. A number of additional documents which you may find very helpful in the process of installing and using FreeBSD may now also be found in the /usr/share/doc directory on any machine running FreeBSD 2.1 or later. You may view the manuals with any HTML capable browser with the following URLs: The FreeBSD handbook The FreeBSD FAQ You can also visit the master (and most frequently updated) copies at . The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. There is an add-on package to the core distribution, for use only in the United States, that contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely (from outside the U.S.) exportable European distribution of DES for our non-U.S. users also exists and is described in the . If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from different hosts (Suns, DEC machines, etc) into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require! We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. If you are outside (or even inside) the U.S., give it a try! Since our first release of FreeBSD 1.0 nearly two years ago, FreeBSD has changed dramatically. Since release 2.0, FreeBSD has been based on the Berkeley 4.4BSD-Lite code rather than the Net2 code used for previous versions. In addition to clearing the legal issues that surrounded the Net2 code, the port to 4.4 has also brought in numerous new features, filesystems and enhanced driver support. Since our release of FreeBSD 2.0 in November of 1994, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped Virtual Memory (VM) system with a merged virtual memory and file buffer cache. This increases performance while reducing FreeBSD's memory footprint, making a system with 4 megabytes of RAM a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial on demand PPP, an improved SCSI subsystem, early support for ISDN, support for FDDI and 100Mbit Fast Ethernet adapters, improved support for the Adaptec 2940 and hundreds of bug fixes. We have also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this constantly evolving process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with some 270 commonly sought-after programs. The list of ports ranges from World Wide Web (http) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 10MB of storage because each port contains only the changes required for the source code to compile on FreeBSD and the information necessary to automatically retrieve the original sources. The original distribution for each port you build is automatically retrieved off of CD-ROM or a via anonymous ftp, so you need only enough disk space to build the ports you want. Each port is also provided as a pre-compiled package which can be installed with the pkg_add(1) command for those who do not wish to compile their own ports from source. See for a more complete description. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. An add-on package, for use only in the United States, contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely exportable European distribution of DES for our non-U.S. users also exists and is described in the . If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from other hosts using DES 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. FreeBSD 2.0.5 represents the culmination of 2 years of work and many thousands of man hours put in by an international development team. We hope you enjoy it! New feature highlights

The following features were added or substantially improved between the release of 2.0 and this 2.0.5 release. In order to facilitate better communication, the person, or persons, responsible for each enhancement is noted. Any questions regarding the new functionality should be directed to them first. Kernel

Merged VM-File Buffer Cache A merged VM/buffer cache design greatly enhances overall system performance and makes it possible to do a number of more optimal memory allocation strategies that were not possible before. - Owner: David Greenman (davidg@FreeBSD.org) and - John Dyson (dyson@implode.root.com) + Owner: &a.davidg; and &a.dyson; Network PCB hash optimization For systems with a great number of active TCP connections (WEB and ftp servers, for example), this greatly speeds up the lookup time required to match an incoming packet up to its associated connection. - Owner: David Greenman (davidg@FreeBSD.org) + Owner: &a.davidg; Name cache optimization The name-cache would cache all files of the same name to the same bucket, which would put for instance all ".." entries in the same bucket. We added the parent directory version to frustrate the hash, and improved the management of the cache in various other ways while we were at it. - Owner: Poul-Henning Kamp (phk@FreeBSD.org) - David Greenman (davidg@FreeBSD.org) + Owner: &a.phk; and &a.davidg; Less restrictive swap-spaces The need to compile the names of the swap devices into the kernel has been removed. Now swapon(8) will accept any block devices, up to the maximum number of swap devices configured in the kernel. - Owner: Poul-Henning Kamp (phk@FreeBSD.org) - David Greenman (davidg@FreeBSD.org) + Owner: &a.phk; and &a.davidg; Hard Wired SCSI Devices Prior to 2.0.5, FreeBSD performed dynamic assignment of unit numbers to SCSI devices as they were probed, allowing a SCSI device failure to possibly change unit number assignment. This could cause filesystems other disks in the system to be incorrectly mounted, or not mounted at all. Hard wiring allows static allocation of unit numbers (and hence device names) to scsi devices based on SCSI ID and bus. SCSI configuration occurs in the kernel config file. Samples of the configuration syntax can be found in the scsi(4) man page or the LINT kernel config file. - Owner: Peter Dufault (dufault@hda.com) + Owner: &a.dufault; Sources involved: sys/scsi/* usr.sbin/config/* Slice Support FreeBSD now supports a slice abstraction which enhances FreeBSD's ability to share disks with other operating systems. This support will allow FreeBSD to inhabit DOS extended partitions. - Owner: Bruce Evans (bde@FreeBSD.org) + Owner: &a.bde; Sources involved: sys/disklabel.h sys/diskslice.h sys/dkbad.h kern/subr_diskslice.c kern/subr_dkbad.c i386/isa/diskslice_machdep.c i386/isa/wd.c scsi/sd.c dev/vn/vn.c Support for Ontrack Disk Manager Version 6.0 Support has been added for disks which use Ontrack Disk Manager. The fdisk program does not know about it however, so make all changes using the install program on the boot.flp or the Ontrack Disk Manager tool under MS-DOS. - Owner: Poul-Henning Kamp (phk@FreeBSD.org) + Owner: &a.phk; Bad144 is back and working Bad144 works again, though the semantics are slightly different than before in that the bad-spots are kept relative to the slice rather than absolute on the disk. - Owner: Bruce Evans (bde@FreeBSD.org) - Poul-Henning Kamp (phk@FreeBSD.org) + Owner: &a.bde; and &a.phk; New device support SCSI and CDROM devices

Matsushita/Panasonic (Creative) CD-ROM driver The Matsushita/Panasonic CR-562 and CR-563 drives are now supported when connected to a Sound Blaster or 100% compatible host adapter. Up to four host adapters are supported for a total of 16 CD-ROM drives. The audio functions are supported with the Karoke variable speed playback. - Owner: Frank Durda IV - (bsdmail@nemesis.lonestar.org) + Owner: &a.uhclem; Sources involved: isa/matcd Adaptec 2742/2842/2940 SCSI driver The original 274x/284x driver has evolved considerably since the 2.0 release of FreeBSD. We now offer full support for the 2940 series as well as the Wide models of these cards. The arbitration bug that caused problems with fast devices has been corrected and experimental tagged queuing support has been added (kernel option AHC_TAGENABLE). John Aycock has also released the sequencer code under a Berkeley style copyright making the driver entirely clean of the GPL. - Owner: Justin Gibbs (gibbs@FreeBSD.org) + Owner: &a.gibbs; Sources involved: isa/aic7770.c pci/aic7870.c i386/scsi/* sys/dev/aic7xxx/* NCR5380/NCR53400 SCSI (ProAudio Spectrum) driver - Owner: core + Owner: &a.core; Submitted by: Serge Vakulenko (vak@cronyx.ru) Sources involved: isa/ncr5380.c - Sony CDROM driver Owner: core + Sony CDROM driver Owner: &a.core; Submitted by: Mikael Hybsch (micke@dynas.se) Sources involved: isa/scd.c Serial devices

SDL Communications Riscom/8 Serial Board Driver - Owner: Andrey Chernov - (ache@FreeBSD.org) + Owner: &a.ache; Sources involved: isa/rc.c isa/rcreg.h Cyclades Cyclom-y Serial Board Driver - Owner: Bruce Evans (bde@FreeBSD.org) + Owner: &a.bde; Submitted by: Andrew Werple (andrew@werple.apana.org.au) and Heikki Suonsivu (hsu@cs.hut.fi) Obtained from: NetBSD Sources involved: isa/cy.c Cronyx/Sigma sync/async serial driver - Owner: core + Owner: &a.core; Submitted by: Serge Vakulenko Sources involved: isa/cronyx.c Networking

Diskless booting Diskless booting in 2.0.5 is much improved over previous releases. The boot program is in src/sys/i386/boot/netboot, and can be run from an MS-DOS system or burned into an EPROM. WD, SMC, 3COM and Novell ethernet cards are currently supported. Local swapping is also supported. DEC DC21140 Fast Ethernet driver This driver supports any of the numerous NICs using the DC21140 chipset including the 100Mb DEC DE-500-XA and SMC 9332. - Owner: core + Owner: &a.core; Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_de.c pci/dc21040.h - DEC FDDI (DEFPA/DEFEA) driver Owner: core + DEC FDDI (DEFPA/DEFEA) driver Owner: &a.core; Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_pdq.c pci/pdq.c pci/pdq_os.h pci/pdqreg.h 3Com 3c505 (Etherlink/+) NIC driver Owner: - core + &a.core; Submitted by: Dean Huxley (dean@fsa.ca) Obtained from: NetBSD Sources involved: isa/if_eg.c Fujitsu MB86960A family of NICs driver - Owner: core + Owner: &a.core; Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp) Sources involved: isa/if_fe.c Intel EtherExpress driver Owner: Rodney W. Grimes (rgrimes@FreeBSD.org) Sources involved: isa/if_ix.c isa/if_ixreg.h - 3Com 3c589 driver Owner: core + 3Com 3c589 driver Owner: &a.core; Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Seiji Murata (seiji@mt.cs.keio.ac.jp) and Noriyuki Takahashi (hor@aecl.ntt.jp) Sources involved: isa/if_zp.c - IBM Credit Card Adapter driver Owner: core + IBM Credit Card Adapter driver Owner: &a.core; Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Sources involved: isa/pcic.c isa/pcic.h EDSS1 and 1TR6 ISDN interface driver - Owner: core + Owner: &a.core; Submitted by: Dietmar Friede (dfriede@drnhh.neuhaus.de) and Juergen Krause (jkr@saarlink.de) Sources involved: gnu/isdn/* Miscellaneous drivers

- Joystick driver Owner: Jean-Marc Zucconi - (jmz@FreeBSD.org) + Joystick driver Owner: &a.jmz; Sources involved: isa/joy.c National Instruments ``LabPC'' driver Owner: - Peter Dufault (dufault@hda.com) + &a.dufault; Sources involved: isa/labpc.c WD7000 driver Owner: Olof Johansson (offe@ludd.luth.se) - Pcvt Console driver Owner: Jörg Wunsch - (joerg@FreeBSD.org) + Pcvt Console driver Owner: &a.joerg; - Submitted by: Hellmuth Michaelis - (hm@altona.hamburg.com) + Submitted by: &a.hm; Sources involved: isa/pcvt/* BSD-audio emulator for VAT driver Owner: Amancio Hasty (ahasty@FreeBSD.org) and - Paul Traina (pst@FreeBSD.org) + &a.pst; Sources involved: isa/sound/vat_audio.c isa/sound/vat_audioio.h National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver - Owner: core + Owner: &a.core; Submitted by: Fred Cawthorne (fcawth@delphi.umd.edu) Sources involved: isa/gpib.c isa/gpib.h isa/gpibreg.h Genius GS-4500 hand scanner driver Owner: - core + &a.core; Submitted by: Gunther Schadow (gusw@fub46.zedat.fu-berlin.de) Sources involved: isa/gsc.c isa/gscreg.h - CORTEX-I Frame Grabber Owner: core + CORTEX-I Frame Grabber Owner: &a.core; Submitted by: Paul S. LaFollette, Jr. ( Sources involved: isa/ctx.c isa/ctxreg.h Video Spigot video capture card Owner: Jim Lowe Experimental features

UNIONFS and LFS The unionfs and LFS file systems are known to be severely broken in FreeBSD 2.0.5. This is in part due to old bugs that we have not had time to resolve yet and the need to update these file systems to deal with the new VM system. We hope to address these issues in a later release of FreeBSD. iBCS2 Support FreeBSD now supports running iBCS2 compatible binaries. Currently SCO UNIX 3.2.2 and 3.2.4, and ISC 2.2 COFF are supported. The iBCS2 emulator is in its early stages and has not been extensively tested, but it is functional. Most of SCO's 3.2.2 binaries work, as does an old INFORMIX-2.10 for SCO. Further testing is necessary to complete this project. There is also work under way for ELF and XOUT loaders, and most of the svr4 syscall wrappers are written. - Owner: Søren Schmidt (sos) and Sean Eric Fagan (sef) + Owner: &a.sos; and &a.sef; Sources involved: sys/i386/ibcs2/* and misc kernel changes. ]]> diff --git a/handbook/slips.sgml b/handbook/slips.sgml index df3dc8db4f..60b827c361 100644 --- a/handbook/slips.sgml +++ b/handbook/slips.sgml @@ -1,507 +1,508 @@ Setting up a SLIP server

Contributed by &a.ghelmer;. v1.0, 15 May 1995. This document provides suggestions for setting up SLIP Server services on a FreeBSD system, which typically means configuring your system to automatically startup connections upon login for remote SLIP clients. The author has written this document based on his experience; however, as your system and needs may be different, this document may not answer all of your questions, and the author cannot be responsible if you damage your system or lose data due to attempting to follow the suggestions here. This guide was originally written for SLIP Server services on a FreeBSD 1.x system. It has been modified to reflect changes in the pathnames and the removal of the SLIP interface compression flags in early versions of FreeBSD 2.X, which appear to be the only major changes between FreeBSD versions. If you do encounter mistakes in this document, please email the author with enough information to help correct the problem. Prerequisites

This document is very technical in nature, so background knowledge is required. It is assumed that you are familiar with the TCP/IP network protocol, and in particular, network and node addressing, network address masks, subnetting, routing, and routing protocols, such as RIP. Configuring SLIP services on a dial-up server requires a knowledge of these concepts, and if you are not familiar with them, please read a copy of either Craig Hunt's TCP/IP Network Administration published by O'Reilly & Associates, Inc. (ISBN Number 0-937175-82-X), or Douglas Comer's books on the TCP/IP protocol. It is further assumed that you have already setup your modem(s) and configured the appropriate system files to allow logins through your modems. If you have not prepared your system for this yet, please see the tutorial for configuring dialup services; if you have a World-Wide Web browser available, browse the list of tutorials at http://www.freebsd.org/; otherwise, check the place where you found this document for a document named 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 /etc/sliphome/slip.hosts to find a matching line for the special user, and if it finds a match, connects the serial line to an available SLIP interface and then runs the shell script /etc/sliphome/slip.login to configure the SLIP interface. An Example of a SLIP Server Login

For example, if a SLIP user ID were Shelmerg, /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 sliplogin will search /etc/sliphome/slip.hosts for a line that had a matching user ID; for example, there may be a line in /etc/sliphome/slip.hosts that reads: Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp /etc/sliphome/slip.login like this: /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp If all goes well, /etc/sliphome/slip.login will issue an ifconfig for the SLIP interface to which 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, /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 us dive into setting up the system. 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 0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 0 0 0 0 0 sl1* 296 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 will have to edit the /etc/sysconfig file and change the setting of the gateway variable to YES. If you have an older system which does not have the /etc/sysconfig file, then add the following command: sysctl -w net.inet.ip.forwarding = 1 to your /etc/rc.local file.

You will then need to reboot for the new settings to take effect.

You will notice that near the end of the default kernel configuration file (/sys/i386/conf/GENERIC) is a line that reads: pseudo-device sl 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. Please refer to for help in reconfiguring your kernel. Sliplogin Configuration

As mentioned earlier, there are three files in the /etc/sliphome directory that are part of the configuration for /usr/sbin/sliplogin (see sliplogin(8) for the actual manual page for sliplogin): slip.hosts, which defines the SLIP users & their associated IP addresses; slip.login, which usually just configures the SLIP interface; and (optionally) slip.logout, which undoes slip.login's effects when the serial connection is terminated. slip.hosts Configuration

/etc/sliphome/slip.hosts contains lines which have at least four items, separated by whitespace: SLIP user's login ID Local address (local to the SLIP server) of the SLIP link Remote address of the SLIP link Network mask The local and remote addresses may be host names (resolved to IP addresses by /etc/hosts or by the domain name service, depending on your specifications in /etc/host.conf), and I believe the network mask may be a name that can be resolved by a lookup into /etc/networks. On a sample system, /etc/sliphome/slip.hosts looks like this: ----- begin /etc/sliphome/slip.hosts ----- # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp ----- end /etc/sliphome/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 will be dropped instead of using up your bandwidth) Note that section and/or consult your IP network manager. If you are going to use a separate subnet for your SLIP clients, you will need to allocate the subnet number out of your assigned IP network number and assign each of your SLIP client's IP numbers out of that subnet. Then, you will probably either need to configure a static route to the SLIP subnet via your SLIP server on your nearest IP router, or install gated on your FreeBSD SLIP server and configure it to talk the appropriate routing protocols to your other routers to inform them about your SLIP server's route to the SLIP subnet. Otherwise, if you will use the ``proxy ARP'' method, you will need to assign your SLIP client's IP addresses out of your SLIP server's Ethernet subnet, and you will also need to adjust your /etc/sliphome/slip.login and /etc/sliphome/slip.logout scripts to use arp(8) to manage the proxy-ARP entries in the SLIP server's ARP table. slip.login Configuration

The typical /etc/sliphome/slip.login file looks like this: ----- begin /etc/sliphome/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/sliphome/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/sliphome/slip.login file will need to look something like this: ----- begin /etc/sliphome/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/sliphome/slip.login for "proxy ARP" ----- The additional line in this slip.login, arp -s $5 00:11:22:33:44:55 pub, creates an ARP entry in the SLIP server's ARP table. This ARP entry causes the SLIP server to respond with the SLIP server's Ethernet MAC address whenever a another IP node on the Ethernet asks to speak to the SLIP client's IP address. When using the example above, be sure to replace the Ethernet MAC address (00:11:22:33:44:55) with the MAC address of your system's Ethernet card, or your ``proxy ARP'' will definitely not work! You can discover your SLIP server's Ethernet MAC address by looking at the results of running netstat -i; the second line of the output should look something like: ed0 1500 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/sliphome/slip.login and /etc/sliphome/slip.logout, the ``execute'' bit (ie, chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) must be set, or sliplogin will be unable to execute it. slip.logout Configuration

/etc/sliphome/slip.logout is not strictly needed (unless you are implementing ``proxy ARP''), but if you decide to create it, this is an example of a basic slip.logout script: ----- begin /etc/sliphome/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/sliphome/slip.logout ----- If you are using ``proxy ARP'', you will want to have /etc/sliphome/slip.logout remove the ARP entry for the SLIP client: ----- begin /etc/sliphome/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/sliphome/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/sliphome/slip.logout has the execute bit set for after you create it (ie, chmod 755 /etc/sliphome/slip.logout). 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. Static Routes

Adding static routes to your nearest default routers can be troublesome (or impossible, if you do not have authority to do so...). If you have a multiple-router network in your organization, some routers, such as Cisco and Proteon, may not only need to be configured with the static route to the SLIP subnet, but also need to be told which static routes to tell other routers about, so some expertise and troubleshooting/tweaking may be necessary to get static-route-based routing to work. Running 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. ftp.gated.cornell.edu in the directory /pub/gated; I believe the current version as of this writing is gated-R3_5Alpha_8.tar.Z, which includes support for FreeBSD ``out-of-the-box''. Complete information and documentation on gated is available on the Web starting at http://www.gated.cornell.edu/. Compile and install it, and then write a /etc/gated.conf file to configure your gated; here is a sample, similar to what the author used on a FreeBSD SLIP server: ----- 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 /var/tmp/gated.output for debugging gated's activity; you can certainly turn off the tracing options if gated works OK for you. You will need to change the xxx.xxx.yy's into the network address of your own SLIP subnet (be sure to change the net mask in the proto direct clause as well). When you get gated built and installed and create a configuration file for it, you will need to run gated in place of routed on your FreeBSD system; change the routed/gated startup parameters in /etc/netstart as appropriate for your system. Please see the manual page for gated for information on gated's command-line parameters. Acknowledgments

Thanks to these people for comments and advice regarding this tutorial: - diff --git a/handbook/submitters.sgml b/handbook/submitters.sgml index d64fe945ef..cde2373710 100644 --- a/handbook/submitters.sgml +++ b/handbook/submitters.sgml @@ -1,522 +1,520 @@ - + Contributing to FreeBSD

Contributed by &a.jkh;.

So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth!

Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors who's ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it.

Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our "TODO" list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project!

Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is needed

The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks

The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers

Autodetect memory over 64MB properly. Move userconfig (-c) into 3rd stage boot. Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs Fix the MSDOS file system. Clean up and document the nullfs filesystem code. Coordinator: &a.gibbs Fix the union file system. Coordinator: &a.dyson Fix the LFS file system. Coordinator: &a.dyson Implement kernel and user vm86 support. Coordinator: &a.hackers Implement Int13 vm86 disk driver. Coordinator: &a.hackers SCSI driver issues. Overall coordination: &a.hackers

Support tagged queuing generically. Requires a rewrite of how we do our command queing, but we need this anyway to for prioritized I/O (CD-R writers/scanners). Better error handling (Busy status and retries). Merged Scatter-Gather list creation code. Kernel issues. Overall coordination: &a.hackers

Complete the eisaconf conversion of all existing drivers. Change all interrupt routines to take a (void *) instead of using unit numbers. Merge EISA/PCI/ISA interrupt registration code. Split PCI/EISA/ISA probes out from drivers like bt742a.c (WIP) Fix the syscons ALT-TAB/vt switching hangs. Coordinator: &a.sos Mouse support for syscons. Merged keyboard code for all console drivers. Rewrite the Intel Etherexpress 16 driver. Merge the 3c509 and 3c590 drivers (essentially provide a PCI probe for ep.c). Support Adaptec 3985 (first as a simple 3 channel SCSI card) Coordinator: &a.gibbs Support Advansys SCSI controller products. Coordinator: &a.gibbs Medium priority tasks

The following tasks need to be done, but not with any particular urgency: DOS emulator (for DOS executables) Coordinator: Port AFS (Andrew File System) to FreeBSD Coordinator: MCA support? This should be finalized one way or the other. Full LKM based driver support/Configuration Manager.

Devise a way to do all LKM registration without ld. This means some kind of symbol table in the kernel. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the LKMs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.nate and &a.phk Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.nate and &a.phk APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks

The following tasks are purely cosmetic or represent such an investment of work that it is not likely that anyone will get them done anytime soon:

The first 20 items are from Terry Lambert <terry@lambert.org> Ability to make BIOS calls from protected mode using V86 mode on the processor and return the results via a mapped interrupt IPC mechanism to the protected mode caller. Drivers built into the kernel that use the BIOS call mechanism to allow them to be independent of the actual underlying hardware the same way that DOS is independent of the underlying hardware. This includes NetWork and ASPI drivers loaded in DOS prior to BSD being loaded by a DOS-based loader program, which means potential polling, which means DOS-not-busy interrupt generation for V86 machines by the protected mode kernel. An image format that allows tagging of such drivers data and text areas in the default kernel executable so that that portion of the kernel address space may be recovered at a later time, after hardware specific protected mode drivers have been loaded and activated. This includes separation of BIOS based drivers from each other, since it is better to run with a BIOS based driver in all cases than to not run at all. Abstraction of the bus interface mechanism. Currently, PCMCIA, EISA, and PCI busses are assumed to be bridged from ISA. This is not something which should be assumed. A configuration manager that knows about PNP events, including power management events, insertion, extraction, and bus (PNP ISA and PCMCIA bridging chips) vs. card level event management. A topological sort mechanism for assigning reassignable addresses that do not collide with other reassignable and non-reassignable device space resource usage by fixed devices. A registration based mechanism for hardware services registration. Specifically, a device centric registration mechanism for timer and sound and other system critical service providers. Consider Timer2 and Timer0 and speaker services as one example of a single monolithic service provider. A kernel exported symbol space in the kernel data space accessible by an LKM loader mechanism that does relocation and symbol space manipulation. The intent of this interface is to support the ability to demand load and unload kernel modules. NetWare Server (protected mode ODI driver) loader and subservices to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Splitting of the console driver into abstraction layers, both to make it easier to port and to kill the X and ThinkPad and PS/2 mouse and LED and console switching and bouncing NumLock problems once and for all. Other kernel emulation environments for other foreign drivers as opportunity permits. SCO and Solaris are good candidates, followed by UnixWare, etc. Processor emulation environments for execution of foreign binaries. This is easier than it sounds if the system call interface does not change much. Streams to allow the use of commercial streams drivers. Kernel multithreading (requires kernel preemption). Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting internal vs. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Reorganization of the source tree for multiple platform ports. A "make world" that "makes the world" (rename the current one to "make regress" if that is all it is good for). A 4M (preferably smaller!) memory footprint. How to contribute

Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary

If you have a bug to report or a suggestion to make: An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See for more information about this and other mailing lists. An actual bug report should be filed by using the send-pr(1) program. 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 is suggested there. You should receive confirmation of your bug report and a tracking number. Keep this tracking number and use it 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(1) command, then you may also file a bug report by sending mail to the &a.bugs;. Changes to the documentation

Changes to the documentation are overseen by the &a.doc;. This does not generally include changes to manual pages, which should be considered under the category of "changes to existing source code." Changes to existing source code

An addition or change to the existing source code is a somewhat trickier affair and depends a lot on how far out of date you are with the current state of the core FreeBSD development. There is a special on-going release of FreeBSD known as ``FreeBSD-current'' which is made available in a variety of ways for the convenience of developers working actively on the system. See for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce and the &a.current lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the diff(1) command, with the `context diff' form being preferred. For example: diff -c oldfile newfile or diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for diff(1) for more details. Once you have a set of diffs (which you may test with the patch(1) command), you should bundle them up in an email message and send it, along with a brief description of what the diffs are for, to the &a.hackers;. 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 do not express themselves well as diffs alone (e.g. you have perhaps added, deleted or renamed files as well) then you may be better off bundling any new files, diffs and instructions for deleting/renaming others into a tar file and running the uuencode(1) program on it before sending the output of that to the &a.hackers;. See the man pages on tar(1) and uuencode(1) for more information on bundling files this way. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, - then you should send it to rather than the &a.hackers + then you should send it to &a.core; rather than the &a.hackers The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them in cases where mailing to hackers is truly impractical. New code or major value-added packages

In the case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it becomes almost always necessary to either send changes as uuencoded tar files or upload them to our ftp site . When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its ``no strings attached'' nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or ``GPL''. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem.

Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a ``BSD-style'' copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the `%%' with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - $Id: submitters.sgml,v 1.31 1996-08-03 13:46:00 jkh Exp $ + $Id: submitters.sgml,v 1.32 1996-09-22 15:40:46 wosch Exp $ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. &porting; Money, Hardware or Internet access

We are always very happy to accept donations to further the cause of the FreeBSD Project and, in a volunteer effort like ours, a little can go a long way! Donations of hardware are also very important to expanding our list of supported peripherals since we generally lack the funds to buy such items ourselves. Donating funds

While the FreeBSD Project is not a 501(C3) (non-profit) corporation and hence cannot offer special tax incentives for any donations made, any such donations will be gratefully accepted on behalf of the project by FreeBSD, Inc.

FreeBSD, Inc. was founded in early 1995 by &a.jkh and &a.davidg with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address: FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, suite #D. Concord CA, 94520 [temporarily using the Walnut Creek CDROM address until a PO box can be opened] Wire transfers may also be sent directly to: Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.) If you do not wish to be listed in our section, please specify this when making your donation. Thanks! Donating hardware

Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.davidg for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to -see such support added. Please contact the before sending +see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of them. Donating Internet access

We can always use new mirror sites for FTP, WWW or sup. If you would like to be such a mirror, please contact for more information. Donors Gallery

The FreeBSD Project is indebted to the following donors and would like to publically thank them here! has generously donated funding for the further development of FreeBSD has generously donated funding for FreeBSD development. has generously donated funding for FreeBSD development. in Japan has graciously donated a portion of their profits from the sale of their FreeBSD for PC98'ers CD, a port of FreeBSD to the NEC PC98. has donated almost more than we can say (see the document for more details). In particular, we would like to thank them for the hardware used for freefall.FreeBSD.ORG, our primary development machine, and for thud.FreeBSD.ORG, our testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet.