Disconnect the FAQ and handbook from the makefiles and remove the files.
The FAQ and handbook have been repository copied to their own top-level
("doc") directory in the cvs tree which will not be branched so as to
avoid the syncing problems. At some point, the sgml text will require
formatting tools that will be from ports rather than the main source tree.
Requested by: jfieber, jkh
This commit is contained in:
peter
parent
39fd96b7d3
commit
d93f6c868e
File diff suppressed because it is too large
Load Diff
@ -1,6 +0,0 @@
|
||||
# $Id$
|
||||
|
||||
DOC= FAQ
|
||||
SRCS= FAQ.sgml
|
||||
|
||||
.include <bsd.sgml.mk>
|
||||
@ -1,23 +1,7 @@
|
||||
# From: @(#)Makefile 8.1 (Berkeley) 6/5/93
|
||||
# $Id$
|
||||
# $Id: Makefile,v 1.12 1997/02/22 12:57:48 peter Exp $
|
||||
|
||||
SUBDIR= FAQ handbook psd smm usd papers
|
||||
|
||||
# List of all language-specific subdirs.
|
||||
LANGSUBDIR= ja_JP.EUC
|
||||
|
||||
# If ALLLANG is defined, descend to all language-specific subdirs too.
|
||||
# If ALLLANG is not defined, but LANG is defined and a subdirectory with
|
||||
# that name exists, descend to that directory too.
|
||||
# In either case, the default subdirectories are always traversed.
|
||||
|
||||
.if defined(ALLLANG)
|
||||
SUBDIR+= ${LANGSUBDIR}
|
||||
.elif defined(LANG)
|
||||
.if exists(${.CURDIR}/${LANG})
|
||||
SUBDIR+= ${LANG}
|
||||
.endif
|
||||
.endif
|
||||
SUBDIR= psd smm usd papers
|
||||
|
||||
# Default output formats are ascii for troff documents, and
|
||||
# ascii and html for sgml documents.
|
||||
|
||||
@ -1,19 +0,0 @@
|
||||
# $Id: Makefile,v 1.25 1997/05/02 02:20:25 ache Exp $
|
||||
|
||||
SGMLOPTS=-links
|
||||
SRCS= authors.sgml basics.sgml bibliography.sgml boothelp.sgml
|
||||
SRCS+= booting.sgml contrib.sgml crypt.sgml ctm.sgml current.sgml cvsup.sgml
|
||||
SRCS+= cyclades.sgml development.sgml dialup.sgml dialout.sgml
|
||||
SRCS+= diskless.sgml dma.sgml eresources.sgml esdi.sgml
|
||||
SRCS+= firewalls.sgml glossary.sgml goals.sgml
|
||||
SRCS+= handbook.sgml history.sgml hw.sgml install.sgml isdn.sgml
|
||||
SRCS+= kerberos.sgml kernelconfig.sgml kerneldebug.sgml kernelopts.sgml
|
||||
SRCS+= lists.sgml mail.sgml memoryuse.sgml
|
||||
SRCS+= mirrors.sgml nfs.sgml nutshell.sgml pgpkeys.sgml policies.sgml
|
||||
SRCS+= porting.sgml ports.sgml ppp.sgml printing.sgml
|
||||
SRCS+= quotas.sgml relnotes.sgml routing.sgml russian.sgml
|
||||
SRCS+= serial.sgml scsi.sgml sections.sgml sio.sgml skey.sgml slipc.sgml
|
||||
SRCS+= slips.sgml stable.sgml submitters.sgml sup.sgml synching.sgml
|
||||
SRCS+= term.sgml userppp.sgml uart.sgml linuxemu.sgml
|
||||
|
||||
.include <bsd.sgml.mk>
|
||||
@ -1,489 +0,0 @@
|
||||
<!-- $Id: authors.sgml,v 1.68 1997/05/19 15:54:36 joerg Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
Names and email address of contributing authors and CVS committers.
|
||||
Use these entities when referencing people. Please note the use of single
|
||||
and double quotes.
|
||||
Please keep this list in alphabetical order by entity names.
|
||||
-->
|
||||
|
||||
<!ENTITY a.ache "Andrey A. Chernov
|
||||
<tt><htmlurl url='mailto:ache@FreeBSD.ORG'
|
||||
name='<ache@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.adam "Adam David
|
||||
<tt><htmlurl url='mailto:adam@FreeBSD.ORG'
|
||||
name='<adam@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.alex "Alex Nash
|
||||
<tt><htmlurl url='mailto:alex@freebsd.org'
|
||||
name='<alex@freebsd.org>'></tt>">
|
||||
|
||||
<!ENTITY a.amurai "Atsushi Murai
|
||||
<tt><htmlurl url='mailto:amurai@FreeBSD.ORG'
|
||||
name='<amurai@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.andreas "Andreas Klemm
|
||||
<tt><htmlurl url='mailto:andreas@FreeBSD.ORG'
|
||||
name='<andreas@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.asami "Satoshi Asami
|
||||
<tt><htmlurl url='mailto:asami@FreeBSD.ORG'
|
||||
name='<asami@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ats "Andreas Schulz
|
||||
<tt><htmlurl url='mailto:ats@FreeBSD.ORG'
|
||||
name='<ats@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.awebster "Andrew Webster
|
||||
<tt><htmlurl url='mailto:awebster@pubnix.net'
|
||||
name='<awebster@pubnix.net>'></tt>">
|
||||
|
||||
<!ENTITY a.bde "Bruce Evans
|
||||
<tt><htmlurl url='mailto:bde@FreeBSD.ORG'
|
||||
name='<bde@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.brian "Brian Somers
|
||||
<tt><htmlurl url='mailto:brian@awfulhak.org'
|
||||
name='<brian@awfulhak.org>'></tt>">
|
||||
|
||||
<!ENTITY a.cawimm "Charles A. Wimmer
|
||||
<tt><htmlurl url='mailto:cawimm@FreeBSD.ORG'
|
||||
name='<cawimm@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.charnier "Philippe Charnier
|
||||
<tt><htmlurl url='mailto:charnier@FreeBSD.ORG'
|
||||
name='<charnier@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.chuck "Chuck Robey
|
||||
<tt><htmlurl url='mailto:chuckr@glue.umd.edu'
|
||||
name='<chuckr@glue.umd.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.chuckr "Chuck Robey
|
||||
<tt><htmlurl url='mailto:chuckr@FreeBSD.ORG'
|
||||
name='<chuckr@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.cracauer "Martin Cracauer
|
||||
<tt><htmlurl url='mailto:cracauer@FreeBSD.ORG'
|
||||
name='<cracauer@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.csgr "Geoff Rehmet
|
||||
<tt><htmlurl url='mailto:csgr@FreeBSD.ORG'
|
||||
name='<csgr@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.danny "Daniel O'Callaghan
|
||||
<tt><htmlurl url='mailto:danny@FreeBSD.ORG'
|
||||
name='<danny@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.darrenr "Darren Reed
|
||||
<tt><htmlurl url='mailto:darrenr@FreeBSD.ORG'
|
||||
name='<darrenr@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.dave "Dave Cornejo
|
||||
<tt><htmlurl url='mailto:dave@FreeBSD.ORG'
|
||||
name='<dave@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.davidg "David Greenman
|
||||
<tt><htmlurl url='mailto:davidg@FreeBSD.ORG'
|
||||
name='<davidg@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.davidn "David Nugent
|
||||
<tt><htmlurl url='mailto:davidn@blaze.net.au'
|
||||
name='<davidn@blaze.net.au>'></tt>">
|
||||
|
||||
<!ENTITY a.dfr "Doug Rabson
|
||||
<tt><htmlurl url='mailto:dfr@FreeBSD.ORG'
|
||||
name='<dfr@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.dima "Dima Ruban
|
||||
<tt><htmlurl url='mailto:dima@FreeBSD.ORG'
|
||||
name='<dima@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.dirkvangulik "Dirk-Willem van Gulik
|
||||
<tt><htmlurl url='mailto:Dirk.vanGulik@jrc.it'
|
||||
name='<Dirk.vanGulik@jrc.it>'></tt>">
|
||||
|
||||
<!ENTITY a.dufault "Peter Dufault
|
||||
<tt><htmlurl url='mailto:dufault@FreeBSD.ORG'
|
||||
name='<dufault@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.dyson "John Dyson
|
||||
<tt><htmlurl url='mailto:dyson@FreeBSD.ORG'
|
||||
name='<dyson@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.eivind "Eivind Eklund
|
||||
<tt><htmlurl url='mailto:perhaps@yes.no'
|
||||
name='<perhaps@yes.no>'></tt>">
|
||||
|
||||
<!ENTITY a.erich "Eric L. Hernes
|
||||
<tt><htmlurl url='mailto:erich@FreeBSD.ORG'
|
||||
name='<erich@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.fenner "Bill Fenner
|
||||
<tt><htmlurl url='mailto:fenner@FreeBSD.ORG'
|
||||
name='<fenner@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.fsmp "Steve Passe
|
||||
<tt><htmlurl url='mailto:fsmp@FreeBSD.ORG'
|
||||
name='<fsmp@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gclarkii "Gary Clark II
|
||||
<tt><htmlurl url='mailto:gclarkii@FreeBSD.ORG'
|
||||
name='<gclarkii@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gena "Gennady B. Sorokopud
|
||||
<tt><htmlurl url='mailto:gena@NetVision.net.il'
|
||||
name='<gena@NetVision.net.il>'></tt>">
|
||||
|
||||
<!ENTITY a.ghelmer "Guy Helmer
|
||||
<tt><htmlurl url='mailto:ghelmer@alpha.dsu.edu'
|
||||
name='<ghelmer@alpha.dsu.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.gibbs "Justin T. Gibbs
|
||||
<tt><htmlurl url='mailto:gibbs@FreeBSD.ORG'
|
||||
name='<gibbs@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gj "Gary Jennejohn
|
||||
<tt><htmlurl url='mailto:gj@FreeBSD.ORG'
|
||||
name='<gj@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gpalmer "Gary Palmer
|
||||
<tt><htmlurl url='mailto:gpalmer@FreeBSD.ORG'
|
||||
name='<gpalmer@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.graichen "Thomas Graichen
|
||||
<tt><htmlurl url='mailto:graichen@FreeBSD.ORG'
|
||||
name='<graichen@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gryphon "Coranth Gryphon
|
||||
<tt><htmlurl url='mailto:gryphon@healer.com'
|
||||
name='<gryphon@healer.com>'></tt>">
|
||||
|
||||
<!ENTITY a.guido "Guido van Rooij
|
||||
<tt><htmlurl url='mailto:guido@FreeBSD.ORG'
|
||||
name='<guido@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.hanai "Hiroyuki HANAI
|
||||
<tt><htmlurl url='mailto:hanai@FreeBSD.ORG'
|
||||
name='<hanai@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.handy "Brian N. Handy
|
||||
<tt><htmlurl url='mailto:handy@sxt4.physics.montana.edu'
|
||||
name='<handy@sxt4.physics.montana.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.hm "Hellmuth Michaelis
|
||||
<tt><htmlurl url='mailto:hm@kts.org'
|
||||
name='<hm@kts.org>'></tt>">
|
||||
|
||||
<!ENTITY a.hsu "Jeffrey Hsu
|
||||
<tt><htmlurl url='mailto:hsu@FreeBSD.ORG'
|
||||
name='<hsu@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.imp "Warner Losh
|
||||
<tt><htmlurl url='mailto:imp@FreeBSD.ORG'
|
||||
name='<imp@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jb "John Birrell
|
||||
<tt><htmlurl url='mailto:jb@cimlogic.com.au'
|
||||
name='<jb@cimlogic.com.au>'></tt>">
|
||||
|
||||
<!ENTITY a.jdp "John Polstra
|
||||
<tt><htmlurl url='mailto:jdp@FreeBSD.ORG'
|
||||
name='<jdp@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jehamby "Jake Hamby
|
||||
<tt><htmlurl url='mailto:jehamby@lightside.com'
|
||||
name='<jehamby@lightside.com>'></tt>">
|
||||
|
||||
<!ENTITY a.jfieber "John Fieber
|
||||
<tt><htmlurl url='mailto:jfieber@FreeBSD.ORG'
|
||||
name='<jfieber@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jfitz "James FitzGibbon
|
||||
<tt><htmlurl url='mailto:james@nexis.net'
|
||||
name='<james@nexis.net>'></tt>">
|
||||
|
||||
<!ENTITY a.jgreco "Joe Greco
|
||||
<tt><htmlurl url='mailto:jgreco@FreeBSD.ORG'
|
||||
name='<jgreco@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jhay "John Hay
|
||||
<tt><htmlurl url='mailto:jhay@FreeBSD.ORG'
|
||||
name='<jhay@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jkh "Jordan K. Hubbard
|
||||
<tt><htmlurl url='mailto:jkh@FreeBSD.ORG'
|
||||
name='<jkh@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jlind "John Lind
|
||||
<tt><htmlurl url='mailto:john@starfire.MN.ORG'
|
||||
name='<john@starfire.MN.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jlrobin "James L. Robinson
|
||||
<tt><htmlurl url='mailto:jlrobin@FreeBSD.ORG'
|
||||
name='<jlrobin@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jmacd "Joshua Peck Macdonald
|
||||
<tt><htmlurl url='mailto:jmacd@FreeBSD.ORG'
|
||||
name='<jmacd@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jmb "Jonathan M. Bresler
|
||||
<tt><htmlurl url='mailto:jmb@FreeBSD.ORG'
|
||||
name='<jmb@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jmg "John-Mark Gurney
|
||||
<tt><htmlurl url='mailto:jmg@FreeBSD.ORG'
|
||||
name='<jmg@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jmz "Jean-Marc Zucconi
|
||||
<tt><htmlurl url='mailto:jmz@FreeBSD.ORG'
|
||||
name='<jmz@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.joerg "Jörg Wunsch
|
||||
<tt><htmlurl url='mailto:joerg@FreeBSD.ORG'
|
||||
name='<joerg@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.john "John Cavanaugh
|
||||
<tt><htmlurl url='mailto:john@FreeBSD.ORG'
|
||||
name='<john@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jraynard "James Raynard
|
||||
<tt><htmlurl url='mailto:jraynard@freebsd.org'
|
||||
name='<jraynard@freebsd.org>'></tt>">
|
||||
|
||||
<!ENTITY a.julian "Julian Elischer
|
||||
<tt><htmlurl url='mailto:julian@FreeBSD.ORG'
|
||||
name='<julian@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jvh "Johannes Helander
|
||||
<tt><htmlurl url='mailto:jvh@FreeBSD.ORG'
|
||||
name='<jvh@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.karl "Karl Strickland
|
||||
<tt><htmlurl url='mailto:karl@FreeBSD.ORG'
|
||||
name='<karl@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.kato "Takenori KATO
|
||||
<tt><htmlurl url='mailto:kato@FreeBSD.ORG'
|
||||
name='<kato@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.kelly "Sean Kelly
|
||||
<tt><htmlurl url='mailto:kelly@fsl.noaa.gov'
|
||||
name='<kelly@fsl.noaa.gov>'></tt>">
|
||||
|
||||
<!ENTITY a.kjc "Kenjiro Cho
|
||||
<tt><htmlurl url='mailto:kjc@FreeBSD.ORG'
|
||||
name='<kjc@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.lars "Lars Fredriksen
|
||||
<tt><htmlurl url='mailto:lars@FreeBSD.ORG'
|
||||
name='<lars@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ljo "L Jonas Olsson
|
||||
<tt><htmlurl url='mailto:ljo@FreeBSD.ORG'
|
||||
name='<ljo@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.markm "Mark Murray
|
||||
<tt><htmlurl url='mailto:markm@FreeBSD.ORG'
|
||||
name='<markm@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.martin "Martin Renters
|
||||
<tt><htmlurl url='mailto:martin@FreeBSD.ORG'
|
||||
name='<martin@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.max "Masafumi NAKANE
|
||||
<tt><htmlurl url='mailto:max@FreeBSD.ORG'
|
||||
name='<max@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.mayo "Mark Mayo
|
||||
<tt><htmlurl url='mailto:mayo@quickweb.com'
|
||||
name='<mayo@quickweb.com>'></tt>">
|
||||
|
||||
<!ENTITY a.mbarkah "Ade Barkah
|
||||
<tt><htmlurl url='mailto:mbarkah@FreeBSD.ORG'
|
||||
name='<mbarkah@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.mckay "Stephen McKay
|
||||
<tt><htmlurl url='mailto:mckay@FreeBSD.ORG'
|
||||
name='<mckay@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.md "Mark Dapoz
|
||||
<tt><htmlurl url='mailto:md@bsc.no'
|
||||
name='<md@bsc.no>'></tt>">
|
||||
|
||||
<!ENTITY a.mpp "Mike Pritchard
|
||||
<tt><htmlurl url='mailto:mpp@FreeBSD.ORG'
|
||||
name='<mpp@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.msmith "Michael Smith
|
||||
<tt><htmlurl url='mailto:msmith@FreeBSD.ORG'
|
||||
name='<msmith@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.nate "Nate Williams
|
||||
<tt><htmlurl url='mailto:nate@FreeBSD.ORG'
|
||||
name='<nate@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.nik "Nik Clayton
|
||||
<tt><htmlurl url='mailto:nik@blueberry.co.uk'
|
||||
name='<nik@blueberry.co.uk>'></tt>">
|
||||
|
||||
<!ENTITY a.nsj "Nate Johnson
|
||||
<tt><htmlurl url='mailto:nsj@FreeBSD.ORG'
|
||||
name='<nsj@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.obrien "David O'Brien
|
||||
<tt><htmlurl url='mailto:obrien@cs.ucdavis.edu'
|
||||
name='<obrien@cs.ucdavis.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.olah "Andras Olah
|
||||
<tt><htmlurl url='mailto:olah@FreeBSD.ORG'
|
||||
name='<olah@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.opsys "Chris Watson
|
||||
<tt><htmlurl url='mailto:opsys@open-systems.net'
|
||||
name='<opsys@open-systems.net>'></tt>">
|
||||
|
||||
<!ENTITY a.paul "Paul Richards
|
||||
<tt><htmlurl url='mailto:paul@FreeBSD.ORG'
|
||||
name='<paul@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.pds "Peter da Silva
|
||||
<tt><htmlurl url='mailto:pds@FreeBSD.ORG'
|
||||
name='<pds@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.peter "Peter Wemm
|
||||
<tt><htmlurl url='mailto:peter@FreeBSD.ORG'
|
||||
name='<peter@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.phk "Poul-Henning Kamp
|
||||
<tt><htmlurl url='mailto:phk@FreeBSD.ORG'
|
||||
name='<phk@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.pjc "Peter Childs
|
||||
<tt><htmlurl url='mailto:pjchilds@imforei.apana.org.au'
|
||||
name='<pjchilds@imforei.apana.org.au>'></tt>">
|
||||
|
||||
<!ENTITY a.proven "Chris Provenzano
|
||||
<tt><htmlurl url='mailto:proven@FreeBSD.ORG'
|
||||
name='<proven@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.pst "Paul Traina
|
||||
<tt><htmlurl url='mailto:pst@FreeBSD.ORG'
|
||||
name='<pst@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.rgrimes "Rodney Grimes
|
||||
<tt><htmlurl url='mailto:rgrimes@FreeBSD.ORG'
|
||||
name='<rgrimes@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.rhuff "Robert Huff
|
||||
<tt><htmlurl url='mailto:rhuff@cybercom.net'
|
||||
name='<rhuff@cybercom.net>'></tt>">
|
||||
|
||||
<!ENTITY a.ricardag "Ricardo AG
|
||||
<tt><htmlurl url='mailto:ricardag@ag.com.br'
|
||||
name='<ricardag@ag.com.br>'></tt>">
|
||||
|
||||
<!ENTITY a.rich "Rich Murphey
|
||||
<tt><htmlurl url='mailto:rich@FreeBSD.ORG'
|
||||
name='<rich@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.roberto "Ollivier Robert
|
||||
<tt><htmlurl url='mailto:roberto@FreeBSD.ORG'
|
||||
name='<roberto@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.scrappy "Marc G. Fournier
|
||||
<tt><htmlurl url='mailto:scrappy@FreeBSD.ORG'
|
||||
name='<scrappy@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.se "Stefan Esser
|
||||
<tt><htmlurl url='mailto:se@FreeBSD.ORG'
|
||||
name='<se@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.sef "Sean Eric Fagan
|
||||
<tt><htmlurl url='mailto:sef@FreeBSD.ORG'
|
||||
name='<sef@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.smace "Scott Mace
|
||||
<tt><htmlurl url='mailto:smace@FreeBSD.ORG'
|
||||
name='<smace@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.smpatel "Sujal Patel
|
||||
<tt><htmlurl url='mailto:smpatel@FreeBSD.ORG'
|
||||
name='<smpatel@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.sos "Søren Schmidt
|
||||
<tt><htmlurl url='mailto:sos@FreeBSD.ORG'
|
||||
name='<sos@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.stark "Gene Stark
|
||||
<tt><htmlurl url='mailto:stark@FreeBSD.ORG'
|
||||
name='<stark@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.stb "Stefan Bethke
|
||||
<tt><htmlurl url='mailto:stb@FreeBSD.ORG'
|
||||
name='<stb@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.steve "Steve Price
|
||||
<tt><htmlurl url='mailto:steve@FreeBSD.ORG'
|
||||
name='<steve@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.swallace "Steven Wallace
|
||||
<tt><htmlurl url='mailto:swallace@FreeBSD.ORG'
|
||||
name='<swallace@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.tedm "Ted Mittelstaedt
|
||||
<tt><htmlurl url='mailto:tedm@FreeBSD.ORG'
|
||||
name='<tedm@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.tegge "Tor Egge
|
||||
<tt><htmlurl url='mailto:tegge@FreeBSD.ORG'
|
||||
name='<tegge@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.tg "Thomas Gellekum
|
||||
<tt><htmlurl url='mailto:tg@FreeBSD.ORG'
|
||||
name='<tg@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.torstenb "Torsten Blum
|
||||
<tt><htmlurl url='mailto:torstenb@FreeBSD.ORG'
|
||||
name='<torstenb@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ugen "Ugen J.S.Antsilevich
|
||||
<tt><htmlurl url='mailto:ugen@FreeBSD.ORG'
|
||||
name='<ugen@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.uhclem "Frank Durda IV
|
||||
<tt><htmlurl url='mailto:uhclem@FreeBSD.ORG'
|
||||
name='<uhclem@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ulf "Ulf Zimmermann
|
||||
<tt><htmlurl url='mailto:ulf@FreeBSD.ORG'
|
||||
name='<ulf@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.whiteside "Don Whiteside
|
||||
<tt><htmlurl url='mailto:whiteside@acm.org'
|
||||
name='<whiteside@acm.org>'></tt>">
|
||||
|
||||
<!ENTITY a.wilko "Wilko Bulte
|
||||
<tt><htmlurl url='mailto:wilko@yedi.iaf.nl'
|
||||
name='<wilko@yedi.iaf.nl>'></tt>">
|
||||
|
||||
<!ENTITY a.wlloyd "Bill Lloyd
|
||||
<tt><htmlurl url='mailto:wlloyd@mpd.ca'
|
||||
name='<wlloyd@mpd.ca>'></tt>">
|
||||
|
||||
<!ENTITY a.wollman "Garrett Wollman
|
||||
<tt><htmlurl url='mailto:wollman@FreeBSD.ORG'
|
||||
name='<wollman@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.wosch "Wolfram Schneider
|
||||
<tt><htmlurl url='mailto:wosch@FreeBSD.ORG'
|
||||
name='<wosch@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.wpaul "Bill Paul
|
||||
<tt><htmlurl url='mailto:wpaul@FreeBSD.ORG'
|
||||
name='<wpaul@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.yokota "Kazutaka YOKOTA
|
||||
<tt><htmlurl url='mailto:yokota@FreeBSD.ORG'
|
||||
name='<yokota@FreeBSD.ORG>'></tt>">
|
||||
@ -1,96 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Unix Basics<label id="basics"></heading>
|
||||
|
||||
<sect>
|
||||
<heading>The online manual<label id="basics:man"></heading>
|
||||
|
||||
<p>The most comprehensive documentation on FreeBSD is in
|
||||
the form of <em>man pages</em>. Nearly every program
|
||||
on the system comes with a short reference manual
|
||||
explaining the basic operation and various arguments.
|
||||
These manuals can be view with the
|
||||
<tt><bf>man</bf></tt> command. Use of the
|
||||
<tt><bf>man</bf></tt> command is simple:
|
||||
<tscreen>
|
||||
<bf>man</bf> <it>command</it>
|
||||
</tscreen>
|
||||
where <it>command</it> is the name of the command
|
||||
you wish to learn about. For example, to learn more about
|
||||
<tt><bf>ls</bf></tt> command type:
|
||||
<tscreen>
|
||||
% <bf>man ls</bf>
|
||||
</tscreen>
|
||||
|
||||
<p>The online manual is divided up into numbered
|
||||
sections:
|
||||
<enum>
|
||||
<item>User commands</item>
|
||||
<item>System calls and error numbers</item>
|
||||
<item>Functions in the C libraries</item>
|
||||
<item>Device drivers</item>
|
||||
<item>File formats</item>
|
||||
<item>Games and other diversions</item>
|
||||
<item>Miscellaneous information</item>
|
||||
<item>System maintenance and operation commands</item>
|
||||
</enum>
|
||||
in some cases, the same topic may appear in more than
|
||||
one section of the on-line manual. For example, there
|
||||
is a <tt><bf>chmod</bf></tt> user command and a
|
||||
<tt><bf>chmod()</bf></tt> system call. In this case,
|
||||
you can tell the <tt><bf>man</bf></tt> command which
|
||||
one you want by specifying the section:
|
||||
<tscreen>
|
||||
% <bf>man 1 chmod</bf>
|
||||
</tscreen>
|
||||
which will display the manual page for the user command
|
||||
<tt><bf>chmod</bf></tt>. References to a particular
|
||||
section of the on-line manual are traditionally placed
|
||||
in parenthesis in written documentation, so
|
||||
<tt><bf>chmod(1)</bf></tt> refers to the <tt><bf>chmod
|
||||
</bf></tt> user command and <tt><bf>chmod(2)</bf></tt>
|
||||
refers to the system call.
|
||||
|
||||
<p>This is fine if you know the name of the command and
|
||||
simply wish to know how to use it, but what if you cannot recall the
|
||||
command name? You can use <tt><bf>man</bf></tt> to
|
||||
search for keywords in the command <em>descriptions</em> by
|
||||
using the <tt><bf>-k</bf></tt> switch:
|
||||
<tscreen>
|
||||
% <bf>man -k mail</bf>
|
||||
</tscreen>
|
||||
With this command you will be presented with a list of
|
||||
commands that have the keyword `mail' in their
|
||||
descriptions. This is actually functionally equivalent to
|
||||
using the <tt><bf>apropos</bf></tt> command.
|
||||
|
||||
<p>So, you are looking at all those fancy commands in <tt>
|
||||
/usr/bin</tt> but do not even have the faintest idea
|
||||
what most of them actually do? Simply do a
|
||||
<tscreen>
|
||||
% <bf>cd /usr/bin; man -f *</bf>
|
||||
</tscreen>
|
||||
or
|
||||
<tscreen>
|
||||
% <bf>cd /usr/bin; whatis *</bf>
|
||||
</tscreen>
|
||||
which does the same thing.
|
||||
|
||||
<sect>
|
||||
<heading>GNU Info files<label id="basics:info"></heading>
|
||||
|
||||
<p>FreeBSD includes many applications and utilities
|
||||
produced by the Free Software Foundation (FSF). In
|
||||
addition to man pages, these programs come with more
|
||||
extensive hypertext documents called <em>info</em>
|
||||
files which can be viewed with the <tt>info</tt>
|
||||
command or, if you installed <tt>emacs</tt>, the info
|
||||
mode of <tt>emacs</tt>.
|
||||
|
||||
To use the <tt>info(1)</tt> command, simply type:
|
||||
<tscreen>% <bf>info</bf></tscreen> For a brief
|
||||
introduction, type <tt><bf>h</bf></tt>. For a quick
|
||||
command reference, type <tt><bf>?</bf></tt>.
|
||||
|
||||
|
||||
@ -1,334 +0,0 @@
|
||||
<!-- $Id: bibliography.sgml,v 1.25 1997/03/19 07:59:19 obrien Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt>
|
||||
<heading>Bibliography<label id="bibliography"></heading>
|
||||
|
||||
<p>While the manual pages provide the definitive reference
|
||||
for individual pieces of the FreeBSD operating system,
|
||||
they are notorious for not illustrating how to put the
|
||||
pieces together to make the whole operating system run
|
||||
smoothly. For this, there is no substitute for a good
|
||||
book on UNIX system administration and a good users'
|
||||
manual.
|
||||
|
||||
<sect>
|
||||
<heading>Books & magazines specific to FreeBSD</heading>
|
||||
|
||||
<p><bf>International books & Magazines:</bf>
|
||||
|
||||
<p><itemize>
|
||||
<item><htmlurl url="http://freebsd.csie.nctu.edu.tw/~jdli/book.html"
|
||||
name="Using FreeBSD"> (in Chinese).
|
||||
<item>FreeBSD for PC 98'ers (in Japanese), published by SHUWA
|
||||
System Co, LTD. ISBN4-87966-468-5 C3055 P2900E.
|
||||
<item>FreeBSD (in Japanese), published by CUTT.
|
||||
ISBN4-906391-22-2 C3055 P2400E.
|
||||
</itemize>
|
||||
|
||||
<p><bf>English language books & Magazines:</bf>
|
||||
|
||||
<p><itemize>
|
||||
<item><htmlurl url="http://www.cdrom.com/titles/os/bsdbook2.htm"
|
||||
name="The Complete FreeBSD">, published by <htmlurl
|
||||
url="http://www.cdrom.com" name="Walnut Creek CDROM">.
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>Users' guides</heading>
|
||||
|
||||
<p><itemize>
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD User's Reference Manual</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-075-9</item>
|
||||
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD User's Supplementary Documents</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-076-7</item>
|
||||
|
||||
<item><sl>UNIX in a Nutshell</sl>.
|
||||
O'Reilly & Associates, Inc., 1990.
|
||||
<newline>ISBN 093717520X</item>
|
||||
|
||||
<item>Mui, Linda.
|
||||
<em>What You Need To Know When You Can't Find Your UNIX
|
||||
System Administrator</em>.
|
||||
O'Reilly & Associates, Inc., 1995.
|
||||
<newline>ISBN 1-56592-104-6 </item>
|
||||
|
||||
<item><htmlurl url="http://www-wks.acs.ohio-state.edu/"
|
||||
name="Ohio State University"> has written
|
||||
a <htmlurl
|
||||
url="http://www-wks.acs.ohio-state.edu/unix_course/unix.html"
|
||||
name="UNIX Introductory Course"> which is available online
|
||||
in HTML and postscript format.</item>
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>Administrators' guides</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Albitz, Paul and Liu, Cricket. <em>DNS and
|
||||
BIND</em>, 2nd Ed.
|
||||
O'Reilly & Associates, Inc., 1997.
|
||||
<newline>ISBN 1-56592-236-0 </item>
|
||||
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD System Manager's Manual</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-080-5</item>
|
||||
|
||||
<item>Costales, Brian, et al.
|
||||
<em>Sendmail</em>, 2nd Ed. O'Reilly &
|
||||
Associates, Inc., 1997.
|
||||
<newline>ISBN 1-56592-222-0 </item>
|
||||
|
||||
<item>Frisch, Æleen. <em>Essential System
|
||||
Administration</em>, 2nd Ed. O'Reilly &
|
||||
Associates, Inc., 1995. <newline>ISBN 1-56592-127-5 </item>
|
||||
|
||||
<item>Hunt, Craig. <em>TCP/IP Network Administration</em>.
|
||||
O'Reilly & Associates, Inc., 1992.
|
||||
<newline>ISBN 0-937175-82-X</item>
|
||||
|
||||
<item>Nemeth, Evi. <em>UNIX System Administration
|
||||
Handbook</em>. 2nd ed. Prentice Hall, 1995.
|
||||
<newline>ISBN 0131510517</item>
|
||||
|
||||
<item>Stern, Hal <em>Managing NFS and NIS</em>
|
||||
O'Reilly & Associates, Inc., 1991.
|
||||
<newline>ISBN 1-937175-75-7 </item>
|
||||
|
||||
</itemize>
|
||||
|
||||
|
||||
|
||||
<sect>
|
||||
<heading>Programmers' guides</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Asente, Paul. <em>X Window System
|
||||
Toolkit</em>. Digital Press.
|
||||
<newline>ISBN 1-55558-051-3</item>
|
||||
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD Programmer's Reference Manual</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-078-3</item>
|
||||
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD Programmer's Supplementary Documents</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-079-1</item>
|
||||
|
||||
<item>Ellis, Margaret A. and Stroustrup,
|
||||
Bjarne. <em>The Annotated C++ Reference
|
||||
Manual</em>. Addison-Wesley, 1990.
|
||||
<newline>ISBN 0-201-51459-1</item>
|
||||
|
||||
<item>Harbison, Samuel P. and Steele, Guy
|
||||
L. Jr. <em>C: A Reference Manual</em>. 4rd ed. Prentice
|
||||
Hall, 1995. <newline>ISBN 0-13-326224-3</item>
|
||||
|
||||
<item>Kernighan, Brian and Dennis M. Ritchie.
|
||||
<em>The C Programming Language.</em>.
|
||||
PTR Prentice Hall, 1988.
|
||||
<newline>ISBN 0-13-110362-9</item>
|
||||
|
||||
<item>Lehey, Greg.
|
||||
<em>Port UNIX Software</em>.
|
||||
O'Reilly & Associates, Inc., 1995.
|
||||
<newline>ISBN 1-56592-126-7</item>
|
||||
|
||||
<item>Plauger, P. J. <em>The Standard C
|
||||
Library</em>. Prentice Hall, 1992.
|
||||
<newline>ISBN 0-13-131509-9</item>
|
||||
|
||||
<item>Stevens, W. Richard. <em>Advanced
|
||||
Programming in the UNIX Environment</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1992
|
||||
<newline>ISBN 0-201-56317-7</item>
|
||||
|
||||
<item>Stevens, W. Richard. <em>UNIX Network
|
||||
Programming</em>. PTR Prentice Hall, 1990.
|
||||
<newline>ISBN 0-13-949876-1</item>
|
||||
|
||||
<item>Wells, Bill. "Writing Serial Drivers for UNIX".
|
||||
<em>Dr. Dobb's Journal</em>. 19(15), December
|
||||
1994. pp68-71, 97-99.</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>Operating System Internals</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Andleigh, Prabhat K. <em>UNIX System Architecture</em>.
|
||||
Prentice-Hall, Inc., 1990.
|
||||
<newline>ISBN 0-13-949843-5</item>
|
||||
|
||||
<item>Jolitz, William. "Porting UNIX to the
|
||||
386". <em>Dr. Dobb's Journal</em>. January
|
||||
1991-July 1992.</item>
|
||||
|
||||
<item>Leffler, Samuel J., Marshall Kirk McKusick,
|
||||
Michael J Karels and John Quarterman <em>The Design and
|
||||
Implementation of the 4.3BSD UNIX Operating
|
||||
System</em>. Reading, Mass. : Addison-Wesley, 1989.
|
||||
<newline>ISBN 0-201-06196-1</item>
|
||||
|
||||
<item>Leffler, Samuel J., Marshall Kirk McKusick,
|
||||
<em>The Design and Implementation of the 4.3BSD
|
||||
UNIX Operating System: Answer Book</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1991.
|
||||
<newline>ISBN 0-201-54629-9</item>
|
||||
|
||||
<item>McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
|
||||
and John Quarterman. <em>The Design and
|
||||
Implementation of the 4.4BSD Operating
|
||||
System</em>. Reading, Mass. : Addison-Wesley, 1996.
|
||||
<newline>ISBN 0-201-54979-4</item>
|
||||
|
||||
<item>Stevens, W. Richard. <em>TCP/IP Illustrated,
|
||||
Volume 1: The Protocols</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1996.
|
||||
<newline>ISBN 0-201-63346-9</item>
|
||||
|
||||
<item>Stevens, W. Richard. <em>TCP/IP Illustrated,
|
||||
Volume 3: TCP for Transactions, HTTP, NNTP
|
||||
and the UNIX Domain Protocols</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1996.
|
||||
<newline>ISBN 0-201-63495-3</item>
|
||||
|
||||
<item>Vahalia, Uresh. <em>UNIX Internals -- The New Frontiers</em>.
|
||||
Prentice Hall, 1996.
|
||||
<newline>ISBN 0-13-101908-2</item>
|
||||
|
||||
<item>Wright, Gary R. and W. Richard Stevens.
|
||||
<em>TCP/IP Illustrated, Volume 2:
|
||||
The Implementation</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1995.
|
||||
<newline>ISBN 0-201-63354-X</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
|
||||
<sect>
|
||||
<heading>Security reference</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Cheswick, William R. and Steven M. Bellovin.
|
||||
<em>Firewalls and Internal Security:
|
||||
Repelling the Wily Hacker</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1995.
|
||||
<newline>ISBN 1-201-63357-4 </item>
|
||||
|
||||
<item>Garfinkel, Simson and Gene Spafford.
|
||||
<em>Practical UNIX Security</em>. 2nd Ed.
|
||||
O'Reilly & Associates, Inc., 1996.
|
||||
<newline>ISBN 1-56592-148-8 </item>
|
||||
|
||||
<item>Garfinkel, Simson.
|
||||
<em>PGP Pretty Good Privacy</em>
|
||||
O'Reilly & Associates, Inc., 1995.
|
||||
<newline>ISBN 1-56592-098-8 </item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>Hardware reference</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Anderson, Don and Tom Shanley.
|
||||
<em>Pentium Processor System Architecture</em>.
|
||||
2nd ed. Reading, Mass. : Addison-Wesley, 1995.
|
||||
<newline>ISBN 0-201-40992-5</item>
|
||||
|
||||
<item>Ferraro, Richard F. <em>Programmer's Guide
|
||||
to the EGA, VGA, and Super VGA Cards</em>.
|
||||
3rd ed. Reading, Mass. : Addison-Wesley, 1995.
|
||||
<newline>ISBN 0-201-62490-7</item>
|
||||
|
||||
<item>Shanley, Tom. <em>80486 System
|
||||
Architecture</em>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <newline>ISBN
|
||||
0-201-40994-1</item>
|
||||
|
||||
<item>Shanley, Tom. <em>ISA System
|
||||
Architecture</em>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995.
|
||||
<newline>ISBN 0-201-40996-8</item>
|
||||
|
||||
<item>Shanley, Tom. <em>PCI System
|
||||
Architecture</em>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <newline>ISBN
|
||||
0-201-40993-3</item>
|
||||
|
||||
<item>Van Gilluwe, Frank. <em>The Undocumented PC</em>.
|
||||
Reading, Mass: Addison-Wesley Pub. Co., 1994.
|
||||
<newline>ISBN 0-201-62277-7</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>UNIX history</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Lion, John <em>Lion's Commentary on UNIX, 6th Ed.
|
||||
With Source Code</em>.
|
||||
ITP Media Group, 1996.
|
||||
<newline>ISBN 1573980137</item>
|
||||
|
||||
<item>Raymond, Eric s. <em>The New Hacker's Dictonary,
|
||||
3rd edition</em>. MIT Press, 1996.
|
||||
<newline>ISBN 0-262-68092-0
|
||||
<newline>Also known as the
|
||||
<htmlurl url="http://www.ccil.org/jargon/jargon.html"
|
||||
name="Jargon File"></item>
|
||||
|
||||
<item>Salus, Peter H. <em>A quarter century of UNIX</em>.
|
||||
Addison-Wesley Publishing Company, Inc., 1994.
|
||||
<newline>ISBN 0-201-54777-5</item>
|
||||
|
||||
<item>Simon Garfinkel, Daniel Weise, Steven Strassmann.
|
||||
<em>The UNIX-HATERS Handbook</em>.
|
||||
IDG Books Worldwide, Inc., 1994.
|
||||
<newline>ISBN 1-56884-203-1</item>
|
||||
|
||||
<item>Don Libes, Sandy Ressler <em>Life with UNIX</em> - special
|
||||
edition. Prentice-Hall, Inc., 1989.
|
||||
<newline>ISBN 0-13-536657-7</item>
|
||||
|
||||
<item><em>The BSD family tree</em>. 1997.
|
||||
<newline>
|
||||
<htmlurl url="http://www.de.freebsd.org/de/ftp/unix-stammbaum"
|
||||
name="http://www.de.freebsd.org/de/ftp/unix-stammbaum">
|
||||
or <url url="file:/usr/share/misc/bsd-family-tree"
|
||||
name="local"> on a FreeBSD-current machine.
|
||||
</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>Magazines and journals</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item><em>The C/C++ Users Journal</em>. R&D Publications
|
||||
Inc. ISSN 1075-2838</item>
|
||||
|
||||
<item><em>Sys Admin - The Journal for UNIX System
|
||||
Administrators</em> Miller Freeman, Inc., ISSN 1061-2688</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
</sect>
|
||||
|
||||
@ -1,50 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!-- Conditional flags for this version of the document -->
|
||||
<!ENTITY % boothelp.only "INCLUDE">
|
||||
<!ENTITY % handbook.only "IGNORE">
|
||||
|
||||
<!-- Entity shorthand for authors' names and email addresses -->
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
<!-- Entity definitions for all the parts -->
|
||||
<!ENTITY % sections SYSTEM "sections.sgml">
|
||||
%sections;
|
||||
|
||||
]>
|
||||
|
||||
<linuxdoc>
|
||||
<book>
|
||||
|
||||
<title>FreeBSD Installation
|
||||
<author>
|
||||
<name></name>
|
||||
</author>
|
||||
|
||||
<abstract>Welcome to FreeBSD! This guide describes the
|
||||
FreeBSD installation process. To navigate through the
|
||||
sections in this guide using the <bf>up</bf> and
|
||||
<bf>down</bf> arrow keys to select the section you wish to
|
||||
read. Then use the <bf>right arrow</bf> or the <bf>enter
|
||||
key</bf> to view the section. You can backtrack through
|
||||
sections you have read by using the <bf>left arrow</bf>.
|
||||
</abstract>
|
||||
|
||||
<chapt><heading>General information</heading>
|
||||
&nutshell;
|
||||
&history;
|
||||
&relnotes;
|
||||
|
||||
&install;
|
||||
&troubleshooting;
|
||||
&bibliography;
|
||||
&eresources;
|
||||
&hw;
|
||||
&contrib;
|
||||
|
||||
</book>
|
||||
</linuxdoc>
|
||||
@ -1,173 +0,0 @@
|
||||
<!-- This is a SGML version of the text on FreeBSD boot procedures
|
||||
made by Poul-Henning Kamp <phk@FreeBSD.ORG>
|
||||
|
||||
This conversion has been made by Ollivier Robert.
|
||||
|
||||
$Id$
|
||||
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
||||
<article>
|
||||
|
||||
<title>Boot overview</title>
|
||||
<author>Poul-Henning Kamp, <tt/<phk@login.dknet.dk>/</author>
|
||||
<date>v1.1, April 26th</date>
|
||||
<abstract>
|
||||
Booting FreeBSD is essentially a three step: Load the kernel,
|
||||
determine the root filesystem and initialize user-land things. This
|
||||
leads to some interesting possibilities as shown below...
|
||||
</abstract>
|
||||
|
||||
<toc>
|
||||
-->
|
||||
|
||||
<sect><heading>The FreeBSD Booting Process<label id="booting"></heading>
|
||||
|
||||
<p><em>Contributed by &a.phk;. v1.1, April 26th.</em>
|
||||
|
||||
Booting FreeBSD is essentially a three step: Load the kernel,
|
||||
determine the root filesystem and initialize user-land things. This
|
||||
leads to some interesting possibilities shown below.
|
||||
|
||||
<sect1><heading>Loading a kernel</heading>
|
||||
<p>
|
||||
We presently have three basic mechanisms for loading the
|
||||
kernel as described below:
|
||||
They all pass some
|
||||
information to the kernel to help the kernel decide what to do
|
||||
next.
|
||||
|
||||
<descrip>
|
||||
<tag>Biosboot</tag>
|
||||
|
||||
Biosboot is our ``bootblocks'', it consists of two files, which
|
||||
will be installed in the first 8Kbytes of the floppy or hard-disk
|
||||
slice to be booted from.
|
||||
|
||||
Biosboot can load a kernel from a FreeBSD filesystem.
|
||||
|
||||
<tag>Dosboot</tag>
|
||||
|
||||
Dosboot was written by DI. Christian Gusenbauer, and is
|
||||
unfortunately at this time one of the few pieces of code that
|
||||
will not compile under FreeBSD itself because it is written for
|
||||
Microsoft compilers.
|
||||
|
||||
Dosboot will boot the kernel from a MS-DOS file or from a FreeBSD
|
||||
filesystem partition on the disk. It attempts to negotiate with
|
||||
the various and strange kinds of memory manglers that lurk in
|
||||
high memory on MS/DOS systems and usually wins them for its
|
||||
case.
|
||||
|
||||
<tag>Netboot</tag>
|
||||
|
||||
Netboot will try to find a supported Ethernet card, and use
|
||||
BOOTP, TFTP and NFS to find a kernel file to boot.
|
||||
</descrip>
|
||||
|
||||
|
||||
<sect1><heading>Determine the root filesystem</heading>
|
||||
<p>
|
||||
Once the kernel is loaded and the boot-code jumps to it, the kernel
|
||||
will initialize itself, trying to determine what hardware is
|
||||
present and so on, and then it needs to find a root filesystem.
|
||||
|
||||
Presently we support the following types of root filesystems:
|
||||
|
||||
<descrip>
|
||||
<tag>UFS</tag>
|
||||
|
||||
This is the most normal type of root filesystem. It can reside on
|
||||
a floppy or on hard disk.
|
||||
|
||||
<tag>MSDOS</tag>
|
||||
|
||||
While this is technically possible, it is not particular useful,
|
||||
because of ``FAT'' filesystems inability to make links, device
|
||||
nodes and such ``UNIXisms''.
|
||||
|
||||
<tag>MFS</tag>
|
||||
|
||||
This is actually a UFS filesystem which has been compiled into
|
||||
the kernel. That means that the kernel does not really need any
|
||||
disks/floppies or other HW to function.
|
||||
|
||||
<tag>CD9660</tag>
|
||||
|
||||
This is for using a CD-ROM as root filesystem.
|
||||
|
||||
<tag>NFS</tag>
|
||||
|
||||
This is for using a fileserver as root filesystem, basically
|
||||
making it a diskless machine.
|
||||
</descrip>
|
||||
|
||||
|
||||
<sect1><heading>Initialize user-land things</heading>
|
||||
<p>
|
||||
To get the user-land going, when the kernel has finished
|
||||
initialization, it will create a process with ``<tt/pid == 1/'' and execute
|
||||
a program on the root filesystem, this program is normally
|
||||
``<tt>/sbin/init</tt>''.
|
||||
|
||||
You can substitute any program for /sbin/init, as long as you keep
|
||||
in mind that:
|
||||
|
||||
there is no stdin/out/err unless you open it yourself, if you exit,
|
||||
the machine panics, signal handling is special for ``<tt/pid ==
|
||||
1/''.
|
||||
|
||||
An example of this is the ``<tt>/stand/sysinstall</tt>''
|
||||
program on the installation floppy.
|
||||
|
||||
|
||||
<sect1><heading>Interesting combinations</heading>
|
||||
<p>
|
||||
Boot a kernel with a MFS in it with a special <tt>/sbin/init</tt>
|
||||
which...
|
||||
<descrip>
|
||||
<tag/A -- Using DOS/
|
||||
<itemize>
|
||||
<item>mounts your <tt/C:/ as <tt>/C:</tt>
|
||||
<item>Attaches <tt>C:/freebsd.fs</tt> on <tt>/dev/vn0</tt>
|
||||
<item>mounts <tt>/dev/vn0</tt> as <tt>/rootfs</tt>
|
||||
<item>makes symlinks<newline>
|
||||
<tt>/rootfs/bin -> /bin</tt><newline>
|
||||
<tt>/rootfs/etc -> /etc</tt><newline>
|
||||
<tt>/rootfs/sbin -> /sbin</tt><newline>
|
||||
(etc...)<newline>
|
||||
</itemize>
|
||||
|
||||
Now you run FreeBSD without repartitioning your hard disk...
|
||||
|
||||
<tag/B -- Using NFS/
|
||||
|
||||
NFS mounts your <tt>server:˜you/FreeBSD</tt> as
|
||||
<tt>/nfs</tt>, chroots to <tt>/nfs</tt> and executes
|
||||
<tt>/sbin/init</tt> there
|
||||
|
||||
Now you run FreeBSD diskless, even though you do not control
|
||||
the NFS server...
|
||||
|
||||
<tag/C -- Start an X-server/
|
||||
|
||||
Now you have an X-terminal, which is better than that dingy
|
||||
X-under-windows-so-slow-you-can-see-what-it-does thing that
|
||||
your boss insist is better than forking our money on HW.
|
||||
|
||||
<tag/D -- Using a tape/
|
||||
Takes a copy of <tt>/dev/rwd0</tt> and writes it to a remote tape
|
||||
station or fileserver.
|
||||
|
||||
Now you finally got that backup you should have made a year
|
||||
ago...
|
||||
|
||||
<tag>E -- Acts as a firewall/web-server/what do I know...</tag>
|
||||
|
||||
This is particular interesting since you can boot from a write-
|
||||
protected floppy, but still write to your root filesystem...
|
||||
</descrip>
|
||||
|
||||
|
||||
|
||||
@ -1,502 +0,0 @@
|
||||
<!-- $Id: contrib.sgml,v 1.248 1997/05/21 03:27:15 asami Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!-- Please try to keep the file 'avail' (from CVSROOT)
|
||||
in sync with the list of FreeBSD Developers -->
|
||||
|
||||
|
||||
<chapt><heading>FreeBSD Project Staff<label id="staff"></heading>
|
||||
|
||||
<p>The FreeBSD Project is managed and operated by the following
|
||||
groups of people:
|
||||
|
||||
<sect><heading>The FreeBSD core team<label id="contrib:core"></heading>
|
||||
|
||||
<p>The FreeBSD core team constitutes the project's ``Board of Directors'',
|
||||
responsible for deciding the project's overall goals and direction
|
||||
as well as managing <ref id="contrib:who" name="specific areas"> of
|
||||
the FreeBSD project landscape.
|
||||
|
||||
<p>(in alphabetical order by last name):
|
||||
|
||||
<itemize>
|
||||
<item>&a.asami;
|
||||
<item>&a.jmb;
|
||||
<item>&a.ache;
|
||||
<item>&a.dyson;
|
||||
<item>&a.bde;
|
||||
<item>&a.gibbs;
|
||||
<item>&a.davidg;
|
||||
<item>&a.jkh;
|
||||
<item>&a.phk;
|
||||
<item>&a.rich;
|
||||
<item>&a.gpalmer;
|
||||
<item>&a.jdp;
|
||||
<item>&a.guido;
|
||||
<item>&a.sos;
|
||||
<item>&a.peter;
|
||||
<item>&a.wollman;
|
||||
<item>&a.joerg;
|
||||
</itemize>
|
||||
|
||||
<sect><heading>The FreeBSD Developers<label id="contrib:committers"></heading>
|
||||
|
||||
<p>These are the people who have commit privileges and do the engineering
|
||||
work on the FreeBSD source tree. All core team members and most
|
||||
FreeBSD Documentation project personnel are also developers.
|
||||
|
||||
<itemize>
|
||||
<item>&a.mbarkah;
|
||||
<item>&a.stb;
|
||||
<item>&a.jb;
|
||||
<item>&a.torstenb;
|
||||
<item>&a.danny;
|
||||
<item>&a.charnier;
|
||||
<item>&a.kjc;
|
||||
<item>&a.gclarkii;
|
||||
<item>&a.cracauer;
|
||||
<item>&a.adam;
|
||||
<item>&a.dufault;
|
||||
<item>&a.uhclem;
|
||||
<item>&a.tegge;
|
||||
<item>&a.eivind;
|
||||
<item>&a.sef;
|
||||
<item>&a.julian;
|
||||
<item>&a.se;
|
||||
<item>&a.fenner;
|
||||
<item>&a.jfieber;
|
||||
<item>&a.jfitz;
|
||||
<item>&a.lars;
|
||||
<item>&a.scrappy;
|
||||
<item>&a.tg;
|
||||
<item>&a.graichen;
|
||||
<item>&a.jgreco;
|
||||
<item>&a.rgrimes;
|
||||
<item>&a.jmg;
|
||||
<item>&a.jhay;
|
||||
<item>&a.hsu;
|
||||
<item>&a.ugen;
|
||||
<item>&a.gj;
|
||||
<item>&a.nsj;
|
||||
<item>&a.ljo;
|
||||
<item>&a.darrenr;
|
||||
<item>&a.kato;
|
||||
<item>&a.andreas;
|
||||
<item>&a.erich;
|
||||
<item>&a.imp;
|
||||
<item>&a.smace;
|
||||
<item>&a.mckay;
|
||||
<item>&a.tedm;
|
||||
<item>&a.amurai;
|
||||
<item>&a.markm;
|
||||
<item>&a.max;
|
||||
<item>&a.alex;
|
||||
<item>&a.davidn;
|
||||
<item>&a.obrien;
|
||||
<item>&a.fsmp;
|
||||
<item>&a.smpatel;
|
||||
<item>&a.wpaul;
|
||||
<item>&a.jmacd;
|
||||
<item>&a.steve;
|
||||
<item>&a.mpp;
|
||||
<item>&a.dfr;
|
||||
<item>&a.jraynard;
|
||||
<item>&a.csgr;
|
||||
<item>&a.martin;
|
||||
<item>&a.paul;
|
||||
<item>&a.roberto;
|
||||
<item>&a.chuckr;
|
||||
<item>&a.dima;
|
||||
<item>&a.wosch;
|
||||
<item>&a.ats;
|
||||
<item>&a.msmith;
|
||||
<item>&a.brian;
|
||||
<item>&a.stark;
|
||||
<item>&a.karl;
|
||||
<item>&a.pst;
|
||||
<item>&a.swallace;
|
||||
<item>&a.nate;
|
||||
<item>&a.yokota;
|
||||
<item>&a.jmz;
|
||||
<item>&a.hanai;
|
||||
</itemize>
|
||||
|
||||
<sect><heading>The FreeBSD Documentation Project<label id="contrib:doc">
|
||||
</heading>
|
||||
|
||||
<p>The <url url="../docproj.html" name="FreeBSD Documentation
|
||||
Project"> is responsible for a number of different services, each
|
||||
service being run by an individual and his <em>deputies</em> (if any):
|
||||
|
||||
<p><descrip>
|
||||
<tag/Documentation Project Manager/ &a.jfieber
|
||||
<tag/Webmaster/ &a.mbarkah;<p><em>Deputy:</em> &a.paul
|
||||
<tag/Handbook & FAQ Editor/ &a.pds
|
||||
<tag/Build Engineer/ &a.paul;<p><em>Deputy:</em> &a.dave
|
||||
<tag/Mirror Manager/ &a.ulf;<p><em>Deputy:</em> &a.john
|
||||
<tag/News Editor/ &a.nsj;<p><em>Deputy:</em> &a.john;
|
||||
<tag/Gallery and Commercial Editor/ &a.nsj;<p><em>Deputy:</em> &a.cawimm
|
||||
<tag/Style Police & Art Director/ &a.dave;<p><em>Deputy:</em> &a.opsys
|
||||
<tag/Database Engineer/ &a.mayo;<p><em>Deputy:</em> &a.cracauer
|
||||
<tag/CGI Engineer/ &a.cracauer;<p><em>Deputy:</em> &a.stb
|
||||
<tag/Bottle Washing/ &a.nsj
|
||||
</descrip>
|
||||
|
||||
<sect><heading>Who is responsible for what<label id="contrib:who"></heading>
|
||||
|
||||
<p><descrip>
|
||||
<tag/Principal Architect/ &a.davidg
|
||||
<tag/Documentation Project Manager/ &a.jfieber
|
||||
<tag/Internationalization/ &a.ache
|
||||
<tag/Networking/ &a.wollman
|
||||
<tag/Postmaster/ &a.jmb;
|
||||
<tag/Release Coordinator/ &a.jkh
|
||||
<tag/Public Relations & Corporate Liaison/ &a.jkh
|
||||
<tag/Security Officer/ &a.guido
|
||||
<tag/Source Repository Manager/ &a.peter
|
||||
<tag/Ports Manager/ &a.asami
|
||||
<tag/XFree86 Project, Inc. Liaison/ &a.rich
|
||||
<tag/Usenet Support/ &a.joerg;
|
||||
</descrip>
|
||||
|
||||
|
||||
<chapt><heading>FreeBSD contributor list<label id="contrib"></heading>
|
||||
|
||||
<sect><heading>Derived software contributors</heading>
|
||||
|
||||
<p>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.
|
||||
|
||||
<sect><heading>Additional FreeBSD contributors<label
|
||||
id="contrib:additional"></heading>
|
||||
|
||||
<p>(in alphabetical order by first name):
|
||||
|
||||
<itemize>
|
||||
<item>A JOSEPH KOSHY <koshy@india.hp.com>
|
||||
<item>ABURAYA Ryushirou <pcs51674@asciinet.or.jp>
|
||||
<item>Adam Glass <glass@postgres.berkeley.edu>
|
||||
<item>Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu>
|
||||
<item>Akito Fujita <fujita@zoo.ncl.omron.co.jp>
|
||||
<item>Alain Kalker <A.C.P.M.Kalker@student.utwente.nl>
|
||||
<item>Alan Cox <alc@cs.rice.edu>
|
||||
<item>Andreas Kohout <shanee@rabbit.augusta.de>
|
||||
<item>Andreas Lohr <andreas@marvin.RoBIN.de>
|
||||
<item>Andrew Gordon <andrew.gordon@net-tel.co.uk>
|
||||
<item>Andrew Herbert <andrew@werple.apana.org.au>
|
||||
<item>Andrew McRae <amcrae@cisco.com>
|
||||
<item>Andrew Moore <alm@FreeBSD.org>
|
||||
<item>Andrew Stevenson <andrew@ugh.net.au>
|
||||
<item>Andrew V. Stesin <stesin@elvisti.kiev.ua>
|
||||
<item>Andrey Zakhvatov <andy@cgu.chel.su>
|
||||
<item>Andy Whitcroft <andy@sarc.city.ac.uk>
|
||||
<item>Anthony Yee-Hang Chan <yeehang@netcom.com>
|
||||
<item>Brent J. Nordquist <bjn@visi.com>
|
||||
<item>Bernd Rosauer <br@schiele-ct.de>
|
||||
<item>Bill Kish <kish@osf.org>
|
||||
<item>&a.wlloyd
|
||||
<item>Bob Wilcox <bob@obiwan.uucp>
|
||||
<item>Boyd Faulkner <faulkner@mpd.tandem.com>
|
||||
<item>Brent J. Nordquist <bjn@visi.com>
|
||||
<item>Brian Clapper <bmc@willscreek.com>
|
||||
<item>Brian Handy <handy@lambic.space.lockheed.com>
|
||||
<item>Brian Tao <taob@risc.org>
|
||||
<item>Carey Jones <mcj@acquiesce.org>
|
||||
<item>Charles Hannum <mycroft@ai.mit.edu>
|
||||
<item>Charles Mott <cmott@srv.net>
|
||||
<item>Chet Ramey <chet@odin.INS.CWRU.Edu>
|
||||
<item>Chris Dabrowski < chris@vader.org>
|
||||
<item>Chris G. Demetriou <cgd@postgres.berkeley.edu>
|
||||
<item>Chris Stenton <jacs@gnome.co.uk>
|
||||
<item>Chris Timmons <skynyrd@opus.cts.cwu.edu>
|
||||
<item>Chris Torek <torek@ee.lbl.gov>
|
||||
<item>Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at>
|
||||
<item>Christian Haury <Christian.Haury@sagem.fr>
|
||||
<item>Christoph Robitschko <chmr@edvz.tu-graz.ac.at>
|
||||
<item>Choi Jun Ho <junker@jazz.snu.ac.kr>
|
||||
<item>Chuck Hein <chein@cisco.com>
|
||||
<item>Conrad Sabatier <conrads@neosoft.com>
|
||||
<item>Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de>
|
||||
<item>Craig Struble <cstruble@vt.edu>
|
||||
<item>Cristian Ferretti <cfs@riemann.mat.puc.cl>
|
||||
<item>Curt Mayer <curt@toad.com>
|
||||
<item>Dan Cross <tenser@spitfire.ecsel.psu.edu>
|
||||
<item>Daniel Baker <dbaker@crash.ops.neosoft.com>
|
||||
<item>Daniel M. Eischen <deischen@iworks.InterWorks.org>
|
||||
<item>Danny J. Zerkel <dzerkel@feephi.phofarm.com>
|
||||
<item>Dave Bodenstab <imdave@synet.net>
|
||||
<item>Dave Burgess <burgess@hrd769.brooks.af.mil>
|
||||
<item>Dave Chapeskie <dchapes@zeus.leitch.com>
|
||||
<item>Dave Edmondson <davided@sco.com>
|
||||
<item>Dave Rivers <rivers@ponds.uucp>
|
||||
<item>David Dawes <dawes@physics.su.OZ.AU>
|
||||
<item>David Leonard <d@scry.dstc.edu.au>
|
||||
<item>Dean Huxley <dean@fsa.ca>
|
||||
<item>Dirk Froemberg <dirk@hal.in-berlin.de>
|
||||
<item>Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
|
||||
<item>Dmitry Kohmanyuk <dk@farm.org>
|
||||
<item>&a.whiteside;
|
||||
<item>Don Yuniskis <dgy@rtd.com>
|
||||
<item>Donald Burr <d_burr@ix.netcom.com>
|
||||
<item>Doug Ambrisko <ambrisko@ambrisko.roble.com>
|
||||
<item>Eric Blood <eblood@cs.unr.edu>
|
||||
<item>Frank Bartels <knarf@camelot.de>
|
||||
<item>Frank Maclachlan <fpm@crash.cts.com>
|
||||
<item>Frank Nobis <fn@trinity.radio-do.de>
|
||||
<item>FURUSAWA Kazuhisa <furusawa@com.cs.osakafu-u.ac.jp>
|
||||
<item>Gary A. Browning <gab10@griffcd.amdahl.com>
|
||||
<item>Greg Ungerer <gerg@stallion.oz.au>
|
||||
<item>Harlan Stenn <Harlan.Stenn@pfcs.com>
|
||||
<item>Havard Eidnes <Havard.Eidnes@runit.sintef.no>
|
||||
<item>Hideaki Ohmon <ohmon@tom.sfc.keio.ac.jp>
|
||||
<item>Hidekazu Kuroki <hidekazu@cs.titech.ac.jp>
|
||||
<item>Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
|
||||
<item>Holger Veit <Holger.Veit@gmd.de>
|
||||
<item>Hung-Chi Chu <hcchu@r350.ee.ntu.edu.tw>
|
||||
<item>Igor Vinokurov <igor@zynaps.ru>
|
||||
<item>Ikuo Nakagawa <ikuo@isl.intec.co.jp>
|
||||
<item>IMAMURA Tomoaki <tomoak-i@is.aist-nara.ac.jp>
|
||||
<item>Ishii Masahiro <?>
|
||||
<item>Itsuro Saito <saito@miv.t.u-tokyo.ac.jp>
|
||||
<item>J. David Lowe <lowe@saturn5.com>
|
||||
<item>J.T. Conklin <jtc@cygnus.com>
|
||||
<item>James Clark <jjc@jclark.com>
|
||||
<item>James da Silva <jds@cs.umd.edu> et al
|
||||
<item>Janusz Kokot <janek@gaja.ipan.lublin.pl>
|
||||
<item>Jason Thorpe <thorpej@nas.nasa.gov>
|
||||
<item>Javier Martin Rueda <jmrueda@diatel.upm.es>
|
||||
<item>Jeffrey Wheat <jeff@cetlink.net>
|
||||
<item>Jian-Da Li <jdli@csie.NCTU.edu.tw>
|
||||
<item>Jim Lowe <james@cs.uwm.edu>
|
||||
<item>Jim Wilson <wilson@moria.cygnus.com>
|
||||
<item>Johann Tonsing <jtonsing@mikom.csir.co.za>
|
||||
<item>Joel Sutton <suttonj@interconnect.com.au>
|
||||
<item>John Capo <jc@irbs.com>
|
||||
<item>John Perry <perry@vishnu.alias.net>
|
||||
<item>Juergen Lock <nox@jelal.hb.north.de>
|
||||
<item>Juha Inkari <inkari@cc.hut.fi>
|
||||
<item>Julian Assange <proff@suburbia.net>
|
||||
<item>Julian Jenkins <kaveman@magna.com.au>
|
||||
<item>Julian Stacey <jhs@freebsd.org>
|
||||
<item>Jun-ichiro Itoh <itojun@csl.sony.co.jp>
|
||||
<item>Justin M. Seger <jseger@scds.ziplink.net>
|
||||
<item>Kazuhiko Kiriyama <kiri@kiri.toba-cmt.ac.jp>
|
||||
<item>Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
|
||||
<item>Keith Bostic <bostic@bostic.com>
|
||||
<item>Keith Moore <?>
|
||||
<item>Kenneth Monville <desmo@bandwidth.org>
|
||||
<item>Kent Vander Velden <graphix@iastate.edu>
|
||||
<item>Kirk McKusick <mckusick@mckusick.com>
|
||||
<item>Kiroh HARADA <kiroh@kh.rim.or.jp>
|
||||
<item>Koichi Sato <copan@ppp.fastnet.or.jp>
|
||||
<item>Kostya Lukin <lukin@okbmei.msk.su>
|
||||
<item>Kurt Olsen <kurto@tiny.mcs.usu.edu>
|
||||
<item>Lars Koeller <Lars_Koeller@odie.physik2.uni-rostock.de>
|
||||
<item>Lucas James <Lucas.James@ldjpc.apana.org.au>
|
||||
<item>Luigi Rizzo <luigi@iet.unipi.it>
|
||||
<item>Makoto Matsushita <matusita@ics.es.osaka-u.ac.jp>
|
||||
<item>Manu Iyengar <iyengar@grunthos.pscwa.psca.com>
|
||||
<item>Marc Frajola <marc@dev.com>
|
||||
<item>Marc Ramirez <mrami@mramirez.sy.yale.edu>
|
||||
<item>Marc Slemko <marcs@znep.com>
|
||||
<item>Marc van Kempen <wmbfmk@urc.tue.nl>
|
||||
<item>Mark Huizer <xaa@stack.nl>
|
||||
<item>Mark J. Taylor <mtaylor@cybernet.com>
|
||||
<item>Mark Tinguely <tinguely@plains.nodak.edu>
|
||||
<tinguely@hookie.cs.ndsu.NoDak.edu>
|
||||
<item>Martin Birgmeier
|
||||
<item>Masachika ISHIZUKA <ishizuka@isis.min.ntt.jp>
|
||||
<item>Mats Lofkvist <mal@algonet.se>
|
||||
<item>Matt Bartley <mbartley@lear35.cytex.com>
|
||||
<item>Matt Thomas <thomas@lkg.dec.com>
|
||||
<item>Matt White <mwhite+@CMU.EDU>
|
||||
<item>Matthew Hunt <mph@pobox.com>
|
||||
<item>Matthew N. Dodd <winter@jurai.net>
|
||||
<item>Matthew Stein <matt@bdd.net>
|
||||
<item>Michael Butschky <butsch@computi.erols.com>
|
||||
<item>Michael Elbel <me@FreeBSD.ORG>
|
||||
<item>Michael Searle <searle@longacre.demon.co.uk>
|
||||
<item>Miguel Angel Sagreras <msagre@cactus.fi.uba.ar>
|
||||
<item>Mikael Hybsch <micke@dynas.se>
|
||||
<item>Mikhail Teterin <mi@aldan.ziplink.net>
|
||||
<item>Mike McGaughey <mmcg@cs.monash.edu.au>
|
||||
<item>Mike Peck <mike@binghamton.edu>
|
||||
<item>MITA Yoshio <mita@jp.FreeBSD.ORG>
|
||||
<item>MOROHOSHI Akihiko <moro@race.u-tokyo.ac.jp>
|
||||
<item>Naoki Hamada <nao@tom-yam.or.jp>
|
||||
<item>Narvi <narvi@haldjas.folklore.ee>
|
||||
<item>NIIMI Satoshi <sa2c@and.or.jp>
|
||||
<item>Nick Sayer <nsayer@quack.kfu.com>
|
||||
<item>Nisha Talagala <nisha@cs.berkeley.edu>
|
||||
<item>Nobuhiro Yasutomi <nobu@psrc.isac.co.jp>
|
||||
<item>Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp>
|
||||
<item>Noritaka Ishizumi <graphite@jp.FreeBSD.ORG>
|
||||
<item>Oliver Laumann <net@informatik.uni-bremen.de>
|
||||
<item>Oliver Oberdorf <oly@world.std.com>
|
||||
<item>Paul Fox <pgf@foxharp.boston.ma.us>
|
||||
<item>Paul Kranenburg <pk@cs.few.eur.nl>
|
||||
<item>Paul Mackerras <paulus@cs.anu.edu.au>
|
||||
<item>Paulo Menezes <paulo@isr.uc.pt>
|
||||
<item>Pedro Giffuni <pgiffuni@fps.biblos.unal.edu.co>
|
||||
<item>Pedro A M Vazquez <vazquez@IQM.Unicamp.BR>
|
||||
<item>Peter Stubbs <PETERS@staidan.qld.edu.au>
|
||||
<item>R. Kym Horsell <?>
|
||||
<item>Ralf S. Engelschall <rse@engelschall.com>
|
||||
<item>Randall Hopper <rhh@stealth.ct.picker.com>
|
||||
<item>Richard Stallman <rms@gnu.ai.mit.edu>
|
||||
<item>Richard Wiwatowski <rjwiwat@adelaide.on.neti>
|
||||
<item>Rob Mallory <rmallory@csusb.edu>
|
||||
<item>Rob Shady <rls@id.net>
|
||||
<item>Rob Snow <rsnow@txdirect.net>
|
||||
<item>Robert Sanders <rsanders@mindspring.com>
|
||||
<item>Robert Withrow <witr@rwwa.com>
|
||||
<item>Ronald Kuehn <kuehn@rz.tu-clausthal.de>
|
||||
<item>Samuel Lam <skl@ScalableNetwork.com>
|
||||
<item>Sander Vesik <sander@haldjas.folklore.ee>
|
||||
<item>Sandro Sigala <ssigala@globalnet.it>
|
||||
<item>Sascha Blank <blank@fox.uni-trier.de>
|
||||
<item>Sascha Wildner <swildner@channelz.GUN.de>
|
||||
<item>Scott Blachowicz <scott@sabami.seaslug.org>
|
||||
<item>Serge V. Vakulenko <vak@zebub.msk.su>
|
||||
<item>Simon Marlow <simonm@dcs.gla.ac.uk>
|
||||
<item>Slaven Rezic (Tomic) <eserte@cs.tu-berlin.de>
|
||||
<item>Soren Dayton <csdayton@midway.uchicago.edu>
|
||||
<item>Stefan Moeding <moeding@bn.DeTeMobil.de>
|
||||
<item>Steve Gerakines <steve2@genesis.tiac.net>
|
||||
<item>Suzuki Yoshiaki <zensyo@ann.tama.kawasaki.jp>
|
||||
<item>Tadashi Kumano <kumano@strl.nhk.or.jp>
|
||||
<item>Taguchi Takeshi <taguchi@tohoku.iij.ad.jp>
|
||||
<item>Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp>
|
||||
<item>Terry Lambert <terry@lambert.org>
|
||||
<item>Terry Lee <terry@uivlsi.csl.uiuc.edu>
|
||||
<item>Theo Deraadt <deraadt@fsa.ca>
|
||||
<item>Thomas König <Thomas.Koenig@ciw.uni-karlsruhe.de>
|
||||
<item>Tim Kientzle <kientzle@netcom.com>
|
||||
<item>Tim Vanderhoek <ac199@freenet.hamilton.on.ca>
|
||||
<item>Tom Samplonius <tom@misery.sdf.com>
|
||||
<item>Torbjorn Granlund <tege@matematik.su.se>
|
||||
<item>Toshihiro Kanda <candy@fct.kgc.co.jp>
|
||||
<item>Vanill Ice <vanilla@Minje.Com.TW>
|
||||
<item>Ville Eerola <ve@sci.fi>
|
||||
<item>Werner Griessl <werner@btp1da.phy.uni-bayreuth.de>
|
||||
<item>Wes Santee <wsantee@wsantee.oz.net>
|
||||
<item>Wolfgang Stanglmeier <wolf@kintaro.cologne.de>
|
||||
<item>Yoshiro Mihira <sanpei@yy.cs.keio.ac.jp>
|
||||
<item>Yukihiro Nakai <nakai@mlab.t.u-tokyo.ac.jp>
|
||||
<item>Yuval Yarom <yval@cs.huji.ac.il>
|
||||
<item>Yves Fonk <yves@cpcoup5.tn.tudelft.nl>
|
||||
</itemize>
|
||||
|
||||
<sect><heading>386BSD Patch kit patch contributors</heading>
|
||||
|
||||
<p>(in alphabetical order by first name):
|
||||
|
||||
<itemize>
|
||||
<item>Adam Glass <glass@postgres.berkeley.edu>
|
||||
<item>Adrian Hall <adrian@ibmpcug.co.uk>
|
||||
<item>Andrey A. Chernov <ache@astral.msk.su>
|
||||
<item>Andrew Herbert <andrew@werple.apana.org.au>
|
||||
<item>Andrew Moore <alm@netcom.com>
|
||||
<item>Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com>
|
||||
<item>Arne Henrik Juul <arnej@Lise.Unit.NO>
|
||||
<item>Bakul Shah <bvs@bitblocks.com>
|
||||
<item>Barry Lustig <barry@ictv.com>
|
||||
<item>Bob Wilcox <bob@obiwan.uucp>
|
||||
<item>Branko Lankester
|
||||
<item>Brett Lymn <blymn@mulga.awadi.com.AU>
|
||||
<item>Charles Hannum <mycroft@ai.mit.edu>
|
||||
<item>Chris G. Demetriou <cgd@postgres.berkeley.edu>
|
||||
<item>Chris Torek <torek@ee.lbl.gov>
|
||||
<item>Christoph Robitschko <chmr@edvz.tu-graz.ac.at>
|
||||
<item>Daniel Poirot <poirot@aio.jsc.nasa.gov>
|
||||
<item>Dave Burgess <burgess@hrd769.brooks.af.mil>
|
||||
<item>Dave Rivers <rivers@ponds.uucp>
|
||||
<item>David Dawes <dawes@physics.su.OZ.AU>
|
||||
<item>David Greenman <davidg@Root.COM>
|
||||
<item>Eric J. Haug <ejh@slustl.slu.edu>
|
||||
<item>Felix Gaehtgens <felix@escape.vsse.in-berlin.de>
|
||||
<item>Frank Maclachlan <fpm@crash.cts.com>
|
||||
<item>Gary A. Browning <gab10@griffcd.amdahl.com>
|
||||
<item>Geoff Rehmet <csgr@alpha.ru.ac.za>
|
||||
<item>Goran Hammarback <goran@astro.uu.se>
|
||||
<item>Guido van Rooij <guido@gvr.win.tue.nl>
|
||||
<item>Guy Harris <guy@auspex.com>
|
||||
<item>Havard Eidnes <Havard.Eidnes@runit.sintef.no>
|
||||
<item>Herb Peyerl <hpeyerl@novatel.cuc.ab.ca
|
||||
<item>Holger Veit <Holger.Veit@gmd.de>
|
||||
<item>Ishii Masahiro, R. Kym Horsell
|
||||
<item>J.T. Conklin <jtc@cygnus.com>
|
||||
<item>Jagane D Sundar < jagane@netcom.com >
|
||||
<item>James Clark <jjc@jclark.com>
|
||||
<item>James Jegers <jimj@miller.cs.uwm.edu>
|
||||
<item>James W. Dolter
|
||||
<item>James da Silva <jds@cs.umd.edu> et al
|
||||
<item>Jay Fenlason <hack@datacube.com>
|
||||
<item>Jim Wilson <wilson@moria.cygnus.com>
|
||||
<item>Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de>
|
||||
<item>Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>
|
||||
<item>John Dyson - <formerly dyson@ref.tfs.com>
|
||||
<item>John Polstra <jdp@polstra.com>
|
||||
<item>John Woods <jfw@eddie.mit.edu>
|
||||
<item>Jordan K. Hubbard <jkh@whisker.hubbard.ie>
|
||||
<item>Julian Elischer <julian@dialix.oz.au>
|
||||
<item>Julian Stacey <jhs@freebsd.org>
|
||||
<item>Karl Lehenbauer <karl@NeoSoft.com>
|
||||
<karl@one.neosoft.com>
|
||||
<item>Keith Bostic <bostic@toe.CS.Berkeley.EDU>
|
||||
<item>Ken Hughes
|
||||
<item>Kent Talarico <kent@shipwreck.tsoft.net>
|
||||
<item>Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu>
|
||||
<kml@mosquito.cis.ufl.edu>
|
||||
<item>Marc Frajola <marc@dev.com>
|
||||
<item>Mark Tinguely <tinguely@plains.nodak.edu>
|
||||
<tinguely@hookie.cs.ndsu.NoDak.edu>
|
||||
<item>Martin Renters <martin@tdc.on.ca>
|
||||
<item>Michael Clay <mclay@weareb.org>
|
||||
<item>Michael Galassi <nerd@percival.rain.com>
|
||||
<item>Mike Durkin <mdurkin@tsoft.sf-bay.org>
|
||||
<item>Naoki Hamada <nao@tom-yam.or.jp>
|
||||
<item>Nate Williams <nate@bsd.coe.montana.edu>
|
||||
<item>Nick Handel <nhandel@NeoSoft.com>
|
||||
<nick@madhouse.neosoft.com>
|
||||
<item>Pace Willisson <pace@blitz.com>
|
||||
<item>Paul Kranenburg <pk@cs.few.eur.nl>
|
||||
<item>Paul Mackerras <paulus@cs.anu.edu.au>
|
||||
<item>Paul Popelka <paulp@uts.amdahl.com>
|
||||
<item>Peter da Silva <peter@NeoSoft.com>
|
||||
<item>Phil Sutherland <philsuth@mycroft.dialix.oz.au>
|
||||
<item>Poul-Henning Kamp<phk@FreeBSD.ORG>
|
||||
<item>Ralf Friedl <friedl@informatik.uni-kl.de>
|
||||
<item>Rick Macklem <root@snowhite.cis.uoguelph.ca>
|
||||
<item>Robert D. Thrush <rd@phoenix.aii.com>
|
||||
<item>Rodney W. Grimes <rgrimes@cdrom.com>
|
||||
<item>Sascha Wildner <swildner@channelz.GUN.de>
|
||||
<item>Scott Burris <scott@pita.cns.ucla.edu>
|
||||
<item>Scott Reynolds <scott@clmqt.marquette.mi.us>
|
||||
<item>Sean Eric Fagan <sef@kithrup.com>
|
||||
<item>Simon J Gerraty <sjg@melb.bull.oz.au>
|
||||
<sjg@zen.void.oz.au>
|
||||
<item>Stephen McKay <syssgm@devetir.qld.gov.au>
|
||||
<item>Terry Lambert <terry@icarus.weber.edu>
|
||||
<item>Terry Lee <terry@uivlsi.csl.uiuc.edu>
|
||||
<item>Tor Egge <Tor.Egge@idi.ntnu.no>
|
||||
<item>Warren Toomey <wkt@csadfa.cs.adfa.oz.au>
|
||||
<item>Wiljo Heinen <wiljo@freeside.ki.open.de>
|
||||
<item>William Jolitz <withheld>
|
||||
<item>Wolfgang Solfrank <ws@tools.de>
|
||||
<item>Wolfgang Stanglmeier <wolf@dentaro.GUN.de>
|
||||
<item>Yuval Yarom <yval@cs.huji.ac.il>
|
||||
</itemize>
|
||||
@ -1,78 +0,0 @@
|
||||
<!-- $Id: crypt.sgml,v 1.3 1997/02/22 12:58:13 peter Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>DES, MD5, and Crypt<label id="crypt"></heading>
|
||||
|
||||
<p><em>Contributed by &a.wollman;<newline>24 September 1995.</em>
|
||||
|
||||
<p>In order to protect the security of passwords on UN*X systems from
|
||||
being easily exposed, passwords have traditionally been scrambled in
|
||||
some way. Starting with Bell Labs' Seventh Edition Unix, passwords
|
||||
were encrypted using what the security people call a ``one-way hash
|
||||
function''. That is to say, the password is transformed in such a way
|
||||
that the original password cannot be regained except by brute-force
|
||||
searching the space of possible passwords. Unfortunately, the only
|
||||
secure method that was available to the AT&T researchers at the
|
||||
time was based on DES, the Data Encryption Standard. This causes only
|
||||
minimal difficulty for commercial vendors, but is a serious problem
|
||||
for an operating system like FreeBSD where all the source code is
|
||||
freely available, because national governments in many places like to
|
||||
place restrictions on cross-border transport of DES and other
|
||||
encryption software.
|
||||
|
||||
<p>So, the FreeBSD team was faced with a dilemma: how could we provide
|
||||
compatibility with all those UNIX systems out there while still not
|
||||
running afoul of the law? We decided to take a dual-track approach:
|
||||
we would make distributions which contained only a non-regulated
|
||||
password scrambler, and then provide as a separate add-on library the
|
||||
DES-based password hash. The password-scrambling function was moved
|
||||
out of the C library to a separate library, called `<tt>libcrypt</tt>'
|
||||
because the name of the C function to implement it is
|
||||
`<tt>crypt</tt>'. In FreeBSD 1.x and some pre-release 2.0 snapshots,
|
||||
the non-regulated scrambler uses an insecure function written by Nate
|
||||
Williams; in subsequent releases this was replaced by a mechanism
|
||||
using the RSA Data Security, Inc., MD5 one-way hash function. Because
|
||||
neither of these functions involve encryption, they are believed to be
|
||||
exportable from the US and importable into many other countries.
|
||||
|
||||
<p>Meanwhile, work was also underway on the DES-based password hash
|
||||
function. First, a version of the `<tt>crypt</tt>' function which was
|
||||
written outside the US was imported, thus synchronizing the US and
|
||||
non-US code. Then, the library was modified and split into two; the
|
||||
DES `<tt>libcrypt</tt>' contains only the code involved in performing
|
||||
the one-way password hash, and a separate `<tt>libcipher</tt>' was
|
||||
created with the entry points to actually perform encryption. The
|
||||
code was partitioned in this way to make it easier to get an export
|
||||
license for the compiled library.
|
||||
|
||||
<sect1><heading>Recognizing your `<tt>crypt</tt>' mechanism</heading>
|
||||
|
||||
<p>It is fairly easy to recognize whether a particular password
|
||||
string was created using the DES- or MD5-based hash function.
|
||||
MD5 password strings always begin with the characters
|
||||
`<tt>$1$</tt>'. DES password strings do not have
|
||||
any particular identifying characteristics, but they are shorter
|
||||
than MD5 passwords, and are coded in a 64-character alphabet
|
||||
which does not include the `<tt>$</tt>' character, so a
|
||||
relatively short string which doesn't begin with a dollar sign is
|
||||
very likely a DES password.
|
||||
|
||||
<p>Determining which library is being used on your system is fairly
|
||||
easy for most programs, except for those like `<tt>init</tt>' which
|
||||
are statically linked. (For those programs, the only way is to try
|
||||
them on a known password and see if it works.) Programs which use
|
||||
`<tt>crypt</tt>' are linked against `<tt>libcrypt</tt>', which for
|
||||
each type of library is a symbolic link to the appropriate
|
||||
implementation. For example, on a system using the DES versions:
|
||||
|
||||
<tscreen><verb>
|
||||
$ cd /usr/lib
|
||||
$ ls -l /usr/lib/libcrypt*
|
||||
lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a
|
||||
lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0
|
||||
lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.a
|
||||
</verb></tscreen>
|
||||
|
||||
On a system using the MD5-based libraries, the same links will be
|
||||
present, but the target will be `<tt>libscrypt</tt>' rather than
|
||||
`<tt>libdescrypt</tt>'.
|
||||
@ -1,201 +0,0 @@
|
||||
<!--
|
||||
# This is the sgml version of the ctm.FAQ file.
|
||||
#
|
||||
# Converted by Ollivier Robert <roberto@FreeBSD.ORG>
|
||||
#
|
||||
# $Id: ctm.sgml,v 1.16 1997/04/19 10:40:45 gpalmer Exp $
|
||||
#
|
||||
# ----------------------------------------------------------------------------
|
||||
# "THE BEER-WARE LICENSE" (Revision 42):
|
||||
# <phk@login.dknet.dk> wrote this file. As long as you retain this notice you
|
||||
# can do whatever you want with this stuff. If we meet some day, and you think
|
||||
# this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
|
||||
# ----------------------------------------------------------------------------
|
||||
#
|
||||
-->
|
||||
|
||||
<sect1><heading>CTM<label id="ctm"></heading>
|
||||
|
||||
<p><em>Contributed by &a.phk;. Updated 16-Mar-1995.</em>
|
||||
|
||||
<tt/CTM/ is a method for keeping a remote directory tree in sync with a
|
||||
central one. It has been developed for usage with FreeBSD's source
|
||||
trees, though other people may find it useful for other purposes as
|
||||
time goes by. Little, if any, documentation currently exists at
|
||||
this time on the process of creating deltas, so talk to &a.phk;
|
||||
for more information should you wish to use <tt/CTM/ for other things.
|
||||
|
||||
<sect2><heading>Why should I use <tt/CTM/?</heading>
|
||||
<p><tt/CTM/ will give you a local copy of the ``FreeBSD-current''
|
||||
sources. If you are an active developer on FreeBSD, but have lousy
|
||||
or non-existent TCP/IP connectivity, <tt/CTM/ was made for you.
|
||||
You will need to transfer up to four deltas per day (or you can
|
||||
have them arrive in email automatically), the sizes for which are
|
||||
always kept as small as possible. This is typically less than 5K,
|
||||
with the occasional (one in ten) being 10-50K and every now and
|
||||
then a biggie of 100K+ or more coming around.
|
||||
|
||||
You will also need to make yourself aware of the various caveats in
|
||||
running ``current'' sources, and for this it is recommended that
|
||||
you read <ref id="current" name="Staying current with FreeBSD">.
|
||||
|
||||
<sect2><heading>What do I need to use <tt/CTM/?</heading>
|
||||
|
||||
<p>You will need two things: The ``<tt/CTM/'' program and the initial
|
||||
deltas to feed it (to get up to ``current'' levels).
|
||||
|
||||
The <tt/CTM/ program has been part of FreeBSD ever since version 2.0
|
||||
was released, and lives in <tt>/usr/src/usr.sbin/<tt/CTM/</tt> 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 <tt/CTM/ sources directly from:
|
||||
|
||||
<url
|
||||
url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm">
|
||||
|
||||
The ``deltas'' you feed <tt/CTM/ can be had two ways, FTP or e-mail.
|
||||
If you have general FTP access to the Internet then the following
|
||||
FTP sites support access to <tt/CTM/:
|
||||
|
||||
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/CTM">
|
||||
|
||||
or see section <ref id="mirrors-ctm" name="mirrors">.
|
||||
|
||||
FTP the relevant directory and fetch the <tt/README/ file,
|
||||
starting from there.
|
||||
|
||||
If you only have access to electronic mail or are otherwise blocked
|
||||
from using FTP then you may wish to get your deltas via email:
|
||||
|
||||
Send email to &a.majordomo to subscribe to
|
||||
the list ``ctm-src-cur''. (If you do not know how to subscribe
|
||||
yourself using majordomo, send a message first containing the
|
||||
word ``help'' - it will send you back usage instructions.)
|
||||
|
||||
When you begin receiving your <tt/CTM/ updates in the mail, you may
|
||||
use the <tt/ctm_rmail/ program to unpack and apply them. You
|
||||
can actually use the <tt/ctm_rmail/ program directly from a entry
|
||||
in <tt>/etc/aliases</tt> if you want to have the process run in a
|
||||
fully automated fashion. Check the <tt/ctm_rmail/ man page for more
|
||||
details.
|
||||
|
||||
<bf/NOTE/: No matter what method you use to get the <tt/CTM/
|
||||
deltas, you should subscribe to the <tt/ctm-announce@FreeBSD.ORG/
|
||||
mailing list. In the future, this will be the only place where
|
||||
announcements concerning the operations of the <tt/CTM/ system will be
|
||||
posted. Send an email to &a.majordomo with a single
|
||||
line of ``<tt/subscribe ctm-announce/'' to get added to the list.
|
||||
|
||||
<sect2><heading>Starting off with <tt/CTM/ for the first time</heading>
|
||||
<p>Before you can start using <tt/CTM/ deltas, you will need to get a
|
||||
special ``base'' delta that provides the starting point for all
|
||||
deltas produced subsequently to it.
|
||||
|
||||
You can recognize a base delta by the ``<tt/A/'' appended to the
|
||||
number (<tt/src-cur.0341A.gz/ for instance). As a rule a base
|
||||
delta is produced every 100 deltas, the next one will be
|
||||
<tt/src-cur.0400A.gz/. By the way, they are large! 25 to 30
|
||||
Megabytes of <tt/gzip/'ed data is common for a base delta.
|
||||
|
||||
If you do have the 2.0-RELEASE <tt/srcdist/, you can instead
|
||||
retrieve the <tt/src-cur.0372R20.gz/ file, it is only 4Mb and it
|
||||
will take you to current from the 2.0-RELEASE sources.
|
||||
|
||||
Once you've picked a base delta to start from, you will also need
|
||||
all deltas with higher numbers following it.
|
||||
|
||||
<sect2><heading>Using <tt/CTM/ in your daily life</heading>
|
||||
<p>To apply the deltas, simply say
|
||||
<verb>
|
||||
cd /where/ever/you/want/the/stuff
|
||||
ctm -v -v /where/you/store/your/deltas/src-cur.*
|
||||
</verb>
|
||||
<tt/CTM/ understands deltas which have been put through <tt/gzip/,
|
||||
so you do not need to gunzip them first, this saves disk space.
|
||||
|
||||
Unless it feels very secure about the entire process, <tt/CTM/ will
|
||||
not touch your tree. To verify a delta you can also use the
|
||||
``<tt/-c/'' flag and <tt/CTM/ will not actually touch your tree; it will
|
||||
merely verify the integrity of the delta and see if it would apply
|
||||
cleanly to your current tree.
|
||||
|
||||
There are other options to <tt/CTM/ as well, look in the sources
|
||||
for more details.
|
||||
|
||||
I would also be very happy if somebody could help with the ``user
|
||||
interface'' portions, as I have realized that I cannot make up my
|
||||
mind on what options should do what, how and when...
|
||||
|
||||
That's really all there is to it. Every time you get a new delta,
|
||||
just run it through <tt/CTM/ to keep your sources up to date.
|
||||
|
||||
Do not remove the deltas if they are hard to download again. You
|
||||
just might want to keep them around in case something bad happens.
|
||||
Even if you only have floppy disks, consider using <tt/fdwrite/ to
|
||||
make a copy.
|
||||
|
||||
|
||||
<sect2><heading>Future plans for <tt/CTM/</heading>
|
||||
<p>
|
||||
Tons of them:
|
||||
<itemize>
|
||||
<item>
|
||||
Make local modifications to the tree possible. One way to do
|
||||
it could be this:<p> When <tt/CTM/ wants to edit the file
|
||||
``<tt>foo/bar.c</tt>'', it would first check for the existence
|
||||
of <tt>foo/bar.c#CTM</tt> If this file exists, the delta is
|
||||
applied to it instead. This way the <tt>foo/bar.c</tt> file
|
||||
can be edited to suit local needs.
|
||||
<item>
|
||||
Make a ``restore file(s)'' option to <tt/CTM/, something like:
|
||||
<verb>
|
||||
ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.*
|
||||
</verb>
|
||||
would restore <tt/wd.c/ to the current status from the files.
|
||||
<item>
|
||||
Clean up the options to <tt/CTM/, they became confusing and
|
||||
counter intuitive.
|
||||
</itemize>
|
||||
|
||||
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...
|
||||
|
||||
<sect2><heading>Miscellaneous stuff</heading>
|
||||
<p>
|
||||
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 ``<tt/sec-cur/''
|
||||
sequence too.
|
||||
|
||||
If you are a frequent or valuable contributor to FreeBSD, I will be
|
||||
willing to arrange special services, one option is delivery via
|
||||
<tt/ftp/ or <tt/rcp/ to a machine closer to you. You need to have
|
||||
earned this, since it takes time to do, but I will be all the more
|
||||
happy to do it for you then.
|
||||
|
||||
There is a sequence of deltas for the <tt/ports/ collection too,
|
||||
but interest has not been all that high yet. Tell me if you want
|
||||
an email list for that too and we will consider setting it up.
|
||||
|
||||
If you have commit privileges or are similarly authorized by the
|
||||
FreeBSD core team, you can also get access to the CVS repository
|
||||
tree by the same means. Contact &a.phk;
|
||||
for details.
|
||||
|
||||
|
||||
<sect2><heading>Thanks!</heading>
|
||||
<p>
|
||||
<descrip>
|
||||
<tag/&a.bde;/
|
||||
for his pointed pen and invaluable comments.
|
||||
<tag/&a.sos;/
|
||||
for patience.
|
||||
<tag/Stephen McKay/
|
||||
wrote <tt/ctm_[rs]mail/, much appreciated.
|
||||
<tag/&a.jkh;/
|
||||
for being so stubborn that I had to make it better.
|
||||
<tag/All the users/
|
||||
I hope you like it...
|
||||
</descrip>
|
||||
|
||||
@ -1,162 +0,0 @@
|
||||
<!-- $Id: current.sgml,v 1.20 1997/05/02 14:15:34 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
|
||||
<sect><heading>Staying current with FreeBSD<label id="current"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;.</em>
|
||||
|
||||
<!--
|
||||
|
||||
THE FREEBSD CURRENT POLICY
|
||||
|
||||
Last updated: $Date: 1997/05/02 14:15:34 $
|
||||
|
||||
This document attempts to explain the rationale behind
|
||||
FreeBSD-current, what you should expect should you decide to run it,
|
||||
and states some prerequisites for making sure the process goes as
|
||||
smoothly as possible.
|
||||
-->
|
||||
|
||||
<sect1><heading>What is FreeBSD-current?</heading>
|
||||
|
||||
<p>FreeBSD-current is, quite literally, nothing more than a daily
|
||||
snapshot of the working sources for FreeBSD. These include work in
|
||||
progress, experimental changes and transitional mechanisms that may or
|
||||
may not be present in the next official release of the software.
|
||||
While many of us compile almost daily from FreeBSD-current sources,
|
||||
there are periods of time when the sources are literally un-compilable.
|
||||
These problems are generally resolved as expeditiously as possible,
|
||||
but whether or not FreeBSD-current sources bring disaster or greatly
|
||||
desired functionality can literally be a matter of which part of any
|
||||
given 24 hour period you grabbed them in!
|
||||
|
||||
Under certain circumstances we will sometimes make binaries for parts
|
||||
of FreeBSD-current available, but only because we are interested in
|
||||
getting something tested, not because we are in the business of
|
||||
providing binary releases of current. If we do not offer, please do not
|
||||
ask! It takes far too much time to do this as a general task.
|
||||
|
||||
<sect1><heading>Who needs FreeBSD-current?</heading>
|
||||
|
||||
<p>FreeBSD-current is made generally available for 3 primary interest groups:
|
||||
<enum>
|
||||
<item> Members of the FreeBSD group who are actively working on some
|
||||
part of the source tree and for whom keeping `current' is an
|
||||
absolute requirement.
|
||||
|
||||
<item> Members of the FreeBSD group who are active testers,
|
||||
willing to spend time working through problems in order to
|
||||
ensure that FreeBSD-current remains as sane as possible. These
|
||||
are also people who wish to make topical suggestions on changes
|
||||
and the general direction of FreeBSD.
|
||||
|
||||
<item> Peripheral members of the FreeBSD (or some other) group who merely
|
||||
wish to keep an eye on things and use the current sources for
|
||||
reference purposes (e.g. for <em>reading</em>, not running). These
|
||||
people also make the occasional comment or contribute code.
|
||||
</enum>
|
||||
|
||||
<sect1><heading>What is FreeBSD-current <em>NOT</em>?</heading>
|
||||
|
||||
<p><enum>
|
||||
<item> A fast-track to getting pre-release bits because you heard there is
|
||||
some cool new feature in there and you want to be the first on
|
||||
your block to have it.
|
||||
|
||||
<item> A quick way of getting bug fixes.
|
||||
|
||||
<item> In any way ``officially supported'' by us.
|
||||
|
||||
We do our best to help people genuinely in one of the 3
|
||||
``legitimate'' FreeBSD-current categories, but we simply <em>do not
|
||||
have the time</em> to provide tech support for it.
|
||||
This is not because we are mean and nasty people who do not like
|
||||
helping people out (we would not even be doing FreeBSD if we were),
|
||||
it is literally because we cannot answer 400 messages a day
|
||||
<em>and</em> actually work on FreeBSD! I am sure that, if given
|
||||
the choice between having us answer lots of questions or continuing to
|
||||
improve FreeBSD, most of you would vote for us improving it.
|
||||
</enum>
|
||||
|
||||
<sect1><heading>Using FreeBSD-current</heading>
|
||||
|
||||
<p><enum> <item> Join the &a.current and the &a.cvsall .
|
||||
This is not just a good idea, it is <em>essential</em>.
|
||||
If you are not on the <em>FreeBSD-current</em> mailing list you
|
||||
will not see the comments that people are making about the
|
||||
current state of the system and thus will probably end up stumbling
|
||||
over a lot of problems that others have already found and
|
||||
solved. Even more importantly, you will miss out on
|
||||
potentially critical information (e.g. ``Yo, Everybody!
|
||||
Before you rebuild <tt>/usr/src</tt>, you <em>must</em>
|
||||
rebuild the kernel or your system will crash horribly!").
|
||||
|
||||
The <em>cvs-all</em> mailing list will allow you to see the commit log
|
||||
entry for each change as it is made along with any pertinent
|
||||
information on possible side-effects.
|
||||
|
||||
To join these lists, send mail to &a.majordomo and specify:
|
||||
<verb>
|
||||
subscribe freebsd-current
|
||||
subscribe cvs-all
|
||||
</verb>
|
||||
In the body of your message. Optionally, you can also say `help'
|
||||
and Majordomo will send you full help on how to subscribe and
|
||||
unsubscribe to the various other mailing lists we support.
|
||||
|
||||
<item> Grab the sources from ftp.FreeBSD.ORG. You can do this in
|
||||
three ways:
|
||||
|
||||
<enum>
|
||||
<item> Use the <ref id="ctm" name="CTM"> facility. Unless you
|
||||
have a good TCP/IP connection at a flat rate, this is
|
||||
the way to do it.
|
||||
|
||||
<item> Use the <ref id="cvsup" name="cvsup"> program with
|
||||
<url url="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/standard-supfile" name="this supfile">.
|
||||
This is the second most recommended method, since it allows
|
||||
you to grab the entire collection once and then only what has
|
||||
changed from then on. Many people run cvsup from cron
|
||||
and keep their sources up-to-date automatically.
|
||||
|
||||
<item> Use ftp. The source tree for FreeBSD-current is always
|
||||
"exported" on:
|
||||
<htmlurl url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current"
|
||||
name="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current">
|
||||
We also use `wu-ftpd' which allows compressed/tar'd grabbing
|
||||
of whole trees. e.g. you see:
|
||||
<verb>
|
||||
usr.bin/lex
|
||||
</verb>
|
||||
You can do:
|
||||
<verb>
|
||||
ftp> cd usr.bin
|
||||
ftp> get lex.tar.Z
|
||||
</verb>
|
||||
And it will get the whole directory for you as a compressed
|
||||
tar file.
|
||||
</enum>
|
||||
|
||||
<item> Essentially, if you need rapid on-demand access to the source and
|
||||
communications bandwidth is not a consideration, use cvsup or ftp.
|
||||
Otherwise, use CTM.
|
||||
|
||||
<item> If you are grabbing the sources to run, and not just look at,
|
||||
then grab <em>all</em> of current, not just selected portions. The
|
||||
reason for this is that various parts of the source depend on
|
||||
updates elsewhere, and trying to compile just a subset is almost
|
||||
guaranteed to get you into trouble.
|
||||
|
||||
<item> Before compiling current, read the Makefile in /usr/src
|
||||
carefully. You should at least run a `make world' the first time
|
||||
through as part of the upgrading process.
|
||||
Reading the &a.current will keep you up-to-date on other
|
||||
bootstrapping procedures that sometimes become necessary as we move
|
||||
towards the next release.
|
||||
|
||||
<item> Be active! If you are running FreeBSD-current, we want to know
|
||||
what you have to say about it, especially if you have suggestions
|
||||
for enhancements or bug fixes. Suggestions with accompanying code
|
||||
are received most enthusiastically!
|
||||
</enum>
|
||||
@ -1,574 +0,0 @@
|
||||
<!-- $Id: cvsup.sgml,v 1.18 1997/05/19 17:39:20 jdp Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect1><heading>CVSup<label id="cvsup"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jdp;</em>.
|
||||
|
||||
<sect2><heading>Introduction<label id="cvsup:intro"></heading>
|
||||
|
||||
<p>CVSup is a software package for distributing and updating source
|
||||
trees from a master CVS repository on a remote server host. The
|
||||
FreeBSD sources are maintained in a CVS repository on a central
|
||||
development machine in California. With CVSup, FreeBSD users can
|
||||
easily keep their own source trees up to date.
|
||||
|
||||
<p>CVSup uses the so-called "pull" model of updating. Under the pull
|
||||
model, each client asks the server for updates, if and when they are
|
||||
wanted. The server waits passively for update requests from its
|
||||
clients. Thus all updates are instigated by the client. The server
|
||||
never sends unsolicited updates. Users must either run the CVSup client
|
||||
manually to get an update, or they must set up a cron job to run it
|
||||
automatically on a regular basis.
|
||||
|
||||
<p>The term "CVSup", capitalized just so, refers to the entire software
|
||||
package. Its main components are the client "cvsup" which runs on each
|
||||
user's machine, and the server "cvsupd" which runs at each of the
|
||||
FreeBSD mirror sites.
|
||||
|
||||
<p>As you read the FreeBSD documentation and mailing lists, you may
|
||||
see references to <ref id="sup">. Sup was the predecessor to CVSup,
|
||||
and it served a similar purpose. CVSup is in used in much the same
|
||||
way as sup and, in fact, uses configuration files which are
|
||||
backward-compatible with sup's. Sup is no longer used in the FreeBSD
|
||||
project, however, because CVSup is both faster and more flexible.
|
||||
|
||||
<sect2><heading>Installation<label id="cvsup:install"></heading>
|
||||
|
||||
<p>The easiest way to install CVSup if you are running FreeBSD 2.2 or
|
||||
later is to use either <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup.tar.gz"
|
||||
name="the port"> from the FreeBSD <ref id="ports" name="ports
|
||||
collection"> or the corresponding <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/net/cvsup-14.1.1.tgz"
|
||||
name="binary package">, depending on whether you prefer to roll your
|
||||
own or not.
|
||||
|
||||
<p>If you are running FreeBSD-2.1.6 or 2.1.7, you unfortunately cannot use the
|
||||
binary package versions due to the fact that it requires a version of
|
||||
the C library that does not yet exist in FreeBSD-2.1.{6,7}. You can easily
|
||||
use <url url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup.tar.gz"
|
||||
name="the port">, however, just as with FreeBSD 2.2. Simply unpack
|
||||
the tar file, cd to the cvsup subdirectory and type "make install"
|
||||
|
||||
<p>Because CVSup is written in <url
|
||||
url="http://www.research.digital.com/SRC/modula-3/html/home.html"
|
||||
name="Modula-3">, both the package and the port require that the
|
||||
Modula-3 runtime libraries be installed. These are available as the
|
||||
<url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/lang/modula-3-lib.tar.gz"
|
||||
name="lang/modula-3-lib"> port and the <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/lang/modula-3-lib-3.6.tgz"
|
||||
name="lang/modula-3-lib-3.6"> package. If you follow the same
|
||||
directions as for cvsup, these libraries will be compiled and/or
|
||||
installed automatically when you install the CVSup port or package.
|
||||
|
||||
<p>The Modula-3 libraries are rather large, and fetching and compiling
|
||||
them is not an instantaneous process. For that reason, a third option
|
||||
is provided. You can get <em>statically linked</em> FreeBSD
|
||||
executables for CVSup from either the USA distribution site:
|
||||
|
||||
<itemize>
|
||||
<item><url url="ftp://hub.freebsd.org/pub/CVSup/cvsup-bin-14.1.1.tar.gz"
|
||||
name="ftp://hub.freebsd.org/pub/CVSup/cvsup-bin-14.1.1.tar.gz">
|
||||
(client).
|
||||
<item><url url="ftp://hub.freebsd.org/pub/CVSup/cvsupd-bin-14.1.1.tar.gz"
|
||||
name="ftp://hub.freebsd.org/pub/CVSup/cvsupd-bin-14.1.1.tar.gz">
|
||||
(server).
|
||||
</itemize>
|
||||
|
||||
or the German mirror:
|
||||
|
||||
<itemize>
|
||||
<item><url url="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup-bin-14.1.1.tar.gz"
|
||||
name="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup-bin-14.1.1.tar.gz">
|
||||
(client).
|
||||
<item><url url="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsupd-bin-14.1.1.tar.gz"
|
||||
name="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsupd-bin-14.1.1.tar.gz">
|
||||
(server).
|
||||
</itemize>
|
||||
|
||||
<p>Most users will need only the client. These executables are entirely
|
||||
self-contained, and they will run on any version of FreeBSD from
|
||||
FreeBSD-2.1.0 to FreeBSD-current.
|
||||
|
||||
<p>In summary, your options for installing CVSup are:
|
||||
|
||||
<itemize>
|
||||
<item>FreeBSD-2.2 or later: static binary, port, or package
|
||||
<item>FreeBSD-2.1.6, 2.1.7: static binary or port
|
||||
<item>FreeBSD-2.1.5 or earlier: static binary
|
||||
</itemize>
|
||||
|
||||
<sect2><heading>Configuration<label id="cvsup:config"></heading>
|
||||
|
||||
<p>CVSup's operation is controlled by a configuration file called the
|
||||
"supfile". Beginning with FreeBSD-2.2, there are some sample supfiles
|
||||
in the directory <url url="file:/usr/share/examples/cvsup"
|
||||
name="/usr/share/examples/cvsup">. These examples are also available
|
||||
from <url url="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/" name="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/"> if you are on a pre-2.2 system.
|
||||
|
||||
<p>The information in a supfile answers the following questions for cvsup:
|
||||
|
||||
<itemize>
|
||||
<item><ref id="cvsup:config:files" name="Which files do you want to receive?">
|
||||
<item><ref id="cvsup:config:vers" name="Which versions of them do you want?">
|
||||
<item><ref id="cvsup:config:where" name="Where do you want to get them from?">
|
||||
<item><ref id="cvsup:config:dest" name="Where do you want to put them on your own machine?">
|
||||
<item><ref id="cvsup:config:status" name="Where do you want to put your status files?">
|
||||
</itemize>
|
||||
|
||||
<p>In the following sections, we will construct a typical supfile by
|
||||
answering each of these questions in turn. First, we describe the
|
||||
overall structure of a supfile.
|
||||
|
||||
<p>A supfile is a text file. Comments begin with "#" and extend to
|
||||
the end of the line. Lines that are blank and lines that contain only
|
||||
comments are ignored.
|
||||
|
||||
<p>Each remaining line describes a set of files that the user wishes
|
||||
to receive. The line begins with the name of a "collection", a
|
||||
logical grouping of files defined by the server. The name of the
|
||||
collection tells the server which files you want. After the
|
||||
collection name come zero or more fields, separated by white space.
|
||||
These fields answer the questions listed above. There are two types
|
||||
of fields: flag fields and value fields. A flag field consists of a
|
||||
keyword standing alone, e.g., "delete" or "compress". A value field
|
||||
also begins with a keyword, but the keyword is followed without
|
||||
intervening white space by "=" and a second word. For example,
|
||||
"release=cvs" is a value field.
|
||||
|
||||
<p>A supfile typically specifies more than one collection to receive.
|
||||
One way to structure a supfile is to specify all of the relevant
|
||||
fields explicitly for each collection. However, that tends to make
|
||||
the supfile lines quite long, and it is inconvenient because most
|
||||
fields are the same for all of the collections in a supfile. CVSup
|
||||
provides a defaulting mechanism to avoid these problems. Lines
|
||||
beginning with the special pseudo-collection name "*default" can be
|
||||
used to set flags and values which will be used as defaults for the
|
||||
subsequent collections in the supfile. A default value can be
|
||||
overridden for an individual collection, by specifying a different
|
||||
value with the collection itself. Defaults can also be changed or
|
||||
augmented in mid-supfile by additional "*default" lines.
|
||||
|
||||
<p>With this background, we will now proceed to construct a supfile
|
||||
for receiving and updating the main source tree of <ref id="current"
|
||||
name="FreeBSD-current">.
|
||||
|
||||
<itemize>
|
||||
<item>Which files do you want to receive?<label id="cvsup:config:files">
|
||||
|
||||
<p>As with sup, the files available via CVSup are organized into named
|
||||
groups called "collections". The collections that are available are
|
||||
described <ref id="cvsup:collec" name="here">.
|
||||
In this example, we wish to receive the
|
||||
entire main source tree for the FreeBSD system. There is a single
|
||||
large collection "src-all" which will give us all of that, except the
|
||||
export-controlled cryptography support. Let us assume for this
|
||||
example that we are in the USA or Canada. Then we can get the
|
||||
cryptography code with one additional collection, "cvs-crypto".
|
||||
As a first step toward constructing our supfile, we
|
||||
simply list these collections, one per line:
|
||||
|
||||
<verb>
|
||||
src-all
|
||||
cvs-crypto
|
||||
</verb>
|
||||
|
||||
<p><item>Which version(s) of them do you want?<label id="cvsup:config:vers">
|
||||
|
||||
<p>With CVSup, you can receive virtually any version of the sources
|
||||
that ever existed. That is possible because the cvsupd server works
|
||||
directly from the CVS repository, which contains all of the versions.
|
||||
You specify which one of them you want using the "tag=" and "date="
|
||||
value fields.
|
||||
|
||||
<p>The "tag=" field names a symbolic tag in the repository. There are
|
||||
two kinds of tags, revision tags and branch tags. A revision tag
|
||||
refers to a specific revision. Its meaning stays the same from day to
|
||||
day. A branch tag, on the other hand, refers to the latest revision
|
||||
on a given line of development, at any given time. Because a branch
|
||||
tag does not refer to a specific revision, it may mean something
|
||||
different tomorrow than it means today.
|
||||
|
||||
<p>Here are the branch tags that users might be interested in:
|
||||
|
||||
<descrip>
|
||||
<tag/tag=./
|
||||
The main line of development, also known as FreeBSD-current.
|
||||
Note: the "." is not punctuation; it is the name of the tag.
|
||||
<tag/tag=RELENG_2_2/
|
||||
The line of development for FreeBSD-2.2.x.
|
||||
<tag/tag=RELENG_2_1_0/
|
||||
The line of development for FreeBSD-2.1.x, also known as
|
||||
FreeBSD-stable.
|
||||
</descrip>
|
||||
|
||||
<p>Here are the revision tags that users might be interested in:
|
||||
|
||||
<descrip>
|
||||
<tag/tag=RELENG_2_2_1_RELEASE/
|
||||
FreeBSD-2.2.1.
|
||||
<tag/tag=RELENG_2_2_0_RELEASE/
|
||||
FreeBSD-2.2.0.
|
||||
<tag/tag=RELENG_2_1_7_RELEASE/
|
||||
FreeBSD-2.1.7.
|
||||
<tag/tag=RELENG_2_1_6_1_RELEASE/
|
||||
FreeBSD-2.1.6.1.
|
||||
<tag/tag=RELENG_2_1_6_RELEASE/
|
||||
FreeBSD-2.1.6.
|
||||
<tag/tag=RELENG_2_1_5_RELEASE/
|
||||
FreeBSD-2.1.5.
|
||||
<tag/tag=RELENG_2_1_0_RELEASE/
|
||||
FreeBSD-2.1.0.
|
||||
</descrip>
|
||||
|
||||
<p>Be very careful to type the tag name exactly as shown. CVSup cannot
|
||||
distinguish between valid and invalid tags. If you misspell the tag,
|
||||
CVSup will behave as though you had specified a valid tag which happens
|
||||
to refer to no files at all. It will delete your existing sources in
|
||||
that case.
|
||||
|
||||
<p>When you specify a branch tag, you normally receive the latest versions
|
||||
of the files on that line of development. If you wish to receive some
|
||||
past version, you can do so by specifying a date with the "date=" value
|
||||
field. The cvsup(1) manual page explains how to do that.
|
||||
|
||||
<p>For our example, we wish to receive FreeBSD-current. We add this line
|
||||
at the beginning of our supfile:
|
||||
|
||||
<verb>
|
||||
*default tag=.
|
||||
</verb>
|
||||
|
||||
<p>There is an important special case that comes into play if you specify
|
||||
neither a "tag=" field nor a "date=" field. In that case, you receive
|
||||
the actual RCS files directly from the server's CVS repository, rather
|
||||
than receiving a particular version. Developers generally prefer this
|
||||
mode of operation. By maintaining a copy of the repository itself on
|
||||
their systems, they gain the ability to browse the revision histories
|
||||
and examine past versions of files. This gain is achieved at a large
|
||||
cost in terms of disk space, however.
|
||||
|
||||
<p><item>Where do you want to get them from?<label id="cvsup:config:where">
|
||||
|
||||
<p>We use the "host=" field to tell cvsup where to obtain its updates.
|
||||
Any of the <ref id="mirrors-cvsup" name="CVSup mirror sites"> will do,
|
||||
though you should try to select one that's near to you.
|
||||
In this example, we'll use the primary FreeBSD distribution site,
|
||||
"cvsup.FreeBSD.org":
|
||||
|
||||
<verb>
|
||||
*default host=cvsup.FreeBSD.org
|
||||
</verb>
|
||||
|
||||
<p>On any particular run of cvsup, you can override this setting on the
|
||||
command line, with "-h hostname".
|
||||
|
||||
<p><item>Where do you want to put them on your own machine?<label id="cvsup:config:dest">
|
||||
|
||||
<p>The "prefix=" field tells cvsup where to put the files it receives.
|
||||
In this example, we will put the source files directly into our main
|
||||
source tree, "/usr/src". The "src" directory is already implicit in the
|
||||
collections we have chosen to receive, so this is the correct
|
||||
specification:
|
||||
|
||||
<verb>
|
||||
*default prefix=/usr
|
||||
</verb>
|
||||
|
||||
<p><item>Where should cvsup maintain its status files?<label id="cvsup:config:status">
|
||||
|
||||
<p>The cvsup client maintains certain status files in what is called
|
||||
the "base" directory. These files help CVSup to work more
|
||||
efficiently, by keeping track of which updates you have already
|
||||
received. We will use the standard base directory,
|
||||
"/usr/local/etc/cvsup":
|
||||
|
||||
<verb>
|
||||
*default base=/usr/local/etc/cvsup
|
||||
</verb>
|
||||
|
||||
<p>This setting is used by default if it is not specified in the
|
||||
supfile, so we actually do not need the above line.
|
||||
|
||||
<p>If your base directory does not already exist, now would be a good
|
||||
time to create it. The cvsup client will refuse to run if the base
|
||||
directory does not exist.
|
||||
|
||||
<p><item>Miscellaneous supfile settings:
|
||||
|
||||
<p>There is one more line of boiler plate that normally needs to be
|
||||
present in the supfile:
|
||||
|
||||
<verb>
|
||||
*default release=cvs delete use-rel-suffix compress
|
||||
</verb>
|
||||
|
||||
<p>"release=cvs" indicates that the server should get its information
|
||||
out of the main FreeBSD CVS repository. This is virtually always the
|
||||
case, but there are other possibilities which are beyond the scope of
|
||||
this discussion.
|
||||
|
||||
<p>"delete" gives CVSup permission to delete files. You should always
|
||||
specify this, so that CVSup can keep your source tree fully up to
|
||||
date. CVSup is careful to delete only those files for which it is
|
||||
responsible. Any extra files you happen to have will be left strictly
|
||||
alone.
|
||||
|
||||
<p>"use-rel-suffix" is ... arcane. If you really want to know about
|
||||
it, see the cvsup(1) manual page. Otherwise, just specify it and
|
||||
do not worry about it.
|
||||
|
||||
<p>"compress" enables the use of gzip-style compression on the
|
||||
communication channel. If your network link is T1 speed or faster,
|
||||
you probably should not use compression. Otherwise, it helps
|
||||
substantially.
|
||||
|
||||
<p><item>Putting it all together:
|
||||
|
||||
<p>Here is the entire supfile for our example:
|
||||
|
||||
<verb>
|
||||
*default tag=.
|
||||
*default host=cvsup.FreeBSD.org
|
||||
*default prefix=/usr
|
||||
*default base=/usr/local/etc/cvsup
|
||||
*default release=cvs delete use-rel-suffix compress
|
||||
src-all
|
||||
cvs-crypto
|
||||
</verb>
|
||||
</itemize>
|
||||
|
||||
<sect2><heading>Running CVSup</heading>
|
||||
|
||||
<p>You are now ready to try an update. The command line for doing this is
|
||||
quite simple:
|
||||
|
||||
<verb>
|
||||
cvsup supfile
|
||||
</verb>
|
||||
|
||||
<p>where "supfile" is of course the name of the supfile you have just created.
|
||||
Assuming you are running under X11, cvsup will display a GUI window with
|
||||
some buttons to do the usual things. Press the "go" button, and watch
|
||||
it run.
|
||||
|
||||
<p>Since you are updating your actual "/usr/src" tree in this example, you
|
||||
will need to run the program as root so that cvsup has the permissions
|
||||
it needs to update your files. Having just created your configuration
|
||||
file, and having never used this program before, that might
|
||||
understandably make you nervous. There is an easy way to do a trial run
|
||||
without touching your precious files. Just create an empty directory
|
||||
somewhere convenient, and name it as an extra argument on the command
|
||||
line:
|
||||
|
||||
<verb>
|
||||
mkdir /var/tmp/dest
|
||||
cvsup supfile /var/tmp/dest
|
||||
</verb>
|
||||
|
||||
<p>The directory you specify will be used as the destination directory
|
||||
for all file updates. CVSup will examine your usual files in
|
||||
"/usr/src", but it will not modify or delete any of them. Any file
|
||||
updates will instead land in "/var/tmp/dest/usr/src". CVSup will also
|
||||
leave its base directory status files untouched when run this way.
|
||||
The new versions of those files will be written into the specified
|
||||
directory. As long as you have read access to "/usr/src", you do not
|
||||
even need to be root to perform this kind of trial run.
|
||||
|
||||
<p>If you are not running X11 or if you just do not like GUIs, you
|
||||
should add a couple of options to the command line when you run cvsup:
|
||||
|
||||
<verb>
|
||||
cvsup -g -L 2 supfile
|
||||
</verb>
|
||||
|
||||
<p>The "-g" tells cvsup not to use its GUI. This is automatic if you are
|
||||
not running X11, but otherwise you have to specify it.
|
||||
|
||||
<p>The "-L 2" tells cvsup to print out the details of all the file updates
|
||||
it is doing. There are three levels of verbosity, from "-L 0" to "-L 2".
|
||||
The default is 0, which means total silence except for error messages.
|
||||
|
||||
<p>There are plenty of other options available. For a brief list of them,
|
||||
type "cvsup -H". For more detailed descriptions, see the manual page.
|
||||
|
||||
<p>Once you are satisfied with the way updates are working, you can arrange
|
||||
for regular runs of cvsup using cron(8). Obviously, you should not let
|
||||
cvsup use its GUI when running it from cron.
|
||||
|
||||
<sect2><heading>CVSup File Collections<label id="cvsup:collec"></heading>
|
||||
|
||||
<p>The file collections available via CVSup are organized
|
||||
hierarchically. There are a few large collections, and they are
|
||||
divided into smaller sub-collections. Receiving a large collection
|
||||
is equivalent to receiving each of its sub-collections.
|
||||
The hierarchical relationships among collections are reflected by
|
||||
the use of indentation in the list below.
|
||||
|
||||
<p> The most commonly used collections are <tt/src-all/,
|
||||
<tt/cvs-crypto/, and <tt/ports-all/. The other collections are used
|
||||
only by small groups of people for specialized purposes, and some mirror
|
||||
sites may not carry all of them.
|
||||
|
||||
<descrip>
|
||||
<tag><tt>cvs-all release=cvs</tt></tag>
|
||||
The main FreeBSD CVS repository, excluding the export-restricted
|
||||
cryptography code.
|
||||
<p>
|
||||
<descrip>
|
||||
<tag><tt>distrib release=cvs</tt></tag>
|
||||
Files related to the distribution and mirroring of FreeBSD.
|
||||
<tag><tt>doc-all release=cvs</tt></tag>
|
||||
Sources for the FreeBSD handbook and other documentation.
|
||||
<tag><tt>ports-all release=cvs</tt></tag>
|
||||
The FreeBSD ports collection.
|
||||
<p>
|
||||
<descrip>
|
||||
<tag><tt>ports-archivers release=cvs</tt></tag>
|
||||
Archiving tools.
|
||||
<tag><tt>ports-astro release=cvs</tt></tag>
|
||||
Astronomical ports.
|
||||
<tag><tt>ports-audio release=cvs</tt></tag>
|
||||
Sound support.
|
||||
<tag><tt>ports-base release=cvs</tt></tag>
|
||||
Miscellaneous files at the top of /usr/ports.
|
||||
<tag><tt>ports-benchmarks release=cvs</tt></tag>
|
||||
Benchmarks.
|
||||
<tag><tt>ports-cad release=cvs</tt></tag>
|
||||
Computer aided design tools.
|
||||
<tag><tt>ports-chinese release=cvs</tt></tag>
|
||||
Chinese language support.
|
||||
<tag><tt>ports-comms release=cvs</tt></tag>
|
||||
Communication software.
|
||||
<tag><tt>ports-converters release=cvs</tt></tag>
|
||||
character code converters.
|
||||
<tag><tt>ports-databases release=cvs</tt></tag>
|
||||
Databases.
|
||||
<tag><tt>ports-devel release=cvs</tt></tag>
|
||||
Development utilities.
|
||||
<tag><tt>ports-editors release=cvs</tt></tag>
|
||||
Editors.
|
||||
<tag><tt>ports-emulators release=cvs</tt></tag>
|
||||
Emulators for other operating systems.
|
||||
<tag><tt>ports-games release=cvs</tt></tag>
|
||||
Games.
|
||||
<tag><tt>ports-graphics release=cvs</tt></tag>
|
||||
Graphics utilities.
|
||||
<tag><tt>ports-japanese release=cvs</tt></tag>
|
||||
Japanese language support.
|
||||
<tag><tt>ports-korean release=cvs</tt></tag>
|
||||
Korean language support.
|
||||
<tag><tt>ports-lang release=cvs</tt></tag>
|
||||
Programming languages.
|
||||
<tag><tt>ports-mail release=cvs</tt></tag>
|
||||
Mail software.
|
||||
<tag><tt>ports-math release=cvs</tt></tag>
|
||||
Numerical computation software.
|
||||
<tag><tt>ports-mbone release=cvs</tt></tag>
|
||||
MBone applications.
|
||||
<tag><tt>ports-misc release=cvs</tt></tag>
|
||||
Miscellaneous utilities.
|
||||
<tag><tt>ports-net release=cvs</tt></tag>
|
||||
Networking software.
|
||||
<tag><tt>ports-news release=cvs</tt></tag>
|
||||
USENET news software.
|
||||
<tag><tt>ports-plan9 release=cvs</tt></tag>
|
||||
Various programs from Plan9.
|
||||
<tag><tt>ports-print release=cvs</tt></tag>
|
||||
Printing software.
|
||||
<tag><tt>ports-russian release=cvs</tt></tag>
|
||||
Russian language support.
|
||||
<tag><tt>ports-security release=cvs</tt></tag>
|
||||
Security utilities.
|
||||
<tag><tt>ports-shells release=cvs</tt></tag>
|
||||
Command line shells.
|
||||
<tag><tt>ports-sysutils release=cvs</tt></tag>
|
||||
System utilities.
|
||||
<tag><tt>ports-textproc release=cvs</tt></tag>
|
||||
text processing utilities (does not include desktop publishing).
|
||||
<tag><tt>ports-vietnamese release=cvs</tt></tag>
|
||||
Vietnamese language support.
|
||||
<tag><tt>ports-www release=cvs</tt></tag>
|
||||
Software related to the World Wide Web.
|
||||
<tag><tt>ports-x11 release=cvs</tt></tag>
|
||||
X11 software.
|
||||
</descrip>
|
||||
<tag><tt>src-all release=cvs</tt></tag>
|
||||
The main FreeBSD sources, excluding the export-restricted cryptography
|
||||
code.
|
||||
<p>
|
||||
<descrip>
|
||||
<tag><tt>src-base release=cvs</tt></tag>
|
||||
Miscellaneous files at the top of <tt>/usr/src</tt>.
|
||||
<tag><tt>src-bin release=cvs</tt></tag>
|
||||
User utilities that may be needed in single-user mode
|
||||
(<tt>/usr/src/bin</tt>).
|
||||
<tag><tt>src-contrib release=cvs</tt></tag>
|
||||
Utilities and libraries from outside the FreeBSD project, used
|
||||
relatively unmodified (<tt>/usr/src/contrib</tt>).
|
||||
<tag><tt>src-etc release=cvs</tt></tag>
|
||||
System configuration files (<tt>/usr/src/etc</tt>).
|
||||
<tag><tt>src-games release=cvs</tt></tag>
|
||||
Games (<tt>/usr/src/games</tt>).
|
||||
<tag><tt>src-gnu release=cvs</tt></tag>
|
||||
Utilities covered by the GNU Public License (<tt>/usr/src/gnu</tt>).
|
||||
<tag><tt>src-include release=cvs</tt></tag>
|
||||
Header files (<tt>/usr/src/include</tt>).
|
||||
<tag><tt>src-lib release=cvs</tt></tag>
|
||||
Libraries (<tt>/usr/src/lib</tt>).
|
||||
<tag><tt>src-libexec release=cvs</tt></tag>
|
||||
System programs normally executed by other programs
|
||||
(<tt>/usr/src/libexec</tt>).
|
||||
<tag><tt>src-release release=cvs</tt></tag>
|
||||
Files required to produce a FreeBSD release (<tt>/usr/src/release</tt>).
|
||||
<tag><tt>src-sbin release=cvs</tt></tag>
|
||||
System utilities for single-user mode (<tt>/usr/src/sbin</tt>).
|
||||
<tag><tt>src-share release=cvs</tt></tag>
|
||||
Files that can be shared across multiple systems (<tt>/usr/src/share</tt>).
|
||||
<tag><tt>src-sys release=cvs</tt></tag>
|
||||
The kernel (<tt>/usr/src/sys</tt>).
|
||||
<tag><tt>src-tools release=cvs</tt></tag>
|
||||
Various tools for the maintenance of FreeBSD (<tt>/usr/src/tools</tt>).
|
||||
<tag><tt>src-usrbin release=cvs</tt></tag>
|
||||
User utilities (<tt>/usr/src/usr.bin</tt>).
|
||||
<tag><tt>src-usrsbin release=cvs</tt></tag>
|
||||
System utilities (<tt>/usr/src/usr.sbin</tt>).
|
||||
</descrip>
|
||||
<tag><tt>www release=cvs</tt></tag>
|
||||
The sources for the World Wide Web data.
|
||||
</descrip>
|
||||
<tag><tt>cvs-crypto release=cvs</tt></tag>
|
||||
The export-restricted cryptography code.
|
||||
<p>
|
||||
<descrip>
|
||||
<tag><tt>src-contrib-crypto release=cvs</tt></tag>
|
||||
Export-restricted utilities and libraries from outside the FreeBSD
|
||||
project, used relatively unmodified (<tt>/usr/src/contrib-crypto</tt>).
|
||||
<tag><tt>src-eBones release=cvs</tt></tag>
|
||||
Kerberos and DES (<tt>/usr/src/eBones</tt>).
|
||||
<tag><tt>src-secure release=cvs</tt></tag>
|
||||
DES (<tt>/usr/src/secure</tt>).
|
||||
</descrip>
|
||||
<tag><tt>distrib release=self</tt></tag>
|
||||
The CVSup server's own configuration files. Used by CVSup mirror sites.
|
||||
<tag><tt>gnats release=current</tt></tag>
|
||||
The GNATS bug-tracking database.
|
||||
<tag><tt>src-sys release=lite2</tt></tag>
|
||||
The CVS repository for the lite2 kernel merge.
|
||||
<tag><tt>src-sys release=smp</tt></tag>
|
||||
The CVS repository for the SMP project.
|
||||
<tag><tt>www release=current</tt></tag>
|
||||
The installed World Wide Web data. Used by WWW mirror sites.
|
||||
</descrip>
|
||||
|
||||
<sect2><heading>Announcements, Questions, and Bug Reports</heading>
|
||||
|
||||
<p>Most FreeBSD-related discussion of CVSup takes place on the
|
||||
&a.hackers;. New versions of the software are announced there, as
|
||||
well as on the &a.announce;.
|
||||
|
||||
<p>Questions and bug reports should be addressed to the author of the
|
||||
program at <url url="mailto:cvsup-bugs@polstra.com"
|
||||
name="cvsup-bugs@polstra.com">.
|
||||
@ -1,57 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
]>
|
||||
-->
|
||||
<sect2><heading>Configuring the <tt>cy</tt> driver<label id="cy"></heading>
|
||||
|
||||
<p><em>Contributed by &a.alex;.<newline>6 June 1996.</em>
|
||||
|
||||
The Cyclades multiport cards are based on the <tt>cy</tt>
|
||||
driver instead of the usual <tt>sio</tt> driver used by
|
||||
other multiport cards. Configuration is a simple matter
|
||||
of:
|
||||
|
||||
<enum>
|
||||
<item>Add the <tt>cy</tt> device to your
|
||||
<ref id="kernelconfig:config" name="kernel configuration">
|
||||
(note that your irq and iomem settings may differ).
|
||||
|
||||
<tscreen><verb>
|
||||
device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr
|
||||
</verb></tscreen>
|
||||
|
||||
<item><ref id="kernelconfig:building" name="Rebuild and install">
|
||||
the new kernel.
|
||||
|
||||
<item>Make the <ref id="kernelconfig:nodes" name="device nodes">
|
||||
by typing (the following example assumes an 8-port board):
|
||||
|
||||
<tscreen><verb>
|
||||
# cd /dev
|
||||
# for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done
|
||||
</verb></tscreen>
|
||||
|
||||
<item>If appropriate, add <ref id="dialup" name="dialup">
|
||||
entries to <ref id="dialup:ttys" name="/etc/ttys"> by
|
||||
duplicating serial device (<tt>ttyd</tt>) entries and
|
||||
using <tt>ttyc</tt> in place of <tt>ttyd</tt>. For
|
||||
example:
|
||||
|
||||
<tscreen><verb>
|
||||
ttyc0 "/usr/libexec/getty std.38400" unknown on insecure
|
||||
ttyc1 "/usr/libexec/getty std.38400" unknown on insecure
|
||||
ttyc2 "/usr/libexec/getty std.38400" unknown on insecure
|
||||
[...]
|
||||
ttyc7 "/usr/libexec/getty std.38400" unknown on insecure
|
||||
</verb></tscreen>
|
||||
|
||||
<item>Reboot with the new kernel.
|
||||
|
||||
</enum>
|
||||
@ -1,106 +0,0 @@
|
||||
<!-- $Id: development.sgml,v 1.11 1997/02/22 12:58:19 peter Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>The FreeBSD development model<label id="development"></heading>
|
||||
|
||||
<p><em>Contributed by &a.asami;</em>.
|
||||
|
||||
<p>The development of FreeBSD is a very open and flexible process,
|
||||
FreeBSD being literally built from the contributions of hundreds of
|
||||
people around the world, as can be seen from our <ref id="contrib"
|
||||
name="list of contributors">. We are constantly on the lookout for
|
||||
new developers and ideas, and those interested in becoming more
|
||||
closely involved with the project need simply contact us at the
|
||||
&a.hackers;. Those who prefer to work more independently are also
|
||||
accommodated, and they are free to use our FTP facilities at <htmlurl
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/incoming"
|
||||
name="ftp.freebsd.org"> to distribute their own patches or work-in-progress
|
||||
sources. The &a.announce; is also available to those wishing
|
||||
to make other FreeBSD users aware of major areas of work.
|
||||
|
||||
Useful things to know about the FreeBSD project and its development process,
|
||||
whether working independently or in close cooperation:
|
||||
|
||||
<descrip>
|
||||
<tag><bf>The CVS repository</bf><label id="development:cvs-repository"></tag>
|
||||
|
||||
<p>The central source tree for FreeBSD is maintained by <htmlurl
|
||||
url="http://www.cyclic.com/cyclic-pages/CVS-sheet.html" name="CVS">
|
||||
(Concurrent Version System), a freely available source code control
|
||||
tool which comes bundled with FreeBSD. The primary <htmlurl
|
||||
url="http://www.freebsd.org/cgi/cvsweb.cgi" name="CVS repository">
|
||||
resides on a machine in Concord CA, USA from where it is replicated
|
||||
to numerous mirror machines throughout the world. The CVS tree, as well
|
||||
as the <ref id="current" name="-current"> and <ref id="stable"
|
||||
name="-stable"> trees which are checked out of it, can be easily
|
||||
replicated to your own machine as well. Please refer to the
|
||||
<ref id="synching" name="Synchronizing your source tree">
|
||||
section for more information on doing this.</p>
|
||||
|
||||
<tag><bf>The committers list</bf><label id="development:committers"></tag>
|
||||
|
||||
<p>The <ref id="contrib:committers" name="committers"> are the people
|
||||
who have <em>write</em> access to the CVS tree, and are thus
|
||||
authorized to make modifications to the FreeBSD source (the term
|
||||
``committer'' comes from the <tt>cvs(1)</tt> ``<tt>commit</tt>''
|
||||
command, which is used to bring new changes into the CVS repository).
|
||||
The best way of making submissions for review by the committers list
|
||||
is to use the <htmlurl url="http://www.freebsd.org/send-pr.html"
|
||||
name="send-pr(1)"> command, though if something appears to be jammed
|
||||
in the system then you may also reach them by sending mail to <htmlurl
|
||||
url="mailto:committers@freebsd.org" name="committers@freebsd.org">.</p>
|
||||
|
||||
<tag><bf>The FreeBSD core team</bf><label id="development:core"></tag>
|
||||
|
||||
<p>The <ref id="contrib:core" name="FreeBSD core team"> would be
|
||||
equivalent to the board of directors if the FreeBSD Project were a
|
||||
company. The primary task of the core team is to make sure the
|
||||
project, as a whole, is in good shape and is heading in the right
|
||||
directions. Inviting dedicated and responsible developers to join our
|
||||
group of committers is one of the functions of the core team, as is
|
||||
the recruitment of new core team members as others move on. Most
|
||||
current members of the core team started as committers who's addiction
|
||||
to the project got the better of them.</p>
|
||||
|
||||
<p>Some core team members also have specific <ref id="contrib:who"
|
||||
name="areas of responsibility">, meaning that they are committed to
|
||||
ensuring that some large portion of the system works as advertised.
|
||||
Note that most members of the core team are volunteers when it comes
|
||||
to FreeBSD development and do not benefit from the project
|
||||
financially, so "commitment" should also not be misconstrued as
|
||||
meaning "guaranteed support." The ``board of directors'' analogy
|
||||
above is not actually very accurate, and it may be more suitable to
|
||||
say that these are the people who gave up their lives in favor of
|
||||
FreeBSD against their better judgement! <tt>;)</tt></p>
|
||||
|
||||
<tag><bf>Outside contributors</bf></tag>
|
||||
|
||||
<p>Last, but definitely not least, the largest group of developers are
|
||||
the users themselves who provide feedback and bug-fixes to us on an
|
||||
almost constant basis. The primary way of keeping in touch with FreeBSD's
|
||||
more non-centralized development is to subscribe to the &a.hackers;
|
||||
(see <ref id="eresources:mail" name="mailing list info">) where such
|
||||
things are discussed.</p>
|
||||
|
||||
<p><ref id="contrib:additional" name="The list"> of those who have
|
||||
contributed something which made its way into our source tree is
|
||||
a long and growing one, so why not join it by contributing something
|
||||
back to FreeBSD today? <tt>:-)</tt></p>
|
||||
|
||||
<p>Providing code is not the only way of contributing to the project;
|
||||
for a more complete list of things that need doing, please refer to the <ref
|
||||
id="submitters" name="how to contribute"> section in this handbook.</p>
|
||||
|
||||
</descrip>
|
||||
|
||||
In summary, our development model is organized as a loose set of
|
||||
concentric circles. The centralized model is designed for the
|
||||
convenience of the <em>users</em> of FreeBSD, who are thereby provided
|
||||
with an easy way of tracking one central code base, not to keep
|
||||
potential contributors out! Our desire is to present a stable
|
||||
operating system with a large set of coherent <ref id="ports"
|
||||
name="application programs"> that the users can easily install and
|
||||
use, and this model works very well in accomplishing that.
|
||||
|
||||
All we ask of those who would join us as FreeBSD developers is some of
|
||||
the same dedication its current people have to its continued success!
|
||||
@ -1,249 +0,0 @@
|
||||
<!-- This is an SGML document in the linuxdoc DTD of the Tutorial for
|
||||
Configuring a FreeBSD for Dialout Services.
|
||||
$Id$
|
||||
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
||||
<linuxdoc>
|
||||
<article>
|
||||
<title>Dialout
|
||||
<author>FAQ
|
||||
<date>24 Nov 1996, (c) 1996
|
||||
|
||||
<abstract> This section contains some basic information on being able to dialout from your FreeBSD box with a modem. This information is really a stepping stone into PPP.
|
||||
</abstract>
|
||||
|
||||
<toc>
|
||||
-->
|
||||
|
||||
<sect><heading>Dialout service<label id="dialout"></heading>
|
||||
|
||||
<p><em>Information integrated from FAQ.</em>
|
||||
|
||||
The following are tips to getting your host to be able to connect over the modem to another computer. This is appropriate for establishing a terminal session with a remote host.
|
||||
<p>This is useful to log onto a BBS.
|
||||
<p>This kind of connection can be extremely helpful to get a file on the Internet if you have problems with PPP. If you need to ftp something and PPP is broken, use the terminal session to ftp it. Then use zmodem to transfer it to your machine.
|
||||
<sect1>
|
||||
<heading>Why cannot I run <tt/tip/ or <tt/cu/?</heading>
|
||||
<p>
|
||||
On your system, the programs <tt/tip/ and <tt/cu/ are probably
|
||||
executable only by <tt/uucp/ and group <tt/dialer/. You can use
|
||||
the group <tt/dialer/ to control who has access to your modem or
|
||||
remote systems. Just add yourself to group dialer.
|
||||
|
||||
Alternatively, you can let everyone on your system run <tt/tip/
|
||||
and <tt/cu/ by typing:
|
||||
<verb>
|
||||
chmod 4511 /usr/bin/tip
|
||||
</verb>
|
||||
You do not have to run this command for <tt/cu/, since <tt/cu/ is
|
||||
just a hard link to <tt/tip/.
|
||||
|
||||
<sect1>
|
||||
<heading>My stock Hayes modem is not supported, what can I do?</heading>
|
||||
<p>
|
||||
Actually, the man page for <tt/tip/ is out of date. There is a
|
||||
generic Hayes dialer already built in. Just use
|
||||
``<tt/at=hayes/'' in your <tt>/etc/remote</tt> file.
|
||||
|
||||
The Hayes driver is not smart enough to recognize some of the
|
||||
advanced features of newer modems—messages like <tt/BUSY/,
|
||||
<tt/NO DIALTONE/, or <tt/CONNECT 115200/ will just confuse it.
|
||||
You should turn those messages off when you use <tt/tip/ (using
|
||||
<tt/ATX0&W/).
|
||||
|
||||
Also, the dial timeout for <tt/tip/ is 60 seconds. Your modem
|
||||
should use something less, or else tip will think there is a
|
||||
communication problem. Try <tt/ATS7=45&W/.
|
||||
|
||||
Actually, as shipped <tt/tip/ does not yet support it fully. The
|
||||
solution is to edit the file <tt/tipconf.h/ in the directory
|
||||
<tt>/usr/src/usr.bin/tip/tip</tt> Obviously you need the source
|
||||
distribution to do this.
|
||||
|
||||
Edit the line ``<tt/#define HAYES 0/'' to ``<tt/#define HAYES
|
||||
1/''. Then ``<tt/make/'' and ``<tt/make install/''. Everything
|
||||
works nicely after that.
|
||||
|
||||
<sect1>
|
||||
<heading>How am I expected to enter these AT commands?<label id="direct-at"></heading>
|
||||
<p>
|
||||
Make what is called a ``<tt/direct/'' entry in your
|
||||
<tt>/etc/remote</tt> file. For example, if your modem is hooked
|
||||
up to the first serial port, <tt>/dev/cuaa0</tt>, then put in the
|
||||
following line:
|
||||
<verb>
|
||||
cuaa0:dv=/dev/cuaa0:br#19200:pa=none
|
||||
</verb>
|
||||
Use the highest bps rate your modem supports in the br
|
||||
capability. Then, type ``<tt/tip cuaa0/'' and you will be
|
||||
connected to your modem.
|
||||
|
||||
If there is no <tt>/dev/cuaa0</tt> on your system, do this:
|
||||
<verb>
|
||||
cd /dev
|
||||
MAKEDEV cuaa0
|
||||
</verb>
|
||||
<p>
|
||||
Or use cu as root with the following command:
|
||||
<verb>
|
||||
cu -l``line'' -s``speed''
|
||||
</verb>
|
||||
with line being the serial port (e.g.<tt>/dev/cuaa0</tt>)
|
||||
and speed being the speed (e.g.<tt>57600</tt>).
|
||||
When you are done entering the AT commands hit <tt>~.</tt> to exit.
|
||||
|
||||
<sect1>
|
||||
<heading>The <tt/@/ sign for the pn capability does not work!</heading>
|
||||
<p>
|
||||
The <tt/@/ sign in the phone number capability tells tip to look in
|
||||
<tt>/etc/phones</tt> for a phone number. But the <tt/@/ sign is
|
||||
also a special character in capability files like
|
||||
<tt>/etc/remote</tt>. Escape it with a backslash:
|
||||
<verb>
|
||||
pn=\@
|
||||
</verb>
|
||||
|
||||
<sect1>
|
||||
<heading>How can I dial a phone number on the command line?</heading>
|
||||
<p>
|
||||
Put what is called a ``<tt/generic/'' entry in your
|
||||
<tt>/etc/remote</tt> file. For example:
|
||||
<verb>
|
||||
tip115200|Dial any phone number at 115200 bps:\
|
||||
:dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
|
||||
tip57600|Dial any phone number at 57600 bps:\
|
||||
:dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:
|
||||
</verb>
|
||||
|
||||
Then you can things like ``<tt/tip -115200 5551234/''. If you
|
||||
prefer <tt/cu/ over <tt/tip/, use a generic cu entry:
|
||||
<verb>
|
||||
cu115200|Use cu to dial any number at 115200bps:\
|
||||
:dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:
|
||||
</verb>
|
||||
and type ``<tt/cu 5551234 -s 115200/''.
|
||||
|
||||
<sect1>
|
||||
<heading>Do I have to type in the bps rate every time I do that?</heading>
|
||||
<p>
|
||||
Put in an entry for <tt/tip1200/ or <tt/cu1200/, but go ahead and
|
||||
use whatever bps rate is appropriate with the br
|
||||
capability. <tt/tip/ thinks a good default is 1200 bps which is
|
||||
why it looks for a ``<tt/tip1200/'' entry. You do not have to use
|
||||
1200 bps, though.
|
||||
|
||||
<sect1>
|
||||
<heading>I access a number of hosts through a terminal server.</heading>
|
||||
<p>
|
||||
Rather than waiting until you are connected and typing
|
||||
``<tt/CONNECT <host>/'' each time, use tip's <tt/cm/
|
||||
capability. For example, these entries in
|
||||
<tt>/etc/remote</tt>:
|
||||
<verb>
|
||||
pain|pain.deep13.com|Forrester's machine:\
|
||||
:cm=CONNECT pain\n:tc=deep13:
|
||||
muffin|muffin.deep13.com|Frank's machine:\
|
||||
:cm=CONNECT muffin\n:tc=deep13:
|
||||
deep13:Gizmonics Institute terminal server:\
|
||||
:dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234:
|
||||
</verb>
|
||||
|
||||
will let you type ``<tt/tip pain/'' or ``<tt/tip muffin/'' to
|
||||
connect to the hosts pain or muffin; and ``<tt/tip deep13/'' to
|
||||
get to the terminal server.
|
||||
|
||||
<sect1>
|
||||
<heading>Can tip try more than one line for each site?</heading>
|
||||
<p>
|
||||
This is often a problem where a university has several modem lines
|
||||
and several thousand students trying to use them...
|
||||
<p>
|
||||
Make an entry for your university in <tt>/etc/remote</tt>
|
||||
and use <tt>@</tt> for the <tt/pn/ capability:
|
||||
<verb>
|
||||
big-university:\
|
||||
:pn=\@:tc=dialout
|
||||
dialout:\
|
||||
:dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:
|
||||
</verb>
|
||||
|
||||
Then, list the phone numbers for the university in
|
||||
<tt>/etc/phones</tt>:
|
||||
<verb>
|
||||
big-university 5551111
|
||||
big-university 5551112
|
||||
big-university 5551113
|
||||
big-university 5551114
|
||||
</verb>
|
||||
|
||||
<tt/tip/ will try each one in the listed order, then give up. If
|
||||
you want to keep retrying, run <tt/tip/ in a while loop.
|
||||
|
||||
<sect1>
|
||||
<heading>Why do I have to hit CTRL+P twice to send CTRL+P once?</heading>
|
||||
<p>
|
||||
CTRL+P is the default ``force'' character, used to tell <tt/tip/
|
||||
that the next character is literal data. You can set the force
|
||||
character to any other character with the <tt/~s/ escape, which
|
||||
means ``set a variable.''
|
||||
|
||||
Type ``<tt/~sforce=<single-char>/'' followed by a newline.
|
||||
<tt/<single-char>/ is any single character. If you leave
|
||||
out <tt/<single-char>/, then the force character is the nul
|
||||
character, which you can get by typing CTRL+2 or CTRL+SPACE. A
|
||||
pretty good value for <tt/<single-char>/ is SHIFT+CTRL+6,
|
||||
which I have seen only used on some terminal servers.
|
||||
|
||||
You can have the force character be whatever you want by
|
||||
specifying the following in your <tt>$HOME/.tiprc</tt>
|
||||
file:
|
||||
<verb>
|
||||
force=<single-char>
|
||||
</verb>
|
||||
|
||||
<sect1>
|
||||
<heading>Suddenly everything I type is in UPPER CASE??</heading>
|
||||
<p>
|
||||
You must have pressed CTRL+A, <tt/tip/'s ``raise character,''
|
||||
specially designed for people with broken caps-lock keys. Use
|
||||
<tt/~s/ as above and set the variable ``raisechar'' to something
|
||||
reasonable. In fact, you can set it to the same as the force
|
||||
character, if you never expect to use either of these features.
|
||||
|
||||
Here is a sample .tiprc file perfect for Emacs users who need to
|
||||
type CTRL+2 and CTRL+A a lot:
|
||||
<verb>
|
||||
force=^^
|
||||
raisechar=^^
|
||||
</verb>
|
||||
The ^^ is SHIFT+CTRL+6.
|
||||
|
||||
<sect1>
|
||||
<heading>How can I do file transfers with <tt/tip/?</heading>
|
||||
<p>
|
||||
If you are talking to another UNIX system, you can send and
|
||||
receive files with <tt/~p/ (put) and <tt/~t/ (take). These
|
||||
commands run ``<tt/cat/'' and ``<tt/echo/'' on the remote system
|
||||
to accept and send files. The syntax is:
|
||||
<verb>
|
||||
~p <local-file> [<remote-file>]
|
||||
~t <remote-file> [<local-file>]
|
||||
</verb>
|
||||
|
||||
There is no error checking, so you probably should use another
|
||||
protocol, like zmodem.
|
||||
|
||||
<sect1>
|
||||
<heading>How can I run zmodem with <tt/tip/?</heading>
|
||||
<p>
|
||||
To receive files, start the sending program on the remote end.
|
||||
Then, type ``<tt/~C rz/'' to begin receiving them locally.
|
||||
|
||||
To send files, start the receiving program on the remote end.
|
||||
Then, type ``<tt/~C sz <files>/'' to send them to the
|
||||
remote system.
|
||||
|
||||
</sect>
|
||||
@ -1,810 +0,0 @@
|
||||
<!-- This is an SGML document in the linuxdoc DTD of the Tutorial for
|
||||
Configuring a FreeBSD for Dialup Services by Guy Helmer.
|
||||
$Id$
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//Linux//DTD linuxdoc//EN">
|
||||
|
||||
|
||||
<article>
|
||||
|
||||
<title>
|
||||
Configuring FreeBSD for Dialup Services
|
||||
<author>Guy Helmer, <tt/ghelmer@alpha.dsu.edu/
|
||||
<date>v0.1, 28 March 1995
|
||||
<abstract>
|
||||
|
||||
-->
|
||||
|
||||
<sect><heading>Dialin service<label id="dialup"></heading>
|
||||
|
||||
<p><em>Contributed by &a.ghelmer;.</em>
|
||||
|
||||
This document provides suggestions for configuring a FreeBSD system to
|
||||
handle dialup modems. This document is written based on the author's
|
||||
experience with FreeBSD versions 1.0, 1.1, and 1.1.5.1 (and experience
|
||||
with dialup modems on other UNIX-like operating systems); however,
|
||||
this document may not answer all of your questions or provide examples
|
||||
specific enough to your environment. The author cannot be responsible
|
||||
if you damage your system or lose data due to attempting to follow the
|
||||
suggestions here.
|
||||
|
||||
<sect1><heading>Prerequisites<label id="dialup:prereqs"></>
|
||||
<p>
|
||||
|
||||
To begin with, the author assumes you have some basic knowledge of
|
||||
FreeBSD. You need to have FreeBSD installed, know how to edit files
|
||||
in a UNIX-like environment, and how to look up manual pages on the
|
||||
system. As discussed below, you will need certain versions of FreeBSD,
|
||||
and knowledge of some terminology & modem and cabling.
|
||||
|
||||
<sect2><heading>FreeBSD Version</heading>
|
||||
<p>
|
||||
|
||||
First, it is assumed that you are using FreeBSD version 1.1 or higher
|
||||
(including versions 2.x). FreeBSD version 1.0 included two different
|
||||
serial drivers, which complicates the situation. Also, the serial
|
||||
device driver (<tt/sio/) has improved in every release of FreeBSD, so
|
||||
more recent versions of FreeBSD are assumed to have better and more
|
||||
efficient drivers than earlier versions.
|
||||
|
||||
<sect2><heading>Terminology</heading>
|
||||
<p>
|
||||
|
||||
A quick rundown of terminology:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/bps/ Bits per Second - the rate at which data is transmitted
|
||||
|
||||
<tag/DTE/ Data Terminal Equipment - for example, your computer
|
||||
|
||||
<tag/DCE/ Data Communications Equipment - your modem
|
||||
|
||||
<tag/RS-232/ EIA standard for serial communications via hardware
|
||||
|
||||
</descrip>
|
||||
|
||||
If you need more information about these terms and data communications
|
||||
in general, the author remembers reading that <em/The RS-232 Bible/
|
||||
(anybody have an ISBN?) is a good reference.
|
||||
|
||||
When talking about communications data rates, the author does not use
|
||||
the term <bf/baud/. Baud refers to the number of electrical state
|
||||
transitions that may be made in a period of time, while <bf/bps/ (bits
|
||||
per second) is the ``correct'' term to use (at least it does not seem
|
||||
to bother the curmudgeons quite a much).
|
||||
|
||||
<sect2><heading>External vs. Internal Modems</heading>
|
||||
<p>
|
||||
|
||||
External modems seem to be more convenient for dialup, because
|
||||
external modems often can be semi-permanently configured via
|
||||
parameters stored in non-volatile RAM and they usually provide lighted
|
||||
indicators that display the state of important RS-232 signals.
|
||||
Blinking lights impress visitors, but lights are also very useful to
|
||||
see whether a modem is operating properly.
|
||||
|
||||
Internal modems usually lack non-volatile RAM, so their configuration
|
||||
may be limited only to setting DIP switches. If your internal modem
|
||||
has any signal indicator lights, it is probably difficult to view the
|
||||
lights when the system's cover is in place.
|
||||
|
||||
<sect2><heading>Modems and Cables</heading>
|
||||
<p>
|
||||
|
||||
A background knowledge of these items is assumed
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> You know how to connect your modem to your computer so that the
|
||||
two can communicate (unless you have an internal modem, which does not
|
||||
need such a cable)
|
||||
|
||||
<item> You are familiar with your modem's command set, or know where
|
||||
to look up needed commands
|
||||
|
||||
<item> You know how to configure your modem (probably via a terminal
|
||||
communications program) so you can set the non-volatile RAM
|
||||
parameters
|
||||
|
||||
</itemize>
|
||||
|
||||
The first, connecting your modem, is usually simple - most
|
||||
straight-through serial cables work without any problems. You need to
|
||||
have a cable with appropriate connectors (DB-25 or DB-9, male or
|
||||
female) on each end, and the cable must be a DCE-to-DTE cable with
|
||||
these signals wired:
|
||||
|
||||
<itemize>
|
||||
<item> Transmitted Data (<tt/SD/)
|
||||
<item> Received Data (<tt/RD/)
|
||||
<item> Request to Send (<tt/RTS/)
|
||||
<item> Clear to Send (<tt/CTS/)
|
||||
<item> Data Set Ready (<tt/DSR/)
|
||||
<item> Data Terminal Ready (<tt/DTR/)
|
||||
<item> Carrier Detect (<tt/CD/)
|
||||
<item> Signal Ground (<tt/SG/)
|
||||
</itemize>
|
||||
|
||||
FreeBSD needs the <tt/RTS/ and <tt/CTS/ signals for flow-control at
|
||||
speeds above 2400bps, the <tt/CD/ signal to detect when a call has
|
||||
been answered or the line has been hung up, and the <tt/DTR/ signal to
|
||||
reset the modem after a session is complete. Some cables are wired
|
||||
without all of the needed signals, so if you have problems, such as
|
||||
a login session not going away when the line hangs up, you may have a
|
||||
problem with your cable.
|
||||
|
||||
The second prerequisite depends on the modem(s) you use. If you do not
|
||||
know your modem's command set by heart, you will need to have the
|
||||
modem's reference book or user's guide handy. Sample commands for USR
|
||||
Sportster 14,400 external modems will be given, which you may be able
|
||||
to use as a reference for your own modem's commands.
|
||||
|
||||
Lastly, you will need to know how to setup your modem so that it will
|
||||
work well with FreeBSD. Like other UNIX-like operating systems,
|
||||
FreeBSD uses the hardware signals to find out when a call has been
|
||||
answered or a line has been hung up and to hangup and reset the modem
|
||||
after a call. FreeBSD avoids sending commands to the modem or
|
||||
watching for status reports from the modem. If you are familiar with
|
||||
connecting modems to PC-based bulletin board systems, this may seem
|
||||
awkward.
|
||||
|
||||
<sect2><heading>Serial Interface Considerations</heading>
|
||||
<p>
|
||||
|
||||
FreeBSD supports NS8250-, NS16450-, NS16550-, and NS16550A-based EIA
|
||||
RS-232C (CCITT V.24) communications interfaces. The 8250 and 16450
|
||||
devices have single-character buffers. The 16550 device provides a
|
||||
16-character buffer, which allows for better system performance.
|
||||
(Bugs in plain 16550's prevent the use of the 16-character buffer, so
|
||||
use 16550A's if possible). Because single-character-buffer devices
|
||||
require more work by the operating system than the 16-character-buffer
|
||||
devices, 16550A-based serial interface cards are much prefered. If
|
||||
the system has many active serial ports or will have a heavy load,
|
||||
16550A-based cards are better for low-error-rate communications.
|
||||
|
||||
<sect1><heading>Quick Overview</heading>
|
||||
<p>
|
||||
|
||||
Here is the process that FreeBSD follows to accept dialup logins. A
|
||||
<tt/getty/ process, spawned by <tt/init/, patiently waits to open the
|
||||
assigned serial port (<tt>/dev/ttyd0</tt>, for our example). The
|
||||
command <tt/ps ax/ might show this:
|
||||
|
||||
<tscreen><verb>
|
||||
4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0
|
||||
</verb></tscreen>
|
||||
|
||||
When a user dials the modem's line and the modems connect, the <tt/CD/
|
||||
line is asserted by the modem. The kernel notices that carrier has
|
||||
been detected and completes <tt/getty/'s open of the port. <tt/getty/
|
||||
sends a <tt/login:/ prompt at the specified initial line speed.
|
||||
<tt/getty/ watches to see if legitimate characters are received, and,
|
||||
in a typical configuration, if it finds junk (probably due to the
|
||||
modem's connection speed being different than <tt/getty/'s speed),
|
||||
<tt/getty/ tries adjusting the line speeds until it receives
|
||||
reasonable characters.
|
||||
|
||||
We hope <tt/getty/ finds the correct speed and the user sees a
|
||||
<tt/login:/ prompt. After the user enters his/her login name,
|
||||
<tt/getty/ executes <tt>/usr/bin/login</tt>, which completes the login
|
||||
by asking for the user's password and then starting the user's shell.
|
||||
|
||||
Let's dive into the configuration...
|
||||
|
||||
<sect1><heading>Kernel Configuration</heading>
|
||||
<p>
|
||||
|
||||
FreeBSD kernels typically come prepared to search for four serial
|
||||
ports, known in the PC-DOS world as <tt/COM1:/, <tt/COM2:/,
|
||||
<tt/COM3:/, and <tt/COM4:/. FreeBSD can presently also handle
|
||||
``dumb'' multiport serial interface cards, such as the Boca Board
|
||||
1008 and 2016 (please see the manual page <tt/sio(4)/ for kernel
|
||||
configuration information if you have a multiport serial card). The
|
||||
default kernel only looks for the standard COM ports, though.
|
||||
|
||||
To see if your kernel recognizes any of your serial ports, watch for
|
||||
messages while the kernel is booting, or use the
|
||||
<tt>/sbin/dmesg</tt> command to replay the kernel's boot messages. In
|
||||
particular, look for messages that start with the characters <tt/sio/.
|
||||
Hint: to view just the messages that have the word <tt/sio/, use the
|
||||
command:
|
||||
|
||||
<tscreen><verb>
|
||||
/sbin/dmesg | grep 'sio'
|
||||
</verb></tscreen>
|
||||
|
||||
For example, on a system with four serial ports, these are the
|
||||
serial-port specific kernel boot messages:
|
||||
|
||||
<tscreen><verb>
|
||||
sio0 at 0x3f8-0x3ff irq 4 on isa
|
||||
sio0: type 16550A
|
||||
sio1 at 0x2f8-0x2ff irq 3 on isa
|
||||
sio1: type 16550A
|
||||
sio2 at 0x3e8-0x3ef irq 5 on isa
|
||||
sio2: type 16550A
|
||||
sio3 at 0x2e8-0x2ef irq 9 on isa
|
||||
sio3: type 16550A
|
||||
</verb></tscreen>
|
||||
|
||||
If your kernel does not recognize all of your serial ports, you will
|
||||
probably need to configure a custom FreeBSD kernel for your system.
|
||||
|
||||
Please see the BSD System Manager's Manual chapter on ``Building
|
||||
Berkeley Kernels with Config'' [the source for which is in
|
||||
<tt>/usr/src/share/doc/smm</tt>] and ``FreeBSD Configuration
|
||||
Options'' [in <tt>/sys/conf/options</tt> and in
|
||||
<tt>/sys/<em>arch</em>/conf/options.<em>arch</em></tt>, with
|
||||
<em>arch</em> for example being <tt>i386</tt>] for more
|
||||
information on configuring and building kernels. You may have to
|
||||
unpack the kernel source distribution if have not installed the system
|
||||
sources already (<tt>srcdist/srcsys.??</tt> in FreeBSD 1.1,
|
||||
<tt>srcdist/sys.??</tt> in FreeBSD 1.1.5.1, or the entire source
|
||||
distribution in FreeBSD 2.0) to be able to configure and build
|
||||
kernels.
|
||||
|
||||
Create a kernel configuration file for your system (if you have not
|
||||
already) by <tt/cd/ing to <tt>/sys/i386/conf</tt>. Then, if you are
|
||||
creating a new custom configuration file, copy the file GENERICAH (or
|
||||
GENERICBT, if you have a BusTek SCSI controller on FreeBSD 1.x) to
|
||||
<em/YOURSYS/, where <em/YOURSYS/ is the name of your system, but in
|
||||
upper-case letters. Edit the file, and change the device lines:
|
||||
|
||||
<tscreen><verb>
|
||||
device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
|
||||
device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
|
||||
device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr
|
||||
device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr
|
||||
</verb></tscreen>
|
||||
|
||||
You can comment-out or completely remove lines for devices you do not
|
||||
have. If you have a multiport serial board, such as the Boca Board
|
||||
BB2016, please see the <tt/sio(4)/ man page for complete information
|
||||
on how to write configuration lines for multiport boards. Be careful
|
||||
if you are using a configuration file that was previously used for a
|
||||
different version of FreeBSD because the device flags have changed
|
||||
between versions.
|
||||
|
||||
Note that <tt/port "IO_COM1"/ is a substitution for <tt/port 0x3f8/,
|
||||
<tt/IO_COM2/ is <tt/0x2f8/, <tt/IO_COM3/ is <tt/0x3e8/, and
|
||||
<tt/IO_COM4/ is <tt/0x2e8/, which are fairly common port addresses for
|
||||
their respective serial ports; interrupts 4, 3, 5, and 9 are fairly
|
||||
common interrupt request lines. Also note that regular serial ports
|
||||
<bf>cannot</bf> share interrupts on ISA-bus PCs (multiport boards have
|
||||
on-board electronics that allow all the 16550A's on the board to share
|
||||
one or two interrupt request lines).
|
||||
|
||||
When you are finished adjusting the kernel configuration file, use the
|
||||
program <tt/config/ as documented in ``Building Berkeley Kernels with
|
||||
Config'' and the <tt/config(8)/ manual page to prepare a kernel
|
||||
building directory, then build, install, and test the new kernel.
|
||||
|
||||
<sect1><heading>Device Special Files</heading>
|
||||
<p>
|
||||
|
||||
Most devices in the kernel are accessed through ``device special
|
||||
files'', which are located in the <tt>/dev</tt> directory. The
|
||||
<tt/sio/ devices are accessed through the <tt>/dev/ttyd?</tt>
|
||||
(dial-in) and <tt>/dev/cua0?</tt> (call-out) devices. On FreeBSD
|
||||
version 1.1.5 and higher, there are also initialization devices
|
||||
(<tt>/dev/ttyid?</tt> and <tt>/dev/cuai0?</tt>) and locking devices
|
||||
(<tt>/dev/ttyld?</tt> and <tt>/dev/cual0?</tt>). The initialization
|
||||
devices are used to initialize communications port parameters each
|
||||
time a port is opened, such as <tt>crtscts</tt> for modems which use
|
||||
<tt>CTS/RTS</tt> signaling for flow control. The locking devices are
|
||||
used to lock flags on ports to prevent users or programs changing
|
||||
certain parameters; see the manual pages <tt/termios(4)/, <tt/sio(4)/,
|
||||
and <tt/stty(1)/ for information on the terminal settings, locking
|
||||
& initializing devices, and setting terminal options,
|
||||
respectively.
|
||||
|
||||
<sect2><heading>Making Device Special Files</heading>
|
||||
<p>
|
||||
|
||||
A shell script called <tt/MAKEDEV/ in the <tt>/dev</tt> directory
|
||||
manages the device special files. (The manual page for
|
||||
<tt/MAKEDEV(8)/ on FreeBSD 1.1.5 is fairly bogus in its discussion of
|
||||
<tt/COM/ ports, so ignore it.) To use <tt/MAKEDEV/ to make dialup
|
||||
device special files for <tt/COM1:/ (port 0), <tt/cd/ to <tt>/dev</tt>
|
||||
and issue the command <tt/MAKEDEV ttyd0/. Likewise, to make dialup
|
||||
device special files for <tt/COM2:/ (port 1), use <tt/MAKEDEV ttyd1/.
|
||||
|
||||
<tt/MAKEDEV/ not only creates the <tt>/dev/ttyd?</tt> device special
|
||||
files, but also creates the <tt>/dev/cua0?</tt> (and all of the
|
||||
initializing and locking special files under FreeBSD 1.1.5 and up) and
|
||||
removes the hardwired terminal special file <tt>/dev/tty0?</tt>, if it
|
||||
exists.
|
||||
|
||||
After making new device special files, be sure to check the
|
||||
permissions on the files (especially the <tt>/dev/cua*</tt> files) to
|
||||
make sure that only users who should have access to those device
|
||||
special files can read & write on them - you probably do not want
|
||||
to allow your average user to use your modems to dialout. The default
|
||||
permissions on the <tt>/dev/cua*</tt> files should be sufficient:
|
||||
|
||||
<tscreen><verb>
|
||||
crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01
|
||||
crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01
|
||||
crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01
|
||||
</verb></tscreen>
|
||||
|
||||
These permissions allow the user <tt/uucp/ and users in the group
|
||||
<tt/dialer/ to use the call-out devices.
|
||||
|
||||
<sect1><heading>Configuration Files</heading>
|
||||
<p>
|
||||
|
||||
There are three system configuration files in the <tt>/etc</tt>
|
||||
directory that you will probably need to edit to allow dialup access to
|
||||
your FreeBSD system. The first, <tt>/etc/gettytab</tt>, contains
|
||||
configuration information for the <tt>/usr/libexec/getty</tt> daemon.
|
||||
Second, <tt>/etc/ttys</tt> holds information that tells
|
||||
<tt>/sbin/init</tt> what <tt/tty/ devices should have <tt/getty/
|
||||
processes running on them. Lastly, you can place port initialization
|
||||
commands in the <tt>/etc/rc.serial</tt> script if you have FreeBSD
|
||||
1.1.5.1 or higher; otherwise, you can initialize ports in the
|
||||
<tt>/etc/rc.local</tt> script.
|
||||
|
||||
There are two schools of thought regarding dialup modems on UNIX. One
|
||||
group likes to configure their modems and system so that no matter at
|
||||
what speed a remote user dials in, the local computer-to-modem RS-232
|
||||
interface runs at a locked speed. The benefit of this configuration
|
||||
is that the remote user always sees a system login prompt immediately.
|
||||
The downside is that the system does not know what a user's true data
|
||||
rate is, so full-screen programs like Emacs will not adjust their
|
||||
screen-painting methods to make their response better for slower
|
||||
connections.
|
||||
|
||||
The other school configures their modems' RS-232 interface to vary its
|
||||
speed based on the remote user's connection speed. For example,
|
||||
V.32bis (14.4 Kbps) connections to the modem might make the modem run
|
||||
its RS-232 interface at 19.2 Kbps, while 2400 bps connections make the
|
||||
modem's RS-232 interface run at 2400 bps. Because <tt/getty/ does not
|
||||
understand any particular modem's connection speed reporting,
|
||||
<tt/getty/ gives a <tt/login:/ message at an initial speed and watches
|
||||
the characters that come back in response. If the user sees junk,
|
||||
it is assumed that they know they should press the
|
||||
<tt><Enter></tt> key until they see a recognizable prompt. If
|
||||
the data rates do not match, <tt/getty/ sees anything the user types as
|
||||
``junk'', tries going to the next speed and gives the <tt/login:/
|
||||
prompt again. This procedure can continue ad nauseum, but normally
|
||||
only takes a keystroke or two before the user sees a good prompt.
|
||||
Obviously, this login sequence does not look as clean as the former
|
||||
``locked-speed'' method, but a user on a low-speed connection should
|
||||
receive better interactive response from full-screen programs.
|
||||
|
||||
The author will try to give balanced configuration information, but is
|
||||
biased towards having the modem's data rate follow the connection
|
||||
rate.
|
||||
|
||||
<sect2><heading>/etc/gettytab</heading>
|
||||
<p>
|
||||
|
||||
<tt>/etc/gettytab</tt> is a <tt/termcap(5)/-style file of
|
||||
configuration information for <tt/getty(8)/. Please see the
|
||||
<tt/gettytab(4)/ manual page for complete information on the format of
|
||||
the file and the list of capabilities.
|
||||
|
||||
<sect3><heading>Locked-Speed Config</heading>
|
||||
<p>
|
||||
|
||||
If you are locking your modem's data communications rate at a
|
||||
particular speed, you probably will not need to make any changes to
|
||||
<tt>/etc/gettytab</tt>.
|
||||
|
||||
<sect3><heading>Matching-Speed Config</heading>
|
||||
<p>
|
||||
|
||||
You will need to setup an entry in <tt>/etc/gettytab</tt> to give
|
||||
<tt/getty/ information about the speeds you wish to use for your
|
||||
modem. If you have a 2400 bps modem, you can probably use the
|
||||
existing <tt/D2400/ entry. This entry already exists in the FreeBSD
|
||||
1.1.5.1 <tt/gettytab/ file, so you do not need to add it unless it is
|
||||
missing under your version of FreeBSD:
|
||||
|
||||
<tscreen><verb>
|
||||
#
|
||||
# Fast dialup terminals, 2400/1200/300 rotary (can start either way)
|
||||
#
|
||||
D2400|d2400|Fast-Dial-2400:\
|
||||
:nx=D1200:tc=2400-baud:
|
||||
3|D1200|Fast-Dial-1200:\
|
||||
:nx=D300:tc=1200-baud:
|
||||
5|D300|Fast-Dial-300:\
|
||||
:nx=D2400:tc=300-baud:
|
||||
</verb></tscreen>
|
||||
|
||||
If you have a higher speed modem, you will probably need to add an entry
|
||||
in <tt>/etc/gettytab</tt>; here is an entry you could use for a 14.4
|
||||
Kbps modem with a top interface speed of 19.2 Kbps:
|
||||
|
||||
<tscreen><verb>
|
||||
#
|
||||
# Additions for a V.32bis Modem
|
||||
#
|
||||
um|V300|High Speed Modem at 300,8-bit:\
|
||||
:nx=V19200:tc=std.300:
|
||||
un|V1200|High Speed Modem at 1200,8-bit:\
|
||||
:nx=V300:tc=std.1200:
|
||||
uo|V2400|High Speed Modem at 2400,8-bit:\
|
||||
:nx=V1200:tc=std.2400:
|
||||
up|V9600|High Speed Modem at 9600,8-bit:\
|
||||
:nx=V2400:tc=std.9600:
|
||||
uq|V19200|High Speed Modem at 19200,8-bit:\
|
||||
:nx=V9600:tc=std.19200:
|
||||
</verb></tscreen>
|
||||
|
||||
On FreeBSD 1.1.5 and later, this will result in 8-bit, no parity
|
||||
connections. Under FreeBSD 1.1, add <tt/:np:/ parameters to the
|
||||
<tt>std.<em/xxx/</tt> entries at the top of the file for 8 bits, no
|
||||
parity; otherwise, the default is 7 bits, even parity.
|
||||
|
||||
The example above starts the communications rate at 19.2 Kbps (for a
|
||||
V.32bis connection), then cycles through 9600 bps (for V.32), 2400
|
||||
bps, 1200 bps, 300 bps, and back to 19.2 Kbps. Communications rate
|
||||
cycling is implemented with the <tt/nx=/ (<bf/next table/) capability.
|
||||
Each of the lines uses a <tt/tc=/ (<bf/table continuation/) entry to
|
||||
pick up the rest of the ``standard'' settings for a particular data
|
||||
rate.
|
||||
|
||||
If you have a 28.8 Kbps modem and/or you want to take advantage of
|
||||
compression on a 14.4 Kbps modem, you need to use a higher
|
||||
communications rate than 19.2 Kbps. Here is an example of a
|
||||
<tt/gettytab/ entry starting a 57.6 Kbps:
|
||||
|
||||
<tscreen><verb>
|
||||
#
|
||||
# Additions for a V.32bis or V.34 Modem
|
||||
# Starting at 57.6 Kbps
|
||||
#
|
||||
vm|VH300|Very High Speed Modem at 300,8-bit:\
|
||||
:nx=VH57600:tc=std.300:
|
||||
vn|VH1200|Very High Speed Modem at 1200,8-bit:\
|
||||
:nx=VH300:tc=std.1200:
|
||||
vo|VH2400|Very High Speed Modem at 2400,8-bit:\
|
||||
:nx=VH1200:tc=std.2400:
|
||||
vp|VH9600|Very High Speed Modem at 9600,8-bit:\
|
||||
:nx=VH2400:tc=std.9600:
|
||||
vq|VH57600|Very High Speed Modem at 57600,8-bit:\
|
||||
:nx=VH9600:tc=std.57600:
|
||||
</verb></tscreen>
|
||||
|
||||
If you have a slow CPU or a heavily loaded system and you do not have
|
||||
16550A-based serial ports, you may receive sio ``silo'' errors at 57.6
|
||||
Kbps.
|
||||
|
||||
<sect2><heading>/etc/ttys<label id="dialup:ttys"></heading>
|
||||
<p>
|
||||
|
||||
<tt>/etc/ttys</tt> is the list of <tt/ttys/ for <tt/init/ to monitor.
|
||||
<tt>/etc/ttys</tt> also provides security information to <tt/login/
|
||||
(user <tt/root/ may only login on ttys marked <tt/secure/). See the
|
||||
manual page for <tt/ttys(5)/ for more information.
|
||||
|
||||
You will need to either modify existing lines in <tt>/etc/ttys</tt> or
|
||||
add new lines to make <tt/init/ run <tt/getty/ processes automatically
|
||||
on your new dialup ports. The general format of the line will be the
|
||||
same, whether you are using a locked-speed or matching-speed
|
||||
configuration:
|
||||
|
||||
<tscreen><verb>
|
||||
ttyd0 "/usr/libexec/getty xxx" dialup on
|
||||
</verb></tscreen>
|
||||
|
||||
The first item in the above line is the device special file for this
|
||||
entry - <tt/ttyd0/ means <tt>/dev/ttyd0</tt> is the file that this
|
||||
<tt/getty/ will be watching. The second item, <tt>"/usr/libexec/getty
|
||||
<em/xxx/"</tt> (<em/xxx/ will be replaced by the initial <tt/gettytab/
|
||||
capability) is the process <tt/init/ will run on the device. The
|
||||
third item, <tt/dialup/, is the default terminal type. The fourth
|
||||
parameter, <tt/on/, indicates to <tt/init/ that the line is
|
||||
operational. There can be a fifth parameter, <tt>secure</tt>, but it
|
||||
should only be used for terminals which are physically secure (such as
|
||||
the system console).
|
||||
|
||||
The default terminal type (<tt/dialup/ in the example above) may
|
||||
depend on local preferences. <tt/dialup/ is the traditional default
|
||||
terminal type on dialup lines so that users may customize their login
|
||||
scripts to notice when the terminal is <tt/dialup/ and automatically
|
||||
adjust their terminal type. However, the author finds it easier at
|
||||
his site to specify <tt/vt102/ as the default terminal type, since the
|
||||
users just use VT102 emulation on their remote systems.
|
||||
|
||||
After you have made changes to <tt>/etc/ttys</tt>, you may send the
|
||||
<tt/init/ process a <tt/HUP/ signal to re-read the file. You can use
|
||||
the command
|
||||
|
||||
<tscreen><verb>
|
||||
kill -1 1
|
||||
</verb></tscreen>
|
||||
|
||||
to send the signal. If this is your first time setting up the system,
|
||||
though, you may want to wait until your modem(s) are properly
|
||||
configured and connected before signaling <tt/init/.
|
||||
|
||||
<sect3><heading>Locked-Speed Config</heading>
|
||||
<p>
|
||||
|
||||
For a locked-speed configuration, your <tt/ttys/ entry needs to
|
||||
have a fixed-speed entry provided to <tt/getty/. For a modem whose
|
||||
port speed is locked at 19.2 Kbps, the <tt/ttys/ entry might look like
|
||||
this:
|
||||
|
||||
<tscreen><verb>
|
||||
ttyd0 "/usr/libexec/getty std.19200" dialup on
|
||||
</verb></tscreen>
|
||||
|
||||
If your modem is locked at a different data rate, substitute the
|
||||
appropriate name for the <tt>std.<em/speed/</tt> entry for
|
||||
<tt/std.19200/ from <tt>/etc/gettytab</tt> for your modem's data rate.
|
||||
|
||||
<sect3><heading>Matching-Speed Config</heading>
|
||||
<p>
|
||||
|
||||
In a matching-speed configuration, your <tt/ttys/ entry needs to
|
||||
reference the appropriate beginning ``auto-baud'' (sic) entry in
|
||||
<tt>/etc/gettytab</tt>. For example, if you added the above suggested
|
||||
entry for a matching-speed modem that starts at 19.2 Kbps (the
|
||||
<tt/gettytab/ entry containing the <tt/V19200/ starting point), your
|
||||
<tt/ttys/ entry might look like this:
|
||||
|
||||
<tscreen><verb>
|
||||
ttyd0 "/usr/libexec/getty V19200" dialup on
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>/etc/rc.serial or /etc/rc.local</heading>
|
||||
<p>
|
||||
|
||||
High-speed modems, like V.32, V.32bis, and V.34 modems, need to use
|
||||
hardware (<tt>RTS/CTS</tt>) flow control. You can add <tt/stty/
|
||||
commands to <tt>/etc/rc.serial</tt> on FreeBSD 1.1.5.1 and up, or
|
||||
<tt>/etc/rc.local</tt> on FreeBSD 1.1, to set the hardware flow
|
||||
control flag in the FreeBSD kernel for the modem ports.
|
||||
|
||||
For example, on a sample FreeBSD 1.1.5.1 system,
|
||||
<tt>/etc/rc.serial</tt> reads:
|
||||
|
||||
<tscreen><verb>
|
||||
#!/bin/sh
|
||||
#
|
||||
# Serial port initial configuration
|
||||
|
||||
stty -f /dev/ttyid1 crtscts
|
||||
stty -f /dev/cuai01 crtscts
|
||||
</verb></tscreen>
|
||||
|
||||
which sets the <tt/termios/ flag <tt/crtscts/ on serial port #1's
|
||||
(<tt/COM2:/) dialin and dialout initialization devices.
|
||||
|
||||
On an old FreeBSD 1.1 system, these entries were added to
|
||||
/etc/rc.local to set the <tt/crtscts/ flag on the devices:
|
||||
|
||||
<tscreen><verb>
|
||||
# Set serial ports to use RTS/CTS flow control
|
||||
stty -f /dev/ttyd0 crtscts
|
||||
stty -f /dev/ttyd1 crtscts
|
||||
stty -f /dev/ttyd2 crtscts
|
||||
stty -f /dev/ttyd3 crtscts
|
||||
</verb></tscreen>
|
||||
|
||||
Since there is no initialization device special file on FreeBSD
|
||||
1.1, one has to just set the flags on the sole device special file and
|
||||
hope the flags are not cleared by a miscreant.
|
||||
|
||||
<sect1><heading>Modem Settings</heading>
|
||||
<p>
|
||||
|
||||
If you have a modem whose parameters may be permanently set in
|
||||
non-volatile RAM, you will need to use a terminal program (such as Telix
|
||||
under PC-DOS or <tt/tip/ under FreeBSD) to set the parameters.
|
||||
Connect to the modem using the same communications speed as the
|
||||
initial speed <tt/getty/ will use and configure the modem's
|
||||
non-volatile RAM to match these requirements:
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> <tt/CD/ asserted when connected
|
||||
|
||||
<item> <tt/DTR/ asserted for operation; dropping DTR hangs up line
|
||||
& resets modem
|
||||
|
||||
<item> <tt/CTS/ transmitted data flow control
|
||||
|
||||
<item> Disable <tt>XON/XOFF</tt> flow control
|
||||
|
||||
<item> <tt/RTS/ received data flow control
|
||||
|
||||
<item> Quiet mode (no result codes)
|
||||
|
||||
<item> No command echo
|
||||
|
||||
</itemize>
|
||||
|
||||
Please read the documentation for your modem to find out what commands
|
||||
and/or DIP switch settings you need to give it.
|
||||
|
||||
For example, to set the above parameters on a USRobotics Sportster
|
||||
14,400 external modem, one could give these commands to the modem:
|
||||
|
||||
<tscreen><verb>
|
||||
ATZ
|
||||
AT&C1&D2&H1&I0&R2&W
|
||||
</verb></tscreen>
|
||||
|
||||
You might also want to take this opportunity to adjust other settings
|
||||
in the modem, such as whether it will use V.42bis and/or MNP5
|
||||
compression.
|
||||
|
||||
The USR Sportster 14,400 external modem also has some DIP switches
|
||||
that need to be set; for other modems, perhaps you can use these
|
||||
settings as an example:
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> Switch 1: UP - DTR Normal
|
||||
|
||||
<item> Switch 2: Do not care (Verbal Result Codes/Numeric Result Codes)
|
||||
|
||||
<item> Switch 3: UP - Suppress Result Codes
|
||||
|
||||
<item> Switch 4: DOWN - No echo, offline commands
|
||||
|
||||
<item> Switch 5: UP - Auto Answer
|
||||
|
||||
<item> Switch 6: UP - Carrier Detect Normal
|
||||
|
||||
<item> Switch 7: UP - Load NVRAM Defaults
|
||||
|
||||
<item> Switch 8: Do not care (Smart Mode/Dumb Mode)
|
||||
|
||||
</itemize>
|
||||
|
||||
Result codes should be disabled/suppressed for dialup modems to avoid
|
||||
problems that can occur if <tt/getty/ mistakenly gives a <tt/login:/
|
||||
prompt to a modem that is in command mode and the modem echoes the
|
||||
command or returns a result code. I have heard this sequence can result
|
||||
in a extended, silly conversation between <tt/getty/ and the modem.
|
||||
|
||||
<sect2><heading>Locked-speed Config</heading>
|
||||
<p>
|
||||
|
||||
For a locked-speed configuration, you will need to configure the modem
|
||||
to maintain a constant modem-to-computer data rate independent of the
|
||||
communications rate. On a USR Sportster 14,400 external modem, these
|
||||
commands will lock the modem-to-computer data rate at the speed used
|
||||
to issue the commands:
|
||||
|
||||
<tscreen><verb>
|
||||
ATZ
|
||||
AT&B1&W
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>Matching-speed Config</heading>
|
||||
<p>
|
||||
|
||||
For a variable-speed configuration, you will need to configure your
|
||||
modem to adjust its serial port data rate to match the incoming call
|
||||
rate. On a USR Sportster 14,400 external modem, these commands will
|
||||
lock the modem's error-corrected data rate to the speed used to issue
|
||||
the commands, but allow the serial port rate to vary for
|
||||
non-error-corrected connections:
|
||||
|
||||
<tscreen><verb>
|
||||
ATZ
|
||||
AT&B2&W
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>Checking the Modem's Configuration</heading>
|
||||
<p>
|
||||
|
||||
Most high-speed modems provide commands to view the modem's current
|
||||
operating parameters in a somewhat human-readable fashion. On the USR
|
||||
Sportster 14,400 external modems, the command <tt/ATI5/ displays the
|
||||
settings that are stored in the non-volatile RAM. To see the true
|
||||
operating parameters of the modem (as influenced by the USR's DIP
|
||||
switch settings), use the commands <tt/ATZ/ and then <tt/ATI4/.
|
||||
|
||||
If you have a different brand of modem, check your modem's manual to
|
||||
see how to double-check your modem's configuration parameters.
|
||||
|
||||
<sect1><heading>Troubleshooting</heading>
|
||||
<p>
|
||||
|
||||
Here are a few steps you can follow to check out the dialup modem on
|
||||
your system.
|
||||
|
||||
<sect2><heading>Checking out the FreeBSD system</heading>
|
||||
<p>
|
||||
|
||||
Hook up your modem to your FreeBSD system, boot the system, and, if
|
||||
your modem has status indication lights, watch to see whether the
|
||||
modem's <tt/DTR/ indicator lights when the <tt/login:/ prompt appears
|
||||
on the system's console - if it lights up, that should mean that
|
||||
FreeBSD has started a <tt/getty/ process on the appropriate
|
||||
communications port and is waiting for the modem to accept a call.
|
||||
|
||||
If the <tt/DTR/ indicator doesn't light, login to the FreeBSD system
|
||||
through the console and issue a <tt/ps ax/ to see if FreeBSD is trying
|
||||
to run a <tt/getty/ process on the correct port. You should see a
|
||||
lines like this among the processes displayed:
|
||||
|
||||
<tscreen><verb>
|
||||
114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0
|
||||
115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1
|
||||
</verb></tscreen>
|
||||
|
||||
If you see something different, like this:
|
||||
|
||||
<tscreen><verb>
|
||||
114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0
|
||||
^^
|
||||
</verb></tscreen>
|
||||
|
||||
and the modem has not accepted a call yet, this means that <tt/getty/
|
||||
has completed its open on the communications port. This could
|
||||
indicate a problem with the cabling or a mis-configured modem, because
|
||||
<tt/getty/ should not be able to open the communications port until
|
||||
<tt/CD/ (carrier detect) has been asserted by the modem.
|
||||
|
||||
If you do not see any <tt/getty/ processes waiting to open the desired
|
||||
<tt/ttyd?/ port, double-check your entries in <tt>/etc/ttys</tt> to
|
||||
see if there are any mistakes there. Also, check the log file
|
||||
<tt>/var/log/messages</tt> to see if there are any log messages from
|
||||
<tt/init/ or <tt/getty/ regarding any problems. If there are any
|
||||
messages, triple-check the configuration files <tt>/etc/ttys</tt> and
|
||||
<tt>/etc/gettytab</tt>, as well as the appropriate device special
|
||||
files <tt>/dev/ttyd?</tt>, for any mistakes, missing entries, or
|
||||
missing device special files.
|
||||
|
||||
<sect2><heading>Try Dialing In</heading>
|
||||
<p>
|
||||
|
||||
Try dialing into the system; be sure to use 8 bits, no parity, 1 stop
|
||||
bit on the remote system. If you do not get a prompt right away, or
|
||||
get garbage, try pressing <tt><Enter></tt> about once per
|
||||
second. If you still do not see a <tt/login:/ prompt after a while,
|
||||
try sending a <tt>BREAK</tt>. If you are using a high-speed modem to
|
||||
do the dialing, try dialing again after locking the dialing modem's
|
||||
interface speed (via <tt>AT&B1</tt> on a USR Sportster, for
|
||||
example).
|
||||
|
||||
If you still cannot get a <tt/login:/ prompt, check
|
||||
<tt>/etc/gettytab</tt> again and double-check that
|
||||
|
||||
<itemize>
|
||||
<item> The initial capability name specified in <tt>/etc/ttys</tt> for
|
||||
the line matches a name of a capability in <tt>/etc/gettytab</tt>
|
||||
|
||||
<item> Each <tt/nx=/ entry matches another <tt/gettytab/ capability
|
||||
name
|
||||
|
||||
<item> Each <tt/tc=/ entry matches another <tt/gettytab/ capability
|
||||
name
|
||||
|
||||
</itemize>
|
||||
|
||||
If you dial but the modem on the FreeBSD system will not answer, make
|
||||
sure that the modem is configured to answer the phone when <tt/DTR/ is
|
||||
asserted. If the modem seems to be configured correctly, verify that
|
||||
the <tt/DTR/ line is asserted by checking the modem's indicator lights
|
||||
(if it has any).
|
||||
|
||||
If you have gone over everything several times and it still does not work,
|
||||
take a break and come back to it later. If it still does not work,
|
||||
perhaps you can send an electronic mail message to the &a.questions
|
||||
describing your modem and your problem, and the good folks on the list will
|
||||
try to help.
|
||||
|
||||
<sect1><heading>Acknowledgments</heading>
|
||||
<p>
|
||||
|
||||
Thanks to these people for comments and advice:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag>&a.kelly</tag> for a number of good suggestions
|
||||
|
||||
</descrip>
|
||||
|
||||
|
||||
@ -1,163 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Diskless operation<label id="diskless"></heading>
|
||||
|
||||
<p><em>Contributed by &a.martin;.</em>
|
||||
|
||||
<tt>netboot.com/netboot.rom</tt> 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)
|
||||
|
||||
<sect1>
|
||||
<heading>Setup Instructions</heading>
|
||||
|
||||
<p><enum>
|
||||
<item> 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:
|
||||
<itemize>
|
||||
<item>HP9000/8xx running HP-UX 9.04 or later (pre
|
||||
9.04 doesn't work)</item>
|
||||
<item>Sun/Solaris 2.3. (you may need to get
|
||||
bootp)</item>
|
||||
</itemize>
|
||||
|
||||
<item>Set up a bootp server to provide the client with
|
||||
IP, gateway, netmask.
|
||||
<tscreen><verb>
|
||||
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:
|
||||
</verb></tscreen></item>
|
||||
|
||||
<item>Set up a TFTP server (on same machine as bootp
|
||||
server) to provide booting information to client.
|
||||
The name of this file is <tt>cfg.X.X.X.X</tt> (or
|
||||
<tt>/tftpboot/cfg.X.X.X.X</tt>, it will try both)
|
||||
where <tt>X.X.X.X</tt> 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:
|
||||
<tscreen><verb>
|
||||
help - print help list
|
||||
ip <X.X.X.X> - print/set client's IP address
|
||||
server <X.X.X.X> - print/set bootp/tftp server address
|
||||
netmask <X.X.X.X> - print/set netmask
|
||||
hostname <name> - print/set hostname
|
||||
kernel <name> - print/set kernel name
|
||||
rootfs <ip:/fs> - print/set root filesystem
|
||||
swapfs <ip:/fs> - print/set swap filesystem
|
||||
swapsize <size> - set diskless swapsize in Kbytes
|
||||
diskboot - boot from disk
|
||||
autoboot - continue boot process
|
||||
trans <on|off> - turn transceiver on|off
|
||||
flags [bcdhsv] - set boot flags
|
||||
</verb></tscreen>
|
||||
A typical completely diskless cfg file might contain:
|
||||
<tscreen><verb>
|
||||
rootfs 192.1.2.3:/rootfs/myclient
|
||||
swapfs 192.1.2.3:/swapfs
|
||||
swapsize 20000
|
||||
hostname myclient.mydomain
|
||||
</verb></tscreen>
|
||||
A cfg file for a machine with local swap might contain:
|
||||
<tscreen><verb>
|
||||
rootfs 192.1.2.3:/rootfs/myclient
|
||||
hostname myclient.mydomain
|
||||
</verb></tscreen>
|
||||
|
||||
<item>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 <tt>/etc/exports</tt> file on FreeBSD might
|
||||
look like:
|
||||
<tscreen><verb>
|
||||
/rootfs/myclient -maproot=0:0 myclient.mydomain
|
||||
/swapfs -maproot=0:0 myclient.mydomain
|
||||
</verb></tscreen>
|
||||
|
||||
And on HP-UX:
|
||||
<tscreen><verb>
|
||||
/rootfs/myclient -root=myclient.mydomain
|
||||
/swapfs -root=myclient.mydomain
|
||||
</verb></tscreen>
|
||||
|
||||
<item>If you are swapping over NFS (completely diskless
|
||||
configuration) create a swap file for your client
|
||||
using <tt>dd</tt>. If your <tt>swapfs</tt> command has the
|
||||
arguments <tt>/swapfs</tt> and the size 20000 as in the
|
||||
example above, the swapfile for myclient will be called
|
||||
<tt>/swapfs/swap.X.X.X.X</tt> where <tt>X.X.X.X</tt>
|
||||
is the client's IP addr, eg:
|
||||
<tscreen><verb>
|
||||
# dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000
|
||||
</verb></tscreen>
|
||||
|
||||
Also, the client's swap space might contain sensitive
|
||||
information once swapping starts, so make sure to
|
||||
restrict read and write access to this file to prevent
|
||||
unauthorized access:
|
||||
<tscreen><verb>
|
||||
# chmod 0600 /swapfs/swap.192.1.2.4
|
||||
</verb></tscreen>
|
||||
|
||||
<item> Unpack the root filesystem in the directory the
|
||||
client will use for its root filesystem
|
||||
(<tt>/rootfs/myclient</tt> in the example above).
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> 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.
|
||||
|
||||
<item> When extracting <tt>/dev</tt> in
|
||||
<tt>/rootfs/myclient</tt>, 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
|
||||
<tt>/dev</tt> and do a "<tt>sh ./MAKEDEV
|
||||
all</tt>" from the client to fix this.
|
||||
</itemize>
|
||||
|
||||
<item>Run <tt>netboot.com</tt> on the client or make an EPROM
|
||||
from the <tt>netboot.rom</tt> file
|
||||
</enum>
|
||||
|
||||
<sect1>
|
||||
<heading>Using Shared <tt>/</tt> and <tt>/usr</tt> filesystems</heading>
|
||||
|
||||
<p>At present there isn't an officially sanctioned way of
|
||||
doing this, although I have been using a shared <tt>/usr</tt>
|
||||
filesystem and individual <tt>/</tt> filesystems for each client.
|
||||
If anyone has any suggestions on how to do this cleanly,
|
||||
please let me and/or the &a.core; know.
|
||||
|
||||
<sect1>
|
||||
<heading>Compiling netboot for specific setups</heading>
|
||||
|
||||
<p>Netboot can be compiled to support NE1000/2000 cards by
|
||||
changing the configuration in
|
||||
<tt>/sys/i386/boot/netboot/Makefile</tt>. See the
|
||||
comments at the top of this file.
|
||||
|
||||
@ -1,535 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
]>
|
||||
-->
|
||||
<sect><heading>DMA: What it is and how it works<label id="dma"></heading>
|
||||
|
||||
<p><em>Copyright © 1995 &a.uhclem;, All Rights Reserved.<newline>
|
||||
10 December 1996.</em>
|
||||
|
||||
<!-- Version 1(3) -->
|
||||
|
||||
Direct Memory Access (DMA) is a method of allowing data to
|
||||
be moved from one location to another in a computer without
|
||||
intervention from the central processor (CPU).
|
||||
|
||||
The way that the DMA function is implemented varies between
|
||||
computer architectures, so this discussion will limit
|
||||
itself to the implementation and workings of the DMA
|
||||
subsystem on the IBM Personal Computer (PC), the IBM PC/AT
|
||||
and all of its successors and clones.
|
||||
|
||||
The PC DMA subsystem is based on the Intel 8237 DMA
|
||||
controller. The 8237 contains four DMA channels that can
|
||||
be programmed independently and any one of the channels may be
|
||||
active at any moment. These channels are numbered 0, 1, 2
|
||||
and 3. Starting with the PC/AT, IBM added a second 8237
|
||||
chip, and numbered those channels 4, 5, 6 and 7.
|
||||
|
||||
The original DMA controller (0, 1, 2 and 3) moves one byte
|
||||
in each transfer. The second DMA controller (4, 5, 6, and
|
||||
7) moves 16-bits from two adjacent memory locations in each
|
||||
transfer, with the first byte always coming from an even-numbered
|
||||
address. The two controllers are identical components and the
|
||||
difference in transfer size is caused by the way the second
|
||||
controller is wired into the system.
|
||||
|
||||
The 8237 has two electrical signals for each channel, named
|
||||
DRQ and -DACK. There are additional signals with the
|
||||
names HRQ (Hold Request), HLDA (Hold Acknowledge), -EOP
|
||||
(End of Process), and the bus control signals -MEMR (Memory
|
||||
Read), -MEMW (Memory Write), -IOR (I/O Read), and -IOW (I/O
|
||||
Write).
|
||||
|
||||
The 8237 DMA is known as a ``fly-by'' DMA controller. This
|
||||
means that the data being moved from one location to
|
||||
another does not pass through the DMA chip and is not
|
||||
stored in the DMA chip. Subsequently, the DMA can only
|
||||
transfer data between an I/O port and a memory address, but
|
||||
not between two I/O ports or two memory locations.
|
||||
|
||||
<quote><em>Note:</em> The 8237 does allow two channels to
|
||||
be connected together to allow memory-to-memory DMA
|
||||
operations in a non-``fly-by'' mode, but nobody in the PC
|
||||
industry uses this scarce resource this way since it is
|
||||
faster to move data between memory locations using the
|
||||
CPU.</quote>
|
||||
|
||||
In the PC architecture, each DMA channel is normally
|
||||
activated only when the hardware that uses that DMA
|
||||
requests a transfer by asserting the DRQ line for that
|
||||
channel.
|
||||
|
||||
|
||||
<sect1><heading>A Sample DMA transfer</heading>
|
||||
|
||||
<p>Here is an example of the steps that occur to cause a
|
||||
DMA transfer. In this example, the floppy disk
|
||||
controller (FDC) has just read a byte from a diskette and
|
||||
wants the DMA to place it in memory at location
|
||||
0x00123456. The process begins by the FDC asserting the
|
||||
DRQ2 signal to alert the DMA controller.
|
||||
|
||||
The DMA controller will note that the DRQ2 signal is asserted.
|
||||
The DMA controller will then make sure that DMA channel 2
|
||||
has been programmed and is enabled. The DMA controller
|
||||
also makes sure that none of the other DMA channels are active
|
||||
or have a higher priority. Once these checks are
|
||||
complete, the DMA asks the CPU to release the bus so that
|
||||
the DMA may use the bus. The DMA requests the bus by
|
||||
asserting the HRQ signal which goes to the CPU.
|
||||
|
||||
The CPU detects the HRQ signal, and will complete
|
||||
executing the current instruction. Once the processor
|
||||
has reached a state where it can release the bus, it
|
||||
will. Now all of the signals normally generated by the
|
||||
CPU (-MEMR, -MEMW, -IOR, -IOW and a few others) are
|
||||
placed in a tri-stated condition (neither high or low)
|
||||
and then the CPU asserts the HLDA signal which tells the
|
||||
DMA controller that it is now in charge of the bus.
|
||||
|
||||
Depending on the processor, the CPU may be able to
|
||||
execute a few additional instructions now that it no
|
||||
longer has the bus, but the CPU will eventually have to
|
||||
wait when it reaches an instruction that must read
|
||||
something from memory that is not in the internal
|
||||
processor cache or pipeline.
|
||||
|
||||
Now that the DMA ``is in charge'', the DMA activates its
|
||||
-MEMR, -MEMW, -IOR, -IOW output signals, and the address
|
||||
outputs from the DMA are set to 0x3456, which will be
|
||||
used to direct the byte that is about to transferred to a
|
||||
specific memory location.
|
||||
|
||||
The DMA will then let the device that requested the DMA
|
||||
transfer know that the transfer is commencing. This is
|
||||
done by asserting the -DACK signal, or in the case of the
|
||||
floppy disk controller, -DACK2 is asserted.
|
||||
|
||||
The floppy disk controller is now responsible for placing
|
||||
the byte to be transferred on the bus Data lines. Unless
|
||||
the floppy controller needs more time to get the data
|
||||
byte on the bus (and if the peripheral does need more time it
|
||||
alerts the DMA via the READY signal), the DMA will wait
|
||||
one DMA clock, and then de-assert the -MEMW and -IOR
|
||||
signals so that the memory will latch and store the byte
|
||||
that was on the bus, and the FDC will know that the byte
|
||||
has been transferred.
|
||||
|
||||
Since the DMA cycle only transfers a single byte at a
|
||||
time, the FDC now drops the DRQ2 signal, so that the DMA
|
||||
knows it is no longer needed. The DMA will de-assert the
|
||||
-DACK2 signal, so that the FDC knows it must stop placing
|
||||
data on the bus.
|
||||
|
||||
The DMA will now check to see if any of the other DMA
|
||||
channels have any work to do. If none of the channels
|
||||
have their DRQ lines asserted, the DMA controller has
|
||||
completed its work and will now tri-state the -MEMR,
|
||||
-MEMW, -IOR, -IOW and address signals.
|
||||
|
||||
Finally, the DMA will de-assert the HRQ signal. The CPU
|
||||
sees this, and de-asserts the HOLDA signal. Now the CPU
|
||||
activates its -MEMR, -MEMW, -IOR, -IOW and address lines,
|
||||
and it resumes executing instructions and accessing main
|
||||
memory and the peripherals.
|
||||
|
||||
For a typical floppy disk sector, the above process is
|
||||
repeated 512 times, once for each byte. Each time a byte
|
||||
is transferred, the address register in the DMA is
|
||||
incremented and the counter that shows how many bytes are
|
||||
to be transferred is decremented.
|
||||
|
||||
When the counter reaches zero, the DMA asserts the EOP
|
||||
signal, which indicates that the counter has reached zero
|
||||
and no more data will be transferred until the DMA
|
||||
controller is reprogrammed by the CPU. This event is
|
||||
also called the Terminal Count (TC). There is only one
|
||||
EOP signal, because only one DMA channel can be active at
|
||||
any instant.
|
||||
|
||||
If a peripheral wants to generate an interrupt when the
|
||||
transfer of a buffer is complete, it can test for its
|
||||
-DACK signal and the EOP signal both being asserted at
|
||||
the same time. When that happens, it means the DMA will not
|
||||
transfer any more information for that peripheral without
|
||||
intervention by the CPU. The peripheral can then assert
|
||||
one of the interrupt signals to get the processors'
|
||||
attention. The DMA chip itself is not capable of
|
||||
generating an interrupt. The peripheral and its
|
||||
associated hardware is responsible for generating any
|
||||
interrupt that occurs.
|
||||
|
||||
It is important to understand that although the CPU
|
||||
always releases the bus to the DMA when the DMA makes the
|
||||
request, this action is invisible to both applications
|
||||
and the operating systems, except for slight changes in
|
||||
the amount of time the processor takes to execute
|
||||
instructions when the DMA is active. Subsequently, the
|
||||
processor must poll the peripheral, poll the registers in
|
||||
the DMA chip, or receive an interrupt from the peripheral
|
||||
to know for certain when a DMA transfer has completed.
|
||||
|
||||
|
||||
<sect1><heading>DMA Page Registers and 16Meg address space limitations</heading>
|
||||
|
||||
<p>You may have noticed earlier that instead of the DMA
|
||||
setting the address lines to 0x00123456 as we said
|
||||
earlier, the DMA only set 0x3456. The reason for this
|
||||
takes a bit of explaining.
|
||||
|
||||
When the original IBM PC was designed, IBM elected to use
|
||||
both DMA and interrupt controller chips that were
|
||||
designed for use with the 8085, an 8-bit processor with
|
||||
an address space of 16 bits (64K). Since the IBM PC
|
||||
supported more than 64K of memory, something had to be
|
||||
done to allow the DMA to read or write memory locations
|
||||
above the 64K mark. What IBM did to solve this problem
|
||||
was to add a latch for each DMA channel that holds the
|
||||
upper bits of the address to be read to or written from.
|
||||
Whenever a DMA channel is active, the contents of that
|
||||
latch are written to the address bus and kept there until
|
||||
the DMA operation for the channel ends. These latches
|
||||
are called ``Page Registers''.
|
||||
|
||||
So for our example above, the DMA would put the 0x3456
|
||||
part of the address on the bus, and the Page Register for
|
||||
DMA channel 2 would put 0x0012xxxx on the bus. Together,
|
||||
these two values form the complete address in memory that
|
||||
is to be accessed.
|
||||
|
||||
Because the Page Register latch is independent of the DMA
|
||||
chip, the area of memory to be read or written must not
|
||||
span a 64K physical boundary. If the DMA accesses memory
|
||||
location 0xffff, after the transfer the DMA will then increment
|
||||
the address register and the DMA will access the next byte at
|
||||
location 0x0000, not 0x10000. The results of letting this
|
||||
happen are probably not intended.
|
||||
|
||||
<quote><em>Note:</em> ``Physical'' 64K boundaries should
|
||||
not be confused with 8086-mode 64K ``Segments'', which
|
||||
are created by adding a segment register with an offset
|
||||
register. Page Registers have no address overlap.</quote>
|
||||
|
||||
To further complicate matters, the external DMA address
|
||||
latches on the PC/AT hold only eight bits, so that gives
|
||||
us 8+16=24 bits, which means that the DMA can only point
|
||||
at memory locations between 0 and 16Meg. For newer
|
||||
computers that allow more than 16Meg of memory, the
|
||||
PC-compatible DMA cannot access memory locations above 16Meg.
|
||||
|
||||
To get around this restriction, operating systems will
|
||||
reserve a buffer in an area below 16Meg that also does not
|
||||
span a physical 64K boundary. Then the DMA will be
|
||||
programmed to transfer data from the peripheral and into that
|
||||
buffer. Once the DMA has moved the data into this buffer,
|
||||
the operating system will then copy the data from the buffer
|
||||
to the address where the data is really supposed to be stored.
|
||||
|
||||
When writing data from an address above 16Meg to a
|
||||
DMA-based peripheral, the data must be first copied from
|
||||
where it resides into a buffer located below 16Meg, and
|
||||
then the DMA can copy the data from the buffer to the
|
||||
hardware. In FreeBSD, these reserved buffers are called
|
||||
``Bounce Buffers''. In the MS-DOS world, they are
|
||||
sometimes called ``Smart Buffers''.
|
||||
|
||||
|
||||
<sect1><heading>DMA Operational Modes and Settings</heading>
|
||||
|
||||
<p>The 8237 DMA can be operated in several modes. The main
|
||||
ones are:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/Single/ A single byte (or word) is transferred.
|
||||
The DMA must release and re-acquire the bus for each
|
||||
additional byte. This is commonly-used by devices
|
||||
that cannot transfer the entire block of data
|
||||
immediately. The peripheral will request the DMA
|
||||
each time it is ready for another transfer.
|
||||
|
||||
The floppy disk controller only has a one-byte
|
||||
buffer, so it uses this mode.
|
||||
|
||||
|
||||
<tag>Block/Demand</tag> Once the DMA acquires the
|
||||
system bus, an entire block of data is transferred,
|
||||
up to a maximum of 64K. If the peripheral needs
|
||||
additional time, it can assert the READY signal to
|
||||
suspend the transfer briefly. READY should not be
|
||||
used excessively, and for slow peripheral transfers,
|
||||
the Single Transfer Mode should be used instead.
|
||||
|
||||
The difference between Block and Demand is that once a
|
||||
Block transfer is started, it runs until the transfer
|
||||
count reaches zero. DRQ only needs to be asserted
|
||||
until -DACK is asserted. Demand Mode will transfer
|
||||
one more bytes until DRQ is de-asserted and the DMA
|
||||
pauses the transfer and releases the bus back to the CPU.
|
||||
When DRQ is asserted later, the transfer resumes where
|
||||
it was suspended.
|
||||
|
||||
Older hard disk controllers used Demand Mode until
|
||||
CPU speeds increased to the point that it was more
|
||||
efficient to transfer the data using the CPU, particularly
|
||||
if the memory locations used in the transfer were above the
|
||||
16Meg mark.
|
||||
|
||||
|
||||
<tag>Cascade</tag> This mechanism allows a DMA channel
|
||||
to request the bus, but then the attached peripheral
|
||||
device is responsible for placing the addressing
|
||||
information on the bus instead of the DMA. This is also
|
||||
known as ``Bus Mastering''.
|
||||
|
||||
When a DMA channel in Cascade Mode receives control
|
||||
of the bus, the DMA does not place addresses and I/O
|
||||
control signals on the bus like the DMA normally does
|
||||
when it is active. Instead, the DMA only asserts the
|
||||
-DACK signal for this channel.
|
||||
|
||||
At this point it is up to the device connected to that DMA
|
||||
channel to provide address and bus control signals.
|
||||
The peripheral has complete control over the system
|
||||
bus, and can do reads and/or writes to any address
|
||||
below 16Meg. When the peripheral is finished with
|
||||
the bus, it de-asserts the DRQ line, and the DMA
|
||||
controller can return control to the CPU or to some
|
||||
other DMA channel.
|
||||
|
||||
Cascade Mode can be used to chain multiple DMA
|
||||
controllers together, and this is exactly what DMA
|
||||
Channel 4 is used for in the PC. When a peripheral
|
||||
requests the bus on DMA channels 0, 1, 2 or 3, the
|
||||
slave DMA controller asserts HLDREQ, but this wire is
|
||||
actually connected to DRQ4 on the primary DMA
|
||||
controller. The primary DMA controller then requests
|
||||
the bus from the CPU using HLDREQ. Once the bus is
|
||||
granted, -DACK4 is asserted, and that wire is
|
||||
actually connected to the HLDA signal on the slave
|
||||
DMA controller. The slave DMA controller then
|
||||
transfers data for the DMA channel that requested it,
|
||||
or the slave DMA may grant the bus to a peripheral
|
||||
that wants to perform its own bus-mastering, such as
|
||||
a SCSI controller.
|
||||
|
||||
Because of this wiring arrangement, only DMA channels
|
||||
0, 1, 2, 3, 5, 6 and 7 are usable on PC/AT systems.
|
||||
|
||||
<quote><em>Note:</em> DMA channel 0 was reserved for
|
||||
refresh operations in early IBM PC computers, but
|
||||
is generally available for use by peripherals in
|
||||
modern systems.</quote>
|
||||
|
||||
When a peripheral is performing Bus Mastering, it is
|
||||
important that the peripheral transmit data to or
|
||||
from memory constantly while it holds the system bus.
|
||||
If the peripheral cannot do this, it must release the
|
||||
bus frequently so that the system can perform refresh
|
||||
operations on main memory.
|
||||
|
||||
The Dynamic RAM used in all PCs for main memory must be
|
||||
accessed frequently to keep the bits stored in the
|
||||
components "charged". Dynamic RAM essentially consists
|
||||
of millions of capacitors with each one holding one bit
|
||||
of data. These capacitors are charged with power to
|
||||
represent a "1" or drained to represent a "0". Because
|
||||
all capacitors leak, power must be added at regular intervals
|
||||
to keep the "1" values intact. The RAM chips actually handle
|
||||
the task of pumping power back into all of the appropriate
|
||||
locations in RAM, but they must be told when to do it by
|
||||
the rest of the computer so that the refresh activity won't
|
||||
interfere with the computer wanting to access RAM normally.
|
||||
If the computer is unable to refresh memory, the contents
|
||||
of memory will become corrupted in just a few milliseconds.
|
||||
|
||||
Since memory read and write cycles ``count'' as refresh
|
||||
cycles (a dynamic RAM refresh cycle is actually an incomplete
|
||||
memory read cycle), as long as the peripheral
|
||||
controller continues reading or writing data to
|
||||
sequential memory locations, that action will refresh
|
||||
all of memory.
|
||||
|
||||
Bus-mastering is found in some SCSI host interfaces and
|
||||
other high-performance peripheral controllers.
|
||||
|
||||
|
||||
<tag>Autoinitialize</tag> This mode causes the DMA to
|
||||
perform Byte, Block or Demand transfers, but when the
|
||||
DMA transfer counter reaches zero, the counter and
|
||||
address are set back to where they were when the DMA
|
||||
channel was originally programmed. This means that
|
||||
as long as the peripheral requests transfers, they will
|
||||
be granted. It is up to the CPU to move new data
|
||||
into the fixed buffer ahead of where the DMA is about
|
||||
to transfer it when doing output operations, and read new
|
||||
data out of the buffer behind where the DMA is writing
|
||||
when doing input operations.
|
||||
|
||||
This technique is frequently used on audio devices that
|
||||
have small or no hardware ``sample'' buffers. There is
|
||||
additional CPU overhead to manage this ``circular'' buffer,
|
||||
but in some cases this may be the only way to eliminate the
|
||||
latency that occurs when the DMA counter reaches zero
|
||||
and the DMA stops transfers until it is reprogrammed.
|
||||
</descrip>
|
||||
|
||||
<sect1><heading>Programming the DMA</heading>
|
||||
|
||||
<p>The DMA channel that is to be programmed should always
|
||||
be ``masked'' before loading any settings. This is because
|
||||
the hardware might unexpectedly assert DRQ, and the DMA might
|
||||
respond, even though not all of the parameters have been
|
||||
loaded or updated.
|
||||
|
||||
Once masked, the host must specify the direction of the
|
||||
transfer (memory-to-I/O or I/O-to-memory), what mode of
|
||||
DMA operation is to be used for the transfer (Single,
|
||||
Block, Demand, Cascade, etc), and finally the address and
|
||||
length of the transfer are loaded. The length that is
|
||||
loaded is one less than the amount you expect the DMA to
|
||||
transfer. The LSB and MSB of the address and length are
|
||||
written to the same 8-bit I/O port, so another port must
|
||||
be written to first to guarantee that the DMA accepts the
|
||||
first byte as the LSB and the second byte as the MSB of
|
||||
the length and address.
|
||||
|
||||
Then, be sure to update the Page Register, which is
|
||||
external to the DMA and is accessed through a different
|
||||
set of I/O ports.
|
||||
|
||||
Once all the settings are ready, the DMA channel can be
|
||||
un-masked. That DMA channel is now considered to be
|
||||
``armed'', and will respond when DRQ is asserted.
|
||||
|
||||
Refer to a hardware data book for precise programming
|
||||
details for the 8237. You will also need to refer to the
|
||||
I/O port map for the PC system, which describes where
|
||||
the DMA and Page Register ports are located. A complete
|
||||
table is located below.
|
||||
|
||||
|
||||
<sect1><heading>DMA Port Map</heading>
|
||||
|
||||
<p>All systems based on the IBM-PC and PC/AT have the DMA
|
||||
hardware located at the same I/O ports. The complete
|
||||
list is provided below. Ports assigned to DMA Controller
|
||||
#2 are undefined on non-AT designs.
|
||||
|
||||
<sect2><heading>0x00 - 0x1f DMA Controller #1 (Channels 0, 1, 2 and 3)</heading>
|
||||
|
||||
<p>DMA Address and Count Registers
|
||||
|
||||
<verb>
|
||||
0x00 write Channel 0 starting address
|
||||
0x00 read Channel 0 current address
|
||||
0x02 write Channel 0 starting word count
|
||||
0x02 read Channel 0 remaining word count
|
||||
|
||||
0x04 write Channel 1 starting address
|
||||
0x04 read Channel 1 current address
|
||||
0x06 write Channel 1 starting word count
|
||||
0x06 read Channel 1 remaining word count
|
||||
|
||||
0x08 write Channel 2 starting address
|
||||
0x08 read Channel 2 current address
|
||||
0x0a write Channel 2 starting word count
|
||||
0x0a read Channel 2 remaining word count
|
||||
|
||||
0x0c write Channel 3 starting address
|
||||
0x0c read Channel 3 current address
|
||||
0x0e write Channel 3 starting word count
|
||||
0x0e read Channel 3 remaining word count
|
||||
</verb>
|
||||
|
||||
DMA Command Registers
|
||||
|
||||
<verb>
|
||||
0x10 write Command Register
|
||||
0x10 read Status Register
|
||||
0x12 write Request Register
|
||||
0x12 read -
|
||||
0x14 write Single Mask Register Bit
|
||||
0x14 read -
|
||||
0x16 write Mode Register
|
||||
0x16 read -
|
||||
0x18 write Clear LSB/MSB Flip-Flop
|
||||
0x18 read -
|
||||
0x1a write Master Clear/Reset
|
||||
0x1a read Temporary Register
|
||||
0x1c write Clear Mask Register
|
||||
0x1c read -
|
||||
0x1e write Write All Mask Register Bits
|
||||
0x1e read -
|
||||
</verb>
|
||||
|
||||
<sect2><heading>0xc0 - 0xdf DMA Controller #2 (Channels 4, 5, 6 and 7)</heading>
|
||||
|
||||
<p>DMA Address and Count Registers
|
||||
|
||||
<verb>
|
||||
0xc0 write Channel 4 starting address
|
||||
0xc0 read Channel 4 current address
|
||||
0xc2 write Channel 4 starting word count
|
||||
0xc2 read Channel 4 remaining word count
|
||||
|
||||
0xc4 write Channel 5 starting address
|
||||
0xc4 read Channel 5 current address
|
||||
0xc6 write Channel 5 starting word count
|
||||
0xc6 read Channel 5 remaining word count
|
||||
|
||||
0xc8 write Channel 6 starting address
|
||||
0xc8 read Channel 6 current address
|
||||
0xca write Channel 6 starting word count
|
||||
0xca read Channel 6 remaining word count
|
||||
|
||||
0xcc write Channel 7 starting address
|
||||
0xcc read Channel 7 current address
|
||||
0xce write Channel 7 starting word count
|
||||
0xce read Channel 7 remaining word count
|
||||
</verb>
|
||||
|
||||
DMA Command Registers
|
||||
|
||||
<verb>
|
||||
0xd0 write Command Register
|
||||
0xd0 read Status Register
|
||||
0xd2 write Request Register
|
||||
0xd2 read -
|
||||
0xd4 write Single Mask Register Bit
|
||||
0xd4 read -
|
||||
0xd6 write Mode Register
|
||||
0xd6 read -
|
||||
0xd8 write Clear LSB/MSB Flip-Flop
|
||||
0xd8 read -
|
||||
0xda write Master Clear/Reset
|
||||
0xda read Temporary Register
|
||||
0xdc write Clear Mask Register
|
||||
0xdc read -
|
||||
0xde write Write All Mask Register Bits
|
||||
0xde read -
|
||||
</verb>
|
||||
|
||||
<sect2><heading>0x80 - 0x9f DMA Page Registers</heading>
|
||||
|
||||
<p><verb>
|
||||
0x87 r/w DMA Channel 0
|
||||
0x83 r/w DMA Channel 1
|
||||
0x81 r/w DMA Channel 2
|
||||
0x82 r/w DMA Channel 3
|
||||
|
||||
0x8b r/w DMA Channel 5
|
||||
0x89 r/w DMA Channel 6
|
||||
0x8a r/w DMA Channel 7
|
||||
|
||||
0x8f Refresh
|
||||
</verb>
|
||||
|
||||
@ -1,459 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt>
|
||||
<heading>Resources on the Internet<label id="eresources"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;.</em>
|
||||
|
||||
<p>The rapid pace of FreeBSD progress makes print media impractical as a
|
||||
means of following the latest developments. Electronic resources are
|
||||
the best, if not often the only, way stay informed of the latest advances.
|
||||
Since FreeBSD is a volunteer effort, the user community itself also
|
||||
generally serves as a `technical support department' of sorts, with
|
||||
electronic mail and USENET news being the most effective way of reaching
|
||||
that community.
|
||||
|
||||
The most important points of contact with the FreeBSD
|
||||
user community are outlined below. If you are aware of other
|
||||
resources not mentioned here, please send them to the &a.doc
|
||||
so that they may also be included.
|
||||
|
||||
<sect>
|
||||
<heading>Mailing lists<label id="eresources:mail"></heading>
|
||||
|
||||
<p>Though many of the FreeBSD development members read USENET, we cannot
|
||||
always guarantee that we will get to your questions in a timely fashion
|
||||
(or at all) if you post them only to one of the comp.unix.bsd.freebsd.*
|
||||
groups. By addressing your questions to the appropriate mailing list
|
||||
you will reach both us and a concentrated FreeBSD audience, invariably
|
||||
assuring a better (or at least faster) response.
|
||||
|
||||
<p>The charters for the various lists are given at the bottom of this
|
||||
document. <bf>Please read the charter before joining or sending
|
||||
mail to any list</bf>. Most of our list subscribers now receive many hundreds
|
||||
of FreeBSD related messages every day, and by setting down charters
|
||||
and rules for proper use we are striving to keep the signal-to-noise ratio
|
||||
of the lists high. To do less would see the mailing lists ultimately fail
|
||||
as an effective communications medium for the project.
|
||||
|
||||
Archives are kept for all of the mailing lists and can be searched
|
||||
using the <url url="http://www.FreeBSD.ORG/search.html"
|
||||
name="FreeBSD World Wide Web server">. The keyword searchable archive
|
||||
offers an excellent way of finding answers to frequently asked
|
||||
questions and should be consulted before posting a question.
|
||||
|
||||
<sect1><heading>List summary<label id="eresources:summary"></heading>
|
||||
|
||||
<p><bf>General lists:</bf> The following are general lists which
|
||||
anyone is free to join:
|
||||
<verb>
|
||||
List Purpose
|
||||
----------------------------------------------------------------------
|
||||
freebsd-announce Important events and project milestones
|
||||
freebsd-bugs Bug reports
|
||||
freebsd-chat Non-technical items related to the FreeBSD community
|
||||
freebsd-current Discussion concerning the use of FreeBSD-current
|
||||
freebsd-stable Discussion concerning the use of FreeBSD-stable
|
||||
freebsd-isp Issues for Internet Service Providers using FreeBSD
|
||||
freebsd-questions User questions
|
||||
</verb>
|
||||
|
||||
<bf>Technical lists:</bf> The following lists are for technical discussion.
|
||||
You should read the charter for each list carefully before joining or
|
||||
sending mail to one as there are firm guidelines for their use and content.
|
||||
<verb>
|
||||
List Purpose
|
||||
----------------------------------------------------------------------
|
||||
freebsd-doc The FreeBSD Documentation project
|
||||
freebsd-emulation Emulation of other systems such as Linux/DOS/Windows
|
||||
freebsd-fs Filesystems
|
||||
freebsd-hackers General technical discussion
|
||||
freebsd-hardware General discussion of hardware for running FreeBSD
|
||||
freebsd-mobile Discussions about mobile computing
|
||||
freebsd-multimedia Multimedia discussion
|
||||
freebsd-platforms Concerning ports to non-Intel architecture platforms
|
||||
freebsd-ports Discussion of the ports collection
|
||||
freebsd-security Security issues
|
||||
freebsd-security-notifications
|
||||
Security notifications (moderated mailing list)
|
||||
freebsd-scsi The SCSI subsystem
|
||||
freebsd-smp Design discussions for [A]Symmetric MultiProcessing
|
||||
</verb>
|
||||
|
||||
<bf>Limited lists:</bf> The following lists require approval from
|
||||
<url url="mailto:core@freebsd.org" name="core@FreeBSD.ORG"> to join,
|
||||
though anyone is free to send messages to them which fall within the
|
||||
scope of their charters. It is also a good idea establish a presence
|
||||
in the technical lists before asking to join one of these limited lists.
|
||||
<verb>
|
||||
List Purpose
|
||||
----------------------------------------------------------------------
|
||||
freebsd-admin Administrative issues
|
||||
freebsd-arch Architecture and design discussions
|
||||
freebsd-core FreeBSD core team
|
||||
freebsd-hubs People running mirror sites (infrastructural support)
|
||||
freebsd-install Installation development
|
||||
freebsd-user-groups User group coordination
|
||||
</verb>
|
||||
|
||||
<bf>CVS lists:</bf> The following lists are for people interested in
|
||||
seeing the log messages for changes to various areas of the source tree.
|
||||
They are <bf>Read-Only</bf> lists and should not have mail sent to them.
|
||||
|
||||
<verb>
|
||||
List name Source area Area Description (source for)
|
||||
----------------------------------------------------------------------
|
||||
cvs-CVSROOT /usr/src/[A-Z]* Top level /usr/src file changes
|
||||
cvs-all /usr/src All changes to the tree (superset)
|
||||
cvs-bin /usr/src/bin System binaries
|
||||
cvs-etc /usr/src/etc System files
|
||||
cvs-games /usr/src/games Games
|
||||
cvs-gnu /usr/src/gnu GPL'd utilities
|
||||
cvs-include /usr/src/include Include files
|
||||
cvs-kerberosIV /usr/src/kerberosIV Kerberos encryption code
|
||||
cvs-lib /usr/src/lib System libraries
|
||||
cvs-libexec /usr/src/libexec System binaries
|
||||
cvs-ports /usr/ports Ported software
|
||||
cvs-sbin /usr/src/sbin System binaries
|
||||
cvs-share /usr/src/share System shared files
|
||||
cvs-sys /usr/src/sys Kernel
|
||||
cvs-usrbin /usr/src/usr.bin Use binaries
|
||||
cvs-usrsbin /usr/src/usr.sbin System binaries
|
||||
</verb>
|
||||
|
||||
<sect1><heading>How to subscribe<label id="eresources:subscribe"></heading>
|
||||
|
||||
<p>All mailing lists live on <tt>FreeBSD.ORG</tt>, so to post to a
|
||||
given list you simply mail to <em>listname</em><tt>@FreeBSD.ORG</tt>. It
|
||||
will then be redistributed to mailing list members world-wide.
|
||||
|
||||
To subscribe to a list, send mail to &a.majordomo and include
|
||||
<tscreen><verb>
|
||||
subscribe <listname> [<optional address>]
|
||||
</verb></tscreen>
|
||||
In the body of your message. For example, to subscribe yourself to
|
||||
freebsd-announce, you'd do:
|
||||
<tscreen><verb>
|
||||
% mail majordomo@FreeBSD.ORG
|
||||
subscribe freebsd-announce
|
||||
^D
|
||||
</verb></tscreen>
|
||||
If you want to subscribe yourself under a different name, or submit a
|
||||
subscription request for a local mailing list (note: this is more efficient
|
||||
if you have several interested parties at one site, and highly appreciated by
|
||||
us!), you would do something like:
|
||||
<tscreen><verb>
|
||||
% mail majordomo@FreeBSD.ORG
|
||||
subscribe freebsd-announce local-announce@somesite.com
|
||||
^D
|
||||
</verb></tscreen>
|
||||
Finally, it is also possible to unsubscribe yourself from a list, get a
|
||||
list of other list members or see the list of mailing lists again by
|
||||
sending other types of control messages to majordomo. For a complete
|
||||
list of available commands, do this:
|
||||
<tscreen><verb>
|
||||
% mail majordomo@FreeBSD.ORG
|
||||
help
|
||||
^D
|
||||
</verb></tscreen>
|
||||
Again, we would like to request that you keep discussion in the technical mailing
|
||||
lists on a technical track. If you are only interested in the "high points"
|
||||
then it is suggested that you join freebsd-announce, which is intended only
|
||||
for infrequent traffic.
|
||||
|
||||
<sect1><heading>List charters<label id="eresources:charters"></heading>
|
||||
|
||||
<p><bf>All</bf>FreeBSD mailing lists have certain basic rules
|
||||
which must be adhered to by anyone using them. Failure to comply
|
||||
with these guidelines will result in two (2) written warnings from the
|
||||
FreeBSD <url url="mailto:postmaster@freebsd.org" name="Postmaster">,
|
||||
after which, on a third offense, the poster will removed from all
|
||||
FreeBSD mailing lists and filtered from further posting to them.
|
||||
We regret that such rules and measures are necessary at all, but
|
||||
today's Internet is a pretty harsh environment, it would seem, and
|
||||
many fail to appreciate just how fragile some of its mechanisms are.
|
||||
|
||||
<p>Rules of the road:
|
||||
<itemize>
|
||||
<item>The topic of any posting should adhere to the basic charter of the list
|
||||
it is posted to, e.g. if the list is about technical issues then your
|
||||
posting should contain technical discussion. Ongoing irrelevant chatter
|
||||
or flaming only detracts from the value of the mailing list for everyone
|
||||
on it and will not be tolerated. For free-form discussion on no
|
||||
particular topic, the <url url="mailto:freebsd-chat@freebsd.org"
|
||||
name="freebsd-chat"> mailing list is freely available and should
|
||||
be used instead.</item>
|
||||
|
||||
<item>No posting should be made to more than 2 mailing lists, and only
|
||||
to 2 when a clear and obvious need to post to both lists exists.
|
||||
For most lists, there is already a great deal of subscriber overlap
|
||||
and except for the most esoteric mixes (say "-stable & -scsi"), there
|
||||
really is no reason to post to more than one list at a time.
|
||||
If a message is sent to you in such a way that multiple mailing lists
|
||||
appear on the Cc line then the cc line should also be trimmed before
|
||||
sending it out again.
|
||||
<em>You are <bf>still</bf> responsible for your own cross-postings, no
|
||||
matter who the originator might have been.</em></item>
|
||||
|
||||
<item>Personal attacks and profanity (in the context of an argument) are
|
||||
not allowed, and that includes users and developers alike. Gross
|
||||
breaches of netiquette, like excerpting or reposting private mail
|
||||
when permission to do so was not and would not be forthcoming,
|
||||
are frowned upon but not specifically enforced. <bf>However</bf>,
|
||||
there are also very few cases where such content would fit within the
|
||||
charter of a list and it would therefore probably rate a warning
|
||||
(or ban) on that basis alone.</item>
|
||||
|
||||
<item>Advertising of non-FreeBSD related products or services is
|
||||
strictly prohibited and will result in an immediate ban if it
|
||||
is clear that the offender is advertising by spam.</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<p><bf>Individual list charters:</bf>
|
||||
|
||||
<p>
|
||||
<descrip>
|
||||
<tag/FREEBSD-ADMIN/ <em>Administrative issues</em><newline>
|
||||
This list is purely for discussion of freebsd.org related issues
|
||||
and to report problems or abuse of project resources. It is a closed
|
||||
list, though anyone may report a problem (with our systems!) to it.
|
||||
|
||||
<tag/FREEBSD-ANNOUNCE/ <em>Important events / milestones</em><newline>
|
||||
This is the mailing list for people interested only in occasional
|
||||
announcements of significant freebsd events. This includes
|
||||
announcements about snapshots and other releases. It contains
|
||||
announcements of new FreeBSD capabilities. It may contain calls
|
||||
for volunteers etc. This is a low volume, strictly moderated mailing list.
|
||||
|
||||
<tag/FREEBSD-ARCH/ <em>Architecture and design discussions</em><newline>
|
||||
This is the mailing list for people discussing FreeBSD architectural
|
||||
issues. It is a closed list, and not for general subscription.
|
||||
|
||||
<tag/FREEBSD-BUGS/ <em>Bug reports</em><newline>
|
||||
This is the mailing list for reporting bugs in FreeBSD
|
||||
Whenever possible, bugs should be submitted using the "send-pr(1)"
|
||||
command or the <url url="http://www.freebsd.org/send-pr.html"
|
||||
name="WEB interface"> to it.
|
||||
|
||||
<tag/FREEBSD-CHAT/ <em>Non technical items related to the
|
||||
FreeBSD community</em><newline>
|
||||
This list contains the overflow from the other lists about
|
||||
non-technical, social information. It includes discussion about
|
||||
whether Jordan looks like a toon ferret or not, whether or not to
|
||||
type in capitals, who is drinking too much coffee, where the best
|
||||
beer is brewed, who is brewing beer in their basement, and so on.
|
||||
Occasional announcements of important events (such as upcoming
|
||||
parties, weddings, births, new jobs, etc) can be made to the
|
||||
technical lists, but the follow ups should be directed to this
|
||||
-chat list.
|
||||
|
||||
<tag/FREEBSD-CORE/ <em>FreeBSD core team</em><newline>
|
||||
This is an internal mailing list for use by the core members.
|
||||
Messages can be sent to it when a serious FreeBSD-related matter
|
||||
requires arbitration or high-level scrutiny.
|
||||
|
||||
<tag/FREEBSD-CURRENT/ <em>Discussions about the use of
|
||||
FreeBSD-current</em><newline> This is the mailing list for users
|
||||
of freebsd-current. It includes warnings about new features
|
||||
coming out in -current that will affect the users, and
|
||||
instructions on steps that must be taken to remain -current.
|
||||
Anyone running "current" must subscribe to this list.
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-CURRENT-DIGEST/ <em>Discussions about the use of
|
||||
FreeBSD-current</em><newline> This is the digest version of the
|
||||
freebsd-current mailing list. The digest consists of all
|
||||
messages sent to freebsd-current bundled together and mailed out
|
||||
as a single message. The average digest size is about 40kB.
|
||||
This list is <bf>Read-Only</bf> and should not be posted to.
|
||||
|
||||
<tag/FREEBSD-STABLE/ <em>Discussions about the use of
|
||||
FreeBSD-stable</em><newline> This is the mailing list for users
|
||||
of freebsd-stable. It includes warnings about new features
|
||||
coming out in -stable that will affect the users, and
|
||||
instructions on steps that must be taken to remain -stable.
|
||||
Anyone running ``stable'' should subscribe to this list.
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-DOC/ <em>Documentation project</em><newline>
|
||||
This mailing list belongs to the FreeBSD Doc Project and is for
|
||||
the discussion of documentation related issues and projects.
|
||||
|
||||
<tag/FREEBSD-FS/ <em>Filesystems</em><newline>
|
||||
Discussions concerning FreeBSD filesystems.
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-HACKERS/ <em>Technical discussions</em><newline>
|
||||
This is a forum for technical discussions related to FreeBSD. This
|
||||
is the primary technical mailing list. It
|
||||
is for individuals actively working on FreeBSD, to bring up problems
|
||||
or discuss alternative solutions. Individuals interested in
|
||||
following the technical discussion are also welcome.
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-HACKERS-DIGEST/ <em>Technical
|
||||
discussions</em><newline> This is the digest version of the
|
||||
freebsd-hackers mailing list. The digest consists of all
|
||||
messages sent to freebsd-hackers bundled together and mailed out
|
||||
as a single message. The average digest size is about 40kB.
|
||||
This list is <bf>Read-Only</bf> and should not be posted to.
|
||||
|
||||
<tag/FREEBSD-HARDWARE/ <em>General discussion of FreeBSD
|
||||
hardware</em><newline> General discussion about the types of
|
||||
hardware that FreeBSD runs on, various problems and suggestions
|
||||
concerning what to buy or avoid.
|
||||
|
||||
<tag/FREEBSD-INSTALL/ <em>Installation discussion</em><newline>
|
||||
This mailing list is for discussing FreeBSD installation
|
||||
development for the future releases and is closed.
|
||||
|
||||
<tag/FREEBSD-ISP/ <em>Issues for Internet Service Providers</em><newline>
|
||||
This mailing list is for discussing topics relevant to Internet
|
||||
Service Providers (ISPs) using FreeBSD.
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-MULTIMEDIA/ <em>Multimedia discussions</em><newline>
|
||||
This is a forum about multimedia applications using FreeBSD.
|
||||
Discussion center around multimedia applications, their installation, their
|
||||
development and their support within FreeBSD
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-PLATFORMS/ <em>Porting to Non-Intel
|
||||
platforms</em><newline> Cross-platform freebsd issues, general
|
||||
discussion and proposals for non-Intel FreeBSD ports.
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-PORTS/ <em>Discussion of "ports"</em><newline>
|
||||
Discussions concerning FreeBSD's "ports collection" (/usr/ports), proposed
|
||||
ports, modifications to ports collection infrastructure and general
|
||||
coordination efforts.
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-QUESTIONS/ <em>User questions</em><newline>
|
||||
This is the mailing list for questions about FreeBSD. You should not
|
||||
send "how to" questions to the technical lists unless you consider the
|
||||
question to be pretty technical.
|
||||
|
||||
<tag/FREEBSD-QUESTIONS-DIGEST/ <em>User questions</em><newline>
|
||||
This is the digest version of the freebsd-questions mailing list.
|
||||
The digest consists of all messages sent to freebsd-questions
|
||||
bundled together and mailed out as a single message. The average
|
||||
digest size is about 40kB.
|
||||
|
||||
<tag/FREEBSD-SCSI/ <em>SCSI subsystem</em><newline>
|
||||
This is the mailing list for people working on the scsi subsystem
|
||||
for FreeBSD.
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-SECURITY/ <em>Security issues</em><newline>
|
||||
FreeBSD computer security issues (DES, Kerberos, known security holes and
|
||||
fixes, etc).
|
||||
This is a technical mailing list for which strictly technical
|
||||
content is expected.
|
||||
|
||||
<tag/FREEBSD-SECURITY-NOTIFICATIONS/ <em>Security Notifications</em><newline>
|
||||
Notifications of FreeBSD security problems and fixes. This is not
|
||||
a discussion list. The discussion list is FreeBSD-security.
|
||||
|
||||
<tag/FREEBSD-USER-GROUPS/ <em>User Group Coordination List</em><newline>
|
||||
This is the mailing list for the coordinators from each of the
|
||||
local area Users Groups to discuss matters with each other and a
|
||||
designated individual from the Core Team. This mail list should
|
||||
be limited to meeting synopsis and coordination of projects that span
|
||||
User Groups. It is a closed list.
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect>
|
||||
<heading>Usenet newsgroups<label id="eresources:news"></heading>
|
||||
|
||||
<p>In addition to two FreeBSD specific newsgroups, there
|
||||
are many others in which FreeBSD is discussed or are
|
||||
otherwise relevant to FreeBSD users. <url
|
||||
url="http://minnie.cs.adfa.oz.au/BSD-info/bsdnews_search.html"
|
||||
name="Keyword searchable archives"> are available for
|
||||
some of these newsgroups from courtesy of Warren Toomey
|
||||
<tt><wkt@cs.adfa.oz.au></tt>.
|
||||
|
||||
<sect1>
|
||||
<heading>BSD specific newsgroups</heading>
|
||||
|
||||
<p><itemize>
|
||||
<item><url url="news:comp.unix.bsd.freebsd.announce"
|
||||
name="comp.unix.bsd.freebsd.announce"></item>
|
||||
<item><url url="news:comp.unix.bsd.freebsd.misc"
|
||||
name="comp.unix.bsd.freebsd.misc"></item>
|
||||
</itemize>
|
||||
|
||||
<sect1>
|
||||
<heading>Other Unix newsgroups of interest</heading>
|
||||
|
||||
<p><itemize>
|
||||
<item><url url="news:comp.unix" name="comp.unix"></item>
|
||||
<item><url url="news:comp.unix.questions" name="comp.unix.questions"></item>
|
||||
<item><url url="news:comp.unix.admin" name="comp.unix.admin"></item>
|
||||
<item><url url="news:comp.unix.programmer" name="comp.unix.programmer"></item>
|
||||
<item><url url="news:comp.unix.shell" name="comp.unix.shell"></item>
|
||||
<item><url url="news:comp.unix.user-friendly" name="comp.unix.user-friendly"></item>
|
||||
<item><url url="news:comp.security.unix" name="comp.security.unix"></item>
|
||||
<item><url url="news:comp.sources.unix" name="comp.sources.unix"></item>
|
||||
<item><url url="news:comp.unix.advocacy" name="comp.unix.advocacy"></item>
|
||||
<item><url url="news:comp.unix.misc" name="comp.unix.misc"></item>
|
||||
<item><url url="news:comp.os.386bsd.announc" name="comp.os.386bsd.announc"></item>
|
||||
<item><url url="news:comp.os.386bsd.app" name="comp.os.386bsd.app"></item>
|
||||
<item><url url="news:comp.os.386bsd.bugs" name="comp.os.386bsd.bugs"></item>
|
||||
<item><url url="news:comp.os.386bsd.development" name="comp.os.386bsd.development"></item>
|
||||
<item><url url="news:comp.os.386bsd.misc" name="comp.os.386bsd.misc"></item>
|
||||
<item><url url="news:comp.os.386bsd.questions" name="comp.os.386bsd.questions"></item>
|
||||
<item><url url="news:comp.bugs.4bsd" name="comp.bugs.4bsd"></item>
|
||||
<item><url url="news:comp.bugs.4bsd.ucb-fixes" name="comp.bugs.4bsd.ucb-fixes"></item>
|
||||
<item><url url="news:comp.unix.bsd" name="comp.unix.bsd"></item>
|
||||
</itemize>
|
||||
|
||||
<sect1>
|
||||
<heading>X Window System</heading>
|
||||
|
||||
<p><itemize>
|
||||
<item><url url="news:comp.windows.x.i386unix" name="comp.windows.x.i386unix"></item>
|
||||
<item><url url="news:comp.windows.x" name="comp.windows.x"></item>
|
||||
<item><url url="news:comp.windows.x.apps" name="comp.windows.x.apps"></item>
|
||||
<item><url url="news:comp.windows.x.announce" name="comp.windows.x.announce"></item>
|
||||
<item><url url="news:comp.windows.x.intrinsics" name="comp.windows.x.intrinsics"></item>
|
||||
<item><url url="news:comp.windows.x.motif" name="comp.windows.x.motif"></item>
|
||||
<item><url url="news:comp.windows.x.pex" name="comp.windows.x.pex"></item>
|
||||
<item><url url="news:comp.emulators.ms-windows.wine" name="comp.emulators.ms-windows.wine"></item>
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>World Wide Web servers<label id="eresources:web"></heading>
|
||||
|
||||
<p><itemize>
|
||||
<item><url url="http://www.FreeBSD.ORG/"> <bf>- Central Server</bf>.</item>
|
||||
<item><url url="http://www.au.freebsd.org/FreeBSD/"> <bf>- Australia</bf>.</item>
|
||||
<item><url url="http://www.br.freebsd.org/"> <bf>- Brazil</bf>.</item>
|
||||
<item><url url="http://www.ca.freebsd.org/"> <bf>- Canada</bf>.</item>
|
||||
<item><url url="http://sunsite.mff.cuni.cz/www.freebsd.org/"><bf>- Czech Republic</bf>.</item>
|
||||
<item><url url="http://sunsite.auc.dk/www.freebsd.org/"> <bf>- Denmark</bf>.</item>
|
||||
<item><url url="http://www.ee.freebsd.org/"> <bf>- Estonia</bf>.</item>
|
||||
<item><url url="http://www.fi.freebsd.org/"> <bf>- Finland</bf>.</item>
|
||||
<item><url url="http://www.de.freebsd.org/"> <bf>- Germany</bf>.</item>
|
||||
<item><url url="http://www.ie.freebsd.org/"> <bf>- Ireland</bf>.</item>
|
||||
<item><url url="http://www.jp.freebsd.org/"> <bf>- Japan</bf>.</item>
|
||||
<item><url url="http://www.kr.freebsd.org/"> <bf>- Korea</bf>.</item>
|
||||
<item><url url="http://www.nl.freebsd.org/"> <bf>- Netherlands</bf>.</item>
|
||||
<item><url url="http://www.pt.freebsd.org/"> <bf>- Portugal</bf>.</item>
|
||||
<item><url url="http://www.se.freebsd.org/www.freebsd.org/"> <bf>- Sweden</bf>.</item>
|
||||
<item><url url="http://www.tw.freebsd.org/freebsd.html"> <bf>- Taiwan</bf>.</item>
|
||||
</itemize>
|
||||
</sect>
|
||||
@ -1,421 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<title>An introduction to ESDI hard disks and their use with FreeBSD</title>
|
||||
<author>(c) 1995, Wilko Bulte, <tt/wilko@yedi.iaf.nl/
|
||||
<date>Tue Sep 12 20:48:44 MET DST 1995</date>
|
||||
|
||||
Copyright 1995, Wilko C. Bulte, Arnhem, The Netherlands
|
||||
|
||||
<abstract>
|
||||
This document describes the use of ESDI disks in combination
|
||||
with the FreeBSD operating system. Contrary to popular
|
||||
belief, this is possible and people are using ESDI based
|
||||
systems successfully! This document tries to explain you
|
||||
how to do this.
|
||||
|
||||
If you find something missing, plain wrong or have useful
|
||||
comments on how to improve
|
||||
the document please send mail to <tt/wilko@yedi.iaf.nl/
|
||||
</abstract>
|
||||
-->
|
||||
|
||||
<sect1><heading>Using ESDI hard disks<label id="esdi"></heading>
|
||||
|
||||
<p><em>Copyright © 1995, &a.wilko;.<newline>24 September 1995.</em>
|
||||
|
||||
ESDI is an acronym that means Enhanced Small Device Interface.
|
||||
It is loosely based on the good old ST506/412 interface originally
|
||||
devised by Seagate Technology, the makers of the first affordable
|
||||
5.25" winchester disk.
|
||||
|
||||
The acronym says Enhanced, and rightly so. In the first place
|
||||
the speed of the interface is higher, 10 or 15 Mbits/second
|
||||
instead of the 5 Mbits/second of ST412 interfaced drives.
|
||||
Secondly some higher level commands are added, making the ESDI
|
||||
interface somewhat 'smarter' to the operating system driver
|
||||
writers. It is by no means as smart as SCSI by the way. ESDI
|
||||
is standardized by ANSI.
|
||||
|
||||
Capacities of the drives are boosted by putting more sectors
|
||||
on each track. Typical is 35 sectors per track, high capacity
|
||||
drives I have seen were up to 54 sectors/track.
|
||||
|
||||
Although ESDI has been largely obsoleted by IDE and SCSI interfaces,
|
||||
the availability of free or cheap surplus drives makes them
|
||||
ideal for low (or now) budget systems.
|
||||
|
||||
<sect2><heading>Concepts of ESDI</heading>
|
||||
<p>
|
||||
<sect3><heading>Physical connections</heading>
|
||||
<p>
|
||||
The ESDI interface uses two cables connected to each drive.
|
||||
One cable is a 34 pin flat cable edge connector that carries
|
||||
the command and status signals from the controller to the
|
||||
drive and vice-versa. The command cable is daisy chained
|
||||
between all the drives. So, it forms a bus onto which all
|
||||
drives are connected.
|
||||
|
||||
The second cable is a 20 pin flat cable edge connector that
|
||||
carries the data to and from the drive. This cable is radially
|
||||
connected, so each drive has its own direct connection to the
|
||||
controller.
|
||||
|
||||
To the best of my knowledge PC ESDI controllers are limited
|
||||
to using a maximum of 2 drives per controller. This is
|
||||
compatibility feature(?) left over from the WD1003 standard
|
||||
that reserves only a single bit for device addressing.
|
||||
|
||||
<sect3><heading>Device addressing</heading>
|
||||
<p>
|
||||
On each command cable a maximum of 7 devices and 1 controller
|
||||
can be present. To enable the controller to uniquely
|
||||
identify which drive it addresses, each ESDI device is equipped
|
||||
with jumpers or switches to select the devices address.
|
||||
|
||||
On PC type controllers the first drive is set to address 0,
|
||||
the second disk to address 1. <it>Always make sure</it> you
|
||||
set each disk to an unique address! So, on a PC with its
|
||||
two drives/controller maximum the first drive is drive 0, the
|
||||
second is drive 1.
|
||||
|
||||
<sect3><heading>Termination</heading>
|
||||
<p>
|
||||
The daisy chained command cable (the 34 pin cable remember?)
|
||||
needs to be terminated at the last drive on the chain.
|
||||
For this purpose ESDI drives come with a termination resistor
|
||||
network that can be removed or disabled by a jumper when it
|
||||
is not used.
|
||||
|
||||
So, one and <it>only</it> one drive, the one at
|
||||
the farthest end of the command
|
||||
cable has its terminator installed/enabled. The controller
|
||||
automatically terminates the other end of the cable.
|
||||
Please note that this implies that the controller must be
|
||||
at one end of the cable and <it>not</it> in the middle.
|
||||
|
||||
<sect2><heading>Using ESDI disks with FreeBSD</heading>
|
||||
<p>
|
||||
Why is ESDI such a pain to get working in the first place?
|
||||
|
||||
People who tried ESDI disks with FreeBSD are known to have
|
||||
developed a profound sense of frustration. A combination of
|
||||
factors works against you to produce effects that are
|
||||
hard to understand when you have never seen them before.
|
||||
|
||||
This has also led to the popular legend ESDI and FreeBSD
|
||||
is a plain NO-GO.
|
||||
The following sections try to list all the pitfalls and
|
||||
solutions.
|
||||
|
||||
<sect3><heading>ESDI speed variants</heading>
|
||||
<p>
|
||||
As briefly mentioned before, ESDI comes in two speed flavors.
|
||||
The older drives and controllers use a 10 Mbits/second
|
||||
data transfer rate. Newer stuff uses 15 Mbits/second.
|
||||
|
||||
It is not hard to imagine that 15 Mbits/second drive cause
|
||||
problems on controllers laid out for 10 Mbits/second.
|
||||
As always, consult your controller <it>and</it> drive
|
||||
documentation to see if things match.
|
||||
|
||||
<sect3><heading>Stay on track</heading>
|
||||
<p>
|
||||
Mainstream ESDI drives use 34 to 36 sectors per track.
|
||||
Most (older) controllers cannot handle more than this
|
||||
number of sectors.
|
||||
Newer, higher capacity, drives use higher numbers of sectors
|
||||
per track. For instance, I own a 670 Mb drive that has
|
||||
54 sectors per track.
|
||||
|
||||
In my case, the controller could not handle this number
|
||||
of sectors. It proved to work well except that it only
|
||||
used 35 sectors on each track. This meant losing a
|
||||
lot of disk space.
|
||||
|
||||
Once again, check the documentation of your hardware for
|
||||
more info. Going out-of-spec like in the example might
|
||||
or might not work. Give it a try or get another more
|
||||
capable controller.
|
||||
|
||||
<sect3><heading>Hard or soft sectoring</heading>
|
||||
<p>
|
||||
Most ESDI drives allow hard or soft sectoring to be
|
||||
selected using a jumper. Hard sectoring means that the
|
||||
drive will produce a sector pulse on the start of each
|
||||
new sector. The controller uses this pulse to tell when
|
||||
it should start to write or read.
|
||||
|
||||
Hard sectoring allows a selection of sector size (normally
|
||||
256, 512 or 1024 bytes per formatted sector). FreeBSD uses
|
||||
512 byte sectors. The number of sectors per track also varies
|
||||
while still using the same number of bytes per formatted sector.
|
||||
The number of <em>unformatted</em> bytes per sector varies,
|
||||
dependent on your controller it needs more or less overhead
|
||||
bytes to work correctly. Pushing more sectors on a track
|
||||
of course gives you more usable space, but might give
|
||||
problems if your controller needs more bytes than the
|
||||
drive offers.
|
||||
|
||||
In case of soft sectoring, the controller itself determines
|
||||
where to start/stop reading or writing. For ESDI
|
||||
hard sectoring is the default (at least on everything
|
||||
I came across). I never felt the urge to try soft sectoring.
|
||||
|
||||
In general, experiment with sector settings before you install
|
||||
FreeBSD because you need to re-run the low-level format
|
||||
after each change.
|
||||
|
||||
<sect3><heading>Low level formatting</heading>
|
||||
<p>
|
||||
ESDI drives need to be low level formatted before they
|
||||
are usable. A reformat is needed whenever you figgle
|
||||
with the number of sectors/track jumpers or the
|
||||
physical orientation of the drive (horizontal, vertical).
|
||||
So, first think, then format.
|
||||
The format time must not be underestimated, for big
|
||||
disks it can take hours.
|
||||
|
||||
After a low level format, a surface scan is done to
|
||||
find and flag bad sectors. Most disks have a
|
||||
manufacturer bad block list listed on a piece of paper
|
||||
or adhesive sticker. In addition, on most disks the
|
||||
list is also written onto the disk.
|
||||
Please use the manufacturer's list. It is much easier
|
||||
to remap a defect now than after FreeBSD is installed.
|
||||
|
||||
Stay away from low-level formatters that mark all
|
||||
sectors of a track as bad as soon as they find one
|
||||
bad sector. Not only does this waste space, it also
|
||||
and more importantly causes you grief with bad144
|
||||
(see the section on bad144).
|
||||
|
||||
<sect3><heading>Translations</heading>
|
||||
<p>
|
||||
Translations, although not exclusively a ESDI-only problem,
|
||||
might give you real trouble.
|
||||
Translations come in multiple flavors. Most of them
|
||||
have in common that they attempt to work around the
|
||||
limitations posed upon disk geometries by the original
|
||||
IBM PC/AT design (thanks IBM!).
|
||||
|
||||
First of all there is the (in)famous 1024 cylinder limit.
|
||||
For a system to be able to boot, the stuff (whatever
|
||||
operating system) must be in the first 1024 cylinders
|
||||
of a disk. Only 10 bits are available to encode the
|
||||
cylinder number. For the number of sectors the limit
|
||||
is 64 (0-63).
|
||||
When you combine the 1024 cylinder limit with the 16 head
|
||||
limit (also a design feature) you max out at fairly limited
|
||||
disk sizes.
|
||||
|
||||
To work around this problem, the manufacturers of ESDI
|
||||
PC controllers added a BIOS prom extension on their boards.
|
||||
This BIOS extension handles disk I/O for booting (and for
|
||||
some operating systems <it>all</it> disk I/O) by using
|
||||
translation. For instance, a big drive might be presented
|
||||
to the system as having 32 heads and 64 sectors/track.
|
||||
The result is that the number of cylinders is reduced to
|
||||
something below 1024 and is therefore usable by the system
|
||||
without problems.
|
||||
It is noteworthy to know that FreeBSD does not use the
|
||||
BIOS after its kernel has started. More on this later.
|
||||
|
||||
A second reason for translations is the fact that most
|
||||
older system BIOSes could only handle drives with 17 sectors
|
||||
per track (the old ST412 standard). Newer system BIOSes
|
||||
usually have a user-defined drive type (in most cases this is
|
||||
drive type 47).
|
||||
|
||||
<em>Whatever you do to translations after reading this document,
|
||||
keep in mind that if you have multiple operating systems on the
|
||||
same disk, all must use the same translation</em>
|
||||
|
||||
While on the subject of translations, I have seen one controller
|
||||
type (but there are probably more like this) offer the option
|
||||
to logically split a drive in multiple partitions as a BIOS
|
||||
option. I had select 1 drive == 1 partition because this
|
||||
controller wrote this info onto the disk. On power-up it
|
||||
read the info and presented itself to the system based on
|
||||
the info from the disk.
|
||||
|
||||
<sect3><heading>Spare sectoring</heading>
|
||||
<p>
|
||||
Most ESDI controllers offer the possibility to remap bad sectors.
|
||||
During/after the low-level format of the disk bad sectors are
|
||||
marked as such, and a replacement sector is put in place
|
||||
(logically of course) of the bad one.
|
||||
|
||||
In most cases the remapping is done by using N-1 sectors on
|
||||
each track for actual data storage, and sector N itself is
|
||||
the spare sector. N is the total number of sectors physically
|
||||
available on the track.
|
||||
The idea behind this is that the operating system sees
|
||||
a 'perfect' disk without bad sectors. In the case of
|
||||
FreeBSD this concept is not usable.
|
||||
|
||||
The problem is that the translation from <it>bad</it> to <it>good</it>
|
||||
is performed by the BIOS of the ESDI controller. FreeBSD,
|
||||
being a true 32 bit operating system, does not use the BIOS
|
||||
after it has been booted. Instead, it has device drivers that
|
||||
talk directly to the hardware.
|
||||
|
||||
<em>So: don't use spare sectoring, bad block remapping or
|
||||
whatever it may be called by the controller manufacturer when you
|
||||
want to use the disk for FreeBSD.</em>
|
||||
|
||||
<sect3><heading>Bad block handling</heading>
|
||||
<p>
|
||||
The preceding section leaves us with a problem. The controller's
|
||||
bad block handling is not usable and still FreeBSD's filesystems
|
||||
assume perfect media without any flaws.
|
||||
To solve this problem, FreeBSD use the <it>bad144</it> tool.
|
||||
Bad144 (named after a Digital Equipment standard for bad block
|
||||
handling) scans a FreeBSD slice for bad blocks. Having found
|
||||
these bad blocks, it writes a table with the offending block
|
||||
numbers to the end of the FreeBSD slice.
|
||||
|
||||
When the disk is in operation, the disk accesses are checked
|
||||
against the table read from the disk. Whenever a block number
|
||||
is requested that is in the bad144 list, a replacement block
|
||||
(also from the end of the FreeBSD slice) is used.
|
||||
In this way, the bad144 replacement scheme presents 'perfect'
|
||||
media to the FreeBSD filesystems.
|
||||
|
||||
There are a number of potential pitfalls associated with
|
||||
the use of bad144.
|
||||
First of all, the slice cannot have more than 126 bad sectors.
|
||||
If your drive has a high number of bad sectors, you might need
|
||||
to divide it into multiple FreeBSD slices each containing less
|
||||
than 126 bad sectors. Stay away from low-level format programs
|
||||
that mark <em>every</em> sector of a track as bad when
|
||||
they find a flaw on the track. As you can imagine, the
|
||||
126 limit is quickly reached when the low-level format is done
|
||||
this way.
|
||||
|
||||
Second, if the slice contains the root filesystem, the slice
|
||||
should be within the 1024 cylinder BIOS limit. During the
|
||||
boot process the bad144 list is read using the BIOS and this
|
||||
only succeeds when the list is within the 1024 cylinder limit.
|
||||
<em>Note</em> that the restriction is not that only the root
|
||||
<em>filesystem</em> must be within the 1024 cylinder limit, but
|
||||
rather the entire <em>slice</em> that contains the root filesystem.
|
||||
|
||||
|
||||
<sect3><heading>Kernel configuration</heading>
|
||||
<p>
|
||||
ESDI disks are handled by the same <it>wd</it>driver as
|
||||
IDE and ST412 MFM disks. The <it>wd</it> driver should work
|
||||
for all WD1003 compatible interfaces.
|
||||
|
||||
Most hardware is jumperable for one of two different I/O
|
||||
address ranges and IRQ lines. This allows you to have
|
||||
two wd type controllers in one system.
|
||||
|
||||
When your hardware allows non-standard strappings, you
|
||||
can use these with FreeBSD as long as you enter the
|
||||
correct info into the kernel config file.
|
||||
An example from the kernel config file (they live in
|
||||
<tt>/sys/i386/conf</tt> BTW).
|
||||
|
||||
<tscreen><verb>
|
||||
# First WD compatible controller
|
||||
controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
|
||||
disk wd0 at wdc0 drive 0
|
||||
disk wd1 at wdc0 drive 1
|
||||
|
||||
# Second WD compatible controller
|
||||
controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr
|
||||
disk wd2 at wdc1 drive 0
|
||||
disk wd3 at wdc1 drive 1
|
||||
</verb></tscreen>
|
||||
|
||||
<!--
|
||||
<sect3><heading>Tuning your ESDI kernel setup</heading>
|
||||
<p>
|
||||
-->
|
||||
|
||||
<sect2><heading>Particulars on ESDI hardware</heading>
|
||||
<p>
|
||||
<sect3><heading>Adaptec 2320 controllers</heading>
|
||||
<p>
|
||||
I successfully installed FreeBSD onto a ESDI disk controlled by a
|
||||
ACB-2320. No other operating system was present on the disk.
|
||||
|
||||
To do so I low level formatted the disk using NEFMT.EXE
|
||||
(<it>ftp</it>able from <it>www.adaptec.com</it>) and answered NO
|
||||
to the question whether the disk should be formatted with a
|
||||
spare sector on each track. The BIOS on the ACD-2320 was
|
||||
disabled. I used the 'free configurable' option in the system
|
||||
BIOS to allow the BIOS to boot it.
|
||||
|
||||
Before using NEFMT.EXE I tried to format the disk using the
|
||||
ACB-2320 BIOS builtin formatter. This proved to be a show stopper,
|
||||
because it did not give me an option to disable spare sectoring.
|
||||
With spare sectoring enabled the FreeBSD installation
|
||||
process broke down on the bad144 run.
|
||||
|
||||
Please check carefully which ACB-232xy variant you have. The
|
||||
x is either 0 or 2, indicating a controller without or with
|
||||
a floppy controller on board.
|
||||
|
||||
The y is more interesting. It can either be a blank,
|
||||
a "A-8" or a "D". A blank indicates a plain 10 Mbits/second
|
||||
controller. An "A-8" indicates a 15 Mbits/second controller
|
||||
capable of handling 52 sectors/track.
|
||||
A "D" means a 15 Mbits/second controller that can also
|
||||
handle drives with > 36 sectors/track (also 52 ?).
|
||||
|
||||
All variations should be capable of using 1:1 interleaving. Use 1:1,
|
||||
FreeBSD is fast enough to handle it.
|
||||
|
||||
<sect3><heading>Western Digital WD1007 controllers</heading>
|
||||
<p>
|
||||
I successfully installed FreeBSD onto a ESDI disk controlled by a
|
||||
WD1007 controller. To be precise, it was a WD1007-WA2. Other
|
||||
variations of the WD1007 do exist.
|
||||
|
||||
To get it to work, I had to disable the sector translation and
|
||||
the WD1007's onboard BIOS. This implied I could not use
|
||||
the low-level formatter built into this BIOS. Instead, I grabbed
|
||||
WDFMT.EXE from www.wdc.com Running this formatted my drive
|
||||
just fine.
|
||||
|
||||
<sect3><heading>Ultrastor U14F controllers</heading>
|
||||
<p>
|
||||
According to multiple reports from the net, Ultrastor ESDI
|
||||
boards work OK with FreeBSD. I lack any further info on
|
||||
particular settings.
|
||||
|
||||
<!--
|
||||
|
||||
<sect2><heading>Tracking down problems</heading>
|
||||
<p>
|
||||
-->
|
||||
|
||||
<sect2><heading>Further reading<label id="esdi:further-reading"></>
|
||||
<p>
|
||||
If you intend to do some serious ESDI hacking, you might want to
|
||||
have the official standard at hand:
|
||||
|
||||
The latest ANSI X3T10 committee document is:
|
||||
<itemize>
|
||||
<item>Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991]
|
||||
[X3T10/792D Rev 11]
|
||||
</itemize>
|
||||
On Usenet the newsgroup <htmlurl url="news:comp.periphs"
|
||||
name="comp.periphs"> is a noteworthy place to look
|
||||
for more info.
|
||||
|
||||
The World Wide Web (WWW) also proves to be a very handy info source:
|
||||
For info on Adaptec ESDI controllers see <htmlurl
|
||||
url="http://www.adaptec.com/">.
|
||||
For info on Western Digital controllers see <htmlurl
|
||||
url="http://www.wdc.com/">.
|
||||
|
||||
<sect2>Thanks to...
|
||||
<p>
|
||||
Andrew Gordon for sending me an Adaptec 2320 controller and ESDI disk
|
||||
for testing.
|
||||
|
||||
@ -1,528 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Firewalls<label id="firewalls"></heading>
|
||||
|
||||
<p><em>Contributed by &a.gpalmer; and &a.alex;.</em>
|
||||
|
||||
Firewalls are an area of increasing interest for people who are
|
||||
connected to the Internet, and are even finding applications on
|
||||
private networks to provide enhanced security. This section will
|
||||
hopefully explain what firewalls are, how to use them, and how to use
|
||||
the facilities provided in the FreeBSD kernel to implement them.
|
||||
|
||||
<quote><bf>Note</bf>: People often think that having a firewall between
|
||||
your companies internal network and the ``Big Bad Internet'' will
|
||||
solve all your security problems. It may help, but a poorly setup
|
||||
firewall system is more of a security risk than not having one at all.
|
||||
A firewall can only add another layer of security to your systems, but
|
||||
they will not be able to stop a really determined hacker from
|
||||
penetrating your internal network. If you let internal security lapse
|
||||
because you believe your firewall to be impenetrable, you have just
|
||||
made the hackers job that bit easier.</quote>
|
||||
|
||||
<sect1><heading>What is a firewall?</heading>
|
||||
|
||||
<p>There are currently two distinct types of firewalls in common
|
||||
use on the Internet today. The first type is more properly called
|
||||
a <bf>packet filtering router</bf>, where the kernel on a
|
||||
multi-homed machine chooses whether to forward or block packets
|
||||
based on a set of rules. The second type, known as <bf>proxy
|
||||
servers</bf>, rely on daemons to provide authentication and to
|
||||
forward packets, possibly on a multi-homed machine which has
|
||||
kernel packet forwarding disabled.
|
||||
|
||||
<p>Sometimes sites combine the two types of firewalls, so that only a
|
||||
certain machine (known as a <bf>bastion host</bf>) is allowed to send
|
||||
packets through a packet filtering router onto an internal
|
||||
network. Proxy services are run on the bastion host, which are
|
||||
generally more secure than normal authentication mechanisms.
|
||||
|
||||
<p>FreeBSD comes with a kernel packet filter (known as <tt>IPFW</tt>),
|
||||
which is what the rest of this section will concentrate on. Proxy
|
||||
servers can be built on FreeBSD from third party software, but there
|
||||
is such a variety of proxy servers available that it would be
|
||||
impossible to cover them in this document.
|
||||
|
||||
<sect2><heading>Packet filtering routers<label id="firewalls:packet_filters"></heading>
|
||||
|
||||
<p>A router is a machine which forwards packets between two or more
|
||||
networks. A packet filtering router has an extra piece of code in its
|
||||
kernel, which compares each packet to a list of rules before deciding
|
||||
if it should be forwarded or not. Most modern IP routing software has
|
||||
packet filtering code in it, which defaults to forwarding all
|
||||
packets. To enable the filters, you need to define a set of rules for
|
||||
the filtering code, so that it can decide if the packet should be
|
||||
allowed to pass or not.
|
||||
|
||||
<p>To decide if a packet should be passed on or not, the code looks
|
||||
through its set of rules for a rule which matches the contents of
|
||||
this packets headers. Once a match is found, the rule action is
|
||||
obeyed. The rule action could be to drop the packet, to forward the
|
||||
packet, or even to send an ICMP message back to the originator. Only
|
||||
the first match counts, as the rules are searched in order. Hence, the
|
||||
list of rules can be referred to as a ``rule chain''.
|
||||
|
||||
<p>The packet matching criteria varies depending on the software used,
|
||||
but typically you can specify rules which depend on the source IP
|
||||
address of the packet, the destination IP address, the source port
|
||||
number, the destination port number (for protocols which support
|
||||
ports), or even the packet type (UDP, TCP, ICMP, etc).
|
||||
|
||||
<sect2><heading>Proxy servers<label id="firewalls:proxy_servers"></heading>
|
||||
|
||||
<p>Proxy servers are machines which have had the normal system daemons
|
||||
(telnetd, ftpd, etc) replaced with special servers. These servers are
|
||||
called <bf>proxy servers</bf> as they normally only allow onward
|
||||
connections to be made. This enables you to run (for example) a proxy
|
||||
telnet server on your firewall host, and people can telnet in to your
|
||||
firewall from the outside, go through some authentication mechanism,
|
||||
and then gain access to the internal network (alternatively, proxy
|
||||
servers can be used for signals coming from the internal network and
|
||||
heading out).
|
||||
|
||||
<p>Proxy servers are normally more secure than normal servers, and
|
||||
often have a wider variety of authentication mechanisms available,
|
||||
including ``one-shot'' password systems so that even if someone
|
||||
manages to discover what password you used, they will not be able to use
|
||||
it to gain access to your systems as the password instantly
|
||||
expires. As they do not actually give users access to the host machine,
|
||||
it becomes a lot more difficult for someone to install backdoors
|
||||
around your security system.
|
||||
|
||||
<p>Proxy servers often have ways of restricting access further, so
|
||||
that only certain hosts can gain access to the servers, and often they
|
||||
can be set up so that you can limit which users can talk to which
|
||||
destination machine. Again, what facilities are available depends
|
||||
largely on what proxy software you choose.
|
||||
|
||||
<sect1><heading>What does IPFW allow me to do?</heading>
|
||||
|
||||
<p><tt>IPFW</tt>, the software supplied with FreeBSD, is a packet
|
||||
filtering and accounting system which resides in the kernel, and has a
|
||||
user-land control utility, <tt>ipfw(8)</tt>. Together, they
|
||||
allow you to define and query the rules currently used by the kernel
|
||||
in its routing decisions.
|
||||
|
||||
<p>There are two related parts to <tt>IPFW</tt>. The firewall section
|
||||
allows you to perform packet filtering. There is also an IP accounting
|
||||
section which allows you to track usage of your router, based on
|
||||
similar rules to the firewall section. This allows you to see (for
|
||||
example) how much traffic your router is getting from a certain
|
||||
machine, or how much WWW (World Wide Web) traffic it is forwarding.
|
||||
|
||||
<p>As a result of the way that <tt>IPFW</tt> is designed, you can use
|
||||
<tt>IPFW</tt> on non-router machines to perform packet filtering on
|
||||
incoming and outgoing connections. This is a special case of the more
|
||||
general use of <tt>IPFW</tt>, and the same commands and techniques
|
||||
should be used in this situation.
|
||||
|
||||
<sect1><heading>Enabling IPFW on FreeBSD</heading>
|
||||
|
||||
<p>As the main part of the <tt>IPFW</tt> system lives in the kernel, you will
|
||||
need to add one or more options to your kernel configuration
|
||||
file, depending on what facilities you want, and recompile your kernel. See
|
||||
<ref id="kernelconfig" name="reconfiguring the kernel"> for more
|
||||
details on how to recompile your kernel.
|
||||
|
||||
<p>There are currently three kernel configuration options
|
||||
relevant to IPFW:
|
||||
|
||||
<descrip>
|
||||
<tag/options IPFIREWALL/ Compiles into the kernel the code for packet
|
||||
filtering.
|
||||
|
||||
<tag/options IPFIREWALL_VERBOSE/ Enables code to allow logging of
|
||||
packets through <tt>syslogd(8)</tt>. Without this option, even if you
|
||||
specify that packets should be logged in the filter rules, nothing
|
||||
will happen.
|
||||
|
||||
<tag/options IPFIREWALL_VERBOSE_LIMIT=10/ Limits the number of
|
||||
packets logged through <tt>syslogd(8)</tt> on a per entry basis.
|
||||
You may wish to use this option in hostile environments in which
|
||||
you want to log firewall activity, but do not want to be open to
|
||||
a denial of service attack via syslog flooding.
|
||||
|
||||
<p>When a chain entry reaches the packet limit specified, logging
|
||||
is turned off for that particular entry. To resume logging, you
|
||||
will need to reset the associated counter using the <tt>ipfw(8)</tt>
|
||||
utility:
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw zero 4500
|
||||
</verb></tscreen>
|
||||
|
||||
Where 4500 is the chain entry you wish to continue logging.
|
||||
|
||||
</descrip>
|
||||
|
||||
Previous versions of FreeBSD contained an <tt>IPFIREWALL_ACCT</tt>
|
||||
option. This is now obsolete as the firewall code automatically
|
||||
includes accounting facilities.
|
||||
|
||||
<sect1><heading>Configuring IPFW</heading>
|
||||
|
||||
<p>The configuration of the <tt>IPFW</tt> software is done through the
|
||||
<tt>ipfw(8)</tt> utility. The syntax for this command looks
|
||||
quite complicated, but it is relatively simple once you understand
|
||||
its structure.
|
||||
|
||||
<p>There are currently four different command categories used by the
|
||||
utility: addition/deletion, listing, flushing, and clearing.
|
||||
Addition/deletion is used to build the rules that control how packets
|
||||
are accepted, rejected, and logged. Listing is used to examine the
|
||||
contents of your rule set (otherwise known as the chain) and packet
|
||||
counters (accounting). Flushing is used to remove all entries from
|
||||
the chain. Clearing is used to zero out one or more accounting
|
||||
entries.
|
||||
|
||||
<sect2><heading>Altering the IPFW rules</heading>
|
||||
|
||||
<p>The syntax for this form of the command is:
|
||||
<tscreen>
|
||||
ipfw [-N] <em>command</em> [<em>index</em>]
|
||||
<em>action</em> [log] <em>protocol</em> <em>addresses</em>
|
||||
[<em>options</em>]
|
||||
</tscreen>
|
||||
|
||||
<p>There is one valid flag when using this form of the command:
|
||||
|
||||
<descrip>
|
||||
<tag/-N/Resolve addresses and service names in output.
|
||||
</descrip>
|
||||
|
||||
The <em>command</em> given can be shortened to the shortest unique
|
||||
form. The valid <em>commands</em> are:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/add/Add an entry to the firewall/accounting rule list
|
||||
|
||||
<tag/delete/Delete an entry from the firewall/accounting rule list
|
||||
|
||||
</descrip>
|
||||
|
||||
Previous versions of <tt>IPFW</tt> used separate firewall and
|
||||
accounting entries. The present version provides packet accounting
|
||||
with each firewall entry.
|
||||
|
||||
<p>If an <tt>index</tt> value is supplied, it used to place the entry
|
||||
at a specific point in the chain. Otherwise, the entry is placed at
|
||||
the end of the chain at an index 100 greater than the last chain
|
||||
entry (this does not include the default policy, rule 65535, deny).
|
||||
|
||||
<p>The <bf>log</bf> option causes matching rules to be output to the
|
||||
system console if the kernel was compiled with <bf>IPFIREWALL_VERBOSE</bf>.
|
||||
|
||||
<p>Valid <em>actions</em> are:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/reject/Drop the packet, and send an ICMP host or port
|
||||
unreachable (as appropriate) packet to the source.
|
||||
|
||||
<tag/allow/Pass the packet on as normal. (aliases: <bf>pass</bf> and
|
||||
<bf>accept</bf>)
|
||||
|
||||
<tag/deny/Drop the packet. The source is not notified via an ICMP
|
||||
message (thus it appears that the packet never arrived at the
|
||||
destination).
|
||||
|
||||
<tag/count/Update packet counters but do not allow/deny the packet
|
||||
based on this rule. The search continues with the next chain entry.
|
||||
|
||||
</descrip>
|
||||
|
||||
<p>Each <em>action</em> will be recognized by the shortest unambiguous
|
||||
prefix.
|
||||
|
||||
The <em>protocols</em> which can be specified are:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/all/Matches any IP packet
|
||||
|
||||
<tag/icmp/Matches ICMP packets
|
||||
|
||||
<tag/tcp/Matches TCP packets
|
||||
|
||||
<tag/udp/Matches UDP packets
|
||||
|
||||
</descrip>
|
||||
|
||||
<p>The <em>address</em> specification is:
|
||||
<tscreen>
|
||||
<bf>from</bf> <<em>address/mask</em>>[<em>port</em>] <bf>to</bf>
|
||||
<<em>address/mask</em>>[<em>port</em>&rsqb [<bf>via</bf> <<em>interface</em>>]
|
||||
</tscreen>
|
||||
|
||||
<p>You can only specify <em>port</em> in conjunction with
|
||||
<em>protocols</em> which support ports (UDP and TCP).
|
||||
|
||||
<p>The <bf>via</bf> is optional and may specify the IP address or
|
||||
domain name of a local IP interface, or an interface name (e.g.
|
||||
<tt>ed0</tt>) to match only packets coming through this interface.
|
||||
Interface unit numbers can be specified with an optional wildcard.
|
||||
For example, <tt>ppp*</tt> would match all kernel PPP interfaces.
|
||||
|
||||
<p>The syntax used to specify an <tt><address/mask></tt> is:
|
||||
<tscreen>
|
||||
<address>
|
||||
</tscreen>
|
||||
or
|
||||
<tscreen>
|
||||
<address>/mask-bits
|
||||
</tscreen>
|
||||
or
|
||||
<tscreen>
|
||||
<address>:mask-pattern
|
||||
</tscreen>
|
||||
|
||||
<p>A valid hostname may be specified in place of the IP
|
||||
address. <tt>mask-bits</tt> is a decimal number representing how many
|
||||
bits in the address mask should be set. e.g. specifying
|
||||
<tscreen>
|
||||
192.216.222.1/24
|
||||
</tscreen>
|
||||
will create a mask which will allow any address in a class C subnet
|
||||
(in this case, 192.216.222) to be matched. <tt>mask-pattern</tt> is an IP
|
||||
address which will be logically AND'ed with the address given. The
|
||||
keyword <tt>any</tt> may be used to specify ``any IP address''.
|
||||
<p>The port numbers to be blocked are specified as:
|
||||
<tscreen>
|
||||
port[,port[,port[...]]]
|
||||
</tscreen>
|
||||
to specify either a single port or a list of ports, or
|
||||
<tscreen><verb>
|
||||
port-port
|
||||
</verb></tscreen>
|
||||
to specify a range of ports. You may also combine a single range with a
|
||||
list, but the range must always be specified first.
|
||||
|
||||
<p>The <em>options</em> available are:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/frag/Matches if the packet is not the first fragment of the datagram.
|
||||
|
||||
<tag/in/Matches if the packet is on the way in.
|
||||
|
||||
<tag/out/Matches if the packet is on the way out.
|
||||
|
||||
<tag/ipoptions <em>spec</em>/Matches if the IP header contains the
|
||||
comma separated list of options specified in <em>spec</em>. The
|
||||
supported list of IP options are: <bf>ssrr</bf> (strict source route),
|
||||
<bf>lsrr</bf> (loose source route), <bf>rr</bf> (record packet route),
|
||||
and <bf>ts</bf> (timestamp). The absence of a particular option may
|
||||
be denoted with a leading '!'.
|
||||
|
||||
<tag/established/Matches if the packet is part of an already established
|
||||
TCP connection (i.e. it has the RST or ACK bits set). You can optimize
|
||||
the performance of the firewall by placing <em>established</em> rules
|
||||
early in the chain.
|
||||
|
||||
<tag/setup/Matches if the packet is an attempt to establish a TCP connection
|
||||
(the SYN bit set is set but the ACK bit is not).
|
||||
|
||||
<tag/tcpflags <em>flags</em>/Matches if the TCP header contains
|
||||
the comma separated list of <em>flags</em>. The supported flags
|
||||
are <bf>fin</bf>, <bf>syn</bf>, <bf>rst</bf>, <bf>psh</bf>, <bf>ack</bf>,
|
||||
and <bf>urg</bf>. The absence of a particular flag may be indicated
|
||||
by a leading '!'.
|
||||
|
||||
<tag/icmptypes <em>types</em>/Matches if the ICMP type is present in
|
||||
the list <em>types</em>. The list may be specified as any combination
|
||||
of ranges and/or individual types separated by commas. Commonly used
|
||||
ICMP types are: <bf>0</bf> echo reply (ping reply), <bf>5</bf>
|
||||
redirect, <bf>8</bf> echo request (ping request), and <bf>11</bf>
|
||||
time exceeded (used to indicate TTL expiration as with
|
||||
<tt>traceroute(8)</tt>).
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect2><heading>Listing the IPFW rules</heading>
|
||||
|
||||
<p>The syntax for this form of the command is:
|
||||
<tscreen>
|
||||
ipfw [-atN] l
|
||||
</tscreen>
|
||||
|
||||
<p>There are three valid flags when using this form of the command:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/-a/While listing, show counter values. This option is the only
|
||||
way to see accounting counters.
|
||||
|
||||
<tag/-t/Display the last match times for each chain entry. The time
|
||||
listing is incompatible with the input syntax used by the
|
||||
<tt>ipfw(8)</tt> utility.
|
||||
|
||||
<tag/-N/Attempt to resolve given addresses and service names.
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect2><heading>Flushing the IPFW rules</heading>
|
||||
|
||||
<p>The syntax for flushing the chain is:
|
||||
<tscreen>
|
||||
ipfw flush
|
||||
</tscreen>
|
||||
|
||||
<p>This causes all entries in the firewall chain to be removed except
|
||||
the fixed default policy enforced by the kernel (index 65535). Use
|
||||
caution when flushing rules, the default deny policy will leave your
|
||||
system cut off from the network until allow entries are added to the
|
||||
chain.
|
||||
|
||||
<sect2><heading>Clearing the IPFW packet counters</heading>
|
||||
|
||||
<p>The syntax for clearing one or more packet counters is:
|
||||
<tscreen>
|
||||
ipfw zero [index]
|
||||
</tscreen>
|
||||
|
||||
<p>When used without an <em>index</em> argument, all packet counters
|
||||
are cleared. If an <em>index</em> is supplied, the clearing operation
|
||||
only affects a specific chain entry.
|
||||
|
||||
<sect1><heading>Example commands for ipfw</heading>
|
||||
|
||||
<p>This command will deny all packets from the host
|
||||
<bf>evil.hacker.org</bf> to the telnet port of the host
|
||||
<bf>nice.people.org</bf> by being forwarded by the router:
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw add deny tcp from evil.hacker.org to nice.people.org 23
|
||||
</verb></tscreen>
|
||||
|
||||
<p>The next example denies and logs any TCP traffic from the entire
|
||||
<bf>hacker.org</bf> network (a class C) to the <bf>nice.people.org</bf>
|
||||
machine (any port).
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw add deny log tcp from evil.hacker.org/24 to nice.people.org
|
||||
</verb></tscreen>
|
||||
|
||||
If you do not want people sending X sessions to your internal network
|
||||
(a subnet of a class C), the following command will do the necessary
|
||||
filtering:
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw add deny from any to my.org/28 6000 setup
|
||||
</verb></tscreen>
|
||||
|
||||
To allow access to the SUP server on <bf>sup.FreeBSD.ORG</bf>, use the
|
||||
following command:
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw add accept from any to sup.FreeBSD.ORG 871
|
||||
</verb></tscreen>
|
||||
|
||||
To see the accounting records:
|
||||
<tscreen><verb>
|
||||
ipfw -a list
|
||||
</verb></tscreen>
|
||||
or in the short form
|
||||
<tscreen><verb>
|
||||
ipfw -a l
|
||||
</verb></tscreen>
|
||||
You can also see the last time a chain entry was matched with
|
||||
<tscreen><verb>
|
||||
ipfw -at l
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>Building a packet filtering firewall</heading>
|
||||
|
||||
<p><quote><bf>Note:</bf> The following suggestions are just that:
|
||||
suggestions. The requirements of each firewall are different and I
|
||||
cannot tell you how to build a firewall to meet your particular
|
||||
requirements.</quote>
|
||||
|
||||
<p>When initially setting up your firewall, unless you have a test
|
||||
bench setup where you can configure your firewall host in a controlled
|
||||
environment, I strongly recommend you use the logging version of the
|
||||
commands and enable logging in the kernel. This will allow you to
|
||||
quickly identify problem areas and cure them without too much
|
||||
disruption. Even after the initial setup phase is complete, I
|
||||
recommend using the logging for of `deny' as it allows tracing of
|
||||
possible attacks and also modification of the firewall rules if your
|
||||
requirements alter.
|
||||
|
||||
<quote><bf>Note:</BF> If you use the logging versions of the
|
||||
<bf>accept</bf> command, it can generate <em>large</em> amounts
|
||||
of log data as one log line will be generated for every packet
|
||||
that passes through the firewall, so large ftp/http transfers,
|
||||
etc, will really slow the system down. It also increases the
|
||||
latencies on those packets as it requires more work to be done by
|
||||
the kernel before the packet can be passed on. syslogd with also
|
||||
start using up a lot more processor time as it logs all the extra
|
||||
data to disk, and it could quite easily fill the partition
|
||||
<tt>/var/log</tt> is located on.</quote>
|
||||
|
||||
<p>As currently supplied, FreeBSD does not have the ability to
|
||||
load firewall rules at boot time. My suggestion is to put a call
|
||||
to a shell script in the <tt>/etc/netstart</tt> script. Put the
|
||||
call early enough in the netstart file so that the firewall is
|
||||
configured before any of the IP interfaces are configured. This
|
||||
means that there is no window during which time your network is
|
||||
open.
|
||||
|
||||
<p>The actual script used to load the rules is entirely up to
|
||||
you. There is currently no support in the <tt>ipfw</tt> utility for
|
||||
loading multiple rules in the one command. The system I use is to use
|
||||
the command:
|
||||
|
||||
<tscreen><verb>
|
||||
# ipfw list
|
||||
</verb></tscreen>
|
||||
|
||||
to write a list of the current rules out to a file, and then use a
|
||||
text editor to prepend ``<tt>ipfw </tt>'' before all the lines. This
|
||||
will allow the script to be fed into /bin/sh and reload the rules into
|
||||
the kernel. Perhaps not the most efficient way, but it works.
|
||||
|
||||
<p>The next problem is what your firewall should actually <bf>DO</bf>!
|
||||
This is largely dependent on what access to your network you want to
|
||||
allow from the outside, and how much access to the outside world you
|
||||
want to allow from the inside. Some general rules are:
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>Block all incoming access to ports below 1024 for TCP. This is
|
||||
where most of the security sensitive services are, like finger, SMTP
|
||||
(mail) and telnet.
|
||||
|
||||
<item>Block <bf>all</bf> incoming UDP traffic. There are very few
|
||||
useful services that travel over UDP, and what useful traffic there is
|
||||
is normally a security threat (e.g. Suns RPC and NFS protocols). This
|
||||
has its disadvantages also, since UDP is a connectionless protocol,
|
||||
denying incoming UDP traffic also blocks the replies to outgoing UDP
|
||||
traffic. This can cause a problem for people (on the inside)
|
||||
using external archie (prospero) servers. If you want to allow access
|
||||
to archie, you'll have to allow packets coming from ports 191 and 1525
|
||||
to any internal UDP port through the firewall. ntp is another service
|
||||
you may consider allowing through, which comes from port 123.
|
||||
|
||||
<item>Block traffic to port 6000 from the outside. Port 6000 is the
|
||||
port used for access to X11 servers, and can be a security threat
|
||||
(especially if people are in the habit of doing <tt>xhost +</tt> on
|
||||
their workstations). X11 can actually use a range of ports starting at
|
||||
6000, the upper limit being how many X displays you can run on the
|
||||
machine. The upper limit as defined by RFC 1700 (Assigned Numbers) is
|
||||
6063.
|
||||
|
||||
<item>Check what ports any internal servers use (e.g. SQL servers,
|
||||
etc). It is probably a good idea to block those as well, as they
|
||||
normally fall outside the 1-1024 range specified above.
|
||||
|
||||
</itemize>
|
||||
|
||||
<p>Another checklist for firewall configuration is available from CERT
|
||||
at <htmlurl url="ftp://ftp.cert.org/pub/tech_tips/packet_filtering"
|
||||
name="ftp://ftp.cert.org/pub/tech_tips/packet_filtering">
|
||||
|
||||
<p>As I said above, these are only <em>guidelines</em>. You will have
|
||||
to decide what filter rules you want to use on your firewall
|
||||
yourself. I cannot accept ANY responsibility if someone breaks into
|
||||
your network, even if you follow the advice given above.
|
||||
@ -1,5 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>* Glossary<label id="glossary"></heading>
|
||||
|
||||
@ -1,25 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>FreeBSD Project goals<label id="goals"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;</em>.
|
||||
|
||||
<p>The goals of the FreeBSD Project are to provide software that may
|
||||
be used for any purpose and without strings attached. Many of us
|
||||
have a significant investment in the code (and project) and would
|
||||
certainly not mind a little financial renumeration now and then,
|
||||
but we're definitely not prepared to insist on it. We believe
|
||||
that our first and foremost "mission" is to provide code to any
|
||||
and all comers, and for whatever purpose, so that the code gets
|
||||
the widest possible use and provides the widest possible benefit.
|
||||
This is, I believe, one of the most fundamental goals of Free
|
||||
Software and one that we enthusiastically support.
|
||||
|
||||
<p>That code in our source tree which falls under the GNU Public License
|
||||
(GPL) or GNU Library Public License (GLPL) comes with slightly more
|
||||
strings attached, though at least on the side of enforced
|
||||
access rather than the usual opposite. Due to the additional
|
||||
complexities that can evolve in the commercial use of GPL software,
|
||||
we do, however, endeavor to replace such software with submissions
|
||||
under the more relaxed BSD copyright whenever possible.
|
||||
@ -1,181 +0,0 @@
|
||||
<!-- $Id: handbook.sgml,v 1.75 1997/05/09 06:19:03 max Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!-- Conditional flags for this version of the document -->
|
||||
<!ENTITY % boothelp.only "IGNORE">
|
||||
<!ENTITY % handbook.only "INCLUDE">
|
||||
|
||||
<!-- Entity shorthand for authors' names and email addresses -->
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
<!-- Entity shorthand for mailing list email addresses -->
|
||||
<!ENTITY % lists SYSTEM "lists.sgml">
|
||||
%lists;
|
||||
|
||||
<!-- Entity definitions for all the parts -->
|
||||
<!ENTITY % sections SYSTEM "sections.sgml">
|
||||
%sections;
|
||||
|
||||
<!-- The currently released version of FreeBSD -->
|
||||
<!ENTITY rel.current CDATA "2.2.2">
|
||||
|
||||
]>
|
||||
|
||||
<linuxdoc>
|
||||
<book>
|
||||
|
||||
<title>FreeBSD Handbook</title>
|
||||
<author>
|
||||
<name>The FreeBSD Documentation Project</name>
|
||||
</author>
|
||||
<date>May 1997</date>
|
||||
|
||||
<abstract>Welcome to FreeBSD! This handbook covers the
|
||||
installation and day to day use of <bf>FreeBSD Release
|
||||
&rel.current;</bf>.
|
||||
|
||||
This manual is a <bf>work in progress</bf> and is the
|
||||
work of many individuals. Many sections do not yet exist
|
||||
and some of those that do exist need to be updated. If
|
||||
you are interested in helping with this project, send
|
||||
email to the &a.doc; The latest version of this
|
||||
document is always available from
|
||||
the <url url="http://www.FreeBSD.ORG/" name="FreeBSD World Wide
|
||||
Web server">. It may also be downloaded in plain text, postscript
|
||||
or HTML from the <url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs"
|
||||
name="FreeBSD FTP server"> or one of the numerous
|
||||
<ref id="mirrors-ftp" name="mirror sites">. You may also want to
|
||||
<url url="/search.html" name="Search the Handbook">.
|
||||
|
||||
</abstract>
|
||||
<toc>
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>Getting Started</heading>
|
||||
|
||||
<chapt><heading>Introduction</heading>
|
||||
<p>FreeBSD is a 4.4BSD-Lite based operating system for Intel
|
||||
architecture (x86) based PCs. For an overview of FreeBSD, see
|
||||
<ref id="nutshell" name="FreeBSD in a nutshell">. For a
|
||||
history of the project, read <ref id="history"
|
||||
name="a brief history of FreeBSD">. To see a description of the
|
||||
latest release, read <ref id="relnotes"
|
||||
name="about the current release">. If you're interested
|
||||
in contributing something to the FreeBSD project (code, equipment,
|
||||
sacks of unmarked bills), please see about <ref id="submitters"
|
||||
name="contributing to FreeBSD">.
|
||||
|
||||
&nutshell;
|
||||
&history;
|
||||
&goals;
|
||||
&development;
|
||||
&relnotes;
|
||||
|
||||
&install;
|
||||
&basics;
|
||||
|
||||
&ports;
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>System Administration</heading>
|
||||
|
||||
&kernelconfig;
|
||||
<chapt><heading>Security</heading>
|
||||
&crypt;
|
||||
&skey;
|
||||
&kerberos;
|
||||
&firewalls;
|
||||
|
||||
&printing;
|
||||
|
||||
"as;
|
||||
<chapt><heading>The X Window System</heading>
|
||||
<p>Pending the completion of this section, please refer to
|
||||
documentation supplied by the <url url="http://www.xfree86.org/"
|
||||
name="The XFree86 Project, Inc">.
|
||||
|
||||
&hw;
|
||||
|
||||
<chapt><heading>Localization<label id="l10n"></heading>
|
||||
&russian;
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>Network Communications</heading>
|
||||
|
||||
<chapt><heading>Serial Communications</heading>
|
||||
&serial;
|
||||
&term;
|
||||
&dialup;
|
||||
&dialout;
|
||||
|
||||
<chapt><heading>PPP and SLIP</heading>
|
||||
|
||||
<p>If your connection to the Internet is through a modem, or
|
||||
you wish to provide other people with dialup connections to
|
||||
the Internet using FreeBSD, you have the option of using PPP
|
||||
or SLIP. Furthermore, two varieties of PPP are provided:
|
||||
<em>user</em> (sometimes referred to as iijppp) and
|
||||
<em>kernel</em>. The procedures for configuring both types
|
||||
of PPP, and for setting up SLIP are described in this
|
||||
chapter.
|
||||
|
||||
&userppp;
|
||||
&ppp;
|
||||
&slipc;
|
||||
&slips;
|
||||
|
||||
<chapt><heading>Advanced networking</heading>
|
||||
&routing;
|
||||
&nfs;
|
||||
&diskless;
|
||||
&isdn;
|
||||
|
||||
&mail;
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>Advanced topics</heading>
|
||||
<chapt><heading>The Cutting Edge: FreeBSD-current and FreeBSD-stable</heading>
|
||||
<p>FreeBSD is under constant development between releases. For
|
||||
people who want to be on the cutting edge, there are several
|
||||
easy mechanisms for keeping your system in sync with the latest
|
||||
developments. Be warned: the cutting edge is not for everyone!
|
||||
This chapter will help you decide if you want to track the development
|
||||
system, or stick with one of the released versions.</p>
|
||||
|
||||
¤t;
|
||||
&stable;
|
||||
&synching;
|
||||
</chapt>
|
||||
|
||||
&submitters;
|
||||
&policies;
|
||||
&kernelopts;
|
||||
&kerneldebug;
|
||||
&linuxemu;
|
||||
<chapt><heading>FreeBSD internals</heading>
|
||||
&booting;
|
||||
&memoryuse;
|
||||
&dma;
|
||||
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>Appendices</heading>
|
||||
|
||||
&mirrors;
|
||||
&bibliography;
|
||||
&eresources;
|
||||
&contrib;
|
||||
&pgpkeys;
|
||||
|
||||
<!-- &glossary; -->
|
||||
|
||||
</book>
|
||||
</linuxdoc>
|
||||
@ -1,91 +0,0 @@
|
||||
<!-- $Id: history.sgml,v 1.21 1997/02/22 12:58:35 peter Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>A brief history of FreeBSD<label id="history"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;</em>.
|
||||
|
||||
The FreeBSD project had its genesis in the early part of 1993,
|
||||
partially as an outgrowth of the "Unofficial 386BSD Patchkit" by the
|
||||
patchkit's last 3 coordinators: Nate Williams, Rod Grimes and myself.
|
||||
|
||||
Our original goal was to produce an intermediate snapshot of 386BSD in
|
||||
order to fix a number of problems with it that the patchkit mechanism
|
||||
just was not capable of solving. Some of you may remember the early
|
||||
working title for the project being "386BSD 0.5" or "386BSD Interim"
|
||||
in reference to that fact.
|
||||
|
||||
386BSD was Bill Jolitz's operating system, which had been up to that
|
||||
point suffering rather severely from almost a year's worth of neglect.
|
||||
As the patchkit swelled ever more uncomfortably with each passing day,
|
||||
we were in unanimous agreement that something had to be done and
|
||||
decided to try and assist Bill by providing this interim "cleanup"
|
||||
snapshot. Those plans came to a rude halt when Bill Jolitz suddenly
|
||||
decided to withdraw his sanction from the project and without any
|
||||
clear indication of what would be done instead.
|
||||
|
||||
It did not take us long to decide that the goal remained worthwhile,
|
||||
even without Bill's support, and so we adopted the name "FreeBSD",
|
||||
coined by David Greenman. Our initial objectives were set after
|
||||
consulting with the system's current users and, once it became clear
|
||||
that the project was on the road to perhaps even becoming a reality,
|
||||
I contacted Walnut Creek CDROM with an eye towards improving
|
||||
FreeBSD's distribution channels for those many unfortunates without
|
||||
easy access to the Internet. Walnut Creek CDROM not only supported
|
||||
the idea of distributing FreeBSD on CD but went so far as to provide
|
||||
the project with a machine to work on and a fast Internet connection.
|
||||
Without Walnut Creek CDROM's almost unprecedented degree of faith in
|
||||
what was, at the time, a completely unknown project, it is quite
|
||||
unlikely that FreeBSD would have gotten as far, as fast, as it
|
||||
has today.
|
||||
|
||||
The first CDROM (and general net-wide) distribution was FreeBSD 1.0,
|
||||
released in December of 1993. This was based on the 4.3BSD-Lite
|
||||
("Net/2") tape from U.C. Berkeley, with many components also provided by
|
||||
386BSD and the Free Software Foundation. It was a fairly reasonable
|
||||
success for a first offering, and we followed it with the highly successful
|
||||
FreeBSD 1.1 release in May of 1994.
|
||||
|
||||
Around this time, some rather unexpected storm clouds formed on the
|
||||
horizon as Novell and U.C. Berkeley settled their long-running lawsuit
|
||||
over the legal status of the Berkeley Net/2 tape. A condition of that
|
||||
settlement was U.C. Berkeley's concession that large parts of Net/2
|
||||
were "encumbered" code and the property of Novell, who had in turn acquired
|
||||
it from AT&T some time previously. What Berkeley got in return was
|
||||
Novell's "blessing" that the 4.4BSD-Lite release, when it was finally
|
||||
released, would be declared unencumbered and all existing Net/2 users
|
||||
would be strongly encouraged to switch. This included FreeBSD, and the
|
||||
project was given until the end of July 1994 to stop shipping its own
|
||||
Net/2 based product. Under the terms of that agreement, the project
|
||||
was allowed one last release before the deadline, that release being
|
||||
FreeBSD 1.1.5.1.
|
||||
|
||||
FreeBSD then set about the arduous task of literally re-inventing itself
|
||||
from a completely new and rather incomplete set of 4.4BSD-Lite bits. The
|
||||
"Lite" releases were light in part because Berkeley's CSRG had removed
|
||||
large chunks of code required for actually constructing a bootable running
|
||||
system (due to various legal requirements) and the fact that the Intel
|
||||
port of 4.4 was highly incomplete. It took the project until December of 1994
|
||||
to make this transition, and in January of 1995 it released FreeBSD 2.0 to
|
||||
the net and on CDROM. Despite being still more than a little rough around
|
||||
the edges, the release was a significant success and was followed by the more
|
||||
robust and easier to install FreeBSD 2.0.5 release in June of 1995.
|
||||
|
||||
<em>Where to from here?</em>
|
||||
|
||||
We released FreeBSD 2.1.5 in August of 1996, and it appeared to be
|
||||
popular enough among the ISP and commercial communities that another
|
||||
release along the 2.1-stable branch was merited. This was FreeBSD 2.1.7.1,
|
||||
released in February 1997 and capping the end of mainstream development
|
||||
on 2.1-stable. Now in maintenance mode, only security enhancements and other
|
||||
critical bug fixes will be done on this branch (RELENG_2_1_0).
|
||||
|
||||
FreeBSD 2.2 was branched from the development mainline ("-current") in
|
||||
November 1996 as the RELENG_2_2 branch, and the first full release
|
||||
(2.2.1) was released in April, 1997. Further releases along the 2.2 branch
|
||||
are planned throughout the Summer and Fall of '97 and into early
|
||||
Winter, at which point the first 3.0 release will appear.
|
||||
|
||||
Long term development projects for everything from SMP to DEC ALPHA support
|
||||
will continue to take place in the 3.0-current branch and SNAPshot releases
|
||||
of 3.0 on CDROM (and, of course, on the net) will begin to appear in May, 1997.
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,819 +0,0 @@
|
||||
<!-- $Id: install.sgml,v 1.52 1997/03/07 12:35:57 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'>
|
||||
-->
|
||||
<chapt><heading>Installing FreeBSD<label id="install"></heading>
|
||||
|
||||
<p>So, you would like to try out FreeBSD on your system?
|
||||
This section is a quick-start guide for what you need to
|
||||
do. FreeBSD can be installed from a variety of media
|
||||
including CD-ROM, floppy disk, magnetic tape, an MS-DOS
|
||||
partition, and if you have a network connection, via
|
||||
anonymous ftp or NFS.
|
||||
|
||||
Regardless of the installation media you choose, you can
|
||||
get started by downloading the <bf>installation disk</bf>
|
||||
as described below. Booting your computer with disk will
|
||||
provide important information about compatibility between
|
||||
FreeBSD and your hardware which could dictate which
|
||||
installation options are possible. It can also provide
|
||||
early clues to compatibility problems that could prevent
|
||||
FreeBSD running on your system at all. If you plan on
|
||||
installing via anonymous FTP, then this installation disk
|
||||
is all you need to download.
|
||||
|
||||
For more information on obtaining the FreeBSD distribution
|
||||
itself, please see <ref id="mirrors" name="Obtaining
|
||||
FreeBSD"> in the Appendix.
|
||||
|
||||
So, to get the show on the road, follow these steps:
|
||||
<enum>
|
||||
|
||||
<item>Review the <ref id="install:hw" name="supported
|
||||
configurations"> section of this installation guide to
|
||||
be sure that your hardware is supported by FreeBSD. It
|
||||
may be helpful to make a list of any special cards you
|
||||
have installed, such as SCSI controllers, Ethernet
|
||||
adapters or sound cards. This list should include
|
||||
relevant configuration parameters such as interrupts
|
||||
(IRQ) and IO port addresses.<P></P></item>
|
||||
|
||||
<item>Download the <url
|
||||
url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/&rel.current;-RELEASE/floppies/boot.flp"
|
||||
name="installation boot disk image"> file to your hard
|
||||
drive, and be sure to tell your browser to
|
||||
<em>save</em> rather than <em>display</em>.
|
||||
<bf>Note:</bf> This disk image can only be used with
|
||||
1.44 megabyte 3.5 inch floppy disks.<P></P></item>
|
||||
|
||||
<item>Make the installation boot disk from the image file:
|
||||
<itemize>
|
||||
<item>If you are using MS-DOS download
|
||||
<url
|
||||
url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/tools/fdimage.exe"
|
||||
name="fdimage.exe">, then run it like so:
|
||||
<tscreen><verb>
|
||||
E:\> tools\fdimage floppies\boot.flp a:
|
||||
</verb></tscreen> The
|
||||
program will format the A: drive and then copy the
|
||||
boot.flp image onto it (assuming that you're at the top
|
||||
level of a FreeBSD distribution and the floppy images
|
||||
live in the floppies subdirectory).<P></P></item>
|
||||
|
||||
<item>If you are using a UNIX system:
|
||||
<tscreen>
|
||||
% dd if=boot.flp of=<em>disk_device</em>
|
||||
</tscreen>
|
||||
where <em>disk_device</em> is the <tt>/dev</tt>
|
||||
entry for the floppy drive. On FreeBSD systems, this
|
||||
is <tt>/dev/fd0</tt> for the A: drive and
|
||||
<tt>/dev/fd1</tt> for the B: drive.<P></P></item>
|
||||
</itemize>
|
||||
<P></P></item>
|
||||
|
||||
<item>With the installation disk in the A: drive, reboot your
|
||||
computer. You should get a boot prompt something like this:
|
||||
<tscreen>
|
||||
>> FreeBSD BOOT ...<newline>
|
||||
Usage: [[[0:][wd](0,a)]/kernel][-abcCdhrsv]<newline>
|
||||
Use 1:sd(0,a)kernel to boot sd0 if it is BIOS drive 1<newline>
|
||||
Use ? for file list or press Enter for defaults<newline>
|
||||
Boot:
|
||||
</tscreen>
|
||||
If you do <em>not</em> type anything, FreeBSD will automatically boot
|
||||
with its default configuration after a delay of about
|
||||
five seconds. As FreeBSD boots, it probes your computer
|
||||
to determine what hardware is installed. The results of
|
||||
this probing is displayed on the screen.<P></P></item>
|
||||
|
||||
<item>When the booting process is finished, The main FreeBSD
|
||||
installation menu will be displayed.</item>
|
||||
|
||||
</enum>
|
||||
|
||||
<p><bf>If something goes wrong...</bf>
|
||||
|
||||
<p>Due to limitations of the PC architecture, it is
|
||||
impossible for probing to be 100 percent reliable. In the event
|
||||
that your hardware is incorrectly identified, or that the
|
||||
probing causes your computer to lock up, first check the
|
||||
<ref id="install:hw" name="supported
|
||||
configurations"> section of this installation guide to be
|
||||
sure that your hardware is indeed supported by FreeBSD.
|
||||
|
||||
<p>If your hardware is supported, reset the computer and when
|
||||
the <tt>Boot:</tt> prompt comes up, type <bf>-c</bf>. This puts
|
||||
FreeBSD into a configuration mode where you can supply
|
||||
hints about your hardware. The FreeBSD kernel on the
|
||||
installation disk is configured assuming that most hardware
|
||||
devices are in their factory default configuration in terms
|
||||
of IRQs, IO addresses and DMA channels. If your hardware
|
||||
has been reconfigured, you will most likely need to use the
|
||||
<bf>-c</bf> option at boot to tell FreeBSD where things are.
|
||||
|
||||
<p>It is also possible that a probe for a device not present
|
||||
will cause a later probe for another device that is present
|
||||
to fail. In that case, the probes for the conflicting
|
||||
driver(s) should be disabled.
|
||||
|
||||
<p>In the configuration mode, you can:
|
||||
|
||||
<itemize>
|
||||
<item>List the device drivers installed in the kernel.</item>
|
||||
<item>Disable device drivers for hardware not present in your
|
||||
system.</item>
|
||||
<item>Change the IRQ, DRQ, and IO port addresses used by a
|
||||
device driver.</item>
|
||||
</itemize>
|
||||
|
||||
<p>While at the <tt>config></tt> prompt, type
|
||||
<tt>help</tt> for more information on the available
|
||||
commands. After adjusting the kernel to match how you have
|
||||
your hardware configured, type <tt>quit</tt> at the
|
||||
<tt>config></tt> prompt to continue booting with the new
|
||||
settings.
|
||||
|
||||
After FreeBSD has been installed, changes made in the
|
||||
configuration mode will be permanent so you do not have
|
||||
to reconfigure every time you boot. Even so, it is likely
|
||||
that you will want to build a custom kernel to optimize the
|
||||
performance of your system. See <ref id="kernelconfig"
|
||||
name="Kernel configuration"> for more information on
|
||||
creating custom kernels.
|
||||
|
||||
<sect><heading>Supported Configurations<label id="install:hw"></heading>
|
||||
|
||||
<p>FreeBSD currently runs on a wide variety of ISA, VLB,
|
||||
EISA and PCI bus based PC's, ranging from 386sx to
|
||||
Pentium class machines (though the 386sx is not
|
||||
recommended). Support for generic IDE or ESDI drive
|
||||
configurations, various SCSI controller, network and
|
||||
serial cards is also provided.
|
||||
|
||||
A minimum of four megabytes of RAM is required to run FreeBSD.
|
||||
To run the X Window System, eight megabytes of RAM is the
|
||||
recommended minimum.
|
||||
|
||||
Following is a list of all disk controllers and Ethernet
|
||||
cards currently known to work with FreeBSD. Other
|
||||
configurations may very well work, and we have simply not
|
||||
received any indication of this.
|
||||
|
||||
<sect1><heading>Disk Controllers</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
<item>WD1003 (any generic MFM/RLL)
|
||||
<item>WD1007 (any generic IDE/ESDI)
|
||||
<item>IDE
|
||||
<item>ATA
|
||||
|
||||
<item>Adaptec 1505 ISA SCSI controller
|
||||
<item>Adaptec 152x series ISA SCSI controllers
|
||||
<item>Adaptec 1535 ISA SCSI controllers
|
||||
<item>Adaptec 154x series ISA SCSI controllers
|
||||
<item>Adaptec 174x series EISA SCSI controller in
|
||||
standard and enhanced mode.
|
||||
<item>Adaptec 274x/284x/2940/2940U/3940
|
||||
(Narrow/Wide/Twin)
|
||||
series EISA/VLB/PCI SCSI controllers
|
||||
<item>Adaptec AIC7850 on-board SCSI controllers
|
||||
<item>Adaptec
|
||||
<!-- AIC-6260 and - actually not working, joerg -->
|
||||
AIC-6360 based boards,
|
||||
which includes the AHA-152x and SoundBlaster SCSI
|
||||
cards.
|
||||
|
||||
<bf>Note:</bf> You cannot boot from the
|
||||
SoundBlaster cards as they have no on-board BIOS,
|
||||
which is necessary for mapping the boot device into
|
||||
the system BIOS I/O vectors. They are perfectly
|
||||
usable for external tapes, CDROMs, etc, however.
|
||||
The same goes for any other AIC-6x60 based card
|
||||
without a boot ROM. Some systems DO have a boot
|
||||
ROM, which is generally indicated by some sort of
|
||||
message when the system is first powered up or
|
||||
reset. Check your system/board documentation for
|
||||
more details.
|
||||
|
||||
<item>Buslogic 545S & 545c
|
||||
<bf>Note:</bf> that Buslogic was formerly known as "Bustek".
|
||||
<item>Buslogic 445S/445c VLB SCSI controller
|
||||
<item>Buslogic 742A/747S/747c EISA SCSI controller.
|
||||
<item>Buslogic 946c PCI SCSI controller
|
||||
<item>Buslogic 956c PCI SCSI controller
|
||||
|
||||
<item>NCR 53C810/53C815/53C825/53C860/53C875 PCI SCSI controller.
|
||||
<item>NCR5380/NCR53400 (``ProAudio Spectrum'') SCSI controller.
|
||||
|
||||
<item>DTC 3290 EISA SCSI controller in 1542 emulation mode.
|
||||
|
||||
<item>UltraStor 14F/24F/34F SCSI controllers.
|
||||
|
||||
<item>Seagate ST01/02 SCSI controllers.
|
||||
|
||||
<item>Future Domain 8xx/950 series SCSI controllers.
|
||||
|
||||
<item>WD7000 SCSI controllers.
|
||||
|
||||
</itemize>
|
||||
|
||||
With all supported SCSI controllers, full support is
|
||||
provided for SCSI-I & SCSI-II peripherals,
|
||||
including Disks, tape drives (including DAT) and CD ROM
|
||||
drives.
|
||||
|
||||
The following CD-ROM type systems are supported at this
|
||||
time:
|
||||
|
||||
<itemize>
|
||||
<item>SoundBlaster SCSI and ProAudio Spectrum SCSI (<tt>cd</tt>)
|
||||
<item>Mitsumi (all models) proprietary interface (<tt>mcd</tt>)
|
||||
<item>Matsushita/Panasonic (Creative)
|
||||
CR-562/CR-563 proprietary interface (<tt>matcd</tt>)
|
||||
<item>Sony proprietary interface (<tt>scd</tt>)
|
||||
<item>ATAPI IDE interface
|
||||
(experimental and should be considered ALPHA quality!)
|
||||
(<tt>wcd</tt>)
|
||||
</itemize>
|
||||
|
||||
<sect1><heading>Ethernet cards</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
|
||||
<item>Allied-Telesis AT1700 and RE2000 cards
|
||||
|
||||
<item>SMC Elite 16 WD8013 Ethernet interface, and
|
||||
most other WD8003E, WD8003EBT, WD8003W, WD8013W,
|
||||
WD8003S, WD8003SBT and WD8013EBT based clones. SMC
|
||||
Elite Ultra is also supported.
|
||||
|
||||
<item>DEC EtherWORKS III NICs (DE203, DE204, and DE205)
|
||||
<item>DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422)
|
||||
<item>DEC DC21040/DC21041/DC21140 based NICs:
|
||||
<itemize>
|
||||
<item>ASUS PCI-L101-TB
|
||||
<item>Accton ENI1203
|
||||
<item>Cogent EM960PCI
|
||||
<item>Compex CPXPCI/32C
|
||||
<item>D-Link DE-530
|
||||
<item>DEC DE435
|
||||
<item>Danpex EN-9400P3
|
||||
<item>JCIS Condor JC1260
|
||||
<item>Linksys EtherPCI
|
||||
<item>Mylex LNP101
|
||||
<item>SMC EtherPower 10/100 (Model 9332)
|
||||
<item>SMC EtherPower (Model 8432)
|
||||
<item>SMC EtherPower (2)
|
||||
<item>Zynx ZX342
|
||||
</itemize>
|
||||
<item>DEC FDDI (DEFPA/DEFEA) NICs
|
||||
|
||||
<item>Fujitsu FMV-181 and FMV-182
|
||||
|
||||
<item>Fujitsu MB86960A/MB86965A
|
||||
|
||||
<item>Intel EtherExpress
|
||||
|
||||
<item>Intel EtherExpress Pro/100B 100Mbit.
|
||||
|
||||
<item>Isolan AT 4141-0 (16 bit)
|
||||
<item>Isolink 4110 (8 bit)
|
||||
|
||||
<item>Novell NE1000, NE2000, and NE2100 ethernet interface.
|
||||
|
||||
<item>3Com 3C501 cards
|
||||
|
||||
<item>3Com 3C503 Etherlink II
|
||||
|
||||
<item>3Com 3c505 Etherlink/+
|
||||
|
||||
<item>3Com 3C507 Etherlink 16/TP
|
||||
|
||||
<item>3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III
|
||||
|
||||
<item>3Com 3C590, 3C595 Etherlink III
|
||||
|
||||
<item>HP PC Lan Plus (27247B and 27252A)
|
||||
|
||||
<item>Toshiba ethernet cards
|
||||
|
||||
<item>PCMCIA ethernet cards from IBM and National
|
||||
Semiconductor are also supported.
|
||||
</itemize>
|
||||
|
||||
<p><em>Note:</em> FreeBSD does not currently support
|
||||
PnP (plug-n-play) features present on some ethernet
|
||||
cards. If your card has PnP and is giving you problems,
|
||||
try disabling its PnP features.
|
||||
|
||||
<sect1><heading>Miscellaneous devices</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
<item>AST 4 port serial card using shared IRQ.
|
||||
|
||||
<item>ARNET 8 port serial card using shared IRQ.
|
||||
|
||||
<item>BOCA IOAT66 6 port serial card using shared IRQ.
|
||||
|
||||
<item>BOCA 2016 16 port serial card using shared IRQ.
|
||||
|
||||
<item>Cyclades Cyclom-y Serial Board.
|
||||
|
||||
<item>STB 4 port card using shared IRQ.
|
||||
|
||||
<item>SDL Communications Riscom/8 Serial Board.
|
||||
|
||||
<item>SDL Communications RISCom/N2 and N2pci sync serial cards.
|
||||
|
||||
<item>Digiboard Sync/570i high-speed sync serial card.
|
||||
|
||||
<item>Decision-Computer Intl. "Eight-Serial" 8 port serial cards
|
||||
using shared IRQ.
|
||||
|
||||
<item>Adlib, SoundBlaster, SoundBlaster Pro,
|
||||
ProAudioSpectrum, Gravis UltraSound, Gravis UltraSound MAX
|
||||
and Roland MPU-401 sound cards.
|
||||
|
||||
<item>Matrox Meteor video frame grabber.
|
||||
|
||||
<item>Creative Labs Video spigot frame grabber.
|
||||
|
||||
<item>Omnimedia Talisman frame grabber.
|
||||
|
||||
<item>X-10 power controllers.
|
||||
|
||||
<item>PC joystick and speaker.
|
||||
</itemize>
|
||||
|
||||
FreeBSD does not currently support IBM's microchannel (MCA) bus.
|
||||
|
||||
<sect><heading>Preparing for the installation</heading>
|
||||
|
||||
<p>There are a number of different methods by which FreeBSD
|
||||
can be installed. The following describes what
|
||||
preparation needs to be done for each type.
|
||||
|
||||
<sect1><heading>Before installing from CDROM</heading>
|
||||
|
||||
<p>If your CDROM is of an unsupported type, then please
|
||||
skip to <ref id="install:msdos" name="MS-DOS Preparation">.
|
||||
|
||||
There is not a lot of preparatory work that needs to be done to
|
||||
successfully install from one of Walnut Creek's FreeBSD CDROMs (other
|
||||
CDROM distributions may work as well, though we cannot say for certain
|
||||
as we have no hand or say in how they are created). You can either
|
||||
boot into the CD installation directly from DOS using Walnut Creek's
|
||||
supplied ``install.bat'' batch file or you can make a boot floppy with
|
||||
the ``makeflp.bat'' command. [NOTE: If you are running
|
||||
FreeBSD 2.1-RELEASE and have an IDE CDROM, use the
|
||||
inst_ide.bat or atapiflp.bat batch files instead].
|
||||
|
||||
For the easiest interface of all (from DOS), type
|
||||
``view''. This will bring up a DOS menu utility that
|
||||
leads you through all the available options.
|
||||
|
||||
If you are creating the boot floppy from a UNIX machine,
|
||||
see <ref id="install" name="the beginning of this
|
||||
guide"> for examples. of how to create the boot floppy.
|
||||
|
||||
Once you have booted from DOS or floppy, you should then
|
||||
be able to select CDROM as the media type in the Media
|
||||
menu and load the entire distribution from CDROM. No
|
||||
other types of installation media should be required.
|
||||
|
||||
After your system is fully installed and you have rebooted
|
||||
from the hard disk, you can mount the CDROM at any time by
|
||||
typing: <tt>mount /cdrom</tt>
|
||||
|
||||
Before removing the CD again, also note that it is necessary to first
|
||||
type: <tt>umount /cdrom</tt>. Do not just remove it from the drive!
|
||||
|
||||
<quote><bf>Special note:</bf> Before invoking the
|
||||
installation, be sure that the CDROM is in the drive
|
||||
so that the install probe can find it. This is also
|
||||
true if you wish the CDROM to be added to the default
|
||||
system configuration automatically during the install
|
||||
(whether or not you actually use it as the
|
||||
installation media).
|
||||
</quote>
|
||||
|
||||
Finally, if you would like people to be able to FTP
|
||||
install FreeBSD directly from the CDROM in your
|
||||
machine, you will find it quite easy. After the machine
|
||||
is fully installed, you simply need to add the
|
||||
following line to the password file (using the vipw
|
||||
command):
|
||||
|
||||
<tscreen><verb>
|
||||
ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent
|
||||
</verb></tscreen>
|
||||
|
||||
Anyone with network connectivity to your machine (and permission
|
||||
to log into it) can now chose a Media type of FTP and type
|
||||
in: <tt>ftp://<em>your machine</em></tt> after picking ``Other''
|
||||
in the ftp sites menu.
|
||||
|
||||
<sect1><heading>Before installing from Floppy</heading>
|
||||
|
||||
<p>If you must install from floppy disks, either due to
|
||||
unsupported hardware or simply because you enjoy doing
|
||||
things the hard way, you must first prepare some
|
||||
floppies for the install.
|
||||
|
||||
You will need, at minimum, as many 1.44MB or 1.2MB floppies as
|
||||
it takes to hold all files in the bin (binary distribution)
|
||||
directory. If you are preparing these floppies under DOS, then
|
||||
THESE floppies *must* be formatted using the MS-DOS FORMAT
|
||||
command. If you are using Windows, use the Windows File
|
||||
Manager format command.
|
||||
|
||||
Do <em>not</em> trust Factory Preformatted floppies! Format
|
||||
them again yourself, just to make sure. Many problems
|
||||
reported by our users in the past have resulted from the use
|
||||
of improperly formatted media, which is why I am taking such
|
||||
special care to mention it here!
|
||||
|
||||
If you are creating the floppies from another FreeBSD machine,
|
||||
a format is still not a bad idea though you do nott need to put
|
||||
a DOS filesystem on each floppy. You can use the `disklabel'
|
||||
and `newfs' commands to put a UFS filesystem on them instead,
|
||||
as the following sequence of commands (for a 3.5" 1.44MB floppy
|
||||
disk) illustrates:
|
||||
|
||||
<tscreen><verb>
|
||||
fdformat -f 1440 fd0.1440
|
||||
disklabel -w -r fd0.1440 floppy3
|
||||
newfs -t 2 -u 18 -l 1 -i 65536 /dev/rfd0
|
||||
|
||||
(Use "fd0.1200" and "floppy5" for 5.25" 1.2MB disks).
|
||||
</verb></tscreen>
|
||||
|
||||
Then you can mount and write to them like any other file
|
||||
system.
|
||||
|
||||
After you have formatted the floppies, you will need to copy
|
||||
the files onto them. The distribution files are split into
|
||||
chunks conveniently sized so that 5 of them will fit on a
|
||||
conventional 1.44MB floppy. Go through all your floppies,
|
||||
packing as many files as will fit on each one, until you have
|
||||
got all the distributions you want packed up in this fashion.
|
||||
Each distribution should go into a subdirectory on the
|
||||
floppy, e.g.: <bf>a:\bin\bin.aa</bf>,
|
||||
<bf>a:\bin\bin.ab</bf>, and so on.
|
||||
|
||||
Once you come to the Media screen of the install,
|
||||
select ``Floppy'' and you will be prompted for the rest.
|
||||
|
||||
|
||||
|
||||
<sect1><heading>Before installing from a MS-DOS partition<label id="install:msdos"></heading>
|
||||
|
||||
<p>To prepare for installation from an MS-DOS partition,
|
||||
copy the files from the distribution into a directory
|
||||
called <tt>C:\FREEBSD</tt>. The directory tree structure
|
||||
of the CDROM must be partially reproduced within this directory
|
||||
so we suggest using the DOS <tt>xcopy</tt>
|
||||
command. For example, to prepare for a minimal installation of
|
||||
FreeBSD:
|
||||
<tscreen><verb>
|
||||
C> MD C:\FREEBSD
|
||||
C> XCOPY /S E:\BIN C:\FREEBSD\BIN\
|
||||
C> XCOPY /S E:\MANPAGES C:\FREEBSD\MANPAGES\
|
||||
</verb></tscreen>
|
||||
assuming that <tt>C:</tt> is where you have free space
|
||||
and <tt>E:</tt> is where your CDROM is mounted.
|
||||
|
||||
For as many `DISTS' you wish to install from MS-DOS
|
||||
(and you have free space for), install each one under
|
||||
<tt>C:\FREEBSD</tt> - the <tt>BIN</tt> dist is only the
|
||||
minimal requirement.
|
||||
|
||||
<sect1><heading>Before installing from QIC/SCSI Tape</heading>
|
||||
|
||||
<p>Installing from tape is probably the easiest method,
|
||||
short of an on-line install using FTP or a CDROM
|
||||
install. The installation program expects the files to
|
||||
be simply tar'ed onto the tape, so after getting all of
|
||||
the files for distribution you are interested in, simply
|
||||
tar them onto the tape with a command like:
|
||||
<tscreen>
|
||||
cd /freebsd/distdir<newline>
|
||||
tar cvf /dev/rwt0 (or /dev/rst0) dist1 .. dist2
|
||||
</tscreen>
|
||||
|
||||
When you go to do the installation, you should also
|
||||
make sure that you leave enough room in some temporary
|
||||
directory (which you will be allowed to choose) to
|
||||
accommodate the <bf>full</bf> contents of the tape you have
|
||||
created. Due to the non-random access nature of tapes,
|
||||
this method of installation requires quite a bit of
|
||||
temporary storage. You should expect to require as
|
||||
much temporary storage as you have stuff written on
|
||||
tape.
|
||||
|
||||
<quote><bf>Note:</bf> When going to do the
|
||||
installation, the tape must be in the drive
|
||||
<em>before</em> booting from the boot floppy. The
|
||||
installation probe may otherwise fail to find it.</quote>
|
||||
|
||||
|
||||
<sect1><heading>Before installing over a network</heading>
|
||||
|
||||
<p>You can do network installations over 3 types of
|
||||
communications links:
|
||||
<descrip>
|
||||
<tag>Serial port</tag> SLIP or PPP
|
||||
<tag>Parallel port</tag> PLIP (laplink cable)
|
||||
<tag>Ethernet</tag> A
|
||||
standard ethernet controller (includes some PCMCIA).
|
||||
</descrip>
|
||||
|
||||
SLIP support is rather primitive, and limited primarily
|
||||
to hard-wired links, such as a serial cable running
|
||||
between a laptop computer and another computer. The
|
||||
link should be hard-wired as the SLIP installation
|
||||
does not currently offer a dialing capability; that
|
||||
facility is provided with the PPP utility, which should
|
||||
be used in preference to SLIP whenever possible.
|
||||
|
||||
If you are using a modem, then PPP is almost certainly
|
||||
your only choice. Make sure that you have your service
|
||||
provider's information handy as you will need to know it
|
||||
fairly soon in the installation process. You will need
|
||||
to know, at the minimum, your service provider's IP
|
||||
address and possibly your own (though you can also
|
||||
leave it blank and allow PPP to negotiate it with your
|
||||
ISP). You also need to know how to use the various ``AT
|
||||
commands'' to dial the ISP with your particular modem as
|
||||
the PPP dialer provides only a very simple terminal
|
||||
emulator.
|
||||
|
||||
If a hard-wired connection to another FreeBSD (2.0R or
|
||||
later) machine is available, you might also consider
|
||||
installing over a ``laplink'' parallel port cable. The
|
||||
data rate over the parallel port is much higher than
|
||||
what is typically possible over a serial line (up to
|
||||
50k/sec), thus resulting in a quicker installation.
|
||||
|
||||
Finally, for the fastest possible network installation,
|
||||
an ethernet adaptor is always a good choice! FreeBSD
|
||||
supports most common PC ethernet cards, a table of
|
||||
supported cards (and their required settings) is
|
||||
provided in <ref id="install:hw" name="Supported
|
||||
Hardware">. If you are using one of the supported
|
||||
PCMCIA ethernet cards, also be sure that it is plugged
|
||||
in <em>before</em> the laptop is powered on! FreeBSD
|
||||
does not, unfortunately, currently support hot
|
||||
insertion of PCMCIA cards during installation.
|
||||
|
||||
You will also need to know your IP address on the
|
||||
network, the netmask value for your address class,
|
||||
and the name of your machine. Your system
|
||||
administrator can tell you which values to use for your
|
||||
particular network setup. If you will be referring to
|
||||
other hosts by name rather than IP address, you will also
|
||||
need a name server and possibly the address of a
|
||||
gateway (if you are using PPP, it is your provider's IP
|
||||
address) to use in talking to it. If you do not know
|
||||
the answers to all or most of these questions, then you
|
||||
should really probably talk to your system
|
||||
administrator <em>first</em> before trying this type of
|
||||
installation.
|
||||
|
||||
Once you have a network link of some sort working, the
|
||||
installation can continue over NFS or FTP.
|
||||
|
||||
<sect2><heading>Preparing for NFS installation</heading>
|
||||
|
||||
<p>NFS installation is fairly straight-forward: Simply
|
||||
copy the FreeBSD distribution files you want onto a
|
||||
server somewhere and then point the NFS media
|
||||
selection at it.
|
||||
|
||||
If this server supports only ``privileged port'' access
|
||||
(as is generally the default for Sun workstations),
|
||||
you will need to set this option in the Options menu
|
||||
before installation can proceed.
|
||||
|
||||
If you have a poor quality ethernet card which
|
||||
suffers from very slow transfer rates, you may also
|
||||
wish to toggle the appropriate Options flag.
|
||||
|
||||
In order for NFS installation to work, the server
|
||||
must support subdir mounts, e.g., if your FreeBSD
|
||||
&rel.current; distribution directory lives on:
|
||||
<bf>ziggy:/usr/archive/stuff/FreeBSD</bf> Then ziggy will have
|
||||
to allow the direct mounting of
|
||||
<bf>/usr/archive/stuff/FreeBSD</bf>, not just <bf>/usr</bf> or
|
||||
<bf>/usr/archive/stuff</bf>.
|
||||
|
||||
In FreeBSD's <bf>/etc/exports</bf> file, this is controlled by
|
||||
the ``<tt>-alldirs</tt>'' option. Other NFS servers may have
|
||||
different conventions. If you are getting
|
||||
`Permission Denied' messages from the server then
|
||||
it is likely that you do not have this enabled
|
||||
properly.
|
||||
|
||||
<sect2><heading>Preparing for FTP Installation</heading>
|
||||
|
||||
<p>FTP installation may be done from any mirror site
|
||||
containing a reasonably up-to-date version of FreeBSD
|
||||
&rel.current;. A full menu of reasonable choices from almost
|
||||
anywhere in the world is provided by the FTP site
|
||||
menu.
|
||||
|
||||
If you are installing from some other FTP site not
|
||||
listed in this menu, or you are having troubles
|
||||
getting your name server configured properly, you can
|
||||
also specify your own URL by selecting the ``Other''
|
||||
choice in that menu. A URL can also be a direct IP
|
||||
address, so the following would work in the absence
|
||||
of a name server:
|
||||
|
||||
<tscreen><verb>
|
||||
ftp://192.216.222.4/pub/FreeBSD/&rel.current;-RELEASE
|
||||
</verb></tscreen>
|
||||
|
||||
There are two FTP installation modes you can use:
|
||||
|
||||
<descrip>
|
||||
<tag>FTP Active</tag>
|
||||
|
||||
For all FTP transfers, use ``Active'' mode. This
|
||||
will not work through firewalls, but will often
|
||||
work with older ftp servers that do not support
|
||||
passive mode. If your connection hangs with
|
||||
passive mode (the default), try active!
|
||||
|
||||
<tag>FTP Passive</tag>
|
||||
|
||||
For all FTP transfers, use ``Passive'' mode. This
|
||||
allows the user to pass through firewalls that do
|
||||
not allow incoming connections on random port
|
||||
addresses.
|
||||
|
||||
</descrip>
|
||||
|
||||
<quote><bf>Note:</bf> Active and passive modes are
|
||||
not the same as a `proxy' connection, where a proxy
|
||||
FTP server is listening and forwarding FTP requests!</quote>
|
||||
|
||||
For a proxy FTP server, you should usually give name of
|
||||
the server you really want as a part of the username,
|
||||
after an @-sign. The proxy server then 'fakes' the real
|
||||
server. An example: Say you want to install from
|
||||
ftp.freebsd.org, using the proxy FTP server foo.bar.com,
|
||||
listening on port 1234.
|
||||
|
||||
In this case, you go to the options menu, set the FTP
|
||||
username to ftp@ftp.freebsd.org, and the password to your
|
||||
e-mail address. As your installation media, you specify
|
||||
FTP (or passive FTP, if the proxy support it), and the URL
|
||||
<tscreen><verb>
|
||||
ftp://foo.bar.com:1234/pub/FreeBSD
|
||||
</verb></tscreen>
|
||||
/pub/FreeBSD from ftp.freebsd.org is proxied under
|
||||
foo.bar.com, allowing you to install from _that_ machine
|
||||
(which fetch the files from ftp.freebsd.org as your
|
||||
installation requests them).
|
||||
|
||||
<sect><heading>Installing FreeBSD</heading>
|
||||
|
||||
<p>Once you have taken note of the appropriate
|
||||
preinstallation steps, you should be able to install
|
||||
FreeBSD without any further trouble.
|
||||
|
||||
Should this not be true, then you may wish to go back and
|
||||
re-read the relevant preparation section above
|
||||
for the installation media type you are trying to use,
|
||||
perhaps there is a helpful hint there that you missed the
|
||||
first time? If you are having hardware trouble, or
|
||||
FreeBSD refuses to boot at all, read the Hardware Guide
|
||||
provided on the boot floppy for a list of possible
|
||||
solutions.
|
||||
|
||||
The FreeBSD boot floppy contains all the on-line
|
||||
documentation you should need to be able to navigate
|
||||
through an installation and if it does not then we would
|
||||
like to know what you found most confusing. Send your
|
||||
comments to the &a.doc;.
|
||||
It is the objective of the
|
||||
FreeBSD installation program (sysinstall) to be
|
||||
self-documenting enough that painful ``step-by-step''
|
||||
guides are no longer necessary. It may take us a little
|
||||
while to reach that objective, but that is the objective!
|
||||
|
||||
Meanwhile, you may also find the following ``typical
|
||||
installation sequence'' to be helpful:
|
||||
|
||||
<enum>
|
||||
<item>Boot the boot floppy. After a boot sequence
|
||||
which can take anywhere from 30 seconds to 3
|
||||
minutes, depending on your hardware, you should be
|
||||
presented with a menu of initial choices. If the
|
||||
floppy does not boot at all, or the boot hangs at some
|
||||
stage, go read the Q&A section of the Hardware Guide
|
||||
for possible causes.
|
||||
|
||||
<item>Press F1. You should see some basic usage
|
||||
instructions on the menu system and general
|
||||
navigation. If you have not used this menu system
|
||||
before then PLEASE read this thoroughly!
|
||||
|
||||
<item>Select the Options item and set any special
|
||||
preferences you may have.
|
||||
|
||||
<item>Select a Novice, Custom or Express install, depending on
|
||||
whether or not you would like the installation to help
|
||||
you through a typical installation, give you a high degree of
|
||||
control over each step of the installation or simply whizz
|
||||
through it (using reasonable defaults when possible) as fast
|
||||
as possible. If you have never used FreeBSD before then the
|
||||
Novice installation method is most recommended.
|
||||
|
||||
<item>The final configuration menu choice allows you to
|
||||
further configure your FreeBSD installation by giving you
|
||||
menu-driven access to various system defaults. Some
|
||||
items, like networking, may be especially important
|
||||
if you did a CDROM/Tape/Floppy installation and have
|
||||
not yet configured your network interfaces (assuming
|
||||
you have any). Properly configuring such interfaces
|
||||
here will allow FreeBSD to come up on the network
|
||||
when you first reboot from the hard disk.
|
||||
</enum>
|
||||
|
||||
<sect><heading>MS-DOS user's Questions and Answers</heading>
|
||||
|
||||
<p>Many FreeBSD users wish to install FreeBSD on PCs inhabited
|
||||
by MS-DOS. Here are some commonly asked questions about
|
||||
installing FreeBSD on such systems.
|
||||
|
||||
<p><bf>Help! I have no space! Do I need to delete
|
||||
everything first?</bf>
|
||||
|
||||
If your machine is already running MS-DOS and has little
|
||||
or no free space available for FreeBSD's installation,
|
||||
all is not lost! You may find the FIPS utility, provided
|
||||
in the <tt>tools</tt> directory on the FreeBSD CDROM or
|
||||
on the various FreeBSD ftp sites, to be quite useful.
|
||||
|
||||
FIPS allows you to split an existing MS-DOS partition
|
||||
into two pieces, preserving the original partition and
|
||||
allowing you to install onto the second free piece. You
|
||||
first defragment your MS-DOS partition, using the DOS
|
||||
6.xx DEFRAG utility or the Norton Disk tools, then run
|
||||
FIPS. It will prompt you for the rest of the information
|
||||
it needs. Afterwards, you can reboot and install FreeBSD
|
||||
on the new free slice. See the <em>Distributions</em>
|
||||
menu for an estimation of how much free space you will need
|
||||
for the kind of installation you want.
|
||||
|
||||
|
||||
<bf>Can I use compressed MS-DOS filesystems from
|
||||
FreeBSD?</bf>
|
||||
|
||||
No. If you are using a utility such as Stacker(tm) or
|
||||
DoubleSpace(tm), FreeBSD will only be able to use
|
||||
whatever portion of the filesystem you leave
|
||||
uncompressed. The rest of the filesystem will show up as
|
||||
one large file (the stacked/dblspaced file!). <bf>Do not
|
||||
remove that file!</bf> You will probably regret it
|
||||
greatly!
|
||||
|
||||
It is probably better to create another uncompressed
|
||||
MS-DOS primary partition and use this for communications
|
||||
between MS-DOS and FreeBSD.
|
||||
|
||||
|
||||
<bf>Can I mount my MS-DOS extended partitions?</bf>
|
||||
|
||||
Yes. DOS extended partitions are mapped in at the end of the other
|
||||
``slices'' in FreeBSD, e.g. your D: drive might be /dev/sd0s5,
|
||||
your E: drive /dev/sd0s6, and so on. This example assumes, of
|
||||
course, that your extended partition is on SCSI drive 0. For IDE drives,
|
||||
substitute ``wd'' for ``sd'' appropriately. You otherwise mount extended
|
||||
partitions exactly like you would mount any other DOS drive, e.g.:
|
||||
|
||||
<tscreen><verb>
|
||||
mount -t msdos /dev/sd0s5 /dos_d
|
||||
</verb></tscreen>
|
||||
|
||||
<bf>Can I run MS-DOS binaries under FreeBSD?</bf>
|
||||
|
||||
Not yet! We would like to add support for this someday, but
|
||||
are still lacking anyone to actually do the work. BSDI has
|
||||
also donated their DOS emulator to the BSD world and this is slowly
|
||||
being ported to FreeBSD-current.
|
||||
|
||||
Send mail to the &a.emulation if you're interested in joining
|
||||
this effort!
|
||||
|
||||
In the interim, there is a nice application available in the
|
||||
<ref id="ports" name="The Ports Collection"> called pcemu
|
||||
which allows you to run many basic MS-DOS text-mode binaries
|
||||
by entirely emulating an 8088 CPU.
|
||||
@ -1,226 +0,0 @@
|
||||
<!-- $Id$-->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>ISDN<label id="isdn"></heading>
|
||||
|
||||
<p><em>Last modified by &a.wlloyd;</em>.
|
||||
|
||||
<p>A good resource for information on ISDN technology and hardware is
|
||||
<url url="http://alumni.caltech.edu/~dank/isdn/" name="Dan Kegel's
|
||||
ISDN Page">.
|
||||
|
||||
A quick simple roadmap to ISDN follows:
|
||||
<itemize>
|
||||
<item>If you live in Europe I suggest you investigate the ISDN card
|
||||
section.
|
||||
|
||||
<item>If you are planning to use ISDN primarily to connect to the
|
||||
Internet with an Internet Provider on a dialup non-dedicated basis, I
|
||||
suggest you look into Terminal Adapters. This will give you the most
|
||||
flexibility, with the fewest problems, if you change providers.
|
||||
|
||||
<item>If you are connecting two lans together, or connecting to the
|
||||
Internet with a dedicated ISDN connection, I suggest you consider the
|
||||
stand alone router/bridge option.
|
||||
</itemize>
|
||||
|
||||
<p>Cost is a significant factor in determining what solution you will
|
||||
choose. The following options are listed from least expensive to most
|
||||
expensive.
|
||||
|
||||
<sect1><heading>ISDN Cards</heading>
|
||||
|
||||
<p><em>Original Contribution by &a.hm;.</em>
|
||||
|
||||
<p>This section is really only relevant to European ISDN users. The
|
||||
cards supported are not yet(?) available for North American ISDN
|
||||
standards.
|
||||
|
||||
<p>You should be aware that this code is largely under development.
|
||||
Specifically, drivers have only been written for two manufacturers
|
||||
cards.
|
||||
|
||||
<p>PC ISDN cards support the full bandwidth of ISDN, 128Kbs. These
|
||||
cards are often the least expensive type of ISDN equipment.
|
||||
|
||||
<p>Under FreeBSD 2.1.0 and 2.1.5, there is early unfinished ISDN code
|
||||
under /usr/src/gnu/isdn. This code is out of date and should not be
|
||||
used. If you want to go this route, get the bisdn stuff. This code
|
||||
has been removed from the main source tree starting with FreeBSD 2.2.
|
||||
|
||||
<p>There is the bisdn ISDN package available from
|
||||
<url url="ftp://ftp.muc.ditec.de/isdn" name="ftp.muc.ditec.de">
|
||||
supporting FreeBSD 2.1R, FreeBSD-current and NetBSD.
|
||||
The latest source can be found on the above mentioned ftp server under
|
||||
directory isdn as file bisdn-097.tar.gz.
|
||||
|
||||
There are drivers for the following cards:
|
||||
<itemize>
|
||||
<item>Currently all (passive) Teles cards and their clones are supported
|
||||
for the EuroISDN (DSS1) and 1TR6 protocols.
|
||||
<item>Dr. Neuhaus - Niccy 1016
|
||||
</itemize>
|
||||
|
||||
There are several limitations with the bisdn stuff. Specifically the
|
||||
following features usually associated with ISDN are not supported.
|
||||
|
||||
<itemize>
|
||||
<item>No PPP support, only raw hdlc. This means you cannot connect to most
|
||||
standalone routers.
|
||||
<item>Bridging Control Protocol not supported.
|
||||
<item>Multiple cards are not supported.
|
||||
<item>No bandwidth on demand.
|
||||
<item>No channel bundling.
|
||||
</itemize>
|
||||
|
||||
A majordomo maintained mailing list is available, to subscribe, send the
|
||||
usual majordomo requests to
|
||||
<htmlurl url="mailto:isdn-request@muc.ditec.de"
|
||||
name="isdn-request@muc.ditec.de">.
|
||||
|
||||
<sect1><heading>ISDN Terminal Adapters</heading>
|
||||
|
||||
<p>Terminal adapters(TA), are to ISDN what modems are to regular phone
|
||||
lines.
|
||||
<p>Most TA's use the standard hayes modem AT command set, and can be
|
||||
used as a drop in replacement for a modem.
|
||||
|
||||
A TA will operate basically the same as a modem except connection and
|
||||
throughput speeds will be much faster than your old modem. You will
|
||||
need to configure <ref id="ppp" name="PPP"> exactly the same as for a
|
||||
modem setup. Make sure you set your serial speed as high as possible.
|
||||
|
||||
The main advantage of using a TA to connect to an Internet Provider is
|
||||
that you can do Dynamic PPP. As IP address space becomes more and more
|
||||
scarce, most providers are not willing to provide you with a static IP
|
||||
anymore. Most standalone routers are not able to accommodate dynamic IP
|
||||
allocation.
|
||||
|
||||
TA's completely rely on the PPP daemon that you are running for their
|
||||
features and stability of connection. This allows you to upgrade easily
|
||||
from using a modem to ISDN on a FreeBSD machine, if you already have PPP
|
||||
setup. However, at the same time any problems you experienced with the
|
||||
PPP program and are going to persist.
|
||||
|
||||
If you want maximum stability, use the kernel <ref id="ppp" name="PPP">
|
||||
option, not the user-land <ref id="userppp" name="iijPPP">.
|
||||
<p>The following TA's are know to work with FreeBSD.
|
||||
|
||||
<itemize>
|
||||
<item>Motorola BitSurfer and Bitsurfer Pro
|
||||
<item>Adtran
|
||||
</itemize>
|
||||
|
||||
Most other TA's will probably work as well, TA vendors try to make sure
|
||||
their product can accept most of the standard modem AT command set.
|
||||
|
||||
The real problem with external TA's is like modems you need a good
|
||||
serial card in your computer.
|
||||
|
||||
You should read the <ref id="uart" name="serial ports"> section in the
|
||||
handbook for a detailed understanding of serial devices, and the
|
||||
differences between asynchronous and synchronous serial ports.
|
||||
|
||||
A TA running off a standard PC serial port (asynchronous) limits you to
|
||||
115.2Kbs, even though you have a 128Kbs connection. To fully utilize
|
||||
the 128Kbs that ISDN is capable of, you must move the TA to a
|
||||
synchronous serial card.
|
||||
|
||||
Do not be fooled into buying an internal TA and thinking you have
|
||||
avoided the synchronous/asynchronous issue. Internal TA's simply have a
|
||||
standard PC serial port chip built into them. All this will do, is save
|
||||
you having to buy another serial cable, and find another empty
|
||||
electrical socket.
|
||||
|
||||
A synchronous card with a TA is at least as fast as a standalone router,
|
||||
and with a simple 386 FreeBSD box driving it, probably more flexible.
|
||||
|
||||
The choice of sync/TA vs standalone router is largely a religious
|
||||
issue. There has been some discussion of this in the mailing lists. I
|
||||
suggest you search the <url url="http://www.freebsd.org/search.html"
|
||||
name="archives"> for the complete discussion.
|
||||
|
||||
<sect1><heading>Standalone ISDN Bridges/Routers</heading>
|
||||
|
||||
<p>ISDN bridges or routers are not at all specific to FreeBSD or any
|
||||
other operating system. For a more complete description of routing and
|
||||
bridging technology, please refer to a Networking reference book.
|
||||
|
||||
In the context of this page, I will use router and bridge
|
||||
interchangeably.
|
||||
|
||||
<p>As the cost of low end ISDN routers/bridges comes down, it will
|
||||
likely become a more and more popular choice. An ISDN router is a small
|
||||
box that plugs directly into your local Ethernet network(or card), and
|
||||
manages its own connection to the other bridge/router. It has all the
|
||||
software to do PPP and other protocols built in.
|
||||
|
||||
A router will allow you much faster throughput that a standard TA, since
|
||||
it will be using a full synchronous ISDN connection.
|
||||
|
||||
The main problem with ISDN routers and bridges is that interoperability
|
||||
between manufacturers can still be a problem. If you are planning to
|
||||
connect to an Internet provider, I recommend that you discuss your needs
|
||||
with them.
|
||||
|
||||
<p>If you are planning to connect two lan segments together, ie: home
|
||||
lan to the office lan, this is the simplest lowest maintenance
|
||||
solution. Since you are buying the equipment for both sides of the
|
||||
connection you can be assured that the link will work.
|
||||
|
||||
For example to connect a home computer or branch office network to a
|
||||
head office network the following setup could be used.
|
||||
|
||||
<em>Branch office or Home network</em>
|
||||
|
||||
Network is 10 Base T Ethernet. Connect router to network cable with
|
||||
AUI/10BT transceiver, if necessary.
|
||||
|
||||
<verb>
|
||||
---Sun workstation
|
||||
|
|
||||
---FreeBSD box
|
||||
|
|
||||
---Windows 95 (Do not admit to owning it)
|
||||
|
|
||||
Standalone router
|
||||
|
|
||||
ISDN BRI line
|
||||
</verb>
|
||||
If your home/branch office is only one computer you can use a twisted
|
||||
pair crossover cable to connect to the standalone router directly.
|
||||
|
||||
<em>Head office or other lan</em>
|
||||
|
||||
Network is Twisted Pair Ethernet.
|
||||
<verb>
|
||||
-------Novell Server
|
||||
| H |
|
||||
| ---Sun
|
||||
| |
|
||||
| U ---FreeBSD
|
||||
| |
|
||||
| ---Windows 95
|
||||
| B |
|
||||
|___---Standalone router
|
||||
|
|
||||
ISDN BRI line
|
||||
</verb>
|
||||
|
||||
One large advantage of most routers/bridges is that they allow you to
|
||||
have 2 SEPARATE INDEPENDENT PPP connections to 2 separate sites at the
|
||||
SAME time. This is not supported on most TA's, except for
|
||||
specific(expensive) models that have two serial ports. Do not confuse
|
||||
this with channel bonding, MPP etc.
|
||||
|
||||
This can be very useful feature, for example if you have an dedicated
|
||||
internet ISDN connection at your office and would like to tap into it,
|
||||
but don't want to get another ISDN line at work. A router at the office
|
||||
location can manage a dedicated B channel connection (64Kbs) to the
|
||||
internet, as well as a use the other B channel for a separate data connection.
|
||||
The second B channel can be used for dialin, dialout or dynamically
|
||||
bond(MPP etc.) with the first B channel for more bandwidth.
|
||||
|
||||
<p>An Ethernet bridge will also allow you to transmit more than just
|
||||
IP traffic, you can also send IPX/SPX or whatever other protocols you
|
||||
use.</p>
|
||||
@ -1,480 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Kerberos<label id="kerberos"></heading>
|
||||
|
||||
<p><em>Contributed by &a.markm; (based on contribution by &a.md;).</em>
|
||||
|
||||
Kerberos is a network add-on system/protocol that allows users to
|
||||
authenticate themselves through the services of a secure server.
|
||||
Services such as remote login, remote copy, secure inter-system
|
||||
file copying and other high-risk tasks are made considerably safer
|
||||
and more controllable.
|
||||
|
||||
The following instructions can be used as a guide on how to
|
||||
set up Kerberos as distributed for FreeBSD. However, you should refer
|
||||
to the relevant manual pages for a complete description.
|
||||
|
||||
In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite,
|
||||
distribution, but eBones, which had been previously ported to
|
||||
FreeBSD 1.1.5.1, and was sourced from outside the USA/Canada,
|
||||
and is thus available to system owners outside those countries.
|
||||
|
||||
For those needing to get a legal foreign distribution of this
|
||||
software, please <em>DO NOT</em> get it from a USA or Canada site.
|
||||
You will get that site in <em>big</em> trouble! A legal copy of this is
|
||||
available from <tt>skeleton.mikom.csir.co.za</tt>, which is in South
|
||||
Africa.
|
||||
|
||||
<sect1>
|
||||
<heading>Creating the initial database</heading>
|
||||
|
||||
<p>This is done on the Kerberos server only. First make sure that your
|
||||
do not have any old Kerberos databases around. You should change to the
|
||||
directory <tt>/etc/kerberosIV</tt> and check that only the following
|
||||
files are present:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cd /etc/kerberosIV
|
||||
grunt# ls
|
||||
README krb.conf krb.realms
|
||||
</verb></tscreen>
|
||||
|
||||
<p>If any additional files (such as <tt>principal.*</tt> or
|
||||
<tt>master_key</tt>) exist, then use the <tt>kdb_destroy</tt>
|
||||
command to destroy the old Kerberos database, of if Kerberos
|
||||
is not running, simply delete the extra files with <tt>rm</tt>.
|
||||
|
||||
You should now edit the <tt>krb.conf</tt> and <tt>krb.realms</tt>
|
||||
files to define your Kerberos realm. In this case the realm will
|
||||
be <it>GRONDAR.ZA</it> and the server is <it>grunt.grondar.za</it>.
|
||||
We edit or create the <tt>krb.conf</tt> file:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cat krb.conf
|
||||
GRONDAR.ZA
|
||||
GRONDAR.ZA grunt.grondar.za admin server
|
||||
CS.BERKELEY.EDU okeeffe.berkeley.edu
|
||||
ATHENA.MIT.EDU kerberos.mit.edu
|
||||
ATHENA.MIT.EDU kerberos-1.mit.edu
|
||||
ATHENA.MIT.EDU kerberos-2.mit.edu
|
||||
ATHENA.MIT.EDU kerberos-3.mit.edu
|
||||
LCS.MIT.EDU kerberos.lcs.mit.edu
|
||||
TELECOM.MIT.EDU bitsy.mit.edu
|
||||
ARC.NASA.GOV trident.arc.nasa.gov
|
||||
</verb></tscreen>
|
||||
|
||||
<p>In this case, the other realms do not need to be there.
|
||||
They are here as an example of how a machine may be made aware
|
||||
of multiple realms. You may wish to not include them for simplicity.
|
||||
|
||||
The first line names the realm in which this system works. The other
|
||||
lines contain realm/host entries. The first item on a line is a realm,
|
||||
and the second is a host in that realm that is acting as a ``key
|
||||
distribution centre''. The words ``admin server'' following a hosts
|
||||
name means that host also provides an administrative database server.
|
||||
For further explanation of these terms, please consult the Kerberos
|
||||
man pages.
|
||||
|
||||
Now we have to add <it>grunt.grondar.za</it> to the <it>GRONDAR.ZA</it>
|
||||
realm and also add an entry to put all hosts in the <it>.grondar.za</it>
|
||||
domain in the <it>GRONDAR.ZA</it> realm. The <tt>krb.realms</tt> file
|
||||
would be updated as follows:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cat krb.realms
|
||||
grunt.grondar.za GRONDAR.ZA
|
||||
.grondar.za GRONDAR.ZA
|
||||
.berkeley.edu CS.BERKELEY.EDU
|
||||
.MIT.EDU ATHENA.MIT.EDU
|
||||
.mit.edu ATHENA.MIT.EDU
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Again, the other realms do not need to be there.
|
||||
They are here as an example of how a machine may be made aware
|
||||
of multiple realms. You may wish to remove them to simplify things.
|
||||
|
||||
The first line puts the <it>specific</it> system into the named
|
||||
realm. The rest of the lines show how to default systems of a
|
||||
particular subdomain to a named realm.
|
||||
|
||||
Now we are ready to create the database. This only needs to run on
|
||||
the Kerberos server (or Key Distribution Centre). Issue the
|
||||
<tt>kdb_init</tt> command to do this:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kdb_init
|
||||
Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA
|
||||
You will be prompted for the database Master Password.
|
||||
It is important that you NOT FORGET this password.
|
||||
|
||||
Enter Kerberos master key:
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Now we have to save the key so that servers on the local
|
||||
machine can pick it up. Use the <tt>kstash</tt> command to
|
||||
do this.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kstash
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
</verb></tscreen>
|
||||
|
||||
<p>This saves the encrypted master password in
|
||||
<tt>/etc/kerberosIV/master_key</tt>.
|
||||
|
||||
<sect1>
|
||||
<heading>Making it all run</heading>
|
||||
|
||||
<p>Two principals need to be added to the database for <it>each</it>
|
||||
system that will be secured with Kerberos. Their names are
|
||||
<tt>kpasswd</tt> and <tt>rcmd</tt> These two principals are
|
||||
made for each system, with the instance being the name of the
|
||||
individual system.
|
||||
|
||||
These daemons, <tt>kpasswd</tt> and <tt>rcmd</tt> allow other systems
|
||||
to change Kerberos passwords and run commands like <tt>rcp</tt>,
|
||||
<tt>rlogin</tt> and <tt>rsh</tt>.
|
||||
|
||||
Now lets add these entries:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kdb_edit
|
||||
Opening database...
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
Previous or default values are in [brackets] ,
|
||||
enter return to leave the same, or new value.
|
||||
|
||||
Principal name: passwd
|
||||
Instance: grunt
|
||||
|
||||
<Not found>, Create [y] ? y
|
||||
|
||||
Principal: passwd, Instance: grunt, kdc_key_ver: 1
|
||||
New Password: <---- enter RANDOM here
|
||||
Verifying password
|
||||
|
||||
New Password: <---- enter RANDOM here
|
||||
|
||||
Random password [y] ? y
|
||||
|
||||
Principal's new key version = 1
|
||||
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ?
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name: rcmd
|
||||
Instance: grunt
|
||||
|
||||
<Not found>, Create [y] ?
|
||||
|
||||
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
|
||||
New Password: <---- enter RANDOM here
|
||||
Verifying password
|
||||
|
||||
New Password: <---- enter RANDOM here
|
||||
|
||||
Random password [y] ?
|
||||
|
||||
Principal's new key version = 1
|
||||
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ?
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name: <---- null entry here will cause an exit
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>Creating the server file</heading>
|
||||
|
||||
<p>We now have to extract all the instances which define the services
|
||||
on each machine. For this we use the <tt>ext_srvtab</tt> command.
|
||||
This will create a file which must be copied or moved <it>by secure
|
||||
means</it> to each Kerberos client's /etc/kerberosIV directory. This
|
||||
file must be present on each server and client, and is crucial to the
|
||||
operation of Kerberos.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# ext_srvtab grunt
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
Generating 'grunt-new-srvtab'....
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Now, this command only generates a temporary file
|
||||
which must be renamed to <tt>srvtab</tt> so that all the
|
||||
server can pick it up. Use the <tt>mv</tt> command to move it
|
||||
into place on the original system:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# mv grunt-new-srvtab srvtab
|
||||
</verb></tscreen>
|
||||
|
||||
<p>If the file is for a client system, and the network is not
|
||||
deemed safe, then copy the <tt><client>-new-srvtab</tt> to
|
||||
removable media and transport it by secure physical means. Be
|
||||
sure to rename it to <tt>srvtab</tt> in the client's
|
||||
<tt>/etc/kerberosIV</tt> directory, and make sure it is mode 600:
|
||||
|
||||
<tscreen><verb>
|
||||
grumble# mv grumble-new-srvtab srvtab
|
||||
grumble# chmod 600 srvtab
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>Populating the database</heading>
|
||||
|
||||
<p>We now have to add some user entries into the database.
|
||||
First lets create an entry for the user <it>jane</it>. Use
|
||||
the <tt>kdb_edit</tt> command to do this:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kdb_edit
|
||||
Opening database...
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
Previous or default values are in [brackets] ,
|
||||
enter return to leave the same, or new value.
|
||||
|
||||
Principal name: jane
|
||||
Instance:
|
||||
|
||||
<Not found>, Create [y] ? y
|
||||
|
||||
Principal: jane, Instance: , kdc_key_ver: 1
|
||||
New Password: <---- enter a secure password here
|
||||
Verifying password
|
||||
|
||||
New Password: <---- re-enter the password here
|
||||
|
||||
Principal's new key version = 1
|
||||
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ?
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name: <---- null entry here will cause an exit
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>Testing it all out</heading>
|
||||
|
||||
<p>First we have to start the Kerberos daemons. NOTE that if you have
|
||||
correctly edited your <tt>/etc/sysconfig</tt> then this will happen
|
||||
automatically when you reboot. This is only necessary on the Kerberos
|
||||
server. Kerberos clients will automagically get what they need from
|
||||
the <tt>/etc/kerberosIV</tt> directory.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kerberos &
|
||||
grunt# Kerberos server starting
|
||||
Sleep forever on error
|
||||
Log file is /var/log/kerberos.log
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
|
||||
Current Kerberos master key version is 1
|
||||
Local realm: GRONDAR.ZA
|
||||
grunt# kadmind -n &
|
||||
grunt# KADM Server KADM0.0A initializing
|
||||
Please do not use 'kill -9' to kill this job, use a
|
||||
regular kill instead
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Now we can try using the <tt>kinit</tt> command to get a ticket for
|
||||
the id <it>jane</it> that we created above:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt$ kinit jane
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
Kerberos Initialization for "jane"
|
||||
Password:
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Try listing the tokens using <tt>klist</tt> to see if we really have them:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt$ klist
|
||||
Ticket file: /tmp/tkt245
|
||||
Principal: jane@GRONDAR.ZA
|
||||
|
||||
Issued Expires Principal
|
||||
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Now try changing the password using <tt>passwd</tt> to check if the
|
||||
kpasswd daemon can get authorization to the Kerberos database:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt$ passwd
|
||||
realm GRONDAR.ZA
|
||||
Old password for jane:
|
||||
New Password for jane:
|
||||
Verifying password
|
||||
New Password for jane:
|
||||
Password changed.
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>Adding <tt>su</tt> privileges</heading>
|
||||
|
||||
<p>Kerberos allows us to give <it>each</it> user who needs root
|
||||
privileges their own <it>separate</it> <tt>su</tt>password. We
|
||||
could now add an id which is authorized to <tt>su</tt> to <it>root</it>.
|
||||
This is controlled by having an instance of <it>root</it> associated
|
||||
with a principal. Using <tt>kdb_edit</tt> we can create the entry
|
||||
<it>jane.root</it> in the Kerberos database:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kdb_edit
|
||||
Opening database...
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
Previous or default values are in [brackets] ,
|
||||
enter return to leave the same, or new value.
|
||||
|
||||
Principal name: jane
|
||||
Instance: root
|
||||
|
||||
<Not found>, Create [y] ? y
|
||||
|
||||
Principal: jane, Instance: root, kdc_key_ver: 1
|
||||
New Password: <---- enter a SECURE password here
|
||||
Verifying password
|
||||
|
||||
New Password: <---- re-enter the password here
|
||||
|
||||
Principal's new key version = 1
|
||||
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short!
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name: <---- null entry here will cause an exit
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Now try getting tokens for it to make sure it works:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kinit jane.root
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
Kerberos Initialization for "jane.root"
|
||||
Password:
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Now we need to add the user to root's <tt>.klogin</tt> file:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cat /root/.klogin
|
||||
jane.root@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Now try doing the <tt>su</tt>:
|
||||
|
||||
<tscreen><verb>
|
||||
[jane@grunt 10407] su
|
||||
Password:
|
||||
grunt#
|
||||
</verb></tscreen>
|
||||
|
||||
and take a look at what tokens we have:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# klist
|
||||
Ticket file: /tmp/tkt_root_245
|
||||
Principal: jane.root@GRONDAR.ZA
|
||||
|
||||
Issued Expires Principal
|
||||
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>Using other commands</heading>
|
||||
|
||||
<p>In an earlier example, we created a principal called <tt>jane</tt>
|
||||
with an instance <tt>root</tt>. This was based on a user with the
|
||||
same name as the principal, and this is a Kerberos default; that a
|
||||
<em><principal>.<instance></em> of the form
|
||||
<em><username>.</em><tt>root</tt> will allow that
|
||||
<em><username></em> to <tt>su</tt> to root if the necessary
|
||||
entries are in the <tt>.klogin</tt> file in <tt>root</tt>'s home
|
||||
directory:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cat /root/.klogin
|
||||
jane.root@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Likewise, if a user has in their own home directory lines of the
|
||||
form:
|
||||
|
||||
<tscreen><verb>
|
||||
[jane@grunt 10543] cat ~/.klogin
|
||||
jane@GRONDAR.ZA
|
||||
jack@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<p>This allows anyone in the <em>GRONDAR.ZA</em> realm who has
|
||||
authenticated themselves to <em>jane</em> or <em>jack</em> (via
|
||||
<tt>kinit</tt>, see above) access to <tt>rlogin</tt> to <em>jane</em>'s
|
||||
account or files on this system (<em>grunt</em>) via <tt>rlogin</tt>,
|
||||
<tt>rsh</tt> or <tt>rcp</tt>.
|
||||
|
||||
For example, Jane now logs into another system, using Kerberos:
|
||||
|
||||
<tscreen><verb>
|
||||
[jane@grumble 573] kinit
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
Password:
|
||||
[jane@grumble 574] rlogin grunt
|
||||
Last login: Mon May 1 21:14:47 from grumble
|
||||
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
|
||||
The Regents of the University of California. All rights reserved.
|
||||
|
||||
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
|
||||
|
||||
[jane@grunt 10567]
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Or Jack logs into Jane's account on the same machine (Jane having set up
|
||||
the <tt>.klogin</tt> file as above, and the person in charge of Kerberos
|
||||
having set up principal <em>jack</em> with a null instance:
|
||||
|
||||
<tscreen><verb>
|
||||
[jack@grumble 573] kinit
|
||||
[jack@grumble 574] rlogin grunt -l jane
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
Password:
|
||||
Last login: Mon May 1 21:16:55 from grumble
|
||||
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
|
||||
The Regents of the University of California. All rights reserved.
|
||||
|
||||
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
|
||||
|
||||
[jane@grunt 10578]
|
||||
</verb></tscreen>
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,525 +0,0 @@
|
||||
<!-- $Id: kerneldebug.sgml,v 1.13 1997/03/18 00:42:36 joerg Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Kernel Debugging<label id="kerneldebug"></heading>
|
||||
|
||||
<p><em>Contributed by &a.paul; and &a.joerg;</em>
|
||||
|
||||
<sect><heading>Debugging a kernel crash dump with kgdb</heading>
|
||||
|
||||
<p>Here are some instructions for getting kernel debugging
|
||||
working on a crash dump, it assumes that you have enough swap
|
||||
space for a crash dump. If you have multiple swap
|
||||
partitions and the first one is too small to hold the dump,
|
||||
you can configure your kernel to use an alternate dump device
|
||||
(in the <tt>config kernel</tt> line), or
|
||||
you can specify an alternate using the dumpon(8) command.
|
||||
Dumps to non-swap devices,
|
||||
tapes for example, are currently not supported. Config your
|
||||
kernel using <tt>config -g</tt>.
|
||||
See <ref id="kernelconfig" name="Kernel Configuration"> for
|
||||
details on configuring the FreeBSD kernel.
|
||||
|
||||
Use the <tt>dumpon(8)</tt> command to tell the kernel where to dump
|
||||
to (note that this will have to be done after configuring the
|
||||
partition in question as swap space via <tt>swapon(8)</tt>). This is
|
||||
normally arranged via <tt>/etc/sysconfig</tt> and <tt>/etc/rc</tt>.
|
||||
Alternatively, you can
|
||||
hard-code the dump device via the `dump' clause in the `config' line
|
||||
of your kernel config file. This is deprecated, use only if you
|
||||
want a crash dump from a kernel that crashes during booting.
|
||||
|
||||
<em><bf>Note:</bf> In the following, the term `<tt>kgdb</tt>' refers
|
||||
to <tt>gdb</tt> run in `kernel debug mode'. This can be accomplished by
|
||||
either starting the <tt>gdb</tt> with the option <tt>-k</tt>, or by linking
|
||||
and starting it under the name <tt>kgdb</tt>. This is not being
|
||||
done by default, however, and the idea is basically deprecated since
|
||||
the GNU folks do not love it if their tools behave differently when
|
||||
called by another name. This feature might as well be discontinued
|
||||
in further releases.</em>
|
||||
|
||||
When the kernel has been built make a copy of it, say
|
||||
<tt>kernel.debug</tt>, and then run <tt>strip -d</tt> on the
|
||||
original. Install the original as normal. You may also install
|
||||
the unstripped kernel, but symbol table lookup time for some
|
||||
programs will drastically increase, and since
|
||||
the whole kernel is loaded entirely at boot time and cannot be
|
||||
swapped out later, several megabytes of
|
||||
physical memory will be wasted.
|
||||
|
||||
If you are testing a new kernel, for example by typing the new
|
||||
kernel's name at the boot prompt, but need to boot a different
|
||||
one in order to get your system up and running again, boot it
|
||||
only into single user state using the <tt>-s</tt> flag at the
|
||||
boot prompt, and then perform the following steps:
|
||||
<tscreen><verb>
|
||||
fsck -p
|
||||
mount -a -t ufs # so your file system for /var/crash is writable
|
||||
savecore -N /kernel.panicked /var/crash
|
||||
exit # ...to multi-user
|
||||
</verb></tscreen>
|
||||
This instructs <tt>savecore(8)</tt> to use another kernel for symbol name
|
||||
extraction. It would otherwise default to the currently running kernel
|
||||
and most likely not do anything at all since the crash dump and the
|
||||
kernel symbols differ.
|
||||
|
||||
Now, after a crash dump, go to <tt>/sys/compile/WHATEVER</tt> and run
|
||||
<tt>kgdb</tt>. From <tt>kgdb</tt> do:
|
||||
<tscreen><verb>
|
||||
symbol-file kernel.debug
|
||||
exec-file /var/crash/kernel.0
|
||||
core-file /var/crash/vmcore.0
|
||||
</verb></tscreen>
|
||||
and voila, you can debug the crash dump using the kernel sources
|
||||
just like you can for any other program.
|
||||
|
||||
Here is a script log of a <tt>kgdb</tt> session illustrating the
|
||||
procedure. Long
|
||||
lines have been folded to improve readability, and the lines are
|
||||
numbered for reference. Despite this, it is a real-world error
|
||||
trace taken during the development of the pcvt console driver.
|
||||
<tscreen><verb>
|
||||
1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:uriah # cd /sys/compile/URIAH
|
||||
3:uriah # kgdb kernel /var/crash/vmcore.1
|
||||
4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done.
|
||||
5:IdlePTD 1f3000
|
||||
6:panic: because you said to!
|
||||
7:current pcb at 1e3f70
|
||||
8:Reading in symbols for ../../i386/i386/machdep.c...done.
|
||||
9:(kgdb) where
|
||||
10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767)
|
||||
11:#1 0xf0115159 in panic ()
|
||||
12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698)
|
||||
13:#3 0xf010185e in db_fncall ()
|
||||
14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073)
|
||||
15:#5 0xf0101711 in db_command_loop ()
|
||||
16:#6 0xf01040a0 in db_trap ()
|
||||
17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723)
|
||||
18:#8 0xf019d2eb in trap_fatal (...)
|
||||
19:#9 0xf019ce60 in trap_pfault (...)
|
||||
20:#10 0xf019cb2f in trap (...)
|
||||
21:#11 0xf01932a1 in exception:calltrap ()
|
||||
22:#12 0xf0191503 in cnopen (...)
|
||||
23:#13 0xf0132c34 in spec_open ()
|
||||
24:#14 0xf012d014 in vn_open ()
|
||||
25:#15 0xf012a183 in open ()
|
||||
26:#16 0xf019d4eb in syscall (...)
|
||||
27:(kgdb) up 10
|
||||
28:Reading in symbols for ../../i386/i386/trap.c...done.
|
||||
29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\
|
||||
30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\
|
||||
31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\
|
||||
32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\
|
||||
33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\
|
||||
34:ss = -266427884}) (../../i386/i386/trap.c line 283)
|
||||
35:283 (void) trap_pfault(&frame, FALSE);
|
||||
36:(kgdb) frame frame->tf_ebp frame->tf_eip
|
||||
37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done.
|
||||
38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\
|
||||
39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403)
|
||||
40:403 return ((*linesw[tp->t_line].l_open)(dev, tp));
|
||||
41:(kgdb) list
|
||||
42:398
|
||||
43:399 tp->t_state |= TS_CARR_ON;
|
||||
44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */
|
||||
45:401
|
||||
46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200)
|
||||
47:403 return ((*linesw[tp->t_line].l_open)(dev, tp));
|
||||
48:404 #else
|
||||
49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag));
|
||||
50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */
|
||||
51:407 }
|
||||
52:(kgdb) print tp
|
||||
53:Reading in symbols for ../../i386/i386/cons.c...done.
|
||||
54:$1 = (struct tty *) 0x1bae
|
||||
55:(kgdb) print tp->t_line
|
||||
56:$2 = 1767990816
|
||||
57:(kgdb) up
|
||||
58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\
|
||||
59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126)
|
||||
60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p));
|
||||
61:(kgdb) up
|
||||
62:#2 0xf0132c34 in spec_open ()
|
||||
63:(kgdb) up
|
||||
64:#3 0xf012d014 in vn_open ()
|
||||
65:(kgdb) up
|
||||
66:#4 0xf012a183 in open ()
|
||||
67:(kgdb) up
|
||||
68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\
|
||||
69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\
|
||||
70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \
|
||||
71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \
|
||||
72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673)
|
||||
73:673 error = (*callp->sy_call)(p, args, rval);
|
||||
74:(kgdb) up
|
||||
75:Initial frame selected; you cannot go up.
|
||||
76:(kgdb) quit
|
||||
77:uriah # exit
|
||||
78:exit
|
||||
79:
|
||||
80:Script done on Fri Dec 30 23:18:04 1994
|
||||
</verb></tscreen>
|
||||
Comments to the above script:
|
||||
|
||||
<descrip>
|
||||
<tag/line 6:/ This is a dump taken from within DDB (see below), hence the
|
||||
panic comment ``because you said to!'', and a rather long
|
||||
stack trace; the initial reason for going into DDB has been
|
||||
a page fault trap though.
|
||||
<tag/line 20:/ This is the location of function <tt>trap()</tt>
|
||||
in the stack trace.
|
||||
<tag/line 36:/ Force usage of a new stack frame; this is no longer
|
||||
necessary now. The stack frames are supposed to point to
|
||||
the right locations now, even in case of a trap.
|
||||
(I do not have a new core dump handy <g>, my kernel
|
||||
did not panic for ia rather long time.)
|
||||
From looking at the code in source line 403,
|
||||
there is a high probability that either the pointer
|
||||
access for ``tp'' was messed up, or the array access was
|
||||
out of bounds.
|
||||
<tag/line 52:/ The pointer looks suspicious, but happens to be a valid
|
||||
address.
|
||||
<tag/line 56:/ However, it obviously points to garbage, so we have found our
|
||||
error! (For those unfamiliar with that particular piece
|
||||
of code: <tt>tp->t_line</tt> refers to the line discipline
|
||||
of the console device here, which must be a rather small integer
|
||||
number.)
|
||||
</descrip>
|
||||
|
||||
|
||||
<sect><heading>Post-mortem analysis of a dump</heading>
|
||||
|
||||
<p>What do you do if a kernel dumped core but you did not expect
|
||||
it, and it is therefore not compiled using <tt>config -g</tt>?
|
||||
Not everything is lost here. Do not panic!
|
||||
|
||||
Of course, you still need to enable crash dumps. See above
|
||||
on the options you have to specify in order to do this.
|
||||
|
||||
Go to your kernel compile directory, and edit the line
|
||||
containing <tt>COPTFLAGS?=-O</tt>. Add the <tt>-g</tt> option
|
||||
there (but <em>do not</em> change anything on the level of
|
||||
optimization). If you do already know roughly the probable
|
||||
location of the failing piece of code (e.g., the <tt>pcvt</tt>
|
||||
driver in the example above), remove all the object files for
|
||||
this code. Rebuild the kernel. Due to the time stamp change on
|
||||
the Makefile, there will be some other object files rebuild,
|
||||
for example <tt>trap.o</tt>. With a bit of luck, the added
|
||||
<tt>-g</tt> option will not change anything for the generated
|
||||
code, so you will finally get a new kernel with similar code to
|
||||
the faulting one but some debugging symbols. You should at
|
||||
least verify the old and new sizes with the <tt>size(1)</tt> command. If
|
||||
there is a mismatch, you probably need to give up here.
|
||||
|
||||
Go and examine the dump as described above. The debugging
|
||||
symbols might be incomplete for some places, as can be seen in
|
||||
the stack trace in the example above where some functions are
|
||||
displayed without line numbers and argument lists. If you need
|
||||
more debugging symbols, remove the appropriate object files and
|
||||
repeat the <tt>kgdb</tt> session until you know enough.
|
||||
|
||||
All this is not guaranteed to work, but it will do it fine in
|
||||
most cases.
|
||||
|
||||
<sect><heading>On-line kernel debugging using DDB</heading>
|
||||
|
||||
<p>While <tt>kgdb</tt> as an offline debugger provides a very
|
||||
high level of user interface, there are some things it cannot do.
|
||||
The most important ones being breakpointing and single-stepping
|
||||
kernel code.
|
||||
|
||||
If you need to do low-level debugging on your kernel, there is
|
||||
an on-line debugger available called DDB. It allows to
|
||||
setting breakpoints, single-steping kernel functions, examining
|
||||
and changing kernel variables, etc. However, it cannot not
|
||||
access kernel source files, and only has access to the global
|
||||
and static symbols, not to the full debug information like
|
||||
<tt>kgdb</tt>.
|
||||
|
||||
To configure your kernel to include DDB, add the option line
|
||||
<tscreen><verb>
|
||||
options DDB
|
||||
</verb></tscreen>
|
||||
to your config file, and rebuild. (See <ref id="kernelconfig"
|
||||
name="Kernel Configuration"> for details on configuring the
|
||||
FreeBSD kernel. Note that if you have an older version of the
|
||||
boot blocks, your debugger symbols might not be loaded at all.
|
||||
Update the boot blocks, the recent ones do load the DDB symbols
|
||||
automagically.)
|
||||
|
||||
Once your DDB kernel is running, there are several ways to
|
||||
enter DDB. The first, and earliest way is to type the boot
|
||||
flag <tt>-d</tt> right at the boot prompt. The kernel will
|
||||
start up in debug mode and enter DDB prior to any device
|
||||
probing. Hence you are able to even debug the device
|
||||
probe/attach functions.
|
||||
|
||||
The second scenario is a hot-key on the keyboard, usually
|
||||
Ctrl-Alt-ESC. For syscons, this can be remapped, and some of
|
||||
the distributed maps do this, so watch out.
|
||||
There is an option
|
||||
available for serial consoles
|
||||
that allows the use of a serial line BREAK on the console line to
|
||||
enter DDB (``<tt>options BREAK_TO_DEBUGGER</tt>''
|
||||
in the kernel config file). It is not the default since there are a lot of
|
||||
crappy serial adapters around that gratuitously generate a
|
||||
BREAK condition for example when pulling the cable.
|
||||
|
||||
The third way is that any panic condition will branch to DDB if
|
||||
the kernel is configured to use it.
|
||||
For this reason, it is not wise to
|
||||
configure a kernel with DDB for a machine running unattended.
|
||||
|
||||
The DDB commands roughly resemble some <tt>gdb</tt> commands. The first you
|
||||
probably need is to set a breakpoint:
|
||||
<tscreen><verb>
|
||||
b function-name
|
||||
b address
|
||||
</verb></tscreen>
|
||||
|
||||
Numbers are taken hexadecimal by default, but to make them
|
||||
distinct from symbol names, hexadecimal numbers starting with the
|
||||
letters <tt>a</tt>-<tt>f</tt> need to be preceded with
|
||||
<tt>0x</tt> (for other numbers, this is optional). Simple
|
||||
expressions are allowed, for example: <tt>function-name + 0x103</tt>.
|
||||
|
||||
To continue the operation of an interrupted kernel, simply type
|
||||
<tscreen><verb>
|
||||
c
|
||||
</verb></tscreen>
|
||||
To get a stack trace, use
|
||||
<tscreen><verb>
|
||||
trace
|
||||
</verb></tscreen>
|
||||
Note that when entering DDB via a hot-key, the kernel is currently
|
||||
servicing an interrupt, so the stack trace might be not of much use
|
||||
for you.
|
||||
|
||||
If you want to remove a breakpoint, use
|
||||
<tscreen><verb>
|
||||
del
|
||||
del address-expression
|
||||
</verb></tscreen>
|
||||
The first form will be accepted immediately after a breakpoint hit,
|
||||
and deletes the current breakpoint. The second form can remove any
|
||||
breakpoint, but you need to specify the exact address, as it can be
|
||||
obtained from
|
||||
<tscreen><verb>
|
||||
show b
|
||||
</verb></tscreen>
|
||||
To single-step the kernel, try
|
||||
<tscreen><verb>
|
||||
s
|
||||
</verb></tscreen>
|
||||
This will step into functions, but you can make DDB trace them until
|
||||
the matching return statement is reached by
|
||||
<tscreen><verb>
|
||||
n
|
||||
</verb></tscreen>
|
||||
<bf>Note:</bf> this is different from <tt>gdb</tt>'s `next' statement, it is like
|
||||
<tt>gdb</tt>'s `finish'.
|
||||
|
||||
To examine data from memory, use (for example):
|
||||
<tscreen><verb>
|
||||
x/wx 0xf0133fe0,40
|
||||
x/hd db_symtab_space
|
||||
x/bc termbuf,10
|
||||
x/s stringbuf
|
||||
</verb></tscreen>
|
||||
for word/halfword/byte access, and hexadecimal/decimal/character/
|
||||
string display. The number after the comma is the object count.
|
||||
To display the next 0x10 items, simply use
|
||||
<tscreen><verb>
|
||||
x ,10
|
||||
</verb></tscreen>
|
||||
Similarly, use
|
||||
<tscreen><verb>
|
||||
x/ia foofunc,10
|
||||
</verb></tscreen>
|
||||
to disassemble the first 0x10 instructions of <tt>foofunc</tt>, and display
|
||||
them along with their offset from the beginning of <tt>foofunc</tt>.
|
||||
|
||||
To modify the memory, use the write command:
|
||||
<tscreen><verb>
|
||||
w/b termbuf 0xa 0xb 0
|
||||
w/w 0xf0010030 0 0
|
||||
</verb></tscreen>
|
||||
The command modifier (<tt>b</tt>/<tt>h</tt>/<tt>w</tt>)
|
||||
specifies the size of the data to be written, the first
|
||||
following expression is the address to write to, the remainder
|
||||
is interpreted as data to write to successive memory locations.
|
||||
|
||||
If you need to know the current registers, use
|
||||
<tscreen><verb>
|
||||
show reg
|
||||
</verb></tscreen>
|
||||
Alternatively, you can display a single register value by e.g.
|
||||
<tscreen><verb>
|
||||
p $eax
|
||||
</verb></tscreen>
|
||||
and modify it by
|
||||
<tscreen><verb>
|
||||
set $eax new-value
|
||||
</verb></tscreen>
|
||||
|
||||
Should you need to call some kernel functions from DDB, simply
|
||||
say
|
||||
<tscreen><verb>
|
||||
call func(arg1, arg2, ...)
|
||||
</verb></tscreen>
|
||||
The return value will be printed.
|
||||
|
||||
For a <tt>ps(1)</tt> style summary of all running processes, use
|
||||
<tscreen><verb>
|
||||
ps
|
||||
</verb></tscreen>
|
||||
|
||||
Now you have now examined why your kernel failed, and you wish to
|
||||
reboot. Remember that, depending on the severity of previous
|
||||
malfunctioning, not all parts of the kernel might still be working
|
||||
as expected. Perform one of the following actions to shut down and
|
||||
reboot your system:
|
||||
<tscreen><verb>
|
||||
call diediedie()
|
||||
</verb></tscreen>
|
||||
|
||||
will cause your kernel to dump core and reboot, so you can
|
||||
later analyze the core on a higher level with kgdb. This
|
||||
command usually must be followed by another
|
||||
`<tt>continue</tt>' statement.
|
||||
There is now an alias for this: `<tt>panic</tt>'.
|
||||
|
||||
<tscreen><verb>
|
||||
call boot(0)
|
||||
</verb></tscreen>
|
||||
might be a good way to cleanly shut down the running system, <tt>sync()</tt>
|
||||
all disks, and finally reboot. As long as the disk and file system
|
||||
interfaces of the kernel are not damaged, this might be a good way
|
||||
for an almost clean shutdown.
|
||||
|
||||
<tscreen><verb>
|
||||
call cpu_reset()
|
||||
</verb></tscreen>
|
||||
is the final way out of disaster and almost the same as hitting
|
||||
the Big Red Button.
|
||||
|
||||
If you need a short command summary, simply type
|
||||
<tscreen><verb>
|
||||
help
|
||||
</verb></tscreen>
|
||||
However, it is highly recommended to have a printed copy of the
|
||||
<tt>ddb(4)</tt> manual page ready for a debugging session.
|
||||
Remember that it is hard to read the on-line manual while
|
||||
single-stepping the kernel.
|
||||
|
||||
<sect><heading>On-line kernel debugging using remote GDB</heading>
|
||||
|
||||
<p>This feature is supported since FreeBSD 2.2, and it's actually
|
||||
a very neat one.
|
||||
|
||||
GDB used to support <em/remote debugging/ for a long time
|
||||
already. This is done using a very simple protocol along a
|
||||
serial line. Obviously, and opposed to the other methods
|
||||
described above, you need two machines for doing this. One is
|
||||
the host providing the debugging environment, including all
|
||||
the sources, and a copy of the kernel binary with all the
|
||||
symbols in it, and the other one is the target machine that
|
||||
simply runs a similar copy of the very same kernel (but stripped
|
||||
off the debugging information).
|
||||
|
||||
You should configure the kernel in question with <tt>config -g</tt>,
|
||||
include <em/DDB/ into the configuration, and compile it as usual.
|
||||
This gives a large blurb of a binary, due
|
||||
to the debugging information. Copy this kernel to the target
|
||||
machine, strip the debugging symbols off with <tt>strip -x</tt>,
|
||||
and boot it using the <tt/-d/ boot option. Connect the first
|
||||
serial line of the target machine to any serial line of the
|
||||
debugging host. Now, on the debugging machine, go to the compile
|
||||
directory of the target kernel, and start gdb:
|
||||
<tscreen><verb>
|
||||
% gdb -k kernel
|
||||
GDB is free software and you are welcome to distribute copies of it
|
||||
under certain conditions; type "show copying" to see the conditions.
|
||||
There is absolutely no warranty for GDB; type "show warranty" for details.
|
||||
GDB 4.16 (i386-unknown-freebsd),
|
||||
Copyright 1996 Free Software Foundation, Inc...
|
||||
(kgdb)
|
||||
</verb></tscreen>
|
||||
|
||||
Initialize the remote debugging session (assuming the first serial
|
||||
port is being used) by:
|
||||
<tscreen><verb>
|
||||
(kgdb) target remote /dev/cuaa0
|
||||
</verb></tscreen>
|
||||
|
||||
Now, on the target host (that entered DDB right before even starting
|
||||
the device probe), type:
|
||||
<tscreen><verb>
|
||||
Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
db> gdb
|
||||
</verb></tscreen>
|
||||
|
||||
DDB will respond with:
|
||||
<tscreen><verb>
|
||||
Next trap will enter GDB remote protocol mode
|
||||
</verb></tscreen>
|
||||
|
||||
Every time you type ``gdb'', the mode will be toggled between
|
||||
remote GDB and local DDB. In order to force a next trap
|
||||
immediately, simply type ``s'' (step). Your hosting GDB will
|
||||
now gain control over the target kernel:
|
||||
<tscreen><verb>
|
||||
Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
at ../../i386/i386/db_interface.c:257
|
||||
(kgdb)
|
||||
</verb></tscreen>
|
||||
|
||||
You can use this session almost as any other GDB session, including
|
||||
full access to the source, running it in gud-mode inside an Emacs
|
||||
window (which gives you an automatic source code display in another
|
||||
Emacs window) etc.
|
||||
|
||||
<p>Remote GDB can also be used to debug LKMs. First build the LKM
|
||||
with debugging symbols:
|
||||
<tscreen><verb>
|
||||
# cd /usr/src/lkm/linux
|
||||
# make clean; make COPTS=-g
|
||||
</verb></tscreen>
|
||||
|
||||
Then install this version of the module on the target machine, load it
|
||||
and use <tt>modstat</tt> to find out where it was loaded:
|
||||
<tscreen><verb>
|
||||
# linux
|
||||
# modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f5109000 001c f510f010 1 linux_mod
|
||||
</verb></tscreen>
|
||||
|
||||
Take the load address of the module and add 0x20 (probably to account
|
||||
for the a.out header). This is the address that the module code was
|
||||
relocated to. Use the <tt>add-symbol-file</tt> command in GDB to tell the
|
||||
debugger about the module:
|
||||
<tscreen><verb>
|
||||
(kgdb) add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020
|
||||
add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
|
||||
text_addr = 0xf5109020?
|
||||
(y or n) y
|
||||
(kgdb)
|
||||
</verb></tscreen>
|
||||
|
||||
You now have access to all the symbols in the LKM.
|
||||
|
||||
<sect><heading>Debugging a console driver</heading>
|
||||
|
||||
<p>Since you need a console driver to run DDB on, things are more
|
||||
complicated if the console driver itself is failing. You might
|
||||
remember the use of a serial console (either with modified boot
|
||||
blocks, or by specifying <tt><bf>-h</bf></tt> at the <tt>Boot:</tt>
|
||||
prompt), and hook up a standard
|
||||
terminal onto your first serial port. DDB works on any configured
|
||||
console driver, of course also on a serial console.
|
||||
|
||||
|
||||
@ -1,149 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
||||
|
||||
<chapt><heading>Adding New Kernel Configuration Options<label id="kernelopts"></heading>
|
||||
|
||||
<p><em>Contributed by &a.joerg;</em>
|
||||
|
||||
<em/Note:/ You should be familiar with the section about <ref
|
||||
id="kernelconfig" name="kernel configuration"> before reading here.
|
||||
|
||||
<sect><heading>What's a <em>kernel option</em>, anyway?</heading>
|
||||
|
||||
<p>The use of kernel options is basically described in the <ref
|
||||
id="kernelconfig:options" name="kernel configuration"> section.
|
||||
There's also an explanation about ``historic'' and ``new-style''
|
||||
options. The ultimate goal is to eventually turn all the supported
|
||||
options in the kernel into new-style ones, so for people who
|
||||
correctly did a <tt/make depend/ in their kernel compile directory
|
||||
after running <tt/config(8)/, the build process will automatically
|
||||
pick up modified options, and only recompile those files where it is
|
||||
necessary. Wiping out the old compile directory on each run of
|
||||
<tt/config(8)/ as it is still done now can then be eliminated again.
|
||||
|
||||
<p>Basically, a kernel option is nothing else than the definition of
|
||||
a C preprocessor macro for the kernel compilation process. To make
|
||||
the build truly optional, the corresponding part of the kernel
|
||||
source (or kernel <tt/.h/ file) must be written with the option
|
||||
concept in mind, i. e. the default must have been made overridable
|
||||
by the config option. This is usually done with something like:
|
||||
|
||||
<verb>
|
||||
#ifndef THIS_OPTION
|
||||
#define THIS_OPTION (some_default_value)
|
||||
#endif /* THIS_OPTION */
|
||||
</verb>
|
||||
<p>This way, an administrator mentioning another value for the
|
||||
option in his config file will take the default out of effect, and
|
||||
replace it with his new value. Apparently, the new value will be
|
||||
substituted into the source code during the preprocessor run, so it
|
||||
must be a valid C expression in whatever context the default value
|
||||
would have been used.
|
||||
|
||||
<p>It is also possible to create value-less options that simply
|
||||
enable or disable a particular piece of code by embracing it in
|
||||
|
||||
<verb>
|
||||
#ifdef THAT_OPTION
|
||||
|
||||
[your code here]
|
||||
|
||||
#endif
|
||||
</verb>
|
||||
<p>Simply mentioning <tt/THAT_OPTION/ in the config file (with or
|
||||
without any value) will then turn on the corresponding piece of
|
||||
code.
|
||||
|
||||
<p>People familiar with the C language will immediately recognize
|
||||
that everything could be counted as a ``config option'' where
|
||||
there is at least a single <tt/#ifdef/ referencing it... Now only
|
||||
few people probably would try to say
|
||||
|
||||
<verb>
|
||||
options notyet,notdef
|
||||
</verb>
|
||||
<p>in their config file however, and watch the kernel compilation
|
||||
fall over. :-)
|
||||
|
||||
<p>Apparently, using arbitrary names for the options makes it very
|
||||
hard to track their usage throughout the kernel source tree. That is
|
||||
the rationale behind the <em/new-style/ option scheme, where each
|
||||
option goes into a separate <tt/.h/ file in the kernel compile
|
||||
directory, which is by convention named <tt>opt_<em>foo</em>.h</tt>.
|
||||
This way, the usual Makefile dependencies could be applied, and
|
||||
<tt/make/ can determine what needs to be recompiled once an option
|
||||
has been changed.
|
||||
|
||||
<p>The old-style option mechanism still has one advantage for local
|
||||
options or maybe experimental options that have a short anticipated
|
||||
lifetime: since it is easy to add a new <tt/#ifdef/ to the kernel
|
||||
source, this has already made it a kernel config option.
|
||||
In this case, the administrator using such an
|
||||
option is responsible himself for knowing about its implications
|
||||
(and maybe manually forcing the recompilation of parts of his
|
||||
kernel). Once the transition of all supported options has been
|
||||
done, <tt/config(8)/ will warn whenever an unsupported option
|
||||
appears in the config file, but it will nevertheless include it into
|
||||
the kernel Makefile.
|
||||
|
||||
|
||||
<sect><heading>Now what do I have to do for it?</heading>
|
||||
|
||||
<p>First, edit <tt>sys/conf/options</tt> (or
|
||||
<tt>sys/i386/conf/options.<em><arch></em></tt>, e. g.
|
||||
<tt>sys/i386/conf/options.i386</tt>), and select an
|
||||
<tt>opt_<em>foo</em>.h</tt> file where your new option would best go
|
||||
into.
|
||||
|
||||
<p>If there is already something that comes close to the purpose of
|
||||
the new option, pick this. For example, options modifying the
|
||||
overall behaviour of the SCSI subsystem can go into <tt/opt_scsi.h/.
|
||||
By default, simply mentioning an option in the appropriate option
|
||||
file, say <tt/FOO/, implies its value will go into the
|
||||
corresponding file <tt/opt_foo.h/. This can be overridden on the
|
||||
right-hand side of a rule by specifying another filename.
|
||||
|
||||
<p>If there is no <tt>opt_<em>foo</em>.h</tt> already available for
|
||||
the intended new option, invent a new name. Make it meaningful, and
|
||||
comment the new section in the
|
||||
<tt>options[<em>.<arch></em>]</tt> file. <tt/config(8)/ will
|
||||
automagically pick up the change, and create that file next time it
|
||||
is run. Most options should go in a header file by themselves..
|
||||
|
||||
<p>Packing too many options into a single
|
||||
<tt>opt_<em>foo</em>.h</tt> will cause too many kernel files to be
|
||||
rebuilt when one of the options has been changed in the config file.
|
||||
|
||||
<p>Finally, find out which kernel files depend on the new option.
|
||||
Unless you have just invented your option, and it does not exist
|
||||
anywhere yet,
|
||||
|
||||
<verb>
|
||||
find /usr/src/sys -name type f | xargs fgrep NEW_OPTION
|
||||
</verb>
|
||||
<p>is your friend in finding them. Go and edit all those files, and
|
||||
add
|
||||
|
||||
<verb>
|
||||
#include "opt_foo.h"
|
||||
</verb>
|
||||
<p><em>on top</em>, before all the <tt/#include <xxx.h>/
|
||||
stuff. The sequence is most important in case the options will
|
||||
override some defaults from the regular include files, where the
|
||||
defaults are protected by
|
||||
|
||||
<verb>
|
||||
#ifndef NEW_OPTION
|
||||
#define NEW_OPTION (something)
|
||||
#endif
|
||||
</verb>
|
||||
<p>in the regular header.
|
||||
|
||||
<p>Adding an option that overrides something in a system header file
|
||||
(i. e., a file sitting in <tt>/usr/include/sys/</tt>) is almost
|
||||
always a mistake. <tt>opt_<em>foo</em>.h</tt> cannot be included
|
||||
into those files since it would break the headers more seriously,
|
||||
but if it is not included, then places that include it may get an
|
||||
inconsistent value for the option. Yes, there are precedents for
|
||||
this right now, but that does not make them more correct.
|
||||
@ -1,700 +0,0 @@
|
||||
<!-- $Id: linuxemu.sgml,v 1.18 1997/03/19 03:15:43 obrien Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Linux Emulation<label id="linuxemu"></heading>
|
||||
|
||||
<p><em>Contributed by &a.handy and &a.rich;</em>
|
||||
|
||||
<sect><heading>How to install the Linux emulator</heading>
|
||||
|
||||
<p>Linux emulation in FreeBSD has reached a point where it is possible
|
||||
to run a large fraction of Linux binaries in both a.out and ELF
|
||||
format. The linux emulation in the 2.1-STABLE branch is capable of
|
||||
running Linux DOOM and Mathematica; the version present in
|
||||
FreeBSD-2.2-RELEASE is vastly more capable and runs all these as well as
|
||||
Quake, Abuse, IDL, netrek for Linux and a whole host of other
|
||||
programs.
|
||||
|
||||
There are some Linux-specific operating system features that are not
|
||||
supported on FreeBSD. Linux binaries will not work on FreeBSD if they
|
||||
use the Linux /proc filesystem (which is different from the optional
|
||||
FreeBSD /proc filesystem) or i386-specific calls, such as enabling
|
||||
virtual 8086 mode.
|
||||
|
||||
<p>To tell whether your kernel is configured for Linux
|
||||
compatibility simply run any Linux binary. If it
|
||||
prints the error message
|
||||
<tscreen>
|
||||
<verb>
|
||||
linux-executable: Exec format error. Wrong Architecture.
|
||||
</verb>
|
||||
</tscreen>
|
||||
then you do not have linux compatibility support and
|
||||
you need to configure and install a new kernel.
|
||||
|
||||
Depending on which version of FreeBSD you are running, how you get
|
||||
Linux-emulation up will vary slightly:
|
||||
|
||||
<sect1><heading>Installing Linux Emulation in 2.1-STABLE</heading>
|
||||
|
||||
<p>The GENERIC kernel in 2.1-STABLE is not configured for linux
|
||||
compatibility so you must reconfigure your kernel for it. There
|
||||
are two ways to do this: 1. linking the emulator statically in the
|
||||
kernel itself and 2. configuring your kernel to dynamically load the
|
||||
linux loadable kernel module (LKM).
|
||||
|
||||
<p>To enable the emulator, add the following to your configuration file
|
||||
(c.f. /sys/i386/conf/LINT):
|
||||
<tscreen>
|
||||
<verb>
|
||||
options COMPAT_LINUX
|
||||
</verb>
|
||||
</tscreen>
|
||||
If you want to run doom or other applications
|
||||
that need shared memory
|
||||
also add the following.
|
||||
<tscreen>
|
||||
<verb>
|
||||
options SYSVSHM
|
||||
</verb>
|
||||
</tscreen>
|
||||
The linux system calls require 4.3BSD system call compatibility. So
|
||||
make sure you have the following.
|
||||
<tscreen>
|
||||
<verb>
|
||||
options "COMPAT_43"
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
If you prefer to statically link the emulator in the kernel rather than
|
||||
use the loadable kernel module (LKM), then add
|
||||
<tscreen>
|
||||
<verb>
|
||||
options LINUX
|
||||
</verb>
|
||||
</tscreen>
|
||||
Then run config and install the new kernel as described in the
|
||||
<ref id="kernelconfig" name="kernel configuration"> section.
|
||||
|
||||
If you decide to use the LKM you must also install the loadable
|
||||
module. A mismatch of versions between the kernel and loadable
|
||||
module can cause the kernel to crash, so the safest thing to do is to
|
||||
reinstall the LKM when you install the kernel.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/src/lkm/linux
|
||||
% make all install
|
||||
</verb>
|
||||
</tscreen>
|
||||
Once you have installed the kernel and the LKM, you can invoke
|
||||
`linux' as root to load the LKM.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% linux
|
||||
Linux emulator installed
|
||||
Module loaded as ID 0
|
||||
%
|
||||
</verb>
|
||||
</tscreen>
|
||||
To see whether the LKM is loaded, run `modstat'.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator
|
||||
%
|
||||
</verb>
|
||||
</tscreen>
|
||||
You can cause the LKM to be loaded when the system boots in either of
|
||||
two ways. On FreeBSD 2.2-RELEASE and 2.1-STABLE enable it in
|
||||
/etc/sysconfig
|
||||
<tscreen>
|
||||
<verb>
|
||||
linux=YES
|
||||
</verb>
|
||||
</tscreen>
|
||||
by changing it from NO to YES. FreeBSD 2.1 RELEASE and earlier do not
|
||||
have such a line and on those you will need to edit /etc/rc.local to
|
||||
add the following line.
|
||||
<tscreen>
|
||||
<verb>
|
||||
linux
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<sect1><heading>Installing Linux Emulation in 2.2-RELEASE and later</heading>
|
||||
|
||||
<p>It is no longer necessary to specify ``options LINUX''
|
||||
or ``options COMPAT_LINUX''. Linux emulation is done with an LKM
|
||||
(``Loadable Kernel Module'') so it can be installed on the fly without
|
||||
having to reboot. You will need the following things in your startup files,
|
||||
however:
|
||||
<enum>
|
||||
<item> In /etc/sysconfig, you need the following line:
|
||||
<tscreen>
|
||||
<verb>
|
||||
linux=YES
|
||||
</verb>
|
||||
</tscreen>
|
||||
<item> This, in turn, triggers the following action in /etc/rc.i386:
|
||||
<tscreen>
|
||||
<verb>
|
||||
# Start the Linux binary emulation if requested.
|
||||
if [ "X${linux}" = X"YES" ]; then
|
||||
echo -n ' '; linux
|
||||
# XXX BOGUS - Linux script shouldn't make any output on success
|
||||
fi
|
||||
</verb>
|
||||
</tscreen>
|
||||
</enum>
|
||||
|
||||
<p>If you want to verify it is running, modstat will do that:
|
||||
<tscreen>
|
||||
<verb>
|
||||
% modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod
|
||||
%
|
||||
</verb>
|
||||
</tscreen>
|
||||
However, there have been reports that this fails on some 2.2-RELEASE and
|
||||
later systems. If for some reason you cannot load the linux
|
||||
LKM, then statically link the emulator in the kernel by adding
|
||||
<tscreen>
|
||||
<verb>
|
||||
options LINUX
|
||||
</verb>
|
||||
</tscreen>
|
||||
to your kernel config file. Then run config and install the new
|
||||
kernel as described in the <ref id="kernelconfig" name="kernel
|
||||
configuration"> section.
|
||||
|
||||
<sect1><heading>Installing Linux Runtime Libraries</heading>
|
||||
|
||||
<sect2><heading>Installing using the linux_lib port</heading>
|
||||
|
||||
<p>Most linux applications use shared libraries, so you are still not
|
||||
done until you install the shared libraries. It is possible to do
|
||||
this by hand, however, it is vastly simpler to just grab the
|
||||
linux_lib port:
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/ports-current/emulators/linux_lib
|
||||
% make all install
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
and you should have a working linux emulator. Legend (and the mail
|
||||
archives :-) seems to hold that Linux emulation works best with
|
||||
linux binaries linked against the ZMAGIC libraries; QMAGIC libraries
|
||||
(such as those used in Slackware V2.0) may tend to give the
|
||||
Linuxulator heartburn. As of this writing (March 1996) ELF emulation
|
||||
is still in the formulative stages but seems to work pretty well. Also,
|
||||
expect some programs to complain about incorrect minor versions. In
|
||||
general this does not seem to be a problem.
|
||||
|
||||
<sect2><heading>Installing libraries manually</heading>
|
||||
|
||||
<p>If you do not have the ``ports'' distribution, you can install the
|
||||
libraries by hand instead. You will need the Linux shared libraries
|
||||
that the program depends on and the runtime linker. Also, you will
|
||||
need to create a "shadow root" directory, /compat/linux, for Linux
|
||||
libraries on your FreeBSD system. Any shared libraries opened by
|
||||
Linux programs run under FreeBSD will look in this tree first. So, if
|
||||
a Linux program loads, for example, /lib/libc.so, FreeBSD will first
|
||||
try to open /compat/linux/lib/libc.so, and if that does not exist then
|
||||
it will try /lib/libc.so. Shared libraries should be installed in the
|
||||
shadow tree /compat/linux/lib rather than the paths that the Linux
|
||||
ld.so reports.
|
||||
|
||||
|
||||
FreeBSD-2.2-RELEASE and later works slightly differently with respect to
|
||||
/compat/linux. On -CURRENT, all files, not just libraries, are
|
||||
searched for from the ``shadow root'' /compat/linux.
|
||||
|
||||
Generally, you will need to look for the shared libraries that Linux
|
||||
binaries depend on only the first few times that you install a Linux
|
||||
program on your FreeBSD system. After a while, you will have a sufficient
|
||||
set of Linux shared libraries on your system to be able to run newly
|
||||
imported Linux binaries without any extra work.
|
||||
|
||||
<sect2><heading>How to install additional shared libraries</heading>
|
||||
|
||||
<p>What if you install the linux_lib port and your application still
|
||||
complains about missing shared libraries? How do you know which
|
||||
shared libraries Linux binaries need, and where to get them?
|
||||
Basically, there are 2 possibilities (when following these
|
||||
instructions: you will need to be root on your FreeBSD system to do
|
||||
the necessary installation steps).
|
||||
|
||||
<p>If you have access to a Linux system, see what shared libraries
|
||||
it needs, and copy them to your FreeBSD system. Example: you have
|
||||
just ftp'ed the Linux binary of Doom. Put it on the Linux
|
||||
system you have access to, and check which shared libraries it
|
||||
needs by running `ldd linuxxdoom':
|
||||
|
||||
<tscreen>
|
||||
<verb>
|
||||
% ldd linuxxdoom
|
||||
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
|
||||
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>You would need go get all the files from the last column, and
|
||||
put them under /compat/linux, with the names in the first column
|
||||
as symbolic links pointing to them. This means you eventually have
|
||||
these files on your FreeBSD system:
|
||||
<tscreen>
|
||||
<verb>
|
||||
/compat/linux/usr/X11/lib/libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
|
||||
/compat/linux/lib/libc.so.4.6.29
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>Note that if you already have a Linux shared library with a
|
||||
matching major revision number to the first column of the 'ldd'
|
||||
output, you will not need to copy the file named in the last column to
|
||||
your system, the one you already have should work. It is advisable to
|
||||
copy the shared library anyway if it is a newer version, though. You
|
||||
can remove the old one, as long as you make the symbolic link point to
|
||||
the new one. So, if you have these libraries on your system:
|
||||
<tscreen>
|
||||
<verb>
|
||||
/compat/linux/lib/libc.so.4.6.27
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
and you find a new binary that claims to require a later version
|
||||
according to the output of ldd:
|
||||
<tscreen>
|
||||
<verb>
|
||||
libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
If it is only one or two versions out of date in the in the trailing
|
||||
digit then do not worry about copying /lib/libc.so.4.6.29 too, because
|
||||
the program should work fine with the slightly older version.
|
||||
However, if you like you can decide to replace the libc.so anyway, and
|
||||
that should leave you with:
|
||||
<tscreen>
|
||||
<verb>
|
||||
/compat/linux/lib/libc.so.4.6.29
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>Please note that the symbolic link mechanism is <em>only</em>
|
||||
needed for Linux binaries, the FreeBSD runtime linker takes care of
|
||||
looking for matching major revision numbers itself, you do not need to
|
||||
worry about that.
|
||||
|
||||
<sect2><heading>Configuring the ld.so -- for FreeBSD 2.2-RELEASE only</heading>
|
||||
|
||||
<p>This section applies only to FreeBSD 2.2-RELEASE and later. Those running
|
||||
2.1-STABLE should skip this section.
|
||||
|
||||
<p>Finally, if you run FreeBSD 2.2-RELEASE you must make sure that you
|
||||
have the Linux runtime linker and its config files on your system. You
|
||||
should copy these files from the Linux system to their appropriate
|
||||
place on your FreeBSD system (to the /compat/linux tree):
|
||||
<tscreen>
|
||||
<verb>
|
||||
/compat/linux/lib/ld.so
|
||||
/compat/linux/etc/ld.so.config
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>If you do not have access to a Linux system, you should get the
|
||||
extra files you need from various ftp sites. Information on where to
|
||||
look for the various files is appended below. For now, let us assume
|
||||
you know where to get the files.
|
||||
|
||||
<p>
|
||||
Retrieve the following files (all from the same ftp site to avoid any
|
||||
version mismatches), and install them under /compat/linux
|
||||
(i.e. /foo/bar is installed as /compat/linux/foo/bar):
|
||||
<tscreen>
|
||||
<verb>
|
||||
/sbin/ldconfig
|
||||
/usr/bin/ldd
|
||||
/lib/libc.so.x.y.z
|
||||
/lib/ld.so
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>ldconfig and ldd do not necessarily need to be under /compat/linux,
|
||||
you can install them elsewhere in the system too. Just make sure they
|
||||
do not conflict with their FreeBSD counterparts. A good idea would be
|
||||
to install them in /usr/local/bin as ldconfig-linux and ldd-linux.
|
||||
<p>
|
||||
Create the file /compat/linux/etc/ld.so.conf, containing the
|
||||
directories in which the Linux runtime linker should look
|
||||
for shared libs. It is a plain text file, containing a directory
|
||||
name on each line. /lib and /usr/lib are standard, you could
|
||||
add the following:
|
||||
<tscreen>
|
||||
<verb>
|
||||
/usr/X11/lib
|
||||
/usr/local/lib
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>When a linux binary opens a library such as /lib/libc.so the
|
||||
emulator maps the name to /compat/linux/lib/libc.so internally. All
|
||||
linux libraries should be installed under /compat/linux (e.g.
|
||||
/compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so, etc.)
|
||||
in order for the emulator to find them.
|
||||
|
||||
<p>Those running FreeBSD 2.2-RELEASE should run the Linux ldconfig program.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /compat/linux/lib
|
||||
% /compat/linux/sbin/ldconfig
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>Ldconfig is statically linked, so it does not need any shared
|
||||
libraries to run. It creates the file /compat/linux/etc/ld.so.cache
|
||||
which contains the names of all the shared libraries. It should rerun
|
||||
to recreate this file whenever you install additional shared
|
||||
libraries.
|
||||
|
||||
On 2.1-STABLE do not install /compat/linux/etc/ld.so.cache or run
|
||||
ldconfig because in 2.1-STABLE the syscalls are implemented
|
||||
differently and ldconfig is not needed or used.
|
||||
|
||||
<p>You should now be set up for Linux binaries which only need a
|
||||
shared libc. You can test this by running the Linux ldd on
|
||||
itself. Suppose that you have it installed as ldd-linux, it should
|
||||
produce something like:
|
||||
<tscreen>
|
||||
<verb>
|
||||
% ldd-linux `which ldd-linux`
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>This being done, you are ready to install new Linux binaries.
|
||||
Whenever you install a new Linux program, you should check if it needs
|
||||
shared libraries, and if so, whether you have them installed in the
|
||||
/compat/linux tree. To do this, you run the Linux version ldd on the
|
||||
new program, and watch its output. ldd (see also the manual page for
|
||||
ldd(1)) will print a list of shared libraries that the program depends
|
||||
on, in the form majorname (jumpversion) => fullname.
|
||||
|
||||
<p>If it prints "not found" instead of fullname it means that you
|
||||
need an extra library. Which library this is, is shown in majorname,
|
||||
which will be of the form libXXXX.so.N You will need to find a
|
||||
libXXXX.so.N.mm on a Linux ftp site, and install it on your
|
||||
system. The XXXX (name) and N (major revision number) should match;
|
||||
the minor number(s) mm are less important, though it is advised to
|
||||
take the most recent version.
|
||||
|
||||
<sect1><heading>Configuring the host name resolver</heading>
|
||||
|
||||
<p>If DNS does not work or you get the messages
|
||||
<tscreen>
|
||||
<verb>
|
||||
resolv+: "bind" is an invalid keyword
|
||||
resolv+: "hosts" is an invalid keyword
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
then you need to configure a /compat/linux/etc/host.conf file
|
||||
containing:
|
||||
<tscreen>
|
||||
<verb>
|
||||
order hosts, bind
|
||||
multi on
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
where the order here specifies that /etc/hosts is searched first and
|
||||
DNS is searched second. When /compat/linux/etc/host.conf is not
|
||||
installed linux applications find FreeBSD's /etc/host.conf and
|
||||
complain about the incompatible FreeBSD syntax. You should remove
|
||||
`bind,' if you have not configured a name-server using the
|
||||
/etc/resolv.conf file.
|
||||
|
||||
<p>Lastly, those who run 2.1-STABLE need to set an the
|
||||
RESOLV_HOST_CONF environment variable so that applications will know
|
||||
how to search the host tables. If you run FreeBSD 2.2-RELEASE can
|
||||
skip this. For the /bin/csh shell use:
|
||||
<tscreen>
|
||||
<verb>
|
||||
setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
For /bin/sh use:
|
||||
<tscreen>
|
||||
<verb>
|
||||
RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<sect1><heading>Finding the necessary files</heading>
|
||||
|
||||
<p>Note: the information below is valid as of the time this document
|
||||
was written, but certain details such as names of ftp sites,
|
||||
directories and distribution names may have changed by the time you
|
||||
read this.
|
||||
|
||||
<p>Linux is distributed by several groups that make their own set
|
||||
of binaries that they distribute. Each distribution has its own
|
||||
name, like ``Slackware'' or ``Yggdrasil''. The distributions are
|
||||
available on a lot of ftp sites. Sometimes the files are unpacked,
|
||||
and you can get the individual files you need, but mostly they
|
||||
are stored in distribution sets, usually consisting of subdirectories
|
||||
with gzipped tar files in them. The primary ftp sites for the
|
||||
distributions are:
|
||||
<verb>
|
||||
sunsite.unc.edu:/pub/Linux/distributions
|
||||
tsx-11.mit.edu:/pub/linux/distributions
|
||||
</verb>
|
||||
|
||||
<p>
|
||||
Some European mirrors:
|
||||
<verb>
|
||||
ftp.luth.se:/pub/linux/distributions
|
||||
ftp.demon.co.uk:/pub/linux/distributions
|
||||
src.doc.ic.ac.uk:/packages/linux/distributions
|
||||
</verb>
|
||||
|
||||
<p>For simplicity, let us concentrate on Slackware here. This
|
||||
distribution consists of a number of subdirectories, containing
|
||||
separate packages. Normally, they are controlled by an install
|
||||
program, but you can retrieve files "by hand" too. First of all, you
|
||||
will need to look in the "contents" subdir of the distribution. You
|
||||
will find a lot of small text files here describing the contents of the
|
||||
separate packages. The fastest way to look something up is to retrieve
|
||||
all the files in the contents subdirectory, and grep through them for
|
||||
the file you need. Here is an example of a list of files that you
|
||||
might need, and in which contents-file you will find it by grepping
|
||||
through them:
|
||||
<tabular ca=ll>
|
||||
Library <colsep>Package <rowsep>
|
||||
ld.so <colsep>ldso <rowsep>
|
||||
ldconfig <colsep>ldso <rowsep>
|
||||
ldd <colsep>ldso <rowsep>
|
||||
libc.so.4 <colsep>shlibs <rowsep>
|
||||
libX11.so.6.0 <colsep>xf_lib <rowsep>
|
||||
libXt.so.6.0 <colsep>xf_lib <rowsep>
|
||||
libX11.so.3 <colsep>oldlibs <rowsep>
|
||||
libXt.so.3 <colsep>oldlibs <rowsep>
|
||||
</tabular>
|
||||
|
||||
<p>So, in this case, you will need the packages ldso, shlibs, xf_lib
|
||||
and oldlibs. In each of the contents-files for these packages, look
|
||||
for a line saying ``PACKAGE LOCATION'', it will tell you on which `disk'
|
||||
the package is, in our case it will tell us in which subdirectory we
|
||||
need to look. For our example, we would find the following locations:
|
||||
<tabular ca=ll>
|
||||
Package <colsep>Location <rowsep>
|
||||
ldso <colsep>diska2 <rowsep>
|
||||
shlibs <colsep>diska2 <rowsep>
|
||||
oldlibs <colsep>diskx6 <rowsep>
|
||||
xf_lib <colsep>diskx9 <rowsep>
|
||||
</tabular>
|
||||
|
||||
<p>The locations called ``diskXX'' refer to the ``slakware/XX''
|
||||
subdirectories of the distribution, others may be found in the
|
||||
``contrib'' subdirectory. In this case, we could now retrieve the
|
||||
packages we need by retrieving the following files (relative to
|
||||
the root of the Slackware distribution tree):
|
||||
<tscreen>
|
||||
<verb>
|
||||
slakware/a2/ldso.tgz
|
||||
slakware/a2/shlibs.tgz
|
||||
slakware/x6/oldlibs/tgz
|
||||
slakware/x9/xf_lib.tgz
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>Extract the files from these gzipped tarfiles in your
|
||||
/compat/linux directory (possibly omitting or afterwards
|
||||
removing files you do not need), and you are done.
|
||||
|
||||
<p><bf>See also:</bf>
|
||||
<verb>
|
||||
ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README
|
||||
|
||||
/usr/src/sys/i386/ibcs2/README.iBCS2
|
||||
</verb>
|
||||
|
||||
<sect><heading>How to Install Mathematica on FreeBSD<label id="mathematica"></heading>
|
||||
|
||||
<p><em>Contributed by &a.rich and &a.chuck</em>
|
||||
|
||||
This document shows how to install the Linux binary
|
||||
distribution of Mathematica 2.2 on FreeBSD 2.1.
|
||||
|
||||
<p>Mathematica supports Linux but not FreeBSD as it stands. So once
|
||||
you have configured your system for Linux compatibility you have most
|
||||
of what you need to run Mathematica.
|
||||
|
||||
<p>For those who already have the student edition of
|
||||
Mathematica for DOS the cost of upgrading to the Linux
|
||||
version at the time this was written, March 1996, was
|
||||
$45.00. It can be ordered directly from Wolfram at
|
||||
(217) 398-6500 and paid for by credit card.
|
||||
|
||||
<sect1><heading>Unpacking the Mathematica distribution</heading>
|
||||
<p>The binaries are currently distributed by Wolfram on CDROM.
|
||||
The CDROM has about a dozen tar files, each of which is a binary
|
||||
distribution for one of the supported architectures. The one
|
||||
for Linux is named LINUX.TAR. You can, for example, unpack this
|
||||
into /usr/local/Mathematica:
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/local
|
||||
% mkdir Mathematica
|
||||
% cd Mathematica
|
||||
% tar -xvf /cdrom/LINUX.TAR
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<sect1><heading>Obtaining your Mathematica Password</heading>
|
||||
<p>Before you can run Mathematica you will have to obtain
|
||||
a password from Wolfram that corresponds to your
|
||||
`machine ID.'
|
||||
|
||||
<p>Once you have installed the linux compatibility runtime
|
||||
libraries and unpacked the mathematica you can obtain
|
||||
the `machine ID' by running the program `mathinfo' in
|
||||
the Install directory.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/local/Mathematica/Install
|
||||
% mathinfo
|
||||
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
|
||||
richc.isdn.bcm.tmc.edu 9845-03452-90255
|
||||
%
|
||||
</verb>
|
||||
</tscreen>
|
||||
So, for example, the `machine ID' of `richc' is `9845-03452-90255'.
|
||||
You can ignore the message about the ioctl that is not
|
||||
implemented. It will not prevent Mathematica from running
|
||||
in any way and you can safely ignore it, though you
|
||||
will see the message every time you run Mathematica.
|
||||
|
||||
<p>When you register with Wolfram, either by email, phone
|
||||
or fax, you will give them the 'machine ID' and they will
|
||||
respond with a corresponding password consisting of
|
||||
groups of numbers. You need to add them both along
|
||||
with the machine name and license number in your
|
||||
mathpass file.
|
||||
|
||||
You can do this by invoking:
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/local/Mathematica/Install
|
||||
% math.install
|
||||
</verb>
|
||||
</tscreen>
|
||||
It will ask you to enter your license number and the
|
||||
Wolfram supplied password. If you get them mixed up or
|
||||
for some reason the math.install fails, That is OK,
|
||||
because you can simply edit the file 'mathpass' in this
|
||||
same directory to correct the info manually.
|
||||
|
||||
<p>After getting past the password, math.install will ask
|
||||
you if you accept their canned install defaults, or if
|
||||
you want to use your own. If you are like us and
|
||||
distrust all install programs, you probably want to
|
||||
specify the actual directories. Beware. Although the
|
||||
math.install program asks you to specify directories,
|
||||
it will not create them for you, so you should perhaps
|
||||
have a second window open with another shell so that
|
||||
you can create them before you give them to the install
|
||||
program. Or, if it fails, you
|
||||
can create the directories and then restart the
|
||||
math.install program. The directories we chose to
|
||||
create beforehand and specify to math.install were:
|
||||
<tscreen>
|
||||
<verb>
|
||||
/usr/local/Mathematica/bin for binaries
|
||||
/usr/local/Mathematica/man/man1 for man pages
|
||||
/usr/local/Mathematica/lib/X11 for the XKeysymb file
|
||||
</verb>
|
||||
</tscreen>
|
||||
You can also tell it to use /tmp/math.record for the
|
||||
system record file, where it puts logs of sessions.
|
||||
After this math.install will continue on to
|
||||
unpacking things and placing everything where it should
|
||||
go.
|
||||
|
||||
<p>The Mathematica Notebook feature is included separately,
|
||||
as the X Front End, and you have to install it separately.
|
||||
To get the X Front End stuff correctly installed, cd
|
||||
into the /usr/local/Mathematica/FrontEnd directory and
|
||||
executed the ./xfe.install shell script. You will have
|
||||
to tell it where to put things, but you do not have to
|
||||
create any directories because it uses all the same
|
||||
directories that had been created for math.install.
|
||||
When it finished, there should be a new shell script in
|
||||
/usr/local/Mathematica/bin called "mathematica".
|
||||
|
||||
<p>Lastly, you need to modify each of the shell scripts that
|
||||
Mathematica has installed. At the beginning of every shell script in
|
||||
/usr/local/Mathematica/bin add the following line:
|
||||
<tscreen>
|
||||
<verb>
|
||||
XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB
|
||||
</verb>
|
||||
</tscreen>
|
||||
This tells Mathematica were to find its own version of the key
|
||||
mapping file XKeysymDB. Without this you will get pages of error
|
||||
messages about missing key mappings.
|
||||
|
||||
On 2.1-STABLE you need to add the following as well:
|
||||
<tscreen>
|
||||
<verb>
|
||||
RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF
|
||||
</verb>
|
||||
</tscreen>
|
||||
This tells Mathematica to use the linux version of host.conf. This
|
||||
file has a different syntax from FreeBSD's host.conf, so you will get an
|
||||
error message about /etc/host.conf if you leave this out.
|
||||
|
||||
<p>You might want to also modify your /etc/manpath.config file
|
||||
to read the new man directory, and you may need to edit your
|
||||
~/.cshrc file to add /usr/local/Mathematica/bin
|
||||
to your path.
|
||||
|
||||
<p>That is about all it takes, With this you should be able
|
||||
to type "mathematica" and get a really slick looking
|
||||
Mathematica Notebook screen up. Mathematica has included
|
||||
the Motif user interfaces, but it is compiled in statically,
|
||||
so you do not need the Motif libraries. Good luck doing this
|
||||
yourself!
|
||||
|
||||
<sect1><heading>Bugs</heading>
|
||||
|
||||
<p>The Notebook front end is known to hang sometimes when reading
|
||||
notebook files with an error messages similar to:
|
||||
<tscreen>
|
||||
<verb>
|
||||
File .../Untitled-1.mb appears to be broken for OMPR.257.0
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
We have not found the cause for this, but it only affects the
|
||||
Notebook's X Window front end, not the mathematica engine itself. So
|
||||
the command line interface invoked by 'math' is unaffected by this
|
||||
bug.
|
||||
|
||||
<sect1><heading>Acknowledgments</heading>
|
||||
|
||||
<p>A well-deserved thanks should go to &a.sos; and &a.peter;
|
||||
who made linux emulation what it is today, and Michael Smith who
|
||||
drove these two guys like dogs to get it to the point where it runs
|
||||
Linux binaries better than linux! :-)
|
||||
@ -1,67 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
Names and email address of contributing authors and CVS committers
|
||||
and some of the common FreeBSD mailing lists. Use these
|
||||
entities when referencing people or mailing lists. Please
|
||||
note the use of single
|
||||
and double quotes.
|
||||
-->
|
||||
|
||||
<!ENTITY a.announce "FreeBSD announcements mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-announce@FreeBSD.ORG'
|
||||
name='<freebsd-announce@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.cvsall "FreeBSD CVS commit message mailing list
|
||||
<tt><htmlurl url='mailto:cvs-all@FreeBSD.ORG'
|
||||
name='<cvs-all@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.doc "FreeBSD documentation project mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-doc@FreeBSD.ORG'
|
||||
name='<freebsd-doc@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.bugs "FreeBSD problem reports mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-bugs@FreeBSD.ORG'
|
||||
name='<freebsd-bugs@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.current "FreeBSD-current mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-current@FreeBSD.ORG'
|
||||
name='<freebsd-current@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.emulation "FreeBSD-emulation mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-emulation@FreeBSD.ORG'
|
||||
name='<freebsd-emulation@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.fs "FreeBSD filesystem project mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-fs@FreeBSD.ORG'
|
||||
name='<freebsd-fs@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.hackers "FreeBSD technical discussions mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-hackers@FreeBSD.ORG'
|
||||
name='<freebsd-hackers@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ports "FreeBSD ports mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-ports@FreeBSD.ORG'
|
||||
name='<freebsd-ports@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.questions "FreeBSD general questions mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-questions@FreeBSD.ORG'
|
||||
name='<freebsd-questions@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.scsi "FreeBSD SCSI subsystem mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-scsi@FreeBSD.ORG'
|
||||
name='<freebsd-scsi@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.stable "FreeBSD-stable mailing list
|
||||
<tt><htmlurl url='mailto:freebsd-stable@FreeBSD.ORG'
|
||||
name='<freebsd-stable@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.majordomo "<tt><htmlurl url='mailto:majordomo@FreeBSD.ORG'
|
||||
name='<majordomo@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.core "FreeBSD core team
|
||||
<tt><htmlurl url='mailto:freebsd-core@FreeBSD.ORG'
|
||||
name='<freebsd-core@FreeBSD.ORG>'></tt>">
|
||||
|
||||
|
||||
@ -1,430 +0,0 @@
|
||||
<!-- $Id$
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
||||
<linuxdoc>
|
||||
<article>
|
||||
<title> Mail
|
||||
<author> &a.wlloyd;
|
||||
<date> 24 Nov 1996, (c) 1996
|
||||
|
||||
<abstract> This section contains basic information on setting up Electronic Mail on your new FreeBSD box.
|
||||
</abstract>
|
||||
|
||||
<toc>
|
||||
-->
|
||||
|
||||
<chapt><heading>Electronic Mail<label id="mail"></heading>
|
||||
|
||||
<p><em>Contributed by &a.wlloyd;.</em>
|
||||
|
||||
<p> Electronic Mail configuration is the subject of many <ref name="System Administration" id="bibliography"> books. If you plan on doing anything beyond setting up one mailhost for your network, you need industrial strength help.
|
||||
|
||||
Some parts of E-Mail configuration are controlled in the Domain Name System (DNS). If you are going to run your own own DNS server check out <bf> <tt> /etc/namedb </tt></bf> and ' <bf><tt>man -k named </tt></bf> ' for more information.
|
||||
|
||||
<sect><heading>Basic Information</heading>
|
||||
|
||||
<p>
|
||||
These are the major programs involved in an E-Mail exchange.
|
||||
A <tt/mailhost/ is a server that is responsible for delivering and receiving all email for your host, and possibly your network.
|
||||
|
||||
<sect1><heading>User program</heading>
|
||||
<p> This is a program like <tt /elm, pine, mail/ , or something more sophisticated like a WWW browser. This program will simply pass off all e-mail transactions to the local <tt/mailhost/ , either by calling <tt>sendmail</tt> or delivering it over TCP.
|
||||
|
||||
<sect1><heading>Mailhost Server Daemon</heading>
|
||||
<p> Usually this program is <tt /sendmail or smail/ running in the background. Turn it off or change the command line options in <tt> /etc/sysconfig </tt>. It is best to leave it on, unless you have a specific reason to want it off. Example: You are building a <ref name="Firewall" id="firewalls">.
|
||||
|
||||
<p>You should be aware that <tt>sendmail</tt> is a potential weak link in a secure site. Some versions of <tt>sendmail</tt> have known security problems.
|
||||
|
||||
<p> <tt><bf> sendmail </bf></tt> does two jobs. It looks after delivering and receiving mail.
|
||||
|
||||
If <bf><tt/sendmail/ </bf> needs to delivery mail off your site it will look up in the DNS to determine the actual host that will receive mail for the destination.
|
||||
|
||||
<p> If it is acting as a delivery agent <tt/sendmail/ will take the message from the local queue and deliver it across the Internet to another sendmail on the receivers computer.
|
||||
|
||||
<sect1><heading>DNS - Name Service</heading>
|
||||
<p>The Domain Name System and its daemon <tt/named/ , contain the database mapping hostname to IP address, and hostname to mailhost. The IP address is specified in an "A" record. The "MX" record specifies the mailhost that will receive mail for you. If you do not have a "MX" record mail for your hostname, the mail will be delivered to your host directly.
|
||||
|
||||
Unless you are running your own DNS server, you will not be able to change any information in the DNS yourself. If you are using an Internet Provider, speak to them.
|
||||
|
||||
<sect1><heading>POP Servers</heading>
|
||||
<p> This program gets the mail from your mailbox and gives it to your browser. If you want to run a POP server on your computer, you will need to do 2 things.
|
||||
<itemize>
|
||||
<item>Get pop software from the <url url="../ports/mail.html" name="Ports collection"> that can be found in <tt><bf>/usr/ports </bf></tt>
|
||||
or packages collection. This handbook section has a complete reference on the <ref name="Ports" id="ports"> system.
|
||||
<item>Modify <bf><tt>/etc/inetd.conf</tt></bf> to load the POP server.
|
||||
</itemize>
|
||||
|
||||
The pop program will have instructions with it. Read them.
|
||||
|
||||
</sect>
|
||||
|
||||
<sect><heading>Configuration</heading>
|
||||
|
||||
<sect1><heading>Basic</heading>
|
||||
<p>
|
||||
As your FreeBSD system comes "out of the box"[TM], you should be able to send E-mail to external hosts as long as you have <bf><tt>/etc/resolv.conf</tt> </bf> setup or are running a name server.
|
||||
If you want to have mail for your host delivered to your specific host,there are two methods:
|
||||
<p>
|
||||
- Run a name server ( <tt><bf>man -k named</></> ) and have your own domain <tt>smallminingco.com </tt>
|
||||
<p>
|
||||
- Get mail delivered to the current DNS name for your host. Ie: <tt>dorm6.ahouse.school.edu </tt>
|
||||
<p>
|
||||
No matter what option you choose, to have mail delivered directly to your host, you must be a full Internet host. You must have a permanent IP address. IE: NO dynamic PPP. If you are behind a firewall, the firewall must be passing on smtp traffic to you. From <bf><tt> /etc/services </tt></bf>
|
||||
<verb>
|
||||
smtp 25/tcp mail #Simple Mail Transfer
|
||||
</verb>
|
||||
If you want to receive mail at your host itself, you must make sure that the DNS MX entry points to your host address, or there is no MX entry for your DNS name.
|
||||
|
||||
Try this
|
||||
<verb>
|
||||
newbsdbox# hostname
|
||||
newbsdbox.freebsd.org
|
||||
newbsdbox# host newbsdbox.freebsd.org
|
||||
newbsdbox.freebsd.org has address 204.216.27.xx
|
||||
</verb>
|
||||
|
||||
If that is all that comes out for your machine, mail directory to <tt><bf>root@newbsdbox.freebsd.org </bf></tt> will work no problems.
|
||||
|
||||
If instead, you have this
|
||||
<verb>
|
||||
newbsdbox# host newbsdbox.freebsd.org
|
||||
newbsdbox.FreeBSD.org has address 204.216.27.xx
|
||||
newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.org
|
||||
</verb>
|
||||
All mail sent to your host directly will end up on freefall, under the same username.
|
||||
|
||||
This information is setup in your domain name server. This should be the same host that is listed as your primary nameserver in <bf><tt> /etc/resolv.conf</tt></bf>
|
||||
|
||||
The DNS record that carries mail routing information is the Mail eXchange entry. If no MX entry exists, mail will be delivered directly to the host by way of the Address record.
|
||||
|
||||
The MX entry for freefall.freebsd.org at one time.
|
||||
<verb>
|
||||
freefall MX 30 mail.crl.net
|
||||
freefall MX 40 agora.rdrop.com
|
||||
freefall HINFO Pentium FreeBSD
|
||||
freefall MX 10 freefall.FreeBSD.org
|
||||
freefall MX 20 who.cdrom.com
|
||||
freefall A 204.216.27.xx
|
||||
freefall CNAME www.FreeBSD.org
|
||||
</verb>
|
||||
|
||||
Freefall has many MX entries. The lowest MX number gets the mail in the end. The others will queue mail temporarily, if freefall is busy or down.
|
||||
|
||||
Alternate MX sites should have separate connections to the Internet, to be most useful. An Internet Provider or other friendly site can provide this service.
|
||||
|
||||
<bf><tt>dig, nslookup, </tt></bf>and<bf><tt> host </tt></bf>are your friends.
|
||||
|
||||
<sect1><heading>Mail for your Domain (Network).<label id="mail:domain"></heading>
|
||||
<p>
|
||||
To setup up a network mailhost, you need to direct the mail from arriving at all the workstations. In other words, you want to hijack all mail for <tt> *.smallminingco.com </tt> and divert it to one machine, your mailhost.
|
||||
|
||||
The network users on their workstations will most likely pick up their mail over POP or telnet.
|
||||
|
||||
A user account with the SAME USERNAME should exist on both machines. Please use <tt/adduser/ to do this as required. If you set the <tt/shell/ to <tt>/nonexistent</tt> the user will not be allowed to login.
|
||||
|
||||
The mailhost that you will be using must be designated the Mail eXchange for each workstation. This must be arranged in DNS (ie BIND, named). Please refer to a Networking book for in-depth information.
|
||||
|
||||
You basically need to add these lines in your DNS server.
|
||||
<verb>
|
||||
pc24.smallminingco.com A xxx.xxx.xxx.xxx ; Workstation ip
|
||||
MX 10 smtp.smallminingco.com ; Your mailhost
|
||||
</verb>
|
||||
|
||||
You cannot do this yourself unless you are running a DNS server. If you do not want to run a DNS server, get somebody else like your Internet Provider to do it.
|
||||
|
||||
This will redirect mail for the workstation to the Mail eXchange host. It does not matter what machine the A record points to, the mail will be sent to the MX host.
|
||||
<p>
|
||||
This feature is used to implement Virtual E-Mail Hosting.
|
||||
<p>Example
|
||||
<p>
|
||||
I have a customer with domain foo.bar and I want all mail for foo.bar to be sent to my machine smtp.smalliap.com. You must make an entry in your DNS server like:
|
||||
<verb>
|
||||
foo.bar MX 10 smtp.smalliap.com ; your mailhost
|
||||
</verb>
|
||||
The A record is not needed if you only want E-Mail for the domain. IE: Don't expect <bf><tt>ping foo.bar</tt></bf> to work unless an Address record for <tt>foo.bar</tt> exists as well.
|
||||
|
||||
On the mailhost that actually accepts mail for final delivery to a mailbox, sendmail must be told what hosts it will be accepting mail for.
|
||||
|
||||
<p>Add pc24.smallminingco.com to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)), or add a "Cw myhost.smalliap.com" line to <bf><tt>/etc/sendmail.cf</tt></bf>
|
||||
<p>
|
||||
If you plan on doing anything serious with <tt/sendmail/ you should install the sendmail source. The source has plenty of documentation with it. You will find information on getting <tt/sendmail/ source from <ref name="the UUCP information" id="sendmailuucp">.
|
||||
|
||||
|
||||
<sect1>
|
||||
<heading> Setting up UUCP.<label id="sendmailuucp"></heading>
|
||||
<p><em>Stolen from the FAQ.</em>
|
||||
<p>
|
||||
The sendmail configuration that ships with FreeBSD is
|
||||
suited for sites that connect directly to the Internet.
|
||||
Sites that wish to exchange their mail via UUCP must install
|
||||
another sendmail configuration file.
|
||||
|
||||
<p>
|
||||
Tweaking <tt>/etc/sendmail.cf</tt> manually is considered
|
||||
something for purists. Sendmail version 8 comes with a
|
||||
new approach of generating config files via some <tt>m4</tt>
|
||||
preprocessing, where the actual hand-crafted configuration
|
||||
is on a higher abstraction level. You should use the
|
||||
configuration files under
|
||||
|
||||
<verb>
|
||||
/usr/src/usr.sbin/sendmail/cf
|
||||
</verb>
|
||||
|
||||
If you did not install your system with full sources,
|
||||
the sendmail config stuff has been
|
||||
broken out into a separate source distribution tarball just
|
||||
for you. Assuming you have your CD-ROM mounted, do:
|
||||
|
||||
<verb>
|
||||
cd /usr/src
|
||||
tar -xvzf /cdrom/dists/src/ssmailcf.aa
|
||||
</verb>
|
||||
|
||||
Do not panic, this is only a few hundred kilobytes in size.
|
||||
The file <tt>README</tt> in the <tt>cf</tt> directory can
|
||||
serve as a basic introduction to m4 configuration.
|
||||
|
||||
<p>
|
||||
For UUCP delivery, you are best advised to use the
|
||||
<em>mailertable</em> feature. This constitutes a database
|
||||
that sendmail can use to base its routing decision upon.
|
||||
|
||||
<p>
|
||||
First, you have to create your <tt>.mc</tt> file. The
|
||||
directory <tt>/usr/src/usr.sbin/sendmail/cf/cf</tt> is the
|
||||
home of these files. Look around, there are already a few
|
||||
examples. Assuming you have named your file <tt>foo.mc</tt>,
|
||||
all you need to do in order to convert it into a valid
|
||||
<tt>sendmail.cf</tt> is:
|
||||
|
||||
<verb>
|
||||
cd /usr/src/usr.sbin/sendmail/cf/cf
|
||||
make foo.cf
|
||||
cp foo.cf /etc/sendmail.cf
|
||||
</verb>
|
||||
|
||||
A typical <tt>.mc</tt> file might look like:
|
||||
|
||||
<verb>
|
||||
include(`../m4/cf.m4')
|
||||
VERSIONID(`Your version number')
|
||||
OSTYPE(bsd4.4)
|
||||
|
||||
FEATURE(nodns)
|
||||
FEATURE(nocanonify)
|
||||
FEATURE(mailertable)
|
||||
|
||||
define(`UUCP_RELAY', your.uucp.relay)
|
||||
define(`UUCP_MAX_SIZE', 200000)
|
||||
|
||||
MAILER(local)
|
||||
MAILER(smtp)
|
||||
MAILER(uucp)
|
||||
|
||||
Cw your.alias.host.name
|
||||
Cw youruucpnodename.UUCP
|
||||
</verb>
|
||||
|
||||
The <em>nodns</em> and <em>nocanonify</em> features will
|
||||
prevent any usage of the DNS during mail delivery. The
|
||||
<em>UUCP_RELAY</em> clause is needed for bizarre reasons,
|
||||
do not ask. Simply put an Internet hostname there that
|
||||
is able to handle .UUCP pseudo-domain addresses; most likely,
|
||||
you will enter the mail relay of your ISP there.
|
||||
|
||||
<p>
|
||||
Once you have this, you need this file called
|
||||
<tt>/etc/mailertable</tt>. A typical example of this
|
||||
gender again:
|
||||
|
||||
<verb>
|
||||
#
|
||||
# makemap hash /etc/mailertable.db < /etc/mailertable
|
||||
#
|
||||
horus.interface-business.de uucp-dom:horus
|
||||
.interface-business.de uucp-dom:if-bus
|
||||
interface-business.de uucp-dom:if-bus
|
||||
.heep.sax.de smtp8:%1
|
||||
horus.UUCP uucp-dom:horus
|
||||
if-bus.UUCP uucp-dom:if-bus
|
||||
. uucp-dom:sax
|
||||
</verb>
|
||||
|
||||
As you can see, this is part of a real-life file. The first
|
||||
three lines handle special cases where domain-addressed mail
|
||||
should not be sent out to the default route, but instead to
|
||||
some UUCP neighbor in order to ``shortcut'' the delivery
|
||||
path. The next line handles mail to the local Ethernet
|
||||
domain that can be delivered using SMTP. Finally, the UUCP
|
||||
neighbors are mentioned in the .UUCP pseudo-domain notation,
|
||||
to allow for a ``uucp-neighbor!recipient'' override of the
|
||||
default rules. The last line is always a single dot, matching
|
||||
everything else, with UUCP delivery to a UUCP neighbor that
|
||||
serves as your universal mail gateway to the world. All of
|
||||
the node names behind the <tt>uucp-dom:</tt> keyword must
|
||||
be valid UUCP neighbors, as you can verify using the
|
||||
command <tt>uuname</tt>.
|
||||
|
||||
<p>
|
||||
As a reminder that this file needs to be converted into a
|
||||
DBM database file before being usable, the command line to
|
||||
accomplish this is best placed as a comment at the top of
|
||||
the mailertable. You always have to execute this command
|
||||
each time you change your mailertable.
|
||||
|
||||
<p>
|
||||
Final hint: if you are uncertain whether some particular
|
||||
mail routing would work, remember the <tt>-bt</tt> option to
|
||||
sendmail. It starts sendmail in <em>address test mode</em>;
|
||||
simply enter ``0 '', followed by the address you wish to
|
||||
test for the mail routing. The last line tells you the used
|
||||
internal mail agent, the destination host this agent will be
|
||||
called with, and the (possibly translated) address. Leave
|
||||
this mode by typing Control-D.
|
||||
|
||||
<verb>
|
||||
j@uriah 191% sendmail -bt
|
||||
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
|
||||
Enter <ruleset> <address>
|
||||
> 0 foo@interface-business.de
|
||||
rewrite: ruleset 0 input: foo @ interface-business . de
|
||||
...
|
||||
rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \
|
||||
< @ interface-business . de >
|
||||
> ^D
|
||||
j@uriah 192%
|
||||
</verb>
|
||||
</sect>
|
||||
|
||||
<sect><heading>FAQ<label id="mailfaq"></heading>
|
||||
|
||||
<p><em>Migration from FAQ.</em>
|
||||
|
||||
<sect1>
|
||||
|
||||
<heading>Why do I have to use the FQDN for hosts on my site?</heading>
|
||||
<p>
|
||||
You will probably find that the host is actually in a different
|
||||
domain; for example, if you are in foo.bar.edu and you wish to reach
|
||||
a host called ``mumble'' in the bar.edu domain, you will have to
|
||||
refer to it by the fully-qualified domain name, ``mumble.bar.edu'',
|
||||
instead of just ``mumble''.
|
||||
<p>
|
||||
Traditionally, this was allowed by BSD BIND resolvers. However
|
||||
the current version of <em>BIND</em> that ships with FreeBSD
|
||||
no longer provides default abbreviations for non-fully
|
||||
qualified domain names other than the domain you are in.
|
||||
So an unqualified host <tt>mumble</tt> must either be found
|
||||
as <tt>mumble.foo.bar.edu</tt>, or it will be searched for
|
||||
in the root domain.
|
||||
<p>
|
||||
This is different from the previous behavior, where the
|
||||
search continued across <tt>mumble.bar.edu</tt>, and
|
||||
<tt>mumble.edu</tt>. Have a look at RFC 1535 for why this
|
||||
was considered bad practice, or even a security hole.
|
||||
<p>
|
||||
As a good workaround, you can place the line
|
||||
<p><tt>
|
||||
search foo.bar.edu bar.edu
|
||||
</tt><p>
|
||||
instead of the previous
|
||||
|
||||
<p><tt>
|
||||
domain foo.bar.edu
|
||||
</tt><p>
|
||||
into your <tt>/etc/resolv.conf</tt>. However, make sure
|
||||
that the search order does not go beyond the ``boundary
|
||||
between local and public administration'', as RFC 1535
|
||||
calls it.
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1><heading>Sendmail says ``mail loops back to myself''</heading>
|
||||
<p>
|
||||
This is answered in the sendmail FAQ as follows:-
|
||||
<verb>
|
||||
* I am getting "Local configuration error" messages, such as:
|
||||
|
||||
553 relay.domain.net config error: mail loops back to myself
|
||||
554 <user@domain.net>... Local configuration error
|
||||
|
||||
How can I solve this problem?
|
||||
|
||||
You have asked mail to the domain (e.g., domain.net) to be
|
||||
forwarded to a specific host (in this case, relay.domain.net)
|
||||
by using an MX record, but the relay machine does not recognize
|
||||
itself as domain.net. Add domain.net to /etc/sendmail.cw
|
||||
(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
|
||||
to /etc/sendmail.cf.
|
||||
</verb>
|
||||
<p>
|
||||
The sendmail FAQ is in <tt>/usr/src/usr.sbin/sendmail</tt>
|
||||
and is recommended reading if you want to do any
|
||||
``tweaking'' of your mail setup.
|
||||
|
||||
|
||||
<sect1><heading>How can I do E-Mail with a dialup PPP host?</heading>
|
||||
<p>
|
||||
You want to connect a FreeBSD box on a lan, to the Internet. The FreeBSD box will be a mail gateway for the lan. The PPP connection is non-dedicated.
|
||||
|
||||
There are at least two way to do this.
|
||||
|
||||
The other is to use UUCP.
|
||||
|
||||
The key is to get a Internet site to provide secondary MX services for your domain.
|
||||
For example:
|
||||
<verb>
|
||||
bigco.com. MX 10 bigco.com.
|
||||
MX 20 smalliap.com.
|
||||
</verb>
|
||||
|
||||
Only one host should be specified as the final recipient ( add ``Cw bigco.com'' in <tt>/etc/sendmail.cf</tt> on bigco.com).
|
||||
|
||||
When the senders sendmail is trying to deliver the mail it will try to connect to you over the modem link. It will most likely time out because you are not online. Sendmail will automatically deliver it to the secondary MX site, ie your Internet provider. The secondary MX site will try every (<tt>sendmail_flags = "-bd -q15m"</tt> in <tt>/etc/sysconfig</tt> ) 15 minutes to connect to your host to deliver the mail to the primary MX site.
|
||||
|
||||
You might wat to use something like this as a login script.
|
||||
<verb>
|
||||
#!/bin/sh
|
||||
# Put me in /usr/local/bin/pppbigco
|
||||
( sleep 60 ; /usr/sbin/sendmail -q ) &
|
||||
/usr/sbin/ppp -direct pppbigco
|
||||
</verb>
|
||||
If you are going to create a separate login script for a user you could use <tt>sendmail -qRbigco.com</tt> instead in the script above. This will force all mail in your queue for bigco.com to be processed immediately.
|
||||
|
||||
|
||||
A further refinement of the situation is as follows.
|
||||
|
||||
Message stolen from the freebsd-isp mailing list.
|
||||
<verb>
|
||||
> we provide the secondary mx for a customer. The customer connects to
|
||||
> our services several times a day automatically to get the mails to
|
||||
> his primary mx (We do not call his site when a mail for his domains
|
||||
> arrived). Our sendmail sends the mailqueue every 30 minutes. At the
|
||||
> moment he has to stay 30 minutes online to be sure that all mail is
|
||||
> gone to the primary mx.
|
||||
>
|
||||
> Is there a command that would initiate sendmail to send all the mails
|
||||
> now? The user has not root-privileges on our machine of course.
|
||||
|
||||
In the 'privacy flags' section of sendmail.cf, there is a definition
|
||||
Opgoaway,restrictqrun
|
||||
|
||||
Remove restrictqrun to allow non-root users to start the queue processing.
|
||||
You might also like to rearrange the MXs. We are the 1st MX for our
|
||||
customers like this, and we have defined:
|
||||
|
||||
# If we are the best MX for a host, try directly instead of generating
|
||||
# local config error.
|
||||
OwTrue
|
||||
|
||||
That way a remote site will deliver straight to you, without trying
|
||||
the customer connection. You then send to your customer. Only works for
|
||||
"hosts", so you need to get your customer to name their mail machine
|
||||
"customer.com" as well as "hostname.customer.com" in the DNS. Just put
|
||||
an A record in the DNS for "customer.com".
|
||||
</verb>
|
||||
|
||||
</sect1>
|
||||
@ -1,50 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>PC memory utilization<label id="memoryuse"></heading>
|
||||
|
||||
<p><em>Contributed by &a.joerg;.<newline>
|
||||
16 Apr 1995.</em>
|
||||
|
||||
<em>A short description of how FreeBSD uses the memory on the i386
|
||||
platform</em>
|
||||
|
||||
The boot sector will be loaded at <tt>0:0x7c00</tt>, and relocates itself
|
||||
immediately to <tt>0x7c0:0</tt>. (This is nothing magic, just an adjustment
|
||||
for the <tt>%cs</tt> selector, done by an <tt>ljmp</tt>.)
|
||||
|
||||
It then loads the first 15 sectors at <tt>0x10000</tt> (segment BOOTSEG in the
|
||||
biosboot Makefile), and sets up the stack to work below <tt>0x1fff0</tt>.
|
||||
After this, it jumps to the entry of boot2 within that code. I.e., it
|
||||
jumps over itself and the (dummy) partition table, and it is going to
|
||||
adjust the %cs selector---we are still in 16-bit mode there.
|
||||
|
||||
boot2 asks for the boot file, and examines the <tt>a.out</tt> header. It masks
|
||||
the file entry point (usually <tt>0xf0100000</tt>) by <tt>0x00ffffff</tt>, and loads the
|
||||
file there. Hence the usual load point is 1 MB (<tt>0x00100000</tt>). During
|
||||
load, the boot code toggles back and forth between real and protected
|
||||
mode, to use the BIOS in real mode.
|
||||
|
||||
The boot code itself uses segment selectors <tt>0x18</tt> and <tt>0x20</tt> for <tt>%cs</tt> and
|
||||
<tt>%ds/%es</tt> in protected mode, and <tt>0x28</tt> to jump back into real mode. The
|
||||
kernel is finally started with <tt>%cs</tt> <tt>0x08</tt> and <tt>%ds/%es/%ss</tt> <tt>0x10</tt>, which
|
||||
refer to dummy descriptors covering the entire address space.
|
||||
|
||||
The kernel will be started at its load point. Since it has been linked
|
||||
for another (high) address, it will have to execute PIC until the page
|
||||
table and page directory stuff is setup properly, at which point
|
||||
paging will be enabled and the kernel will finally run at the address
|
||||
for which it was linked.
|
||||
|
||||
|
||||
<em>Contributed by &a.davidg;.<newline>
|
||||
16 Apr 1995.</em>
|
||||
|
||||
The physical pages immediately following the kernel BSS contain
|
||||
proc0's page directory, page tables, and upages. Some time later
|
||||
when the VM system is initialized, the physical memory between
|
||||
<tt>0x1000-0x9ffff</tt> and the physical memory after the kernel
|
||||
(text+data+bss+proc0 stuff+other misc) is made available in the
|
||||
form of general VM pages and added to the global free page list.
|
||||
|
||||
|
||||
@ -1,702 +0,0 @@
|
||||
<!-- $Id: mirrors.sgml,v 1.55 1997/04/25 20:03:48 max Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<!doctype linuxdoc public "-//FreeBSD//DTD linuxdoc//EN">
|
||||
-->
|
||||
|
||||
<chapt><heading>Obtaining FreeBSD<label id="mirrors"></heading>
|
||||
|
||||
<sect><heading>CD-ROM Publishers</heading>
|
||||
|
||||
<p>FreeBSD is available on CD-ROM from Walnut Creek CDROM:
|
||||
<quote>
|
||||
Walnut Creek CDROM<newline>
|
||||
1547 Palos Verdes Mall, Suite 260<newline>
|
||||
Walnut Creek CA 94596 USA<newline>
|
||||
Phone: +1 510 674-0783<newline>
|
||||
Fax: +1 510 674-0821<newline>
|
||||
Email: <url url="mailto:info@cdrom.com" name="info@cdrom.com"><newline>
|
||||
WWW: <url url="http://www.cdrom.com/" name="http://www.cdrom.com/">
|
||||
</quote>
|
||||
|
||||
<sect><heading>FTP Sites<label id="mirrors-ftp"></heading>
|
||||
|
||||
<p>The official sources for FreeBSD are available via anonymous FTP from:
|
||||
<quote>
|
||||
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.FreeBSD.ORG/pub/FreeBSD">.
|
||||
</quote>
|
||||
|
||||
<p>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.
|
||||
|
||||
<ref id="mirrors-ar" name="Argentina">,
|
||||
<ref id="mirrors-au" name="Australia">,
|
||||
<ref id="mirrors-br" name="Brazil">,
|
||||
<ref id="mirrors-ca" name="Canada">,
|
||||
<ref id="mirrors-cz" name="Czech Republic">,
|
||||
<ref id="mirrors-dk" name="Denmark">,
|
||||
<ref id="mirrors-ee" name="Estonia">,
|
||||
<ref id="mirrors-fi" name="Finland">,
|
||||
<ref id="mirrors-fr" name="France">,
|
||||
<ref id="mirrors-de" name="Germany">,
|
||||
<ref id="mirrors-hk" name="Hong Kong">,
|
||||
<ref id="mirrors-ie" name="Ireland">,
|
||||
<ref id="mirrors-il" name="Israel">,
|
||||
<ref id="mirrors-jp" name="Japan">,
|
||||
<ref id="mirrors-kr" name="Korea">,
|
||||
<ref id="mirrors-nl" name="Netherlands">,
|
||||
<ref id="mirrors-pl" name="Poland">,
|
||||
<ref id="mirrors-pt" name="Portugal">,
|
||||
<ref id="mirrors-ru" name="Russia">,
|
||||
<ref id="mirrors-za" name="South Africa">,
|
||||
<ref id="mirrors-se" name="Sweden">,
|
||||
<ref id="mirrors-tw" name="Taiwan">,
|
||||
<ref id="mirrors-th" name="Thailand">,
|
||||
<ref id="mirrors-us" name="USA">,
|
||||
<ref id="mirrors-uk" name="UK">.
|
||||
|
||||
<descrip>
|
||||
<tag><label id="mirrors-ar">Argentina</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@ar.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.ar.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.ar.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-au">Australia</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@au.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.au.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.au.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.au.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.au.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.au.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp3.au.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp4.au.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp4.au.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-br">Brazil</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@br.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
<item>
|
||||
<url url="ftp://ftp.br.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.br.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.br.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.br.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.br.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp3.br.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp4.br.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp4.br.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp5.br.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp5.br.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp6.br.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp6.br.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp7.br.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp7.br.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-ca">Canada</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@ca.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.ca.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.ca.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-cz">Czech Republic</tag>
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://sunsite.mff.cuni.cz/OS/FreeBSD"
|
||||
name="ftp://sunsite.mff.cuni.cz/OS/FreeBSD"><newline>
|
||||
Contact: <url url="mailto:jj@sunsite.mff.cuni.cz"
|
||||
name="jj@sunsite.mff.cuni.cz">.
|
||||
|
||||
</itemize>
|
||||
|
||||
|
||||
<tag><label id="mirrors-dk">Denmark</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@dk.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.dk.freeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.dk.freeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-ee">Estonia</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@ee.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.ee.freebsd.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.ee.freebsd.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-fi">Finland</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@fi.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.fi.freebsd.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.fi.freebsd.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-fr">France</tag>
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.ibp.fr/pub/FreeBSD"
|
||||
name="ftp://ftp.ibp.fr/pub/FreeBSD"><newline>
|
||||
Contact: <url url="mailto:Remy.Card@ibp.fr"
|
||||
name="Remy.Card@ibp.fr">.
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-de">Germany</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@de.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.de.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.de.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.de.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.de.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.de.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp3.de.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp4.de.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp4.de.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp5.de.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp5.de.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp6.de.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp6.de.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp7.de.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp7.de.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-hk">Hong Kong</tag>
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.hk.super.net/pub/FreeBSD"
|
||||
name="ftp://ftp.hk.super.net/pub/FreeBSD"><newline>
|
||||
Contact: <url url="mailto:ftp-admin@HK.Super.NET"
|
||||
name="ftp-admin@HK.Super.NET">.
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-ie">Ireland</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@ie.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.ie.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.ie.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-il">Israel</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@il.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.il.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.il.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.il.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.il.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-jp">Japan</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@jp.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.jp.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.jp.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.jp.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.jp.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.jp.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp3.jp.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp4.jp.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp4.jp.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp5.jp.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp5.jp.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp6.jp.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp6.jp.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-kr">Korea</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@kr.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.kr.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.kr.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.kr.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.kr.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-nl">Netherlands</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@nl.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.nl.freebsd.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.nl.freebsd.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-pl">Poland</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@pl.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.pl.freebsd.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.pl.freebsd.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-pt">Portugal</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@pt.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.pt.freebsd.org/pub/FreeBSD"
|
||||
name="ftp://ftp.pt.freebsd.org/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.pt.freebsd.org/pub/FreeBSD"
|
||||
name="ftp://ftp2.pt.freebsd.org/pub/FreeBSD"><newline>
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-ru">Russia</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@ru.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.ru.freebsd.org/pub/FreeBSD"
|
||||
name="ftp://ftp.ru.freebsd.org/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.ru.freebsd.org/pub/FreeBSD"
|
||||
name="ftp://ftp2.ru.freebsd.org/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.ru.freebsd.org/pub/FreeBSD"
|
||||
name="ftp://ftp3.ru.freebsd.org/pub/FreeBSD"><newline>
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-za">South Africa</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@za.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.za.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.za.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.za.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.za.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.za.FreeBSD.ORG/FreeBSD"
|
||||
name="ftp://ftp3.za.FreeBSD.ORG/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-se">Sweden</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@se.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.se.freebsd.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.se.freebsd.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-tw">Taiwan</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@tw.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.tw.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.tw.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.tw.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.tw.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.tw.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp3.tw.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-th">Thailand</tag>
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.nectec.or.th/pub/FreeBSD"
|
||||
name="ftp://ftp.nectec.or.th/pub/FreeBSD"><newline>
|
||||
Contact: <url url="mailto:ftpadmin@ftp.nectec.or.th"
|
||||
name="ftpadmin@ftp.nectec.or.th">.
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-us">USA</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp3.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp4.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp4.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp5.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp5.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp6.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp6.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag><label id="mirrors-uk">UK</tag>
|
||||
|
||||
In case of problems, please contact the
|
||||
<url url="mailto:hostmaster@uk.FreeBSD.ORG" name="hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.uk.FreeBSD.ORG/packages/unix/FreeBSD"
|
||||
name="ftp://ftp.uk.FreeBSD.ORG/packages/unix/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp2.uk.FreeBSD.ORG/pub/walnut.creek/FreeBSD"
|
||||
name="ftp://ftp2.uk.FreeBSD.ORG/pub/walnut.creek/FreeBSD"><newline>
|
||||
<item>
|
||||
<url url="ftp://ftp3.uk.FreeBSD.ORG/pub/unix/FreeBSD"
|
||||
name="ftp://ftp3.uk.FreeBSD.ORG/pub/unix/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
</descrip>
|
||||
|
||||
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:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag>South Africa</tag>
|
||||
|
||||
<url url="mailto:hostmaster@internat.FreeBSD.ORG" name="Hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.internat.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.internat.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp2.internat.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp2.internat.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag>Brazil</tag>
|
||||
|
||||
<url url="mailto:hostmaster@br.FreeBSD.ORG" name="Hostmaster">
|
||||
for this domain.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://ftp.br.FreeBSD.ORG/pub/FreeBSD"
|
||||
name="ftp://ftp.br.FreeBSD.ORG/pub/FreeBSD"><newline>
|
||||
|
||||
</itemize>
|
||||
|
||||
<tag>Finland</tag>
|
||||
|
||||
<itemize>
|
||||
|
||||
<item>
|
||||
<url url="ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt"
|
||||
name="ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt"><newline>
|
||||
Contact: <url url="mailto:count@nic.funet.fi"
|
||||
name="count@nic.funet.fi">.
|
||||
|
||||
</itemize>
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect><heading>CTM Sites<label id="mirrors-ctm"></heading>
|
||||
|
||||
<p><ref id="ctm" name="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 &a.phk;.
|
||||
|
||||
<descrip>
|
||||
<tag>California, Bay Area, official source</tag>
|
||||
<itemize>
|
||||
<item>
|
||||
<url url="ftp://freefall.freebsd.org/pub/CTM"
|
||||
name="ftp://freefall.freebsd.org/pub/CTM"><newline>
|
||||
</itemize>
|
||||
|
||||
|
||||
<tag>Germany, Berlin</tag>
|
||||
<itemize>
|
||||
<item>
|
||||
<url url="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CTM"
|
||||
name="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CTM"><newline>
|
||||
</itemize>
|
||||
|
||||
|
||||
<tag>Germany, Trier</tag>
|
||||
<itemize>
|
||||
<item>
|
||||
<url url="ftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTM"
|
||||
name="ftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTM"><newline>
|
||||
</itemize>
|
||||
|
||||
|
||||
<tag>South Africa, backup server for old deltas</tag>
|
||||
<itemize>
|
||||
<item>
|
||||
<url url="ftp://ftp.internat.freebsd.org/pub/FreeBSD/CTM"
|
||||
name="ftp://ftp.internat.freebsd.org/pub/FreeBSD/CTM"><newline>
|
||||
</itemize>
|
||||
|
||||
|
||||
<tag>Taiwan/R.O.C, Chiayi</tag>
|
||||
<itemize>
|
||||
<item>
|
||||
<url url="ftp://ftp.ccu.edu.tw/pub/freebsd/CTM"
|
||||
name="ftp://ftp.ccu.edu.tw/pub/freebsd/CTM"><newline>
|
||||
</itemize>
|
||||
|
||||
</descrip>
|
||||
|
||||
|
||||
If you did not find a mirror near to you or the mirror is incomplete,
|
||||
try
|
||||
<url url="http://ftpsearch.ntnu.no/" name="FTP search"> at
|
||||
<url url="http://ftpsearch.ntnu.no/ftpsearch/"
|
||||
name="http://ftpsearch.ntnu.no/ftpsearch">.
|
||||
FTP search is a great free archie server in Trondheim, Norway.
|
||||
|
||||
<sect><heading>CVSup Sites<label id="mirrors-cvsup"></heading>
|
||||
|
||||
<p><ref id="cvsup" name="CVSup"> servers for FreeBSD are running at
|
||||
the following sites:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag>Argentina</tag>
|
||||
<itemize>
|
||||
<item>cvsup.ar.FreeBSD.ORG
|
||||
(<url url="mailto:msagre@cactus.fi.uba.ar" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
<tag>Australia</tag>
|
||||
<itemize>
|
||||
<item>cvsup.au.FreeBSD.ORG
|
||||
(<url url="mailto:dawes@physics.usyd.edu.au" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
<tag>Germany</tag>
|
||||
<itemize>
|
||||
<item>cvsup.de.FreeBSD.ORG
|
||||
(<url url="mailto:wosch@cs.tu-berlin.de" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
<tag>Japan</tag>
|
||||
<itemize>
|
||||
<item>cvsup.jp.FreeBSD.ORG
|
||||
(<url url="mailto:simokawa@sat.t.u-tokyo.ac.jp" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
<tag>Netherlands</tag>
|
||||
<itemize>
|
||||
<item>cvsup.nl.FreeBSD.ORG
|
||||
(<url url="mailto:xaa@stack.nl" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
<tag>Norway</tag>
|
||||
<itemize>
|
||||
<item>cvsup.no.FreeBSD.ORG
|
||||
(<url url="mailto:Tor.Egge@idt.ntnu.no" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
<tag>South Africa</tag>
|
||||
<itemize>
|
||||
<item>cvsup.za.FreeBSD.ORG
|
||||
(<url url="mailto:markm@FreeBSD.ORG" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
<tag>Taiwan</tag>
|
||||
<itemize>
|
||||
<item>sup.tw.FreeBSD.ORG
|
||||
(<url url="mailto:jdli@freebsd.csie.nctu.edu.tw" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
<tag>USA</tag>
|
||||
<itemize>
|
||||
<item>cvsup.FreeBSD.ORG
|
||||
(<url url="mailto:jdp@FreeBSD.ORG" name="maintainer">)
|
||||
<item>cvsup2.FreeBSD.ORG
|
||||
(<url url="mailto:jdp@FreeBSD.ORG" name="maintainer">)
|
||||
<item>cvsup4.FreeBSD.ORG
|
||||
(<url url="mailto:jdp@FreeBSD.ORG" name="maintainer">)
|
||||
<item>cvsup5.FreeBSD.ORG
|
||||
(<url url="mailto:skynyrd@opus.cts.cwu.edu" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
</descrip>
|
||||
|
||||
The export-restricted code for FreeBSD (eBones and secure) is
|
||||
available via CVSup at the following international repository.
|
||||
Please use this site to get the export-restricted code, if you are
|
||||
outside the USA or Canada.
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag>South Africa</tag>
|
||||
<itemize>
|
||||
<item>cvsup.internat.FreeBSD.ORG
|
||||
(<url url="mailto:markm@FreeBSD.ORG" name="maintainer">)
|
||||
</itemize>
|
||||
|
||||
</descrip>
|
||||
@ -1,86 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>NFS<label id="nfs"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jlind;.</em>
|
||||
|
||||
Certain Ethernet adapters for ISA PC systems have limitations which
|
||||
can lead to serious network problems, particularly with NFS. This
|
||||
difficulty is not specific to FreeBSD, but FreeBSD systems are affected
|
||||
by it.
|
||||
|
||||
The problem nearly always occurs when (FreeBSD) PC systems are networked
|
||||
with high-performance workstations, such as those made by Silicon Graphics,
|
||||
Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some
|
||||
operations may succeed, but suddenly the server will seem to become
|
||||
unresponsive to the client, even though requests to and from other systems
|
||||
continue to be processed. This happens to the client system, whether the
|
||||
client is the FreeBSD system or the workstation. On many systems, there is
|
||||
no way to shut down the client gracefully once this problem has manifested
|
||||
itself. The only solution is often to reset the client, because the NFS
|
||||
situation cannot be resolved.
|
||||
|
||||
Though the "correct" solution is to get a higher performance and capacity
|
||||
Ethernet adapter for the FreeBSD system, there is a simple workaround that
|
||||
will allow satisfactory operation. If the FreeBSD system is the SERVER,
|
||||
include the option "-w=1024" on the mount from the client. If the
|
||||
FreeBSD system is the CLIENT, then mount the NFS file system with the
|
||||
option "-r=1024". These options may be specified using the fourth
|
||||
field of the fstab entry on the client for automatic mounts, or by using
|
||||
the "-o" parameter of the mount command for manual mounts.
|
||||
|
||||
It should be noted that there is a different problem,
|
||||
sometimes mistaken for this one,
|
||||
when the NFS servers and clients are on different networks.
|
||||
If that is the case, make CERTAIN that your routers are routing the
|
||||
necessary UDP information, or you will not get anywhere, no matter
|
||||
what else you are doing.
|
||||
|
||||
In the following examples, "fastws" is the host (interface) name of a
|
||||
high-performance workstation, and "freebox" is the host (interface) name of
|
||||
a FreeBSD system with a lower-performance Ethernet adapter. Also,
|
||||
"/sharedfs" will be the exported NFS filesystem (see "man exports"), and
|
||||
"/project" will be the mount point on the client for the exported file
|
||||
system. In all cases, note that additional options, such as "hard" or
|
||||
"soft" and "bg" may be desirable in your application.
|
||||
|
||||
Examples for the FreeBSD system ("freebox") as the client:
|
||||
in <tt>/etc/fstab</tt> on freebox:
|
||||
fastws:/sharedfs /project nfs rw,-r=1024 0 0
|
||||
as a manual mount command on freebox:
|
||||
mount -t nfs -o -r=1024 fastws:/sharedfs /project
|
||||
|
||||
Examples for the FreeBSD system as the server:
|
||||
in <tt>/etc/fstab</tt> on fastws:
|
||||
freebox:/sharedfs /project nfs rw,-w=1024 0 0
|
||||
as a manual mount command on fastws:
|
||||
mount -t nfs -o -w=1024 freebox:/sharedfs /project
|
||||
|
||||
Nearly any 16-bit Ethernet adapter will allow operation without the above
|
||||
restrictions on the read or write size.
|
||||
|
||||
For anyone who cares, here is what happens when the failure occurs, which
|
||||
also explains why it is unrecoverable. NFS typically works with a "block"
|
||||
size of 8k (though it may do fragments of smaller sizes). Since the maximum
|
||||
Ethernet packet is around 1500 bytes, the NFS "block" gets split into
|
||||
multiple Ethernet packets, even though it is still a single unit to the
|
||||
upper-level code, and must be received, assembled, and ACKNOWLEDGED as a
|
||||
unit. The high-performance workstations can pump out the packets which
|
||||
comprise the NFS unit one right after the other, just as close together as
|
||||
the standard allows. On the smaller, lower capacity cards, the later
|
||||
packets overrun the earlier packets of the same unit before they can be
|
||||
transferred to the host and the unit as a whole cannot be reconstructed or
|
||||
acknowledged. As a result, the workstation will time out and try again,
|
||||
but it will try again with the entire 8K unit, and the process will be
|
||||
repeated, ad infinitum.
|
||||
|
||||
By keeping the unit size below the Ethernet packet size limitation, we
|
||||
ensure that any complete Ethernet packet received can be acknowledged
|
||||
individually, avoiding the deadlock situation.
|
||||
|
||||
Overruns may still occur when a high-performance workstations is slamming
|
||||
data out to a PC system, but with the better cards, such overruns are
|
||||
not guaranteed on NFS "units". When an overrun occurs, the units affected
|
||||
will be retransmitted, and there will be a fair chance that they will be
|
||||
received, assembled, and acknowledged.
|
||||
@ -1,151 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>FreeBSD in a nutshell<label id="nutshell"></heading>
|
||||
|
||||
<p>FreeBSD is a state of the art operating system for
|
||||
personal computers based on the Intel CPU architecture, which
|
||||
includes the 386, 486 and Pentium processors (both SX and DX versions).
|
||||
Intel compatible CPUs from AMD and Cyrix are supported as well.
|
||||
FreeBSD provides you with many advanced features previously available
|
||||
only on much more expensive computers. These features include:
|
||||
|
||||
<itemize>
|
||||
<item><bf>Preemptive multitasking</bf> with dynamic priority
|
||||
adjustment to ensure smooth and fair sharing of the
|
||||
computer between applications and users.</item>
|
||||
<item><bf>Multiuser</bf> access means that many people can use a
|
||||
FreeBSD system simultaneously for a variety of things. System
|
||||
peripherals such as printers and tape drives are also properly
|
||||
SHARED BETWEEN ALL users on the system.</item>
|
||||
<item>Complete <bf>TCP/IP networking</bf> including SLIP, PPP, NFS
|
||||
and NIS support. This means that your FreeBSD machine can
|
||||
inter-operate easily with other systems as well act as an enterprise
|
||||
server, providing vital functions such as NFS (remote file access) and
|
||||
e-mail services or putting your organization on the Internet
|
||||
with WWW, ftp, routing and firewall (security) services.</item>
|
||||
<item><bf>Memory protection</bf> ensures that applications (or
|
||||
users) cannot interfere with each other. One application
|
||||
crashing will not affect others in any way.</item>
|
||||
<item>FreeBSD is a <bf>32-bit</bf> operating system and was designed
|
||||
as such from the ground up.</item>
|
||||
<item>The industry standard <bf>X Window System</bf> (X11R6)
|
||||
provides a graphical user interface (GUI) for the cost of a
|
||||
common VGA card and monitor and comes with full sources.</item>
|
||||
<item><bf>Binary compatibility</bf> with many programs built for SCO,
|
||||
BSDI, NetBSD, Linux and 386BSD.</item>
|
||||
<item>Hundreds of <bf>ready-to-run</bf> applications are
|
||||
available from the
|
||||
FreeBSD <bf>ports</bf> and <bf>packages</bf>
|
||||
collection. Why search the net when you can find it all
|
||||
right here?</item>
|
||||
<item>Thousands of additional and <bf>easy-to-port</bf> applications
|
||||
available on the Internet. FreeBSD is source code compatible
|
||||
with most popular commercial Unix systems and thus most
|
||||
applications require few, if any, changes to compile.</item>
|
||||
<item>Demand paged <bf>virtual memory</bf> and `merged VM/buffer cache'
|
||||
design efficiently satisfies applications with large appetites
|
||||
for memory while still maintaining interactive response to other
|
||||
users.</item>
|
||||
<item><bf>Shared libraries</bf> (the Unix equivalent of
|
||||
MS-Windows DLLs) provide for efficient use of disk space
|
||||
and memory.</item>
|
||||
<item>A full compliment of <bf>C</bf>, <bf>C++</bf> and
|
||||
<bf>Fortran</bf> development tools. Many additional
|
||||
languages for advanced research and development are
|
||||
also available in the ports and packages collection.</item>
|
||||
<item><bf>Source code</bf> for the entire system means you have
|
||||
the greatest degree of control over your environment. Why be
|
||||
locked into a proprietary solution and at the mercy of your vendor
|
||||
when you can have a truly Open System?</item>
|
||||
<item>Extensive <bf>on-line documentation</bf>.</item>
|
||||
<item><bf>And many more!</bf></item>
|
||||
</itemize>
|
||||
|
||||
FreeBSD is based on the 4.4BSD-Lite release from Computer
|
||||
Systems Research Group (CSRG) at the University of
|
||||
California at Berkeley, and carries on the distinguished
|
||||
tradition of BSD systems development. In addition to the
|
||||
fine work provided by CSRG, the FreeBSD Project has put in
|
||||
many thousands of hours in fine tuning the system for
|
||||
maximum performance and reliability in real-life load
|
||||
situations. As many of the commercial giants struggle to
|
||||
field PC operating systems with such features, performance
|
||||
and reliability, FreeBSD can offer them <bf>now</bf>!
|
||||
|
||||
The applications to which FreeBSD can be put are truly
|
||||
limited only by your own imagination. From software
|
||||
development to factory automation, inventory control to
|
||||
azimuth correction of remote satellite antennae; if it can
|
||||
be done with a commercial UNIX product then it is more than
|
||||
likely that you can do it with FreeBSD, too! FreeBSD also
|
||||
benefits significantly from the literally thousands of high
|
||||
quality applications developed by research centers and
|
||||
universities around the world, often available at little
|
||||
to no cost. Commercial applications are also available
|
||||
and appearing in greater numbers every day.
|
||||
|
||||
Because the source code for FreeBSD itself is generally
|
||||
available, the system can also be customized to an almost
|
||||
unheard of degree for special applications or projects, and
|
||||
in ways not generally possible with operating systems from
|
||||
most major commercial vendors. Here is just a sampling of
|
||||
some of the applications in which people are currently
|
||||
using FreeBSD:
|
||||
|
||||
<itemize>
|
||||
<item><bf>Internet Services:</bf> The robust TCP/IP networking
|
||||
built into FreeBSD makes it an ideal platform for a
|
||||
variety of Internet services such as:
|
||||
<itemize>
|
||||
<item>FTP servers</item>
|
||||
<item>World Wide Web servers</item>
|
||||
<item>Gopher servers</item>
|
||||
<item>Electronic Mail servers</item>
|
||||
<item>USENET News</item>
|
||||
<item>Bulletin Board Systems</item>
|
||||
<item>And more...</item>
|
||||
</itemize>
|
||||
You can easily start out small with an inexpensive 386
|
||||
class PC and upgrade as your enterprise grows.</item>
|
||||
<item><bf>Education:</bf> Are you a student of computer science
|
||||
or a related engineering field? There is no better way
|
||||
of learning about operating systems, computer
|
||||
architecture and networking than the hands on, under the
|
||||
hood experience that FreeBSD can provide. A number of
|
||||
freely available CAD, mathematical and graphic design
|
||||
packages also make it highly useful to those who's
|
||||
primary interest in a computer is to get <em>other</em>
|
||||
work done!</item>
|
||||
<item><bf>Research:</bf> With source code for the entire system
|
||||
available, FreeBSD is an excellent platform for research
|
||||
in operating systems as well as other branches of
|
||||
computer science. FreeBSD's freely available nature also
|
||||
makes it possible for remote groups to collaborate on
|
||||
ideas or shared development without having to worry about
|
||||
special licensing agreements or limitations on what
|
||||
may be discussed in open forums.</item>
|
||||
<item><bf>Networking:</bf> Need a new router? A name server
|
||||
(DNS)? A firewall to keep people out of your internal
|
||||
network? FreeBSD can easily turn that unused 386 or 486 PC
|
||||
sitting in the corner into an advanced router with
|
||||
sophisticated packet filtering capabilities. </item>
|
||||
<item><bf>X Window workstation:</bf> FreeBSD is a fine
|
||||
choice for an inexpensive X terminal solution, either
|
||||
using the freely available XFree86 server or one
|
||||
of the excellent commercial servers provided by X Inside.
|
||||
Unlike an X
|
||||
terminal, FreeBSD allows many applications to be run
|
||||
locally, if desired, thus relieving the burden on a
|
||||
central server. FreeBSD can even boot
|
||||
"diskless", making individual workstations even cheaper
|
||||
and easier to administer.</item>
|
||||
<item><bf>Software Development:</bf> The basic FreeBSD system
|
||||
comes with a full compliment of development tools
|
||||
including the renowned GNU C/C++ compiler and
|
||||
debugger. </item>
|
||||
</itemize>
|
||||
|
||||
FreeBSD is available in both source and binary form on CDROM and
|
||||
via anonymous ftp. See <ref id="mirrors" name="Obtaining FreeBSD">
|
||||
for more details.
|
||||
@ -1,364 +0,0 @@
|
||||
<!-- $Id: pgpkeys.sgml,v 1.19 1997/04/25 22:54:33 ache Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>PGP keys<label id="pgpkeys"></heading>
|
||||
<p> In case you need to verify a signature or send encrypted
|
||||
email to one of the officers or core team members a
|
||||
number of keys are provided here for your convenience.
|
||||
<sect><heading>Officers</heading>
|
||||
<sect1><heading>
|
||||
FreeBSD Security Officer <security-officer@freebsd.org>
|
||||
</heading> <p>
|
||||
<tscreen><verb>
|
||||
FreeBSD Security Officer <security-officer@freebsd.org>
|
||||
Fingerprint = 41 08 4E BB DB 41 60 71 F9 E5 0E 98 73 AF 3F 11
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.3i
|
||||
|
||||
mQCNAzF7MY4AAAEEAK7qBgPuBejER5HQbQlsOldk3ZVWXlRj54raz3IbuAUrDrQL
|
||||
h3g57T9QY++f3Mot2LAf5lDJbsMfWrtwPrPwCCFRYQd6XH778a+l4ju5axyjrt/L
|
||||
Ciw9RrOC+WaPv3lIdLuqYge2QRC1LvKACIPNbIcgbnLeRGLovFUuHi5z0oilAAUR
|
||||
tDdGcmVlQlNEIFNlY3VyaXR5IE9mZmljZXIgPHNlY3VyaXR5LW9mZmljZXJAZnJl
|
||||
ZWJzZC5vcmc+iQCVAwUQMX6yrOJgpPLZnQjrAQHyowQA1Nv2AY8vJIrdp2ttV6RU
|
||||
tZBYnI7gTO3sFC2bhIHsCvfVU3JphfqWQ7AnTXcD2yPjGcchUfc/EcL1tSlqW4y7
|
||||
PMP4GHZp9vHog1NAsgLC9Y1P/1cOeuhZ0pDpZZ5zxTo6TQcCBjQA6KhiBFP4TJql
|
||||
3olFfPBh3B/Tu3dqmEbSWpuJAJUDBRAxez3C9RVb+45ULV0BAak8A/9JIG/jRJaz
|
||||
QbKom6wMw852C/Z0qBLJy7KdN30099zMjQYeC9PnlkZ0USjQ4TSpC8UerYv6IfhV
|
||||
nNY6gyF2Hx4CbEFlopnfA1c4yxtXKti1kSN6wBy/ki3SmqtfDhPQ4Q31p63cSe5A
|
||||
3aoHcjvWuqPLpW4ba2uHVKGP3g7SSt6AOYkAlQMFEDF8mz0ff6kIA1j8vQEBmZcD
|
||||
/REaUPDRx6qr1XRQlMs6pfgNKEwnKmcUzQLCvKBnYYGmD5ydPLxCPSFnPcPthaUb
|
||||
5zVgMTjfjS2fkEiRrua4duGRgqN4xY7VRAsIQeMSITBOZeBZZf2oa9Ntidr5PumS
|
||||
9uQ9bvdfWMpsemk2MaRG9BSoy5Wvy8VxROYYUwpT8Cf2iQCVAwUQMXsyqWtaZ42B
|
||||
sqd5AQHKjAQAvolI30Nyu3IyTfNeCb/DvOe9tlOn/o+VUDNJiE/PuBe1s2Y94a/P
|
||||
BfcohpKC2kza3NiW6lLTp00OWQsuu0QAPc02vYOyseZWy4y3Phnw60pWzLcFdemT
|
||||
0GiYS5Xm1o9nAhPFciybn9j1q8UadIlIq0wbqWgdInBT8YI/l4f5sf6JAJUDBRAx
|
||||
ezKXVS4eLnPSiKUBAc5OBACIXTlKqQC3B53qt7bNMV46m81fuw1PhKaJEI033mCD
|
||||
ovzyEFFQeOyRXeu25Jg9Bq0Sn37ynISucHSmt2tUD5W0+p1MUGyTqnfqejMUWBzO
|
||||
v4Xhp6a8RtDdUMBOTtro16iulGiRrCKxzVgEl4i+9Z0ZiE6BWlg5AetoF5n3mGk1
|
||||
lw==
|
||||
=ipyA
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect><heading>Core team members</heading>
|
||||
<sect1><heading>&a.jkh</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
Jordan K. Hubbard <jkh@FreeBSD.org>
|
||||
Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2i
|
||||
|
||||
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
|
||||
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
|
||||
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
|
||||
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokAlQMFEDF75D1r
|
||||
WmeNgbKneQEBXtcD+gJIv8JzZRKlDZyTCQanK8iRgE+zMhxptI0kDObaGxT1BrpY
|
||||
4/EPyiUN10G4k2Jb+DOc8Lg2xDQ3xmvgipFf9NMNV/ThaEuZ3wA31I6tW/arQEqB
|
||||
Tp8u6T3v20m62t7Afo9HaoE6MBpHQUk2TilxgAd5P57sporL3pgW9YojIO9ziQCV
|
||||
AwUQMXyV2h9/qQgDWPy9AQEMfgP/RmbSg2WlesATUQ4WuanjcdREduKPyfQatrXD
|
||||
2xt+jg9X78dTyiNN1YvLqvT6msfs04MKSC0hA2mou6ozw8Xak+1QmP0fBOZKp9pP
|
||||
8szO188Do9ByzJPvHF1eXT7jFMOXVq8ZIl9iwjxcIDLzlxOz49DC7LO6AT+LKQk7
|
||||
UGeP+lqJAJUDBRAxe+UG9RVb+45ULV0BAXZ9A/9F9gLpGukVNkeOjaqxQdJGTS+a
|
||||
xh/Abk0c/nKhAEyxpAl5JyQ3ifYk6BHhPvlTi9LrZoXGA8sk/eU4eRTZVzvGEC4G
|
||||
+xsavlE/xzku8855QTLPpkCunUpQeu1wzaIrUUE6Zjh05imFbJYyQOBgTFpuqWsC
|
||||
rsUpl+2mr8IGIxG5rA==
|
||||
=LW9i
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>&a.phk</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
Poul-Henning Kamp <phk@FreeBSD.org>
|
||||
Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.3ia
|
||||
|
||||
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI
|
||||
ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA
|
||||
K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR
|
||||
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDMGK9qz
|
||||
WmLrWZ8yPQEB4iED/18bQVhV2gUYFSxIUTaUtO2HVPi7GRpSzmXoTfS+FJyRR0ED
|
||||
zTqTHstoBe2PeWgTsOf9cUub5UKcJkRQp7VrJv4Kncyuq7pX69a+QMveCzuUwAur
|
||||
nDbt/emOL6NU8g9Uk50QuOuipb5rULQLRRoF5TkViy/VES83ERXdYQ9Ml3fWiQCV
|
||||
AwUQMX6NfWtaZ42Bsqd5AQEKsgP+L+uLz95dRdEmnZ+omrO+tYZM/0jHU7i8yC5q
|
||||
H0gguKOCljI4liR7NkqKONUJWYtfsTB81d9iSosBZRrTx6i/hB8l8kOB975n/f9S
|
||||
hftFwmjLYCNMFlDM4j0kySvMV20UZjAyv9BeE51VWlIZ5n/oeSuzul3Znow02tF/
|
||||
zVnInJiJAJUDBRAxfJXn9RVb+45ULV0BAXJ8A/9K6NT6VLZZC5q3g7bBk5DWuzBS
|
||||
3oK2Ebww6xzsD2R9edltoz1J3GPngK0CWpHh4kw5iTaRWoC2YJYRNG6icnGvlMAl
|
||||
1/urqQHJVhxATINm8oljDKsj1RBJ6VKBzNbCJIHTVpX0AJoqUQX2Idi8goFr0fAm
|
||||
7cD2CBb1JhoAdzEfO4kAlQMFEDFLHlwff6kIA1j8vQEBj5MD/1hA8hJdhpL7mvQj
|
||||
rTAIn6Ldr08Lr1lqTaKSBMdCL3suGlW0Sw/dIBgicPDhgxLahT3DVfGiIst32FSl
|
||||
xmWY7wine80X4TZkJ9Hiw3Mpqtjl92j6zHNq0ZZE+CceNubpEdYLDqokAIMPdWlo
|
||||
WPHZcPxCs5PKI5udseFYF2gQAjI2iQCVAwUQMTlDoO9huekR1Y7VAQGy+AP/Rzp+
|
||||
UGtJavbSiPx5EnXOXxkA/+ulXQgQG9vdkWwewkvxDNOzHW3KkUWCGtPtIMENznbF
|
||||
j3QlYB+USIaf1ogvlD5EdXGPDfTINpE8CX2WXzajfgYFpYETDzduwjoWDZfEN9zZ
|
||||
fQqQS62VgAReOIz3k9BL708z/+WUO0++RLGCmImJAJUDBRAw5q8kAPLZCeu7G0EB
|
||||
AT3bBACwo+r9TgbiSyyU5cZpq5KgGT1c7eUHXjtxKmtrXD1nFNJ6j7x2DM2XGe6B
|
||||
YOfDWbFq4UkEAyAeXviuuUP4enQu1v2g7JGXeuI8bRM519pLdPzDq/DnbA4rNStn
|
||||
/SkH7awMfNSplcFuE6rc5ezVkw17eOHzDrYmwsFavL9gxZEycg==
|
||||
=Q45T
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>&a.joerg</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>
|
||||
Key fingerprint = DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.3ia
|
||||
|
||||
mQCNAzGCFeAAAAEEAKmRBU2Nvc7nZy1Ouid61HunA/5hF4O91cXm71/KPaT7dskz
|
||||
q5sFXvPJPpawwvqHPHfEbAK42ZaywyFp59L1GaYj87Pda+PlAYRJyY2DJl5/7JPe
|
||||
ziq+7B8MdvbX6D526sdmcR+jPXPbHznASjkx9DPmK+7TgFujyXW7bjh2o/exAAUR
|
||||
tC1Kb2VyZyBXdW5zY2ggPGpvZXJnX3d1bnNjaEB1cmlhaC5oZWVwLnNheC5kZT6J
|
||||
AJUDBRAyCIWZdbtuOHaj97EBAVMzA/41VIph36l+yO9WGKkEB+NYbYOz2W/kyi74
|
||||
kXLvLdTXcRYFaCSZORSsQKPGNMrPZUoLoAKxE25AoCgl5towqr/sCcu0A0MMvJdd
|
||||
UvlQ2T+ylSpGmWchqoXCN7FdGyxrZ5zzxzLIvtcio6kaHd76XxyJpltCASupdD53
|
||||
nEtxnu8sRrQxSm9lcmcgV3Vuc2NoIDxqb2VyZ193dW5zY2hAaW50ZXJmYWNlLWJ1
|
||||
c2luZXNzLmRlPokAlQMFEDIIhfR1u244dqP3sQEBWoID/RhBm+qtW+hu2fqAj9d8
|
||||
CVgEKJugrxZIpXuCKFvO+bCgQtogt9EX+TJh4s8UUdcFkyEIu8CT2C3Rrr1grvck
|
||||
fxvrTgzSzvtYyv1072X3GkVY+SlUMBMArdl1qNW23oT7Q558ajnsaL065XJ5m7Ha
|
||||
cgTTikiofYG8i1s7TrsEeq6PtCJKb2VyZyBXdW5zY2ggPGpAdXJpYWguaGVlcC5z
|
||||
YXguZGU+iQCVAwUQMaS91D4gHQUlG9CZAQGYOwQAhPpiobK3d/fz+jWrbQgjkoO+
|
||||
j39glYGXb22+6iuEprFRs/ufKYtjljNTNK3B4DWSkyIPawcuO4Lotijp6jke2bsj
|
||||
FSSashGWcsJlpnwsv7EeFItT3oWTTTQQItPbtNyLW6M6xB+jLGtaAvJqfOlzgO9B
|
||||
LfHuA2LY+WvbVW447SWJAJUDBRAxqWRsdbtuOHaj97EBAXDBA/49rzZB5akkTSbt
|
||||
/gNd38OJgC+H8N5da25vV9dD3KoAvXfWfw7OxIsxvQ/Ab+rJmukrrWxPdsC+1WU1
|
||||
+1rGa4PvJp/VJRDes2awGrn+iO7/cQoSIVziC27JpcbvjLvLVcBIiy1yT/RvJ+87
|
||||
a3jPRHt3VFGcpFh4KykxxSNiyGygl4kAlQMFEDGCUB31FVv7jlQtXQEB5KgD/iIJ
|
||||
Ze5lFkPr2B/Cr7BKMVBot1/JSu05NsHgJZ3uK15w4mVtNPZcFi/dKbn+qRM6LKDF
|
||||
e/GF0HZD/ZD1FJt8yQjzF2w340B+F2GGEOwnClqZDtEAqnIBzM/ECQQqH+6Bi8gp
|
||||
kFZrFgg5eON7ikqmusDnOlYStM/CBfgpSbR8kDmFtCZKb2VyZyBXdW5zY2ggPGpA
|
||||
aW50ZXJmYWNlLWJ1c2luZXNzLmRlPokAlQMFEDMF5M3HZvEPv7z0SQEBAOEEAIDT
|
||||
V9RxYF6zHrQ2/sOshBkA5CQgwGPW+pgNhzXii0AIbKGZeB8ANforkGgoKN5chQvt
|
||||
Un9PezlE7O+M+V9bwnnalaBcPQsSN8bnLbd6SQm2zevH5TpZ6tFnWKLllhpRcC5Y
|
||||
eTxMv/1bcF/ZaoLIs5Yc4rfn1+gU+AYCouW2g4a1iQCVAwUQMgir3g/XgicV+IVJ
|
||||
AQHmzAP/ZkT8uiuou019kY1CkpdqeaGK1z5NdmbMOIo7pLbJcc0ITgsjEghitlBA
|
||||
uFDPTF6dR9SWUMTfw3H5zO1WlLflXtMGegwvYAUhydYSlcR3uV049upiK+K3Fzct
|
||||
lxAzCvULJwcSAGZwVU40ji3YaqkjKd1CyzqQZUS9kWK6otuyF6+JAJUDBRAxqW53
|
||||
dbtuOHaj97EBASZ0A/0VUgM4H+LqK7936W6LCNCxNy1LnwGBgUiTSZ7JHisrnWZD
|
||||
ZCOcxhg8FZ3h/3EpCk+DkaKHqnEwcSnjGjLlz1Zd9EGoYDcFo37k75eTmfKK7EBh
|
||||
liJ+RYamF7CpIxBsSDgTn775VUNFG3EdDdvuRejG+Rqq12aSHrJ+4xSaZECj1A==
|
||||
=ItLi
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>&a.ache</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
Andrey A. Chernov <ache@FreeBSD.org>
|
||||
aka <ache@nagual.pp.ru>
|
||||
Key fingerprint = 33 03 9F 48 33 7B 4A 15 63 48 88 0A C4 97 FD 49
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.3ia
|
||||
|
||||
mQCNAiqUMGQAAAEEAPGhcD6A2Buey5LYz0sphDLpVgOZc/bb9UHAbaGKUAGXmafs
|
||||
Dcb2HnsuYGgX/zrQXuCi/wIGtXcZWB97APtKOhFsZnPinDR5n/dde/mw9FnuhwqD
|
||||
m+rKSL1HlN0z/Msa5y7g16760wHhSR6NoBSEG5wQAHIMMq7Q0uJgpPLZnQjrAAUT
|
||||
tCVBbmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucHAucnU+iQCVAwUQM2Ez
|
||||
u+JgpPLZnQjrAQEyugP8DPnS8ixJ5OeuYgPFQf5sy6l+LrB6hyaS+lgsUPahWjNY
|
||||
cnaDmfda/q/BV5d4+y5rlQe/pjnYG7/yQuAR3jhlXz8XDrqlBOnW9AtYjDt5rMfJ
|
||||
aGFTGXAPGZ6k6zQZE0/YurT8ia3qjvuZm3Fw4NJrHRx7ETHRvVJDvxA6Ggsvmr20
|
||||
IkFuZHJleSBBLiBDaGVybm92IDxhY2hlQG5hZ3VhbC5ydT6JAJUDBRAxybkd4mCk
|
||||
8tmdCOsBAfC9A/0Z2YB/WB1y5rIcSA2RzXWZpw8fXVzBaNiPMDZih5wUwZXuKoor
|
||||
xBiuvUyNsZd/wMAbxRt+bRBsjwuPyIbc2Coiu7RzvZS4cZKf8A98YYbQC09flQr+
|
||||
TsGAjQJramjo0DmetKny0Ox0TP/iDJ5rzhFeXamu1N/kmPTuF+VtGy0ZcrQyQW5k
|
||||
cmV5IEEuIENoZXJub3YsIEJsYWNrIE1hZ2UgPGFjaGVAYXN0cmFsLm1zay5zdT6J
|
||||
AJUDBRAwKwCjn+savKgvyHcBAerVBACJ3I0WoD2G+uYxyOljtywlUWUa+PnvhaPg
|
||||
Y9qjell65BowGaxappctidZT8CV1vqRPPr6dFxBfnTMUfRMdI98CnARbvLJtJMjl
|
||||
qkmZZPeqEo3a+Ys2DbI3OGotPMcsPWUfeLWl9CrxZ6+s1+MtRyjlL9W56ROZr+iy
|
||||
fMILDt9DMIkAlQMFEDAq/ChrWmeNgbKneQEBGKEEAKhevep8brmEULIokhKaM69q
|
||||
gatqfFQiR4NLTJB1MfOFD53AHU6GErXkTQ3CvQwpqMsyb3Sfr5l1vnL8UiOk+uK7
|
||||
x0iuUetZmV7Brzx4QMz5D83FPWJiD4dooMATXvWOYulKkIvQyIm07SLfovd6RUPs
|
||||
e/y9985kc9IeKsjMk5lNiQCVAwUQMBq7rMUtR20Nv5BtAQFBfwP8DHCRh4VpjFlg
|
||||
wU4Mci9KTbeECyMKZQDZSKXUV5YC6xv6jzFF88NztOeiysiJ8mpsXn59wcIblVJM
|
||||
aWEGF3XxhZR5pt/+H07YGxBfnnJZG4HbHd2InXEj9VV0b6vGUwKYThlHVOX3H4y2
|
||||
6f0qopWkHf1WWQIFhDeGWA239MlRjiuJAJUDBRAwEcybIlGW2WZtAFEBAVCTA/9g
|
||||
LdqGzdkwyiuI6W3dnEY1RQ9MXusgRHeP5zuaoYbjp0ScMHmxSuTNpymgtfmyPW0Z
|
||||
Hdu/P1ri+aTUC/coU02+tlnf8FkUamreYJOIAL3OzI1hDwvQB8YhQ7mCgIiOrA5M
|
||||
1AgA6k2wnlL6cwCRAHhiaY2UjoZNvcPXzN+E9nq5yIkAlQIFEDAPSyXi5bvh+14V
|
||||
GQEBawAD/01ioFEEpuaW1AOnIrj6MEBiORcEmYBEVcolhOWdOA4cylmqhXJb3rGd
|
||||
prkzPESK7tlabmgvXRAMinWSuQE/Ypya99IwwdvloYIJBzb8/w2V9cC4e00bNiIj
|
||||
RQAjCLyKH9LWWJV++eoX25Xd3eSgTtWxD04DhCjRkvaCBb7+ARpgiQCVAwUQMA7P
|
||||
qrH8jId7euXhAQEi9gP+Mivxeqj/YjmCdyCFJ4VHTWfS8QsUi9oXhweh8bPLMGli
|
||||
x8D7qmAUjUgz4tQXeRtSQBj/a5J/1TkQJxowJNYLBWAlU76gbTvlIcQzhu6GvO61
|
||||
mIzV1PJNp6lo+lPJExRTH1kwxgmzuxuosh3V4PCsnFQ+GsE29//DZbaxgdJjxx2J
|
||||
AJUDBRAwDOqAdx2Srolyx8EBAZPHBAC2B4sWLauFI52WWkNdTDP5JLpsSMVNaBGx
|
||||
YUzL1Cc5yqvLDsvK4WZZ6KfiNqyNjTfcmw4N9ZA+I9U0DdQSddWD36fwC80w87wm
|
||||
RG8KfV42DRVonL0nfry4CuKj3dqB3Zh/9Hmv5AS4+MiyxWTyF1zL+W4SFKJdZ/ps
|
||||
sxUcQDQn44kAlQMFEDANSL7iYKTy2Z0I6wEBq0EEAIcH6q1bzzSx5EINkuOX9tPV
|
||||
vXjmmjrRTu7prc8QGRjQ0Dva1YNC5E8X8Kf/T5V0U3FBSyCStvBolY6iLQpCy+U6
|
||||
bdGuzEpuf268QovETHIofenGnvqS/P+URbAR4q8Er7zg9vWXOkbdbu7ZcN+LdVA9
|
||||
OLflJkwAdzoLQK3+aM2ViQCVAwUQMAys8PvCP42xMxQ5AQElyQP+KThaxnObao7H
|
||||
0XB6sartnByFz4mrVh43k/GnOpJ/gAbv7t0Uif6h7pfYVwjOBthj4h+aAkgcRWMM
|
||||
cfn64BfJvqXiIpzz15BrA7e3zyl8cslZtPOae+DPZwyvG33gdG+CQd+9ykYSBvKV
|
||||
2roQHfc66drMVx9kVEhxeTWx/IsO9gQ=
|
||||
=YGYK
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>&a.rich</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
Rich Murphey <rich@FreeBSD.org>
|
||||
fingerprint = AF A0 60 C4 84 D6 0C 73 D1 EF C0 E9 9D 21 DB E4
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2
|
||||
|
||||
mQCNAy97V+MAAAEEALiNM3FCwm3qrCe81E20UOSlNclOWfZHNAyOyj1ahHeINvo1
|
||||
FBF2Gd5Lbj0y8SLMno5yJ6P4F4r+x3jwHZrzAIwMs/lxDXRtB0VeVWnlj6a3Rezs
|
||||
wbfaTeSVyh5JohEcKdoYiMG5wjATOwK/NAwIPthB1RzRjnEeer3HI3ZYNEOpAAUR
|
||||
tCRSaWNoIE11cnBoZXkgPHJpY2hAbGFtcHJleS51dG1iLmVkdT6JAJUDBRAve15W
|
||||
vccjdlg0Q6kBAZTZBACcNd/LiVnMFURPrO4pVRn1sVQeokVX7izeWQ7siE31Iy7g
|
||||
Sb97WRLEYDi686osaGfsuKNA87Rm+q5F+jxeUV4w4szoqp60gGvCbD0KCB2hWraP
|
||||
/2s2qdVAxhfcoTin/Qp1ZWvXxFF7imGA/IjYIfB42VkaRYu6BwLEm3YAGfGcSw==
|
||||
=QoiM
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>&a.peter</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
Peter Wemm <peter@FreeBSD.org>
|
||||
aka <peter@spinner.dialix.com>
|
||||
aka <peter@haywire.dialix.com>
|
||||
aka <peter@perth.dialix.oz.au>
|
||||
Key fingerprint = 47 05 04 CA 4C EE F8 93 F6 DB 02 92 6D F5 58 8A
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.3ia
|
||||
|
||||
mQCNAy9/FJwAAAEEALxs9dE9tFd0Ru1TXdq301KfEoe5uYKKuldHRBOacG2Wny6/
|
||||
W3Ill57hOi2+xmq5X/mHkapywxvy4cyLdt31i4GEKDvxpDvEzAYcy2n9dIup/eg2
|
||||
kEhRBX9G5k/LKM4NQsRIieaIEGGgCZRm0lINqw495aZYrPpO4EqGN2HYnOMZAAUT
|
||||
tCVQZXRlciBXZW1tIDxwZXRlckBoYXl3aXJlLmRpYWxpeC5jb20+iQCVAwUQMwWT
|
||||
cXW7bjh2o/exAQEFkQP+LIx5zKlYp1uR24xGApMFNrNtjh+iDIWnxxb2M2Kb6x4G
|
||||
9z6OmbUCoDTGrX9SSL2Usm2RD0BZfyv9D9QRWC2TSOPkPRqQgIycc11vgbLolJJN
|
||||
eixqsxlFeKLGEx9eRQCCbo3dQIUjc2yaOe484QamhsK1nL5xpoNWI1P9zIOpDiGJ
|
||||
AJUDBRAxsRPqSoY3Ydic4xkBAbWLA/9q1Fdnnk4unpGQsG31Qbtr4AzaQD5m/JHI
|
||||
4gRmSmbj6luJMgNG3fpO06Gd/Z7uxyCJB8pTst2a8C/ljOYZxWT+5uSzkQXeMi5c
|
||||
YcI1sZbUpkHtmqPW623hr1PB3ZLA1TIcTbQW+NzJsxQ1Pc6XG9fGkT9WXQW3Xhet
|
||||
AP+juVTAhLQlUGV0ZXIgV2VtbSA8cGV0ZXJAcGVydGguZGlhbGl4Lm96LmF1PokA
|
||||
lQMFEDGxFCFKhjdh2JzjGQEB6XkD/2HOwfuFrnQUtdwFPUkgtEqNeSr64jQ3Maz8
|
||||
xgEtbaw/ym1PbhbCk311UWQq4+izZE2xktHTFClJfaMnxVIfboPyuiSF99KHiWnf
|
||||
/Gspet0S7m/+RXIwZi1qSqvAanxMiA7kKgFSCmchzas8TQcyyXHtn/gl9v0khJkb
|
||||
/fv3R20btB5QZXRlciBXZW1tIDxwZXRlckBGcmVlQlNELm9yZz6JAJUDBRAxsRJd
|
||||
SoY3Ydic4xkBAZJUA/4i/NWHz5LIH/R4IF/3V3LleFyMFr5EPFY0/4mcv2v+ju9g
|
||||
brOEM/xd4LlPrx1XqPeZ74JQ6K9mHR64RhKR7ZJJ9A+12yr5dVqihe911KyLKab9
|
||||
4qZUHYi36WQu2VtLGnw/t8Jg44fQSzbBF5q9iTzcfNOYhRkSD3BdDrC3llywO7Ql
|
||||
UGV0ZXIgV2VtbSA8cGV0ZXJAc3Bpbm5lci5kaWFsaXguY29tPokAlQMFEDGxEi1K
|
||||
hjdh2JzjGQEBdA4EAKmNFlj8RF9HQsoI3UabnvYqAWN5wCwEB4u+Zf8zq6OHic23
|
||||
TzoK1SPlmSdBE1dXXQGS6aiDkLT+xOdeewNs7nfUIcH/DBjSuklAOJzKliXPQW7E
|
||||
kuKNwy4eq5bl+j3HB27i+WBXhn6OaNNQY674LGaR41EGq44Wo5ATcIicig/z
|
||||
=gv+h
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>&a.jmb</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
Jonathan M. Bresler <jmb@FreeBSD.org>
|
||||
Key fingerprint = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2
|
||||
|
||||
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
|
||||
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
|
||||
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
|
||||
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQMqyL
|
||||
0LNaYutZnzI9AQF25QP9GFXhBrz2tiWz2+0gWbpcGNnyZbfsVjF6ojGDdmsjJMyW
|
||||
CGw49XR/vPKYIJY9EYo4t49GIajRkISQNNiIz22fBAjT2uY9YlvnTJ9NJleMfHr4
|
||||
dybo7oEKYMWWijQzGjqf2m8wf9OaaofEKwBX6nxcRbKsxm/BVLKczGYl3Xtjkcu0
|
||||
E0pvbmF0aGFuIE0uIEJyZXNsZXKJAJUDBRAxti1hAdtd0pfmON0BAcQfA/98RpCh
|
||||
OLvMoPVT/mRbZg8gFTIxOkuI71A6viy1iMm+EeHgSPB8a8wiFsWs8q3FI0fWzebi
|
||||
MBcpeJAEMLPXsgjMvifx2W6fE0YTkwdyyalbOCDIiDjNs+o85yDiAsURawSSvajR
|
||||
qTDMgZre1sK8L4hNpf+t2VZXWNpCNOpI3I9kEw==
|
||||
=6F5u
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>&a.jdp</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
John D. Polstra <jdp@polstra.com>
|
||||
Fingerprint = 54 3A 90 59 6B A4 9D 61 BF 1D 03 09 35 8D F6 0D
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2
|
||||
|
||||
mQCNAzMElMEAAAEEALizp6ZW9QifQgWoFmG3cXhzQ1+Gt+a4S1adC/TdHdBvw1M/
|
||||
I6Ok7TC0dKF8blW3VRgeHo4F3XhGn+n9MqIdboh4HJC5Iiy63m98sVLJSwyGO4oM
|
||||
dkEGyyCLxqP6h/DU/tzNBdqFzetGtYvU4ftt3RO0a506cr2CHcdm8Q+/vPRJAAUR
|
||||
tCFKb2huIEQuIFBvbHN0cmEgPGpkcEBwb2xzdHJhLmNvbT6JAJUDBRAzBNBE9RVb
|
||||
+45ULV0BAWgiA/0WWO3+c3qlptPCHJ3DFm6gG/qNKsY94agL/mHOr0fxMP5l2qKX
|
||||
O6a1bWkvGoYq0EwoKGFfn0QeHiCl6jVi3CdBX+W7bObMcoi+foqZ6zluOWBC1Jdk
|
||||
WQ5/DeqQGYXqbYjqO8voCScTAPge3XlMwVpMZTv24u+nYxtLkE0ZcwtY9IkAlQMF
|
||||
EDMEt/DHZvEPv7z0SQEBXh8D/2egM5ckIRpGz9kcFTDClgdWWtlgwC1iI2p9gEhq
|
||||
aufy+FUJlZS4GSQLWB0BlrTmDC9HuyQ+KZqKFRbVZLyzkH7WFs4zDmwQryLV5wkN
|
||||
C4BRRBXZfWy8s4+zT2WQD1aPO+ZsgRauYLkJgTvXTPU2JCN62Nsd8R7bJS5tuHEm
|
||||
7HGmiQCVAwUQMwSvHB9/qQgDWPy9AQFAhAQAgJ1AlbKITrEoJ0+pLIsov3eQ348m
|
||||
SVHEBGIkU3Xznjr8NzT9aYtq4TIzt8jplqP3QoV1ka1yYpZf0NjvfZ+ffYp/sIaU
|
||||
wPbEpgtmHnVWJAebMbNs/Ad1w8GDvxEt9IaCbMJGZnHmfnEqOBIxF7VBDPHHoJxM
|
||||
V31K/PIoYsHAy5w=
|
||||
=cHFa
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>&a.guido</heading><p>
|
||||
|
||||
<tscreen><verb>
|
||||
Guido van Rooij <guido@gvr.win.tue.nl>
|
||||
Fingerprint = 16 79 09 F3 C0 E4 28 A7 32 62 FA F6 60 31 C0 ED
|
||||
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
Version: 2.6.2
|
||||
|
||||
mQCNAzGeO84AAAEEAKKAY91Na//DXwlUusr9GVESSlVwVP6DyH1wcZXhfN1fyZHq
|
||||
SwhMCEdHYoojQds+VqD1iiZQvv1RLByBgj622PDAPN4+Z49HjGs7YbZsUNuQqPPU
|
||||
wRPpP6ty69x1hPKq1sQIB5MS4radpCM+4wbZbhxv7l4rP3RWUbNaYutZnzI9AAUR
|
||||
tCZHdWlkbyB2YW4gUm9vaWogPGd1aWRvQGd2ci53aW4udHVlLm5sPokAlQMFEDMG
|
||||
Hcgff6kIA1j8vQEBbYgD/jm9xHuUuY+iXDkOzpCXBYACYEZDV913MjtyBAmaVqYo
|
||||
Rh5HFimkGXe+rCo78Aau0hc57fFMTsJqnuWEqVt3GRq28hSK1FOZ7ni9/XibHcmN
|
||||
rt2yugl3hYpClijo4nrDL1NxibbamkGW/vFGcljS0jqXz6NDVbGx5Oo7HBByxByz
|
||||
iQCVAwUQMhmtVjt/x7zOdmsfAQFuVQQApsVUTigT5YWjQA9Nd5Z0+a/oVtZpyw5Z
|
||||
OljLJP3vqJdMa6TidhfcatjHbFTve5x1dmjFgMX/MQTd8zf/+Xccy/PX4+lnKNpP
|
||||
eSf1Y4aK+E8KHmBGd6GzX6CIboyGYLS9e3kGnN06F2AQtaLyJFgQ71wRaGuyKmQG
|
||||
FwTn7jiKb1aJAJUDBRAyEOLXPt3iN6QQUSEBATwQA/9jqu0Nbk154+Pn+9mJX/YT
|
||||
fYR2UqK/5FKCqgL5Nt/Deg2re0zMD1f8F9Dj6vuAAxq8hnOkIHKlWolMjkRKkzJi
|
||||
mSPEWl3AuHJ31k948J8it4f8kq/o44usIA2KKVMlI63Q/rmNdfWCyiYQEVGcRbTm
|
||||
GTdZIHYCOgV5dOo4ebFqgYkAlQMFEDIE1nMEJn15jgpJ0QEBW6kEAKqN8XSgzTqf
|
||||
CrxFXT07MlHhfdbKUTNUoboxCGCLNW05vf1A8F5fdE5i14LiwkldWIzPxWD+Sa3L
|
||||
fNPCfCZTaCiyGcLyTzVfBHA18MBAOOX6JiTpdcm22jLGUWBf/aJK3yz/nfbWntd/
|
||||
LRHysIdVp29lP5BF+J9/Lzbb/9LxP1taiQCVAwUQMgRXZ44CzbsJWQz9AQFf7gP/
|
||||
Qa2FS5S6RYKG3rYanWADVe/ikFV2lxuM1azlWbsmljXvKVWGe6cV693nS5lGGAjx
|
||||
lbd2ADwXjlkNhv45HLWFm9PEveO9Jjr6tMuXVt8N2pxiX+1PLUN9CtphTIU7Yfjn
|
||||
s6ryZZfwGHSfIxNGi5ua2SoXhg0svaYnxHxXmOtH24iJAJUDBRAyAkpV8qaAEa3W
|
||||
TBkBARfQBAC+S3kbulEAN3SI7/A+A/dtl9DfZezT9C4SRBGsl2clQFMGIXmMQ/7v
|
||||
7lLXrKQ7U2zVbgNfU8smw5h2vBIL6f1PyexSmc3mz9JY4er8KeZpcf6H0rSkHl+i
|
||||
d7TF0GvuTdNPFO8hc9En+GG6QHOqbkB4NRZ6cwtfwUMhk2FHXBnjF4kAlQMFEDH5
|
||||
FFukUJAsCdPmTQEBe74EAMBsxDnbD9cuI5MfF/QeTNEG4BIVUZtAkDme4Eg7zvsP
|
||||
d3DeJKCGeNjiCWYrRTCGwaCWzMQk+/+MOmdkI6Oml+AIurJLoHceHS9jP1izdP7f
|
||||
N2jkdeJSBsixunbQWtUElSgOQQ4iF5kqwBhxtOfEP/L9QsoydRMR1yB6WPD75H7V
|
||||
iQCVAwUQMZ9YNGtaZ42Bsqd5AQH0PAQAhpVlAc3ZM/KOTywBSh8zWKVlSk3q/zGn
|
||||
k7hJmFThnlhH1723+WmXE8aAPJi+VXOWJUFQgwELJ6R8jSU2qvk2m1VWyYSqRKvc
|
||||
VRQMqT2wjss0GE1Ngg7tMrkRHT0il7E2xxIb8vMrIwmdkbTfYqBUhhGnsWPHZHq7
|
||||
MoA1/b+rK7CJAJUDBRAxnvXh3IDyptUyfLkBAYTDA/4mEKlIP/EUX2Zmxgrd/JQB
|
||||
hqcQlkTrBAaDOnOqe/4oewMKR7yaMpztYhJs97i03Vu3fgoLhDspE55ooEeHj0r4
|
||||
cOdiWfYDsjSFUYSPNVhW4OSruMA3c29ynMqNHD7hpr3rcCPUi7J2RncocOcCjjK2
|
||||
BQb/9IAUNeK4C9gPxMEZLokAlQMFEDGeO86zWmLrWZ8yPQEBEEID/2fPEUrSX3Yk
|
||||
j5TJPFZ9MNX0lEo7AHYjnJgEbNI4pYm6C3PnMlsYfCSQDHuXmRQHAOWSdwOLvCkN
|
||||
F8eDaF3M6u0urgeVJ+KVUnTz2+LZoZs12XSZKCte0HxjbvPpWMTTrYyimGezH79C
|
||||
mgDVjsHaYOx3EXF0nnDmtXurGioEmW1J
|
||||
=mSvM
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
</verb></tscreen>
|
||||
@ -1,230 +0,0 @@
|
||||
<!-- $Id: policies.sgml,v 1.13 1997/04/03 01:07:38 max Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Source Tree Guidelines and Policies
|
||||
<label id="policies">
|
||||
</heading>
|
||||
|
||||
<p><em>Contributed by &a.phk;.</em>
|
||||
|
||||
This chapter documents various guidelines and policies in force
|
||||
for the FreeBSD source tree.
|
||||
|
||||
<sect><heading>MAINTAINER on Makefiles
|
||||
<label id="policies:maintainer">
|
||||
</heading>
|
||||
|
||||
<p>June 1996.
|
||||
|
||||
<p>If a particular portion of the FreeBSD distribution is being maintained by a
|
||||
person or group of persons, they can communicate this fact to the
|
||||
world by adding a
|
||||
|
||||
<verb>
|
||||
MAINTAINER= email-addresses
|
||||
</verb>
|
||||
|
||||
<p>line to the makefiles covering this portion of the source tree.
|
||||
|
||||
<p>The semantics of this are as follows:
|
||||
|
||||
<p>The maintainer owns and is responsible for that code. This means
|
||||
that he is responsible for fixing bugs and answer problem reports
|
||||
pertaining to that piece of the code, and in the case of contributed
|
||||
software, for tracking new versions, as appropriate.
|
||||
|
||||
<p>Changes to directories which have a maintainer defined shall be
|
||||
sent to the
|
||||
maintainer for review before being committed. Only if the maintainer does not respond
|
||||
for an unacceptable period of time, to several emails, will it be
|
||||
acceptable to commit changes without review by the maintainer.
|
||||
However, it is suggested that you try and have the changes reviewed
|
||||
by someone else if at all possible.
|
||||
|
||||
<p>It is of course not acceptable to add a person or group as maintainer
|
||||
unless they agree to assume this duty. On the other hand it doesn't
|
||||
have to be a committer and it can easily be a group of people.
|
||||
|
||||
<sect><heading>Contributed software</heading>
|
||||
|
||||
<p>June 1996.
|
||||
|
||||
<p>Some parts of the FreeBSD distribution consist of software that
|
||||
is actively being maintained outside the FreeBSD project. For
|
||||
historical reasons, we call this <em>contributed</em> software. Some
|
||||
examples are perl, gcc and patch.
|
||||
|
||||
<p>Over the last couple of years, various methods have been used in
|
||||
dealing with this type of software and all have some number of
|
||||
advantages and drawbacks. No clear winner has emerged.
|
||||
|
||||
<p>Since this is the case, after some debate one of these methods has
|
||||
been selected as the "official" method and will be required for
|
||||
future imports of software of this kind. Furthermore, it is strongly
|
||||
suggested that existing contributed software converge on this model
|
||||
over time, as it has significant advantages over the old method,
|
||||
including the ability to easily obtain diffs relative to the
|
||||
"official" versions of the source by everyone (even without cvs
|
||||
access). This will make it significantly easier to return changes
|
||||
to the primary developers of the contributed software.
|
||||
|
||||
<p>Ultimately, however, it comes down to the people actually doing
|
||||
the work. If using this model is particularly unsuited to the
|
||||
package being dealt with, exceptions to these rules may be granted
|
||||
only with the approval of the core team and with the general
|
||||
consensus of the other developers. The ability to maintain the
|
||||
package in the future will be a key issue in the decisions.
|
||||
|
||||
<p>The <tt>Tcl</tt> embedded programming language will be used as example
|
||||
of how this model works:
|
||||
|
||||
<p><verb>src/contrib/tcl</verb> contains the source as distributed by the maintainers
|
||||
of this package. Parts that are entirely not applicable for FreeBSD
|
||||
can be removed. In the case of Tcl, the "mac", "win" and "compat"
|
||||
subdirectories were eliminated before the import
|
||||
|
||||
<p><verb>src/lib/libtcl</verb> contains only a "bmake style" Makefile that uses
|
||||
the standard bsd.lib.mk makefile rules to produce the library and
|
||||
install the documentation.
|
||||
|
||||
<p><verb>src/usr.bin/tclsh</verb> contains only a bmake style Makefile which will
|
||||
produce and install the "tclsh" program and its associated man-pages
|
||||
using the standard bsd.prog.mk rules.
|
||||
|
||||
<p><verb>src/tools/tools/tcl_bmake</verb> contains a couple of shell-scripts that can be of help
|
||||
when the tcl software needs updated, these are not part of the
|
||||
build or installed software.
|
||||
|
||||
<p>The important thing here is that the "src/contrib/tcl" directory
|
||||
is created according to the rules: It is supposed to contain the
|
||||
sources as distributed (on a proper CVS vendor-branch) with as few
|
||||
FreeBSD-specific changes as possible. The 'easy-import' tool on
|
||||
freefall will assist in doing the import, but if there are any
|
||||
doubts on how to go about it, it is imperative that you ask first
|
||||
and not blunder ahead and hope it "works out". CVS is not forgiving
|
||||
of import accidents and a fair amount of effort is required to back
|
||||
out major mistakes.
|
||||
|
||||
<p>Because of some unfortunate design limitations with CVS's vendor
|
||||
branches, it is required that "official" patches from the vendor
|
||||
be applied to the original distributed sources and the result
|
||||
re-imported onto the vendor branch again. Official patches should
|
||||
never be patched into the FreeBSD checked out version and
|
||||
"committed", as this destroys the vendor branch coherency and makes
|
||||
importing future versions rather difficult as there will be conflicts.
|
||||
|
||||
<p>Since many packages contain files that are meant for compatibility
|
||||
with other architectures and environments that FreeBSD, it is
|
||||
permissible to remove parts of the distribution tree that are of no interest
|
||||
to FreeBSD in order to save space. Files containing copyright
|
||||
notices and release-note kind of information applicable to the
|
||||
remaining files shall <em>not</em> be removed.
|
||||
|
||||
<p>If it seems easier, the "bmake" makefiles can be produced from the
|
||||
dist tree automatically by some utility, something which would
|
||||
hopefully make it even easier to upgrade to a new version. If this
|
||||
is done, be sure to check in such utilities (as necessary) in the
|
||||
src/tools directory along with the port itself so that it is available
|
||||
to future maintainers.
|
||||
|
||||
<p>In the src/contrib/tcl level directory, a file called FREEBSD-upgrade
|
||||
should be added and it should states things like:
|
||||
|
||||
<itemize>
|
||||
<item> Which files have been left out
|
||||
<item> Where the original distribution was obtained from and/or the official
|
||||
master site.
|
||||
<item> Where to send patches back to the original authors
|
||||
<item> Perhaps an overview of the FreeBSD-specific changes that have been made.
|
||||
</itemize>
|
||||
|
||||
<p>However, please do not import FREEBSD-upgrade with the contributed source.
|
||||
Rather you should ``cvs add FREEBSD-upgrade ; cvs ci'' after the
|
||||
initial import. Example wording from ``src/contrib/cpio'' is below:
|
||||
|
||||
<verb>This directory contains virgin sources of the original distribution files
|
||||
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
|
||||
the files in this directory via patches and a cvs commit. New versions or
|
||||
official-patch versions must be imported.
|
||||
|
||||
For the import of GNU cpio 2.4.2, the following files were removed:
|
||||
|
||||
INSTALL cpio.info mkdir.c
|
||||
Makefile.in cpio.texi mkinstalldirs
|
||||
|
||||
To upgrade to a newer version of cpio, when it is available:
|
||||
1. Unpack the new version into an empty directory.
|
||||
[Do not make ANY changes to the files.]
|
||||
|
||||
2. Remove the files listed above and any others that don't apply to
|
||||
FreeBSD.
|
||||
|
||||
3. Use the command:
|
||||
cvs import -m 'Virgin import of GNU cpio v<version>' \
|
||||
src/contrib/cpio GNU v<version>
|
||||
|
||||
For example, to do the import of version 2.4.2, I typed:
|
||||
cvs import -m 'Virgin import of GNU v2.4.2' \
|
||||
src/contrib/cpio GNU v2.4.2
|
||||
|
||||
4. Follow the instructions printed out in step 3 to resolve any
|
||||
conflicts between local FreeBSD changes and the newer version.
|
||||
|
||||
Do not, under any circumstances, deviate from this procedure.
|
||||
|
||||
To make local changes to cpio, simply patch and commit to the main
|
||||
branch (aka HEAD). Never make local changes on the GNU branch.
|
||||
|
||||
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
|
||||
inclusion in the next vendor release.
|
||||
|
||||
obrien@freebsd.org - 30 March 1997</verb>
|
||||
|
||||
|
||||
<sect><heading>Shared libraries
|
||||
<label id="policies:shlib">
|
||||
</heading>
|
||||
|
||||
<p><em>Contributed by &a.asami;, &a.peter;, and &a.obrien;.
|
||||
<newline>9 December 1996.</em></p>
|
||||
|
||||
<p>If you are adding shared library support to a port or other piece
|
||||
of software that doesn't have one, the version numbers should
|
||||
follow these rules. Generally, the resulting numbers will have
|
||||
nothing to do with the release version of the software.
|
||||
|
||||
<p>The three principles of shared library building are:
|
||||
|
||||
<itemize>
|
||||
<item>Start from 1.0
|
||||
<item>If there is a change that is backwards compatible, bump
|
||||
minor number
|
||||
<item>If there is an incompatible change, bump major number
|
||||
</itemize>
|
||||
|
||||
<p>For instance, added functions and bugfixes result in the minor
|
||||
version number being bumped, while deleted functions, changed
|
||||
function call syntax etc. will force the major version number
|
||||
to change.
|
||||
|
||||
<p>Stick to version numbers of the form major.minor (x.y). Our dynamic
|
||||
linker does not handle version numbers of the form x.y.z well. Any
|
||||
version number after the ``y'' (ie. the third digit) is totally ignored
|
||||
when comparing shared lib version numbers to decide which library to
|
||||
link with. Given two shared libraries that differ only in the `micro'
|
||||
revision, ld.so will link with the higher one. Ie: if you link with
|
||||
libfoo.so.3.3.3, the linker only records 3.3 in the headers, and will
|
||||
link with anything starting with libfoo.so.3.(anything >= 3).(highest
|
||||
available).
|
||||
<p>Note that ld.so will always use the highest "minor" revision.
|
||||
Ie: it will use libc.so.2.2 in preference to libc.so.2.0, even if the
|
||||
program was initially linked with libc.so.2.0.
|
||||
|
||||
<p>For non-port libraries, it is also our policy to change the
|
||||
shared library version number only once between releases. When
|
||||
you make a change to a system library that requires the version
|
||||
number to be bumped, check the Makefile's commit logs. It is the
|
||||
responsibility of the committer to ensure that the first such
|
||||
change since the release will result in the shared library version
|
||||
number in the Makefile to be updated, and any subsequent changes
|
||||
will not.
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,847 +0,0 @@
|
||||
<!-- $Id: ports.sgml,v 1.24 1997/03/08 11:44:08 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Installing Applications: The Ports collection<label id="ports"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jraynard;.</em>
|
||||
|
||||
The FreeBSD Ports collection allows you to compile and install a very
|
||||
wide range of applications with a minimum of effort.
|
||||
|
||||
<p> For all the hype about open standards, getting a program to work
|
||||
on different versions of Unix in the real world can be a tedious and
|
||||
tricky business, as anyone who has tried it will know. You may be lucky
|
||||
enough to find that the program you want will compile cleanly on your
|
||||
system, install itself in all the right places and run flawlessly
|
||||
``out of the box'', but this is unfortunately rather rare. With most
|
||||
programs, you will find yourself doing a fair bit of head-scratching,
|
||||
and there are quite a few programs that will result in premature
|
||||
greying, or even chronic alopecia...
|
||||
|
||||
<p> Some software distributions have attacked this problem by
|
||||
providing configuration scripts. Some of these are very clever, but
|
||||
they have an unfortunate tendency to triumphantly announce that your
|
||||
system is something you have never heard of and then ask you lots of
|
||||
questions that sound like a final exam in system-level Unix
|
||||
programming (``Does your system's gethitlist function return a const
|
||||
pointer to a fromboz or a pointer to a const fromboz? Do you have
|
||||
Foonix style unacceptable exception handling? And if not, why not?'').
|
||||
|
||||
<p> Fortunately, with the Ports collection, all the hard work involved
|
||||
has already been done, and you can just type 'make install' and get a
|
||||
working program.
|
||||
|
||||
<sect><heading>Why have a Ports Collection?</heading>
|
||||
|
||||
<p>The base FreeBSD system comes with a very wide range of tools and
|
||||
system utilities, but a lot of popular programs are not in the base
|
||||
system, for good reasons:-
|
||||
|
||||
<enum>
|
||||
<item>``I can not live without x y and z on my system'' type programs
|
||||
(eg a certain Lisp-based editor, or the mtools set of programs for
|
||||
dealing with DOS floppy disks), because it is too subjective (many
|
||||
people can not stand Emacs and/or never use DOS floppies and seem none
|
||||
the worse for it).
|
||||
|
||||
<item>Too specialised to put in the base system (CAD, databases).
|
||||
|
||||
<item>Programs which fall into the ``I would not mind having a look at
|
||||
that when I get a spare minute'' category, rather than system-critical
|
||||
ones (some languages, perhaps).
|
||||
|
||||
<item>``Wow fab this is way cool'' fun type programs that could not
|
||||
possibly be supplied with a serious operating system like FreeBSD ;-)
|
||||
|
||||
<item>However many programs you put in the base system, people will
|
||||
always want more, and a line has to be drawn somewhere (otherwise
|
||||
FreeBSD distributions would become absolutely enormous).
|
||||
</enum>
|
||||
|
||||
<p> Obviously it would be unreasonable to expect everyone to port their
|
||||
favourite programs by hand (not to mention a tremendous amount of
|
||||
duplicated work), so the FreeBSD Project came up with an ingenious
|
||||
way of using standard tools that would automate the process.
|
||||
|
||||
<p> Incidentally, this is an excellent illustration of how ``the Unix way''
|
||||
works in practice by combining a set of simple but very flexible tools
|
||||
into something very powerful.
|
||||
|
||||
<sect><heading> How does the Ports collection work?</heading>
|
||||
<p>
|
||||
Programs are typically distributed on the Internet as a
|
||||
<ref id="ports:tarball" name="tarball"> consisting of
|
||||
a Makefile and the source code for the program and usually
|
||||
some instructions (which are unfortunately not always as instructive
|
||||
as they could be), with perhaps a configuration script.
|
||||
<p>
|
||||
The standard scenario is that you FTP down the tarball, extract it
|
||||
somewhere, glance through the instructions, make any changes that seem
|
||||
necessary, run the configure script to set things up and use the standard
|
||||
`make' program to compile and install the program from the source.
|
||||
<p>
|
||||
FreeBSD ports still use the tarball mechanism, but use a
|
||||
<ref id="ports:skeleton" name="skeleton"> to hold the "knowledge"
|
||||
of how to get the program working on FreeBSD, rather than expecting the
|
||||
user to be able to work it out. They also supply their own customised
|
||||
<ref id="ports:makefile" name="Makefile">, so that almost every port
|
||||
can be built in the same way.
|
||||
<p>
|
||||
If you look at a port skeleton (either on <htmlurl
|
||||
url="file://localhost/usr/ports/shells/bash" name="your FreeBSD
|
||||
system"> or <htmlurl
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/ports/shells/bash" name="the
|
||||
FTP site">) and expect to find all sorts of pointy-headed rocket
|
||||
science lurking there, you may be disappointed by the one or two
|
||||
rather unexciting-looking files and directories you find there.
|
||||
(We will discuss in a minute how to go about <ref id="ports:getting"
|
||||
name="Getting a port">).
|
||||
|
||||
<p>``How on earth can this do anything?'' I hear you cry. ``There
|
||||
is not even any source code there!''
|
||||
|
||||
<p> Fear not, gentle reader, all will become clear (hopefully). Let's
|
||||
see what happens if we try and install a port. I have chosen `bash', also
|
||||
known as the Bourne-Again Shell, as that seems fairly typical.
|
||||
|
||||
<em>Note</em> if you are trying this at home, you will need to be root.
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports/shells/bash
|
||||
# make install
|
||||
Checksums OK.
|
||||
===> Extracting for bash-1.14.5
|
||||
===> Patching for bash-1.14.5
|
||||
===> Applying FreeBSD patches for bash-1.14.5
|
||||
===> Configuring for bash-1.14.5
|
||||
===> Building for bash-1.14.5
|
||||
[lots and lots of compiler output here...]
|
||||
===> Installing for bash-1.14.5
|
||||
make -f bash-Makefile bindir=/usr/local/bin prefix=/usr/local install
|
||||
(cd ./documentation/; make )
|
||||
rm -f builtins.txt
|
||||
nroff -man builtins.1 > builtins.txt
|
||||
install -c -o bin -g bin -m 555 bash /usr/local/bin/bash
|
||||
install -c -o bin -g bin -m 555 bashbug /usr/local/bin/bashbug
|
||||
( cd ./documentation/ ; make mandir=/usr/local/man/man1 man3dir=/usr/local/man/man3 infodir=/usr/local/info install )
|
||||
[ -d /usr/local/man/man1 ] || mkdir /usr/local/man/man1
|
||||
[ -d /usr/local/info ] || mkdir /usr/local/info
|
||||
../support/install.sh -c -m 644 bash.1 /usr/local/man/man1
|
||||
../support/install.sh -c -m 644 builtins.1 /usr/local/man/man1/bash_builtins.1
|
||||
../support/install.sh -c -m 644 features.info /usr/local/info/bash.info
|
||||
gzip -9nf /usr/local/man/man1/bash.1 /usr/local/man/man1/bash_builtins.1
|
||||
===> Registering installation for bash-1.14.5
|
||||
</verb>
|
||||
|
||||
<p> To avoid confusing the issue, I have slightly pruned the install
|
||||
output, as well as completely removing the build output. If you tried
|
||||
this yourself, you may well have got something like this at the start:-
|
||||
|
||||
<label id="ports:fetch">
|
||||
<verb>
|
||||
>> bash-1.14.5.tar.gz doesn't seem to exist on this system.
|
||||
>> Attempting to fetch from ftp://slc2.ins.cwru.edu/pub/dist/.
|
||||
</verb>
|
||||
|
||||
<p> The `make' program has noticed that you did not have a local copy
|
||||
of the source code and tried to FTP it down so it could get the job
|
||||
done (are you starting to feel impressed? 8-)). I already had the
|
||||
source handy in my example, so it did not need to fetch it.
|
||||
|
||||
<p> Let's go through this and see what the `make' program was doing.
|
||||
|
||||
<enum>
|
||||
<item> Locate the source code <ref id="ports:tarball"
|
||||
name="tarball."> If it is not available locally, try to grab it from an
|
||||
FTP site.
|
||||
|
||||
<item> Run a <ref id="ports:checksum" name="checksum"> test on the
|
||||
tarball to make sure it has not been tampered with, accidentally
|
||||
truncated, struck by neutrinos while in transit, etc.
|
||||
|
||||
<item> Extract the tarball into a temporary work directory.
|
||||
|
||||
<item> Apply any <ref id="ports:patch" name="patches"> needed to get
|
||||
the source to compile and run under FreeBSD.
|
||||
|
||||
<item> Run any configuration script required by the build process and
|
||||
correctly answer any questions it asks.
|
||||
|
||||
<item> (Finally!) Compile the code.
|
||||
|
||||
<item> Install the program executable and other supporting files, man
|
||||
pages, etc. under the /usr/local hierarchy, where they will not get mixed
|
||||
up with system programs. This also makes sure that all the ports you
|
||||
install will go in the same place, instead of being flung all over
|
||||
your system.
|
||||
|
||||
<item> Register the installation in a database. This means
|
||||
that, if you do not like the program, you can cleanly <ref
|
||||
id="ports:remove" name="remove"> all traces of it from your system.
|
||||
|
||||
</enum>
|
||||
|
||||
<p> See if you can match these steps to the make output. And if you
|
||||
were not impressed before, you should be by now!
|
||||
|
||||
<sect><heading>Getting a FreeBSD Port<label id="ports:getting"></heading>
|
||||
<p>
|
||||
There are two ways of getting hold of the FreeBSD port for a
|
||||
program. One requires a <ref id="ports:cd" name="FreeBSD
|
||||
CDROM">, the other involves using an <ref id="ports:inet"
|
||||
name="Internet Connection.">
|
||||
|
||||
<sect1><heading>Compiling ports from CDROM<label id="ports:cd"></heading>
|
||||
<p>
|
||||
If you answered yes to the question ``Do you want to link the ports
|
||||
collection to your CDROM'' during the FreeBSD installation, the initial
|
||||
setting up will already have been done for you.
|
||||
<p>
|
||||
If not, make sure the <em /FreeBSD/ CDROM is in the drive and mounted on,
|
||||
say, /cdrom. Then do
|
||||
|
||||
<verb>
|
||||
# mkdir /usr/ports
|
||||
# cd /usr/ports
|
||||
# ln -s /cdrom/ports/distfiles distfiles
|
||||
</verb>
|
||||
|
||||
to enable the ports make mechanism to find the tarballs (it expects to
|
||||
find them in /usr/ports/distfiles, which is why we sym-linked the
|
||||
CDROM's tarball directory to there).
|
||||
<p>
|
||||
Now, suppose you want to install the gnats program from the databases
|
||||
directory. Here is how to do it:-
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# mkdir databases
|
||||
# cp -R /cdrom/ports/databases/gnats databases
|
||||
# cd databases/gnats
|
||||
# make install
|
||||
</verb>
|
||||
|
||||
Or if you are a serious database user and you want to compare all the
|
||||
ones available in the Ports collection, do
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# cp -R /cdrom/ports/databases .
|
||||
# cd databases
|
||||
# make install
|
||||
</verb>
|
||||
|
||||
(yes, that really is a dot on its own after the cp command and not a
|
||||
mistake. It is Unix-ese for ``the current directory'')
|
||||
<p>
|
||||
and the ports make mechanism will automatically compile and install
|
||||
all the ports in the databases directory for you!
|
||||
<p>
|
||||
If you do not like this method, here is a completely different way of
|
||||
doing it:-
|
||||
<p>
|
||||
Create a "link tree" to it using the <tt>lndir(1)</tt> command that
|
||||
comes with the <em>XFree86</em> distribution. Find a location with
|
||||
some free space, create a directory there and then cd to it. Then
|
||||
invoke the <tt>lndir(1)</tt> command with the full pathname of the ``ports''
|
||||
directory on the CDROM as the first argument and . (the current directory)
|
||||
as the second. This might be, for example, something like:
|
||||
<verb>
|
||||
lndir /cdrom/ports .
|
||||
</verb>
|
||||
<p>Then you can build ports directly off the CDROM by building them in the
|
||||
link tree you have created.
|
||||
<p>
|
||||
Note that there are some ports for which we cannot provide the original
|
||||
source in the CDROM due to licensing limitations. In that case,
|
||||
you will need to look at the section on <ref id="ports:inet"
|
||||
name="Compiling ports using an Internet connection.">
|
||||
|
||||
<sect1><heading>Compiling ports from the Internet<label
|
||||
id="ports:inet"></heading>
|
||||
<p>
|
||||
If you do not have a CDROM, or you want to make sure you get the very
|
||||
latest version of the port you want, you will need to download the
|
||||
<ref id="ports:skeleton" name="skeleton"> for the port. Now this
|
||||
might sound like rather a fiddly job
|
||||
full of pitfalls, like downloading the patches into the pkg
|
||||
sub-directory by mistake, but it is actually very easy.
|
||||
<p>
|
||||
The key to it is that the FreeBSD FTP server can create on-the-fly
|
||||
<ref id="ports:tarball" name="tarballs"> for you. Here is how it works,
|
||||
with the gnats program in the databases directory as an example (the
|
||||
bits in square brackets are comments, do not type them in if you are
|
||||
trying this yourself!):-
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# mkdir databases
|
||||
# cd databases
|
||||
# ftp ftp.freebsd.org
|
||||
[log in as `ftp' and give your email address when asked for a
|
||||
password. Remember to use binary (aka image) mode!]
|
||||
> cd /pub/FreeBSD/ports/databases
|
||||
> get gnats.tar.gz [tarballs up the gnats skeleton for us]
|
||||
> quit
|
||||
# tar xzf gnats.tar.gz [extract the gnats skeleton]
|
||||
# cd gnats
|
||||
# make install [build and install gnats]
|
||||
</verb>
|
||||
|
||||
What happened here? We connected to the FTP server in the usual way
|
||||
and went to its databases sub-directory. When we gave it the command
|
||||
`get gnats.tar.gz', the FTP server <ref id="ports:tarball"
|
||||
name="tarballed"> up the gnats directory for us and even went to the
|
||||
trouble of compressing it before sending it so we could get our hands
|
||||
on it a little quicker.
|
||||
<p>
|
||||
We then extracted the gnats skeleton and went into the gnats directory
|
||||
to build the port. As we explained <ref id="ports:fetch"
|
||||
name="earlier">, the make process noticed we did not have a copy of the
|
||||
source locally, so it fetched one before extracting, patching and
|
||||
building it.
|
||||
<p>
|
||||
Let's try something more ambitious now. Instead of getting a single
|
||||
port skeleton, let's get a whole sub-directory, for example all the
|
||||
database skeletons in the ports collection. It looks almost the same:-
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# ftp ftp.freebsd.org
|
||||
[log in as `ftp' and give your email address when asked for a
|
||||
password. Remember to use binary (aka image) mode!]
|
||||
> cd /pub/FreeBSD/ports
|
||||
> get databases.tar.gz [tarballs up the databases directory for us]
|
||||
> quit
|
||||
# tar xzf databases.tar.gz [extract all the database skeletons]
|
||||
# cd databases
|
||||
# make install [build and install all the database ports]
|
||||
</verb>
|
||||
|
||||
With half a dozen straightforward commands, we have now got a set of
|
||||
database programs on our FreeBSD machine! All we did that was
|
||||
different from getting a single port skeleton and building it was that
|
||||
we got a whole directory at once, and compiled everything in it at
|
||||
once. Pretty impressive, no?
|
||||
<p>
|
||||
If you expect to be installing more than one or two ports, it is
|
||||
probably worth downloading all the ports directories - this involves
|
||||
downloading 2 or 3MB, when they are compressed. However, don't get
|
||||
carried away and type 'get ports.tar.gz' unless you are prepared to
|
||||
download the distfiles directory as well - this contains the source
|
||||
code for every single port and will take a very long time to download!
|
||||
|
||||
<sect><heading>Skeletons<label id="ports:skeleton"></heading>
|
||||
<p>
|
||||
A team of compulsive hackers who have forgotten to eat in a frantic
|
||||
attempt to make a deadline? Something unpleasant lurking in the FreeBSD
|
||||
attic? No, a skeleton here is a minimal framework that supplies everything
|
||||
needed to make the ports magic work.
|
||||
|
||||
<sect1><heading>Makefile<label id="ports:makefile"></heading>
|
||||
<p>
|
||||
The most important component of a skeleton is the Makefile. This contains
|
||||
various statements that specify how the port should be compiled and
|
||||
installed. Here is the Makefile for bash:-
|
||||
|
||||
<verb>
|
||||
# New ports collection makefile for: bash
|
||||
# Version required: 1.14.5
|
||||
# Date created: 21 August 1994
|
||||
# Whom: jkh
|
||||
#
|
||||
# Makefile,v 1.13 1995/10/04 14:45:01 asami Exp
|
||||
#
|
||||
|
||||
DISTNAME= bash-1.14.5
|
||||
CATEGORIES= shells
|
||||
MASTER_SITES= ftp://slc2.ins.cwru.edu/pub/dist/
|
||||
|
||||
MAINTAINER= ache@FreeBSD.ORG
|
||||
|
||||
post-install:
|
||||
.if !defined(NOMANCOMPRESS)
|
||||
gzip -9nf ${PREFIX}/man/man1/bash.1 ${PREFIX}/man/man1/bash_builtins.1
|
||||
.endif
|
||||
|
||||
.include <bsd.port.mk>
|
||||
</verb>
|
||||
|
||||
The lines beginning with a "#" sign are comments for the benefit
|
||||
of human readers (as in most Unix script files).
|
||||
<p>
|
||||
`DISTNAME" specifies the name of the <ref id="ports:tarball"
|
||||
name="tarball">, but without the extension.
|
||||
<p>
|
||||
`CATEGORIES" states what kind of program this is.
|
||||
<p>
|
||||
`MASTER_SITES" is the URL(s) of the master FTP site, which is
|
||||
used to retrieve the <ref id="ports:tarball" name="tarball"> if it is not
|
||||
available on the local system. This is a site which is regarded as
|
||||
reputable, and is normally the one from which the program is officially
|
||||
distributed (in so far as any software is "officially" distributed
|
||||
on the Internet).
|
||||
<p>
|
||||
`MAINTAINER" is the email address of the person who is
|
||||
responsible for updating the skeleton if, for example a new version
|
||||
of the program comes out. (Note: The title of "maintainer"
|
||||
is mainly an administrative one; it does <em /not/ mean the person
|
||||
concerned is responsible for supporting the program. If you have any
|
||||
<ref id="ports:kaput" name="problems with a port,"> please mail
|
||||
&a.ports; and <em /not/ the maintainer. Thank you!)
|
||||
<p>
|
||||
Skipping over the next few lines for a minute, the line
|
||||
<verb>
|
||||
.include <bsd.port.mk>
|
||||
</verb>
|
||||
says that the other statements and commands
|
||||
needed for this port are in a standard file called
|
||||
`bsd.port.mk". As these are the same for all ports, there is
|
||||
no point in duplicating them all over the place, so they are kept in a
|
||||
single standard file.
|
||||
<p>
|
||||
This is probably not the place to go into a detailed examination of
|
||||
how Makefiles work; suffice it to say that the lines starting with
|
||||
`post-install" over-ride the instructions in bsd.port.mk
|
||||
about what to do after installing the program, so that the man pages
|
||||
can be compressed after they have been put in their final destination.
|
||||
|
||||
<sect1><heading>The files directory</heading>
|
||||
<p>
|
||||
The file containing the <ref id="ports:checksum" name="checksum"> for
|
||||
the port is called "md5", after the MD5 algorithm
|
||||
used for ports checksums. It lives in a directory with the slightly
|
||||
confusing name of "files".
|
||||
<p>
|
||||
This directory can also contain other miscellaneous files that are required
|
||||
by the port and do not belong anywhere else.
|
||||
|
||||
<sect1><heading>The patches directory</heading>
|
||||
<p>
|
||||
This directory contains the <ref id="ports:patch" name="patches"> needed
|
||||
to make everything work properly under FreeBSD.
|
||||
|
||||
<sect1><heading>The pkg directory</heading>
|
||||
<p>
|
||||
This program contains three quite useful files:-
|
||||
|
||||
<itemize>
|
||||
<item>
|
||||
COMMENT - a one-line description of the program.
|
||||
|
||||
<item>
|
||||
DESCR - a more detailed description.
|
||||
|
||||
<item>
|
||||
PLIST - a list of all the files that will be created when the program is installed.
|
||||
</itemize>
|
||||
|
||||
<sect><heading>It does not work?!<label id="ports:kaput"></heading>
|
||||
|
||||
<p>Oh. You can do one of four (4) things :
|
||||
|
||||
<enum>
|
||||
<item> Fix it yourself. Technical details can be found in
|
||||
<ref id="porting" name="Porting applications.">
|
||||
<item> Gripe. This is done by e-mail *ONLY*! The people at Walnut Creek are
|
||||
in no way responsible for the functionality (or lack thereof) of the
|
||||
FreeBSD system as a whole, and especially the ports system, which
|
||||
is mainly contributed by 3rd parties. (If you do not believe me, check
|
||||
the catalogue, especially the line saying "We cannot offer tech-support
|
||||
on this product")
|
||||
|
||||
The e-mail address is the &a.ports;. Please include
|
||||
details of the port, where you got both the port source &
|
||||
distfile(s) from, and what the error was.
|
||||
|
||||
Note: At time of writing, lang/Sather does not seem to work on Pentium
|
||||
machines due to the Intel Curse (aka the Floating Point Division Bug).
|
||||
Please do not tell us about this - gripe to Intel instead - it is their
|
||||
bug!
|
||||
|
||||
<item> Forget it. This is the easiest for most - very few of the programs in
|
||||
ports can be classified as `essential'!
|
||||
|
||||
<item> Grab the pre-compiled package from a ftp server. The ``master'' package
|
||||
collection is on FreeBSD's FTP server in the <htmlurl
|
||||
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/packages/"
|
||||
name="packages directory.">
|
||||
|
||||
though check your local mirror first, please!
|
||||
|
||||
These are more likely to work (on the whole) than trying to compile from
|
||||
source, and a lot faster! Use the <tt>pkg_add(1)</tt>
|
||||
dddprogram to install them to your system.
|
||||
|
||||
</enum>
|
||||
|
||||
<sect><heading>I have this program that I would like to make into a port...</heading>
|
||||
|
||||
<p>Great! Please see the <ref id="porting:starting" name="guidelines">
|
||||
for detailed instructions on how to do this.
|
||||
|
||||
<sect><heading>Some Questions and Answers</heading>
|
||||
<p>
|
||||
<itemize>
|
||||
<item>
|
||||
Q. I thought this was going to be a discussion about modems??!
|
||||
<p>
|
||||
A. Ah. You must be thinking of the serial ports on the back of your
|
||||
computer. We are using `port' here to mean the result of `porting' a
|
||||
program from one version of Unix to another. (It is an unfortunate bad
|
||||
habit of computer people to use the same word to refer to several
|
||||
completely different things).
|
||||
|
||||
<item>
|
||||
Q. I thought you were supposed to use packages to install extra
|
||||
programs?
|
||||
<p>
|
||||
A. Yes, that is usually the quickest and easiest way of doing it.
|
||||
|
||||
<item>
|
||||
Q. So why bother with ports then?
|
||||
<p>
|
||||
A. Several reasons:-
|
||||
|
||||
<enum>
|
||||
<item> The licensing conditions on some software distributions
|
||||
require that they be distributed as source code, not binaries.
|
||||
|
||||
<item> Some people do not trust binary distributions. At least with
|
||||
source code you can (in theory) read through it and look for potential
|
||||
problems yourself.
|
||||
|
||||
<item> If you have some local patches, you will need the source to add
|
||||
them yourself.
|
||||
|
||||
<item> You might have opinions on how a program should be compiled
|
||||
that differ from the person who did the package - some people have
|
||||
strong views on what optimisation setting should be used, whether to
|
||||
build debug versions and then strip them or not, etc. etc.
|
||||
|
||||
<item> Some people like having code around, so they can read it if
|
||||
they get bored, hack around with it, borrow from it (licence terms
|
||||
permitting, of course!) and so on.
|
||||
|
||||
<item> If you ain't got the source, it ain't software! ;-)
|
||||
</enum>
|
||||
|
||||
<item><label id="ports:patch">
|
||||
Q. What is a patch?
|
||||
<p>
|
||||
A. A patch is a small (usually) file that specifies how to go from one
|
||||
version of a file to another. It contains text that says, in effect,
|
||||
things like ``delete line 23'', ``add these two lines after line 468''
|
||||
or ``change line 197 to this''. Also known as a `diff', since it is
|
||||
generated by a program of that name.
|
||||
|
||||
<item><label id="ports:tarball">
|
||||
Q. What is all this about tarballs?
|
||||
<p>
|
||||
A. It is a file ending in .tar.gz (with variations like .tar.Z, or
|
||||
even .tgz if you are trying to squeeze the names into a DOS filesystem).
|
||||
<p>
|
||||
Basically, it is a directory tree that has been archived into a single
|
||||
file (.tar) and then compressed (.gz). This technique was originally
|
||||
used for <em /T/ape <em /AR/chives (hence the name `tar'), but it is a
|
||||
widely used way of distributing program source code around the
|
||||
Internet.
|
||||
<p>
|
||||
You can see what files are in them, or even extract them yourself, by
|
||||
using the standard Unix tar program, which comes with the base FreeBSD
|
||||
system, like this:-
|
||||
|
||||
<verb>
|
||||
tar tvzf foobar.tar.gz # View contents of foobar.tar.gz
|
||||
tar xzvf foobar.tar.gz # Extract contents into the current directory
|
||||
</verb>
|
||||
|
||||
<item><label id="ports:checksum">
|
||||
Q. And a checksum?
|
||||
<p>
|
||||
A. It is a number generated by adding up all the data in the file you
|
||||
want to check. If any of the characters change, the checksum will no
|
||||
longer be equal to the total, so a simple comparison will allow you to
|
||||
spot the difference. (In practice, it is done in a more complicated way
|
||||
to spot problems like position-swapping, which will not show up with a
|
||||
simplistic addition).
|
||||
|
||||
<item>
|
||||
Q. I did what you said for <ref id="ports:cd" name="compiling ports
|
||||
from a CDROM"> and it worked great until I tried to install the kermit
|
||||
port:-
|
||||
|
||||
<verb>
|
||||
# make install
|
||||
>> cku190.tar.gz doesn't seem to exist on this system.
|
||||
>> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/.
|
||||
</verb>
|
||||
|
||||
Why can it not be found? Have I got a dud CDROM?
|
||||
<p>
|
||||
A. The licensing terms for kermit do not allow us to put the tarball
|
||||
for it on the CDROM, so you will have to fetch it by hand - sorry!
|
||||
The reason why you got all those error messages was because you
|
||||
were not connected to the Internet at the time. Once you have downloaded
|
||||
it from any of the sites above, you can re-start the process (try and
|
||||
choose the nearest site to you, though, to save your time and the
|
||||
Internet's bandwidth).
|
||||
|
||||
<item>
|
||||
Q. I did that, but when I tried to put it into /usr/ports/distfiles I
|
||||
got some error about not having permission.
|
||||
<p>
|
||||
A. The ports mechanism looks for the tarball in /usr/ports/distfiles,
|
||||
but you will not be able to copy anything there because it is sym-linked
|
||||
to the CDROM, which is read-only. You can tell it to look somewhere
|
||||
else by doing
|
||||
|
||||
<verb>
|
||||
DISTDIR=/where/you/put/it make install
|
||||
</verb>
|
||||
|
||||
<item>
|
||||
Q. Does the ports scheme only work if you have everything in
|
||||
/usr/ports? My system administrator says I must put everything under
|
||||
/u/people/guests/wurzburger, but it does not seem to work.
|
||||
<p>
|
||||
A. You can use the PORTSDIR and PREFIX variables to tell the ports
|
||||
mechanism to use different directories. For instance,
|
||||
|
||||
<verb>
|
||||
PORTSDIR=/u/people/guests/wurzburger/ports make install
|
||||
</verb>
|
||||
|
||||
will compile the port in /u/people/guests/wurzburger/ports and install
|
||||
everything under /usr/local.
|
||||
|
||||
<verb>
|
||||
PREFIX=/u/people/guests/wurzburger/local make install
|
||||
</verb>
|
||||
|
||||
will compile it in /usr/ports and install it in
|
||||
/u/people/guests/wurzburger/local.
|
||||
|
||||
And of course
|
||||
|
||||
<verb>
|
||||
PORTSDIR=.../ports PREFIX=.../local make install
|
||||
</verb>
|
||||
|
||||
will combine the two (it is too long to fit on the page if I write it
|
||||
in full, but I am sure you get the idea).
|
||||
<p>
|
||||
If you do not fancy typing all that in every time you install a port
|
||||
(and to be honest, who would?), it is a good idea to put these variables
|
||||
into your environment.
|
||||
|
||||
<item>
|
||||
Q. I do not have a FreeBSD CDROM, but I would like to have all the tarballs
|
||||
handy on my system so I do not have to wait for a download every time I
|
||||
install a port. Is there an easy way to get them all at once?
|
||||
<p>
|
||||
A. To get every single tarball for the ports collection, do
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# make fetch
|
||||
</verb>
|
||||
|
||||
For all the tarballs for a single ports directory, do
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports/directory
|
||||
# make fetch
|
||||
</verb>
|
||||
|
||||
and for just one port - well, I think you have guessed already.
|
||||
|
||||
<item>
|
||||
Q. I know it is probably faster to fetch the tarballs from one of the
|
||||
FreeBSD mirror sites close by. Is there any way to tell the port to
|
||||
fetch them from servers other than ones listed in the MASTER_SITES?
|
||||
<p>
|
||||
A. Yes. If you know, for example, ftp.FreeBSD.ORG is much closer than
|
||||
sites listed in MASTER_SITES, do as following example.
|
||||
<verb>
|
||||
# cd /usr/ports/directory
|
||||
# make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch
|
||||
</verb>
|
||||
|
||||
<item>
|
||||
Q. I want to know what files make is going to need before it tries to
|
||||
pull them down.
|
||||
<p>
|
||||
A. 'make fetch-list' will display a list of the files needed for a port.
|
||||
|
||||
<item>
|
||||
Q. Is there any way to stop the port from compiling? I want to do some
|
||||
hacking on the source before I install it, but it is a bit tiresome having
|
||||
to watch it and hit control-C every time.
|
||||
<p>
|
||||
A. Doing 'make extract' will stop it after it has fetched and
|
||||
extracted the source code.
|
||||
|
||||
<item>
|
||||
Q. I am trying to make my own port and I want to be able to stop it
|
||||
compiling until I have had a chance to see if my patches worked properly.
|
||||
Is there something like 'make extract', but for patches?
|
||||
<p>
|
||||
A. Yep, 'make patch' is what you want. And by the way, thank you for
|
||||
your efforts!
|
||||
|
||||
<item>
|
||||
Q. I have heard that some compiler options can cause bugs. Is this true?
|
||||
How can I make sure that I compile ports with the right settings?
|
||||
<p>
|
||||
A. Yes, with version 2.6.3 of gcc (the version shipped with FreeBSD
|
||||
2.1.0 and 2.1.5), the -O2 option could result in buggy code unless you
|
||||
used the -fno-strength-reduce option as well. (Most of the ports don't
|
||||
use -O2). You <em /should/ be able to specify the compiler options
|
||||
used by something like
|
||||
|
||||
<verb>
|
||||
# CFLAGS='-O2 -fno-strength-reduce' make install
|
||||
</verb>
|
||||
|
||||
or by editing /etc/make.conf, but this does not always seem to get
|
||||
picked up. The surest way is to do 'make configure', then go into the
|
||||
source directory and inspect the Makefiles by hand, but this can get
|
||||
tedious if the source has lots of sub-directories, each with their own
|
||||
Makefiles.
|
||||
|
||||
<item>
|
||||
Q. There are so many ports it is hard to find the one I want. Is there a
|
||||
list anywhere of what ports are available?
|
||||
<p>
|
||||
A. Look in the INDEX file in /usr/ports.
|
||||
|
||||
<item>
|
||||
Q. I went to install the 'foo' port but the system suddenly stopped
|
||||
and starting compiling the 'bar' port. What's going on?
|
||||
<p>
|
||||
A. The 'foo' port needs something that is supplied with 'bar' - for
|
||||
instance, if 'foo' uses graphics, 'bar' might have a library with
|
||||
useful graphics processing routines. Or 'bar' might be a tool that is
|
||||
needed to compile the 'foo' port.
|
||||
|
||||
<item><label id="ports:remove">
|
||||
Q. I installed the grizzle program from the ports and frankly it is a
|
||||
complete waste of disk space. I want to delete it but I do not know
|
||||
where it put all the files. Any clues?
|
||||
<p>
|
||||
A. No problem, just do
|
||||
|
||||
<verb>
|
||||
pkg_delete grizzle-6.5
|
||||
</verb>
|
||||
<item>
|
||||
|
||||
Q. Hang on a minute, you have to know the version number to use that
|
||||
command. You do not seriously expect me to remember that, do you??
|
||||
<p>
|
||||
A. Not at all, you can find it out by doing
|
||||
|
||||
<verb>
|
||||
pkg_info -a | grep grizzle
|
||||
</verb>
|
||||
|
||||
And it will tell you:-
|
||||
|
||||
<verb>
|
||||
Information for grizzle-6.5:
|
||||
grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game.
|
||||
</verb>
|
||||
|
||||
<item>
|
||||
Q. Talking of disk space, the ports directory seems to be taking up
|
||||
an awful lot of room. Is it safe to go in there and delete things?
|
||||
<p>
|
||||
A. Yes, if you have installed the program and are fairly certain you
|
||||
will not need the source again, there is no point in keeping it hanging
|
||||
around. The best way to do this is
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# make clean
|
||||
</verb>
|
||||
|
||||
which will go through all the ports subdirectories and delete
|
||||
everything except the skeletons for each port.
|
||||
<item>
|
||||
Q. I tried that and it still left all those tarballs or whatever you
|
||||
called them in the distfiles directory. Can I delete those as well?
|
||||
<p>
|
||||
A. Yes, if you are sure you have finished with them, those can go as
|
||||
well.
|
||||
|
||||
<item>
|
||||
Q. I like having lots and lots of programs to play with. Is there any
|
||||
way of installing all the ports in one go?
|
||||
<p>
|
||||
A. Just do
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# make install
|
||||
</verb>
|
||||
|
||||
<item>
|
||||
Q. OK, I tried that, but I thought it would take a very long time so I
|
||||
went to bed and left it to get on with it. When I looked at the
|
||||
computer this morning, it had only done three and a half ports. Did
|
||||
something go wrong?
|
||||
<p>
|
||||
A. No, the problem is that some of the ports need to ask you questions
|
||||
that we can not answer for you (eg ``Do you want to print on A4 or US
|
||||
letter sized paper?'') and they need to have someone on hand to answer
|
||||
them.
|
||||
|
||||
<item>
|
||||
Q. I really do not want to spend all day staring at the monitor. Any
|
||||
better ideas?
|
||||
<p>
|
||||
A. OK, do this before you go to bed/work/the local park:-
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# make -DBATCH install
|
||||
</verb>
|
||||
|
||||
This will install every port that does <em /not/ require user
|
||||
input. Then, when you come back, do
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports
|
||||
# make -DIS_INTERACTIVE install
|
||||
</verb>
|
||||
|
||||
to finish the job.
|
||||
|
||||
<item>
|
||||
Q. At work, we are using frobble, which is in your ports collection,
|
||||
but we have altered it quite a bit to get it to do what we need. Is
|
||||
there any way of making our own packages, so we can distribute it more
|
||||
easily around our sites?
|
||||
<p>
|
||||
A. No problem, assuming you know how to make patches for your changes:-
|
||||
|
||||
<verb>
|
||||
# cd /usr/ports/somewhere/frobble
|
||||
# make extract
|
||||
# cd work/frobble-2.8
|
||||
[Apply your patches]
|
||||
# cd ../..
|
||||
# make package
|
||||
</verb>
|
||||
|
||||
<item>
|
||||
Q. This ports stuff is really clever. I am desperate to find out how
|
||||
you did it. What is the secret?
|
||||
<p>
|
||||
A. Nothing secret about it at all, just look at the bsd.ports.mk and
|
||||
bsd.ports.subdir.mk files in your <htmlurl
|
||||
url="file://localhost/usr/share/mk/" name="makefiles directory.">
|
||||
(Note: readers with an aversion to intricate shell-scripts are advised
|
||||
not to follow this link...)
|
||||
</itemize>
|
||||
@ -1,427 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Setting up kernel PPP<label id="ppp"></heading>
|
||||
|
||||
<p><em>Contributed by &a.gena;.</em>
|
||||
|
||||
Before you start setting up PPP on your machine make
|
||||
sure that pppd is located in /usr/sbin and directory /etc/ppp
|
||||
exists.
|
||||
|
||||
pppd can work in two modes:
|
||||
<enum>
|
||||
<item> as a "client" , i.e. you want to connect your machine to outside
|
||||
world via PPP serial connection or modem line.
|
||||
|
||||
<item> as a "server" , i.e. your machine is located on the network and
|
||||
used to connect other computers using PPP.
|
||||
</enum>
|
||||
In both cases you will need to set up an options file (<tt>/etc/ppp/options</tt>
|
||||
or <tt>~/.ppprc</tt> if you have more then one user on your machine that uses
|
||||
PPP).
|
||||
|
||||
You also will need some modem/serial software ( preferably kermit )
|
||||
so you can dial and establish connection with remote host.
|
||||
|
||||
<sect1><heading>Working as a PPP client</heading>
|
||||
|
||||
<p>I used the following <tt>/etc/ppp/options</tt> to connect to CISCO terminal
|
||||
server PPP line.
|
||||
<verb>
|
||||
crtscts # enable hardware flow control
|
||||
modem # modem control line
|
||||
noipdefault # remote PPP server must supply your IP address.
|
||||
# if the remote host doesn't send your IP during IPCP
|
||||
# negotiation , remove this option
|
||||
passive # wait for LCP packets
|
||||
domain ppp.foo.com # put your domain name here
|
||||
|
||||
:<remote_ip> # put the IP of remote PPP host here
|
||||
# it will be used to route packets via PPP link
|
||||
# if you didn't specified the noipdefault option
|
||||
# change this line to <local_ip>:<remote_ip>
|
||||
|
||||
defaultroute # put this if you want that PPP server will be your
|
||||
# default router
|
||||
</verb>
|
||||
|
||||
To connect:
|
||||
<enum>
|
||||
<item> Dial to the remote host using kermit ( or other modem program )
|
||||
enter your user name and password ( or whatever is needed to enable PPP
|
||||
on the remote host )
|
||||
|
||||
<item> Exit kermit. ( without hanging up the line )
|
||||
|
||||
<item> enter:
|
||||
<verb>
|
||||
/usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200
|
||||
</verb>
|
||||
( put the appropriate speed and device name )
|
||||
</enum>
|
||||
|
||||
Now your computer is connected with PPP. If the connection fails for some
|
||||
reasons you can add the "debug" option to the <tt>/etc/ppp/options</tt> file
|
||||
and check messages on the console to track the problem
|
||||
|
||||
Following <tt>/etc/ppp/pppup</tt> script will make all 3 stages automatically:
|
||||
<verb>
|
||||
#!/bin/sh
|
||||
ps ax |grep pppd |grep -v grep
|
||||
pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
|
||||
if [ "X${pid}" != "X" ] ; then
|
||||
echo 'killing pppd, PID=' ${pid}
|
||||
kill ${pid}
|
||||
fi
|
||||
ps ax |grep kermit |grep -v grep
|
||||
pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
|
||||
if [ "X${pid}" != "X" ] ; then
|
||||
echo 'killing kermit, PID=' ${pid}
|
||||
kill -9 ${pid}
|
||||
fi
|
||||
|
||||
ifconfig ppp0 down
|
||||
ifconfig ppp0 delete
|
||||
|
||||
kermit -y /etc/ppp/kermit.dial
|
||||
pppd /dev/tty01 19200
|
||||
</verb>
|
||||
|
||||
<tt>/etc/ppp/kermit.dial</tt> is kermit script that dials and makes all
|
||||
necessary authorization on the remote host.
|
||||
( Example of such script is attached to the end of this document )
|
||||
|
||||
Use the following <tt>/etc/ppp/pppdown</tt> script to disconnect the PPP line:
|
||||
<verb>
|
||||
#!/bin/sh
|
||||
pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
|
||||
if [ X${pid} != "X" ] ; then
|
||||
echo 'killing pppd, PID=' ${pid}
|
||||
kill -TERM ${pid}
|
||||
fi
|
||||
|
||||
ps ax |grep kermit |grep -v grep
|
||||
pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
|
||||
if [ "X${pid}" != "X" ] ; then
|
||||
echo 'killing kermit, PID=' ${pid}
|
||||
kill -9 ${pid}
|
||||
fi
|
||||
|
||||
/sbin/ifconfig ppp0 down
|
||||
/sbin/ifconfig ppp0 delete
|
||||
kermit -y /etc/ppp/kermit.hup
|
||||
/etc/ppp/ppptest
|
||||
</verb>
|
||||
|
||||
Check if PPP is still running (<tt>/usr/etc/ppp/ppptest</tt>):
|
||||
<verb>
|
||||
#!/bin/sh
|
||||
pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'`
|
||||
if [ X${pid} != "X" ] ; then
|
||||
echo 'pppd running: PID=' ${pid-NONE}
|
||||
else
|
||||
echo 'No pppd running.'
|
||||
fi
|
||||
set -x
|
||||
netstat -n -I ppp0
|
||||
ifconfig ppp0
|
||||
</verb>
|
||||
|
||||
Hangs up modem line (<tt>/etc/ppp/kermit.hup</tt>):
|
||||
<verb>
|
||||
set line /dev/tty01 ; put your modem device here
|
||||
set speed 19200
|
||||
set file type binary
|
||||
set file names literal
|
||||
set win 8
|
||||
set rec pack 1024
|
||||
set send pack 1024
|
||||
set block 3
|
||||
set term bytesize 8
|
||||
set command bytesize 8
|
||||
set flow none
|
||||
|
||||
pau 1
|
||||
out +++
|
||||
inp 5 OK
|
||||
out ATH0\13
|
||||
echo \13
|
||||
exit
|
||||
</verb>
|
||||
|
||||
|
||||
<p>Here is an alternate method using <tt>chat</tt> instead of
|
||||
<tt>kermit</tt>.
|
||||
|
||||
<em>Contributed by &a.rhuff;.</em>
|
||||
|
||||
<p>The following two files are sufficient to accomplish a pppd
|
||||
connection.
|
||||
|
||||
<p><tt>/etc/ppp/options</tt>:
|
||||
<verb>
|
||||
/dev/cuaa1 115200
|
||||
|
||||
crtscts # enable hardware flow control
|
||||
modem # modem control line
|
||||
connect "/usr/bin/chat -f /etc/ppp/login.chat.script"
|
||||
noipdefault # remote PPP server must supply your IP address.
|
||||
# if the remote host doesn't send your IP during
|
||||
# IPCP negotiation, remove this option
|
||||
passive # wait for LCP packets
|
||||
domain <your.domain> # put your domain name here
|
||||
|
||||
: # put the IP of remote PPP host here
|
||||
# it will be used to route packets via PPP link
|
||||
# if you didn't specified the noipdefault option
|
||||
# change this line to <local_ip>:<remote_ip>
|
||||
|
||||
defaultroute # put this if you want that PPP server will be
|
||||
# your default router
|
||||
</verb>
|
||||
|
||||
|
||||
<p><tt>/etc/ppp/login.chat.script</tt>:
|
||||
|
||||
(This should actually go into a single line.)
|
||||
|
||||
<verb>
|
||||
ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number>
|
||||
CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id>
|
||||
TIMEOUT 5 sword: <password>
|
||||
</verb>
|
||||
|
||||
|
||||
Once these are installed and modified correctly, all you need to
|
||||
do is
|
||||
|
||||
<p><tt>pppd</tt>.
|
||||
|
||||
|
||||
<em> This sample based primarily on information provided by: Trev Roydhouse
|
||||
<Trev.Roydhouse@f401.n711.z3.fidonet.org> and used by
|
||||
permission.</em>
|
||||
|
||||
|
||||
<sect1><heading>Working as a PPP server</heading>
|
||||
|
||||
<p><tt>/etc/ppp/options</tt>:
|
||||
<verb>
|
||||
crtscts # Hardware flow control
|
||||
netmask 255.255.255.0 # netmask ( not required )
|
||||
192.114.208.20:192.114.208.165 # ip's of local and remote hosts
|
||||
# local ip must be different from one
|
||||
# you assigned to the ethernet ( or other )
|
||||
# interface on your machine.
|
||||
# remote IP is ip address that will be
|
||||
# assigned to the remote machine
|
||||
domain ppp.foo.com # your domain
|
||||
passive # wait for LCP
|
||||
modem # modem line
|
||||
</verb>
|
||||
|
||||
Following <tt>/etc/ppp/pppserv</tt> script will enable ppp server on your
|
||||
machine
|
||||
<verb>
|
||||
#!/bin/sh
|
||||
ps ax |grep pppd |grep -v grep
|
||||
pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
|
||||
if [ "X${pid}" != "X" ] ; then
|
||||
echo 'killing pppd, PID=' ${pid}
|
||||
kill ${pid}
|
||||
fi
|
||||
ps ax |grep kermit |grep -v grep
|
||||
pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
|
||||
if [ "X${pid}" != "X" ] ; then
|
||||
echo 'killing kermit, PID=' ${pid}
|
||||
kill -9 ${pid}
|
||||
fi
|
||||
|
||||
# reset ppp interface
|
||||
ifconfig ppp0 down
|
||||
ifconfig ppp0 delete
|
||||
|
||||
# enable autoanswer mode
|
||||
kermit -y /etc/ppp/kermit.ans
|
||||
|
||||
# run ppp
|
||||
pppd /dev/tty01 19200
|
||||
</verb>
|
||||
|
||||
Use this <tt>/etc/ppp/pppservdown</tt> script to stop ppp server:
|
||||
<verb>
|
||||
#!/bin/sh
|
||||
ps ax |grep pppd |grep -v grep
|
||||
pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'`
|
||||
if [ "X${pid}" != "X" ] ; then
|
||||
echo 'killing pppd, PID=' ${pid}
|
||||
kill ${pid}
|
||||
fi
|
||||
ps ax |grep kermit |grep -v grep
|
||||
pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'`
|
||||
if [ "X${pid}" != "X" ] ; then
|
||||
echo 'killing kermit, PID=' ${pid}
|
||||
kill -9 ${pid}
|
||||
fi
|
||||
ifconfig ppp0 down
|
||||
ifconfig ppp0 delete
|
||||
|
||||
kermit -y /etc/ppp/kermit.noans
|
||||
</verb>
|
||||
|
||||
Following kermit script will enable/disable autoanswer mode
|
||||
on your modem (<tt>/etc/ppp/kermit.ans</tt>):
|
||||
<verb>
|
||||
set line /dev/tty01
|
||||
set speed 19200
|
||||
set file type binary
|
||||
set file names literal
|
||||
set win 8
|
||||
set rec pack 1024
|
||||
set send pack 1024
|
||||
set block 3
|
||||
set term bytesize 8
|
||||
set command bytesize 8
|
||||
set flow none
|
||||
|
||||
pau 1
|
||||
out +++
|
||||
inp 5 OK
|
||||
out ATH0\13
|
||||
inp 5 OK
|
||||
echo \13
|
||||
out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable
|
||||
; autoanswer mod
|
||||
inp 5 OK
|
||||
echo \13
|
||||
exit
|
||||
</verb>
|
||||
|
||||
This <tt>/etc/ppp/kermit.dial</tt> script is used for dialing and authorizing
|
||||
on remote host. You will need to customize it for your needs.
|
||||
Put your login and password in this script , also you will need
|
||||
to change input statement depending on responses from your modem
|
||||
and remote host.
|
||||
<verb>
|
||||
;
|
||||
; put the com line attached to the modem here:
|
||||
;
|
||||
set line /dev/tty01
|
||||
;
|
||||
; put the modem speed here:
|
||||
;
|
||||
set speed 19200
|
||||
set file type binary ; full 8 bit file xfer
|
||||
set file names literal
|
||||
set win 8
|
||||
set rec pack 1024
|
||||
set send pack 1024
|
||||
set block 3
|
||||
set term bytesize 8
|
||||
set command bytesize 8
|
||||
set flow none
|
||||
set modem hayes
|
||||
set dial hangup off
|
||||
set carrier auto ; Then SET CARRIER if necessary,
|
||||
set dial display on ; Then SET DIAL if necessary,
|
||||
set input echo on
|
||||
set input timeout proceed
|
||||
set input case ignore
|
||||
def \%x 0 ; login prompt counter
|
||||
goto slhup
|
||||
|
||||
:slcmd ; put the modem in command mode
|
||||
echo Put the modem in command mode.
|
||||
clear ; Clear unread characters from input buffer
|
||||
pause 1
|
||||
output +++ ; hayes escape sequence
|
||||
input 1 OK\13\10 ; wait for OK
|
||||
if success goto slhup
|
||||
output \13
|
||||
pause 1
|
||||
output at\13
|
||||
input 1 OK\13\10
|
||||
if fail goto slcmd ; if modem doesn't answer OK, try again
|
||||
|
||||
:slhup ; hang up the phone
|
||||
clear ; Clear unread characters from input buffer
|
||||
pause 1
|
||||
echo Hanging up the phone.
|
||||
output ath0\13 ; hayes command for on hook
|
||||
input 2 OK\13\10
|
||||
if fail goto slcmd ; if no OK answer, put modem in command mode
|
||||
|
||||
:sldial ; dial the number
|
||||
pause 1
|
||||
echo Dialing.
|
||||
output atdt9,550311\13\10 ; put phone number here
|
||||
assign \%x 0 ; zero the time counter
|
||||
|
||||
:look
|
||||
clear ; Clear unread characters from input buffer
|
||||
increment \%x ; Count the seconds
|
||||
input 1 {CONNECT }
|
||||
if success goto sllogin
|
||||
reinput 1 {NO CARRIER\13\10}
|
||||
if success goto sldial
|
||||
reinput 1 {NO DIALTONE\13\10}
|
||||
if success goto slnodial
|
||||
reinput 1 {\255}
|
||||
if success goto slhup
|
||||
reinput 1 {\127}
|
||||
if success goto slhup
|
||||
if < \%x 60 goto look
|
||||
else goto slhup
|
||||
|
||||
:sllogin ; login
|
||||
assign \%x 0 ; zero the time counter
|
||||
pause 1
|
||||
echo Looking for login prompt.
|
||||
|
||||
:slloop
|
||||
increment \%x ; Count the seconds
|
||||
clear ; Clear unread characters from input buffer
|
||||
output \13
|
||||
;
|
||||
; put your expected login prompt here:
|
||||
;
|
||||
input 1 {Username: }
|
||||
if success goto sluid
|
||||
reinput 1 {\255}
|
||||
if success goto slhup
|
||||
reinput 1 {\127}
|
||||
if success goto slhup
|
||||
if < \%x 10 goto slloop ; try 10 times to get a login prompt
|
||||
else goto slhup ; hang up and start again if 10 failures
|
||||
|
||||
:sluid
|
||||
;
|
||||
; put your userid here:
|
||||
;
|
||||
output ppp-login\13
|
||||
input 1 {Password: }
|
||||
;
|
||||
; put your password here:
|
||||
;
|
||||
output ppp-password\13
|
||||
input 1 {Entering SLIP mode.}
|
||||
echo
|
||||
quit
|
||||
|
||||
:slnodial
|
||||
echo \7No dialtone. Check the telephone line!\7
|
||||
exit 1
|
||||
|
||||
; local variables:
|
||||
; mode: csh
|
||||
; comment-start: "; "
|
||||
; comment-start-skip: "; "
|
||||
; end:
|
||||
</verb>
|
||||
|
||||
<!--
|
||||
###################################################################
|
||||
Gennady B. Sorokopud ( gena@NetVision.net.il ) 24/10/94 12:00
|
||||
-->
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,208 +0,0 @@
|
||||
<!-- This is an SGML document in the linuxdoc DTD describing
|
||||
disk quotas under FreeBSD. By Mike Pritchard, 1996.
|
||||
|
||||
$Id: quotas.sgml,v 1.5 1997/02/22 12:59:12 peter Exp $
|
||||
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
||||
<article>
|
||||
<title> Disk quotas
|
||||
<author> Mike Pritchard <tt/mpp@FreeBSD.org/
|
||||
<date> 26 February 1996, (c) 1996
|
||||
|
||||
<abstract> This document describes configuration and administration
|
||||
of disk quotas under FreeBSD. </abstract>
|
||||
|
||||
<toc>
|
||||
-->
|
||||
|
||||
<chapt><heading>Disk quotas<label id="quotas"></heading>
|
||||
|
||||
<p><em>Contributed by &a.mpp;.<newline>26 February 1996</em>
|
||||
|
||||
Quotas are an optional feature of the operating system that allow
|
||||
you to limit the amount of disk space and/or the number of files
|
||||
a user, or members of a group, may allocate on a per-file system basis.
|
||||
This is used most often on timesharing systems where it is desirable
|
||||
to limit the amount of resources any one user or group of users may
|
||||
allocate. This will prevent one user from consuming all of
|
||||
the available disk space.
|
||||
|
||||
<sect><heading>Configuring your system to enable disk quotas</heading>
|
||||
|
||||
<p>Before attempting to use disk quotas it is
|
||||
necessary to make sure that quotas are configured in your kernel.
|
||||
This is done by adding the following line to your kernel configuration file:
|
||||
<verb>
|
||||
options QUOTA
|
||||
</verb>
|
||||
The stock GENERIC kernel does not have this enabled by default, so you
|
||||
will have to configure, build and install a custom kernel in order to use
|
||||
disk quotas. Please refer to the
|
||||
<ref id="kernelconfig" name="Configuring the FreeBSD Kernel">
|
||||
section for more information on kernel configuration.
|
||||
|
||||
<p>Next you will need to enable disk quotas in <tt>/etc/sysconfig</tt>.
|
||||
This is done by changing the line:
|
||||
<verb>
|
||||
quotas=NO
|
||||
</verb>
|
||||
to:
|
||||
<verb>
|
||||
quotas=YES
|
||||
</verb>
|
||||
|
||||
<p>Finally you will need to edit <tt>/etc/fstab</tt> to enable
|
||||
disk quotas on a per-file system basis. This is where you can
|
||||
either enable user or group quotas or both for all of your file
|
||||
systems.
|
||||
|
||||
<p>To enable per-user quotas on a file system, add the
|
||||
<tt>userquota</tt> option to the options field in the
|
||||
<tt>/etc/fstab</tt> entry for the file system you want to
|
||||
to enable quotas on. For example:
|
||||
<verb>
|
||||
/dev/sd1s2g /home ufs rw,userquota 1 2
|
||||
</verb>
|
||||
|
||||
<p>Similarly, to enable group quotas, use the <tt>groupquota</tt>
|
||||
option instead of the <tt>userquota</tt> keyword. To enable both
|
||||
user and group quotas, change the entry as follows:
|
||||
<verb>
|
||||
/dev/sd1s2g /home ufs rw,userquota,groupquota 1 2
|
||||
</verb>
|
||||
|
||||
<p>By default the quota files are stored in the root directory of the file
|
||||
system with the names <tt>quota.user</tt> and <tt>quota.group</tt>
|
||||
for user and group quotas respectively. See <tt>man fstab</tt> for more
|
||||
information. Even though that man page says that you can specify an
|
||||
alternate location for the quota files, this is not recommended since
|
||||
all of the various quota utilities do not seem to handle this
|
||||
properly.
|
||||
|
||||
<p>At this point you should reboot your system with your new kernel.
|
||||
<tt>/etc/rc</tt> will automatically run the appropriate commands to
|
||||
create the initial quota files for all of the quotas you enabled
|
||||
in <tt>/etc/fstab</tt>, so there is no need to manually create any
|
||||
zero length quota files.
|
||||
|
||||
<p>In the normal course of operations you should not be required
|
||||
to run the <tt>quotacheck</tt>, <tt>quotaon</tt>, or <tt>quotaoff</tt>
|
||||
commands manually. However, you may want to read their man pages
|
||||
just to be familiar with their operation.
|
||||
|
||||
<sect><heading>Setting quota limits</heading>
|
||||
|
||||
<p>Once you have configured your system to enable quotas, verify that
|
||||
they really are enabled. An easy way to do this is to run
|
||||
<tt>quota -v</tt>. You should see a one line summary of disk
|
||||
usage and current quota limits for each file system that
|
||||
quotas are enabled on.
|
||||
|
||||
<p>You are now ready to start assigning quota limits
|
||||
with the <tt>edquota</tt> command.
|
||||
|
||||
<p>You have several options on how to enforce limits on the amount of
|
||||
disk space a user or group may allocate, and how many files they may create.
|
||||
You may limit allocations based on disk space (block quotas) or
|
||||
number of files (inode quotas) or a combination of both.
|
||||
Each of these limits are further broken down into two categories: hard and
|
||||
soft limits.
|
||||
|
||||
<p>A hard limit may not be exceeded. Once a user reaches their hard
|
||||
limit they may not make any further allocations on the file system
|
||||
in question. For example, if the user has a hard limit of 500 blocks
|
||||
on a file system and is currently using 490 blocks, the user can only allocate
|
||||
an additional 10 blocks. Attempting to allocate an additional 11 blocks
|
||||
will fail.
|
||||
|
||||
<p>Soft limits on the other hand can be exceeded for a limited amount
|
||||
of time. This period of time is known as the grace period, which is
|
||||
one week by default. If a user stays over his or her soft limit longer
|
||||
than their grace period, the soft limit will turn into a hard limit
|
||||
and no further allocations will be allowed. When the user drops
|
||||
back below the soft limit, the grace period will be reset.
|
||||
|
||||
<p>The following is an example of what you might see when
|
||||
you run then <tt>edquota</tt> command. When the <tt>edquota</tt>
|
||||
command is invoked, you are placed into the editor specified by the
|
||||
<tt>EDITOR</tt> environment variable, or in the <tt>vi</tt> editor
|
||||
if the <tt>EDITOR</tt> variable is not set, to
|
||||
allow you to edit the quota limits.
|
||||
<verb>
|
||||
# edquota -u test
|
||||
Quotas for user test:
|
||||
/usr: blocks in use: 65, limits (soft = 50, hard = 75)
|
||||
inodes in use: 7, limits (soft = 50, hard = 60)
|
||||
/usr/var: blocks in use: 0, limits (soft = 50, hard = 75)
|
||||
inodes in use: 0, limits (soft = 50, hard = 60)
|
||||
</verb>
|
||||
You will normally see two lines for each file system that has
|
||||
quotas enabled. One line for the block limits, and one line
|
||||
for inode limits. Simply change the value you want updated
|
||||
to modify the quota limit. For example, to raise this users
|
||||
block limit from a soft limit of 50 and a hard limit of 75
|
||||
to a soft limit of 500 and a hard limit of 600, change:
|
||||
<verb>
|
||||
/usr: blocks in use: 65, limits (soft = 50, hard = 75)
|
||||
</verb>
|
||||
to:
|
||||
<verb>
|
||||
/usr: blocks in use: 65, limits (soft = 500, hard = 600)
|
||||
</verb>
|
||||
The new quota limits will be in place when you exit the editor.
|
||||
|
||||
<p>Sometimes it is desirable to set quota limits on a range
|
||||
of uids. This can be done by use of the <tt>-p</tt> option
|
||||
on the <tt>edquota</tt> command. First, assign the desired
|
||||
quota limit to a user, and then run
|
||||
<tt>edquota -p protouser startuid-enduid</tt>.
|
||||
For example, if user <tt>test</tt> has the desired quota
|
||||
limits, the following command can be used to duplicate
|
||||
those quota limits for uids 10,000 through 19,999:
|
||||
<verb>
|
||||
edquota -p test 10000-19999
|
||||
</verb>
|
||||
|
||||
<p>The ability to specify uid ranges was added to the system
|
||||
after 2.1 was released. If you need this feature on a 2.1
|
||||
system, you will need to obtain a newer copy of edquota.
|
||||
|
||||
<p>See <tt>man edquota</tt> for more detailed information.
|
||||
|
||||
<sect><heading>Checking quota limits and disk usage</heading>
|
||||
|
||||
<p>You can use either the <tt>quota</tt> or the <tt>repquota</tt>
|
||||
commands to check quota limits and disk usage. The <tt>quota</tt>
|
||||
command can be used to check individual user and group quotas and
|
||||
disk usage. Only the super-user may examine quotas and usage for
|
||||
other users, or for groups that they are not a member of.
|
||||
The <tt>repquota</tt> command can be used to get a summary of all
|
||||
quotas and disk usage for file systems with quotas enabled.
|
||||
|
||||
<p>The following is some sample output from the <tt>quota -v</tt>
|
||||
command for a user that has quota limits on two file systems.
|
||||
|
||||
<verb>
|
||||
Disk quotas for user test (uid 1002):
|
||||
Filesystem blocks quota limit grace files quota limit grace
|
||||
/usr 65* 50 75 5days 7 50 60
|
||||
/usr/var 0 50 75 0 50 60
|
||||
</verb>
|
||||
On the /usr file system in the above example this user is
|
||||
currently 15 blocks over their soft limit of 50 blocks and has 5 days of
|
||||
their grace period left. Note the asterisk (*) which indicates that
|
||||
the user is currently over their quota limit.
|
||||
|
||||
<p>Normally file systems that the user is not using any disk space
|
||||
on will not show up in the output from the <tt>quota</tt> command,
|
||||
even if they have a quota limit assigned for that file system.
|
||||
The <tt>-v</tt> option will display those file systems, such as
|
||||
the <tt>/usr/var</tt> file system in the above example.
|
||||
|
||||
<sect><heading>* Quotas over NFS</heading>
|
||||
|
||||
<p>This section is still under development.
|
||||
|
||||
@ -1,587 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'>
|
||||
<linuxdoc><book><chapt>foo
|
||||
-->
|
||||
<sect><heading>About the current release<label id="relnotes"></heading>
|
||||
|
||||
<p>FreeBSD is a freely available, full source 4.4BSD-Lite
|
||||
based release for Intel i386/i486/Pentium/PentiumPro (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 in January of 95, 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 hundreds of commonly
|
||||
sought-after programs. At the beginning of December 96 there were
|
||||
more than 700 ports ! 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
|
||||
all'' followed by ``make install'' after successful
|
||||
compilation 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
|
||||
<bf>/usr/share/doc</bf> directory on any machine running
|
||||
FreeBSD 2.1 or later. You may view the
|
||||
manuals with any HTML capable browser with the
|
||||
following URLs:
|
||||
|
||||
<descrip>
|
||||
<tag>The FreeBSD handbook</tag>
|
||||
<htmlurl url="file:/usr/share/doc/handbook/handbook.html">
|
||||
|
||||
<tag>The FreeBSD FAQ</tag>
|
||||
<htmlurl url="file:/usr/share/doc/FAQ/FAQ.html">
|
||||
</descrip>
|
||||
|
||||
You can also visit the master (and most frequently
|
||||
updated) copies at <htmlurl
|
||||
url="http://www.freebsd.org"
|
||||
name="http://www.freebsd.org">.
|
||||
|
||||
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 <htmlurl
|
||||
url="../FAQ/FAQ.html" name="FreeBSD FAQ">.
|
||||
|
||||
If password security for FreeBSD is all you need, and
|
||||
you have no requirement for copying encrypted passwords
|
||||
from different hosts (Suns, DEC machines, etc) into
|
||||
FreeBSD password entries, then FreeBSD's MD5 based
|
||||
security may be all you require! We feel that our
|
||||
default security model is more than a match for DES,
|
||||
and without any messy export issues to deal with. If
|
||||
you are outside (or even inside) the U.S., give it a
|
||||
try!
|
||||
|
||||
<![ IGNORE [
|
||||
<p>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 <tt>pkg_add(1)</tt> command for those who do not
|
||||
wish to compile their own ports from source. See <ref
|
||||
id="ports" name="The Ports Collection"> for a more
|
||||
complete description.
|
||||
|
||||
<!-- XXX make xref
|
||||
For a list of contributors and a general project
|
||||
description, please see the file "CONTRIB.FreeBSD"
|
||||
which should be bundled with your binary distribution.
|
||||
|
||||
Also see the "REGISTER.FreeBSD" file for information on
|
||||
registering with the "Free BSD user counter". This
|
||||
counter is for ALL freely available variants of BSD,
|
||||
not just FreeBSD, and we urge you to register yourself
|
||||
with it.
|
||||
-->
|
||||
|
||||
The core of FreeBSD does not contain DES code which
|
||||
would inhibit its being exported outside the United
|
||||
States. 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 <url
|
||||
url="http://www.freebsd.org/FAQ" name="FreeBSD
|
||||
FAQ">. 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!
|
||||
|
||||
<sect1><heading>New feature highlights</heading>
|
||||
|
||||
<p>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.
|
||||
|
||||
<sect2><heading>Kernel</heading>
|
||||
|
||||
<p>
|
||||
<descrip>
|
||||
|
||||
<tag>Merged VM-File Buffer Cache</tag> 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: &a.davidg; and &a.dyson;
|
||||
|
||||
<tag>Network PCB hash optimization</tag> 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: &a.davidg;
|
||||
|
||||
<tag>Name cache optimization</tag> 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: &a.phk; and &a.davidg;
|
||||
|
||||
<tag>Less restrictive swap-spaces</tag> The need
|
||||
to compile the names of the swap devices into
|
||||
the kernel has been removed. Now
|
||||
<tt>swapon(8)</tt> will accept any block
|
||||
devices, up to the maximum number of swap
|
||||
devices configured in the kernel.
|
||||
|
||||
Owner: &a.phk; and &a.davidg;
|
||||
|
||||
<tag>Hard Wired SCSI Devices</tag> 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 <tt>scsi(4)</tt> man
|
||||
page or the LINT kernel config file.
|
||||
|
||||
Owner: &a.dufault;
|
||||
|
||||
Sources involved: <tt>sys/scsi/*</tt>
|
||||
<tt>usr.sbin/config/*</tt>
|
||||
|
||||
<tag>Slice Support</tag> FreeBSD now supports a
|
||||
<em>slice</em> abstraction which enhances
|
||||
FreeBSD's ability to share disks with other
|
||||
operating systems. This support will allow
|
||||
FreeBSD to inhabit DOS extended partitions.
|
||||
|
||||
Owner: &a.bde;
|
||||
|
||||
Sources involved: <tt>sys/disklabel.h</tt>
|
||||
<tt>sys/diskslice.h</tt> <tt>sys/dkbad.h</tt>
|
||||
<tt>kern/subr_diskslice.c</tt> <tt>kern/subr_dkbad.c</tt>
|
||||
<tt>i386/isa/diskslice_machdep.c</tt> <tt>i386/isa/wd.c</tt>
|
||||
<tt>scsi/sd.c</tt> <tt>dev/vn/vn.c</tt>
|
||||
|
||||
<tag>Support for Ontrack Disk Manager Version 6.0</tag>
|
||||
Support has been added for disks
|
||||
which use Ontrack Disk Manager. The fdisk
|
||||
program does <em>not</em> 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: &a.phk;
|
||||
|
||||
<tag>Bad144 is back and working</tag> 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: &a.bde; and &a.phk;
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect2><heading>New device support</heading>
|
||||
|
||||
<sect3><heading>SCSI and CDROM devices</heading>
|
||||
|
||||
<p><descrip>
|
||||
|
||||
<tag>Matsushita/Panasonic (Creative) CD-ROM driver</tag>
|
||||
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: &a.uhclem;
|
||||
|
||||
Sources involved: <tt>isa/matcd</tt>
|
||||
|
||||
<tag>Adaptec 2742/2842/2940 SCSI driver</tag> 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
|
||||
<em>experimental</em> tagged queuing support has
|
||||
been added (kernel option
|
||||
<tt>AHC_TAGENABLE</tt>). John Aycock has also
|
||||
released the sequencer code under a Berkeley
|
||||
style copyright making the driver entirely clean
|
||||
of the GPL.
|
||||
|
||||
Owner: &a.gibbs;
|
||||
|
||||
Sources involved: <tt>isa/aic7770.c</tt> <tt>pci/aic7870.c</tt>
|
||||
<tt>i386/scsi/*</tt> <tt>sys/dev/aic7xxx/*</tt>
|
||||
|
||||
<tag>NCR5380/NCR53400 SCSI (ProAudio Spectrum) driver</tag>
|
||||
Owner: &a.core;
|
||||
|
||||
Submitted by: Serge Vakulenko (vak@cronyx.ru)
|
||||
|
||||
Sources involved: <tt>isa/ncr5380.c</tt>
|
||||
|
||||
<tag>Sony CDROM driver</tag> Owner: &a.core;
|
||||
|
||||
Submitted by: Mikael Hybsch (micke@dynas.se)
|
||||
|
||||
Sources involved: <tt>isa/scd.c</tt>
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect3><heading>Serial devices</heading>
|
||||
|
||||
<p><descrip>
|
||||
|
||||
<tag>SDL Communications Riscom/8 Serial Board Driver</tag>
|
||||
Owner: &a.ache;
|
||||
|
||||
Sources involved: <tt>isa/rc.c</tt> <tt>isa/rcreg.h</tt>
|
||||
|
||||
<tag>Cyclades Cyclom-y Serial Board Driver</tag>
|
||||
Owner: &a.bde;
|
||||
|
||||
Submitted by: Andrew Werple
|
||||
(andrew@werple.apana.org.au) and Heikki Suonsivu
|
||||
(hsu@cs.hut.fi)
|
||||
|
||||
Obtained from: NetBSD
|
||||
|
||||
Sources involved: <tt>isa/cy.c</tt>
|
||||
|
||||
<tag>Cronyx/Sigma sync/async serial driver</tag>
|
||||
Owner: &a.core;
|
||||
|
||||
Submitted by: Serge Vakulenko
|
||||
|
||||
Sources involved: <tt>isa/cronyx.c</tt>
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect2><heading>Networking</heading>
|
||||
|
||||
<p><descrip>
|
||||
|
||||
<tag>Diskless booting</tag> Diskless booting in 2.0.5
|
||||
is much improved over previous releases. The boot
|
||||
program is in <tt>src/sys/i386/boot/netboot</tt>,
|
||||
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.
|
||||
|
||||
<tag>DEC DC21140 Fast Ethernet driver</tag> This
|
||||
driver supports any of the numerous NICs using the
|
||||
DC21140 chipset including the 100Mb DEC DE-500-XA
|
||||
and SMC 9332.
|
||||
|
||||
Owner: &a.core;
|
||||
|
||||
Submitted by: Matt Thomas (thomas@lkg.dec.com)
|
||||
|
||||
Sources involved: <tt>pci/if_de.c</tt> <tt>pci/dc21040.h</tt>
|
||||
|
||||
|
||||
<tag>DEC FDDI (DEFPA/DEFEA) driver</tag> Owner: &a.core;
|
||||
|
||||
Submitted by: Matt Thomas (thomas@lkg.dec.com)
|
||||
|
||||
Sources involved: <tt>pci/if_pdq.c</tt> <tt>pci/pdq.c</tt>
|
||||
<tt>pci/pdq_os.h</tt> <tt>pci/pdqreg.h</tt>
|
||||
|
||||
|
||||
<tag>3Com 3c505 (Etherlink/+) NIC driver</tag> Owner:
|
||||
&a.core;
|
||||
|
||||
Submitted by: Dean Huxley (dean@fsa.ca)
|
||||
|
||||
Obtained from: NetBSD
|
||||
|
||||
Sources involved: <tt>isa/if_eg.c</tt>
|
||||
|
||||
|
||||
<tag>Fujitsu MB86960A family of NICs driver</tag>
|
||||
Owner: &a.core;
|
||||
|
||||
Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp)
|
||||
|
||||
Sources involved: <tt>isa/if_fe.c</tt>
|
||||
|
||||
|
||||
<tag>Intel EtherExpress driver</tag> Owner: Rodney
|
||||
W. Grimes (rgrimes@FreeBSD.org)
|
||||
|
||||
Sources involved: <tt>isa/if_ix.c</tt> <tt>isa/if_ixreg.h</tt>
|
||||
|
||||
|
||||
<tag>3Com 3c589 driver</tag> 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: <tt>isa/if_zp.c</tt>
|
||||
|
||||
|
||||
<tag>IBM Credit Card Adapter driver</tag> Owner: &a.core;
|
||||
|
||||
Submitted by: "HOSOKAWA Tatsumi"
|
||||
(hosokawa@mt.cs.keio.ac.jp),
|
||||
|
||||
Sources involved: <tt>isa/pcic.c</tt> <tt>isa/pcic.h</tt>
|
||||
|
||||
|
||||
<tag>EDSS1 and 1TR6 ISDN interface driver</tag>
|
||||
Owner: &a.core;
|
||||
|
||||
Submitted by: Dietmar Friede
|
||||
(dfriede@drnhh.neuhaus.de) and Juergen Krause
|
||||
(jkr@saarlink.de)
|
||||
|
||||
Sources involved: <tt>gnu/isdn/*</tt>
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect2><heading>Miscellaneous drivers</heading>
|
||||
|
||||
<p><descrip>
|
||||
|
||||
<tag>Joystick driver</tag> Owner: &a.jmz;
|
||||
|
||||
Sources involved: <tt>isa/joy.c</tt>
|
||||
|
||||
<tag>National Instruments ``LabPC'' driver</tag> Owner:
|
||||
&a.dufault;
|
||||
|
||||
Sources involved: <tt>isa/labpc.c</tt>
|
||||
|
||||
<tag>WD7000 driver</tag> Owner: Olof Johansson
|
||||
(offe@ludd.luth.se)
|
||||
|
||||
<tag>Pcvt Console driver</tag> Owner: &a.joerg;
|
||||
|
||||
Submitted by: &a.hm;
|
||||
|
||||
Sources involved: <tt>isa/pcvt/*</tt>
|
||||
|
||||
<tag>BSD-audio emulator for VAT driver</tag> Owner:
|
||||
Amancio Hasty (ahasty@FreeBSD.org) and
|
||||
&a.pst;
|
||||
|
||||
Sources involved: <tt>isa/sound/vat_audio.c</tt>
|
||||
<tt>isa/sound/vat_audioio.h</tt>
|
||||
|
||||
<tag>National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver</tag>
|
||||
Owner: &a.core;
|
||||
|
||||
Submitted by: Fred Cawthorne
|
||||
(fcawth@delphi.umd.edu)
|
||||
|
||||
Sources involved: <tt>isa/gpib.c</tt> <tt>isa/gpib.h</tt>
|
||||
<tt>isa/gpibreg.h</tt>
|
||||
|
||||
<tag>Genius GS-4500 hand scanner driver</tag> Owner:
|
||||
&a.core;
|
||||
|
||||
Submitted by: Gunther Schadow
|
||||
(gusw@fub46.zedat.fu-berlin.de)
|
||||
|
||||
Sources involved: <tt>isa/gsc.c</tt> <tt>isa/gscreg.h</tt>
|
||||
|
||||
<tag>CORTEX-I Frame Grabber</tag> Owner: &a.core;
|
||||
|
||||
Submitted by: Paul S. LaFollette, Jr. (
|
||||
|
||||
Sources involved: <tt>isa/ctx.c</tt> <tt>isa/ctxreg.h</tt>
|
||||
|
||||
|
||||
<tag>Video Spigot video capture card</tag> Owner: Jim
|
||||
Lowe
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect1><heading>Experimental features</heading>
|
||||
|
||||
<p><descrip>
|
||||
|
||||
<tag>UNIONFS and LFS</tag> 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.
|
||||
|
||||
<tag>iBCS2 Support</tag> 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: &a.sos; and &a.sef;
|
||||
|
||||
Sources involved: <tt>sys/i386/ibcs2/*</tt> and misc
|
||||
kernel changes.
|
||||
|
||||
</descrip>
|
||||
<!--
|
||||
<sect1><heading>Reporting problems, making suggestions, submitting code</heading>
|
||||
|
||||
<p>Your suggestions, bug reports and contributions of code
|
||||
are always valued - please do not hesitate to report any
|
||||
problems you may find (preferably with a fix attached if
|
||||
you can!).
|
||||
|
||||
The preferred method to submit bug reports from a machine
|
||||
with Internet mail connectivity is to use the send-pr
|
||||
command. Bug reports will be dutifully filed by our
|
||||
faithful bug-filer program and you can be sure that we will
|
||||
do our best to respond to all reported bugs as soon as
|
||||
possible.
|
||||
|
||||
If, for some reason, you are unable to use the send-pr
|
||||
command to submit a bug report, you can try to send it
|
||||
to: <tscreen>bugs@FreeBSD.org</tscreen> Otherwise, for
|
||||
any questions or suggestions, please send mail to:
|
||||
<tscreen>questions@FreeBSD.org</tscreen>
|
||||
|
||||
Additionally, being a volunteer effort, we are always
|
||||
happy to have extra hands willing to help - there are
|
||||
already far more enhancements to be done than we can ever
|
||||
manage to do by ourselves! To contact us on technical
|
||||
matters, or with offers of help, you may send mail to:
|
||||
<tscreen>hackers@FreeBSD.org</tscreen>
|
||||
|
||||
Since these mailing lists can experience significant
|
||||
amounts of traffic, if you have slow or expensive mail
|
||||
access and you are only interested in keeping up with
|
||||
significant FreeBSD events, you may find it preferable to
|
||||
subscribe to: <tscreen>announce@FreeBSD.org</tscreen>
|
||||
|
||||
All but the freebsd-bugs groups can be freely joined by
|
||||
anyone wishing to do so. Send mail to &a.majordomo
|
||||
and include the keyword `help' on a
|
||||
line by itself somewhere in the body of the message.
|
||||
This will give you more information on joining the
|
||||
various lists, accessing archives, etc. There are a
|
||||
number of mailing lists targeted at special interest
|
||||
groups not mentioned here, so send mail to majordomo and
|
||||
ask about them!
|
||||
|
||||
-->
|
||||
]]>
|
||||
@ -1,279 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
||||
|
||||
<sect><heading>Gateways and routes<label id="routing"></heading>
|
||||
|
||||
<p><em>Contributed by &a.gryphon;.<newline>6 October 1995.</em>
|
||||
|
||||
For one machine to be able to find another, there must be a
|
||||
mechanism in place to describe how to get from one to the
|
||||
other. This is called Routing. A ``route'' is a defined
|
||||
pair of addresses: a <bf>destination</bf> and a
|
||||
<bf>gateway</bf>. The pair indicates that if you are
|
||||
trying to get to this <em>destination</em>, send along
|
||||
through this <em>gateway</em>. There are three types of
|
||||
destinations: individual hosts, subnets, and ``default''. The
|
||||
``default route'' is used if none of the other routes
|
||||
apply. We will talk a little bit more about default routes
|
||||
later on. There are also three types of gateways:
|
||||
individual hosts, interfaces (also called ``links''), and
|
||||
ethernet hardware addresses.
|
||||
|
||||
<sect1><heading>An example</heading>
|
||||
|
||||
<p>To illustrate different aspects of routing, we will use
|
||||
the following example which is the output of the command
|
||||
<tt>netstat -r</tt>:
|
||||
|
||||
<tscreen><verb>
|
||||
Destination Gateway Flags Refs Use Netif Expire
|
||||
|
||||
default outside-gw UGSc 37 418 ppp0
|
||||
localhost localhost UH 0 181 lo0
|
||||
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
|
||||
10.20.30.255 link#1 UHLW 1 2421
|
||||
foobar.com link#1 UC 0 0
|
||||
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
|
||||
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
|
||||
host2.foobar.com link#1 UC 0 0
|
||||
224 link#1 UC 0 0
|
||||
</verb></tscreen>
|
||||
|
||||
The first two lines specify the default route (which we
|
||||
will cover in the next section) and the <tt>localhost</tt> route.
|
||||
|
||||
The interface (<tt>Netif</tt> column) that it specifies to use
|
||||
for <tt>localhost</tt> is <tt>lo0</tt>, also known as the
|
||||
loopback device. This says to keep all traffic for this
|
||||
destination internal, rather than sending it out over the
|
||||
LAN, since it will only end up back where it started
|
||||
anyway.
|
||||
|
||||
The next thing that stands out are the
|
||||
``<tt>0:e0:...</tt>'' addresses. These are ethernet
|
||||
hardware addresses. FreeBSD will automatically identify any
|
||||
hosts (<tt>test0</tt> in the example) on the local ethernet and
|
||||
add a route for that host, directly to it over the ethernet
|
||||
interface, <tt>ed0</tt>. There is also a timeout
|
||||
(<tt>Expire</tt> column) associated with this type of route,
|
||||
which is used if we fail to hear from the host in a
|
||||
specific amount of time. In this case the route will be
|
||||
automatically deleted. These hosts are identified using a
|
||||
mechanism known as RIP (Routing Information Protocol),
|
||||
which figures out routes to local hosts based upon a
|
||||
shortest path determination.
|
||||
|
||||
FreeBSD will also add subnet routes for the local subnet
|
||||
(<tt>10.20.30.255</tt> is the broadcast address for the subnet
|
||||
<tt>10.20.30</tt>, and <tt>foobar.com</tt> is the domain name
|
||||
associated with that subnet). The designation <tt>link#1</tt>
|
||||
refers to the first ethernet card in the machine. You will
|
||||
notice no additional interface is specified for those.
|
||||
|
||||
Both of these groups (local network hosts and local
|
||||
subnets) have their routes automatically configured by a
|
||||
daemon called <tt>routed</tt>. If this is not run, then only
|
||||
routes which are statically defined (ie. entered
|
||||
explicitly) will exist.
|
||||
|
||||
The <tt>host1</tt> line refers to our host, which it knows by
|
||||
ethernet address. Since we are the sending host, FreeBSD
|
||||
knows to use the loopback interface (<tt>lo0</tt>) rather than
|
||||
sending it out over the ethernet interface.
|
||||
|
||||
The two <tt>host2</tt> lines are an example of what happens
|
||||
when we use an ifconfig alias (see the section of ethernet
|
||||
for reasons why we would do this). The <tt>=></tt>
|
||||
symbol after the <tt>lo0</tt> interface says that not only are
|
||||
we using the loopback (since this is address also refers to
|
||||
the local host), but specifically it is an alias. Such
|
||||
routes only show up on the host that supports the alias;
|
||||
all other hosts on the local network will simply have a
|
||||
<tt>link#1</tt> line for such.
|
||||
|
||||
The final line (destination subnet <tt>224</tt>) deals with
|
||||
MultiCasting, which will be covered in a another section.
|
||||
|
||||
The other column that we should talk about are the
|
||||
<tt>Flags</tt>. Each route has different attributes that are
|
||||
described in the column. Below is a short table of some of
|
||||
these flags and their meanings:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/U/ <bf/Up:/ The route is active.
|
||||
|
||||
<tag/H/ <bf/Host:/ The route destination is a single host.
|
||||
|
||||
<tag/G/ <bf/Gateway:/ Send anything for this destination
|
||||
on to this remote system, which will figure out from
|
||||
there where to send it.
|
||||
|
||||
<tag/S/ <bf/Static:/ This route was configured manually,
|
||||
not automatically generated by the system.
|
||||
|
||||
<tag/C/ <bf/Clone:/ Generates a new route based upon this
|
||||
route for machines we connect to. This type of route is
|
||||
normally used for local networks.
|
||||
|
||||
<tag/W/ <bf/WasCloned/ Indicated a route that was
|
||||
auto-configured based upon a local area network (Clone)
|
||||
route.
|
||||
|
||||
<tag/L/ <bf/Link:/ Route involves references to ethernet
|
||||
hardware.
|
||||
|
||||
</descrip>
|
||||
|
||||
|
||||
<sect1><heading>Default routes</heading>
|
||||
|
||||
<p>When the local system needs to make a connection to
|
||||
remote host, it checks the routing table to determine if
|
||||
a known path exists. If the remote host falls into a
|
||||
subnet that we know how to reach (Cloned routes), then
|
||||
the system checks to see if it can connect along that
|
||||
interface.
|
||||
|
||||
If all known paths fail, the system has one last option:
|
||||
the <bf>default</bf> route. This route is a special type
|
||||
of gateway route (usually the only one present in the
|
||||
system), and is always marked with a ``<tt>c</tt>'' in
|
||||
the flags field. For hosts on a local area network, this
|
||||
gateway is set to whatever machine has a direct
|
||||
connection to the outside world (whether via PPP link, or
|
||||
your hardware device attached to a dedicated data line).
|
||||
|
||||
If you are configuring the default route for a machine
|
||||
which itself is functioning as the gateway to the outside
|
||||
world, then the default route will be the gateway machine
|
||||
at your Internet Service Provider's (ISP) site.
|
||||
|
||||
Let us look at an example of default routes. This is a
|
||||
common configuration:
|
||||
<tscreen><verb>
|
||||
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
|
||||
</verb></tscreen>
|
||||
|
||||
The hosts <tt>Local1</tt> and <tt>Local2</tt> are at your
|
||||
site, with the formed being your PPP connection to your
|
||||
ISP's Terminal Server. Your ISP has a local network at
|
||||
their site, which has, among other things, the server
|
||||
where you connect and a hardware device (T1-GW) attached
|
||||
to the ISP's Internet feed.
|
||||
|
||||
The default routes for each of your machines will be:
|
||||
|
||||
<tscreen><verb>
|
||||
host default gateway interface
|
||||
---- --------------- ---------
|
||||
Local2 Local1 ethernet
|
||||
Local1 T1-GW PPP
|
||||
</verb></tscreen>
|
||||
|
||||
A common question is ``Why (or how) would we set the
|
||||
T1-GW to be the default gateway for Local1, rather than
|
||||
the ISP server it is connected to?''.
|
||||
|
||||
Remember, since the PPP interface is using an address on
|
||||
the ISP's local network for your side of the connection,
|
||||
routes for any other machines on the ISP's local network
|
||||
will be automatically generated. Hence, you will already
|
||||
know how to reach the T1-GW machine, so there is no need
|
||||
for the intermediate step of sending traffic to the ISP
|
||||
server.
|
||||
|
||||
As a final note, it is common to use the address ``<tt>...1</tt>''
|
||||
as the gateway address for your local network. So (using
|
||||
the same example), if your local class-C address space
|
||||
was <tt>10.20.30</tt> and your ISP was using <tt>10.9.9</tt> then the
|
||||
default routes would be:
|
||||
|
||||
<tscreen><verb>
|
||||
Local2 (10.20.30.2) --> Local1 (10.20.30.1)
|
||||
Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>Dual homed hosts</heading>
|
||||
|
||||
<p>There is one other type of configuration that we should
|
||||
cover, and that is a host that sits on two different
|
||||
networks. Technically, any machine functioning as a
|
||||
gateway (in the example above, using a PPP connection)
|
||||
counts as a dual-homed host. But the term is really only
|
||||
used to refer to a machine that sits on two local-area
|
||||
networks.
|
||||
|
||||
In one case, the machine as two ethernet cards, each
|
||||
having an address on the separate subnets. Alternately,
|
||||
the machine may only have one ethernet card, and be using
|
||||
ifconfig aliasing. The former is used if two physically
|
||||
separate ethernet networks are in use, the latter if
|
||||
there is one physical network segment, but two logically
|
||||
separate subnets.
|
||||
|
||||
Either way, routing tables are set up so that each subnet
|
||||
knows that this machine is the defined gateway (inbound
|
||||
route) to the other subnet. This configuration, with the
|
||||
machine acting as a Bridge between the two subnets, is
|
||||
often used when we need to implement packet filtering or
|
||||
firewall security in either or both directions.
|
||||
|
||||
<sect1><heading>Routing propagation</heading>
|
||||
|
||||
<p>We have already talked about how we define our routes to
|
||||
the outside world, but not about how the outside world
|
||||
finds us.
|
||||
|
||||
We already know that routing tables can be set up so that
|
||||
all traffic for a particular address space (in our
|
||||
examples, a class-C subnet) can be sent to a particular
|
||||
host on that network, which will forward the packets
|
||||
inbound.
|
||||
|
||||
When you get an address space assigned to your site, your
|
||||
service provider will set up their routing tables so that
|
||||
all traffic for your subnet will be sent down your PPP
|
||||
link to your site. But how do sites across the country
|
||||
know to send to your ISP?
|
||||
|
||||
There is a system (much like the distributed DNS
|
||||
information) that keeps track of all assigned
|
||||
address-spaces, and defines their point of connection to
|
||||
the Internet Backbone. The ``Backbone'' are the main
|
||||
trunk lines that carry Internet traffic across the
|
||||
country, and around the world. Each backbone machine has
|
||||
a copy of a master set of tables, which direct traffic
|
||||
for a particular network to a specific backbone carrier,
|
||||
and from there down the chain of service providers until
|
||||
it reaches your network.
|
||||
|
||||
It is the task of your service provider to advertise to
|
||||
the backbone sites that they are the point of connection
|
||||
(and thus the path inward) for your site. This is known
|
||||
as route propagation.
|
||||
|
||||
<!--
|
||||
<sect1><heading>Multicast Routing</heading>
|
||||
-->
|
||||
|
||||
<sect1><heading>Troubleshooting</heading>
|
||||
|
||||
<p>Sometimes, there is a problem with routing propagation,
|
||||
and some sites are unable to connect to you. Perhaps the
|
||||
most useful command for trying to figure out where a
|
||||
routing is breaking down is the <tt>traceroute(8)</tt>
|
||||
command. It is equally useful if you cannot seem to make
|
||||
a connection to a remote machine (ie. <tt>ping(8)</tt>
|
||||
fails).
|
||||
|
||||
The <tt>traceroute(8)</tt> command is run with the name
|
||||
of the remote host you are trying to connect to. It will
|
||||
show the gateway hosts along the path of the attempt,
|
||||
eventually either reaching the target host, or
|
||||
terminating because of a lack of connection.
|
||||
|
||||
For more information, see the manual page for
|
||||
<tt>traceroute(8)</tt>.
|
||||
|
||||
@ -1,195 +0,0 @@
|
||||
<!-- $Id: russian.sgml,v 1.3 1997/05/02 08:07:35 ache Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Russian Language (KOI8-R encoding)<label id="russian"></heading>
|
||||
<p><em>Contributed by &a.ache;<newline>
|
||||
1 May 1997</em>.
|
||||
<p>See more info about KOI8-R encoding at
|
||||
<htmlurl url="http://www.nagual.pp.ru/~ache/koi8.html"
|
||||
name="KOI8-R References (Russian Net Character Set)">.
|
||||
|
||||
<sect1><heading>Console Setup<label id="russian:console"></heading>
|
||||
<p>
|
||||
<enum>
|
||||
<item>Russian console entry in <tt>/etc/rc.conf</tt> should looks like
|
||||
<verb>
|
||||
keymap=ru.koi8-r
|
||||
keychange="61 ^[[K"
|
||||
scrnmap=koi8-r2cp866
|
||||
font8x16=cp866b-8x16
|
||||
font8x14=cp866-8x14
|
||||
font8x8=cp866-8x8
|
||||
</verb>
|
||||
<p>
|
||||
<it>NOTE:</it> ^[ means that real ESC character must be entered into
|
||||
<tt>/etc/rc.conf</tt>,
|
||||
not just ^[ string.
|
||||
<p>
|
||||
This tuning means KOI8-R keyboard with Alternative
|
||||
screen font mapped to KOI8-R encoding to
|
||||
preserve pseudographics, <it>Gray Delete</it> key remapped to match Russian
|
||||
<tt>termcap(5)</tt> entry for FreeBSD console.
|
||||
<p>
|
||||
RUS/LAT switch will be <bf>CapsLock</bf>. Old CapsLock function still
|
||||
available via <bf>Shift+CapsLock</bf>. CapsLock LED will
|
||||
indicate RUS mode, not CapsLock mode.
|
||||
|
||||
<item>For each <tt>ttyv?</tt> entry in <tt>/etc/ttys</tt>
|
||||
change terminal type from <tt>cons25</tt> to
|
||||
<tt>cons25r</tt>, i.e. each entry should looks like
|
||||
<verb>
|
||||
ttyv0 "/usr/libexec/getty Pc" cons25r on secure
|
||||
</verb>
|
||||
</enum>
|
||||
|
||||
<sect1><heading>Locale Setup<label id="russian:locale"></heading>
|
||||
<p><label id="russian:env">
|
||||
There is two environment variables for locale setup:
|
||||
<itemize>
|
||||
<item><tt>LANG</tt>
|
||||
for POSIX <tt>setlocale(3)</tt> family functions;
|
||||
<item><tt>MM_CHARSET</tt>
|
||||
for applications MIME chararter set.
|
||||
</itemize>
|
||||
<p>
|
||||
The best way is using <tt>/etc/login.conf</tt>
|
||||
<tt>russian</tt> user's login class
|
||||
in <tt>passwd(5)</tt> entry login class position.
|
||||
See <tt>login.conf(5)</tt> for details.
|
||||
|
||||
<sect2><heading>Login Class Method<label id="russian:class"></heading>
|
||||
<p>
|
||||
First of all check your <tt>/etc/login.conf</tt> have
|
||||
<tt>russian</tt> login class, this entry may looks like:
|
||||
<verb>
|
||||
russian:Russian Users Accounts:\
|
||||
:charset=KOI8-R:\
|
||||
:lang=ru_RU.KOI8-R:\
|
||||
:tc=default:
|
||||
</verb>
|
||||
|
||||
<sect3><heading>How to do it with vipw(8)</heading>
|
||||
<p>
|
||||
If you use <tt>vipw(8)</tt> for adding new users,
|
||||
<tt>/etc/master.passwd</tt>
|
||||
entry should looks like:
|
||||
<verb>
|
||||
user:password:1111:11:russian:0:0:User Name:/home/user:/bin/csh
|
||||
</verb>
|
||||
|
||||
<sect3><heading>How to do it with adduser(8)</heading>
|
||||
<p>
|
||||
If you use <tt>adduser(8)</tt> for adding new users:
|
||||
<itemize>
|
||||
<item>Set
|
||||
<verb>
|
||||
defaultclass = russian
|
||||
</verb>
|
||||
in <tt>/etc/adduser.conf</tt>
|
||||
(you must enter <tt>default</tt> class for all non-Russian
|
||||
users in this case);
|
||||
<newline><newline>
|
||||
|
||||
<item>Alternative variant will be answering <tt>russian</tt>
|
||||
each time when you see
|
||||
<verb>
|
||||
Enter login class: default []:
|
||||
</verb>
|
||||
prompt from <tt>adduser(8)</tt>;
|
||||
<newline><newline>
|
||||
|
||||
<item>Another variant: call
|
||||
<verb>
|
||||
# adduser -class russian
|
||||
</verb>
|
||||
for each Russian user you want to add.
|
||||
</itemize>
|
||||
|
||||
<sect3><heading>How to do it with pw(8)</heading>
|
||||
<p>
|
||||
If you use <tt>pw(8)</tt> for adding new users, call it in this form:
|
||||
<verb>
|
||||
# pw useradd user_name -L russian
|
||||
</verb>
|
||||
|
||||
<sect2><heading>Shell Startup Files Method</heading>
|
||||
<p>
|
||||
If you don't want to use
|
||||
<ref id="russian:class" name="login class method">
|
||||
for some reasons, just set
|
||||
this
|
||||
<ref id="russian:env" name="two environment variables">
|
||||
in the following shell startup files:
|
||||
<itemize>
|
||||
<item><tt>/etc/profile</tt>:
|
||||
<verb>
|
||||
LANG=ru_RU.KOI8-R; export LANG
|
||||
MM_CHARSET=KOI8-R; export MM_CHARSET
|
||||
</verb>
|
||||
|
||||
<item><tt>/etc/csh.login</tt>:
|
||||
<verb>
|
||||
setenv LANG ru_RU.KOI8-R
|
||||
setenv MM_CHARSET KOI8-R
|
||||
</verb>
|
||||
</itemize>
|
||||
<p>
|
||||
Alternatively you can add this instructions to
|
||||
<itemize>
|
||||
<item><tt>/usr/share/skel/dot.profile</tt>:
|
||||
<p>
|
||||
(similar to <tt>/etc/profile</tt> above);
|
||||
|
||||
<item><tt>/usr/share/skel/dot.login</tt>:
|
||||
<p>
|
||||
(similar to <tt>/etc/csh.login</tt> above).
|
||||
</itemize>
|
||||
|
||||
<sect1><heading>X Window Setup<label id="russian:xwindow"></heading>
|
||||
<p>
|
||||
Step by step instructions:
|
||||
<enum>
|
||||
<item>Do
|
||||
<ref id="russian:locale" name="locale setup"> first as described.
|
||||
<p>
|
||||
<it>NOTE:</it><label id="russian:note">
|
||||
Russian KOI8-R locale may not work with old XFree86 versions
|
||||
(lower than 3.2.1 + locale/keyboard patches).
|
||||
XFree86 port from <tt>/usr/ports/x11/XFree86</tt> already have
|
||||
all neccessary patches, so it will work, if you install XFree86
|
||||
from this port.
|
||||
Basically, XFree86 version shipped with latest FreeBSD distribution should
|
||||
work too unless somebody forget to apply port patches to it.
|
||||
|
||||
<item>Go to <tt>/usr/ports/russian/X.language</tt> directory and say
|
||||
<verb>
|
||||
# make all install
|
||||
</verb>
|
||||
there. This port install latest version of KOI8-R fonts.
|
||||
<p>
|
||||
Check find <tt>"Files"</tt> section in your <tt>/etc/XF86Config</tt>,
|
||||
following lines must be before any other <tt>FontPath</tt> entries:
|
||||
<verb>
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/misc"
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/75dpi"
|
||||
FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/100dpi"
|
||||
</verb>
|
||||
<p>
|
||||
If you use high resolution video mode, swap 75 dpi and
|
||||
100 dpi lines.
|
||||
|
||||
<item>To activate Russian keyboard add
|
||||
<verb>
|
||||
XkbKeymap "xfree86(ru)"
|
||||
</verb>
|
||||
line into <tt>"Keyboard"</tt> section in your <tt>/etc/XF86Config</tt>,
|
||||
also make sure that <tt>XkbDisable</tt> is turned off (commented out)
|
||||
there.
|
||||
<p>
|
||||
RUS/LAT switch will be <bf>CapsLock</bf>. Old CapsLock function still
|
||||
available via <bf>Shift+CapsLock</bf> (in LAT mode only).
|
||||
<p>
|
||||
<it>NOTE:</it>
|
||||
Russian XKB keyboard may not work with old XFree86 versions,
|
||||
see <ref id="russian:note" name="locale note"> for more info.
|
||||
</enum>
|
||||
@ -1,891 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<title>An introduction to SCSI and its use with FreeBSD</title>
|
||||
<author>(c) 1995-1996, Wilko Bulte, <tt/wilko@yedi.iaf.nl/
|
||||
<date>Sat Jul 6 20:57:39 MET DST 1996</date>
|
||||
Copyright 1995-1996, Wilko C. Bulte, Arnhem, The Netherlands
|
||||
|
||||
<abstract>
|
||||
This document attempts to describe the background of SCSI, its
|
||||
(mis)use with FreeBSD and some common pitfalls.
|
||||
</abstract>
|
||||
|
||||
-->
|
||||
<sect1><heading>What is SCSI?<label id="scsi"></heading>
|
||||
|
||||
<p><em>Copyright © 1995, &a.wilko;.<newline>July 6, 1996.</em>
|
||||
|
||||
SCSI is an acronym for Small Computer Systems Interface. It is an
|
||||
ANSI standard that has become one of the leading I/O buses in the
|
||||
computer industry. The foundation of the SCSI standard was laid by
|
||||
Shugart Associates (the same guys that gave the world the first
|
||||
mini floppy disks) when they introduced the SASI bus (Shugart Associates
|
||||
Standard Interface).
|
||||
|
||||
After some time an industry effort was started to come to a more strict
|
||||
standard allowing devices from different vendors to work together.
|
||||
This effort was recognized in the ANSI SCSI-1 standard. The SCSI-1
|
||||
standard (approx 1985) is rapidly becoming obsolete. The current
|
||||
standard is SCSI-2 (see <ref id="scsi:further-reading" name="Further
|
||||
reading">), with SCSI-3 on the drawing boards.
|
||||
|
||||
In addition to a physical interconnection standard, SCSI defines a
|
||||
logical (command set) standard to which disk devices must adhere.
|
||||
This standard is called the Common Command Set (CCS) and was
|
||||
developed more or less in parallel with ANSI SCSI-1. SCSI-2
|
||||
includes the (revised) CCS as part of the standard itself. The
|
||||
commands are dependent on the type of device at hand. It does not
|
||||
make much sense of course to define a Write command for a
|
||||
scanner.
|
||||
|
||||
The SCSI bus is a parallel bus, which comes in a number of
|
||||
variants. The oldest and most used is an 8 bit wide bus, with
|
||||
single-ended signals, carried on 50 wires. (If you do not know what
|
||||
single-ended means, do not worry, that is what this document is all
|
||||
about.) Modern designs also use 16 bit wide buses, with
|
||||
differential signals. This allows transfer speeds of
|
||||
20Mbytes/second, on cables lengths of up to 25 meters. SCSI-2
|
||||
allows a maximum bus width of 32 bits, using an additional cable.
|
||||
Quickly emerging are Ultra SCSI (also called Fast-20) and Ultra2
|
||||
(also called Fast-40). Fast-20 is 20 mega-transfers per second
|
||||
(20 Mbytes/sec on a 8 bit bus), Fast-40 is 40 mega-transfers per
|
||||
second (40 Mbytes/sec on a 8 bit bus).
|
||||
|
||||
Of course the SCSI bus not only has data lines, but also a number
|
||||
of control signals. A very elaborate protocol is part of the
|
||||
standard to allow multiple devices to share the bus in an efficient
|
||||
manner. In SCSI-2, the data is always checked using a separate
|
||||
parity line. In pre-SCSI-2 designs parity was optional.
|
||||
|
||||
In SCSI-3 even faster bus types are introduced, along with a serial
|
||||
SCSI busses that reduces the cabling overhead and allows a higher
|
||||
maximum bus length. You might see names like SSA and Fiberchannel
|
||||
in this context. None of the serial buses are currently in widespread
|
||||
use (especially not in the typical FreeBSD environment). For
|
||||
this reason the serial bus types are not discussed any further.
|
||||
|
||||
As you could have guessed from the description above, SCSI devices
|
||||
are intelligent. They have to be to adhere to the SCSI standard
|
||||
(which is over 2 inches thick BTW). So, for a hard disk drive for
|
||||
instance you do not specify a head/cylinder/sector to address a
|
||||
particular block, but simply the number of the block you want.
|
||||
Elaborate caching schemes, automatic bad block replacement etc
|
||||
are all made possible by this 'intelligent device' approach.
|
||||
|
||||
On a SCSI bus, each possible pair of devices can communicate. Whether
|
||||
their function allows this is another matter, but the standard does
|
||||
not restrict it. To avoid signal contention, the 2 devices have to
|
||||
arbitrate for the bus before using it.
|
||||
|
||||
The philosophy of SCSI is to have a standard that allows
|
||||
older-standard devices to work with newer-standard ones. So, an
|
||||
old SCSI-1 device should normally work on a SCSI-2 bus. I say
|
||||
Normally, because it is not absolutely sure that the implementation
|
||||
of an old device follows the (old) standard closely enough to be
|
||||
acceptable on a new bus. Modern devices are usually more
|
||||
well-behaved, because the standardization has become more strict
|
||||
and is better adhered to by the device manufacturers.
|
||||
|
||||
Generally speaking, the chances of getting a working set of
|
||||
devices on a single bus is better when all the devices are SCSI-2
|
||||
or newer. This implies that you do not have to dump all your old
|
||||
stuff when you get that shiny 2Gb disk: I own a system on which a
|
||||
pre-SCSI-1 disk, a SCSI-2 QIC tape unit, a SCSI-1 helical scan
|
||||
tape unit and 2 SCSI-1 disks work together quite happily. From
|
||||
a performance standpoint you might want to separate your older
|
||||
and newer (=faster) devices however.
|
||||
|
||||
<sect2><heading>Components of SCSI</heading>
|
||||
<p>
|
||||
<!-- <sect3><heading>A <it>smart</it> interface</heading>
|
||||
<p> -->
|
||||
As said before, SCSI devices are smart. The idea is to put the
|
||||
knowledge about intimate hardware details onto the SCSI device
|
||||
itself. In this way, the host system does not have to worry
|
||||
about things like how many heads are hard disks has, or how many
|
||||
tracks there are on a specific tape device. If you are curious,
|
||||
the standard specifies commands with which you can query your
|
||||
devices on their hardware particulars. FreeBSD uses this
|
||||
capability during boot to check out what devices are connected
|
||||
and whether they need any special treatment.
|
||||
|
||||
The advantage of intelligent devices is obvious: the device
|
||||
drivers on the host can be made in a much more generic fashion,
|
||||
there is no longer a need to change (and qualify!) drivers for
|
||||
every odd new device that is introduced.
|
||||
|
||||
<!-- <sect3><heading>Do's and don't's on interconnections</heading>
|
||||
<p> -->
|
||||
For cabling and connectors there is a golden rule: get good
|
||||
stuff. With bus speeds going up all the time you will save
|
||||
yourself a lot of grief by using good material.
|
||||
|
||||
So, gold plated connectors, shielded cabling, sturdy connector
|
||||
hoods with strain reliefs etc are the way to go. Second golden
|
||||
rule: do no use cables longer than necessary. I once spent 3 days
|
||||
hunting down a problem with a flaky machine only to discover that
|
||||
shortening the SCSI bus by 1 meter solved the problem. And the
|
||||
original bus length was well within the SCSI specification.
|
||||
|
||||
<sect2><heading>SCSI bus types</heading>
|
||||
<p>
|
||||
From an electrical point of view, there are two incompatible bus
|
||||
types: single-ended and differential. This means that there are
|
||||
two different main groups of SCSI devices and controllers, which
|
||||
cannot be mixed on the same bus. It is possible however to use
|
||||
special converter hardware to transform a single-ended bus into a
|
||||
differential one (and vice versa). The differences between the
|
||||
bus types are explained in the next sections.
|
||||
|
||||
In lots of SCSI related documentation there is a sort of jargon
|
||||
in use to abbreviate the different bus types. A small list:
|
||||
|
||||
<itemize>
|
||||
<item>FWD: Fast Wide Differential
|
||||
<item>FND: Fast Narrow Differential
|
||||
<item>SE: Single Ended
|
||||
<item>FN: Fast Narrow
|
||||
<item>etc.
|
||||
</itemize>
|
||||
|
||||
With a minor amount of imagination one can usually imagine what
|
||||
is meant.
|
||||
|
||||
Wide is a bit ambiguous, it can indicate 16 or 32 bit buses. As
|
||||
far as I know, the 32 bit variant is not (yet) in use, so wide
|
||||
normally means 16 bit.
|
||||
|
||||
Fast means that the timing on the bus is somewhat different, so
|
||||
that on a narrow (8 bit) bus 10 Mbytes/sec are possible instead
|
||||
of 5 Mbytes/sec for 'slow' SCSI. As discussed before, bus
|
||||
speeds of 20 and 40 megatransfers/second are also emerging
|
||||
(Fast-20 == Ultra SCSI and Fast-40 == Ultra2 SCSI).
|
||||
|
||||
It should be noted that the data lines > 8 are only used for
|
||||
data transfers and device addressing. The transfers of commands
|
||||
and status messages etc are only performed on the lowest 8
|
||||
data lines. The standard allows narrow devices to operate on
|
||||
a wide bus. The usable bus width is negotiated
|
||||
between the devices. You have to watch your device addressing
|
||||
closely when mixing wide and narrow.
|
||||
|
||||
<sect3><heading>Single ended buses</heading>
|
||||
<p>
|
||||
A single-ended SCSI bus uses signals that are either 5 Volts or
|
||||
0 Volts (indeed, TTL levels) and are relative to a COMMON
|
||||
ground reference. A singled ended 8 bit SCSI bus has
|
||||
approximately 25 ground lines, who are all tied to a single
|
||||
`rail' on all devices. A standard single ended bus has a
|
||||
maximum length of 6 meters. If the same bus is used with
|
||||
fast-SCSI devices, the maximum length allowed drops to 3
|
||||
meters. Fast-SCSI means that instead of 5Mbytes/sec the bus
|
||||
allows 10Mbytes/sec transfers.
|
||||
|
||||
Fast-20 (Ultra SCSI) and Fast-40 allow for 20 and 40
|
||||
megatransfers/second respectively. So, F20 is 20 Mbytes/second
|
||||
on a 8 bit bus, 40 Mbytes/second on a 16 bit bus etc.
|
||||
For F20 the max bus length is 1.5 meters, for F40 it
|
||||
becomes 0.75 meters. Be aware that F20 is pushing
|
||||
the limits quite a bit, so you will quickly find out if your
|
||||
SCSI bus is electrically sound.
|
||||
|
||||
Please note that this means that
|
||||
if some devices on your bus use 'fast' to communicate your
|
||||
bus must adhere to the length restrictions for fast buses!
|
||||
|
||||
It is obvious that with the newer fast-SCSI devices the
|
||||
bus length can become a real bottleneck. This is why the
|
||||
differential SCSI bus was introduced in the SCSI-2 standard.
|
||||
|
||||
For connector pinning and connector types please refer to the
|
||||
SCSI-2 standard (see <ref id="scsi:further-reading" name="Further
|
||||
reading">) itself, connectors etc are listed there in
|
||||
painstaking detail.
|
||||
|
||||
Beware of devices using non-standard cabling. For instance
|
||||
Apple uses a 25pin D-type connecter (like the one on serial
|
||||
ports and parallel printers). Considering
|
||||
that the official SCSI bus needs 50 pins you can imagine
|
||||
the use of this connector needs some 'creative cabling'.
|
||||
The reduction of the number of ground wires they used
|
||||
is a bad idea, you better stick to 50 pins cabling
|
||||
in accordance with the SCSI standard. For Fast-20 and 40
|
||||
do not even think about buses like this.
|
||||
|
||||
<sect3><heading>Differential buses</heading>
|
||||
<p>
|
||||
A differential SCSI bus has a maximum length of 25
|
||||
meters. Quite a difference from the 3 meters for a single-ended
|
||||
fast-SCSI bus. The idea behind differential signals is that
|
||||
each bus signal has its own return wire. So, each signal is
|
||||
carried on a (preferably twisted) pair of wires. The voltage
|
||||
difference between these two wires determines whether the
|
||||
signal is asserted or de-asserted. To a certain extent the
|
||||
voltage difference between ground and the signal wire pair is
|
||||
not relevant (do not try 10 kVolts though).
|
||||
|
||||
It is beyond the scope of this document to explain why this
|
||||
differential idea is so much better. Just accept that
|
||||
electrically seen the use of differential signals gives a much
|
||||
better noise margin. You will normally find differential buses
|
||||
in use for inter-cabinet connections. Because of the lower cost
|
||||
single ended is mostly used for shorter buses like inside
|
||||
cabinets.
|
||||
|
||||
There is nothing that stops you from using differential stuff
|
||||
with FreeBSD, as long as you use a controller that has device
|
||||
driver support in FreeBSD. As an example, Adaptec marketed the
|
||||
AHA1740 as a single ended board, whereas the AHA1744 was differential.
|
||||
The software interface to the host is identical for both.
|
||||
|
||||
<sect3><heading>Terminators</heading>
|
||||
<p>
|
||||
Terminators in SCSI terminology are resistor networks that are
|
||||
used to get a correct impedance matching. Impedance matching
|
||||
is important to get clean signals on the bus, without
|
||||
reflections or ringing. If you once made a long distance
|
||||
telephone call on a bad line you probably know what reflections
|
||||
are. With 20Mbytes/sec traveling over your SCSI bus, you
|
||||
do not want signals echoing back.
|
||||
|
||||
Terminators come in various incarnations, with more or less
|
||||
sophisticated designs. Of course, there are internal and
|
||||
external variants. Almost every SCSI device comes with a
|
||||
number of sockets in which a number of resistor networks can
|
||||
(must be!) installed. If you remove terminators from a device,
|
||||
carefully store them. You will need them when you ever decide to
|
||||
reconfigure your SCSI bus. There is enough variation in even
|
||||
these simple tiny things to make finding the exact replacement
|
||||
a frustrating business. There are also SCSI devices that have
|
||||
a single jumper to enable or disable a built-in terminator.
|
||||
There are special terminators you can stick onto a flat cable
|
||||
bus. Others look like external connectors, or a connector hood
|
||||
without a cable. So, lots of choice as you can see.
|
||||
|
||||
There is much debate going on if and when you should switch
|
||||
from simple resistor (passive) terminators to active
|
||||
terminators. Active terminators contain slightly more elaborate
|
||||
circuit to give cleaner bus signals. The general consensus
|
||||
seems to be that the usefulness of active termination increases
|
||||
when you have long buses and/or fast devices. If you ever have
|
||||
problems with your SCSI buses you might consider trying an
|
||||
active terminator. Try to borrow one first, they reputedly are
|
||||
quite expensive.
|
||||
|
||||
Please keep in mind that terminators for differential and
|
||||
single-ended buses are not identical. You should <bf>not
|
||||
mix</bf> the two variants.
|
||||
|
||||
OK, and now where should you install your terminators? This is
|
||||
by far the most misunderstood part of SCSI. And it is by far
|
||||
the simplest. The rule is: <bf>every SCSI bus has 2 (two)
|
||||
terminators, one at each end of the bus.</bf> So, two and not
|
||||
one or three or whatever. Do yourself a favor and stick to
|
||||
this rule. It will save you endless grief, because wrong
|
||||
termination has the potential to introduce highly mysterious
|
||||
bugs.
|
||||
|
||||
A common pitfall is to have an internal (flat)cable in a
|
||||
machine and also an external cable attached to the
|
||||
controller. It seems almost everybody forgets to remove the
|
||||
terminators from the controller. The terminator must now be on
|
||||
the last external device, and not on the controller! In
|
||||
general, every reconfiguration of a SCSI bus must pay attention
|
||||
to this.
|
||||
|
||||
What I did myself is remove all terminators from my SCSI
|
||||
devices and controllers. I own a couple of external
|
||||
terminators, for both the Centronics-type external cabling and
|
||||
for the internal flat cable connectors. This makes
|
||||
reconfiguration much easier.
|
||||
|
||||
On modern devices, sometimes integrated terminators are
|
||||
used. These things are special purpose integrated circuits that
|
||||
can be dis/en-abled with a control pin. It is not necessary to
|
||||
physically remove them from a device. You may find them on
|
||||
newer host adapters, sometimes they even are software
|
||||
configurable, using some sort of setup tool. Consult you
|
||||
documentation!
|
||||
|
||||
<sect3><heading>Terminator power</heading>
|
||||
<p>
|
||||
The terminators discussed in the previous chapter need power to
|
||||
operate properly. On the SCSI bus, a line is dedicated to this
|
||||
purpose. So, simple huh?
|
||||
|
||||
Not so. Each device can provide its own terminator power to
|
||||
the terminator sockets it has on-device. But if you have
|
||||
external terminators, or when the device supplying the
|
||||
terminator power to the SCSI bus line is switched off you are
|
||||
in trouble.
|
||||
|
||||
The idea is that initiators (these are devices that initiate
|
||||
actions on the bus, a discussion follows) must supply
|
||||
terminator power. All SCSI devices are allowed (but not
|
||||
required) to supply terminator power.
|
||||
|
||||
To allow for un-powered devices on a bus, the terminator
|
||||
power must be supplied to the bus via a diode. This prevents
|
||||
the backflow of current to un-powered devices.
|
||||
|
||||
To prevent all kinds of nastiness, the terminator power is
|
||||
usually fused. As you can imagine, fuses might blow. This can,
|
||||
but does not have to, lead to a non functional bus. If multiple
|
||||
devices supply terminator power, a single blown fuse will not
|
||||
put you out of business. A single supplier with a blown fuse
|
||||
certainly will. Clever external terminators sometimes have a
|
||||
LED indication that shows whether terminator power is present.
|
||||
|
||||
In newer designs auto-restoring fuses that 'reset'
|
||||
themselves after some time are sometimes used.
|
||||
|
||||
<sect3><heading>Device addressing</heading>
|
||||
<p>
|
||||
Because the SCSI bus is, ehh, a bus there must be a way to
|
||||
distinguish or address the different devices connected to it.
|
||||
|
||||
This is done by means of the SCSI or target ID. Each device has
|
||||
a unique target ID. You can select the ID to which a device
|
||||
must respond using a set of jumpers, or a dip switch, or
|
||||
something similar. Consult the documentation of your device for
|
||||
more information.
|
||||
|
||||
Beware of multiple devices configured to use the same ID. Chaos
|
||||
normally reigns in this case. A pitfall is that one of the
|
||||
devices sharing the same ID sometimes even manages to answer
|
||||
to I/O requests!
|
||||
|
||||
For an 8 bit bus, a maximum of 8 targets is possible. The
|
||||
maximum is 8 because the selection is done bitwise using the 8
|
||||
data lines on the bus. For wide buses this increases to the
|
||||
number of data lines.
|
||||
|
||||
The higher the SCSI target ID, the higher the priority the
|
||||
devices has. When it comes to arbitration between devices that
|
||||
want to use the bus at the same time, the device that has the
|
||||
highest SCSI ID will win. This also means that the SCSI
|
||||
host adapter usually uses target ID 7 (for narrow buses).
|
||||
|
||||
For a further subdivision, the standard allows for Logical
|
||||
Units or LUNs for short. A single target ID may have multiple
|
||||
LUNs. For example, a tape device including a tape changer may
|
||||
have LUN 0 for the tape device itself, and LUN 1 for the
|
||||
tape changer. In this way, the host system can address each of
|
||||
the functional units of the tape changer as desired.
|
||||
|
||||
<sect3><heading>Bus layout</heading>
|
||||
<p>
|
||||
SCSI buses are linear. So, not shaped like Y-junctions, star
|
||||
topologies, cobwebs or whatever else people might want to
|
||||
invent.
|
||||
|
||||
You might notice that the terminator issue discussed earlier
|
||||
becomes rather hairy if your bus is not linear.
|
||||
|
||||
The electrical characteristics, its noise margins and
|
||||
ultimately the reliability of it all are tightly related to
|
||||
linear bus rule.
|
||||
|
||||
<bf>Stick to the linear bus rule!</bf>
|
||||
|
||||
<sect2><heading>Using SCSI with FreeBSD</heading>
|
||||
<p>
|
||||
<sect3><heading>About translations, BIOSes and magic...</heading>
|
||||
<p>
|
||||
As stated before, you should first make sure that you have a
|
||||
electrically sound bus.
|
||||
|
||||
When you want to use a SCSI disk on your PC as boot disk, you
|
||||
must aware of some quirks related to PC BIOSes. The PC BIOS in
|
||||
its first incarnation used a low level physical interface to the
|
||||
hard disk. So, you had to tell the BIOS (using a setup tool or a
|
||||
BIOS built-in setup) how your disk physically looked like. This
|
||||
involved stating number of heads, number of cylinders, number of
|
||||
sectors per track, obscure things like precompensation and
|
||||
reduced write current cylinder etc.
|
||||
|
||||
One might be inclined to think that since SCSI disks are smart
|
||||
you can forget about this. Alas, the arcane setup issue is still
|
||||
present today. The system BIOS needs to know how to access your
|
||||
SCSI disk with the head/cyl/sector method in order to load the
|
||||
FreeBSD kernel during boot.
|
||||
|
||||
The SCSI host adapter or SCSI controller you have put in your
|
||||
AT/EISA/PCI/whatever bus to connect your disk therefore has its
|
||||
own on-board BIOS. During system startup, the SCSI BIOS takes over
|
||||
the hard disk interface routines from the system BIOS. To fool the
|
||||
system BIOS, the system setup is normally set to No hard disk
|
||||
present. Obvious, isn't it?
|
||||
|
||||
The SCSI BIOS itself presents to the system a so called
|
||||
<bf>translated</bf> drive. This means that a fake drive table is
|
||||
constructed that allows the PC to boot the drive. This
|
||||
translation is often (but not always) done using a pseudo drive
|
||||
with 64 heads and 32 sectors per track. By varying the number of
|
||||
cylinders, the SCSI BIOS adapts to the actual drive size. It is
|
||||
useful to note that 32 * 64 / 2 = the size of your drive in
|
||||
megabytes. The division by 2 is to get from disk blocks that are
|
||||
normally 512 bytes in size to Kbytes.
|
||||
|
||||
Right. All is well now?! No, it is not. The system BIOS has
|
||||
another quirk you might run into. The number of cylinders of a
|
||||
bootable hard disk cannot be greater than 1024. Using the
|
||||
translation above, this is a show-stopper for disks greater than
|
||||
1 Gb. With disk capacities going up all the time this is causing
|
||||
problems.
|
||||
|
||||
Fortunately, the solution is simple: just use another
|
||||
translation, e.g. with 128 heads instead of 32. In most cases new
|
||||
SCSI BIOS versions are available to upgrade older SCSI host
|
||||
adapters. Some newer adapters have an option, in the form of a
|
||||
jumper or software setup selection, to switch the translation the
|
||||
SCSI BIOS uses.
|
||||
|
||||
It is very important that <bf>all</bf> operating systems on the
|
||||
disk use the <bf>same translation</bf> to get the right idea about
|
||||
where to find the relevant partitions. So, when installing
|
||||
FreeBSD you must answer any questions about heads/cylinders
|
||||
etc using the translated values your host adapter uses.
|
||||
|
||||
Failing to observe the translation issue might lead to
|
||||
un-bootable systems or operating systems overwriting each
|
||||
others partitions. Using fdisk you should be able to see
|
||||
all partitions.
|
||||
|
||||
You might have heard some talk of 'lying' devices?
|
||||
Older FreeBSD kernels used to report the geometry
|
||||
of SCSI disks when booting. An example from one of my systems:
|
||||
|
||||
<verb>
|
||||
aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4>
|
||||
sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512
|
||||
</verb>
|
||||
Newer kernels usually do not report this information. e.g.
|
||||
<verb>
|
||||
(bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2
|
||||
sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)
|
||||
</verb>
|
||||
|
||||
Why has this changed?
|
||||
|
||||
This info is retrieved from the SCSI disk itself. Newer disks
|
||||
often use a technique called zone bit recording. The idea is that
|
||||
on the outer cylinders of the drive there is more space so more
|
||||
sectors per track can be put on them. This results in disks that
|
||||
have more tracks on outer cylinders than on the inner cylinders
|
||||
and, last but not least, have more capacity. You can imagine that
|
||||
the value reported by the drive when inquiring about the geometry
|
||||
now becomes suspect at best, and nearly always misleading. When
|
||||
asked for a geometry , it is nearly always better to supply the
|
||||
geometry used by the BIOS, or <em>if the BIOS is never going to know
|
||||
about this disk</em>, (e.g. it is not a booting disk) to supply a
|
||||
fictitious geometry that is convenient.
|
||||
|
||||
<sect3><heading>SCSI subsystem design</heading>
|
||||
<p>
|
||||
FreeBSD uses a layered SCSI subsystem. For each different
|
||||
controller card a device driver is written. This driver
|
||||
knows all the intimate details about the hardware it
|
||||
controls. The driver has a interface to the upper layers of the
|
||||
SCSI subsystem through which it receives its commands and
|
||||
reports back any status.
|
||||
|
||||
On top of the card drivers there are a number of more generic
|
||||
drivers for a class of devices. More specific: a driver for
|
||||
tape devices (abbreviation: st), magnetic disks (sd), cdroms (cd)
|
||||
etc. In case you are wondering where you can find this stuff, it
|
||||
all lives in <tt>/sys/scsi</tt>. See the man pages in section 4
|
||||
for more details.
|
||||
|
||||
The multi level design allows a decoupling of low-level bit
|
||||
banging and more high level stuff. Adding support for another
|
||||
piece of hardware is a much more manageable problem.
|
||||
|
||||
<sect3><heading>Kernel configuration</heading>
|
||||
<p>
|
||||
Dependent on your hardware, the kernel configuration file must
|
||||
contain one or more lines describing your host adapter(s).
|
||||
This includes I/O addresses, interrupts etc.
|
||||
Consult the man page for your
|
||||
adapter driver to get more info. Apart from that, check out
|
||||
/sys/i386/conf/LINT for an overview of a kernel config file.
|
||||
LINT contains every possible option you can dream of. It
|
||||
does <em>not</em> imply LINT will actually get you to a
|
||||
working kernel at all.
|
||||
|
||||
Although it is probably stating the obvious: the kernel config
|
||||
file should reflect your actual hardware setup. So, interrupts,
|
||||
I/O addresses etc must match the kernel config file. During
|
||||
system boot messages will be displayed to indicate whether
|
||||
the configured hardware was actually found.
|
||||
|
||||
An example loosely based on the FreeBSD 2.0.5-Release kernel config
|
||||
file LINT with some added comments (between []):
|
||||
|
||||
<verb>
|
||||
|
||||
# SCSI host adapters: `aha', `ahb', `aic', `bt', `nca'
|
||||
#
|
||||
# aha: Adaptec 154x
|
||||
# ahb: Adaptec 174x
|
||||
# ahc: Adaptec 274x/284x/294x
|
||||
# aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!)
|
||||
# bt: Most Buslogic controllers
|
||||
# nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130
|
||||
# uha: UltraStore 14F and 34F
|
||||
# sea: Seagate ST01/02 8 bit controller (slow!)
|
||||
# wds: Western Digital WD7000 controller (no scatter/gather!).
|
||||
#
|
||||
|
||||
[For an Adaptec AHA274x, 284x etc controller]
|
||||
controller ahc0 at isa? bio irq ? vector ahcintr # port??? iomem?
|
||||
|
||||
[For an Adaptec AHA174x controller]
|
||||
controller ahb0 at isa? bio irq ? vector ahbintr
|
||||
|
||||
[For an Ultrastor adapter]
|
||||
controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr
|
||||
|
||||
# Map SCSI buses to specific SCSI adapters
|
||||
controller scbus0 at ahc0
|
||||
controller scbus2 at ahb0
|
||||
controller scbus1 at uha0
|
||||
|
||||
# The actual SCSI devices
|
||||
disk sd0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0]
|
||||
disk sd1 at scbus0 target 1 [implicit LUN 0 if omitted]
|
||||
disk sd2 at scbus1 target 3 [SCSI disk on the uha0]
|
||||
disk sd3 at scbus2 target 4 [SCSI disk on the ahb0]
|
||||
tape st1 at scbus0 target 6 [SCSI tape at target 6]
|
||||
device cd0 at scbus? [the first ever CDROM found, no wiring]
|
||||
|
||||
</verb>
|
||||
|
||||
The example above tells the kernel to look for a ahc (Adaptec 274x)
|
||||
controller, then for an Adaptec 174x board, and
|
||||
so on. The lines following the controller specifications
|
||||
tell the kernel to configure specific devices but
|
||||
<em>only</em> attach them when they match the target ID and
|
||||
LUN specified on the corresponding bus.
|
||||
|
||||
Wired down devices get 'first shot' at the unit numbers
|
||||
so the first non 'wired down' device, is allocated the unit number
|
||||
one greater than the highest 'wired down' unit number
|
||||
for that kind of device.
|
||||
So, if you had a SCSI tape at target ID 2 it would be
|
||||
configured as st2, as the tape at target ID 6 is wired down
|
||||
to unit number 1. Note that <em>wired down devices need not
|
||||
be found</em>
|
||||
to get their unit number. The unit number for a wired down device
|
||||
is reserved for that device, even if it is turned off at boot
|
||||
time. This allows the device to be turned on and brought
|
||||
on-line at a later time, without rebooting. Notice that a device's
|
||||
unit number has <em>no</em> relationship with its target ID on
|
||||
the SCSI bus.
|
||||
|
||||
Below is another example of a kernel config file as used by
|
||||
FreeBSD version < 2.0.5. The difference with the first example is
|
||||
that devices are not 'wired down'. 'Wired down' means
|
||||
that you specify which SCSI target belongs to which device.
|
||||
|
||||
A kernel built to the config file below will attach
|
||||
the first SCSI disk it finds to sd0, the second disk to sd1
|
||||
etc. If you ever removed or added a disk, all other devices
|
||||
of the same type (disk in this case) would 'move around'.
|
||||
This implies you have to change <tt>/etc/fstab</tt> each time.
|
||||
|
||||
Although the old style still works, you
|
||||
are <em>strongly</em> recommended to use this new feature.
|
||||
It will save you a lot of grief whenever you shift your
|
||||
hardware around on the SCSI buses. So, when you re-use
|
||||
your old trusty config file after upgrading from a
|
||||
pre-FreeBSD2.0.5.R system check this out.
|
||||
|
||||
<verb>
|
||||
[driver for Adaptec 174x]
|
||||
controller ahb0 at isa? bio irq 11 vector ahbintr
|
||||
[for Adaptec 154x]
|
||||
controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr
|
||||
[for Seagate ST01/02]
|
||||
controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr
|
||||
controller scbus0
|
||||
|
||||
device sd0 [support for 4 SCSI harddisks, sd0 up sd3]
|
||||
|
||||
device st0 [support for 2 SCSI tapes]
|
||||
|
||||
[for the cdrom]
|
||||
device cd0 #Only need one of these, the code dynamically grows
|
||||
</verb>
|
||||
|
||||
|
||||
Both examples support SCSI disks. If during boot more
|
||||
devices of a specific type (e.g. sd disks) are found than are
|
||||
configured in the booting kernel, the system will simply allocate
|
||||
more devices, incrementing the unit number starting at the last
|
||||
number 'wired down'. If there are no 'wired down' devices
|
||||
then counting starts at unit 0.
|
||||
|
||||
Use <tt>man 4 scsi</tt> to check for the latest info on the SCSI
|
||||
subsystem. For more detailed info on host adapter drivers use eg
|
||||
<tt>man 4 aha</tt> for info on the Adaptec 154x driver.
|
||||
|
||||
<sect3><heading>Tuning your SCSI kernel setup</heading>
|
||||
<p>
|
||||
Experience has shown that some devices are slow to respond to INQUIRY
|
||||
commands after a SCSI bus reset (which happens at boot time).
|
||||
An INQUIRY command is sent by the kernel on boot to see what
|
||||
kind of device (disk, tape, CDROM etc) is connected to a
|
||||
specific target ID. This process is called device probing by the way.
|
||||
|
||||
To work around the 'slow response' problem, FreeBSD allows a
|
||||
tunable delay time
|
||||
before the SCSI devices are probed following a SCSI bus reset.
|
||||
You can set this delay time in your kernel configuration file
|
||||
using a line like:
|
||||
|
||||
<verb>
|
||||
options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device
|
||||
</verb>
|
||||
This line sets the delay time to 15 seconds. On my own system I had to
|
||||
use 3 seconds minimum to get my trusty old CDROM drive to be recognized.
|
||||
Start with a high value (say 30 seconds or so) when you have problems
|
||||
with device recognition. If this helps, tune it back until it just stays
|
||||
working.
|
||||
|
||||
<sect3><heading>Rogue SCSI devices</heading>
|
||||
<p>
|
||||
Although the SCSI standard tries to be complete and concise, it is
|
||||
a complex standard and implementing things correctly is no easy task.
|
||||
Some vendors do a better job then others.
|
||||
|
||||
This is exactly where the 'rogue' devices come into view. Rogues are
|
||||
devices that are recognized by the FreeBSD kernel as behaving slightly
|
||||
(...) non-standard. Rogue devices are reported by the kernel when
|
||||
booting. An example for two of my cartridge tape units:
|
||||
|
||||
<verb>
|
||||
Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:>
|
||||
Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue
|
||||
|
||||
Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005>
|
||||
Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue
|
||||
</verb>
|
||||
|
||||
For instance, there are devices that respond to
|
||||
all LUNs on a certain target ID, even if they are actually only one
|
||||
device. It is easy to see that the kernel might be fooled into
|
||||
believing that there are 8 LUNs at that particular target ID. The
|
||||
confusion this causes is left as an exercise to the reader.
|
||||
|
||||
The SCSI subsystem of FreeBSD recognizes devices with bad habits by
|
||||
looking at the INQUIRY response they send when probed. Because the
|
||||
INQUIRY response also includes the version number of the device
|
||||
firmware, it is even possible that for different firmware versions
|
||||
different workarounds are used. See e.g. /sys/scsi/st.c and
|
||||
/sys/scsi/scsiconf.c for more info on how this is done.
|
||||
|
||||
This scheme works fine, but keep in mind that it of course only
|
||||
works for devices that are KNOWN to be weird. If you are the first
|
||||
to connect your bogus Mumbletech SCSI CDROM you might be the one
|
||||
that has to define which workaround is needed.
|
||||
|
||||
After you got your Mumbletech working, please send the required
|
||||
workaround to the FreeBSD development team for inclusion in the
|
||||
next release of FreeBSD. Other Mumbletech owners will be grateful
|
||||
to you.
|
||||
|
||||
<sect3><heading>Multiple LUN devices</heading>
|
||||
<p>
|
||||
In some cases you come across devices that use multiple
|
||||
logical units (LUNs) on a single SCSI ID. In most cases
|
||||
FreeBSD only probes devices for LUN 0. An example are
|
||||
so called bridge boards that connect 2 non-SCSI harddisks
|
||||
to a SCSI bus (e.g. an Emulex MD21 found in old Sun systems).
|
||||
|
||||
This means that any devices with LUNs != 0 are not normally
|
||||
found during device probe on system boot. To work around this
|
||||
problem you must add an appropriate entry in /sys/scsi/scsiconf.c
|
||||
and rebuild your kernel.
|
||||
|
||||
Look for a struct that is initialised like below:
|
||||
<verb>
|
||||
{
|
||||
T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A",
|
||||
"mx1", SC_ONE_LU
|
||||
}
|
||||
</verb>
|
||||
|
||||
For you Mumbletech BRIDGE2000 that has more than one LUN,
|
||||
acts as a SCSI disk
|
||||
and has firmware revision 123 you would add something like:
|
||||
|
||||
<verb>
|
||||
{
|
||||
T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123",
|
||||
"sd", SC_MORE_LUS
|
||||
}
|
||||
</verb>
|
||||
|
||||
The kernel on boot scans the inquiry data it receives against
|
||||
the table and acts accordingly. See the source for more info.
|
||||
|
||||
<sect3><heading>Tagged command queueing</heading>
|
||||
<p>
|
||||
Modern SCSI devices, particularly magnetic disks, support
|
||||
what is called tagged command queuing (TCQ).
|
||||
|
||||
In a nutshell, TCQ allows the device to have multiple I/O
|
||||
requests outstanding at the same time. Because the device
|
||||
is intelligent, it can optimise its operations (like
|
||||
head positioning) based on its own request queue. On
|
||||
SCSI devices like RAID (Redundant Array of Independent
|
||||
Disks) arrays the TCQ function is indispensable to take
|
||||
advantage of the device's inherent parallelism.
|
||||
|
||||
Each I/O request is uniquely identified by a 'tag' (hence
|
||||
the name tagged command queuing) and this tag is used by
|
||||
FreeBSD to see which I/O in the device drivers queue is
|
||||
reported as complete by the device.
|
||||
|
||||
It should be noted however that TCQ requires device driver
|
||||
support and that some devices implemented it 'not quite
|
||||
right' in their firmware. This problem bit me once, and
|
||||
it leads to highly mysterious problems. In such cases,
|
||||
try to disable TCQ.
|
||||
|
||||
<sect3><heading>Busmaster host adapters</heading>
|
||||
<p>
|
||||
Most, but not all, SCSI host adapters are bus mastering controllers.
|
||||
This means that they can do I/O on their own without putting load onto
|
||||
the host CPU for data movement.
|
||||
|
||||
This is of course an advantage for a multitasking operating system like
|
||||
FreeBSD. It must be noted however that there might be some rough edges.
|
||||
|
||||
For instance an Adaptec 1542 controller can be set to use different
|
||||
transfer speeds on the host bus (ISA or AT in this case). The controller
|
||||
is settable to different rates because not all motherboards can handle
|
||||
the higher speeds. Problems like hangups, bad data etc might be the
|
||||
result of using a higher data transfer rate then your motherboard
|
||||
can stomach.
|
||||
|
||||
The solution is of course obvious: switch to a lower data transfer rate
|
||||
and try if that works better.
|
||||
|
||||
In the case of a Adaptec 1542, there is an option that can be put
|
||||
into the kernel config file to allow dynamic determination of the
|
||||
right, read: fastest feasible, transfer rate. This option is
|
||||
disabled by default:
|
||||
|
||||
<verb>
|
||||
options "TUNE_1542" #dynamic tune of bus DMA speed
|
||||
</verb>
|
||||
|
||||
Check the man pages for the host adapter that you use. Or better
|
||||
still, use the ultimate documentation (read: driver source).
|
||||
|
||||
<sect2><heading>Tracking down problems</heading>
|
||||
<p>
|
||||
The following list is an attempt to give a guideline for the most
|
||||
common SCSI problems and their solutions. It is by no means
|
||||
complete.
|
||||
|
||||
<itemize>
|
||||
<item>
|
||||
Check for loose connectors and cables.
|
||||
<item>
|
||||
Check and double check the location and number of your terminators.
|
||||
<item>
|
||||
Check if your bus has at least one supplier of terminator power
|
||||
(especially with external terminators.
|
||||
<item>
|
||||
Check if no double target IDs are used.
|
||||
<item>
|
||||
Check if all devices to be used are powered up.
|
||||
<item>
|
||||
Make a minimal bus config with as little devices as possible.
|
||||
<item>
|
||||
If possible, configure your host adapter to use slow bus speeds.
|
||||
<item>
|
||||
Disable tagged command queuing to make things as simple as
|
||||
possible (for a NCR hostadapter based system see man
|
||||
ncrcontrol)
|
||||
<item>
|
||||
If you can compile a kernel, make one with the SCSIDEBUG option,
|
||||
and try accessing the device with debugging turned on for
|
||||
that device. If your device does not even probe at startup,
|
||||
you may have to define the address of the device that
|
||||
is failing, and the desired debug level in
|
||||
<tt>/sys/scsi/scsidebug.h</tt>.
|
||||
If it probes but just does not work, you can use the
|
||||
<tt>scsi(8)</tt> command to dynamically set a debug level to
|
||||
it in a running kernel (if SCSIDEBUG is defined).
|
||||
This will give you COPIOUS debugging output with which to confuse
|
||||
the gurus. see <tt>man 4 scsi</tt> for more exact information.
|
||||
Also look at <tt>man 8 scsi</tt>.
|
||||
</itemize>
|
||||
|
||||
<sect2><heading>Further reading<label id="scsi:further-reading"></heading>
|
||||
<p>
|
||||
If you intend to do some serious SCSI hacking, you might want to
|
||||
have the official standard at hand:
|
||||
|
||||
Approved American National Standards can be purchased from ANSI at
|
||||
11 West 42nd Street, 13th Floor, New York, NY 10036, Sales Dept:
|
||||
(212) 642-4900. You can also buy many ANSI standards and most
|
||||
committee draft documents from Global Engineering Documents, 15
|
||||
Inverness Way East, Englewood, CO 80112-5704, Phone: (800)
|
||||
854-7179, Outside USA and Canada: (303) 792-2181, FAX: (303) 792-
|
||||
2192.
|
||||
|
||||
Many X3T10 draft documents are available electronically on the SCSI
|
||||
BBS (719-574-0424) and on the ncrinfo.ncr.com anonymous ftp site.
|
||||
|
||||
Latest X3T10 committee documents are:
|
||||
<itemize>
|
||||
<item>AT Attachment (ATA or IDE) [X3.221-1994] (<em>Approved</em>)
|
||||
<item>ATA Extensions (ATA-2) [X3T10/948D Rev 2i]
|
||||
<item>Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (<em>Approved</em>)
|
||||
<item>Small Computer System Interface - 2 (SCSI-2) [X3.131-1994] (<em>Approved</em>)
|
||||
<item>SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM)
|
||||
[X3T10/792D Rev 11]
|
||||
</itemize>
|
||||
Other publications that might provide you with additional information are:
|
||||
<itemize>
|
||||
<item>"SCSI: Understanding the Small Computer System Interface", written by NCR
|
||||
Corporation. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632
|
||||
Phone: (201) 767-5937 ISBN 0-13-796855-8
|
||||
|
||||
<item>"Basics of SCSI", a SCSI tutorial written by Ancot Corporation
|
||||
Contact Ancot for availability information at:
|
||||
Phone: (415) 322-5322 Fax: (415) 322-0455
|
||||
|
||||
<item>"SCSI Interconnection Guide Book", an AMP publication (dated 4/93, Catalog
|
||||
65237) that lists the various SCSI connectors and suggests cabling schemes.
|
||||
Available from AMP at (800) 522-6752 or (717) 564-0100
|
||||
|
||||
<item>"Fast Track to SCSI", A Product Guide written by Fujitsu.
|
||||
Available from: Prentice Hall, Englewood Cliffs, NJ, 07632
|
||||
Phone: (201) 767-5937 ISBN 0-13-307000-X
|
||||
|
||||
<item>"The SCSI Bench Reference", "The SCSI Encyclopedia", and the "SCSI Tutor",
|
||||
ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070
|
||||
Phone: (408) 867-6642
|
||||
|
||||
<item>"Zadian SCSI Navigator" (quick ref. book) and "Discover the Power of SCSI"
|
||||
(First book along with a one-hour video and tutorial book), Zadian Software,
|
||||
Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800
|
||||
</itemize>
|
||||
|
||||
On Usenet the newsgroups <htmlurl
|
||||
url="news:comp.periphs.scsi" name="comp.periphs.scsi">
|
||||
and <htmlurl url="news:comp.periphs" name="comp.periphs">
|
||||
are noteworthy places to look for more info. You can also
|
||||
find the SCSI-Faq there, which is posted periodically.
|
||||
|
||||
Most major SCSI device and host adapter suppliers operate ftp sites
|
||||
and/or BBS systems. They may be valuable sources of information
|
||||
about the devices you own.
|
||||
@ -1,62 +0,0 @@
|
||||
<!-- $Id: sections.sgml,v 1.23 1997/05/01 03:06:32 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!-- Entities containing all the pieces of the handbook are -->
|
||||
<!-- defined here -->
|
||||
|
||||
<!ENTITY bibliography SYSTEM "bibliography.sgml">
|
||||
<!ENTITY basics SYSTEM "basics.sgml">
|
||||
<!ENTITY booting SYSTEM "booting.sgml">
|
||||
<!ENTITY contrib SYSTEM "contrib.sgml">
|
||||
<!ENTITY ctm SYSTEM "ctm.sgml">
|
||||
<!ENTITY cvsup SYSTEM "cvsup.sgml">
|
||||
<!ENTITY current SYSTEM "current.sgml">
|
||||
<!ENTITY stable SYSTEM "stable.sgml">
|
||||
<!ENTITY crypt SYSTEM "crypt.sgml">
|
||||
<!ENTITY development SYSTEM "development.sgml">
|
||||
<!ENTITY dialup SYSTEM "dialup.sgml">
|
||||
<!ENTITY dialout SYSTEM "dialout.sgml">
|
||||
<!ENTITY diskless SYSTEM "diskless.sgml">
|
||||
<!ENTITY dma SYSTEM "dma.sgml">
|
||||
<!ENTITY eresources SYSTEM "eresources.sgml">
|
||||
<!ENTITY esdi SYSTEM "esdi.sgml">
|
||||
<!ENTITY firewalls SYSTEM "firewalls.sgml">
|
||||
<!ENTITY goals SYSTEM "goals.sgml">
|
||||
<!ENTITY glossary SYSTEM "glossary.sgml">
|
||||
<!ENTITY history SYSTEM "history.sgml">
|
||||
<!ENTITY hw SYSTEM "hw.sgml">
|
||||
<!ENTITY install SYSTEM "install.sgml">
|
||||
<!ENTITY term SYSTEM "term.sgml">
|
||||
<!ENTITY isdn SYSTEM "isdn.sgml">
|
||||
<!ENTITY kerberos SYSTEM "kerberos.sgml">
|
||||
<!ENTITY kernelconfig SYSTEM "kernelconfig.sgml">
|
||||
<!ENTITY kerneldebug SYSTEM "kerneldebug.sgml">
|
||||
<!ENTITY kernelopts SYSTEM "kernelopts.sgml">
|
||||
<!ENTITY linuxemu SYSTEM "linuxemu.sgml">
|
||||
<!ENTITY mail SYSTEM "mail.sgml">
|
||||
<!ENTITY memoryuse SYSTEM "memoryuse.sgml">
|
||||
<!ENTITY mirrors SYSTEM "mirrors.sgml">
|
||||
<!ENTITY nfs SYSTEM "nfs.sgml">
|
||||
<!ENTITY nutshell SYSTEM "nutshell.sgml">
|
||||
<!ENTITY pgpkeys SYSTEM "pgpkeys.sgml">
|
||||
<!ENTITY policies SYSTEM "policies.sgml">
|
||||
<!ENTITY porting SYSTEM "porting.sgml">
|
||||
<!ENTITY ports SYSTEM "ports.sgml">
|
||||
<!ENTITY ppp SYSTEM "ppp.sgml">
|
||||
<!ENTITY printing SYSTEM "printing.sgml">
|
||||
<!ENTITY quotas SYSTEM "quotas.sgml">
|
||||
<!ENTITY relnotes SYSTEM "relnotes.sgml">
|
||||
<!ENTITY routing SYSTEM "routing.sgml">
|
||||
<!ENTITY russian SYSTEM "russian.sgml">
|
||||
<!ENTITY serial SYSTEM "serial.sgml">
|
||||
<!ENTITY scsi SYSTEM "scsi.sgml">
|
||||
<!ENTITY sio SYSTEM "sio.sgml">
|
||||
<!ENTITY cy SYSTEM "cyclades.sgml">
|
||||
<!ENTITY skey SYSTEM "skey.sgml">
|
||||
<!ENTITY slipc SYSTEM "slipc.sgml">
|
||||
<!ENTITY slips SYSTEM "slips.sgml">
|
||||
<!ENTITY submitters SYSTEM "submitters.sgml">
|
||||
<!ENTITY sup SYSTEM "sup.sgml">
|
||||
<!ENTITY synching SYSTEM "synching.sgml">
|
||||
<!ENTITY uart SYSTEM "uart.sgml">
|
||||
<!ENTITY userppp SYSTEM "userppp.sgml">
|
||||
@ -1,64 +0,0 @@
|
||||
<!-- This is an SGML document in the linuxdoc DTD of the Tutorial for
|
||||
Configuring a FreeBSD for Dialup Services by Guy Helmer.
|
||||
$Id$
|
||||
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
||||
<linuxdoc>
|
||||
<article>
|
||||
<title> Serial Basics
|
||||
<author> FAQ
|
||||
<date> 24 Nov 1996, (c) 1996
|
||||
|
||||
<abstract> This section outlines some of the basics to get your serial ports working. This is really just a stepping stone into the section on PPP or Dialout if you are interested in modems.
|
||||
</abstract>
|
||||
|
||||
<toc>
|
||||
-->
|
||||
|
||||
<sect><heading>Serial Basics<label id="serial"></heading>
|
||||
|
||||
<p><em>Assembled from FAQ.</em>
|
||||
|
||||
This section should give you some general information about serial ports. If you do not find what you want here, check into the Terminal and Dialup sections of the handbook.
|
||||
|
||||
|
||||
<p>
|
||||
The <tt/ttydX/ (or <tt/cuaaX/) device is the regular device
|
||||
you will want to open for your applications. When a process opens
|
||||
the device, it will have a default set of terminal I/O settings.
|
||||
You can see these settings with the command
|
||||
<verb>
|
||||
stty -a -f /dev/ttyd1
|
||||
</verb>
|
||||
|
||||
When you change the settings to this device, the settings are in
|
||||
effect until the device is closed. When it is reopened, it goes
|
||||
back to the default set. To make changes to the default set, you
|
||||
can open and adjust the settings of the ``initial state'' device.
|
||||
For example, to turn on <tt/CLOCAL/ mode, 8 bits, and
|
||||
<tt>XON/XOFF</tt> flow control by default for ttyd5, do:
|
||||
<verb>
|
||||
stty -f /dev/ttyid5 clocal cs8 ixon ixoff
|
||||
</verb>
|
||||
|
||||
A good place to do this is in <tt>/etc/rc.serial</tt>. Now, an
|
||||
application will have these settings by default when it opens
|
||||
<tt/ttyd5/. It can still change these settings to its liking,
|
||||
though.
|
||||
|
||||
You can also prevent certain settings from being changed by an
|
||||
application by making adjustments to the ``lock state'' device.
|
||||
For example, to lock the speed of <tt/ttyd5/ to 57600 bps, do
|
||||
<verb>
|
||||
stty -f /dev/ttyld5 57600
|
||||
</verb>
|
||||
|
||||
Now, an application that opens <tt/ttyd5/ and tries to change the
|
||||
speed of the port will be stuck with 57600 bps.
|
||||
|
||||
Naturally, you should make the initial state and lock state
|
||||
devices writable only by <tt/root/. The <tt/MAKEDEV/ script does
|
||||
<bf/NOT/ do this when it creates the device entries.
|
||||
@ -1,207 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
]>
|
||||
-->
|
||||
<sect2><heading>Configuring the <tt>sio</tt> driver<label id="sio"></heading>
|
||||
|
||||
<p>The <tt>sio</tt> driver provides support for NS8250-,
|
||||
NS16450-, NS16550 and NS16550A-based EIA RS-232C (CCITT
|
||||
V.24) communications interfaces. Several multiport
|
||||
cards are supported as well. See the <tt>sio(4)</tt>
|
||||
manual page for detailed technical documentation.
|
||||
|
||||
<sect3><heading>Digi International (DigiBoard) PC/8</heading>
|
||||
|
||||
<p><em>Contributed by &a.awebster;.<newline>26 August
|
||||
1995.</em>
|
||||
|
||||
Here is a config snippet from a machine with
|
||||
a Digi International PC/8 with 16550. It has 8 modems connected
|
||||
to these 8 lines, and they work just great. Do not
|
||||
forget to add <tt>options COM_MULTIPORT</tt> or it
|
||||
will not work very well!
|
||||
|
||||
<tscreen><verb>
|
||||
device sio4 at isa? port 0x100 tty flags 0xb05
|
||||
device sio5 at isa? port 0x108 tty flags 0xb05
|
||||
device sio6 at isa? port 0x110 tty flags 0xb05
|
||||
device sio7 at isa? port 0x118 tty flags 0xb05
|
||||
device sio8 at isa? port 0x120 tty flags 0xb05
|
||||
device sio9 at isa? port 0x128 tty flags 0xb05
|
||||
device sio10 at isa? port 0x130 tty flags 0xb05
|
||||
device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr
|
||||
</verb></tscreen>
|
||||
|
||||
The trick in setting this up is that the MSB of the
|
||||
flags represent the last SIO port, in this case 11 so
|
||||
flags are 0xb05.
|
||||
|
||||
<sect3><heading>Boca 16</heading>
|
||||
|
||||
<p><em>Contributed by &a.whiteside;.<newline>26 August
|
||||
1995.</em>
|
||||
|
||||
The procedures to make a Boca 16 pord board with
|
||||
FreeBSD are pretty straightforward, but you will need
|
||||
a couple things to make it work:
|
||||
|
||||
<enum>
|
||||
<item>You either need the kernel sources installed
|
||||
so you can recompile the necessary options or
|
||||
you will need someone else to compile it for you.
|
||||
The 2.0.5 default kernel does <bf>not</bf> come with
|
||||
multiport support enabled and you will need to add
|
||||
a device entry for each port anyways.
|
||||
</item>
|
||||
<item>Two, you will need to know the interrupt and IO
|
||||
setting for your Boca Board so you can set these
|
||||
options properly in the kernel.</item>
|
||||
</enum>
|
||||
|
||||
One important note - the actual UART chips for the
|
||||
Boca 16 are in the connector box, not on the internal
|
||||
board itself. So if you have it unplugged, probes of
|
||||
those ports will fail. I have never tested booting with
|
||||
the box unplugged and plugging it back in, and I
|
||||
suggest you do not either.
|
||||
|
||||
If you do not already have a custom kernel
|
||||
configuration file set up, refer to <ref
|
||||
id="kernelconfig" name="Kernel Configuration"> for
|
||||
general procedures. The following are the specifics
|
||||
for the Boca 16 board and assume you are using the
|
||||
kernel name MYKERNEL and editing with vi.
|
||||
|
||||
<enum>
|
||||
<item>Add the line
|
||||
<tscreen><verb>
|
||||
options COM_MULTIPORT
|
||||
</verb></tscreen>
|
||||
to the config file.
|
||||
</item>
|
||||
|
||||
<item>Where the current <tt>device sio
|
||||
<em>xxx</em></tt> lines are, you will need to add
|
||||
16 more devices. <em>Only the last device
|
||||
includes the interrupt vector for the
|
||||
board</em>. (See the <tt>sio(4)</tt> manual page
|
||||
for detail as to why.)
|
||||
|
||||
The following example is for a Boca Board with an
|
||||
interrupt of 3, and a base IO address 100h. The
|
||||
IO address for Each port is +8 hexadecimal from
|
||||
the previous port, thus the 100h, 108h, 110h...
|
||||
addresses.
|
||||
|
||||
<tscreen><verb>
|
||||
device sio1 at isa? port 0x100 tty flags 0x1005
|
||||
device sio2 at isa? port 0x108 tty flags 0x1005
|
||||
device sio3 at isa? port 0x110 tty flags 0x1005
|
||||
device sio4 at isa? port 0x118 tty flags 0x1005
|
||||
[...]
|
||||
device sio15 at isa? port 0x170 tty flags 0x1005
|
||||
device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr
|
||||
</verb></tscreen>
|
||||
|
||||
The flags entry <em>must</em> be changed from
|
||||
this example unless you are using the exact same
|
||||
sio assignments. Flags are set according to
|
||||
0x<em>MYY</em> where <em>M</em> indicates the
|
||||
minor number of the master port (the last port on
|
||||
a Boca 16) and <em>YY</em> indicates if FIFO is
|
||||
enabled or disabled(enabled), IRQ sharing is
|
||||
used(yes) and if there is an AST/4 compatible IRQ
|
||||
control register(no).
|
||||
|
||||
In this example,
|
||||
<tscreen><verb>
|
||||
flags 0x1005
|
||||
</verb></tscreen>
|
||||
|
||||
indicates that the master port is sio16. If I
|
||||
added another board and assigned sio17 through
|
||||
sio28, the flags for all 16 ports on
|
||||
<em>that</em> board would be 0x1C05, where 1C
|
||||
indicates the minor number of the master port.
|
||||
Do not change the 05 setting.</item>
|
||||
|
||||
<item>Save and complete the kernel configuration,
|
||||
recompile, install and reboot.
|
||||
|
||||
Presuming you have successfully installed the
|
||||
recompiled kernel and have it set to the correct
|
||||
address and IRQ, your boot message should
|
||||
indicate the successful probe of the Boca ports
|
||||
as follows: (obviously the sio numbers, IO and
|
||||
IRQ could be different)
|
||||
|
||||
<tscreen><verb>
|
||||
sio1 at 0x100-0x107 flags 0x1005 on isa
|
||||
sio1: type 16550A (multiport)
|
||||
sio2 at 0x108-0x10f flags 0x1005 on isa
|
||||
sio2: type 16550A (multiport)
|
||||
sio3 at 0x110-0x117 flags 0x1005 on isa
|
||||
sio3: type 16550A (multiport)
|
||||
sio4 at 0x118-0x11f flags 0x1005 on isa
|
||||
sio4: type 16550A (multiport)
|
||||
sio5 at 0x120-0x127 flags 0x1005 on isa
|
||||
sio5: type 16550A (multiport)
|
||||
sio6 at 0x128-0x12f flags 0x1005 on isa
|
||||
sio6: type 16550A (multiport)
|
||||
sio7 at 0x130-0x137 flags 0x1005 on isa
|
||||
sio7: type 16550A (multiport)
|
||||
sio8 at 0x138-0x13f flags 0x1005 on isa
|
||||
sio8: type 16550A (multiport)
|
||||
sio9 at 0x140-0x147 flags 0x1005 on isa
|
||||
sio9: type 16550A (multiport)
|
||||
sio10 at 0x148-0x14f flags 0x1005 on isa
|
||||
sio10: type 16550A (multiport)
|
||||
sio11 at 0x150-0x157 flags 0x1005 on isa
|
||||
sio11: type 16550A (multiport)
|
||||
sio12 at 0x158-0x15f flags 0x1005 on isa
|
||||
sio12: type 16550A (multiport)
|
||||
sio13 at 0x160-0x167 flags 0x1005 on isa
|
||||
sio13: type 16550A (multiport)
|
||||
sio14 at 0x168-0x16f flags 0x1005 on isa
|
||||
sio14: type 16550A (multiport)
|
||||
sio15 at 0x170-0x177 flags 0x1005 on isa
|
||||
sio15: type 16550A (multiport)
|
||||
sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa
|
||||
sio16: type 16550A (multiport master)
|
||||
</verb></tscreen>
|
||||
|
||||
If the messages go by too fast to see, <tt>dmesg
|
||||
> more</tt> will show you the boot
|
||||
messages.</item>
|
||||
|
||||
<item>Next, appropriate entries in <tt>/dev</tt> for the devices
|
||||
must be made using the <tt>/dev/MAKEDEV</tt>
|
||||
script. After becoming root:
|
||||
<tscreen>
|
||||
# cd /dev<newline>
|
||||
# ./MAKEDEV tty1<newline>
|
||||
# ./MAKEDEV cua1<newline>
|
||||
<em>(everything in between)</em><newline>
|
||||
# ./MAKEDEV ttyg<newline>
|
||||
# ./MAKEDEV cuag
|
||||
</tscreen>
|
||||
|
||||
If you do not want or need callout devices for some
|
||||
reason, you can dispense with making the <tt>cua*</tt>
|
||||
devices.</item>
|
||||
|
||||
<item>If you want a quick and sloppy way to make
|
||||
sure the devices are working, you can simply plug
|
||||
a modem into each port and (as root) <tt>echo at
|
||||
> ttyd*</tt> for each device you have
|
||||
made. You <em>should</em> see the RX lights flash
|
||||
for each working port.</item>
|
||||
</enum>
|
||||
|
||||
@ -1,302 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!--
|
||||
Copyright 1995 Massachusetts Institute of Technology
|
||||
|
||||
Permission to use, copy, modify, and distribute this software and
|
||||
its documentation for any purpose and without fee is hereby
|
||||
granted, provided that both the above copyright notice and this
|
||||
permission notice appear in all copies, that both the above
|
||||
copyright notice and this permission notice appear in all
|
||||
supporting documentation, and that the name of M.I.T. not be used
|
||||
in advertising or publicity pertaining to distribution of the
|
||||
software without specific, written prior permission. M.I.T. makes
|
||||
no representations about the suitability of this software for any
|
||||
purpose. It is provided "as is" without express or implied
|
||||
warranty.
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY M.I.T. ``AS IS''. M.I.T. DISCLAIMS
|
||||
ALL EXPRESS OR IMPLIED WARRANTIES WITH REGARD TO THIS SOFTWARE,
|
||||
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT
|
||||
SHALL M.I.T. 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.
|
||||
-->
|
||||
|
||||
<sect><heading>S/Key<label id="skey"></heading>
|
||||
|
||||
<p><em>Contributed by &a.wollman;<newline>25 September 1995.</em>
|
||||
|
||||
<p>S/Key is a one-time password scheme based on a one-way hash function
|
||||
(in our version, this is MD4 for compatibility; other versions have
|
||||
used MD5 and DES-MAC). S/Key has been a standard part of all FreeBSD
|
||||
distributions since version 1.1.5, and is also implemented on a large
|
||||
and growing number of other systems. S/Key is a registered trademark
|
||||
of Bell Communications Research, Inc.
|
||||
|
||||
<!-- XXX - is there a better word to use than UNIX? -->
|
||||
<p>There are three different sorts of passwords which we will talk about
|
||||
in the discussion below. The first is your usual UNIX-style or Kerberos
|
||||
password; we will call this a ``UNIX password''. The second sort is the
|
||||
one-time password which is generated by the S/Key `<tt/key/' program and
|
||||
accepted by the `<tt/keyinit/' program and the login prompt; we will call
|
||||
this a ``one-time password''. The final sort of password is the
|
||||
secret password which you give to the `<tt/key/' program (and sometimes the
|
||||
`<tt/keyinit/' program) which it uses to generate one-time passwords; we will
|
||||
call it a ``secret password'' or just unqualified ``password''.
|
||||
|
||||
<p>The secret password does not necessarily have anything to do with your
|
||||
UNIX password (while they can be the same, this is not recommended).
|
||||
While UNIX passwords are limited to eight characters in length, your
|
||||
S/Key secret password can be as long as you like; I use seven-word
|
||||
phrases. In general, the S/Key system operates completely
|
||||
independently of the UNIX password system.
|
||||
|
||||
<p>There are in addition two other sorts of data involved in the S/Key
|
||||
system; one is called the ``seed'' or (confusingly) ``key'', and
|
||||
consists of two letters and five digits, and the other is the
|
||||
``iteration count'' and is a number between 100 and 1. S/Key
|
||||
constructs a one-time password from these components by concatenating
|
||||
the seed and the secret password, then applying a one-way hash (the
|
||||
RSA Data Security, Inc., MD4 secure hash function) iteration-count
|
||||
times, and turning the result into six short English words. The
|
||||
`<tt/login/' and `<tt/su/' programs keep track of the last one-time
|
||||
password used, and the user is authenticated if the hash of the
|
||||
user-provided password is equal to the previous password. Because a
|
||||
one-way hash function is used, it is not possible to generate future
|
||||
one-time passwords having overheard one which was successfully used;
|
||||
the iteration count is decremented after each successful login to keep
|
||||
the user and login program in sync. (When you get the iteration count
|
||||
down to 1, it is time to reinitialize S/Key.)
|
||||
|
||||
<p>There are four programs involved in the S/Key system which we will
|
||||
discuss below. The `<tt/key/' program accepts an iteration count, a
|
||||
seed, and a secret password, and generates a one-time password. The
|
||||
`<tt/keyinit/' program is used to initialized S/Key, and to change
|
||||
passwords, iteration counts, or seeds; it takes either a secret
|
||||
password, or an iteration count, seed, and one-time password. The
|
||||
`<tt/keyinfo/' program examines the <tt>/etc/skeykeys</tt> file and
|
||||
prints out the invoking user's current iteration count and seed.
|
||||
Finally, the `<tt/login/' and `<tt/su/' programs contain the necessary
|
||||
logic to accept S/Key one-time passwords for authentication. The
|
||||
`<tt/login/' program is also capable of disallowing the use of UNIX
|
||||
passwords on connections coming from specified addresses.
|
||||
|
||||
<p>There are four different sorts of operations we will cover. The first
|
||||
is using the `<tt/keyinit/' program over a secure connection to set up
|
||||
S/Key for the first time, or to change your password or seed. The
|
||||
second operation is using the `<tt/keyinit/' program over an insecure
|
||||
connection, in conjunction with the `<tt/key/' program over a secure
|
||||
connection, to do the same. The third is using the `<tt/key/' program to
|
||||
log in over an insecure connection. The fourth is using the `<tt/key/'
|
||||
program to generate a number of keys which can be written down or
|
||||
printed out to carry with you when going to some location without
|
||||
secure connections to anywhere (like at a conference).
|
||||
|
||||
<sect1><heading>Secure connection initialization</heading>
|
||||
|
||||
<p>To initialize S/Key, change your password, or change your seed while
|
||||
logged in over a secure connection (e.g., on the console of a machine),
|
||||
use the `<tt/keyinit/' command without any parameters while logged in as
|
||||
yourself:
|
||||
|
||||
<tscreen><verb>
|
||||
$ keyinit
|
||||
Updating wollman: ) these will not appear if you
|
||||
Old key: ha73895 ) have not used S/Key before
|
||||
Reminder - Only use this method if you are directly connected.
|
||||
If you are using telnet or rlogin exit with no password and use keyinit -s.
|
||||
Enter secret password: ) I typed my pass phrase here
|
||||
Again secret password: ) I typed it again
|
||||
|
||||
ID wollman s/key is 99 ha73896 ) discussed below
|
||||
SAG HAS FONT GOUT FATE BOOM )
|
||||
</verb></tscreen>
|
||||
|
||||
<p>There is a lot of information here. At the `Enter secret password:'
|
||||
prompt, you should enter some password or phrase (I use phrases of
|
||||
minimum seven words) which will be needed to generate login keys. The
|
||||
line starting `ID' gives the parameters of your particular S/Key
|
||||
instance: your login name, the iteration count, and seed. When
|
||||
logging in with S/Key, the system will remember these parameters and
|
||||
present them back to you so you do not have to remember them. The last
|
||||
line gives the particular one-time password which corresponds to those
|
||||
parameters and your secret password; if you were to re-login
|
||||
immediately, this one-time password is the one you would use.
|
||||
|
||||
<sect1><heading>Insecure connection initialization</heading>
|
||||
|
||||
<p>To initialize S/Key or change your password or seed over an insecure
|
||||
connection, you will need to already have a secure connection to some
|
||||
place where you can run the `<tt/key/' program; this might be in the form
|
||||
of a desk accessory on a Macintosh, or a shell prompt on a machine you
|
||||
trust (we will show the latter). You will also need to make up an
|
||||
iteration count (100 is probably a good value), and you may make up
|
||||
your own seed or use a randomly-generated one. Over on the insecure
|
||||
connection (to the machine you are initializing), use the `<tt/keyinit -s/'
|
||||
command:
|
||||
|
||||
<tscreen><verb>
|
||||
$ keyinit -s
|
||||
Updating wollman:
|
||||
Old key: kh94741
|
||||
Reminder you need the 6 English words from the skey command.
|
||||
Enter sequence count from 1 to 9999: 100 ) I typed this
|
||||
Enter new key [default kh94742]:
|
||||
s/key 100 kh94742
|
||||
</verb></tscreen>
|
||||
|
||||
To accept the default seed (which the `keyinit' program confusingly
|
||||
calls a `key'), press return. Then move over to your secure
|
||||
connection or S/Key desk accessory, and give it the same parameters:
|
||||
|
||||
<tscreen><verb>
|
||||
$ key 100 kh94742
|
||||
Reminder - Do not use this program while logged in via telnet or rlogin.
|
||||
Enter secret password: ) I typed my secret password
|
||||
HULL NAY YANG TREE TOUT VETO
|
||||
</verb></tscreen>
|
||||
|
||||
Now switch back over to the insecure connection, and copy the one-time
|
||||
password generated by `<tt/key/' over to the `<tt/keyinit/' program:
|
||||
|
||||
<tscreen><verb>
|
||||
s/key access password: HULL NAY YANG TREE TOUT VETO
|
||||
|
||||
ID wollman s/key is 100 kh94742
|
||||
HULL NAY YANG TREE TOUT VETO
|
||||
</verb></tscreen>
|
||||
|
||||
The rest of the description from the previous section applies here as
|
||||
well.
|
||||
|
||||
<sect1><heading>Diversion: a login prompt</heading>
|
||||
|
||||
<p>Before explaining how to generate one-time passwords, we should go
|
||||
over an S/Key login prompt:
|
||||
|
||||
<tscreen><verb>
|
||||
$ telnet himalia
|
||||
Trying 18.26.0.186...
|
||||
Connected to himalia.lcs.mit.edu.
|
||||
Escape character is '^]'.
|
||||
s/key 92 hi52030
|
||||
Password:
|
||||
</verb></tscreen>
|
||||
|
||||
Note that, before prompting for a password, the login program
|
||||
prints out the iteration number and seed which you will need in order
|
||||
to generate the appropriate key. You will also find a useful feature
|
||||
(not shown here): if you press return at the password prompt, the
|
||||
login program will turn echo on, so you can see what you are typing.
|
||||
This can be extremely useful if you are attempting to type in an S/Key
|
||||
by hand, such as from a printout.
|
||||
|
||||
<p>If this machine were configured to disallow UNIX passwords over a
|
||||
connection from my machine, the prompt would have also included the
|
||||
annotation `<tt>(s/key required)</tt>', indicating that only S/Key one-time
|
||||
passwords will be accepted.
|
||||
|
||||
<sect1><heading>Generating a single one-time password</heading>
|
||||
|
||||
<p>Now, to generate the one-time password needed to answer this login
|
||||
prompt, we use a trusted machine and the `<tt/key/' program. (There are
|
||||
versions of the `<tt/key/' program from DOS and Windows machines, and there
|
||||
is an S/Key desk accessory for Macintosh computers as well.) The
|
||||
command-line `<tt/key/' program takes as its parameters the iteration count
|
||||
and seed; you can cut-and-paste right from the login prompt starting
|
||||
at ``<tt/key/'' to the end of the line. Thus:
|
||||
|
||||
<tscreen><verb>
|
||||
$ key 92 hi52030 ) pasted from previous section
|
||||
Reminder - Do not use this program while logged in via telnet or rlogin.
|
||||
Enter secret password: ) I typed my secret password
|
||||
ADEN BED WOLF HAW HOT STUN
|
||||
</verb></tscreen>
|
||||
|
||||
And in the other window:
|
||||
|
||||
<tscreen><verb>
|
||||
s/key 92 hi52030 ) from previous section
|
||||
Password:
|
||||
(turning echo on)
|
||||
Password:ADEN BED WOLF HAW HOT STUN
|
||||
Last login: Wed Jun 28 15:31:00 from halloran-eldar.l
|
||||
[etc.]
|
||||
</verb></tscreen>
|
||||
|
||||
This is the easiest mechanism <em/if/ you have a trusted machine.
|
||||
|
||||
<sect1><heading>Generating multiple one-time passwords</heading>
|
||||
|
||||
<p>Sometimes we have to go places where no trusted machines or
|
||||
connections are available. In this case, it is possible to use the
|
||||
`<tt/key/' command to generate a number of one-time passwords in the same
|
||||
command; these can then be printed out. For example:
|
||||
|
||||
<tscreen><verb>
|
||||
$ key -n 25 57 zz99999
|
||||
Reminder - Do not use this program while logged in via telnet or rlogin.
|
||||
Enter secret password:
|
||||
33: WALT THY MALI DARN NIT HEAD
|
||||
34: ASK RICE BEAU GINA DOUR STAG
|
||||
[...]
|
||||
56: AMOS BOWL LUG FAT CAIN INCH
|
||||
57: GROW HAYS TUN DISH CAR BALM
|
||||
</verb></tscreen>
|
||||
|
||||
The `<tt/-n 25/' requests twenty-five keys in sequence; the `<tt/57/' indicates
|
||||
the <em/ending/ iteration number; and the rest is as before. Note that
|
||||
these are printed out in <em/reverse/ order of eventual use. If you are
|
||||
really paranoid, you might want to write the results down by hand;
|
||||
otherwise you can cut-and-paste into `<tt/lpr/'. Note that each line shows
|
||||
both the iteration count and the one-time password; you may still find
|
||||
it handy to scratch off passwords as you use them.
|
||||
|
||||
<sect1><heading>Restricting use of UNIX passwords</heading>
|
||||
|
||||
<p>The configuration file <tt>/etc/skey.access</tt> can be used to
|
||||
configure restrictions on the use of UNIX passwords based on the host
|
||||
name, user name, terminal port, or IP address of a login session. The
|
||||
complete format of the file is documented in the <em/skey.access/(5)
|
||||
manual page; there are also some security cautions there which should
|
||||
be read before depending on this file for security.
|
||||
|
||||
<p>If there is no <tt>/etc/skey.access</tt> file (which is the default
|
||||
state as FreeBSD is shipped), then all users will be allowed to use
|
||||
UNIX passwords. If the file exists, however, then all users will be
|
||||
required to use S/Key unless explicitly permitted to do otherwise by
|
||||
configuration statements in the <tt/skey.access/ file. In all cases,
|
||||
UNIX passwords are permitted on the console.
|
||||
|
||||
<p>Here is a sample configuration file which illustrates the three most
|
||||
common sorts of configuration statements:
|
||||
|
||||
<tscreen><verb>
|
||||
permit internet 18.26.0.0 255.255.0.0
|
||||
permit user jrl
|
||||
permit port ttyd0
|
||||
</verb></tscreen>
|
||||
|
||||
The first line (`<tt/permit internet/') allows users whose IP source
|
||||
address (which is vulnerable to spoofing) matches the specified value
|
||||
and mask, to use UNIX passwords. This should not be considered a
|
||||
security mechanism, but rather, a means to remind authorized users
|
||||
that they are using an insecure network and need to use S/Key for
|
||||
authentication.
|
||||
|
||||
<p>The second line (`<tt/permit user/') allows the specified user to
|
||||
use UNIX passwords at any time. Generally speaking, this should only
|
||||
be used for people who are either unable to use the `<tt/key/'
|
||||
program, like those with dumb terminals, or those who are uneducable.
|
||||
|
||||
<p>The third line (`<tt/permit port/') allows all users logging in on
|
||||
the specified terminal line to use UNIX passwords; this would be used
|
||||
for dial-ups.
|
||||
|
||||
@ -1,193 +0,0 @@
|
||||
<!-- $Id$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Setting up a SLIP client<label id="slipc"></heading>
|
||||
|
||||
<p><em>Contributed by &a.asami;<newline>8 Aug 1995.</em>
|
||||
|
||||
The following is one way to set up a FreeBSD machine for SLIP on a
|
||||
static host network. For dynamic hostname assignments (i.e., your
|
||||
address changes each time you dial up), you probably need to do
|
||||
something much fancier.
|
||||
|
||||
<!--
|
||||
This is just "what I did, and it worked for me". I am sharing this
|
||||
just for your reference, I am no expert in SLIP nor networking so your
|
||||
mileage may vary.
|
||||
-->
|
||||
|
||||
First, determine which serial port your modem is connected to. I have
|
||||
a symbolic link <tt>/dev/modem -> cuaa1</tt>, and only use the modem name in my
|
||||
configuration files. It can become quite cumbersome when you need to
|
||||
fix a bunch of files in <tt>/etc</tt> and <tt>.kermrc</tt>'s all over the system! (Note
|
||||
that <tt>/dev/cuaa0</tt> is COM1, <tt>cuaa1</tt> is COM2, etc.)
|
||||
|
||||
Make sure you have
|
||||
<verb>
|
||||
pseudo-device sl 1
|
||||
</verb>
|
||||
in your kernel's config file. It is included in the GENERIC kernel,
|
||||
so this will not be a problem unless you deleted it.
|
||||
|
||||
<sect1><heading>Things you have to do only once</heading>
|
||||
|
||||
<p><enum>
|
||||
<item>Add your home machine, the gateway and nameservers to your
|
||||
<tt>/etc/hosts</tt> file. Mine looks like this:
|
||||
<verb>
|
||||
127.0.0.1 localhost loghost
|
||||
136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia
|
||||
|
||||
136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway
|
||||
128.32.136.9 ns1.Berkeley.edu ns1
|
||||
128.32.136.12 ns2.Berkeley.edu ns2
|
||||
</verb>
|
||||
By the way, silvia is the name of the car that I had when I was
|
||||
back in Japan (it is called 2?0SX here in U.S.).
|
||||
|
||||
<item>Make sure you have "hosts" before "bind" in your <tt>/etc/host.conf</tt>.
|
||||
Otherwise, funny things may happen.
|
||||
|
||||
<item>Edit the file <tt>/etc/sysconfig</tt>.
|
||||
<enum>
|
||||
<item>Set your hostname by editing the line that says:
|
||||
<verb>
|
||||
hostname=myname.my.domain
|
||||
</verb>
|
||||
You should give it your full Internet hostname.
|
||||
|
||||
<item>Add sl0 to the list of network interfaces by changing the line
|
||||
that says:
|
||||
<verb>
|
||||
network_interfaces="lo0"
|
||||
</verb>
|
||||
to:
|
||||
<verb>
|
||||
network_interfaces="lo0 sl0"
|
||||
</verb>
|
||||
|
||||
<item>Set the startup flags of sl0 by adding a line:
|
||||
<verb>
|
||||
ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up"
|
||||
</verb>
|
||||
|
||||
<item>Designate the default router by changing the line:
|
||||
<verb>
|
||||
defaultrouter=NO
|
||||
</verb>
|
||||
to:
|
||||
<verb>
|
||||
defaultrouter=slip-gateway
|
||||
</verb>
|
||||
</enum>
|
||||
|
||||
<item>Make a file <tt>/etc/resolv.conf</tt> which contains:
|
||||
<verb>
|
||||
domain HIP.Berkeley.EDU
|
||||
nameserver 128.32.136.9
|
||||
nameserver 128.32.136.12
|
||||
</verb>
|
||||
As you can see, these set up the nameserver hosts. Of course, the
|
||||
actual domain names and addresses depend on your environment.
|
||||
|
||||
<item>Set the password for root and toor (and any other accounts that
|
||||
does not have a password). Use passwd, do not edit the <tt>/etc/passwd</tt>
|
||||
or <tt>/etc/master.passwd</tt> files!
|
||||
|
||||
<item>Reboot your machine and make sure it comes up with the correct
|
||||
hostname.
|
||||
</enum>
|
||||
|
||||
<sect1><heading>Making a SLIP connection</heading>
|
||||
|
||||
<p><enum>
|
||||
<item>Dial up, type "slip" at the prompt, enter your machine name and
|
||||
password. The things you need to enter depends on your
|
||||
environment. I use kermit, with a script like this:
|
||||
<verb>
|
||||
# kermit setup
|
||||
set modem hayes
|
||||
set line /dev/modem
|
||||
set speed 115200
|
||||
set parity none
|
||||
set flow rts/cts
|
||||
set terminal bytesize 8
|
||||
set file type binary
|
||||
# The next macro will dial up and login
|
||||
define slip dial 643-9600, input 10 =>, if failure stop, -
|
||||
output slip\x0d, input 10 Username:, if failure stop, -
|
||||
output silvia\x0d, input 10 Password:, if failure stop, -
|
||||
output ***\x0d, echo \x0aCONNECTED\x0a
|
||||
</verb>
|
||||
(of course, you have to change the hostname and password to fit
|
||||
yours). Then you can just type "slip" from the kermit prompt to
|
||||
get connected.
|
||||
|
||||
<bf>Note</bf>: leaving your password in plain text anywhere in the
|
||||
filesystem is generally a BAD idea. Do it at your own risk. I am
|
||||
just too lazy.
|
||||
|
||||
<item>Leave the kermit there (you can suspend it by "z") and as root,
|
||||
type
|
||||
<verb>
|
||||
slattach -h -c -s 115200 /dev/modem
|
||||
</verb>
|
||||
if you are able to "ping" hosts on the other side of the router,
|
||||
you are connected! If it does not work, you might want to try "-a"
|
||||
instead of "-c" as an argument to slattach.
|
||||
</enum>
|
||||
|
||||
<sect1><heading>How to shutdown the connection</heading>
|
||||
|
||||
<p>Type "kill -INT `cat /var/run/slattach.modem.pid`" (as root) to
|
||||
kill slattach. Then go back to kermit ("fg" if you suspended it)
|
||||
and exit from it ("q").
|
||||
|
||||
The slattach man page says you have to use "ifconfig sl0 down" to
|
||||
mark the interface down, but this does not seem to make any
|
||||
difference for me. ("ifconfig sl0" reports the same thing.)
|
||||
|
||||
Some times, your modem might refuse to drop the carrier (mine
|
||||
often does). In that case, simply start kermit and quit it again.
|
||||
It usually goes out on the second try.
|
||||
|
||||
<sect1><heading>Troubleshooting</heading>
|
||||
|
||||
<p>If it does not work, feel free to ask me. The things that people
|
||||
tripped over so far:
|
||||
<itemize>
|
||||
<item>Not using "-c" or "-a" in slattach (I have no idea why this can be
|
||||
fatal, but adding this flag solved the problem for at least one
|
||||
person)
|
||||
|
||||
<item>Using "s10" instead of "sl0" (might be hard to see the difference on
|
||||
some fonts).
|
||||
|
||||
<item>Try "ifconfig sl0" to see your interface status. I get:
|
||||
<verb>
|
||||
silvia# ifconfig sl0
|
||||
sl0: flags=10<POINTOPOINT>
|
||||
inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00
|
||||
</verb>
|
||||
|
||||
<item>Also, <tt>netstat -r</tt> will give the routing table, in case you get
|
||||
the "no route to host" messages from ping. Mine looks like:
|
||||
<verb>
|
||||
silvia# netstat -r
|
||||
Routing tables
|
||||
Destination Gateway Flags Refs Use IfaceMTU Rtt
|
||||
Netmasks:
|
||||
(root node)
|
||||
(root node)
|
||||
|
||||
Route Tree for Protocol Family inet:
|
||||
(root node) =>
|
||||
default inr-3.Berkeley.EDU UG 8 224515 sl0 - -
|
||||
localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438
|
||||
inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - -
|
||||
silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438
|
||||
(root node)
|
||||
</verb>
|
||||
(this is after transferring a bunch of files, your numbers should be
|
||||
smaller).
|
||||
</itemize>
|
||||
@ -1,509 +0,0 @@
|
||||
<!-- $Id$
|
||||
This is an SGML version in the linuxdoc DTD of the SLIP Server
|
||||
FAQ by Guy Helmer.
|
||||
|
||||
This guide provides instruction in configuring and preparing
|
||||
a FreeBSD system to be a dialup SLIP server.
|
||||
|
||||
<title>
|
||||
Setting up FreeBSD as a SLIP Server
|
||||
<author>Guy Helmer, <tt/ghelmer@alpha.dsu.edu/
|
||||
<date>v1.0, 15 May 1995
|
||||
|
||||
-->
|
||||
|
||||
<sect><heading>Setting up a SLIP server<label id="slips"></heading>
|
||||
<p><em>Contributed by &a.ghelmer;.<newline>
|
||||
v1.0, 15 May 1995.</em>
|
||||
|
||||
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.
|
||||
|
||||
<sect1><heading>Prerequisites<label id="slips:prereqs"></>
|
||||
|
||||
<p>
|
||||
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 <em>TCP/IP Network
|
||||
Administration</em> 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
|
||||
<tt>http://www.freebsd.org/</tt>; otherwise, check the place
|
||||
where you found this document for a document named <tt/dialup.txt/ or
|
||||
something similar. You may also want to check the manual pages for
|
||||
<tt/sio(4)/ for information on the serial port device driver and
|
||||
<tt/ttys(5)/, <tt/gettytab(5)/, <tt/getty(8)/, & <tt/init(8)/ for
|
||||
information relevant to configuring the system to accept logins on
|
||||
modems, and perhaps <tt/stty(1)/ for information on setting serial
|
||||
port parameters [such as <tt/clocal/ for directly-connected
|
||||
serial interfaces].
|
||||
|
||||
<sect1><heading>Quick Overview</heading>
|
||||
<p>
|
||||
|
||||
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 <tt>/usr/sbin/sliplogin</tt>
|
||||
as the special user's shell. The <tt/sliplogin/ program browses the
|
||||
file <tt>/etc/sliphome/slip.hosts</tt> 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
|
||||
<tt>/etc/sliphome/slip.login</tt> to configure the SLIP interface.
|
||||
|
||||
<sect2><heading>An Example of a SLIP Server Login</heading>
|
||||
<p>
|
||||
|
||||
For example, if a SLIP user ID were <tt>Shelmerg</tt>, <tt/Shelmerg/'s
|
||||
entry in <tt>/etc/master.passwd</tt> would look something like this
|
||||
(except it would be all on one line):
|
||||
|
||||
<tscreen><verb>
|
||||
Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:
|
||||
/usr/users/Shelmerg:/usr/sbin/sliplogin
|
||||
</verb></tscreen>
|
||||
|
||||
and, when <tt/Shelmerg/ logs in, <tt>sliplogin</tt> will search
|
||||
<tt>/etc/sliphome/slip.hosts</tt> for a line that had a matching user
|
||||
ID; for example, there may be a line in
|
||||
<tt>/etc/sliphome/slip.hosts</tt> that reads:
|
||||
|
||||
<tscreen><verb>
|
||||
Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp
|
||||
</verb></tscreen>
|
||||
|
||||
<tt/sliplogin/ will find that matching line, hook the serial line into
|
||||
the next available SLIP interface, and then execute
|
||||
<tt>/etc/sliphome/slip.login</tt> like this:
|
||||
|
||||
<tscreen><verb>
|
||||
/etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp
|
||||
</verb></tscreen>
|
||||
|
||||
If all goes well, <tt>/etc/sliphome/slip.login</tt> will issue an
|
||||
<tt>ifconfig</tt> for the SLIP interface to which <tt/sliplogin/
|
||||
attached itself (slip interface 0, in the above example, which was the
|
||||
first parameter in the list given to <tt>slip.login</tt>) to set the
|
||||
local IP address (<tt>dc-slip</tt>), remote IP address
|
||||
(<tt>sl-helmer</tt>), network mask for the SLIP interface
|
||||
(<tt>0xfffffc00</tt>), and any additional flags (<tt>autocomp</tt>).
|
||||
If something goes wrong, <tt/sliplogin/ usually logs good
|
||||
informational messages via the daemon syslog facility, which usually
|
||||
goes into <tt>/var/log/messages</tt> (see the manual pages for
|
||||
<tt>syslogd(8)</tt> and <tt>syslog.conf(5)</tt>, and perhaps check
|
||||
<tt>/etc/syslog.conf</tt> to see to which files <tt>syslogd</tt> is
|
||||
logging).
|
||||
|
||||
OK, enough of the examples -- let us dive into setting up the system.
|
||||
|
||||
<sect1><heading>Kernel Configuration</heading>
|
||||
<p>
|
||||
FreeBSD's default kernels usually come with two SLIP interfaces
|
||||
defined (<tt>sl0</tt> and <tt>sl1</tt>); you can use <tt>netstat
|
||||
-i</tt> to see whether these interfaces are defined in your kernel.
|
||||
|
||||
Sample output from <tt>netstat -i</tt>:
|
||||
|
||||
<tscreen><verb>
|
||||
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
|
||||
ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133
|
||||
ed0 1500 138.247.224 ivory 291311 0 174209 0 133
|
||||
lo0 65535 <Link> 79 0 79 0 0
|
||||
lo0 65535 loop localhost 79 0 79 0 0
|
||||
sl0* 296 <Link> 0 0 0 0 0
|
||||
sl1* 296 <Link> 0 0 0 0 0
|
||||
</verb></tscreen>
|
||||
|
||||
The <tt>sl0</tt> and <tt>sl1</tt> interfaces shown in <tt>netstat
|
||||
-i</tt>'s output indicate that there are two SLIP interfaces built
|
||||
into the kernel. (The asterisks after the <tt>sl0</tt> and
|
||||
<tt>sl1</tt> 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 <tt>/etc/sysconfig</tt> file and change
|
||||
the setting of the <bf>gateway</bf> variable to <tt>YES</tt>. If you
|
||||
have an older system which does not have the <tt>/etc/sysconfig</tt>
|
||||
file, then add the following command:
|
||||
<verb>
|
||||
sysctl -w net.inet.ip.forwarding = 1
|
||||
</verb>
|
||||
to your <tt>/etc/rc.local</tt> file.
|
||||
|
||||
<p>You will then need to reboot for the new settings to take effect.
|
||||
|
||||
<p>You will notice that near the end of the default kernel configuration
|
||||
file (<tt>/sys/i386/conf/GENERIC</tt>) is a line that reads:
|
||||
|
||||
<tscreen><verb>
|
||||
pseudo-device sl 2
|
||||
</verb></tscreen>
|
||||
|
||||
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 <ref id="kernelconfig" name="Configuring the FreeBSD Kernel">
|
||||
for help in reconfiguring your kernel.
|
||||
|
||||
<sect1><heading>Sliplogin Configuration</heading>
|
||||
|
||||
<p>
|
||||
|
||||
As mentioned earlier, there are three files in the
|
||||
<tt>/etc/sliphome</tt> directory that are part of the configuration
|
||||
for <tt>/usr/sbin/sliplogin</tt> (see <tt>sliplogin(8)</tt> for the
|
||||
actual manual page for <tt>sliplogin</tt>): <tt>slip.hosts</tt>, which
|
||||
defines the SLIP users & their associated IP addresses;
|
||||
<tt>slip.login</tt>, which usually just configures the SLIP interface;
|
||||
and (optionally) <tt>slip.logout</tt>, which undoes
|
||||
<tt>slip.login</tt>'s effects when the serial connection is
|
||||
terminated.
|
||||
|
||||
<sect2><heading>slip.hosts Configuration</heading>
|
||||
|
||||
<p>
|
||||
|
||||
<tt>/etc/sliphome/slip.hosts</tt> contains lines which have at least
|
||||
four items, separated by whitespace:
|
||||
|
||||
<itemize>
|
||||
<item> SLIP user's login ID
|
||||
<item> Local address (local to the SLIP server) of the SLIP link
|
||||
<item> Remote address of the SLIP link
|
||||
<item> Network mask
|
||||
</itemize>
|
||||
|
||||
The local and remote addresses may be host names (resolved to IP
|
||||
addresses by <tt>/etc/hosts</tt> or by the domain name service,
|
||||
depending on your specifications in <tt>/etc/host.conf</tt>), and I
|
||||
believe the network mask may be a name that can be resolved by a
|
||||
lookup into <tt>/etc/networks</tt>. On a sample system,
|
||||
<tt>/etc/sliphome/slip.hosts</tt> looks like this:
|
||||
|
||||
<tscreen><verb>
|
||||
----- 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 ------
|
||||
</verb></tscreen>
|
||||
|
||||
At the end of the line is one or more of the options.
|
||||
|
||||
<itemize>
|
||||
<item> <tt>normal</tt> - no header compression
|
||||
<item> <tt>compress</tt> - compress headers
|
||||
<item> <tt>autocomp</tt> - compress headers if the remote end allows it
|
||||
<item> <tt>noicmp</tt> - disable ICMP packets (so any ``ping'' packets will be
|
||||
dropped instead of using up your bandwidth)
|
||||
</itemize>
|
||||
|
||||
Note that <tt/sliplogin/ under early releases of FreeBSD 2 ignored
|
||||
the options that FreeBSD 1.x recognized, so the options
|
||||
<tt/normal/, <tt/compress/, <tt/autocomp/, and <tt/noicmp/ had no effect
|
||||
until support was added in FreeBSD 2.2 (unless your <tt/slip.login/ script
|
||||
included code to make use of the flags).
|
||||
|
||||
Your choice of local and remote addresses for your SLIP links depends
|
||||
on whether you are going to dedicate a TCP/IP subnet or if you are
|
||||
going to use ``proxy ARP'' on your SLIP server (it is not ``true''
|
||||
proxy ARP, but that is the terminology used in this document to
|
||||
describe it). If you are not sure which method to select or how to
|
||||
assign IP addresses, please refer to the TCP/IP books referenced in
|
||||
the <ref id="slips:prereqs"> 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 <tt>gated</tt> 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
|
||||
<tt>/etc/sliphome/slip.login</tt> and
|
||||
<tt>/etc/sliphome/slip.logout</tt> scripts to use <tt>arp(8)</tt> to
|
||||
manage the proxy-ARP entries in the SLIP server's ARP table.
|
||||
|
||||
<sect2><heading>slip.login Configuration</heading>
|
||||
|
||||
<p>
|
||||
The typical <tt>/etc/sliphome/slip.login</tt> file looks like this:
|
||||
|
||||
<tscreen><verb>
|
||||
----- 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 -----
|
||||
</verb></tscreen>
|
||||
|
||||
This <tt>slip.login</tt> 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
|
||||
<tt>/etc/sliphome/slip.login</tt> file will need to look something
|
||||
like this:
|
||||
|
||||
<tscreen><verb>
|
||||
----- 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" -----
|
||||
</verb></tscreen>
|
||||
|
||||
The additional line in this <tt>slip.login</tt>, <tt>arp -s $5
|
||||
00:11:22:33:44:55 pub</tt>, 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 (<tt>00:11:22:33:44:55</tt>) 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 <tt>netstat -i</tt>; the second line of the output
|
||||
should look something like:
|
||||
|
||||
<tscreen><verb>
|
||||
ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116
|
||||
^^^^^^^^^^^^^^^
|
||||
</verb></tscreen>
|
||||
|
||||
which indicates that this particular system's Ethernet MAC address is
|
||||
<tt>00:02:c1:28:5f:4a</tt> -- the periods in the Ethernet MAC address
|
||||
given by <tt>netstat -i</tt> 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 <tt>arp(8)</tt> desires; see the manual page on
|
||||
<tt>arp(8)</tt> for complete information on usage.
|
||||
|
||||
Note that when you create <tt>/etc/sliphome/slip.login</tt> and
|
||||
<tt>/etc/sliphome/slip.logout</tt>, the ``execute'' bit (ie,
|
||||
<tt>chmod 755 /etc/sliphome/slip.login
|
||||
/etc/sliphome/slip.logout</tt>) must be set, or <tt>sliplogin</tt>
|
||||
will be unable to execute it.
|
||||
|
||||
<sect2><heading>slip.logout Configuration</heading>
|
||||
|
||||
<p>
|
||||
|
||||
<tt>/etc/sliphome/slip.logout</tt> is not strictly needed (unless you
|
||||
are implementing ``proxy ARP''), but if you decide to create it, this
|
||||
is an example of a basic <tt>slip.logout</tt> script:
|
||||
|
||||
<tscreen><verb>
|
||||
----- 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 -----
|
||||
</verb></tscreen>
|
||||
|
||||
If you are using ``proxy ARP'', you will want to have
|
||||
<tt>/etc/sliphome/slip.logout</tt> remove the ARP entry for the SLIP
|
||||
client:
|
||||
|
||||
<tscreen><verb>
|
||||
----- 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" -----
|
||||
</verb></tscreen>
|
||||
|
||||
The <tt>arp -d $5</tt> removes the ARP entry that the ``proxy ARP''
|
||||
<tt>slip.login</tt> added when the SLIP client logged in.
|
||||
|
||||
It bears repeating: make sure <tt>/etc/sliphome/slip.logout</tt> has
|
||||
the execute bit set for after you create it (ie, <tt>chmod 755
|
||||
/etc/sliphome/slip.logout</tt>).
|
||||
|
||||
<sect1><heading>Routing Considerations</heading>
|
||||
|
||||
<p>
|
||||
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
|
||||
<tt>gated</tt> on your FreeBSD SLIP server so that it will tell your
|
||||
routers via appropriate routing protocols about your SLIP subnet.
|
||||
|
||||
<sect2><heading>Static Routes</heading>
|
||||
|
||||
<p>
|
||||
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.
|
||||
|
||||
<sect2><heading>Running gated</heading>
|
||||
|
||||
<p>
|
||||
An alternative to the headaches of static routes is to install
|
||||
<tt>gated</tt> 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. <tt/gated/ is available via anonymous ftp
|
||||
from <tt>ftp.gated.cornell.edu</tt> in the directory
|
||||
<tt>/pub/gated</tt>; I believe the current version as of this writing
|
||||
is <tt>gated-R3_5Alpha_8.tar.Z</tt>, which includes support for
|
||||
FreeBSD ``out-of-the-box''. Complete information and documentation on
|
||||
<tt>gated</tt> is available on the Web starting at
|
||||
<tt>http://www.gated.cornell.edu/</tt>. Compile and install it, and
|
||||
then write a <tt>/etc/gated.conf</tt> file to configure your gated;
|
||||
here is a sample, similar to what the author used on a FreeBSD SLIP
|
||||
server:
|
||||
|
||||
<tscreen><verb>
|
||||
----- 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 -----
|
||||
</verb></tscreen>
|
||||
|
||||
The above sample <tt>gated.conf</tt> file broadcasts routing
|
||||
information regarding the SLIP subnet <tt>xxx.xxx.yy</tt> via RIP onto
|
||||
the Ethernet; if you are using a different Ethernet driver than the
|
||||
<tt/ed/ driver, you will need to change the references to the <tt/ed/
|
||||
interface appropriately. This sample file also sets up tracing to
|
||||
<tt>/var/tmp/gated.output</tt> for debugging <tt>gated</tt>'s
|
||||
activity; you can certainly turn off the tracing options if
|
||||
<tt>gated</tt> works OK for you. You will need to change the
|
||||
<tt>xxx.xxx.yy</tt>'s into the network address of your own SLIP subnet
|
||||
(be sure to change the net mask in the <tt>proto direct</tt> clause as
|
||||
well).
|
||||
|
||||
When you get <tt>gated</tt> built and installed and create a
|
||||
configuration file for it, you will need to run <tt>gated</tt> in place
|
||||
of <tt>routed</tt> on your FreeBSD system; change the
|
||||
<tt>routed/gated</tt> startup parameters in <tt>/etc/netstart</tt> as
|
||||
appropriate for your system. Please see the manual page for
|
||||
<tt>gated</tt> for information on <tt>gated</tt>'s command-line
|
||||
parameters.
|
||||
|
||||
<sect1><heading>Acknowledgments</heading>
|
||||
|
||||
<p>
|
||||
Thanks to these people for comments and advice regarding this tutorial:
|
||||
|
||||
<descrip>
|
||||
<tag/&a.wilko;/
|
||||
|
||||
<tag/Piero Serini/ <Piero@Strider.Inet.IT>
|
||||
</descrip>
|
||||
|
||||
<!-- </article> -->
|
||||
@ -1,108 +0,0 @@
|
||||
<!-- $Id: stable.sgml,v 1.11 1997/05/02 14:15:34 jfieber Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
|
||||
<sect><heading>Staying stable with FreeBSD<label id="stable"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;.</em>
|
||||
|
||||
<!--
|
||||
|
||||
THE FREEBSD STABLE POLICY
|
||||
|
||||
Last updated: $Date: 1997/05/02 14:15:34 $
|
||||
|
||||
This document attempts to explain the rationale behind
|
||||
FreeBSD-stable, what you should expect should you decide to run it,
|
||||
and states some prerequisites for making sure the process goes as
|
||||
smoothly as possible.
|
||||
-->
|
||||
|
||||
<sect1><heading>What is FreeBSD-stable?</heading>
|
||||
|
||||
<p>FreeBSD-stable is our development branch for a more low-key and
|
||||
conservative set of changes intended for our next mainstream release.
|
||||
Changes of an experimental or untested nature do not go into this
|
||||
branch (see <ref id="current" name="FreeBSD-current">).
|
||||
|
||||
<sect1><heading>Who needs FreeBSD-stable?</heading>
|
||||
|
||||
<p>If you are a commercial user or someone who puts maximum stability of
|
||||
their FreeBSD system before all other concerns, you should consider tracking
|
||||
<em>stable</em>. This is especially true if you have installed the most
|
||||
recent release (<url url="ftp://ftp.freebsd.org/pub/FreeBSD/2.1.7-RELEASE"
|
||||
name="2.1.7-RELEASE"> at the time of this writing) since the <em>stable</em>
|
||||
branch is effectively a bug-fix stream relative to the previous release.
|
||||
|
||||
<p>Please note that the <em>stable</em> tree endeavors, above all, to
|
||||
be fully compilable and stable at all times, but we do occasionally
|
||||
make mistakes (these are still active sources with quickly-transmitted
|
||||
updates, after all). We also do our best to thoroughly test fixes in
|
||||
<em>current</em> before bringing them into <em>stable</em>, but sometimes
|
||||
our tests fail to catch every case. If something breaks for you in
|
||||
<em>stable</em>, please let us know <em>immediately!</em> (see
|
||||
next section).
|
||||
|
||||
<sect1><heading>Using FreeBSD-stable</heading>
|
||||
|
||||
<p><enum><item> Join the &a.stable . This will
|
||||
keep you informed of build-dependencies that may appear in
|
||||
<em>stable</em> or any other issues requiring special attention.
|
||||
Developers will also make announcements in this mailing list when
|
||||
they are contemplating some contraversal fix or update, giving
|
||||
the users a chance to respond if they have any issues to raise concerning
|
||||
the proposed change.
|
||||
|
||||
To join this list, send mail to &a.majordomo and say:
|
||||
<verb>
|
||||
subscribe freebsd-stable
|
||||
</verb>
|
||||
In the body of your message. Optionally, you can also say `help'
|
||||
and Majordomo will send you full help on how to subscribe and
|
||||
unsubscribe to the various other mailing lists we support.
|
||||
|
||||
<item> Grab the sources from ftp.FreeBSD.ORG. You can do this in
|
||||
three ways:
|
||||
|
||||
<enum>
|
||||
<item> Use the <ref id="ctm" name="CTM"> facility. Unless you
|
||||
have a good TCP/IP connection at a flat rate, this is
|
||||
the way to do it.
|
||||
|
||||
<item> Use the <ref id="cvsup" name="cvsup"> program with
|
||||
<url url="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/stable-supfile" name="this supfile">.
|
||||
This is the second most recommended method, since it allows
|
||||
you to grab the entire collection once and then only what has
|
||||
changed from then on. Many people run cvsup from cron
|
||||
to keep their sources up-to-date automatically.
|
||||
|
||||
<item> Use ftp. The source tree for FreeBSD-stable is always
|
||||
"exported" on:
|
||||
<htmlurl url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stable"
|
||||
name="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stable">
|
||||
|
||||
<p>We also use `wu-ftpd' which allows compressed/tar'd grabbing
|
||||
of whole trees. e.g. you see:
|
||||
<verb>
|
||||
usr.bin/lex
|
||||
</verb>
|
||||
You can do:
|
||||
<verb>
|
||||
ftp> cd usr.bin
|
||||
ftp> get lex.tar.Z
|
||||
</verb>
|
||||
And it will get the whole directory for you as a compressed
|
||||
tar file.
|
||||
</enum>
|
||||
|
||||
<item> Essentially, if you need rapid on-demand access to the source and
|
||||
communications bandwidth is not a consideration, use cvsup or ftp.
|
||||
Otherwise, use CTM.
|
||||
|
||||
<item> Before compiling stable, read the Makefile in /usr/src
|
||||
carefully. You should at least run a `make world' the first time
|
||||
through as part of the upgrading process.
|
||||
Reading the &a.stable will keep you up-to-date on other bootstrapping
|
||||
procedures that sometimes become necessary as we move towards the next
|
||||
release.
|
||||
</enum>
|
||||
@ -1,619 +0,0 @@
|
||||
<!-- $Id: submitters.sgml,v 1.52 1997/04/23 18:36:37 jkh Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<chapt><heading>Contributing to FreeBSD<label id="submitters"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;.</em>
|
||||
|
||||
<p>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 <em>relies</em> 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!
|
||||
|
||||
<p>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.
|
||||
|
||||
<p>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!
|
||||
|
||||
<p>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.
|
||||
|
||||
<sect><heading>What is needed</heading>
|
||||
|
||||
<p>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?
|
||||
|
||||
<sect1><heading>High priority tasks</heading>
|
||||
<p>The following tasks are considered to be urgent, usually because
|
||||
they represent something that is badly broken or sorely needed:
|
||||
<enum>
|
||||
<item>3-stage boot issues. Overall coordination:
|
||||
&a.hackers
|
||||
<p><itemize>
|
||||
<item>Autodetect memory over 64MB properly.
|
||||
<item>Move userconfig (-c) into 3rd stage boot.
|
||||
<item>Do WinNT compatible drive tagging so that the 3rd stage can
|
||||
provide an accurate mapping of BIOS geometries for disks.
|
||||
</itemize>
|
||||
<item>Filesystem problems. Overall coordination:
|
||||
&a.fs
|
||||
<itemize>
|
||||
<item>Fix the MSDOS file system.
|
||||
<item>Clean up and document the nullfs filesystem code. Coordinator: &a.gibbs
|
||||
<item>Fix the union file system. Coordinator: &a.dyson
|
||||
<item>Fix the LFS file system. Coordinator: &a.dyson
|
||||
</itemize>
|
||||
<item>Implement kernel and user vm86 support. Coordinator: &a.hackers
|
||||
<item>Implement Int13 vm86 disk driver. Coordinator: &a.hackers
|
||||
<item>SCSI driver issues. Overall coordination: &a.hackers
|
||||
<p><itemize>
|
||||
<item>Support tagged queuing generically. Requires a rewrite of how we do
|
||||
our command queuing, but we need this anyway to for prioritized I/O
|
||||
(CD-R writers/scanners).
|
||||
<item>Better error handling (Busy status and retries).
|
||||
<item>Merged Scatter-Gather list creation code.
|
||||
</itemize>
|
||||
<item>Kernel issues. Overall coordination:
|
||||
&a.hackers
|
||||
<p><itemize>
|
||||
<item>Complete the eisaconf conversion of all existing drivers.
|
||||
<item>Change all interrupt routines to take a (void *) instead of
|
||||
using unit numbers.
|
||||
<item>Merge EISA/PCI/ISA interrupt registration code.
|
||||
<item>Split PCI/EISA/ISA probes out from drivers like bt742a.c (WIP)
|
||||
<item>Fix the syscons ALT-TAB/vt switching hangs. Coordinator: &a.sos
|
||||
<item>Mouse support for syscons.
|
||||
<item>Merged keyboard code for all console drivers.
|
||||
<item>Rewrite the Intel Etherexpress 16 driver.
|
||||
<item>Merge the 3c509 and 3c590 drivers (essentially provide a PCI probe for
|
||||
ep.c).
|
||||
<item>Support Adaptec 3985 (first as a simple 3 channel SCSI card)
|
||||
Coordinator: &a.gibbs
|
||||
<item>Support Advansys SCSI controller products. Coordinator: &a.gibbs
|
||||
</itemize>
|
||||
</enum>
|
||||
|
||||
<sect1><heading>Medium priority tasks</heading>
|
||||
<p>The following tasks need to be done, but not with any particular
|
||||
urgency:
|
||||
<enum>
|
||||
<item>DOS emulator (for DOS executables) Coordinator: <tt><url
|
||||
url="mailto:jr@jrw.org" name="J.R. Westmoreland"></tt>
|
||||
<item>Port AFS (Andrew File System) to FreeBSD Coordinator: <tt><url
|
||||
url="mailto:ajones@ctron.com" name="Alexander Seth Jones"></tt>
|
||||
|
||||
<item>MCA support? This should be finalized one way or the other.
|
||||
<item>Full LKM based driver support/Configuration Manager.
|
||||
<p><itemize>
|
||||
<item>Devise a way to do all LKM registration without ld. This means
|
||||
some kind of symbol table in the kernel.
|
||||
<item>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.
|
||||
</itemize>
|
||||
<item>PCMCIA/PCCARD. Coordinators: &a.nate and &a.phk
|
||||
<itemize>
|
||||
<item>Documentation!
|
||||
<item>Reliable operation of the pcic driver (needs testing).
|
||||
<item>Recognizer and handler for sio.c (mostly done).
|
||||
<item>Recognizer and handler for ed.c (mostly done).
|
||||
<item>Recognizer and handler for ep.c (mostly done).
|
||||
<item>User-mode recognizer and handler (partially done).
|
||||
</itemize>
|
||||
<item>Advanced Power Management. Coordinators: &a.nate and &a.phk
|
||||
<itemize>
|
||||
<item>APM sub-driver (mostly done).
|
||||
<item>IDE/ATA disk sub-driver (partially done).
|
||||
<item>syscons/pcvt sub-driver.
|
||||
<item>Integration with the PCMCIA/PCCARD drivers (suspend/resume).
|
||||
</itemize>
|
||||
</enum>
|
||||
|
||||
<sect1><heading>Low priority tasks</heading>
|
||||
<p>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:
|
||||
|
||||
<p>The first 20 items are from Terry Lambert <terry@lambert.org>
|
||||
<enum>
|
||||
<item>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.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>An "upgrade system" option that works on Linux boxes instead
|
||||
of just previous rev FreeBSD boxes.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>Other kernel emulation environments for other foreign drivers
|
||||
as opportunity permits. SCO and Solaris are good candidates,
|
||||
followed by UnixWare, etc.
|
||||
|
||||
<item>Processor emulation environments for execution of foreign binaries.
|
||||
This is easier than it sounds if the system call interface does not
|
||||
change much.
|
||||
|
||||
<item>Streams to allow the use of commercial streams drivers.
|
||||
|
||||
<item>Kernel multithreading (requires kernel preemption).
|
||||
|
||||
<item>Symmetric Multiprocessing with kernel preemption (requires kernel
|
||||
preemption).
|
||||
|
||||
<item>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).
|
||||
|
||||
<item>Reorganization of the source tree for multiple platform ports.
|
||||
|
||||
<item>A "make world" that "makes the world" (rename the current one
|
||||
to "make regress" if that is all it is good for).
|
||||
|
||||
<item>A 4M (preferably smaller!) memory footprint.
|
||||
|
||||
</enum>
|
||||
|
||||
<sect><heading>How to contribute</heading>
|
||||
|
||||
<p>Contributions to the system generally fall into one or more of
|
||||
the following 6 categories:
|
||||
|
||||
<sect1><heading>Bug reports and general commentary</heading>
|
||||
<p>If you have a bug to report or a suggestion to make:
|
||||
|
||||
<itemize>
|
||||
<item>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 <em>high</em>
|
||||
volume of mail!) may
|
||||
subscribe to the hackers mailing list by sending mail to
|
||||
&a.majordomo;.
|
||||
See <ref id="eresources:mail" name="mailing lists">
|
||||
for more information about this and other mailing lists.
|
||||
|
||||
<item>An actual bug report should be filed by using the send-pr(1)
|
||||
program or its <url url="http://www.freebsd.org/send-pr.html"
|
||||
name="WEB based equivalent">. This will prompt you for various
|
||||
fields to fill in. In the send-pr(1) case, simply go to the
|
||||
fields surrounded by <tt><></tt>'s and fill in your own
|
||||
information in place of what is suggested there. With the
|
||||
WEB based interface, you simply select the appropriate items from
|
||||
various option menus and fill in the various fields shown there.
|
||||
|
||||
<p>You should receive confirmation of your bug report along with
|
||||
a tracking number. Please keep this tracking number and refer to
|
||||
it in any subsequent correspondence so that people can find the
|
||||
details of your problem quickly. You may also send mail to
|
||||
<url url="mailto:bug-followup@freebsd.org"
|
||||
name="bug-followup@freebsd.org"> with your PR# in the subject
|
||||
line to append further information to an existing bug report.
|
||||
|
||||
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 <tt>send-pr(1)</tt> command,
|
||||
then you may also file a bug report by sending mail to the &a.bugs;.
|
||||
</itemize>
|
||||
|
||||
<sect1><heading>Changes to the documentation</heading>
|
||||
|
||||
<p>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."
|
||||
|
||||
<sect1><heading>Changes to existing source code</heading>
|
||||
|
||||
<p>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 <ref id="current" name="Staying
|
||||
current with FreeBSD"> for more information about getting and using
|
||||
FreeBSD-current.
|
||||
|
||||
Working from older sources unfortunately means that your changes may
|
||||
sometimes be too obsolete or too divergent for easy re-integration into
|
||||
FreeBSD. Chances of this can be minimized somewhat by subscribing to the
|
||||
&a.announce and the &a.current lists, where discussions
|
||||
on the current state of the system take place.
|
||||
|
||||
Assuming that you can manage to secure fairly up-to-date sources to base
|
||||
your changes on, the next step is to produce a set of diffs to send to the
|
||||
FreeBSD maintainers. This is done with the <tt>diff(1)</tt> command,
|
||||
with the `context diff' form being preferred. For example:
|
||||
<tscreen><verb>
|
||||
diff -c oldfile newfile
|
||||
</verb></tscreen>
|
||||
or
|
||||
<tscreen><verb>
|
||||
diff -c -r olddir newdir
|
||||
</verb></tscreen>
|
||||
would generate such a set of context diffs for the given source file
|
||||
or directory hierarchy. See the man page for <tt>diff(1)</tt> for more
|
||||
details.
|
||||
|
||||
Once you have a set of diffs (which you may test with the
|
||||
<tt>patch(1)</tt> 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 <tt>tar</tt>
|
||||
file and running the <tt>uuencode(1)</tt> program on it before
|
||||
sending the output of that to the &a.hackers;.
|
||||
See the man pages on <tt>tar(1)</tt> and <tt>uuencode(1)</tt> 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 &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
|
||||
<em>very busy</em> and so you should only send mail to them
|
||||
in cases where mailing to hackers is truly impractical.
|
||||
|
||||
Please refer to <tt>man 9 intro</tt> and <tt>man 9 style</tt>
|
||||
for some information on coding style. We would appreciate
|
||||
it if you were at least aware of this information before
|
||||
submitting code.
|
||||
|
||||
<sect1><heading>New code or major value-added packages</heading>
|
||||
|
||||
<p>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
|
||||
uuencode'd tar files or upload them to our ftp site <url
|
||||
url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming">.
|
||||
|
||||
When working with large amounts of code, the touchy subject of
|
||||
copyrights also invariably comes up. Acceptable copyrights
|
||||
for code included in FreeBSD are:
|
||||
|
||||
<enum>
|
||||
<item>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.
|
||||
|
||||
<item>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
|
||||
<tt>/sys/gnu</tt> or <tt>/usr/src/gnu</tt>, and is therefore
|
||||
easily identifiable to anyone for whom the GPL presents a problem.
|
||||
</enum>
|
||||
|
||||
<p>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 `<tt>%%</tt>' with
|
||||
the appropriate information.
|
||||
<tscreen><verb>
|
||||
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$
|
||||
</verb></tscreen>
|
||||
For your convenience, a copy of this text can be found in
|
||||
<tt>/usr/share/examples/etc/bsd-style-copyright</tt>.
|
||||
|
||||
&porting;
|
||||
|
||||
<sect1><heading>Money, Hardware or Internet access</heading>
|
||||
<p>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.
|
||||
|
||||
<sect2><heading>Donating funds</heading>
|
||||
<p>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.
|
||||
|
||||
<p>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:
|
||||
|
||||
<tscreen><verb>
|
||||
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]
|
||||
</verb></tscreen>
|
||||
|
||||
Wire transfers may also be sent directly to:
|
||||
|
||||
<tscreen><verb>
|
||||
Bank Of America
|
||||
Concord Main Office
|
||||
P.O. Box 37176
|
||||
San Francisco CA, 94137-5176
|
||||
|
||||
Routing #: 121-000-358
|
||||
Account #: 01411-07441 (FreeBSD, Inc.)
|
||||
</verb></tscreen>
|
||||
|
||||
If you do not wish to be listed in our <ref id="donors" name="donors">
|
||||
section, please specify this when making your donation. Thanks!
|
||||
|
||||
<sect2><heading>Donating hardware</heading>
|
||||
|
||||
<p>Donations of hardware in any of the 3 following categories are also gladly
|
||||
accepted by the FreeBSD Project:
|
||||
|
||||
<itemize>
|
||||
<item>General purpose hardware such as disk drives, memory or complete
|
||||
systems should be sent to the FreeBSD, Inc. address listed in the
|
||||
<em>donating funds</em> section.
|
||||
|
||||
<item>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.
|
||||
|
||||
<item>Hardware currently unsupported by FreeBSD for which you would like to
|
||||
see such support added. Please contact the &a.core; before sending
|
||||
such items as we will need to find a developer willing to take on the task
|
||||
before we can accept delivery of new hardware.
|
||||
</itemize>
|
||||
|
||||
<sect2><heading>Donating Internet access</heading>
|
||||
|
||||
<p>We can always use new mirror sites for FTP, WWW or cvsup.
|
||||
If you would like to be such a mirror, please contact
|
||||
<url url="mailto:admin@FreeBSD.ORG" name="the FreeBSD project
|
||||
administrators"> for more information.
|
||||
|
||||
<sect><heading>Donors Gallery<label id="donors"></heading>
|
||||
|
||||
<p>The FreeBSD Project is indebted to the following donors and would
|
||||
like to publically thank them here!
|
||||
|
||||
<itemize>
|
||||
<item><bf>Contributors to the central server project:</bf>
|
||||
<p>The following individuals and businesses made it possible for
|
||||
the FreeBSD Project to build a new central server machine to eventually
|
||||
replace <em>freefall.freebsd.org</em> by donating the following items:
|
||||
|
||||
<itemize>
|
||||
<item><url url="mailto:mbarkah@freebsd.org" name="Ade Barkah">
|
||||
and his employer, <url url="http://www.hemi.com"
|
||||
name="Hemisphere Online">, donated a <bf>Pentium Pro (P6) 200Mhz CPU
|
||||
</bf>
|
||||
|
||||
<item><url url="http://www.asacomputers.com" name="ASA Computers">
|
||||
donated a <bf>Tyan 1662 motherboard</bf>.
|
||||
|
||||
<item><url url="mailto:joe@via.net" name="Joe McGuckin"> of
|
||||
<url url="http://www.via.net" name="ViaNet Communications">
|
||||
donated a <bf>Kingston ethernet controller.</bf>
|
||||
|
||||
<item><url url="mailto:jack@diamond.xtalwind.net"
|
||||
name="Jack O'Neill"> donated an <bf>NCR 53C875 SCSI
|
||||
controller card</bf>.
|
||||
|
||||
<item><url url="mailto:ulf@Alameda.net" name="Ulf Zimmermann">
|
||||
of <url url="http://www.Alameda.net" name="Alameda Networks">
|
||||
donated <bf>128MB of memory</bf>, a <bf>4 Gb disk drive
|
||||
and the case.</bf>
|
||||
</itemize>
|
||||
|
||||
<item><bf>Direct funding:</bf>
|
||||
<p>The following individuals and businesses have generously contributed
|
||||
direct funding to the project:
|
||||
|
||||
<itemize>
|
||||
<item><url url="mailto:ANDRSN@HOOVER.STANFORD.EDU"
|
||||
name="Annelise Anderson">
|
||||
|
||||
<item><url url="http://www.epilogue.com/" name="Epilogue
|
||||
Technology Corporation">
|
||||
|
||||
<item>Sean Eric Fagan
|
||||
|
||||
<item><url url="mailto:gmarco@masternet.it"
|
||||
name="Gianmarco Giovannelli">
|
||||
|
||||
<item><url url="mailto:joeg@truenorth.org" name="Josef C. Grosch">
|
||||
|
||||
<item><url url="mailto:chuckr@freebsd.org" name="Chuck Robey">
|
||||
|
||||
<item><url url="mailto:ken@stox.sa.enteract.com"
|
||||
name="Kenneth P. Stox"> of <url url="http://www.imagescape.com"
|
||||
name="Imaginary Landscape, LLC.">
|
||||
|
||||
<item><url url="mailto:dk@dog.farm.org"
|
||||
name="Dmitry S. Kohmanyuk">
|
||||
|
||||
<item><url url="http://www.iijnet.or.jp/laser5/" name="Laser5">
|
||||
of Japan (a portion of the profits from sales of their
|
||||
<em>FreeBSD for PC98'ers</em> CD, a port of FreeBSD to
|
||||
the NEC PC98).
|
||||
</itemize>
|
||||
|
||||
<item><bf>Hardware contributors:</bf>
|
||||
<p>
|
||||
The following individuals and businesses have generously contributed
|
||||
hardware for testing and device driver development/support:
|
||||
|
||||
<itemize>
|
||||
<item>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.
|
||||
|
||||
<item>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!
|
||||
|
||||
<item>Dermot McDonnell donated the Toshiba XM3401B CDROM drive
|
||||
currently used in freefall.
|
||||
|
||||
<item>&a.chuck; contributed his floppy tape streamer for experimental
|
||||
work.
|
||||
|
||||
<item>Larry Altneu <larry@ALR.COM>, and &a.wilko;,
|
||||
provided Wangtek and Archive QIC-02 tape drives in order to
|
||||
improve the <tt>wt</tt> driver.
|
||||
|
||||
<item>Ernst Winter <ewinter@lobo.muc.de> contributed a 2.88 MB
|
||||
floppy drive to the project. This will hopefully increase the
|
||||
pressure for rewriting the floppy disk driver. ;-)
|
||||
|
||||
<item><url url="mailto:kuku@freebsd.org" name="Christoph Kukulies">
|
||||
donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver
|
||||
development.
|
||||
|
||||
</itemize>
|
||||
|
||||
<item><bf>Special contributors:</bf>
|
||||
<p>
|
||||
<itemize>
|
||||
<item><url url="http://www.cdrom.com" name="Walnut Creek CDROM">
|
||||
has donated almost more than we can say (see the
|
||||
<ref id="history" name="history"> document for more details).
|
||||
In particular, we would like to thank them for the original hardware
|
||||
used for <em>freefall.FreeBSD.ORG</em>, our primary development
|
||||
machine, and for <em>thud.FreeBSD.ORG</em>, a testing and build box.
|
||||
We are also indebted to them for funding various contributors over
|
||||
the years and providing us with unrestricted use of their T1
|
||||
connection to the Internet.</item>
|
||||
|
||||
<item>The <url url="http://www.interface-business.de"
|
||||
name="interface business GmbH, Dresden"> has been patiently
|
||||
supporting &a.joerg; who has often preferred FreeBSD work over
|
||||
paywork, and used to fall back to their (quite expensive) EUnet
|
||||
Internet connection whenever his private connection became too
|
||||
slow or flakey to work with it...</item>
|
||||
</itemize>
|
||||
</itemize>
|
||||
@ -1,163 +0,0 @@
|
||||
<!-- $Id: sup.sgml,v 1.28 1997/04/27 00:32:37 asami Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
|
||||
<sect1><heading>SUP<label id="sup"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh; and &a.gclarkii;.</em>
|
||||
|
||||
SUP is a network based software update tool developed at CMU. The
|
||||
purpose of this document is get the beginner up and running with sup.
|
||||
|
||||
<sect2><heading>Configuration<label id="sup:setup"></heading>
|
||||
|
||||
<p>SUP gets the information it needs to run from a configuration file
|
||||
called a supfile. There are different example supfiles provided
|
||||
for different source releases of FreeBSD. The
|
||||
<url url="file:/usr/share/examples/sup/standard-supfile"
|
||||
name="/usr/share/examples/sup/standard-supfile"> file, for example,
|
||||
contains sup information for the latest standard FreeBSD source
|
||||
distributions - it tells sup what collections it will be updating
|
||||
and/or installing and where they go. Someone using this particular
|
||||
supfile is said to be supping <ref id="current" name="-current">.
|
||||
<p>For ports, please have a look at
|
||||
<url url="file:/usr/share/examples/sup/ports-supfile"
|
||||
name="/usr/share/examples/sup/ports-supfile">.<p>
|
||||
If you are interested in obtaining the
|
||||
<url url="http://www.freebsd.org/cgi/cvsweb.cgi" name="CVS"> files
|
||||
that make up the source tree, refer to
|
||||
<url url="file:/usr/share/examples/sup/cvs-supfile"
|
||||
name="/usr/share/examples/sup/cvs-supfile">.<p>
|
||||
If you would rather track changes to the -stable branch, refer to
|
||||
<url url="file:/usr/share/examples/sup/stable-supfile"
|
||||
name="/usr/share/examples/sup/stable-supfile"> instead.
|
||||
|
||||
If you are inside the United States, you may also uncomment
|
||||
the `secure' and `eBones' collection lines to grab the DES code.
|
||||
If you are outside the
|
||||
U.S., you should NOT sup this code from sup.FreeBSD.ORG as this will
|
||||
violate U.S. export restrictions. Instead you should use the
|
||||
<url url="file:/usr/share/examples/sup/secure-supfile"
|
||||
name="secure-supfile"> in the sup examples directory. This will
|
||||
connect you to the international sup site that contains a secure distribution.
|
||||
Any distributions you do not wish to receive can be commented out
|
||||
with a # at the beginning of the distribution line.
|
||||
|
||||
Please consult the file
|
||||
<url url="file:/usr/share/examples/sup/README"
|
||||
name="/usr/share/examples/sup/README">
|
||||
for a list of alternate sup servers. The default sup server (sup.FreeBSD.ORG)
|
||||
listed in the above example files is currently overloaded and any traffic
|
||||
that can be transfered to a different host will help relieve some of
|
||||
the strain.
|
||||
|
||||
Once this is setup, you are ready to go. To start sup type:
|
||||
<verb>
|
||||
sup supfile
|
||||
</verb>
|
||||
If you wish to see what sup is doing "verbosely", give it the -v option,
|
||||
like so:
|
||||
<verb>
|
||||
sup -v supfile
|
||||
</verb>
|
||||
Thats all there is to it! Remember that if you are running current,
|
||||
which is what you will have if you sup with the standard-supfile, please
|
||||
join the &a.current . You should also be sure to read
|
||||
<ref id="current" name="Staying current with FreeBSD">
|
||||
for important information on just what we can and cannot do for you as
|
||||
a -current user. If you are using the stable-supfile, please
|
||||
join the &a.stable and read
|
||||
<ref id="stable" name="Staying stable with FreeBSD">.
|
||||
|
||||
<sect2><heading>Distributions<label id="sup:dists">
|
||||
</heading>
|
||||
|
||||
<p>For the main FreeBSD distribution using the standard-supfile:
|
||||
<verb>
|
||||
src-base: /usr/src/... misc files at the top of /usr/src
|
||||
src-bin: /usr/src/bin user and system binaries
|
||||
src-contrib: /usr/src/contrib contributed software
|
||||
src-secure: /usr/src/secure DES Sources (US/Canada ONLY)
|
||||
src-eBones: /usr/src/eBones Kerberos and DES (US/Canada ONLY)
|
||||
src-etc: /usr/src/etc system files
|
||||
src-games: /usr/src/games games
|
||||
src-gnu: /usr/src/gnu sources under the GNU Public License
|
||||
src-include: /usr/src/include include files
|
||||
src-sys: /usr/src/sys kernel sources
|
||||
src-lib: /usr/src/lib libraries
|
||||
src-libexec: /usr/src/libexec system binaries
|
||||
src-release: /usr/src/release sources required to build a release
|
||||
src-share: /usr/src/share various shared resources
|
||||
src-sbin: /usr/src/sbin single user system binaries
|
||||
src-tools: /usr/src/tools various management tools
|
||||
src-usrbin: /usr/src/usr.bin user binaries
|
||||
src-usrsbin: /usr/src/usr.sbin system binaries
|
||||
</verb>
|
||||
|
||||
<p>For the international FreeBSD distribution using the secure-supfile:
|
||||
<verb>
|
||||
src-secure: /usr/src/secure DES Sources
|
||||
src-eBones: /usr/src/eBones Kerberos and DES
|
||||
</verb>
|
||||
|
||||
<p>There is also a collection including all of the above, except for
|
||||
either (domestic or international) versions of the export-restricted
|
||||
software (i.e., <tt>src-secure</tt> and <tt>src-eBones</tt>
|
||||
collections):
|
||||
<verb>
|
||||
src-all: /usr/src the whole operating system (almost)
|
||||
</verb>
|
||||
|
||||
<p>And for the ports collection:
|
||||
<verb>
|
||||
ports-base: /usr/ports/... misc files at the top of /usr/ports
|
||||
ports-archivers: /usr/ports/archivers archiving tools
|
||||
ports-astro: /usr/ports/astro astronomical ports
|
||||
ports-audio: /usr/ports/audio sound support
|
||||
ports-benchmarks: /usr/ports/benchmarks benchmarks
|
||||
ports-cad: /usr/ports/cad CAD tools
|
||||
ports-chinese: /usr/ports/chinese Chinese support
|
||||
ports-comms: /usr/ports/comms communication software
|
||||
ports-converters: /usr/ports/converters character code converters
|
||||
ports-databases: /usr/ports/databases databases
|
||||
ports-devel: /usr/ports/devel development utilities
|
||||
ports-editors: /usr/ports/editors editors
|
||||
ports-emulators: /usr/ports/emulators emulators for other OSes
|
||||
ports-games: /usr/ports/games games
|
||||
ports-graphics: /usr/ports/graphics various graphics utilities
|
||||
ports-japanese: /usr/ports/japanese Japanese support
|
||||
ports-korean: /usr/ports/korean Korean support
|
||||
ports-lang: /usr/ports/lang programming languages
|
||||
ports-mail: /usr/ports/mail mail software
|
||||
ports-math: /usr/ports/math numerical computation software
|
||||
ports-mbone: /usr/ports/mbone MBone applications
|
||||
ports-misc: /usr/ports/misc miscellaneous utilities
|
||||
ports-net: /usr/ports/net networking software
|
||||
ports-news: /usr/ports/news USENET news software
|
||||
ports-plan9: /usr/ports/plan9 various programs from Plan9
|
||||
ports-print: /usr/ports/print printing software
|
||||
ports-russian: /usr/ports/russian Russian support
|
||||
ports-security: /usr/ports/security ``security'' utilities, for better or for worse
|
||||
ports-shells: /usr/ports/shells various UN*X shells
|
||||
ports-sysutils: /usr/ports/sysutils system utilities
|
||||
ports-textproc: /usr/ports/textproc text processing utilities (does not include desktop publishing)
|
||||
ports-vietnamese: /usr/ports/vietnamese Vietnamese support
|
||||
ports-www: /usr/ports/www software related to the world wide web
|
||||
ports-x11: /usr/ports/x11 X11 software
|
||||
</verb>
|
||||
|
||||
<p>There is also a collection including all of the above:
|
||||
<verb>
|
||||
ports-all: /usr/ports the whole ports tree
|
||||
</verb>
|
||||
|
||||
<!-- The following is currently not available (and probably will never return)
|
||||
<p>If you want to keep updated on the original source of the ports,
|
||||
you can also add this to your supfile. But note that this collection
|
||||
is <em>enormous</em>, and unless you are an ftp site mirroring the
|
||||
entire FreeBSD tree (but cannot use ``mirror'' for some reason), you
|
||||
(and us) are much better off not using sup to collect these:
|
||||
<verb>
|
||||
ports-distfiles: /usr/ports/distfiles original tarballs
|
||||
</verb>
|
||||
-->
|
||||
@ -1,50 +0,0 @@
|
||||
<!-- $Id: synching.sgml,v 1.9 1997/02/22 12:59:32 peter Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect><heading>Synchronizing source trees over the Internet<label id="synching"></heading>
|
||||
|
||||
<p><em>Contributed by &a.jkh;.</em>
|
||||
|
||||
<!--
|
||||
|
||||
Last updated: $Date: 1997/02/22 12:59:32 $
|
||||
|
||||
This document tries to describe the various ways in which a user may
|
||||
use the internet to keep development sources in synch.
|
||||
-->
|
||||
|
||||
<p>There are various ways of using an Internet (or email) connection
|
||||
to stay up-to-date with any given area of the FreeBSD project sources,
|
||||
or all areas, depending on what interests you. The primary
|
||||
services we offer are CVSup and CTM.
|
||||
|
||||
<p><bf>CVSup</bf> is the new kid on the block, it does everything that sup
|
||||
did and more, doing it also far more efficiently in terms of its demands
|
||||
on server disk space and network resources. Because of this, CVSup has
|
||||
largely replaced <ref id="sup"> in the FreeBSD Project. Like sup, it also
|
||||
operates on a <em>pull</em> synchronization model.
|
||||
|
||||
<p><bf>CTM</bf>, on the other hand, does not interactively compare
|
||||
the sources you have with those on the master archive. Instead, a script
|
||||
which identifies changes in files since its previous run is executed several
|
||||
times a day on the master archive, any detected changes being compressed,
|
||||
stamped with a sequence-number and encoded for transmission over email
|
||||
(printable ASCII only). Once received, these "CTM deltas" can then be
|
||||
handed to the ctm_rmail(1) utility which will automatically decode, verify
|
||||
and apply the changes to the user's copy of the sources. This process is
|
||||
far more efficient than CVSup, and places less strain on our server resources
|
||||
since it is a <em>push</em> rather than a <em>pull</em> model.
|
||||
|
||||
<p>There are other trade-offs, of course. With CVSup, you can also
|
||||
inadvertently wipe out portions of your archive and CVSup will detect
|
||||
and rebuild the damaged portions for you. CTM won't do this, and if
|
||||
you wipe some portion of your source tree out (and don't have it backed
|
||||
up) then you will have to start from scratch (from the most recent CVS
|
||||
"base delta") and rebuild it all.
|
||||
|
||||
For more information on CTM, CVSup or the now largely-obsolete sup, please
|
||||
see one of the following sections:
|
||||
|
||||
&ctm;
|
||||
&cvsup;
|
||||
⊃
|
||||
@ -1,539 +0,0 @@
|
||||
<!-- This is an SGML document in the linuxdoc DTD describing
|
||||
hardwired terminals with FreeBSD. By Sean Kelly, (c) 1996.
|
||||
|
||||
$Id$
|
||||
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
||||
<linuxdoc>
|
||||
<article>
|
||||
<title> Hardwired Terminals
|
||||
<author> Sean Kelly <tt/kelly@fsl.noaa.gov/
|
||||
<date> 24 June 1996, (c) 1996
|
||||
|
||||
<abstract> This document describes using hardwired terminals
|
||||
attached to computers running FreeBSD. It describes how to
|
||||
set up the terminal hardware (including cabling), how to
|
||||
configure FreeBSD to provide login sessions to those
|
||||
terminals, and how to troubleshoot problems with terminals.
|
||||
</abstract>
|
||||
|
||||
<toc>
|
||||
-->
|
||||
|
||||
<sect><heading>Terminals<label id="term"></heading>
|
||||
|
||||
<p><em>Contributed by &a.kelly;<newline>28 July 1996</em>
|
||||
|
||||
Terminals provide a convenient and low-cost way to access the
|
||||
power of your FreeBSD system when you are not at the computer's
|
||||
console or on a connected network. This section describes how
|
||||
to use terminals with FreeBSD.
|
||||
|
||||
<sect1><heading>Uses and Types of Terminals<label
|
||||
id="term:uses"></heading>
|
||||
|
||||
<p>The original Unix systems did not have consoles. Instead,
|
||||
people logged in and ran programs through terminals that were
|
||||
connected to the computer's serial ports. It is quite similar
|
||||
to using a modem and some terminal software to dial into a
|
||||
remote system to do text-only work.
|
||||
|
||||
Today's PCs have consoles capable of high quality graphics,
|
||||
but the ability to establish a login session on a serial port
|
||||
still exists in nearly every Unix-style operating system
|
||||
today; FreeBSD is no exception. By using a terminal attached
|
||||
to a unused serial port, you can log in and run any text
|
||||
program that you would normally run on the console or in an
|
||||
<tt/xterm/ window in the X Window System.
|
||||
|
||||
For the business user, you can attach many terminals to a
|
||||
FreeBSD system and place them on your employees' desktops.
|
||||
For a home user, a spare computer such as an older IBM PC or a
|
||||
Macintosh can be a terminal wired into a more powerful
|
||||
computer running FreeBSD. You can turn what might otherwise
|
||||
be a single-user computer into a powerful multiple user
|
||||
system.
|
||||
|
||||
For FreeBSD, there are three kinds of terminals:
|
||||
|
||||
<itemize>
|
||||
<item><ref name="Dumb terminals" id="term:dumb">
|
||||
<item><ref name="PCs acting as terminals" id="term:pcs">
|
||||
<item><ref name="X terminals" id="term:x">
|
||||
</itemize>
|
||||
|
||||
The remaining subsections describe each kind.
|
||||
|
||||
<sect2><heading>Dumb Terminals<label id="term:dumb"></heading>
|
||||
|
||||
<p>Dumb terminals are specialized pieces of hardware that let
|
||||
you connect to computers over serial lines. They are called
|
||||
``dumb'' because they have only enough computational power
|
||||
to display, send, and receive text. You cannot run any
|
||||
programs on them. It is the computer to which you connect
|
||||
them that has all the power to run text editors, compilers,
|
||||
email, games, and so forth.
|
||||
|
||||
There are hundreds of kinds of dumb terminals made by
|
||||
many manufacturers, including Digital Equipment
|
||||
Corporation's VT-100 and Wyse's WY-75. Just about any kind
|
||||
will work with FreeBSD. Some high-end terminals can even
|
||||
display graphics, but only certain software packages can
|
||||
take advantage of these advanced features.
|
||||
|
||||
Dumb terminals are popular in work environments where
|
||||
workers do not need access to graphic applications such as
|
||||
those provided by the X Window System.
|
||||
|
||||
<sect2><heading>PCs Acting As Terminals<label
|
||||
id="term:pcs"></heading>
|
||||
|
||||
<p>If a <ref name="dumb terminal" id="term:dumb"> has just
|
||||
enough ability to display, send, and receive text, then
|
||||
certainly any spare personal computer can be a dumb
|
||||
terminal. All you need is the proper cable and some
|
||||
<em/terminal emulation/ software to run on the computer.
|
||||
|
||||
Such a configuration is popular in homes. For example, if
|
||||
your spouse is busy working on your FreeBSD system's
|
||||
console, you can do some text-only work at the same time
|
||||
from a less powerful personal computer hooked up as a
|
||||
terminal to the FreeBSD system.
|
||||
|
||||
<sect2><heading>X Terminals<label id="term:x"></heading>
|
||||
|
||||
<p>X terminals are the most sophisticated kind of terminal
|
||||
available. Instead of connecting to a serial port, they
|
||||
usually connect to a network like Ethernet. Instead of
|
||||
being relegated to text-only applications, they can display
|
||||
any X application.
|
||||
|
||||
We introduce X terminals just for the sake of completeness.
|
||||
However, this chapter does <em/not/ cover setup,
|
||||
configuration, or use of X terminals.
|
||||
|
||||
<sect1><heading>Cables and Ports<label
|
||||
id="term:cables-ports"></heading>
|
||||
|
||||
<p>To connect a terminal to your FreeBSD system, you need the
|
||||
right kind of cable and a serial port to which to connect it.
|
||||
This section tells you what to do. If you are already
|
||||
familiar with your terminal and the cable it requires, skip to
|
||||
<ref name="Configuration" id="term:config">.
|
||||
|
||||
<sect2><heading>Cables<label id="term:cables"></heading>
|
||||
|
||||
<p>Because terminals use serial ports, you need to use
|
||||
serial---also known as RS-232C---cables to connect the
|
||||
terminal to the FreeBSD system.
|
||||
|
||||
There are a couple of kinds of serial cables. Which one
|
||||
you'll use depends on the terminal you want to connect:
|
||||
|
||||
<itemize>
|
||||
<item>If you are connecting a personal computer to act as
|
||||
a terminal, use a <ref name="null-modem" id="term:null">
|
||||
cable. A null-modem cable connects two computers or
|
||||
terminals together.
|
||||
|
||||
<item>If you have an actual terminal, your best source of
|
||||
information on what cable to use is the documentation
|
||||
that accompanied the terminal. If you do not have the
|
||||
documentation, then try a <ref name="null-modem"
|
||||
id="term:null"> cable. If that does not work, then try
|
||||
a <ref name="standard" id="term:std"> cable.
|
||||
</itemize>
|
||||
|
||||
Also, the serial port on <em/both/ the terminal and your
|
||||
FreeBSD system must have connectors that will fit the cable
|
||||
you are using.
|
||||
|
||||
<sect3><heading>Null-modem cables<label id="term:null"></heading>
|
||||
|
||||
<p>A null-modem cable passes some signals straight through,
|
||||
like ``signal ground,'' but switches other signals. For
|
||||
example, the ``send data'' pin on one end goes to the
|
||||
``receive data'' pin on the other end.
|
||||
|
||||
If you like making your own cables, here is a table
|
||||
showing a recommended way to construct a null-modem cable
|
||||
for use with terminals. This table shows the RS-232C
|
||||
signal names and the pin numbers on a DB-25 connector.
|
||||
<tscreen><verb>
|
||||
Signal Pin# Pin# Signal
|
||||
TxD 2 ----------------------- 3 RxD
|
||||
RxD 3 ----------------------- 2 TxD
|
||||
DTR 20 ----------------------- 6 DSR
|
||||
DSR 6 ----------------------- 20 DTR
|
||||
SG 7 ----------------------- 7 SG
|
||||
DCD 8 ----------------------+ 4 RTS*
|
||||
*RTS 4 + + 5 CTS*
|
||||
*CTS 5 +---------------------- 8 DCD
|
||||
|
||||
* Connect pins 4 to 5 internally in the connector hood, and then to
|
||||
pin 8 in the remote hood.
|
||||
</verb></tscreen>
|
||||
|
||||
<sect3><heading>Standard RS-232C Cables<label
|
||||
id="term:std"></heading>
|
||||
|
||||
<p>A standard serial cable passes all the RS-232C signals
|
||||
straight-through. That is, the ``send data'' pin on one
|
||||
end of the cable goes to the ``send data'' pin on the
|
||||
other end. This is the type of cable to connect a modem
|
||||
to your FreeBSD system, and the type of cable needed for
|
||||
some terminals.
|
||||
|
||||
<sect2><heading>Ports<label id="term:ports"></heading>
|
||||
|
||||
<p>Serial ports are the devices through which data is
|
||||
transferred between the FreeBSD host computer and the
|
||||
terminal. This section describes the kinds of ports that
|
||||
exist and how they are addressed in FreeBSD.
|
||||
|
||||
<sect3><heading>Kinds of Ports<label
|
||||
id="term:portkinds"></heading>
|
||||
|
||||
<p>Several kinds of serial ports exist. Before you purchase
|
||||
or construct a cable, you need to make sure it will fit
|
||||
the ports on your terminal and on the FreeBSD system.
|
||||
|
||||
Most terminals will have DB25 ports. Personal computers,
|
||||
including PCs running FreeBSD, will have DB25 or DB9
|
||||
ports. If you have a multiport serial card for your PC,
|
||||
you may have RJ-12 or RJ-45 ports.
|
||||
|
||||
See the documentation that accompanied the hardware for
|
||||
specifications on the kind of port in use. A visual
|
||||
inspection of the port often works, too.
|
||||
|
||||
<sect3><heading>Port Names<label
|
||||
id="term:portnames"></heading>
|
||||
|
||||
<p>In FreeBSD, you access each serial port through an entry
|
||||
in the <tt>/dev</tt> directory. There are two different
|
||||
kinds of entries:
|
||||
<itemize>
|
||||
<item>Callin ports are named <tt>/dev/ttyd<it/X/</tt>
|
||||
where <it/X/ is the port number, starting from zero.
|
||||
Generally, you use the callin port for terminals.
|
||||
Callin ports require that the serial line assert the
|
||||
data carrier detect (DCD) signal to work.
|
||||
|
||||
<item>Callout ports are named <tt>/dev/cuaa<it/X/</tt>.
|
||||
You usually do not use the callout port for terminals,
|
||||
just for modems. You may use the callout port if the
|
||||
serial cable or the terminal does not support the
|
||||
carrier detect signal.
|
||||
</itemize>
|
||||
|
||||
See the sio(4) manual page for more information.
|
||||
|
||||
If you have connected a terminal to the first serial port
|
||||
(COM1 in DOS parlance), then you want to use
|
||||
<tt>/dev/ttyd0</tt> to refer to the terminal. If it is on
|
||||
the second serial port (also known as COM2), it is
|
||||
<tt>/dev/ttyd1</tt>, and so forth.
|
||||
|
||||
Note that you may have to configure your kernel to support
|
||||
each serial port, especially if you have a multiport
|
||||
serial card. See <ref name="Configuring the FreeBSD
|
||||
Kernel" id="kernelconfig"> for more information.
|
||||
|
||||
<sect1><heading>Configuration<label id="term:config"></heading>
|
||||
|
||||
<p>This section describes what you need to configure on your
|
||||
FreeBSD system to enable a login session on a terminal. It
|
||||
assumes you have already configured your kernel to support the
|
||||
serial port to which the terminal is connected---and that you
|
||||
have connected it.
|
||||
|
||||
In a nutshell, you need to tell the <tt/init/ process, which is
|
||||
responsible for process control and initialization, to start a
|
||||
<tt/getty/ process, which is responsible for reading a login
|
||||
name and starting the <tt/login/ program.
|
||||
|
||||
To do so, you have to edit the <tt>/etc/ttys</tt> file.
|
||||
First, use the <tt/su/ command to become root. Then, make the
|
||||
following changes to <tt>/etc/ttys</tt>:
|
||||
<enum>
|
||||
<item>Add an line to <tt>/etc/ttys</tt> for the entry in the
|
||||
<tt>/dev</tt> directory for the serial port if it is not
|
||||
already there.
|
||||
|
||||
<item>Specify that <tt>/usr/libexec/getty</tt> be run on the
|
||||
port, and specify the appropriate <tt/getty/ type from the
|
||||
<tt>/etc/gettytab</tt> file.
|
||||
|
||||
<item>Specify the default terminal type.
|
||||
|
||||
<item>Set the port to ``on.''
|
||||
|
||||
<item>Specify whether the port should be ``secure.''
|
||||
|
||||
<item>Force <tt/init/ to reread the <tt>/etc/ttys</tt> file.
|
||||
</enum>
|
||||
|
||||
As an optional step, you may wish to create a custom
|
||||
<tt/getty/ type for use in step 2 by making an entry in
|
||||
<tt>/etc/gettytab</tt>. This document does not explain how to
|
||||
do so; you are encouraged to see the gettytab(5) and the
|
||||
getty(8) manual pages for more information.
|
||||
|
||||
The remaining sections detail how to do these steps. We will
|
||||
use a running example throughout these sections to illustrate
|
||||
what we need to do. In our example, we will connect two
|
||||
terminals to the system: a Wyse-50 and a old 286 IBM PC
|
||||
running Procomm terminal software emulating a VT-100 terminal.
|
||||
We connect the Wyse to the second serial port and the 286 to
|
||||
the sixth serial port (a port on a multiport serial card).
|
||||
|
||||
For more information on the <tt>/etc/ttys</tt> file, see the
|
||||
ttys(5) manual page.
|
||||
|
||||
<sect2><heading>Adding an Entry to <tt>/etc/ttys</tt><label
|
||||
id="term:etcttys"></heading>
|
||||
<p>First, you need to add an entry to the <tt>/etc/ttys</tt>
|
||||
file, unless one is already there.
|
||||
|
||||
The <tt>/etc/ttys</tt> file lists all of the ports on your
|
||||
FreeBSD system where you want to allow logins. For example,
|
||||
the first virtual console <tt>ttyv0</tt> has an entry in
|
||||
this file. You can log in on the console using this entry.
|
||||
This file contains entries for the other virtual consoles,
|
||||
serial ports, and pseudo-ttys. For a hardwired terminal,
|
||||
just list the serial port's <tt>/dev</tt> entry without the
|
||||
<tt>/dev</tt> part.
|
||||
|
||||
When you installed your FreeBSD system, the
|
||||
<tt>/etc/ttys</tt> file included entries for the first four
|
||||
serial ports: <tt/ttyd0/ through <tt/ttyd3/. If you are
|
||||
attaching a terminal on one of those ports, you do not need
|
||||
to add an entry.
|
||||
|
||||
In our example, we attached a Wyse-50 to the second serial
|
||||
port, <tt/ttyd1/, which is already in the file. We need to
|
||||
add an entry for the 286 PC connected to the sixth serial
|
||||
port. Here is an excerpt of the <tt>/etc/ttys</tt> file
|
||||
after we add the new entry:
|
||||
<tscreen><verb>
|
||||
ttyd1 "/usr/libexec/getty std.9600" unknown off secure
|
||||
ttyd5
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>Specifying the <tt/getty/ Type<label
|
||||
id="term:getty"></heading>
|
||||
<p>Next, we need to specify what program will be run to handle
|
||||
the logins on a terminal. For FreeBSD, the standard program
|
||||
to do that is <tt>/usr/libexec/getty</tt>. It is what
|
||||
provides the <tt>login:</tt> prompt.
|
||||
|
||||
The program <tt/getty/ takes one (optional) parameter on its
|
||||
command line, the <em/<tt/getty/ type/. A <tt/getty/ type
|
||||
tells about characteristics on the terminal line, like bps
|
||||
rate and parity. The <tt/getty/ program reads these
|
||||
characteristics from the file <tt>/etc/gettytab</tt>.
|
||||
|
||||
The file <tt>/etc/gettytab</tt> contains lots of entries for
|
||||
terminal lines both old and new. In almost all cases, the
|
||||
entries that start with the text <tt/std/ will work for
|
||||
hardwired terminals. These entries ignore parity. There is
|
||||
a <tt/std/ entry for each bps rate from 110 to 115200. Of
|
||||
course, you can add your own entries to this file. The
|
||||
manual page gettytab(5) provides more information.
|
||||
|
||||
When setting the <tt/getty/ type in the <tt>/etc/ttys</tt>
|
||||
file, make sure that the communications settings on the
|
||||
terminal match.
|
||||
|
||||
For our example, the Wyse-50 uses no parity and connects at
|
||||
38400 bps. The 286 PC uses no parity and connects at 19200
|
||||
bps. Here is the <tt>/etc/ttys</tt> file so far (showing
|
||||
just the two terminals in which we are interested):
|
||||
<tscreen><verb>
|
||||
ttyd1 "/usr/libexec/getty std.38400" unknown off secure
|
||||
ttyd5 "/usr/libexec/getty std.19200"
|
||||
</verb></tscreen>
|
||||
Note that the second field---where we specify what program
|
||||
to run---appears in quotes. This is important, otherwise
|
||||
the type argument to <tt/getty/ might be interpreted as the
|
||||
next field.
|
||||
|
||||
<sect2><heading>Specifying the Default Terminal Type<label
|
||||
id="term:deftermtype"></heading>
|
||||
|
||||
<p>The third field in the <tt>/etc/ttys</tt> file lists the
|
||||
default terminal type for the port. For dialup ports, you
|
||||
typically put <tt/unknown/ or <tt/dialup/ in this field
|
||||
because users may dial up with practically any kind of
|
||||
terminal or software. For hardwired terminals, the terminal
|
||||
type does not change, so you can put a real terminal type in
|
||||
this field.
|
||||
|
||||
Users will usually use the <tt/tset/ program in
|
||||
their <tt/.login/ or <tt/.profile/ files to check the terminal
|
||||
type and prompt for one if necessary. By setting a terminal
|
||||
type in the <tt>/etc/ttys</tt> file, users can forego such
|
||||
prompting.
|
||||
|
||||
To find out what terminal types FreeBSD supports, see the
|
||||
file <tt>/usr/share/misc/termcap</tt>. It lists about 600
|
||||
terminal types. You can add more if you wish. See the
|
||||
termcap(5) manual page for information.
|
||||
|
||||
In our example, the Wyse-50 is a Wyse-50 type of terminal
|
||||
(although it can emulate others, we will leave it in Wyse-50
|
||||
mode). The 286 PC is running Procomm which will be set to
|
||||
emulate a VT-100. Here are the pertinent yet unfinished
|
||||
entries from the <tt>/etc/ttys</tt> file:
|
||||
<tscreen><verb>
|
||||
ttyd1 "/usr/libexec/getty std.38400" wy50 off secure
|
||||
ttyd5 "/usr/libexec/getty std.19200" vt100
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>Enabling the Port<label
|
||||
id="term:enable"></heading>
|
||||
<p>The next field in <tt>/etc/ttys</tt>, the fourth field,
|
||||
tells whether to enable the port. Putting <tt/on/ here will
|
||||
have the <tt/init/ process start the program in the second
|
||||
field, <tt/getty/, which will prompt for a login. If you
|
||||
put <tt/off/ in the fourth field, there will be no
|
||||
<tt/getty/, and hence no logins on the port.
|
||||
|
||||
So, naturally, you want an <tt/on/ in this field. Here
|
||||
again is the <tt>/etc/ttys</tt> file. We have turned each
|
||||
port <tt/on/.
|
||||
<tscreen><verb>
|
||||
ttyd1 "/usr/libexec/getty std.38400" wy50 on secure
|
||||
ttyd5 "/usr/libexec/getty std.19200" vt100 on
|
||||
</verb></tscreen>
|
||||
|
||||
|
||||
<sect2><heading>Specifying Secure Ports<label
|
||||
id="term:secure"></heading>
|
||||
<p>We have arrived at the last field (well, almost: there is
|
||||
an optional <tt/window/ specifier, but we will ignore that).
|
||||
The last field tells whether the port is secure.
|
||||
|
||||
What does ``secure'' mean?
|
||||
|
||||
It means that the root account (or any account with a user
|
||||
ID of 0) may login on the port. Insecure ports do not
|
||||
allow root to login.
|
||||
|
||||
How do you use secure and insecure ports?
|
||||
|
||||
By marking a port as insecure, the terminal to which it is
|
||||
connected will not allow root to login. People who know
|
||||
the root password to your FreeBSD system will first have to
|
||||
login using a regular user account. To gain superuser
|
||||
privileges, they will then have to use the <tt/su/ command.
|
||||
|
||||
Because of this, you will have two records to help track
|
||||
down possible compromises of root privileges: both the login
|
||||
and the <tt/su/ command make records in the system log (and
|
||||
logins are also recorded in the <tt/wtmp/ file).
|
||||
|
||||
By marking a port as secure, the terminal will allow root
|
||||
in. People who know the root password will just login as
|
||||
root. You will not have the potentially useful login and
|
||||
<tt/su/ command records.
|
||||
|
||||
Which should you use?
|
||||
|
||||
Just use ``insecure.'' Use ``insecure'' <em/even/ for
|
||||
terminals <em/not/ in public user areas or behind locked
|
||||
doors. It is quite easy to login and use <tt/su/ if you
|
||||
need superuser privileges.
|
||||
|
||||
Here finally are the completed entries in the
|
||||
<tt>/etc/ttys</tt> file, with comments added to describe
|
||||
where the terminals are:
|
||||
<tscreen><verb>
|
||||
ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen
|
||||
ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>Force <tt/init/ to Reread
|
||||
<tt>/etc/ttys</tt><label id="term:hup"></heading>
|
||||
<p>When you boot FreeBSD, the first process, <tt/init/, will
|
||||
read the <tt>/etc/ttys</tt> file and start the programs
|
||||
listed for each enabled port to prompt for logins.
|
||||
|
||||
After you edit <tt>/etc/ttys</tt>, you do not want to have
|
||||
to reboot your system to get <tt/init/ to see the changes.
|
||||
So, <tt/init/ will reread <tt>/etc/ttys</tt> if it receives
|
||||
a SIGHUP (hangup) signal.
|
||||
|
||||
So, after you have saved your changes to <tt>/etc/ttys</tt>,
|
||||
send SIGHUP to <tt/init/ by typing:
|
||||
<tscreen><verb>
|
||||
kill -HUP 1
|
||||
</verb></tscreen>
|
||||
(The <tt/init/ process <em/always/ has process ID 1.)
|
||||
|
||||
If everything is set up correctly, all cables are in place,
|
||||
and the terminals are powered up, you should see login
|
||||
prompts. Your terminals are ready for their first logins!
|
||||
|
||||
<sect1><heading>Debugging your connection<label
|
||||
id="term:debug"></heading>
|
||||
<p>Even with the most meticulous attention to detail, something
|
||||
could still go wrong while setting up a terminal. Here is a
|
||||
list of symptoms and some suggested fixes.
|
||||
|
||||
<descrip>
|
||||
<tag/No login prompt appears/
|
||||
|
||||
Make sure the terminal is plugged in and powered up. If
|
||||
it is a personal computer acting as a terminal, make sure
|
||||
it is running terminal emulation software on the correct
|
||||
serial port.
|
||||
|
||||
Make sure the cable is connected firmly to both the
|
||||
terminal and the FreeBSD computer. Make sure it is the
|
||||
right kind of cable.
|
||||
|
||||
Make sure the terminal and FreeBSD agree on the bps rate
|
||||
and parity settings. If you have a video display
|
||||
terminal, make sure the contrast and brightness controls
|
||||
are turned up. If it is a printing terminal, make sure
|
||||
paper and ink are in good supply.
|
||||
|
||||
Make sure that a <tt/getty/ process is running and serving
|
||||
the terminal. Type
|
||||
<tscreen><verb>
|
||||
ps -axww|grep getty
|
||||
</verb></tscreen>
|
||||
to get a list of running <tt/getty/ processes. You should
|
||||
see an entry for the terminal. For example, the display
|
||||
<tscreen><verb>
|
||||
22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1
|
||||
</verb></tscreen>
|
||||
shows that a <tt/getty/ is running on the second serial
|
||||
port <tt/ttyd1/ and is using the <tt/std.38400/ entry in
|
||||
<tt>/etc/gettytab</tt>.
|
||||
|
||||
If no <tt/getty/ process is running, make sure you have
|
||||
enabled the port in <tt>/etc/ttys</tt>. Make sure you
|
||||
have run <tt/kill -HUP 1/.
|
||||
|
||||
<tag/Garbage appears instead of a login prompt/
|
||||
|
||||
Make sure the terminal and FreeBSD agree on the bps rate
|
||||
and parity settings. Check the getty processes to make
|
||||
sure the correct <tt/getty/ type is in use. If not, edit
|
||||
<tt>/etc/ttys</tt> and run <tt/kill -HUP 1/.
|
||||
|
||||
<tag/Characters appear doubled; the password appears when typed/
|
||||
|
||||
Switch the terminal (or the terminal emulation software)
|
||||
from ``half duplex'' or ``local echo'' to ``full duplex.''
|
||||
|
||||
</descrip>
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,751 +0,0 @@
|
||||
<!-- $Id: userppp.sgml,v 1.16 1997/05/12 16:29:48 brian Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
|
||||
<sect>Setting up user PPP<label id="userppp">
|
||||
|
||||
<!-- This FAQ/HowTo is intended to get you up and running with
|
||||
iijppp, also known as <em>user level ppp</em> or just
|
||||
simply <em>ppp</em> for FreeBSD 2.0.5 and above.
|
||||
|
||||
<p>It also outlines how to use iijppp as a ppp server.
|
||||
|
||||
<p>This document has originally written by Nik Clayton, and has
|
||||
turned into a collaborative effort over the years.
|
||||
|
||||
-->
|
||||
|
||||
<p>User PPP was introduced to FreeBSD in release 2.0.5 as an
|
||||
addition to the existing kernel implementation of PPP. So,
|
||||
what is different about this new PPP that warrants its
|
||||
addition? To quote from the manual page:
|
||||
|
||||
<quote>
|
||||
This is a user process PPP software package. Normally, PPP is
|
||||
implemented as a part of the kernel (e.g. as managed by pppd) and
|
||||
it is thus somewhat hard to debug and/or modify its behavior. However,
|
||||
in this implementation PPP is done as a user process with the help of
|
||||
the tunnel device driver (tun).
|
||||
</quote>
|
||||
|
||||
In essence, this means that rather than running a PPP daemon, the ppp
|
||||
program can be run as and when desired. No PPP interface needs to be
|
||||
compiled into the kernel, as the program can use the generic tunnel
|
||||
device to get data into and out of the kernel.
|
||||
|
||||
From here on out, user ppp will be referred to simply as ppp unless a
|
||||
distinction needs to be made between it and any other PPP client/server
|
||||
software. Unless otherwise stated, all commands in this section should
|
||||
be executed as root.
|
||||
|
||||
<sect1><heading>Before you start</heading>
|
||||
|
||||
<p>This document assumes you are in roughly this position:
|
||||
|
||||
You have an account with an Internet Service Provider (ISP) which lets you
|
||||
use PPP. Further, you have a modem (or other device) connected and
|
||||
configured correctly which allows you to connect to your ISP.
|
||||
|
||||
You are going to need the following information to hand:
|
||||
|
||||
<itemize>
|
||||
<item>The IP address of your ISP's gateway. The gateway is the
|
||||
machine to which you will connect and will
|
||||
be set up as your <tt>default route</tt>.
|
||||
|
||||
<item>Your ISP's netmask setting. If you can't determine this,
|
||||
assume a netmask of 0xffffff00.
|
||||
|
||||
<item>The IP addresses of one or more nameservers. Normally, you
|
||||
will be given two IP numbers.
|
||||
|
||||
<item>If your ISP allocates you a static IP address and/or hostname
|
||||
then you will need that as well. If not, you will need to know
|
||||
from what range of IP addresses your allocated IP address will
|
||||
belong. If you havn't been given this range, you can accept
|
||||
any IP number (as explained later).
|
||||
</itemize>
|
||||
|
||||
If you do not have any of this information then contact your ISP and make
|
||||
sure they provide it to you.
|
||||
|
||||
In addition, it is assumed that because your connection to the
|
||||
Internet is not full time you are not running a name server
|
||||
(<tt>named(8)</tt>). If this is not the case, ignore any
|
||||
information on setting up the <tt>/etc/resolv.conf</tt> file.
|
||||
|
||||
<sect1><heading>Building a ppp ready kernel</heading>
|
||||
|
||||
<p>As the description states, ``ppp'' uses the kernel ``tun'' device.
|
||||
It is necessary to make sure that your kernel has support for this
|
||||
device compiled in.
|
||||
|
||||
To check this, go to your kernel compile directory (probably
|
||||
/sys/i386/conf) and examine your kernel configuration file.
|
||||
It needs to have the line
|
||||
|
||||
<tscreen><verb>
|
||||
pseudo-device tun 1
|
||||
</verb></tscreen>
|
||||
|
||||
in it somewhere. The stock GENERIC kernel has this as standard, so
|
||||
if you have not installed a custom kernel or you do not have a /sys
|
||||
directory, you do not have to change anything.
|
||||
If your kernel configuration file does not have this line in it, or
|
||||
you need to configure more than one tun device (for example, if
|
||||
you are setting up a server and could have 16 dialup ppp connections
|
||||
at any one time then you will need to use ``16'' instead of ``1''),
|
||||
then you should add the line, re-compile, re-install and boot the new
|
||||
kernel. Please refer to the
|
||||
<ref id="kernelconfig" name="Configuring the FreeBSD Kernel">
|
||||
section for more information on kernel configuration.
|
||||
|
||||
<p>You can check how many tunnel devices your current kernel has by
|
||||
typing the following:
|
||||
|
||||
<tscreen><verb>
|
||||
# ifconfig -a
|
||||
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
|
||||
inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff
|
||||
tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576
|
||||
tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
|
||||
inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff
|
||||
tun3: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500
|
||||
</verb></tscreen>
|
||||
|
||||
which in this case shows four tunnel devices, two of which are
|
||||
currently configured and being used.
|
||||
|
||||
<p>If you have a kernel without the tun device, and you can not
|
||||
rebuild it for some reason, all is not lost. You should be
|
||||
able to dynamically load the code. Refer to the appropriate
|
||||
modload(8) and lkm(4) pages for further details.
|
||||
|
||||
<p>You may also wish to take this opportunity to configure a firewall.
|
||||
Details can be found in the <ref id="firewalls" name="Firewalls">
|
||||
section.
|
||||
|
||||
<sect1><heading>Check the tun device</heading>
|
||||
|
||||
<p>Most users will only require one ``tun'' device (tun0). If you have
|
||||
used more (i.e., a number other than `1' in the pseudo-device line
|
||||
in the kernel configuration file) then alter all references to ``tun0''
|
||||
below to reflect whichever device number you are using.
|
||||
|
||||
The easiest way to make sure that the tun0 device is configured correctly
|
||||
is to re-make it. To this end, execute the following commands:
|
||||
|
||||
<tscreen><verb>
|
||||
# cd /dev
|
||||
# ./MAKEDEV tun0
|
||||
</verb></tscreen>
|
||||
|
||||
<p>If you require 16 tunnel devices in your kernel, you will need to
|
||||
create more than just tun0:
|
||||
|
||||
<tscreen><verb>
|
||||
# cd /dev
|
||||
# ./MAKEDEV tun0 tun1 tun2 tun3 tun4 tun5 tun6 tun7 tun8 tun9
|
||||
# ./MAKEDEV tun10 tun11 tun12 tun13 tun14 tun15
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Also, to confirm that the kernel is configured correctly,
|
||||
the following command should give the indicated output:
|
||||
|
||||
<tscreen><verb>
|
||||
$ ifconfig tun0
|
||||
tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500
|
||||
$
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>PPP Name Resolution Configuration</heading>
|
||||
|
||||
<p>The resolver is the part of the networking system that turns IP
|
||||
addresses into hostnames and vice versa. It can be configured
|
||||
to look for maps that describe IP to hostname mappings in one
|
||||
of two places. The first is a file called <tt>/etc/hosts</tt>
|
||||
(<tt>man 5 hosts</tt>). The second is the Internet Domain Name
|
||||
Service (DNS), a distributed data base, the discussion of which
|
||||
is beyond the scope of this document.
|
||||
|
||||
<p>This section describes briefly how to configure your resolver. If
|
||||
you are already running a DNS, this section may be skipped.
|
||||
|
||||
<p>The resolver is a set of system calls that do the name mappings, but
|
||||
you have to tell them where to get their information from. You do
|
||||
this by first editing the file <tt>/etc/host.conf</tt>. Do
|
||||
<bf>not</bf> call this file <tt>/etc/hosts.conf</tt> (note the extra
|
||||
``s'') as the results can be confusing.
|
||||
|
||||
<sect2><heading>Edit the /etc/host.conf file</heading>
|
||||
|
||||
<p>This file should contain the following two lines:
|
||||
|
||||
<tscreen><verb>
|
||||
hosts
|
||||
bind
|
||||
</verb></tscreen>
|
||||
which instructs the resolver to first look in the file
|
||||
<tt>/etc/hosts</tt>, and then to consult the DNS if the
|
||||
name was not found.
|
||||
|
||||
<sect2><heading>Edit the /etc/hosts(5) file</heading>
|
||||
|
||||
<p>This file should contain the IP addresses and names of machines on your
|
||||
network. At a bare minimum it should contain entries for the machine
|
||||
which will be running ppp. Assuming that your machine is called
|
||||
foo.bar.com with the IP address 10.0.0.1, <tt>/etc/hosts</tt> should
|
||||
contain:
|
||||
|
||||
<tscreen><verb>
|
||||
127.0.0.1 localhost
|
||||
10.0.0.1 foo.bar.com foo
|
||||
</verb></tscreen>
|
||||
|
||||
The first line defines the alias ``localhost'' as a synonym for the
|
||||
current machine. Regardless of your own IP address, the IP address for
|
||||
this line should always be 127.0.0.1. The second line maps the name
|
||||
``foo.bar.com'' (and the shorthand ``foo'') to the IP address 10.0.0.1.
|
||||
|
||||
If your provider allocates you a static IP address then use this in place
|
||||
of 10.0.0.1.
|
||||
|
||||
<sect2><heading>Edit the /etc/resolv.conf file</heading>
|
||||
|
||||
<p><tt>/etc/resolv.conf</tt> contains some extra information required when
|
||||
you are not running a nameserver. It points the resolver routines at real
|
||||
nameservers, and specifies some other information.
|
||||
|
||||
At the very least, <tt>/etc/resolv.conf</tt> should contain one line with
|
||||
a nameserver which can be queried, but two nameservers are preferable.
|
||||
You should enter these as IP addresses, for example:
|
||||
|
||||
<tscreen><verb>
|
||||
nameserver 1.2.3.4
|
||||
nameserver 1.2.3.5
|
||||
</verb></tscreen>
|
||||
|
||||
Add as many ``nameserver'' lines as your ISP provides nameservers.
|
||||
Refer to the resolv.conf manual page for further details of entries
|
||||
in this file.
|
||||
|
||||
<sect1><heading>PPP Configuration</heading>
|
||||
|
||||
<p>Both user ppp and pppd (the kernel level implementation of PPP)
|
||||
use configuration files located in the <tt>/etc/ppp</tt> directory.
|
||||
The sample configuration files provided are a good reference for
|
||||
user ppp, so don't delete them.
|
||||
|
||||
<p>Configuring ppp requires that you edit up to three files, depending
|
||||
on your requirements. What you put in them depends to some extent
|
||||
on whether your ISP allocates IP addresses statically (i.e., you get
|
||||
given one IP address, and always use that one) or dynamically (i.e.,
|
||||
your IP address can be different during different PPP sessions).
|
||||
|
||||
<sect2><heading>PPP and static IP addresses</heading>
|
||||
|
||||
<p>You will need to create three files in the <tt>/etc/ppp</tt>
|
||||
directory.
|
||||
|
||||
<p>The first of these files is <tt>ppp.conf</tt>. It should look
|
||||
similar to the example below. Note that lines that end in a
|
||||
``:'' start in column 1, all other lines should be indented as
|
||||
shown using spaces or tabs.
|
||||
|
||||
<tt>/etc/ppp/ppp.conf</tt>
|
||||
<tscreen><verb>
|
||||
1 default:
|
||||
2 set device /dev/cuaa0
|
||||
3 set speed 38400
|
||||
4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK
|
||||
\\dATDT\\T TIMEOUT 40 CONNECT"
|
||||
5 provider:
|
||||
6 set phone 01234567890
|
||||
7 set login "TIMEOUT 10 gin:-BREAK-gin: foo word: bar col: ppp"
|
||||
8 set timeout 120
|
||||
9 set ifaddr x.x.x.x y.y.y.y
|
||||
10 delete ALL
|
||||
11 add 0 0 y.y.y.y
|
||||
12 set openmode active
|
||||
</verb></tscreen>
|
||||
Do not include the line numbers, they are just for reference in
|
||||
this discussion.
|
||||
|
||||
<descrip>
|
||||
<tag/Line 1:/ Identifies the default entry. Commands in this entry are
|
||||
executed automatically when ppp is run.
|
||||
|
||||
<tag/Line 2:/ Identifies the device to which the modem is connected.
|
||||
COM1: is <tt>/dev/cuaa0</tt> and COM2: is <tt>/dev/cuaa1</tt>.
|
||||
|
||||
<tag/Line 3:/ Sets the speed you want to connect at.
|
||||
|
||||
<tag/Line 4:/ The dial string. User ppp uses an expect-send syntax similar
|
||||
to the <tt>chat(8)</tt> program. Refer to the manual page
|
||||
for information on the features of this language.
|
||||
|
||||
<tag/Line 5:/ Identifies an entry for a provider called ``provider''.
|
||||
|
||||
<tag/Line 6:/ Sets the phone number for this provider. Multiple phone
|
||||
numbers may be specified using the `:' character as a
|
||||
seperator.
|
||||
|
||||
<tag/Line 7:/ The login string. The login string is of the same
|
||||
syntax as the dial string. In this example, the string is
|
||||
for a service who's login session looks like
|
||||
|
||||
<tscreen><verb>
|
||||
J. Random Provider
|
||||
login: foo
|
||||
password: bar
|
||||
protocol: ppp
|
||||
</verb></tscreen>
|
||||
|
||||
You will need to alter this script to suit your own needs.
|
||||
|
||||
<tag/Line 8:/ Sets the default timeout (in seconds) for the connection.
|
||||
Here, the connection will be closed automatically after
|
||||
120 seconds of inactivity.
|
||||
|
||||
<tag/Line 9:/ Sets the interface addresses. The string x.x.x.x should be
|
||||
replaced by the IP address that your provider allocates you.
|
||||
The string y.y.y.y should be replaced by the IP address that
|
||||
your ISP indicated for their gateway (the machine to which
|
||||
you connect).
|
||||
|
||||
<tag/Line 10:/ Deletes all existing routing table entries for the
|
||||
acquired tun device.
|
||||
|
||||
<tag/Line 11:/ Adds a default route to your ISPs IP number. The IP
|
||||
number should always be that of your ISPs gateway.
|
||||
|
||||
<tag/Line 12:/ Tells our side to begin negotiation. This is not always
|
||||
necessary, but it does no harm to have both sides initiating
|
||||
the Line Control Protocol (LCP).
|
||||
</descrip>
|
||||
|
||||
<p>The second of these files is <tt>/etc/ppp/ppp.linkup</tt>:
|
||||
|
||||
<tscreen><verb>
|
||||
x.x.x.x:
|
||||
delete ALL
|
||||
add 0 0 HISADDR
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Replace x.x.x.x with your IP address as before. This file is used to
|
||||
automatically delete all existing routes for the acquired line and
|
||||
add a default route from your ISP (who's address is automatically
|
||||
inserted with the HISADDR macro) to you.
|
||||
|
||||
<p>With a static IP number assigned by your ISP, you don't actually
|
||||
need an entry in <tt>/etc/ppp.linkup</tt>, but again, it doesn't
|
||||
do any harm to have it.
|
||||
|
||||
<p>Finally, the third of these files is <tt>/etc/ppp/ppp.secret</tt>.
|
||||
This file allows you to set some passwords to control access to
|
||||
your ppp server. You may or may not want to configure this file,
|
||||
depending on how many people have access to your ppp system.
|
||||
|
||||
<p>Examples can be found in the <tt>/etc/ppp</tt> directory.
|
||||
|
||||
<sect2><heading>PPP and Dynamic IP addresses</heading>
|
||||
|
||||
<p>If your service provider does not assign static IP numbers,
|
||||
<tt>ppp</tt> can be configured to negotiate the local and
|
||||
remote addresses. This is done by "guessing" an IP number
|
||||
and allowing ppp to set it up correctly using the LCP at
|
||||
connection time. Otherwise, the configuration is the same as
|
||||
that of a static IP configuration.
|
||||
|
||||
<p>Put the following lines in your <tt>ppp.conf</tt> file:
|
||||
|
||||
<tscreen><verb>
|
||||
ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0
|
||||
delete ALL
|
||||
add 0 0 10.0.0.2
|
||||
</verb></tscreen>
|
||||
|
||||
<p>You should NOT use 0 as either IP address. If you do, ppp will not be
|
||||
able to set up the correct initial entries in the routing table.
|
||||
|
||||
<p>The number after the ``/'' character is the number of bits of
|
||||
the address that ppp will insist on.
|
||||
|
||||
<p>Note also that the HISADDR macro is not yet available in
|
||||
<tt>ppp.conf</tt>, only in <tt>ppp.linkup</tt>.
|
||||
|
||||
<p>See the pmdemand entry in the files <tt>/etc/ppp/ppp.conf.sample</tt> and
|
||||
<tt>/etc/ppp/ppp.linkup.sample</tt> for a detailed example.
|
||||
|
||||
<sect2><heading>Receiving incoming calls with PPP</heading>
|
||||
|
||||
<p>This section describes setting up iijppp in a server role.
|
||||
|
||||
<p>When you configure <tt>ppp</tt> to receive incoming calls, you
|
||||
must decide whether you wish to forward packets for just
|
||||
<tt>ppp</tt> connections, for all interfaces, or not at all.
|
||||
To forward for just ppp connections, include the line
|
||||
|
||||
<tscreen><verb>
|
||||
enable proxy
|
||||
</verb></tscreen>
|
||||
|
||||
in your <tt>ppp.conf</tt> file. If you wish to forward packets on all
|
||||
interfaces, use the
|
||||
|
||||
<tscreen><verb>
|
||||
gateway=YES
|
||||
</verb></tscreen>
|
||||
|
||||
option in <tt>/etc/rc.conf</tt> (this file used to be called
|
||||
<tt>/etc/sysconfig</tt>).
|
||||
|
||||
<sect3><heading>Which getty?</heading>
|
||||
|
||||
<p><ref id="dialup" name="Configuring FreeBSD for Dialup Services">
|
||||
provides a good description on enabling dialup services using getty.
|
||||
|
||||
<p>An alternative to getty is
|
||||
<url url="http://www.leo.org/~doering/mgetty/index.html" name="mgetty">,
|
||||
a smarter version of getty designed with dialup lines in mind.
|
||||
|
||||
<p>The advantages of using mgetty is that it actively <em>talks</em> to
|
||||
modems, meaning if port is turned off in <tt>/etc/ttys</tt> then
|
||||
your modem won't answer the phone.
|
||||
|
||||
<p>Later versions of mgetty (from 0.99beta onwards) also support the
|
||||
automatic detection of PPP streams, allowing your clients script-less
|
||||
access to your server.
|
||||
|
||||
<p>Obtaining and configuring mgetty correctly is beyond the scope of
|
||||
this document.
|
||||
|
||||
<sect3><heading>Setting up a PPP shell for dynamic-IP users</heading>
|
||||
|
||||
<p>Create a file called <tt>/etc/ppp/ppp-shell</tt> containing the
|
||||
following:
|
||||
|
||||
<tscreen><verb>
|
||||
#!/bin/sh
|
||||
IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'`
|
||||
CALLEDAS="$IDENT"
|
||||
TTY=`tty`
|
||||
|
||||
if [ x$IDENT = xdialup ]; then
|
||||
IDENT=`basename $TTY`
|
||||
fi
|
||||
|
||||
echo "PPP for $CALLEDAS on $TTY"
|
||||
echo "Starting PPP for $IDENT"
|
||||
|
||||
exec /usr/sbin/ppp -direct $IDENT
|
||||
</verb></tscreen>
|
||||
|
||||
<p>This script should be executable. Now make a symbolic link called
|
||||
<tt>ppp-dialup</tt> to this script using the following commands:
|
||||
|
||||
<tscreen><verb>
|
||||
# ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-dialup
|
||||
</verb></tscreen>
|
||||
|
||||
<p>You should use this script as the <em>shell</em> for all your dialup
|
||||
ppp users. This is an example from <tt>/etc/password</tt>
|
||||
for a dialup PPP user with username pchilds. (remember don't directly
|
||||
edit the password file, use <tt>vipw</tt>)
|
||||
|
||||
<tscreen><verb>
|
||||
pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Create a <tt>/home/ppp</tt> directory that is world readable
|
||||
containing the following 0 byte files
|
||||
|
||||
<tscreen><verb>
|
||||
-r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin
|
||||
-r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts
|
||||
</verb></tscreen>
|
||||
|
||||
which prevents <tt>/etc/motd</tt> from being displayed.
|
||||
|
||||
<sect3><heading>Setting up a PPP shell for static-IP users</heading>
|
||||
|
||||
<p>Create the <tt>ppp-shell</tt> file as above and for each account with
|
||||
statically assigned IPs create a symbolic link to <tt>ppp-shell</tt>.
|
||||
|
||||
<p>For example, if you have three dialup customers fred, sam, and mary,
|
||||
that you route class C networks for, you would type the following:
|
||||
|
||||
<tscreen><verb>
|
||||
# ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred
|
||||
# ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam
|
||||
# ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Each of these users dialup accounts should have their shell set
|
||||
to the symbolic link created above. (ie. mary's shell should be
|
||||
<tt>/etc/ppp/ppp-mary</tt>).
|
||||
|
||||
<sect3><heading>Setting up ppp.conf for dynamic-IP users</heading>
|
||||
|
||||
<p>The <tt>/etc/ppp/ppp.conf</tt> file should contain something along
|
||||
the lines of
|
||||
|
||||
<tscreen><verb>
|
||||
default:
|
||||
set debug phase lcp chat
|
||||
set timeout 0
|
||||
|
||||
ttyd0:
|
||||
set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255
|
||||
enable proxy
|
||||
|
||||
ttyd1:
|
||||
set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255
|
||||
enable proxy
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Note the indenting is important.
|
||||
|
||||
<p>The <tt>default:</tt> section is loaded for each session. For each
|
||||
dialup line enabled in <tt>/etc/ttys</tt> create an entry similar
|
||||
to the one for <tt>ttyd0:</tt> above. Each line should get a unique
|
||||
IP from your pool of ip address for dynamic users.
|
||||
|
||||
<sect3><heading>Setting up ppp.conf for static-IP users</heading>
|
||||
|
||||
<p>Along with the contents of the sample <tt>/etc/ppp/ppp.conf</tt>
|
||||
above you should add a section for each of the statically assigned
|
||||
dialup users. We will continue with our fred, sam, and mary example.
|
||||
|
||||
<tscreen><verb>
|
||||
fred:
|
||||
set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255
|
||||
|
||||
sam:
|
||||
set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255
|
||||
|
||||
mary:
|
||||
set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255
|
||||
</verb></tscreen>
|
||||
|
||||
<p>The file <tt>/etc/ppp/ppp.linkup</tt> should also contain routing
|
||||
information for each static IP user if required. The line below
|
||||
would add a route for the <tt>203.14.101.0</tt> class C via
|
||||
the client's ppp link.
|
||||
|
||||
<tscreen><verb>
|
||||
fred:
|
||||
add 203.14.101.0 netmask 255.255.255.0 HISADDR
|
||||
|
||||
sam:
|
||||
add 203.14.102.0 netmask 255.255.255.0 HISADDR
|
||||
|
||||
mary:
|
||||
add 203.14.103.0 netmask 255.255.255.0 HISADDR
|
||||
</verb></tscreen>
|
||||
|
||||
<sect3><heading>More on mgetty, AutoPPP, and MS extensions</heading>
|
||||
|
||||
<sect4><heading>Mgetty and AutoPPP</heading>
|
||||
|
||||
<p>Configuring and compiling mgetty with the AUTO_PPP option enabled
|
||||
allows mgetty to detect the LCP phase of PPP connections and automatically
|
||||
spawn off a ppp shell. However, since the default login/password sequence
|
||||
does not occur it is necessary to authenticate users using either PAP
|
||||
or CHAP.
|
||||
|
||||
<p>This section assumes the user has successfully configured, compiled, and
|
||||
installed a version of mgetty with the AUTO_PPP option (v0.99beta or later)
|
||||
|
||||
<p>Make sure your <tt>/usr/local/etc/mgetty+sendfax/login.config</tt> file
|
||||
has the following in it:
|
||||
|
||||
<tscreen><verb>
|
||||
/AutoPPP/ - - /etc/ppp/ppp-pap-dialup
|
||||
</verb></tscreen>
|
||||
|
||||
<p>This will tell mgetty to run the <tt>ppp-pap-dialup</tt> script for
|
||||
detected PPP connections.
|
||||
|
||||
<p>Create a file called <tt>/etc/ppp/ppp-pap-dialup</tt> containing the
|
||||
following (the file should be executable):
|
||||
|
||||
<tscreen><verb>
|
||||
#!/bin/sh
|
||||
TTY=`tty`
|
||||
IDENT=`basename $TTY`
|
||||
exec /usr/sbin/ppp -direct pap$IDENT
|
||||
</verb></tscreen>
|
||||
|
||||
<p>For each dialup line enabled in <tt>/etc/ttys</tt> create a corresponding
|
||||
entry in <tt>/etc/ppp/ppp.conf</tt>. This will happily co-exist with
|
||||
the definitions we created above.
|
||||
|
||||
<tscreen><verb>
|
||||
papttyd0:
|
||||
enable pap
|
||||
set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255
|
||||
enable proxy
|
||||
|
||||
papttyd1:
|
||||
enable pap
|
||||
set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255
|
||||
enable proxy
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Each user logging in with this method will need to have a username/password
|
||||
in <tt>/etc/ppp/ppp.secret</tt> file, or alternatively add the
|
||||
|
||||
<tscreen><verb>
|
||||
enable passwdauth
|
||||
</verb></tscreen>
|
||||
|
||||
option to authenticate users via pap from the <tt>/etc/password</tt>d
|
||||
file. (*)
|
||||
|
||||
<p>(*) Note this option only available in 2.2-961014-SNAP or later, or by
|
||||
getting the updated ppp code for 2.1.x. (see MS extensions below for details)
|
||||
|
||||
<sect4><heading>MS extentions</heading>
|
||||
|
||||
<p>From 2.2-961014-SNAP onwards it is possible to allow the automatic
|
||||
negotiation of DNS and NetBIOS name servers with clients supporting
|
||||
this feature (namely Win95/NT clients). See RFC1877 for more details
|
||||
on the protocol.
|
||||
|
||||
<p>An example of enabling these extensions in your
|
||||
<tt>/etc/ppp/ppp.conf</tt> file is illustrated below.
|
||||
|
||||
<tscreen><verb>
|
||||
default:
|
||||
set debug phase lcp chat
|
||||
set timeout 0
|
||||
enable msext
|
||||
set ns 203.14.100.1 203.14.100.2
|
||||
set nbns 203.14.100.5
|
||||
</verb></tscreen>
|
||||
|
||||
<p>This will tell the clients the primary and secondary
|
||||
name server addresses, and a netbios nameserver host.
|
||||
|
||||
<sect1><heading>Final system configuration</heading>
|
||||
|
||||
<p>You now have PPP configured, but there are a few more things to
|
||||
do before it is ready to work. They all involve editing the
|
||||
<tt>/etc/rc.conf</tt> file (was <tt>/etc/sysconfig</tt>).
|
||||
|
||||
Working from the top down in this file, make sure the ``hostname='' line
|
||||
is set, e.g.:
|
||||
|
||||
<tscreen><verb>
|
||||
hostname=foo.bar.com
|
||||
</verb></tscreen>
|
||||
|
||||
<p>Look for the network_interfaces variable. If you want to configure
|
||||
your system to dial your ISP on demand, make sure the tun0 device is
|
||||
added to the list, otherwise remove it.
|
||||
|
||||
<tscreen><verb>
|
||||
network_interfaces="lo0 tun0"
|
||||
ifconfig_tun0=
|
||||
</verb></tscreen>
|
||||
|
||||
Note, the <tt>ifconfig_tun0</tt> variable should be empty, and
|
||||
a file called /etc/start_if.tun0 should be created. This file
|
||||
should contain the line
|
||||
|
||||
<tscreen><verb>
|
||||
ppp -auto mysystem
|
||||
</verb></tscreen>
|
||||
|
||||
This script is executed at network configuration time, starting
|
||||
your ppp daemon in automatic mode.
|
||||
|
||||
<p>Set the router program to ``NO'' with the line
|
||||
|
||||
<tscreen><verb>
|
||||
router_enable=NO (/etc/rc.conf)
|
||||
router=NO (/etc/sysconfig)
|
||||
</verb></tscreen>
|
||||
|
||||
It is important that the <tt>routed</tt> daemon is not started
|
||||
(the default) as <tt>routed</tt> tends to delete the default
|
||||
routing table entries created by ppp.
|
||||
|
||||
<p>It is probably worth your while ensuring that the ``sendmail_flags'' line
|
||||
does not include the ``-q'' option, otherwise sendmail will attempt to do
|
||||
a network lookup every now and then, possibly causing your machine to dial
|
||||
out. You may try:
|
||||
|
||||
<tscreen><verb>
|
||||
sendmail_flags="-bd"
|
||||
</verb></tscreen>
|
||||
|
||||
The upshot of this is that you must force sendmail to re-examine the
|
||||
mail queue whenever the ppp link is up by typing:
|
||||
|
||||
<tscreen><verb>
|
||||
# /usr/sbin/sendmail -q
|
||||
</verb></tscreen>
|
||||
|
||||
If you don't like this, it is possible to set up a "dfilter" to block
|
||||
SMTP traffic. Refer to the sample files for further details. You
|
||||
can also use a script in the <tt>ppp.linkup</tt> file to execute this
|
||||
command.
|
||||
|
||||
All that is left is to reboot the machine.
|
||||
|
||||
You can now either type
|
||||
<tscreen><verb>
|
||||
# ppp
|
||||
</verb></tscreen>
|
||||
|
||||
and then ``dial provider'' to start the PPP session, or, if you
|
||||
want ppp to establish sessions automatically when there is outbound
|
||||
traffic (and you havn't created the start_if.tun0 script) , type
|
||||
|
||||
<tscreen><verb>
|
||||
# ppp -auto provider
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading>Summary</heading>
|
||||
|
||||
<p>To recap, the following steps are necessary when setting up ppp
|
||||
for the first time:
|
||||
|
||||
<p>Client side:
|
||||
|
||||
<itemize>
|
||||
<item>Ensure that the tun device is built into your kernel.
|
||||
<item>Ensure that the tunX device file is available in the
|
||||
<tt>/dev</tt> directory.
|
||||
<item>Create an entry in <tt>/etc/ppp.conf</tt>. The
|
||||
<tt>pmdemand</tt> example should suffice for most
|
||||
ISPs.
|
||||
<item>Create an entry in <tt>/etc/ppp.linkup</tt>.
|
||||
<item>Update your rc.conf (or sysconfig) file.
|
||||
<item>Create a start_if.tun0 script if you require demand
|
||||
dialing.
|
||||
</itemize>
|
||||
|
||||
<p>Server side:
|
||||
<itemize>
|
||||
<item>Ensure that the tun device is built into your kernel.
|
||||
<item>Ensure that the tunX device file is available in the
|
||||
<tt>/dev</tt> directory.
|
||||
<item>Create an entry in /etc/passwd (using the vipw(8)
|
||||
program).
|
||||
<item>Create a profile in this users home directory that
|
||||
runs ``ppp -direct direct-server'' or similar.
|
||||
<item>Create an entry in <tt>/etc/ppp.conf</tt>. The
|
||||
<tt>direct-server</tt> example should suffice.
|
||||
<item>Create an entry in <tt>/etc/ppp.linkup</tt>.
|
||||
<item>Update your rc.conf (or sysconfig) file.
|
||||
</itemize>
|
||||
|
||||
<sect1><heading>Acknowledgments</heading>
|
||||
|
||||
<p>Thanks to the following for their comments & suggestions:
|
||||
|
||||
<p>&a.nik
|
||||
<p>&a.dirkvangulik
|
||||
<p>&a.pjc
|
||||
@ -1,6 +0,0 @@
|
||||
# From: @(#)Makefile 8.1 (Berkeley) 6/5/93
|
||||
# $Id$
|
||||
|
||||
SUBDIR= handbook
|
||||
|
||||
.include <bsd.subdir.mk>
|
||||
@ -1,26 +0,0 @@
|
||||
# $Id: Makefile,v 1.9 1997/05/09 23:09:56 max Exp $
|
||||
# Original revision: 1.22
|
||||
# The FreeBSD Japanese Documentation Project
|
||||
|
||||
DOC= handbook
|
||||
DOCDIR=${SHAREDIR}/doc/ja_JP.EUC
|
||||
FORMATS= html roff
|
||||
SGMLOPTS+=-e EUC-JP
|
||||
|
||||
SRCS= authors.sgml basics.sgml bibliography.sgml boothelp.sgml
|
||||
SRCS+= booting.sgml contrib.sgml crypt.sgml ctm.sgml current.sgml cvsup.sgml
|
||||
SRCS+= cyclades.sgml development.sgml dialup.sgml dialout.sgml
|
||||
SRCS+= diskless.sgml dma.sgml eresources.sgml esdi.sgml
|
||||
SRCS+= firewalls.sgml glossary.sgml goals.sgml
|
||||
SRCS+= handbook.sgml history.sgml hw.sgml install.sgml isdn.sgml
|
||||
SRCS+= kerberos.sgml kernelconfig.sgml kerneldebug.sgml kernelopts.sgml
|
||||
SRCS+= lists.sgml mail.sgml memoryuse.sgml
|
||||
SRCS+= mirrors.sgml nfs.sgml nutshell.sgml pgpkeys.sgml policies.sgml
|
||||
SRCS+= porting.sgml ports.sgml ppp.sgml printing.sgml
|
||||
SRCS+= quotas.sgml relnotes.sgml routing.sgml russian.sgml
|
||||
SRCS+= serial.sgml scsi.sgml sections.sgml sio.sgml skey.sgml slipc.sgml
|
||||
SRCS+= slips.sgml stable.sgml submitters.sgml sup.sgml synching.sgml
|
||||
SRCS+= term.sgml userppp.sgml uart.sgml linuxemu.sgml
|
||||
SRCS+= jcontrib.sgml jmembers.sgml
|
||||
|
||||
.include <bsd.sgml.mk>
|
||||
@ -1,490 +0,0 @@
|
||||
<!-- $Id: authors.sgml,v 1.22 1997/05/13 22:57:43 max Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.69 -->
|
||||
|
||||
<!--
|
||||
Names and email address of contributing authors and CVS committers.
|
||||
Use these entities when referencing people. Please note the use of single
|
||||
and double quotes.
|
||||
Please keep this list in alphabetical order by entity names.
|
||||
-->
|
||||
|
||||
<!ENTITY a.ache "Andrey A. Chernov
|
||||
<tt><htmlurl url='mailto:ache@FreeBSD.ORG'
|
||||
name='<ache@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.adam "Adam David
|
||||
<tt><htmlurl url='mailto:adam@FreeBSD.ORG'
|
||||
name='<adam@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.alex "Alex Nash
|
||||
<tt><htmlurl url='mailto:alex@freebsd.org'
|
||||
name='<alex@freebsd.org>'></tt>">
|
||||
|
||||
<!ENTITY a.amurai "Atsushi Murai
|
||||
<tt><htmlurl url='mailto:amurai@FreeBSD.ORG'
|
||||
name='<amurai@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.andreas "Andreas Klemm
|
||||
<tt><htmlurl url='mailto:andreas@FreeBSD.ORG'
|
||||
name='<andreas@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.asami "浅見 賢
|
||||
<tt><htmlurl url='mailto:asami@FreeBSD.ORG'
|
||||
name='<asami@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ats "Andreas Schulz
|
||||
<tt><htmlurl url='mailto:ats@FreeBSD.ORG'
|
||||
name='<ats@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.awebster "Andrew Webster
|
||||
<tt><htmlurl url='mailto:awebster@pubnix.net'
|
||||
name='<awebster@pubnix.net>'></tt>">
|
||||
|
||||
<!ENTITY a.bde "Bruce Evans
|
||||
<tt><htmlurl url='mailto:bde@FreeBSD.ORG'
|
||||
name='<bde@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.brian "Brian Somers
|
||||
<tt><htmlurl url='mailto:brian@awfulhak.org'
|
||||
name='<brian@awfulhak.org>'></tt>">
|
||||
|
||||
<!ENTITY a.cawimm "Charles A. Wimmer
|
||||
<tt><htmlurl url='mailto:cawimm@FreeBSD.ORG'
|
||||
name='<cawimm@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.charnier "Philippe Charnier
|
||||
<tt><htmlurl url='mailto:charnier@FreeBSD.ORG'
|
||||
name='<charnier@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.chuck "Chuck Robey
|
||||
<tt><htmlurl url='mailto:chuckr@glue.umd.edu'
|
||||
name='<chuckr@glue.umd.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.chuckr "Chuck Robey
|
||||
<tt><htmlurl url='mailto:chuckr@FreeBSD.ORG'
|
||||
name='<chuckr@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.cracauer "Martin Cracauer
|
||||
<tt><htmlurl url='mailto:cracauer@FreeBSD.ORG'
|
||||
name='<cracauer@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.csgr "Geoff Rehmet
|
||||
<tt><htmlurl url='mailto:csgr@FreeBSD.ORG'
|
||||
name='<csgr@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.danny "Daniel O'Callaghan
|
||||
<tt><htmlurl url='mailto:danny@FreeBSD.ORG'
|
||||
name='<danny@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.darrenr "Darren Reed
|
||||
<tt><htmlurl url='mailto:darrenr@FreeBSD.ORG'
|
||||
name='<darrenr@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.dave "Dave Cornejo
|
||||
<tt><htmlurl url='mailto:dave@FreeBSD.ORG'
|
||||
name='<dave@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.davidg "David Greenman
|
||||
<tt><htmlurl url='mailto:davidg@FreeBSD.ORG'
|
||||
name='<davidg@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.davidn "David Nugent
|
||||
<tt><htmlurl url='mailto:davidn@blaze.net.au'
|
||||
name='<davidn@blaze.net.au>'></tt>">
|
||||
|
||||
<!ENTITY a.dfr "Doug Rabson
|
||||
<tt><htmlurl url='mailto:dfr@FreeBSD.ORG'
|
||||
name='<dfr@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.dima "Dima Ruban
|
||||
<tt><htmlurl url='mailto:dima@FreeBSD.ORG'
|
||||
name='<dima@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.dirkvangulik "Dirk-Willem van Gulik
|
||||
<tt><htmlurl url='mailto:Dirk.vanGulik@jrc.it'
|
||||
name='<Dirk.vanGulik@jrc.it>'></tt>">
|
||||
|
||||
<!ENTITY a.dufault "Peter Dufault
|
||||
<tt><htmlurl url='mailto:dufault@FreeBSD.ORG'
|
||||
name='<dufault@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.dyson "John Dyson
|
||||
<tt><htmlurl url='mailto:dyson@FreeBSD.ORG'
|
||||
name='<dyson@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.eivind "Eivind Eklund
|
||||
<tt><htmlurl url='mailto:perhaps@yes.no'
|
||||
name='<perhaps@yes.no>'></tt>">
|
||||
|
||||
<!ENTITY a.erich "Eric L. Hernes
|
||||
<tt><htmlurl url='mailto:erich@FreeBSD.ORG'
|
||||
name='<erich@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.fenner "Bill Fenner
|
||||
<tt><htmlurl url='mailto:fenner@FreeBSD.ORG'
|
||||
name='<fenner@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.fsmp "Steve Passe
|
||||
<tt><htmlurl url='mailto:fsmp@FreeBSD.ORG'
|
||||
name='<fsmp@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gclarkii "Gary Clark II
|
||||
<tt><htmlurl url='mailto:gclarkii@FreeBSD.ORG'
|
||||
name='<gclarkii@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gena "Gennady B. Sorokopud
|
||||
<tt><htmlurl url='mailto:gena@NetVision.net.il'
|
||||
name='<gena@NetVision.net.il>'></tt>">
|
||||
|
||||
<!ENTITY a.ghelmer "Guy Helmer
|
||||
<tt><htmlurl url='mailto:ghelmer@alpha.dsu.edu'
|
||||
name='<ghelmer@alpha.dsu.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.gibbs "Justin T. Gibbs
|
||||
<tt><htmlurl url='mailto:gibbs@FreeBSD.ORG'
|
||||
name='<gibbs@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gj "Gary Jennejohn
|
||||
<tt><htmlurl url='mailto:gj@FreeBSD.ORG'
|
||||
name='<gj@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gpalmer "Gary Palmer
|
||||
<tt><htmlurl url='mailto:gpalmer@FreeBSD.ORG'
|
||||
name='<gpalmer@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.graichen "Thomas Graichen
|
||||
<tt><htmlurl url='mailto:graichen@FreeBSD.ORG'
|
||||
name='<graichen@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.gryphon "Coranth Gryphon
|
||||
<tt><htmlurl url='mailto:gryphon@healer.com'
|
||||
name='<gryphon@healer.com>'></tt>">
|
||||
|
||||
<!ENTITY a.guido "Guido van Rooij
|
||||
<tt><htmlurl url='mailto:guido@FreeBSD.ORG'
|
||||
name='<guido@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.hanai "花井浩之
|
||||
<tt><htmlurl url='mailto:hanai@FreeBSD.ORG'
|
||||
name='<hanai@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.handy "Brian N. Handy
|
||||
<tt><htmlurl url='mailto:handy@sxt4.physics.montana.edu'
|
||||
name='<handy@sxt4.physics.montana.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.hm "Hellmuth Michaelis
|
||||
<tt><htmlurl url='mailto:hm@kts.org'
|
||||
name='<hm@kts.org>'></tt>">
|
||||
|
||||
<!ENTITY a.hsu "Jeffrey Hsu
|
||||
<tt><htmlurl url='mailto:hsu@FreeBSD.ORG'
|
||||
name='<hsu@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.imp "Warner Losh
|
||||
<tt><htmlurl url='mailto:imp@FreeBSD.ORG'
|
||||
name='<imp@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jb "John Birrell
|
||||
<tt><htmlurl url='mailto:jb@cimlogic.com.au'
|
||||
name='<jb@cimlogic.com.au>'></tt>">
|
||||
|
||||
<!ENTITY a.jdp "John Polstra
|
||||
<tt><htmlurl url='mailto:jdp@FreeBSD.ORG'
|
||||
name='<jdp@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jehamby "Jake Hamby
|
||||
<tt><htmlurl url='mailto:jehamby@lightside.com'
|
||||
name='<jehamby@lightside.com>'></tt>">
|
||||
|
||||
<!ENTITY a.jfieber "John Fieber
|
||||
<tt><htmlurl url='mailto:jfieber@FreeBSD.ORG'
|
||||
name='<jfieber@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jfitz "James FitzGibbon
|
||||
<tt><htmlurl url='mailto:james@nexis.net'
|
||||
name='<james@nexis.net>'></tt>">
|
||||
|
||||
<!ENTITY a.jgreco "Joe Greco
|
||||
<tt><htmlurl url='mailto:jgreco@FreeBSD.ORG'
|
||||
name='<jgreco@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jhay "John Hay
|
||||
<tt><htmlurl url='mailto:jhay@FreeBSD.ORG'
|
||||
name='<jhay@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jkh "Jordan K. Hubbard
|
||||
<tt><htmlurl url='mailto:jkh@FreeBSD.ORG'
|
||||
name='<jkh@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jlind "John Lind
|
||||
<tt><htmlurl url='mailto:john@starfire.MN.ORG'
|
||||
name='<john@starfire.MN.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jlrobin "James L. Robinson
|
||||
<tt><htmlurl url='mailto:jlrobin@FreeBSD.ORG'
|
||||
name='<jlrobin@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jmacd "Joshua Peck Macdonald
|
||||
<tt><htmlurl url='mailto:jmacd@FreeBSD.ORG'
|
||||
name='<jmacd@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jmb "Jonathan M. Bresler
|
||||
<tt><htmlurl url='mailto:jmb@FreeBSD.ORG'
|
||||
name='<jmb@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jmg "John-Mark Gurney
|
||||
<tt><htmlurl url='mailto:jmg@FreeBSD.ORG'
|
||||
name='<jmg@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jmz "Jean-Marc Zucconi
|
||||
<tt><htmlurl url='mailto:jmz@FreeBSD.ORG'
|
||||
name='<jmz@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.joerg "Jörg Wunsch
|
||||
<tt><htmlurl url='mailto:joerg@FreeBSD.ORG'
|
||||
name='<joerg@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.john "John Cavanaugh
|
||||
<tt><htmlurl url='mailto:john@FreeBSD.ORG'
|
||||
name='<john@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jraynard "James Raynard
|
||||
<tt><htmlurl url='mailto:jraynard@freebsd.org'
|
||||
name='<jraynard@freebsd.org>'></tt>">
|
||||
|
||||
<!ENTITY a.julian "Julian Elischer
|
||||
<tt><htmlurl url='mailto:julian@FreeBSD.ORG'
|
||||
name='<julian@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.jvh "Johannes Helander
|
||||
<tt><htmlurl url='mailto:jvh@FreeBSD.ORG'
|
||||
name='<jvh@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.karl "Karl Strickland
|
||||
<tt><htmlurl url='mailto:karl@FreeBSD.ORG'
|
||||
name='<karl@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.kato "Takenori KATO
|
||||
<tt><htmlurl url='mailto:kato@FreeBSD.ORG'
|
||||
name='<kato@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.kelly "Sean Kelly
|
||||
<tt><htmlurl url='mailto:kelly@fsl.noaa.gov'
|
||||
name='<kelly@fsl.noaa.gov>'></tt>">
|
||||
|
||||
<!ENTITY a.kjc "Kenjiro Cho
|
||||
<tt><htmlurl url='mailto:kjc@FreeBSD.ORG'
|
||||
name='<kjc@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.lars "Lars Fredriksen
|
||||
<tt><htmlurl url='mailto:lars@FreeBSD.ORG'
|
||||
name='<lars@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ljo "L Jonas Olsson
|
||||
<tt><htmlurl url='mailto:ljo@FreeBSD.ORG'
|
||||
name='<ljo@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.markm "Mark Murray
|
||||
<tt><htmlurl url='mailto:markm@FreeBSD.ORG'
|
||||
name='<markm@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.martin "Martin Renters
|
||||
<tt><htmlurl url='mailto:martin@FreeBSD.ORG'
|
||||
name='<martin@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.max "中根 雅文
|
||||
<tt><htmlurl url='mailto:max@FreeBSD.ORG'
|
||||
name='<max@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.mayo "Mark Mayo
|
||||
<tt><htmlurl url='mailto:mayo@quickweb.com'
|
||||
name='<mayo@quickweb.com>'></tt>">
|
||||
|
||||
<!ENTITY a.mbarkah "Ade Barkah
|
||||
<tt><htmlurl url='mailto:mbarkah@FreeBSD.ORG'
|
||||
name='<mbarkah@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.mckay "Stephen McKay
|
||||
<tt><htmlurl url='mailto:mckay@FreeBSD.ORG'
|
||||
name='<mckay@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.md "Mark Dapoz
|
||||
<tt><htmlurl url='mailto:md@bsc.no'
|
||||
name='<md@bsc.no>'></tt>">
|
||||
|
||||
<!ENTITY a.mpp "Mike Pritchard
|
||||
<tt><htmlurl url='mailto:mpp@FreeBSD.ORG'
|
||||
name='<mpp@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.msmith "Michael Smith
|
||||
<tt><htmlurl url='mailto:msmith@FreeBSD.ORG'
|
||||
name='<msmith@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.nate "Nate Williams
|
||||
<tt><htmlurl url='mailto:nate@FreeBSD.ORG'
|
||||
name='<nate@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.nik "Nik Clayton
|
||||
<tt><htmlurl url='mailto:nik@blueberry.co.uk'
|
||||
name='<nik@blueberry.co.uk>'></tt>">
|
||||
|
||||
<!ENTITY a.nsj "Nate Johnson
|
||||
<tt><htmlurl url='mailto:nsj@FreeBSD.ORG'
|
||||
name='<nsj@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.obrien "David O'Brien
|
||||
<tt><htmlurl url='mailto:obrien@cs.ucdavis.edu'
|
||||
name='<obrien@cs.ucdavis.edu>'></tt>">
|
||||
|
||||
<!ENTITY a.olah "Andras Olah
|
||||
<tt><htmlurl url='mailto:olah@FreeBSD.ORG'
|
||||
name='<olah@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.opsys "Chris Watson
|
||||
<tt><htmlurl url='mailto:opsys@open-systems.net'
|
||||
name='<opsys@open-systems.net>'></tt>">
|
||||
|
||||
<!ENTITY a.paul "Paul Richards
|
||||
<tt><htmlurl url='mailto:paul@FreeBSD.ORG'
|
||||
name='<paul@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.pds "Peter da Silva
|
||||
<tt><htmlurl url='mailto:pds@FreeBSD.ORG'
|
||||
name='<pds@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.peter "Peter Wemm
|
||||
<tt><htmlurl url='mailto:peter@FreeBSD.ORG'
|
||||
name='<peter@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.phk "Poul-Henning Kamp
|
||||
<tt><htmlurl url='mailto:phk@FreeBSD.ORG'
|
||||
name='<phk@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.pjc "Peter Childs
|
||||
<tt><htmlurl url='mailto:pjchilds@imforei.apana.org.au'
|
||||
name='<pjchilds@imforei.apana.org.au>'></tt>">
|
||||
|
||||
<!ENTITY a.proven "Chris Provenzano
|
||||
<tt><htmlurl url='mailto:proven@FreeBSD.ORG'
|
||||
name='<proven@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.pst "Paul Traina
|
||||
<tt><htmlurl url='mailto:pst@FreeBSD.ORG'
|
||||
name='<pst@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.rgrimes "Rodney Grimes
|
||||
<tt><htmlurl url='mailto:rgrimes@FreeBSD.ORG'
|
||||
name='<rgrimes@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.rhuff "Robert Huff
|
||||
<tt><htmlurl url='mailto:rhuff@cybercom.net'
|
||||
name='<rhuff@cybercom.net>'></tt>">
|
||||
|
||||
<!ENTITY a.ricardag "Ricardo AG
|
||||
<tt><htmlurl url='mailto:ricardag@ag.com.br'
|
||||
name='<ricardag@ag.com.br>'></tt>">
|
||||
|
||||
<!ENTITY a.rich "Rich Murphey
|
||||
<tt><htmlurl url='mailto:rich@FreeBSD.ORG'
|
||||
name='<rich@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.roberto "Ollivier Robert
|
||||
<tt><htmlurl url='mailto:roberto@FreeBSD.ORG'
|
||||
name='<roberto@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.scrappy "Marc G. Fournier
|
||||
<tt><htmlurl url='mailto:scrappy@FreeBSD.ORG'
|
||||
name='<scrappy@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.se "Stefan Esser
|
||||
<tt><htmlurl url='mailto:se@FreeBSD.ORG'
|
||||
name='<se@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.sef "Sean Eric Fagan
|
||||
<tt><htmlurl url='mailto:sef@FreeBSD.ORG'
|
||||
name='<sef@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.smace "Scott Mace
|
||||
<tt><htmlurl url='mailto:smace@FreeBSD.ORG'
|
||||
name='<smace@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.smpatel "Sujal Patel
|
||||
<tt><htmlurl url='mailto:smpatel@FreeBSD.ORG'
|
||||
name='<smpatel@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.sos "Søren Schmidt
|
||||
<tt><htmlurl url='mailto:sos@FreeBSD.ORG'
|
||||
name='<sos@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.stark "Gene Stark
|
||||
<tt><htmlurl url='mailto:stark@FreeBSD.ORG'
|
||||
name='<stark@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.stb "Stefan Bethke
|
||||
<tt><htmlurl url='mailto:stb@FreeBSD.ORG'
|
||||
name='<stb@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.steve "Steve Price
|
||||
<tt><htmlurl url='mailto:steve@FreeBSD.ORG'
|
||||
name='<steve@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.swallace "Steven Wallace
|
||||
<tt><htmlurl url='mailto:swallace@FreeBSD.ORG'
|
||||
name='<swallace@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.tedm "Ted Mittelstaedt
|
||||
<tt><htmlurl url='mailto:tedm@FreeBSD.ORG'
|
||||
name='<tedm@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.tegge "Tor Egge
|
||||
<tt><htmlurl url='mailto:tegge@FreeBSD.ORG'
|
||||
name='<tegge@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.tg "Thomas Gellekum
|
||||
<tt><htmlurl url='mailto:tg@FreeBSD.ORG'
|
||||
name='<tg@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.torstenb "Torsten Blum
|
||||
<tt><htmlurl url='mailto:torstenb@FreeBSD.ORG'
|
||||
name='<torstenb@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ugen "Ugen J.S.Antsilevich
|
||||
<tt><htmlurl url='mailto:ugen@FreeBSD.ORG'
|
||||
name='<ugen@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.uhclem "Frank Durda IV
|
||||
<tt><htmlurl url='mailto:uhclem@FreeBSD.ORG'
|
||||
name='<uhclem@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.ulf "Ulf Zimmermann
|
||||
<tt><htmlurl url='mailto:ulf@FreeBSD.ORG'
|
||||
name='<ulf@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.whiteside "Don Whiteside
|
||||
<tt><htmlurl url='mailto:whiteside@acm.org'
|
||||
name='<whiteside@acm.org>'></tt>">
|
||||
|
||||
<!ENTITY a.wilko "Wilko Bulte
|
||||
<tt><htmlurl url='mailto:wilko@yedi.iaf.nl'
|
||||
name='<wilko@yedi.iaf.nl>'></tt>">
|
||||
|
||||
<!ENTITY a.wlloyd "Bill Lloyd
|
||||
<tt><htmlurl url='mailto:wlloyd@mpd.ca'
|
||||
name='<wlloyd@mpd.ca>'></tt>">
|
||||
|
||||
<!ENTITY a.wollman "Garrett Wollman
|
||||
<tt><htmlurl url='mailto:wollman@FreeBSD.ORG'
|
||||
name='<wollman@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.wosch "Wolfram Schneider
|
||||
<tt><htmlurl url='mailto:wosch@FreeBSD.ORG'
|
||||
name='<wosch@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.wpaul "Bill Paul
|
||||
<tt><htmlurl url='mailto:wpaul@FreeBSD.ORG'
|
||||
name='<wpaul@FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!ENTITY a.yokota "Kazutaka YOKOTA
|
||||
<tt><htmlurl url='mailto:yokota@FreeBSD.ORG'
|
||||
name='<yokota@FreeBSD.ORG>'></tt>">
|
||||
@ -1,93 +0,0 @@
|
||||
<!-- $Id: basics.sgml,v 1.4 1997/02/22 13:00:36 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.9 -->
|
||||
|
||||
<chapt><heading>Unix の基礎知識<label id="basics"></heading>
|
||||
|
||||
<p><em>訳: &a.nakai;<newline>12 October 1996.</em>
|
||||
|
||||
<sect>
|
||||
<heading>オンラインマニュアル<label id="basics:man"></heading>
|
||||
|
||||
<p>FreeBSD についてのもっとも包括的なドキュメントは
|
||||
<em>マニュアルページ</em>の形式になっているものです.
|
||||
FreeBSD システム上のほとんどすべてのプログラムには基本的な
|
||||
操作方法とさまざまな引数を説明しているリファレンスマニュアル
|
||||
がついています。これらのマニュアルは
|
||||
<tt><bf>man</bf></tt> コマンドで見ることができます。
|
||||
<tt><bf>man</bf></tt> コマンドの使い方は簡単です :
|
||||
<tscreen>
|
||||
<bf>man</bf> <it>コマンド名</it>
|
||||
</tscreen>
|
||||
<it>コマンド名</it>のところには知りたいコマンドの名前を入れます。
|
||||
たとえば、<tt><bf>ls</bf></tt> コマンドについて知りたい場合には
|
||||
次のように入力します :
|
||||
<tscreen>
|
||||
% <bf>man ls</bf>
|
||||
</tscreen>
|
||||
|
||||
<p>オンラインマニュアルは数字のついたセクションに分けられています :
|
||||
<enum>
|
||||
<item>ユーザコマンド</item>
|
||||
<item>システムコールとエラー番号</item>
|
||||
<item>C のライブラリ関数</item>
|
||||
<item>デバイスドライバ</item>
|
||||
<item>ファイル形式</item>
|
||||
<item>ゲームとほかのお楽しみ</item>
|
||||
<item>そのほかの情報</item>
|
||||
<item>システムの管理と操作のためのコマンド</item>
|
||||
</enum>
|
||||
場合によっては, 同じことがらでもオンラインマニュアルでは
|
||||
複数のセクションに記載されていることがあります。たとえば、
|
||||
<tt><bf>chmod</bf></tt> ユーザコマンドと <tt><bf>chmod()</bf></tt>
|
||||
システムコールがあります。この場合、<tt><bf>man</bf></tt>
|
||||
コマンドでどちらを参照したいかをセクションで指定することが
|
||||
できます :
|
||||
<tscreen>
|
||||
% <bf>man 1 chmod</bf>
|
||||
</tscreen>
|
||||
とすればユーザコマンドとしての <tt><bf>chmod</bf></tt>
|
||||
のマニュアルページが表示されます。オンラインマニュアル上の特定の
|
||||
セクションへの参照は通常、書かれているドキュメントの
|
||||
括弧の中に示されています。ですから、<tt><bf>chmod(1)</bf></tt> は
|
||||
<tt><bf>chmod</bf></tt> ユーザコマンドを、
|
||||
<tt><bf>chmod(2)</bf></tt> はシステムコールの方を示しています。
|
||||
|
||||
<p>コマンドの名前を知っていて, 単純にその使い方が分かる場合は
|
||||
よいのですが、もしコマンドの名前を思い出せない場合には
|
||||
どうしたらいいのでしょう? <tt><bf>man</bf></tt> に
|
||||
<tt><bf>-k</bf></tt> スイッチをつければ,
|
||||
コマンドデスクリプション中のキーワードから検索することができます :
|
||||
<tscreen>
|
||||
% <bf>man -k mail</bf>
|
||||
</tscreen>
|
||||
このコマンドを使うことで, 「mail」というキーワードを含むコマンドの
|
||||
一覧を参照することができます。実を言うと <tt><bf>apropos</bf></tt>
|
||||
コマンドを使うのと機能的には同じです。
|
||||
|
||||
<p>それから、<tt>/usr/bin</tt> にある優れたコマンドすべてを目にしても、
|
||||
それらの大半がどういった働きをするのかまったく見当もつかないときは
|
||||
どうしたらよいでしょう。単純に、
|
||||
<tscreen>
|
||||
% <bf>cd /usr/bin; man -f *</bf>
|
||||
</tscreen>
|
||||
あるいは同じ働きをする
|
||||
<tscreen>
|
||||
% <bf>cd /usr/bin; whatis *</bf>
|
||||
</tscreen>
|
||||
としましょう。
|
||||
|
||||
<sect>
|
||||
<heading>GNU の Info ファイル<label id="basics:info"></heading>
|
||||
|
||||
<p>FreeBSD には Free Software Foundation (FSF) によるアプリケーションや
|
||||
ユーティリティがたくさんあります。こうしたプログラムには
|
||||
manページに加えて、<em>info</em> ファイルと呼ばれる
|
||||
ハイパーテキスト形式のドキュメントが付属になっていて、<tt>info</tt>
|
||||
コマンドや、<tt>emacs</tt> をインストールしているなら
|
||||
<tt>emacs</tt> の info モードで見ることができます。
|
||||
|
||||
<tt>info(1)</tt> コマンドを使うには, 単にこう入力します。
|
||||
<tscreen>% <bf>info</bf></tscreen> おおまかなイントロダクションを
|
||||
見るには、<tt><bf>h</bf></tt> と入力します。
|
||||
クイックコマンドリファレンスは <tt><bf>?</bf></tt> とします。
|
||||
@ -1,429 +0,0 @@
|
||||
<!-- $Id: bibliography.sgml,v 1.7 1997/03/21 09:46:34 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.26 -->
|
||||
|
||||
<chapt>
|
||||
<heading>参考図書<label id="bibliography"></heading>
|
||||
|
||||
<p><em>訳: &a.nakai;<newline>12 October 1996.</em>
|
||||
|
||||
<p>FreeBSD オペレーティングシステムの個々の部分については
|
||||
マニュアルページで定義のような説明がなされていますが,
|
||||
それらにはどうやってその部分どうしをつなぎあわせて
|
||||
オペレーティングシステム全体を円滑に動作させるかを
|
||||
説明していないという欠点がよく指摘されます.
|
||||
それを補うためには UNIX システム管理についてのよい本や,
|
||||
すぐれた利用者向けのマニュアルが欠かせません.
|
||||
|
||||
<sect>
|
||||
<heading>FreeBSDのためだけの書籍 & 雑誌</heading>
|
||||
|
||||
<p><bf>非英語文化圏の 書籍 & 雑誌:</bf>
|
||||
|
||||
<p><itemize>
|
||||
<item><htmlurl url="http://freebsd.csie.nctu.edu.tw/~jdli/book.html"
|
||||
name="FreeBSD 入門與應用"> (in Chinese).
|
||||
<item>FreeBSD入門キット 98版第二版. 宮嵜忠臣 著.
|
||||
秀和システム. ISBN4-87966-535-5 C3055 2900円.
|
||||
<item>FreeBSD入門キット AT互換機版 第二版. 宮嵜忠臣 著.
|
||||
秀和システム. ISBN4-87966-535-5 C3055 2900円.
|
||||
<item>ここまでできる FreeBSD パワーガイド.
|
||||
霜山 滋 仲道 嘉夫 山中右次 著. 秀和システム.
|
||||
ISBN 4-87966-637-8 2600円.
|
||||
</itemize>
|
||||
|
||||
<p><bf>英語の書籍 & 雑誌:</bf>
|
||||
|
||||
<p><itemize>
|
||||
<item><htmlurl url="http://www.cdrom.com/titles/os/bsdbook2.htm"
|
||||
name="The Complete FreeBSD">, published by <htmlurl
|
||||
url="http://www.cdrom.com" name="Walnut Creek CDROM">.
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>利用者向けのガイド</heading>
|
||||
|
||||
<p><itemize>
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD User's Reference Manual</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-075-9</item>
|
||||
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD User's Supplementary Documents</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-076-7</item>
|
||||
|
||||
<item><sl>UNIX in a Nutshell</sl>.
|
||||
O'Reilly & Associates, Inc., 1990.
|
||||
<newline>ISBN 093717520X</item>
|
||||
|
||||
<item>Mui, Linda.
|
||||
<em>What You Need To Know When You Can't Find Your UNIX
|
||||
System Administrator</em>.
|
||||
O'Reilly & Associates, Inc., 1995.
|
||||
<newline>ISBN 1-56592-104-6 </item>
|
||||
|
||||
<item><htmlurl url="http://www-wks.acs.ohio-state.edu/"
|
||||
name="Ohio State University"> has written
|
||||
a <htmlurl
|
||||
url="http://www-wks.acs.ohio-state.edu/unix_course/unix.html"
|
||||
name="UNIX Introductory Course"> which is available online
|
||||
in HTML and postscript format.</item>
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>管理者向けのガイド</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Albitz, Paul and Liu, Cricket. <em>DNS and
|
||||
BIND</em>, 2nd Ed.
|
||||
O'Reilly & Associates, Inc., 1997.
|
||||
<newline>ISBN ISBN 1-56592-236-0
|
||||
<newline>(訳注: 第一版の邦訳は以下のものが出版されています.
|
||||
<newline>浅羽登志也 / 上水流由香 監訳. <em>DNS & BIND</em>.
|
||||
アスキー, 1995.
|
||||
<newline>ISBN 4-7561-0314-6)
|
||||
</item>
|
||||
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD System Manager's Manual</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-080-5</item>
|
||||
|
||||
<item>Costales, Brian, et al.
|
||||
<em>Sendmail</em>, 2nd Ed. O'Reilly &
|
||||
Associates, Inc., 1997.
|
||||
<newline>ISBN 1-56592-222-0
|
||||
<newline>(訳注: 第一版の邦訳は以下のものが出版されています.
|
||||
<newline>村井純 監訳. <em>sendmail 解説</em>.
|
||||
インターナショナル・トムソン・パブリッシング・ジャパン, 1994.
|
||||
<newline>ISBN 4-900718-07-6)
|
||||
</item>
|
||||
|
||||
<item>Frisch, Æleen. <em>Essential System
|
||||
Administration</em>, 2nd Ed. O'Reilly &
|
||||
Associates, Inc., 1995. <newline>ISBN 1-56592-127-5
|
||||
<newline>(訳注: 第一版の邦訳は以下のものが出版されています.
|
||||
<newline>榊正憲 訳. <em>UNIX システム管理入門</em>.
|
||||
アスキー, 1995.
|
||||
<newline>ISBN 4-7561-0313-8)
|
||||
</item>
|
||||
|
||||
<item>Hunt, Craig. <em>TCP/IP Network Administration</em>.
|
||||
O'Reilly & Associates, Inc., 1992.
|
||||
<newline>ISBN 0-937175-82-X
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>村井純 監訳. <em>TCP/IP ネットワーク管理</em>.
|
||||
インターナショナル・トムソン・パブリッシング・ジャパン, 1994.
|
||||
<newline>ISBN 4-900718-01-7)
|
||||
</item>
|
||||
|
||||
<item>Nemeth, Evi. <em>UNIX System Administration
|
||||
Handbook</em>. 2nd ed. Prentice Hall, 1995.
|
||||
<newline>ISBN 0131510517
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>井上尚司監訳. <em>UNIX システム管理入門</em>.
|
||||
ソフトバンク, 1992.
|
||||
<newline>ISBN 4-89052-362-6
|
||||
<newline>原本は第2版だが、訳出は第1版のみ)
|
||||
</item>
|
||||
|
||||
<item>Stern, Hal <em>Managing NFS and NIS</em>
|
||||
O'Reilly & Associates, Inc., 1991.
|
||||
<newline>ISBN 1-937175-75-7 </item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>プログラマ向けのガイド</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Asente, Paul. <em>X Window System
|
||||
Toolkit</em>. Digital Press.
|
||||
<newline>ISBN 1-55558-051-3</item>
|
||||
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD Programmer's Reference Manual</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-078-3</item>
|
||||
|
||||
<item>Computer Systems Research Group, UC Berkeley.
|
||||
<sl>4.4BSD Programmer's Supplementary Documents</sl>.
|
||||
O'Reilly & Associates, Inc., 1994.
|
||||
<newline>ISBN 1-56592-079-1</item>
|
||||
|
||||
<item>Ellis, Margaret A. and Stroustrup,
|
||||
Bjarne. <em>The Annotated C++ Reference
|
||||
Manual</em>. Addison-Wesley, 1990.
|
||||
<newline>ISBN 0-201-51459-1
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>足立高徳 / 小山裕司 訳.
|
||||
<em>注解 C++ リファレンスマニュアル</em>.
|
||||
トッパン, 1992.
|
||||
<newline>ISBN 4-8101-8027-1)
|
||||
</item>
|
||||
|
||||
<item>Harbison, Samuel P. and Steele, Guy
|
||||
L. Jr. <em>C: A Reference Manual</em>. 4rd ed. Prentice
|
||||
Hall, 1995. <newline>ISBN 0-13-326224-3
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>斎藤信男監訳.
|
||||
<em>新・詳説C言語リファレンス[H&Sリファレンス]</em>.
|
||||
ソフトバンク, 1994.
|
||||
<newline>ISBN 4-89052-506-8
|
||||
<newline>原本は第4版だが、訳出は第3版のみ。)
|
||||
</item>
|
||||
|
||||
<item>Kernighan, Brian and Dennis M. Ritchie.
|
||||
<em>The C Programming Language.</em>.
|
||||
PTR Prentice Hall, 1988.
|
||||
<newline>ISBN 0-13-110362-9
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>石田晴久 訳.
|
||||
<em>プログラミング言語 C 第2版(訳書訂正版)</em>
|
||||
共立出版, 1989.
|
||||
<newline>ISBN 4-320-02692-6)
|
||||
</item>
|
||||
|
||||
<item>Lehey, Greg.
|
||||
<em>Port UNIX Software</em>.
|
||||
O'Reilly & Associates, Inc., 1995.
|
||||
<newline>ISBN 1-56592-126-7</item>
|
||||
|
||||
<item>Plauger, P. J. <em>The Standard C
|
||||
Library</em>. Prentice Hall, 1992.
|
||||
<newline>ISBN 0-13-131509-9
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>福富寛 / 門倉明彦 / 清水恵介 訳.
|
||||
<em>標準 C ライブラリ ANSI/ISO/JIS C規格</em>.
|
||||
トッパン, 1995.
|
||||
<newline>ISBN 4-8101-8541-9)
|
||||
</item>
|
||||
|
||||
<item>Stevens, W. Richard. <em>Advanced
|
||||
Programming in the UNIX Environment</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1992
|
||||
<newline>ISBN 0-201-56317-7
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>大木敦雄 訳.
|
||||
<em>詳解 UNIX プログラミング</em>. トッパン, 1994.
|
||||
<newline>ISBN 4-89052-524-6)
|
||||
</item>
|
||||
|
||||
<item>Stevens, W. Richard. <em>UNIX Network
|
||||
Programming</em>. PTR Prentice Hall, 1990.
|
||||
<newline>ISBN 0-13-949876-1
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>篠田陽一 訳.
|
||||
<em>UNIX ネットワークプログラミング</em>.
|
||||
トッパン,1992.
|
||||
<newline>ISBN 4-8101-8509-5)
|
||||
</item>
|
||||
|
||||
<item>Wells, Bill. "Writing Serial Drivers for UNIX".
|
||||
<em>Dr. Dobb's Journal</em>. 19(15), December
|
||||
1994. pp68-71, 97-99.</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>オペレーティングシステム内部</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Andleigh, Prabhat K. <em>UNIX System Architecture</em>.
|
||||
Prentice-Hall, Inc., 1990.
|
||||
<newline>ISBN 0-13-949843-5</item>
|
||||
|
||||
<item>Jolitz, William. "Porting UNIX to the
|
||||
386". <em>Dr. Dobb's Journal</em>. January
|
||||
1991-July 1992.
|
||||
</item>
|
||||
|
||||
<item>Leffler, Samuel J., Marshall Kirk McKusick,
|
||||
Michael J Karels and John Quarterman <em>The Design and
|
||||
Implementation of the 4.3BSD UNIX Operating
|
||||
System</em>. Reading, Mass. : Addison-Wesley, 1989.
|
||||
<newline>ISBN 0-201-06196-1
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>中村明 / 相田仁 / 計宇生 / 小池汎平 訳.
|
||||
<em>UNIX 4.3BSDの設計と実装</em>. 丸善, 1991.
|
||||
<newline>ISBN 4-621-03607-6)
|
||||
</item>
|
||||
|
||||
<item>Leffler, Samuel J., Marshall Kirk McKusick,
|
||||
<em>The Design and Implementation of the 4.3BSD
|
||||
UNIX Operating System: Answer Book</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1991.
|
||||
<newline>ISBN 0-201-54629-9
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>相田仁 / 計宇生 / 小池汎平 訳.
|
||||
<em>UNIX 4.3BSDの設計と実装</em>.
|
||||
アンサーブック, トッパン, 1991.
|
||||
<newline>ISBN 4-8101-8039-5)
|
||||
</item>
|
||||
|
||||
<item>McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
|
||||
and John Quarterman. <em>The Design and
|
||||
Implementation of the 4.4BSD Operating
|
||||
System</em>. Reading, Mass. : Addison-Wesley, 1996.
|
||||
<newline>ISBN 0-201-54979-4</item>
|
||||
|
||||
<item>Stevens, W. Richard. <em>TCP/IP Illustrated,
|
||||
Volume 1: The Protocols</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1996.
|
||||
<newline>ISBN 0-201-63346-9</item>
|
||||
|
||||
<item>Stevens, W. Richard. <em>TCP/IP Illustrated,
|
||||
Volume 3: TCP for Transactions, HTTP, NNTP
|
||||
and the UNIX Domain Protocols</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1996.
|
||||
<newline>ISBN 0-201-63495-3</item>
|
||||
|
||||
<item>Vahalia, Uresh. <em>UNIX Internals -- The New Frontiers</em>.
|
||||
Prentice Hall, 1996.
|
||||
<newline>ISBN 0-13-101908-2</item>
|
||||
|
||||
<item>Wright, Gary R. and W. Richard Stevens.
|
||||
<em>TCP/IP Illustrated, Volume 2:
|
||||
The Implementation</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1995.
|
||||
<newline>ISBN 0-201-63354-X</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
|
||||
<sect>
|
||||
<heading>セキュリティの参考資料</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Cheswick, William R. and Steven M. Bellovin.
|
||||
<em>Firewalls and Internal Security:
|
||||
Repelling the Wily Hacker</em>.
|
||||
Reading, Mass. : Addison-Wesley, 1995.
|
||||
<newline>ISBN 1-201-63357-4
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>川副博 監訳. <em>ファイアウォール</em>.
|
||||
ソフトバンク, 1995.
|
||||
<newline>ISBN 4-89052-672-2)
|
||||
</item>
|
||||
|
||||
<item>Garfinkel, Simson and Gene Spafford.
|
||||
<em>Practical UNIX Security</em>. 2nd Ed.
|
||||
O'Reilly & Associates, Inc., 1996.
|
||||
<newline>ISBN 1-56592-148-8
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>山口英監訳. <em>UNIX セキュリティ</em>.
|
||||
アスキー, 1993.
|
||||
<newline>ISBN 4-7561-0274-3
|
||||
<newline>原本は第2版だが、訳出は第1版のみ)
|
||||
</item>
|
||||
|
||||
<item>Garfinkel, Simson.
|
||||
<em>PGP Pretty Good Privacy</em>
|
||||
O'Reilly & Associates, Inc., 1995.
|
||||
<newline>ISBN 1-56592-098-8 </item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>ハードウェアの参考資料</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Anderson, Don and Tom Shanley.
|
||||
<em>Pentium Processor System Architecture</em>.
|
||||
2nd ed. Reading, Mass. : Addison-Wesley, 1995.
|
||||
<newline>ISBN 0-201-40992-5</item>
|
||||
|
||||
<item>Ferraro, Richard F. <em>Programmer's Guide
|
||||
to the EGA, VGA, and Super VGA Cards</em>.
|
||||
3rd ed. Reading, Mass. : Addison-Wesley, 1995.
|
||||
<newline>ISBN 0-201-62490-7</item>
|
||||
|
||||
<item>Shanley, Tom. <em>80486 System
|
||||
Architecture</em>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <newline>ISBN
|
||||
0-201-40994-1</item>
|
||||
|
||||
<item>Shanley, Tom. <em>ISA System
|
||||
Architecture</em>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995.
|
||||
<newline>ISBN 0-201-40996-8</item>
|
||||
|
||||
<item>Shanley, Tom. <em>PCI System
|
||||
Architecture</em>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. <newline>ISBN
|
||||
0-201-40993-3</item>
|
||||
|
||||
<item>Van Gilluwe, Frank. <em>The Undocumented PC</em>.
|
||||
Reading, Mass: Addison-Wesley Pub. Co., 1994.
|
||||
<newline>ISBN 0-201-62277-7</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>UNIX の歴史</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item>Lion, John <em>Lion's Commentary on UNIX, 6th Ed.
|
||||
With Source Code</em>.
|
||||
ITP Media Group, 1996.
|
||||
<newline>ISBN 1573980137</item>
|
||||
|
||||
<item>Raymond, Eric s. <em>The New Hacker's Dictonary,
|
||||
3rd edition</em>. MIT Press, 1996.
|
||||
<newline>ISBN 0-262-68092-0
|
||||
<newline>Also known as the
|
||||
<htmlurl url="http://www.ccil.org/jargon/jargon.html"
|
||||
name="Jargon File"></item>
|
||||
|
||||
<item>Saulus, Peter H. <em>A quarter century of UNIX</em>.
|
||||
Addison-Wesley Publishing Company, Inc., 1994.
|
||||
<newline>ISBN 0-201-54777-5</item>
|
||||
|
||||
<item>Simon Garfinkel, Daniel Weise, Steven Strassmann.
|
||||
<em>The UNIX-HATERS Handbook</em>.
|
||||
IDG Books Worldwide, Inc., 1994.
|
||||
<newline>ISBN 1-56884-203-1</item>
|
||||
|
||||
<item>Don Libes, Sandy Ressler <em>Life with UNIX</em> - special
|
||||
edition. Prentice-Hall, Inc., 1989.
|
||||
<newline>ISBN 0-13-536657-7
|
||||
<newline>(訳注: 邦訳は以下のものが出版されています.
|
||||
<newline>坂本文 監訳. <em>Life with UNIX</em>.
|
||||
アスキー, 1990.
|
||||
<newline>ISBN 4-7561-0783-4
|
||||
<newline>邦訳がSpecial 版の訳出か否かは不明)
|
||||
</item>
|
||||
|
||||
<item><em>BSD 系 OS の系譜図</em>. 1997年.
|
||||
<newline>
|
||||
<htmlurl url="http://www.de.freebsd.org/de/ftp/unix-stammbaum"
|
||||
name="http://www.de.freebsd.org/de/ftp/unix-stammbaum">
|
||||
または, FreeBSD-current マシンの<url
|
||||
url="file:/usr/share/misc/bsd-family-tree" name="ローカルファイル">.
|
||||
</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>雑誌とジャーナル</heading>
|
||||
|
||||
<p><itemize>
|
||||
|
||||
<item><em>The C/C++ Users Journal</em>. R&D Publications
|
||||
Inc. ISSN 1075-2838</item>
|
||||
|
||||
<item><em>Sys Admin - The Journal for UNIX System
|
||||
Administrators</em> Miller Freeman, Inc., ISSN 1061-2688</item>
|
||||
|
||||
</itemize>
|
||||
|
||||
</sect>
|
||||
|
||||
@ -1,51 +0,0 @@
|
||||
<!-- $Id: boothelp.sgml,v 1.4 1997/02/22 13:00:38 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.4 -->
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!-- Conditional flags for this version of the document -->
|
||||
<!ENTITY % boothelp.only "INCLUDE">
|
||||
<!ENTITY % handbook.only "IGNORE">
|
||||
|
||||
<!-- Entity shorthand for authors' names and email addresses -->
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
<!-- Entity definitions for all the parts -->
|
||||
<!ENTITY % sections SYSTEM "sections.sgml">
|
||||
%sections;
|
||||
|
||||
]>
|
||||
|
||||
<linuxdoc>
|
||||
<book>
|
||||
|
||||
<title>FreeBSD のインストール
|
||||
<author>
|
||||
<name></name>
|
||||
</author>
|
||||
|
||||
<abstract>FreeBSD の世界へようこそ! このガイドは FreeBSD の
|
||||
インストール方法について説明しています.
|
||||
矢印キーの<bf>上</bf>と<bf>下</bf>を使って
|
||||
このガイドの読みたいセクションに移動し,
|
||||
<bf>右矢印キー</bf>か<bf>リターンキー</bf>を使ってお読みください.
|
||||
一度読んだことのあるセクションは<bf>左矢印キー</bf>で
|
||||
戻って読みなおすことができます.
|
||||
</abstract>
|
||||
|
||||
<chapt><heading>一般的な情報</heading>
|
||||
&nutshell;
|
||||
&history;
|
||||
&relnotes;
|
||||
|
||||
&install;
|
||||
&troubleshooting;
|
||||
&bibliography;
|
||||
&eresources;
|
||||
&hw;
|
||||
&contrib;
|
||||
|
||||
</book>
|
||||
</linuxdoc>
|
||||
@ -1,183 +0,0 @@
|
||||
<!-- $Id: booting.sgml,v 1.4 1997/02/22 13:00:39 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.13 -->
|
||||
|
||||
<!-- This is a SGML version of the text on FreeBSD boot procedures
|
||||
made by Poul-Henning Kamp <phk@FreeBSD.ORG>
|
||||
|
||||
This conversion has been made by Ollivier Robert.
|
||||
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
||||
<article>
|
||||
|
||||
<title>ブートの概要</title>
|
||||
<author>Poul-Henning Kamp, <tt/<phk@login.dknet.dk>/</author>
|
||||
<date>v1.1, April 26th</date>
|
||||
<abstract>
|
||||
FreeBSDのブートには基本的に3つの段階があります:
|
||||
カーネルの読み込み、ルートのファイルシステムの決定、そして
|
||||
ユーザ領域にあるものの初期化です。このことは下に述べる
|
||||
いくつかの興味深い可能性につながっているのです...
|
||||
</abstract>
|
||||
|
||||
<toc>
|
||||
-->
|
||||
|
||||
<sect><heading>FreeBSDのブート処理の流れ<label id="booting"></heading>
|
||||
|
||||
<p><em>原作: &a.phk;. v1.1, April 26th.</em>
|
||||
<p><em>訳: &a.nakai; September 6 1996.</em>
|
||||
|
||||
FreeBSDのブートには基本的に3つの段階があります:
|
||||
カーネルの読み込み, ルートのファイルシステムの決定, そして
|
||||
ユーザ領域にあるものの初期化です. このことは下に述べる
|
||||
いくつかの興味深い可能性につながっています。
|
||||
|
||||
<sect1><heading>カーネルの読み込み</heading>
|
||||
<p>
|
||||
現在, カーネルの読み込みには基本的に下に挙げる3つの方法が
|
||||
あります:
|
||||
これらはカーネルが次に何をしたらいいのかという情報をカーネルに
|
||||
与えます.
|
||||
|
||||
<descrip>
|
||||
<tag>Biosboot</tag>
|
||||
|
||||
Biosbootは「ブートブロック」に相当するもので, 2つのファイル
|
||||
から構成されており, フロッピーディスクやハードディスクのブートを
|
||||
開始する側の 8K バイトにインストールされています。
|
||||
|
||||
Biosboot は FreeBSD のファイルシステムからカーネルを
|
||||
読み込むことができます.
|
||||
|
||||
<tag>Dosboot</tag>
|
||||
|
||||
Dosbootは DI. Christian Gusenbauerによって書かれましたが,
|
||||
不幸にしてこの場合には、コードのある一部分がマイクロソフトの
|
||||
コンパイラ向けに書かれているため、FreeBSD 単体ではコンパイル
|
||||
することはできません.
|
||||
|
||||
Dosboot は MS-DOS のファイルから、またはディスクの
|
||||
FreeBSD ファイルシステムのパーティションからカーネルをブートします。
|
||||
これは MS-DOS システムのハイメモリ領域に潜んでいるメモリマネージャ等の
|
||||
さまざまな怪しい代物とメモリの取り合いをして、なんとかブートしています.
|
||||
|
||||
<tag>Netboot</tag>
|
||||
|
||||
Netboot はサポートされているイーサネットカードを検出し、
|
||||
BOOTP や TFTP、NFS を使ってブートするカーネルを探そうとします。
|
||||
|
||||
</descrip>
|
||||
|
||||
|
||||
<sect1><heading>ルートファイルシステムの決定</heading>
|
||||
<p>
|
||||
カーネルが読み込まれ、ブートプログラムがカーネルに移行したら,
|
||||
カーネルは自身の初期化をし, どんなハードウェアが組み込まれいるか
|
||||
を決定し、それからルートファイルシステムを探さなくてはなりません。
|
||||
|
||||
現在サポートされているルートファイルシステムは次の通りです :
|
||||
|
||||
<descrip>
|
||||
<tag>UFS</tag>
|
||||
|
||||
UFS は, もっとも一般的なタイプのルートシステムです。
|
||||
フロッピーディスクやハードディスク上に存在します。
|
||||
|
||||
<tag>MSDOS</tag>
|
||||
|
||||
技術的に可能ですが、あまり有用ではありません。なぜならば、
|
||||
``FAT''ファイルシステムではリンクやデバイスノードなどの
|
||||
``UNIX 主義''を実現できないからです。
|
||||
|
||||
<tag>MFS</tag>
|
||||
|
||||
MFS はカーネル内部に組み込みになっている UFS
|
||||
ファイルシステムです。つまり MFS を機能させるのに
|
||||
ディスクやフロッピーディスクなどのハードウェアは
|
||||
必要ではありません.
|
||||
|
||||
|
||||
<tag>CD9660</tag>
|
||||
|
||||
CD9660 は CD-ROM をルートファイルシステムに使用したものです。
|
||||
|
||||
<tag>NFS</tag>
|
||||
|
||||
これはルートシステムにファイルサーバを使用していて、基本的に
|
||||
ディスクレスのマシンのためにあります。
|
||||
</descrip>
|
||||
|
||||
|
||||
<sect1><heading>ユーザ領域にあるものの初期化</heading>
|
||||
<p>
|
||||
|
||||
ユーザ領域で動作させるようにするために、カーネルが初期化を終えると、
|
||||
カーネルは``<tt/pid == 1/''のプロセスを生成し、ルートファイルシステム
|
||||
上のプログラムを実行します。このプログラムは通常``<tt>/sbin/init</tt>''
|
||||
です。
|
||||
|
||||
/sbin/init を別なプログラム置き換えてしまうことは可能ですが、そのプロセス
|
||||
には以下のような制約があります:
|
||||
|
||||
pid が 1 のプロセスには stdin/stdout/stderr は割り当てられていませんので、
|
||||
プログラムは自分でこれらをオープンしないとなりません。
|
||||
このプロセスが終了するとカーネルはパニックメッセージを表示して
|
||||
停止します。
|
||||
また、このプロセスに対するシグナル処理は特殊です。
|
||||
|
||||
この例として、インストール用のフロッピーディスクにある
|
||||
``<tt>/stand/sysinstall</tt>''があります。
|
||||
|
||||
|
||||
<sect1><heading>興味深い連係</heading>
|
||||
<p>
|
||||
カーネルを MFS でブートするのには次のような特別の<tt>/sbin/init</tt>
|
||||
を使います。
|
||||
<descrip>
|
||||
<tag/A -- DOS を使う場合/
|
||||
<itemize>
|
||||
<item><tt/C:/ を <tt>/C:</tt> にマウントします。
|
||||
<item><tt>C:/freebsd.fs</tt> を <tt>/dev/vn0</tt> にアタッチします。
|
||||
<item><tt>/dev/vn0</tt> を <tt>/rootfs</tt> にマウントします。
|
||||
<item>シンボリックリンクを作ります。<newline>
|
||||
<tt>/rootfs/bin -> /bin</tt><newline>
|
||||
<tt>/rootfs/etc -> /etc</tt><newline>
|
||||
<tt>/rootfs/sbin -> /sbin</tt><newline>
|
||||
(etc...)<newline>
|
||||
</itemize>
|
||||
|
||||
これでハードディスクのパーティションを切り直さずに FreeBSD を
|
||||
使うことができます。
|
||||
|
||||
<tag/B -- NFS を使う場合/
|
||||
|
||||
NFS は<tt>サーバ:˜you/FreeBSD</tt> を
|
||||
<tt>/nfs</tt>にマウントし、ルートディレクトリを <tt>/nfs</tt> に変更して,
|
||||
そこで<tt>/sbin/init</tt>を実行します。
|
||||
|
||||
これで FreeBSD をディスクレスで実行できますが、NFS サーバを
|
||||
コントロールできないままです...
|
||||
|
||||
<tag/C -- X-server を起動する場合/
|
||||
|
||||
これで Xターミナルが手に入りました. これは, これでハードウェア
|
||||
に費用を割いたりするよりはいい, と上司が主張した, Windows で
|
||||
動作する遅くて何がおこなわれているのか見ることができるような
|
||||
すすけた X Window エミュレータなんかよりよいものです.
|
||||
|
||||
<tag/D -- テープを使う場合/
|
||||
<tt>/dev/rwd0</tt> のコピーを取って、リモートにあるテープ
|
||||
ステーションやファイルサーバに書き込んでください。
|
||||
|
||||
これで一年前に取っておくべきだったバックアップをやっと
|
||||
取ることができました。
|
||||
|
||||
<tag>E -- ファイアウォール/Web サーバとして動作させる場合 (私の知っている範囲で...)</tag>
|
||||
|
||||
これは特に面白いもので、書き込み禁止のフロッピーディスクから
|
||||
ブートができて、ルートのファイルシステムに書き込むことができる
|
||||
というものです。
|
||||
</descrip>
|
||||
@ -1,499 +0,0 @@
|
||||
<!-- $Id: contrib.sgml,v 1.57 1997/05/20 14:25:19 max Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.249 -->
|
||||
|
||||
<!-- Please try to keep the file 'avail' (from CVSROOT)
|
||||
in sync with the list of FreeBSD Developers -->
|
||||
|
||||
<chapt><heading>FreeBSDプロジェクトスタッフ<label id="staff"></heading>
|
||||
|
||||
<p><em>訳: &a.hanai;<newline>28 August 1996.</em>
|
||||
|
||||
<p>FreeBSDプロジェクトは, 以下の人々によって管理運営されています.
|
||||
|
||||
<sect><heading>FreeBSD コアチーム<label id="contrib:core"></heading>
|
||||
<p>FreeBSD コアチームは, プロジェクトの運用委員会を形成し, FreeBSD
|
||||
プロジェクトの全般的な目的や方針の決定を行います. さらに,
|
||||
FreeBSDプロジェクトの<ref id="contrib:who" name="特定の分野">の
|
||||
運用も行っています.
|
||||
|
||||
<p>(姓でアルファベット順):
|
||||
|
||||
<itemize>
|
||||
<item>&a.asami;
|
||||
<item>&a.jmb;
|
||||
<item>&a.ache;
|
||||
<item>&a.dyson;
|
||||
<item>&a.bde;
|
||||
<item>&a.gibbs;
|
||||
<item>&a.davidg;
|
||||
<item>&a.jkh;
|
||||
<item>&a.phk;
|
||||
<item>&a.rich;
|
||||
<item>&a.gpalmer;
|
||||
<item>&a.jdp;
|
||||
<item>&a.guido;
|
||||
<item>&a.sos;
|
||||
<item>&a.peter;
|
||||
<item>&a.wollman;
|
||||
<item>&a.joerg;
|
||||
</itemize>
|
||||
|
||||
<sect><heading>FreeBSD の開発者たち<label id="contrib:committers"></heading>
|
||||
|
||||
<p>(CVSの)commitする権利を持っていて, FreeBSD のソースツリーについて
|
||||
作業をおこなっている人々がいます. すべてのコアチームのメンバと
|
||||
ほとんどの FreeBSDドキュメンテーションプロジェクトのスタッフはま
|
||||
た 開発者でもあります.
|
||||
|
||||
<itemize>
|
||||
<item>&a.mbarkah;
|
||||
<item>&a.stb;
|
||||
<item>&a.jb;
|
||||
<item>&a.torstenb;
|
||||
<item>&a.danny;
|
||||
<item>&a.charnier;
|
||||
<item>&a.kjc;
|
||||
<item>&a.gclarkii;
|
||||
<item>&a.cracauer;
|
||||
<item>&a.adam;
|
||||
<item>&a.dufault;
|
||||
<item>&a.uhclem;
|
||||
<item>&a.tegge;
|
||||
<item>&a.eivind;
|
||||
<item>&a.sef;
|
||||
<item>&a.julian;
|
||||
<item>&a.se;
|
||||
<item>&a.fenner;
|
||||
<item>&a.jfieber;
|
||||
<item>&a.jfitz;
|
||||
<item>&a.lars;
|
||||
<item>&a.scrappy;
|
||||
<item>&a.tg;
|
||||
<item>&a.graichen;
|
||||
<item>&a.jgreco;
|
||||
<item>&a.rgrimes;
|
||||
<item>&a.jmg;
|
||||
<item>&a.jhay;
|
||||
<item>&a.hsu;
|
||||
<item>&a.ugen;
|
||||
<item>&a.gj;
|
||||
<item>&a.nsj;
|
||||
<item>&a.ljo;
|
||||
<item>&a.darrenr;
|
||||
<item>&a.kato;
|
||||
<item>&a.andreas;
|
||||
<item>&a.erich;
|
||||
<item>&a.imp;
|
||||
<item>&a.smace;
|
||||
<item>&a.mckay;
|
||||
<item>&a.tedm;
|
||||
<item>&a.amurai;
|
||||
<item>&a.markm;
|
||||
<item>&a.max;
|
||||
<item>&a.alex;
|
||||
<item>&a.davidn;
|
||||
<item>&a.obrien;
|
||||
<item>&a.fsmp;
|
||||
<item>&a.smpatel;
|
||||
<item>&a.wpaul;
|
||||
<item>&a.jmacd;
|
||||
<item>&a.steve;
|
||||
<item>&a.mpp;
|
||||
<item>&a.dfr;
|
||||
<item>&a.jraynard;
|
||||
<item>&a.csgr;
|
||||
<item>&a.martin;
|
||||
<item>&a.paul;
|
||||
<item>&a.roberto;
|
||||
<item>&a.chuckr;
|
||||
<item>&a.dima;
|
||||
<item>&a.wosch;
|
||||
<item>&a.ats;
|
||||
<item>&a.msmith;
|
||||
<item>&a.brian;
|
||||
<item>&a.stark;
|
||||
<item>&a.karl;
|
||||
<item>&a.pst;
|
||||
<item>&a.swallace;
|
||||
<item>&a.nate;
|
||||
<item>&a.yokota;
|
||||
<item>&a.jmz;
|
||||
<item>&a.hanai;
|
||||
</itemize>
|
||||
|
||||
<sect><heading>FreeBSD ドキュメンテーションプロジェクト<label
|
||||
id="contrib:doc"></heading>
|
||||
|
||||
<p>FreeBSD ドキュメンテーションプロジェクトは複数のサービスを提供
|
||||
しています. それぞれのサービスは, 以下の担当者とその
|
||||
<em>副担当者</em>によって運用されています.
|
||||
|
||||
<p><descrip>
|
||||
<tag/ドキュメンテーションプロジェクト担当/ &a.jfieber
|
||||
<tag/Web 管理責任者/ &a.mbarkah; <p><em>副責任者:</em> &a.paul
|
||||
<tag/ハンドブックおよび FAQ 編集担当/ &a.pds
|
||||
<tag/ドキュメント構築環境の技術責任者/ &a.paul; <p><em>副責任者:</em> &a.dave
|
||||
<tag/Mirror 担当/ &a.ulf; <p><em>副担当</em>&a.john
|
||||
<tag/ニュースフラッシュ編集担当/ &a.nsj; <p><em>副担当:</em>&a.john;
|
||||
<tag/FreeBSD ギャラリーおよび商用ベンダ情報ページ担当/ &a.nsj; <p><em>副担当</em>&a.cawimm
|
||||
<tag/WEB ページデザイン等の美術担当/ &a.dave; <p><em>副担当:</em>&a.opsys
|
||||
<tag/データベース技術担当/ &a.mayo; <p><em>副担当:</em>&a.cracauer
|
||||
<tag/CGI 技術担当/ &a.cracauer;<p><em>副担当:</em> &a.stb
|
||||
<tag/雑務担当/ &a.nsj
|
||||
</descrip>
|
||||
|
||||
<sect><heading>担当者<label id="contrib:who"></heading>
|
||||
|
||||
<p><descrip>
|
||||
<tag/最高技術責任者/ &a.davidg
|
||||
<tag/ドキュメンテーションプロジェクト担当/ &a.jfieber
|
||||
<tag/国際化/ &a.ache
|
||||
<tag/ネットワーク/ &a.wollman
|
||||
<tag/ポストマスタ/ &a.jmb;
|
||||
<tag/リリースコーディネータ/ &a.jkh
|
||||
<tag/広報および渉外担当/ &a.jkh
|
||||
<tag/セキュリティ担当/ &a.guido
|
||||
<tag/CVS ツリー管理者/ &a.peter
|
||||
<tag/ports コレクション担当/ &a.asami
|
||||
<tag/XFree86 Project, Inc. との渉外担当/ &a.rich
|
||||
<tag/Usenet サポート/ &a.joerg;
|
||||
</descrip>
|
||||
|
||||
<chapt><heading>FreeBSDへのコントリビュータ<label id="contrib"></heading>
|
||||
|
||||
<sect><heading>BSD派生ソフトウェアへのコントリビュータ</heading>
|
||||
|
||||
<p>このソフトウェアは最初は William F. Jolitz の 386BSD release 0.1
|
||||
から派生しましたが, オリジナルの 386BSD に固有のコードはほとんど
|
||||
残っていません. このソフトウェアは基本的にはカリフォルニア大学
|
||||
バークレイ校の Computer Science Research Group (CSRG) とその共同研究者
|
||||
たちによる 4.4BSD-Lite リリースから再実装されました.
|
||||
|
||||
また, NetBSD の一部も FreeBSD に取り込まれています. したがって私たちは
|
||||
NetBSD へ貢献した人々すべてに感謝します.二つのグループの関係が
|
||||
ギクシャクすることも時にはありますが, 私たちは基本的には共に同じ目的
|
||||
を持っています. すなわち, 人々のコンピュータにもっと BSD をベースに
|
||||
したオペレーティングシステムを! ということです. 私たちは NetBSD
|
||||
の努力が常に成功してほしいと思っています.
|
||||
|
||||
<sect><heading>その他の FreeBSD へのコントリビュータ<label
|
||||
id="contrib:additional"></heading>
|
||||
|
||||
<p>(名前でアルファベット順に):
|
||||
|
||||
<itemize>
|
||||
<item>A JOSEPH KOSHY <koshy@india.hp.com>
|
||||
<item>ABURAYA Ryushirou <pcs51674@asciinet.or.jp>
|
||||
<item>Adam Glass <glass@postgres.berkeley.edu>
|
||||
<item>Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu>
|
||||
<item>Akito Fujita <fujita@zoo.ncl.omron.co.jp>
|
||||
<item>Alain Kalker <A.C.P.M.Kalker@student.utwente.nl>
|
||||
<item>Alan Cox <alc@cs.rice.edu>
|
||||
<item>Andreas Kohout <shanee@rabbit.augusta.de>
|
||||
<item>Andreas Lohr <andreas@marvin.RoBIN.de>
|
||||
<item>Andrew Gordon <andrew.gordon@net-tel.co.uk>
|
||||
<item>Andrew Herbert <andrew@werple.apana.org.au>
|
||||
<item>Andrew McRae <amcrae@cisco.com>
|
||||
<item>Andrew Moore <alm@FreeBSD.org>
|
||||
<item>Andrew Stevenson <andrew@ugh.net.au>
|
||||
<item>Andrew V. Stesin <stesin@elvisti.kiev.ua>
|
||||
<item>Andrey Zakhvatov <andy@cgu.chel.su>
|
||||
<item>Andy Whitcroft <andy@sarc.city.ac.uk>
|
||||
<item>Anthony Yee-Hang Chan <yeehang@netcom.com>
|
||||
<item>Brent J. Nordquist <bjn@visi.com>
|
||||
<item>Bernd Rosauer <br@schiele-ct.de>
|
||||
<item>Bill Kish <kish@osf.org>
|
||||
<item>&a.wlloyd
|
||||
<item>Bob Wilcox <bob@obiwan.uucp>
|
||||
<item>Boyd Faulkner <faulkner@mpd.tandem.com>
|
||||
<item>Brent J. Nordquist <bjn@visi.com>
|
||||
<item>Brian Clapper <bmc@willscreek.com>
|
||||
<item>Brian Handy <handy@lambic.space.lockheed.com>
|
||||
<item>Brian Tao <taob@risc.org>
|
||||
<item>Carey Jones <mcj@acquiesce.org>
|
||||
<item>Charles Hannum <mycroft@ai.mit.edu>
|
||||
<item>Charles Mott <cmott@srv.net>
|
||||
<item>Chet Ramey <chet@odin.INS.CWRU.Edu>
|
||||
<item>Chris Dabrowski < chris@vader.org>
|
||||
<item>Chris G. Demetriou <cgd@postgres.berkeley.edu>
|
||||
<item>Chris Stenton <jacs@gnome.co.uk>
|
||||
<item>Chris Timmons <skynyrd@opus.cts.cwu.edu>
|
||||
<item>Chris Torek <torek@ee.lbl.gov>
|
||||
<item>Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at>
|
||||
<item>Christian Haury <Christian.Haury@sagem.fr>
|
||||
<item>Christoph Robitschko <chmr@edvz.tu-graz.ac.at>
|
||||
<item>Choi Jun Ho <junker@jazz.snu.ac.kr>
|
||||
<item>Chuck Hein <chein@cisco.com>
|
||||
<item>Conrad Sabatier <conrads@neosoft.com>
|
||||
<item>Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de>
|
||||
<item>Craig Struble <cstruble@vt.edu>
|
||||
<item>Cristian Ferretti <cfs@riemann.mat.puc.cl>
|
||||
<item>Curt Mayer <curt@toad.com>
|
||||
<item>Dan Cross <tenser@spitfire.ecsel.psu.edu>
|
||||
<item>Daniel Baker <dbaker@crash.ops.neosoft.com>
|
||||
<item>Daniel M. Eischen <deischen@iworks.InterWorks.org>
|
||||
<item>Danny J. Zerkel <dzerkel@feephi.phofarm.com>
|
||||
<item>Dave Bodenstab <imdave@synet.net>
|
||||
<item>Dave Burgess <burgess@hrd769.brooks.af.mil>
|
||||
<item>Dave Chapeskie <dchapes@zeus.leitch.com>
|
||||
<item>Dave Edmondson <davided@sco.com>
|
||||
<item>Dave Rivers <rivers@ponds.uucp>
|
||||
<item>David Dawes <dawes@physics.su.OZ.AU>
|
||||
<item>David Leonard <d@scry.dstc.edu.au>
|
||||
<item>Dean Huxley <dean@fsa.ca>
|
||||
<item>Dirk Froemberg <dirk@hal.in-berlin.de>
|
||||
<item>Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
|
||||
<item>Dmitry Kohmanyuk <dk@farm.org>
|
||||
<item>&a.whiteside;
|
||||
<item>Don Yuniskis <dgy@rtd.com>
|
||||
<item>Donald Burr <d_burr@ix.netcom.com>
|
||||
<item>Doug Ambrisko <ambrisko@ambrisko.roble.com>
|
||||
<item>Eric Blood <eblood@cs.unr.edu>
|
||||
<item>Frank Bartels <knarf@camelot.de>
|
||||
<item>Frank Maclachlan <fpm@crash.cts.com>
|
||||
<item>Frank Nobis <fn@trinity.radio-do.de>
|
||||
<item>FURUSAWA Kazuhisa <furusawa@com.cs.osakafu-u.ac.jp>
|
||||
<item>Gary A. Browning <gab10@griffcd.amdahl.com>
|
||||
<item>Greg Ungerer <gerg@stallion.oz.au>
|
||||
<item>Harlan Stenn <Harlan.Stenn@pfcs.com>
|
||||
<item>Havard Eidnes <Havard.Eidnes@runit.sintef.no>
|
||||
<item>Hideaki Ohmon <ohmon@tom.sfc.keio.ac.jp>
|
||||
<item>Hidekazu Kuroki <hidekazu@cs.titech.ac.jp>
|
||||
<item>Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
|
||||
<item>Holger Veit <Holger.Veit@gmd.de>
|
||||
<item>Hung-Chi Chu <hcchu@r350.ee.ntu.edu.tw>
|
||||
<item>Igor Vinokurov <igor@zynaps.ru>
|
||||
<item>Ikuo Nakagawa <ikuo@isl.intec.co.jp>
|
||||
<item>IMAMURA Tomoaki <tomoak-i@is.aist-nara.ac.jp>
|
||||
<item>Ishii Masahiro <?>
|
||||
<item>Itsuro Saito <saito@miv.t.u-tokyo.ac.jp>
|
||||
<item>J. David Lowe <lowe@saturn5.com>
|
||||
<item>J.T. Conklin <jtc@cygnus.com>
|
||||
<item>James Clark <jjc@jclark.com>
|
||||
<item>James da Silva <jds@cs.umd.edu> et al
|
||||
<item>Janusz Kokot <janek@gaja.ipan.lublin.pl>
|
||||
<item>Jason Thorpe <thorpej@nas.nasa.gov>
|
||||
<item>Javier Martin Rueda <jmrueda@diatel.upm.es>
|
||||
<item>Jeffrey Wheat <jeff@cetlink.net>
|
||||
<item>Jian-Da Li <jdli@csie.NCTU.edu.tw>
|
||||
<item>Jim Lowe <james@cs.uwm.edu>
|
||||
<item>Jim Wilson <wilson@moria.cygnus.com>
|
||||
<item>Johann Tonsing <jtonsing@mikom.csir.co.za>
|
||||
<item>Joel Sutton <suttonj@interconnect.com.au>
|
||||
<item>John Capo <jc@irbs.com>
|
||||
<item>John Perry <perry@vishnu.alias.net>
|
||||
<item>Juergen Lock <nox@jelal.hb.north.de>
|
||||
<item>Juha Inkari <inkari@cc.hut.fi>
|
||||
<item>Julian Assange <proff@suburbia.net>
|
||||
<item>Julian Jenkins <kaveman@magna.com.au>
|
||||
<item>Julian Stacey <jhs@freebsd.org>
|
||||
<item>Jun-ichiro Itoh <itojun@csl.sony.co.jp>
|
||||
<item>Justin M. Seger <jseger@scds.ziplink.net>
|
||||
<item>Kazuhiko Kiriyama <kiri@kiri.toba-cmt.ac.jp>
|
||||
<item>Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
|
||||
<item>Keith Bostic <bostic@bostic.com>
|
||||
<item>Keith Moore <?>
|
||||
<item>Kenneth Monville <desmo@bandwidth.org>
|
||||
<item>Kent Vander Velden <graphix@iastate.edu>
|
||||
<item>Kirk McKusick <mckusick@mckusick.com>
|
||||
<item>Kiroh HARADA <kiroh@kh.rim.or.jp>
|
||||
<item>Koichi Sato <copan@ppp.fastnet.or.jp>
|
||||
<item>Kostya Lukin <lukin@okbmei.msk.su>
|
||||
<item>Kurt Olsen <kurto@tiny.mcs.usu.edu>
|
||||
<item>Lars Koeller <Lars_Koeller@odie.physik2.uni-rostock.de>
|
||||
<item>Lucas James <Lucas.James@ldjpc.apana.org.au>
|
||||
<item>Luigi Rizzo <luigi@iet.unipi.it>
|
||||
<item>Makoto Matsushita <matusita@ics.es.osaka-u.ac.jp>
|
||||
<item>Manu Iyengar <iyengar@grunthos.pscwa.psca.com>
|
||||
<item>Marc Frajola <marc@dev.com>
|
||||
<item>Marc Ramirez <mrami@mramirez.sy.yale.edu>
|
||||
<item>Marc Slemko <marcs@znep.com>
|
||||
<item>Marc van Kempen <wmbfmk@urc.tue.nl>
|
||||
<item>Mark Huizer <xaa@stack.nl>
|
||||
<item>Mark J. Taylor <mtaylor@cybernet.com>
|
||||
<item>Mark Tinguely <tinguely@plains.nodak.edu>
|
||||
<tinguely@hookie.cs.ndsu.NoDak.edu>
|
||||
<item>Martin Birgmeier
|
||||
<item>Masachika ISHIZUKA <ishizuka@isis.min.ntt.jp>
|
||||
<item>Mats Lofkvist <mal@algonet.se>
|
||||
<item>Matt Bartley <mbartley@lear35.cytex.com>
|
||||
<item>Matt Thomas <thomas@lkg.dec.com>
|
||||
<item>Matt White <mwhite+@CMU.EDU>
|
||||
<item>Matthew Hunt <mph@pobox.com>
|
||||
<item>Matthew N. Dodd <winter@jurai.net>
|
||||
<item>Matthew Stein <matt@bdd.net>
|
||||
<item>Michael Butschky <butsch@computi.erols.com>
|
||||
<item>Michael Elbel <me@FreeBSD.ORG>
|
||||
<item>Michael Searle <searle@longacre.demon.co.uk>
|
||||
<item>Miguel Angel Sagreras <msagre@cactus.fi.uba.ar>
|
||||
<item>Mikael Hybsch <micke@dynas.se>
|
||||
<item>Mikhail Teterin <mi@aldan.ziplink.net>
|
||||
<item>Mike McGaughey <mmcg@cs.monash.edu.au>
|
||||
<item>Mike Peck <mike@binghamton.edu>
|
||||
<item>MITA Yoshio <mita@jp.FreeBSD.ORG>
|
||||
<item>MOROHOSHI Akihiko <moro@race.u-tokyo.ac.jp>
|
||||
<item>Naoki Hamada <nao@tom-yam.or.jp>
|
||||
<item>Narvi <narvi@haldjas.folklore.ee>
|
||||
<item>NIIMI Satoshi <sa2c@and.or.jp>
|
||||
<item>Nick Sayer <nsayer@quack.kfu.com>
|
||||
<item>Nisha Talagala <nisha@cs.berkeley.edu>
|
||||
<item>Nobuhiro Yasutomi <nobu@psrc.isac.co.jp>
|
||||
<item>Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp>
|
||||
<item>Noritaka Ishizumi <graphite@jp.FreeBSD.ORG>
|
||||
<item>Oliver Laumann <net@informatik.uni-bremen.de>
|
||||
<item>Oliver Oberdorf <oly@world.std.com>
|
||||
<item>Paul Fox <pgf@foxharp.boston.ma.us>
|
||||
<item>Paul Kranenburg <pk@cs.few.eur.nl>
|
||||
<item>Paul Mackerras <paulus@cs.anu.edu.au>
|
||||
<item>Paulo Menezes <paulo@isr.uc.pt>
|
||||
<item>Pedro Giffuni <pgiffuni@fps.biblos.unal.edu.co>
|
||||
<item>Pedro A M Vazquez <vazquez@IQM.Unicamp.BR>
|
||||
<item>Peter Stubbs <PETERS@staidan.qld.edu.au>
|
||||
<item>R. Kym Horsell <?>
|
||||
<item>Ralf S. Engelschall <rse@engelschall.com>
|
||||
<item>Randall Hopper <rhh@stealth.ct.picker.com>
|
||||
<item>Richard Stallman <rms@gnu.ai.mit.edu>
|
||||
<item>Richard Wiwatowski <rjwiwat@adelaide.on.neti>
|
||||
<item>Rob Mallory <rmallory@csusb.edu>
|
||||
<item>Rob Shady <rls@id.net>
|
||||
<item>Rob Snow <rsnow@txdirect.net>
|
||||
<item>Robert Sanders <rsanders@mindspring.com>
|
||||
<item>Robert Withrow <witr@rwwa.com>
|
||||
<item>Ronald Kuehn <kuehn@rz.tu-clausthal.de>
|
||||
<item>Samuel Lam <skl@ScalableNetwork.com>
|
||||
<item>Sander Vesik <sander@haldjas.folklore.ee>
|
||||
<item>Sandro Sigala <ssigala@globalnet.it>
|
||||
<item>Sascha Blank <blank@fox.uni-trier.de>
|
||||
<item>Sascha Wildner <swildner@channelz.GUN.de>
|
||||
<item>Scott Blachowicz <scott@sabami.seaslug.org>
|
||||
<item>Serge V. Vakulenko <vak@zebub.msk.su>
|
||||
<item>Simon Marlow <simonm@dcs.gla.ac.uk>
|
||||
<item>Slaven Rezic (Tomic) <eserte@cs.tu-berlin.de>
|
||||
<item>Soren Dayton <csdayton@midway.uchicago.edu>
|
||||
<item>Stefan Moeding <moeding@bn.DeTeMobil.de>
|
||||
<item>Steve Gerakines <steve2@genesis.tiac.net>
|
||||
<item>Suzuki Yoshiaki <zensyo@ann.tama.kawasaki.jp>
|
||||
<item>Tadashi Kumano <kumano@strl.nhk.or.jp>
|
||||
<item>Taguchi Takeshi <taguchi@tohoku.iij.ad.jp>
|
||||
<item>Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp>
|
||||
<item>Terry Lambert <terry@lambert.org>
|
||||
<item>Terry Lee <terry@uivlsi.csl.uiuc.edu>
|
||||
<item>Theo Deraadt <deraadt@fsa.ca>
|
||||
<item>Thomas König <Thomas.Koenig@ciw.uni-karlsruhe.de>
|
||||
<item>Tim Kientzle <kientzle@netcom.com>
|
||||
<item>Tim Vanderhoek <ac199@freenet.hamilton.on.ca>
|
||||
<item>Tom Samplonius <tom@misery.sdf.com>
|
||||
<item>Torbjorn Granlund <tege@matematik.su.se>
|
||||
<item>Toshihiro Kanda <candy@fct.kgc.co.jp>
|
||||
<item>Vanill Ice <vanilla@Minje.Com.TW>
|
||||
<item>Ville Eerola <ve@sci.fi>
|
||||
<item>Werner Griessl <werner@btp1da.phy.uni-bayreuth.de>
|
||||
<item>Wes Santee <wsantee@wsantee.oz.net>
|
||||
<item>Wolfgang Stanglmeier <wolf@kintaro.cologne.de>
|
||||
<item>Yoshiro Mihira <sanpei@yy.cs.keio.ac.jp>
|
||||
<item>Yukihiro Nakai <nakai@mlab.t.u-tokyo.ac.jp>
|
||||
<item>Yuval Yarom <yval@cs.huji.ac.il>
|
||||
<item>Yves Fonk <yves@cpcoup5.tn.tudelft.nl>
|
||||
</itemize>
|
||||
|
||||
<sect><heading>386BSD パッチキットへのパッチ提供者</heading>
|
||||
|
||||
<p>(名前でアルファベット順):
|
||||
|
||||
<itemize>
|
||||
<item>Adam Glass <glass@postgres.berkeley.edu>
|
||||
<item>Adrian Hall <adrian@ibmpcug.co.uk>
|
||||
<item>Andrey A. Chernov <ache@astral.msk.su>
|
||||
<item>Andrew Herbert <andrew@werple.apana.org.au>
|
||||
<item>Andrew Moore <alm@netcom.com>
|
||||
<item>Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com>
|
||||
<item>Arne Henrik Juul <arnej@Lise.Unit.NO>
|
||||
<item>Bakul Shah <bvs@bitblocks.com>
|
||||
<item>Barry Lustig <barry@ictv.com>
|
||||
<item>Bob Wilcox <bob@obiwan.uucp>
|
||||
<item>Branko Lankester
|
||||
<item>Brett Lymn <blymn@mulga.awadi.com.AU>
|
||||
<item>Charles Hannum <mycroft@ai.mit.edu>
|
||||
<item>Chris G. Demetriou <cgd@postgres.berkeley.edu>
|
||||
<item>Chris Torek <torek@ee.lbl.gov>
|
||||
<item>Christoph Robitschko <chmr@edvz.tu-graz.ac.at>
|
||||
<item>Daniel Poirot <poirot@aio.jsc.nasa.gov>
|
||||
<item>Dave Burgess <burgess@hrd769.brooks.af.mil>
|
||||
<item>Dave Rivers <rivers@ponds.uucp>
|
||||
<item>David Dawes <dawes@physics.su.OZ.AU>
|
||||
<item>David Greenman <davidg@Root.COM>
|
||||
<item>Eric J. Haug <ejh@slustl.slu.edu>
|
||||
<item>Felix Gaehtgens <felix@escape.vsse.in-berlin.de>
|
||||
<item>Frank Maclachlan <fpm@crash.cts.com>
|
||||
<item>Gary A. Browning <gab10@griffcd.amdahl.com>
|
||||
<item>Geoff Rehmet <csgr@alpha.ru.ac.za>
|
||||
<item>Goran Hammarback <goran@astro.uu.se>
|
||||
<item>Guido van Rooij <guido@gvr.win.tue.nl>
|
||||
<item>Guy Harris <guy@auspex.com>
|
||||
<item>Havard Eidnes <Havard.Eidnes@runit.sintef.no>
|
||||
<item>Herb Peyerl <hpeyerl@novatel.cuc.ab.ca
|
||||
<item>Holger Veit <Holger.Veit@gmd.de>
|
||||
<item>Ishii Masahiro, R. Kym Horsell
|
||||
<item>J.T. Conklin <jtc@cygnus.com>
|
||||
<item>Jagane D Sundar < jagane@netcom.com >
|
||||
<item>James Clark <jjc@jclark.com>
|
||||
<item>James Jegers <jimj@miller.cs.uwm.edu>
|
||||
<item>James W. Dolter
|
||||
<item>James da Silva <jds@cs.umd.edu> et al
|
||||
<item>Jay Fenlason <hack@datacube.com>
|
||||
<item>Jim Wilson <wilson@moria.cygnus.com>
|
||||
<item>Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de>
|
||||
<item>Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>
|
||||
<item>John Dyson - <formerly dyson@ref.tfs.com>
|
||||
<item>John Polstra <jdp@polstra.com>
|
||||
<item>John Woods <jfw@eddie.mit.edu>
|
||||
<item>Jordan K. Hubbard <jkh@whisker.hubbard.ie>
|
||||
<item>Julian Elischer <julian@dialix.oz.au>
|
||||
<item>Julian Stacey <jhs@freebsd.org>
|
||||
<item>Karl Lehenbauer <karl@NeoSoft.com>
|
||||
<karl@one.neosoft.com>
|
||||
<item>Keith Bostic <bostic@toe.CS.Berkeley.EDU>
|
||||
<item>Ken Hughes
|
||||
<item>Kent Talarico <kent@shipwreck.tsoft.net>
|
||||
<item>Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu>
|
||||
<kml@mosquito.cis.ufl.edu>
|
||||
<item>Marc Frajola <marc@dev.com>
|
||||
<item>Mark Tinguely <tinguely@plains.nodak.edu>
|
||||
<tinguely@hookie.cs.ndsu.NoDak.edu>
|
||||
<item>Martin Renters <martin@tdc.on.ca>
|
||||
<item>Michael Clay <mclay@weareb.org>
|
||||
<item>Michael Galassi <nerd@percival.rain.com>
|
||||
<item>Mike Durkin <mdurkin@tsoft.sf-bay.org>
|
||||
<item>Naoki Hamada <nao@tom-yam.or.jp>
|
||||
<item>Nate Williams <nate@bsd.coe.montana.edu>
|
||||
<item>Nick Handel <nhandel@NeoSoft.com>
|
||||
<nick@madhouse.neosoft.com>
|
||||
<item>Pace Willisson <pace@blitz.com>
|
||||
<item>Paul Kranenburg <pk@cs.few.eur.nl>
|
||||
<item>Paul Mackerras <paulus@cs.anu.edu.au>
|
||||
<item>Paul Popelka <paulp@uts.amdahl.com>
|
||||
<item>Peter da Silva <peter@NeoSoft.com>
|
||||
<item>Phil Sutherland <philsuth@mycroft.dialix.oz.au>
|
||||
<item>Poul-Henning Kamp<phk@FreeBSD.ORG>
|
||||
<item>Ralf Friedl <friedl@informatik.uni-kl.de>
|
||||
<item>Rick Macklem <root@snowhite.cis.uoguelph.ca>
|
||||
<item>Robert D. Thrush <rd@phoenix.aii.com>
|
||||
<item>Rodney W. Grimes <rgrimes@cdrom.com>
|
||||
<item>Sascha Wildner <swildner@channelz.GUN.de>
|
||||
<item>Scott Burris <scott@pita.cns.ucla.edu>
|
||||
<item>Scott Reynolds <scott@clmqt.marquette.mi.us>
|
||||
<item>Sean Eric Fagan <sef@kithrup.com>
|
||||
<item>Simon J Gerraty <sjg@melb.bull.oz.au>
|
||||
<sjg@zen.void.oz.au>
|
||||
<item>Stephen McKay <syssgm@devetir.qld.gov.au>
|
||||
<item>Terry Lambert <terry@icarus.weber.edu>
|
||||
<item>Terry Lee <terry@uivlsi.csl.uiuc.edu>
|
||||
<item>Tor Egge <Tor.Egge@idi.ntnu.no>
|
||||
<item>Warren Toomey <wkt@csadfa.cs.adfa.oz.au>
|
||||
<item>Wiljo Heinen <wiljo@freeside.ki.open.de>
|
||||
<item>William Jolitz <withheld>
|
||||
<item>Wolfgang Solfrank <ws@tools.de>
|
||||
<item>Wolfgang Stanglmeier <wolf@dentaro.GUN.de>
|
||||
<item>Yuval Yarom <yval@cs.huji.ac.il>
|
||||
</itemize>
|
||||
@ -1,79 +0,0 @@
|
||||
<!-- $Id: crypt.sgml,v 1.6 1997/02/25 04:54:28 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.4 -->
|
||||
|
||||
<sect><heading>DES, MD5, と Crypt<label id="crypt"></heading>
|
||||
|
||||
<p><em>原作: &a.wollman;<newline>24 September 1995.</em>
|
||||
|
||||
<p><em>訳: &a.hanai;<newline>12 September 1996.</em>
|
||||
|
||||
<p>UN*X システムにおいてパスワードを保護し, 簡単に覗かれるのを防
|
||||
ぐために, 従来パスワードはある方法によりスクランブルされてきました.
|
||||
ベル研の Unix 第7版に始まって以来, パスワードはセキュリティの専門家がい
|
||||
うところの「一方向ハッシュ関数」というものを用いることにより暗号化されるようになりました.
|
||||
つまり, 可能な限りのパスワード空間を検索するという強引な
|
||||
方法以外にそのオリジナルを得ることができない, といった方法でパスワードは変換
|
||||
されるのです. 不幸なことに, その当時 AT&T の研究者たちが手に入れることができ
|
||||
た唯一の暗号化方法は DES(Data Encryption Standard) に基づいたものでし
|
||||
た. これは営利企業にとっては大して問題ではありませんが, FreeBSDのよ
|
||||
うにすべてのソースコードが自由に手に入るオペレーティングシステムにとっ
|
||||
ては重大な問題となります. なぜなら, 多くの政府は DES やその他の暗号化ソフ
|
||||
トウェアが国境を越えることに制限をつけようとしているからです.
|
||||
|
||||
<p>ここで, FreeBSD チームは一つのジレンマに直面しました. つまり, どうす
|
||||
れば法に触れることなく国外にあるそれらの UNIX システムのすべてに互換性を持
|
||||
たせることができるか, ということです. 私たちは ``dual track approach'' を
|
||||
取ることに決めました. 規制されていないパスワードスクランブラのみを含む
|
||||
配布用物件を作り, DES に基づいたパスワードハッシュを付加ライブラリ
|
||||
として分けて供給するのです. パスワードをスクランブルさせる関数は, C ライブラリから
|
||||
`<tt>libcrypt</tt>' と呼ばれる(それを実行する C 関数が `<tt>crypt</tt>' と
|
||||
いう名前だからです)別のライブラリへ移されました. FreeBSD 1.x 及び
|
||||
2.0 のリリース前のスナップショットでは, その規制されていないスクランブラは
|
||||
Nate Williams によって書かれた安全でない関数を使っていますが, 次の
|
||||
リリースでは RSA Data Security 社の一方向ハッシュ関数の MD5 を使う方法
|
||||
に置き換えられました. これらの関数はどれも暗号化を含んでいないため,
|
||||
合衆国から持ち出し, 他の多くの国へ持ち込めるものであるとされています.
|
||||
|
||||
<p>一方, DES に基づいたパスワードハッシュ関数に関する作業もまた進行中
|
||||
でした, まず, 合衆国及び他の国で書かれたコードの同期をとりながら,
|
||||
合衆国の外で書かれた `<tt>crypt</tt>' のあるバージョンが持ち込まれました.
|
||||
そしてライブラリは修正され, 二つにわけられました. すなわち
|
||||
DES `<tt>libcrypt</tt>' は一方向パスワードハッシュをおこなうのに必要なコード
|
||||
のみを含み, それとは別の `<tt>libcipher</tt>' は実際に暗号化をおこなう
|
||||
ためのエントリポイントとして生成されました. コンパイルされたライブラリに対
|
||||
して国外に持ち出す許可を得るのを簡単にするために, コードはこのように分け
|
||||
られたのです.
|
||||
|
||||
<sect1><heading>`<tt>crypt</tt>' メカニズムを理解する</heading>
|
||||
|
||||
<p>あるパスワード文字列を作るのに, DES に基づいたハッシュ関数を使っ
|
||||
たのか, MD5に基づいたハッシュ関数を使ったのかは非常に簡単にわかります.
|
||||
MD5 を使ったパスワード文字列は必ず `<tt>$1$</tt>' という文字
|
||||
で始まります. DESを使ったパスワード文字列はどんな特定の文字も持っていま
|
||||
せんが, MD5を使ったパスワードよりも短く, `<tt>$</tt>' という文字
|
||||
を持たない64文字のアルファベットで構成されています. したがって, ドル記号で
|
||||
始まっていない比較的短い文字列は DES を使ったパスワードである可能性が非常
|
||||
に高いです.
|
||||
|
||||
<p>あなたのシステムで, どちらのライブラリが使われているかを決めるの
|
||||
は, スタティックにリンクされている `<tt>init</tt>' のようなもの(その
|
||||
ようなプログラムに対する唯一の方法はわかっているパスワードを試してみ
|
||||
て動くかどうかを確認することです.)を除いたほとんどのプログラムについ
|
||||
ては非常に簡単なことです. `<tt>crypt</tt>' を使うようなプログラムは
|
||||
`<tt>libcrypt</tt>' にリンクされています. そしてそれぞれのライブラリに
|
||||
対する `<tt>libcrypt</tt>' は適切な実装へのシンボリックリンクとなってい
|
||||
ます. 例えば, DES 版を使っているようなシステムにおいては次のようになって
|
||||
います:
|
||||
|
||||
<tscreen><verb>
|
||||
$ cd /usr/lib
|
||||
$ ls -l /usr/lib/libcrypt*
|
||||
lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a
|
||||
lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0
|
||||
lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.a
|
||||
</verb></tscreen>
|
||||
|
||||
MD5 に基づいたライブラリを使っているシステムにおいては, 同じようなリンクが
|
||||
見られるでしょうが, そのターゲットは `<tt>libdescrypt</tt>' ではなく
|
||||
`<tt>libscrypt</tt>' になっているでしょう.
|
||||
@ -1,217 +0,0 @@
|
||||
<!-- $Id: ctm.sgml,v 1.7 1997/04/25 07:24:02 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.17 -->
|
||||
<!--
|
||||
# This is the sgml version of the ctm.FAQ file.
|
||||
#
|
||||
# Converted by Ollivier Robert <roberto@FreeBSD.ORG>
|
||||
#
|
||||
#
|
||||
# ----------------------------------------------------------------------------
|
||||
# "THE BEER-WARE LICENSE" (Revision 42):
|
||||
# <phk@login.dknet.dk> wrote this file. As long as you retain this notice you
|
||||
# can do whatever you want with this stuff. If we meet some day, and you think
|
||||
# this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp
|
||||
# ----------------------------------------------------------------------------
|
||||
#
|
||||
-->
|
||||
|
||||
<sect1><heading>CTM<label id="ctm"></heading>
|
||||
|
||||
<p><em>原作: &a.phk;. 更新: 16-Mar-1995.</em>
|
||||
|
||||
<p><em>訳: &a.hanai;<newline>5 November 1996.</em>
|
||||
|
||||
<tt/CTM/ はリモートのディレクトリツリーを中央のツリーに同期させるための
|
||||
手段です. これはFreeBSDのソースツリーの配布を行なうために開発されまし
|
||||
たが, 時が経つにつれて別の目的にも有用であることがわかるかも
|
||||
しれません. デルタを作り出す処理に関するドキュメントは現在ほとんど
|
||||
ありません。従って, もしあなたが<tt/CTM/ を他のことに使いたいなら
|
||||
&a.phk;にさらなる情報を問い合わせてください.
|
||||
|
||||
<sect2><heading>なぜ<tt/CTM/を使うの?</heading>
|
||||
<p><tt/CTM/ を使うことにより``FreeBSD-current''のローカルコピーを得ることが
|
||||
できます. もしあなたがFreeBSDのアクティブな開発者であるにもかかわらず
|
||||
お粗末なTCP/IP接続しか持っていなかったり, またはTCP/IP接続が
|
||||
行なえないとしたら, <tt/CTM/はそんなあなたのために作られたのです.
|
||||
あなたは一日あたり四つまでのデルタを転送する必要があるでしょう
|
||||
(またはそれを自動的にメールで受けとることができます).
|
||||
デルタのサイズは常にできるだけ小さく保たれています.
|
||||
大抵の場合5KBよりも小さく,
|
||||
たまに(10回に1回程度)10-50KBになり, ときおり100KBかもっと大きくなる
|
||||
でしょう.
|
||||
|
||||
``current''のソースを追いかけるのに,
|
||||
様々な注意に気を付けておく必要もあるでしょう. そのためには
|
||||
<ref id="current" name="最新のカレントを追いかける">を読むことを
|
||||
お勧めします.
|
||||
|
||||
<sect2><heading><tt/CTM/を使うには何が必要?</heading>
|
||||
|
||||
<p>二つのものが必要でしょう: ``<tt/CTM/'' プログラムとそれに与える
|
||||
(``current''レベルを得るための)最初のデルタです.
|
||||
|
||||
<tt/CTM/ プログラムはバージョン2.0のリリース以来FreeBSDの一部にな
|
||||
りました. もしソースのコピーを持っているなら
|
||||
<tt>/usr/src/usr.sbin/<tt/CTM/</tt>にあります.
|
||||
|
||||
もしFreeBSDの2.0以前のバージョンなら, 最新の<tt/CTM/のソースを直接
|
||||
|
||||
<url
|
||||
url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm">
|
||||
|
||||
から入手できます.
|
||||
<tt/CTM/に与える「デルタ」は二つの方法, FTPまたはe-mail, で得ること
|
||||
ができます.
|
||||
もしインターネットにFTPアクセスできるなら, 次のFTPサイト:
|
||||
|
||||
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/CTM">
|
||||
|
||||
または、その<ref id="mirrors-ctm" name="ミラーサイト">が<tt/CTM/
|
||||
へのアクセスをサポートします.
|
||||
適切なディレクトリにFTPして<tt/README/ファイルを入手し, そこから
|
||||
スタートしてください.
|
||||
|
||||
もし電子メールにしかアクセスできない もしくはFTPの使用が制限され
|
||||
ているなら, e-mailでデルタを入手したいと思うかもしれません.
|
||||
|
||||
メーリングリスト``ctm-src-cur''に参加するために&a.majordomo
|
||||
へメールを送ってください. (もしmajordomoを使って参加する方法を知らない
|
||||
のであれば, 最初に``help''という語を含むメッセージを送ってください.
|
||||
- 使い方の説明が送られてくるでしょう.)
|
||||
|
||||
メールで<tt/CTM/による更新ファイルを受け取り始めると, 中身を取り出して使用
|
||||
するために<tt/ctm_rmail/プログラムを使うかもしれません. それを完全
|
||||
に自動で行ないたいなら, <tt>/etc/aliases</tt>から<tt/ctm_rmail/プロ
|
||||
グラムを直接使うこともできます.
|
||||
さらに詳しいことは<tt/ctm_rmail/ manページを御覧ください.
|
||||
|
||||
<bf/注/: <tt/CTM/デルタを得るためにどの方法を使うのであっても,
|
||||
<tt/ctm-announce@FreeBSD.ORG/メーリングリストに参加するべきです.
|
||||
このメーリングリストは将来的には<tt/CTM/システムの操作に関する
|
||||
アナウンスがポストされる唯一の場になるでしょう.
|
||||
メーリングリストに加わるためには``<tt/subscribe ctm-announce/''
|
||||
と書いた一行だけのメールを &a.majordomo へ送ってください.
|
||||
|
||||
<sect2><heading>はじめて<tt/CTM/を使い始める</heading>
|
||||
<p><tt/CTM/ デルタを使い始めるためには, 特別な「ベース」デルタを
|
||||
入手する必要があるでしょう. これは以降作られる全てのデルタの
|
||||
出発点となるものです.
|
||||
|
||||
ベースデルタは数字に付け加えられた``<tt/A/''によって認識することが
|
||||
出来ます(例えば, <tt/src-cur.0341A.gz/).
|
||||
規則としてベースデルタは100デルタ毎に作られるので, 次のベースデルタ
|
||||
は<tt/src-cur.0400A.gz/となるでしょう. ところで, ベースデルタは
|
||||
とても大きいです! 25MBから30 MB の<tt/gzip/されたデータ, というのが
|
||||
ベースデルタとしては普通です.
|
||||
|
||||
もし2.0-RELEASEの<tt/srcdist/を持っているのなら, 代わりに
|
||||
<tt/src-cur.0372R20.gz/ファイルを見つけることができるでしょう. これは
|
||||
たったの4MBしかなく, これにより2.0-RELEASEのソースからcurrentを
|
||||
得ることができます.
|
||||
|
||||
一度スタートするためのベースデルタを得ると, それに続く多数の
|
||||
全てのデルタも必要になるでしょう.
|
||||
|
||||
<sect2><heading><tt/CTM/を日常で使う</heading>
|
||||
<p>デルタを適用するためには, 単に
|
||||
<verb>
|
||||
cd /where/ever/you/want/the/stuff??
|
||||
ctm -v -v /where/you/store/your/deltas/src-cur.*??
|
||||
</verb>
|
||||
とします.
|
||||
<tt/CTM/ はどれが<tt/gzip/されているか理解します. 従って最初に
|
||||
gunzipしておく必要はありません. ディスクの節約にもなります.
|
||||
|
||||
全体の処理に関して確信するまでは<tt/CTM/は(ソース)ツリーに対して
|
||||
何もしません.
|
||||
また, デルタを確かめるためには``<tt/-c/''フラグを使うことができます.
|
||||
このフラグがあると<tt/CTM/はツリーに対して実際には何も行ないません.
|
||||
単にデルタの完全性を確認し, 現在のツリーに問題なく使用できるかを確認
|
||||
するだけです.
|
||||
|
||||
<tt/CTM/には他にもオプションがあります. 詳細に関してはソースを
|
||||
見てください.
|
||||
|
||||
もし誰かが「ユーザ インターフェース」の部分に関して助けてくれるなら
|
||||
私はとても嬉しいです. なぜならどういうオプションが何を, どのよう
|
||||
に, いつ行なうようにするべきか決めかねているからです.
|
||||
|
||||
以上でやることは本当に全部です. 新しいデルタを入手した時には,
|
||||
ソースを最新のものにするためにそれを<tt/CTM/に通すだけです.
|
||||
|
||||
もしデルタを再ダウンロードするのが骨の折れる作業であれば, デルタを
|
||||
消さないでおいてください.
|
||||
なにかおかしなことが起こった場合には置いておけば良かった
|
||||
と思うかもしれません. もしフロッピーディスクしか持っていない状況
|
||||
であってもコピーを取るのに<tt/fdwrite/を使うことを考えてください.
|
||||
|
||||
|
||||
<sect2><heading><tt/CTM/の将来計画</heading>
|
||||
<p>
|
||||
重要なもの
|
||||
<itemize>
|
||||
<item>
|
||||
ソースツリーへのローカルな修正を可能にすること. これを実現
|
||||
する一つの方法は次のようなものでしょう:
|
||||
<p> <tt/CTM/が``<tt>foo/bar.c</tt>''というファイルを変更しようと
|
||||
する時, 最初に<tt>foo/bar.c#CTM</tt>というファイルがあるか
|
||||
どうかチェックします. もしこのファイルがあれば, それに
|
||||
デルタを適用します. このようにして<tt>foo/bar.c</tt>
|
||||
ファイルをローカルな要求に合うように変更しておくことができます.
|
||||
<item>
|
||||
「ファイル復活」のオプションを<tt/CTM/に付ける. これは
|
||||
次のようなものです.
|
||||
<verb>
|
||||
ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.*
|
||||
</verb>
|
||||
これは src-cur ファイルから<tt/wd.c/を復旧して現在の状態に戻します.
|
||||
<item>
|
||||
<tt/CTM/へのオプションを整理する. さもないと混乱し, 直観に反したもの
|
||||
になります.
|
||||
</itemize>
|
||||
|
||||
残念なことに私は非常に忙しいです. 従ってこれを行なうどんな手助け
|
||||
でも歓迎します. その際, 自分が何をやりたいかを私に
|
||||
言うのを忘れずに.
|
||||
|
||||
<sect2><heading>その他</heading>
|
||||
<p>
|
||||
「DESに染まった」(例えば, 国外への持ち出しが規制された)ソースは
|
||||
まったく含まれません. 手に入るのは「国際」バージョンだけです.
|
||||
もし興味のある人が多いようであれば, 我々は``<tt/sec-cur/''シーケンスも
|
||||
セットアップするつもりです.
|
||||
|
||||
もしあなたがFreeBSDに対して頻繁なまたは価値のある貢献をしている
|
||||
のであれば, 私は特別なサービス, 一つには<tt/ftp/か<tt/rcp/によるあなた
|
||||
の近くのマシンへの配布, をしたいと思うでしょう.
|
||||
これには時間がかかるので, あなたがこれを受けるに値する必要があります.
|
||||
しかし, あなたにその価値があるなら, 私は喜んでそうするでしょう.
|
||||
|
||||
<tt/ports/コレクションに対するデルタのシーケンスもあります. しかし,
|
||||
まだあまり興味は持たれていないようです. もしこれに対するメーリング
|
||||
リストが欲しい時も私に言ってください. 我々はセットアップすることを
|
||||
考えます.
|
||||
|
||||
もしあなたがコミット特権を持っているか, または同様にFreeBSDコアチーム
|
||||
からその必要ありと認められていれば, CVSリポジトリツリーへの
|
||||
アクセスも同じ手段で得ることができます. 詳細は&a.phk;へ聞いてください.
|
||||
|
||||
|
||||
<sect2><heading>ありがとう!</heading>
|
||||
<p>
|
||||
<descrip>
|
||||
<tag/&a.bde;/
|
||||
辛辣なペンと価値のないコメントに対して.
|
||||
<tag/&a.sos;/
|
||||
よく辛抱してくれました.
|
||||
<tag/Stephen McKay/
|
||||
<tt/ctm_[rs]mail/を書いてくれました. とても感謝して
|
||||
います.
|
||||
<tag/&a.jkh/
|
||||
彼が頑固として譲らなかったため, 私もこの <tt/CTM/ をもっと良いものに
|
||||
しないわけにはいきませんでした. 彼の頑固さに感謝します.
|
||||
<tag/ユーザの人みんな/
|
||||
気に入ってくれることを願っています...
|
||||
</descrip>
|
||||
|
||||
@ -1,161 +0,0 @@
|
||||
<!-- $Id: current.sgml,v 1.6 1997/02/25 04:54:41 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.21 -->
|
||||
|
||||
<sect><heading>最新のFreeBSDを追いかける<label id="current"></heading>
|
||||
|
||||
<p><em>原作: &a.jkh;.</em>
|
||||
|
||||
<p><em>訳: &a.hanai;<newline>6 November 1996.</em>
|
||||
|
||||
<!--
|
||||
|
||||
THE FREEBSD CURRENT POLICY
|
||||
|
||||
Last updated: $Date: 1997/02/25 04:54:41 $
|
||||
|
||||
This document attempts to explain the rationale behind
|
||||
FreeBSD-current, what you should expect should you decide to run it,
|
||||
and states some prerequisites for making sure the process goes as
|
||||
smoothly as possible.
|
||||
-->
|
||||
|
||||
<sect1><heading>FreeBSD-currentってなに?</heading>
|
||||
|
||||
<p>FreeBSD-currentとは，文字通りに，日々変更されているFreeBSDのソース
|
||||
のスナップショット以外の何ものでもありません．中には現在開発途上の
|
||||
ソフトウェア, 実験的な変更、あるいは過渡的な機能などが含まれています.
|
||||
また, この中に入っている機能がすべて次の公式リリースに入るとはかぎりません.
|
||||
FreeBSD-currentをソースからほとんど毎日コンパイルしている人はたくさん
|
||||
いますが, 時期によってはFreeBSD-currentはコンパイルさえできない状態に
|
||||
なっていることもあります. これらの問題は一般的には可能な限り素早く解決
|
||||
されますが, FreeBSD-currentのソースが不幸をもたらすか, それとも非常に
|
||||
素晴らしい機能をもたらすかというのは文字通り, ある与えられた24時間の間
|
||||
のどの部分であなたがソースを手に入れたか, による場合もあります.
|
||||
|
||||
必要があるときには, 時折 FreeBSD-current の一部をバイナリとして提供する
|
||||
こともありますが, それはただ何かをテストしてほしいためであって,
|
||||
我々が current をバイナリリリースとして提供することにしたわけではありません.
|
||||
我々が提供していないならば, 要求しないで下さい!
|
||||
これは普段から行なうにはあまりにも時間がかかり過ぎるのです．
|
||||
|
||||
<sect1><heading>誰がFreeBSD-currentを必要としてるの?</heading>
|
||||
|
||||
<p>FreeBSD-currentは次の3つのどれかにあてはまる人のために一般に公開してい
|
||||
ます.
|
||||
<enum>
|
||||
<item> ソースツリーの，ある部分または別の部分に関して活発に作業して
|
||||
いるFreeBSDグループのメンバ．彼らにとっては`最新のもの'に維持して
|
||||
おくことは絶対的な要求なのです．
|
||||
|
||||
<item> FreeBSD-currentが出来るだけ健全である時間の割合を増やすために
|
||||
様々な問題と戦うのに時間を費やすのを厭わず活発にテストを行なっている
|
||||
FreeBSDグループのメンバ．彼らはまた様々な変更に関する提案やFreeBSD
|
||||
の大まかな方向付けを行ないたいと思っている人々でもあります．
|
||||
|
||||
<item> 単に，様々な事に目を向け，参考のために(例えば，動かすためではなく
|
||||
<em>読むため</em>に)最新のソースを使いたいと思っているFreeBSD(または
|
||||
他の)グループのまわりにいるメンバ．これらの人々はまた時によってコメ
|
||||
ントをしたりコードを寄稿したりします．
|
||||
</enum>
|
||||
|
||||
<sect1><heading>FreeBSD-currentに期待しては<em>いけない</em>ことは?</heading>
|
||||
|
||||
<p><enum>
|
||||
<item> あなたが何か新しいカッコイイモノがあると聞き, あなたの
|
||||
周りで最初にそれを持ちたいためにリリース前のコードの断片を
|
||||
追いかけること.
|
||||
|
||||
<item> バグを修正するための素早い方法.
|
||||
|
||||
<item> いずれにしても我々によって``公式にサポートされている''.
|
||||
|
||||
私たちは3つの「公式な」FreeBSD-currentのグループの一つに実際に属する
|
||||
人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには
|
||||
単に「時間が足りない」のです.
|
||||
これは我々が外の人を助けるのが好きではないケチで意地悪い人間だと
|
||||
いうことではなく(もしそうなら FreeBSD なんかやっていません), 文字通り
|
||||
我々は一日に400ものメッセージに答え<em>かつ</em> FreeBSD の作業をする
|
||||
ことなど出来ない! ということなのです. もし, たくさんの質問に答えるか
|
||||
それとも FreeBSD を良くする作業を続けるかという選択が与えられた場合,
|
||||
あなた方のほとんどは後者を支持する, と私は確信しています.
|
||||
</enum>
|
||||
|
||||
<sect1><heading>FreeBSD-currentを使う</heading>
|
||||
|
||||
<p><enum> <item> &a.current;と&a.cvsall;に加わって下さい.
|
||||
これは単に良い考えであるというだけでなく, <em>必須の</em>ことなのです.
|
||||
もし<em>FreeBSD-current</em>メーリングリストに入っていなければ,
|
||||
様々な人がシステムの現在の状態について述べているコメントを決して見ることは
|
||||
ありませんし, 従って他の人が既に見つけて解決している多くの問題に戸惑っ
|
||||
てあきらめてしまうでしょう. さらに言うと, 非常に不可欠な情報
|
||||
(例えば, 「やぁ, みんな! <tt>/usr/src</tt>を作り直す前にカーネルの
|
||||
再構築を<em>やらないといけないよ</em>, さもないととんでもないクラッシュが起きるぜ!」)を見逃してしまうでしょう.
|
||||
|
||||
<em>cvs-all</em>メーリングリストはそれぞれの変更についてそれに関して起
|
||||
こり得る情報を見ることが出来ます.
|
||||
|
||||
これらのメーリングリストに入るには, &a.majordomo;へ
|
||||
<verb>
|
||||
subscribe freebsd-current
|
||||
subscribe cvs-all
|
||||
</verb>
|
||||
と書いたメールを送って下さい.
|
||||
オプションとして本文に`help'と書けば Majordomo はあなたへ我々がサポ
|
||||
ートする様々なメーリングリストに参加/脱退する方法に関する詳しい
|
||||
ヘルプを送ります.
|
||||
|
||||
<item> ftp.FreeBSD.ORGからのソースの入手. 以下の3つの方法で行なうこと
|
||||
が出来ます.
|
||||
|
||||
<enum>
|
||||
<item> 下に述べられている<ref id="ctm" name="CTM">を用いる.
|
||||
均一なレートの, 良質の TCP/IP 接続を持っていない人には,
|
||||
これが一番いい方法でしょう.
|
||||
|
||||
<item> <ref id="cvsup" name="cvsup"> を
|
||||
<url url="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/standard-supfile" name="この supfile">
|
||||
を用いて使用する.
|
||||
これは2番目に推薦される方法です. なぜなら, cvssupによって一度全体
|
||||
を入手し, 後は変更されたところだけを入手することが出来るからです.
|
||||
たくさんの人がvsupをcronから起動し, 自動的にソースを最新のもの
|
||||
に保っています.
|
||||
|
||||
<item> ftpを使う. FreeBSD-currentのソースツリーは常に
|
||||
<htmlurl url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current"
|
||||
name="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current">
|
||||
に公開されています.
|
||||
我々はまた全体をcompress/tarして入手できる `wu-ftpd' を使ってい
|
||||
ます. 例えば,
|
||||
<verb>
|
||||
usr.bin/lex
|
||||
</verb>
|
||||
があったとすると,
|
||||
<verb>
|
||||
ftp> cd usr.bin
|
||||
ftp> get lex.tar.Z
|
||||
</verb>
|
||||
とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体)
|
||||
をcompressされたtarファイルとして入手することができます.
|
||||
</enum>
|
||||
|
||||
<item> 以上のことをまとめると, 必要に応じて迅速なアクセスをする必要があり,
|
||||
接続のバンド幅が問題ではなければcvsupかftpを使いましょう. そうではなければ
|
||||
CTMを使いましょう.
|
||||
|
||||
<item> もしソースを, 眺めるだけでなく走らせるために入手しているので
|
||||
あれば, 一部だけ選ぶのではなく,
|
||||
current の<em>全体</em>を手に入れてください.
|
||||
なぜなら, ソースの様々な部分が他の部分の更新に依存しており, 一部のみを
|
||||
コンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです.
|
||||
|
||||
<item> current をコンパイルする前に /usr/src にある Makefile
|
||||
をよく読んでください. アップグレードの処理の一部として,
|
||||
少なくとも一回は最初に `make world' を行なうべきでしょう.
|
||||
&a.current;を読めば, 次のリリースへ向けて, 時々必要になる
|
||||
他のブートストラップの方法に関して常に最新情報を得ることが出来ます.
|
||||
|
||||
<item> アクティブになって下さい! もしFreeBSD-currentを走らせているなら
|
||||
我々はそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲して
|
||||
います. コードを伴う提案はもっとも歓迎されるものです!
|
||||
</enum>
|
||||
@ -1,576 +0,0 @@
|
||||
<!-- $Id: cvsup.sgml,v 1.18 1997/05/20 01:53:11 max Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.19 -->
|
||||
|
||||
<sect1><heading>CVSup<label id="cvsup"></heading>
|
||||
|
||||
<p><em>原作: &a.jdp;</em>.
|
||||
<p><em>訳: &a.iwasaki;.<newline>27 February 1997.</em>
|
||||
|
||||
<sect2><heading>CVSup の紹介<label id="cvsup:intro"></heading>
|
||||
|
||||
<p>CVSup は, リモートのサーバホストにあるマスタ CVS リポジトリから
|
||||
ソースツリーを配布し更新するためのソフトウェアパッケージです. FreeBSD
|
||||
のソースは, カリフォルニアにある中心的な開発マシンの CVS リポジトリの
|
||||
中でメンテナンスしています. CVSup を使用することで, FreeBSD ユーザは
|
||||
簡単に自分のソースツリーを最新の状態にしておくことができます.
|
||||
|
||||
<p>CVSup は "pull" モデルとよばれる更新のモデルを採用しています.
|
||||
pull モデルでは, 各クライアントが更新したい場合に更新したい時点で,
|
||||
サーバに更新の問い合わせをおこないます. サーバはクライアントからの
|
||||
更新の要求を受け身の状態で待ちます. したがって, すべての更新は
|
||||
クライアント主導でおこなわれます. サーバは頼まれもしない更新情報を
|
||||
送るようなことはしません. ユーザは CVSup クライアントを手動で実行して
|
||||
更新をおこなうか, cron ジョブを設定して定期的に自動実行する必要があります.
|
||||
|
||||
<p>用語 "CVSup" のように大文字で表記しているものは, ソフトウェアパッケージ
|
||||
全体を指します. 主な構成物は, 各ユーザマシンで実行するクライアントである
|
||||
"cvsup", FreeBSD の各ミラーサイトで実行するサーバ "cvsupd" です.
|
||||
|
||||
<p>FreeBSD の文書やメーリングリストを読んだ際に, sup についての言及を
|
||||
見かけたかもしれません. sup は CVSup の前に存在していたもので, 同様の
|
||||
目的で使われていました. CVSup は sup と同じように使用されており, 実際,
|
||||
sup と互換性のあるコンフィグレーションファイルを使用します. しかし,
|
||||
CVSup の方がより高速で柔軟性もあるので, もはや sup は FreeBSD
|
||||
プロジェクトでは使用されていません.
|
||||
|
||||
<sect2><heading>CVSup のインストール<label id="cvsup:install"></heading>
|
||||
|
||||
<p>FreeBSD 2.2 以降を使用している場合, CVSup をインストールするもっとも
|
||||
簡単な方法は, FreeBSD <ref id="ports" name="ports コレクション"> の
|
||||
<url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup.tar.gz"
|
||||
name="port"> または対応する <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/net/cvsup-14.1.1.tgz"
|
||||
name="バイナリ package"> を使うことです. どちらを使うかは,
|
||||
CVSupを自分で作りたいかどうかによります.
|
||||
|
||||
<p>FreeBSD-2.1.6 または 2.1.7 を使用している場合は, 残念ながら
|
||||
FreeBSD-2.1.{6,7} には存在しないバージョンの C ライブラリが必要となるため
|
||||
バイナリ package は使用できません.
|
||||
しかし, <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup.tar.gz"
|
||||
name="port"> は FreeBSD 2.2 とまったく同じように簡単に使うことができます.
|
||||
単に tar ファイルを展開し, cvsup ディレクトリへ cd して "make install"
|
||||
とタイプするだけです.
|
||||
|
||||
<p>CVSup は <url
|
||||
url="http://www.research.digital.com/SRC/modula-3/html/home.html"
|
||||
name="Modula-3"> で書かれているため, package と port 両方とも Modula-3
|
||||
ランタイムライブラリがインストールされていることが必要です. これらは
|
||||
port の <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/lang/modula-3-lib.tar.gz"
|
||||
name="lang/modula-3-lib"> および package の <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/lang/modula-3-lib-3.6.tgz"
|
||||
name="lang/modula-3-lib-3.6"> にあります. これらのライブラリの port
|
||||
や package に対して cvsup と同じ管理方法を取っていれば, CVSup の
|
||||
port や package をインストールする際に, これらのライブラリも自動的に
|
||||
コンパイルそして/またはインストールされます.
|
||||
|
||||
<p>Modula-3 ライブラリはかなり大きく, これらの転送やコンパイルはすぐに
|
||||
終わるものではありません. この理由から, 三つめの選択肢が提供されています.
|
||||
以下のアメリカ合衆国にある配布サイトのどちらからでも, FreeBSD 用の
|
||||
<em>スタティックリンクされた</em> CVSup 実行形式が入手可能です:
|
||||
|
||||
<itemize>
|
||||
<item><url url="ftp://hub.freebsd.org/pub/CVSup/cvsup-bin-14.1.1.tar.gz"
|
||||
name="ftp://hub.freebsd.org/pub/CVSup/cvsup-bin-14.1.1.tar.gz">
|
||||
(クライアント).
|
||||
<item><url url="ftp://hub.freebsd.org/pub/CVSup/cvsupd-bin-14.1.1.tar.gz"
|
||||
name="ftp://hub.freebsd.org/pub/CVSup/cvsupd-bin-14.1.1.tar.gz">
|
||||
(サーバ).
|
||||
</itemize>
|
||||
|
||||
また, ドイツのミラーサイトは以下の通りです:
|
||||
|
||||
<itemize>
|
||||
<item><url url="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup-bin-14.1.1.tar.gz"
|
||||
name="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup-bin-14.1.1.tar.gz">
|
||||
(クライアント).
|
||||
<item><url url="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsupd-bin-14.1.1.tar.gz"
|
||||
name="ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsupd-bin-14.1.1.tar.gz">
|
||||
(サーバ).
|
||||
</itemize>
|
||||
|
||||
訳注: 日本国内のミラーサイトは以下の通りです:
|
||||
|
||||
<itemize>
|
||||
<item><url url="ftp://jaz.jp.freebsd.org/pub/FreeBSD-freefall/CVSup/cvsup-bin-14.1.1.tar.gz"
|
||||
name="ftp://jaz.jp.freebsd.org/pub/FreeBSD-freefall/CVSup/cvsup-bin-14.1.1.tar.gz">
|
||||
(クライアント).
|
||||
<item><url url="ftp://jaz.jp.freebsd.org/pub/FreeBSD-freefall/CVSup/cvsupd-bin-14.1.1.tar.gz"
|
||||
name="ftp://jaz.jp.freebsd.org/pub/FreeBSD-freefall/CVSup/cvsupd-bin-14.1.1.tar.gz">
|
||||
(サーバ).
|
||||
</itemize>
|
||||
|
||||
<p>ほとんどのユーザはクライアントのみが必要になるでしょう. これらの
|
||||
実行形式は完全に自己完結しており, FreeBSD-2.1.0 から FreeBSD-current
|
||||
までの, どのバージョンでも動作します.
|
||||
|
||||
<p>まとめると, CVSup をインストールするための選択肢は以下の通りです:
|
||||
|
||||
<itemize>
|
||||
<item>FreeBSD-2.2以降: スタティックバイナリ, port, package
|
||||
<item>FreeBSD-2.1.6, 2.1.7: スタティックバイナリ, port
|
||||
<item>FreeBSD-2.1.5 以前: スタティックバイナリ
|
||||
</itemize>
|
||||
|
||||
<sect2><heading>CVSup のコンフィグレーション<label id="cvsup:config"></heading>
|
||||
|
||||
<p>CVSup の動作は, "supfile" と呼ばれるコンフィグレーションファイルで
|
||||
制御します. FreeBSD-2.2 からは, supfile のサンプルがディレクトリ <url
|
||||
url="file:/usr/share/examples/cvsup" name="/usr/share/examples/cvsup">
|
||||
の下にあります. 2.2 以前のシステムを使用している場合は, これらの
|
||||
サンプルを <url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/"
|
||||
name="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/">
|
||||
から入手することができます.
|
||||
|
||||
<p>supfile には以下の cvsup に関する質問への答えを記述します:
|
||||
|
||||
<itemize>
|
||||
<item><ref id="cvsup:config:files" name="どのファイルを受け取りたいのか?">
|
||||
<item><ref id="cvsup:config:vers" name="どのバージョンのものが欲しいのか?">
|
||||
<item><ref id="cvsup:config:where" name="どこから入手したいのか?">
|
||||
<item><ref id="cvsup:config:dest" name="自分のマシンのどこに置きたいのか?">
|
||||
<item><ref id="cvsup:config:status" name="どこに status ファイルを置きたいのか?">
|
||||
</itemize>
|
||||
|
||||
<p>次のセクションで, これらの質問に順番に答えながら典型的な supfile
|
||||
を組み立てていきます. 最初に supfile の全体構造を説明します.
|
||||
|
||||
<p>supfile はテキストファイルです. コメントは "#" から行末までです.
|
||||
空行とコメントだけの行は無視します.
|
||||
|
||||
<p>残りの各行には, ユーザが受け取りたいファイル群について記述します.
|
||||
行の始めは, サーバ側で定義した論理的なファイルのグループである
|
||||
「コレクション」の名称です. コレクションの名称を指定して, 欲しいファイル群を
|
||||
サーバに伝えます. コレクション名の後には, ホワイトスペースで区切られた
|
||||
0個以上のフィールドが続きます. これらのフィールドが上記の質問に対する
|
||||
答えになります. フィールドには 2種類あります: flag フィールドと value
|
||||
フィールドです. flag フィールドは "delete" や "compress" のような
|
||||
単独のキーワードから成ります. また, value フィールドもキーワードで
|
||||
始まりますが, キーワードの後にはホワイトスペースは入らず, "=" と
|
||||
二つめの単語が続きます. 例えば, "release=cvs" は value フィールドです.
|
||||
|
||||
<p>通常, supfile には受け取りたいコレクションを一つ以上指定します.
|
||||
supfile を組み立てる一つの方法として, コレクション毎にすべての関係の
|
||||
あるフィールドを明示的に指定する方法があります. しかし, これでは supfile
|
||||
のすべてのコレクションに対してほとんどのフィールドが同じになるため,
|
||||
行が非常に長くなってしまい不便になります. これらの問題を避けるため,
|
||||
CVSup ではデフォルトを指定することのできるメカニズムが提供されています.
|
||||
特殊な擬似コレクション名 "*default" で始まる行は, supfile 中の後続の
|
||||
コレクションに対して使用する flag フィールドと value フィールドの
|
||||
デフォルトを設定するために利用できます. 個々のコレクションで固有の値を
|
||||
指定すると, デフォルト値を無効にできます. また "*default" 行を追加すると,
|
||||
supfile の途中からデフォルト値の変更や追加が可能になります.
|
||||
|
||||
<p>これまでの予備知識を基に, <ref id="current" name="FreeBSD-current">
|
||||
のメインのソースツリーを受け取って更新するための supfile を
|
||||
組み立ててみましょう.
|
||||
|
||||
<itemize>
|
||||
<item>どのファイルを受け取りたいのか?<label id="cvsup:config:files">
|
||||
|
||||
<p>sup の場合と同様に, CVSup を通して入手できるファイルは
|
||||
「コレクション」と呼ばれる名前の付けられたグループにまとめられています.
|
||||
利用可能なコレクションについては<ref id="cvsup:collec" name="ここ">
|
||||
で説明しています. ここでは, FreeBSD システムのメインのソースツリー全体
|
||||
を受け取るための設定例を紹介します.
|
||||
輸出規制されている暗号化サポートのコード以外のすべてを含む "src-all" という
|
||||
単一の大きなコレクションがあります. この例では私たちがアメリカ合衆国か
|
||||
カナダにいるものと仮定します. その場合, "cvs-crypto" という一つの付化的な
|
||||
コレクションで暗号化コードを入手することができます. supfile
|
||||
を組み立てる最初のステップとして, これらのコレクションを一行に一つづつ
|
||||
記述します:
|
||||
|
||||
<verb>
|
||||
src-all
|
||||
cvs-crypto
|
||||
</verb>
|
||||
|
||||
<p><item>どのバージョンのものが欲しいのか?<label id="cvsup:config:vers">
|
||||
|
||||
<p>CVSup を使用すると, かつて存在していたことのある, 事実上どのバージョンの
|
||||
ソースでも受け取ることができます. これは cvsupd サーバがすべてのバージョンを含む
|
||||
CVS リポジトリに基づいて動作することにより, 実現されています.
|
||||
"tag=" および "date=" の value フィールドを使用して, 欲しいバージョンの
|
||||
一つを指定します.
|
||||
|
||||
<p>"tag=" フィールドはリポジトリ中のシンボリックタグを指定します.
|
||||
tag には revision tag と branch tag の二種類があります. revision tag
|
||||
は特定のリビジョンを指します. これは, 毎日同じ状態に保つことになります.
|
||||
一方 branch tag は, ある時点での開発分流の最新のリビジョンを指します.
|
||||
branch tag は特定のリビジョンを指定している訳ではないので, 今日と明日では
|
||||
異なるリビジョンを参照することになるかもしれません.
|
||||
|
||||
<p>以下はユーザが興味を持っていると思われる branch tag です:
|
||||
|
||||
<descrip>
|
||||
<tag/tag=./
|
||||
メインの開発分流であり, FreeBSD-current として知られています.
|
||||
注意: "." は句読点ではありません. tag の名称です.
|
||||
<tag/tag=RELENG_2_2/
|
||||
FreeBSD-2.2 の先頭の開発分流です.
|
||||
<tag/tag=RELENG_2_1_0/
|
||||
FreeBSD-2.1.x 用の開発分流であり, FreeBSD-stable として知られています.
|
||||
</descrip>
|
||||
|
||||
<p>以下はユーザが興味を持っていると思われる revision tag です:
|
||||
|
||||
<descrip>
|
||||
<tag/tag=RELENG_2_2_1_RELEASE/
|
||||
FreeBSD-2.2.1.
|
||||
<tag/tag=RELENG_2_2_0_RELEASE/
|
||||
FreeBSD-2.2.0.
|
||||
<tag/tag=RELENG_2_1_7_RELEASE/
|
||||
FreeBSD-2.1.7.
|
||||
<tag/tag=RELENG_2_1_6_1_RELEASE/
|
||||
FreeBSD-2.1.6.1.
|
||||
<tag/tag=RELENG_2_1_6_RELEASE/
|
||||
FreeBSD-2.1.6.
|
||||
<tag/tag=RELENG_2_1_5_RELEASE/
|
||||
FreeBSD-2.1.5.
|
||||
<tag/tag=RELENG_2_1_0_RELEASE/
|
||||
FreeBSD-2.1.0.
|
||||
</descrip>
|
||||
|
||||
<p>tag 名を示した通りにタイプされているか十分注意してください. CVSup
|
||||
は tag 名が正しいかどうかを見分けることはできません.
|
||||
tag が間違っていた場合, たまたまファイルがまったく存在しない正しい tag
|
||||
が指定されたものとしてCVSup は動作します. その場合は, 現在あるソースが
|
||||
削除されるでしょう.
|
||||
|
||||
<p>branch tag を指定した際には, 通常はその開発分流の最新バージョンの
|
||||
ファイルを受け取ります. いくらか前のバージョンを受け取りたい場合は,
|
||||
"date=" の value フィールドを使って日付を指定することで, これを実現することが
|
||||
できます. cvsup(1) のマニュアルページで, その方法を説明しています.
|
||||
|
||||
<p>例として, FreeBSD-current を受け取りたいとします. 次の行を supfile
|
||||
の始めに追加します:
|
||||
|
||||
<verb>
|
||||
*default tag=.
|
||||
</verb>
|
||||
|
||||
<p>"tag=" フィールドも "date=" フィールドも指定しなかった場合に
|
||||
動き出す重要な特殊なケースがあります. そのケースでは, 特定のバージョンの
|
||||
ファイルを受け取るのではなく, サーバの CVS リポジトリから実際の RCS
|
||||
ファイルを直接受け取ります. 一般的に開発者はこの処理のモードが
|
||||
好きなようです. 彼らのシステム上にリポジトリそのもののコピーを維持することで,
|
||||
リビジョン履歴を閲覧し過去のバージョンのファイルを検査できるようになります.
|
||||
しかし, これには大きなディスクスペースが必要になります.
|
||||
|
||||
<p><item>どこから入手したいのか?<label id="cvsup:config:where">
|
||||
|
||||
<p>更新情報をどこから入手するかを cvsup に伝えるために "host="
|
||||
フィールドを使用します。<ref id="mirrors-cvsup" name="CVSup ミラーサイト">
|
||||
のどこからでも入手できますが、最寄りのサイトを選ぶべきでしょう。
|
||||
この例では、第一の FreeBSD 配布サイト "cvsup.FreeBSD.org" を使用します:
|
||||
|
||||
<verb>
|
||||
*default host=cvsup.FreeBSD.org
|
||||
</verb>
|
||||
|
||||
<p>どのように cvsup を実行しても, この設定は "-h hostname" を
|
||||
使用してコマンドラインで変更することができます.
|
||||
|
||||
<p><item>自分のマシンのどこに置きたいのか?<label id="cvsup:config:dest">
|
||||
|
||||
<p>"prefix=" フィールドは, cvsup に受け取ったファイルをどこに置くかを
|
||||
伝えます. この例では, ソースファイルを直接メインのソースツリー
|
||||
"/usr/src" に置きます. "src" ディレクトリはすでにファイルを受け取るために
|
||||
選択したコレクションで暗黙に指定しているので, これは正しい仕様となります:
|
||||
|
||||
<verb>
|
||||
*default prefix=/usr
|
||||
</verb>
|
||||
|
||||
<p><item>どこに status ファイルを置きたいのか?<label id="cvsup:config:status">
|
||||
|
||||
<p>cvsup クライアントは "base" ディレクトリと呼ばれる場所に, ある
|
||||
status ファイルを維持しています. すでに受け取った更新情報を追従し続け
|
||||
ることで, これらのファイルは CVSup がより効果的に動作することを支援し
|
||||
ます. 標準の base ディレクトリ "/usr/local/etc/cvsup" を使用します:
|
||||
|
||||
<verb>
|
||||
*default base=/usr/local/etc/cvsup
|
||||
</verb>
|
||||
|
||||
<p>supfile に指定がない場合は, この設定をデフォルトで使用しますので,
|
||||
実際には上の行は必要ありません.
|
||||
|
||||
<p>base ディレクトリが存在しない場合は作成しておきましょう. base
|
||||
ディレクトリが存在しない場合, cvsup クライアントは実行を拒否します.
|
||||
|
||||
<p><item>その他もろもろの supfileの設定:
|
||||
|
||||
<p>通常 supfile に入れておくべき行がもう一つあります:
|
||||
|
||||
<verb>
|
||||
*default release=cvs delete use-rel-suffix compress
|
||||
</verb>
|
||||
|
||||
<p>"release=cvs" は, サーバがメインの FreeBSD CVS リポジトリから
|
||||
その情報を取得するように指示します. ほとんどの場合はこのようにしておきますが,
|
||||
ここでの説明の範疇をこえるような状況では他の指定をすることも可能です.
|
||||
|
||||
<p>"delete" は CVSup にファイルを削除することを許可します. CVSup が
|
||||
ソースツリーを完全に最新の状態に保てるようにするためには, これは常に
|
||||
指定しておくべきでしょう. CVSup は, これらの責任範囲のファイルだけを
|
||||
慎重に削除します. たまたま存在する他の余分なファイルについては,
|
||||
まったく手をつけずに残しておきます.
|
||||
|
||||
<p>"use-rel-suffix" は ... 神秘的なものです. これについて本当に
|
||||
知りたい人は, cvsup(1) のマニュアルページをご覧ください. でなければ,
|
||||
何も考えずに指定してみてください.
|
||||
|
||||
<p>"compress" は通信チャネルで gzip 形式の圧縮の使用を有効にします.
|
||||
ご使用のネットワーク接続が T1 speed 以上である場合, この圧縮を
|
||||
使用しない方がよいかもしれません. そうでない場合は十分に役に立ちます.
|
||||
|
||||
<p><item>supfile の例のまとめ:
|
||||
|
||||
<p>以下は supfile の例の全体です:
|
||||
|
||||
<verb>
|
||||
*default tag=.
|
||||
*default host=cvsup.FreeBSD.org
|
||||
*default prefix=/usr
|
||||
*default base=/usr/local/etc/cvsup
|
||||
*default release=cvs delete use-rel-suffix compress
|
||||
src-all
|
||||
cvs-crypto
|
||||
</verb>
|
||||
</itemize>
|
||||
|
||||
<sect2><heading>CVSup の実行</heading>
|
||||
|
||||
<p>さて, 更新の準備ができました. これを実行するコマンドラインは
|
||||
実に簡単です:
|
||||
|
||||
<verb>
|
||||
cvsup supfile
|
||||
</verb>
|
||||
|
||||
<p>もちろん, ここでの "supfile" は作成したばかりの supfile
|
||||
のファイル名です. X11 環境で実行するものと仮定して, cvsup は
|
||||
通常の操作に必要なボタンを持つ GUI ウィンドウを表示します.
|
||||
"go" ボタンを押して, 実行を監視してください.
|
||||
|
||||
<p>この例では実際の "/usr/src" ツリーを更新しているので, cvsup
|
||||
にファイルを更新するのに必要なパーミッションを与えるために, ユーザ root
|
||||
で実行する必要があります. コンフィグレーションファイルを作ったばかりで,
|
||||
しかも以前にこのプログラムを実行したことがないので, 神経質になるのは
|
||||
無理もない話だと思います. 大切なファイルに触らずに試しに実行する簡単な
|
||||
方法があります. どこか適当な場所に空のディレクトリを作成して,
|
||||
コマンドラインの引数で指定するだけです:
|
||||
|
||||
<verb>
|
||||
mkdir /var/tmp/dest
|
||||
cvsup supfile /var/tmp/dest
|
||||
</verb>
|
||||
|
||||
<p>指定したディレクトリは, すべての更新されるファイルの
|
||||
更新先ディレクトリとして使用します. CVSup は "/usr/src" の下の
|
||||
ファイルを検査しますが, 変更や削除はまったくおこないません.
|
||||
かわりに "/var/tmp/dest/usr/src" に更新されたすべてのファイルが
|
||||
置かれるようになります. この方法で実行した場合は, CVSup は base
|
||||
ディレクトリの status ファイルを更新せずにそのままにします.
|
||||
これらのファイルの新しいバージョンは指定されたディレクトリ
|
||||
に書き込まれます. "/usr/src" の読み取り許可がある限り, このような
|
||||
試し実行のためにユーザ root になる必要はありません.
|
||||
|
||||
<p>X11 を利用していないとか単に GUI が気に入らない場合は, cvsup
|
||||
起動時にコマンドラインに二つほどオプションを追加する必要があります:
|
||||
|
||||
<verb>
|
||||
cvsup -g -L 2 supfile
|
||||
</verb>
|
||||
|
||||
<p>"-g" オプションは cvsup に GUI を使用しないように伝えます. X11
|
||||
を利用していない場合には自動的に指定されますが, そうでない場合は
|
||||
明示的に指定します.
|
||||
|
||||
<p>"-L 2" オプションは cvsup にファイル更新中の詳細情報をプリントアウト
|
||||
するように伝えます. 冗長性には "-L 0" から "-L 2" までの三つのレベル
|
||||
があります. デフォルトは 0 であり, エラーメッセージ以外はまったく出力
|
||||
しません.
|
||||
|
||||
<p>たくさんの他のオプション変数があります. それらの簡単な一覧は
|
||||
"cvsup -H" で表示されます. より詳しい説明はマニュアルページをご覧ください.
|
||||
|
||||
<p>動作している更新の方法に満足したら, cron(8) を使って cvsup を定期的に
|
||||
実行させる準備をすることができます. cron から起動する際には, 明示的に
|
||||
cvsup が GUI を使わないようにする必要があります.
|
||||
|
||||
<sect2><heading>CVSup ファイルコレクション<label id="cvsup:collec"></heading>
|
||||
|
||||
<p>CVSup 経由で入手できるファイルコレクションは階層的に組織化されています.
|
||||
いくつか大きなコレクションがあり, それらは小さなサブコレクションに
|
||||
分割されています. 大きなコレクションは, そのサブコレクション毎に
|
||||
受信することと同じことになります. 下の一覧ではコレクション間の階層関係を
|
||||
字下げして表現します.
|
||||
|
||||
<p> 最も一般的に使用するコレクションは <tt/src-all/, <tt/cvs-crypto/,
|
||||
そして <tt/ports-all/ です. 他のコレクションは特別な目的を持つ人達だけが
|
||||
使用しており, ミラーサイトはそれらのすべてを持っていないかもしれません.
|
||||
|
||||
<descrip>
|
||||
<tag><tt>cvs-all release=cvs</tt></tag>
|
||||
メインの FreeBSD CVS リポジトリであり, 輸出規制された暗号化コードは含まれていません.
|
||||
<p>
|
||||
<descrip>
|
||||
<tag><tt>distrib release=cvs</tt></tag>
|
||||
FreeBSD の配布とミラーに関連するファイルです.
|
||||
<tag><tt>doc-all release=cvs</tt></tag>
|
||||
FreeBSD ハンドブックおよびその他のドキュメントのソースです.
|
||||
<tag><tt>ports-all release=cvs</tt></tag>
|
||||
FreeBSD の ports コレクションです.
|
||||
<p>
|
||||
<descrip>
|
||||
<tag><tt>ports-archivers release=cvs</tt></tag>
|
||||
アーカイビングのツール.
|
||||
<tag><tt>ports-astro release=cvs</tt></tag>
|
||||
天文学関連の ports.
|
||||
<tag><tt>ports-audio release=cvs</tt></tag>
|
||||
サウンドサポート.
|
||||
<tag><tt>ports-base release=cvs</tt></tag>
|
||||
<tt>/usr/ports</tt> のトップにあるその他のファイル.
|
||||
<tag><tt>ports-benchmarks release=cvs</tt></tag>
|
||||
ベンチマークプログラム.
|
||||
<tag><tt>ports-cad release=cvs</tt></tag>
|
||||
CAD ツール.
|
||||
<tag><tt>ports-chinese release=cvs</tt></tag>
|
||||
中国語サポート.
|
||||
<tag><tt>ports-comms release=cvs</tt></tag>
|
||||
通信ソフトウェア.
|
||||
<tag><tt>ports-converters release=cvs</tt></tag>
|
||||
文字コードコンバータ.
|
||||
<tag><tt>ports-databases release=cvs</tt></tag>
|
||||
データベース.
|
||||
<tag><tt>ports-devel release=cvs</tt></tag>
|
||||
開発ユーティリティ.
|
||||
<tag><tt>ports-editors release=cvs</tt></tag>
|
||||
エディタ.
|
||||
<tag><tt>ports-emulators release=cvs</tt></tag>
|
||||
他の OS のエミュレータ.
|
||||
<tag><tt>ports-games release=cvs</tt></tag>
|
||||
ゲーム.
|
||||
<tag><tt>ports-graphics release=cvs</tt></tag>
|
||||
グラフィックユーティリティ.
|
||||
<tag><tt>ports-japanese release=cvs</tt></tag>
|
||||
日本語サポート.
|
||||
<tag><tt>ports-korean release=cvs</tt></tag>
|
||||
韓国語サポート.
|
||||
<tag><tt>ports-lang release=cvs</tt></tag>
|
||||
プログラミング言語.
|
||||
<tag><tt>ports-mail release=cvs</tt></tag>
|
||||
メールソフトウェア.
|
||||
<tag><tt>ports-math release=cvs</tt></tag>
|
||||
数値計算ソフトウェア.
|
||||
<tag><tt>ports-mbone release=cvs</tt></tag>
|
||||
MBone アプリケーション.
|
||||
<tag><tt>ports-misc release=cvs</tt></tag>
|
||||
色々なユーティリティ.
|
||||
<tag><tt>ports-net release=cvs</tt></tag>
|
||||
ネットワーキングソフトウェア.
|
||||
<tag><tt>ports-news release=cvs</tt></tag>
|
||||
USENET ニュースのソフトウェア.
|
||||
<tag><tt>ports-plan9 release=cvs</tt></tag>
|
||||
Plan9 からの色々なプログラム.
|
||||
<tag><tt>ports-print release=cvs</tt></tag>
|
||||
印刷ソフトウェア.
|
||||
<tag><tt>ports-russian release=cvs</tt></tag>
|
||||
ロシア語サポート.
|
||||
<tag><tt>ports-security release=cvs</tt></tag>
|
||||
セキュリティユーティリティ.
|
||||
<tag><tt>ports-shells release=cvs</tt></tag>
|
||||
コマンドラインシェル.
|
||||
<tag><tt>ports-sysutils release=cvs</tt></tag>
|
||||
システムユーティリティ.
|
||||
<tag><tt>ports-textproc release=cvs</tt></tag>
|
||||
文書処理ユーティリティ(デスクトップパブリッシングは含まない).
|
||||
<tag><tt>ports-vietnamese release=cvs</tt></tag>
|
||||
ベトナム語サポート.
|
||||
<tag><tt>ports-www release=cvs</tt></tag>
|
||||
World Wide Web 関連のソフトウェア.
|
||||
<tag><tt>ports-x11 release=cvs</tt></tag>
|
||||
X11 のソフトウェア.
|
||||
</descrip>
|
||||
<tag><tt>src-all release=cvs</tt></tag>
|
||||
メインの FreeBSD ソース群であり, 輸出規制された暗号化コードは含まれていません.
|
||||
<p>
|
||||
<descrip>
|
||||
<tag><tt>src-base release=cvs</tt></tag>
|
||||
<tt>/usr/src</tt> のトップにあるその他のファイル.
|
||||
<tag><tt>src-bin release=cvs</tt></tag>
|
||||
シングルユーザモードで必要なユーザユーティリティ
|
||||
(<tt>/usr/src/bin</tt>).
|
||||
<tag><tt>src-contrib release=cvs</tt></tag>
|
||||
FreeBSD プロジェクト外部からのユーティリティおよびライブラリ,
|
||||
比較的無修正 (<tt>/usr/src/contrib</tt>).
|
||||
<tag><tt>src-etc release=cvs</tt></tag>
|
||||
システムコンフィグレーションファイル (<tt>/usr/src/etc</tt>).
|
||||
<tag><tt>src-games release=cvs</tt></tag>
|
||||
ゲーム(<tt>/usr/src/games</tt>).
|
||||
<tag><tt>src-gnu release=cvs</tt></tag>
|
||||
GNU Public License 下にあるユーティリティ (<tt>/usr/src/gnu</tt>).
|
||||
<tag><tt>src-include release=cvs</tt></tag>
|
||||
ヘッダファイル (<tt>/usr/src/include</tt>).
|
||||
<tag><tt>src-lib release=cvs</tt></tag>
|
||||
ライブラリ (<tt>/usr/src/lib</tt>).
|
||||
<tag><tt>src-libexec release=cvs</tt></tag>
|
||||
システムプログラムであり, 通常は他のプログラムから実行される
|
||||
(<tt>/usr/src/libexec</tt>).
|
||||
<tag><tt>src-release release=cvs</tt></tag>
|
||||
FreeBSD の release を構築するために必要なファイル (<tt>/usr/src/release</tt>).
|
||||
<tag><tt>src-sbin release=cvs</tt></tag>
|
||||
シングルユーザモード用のシステムユーティリティ(<tt>/usr/src/sbin</tt>).
|
||||
<tag><tt>src-share release=cvs</tt></tag>
|
||||
多様なシステム間で共有可能なファイル (<tt>/usr/src/share</tt>).
|
||||
<tag><tt>src-sys release=cvs</tt></tag>
|
||||
カーネル (<tt>/usr/src/sys</tt>).
|
||||
<tag><tt>src-tools release=cvs</tt></tag>
|
||||
FreeBSD の保守用の色々なツール (<tt>/usr/src/tools</tt>).
|
||||
<tag><tt>src-usrbin release=cvs</tt></tag>
|
||||
ユーザユーティリティ (<tt>/usr/src/usr.bin</tt>).
|
||||
<tag><tt>src-usrsbin release=cvs</tt></tag>
|
||||
システムユーティリティ (<tt>/usr/src/usr.sbin</tt>).
|
||||
</descrip>
|
||||
<tag><tt>www release=cvs</tt></tag>
|
||||
World Wide Web のデータ用のソースです.
|
||||
</descrip>
|
||||
<tag><tt>cvs-crypto release=cvs</tt></tag>
|
||||
輸出規制された暗号化コードです.
|
||||
<p>
|
||||
<descrip>
|
||||
<tag><tt>src-contrib-crypto release=cvs</tt></tag>
|
||||
輸出規制された FreeBSD プロジェクト外部からのユーティリティおよび
|
||||
ライブラリ, 比較的無修正 (<tt>/usr/src/contrib-crypto</tt>).
|
||||
<tag><tt>src-eBones release=cvs</tt></tag>
|
||||
Kerberos および DES (<tt>/usr/src/eBones</tt>).
|
||||
<tag><tt>src-secure release=cvs</tt></tag>
|
||||
DES (<tt>/usr/src/secure</tt>).
|
||||
</descrip>
|
||||
<tag><tt>distrib release=self</tt></tag>
|
||||
CVSup サーバ自身のコンフィグレーションファイルです. CVSup ミラーサイトが使用します.
|
||||
<tag><tt>gnats release=current</tt></tag>
|
||||
GNATS バグトラッキングデータベースです.
|
||||
<tag><tt>src-sys release=lite2</tt></tag>
|
||||
lite2 kernel のマージ用の CVS リポジトリです.
|
||||
<tag><tt>src-sys release=smp</tt></tag>
|
||||
SMP プロジェクト用の CVS リポジトリです.
|
||||
<tag><tt>www release=current</tt></tag>
|
||||
インストールされた World Wide Web のデータです. WWW ミラーサイトが使用します.
|
||||
</descrip>
|
||||
|
||||
<sect2><heading>CVSup のアナウンス, 質問およびバグ報告</heading>
|
||||
|
||||
<p>CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; で
|
||||
おこなわれています. ソフトウェアの新しいバージョンは &a.announce; で
|
||||
アナウンスされます.
|
||||
|
||||
<p>質問とバグ報告はプログラムの作者, <url
|
||||
url="mailto:cvsup-bugs@polstra.com" name="cvsup-bugs@polstra.com"> へ
|
||||
送ってください.
|
||||
@ -1,58 +0,0 @@
|
||||
<!-- $Id: cyclades.sgml,v 1.4 1997/02/22 13:00:49 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.3 -->
|
||||
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
]>
|
||||
-->
|
||||
<sect2><heading><tt>cy</tt> ドライバのコンフィグ<label id="cy"></heading>
|
||||
|
||||
<p><em>原作: &a.alex;.<newline>6 June 1996.</em>
|
||||
<p><em>訳: &a.yuki;.<newline>6 September 1996.</em>
|
||||
|
||||
Cyclades社のマルチポートカードは, 他のマルチポートカードが
|
||||
使う<tt>sio</tt>の代わりに<tt>cy</tt>ドライバを使います.
|
||||
コンフィグレーションは非常に簡単で,
|
||||
|
||||
<enum>
|
||||
<item><tt>cy</tt> デバイスをあなたの
|
||||
<ref id="kernelconfig:config"
|
||||
name="カーネルのコンフィグレーション">に足します.
|
||||
(注意. あなたのirqやiomemの設定がが違っているかもしれません)
|
||||
|
||||
<tscreen><verb>
|
||||
device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr
|
||||
</verb></tscreen>
|
||||
|
||||
<item>新しいカーネルの<ref id="kernelconfig:building"
|
||||
name="再構成とインストール"> をします.
|
||||
|
||||
<item><ref id="kernelconfig:nodes" name="デバイスノード">
|
||||
を次(8ポートと仮定しています.)のように打って作ります:
|
||||
|
||||
<tscreen><verb>
|
||||
# cd /dev
|
||||
# for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done
|
||||
</verb></tscreen>
|
||||
|
||||
<item>もし, 必要なら
|
||||
シリアルデバイス(<tt>ttyd</tt>)とそっくりにコピーして
|
||||
<ref id="dialup" name="dialup">エントリを作り, <tt>ttyd</tt>
|
||||
<tt>ttyd</tt>の代わりに<tt>ttyc</tt>を使います. 例:
|
||||
|
||||
<tscreen><verb>
|
||||
ttyc0 "/usr/libexec/getty std.38400" unknown on insecure
|
||||
ttyc1 "/usr/libexec/getty std.38400" unknown on insecure
|
||||
ttyc2 "/usr/libexec/getty std.38400" unknown on insecure
|
||||
[...]
|
||||
ttyc7 "/usr/libexec/getty std.38400" unknown on insecure
|
||||
</verb></tscreen>
|
||||
|
||||
<item>新しいカーネルで立ち上げます.
|
||||
|
||||
</enum>
|
||||
@ -1,103 +0,0 @@
|
||||
<!-- $Id: development.sgml,v 1.7 1997/02/25 04:54:57 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.12 -->
|
||||
|
||||
<sect><heading>FreeBSDの開発モデル<label id="development"></heading>
|
||||
|
||||
<p><em>原作: &a.asami;.
|
||||
<newline>18 October 1996.</em>
|
||||
|
||||
<p><em>訳: &a.asami;.
|
||||
<newline>31 October 1996.</em>
|
||||
|
||||
<p>FreeBSDの開発は非常に開かれた, 柔軟性のあるプロセスです. <ref
|
||||
id="contrib" name="コントリビュータのリスト">を見ていただければわかる
|
||||
とおり, FreeBSDは文字通り世界中の何百という人々の努力によって開発され
|
||||
ています. 新しい開発者はいつでも大歓迎ですので, &a.hackers; にメールを
|
||||
送ってください. また, 大勢で議論するよりは一人で静かに開発にふけりた
|
||||
いという人は私たちのFTPサイト<htmlurl
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/incoming"
|
||||
name="ftp.freebsd.org">を使ってパッチや開発中のソースを公開してくださっ
|
||||
て結構です. &a.announce; もありますので, 他のFreeBSDユーザに自分のやっ
|
||||
ていることを宣伝したい時にはどうぞ使ってください.
|
||||
|
||||
あと, FreeBSDプロジェクトとその開発プロセスについて, どなたにも知って
|
||||
いていただきたいのは以下のようなことです.
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag><bf>CVSリポジトリ</bf><label id="development:cvs-repository"></tag>
|
||||
|
||||
<p>FreeBSDのソースツリーは<htmlurl
|
||||
url="http://www.cyclic.com/cyclic-pages/CVS-sheet.html" name="CVS">
|
||||
(Concurrent Version System)によってメンテナンスされています. CVSはソー
|
||||
スコード管理用のフリーソフトウェアで, FreeBSDのリリースにも含まれてい
|
||||
ます. FreeBSDの<htmlurl url="http://www.freebsd.org/cgi/cvsweb"
|
||||
name="メインのCVSリポジトリ">は米国カリフォルニア州のコンコルド市に存在
|
||||
し, そこから世界中のたくさんのミラーサイトにコピーされています. CVSツ
|
||||
リーそのもの, そしてそのチェックアウトされたバージョンである<ref
|
||||
id="current" name="-current">と<ref id="stable" name="-stable">はあな
|
||||
たのマシンにも簡単に取ってくることができます. これについては<ref
|
||||
id="synching" name="ソースツリーの同期">の章をご覧ください.</p>
|
||||
|
||||
<tag><bf>ソースツリー管理者</bf><label id="development:committers"></tag>
|
||||
|
||||
<p><ref id="contrib:committers" name="ソースツリー管理者">はCVSツリー
|
||||
への書き込み権限を持っている人, つまりFreeBSDのソースに変更を加えるこ
|
||||
とができる人です. (CVSでリポジトリに変更を加えるには<tt>cvs(1)</tt>
|
||||
``<tt>commit</tt>'' というコマンドを使うので, これらの人々は英語では
|
||||
``committers'' と呼ばれます.) 開発者にコードを送って見てもらうのに一
|
||||
番いい方法は<htmlurl url="http://www.freebsd.org/send-pr.html"
|
||||
name="send-pr(1)">コマンドを使うことです. もし, 何か問題があって
|
||||
<tt>send-pr</tt>が使えないなら<htmlurl
|
||||
url="mailto:committers@freebsd.org" name="committers@freebsd.org">にメー
|
||||
ルを送っていただいても結構です.</p>
|
||||
|
||||
<tag><bf>FreeBSDコアチーム</bf><label id="development:core"></tag>
|
||||
|
||||
<p><ref id="contrib:core" name="FreeBSDコアチーム">はFreeBSDプロジェク
|
||||
トが会社だとすると取締役会にあたるものです. コアチームとして一番重要
|
||||
な役割はFreeBSDプロジェクトが全体としてよい方向に向かっていることを確
|
||||
認することです. 責任感あふれる開発者を上記のソースツリー管理者として
|
||||
招くこと, また仕事上の都合などでコアチームをやめた人たちの後任を見つけ
|
||||
ることもコアチームの役割です. 現在のコアチームのほとんどは最初は単な
|
||||
る一開発者としてプロジェクトに関わりはじめ, ずるずるといつのまにか深み
|
||||
にはまってしまった人です.</p>
|
||||
|
||||
<p>コアチームのうち何人かは特定の<ref id="contrib:who" name="担当分野">
|
||||
を持っており, システムのうち一部に特に重点をおいて面倒を見ています.
|
||||
また, 忘れてほしくないのはコアチームのほとんどはFreeBSDについてはボラ
|
||||
ンティアであり, FreeBSDプロジェクトからは何ら金銭的な支援を受けていな
|
||||
いということです. ですから, ここでの「責任」は「保証されたサポート」
|
||||
ではありません. そういう意味で, 上記の取締役会という例えはあまりよく
|
||||
ないかもしれません. むしろ, FreeBSDのために人生を棒に振ってしまった人
|
||||
の集まりといった方が正しいかも.... <tt>;)</tt></p>
|
||||
|
||||
<tag><bf>その他のコントリビュータ</bf></tag>
|
||||
|
||||
<p>最後になりますが, もっとも重要で多数をしめる開発者はフィードバック
|
||||
やバグフィクスをどんどん送ってくれるユーザ自身です. FreeBSDの開発に外
|
||||
郭から関わっていきたいという人は &a.hackers; (<ref id="eresources:mail"
|
||||
name="メーリングリスト情報">を見てください) に参加するといいでしょう.</p>
|
||||
|
||||
<p>FreeBSDのソースツリーに入っている何かを書いた人の<ref
|
||||
id="contrib:additional" name="リスト">は日に日に長くなっています. あ
|
||||
なたも今日, 何か送ることからはじめてみませんか? <tt>:-)</tt></p>
|
||||
|
||||
<p>もちろんFreeBSDに貢献するにはコードを書くほかにもいろいろな方法があ
|
||||
ります. 助けが求められている分野については, このハンドブックの<ref
|
||||
id="submitters" name="貢献の仕方">の節を見てください.</p>
|
||||
|
||||
</descrip>
|
||||
|
||||
ひとことで言うと, FreeBSDの開発組織はゆるやかな同心円状になっています.
|
||||
ともすると中央集権的に見えがちなこの組織は, FreeBSDの<em>ユーザ</em>が
|
||||
きちんと管理されたコードベースを容易に追いかけられるようにデザインされ
|
||||
ているもので, 貢献したいという人を締め出す意図は全くありません! 私た
|
||||
ちの目標は安定したオペレーティングシステムと簡単にインストールして使う
|
||||
ことのできる<ref id="ports" name="アプリケーション">を提供することであ
|
||||
り, この方法は結構うまくはたらくのです.
|
||||
|
||||
これからFreeBSDの開発にたずさわろうという人に, 私たちが望むことはただ
|
||||
一つです: FreeBSDの成功を継続的なものにするために, 現在の開発者と同じ
|
||||
ような情熱を持って接してください!
|
||||
@ -1,264 +0,0 @@
|
||||
<!-- $Id: dialout.sgml,v 1.4 1997/02/22 13:00:51 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.5 -->
|
||||
|
||||
<!-- This is an SGML document in the Linuxdoc DTD of the Tutorial for
|
||||
Configuring a FreeBSD for Dialout Services.
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
|
||||
|
||||
<linuxdoc>
|
||||
<article>
|
||||
<title>Dialout
|
||||
<author>FAQ
|
||||
<date>24 NOV 1996, (c) 1996
|
||||
|
||||
<abstract>この章は FreeBSD に接続しているモデムからダイアルアウトするための
|
||||
基本的な情報について説明しています. この情報は将来 PPP 接続をおこなう場合の
|
||||
第一のステップとなります.
|
||||
</abstract>
|
||||
|
||||
<toc>
|
||||
-->
|
||||
|
||||
<sect><heading>ダイアルアウトサービス<label id="dialout"></heading>
|
||||
|
||||
<p><em>原作: FAQ からの情報</em>
|
||||
<p><em>訳: 丸山剛司 <url url="mailto:tmaruya@nnc.or.jp"
|
||||
name="<tmaruya@nnc.or.jp>">.
|
||||
<newline>31 December 1996.</em>
|
||||
|
||||
以下はモデムを利用して他のコンピュータと接続する方法を説明しています.
|
||||
これはリモートホストとターミナル接続を確立するための適切な方法です.
|
||||
<p>これは BBS に接続するときによく使います.
|
||||
<p>この種の接続は PPP 接続に問題がある場合, Internet 上にあるファイルを
|
||||
転送するのに非常に役に立ちます. FTP で何らかのファイルを転送したいのに
|
||||
PPP 接続を確立できない場合は, ファイルを FTP 転送するためにターミナルセッション
|
||||
を利用します. そして ZMODEM を利用してファイルを転送します.
|
||||
<sect1>
|
||||
<heading><tt/tip/ や <tt/cu/ が実行できないはなぜ?</heading>
|
||||
<p>
|
||||
あなたのシステムで <tt/tip/ や <tt/cu/ というプログラムは
|
||||
<tt/uucp/ や <tt/dialer/ というグループに所属しているユーザのみが
|
||||
実行できるようになっているのでしょう. リモートホストやモデムを
|
||||
利用できる <tt/dialer/ のグループにあなたのアカウントを
|
||||
加えましょう.
|
||||
|
||||
もしくは下記のコマンドを使うことによって, そのシステムで
|
||||
<tt/tip/ や <tt/cu/ を誰でも使えるようになります:
|
||||
<verb>
|
||||
chmod 4511 /usr/bin/tip
|
||||
</verb>
|
||||
このコマンドは <tt/cu/ に対しておこなう必要はありません, それは
|
||||
<tt/cu/ は <tt/tip/ に対するハードリンクだからです.
|
||||
|
||||
<sect1>
|
||||
<heading>私の Hayes モデムはサポートされていません, どうしよう?
|
||||
</heading>
|
||||
<p>
|
||||
実際, <tt/tip/ の マニュアルページは古くなっています. 既に Hayes
|
||||
ダイアラが組み込まれています. <tt>/etc/remote</tt> ファイル中で
|
||||
``<tt/at=hayes/'' を使ってください.
|
||||
|
||||
Hayes ドライバは, 最近のモデムの新しい機能である
|
||||
<tt/BUSY/, <tt/NO DIALTONE/, <tt/CONNECT 115200/などのメッセージを
|
||||
認識できるほど賢くはなく, 単に混乱を起こすだけです.
|
||||
<tt/tip/を使う場合には, (<tt/ATX0&W/ とするなどして) これらの
|
||||
メッセージを表示させないようにしなくてはいけません.
|
||||
|
||||
また, <tt/tip/ のダイアルのタイムアウトは 60秒です. モデムの
|
||||
タイムアウト設定はそれより短くすべきであり, そうしないと
|
||||
<tt/tip/ は通信に問題があると判断するでしょう. <tt/ATS7=45&W/
|
||||
を実行してください.
|
||||
|
||||
実際, デフォルトの <tt/tip/ は Hayes の完全なサポートを
|
||||
しているわけではありません. 解決方法は
|
||||
<tt>/usr/src/usr.bin/tip/tip</tt> の下の <tt/tipconf.h/
|
||||
を変更することです. もちろんこれにはソース配布ファイルが必要です.
|
||||
|
||||
``<tt/#define HAYES 0/'' と記述されている行を ``<tt/#define HAYES 1/''
|
||||
と変更し, そして ``<tt/make/'', ``<tt/make install/'' を実行します.
|
||||
これでうまく動作するでしょう.
|
||||
|
||||
<sect1>
|
||||
<heading>これらの AT コマンドを入力するには?<label id="direct-at">
|
||||
</heading>
|
||||
<p>
|
||||
<tt>/etc/remote</tt> ファイルの中で ``<tt/direct/'' エントリを作ります.
|
||||
たとえばモデムが 1番目のシリアルポートである <tt>/dev/cuaa0</tt>
|
||||
に接続されている場合, 次のようにします:
|
||||
<verb>
|
||||
cuaa0:dv=/dev/cuaa0:br#19200:pa=none
|
||||
</verb>
|
||||
モデムがサポートする最大の bps レートを br フィールドに使います.
|
||||
そして ``<tt/tip cuaa0/'' を実行すると, モデムが利用できるようになります.
|
||||
|
||||
<tt>/dev/cuaa0</tt>がシステムに存在しない場合は, 次のようにします:
|
||||
<verb>
|
||||
cd /dev
|
||||
./MAKEDEV cuaa0
|
||||
</verb>
|
||||
<p>
|
||||
または root になって以下のように cu コマンドを実行します:
|
||||
<verb>
|
||||
cu -l ``line'' -s ``speed''
|
||||
</verb>
|
||||
line にはシリアルポートを指定します (例えば <tt>/dev/cuaa0</tt>).
|
||||
そして speed には接続する速度を指定します (例えば <tt>57600</tt>).
|
||||
その後 AT コマンドを実行したら, <tt>~.</tt> と入力すれば終了します.
|
||||
|
||||
<sect1>
|
||||
<heading>pn 機能の <tt/@/ 記号が使えません!</heading>
|
||||
<p>
|
||||
電話番号 (pn) 機能の中での <tt/@/ 記号は, tip に
|
||||
<tt>/etc/phone</tt> にある電話番号を参照するように伝えます.
|
||||
しかし <tt/@/ の文字は <tt>/etc/remote</tt> のような
|
||||
設定ファイルの中では特殊文字となります.
|
||||
バックスラッシュを使ってエスケープをおこないます:
|
||||
<verb>
|
||||
pn=\@
|
||||
</verb>
|
||||
|
||||
<sect1>
|
||||
<heading>コマンドラインから電話番号を指定するには?</heading>
|
||||
<p>
|
||||
``<tt/generic/'' エントリと呼ばれるものを <tt>/etc/remote</tt>
|
||||
に追加します. 例えば次のようにします:
|
||||
<verb>
|
||||
tip115200|Dial any phone number at 115200 bps:\
|
||||
:dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
|
||||
tip57600|Dial any phone number at 57600bps:\
|
||||
:dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:
|
||||
</verb>
|
||||
|
||||
そして ``<tt/tip -115200 5551234/'' のように利用できます.
|
||||
<tt/tip/ より <tt/cu/ を使いたい場合,
|
||||
<tt/cu/ の generic エントリを使います:
|
||||
<verb>
|
||||
cu115200|Use cu to dial any number at 115200bps:\
|
||||
:dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:
|
||||
</verb>
|
||||
そして ``<tt/cu 5551234 -s 115200/'' と実行します.
|
||||
|
||||
<sect1>
|
||||
<heading>毎回 bps レートを入力しなければいけませんか?</heading>
|
||||
<p>
|
||||
<tt/tip1200/ や <tt/cu1200/ 用のエントリを記述し,
|
||||
適切な通信速度を br フィールドに設定します.
|
||||
<tt/tip/ は 1200 bps が正しいデフォルト値であるとみなすので,
|
||||
``<tt/tip1200/'' エントリを参照します. もちろん 1200 bps
|
||||
を使わなければならないわけではありません.
|
||||
|
||||
<sect1>
|
||||
<heading>ターミナルサーバを経由して複数のホストへアクセスしたいんです.
|
||||
</heading>
|
||||
<p>
|
||||
毎回接続されるのを待って ``<tt/CONNECT <host>/'' と入力する
|
||||
かわりに, tip の <tt/cm/ 機能を使います.
|
||||
例えば, <tt>/etc/remote</tt> に次のようなエントリを追加します:
|
||||
<verb>
|
||||
pain|pain.deep13.com|Forrester's machine:\
|
||||
:cm=CONNECT pain\n:tc=deep13:
|
||||
muffin|muffin.deep13.com|Frank's machine:\
|
||||
:cm=CONNECT muffin\n:tc=deep13:
|
||||
deep13:Gizmonics Institute terminal server:\
|
||||
:dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234:
|
||||
</verb>
|
||||
|
||||
これで, ``<tt/tip pain/'' や ``<tt/tip muffin/'' と実行すると
|
||||
pain や muffin のホストに接続することができ,
|
||||
<tt/tip deep13/ を実行するとターミナルサーバに接続します.
|
||||
|
||||
<sect1>
|
||||
<heading>tip を使ってそれぞれのサイトの複数の回線に接続できますか?
|
||||
</heading>
|
||||
<p>
|
||||
これは大学に電話回線がいくつかあって数千人の学生が接続しようとする
|
||||
場合によくある問題です.
|
||||
<p>
|
||||
あなたの大学のエントリを <tt>/etc/remote</tt> ファイルに作成して,
|
||||
<tt/pn/ のフィールドには <tt>@</tt> を使います:
|
||||
<verb>
|
||||
big-university:\
|
||||
:pn=\@:tc=dialout
|
||||
dialout:\
|
||||
:dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:
|
||||
</verb>
|
||||
|
||||
そして <tt>/etc/phone</tt> ファイルに大学の電話番号の一覧を書きます:
|
||||
<verb>
|
||||
big-university 5551111
|
||||
big-university 5551112
|
||||
big-university 5551113
|
||||
big-university 5551114
|
||||
</verb>
|
||||
|
||||
<tt/tip/ は一連の電話番号を試みて, 最終的に接続できなければあきらめます.
|
||||
リトライを続けさせたい場合は, <tt/tip/ を while ループに入れて
|
||||
実行します.
|
||||
|
||||
<sect1>
|
||||
<heading>CTRL+P を 1回送るために 2度押す必要があるのはなぜ?
|
||||
</heading>
|
||||
<p>
|
||||
CTRL+P は通常 ``force (強制)'' 文字であり, <tt/tip/ に次の文字が
|
||||
リテラルデータであることを伝えます. force 文字は「変数の設定」
|
||||
を意味する <tt/~s/ エスケープによって他の文字にすることができます.
|
||||
|
||||
``<tt/~sforce=<single-char>/'' と入力して改行します.
|
||||
<tt/<single-char>/ は, 任意の 1バイト文字です.
|
||||
<tt/<single-char>/ を省略すると NUL 文字になり,
|
||||
これは CTRL+2 や CTRL+SPACE を押しても入力できます.
|
||||
いくつかのターミナルサーバで使われているのを
|
||||
見ただけですが, <tt/<single-char>/ に SHIFT+CTRL+6
|
||||
に割り当てるのもよいでしょう.
|
||||
|
||||
<tt>$HOME/.tiprc</tt> に次のように定義することで,
|
||||
任意の文字を force 文字として利用できます:
|
||||
<verb>
|
||||
force=<single-char>
|
||||
</verb>
|
||||
|
||||
<sect1>
|
||||
<heading>打ち込んだ文字が突然すべて大文字になりました??</heading>
|
||||
<p>
|
||||
CTRL+A を押してしまい、caps-lock キーが壊れている場合のために設計された
|
||||
tip の ``raise character'' モードに入ったのでしょう.
|
||||
既に述べたように <tt/~s/ を使って, ``raisechar'' をより適切な値に
|
||||
変更してください. もしこれら両方の機能を使用しないのであれば,
|
||||
force 文字と同じ設定にすることもできます.
|
||||
|
||||
以下は CTRL+2 や CTRL+A などを頻繁に使う必要のある Emacs
|
||||
ユーザにうってつけの. tiprc ファイルのサンプルです:
|
||||
<verb>
|
||||
force=^^
|
||||
raisechar=^^
|
||||
</verb>
|
||||
^^ は SHIFT+CTRL+6 です.
|
||||
|
||||
<sect1>
|
||||
<heading><tt/tip/ でファイルを転送するには?</heading>
|
||||
<p>
|
||||
もし他の UNIX のシステムと接続しているなら, <tt/~p/(put) や
|
||||
<tt/~t/(take) でファイルの送受信ができます. これらのコマンドは
|
||||
相手のシステムの上で ``<tt/cat/'' や ``<tt/echo/'' を実行することで
|
||||
送受信をします. 書式は以下のようになります:
|
||||
<verb>
|
||||
~p <ローカルのファイル名> [<リモートのファイル名>]
|
||||
~t <リモートのファイル名> [<ローカルのファイル名>]
|
||||
</verb>
|
||||
|
||||
この方法ではエラーチェックをおこないませんので, zmodem
|
||||
などの他のプロトコルを使った方がよいでしょう.
|
||||
|
||||
<sect1>
|
||||
<heading><tt/tip/ から zmodem を実行するには?</heading>
|
||||
<p>
|
||||
ファイルを受信するには, リモート側で送信プログラムを起動します.
|
||||
そして ``<tt/~C rz/'' と入力すると, ローカル側へのファイルの受信が
|
||||
始まります.
|
||||
|
||||
ファイルを送信するには, リモート側で受信プログラムを起動します.
|
||||
そして ``<tt/~C sz <files>/'' と入力すると, リモート側への
|
||||
ファイルの送信が始まります.
|
||||
</sect>
|
||||
@ -1,821 +0,0 @@
|
||||
<!-- $Id: dialup.sgml,v 1.6 1997/02/22 13:00:53 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.17 -->
|
||||
<!-- This is an SGML document in the linuxdoc DTD of the Tutorial for
|
||||
Configuring a FreeBSD for Dialup Services by Guy Helmer.
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//Linux//DTD linuxdoc//EN">
|
||||
|
||||
|
||||
<article>
|
||||
|
||||
<title>
|
||||
FreeBSD でダイアルアップ サービスを行うための設定
|
||||
<author>Guy Helmer, <tt/ghelmer@alpha.dsu.edu/
|
||||
<date>v0.1, 28 March 1995
|
||||
<abstract>
|
||||
|
||||
-->
|
||||
|
||||
<sect><heading>ダイアルインサービス<label id="dialup"></heading>
|
||||
|
||||
<p><em>原作: &a.ghelmer;.</em>
|
||||
<p><em>訳: &a.max;.<newline>6 September 1996.</em>
|
||||
|
||||
このドキュメントでは, FreeBSD で外部からのモデムによるアクセスを受け付
|
||||
けるための設定に関してまとめてあります. このドキュメントは筆者が
|
||||
FreeBSD 1.0, 1.1 および 1.1.5.1 での経験と, 他の UNIX 系 OS での経験を
|
||||
基に書いたものですが, 必ずしも十分な内容でないかもしれませんし, 掲載し
|
||||
た実例もあなたが今お使いの環境とは一致しないかもしれません. また, 筆者
|
||||
はこのドキュメントに従って行われた作業でデータが失われたりシステムが破
|
||||
壊されるようなことがあっても, 一切責任をとれません.
|
||||
|
||||
<sect1><heading>設定を始める前に<label id="dialup:prereqs"></>
|
||||
<p>
|
||||
|
||||
筆者は, 読者が FreeBSD に関する基本的な知識をもっていることを仮定して
|
||||
このドキュメントをまとめました. まず, FreeBSD が既にインストールされ
|
||||
ていて, UNIX 系環境においてファイルの編集の方法やシステムに付属のマニュ
|
||||
アルを参照する方法を知っている必要があります. また, 以下に示すように,
|
||||
FreeBSD の特定のバージョンが必要となりますし, いくつかの用語に関する
|
||||
知識, そしてモデムや多少の配線に関する知識も必要となります.
|
||||
|
||||
<sect2><heading>FreeBSD のバージョン</heading>
|
||||
<p>
|
||||
|
||||
まず, FreeBSD のバージョンは 1.1 以上を使用してください (バージョン
|
||||
2.x でもかまいません. ). FreeBSD 1.0 には, 2種類のシリアル ドライバ
|
||||
が含まれているので, 混乱の元となり得ます. また, FreeBSD のシリアル
|
||||
ディバイス ドライバ (<tt/sio/) は, バージョンを追う毎に改善されてき
|
||||
ていますので, より新しいバージョンの FreeBSD を使用することで, よりよ
|
||||
い, より効率の高いドライバを利用することができるはずです.
|
||||
|
||||
<sect2><heading>用語解説</heading>
|
||||
<p>
|
||||
|
||||
以下, 簡単にいくつかの用語について解説しておきます.
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/bps/ Bits per Second の略で, データの転送速度を表す単位.
|
||||
|
||||
<tag/DTE/ Data Terminal Equipment の略. たとえばコンピュータ本体のこと.
|
||||
|
||||
<tag/DCE/ Data Communications Equipment の略で, 具体的にはモデムのこと.
|
||||
|
||||
<tag/RS-232/ EIA (米電気産業協会) のハードウェア間シリアル通信の標準規
|
||||
格.
|
||||
|
||||
</descrip>
|
||||
|
||||
これらの用語やデータ通信一般に関して, より詳しい情報が必要な場合は,
|
||||
<em/The RS-232 Bible/ という本 (誰か ISBN 分かる方いませんか?) が参考
|
||||
になると思います.
|
||||
|
||||
通信においてのデータ転送速度に関して, このドキュメントでは <bf/ボーレー
|
||||
ト/ (baud rate) ではなく, <bf/bps/ (bits per second) をその単位として
|
||||
使うことにします. これは, ボーというのは一定時間に生じる電気的状態の変
|
||||
化の数を表す単位にすぎず, <bf/bps/ という単位の方が実体に即しているか
|
||||
らです. (少なくとも, こういう表現をしておけば, 意地の悪い人に怒られる
|
||||
こともないのではないかと思います. )
|
||||
|
||||
<sect2><heading>外づけモデムと内蔵モデムについて</heading>
|
||||
<p>
|
||||
|
||||
ダイアルアップのサービスに関していえば, 外づけのモデムの方が適している
|
||||
ようです. これは, 多くの外づけのモデムは設定を不揮発ラムに書き込んで半
|
||||
永久的に保存することができますし, また RS-232 に関する重要な情報を知る
|
||||
ための点滅するライトによるインディケータが搭載されているからです. 点滅
|
||||
するライトは, システムを見に来た訪問者に強い印象を与えるという効果だけ
|
||||
でなく, モデムが適切に動作しているかどうかを知るためにも有効です.
|
||||
|
||||
一方, たいていの内蔵型のモデムには不揮発性ラムが搭載されていないため,
|
||||
ディップ スイッチの変更以外に設定を保存する方法がありません. また, も
|
||||
しインディケータがついていても, おそらくコンピュータのケース カバーが
|
||||
外されていなければその状態を確認するのは難しいでしょう.
|
||||
|
||||
<sect2><heading>モデムとケーブル</heading>
|
||||
<p>
|
||||
|
||||
以下のことに関して, 予め知っておく必要があります.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> コンピュータとモデムの間での通信が行えるようにするための接続方
|
||||
法. (内蔵型の場合は接続の必要はありません)
|
||||
|
||||
<item> お使いのモデムのコマンドについての知識, あるいはコマンドの解説
|
||||
の在処
|
||||
|
||||
<item> (通信ソフトを使っての) モデムの不揮発ラムに保存可能な設定の変更
|
||||
方法
|
||||
|
||||
</itemize>
|
||||
|
||||
1番目のモデムの接続はたいてい簡単に行えるはずです. ほとんどのストレー
|
||||
ト シリアル ケーブルが使えるでしょう. 使用すべきケーブルは, 両端に適
|
||||
切なコネクタ (DB-25 または DB-9 の雄または雌) のついた, DCE-DTE 間接
|
||||
続用のもので, 以下の信号線が接続されていなければなりません.
|
||||
|
||||
<itemize>
|
||||
<item> Transmitted Data (<tt/SD/)
|
||||
<item> Received Data (<tt/RD/)
|
||||
<item> Request to Send (<tt/RTS/)
|
||||
<item> Clear to Send (<tt/CTS/)
|
||||
<item> Data Set Ready (<tt/DSR/)
|
||||
<item> Data Terminal Ready (<tt/DTR/)
|
||||
<item> Carrier Detect (<tt/CD/)
|
||||
<item> Signal Ground (<tt/SG/)
|
||||
</itemize>
|
||||
|
||||
FreeBSD で 2400bps 以上の転送速度を利用する場合には, フロー制御のため
|
||||
に <tt/RTS/ 信号と <tt/CTS/ 信号が必要です. また, 接続の確立と回線の切
|
||||
断を検出するために <tt/CD/ 信号を利用します. さらに, <tt/DTR/ 信号を使っ
|
||||
て回線切断後のモデムのリセットを行います. ケーブルの中には, 総ての必要
|
||||
な信号線が接続されていないものもありますので, たとえば, 回線切断後でも
|
||||
ログイン セッションが残ってしまうといった問題が発生した場合などには,
|
||||
ケーブルに問題がある可能性もあります.
|
||||
|
||||
次に, お使いのモデムにもよりますが, もしモデムのコマンドをよく覚えてい
|
||||
ない場合は, モデムのマニュアルをすぐに参照できるようにしておいてくださ
|
||||
い. このドキュメントでは例として USR Sportstar の 14,400 bps の外づけ型
|
||||
モデムのコマンドを示しておきます. 他の種類のモデムをお使いの場合も, 参
|
||||
考になるかもしれません.
|
||||
|
||||
最後に, FreeBSDで快適にモデムを使うためにも, モデムの設定方法を知って
|
||||
おく必要があります. FreeBSD も他の UNIX 系 OS と同様, 回線の接続およ
|
||||
び切断の検出や回線の切断および回線切断後のモデムの初期化にハードウェア
|
||||
シグナルを利用します. FreeBSD は, モデムに対するコマンドの送信やモデ
|
||||
ムの状態の監視を行いません. パソコンで運用されている BBS への接続に慣
|
||||
れている方にとっては, ちょっとめんどうかもしれませんね.
|
||||
|
||||
<sect2><heading>シリアル インタフェースについて</heading>
|
||||
<p>
|
||||
|
||||
FreeBSD では, NS8250-, NS16450-, NS16550- および NS16550A- に基づ
|
||||
いた EIA RS-232C (CCITT V.24) 規格のシリアル インタフェースをサポート
|
||||
しています. 8250 および 16450 ベースのディバイスには1文字のキャラクタ
|
||||
バッファが搭載されています. また, 16550 系のディバイスには, 16文字分
|
||||
のバッファが搭載されていて, はるかによいパフォーマンスを得られます.
|
||||
(ただし, 無印の 16550 では, バグがあって 16 文字バッファが利用できませ
|
||||
んので, 可能であれば 16550A 系のディバイスを利用してください. ) 1文字
|
||||
のバッファの物は, 16550 系のものと比べて OS にかける負荷が大きいので,
|
||||
16550A 系ディバイスの利用を強く推奨します. 多数のシリアル ポートを利
|
||||
用する場合や, 負荷の高いシステムにおいては, 16550A 系ディバイスを使う
|
||||
ことで, エラー発生率を低く押さえることができます.
|
||||
|
||||
<sect1><heading>概要</heading>
|
||||
<p>
|
||||
|
||||
FreeBSD は以下の手順でモデムからのログインを受付ます. <tt/init/ から起
|
||||
動された <tt/getty/ のプロセスが, 割り当てられたシリアル ポート (この
|
||||
例では <tt>/dev/ttyd0</tt>) がオープンされるのを辛抱強く待ちます.
|
||||
<tt/ps ax/ コマンドを実行すると, 以下のような出力が得られるはずです.
|
||||
|
||||
<tscreen><verb>
|
||||
4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0
|
||||
</verb></tscreen>
|
||||
|
||||
ユーザがモデムに電話をかけ, モデム同士が接続されると, モデムの <tt/CD/
|
||||
が検出されます. その結果, kernel がキャリア信号を検出して,
|
||||
<tt/getty/ によるポートのオープンの処理が終了します. <tt/getty/ は,
|
||||
<tt/login:/ プロンプトを指定されている初期回線速度で送信します.
|
||||
<tt/getty/ は, 正常に文字列を受信できるかどうか監視し, 通常の設定では,
|
||||
もし以上な文字列を検出した場合 (理由としては, <tt/getty/ の速度とモデ
|
||||
ムの接続速度が異なっているような場合が考えられます. ), 正常に文字列が
|
||||
受信できるまで, <tt/getty/ は速度を変え続けます.
|
||||
|
||||
<tt/getty/ が正しい速度を検出すれば, ユーザに対して <tt/login:/ プロン
|
||||
プトが表示されるはずです. ユーザがログイン名を入力すると, <tt/getty/
|
||||
は <tt>/usr/bin/login</tt> を起動して, パスワードの入力を要求し, その
|
||||
後ユーザのシェルを起動します.
|
||||
|
||||
それでは, 続いて設定についての解説です.
|
||||
|
||||
<sect1><heading>Kernel の設定</heading>
|
||||
<p>
|
||||
|
||||
通常, FreeBSD の kernel は, PC-DOS の世界で <tt/COM1:/, <tt/COM2:/
|
||||
, <tt/COM3:/ および <tt/COM4:/ と呼ばれる四つのシリアル ポートを探す
|
||||
ように設定されています. また, FreeBSD では, 現在のところ Boca の 1008
|
||||
や 2016 のような, 単純なマルチポートのシリアル インタフェースもサポー
|
||||
トしています. (マルチポートのシリアル ボードに関しての kernel の設定
|
||||
については, <tt/sio(4)/ のマニュアルを参照してください. ) デフォルト
|
||||
の kernel は, COM ポートだけを探します.
|
||||
|
||||
搭載されているシリアル ポートのいずれかを, kernel が認識しているかどう
|
||||
か確認したい場合は, kernel 起動時のメッセージを注意深く見ているか, あ
|
||||
るいは <tt>/sbin/dmesg</tt> コマンドを使って, ブート時の出力メッセージ
|
||||
を確認してください. 特に, <tt/sio/ で始まるメッセージをよく見てくださ
|
||||
い. 参考までに, 以下のコマンドで <tt/sio/ という文字列を含むメッセージ
|
||||
だけを表示することができます.
|
||||
|
||||
<tscreen><verb>
|
||||
/sbin/dmesg | grep 'sio'
|
||||
</verb></tscreen>
|
||||
|
||||
たとえば, シリアル ポートを四つ持つシステムの場合は, 以下のようなシリ
|
||||
アル ポートに関するメッセージが kernel によって表示されます.
|
||||
|
||||
<tscreen><verb>
|
||||
sio0 at 0x3f8-0x3ff irq 4 on isa
|
||||
sio0: type 16550A
|
||||
sio1 at 0x2f8-0x2ff irq 3 on isa
|
||||
sio1: type 16550A
|
||||
sio2 at 0x3e8-0x3ef irq 5 on isa
|
||||
sio2: type 16550A
|
||||
sio3 at 0x2e8-0x2ef irq 9 on isa
|
||||
sio3: type 16550A
|
||||
</verb></tscreen>
|
||||
|
||||
もし, kernel に正常に認識されないポートがある場合は, おそらくカスタマ
|
||||
イズした kernel を構築する必要があるでしょう.
|
||||
|
||||
kernel 構築と構築のための設定に関しては, BSD System Manager's Manual
|
||||
の ``Building Berkeley Kernels with Config (config コマンドによる BSD
|
||||
kernel の構築) '' [ソース ファイルは
|
||||
<tt>/usr/src/share/doc/smm</tt> にあります]と ``FreeBSD
|
||||
Configuration Options'' [ <tt>/sys/conf/options</tt> および
|
||||
<tt>/sys/<em>arch</em>/conf/options.<em>arch</em></tt> の
|
||||
<em>arch</em>の部分をたとえば<tt>i386</tt>としたファイル ] を参照
|
||||
してください.
|
||||
|
||||
kernel の設定と構築をするためには, kernel のソース
|
||||
(FreeBSD 1.1 では <tt>srcdist/srcsys.??</tt>, FreeBSD 1.1.5.1 では
|
||||
<tt>srcdist/sys.??</tt>, またFreeBSD 2.0 では総てのソース)を展開
|
||||
する必要があります.
|
||||
|
||||
まだ自分のシステムの kernel 用のコンフィギュレーション ファイルを作っ
|
||||
ていない場合は, <tt>/sys/i386/conf</tt> に <tt/cd/ して作成してくださ
|
||||
い. 初めてコンフィギュレーション ファイルを作る場合は, まず GENRICAH
|
||||
(FreeBSD 1.x で BusTek の SCSI コントローラを使っている場合は
|
||||
GENERICBT) というファイルを, <em/YOURSYS/ にコピーしてください. ここ
|
||||
で, <em/YOURSYS/ はあなたのシステム名で, 大文字である必要があります.
|
||||
このファイルを編集して, ディバイスに関する記述を変更します.
|
||||
|
||||
<tscreen><verb>
|
||||
device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
|
||||
device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
|
||||
device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr
|
||||
device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr
|
||||
</verb></tscreen>
|
||||
|
||||
システムに搭載されていないディバイスに関する記述は, コメントアウトまた
|
||||
は削除してしまってかまいません. Boca の BB2016 のようなマルチポートの
|
||||
シリアル ボードをお持ちの場合は, <tt/sio(4)/ のマニュアルを見て, マ
|
||||
ルチポートのボードのためのコンフィギュレーション ファイルの記述のし方
|
||||
に関して確認してください. ディバイスのフラグの指定方法がバージョンによっ
|
||||
て異なりますので, 別のバージョンの FreeBSD で利用していたコンフィギュ
|
||||
レーション ファイルを流用する場合には十分注意してください.
|
||||
|
||||
なお, <tt/port "IO_COM1"/, <tt/"IO_COM2"/, <tt/"IO_COM3"/ および
|
||||
<tt/"IO_COM4"/ は, それぞれのポートの一般的なアドレスである <tt/0x3f8/,
|
||||
|
||||
<tt/0x2f8/, <tt/0x3e8/ および <tt/0x2e8/ を表します. また, 割り込
|
||||
み番号 4, 3, 5 と 9 は, それぞれ <tt/COM1:/ から <tt/COM4:/ のポー
|
||||
トで一般的に使用される IRQ です. また, ISA バスのコンピュータの場合,
|
||||
一般的なシリアルポートは複数のポートで一つの IRQ を共有することが <bf>
|
||||
できません</bf>ので注意が必要です. (マルチポートのシリアル ボードの
|
||||
場合は, 複数の 16550A ベースのポートで一つまたは二つの IRQ を共有する
|
||||
ための機構を備えています. )
|
||||
|
||||
コンフィギュレーション ファイルの編集が終わったら, ``Building
|
||||
Berkeley Kernels with Config (config コマンドによる BSD kernel の構築)''
|
||||
および <tt/config(8)/ のマニュアルにしたがって, <tt/config/ コマンド
|
||||
を使って kernel 構築のためのディレクトリを作成した後, kernel の構築,
|
||||
インストールおよびテストを行ってください.
|
||||
|
||||
<sect1><heading>ディバイス スペシャル ファイル</heading>
|
||||
<p>
|
||||
|
||||
kernel に組み込まれているほとんどのディバイスは, <tt>/dev</tt> ディレ
|
||||
クトリにある, 「ディバイス スペシャル ファイル」を介してアクセスされ
|
||||
ます. <tt/sio/ ディバイスの場合は, 着信用の <tt>/dev/ttyd?</tt> およ
|
||||
び, 発信用の <tt>/dev/cua0?</tt> が利用されます. さらに, FreeBSD の
|
||||
1.1.5 以降では, 初期化ディバイス (<tt>/dev/ttyi?</tt> と
|
||||
<tt>/dev/cuai0?</tt>)およびロッキング ディバイス (<tt>/dev/ttyld?</tt> と
|
||||
<tt>/dev/cual0?</tt>) も合わせて利用されます. 初期化ディバイスは, 通信
|
||||
ポートがオープンされる度に, そのポートの初期設定を行うために使われます.
|
||||
たとえば, <tt>CTS/RTS</tt> によるフロー制御を行うモデムが接続されてい
|
||||
る場合の <tt/crtscts/ などのパラメータの初期化が行われます. ロッキング
|
||||
ディバイスは, ポートの設定をロックし, 他のユーザやプログラムにこれらを
|
||||
変更されることのないようにするために利用されます. 通信ポートの設定, 初
|
||||
期化とロックおよび設定の変更に関しては, それぞれ <tt/termios(4)/,
|
||||
<tt/sio(4)/ と <tt/stty(1)/ のマニュアルをご覧ください.
|
||||
|
||||
<sect2><heading>ディバイス スペシャル ファイルの作成</heading>
|
||||
<p>
|
||||
|
||||
ディバイス スペシャル ファイルの管理は, ディレクトリ <tt>/dev</tt>
|
||||
にあるシェル スクリプト <tt/MAKEDEV/ によって行います. (FreeBSD
|
||||
1.1.5 の <tt/MAKEDEV(8)/ のマニュアルの <tt/COM/ ポートに関する記述は,
|
||||
かなりいい加減なので無視してください. ) <tt/MAKEDEV/ を使って,
|
||||
<tt/COM1:/ (ポート 0) をダイアルアップのポートとして利用するためのディ
|
||||
バイス スペシャル ファイルを作るには, <tt>/dev</tt> に <tt/cd/ して
|
||||
から, <tt/MAKEDEV ttyd0/ と実行してください. 同様に, <tt/MAKEDEV
|
||||
ttyd1/ とすることで, <tt/COM2:/ (ポート 1) 用のディバイス スペシャル ファイル
|
||||
を作成することができます.
|
||||
|
||||
<tt/MAKEDEV/ は, <tt>/dev/ttyd?</tt> のディバイス ファイルだけでなく,
|
||||
<tt>/dev/cua0?</tt> (および FreeBSD 1.1.5 以降では総ての初期化ディバイ
|
||||
スとロッキング ディバイスのスペシャル ファイル) も作成します. さらに,
|
||||
もしシリアル端末用のスペシャル ファイル<tt>/dev/tty0?</tt> が存在すれ
|
||||
ば, それらの削除も行います.
|
||||
|
||||
ディバイス スペシャル ファイルの作成後, これらのファイルのパーミション
|
||||
が適切に設定されていて, これらのディバイスを利用してもよいユーザのみが
|
||||
読み書きできるようになっていることを確認してください. (特に
|
||||
<tt>/dev/cua*</tt> のパーミションには注意を払ってください. ) この確認
|
||||
を怠ると, 一般のユーザがあなたのモデムを使うことができるようなことにな
|
||||
りかねません. デフォルトの <tt>/dev/cua*</tt> のパーミションは, 以下の
|
||||
ようになっていて, たいていの場合適切なものだと思います.
|
||||
|
||||
<tscreen><verb>
|
||||
crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01
|
||||
crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01
|
||||
crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01
|
||||
</verb></tscreen>
|
||||
|
||||
上の設定では, ユーザ <tt/uucp/ と, グループ <tt/dialer/ に属するユーザ
|
||||
が発信用のディバイスを利用できます.
|
||||
|
||||
<sect1><heading>設定ファイル</heading>
|
||||
<p>
|
||||
|
||||
FreeBSD のシステムへのダイアル アップによるアクセスを実現するために編
|
||||
集が必要と思われる設定ファイルが, <tt>/etc</tt> ディレクトリに三つあ
|
||||
ります. まず, <tt>/etc/gettytab</tt> には,
|
||||
<tt>/usr/libexec/getty</tt> デーモンの設定を記述します. つぎに,
|
||||
<tt>/etc/ttys</tt> に保存されている情報から, <tt>/sbin/init</tt> はど
|
||||
の <tt/tty/ ディバイスに対して <tt/getty/ のプロセスを実行するべきか判
|
||||
断します. 最後に, お使いの FreeBSD が 1.1.5.1 以降のものならば
|
||||
<tt>/etc/rc.serial</tt> スクリプトに, それ以前のものならば
|
||||
<tt>/etc/rc.local</tt> スクリプトにシリアル ポートの初期化のためのコマ
|
||||
ンドを記述することができます.
|
||||
|
||||
UNIX にダイアル アップ モデムを接続する方法には, 二つの考え方がありま
|
||||
す. 一つの方法は, ダイアル インしてくるユーザの接続速度に関係なく, 常
|
||||
にモデムとローカルのコンピュータの RS-232 インタフェースの接続速度を一
|
||||
定に保つように設定する方法です. この設定の長所は, ユーザがダイアル イ
|
||||
ンして接続されると, 即座にシステムからのログイン プロンプトが送信され
|
||||
るということです. 短所は, システムが実際のモデム間の速度を知ることがで
|
||||
きないために, Emacs のようなフル スクリーンのプログラムが, 端末との接
|
||||
続速度が遅い場合でも, そのような場合に効果的な方法で画面出力を行わない
|
||||
点です.
|
||||
|
||||
もう一つは, モデムの RS-232 インタフェースとコンピュータの接続速度を,
|
||||
モデム間の接続速度に応じて変化させるような設定です. たとえば, モデム間
|
||||
の接続が V.32bis (14.4 Kbps) ならば, モデムとコンピュータの間の接続を
|
||||
19.2 Kbps とし, モデム間の接続が 2400 bps の時には, モデムとコンピュー
|
||||
タ間も 2400 bps で接続するような設定をします. この場合, <tt/getty/ は,
|
||||
モデムが返すリザルト コードからモデムとコンピュータの接続速度を認識す
|
||||
ることができませんので, <tt/getty/ は, まず初期速度で <tt/login:/ とい
|
||||
う文字列を送信して, それに対する応答の文字列を監視します. ここで, ユー
|
||||
ザ側の端末に無意味な文字列が表示された場合, ユーザは意味のある文字列を
|
||||
受信するまで <tt><Enter></tt> キーを繰り返し押さなければならない
|
||||
ということを知っていると仮定しています. もし接続速度が間違っている場合,
|
||||
<tt/getty/ は, ユーザから送られた文字を無意味な文字列として扱い, 次の
|
||||
速度を試します. そして, ここで再度 <tt/login:/ プロンプトを送信します.
|
||||
この一連の動作が異常な回数繰り返されることも考えられますが, 普通は1度
|
||||
か2度のキー入力があれば, ユーザはまともなプロンプトを受信できます. こ
|
||||
のログインの動作が前者の固定速度による方法に比べて美しくないのは明らか
|
||||
ですが, この方法では, 低速度で接続しているユーザに対するフル スクリー
|
||||
ンのプログラムからのレスポンスが改善されます.
|
||||
|
||||
このドキュメントでは, 両方の設定方法について解説しますが, どちらかとい
|
||||
うとモデム間の速度に応じて RS-232 インタフェースの速度が変化するような
|
||||
設定の方に偏った説明になってしまうと思います.
|
||||
|
||||
<sect2><heading>/etc/gettytab</heading>
|
||||
<p>
|
||||
|
||||
<tt>/etc/gettytab</tt> は, <tt/getty(8)/ の設定ファイルで,
|
||||
<tt/termcap(5)/ と同様の形式で記述されます. ファイルのフォーマットや定
|
||||
義できる機能についての詳細については, <tt/gettytab(4)/ のマニュアルを
|
||||
ご覧ください.
|
||||
|
||||
<sect3><heading>固定速度の設定</heading>
|
||||
<p>
|
||||
|
||||
モデムとコンピュータ間の通信速度を固定して使う場合, おそらく
|
||||
<tt>/etc/gettytab</tt> に特に変更を加える必要はないはずです.
|
||||
|
||||
<sect3><heading>可変速度の設定</heading>
|
||||
<p>
|
||||
|
||||
<tt/getty/ が利用するモデムとコンピュータの接続速度に関する情報を
|
||||
<tt>/etc/gettytab</tt> に記述する必要があります. もし, 2400 bps のモ
|
||||
デムをお使いになるのであれば, 既存の <tt/D2400/ のエントリがそのまま利
|
||||
用できるでしょう. このエントリは FreeBSD の 1.1.5.1 の <tt/gettytab/
|
||||
には既に含まれていますので, あなたの FreeBSD のバージョンでこのエント
|
||||
リが存在しているのであれば, 新たに追加する必要はありません.
|
||||
|
||||
<tscreen><verb>
|
||||
#
|
||||
# Fast dialup terminals, 2400/1200/300 rotary (can start either way)
|
||||
#
|
||||
D2400|d2400|Fast-Dial-2400:\
|
||||
:nx=D1200:tc=2400-baud:
|
||||
3|D1200|Fast-Dial-1200:\
|
||||
:nx=D300:tc=1200-baud:
|
||||
5|D300|Fast-Dial-300:\
|
||||
:nx=D2400:tc=300-baud:
|
||||
</verb></tscreen>
|
||||
|
||||
高速モデムをお使いの場合は, おそらく <tt>/etc/gettytab</tt> に新たなエ
|
||||
ントリを追加する必要があります. 以下の例は, 14.4 Kbps のモデムを, 最
|
||||
大インタフェース速度を 19.2 Kbps として利用するためのエントリです.
|
||||
|
||||
<tscreen><verb>
|
||||
#
|
||||
# Additions for a V.32bis Modem
|
||||
#
|
||||
um|V300|High Speed Modem at 300,8-bit:\
|
||||
:nx=V19200:tc=std.300:
|
||||
un|V1200|High Speed Modem at 1200,8-bit:\
|
||||
:nx=V300:tc=std.1200:
|
||||
uo|V2400|High Speed Modem at 2400,8-bit:\
|
||||
:nx=V1200:tc=std.2400:
|
||||
up|V9600|High Speed Modem at 9600,8-bit:\
|
||||
:nx=V2400:tc=std.9600:
|
||||
uq|V19200|High Speed Modem at 19200,8-bit:\
|
||||
:nx=V9600:tc=std.19200:
|
||||
</verb></tscreen>
|
||||
|
||||
上記の例を利用した場合, FreeBSD 1.1.5 以降ではパリティなし, 8ビットの
|
||||
接続が行われます. FreeBSD 1.1 では, <tt/:np:/ パラメータをファイルの
|
||||
先頭の <tt/std.<em/xxx/</tt> のエントリに追加することで, パリティなし,
|
||||
8ビットの接続が行われますが, このパラメータを追加しなければ接続は偶数
|
||||
パリティ, 7ビットになります.
|
||||
|
||||
上記の例では, まず 19.2 Kbps (V.32bis) によるモデムとコンピュータ間の
|
||||
接続を試み, 続いて 9600 bps (V.32), 2400 bps, 1200 bps, 300 bpsと順に
|
||||
試み, 再び 19.2 Kbps による接続を試みるという循環に入ります. この接続
|
||||
速度の循環は, <tt/nx=/(<bf/next table/) の機能で実現されています. ま
|
||||
た, 各行はそれぞれ <tt/tc=/(<bf/table continuation/) の機能を使って,
|
||||
その他の接続速度に依存した「標準的な」設定を取り込んでいます.
|
||||
|
||||
もし, お使いのモデムが 28.8 Kbps であったり, 14.4 Kbps の圧縮転送の機
|
||||
能を有効に利用したい場合は, 19.2 Kbps よりも速い速度を利用するように
|
||||
設定する必要があります. 以下に 57.6 Kbps から接続を試みる
|
||||
<tt/gettytab/ の設定例を示しておきます.
|
||||
|
||||
<tscreen><verb>
|
||||
#
|
||||
# Additions for a V.32bis or V.34 Modem
|
||||
# Starting at 57.6 Kbps
|
||||
#
|
||||
vm|VH300|Very High Speed Modem at 300,8-bit:\
|
||||
:nx=VH57600:tc=std.300:
|
||||
vn|VH1200|Very High Speed Modem at 1200,8-bit:\
|
||||
:nx=VH300:tc=std.1200:
|
||||
vo|VH2400|Very High Speed Modem at 2400,8-bit:\
|
||||
:nx=VH1200:tc=std.2400:
|
||||
vp|VH9600|Very High Speed Modem at 9600,8-bit:\
|
||||
:nx=VH2400:tc=std.9600:
|
||||
vq|VH57600|Very High Speed Modem at 57600,8-bit:\
|
||||
:nx=VH9600:tc=std.57600:
|
||||
</verb></tscreen>
|
||||
|
||||
もし, お使いの CPU が低速のものであったり, CPU に対する負荷が高い場合
|
||||
で, 16650A 系のシリアル ポートをお使いでない場合, 57.6 Kbps の接続に
|
||||
おいて, sio の ``slio'' エラーが発生するかもしれません.
|
||||
|
||||
<sect2><heading>/etc/ttys<label id="dialup:ttys"></heading>
|
||||
<p>
|
||||
|
||||
<tt>/etc/ttys</tt> には, <tt/init/ が監視すべき <tt/tty/ のリストを記
|
||||
述します. さらに, <tt>/etc/ttys</tt> は, <tt/login/ に対してセキュリ
|
||||
ティに関する情報を提供します. (ユーザ <tt/root/ は, <tt/secure/ とマー
|
||||
クされている <tt/tty/ のみからログインできます. ) 詳しくは
|
||||
<tt/ttys(5)/ のマニュアルをご覧ください.
|
||||
|
||||
<tt>/etc/ttys</tt> の既存の行を変更するか, あるいは新しい行を追加して,
|
||||
<tt/init/ が自動的に新しいダイアル アップ サービス用のポートに対して
|
||||
<tt/getty/ プロセスを起動するようにしてください. 書式は, 固定速度の設
|
||||
定か可変速度の設定かに関わらず, 以下のとおりです.
|
||||
|
||||
<tscreen><verb>
|
||||
ttyd0 "/usr/libexec/getty xxx" dialup on
|
||||
</verb></tscreen>
|
||||
|
||||
1番目の項目は, このエントリで対象とするディバイス スペシャル ファイル
|
||||
です. 上の例では <tt/ttyd0/ として, <tt>/dev/ttyd0</tt> を <tt/getty/
|
||||
に監視させることを表しています. 2番目の項目 <tt>"/usr/libexec/getty
|
||||
<em/xxx/"</tt> (<em/xxx/ は初期段階で使われる <tt/gettytab/ のエントリ
|
||||
に置き換えてください. ) が, <tt/init/ がこのディバイスに対して起動する
|
||||
プロセスです. 3番目の <tt/dialup/ は, デフォルトのターミナル タイプで
|
||||
す. 4番目の <tt/on/ は, この行が有効であることを <tt/init/ に対して示
|
||||
しています. 5番目の項目に <tt/secure/ を指定することもできますが, これ
|
||||
は, たとえばシステムのコンソールのように, 物理的に安全な端末に対しての
|
||||
み指定するようにしてください.
|
||||
|
||||
デフォルトのターミナル タイプ (上記の例では <tt/dialup/) は, ローカル
|
||||
のユーザの好みによって異なってきます. ユーザがログイン スクリプトをカ
|
||||
スタマイズして, ターミナル タイプが <tt/dialup/ の時には自動的に他のター
|
||||
ミナル タイプを設定できるように, ダイアル アップのポートのデフォルトの
|
||||
ターミナル タイプには <tt/dialup/ が伝統的に用いられています. しかし,
|
||||
筆者のサイトでは, ほとんどのユーザが VT102 エミュレイションを使ってい
|
||||
るので, ダイアル アップのポートのデフォルト ターミナル タイプとして
|
||||
<tt/vt102/ を指定しています.
|
||||
|
||||
<tt>/etc/ttys</tt> の修正がすんだら, 以下のようなコマンドを使って
|
||||
<tt/init/ プロセスに <tt/HUP/ シグナルを送り, <tt>/etc/ttys</tt> を
|
||||
読み込み直させてください.
|
||||
|
||||
<tscreen><verb>
|
||||
kill -1 1
|
||||
</verb></tscreen>
|
||||
|
||||
ただ, もし初めてシステムを設定しているのであれば, モデムが適切に設定さ
|
||||
れて接続されるまでは, <tt/init/ に対してシグナルを送らない方がいいか
|
||||
もしれません.
|
||||
|
||||
<sect3><heading>固定速度の設定</heading>
|
||||
<p>
|
||||
|
||||
速度を固定する設定では, <tt>/etc/ttys</tt> の中で, <tt/getty/ に対し
|
||||
て固定速度のエントリを指定する必要があります. たとえば, 以下の例はポー
|
||||
トのスピードが 19.2 Kbps に固定されたモデムのための <tt/ttys/ のエント
|
||||
リです.
|
||||
|
||||
<tscreen><verb>
|
||||
ttyd0 "/usr/libexec/getty std.19200" dialup on
|
||||
</verb></tscreen>
|
||||
|
||||
別の速度でモデムのポートのスピードを固定したい場合は,
|
||||
<tt>/etc/gettytab</tt> から適切なエントリを選んで, 上の例の
|
||||
<tt/std.19200/ の部分を <tt>std.<em/speed/</tt> として, 適切な速度のも
|
||||
のに置き換えてください.
|
||||
|
||||
<sect3><heading>可変速度の設定</heading>
|
||||
<p>
|
||||
|
||||
可変速度の設定では, <tt/ttys/ のエントリが, <tt>/etc/gettytab</tt>
|
||||
の中の適切な「自動速度調整」の初期設定のエントリを参照していなければな
|
||||
りません. たとえば, もし前述の 19.2 Kbps から接続を試みる可変速度の設
|
||||
定例 (<tt/V19200/ の <tt/gettytab/ エントリ)をそのまま <tt/ttys/ に追
|
||||
加したのであれば, <tt/ttys/ エントリは以下のようになります.
|
||||
|
||||
<tscreen><verb>
|
||||
ttyd0 "/usr/libexec/getty V19200" dialup on
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>/etc/rc.serial または /etc/rc.local</heading>
|
||||
<p>
|
||||
|
||||
V.32, V.32bis または V.34 モデムのような高速モデムを利用する場合, ハー
|
||||
ドウェア (<tt>RTS/CTS</tt>) フロー制御を行う必要があります. FreeBSD
|
||||
kernel のモデム ポートにハードウェア フロー制御のフラグを設定するため
|
||||
の <tt/stty/ コマンドを, FreeBSD 1.1.5.1 以降では
|
||||
<tt>/etc/rc.serial</tt> に, FreeBSD 1.1 では <tt>/etc/rc.local</tt> に
|
||||
記述できます.
|
||||
|
||||
たとえば, FreeBSD 1.1.5.1 の <tt>/etc/rc.serial</tt> のサンプルは以下
|
||||
のとおりです.
|
||||
|
||||
<tscreen><verb>
|
||||
#!/bin/sh
|
||||
#
|
||||
# Serial port initial configuration
|
||||
|
||||
stty -f /dev/ttyid1 crtscts
|
||||
stty -f /dev/cuai01 crtscts
|
||||
</verb></tscreen>
|
||||
|
||||
この例では, <tt/termio/ のフラグ <tt/crtscts/ をシリアル ポート #1
|
||||
(<tt/com2:/) のダイアル インおよびダイアル アウトの初期化ディバイスに
|
||||
設定しています.
|
||||
|
||||
古い FreeBSD 1.1 では, 以下のエントリが <tt/crtscts/ フラグを設定する
|
||||
ために <tt>/etc/rc.local</tt> に追加されていました.
|
||||
|
||||
<tscreen><verb>
|
||||
# Set serial ports to use RTS/CTS flow control
|
||||
stty -f /dev/ttyd0 crtscts
|
||||
stty -f /dev/ttyd1 crtscts
|
||||
stty -f /dev/ttyd2 crtscts
|
||||
stty -f /dev/ttyd3 crtscts
|
||||
</verb></tscreen>
|
||||
|
||||
FreeBSD 1.1 には初期化のためのディバイス スペシャル ファイルがないので,
|
||||
ディバイス ファイルそのものにフラグを設定して, その後はフラグをクリア
|
||||
してしまうような極悪人が現れないことを願うしかありません.
|
||||
|
||||
<sect1><heading>モデムの設定</heading>
|
||||
<p>
|
||||
|
||||
もし, あなたのモデムがパラメータを不揮発ラムに保存できるタイプならば,
|
||||
PC-DOS 上の Telix や FreeBSD 上の <tt/tip/ などのような通信プログラム
|
||||
を使って, パラメータを設定してください.
|
||||
<tt/getty/ が利用する初期速度でモデムに接続して, 以下の条件を満たすよ
|
||||
うに不揮発ラムの設定を変更してください.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> 接続時に <tt/CD/ 信号がオンになる
|
||||
|
||||
<item> 接続時に <tt/DTR/ がオンになり, <tt/DTR/ オフで回線を切断しモ
|
||||
デムをリセットする.
|
||||
|
||||
<item> 送信時フロー制御には <tt/CTS/ を利用.
|
||||
|
||||
<item> <tt>XON/XOFF</tt> によるフロー制御を行わない.
|
||||
|
||||
<item> 受信時のフロー制御は <tt/RTS/ を使用.
|
||||
|
||||
<item> Quiet mode (リザルト コードを返さない)
|
||||
|
||||
<item> コマンド エコーを返さない.
|
||||
|
||||
</itemize>
|
||||
|
||||
これらを実現するためのコマンドやディップ スイッチの設定に関しては, モ
|
||||
デムのマニュアルを参照してください.
|
||||
|
||||
以下に, USRobotics Sportster の 14,400 bps の外づけモデムの設定例を示
|
||||
しておきます.
|
||||
|
||||
<tscreen><verb>
|
||||
ATZ
|
||||
AT&C1&D2&H1&I0&R2&W
|
||||
</verb></tscreen>
|
||||
|
||||
ことのついでに, たとえば, V42.bis や MNP5 のデータ圧縮を使用するかど
|
||||
うかなどのモデムの他の設定について確認, 調整しておくのもよいかもしれま
|
||||
せん.
|
||||
|
||||
さらに, USRobotics Sportster の 14,400 bps の外づけモデムでは, 以下の
|
||||
ようなディップ スイッチの設定も必要です. 他のモデムをお使いの方も, 以
|
||||
下の例を設定の参考にしてください.
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> スイッチ1: UP - DTR 標準
|
||||
|
||||
<item> スイッチ2: 無視 (リザルト コードを単語形式にするか数値形式にす
|
||||
るか)
|
||||
|
||||
<item> スイッチ3: UP - リザルト コードを返さない
|
||||
|
||||
<item> スイッチ4: DOWN - コマンド エコーを返さない
|
||||
|
||||
<item> スイッチ5: UP - 自動着信
|
||||
|
||||
<item> スイッチ6: UP - CD 標準
|
||||
|
||||
<item> スイッチ7: UP - 不揮発ラムからデフォルト値をロードする
|
||||
|
||||
<item> スイッチ8: 無視 (Smart Mode/Dumb Mode)
|
||||
|
||||
</itemize>
|
||||
|
||||
リザルト コードを返さないように設定しておかないと, <tt/getty/ が誤っ
|
||||
て <tt/login:/ プロンプトをコマンド モードのモデムに送信してしまった場
|
||||
合に, モデムがこの入力をエコーしたり, この入力に対するリザルト コード
|
||||
を返してしまったりすることになります. この結果として, モデムと
|
||||
<tt/getty/ の間で延々と無意味なやりとりが続いたというケースを聞いたこ
|
||||
とがあります.
|
||||
|
||||
<sect2><heading>固定速度の設定</heading>
|
||||
<p>
|
||||
|
||||
固定速度の設定では, モデムとコンピュータ間の通信速度をモデムとモデム間
|
||||
の接続速度に関係なく, 常に一定に保つように, モデムを設定する必要があり
|
||||
ます. USRobotics Sportster の 14,400 bps 外づけモデムの場合, 以下のコ
|
||||
マンドで, モデムとコンピュータ間の速度が, コマンド送信時の速度に固定さ
|
||||
れます.
|
||||
|
||||
<tscreen><verb>
|
||||
ATZ
|
||||
AT&B1&W
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>可変速度の設定</heading>
|
||||
<p>
|
||||
|
||||
可変速度の設定では, シリアル ポートの速度が, 着信速度に応じて変化する
|
||||
ように設定しなければいけません. USRobotics Sporster の 14,400 bps 外
|
||||
づけモデムの場合, 以下のコマンドで, エラー訂正機能を利用した通信の場合
|
||||
は, コマンドを送信した時の通信速度にシリアル ポートの速度を固定し, エ
|
||||
ラー訂正機能を利用しない接続では, シリアル ポートの速度が変化するよう
|
||||
に設定されます.
|
||||
|
||||
<tscreen><verb>
|
||||
ATZ
|
||||
AT&B2&W
|
||||
</verb></tscreen>
|
||||
|
||||
<sect2><heading>モデムの設定の確認</heading>
|
||||
<p>
|
||||
|
||||
ほとんどの高速モデムには, 現在の設定をある程度人間にも理解できる形式に
|
||||
して表示させるコマンドがあります. USRobotics Sporster の 14,400 bps
|
||||
外づけモデムの場合は, <tt/ATI5/ コマンドで, 現在の不揮発ラムの設定を
|
||||
表示することができます. さらに, ディップ スイッチの設定も含めた現在の
|
||||
設定を確認するためには, <tt/ATZ/ コマンドを送信してから, <tt/ATI4/
|
||||
コマンドを送信してください.
|
||||
|
||||
他のメーカーのモデムをお使いの場合は, モデムのマニュアルで設定値の確認
|
||||
方法を確認してください.
|
||||
|
||||
<sect1><heading>トラブルシューティング</heading>
|
||||
<p>
|
||||
|
||||
以下の手順でダイアル アップ モデムの動作を確認することができます.
|
||||
|
||||
<sect2><heading> FreeBSD システムの動作確認</heading>
|
||||
<p>
|
||||
|
||||
モデムを FreeBSD システムに接続し, システムをブートします. あなたのモ
|
||||
デムにモデムの状態を確認するためのインジケータがあれば, <tt/DTR/ のイ
|
||||
ンジケータの状態に注目してください. もし, システムのコンソールに
|
||||
<tt/login:/ プロンプトが表示された時に, <tt/DTR/ のインジケータが点灯
|
||||
すれば, FreeBSD が適切なポートに対して <tt/getty/ を起動し, モデムへ
|
||||
の着信を待っている状態であることを意味しています.
|
||||
|
||||
もし <tt/DTR/ のインジケータが点灯しない場合は, システムのコンソールか
|
||||
ら FreeBSD にログインして, <tt/ps ax/ を実行し, FreeBSD が 適切なポー
|
||||
トに対して<tt/getty/ プロセスを起動しようとしているのかどうか確認して
|
||||
ください. プロセスに関する情報の中に, 以下のような行が表示されるはずで
|
||||
す.
|
||||
|
||||
<tscreen><verb>
|
||||
114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0
|
||||
115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1
|
||||
</verb></tscreen>
|
||||
|
||||
モデムにまだ着信がない状態の時に, 以下のように上とは異なる出力があった
|
||||
場合, <tt/getty/ は既にモデム ポートのオープンを終了したということに
|
||||
なります.
|
||||
|
||||
<tscreen><verb>
|
||||
114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0
|
||||
^^
|
||||
</verb></tscreen>
|
||||
|
||||
<tt/getty/ は, <tt/CD/ (carrier detect) 信号がオンの状態になるまで,
|
||||
ポートのオープンを完了することはできませんので, この場合は接続に問題が
|
||||
あるか, あるいはモデムの設定に問題があることが考えられます.
|
||||
|
||||
もし, 適切なポートをオープンしようとしている <tt/getty/ が見あたらない
|
||||
場合は, 再度 <tt>/etc/ttys</tt> の内容を確認し, 書式などに誤りがないか
|
||||
調べてみてください. また, ログ ファイル <tt>/var/log/messages</tt> に
|
||||
<tt/init/ および <tt/getty/ から何か出力がないかどうかも確認してみてく
|
||||
ださい. もし何かメッセージが記録されていたら, 再度 <tt>/etc/ttys</tt> ,
|
||||
<tt>/etc/gettytab</tt> の二つの設定ファイルと, ディバイス スペシャル
|
||||
ファイル <tt>/dev/ttyd?</tt> を確認し, 記述に誤りがないか, 足りないエ
|
||||
ントリがないか, 足りないディバイス スペシャルファイルがないかといった
|
||||
点について調べてみてください.
|
||||
|
||||
<sect2><heading>モデムで接続してみる</heading>
|
||||
<p>
|
||||
|
||||
実際にモデムを使って別のコンピュータから接続してみてください. この時,
|
||||
8ビット, パリティなし, 1ストップ ビットで接続するようにしてください.
|
||||
接続後すぐにプロンプトが返ってこない場合や, 無意味な文字列が表示される
|
||||
場合は, 1秒に1回くらいの割合で <tt><Enter></tt> キーを押してみて
|
||||
ください. しばらくたって, なおも <tt/login:/ プロンプトが現れない場合
|
||||
は, <tt>BREAK</tt> 信号を送信してみてください. この時, 端末側で使って
|
||||
いるモデムが高速モデムならば, このモデムのインタフェースの接続速度を固
|
||||
定してから, 再度ダイアル インしてみてください. (たとえば, USRobotics
|
||||
Sportster の場合は, <tt>AT&B1</tt>)
|
||||
|
||||
それでもまだ <tt/login:/ プロンプトが表示されない場合は,
|
||||
<tt>/etc/gettytab</tt> の以下の点について再度確認してみてください.
|
||||
|
||||
<itemize>
|
||||
<item> <tt>/etc/ttys</tt> の対応する行の 2番目の項目で,
|
||||
<tt>/etc/gettytab</tt> の中で定義されているエントリが指定されているか
|
||||
|
||||
<item> 各 <tt/nx=/ で <tt>/etc/gettytab</tt> の中で定義されているもの
|
||||
が指定されているか
|
||||
|
||||
<item> 各 <tt/tc=/ で <tt>/etc/gettytab</tt> の中で定義されているもの
|
||||
が指定されているか
|
||||
|
||||
</itemize>
|
||||
|
||||
もしダイアル インしても, FreeBSD システム側のモデムが応答しない場合は,
|
||||
FreeBSD 側のモデムが <tt/DTR/ がオンになった時に電話にでるように設定さ
|
||||
れているかを確認してください. もしモデムの設定に問題がなさそうならば,
|
||||
モデムのインジケータ (がもしあれば) で, <tt/DTR/ がオンになっているか
|
||||
を確認してください.
|
||||
|
||||
この確認のステップを数回繰り返してもうまくいかない場合は, 一度休憩して,
|
||||
しばらくたってから挑戦してみましょう. それでもだめなら, おそらく
|
||||
&a.questions にあなたのモデムについての情報と問題を書いたメールを送れ
|
||||
ば, メーリング リストのメンバーが問題の解決を助けるべく努力してくれる
|
||||
でしょう.
|
||||
|
||||
<sect1><heading>謝辞</heading>
|
||||
<p>
|
||||
|
||||
以下の方々から, 多くのコメントやアドバイスをいただきました. ここに謝意
|
||||
を表します.
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/Sean Kelly/ <kelly@fsl.noaa.gov> 多くのすばらしい助言をいた
|
||||
だきました
|
||||
|
||||
</descrip>
|
||||
@ -1,164 +0,0 @@
|
||||
<!-- $Id: diskless.sgml,v 1.5 1997/02/22 13:00:54 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.9 -->
|
||||
<!-- 日本語訳 Y.Suzuki(yasu@hike.te.chiba-u.ac.jp)-->
|
||||
|
||||
<sect><heading>Diskless operation<label id="diskless"></heading>
|
||||
|
||||
<p><em>原作: &a.martin;</em>
|
||||
<p><em>訳: &a.yasu;</em>
|
||||
|
||||
<tt>netboot.com/netboot.rom</tt>によって、
|
||||
ディスクのないクライアントで
|
||||
ネットワーク経由でFreeBSDマシンのブートを行い
|
||||
FreeBSDを走らせることができます。
|
||||
2.0ではローカルなスワップを持つことができます。
|
||||
NFS経由のスワッピングもサポートされています。
|
||||
|
||||
サポートされているイーサネットカード:
|
||||
Western Digital/SMC 8003, 8013, 8216 とその互換ボード,
|
||||
NE1000/NE2000 とその互換カード (再コンパイルが必要)
|
||||
|
||||
<sect1>
|
||||
<heading>セットアップの手順</heading>
|
||||
|
||||
<p><enum>
|
||||
<item>サーバにするマシンを見つけます。
|
||||
このマシンには、FreeBSD 2.0のバイナリとbootpを
|
||||
記憶するだけの十分なディスクスペースが必要です。
|
||||
tftp と NFS も使えます。
|
||||
|
||||
テストしたマシン:
|
||||
<itemize>
|
||||
<item>HP9000/8xx / HP-UX 9.04以降
|
||||
(9.04以前では動きません)</item>
|
||||
<item>Sun/Solaris 2.3. (bootpが必要)</item>
|
||||
</itemize>
|
||||
|
||||
<item>クライアントにIP,gateway,netmaskを提供する
|
||||
bootpサーバをセットアップします。
|
||||
<tscreen><verb>
|
||||
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:
|
||||
</verb></tscreen></item>
|
||||
|
||||
<item>クライアントにブート情報を提供するTFTPサーバを
|
||||
(bootpサーバと同じマシンに)セットアップします。
|
||||
このファイルの名前は、<tt>cfg.X.X.X.X</tt> (もしくは
|
||||
<tt>/tftpboot/cfg.X.X.X.X</tt>)で、
|
||||
ここで<tt>X.X.X.X</tt> はクライアントのIPアドレスです。
|
||||
このファイルの内容は netbootコマンドで有効です。
|
||||
2.0では、netboot は以下のようなコマンドを持ちます:
|
||||
<tscreen><verb>
|
||||
help - helpリストの表示
|
||||
ip <X.X.X.X> - クライアントのIPアドレスの表示/セット
|
||||
server <X.X.X.X> - bootp/tftp サーバのアドレスの表示/セット
|
||||
netmask <X.X.X.X> - netmaskの表示/セット
|
||||
hostname <name> - hostnameの表示/セット
|
||||
kernel <name> - カーネル名の表示/セット
|
||||
rootfs <ip:/fs> - root ファイルシステムの表示/セット
|
||||
swapfs <ip:/fs> - swap ファイルシステムの表示/セット
|
||||
swapsize <size> - diskless swapsize を Kbytes単位でセット
|
||||
diskboot - ディスクからのブート
|
||||
autoboot - ブートプロセスの続行
|
||||
trans <on|off> - トランシーバのオン|オフ
|
||||
flags [bcdhsv] - ブートフラグの設定
|
||||
</verb></tscreen>
|
||||
完全にディスクレスな場合の一般的なcfgファイルは以下のようになります:
|
||||
<tscreen><verb>
|
||||
rootfs 192.1.2.3:/rootfs/myclient
|
||||
swapfs 192.1.2.3:/swapfs
|
||||
swapsize 20000
|
||||
hostname myclient.mydomain
|
||||
</verb></tscreen>
|
||||
ローカルにswapを持つマシンについては以下のようになります:
|
||||
<tscreen><verb>
|
||||
rootfs 192.1.2.3:/rootfs/myclient
|
||||
hostname myclient.mydomain
|
||||
</verb></tscreen>
|
||||
|
||||
<item>NFS サーバがクライアントにroot(必要ならswapも)
|
||||
ファイルシステムをexportしているか、また、
|
||||
クライアントがこれらのファイルシステムに
|
||||
ルートアクセスできるか確認します。
|
||||
|
||||
FreeBSDにおける一般的な <tt>/etc/exports</tt> ファイルは
|
||||
以下のようになります:
|
||||
<tscreen><verb>
|
||||
/rootfs/myclient -maproot=0:0 myclient.mydomain
|
||||
/swapfs -maproot=0:0 myclient.mydomain
|
||||
</verb></tscreen>
|
||||
|
||||
そして、HP-UX側では以下のようになります:
|
||||
<tscreen><verb>
|
||||
/rootfs/myclient -root=myclient.mydomain
|
||||
/swapfs -root=myclient.mydomain
|
||||
</verb></tscreen>
|
||||
|
||||
<item>NFS経由でスワッピングを行う場合
|
||||
(完全にディスクレスな場合の設定)、
|
||||
クライアントが <tt>dd</tt> で使用する swap ファイルを作成します。
|
||||
もし、<tt>swapfs</tt> コマンドが上記の例のように
|
||||
引数 <tt>/swapfs</tt>を持ちそのサイズが 20000 である場合、
|
||||
myclientに対するスワップファイルは
|
||||
<tt>/swapfs/swap.X.X.X.X</tt> で呼び出されます。
|
||||
ここで <tt>X.X.X.X</tt> はクライアントのIPアドレスです。
|
||||
|
||||
例:
|
||||
<tscreen><verb>
|
||||
# dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000
|
||||
</verb></tscreen>
|
||||
|
||||
また、スワッピングが開始されるとクライアントのスワップスペースは
|
||||
センシティブな情報を含むようになるので、不正なアクセスを防止するため、
|
||||
このファイルへの読み書きのアクセス制限がなされていることを確認して下さい:
|
||||
<tscreen><verb>
|
||||
# chmod 0600 /swapfs/swap.192.1.2.4
|
||||
</verb></tscreen>
|
||||
|
||||
<item>クライアントがそれぞれのrootファイルシステムとして使う
|
||||
ディレクトリにrootファイルシステムを展開します。
|
||||
(上記の例では<tt>/rootfs/myclient</tt>).
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> HP-UX システム: サーバはHP9000/800 シリーズのマシンで、
|
||||
HP-UX 9.04 以降が必要です。
|
||||
これ以前のバージョンではNFSを経由するデバイスファイルが
|
||||
作成ができません。
|
||||
|
||||
<item> <tt>/rootfs/myclient</tt> に <tt>/dev</tt> を
|
||||
展開する際に、いくつかのシステム(HPUX)ではFreeBSDに合った
|
||||
デバイスファイルが作成されないので注意してください。
|
||||
その際には最初の起動時にシングルユーザモードに移行して
|
||||
(ブートの段階でCtrl-Cを押す)、<tt>/dev</tt> に移って
|
||||
"<tt>sh ./MAKEDEV all</tt>" として、クライアントからこれを
|
||||
修正してください。
|
||||
</itemize>
|
||||
|
||||
<item>クライアントで <tt>netboot.com</tt> を実行するか、
|
||||
<tt>netboot.rom</tt> ファイルから EPROMを作成します。
|
||||
</enum>
|
||||
|
||||
<sect1>
|
||||
<heading><tt>/</tt> および <tt>/usr</tt> ファイルシステムを共有して使用する</heading>
|
||||
|
||||
<p>今のところ、これを行う公式に認められた方法はありませんが、
|
||||
私はそれぞれのクライアントで <tt>/usr</tt> ファイルシステムと
|
||||
個々の <tt>/</tt> ファイルシステム を共有して使っています。
|
||||
どなたかこれをきちんと行うやり方の提案がありましたら、
|
||||
私に、もしくは &a.core; グループに知らせてください。
|
||||
|
||||
<sect1>
|
||||
<heading>特定の設定についてnetbootをコンパイルする</heading>
|
||||
|
||||
<p><tt>/sys/i386/boot/netboot/Makefile</tt> の中の設定を変更して
|
||||
コンパイルすることで、netbootでNE1000/2000 カードをサポートします。
|
||||
このファイルの先頭にあるコメントを見てください。
|
||||
@ -1,501 +0,0 @@
|
||||
<!-- $Id: dma.sgml,v 1.5 1997/02/22 13:00:55 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.7 -->
|
||||
<!-- 日本語訳 鈴木康修 (yasu@hike.te.chiba-u.ac.jp) -->
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
]>
|
||||
-->
|
||||
<sect><heading>DMAとはどういったものでどういう働きをするのか <label id="dma"></heading>
|
||||
|
||||
<p><em>原作: &a.uhclem;<newline>
|
||||
<newline>訳: &a.yasu;<newline>
|
||||
10 December 1996.</em>
|
||||
|
||||
<!-- Version 1(3) -->
|
||||
|
||||
Direct Memory Access (DMA)は, 中央演算処理装置 (CPU)からの干渉なく
|
||||
データを計算機中である場所から別の場所に動かすための手法です.
|
||||
|
||||
DMA機能の実装の方法はそれぞれの計算機アーキテクチャ間で異なるもので
|
||||
あるため, ここでの議論はIBMパーソナルコンピュータ(PC),
|
||||
PC/ATとその互換機におけるDMAサブシステムの実装と働きに限定します.
|
||||
|
||||
PCの DMAサブシステムは, Intelの 8237 DMAコントローラをベースにして
|
||||
います. 8237はそれぞれ独立にプログラムできる4つのDMAチャネルを持ち,
|
||||
それぞれどのチャネルもいつでもアクティブにできます.
|
||||
これらのチャネルは順に 0, 1, 2, 3となっています.
|
||||
PC/ATからは, セカンド 8237 チップが追加され,それらは 4, 5, 6, 7と
|
||||
なっています.
|
||||
|
||||
オリジナルの DMAコントローラ(0, 1, 2, 3)は, 1回の転送で1バイト
|
||||
転送します.
|
||||
セカンドDMAコントローラ(4, 5, 6, 7)は1回で 隣接する2つのメモリ番地から
|
||||
16ビット転送します.
|
||||
ここで, 最初のバイトは通常偶数のアドレスになります.
|
||||
2つのコントローラは全く同じものであり, 転送量が異なるのは
|
||||
セカンドコントローラがシステムに直結しているためです.
|
||||
|
||||
8237 は個々のチャネルについて, DRQと-DACKという2つの電気信号を
|
||||
持っています. その他に, HRQ (Hold Request), HLDA (Hold Acknowledge),
|
||||
-EOP (End of Process)があり, バス制御信号として -MEMR (Memory Read),
|
||||
-MEMW (Memory Write), -IOR (I/O Read), and -IOW (I/O Write)があります.
|
||||
|
||||
8237 DMACは, いわゆる``fly-by'' DMAコントローラです.
|
||||
これは, データの移動を行う際に, データは DMACチップを通過せず,
|
||||
DMACチップに格納されないことを意味します.
|
||||
また, DMACはI/Oポートとメモリアドレス間でのみデータを
|
||||
転送することができますが, 2つのI/Oポートもしくは2つのメモリアドレス
|
||||
間ではできません.
|
||||
|
||||
<quote><em>注:</em> 8237は, 非``fly-by''モードでは, 互いに接続された
|
||||
2つのチャネルでのメモリ-メモリ間でのDMA操作を許可します.
|
||||
しかし, PCメーカは, ただでさえ乏しいこのリソースをこんなふうに
|
||||
使ったりしません。
|
||||
なぜなら, CPUを使用してメモリ間のデータを動かす方が早いからです.
|
||||
</quote>
|
||||
|
||||
PCアーキテクチャでは, それぞれのDMAチャネルは, 通常そのDMAを
|
||||
使用するハードウェアがそのチャネルについてDRQを使って
|
||||
転送を要求した時のみ動作します.
|
||||
|
||||
|
||||
<sect1><heading>DMA転送の例</heading>
|
||||
|
||||
<p>これはDMA転送の手順の例です.
|
||||
この例では, フロッピーディスクコントローラ (FDC)が
|
||||
ディスケットから1バイト読み込んで, DMAを使って,メモリの0x00123456番地に
|
||||
格納したいとします. 処理は, FDCによって, DRQ2信号を有効にして
|
||||
DMAコントローラに要求を伝えることで開始します.
|
||||
|
||||
DMAコントローラはDRQ2シグナルが有効になったことを記録します.
|
||||
するとDMAコントローラはDMAチャネル2がプログラムされ, 有効に
|
||||
なっていることを確認します.
|
||||
DMAコントローラはまた, 他のDMAチャネルがアクティブでないか, または
|
||||
より高い優先度を持っていないかを確認します.
|
||||
一旦これらのチェックが完了すると, DMACはDMACがバスを使うために
|
||||
バスを開放するようにCPUに要求します.
|
||||
DMACはCPUにHRQ信号を送ってバスを要求します.
|
||||
|
||||
CPUはHRQ信号を検出し, 現在の指示の実行を完了します.
|
||||
一旦プロセッサがバスを開放することができる状態になると, 解放を
|
||||
行います.
|
||||
通常は CPU により駆動される信号 (-MEMR, -MEMW, -IOR, -IOW, その他)を
|
||||
すべてハイインピーダンス (ハイともローとも指定しない)状態にした後,
|
||||
CPUは HLDA信号を有効にして DMAコントローラにバスを明け渡したことを
|
||||
伝えます.
|
||||
|
||||
プロセッサによっては, CPUはバスを使用しないいくつかの
|
||||
命令を追加して実行することもできますが,
|
||||
しかし,プロセッサの内部キャッシュやパイプライン以外のメモリから
|
||||
何か読み出すといった指示に到達したら結局CPUは待たなくてはなりません.
|
||||
|
||||
ここで,DMACが バスを「託される」と,
|
||||
DMACはその -MEMR, -MEMW, -IOR, -IOW 出力信号をアクティブにし,
|
||||
DMACから出力されるアドレスは 0x3456にセットされます.これは
|
||||
転送しようとする特定のメモリ番地をバイトで指示するのに使われます.
|
||||
|
||||
するとDMACはDMA転送をリクエストしたデバイスに転送が始まることを
|
||||
知らせます.これは -DACK信号をアクティブにすることで行われます.
|
||||
フロッピーディスクコントローラの場合は, -DACK2を
|
||||
アクティブにすることで行われます.
|
||||
|
||||
バスのデータ線に転送されるバイトにを出力することについては
|
||||
フロッピーディスクコントローラが責任をもつことになります.
|
||||
もし,フロッピーディスクコントローラがバス上にバイトデータを
|
||||
出力するのに余計な時間を必要としなければ
|
||||
(もし周辺装置がもっと時間を必要とする場合には, READY信号を
|
||||
経由してDMACに通知します), DMAは 1 DMAクロック待ち,
|
||||
メモリにバス上のバイトデータを格納するために
|
||||
-MEMW および -IOR 信号を解除します. そして
|
||||
FDCはバイトデータが転送されたことを認識します.
|
||||
|
||||
DMAサイクルは1度に1バイトしか転送しないので,
|
||||
FDCはDRQ2信号を止めて, DMACに転送の終了を知らせます.
|
||||
DMACは-DACK2信号を解除して, FDCはバス上へのデータ出力を
|
||||
停止しなくてはならないことを知らせます.
|
||||
|
||||
次にDMACは他のDMAチャネルのいずれかに要求がきていないか
|
||||
チェックを行います. もしどのチャネルのDRQも有効になっていなければ,
|
||||
DMAコントローラは処理を完了して, -MEMR, -MEMW, -IOR, -IOW および
|
||||
アドレス信号をハイインピーダンス状態にします.
|
||||
|
||||
最後に, DMAはHRQ信号を解除します. CPUはこれを見ると,HOLDA信号を
|
||||
解除します. そしてCPUは自らの -MEMR, -MEMW, -IOR, -IOW 信号および
|
||||
アドレス線を有効にし, 命令の実行やメインメモリや周辺機器へのアクセスを
|
||||
再開します.
|
||||
|
||||
典型的なフロッピーディスクの1セクタについては, 上記のプロセスが
|
||||
それぞれのバイトについて1回行われ, 全部で512回繰り返されます.
|
||||
1バイト転送される毎に,DMAC内のアドレスレジスタはインクリメントされ,
|
||||
何バイト転送すればよいかを示すカウンタがデクリメントされます.
|
||||
|
||||
カウンタが0になると, DMAはカウンタが0になったことを示すEOP信号を
|
||||
送り, DMAコントローラがCPUによって再びプログラムされるまで
|
||||
これ以上データは転送されなくなります.
|
||||
|
||||
このイベントはターミナルカウント(TC)とも呼ばれます.
|
||||
EOP信号は1本しかありません. なぜならどんな時もただ1つのDMAチャネル
|
||||
のみをアクティブにすることができるためです.
|
||||
|
||||
もし, バッファの転送が完了した時に周辺機器から割り込みを発生させたい
|
||||
とき, 周辺機器は -DACK信号およびEOP信号の両方が同時に発信されたか
|
||||
どうかをテストします. それが生じると, DMACはCPUの介在がなければ
|
||||
これ以上はその周辺機器についての情報を転送しないことを意味します.
|
||||
すると周辺機器はプロセッサの注意を得るために割り込み信号のうちの1つを
|
||||
発信します. DMAチップ自身は割り込みを生じさせる能力は持っていません.
|
||||
周辺機器とそれに関連するハードウェアが割り込みを生成する責任を
|
||||
持ちます.
|
||||
|
||||
DMACが要求を出したときにはCPUは常にバスをDMACに開放しますが,
|
||||
この動作は, DMACがアクティブになった時にプロセッサが命令を実行するのに
|
||||
かかる時間がわずかに変化することを除いては, アプリケーション,
|
||||
オペレーティングシステムの両方からはわからないということを
|
||||
理解することが重要です.
|
||||
そのため, プロセッサが確かにDMA転送が完了したことを知るためには,
|
||||
周辺装置やDMAチップ中のレジスタを調べたり,周辺装置からの割り込みを
|
||||
受け取る必要があります.
|
||||
|
||||
|
||||
<sect1><heading>DMA ページレジスタ および 16メガ アドレス空間制限</heading>
|
||||
|
||||
<p>これまで述べたのとは異なり, DMACはアドレス線を 0x0123456 にセットする
|
||||
代わりに 0x3456 だけをセットすることにあなたは気づいたかも
|
||||
しれません. この理由について少し説明します.
|
||||
|
||||
オリジナルのIBM PCがデザインされた時, IBMは, DMACと割込み制御チップの
|
||||
両方を, 8085(8ビットプロセッサで, 16ビットのアドレス空間(64k)を持つ)と
|
||||
組み合わせて使うように設計されたチップを使うことを選びました.
|
||||
IBM PCが64k以上のメモリをサポートしていたため,
|
||||
DMACが64kを越えるメモリ番地に読み込み又は書き込みを行うために
|
||||
変更を行う必要が生じました.
|
||||
この問題を解決するためにIBMが行ったのは, それぞれのDMAチャネルに
|
||||
ついてラッチを追加することでした. つまり, 読み込む又は書き込む先の
|
||||
アドレスの上位ビットに保持するためのものです.
|
||||
DMAチャネルがアクティブな時はいつでも,
|
||||
このラッチの内容はアドレスバスに書かれて, そのチャネルのDMA操作が
|
||||
終了するまでそこに保持されます.
|
||||
これらのラッチは「ページレジスタ」と呼ばれます.
|
||||
|
||||
そのため上記に示した例では, DMACはアドレスの0x3456の部分をバス上に
|
||||
置き, DMAチャネル2に対するページレジスタは, 0x0012xxxxをバス上に
|
||||
置きます. これらの2つの値が組み合わされてアクセスされるメモリ中の完全な
|
||||
アドレスを形成します.
|
||||
|
||||
ページレジスタのラッチはDMAチップとは独立であるので,
|
||||
読み込まれる又は書き込まれるメモリ領域は, 64kの物理的境界を
|
||||
またいではなりません.
|
||||
DMACがメモリの0xffff番地をアクセスすると, データの転送後,
|
||||
DMACはアドレスレジスタをインクリメントし, 0x0000番地にある次のバイトを
|
||||
アクセスします. 0x10000番地ではありません.
|
||||
これはおそらく意図されたものとは異なっているでしょう.
|
||||
|
||||
<quote><em>注:</em> 「物理的な」 64Kの境界を 8086モードの
|
||||
64k「セグメント」と混同してはいけません. セグメントは, セグメント
|
||||
レジスタにオフセットレジスタを加算して作られるものです.
|
||||
ページレジスタにはアドレスのオーバーラップはありません. </quote>
|
||||
|
||||
さらに複雑なことには, PC/ATでは外部のDMAアドレスのラッチは
|
||||
8ビットしか保持しません. よって8+16で24ビットになり, これは
|
||||
DMAが0から16メガの間のメモリ番地しか指し示せないことを
|
||||
意味します. 16メガ以上のメモリを持ったより新しいマシンにおいても,
|
||||
PCコンパチブルなDMAでは16メガ以上のメモリ番地にはアクセスできません.
|
||||
|
||||
この制限を避けるために, オペレーティングシステムは
|
||||
16メガ以下にある物理的な64kの境界をまたがない領域にバッファを
|
||||
予約します. そして, DMACはデータを周辺機器からそのバッファに
|
||||
転送するようにプログラムされます. 一旦DMACがこのバッファに
|
||||
データを動かすと, オペレーティングシステムは本当にデータを
|
||||
格納したいアドレスにバッファからデータをコピーします.
|
||||
|
||||
16メガを越えるアドレスからDMAベースの周辺機器にデータを
|
||||
書き込む際には, データは16メガ以下に位置したバッファから最初に
|
||||
コピーされなくてはならず, その後, DMACはバッファからハードウェアに
|
||||
データをコピーすることができます. FreeBSDでは, これらの予約バッファは
|
||||
「バウンスバッファ」と呼ばれます. MS-DOSの世界では,
|
||||
これらは「スマートバッファ」などと呼ばれます.
|
||||
|
||||
|
||||
<sect1><heading>DMA操作モードとその設定</heading>
|
||||
|
||||
<p>8237 DMA はいくつかのモードで動作します. 主なモードは,
|
||||
以下のとおりです.
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag>シングル転送モード</tag>
|
||||
シングルバイト(もしくはワード)が転送されます.
|
||||
DMAは1バイト毎にバスを開放し,
|
||||
再び要求しなくてはなくてはなりません.
|
||||
これは一般に, すぐにはデータのブロック全てを転送できないデバイスに
|
||||
よって使用されます.
|
||||
周辺装置は次の転送の準備ができる毎にDMAを要求します.
|
||||
|
||||
フロッピーディスクコントローラは1バイトのバッファしか持たないので,
|
||||
このモードを使用します.
|
||||
|
||||
|
||||
<tag>ブロック/デマンド転送モード</tag>
|
||||
一旦DMACがシステムバスを取得すると, 最大64kまでのデータブロック
|
||||
全体が転送されます.
|
||||
もし周辺装置が余分に時間を必要とするときは,
|
||||
転送を一時中断するためにREADY信号を有効にします.
|
||||
READY信号は過度に使われるべきではなく, 遅い周辺装置の転送の場合は
|
||||
シングル転送モードを代わりに使うべきです.
|
||||
|
||||
ブロック転送モードとデマンド転送モードの違いは, 一旦ブロック転送が
|
||||
始まると,転送カウンタか0になるまでそれが行われるところです.
|
||||
1バイト転送するにはDRQが -DACK が有効になるまでの間だけ
|
||||
有効であれば充分です.
|
||||
デマンドモードはDRQが有効な間は転送が続けられます.
|
||||
DMACが転送を一時中止した場合はバスを解放してCPUに返します.
|
||||
その後、DRQが有効になると, 転送は中断したところから再開されます.
|
||||
|
||||
データの転送, 特に転送に使われるメモリ番地が16Mを越える場合に,
|
||||
CPUを使った方が効率がよくなるまでCPUの速度が向上する以前の
|
||||
古いハードディスクコントローラはデマンドモードを使っていました.
|
||||
|
||||
|
||||
<tag>カスケード転送モード</tag>
|
||||
このメカニズムはDMAチャネルがバスを要求することを許可する
|
||||
ものですが, 接続されたデバイスはバス上のアドレス情報の配置に
|
||||
ついてDMACに代わって責任を持ちます.
|
||||
これはいわゆる「バスマスタ」というものです.
|
||||
|
||||
カスケードモードのDMAチャネルがバスのコントロールを受け取ると,
|
||||
DMAは通常行われるようなバス上のアドレスとI/Oコントロール信号の
|
||||
出力を行いません. 代わりに, DMAはこのチャネルの -DACK信号を
|
||||
有効にします.
|
||||
|
||||
この時点で, アドレスとバスコントロール信号の供給は
|
||||
DMAチャネルに接続されたデバイスが担当します.
|
||||
周辺機器はシステムバスの完全なコントロールを行い,
|
||||
16メガ以下の任意のアドレスの読み込みおよび書き込みを行うことが
|
||||
できます. 周辺機器はバスの使用を終えると, DRQ線を無効にして,
|
||||
DMAコントローラはCPUもしくは他のDMAチャネルに制御を返します.
|
||||
|
||||
カスケードモードは複数のDMAコントローラを相互接続するのに
|
||||
使われます. PC内ではDMAチャネル4がまさにこの用途に使われています.
|
||||
周辺機器がDMAチャネル0, 1, 2, 3でバスを要求すると,
|
||||
スレーブDMAコントローラは HLDREQ を有効にしますが,
|
||||
この線は実際にはプライマリDMAコントローラのDRQ4に接続されています.
|
||||
プライマリのDMAコントローラはその後 HLDREQ を使ってCPUにバスを
|
||||
要求します. バスが与えられると, -DACK4が有効になり,
|
||||
この線は実際にはスレーブDMAコントローラの HLDA信号に
|
||||
接続されています.
|
||||
スレーブDMAコントローラはその後要求したDMAチャネルに対して
|
||||
データを転送するか, SCSIコントローラのような
|
||||
バスマスタリングを要求する周辺機器にバスを許可します.
|
||||
|
||||
このような配線がおこなわれているため, PC/ATシステムでは
|
||||
DMAチャネルは
|
||||
0, 1, 2, 3, 5, 6, 7のみが使用できます.
|
||||
|
||||
<quote><em>注:</em>
|
||||
初期のIBM PCコンピュータでは, DMAチャネル0は操作の
|
||||
リフレッシュのために予約されていますが,
|
||||
最近のシステムでは通常, 周辺機器によって使用することができます.
|
||||
</quote>
|
||||
|
||||
周辺機器がバスマスタリングを行っている時は,
|
||||
システムバスを保持している間絶えずメモリにもしくはメモリから
|
||||
データを転送することが重要です.もし, 周辺機器がこのように
|
||||
できないときは, システムがメインメモリのリフレッシュを
|
||||
行なえるようにしばしばバスを開放しなくてはなりません.
|
||||
|
||||
全てのPCでメインメモリとして使われるダイナミックRAMは,
|
||||
中身が「満たされている」ビットを保持するため
|
||||
頻繁にアクセスされなくてはなりません.
|
||||
ダイナミックRAMは, それぞれが1ビットのデータを記憶するコンデンサが
|
||||
たくさん集まって構成されています. これらのコンデンサは充電された
|
||||
状態で"1", 充電されていない状態で"0"を表します.
|
||||
全てのコンデンサは放電するため, "1"の値を保持するために,
|
||||
一定の間隔で電力を加える必要があります.
|
||||
実際にRAMチップはRAMの適切な場所に電力を送る作業を行ないますが,
|
||||
メモリのリフレッシュ作業がRAMを普通にアクセスする時と
|
||||
衝突しないように, それをいつ行なうかを
|
||||
コンピュータが休止状態の時に知らせなくてはなりません.
|
||||
もしコンピュータがメモリのリフレッシュを行なえない場合は,
|
||||
メモリの中身はわずか数ミリ秒で壊れてしまいます。
|
||||
|
||||
メモリの読み込みと書き込みのサイクルはリフレッシュサイクルとして
|
||||
カウントされる(ダイナミックRAMのリフレッシュサイクルは
|
||||
実際には不完全なメモリ読み込みサイクルになります)ので,
|
||||
周辺機器のコントローラが連続するメモリ番地からデータの読み込み
|
||||
または書き込みを行う間は, メモリの全てがリフレッシュされます.
|
||||
|
||||
バスマスタリングはいくつかのSCSIホストインターフェースやその他の
|
||||
ハイパフォーマンスな周辺機器コントローラに見られます.
|
||||
|
||||
|
||||
<tag>自動初期化転送モード</tag>
|
||||
このモードにおいてDMAはバイト, ブロック, デマンド転送を行いますが,
|
||||
DMA転送カウンタが0になると, カウンタとアドレスはDMAチャネルが
|
||||
もともとプログラムされた時のものに戻されます.
|
||||
これは, 周辺機器が転送を要求している間は転送が続けられることを
|
||||
意味します.
|
||||
転送領域としてDMACにプログラムされた固定バッファの中で,
|
||||
出力操作でDMACがデータを読み出す前もって新しいデータを
|
||||
書き込んだり入力操作でDMACが書き込んだあとに,
|
||||
そこから新しいデータを読み出す作業はCPUが受け持ちます.
|
||||
|
||||
このテクニックは, サンプリング用のバッファが小さいもしくは
|
||||
それを持たないオーディオデバイスによく使われます.
|
||||
この「環状」バッファの管理は更なるCPUオーバーヘッドになりますが,
|
||||
DMAカウンタが0になり, 再プログラムされるまでDMAが停止してしまう
|
||||
ことによって起きる遅延は, この方法でしかなくす事ができない
|
||||
場合もあります.
|
||||
</descrip>
|
||||
|
||||
<sect1><heading>DMAのプログラミング</heading>
|
||||
|
||||
<p>プログラムされるDMAチャネルは, 通常, 設定を行う前に
|
||||
「マスクする」べきです.
|
||||
これはハードウェアが予期せずDRQを有効にすると, たとえ全てのパラメータが
|
||||
満たされてない場合や更新されていない場合でも, DMACは
|
||||
それに応答してしまうからです.
|
||||
|
||||
マスクを行ってから,ホストは転送の方向(メモリからI/O,
|
||||
もしくはI/Oからメモリ)と, 転送に使用するDMA操作のモード
|
||||
(シングル, ブロック, デマンド, カスケードなど)を設定し, 最後に
|
||||
アドレスや転送の長さを設定します.
|
||||
設定される長さはDMACに転送させたい量よりも1少なくなります.
|
||||
アドレスや転送長のLSBとMSBは同じ8ビットI/Oポートに書き込まれます.
|
||||
そのためDMACが最初のバイトをLSBとして, 2番目のバイトをMSBとして
|
||||
受け取ることを保証するために, 最初に別のポートに書き込みを行なって
|
||||
LSBとMSBの判別を行なうフリップフロップをクリアしておく必要があります.
|
||||
|
||||
そして,DMAのページレジスタを更新します. これはDMACの外部にあり
|
||||
I/Oポートの別のセットを通してアクセスされます.
|
||||
|
||||
すべての設定ができると, DMAチャネルはマスクを解除することができます.
|
||||
そのDMAチャネルは「準備ができた」とみなされ, DRQが有効になると
|
||||
応答します.
|
||||
|
||||
8237のプログラミングの正確な詳細については,
|
||||
ハードウェアデータブックを参照してください.
|
||||
PCシステムにおけるI/Oマップについても参照する必要があるでしょう.
|
||||
このマップにはDMAおよびページレジスタのポートがどこに位置するのかを
|
||||
書いてあります. 以下に完全な表を示します.
|
||||
|
||||
|
||||
<sect1><heading>DMAポートのマップ</heading>
|
||||
|
||||
<p>IBM-PCとPC/ATに基づくすべてのシステムでは, 同じI/Oポートに配置された
|
||||
DMAハードウェアを持っています. その完全なリストを以下に示します.
|
||||
DMAコントローラ2に割り当てられたポートは, AT以外のデザインでは
|
||||
未定義になっています.
|
||||
|
||||
<sect2><heading>0x00 - 0x1f DMA コントローラ #1 (Channels 0, 1, 2 and 3)</heading>
|
||||
|
||||
<p>DMA アドレス および カウントレジスタ
|
||||
|
||||
<verb>
|
||||
0x00 write Channel 0 starting address
|
||||
0x00 read Channel 0 current address
|
||||
0x02 write Channel 0 starting word count
|
||||
0x02 read Channel 0 remaining word count
|
||||
|
||||
0x04 write Channel 1 starting address
|
||||
0x04 read Channel 1 current address
|
||||
0x06 write Channel 1 starting word count
|
||||
0x06 read Channel 1 remaining word count
|
||||
|
||||
0x08 write Channel 2 starting address
|
||||
0x08 read Channel 2 current address
|
||||
0x0a write Channel 2 starting word count
|
||||
0x0a read Channel 2 remaining word count
|
||||
|
||||
0x0c write Channel 3 starting address
|
||||
0x0c read Channel 3 current address
|
||||
0x0e write Channel 3 starting word count
|
||||
0x0e read Channel 3 remaining word count
|
||||
</verb>
|
||||
|
||||
DMA コマンドレジスタ
|
||||
|
||||
<verb>
|
||||
0x10 write Command Register
|
||||
0x10 read Status Register
|
||||
0x12 write Request Register
|
||||
0x12 read -
|
||||
0x14 write Single Mask Register Bit
|
||||
0x14 read -
|
||||
0x16 write Mode Register
|
||||
0x16 read -
|
||||
0x18 write Clear LSB/MSB Flip-Flop
|
||||
0x18 read -
|
||||
0x1a write Master Clear/Reset
|
||||
0x1a read Temporary Register
|
||||
0x1c write Clear Mask Register
|
||||
0x1c read -
|
||||
0x1e write Write All Mask Register Bits
|
||||
0x1e read -
|
||||
</verb>
|
||||
|
||||
<sect2><heading>0xc0 - 0xdf DMA コントローラ #2 (Channels 4, 5, 6 and 7)</heading>
|
||||
|
||||
<p>DMA アドレス および カウントレジスタ
|
||||
|
||||
<verb>
|
||||
0xc0 write Channel 4 starting address
|
||||
0xc0 read Channel 4 current address
|
||||
0xc2 write Channel 4 starting word count
|
||||
0xc2 read Channel 4 remaining word count
|
||||
|
||||
0xc4 write Channel 5 starting address
|
||||
0xc4 read Channel 5 current address
|
||||
0xc6 write Channel 5 starting word count
|
||||
0xc6 read Channel 5 remaining word count
|
||||
|
||||
0xc8 write Channel 6 starting address
|
||||
0xc8 read Channel 6 current address
|
||||
0xca write Channel 6 starting word count
|
||||
0xca read Channel 6 remaining word count
|
||||
|
||||
0xcc write Channel 7 starting address
|
||||
0xcc read Channel 7 current address
|
||||
0xce write Channel 7 starting word count
|
||||
0xce read Channel 7 remaining word count
|
||||
</verb>
|
||||
|
||||
DMA コマンドレジスタ
|
||||
|
||||
<verb>
|
||||
0xd0 write Command Register
|
||||
0xd0 read Status Register
|
||||
0xd2 write Request Register
|
||||
0xd2 read -
|
||||
0xd4 write Single Mask Register Bit
|
||||
0xd4 read -
|
||||
0xd6 write Mode Register
|
||||
0xd6 read -
|
||||
0xd8 write Clear LSB/MSB Flip-Flop
|
||||
0xd8 read -
|
||||
0xda write Master Clear/Reset
|
||||
0xda read Temporary Register
|
||||
0xdc write Clear Mask Register
|
||||
0xdc read -
|
||||
0xde write Write All Mask Register Bits
|
||||
0xde read -
|
||||
</verb>
|
||||
|
||||
<sect2><heading>0x80 - 0x9f DMA ページレジスタ</heading>
|
||||
|
||||
<p><verb>
|
||||
0x87 r/w DMA Channel 0
|
||||
0x83 r/w DMA Channel 1
|
||||
0x81 r/w DMA Channel 2
|
||||
0x82 r/w DMA Channel 3
|
||||
|
||||
0x8b r/w DMA Channel 5
|
||||
0x89 r/w DMA Channel 6
|
||||
0x8a r/w DMA Channel 7
|
||||
|
||||
0x8f Refresh
|
||||
</verb>
|
||||
|
||||
@ -1,454 +0,0 @@
|
||||
<!-- $Id: eresources.sgml,v 1.5 1997/02/22 13:00:56 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.34 -->
|
||||
|
||||
<chapt>
|
||||
<heading>インターネット上のリソース<label id="eresources"></heading>
|
||||
|
||||
<p><em>原作: &a.jkh;.</em>
|
||||
|
||||
<p><em>訳: &a.yuki;.<newline>28 August 1996</em>
|
||||
|
||||
<p>FreeBSDの進歩が急速であるため, 最新の開発をフォローするためには,
|
||||
印刷したメディアは実用的でなくなっています.
|
||||
大抵の場合, 最新情報を入手する方法としては, 電子的なリソースが
|
||||
ベストです. FreeBSDはボランティアの努力によって,
|
||||
ユーザコミュニティ自体が, 一種の「テクニカルサポート部門」としての
|
||||
役割も通常果たしており, 電子メールやUsenetのニュースがこれらのコミュ
|
||||
ニティにたどり着く最も効果的な方法になっています.
|
||||
|
||||
以下に, FreeBSD ユーザコミュニティに連絡を取る場合の最も重要な点についての
|
||||
概略を示します. もしここに書かれていない他のリソースに気がついた場合は,
|
||||
それらを &a.doc に送って頂ければ, それらをここに含めるかもしれません.
|
||||
|
||||
<sect>
|
||||
<heading>メーリングリスト<label id="eresources:mail"></heading>
|
||||
<p>多くのFreeBSDの開発メンバはUSENETを読むことができますが,
|
||||
もし, comp.unix.bsd.freebsd.*のグループの一つに質問を投稿したとしても
|
||||
タイムリにその質問を受け取るということは保証できません.
|
||||
質問を適切なメーリングリストに投稿すれば, 私たちかFreeBSDの関係者から,
|
||||
よりよい (そして少なくともより早い) 反応がいつでも得られることでしょう.
|
||||
|
||||
<P>さまざまなメーリングリストの憲章をこのドキュメントの最後に記載しま
|
||||
す. <bf>私たちは, メーリングリストの質, 特に技術面に関する質を高く保つ
|
||||
ために努力しているので, メーリングリストに参加する前にその憲章を読んで
|
||||
ください. </bf>私たちのメーリングリストの参加者のほとんどは, 現在非常
|
||||
にたくさんのFreeBSDに関連したメッセージを毎日受け取っており, メーリン
|
||||
グリストに対するふさわしい用いられ方をするための憲章やルールを決めるこ
|
||||
とによって, メーリングリストのS/N比を高くする保つように励んでいます.
|
||||
そうしないと, 結果的に, メーリングリストがプロジェクトにとって
|
||||
事実上のコミュニケーションの手段になってしまうでしょう.
|
||||
|
||||
メーリングリストはいずれもアーカイブされており, それらは
|
||||
<url url="http://www.FreeBSD.ORG/search.html"
|
||||
name="FreeBSD World Wide Web server"> で検索することができます.
|
||||
キーワード検索可能なアーカイブの提供は,
|
||||
良くある質問に対する回答を見つけるすぐれた方法ですから,
|
||||
質問を投稿する前に調べてみるべきでしょう.
|
||||
|
||||
<sect1><heading>メーリングリストの概説<label id="eresources:summary"></heading>
|
||||
|
||||
<p><bf>一般的なメーリングリスト:</bf> 以下のものは誰でも自由に参加できる
|
||||
一般的なものです:
|
||||
<verb>
|
||||
リスト 目的
|
||||
----------------------------------------------------------------------
|
||||
freebsd-announce 重要なイベントやプロジェクトのマイルストン
|
||||
freebsd-bugs バグレポート
|
||||
freebsd-chat FreeBSDコミュニティに関連する技術的ではない話題
|
||||
freebsd-current FreeBSD-currentの使用に関連する議論
|
||||
freebsd-stable FreeBSD-stableの使用に関連する議論
|
||||
freebsd-isp FreeBSDを用いているインターネットサービスプロバイダの話題
|
||||
freebsd-questions ユーザからの質問
|
||||
</verb>
|
||||
|
||||
<bf>技術的なメーリングリスト:</bf> 以下のメーリングリストは, 技術的な
|
||||
議論のためのものです. それらの利用や内容のためにしっかりとしたガイドラ
|
||||
インがあるので, これらのメーリングリストに入ったり, どれか一つにメール
|
||||
を送ったりする前には, それらのメーリングリストの憲章を注意深く読むべきで
|
||||
す.
|
||||
<verb>
|
||||
リスト 目的
|
||||
----------------------------------------------------------------------
|
||||
freebsd-doc FreeBSDのドキュメンテーションプロジェクト
|
||||
freebsd-emulation Linux/DOS/Windowsのような他のシステムのエミュレーション
|
||||
freebsd-fs ファイルシステム
|
||||
freebsd-hackers 一般的な技術の議論
|
||||
freebsd-hardware FreeBSDの走るハードウェアの一般的な議論
|
||||
freebsd-mobile モーバイルコンピューティングについての議論
|
||||
freebsd-multimedia マルチメディアの議論
|
||||
freebsd-platforms Intel以外のアーキテクチャのプラットフォームへの移植
|
||||
freebsd-ports portsコレクションに関する議論
|
||||
freebsd-security セキュリティに関する話題
|
||||
freebsd-security-notifications
|
||||
セキュリティに関する通知 (モデレーテッドメーリングリスト)
|
||||
freebsd-scsi SCSIサブシステム
|
||||
freebsd-smp 対称/非対称のマルチプロセッシングの設計に関する議論
|
||||
</verb>
|
||||
|
||||
<bf>制限されているメーリングリスト:</bf> 以下のメーリングリストは参加
|
||||
するには<url url="mailto:core@freebsd.org" name="core@FreeBSD.ORG">の
|
||||
認可が必要ですが, それぞれの憲章の範囲内であれば, 提案やコメントは誰で
|
||||
も自由に投稿することができます.
|
||||
<verb>
|
||||
メーリングリスト 目的
|
||||
----------------------------------------------------------------------
|
||||
freebsd-admin 管理に関する話題
|
||||
freebsd-arch アーキテクチャや設計の議論
|
||||
freebsd-core FreeBSDコアチーム
|
||||
freebsd-hubs ミラーサイトを運営している人達 (基盤のサポート)
|
||||
freebsd-install インストール関係の開発
|
||||
freebsd-user-groups ユーザグループの調整
|
||||
</verb>
|
||||
|
||||
<bf>CVSメーリングリスト:</bf> 以下のメーリングリストはソースツリーの
|
||||
さまざまな場所の変更のログメッセージを見ることに興味のある人向けです.
|
||||
これらは<bf>読み専用</bf>のリストで, これらにメールを送る事は出来ません.
|
||||
<verb>
|
||||
メーリングリスト ソースの範囲 (ソースの) 範囲の説明
|
||||
----------------------------------------------------------------------
|
||||
cvs-CVSROOT /usr/src/[A-Z]* /usr/src/ 以下のトップレベルのファイルの変更
|
||||
cvs-all /usr/src ツリーのすべての変更 (スーパーセット)
|
||||
cvs-bin /usr/src/bin システムバイナリ
|
||||
cvs-etc /usr/src/etc システムファイル
|
||||
cvs-games /usr/src/games ゲーム
|
||||
cvs-gnu /usr/src/gnu GPLにしたがったユーティリティ
|
||||
cvs-include /usr/src/include インクルードファイル
|
||||
cvs-kerberosIV /usr/src/kerberosIV Kerberos暗号化コード
|
||||
cvs-lib /usr/src/lib システムライブラリ
|
||||
cvs-libexec /usr/src/libexec システムバイナリ
|
||||
cvs-ports /usr/ports 移植済みソフトウェア
|
||||
cvs-sbin /usr/src/sbin システムバイナリ
|
||||
cvs-share /usr/src/share システム共有ファイル
|
||||
cvs-sys /usr/src/sys カーネル
|
||||
cvs-usrbin /usr/src/usr.bin ユーザバイナリ
|
||||
cvs-usrsbin /usr/src/usr.sbin システムバイナリ
|
||||
</verb>
|
||||
|
||||
<sect1><heading>参加方法<label id="eresources:subscribe"></heading>
|
||||
|
||||
<p>どのメーリングリストも<tt>FreeBSD.ORG</tt>にあるので,
|
||||
メーリングリストにメールを送るには, ただ
|
||||
<em>listname</em><tt>@FreeBSD.ORG</tt> にメールを送るだけです.
|
||||
すると, メーリングリストに登録されている世界中のメンバに再配布されます.
|
||||
|
||||
メーリングリストに参加するには,
|
||||
<tscreen><verb>
|
||||
subscribe <listname> [<optional address>]
|
||||
</verb></tscreen>
|
||||
という内容をメッセージの本文に含むメールを &a.majordomo に送ります.
|
||||
例えば, freebsd-announce に参加したい場合は次のようにします:
|
||||
<tscreen><verb>
|
||||
% mail majordomo@FreeBSD.ORG
|
||||
subscribe freebsd-announce
|
||||
^D
|
||||
</verb></tscreen>
|
||||
もし, あなたが, 自分自身を違う名前 (メールアドレス) で登録したい場合,
|
||||
あるいは, ローカルなメーリングリスト (注意:もしあなたのサイトに,
|
||||
興味を持った仲間がいるなら, これはより有効ですし,
|
||||
私たちにとっても非常に嬉しいことです.)
|
||||
を登録する申し込みをおこないたいのであれば, 次のようにします:
|
||||
<tscreen><verb>
|
||||
% mail majordomo@FreeBSD.ORG
|
||||
subscribe freebsd-announce local-announce@somesite.com
|
||||
^D
|
||||
</verb></tscreen>
|
||||
最後に, majordomoに対して
|
||||
他のタイプのコントロールメッセージを送ることで
|
||||
メーリングリストから脱退したり, メーリングリストの他のメンバのリストを
|
||||
得たり, 再びメーリングリストのリストを見たりすることも可能です.
|
||||
利用できるコマンドの完全なリストを入手するには, 次のようにします:
|
||||
<tscreen><verb>
|
||||
% mail majordomo@FreeBSD.ORG
|
||||
help
|
||||
^D
|
||||
</verb></tscreen>
|
||||
再度言いますが, 私たちは技術的なメーリングリストでは技術的な議論を保つよう
|
||||
要求します. もし, 「高いレベル」にのみ興味があるなら, freebsd-announce
|
||||
に参加するように勧めます. これは少ないトラフィックの予定です.
|
||||
|
||||
<sect1><heading>メーリングリストの憲章<label id="eresources:charters"></heading>
|
||||
|
||||
<p><bf>全て</bf>FreeBSDメーリングリストは誰でもそれらを利用することに
|
||||
固守しなければいけないという一定の簡単なルールがあります. これらのルー
|
||||
ルに従わないと, 結果としてFreeBSDの<url
|
||||
url="mailto:postmaster@freebsd.org" name="Postmaster">から2回までは警
|
||||
告を受けます. 3回違反すると, 投稿者は全てのFreeBSDのメーリングリストか
|
||||
ら削除され, そのメーリングリストへのさらなる投稿から締め出されるでしょ
|
||||
う. これらのルールや対策が必要なのは残念です. しかし,今日のインターネッ
|
||||
トはずいぶんいやらしい環境になっており, 一般の人々は, その(対策の)メカ
|
||||
ニズムがいかにもろいかという事すら認識する事が出来ていないと思われます.
|
||||
|
||||
<p>道標
|
||||
<itemize>
|
||||
<item>いかなる投稿記事もそのメーリングリストの基本的な憲章を守るべきで
|
||||
す. 例えば, そのメーリングリストが技受的な問題に関するものであ
|
||||
れば, 技術的な議論を含む投稿でなければなりません. 現在継続中の
|
||||
不適切な憲章やフレイムは, 所属している全ての人に対してメーリングリスト
|
||||
の価値を下げてしまうだけですし, 許される行為ではないでしょう.
|
||||
とくに話題のない自由形式の議論に対しては<url
|
||||
url="mailto:freebsd-chat@freebsd.org" name="freebsd-chat">メーリ
|
||||
ングリストが自由に認可されているので, かわりに使うべきでしょう.</item>
|
||||
|
||||
<item>2つのメーリングリストに送るはっきりとした明確な必要性が存在する
|
||||
時, 2つ以上のメーリングリストに投稿すべきではありません. どのリ
|
||||
ストに対しても, (メーリングリストの)参加者は(複数のメーリングリ
|
||||
ストに)重複して参加しており, 関連する部分が少ない(例えば,
|
||||
"-stable と - scsi")メーリングリストを除いては, 一度に複数のメー
|
||||
リングリストに投稿する理由は全くありません. もし, Ccに複数の
|
||||
メーリングリストがそのような形で現れて, あなたに届いたのであれば,
|
||||
再びそのメールに返事を出す前に, ccの部分もまた編集するべきです.
|
||||
<em>元記事を書いたのが誰であっても, あなた自身のクロスポストに
|
||||
<bf>まだ</bf>責任があります. </em>
|
||||
|
||||
<item>ユーザであれ開発者であれ, (議論の中で) 個人を攻撃したり冒涜した
|
||||
りすることは許されません. 個人的なメールを引用したり再投稿したり
|
||||
する許可をもらえなかったり, もらえそうにない時に, それをおこなう
|
||||
ようなネチケット (訳注: ネットワークにおけるエチケット) に対する
|
||||
ひどい違反は好まれませんが, してはならないと特別に定められている
|
||||
わけではありません. <bf>しかしながら</bf>, そのような内容がメー
|
||||
リングリストの憲章に沿う場合はほとんどありません。このため、メー
|
||||
リングリストの憲章に違反しているということだけで警告（または禁止）
|
||||
に値するものと考えていいでしょう。
|
||||
|
||||
<item>FreeBSD以外の関連する製品やサービスの広告は, 絶対に禁止し, spam
|
||||
による違反者が宣伝していることが明確であったら, すぐに禁止しま
|
||||
す. </item>
|
||||
|
||||
</itemize>
|
||||
|
||||
<p><bf>個々のメーリングリストの憲章:</bf>
|
||||
|
||||
<p>
|
||||
<descrip>
|
||||
<tag/FREEBSD-ADMIN/ <em>管理上の話題</em><newline>
|
||||
このリストは, 純粋にfreebsd.org関係の議論のためのメーリングリストで,プ
|
||||
ロジェクトの資源の問題や乱用の報告を行ないます. これはクローズドなリ
|
||||
ストですが, 誰でも問題(私達のシステムを含みます!)を報告できます.
|
||||
|
||||
<tag/FREEBSD-ANNOUNCE/ <em>重要なイベント/マイルストン</em><newline>
|
||||
これは, 単にたまに発表される重要なfreebsdのイベントに関心がある人のた
|
||||
めのメーリングリストです. これは, スナップショットやその他のリリースに
|
||||
ついてのアナウンスを含みます. そのアナウンスは新しいFreeBSDの機能のア
|
||||
ナウンスを含んでいます. ボランティア等の呼びかけがあるかもしれませ
|
||||
ん. これは流通量の少ないメーリングリストで, 完全なのモデレートメーリン
|
||||
グリストです.
|
||||
|
||||
<tag/FREEBSD-ARCH/ <em>アーキテクチャと設計の議論</em><newline>
|
||||
これは, FreeBSDの設計に関する議論をする人向けのメーリングリストです.
|
||||
これは, クローズドなリストで, 一般的には参加できません.
|
||||
|
||||
<tag/FREEBSD-BUGS/ <em>バグレポート</em><newline>
|
||||
これは, FreeBSDのバグレポートのためのメーリングリストです. 可能である
|
||||
場合はいつでも, バグは ``send-pr(1)'' を使うか, <url
|
||||
url="http://www.freebsd.org/send-pr.html" name="WEB interface">を用い
|
||||
て送られる必要があります.
|
||||
|
||||
<tag/FREEBSD-CHAT/ <em>FreeBSDのコミュニティに関する
|
||||
技術的ではない話題</em><newline>
|
||||
このメーリングリストは技術的ではなく, 社会的な情報について,
|
||||
他のメーリングリストでは取り扱わない話題を含みます.
|
||||
これは, Jordanがシロイタチに似ているかどうか,
|
||||
大文字で打つかどうか, 誰がたくさんコーヒーを飲むか,
|
||||
どこのビールが一番うまいか, 誰が地下室でビールを作っているか,
|
||||
などについての議論を含みます. 時々重要なイベント (将来開催されるパーティーや,
|
||||
結婚式, 誕生日, 新しい仕事など) のお知らせが, 技術的なメーリングリストから
|
||||
でてきます. しかし, フォローは直接 -chatメーリングリストにするべきです.
|
||||
|
||||
<tag/FREEBSD-CORE/ <em>FreeBSDコアチーム</em><newline>
|
||||
これは, コアメンバが使う内部メーリングリストです. FreeBSDに関連する深
|
||||
刻なやっかい事の裁定やハイレベルな綿密な調査を要求するときに, このメー
|
||||
リングリストにメッセージを送る事が出来ます.
|
||||
|
||||
<tag/FREEBSD-CURRENT/ <em>FreeBSD-currentの使用に関する議論
|
||||
</em><newline>これは freebsd-current のユーザのためのメーリングリストです.
|
||||
メーリングリストでの話題は, -current で登場した新しい機能について,
|
||||
その新機能によってユーザに影響することについての注意, および -current
|
||||
のままでいるために必要な手順についての説明を含みます.
|
||||
"current" を走らせている人はこのメーリングリストに登録しなくてはなりません.
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-CURRENT-DIGEST/ <em>FreeBSD-currentの使用に関する議論
|
||||
</em><newline> freebsd-currentメーリングリストのダイジェスト版です. こ
|
||||
のダイジェストはfreebsd-currentに送られたすべてのメッセージをまとめた
|
||||
ものを, 1つのメールにして送り出します. 平均のサイズは約40kbyteです. こ
|
||||
のメーリングリストは<bf>読み専用</bf>で, メールを送るような事はしない
|
||||
で下さい.
|
||||
|
||||
<tag/FREEBSD-STABLE/ <em>FreeBSD-stableの使用に関する議論
|
||||
</em><newline>これは freebsd-stable のユーザ用のメーリングリストです.
|
||||
メーリングリストでの話題は, -stable で登場した新しい機能について, そ
|
||||
の新機能によってユーザに影響することについての注意, および -stable
|
||||
のままでいるために必要な手順についての説明を含みます.
|
||||
"stable" を走らせている人はこのメーリングリストに登録すべきです.
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-DOC/ <em>ドキュメンテーションプロジェクト</em><newline>
|
||||
このメーリングリストはFreeBSD Doc Projectに属し,
|
||||
ドキュメンテーションに関連する問題やプロジェクトの議論のためのものです.
|
||||
|
||||
<tag/FREEBSD-FS/ <em>ファイルシステム</em><newline>
|
||||
FreeBSDのファイルシステムに関する議論
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-HACKERS/ <em>技術的な議論</em><newline>
|
||||
これはFreeBSDに関する技術的な議論のためのフォーラムです.
|
||||
これは最もテクニカルなメーリングリストです.
|
||||
このメーリングリストは, FreeBSD 上でアクティブに活動をしている人のためのもので,
|
||||
問題を持ち出したり, 代わりの解決法を議論します.
|
||||
技術的な議論をフォローするのに興味がある人も歓迎します.
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-HACKERS-DIGEST/ <em>技術的な議論</em><newline>
|
||||
freebsd-hackersメーリングリストのダイジェスト版です. このダイジェスト
|
||||
はfreebsd-hackersに送られたすべてのメッセージをまとめたものを, 1つのメー
|
||||
ルにして送り出します. 平均のサイズは約40kbyteです. このメーリングリス
|
||||
トは<bf>読み専用</bf>で, メールを送るような事はしないで下さい.
|
||||
|
||||
<tag/FREEBSD-HARDWARE/ <em>FreeBSDのハードウェアの一般的な議論
|
||||
</em><newline> FreeBSDが走っているハードウェアのタイプや,
|
||||
何を買ったり避けたりするかに関する様々な問題や, 提案に関する議論.
|
||||
|
||||
<tag/FREEBSD-INSTALL/ <em>インストールに関する議論</em><newline>
|
||||
このメーリングリストは将来のリリースのインストールに関する開発の
|
||||
議論のためのもので, クローズドなメーリングリストです.
|
||||
|
||||
<tag/FREEBSD-ISP/ <em>インターネットサービスプロバイダのについての話題
|
||||
</em><newline>このメーリングリストは, FreeBSDを用いたインターネット
|
||||
サービスプロバイダ (ISP) に関する話題の議論のためのものです.
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-MULTIMEDIA/ <em>マルチメディアについての議論</em><newline>
|
||||
このメーリングリストはFreeBSD上を用いたマルチメディアアプリケーションについてのフォーラムです.
|
||||
マルチメディアアプリケーションをとりまく議論の中心は, それらのインストール,
|
||||
開発, そしてFreeBSDにおけるサポートについてです.
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-PLATFORMS/ <em>Intel以外のプラットフォームへの移植
|
||||
</em><newline>クロスプラットフォームのFreeBSDの問題.
|
||||
Intel以外のプラットフォームへのFreeBSDの移植についての一般的な議論や提案.
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-PORTS/ <em>``ports'' の議論</em><newline>
|
||||
FreeBSD の ``ports コレクション'' (/usr/ports) や, 移植の提案,
|
||||
ports コレクションの基盤の変更, 一般的な整合化活動についての議論.
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-QUESTIONS/ <em>ユーザからの質問</em><newline>
|
||||
FreeBSDに関する質問のためののメーリングリストです.
|
||||
その質問がかなり技術的だと思わないのであれば,
|
||||
「どのようにして」という質問を技術的なメーリングリストに送るべきではありません.
|
||||
|
||||
<tag/FREEBSD-QUESTIONS-DIGEST/ <em>ユーザからの質問</em><newline>
|
||||
freebsd-questionsメーリングリストのダイジェスト版です.
|
||||
このダイジェストはfreebsd-questionsに送られたすべてのメッセージをまとめたものを,
|
||||
1つのメールにして送り出します. 平均のサイズは約40kbyteです.
|
||||
|
||||
<tag/FREEBSD-SCSI/ <em>SCSIサブシステム</em><newline>
|
||||
これはFreeBSDのためのscsiサブシステムについて作業している人向けです.
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-SECURITY/ <em>セキュリティの関連の話題</em><newline>
|
||||
FreeBSDコンピュータのセキュリティの話題 (DES, Kerberos, よく知られている
|
||||
セキュリティホールや, それらのふさぎ方など)
|
||||
これは技術的なメーリングリストなので, 完全に技術的な内容を要求します.
|
||||
|
||||
<tag/FREEBSD-SECURITY-NOTIFICATIONS/ <em>セキュリティ関連の通知</em><newline>
|
||||
FreeBSD のセキュリティ問題や, 修正に関する通知を行ないます.
|
||||
このメーリングリストは議論を行なうためのメーリングリストではありません.
|
||||
議論は FreeBSD-security で行ないます.
|
||||
|
||||
<tag/FREEBSD-USER-GROUPS/ <em>ユーザグループの調整のメーリングリスト</em><newline>
|
||||
これは, ローカルなユーザグループがお互いに, または,
|
||||
コアチームが指定した個人と問題を議論する,
|
||||
それぞれのローカルエリアのユーザグループからの調整人向けの
|
||||
メーリングリストです.
|
||||
このメーリングリストはユーザグループ間の
|
||||
ミーティングの概要やプロジェクトの調整に制限されるべきです.
|
||||
これはクローズドなメーリングリストです.
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect>
|
||||
<heading>Usenet ニュースグループ<label id="eresources:news"></heading>
|
||||
|
||||
<p>2つのFreeBSD用のニュースグループがあります. ここでは
|
||||
FreeBSDの議論をするたくさんの様々な人がおり,
|
||||
他にもFreeBSD関連するユーザがいます.
|
||||
これらのいくつかのニュースグループは Warren Toomey
|
||||
<tt><wkt@cs.adfa.oz.au></tt> によって <url
|
||||
url="http://minnie.cs.adfa.oz.au/BSD-info/bsdnews_search.html"
|
||||
name="Keyword searchable archives"> で,
|
||||
検索できるようになっています.
|
||||
|
||||
<sect1>
|
||||
<heading>BSD用のニュースグループ</heading>
|
||||
|
||||
<p><itemize>
|
||||
<item><url url="news:comp.unix.bsd.freebsd.announce"
|
||||
name="comp.unix.bsd.freebsd.announce"></item>
|
||||
<item><url url="news:comp.unix.bsd.freebsd.misc"
|
||||
name="comp.unix.bsd.freebsd.misc"></item>
|
||||
</itemize>
|
||||
|
||||
<sect1>
|
||||
<heading>関連する他のUnixのニュースグループ</heading>
|
||||
|
||||
<p><itemize>
|
||||
<item><url url="news:comp.unix" name="comp.unix"></item>
|
||||
<item><url url="news:comp.unix.questions" name="comp.unix.questions"></item>
|
||||
<item><url url="news:comp.unix.admin" name="comp.unix.admin"></item>
|
||||
<item><url url="news:comp.unix.programmer" name="comp.unix.programmer"></item>
|
||||
<item><url url="news:comp.unix.shell" name="comp.unix.shell"></item>
|
||||
<item><url url="news:comp.unix.user-friendly" name="comp.unix.user-friendly"></item>
|
||||
<item><url url="news:comp.security.unix" name="comp.security.unix"></item>
|
||||
<item><url url="news:comp.sources.unix" name="comp.sources.unix"></item>
|
||||
<item><url url="news:comp.unix.advocacy" name="comp.unix.advocacy"></item>
|
||||
<item><url url="news:comp.unix.misc" name="comp.unix.misc"></item>
|
||||
<item><url url="news:comp.os.386bsd.announc" name="comp.os.386bsd.announc"></item>
|
||||
<item><url url="news:comp.os.386bsd.app" name="comp.os.386bsd.app"></item>
|
||||
<item><url url="news:comp.os.386bsd.bugs" name="comp.os.386bsd.bugs"></item>
|
||||
<item><url url="news:comp.os.386bsd.development" name="comp.os.386bsd.development"></item>
|
||||
<item><url url="news:comp.os.386bsd.misc" name="comp.os.386bsd.misc"></item>
|
||||
<item><url url="news:comp.os.386bsd.questions" name="comp.os.386bsd.questions"></item>
|
||||
<item><url url="news:comp.bugs.4bsd" name="comp.bugs.4bsd"></item>
|
||||
<item><url url="news:comp.bugs.4bsd.ucb-fixes" name="comp.bugs.4bsd.ucb-fixes"></item>
|
||||
<item><url url="news:comp.unix.bsd" name="comp.unix.bsd"></item>
|
||||
</itemize>
|
||||
|
||||
<sect1>
|
||||
<heading>X Window システム</heading>
|
||||
|
||||
<p><itemize>
|
||||
<item><url url="news:comp.windows.x.i386unix" name="comp.windows.x.i386unix"></item>
|
||||
<item><url url="news:comp.windows.x" name="comp.windows.x"></item>
|
||||
<item><url url="news:comp.windows.x.apps" name="comp.windows.x.apps"></item>
|
||||
<item><url url="news:comp.windows.x.announce" name="comp.windows.x.announce"></item>
|
||||
<item><url url="news:comp.windows.x.intrinsics" name="comp.windows.x.intrinsics"></item>
|
||||
<item><url url="news:comp.windows.x.motif" name="comp.windows.x.motif"></item>
|
||||
<item><url url="news:comp.windows.x.pex" name="comp.windows.x.pex"></item>
|
||||
<item><url url="news:comp.emulators.ms-windows.wine" name="comp.emulators.ms-windows.wine"></item>
|
||||
</itemize>
|
||||
|
||||
<sect>
|
||||
<heading>World Wide Web サイト<label id="eresources:web"></heading>
|
||||
|
||||
<p><itemize>
|
||||
<item><url url="http://www.FreeBSD.ORG/"> <bf>- 本家のサーバ</bf>.</item>
|
||||
<item><url url="http://www.au.freebsd.org/FreeBSD/"> <bf>- オーストラリア</bf>.</item>
|
||||
<item><url url="http://www.br.freebsd.org/"> <bf>- ブラジル</bf>.</item>
|
||||
<item><url url="http://www.ca.freebsd.org/"> <bf>- カナダ</bf>.</item>
|
||||
<item><url url="http://sunsite.mff.cuni.cz/www.freebsd.org/"><bf>- チェコ</bf>.</item>
|
||||
<item><url url="http://sunsite.auc.dk/www.freebsd.org/"> <bf>- デンマーク</bf>.</item>
|
||||
<item><url url="http://www.ee.freebsd.org/"> <bf>- エストニア</bf>.</item>
|
||||
<item><url url="http://www.fi.freebsd.org/"> <bf>- フィンランド</bf>.</item>
|
||||
<item><url url="http://www.de.freebsd.org/"> <bf>- ドイツ</bf>.</item>
|
||||
<item><url url="http://www.ie.freebsd.org/"> <bf>- アイルランド</bf>.</item>
|
||||
<item><url url="http://www.jp.freebsd.org/"> <bf>- 日本</bf>.</item>
|
||||
<item><url url="http://www.kr.freebsd.org/"> <bf>- 韓国</bf>.</item>
|
||||
<item><url url="http://www.nl.freebsd.org/"> <bf>- ニュージーランド</bf>.</item>
|
||||
<item><url url="http://www.pt.freebsd.org/"> <bf>- ポルトガル</bf>.</item>
|
||||
<item><url url="http://www.se.freebsd.org/www.freebsd.org/"> <bf>- スウェーデン</bf>.</item>
|
||||
<item><url url="http://www.tw.freebsd.org/freebsd.html"> <bf>- 台湾</bf>.</item>
|
||||
</itemize>
|
||||
</sect>
|
||||
@ -1,418 +0,0 @@
|
||||
<!-- $Id: esdi.sgml,v 1.4 1997/02/22 13:00:58 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.10 -->
|
||||
|
||||
<!--
|
||||
<title>ESDIハードディスクの紹介と FreeBSDでの利用</title>
|
||||
<author>(c) 1995, Wilko Bulte, <tt/wilko@yedi.iaf.nl/
|
||||
<date>Tue Sep 12 20:48:44 MET DST 1995</date>
|
||||
|
||||
Copyright 1995, Wilko C. Bulte, Arnhem, The Netherlands
|
||||
|
||||
<abstract>
|
||||
この文書で解説するのは, ESDIハードディスクを FreeBSDオペレーティングシ
|
||||
ステムとの組み合わせで利用することについてです. 一般的に信じられている
|
||||
こととは違い, ESDIハードディスクを FreeBSDで利用することは可能です. 実
|
||||
際, ESDIを利用したシステムをうまく使っている人たちが存在します! この
|
||||
文書をとおして, ESDIハードディスクをいかに使うのかを紹介していきたいと
|
||||
思います.
|
||||
|
||||
この文書のなかで, もし欠落しているものや単純な間違い, あるいは文書をよ
|
||||
りよいものにするための有効なご意見がございましたら, ぜひ
|
||||
<tt/wilko@yedi.iaf.nl/ までメールにてお知らせください.
|
||||
</abstract>
|
||||
-->
|
||||
|
||||
<sect1><heading>ESDIハードディスクの使い方<label id="esdi"></heading>
|
||||
|
||||
<p><em>原作および Copyright © 1995, &a.wilko;.<newline>24 September 1995.</em>
|
||||
|
||||
<p><em>訳: &a.ts;<newline>2 September 1996.</em>
|
||||
|
||||
ESDIとは Enhanced Small Device Interfaceの略語です. この技術は, 馴染み
|
||||
深い ST506や ST412といったインタフェースに基づくものであり, 世界初の普
|
||||
及型 5.25インチのウィンチェスタディスクを造ったSeagate Technology社に
|
||||
よって最初に作られました.
|
||||
|
||||
ESDIの Eは拡張 (Enhanced) を表しており, 実際そのとおりです. まず, イン
|
||||
タフェースの速度は速く, 10 ないし 15Mビット/秒であり, ST412インタフェー
|
||||
スに接続したドライブの 5Mビット/秒よりも高速です. また, 上位レベルのコ
|
||||
マンドがいくつか追加されて, オペレーティングシステムレベルのドライバ作
|
||||
成者にとって, ESDIインタフェースはある程度インテリジェントなものとなり
|
||||
ました. ただし SCSIほどにインテリジェントではありません. ESDIは ANSIが
|
||||
標準化をおこなっています.
|
||||
|
||||
トラックごとのセクタ数を増やすことで, ESDIドライブの記憶容量は引き上げ
|
||||
られました. 通常, トラックあたり 35セクタですが, 今までに筆者がみたド
|
||||
ライブの中で大容量のものは, トラックあたり 54セクタもありました.
|
||||
|
||||
ESDIは IDEや SCSIといったインタフェースの普及によって消えつつあります
|
||||
が, 無料あるいは在庫処分の格安なドライブが入手可能であることを考えると,
|
||||
少ない (もしくは現状の) 予算で縛られたシステムにとって, ESDIドライブは
|
||||
理想的です.
|
||||
|
||||
<sect2><heading>ESDIのコンセプト</heading>
|
||||
<p>
|
||||
<sect3><heading>物理的な接続</heading>
|
||||
<p>
|
||||
ESDIインタフェースでは, ドライブごとに2つのケーブルを接続します. 第 1
|
||||
のケーブルは34ピンのフラットケーブルエッジコネクタで, コントローラとド
|
||||
ライブ間のコマンドおよびステータスの両信号のやりとりのためのものです.
|
||||
コマンド用ケーブルは, すべての ESDIドライブをデイジーチェーンで結び
|
||||
ますから, すべてのドライブを接続したバスを構成することになります.
|
||||
|
||||
第2のケーブルは20ピンのフラットケーブルエッジコネクタで, ドライブへの
|
||||
データ入出力に使います. このケーブルは放射状に接続しますから, ドライブ
|
||||
ごとにコントローラへの専用接続を持つことになるわけです.
|
||||
|
||||
筆者の経験によれば, PC向け ESDIコントローラには, コントローラあたり最
|
||||
大 2 台までのデバイス接続が可能という制限がありました. これは, ドライ
|
||||
ブのアドレス割り当てのために, 単一ビットだけを用意したという WD1003か
|
||||
ら持ち越された互換 (?) 機能なのだと思われます.
|
||||
|
||||
<sect3><heading>デバイスのアドレス指定</heading>
|
||||
<p>
|
||||
1本のコマンドケーブルには最大で 7つのデバイスと 1つのコントローラを接
|
||||
続することができます. どのドライブをコントローラがアドレスしているのか
|
||||
を個別に認識できるようにするために, ESDIデバイスは, デバイスアドレスを
|
||||
設定するためのジャンパかスイッチを備えています.
|
||||
|
||||
PC向けコントローラでは, 最初のドライブにはアドレス0を設定し, 第2番目の
|
||||
ディスクへはアドレス1を設定します. <it>いつも留意すべきことは, </it>
|
||||
ディスクごとに固有のアドレスを必ず設定するということです! つまり, コン
|
||||
トローラあたり最大2台のドライブというような PC向けのものでは, 第1 ドラ
|
||||
イブは第0番ドライブで, 第2ドライブは第1番ドライブだということです.
|
||||
|
||||
<sect3><heading>ターミネート処理 (termination)</heading>
|
||||
<p>
|
||||
デイジーチェーン接続用コマンドケーブル (34ピンのケーブルであることを覚
|
||||
えていますか? ) では, 最後のチェーン接続ドライブでターミネートしなけれ
|
||||
ばなりません. このために, ESDIドライブにはターミネート用抵抗ネットワー
|
||||
クが付属しており, ターミネートする必要がないときにはその抵抗をドライブ
|
||||
から外したり, またはジャンパで無効 (disable) にすることができるようになっ
|
||||
ています.
|
||||
|
||||
したがって, ひとつのドライブ, すなわちコマンドケーブルの最終端に位置す
|
||||
るドライブだけが, そのターミネート用抵抗を有効 (installまたは enable)
|
||||
にすることができます. コントローラは自動的にコマンドケーブルのもう一方
|
||||
の端のターミネート用抵抗を有効にします. ご注意いただきたいのは, コント
|
||||
ローラは必ずコマンドケーブルのいずれかの端に位置しなければならず, けっ
|
||||
して途中に位置するようにしては <it>いけない</it> ということです.
|
||||
|
||||
<sect2><heading>ESDIディスクの FreeBSDでの使い方</heading>
|
||||
<p>
|
||||
ESDIを初めて動かすようにすることが, どうしてこうも大変なことなのでしょ
|
||||
うか ?
|
||||
|
||||
ESDIディスクを FreeBSDで動かそうと試みた人たちが激烈なイライラを募らせ
|
||||
たことは知られています. 今までまったく ESDIを知らない場合には, 複数の
|
||||
要因の組み合わせが悪く働いて, ESDIへの理解を妨げることになるかもしれま
|
||||
せん.
|
||||
|
||||
このことは, ESDIと FreeBSDの組み合わせは選んではいけないという俗説も生
|
||||
み出しました. 以下の節において, 落し穴のすべてとその解決策を
|
||||
述べてみようと思います.
|
||||
|
||||
<sect3><heading>ESDI速度の違い</heading>
|
||||
<p>
|
||||
すでに簡単に紹介したように, ESDIは2種類の速度を持っています. 旧式のド
|
||||
ライブとコントローラは 10Mビット/秒のデータ転送速度ですが, 新しいもの
|
||||
では 15Mビット/秒が利用できます.
|
||||
|
||||
仮に 10Mビット/秒のコントローラへ 15Mビット/秒のドライブを接続したよ
|
||||
うな場合に問題が生じることを予想することは簡単です. したがって必ず, コ
|
||||
ントローラ <it>および</it> ドライブのマニュアルを参照して, それぞれの
|
||||
転送速度が一致しているかどうかを調べるようにしてください.
|
||||
|
||||
<sect3><heading>トラックについて</heading>
|
||||
<p>
|
||||
主流の ESDIドライブは, トラックあたり34ないし36個のセクタを持ちます.
|
||||
しかし大部分の (古い) コントローラは36個以上のセクタを扱うことができま
|
||||
せん.
|
||||
|
||||
新しい大容量のドライブでは, トラックごとにさらに多くの数のセクタを持つ
|
||||
ことができます. たとえば筆者の 670MBのドライブは, トラックあたり 54セ
|
||||
クタも持たせることができます.
|
||||
|
||||
筆者のコントローラは54セクタ数をサポートしていませんでしたが, トラック
|
||||
あたり35セクタという設定で, 問題なく動作しました. しかし, これが意味す
|
||||
るのは大量のディスク容量を失うということです.
|
||||
|
||||
もう一度, 詳しい情報についてハードウェアのドキュメントを調べてください.
|
||||
この例のような仕様からはずれた設定をしたときには, うまく動くかもしれま
|
||||
せんが, 動かないこともあります. そのようなときには, 別のより多くの機能
|
||||
をもつコントローラで試してみるようにしてください.
|
||||
|
||||
<sect3><heading>ハードセクタとソフトセクタ</heading>
|
||||
<p>
|
||||
多くの ESDIドライブでは, ハードセクタまたはソフトセクタによる処理を,
|
||||
ジャンパ設定で指定することができます. ハードセクタとは, 新しいセクタの
|
||||
開始位置において, ESDIドライブにセクタパルス (sector pulse) を発生させ
|
||||
ることです. コントローラはこのパルスを利用して, 書き込みや読み取りのタ
|
||||
イミングを指示します.
|
||||
|
||||
ハードセクタではセクタのサイズを選ぶことができます (通常はフォーマット
|
||||
後セクタあたり256, 512, および1024バイト). FreeBSDは512バイトのセクタ
|
||||
サイズを使います. トラックあたりのセクタ数は, 同じように選択に幅があり
|
||||
ますが, フォーマット後のセクタのバイト数はすべて同じです. セクタごとの
|
||||
<em>未フォーマット</em> のバイト数は, コントローラがどの程度の調整用の
|
||||
バイト数を必要とするかによって異なります. トラックあたりのセクタ数を多
|
||||
くすれば記憶容量は増えますが, もしドライブから与えられるバイト数よりも
|
||||
多くのものをコントローラが必要とするのであれば, 問題を生じることがあり
|
||||
ます.
|
||||
|
||||
ソフトセクタでは, コントローラ自身が読み書きの始まりと終りの位置を決め
|
||||
ます. なお, ESDI (筆者が知り得たものすべて) では, ハードセクタがデフォ
|
||||
ルトのようです. ソフトセクタを試みる必要性は感じたことがありません.
|
||||
|
||||
通常, FreeBSDをインストールする以前に, まずセクタ処理の設定を試される
|
||||
ことをおすすめします. というのも, セクタ処理の設定を変えるたびに, 物理
|
||||
フォーマット (low-level format) をしなければならないからです.
|
||||
|
||||
<sect3><heading>物理フォーマット処理</heading>
|
||||
<p>
|
||||
ESDIドライブは, 使い始める前に, 物理フォーマットをおこなう必要があります.
|
||||
もしトラックあたりのセクタ数を変えたり, ドライブの物理的な設置方法 (水
|
||||
平や垂直方向) を変えたときには, ふたたびフォーマットする必要があります
|
||||
から, よく検討した後でフォーマットしてください. フォーマット処理の所要
|
||||
時間を短く予想してはいけません. 大容量のディスクでは数時間を要します.
|
||||
|
||||
物理フォーマットが終わったならば, サーフィススキャン (surface scan) を
|
||||
おこない, バッドセクタの検出とフラグの処理をします. ほとんどのディスクには,
|
||||
メーカが作成したバッドブロックリストを記録した用紙またはステッカーが付
|
||||
いています. さらに, ほとんどのディスク内にもバッドブロックリストが記録
|
||||
されています. メーカが作成したリストを利用するようにしてください. この
|
||||
時点で不良部分をマップし直す方が, FreeBSDのインストール後におこなうよりも,
|
||||
はるかに簡単です.
|
||||
|
||||
物理フォーマットプログラムのなかでも, トラックの中にひとつでもバッドセ
|
||||
クタがあれば, 同じトラック内の残りのすべてのセクタを不良とするようなプ
|
||||
ログラムがありますから, そのようなものは利用しないようにしてください.
|
||||
ディスクスペースの浪費だけでなく, より重大な bad144と関連した悲劇の原
|
||||
因にもなるからです (bad144の節を参照のこと).
|
||||
|
||||
<sect3><heading>トランスレーション</heading>
|
||||
<p>
|
||||
トランスレーションが, ESDIだけに限定された問題ではないにもかかわらず,
|
||||
重大な困難になることがあります. トランスレーションにはいくつかの側面が
|
||||
あります. 多くに共通なものは, IBM PC/ATのオリジナルの設計に起因するディ
|
||||
スクジオメトリに関する制限を, うまく回避するような調整を試みるものです
|
||||
(IBM に感謝 ! ).
|
||||
|
||||
まずはじめに, 1024シリンダに関する (悪) 名高い制限があります. すなわ
|
||||
ち, ブート可能なシステムについて, システム関連ファイルは (オペレーティ
|
||||
ングシステムがどのようなものであっても) , ディスクの先頭部分の 1024シ
|
||||
リンダ内になければいけない, という制限です. シリンダ番号を表すためには
|
||||
10ビットしか与えられていません. セクタの総数については, 上限は 64 (0か
|
||||
ら 63) です. この1024シリンダの制限を, 16ヘッドの制限 (これも ATの仕様
|
||||
による) と組み合わせると, かなり限定されたディスク容量しか利用できませ
|
||||
ん.
|
||||
|
||||
この難点を解消するために, PC 向け ESDIコントローラのメーカは, 自社のコ
|
||||
ントローラボードへ BIOS PROM拡張を施しました. この BIOS拡張の内容は,
|
||||
ブート時のディスクI/Oを (OSによっては <it>すべて</it> のディスクI/Oも)
|
||||
, トランスレーションを用いておこなうというものです. すなわち, 大容量のディ
|
||||
スクを, あたかも32ヘッドかつトラックあたり64セクタであるようなデバイス
|
||||
として OSへ知らせるのです. この結果, 総シリンダー数は 1024よりも少なく
|
||||
なりますから, 上記の難点などなかったものとして大容量ディスクを使うこと
|
||||
ができるようになります. なお, 注目いただきたいことは, FreeBSDカーネル
|
||||
の起動以降, FreeBSDはこの BIOS拡張機能を使わないということです. 詳しく
|
||||
は後ほどご説明いたします.
|
||||
|
||||
トランスレーションの第2の存在理由は, 多くの旧いシステムBIOSが, トラッ
|
||||
クあたり17セクタのドライブだけしか扱えない (ST412という古い仕様) から,
|
||||
というものです. 比較的新しい BIOSは通常, 自由な値を設定できるドライブ
|
||||
タイプ (多くの場合ドライブタイプ47) を持っています.
|
||||
|
||||
<em>この文書を読み終えられた後で, どのようにトランスレーションを利用す
|
||||
るにせよ, ぜひご留意いただきたいことがあります. もし複数の OSをひとつ
|
||||
のディスクにインストールするときには, 必ず同じトランスレーションを使わ
|
||||
なければなりません. </em>
|
||||
|
||||
トランスレーションに関して, 筆者が使用したコントローラは, ひとつのドラ
|
||||
イブを複数のパーティションに論理的に分けることができる機能を BIOSのオ
|
||||
プションとして持っていました (このような製品はいくつかあると思われる).
|
||||
しかし, ひとつのドライブにはひとつのパーティションに限定しました. なぜ
|
||||
なら, このコントローラはパーティション情報をディスクへ書き出すからです.
|
||||
つまり, 電源を入れると, コントローラはこの情報を読み取り, OSに対してディ
|
||||
スクから読みとった情報に基づくデバイスとして知らせるからです.
|
||||
|
||||
<sect3><heading>代替セクタ処理</heading>
|
||||
<p>
|
||||
多くの ESDIコントローラはバッドセクタを取り替える機能を備えています.
|
||||
ディスクの物理フォーマット処理の途中もしくは終了時に, バッドセクタであ
|
||||
ることを記録して, 代わりのセクタを壊れたセクタの位置へ (論理的に) 置き
|
||||
ます.
|
||||
|
||||
通常この置き換え処理は, トラック内のN-1個のセクタを実際のデータ記録に
|
||||
使い, 第N番目のセクタだけを代替セクタとすることで実現します. ここでNと
|
||||
いう値はトラック内の物理的セクタの総数です. このアイデアが生まれた背景
|
||||
は, オペレーティングシステムが壊れたセクタを持たない「完全」なディスク
|
||||
を想定している, というものです. しかし FreeBSDではこのアイデアを使うこ
|
||||
とはできません.
|
||||
|
||||
理由は, <it>使用不可 (bad)</it> から <it>使用可能</it> への変換をおこなう
|
||||
のが ESDIコントローラ上の BIOSだからなのです. FreeBSDは, 真の 32ビット
|
||||
のオペレーティングシステムであるために, ブート後には BIOSを使いません.
|
||||
代わりに FreeBSDが使うのは, ハードウェアと直接「対話」するデバイスドラ
|
||||
イバというものです.
|
||||
|
||||
<em>結論: 代替セクタ処理やバッドブロックマッピングなど, コントローラ・
|
||||
メーカがなんと呼ぶかは判りませんが, それらに似た機能を FreeBSDのディス
|
||||
クへは使わないでください. </em>
|
||||
|
||||
<sect3><heading>バッドブロックの取り扱い</heading>
|
||||
<p>
|
||||
前節から残された問題があります. すなわち, コントローラによるバッドブロッ
|
||||
ク処理は利用できない状況であるにもかかわらず, FreeBSDのファイルシステ
|
||||
ムが想定しているのはあくまで完全無欠なディスクである, という問題で
|
||||
す. これを解消するために, FreeBSDは <it>bad144</it> というツールを採用
|
||||
しています. この bad144 (この名前は DEC社の標準となったバッドブロック
|
||||
処理に由来している) は, FreeBSDのスライスごとにバッドブロックを調べま
|
||||
す. バッドブロックを見つけ出すと, bad144は傷ついたブロック番号によるテー
|
||||
ブルを FreeBSDスライスの末尾へ書き込みます.
|
||||
|
||||
ディスクが動作し始めると, ディスクから読みとられたテーブルを基に, ディ
|
||||
スクアクセスを調べます. この bad144リストに記録されたブロック番号への
|
||||
要求が起こると, 代わりのブロック (同じく FreeBSDスライスの末尾に位置す
|
||||
る) を使います. このように, bad144による置換手続きによって「完全」なディ
|
||||
スクを FreeBSDファイルシステムへ提供しているのです.
|
||||
|
||||
Bad144の使用により陥るかもしれない落し穴があります. まず, ひとつのス
|
||||
ライスには126個以上のバッドセクタを持てません. もしドライブに126個以上
|
||||
のバッドセクタがあったときには, 複数の FreeBSDのスライスに分けて, 各ス
|
||||
ライスのバッドセクタが126個以下となるようにする必要があります. くれぐ
|
||||
れも, ひとつのトラック内にたったひとつの欠陥セクタが見つかっただけで,
|
||||
そのトラック内セクタ <em>すべて</em> を傷ついたものとして記録するよう
|
||||
な物理フォーマットプログラムを使わないようにしてください. 簡単にお解り
|
||||
いただけると思いますが, このような物理フォーマットをおこなえば, 126個の制
|
||||
限は短時間で達成してしまいます.
|
||||
|
||||
次に, もしスライスが rootファイルシステムを含んでいるときには, 1024シ
|
||||
リンダ以内という BIOSの制限を守っていなければなりません. ブート処理の
|
||||
ときですから, bad144リストは BIOSを使って読み取りますので, このリスト
|
||||
が1024シリンダ限界以内に位置していなければ読みとれません. <em>注意
|
||||
</em> いただきたいのは, この制限は root <em>ファイルシステム</em> だけ
|
||||
が1024シリンダ限界以内にあれば十分ということではなく, rootシステムを含
|
||||
んだ <em>スライス</em> 全体が1024シリンダ限界以内におさまっている必要
|
||||
があります.
|
||||
|
||||
<sect3><heading>カーネルのコンフィグレーション</heading>
|
||||
<p>
|
||||
ESDIディスクを扱うドライバは, IDEや ST412 MFMディスクなどと同じ
|
||||
<it>wd</it> ドライバです. この <it>wd</it> ドライバは, すべての WD1003
|
||||
互換インタフェースにも利用できるはずです.
|
||||
|
||||
大部分のハードウェアは, ジャンパの設定によって, ふたつの I/Oアドレス範
|
||||
囲と IRQ値のうちから, それぞれひとつを選ぶことができます. したがって,
|
||||
wdタイプのふたつのコントローラをひとつのシステムで使うことができます.
|
||||
|
||||
もし設定しようとしているハードウェアが標準以外の割り当てをサポートして
|
||||
いれば, 適切な設定情報をカーネルのコンフィグレーションファイルに記述す
|
||||
ることで, この非標準割り当てを利用できます. 次にカーネルのコンフィグレー
|
||||
ションファイルの例を示します (このファイルがあるディレクトリは
|
||||
<tt>/sys/i386/conf</tt> である).
|
||||
|
||||
<tscreen><verb>
|
||||
# First WD compatible controller
|
||||
controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
|
||||
disk wd0 at wdc0 drive 0
|
||||
disk wd1 at wdc0 drive 1
|
||||
|
||||
# Second WD compatible controller
|
||||
controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr
|
||||
disk wd2 at wdc1 drive 0
|
||||
disk wd3 at wdc1 drive 1
|
||||
</verb></tscreen>
|
||||
|
||||
<!--
|
||||
<sect3><heading>Tuning your ESDI kernel setup</heading>
|
||||
<p>
|
||||
-->
|
||||
|
||||
<sect2><heading>ESDIハードウェアの例</heading>
|
||||
<p>
|
||||
<sect3><heading>Adaptec 2320コントローラ</heading>
|
||||
<p>
|
||||
筆者は, ACB-2320でコントロールされた ESDIディスクへ, FreeBSDをインストー
|
||||
ルすることができました. なお, このディスクには他のオペレーティングシス
|
||||
テムをインストールしていません.
|
||||
|
||||
インストールするために, まず, NEFMT.EXE (<it>www.adaptec.com</it> から
|
||||
<it>ftp</it>可能) でディスクを物理フォーマットし, かつトラックを代替セ
|
||||
クタとともにフォーマットするかどうかの設問に NOと答えました. また
|
||||
ACB-2320の BIOSは使わないように設定しました. そしてシステム BIOSがブー
|
||||
トできるように, システム BIOSの「自由に設定可能」オプションを使いまし
|
||||
た.
|
||||
|
||||
実は, NEFMT.EXEを使う以前に, まず ACB-2320 の BIOSに組み込まれているフォー
|
||||
マットプログラムでディスクをフォーマットしてみましたが, 使えないことが
|
||||
判りました. なぜなら, 代替セクタの処理をおこなわないようにするオプションが
|
||||
用意されていないからです. 代替セクタ処理をおこなうようにすると, FreeBSDの
|
||||
インストール作業は bad144の実行の段階で失敗しました.
|
||||
|
||||
もし ACB-232xyをお持ちであれば, そのバージョン番号に注意してください.
|
||||
文字 xには0か2が入りまして, ボード上にフロッピーコントローラがあるかど
|
||||
うかを見分けることができます.
|
||||
|
||||
文字 yはさらに興味深いもので, ブランクか, A-8か, または Dのいずれかで
|
||||
す. ブランクは, 単純な10Mビット/秒のコントローラであることを表します.
|
||||
A-8は, 15Mビット/秒のコントローラで, かつ 52セクタ/トラックをサポート
|
||||
しているものであることを表します. Dは, 15Mビット/秒のコントローラで,
|
||||
かつ 36セクタ/トラック以上 (52セクタも可能か?) のドライブをサポートし
|
||||
ているものであることを表します.
|
||||
|
||||
このコントローラのすべてのバージョンはインターリーブ比 1:1に対応してい
|
||||
るはずです. FreeBSDは充分高速なので, ぜひ 1:1と指定してください.
|
||||
|
||||
<sect3><heading>Western Digital WD1007コントローラ</heading>
|
||||
<p>
|
||||
筆者は, WD1007でコントロールされた ESDIディスクへ, FreeBSDをインストー
|
||||
ルすることができました. 正確には WD1007-WA2というコントローラでした.
|
||||
これ以外の複数のバージョンも WD1007にあります.
|
||||
|
||||
利用できるようにするために, セクタトランスレーションとWD1007の BIOSと
|
||||
を使わないように設定しました. この設定の意味は, BIOSに組み込まれた物理
|
||||
フォーマットプログラムを使えないようにしたということです. 代わりに,
|
||||
<it>www.wdc.com</it>から WDFMT.EXEを入手して, ディスクをフォーマットし
|
||||
ました. 以後, 順調に動いています.
|
||||
|
||||
<sect3><heading>Ultrastor U14Fコントローラ</heading>
|
||||
<p>
|
||||
ネットに流れたいくつかの報告によれば, Ultrastorの ESDIボードも FreeBSD
|
||||
で動作するようです. 実際の設定についての詳しい情報はありません.
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
<sect2><heading>Tracking down problems</heading>
|
||||
<p>
|
||||
-->
|
||||
|
||||
<sect2><heading>追加資料<label id="esdi:further-reading"></>
|
||||
<p>
|
||||
本格的に ESDIのプログラミングを計画している方は, 次の公式規格仕様書を
|
||||
入手なさることをおすすめします.
|
||||
|
||||
最新の ANSI X3T10 委員会の文書は次のものです：
|
||||
|
||||
<itemize>
|
||||
<item>Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991]
|
||||
[X3T10/792D Rev 11]
|
||||
</itemize>
|
||||
|
||||
USENETのニュースグループ <htmlurl url="news:comp.periphs"
|
||||
name="comp.periphs"> は, 詳しい情報を得ることができる注目すべきもので
|
||||
す.
|
||||
|
||||
World Wide Web (WWW) もまた便利な情報源です. Adaptec社の ESDIコントロー
|
||||
ラについては <htmlurl url="http://www.adaptec.com/">を参照ください.
|
||||
Western Digital社のコントローラについては <htmlurl
|
||||
url="http://www.wdc.com/"> を参照ください.
|
||||
|
||||
<sect2>感謝
|
||||
<p>
|
||||
Andrew Gordon氏より, テスト用の Adaptec 2320コントローラと ESDIディス
|
||||
クを送っていただきました.
|
||||
|
||||
|
||||
@ -1,579 +0,0 @@
|
||||
<!-- $Id: firewalls.sgml,v 1.5 1997/02/22 13:00:59 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.17 -->
|
||||
|
||||
<sect><heading> ファイアウォール <label id="firewalls"></heading>
|
||||
|
||||
<p><em>原作: &a.gpalmer;, &a.alex;.</em>
|
||||
<p><em>訳: &a.saeki;.<newline>
|
||||
11 November 1996.</em>
|
||||
|
||||
ファイアウォールは, インターネットに参加している人はもちろんのこと,
|
||||
プライベートネットワークのセキュリティ向上のためのアプリケーションを
|
||||
探している人にとっても, ますます興味深くなりつつある分野です.
|
||||
このセクションではファイアウォールとは何か, ファイアウォールの使用法,
|
||||
そしてファイアウォールを構築するために FreeBSD のカーネルで
|
||||
提供されているファシリティ (機能) の使用法について説明したいと思います.
|
||||
|
||||
<quote><bf> 注: </bf> 社内のネットワークと「巨大かつ信頼のおけない
|
||||
インターネット」との間にファイアウォールを構築することで
|
||||
セキュリティ上のすべての問題が解決できると考える人がいます.
|
||||
ファイアウォールはセキュリティ上の問題を解決する助けになる場合もありますが,
|
||||
充分な設定がなされていないファイアウォールは, まったくファイアウォールを
|
||||
持たない場合よりもセキュリティ上の危険を増大させてしまいます.
|
||||
<!-- (訳注: 増大させてしまう可能性がある程度だと思いますが、十分に理解した
|
||||
上でファイアウォールを構築することが非常に重要です). -->
|
||||
ファイアウォールにできることは, あなたのシステムにもう一つのセキュリティ層を
|
||||
追加することだけで, 本気でアタックをしかけてくるクラッカーが内部ネットワークに
|
||||
侵入するのを妨げることはできません.
|
||||
ファイアウォールを侵入不可能と過信して
|
||||
内部のセキュリティをおろそかにすることは,
|
||||
単にクラッカーの仕事を少し簡単にするだけでしかありません. </quote>
|
||||
|
||||
<sect1><heading> ファイアウォールとは何か ? </heading>
|
||||
|
||||
<p> 現在インターネットで普通に使用されているファイアウォールには
|
||||
二つの異なるタイプがあります.
|
||||
一つは, 厳密には <bf> パケットフィルタリングルータ </bf> と
|
||||
呼ばれるタイプのものです. これはマルチホームのホストマシン (複数の
|
||||
ネットワークに接続されているマシン) のカーネルが, ある規則にしたがって
|
||||
パケットを転送したりブロックしたりするものです.
|
||||
もう一つは, <bf> proxy (代理) サーバ </bf> として知られているタイプのものです.
|
||||
これは, おそらくはマルチホームのホストマシン上で, カーネルによるパケット転送を
|
||||
禁止して, デーモンにより認証の提供とパケットの転送とをおこなうものです.
|
||||
|
||||
<p> 二つのタイプのファイアウォールを組み合わせて使用して,
|
||||
特定のマシン (<bf> 要塞ホスト </bf> と呼ばれる) だけが
|
||||
パケットフィルタリングルータを通して内部ネットワークへ
|
||||
パケットを送ることができるよう設定しているサイトがしばしば存在します.
|
||||
proxy (代理) サービスは通常の認証メカニズムよりもセキュリティを強化してある
|
||||
要塞ホストで動作させます.
|
||||
<!-- (訳注: proxy サービスをおこなうアプリケーションなど,
|
||||
おそらくはあまり実績のないアプリケーションプログラムを利用したサービスを
|
||||
要塞ホスト上で提供するのは避けた方がよいでしょう.
|
||||
proxy サービスを提供する場合には, 要塞ホストとは別の, バリアセグメント上の
|
||||
ホストで proxy サービスを提供し, パケットフィルタリングを利用して
|
||||
サービスの利用を制限するようにした方が安全です.) -->
|
||||
|
||||
<p>FreeBSD は (<tt>IPFW</tt> として知られる) カーネルパケットフィルタ込みで
|
||||
提供されています. このセクションの後の方では, このフィルタについての
|
||||
説明を集中しておこないます.
|
||||
サードパーティから提供されるソフトウェアを使用することにより, Proxy サーバを
|
||||
FreeBSD 上に構築することができます. しかし, 現在入手可能な proxy サーバは
|
||||
たいへんバラエティに富んでいるので, このドキュメントでそれらすべてを
|
||||
カバーすることは不可能です.
|
||||
|
||||
<sect2><heading> パケットフィルタリングルータ <label id="firewalls:packet_filters"></heading>
|
||||
|
||||
<p> ルータとは, 二つまたはそれ以上のネットワークの間でパケットの転送をおこなう
|
||||
マシンのことです. パケットフィルタリングルータは, そのカーネルの内部に,
|
||||
一つ一つのパケットをルールリストと比較して転送するかしないかを決める
|
||||
特別なコードを持っています.
|
||||
最近の IP ルーティングソフトウェアのほとんどは, 内部に
|
||||
パケットのフィルタリングをおこなうためのコードを持っていて, デフォルトでは
|
||||
すべてのパケットを転送するようになっています.
|
||||
このフィルタを有効にするためには, パケットの通過を許すべきかどうかを決める
|
||||
ルールを自分で定義する必要があります.
|
||||
|
||||
<p> パケットを通すべきか通すべきでないかを決めるために,
|
||||
パケットヘッダの内容にマッチするものがルールリストから探されます.
|
||||
マッチするルールが見つかると, ルールアクションが実行されます.
|
||||
ルールアクションには, パケットを捨てる, パケットを転送する,
|
||||
またはパケットの発信元に ICMP メッセージを送り返すというものがあります.
|
||||
ルールの検索は先頭から順番におこなわれ, 通常は最初にマッチしたものだけが
|
||||
適用されます.
|
||||
そのため, このルールリストは「ルールチェーン」と呼ばれることもあります.
|
||||
|
||||
<p> パケットマッチングの基準は使用するソフトウェアによって異なりますが,
|
||||
通常はパケットの発信元 IP アドレス, 宛先 IP アドレス, 発信元ポート番号,
|
||||
宛先ポート番号 (ポート番号はポートをサポートするプロトコルの場合のみ),
|
||||
パケットタイプ (UDP, TCP, ICMP など) に基づくルールを指定することができます.
|
||||
|
||||
<sect2><heading>Proxy サーバ <label id="firewalls:proxy_servers"></heading>
|
||||
|
||||
<p>Proxy サーバとは通常のシステムデーモン (telnetd, ftpd など) を
|
||||
特別なサーバで置き換えたマシンのことです.
|
||||
これらのサーバは, 通常は中継をおこなって特定方向への接続だけを許すため,
|
||||
<bf>proxy サーバ </bf> と呼ばれます.
|
||||
(例えば) proxy telnet サーバをファイアウォールホストで走らせておきます.
|
||||
外部からユーザがファイアウォールに対して telnet を実行すると,
|
||||
proxy telnet サーバが応答して, 何らかの認証メカニズムを実行します.
|
||||
これを通過した後で, 内部ネットワークへのアクセスがおこなえるように
|
||||
なるのです. (内部ネットワークからの信号は proxy サーバがかわりに受け取り,
|
||||
外へ向けて送り出します.)
|
||||
|
||||
<p>Proxy サーバは通常, 普通のサーバより堅固に構築されていて,
|
||||
しばしば「使い捨て」パスワードシステムなどを含む,
|
||||
多様な認証メカニズムを持っています.
|
||||
「使い捨て」パスワードシステムとは, どういうものなのでしょうか.
|
||||
仮に誰かが何らかの方法で, あなたが使用したパスワードを手に入れたとします.
|
||||
しかし, 一度使用したことで, そのパスワードは既に無効になっているのです.
|
||||
ですから, そのパスワードをもう一度使用したとしても, あなたのシステムへ
|
||||
アクセスすることはできないというわけです.
|
||||
これらのサーバは中継をおこなうだけで, 実際のところサーバホスト自身への
|
||||
アクセスをユーザに許してはいません. そのため, 何者かがセキュリティシステムに
|
||||
侵入用の裏口を取り付けることは, より困難になっています.
|
||||
|
||||
<p>proxy サーバはアクセス制限の方法をいくつも持っていて, 特定のホスト
|
||||
だけがサーバへのアクセス権を得ることができるようになっていることがあり
|
||||
ます. そして目的のマシンと通信できるユーザを制限するように
|
||||
設定することもできます.
|
||||
もう一度言いますが, どんなファシリティ (機能) が使えるかは,
|
||||
どんな proxy サービスをおこなうソフトウェアを選ぶかに大きく依存します.
|
||||
|
||||
<sect1><heading> IPFW で何ができるか </heading>
|
||||
|
||||
<p>FreeBSD とともに配布されている <tt>IPFW</tt> は, カーネル内部にあって
|
||||
パケットのフィルタリングとアカウンティングをおこなうシステムであり,
|
||||
ユーザ側のコントロールユーティリティである <tt>ipfw(8)</tt> を
|
||||
含んでいます. ルーティングの決定をおこなう際に, これらは互いに協力して,
|
||||
カーネルで使用されるルールを定義したり, 現在使用されているルールを
|
||||
問い合わせたりすることができます.
|
||||
|
||||
<p><tt>IPFW</tt> は互いに関連する二つの部分からなっています.
|
||||
ファイアウォールセクションはパケットフィルタリングをおこないます.
|
||||
また, IP アカウンティングセクションはファイアウォールセクションのものと
|
||||
似たルールに基づいてルータの使用を追跡します.
|
||||
これにより, (例えば) 特定のマシンからルータへのトラフィックがどのくらい
|
||||
発生しているか調べたり, どれだけの WWW (World Wide Web) トラフィックが
|
||||
フォワードされているかを知ることができます.
|
||||
|
||||
<p><tt>IPFW</tt> は, ルータではないマシンにおいても入出力コネクションの
|
||||
パケットフィルタリングのために使用することができるように設計されています.
|
||||
これは一般的な <tt>IPFW</tt> の使用法とは異なる特別な使い方ですが,
|
||||
こういった状況でも同じコマンドとテクニックが使用されます.
|
||||
|
||||
<sect1><heading>FreeBSD で IPFW を有効にする </heading>
|
||||
|
||||
<p><tt>IPFW</tt> システムの中心となる部分はカーネル内部にあります.
|
||||
そのため, どのファシリティ (機能) を必要とするかによって, 一つまたは
|
||||
それ以上のオプションをカーネルコンフィグレーションファイルに追加し,
|
||||
カーネルを再コンパイルする必要があるでしょう.
|
||||
カーネルの再コンパイル方法の詳細については,
|
||||
<ref id="kernelconfig" name="カーネルコンフィグレーション"> を参照してください.
|
||||
|
||||
<p>現在, IPFW に関係するカーネルコンフィグレーションオプションは
|
||||
三つあります:
|
||||
|
||||
<descrip>
|
||||
<tag/options IPFIREWALL/ パケットフィルタリングのためのコードを
|
||||
カーネルに組み込みます.
|
||||
|
||||
<tag/options IPFIREWALL_VERBOSE/<tt>syslogd(8)</tt> を通じて
|
||||
パケットのログを取るためのコードを有効にします.
|
||||
フィルタルールでパケットのログを取るように指定しても,
|
||||
このオプションが指定されていなければ, ログを取ることはできません.
|
||||
|
||||
<tag/options IPFIREWALL_VERBOSE_LIMIT=10/<tt>syslogd(8)</tt> を通じて
|
||||
ログを取るパケットの数をエントリ毎に制限します.
|
||||
敵対的な環境においてファイアウォールの動作のログを取りたいけれど,
|
||||
syslog の洪水によるサービス拒絶攻撃に対し無防備でありたくないという場合に,
|
||||
このオプションを使用したいと思うことがあるかもしれません.
|
||||
|
||||
<p> チェーンエントリのログが指定された制限数に達すると,
|
||||
そのエントリに関するログ取りは停止されます.
|
||||
ログ取りを再開するには, <tt>ipfw(8)</tt> ユーティリティを使用して
|
||||
関連するカウンタをリセットする必要があります:
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw zero 4500
|
||||
</verb></tscreen>
|
||||
|
||||
4500 とは, ログ取りを続行したいチェーンエントリの番号です.
|
||||
|
||||
</descrip>
|
||||
|
||||
以前のバージョンの FreeBSD は <tt>IPFIREWALL_ACCT</tt> というオプションを
|
||||
持っていました.
|
||||
しかし, ファイアウォールコードがアカウンティングファシリティ (機能) を
|
||||
自動的に含むようになったため, 現在では使用されることはなくなっています.
|
||||
|
||||
<sect1><heading>IPFW の設定 </heading>
|
||||
|
||||
<p><tt>IPFW</tt> ソフトウェアの設定は <tt>ipfw(8)</tt> ユーティリティを
|
||||
通じておこないます. このコマンドの構文は非常に複雑に見えますが,
|
||||
一旦その構造を理解すれば比較的単純です.
|
||||
|
||||
<p> このユーティリティでは今のところ四つの異なるコマンドカテゴリが
|
||||
使用されています: それは追加 / 削除, 表示, フラッシュ, およびクリアです.
|
||||
追加 / 削除はパケットの受け入れ, 拒絶, ログ取りをどのようにおこなうか
|
||||
というルールを構築するのに使用します.
|
||||
表示はルールリスト (またはチェーン) と (アカウンティング用) パケットカウンタの
|
||||
内容を調べるのに使用します.
|
||||
フラッシュはチェーンからすべてのエントリを取り除くのに使用します.
|
||||
クリアは一つまたはそれ以上のアカウンティングエントリをゼロにするのに
|
||||
使用します.
|
||||
|
||||
<sect2><heading>IPFW ルールの変更 </heading>
|
||||
|
||||
<p> この形式での使用法は:
|
||||
<tscreen>
|
||||
ipfw [-N] <em> コマンド </em> [<em>index</em>]
|
||||
<em> アクション </em> [log] <em> プロトコル </em><em> アドレス </em>
|
||||
[<em> オプション </em>]
|
||||
</tscreen>
|
||||
|
||||
<p> この形式で使用する際に有効なフラグは一つだけです:
|
||||
|
||||
<descrip>
|
||||
<tag/-N/ アドレスやサービス名を文字列に変換して表示します.
|
||||
</descrip>
|
||||
|
||||
<em> コマンド </em> は一意である限り短縮可能です.
|
||||
有効な <em> コマンド </em> は:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/add/ ファイアウォール / アカウンティングルールリストに
|
||||
エントリを追加します.
|
||||
|
||||
<tag/delete/ ファイアウォール / アカウンティングルールリストから
|
||||
エントリを削除します.
|
||||
|
||||
</descrip>
|
||||
|
||||
以前のバージョンの <tt>IPFW</tt> では, ファイアウォールエントリと
|
||||
パケットアカウンティングエントリが別々に利用されていました.
|
||||
現在のバージョンでは, それぞれのファイアウォールエントリ毎に
|
||||
パケットアカウンティングエントリが備えられています.
|
||||
|
||||
<p><tt>index</tt> が指定されていると, エントリはチェーン中の
|
||||
<tt>index</tt> で示される位置に置かれます. <tt>index</tt> が指定されて
|
||||
いなければ, エントリは (65535 番のデフォルトルールである
|
||||
パケット拒絶を別にして) 最後のチェーンエントリの index に 100 を足した
|
||||
位置 (チェーンの最後) に置かれます.
|
||||
|
||||
<p> カーネルが <bf>IPFIREWALL_VERBOSE</bf> つきでコンパイルされている場合,
|
||||
<bf>log</bf> オプションはマッチしたルールをシステムコンソールに出力させます.
|
||||
|
||||
<p>有効な <em> アクション </em> は:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/reject/ パケットを捨てます, ICMP ホスト / ポート到達不能パケットを
|
||||
(適切な方を) 発信元へ送ります.
|
||||
|
||||
<tag/allow/ 通常通りパケットを通過させます. (別名: <bf>pass</bf> および
|
||||
<bf>accept</bf>)
|
||||
|
||||
<tag/deny/ パケットを捨てます. 発信元は ICMP メッセージによる
|
||||
通知を受けません (そのためパケットが宛先に到達しなかったように見えます).
|
||||
|
||||
<tag/count/ このルールはパケットカウンタを更新するだけで, パケットを
|
||||
通過させたり拒絶したりしません. 検索は次のチェーンエントリから続けられます.
|
||||
|
||||
</descrip>
|
||||
|
||||
<p> それぞれの <em> アクション </em> は一意な先頭部分だけでも認識されます.
|
||||
|
||||
指定可能な <em> プロトコル </em> は以下の通り:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/all/ 任意の IP パケットにマッチします.
|
||||
|
||||
<tag/icmp/ICMP パケットにマッチします.
|
||||
|
||||
<tag/tcp/TCP パケットにマッチします.
|
||||
|
||||
<tag/udp/UDP パケットにマッチします.
|
||||
|
||||
</descrip>
|
||||
|
||||
<p><em> アドレス </em> の指定は:
|
||||
<tscreen>
|
||||
<bf>from</bf> <<em>address/mask</em>>[<em>port</em>] <bf>to</bf>
|
||||
<<em>address/mask</em>>[<em>port</em>&rsqb [<bf>via</bf> <<em>interface</em>>]
|
||||
</tscreen>
|
||||
|
||||
<p><em>port</em> はポートをサポートする <em> プロトコル </em> (UDP と TCP) の
|
||||
場合にだけ指定可能です.
|
||||
|
||||
<p><bf>via</bf> は必須ではなく, 特定のインターフェースを通ってきたパケット
|
||||
だけにマッチするように, IP アドレスまたはローカル IP インターフェースの
|
||||
ドメイン名, またはインターフェース名 (例えば <tt>ed0</tt>) を
|
||||
指定することができます.
|
||||
インターフェースユニット番号はオプションで, ワイルドカードで指定することが
|
||||
できます. 例えば, <tt>ppp*</tt> はすべてのカーネル PPP インターフェースに
|
||||
マッチします.
|
||||
|
||||
<p><tt><address/mask></tt> の指定は:
|
||||
<tscreen>
|
||||
<address>
|
||||
</tscreen>
|
||||
または
|
||||
<tscreen>
|
||||
<address>/mask-bits
|
||||
</tscreen>
|
||||
または
|
||||
<tscreen>
|
||||
<address>:mask-pattern
|
||||
</tscreen>
|
||||
|
||||
<p>IP アドレスのかわりに有効なホスト名を指定することも可能です.
|
||||
<tt>mask-bits</tt> はアドレスマスクで上位何ビットを１にするべきかを
|
||||
示す十進数値です. 例えば次の指定,
|
||||
<tscreen>
|
||||
192.216.222.1/24
|
||||
</tscreen>
|
||||
はクラス C のサブネット (この場合 192.216.222) の任意のアドレスにマッチする
|
||||
マスクを作成します. <tt>mask-pattern</tt> は与えられたアドレスと
|
||||
論理 AND される IP アドレスです.
|
||||
キーワード <tt>any</tt> は「任意の IP アドレス」を指定するために
|
||||
使用することができます.
|
||||
<p> ブロックするポート番号は以下のように指定します:
|
||||
<tscreen>
|
||||
port[,port[,port[...]]]
|
||||
</tscreen>
|
||||
のように単独のポートまたはポートのリストを指定します. または
|
||||
<tscreen><verb>
|
||||
port-port
|
||||
</verb></tscreen>
|
||||
のようにポートの範囲を指定します. 単独のポートとポートのリストを
|
||||
組み合わせて指定することも可能ですが, その場合は常に範囲の方を
|
||||
最初に指定しなければなりません.
|
||||
|
||||
<p> 使用可能な <em> オプション </em> は:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/frag/ データグラムの最初のフラグメントでなければマッチします.
|
||||
|
||||
<tag/in/ 入力途中のパケットであればマッチします.
|
||||
|
||||
<tag/out/ 出力途中のパケットであればマッチします.
|
||||
|
||||
<tag/ipoptions <em>spec</em>/IP ヘッダが <em>spec</em> に指定された
|
||||
カンマで区切られたオプションのリストを含んでいればマッチします.
|
||||
サポートされている IP オプションのリストは:
|
||||
<bf>ssrr</bf> (ストリクトソースルート),
|
||||
<bf>lsrr</bf> (ルーズソースルート), <bf>rr</bf> (レコードパケットルート),
|
||||
そして <bf>ts</bf> (タイムスタンプ) です.
|
||||
特定のオプションを含まないことを指定するには '!' を先頭につけます.
|
||||
|
||||
<tag/established/ パケットが既に確立されている TCP コネクションの一部であれば
|
||||
(つまり RST または ACK ビットがセットされていれば) マッチします.
|
||||
<em>established</em> ルールをチェーンの最初の方に置くことで,
|
||||
ファイアウォールのパフォーマンスを向上させることができます.
|
||||
|
||||
<tag/setup/ パケットが TCP コネクションを確立しようとするものであれば
|
||||
(SYN ビットがセットされ ACK ビットはセットされていなければ) マッチします.
|
||||
|
||||
<tag/tcpflags <em>flags</em>/TCP ヘッダが <em>flags</em> に指定された
|
||||
カンマで区切られたフラグのリストを含んでいればマッチします.
|
||||
サポートされているフラグは, <bf>fin</bf>, <bf>syn</bf>, <bf>rst</bf>,
|
||||
<bf>psh</bf>, <bf>ack</bf> と <bf>urg</bf> です.
|
||||
特定のフラグを含まないことを指定するには '!' を先頭につけます.
|
||||
|
||||
<tag/icmptypes <em>types</em>/ICMP タイプが <em>types</em> リストに
|
||||
存在していればマッチします. リストはタイプの範囲または個々のタイプを
|
||||
カンマで区切った任意の組合せで指定できます.
|
||||
一般的に使用されている ICMP タイプは:
|
||||
<bf>0</bf> エコーリプライ (ping リプライ),
|
||||
<bf>5</bf> リダイレクト, <bf>8</bf> エコーリクエスト (ping リクエスト),
|
||||
そして <bf>11</bf> 時間超過 (<tt>traceroute(8)</tt> で使用されているように,
|
||||
TTL 満了を示すのに使用されます) です.
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect2><heading> IPFW ルールリストの表示 </heading>
|
||||
|
||||
<p> この形式での使用法は:
|
||||
<tscreen>
|
||||
ipfw [-atN] l
|
||||
</tscreen>
|
||||
|
||||
<p>この形式で使用する際に有効なフラグは三つあります:
|
||||
|
||||
<descrip>
|
||||
|
||||
<tag/-a/ リスト表示の際にカウンタの値も表示します. このオプションは
|
||||
アカウンティングカウンタの内容を見る唯一の手段です.
|
||||
|
||||
<tag/-t/ 各チェーンエントリが最後にマッチした時刻を表示します.
|
||||
この時刻表示は <tt>ipfw(8)</tt> ユーティリティで使用される入力形式と
|
||||
互換性がありません.
|
||||
|
||||
<tag/-N/ (可能であれば) アドレスやサービス名を文字列に変換して表示します.
|
||||
|
||||
</descrip>
|
||||
|
||||
<sect2><heading>IPFW ルールのフラッシュ </heading>
|
||||
|
||||
<p> チェーンをフラッシュするには:
|
||||
<tscreen>
|
||||
ipfw flush
|
||||
</tscreen>
|
||||
|
||||
<p> カーネルに固定されているデフォルトルール (インデックス 65535 番)
|
||||
以外の, ファイアウォールチェーンの中のすべてのエントリを削除します.
|
||||
デフォルトではすべてのパケットが拒絶されるので, 一旦これを実行すると,
|
||||
パケットを許可するエントリがチェーンに追加されるまで,
|
||||
あなたのシステムがネットワークから切り放されてしまいます.
|
||||
そのため, ルールのフラッシュをおこなうときは注意が必要です.
|
||||
|
||||
<sect2><heading> IPFW パケットカウンタのクリア </heading>
|
||||
|
||||
<p> 一つまたはそれ以上のパケットカウンタをクリアするためには:
|
||||
<tscreen>
|
||||
ipfw zero [index]
|
||||
</tscreen>
|
||||
|
||||
<p><em>index</em> が指定されていなければ, すべてのパケットカウンタが
|
||||
クリアされます.
|
||||
<em>index</em> が指定されていれば, 特定のチェーンエントリだけが
|
||||
クリアされます.
|
||||
|
||||
<sect1><heading> ipfw に対するコマンドの例 </heading>
|
||||
|
||||
<p> このコマンドはルータを介して転送される,
|
||||
ホスト <bf>evil.hacker.org</bf> から
|
||||
ホスト <bf>nice.people.org</bf> の telnet ポートへの
|
||||
すべてのパケットを拒絶します:
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw add deny tcp from evil.hacker.org to nice.people.org 23
|
||||
</verb></tscreen>
|
||||
|
||||
<p> 次の例は, ネットワーク <bf>hacker.org</bf> (クラス C) 全体から
|
||||
マシン <bf>nice.people.org</bf> (の任意のポート) への
|
||||
任意の TCP トラフィックを拒絶し, ログを取ります.
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw add deny log tcp from evil.hacker.org/24 to nice.people.org
|
||||
</verb></tscreen>
|
||||
|
||||
あなたの内部ネットワーク (クラス C のサブネット) に対する X セッションを
|
||||
張れないようにする場合, 以下のコマンドで必要なフィルタリングがおこなえます:
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw add deny from any to my.org/28 6000 setup
|
||||
</verb></tscreen>
|
||||
|
||||
<bf>sup.FreeBSD.ORG</bf> の SUP サーバへのアクセスを許可するためには,
|
||||
以下のコマンドを使用します:
|
||||
|
||||
<tscreen><verb>
|
||||
ipfw add accept from any to sup.FreeBSD.ORG 871
|
||||
</verb></tscreen>
|
||||
|
||||
アカウンティングレコードを見るには:
|
||||
<tscreen><verb>
|
||||
ipfw -a list
|
||||
</verb></tscreen>
|
||||
または短縮形式で
|
||||
<tscreen><verb>
|
||||
ipfw -a l
|
||||
</verb></tscreen>
|
||||
最後にチェーンエントリがマッチした時刻を見ることもできます.
|
||||
<tscreen><verb>
|
||||
ipfw -at l
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1><heading> パケットフィルタリングファイアウォールの構築 </heading>
|
||||
|
||||
<p><quote><bf> 注: </bf> 以下の提案は, ただの提案にすぎません:
|
||||
必要な処理はそれぞれのファイアウォールで異なるため,
|
||||
あなた独自の要求にあったファイアウォールを構築する方法を
|
||||
ここで述べることはできないのです. </quote>
|
||||
|
||||
<p> 最初にファイアウォールをセットアップするとき,
|
||||
コントロールされた環境でファイアウォールホストの設定がおこなえるような
|
||||
テストベンチセットアップが用意できない場合には, カーネルのログ取りを
|
||||
有効にしてログ取り版のコマンドを使用することを強くおすすめします.
|
||||
そうすることで, 大した混乱や中断なしに問題となる範囲の特定と処置を
|
||||
素早くおこなうことができます.
|
||||
初期セットアップフェーズが完了してからであっても,
|
||||
アタックの可能性のあるアクセスをトレースしたり,
|
||||
要求の変化に応じてファイアウォールルールを変更したりできるので,
|
||||
`deny' に対するログ取りをおこなうことをおすすめします.
|
||||
|
||||
<quote><bf> 注: </BF><bf>accept</bf> コマンドのログ取りをおこなっていると,
|
||||
ファイアウォールをパケットが一つ通過する毎に 1 行のログが生成されるため
|
||||
<em>大量の</em> ログデータが発生します.
|
||||
そのため, 大規模な ftp/http 転送などをおこなうと, システムが非常に
|
||||
遅くなってしまいます.
|
||||
また, パケットが通過するまでにカーネルにより多くの仕事を要求するため,
|
||||
パケットのレイテンシ (latency) を増加させてしまいます.
|
||||
syslogd もログをディスクに記録するなど, より多くの CPU タイムを
|
||||
使用し始め, 実に容易に <tt>/var/log</tt> が置かれているパーティションを
|
||||
パンクさせてしまう可能性があります. </quote>
|
||||
|
||||
<p> 現状では, FreeBSD はブート時にファイアウォールルールをロードする
|
||||
能力を持っていません.
|
||||
私は <tt>/etc/netstart</tt> スクリプトにロードをおこなうスクリプトを
|
||||
追加することをおすすめします. IP インターフェースの設定がおこなわれる前に
|
||||
ファイアウォールの設定がおこなわれるように, netstart ファイル中の
|
||||
充分に早い位置にルールをロードするスクリプトを配置してください.
|
||||
こうすることで, ネットワークがオープンな間は常に抜け道が塞がれている
|
||||
ことになります.
|
||||
|
||||
<p> ルールをロードするために使用するスクリプトは,
|
||||
あなたが作成しなければなりません.
|
||||
現在のところ <tt>ipfw</tt> は 1 コマンドで複数のルールを
|
||||
ロードするユーティリティをサポートしていません.
|
||||
私が使用しているシステムでは以下のようにしています:
|
||||
|
||||
<tscreen><verb>
|
||||
# ipfw list
|
||||
</verb></tscreen>
|
||||
|
||||
ファイルに現在のルールリストを出力し, テキストエディタを使用して
|
||||
すべての行の前に ``<tt>ipfw </tt>'' と書き足します.
|
||||
こうすることで, このスクリプトを /bin/sh に与えてルールをカーネルに再読み込み
|
||||
させることができます. これは最も効率的な方法とはいえないかもしれませんが,
|
||||
きちんと動作しています.
|
||||
|
||||
<p> 次の問題は, ファイアウォールが実際には何を <bf> する </bf> べきかです !
|
||||
これは外部からそのネットワークへのどんなアクセスを許したいか,
|
||||
また内部から外界へのアクセスをどのくらい許したいかに大きく依存します.
|
||||
いくつか一般的なルールを挙げると:
|
||||
|
||||
<itemize>
|
||||
|
||||
<item> 1024 番以下のポートへのすべての TCP 入力アクセスをブロックします.
|
||||
ここは finger, SMTP (mail) そして telnet など, 最もセキュリティに敏感な
|
||||
サービスが存在する場所だからです.
|
||||
|
||||
<item><bf> すべての </bf> 入力 UDP トラフィックをブロックします.
|
||||
これは UDP を使用しているサービスで有用なものは極めて少ないうえ,
|
||||
有用なトラフィック (例えば Sun の RPC と NFS プロトコル) は,
|
||||
通常セキュリティに対する脅威となるためです.
|
||||
UDP はコネクションレスプロトコルであるため,
|
||||
入力 UDP トラフィックを拒絶することは
|
||||
すなわち出力 UDP トラフィックに対する返答をも
|
||||
ブロックすることになるので, このことはそれなりの不利益をもたらします.
|
||||
たとえば外部の archie (prospero) サーバを使用している (内部の) ユーザに
|
||||
とって問題となる可能性があります.
|
||||
もし archie へのアクセスを許したければ, 191 番と 1525 番のポートから
|
||||
任意の UDP ポートへ来るパケットがファイアウォールを通過することを
|
||||
許可しなければなりません.
|
||||
123 番のポートから来るパケットは ntp パケットで,
|
||||
これも通過の許可を考慮する必要があるもう一つのサービスです.
|
||||
|
||||
<item> 外部から 6000 番のポートへのトラフィックをブロックします.
|
||||
6000 番のポートは X11 サーバへのアクセスに使用されるポートで,
|
||||
セキュリティに対する脅威となりえます. (特に自分のワークステーションで
|
||||
<tt>xhost +</tt> をおこなう癖を持っている人がいればなおさらです).
|
||||
X11 は実際に 6000 番以降のポートを使用する可能性があるため, 通過許可に
|
||||
上限を定めると, そのマシンで走らせることのできる X ディスプレイの
|
||||
個数が制限されます.
|
||||
RFC 1700 (Assigned Numbers) で定義されているように, 上限は 6063 です.
|
||||
|
||||
<item> 内部のサーバ (例えば SQL サーバなど) がどのポートを使用するかを
|
||||
チェックします.
|
||||
それらのポートは通常, 上で指定した 1-1024 番の範囲から外れていますので,
|
||||
これらも同様にブロックしておくことはおそらく良い考えです.
|
||||
|
||||
</itemize>
|
||||
|
||||
<p> これとは別のファイアウォール設定に関するチェックリストが CERT から
|
||||
入手可能です.
|
||||
<htmlurl url="ftp://ftp.cert.org/pub/tech_tips/packet_filtering"
|
||||
name="ftp://ftp.cert.org/pub/tech_tips/packet_filtering">
|
||||
|
||||
<p> 前にも述べたように, これはただの <em> ガイドライン </em> にすぎません.
|
||||
ファイアウォールでどのようなフィルタルールを使用するかは, あなた自身が
|
||||
決めなければなりません.
|
||||
これまでのアドバイスにしたがったにも関わらず, 誰かがあなたのネットワークに
|
||||
侵入してきたとしても, 私は「いかなる」責任もとることはできません.
|
||||
@ -1,6 +0,0 @@
|
||||
<!-- $Id: glossary.sgml,v 1.4 1997/02/22 13:01:03 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.5 -->
|
||||
|
||||
<chapt><heading>* Glossary<label id="glossary"></heading>
|
||||
|
||||
@ -1,33 +0,0 @@
|
||||
<!-- $Id: goals.sgml,v 1.4 1997/02/22 13:01:05 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.4 -->
|
||||
|
||||
<sect><heading>FreeBSDプロジェクトの目的<label id="goals"></heading>
|
||||
|
||||
<p><em>原作: &a.jkh;</em>
|
||||
<p><em>訳: &a.kiroh;<newline>24 September 1996.</em>
|
||||
<p>
|
||||
FreeBSDプロジェクトの目的は、いかなる用途にも使用でき、何ら制限のない
|
||||
ソフトウェアを供給することです。私たちの多くは、コード(そしてプロジェ
|
||||
クト)に対してかなりの投資をしてきており、これからも多少の無駄はあって
|
||||
も投資を続けて行くつもりです。ただ、他の人達にも同じような負担をするよ
|
||||
うに主張しているわけではありません。FreeBSD に興味を持っている一人の残
|
||||
らず全ての人々に、目的を限定しないでコードを提供すること。これが、私た
|
||||
ちの最初のそして最大の``任務''であると信じています。そうすれば、コード
|
||||
は可能な限り広く使われ、最大の恩恵をもたらすことができるでしょう。これ
|
||||
が、私たちが熱烈に支持しているフリーソフトウェアの最も基本的な目的であ
|
||||
ると、私は信じています。
|
||||
|
||||
<p>
|
||||
私たちのソースツリーに含まれるソースのうち、GNU一般公有使用許諾(GPL)ま
|
||||
たはGNUライブラリ一般公有使用許諾(GLPL)に従っているものについては、多
|
||||
少制限が科されています。ただし、ソースコードへのアクセスの保証という、
|
||||
一般の制限とはいわば逆の制限(訳注1)です。ただしGPLソフトウェアを商用で
|
||||
利用する場合、さらに複雑になるのは避けられません。そのため、それらのソ
|
||||
フトウェアを、より制限の少ないBSD著作権に従ったソフトウェアで置き換え
|
||||
る努力を、可能な限り日々続けています。
|
||||
|
||||
<p>
|
||||
(訳注1) GPL では、「ソースコードを実際に受け取るか、あるいは、希望しさ
|
||||
えすればそれを入手することが可能であること」を求めています。
|
||||
|
||||
@ -1,195 +0,0 @@
|
||||
<!-- $Id: handbook.sgml,v 1.17 1997/05/18 02:30:50 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.76 -->
|
||||
|
||||
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
|
||||
|
||||
<!-- Conditional flags for this version of the document -->
|
||||
<!ENTITY % boothelp.only "IGNORE">
|
||||
<!ENTITY % handbook.only "INCLUDE">
|
||||
|
||||
<!-- Entity shorthand for authors' names and email addresses -->
|
||||
<!ENTITY % authors SYSTEM "authors.sgml">
|
||||
%authors;
|
||||
|
||||
<!-- Entity shorthand for translator's names and email addresses -->
|
||||
<!ENTITY % jmembers SYSTEM "jmembers.sgml">
|
||||
%jmembers;
|
||||
|
||||
<!-- Entity shorthand for mailing list email addresses -->
|
||||
<!ENTITY % lists SYSTEM "lists.sgml">
|
||||
%lists;
|
||||
|
||||
<!-- Entity definitions for all the parts -->
|
||||
<!ENTITY % sections SYSTEM "sections.sgml">
|
||||
%sections;
|
||||
|
||||
<!-- The currently released version of FreeBSD -->
|
||||
<!ENTITY rel.current CDATA "2.2.2">
|
||||
|
||||
]>
|
||||
|
||||
<linuxdoc>
|
||||
<book>
|
||||
|
||||
<title>FreeBSD ハンドブック</title>
|
||||
<author>
|
||||
<name>FreeBSD ドキュメンテーションプロジェクト</name>
|
||||
</author>
|
||||
<date>1997年5月</date>
|
||||
|
||||
<abstract>FreeBSD へようこそ! このハンドブックは<bf>FreeBSD Release
|
||||
&rel.current;</bf>のインストールおよび, 日常での使い方について記述したもので,
|
||||
FreeBSD ドキュメンテーションプロジェクトによって編集されています.
|
||||
|
||||
日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクトがおこなって
|
||||
います. 本書は<bf>現在進行中の作業</bf>であって, 多くの個人の手からなる
|
||||
仕事です. 多くのセクションはまだ存在しませんし, いま存在するセクションの
|
||||
いくつかはアップデートが必要です. この FreeBSD ドキュメンテーション
|
||||
プロジェクトに協力したいと思ったら, &a.doc; まで (英語で) 電子メールを
|
||||
送ってください. ハンドブックそのものに関する議論は, こちらで
|
||||
おこなわれています. (もちろん英語でです.)
|
||||
日本語訳および, 日本語版のみに関することは &a.doc-jp; において日本語で
|
||||
議論されています. 必要に応じて日本語ドキュメンテーションプロジェクトから
|
||||
本家ドキュメンテーションプロジェクトに対してフィードバックをおこないますので,
|
||||
英語が得意でない方は &a.doc-jp; まで日本語でコメントをお寄せください.
|
||||
このドキュメントの最新バージョンは, いつでも
|
||||
<url url="http://www.jp.FreeBSD.ORG/"
|
||||
name="日本国内版 FreeBSD World Wide Web サーバ">や
|
||||
<url url="http://www.FreeBSD.ORG/" name="FreeBSD World Wide Web サーバ">
|
||||
から入手できますし,
|
||||
<url url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs" name="FreeBSD FTP サーバ">
|
||||
や, たくさんある<ref id="mirrors" name="ミラーサイト">からプレインテキスト,
|
||||
postscript, HTML などの形式でダウンロードすることもできます.
|
||||
また, <url url="/search.html" name="ハンドブックの検索">も可能です.
|
||||
|
||||
</abstract>
|
||||
<toc>
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>導入</heading>
|
||||
|
||||
<chapt><heading>はじめに</heading>
|
||||
<p>FreeBSD は, Intel アーキテクチャ (x86) ベースの PC のための
|
||||
4.4BSD-Lite をベースとしたオペレーティングシステムです.
|
||||
FreeBSD の概要については,
|
||||
<ref id="nutshell" name="FreeBSD とは">をご覧ください.
|
||||
このプロジェクトの歴史については, <ref id="history" name="FreeBSD 小史">
|
||||
をご覧ください. 最新のリリースについての記述は,
|
||||
<ref id="relnotes" name="現在のリリースについて">をご覧ください.
|
||||
FreeBSD プロジェクトへの何らかの貢献 (ソースコード, 機器, 資金の提供など)
|
||||
について興味があれば, <ref id="submitters" name="FreeBSD への貢献">
|
||||
の章をご覧ください.
|
||||
|
||||
&nutshell;
|
||||
&history;
|
||||
&goals;
|
||||
&development;
|
||||
&relnotes;
|
||||
|
||||
&install;
|
||||
&basics;
|
||||
|
||||
&ports;
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>システム管理</heading>
|
||||
|
||||
&kernelconfig;
|
||||
<chapt><heading>セキュリティ</heading>
|
||||
&crypt;
|
||||
&skey;
|
||||
&kerberos;
|
||||
&firewalls;
|
||||
|
||||
&printing;
|
||||
|
||||
"as;
|
||||
<chapt><heading>X ウィンドウシステム</heading>
|
||||
<p>この節の完成は保留にしてあります.
|
||||
<url url="http://www.xfree86.org/" name="The XFree86 Project, Inc">
|
||||
から提供されるドキュメントを参考にしてください.
|
||||
|
||||
&hw;
|
||||
|
||||
<chapt><heading>ローカル化<label id="l10n"></heading>
|
||||
&russian;
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>ネットワーク通信</heading>
|
||||
|
||||
<chapt><heading>シリアル通信</heading>
|
||||
&serial;
|
||||
&term;
|
||||
&dialup;
|
||||
&dialout;
|
||||
|
||||
<chapt><heading>PPP と SLIP</heading>
|
||||
|
||||
<p>もしあなたがモデムを使ってインターネットに接続したり,
|
||||
他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を
|
||||
提供しようとしているのでしたら, PPP または SLIP 接続を選択することができます.
|
||||
PPP 接続には, 2 種類の方法が提供されています:
|
||||
<em>ユーザ</em>PPP (iijppp とも呼ばれます) と<em>カーネル</em>PPP です.
|
||||
両方の PPP の設定手順と, SLIP の設定方法については以下の章に書かれています.
|
||||
|
||||
&userppp;
|
||||
&ppp;
|
||||
&slipc;
|
||||
&slips;
|
||||
|
||||
<chapt><heading>高度なネットワーク</heading>
|
||||
&routing;
|
||||
&nfs;
|
||||
&diskless;
|
||||
&isdn;
|
||||
|
||||
&mail;
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>さらに進んだ話題</heading>
|
||||
<chapt><heading>開発の最前線: FreeBSD-current と FreeBSD-stable</heading>
|
||||
<p>あるリリースから次のリリースまでの期間にも, FreeBSD の開発は
|
||||
休みなく続けられています. この開発の最前線に興味を持っている人のために,
|
||||
手元のシステムを最新の開発ツリーに同期させておくための,
|
||||
とても使いやすい仕掛けが何種類も用意されています.
|
||||
注意: 開発の最前線は, 誰でもが扱えるという性質のものではありません!
|
||||
もしもあなたが, 開発途中のシステムを追いかけようか, それともリリース
|
||||
バージョンのどれかを使い続けようかと迷っているのなら,
|
||||
きっとこの章が参考になるでしょう. </p>
|
||||
|
||||
¤t;
|
||||
&stable;
|
||||
&synching;
|
||||
</chapt>
|
||||
|
||||
&submitters;
|
||||
&policies;
|
||||
&kernelopts;
|
||||
&kerneldebug;
|
||||
&linuxemu;
|
||||
<chapt><heading>FreeBSD の内部</heading>
|
||||
&booting;
|
||||
&memoryuse;
|
||||
&dma;
|
||||
|
||||
|
||||
<!-- ************************************************************ -->
|
||||
|
||||
<part><heading>付録</heading>
|
||||
|
||||
&mirrors;
|
||||
&bibliography;
|
||||
&eresources;
|
||||
&contrib;
|
||||
&pgpkeys;
|
||||
&jcontrib;
|
||||
|
||||
<!-- &glossary; -->
|
||||
|
||||
</book>
|
||||
</linuxdoc>
|
||||
@ -1,114 +0,0 @@
|
||||
<!-- $Id: history.sgml,v 1.6 1997/02/25 04:55:50 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.22 -->
|
||||
<!-- 和訳: masaki@po.iijnet.or.jp + hino@nwk.cl.nec.co.jp 1997/5/13 -->
|
||||
|
||||
<sect><heading>FreeBSD 小史<label id="history"></heading>
|
||||
|
||||
<p><em>原作: &a.jkh;</em>.
|
||||
|
||||
<p><em>訳: &a.masaki;, &a.hino;.<newline>19 December 1996.</em>
|
||||
|
||||
FreeBSD プロジェクトは 1993年の始めに ``Unofficial 386BSD Patchkit''
|
||||
の最後の 3人のまとめ役によって, 部分的に patchkit から派生する形で開始
|
||||
されました. ここでの 3人のまとめ役というのは, Nate Williams と, Rod
|
||||
Grimes と, 私 (Jordan K. Hubbard) です.
|
||||
|
||||
私たちのもともとの目標は, patchkit という仕組みではもう十分に解
|
||||
決できなくなってしまった 386BSD の数多くの問題を修正するための, 386BSD
|
||||
の暫定的なスナップショットを作成することでした. こういった経緯を経てい
|
||||
るので, このプロジェクトの初期の頃の名前が ``386BSD 0.5'' や ``386BSD
|
||||
暫定版 (Interim)'' であったということを覚えている人もいるでしょう.
|
||||
|
||||
386BSD は, Bill Jolitz が (訳注: バークレイ Net/2 テープを基に) 作成し
|
||||
たオペレーティングシステムです. 当時の 386BSD は, ほぼ一年にわたって放っ
|
||||
ておかれていた (訳注: 作者がバグの報告を受けても何もしなかった) という
|
||||
ひどい状況に苦しんでいました. 作者の代わりに問題を修正し続けていた
|
||||
patchkit は日を追うごとに不快なまでに膨張してしまっていました. このよ
|
||||
うな状況に対して, このままではいけない, 何か行動を起こさなければ, とい
|
||||
うことで異議を唱えるものは私たちのなかにはいませんでした. そして私たち
|
||||
は挑戦することを決断し, 暫定的な「クリーンアップ」スナップショットを作
|
||||
成することで Bill を手助けしようと決めたのです. しかし, この計画は唐突
|
||||
に終了してしまいました. Bill Jolitz が, このプロジェクトに対する受け
|
||||
入れ支持を取り下げることを突然決意し, なおかつこのプロジェクトの代わり
|
||||
に何をするのかを一切言明しなかったのです.
|
||||
|
||||
たとえ Bill が支持してくれないとしても, われわれの目標には依然としてや
|
||||
る価値があると決心するのにさしたる時間はかかりませんでした. そこで
|
||||
David Greenman が考案した名称 ``FreeBSD'' を私たちのプロジェクトの名前
|
||||
に採用し, 新たなスタートを切りました. この時点でのプロジェクトの初期目
|
||||
標は, すでにこのシステム (訳注: 386BSD + Patchkit) を使っていた利用者
|
||||
たちと相談して決められました. プロジェクトが実現に向けて軌道に乗ってき
|
||||
たことが明確になった時点で, 私は Walnut Creek CDROM 社に連絡してみまし
|
||||
た. CDROM を使って FreeBSD を配布することによって, インターネットに容
|
||||
易に接続できない多くの人々が FreeBSD を簡単に入手できるようになると考
|
||||
えたからです. Walnut Creek CDROM 社は FreeBSD を CD で配布するというア
|
||||
イデアを採用してくれたばかりか, 作業するためのマシンと高速なインターネッ
|
||||
ト回線を私たちのプロジェクトに提供してくれました. 当時は海のものとも山
|
||||
のものともわからなかった私たちのプロジェクトに対して, Walnut Creek
|
||||
CDROM 社が信じられないほどの信頼を寄せてくれたおかげで, FreeBSD は短期
|
||||
間のうちにここまで大きく成長したのです.
|
||||
|
||||
CDROM による最初の配布 (そしてネットでの, ベータ版ではない最初の一般向
|
||||
け配布) は FreeBSD 1.0 で, 1993年 12月に公開されました. これは カリフォ
|
||||
ルニア大学バークレイ校の 4.3BSD-Lite (``Net/2'') を基とし, 386BSD や
|
||||
Free Software Foundation からも多くの部分を取り入れたものです. これは
|
||||
初めて公開したものとしては十分に成功しました. 続けて 1994年 5月に
|
||||
FreeBSD 1.1 を公開し, 非常に大きな成功を収めました.
|
||||
|
||||
この時期, あまり予想していなかった嵐が遠くから接近してきていました. バー
|
||||
クレイ Net/2 テープの法的な位置づけについて, Novell 社と カリフォルニ
|
||||
ア大学バークレイ校との間の長期にわたる法廷論争において和解が成立したの
|
||||
です. 和解の内容は, Net/2 のかなりの部分が「権利つき (encumbered)」コー
|
||||
ドであり, それは Novell 社の所有物である, というバークレイ校側が譲歩し
|
||||
たものでした. なお, Novell 社はこれらの権利を裁判が始まる少し前に
|
||||
AT&T 社から買収していました. 和解における譲歩の見返りにバークレイ
|
||||
校が得たのは, 4.4BSD-Lite が最終的に発表された時点で, 4.4BSD-Lite は権
|
||||
利つきではないと公式に宣言されること, そしてすべての既存の Net/2 の利
|
||||
用者が 4.4BSD-Lite の利用へと移行することが強く奨励されること, という
|
||||
Novell 社からの「ありがたき天からの恵み」でした. (訳注: 4.4BSD-Lite は
|
||||
その後 Novell 社のチェックを受けてから公開された.) FreeBSD も Net/2 を利
|
||||
用していましたから, 1994年の 7月の終わりまでに Net/2 ベースの FreeBSD
|
||||
の出荷を停止するように言われました. ただし, このときの合意によって, 私
|
||||
たちは締め切りまでに一回だけ最後の公開をすることを許されました. そして
|
||||
それは FreeBSD 1.1.5.1 となりました.
|
||||
|
||||
それから FreeBSD プロジェクトは, まっさらでかなり不完全な 4.4BSD-Lite
|
||||
を基に, 文字どおり一から再度作り直すという, 難しくて大変な作業の準備を始めまし
|
||||
た. ``Lite'' バージョンは, 部分的には本当に軽くて, 中身がなかったので
|
||||
す. 起動し, 動作できるシステムを実際に作り上げるために必要となるプログ
|
||||
ラムコードのかなりの部分がバークレイ校 の CSRG (訳注: BSDを作っている
|
||||
グループ) によって (いろいろな法的要求のせいで) 削除されてしまっていた
|
||||
ということと, 4.4BSD の Intel アーキテクチャ対応が元々かなり不完全であっ
|
||||
たということがその理由です. この移行作業は結局 1994年の 12月までかかり
|
||||
ました. そして 1995年の 1月に FreeBSD 2.0 をネットと CDROM を通じて公
|
||||
開しました. これは, かなり粗削りなところが残っていたにもかかわらず, か
|
||||
なりの成功を収めました. そしてその後に, より信頼性が高く, そしてインス
|
||||
トールが簡単になった FreeBSD 2.0.5 が 1995年の 6月に公開されました.
|
||||
|
||||
|
||||
<em>これからのことについて</em>
|
||||
|
||||
私たちは 1996年の 8月に FreeBSD 2.1.5 を公開しました. この出来が非常に
|
||||
良く, 特に業務で運用しているサイトや ISP での人気が高かったので, 私た
|
||||
ちは 2.1-STABLE 開発分流から更に公開をおこなうことにメリットがあると考
|
||||
えました. それが FreeBSD 2.1.7.1 で, 2.1-STABLE 開発分流の最後を締めく
|
||||
くるものとして, 1997年の 2月に公開されました. 2.1-STABLE 開発分流
|
||||
(RELENG_2_1_0) は現在, 保守のみをおこなう状態になっており, 今後は, セ
|
||||
キュリティの改善や他の何か重要なバグフィックスのみがおこなわれるでしょ
|
||||
う.
|
||||
|
||||
FreeBSD 2.2 の開発は, RELENG_2_2 開発分流として, 開発の本流
|
||||
(``-current'') から 1996年 11月に分岐し, そして 1997年 4月に最初の公開
|
||||
(2.2.1) がおこなわれました. RELENG_2_2 開発分流に関する今後の計画では,
|
||||
97年の夏から秋の間に数回の公開をおこなうことが予定されています. そして
|
||||
97年の冬のはじめ頃には, FreeBSD 3.0 の最初の公開をおこなう予定です.
|
||||
<!-- 訳者覚書:Jordan氏は最後の文に関する質問に対し以下の回答をくれた. -->
|
||||
<!-- What I meant to say was: -->
|
||||
<!-- o Several releases of 2.2.x during Summer and Fall of 1997. -->
|
||||
<!-- o The first official release of 3.0.x in Winter of 1997. -->
|
||||
|
||||
SMP のサポートから DEC ALPHA のサポートまでのすべての長期的な開発プロ
|
||||
ジェクトは, 3.0-CURRENT 開発分流において継続しています. CDROM (もちろ
|
||||
ん, ネットワーク上でも) による 3.0 のスナップショット公開は, 1997年
|
||||
5月頃から開始される予定です.
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,846 +0,0 @@
|
||||
<!-- $Id: install.sgml,v 1.14 1997/04/01 02:38:01 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.53 -->
|
||||
|
||||
<!--
|
||||
<!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'>
|
||||
-->
|
||||
<chapt><heading>FreeBSDのインストール<label id="install"></heading>
|
||||
|
||||
<p><em>原作: 不明</em>
|
||||
|
||||
<p><em>訳: &a.mita;, <newline>&a.hanai;, <newline>&a.iwasaki;.
|
||||
<newline>26 January 1997.</em>
|
||||
|
||||
<p>それでは, FreeBSD のインストールに挑戦してみましょう.
|
||||
この章には, あなたが何をする必要があるかの簡単なガイドが
|
||||
書いてあります. FreeBSD は, CD-ROM, フロッピーディスク, 磁気テープ,
|
||||
MS-DOSのパーティション, ネットワーク接続しているところでは
|
||||
anonymous FTP や NFS を通じてインストールすることができます.
|
||||
|
||||
どのインストールメディアを利用する場合も, まず<bf>インストールディスク</bf>
|
||||
をダウンロードするところから始まります. このディスクであなたの
|
||||
コンピュータを立ち上げることで, FreeBSD とあなたのハードウェアとの
|
||||
相性に関する重要な情報を手に入れることができ, このハードウェアでは
|
||||
どんなインストールオプションが使えるかを指定することができます.
|
||||
もしもあなたが anonymous FTP を使用してインストールする予定なら,
|
||||
インストールディスクだけをダウンロードすればOKです.
|
||||
|
||||
FreeBSDの配布に関する情報は, 付録の <ref id="mirrors" name="FreeBSD の入手方法">
|
||||
をご覧ください.
|
||||
|
||||
仕事にとりかかるには, 以下のような手順を踏みます.
|
||||
<enum>
|
||||
|
||||
<item>このインストールガイドの <ref id="install:hw"
|
||||
name="サポートされている設定一覧"> の節を読んで, あなたのハードウェアが
|
||||
FreeBSD でサポートされていることを確認します. SCSI コントローラだとか,
|
||||
イーサネットアダプタだとか, サウンドカードだとかの, あなたのマシンが
|
||||
装備している特別なカードのリストを作っておくと便利です. この
|
||||
リストには, 割り込み番号 (IRQ) とか, IO ポートのアドレスとかの, カードに
|
||||
関係する設定も書いておきましょう.<P></P></item>
|
||||
<item><url
|
||||
url="ftp://ftp.freebsd.org/pub/FreeBSD/&rel.current;-RELEASE/floppies/boot.flp"
|
||||
name="ブートディスクのイメージ"> ファイルをあなたの
|
||||
ハードディスクにダウンロードしてきます. ブラウザのコマンドでは,
|
||||
<em>display</em> ではなくて <em>save</em> を選ぶことに注意してください.
|
||||
|
||||
<bf>注意:</bf> このディスクイメージは, 1.44 メガバイトの 3.5 インチフロッピーディスクのみで使用可能です.<P></P></item>
|
||||
|
||||
<item>このイメージファイルからブートディスクを作成します,
|
||||
<itemize>
|
||||
<item>MS-DOSを使っている場合:
|
||||
<url
|
||||
url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/tools/fdimage.exe"
|
||||
name="fdimage.exe"> をダウンロードして, これを実行します.
|
||||
<tscreen><verb>
|
||||
E:\> tools\fdimage floppies\boot.flp a:
|
||||
</verb></tscreen>
|
||||
このプログラムは, A: ドライブをフォーマットした後 boot.flp の内容を書き込みます
|
||||
(ここでは FreeBSD の配布物のトップレベルディレクトリにおり, フロッピーイメージ
|
||||
は floppies ディレクトリにあると仮定しています).<P></P></item>
|
||||
|
||||
<item>UNIX システムを使っている場合:
|
||||
<tscreen>
|
||||
% dd if=boot.flp of=<em>disk_device</em>
|
||||
</tscreen>
|
||||
を実行します. ここで, <em>disk_device</em> はフロッピードライブに
|
||||
対応する <tt>/dev</tt>の中のエントリです. FreeBSD では,
|
||||
<tt>/dev/fd0</tt> が A:ドライブに, <tt>/dev/fd1</tt> が B:ドライブに
|
||||
対応しています.<P></P></item>
|
||||
</itemize>
|
||||
<P></P></item>
|
||||
|
||||
<item>インストールディスクを A:ドライブに入れて, コンピュータを
|
||||
立ち上げ直します. そうすると次のようなプロンプトが出てくるはずです.
|
||||
<tscreen>
|
||||
>> FreeBSD BOOT ...<newline>
|
||||
Usage: [[[0:][wd](0,a)]/kernel][-abcCdhrsv]<newline>
|
||||
Use 1:sd(0,a)kernel to boot sd0 if it is BIOS drive 1<newline>
|
||||
Use ? for file list or press Enter for defaults<newline>
|
||||
Boot:
|
||||
</tscreen>
|
||||
ここで何もタイプしない場合, 5秒間の待ち時間の後に FreeBSD は
|
||||
自動的にデフォルトの設定で立ち上がります. 立ち上げの際, どんな
|
||||
ハードウェアが装備されているかを検出 (プローブ) します. この結果は
|
||||
スクリーン上に表示されます.<P></P></item>
|
||||
|
||||
<item>立ち上げプロセスが終了したら, FreeBSD インストールメニューが
|
||||
表示されます.
|
||||
</item>
|
||||
</enum>
|
||||
|
||||
<p><bf>もしも問題が起こった場合</bf>
|
||||
|
||||
<p>PC アーキテクチャの制限のため, 100パーセントの信頼をもって検出する
|
||||
ことは不可能です. もしもあなたのハードウェアが間違って認識されたり,
|
||||
検出途中でコンピュータが固まってしまうようなことが起こった場合,
|
||||
まずこのガイドの <ref id="install:hw" name="サポートされている設定一覧">
|
||||
の節を読んで, あなたのハードウェアが本当に
|
||||
FreeBSD でサポートされているかどうかを確かめてください.
|
||||
|
||||
<p>ハードウェアがサポートされていた場合, リセットして
|
||||
<tt>Boot:</tt> プロンプトが出てきたところで, <bf>-c</bf> と打ち込んで
|
||||
ください. こうすると, FreeBSD はコンフィグレーションモードになり,
|
||||
ハードウェアに関する情報を FreeBSD に与えることができるようになります.
|
||||
インストールディスクの FreeBSD カーネルは, 多くのデバイスの IRQ,
|
||||
IO アドレスが工場出荷時の値に設定されているものと仮定して作られています.
|
||||
もしもあなたのハードウェアの設定を変更したなら, <bf> -c</bf>
|
||||
オプションで立ち上げて, 設定がどうなっているかを指定してあげること
|
||||
が必要になるでしょう.
|
||||
|
||||
<p>存在しないデバイスを検出すると, 実際に存在している他のデバイスの
|
||||
検出に失敗することが考えられます. そのような場合は, 衝突している
|
||||
デバイスを無効にしなくてはなりません.
|
||||
|
||||
<p>コンフィグレーションモードでは,
|
||||
<itemize>
|
||||
<item>カーネルに組み込まれているデバイスドライバの一覧を表示する</item>
|
||||
<item>あなたのシステムにないハードウェアのデバイスドライバを無効にする</item>
|
||||
<item>デバイスドライバの IRQ, DRQ, IO ポートアドレスなどの変更する</item>
|
||||
</itemize>
|
||||
などができます.
|
||||
<p> <tt>config></tt> プロンプトが出ているところで, <tt>help</tt>
|
||||
と打ち込むと, 使用可能なコマンドについての詳しい説明が出てきます.
|
||||
あなたのマシンのハードウェア設定に合うようにカーネルを変更したら,
|
||||
<tt>config></tt> プロンプトが出たところで <tt>quit</tt> と打ち込んで,
|
||||
新しい設定でマシンを立ち上げます.
|
||||
|
||||
FreeBSD のインストールがひとたび終了した後は, コンフィグレーションモード
|
||||
での変更はずっと保持されますので, 立ち上げのたびに設定変更をする必要は
|
||||
なくなりますが, あなたのシステムの性能を高めるために,
|
||||
カスタムカーネルを作るのが好ましいでしょう. カスタムカーネルの作成に関しては,
|
||||
<ref id="kernelconfig" name="FreeBSD カーネルのコンフィグレーション">
|
||||
の章をご覧ください.
|
||||
|
||||
<sect><heading>サポートされている設定一覧<label id="install:hw"></heading>
|
||||
|
||||
<p>現在 FreeBSD は, ISA, VL, EISA, PCI バスや, 386SX から Pentium クラス
|
||||
までのさまざまな種類の PC で動作します (386SXはおすすめではありません).
|
||||
IDE, ESDIドライブや, さまざまな SCSI コントローラ, ネットワークカードや
|
||||
シリアルカードにも対応しています.
|
||||
|
||||
FreeBSD を走らせるには, 最低 4メガバイトの RAM が必要です. X Window System を
|
||||
走らせるには最低でも 8メガバイトの RAM が推奨されます.
|
||||
|
||||
以下のリストでは, FreeBSD で動作が確認されているディスクコントローラ
|
||||
やイーサネットカードです. 他の設定でもうまく動いてくれると
|
||||
思いますが, 私たちのところには情報は入ってきていません.
|
||||
|
||||
<sect1><heading>ディスクコントローラ</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
<item>WD1003 (あらゆる MFM/RLL)
|
||||
<item>WD1007 (あらゆる IDE/ESDI)
|
||||
<item>IDE
|
||||
<item>ATA
|
||||
|
||||
<item>Adaptec 1505 ISA SCSI コントローラ
|
||||
<item>Adaptec 152x シリーズ ISA SCSI コントローラ
|
||||
<item>Adaptec 1535 ISA SCSI コントローラ
|
||||
<item>Adaptec 154x シリーズ ISA SCSI コントローラ
|
||||
<item>Adaptec 174x シリーズ EISA SCSI コントローラ
|
||||
(スタンダード, エンハンスドモード)
|
||||
<item>Adaptec 274x/284x/2940/2940U/3940
|
||||
(Narrow/Wide/Twin)
|
||||
シリーズ EISA/VLB/PCI SCSI コントローラ
|
||||
<item>Adaptec AIC7850 オンボード SCSI コントローラ
|
||||
<item>Adaptec
|
||||
<!-- AIC-6260 and - 実際のところ動いていません, joerg -->
|
||||
AIC-6360系のボード
|
||||
AHA-152x や SoundBlaster SCSI などがこれにあたります.
|
||||
|
||||
<bf>注意:</bf> Soundblaster カードには, オンボード BIOS
|
||||
が載っていないので, このカードからは FreeBSD を起動できません.
|
||||
オンボード BIOS とは, システム BIOS の I/O ベクタにブートデバイスを
|
||||
登録するときに必要なものです. このカードは外部テープであるとか,
|
||||
CD-ROM であるとかその他の場合には十分利用可能です.
|
||||
同じことは, ブート ROM の載っていない AIC-6x60 系のカードにもいえます.
|
||||
いくつかのシステムでは実際にブート ROM を持っています.
|
||||
それは電源を入れるかリセットしたとき, 最初に表示されます.
|
||||
詳しくはあなたのシステムやボードの解説書をご覧ください.
|
||||
|
||||
|
||||
<item>Buslogic 545S & 545c
|
||||
<bf>注意:</bf> Buslogic社は古くは Bustek社といっていました.
|
||||
<item>Buslogic 445S/445c VLバス SCSI コントローラ
|
||||
<item>Buslogic 742A, 747S, 747c EISA SCSI コントローラ.
|
||||
<item>Buslogic 946c PCI SCSI コントローラ
|
||||
<item>Buslogic 956c PCI SCSI コントローラ
|
||||
|
||||
<item>NCR 53C810 , 53C825 PCI SCSI コントローラ.
|
||||
<item>NCR5380/NCR53400 (``ProAudio Spectrum'') SCSI コントローラ.
|
||||
|
||||
<item>DTC 3290 EISA SCSI コントローラ (1542 エミュレーション)
|
||||
|
||||
<item>UltraStor 14F, 24F, 34F SCSI コントローラ.
|
||||
|
||||
<item>Seagate ST01/02 SCSI コントローラ.
|
||||
|
||||
<item>Future Domain 8xx/950 シリーズ SCSI コントローラ.
|
||||
|
||||
<item>WD7000 SCSI コントローラ.
|
||||
|
||||
</itemize>
|
||||
|
||||
サポートされている SCSI コントローラのすべてで, ディスク, テープドライブ
|
||||
(含む DAT), CD-ROM ドライブなどの周辺機器との通信に SCSI-I,
|
||||
SCSI-II が利用可能です.
|
||||
|
||||
現在, 次にあげるタイプの CD-ROM ドライブがサポートされてます.
|
||||
<itemize>
|
||||
<item>Soundblaster SCSI , ProAudio Spectrum SCSI (<tt>cd</tt>)
|
||||
<item>ミツミ (全モデル) 独自のインタフェース (<tt>mcd</tt>)
|
||||
<item>松下 / Panasonic (Creative)
|
||||
CR-562/CR-563 インタフェース (<tt>matcd</tt>)
|
||||
<item>ソニー インタフェース (<tt>scd</tt>)
|
||||
<item>ATAPI IDE インタフェース
|
||||
(まだまだお試し段階で, クオリティは低いです)
|
||||
(<tt>wcd</tt>)
|
||||
</itemize>
|
||||
|
||||
<sect1><heading>イーサネットカード</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
|
||||
<item>Allied-Telesis AT1700, RE2000 カード
|
||||
|
||||
<item>SMC Elite 16 WD8013 Ethernet インタフェース,
|
||||
その他多くの WD8003E, WD8003EBT, WD8003W, WD8013W,
|
||||
WD8003S, WD8003SBT や WD8013EBTなどの互換品.
|
||||
SMC Elite Ultra もサポートされています.
|
||||
|
||||
<item>DEC EtherWORKS III ネットワークインタフェースカード (DE203, DE204, DE205)
|
||||
<item>DEC EtherWORKS II ネットワークインタフェースカード (DE200, DE201, DE202, DE422)
|
||||
<item>DEC DC21040/DC21041/DC21140 ベースのネットワークインタフェースカード:
|
||||
<itemize>
|
||||
<item>ASUS PCI-L101-TB
|
||||
<item>Accton ENI1203
|
||||
<item>Cogent EM960PCI
|
||||
<item>Compex CPXPCI/32C
|
||||
<item>D-Link DE-530
|
||||
<item>DEC DE435
|
||||
<item>Danpex EN-9400P3
|
||||
<item>JCIS Condor JC1260
|
||||
<item>Linksys EtherPCI
|
||||
<item>Mylex LNP101
|
||||
<item>SMC EtherPower 10/100 (Model 9332)
|
||||
<item>SMC EtherPower (Model 8432)
|
||||
<item>SMC EtherPower (2)
|
||||
<item>Zynx ZX342
|
||||
</itemize>
|
||||
<item>DEC FDDI (DEFPA/DEFEA) ネットワークインタフェースカード
|
||||
|
||||
<item>富士通 FMV-181, FMV-182
|
||||
|
||||
<item>富士通 MB86960A/MB86965A
|
||||
|
||||
<item>Intel EtherExpress
|
||||
|
||||
<item>Intel EtherExpress Pro/100B 100Mbit.
|
||||
|
||||
<item>Isolan AT 4141-0 (16 bit)
|
||||
<item>Isolink 4110 (8 bit)
|
||||
|
||||
<item>Novell NE1000, NE2000, NE2100 イーサネットインタフェース
|
||||
|
||||
<item>3Com 3C501 カード
|
||||
|
||||
<item>3Com 3C503 Etherlink II
|
||||
|
||||
<item>3Com 3c505 Etherlink/+
|
||||
|
||||
<item>3Com 3C507 Etherlink 16/TP
|
||||
|
||||
<item>3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III
|
||||
|
||||
<item>3Com 3C590, 3C595 Etherlink III
|
||||
|
||||
<item>HP PC Lan Plus (27247B と 27252A)
|
||||
|
||||
<item>東芝 イーサネットカード
|
||||
|
||||
<item>IBM , National Semiconductor社 PCMCIA
|
||||
イーサネットカードもサポートされています.
|
||||
</itemize>
|
||||
|
||||
<p><em>注意:</em> FreeBSD は今のところ, いくつかのイーサネットカードの
|
||||
PnP (プラグ&プレイ) 機能には対応していません. もし PnP で問題が起こる
|
||||
ようでしたら, PnP 機能を無効にしてください.
|
||||
|
||||
<sect1><heading>その他のデバイス</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
<item> AST 4 ポート シリアルカード (シェアード IRQ 使用)
|
||||
|
||||
<item> ARNET 8 ポート シリアルカード (シェアード IRQ 使用)
|
||||
|
||||
<item> BOCA IOAT66 6 ポート シリアルカード (シェアード IRQ 使用)
|
||||
|
||||
<item> BOCA 2016 16 ポート シリアルカード (シェアード IRQ 使用)
|
||||
|
||||
<item> Cyclades Cyclom-y シリアルボード
|
||||
|
||||
<item> STB 4 ポート カード (シェアード IRQ 使用)
|
||||
|
||||
<item> SDL Communications Riscom/8 シリアルボード
|
||||
|
||||
<item> SDL Communications RISCom/N2 と N2pci 同期シリアルカード
|
||||
|
||||
<item> Digiboard Sync/570i high-speed 同期シリアルカード
|
||||
|
||||
<item>Decision-Computer Intl. "Eight-Serial" 8 ポートシリアルカード
|
||||
(シェアード IRQ 使用)
|
||||
|
||||
<item> Adlib, SoundBlaster, SoundBlaster Pro,
|
||||
ProAudioSpectrum, Gravis UltraSound, Gravis UltraSound MAX
|
||||
Roland MPU-401 などのサウンドカード
|
||||
|
||||
<item>Matrox Meteor video フレームグラバー
|
||||
|
||||
<item>Creative Labs Video spigot フレームグラバー
|
||||
|
||||
<item>Omnimedia Talisman フレームグラバー
|
||||
|
||||
<item>X-10 power コントローラ
|
||||
|
||||
<item>PC ジョイスティックおよびスピーカ
|
||||
</itemize>
|
||||
FreeBSD は今のところ, IBM社のマイクロチャネルアーキテクチャ (MCA) バスには
|
||||
対応していません.
|
||||
|
||||
<sect><heading>インストールの下準備</heading>
|
||||
|
||||
<p>FreeBSD のインストール方法はさまざまあります. それぞれの
|
||||
インストール方法に対して, どのような下準備が必要かをこれから説明します.
|
||||
|
||||
<sect1><heading>CD-ROM からインストールする前に</heading>
|
||||
|
||||
<p>あなたの CD-ROM ドライブがサポートされていないタイプの場合は,
|
||||
<ref id="install:msdos"
|
||||
name="ハードディスクの MS-DOS パーティションからインストールする前に">
|
||||
に飛んでください.
|
||||
Walnut Creek の FreeBSD CD-ROM からインストールする場合は, 大した下準備
|
||||
をしないでもうまくインストールできることでしょう (その他の CD-ROM
|
||||
でもうまくいくでしょうが, その CD-ROM がどうやって作られているか, 私たち
|
||||
はわかりませんので確実なことは言えません).
|
||||
Walnut Creek の CD-ROM に収録されている, ``install.bat'' で直接 FreeBSD
|
||||
を立ち上げることもできますし, ``makeflp.bat'' でブートフロッピーディスクを
|
||||
つくることもできます. [注意: もし FreeBSD 2.1-RELEASE を使っていて
|
||||
IDE CD-ROM ドライブを持っている場合, install.bat のかわりに
|
||||
inst_ide.bat もしくは atapiflp.bat を使ってください. ]
|
||||
|
||||
DOS から最も楽なインタフェースを使いたい場合は ``view'' と打ち込みます.
|
||||
そうすると DOS でのメニューが立ち上がって, 可能なオプション
|
||||
すべてを選択できます.
|
||||
|
||||
あなたが UNIX マシンでブートフロッピーディスクを作成している場合は,
|
||||
<ref id="install" name="FreeBSD のインストール"> を参考にしてください.
|
||||
|
||||
DOS から, もしくはフロッピーディスクから起動をおこなうと,
|
||||
メニュー ``Media'' から, インストールメディアとして CDROM を
|
||||
選択することで, 配布ファイルをロードすることができるようになります.
|
||||
他の種類のインストールメディアは不要なはずです.
|
||||
|
||||
システムインストールがすべて終了して, ハードディスクから起動
|
||||
しなおしてからは, <tt>mount /cdrom</tt> とタイプする
|
||||
ことでいつでも CD-ROM のマウントをすることができるようになります.
|
||||
|
||||
CD-ROM を取り出す前には <tt>umount /cdrom</tt> と打ち込まなくてはならない
|
||||
ことを覚えておいてください. 単純にドライブから取り出さないように!
|
||||
|
||||
<quote><bf>特別な注意:</bf> インストールに入る前に,
|
||||
CD-ROM をドライブに入れておいて, インストールフロッピーディスクが立ち上がる
|
||||
ときに CD-ROM を見つけられるようにしておくようにしましょう. CD-ROM を
|
||||
デフォルトでシステムにつけ加えたい場合も CD-ROM を入れておきます
|
||||
(インストールメディアとして実際に CDROM を選択しない場合も同様).
|
||||
</quote>
|
||||
|
||||
おわりに, あなたのマシンの CD-ROM を直接使って, FTP 経由で別のマシンに
|
||||
FreeBSD をインストールさせたいとします. やり方は簡単です.
|
||||
あなたのマシンのインストールが終了した後に, vipw コマンドを使って,
|
||||
passwd ファイルに以下の行を追加します.
|
||||
|
||||
<tscreen><verb>
|
||||
ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent
|
||||
</verb></tscreen>
|
||||
|
||||
こうするとあなたのマシンにネットワーク接続できる人 (そして,
|
||||
login 許可を持っている人) は, メディアタイプとして FTP を選択できるように
|
||||
なります. 具体的には, FTP サイトの選択メニューから ``Other'' を選択して,
|
||||
<tt>ftp://<em>あなたのマシンのアドレス</em></tt>
|
||||
を入力します.
|
||||
|
||||
<sect1><heading>フロッピーディスクからのインストールの前に</heading>
|
||||
|
||||
<p>あなたがフロッピーディスクからのインストールをしなくては
|
||||
ならない場合, その理由はハードウェアがサポートされてなかったためか,
|
||||
単にいばらの道を通ることを楽しんでいるからでしょうが, インストール用の
|
||||
フロッピーディスクを用意する必要があります.
|
||||
|
||||
最低でも bin (基本配布ファイル) ディレクトリ内のすべてのファイル
|
||||
を入れられるだけの 1.44 メガバイトか 1.2 メガバイトのフロッピーディスク
|
||||
が必要です. これらのフロッピーディスクを DOS で作成している場合は,
|
||||
フロッピーディスクは「MS-DOS の FORMAT コマンドでフォーマット」
|
||||
されなくてはなりません. Windows をお使いの場合は, Windowsの
|
||||
ファイルマネージャの初期化コマンドを使用してください.
|
||||
|
||||
工場での初期化済みディスクを「信用しないでください」. 念のためにあなた
|
||||
自身でフォーマットし直してください. ユーザからのトラブル報告の多くは
|
||||
ちゃんと初期化されていないディスクを使用していたことが原因となっています.
|
||||
私が特にフォーマットし直してくださいと述べているのも, この理由からです.
|
||||
|
||||
他の FreeBSD マシンでフロッピーディスクを作成している場合,
|
||||
フォーマットすることは悪いことではありません. いちいち DOS
|
||||
ファイルシステムのフロッピーディスクを作成する必要はありませんので,
|
||||
`disklabel' コマンドと `newfs' コマンドを使って, 次のような手順で
|
||||
(3.5 インチ 1.44 メガバイトディスク用の) UFS ファイルシステムを
|
||||
作成することもできます.
|
||||
|
||||
<tscreen><verb>
|
||||
fdformat -f 1440 fd0.1440
|
||||
disklabel -w -r fd0.1440 floppy3
|
||||
newfs -t 2 -u 18 -l 1 -i 65536 /dev/rfd0
|
||||
|
||||
(5.25 インチの 1.2 メガバイトディスクの場合は "fd0.1200" と "floppy5" にしてください)
|
||||
</verb></tscreen>
|
||||
|
||||
これで他のファイルシステムと同様に mount して書き込むことができます.
|
||||
|
||||
フォーマットされたフロッピーディスクを用意したら, それらにファイル
|
||||
をコピーしなくてはなりません. 配布ファイルはいくつかのかたまり
|
||||
にわかれていて, これらのかたまり五つで一般的な 1.44 メガバイトの
|
||||
フロッピーディスクに収まるようになっています. フロッピーディスクに
|
||||
入るだけファイルを入れていって, 配布ファイルをすべてコピーしてください.
|
||||
それぞれの配布ファイルはサブディレクトリにコピーする必要があります. 例えば,
|
||||
<bf>a:\bin\bin.aa</bf>とか,
|
||||
<bf>a:\bin\bin.ab</bf>といった感じです.
|
||||
|
||||
インストールメディアの選択場面になったら, ``Floppy'' を選択して,
|
||||
残りの指定をやってください.
|
||||
|
||||
<sect1><heading>ハードディスクの MS-DOS パーティションからインストールする前に
|
||||
<label id="install:msdos"></heading>
|
||||
|
||||
<p>
|
||||
|
||||
ハードディスクの MS-DOS パーティションからインストールするときは,
|
||||
まずファイルを <tt>C:\FREEBSD</tt> にコピーします.
|
||||
CD-ROM にあるディレクトリ構造を反映してコピーしなくてはなりません.
|
||||
DOS の <tt>xcopy</tt> コマンドの使用をおすすめします.
|
||||
|
||||
例えば, FreeBSD の最低限のインストールをするには, このような手順で
|
||||
コピーします.
|
||||
<tscreen><verb>
|
||||
C> MD C:\FREEBSD
|
||||
C> XCOPY /S E:\BIN C:\FREEBSD\BIN\
|
||||
C> XCOPY /S E:\MANPAGES C:\FREEBSD\MANPAGES\
|
||||
</verb></tscreen>
|
||||
|
||||
ここで, <tt>C:</tt>ドライブには十分なディスクスペースが残っており,
|
||||
CD-ROM は <tt> E:</tt>ドライブに接続されているものとします.
|
||||
|
||||
MS-DOS からたくさんの `配布ファイル (DISTS)' をインストールしたい
|
||||
(そしてディスクの余裕がある) 場合は, それぞれ <tt>C:\FREEBSD</tt>
|
||||
ディレクトリにコピーします - <tt>BIN</tt> 配布ファイルは,
|
||||
最低限必要なものです.
|
||||
|
||||
<sect1><heading>QIC/SCSI テープからのインストールの前に</heading>
|
||||
|
||||
<p>テープからのインストールは, おそらく FTP を利用したオンライン
|
||||
インストールか, CD-ROM を利用したインストールができない場合の,
|
||||
もっとも簡単な方法でしょう. インストールプログラムは, 以下のような
|
||||
コマンドを使用して, 単純に配布ファイルがテープ上に tar されていることを
|
||||
期待しています.
|
||||
|
||||
<tscreen>
|
||||
cd /freebsd/distdir<newline>
|
||||
tar cvf /dev/rwt0 (または /dev/rst0) dist1 .. dist2
|
||||
</tscreen>
|
||||
|
||||
インストールに入る前に, テンポラリ (一時使用) ディレクトリに
|
||||
十分なディスクスペースを確保して, 作成したテープの<bf>すべての</bf>
|
||||
ファイルを格納できることを確認してください (テンポラリディレクトリは
|
||||
自分で選ぶことができます). テープの特性上, ランダムにアクセスするこ
|
||||
とができませんので, 一時的に極めて大量の容量を必要とします.
|
||||
テープに準備しただけの量のディスクスペースを一時的に使用することに
|
||||
留意してください.
|
||||
|
||||
|
||||
<quote><bf>注意:</bf> インストールに入るときは, ブートフロッピーディスク
|
||||
から立ち上げる<bf>前</bf>にテープをドライブに入れておかなくてはなりません.
|
||||
さもないとインストール時のデバイス検出のときにテープを見つけられません. </quote>
|
||||
|
||||
|
||||
<sect1><heading>ネットワーク経由のインストールの前に</heading>
|
||||
|
||||
<p>三つの物理的な接続形態で, ネットワーク経由のインストールを
|
||||
おこなうことができます.
|
||||
<descrip>
|
||||
<tag>シリアルポート</tag> SLIP もしくは PPP 方式.
|
||||
<tag>パラレルポート</tag> PLIP (laplink ケーブル使用)
|
||||
<tag>イーサネット</tag> 標準的なイーサネットコントローラ
|
||||
(いくつかの PCMCIA カードにも対応)
|
||||
</descrip>
|
||||
|
||||
SLIP のサポートはまだまだ原始的とも呼べる方法なので, ラップトップと
|
||||
他のコンピュータをシリアルケーブルで接続するといった具合いに,
|
||||
直接接続してなくてはいけません. SLIP インストールは, ダイヤル機能を
|
||||
持っていませんので, インストールするためには直接接続しなくてはなりません.
|
||||
PPP インストールではダイヤルアップ接続が可能ですので, できれば PPP 接続の
|
||||
方を選択しましょう.
|
||||
|
||||
もしもあなたがモデムを使用しているなら, あなたに残された選択肢は
|
||||
ほぼ間違いなく PPP インストールでしょう. インストール時に必要になりますので,
|
||||
サービスプロバイダ (ISP) に関する情報を用意しておきましょう.
|
||||
少なくともプロバイダと, 可能ならあなたの IP アドレスを知っておかなくては
|
||||
なりません (IP アドレスの欄を空白にしておいて, PPP に IP アドレスの
|
||||
割り当て処理をさせてもかまいません). PPP ダイヤルの際は, とても
|
||||
シンプルな端末エミュレータで作業することになりますので, お手持ちのモデムで
|
||||
ISP にダイヤルするために, ``ATコマンド'' の使い方を知っておく必要があります.
|
||||
|
||||
FreeBSD (2.0R 以降) の動いている別のマシンと直接接続が可能でしたら,
|
||||
``laplink'' パラレルポートケーブルで接続することを考えてみましょう.
|
||||
パラレルポート経由のデータ転送スピードは, シリアルラインでの
|
||||
一般的なスピード (最高 50kbit/sec) よりもずっと高速ですので,
|
||||
高速にインストールすることができます.
|
||||
|
||||
最後になりますが, ネットワークインストールのうちでもっとも高速なものとしては
|
||||
イーサネットアダプタを使用するのがあげられます. FreeBSD ではきわめて多くの
|
||||
PC イーサネットカードをサポートしています. サポートされている
|
||||
カードの表 (と, 必要な設定) は,
|
||||
<ref id="install:hw" name="サポートされている設定一覧"> に書いてあります.
|
||||
サポートされている PCMCIA カードを使っている場合には, ラップトップの電源を
|
||||
入れる「前」に差し込んでおくことにも注意してください. 残念ながら今の
|
||||
FreeBSD は, インストール時の活線挿抜には対応していません.
|
||||
|
||||
ネットワークでの IP アドレス, あなたのアドレスクラスに対応した
|
||||
ネットマスク, マシン名を知っておくことも必要です. ネットワーク管理者の方に
|
||||
たずねればどんな値を使ったらよいかを教えてくれるでしょう. もしも他のホストを
|
||||
IP アドレスではなくて名前で引きたい場合, ネームサーバとゲートウェイ
|
||||
のアドレスも知らなくてはなりません (PPP をご使用の場合は, プロバイダの
|
||||
IP アドレスになります). これらのうちのすべて, またはいくつかを
|
||||
知らない場合は, イーサネット経由でのインストールを始める前に「まず」
|
||||
ネットワーク管理者に相談してください.
|
||||
|
||||
何らかのネットワーク接続ができたら, 続けてインストールを NFS か
|
||||
FTP 経由でおこないます.
|
||||
|
||||
<sect2><heading>NFS インストールのための下準備</heading>
|
||||
|
||||
<p>NFS インストールはまったく単純明解です. FreeBSD の配布ファイルを
|
||||
サーバの好きな場所にコピーしておいて, メディア選択で NFS を選択します.
|
||||
|
||||
もしサーバが ``privileged (特権) ポート'' へのアクセスのみをサポート
|
||||
している場合, (Sun ワークステーションの標準ではこうなっています)
|
||||
インストールを進める前に Options メニューを選択して, ``privileged
|
||||
port'' オプションを選択してください.
|
||||
|
||||
イーサネットカードの性能が悪くて, 転送速度が遅くて困っている場合も,
|
||||
適当な Options を選択するとよいでしょう.
|
||||
|
||||
NFS 経由でインストールするためには, サブディレクトリも
|
||||
含めたマウントにサーバが対応している必要があります. 例えば,
|
||||
FreeBSD &rel.current; の配布ファイルが
|
||||
<bf>ziggy:/usr/archive/stuff/FreeBSD</bf>
|
||||
にあるとすると, マシン ziggy では <bf>/usr</bf> や
|
||||
<bf>/usr/archive/stuff</bf> だけではなく,
|
||||
<bf>/usr/archive/stuff/FreeBSD</bf> の直接マウントが可能に
|
||||
なっていなければなりません.
|
||||
|
||||
FreeBSD の <bf>/etc/exports</bf> ファイルでは, このことは
|
||||
``<tt>-alldirs</tt>'' オプションによって制御されています.
|
||||
他の NFS サーバの場合だとまた話が違ってくるかもしれません.
|
||||
もしもサーバから `Permission Denied' というメッセージが
|
||||
返ってくるようでしたら, サブディレクトリマウントをちゃんと
|
||||
有効にできていないことが考えられます.
|
||||
|
||||
<sect2><heading>FTP インストールのための下準備</heading>
|
||||
|
||||
<p>FTP 経由のインストールは, FreeBSD &rel.current; の最新バージョンを
|
||||
ミラーしているどのサイトからでも可能です. 世界中の妥当な FTP サイトの
|
||||
選択肢をメニューに並べておきました.
|
||||
|
||||
このメニューに出ていない他の FTP サイトからインストール
|
||||
する場合や, ネームサーバの設定に問題が生じた場合は,
|
||||
メニューでサイト ``Other'' を選ぶところで, お好みの
|
||||
URL でサイトを指定することができます. URL として直接 IP
|
||||
アドレスで指定してもよく, 直接指定した場合はネームサーバ
|
||||
がなくても FTP インストールが可能になります. 例えば,
|
||||
<tscreen><verb>
|
||||
ftp://192.216.222.4/pub/FreeBSD/&rel.current;-RELEASE
|
||||
</verb></tscreen>
|
||||
のような感じですね.
|
||||
|
||||
FTP 経由のインストールモードとして, このようなものが
|
||||
使用可能です:
|
||||
|
||||
<descrip>
|
||||
<tag>FTP Active</tag>
|
||||
|
||||
すべての FTP 転送の際に ``Active'' モードを使用します.
|
||||
ファイアウォール内部のマシンではうまく動きませんが,
|
||||
passive モードをサポートしていない古い FTP サーバでも
|
||||
動作します. passive モードでの FTP 転送 (こちらが
|
||||
デフォルトです) が失敗した場合は, active を使ってください.
|
||||
|
||||
<tag>FTP Passive</tag>
|
||||
|
||||
すべての FTP 転送の際に ``Passive'' モードを使用します.
|
||||
このモードを使用することで, ランダムポートアクセスインを
|
||||
許さないファイアウォールを越えることができるようになります.
|
||||
|
||||
</descrip>
|
||||
|
||||
<quote><bf>注意:</bf> Active, passive モードは `proxy'
|
||||
接続と同じではありません! proxy FTP サーバは FTP 要求
|
||||
を受け付け実際の FTP サーバへ転送します. </quote>
|
||||
|
||||
通常 proxy FTP サーバ に対しては, ユーザ名の一部として
|
||||
@ 記号に続いて実際に接続したいサーバの名称を与える必要が
|
||||
あります. そうすると proxy サーバは本当のサーバの「ふり」
|
||||
をするようになります. 例えば: ftp.freebsd.org から ポート番号
|
||||
1234 で要求を待つ proxy FTP サーバ foo.bar.com を使って
|
||||
インストールしたいとします.
|
||||
|
||||
この場合では, 「オプション」メニューで FTP username を
|
||||
ftp@ftp.freebsd.org, パスワードとして自分の電子メールアドレス
|
||||
を指定します. インストールメディアとして FTP (または proxy
|
||||
サーバがサポートしていれば passive FTP), URL を以下のようにします:
|
||||
<tscreen><verb>
|
||||
ftp://foo.bar.com:1234/pub/FreeBSD
|
||||
</verb></tscreen>
|
||||
ftp.freebsd.org の /pub/FreeBSD に対する FTP 要求については
|
||||
foo.bar.com が代理で処理をおこなうことになり, 「むこう」
|
||||
のマシンからインストールすることができます (インストール時
|
||||
の要求により ftp.freebsd.org からファイルをもってきます).
|
||||
|
||||
<sect><heading>FreeBSD のインストール</heading>
|
||||
|
||||
<p>インストールの下準備を適切に書き留めておけば, なんの
|
||||
問題もなく FreeBSD のインストールができることと思います.
|
||||
|
||||
何かうまくいかなかった場合は, あなたが使おうとしている
|
||||
インストールメディアのことが書いてある箇所まで戻って
|
||||
もう一度読むとよいでしょう. おそらく最初読んだときに
|
||||
見落していた, 有効なヒントがあるものと思います.
|
||||
ハードウェアの問題が出てきたとか, FreeBSD がまったく
|
||||
立ち上がらない場合は, boot フロッピーディスクに提供されている
|
||||
Hardware Guide を読んで, 何か解決方法はないか探してください.
|
||||
|
||||
FreeBSD のブートフロッピーディスクには, インストールをおこなうために
|
||||
必要と思われるすべてのオンラインドキュメントを用意してあります.
|
||||
もしもそのドキュメントがお望みのものでないようでしたら,
|
||||
私たちはあなたが何にもっとも困っているのかを知りたいと思います.
|
||||
コメントを &a.doc; にお送りください. FreeBSD のインストールプログラム
|
||||
(sysinstall) を, うっとうしい ``step-by-step'' ガイドなしに,
|
||||
プログラム自身で使用方法がわかるようにするのが最終目標です.
|
||||
目標達成までには時間がかかりそうですが, ともかくそれが
|
||||
目標なのであります.
|
||||
|
||||
|
||||
閑話休題. ここに, 「典型的なインストールの手順」を
|
||||
まとめてみましたので, お役にたてるものと思います.
|
||||
<enum>
|
||||
<item>ブートフロッピーディスクから起動します. ハードウェアの性能に
|
||||
よりますが, 起動には 30秒から 3分かかります. 起動したら
|
||||
初期選択画面が出てくるでしょう, もしもフロッピーディスクから
|
||||
まったく起動しなかったり, どこかの段階で起動が止まってしまった
|
||||
場合は, ハードウェアガイドの Q&A を読んで, 理由を
|
||||
探ってみます.
|
||||
|
||||
<item>F1 キーを叩きます. メニューシステムとインストールプログラム
|
||||
全般に対しての使い方が表示されます. このメニューシステムを
|
||||
使ったことがない場合は, 「徹底的に」読んでください.
|
||||
|
||||
<item>Options を選択し, 他に必要な特別な選択を
|
||||
おこないます.
|
||||
|
||||
<item>典型的なインストールでおまかせしたい方は Novice を,
|
||||
インストールのそれぞれの段階をいちいちコントロールしたい方は Custom を,
|
||||
(可能であれば適切なデフォルトを使用して) 簡単にさっさと済ませたい方は
|
||||
Express を, それぞれ好みに応じて選んでください.
|
||||
FreeBSD を初めて使う方には, Novice を一番におすすめします.
|
||||
|
||||
<item>final configuration メニューからは, メニュー形式のさらに
|
||||
進んだ設定をおこなうことができます. ネットワーク周りの
|
||||
設定は, 特に CD-ROM / テープ / フロッピーディスクから
|
||||
インストールして, まだネットワーク設定をおこなっていない
|
||||
人にとっては特に重要でしょう. インストールの時点できちんと
|
||||
設定しておけば, ハードディスクからシステムを立ち上げ直した
|
||||
時点でネットワーク接続ができるようになっていることでしょう.
|
||||
</enum>
|
||||
|
||||
<!-- なぜか最近の install.sgml では, 削除されてます. もったいない... -->
|
||||
<!--
|
||||
<sect1><heading>Express インストール</heading>
|
||||
|
||||
<p>Express インストールは Custom インストールとそんなに変わる
|
||||
ところはないのですが, 必要な作業を流れに沿って順番に提示
|
||||
してくれて, それぞれの段階で便利なガイドが表示されるところが
|
||||
ことなっています.
|
||||
|
||||
<enum>
|
||||
<item>インストールは `Partition Editor' から始まります.
|
||||
ここでどのドライブを FreeBSD で使うかを指定します.
|
||||
もしもドライブ全体を使いたい場合は, `A' コマンド
|
||||
だけを打ち込めばよいはずです.
|
||||
|
||||
<item>次に `Label Editor' に進みます. 確保した FreeBSD の
|
||||
パーティションをどのように使うか, または DOS のような
|
||||
FreeBSD 以外のパーティションをどこにマウントするかなどを
|
||||
指定します. 標準のままの使い方でよければ単に `A' と
|
||||
打ち込みます.
|
||||
|
||||
<item>次は `Distributions' メニューに進みます.
|
||||
ここでは何をインストールしたいかを選択します.
|
||||
小規模システムにしたい場合は ``User'' を選択しますし,
|
||||
FreeBSD からの何らかの拡張をしようと思っている場合は
|
||||
``Developer'' を選択します.
|
||||
どの選択肢も気に入らない場合は Custom を選んでください.
|
||||
|
||||
<item>次に, `Media' メニューで, どのメディアから
|
||||
インストールしたいかを指定します. もしも望みのメディアが
|
||||
選ばれており, 自動的に設定されていた場合は, ただメニュー
|
||||
から戻ってくるだけで OK です. そうでない場合はメディアタイプ
|
||||
の細かい指定をおこないます.
|
||||
|
||||
<item>おわりに, これまでのすべての指定で GO サインを出すか
|
||||
どうか求められてきます (これまでの段階ではまだ
|
||||
ディスクに書き込まれていませんし, GO サインを
|
||||
出すまで書き込まれません). GO サインを出すと
|
||||
いよいよインストールが始まります. 新しく
|
||||
作ったパーティションや, 変更したパーティションの
|
||||
情報が書き出され, 新しいファイルシステムが
|
||||
作られたり, ファイルシステムはそのままでラベル
|
||||
されたりします (新しいファイルシステムを作るか,
|
||||
既存のものにラベルするかは, Label Editor の
|
||||
newfs オプションをどう設定したかで決まります).
|
||||
ファイルシステムができると選択した配布ファイルが
|
||||
すべて展開されます.
|
||||
</enum>
|
||||
|
||||
ここまでくれば, sysinstall プログラムでの作業は大体おしまいです.
|
||||
`Quit' を選択できます. sysinstall プログラムを
|
||||
インストーラとして使用している場合 (システムのインストール
|
||||
が完了する直前) は, 最後の行でリターンキーを打って
|
||||
`Quit' を選択すると, システムは再起動します (訳注:再起動した
|
||||
ときにはブートフロッピーディスクを抜きとります). インストールの
|
||||
際にブートマネージャオプションを選択していたなら, `F?'
|
||||
プロンプトのついたブートメニューが現れるでしょう. 表示され
|
||||
ているとおりにファンクションキーを押して FreeBSD を選択する
|
||||
と, ハードディスクから FreeBSD が立ち上がることでしょう.
|
||||
|
||||
何らかの理由でうまくいかなかった場合は, ハードウェアガイドの
|
||||
Q&Aを読んで, 問題解決の手がかりを探してください.
|
||||
|
||||
<sect1><heading>Custom インストール</heading>
|
||||
|
||||
<p>このメニューを使えば, ``Commit'' しない限り, あなたの
|
||||
システムを変更することなくすべての設定ができます. ``Commit''
|
||||
することですでに指定しておいた, システム変更の要求を実際に
|
||||
おこないます. メニューのなかの, いくつかのオプションでは,
|
||||
変更点をその場で書き込めるように `Write' コマンドが用意
|
||||
されていますが, 本当に必要があると確信を持っている場合のみ
|
||||
使用するべきでしょう. 変更点を最後まで実際に書き込まないで
|
||||
おいて, 最後の瞬間まで気が変わったときにオプションを変更
|
||||
できるようにしておくべきでしょう.
|
||||
|
||||
もしも混乱したときは大抵, F1 キーを押すと表示される
|
||||
スクリーンに関する正しい情報が得られると思います.
|
||||
|
||||
-->
|
||||
<!-- ここまでコメントアウトしてます -->
|
||||
|
||||
<sect><heading>MS-DOS ユーザのためのQ&A</heading>
|
||||
|
||||
<p>多くのFreeBSD ユーザは, MS-DOS が入っている PC に FreeBSD を
|
||||
インストールしたいと考えます. そのようなシステムに
|
||||
FreeBSD をインストールする際によく聞かれる質問を集めて
|
||||
あります.
|
||||
|
||||
<p><bf>助けて! ディスクスペースが余ってないのです.
|
||||
最初に MS-DOS のファイルを全部削除しないといけませんか? </bf>
|
||||
|
||||
もしあなたのマシンですでに MS-DOS が走っていて, FreeBSD の
|
||||
インストール用の空きスペースが少ないか, まったくない場合でも
|
||||
大丈夫です. FreeBSD の CD-ROM や, FTP サイトの <tt>tools</tt>
|
||||
ディレクトリに FIPS プログラムというのがありますが,
|
||||
これが非常に役立ちます.
|
||||
|
||||
FIPS を使えば, すでに存在している MS-DOS のパーティションを
|
||||
二つに分けることができ, さらにもともとのパーティションは
|
||||
残してくれて, 二つめのパーティションを FreeBSD の
|
||||
インストールに使用することができるようになります.
|
||||
まず DOS6.xx についてくる DEFRAG か, Norton Disk ツールを使って,
|
||||
MS-DOS パーティションからフラグメント情報を取り去って, その後に
|
||||
FIPS を走らせます. FIPS ユーティリティから必要な情報が
|
||||
手に入ります. その後マシンを立ち上げ直して, 空いた場所に
|
||||
FreeBSD をインストールします. どのくらいの空きスペースが
|
||||
インストールに必要かは, <em>Distributions</em> メニューを
|
||||
参考にしてください.
|
||||
|
||||
<bf>FreeBSD で MS-DOS の圧縮ファイルシステムにアクセス
|
||||
できますか? </bf>
|
||||
|
||||
いいえ. もし Stacker(tm) や DoubleSpace(tm) のような
|
||||
ユーティリティをお使いの場合, FreeBSD は非圧縮の部分にしか
|
||||
アクセスできません. 残りの場所は一つの大きなファイルとして
|
||||
(stack された, もしくは doublespace されたファイルとして)
|
||||
見えます. <bf>そのファイルを削除しないでください!!</bf>
|
||||
削除してしまうと後できっと後悔します.
|
||||
|
||||
非圧縮の MS-DOS の基本区画を作って, そちらを MS-DOS と
|
||||
FreeBSD とのやり取りに使うのがよろしいでしょう.
|
||||
|
||||
<bf>MS-DOS 拡張フォーマットをマウントできますか?</bf>
|
||||
|
||||
はい. DOS 拡張パーティションは FreeBSD の他の「スライス」の最後に
|
||||
マップされます. 例えば D:ドライブ が /dev/sd0s5, E:ドライブが
|
||||
/dev/sd0s6, といった具合いです. もちろん, この例では拡張
|
||||
パーティションが SCSI ドライブ 0 にあることを仮定しています.
|
||||
IDE ドライブでは当然, ``sd'' が ``wd'' となります. 他の DOS ドライブを
|
||||
マウントするのと同様に, 次のようにして拡張パーティションもちゃんと
|
||||
マウントできます:
|
||||
|
||||
<tscreen><verb>
|
||||
mount -t msdos /dev/sd0s5 /dos_d
|
||||
</verb></tscreen>
|
||||
|
||||
<bf>MS-DOS のバイナリを FreeBSD で実行できますか?</bf>
|
||||
|
||||
まだです. この機能を実現するためのサポートを期待しているのですが,
|
||||
いまのところ実際にこの作業をしている人間はいません. BSDI には
|
||||
寄贈された BSD 用の DOS エミュレータがあり, 徐々に FreeBSD-current
|
||||
に移植されつつあります.
|
||||
|
||||
もしあなたがこの作業に加わりたいと思いましたら &a.emulation
|
||||
にご連絡ください.
|
||||
|
||||
それまでの間, <ref id="ports" name="ports コレクション"> には, pcemu
|
||||
という素晴らしいアプリケーションがあり, これをつかうことで多くの
|
||||
MS-DOS のテキストモードで動くプログラムを完全な 8088CPU の
|
||||
エミュレーション環境で走らせることができます.
|
||||
@ -1,231 +0,0 @@
|
||||
<!-- $Id: isdn.sgml,v 1.7 1997/02/22 13:01:15 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.11 -->
|
||||
|
||||
<sect><heading>ISDN<label id="isdn"></heading>
|
||||
|
||||
<p><em>最終更新: &a.wlloyd;</em>.
|
||||
<p><em>訳: &a.kiroh;.<newline>11 December 1996.</em>
|
||||
|
||||
<p>ISDN 技術とハードウェアに関しては,
|
||||
<url url="http://alumni.caltech.edu/~dank/isdn/" name="Dan Kegel's
|
||||
ISDN Page"> がよい参考になるでしょう.
|
||||
|
||||
ISDN の導入手順は, 簡単にいって以下のようになります.
|
||||
<itemize>
|
||||
<item>ヨーロッパ在住の方は, ISDN カードの節に進んでください.
|
||||
|
||||
<item>ISDN を使って, インターネットプロバイダに(専用線は使用せず), ダ
|
||||
イアルアップ接続しようとしている場合は, ターミナルアダプタの使用を考え
|
||||
てみてください. この方法はもっとも柔軟性があり, プロバイダを変更した場
|
||||
合の問題も少ないでしょう.
|
||||
|
||||
<item>2つの LAN の間を接続しようする場合や, ISDN 専用線を使用する場合
|
||||
には, スタンドアローンルータ/ブリッジの使用を勧めます.
|
||||
|
||||
</itemize>
|
||||
|
||||
<p>どの方法を用いるかを決定するには, 費用が重要な要素になってきます.
|
||||
以下に, 最も安価な方法から, 高価な方法まで順に説明していきます.
|
||||
|
||||
<sect1><heading>ISDN カード</heading>
|
||||
|
||||
<p><em>原著者:&a.hm;.</em>
|
||||
|
||||
<p>このセクションの記述は, ヨーロッパの ISDN ユーザにのみ有効です.
|
||||
サポートされているカードは, まだ北米の ISDN 標準には適合していないかもしれ
|
||||
ません(?).
|
||||
|
||||
<p>このコードは, まだ大部分が開発段階にあります. とくにドライバに関し
|
||||
ては, 二つのメーカーのカードしかサポートしていません.
|
||||
|
||||
<p>PC ISDN カードは, ISDN の最大のバンド幅 128Kbs をサポートします. こ
|
||||
れらのカードは, ISDN 機器のうちもっとも安価な部類に入ります.
|
||||
|
||||
<p>FreeBSD 2.1.0 および 2.1.5 では, 初期の未完成の ISDN のためのコード
|
||||
が /usr/src/gnu/isdn に含まれていますが, 古いバージョンのものですの
|
||||
で使用しないでください. カーネルから ISDN をサポートしたい場合は,
|
||||
bisdn パッケージを入手してください. このコードは, FreeBSD 2.2 からメイ
|
||||
ンソースツリーから削除されています.
|
||||
|
||||
<p>bisdn という ISDN パッケージが以下のURLから入手できます.
|
||||
<htmlurl url="ftp://ftp.muc.ditec.de/isdn" name="ftp.muc.ditec.de">
|
||||
FreeBSD 2.1R, FreeBSD-current, NetBSDがサポートされています.
|
||||
最新のソースは, 上記のftpサーバの isdn ディレクトリから,
|
||||
bisdn-097.tar.gz という名前で入手できます.
|
||||
|
||||
以下のカードのドライバが存在します:
|
||||
<itemize>
|
||||
<item>EuroISDN (DSS1)および1TR6プロトコル用には, 現在すべての(passive) Teles
|
||||
カードおよびそのクローンがサポートされています.
|
||||
<item>Dr. Nauhaus - Niccy 1016
|
||||
</itemize>
|
||||
|
||||
bisdn には, いくつかの制限があります.
|
||||
特に ISDN に関連する機能のうち, 以下の機能はサポートされません.
|
||||
<itemize>
|
||||
<item>PPP はサポートされません. raw hdlc のみです. すなわち, Cisco 製
|
||||
など, ほとんどのスタンドアロンーンルータ等とは接続できません.
|
||||
<item>ブリッジングコントロールプロトコルはサポートされません.
|
||||
<item>複数のカードは同時に使用できません.
|
||||
<item>動的なバンド幅の変更はできません.
|
||||
<item>チャンネルのバンドリングはできません.
|
||||
</itemize>
|
||||
|
||||
majordomoによるメーリングリストが利用できます. 参加するには, 通常の
|
||||
majordomo リクエストを以下のメールアドレスまで送ってください.
|
||||
<htmlurl url="mailto:isdn-request@muc.ditec.de"
|
||||
name="isdn-request@muc.ditec.de">.
|
||||
|
||||
<sect1><heading>ISDN ターミナルアダプタ</heading>
|
||||
|
||||
<p>ターミナルアダプタ (TA) はISDN に対して, 通常の電話線に対するモデ
|
||||
ムに相当するものです.
|
||||
|
||||
<p>ほとんどの TA は, 標準のヘイズ AT コマンドセットを使用しているので,
|
||||
単にモデムと置き換えて使うことができます.
|
||||
|
||||
TA は, 基本的にはモデムと同じように動作しますが, 接続方法は異なり, 通
|
||||
信速度も古いモデムよりはるかに速くなります. <ref id="ppp" name="PPP">
|
||||
の設定を, モデムの場合と同じように行ってください. とくにシリアル速度を
|
||||
使用できる最高速度に設定するのを忘れないでください.
|
||||
|
||||
プロバイダへの接続に TA を使用する最大のメリットは, 動的 PPP を行える
|
||||
ことです. 最近 IP アドレスが不足してきているため, ほとんどのプロバイダ
|
||||
は, 専用の IP アドレスを割り当てないようになっています. ほとんどのスタ
|
||||
ンドアローンルータは, 動的 IP アドレスに対応していません.
|
||||
|
||||
訳注: 最近の ISDN ルータでは, IP アドレスの動的割り当てに対応している
|
||||
ものも多いようです. ただし制限がある場合もありますので, 詳しくはメーカ
|
||||
に問い合わせてください.
|
||||
|
||||
TA を使用した場合の機能や接続の安定性は, 使用している PPP デーモンに完
|
||||
全に依存します. そのため, FreeBSD で PPP の設定が完了していれば, 使用
|
||||
している既存のモデムを ISDN の TA に簡単にアップグレードすることができ
|
||||
ます. ただし, それまでの PPP のプログラムに問題があった場合, その問題
|
||||
は TA に置き換えてもそのまま残ります.
|
||||
|
||||
最高の安定性を求めるのであれば, ユーザープロセス<ref id="userppp"
|
||||
name="iijPPP"> ではなく, カーネル<ref id="ppp" name="PPP">を使用してく
|
||||
ださい.
|
||||
|
||||
<p>以下の TA は, FreeBSD で動作確認ずみです.
|
||||
|
||||
<itemize>
|
||||
<item>Motorola BitSurfer および Bitsurfer Pro
|
||||
<item>Adtran
|
||||
</itemize>
|
||||
|
||||
他の TA もほとんどの場合うまく動作するでしょう. TA のメーカーでは, TA
|
||||
がほとんどの標準モデム AT コマンドセットを受け付けるようにするよう, 努
|
||||
力しているようです.
|
||||
|
||||
外部 TA を使う際の最大の問題点は, モデムの場合と同じく良いシリアルカー
|
||||
ドが必要であるということです.
|
||||
|
||||
シリアルデバイスの詳細, そして非同期シリアルポートと同期シリアルポート
|
||||
の差については, ハンドブックの<ref id="uart" name="シリアルポート"> の
|
||||
節を参照してください.
|
||||
|
||||
標準の PC シリアルポート(非同期)に接続された TA は, 128Kbs の接続を行っ
|
||||
ていても, 最大通信速度が 115.2Kbs に制限されてしまいます. 128Kbs の
|
||||
ISDN の性能を最大限に生かすためには, TA を同期シリアルカードに接続しな
|
||||
ければなりません.
|
||||
|
||||
内蔵 TA を購入して, 同期／非同期問題を片付けてしまおうとは思わないでく
|
||||
ださい. 内蔵 TA には, 単に標準 PC シリアルポートのチップが内蔵されてい
|
||||
るだけです. 内蔵 TA の利点といえば, シリアルケーブルを買わなくていいと
|
||||
いうことと, 電源コンセントが一つ少なくて済むということくらいでしょう.
|
||||
|
||||
同期カードと TA の組合せは 386 の FreeBSD マシンの場合でも, スタンドア
|
||||
ローンのルータと同程度の速度は確保できます. またこの組合せでは, ルータ
|
||||
より柔軟な設定が可能です.
|
||||
|
||||
同期カード/TA を選ぶか, スタンドアローンルータを選ぶかは, 多分に宗教的
|
||||
な問題です. メーリングリストでもいくつか議論がありました. 議論の内容に
|
||||
ついては, <url url="http://www.freebsd.org/search.html" name="archives">
|
||||
を参照してください.
|
||||
|
||||
<sect1><heading>スタンドアローン ISDN ブリッジ/ルータ</heading>
|
||||
|
||||
<p>ISDN ブリッジやルータは, OS 特有のものではありません. もちろん
|
||||
FreeBSD 特有のものでもありません. ルーティングやブリッジング技術に関す
|
||||
る詳細は, ネットワークの参考書をご覧ください.
|
||||
|
||||
このページでは, ルータとブリッジにどちらでもあてはまるように記述します.
|
||||
|
||||
<p>ISDN ルータ/ブリッジは, ローエンドの製品のコストが下がってきている
|
||||
こともあり, より一般的に使用されるようになるでしょう. ISDN ルータは,
|
||||
外見は小さな箱で, ローカルのイーサネットネットワーク(もしくはカード)と
|
||||
直接, 接続します. また, 自身で他のブリッジ/ルータとの接続を制御します.
|
||||
PPP や他のプロトコルを使用するためのソフトウェアは, すべて組み込まれて
|
||||
います.
|
||||
|
||||
ルータは, 完全な同期 ISDN 接続を使用するため, 通常の TA と比較してスルー
|
||||
プットが大幅に向上します.
|
||||
|
||||
ISDN ルータ/ブリッジを使用する場合の最大の問題点は, 各メーカーの製品間
|
||||
に相性の問題がまだ存在することです. インターネットプロバイダとの接続を
|
||||
考えている場合には, プロバイダと相談することをお勧めします.
|
||||
|
||||
<p>事務所の LAN と家庭の LAN の間など, 二つの LAN セグメントの間を接続
|
||||
しようとしている場合は, ブリッジ/ルータの使用がもっともメンテナンスが
|
||||
簡単で, 努力が少なくてすむ方法です. 両側の機材を購入するのであれば, メー
|
||||
カー間の接続性の問題もないでしょう.
|
||||
|
||||
たとえば家庭の LAN や出張所の LAN を本社のネットワークに接続するために
|
||||
は, 以下のような設定が使用できます.
|
||||
|
||||
<em>出張所 LAN または 家庭 LAN</em>
|
||||
|
||||
ネットワークは, 10 Base T イーサネットです. ルータとネットワークの間は,
|
||||
必要に応じて AUI/10BT トランシーバを使って接続します.
|
||||
|
||||
<verb>
|
||||
---Sun ワークステーション
|
||||
|
|
||||
---FreeBSD マシン
|
||||
|
|
||||
---Windows 95 (別に勧めているわけじゃありません)
|
||||
|
|
||||
スタンドアローンルータ
|
||||
|
|
||||
ISDN BRI ライン
|
||||
</verb>
|
||||
家庭/出張所 LAN で, 一台しかコンピュータを接続しないのであれば, クロス
|
||||
のツイストペアケーブルを使用して, スタンドアローンルータと直結も可能で
|
||||
す.
|
||||
|
||||
<em>本社 LAN や他の LAN</em>
|
||||
|
||||
ネットワークは, ツイストペアイーサネットです.
|
||||
<verb>
|
||||
-------Novell サーバ
|
||||
| |
|
||||
|ハ ---Sun
|
||||
| |
|
||||
| ---FreeBSD
|
||||
| |
|
||||
|ブ ---Windows 95
|
||||
| |
|
||||
|___---スタンドアローンルータ
|
||||
|
|
||||
ISDN BRI ライン
|
||||
</verb>
|
||||
|
||||
ほとんどのルータ/ブリッジでは, 別々の二つのサイトに対して, 同時にそれ
|
||||
ぞれ独立した二つの PPP 接続が可能です. これは, 通常の TA ではサポート
|
||||
されない機能で, ルータ/ブリッジ接続の大きな利点です (シリアルポートを
|
||||
二つもつ特殊(そして高価な) TA では可能です). チャンネル割り当てや MPP
|
||||
などと混同しないでください.
|
||||
|
||||
これは, 大変便利な機能です. たとえば事務所で専用線インターネット ISDN
|
||||
接続を使用していて, 別の ISDN ラインを購入したくないとします. この場合,
|
||||
事務所のルータは, 一つの専用線 B チャンネル接続(64Kbs)を維持しつつ, 別
|
||||
の B チャンネルを他の用途に使用することができます. たとえば, 他の場所
|
||||
とのダイアルイン, ダイアルアウトに使用したり, バンド幅を増やすために,
|
||||
インターネットとの接続への動的に割り当て(MPP など)に使用したりすること
|
||||
が可能です.
|
||||
|
||||
<p>またイーサネットブリッジは, IP パケットだけでなく IPX/SPX などすべての
|
||||
プロトコルのパケットを中継することが可能です. </p>
|
||||
@ -1,74 +0,0 @@
|
||||
<!-- $Id: jcontrib.sgml,v 1.6 1997/03/03 04:56:30 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
|
||||
<chapt><heading>FreeBSD Handbook 日本語化について<label id="jcontrib"></heading>
|
||||
|
||||
<p>FreeBSD 日本語ドキュメンテーションプロジェクトは, FreeBSD 関係の日本語
|
||||
ドキュメントが少ないことを嘆いた数人の FreeBSD ユーザの提唱によって
|
||||
1996年2月26日にスタートし, その最初の作業として, FreeBSD Handbook
|
||||
の日本語への翻訳を始めました.
|
||||
当初の予定から大幅に遅れながらもなんとか完成することができましたが,
|
||||
これで終りではありません.
|
||||
オリジナルの FreeBSD Handbook は日毎に更新されており, 私たちもまた
|
||||
これに追い付くために作業を続けていきます. もちろん, 新しいメンバも大歓迎
|
||||
です.
|
||||
日本語翻訳版について, 何かお気づきの点がありましたら, &a.doc-jp;
|
||||
までご連絡ください.
|
||||
また, もし私たちの作業を手伝ってくれるなら,
|
||||
<url url="http://www.astec.co.jp/~hanai/FreeBSD/" name="FreeBSD 日本語ドキュメンテーションプロジェクトのページ">をご覧の上, 是非参加してください.
|
||||
|
||||
<sect><heading>翻訳者 (五十音順)</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
<item>&a.asami
|
||||
<item>&a.arimura
|
||||
<item>&a.graphite
|
||||
<item>&a.iwasaki
|
||||
<item>&a.yoshiaki
|
||||
<item>&a.candy
|
||||
<item>&a.kimura
|
||||
<item>&a.masaki
|
||||
<item>&a.motoyuki
|
||||
<item>&a.saeki
|
||||
<item>&a.simokawa
|
||||
<item>&a.yasu
|
||||
<item>&a.mihoko
|
||||
<item>&a.ts
|
||||
<item>&a.nakai
|
||||
<item>&a.ikuo
|
||||
<item>&a.max
|
||||
<item>&a.hanai
|
||||
<item>&a.kiroh
|
||||
<item>&a.hino
|
||||
<item>&a.yuki
|
||||
<item>&a.maruyama
|
||||
<item>&a.mita
|
||||
<item>&a.kmiyakoda
|
||||
<item>&a.tomo
|
||||
</itemize>
|
||||
|
||||
<sect><heading>査読者 (五十音順)</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
<item>&a.asami
|
||||
<item>&a.iwasaki
|
||||
<item>&a.yoshiaki
|
||||
<item>&a.kanou
|
||||
<item>&a.koga
|
||||
<item>&a.saeki
|
||||
<item>&a.hanai
|
||||
<item>&a.nao
|
||||
<item>&a.kiroh
|
||||
<item>&a.hino
|
||||
<item>&a.yuki
|
||||
</itemize>
|
||||
|
||||
<sect><heading>ツール作成者</heading>
|
||||
|
||||
<p>
|
||||
<itemize>
|
||||
<item>&a.katsu
|
||||
<item>&a.iwasaki
|
||||
</itemize>
|
||||
@ -1,132 +0,0 @@
|
||||
<!-- $Id: jmembers.sgml,v 1.7 1997/03/03 04:56:31 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
|
||||
<!--
|
||||
翻訳者及び査読者の名前及び電子メールアドレス
|
||||
-->
|
||||
|
||||
<!ENTITY a.doc-jp "FreeBSD 日本語ドキュメンテーションプロジェクト
|
||||
<tt><htmlurl url='mailto:doc-jp@jp.FreeBSD.ORG'
|
||||
name='<doc-jp@jp.FreeBSD.ORG>'></tt>">
|
||||
|
||||
<!--
|
||||
<!ENTITY a.asami "浅見 賢
|
||||
<tt><htmlurl url='mailto:asami@FreeBSD.ORG'
|
||||
name='<asami@FreeBSD.ORG>'></tt>">
|
||||
浅見さんは既に authors.sgml に入っているのでコメントアウト ;-)
|
||||
-->
|
||||
|
||||
<!ENTITY a.nakai "中井 幸博
|
||||
<tt><htmlurl url='mailto:nakai@mlab.t.u-tokyo.ac.jp'
|
||||
name='<nakai@mlab.t.u-tokyo.ac.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.koga "こがよういちろう
|
||||
<tt><htmlurl url='mailto:y-koga@ccs.mt.nec.co.jp'
|
||||
name='<y-koga@ccs.mt.nec.co.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.iwasaki "岩崎 満
|
||||
<tt><htmlurl url='mailto:iwasaki@jp.FreeBSD.org'
|
||||
name='<iwasaki@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.yuki "前田 幸範
|
||||
<tt><htmlurl url='mailto:yuki@jp.FreeBSD.org'
|
||||
name='<yuki@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!--
|
||||
<!ENTITY a.max "中根 雅文
|
||||
<tt><htmlurl url='mailto:max@FreeBSD.ORG'
|
||||
name='<max@FreeBSD.ORG>'></tt>">
|
||||
中根さんは既に authors.sgml に入っているのでコメントアウト ;-)
|
||||
-->
|
||||
|
||||
<!ENTITY a.yasu "鈴木 康修
|
||||
<tt><htmlurl url='mailto:yasu@hike.te.chiba-u.ac.jp'
|
||||
name='<yasu@hike.te.chiba-u.ac.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.katsu "勝間田 淳
|
||||
<tt><htmlurl url='mailto:katsu@baum.kiyose.tokyo.jp'
|
||||
name='<katsu@baum.kiyose.tokyo.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.ts "冨田 重成
|
||||
<tt><htmlurl url='mailto:ts@icu.ac.jp'
|
||||
name='<ts@icu.ac.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.saeki "佐伯 隆司
|
||||
<tt><htmlurl url='mailto:saeki@jp.FreeBSD.org'
|
||||
name='<saeki@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.kiroh "はらだ きろう
|
||||
<tt><htmlurl url='mailto:kiroh@kh.rim.or.jp'
|
||||
name='<kiroh@kh.rim.or.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.masaki "櫛田 昌希
|
||||
<tt><htmlurl url='mailto:masaki@po.iijnet.or.jp'
|
||||
name='<masaki@po.iijnet.or.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.hino "日野 浩志
|
||||
<tt><htmlurl url='mailto:hino@nwk.cl.nec.co.jp'
|
||||
name='<hino@nwk.cl.nec.co.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.mita "三田 吉郎
|
||||
<tt><htmlurl url='mailto:mita@jp.FreeBSD.org'
|
||||
name='<mita@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.yoshiaki "内川 喜章
|
||||
<tt><htmlurl url='mailto:yoshiaki@kt.rim.or.jp'
|
||||
name='<yoshiaki@kt.rim.or.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.arimura "有村 光晴
|
||||
<tt><htmlurl url='mailto:arimura@jp.FreeBSD.org'
|
||||
name='<arimura@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.hanai "花井 浩之
|
||||
<tt><htmlurl url='mailto:hanai@jp.FreeBSD.org'
|
||||
name='<hanai@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.tomo "渡辺 智雄
|
||||
<tt><htmlurl url='mailto:tomo@jp.FreeBSD.org'
|
||||
name='<tomo@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.mihoko "田中 美穂子
|
||||
<tt><htmlurl url='mailto:mihoko@pa.yokogawa.co.jp'
|
||||
name='<mihoko@pa.yokogawa.co.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.simokawa "下川 英敏
|
||||
<tt><htmlurl url='mailto:simokawa@jp.FreeBSD.org'
|
||||
name='<simokawa@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.graphite "石墨 紀孝
|
||||
<tt><htmlurl url='mailto:graphite@jp.FreeBSD.org'
|
||||
name='<graphite@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.kimura "木村 成伴
|
||||
<tt><htmlurl url='mailto:kimura@netlab.is.tsukuba.ac.jp'
|
||||
name='<kimura@netlab.is.tsukuba.ac.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.ikuo "中川 郁夫
|
||||
<tt><htmlurl url='mailto:ikuo@jp.FreeBSD.org'
|
||||
name='<ikuo@jp.FreeBSD.org>'></tt>">
|
||||
|
||||
<!ENTITY a.kmiyakoda "都田 克郎
|
||||
<tt><htmlurl url='mailto:kmiyakoda@ctn.co.jp'
|
||||
name='<kmiyakoda@ctn.co.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.kanou "狩野 宏樹
|
||||
<tt><htmlurl url='mailto:g92k0323@cfi.waseda.ac.jp'
|
||||
name='<g92k0323@cfi.waseda.ac.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.nao "浜田 直樹
|
||||
<tt><htmlurl url='mailto:nao@tom-yam.or.jp'
|
||||
name='<nao@tom-yam.or.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.maruyama "丸山 剛司
|
||||
<tt><htmlurl url='mailto:tmaruya@nnc.or.jp'
|
||||
name='<tmaruya@nnc.or.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.candy "神田敏広
|
||||
<tt><htmlurl url='mailto:candy@fct.kgc.co.jp'
|
||||
name='<candy@fct.kgc.co.jp>'></tt>">
|
||||
|
||||
<!ENTITY a.motoyuki "今野 元之
|
||||
<tt><htmlurl url='mailto:motoyuki@st.rim.or.jp'
|
||||
name='<motoyuki@st.rim.or.jp>'></tt>">
|
||||
@ -1,492 +0,0 @@
|
||||
<!-- $Id: kerberos.sgml,v 1.4 1997/02/22 13:01:19 peter Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.10 -->
|
||||
|
||||
<sect><heading>Kerberos<label id="kerberos"></heading>
|
||||
|
||||
<p><em>原作: &a.markm; (&a.md; からの寄稿に基づいています).</em>
|
||||
|
||||
<em>訳: &a.arimura;.</em>
|
||||
|
||||
Kerberosは, サーバのサービスによってユーザが安全に認証を受けられる
|
||||
ようにするための, ネットワークの付加システム及びプロトコルです.
|
||||
リモートログイン, リモートコピー, システム間での安全なファイルのコピ
|
||||
ーやその他のリスクの高い仕事がかなり安全に, そしてこれまでより制御
|
||||
できるようになります.
|
||||
|
||||
以下の文章は, FreeBSD用として配布されているKerberosをセットアップ
|
||||
する際のガイドとして読むことができます.
|
||||
しかし, 完全な説明が必要な場合には, マニュアルページを読んだ方がよい
|
||||
でしょう.
|
||||
|
||||
FreeBSDのKerberosは, オリジナルの4.4BSD-Liteの配布に含まれている
|
||||
ものではなく, FreeBSD 1.1.5.1のときに移植されたeBonesです.
|
||||
これはアメリカ/カナダの外で作成されており, これら以外の国の人々にも
|
||||
手に入れられるものです.
|
||||
|
||||
このソフトウェアを合法的な配布物として得るために, アメリカも
|
||||
しくはカナダのサイトから<em>持ってこないでください</em>.
|
||||
でないと, そのサイトが<em>大変な</em>問題に巻き込まれます.
|
||||
合法的な配布は, 南アフリカの<tt>skeleton.mikom.csir.co.za</tt>から
|
||||
入手することができます.
|
||||
|
||||
<sect1>
|
||||
<heading>初期データベースの作成</heading>
|
||||
|
||||
<p>この作業はKerberosサーバだけでおこないます. まず, 古いKerberosの
|
||||
データベースが存在しないことを確認してください.
|
||||
ディレクトリ<tt>/etc/kerberosIV</tt>に移って, 次のファイルだけが
|
||||
存在することをチェックします:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cd /etc/kerberosIV
|
||||
grunt# ls
|
||||
README krb.conf krb.realms
|
||||
</verb></tscreen>
|
||||
|
||||
<p>もし他のファイル (<tt>principal.*</tt>や<tt>master_key</tt>) が
|
||||
存在する場合には, <tt>kdb_destroy</tt>というコマンドで古い
|
||||
Kerberosデータベースを消してください.
|
||||
Kerberosが走っていなければ, 単に<tt>rm</tt>で余計なファイルを消せ
|
||||
ばよいです.
|
||||
|
||||
まず, <tt>krb.conf</tt>と<tt>krb.realms</tt>を編集してKerberosの
|
||||
管理領域 (realm) を定義してください. ここでは管理領域が<it>GRONDAR.ZA</it>
|
||||
で, サーバ名が<it>grunt.grondar.za</it>であるとします.
|
||||
<tt>krb.conf</tt>というファイルを次のように編集してください:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cat krb.conf
|
||||
GRONDAR.ZA
|
||||
GRONDAR.ZA grunt.grondar.za admin server
|
||||
CS.BERKELEY.EDU okeeffe.berkeley.edu
|
||||
ATHENA.MIT.EDU kerberos.mit.edu
|
||||
ATHENA.MIT.EDU kerberos-1.mit.edu
|
||||
ATHENA.MIT.EDU kerberos-2.mit.edu
|
||||
ATHENA.MIT.EDU kerberos-3.mit.edu
|
||||
LCS.MIT.EDU kerberos.lcs.mit.edu
|
||||
TELECOM.MIT.EDU bitsy.mit.edu
|
||||
ARC.NASA.GOV trident.arc.nasa.gov
|
||||
</verb></tscreen>
|
||||
|
||||
<p>この例にあるような他の管理領域は, 実際には必要ありません.
|
||||
この例は複数の管理領域を認識する方法を示したものですので,
|
||||
これらの行は含めなくても結構です.
|
||||
|
||||
1行目はこのシステムが動いている管理領域の名前です.
|
||||
他の行は管理領域とホスト名のエントリです.
|
||||
行の1つめの単語が管理領域で, 2つめがその管理領域の中で
|
||||
``鍵配布センター''(Key Distribution Center) として働くホスト名です.
|
||||
ホスト名の次に ``admin server'' と書いてある場合には, そのホストが
|
||||
``管理データベースサーバ''(Administrative Database Server) も提供
|
||||
することを意味します.
|
||||
これらの単語について詳しく知りたい場合にはKerberosのマニュアル
|
||||
ページをご覧ください.
|
||||
|
||||
ここで, <it>GRONDAR.ZA</it>という管理領域に<it>grunt.grondar.za</it>
|
||||
およびその他の<it>.grondar.za</it>ドメインのすべてのホストを追加し
|
||||
なければなりません. <tt>krb.realms</tt>は次のようになります:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cat krb.realms
|
||||
grunt.grondar.za GRONDAR.ZA
|
||||
.grondar.za GRONDAR.ZA
|
||||
.berkeley.edu CS.BERKELEY.EDU
|
||||
.MIT.EDU ATHENA.MIT.EDU
|
||||
.mit.edu ATHENA.MIT.EDU
|
||||
</verb></tscreen>
|
||||
|
||||
<p>もう一度注意しますが, 他の管理領域を書く必要はありません.
|
||||
これらは複数の管理領域を認識できるようにマシンを設定する方法を
|
||||
示した例ですので, これらの行は消して構いません.
|
||||
|
||||
1行目は名前をつけた管理領域に<it>特定の</it>システムを含めるための
|
||||
ものです. 残りの行は名前をつけた管理領域にサブドメインのデフォルトの
|
||||
システムを含めるためのものです.
|
||||
|
||||
これでデータベースを作成する準備ができました. この操作はKerberos
|
||||
サーバ (鍵配布センター) を起動するだけです. <tt>kdb_init</tt>コ
|
||||
マンドを次のように実行してください:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kdb_init
|
||||
Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA
|
||||
You will be prompted for the database Master Password.
|
||||
It is important that you NOT FORGET this password.
|
||||
|
||||
Enter Kerberos master key:
|
||||
</verb></tscreen>
|
||||
|
||||
<p>ここで鍵を保存して, ローカルのマシンにあるサーバが取り出せるように
|
||||
します. それには<tt>kstash</tt>コマンドを使用します.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kstash
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
</verb></tscreen>
|
||||
|
||||
<p>これで暗号化されたマスタパスワードが
|
||||
<tt>/etc/kerberosIV/master_key</tt>に保存されました.
|
||||
|
||||
<sect1>
|
||||
<heading>すべてが動くようにするための設定</heading>
|
||||
|
||||
<p>Kerberosを導入する<it>それぞれの</it>システムのデータベースに, 2つ
|
||||
のprincipal (主体名) を追加する必要があります. その名前は
|
||||
<tt>kpasswd</tt>と<tt>rcmd</tt>です. これら2つのprincipalは, 個々
|
||||
のシステムにおいて, システム名と同じ名前のインスタンスと組にして作成
|
||||
されます.
|
||||
|
||||
これらの<tt>kpasswd</tt>と<tt>rcmd</tt>というデーモンによって, 他の
|
||||
システムからKerberosのパスワードを変更したり, <tt>rcp</tt>や
|
||||
<tt>rlogin</tt>, <tt>rsh</tt>といったコマンドを実行したりできるよ
|
||||
うになります.
|
||||
|
||||
それでは実際にこれらのエントリを追加しましょう:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kdb_edit
|
||||
Opening database...
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
Previous or default values are in [brackets] ,
|
||||
enter return to leave the same, or new value.
|
||||
|
||||
Principal name: passwd
|
||||
Instance: grunt
|
||||
|
||||
<Not found>, Create [y] ? y
|
||||
|
||||
Principal: passwd, Instance: grunt, kdc_key_ver: 1
|
||||
New Password: <---- ここは「RANDOM」と入力してください
|
||||
Verifying password
|
||||
|
||||
New Password: <---- ここは「RANDOM」と入力してください
|
||||
|
||||
Random password [y] ? y
|
||||
|
||||
Principal's new key version = 1
|
||||
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ?
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name: rcmd
|
||||
Instance: grunt
|
||||
|
||||
<Not found>, Create [y] ?
|
||||
|
||||
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
|
||||
New Password: <---- ここは「RANDOM」と入力してください
|
||||
Verifying password
|
||||
|
||||
New Password: <---- ここは「RANDOM」と入力してください
|
||||
|
||||
Random password [y] ?
|
||||
|
||||
Principal's new key version = 1
|
||||
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ?
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name: <---- 何も入力しないと終了します
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>サーバファイルの作成</heading>
|
||||
|
||||
<p>次に, 各マシンにおけるサービスを定義している, すべてのインスタンス
|
||||
を展開します. これには<tt>ext_srvtab</tt>というコマンドを使用しま
|
||||
す. このコマンドで作成されるファイルは, Kerberosの各クライアン
|
||||
トの/etc/kerberosIVディレクトリに<it>安全な方法で</it>コピーまたは
|
||||
移動する必要があります. このファイルはそれぞれのサーバとクラ
|
||||
イアントに存在しなければならず, またKerberosの運用において重要なも
|
||||
のです.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# ext_srvtab grunt
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
Generating 'grunt-new-srvtab'....
|
||||
</verb></tscreen>
|
||||
|
||||
<p>このコマンドは一時的なファイルを作成するだけです. ファイル名をすべ
|
||||
てのサーバが読めるような<tt>srvtab</tt>という名前に変更しな
|
||||
ければなりません. <tt>mv</tt>コマンドを用いてシステムの場所に移動
|
||||
してください.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# mv grunt-new-srvtab srvtab
|
||||
</verb></tscreen>
|
||||
|
||||
<p>そのファイルがクライアントに配るためのもので, ネットワークが安全で
|
||||
はないと思われる場合には, <tt><client>-new-srvtab</tt>を移動
|
||||
可能なメディアにコピーして物理的に安全な方法で運んでください. クラ
|
||||
イアントの<tt>/etc/kerberosIV</tt>ディレクトリで, 名前を
|
||||
<tt>srvtab</tt>に変更し, modeを600にするのを忘れないでください:
|
||||
|
||||
<tscreen><verb>
|
||||
grumble# mv grumble-new-srvtab srvtab
|
||||
grumble# chmod 600 srvtab
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>データベースへのユーザの追加</heading>
|
||||
|
||||
<p>ここで, ユーザのエントリをデータベースに追加する必要があります.
|
||||
始めに, ユーザ<it>jane</it>のエントリを作成してみましょう.
|
||||
<tt>kdb_edit</tt>を用いて次のように作成してください:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kdb_edit
|
||||
Opening database...
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
Previous or default values are in [brackets] ,
|
||||
enter return to leave the same, or new value.
|
||||
|
||||
Principal name: jane
|
||||
Instance:
|
||||
|
||||
<Not found>, Create [y] ? y
|
||||
|
||||
Principal: jane, Instance: , kdc_key_ver: 1
|
||||
New Password: <---- 安全なパスワードを入れてください
|
||||
Verifying password
|
||||
|
||||
New Password: <---- もう一度パスワードを入れてください
|
||||
|
||||
Principal's new key version = 1
|
||||
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ?
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name: <---- 何も入力しないと終了します
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>すべてのテスト</heading>
|
||||
|
||||
<p>まず始めにKerberosデーモンを起動する必要があります.
|
||||
<tt>/etc/sysconfig</tt>ファイルを正しく編集してあれば, マシンを再
|
||||
起動することでに自動的にデーモンが起動します. これはKerberosサー
|
||||
バでのみ必要です. Kerberosクライアントは<tt>/etc/kerberosIV</tt>か
|
||||
ら必要なものを自動的に入手します.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kerberos &
|
||||
grunt# Kerberos server starting
|
||||
Sleep forever on error
|
||||
Log file is /var/log/kerberos.log
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
|
||||
Current Kerberos master key version is 1
|
||||
Local realm: GRONDAR.ZA
|
||||
grunt# kadmind -n &
|
||||
grunt# KADM Server KADM0.0A initializing
|
||||
Please do not use 'kill -9' to kill this job, use a
|
||||
regular kill instead
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
</verb></tscreen>
|
||||
|
||||
<p>さあ, これで上で作成した<it>jane</it>というIDのチケットを
|
||||
<tt>kinit</tt>コマンドで得ることができます:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt$ kinit jane
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
Kerberos Initialization for "jane"
|
||||
Password:
|
||||
</verb></tscreen>
|
||||
|
||||
<p><tt>klist</tt>コマンドを用いてトークンを見て, きちんとチケットを持って
|
||||
いるかどうか確認してください:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt$ klist
|
||||
Ticket file: /tmp/tkt245
|
||||
Principal: jane@GRONDAR.ZA
|
||||
|
||||
Issued Expires Principal
|
||||
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<p><tt>passwd</tt>コマンドを用いてパスワードを変更して, kpasswdデーモ
|
||||
ンがKerberosデータベースに対して認証されるかどうかチェックして
|
||||
ください:
|
||||
|
||||
|
||||
<tscreen><verb>
|
||||
grunt$ passwd
|
||||
realm GRONDAR.ZA
|
||||
Old password for jane:
|
||||
New Password for jane:
|
||||
Verifying password
|
||||
New Password for jane:
|
||||
Password changed.
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading><tt>su</tt>特権の追加</heading>
|
||||
|
||||
<p>root権限が必要なユーザは<it>誰でも</it>, <tt>su</tt>コマンドのパス
|
||||
ワードをユーザ毎に<it>別のもの</it>として持つことができます.
|
||||
<it>root</it>に<tt>su</tt>できる権利を与えられたidを追加します.
|
||||
これは, principalに付いている<it>root</it>というインスタンスに
|
||||
よって制御されています. <tt>kdb_edit</tt>を用いて
|
||||
<it>jane.root</it>というエントリをKerberosデータベースに作成します:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kdb_edit
|
||||
Opening database...
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
||||
Current Kerberos master key version is 1.
|
||||
|
||||
Master key entered. BEWARE!
|
||||
Previous or default values are in [brackets] ,
|
||||
enter return to leave the same, or new value.
|
||||
|
||||
Principal name: jane
|
||||
Instance: root
|
||||
|
||||
<Not found>, Create [y] ? y
|
||||
|
||||
Principal: jane, Instance: root, kdc_key_ver: 1
|
||||
New Password: <---- 安全なパスワードを入れます
|
||||
Verifying password
|
||||
|
||||
New Password: <---- もう一回パスワードを入れます
|
||||
|
||||
Principal's new key version = 1
|
||||
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ここは短くしてください
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name: <---- 何も入力しないと終了します
|
||||
</verb></tscreen>
|
||||
|
||||
<p>実際にトークンをもらって, ちゃんと働いているかどうか確認しましょう:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# kinit jane.root
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
Kerberos Initialization for "jane.root"
|
||||
Password:
|
||||
</verb></tscreen>
|
||||
|
||||
<p>ここでrootユーザの<tt>.klogin</tt>ファイルにユーザを追加する必要が
|
||||
あります.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cat /root/.klogin
|
||||
jane.root@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<p><tt>su</tt>してみましょう:
|
||||
|
||||
<tscreen><verb>
|
||||
[jane@grunt 10407] su
|
||||
Password:
|
||||
grunt#
|
||||
</verb></tscreen>
|
||||
|
||||
どのトークンを持っているか見てみましょう:
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# klist
|
||||
Ticket file: /tmp/tkt_root_245
|
||||
Principal: jane.root@GRONDAR.ZA
|
||||
|
||||
Issued Expires Principal
|
||||
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>他のコマンドの使用</heading>
|
||||
|
||||
<p>ここまでの例では, <tt>jane</tt>というprincipalを<tt>root</tt>とい
|
||||
うインスタンス付きで作成しました. これはユーザと同じ名前をprincipalと
|
||||
しており, Kerberosのデフォルトの値です;
|
||||
<em><username>.</em><tt>root</tt>という形式の
|
||||
<em><principal>.<instance></em>で, 必要なエント
|
||||
リが<tt>root</tt>のホームディレクトリの<tt>.klogin</tt>ファイルに
|
||||
あれば, <em><username></em>がrootに<tt>su</tt>することができま
|
||||
す.
|
||||
|
||||
<tscreen><verb>
|
||||
grunt# cat /root/.klogin
|
||||
jane.root@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<p>同様に, ユーザのホームディレクトリの<tt>.klogin</tt>ファイルに次の
|
||||
ような行がある場合には:
|
||||
|
||||
<tscreen><verb>
|
||||
[jane@grunt 10543] cat ~/.klogin
|
||||
jane@GRONDAR.ZA
|
||||
jack@GRONDAR.ZA
|
||||
</verb></tscreen>
|
||||
|
||||
<p><em>jane</em>または<em>jack</em>という名前で (前述の<tt>kinit</tt>
|
||||
によって) 認証されている<em>GRONDAR.ZA</em>という管理領域のユーザ
|
||||
なら誰でも<tt>rlogin</tt>や<tt>rsh</tt>, <tt>rcp</tt>等によってこ
|
||||
のシステム (<em>grunt</em>) の<em>jane</em>のアカウントまたはファ
|
||||
イルにアクセスできます.
|
||||
|
||||
例えば, Janeが他のシステムにKerberosを用いてloginします:
|
||||
|
||||
<tscreen><verb>
|
||||
[jane@grumble 573] kinit
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
Password:
|
||||
[jane@grumble 574] rlogin grunt
|
||||
Last login: Mon May 1 21:14:47 from grumble
|
||||
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
|
||||
The Regents of the University of California. All rights reserved.
|
||||
|
||||
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
|
||||
|
||||
[jane@grunt 10567]
|
||||
</verb></tscreen>
|
||||
|
||||
<p>次の例では, Jackが同じマシンのJaneのアカウントにloginします. Janeは
|
||||
<tt>.klogin</tt>ファイルを前述のように設定しており,
|
||||
Kerberosでは<em>jack</em>というprincipalをインスタンスなしで設定してあ
|
||||
ります.
|
||||
|
||||
<tscreen><verb>
|
||||
[jack@grumble 573] kinit
|
||||
[jack@grumble 574] rlogin grunt -l jane
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
Password:
|
||||
Last login: Mon May 1 21:16:55 from grumble
|
||||
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
|
||||
The Regents of the University of California. All rights reserved.
|
||||
|
||||
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
|
||||
|
||||
[jane@grunt 10578]
|
||||
</verb></tscreen>
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,523 +0,0 @@
|
||||
<!-- $Id: kerneldebug.sgml,v 1.6 1997/03/25 06:31:27 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.14 -->
|
||||
|
||||
<chapt><heading>カーネルデバッグ<label id="kerneldebug"></heading>
|
||||
|
||||
<p><em>原作 &a.paul; and &a.joerg;</em>
|
||||
<p><em>訳: &a.yoshiaki;. <newline>
|
||||
18 March 1997. </em>
|
||||
|
||||
<sect><heading>kgdbによるカーネルのクラッシュダンプのデバッグ</heading>
|
||||
|
||||
<p>ここではクラッシュダンプ (crash dump : 訳注 この文脈では kernel 自身
|
||||
の異常によって停止した場合に出力されるイメージを指します) によるカー
|
||||
ネルデバッグの方法を示します.
|
||||
|
||||
ここではダンプするための十分なスワップ (swap) の容量があるものとし
|
||||
ます.
|
||||
もし複数のスワップパーティションを持ち, 最初のパーティションがダンプ
|
||||
を保持するのに十分な大きさを持たない場合は別のダンプデバイスを使うよ
|
||||
うに (<tt>config kernel</tt> 行で) カーネルのコンフィグをおこなうか,
|
||||
dumpon(8)コマンドを使って別のデバイスを示すことができます. スワップ
|
||||
をおこなわないデバイスへのダンプ, 例えばテープへのダンプは現在サポートさ
|
||||
れていません. カーネルのコンフィグは <tt>config -g</tt> によって行っ
|
||||
てください.
|
||||
<ref id="kernelconfig" name="FreeBSDカーネルのコンフィグレーション">
|
||||
には FreeBSDのカーネルの設定の詳細がありますので参照してください.
|
||||
|
||||
<tt>dumpon(8)</tt>コマンドを使ってどこへダンプするかカーネルに伝えて
|
||||
ください(swapon(8)によってそのパーティションがスワップとして設定された
|
||||
後でなければならないことに注意してください). これは普通は
|
||||
<tt>/etc/sysconfig</tt> や <tt>/etc/rc</tt>で設定されます. あるいは
|
||||
別の方法としてカーネルコンフィグレーションファイルの `config'行の `dump'節 で
|
||||
ダンプデバイスをハードコードすることができます. この方法はあまりよくは
|
||||
ありません. カーネルがブート時に crash する場合のクラッシュダンプを取り
|
||||
たい時だけ使うべきです.
|
||||
|
||||
<em><bf>Note:</bf> 以下では `<tt>kgdb</tt>'という用語は <tt>gdb</tt>を
|
||||
カーネルデバッグモードで動かしていることを意味します. <tt>gdb</tt>を
|
||||
<tt>-k</tt>オプションをつけて起動するか <tt>kgdb</tt>という名前でリン
|
||||
クして起動することでこのモードになります. デフォルトでは このリンク
|
||||
は作られていません. また, このアイデアは GNU関係者たちが彼らのツール
|
||||
を別の名前で呼び出した時に異なった動作をするということを好まない, と
|
||||
いう点で不評です. あるいは将来この機能を廃止することになるかもしれません. </em>
|
||||
|
||||
カーネルを作った時にそのコピーを <tt>kernel.debug</tt>という名前で作
|
||||
りましょう. また, オリジナルに対して <tt>strip -d</tt>を実行します.
|
||||
オリジナルを普通にインストールします. また strip していないカーネル
|
||||
も同様にインストールすることができますが, シンボルテーブルの参照時間
|
||||
がいくつかのプログラムでは劇的に増加するでしょう. また, カーネル全体
|
||||
はブート時に読み込まれスワップアウトされないため数メガバイトの物理メ
|
||||
モリが無駄になります.
|
||||
|
||||
例えばブートプロンプトで新しいカーネルの名前をタイプすることによって,
|
||||
新しいカーネルをテストした場合で, 再びシステムを動かすのに別のカーネ
|
||||
ルで立ち上げることが必要な場合はブートプロンプトで <tt>-s</tt>フラグ
|
||||
を使いシングルユーザの状態にしてください. そして以下のような操作をおこな
|
||||
います.
|
||||
<tscreen><verb>
|
||||
fsck -p
|
||||
mount -a -t ufs # /var/crash 用のファイルシステムを書き込み可能にする
|
||||
savecore -N /kernel.panicked /var/crash
|
||||
exit # ...マルチユーザモードへ移行
|
||||
</verb></tscreen>
|
||||
ここに示した <tt>savecore(8)</tt>は (現在動いているものとは別の) カー
|
||||
ネルのシンボル名の抽出をおこなうために使っています. 抽出はデフォルトで
|
||||
は現在動いているカーネルに対しておこなわれ, クラッシュダンプとカーネルシンボ
|
||||
ルのくい違いのためにまったく何もしません (訳注:そのためにオプション
|
||||
で実際にダンプをおこしたカーネルを指定します).
|
||||
|
||||
クラッシュダンプの起きた後に <tt>/sys/compile/WHATEVER</tt>へ行き
|
||||
<tt>kgdb</tt>を動かします. <tt>kgdb</tt> より次のようにします.
|
||||
<tscreen><verb>
|
||||
symbol-file kernel.debug
|
||||
exec-file /var/crash/kernel.0
|
||||
core-file /var/crash/vmcore.0
|
||||
</verb></tscreen>
|
||||
こうすると, クラッシュダンプを使ってカーネルソースを他のプログラムと同様に
|
||||
デバッグすることができます.
|
||||
|
||||
次に <tt>kgdb</tt> での手順のセッションのログを示します. 長い行は読
|
||||
みやすくするために改行しました. また, 参照のために行番号を入れてあり
|
||||
ます. ただし, これは実際の pcvtコンソールドライバの開発中の実際のエ
|
||||
ラーのトレースです.
|
||||
<tscreen><verb>
|
||||
1:Script started on Fri Dec 30 23:15:22 1994
|
||||
2:uriah # cd /sys/compile/URIAH
|
||||
3:uriah # kgdb kernel /var/crash/vmcore.1
|
||||
4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done.
|
||||
5:IdlePTD 1f3000
|
||||
6:panic: because you said to!
|
||||
7:current pcb at 1e3f70
|
||||
8:Reading in symbols for ../../i386/i386/machdep.c...done.
|
||||
9:(kgdb) where
|
||||
10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767)
|
||||
11:#1 0xf0115159 in panic ()
|
||||
12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698)
|
||||
13:#3 0xf010185e in db_fncall ()
|
||||
14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073)
|
||||
15:#5 0xf0101711 in db_command_loop ()
|
||||
16:#6 0xf01040a0 in db_trap ()
|
||||
17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723)
|
||||
18:#8 0xf019d2eb in trap_fatal (...)
|
||||
19:#9 0xf019ce60 in trap_pfault (...)
|
||||
20:#10 0xf019cb2f in trap (...)
|
||||
21:#11 0xf01932a1 in exception:calltrap ()
|
||||
22:#12 0xf0191503 in cnopen (...)
|
||||
23:#13 0xf0132c34 in spec_open ()
|
||||
24:#14 0xf012d014 in vn_open ()
|
||||
25:#15 0xf012a183 in open ()
|
||||
26:#16 0xf019d4eb in syscall (...)
|
||||
27:(kgdb) up 10
|
||||
28:Reading in symbols for ../../i386/i386/trap.c...done.
|
||||
29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\
|
||||
30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\
|
||||
31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\
|
||||
32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\
|
||||
33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\
|
||||
34:ss = -266427884}) (../../i386/i386/trap.c line 283)
|
||||
35:283 (void) trap_pfault(&frame, FALSE);
|
||||
36:(kgdb) frame frame->tf_ebp frame->tf_eip
|
||||
37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done.
|
||||
38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\
|
||||
39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403)
|
||||
40:403 return ((*linesw[tp->t_line].l_open)(dev, tp));
|
||||
41:(kgdb) list
|
||||
42:398
|
||||
43:399 tp->t_state |= TS_CARR_ON;
|
||||
44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */
|
||||
45:401
|
||||
46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200)
|
||||
47:403 return ((*linesw[tp->t_line].l_open)(dev, tp));
|
||||
48:404 #else
|
||||
49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag));
|
||||
50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */
|
||||
51:407 }
|
||||
52:(kgdb) print tp
|
||||
53:Reading in symbols for ../../i386/i386/cons.c...done.
|
||||
54:$1 = (struct tty *) 0x1bae
|
||||
55:(kgdb) print tp->t_line
|
||||
56:$2 = 1767990816
|
||||
57:(kgdb) up
|
||||
58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\
|
||||
59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126)
|
||||
60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p));
|
||||
61:(kgdb) up
|
||||
62:#2 0xf0132c34 in spec_open ()
|
||||
63:(kgdb) up
|
||||
64:#3 0xf012d014 in vn_open ()
|
||||
65:(kgdb) up
|
||||
66:#4 0xf012a183 in open ()
|
||||
67:(kgdb) up
|
||||
68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\
|
||||
69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\
|
||||
70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \
|
||||
71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \
|
||||
72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673)
|
||||
73:673 error = (*callp->sy_call)(p, args, rval);
|
||||
74:(kgdb) up
|
||||
75:Initial frame selected; you cannot go up.
|
||||
76:(kgdb) quit
|
||||
77:uriah # exit
|
||||
78:exit
|
||||
79:
|
||||
80:Script done on Fri Dec 30 23:18:04 1994
|
||||
</verb></tscreen>
|
||||
上の出力についてのコメントをします.
|
||||
|
||||
<descrip>
|
||||
<tag/line 6:/ これは DDB (後述) からのダンプです. このため ``because you
|
||||
said to!'' という panicコメントがつき, ページフォルトのト
|
||||
ラップによって DDBに入ったことが原因の, やや長いスタックトレー
|
||||
スがあります.
|
||||
<tag/line 20:/ スタックトレースでのこれは <tt>trap()</tt>関数の位置で
|
||||
す.
|
||||
<tag/line 36:/ 新しいスタックフレームの使用を指定しています. これは現
|
||||
在は必要ありません. trapの場合ではスタックフレームは正
|
||||
しい場所を指していると考えられます. (私は新しいコアダンプ
|
||||
を持っていません. 私のカーネルは長い間 panicを起こしていま
|
||||
せん.) ソースコードの 403行を見ると,``tp''ポインタのアク
|
||||
セスが失敗しているか配列のアクセスが範囲外である可能性が高
|
||||
いことがわかります.
|
||||
<tag/line 52:/ 怪しいポインタですが, アクセスは正常におこなえました.
|
||||
<tag/line 56:/ ところが, 明らかにポインタはゴミを指しています. これで
|
||||
エラーを見つけました! (ここのコードの部分からはよくわかり
|
||||
ませんが, <tt>tp->t_line</tt>はコンソールデバイスの規定
|
||||
する行を参照しているので, もっと小さな整数でなければなりませ
|
||||
ん. )
|
||||
</descrip>
|
||||
|
||||
<sect><heading>突然ダンプした場合の解析</heading>
|
||||
|
||||
<p>カーネルが予想もしない時にコアダンプして <tt>config -g</tt>
|
||||
を行ってコンパイルされていなかった場合にはどうしたらよいでしょう.
|
||||
すべてが失われるわけではありません. パニックを起こさないでください.
|
||||
|
||||
もちろん, クラッシュダンプを使えるようにする必要があります.
|
||||
使い方は前述の部分を見てください.
|
||||
|
||||
カーネルのコンパイルディレクトリで, (Makefileの)
|
||||
<tt>COPTFLAGS?=-O</tt>とある行を編集します. <tt>-g</tt>オプショ
|
||||
ンをここに加えます(オプティマイズオプションのレベルは <em>変更しな
|
||||
いでください</em> ). もし大まかにコードのどこで問題が起きているか (例
|
||||
えば, 上の例では <tt>pcvt</tt>ドライバ) わかっているのでしたら, その部
|
||||
分のコードについてのすべてのオブジェクトファイルを消してください. カーネ
|
||||
ルを再構築しましょう. Makefileのタイムスタンプの変更により, 例えば
|
||||
<tt> trap.o </tt>などのいくつかの他のオブジェクトファイルも作り直さ
|
||||
れます. 少しの幸運があれば, <tt>-g</tt>オプションが追加されても作ら
|
||||
れるコードは変更されず, いくらかのデバッグシンボル以外には問題を
|
||||
起こしたコードとそっくりな新しいカーネルを手に入れることができます.
|
||||
少なくとも <tt>size</tt>コマンドで古い方と新しい方のサイズを比較すべ
|
||||
きです. これが食い違っていれば, 多分あきらめなければならないでしょう.
|
||||
|
||||
ダンプを使って前述のように動かして調べます. デバッグシンボルは
|
||||
必ずしも十分ではありません. 上の例ではスタックトレースでいくつかの関
|
||||
数の行番号や引数リストが表示されないかもしれません. もしより多くのデ
|
||||
バッグシンボルが必要であれば,十分になるまで適切なオブジェクトファイ
|
||||
ルを消して (makeして) <tt>kgdb</tt>セッションを繰り返してください.
|
||||
|
||||
これは必ずしもうまく動くと保証はできません. しかしほとんどの場合でう
|
||||
まくいくでしょう.
|
||||
|
||||
<sect><heading>DDBを使ったオンラインカーネルデバッグ</heading>
|
||||
|
||||
<p> <tt>kgdb</tt> は非常に高レベルのユーザインタフェースを提
|
||||
供するオフラインデバッガですが, いくつかのことはできません.
|
||||
(できないことの中で)極めて重要なことはカーネルコードへのブレークポイ
|
||||
ントの設定とシングルステップ実行です.
|
||||
|
||||
カーネルの低レベルデバッグが必要であれば, DDBと呼ばれる on-lineデバッ
|
||||
ガが使えます. ブレークポイントの設定, シングルステップのカーネルの実
|
||||
行, 変数の検査と変更などができます. ただし,これはカーネルのソースファ
|
||||
イルにアクセスすることはできません. <tt>kgdb</tt>のようにすべてのデ
|
||||
バッグ情報にはアクセスできず, globalと staticのシンボルにアクセス
|
||||
することができるだけです.
|
||||
|
||||
カーネルに DDBを含めるためにはコンフィグファイルに次のようなオプショ
|
||||
ンを加えて,
|
||||
|
||||
<tscreen><verb>
|
||||
options DDB
|
||||
</verb></tscreen>
|
||||
|
||||
再構築をおこないます. ( FreeBSDのカーネルの設定の詳細については<ref
|
||||
id="kernelconfig" name="FreeBSDカーネルのコンフィグレーション">を参照してくださ
|
||||
い. もしブートブロックが古いバージョンですと, デバッガのシンボルが完
|
||||
全にはロードされないかもしれませんので注意してください. DDBシンボル
|
||||
がロードされるようにブートブロックを最新の物にアップデートしてくださ
|
||||
い)
|
||||
|
||||
DDB カーネルの実行において, DDBに入るいくつかの方法があります. 最初
|
||||
の, 最も早い方法はブートプロンプトが出ている時に<tt>-d</tt>のブート
|
||||
フラグをタイプすることです. カーネルはデバッグモードで起動し, デバ
|
||||
イスのプローブ以前に DDBに入ります. したがって, デバイスのプローブ/初期
|
||||
設定ファンクションのデバッグができます.
|
||||
|
||||
2つ目のシナリオはキーボードのホットキーで, 通常は Ctrl-Alt-ESCです.
|
||||
syscons ではホットキーは再設定することができ, 配付されているいくつかの
|
||||
キーマッピングでは別のキーに再設定されていますので確認しておいてください.
|
||||
シリアルラインの BREAKを使って シリアルコンソールから DDBへ入ることを可
|
||||
能にするオプションもあります (カーネルコンフィグレーションファイルの
|
||||
``<tt>options BREAK_TO_DEBUGGER</tt>''). これは 多くのつまらないシリ
|
||||
アルアダプタが, 例えばケーブルを引き抜いた時に BREAK状態を意味もなく
|
||||
作り出してしまうのでデフォルトでは無効になっています.
|
||||
|
||||
3つ目は, DDBを使うようになっているカーネルがパニック状態になると DDB
|
||||
へ入るというものです. このため, 無人運転するマシンのカーネルにDDBを
|
||||
入れるのは賢明ではありません.
|
||||
|
||||
DDBのコマンドはおおまかには <tt>gdb</tt> のいくつかのコマンドと似て
|
||||
います。おそらく最初にブレークポイントを設定する必要があるでしょう。
|
||||
<tscreen><verb>
|
||||
b function-name
|
||||
b address
|
||||
</verb></tscreen>
|
||||
|
||||
数値はデフォルトでは16進数で, シンボル名とはまったく異ります. 16進数で
|
||||
<tt>a</tt>-<tt>f</tt> の文字で始まる場合は, 先頭に
|
||||
<tt>0x</tt>をつける必要があります(それ以外の数字の場合はどちらでもか
|
||||
まいません). <tt>function-name + 0x103</tt>のような単純な式を使うこ
|
||||
とができます.
|
||||
|
||||
割り込みされたカーネルから処理を続行するためには,
|
||||
<tscreen><verb>
|
||||
c
|
||||
</verb></tscreen>
|
||||
とタイプするだけです.
|
||||
スタックのトレースには
|
||||
<tscreen><verb>
|
||||
trace
|
||||
</verb></tscreen>
|
||||
とします.
|
||||
|
||||
DDB にホットキーで入った場合は, カーネルはその (ホットキーの) 割り込み
|
||||
の処理を行っていますのでスタックトレースはあまり役にたたないことに注
|
||||
意してください.
|
||||
|
||||
ブレークポイントを削除したい場合は,
|
||||
<tscreen><verb>
|
||||
del
|
||||
del address-expression
|
||||
</verb></tscreen>
|
||||
とします. 最初の形式はブレークポイントにヒットしたすぐ後で使うことが
|
||||
でき, 現在のブレークポイントを削除します. 2番目の形式では任意のブレー
|
||||
クポイントを削除することができますが, 次の形式で得られるような正確な
|
||||
アドレスを与えることが必要です.
|
||||
<tscreen><verb>
|
||||
show b
|
||||
</verb></tscreen>
|
||||
カーネルをシングルステップ実行させるには
|
||||
<tscreen><verb>
|
||||
s
|
||||
</verb></tscreen>
|
||||
としてみてください. これは関数呼出し先までステップ実行 (step into
|
||||
function) するでしょう. 次のステートメントが終了するまでのDDBトレースは
|
||||
<tscreen><verb>
|
||||
n
|
||||
</verb></tscreen>
|
||||
によっておこなうことができます.
|
||||
|
||||
<bf>Note:</bf> これは <tt>gdb</tt> の `next' 命令とは異ります.
|
||||
<tt>gdb</tt>の `finish'命令と似ています.
|
||||
|
||||
メモリ上のデータを調べるには (例として) 次のようにします.
|
||||
<tscreen><verb>
|
||||
x/wx 0xf0133fe0,40
|
||||
x/hd db_symtab_space
|
||||
x/bc termbuf,10
|
||||
x/s stringbuf
|
||||
</verb></tscreen>
|
||||
word/halfword/byte 単位でアクセスをおこない, hex (16進) /dec (10進) /
|
||||
char (文字) /string (文字列) で表示します. カンマの後ろの数字はオブジェク
|
||||
トカウントです. 次の 0x10個の要素を表示するには, 単純に
|
||||
<tscreen><verb>
|
||||
x ,10
|
||||
</verb></tscreen>
|
||||
とします. 同様に次のように使うことができます.
|
||||
<tscreen><verb>
|
||||
x/ia foofunc,10
|
||||
</verb></tscreen>
|
||||
<tt>foofunc</tt>の最初の 0x10個の命令語をディスアセンブルし,
|
||||
<tt>foofunc</tt>の先頭からのオフセットとともに表示します.
|
||||
|
||||
メモリの内容を変更するには writeコマンドを使います.
|
||||
<tscreen><verb>
|
||||
w/b termbuf 0xa 0xb 0
|
||||
w/w 0xf0010030 0 0
|
||||
</verb></tscreen>
|
||||
コマンドモディファイアの (<tt>b</tt>/<tt>h</tt>/<tt>w</tt>) はデータを
|
||||
書くサイズを定義し, これに続く最初の式は書き込むアドレス, 残りがこれ
|
||||
に続く連続するメモリアドレスに書き込まれるデータになります.
|
||||
|
||||
現在のレジスタ群の内容を知りたい場合は
|
||||
<tscreen><verb>
|
||||
show reg
|
||||
</verb></tscreen>
|
||||
とします. また, 単一のレジスタの値を表示するには, 例えば
|
||||
<tscreen><verb>
|
||||
p $eax
|
||||
</verb></tscreen>
|
||||
とします. また値の変更は
|
||||
<tscreen><verb>
|
||||
set $eax new-value
|
||||
</verb></tscreen>
|
||||
とします.
|
||||
|
||||
DDBからカーネルの関数を呼び出す必要がある場合は, 単に
|
||||
<tscreen><verb>
|
||||
call func(arg1, arg2, ...)
|
||||
</verb></tscreen>
|
||||
とします. return 値が出力されます.
|
||||
|
||||
動いているプロセスの <tt>ps(1)</tt>スタイルの概要は
|
||||
<tscreen><verb>
|
||||
ps
|
||||
</verb></tscreen>
|
||||
です.
|
||||
|
||||
カーネルの失敗の原因の調査が終わったらリブートすべきです. それまでの
|
||||
不具合によりカーネルのすべての部分が期待するような動作をしているわけ
|
||||
ではないということを忘れないでください. 以下のうちいずれかの方法でシ
|
||||
ステムのシャットダウンおよびリブートを行ってください.
|
||||
<tscreen><verb>
|
||||
call diediedie()
|
||||
</verb></tscreen>
|
||||
|
||||
カーネルをコアダンプしてリブートしますので, 後で kgdbによってコアの高
|
||||
レベル解析をすることができます. このコマンドは通常
|
||||
`<tt>continue</tt>'命令にエイリアスされています.
|
||||
`<tt>panic</tt>'にエイリアスされている
|
||||
<tscreen><verb>
|
||||
call boot(0)
|
||||
</verb></tscreen>
|
||||
は動いているシステムを `clean' に shut downするよい方法です. すべて
|
||||
のディスクを <tt>sync()</tt>して最後にリブートします. ディスクとカー
|
||||
ネルのファイルシステムインタフェースが破損していない限り, ほぼ完全
|
||||
に `clean'にシャットダウンするよい方法でしょう.
|
||||
|
||||
<tscreen><verb>
|
||||
call cpu_reset()
|
||||
</verb></tscreen>
|
||||
は大惨事を防ぐための最後の手段で「赤い大きなボタン」を押すのとほとんど
|
||||
同じです.(訳注: リセットボタンを押すのとほぼ同じであるという意味です)
|
||||
|
||||
短いコマンドの要約は
|
||||
<tscreen><verb>
|
||||
help
|
||||
</verb></tscreen>
|
||||
をタイプします. ただし, デバッグセッションのために <tt>ddb(4)</tt> の
|
||||
マニュアルページのプリントアウトを用意しておくことを強くお奨めします.
|
||||
カーネルのシングルステップ中にオンラインマニュアルを読むことは難しい
|
||||
ということを覚えておいてください.
|
||||
|
||||
<sect><heading>リモート GDB を使ったオンラインカーネルデバッグ</heading>
|
||||
|
||||
<p>この機能は FreeBSD 2.2 からサポートされました. これは本当にすばらし
|
||||
い機能です.
|
||||
|
||||
GDB はすでにかなり以前より <em/リモートデバッグ/ をサポートしてい
|
||||
ます. これはシリアル回線を使い非常に単純なプロトコルで行ないます.
|
||||
もちろん, この方法では今までに示した方法とは違い, 2台のマシンが必
|
||||
要になります. 1台はデバッグ環境のためのホストで, すべてのソースとす
|
||||
べてのシンボルを含んだバイナリのコピーを持っています. もう 1台は
|
||||
ターゲットマシンで, 同一のカーネルのコピー (ただしデバッグ情報は
|
||||
取り除いてあるもの) を単に実行するためのものです.
|
||||
|
||||
この場合, カーネルのコンフィグレーションは <tt>config -g</tt> で行な
|
||||
い, <em/DDB/ を含めなくてはなりません. そうして通常通りコンパイルし
|
||||
ます. こうして作ったバイナリファイルはデバッグ情報のために非常に大き
|
||||
くなります. このカーネルをターゲットマシンにコピーして
|
||||
<tt>strip -x</tt> でデバッグシンボルを取り除きます. そして <tt/-d/
|
||||
ブートオプションを使いブートします. ターゲットマシンの 1番目の
|
||||
シリアル回線をデバッグホストのいずれかのシリアル回線につないでおきま
|
||||
しょう. それからデバッグ(訳注:ホスト)マシン上で, ターゲットとなって
|
||||
いるカーネルのコンパイルディレクトリで gdb を起動します:
|
||||
|
||||
<tscreen><verb>
|
||||
% gdb -k kernel
|
||||
GDB is free software and you are welcome to distribute copies of it
|
||||
under certain conditions; type "show copying" to see the conditions.
|
||||
There is absolutely no warranty for GDB; type "show warranty" for details.
|
||||
GDB 4.16 (i386-unknown-freebsd),
|
||||
Copyright 1996 Free Software Foundation, Inc...
|
||||
(kgdb)
|
||||
</verb></tscreen>
|
||||
|
||||
リモートデバッグセッションの初期化 (1番目のシリアルポートを使用する
|
||||
ことの設定) を以下のように行ないます.
|
||||
|
||||
<tscreen><verb>
|
||||
(kgdb) target remote /dev/cuaa0
|
||||
</verb></tscreen>
|
||||
|
||||
次にターゲットマシン (デバイスのプローブ直前で DDB に入っています)
|
||||
で次のように入力します:
|
||||
|
||||
<tscreen><verb>
|
||||
Debugger("Boot flags requested debugger")
|
||||
Stopped at Debugger+0x35: movb $0, edata+0x51bc
|
||||
db> gdb
|
||||
</verb></tscreen>
|
||||
|
||||
DDB は次のような出力を返すでしょう.
|
||||
<tscreen><verb>
|
||||
Next trap will enter GDB remote protocol mode
|
||||
</verb></tscreen>
|
||||
|
||||
``gdb''と入力するたびに リモート GDB とローカル DDB が交互に切り替わ
|
||||
ります. トラップをすぐに起こすために単に ``s'' (step) と入力して下
|
||||
さい. そうするとホストの GDB はターゲットのカーネルの制御を行なうよ
|
||||
うになります.
|
||||
|
||||
<tscreen><verb>
|
||||
Remote debugging using /dev/cuaa0
|
||||
Debugger (msg=0xf01b0383 "Boot flags requested debugger")
|
||||
at ../../i386/i386/db_interface.c:257
|
||||
(kgdb)
|
||||
</verb></tscreen>
|
||||
|
||||
このセッションではソースコードへのフルアクセスや Emacs の window 上
|
||||
の gud-mode (これは別の Emacs window に自動的にソースコードを表示し
|
||||
ます) で動かすなど, 通常の GDB セッションでできることのほとんどのこ
|
||||
とができます.
|
||||
|
||||
<p>リモート GDB は LKM のデバッグも行なうことができます. 最初に LKM を
|
||||
デバッグシンボルを含めた形で作ります.
|
||||
<tscreen><verb>
|
||||
# cd /usr/src/lkm/linux
|
||||
# make clean; make COPTS=-g
|
||||
</verb></tscreen>
|
||||
|
||||
そしてターゲットマシン上でモジュールのこのバージョンをインストールし
|
||||
ます. これをロードしてから, <tt>modstat</tt> を使ってロードされている
|
||||
ことを確認してください:
|
||||
<tscreen><verb>
|
||||
# linux
|
||||
# modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f5109000 001c f510f010 1 linux_mod
|
||||
</verb></tscreen>
|
||||
|
||||
示されたロードアドレスに 0x20 (a.outのヘッダはおそらくこの大きさでしょ
|
||||
う) を加えます. それがモジュールコードの再配置されるアドレスです.
|
||||
GDB の <tt>add-symbol-file</tt> コマンドを使ってデバッガにモジュールの
|
||||
情報をつたえます.
|
||||
<tscreen><verb>
|
||||
(kgdb) add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020
|
||||
add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
|
||||
text_addr = 0xf5109020?
|
||||
(y or n) y
|
||||
(kgdb)
|
||||
</verb></tscreen>
|
||||
|
||||
これで LKM のすべてのシンボルにアクセスできるようになります.
|
||||
|
||||
<sect><heading>コンソールドライバのデバッグ</heading>
|
||||
|
||||
<p>DDBを動かすためにはコンソールドライバが必要ですから, コンソールドラ
|
||||
イバ自身に不具合のある場合は複雑になります. シリアルコンソールを利
|
||||
用する方法 (ブートブロックを変更するか <tt>Boot:</tt>プロンプトで
|
||||
<tt><bf>-h</bf></tt>と入力する) を思い出してください. そして標準ター
|
||||
ミナルを最初のシリアルポートに設定します. DDBは, もちろんシリアルコ
|
||||
ンソールを含むいずれのコンソールドライバの設定でも動作します.
|
||||
@ -1,153 +0,0 @@
|
||||
<!-- $Id: kernelopts.sgml,v 1.9 1997/02/22 13:01:22 peter Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!-- Original revision: 1.7 -->
|
||||
|
||||
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
||||
|
||||
<chapt><heading>カーネルコンフィグレーションの新しいオプションを追加する
|
||||
<label id="kernelopts"></heading>
|
||||
|
||||
<p><em>原作: &a.joerg;</em>
|
||||
|
||||
<p><em>訳: &a.yoshiaki; . <newline> 29 December 1996.</em>
|
||||
|
||||
<em/注:/ この章をお読みになる前に <ref id="kernelconfig"
|
||||
name="FreeBSDカーネルのコンフィグレーション"> の章の内容を
|
||||
理解しておいてください.
|
||||
|
||||
<sect><heading>そもそも<em>カーネル オプション</em>って何?</heading>
|
||||
|
||||
<p>カーネルオプションの使い方は基本的には <ref
|
||||
id="kernelconfig:options" name="FreeBSDカーネルのコンフィグレーション">
|
||||
の章に書いてあります.
|
||||
そこには「伝統的な形式」と「新しい形式」のオプションの説明があります.
|
||||
すべてのカーネルのオプションを新しい形式のものに置き換え, コンフィグファイル
|
||||
を修正して <tt/config(8)/ を実行した後にカーネルのコンパイルディレクトリで
|
||||
<tt/make depend/ を実行すれば, ビルドプロセスが自動的に変更された
|
||||
オプションを検出し, 必要なファイルだけを再コンパイルするようにすることが
|
||||
最終的な目的です. <tt/config(8)/ を実行するたびに古いコンパイルディレクトリ
|
||||
を消してしまう現在のやりかたは, やがておこなわれなくなるでしょう.
|
||||
|
||||
<p>基本的に, カーネルオプションはカーネルのコンパイルプロセスの
|
||||
C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make できる
|
||||
ようにするためには, 対応する部分のカーネルソース (またはカーネルの
|
||||
<tt/.h/ ファイル) がオプションを使えるようにあらかじめ書かれていなければ
|
||||
なりません. つまりデフォルト値をコンフィグファイルのオプションで置き換え
|
||||
られるようになっていなければなりません. これは普通は次のようになっています.
|
||||
|
||||
<verb>
|
||||
#ifndef THIS_OPTION
|
||||
#define THIS_OPTION (some_default_value)
|
||||
#endif /* THIS_OPTION */
|
||||
</verb>
|
||||
<p>この場合, 管理者がコンフィグファイルのオプションに別の値を記述すれば,
|
||||
デフォルトの設定を打ち消して新しい値に置き換えられます. 当然,
|
||||
新しい値はプリプロセッサによってソースコード中で置き換えられるため,
|
||||
デフォルトの値が使われていた場所において C の式として有効な値でなければ
|
||||
なりません.
|
||||
|
||||
<p>また, 単に特定のコードを有効にするか無効にするかを設定するための
|
||||
値を持たないオプションも作ることができます.
|
||||
|
||||
<verb>
|
||||
#ifdef THAT_OPTION
|
||||
|
||||
[あなたのコードが入ります]
|
||||
|
||||
#endif
|
||||
</verb>
|
||||
<p>コンフィグファイルに <tt/THAT_OPTION/ と記述するだけで (値の有無
|
||||
にかかわらず) 対応する部分のコードが組み込まれます.
|
||||
|
||||
<p>C 言語にくわしい人であれば「コンフィグオプション」とされているもの
|
||||
は少なくとも一つの <tt/#ifdef/ で参照されているということはすぐに理解
|
||||
できるでしょう. ところで, ごく一部の人たちは次のようなものを試して
|
||||
みようとするかもしれません.
|
||||
|
||||
<verb>
|
||||
options notyet,notdef
|
||||
</verb>
|
||||
<p>このようにコンフィグファイルをしておくと, カーネルのコンパイルは
|
||||
うまく行きません. :-)
|
||||
|
||||
<p> (訳注: たとえば MATH_EMULATE のように 有効/無効のためのパラメタを
|
||||
持たないオプションの場合, 無効とするためのパラメタをつけて, オプション
|
||||
で「無効とする」と明示することはできないという意味です)
|
||||
|
||||
<p>明らかに, 任意のオプション名がカーネルソースツリー全体でどのように
|
||||
使われているかを追いかけることは非常に難しいことです. このことが
|
||||
<em/新しい形式/ のオプションの機構を採り入れる理由の背景です.
|
||||
ここではそれぞれのオプションはカーネルコンパイルディレクトリにある別々の
|
||||
<tt/.h/ ファイルとなり, <tt>opt_<em>foo</em>.h</tt> という名前に
|
||||
されます. この方法では, 通常の Makefile の依存関係が適用され,
|
||||
<tt/make/ プログラムはオプションが変更された時に再コンパイルが必要な
|
||||
ものを見つけることができます.
|
||||
|
||||
<p>古い形式のオプションの機構は, 局部的なオプションや実験的なオプション
|
||||
のような一時的に利用されると考えられるオプションにおいては有効です.
|
||||
つまり <tt/#ifdef/ をカーネルのソースに追加するのは簡単であり,
|
||||
それがそのままカーネルコンフィグオプションになります.
|
||||
この場合, 管理者はオプションの利用において
|
||||
依存関係を把握しておく責任があります (また, 手動でカーネルの一部分を
|
||||
強制的に再コンパイルする必要があるかもしれません). サポートされている
|
||||
オプションのすべてについて一つでも変更があると, <tt/config(8)/ は
|
||||
サポートされていないオプションがコンフィグファイルの中にあるという警告
|
||||
を出しますが, カーネルの Makefile 内にはそれを含めます.
|
||||
|
||||
<sect><heading>ではどのようにして追加するのでしょう?</heading>
|
||||
|
||||
<p>最初に <tt>sys/conf/options</tt> (または
|
||||
<tt>sys/i386/conf/options.<em><arch></em></tt>, たとえば
|
||||
<tt>sys/i386/conf/options.i386</tt>) を編集し, 新しいオプション
|
||||
を含めるのに最適な <tt>opt_<em>foo</em>.h</tt> ファイルを選びます.
|
||||
|
||||
<p>新しいオプションの必要がなくなったとしたら, これを取り除きます.
|
||||
たとえば, SCSI サブシステムに関するすべてのふるまいについてのオプション
|
||||
の変更は <tt/opt_scsi.h/ に入れられます. デフォルトでは, 適切
|
||||
なオプションファイルに単に記述されます. たとえば <tt/FOO/ であれば
|
||||
値は対応するファイルの <tt/opt_foo.h/ に格納されます. これは右端に別
|
||||
のファイル名を書いて置き換えることができます.
|
||||
|
||||
<p>新しいオプションを加えるのに使えそうな
|
||||
<tt>opt_<em>foo</em>.h</tt> がない場合は新しい名前を作ってください.
|
||||
意味のある名前を作り <tt>options[<em>.<arch></em>]</tt> ファイル
|
||||
に新しいセクションのコメントをつけてください. <tt/config(8)/ は自動的
|
||||
に変更を検出して, 次の実行からは (訳注: 新しい <tt/.h/) ファイル
|
||||
を作ります. ほとんどのオプションはヘッダファイルに入れられます.
|
||||
|
||||
<p>大量のオプションを一つの <tt>opt_<em>foo</em>.h</tt> にまとめると
|
||||
コンフィグファイルの一つのオプションを変更したときに多くのファイルが
|
||||
再コンパイルされる原因になります.
|
||||
|
||||
<p>新しいオプションに依存するカーネルファイルは最終的には見つけ出
|
||||
されます. ただし, オプションを作っただけで対応するソースがどこにも
|
||||
ない場合は別です.
|
||||
|
||||
<verb>
|
||||
find /usr/src/sys -name type f | xargs fgrep NEW_OPTION
|
||||
</verb>
|
||||
<p>オプションに対応するソースを見つけるのに上記のコマンドは便利です.
|
||||
見つけたすべてのファイルで編集, 追加をおこないます.
|
||||
|
||||
<verb>
|
||||
#include "opt_foo.h"
|
||||
</verb>
|
||||
<p><em>ファイルの先頭の</em>, すべての <tt/#include <xxx.h>/
|
||||
より前に入れます. この場合, オプションによって次のようにしてデフォルト値
|
||||
を持たせている標準のヘッダファイル内の値を置き換えるため, 順番は非常に
|
||||
重要です.
|
||||
|
||||
<verb>
|
||||
#ifndef NEW_OPTION
|
||||
#define NEW_OPTION (something)
|
||||
#endif
|
||||
</verb>
|
||||
|
||||
|
||||
<p>システムヘッダファイル (たとえば <tt>/usr/include/sys/</tt> にある
|
||||
ファイル) をオプションで置き換えることは, ほとんどの場合で失敗します.
|
||||
そうすると, ヘッダファイルを深刻な状態に破壊してしまうので, include
|
||||
しないとオプションの値によって不整合が起きてしまう場合を除き, それらの
|
||||
ファイルに <tt>opt_<em>foo</em>.h</tt> を include しないでください.
|
||||
そう, 現在このような例がいくつか存在していますが, 必ずしも正しい方法
|
||||
ではありません.
|
||||
@ -1,714 +0,0 @@
|
||||
<!-- $Id: linuxemu.sgml,v 1.7 1997/02/25 04:56:46 hanai Exp $ -->
|
||||
<!-- The FreeBSD Japanese Documentation Project -->
|
||||
<!-- Original revision: 1.19 -->
|
||||
|
||||
<chapt><heading>Linux エミュレーション<label id="linuxemu"></heading>
|
||||
|
||||
<p><em>原作: &a.handy and &a.rich;</em>
|
||||
<p><em>訳: &a.kiroh;.<newline>24 September 1996.</em>
|
||||
|
||||
<sect><heading>Linux エミュレータのインストール</heading>
|
||||
|
||||
<p>
|
||||
FreeBSD での Linux エミュレーションは, 大部分の Linux バイナリ(a.out
|
||||
および ELF フォーマット)を実行できる状態になっています. 2.1-STABLE ブラン
|
||||
チでのエミュレーションでは, Linux DOOM や Mathematica が実行できます.
|
||||
FreeBSD 2.2-RELEASE でのエミュレーションは, さらに強化されており, Linux 用
|
||||
の Quake, Abuse, IDL, netrek など, 多数のソフトウェアが実行できます.
|
||||
|
||||
Linux オペレーティングシステムには、特有の機能がいくつかあり, FreeBSD
|
||||
でサポートされていないものもあります. Linux の /proc ファイルシステム
|
||||
を使ったバイナリは, FreeBSD では実行できません (FreeBSD で使用可能な
|
||||
/proc ファイルシステムとは仕様が異なっているためです). また仮想8086モー
|
||||
ドを有効にするなど, i386 に特有なシステムコールを使っている場合も実行
|
||||
できません.
|
||||
|
||||
<p>
|
||||
カーネルが Linux エミュレーションを使用するように構築されているかを調
|
||||
べるには, Linux のバイナリを実行してみるのが簡単です.
|
||||
<tscreen>
|
||||
<verb>
|
||||
linux-executable: Exec format error. Wrong Architecture.
|
||||
</verb>
|
||||
</tscreen>
|
||||
このようなエラーメッセージが表示されるようであれば, Linux との互換性は
|
||||
サポートされていません. カーネルを再構築してインストールする必要があり
|
||||
ます.
|
||||
|
||||
Linux エミュレーションの設定方法は, 使用している FreeBSD のバージョン
|
||||
によって多少異なっています.
|
||||
|
||||
<sect1><heading>2.1-STABLE への Linux エミュレーションのインストール</heading>
|
||||
|
||||
<p>2.1-STABLE の GENERIC カーネルは, Linux との互換性を保つように構築
|
||||
されていません. カーネルの再構築が必要です. 再構築をおこなうには, 2つの方
|
||||
法があります. 1つは, エミュレータをカーネル自体にスタティックリンクす
|
||||
る方法. もう1つは, 動的に Linux ローダブルカーネルモジュール(LKM)をロー
|
||||
ドするようにする方法です.
|
||||
|
||||
<p>エミュレータを有効にするには, 以下をコンフィグレーションファイル
|
||||
(/sys/i386/conf/LINT など) に追加します.
|
||||
<tscreen>
|
||||
<verb>
|
||||
options COMPAT_LINUX
|
||||
</verb>
|
||||
</tscreen>
|
||||
Linux DOOM などのアプリケーションを実行したい場合は, 共有メモリも有効
|
||||
にしておかなければなりません. 以下を追加します.
|
||||
<tscreen>
|
||||
<verb>
|
||||
options SYSVSHM
|
||||
</verb>
|
||||
</tscreen>
|
||||
Linux のシステムコールを使用するには, 4.3BSD のシステムコールとの互換
|
||||
性が保たれていることが必要です. 以下の行が含まれていることを確認してく
|
||||
ださい.
|
||||
<tscreen>
|
||||
<verb>
|
||||
options "COMPAT_43"
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
LKM を使用せずエミュレータをカーネルにスタティックにリンクしたい場合は,
|
||||
以下の行を追加します.
|
||||
<tscreen>
|
||||
<verb>
|
||||
options LINUX
|
||||
</verb>
|
||||
</tscreen>
|
||||
<ref id="kernelconfig" name="FreeBSDカーネルのコンフィグレーション">の節の記述に
|
||||
したがって config と, 新しいカーネルのインストールをおこなってください.
|
||||
|
||||
LKM を使用する場合は, ローダブルモジュールをインストールしなければなり
|
||||
ません. カーネルとローダブルモジュールのバージョンが異なると, カーネル
|
||||
がクラッシュする場合がありますので, 安全を期すためには, カーネルをイン
|
||||
ストールするごとに, LKM も再インストールしてください.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/src/lkm/linux
|
||||
% make all install
|
||||
</verb>
|
||||
</tscreen>
|
||||
カーネルと LKM のインストールが終了したら, root で `linux' コマンドを
|
||||
実行することで LKM をロードできます.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% linux
|
||||
Linux emulator installed
|
||||
Module loaded as ID 0
|
||||
%
|
||||
</verb>
|
||||
</tscreen>
|
||||
LKM がロードされたかどうかを確認するには, `modstat' を実行します.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator
|
||||
%
|
||||
</verb>
|
||||
</tscreen>
|
||||
システムブート時に, LKM をロードするようにするには, 2つの方法がありま
|
||||
す. FreeBSD 2.2-RELEASE または 2.1-STABLE では, /etc/sysconfig を,
|
||||
<tscreen>
|
||||
<verb>
|
||||
linux=YES
|
||||
</verb>
|
||||
</tscreen>
|
||||
のように, NO を YES に変更してください. FreeBSD 2.1 RELEASE およびそれ以
|
||||
前のバージョンでは, そのような行はありませんので, /etc/rc.local に以下
|
||||
の行を追加する必要があります.
|
||||
<tscreen>
|
||||
<verb>
|
||||
linux
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<sect1><heading>2.2-RELEASE への Linux エミュレーションのインストール
|
||||
</heading>
|
||||
|
||||
<p>``options LINUX'' や ``options COMPAT_LINUX'' を指定する必要
|
||||
はなくなりました. Linux エミュレーションは LKM(「ローダブルカーネルモジュール」)
|
||||
を使用して, リブートせず簡単にインストールできます. スタートアッ
|
||||
プファイルで以下のように指定します.
|
||||
<enum>
|
||||
<item>/etc/sysconfig に以下の行が必要です.
|
||||
<tscreen>
|
||||
<verb>
|
||||
linux=YES
|
||||
</verb>
|
||||
</tscreen>
|
||||
<item> これは結果的に, /etc/rc.i386 の以下の指定を有効にします.
|
||||
<tscreen>
|
||||
<verb>
|
||||
# Start the Linux binary emulation if requested.
|
||||
if [ "X${linux}" = X"YES" ]; then
|
||||
echo -n ' '; linux
|
||||
# XXX BOGUS - Linux script shouldn't make any output on success
|
||||
fi
|
||||
</verb>
|
||||
</tscreen>
|
||||
</enum>
|
||||
|
||||
<p>実行されたかどうかを確認するには, modstat を使用します.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% modstat
|
||||
Type Id Off Loadaddr Size Info Rev Module Name
|
||||
EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod
|
||||
%
|
||||
</verb>
|
||||
</tscreen>
|
||||
2.2-RELEASE とそれ以降のシステムの中には, modstat の実行がうまくいかない
|
||||
ものがあるという報告もあります. 何らかの理由で, Linux LKM がロードできな
|
||||
い場合は,
|
||||
<tscreen>
|
||||
<verb>
|
||||
options LINUX
|
||||
</verb>
|
||||
</tscreen>
|
||||
をカーネルの設定ファイルに指定して, エミュレータをスタティックにリンク
|
||||
してください. <ref id="kernelconfig" name="FreeBSDカーネルのコンフィグレーション">
|
||||
の節の記述にしたがって config と, 新しいカーネルのインストールをおこ
|
||||
なってください.
|
||||
|
||||
<sect1><heading>Linux ランタイムライブラリのインストール</heading>
|
||||
|
||||
<sect2><heading>linux_lib port を使用してのインストール</heading>
|
||||
|
||||
<p>多くの Linux アプリケーションはシェアードライブラリを使用しますので,
|
||||
シェアードライブラリのインストールが終了しなければ, エミュレータのイン
|
||||
ストールは終わったことになりません. 手動でもインストールできますが,
|
||||
linux_lib port を使用するのが簡単です.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/ports-current/emulators/linux_lib
|
||||
% make all install
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
これで, Linux エミュレータが動作するようになったはずです. 伝説(とメー
|
||||
ルのアーカイブ :-) によれば, Linux エミュレーションは, ZMAGIC ライブラ
|
||||
リとリンクされている Linux バイナリに対して, 最もうまく動作するようで
|
||||
す. Slackware V2.0 などに使われている QMAGIC ライブラリだと, エミュレー
|
||||
タが胸やけするかもしれません. これを書いている時点(1996年5月)で, ELF
|
||||
エミュレーションは依然実験段階ですが, かなりうまく動作しているようです.
|
||||
マイナーバージョンの不一致などを報告するプログラムもありますが, 普通は
|
||||
問題にならないようです.
|
||||
|
||||
<sect2><heading>手動でのライブラリのインストール</heading>
|
||||
|
||||
<p>``ports'' ディストリビューションが手元にない場合は, 手動でライブラ
|
||||
リをインストールする必要があります. プログラムが必要とする Linux のシェ
|
||||
アードライブラリとラインタイムリンカが必要です. また Linux ライブラリ
|
||||
の用の``shadow root'' ディレクトリ, /compat/linux, を作成する必要があ
|
||||
ります. FreeBSD で動作する Linux のプログラムが使用するシェアードライ
|
||||
ブラリは,まずこのファイルツリーから検索されます. 例えば, Linux のプロ
|
||||
グラムが/lib/libc.so をロードしようとした場合には, FreeBSD は, まず
|
||||
/compat/linux/lib/libc.so を開こうとします. 存在にしなかった場合には,
|
||||
次に /lib/libc.so を試します. シェアードライブラリは, Linux の ld.so
|
||||
が参照するライブラリではなく, /compat/linux/lib 以下にインストールする
|
||||
必要があります.
|
||||
|
||||
FreeBSD 2.2-RELEASE 以降では, /compat/linux にかかわる動作が多少異なりま
|
||||
す. -CURRENT では, ライブラリだけでなくすべてのファイルが, ``shadow
|
||||
root'' /compat/linux から検索されます.
|
||||
|
||||
Linux のプログラムが必要とするシェアードライブラリを探す必要があるのは,
|
||||
FreeBSD のシステムに Linux のプログラムをインストールする最初の数回だ
|
||||
けでしょう. それが過ぎれば, 十分な Linux のシェアードライブラリがシス
|
||||
テムにインストールされ, 新しくインストールした Linux のバイナリも, 余
|
||||
計な作業をせずに動作させることができるようになります.
|
||||
|
||||
<sect2><heading>シェアードライブラリの追加</heading>
|
||||
|
||||
<p>
|
||||
linux_port をインストールした後に, アプリケーションが必要なライブラリ
|
||||
が存在しないというエラーを出したらどうしたらよいでしょうか? Linux のバ
|
||||
イナリがどのシェアードライブラリを必要とし, そしてどこで入手できるか,
|
||||
どのように探したらよいでしょうか? 基本的には, 以下の2種類の方法があり
|
||||
ます(以下の手順にしたがう場合には, 必要なインストール作業をおこなう FreeBSD シ
|
||||
ステム上で root として作業をおこなう必要があります).
|
||||
|
||||
<p>Linux システムを使用でき, 必要なシェアードライブラリが調べられる場
|
||||
合には, 単に FreeBSD のシステムにそのライブラリをコピーするだけで
|
||||
す. 例えば, DOOM の Linux バイナリを ftp で持ってきたとします. 使用で
|
||||
きる Linux システムの上に転送して, `ldd linuxxdoom' とやれば, 必要とす
|
||||
るシェアードライブラリがチェックできます.
|
||||
|
||||
<tscreen>
|
||||
<verb>
|
||||
% ldd linuxxdoom
|
||||
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
|
||||
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>
|
||||
最後のカラムに表示されているすべてのファイルを持って来て, /compat/linux の下
|
||||
に置き, 最初のカラムに示されるファイル名からシンボリックリンクを張る必
|
||||
要があります. すなわち, FreeBSD のシステムで, 以下のようなファイルが必
|
||||
要となります.
|
||||
<tscreen>
|
||||
<verb>
|
||||
/compat/linux/usr/X11/lib/libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3.1.0
|
||||
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
|
||||
/compat/linux/lib/libc.so.4.6.29
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>
|
||||
最初のカラムに表示されているファイルと, メジャーバージョンの同じ Linux
|
||||
シェアードライブラリを既にインストールしている場合は, 新たにコピーする
|
||||
必要はありません. 既にあるライブラリで動作するはずです. ただ, 新しいバー
|
||||
ジョンのシェアードライブラリがある場合は, 新しいものをコピーすることを
|
||||
お奨めします. 新しいライブラリにシンボリックリンクを変更したら, 古いラ
|
||||
イブラリは削除してかまいません.
|
||||
<tscreen>
|
||||
<verb>
|
||||
/compat/linux/lib/libc.so.4.6.27
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27
|
||||
</verb>
|
||||
</tscreen>
|
||||
以上のようなライブラリがインストールされており, 新しいバイナリに対する
|
||||
ldd の出力が以下のようになる場合を考えます。
|
||||
<tscreen>
|
||||
<verb>
|
||||
libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
このように最後の番号が1つか2つ古いだけならば, 普通は
|
||||
/lib/libc.so.4.6.29 をコピーする必要はありません. わずかに古いライブラ
|
||||
リでも, プログラムは動作するはずだからです. もちろん, 新しいライブラリ
|
||||
と置き換えて, 以下のようにしても構いません.
|
||||
<tscreen>
|
||||
<verb>
|
||||
/compat/linux/lib/libc.so.4.6.29
|
||||
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>シンボリックリンクのメカニズムは, Linux バイナリに<em>のみ</em>必要
|
||||
なことに注意してください. FreeBSD のランタイムリンカは, メジャーリビジョ
|
||||
ン番号の一致したライブラリを検索しますから, ユーザが気にする必要はあり
|
||||
ません.
|
||||
|
||||
<sect2><heading>ld.so の設定 -- FreeBSD 2.2-RELEASE のみ</heading>
|
||||
|
||||
<p>このセクションは, FreeBSD 2.2-CURRENT 以降にのみ当てはまります.
|
||||
2.1-STABLE を使用している方は, 飛ばしてください.
|
||||
|
||||
<p>
|
||||
最後に, FreeBSD 2.2-RELEASE を使われている場合は, Linux のランタイムリンカと
|
||||
その設定ファイルがシステムに導入されていることを確認してください.
|
||||
これらのファイルは, FreeBSD システムの適切な位置(/compat/linux ツリー以
|
||||
下)にコピーされている必要があります.
|
||||
|
||||
<tscreen>
|
||||
<verb>
|
||||
/compat/linux/lib/ld.so
|
||||
/compat/linux/etc/ld.so.config
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>使用できる Linux システムがない場合は, 必要なファイルは近くの FTP サイ
|
||||
トから入手してください. 各種ファイルの入手先についての情報を, 後に付
|
||||
けておきます. ここでは, 必要なファイルの入手先がわかっているものとしま
|
||||
す.
|
||||
|
||||
<p>
|
||||
以下のファイルを取得します(バージョンの不一致を避けるために, すべて同一
|
||||
の FTP サイトから入手してください). 取得したファイルを /compat/linux
|
||||
以下にインストールしてください(例えば, /foo/bar は,
|
||||
/compat/linux/foo/bar にインストールされます).
|
||||
|
||||
<tscreen>
|
||||
<verb>
|
||||
/sbin/ldconfig
|
||||
/usr/bin/ldd
|
||||
/lib/libc.so.x.y.z
|
||||
/lib/ld.so
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>ldconfig と ldd は, /compat/linux の下にある必要はありません. システム
|
||||
のどこにあっても構いません. ただ, FreeBSD の同名のコマンドと間違えないように
|
||||
注意してください. /usr/local/bin の中に, ldconfig-linux, ldd-linux とし
|
||||
てインストールするのもよいアイディアでしょう.
|
||||
<p>
|
||||
/compat/linux/etc/ld.so.conf ファイルを作成し, Linux ラインタイムリンカ
|
||||
がシェアードライブラリを検索するディレクトリを記述してください. このファ
|
||||
イルはプレインテキストファイルで, それぞれの行にディレクトリ名を含みま
|
||||
す. /lib と /usr/lib は標準ですから, 以下のようなディレクトリが追加できま
|
||||
す.
|
||||
<tscreen>
|
||||
<verb>
|
||||
/usr/X11/lib
|
||||
/usr/local/lib
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>
|
||||
Linux バイナリが, /lib/libc.so というライブラリを開いた場合, エミュレー
|
||||
タは内部で, ファイル名を /compat/linux/lib/libc.so にマップします. エ
|
||||
ミュレータがライブラリを検索するために, すべての Linux のライブラリ
|
||||
(/compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so など)
|
||||
は, /compat/linux 以下にインストールされていなければなりません.
|
||||
|
||||
<p>FreeBSD 2.2-RELEASE を使用している場合は, Linux の ldconfig プログラム
|
||||
を実行する必要があります.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /compat/linux/lib
|
||||
% /compat/linux/sbin/ldconfig
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>
|
||||
ldconfig はスタティックリンクされていますから, 実行するのにシェアードラ
|
||||
イブラリを必要としません. ldconfig は, /compat/linux/etc/ld.so.cache
|
||||
ファイルを作成し, すべてのシェアードライブラリの名前を格納します. ライ
|
||||
ブラリの追加をおこなった場合には, ldconfig を再実行して, このファイルを作り
|
||||
直さなければなりません.
|
||||
|
||||
2.1-STABLE では, /compat/linux/etc/ld.so.cache をインストールしたり,
|
||||
ldconfig を実行したりしないでください. 2.1-STABLE では, システムコー
|
||||
ルの実装方法が異なるため, ldconfig は使用されません.
|
||||
|
||||
<p>
|
||||
これで, libc シェアードライブラリを必要とする Linux バイナリを実行する設
|
||||
定が終了しました. ldd を ldd 自身に実行してテストしてください.
|
||||
ldd-linux としてインストールしている場合は, 以下のような結果になるはず
|
||||
です.
|
||||
|
||||
<tscreen>
|
||||
<verb>
|
||||
% ldd-linux `which ldd-linux`
|
||||
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>ここまで終了すれば, 新しい Linux のバイナリをインストールできます.
|
||||
新しい Linux バイナリをインストールするときは, それがシェアードライブ
|
||||
ラリを必要とするかどうか確認してください. 必要とする場合は,
|
||||
/compat/linux 以下にインストールされているかどうか確認してください. こ
|
||||
れは, Linux の ldd を新しいプログラムに対して実行し, 出力を確認するこ
|
||||
とによりおこなえます. ldd(ldd(1)マニュアルページも参照してください)は, プ
|
||||
ログラムが必要とするシェアードライブラリのリストを, majorname
|
||||
(jumpversion) => fullname という形式で出力します.
|
||||
|
||||
<p>
|
||||
fullname のかわりに ``not found'' と出力される場合は, ライブラリの追加をす
|
||||
る必要があります. 必要なライブラリの名前は, majorname に
|
||||
libXXXX.so.N.mm という形式で示されています. Linux の FTP サイトで
|
||||
libXXXX.so.N.mm を探し, インストールしてください. XXXX(名前)とN(メジャー
|
||||
リビジョン番号)は一致している必要があります. マイナー番号 mm は, それほ
|
||||
ど重要ではありませんが, なるべく最新のものをインストールするようにして
|
||||
ください.
|
||||
|
||||
<sect1><heading>ホストネームリゾルバの設定</heading>
|
||||
|
||||
<p>DNS がうまく動作しなかったり, 以下のようなエラーメッセージが表示され
|
||||
る場合は, /compat/linux/etc/host.conf ファイルを設定する必要があります.
|
||||
<tscreen>
|
||||
<verb>
|
||||
resolv+: "bind" is an invalid keyword
|
||||
resolv+: "hosts" is an invalid keyword
|
||||
</verb>
|
||||
</tscreen>
|
||||
ファイルの内容を以下のように設定してください.
|
||||
<tscreen>
|
||||
<verb>
|
||||
order hosts, bind
|
||||
multi on
|
||||
</verb>
|
||||
</tscreen>
|
||||
ここで, order は /etc/hosts を最初に検索し, 次にDNSを検索するように指定
|
||||
します. /compat/linux/etc/host.conf がインストールされていない場合は,
|
||||
Linux のアプリケーションは, FreeBSD の /etc/host.conf を使用しようとして,
|
||||
文法の違いによる警告を表示します. /etc/resolv.conf を使用してネームサー
|
||||
バを設定していない場合には, `bind' を削除してください.
|
||||
|
||||
<p>最後になりますが, 2.1-STABLE を使用している場合は,
|
||||
RESOLV_HOST_CONF 環境変数を指定して, アプリケーションにホストテーブル
|
||||
の検索方法を指定する必要があります. FreeBSD 2.2-RELEASE を使用している場合
|
||||
は, スキップしてください. /bin/csh を使っている場合は, 以下のようにし
|
||||
ます.
|
||||
<tscreen>
|
||||
<verb>
|
||||
setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
/bin/shの場合は, 以下のようにします.
|
||||
<tscreen>
|
||||
<verb>
|
||||
RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<sect1><heading>必要なファイルを探すには</heading>
|
||||
|
||||
<p>
|
||||
注意: 以下の情報は, この文書が書かれた時点では有効ですが, FTP サイトの
|
||||
名前, ディレクトリ, 配布ファイル名などは, 変更されている可能性がありま
|
||||
す.
|
||||
<p>
|
||||
訳注: ここに取り上げられている FTP サイトは, 日本国内にもミラーサイト
|
||||
が多数存在します。なるべく近くの FTP サイトからファイルを入手してくだ
|
||||
さい.
|
||||
|
||||
<p>
|
||||
Linux は, いくつかのグループが, それぞれ独自のバイナリ配布セットを作成
|
||||
して配布しています. 配布セットは, ``Slackware'' や ``Yggdrasil'' など
|
||||
の名前がつけられています. これらの配布セットは, 多くの FTP サイトから
|
||||
入手できます. ファイルが展開されており, 必要なファイルのみを取得できる
|
||||
場合もありますが, 通常は圧縮された配布セットの形で入手できます. 配布
|
||||
セットは, いくつかのサブディレクトリに, gzip で圧縮された tar ファイル
|
||||
として格納されています. それぞれの配布セットの一次配布先は, 以下の通り
|
||||
です.
|
||||
<verb>
|
||||
sunsite.unc.edu:/pub/Linux/distributions
|
||||
tsx-11.mit.edu:/pub/linux/distributions
|
||||
</verb>
|
||||
|
||||
<p>
|
||||
ヨーロッパのミラーサイトの例:
|
||||
<verb>
|
||||
ftp.luth.se:/pub/linux/distributions
|
||||
ftp.demon.co.uk:/pub/linux/distributions
|
||||
src.doc.ic.ac.uk:/packages/linux/distributions
|
||||
</verb>
|
||||
|
||||
<p>
|
||||
混乱を避けるために, ここでは Slackware だけを取り上げます. この配布セッ
|
||||
トは, 多くのサブディレクトリ内にある別々のパッケージから構成されていま
|
||||
す. 通常, パッケージはインストールプログラムにより自動的に制御されま
|
||||
すが, ``手動で''おこなうことも可能です. まず配布セットの中の,
|
||||
``contents'' サブディレクトリの内容を書くにしてください. ここには多く
|
||||
の小さなテキストファイルが含まれおり, それぞれのパッケージの内容が記述
|
||||
されています. 必要なファイルを探している場合は, まず contents 内のテキ
|
||||
ストファイルを取得し, そのファイルの中から grep を使用して検索するのが,
|
||||
最も速い方法でしょう. 以下に必要となるであろうファイルを, grep を使用
|
||||
して検索した例を示します.
|
||||
<tabular ca=ll>
|
||||
Library <colsep>Package <rowsep>
|
||||
ld.so <colsep>ldso <rowsep>
|
||||
ldconfig <colsep>ldso <rowsep>
|
||||
ldd <colsep>ldso <rowsep>
|
||||
libc.so.4 <colsep>shlibs <rowsep>
|
||||
libX11.so.6.0 <colsep>xf_lib <rowsep>
|
||||
libXt.so.6.0 <colsep>xf_lib <rowsep>
|
||||
libX11.so.3 <colsep>oldlibs <rowsep>
|
||||
libXt.so.3 <colsep>oldlibs <rowsep>
|
||||
</tabular>
|
||||
|
||||
<p>
|
||||
この場合は, ldso, shlibs, xf_lib, oldlibs というパッケージが必要なこと
|
||||
がわかります. それぞれのcontentsファイルの中で, ``PACKAGE LOCATION''
|
||||
と書いてある行を探してください. その行に, パッケージが含まれているディ
|
||||
スク, 今回の場合はサブディレクトリ名が書かれています. たとえば, 以下の
|
||||
ようになります.
|
||||
<tabular ca=ll>
|
||||
Package <colsep>Location <rowsep>
|
||||
ldso <colsep>diska2 <rowsep>
|
||||
shlibs <colsep>diska2 <rowsep>
|
||||
oldlibs <colsep>diskx6 <rowsep>
|
||||
xf_lib <colsep>diskx9 <rowsep>
|
||||
</tabular>
|
||||
|
||||
<p>``diskXX'' というのは, 配布セットの ``slackware/XX'' サブディレクトリ
|
||||
を示します. それ以外の場合は, ``contrib'' サブディレクトリに格納されて
|
||||
います. 今回の場合は, 以下のファイルを取得すればいいことがわかります
|
||||
(ファイル名は, 配布セットのルートディレクトリからの相対パスで示してあ
|
||||
ります).
|
||||
<tscreen>
|
||||
<verb>
|
||||
slakware/a2/ldso.tgz
|
||||
slakware/a2/shlibs.tgz
|
||||
slakware/x6/oldlibs/tgz
|
||||
slakware/x9/xf_lib.tgz
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<p>
|
||||
gzip で圧縮された tar ファイルから必要なファイルを /compat/linux ディ
|
||||
レクトリに格納してください(必要なファイルのみを展開するか, あるいは必
|
||||
要でないファイルを後で削除してください). これで作業は終了です.
|
||||
|
||||
<p><bf>参照:</bf>
|
||||
<verb>
|
||||
ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README
|
||||
|
||||
/usr/src/sys/i386/ibcs2/README.iBCS2
|
||||
</verb>
|
||||
|
||||
<sect><heading>FreeBSD への Mathematica のインストール<label id="mathematica"></heading>
|
||||
|
||||
<p><em>原作: &a.rich and &a.chuck</em>
|
||||
<p><em>訳: &a.kiroh;.</em>
|
||||
|
||||
この文書は, Mathematica 2.2 の Linux バイナリディストリビューションを,
|
||||
FreeBSD 2.1 にインストールする方法について説明します.
|
||||
|
||||
<p>
|
||||
Mathematica は, そのままでは FreeBSD をサポートしていませんが, Linux は
|
||||
サポートしています. ですから, Linux エミュレータの設定が終わってしまえ
|
||||
ば, Mathematica を動作させる環境はほとんど整ったことになります.
|
||||
|
||||
<p>
|
||||
DOS 用のスチューデント版 Mathematica から Linux バージョンへのアップグレー
|
||||
ド価格は, 執筆時点 (1996年5月) では, $45.00 です.
|
||||
直接 Wolfram(電話番号(217) 398-6500)に注文して, 支払いはクレジットカー
|
||||
ドでおこなえます。
|
||||
|
||||
<sect1><heading>Mathematica ディストリビューションの展開</heading>
|
||||
<p>
|
||||
バイナリは, Wolfram から CDROM で配布されています. CDROM には, 1ダー
|
||||
スほどの tar ファイルが含まれており, それぞれサポートされているアーキテ
|
||||
クチャに対応しています. Linux 用のファイルは, LINUX.TAR です. 例えば
|
||||
/usr/local/Mathematica 以下にインストールする場合は, 以下のようにしま
|
||||
す.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/local
|
||||
% mkdir Mathematica
|
||||
% cd Mathematica
|
||||
% tar -xvf /cdrom/LINUX.TAR
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
<sect1><heading>Mathematica パスワードの取得</heading>
|
||||
<p>
|
||||
Mathematica を実行する前に, 使用するマシンに対応した `machine ID' を
|
||||
Wolfram から取得する必要があります.
|
||||
|
||||
<p>
|
||||
Linux 互換ランタイムライブラリがインストールされており, mathematica の展
|
||||
開が終了したら, Install ディレクトリで `mathinfo' プログラムを使用す
|
||||
ることで `machine ID' を得ることができます.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/local/Mathematica/Install
|
||||
% mathinfo
|
||||
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
|
||||
richc.isdn.bcm.tmc.edu 9845-03452-90255
|
||||
%
|
||||
</verb>
|
||||
</tscreen>
|
||||
ここで, `richc' の `machine ID' は, `9845-03452-90255' となります.
|
||||
ioctl のメッセージは無視してください. まだ FreeBSD では実装されていません.
|
||||
Mathematica を実行するたびに同様のメッセージが表示されますが, 実際の使
|
||||
用に問題はありませんので, 無視してかまいません.
|
||||
|
||||
<p>電子メールや電話, ファックスなどで Wolfram に `machine ID' を知らせ
|
||||
て登録すると, いくつかの番号のグループからなるパスワードが送り返されて
|
||||
きます. パスワードを, マシン名, ライセンス番号とともに, mathpass ファ
|
||||
イルに追加します.
|
||||
|
||||
追加は, 以下のようにおこないます.
|
||||
<tscreen>
|
||||
<verb>
|
||||
% cd /usr/local/Mathematica/Install
|
||||
% math.install
|
||||
</verb>
|
||||
</tscreen>
|
||||
ライセンス番号と, Wolfram から送られてきたパスワードを入力を求めます.
|
||||
入力を間違えたりして, math.install の実行が失敗しても大丈夫です.
|
||||
`mathpass' ファイルを手動で編集して, 情報を訂正してください.
|
||||
|
||||
<p>
|
||||
パスワードの入力後, math.install では, インストール方法を, デフォルト
|
||||
設定でのインストールか、自分で方法を指定するインストールから選ぶことが
|
||||
できます. 筆者のようにインストールプログラムを信用していない場合は, 自
|
||||
分でディレクトリを指定する方を選択するでしょう. 自分で指定するインストー
|
||||
ルを選んだ場合, math.install 自身ではディレクトリの作成はおこないません.
|
||||
注意してください. 別のウィンドウでシェルを開いて, 指定するディレクトリ
|
||||
を作成してください. 存在しないディレクトリを指定して, math.install が
|
||||
インストールに失敗した場合には, ディレクトリを作成し, math.install を
|
||||
再び実行してください. 筆者らがインストール先に選んだディレクトリは, 以
|
||||
下の通りです. くれぐれもあらかじめ作成してから, math.install で指定す
|
||||
るようにしてください.
|
||||
<tscreen>
|
||||
<verb>
|
||||
/usr/local/Mathematica/bin バイナリファイル
|
||||
/usr/local/Mathematica/man/man1 マニュアルページ
|
||||
/usr/local/Mathematica/lib/X11 XKeysymbファイル
|
||||
</verb>
|
||||
</tscreen>
|
||||
また, システムレコードファイルとして, /tmp/math.record を使用するように
|
||||
設定することもできます. このファイルには, セッションのログが記録されま
|
||||
す. この設定が終了すると, math.install は残りのファイルを展開して, 必
|
||||
要な場所に格納します.
|
||||
|
||||
<p>
|
||||
Mathematica ノートブックの機能は, X フロントエンドとして本体とは別に含
|
||||
まれています. X フロントエンドを正しくインストールするには,
|
||||
/usr/local/Mathematica/FrontEnd ディレクトリに移動し, ./xfe.install シェ
|
||||
ルスクリプトを実行します. インストール先を指定しなければなりませんが,
|
||||
あらかじめ作成する必要はありません. 必要なディレクトリは, すべて
|
||||
math.install によって作成されているからです. インストールが終了したら,
|
||||
/usr/local/Mathematica/bin ディレクトリに, ``mathematica'' という名前の
|
||||
シェルスクリプトが新たに作成されているはずです.
|
||||
|
||||
<p>最後に, Mathematica がインストールしたシェルスクリプトを修正する必要
|
||||
があります. /usr/local/Mathematica/bin に含まれるすべてのシェルスクリプ
|
||||
トの先頭部分に以下の行を追加します.
|
||||
<tscreen>
|
||||
<verb>
|
||||
XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB
|
||||
</verb>
|
||||
</tscreen>
|
||||
これは, Mathematica が使用する Mathematica バージョンのキーマップファイル
|
||||
XKeysymDB の場所を指定するものです.
|
||||
|
||||
2.1-STABLE を使用している場合は, 以下の行も追加してください.
|
||||
<tscreen>
|
||||
<verb>
|
||||
RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF
|
||||
</verb>
|
||||
</tscreen>
|
||||
これは, Mathematica に Linux バージョンの host.conf を使用するように指定し
|
||||
ます. FreeBSD の host.conf の文法は, Linux のものと異なっているため, この
|
||||
指定をおこなわないと, /etc/host.conf に関わるエラーが発生します.
|
||||
|
||||
<p>
|
||||
新しいマニュアルページを利用したい場合は, さらに /etc/manpath.config ファイ
|
||||
ルを修正する必要があります. また自分の~/.cshrcを変更して,
|
||||
/usr/local/Mathematica/bin をパスに追加してください.
|
||||
|
||||
<p>
|
||||
これでインストール作業はすべて終了です. ``mathematica'' とタイプすれば,
|
||||
見栄えのする Mathematica ノートブックが表示されるはずです. Mathematica
|
||||
には, Motif ユーザインタフェースが含まれますが, スタティックにリンクさ
|
||||
れているため, Motif のライブラリは必要ありあません. 頑張って
|
||||
Mathematica をインストールしてください.
|
||||
|
||||
<sect1><heading>バグ</heading>
|
||||
|
||||
<p>
|
||||
ノートブックフロントエンドは, 以下のようなエラーメッセージを表示して,
|
||||
ハングすることがあることが知られています.
|
||||
<tscreen>
|
||||
<verb>
|
||||
File .../Untitled-1.mb appears to be broken for OMPR.257.0
|
||||
</verb>
|
||||
</tscreen>
|
||||
|
||||
今のところ原因はわかっていませんが, このバグが影響を及ぼすのは, ノートブッ
|
||||
クの X window フロントエンドのみです. Mathematica エンジン本体に影響は
|
||||
ありません. そのため, ``math'' によって起動されるコマンドラインのインタ
|
||||
フェースを使用している場合は, このバグは関係ありません.
|
||||
|
||||
<sect1><heading>謝辞</heading>
|
||||
|
||||
<p>&a.sosと&a.peterに深く感謝します. Linuxエミュレーションが現在の形に
|
||||
あるのは, 彼らのおかげです. そして, 彼ら二人にハッパをかけて, 犬のよう
|
||||
に働かせた Michael Smithに. 今やLinuxエミュレーションは, linuxよりうま
|
||||
くlinuxバイナリを実行できます！ :-)
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user