ISO_* -> ISO* rename
Andrey A. Chernov
23 years ago
parent
e8fc3b162e
commit
f749b200c1
Notes:
svn2git
3 years ago
svn path=/head/; revision=9587
@ -1,8 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
COMPAT_SYMLINK = de
|
||||
|
||||
SUBDIR= books
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,14 +0,0 @@
|
||||
#
|
||||
# The FreeBSD Documentation Project
|
||||
# The FreeBSD German Documentation Project
|
||||
#
|
||||
# $FreeBSD: doc/de_DE.ISO_8859-1/books/Makefile,v 1.1 2000/08/06 14:44:20 alex Exp $
|
||||
# $FreeBSDde: de-docproj/books/Makefile,v 1.4 2001/02/01 21:24:27 alex Exp $
|
||||
#
|
||||
|
||||
SUBDIR= faq handbook
|
||||
|
||||
ROOT_SYMLINKS= handbook
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,11 +0,0 @@
|
||||
#
|
||||
# The FreeBSD Documentation Project
|
||||
# The FreeBSD German Documentation Project
|
||||
#
|
||||
# $FreeBSD: doc/de_DE.ISO_8859-1/books/Makefile.inc,v 1.1 2000/08/25 18:33:40 alex Exp $
|
||||
# $FreeBSDde: de-docproj/books/Makefile.inc,v 1.4 2001/02/01 21:24:27 alex Exp $
|
||||
#
|
||||
|
||||
TIDYFLAGS= -latin1
|
||||
|
||||
DESTDIR?= ${DOCDIR}/de_DE.ISO_8859-1/books/${.CURDIR:T}
|
||||
@ -1,32 +0,0 @@
|
||||
#
|
||||
# The FreeBSD Documentation Project
|
||||
# The FreeBSD German Documentation Project
|
||||
#
|
||||
# Build the FreeBSD FAQ in the German translation
|
||||
#
|
||||
# $FreeBSD: doc/de_DE.ISO_8859-1/books/faq/Makefile,v 1.1 2001/02/01 21:29:56 alex Exp $
|
||||
# $FreeBSDde: de-docproj/books/faq/Makefile,v 1.5 2001/05/20 22:15:47 ue Exp $
|
||||
#
|
||||
|
||||
MAINTAINER=de-bsd-translators@DE.FreeBSD.org
|
||||
|
||||
DOC?= book
|
||||
|
||||
FORMATS?= html-split html
|
||||
|
||||
INSTALL_COMPRESSED?= gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
JADEFLAGS+=-Vbiblio-xref-title
|
||||
|
||||
#
|
||||
# SRCS lists the individual SGML files that make up the document. Changes
|
||||
# to any of these files will force a rebuild
|
||||
#
|
||||
|
||||
# SGML content
|
||||
SRCS= book.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,36 +0,0 @@
|
||||
#
|
||||
# $FreeBSD$
|
||||
# $FreeBSDde: de-docproj/books/handbook/Makefile,v 1.4 2001/03/24 15:53:55 alex Exp $
|
||||
#
|
||||
# Build the FreeBSD Handbook in its German translation.
|
||||
#
|
||||
|
||||
MAINTAINER=alex@FreeBSD.org
|
||||
|
||||
DOC?= book
|
||||
|
||||
FORMATS?= html-split
|
||||
|
||||
INSTALL_COMPRESSED?= gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
#
|
||||
# SRCS lists the individual SGML files that make up the document. Changes
|
||||
# to any of these files will force a rebuild
|
||||
#
|
||||
|
||||
# SGML content
|
||||
SRCS= book.sgml
|
||||
SRCS+= backups/chapter.sgml
|
||||
SRCS+= basics/chapter.sgml
|
||||
SRCS+= bibliography/chapter.sgml
|
||||
SRCS+= ports/chapter.sgml
|
||||
SRCS+= users/chapter.sgml
|
||||
|
||||
# Entities
|
||||
SRCS+= ../../../en_US.ISO_8859-1/books/handbook/authors.ent
|
||||
SRCS+= chapters.ent
|
||||
SRCS+= newsgroups.ent
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1 +0,0 @@
|
||||
<!DOCTYPE appendix PUBLIC "-//FreeBSD//DTD DocBook V3.1-Based Extension//EN">
|
||||
@ -1,848 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
Original version 1.25
|
||||
$FreeBSD: doc/de_DE.ISO_8859-1/books/handbook/backups/chapter.sgml,v 1.1 2000/06/13 09:42:15 alex Exp $
|
||||
-->
|
||||
|
||||
<chapter id="backups">
|
||||
<title>Datensicherung</title>
|
||||
|
||||
<para><emphasis>Übersetzt von &a.de.bwarken,
|
||||
Januar 1999</emphasis></para>
|
||||
|
||||
<para>Das folgende Kapitel beschäftigt sich mit der Datensicherung und
|
||||
den dazu verwendeten Programmen. Wenn Sie etwas zu diesem Kapitel
|
||||
beisteuern möchten, senden Sie es bitte an die (englischsprachige)
|
||||
&a.doc;</para>
|
||||
|
||||
<sect1 id="backups-tapebackups">
|
||||
<title>Bandmedien</title>
|
||||
|
||||
<para>Die wichtigsten Bandmedien sind 4mm, 8mm, QIC,
|
||||
Mini-Cartridge und DLT.</para>
|
||||
|
||||
<sect2 id="backups-tapebackups-4mm">
|
||||
<title>4mm (DDS: Digital Data Storage)</title>
|
||||
|
||||
<para>Die 4mm-Bänder ersetzen mehr und mehr das QIC-Format als
|
||||
Backupmedium der Wahl für Workstations. Dieser Trend nahm stark
|
||||
zu, als Conner die Firma Archive, einen führenden Hersteller von
|
||||
QIC-Laufwerken, aufkaufte und die Produktion von QIC-Laufwerken
|
||||
stoppte. 4mm-Laufwerke sind klein und ruhig, haben aber nicht den
|
||||
gleichen Ruf der Zuverlässigkeit, den die 8mm-Laufwerke
|
||||
genießen. Die 4mm-Kassetten sind preiswerter und mit den
|
||||
Maßen 76,2 x 50,8 x 12,7 mm (3 x 2 x 0,5 Inch) kleiner als die
|
||||
8mm-Kassetten. Sowohl die 4mm- als auch die 8mm-Magnetköpfe
|
||||
haben eine relativ kurze Lebensdauer, weil beide die gleiche
|
||||
Helical-Scan-Technologie benutzen.</para>
|
||||
|
||||
<para>Der Datendurchsatz dieser Laufwerke beginnt bei etwa 150
|
||||
kByte/s, Spitzenwerte liegen bei etwa 500 kByte/s. Die
|
||||
Datenkapazität liegt zwischen 1,3 GB und 2 GB. Die meisten
|
||||
Geräte haben eine Hardwarekompression eingebaut, die die
|
||||
Kapazität ungefähr verdoppelt. Es gibt
|
||||
Multi-Drive-Einheiten für Bandbibliotheken mit bis zu 6
|
||||
Laufwerken in einem Gehäuse und automatischem Bandwechsel. Die
|
||||
Kapazität einer solchen Bibliothek liegt bei 240 GB.</para>
|
||||
|
||||
<para>Der Standard DDS-3 unterstützt nun Bandkapazitäten bis
|
||||
zu 12 GB (oder komprimiert 24 GB).</para>
|
||||
|
||||
<para>4mm-Laufwerke, ebenso wie 8mm-Laufwerke, verwenden Helical-Scan.
|
||||
Alle Vor- und Nachteile von Helical-Scan gelten sowohl für 4mm-
|
||||
als auch für 8mm-Laufwerke.</para>
|
||||
|
||||
<para>Bänder sollten nach 2.000 Banddurchläufen oder 100
|
||||
vollen Backups ersetzt werden.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="backups-tapebackups-8mm">
|
||||
<title>8mm (Exabyte)</title>
|
||||
|
||||
<para>8mm-Bänder sind die verbreitetsten SCSI-Bandlaufwerke; sie
|
||||
sind das geeignetste Bandformat zum Austausch von Bändern. Fast
|
||||
an jedem Standort gibt es ein 8mm-Bandlaufwerk mit 2 GB.
|
||||
8mm-Bänder sind zuverlässig, gut zu handhaben und arbeiten
|
||||
leise. Bandkassetten sind preiswert und klein mit 122 x 84 x 15 mm
|
||||
(4,8 x 3,3 x 0,6 Inch). ein Nachteil der 8mm-Technologie ist die
|
||||
relativ kurze Lebensdauer des Schreib-/Lesekopfs und der Bänder
|
||||
auf Grund der hohen Relativgeschwindigkeit des Bandes über die
|
||||
Köpfe hinweg.</para>
|
||||
|
||||
<para>Der Datendurchsatz liegt ungefähr zwischen 250 kByte/s und
|
||||
500 kByte/s. Die Datenkapazität beginnt bei 300 MB und erreicht
|
||||
bis zu 7 GB bei den Spitzengeräten. Die meisten Geräte
|
||||
haben eine Hardwarekompression eingebaut, die die Kapazität
|
||||
ungefähr verdoppelt. Diese Laufwerke sind erhältlich in
|
||||
Form von Einzelgeräten oder als Multi-Drive-Bandbibliotheken mit
|
||||
6 Laufwerken und 120 Bändern in einem Gehäuse. Die
|
||||
Bänder werden von der Geräteeinheit automatisch gewechselt.
|
||||
Die Kapazität einer solchen Bibliothek liegt bei 840 GB und
|
||||
mehr.</para>
|
||||
|
||||
<para>Das Exabyte-Modell <quote>Mammoth</quote> unterstützt 12 GB
|
||||
auf einem Band (24 MB mit Kompression) und kostet etwa doppelt so viel
|
||||
wie ein konventionelles Bandlaufwerk.</para>
|
||||
|
||||
<para>Die Daten werden mittels Helical-Scan auf das Band
|
||||
aufgezeichnet, die Köpfe sind leicht schräg zum Medium
|
||||
angebracht (mit einem Winkel von etwa 6 Grad). Das Band wickelt sich
|
||||
270 Grad um die Spule, die die Köpfe trägt. Die Spule dreht
|
||||
sich, während das Band darüberläuft. Das Resultat ist
|
||||
eine hohe Datendichte und eng gepackte Spuren, die von einem Rand des
|
||||
Bands zum gegenüberliegenden quer über das Band abgewinkelt
|
||||
verlaufen.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="backups-tapebackups-qic">
|
||||
<title>QIC</title>
|
||||
|
||||
<para>QIC-150-Bänder und -Laufwerke sind wohl der am weitesten
|
||||
verbreitete Bandtyp überhaupt. QIC-Bandlaufwerke sind die
|
||||
preiswertesten "seriösen" Backupgeräte, die angeboten
|
||||
werden. Der Nachteil dabei ist der hohe Preis der Bänder.
|
||||
QIC-Bänder sind im Vergleich zu 8mm- oder 4mm-Bändern bis zu
|
||||
5 Mal teurer, wenn man den Preis auf 1 GB Datenkapazität
|
||||
umrechnet. Aber wenn Ihr Bedarf mit einem halben Dutzend Bänder
|
||||
abgedeckt werden kann, mag QIC die richtige Wahl sein.</para>
|
||||
|
||||
<para>QIC ist der <emphasis>gängigste</emphasis>
|
||||
Bandlaufwerkstyp. Jeder Standort hat ein QIC-Laufwerk der einen oder
|
||||
anderen Dichte. Aber gerade das ist der Haken an der Sache, QIC
|
||||
bietet eine große Anzahl verschiedener Datendichten auf
|
||||
physikalisch ähnlichen (manchmal identischen) Bändern.
|
||||
QIC-Laufwerke sind nicht leise. Diese Laufwerke suchen lautstark die
|
||||
richtige Bandstelle, bevor sie mit der Datenaufzeichnung beginnen.
|
||||
Sie sind während des Lesens, Schreibens und Suchens deutlich
|
||||
hörbar.</para>
|
||||
|
||||
<para>Die Abmessungen der QIC-Kassetten betragen 152.4 x 101.6 x 17.78
|
||||
mm (6 x 4 x 0,7 Inch), die QIC-Bandbreite beträgt 6,35 mm (1/4
|
||||
Inch). <link
|
||||
linkend="backups-tapebackups-mini">Mini-Cartridges</link>, die die
|
||||
gleiche Bandbreite verwenden, werden gesondert vorgestellt.
|
||||
Bandbibliotheken und Bandwechselgeräte gibt es im QIC-Format
|
||||
keine.</para>
|
||||
|
||||
<para>Der Datendurchsatz liegt ungefähr zwischen 150 kByte/s und
|
||||
500 kByte/s. Die Datenkapzität reicht von 40 MB bis zu 15 GB.
|
||||
Hardwarekompression ist in vielen der neueren QIC-Laufwerke eingebaut.
|
||||
QIC-Laufwerke werden heute seltener eingesetzt; sie werden von den
|
||||
DAT-Laufwerken abgelöst.</para>
|
||||
|
||||
<para>Die Daten werden auf dem Band in Spuren aufgezeichnet. Die
|
||||
Spuren verlaufen entlang der Längsachse des Bandmediums von einem
|
||||
Ende zum anderen. Die Anzahl der Spuren, und damit auch die Breite
|
||||
einer Spur, variiert mit der Kapazität des Laufwerks. Die
|
||||
meisten, wenn nicht alle neueren Laufwerke sind
|
||||
rückwärtskompatibel, zumindest zum Lesen (aber oft auch zum
|
||||
Schreiben). QIC hat einen guten Ruf bezüglich der
|
||||
Datensicherheit (die Mechanik ist einfacher und robuster als diejenige
|
||||
der Helical-Scan-Laufwerken).</para>
|
||||
|
||||
<para>Bänder sollten nach 5,000 Backups ersetzt werden.</para>
|
||||
</sect2>
|
||||
|
||||
<![ %not.published; [
|
||||
|
||||
<sect2 id="backups-tapebackups-mini">
|
||||
<title>* Mini-Cartridge</title>
|
||||
|
||||
<para></para>
|
||||
</sect2>
|
||||
|
||||
]]>
|
||||
|
||||
<sect2 id="backups-tapebackups-dlt">
|
||||
<title>DLT</title>
|
||||
|
||||
<para>DLT hat die schnellste Datentransferrate von allen hier
|
||||
aufgelisteten Gerätetypen. Das 1/2-Inch-Band (12,7 mm) befindet
|
||||
sich in einer Spulkassette mit den Abmessungen 101,6 x 101,6 x 25,4 mm
|
||||
(4 x 4 x 1 Inch). Die eine Seite der Kassette hat eine bewegliche
|
||||
Abdeckung. Der Laufwerksmechanismus öffnet diese Abdeckung und
|
||||
zieht die Bandführung heraus. Die Bandführung trägt
|
||||
ein ovales Loch, die das Laufwerk zum "Einhängen" des Bandes
|
||||
benutzt. Die Aufwickelspule befindet sich im Innern des
|
||||
Bandlaufwerks. Bei allen anderen hier besprochenen Bandkassetten
|
||||
(9-Spur-Bänder sind die einzige Ausnahme) befinden sich sowohl
|
||||
die Auf- als auch die Abwickelspule im Inneren der
|
||||
Bandkassette.</para>
|
||||
|
||||
<para>Der Datendurchsatz liegt bei etwa 1,5 MBytes/s, der dreifache
|
||||
Durchsatz der 4mm-, 8mm- oder QIC-Bandlaufwerke. Die
|
||||
Datenkapazität reicht von 10 GB bis 20 GB für
|
||||
Einfachlaufwerke. Auch Mehrfachbandgeräte sind erhältlich,
|
||||
sowohl als Bandwechsler wie auch als Multi-Drive-Bandbibliotheken, die
|
||||
Platz für 5 bis 900 Bänder verteilt auf 1 bis 20 Laufwerke
|
||||
enthalten, mit einer Speicherkapazität von 50 GB bis 9 TB.</para>
|
||||
|
||||
<para>Mit Kompression unterstützt das Format DLT Type IV bis zu
|
||||
70 GB Kapazität.</para>
|
||||
|
||||
<para>Die Daten werden auf dem Band in Spuren aufgezeichnet, die
|
||||
parallel zur Bewegungsrichtung verlaufen (gerade so wie bei den
|
||||
QIC-Bändern). Zwei Spuren werden dabei gleichzeitig beschrieben.
|
||||
Die Lebenszeit der Lese- und Schreibköpfe sind relativ lang; denn
|
||||
sobald das Band anhält, gibt es keine Relativbewegung mehr
|
||||
zwischen den Köpfen und dem Band.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title id="backups-tapebackups-ait">AIT</title>
|
||||
|
||||
<para>AIT ist ein neues Format von Sony, das (mit Kompression) bis zu
|
||||
50 GB pro Band speichern kann. Die Bänder haben einen
|
||||
Speicherchip, der einen Index mit dem Inhalt des Bandes anlegt.
|
||||
Dieser Index kann vom Bandlaufwerk zur schnellen Bestimmung der Lage
|
||||
von Dateien auf dem Band benutzt werden, während andere
|
||||
Bänder einige Minuten zur Lokalisierung benötigen.</para>
|
||||
|
||||
<para>Entsprechende Software wie etwa SAMS:Alexandria
|
||||
können 40 oder mehr AIT-Bandbibliotheken verarbeiten, indem sie
|
||||
direkt mit dem Speicherchip des Bandes kommunizieren, wenn der
|
||||
Bandinhalt am Bildschirm dargestellt werden soll oder bestimmt werden
|
||||
soll, welche Dateien auf welchem Band gespeichert sind, oder um das
|
||||
richtige Band zu lockalisieren, zu laden und Daten vom Band
|
||||
zurückzuspielen. Bibliotheken dieser Art liegen in der
|
||||
Preiskategorie von $20,000, womit sie etwas aus dem Hobbymarkt
|
||||
herausfallen.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Die erste Benutzung eines neuen Bands</title>
|
||||
|
||||
<para>Der Versuch ein neues, vollkommen leeres Band ohne weiteres zu
|
||||
lesen oder zu beschreiben wird schiefgehen. Auf der Konsole werden
|
||||
dann Meldungen ähnlich wie folgt ausgegeben:</para>
|
||||
|
||||
<screen>sa0(ncr1:4:0): NOT READY asc:4,1
|
||||
0(ncr1:4:0): Logical unit is in process of becoming ready</screen>
|
||||
|
||||
<para>Das Band enthält nämlich keinen Identifier-Block
|
||||
(Blocknummer 0). Alle QIC-Bandlaufwerke seit der Einführung des
|
||||
QIC-525-Standards schreiben einen Identifier-Block auf das Band. Es
|
||||
gibt zwei Lösungen:</para>
|
||||
|
||||
<para><command>mt fsf 1</command> veranlasst das Bandlaufwerk einen
|
||||
Identifier-Block auf das Band zu schreiben.</para>
|
||||
|
||||
<para>Das Band durch Drücken des Bandauswurfknopfs an der
|
||||
Vorderseite des Bandgeräts auswerfen.</para>
|
||||
|
||||
<para>Danach das Band wieder einlegen und Daten auf das Band
|
||||
übertragen wie in &man.dump.8; beschrieben.</para>
|
||||
|
||||
<para>Das Kommando &man.dump.8; gibt die Meldung <literal>DUMP: End of
|
||||
tape detected</literal> zurück und die Konsole zeigt:
|
||||
<literal>HARDWARE FAILURE info:280 asc:80,96</literal></para>
|
||||
|
||||
<para>Das Band zurückspulen mit dem Kommando: <command>mt
|
||||
rewind</command></para>
|
||||
|
||||
<para>Nachfolgende Bandoperationen werden dann erfolgreich
|
||||
ausgeführt.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="backup-programs">
|
||||
<title>Backup-Programme</title>
|
||||
|
||||
<para>Die drei wichtigsten Programme sind
|
||||
&man.dump.8;,
|
||||
&man.tar.1;,
|
||||
and
|
||||
&man.cpio.1;.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Aufspielen und Wiederherstellen</title>
|
||||
|
||||
<para>&man.dump.8; und &man.restore.8; sind die traditionellen
|
||||
Backupprogramme in UNIX. Sie betrachten das Laufwerk als eine
|
||||
Ansammlung von Blöcken, operieren also unterhalb dem
|
||||
Abstraktionslevel von Dateien, Links und Verzeichnissen, die die
|
||||
Grundlage des Dateisystemkonzepts bilden.</para>
|
||||
|
||||
<para>&man.dump.8; führt Datensicherungen von Geräten aus,
|
||||
bearbeitet also nur komplette Dateisysteme, nicht jedoch Teile eines
|
||||
Dateisystems und auch keine Verzeichnisbäume, die mehr als ein
|
||||
Dateisystem überspannen, was durch Verwendung von symbolischen
|
||||
Links mittels &man.ln.1; oder durch das Einhängen von
|
||||
Dateisystemen vorkommen kann. &man.dump.8; schreibt also keine
|
||||
Dateien und Verzeichnisse auf das Band, sondern direkt die
|
||||
Datenblöcke, die die Dateien und Verzeichnisse enthalten.</para>
|
||||
|
||||
<para>&man.dump.8; hat einige Eigenarten, die noch aus den frühen
|
||||
Tagen der Version 6 von ATT UNIX (ca. 1975) stammen. Die Parameter
|
||||
sind für 9-Spur-Bänder (6250 bpi) voreingestellt, nicht auf
|
||||
die heute üblichen Medien hoher Dichte (bis zu 62.182 ftpi). Bei
|
||||
der Verwendung der Kapazitäten moderner Bandlaufwerke muss diese
|
||||
Voreinstellung auf der Kommandozeile überschrieben werden.</para>
|
||||
|
||||
<para>&man.rdump.8; und &man.rrestore.8; können Daten über
|
||||
Netzwerk auf ein Band, das sich in einem Laufwerk eines anderen
|
||||
Computers befindet, überspielen. Beide Programme benutzen die
|
||||
Befehle &man.rcmd.3; und &man.ruserok.3; zum Zugriff auf das entfernte
|
||||
Bandlaufwerk. Daher muss der Anwender, der das Backup
|
||||
durchführt, auf dem entfernten Computer eine Zugangsberechtigung
|
||||
für <literal>rhosts</literal> haben.</para>
|
||||
|
||||
<para>Die Argumente zu &man.rdump.8; und &man.rrestore.8; müssen
|
||||
zur Verwendung auf dem entfernten Computer geeignet sein.
|
||||
(Z.B. lautet das Kommando zum Aufrufen von <command>rdump</command>
|
||||
von einem FreeBSD-Computer aus auf ein Exabyte-Bandlaufwerk auf einer
|
||||
Sun namens <hostid>komodo</hostid>: <command>/sbin/rdump 0dsbfu 54000
|
||||
13000 126 komodo:/dev/nrsa8 /dev/rda0a 2>&1</command>). Man
|
||||
beachte, dass bei der Ausführung die Sicherheitsvorkehrungen wie
|
||||
beim Aufruf des Kommandos <literal>rhosts</literal> gelten.
|
||||
Erkundigen Sie sich nach Ihrer Zugangsberechtigung.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tar</title>
|
||||
|
||||
<para>&man.tar.1; stammt ebenfalls aus Version 6 von ATT Unix
|
||||
(ca. 1975). &man.tar.1; arbeitet mit dem Dateisystem, denn es
|
||||
schreibt Dateien und Verzeichnisse auf das Band. &man.tar.1;
|
||||
unterstützt zwar nicht den vollen Umfang von Optionen, die bei
|
||||
&man.cpio.1; zur Verfügung stehen, aber dafür erfordert
|
||||
&man.tar.1; nicht die ungewöhnliche Kommando-Pipeline,1 die
|
||||
&man.cpio.1; verwendet.</para>
|
||||
|
||||
<para>Die meisten Versionen von &man.tar.1; unterstützen keine
|
||||
Backups über das Netzwerk. Die GNU-Version von &man.tar.1;, die
|
||||
in FreeBSD verwendet wird, unterstüzt jedoch entfernte
|
||||
Geräte mit der gleichen Syntax wie &man.rdump.8;. Um &man.tar.1;
|
||||
für ein Exabyte-Bandlaufwerk auf einer Sun
|
||||
namens<hostid>komodo</hostid> auszuführen, muss folgendes
|
||||
Kommando aufgerufen werden: <command>/usr/bin/tar cf komodo:/dev/nrsa8
|
||||
. 2>&1</command>. Bei den Versionen ohne Unterstützung
|
||||
für entfernte Geräte kann man die Daten über eine
|
||||
Pipeline und &man.rsh.1; an ein entferntes Laufwerk senden.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>tar cf - . | rsh <replaceable>hostname</replaceable> dd of=<replaceable>tape-device</replaceable> obs=20b</userinput></screen>
|
||||
|
||||
<para>Wenn Sie Bedenken bezüglich der Sicherheit beim Backup
|
||||
über's Netz haben, sollten Sie &man.ssh.1; anstatt
|
||||
&man.rsh.1; benutzen.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Cpio</title>
|
||||
|
||||
<para>&man.cpio.1; ist das ursprüngliche Unix-Programm zum
|
||||
Dateitransfer mit magnetischen Medien. &man.cpio.1; hat (neben vielen
|
||||
anderen Leistungsmerkmalen) Optionen zum Byte-Swapping, zum Schreiben
|
||||
einer Anzahl verschiedener Archivformate und zum Weiterleiten von
|
||||
Daten an andere Programme über Pipeline. Dieses letztes
|
||||
Leistungsmerkmal macht &man.cpio.1; zu einer ausgezeichneten Wahl
|
||||
für Installationsmedien. Leider kann &man.cpio.1; keine
|
||||
Dateibäume durchlaufen, so dass eine Liste der zu bearbeitenden
|
||||
Dateien über <filename>stdin</filename> angegeben werden
|
||||
muss.</para>
|
||||
|
||||
<para>&man.cpio.1; unterstützt keine Backups über das
|
||||
Netzwerk. Man kann aber eine Pipeline und &man.rsh.1 verwenden, um
|
||||
Daten an ein entferntes Bandlaufwerk zu senden. (XXX ein
|
||||
Beispiel-Kommando beifügen)</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Pax</title>
|
||||
|
||||
<para>&man.pax.1; ist die Antort von IEEE/POSIX auf &man.tar.1; und
|
||||
&man.cpio.1;. Über die Jahre hinweg sind die verschiedenen
|
||||
Versionen von &man.tar.1; und &man.cpio.1; leicht inkompatibel
|
||||
geworden. Daher hat POSIX, statt eine Standardisierung zwischen
|
||||
diesen auszufechten, ein neues Archivprogramm geschaffen. &man.pax.1;
|
||||
versucht viele der unterschiedlichen cpio- und tar-Formate zu lesen
|
||||
und zu schreiben, außerdem einige neue, eigene Formate. Die
|
||||
Kommandostruktur ähnelt eher &man.cpio.1; als &man.tar.1;.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="backups-programs-amanda">
|
||||
<title>Amanda</title>
|
||||
|
||||
<para><ulink url="../ports/misc.html#amanda-2.4.0">Amanda</ulink>
|
||||
(Advanced Maryland Network Disk Archiver) ist ein
|
||||
Client/Server-Backupsystem, nicht nur ein einzelnes Programm. Ein
|
||||
Amanda-Server kann auf einem einzigen Bandlaufwerk Datensicherungen
|
||||
von jeder beliebigen Anzahl von Computern speichern, sofern auf diesen
|
||||
jeweils ein Amanda-Client läuft und sie über Netzwerk mit
|
||||
dem Amanda-Server verbunden sind.</para>
|
||||
|
||||
<para>Ein häufiges Problem bei Standorten mit einer Anzahl
|
||||
großer Festplatten ist, dass das Kopieren der Daten auf Band
|
||||
langsamer vor sich geht als solche Daten anfallen. Amanda löst
|
||||
dieses Problem durch Verwendung einer "Holding Disk", einer Festplatte
|
||||
zum gleichzeitigen Zwischenspeichern mehrerer Dateisysteme.</para>
|
||||
|
||||
<para>Für Datensicherungen über einen längeren Zeitraum
|
||||
erzeugt Amanda "Archivsets" von allen Dateisystemen, die in Amanda's
|
||||
Konfigurationsdatei genannt werden. Ein Archivset ist eine Gruppe von
|
||||
Bändern mit vollen Backups und Reihen von inkrementellen (oder
|
||||
differentiellen) Backups, die jeweils nur die Unterschiede zum vorigen
|
||||
Backup enthalten. Zur Wiederherstellung von beschädigten
|
||||
Dateissystemen benötigt man das letzte volle Backup und alle
|
||||
darauf folgenden inkrementellen Backups.</para>
|
||||
|
||||
<para>Ein gängiger Datensicherungsplan ist, an den Wochenenden
|
||||
ein volles Backup und während der Woche jede Nacht ein
|
||||
inkrementelles Backup zu erstellen.</para>
|
||||
|
||||
<para>Die Konfigurationsdatei ermöglicht die Feineinstellung der
|
||||
Backups und des Netzwerkverkehrs von Amanda. Amanda kann zum
|
||||
Schreiben der Daten auf das Band jedes der oben beschriebenen
|
||||
Backuprogramme verwenden. Amanda ist erhältlich als Portierung
|
||||
oder als Softwarepaket, es ist nicht von vorne herein auf dem System
|
||||
installiert.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tue nichts</title>
|
||||
|
||||
<para><quote>Tue nichts</quote> ist kein Computerprogramm, sondern die
|
||||
am häufigsten angewendete Backupstrategie. Diese kostet nichts,
|
||||
man muss keinen Backupplan befolgen, einfach nur nein sagen. Wenn
|
||||
etwas passiert, einfach grinsen und ertragen!</para>
|
||||
|
||||
<para>Wenn Ihre Zeit und Ihre Daten nicht so wichtig sind, dann ist
|
||||
die Strategie <quote>Tue nichts</quote> das geeignetste Backupprogramm
|
||||
für Ihren Computer. Aber UNIX ein nützliches Werkzeug. Sie
|
||||
müssen damit rechnen, dass Sie innerhalb von sechs Monaten eine
|
||||
Sammlung von Dateien haben, die für Sie wertvoll geworden
|
||||
sind.</para>
|
||||
|
||||
<para><quote>Tue nichts</quote> ist die richtige Backupmethode für
|
||||
<filename>/usr/obj</filename> und andere Verzeichnisbäume, die
|
||||
vom Computer exakt wiedererzeugt werden können. Ein Beispiel
|
||||
sind die Dateien, die diese Handbuchseiten darstellen — sie
|
||||
wurden aus Quelldateien im Format <acronym>SGML</acronym> erzeugt. Es
|
||||
ist nicht nötig, Sicherheitskopien der Dateien in den
|
||||
sekundären Formaten wie etwa <acronym>HTML</acronym> zu
|
||||
erstellen. Die Quelldateien in <acronym>SGML</acronym> sollten jedoch
|
||||
in die regelmäßigen Backups mit einbezogen werden.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Welches Backup-Programm ist am Besten?</title>
|
||||
|
||||
<para>&man.dump.8;, <emphasis>Punkt und Schluss.</emphasis> Elizabeth
|
||||
D. Zwicky hat alle hier genannten Backup-Programme bis zur
|
||||
Erschöpfung ausgetestet. Ihre eindeutige Wahl zur Sicherung
|
||||
aller Daten mit Berücksichtigung aller Besonderheiten von
|
||||
UNIX-Dateisystemen ist &man.dump.8;.</para>
|
||||
|
||||
<para>Elizabeth erzeugte Dateisysteme mit einer großen Vielfalt
|
||||
ungewöhnlicher Bedingungen (und einiger gar nicht so
|
||||
ungewöhnlicher) und testete jedes Programm durch ein Backup und
|
||||
eine Wiederherstellung dieser Dateisysteme. Unter den Besonderheiten
|
||||
waren Dateien mit Löchern, Dateien mit Löchern und einem
|
||||
Block mit Null-Zeichen, Dateien mit ausgefallenen Buchstaben im
|
||||
Dateinamen, unlesbare und nichtschreibbare Dateien,
|
||||
Gerätedateien, Dateien, deren Länge sich während des
|
||||
Backups ändert, Dateien, die während des Backups erzeugt und
|
||||
gelöscht werden, u.v.m. Sie berichtete über ihre Ergebnisse
|
||||
in LISA V im Oktober 1991, s. <ulink
|
||||
url="http://reality.sgi.com/zwicky_neu/testdump.doc.html">Torture-testing
|
||||
Backup and Archive Programs</ulink>.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Die Wiederherstellung in einem Notfall</title>
|
||||
|
||||
<sect3>
|
||||
<title>Vor dem Unglück</title>
|
||||
|
||||
<para>Es sind nur vier Vorkehrungen zu treffen, um auf jedes
|
||||
erdenkliche Unglück vorbereitet zu sein.</para>
|
||||
|
||||
<para>Als erstes drucken Sie das Disklabel jeder Ihrer Festplatten
|
||||
(z.B. mittels <command>disklabel da0 | lpr</command>), die
|
||||
Partitions- und Dateisystemtabelle jeder Festplatte (mit
|
||||
<filename>/etc/fstab</filename>) sowie alle Bootmeldungen, jeweils
|
||||
in zweifacher Ausfertigung.</para>
|
||||
|
||||
<para>Zweitens, überzeugen Sie sich, dass sowohl die
|
||||
Bootdiskette als auch die Reparaturdiskette
|
||||
(<filename>boot.flp</filename> bzw. <filename>fixit.flp</filename>)
|
||||
all Ihre Geräte ansprechen können. Die einfachste Methode
|
||||
dies nach zu prüfen ist, Ihren Rechner mit der Boot-Diskette im
|
||||
Floppylaufwerk neu zu starten und die Bootmeldungen zu durchzusehen.
|
||||
Wenn all Ihre Geräte aufgelistet sind und funktionieren,
|
||||
können Sie weiter zu Schritt drei gehen.</para>
|
||||
|
||||
<para>Ist das nicht der Fall, müssen Sie sich eine eigene
|
||||
Version der beiden zum Booten benötigten Disketten erstellen.
|
||||
Diese müssen einen Kernel enthalten, der all Ihre Platten
|
||||
mounten kann und Zugriff auf Ihr Bandlaufwerk gestattet. Diese
|
||||
Disketten müssen ferner folgende Programme enthalten:
|
||||
&man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8; sowie
|
||||
jedes Backup-Programm, das Sie verwenden. Diese Programme
|
||||
müssen statisch gelinkt sein. Falls Sie &man.dump.8;
|
||||
verwenden, muss die Diskette auch &man.restore.8; enthalten.</para>
|
||||
|
||||
<para>Drittens, machen Sie oft Backups auf Band. Jede Änderung
|
||||
seit Ihrem letzten Backup kann unwiederbringlich verloren gehen.
|
||||
Versehen Sie die Backup-Bänder mit Schreibschutz.</para>
|
||||
|
||||
<para>Viertens, testen Sie aus, wie die Disketten (entweder
|
||||
<filename>boot.flp</filename> und <filename>fixit.flp</filename>
|
||||
oder Ihre beiden eigenen Disketten aus Schritt zwei) und die
|
||||
Bänder mit den Backups zu behandeln sind. Machen Sie sich
|
||||
Notizen zu diesem Test. Bewahren Sie diese Notizen zusammen mit den
|
||||
Bootdisketten, den Ausdrucken und den Bändern mit den Backups
|
||||
auf. Wenn der Ernstfall eintritt, werden Sie vielleicht so genervt
|
||||
sein, dass Sie ohne Ihre Notizen evt. das Backup auf Ihren
|
||||
Bändern zerstören. (Wie das geht? Man braucht nur
|
||||
unglücklicherweise den Befehl <command>tar cvf
|
||||
/dev/rsa0</command> einzugeben um ein Band zu
|
||||
überschreiben).</para>
|
||||
|
||||
<para>Als zusätzliche Sicherheitsvorkehrung, kann man jeweils
|
||||
die Disketten und Bänder zweifach erstellen. Eine der Kopien
|
||||
sollte an einem entfernten Standort aufbewahrt werden. Ein
|
||||
entfernter Standort ist NICHT der Keller im gleichen
|
||||
Bürogebäude. Eine Anzahl von Firmen im World Trade Center
|
||||
musste diese Lektion auf die harte Tour lernen. Ein entfernter
|
||||
Standort sollte von Ihrem Computer und Ihren Festplatten
|
||||
physikalisch durch eine erhebliche Entfernung getrennt sein.</para>
|
||||
|
||||
<para>Ein Beispielskript zum Erstellen eigener Bootdisketten:</para>
|
||||
|
||||
<programlisting>
|
||||
<![ CDATA [#!/bin/sh
|
||||
#
|
||||
# Erstellen einer Diskette zur Wiederherstellung eines Backups
|
||||
#
|
||||
# Diskette formatieren
|
||||
#
|
||||
PATH=/bin:/sbin:/usr/sbin:/usr/bin
|
||||
|
||||
fdformat -q fd0
|
||||
if [ $? -ne 0 ]
|
||||
then
|
||||
echo "Bad floppy, please use a new one"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Die Bootbloecke auf die Diskette schreiben
|
||||
#
|
||||
disklabel -w -B /dev/rfd0c fd1440
|
||||
|
||||
#
|
||||
# Dateisystem fuer die (einzige) Partition auf der Diskette
|
||||
#
|
||||
newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/rfd0a
|
||||
|
||||
#
|
||||
# Diskette mounten
|
||||
#
|
||||
mount /dev/fd0a /mnt
|
||||
|
||||
#
|
||||
# Benoetigte Verzeichnisse erstellen
|
||||
#
|
||||
mkdir /mnt/dev
|
||||
mkdir /mnt/bin
|
||||
mkdir /mnt/sbin
|
||||
mkdir /mnt/etc
|
||||
mkdir /mnt/root
|
||||
mkdir /mnt/mnt # fuer die Root-Partition
|
||||
mkdir /mnt/tmp
|
||||
mkdir /mnt/var
|
||||
|
||||
#
|
||||
# die Verzeichnisse bevoelkern
|
||||
#
|
||||
if [ ! -x /sys/compile/MINI/kernel ]
|
||||
then
|
||||
cat << EOM
|
||||
Der MINI_Kernel existiert nicht, bitte einen erzeugen.
|
||||
Hier ein Beispiel einer Konfigurationsdatei:
|
||||
#
|
||||
# MINI -- Ein FreeBSD-Kernel, der auf die Diskette passt.
|
||||
#
|
||||
machine "i386"
|
||||
cpu "I486_CPU"
|
||||
ident MINI
|
||||
maxusers 5
|
||||
|
||||
options INET # notwendig fuer _tcp _icmpstat _ipstat
|
||||
# _udpstat _tcpstat _udb
|
||||
options FFS #Berkeley Fast File System
|
||||
options FAT_CURSOR #Blockcursor in syscons oder pccons
|
||||
options SCSI_DELAY=15 #traue nicht Joe's SCSI-Geraet
|
||||
options NCONS=2 #2 virtuelle Konsolen
|
||||
options USERCONFIG #Konfiguration mit -c XXX zulassen
|
||||
|
||||
|
||||
config kernel root on da0 swap on da0 and da1 dumps on da0
|
||||
|
||||
controller isa0
|
||||
controller pci0
|
||||
|
||||
controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
|
||||
disk fd0 at fdc0 drive 0
|
||||
|
||||
controller ncr0
|
||||
|
||||
controller scbus0
|
||||
|
||||
device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr
|
||||
device npx0 at isa? port "IO_NPX" irq 13 vector npxintr
|
||||
|
||||
device da0
|
||||
device da1
|
||||
device da2
|
||||
|
||||
device sa0
|
||||
|
||||
pseudo-device loop # von INET benoetigt
|
||||
pseudo-device gzip # komprimierte a.out-Dateien ausfuehren
|
||||
EOM
|
||||
exit 1
|
||||
fi
|
||||
|
||||
cp -f /sys/compile/MINI/kernel /mnt
|
||||
|
||||
gzip -c -best /sbin/init > /mnt/sbin/init
|
||||
gzip -c -best /sbin/fsck > /mnt/sbin/fsck
|
||||
gzip -c -best /sbin/mount > /mnt/sbin/mount
|
||||
gzip -c -best /sbin/halt > /mnt/sbin/halt
|
||||
gzip -c -best /sbin/restore > /mnt/sbin/restore
|
||||
|
||||
gzip -c -best /bin/sh > /mnt/bin/sh
|
||||
gzip -c -best /bin/sync > /mnt/bin/sync
|
||||
|
||||
cp /root/.profile /mnt/root
|
||||
|
||||
cp -f /dev/MAKEDEV /mnt/dev
|
||||
chmod 755 /mnt/dev/MAKEDEV
|
||||
|
||||
chmod 500 /mnt/sbin/init
|
||||
chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt
|
||||
chmod 555 /mnt/bin/sh /mnt/bin/sync
|
||||
chmod 6555 /mnt/sbin/restore
|
||||
|
||||
#
|
||||
# Geraetedateien erstellen
|
||||
#
|
||||
cd /mnt/dev
|
||||
./MAKEDEV std
|
||||
./MAKEDEV da0
|
||||
./MAKEDEV da1
|
||||
./MAKEDEV da2
|
||||
./MAKEDEV sa0
|
||||
./MAKEDEV pty0
|
||||
cd /
|
||||
|
||||
#
|
||||
# Minimale Dateisystemtabelle erstellen
|
||||
#
|
||||
cat > /mnt/etc/fstab <<EOM
|
||||
/dev/fd0a / ufs rw 1 1
|
||||
EOM
|
||||
|
||||
#
|
||||
# Minimale Passwortdatei erstellen
|
||||
#
|
||||
cat > /mnt/etc/passwd <<EOM
|
||||
root:*:0:0:Charlie &:/root:/bin/sh
|
||||
EOM
|
||||
|
||||
cat > /mnt/etc/master.passwd <<EOM
|
||||
root::0:0::0:0:Charlie &:/root:/bin/sh
|
||||
EOM
|
||||
|
||||
chmod 600 /mnt/etc/master.passwd
|
||||
chmod 644 /mnt/etc/passwd
|
||||
/usr/sbin/pwd_mkdb -d/mnt/etc /mnt/etc/master.passwd
|
||||
|
||||
#
|
||||
# Die Diskette aushaengen und den Benutzer informieren
|
||||
#
|
||||
/sbin/umount /mnt
|
||||
echo "Die Diskette wurde ausgehaengt und ist jetzt bereit."]]></programlisting>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Nach dem Unglück</title>
|
||||
|
||||
<para>Die Schlüsselfrage ist, ob Ihre Hardware überlebt
|
||||
hat. Denn da Sie ja regelmäßig Backups angefertigt
|
||||
haben, brauchen Sie sich um die Software keine Sorgen zu
|
||||
machen.</para>
|
||||
|
||||
<para>Falls die Hardware beschädigt wurde, ersetzen Sie zuerst
|
||||
die defekten Teile.</para>
|
||||
|
||||
<para>Falls die Hardware funktioniert, überprüfen Sie die
|
||||
Disketten. Wenn Sie eigene Bootdisketten verwenden, booten Sie im
|
||||
Single-User-Modus (geben dazu Sie <literal>-s</literal> am
|
||||
Boot-Prompt <prompt>boot:</prompt> ein). Überspringen Sie den
|
||||
folgenden Paragrafen.</para>
|
||||
|
||||
<para>Wenn Sie die Standarddisketten <filename>boot.flp</filename>
|
||||
und <filename>fixit.flp</filename> verwenden, lesen Sie hier weiter.
|
||||
Legen Sie die Bootdiskette <filename>boot.flp</filename> in das
|
||||
erste Floppylaufwerk ein und starten Sie den Computer. Wie
|
||||
üblich wird dann das originale Installationsmenü von
|
||||
FreeBSD gestartet. Wählen Sie die Option
|
||||
<literal>Fixit--Repair mode with CDROM or floppy.</literal>. Legen
|
||||
Sie die Diskette <filename>fixit.flp</filename> ein, wenn danach
|
||||
gefragt wird. <command>restore</command> und die anderen Programme,
|
||||
die Sie benötigen, befinden sich dann in
|
||||
<filename>/mnt2/stand</filename>.</para>
|
||||
|
||||
<para>Stellen Sie die Dateisysteme nacheinander, getrennt von
|
||||
einander, wieder her.</para>
|
||||
|
||||
<para>Versuchen Sie die Root-Partition Ihrer ersten Festplatte
|
||||
&man.mount.8; einzuhängen (z.B. mit <command>mount /dev/sd0a
|
||||
/mnt</command>). Wenn das Disklabel beschädigt wurde, benutzen
|
||||
Sie &man.disklabel.8; um die Platte neu zu partitionieren und zu
|
||||
benennen und zwar so, dass die Festplatte mit dem Label
|
||||
übereinstimmt, das Sie ausgedruckt und aufbewahrt haben.</para>
|
||||
|
||||
<para>Verwenden Sie &man.newfs.8; um neue Dateisysteme auf den
|
||||
Partitionen anzulegen. Hängen Sie nun die Root-Partition der
|
||||
Festplatte mit Schreibzugriff ein (mit <command>mount -u -o rw
|
||||
/mnt</command>). Benutzen Sie Ihr Backup-Programm um die Daten
|
||||
für das jeweilige Dateisystem aus den Backup-Bändern
|
||||
wieder her zu stellen (z.B. durch <command>restore vrf
|
||||
/dev/sta</command>). Hängen Sie das Dateisystem wieder aus
|
||||
(z.B. durch <command>umount /mnt</command>). Wiederholen Sie diesen
|
||||
Ablauf für jedes betroffene Dateisystem.</para>
|
||||
|
||||
<para>Sobald Ihr System wieder läuft, machen Sie gleich wieder
|
||||
ein vollständiges Backup auf neue Bänder. Denn die
|
||||
Ursache für den Absturz oder den Datenverlust kann wieder
|
||||
zuschlagen. Eine weitere Stunde, die Sie jetzt noch
|
||||
dranhängen, kann Ihnen später ein weiteres Missgeschick
|
||||
ersparen.</para>
|
||||
</sect3>
|
||||
|
||||
<![ %not.published; [
|
||||
|
||||
<sect3>
|
||||
<title>* Ich habe mich nicht auf Missgeschicke vorbereitet - was
|
||||
nun?</title>
|
||||
|
||||
<para></para>
|
||||
</sect3>
|
||||
|
||||
]]>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="backups-floppybackups">
|
||||
<title>Was ist mit Backups auf Disketten?</title>
|
||||
|
||||
<sect2 id="floppies-using">
|
||||
<title>Kann ich Disketten zum Backup meiner Daten verwenden?</title>
|
||||
|
||||
<para>Disketten sind kein wirklich geeignetes Medium für Backups
|
||||
aus folgenden Gründen:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Disketten sind unzuverlässig, besonders
|
||||
langfristig.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Speichern und Wiederherstellen ist sehr langsam.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Sie haben eine sehr eingeschränkte Kapazität (Die
|
||||
Zeiten sind längst vorbei, wo eine ganze Festplatte auf ein
|
||||
Dutzend Floppies oder so gespeichert werden konnte).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Wenn jedoch keine andere Möglichkeit zum Datenbackup
|
||||
vorhanden ist, dann sind Disketten immer noch besser als gar kein
|
||||
Backup.</para>
|
||||
|
||||
<para>Wenn man gezwungen ist Disketten zu verwenden, dann sollte man
|
||||
auf eine gute Qualität achten. Floppies, die schon einige Jahre
|
||||
im Büro herumgelegen haben, sind eine schlechte Wahl. Ideal sind
|
||||
neue Disketten von einem renommierten Hersteller.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="floppies-creating">
|
||||
<title>Wie mache ich ein Backup auf Disketten?</title>
|
||||
|
||||
<para>Die beste Art eines Diskettenbackups ist der Befehl &man.tar.1;
|
||||
mit der Mehrfachband-Option <option>-M</option>, die es
|
||||
ermöglicht ein Backup über mehrere Floppies zu
|
||||
verteilen.</para>
|
||||
|
||||
<para>Ein Backup aller Dateien im aktuellen Verzeichnis
|
||||
einschließlich aller Unterverzeichnisse wird durch den folgenden
|
||||
Befehl veranlasst (als root):</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>tar Mcvf /dev/rfd0 *</userinput></screen>
|
||||
|
||||
<para>Wenn die erste Floppy voll ist, meldet sich &man.tar.1; und
|
||||
verlangt einen Diskettenwechsel (weil &man.tar.1; unabhängig vom
|
||||
Medium arbeitet, wird der nächste Band (Volume) verlangt, was in
|
||||
diesem Zusammenhang eine Diskette bedeutet), in etwa wie folgt:</para>
|
||||
|
||||
<screen>Prepare volume #2 for /dev/rfd0 and hit return:</screen>
|
||||
|
||||
<para>Dies wird mit steigender Volumezahl wiederholt, bis alle
|
||||
angebenen Dateien archiviert sind.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="floppies-compress">
|
||||
<title>Können Diskettenbackups komprimiert werden?</title>
|
||||
|
||||
<para>Leider erlaubt es &man.tar.1; nicht, die Option
|
||||
<option>-z</option> für Multi-Volume-Archive zu verwenden. Man
|
||||
kann natürlich alle Dateien mit &man.gzip.1; komprimieren, sie
|
||||
mit &man.tar.1; auf die Floppies aufspielen, und dann die Dateien
|
||||
wieder &man.gunzip.1; entkomprimieren!</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="floppies-restoring">
|
||||
<title>Wie werden Diskettenbackups wieder her gestellt?</title>
|
||||
|
||||
<para>Zur Wiederherstellung des gesamten Archivs verwendet man:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>tar Mxvf /dev/rfd0</userinput></screen>
|
||||
|
||||
<para>Eine Methode um nur bestimmte Dateien wieder her zu stellen ist
|
||||
mit der ersten Diskette den folgenden Befehl auszuführen:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>tar Mxvf /dev/rfd0 <replaceable>filename</replaceable></userinput></screen>
|
||||
|
||||
<para>&man.tar.1; wird dann dir folgenden Disketten anfordern, bis die
|
||||
benötigte Datei gefunden ist.</para>
|
||||
|
||||
<para>Wenn man die Diskette kennt auf der sich die Datei befindet,
|
||||
kann man alternativ diese Diskette auch direkt einlegen und den
|
||||
gleichen Befehl wie oben verwenden. Man beachte, dass, falls die
|
||||
erste Datei eine Fortsetzung eine Fortsetzung einer Datei von einer
|
||||
der vorigen Disketten ist, &man.tar.1; die Warnung ausgibt, dass diese
|
||||
Datei nicht wiederhergestellt werden kann, selbst dann, wenn dies gar
|
||||
nicht verlangt wurde!</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
@ -1,485 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
Original version 1.26
|
||||
$FreeBSD: doc/de_DE.ISO_8859-1/books/handbook/bibliography/chapter.sgml,v 1.1 2000/06/29 10:08:28 alex Exp $
|
||||
-->
|
||||
|
||||
<appendix id="bibliography">
|
||||
<title>Bibliografie</title>
|
||||
|
||||
<para><emphasis>Übersetzt von &a.de.gruender</emphasis></para>
|
||||
|
||||
<para>Während die Manual-Seiten die endgültige Auskunft
|
||||
über bestimmte Teile des FreeBSD Betriebssystems geben, so
|
||||
können sie jedoch nicht darstellen, wie man die einzelnen Teile
|
||||
zusammenfügt, um ein vollständig laufendes Betriebssystem
|
||||
herzustellen. Daher gibt es keinen Ersatz für ein gutes Buch
|
||||
für UNIX System-Administration und ein gutes
|
||||
Benutzerhandbuch.</para>
|
||||
|
||||
<sect1 id="bibliography-freebsd">
|
||||
<title>Bücher & Magazine speziell für FreeBSD</title>
|
||||
|
||||
<para><emphasis>Internationale Bücher &
|
||||
Magazine:</emphasis></para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://jdli.tw.freebsd.org/publication/book/freebsd2/index.htm">Using FreeBSD</ulink> (auf chinesisch).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD for PC 98'ers (auf japanisch), herausgegeben von
|
||||
SHUWA System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD (auf japanisch), herausgegeben von CUTT. ISBN
|
||||
4-906391-22-2 C3055 P2400E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://www.shoeisha.co.jp/pc/index/shinkan/97_05_06.htm">Complete Introduction to FreeBSD</ulink> (auf japanisch), herausgegeben von <ulink url="http://www.shoeisha.co.jp/">Shoeisha Co., Ltd</ulink>. ISBN 4-88135-473-6 P3600E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://www.ascii.co.jp/pb/book1/shinkan/detail/1322785.html">Personal UNIX Starter Kit FreeBSD</ulink> (auf japanisch), herausgegeben von <ulink url="http://www.ascii.co.jp/">ASCII</ulink>. ISBN 4-7561-1733-3 P3000E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD Handbook (japanische Übersetzung), herausgegeben
|
||||
von <ulink url="http://www.ascii.co.jp/">ASCII</ulink>. ISBN
|
||||
4-7561-1580-2 P3800E.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD mit Methode (auf deutsch), herausgegeben von Computer und
|
||||
Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-932311-31-0.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://www.pc.mycom.co.jp/FreeBSD/install-manual.html">FreeBSD Install and Utilization Manual</ulink> (auf japanisch), herausgegeben von <ulink url="http://www.pc.mycom.co.jp/">Mainichi Communications Inc.</ulink>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><emphasis>Englischsprachige Bücher &
|
||||
Magazine:</emphasis></para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://www.cdrom.com/titles/freebsd/bsdcomp_bkx.phtml">
|
||||
The Complete FreeBSD</ulink>, herausgegeben von <ulink
|
||||
url="http://www.cdrom.com/">Walnut Creek CDROM</ulink>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bibliography-userguides">
|
||||
<title>Handbücher</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD
|
||||
User's Reference Manual</emphasis>. O'Reilly & Associates,
|
||||
Inc., 1994. ISBN 1-56592-075-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD
|
||||
User's Supplementary Documents</emphasis>. O'Reilly &
|
||||
Associates, Inc., 1994. ISBN 1-56592-076-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>UNIX in a Nutshell</emphasis>. O'Reilly &
|
||||
Associates, Inc., 1990. ISBN 093717520X</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Mui, Linda. <emphasis>What You Need To Know When You Can't Find
|
||||
Your UNIX System Administrator</emphasis>. O'Reilly &
|
||||
Associates, Inc., 1995. ISBN 1-56592-104-6</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Die <ulink url="http://www-wks.acs.ohio-state.edu/">Ohio State
|
||||
University</ulink> hat ein <ulink
|
||||
url="http://www-wks.acs.ohio-state.edu/unix_course/unix.html">UNIX
|
||||
Introductory Course</ulink> geschrieben, welcher auch online im
|
||||
HTML- und Postscriptformat verfügbar ist.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="http://www.jp.FreeBSD.org/">Jpman Project, Japan
|
||||
FreeBSD Users Group</ulink>. <ulink
|
||||
url="http://www.pc.mycom.co.jp/FreeBSD/urm.html">FreeBSD User's
|
||||
Reference Manual</ulink> (japanische Übersetzung). <ulink
|
||||
url="http://www.pc.mycom.co.jp/">Mainichi Communications
|
||||
Inc.</ulink>, 1998. ISBN4-8399-0088-4 P3800E.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bibliography-adminguides">
|
||||
<title>Administrations-Anleitungen</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Albitz, Paul and Liu, Cricket. <emphasis>DNS and
|
||||
BIND</emphasis>, 3nd Ed. O'Reilly & Associates, Inc., 1998.
|
||||
ISBN 1-56592-512-2</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD
|
||||
System Manager's Manual</emphasis>. O'Reilly & Associates,
|
||||
Inc., 1994. ISBN 1-56592-080-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Costales, Brian, et al. <emphasis>Sendmail</emphasis>, 2nd Ed.
|
||||
O'Reilly & Associates, Inc., 1997. ISBN 1-56592-222-0</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Frisch, Æleen. <emphasis>Essential System
|
||||
Administration</emphasis>, 2nd Ed. O'Reilly & Associates,
|
||||
Inc., 1995. ISBN 1-56592-127-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Hunt, Craig. <emphasis>TCP/IP Network
|
||||
Administration</emphasis>, 2nd Ed. O'Reilly & Associates, Inc., 1997.
|
||||
ISBN 1-56592-322-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Nemeth, Evi. <emphasis>UNIX System Administration
|
||||
Handbook</emphasis>. 3nd Ed. Prentice Hall, 2000. ISBN
|
||||
0-13-020601-6</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stern, Hal <emphasis>Managing NFS and NIS</emphasis> O'Reilly
|
||||
& Associates, Inc., 1991. ISBN 0-937175-75-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="http://www.jp.FreeBSD.org/">Jpman Project, Japan
|
||||
FreeBSD Users Group</ulink>. <ulink
|
||||
url="http://www.pc.mycom.co.jp/FreeBSD/sam.html">FreeBSD System
|
||||
Administrator's Manual</ulink> (japanische Übersetzung). <ulink
|
||||
url="http://www.pc.mycom.co.jp/">Mainichi Communications
|
||||
Inc.</ulink>, 1998. ISBN4-8399-0109-0 P3300E.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bibliography-programmers">
|
||||
<title>Programmierhandbücher</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Asente, Paul. <emphasis>X Window System Toolkit</emphasis>.
|
||||
Digital Press. ISBN 1-55558-051-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD
|
||||
Programmer's Reference Manual</emphasis>. O'Reilly &
|
||||
Associates, Inc., 1994. ISBN 1-56592-078-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Computer Systems Research Group, UC Berkeley. <emphasis>4.4BSD
|
||||
Programmer's Supplementary Documents</emphasis>. O'Reilly &
|
||||
Associates, Inc., 1994. ISBN 1-56592-079-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Harbison, Samuel P. and Steele, Guy L. Jr. <emphasis>C: A
|
||||
Reference Manual</emphasis>. 4rd ed. Prentice Hall, 1995.
|
||||
ISBN 0-13-326224-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Kernighan, Brian and Dennis M. Ritchie. <emphasis>The C
|
||||
Programming Language.</emphasis>. PTR Prentice Hall, 1988.
|
||||
ISBN 0-13-110362-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Lehey, Greg. <emphasis>Porting UNIX Software</emphasis>.
|
||||
O'Reilly & Associates, Inc., 1995. ISBN 1-56592-126-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Plauger, P. J. <emphasis>The Standard C Library</emphasis>.
|
||||
Prentice Hall, 1992. ISBN 0-13-131509-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>Advanced Programming in the UNIX
|
||||
Environment</emphasis>. Reading, Mass. : Addison-Wesley, 1992
|
||||
ISBN 0-201-56317-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>UNIX Network
|
||||
Programming</emphasis>. 2nd Ed, PTR Prentice Hall, 1998. ISBN
|
||||
0-13-490012-X</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wells, Bill. <quote>Writing Serial Drivers for UNIX</quote>.
|
||||
<emphasis>Dr. Dobb's Journal</emphasis>. 19(15), December 1994.
|
||||
pp68-71, 97-99.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bibliography-osinternals">
|
||||
<title>Betriebssystem-Interna</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Andleigh, Prabhat K. <emphasis>UNIX System
|
||||
Architecture</emphasis>. Prentice-Hall, Inc., 1990. ISBN
|
||||
0-13-949843-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Jolitz, William. <quote>Porting UNIX to the 386</quote>.
|
||||
<emphasis>Dr. Dobb's Journal</emphasis>. January 1991-July
|
||||
1992.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and
|
||||
John Quarterman <emphasis>The Design and Implementation of the
|
||||
4.3BSD UNIX Operating System</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1989. ISBN 0-201-06196-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Leffler, Samuel J., Marshall Kirk McKusick, <emphasis>The Design
|
||||
and Implementation of the 4.3BSD UNIX Operating System: Answer
|
||||
Book</emphasis>. Reading, Mass. : Addison-Wesley, 1991. ISBN
|
||||
0-201-54629-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and
|
||||
John Quarterman. <emphasis>The Design and Implementation of the
|
||||
4.4BSD Operating System</emphasis>. Reading, Mass. :
|
||||
Addison-Wesley, 1996. ISBN 0-201-54979-4</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume 1:
|
||||
The Protocols</emphasis>. Reading, Mass. : Addison-Wesley,
|
||||
1996. ISBN 0-201-63346-9</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Schimmel, Curt. <emphasis>Unix Systems for Modern
|
||||
Architectures</emphasis>. Reading, Mass. : Addison-Wesley, 1994.
|
||||
ISBN 0-201-63338-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stevens, W. Richard. <emphasis>TCP/IP Illustrated, Volume 3:
|
||||
TCP for Transactions, HTTP, NNTP and the UNIX Domain
|
||||
Protocols</emphasis>. Reading, Mass. : Addison-Wesley, 1996.
|
||||
ISBN 0-201-63495-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Vahalia, Uresh. <emphasis>UNIX Internals -- The New
|
||||
Frontiers</emphasis>. Prentice Hall, 1996. ISBN
|
||||
0-13-101908-2</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Wright, Gary R. and W. Richard Stevens. <emphasis>TCP/IP
|
||||
Illustrated, Volume 2: The Implementation</emphasis>. Reading,
|
||||
Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bibliography-security">
|
||||
<title>Sicherheits-Anleitung</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Cheswick, William R. and Steven M. Bellovin. <emphasis>Firewalls
|
||||
and Internet Security: Repelling the Wily Hacker</emphasis>.
|
||||
Reading, Mass. : Addison-Wesley, 1995. ISBN
|
||||
0-201-63357-4</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Garfinkel, Simson and Gene Spafford. <emphasis>Practical UNIX
|
||||
Security</emphasis>. 2nd Ed. O'Reilly & Associates, Inc.,
|
||||
1996. ISBN 1-56592-148-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Garfinkel, Simson. <emphasis>PGP Pretty Good
|
||||
Privacy</emphasis> O'Reilly & Associates, Inc., 1995. ISBN
|
||||
1-56592-098-8</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bibliography-hardware">
|
||||
<title>Hardware-Anleitung</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Anderson, Don and Tom Shanley. <emphasis>Pentium Processor
|
||||
System Architecture</emphasis>. 2nd Ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. ISBN 0-201-40992-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ferraro, Richard F. <emphasis>Programmer's Guide to the EGA,
|
||||
VGA, and Super VGA Cards</emphasis>. 3rd ed. Reading, Mass. :
|
||||
Addison-Wesley, 1995. ISBN 0-201-62490-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Die Intel Corporation veröffentlicht Dokumentationen
|
||||
Ihrer CPUs, Chipsets und Standards auf ihrer <ulink
|
||||
url="http://developer.intel.com/">developer web site</ulink>,
|
||||
normalerweise als PDF-Dateien.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>80486 System Architecture</emphasis>.
|
||||
3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN
|
||||
0-201-40994-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>ISA System Architecture</emphasis>.
|
||||
3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN
|
||||
0-201-40996-8</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shanley, Tom. <emphasis>PCI System Architecture</emphasis>.
|
||||
3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN
|
||||
0-201-40993-3</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Van Gilluwe, Frank. <emphasis>The Undocumented PC</emphasis>.
|
||||
Reading, Mass: Addison-Wesley Pub. Co., 1994. ISBN
|
||||
0-201-62277-7</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bibliography-history">
|
||||
<title>UNIX Geschichte</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Lion, John <emphasis>Lion's Commentary on UNIX, 6th Ed. With
|
||||
Source Code</emphasis>. ITP Media Group, 1996. ISBN
|
||||
1573980137</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Raymond, Eric S. <emphasis>The New Hacker's Dictionary, 3rd
|
||||
edition</emphasis>. MIT Press, 1996. ISBN
|
||||
0-262-68092-0. Auch bekannt als das <ulink
|
||||
url="http://www.ccil.org/jargon/jargon.html">Jargon
|
||||
File</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Salus, Peter H. <emphasis>A quarter century of UNIX</emphasis>.
|
||||
Addison-Wesley Publishing Company, Inc., 1994. ISBN
|
||||
0-201-54777-5</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Simon Garfinkel, Daniel Weise, Steven Strassmann. <emphasis>The
|
||||
UNIX-HATERS Handbook</emphasis>. IDG Books Worldwide, Inc.,
|
||||
1994. ISBN 1-56884-203-1</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don Libes, Sandy Ressler <emphasis>Life with UNIX</emphasis>
|
||||
— special edition. Prentice-Hall, Inc., 1989. ISBN
|
||||
0-13-536657-7</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The BSD family tree</emphasis>. 1997. <ulink
|
||||
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree">ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree</ulink> oder <ulink url="file:/usr/share/misc/bsd-family-tree">local</ulink> auf einem FreeBSD-current Rechner.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>The BSD Release Announcements collection</emphasis>.
|
||||
1997. <ulink
|
||||
url="http://www.de.FreeBSD.org/de/ftp/releases/">http://www.de.FreeBSD.org/de/ftp/releases/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Networked Computer Science Technical Reports
|
||||
Library</emphasis>. <ulink
|
||||
url="http://www.ncstrl.org/">http://www.ncstrl.org/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Old BSD releases from the Computer Systems Research
|
||||
group (CSRG)</emphasis>. <ulink
|
||||
url="http://www.mckusick.com/csrg/">http://www.mckusick.com/csrg/</ulink>:
|
||||
Das Paket mit 4 CDROM enthält alle BSD-Versionen von 1BSD
|
||||
bis 4.4BSD und 4.4BSD-Lite2 (unglücklicherweise nicht
|
||||
2.11BSD). Die letzte CD beinhaltet auch die finalen Sourcen
|
||||
inclusive den SCCS Dateien.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="bibliography-journals">
|
||||
<title>Magazine und Journale</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis>The C/C++ Users Journal</emphasis>. R&D
|
||||
Publications Inc. ISSN 1075-2838</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Sys Admin — The Journal for UNIX System
|
||||
Administrators</emphasis> Miller Freeman, Inc., ISSN
|
||||
1061-2688</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
</appendix>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../appendix.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "appendix")
|
||||
End:
|
||||
-->
|
||||
|
||||
@ -1,119 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/handbook/book.sgml,v 1.6 2001/03/24 15:19:30 alex Exp $
|
||||
Original version: ?
|
||||
-->
|
||||
|
||||
<!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V3.1-Based Extension//EN" [
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
|
||||
<!ENTITY % bookinfo PUBLIC "-//FreeBSD//ENTITIES DocBook BookInfo Entities//EN">
|
||||
%bookinfo;
|
||||
|
||||
<!ENTITY % translators PUBLIC "-//FreeBSD//ENTITIES DocBook Translator Entities//DE">
|
||||
%translators;
|
||||
|
||||
<!ENTITY % chapters SYSTEM "chapters.ent"> %chapters;
|
||||
<!ENTITY % authors SYSTEM "../../../en_US.ISO_8859-1/books/handbook/authors.ent"> %authors;
|
||||
<!ENTITY % mailing-lists SYSTEM "mailing-lists.ent"> %mailing-lists;
|
||||
<!ENTITY % newsgroups SYSTEM "newsgroups.ent"> %newsgroups;
|
||||
<!ENTITY % not.published "INCLUDE">
|
||||
|
||||
<!-- Die aktuelle FreeBSD-RELEASE version. Wird für verschiedene Dinge benutzt,
|
||||
z.B. Links auf Webseiten usw. Solange NICHT ändern wie es nicht wirklich
|
||||
Release-Zeit ist. -->
|
||||
<!ENTITY rel.current CDATA "4.2">
|
||||
]>
|
||||
|
||||
<book>
|
||||
<bookinfo>
|
||||
<title>FreeBSD Handbuch</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<surname>The FreeBSD German Documentation Project</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>de-bsd-translators@de.FreeBSD.org</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>February 1999</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>1995</year>
|
||||
<year>1996</year>
|
||||
<year>1997</year>
|
||||
<year>1998</year>
|
||||
<year>1999</year>
|
||||
<year>2000</year>
|
||||
<year>2001</year>
|
||||
<holder>The FreeBSD German Documentation Project</holder>
|
||||
</copyright>
|
||||
|
||||
&bookinfo.legalnotice;
|
||||
|
||||
<abstract>
|
||||
<para>Willkommen bei FreeBSD! Dieses Handbuch beschreibt die
|
||||
Installation und den täglichen Umgang mit <emphasis>FreeBSD
|
||||
Release &rel.current;</emphasis>.
|
||||
Das Handbuch ist <emphasis>jederzeit unter Bearbeitung</emphasis>
|
||||
und die Arbeit vieler Einzelpersonen. Manche Kapitel existieren noch
|
||||
nicht und andere Kapitel müssen auf den neusten Stand
|
||||
gebracht werden.
|
||||
Wenn Sie an diesem Projekt mithelfen möchten, senden Sie bitte
|
||||
eine E-Mail an die &a.de.translators;. Die letzte Version des
|
||||
Handbuchs ist immer auf dem
|
||||
<ulink URL="http://www.FreeBSD.ORG/de/handbook/">FreeBSD Web
|
||||
Server</ulink> verfügbar.
|
||||
Es kann außerdem in verschiedenen Formaten und in komprimierter
|
||||
Form vom <ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/doc">FreeBSD
|
||||
FTP Server</ulink> oder einer der vielen
|
||||
|
||||
<!--
|
||||
<link linkend="mirrors-ftp">Mirror Seiten</link>
|
||||
-->
|
||||
|
||||
<ulink URL="http://www.FreeBSD.org/handbook/mirrors-ftp.html">Mirror
|
||||
Seiten</ulink> herunter geladen werden.
|
||||
Vielleicht möchten Sie das Handbuch auch
|
||||
<ulink URL="http://www.FreeBSD.org/search.html">durchsuchen</ulink>.</para>
|
||||
</abstract>
|
||||
</bookinfo>
|
||||
|
||||
<part>
|
||||
<title>Erste Schritte</title>
|
||||
|
||||
&chap.basics;
|
||||
&chap.ports;
|
||||
</part>
|
||||
|
||||
<part>
|
||||
<title>System Administration</title>
|
||||
&chap.users;
|
||||
&chap.backups;
|
||||
</part>
|
||||
|
||||
<part>
|
||||
<title>Anhang</title>
|
||||
|
||||
&chap.bibliography;
|
||||
</part>
|
||||
|
||||
</book>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
End:
|
||||
-->
|
||||
|
||||
@ -1 +0,0 @@
|
||||
<!DOCTYPE chapter PUBLIC "-//FreeBSD//DTD DocBook V3.1-Based Extension//EN">
|
||||
@ -1,22 +0,0 @@
|
||||
<!--
|
||||
Die Entities für jedes Kapitel im FreeBSD Handbuch.
|
||||
Jede Entity heißt chap.foo, wobei foo der Name des ID-Attributes
|
||||
dieses Kapitels ist und dem Verzeichnis, in dem die entsprechende
|
||||
.sgml Datei liegt, entspricht.
|
||||
|
||||
Kapitel sollten in der Reihenfolge aufgelistet sein, in der auf sie
|
||||
referenziert wird.
|
||||
|
||||
$FreeBSD: doc/de_DE.ISO_8859-1/books/handbook/chapters.ent,v 1.5 2000/08/18 12:47:39 alex Exp $
|
||||
-->
|
||||
|
||||
<!-- Teil Eins -->
|
||||
<!ENTITY chap.basics SYSTEM "basics/chapter.sgml">
|
||||
<!ENTITY chap.ports SYSTEM "ports/chapter.sgml">
|
||||
|
||||
<!-- Teil Zwei -->
|
||||
<!ENTITY chap.users SYSTEM "users/chapter.sgml">
|
||||
<!ENTITY chap.backups SYSTEM "backups/chapter.sgml">
|
||||
|
||||
<!-- Teil Fünf (Anhang) -->
|
||||
<!ENTITY chap.bibliography SYSTEM "bibliography/chapter.sgml">
|
||||
@ -1,114 +0,0 @@
|
||||
<!--
|
||||
Namen der FreeBSD Mailinglisten und verwandter Software
|
||||
|
||||
$FreeBSD: doc/de_DE.ISO_8859-1/books/handbook/mailing-lists.ent,v 1.1 2000/06/11 18:50:56 alex Exp $
|
||||
-->
|
||||
|
||||
<!ENTITY a.advocacy "FreeBSD Befürworter Mailingliste
|
||||
<email>freebsd-advocacy@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.announce "FreeBSD Ankündigungen Mailingliste
|
||||
<email>freebsd-announce@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.bugs "FreeBSD Problem Report (PR) Mailingliste
|
||||
<email>freebsd-bugs@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.chat "FreeBSD Chat Mailingliste
|
||||
<email>freebsd-chat@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.core "FreeBSD Core Team
|
||||
<email>freebsd-core@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.current "FreeBSD-current Mailingliste
|
||||
<email>freebsd-current@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.cvsall "FreeBSD CVS Commit Nachrichten Mailingliste
|
||||
<email>cvs-all@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.database "FreeBSD basierte Datenbanken Mailingliste
|
||||
<email>freebsd-database@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.doc "FreeBSD Documentation Project Mailingliste
|
||||
<email>freebsd-doc@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.emulation "FreeBSD-emulation Mailingliste
|
||||
<email>freebsd-emulation@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.fs "FreeBSD Filesystem Project (Dateisysteme) Mailingliste
|
||||
<email>freebsd-fs@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.hackers "FreeBSD technische Diskussionen Mailingliste
|
||||
<email>freebsd-hackers@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.hardware "FreeBSD Hardware und Zubehör Mailingliste
|
||||
<email>freebsd-hardware@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.isdn "FreeBSD ISDN Mailingliste
|
||||
<email>freebsd-isdn@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.isp "FreeBSD Internet Service Providers Mailingliste
|
||||
<email>freebsd-isp@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.java "FreeBSD Java Mailingliste
|
||||
<email>freebsd-java@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.jobs "FreeBSD betreffende Stellenangebote/-gesuche Mailingliste
|
||||
<email>freebsd-jobs@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mobile "FreeBSD Laptop Computer Mailingliste
|
||||
<email>freebsd-mobile@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.mozilla "FreeBSD Portierung des Mozilla Browsers Mailingliste
|
||||
<email>freebsd-mozilla@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.multimedia "FreeBSD Multimedia Mailingliste
|
||||
<email>freebsd-multimedia@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.net "FreeBSD Netzwerk und Netzwerktechnik Mailingliste
|
||||
<email>freebsd-net@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.newbies "FreeBSD Anfänger Mailingliste
|
||||
<email>freebsd-newbies@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.newbus "New Bus Architektur Mailingliste
|
||||
<email>new-bus-arch@bostonradio.org</email>">
|
||||
|
||||
<!ENTITY a.ports "FreeBSD Ports Mailingliste
|
||||
<email>freebsd-ports@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.questions "FreeBSD generelle Fragen Mailingliste
|
||||
<email>freebsd-questions@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.scsi "FreeBSD SCSI Subsystem Mailingliste
|
||||
<email>freebsd-scsi@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.security "FreeBSD Security Mailingliste
|
||||
<email>freebsd-security@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.security-notifications "FreeBSD Sicherheits Benachrichtungen Mailingliste
|
||||
<email>freebsd-security-notifications@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.small "FreeBSD-small Mailingliste
|
||||
<email>freebsd-small@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.smp "FreeBSD Symmetric Multiprocessing Mailingliste
|
||||
<email>freebsd-smp@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.stable "FreeBSD-stable Mailingliste
|
||||
<email>freebsd-stable@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.tokenring "FreeBSD Tokenring Mailingliste
|
||||
<email>freebsd-tokenring@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.www "FreeBSD Webmaster Mailingliste
|
||||
<email>freebsd-www@FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.majordomo "<email>majordomo@FreeBSD.org</email>">
|
||||
|
||||
<!-- Deutsche Mailinglisten -->
|
||||
|
||||
<!ENTITY a.de.translators "FreeBSD German Documentation Project Mailingliste
|
||||
<email>de-bsd-translators@de.FreeBSD.org</email>">
|
||||
|
||||
<!ENTITY a.de.questions "deutsche FreeBSD Fragen Mailingliste
|
||||
<email>de-bsd-questions@de.FreeBSD.org</email>">
|
||||
@ -1,10 +0,0 @@
|
||||
<!--
|
||||
Namen der FreeBSD Newsgroups
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<!ENTITY ng.misc "die
|
||||
<ulink url='news:comp.unix.bsd.freebsd.misc'>comp.unix.bsd.freebsd.misc</ulink>
|
||||
Newsgroup">
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,445 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
Original Revision 1.4
|
||||
|
||||
$FreeBSD$
|
||||
$FreeBSDde: de-docproj/books/handbook/users/chapter.sgml,v 1.2 2001/03/23 07:28:36 robert Exp $
|
||||
-->
|
||||
|
||||
<chapter id="users">
|
||||
<title>Benutzer und grundlegende Account-Verwaltung</title>
|
||||
|
||||
<sect1 id="users-synopsis">
|
||||
<title>Übersicht</title>
|
||||
|
||||
<para><emphasis>Beigesteuert von &a.nbm; im Februar 2000. Übersetzt
|
||||
von &a.de.robert; im Juli 2000.</emphasis></para>
|
||||
|
||||
<para>Jeder Zugriff auf das System geschieht über Accounts und alle
|
||||
Prozesse werden von Benutzern gestartet, also sind Benutzer- und
|
||||
Account-Verwaltung von wesentlicher Bedeutung in FreeBSD-Systemen.</para>
|
||||
|
||||
<para>Es gibt drei Haupttypen von Accounts: Der
|
||||
<link linkend="users-superuser">Superuser</link>,
|
||||
<link linkend="users-system">Systembenutzer</link> und
|
||||
<link linkend="users-user">Benutzer-Accounts</link>. Der
|
||||
Superuser-Account, normalerweise <username>root</username> genannt, wird
|
||||
benutzt, um das System ohne Beschränkungen auf Privilegien zu
|
||||
verwalten. Systembenutzer starten Dienste. Abschliessend werden
|
||||
Benutzer-Accounts von echten Menschen genutzt, die sich einloggen, Mails
|
||||
lesen und so weiter.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="users-superuser">
|
||||
<title>Der Superuser-Account</title>
|
||||
|
||||
<para>Der Superuser-Account, normalerweise <username>root</username>
|
||||
genannt, ist vorkonfiguriert und erleichtert die Systemverwaltung, sollte
|
||||
aber nicht für alltägliche Aufgaben wie verschicken und
|
||||
empfangen von Mails, Entdecken des Systems oder Programmierung benutzt
|
||||
werden.</para>
|
||||
|
||||
<para>Das ist so, da der Superuser im Gegensatz zu normalen
|
||||
Benutzer-Accounts ohne Beschränkungen operiert und falsche
|
||||
Anwendung des Superuser-Accounts in spektakulären Katastrophen
|
||||
resultieren kann. Benutzer-Accounts sind nicht fähig das System
|
||||
versehentlich zu zerstören, deswegen ist es generell am besten
|
||||
normale Benutzer-Accounts zu verwenden, solange man nicht
|
||||
hauptsächlich die extra Privililegien benötigt.</para>
|
||||
|
||||
<para>Zusätzlich sollten Sie Kommandos, die Sie als Superuser
|
||||
eingeben, immer doppelt und dreifach überprüfen, da ein
|
||||
zusätzliches Leerzeichen oder ein fehlender Buchstabe irreparablen
|
||||
Datenverlust bedeuten kann. Diese zusätzlichen Privilegien, die Sie
|
||||
benötigten, als Sie zu dem Superuser-Account gewechselt haben,
|
||||
bedeuten, dass die Absicherung Ihres normalen Benutzer-Accounts nicht
|
||||
mehr gültig ist.</para>
|
||||
|
||||
<para>Das erste, das Sie tun sollten, nachdem Sie dieses Kapitel gelesen
|
||||
haben, ist einen unprivilegierten Benutzer für Ihre eigene normale
|
||||
Benutzung zu erstellen, wenn Sie das nicht bereits getan haben. Das
|
||||
trifft immer zu, egal ob Sie ein Mehrbenutzer-System oder ein System
|
||||
laufen haben, welches Sie alleine benutzen. Später in diesem
|
||||
Kapitel besprechen wir, wie man zusätzliche Accounts erstellt und
|
||||
wie man zwischen dem normalen Benutzer und dem Superuser wechselt.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="users-system">
|
||||
<title>System-Accounts</title>
|
||||
|
||||
<para>Systembenutzer starten Dienste wie DNS, mail, Web-Server und so
|
||||
weiter. Der Grund dafür ist die Sicherheit; wenn die Programme
|
||||
von dem Superuser gestartet werden, können Sie ohne
|
||||
Einschränkungen handeln.</para>
|
||||
|
||||
<para>Beispiele von Systembenutzern sind <username>daemon</username>,
|
||||
<username>operator</username>, <username>bind</username> (für den
|
||||
Domain Name Service) und <username>news</username>. Oft erstellen
|
||||
Systemadministratoren den Benutzer <username>httpd</username>, um
|
||||
Web-Server laufen zu lassen, die sie installieren.</para>
|
||||
|
||||
<para><username>nobody</username> ist der generische unprivilegierte
|
||||
Systembenutzer, aber je mehr Dienste nobody benutzen, um so
|
||||
privilegierter wird er.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="users-user">
|
||||
<title>Benutzer-Accounts</title>
|
||||
|
||||
<para>Benutzer-Account sind das primäre Mittel des Zugriffs für
|
||||
echte Menschen auf das System und isolieren Benutzer und Umgebung,
|
||||
schützen die Benutzer davor das System oder Daten anderer Benutzer
|
||||
zu beschädigen und erlauben Benutzern ihre Umgebung selbst
|
||||
einzurichten, ohne das sich dies auf andere auswirkt.</para>
|
||||
|
||||
<para>Jede Person, die auf Ihr System zugreift, sollte ihren eigenen
|
||||
Account besitzen. Das erlaubt Ihnen herauszufinden, wer was macht
|
||||
und hält Leute davon ab, die Einstellungen der anderen zu
|
||||
verändern oder mails zu lesen, die nicht für sie bestimmt
|
||||
waren.</para>
|
||||
|
||||
<para>Jeder Benutzer kann seine eigene Umgebung einstellen, um sie
|
||||
der Benutzung auf dem System anzupassen: Alternative Shells, Editoren,
|
||||
Tastaturbelegungen und Sprache.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="users-modifying">
|
||||
<title>Accounts verändern</title>
|
||||
|
||||
<para><application>pw</application> ist ein mächtiges und flexibles
|
||||
Mittel für zum Ändern von Accounts, aber <application>adduser
|
||||
</application> wird empfohlen zum Erstellen und <application>rmuser
|
||||
</application> zum Löschen von Accounts.</para>
|
||||
|
||||
<para><application>chpass</application> erlaubt dem Systemadministrator
|
||||
und normalen Benutzern Passwörter, Shells und personelle
|
||||
Informationen einzustellen. Jedoch ist <application>passwd</application>
|
||||
das gewöhnlichere Mittel, um Passwörter im speziellen zu
|
||||
ändern.</para>
|
||||
|
||||
<sect2 id="users-adduser">
|
||||
<title>adduser</title>
|
||||
|
||||
<para><application>adduser</application> ist ein einfaches Programm
|
||||
um neue Benutzer hinzuzufügen. Es erstellt <filename>passwd
|
||||
</filename> und <filename>group</filename> Einträge für den
|
||||
Benutzer, genauso wie ein home Verzeichnis, kopiert ein paar
|
||||
vorgegebene dotfiles aus <filename>/usr/share/skel</filename> und kann
|
||||
optional dem Benutzer eine ,,Willkommen``-Nachricht zuschicken.</para>
|
||||
|
||||
<para>Um die anfängliche Konfigurationsdatei zu erstellen,
|
||||
benutzen Sie: <command>adduser -s -config_create</command>.
|
||||
<footnote>
|
||||
<para>Das <option>-s</option> bringt <application>adduser
|
||||
</application> dazu, weniger Fragen und Fehlermeldungen auszugeben.
|
||||
Wir benutzen <option>-v</option> später, wenn wir die
|
||||
Voreinstellungen ändern wollen.</para>
|
||||
</footnote>
|
||||
Zunächst konfigurieren wir addusers Voreinstellungen und
|
||||
erstellen unseren ersten Benutzer-Account, da es böse und
|
||||
unangenehm ist, root für normale Aufgaben zu verwenden.</para>
|
||||
<example>
|
||||
<title>Die Konfiguration für adduser ändern</title>
|
||||
|
||||
<screen>&prompt.root; <userinput>adduser -v</userinput>
|
||||
Use option ``-silent'' if you don't want to see all warnings and questions.
|
||||
Check /etc/shells
|
||||
Check /etc/master.passwd
|
||||
Check /etc/group
|
||||
Enter your default shell: csh date no sh tcsh [sh]: <userinput>tcsh</userinput>
|
||||
Your default shell is: tcsh -> /usr/local/bin/tcsh
|
||||
Enter your default HOME partition: [/home]:
|
||||
Copy dotfiles from: /usr/share/skel no [/usr/share/skel]:
|
||||
Send message from file: /etc/adduser.message no
|
||||
[/etc/adduser.message]: <userinput>no</userinput>
|
||||
Do not send message
|
||||
Use passwords (y/n) [y]: <userinput>y</userinput>
|
||||
|
||||
Write your changes to /etc/adduser.conf? (y/n) [n]: <userinput>y</userinput>
|
||||
|
||||
Ok, let's go.
|
||||
Don't worry about mistakes. I will give you the chance later to correct any input.
|
||||
Enter username [a-z0-9_-]: <userinput>jru</userinput>
|
||||
Enter full name []: <userinput>J. Random User</userinput>
|
||||
Enter shell csh date no sh tcsh [tcsh]:
|
||||
Enter home directory (full path) [/home/jru]:
|
||||
Uid [1001]:
|
||||
Enter login class: default []:
|
||||
Login group jru [jru]:
|
||||
Login group is ``jru''. Invite jru into other groups: guest no
|
||||
[no]: <userinput>wheel</userinput>
|
||||
Enter password []:
|
||||
Enter password again []:
|
||||
|
||||
Name: jru
|
||||
Password: ****
|
||||
Fullname: J. Random User
|
||||
Uid: 1007
|
||||
Gid: 1007 (jru)
|
||||
Class:
|
||||
Groups: jru wheel
|
||||
HOME: /home/jru
|
||||
Shell: /usr/local/bin/tcsh
|
||||
OK? (y/n) [y]: <userinput>y</userinput>
|
||||
Added user ``jru''
|
||||
Copy files from /usr/share/skel to /home/jru
|
||||
Add another user? (y/n) [y]: <userinput>n</userinput>
|
||||
Goodbye!
|
||||
&prompt.root;</screen>
|
||||
</example>
|
||||
|
||||
<para>Zusammengefasst haben wir die vorgegebene Shell in
|
||||
<application>tcsh</application> (eine zusätzliche Shell aus
|
||||
den Packages) geändert und das Senden einer
|
||||
,,Willkommen``-Nachricht an neue Benutzer abgeschaltet.
|
||||
Danach haben wir die Konfiguration abgespeichert und anschliessend
|
||||
einen Account für <username>jru</username> eingerichtet
|
||||
und sichergestellt, dass <username>jru</username> in der
|
||||
Gruppe <username>wheel</username> ist (was später wichtig ist,
|
||||
wie wir sehen werden).</para>
|
||||
<note>
|
||||
<para>Wenn Sie das Passwort eingeben, werden weder Passwort noch
|
||||
Sternchen angezeigt. Passen Sie auf, dass Sie das Passwort nicht
|
||||
zweimal falsch eingeben. :-)</para>
|
||||
</note>
|
||||
<note>
|
||||
<para>Benutzen Sie ab jetzt <command>adduser</command> ohne Argumente,
|
||||
dann müssen Sie nicht jedes mal die Vorgaben neu einstellen.
|
||||
Wenn das Programm Sie fragt, ob Sie die Vorgaben ändern wollen,
|
||||
verlassen und starten Sie es erneut mit der <option>-s</option>
|
||||
Option.</para>
|
||||
</note>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="users-rmuser">
|
||||
<title>rmuser</title>
|
||||
|
||||
<para><application>rmuser</application> entfernt Benutzer aus dem System,
|
||||
inklusive der Spuren ausserhalb der Benutzer-Datenbank.</para>
|
||||
|
||||
<para><application>rmuser</application> führt die folgenden
|
||||
Schritte durch:</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<para>Enfernt den &man.crontab.1; Eintrag des Benutzers (wenn dieser
|
||||
existiert).</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Entfernt alle &man.at.1; jobs, die dem Benutzer gehören.
|
||||
</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Schliesst alle Prozesse des Benutzers.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Entfernt den Benutzer aus der lokalen Passwort-Datei des
|
||||
Systems.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Entfernt das home Verzeichnis des Benutzers (falls es dem
|
||||
Benutzer gehört).</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Entfernt die eingegangen mails, die dem Benutzer gehören,
|
||||
aus <filename>/var/mail</filename>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Entfernt alle Dateien des Benutzers aus temporären
|
||||
Dateispeicherbereichen wie <filename>/tmp</filename>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Entfernt den Benutzernamen von allen Gruppen, zu denen er
|
||||
gehört, aus <filename>/etc/group</filename>.
|
||||
|
||||
<note>
|
||||
<para>Wenn eine Gruppe leer wird und der Gruppenname mit dem
|
||||
Benutzernamen identisch ist, wird die Gruppe entfernt; das
|
||||
ergänzt sich mit den einzelnen Benutzer-Gruppen, die von
|
||||
&man.adduser.8; für jeden neuen Benutzer erstellt werden.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
</step>
|
||||
</procedure>
|
||||
|
||||
<para><application>rmuser</application> kann nicht dafür benutzt
|
||||
werden Superuser-Accounts zu entfernen, da dies nahezu immer ein
|
||||
Zeichen für eine massive Verwüstung ist.</para>
|
||||
|
||||
<para>Als Vorgabe wird ein interaktiver Modus benutzt, der
|
||||
sicherzustellen versucht, dass Sie wissen, was Sie tun.</para>
|
||||
|
||||
<example>
|
||||
<title>interaktives Account-Entfernen mit rmuser</title>
|
||||
|
||||
<screen>&prompt.root; <userinput>rmuser jru</userinput>
|
||||
Matching password entry:
|
||||
jru:*:1000:1000::0:0:J. Random User:/home/jru:/usr/local/bin/tcsh
|
||||
Is this the entry you wish to remove? <userinput>y</userinput>
|
||||
Remove user's home directory (/home/jru)? <userinput>y</userinput>
|
||||
Updating password file, updating databases, done.
|
||||
Updating group file: trusted (removing group jru -- personal group is empty) done.
|
||||
Removing user's incoming mail file /var/mail/jru: done.
|
||||
Removing files belonging to jru from /tmp: done.
|
||||
Removing files belonging to jru from /var/tmp: done.
|
||||
Removing files belonging to jru from /var/tmp/vi.recover: done.
|
||||
&prompt.root;</screen>
|
||||
</example>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="users-pw">
|
||||
<title>pw</title>
|
||||
|
||||
<para><application>pw</application> ist ein Kommandozeilenprogramm, mit
|
||||
dem man Benutzer und Gruppen erstellen, entfernen und anzeigen kann,
|
||||
und fungiert als Editor der Benutzer- und Gruppendateien des Systems.
|
||||
</para>
|
||||
|
||||
<para>Es wurde entworfen um nützlich als direkt ausgeführter
|
||||
Befehl und für die Benutzung in Shell-Scripts zu sein.</para>
|
||||
|
||||
<para>Informationen darüber gibt es in &man.pw.8;.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="users-chpass">
|
||||
<title>chpass</title>
|
||||
|
||||
<para><application>chpass</application> ändert Informationen der
|
||||
Benutzerdatenbank wie Passwörter, Shells und personelle
|
||||
Informationen.</para>
|
||||
|
||||
<para>Nur Systemadministratoren, als Superuser, können die
|
||||
Informationen und Passwörter der anderen Benutzer mit
|
||||
<application>chpass</application> verändern.</para>
|
||||
|
||||
<para>Werden keine Optionen neben dem optionalen Benutzernamen
|
||||
angegeben, zeigt <application>chpass</application> einen Editor
|
||||
mit Benutzerinformationen an und wenn dieser Editor beendet wird,
|
||||
versucht es die Informationen in der Benutzerdatenbank zu
|
||||
verändern.</para>
|
||||
|
||||
<example>
|
||||
<title>Interaktives chpass des Superusers</title>
|
||||
|
||||
<screen>#Changing user database information for jru.
|
||||
Login: jru
|
||||
Password: *
|
||||
Uid [#]: 1000
|
||||
Gid [# or name]: 1000
|
||||
Change [month day year]:
|
||||
Expire [month day year]:
|
||||
Class:
|
||||
Home directory: /home/jru
|
||||
Shell: /usr/local/bin/tcsh
|
||||
Full Name: J. Random User
|
||||
Office Location:
|
||||
Office Phone:
|
||||
Home Phone:
|
||||
Other information:</screen>
|
||||
</example>
|
||||
|
||||
<para>Der normale Benutzer kann nur einen kleinen Teil dieser
|
||||
Informationen verändern und natürlich nur für sich
|
||||
selbst.</para>
|
||||
|
||||
<example>
|
||||
<title>Interaktives chpass eines normalen Benutzers</title>
|
||||
|
||||
<screen>#Changing user database information for jru.
|
||||
Shell: /usr/local/bin/tcsh
|
||||
Full Name: J. Random User
|
||||
Office Location:
|
||||
Office Phone:
|
||||
Home Phone:
|
||||
Other information:</screen>
|
||||
</example>
|
||||
|
||||
<note>
|
||||
<para><command>chfn</command> und <command>chsh</command> sind
|
||||
nur Verweise auf <command>chpass</command>, genauso wie
|
||||
<command>ypchpass</command>, <command>ypchfn</command> und
|
||||
<command>ypchsh</command>. NIS wird automatisch unterstützt,
|
||||
deswegen ist es nicht notwendig das <literal>yp</literal> vor dem
|
||||
Kommando einzugeben.</para>
|
||||
</note>
|
||||
</sect2>
|
||||
<sect2 id="users-passwd">
|
||||
<title>passwd</title>
|
||||
|
||||
<para><application>passwd</application> ist der übliche Weg Ihr
|
||||
eigenes Passwort als Benutzer zu ändern oder das Passwort eines
|
||||
anderen Benutzers als Superuser.</para>
|
||||
|
||||
<note>
|
||||
<para>Benutzer müssen ihr ursprüngliches Passwort eingeben,
|
||||
bevor sie es wechseln, um eine unauthorisierte Person davon
|
||||
abzuhalten ihr Passwort zu ändern, wenn der Benutzer gerade
|
||||
nicht an seinem Gerät ist.</para>
|
||||
</note>
|
||||
|
||||
<example>
|
||||
<title>passwd</title>
|
||||
|
||||
<screen>&prompt.user; <userinput>passwd</userinput>
|
||||
Changing local password for jru.
|
||||
Old password:
|
||||
New password:
|
||||
Retype new password:
|
||||
passwd: updating the database...
|
||||
passwd: done
|
||||
|
||||
&prompt.root; <userinput>passwd jru</userinput>
|
||||
Changing local password for jru.
|
||||
New password:
|
||||
Retype new password:
|
||||
passwd: updating the database...
|
||||
passwd: done</screen>
|
||||
</example>
|
||||
|
||||
<note>
|
||||
<para><command>yppasswd</command> ist nur ein Verweis zu
|
||||
<command>passwd</command>. NIS wird automatisch
|
||||
unterstützt, also ist es nicht notwendig, <literal>yp</literal>
|
||||
vor dem Kommando einzugeben.</para>
|
||||
</note>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="users-limiting-and-personalizing">
|
||||
<title>Benutzer einschränken und personalisieren</title>
|
||||
|
||||
<para>Kontigente erlauben dem Systemadministrator
|
||||
Benutzungsbeschränkungen der Festplatte festzusetzen und Benutzern
|
||||
ihre Festplattenbenutzung zu überprüfen, wenn Kontigente
|
||||
auf dem System verwendet werden. Kontigente werden in ihrem
|
||||
<!--
|
||||
<link linkend="quotas">eigenen Kapitel</link>
|
||||
-->
|
||||
eigenen Kapitel
|
||||
besprochen.</para>
|
||||
|
||||
<para>Die Lokalisierung ist eine Umgebung, die vom Systemadministrator oder
|
||||
Benutzer eingerichtet wird, um verschiedene Sprachen, Zeichensätze,
|
||||
Datum- und Zeitstandards und so weiter unterzubringen. Dies wird im
|
||||
Kapitel über die
|
||||
<!--
|
||||
<link linkend="l10n">Lokalisierung</link>
|
||||
-->
|
||||
Lokalisierung
|
||||
besprochen.</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
@ -1,12 +0,0 @@
|
||||
<!--
|
||||
Querverweise auf andere Dateien können in einem DocBook BookInfo
|
||||
Element eingefügt werden.
|
||||
|
||||
Entity Namen haben die Form "bookinfo.<element>", wobei <element> der
|
||||
Name des äußersten Elements in der Entity ist. Beispiele sind
|
||||
"bookinfo.legalnotice" und "bookinfo.preface".
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<!ENTITY bookinfo.legalnotice SYSTEM "legalnotice.sgml">
|
||||
@ -1,9 +0,0 @@
|
||||
-- ...................................................................... --
|
||||
-- FreeBSD SGML Public Identifiers ...................................... --
|
||||
|
||||
-- $FreeBSD: doc/share/sgml/catalog,v 1.9 2000/07/08 16:31:28 phantom Exp $
|
||||
--
|
||||
|
||||
PUBLIC "-//FreeBSD//DOCUMENT DocBook Stylesheet//EN"
|
||||
"freebsd.dsl"
|
||||
|
||||
@ -1,55 +0,0 @@
|
||||
<!-- $FreeBSDde: de-docproj/share/sgml/freebsd.dsl,v 1.4 2001/01/06 18:15:53 alex Exp $
|
||||
$FreeBSD: doc/de_DE.ISO_8859-1/share/sgml/freebsd.dsl,v 1.5 2001/04/01 13:59:08 alex Exp $ -->
|
||||
|
||||
<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
|
||||
<!ENTITY freebsd.dsl PUBLIC "-//FreeBSD//DOCUMENT DocBook Language Neutral Stylesheet//EN" CDATA DSSSL>
|
||||
<!ENTITY % output.html "IGNORE">
|
||||
<!ENTITY % output.print "IGNORE">
|
||||
]>
|
||||
|
||||
<style-sheet>
|
||||
<style-specification use="docbook">
|
||||
<style-specification-body>
|
||||
|
||||
<![ %output.html; [
|
||||
(define ($email-footer$)
|
||||
(make sequence
|
||||
(make element gi: "p"
|
||||
attributes: (list (list "align" "center"))
|
||||
(make element gi: "small"
|
||||
(literal "Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine EMail an <")
|
||||
(make element gi: "a"
|
||||
attributes: (list (list "href" "mailto:de-bsd-questions@de.FreeBSD.org"))
|
||||
(literal "de-bsd-questions@de.FreeBSD.org"))
|
||||
(literal ">.")
|
||||
(make empty-element gi: "br")
|
||||
(literal "Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine Email an <")
|
||||
(make element gi: "a"
|
||||
attributes: (list (list "href" "mailto:de-bsd-translators@de.FreeBSD.org"))
|
||||
(literal "de-bsd-translators@de.FreeBSD.org"))
|
||||
(literal ">.")))))
|
||||
|
||||
|
||||
<!-- Convert " ... " to `` ... '' in the HTML output. -->
|
||||
(element quote
|
||||
(make sequence
|
||||
(literal "``")
|
||||
(process-children)
|
||||
(literal "''")))
|
||||
|
||||
<!-- Generate links to HTML man pages -->
|
||||
(define %refentry-xref-link% #t)
|
||||
|
||||
<!-- Specify how to generate the man page link HREF -->
|
||||
(define ($create-refentry-xref-link$ refentrytitle manvolnum)
|
||||
(string-append "http://www.de.FreeBSD.org/cgi/man.cgi?"
|
||||
refentrytitle
|
||||
"("
|
||||
manvolnum
|
||||
")"))
|
||||
]]>
|
||||
</style-specification-body>
|
||||
</style-specification>
|
||||
|
||||
<external-specification id="docbook" document="freebsd.dsl">
|
||||
</style-sheet>
|
||||
@ -1,44 +0,0 @@
|
||||
<!--
|
||||
Standard FreeBSD Documentation Project Legal Notice.
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<legalnotice>
|
||||
<para>Redistribution and use in source (SGML DocBook) and 'compiled'
|
||||
forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without
|
||||
modification, are permitted provided that the following conditions are
|
||||
met:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Redistributions of source code (SGML DocBook) must retain the
|
||||
above copyright notice, this list of conditions and the following
|
||||
disclaimer as the first lines of this file unmodified.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Redistributions in compiled form (transformed to other DTDs,
|
||||
converted to PDF, PostScript, RTF and other formats) 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.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<important>
|
||||
<para>THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION
|
||||
PROJECT "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
|
||||
THE FREEBSD DOCUMENTATION PROJECT 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 DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
|
||||
DAMAGE.</para>
|
||||
</important>
|
||||
</legalnotice>
|
||||
|
||||
@ -1,14 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD German Documentation Project
|
||||
|
||||
Deutsche Übersetzer
|
||||
$FreeBSDde: de-docproj/share/sgml/translators.ent,v 1.4 2001/03/23 03:22:50 robert Exp $
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
||||
<!ENTITY a.de.bwarken "Bernd Warken <email>bwarken@mayn.de</email>">
|
||||
<!ENTITY a.de.gruender "Frank Gründer <email>elwood@mc5sys.in-berlin.de</email>">
|
||||
<!ENTITY a.de.pierau "Uwe Pierau <email>uwe.pierau@tu-clausthal.de</email>">
|
||||
<!ENTITY a.de.robert "Robert Drehmel <email>robert@gizmo.quizbot.org</email>">
|
||||
<!ENTITY a.de.ue "Udo Erdelhoff <email>ue@nathan.ruhr.de</email>">
|
||||
@ -1,5 +1,5 @@
|
||||
#
|
||||
# $FreeBSD$
|
||||
# $FreeBSD: doc/en_US.ISO8859-1/articles/Makefile.inc,v 1.3 1999/09/06 06:52:35 peter Exp $
|
||||
#
|
||||
|
||||
DESTDIR?= ${DOCDIR}/en_US.ISO_8859-1/articles/${.CURDIR:T}
|
||||
DESTDIR?= ${DOCDIR}/en_US.ISO8859-1/articles/${.CURDIR:T}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
#
|
||||
# $FreeBSD$
|
||||
# $FreeBSD: doc/en_US.ISO8859-1/books/Makefile.inc,v 1.3 1999/09/06 06:52:39 peter Exp $
|
||||
#
|
||||
|
||||
DESTDIR?= ${DOCDIR}/en_US.ISO_8859-1/books/${.CURDIR:T}
|
||||
DESTDIR?= ${DOCDIR}/en_US.ISO8859-1/books/${.CURDIR:T}
|
||||
|
||||
@ -1,9 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
SUBDIR = articles
|
||||
SUBDIR+= books
|
||||
|
||||
COMPAT_SYMLINK = en
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,21 +0,0 @@
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/articles/Makefile,v 1.10 2001/03/14 18:11:19 nik Exp $
|
||||
|
||||
SUBDIR = committers-guide
|
||||
SUBDIR+= dialup-firewall
|
||||
SUBDIR+= diskless-x
|
||||
SUBDIR+= explaining-bsd
|
||||
SUBDIR+= freebsd-questions
|
||||
SUBDIR+= fonts
|
||||
SUBDIR+= formatting-media
|
||||
SUBDIR+= ipsec-must
|
||||
SUBDIR+= mh
|
||||
SUBDIR+= multi-os
|
||||
SUBDIR+= new-users
|
||||
SUBDIR+= programming-tools
|
||||
SUBDIR+= vm-design
|
||||
SUBDIR+= zip-drive
|
||||
|
||||
# ROOT_SYMLINKS+= new-users
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,5 +0,0 @@
|
||||
#
|
||||
# $FreeBSD$
|
||||
#
|
||||
|
||||
DESTDIR?= ${DOCDIR}/en_US.ISO_8859-1/articles/${.CURDIR:T}
|
||||
@ -1,27 +0,0 @@
|
||||
#
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/articles/committers-guide/Makefile,v 1.3 1999/09/06 06:52:35 peter Exp $
|
||||
#
|
||||
# Build the FreeBSD New Committers Guide
|
||||
#
|
||||
|
||||
MAINTAINER=jhb@FreeBSD.org
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?= gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
JADEFLAGS+= -V %generate-article-toc%
|
||||
|
||||
#
|
||||
# SRCS lists the individual SGML files that make up the document. Changes
|
||||
# to any of these files will force a rebuild
|
||||
#
|
||||
|
||||
# SGML content
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,14 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,361 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/articles/dialup-firewall/article.sgml,v 1.6 2001/02/27 12:45:43 jesusr Exp $
|
||||
-->
|
||||
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
]>
|
||||
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Dialup firewalling with FreeBSD</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Marc</firstname>
|
||||
<surname>Silver</surname>
|
||||
|
||||
<affiliation>
|
||||
<address><email>marcs@draenor.org</email></address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>$Date: 2001-04-17 15:53:37 $</pubdate>
|
||||
|
||||
<abstract>
|
||||
<para>This article documents how to setup a firewall using a PPP
|
||||
dialup with FreeBSD and IPFW, and specifically with firewalling over
|
||||
a dialup with a dynamically assigned IP address. This document does
|
||||
not cover setting up your PPP connection in the first place.</para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<sect1 id="preface">
|
||||
<title>Preface</title>
|
||||
|
||||
<para>Dialup Firewalling with FreeBSD</para>
|
||||
|
||||
<para>This document aims to cover the process that is required in
|
||||
order to setup firewalling with FreeBSD when are dynamically
|
||||
assigned an IP address by your ISP. While every effort has been
|
||||
made to make this document as informative and correct as possible,
|
||||
you are welcome to mail your comments/suggestions to the
|
||||
<ulink URL="mailto:marcs@draenor.org">maintainer</ulink>.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="kernel">
|
||||
<title>Kernel Options</title>
|
||||
|
||||
<para>The first thing you'll need to do is recompile your kernel in
|
||||
FreeBSD. If you need more information on how to recompile the kernel,
|
||||
then the best place to start is the <ulink
|
||||
URL="http://www.freebsd.org/handbook/kernelconfig.html">kernel
|
||||
configuration section in the Handbook</ulink>. You need to compile the
|
||||
following options into the kernel: </para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal>options IPFIREWALL</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>Enables the kernel's firewall code.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>options IPFIREWALL_VERBOSE</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>Sends logged packets to the system logger.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>options
|
||||
IPFIREWALL_VERBOSE_LIMIT=<replaceable>100</replaceable></literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>Limits the number of times a matching entry is logged. This
|
||||
stops your log files filling up with lots of repetitive entries.
|
||||
<replaceable>100</replaceable> is a reasonable number to use, but
|
||||
you can adjust it based on your requirements.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>options IPDIVERT</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>Enables <emphasis>divert</emphasis> sockets, which will be
|
||||
shown later.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>There are also some other OPTIONAL items that you can compile
|
||||
into the kernel for some added security. These are not required in
|
||||
order to get firewalling to work, but some more paranoid users may
|
||||
want to use them.</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal>options TCP_RESTRICT_RST</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>This option blocks all TCP RST packets. This is
|
||||
best used for systems that might be exposed to SYN
|
||||
flooding (IRC Servers are a good example) or for those who
|
||||
do not want to be easily portscannable.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>options TCP_DROP_SYNFIN</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>This option ignores TCP packets with SYN and FIN. This
|
||||
prevents tools such as nmap etc from identifying the TCP/IP
|
||||
stack of the machine, but breaks support for RFC1644
|
||||
extensions. This is NOT recommended if the machine will be
|
||||
running a web server.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Don't reboot once you have recompiled the kernel. Hopefully, we will
|
||||
need to reboot just once in order to complete the installing of the
|
||||
firewall.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="rcconf">
|
||||
<title>Changing <filename>/etc/rc.conf</filename> to load the
|
||||
firewall</title>
|
||||
|
||||
<para>We now need to make some changes to
|
||||
<filename>/etc/rc.conf</filename> in order to tell it about the
|
||||
firewall. Simply add the following lines:</para>
|
||||
|
||||
<programlisting>firewall_enable="YES"
|
||||
firewall_script="/etc/firewall/fwrules"
|
||||
natd_enable="YES"
|
||||
natd_interface="tun0"
|
||||
natd_flags="-dynamic"</programlisting>
|
||||
|
||||
<para>For more information on what the above do take a look at
|
||||
<filename>/etc/defaults/rc.conf</filename> and read
|
||||
&man.rc.conf.5;</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Disable PPP's network address translation</title>
|
||||
|
||||
<para>You may already be using PPP's built in network address
|
||||
translation (NAT). If that is the case you will have to disable it,
|
||||
as these examples use &man.natd.8; to do the same.</para>
|
||||
|
||||
<para>If you already have a block of entries to
|
||||
automatically start PPP it probably looks like this:</para>
|
||||
|
||||
<programlisting>ppp_enable="YES"
|
||||
ppp_mode="auto"
|
||||
ppp_nat="YES"
|
||||
ppp_profile="<replaceable>profile</replaceable>"</programlisting>
|
||||
|
||||
<para>If so, remove the <literal>ppp_nat="YES"</literal> line. You will
|
||||
also need to remove any <literal>nat enable yes</literal> or
|
||||
<literal>alias enable yes</literal> in
|
||||
<filename>/etc/ppp/ppp.conf</filename>.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="rules">
|
||||
<title>The ruleset for the firewall</title>
|
||||
|
||||
<para>We're nearly done now. All that remains now is to define the
|
||||
firewall rules and then we can reboot and the firewall should be up and
|
||||
running. I realise that everyone will want something slightly different
|
||||
when it comes to their rulebase. What I've tried to do is write a
|
||||
rulebase that suits most dialup users. You can obviously modify it to
|
||||
your needs by simply using the following rules as the foundation for
|
||||
your own rulebase. First, let's start with the basics of closed
|
||||
firewalling. What you want to do is deny everything by default and then
|
||||
only open up for the things you really need. Rules should be in the
|
||||
order of allow first and then deny. The premise is that you add the
|
||||
rules for your allows, and then everything else is denied. :)</para>
|
||||
|
||||
<para>Now, let's make the dir /etc/firewall. Change into the directory and
|
||||
edit the file fwrules as we specified in rc.conf. Please note that you
|
||||
can change this filename to be anything you wish. This guide just gives
|
||||
an example of a filename. </para>
|
||||
|
||||
<para>Now, let's look at a sample firewall file, and we'll detail
|
||||
everything in it. </para>
|
||||
|
||||
<programlisting># Firewall rules
|
||||
# Written by Marc Silver (marcs@draenor.org)
|
||||
# http://draenor.org/ipfw
|
||||
# Freely distributable
|
||||
|
||||
|
||||
# Define the firewall command (as in /etc/rc.firewall) for easy
|
||||
# reference. Helps to make it easier to read.
|
||||
fwcmd="/sbin/ipfw"
|
||||
|
||||
# Force a flushing of the current rules before we reload.
|
||||
$fwcmd -f flush
|
||||
|
||||
# Divert all packets through the tunnel interface.
|
||||
$fwcmd add divert natd all from any to any via tun0
|
||||
|
||||
# Allow all data from my network card and localhost. Make sure you
|
||||
# change your network card (mine was fxp0) before you reboot. :)
|
||||
$fwcmd add allow ip from any to any via lo0
|
||||
$fwcmd add allow ip from any to any via fxp0
|
||||
|
||||
# Allow all connections that I initiate.
|
||||
$fwcmd add allow tcp from any to any out xmit tun0 setup
|
||||
|
||||
# Once connections are made, allow them to stay open.
|
||||
$fwcmd add allow tcp from any to any via tun0 established
|
||||
|
||||
# Everyone on the internet is allowed to connect to the following
|
||||
# services on the machine. This example shows that people may connect
|
||||
# to ssh and apache.
|
||||
$fwcmd add allow tcp from any to any 80 setup
|
||||
$fwcmd add allow tcp from any to any 22 setup
|
||||
|
||||
# This sends a RESET to all ident packets.
|
||||
$fwcmd add reset log tcp from any to any 113 in recv tun0
|
||||
|
||||
# Allow outgoing DNS queries ONLY to the specified servers.
|
||||
$fwcmd add allow udp from any to <replaceable>x.x.x.x</replaceable> 53 out xmit tun0
|
||||
|
||||
# Allow them back in with the answers... :)
|
||||
$fwcmd add allow udp from <replaceable>x.x.x.x</replaceable> 53 to any in recv tun0
|
||||
|
||||
# Allow ICMP (for ping and traceroute to work). You may wish to
|
||||
# disallow this, but I feel it suits my needs to keep them in.
|
||||
$fwcmd add 65435 allow icmp from any to any
|
||||
|
||||
# Deny all the rest.
|
||||
$fwcmd add 65435 deny log ip from any to any</programlisting>
|
||||
|
||||
<para>You now have a fully functional firewall that will allow on
|
||||
connections to ports 80 and 22 and will log any other connection
|
||||
attempts. Now, you should be able to safely reboot and your firewall
|
||||
should come up fine. If you find this incorrect in anyway or experience
|
||||
any problems, or have any suggestions to improve this page, please
|
||||
email me.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Questions</title>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>Why are you using natd and ipfw when you could be using
|
||||
the built in ppp-filters?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>I'll have to be honest and say there's no definitive reason
|
||||
why I use ipfw and natd instead of the built in ppp filters. From
|
||||
the discussions I've had with people the consensus seems to be
|
||||
that while ipfw is certainly more powerful and more configurable
|
||||
than the ppp filters, what it makes up for in functionality it
|
||||
loses in being easy to customise. One of the reasons I use it is
|
||||
because I prefer firewalling to be done at a kernel level rather
|
||||
than by a userland program.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>If I'm using private addresses internally, such as in the
|
||||
192.168.0.0 range, Could I add a command like <literal>$fwcmd add
|
||||
deny all from any to 192.168.0.0:255.255.0.0 via tun0</literal>
|
||||
to the firewall rules to prevent outside attempts to connect to
|
||||
internal machines?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>The simple answer is no. The reason for this is that natd is
|
||||
doing address translation for <emphasis>anything</emphasis> being
|
||||
diverted through the tun0 device. As far as it's concerned
|
||||
incoming packets will speak only to the dynamically assigned IP
|
||||
address and NOT to the internal network. Note though that you can
|
||||
add a rule like <literal>$fwcmd add deny all from
|
||||
192.168.0.4:255.255.0.0 to any via tun0</literal> which would
|
||||
limit a host on your internal network from going out via the
|
||||
firewall.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>There must be something wrong. I followed your instructions
|
||||
to the letter and now I am locked out.</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>This tutorial assumes that you are running
|
||||
<emphasis>userland-ppp</emphasis>, therefore the supplied ruleset
|
||||
operates on the <devicename>tun0</devicename> interface, which
|
||||
corresponds to the first connection made with &man.ppp.8; (a.k.a.
|
||||
<emphasis>user-ppp</emphasis>). Additional connections would use
|
||||
<devicename>tun1</devicename>, <devicename>tun2</devicename> and so
|
||||
on.</para>
|
||||
|
||||
<para>You should also note that &man.pppd.8; uses the
|
||||
<devicename>ppp0</devicename> interface instead, so if you start the
|
||||
connection with &man.pppd.8; you must substitute
|
||||
<devicename>tun0</devicename> for <devicename>ppp0</devicename>. A
|
||||
quick way to edit the firewall rules to reflect this change is shown
|
||||
below. The original ruleset is backed up as
|
||||
<filename>fwrules_tun0</filename>.</para>
|
||||
|
||||
<screen>
|
||||
&prompt.user; <userinput>cd /etc/firewall</userinput>
|
||||
/etc/firewall&prompt.user; <userinput>su</userinput>
|
||||
<prompt>Password:</prompt>
|
||||
/etc/firewall&prompt.root; <userinput>mv fwrules fwrules_tun0</userinput>
|
||||
/etc/firewall&prompt.root; <userinput>cat fwrules_tun0 | sed s/tun0/ppp0/g > fwrules</userinput>
|
||||
</screen>
|
||||
|
||||
<para>To know whether you are currently using &man.ppp.8; or
|
||||
&man.pppd.8; you can examine the output of &man.ifconfig.8; once the
|
||||
connection is up. E.g., for a connection made with &man.pppd.8; you
|
||||
would see something like this (showing only the relevant lines):</para>
|
||||
|
||||
<screen>
|
||||
&prompt.user; <userinput>ifconfig</userinput>
|
||||
<emphasis>(skipped...)</emphasis>
|
||||
ppp0: flags=<replaceable>8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524</replaceable>
|
||||
inet <replaceable>xxx.xxx.xxx.xxx</replaceable> --> <replaceable>xxx.xxx.xxx.xxx</replaceable> netmask <replaceable>0xff000000</replaceable>
|
||||
<emphasis>(skipped...)</emphasis>
|
||||
</screen>
|
||||
|
||||
<para>On the other hand, for a connection made with &man.ppp.8;
|
||||
(<emphasis>user-ppp</emphasis>) you should see something similar to
|
||||
this:</para>
|
||||
|
||||
<screen>
|
||||
&prompt.user; <userinput>ifconfig</userinput>
|
||||
<emphasis>(skipped...)</emphasis>
|
||||
ppp0: flags=<replaceable>8010<POINTOPOINT,MULTICAST> mtu 1500</replaceable>
|
||||
<emphasis>(skipped...)</emphasis>
|
||||
tun0: flags=<replaceable>8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524</replaceable>
|
||||
<emphasis>(IPv6 stuff skipped...)</emphasis>
|
||||
inet <replaceable>xxx.xxx.xxx.xxx</replaceable> --> <replaceable>xxx.xxx.xxx.xxx</replaceable> netmask <replaceable>0xffffff00</replaceable>
|
||||
Opened by PID <replaceable>xxxxx</replaceable>
|
||||
<emphasis>(skipped...)</emphasis>
|
||||
</screen>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
</qandaset>
|
||||
</sect1>
|
||||
</article>
|
||||
@ -1,14 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,349 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/articles/diskless-x/article.sgml,v 1.3 1999/11/15 22:55:44 phantom Exp $
|
||||
-->
|
||||
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
]>
|
||||
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Diskless X Server: a how to guide</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname> Jerry</firstname>
|
||||
<surname>Kendall</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>jerry@kcis.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author></authorgroup>
|
||||
|
||||
<pubdate>28-December-1996</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>1996</year>
|
||||
<holder>Jerry Kendall</holder>
|
||||
</copyright>
|
||||
|
||||
<abstract>
|
||||
<para>With the help of some friends on the FreeBSD-hackers list, I have
|
||||
been able to create a diskless X terminal. The creation of the X
|
||||
terminal required first creating a diskless system with minimal
|
||||
utilities mounted via NFS. These same steps were used to create 2
|
||||
separate diskless systems. The first is <hostid
|
||||
role="fqdn">altair.kcis.com</hostid>. A diskless X terminal that I
|
||||
run on my old 386DX-40. It has a 340Meg hard disk but, I did not want
|
||||
to change it. So, it boots from <hostid
|
||||
role="fqdn">antares.kcis.com</hostid> across a Ethernet. The second
|
||||
system is a 486DX2-66. I setup a diskless FreeBSD (complete) that
|
||||
uses no local disk. The server in that case is a Sun 670MP running
|
||||
SunOS 4.1.3. The same setup configuration was needed for both.</para>
|
||||
|
||||
<para>I am sure that there is stuff that needs to be added
|
||||
to this. Please send me any comments.</para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<sect1>
|
||||
<title>Creating the boot floppy (On the diskless system)</title>
|
||||
|
||||
<para>Since the network boot loaders will not work with some of the TSR's
|
||||
and such that MS-DOS uses, it is best to create a dedicated boot floppy
|
||||
or, if you can, create an MS-DOS menu that will (via the
|
||||
<filename>config.sys</filename>/<filename>autoexec.bat</filename> files)
|
||||
ask what configuration to load when the system starts. The later is the
|
||||
method that I use and it works great. My MS-DOS (6.x) menu is
|
||||
below.</para>
|
||||
|
||||
<example>
|
||||
<title><filename>config.sys</filename></title>
|
||||
|
||||
<programlisting>[menu]
|
||||
menuitem=normal, normal
|
||||
menuitem=unix, unix
|
||||
[normal]
|
||||
....
|
||||
normal config.sys stuff
|
||||
...
|
||||
[unix]</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title><filename>autoexec.bat</filename></title>
|
||||
|
||||
<programlisting>@ECHO OFF
|
||||
goto %config%
|
||||
|
||||
:normal
|
||||
...
|
||||
normal autoexec.bat stuff
|
||||
...
|
||||
goto end
|
||||
|
||||
:unix
|
||||
cd \netboot
|
||||
nb8390.com
|
||||
|
||||
:end</programlisting>
|
||||
</example>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Getting the network boot programs (On the server)</title>
|
||||
|
||||
<para>Compile the 'net-boot' programs that are located in
|
||||
<filename>/usr/src/sys/i386/boot/netboot</filename>. You should read
|
||||
the comments at the top of the <filename>Makefile</filename>. Adjust as
|
||||
required. Make a backup of the original in case it gets foobar'd. When
|
||||
the build is done, there should be 2 MS-DOS executables,
|
||||
<filename>nb8390.com</filename> and <filename>nb3c509.com</filename>.
|
||||
One of these two programs will be what you need to run on the diskless
|
||||
server. It will load the kernel from the boot server. At this point,
|
||||
put both programs on the MS-DOS boot floppy created earlier.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Determine which program to run (On the diskless system)</title>
|
||||
|
||||
<para>If you know the chipset that your Ethernet adapter uses, this is
|
||||
easy. If you have the NS8390 chipset, or a NS8390 based chipset, use
|
||||
<filename>nb8390.com</filename>. If you have a 3Com 509 based chipset,
|
||||
use the <filename>nb3C509.com</filename> boot program. If you are not
|
||||
sure which you have, try using one, if it says <errorname>No adapter
|
||||
found</errorname>, try the other. Beyond that, you are pretty much on
|
||||
your own.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Booting across the network</title>
|
||||
|
||||
<para>Boot the diskless system with out any config.sys/autoexec.bat
|
||||
files. try running the boot program for your Ethernet adapter.</para>
|
||||
|
||||
<para>My Ethernet adapter is running in WD8013 16bit mode so I run
|
||||
<filename>nb8390.com</filename></para>
|
||||
|
||||
<screen><prompt>C:></prompt> <userinput>cd \netboot</userinput>
|
||||
<prompt>C:></prompt> <userinput>nb8390</userinput>
|
||||
|
||||
<prompt>Boot from Network (Y/N) ?</prompt> <userinput>Y</userinput>
|
||||
|
||||
BOOTP/TFTP/NFS bootstrap loader ESC for menu
|
||||
|
||||
Searching for adapter..
|
||||
WD8013EBT base 0x0300, memory 0x000D8000, addr 00:40:01:43:26:66
|
||||
|
||||
Searching for server...</screen>
|
||||
|
||||
<para>At this point, my diskless system is trying to find a machine to act
|
||||
as a boot server. Make note of the <literal>addr</literal> line above,
|
||||
you will need this number later. Reset the diskless system and modify
|
||||
your <filename>config.sys</filename> and
|
||||
<filename>autoexec.bat</filename> files to do these steps automatically
|
||||
for you. Perhaps in a menu. If you had to run
|
||||
<command>nb3c509.com</command> instead of <command>nb8390.com</command>
|
||||
the output is the same as above. If you got <errorname>No adapter
|
||||
found</errorname> at the <literal>Searching for adapter...</literal>
|
||||
message, verify that you did indeed set the compile time defines in the
|
||||
<filename>Makefile</filename> correctly.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Allowing systems to boot across the network (On the server)</title>
|
||||
|
||||
<para>Make sure the <filename>/etc/inetd.conf</filename> file has entries
|
||||
for tftp and bootps. Mine are listed below:</para>
|
||||
|
||||
<programlisting>tftp dgram udp wait nobody /usr/libexec/tftpd tftpd /tftpboot
|
||||
#
|
||||
# Additions by who ever you are
|
||||
bootps dgram udp wait root /usr/libexec/bootpd bootpd /etc/bootptab</programlisting>
|
||||
|
||||
<para>If you have to change the <filename>/etc/inetd.conf</filename> file,
|
||||
send a <literal>HUP</literal> signal to inetd. To do this, get the
|
||||
process ID of inetd with <command>ps -ax | grep inetd | grep -v
|
||||
grep</command>. Once you have it, send it a HUP signal. Do this by
|
||||
<command>kill -HUP <pid></command>. This will force inetd to
|
||||
re-read its config file.</para>
|
||||
|
||||
<para>Did you remember to note the <literal>addr</literal> line from the
|
||||
output of the boot loader on the diskless system? Guess what, here is
|
||||
where you need it.</para>
|
||||
|
||||
<para>Add an entry to <literal>/etc/bootptab</literal> (maybe creating the
|
||||
file). It should be laid out identical to this:</para>
|
||||
|
||||
<programlisting>altair:\
|
||||
:ht=ether:\
|
||||
:ha=004001432666:\
|
||||
:sm=255.255.255.0:\
|
||||
:hn:\
|
||||
:ds=199.246.76.1:\
|
||||
:ip=199.246.76.2:\
|
||||
:gw=199.246.76.1:\
|
||||
:vm=rfc1048:</programlisting>
|
||||
|
||||
<para>The lines are as follows:</para>
|
||||
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><literal>altair</literal></entry>
|
||||
<entry>the diskless systems name without the domain name.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>ht=ether</literal></entry>
|
||||
<entry>the hardware type of 'ethernet'.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>ha=004001432666</literal></entry>
|
||||
<entry>the hardware address (the number noted above).</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>sm=255.255.255.0</literal></entry>
|
||||
<entry>the subnet mask.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>hn</literal></entry>
|
||||
<entry>tells server to send client's hostname to the
|
||||
client.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>ds=199.246.76.1</literal></entry>
|
||||
<entry>tells the client who the domain server is.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>ip=199.246.76.2</literal></entry>
|
||||
<entry>tells the client what it's IP address is.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>gw=199.246.76.1</literal></entry>
|
||||
<entry>tells the client what the default gateway is.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><literal>vm=...</literal></entry>
|
||||
<entry>just leave it there.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<note>
|
||||
<para>Be sure to setup the IP addresses correctly, the addresses above
|
||||
are my own.</para>
|
||||
</note>
|
||||
|
||||
<para>Create the directory '/tftpboot' on the server it will contain the
|
||||
configuration files for the diskless systems that the server will serve.
|
||||
These files will be named 'cfg.<ip>' where <ip> is the IP
|
||||
address of the diskless system. The config file for 'altair' is
|
||||
/tftpboot/cfg.199.246.76.2. The contents is:</para>
|
||||
|
||||
<programlisting>rootfs 199.246.76.1:/DiskLess/rootfs/altair
|
||||
hostname altair.kcis.com</programlisting>
|
||||
|
||||
<para>The line <literal>hostname altair.kcis.com</literal> simply tells
|
||||
the diskless system what its fully qualified domain name is.</para>
|
||||
|
||||
<para>The line <literal>rootfs
|
||||
199.246.76.1:/DiskLess/rootfs/altair</literal> tells the diskless
|
||||
system where its NFS mountable root filesystem is located.</para>
|
||||
|
||||
<note>
|
||||
<para>The NFS mounted root filesystem will be mounted <emphasis>read
|
||||
only</emphasis>.</para>
|
||||
</note>
|
||||
|
||||
<para>The hierarchy for the diskless system can be re-mounted allowing
|
||||
read-write operations if required.</para>
|
||||
|
||||
<para>I use my spare 386DX-40 as a dedicated X terminal.</para>
|
||||
|
||||
<para>The hierarchy for 'altair' is:</para>
|
||||
|
||||
<literallayout>/
|
||||
/bin
|
||||
/etc
|
||||
/tmp
|
||||
/sbin
|
||||
/dev
|
||||
/dev/fd
|
||||
/usr
|
||||
/var
|
||||
/var/run</literallayout>
|
||||
|
||||
<para>The actual list of files is:</para>
|
||||
|
||||
<screen>-r-xr-xr-x 1 root wheel 779984 Dec 11 23:44 ./kernel
|
||||
-r-xr-xr-x 1 root bin 299008 Dec 12 00:22 ./bin/sh
|
||||
-rw-r--r-- 1 root wheel 499 Dec 15 15:54 ./etc/rc
|
||||
-rw-r--r-- 1 root wheel 1411 Dec 11 23:19 ./etc/ttys
|
||||
-rw-r--r-- 1 root wheel 157 Dec 15 15:42 ./etc/hosts
|
||||
-rw-r--r-- 1 root bin 1569 Dec 15 15:26 ./etc/XF86Config.altair
|
||||
-r-x------ 1 bin bin 151552 Jun 10 1995 ./sbin/init
|
||||
-r-xr-xr-x 1 bin bin 176128 Jun 10 1995 ./sbin/ifconfig
|
||||
-r-xr-xr-x 1 bin bin 110592 Jun 10 1995 ./sbin/mount_nfs
|
||||
-r-xr-xr-x 1 bin bin 135168 Jun 10 1995 ./sbin/reboot
|
||||
-r-xr-xr-x 1 root bin 73728 Dec 13 22:38 ./sbin/mount
|
||||
-r-xr-xr-x 1 root wheel 1992 Jun 10 1995 ./dev/MAKEDEV.local
|
||||
-r-xr-xr-x 1 root wheel 24419 Jun 10 1995 ./dev/MAKEDEV</screen>
|
||||
|
||||
<para>Don't forget to run <command>MAKEDEV all</command> in the
|
||||
<filename>dev</filename> directory.</para>
|
||||
|
||||
<para>My <filename>/etc/rc</filename> for <hostid>altair</hostid>
|
||||
is:</para>
|
||||
|
||||
<programlisting>#!/bin/sh
|
||||
#
|
||||
PATH=/bin:/
|
||||
export PATH
|
||||
#
|
||||
# configure the localhost
|
||||
/sbin/ifconfig lo0 127.0.0.1
|
||||
#
|
||||
# configure the ethernet card
|
||||
/sbin/ifconfig ed0 199.246.76.2 netmask 0xffffff00
|
||||
#
|
||||
# mount the root filesystem via NFS
|
||||
/sbin/mount antares:/DiskLess/rootfs/altair /
|
||||
#
|
||||
# mount the /usr filesystem via NFS
|
||||
/sbin/mount antares:/DiskLess/usr /usr
|
||||
#
|
||||
/usr/X11R6/bin/XF86_SVGA -query antares -xf86config /etc/XF86Config.altair > /dev/null 2>&1
|
||||
#
|
||||
# Reboot after X exits
|
||||
/sbin/reboot
|
||||
#
|
||||
# We blew up....
|
||||
exit 1</programlisting>
|
||||
|
||||
<para>Any comments and all questions welcome.</para>
|
||||
</sect1>
|
||||
</article>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
End:
|
||||
-->
|
||||
@ -1,23 +0,0 @@
|
||||
#
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/articles/freebsd-questions/Makefile,v 1.1 2001/02/16 00:22:33 nik Exp $
|
||||
#
|
||||
|
||||
MAINTAINER=grog@FreeBSD.org
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?= gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
#
|
||||
# SRCS lists the individual SGML files that make up the document. Changes
|
||||
# to any of these files will force a rebuild
|
||||
#
|
||||
|
||||
# SGML content
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,542 +0,0 @@
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
]>
|
||||
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Explaining BSD</title>
|
||||
|
||||
<author>
|
||||
<firstname>Greg</firstname>
|
||||
<surname>Lehey</surname>
|
||||
|
||||
<affiliation>
|
||||
<address><email>grog@FreeBSD.org</email></address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<abstract>
|
||||
<para>In the open source world, the word <quote>Linux</quote> is almost
|
||||
synonymous with <quote>Operating System</quote>, but it's not the only
|
||||
open source <trademark>UNIX</trademark> operating system. According
|
||||
to the <ulink
|
||||
url="http://www.leb.net/hzo/ioscount/data/r.9904.txt">Internet
|
||||
Operating System Counter</ulink>, as of April 1999 31.3% of the
|
||||
world's network connected machines run Linux. 14.6% run BSD UNIX.
|
||||
Some of the world's largest web operations, such as <ulink
|
||||
url="http://www.yahoo.com">Yahoo!</ulink>, run BSD. The world's
|
||||
busiest ftp server, <ulink
|
||||
url="ftp://ftp.cdrom.com">ftp.cdrom.com</ulink>, uses BSD to
|
||||
transfer 1.4 TB of data a day. Clearly this is not a niche
|
||||
market: BSD is a well-kept secret.</para>
|
||||
|
||||
<para>So what's the secret? Why isn't BSD better known? This white
|
||||
paper addresses these and other questions.</para>
|
||||
|
||||
<para>Throughout this paper, differences between BSD and Linux will be
|
||||
noted <emphasis>like this</emphasis>.</para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<sect1>
|
||||
<title>What is BSD?</title>
|
||||
|
||||
<para>BSD stands for <quote>Berkeley Software Distribution</quote>. It is
|
||||
the name of distributions of source code from the University of
|
||||
California, Berkeley, which were originally extensions to AT&T's
|
||||
Research UNIX operating system. Several open source operating system
|
||||
projects are based on a release of this source code known as
|
||||
4.4BSD-Lite. In addition, they comprise a number of packages from other
|
||||
Open Source projects, including notably the GNU project. The overall
|
||||
operating system comprises:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The BSD kernel, which handles process scheduling, memory
|
||||
management, symmetric multi-processing (SMP), device drivers,
|
||||
etc.</para>
|
||||
|
||||
<para><emphasis>Unlike the Linux kernel, there are several different
|
||||
BSD kernels with differing capabilities.</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The C library, the base API for the system.</para>
|
||||
|
||||
<para><emphasis>The BSD C library is based on code from Berkeley, not
|
||||
the GNU project.</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Utilities such as shells, file utilities, compilers and
|
||||
linkers.</para>
|
||||
|
||||
<para><emphasis>Some of the utilities are derived from the GNU
|
||||
project, others are not.</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The X Window system, which handles graphical display.</para>
|
||||
|
||||
<para>The X Window system used in most versions of BSD is maintained
|
||||
by a separate project, the
|
||||
<ulink url="http://www.XFree86.org/">XFree86 project</ulink>.
|
||||
This is the same code as Linux uses. BSD does not normally
|
||||
specify a <quote>graphical desktop</quote> such as GNOME or KDE,
|
||||
though these are available.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Many other programs and utilities.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>What, a real UNIX?</title>
|
||||
|
||||
<para>The BSD operating systems are not clones, but open source
|
||||
derivatives of AT&T's Research UNIX operating system, which is also
|
||||
the ancestor of the modern UNIX System V. This may surprise you. How
|
||||
could that happen when AT&T has never released its code as open
|
||||
source?</para>
|
||||
|
||||
<para>It's true that AT&T UNIX is not open source, and in a copyright
|
||||
sense BSD is very definitely <emphasis>not</emphasis> UNIX, but on the
|
||||
other hand, AT&T has imported sources from other projects,
|
||||
noticeably the Computer Sciences Research Group of the University of
|
||||
California in Berkeley, CA. Starting in 1976, the CSRG started
|
||||
releasing tapes of their software, calling them <emphasis>Berkeley
|
||||
Software Distribution</emphasis> or <emphasis>BSD</emphasis>.</para>
|
||||
|
||||
<para>Initial BSD releases consisted mainly of user programs, but that
|
||||
changed dramatically when the CSRG landed a contract with the Defense
|
||||
Advanced Projects Research Agency (DARPA) to upgrade the communications
|
||||
protocols on their network, ARPANET. The new protocols were known as
|
||||
the <emphasis>Internet Protocols</emphasis>, later
|
||||
<emphasis>TCP/IP</emphasis> after the most important protocols. The
|
||||
first widely distributed implementation was part of 4.2BSD, in
|
||||
1982.</para>
|
||||
|
||||
<para>In the course of the 1980s, a number of new workstation companies
|
||||
sprang up. Many preferred to license UNIX rather than developing
|
||||
operating systems for themselves. In particular, Sun Microsystems
|
||||
licensed UNIX and implemented a version of 4.2BSD, which they called
|
||||
SunOS. When AT&T themselves were allowed to sell UNIX commercially,
|
||||
they started with a somewhat bare-bones implementation called System
|
||||
III, to be quickly followed by System V. The System V code base did not
|
||||
include networking, so all implementions included additional software
|
||||
from the BSD, including the TCP/IP software, but also utilities such as
|
||||
the <emphasis>csh</emphasis> shell and the <emphasis>vi</emphasis>
|
||||
editor. Collectively, these enhancements were known as the
|
||||
<emphasis>Berkeley Extensions</emphasis>.</para>
|
||||
|
||||
<para>The BSD tapes contained AT&T source code and thus required a
|
||||
UNIX source license. By 1990, the CSRG's funding was running out, and
|
||||
it faced closure. Some members of the group decided to release the BSD
|
||||
code, which was Open Source, without the AT&T proprietary code.
|
||||
This finally happened with the <emphasis>Networking Tape 2</emphasis>,
|
||||
usually known as <emphasis>Net/2</emphasis>. Net/2 was not a complete
|
||||
operating system: about 20% of the kernel code was missing. One of the
|
||||
CSRG members, William F. Jolitz, wrote the remaining code and released
|
||||
it in early 1992 as <emphasis>386BSD</emphasis>. At the same time,
|
||||
another group of ex-CSRG members formed a commercial company called
|
||||
<ulink url="http://www.bsdi.com">Berkeley Software Design Inc.</ulink>
|
||||
and released a beta version of an operating system called
|
||||
<ulink url="http://www.bsdi.com">BSD/386</ulink>, which was based on
|
||||
the same sources. The name of the operating system has since changed
|
||||
to BSD/OS.</para>
|
||||
|
||||
<para>386BSD never became a stable operating system. Instead, two other
|
||||
projects split off from it in 1993:
|
||||
<ulink url="http://www.NetBSD.org">NetBSD</ulink> and
|
||||
<ulink url="http://www.FreeBSD.org">FreeBSD</ulink>. The two projects
|
||||
originally diverged due to differences in patience waiting for
|
||||
improvements to 386BSD: the NetBSD people started early in the year,
|
||||
and the first version of FreeBSD wasn't ready until the end of the
|
||||
year. In the meantime, the code base had diverged sufficiently to
|
||||
make it difficult to merge. In addition, the projects had different
|
||||
aims, as we'll see below. In 1996, a further project,
|
||||
<ulink url="http://www.OpenBSD.org">OpenBSD</ulink>, split off from
|
||||
NetBSD.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Why isn't BSD better known?</title>
|
||||
|
||||
<para>For a number of reasons, BSD is relatively unknown:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>The BSD developers are often more interested in polishing their
|
||||
code than marketing it.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Much of Linux's popularity is due to factors external to the
|
||||
Linux projects, such as the press, and to companies formed to
|
||||
provide Linux services. Until recently, the open source BSDs had no
|
||||
such proponents.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD developers tend to be more experienced than Linux
|
||||
developers, and have less interest in making the system easy to use.
|
||||
Newcomers tend to feel more comfortable with Linux.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>In 1992, AT&T sued
|
||||
<ulink url="http://www.bsdi.com">BSDI</ulink>,
|
||||
the vendor of BSD/386, alleging that the product contained
|
||||
AT&T-copyrighted code. The case was settled out of court in
|
||||
1994, but the spectre of the litigation continues to haunt people.
|
||||
As recently as March 2000 an article published on the web claimed
|
||||
that the court case had been <quote>recently settled</quote>.</para>
|
||||
|
||||
<para>One detail that the lawsuit did clarify is the naming: in the
|
||||
1980s, BSD was known as <quote>BSD UNIX</quote>. With the
|
||||
elimination of the last vestige of AT&T code from BSD, it
|
||||
also lost the right to the name UNIX. Thus you will see
|
||||
references in book titles to <quote>the 4.3BSD UNIX operating
|
||||
system</quote> and <quote>the 4.4BSD operating
|
||||
system</quote>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>There is a perception that the BSD projects are fragmented and
|
||||
belligerent. The
|
||||
<ulink url="http://interactive.wsj.com/bin/login?Tag=/&URI=/archive/retrieve.cgi%253Fid%253DSB952470579348918651.djm&">Wall Street
|
||||
Journal</ulink> spoke of <quote>balkanization</quote> of the
|
||||
BSD projects. Like the law suit, this perception bases mainly
|
||||
on ancient history.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Comparing BSD and Linux</title>
|
||||
|
||||
<para>So what's really the difference between, say, Debian Linux and
|
||||
FreeBSD? For the average user, the difference is surprisingly small:
|
||||
Both are UNIX-like operating systems. Both are developed by
|
||||
non-commercial projects (this doesn't apply to many other Linux
|
||||
distributions, of course). In the following section, we'll look at BSD
|
||||
and compare it to Linux. The description applies most closely to
|
||||
FreeBSD, which accounts for an estimated 80% of the BSD installations,
|
||||
but the differences from NetBSD and OpenBSD are small.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Who owns BSD?</title>
|
||||
|
||||
<para>No one person or corporation owns BSD. It is created and
|
||||
distributed by a community of highly technical and committed
|
||||
contributors all over the world. Some of the components of BSD are
|
||||
Open Source projects managed by a different project maintainer.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>How is BSD developed and updated?</title>
|
||||
|
||||
<para>The BSD kernels are developed and updated following the Open
|
||||
Source development model. Each project maintains a publicly
|
||||
accessible <emphasis>source tree</emphasis> under the
|
||||
<ulink url="http://www.sourcegear.com/CVS">Concurrent Versions
|
||||
System</ulink> (CVS), which contains all source files for the
|
||||
project, including documentation and other incidental files. CVS
|
||||
allows users to <quote>check out</quote> (in other words, to
|
||||
extract a copy of) any desired version of the system.</para>
|
||||
|
||||
<para>A large number of developers worldwide contribute to improvements
|
||||
to BSD. They are divided into three kinds:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis>Contributors</emphasis> write code or documentation.
|
||||
They are not permitted to commit (add code) directly to the source
|
||||
tree. In order for their code to be included in the system, it
|
||||
must be reviewed and checked in by a registered developer, known
|
||||
as a <emphasis>committer</emphasis>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Committers</emphasis> are developers with write
|
||||
access to the source tree. In order to become a committer, an
|
||||
individual must show ability in the area in which he is
|
||||
active.</para>
|
||||
|
||||
<para>
|
||||
It is at the individual committer's discretion whether he should
|
||||
obtain authority before committing changes to the source tree. In
|
||||
general, an experienced committer may make changes which are
|
||||
obviously correct without obtaining consensus. For example, a
|
||||
documentation project committer may correct typographical or
|
||||
grammatical errors without review. On the other hand, developers
|
||||
making far-reaching or complicated changes are expected to submit
|
||||
their changes for review before committing them. In extreme
|
||||
cases, a core team member with a function such as Principal
|
||||
Architect may order that changes be removed from the tree, a
|
||||
process known as <emphasis>backing out</emphasis>. All committers
|
||||
receive mail describing each individual commit, so it is not
|
||||
possible to commit secretly.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Core team</emphasis> In addition, FreeBSD
|
||||
and NetBSD each have a core team which manages the project. The
|
||||
core teams developed in the course of the projects, and their role
|
||||
is not always well-defined. It is not necessary to be a developer
|
||||
in order to be a core team member, though it is normal. The rules
|
||||
for the core team vary from one project to the other, but in
|
||||
general they have more say in the direction of the project than
|
||||
non-core team members have.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>This arrangement differs from Linux in a number of ways:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>No one person controls the content of the system. In
|
||||
practice, this difference is overrated, since the Chief Architect
|
||||
can require that code be backed out, and even in the Linux project
|
||||
several people are permitted to make changes.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>On the other hand, there <emphasis>is</emphasis> a central
|
||||
repository, a single place where you can find the entire operating
|
||||
system sources, including all older versions.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD projects maintain the entire <quote>Operating
|
||||
System</quote>, not only the kernel. This distinction is only
|
||||
marginally useful: neither BSD nor Linux is useful without
|
||||
applications. The applications used under BSD are frequently the
|
||||
same as the applications used under Linux.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>As a result of the formalized maintenance of a single CVS
|
||||
source tree, BSD development is clear, and it is possible to
|
||||
access any version of the system by release number or by date.
|
||||
CVS also allows incremental updates to the system: for example,
|
||||
the FreeBSD repository is updated about 100 times a day. Most of
|
||||
these changes are small.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>BSD releases</title>
|
||||
|
||||
<para>Each BSD project provides the system in three different
|
||||
<quote>releases</quote>. As with Linux, releases are assigned a
|
||||
number such as 1.4.1 or 3.5. In addition, the version number has a
|
||||
suffix indicating its purpose:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>The development version of the system is called
|
||||
<emphasis>CURRENT</emphasis>. FreeBSD assigns a number to
|
||||
CURRENT, for example FreeBSD 5.0-CURRENT. NetBSD uses a slightly
|
||||
different naming scheme and appends a single-letter suffix which
|
||||
indicates changes in the internal interfaces, for example NetBSD
|
||||
1.4.3G. OpenBSD does not assign a number ("OpenBSD-current").
|
||||
All new development on the system goes into this branch.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>At regular intervals, between two and four times a year, the
|
||||
projects bring out a <emphasis>RELEASE</emphasis> version of the
|
||||
system, which is available on CD-ROM and for free download from
|
||||
ftp sites, for example OpenBSD 2.6-RELEASE or NetBSD 1.4-RELEASE.
|
||||
The RELEASE version is intended for end users and is the normal
|
||||
version of the system. NetBSD also provides <emphasis>patch
|
||||
releases</emphasis> with a third digit, for example NetBSD
|
||||
1.4.2.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>As bugs are found in a RELEASE version, they are fixed, and
|
||||
the fixes are added to the CVS tree. In FreeBSD, the resultant
|
||||
version is called the STABLE version, while in NetBSD and OpenBSD
|
||||
it continues to be called the RELEASE version. Smaller new
|
||||
features can also be added to this branch after a period of test
|
||||
in the CURRENT branch.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para><emphasis>By contrast, Linux maintains two separate code trees:
|
||||
the stable version and the development version. Stable versions
|
||||
have an even minor version number, such as 2.0, 2.2 or 2.4.
|
||||
Development versions have an odd minor version number, such as 2.1,
|
||||
2.3 or 2.5. In each case, the number is followed by a further
|
||||
number designating the exact release. In addition, each vendor adds
|
||||
their own userland programs and utilities, so the name of the
|
||||
distribution is also important. Each distribution vendor also
|
||||
assigns version numbers to the distribution, so a complete
|
||||
description might be something like <quote>TurboLinux 6.0 with kernel
|
||||
2.2.14</quote></emphasis></para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>What versions of BSD are available?</title>
|
||||
|
||||
<para>In contrast to the numerous Linux distributions, there are only
|
||||
three open source BSDs. Each BSD project maintains its own source
|
||||
tree and its own kernel. In practice, though, there appear to be
|
||||
fewer divergences between the userland code of the projects than there
|
||||
is in Linux.</para>
|
||||
|
||||
<para>It's difficult to categorize the goals of each project: the
|
||||
differences are very subjective. Basically,</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>FreeBSD aims for high performance and ease of use by
|
||||
end users, and is a favourite of web content providers. It runs
|
||||
on PCs and Compaq's Alpha processors. The FreeBSD project has
|
||||
significantly more users than the other projects.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>NetBSD aims for maximum portability: <quote>of course it runs
|
||||
NetBSD</quote>. It runs on machines from palmtops to large
|
||||
servers, and has even been used on NASA space missions. It is a
|
||||
particularly good choice for running on old non-Intel
|
||||
hardware.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>OpenBSD aims for security and code purity: it uses a
|
||||
combination of the open source concept and rigorous code reviews
|
||||
to create a system which is demonstrably correct, making it the
|
||||
choice of security-conscious organizations such as banks, stock
|
||||
exchanges and US Government departments. Like NetBSD, it runs on
|
||||
a number of platforms.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>There are also two additional BSD operating systems which are not
|
||||
open source, BSD/OS and Apple's Mac OS X:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>BSD/OS is the oldest of the 4.4BSD derivatives. It
|
||||
is not open source, though source code licenses are available at
|
||||
relatively low cost. It resembles FreeBSD in many ways.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="http://www.apple.com/macosx/server/">Mac OS
|
||||
X</ulink> is the latest version of the operating system for
|
||||
<ulink url="http://www.apple.com">Apple Computer Inc.'s</ulink>
|
||||
Macintosh line. Unlike the rest of the operating system, the
|
||||
kernel is open source. As part of this development, key Apple
|
||||
developers have commit access to the FreeBSD source tree.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>How does the BSD license differ from the GNU Public
|
||||
license?</title>
|
||||
|
||||
<para>Linux is available under the
|
||||
<ulink url="http://www.fsf.org/copyleft/gpl.html">GNU General Public
|
||||
License</ulink> (GPL), which is designed to eliminate closed
|
||||
source software. In particular, any derivative work of a product
|
||||
released under the GPL must also be supplied with source code if
|
||||
requested. By contrast, the
|
||||
<ulink url="http://www.opensource.org/licenses/bsd-license.html">BSD
|
||||
license</ulink> is less restrictive: binary-only distributions are
|
||||
allowed. This is particularly attractive for embedded
|
||||
applications.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>What else should I know?</title>
|
||||
|
||||
<para>Since fewer applications are available for BSD than Linux, the BSD
|
||||
developers created a Linux compatibility package, which allows Linux
|
||||
programs to run under BSD. The package includes both kernel
|
||||
modifications, in order to correctly perform Linux system calls, and
|
||||
Linux compatibility files such as the C library. There is no
|
||||
noticeable difference in execution speed between a Linux application
|
||||
running on a Linux machine and a Linux application running on a BSD
|
||||
machine of the same speed.</para>
|
||||
|
||||
<para>The <quote>all from one supplier</quote> nature of BSD means that
|
||||
upgrades are much easier to handle than is frequently the case with
|
||||
Linux. BSD handles library version upgrades by providing
|
||||
compatibility modules for earlier library versions, so it is possible
|
||||
to run binaries which are several years old with no problems.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Which should I use, BSD or Linux?</title>
|
||||
|
||||
<para>What does this all mean in practice? Who should use BSD, who
|
||||
should use Linux?</para>
|
||||
|
||||
<para>This is a very difficult question to answer. Here are some
|
||||
guidelines:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><quote>If it ain't broke, don't fix it</quote>: If you already
|
||||
use an open source operating system, and you are happy with it,
|
||||
there's probably no good reason to change.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD systems, in particular FreeBSD, can have notably higher
|
||||
performance than Linux. But this isn't across the board. In many
|
||||
cases, there is little or no difference in performance. In some
|
||||
cases, Linux may perform better than FreeBSD.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>In general, BSD systems have a better reputation for
|
||||
reliability, mainly as a result of the more mature code
|
||||
base.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The BSD license may be more attractive than the GPL.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD can execute Linux code, while Linux can't execute BSD
|
||||
code. As a result, more software is available for BSD than for
|
||||
Linux.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Who provides support, service, and training for BSD?</title>
|
||||
|
||||
<para>BSDi have always supported BSD/OS, and they have recently
|
||||
announced support contracts for FreeBSD.</para>
|
||||
|
||||
<para>In addition, each of the projects has a list of consultants for
|
||||
hire:
|
||||
<ulink url="http://www.freebsd.org/commercial/consulting_bycat.html">FreeBSD</ulink>,
|
||||
<ulink url="http://www.netbsd.org/gallery/consultants.html">NetBSD</ulink>,
|
||||
and <ulink url="http://www.openbsd.org/support.html">OpenBSD</ulink>.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</article>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
End:
|
||||
-->
|
||||
@ -1,14 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,988 +0,0 @@
|
||||
<!-- $FreeBSD: doc/en_US.ISO_8859-1/articles/fonts/article.sgml,v 1.14 2001/04/17 15:53:37 nik Exp $ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
]>
|
||||
|
||||
<!-- Recently, I wanted to figure out how to use some additional fonts that
|
||||
I had accumulated. I finally figured out *how to do it* from the various
|
||||
man pages and documentation. Since it might be of use to other users,
|
||||
and I didn't see any reference to this topic in the FAQ or handbook, I
|
||||
thought I'd try my hand at a simple cookbook tutorial addressing the
|
||||
use of fonts. I have included my unanswered questions at the end of
|
||||
the document.
|
||||
|
||||
Anyway, here's what I put together. This is my present understanding of
|
||||
fonts and how to use them with FreeBSD. I am sure that there are errors or
|
||||
misunderstandings, but it contains enough valid information to allow the
|
||||
use of additional fonts with Ghostscript, X11 and Groff. This is my first
|
||||
attempt to write anything along the lines of a tutorial/FAQ, so I am sure
|
||||
it is pretty raw. There are probably better ways to do some of this stuff,
|
||||
and I would welcome being corrected.
|
||||
-->
|
||||
|
||||
<!-- The section "Setting a virtual console to 80x60 line mode" was
|
||||
updated to reflect changes in FreeBSD system configuration
|
||||
files by Mark Ovens <mark@ukug.uk.freebsd.org> 27/5/00
|
||||
-->
|
||||
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Fonts and FreeBSD</title>
|
||||
|
||||
<subtitle>A Tutorial</subtitle>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Dave</firstname>
|
||||
|
||||
<surname>Bodenstab</surname>
|
||||
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>imdave@synet.net</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>Wed Aug 7, 1996</pubdate>
|
||||
|
||||
<abstract>
|
||||
<para>This document contains a description of the various font
|
||||
files that may be used with FreeBSD and the syscons driver,
|
||||
X11, Ghostscript and Groff. Cookbook examples are provided
|
||||
for switching the syscons display to 80x60 mode, and for using
|
||||
type 1 fonts with the above application programs.</para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<sect1>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>There are many sources of fonts available, and one might ask
|
||||
how they might be used with FreeBSD. The answer can be found by
|
||||
carefully searching the documentation for the component that one
|
||||
would like to use. This is very time consuming, so this
|
||||
tutorial is an attempt to provide a shortcut for others who
|
||||
might be interested.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Basic terminology</title>
|
||||
|
||||
<para>There are many different font formats and associated font
|
||||
file suffixes. A few that will be addressed here are:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><filename>.pfa</filename>, <filename>.pfb</filename></term>
|
||||
|
||||
<listitem>
|
||||
<para>Postscript type 1 fonts. The
|
||||
<filename>.pfa</filename> is the
|
||||
<emphasis>A</emphasis>scii form and
|
||||
<filename>.pfb</filename> the <emphasis>B</emphasis>inary
|
||||
form.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>.afm</filename></term>
|
||||
|
||||
<listitem>
|
||||
<para>The font metrics associated with a type 1 font.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>.pfm</filename></term>
|
||||
|
||||
<listitem>
|
||||
<para>The printer font metrics associated with a type 1
|
||||
font.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>.ttf</filename></term>
|
||||
|
||||
<listitem>
|
||||
<para>A TrueType font</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>.fot</filename></term>
|
||||
|
||||
<listitem>
|
||||
<para>An indirect reference to a TrueType font (not an
|
||||
actual font)</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><filename>.fon</filename>, <filename>.fnt</filename></term>
|
||||
|
||||
<listitem>
|
||||
<para>Bitmapped screen fonts</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>The <filename>.fot</filename> file is used by Windows as
|
||||
sort of a symbolic link to the actual TrueType font
|
||||
(<filename>.ttf</filename>) file. The <filename>.fon</filename>
|
||||
font files are also used by Windows. I know of no way to use
|
||||
this font format with FreeBSD.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>What font formats can I use?</title>
|
||||
|
||||
<para>Which font file format is useful depends on the application
|
||||
being used. FreeBSD by itself uses no fonts. Application
|
||||
programs and/or drivers may make use of the font files. Here is
|
||||
a small cross reference of application/driver to the font type
|
||||
suffixes:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Driver</term>
|
||||
|
||||
<listitem>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>syscons</term>
|
||||
|
||||
<listitem>
|
||||
<para><filename>.fnt</filename></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Application</term>
|
||||
|
||||
<listitem>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Ghostscript</term>
|
||||
|
||||
<listitem>
|
||||
<para><filename>.pfa</filename>,
|
||||
<filename>.pfb</filename>,
|
||||
<filename>.ttf</filename></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>X11</term>
|
||||
|
||||
<listitem>
|
||||
<para><filename>.pfa</filename>,
|
||||
<filename>.pfb</filename></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Groff</term>
|
||||
|
||||
<listitem>
|
||||
<para><filename>.pfa</filename>,
|
||||
<filename>.afm</filename></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Povray</term>
|
||||
|
||||
<listitem>
|
||||
<para><filename>.ttf</filename></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>The <filename>.fnt</filename> suffix is used quite
|
||||
frequently. I suspect that whenever someone wanted to create a
|
||||
specialized font file for their application, more often than not
|
||||
they chose this suffix. Therefore, it is likely that files with
|
||||
this suffix are not all the same format; specifically, the
|
||||
<filename>.fnt</filename> files used by syscons under FreeBSD
|
||||
may not be the same format as a <filename>.fnt</filename> file
|
||||
one encounters in the MSDOS/Windows environment. I have not
|
||||
made any attempt at using other <filename>.fnt</filename> files
|
||||
other than those provided with FreeBSD.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Setting a virtual console to 80x60 line mode</title>
|
||||
|
||||
<para>First, an 8x8 font must be loaded. To do this,
|
||||
<filename>/etc/rc.conf</filename> should contain the
|
||||
line (change the font name to an appropriate one for
|
||||
your locale):</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>font8x8="iso-8x8" # font 8x8 from /usr/share/syscons/fonts/* (or NO).</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>The command to actually switch the mode is
|
||||
&man.vidcontrol.1;:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>vidcontrol VGA_80x60</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Various screen orientated programs, such as &man.vi.1;, must
|
||||
be able to determine the current screen dimensions. As this is
|
||||
achieved this through <command>ioctl</command> calls to the console
|
||||
driver (such as &man.syscons.4;) they will correctly determine the new
|
||||
screen dimensions.</para>
|
||||
|
||||
<para>To make this more seamless, one can embed these commands in
|
||||
the startup scripts so it takes place when the system boots.
|
||||
To do this is add this line to <filename>/etc/rc.conf</filename>
|
||||
</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>allscreens_flags="VGA_80x60" # Set this vidcontrol mode for all virtual screens
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>References: &man.rc.conf.5;, &man.vidcontrol.1;.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Using type 1 fonts with X11</title>
|
||||
|
||||
<para>X11 can use either the <filename>.pfa</filename> or the
|
||||
<filename>.pfb</filename> format fonts. The X11 fonts are
|
||||
located in various subdirectories under
|
||||
<filename>/usr/X11R6/lib/X11/fonts</filename>. Each font file
|
||||
is cross referenced to its X11 name by the contents of the
|
||||
<filename>fonts.dir</filename> file in each directory.</para>
|
||||
|
||||
<para>There is already a directory named <filename>Type1</filename>. The
|
||||
most straight forward way to add a new font is to put it into
|
||||
this directory. A better way is to keep all new fonts in a
|
||||
separate directory and use a symbolic link to the additional
|
||||
font. This allows one to more easily keep track of ones fonts
|
||||
without confusing them with the fonts that were originally
|
||||
provided. For example:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><lineannotation>Create a directory to contain the font files</lineannotation>
|
||||
&prompt.user; <userinput>mkdir -p /usr/local/share/fonts/type1</userinput>
|
||||
&prompt.user; <userinput>cd /usr/local/share/fonts/type1</userinput>
|
||||
|
||||
<lineannotation>Place the .pfa, .pfb and .afm files here</lineannotation>
|
||||
<lineannotation>One might want to keep readme files, and other documentation</lineannotation>
|
||||
<lineannotation>for the fonts here also</lineannotation>
|
||||
&prompt.user; <userinput>cp /cdrom/fonts/atm/showboat/showboat.pfb .</userinput>
|
||||
&prompt.user; <userinput>cp /cdrom/fonts/atm/showboat/showboat.afm .</userinput>
|
||||
|
||||
<lineannotation>Maintain an index to cross reference the fonts</lineannotation>
|
||||
&prompt.user; <userinput>echo showboat - InfoMagic CICA, Dec 1994, /fonts/atm/showboat >>INDEX</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Now, to use a new font with X11, one must make the font file
|
||||
available and update the font name files. The X11 font names
|
||||
look like:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>-bitstream-charter-medium-r-normal-xxx-0-0-0-0-p-0-iso8859-1
|
||||
| | | | | | | | | | | | \ \
|
||||
| | | | | \ \ \ \ \ \ \ +----+- character set
|
||||
| | | | \ \ \ \ \ \ \ +- average width
|
||||
| | | | \ \ \ \ \ \ +- spacing
|
||||
| | | \ \ \ \ \ \ +- vertical res.
|
||||
| | | \ \ \ \ \ +- horizontal res.
|
||||
| | | \ \ \ \ +- points
|
||||
| | | \ \ \ +- pixels
|
||||
| | | \ \ \
|
||||
foundry family weight slant width additional style
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>A new name needs to be created for each new font. If you
|
||||
have some information from the documentation that accompanied
|
||||
the font, then it could serve as the basis for creating the
|
||||
name. If there is no information, then you can get some idea by
|
||||
using &man.strings.1; on the font file. For example:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>strings showboat.pfb | more</userinput>
|
||||
%!FontType1-1.0: Showboat 001.001
|
||||
%%CreationDate: 1/15/91 5:16:03 PM
|
||||
%%VMusage: 1024 45747
|
||||
% Generated by Fontographer 3.1
|
||||
% Showboat
|
||||
1991 by David Rakowski. Alle Rechte Vorbehalten.
|
||||
FontDirectory/Showboat known{/Showboat findfont dup/UniqueID known{dup
|
||||
/UniqueID get 4962377 eq exch/FontType get 1 eq and}{pop false}ifelse
|
||||
{save true}{false}ifelse}{false}ifelse
|
||||
12 dict begin
|
||||
/FontInfo 9 dict dup begin
|
||||
/version (001.001) readonly def
|
||||
/FullName (Showboat) readonly def
|
||||
/FamilyName (Showboat) readonly def
|
||||
/Weight (Medium) readonly def
|
||||
/ItalicAngle 0 def
|
||||
/isFixedPitch false def
|
||||
/UnderlinePosition -106 def
|
||||
/UnderlineThickness 16 def
|
||||
/Notice (Showboat
|
||||
1991 by David Rakowski. Alle Rechte Vorbehalten.) readonly def
|
||||
end readonly def
|
||||
/FontName /Showboat def
|
||||
--stdin--
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Using this information, a possible name might be:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>-type1-Showboat-medium-r-normal-decorative-0-0-0-0-p-0-iso8859-1
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The components of our name are:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Foundry</term>
|
||||
|
||||
<listitem>
|
||||
<para>Lets just name all the new fonts
|
||||
<literal>type1</literal>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Family</term>
|
||||
|
||||
<listitem>
|
||||
<para>The name of the font.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Weight</term>
|
||||
|
||||
<listitem>
|
||||
<para>Normal, bold, medium, semibold, etc. From the
|
||||
&man.strings.1;
|
||||
output above, it appears that this font has a weight of
|
||||
<emphasis>medium</emphasis>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Slant</term>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis remap=bf>r</emphasis>oman, <emphasis
|
||||
remap=bf>i</emphasis>talic, <emphasis
|
||||
remap=bf>o</emphasis>blique, etc. Since the
|
||||
<emphasis>ItalicAngle</emphasis> is zero,
|
||||
<emphasis>roman</emphasis> will be used.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Width</term>
|
||||
|
||||
<listitem>
|
||||
<para>Normal, wide, condensed, extended, etc. Until it can
|
||||
be examined, the assumption will be
|
||||
<emphasis>normal</emphasis>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Additional style</term>
|
||||
|
||||
<listitem>
|
||||
<para>Usually omitted, but this will indicate that the font
|
||||
contains decorative capital letters.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Spacing</term>
|
||||
|
||||
<listitem>
|
||||
<para>proportional or monospaced.
|
||||
<emphasis>Proportional</emphasis> is used since
|
||||
<emphasis>isFixedPitch</emphasis> is false.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>All of these names are arbitrary, but one should strive to
|
||||
be compatible with the existing conventions. A font is
|
||||
referenced by name with possible wild cards by an X11 program,
|
||||
so the name chosen should make some sense. One might begin by
|
||||
simply using
|
||||
|
||||
<informalexample>
|
||||
<screen>…-normal-r-normal-…-p-…
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
as the name, and then use
|
||||
&man.xfontsel.1;
|
||||
to examine it and adjust the name based on the appearance of the
|
||||
font.</para>
|
||||
|
||||
<para>So, to complete our example:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><lineannotation>Make the font accessible to X11</lineannotation>
|
||||
&prompt.user; <userinput>cd /usr/X11R6/lib/X11/fonts/Type1</userinput>
|
||||
&prompt.user; <userinput>ln -s /usr/local/share/fonts/type1/showboat.pfb .</userinput>
|
||||
|
||||
<lineannotation>Edit fonts.dir and fonts.scale, adding the line describing the font
|
||||
and incrementing the number of fonts which is found on the first line.</lineannotation>
|
||||
&prompt.user; <userinput>ex fonts.dir
|
||||
:1p
|
||||
25
|
||||
:1c
|
||||
26
|
||||
.
|
||||
:$a
|
||||
showboat.pfb -type1-showboat-medium-r-normal-decorative-0-0-0-0-p-0-iso8859-1
|
||||
.
|
||||
:wq</userinput>
|
||||
|
||||
<lineannotation><filename>fonts.scale</filename> seems to be identical to <filename>fonts.dir</filename>…</lineannotation>
|
||||
&prompt.user; <userinput>cp fonts.dir fonts.scale</userinput>
|
||||
|
||||
<lineannotation>Tell X11 that things have changed</lineannotation>
|
||||
&prompt.user; <userinput>xset fp rehash</userinput>
|
||||
|
||||
<lineannotation>Examine the new font</lineannotation>
|
||||
&prompt.user; <userinput>xfontsel -pattern -type1-*</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>References: &man.xfontsel.1;, &man.xset.1;, <citetitle>The X
|
||||
Windows System in a Nutshell</citetitle>, <ulink
|
||||
URL="http://www.ora.com/">O'Reilly &
|
||||
Associates</ulink>.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Using type 1 fonts with Ghostscript</title>
|
||||
|
||||
<para>Ghostscript references a font via its <filename>Fontmap</filename>
|
||||
file. This must be modified in a similar way to the X11
|
||||
<filename>fonts.dir</filename> file. Ghostscript can use either
|
||||
the <filename>.pfa</filename> or the <filename>.pfb</filename>
|
||||
format fonts. Using the font from the previous example, here is
|
||||
how to use it with Ghostscript:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><lineannotation>Put the font in Ghostscript's font directory</lineannotation>
|
||||
&prompt.user; <userinput>cd /usr/local/share/ghostscript/fonts</userinput>
|
||||
&prompt.user; <userinput>ln -s /usr/local/share/fonts/type1/showboat.pfb .</userinput>
|
||||
|
||||
<lineannotation>Edit Fontmap so Ghostscript knows about the font</lineannotation>
|
||||
&prompt.user; <userinput>cd /usr/local/share/ghostscript/4.01</userinput>
|
||||
&prompt.user; <userinput>ex Fontmap
|
||||
:$a
|
||||
/Showboat (showboat.pfb) ; % From CICA /fonts/atm/showboat
|
||||
.
|
||||
:wq</userinput>
|
||||
|
||||
<lineannotation>Use Ghostscript to examine the font</lineannotation>
|
||||
&prompt.user; <userinput>gs prfont.ps</userinput>
|
||||
Aladdin Ghostscript 4.01 (1996-7-10)
|
||||
Copyright (C) 1996 Aladdin Enterprises, Menlo Park, CA. All rights
|
||||
reserved.
|
||||
This software comes with NO WARRANTY: see the file PUBLIC for details.
|
||||
Loading Times-Roman font from /usr/local/share/ghostscript/fonts/tir_____.pfb...
|
||||
/1899520 581354 1300084 13826 0 done.
|
||||
GS><userinput>Showboat DoFont</userinput>
|
||||
Loading Showboat font from /usr/local/share/ghostscript/fonts/showboat.pfb...
|
||||
1939688 565415 1300084 16901 0 done.
|
||||
>>showpage, press <return> to continue<<
|
||||
>>showpage, press <return> to continue<<
|
||||
>>showpage, press <return> to continue<<
|
||||
GS><userinput>quit</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>References: <filename>fonts.txt</filename> in the
|
||||
Ghostscript 4.01 distribution</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Using type 1 fonts with Groff</title>
|
||||
|
||||
<para>Now that the new font can be used by both X11 and
|
||||
Ghostscript, how can one use the new font with groff? First of
|
||||
all, since we are dealing with type 1 postscript fonts, the
|
||||
groff device that is applicable is the <emphasis>ps</emphasis>
|
||||
device. A font file must be created for each font that groff
|
||||
can use. A groff font name is just a file in
|
||||
<filename>/usr/share/groff_font/devps</filename>. With our
|
||||
example, the font file could be
|
||||
<filename>/usr/share/groff_font/devps/SHOWBOAT</filename>. The
|
||||
file must be created using tools provided by groff.</para>
|
||||
|
||||
<para>The first tool is <command>afmtodit</command>. This is not
|
||||
normally installed, so it must be retrieved from the source
|
||||
distribution. I found I had to change the first line of the
|
||||
file, so I did:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>cp /usr/src/gnu/usr.bin/groff/afmtodit/afmtodit.pl /tmp</userinput>
|
||||
&prompt.user; <userinput>ex /tmp/afmtodit.pl
|
||||
:1c
|
||||
#!/usr/bin/perl -P-
|
||||
.
|
||||
:wq</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This tool will create the groff font file from the metrics
|
||||
file (<filename>.afm</filename> suffix.) Continuing with our
|
||||
example:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><lineannotation>Many <filename>.afm</filename> files are in Mac format… ^M delimited lines
|
||||
We need to convert them to unix style ^J delimited lines</lineannotation>
|
||||
&prompt.user; <userinput>cd /tmp</userinput>
|
||||
&prompt.user; <userinput>cat /usr/local/share/fonts/type1/showboat.afm |
|
||||
tr '\015' '\012' >showboat.afm</userinput>
|
||||
|
||||
<lineannotation>Now create the groff font file</lineannotation>
|
||||
&prompt.user; <userinput>cd /usr/share/groff_font/devps</userinput>
|
||||
&prompt.user; <userinput>/tmp/afmtodit.pl -d DESC -e text.enc /tmp/showboat.afm generate/textmap SHOWBOAT</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The font can now be referenced with the name
|
||||
SHOWBOAT.</para>
|
||||
|
||||
<para>If ghostscript is used to drive the printers on the system,
|
||||
then nothing more needs to be done. However, if true postscript
|
||||
printers are used, then the font must be down loaded to the
|
||||
printer in order for the font to be used (unless the printer
|
||||
happens to have the showboat font built in or on an accessible
|
||||
font disk.) The final step is to create a down loadable font.
|
||||
The <command>pfbtops</command> tool is used to create the
|
||||
<filename>.pfa</filename> format of the font, and the
|
||||
<filename>download</filename> file is modified to reference the new
|
||||
font. The <filename>download</filename> file must reference the
|
||||
internal name of the font. This can easily be determined from
|
||||
the groff font file as illustrated:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><lineannotation>Create the <filename>.pfa</filename> font file</lineannotation>
|
||||
&prompt.user; <userinput>pfbtops /usr/local/share/fonts/type1/showboat.pfb >showboat.pfa</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Of course, if the <filename>.pfa</filename> file is already
|
||||
available, just use a symbolic link to reference it.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen><lineannotation>Get the internal font name</lineannotation>
|
||||
&prompt.user; <userinput>fgrep internalname SHOWBOAT</userinput>
|
||||
internalname Showboat
|
||||
|
||||
<lineannotation>Tell groff that the font must be down loaded</lineannotation>
|
||||
&prompt.user; <userinput>ex download
|
||||
:$a
|
||||
Showboat showboat.pfa
|
||||
.
|
||||
:wq</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To test the font:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>cd /tmp</userinput>
|
||||
&prompt.user; <userinput>cat >example.t <<EOF
|
||||
.sp 5
|
||||
.ps 16
|
||||
This is an example of the Showboat font:
|
||||
.br
|
||||
.ps 48
|
||||
.vs (\n(.s+2)p
|
||||
.sp
|
||||
.ft SHOWBOAT
|
||||
ABCDEFGHI
|
||||
.br
|
||||
JKLMNOPQR
|
||||
.br
|
||||
STUVWXYZ
|
||||
.sp
|
||||
.ps 16
|
||||
.vs (\n(.s+2)p
|
||||
.fp 5 SHOWBOAT
|
||||
.ft R
|
||||
To use it for the first letter of a paragraph, it will look like:
|
||||
.sp 50p
|
||||
\s(48\f5H\s0\fRere is the first sentence of a paragraph that uses the
|
||||
showboat font as its first letter.
|
||||
Additional vertical space must be used to allow room for the larger
|
||||
letter.
|
||||
EOF</userinput>
|
||||
&prompt.user; <userinput>groff -Tps example.t >example.ps</userinput>
|
||||
|
||||
<lineannotation>To use ghostscript/ghostview</lineannotation>
|
||||
&prompt.user; <userinput>ghostview example.ps</userinput>
|
||||
|
||||
<lineannotation>To print it</lineannotation>
|
||||
&prompt.user; <userinput>lpr -Ppostscript example.ps</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>References:
|
||||
<filename>/usr/src/gnu/usr.bin/groff/afmtodit/afmtodit.man</filename>,
|
||||
&man.groff.font.5;, &man.groff.char.7;, &man.pfbtops.1;.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Converting TrueType fonts to a groff/postscript format for
|
||||
groff</title>
|
||||
|
||||
<para>This potentially requires a bit of work, simply because it
|
||||
depends on some utilities that are not installed as part of the
|
||||
base system. They are:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><command>ttf2pf</command></term>
|
||||
|
||||
<listitem>
|
||||
<para>TrueType to postscript convertsion utilities. This
|
||||
allows conversion of a TrueType font to an ascii font
|
||||
metric (<filename>.afm</filename>) file.</para>
|
||||
|
||||
<para>Currently available at <ulink
|
||||
url="http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf/">http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf</ulink>.
|
||||
Note: These files are postscript programs and must be
|
||||
downloaded to disk by holding down the
|
||||
<keycap>Shift</keycap> key when clicking on the link.
|
||||
Otherwise, your browser may try to launch
|
||||
<application>ghostview</application> to view them.</para>
|
||||
|
||||
<para>The files of interest are:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>GS_TTF.PS</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>PF2AFM.PS</filename></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>ttf2pf.ps</filename></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The funny upper/lower case is due to their being
|
||||
intended also for DOS shells.
|
||||
<filename>ttf2pf.ps</filename> makes use of the others as
|
||||
upper case, so any renaming must be consistent with this.
|
||||
(Actually, <filename>GS_TTF.PS</filename> and
|
||||
<filename>PFS2AFM.PS</filename> are supposedly part of the
|
||||
ghostscript distribution, but it's just as easy to use
|
||||
these as an isolated utility. FreeBSD doesn't seem to
|
||||
include the latter.) You also may want to have these
|
||||
installed to
|
||||
<filename>/usr/local/share/groff_font/devps</filename>(?).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><command>afmtodit</command></term>
|
||||
|
||||
<listitem>
|
||||
<para>Creates font files for use with groff from ascii font
|
||||
metrics file. This usually resides in the directory,
|
||||
<filename>/usr/src/contrib/groff/afmtodit</filename>, and
|
||||
requires some work to get going.</para>
|
||||
|
||||
<note>
|
||||
<para> If you're paranoid about working in the
|
||||
<filename>/usr/src</filename> tree, simply copy the
|
||||
contents of the above directory to a work
|
||||
location.</para>
|
||||
</note>
|
||||
|
||||
<para>In the work area, you'll need to make the utility.
|
||||
Just type:</para>
|
||||
|
||||
<screen><prompt>#</prompt> <userinput>make -f Makefile.sub afmtodit</userinput>
|
||||
</screen>
|
||||
|
||||
<para>You may also need to copy
|
||||
<filename>/usr/contrib/groff/devps/generate/textmap</filename>
|
||||
to
|
||||
<filename>/usr/share/groff_font/devps/generate</filename>
|
||||
if it doesn't already exist.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Once all these utilities are in place, you're ready to
|
||||
commence:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Create the <filename>.afm</filename> file by
|
||||
typing:</para>
|
||||
|
||||
<screen><prompt>%</prompt> <userinput>gs <optional>-dNODISPLAY</optional> <optional>-q</optional> -- ttf2pf.ps <replaceable>TTF_name</replaceable> <optional><replaceable>PS_font_name</replaceable> <optional><replaceable>AFM_name</replaceable></optional></optional></userinput>
|
||||
</screen>
|
||||
|
||||
<para>Where, <replaceable>TTF_name</replaceable> is your
|
||||
TrueType font file, <replaceable>PS_font_name</replaceable>
|
||||
is the file name for the <filename>.pfa</filename> file,
|
||||
<replaceable>AFM_name</replaceable> is the name you wish for
|
||||
the <filename>.afm</filename> file. If you do not specify
|
||||
output file names for the <filename>.pfa</filename> or
|
||||
<filename>.afm</filename> files, then default names will be
|
||||
generated from the TrueType font file name.</para>
|
||||
|
||||
<para>This also produces a <filename>.pfa</filename> file, the
|
||||
ascii postscript font metrics file
|
||||
(<filename>.pfb</filename> is for the binrary form). This
|
||||
won't be needed, but could (I think) be useful for a
|
||||
fontserver.</para>
|
||||
|
||||
<para>For example, to convert the 30f9 Barcode font using the
|
||||
default file names, use the following command:</para>
|
||||
|
||||
<screen><prompt>%</prompt> <userinput>gs -dNODISPLAY -- ttf2pf.ps 3of9.ttf</userinput>
|
||||
Aladdin Ghostscript 5.10 (1997-11-23)
|
||||
Copyright (C) 1997 Aladdin Enterprises, Menlo Park, CA. All rights reserved.
|
||||
This software comes with NO WARRANTY: see the file PUBLIC for details.
|
||||
Converting 3of9.ttf to 3of9.pfa and 3of9.afm.
|
||||
</screen>
|
||||
|
||||
<para>If you want the converted fonts to be stored in
|
||||
<filename>A.pfa</filename> and <filename>B.afm</filename>,
|
||||
then use this command:</para>
|
||||
|
||||
<screen><prompt>%</prompt> <userinput>gs -dNODISPLAY -- ttf2pf.ps 3of9.ttf A B</userinput>
|
||||
Aladdin Ghostscript 5.10 (1997-11-23)
|
||||
Copyright (C) 1997 Aladdin Enterprises, Menlo Park, CA. All rights reserved.
|
||||
This software comes with NO WARRANTY: see the file PUBLIC for details.
|
||||
Converting 3of9.ttf to A.pfa and B.afm.
|
||||
</screen>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Create the groff postscript file:</para>
|
||||
|
||||
<para>Change directories to
|
||||
<filename>/usr/share/groff_font/devps</filename> so as to
|
||||
make the following command easier to execute. You'll
|
||||
probably need root priviledges for this. (Or, if you're
|
||||
paranoid about working there, make sure you reference the
|
||||
files <filename>DESC</filename>,
|
||||
<filename>text.enc</filename> and
|
||||
<filename>generate/textmap</filename> as being in this
|
||||
directory.)</para>
|
||||
|
||||
<screen><prompt>%</prompt> <userinput>afmtodit -d DESC -e text.enc file.afm \
|
||||
generate/textmap <replaceable>PS_font_name</replaceable></userinput>
|
||||
</screen>
|
||||
|
||||
<para>Where, <filename>file.afm</filename> is the
|
||||
<replaceable>AFM_name</replaceable> created by
|
||||
<command>ttf2pf.ps</command> above, and
|
||||
<replaceable>PS_font_name</replaceable> is the font name
|
||||
used from that command, as well as the name that
|
||||
&man.groff.1; will use for references to this font. For
|
||||
example, assuming you used the first
|
||||
<command>tiff2pf.ps</command> command above, then the 3of9
|
||||
Barcode font can be created using the command:</para>
|
||||
|
||||
<screen><prompt>%</prompt> <userinput>afmtodit -d DESC -e text.enc 3of9.afm \
|
||||
generate/textmap 3of9</userinput>
|
||||
</screen>
|
||||
|
||||
<para>Ensure that the resulting
|
||||
<replaceable>PS_font_name</replaceable> file (e.g.,
|
||||
<filename>3of9</filename> in the example above) is located
|
||||
in the directory
|
||||
<filename>/usr/share/groff_font/devps</filename> by copying
|
||||
or moving it there.</para>
|
||||
|
||||
<para>Note that if <filename>ttf2pf.ps</filename> assigns a
|
||||
font name using the one it finds in the TrueType font file
|
||||
and you want to use a different name, you must edit the
|
||||
<filename>.afm</filename> file prior to running
|
||||
<command>afmtodit</command>. This name must also match the
|
||||
one used in the Fontmap file if you wish to pipe
|
||||
&man.groff.1; into &man.gs.1;.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Can TrueType fonts be used with other programs?</title>
|
||||
|
||||
<para>The TrueType font format is used by Windows, Windows 95, and
|
||||
Mac's. It is quite popular and there are a great number of
|
||||
fonts available in this format.</para>
|
||||
|
||||
<para>Unfortunately, there are few applications that I am aware of
|
||||
that can use this format: Ghostscript and Povray come to mind.
|
||||
Ghostscript's support, according to the documentation, is
|
||||
rudimentary and the results are likely to be inferior to type 1
|
||||
fonts. Povray version 3 also has the ability to use TrueType
|
||||
fonts, but I rather doubt many people will be creating documents
|
||||
as a series of raytraced pages :-).</para>
|
||||
|
||||
<para>This rather dismal situation may soon change. The <ulink
|
||||
url="http://www.freetype.org/">FreeType Project</ulink> is
|
||||
currently developing a useful set of FreeType tools:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The freetype module is included with XFree86 4.x. For
|
||||
more information please see the <ulink
|
||||
url="http://www.freebsd.org/handbook/x-fonts.html">FreeBSD
|
||||
Handbook</ulink> or the <ulink
|
||||
url="http://www.xfree86.org/4.0.2/fonts.html">XFree86 4.0.2
|
||||
Fonts</ulink> page.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <command>xfsft</command> font server for X11 can
|
||||
serve TrueType fonts in addition to regular fonts. Though
|
||||
currently in beta, it is said to be quite useable. See
|
||||
<ulink
|
||||
url="http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/">Juliusz
|
||||
Chroboczek's page</ulink> for further information.
|
||||
Porting instructions for FreeBSD can be found at <ulink
|
||||
url="http://math.missouri.edu/~stephen/software/">Stephen
|
||||
Montgomery's software page</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><command>xfstt</command> is another font server for X11,
|
||||
available under <ulink url="
|
||||
ftp://sunsite.unc.edu/pub/Linux/X11/fonts">
|
||||
ftp://sunsite.unc.edu/pub/Linux/X11/fonts</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A program called <command>ttf2bdf</command> can produce
|
||||
BDF files suitable for use in an X environment from TrueType
|
||||
files. Linux binaries are said to be available from <ulink
|
||||
url="ftp://crl.nmsu.edu/CLR/multiling/General">ftp://crl.nmsu.edu/CLR/multiling/General/</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>For people requiring the use of Asian TrueType fonts,
|
||||
the <command>XTT</command> font server may be worth a look.
|
||||
Information about <command>XTT</command> can be found at
|
||||
URL: <ulink
|
||||
url="http://hawk.ise.chuo-u.ac.jp/student/person/tshiozak/study/freebsd-at-random/x-tt/index-en.html">http://hawk.ise.chuo-u.ac.jp/student/person/tshiozak/study/freebsd-at-random/x-tt/index-en.html</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>and others …</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The <ulink
|
||||
url="http://freetype.sourceforge.net/projects.html">FreeType Projects
|
||||
page </ulink> is a good starting point for information on
|
||||
these and other free TrueType projects.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Where can additional fonts be obtained?</title>
|
||||
|
||||
<para>Many fonts are available on the Internet. They are either
|
||||
entirely free, or are share-ware. In addition, there are many
|
||||
inexpensive CDROMs available that contain many fonts. Some
|
||||
Internet locations (as of August 1996) are:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="ftp://ftp.winsite.com">ftp://ftp.winsite.com</ulink>
|
||||
(Formerly CICA)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://www.simtel.net/">http://www.simtel.net/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="ftp://ftp.coast.net/">ftp://ftp.coast.net/</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://af-pc-plloyd.ecel.uwa.edu.au/fonts/index.html">http://af-pc-plloyd.ecel.uwa.edu.au/fonts/index.html</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://www.esselte.com/letraset/index.html">http://www.esselte.com/letraset/index.html</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink
|
||||
url="http://www.inil.com/users/elfring/esf.htm">http://www.inil.com/users/elfring/esf.htm</ulink></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Additional questions</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>What use are the <filename>.pfm</filename> files?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Can one generate the <filename>.afm</filename> file from
|
||||
a <filename>.pfa</filename> or
|
||||
<filename>.pfb</filename>?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>How to generate the groff character mapping files for
|
||||
postscript fonts with non-standard character names?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Can xditview and devX?? devices be setup to access all
|
||||
the new fonts?</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>It would be good to have examples of using TrueType
|
||||
fonts with povray and ghostscript.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
</article>
|
||||
@ -1,14 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,636 +0,0 @@
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
]>
|
||||
<!-- $FreeBSD: doc/en_US.ISO_8859-1/articles/formatting-media/article.sgml,v 1.15 2001/04/17 15:53:38 nik Exp $ -->
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Formatting Media For Use With FreeBSD</title>
|
||||
|
||||
<subtitle>A Tutorial</subtitle>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Doug</firstname>
|
||||
|
||||
<surname>White</surname>
|
||||
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>dwhite@resnet.uoregon.edu</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>March 1997</pubdate>
|
||||
|
||||
<abstract>
|
||||
<para>This document describes how to slice, partition, and
|
||||
format hard disk drives and similar media for use with
|
||||
FreeBSD. The examples given have been tested under FreeBSD
|
||||
2.2 and should work for other releases. The text has been updated
|
||||
for FreeBSD version 4.</para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<sect1>
|
||||
<title>Introduction & Definitions</title>
|
||||
|
||||
<sect2>
|
||||
<title>Overview</title>
|
||||
|
||||
<para>Successfully adding disks to an existing system is the
|
||||
mark of an experienced system administrator. Slicing,
|
||||
partitioning, and adding disks requires a careful dance of
|
||||
proper command and name syntax. One slipped finger and an
|
||||
entire disk could disappear in seconds. This document is
|
||||
written in an attempt to simplify this process and avoid
|
||||
accidents. Thankfully, enhancements to existing tools
|
||||
(notably sysinstall) have greatly improved this process in
|
||||
recent releases of FreeBSD.</para>
|
||||
|
||||
<para>There are two possible modes of disk formatting:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><firstterm>compatibility mode</firstterm>: Arranging a
|
||||
disk so that it has a slice table for use with other
|
||||
operating systems.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><firstterm>dedicated mode</firstterm>, sometimes called
|
||||
<firstterm>dangerously dedicated mode</firstterm>: Formatting a disk
|
||||
with no slice table. This makes the process of adding disks easier,
|
||||
however non-FreeBSD operating systems may not accept the disk. The
|
||||
term <emphasis>dangerously</emphasis> refers to the danger that the
|
||||
system may not recognize a disk formatted in this manner.</para>
|
||||
</listitem> </itemizedlist>
|
||||
|
||||
<para>For most cases, dedicated mode is the easiest to set up
|
||||
and use in existing systems, as a new disk is usually
|
||||
dedicated entirely to FreeBSD. However, compatibility mode
|
||||
insures optimum interoperability with future installations at
|
||||
a cost of increased complexity.</para>
|
||||
|
||||
<para>In addition to selecting the mode, two methods of slicing
|
||||
the disk are available. One is using the system installation
|
||||
tool <command>/stand/sysinstall</command>. 2.1.7-RELEASE and
|
||||
later versions of <command>sysinstall</command> contain code
|
||||
to ease setup of disks during normal system operation, mainly
|
||||
allowing access to the Label and Partition editors and a Write
|
||||
feature which will update just the selected disk and slice
|
||||
without affecting other disks. The other method is running
|
||||
the tools manually from a root command line. For
|
||||
dedicated mode, only three or four commands are involved while
|
||||
<command>sysinstall</command> requires some
|
||||
manipulation.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Definitions</title>
|
||||
|
||||
<para>UNIX disk management over the centuries has invented many
|
||||
new definitions for old words. The following glossary covers
|
||||
the definitions used in this document and (hopefully) for
|
||||
FreeBSD in general.</para>
|
||||
|
||||
<!-- I'm tempted to use GLOSSARY here but will resort to a list for
|
||||
now. -->
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>compatibility mode: Arranging a disk so that it has a
|
||||
slice table for use with other operating systems. Oppose
|
||||
dedicated mode.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>(dangerously) dedicated mode: Formatting a disk with no
|
||||
slice table. This makes the process of adding disks
|
||||
easier, however non-FreeBSD operating systems may not
|
||||
accept the disk. Oppose compatibility mode.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>disk: A circular disc, covered with magnetic or
|
||||
similarly manipulable material, spun by a motor under a
|
||||
head. Data is stored on the disk by changing the pattern
|
||||
of magnetism on the disc, which can be later read. Hard
|
||||
disks, CD-ROMs, Magneto-optical,and Zip/Jaz removables are
|
||||
examples of disks.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>slice: A division of a disk. Up to four slices are
|
||||
permitted on one disk in the PC standard. Slices are
|
||||
composed of contiguous sectors. Slices are recorded in a
|
||||
<quote>slice table</quote> used by the system BIOS to
|
||||
locate bootable partitions. The slice table is usually
|
||||
called the Partition Table in DOS parlance. Maintained by
|
||||
the fdisk utility.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>partition: A division of a slice. Usually used in
|
||||
reference to divisions of the FreeBSD slice of a disk.
|
||||
Each filesystem and swap area on a disk resides in a
|
||||
partition. Maintained using the disklabel utility.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>sector: Smallest subdivision of a disk. One sector
|
||||
usually represents 512 bytes of data.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Warnings & Pitfalls</title>
|
||||
|
||||
<para>Building disks is not something to take lightly. It is
|
||||
quite possible to destroy the contents of other disks in your
|
||||
system if the proper precautions are not taken.</para>
|
||||
|
||||
<para><emphasis>Check your work carefully.</emphasis> It is very simple
|
||||
to destroy the incorrect disk when working with these
|
||||
commands. When in doubt consult the kernel boot output for
|
||||
the proper device.</para>
|
||||
|
||||
<para>Needless to say, we are not responsible for any damage to
|
||||
any data or hardware that you may experience. You work at
|
||||
your own risk!</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Zip, Jaz, and Other Removables</title>
|
||||
|
||||
<para>Removable disks can be formatted in the same way as normal
|
||||
hard disks. It is essential to have the disk drive connected
|
||||
to the system and a disk placed in the drive during startup,
|
||||
so the kernel can determine the drive's geometry. Check the
|
||||
<command>dmesg</command> output and make sure your device and
|
||||
the disk's size is listed. If the kernel reports
|
||||
|
||||
<informalexample>
|
||||
<screen>Can't get the size
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
then the disk was not in the drive. In this case, you will
|
||||
need to restart the machine before attempting to format
|
||||
disks.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Formatting Disks in Dedicated Mode</title>
|
||||
|
||||
<sect2>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>This section details how to make disks that are totally
|
||||
dedicated to FreeBSD. Remember, dedicated mode disks sometimes
|
||||
cannot be booted by the PC architecture.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Making Dedicated Mode Disks using Sysinstall</title>
|
||||
|
||||
<para><command>/stand/sysinstall</command>, the system
|
||||
installation utility, has been expanded in recent versions to
|
||||
make the process of dividing disks properly a less tiring
|
||||
affair. The fdisk and disklabel editors built into sysinstall
|
||||
are GUI tools that remove much of the confusion from slicing
|
||||
disks. For FreeBSD versions 2.1.7 and later, this is perhaps
|
||||
the simplest way to slice disks.</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<para>Start sysinstall as root by typing
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>/stand/sysinstall</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
from the command prompt.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select <command>Index</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select <command>Partition</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select the disk to edit with arrow keys and
|
||||
<keycap>SPACE</keycap>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>If you are using this entire disk for FreeBSD, select
|
||||
<command>A</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When asked:
|
||||
|
||||
<informalexample>
|
||||
<screen>Do you want to do this with a true partition entry so as to remain
|
||||
cooperative with any future possible operating systems on the
|
||||
drive(s)?
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
answer <command>No</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When asked if you still want to do this, answer
|
||||
<command>Yes</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select <command>Write</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When warned about Writing on installed systems, answer
|
||||
<command>Yes</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para><command>Quit</command>the FDISK Editor and
|
||||
<keycap>ESCAPE</keycap> back to the Index menu.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select <command>Label</command> from the Index
|
||||
menu.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Label as desired. For a single partition, enter
|
||||
<command>C</command> to Create a partition, accept the
|
||||
default size, partition type Filesystem, and a mountpoint
|
||||
(which isn't used).</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Enter <command>W</command> when done and confirm to
|
||||
continue. The filesystem will be newfs'd for you, unless
|
||||
you select otherwise (for news partitions you'll want to
|
||||
do this!). You'll get the error:
|
||||
|
||||
<informalexample>
|
||||
<screen>Error mounting /mnt/dev/ad2s1e on /mnt/blah : No such file or directory
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
Ignore.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Exit out by repeatedly pressing
|
||||
<keycap>ESCAPE</keycap>.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Making Dedicated Mode Disks Using the Command Line</title>
|
||||
|
||||
<para>Execute the following commands, replacing ad2 with the
|
||||
disk name.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>dd if=/dev/zero of=/dev/ad2 count=2</userinput>
|
||||
&prompt.root; <userinput>disklabel /dev/ad2 | disklabel -B -R -r ad2 /dev/stdin</userinput>
|
||||
<lineannotation>We only want one partition, so using slice 'c' should be fine:</lineannotation>
|
||||
&prompt.root; <userinput>newfs /dev/ad2c</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>If you need to edit the disklabel to create multiple
|
||||
partitions (such as swap), use the following: </para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>dd if=/dev/zero of=/dev/ad2 count=2</userinput>
|
||||
&prompt.root; <userinput>disklabel /dev/$d > /tmp/label</userinput>
|
||||
<lineannotation>Edit disklabel to add partitions:</lineannotation>
|
||||
&prompt.root; <userinput>vi /tmp/label</userinput>
|
||||
&prompt.root; <userinput>disklabel -B -R -r ad2 /tmp/label</userinput>
|
||||
<lineannotation>newfs partitions appropriately</lineannotation>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Your disk is now ready for use.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Making Compatibility Mode Disks</title>
|
||||
|
||||
<sect2>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>The command line is the easiest way to make dedicated
|
||||
disks, and the worst way to make compatibility disks. The
|
||||
command-line fdisk utility requires higher math skills and an
|
||||
in-depth understanding of the slice table, which is more than
|
||||
most people want to deal with. Use sysinstall for
|
||||
compatibility disks, as described below.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Making Compatibility Mode Disks Using Sysinstall</title>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<para>Start sysinstall as root by typing
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>/stand/sysinstall</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
from the command prompt.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select <command>Index</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select <command>Partition</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select the disk to edit with arrow keys and
|
||||
<keycap>SPACE</keycap>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>If you are using this entire disk for FreeBSD, select
|
||||
<command>A</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When asked:
|
||||
|
||||
<informalexample>
|
||||
<screen>Do you want to do this with a true partition entry so as to remain
|
||||
cooperative with any future possible operating systems on the
|
||||
drive(s)?
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
answer <command>yes</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select <command>Write</command>.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When asked to install the boot manager, select None
|
||||
with <keycap>SPACE</keycap> then hit
|
||||
<keycap>ENTER</keycap> for OK.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para><command>Quit</command> the FDISK Editor.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>You'll be asked about the boot manager, select
|
||||
<command>None</command> again. </para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Select <command>Label</command> from the Index
|
||||
menu.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Label as desired. For a single partition, accept the
|
||||
default size, type filesystem, and a mountpoint (which
|
||||
isn't used).</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>The filesystem will be newfs'd for you, unless you
|
||||
select otherwise (for news partitions you'll want to do
|
||||
this!). You'll get the error:
|
||||
|
||||
<informalexample>
|
||||
<screen>Error mounting /mnt/dev/ad2s1e on /mnt/blah : No such file or directory
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
Ignore.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Exit out by repeatedly pressing
|
||||
<keycap>ESCAPE</keycap>.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
|
||||
<para>Your new disk is now ready for use.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Other Disk Operations</title>
|
||||
|
||||
<sect2>
|
||||
<title>Adding Swap Space</title>
|
||||
|
||||
<para>As a system grows, it's need for swap space can also grow.
|
||||
Although adding swap space to existing disks is very
|
||||
difficult, a new disk can be partitioned with additional swap
|
||||
space.</para>
|
||||
|
||||
<para>To add swap space when adding a disk to a system:</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<para>When partitioning the disk, edit the disklabel and
|
||||
allocate the amount of swap space to add in partition `b'
|
||||
and the remainder in another partition, such as `a' or
|
||||
`e'. The size is given in 512 byte blocks.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When newfsing the drive, do NOT newfs the `c'
|
||||
partition. Instead, newfs the partition where the
|
||||
non-swap space lies.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Add an entry to <filename>/etc/fstab</filename> as
|
||||
follows:</para>
|
||||
|
||||
<informalexample>
|
||||
<programlisting>/dev/ad0b none swap sw 0 0
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
<para>Change /dev/ad0b to the device of the newly added
|
||||
space.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>To make the new space immediately available, use the
|
||||
<command>swapon</command> command.
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>swapon /dev/da0b</userinput>
|
||||
swapon: added /dev/da0b as swap space
|
||||
</screen>
|
||||
</informalexample>
|
||||
</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Copying the Contents of Disks</title>
|
||||
<!-- Should have specific tag -->
|
||||
|
||||
<para>Submitted By: Renaud Waldura
|
||||
(<email>renaud@softway.com</email>) </para>
|
||||
|
||||
<para>To move file from your original base disk to the fresh new
|
||||
one, do:
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>mount /dev/ad2 /mnt</userinput>
|
||||
&prompt.root; <userinput>pax -r -w -p e /usr/home /mnt</userinput>
|
||||
&prompt.root; <userinput>umount /mnt</userinput>
|
||||
&prompt.root; <userinput>rm -rf /usr/home/*</userinput>
|
||||
&prompt.root; <userinput>mount /dev/ad2 /usr/home</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Creating Striped Disks using CCD</title>
|
||||
|
||||
<para>Commands Submitted By: Stan Brown
|
||||
(<email>stanb@awod.com</email>) </para>
|
||||
|
||||
<para>The Concatenated Disk Driver, or CCD, allows you to treat
|
||||
several identical disks as a single disk. Striping can result
|
||||
in increased disk performance by distributing reads and writes
|
||||
across the disks. See the &man.ccd.4; and &man.ccdconfig.8;
|
||||
man pages or the <ulink
|
||||
URL="http://stampede.cs.berkeley.edu/ccd/">CCD
|
||||
Homepage</ulink> for further details.</para>
|
||||
|
||||
<para>You no longer need to build a special kernel to run ccd. When you
|
||||
run <command>ccdconfig</command>, it will load the KLD for you if the
|
||||
kernel does not contain CCD support.</para>
|
||||
|
||||
<para>You build CCDs on disk partitions of type
|
||||
<emphasis>4.2BSD</emphasis>. If you want to use the entire disk, you
|
||||
still need to create a new partition. For example, <userinput>disklabel
|
||||
-e</userinput> might show:
|
||||
|
||||
<informalexample>
|
||||
<screen># size offset fstype [fsize bsize bps/cpg]
|
||||
c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597)
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You shouldn't use partition <emphasis>c</emphasis> for the CCD,
|
||||
since it is of type <emphasis>unused</emphasis>. Instead, create a new
|
||||
partition of exactly the same size, but with type
|
||||
<emphasis>4.2BSD</emphasis>:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen># size offset fstype [fsize bsize bps/cpg]
|
||||
c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597)
|
||||
<userinput> e: 60074784 0 4.2BSD 0 0 0 # (Cyl. 0 - 59597)</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>To create a new CCD, execute the following commands. This
|
||||
describes how to add three disks together; simply add or remove devices
|
||||
as necessary. Remember that the disks to be striped must be
|
||||
<emphasis>identical.</emphasis></para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>cd /dev ; sh MAKDEV ccd0</userinput>
|
||||
|
||||
&prompt.root; <userinput>disklabel -r -w da0 auto</userinput>
|
||||
&prompt.root; <userinput>disklabel -r -w da1 auto</userinput>
|
||||
&prompt.root; <userinput>disklabel -r -w da2 auto</userinput>
|
||||
|
||||
&prompt.root; <userinput>disklabel -e da0</userinput>
|
||||
<lineannotation>Add partition e with type 4.2BSD</lineannotation>
|
||||
&prompt.root; <userinput>disklabel -e da1</userinput>
|
||||
<lineannotation>Add partition e with type 4.2BSD</lineannotation>
|
||||
&prompt.root; <userinput>disklabel -e da2</userinput>
|
||||
<lineannotation>Add partition e with type 4.2BSD</lineannotation>
|
||||
|
||||
&prompt.root; <userinput>ccdconfig ccd0 273 0 /dev/da0e /dev/da1e /dev/da2e</userinput>
|
||||
|
||||
&prompt.root; <userinput>newfs /dev/ccd0c</userinput>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The value 273 is the stripe size. This is the number of disk
|
||||
sectors (of 512 bytes each) in each block of data on the CCD. It should
|
||||
be at least 128 kB, and it should not be not be a power of 2.</para>
|
||||
|
||||
<para>Now you can mount and use your CCD by referencing device
|
||||
/dev/ccd0c.</para>
|
||||
<para>
|
||||
A more powerful and flexible alternative to CCD is Vinum. See the <ulink
|
||||
URL="http://www.vinumvm.org/">Vinum Project home page</ulink> for further
|
||||
details
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Credits</title>
|
||||
|
||||
<para>The author would like to thank the following individuals for
|
||||
their contributions to this project:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Darryl Okahata
|
||||
(<email>darrylo@hpnmhjw.sr.hp.com</email>) for his simple
|
||||
dedicated mode setup documentation which I have used
|
||||
repeatedly on FreeBSD-questions.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Jordan Hubbard (<email>jkh@FreeBSD.org</email>) for
|
||||
making sysinstall useful for this type of task.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>John Fieber (<email>jfieber@indiana.edu</email>) for
|
||||
making information and examples of the DocBook DTD on which
|
||||
this document is based.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Greg Lehey (<email>grog@FreeBSD.org</email>) for
|
||||
checking my work and pointing out inaccuracies, as well as
|
||||
miscellaneous support.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
</article>
|
||||
@ -1,23 +0,0 @@
|
||||
#
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/articles/committers-guide/Makefile,v 1.3 1999/09/06 06:52:35 peter Exp $
|
||||
#
|
||||
|
||||
MAINTAINER=grog@FreeBSD.org
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?= gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
#
|
||||
# SRCS lists the individual SGML files that make up the document. Changes
|
||||
# to any of these files will force a rebuild
|
||||
#
|
||||
|
||||
# SGML content
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,563 +0,0 @@
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V3.1-Based Extension//EN" [
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
]>
|
||||
|
||||
<article>
|
||||
<artheader>
|
||||
<title>How to get best results from the FreeBSD-questions mailing
|
||||
list</title>
|
||||
|
||||
<author>
|
||||
<firstname>Greg</firstname>
|
||||
<surname>Lehey</surname>
|
||||
|
||||
<affiliation>
|
||||
<address><email>grog@FreeBSD.org</email></address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<pubdate>$FreeBSD$</pubdate>
|
||||
|
||||
<abstract>
|
||||
<para>This document provides useful information for people looking to
|
||||
prepare an e-mail to the FreeBSD-questions mailing list. Advice and
|
||||
hints are given that will maximise the chance that the reader will
|
||||
receive useful replies.</para>
|
||||
|
||||
<para>This document is regularly posted to the FreeBSD-questions mailing
|
||||
list.</para>
|
||||
</abstract>
|
||||
</artheader>
|
||||
|
||||
<sect1>
|
||||
<title id="Introduction">Introduction</title>
|
||||
|
||||
<para><literal>FreeBSD-questions</literal> is a mailing list maintained by
|
||||
the FreeBSD project to help people who have questions about the normal
|
||||
use of FreeBSD. Another group, <literal>FreeBSD-hackers</literal>,
|
||||
discusses more advanced questions such as future development
|
||||
work.</para>
|
||||
|
||||
<note>
|
||||
<para>The term <quote>hacker</quote> has nothing to do with breaking
|
||||
into other people's computers. The correct term for the latter
|
||||
activity is <quote>cracker</quote>, but the popular press hasn't found
|
||||
out yet. The FreeBSD hackers disapprove strongly of cracking
|
||||
security, and have nothing to do with it. For a longer description of
|
||||
hackers, see Eric Raymond's <ulink
|
||||
url="http://www.tuxedo.org/~esr/faqs/hacker-howto.html">How To Become A Hacker</ulink></para>
|
||||
</note>
|
||||
|
||||
<para>This is a regular posting aimed to help both those seeking advice
|
||||
from FreeBSD-questions (the <quote>newcomers</quote>), and also those
|
||||
who answer the questions (the <quote>hackers</quote>).</para>
|
||||
|
||||
<para>Inevitably there is some friction, which stems from the different
|
||||
viewpoints of the two groups. The newcomers accuse the hackers of being
|
||||
arrogant, stuck-up, and unhelpful, while the hackers accuse the
|
||||
newcomers of being stupid, unable to read plain English, and expecting
|
||||
everything to be handed to them on a silver platter. Of course, there's
|
||||
an element of truth in both these claims, but for the most part these
|
||||
viewpoints come from a sense of frustration.</para>
|
||||
|
||||
<para>In this document, I'd like to do something to relieve this
|
||||
frustration and help everybody get better results from
|
||||
FreeBSD-questions. In the following section, I recommend how to submit
|
||||
a question; after that, we'll look at how to answer one.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title id="subscribe">How to subscribe to FreeBSD-questions</title>
|
||||
|
||||
<para>FreeBSD-questions is a mailing list, so you need mail access. Send
|
||||
a mail message to <email>majordomo@FreeBSD.org</email> with the single
|
||||
line:</para>
|
||||
|
||||
<literallayout class="monospaced">subscribe FreeBSD-questions</literallayout>
|
||||
|
||||
<para><application>majordomo</application> is an automatic program which
|
||||
maintains the mailing list, so you don't need a subject line. If your
|
||||
mailer complains, however, you can put anything you like in the subject
|
||||
line.</para>
|
||||
|
||||
<para>When you get the reply from <application>majordomo</application>
|
||||
telling you the details of the list, <emphasis>please save
|
||||
it</emphasis>. If you ever should want to leave the list, you'll need
|
||||
the information there. See the next section for more details.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title id="unsubscribe">How to unsubscribe from FreeBSD-questions</title>
|
||||
|
||||
<para>When you subscribed to FreeBSD-questions, you got a welcome message
|
||||
from <email>Majordomo@FreeBSD.ORG</email>. In this message, amongst
|
||||
other things, it told you how to unsubscribe. Here's a typical
|
||||
message:</para>
|
||||
|
||||
<literallayout class="monospaced">Welcome to the freebsd-questions mailing list!
|
||||
|
||||
If you ever want to remove yourself from this mailing list, you can send
|
||||
mail to "Majordomo@FreeBSD.ORG" with the following command in the body
|
||||
of your email message:
|
||||
|
||||
unsubscribe freebsd-questions Greg Lehey <grog@lemis.de>
|
||||
|
||||
Here's the general information for the list you've subscribed to,
|
||||
in case you don't already have it:
|
||||
|
||||
FREEBSD-QUESTIONS User questions
|
||||
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.</literallayout>
|
||||
|
||||
<para>Normally, unsubscribing is even simpler than the message suggests:
|
||||
you don't need to specify your mail ID unless it is different from the
|
||||
one which you specified when you subscribed.</para>
|
||||
|
||||
<para>If Majordomo replies and tells you (incorrectly) that you're not on
|
||||
the list, this may mean one of two things:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>You have changed your mail ID since you subscribed. That's
|
||||
where keeping the original message from <literal>majordomo</literal>
|
||||
comes in handy. For example, the sample message above shows my mail
|
||||
ID as <literal>grog@lemis.de</literal>. Since then, I have changed
|
||||
it to <literal>grog@lemis.com</literal>. If I were to try to remove
|
||||
<literal>grog@lemis.com</literal> from the list, it would fail: I
|
||||
would have to specify the name with which I joined.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>You're subscribed to a mailing list which is subscribed to
|
||||
<literal>FreeBSD-questions</literal>. If that's the case, you'll
|
||||
have to figure out which one it is and get your name taken off that
|
||||
one. If you're not sure which one it might be, check the headers of
|
||||
the messages you receive from freebsd-questions: maybe there's a
|
||||
clue there.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If you've done all this, and you still can't figure out what's going
|
||||
on, send a message to <email>Postmaster@FreeBSD.org</email>, and he will
|
||||
sort things out for you. <emphasis>Don't</emphasis> send a message to
|
||||
FreeBSD-questions: they can't help you.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title id="askwho">Should I ask <literal>-questions</literal> or
|
||||
<literal>-hackers</literal>?</title>
|
||||
|
||||
<para>Two mailing lists handle general questions about FreeBSD,
|
||||
<literal>FreeBSD-questions</literal> and
|
||||
<literal>FreeBSD-hackers</literal>. In some cases, it's not really
|
||||
clear which group you should ask. The following criteria should help
|
||||
for 99% of all questions, however:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>If the question is of a general nature, ask
|
||||
<literal>FreeBSD-questions</literal>. Examples might be questions
|
||||
about intstalling FreeBSD or the use of a particular UNIX
|
||||
utility.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you think the question relates to a bug, but you're not sure,
|
||||
or you don't know how to look for it, send the message to
|
||||
<literal>FreeBSD-questions</literal>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If the question relates to a bug, and you're
|
||||
<emphasis>sure</emphasis> that it's a bug (for example, you can
|
||||
pinpoint the place in the code where it happens, and you maybe have
|
||||
a fix), then send the message to
|
||||
<literal>FreeBSD-hackers</literal>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If the question relates to enhancements to FreeBSD, and you
|
||||
can make suggestions about how to implement them, then send the
|
||||
message to <literal>FreeBSD-hackers</literal>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>There are also a number of other specialized mailing lists, for
|
||||
example <literal>FreeBSD-isp</literal>, which caters to the interests of
|
||||
ISPs (Internet Service Providers) who run FreeBSD. If you happen to be
|
||||
an ISP, this doesn't mean you should automatically send your questions
|
||||
to <literal>FreeBSD-isp</literal>. The criteria above still apply, and
|
||||
it's in your interest to stick to them, since you're more likely to get
|
||||
good results that way.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title id="submit">How to submit a question</title>
|
||||
|
||||
<para>When submitting a question to FreeBSD-questions, consider the
|
||||
following points:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para> Remember that nobody gets paid for answering a FreeBSD
|
||||
question. They do it of their own free will. You can influence this
|
||||
free will positively by submitting a well-formulated question
|
||||
supplying as much relevant information as possible. You can
|
||||
influence this free will negatively by submitting an incomplete,
|
||||
illegible, or rude question. It's perfectly possible to send a
|
||||
message to FreeBSD-questions and not get an answer even if you
|
||||
follow these rules. It's much more possible to not get an answer if
|
||||
you don't. In the rest of this document, we'll look at how to get
|
||||
the most out of your question to FreeBSD-questions.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Not everybody who answers FreeBSD questions reads every message:
|
||||
they look at the subject line and decide whether it interests them.
|
||||
Clearly, it's in your interest to specify a subject. ``FreeBSD
|
||||
problem'' or ``Help'' aren't enough. If you provide no subject at
|
||||
all, many people won't bother reading it. If your subject isn't
|
||||
specific enough, the people who can answer it may not read
|
||||
it.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Format your message so that it is legible, and
|
||||
PLEASE DON'T SHOUT!!!!!. We appreciate that a lot of people don't
|
||||
speak English as their first language, and we try to make
|
||||
allowances for that, but it's really painful to try to read a
|
||||
message written full of typos or without any line breaks.</para>
|
||||
|
||||
<para>Don't underestimate the effect that a poorly formatted mail
|
||||
message has, not just on the FreeBSD-questions mailing list.
|
||||
Your mail message is all people see of you, and if it's poorly
|
||||
formatted, one line per paragraph, badly spelt, or full of
|
||||
errors, it will give people a poor impression of you.</para>
|
||||
|
||||
<para>A lot of badly formatted messages come from
|
||||
<ulink url="http://www.lemis.com/email.html">bad mailers or badly
|
||||
configured mailers</ulink>. The following mailers are known to
|
||||
send out badly formatted messages without you finding out about
|
||||
them:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>cc:Mail</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Eudora</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>exmh</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Microsoft Exchange</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Microsoft Internet Mail</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Microsoft Outlook</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Netscape</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>As you can see, the mailers in the Microsoft world are frequent
|
||||
offenders. If at all possible, use a UNIX mailer. If you must use a
|
||||
mailer under Microsoft environments, make sure it is set up
|
||||
correctly. Try not to use <acronym>MIME</acronym>: a lot of people
|
||||
use mailers which don't get on very well with
|
||||
<acronym>MIME</acronym>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Make sure your time and time zone are set correctly. This may
|
||||
seem a little silly, since your message still gets there, but many
|
||||
of the people you are trying to reach get several hundred messages a
|
||||
day. They frequently sort the incoming messages by subject and by
|
||||
date, and if your message doesn't come before the first answer, they
|
||||
may assume they missed it and not bother to look.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't include unrelated questions in the same message. Firstly,
|
||||
a long message tends to scare people off, and secondly, it's more
|
||||
difficult to get all the people who can answer all the questions to
|
||||
read the message.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Specify as much information as possible. This is a difficult
|
||||
area, and we need to expand on what information you need to submit,
|
||||
but here's a start:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>In nearly every case, it's important to know the version of
|
||||
FreeBSD you're running. This is particularly the case for
|
||||
FreeBSD-CURRENT, where you should also specify the date of the
|
||||
sources, though of course you shouldn't be sending questions
|
||||
about -CURRENT to FreeBSD-questions.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para>With any problem which <emphasis>could</emphasis> be
|
||||
hardware related, tell us about your hardware. In case of
|
||||
doubt, assume it's possible that it's hardware. What kind of
|
||||
CPU are you using? How fast? What motherboard? How much
|
||||
memory? What peripherals?</para>
|
||||
|
||||
<para>There's a judgement call here, of course, but the output of
|
||||
the &man.dmesg.8; command can frequently be very useful, since it
|
||||
tells not just what hardware you're running, but what version of
|
||||
FreeBSD as well.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you get error messages, don't say <quote>I get error
|
||||
messages</quote>, say (for example) <quote>I get the error
|
||||
message 'No route to host'</quote>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If your system panics, don't say <quote>My system
|
||||
panicked</quote>, say (for example) <quote>my system panicked
|
||||
with the message 'free vnode isn't'</quote>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you have difficulty installing FreeBSD, please tell us
|
||||
what hardware you have. In particular, it's important to know
|
||||
the IRQs and I/O addresses of the boards installed in your
|
||||
machine.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you have difficulty getting PPP to run, describe the
|
||||
configuration. Which version of PPP do you use? What kind of
|
||||
authentication do you have? Do you have a static or dynamic IP
|
||||
address? What kind of messages do you get in the log
|
||||
file?</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A lot of the information you need to supply is the output of
|
||||
programs, such as &man.dmesg.8;, or console messages, which usually
|
||||
appear in <filename>/var/log/messages</filename>. Don't try to copy
|
||||
this information by typing it in again; it's a real pain, and you're
|
||||
bound to make a mistake. To send log file contents, either make a
|
||||
copy of the file and use an editor to trim the information to what
|
||||
is relevant, or cut and paste into your message. For the output of
|
||||
programs like &man.dmesg.8;, redirect the output to a file and
|
||||
include that. For example,</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>dmesg > /tmp/dmesg.out</userinput></screen>
|
||||
|
||||
<para>This redirects the information to the file
|
||||
<filename>/tmp/dmesg.out</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you do all this, and you still don't get an answer, there
|
||||
could be other reasons. For example, the problem is so complicated
|
||||
that nobody knows the answer, or the person who does know the answer
|
||||
was offline. If you don't get an answer after, say, a week, it
|
||||
might help to re-send the message. If you don't get an answer to
|
||||
your second message, though, you're probably not going to get one
|
||||
from this forum. Resending the same message again and again will
|
||||
only make you unpopular.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>To summarize, let's assume you know the answer to the following
|
||||
question (yes, it's the same one in each case <literal>:-)</literal>.
|
||||
You choose which of these two questions you would be more prepared to
|
||||
answer:</para>
|
||||
|
||||
<example>
|
||||
<title>Message 1</title>
|
||||
|
||||
<literallayout class="monospaced">Subject: HELP!!?!??
|
||||
I just can't get hits damn silly FereBSD system to
|
||||
workd, and Im really good at this tsuff, but I have never seen
|
||||
anythign sho difficult to install, it jst wont work whatever I try
|
||||
so why don't y9ou guys tell me what I doing wrong.</literallayout>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Message 2</title>
|
||||
|
||||
<literallayout class="monospaced">Subject: Problems installing FreeBSD
|
||||
|
||||
I've just got the FreeBSD 2.1.5 CD-ROM from Walnut Creek, and I'm having a lot
|
||||
of difficulty installing it. I have a 66 MHz 486 with 16 MB of
|
||||
memory and an Adaptec 1540A SCSI board, a 1.2GB Quantum Fireball
|
||||
disk and a Toshiba 3501XA CD-ROM drive. The installation works just
|
||||
fine, but when I try to reboot the system, I get the message
|
||||
``Missing Operating System''.</literallayout>
|
||||
</example>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title id="followup">How to follow up to a question</title>
|
||||
|
||||
<para>Often you will want to send in additional information to a question
|
||||
you have already sent. The best way to do this is to reply to your
|
||||
original message. This has three advantages:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>You include the original message text, so people will know what
|
||||
you're talking about. Don't forget to trim unnecessary text out,
|
||||
though.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The text in the subject line stays the same (you did remember to
|
||||
put one in, didn't you?). Many mailers will sort messages by
|
||||
subject. This helps group messages together.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The message reference numbers in the header will refer to the
|
||||
previous message. Some mailers, such as
|
||||
<ulink url="http://www.mutt.org/">mutt</ulink>, can
|
||||
<emphasis>thread</emphasis> messages, showing the exact
|
||||
relationships between the messages.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title id="answer">How to answer a question</title>
|
||||
|
||||
|
||||
<para>Before you answer a question to FreeBSD-questions, consider:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>A lot of the points on submitting questions also apply to
|
||||
answering questions. Read them.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Has somebody already answered the question? The easiest way to
|
||||
check this is to sort your incoming mail by subject: then
|
||||
(hopefully) you'll see the question followed by any answers, all
|
||||
together.</para>
|
||||
|
||||
<para>If somebody has already answered it, it doesn't automatically
|
||||
mean that you shouldn't send another answer. But it makes sense to
|
||||
read all the other answers first.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Do you have something to contribute beyond what has already been
|
||||
said? In general, <quote>Yeah, me too</quote> answers don't help
|
||||
much, although there are exceptions, like when somebody is
|
||||
describing a problem he's having, and he doesn't know whether it's
|
||||
his fault or whether there's something wrong with the hardware or
|
||||
software. If you do send a <quote>me too</quote> answer, you should
|
||||
also include any further relevant information.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Are you sure you understand the question? Very frequently, the
|
||||
person who asks the question is confused or doesn't express himself
|
||||
very well. Even with the best understanding of the system, it's
|
||||
easy to send a reply which doesn't answer the question. This
|
||||
doesn't help: you'll leave the person who submitted the question
|
||||
more frustrated or confused than ever. If nobody else answers, and
|
||||
you're not too sure either, you can always ask for more
|
||||
information.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Are you sure your answer is correct?
|
||||
If not, wait a day or so. If nobody else comes up with a
|
||||
better answer, you can still reply and say, for example, <quote>I
|
||||
don't know if this is correct, but since nobody else has
|
||||
replied, why don't you try replacing your ATAPI CD-ROM with
|
||||
a frog?</quote>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Unless there's a good reason to do otherwise, reply to the
|
||||
sender and to FreeBSD-questions. Many people on the
|
||||
FreeBSD-questions are <quote>lurkers</quote>: they learn by reading
|
||||
messages sent and replied to by others. If you take a message which
|
||||
is of general interest off the list, you're depriving these people
|
||||
of their information. Be careful with group replies; lots of people
|
||||
send messages with hundreds of CCs. If this is the case, be sure to
|
||||
trim the Cc: lines appropriately.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Include relevant text from the original message. Trim it to the
|
||||
minimum, but don't overdo it. It should still be possible for
|
||||
somebody who didn't read the original message to understand what
|
||||
you're talking about.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Use some technique to identify which text came from the original
|
||||
message, and which text you add. I personally find that prepending
|
||||
<quote><literal>> </literal></quote> to the original message
|
||||
works best. Leaving white space after the
|
||||
<quote><literal>> </literal></quote> and leave empty lines
|
||||
between your text and the original text both make the result more
|
||||
readable.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Put your response in the correct place (after the text to which
|
||||
it replies). It's very difficult to read a thread of responses
|
||||
where each reply comes before the text to which it replies.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Most mailers change the subject line on a reply by prepending a
|
||||
text such as <quote>Re: </quote>. If your mailer doesn't do it
|
||||
automatically, you should do it manually.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If the submitter didn't abide by format conventions (lines too
|
||||
long, inappropriate subject line), <emphasis>please</emphasis> fix
|
||||
it. In the case of an incorrect subject line (such as
|
||||
<quote>HELP!!??</quote>), change the subject line to (say)
|
||||
<quote>Re: Difficulties with sync PPP (was: HELP!!??)</quote>. That
|
||||
way other people trying to follow the thread will have less
|
||||
difficulty following it.</para>
|
||||
|
||||
<para>In such cases, it's appropriate to say what you did and why you
|
||||
did it, but try not to be rude. If you find you can't answer
|
||||
without being rude, don't answer.</para>
|
||||
|
||||
<para>If you just want to reply to a message because of its bad
|
||||
format, just reply to the submitter, not to the list. You can just
|
||||
send him this message in reply, if you like.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
</article>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
End:
|
||||
-->
|
||||
@ -1,16 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
DOCFORMAT= html
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,297 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<title>Independent Verification of IPSec Functionality in FreeBSD</title>
|
||||
</head>
|
||||
|
||||
<body text="#000000" bgcolor="#FFFFFF">
|
||||
|
||||
<h1>Independent Verification of IPsec Functionality Under FreeBSD 3.0</h1>
|
||||
|
||||
<p align="center"><i>You installed IPsec and it seems to be working.
|
||||
How do you know? I describe a method for experimentally verifying
|
||||
that IPsec is working</i></p>
|
||||
|
||||
<h2>The Problem</h2>
|
||||
|
||||
<p>First, let's assume you have <a href="#Installing IPsec">installed
|
||||
<i>IPsec</i></a>. How do you know its <a href="#Caveat">working</a>?
|
||||
Sure, your connection won't work if its misconfigured, and it will work
|
||||
when you finally get it right. <i>Netstat</i> will list it. But can you
|
||||
independently confirm it?</p>
|
||||
|
||||
<h2>The Solution</h2>
|
||||
|
||||
<p>First, some crypto-relevent info theory:</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
<p>Encrypted data is uniformly distributed, ie, has maximal entropy
|
||||
per symbol.</p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>Raw, uncompressed data is typically redundant, i.e., has
|
||||
sub-maximal entropy.</p>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>Suppose you could measure the entropy of the data to- and from- your
|
||||
network interface. Then you could see the difference between unencrypted
|
||||
data and encrypted data. This would be true even if some of the data
|
||||
in "encrypted mode" was not encrypted ---as the outermost IP header must
|
||||
be, if the packet is to be routable.</p>
|
||||
|
||||
<h4><a name="MUST"></a>MUST</h4>
|
||||
|
||||
<p>Ueli Maurer's "Universal Statistical Test for Random Bit Generators"
|
||||
("MUST") quickly measures the entropy of a sample. It uses a
|
||||
compression-like algorithm. <a href="#Maurer's Universal Statistical
|
||||
Test">The code is given below for a variant which measures successive
|
||||
(~quarter megabyte) chunks of a file</a>.</p>
|
||||
|
||||
<h4><a NAME="Tcpdump"></a>Tcpdump</h4>
|
||||
|
||||
<p>We also need a way to capture the raw network data. A program called
|
||||
"<i>tcpdump</i>" lets you do this, if you have enabled the <i>Berkeley
|
||||
Packet Filter</i> interface in your <a
|
||||
href="#KERNELNAME">kernel's config file</a>.</p>
|
||||
|
||||
<p>The command</p>
|
||||
|
||||
<blockquote><b>tcpdump</b> <b>-c</b> 4000 <b>-s</b> 10000 <b>-w</b>
|
||||
<i>dumpfile.bin</i></blockquote>
|
||||
|
||||
<p>will capture 4000 raw packets to <i>dumpfile.bin</i>. Up to 10,000
|
||||
bytes per packet will be captured in this example.</p>
|
||||
|
||||
<h2>The Experiment</h2>
|
||||
|
||||
<p>Here's the experiment. Open a window to an IPsec host and another
|
||||
window to an insecure host.</p>
|
||||
|
||||
<p>Now start <a href="#Tcpdump">capturing packets</a>.</p>
|
||||
|
||||
<p>In the "secure" window, run the unix command "yes", which will stream
|
||||
the "y" character. After a while, stop this. Switch to the insecure
|
||||
window, and repeat. After a while, stop.</p>
|
||||
|
||||
<p>Now run <a href="#Maurer's Universal Statistical Test">MUST</a> on the
|
||||
captured packets. You should see something like the the following.
|
||||
The important thing to note is that the secure connection has 93% (6.7)
|
||||
of the expected value (7.18), and the "normal" connection has 29% (2.1)
|
||||
of the expected value.</p>
|
||||
|
||||
|
||||
<pre>% tcpdump -c 4000 -s 10000 -w ipsecdemo.bin
|
||||
% uliscan ipsecdemo.bin
|
||||
|
||||
Uliscan 21 Dec 98
|
||||
L=8 256 258560
|
||||
Measuring file ipsecdemo.bin
|
||||
Init done
|
||||
Expected value for L=8 is 7.1836656
|
||||
6.9396 --------------------------------------------------------
|
||||
6.6177 -----------------------------------------------------
|
||||
6.4100 ---------------------------------------------------
|
||||
2.1101 -----------------
|
||||
2.0838 -----------------
|
||||
2.0983 -----------------</pre>
|
||||
|
||||
<h2><a NAME="Caveat"></a>Caveat</h2>
|
||||
|
||||
<p>This experiment shows that IPsec <i>does</i> seem to be distributing the
|
||||
payload data <i>uniformly</i>, as encryption should. However, the
|
||||
experiment described here <i>can not </i>detect many possible flaws in a
|
||||
system (none of which do I have any evidence for). These include poor
|
||||
key generation or exchange, data or keys being visible to others, use of
|
||||
weak algorithms, kernel subversion, etc. Study the source; know the
|
||||
code.</p>
|
||||
|
||||
<h2><a NAME="IPsec"></a>IPsec -Definition</h2>
|
||||
|
||||
<p>Internet Protocol security extensions to IP v 4; required for IP v6. A
|
||||
protocol for negotiating encryption and authentication at the IP
|
||||
(host-to-host) level. SSL secures only one application socket; SSH
|
||||
secures only a login; PGP secures only a specified file or
|
||||
message. IPsec encrypts everything between two hosts.</p>
|
||||
|
||||
<h2><a NAME="Installing IPsec"></a>Installing IPsec</h2>
|
||||
|
||||
<p>Starting from the BSD 3.0 stable release,</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
<p>install IPsec v0.04, rebuild, reinstall</p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>run the administration tools (e.g, <i>ipsecadm</i>) and distribute
|
||||
keys (or use <i>Photuris</i> for key exchange)</p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<p>set the routes (<i>rt</i>) up appropriately</p>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>You may want to make an "ipsec_setup" script containing the
|
||||
<i>ipsecadm</i> and <i>rt</i> commands which establish your IPsec
|
||||
tunnel. You can run this script automatically at boottime from your
|
||||
<i>/etc/rc.local</i> The ipsec_setup script will have to contain at
|
||||
least two <i>ipsecadm</i> commands and one <i>rt</i> command to be
|
||||
useful.</p>
|
||||
|
||||
<h2><a NAME="KERNELNAME"></a>usr/src/sys/i386/conf/KERNELNAME</h2>
|
||||
|
||||
<p>This needs to be present in the kernel config file in order to run
|
||||
IPsec. After adding it, run <i>config</i>, etc. and rebuild and
|
||||
reinstall.</p>
|
||||
|
||||
<pre># The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be
|
||||
# aware of the legal and administrative consequences of enabling this
|
||||
# option. Heh heh. The number of devices determines the maximum number of
|
||||
# simultaneous BPF clients programs runnable.
|
||||
pseudo-device bpfilter 2 #Berkeley packet filter
|
||||
|
||||
# IPSEC
|
||||
options IPSEC
|
||||
options "MD5"
|
||||
pseudo-device enc 1</pre>
|
||||
|
||||
<h2><a name="Maurer's Universal Statistical Test"></a>Maurer's Universal Statistical Test (for block
|
||||
size=8 bits)</h2>
|
||||
|
||||
<pre><![ CDATA [/*
|
||||
ULISCAN.c ---blocksize of 8
|
||||
|
||||
1 Oct 98
|
||||
1 Dec 98
|
||||
21 Dec 98 uliscan.c derived from ueli8.c
|
||||
|
||||
This version has // comments removed for Sun cc
|
||||
|
||||
This implements Ueli M Maurer's "Universal Statistical Test for Random
|
||||
Bit Generators" using L=8
|
||||
|
||||
Accepts a filename on the command line; writes its results, with other
|
||||
info, to stdout.
|
||||
|
||||
Handles input file exhaustion gracefully.
|
||||
|
||||
Ref: J. Cryptology v 5 no 2, 1992 pp 89-105
|
||||
also on the web somewhere, which is where I found it.
|
||||
|
||||
-David Honig
|
||||
honig@sprynet.com
|
||||
|
||||
Usage:
|
||||
ULISCAN filename
|
||||
outputs to stdout
|
||||
*/
|
||||
|
||||
#define L 8
|
||||
#define V (1<<L)
|
||||
#define Q (10*V)
|
||||
#define K (100 *Q)
|
||||
#define MAXSAMP (Q + K)
|
||||
|
||||
#include <stdio.h>
|
||||
#include <math.h>
|
||||
|
||||
int main(argc, argv)
|
||||
int argc;
|
||||
char **argv;
|
||||
{
|
||||
FILE *fptr;
|
||||
int i,j;
|
||||
int b, c;
|
||||
int table[V];
|
||||
double sum = 0.0;
|
||||
int iproduct = 1;
|
||||
int run;
|
||||
|
||||
extern double log(/* double x */);
|
||||
|
||||
printf("Uliscan 21 Dec 98 \nL=%d %d %d \n", L, V, MAXSAMP);
|
||||
|
||||
if (argc < 2) {
|
||||
printf("Usage: Uliscan filename\n");
|
||||
exit(-1);
|
||||
} else {
|
||||
printf("Measuring file %s\n", argv[1]);
|
||||
}
|
||||
|
||||
fptr = fopen(argv[1],"rb");
|
||||
|
||||
if (fptr == NULL) {
|
||||
printf("Can't find %s\n", argv[1]);
|
||||
exit(-1);
|
||||
}
|
||||
|
||||
for (i = 0; i < V; i++) {
|
||||
table[i] = 0;
|
||||
}
|
||||
|
||||
for (i = 0; i < Q; i++) {
|
||||
b = fgetc(fptr);
|
||||
table[b] = i;
|
||||
}
|
||||
|
||||
printf("Init done\n");
|
||||
|
||||
printf("Expected value for L=8 is 7.1836656\n");
|
||||
|
||||
run = 1;
|
||||
|
||||
while (run) {
|
||||
sum = 0.0;
|
||||
iproduct = 1;
|
||||
|
||||
if (run)
|
||||
for (i = Q; run && i < Q + K; i++) {
|
||||
j = i;
|
||||
b = fgetc(fptr);
|
||||
|
||||
if (b < 0)
|
||||
run = 0;
|
||||
|
||||
if (run) {
|
||||
if (table[b] > j)
|
||||
j += K;
|
||||
|
||||
sum += log((double)(j-table[b]));
|
||||
|
||||
table[b] = i;
|
||||
}
|
||||
}
|
||||
|
||||
if (!run)
|
||||
printf("Premature end of file; read %d blocks.\n", i - Q);
|
||||
|
||||
sum = (sum/((double)(i - Q))) / log(2.0);
|
||||
printf("%4.4f ", sum);
|
||||
|
||||
for (i = 0; i < (int)(sum*8.0 + 0.50); i++)
|
||||
printf("-");
|
||||
|
||||
printf("\n");
|
||||
|
||||
/* refill initial table */
|
||||
if (0) {
|
||||
for (i = 0; i < Q; i++) {
|
||||
b = fgetc(fptr);
|
||||
if (b < 0) {
|
||||
run = 0;
|
||||
} else {
|
||||
table[b] = i;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}]]></pre>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
@ -1,14 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,782 +0,0 @@
|
||||
<!-- $FreeBSD: doc/en_US.ISO_8859-1/articles/mh/article.sgml,v 1.8 2000/07/26 18:24:49 jim Exp $ -->
|
||||
<!-- FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN">
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>An MH Primer</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Matt</firstname>
|
||||
|
||||
<surname>Midboe</surname>
|
||||
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>matt@garply.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>v1.0, 16 January 1996</pubdate>
|
||||
|
||||
<abstract>
|
||||
<para>This document contains an introduction to using MH on
|
||||
FreeBSD</para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<sect1 id="mhintro">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>MH started back in 1977 at the RAND Corporation, where the
|
||||
initial philosophies behind MH were developed. MH isn't so much
|
||||
a monolithic email program but a philosophy about how best to
|
||||
develop tools for reading email. The MH developers have done a
|
||||
great job adhering to the <acronym>KISS</acronym> principle: Keep It
|
||||
Simple Stupid. Rather than have one large program for reading,
|
||||
sending and handling email they have written specialized
|
||||
programs for each part of your email life. One might liken MH to
|
||||
the specialization that one finds in insects and nature. Each
|
||||
tool in MH does one thing, and does it very well.</para>
|
||||
|
||||
<para>Beyond just the various tools that one uses to handle their
|
||||
email MH has done an excellent job keeping the configuration of
|
||||
each of these tools consistent and uniform. In fact, if you are
|
||||
not quite sure how something is supposed to work or what the
|
||||
arguments for some command are supposed to be then you can
|
||||
generally guess and be right. Each MH command is consistent
|
||||
about how it handles reading the configuration files and how it
|
||||
takes arguments on the command line. One useful thing to
|
||||
remember is that you can always add a <option>-help</option> to
|
||||
the command to have it display the options for that
|
||||
command.</para>
|
||||
|
||||
<para>The first thing that you need to do is to make sure that you
|
||||
have installed the MH package on your FreeBSD machine. If you
|
||||
installed from CDROM you should be able to execute the following
|
||||
to load mh:
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.root; <userinput>pkg_add /cdrom/packages/mh-6.8.3.tgz</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
You will notice that it created a <filename>/usr/local/lib/mh</filename>
|
||||
directory for you as well as adding several binaries to the
|
||||
<filename>/usr/local/bin</filename> directory. If you would prefer to
|
||||
compile it yourself then you can anonymous ftp it from <ulink
|
||||
URL="ftp://ftp.ics.uci.edu/">ftp.ics.uci.edu</ulink> or <ulink
|
||||
URL="ftp://louie.udel.edu/">louie.udel.edu</ulink>.</para>
|
||||
|
||||
<para>This primer is not a full comprehensive explanation of how
|
||||
MH works. This is just intended to get you started on the road
|
||||
to happier, faster mail reading. You should read the man pages
|
||||
for the various commands. Also you might want to read the <ulink
|
||||
URL="news:comp.mail.mh">comp.mail.mh</ulink> newsgroup. Also
|
||||
you can read the <ulink
|
||||
URL="http://www.cis.ohio-state.edu/hypertext/faq/usenet/mh-faq/part1/faq.html">FAQ
|
||||
for MH</ulink>. The best resource for MH is the O'Reilly and
|
||||
Associates book written by Jerry Peek.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Reading Mail</title>
|
||||
|
||||
<para>This section covers how to use <command>inc</command>,
|
||||
<command>show</command>, <command>scan</command>, <command>next</command>,
|
||||
<command>prev</command>, <command>rmm</command>, <command>rmf</command>, and
|
||||
<command>msgchk</command>. One of the best things about MH is the
|
||||
consistent interface between programs. A few things to keep in
|
||||
mind when using these commands is how to specify message lists.
|
||||
In the case of <command>inc</command> this doesn't really make any
|
||||
sense but with commands like <command>show</command> it is useful to
|
||||
know. </para>
|
||||
|
||||
<para>A message list can consist of something like <parameter>23
|
||||
20 16</parameter> which will act on messages 23, 20 and 16. This is
|
||||
fairly simple but you can do more useful things like
|
||||
<parameter>23-30</parameter> which will act on all the messages between
|
||||
23 and 30. You can also specify something like
|
||||
<parameter>cur:10</parameter> which will act on the current message and
|
||||
the next 9 messages. The <parameter>cur</parameter>, <parameter>last</parameter>,
|
||||
and <parameter>first</parameter> messages are special messages that refer
|
||||
to the current, last or first message in the folder.</para>
|
||||
|
||||
<sect2 id="inc">
|
||||
<title><command>inc</command>, <command>msgchk</command>—read in your
|
||||
new email or check it</title>
|
||||
|
||||
<para>If you just type in <userinput>inc</userinput> and hit
|
||||
<keycap>return</keycap> you will be well on your way to getting
|
||||
started with MH. The first time you run <command>inc</command> it
|
||||
will setup your account to use all the MH defaults and ask you
|
||||
about creating a Mail directory. If you have mail waiting to
|
||||
be downloaded you will see something that looks like:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen> 29 01/15 Doug White Re: Another Failed to boot problem<<On Mon, 15 J
|
||||
30 01/16 "Jordan K. Hubbar Re: FBSD 2.1<<> Do you want a library instead of
|
||||
31 01/16 Bruce Evans Re: location of bad144 table<<>> >It would appea
|
||||
32 01/16 "Jordan K. Hubbar Re: video is up<<> Anyway, mrouted won't run, ev
|
||||
33 01/16 Michael Smith Re: FBSD 2.1<<Nate Williams stands accused of sa
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This is the same thing you will see from a
|
||||
<command>scan</command> (see <xref linkend="scan">). If you just run
|
||||
<command>inc</command> with no arguments it will look on your
|
||||
computer for email that is supposed to be coming to
|
||||
you.</para>
|
||||
|
||||
<para>A lot of people like to use POP for grabbing their email.
|
||||
MH can do POP to grab your email. You will need to give
|
||||
<command>inc</command> a few command line arguments.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>inc -host mail.pop.org -user <replaceable>username</> -norpop</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>That tells <command>inc</command> to go to
|
||||
<parameter>mail.pop.org</parameter> to download your email, and that
|
||||
your username on their system is <replaceable>username</replaceable>. The
|
||||
<option>-norpop</option> option tells <command>inc</command> to use
|
||||
plain POP3 for downloading your email. MH has support for a
|
||||
few different dialects of POP. More than likely you will never
|
||||
ever need to use them though. While you can do more complex
|
||||
things with inc such as audit files and scan format files this
|
||||
will get you going.</para>
|
||||
|
||||
<para>The <command>msgchk</command> command is used to get information
|
||||
on whether or not you have new email. <command>msgchk</command> takes
|
||||
the same <option>-host</option> and <option>-user</option>
|
||||
options that <command>inc</command> takes.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="show">
|
||||
<title><command>show</command>, <command>next</command> and
|
||||
<command>prev</command>—displaying and moving through
|
||||
email</title>
|
||||
|
||||
<para><command>show</command> is to show a letter in your current
|
||||
folder. Like <command>inc</command>, <command>show</command> is a fairly
|
||||
straightforward command. If you just type <userinput>show</userinput>
|
||||
and hit <keycap>return</keycap> then it displays the current
|
||||
message. You can also give specific message numbers to
|
||||
show:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>show 32 45 56</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This would display message numbers 32, 45 and 56 right
|
||||
after each other. Unless you change the default behavior
|
||||
<command>show</command> basically just does a <command>more</command> on the
|
||||
email message.</para>
|
||||
|
||||
<para><command>next</command> is used to move onto the next message and
|
||||
<command>prev</command> will go to the previous message. Both
|
||||
commands have an implied <command>show</command> command so that when
|
||||
you go to the next message it automatically displays
|
||||
it.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="scan">
|
||||
<title><command>scan</command>—shows you a scan of your
|
||||
messages</title>
|
||||
|
||||
<para><command>scan</command> will display a brief listing of the
|
||||
messages in your current folder. This is an example of what
|
||||
the <command>scan</command> command will give you.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen> 30+ 01/16 "Jordan K. Hubbar Re: FBSD 2.1<<> Do you want a library instead of
|
||||
31 01/16 Bruce Evans Re: location of bad144 table<<>> >It would appea
|
||||
32 01/16 "Jordan K. Hubbar Re: video is up<<> Anyway, mrouted won't run, ev
|
||||
33 01/16 Michael Smith Re: FBSD 2.1<<Nate Williams stands accused of sa
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Like just about everything in MH this display is very
|
||||
configurable. This is the typical default display. It gives
|
||||
you the message number, the date on the email, the sender, the
|
||||
subject line, and a sentence fragment from the very beginning
|
||||
of the email if it can fit it. The <literal>+</literal> means that
|
||||
message is the current message, so if you do a
|
||||
<command>show</command> it will display that message.</para>
|
||||
|
||||
<para>One useful option for scan is the
|
||||
<option>-reverse</option> option. This will list your messages
|
||||
with the highest message number first and lowest message
|
||||
number last. Another useful option with <command>scan</command> is to
|
||||
have it read from a file. If you want to scan your incoming
|
||||
mailbox on FreeBSD without having to <command>inc</command> it you
|
||||
can do <command>scan -file
|
||||
/var/mail/<replaceable>username</replaceable></command>. This can be used
|
||||
with any file that is in the <database>mbox</database> format.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="rmm">
|
||||
<title><command>rmm</command> and <command>rmf</command>—remove the
|
||||
current message or folder</title>
|
||||
|
||||
<para><command>rmm</command> is used to remove a mail message. The
|
||||
default is typically to not actually remove the message but to
|
||||
rename the file to one that is ignored by the MH commands. You
|
||||
will need to through periodically and physically delete the
|
||||
<quote>removed</quote> messages.</para>
|
||||
|
||||
<para>The <command>rmf</command> command is used to remove folders.
|
||||
This doesn't just rename the files but actually removes the
|
||||
from the hard drive so you should be careful when you use this
|
||||
command.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="samplereading">
|
||||
<title>A typical session of reading with MH</title>
|
||||
|
||||
<para>The first thing that you will want to do is
|
||||
<command>inc</command> your new mail. So at a shell prompt just type
|
||||
in <command>inc</command> and hit <keycap>return</keycap>.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>inc</>
|
||||
Incorporating new mail into inbox...
|
||||
|
||||
36+ 01/19 "Stephen L. Lange Request...<<Please remove me as contact for pind
|
||||
37 01/19 Matt Thomas Re: kern/950: Two PCI bridge chips fail (multipl
|
||||
38 01/19 "Amancio Hasty Jr Re: FreeBSD and VAT<<>>> Bill Fenner said: > In
|
||||
&prompt.user;
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This shows you the new email that has been added to your
|
||||
mailbox. So the next thing to do is <command>show</command> the email
|
||||
and move around.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>show</>
|
||||
Received: by sashimi.wwa.com (Smail3.1.29.1 #2)
|
||||
id m0tdMZ2-001W2UC; Fri, 19 Jan 96 13:33 CST
|
||||
Date: Fri, 19 Jan 1996 13:33:31 -0600 (CST)
|
||||
From: "Stephen L. Lange" <stvlange@wwa.com>
|
||||
To: matt@garply.com
|
||||
Subject: Request...
|
||||
Message-Id: <Pine.BSD.3.91.960119133211.824A-100000@sashimi.wwa.com>
|
||||
Mime-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
|
||||
|
||||
Please remove me as contact for pindat.com
|
||||
|
||||
&prompt.user; <userinput>rmm</>
|
||||
&prompt.user; <userinput>next</>
|
||||
Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8
|
||||
.6.9) with SMTP id RAA24416; Fri, 19 Jan 1996 17:56:48 GMT
|
||||
Message-Id: <199601191756.RAA24416@whydos.lkg.dec.com>
|
||||
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO pro
|
||||
tocol
|
||||
To: hsu@clinet.fi
|
||||
Cc: hackers@FreeBSD.org
|
||||
Subject: Re: kern/950: Two PCI bridge chips fail (multiple multiport ethernet
|
||||
boards)
|
||||
In-Reply-To: Your message of "Fri, 19 Jan 1996 00:18:36 +0100."
|
||||
<199601182318.AA11772@Sysiphos>
|
||||
X-Mailer: exmh version 1.5omega 10/6/94
|
||||
Date: Fri, 19 Jan 1996 17:56:40 +0000
|
||||
From: Matt Thomas <matt@lkg.dec.com>
|
||||
Sender: owner-hackers@FreeBSD.org
|
||||
Precedence: bulk
|
||||
|
||||
|
||||
This is due to a typo in pcireg.h (to
|
||||
which I am probably the guilty party).
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The <command>rmm</command> removed the current message and the
|
||||
<command>next</command> command moved me on to the next message. Now
|
||||
if I wanted to look at ten most recent messages so I could
|
||||
read one of them here is what I would do:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>scan last:10</>
|
||||
26 01/16 maddy Re: Testing some stuff<<yeah, well, Trinity has
|
||||
27 01/17 Automatic digest NET-HAPPENINGS Digest - 16 Jan 1996 to 17 Jan 19
|
||||
28 01/17 Evans A Criswell Re: Hey dude<<>From matt@tempest.garply.com Tue
|
||||
29 01/16 Karl Heuer need configure/make volunteers<<The FSF is looki
|
||||
30 01/18 Paul Stephanouk Re: [alt.religion.scientology] Raw Meat (humor)<
|
||||
31 01/18 Bill Lenherr Re: Linux NIS Solaris<<--- On Thu, 18 Jan 1996 1
|
||||
34 01/19 John Fieber Re: Stuff for the email section?<<On Fri, 19 Jan
|
||||
35 01/19 support@foo.garpl [garply.com #1138] parlor<<Hello. This is the Ne
|
||||
37+ 01/19 Matt Thomas Re: kern/950: Two PCI bridge chips fail (multipl
|
||||
38 01/19 "Amancio Hasty Jr Re: FreeBSD and VAT<<>>> Bill Fenner said: > In
|
||||
&prompt.user;
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Then if I wanted to read message number 27 I would do a
|
||||
<userinput>show 27</userinput> and it would be displayed. As you can
|
||||
probably tell from this sample session MH is pretty easy to
|
||||
use and looking through emails and displaying them is fairly
|
||||
intuitive and easy.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Folders and Mail Searching</title>
|
||||
|
||||
<para>Anybody who gets lots of email definitely wants to be able
|
||||
to prioritize, stamp, brief, de-brief, and number their emails
|
||||
in a variety of different ways. MH can do this better than just
|
||||
about anything. One thing that we haven't really talked about is
|
||||
the concept of folders. You have undoubtedly come across the
|
||||
folders concept using other email programs. MH has folders too.
|
||||
MH can even do sub-folders of a folder. One thing you should
|
||||
keep in mind with MH is that when you ran <command>inc</command> for
|
||||
the first time and it asked you if it could create a
|
||||
<filename>Mail</filename> directory it began storing everything in that
|
||||
directory. If you look at that directory you will find a
|
||||
directory named <filename>inbox</filename>. The <filename>inbox</filename>
|
||||
directory houses all of your incoming mail that hasn't been
|
||||
thrown anywhere else.</para>
|
||||
|
||||
<para>Whenever you create a new folder a new directory is going to
|
||||
be created underneath your MH <filename>Mail</filename> directory, and
|
||||
messages in that folder are going to be stored in that
|
||||
directory. When new email comes in that new email is thrown
|
||||
into your <filename>inbox</filename> directory with a file name that is
|
||||
equivalent to the message number. So even if you didn't have
|
||||
any of the MH tools to read your email you could still use
|
||||
standard UNIX commands to munge around in those directories and
|
||||
just more your files. It's this simplicity that really gives you
|
||||
a lot of power with what you can do with your email.</para>
|
||||
|
||||
<para>Just as you can use message lists like <parameter>23 16
|
||||
42</parameter> with most MH commands there is a folder option you can
|
||||
specify with just about every MH command. If you do a
|
||||
<command>scan +freebsd</command> it will scan your <filename>freebsd</filename>
|
||||
folder, and your current folder will be changed to
|
||||
<filename>freebsd</filename>. If you do a <command>show +freebsd 23 16
|
||||
42</command>, <command>show</command> is going to switch to your
|
||||
<filename>freebsd</filename> folder and display messages 23, 16 and 42.
|
||||
So remember that <option>+<replaceable>folder</replaceable></option> syntax. You
|
||||
will need to make sure you use it to make commands process
|
||||
different folders. Remember you default folder for mail is
|
||||
<filename>inbox</filename> so doing a <command>folder +inbox</command> should
|
||||
always get you back to your mail. Of course, in MH's infinite
|
||||
flexibility this can be changed but most places have probably
|
||||
left it as <command>inbox</command>.</para>
|
||||
|
||||
<sect2>
|
||||
<title><command>pick</command>—search email that matches certain
|
||||
criteria</title>
|
||||
|
||||
<para><command>pick</command> is one of the more complex commands in
|
||||
the MH system. So you might want to read the
|
||||
<citerefentry><refentrytitle>pick</refentrytitle><manvolnum>1</manvolnum></citerefentry> man
|
||||
page for a more thorough understanding. At its simplest level
|
||||
you can do something like</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>pick -search pci</>
|
||||
15
|
||||
42
|
||||
55
|
||||
56
|
||||
57
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will tell <command>pick</command> to look through every
|
||||
single line in every message in your current folder and tell
|
||||
you which message numbers it found the word <literal>pci</literal>
|
||||
in. You can then <command>show</command> those messages and read them
|
||||
if you wish or <command>rmm</command> them. You would have to specify
|
||||
something like <command>show 15 42 55-57</command> to display them
|
||||
though. A slightly more useful thing to do is this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>pick -search pci -seq pick</>
|
||||
5 hits
|
||||
&prompt.user; <userinput>show pick</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>This will show you the same messages you just didn't have
|
||||
to work as hard to do it. The <option>-seq</option> option is
|
||||
really an abbreviation of <option>-sequence</option> and
|
||||
<command>pick</command> is just a sequence which contains the message
|
||||
numbers that matched. You can use sequences with just about
|
||||
any MH command. So you could have done an <command>rmm pick</command>
|
||||
and all those messages would be removed instead. You sequence
|
||||
can be named anything. If you run pick again it will overwrite
|
||||
the old sequence if you use the same name.</para>
|
||||
|
||||
<para>Doing a <command>pick -search</command> can be a bit more
|
||||
time consuming than just searching for message from someone,
|
||||
or to someone. So <command>pick</command> allows you to use the
|
||||
following predefined search criteria:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>-to</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>search based upon who the message is to</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-cc</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>search based on who is in the cc list</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-from</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>search for who sent the message</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-subject</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>search for emails with this subject</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-date</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>find emails with a matching dat</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--<replaceable>component</replaceable></option></term>
|
||||
|
||||
<listitem>
|
||||
<para>search for any other component in the header. (i.e.
|
||||
<option>--reply-to</option> to find all emails with a certain
|
||||
reply-to in the header)</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>This allows you to do things like
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>pick -to freebsd-hackers@FreeBSD.org -seq hackers</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
to get a list of all the email send to the FreeBSD hackers
|
||||
mailing list. <command>pick</command> also allows you to group these
|
||||
criteria in different ways using the following options:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>… <option>-and</option> …</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>… <option>-or</option> &hellip</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>-not</option> …</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><option>-lbrace</option> …
|
||||
<option>-rbrace</option></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>These commands allow you to do things like</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>pick -to freebsd-hackers -and -cc freebsd-hackers</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>That will grab all the email in your inbox that was sent
|
||||
to freebsd-hackers or cc'd to that list. The brace options
|
||||
allow you to group search criteria together. This is sometimes
|
||||
very necessary as in the following example</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>&prompt.user; <userinput>pick -lbrace -to freebsd-hackers -and
|
||||
-not -cc freebsd-questions -rbrace -and -subject pci</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>Basically this says <quote>pick (to freebsd-hackers and
|
||||
not cc'd on freebsd-questions) and the subject is
|
||||
pci</quote>. It should look through your folder and find
|
||||
all messages sent to the freebsd-hackers list that aren't cc'd
|
||||
to the freebsd-questions list that contain something on pci in
|
||||
the subject line. Ordinarily you might have to worry about
|
||||
something called operator precedence. Remember in math how you
|
||||
evaluate from left to right and you do multiplication and
|
||||
division first and addition and subtraction second? MH has the
|
||||
same type of rules for <command>pick</command>. It's fairly complex
|
||||
so you might want to study the man page. This document is just
|
||||
to help you get acquainted with MH.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title><command>folder</command>, <command>folders</command>,
|
||||
<command>refile</command>—three useful programs for folder
|
||||
maintenance</title>
|
||||
|
||||
<para>There are three programs which are primarily just for
|
||||
manipulating your folders. The <command>folder</command> program is
|
||||
used to switch between folders, pack them, and list them. At
|
||||
its simplest level you can do a <command>folder
|
||||
+<replaceable>newfolder</replaceable></command> and you will be switched into
|
||||
<replaceable>newfolder</replaceable>. From there on out all your MH
|
||||
commands like <command>comp</command>, <command>repl</command>,
|
||||
<command>scan</command>, and <command>show</command> will act on that
|
||||
<command>newfolder</command> folder.</para>
|
||||
|
||||
<para>Sometimes when you are reading and deleting messages you
|
||||
will develop <quote>holes</quote> in your folders. If you do a
|
||||
<command>scan</command> you might just see messages 34, 35, 36, 43,
|
||||
55, 56, 57, 80. If you do a <command>folder -pack</command>
|
||||
this will renumber all your messages so that there are no
|
||||
holes. It doesn't actually delete any messages though. So you
|
||||
may need to periodically go through and physically delete
|
||||
<command>rmm</command>'d messages.</para>
|
||||
|
||||
<para>If you need statistics on your folders you can do a
|
||||
<command>folders</command> or <command>folder -all</command> to list
|
||||
all your folders, how many messages they have, what the
|
||||
current message is in each one and so on. This line of stats
|
||||
it displays for all your folders is the same one you get when
|
||||
you change to a folder with <command>folder +foldername</command>. A
|
||||
<command>folders</command> command looks like this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen> Folder # of messages ( range ); cur msg (other files)
|
||||
announce has 1 message ( 1- 1).
|
||||
drafts has no messages.
|
||||
f-hackers has 43 messages ( 1- 43).
|
||||
f-questions has 16 messages ( 1- 16).
|
||||
inbox+ has 35 messages ( 1- 38); cur= 37.
|
||||
lists has 8 messages ( 1- 8).
|
||||
netfuture has 1 message ( 1- 1).
|
||||
out has 31 messages ( 1- 31).
|
||||
personal has 6 messages ( 1- 6).
|
||||
todo has 58 messages ( 1- 58); cur= 1.
|
||||
|
||||
TOTAL= 199 messages in 13 folders.
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>The <command>refile</command> command is what you use to move
|
||||
messages between folders. When you do something like
|
||||
<command>refile 23 +netfuture</command> message number 23 is moved
|
||||
into the <filename>netfuture</filename> folder. You could also do
|
||||
something like <command>refile 23 +netfuture/latest</command> which
|
||||
would put message number 23 in a subfolder called
|
||||
<filename>latest</filename> under the <filename>netfuture</filename> folder.
|
||||
If you want to keep a message in the current folder and link
|
||||
it you can do a <command>refile -link 23 +netfuture</command>
|
||||
which would keep 23 in your current <filename>inbox</filename> but
|
||||
also list in your <filename>netfuture</filename> folder. You are
|
||||
probably beginning to realize some of the really powerful
|
||||
things you can do with MH.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Sending Mail</title>
|
||||
|
||||
<para>Email is a two way street for most people so you want to be
|
||||
able to send something back. The way MH handles sending mail can
|
||||
be a bit difficult to follow at first, but it allows for
|
||||
incredible flexibility. The first thing MH does is to copy a
|
||||
components file into your outgoing email. A components file is
|
||||
basically a skeleton email letter with stuff like the To: and
|
||||
Subject: headers already in it. You are then sent into your
|
||||
editor where you fill in the header information and then type
|
||||
the body of your message below the dashed lines in the message.
|
||||
Then to the <command>whatnow</command> program. When you are at the
|
||||
<prompt>What now?</prompt> prompt you can tell it to
|
||||
<command>send</command>, <command>list</command>, <command>edit</command>,
|
||||
<command>edit</command>, <command>push</command>, and <command>quit</command>. Most
|
||||
of these commands are self-explanatory. So the message sending
|
||||
process involves copying a component file, editing your email,
|
||||
and then telling the <command>whatnow</command> program what to do with
|
||||
your email.</para>
|
||||
|
||||
<sect2>
|
||||
<title><command>comp</command>, <command>forw</command>,
|
||||
<command>reply</command>—compose, forward or reply to a message
|
||||
to someone</title>
|
||||
|
||||
<para>The <command>comp</command> program has a few useful command line
|
||||
options. The most important one to know right now is the
|
||||
<option>-editor</option> option. When MH is installed the
|
||||
default editor is usually a program called
|
||||
<command>prompter</command> which comes with MH. It's not a very
|
||||
exciting editor and basically just gets the job done. So when
|
||||
you go to compose a message to someone you might want to use
|
||||
<command>comp -editor /usr/bin/vi/</command> or <command>comp -editor
|
||||
/usr/local/bin/pico/</command> instead. Once you have run
|
||||
<emphasis>comp</emphasis> you are in your editor and you see
|
||||
something that looks like this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>To:
|
||||
cc:
|
||||
Subject:
|
||||
--------
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You need to put the person you are sending the mail to
|
||||
after the <literal>To:</literal> line. It works the same way for the
|
||||
other headers also, so you would need to put your subject
|
||||
after the <literal>Subject:</literal> line. Then you would just put
|
||||
the body of your message after the dashed lines. It may seem a
|
||||
bit simplistic since a lot of email programs have special
|
||||
requesters that ask you for this information but there really
|
||||
isn't any point to that. Plus this really gives you excellent
|
||||
flexibility.</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>To:<userinput>freebsd-rave@FreeBSD.org</>
|
||||
cc:
|
||||
Subject:<userinput>And on the 8th day God created the FreeBSD core team</>
|
||||
--------
|
||||
<userinput>Wow this is an amazing operating system. Thanks!</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>You can now save this message and exit your editor. You
|
||||
will see the <prompt>What now?</prompt> prompt and you can type in
|
||||
<userinput>send</userinput> or <userinput>s</userinput> and hit
|
||||
<keycap>return</keycap>. Then the FreeBSD core team will receive
|
||||
their just rewards. As I mentioned earlier you can also use
|
||||
other commands, for example <command>quit</command> if you don't want
|
||||
to send the message.</para>
|
||||
|
||||
<para>The <command>forw</command> command is stunningly similar. The
|
||||
big difference being that the message you are forwarding is
|
||||
automatically included in the outgoing message. When you run
|
||||
<command>forw</command> it will forward your current message. You can
|
||||
always tell it to forward something else by doing something
|
||||
like <command>forw 23</command> and then message number 23 will be
|
||||
put in your outgoing message instead of the current message.
|
||||
Beyond those small differences <command>forw</command> functions
|
||||
exactly the same as <command>comp</command>. You go through the exact
|
||||
same message sending process.</para>
|
||||
|
||||
<para>The <command>repl</command> command will reply to whatever your
|
||||
current message is, unless you give it a different message to
|
||||
reply to. <command>repl</command> will do its best to go ahead and
|
||||
fill in some of the email headers already. So you will notice
|
||||
that the <literal>To:</literal> header already has the address of the
|
||||
recipient in there. Also the <literal>Subject:</literal> line will
|
||||
already be filled in. You then go about the normal message
|
||||
composition process and you are done. One useful command line
|
||||
option to know here is the <option>-cc</option> option. You
|
||||
can use <parameter>all</parameter>, <parameter>to</parameter>, <parameter>cc</parameter>,
|
||||
<parameter>me</parameter> after the <option>-cc</option> option to have
|
||||
<command>repl</command> automatically add the various addresses to
|
||||
the cc list in the message. You have probably noticed that the
|
||||
original message isn't included. This is because most MH
|
||||
setups are configured to do this from the start.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title><filename>components</filename>, and
|
||||
<filename>replcomps</filename>—components files for
|
||||
<command>comp</command> and <command>repl</command></title>
|
||||
|
||||
<para>The <filename>components</filename> file is usually in
|
||||
<filename>/usr/local/lib/mh</filename>. You can copy that file
|
||||
into your MH Mail directory and edit to contain what you want
|
||||
it to contain. It is a fairly basic file. You have various
|
||||
email headers at the top, a dashed line and then nothing. The
|
||||
<command>comp</command> command just copies this
|
||||
<filename>components</filename> file and then edits it. You can add
|
||||
any kind of valid RFC822 header you want. For instance you
|
||||
could have something like this in your <filename>components</filename>
|
||||
file:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>To:
|
||||
Fcc: out
|
||||
Subject:
|
||||
X-Mailer: MH 6.8.3
|
||||
X-Home-Page: http://www.FreeBSD.org/
|
||||
-------
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>MH would then copy this components file and throw you into
|
||||
your editor. The <filename>components</filename> file is fairly
|
||||
simple. If you wanted to have a signature on those messages
|
||||
you would just put your signature in that
|
||||
<filename>components</filename> file.</para>
|
||||
|
||||
<para>The <filename>replcomps</filename> file is a bit more complex. The
|
||||
default <filename>replcomps</filename> looks like this:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>%(lit)%(formataddr %<{reply-to}%?{from}%?{sender}%?{return-path}%>)\
|
||||
%<(nonnull)%(void(width))%(putaddr To: )\n%>\
|
||||
%(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
|
||||
%<(nonnull)%(void(width))%(putaddr cc: )\n%>\
|
||||
%<{fcc}Fcc: %{fcc}\n%>\
|
||||
%<{subject}Subject: Re: %{subject}\n%>\
|
||||
%<{date}In-reply-to: Your message of "\
|
||||
%<(nodate{date})%{date}%|%(pretty{date})%>."%<{message-id}
|
||||
%{message-id}%>\n%>\
|
||||
--------
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>It's in the same basic format as the
|
||||
<filename>components</filename> file but it contains quite a few extra
|
||||
formatting codes. The <literal>%(lit)</literal> command makes room
|
||||
for the address. The <literal>%(formataddr</literal> is a function
|
||||
that returns a proper email address. The next part is
|
||||
<literal>%<</literal> which means if and the
|
||||
<literal>{reply-to}</literal> means the reply-to field in the
|
||||
original message. So that might be translated this way:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>%<<emphasis remap=bf>if</emphasis> {reply-to} <emphasis remap=bf>the original message has a reply-to</emphasis>
|
||||
then give that to formataddr, %? <emphasis remap=bf>else</emphasis> {from} <emphasis remap=bf>take the
|
||||
from address</emphasis>, %? <emphasis remap=bf>else</emphasis> {sender} <emphasis remap=bf>take the sender address</emphasis>, %?
|
||||
<emphasis remap=bf>else</emphasis> {return-path} <emphasis remap=bf>take the return-path from the original
|
||||
message</emphasis>, %> <emphasis remap=bf>endif</emphasis>.
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>As you can tell MH formatting can get rather involved. You
|
||||
can probably decipher what most of the other functions and
|
||||
variables mean. All of the information on writing these format
|
||||
strings is in the MH-Format man page. The really nice thing is
|
||||
that once you have built your customized
|
||||
<filename>replcomps</filename> file you won't need to touch it again.
|
||||
No other email program really gives you the power and
|
||||
flexibility that MH gives you.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</article>
|
||||
@ -1,14 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,743 +0,0 @@
|
||||
<!-- $FreeBSD: doc/en_US.ISO_8859-1/articles/multi-os/article.sgml,v 1.13 2000/07/26 18:24:49 jim Exp $ -->
|
||||
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN">
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Installing and Using FreeBSD With Other Operating Systems</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Jay</firstname>
|
||||
|
||||
<surname>Richmond</surname>
|
||||
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>jayrich@sysc.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>6 August 1996</pubdate>
|
||||
|
||||
<abstract>
|
||||
<para>This document discusses how to make FreeBSD coexist nicely
|
||||
with other popular operating systems such as Linux, MS-DOS,
|
||||
OS/2, and Windows 95. Special thanks to: Annelise Anderson
|
||||
<email>andrsn@stanford.edu</email>, Randall Hopper
|
||||
<email>rhh@ct.picker.com</email>, and Jordan K. Hubbard
|
||||
<email>jkh@time.cdrom.com</email></para>
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<sect1>
|
||||
<title>Overview</title>
|
||||
|
||||
<para>Most people can't fit these operating systems together
|
||||
comfortably without having a larger hard disk, so special
|
||||
information on large EIDE drives is included. Because there are
|
||||
so many combinations of possible operating systems and hard disk
|
||||
configurations, the <xref linkend="ch5"> section may be of the
|
||||
most use to you. It contains descriptions of specific working
|
||||
computer setups that use multiple operating systems.</para>
|
||||
|
||||
<para>This document assumes that you have already made room on
|
||||
your hard disk for an additional operating system. Any time you
|
||||
repartition your hard drive, you run the risk of destroying the
|
||||
data on the original partitions. However, if your hard drive is
|
||||
completely occupied by DOS, you might find the FIPS utility
|
||||
(included on the FreeBSD CD-ROM in the
|
||||
<filename>\TOOLS</filename> directory or via <ulink
|
||||
URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/tools">ftp</ulink>)
|
||||
useful. It lets you repartition your hard disk without
|
||||
destroying the data already on it. There is also a commercial
|
||||
program available called Partition Magic, which lets you size
|
||||
and delete partitions without consequence.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ch2">
|
||||
<title>Overview of Boot Managers</title>
|
||||
|
||||
<para>These are just brief descriptions of some of the different
|
||||
boot managers you may encounter. Depending on your computer
|
||||
setup, you may find it useful to use more than one of them on
|
||||
the same system.</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Boot Easy</term>
|
||||
|
||||
<listitem>
|
||||
<para>This is the default boot manager used with FreeBSD.
|
||||
It has the ability to boot most anything, including BSD,
|
||||
OS/2 (HPFS), Windows 95 (FAT and FAT32), and Linux.
|
||||
Partitions are selected with the function keys.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>OS/2 Boot Manager</term>
|
||||
|
||||
<listitem>
|
||||
<para>This will boot FAT, HPFS, FFS (FreeBSD), and EXT2
|
||||
(Linux). It will also boot FAT32 partitions. Partitions
|
||||
are selected using arrow keys. The OS/2 Boot Manager is
|
||||
the only one to use its own separate partition, unlike the
|
||||
others which use the master boot record (MBR). Therefore,
|
||||
it must be installed below the 1024th cylinder to avoid
|
||||
booting problems. It can boot Linux using LILO when it is
|
||||
part of the boot sector, not the MBR. Go to <ulink
|
||||
URL="http://www.linuxresources.com/LDP/HOWTO/HOWTO-INDEX.html">Linux
|
||||
HOWTOs</ulink> on the World Wide Web for more
|
||||
information on booting Linux with OS/2's boot
|
||||
manager.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>OS-BS</term>
|
||||
|
||||
<listitem>
|
||||
<para>This is an alternative to Boot Easy. It gives you more
|
||||
control over the booting process, with the ability to set
|
||||
the default partition to boot and the booting timeout.
|
||||
The beta version of this programs allows you to boot by
|
||||
selecting the OS with your arrow keys. It is included on
|
||||
the FreeBSD CD in the <filename>\TOOLS</filename>
|
||||
directory, and via <ulink
|
||||
URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/tools">ftp</ulink>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>LILO, or LInux LOader</term>
|
||||
|
||||
<listitem>
|
||||
<para>This is a limited boot manager. It will boot FreeBSD,
|
||||
though some customization work is required in the LILO
|
||||
configuration file.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<note id="fat32">
|
||||
<title>About FAT32</title>
|
||||
|
||||
<para>FAT32 is the replacement to the FAT filesystem included in
|
||||
Microsoft's OEM SR2 Beta release, which is expected to be
|
||||
utilitized on computers pre-loaded with Windows 95 towards the
|
||||
end of 1996. It converts the normal FAT file system and
|
||||
allows you to use smaller cluster sizes for larger hard
|
||||
drives. FAT32 also modifies the traditional FAT boot sector
|
||||
and allocation table, making it incompatible with some boot
|
||||
managers.</para>
|
||||
</note>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ch3">
|
||||
<title>A Typical Installation</title>
|
||||
|
||||
<para>Let's say I have two large EIDE hard drives, and I want to
|
||||
install FreeBSD, Linux, and Windows 95 on them.</para>
|
||||
|
||||
<para>Here's how I might do it using these hard disks:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename>/dev/wd0</filename> (first physical hard disk)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>/dev/wd1</filename> (second hard disk)</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Both disks have 1416 cylinders.</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<para>I boot from a MS-DOS or Windows 95 boot disk that
|
||||
contains the <filename>FDISK.EXE</filename> utility and make a small
|
||||
50 meg primary partition (35-40 for Windows 95, plus a
|
||||
little breathing room) on the first disk. Also create a
|
||||
larger partition on the second hard disk for my Windows
|
||||
applications and data.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>I reboot and install Windows 95 (easier said than done)
|
||||
on the <filename>C:</filename> partition.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>The next thing I do is install Linux. I'm not sure
|
||||
about all the distributions of Linux, but slackware includes
|
||||
LILO (see <xref linkend="ch2">). When I am partitioning out
|
||||
my hard disk with Linux <command>fdisk</command>, I would
|
||||
put all of Linux on the first drive (maybe 300 megs for a
|
||||
nice root partition and some swap space).</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>After I install Linux, and are prompted about installing
|
||||
LILO, make SURE that I install it on the boot sector of my
|
||||
root Linux partition, not in the MBR (master boot
|
||||
record).</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>The remaining hard disk space can go to FreeBSD. I also
|
||||
make sure that my FreeBSD root slice does not go beyond the
|
||||
1024th cylinder. (The 1024th cylinder is 528 megs into the
|
||||
disk with our hypothetical 720MB disks). I will use the
|
||||
rest of the hard drive (about 270 megs) for the
|
||||
<filename>/usr</filename> and <filename>/</filename> slices if I wish. The
|
||||
rest of the second hard disk (size depends on the amount of
|
||||
my Windows application/data partition that I created in step
|
||||
1 can go to the <filename>/usr/src</filename> slice and swap
|
||||
space.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When viewed with the Windows 95 <command>fdisk</command>
|
||||
utility, my hard drives should now look something like this:
|
||||
|
||||
<screen>
|
||||
---------------------------------------------------------------------
|
||||
|
||||
Display Partition Information
|
||||
|
||||
Current fixed disk drive: 1
|
||||
|
||||
Partition Status Type Volume_Label Mbytes System Usage
|
||||
C: 1 A PRI DOS 50 FAT** 7%
|
||||
2 A Non-DOS (Linux) 300 43%
|
||||
|
||||
Total disk space is 696 Mbytes (1 Mbyte = 1048576 bytes)
|
||||
|
||||
Press Esc to continue
|
||||
|
||||
---------------------------------------------------------------------
|
||||
|
||||
Display Partition Information
|
||||
|
||||
Current fixed disk drive: 2
|
||||
|
||||
Partition Status Type Volume_Label Mbytes System Usage
|
||||
D: 1 A PRI DOS 420 FAT** 60%
|
||||
|
||||
Total disk space is 696 Mbytes (1 Mbyte = 1048576 bytes)
|
||||
|
||||
Press Esc to continue
|
||||
|
||||
---------------------------------------------------------------------
|
||||
</screen>
|
||||
** May say FAT16 or FAT32 if you are using the OEM SR2
|
||||
update. See <xref linkend="ch2">).</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Install FreeBSD. I make sure to boot with my first hard
|
||||
disk set at <quote>NORMAL</quote> in the BIOS. If it is not,
|
||||
I'll have the enter my true disk geometry at boot time (to
|
||||
get this, boot Windows 95 and consult Microsoft Diagnostics
|
||||
(<filename>MSD.EXE</filename>), or check your BIOS) with the
|
||||
parameter <literal>hd0=1416,16,63</literal> where
|
||||
<replaceable>1416</replaceable> is the number of cylinders on my hard
|
||||
disk, <replaceable>16</replaceable> is the number of heads per track,
|
||||
and <replaceable>63</replaceable> is the number of sectors per track on
|
||||
the drive.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When partitioning out the hard disk, I make sure to
|
||||
install Boot Easy on the first disk. I don't worry about
|
||||
the second disk, nothing is booting off of it.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>When I reboot, Boot Easy should recognize my three
|
||||
bootable partitions as DOS (Windows 95), Linux, and BSD
|
||||
(FreeBSD).</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ch4">
|
||||
<title>Special Considerations</title>
|
||||
|
||||
<para>Most operating systems are very picky about where and how
|
||||
they are placed on the hard disk. Windows 95 and DOS need to be
|
||||
on the first primary partitiin on the first hard disk. OS/2 is
|
||||
the exception. It can be installed on the first or second disk
|
||||
in a primary or extended partition. If you are not sure, keep
|
||||
the beginning of the bootable partitions below the 1024th
|
||||
cylinder.</para>
|
||||
|
||||
<para>If you install Windows 95 on an existing BSD system, it will
|
||||
<quote>destroy</quote> the MBR, and you will have to reinstall your
|
||||
previous boot manager. Boot Easy can be reinstalled by using
|
||||
the BOOTINST.EXE utility included in the \TOOLS directory on the
|
||||
CD-ROM, and via <ulink
|
||||
URL="ftp://ftp.FreeBSD.org/pub/FreeBSD/tools">ftp</ulink>.
|
||||
You can also re-start the installation process and go to the
|
||||
partition editor. From there, mark the FreeBSD partition as
|
||||
bootable, select Boot Manager, and then type W to (W)rite out
|
||||
the information to the MBR. You can now reboot, and Boot Easy
|
||||
should then recognize Windows 95 as DOS.</para>
|
||||
|
||||
<para>Please keep in mind that OS/2 can read FAT and HPFS
|
||||
partitions, but not FFS (FreeBSD) or EXT2 (Linux) partitions.
|
||||
Likewise, Windows 95 can only read and write to FAT and FAT32
|
||||
(see <xref linkend="ch2">) partitions. FreeBSD can read most
|
||||
file systems, but currently cannot read HPFS partitions. Linux
|
||||
can read HPFS partitions, but can't write to them. Recent
|
||||
versions of the Linux kernel (2.x) can read and write to Windows
|
||||
95 VFAT partitions (VFAT is what gives Windows 95 long file
|
||||
names - it's pretty much the same as FAT). Linux can read and
|
||||
write to most file systems. Got that? I hope so.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ch5">
|
||||
<title>Examples</title>
|
||||
|
||||
<para><emphasis>(section needs work, please send your example to
|
||||
<email>jayrich@sysc.com</email>)</emphasis>.</para>
|
||||
|
||||
<para>FreeBSD+Win95: If you installed FreeBSD after Windows 95,
|
||||
you should see <literal>DOS</literal> on the Boot Easy menu. This is
|
||||
Windows 95. If you installed Windows 95 after FreeBSD, read
|
||||
<xref linkend="ch4"> above. As long as your hard disk does not
|
||||
have 1024 cylinders you should not have a problem booting. If
|
||||
one of your partitions goes beyond the 1024th cylinder however,
|
||||
and you get messages like <errorname>invalid system disk</errorname>
|
||||
under DOS (Windows 95) and FreeBSD will not boot, try looking
|
||||
for a setting in your BIOS called <quote>> 1024 cylinder
|
||||
support</quote> or <quote>NORMAL/LBA</quote> mode. DOS may need LBA
|
||||
(Logical Block Addressing) in order to boot correctly. If the
|
||||
idea of switching BIOS settings every time you boot up doesn't
|
||||
appeal to you, you can boot FreeBSD through DOS via the
|
||||
<filename>FBSDBOOT.EXE</filename> utility on the CD (It should find your
|
||||
FreeBSD partition and boot it.)</para>
|
||||
|
||||
<para>FreeBSD+OS/2+Win95: Nothing new here. OS/2's boot manger
|
||||
can boot all of these operating systems, so that shouldn't be a
|
||||
problem.</para>
|
||||
|
||||
<para>FreeBSD+Linux: You can also use Boot Easy to boot both
|
||||
operating systems.</para>
|
||||
|
||||
<para>FreeBSD+Linux+Win95: (see <xref linkend="ch3">)</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="sources">
|
||||
<title>Other Sources of Help</title>
|
||||
|
||||
<para>There are many <ulink
|
||||
URL="http://www.linuxresources.com/LDP/HOWTO/HOWTO-INDEX.html">Linux
|
||||
HOW-TOs</ulink> that deal with multiple operating systems on
|
||||
the same hard disk.</para>
|
||||
|
||||
<para>The <ulink
|
||||
URL="http://www.linuxresources.com/LDP/HOWTO/mini/Linux+DOS+Win95+OS2.html">Linux+DOS+Win95+OS2
|
||||
mini-HOWTO</ulink> offers help on configuring the OS/2 boot
|
||||
manager, and the <ulink
|
||||
URL="http://www.linuxresources.com/LDP/HOWTO/mini/Linux+FreeBSD.html">Linux+FreeBSD
|
||||
mini-HOWTO</ulink> might be interesting as well. The <ulink
|
||||
URL="http://www.in.net/~jkatz/win95/Linux-HOWTO.html">Linux-HOWTO</ulink>
|
||||
is also helpful.</para>
|
||||
|
||||
<para>The <ulink
|
||||
URL="http://www.dorsai.org/~dcl/publications/NTLDR_Hacking">NT
|
||||
Loader Hacking Guide</ulink> provides good information on
|
||||
multibooting Windows NT, '95, and DOS with other operating
|
||||
systems.</para>
|
||||
|
||||
<para>And Hale Landis's "How It Works" document pack contains some
|
||||
good info on all sorts of disk geometry and booting related
|
||||
topics. You can find it at
|
||||
<ulink
|
||||
URL="ftp://fission.dt.wdc.com/pub/otherdocs/pc_systems/how_it_works/allhiw.zip">ftp://fission.dt.wdc.com/pub/otherdocs/pc_systems/how_it_works/allhiw.zip</ulink>.</para>
|
||||
|
||||
<para>Finally, don't overlook FreeBSD's kernel documentation on
|
||||
the booting procedure, available in the kernel source
|
||||
distribution (it unpacks to <ulink
|
||||
URL="file:/usr/src/sys/i386/boot/biosboot/README.386BSD">file:/usr/src/sys/i386/boot/biosboot/README.386BSD</ulink>.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Technical Details</title>
|
||||
|
||||
<para><emphasis>(Contributed by Randall Hopper,
|
||||
<email>rhh@ct.picker.com</email>)</emphasis></para>
|
||||
|
||||
<para>This section attempts to give you enough basic information
|
||||
about your hard disks and the disk booting process so that you
|
||||
can troubleshoot most problems you might encounter when getting
|
||||
set up to boot several operating systems. It starts in pretty
|
||||
basic terms, so you may want to skim down in this section until
|
||||
it begins to look unfamiliar and then start reading.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Disk Primer</title>
|
||||
|
||||
<para>Three fundamental terms are used to describe the location
|
||||
of data on your hard disk: Cylinders, Heads, and Sectors.
|
||||
It's not particularly important to know what these terms
|
||||
relate to except to know that, together, they identify where
|
||||
data is physically on your disk.</para>
|
||||
|
||||
<para>Your disk has a particular number of cylinders, number of
|
||||
heads, and number of sectors per cylinder-head (a
|
||||
cylinder-head also known nown as a track). Collectively this
|
||||
information defines the "physical disk geometry" for your hard
|
||||
disk. There are typically 512 bytes per sector, and 63
|
||||
sectors per track, with the number of cylinders and heads
|
||||
varying widely from disk to disk. Thus you can figure the
|
||||
number of bytes of data that'll fit on your own disk by
|
||||
calculating:</para>
|
||||
|
||||
<informalexample>
|
||||
<para>(# of cylinders) × (# heads) × (63
|
||||
sectors/track) × (512 bytes/sect)</para>
|
||||
</informalexample>
|
||||
|
||||
<para>For example, on my 1.6 Gig Western Digital AC31600 EIDE hard
|
||||
disk,that's:</para>
|
||||
|
||||
<informalexample>
|
||||
<para>(3148 cyl) × (16 heads) × (63
|
||||
sectors/track) × (512 bytes/sect)</para>
|
||||
</informalexample>
|
||||
|
||||
<para>which is 1,624,670,208 bytes, or around 1.6 Gig.</para>
|
||||
|
||||
<para>You can find out the physical disk geometry (number of
|
||||
cylinders, heads, and sectors/track counts) for your hard
|
||||
disks using ATAID or other programs off the net. Your hard
|
||||
disk probably came with this information as well. Be careful
|
||||
though: if you're using BIOS LBA (see <xref
|
||||
linkend="limits">), you can't use just any program to get
|
||||
the physical geometry. This is because many programs (e.g.
|
||||
<filename>MSD.EXE</filename> or FreeBSD fdisk) don't identify the
|
||||
physical disk geometry; they instead report the
|
||||
<firstterm>translated geometry</firstterm> (virtual numbers from using
|
||||
LBA). Stay tuned for what that means.</para>
|
||||
|
||||
<para>One other useful thing about these terms. Given 3
|
||||
numbers—a cylinder number, a head number, and a
|
||||
sector-within-track number—you identify a specific
|
||||
absolute sector (a 512 byte block of data) on your disk.
|
||||
Cylinders and Heads are numbered up from 0, and Sectors are
|
||||
numbered up from 1.</para>
|
||||
|
||||
<para>For those that are interested in more technical details,
|
||||
information on disk geometry, boot sectors, BIOSes, etc. can
|
||||
be found all over the net. Query Lycos, Yahoo, etc. for
|
||||
<literal>boot sector</literal> or <literal>master boot record</literal>.
|
||||
Among the useful info you'll find are Hale Landis's
|
||||
<citetitle>How It Works</citetitle> document pack. See the <xref
|
||||
linkend="sources"> section for a few pointers to this
|
||||
pack.</para>
|
||||
|
||||
<para>Ok, enough terminology. We're talking about booting
|
||||
here.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="booting">
|
||||
<title>The Booting Process</title>
|
||||
|
||||
<para>On the first sector of your disk (Cyl 0, Head 0, Sector 1)
|
||||
lives the Master Boot Record (MBR). It contains a map of your
|
||||
disk. It identifies up to 4 <firstterm>partitions</firstterm>, each of
|
||||
which is a contiguous chunk of that disk. FreeBSD calls
|
||||
partitions <firstterm>slices</firstterm> to avoid confusion with it's
|
||||
own partitions, but we won't do that here. Each partition can
|
||||
contain its own operating system.</para>
|
||||
|
||||
<para>Each partition entry in the MBR has a <firstterm>Partition
|
||||
ID</firstterm>, a <firstterm>Start Cylinder/Head/Sector</firstterm>, and an
|
||||
<firstterm>End Cylinder/Head/Sector</firstterm>. The Partition ID
|
||||
tells what type of partition it is (what OS) and the Start/End
|
||||
tells where it is. <xref linkend="tbl-pid"> lists a
|
||||
smattering of some common Partition IDs.</para>
|
||||
|
||||
<table id="tbl-pid">
|
||||
<title>Partition IDs</title>
|
||||
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>ID (hex)</entry>
|
||||
<entry>Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>01</entry>
|
||||
<entry>Primary DOS12 (12-bit FAT)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>04</entry>
|
||||
<entry>Primary DOS16 (16-bit FAT)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>05</entry>
|
||||
<entry>Extended DOS</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>06</entry>
|
||||
<entry>Primary big DOS (> 32MB)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>0A</entry>
|
||||
<entry>OS/2</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>83</entry>
|
||||
<entry>Linux (EXT2FS)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>A5</entry>
|
||||
<entry>FreeBSD, NetBSD, 386BSD (UFS)</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>Note that not all partitions are bootable (e.g. Extended
|
||||
DOS). Some are—some aren't. What makes a partition
|
||||
bootable is the configuration of the <firstterm>Partition Boot
|
||||
Sector</firstterm> that exists at the beginning of each
|
||||
partition.</para>
|
||||
|
||||
<para>When you configure your favorite boot manager, it looks up
|
||||
the entries in the MBR partition tables of all your hard disks
|
||||
and lets you name the entries in that list. Then when you
|
||||
boot, the boot manager is invoked by special code in the
|
||||
Master Boot Sector of the first probed hard disk on your
|
||||
system. It looks at the MBR partition table entry
|
||||
corresponding to the partition choice you made, uses the Start
|
||||
Cylinder/Head/Sector information for that partition, loads up
|
||||
the Partition Boot Sector for that partition, and gives it
|
||||
control. That Boot Sector for the partition itself contains
|
||||
enough information to start loading the operating system on
|
||||
that partition.</para>
|
||||
|
||||
<para>One thing we just brushed past that's important to know.
|
||||
All of your hard disks have MBRs. However, the one that's
|
||||
important is the one on the disk that's first probed by the
|
||||
BIOS. If you have only IDE hard disks, its the first IDE disk
|
||||
(e.g. primary disk on first controller). Similarly for SCSI
|
||||
only systems. If you have both IDE and SCSI hard disks
|
||||
though, the IDE disk is typically probed first by the BIOS, so
|
||||
the first IDE disk is the first probed disk. The boot manager
|
||||
you will install will be hooked into the MBR on this first
|
||||
probed hard disk that we've just described.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="limits">
|
||||
<title>Booting Limitations and Warnings</title>
|
||||
|
||||
<para>Now the interesting stuff that you need to watch out
|
||||
for.</para>
|
||||
|
||||
<sect3>
|
||||
<title>The dreaded 1024 cylinder limit and how BIOS LBA helps</title>
|
||||
|
||||
<para>The first part of the booting process is all done
|
||||
through the BIOS, (if that's a new term to you, the BIOS is
|
||||
a software chip on your system motherboard which provides
|
||||
startup code for your computer). As such, this first part
|
||||
of the process is subject to the limitations of the BIOS
|
||||
interface.</para>
|
||||
|
||||
<para>The BIOS interface used to read the hard disk during
|
||||
this period (INT 13H, Subfunction 2) allocates 10 bits to
|
||||
the Cylinder Number, 8 bits to the Head Number, and 6 bits
|
||||
to the Sector Number. This restricts users of this
|
||||
interface (i.e. boot managers hooked into your disk's MBR as
|
||||
well as OS loaders hooked into the Boot Sectors) to the
|
||||
following limits:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>1024 cylinders, max</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>256 heads, max</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>64 sectors/track, max (actually 63, <literal>0</literal>
|
||||
isn't available)</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Now big hard disks have lots of cylinders but not a lot
|
||||
of heads, so invariably with big hard disks the number of
|
||||
cylinders is greater than 1024. Given this and the BIOS
|
||||
interface as is, you can't boot off just anywhere on your
|
||||
hard disk. The boot code (the boot manager and the OS
|
||||
loader hooked into all bootable partitions' Boot Sectors)
|
||||
has to reside below cylinder 1024. In fact, if your hard
|
||||
disk is typical and has 16 heads, this equates to:</para>
|
||||
|
||||
<informalexample>
|
||||
<para>1024 cyl/disk × 16 heads/disk × 63
|
||||
sect/(cyl-head) × 512 bytes/sector</para>
|
||||
</informalexample>
|
||||
|
||||
<para>which is around the often-mentioned 528MB limit.</para>
|
||||
|
||||
<para>This is where BIOS LBA (Logical Block Addressing) comes
|
||||
in. BIOS LBA gives the user of the BIOS API calls access to
|
||||
physical cylinders above 1024 though the BIOS interfaces by
|
||||
redefining a cylinder. That is, it remaps your cylinders
|
||||
and heads, making it appear through the BIOS as though the
|
||||
disk has fewer cylinders and more heads than it actually
|
||||
does. In other words, it takes advantage of the fact that
|
||||
hard disks have relatively few heads and lots of cylinders
|
||||
by shifting the balance between number of cylinders and
|
||||
number of heads so that both numbers lie below the
|
||||
above-mentioned limits (1024 cylinders, 256 heads).</para>
|
||||
|
||||
<para>With BIOS LBA, the hard disk size limitation is
|
||||
virtually removed (well, pushed up to 8 Gigabytes anyway).
|
||||
If you have an LBA BIOS, you can put FreeBSD or any OS
|
||||
anywhere you want and not hit the 1024 cylinder
|
||||
limit.</para>
|
||||
|
||||
<para>To use my 1.6 Gig Western Digital as an example again,
|
||||
it's physical geometry is:</para>
|
||||
|
||||
<informalexample>
|
||||
<para>(3148 cyl, 16 heads, 63 sectors/track, 512
|
||||
bytes/sector)</para>
|
||||
</informalexample>
|
||||
|
||||
<para>However, my BIOS LBA remaps this to:</para>
|
||||
|
||||
<informalexample>
|
||||
<para>(787 cyl, 64 heads, 63 sectors/track, 512
|
||||
bytes/sector)</para>
|
||||
</informalexample>
|
||||
|
||||
<para>giving the same effective size disk, but with cylinder
|
||||
and head counts within the BIOS API's range (Incidentally, I
|
||||
have both Linux and FreeBSD existing on one of my hard disks
|
||||
above the 1024th physical cylinder, and both operating
|
||||
systems boot fine, thanks to BIOS LBA).</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Boot Managers and Disk Allocation</title>
|
||||
|
||||
<para>Another gotcha to watch out when installing boot
|
||||
managers is allocating space for your boot manager. It's
|
||||
best to be aware of this issue up front to save yourself
|
||||
from having to reinstall one or more of your OSs.</para>
|
||||
|
||||
<para>If you followed the discussion in <xref
|
||||
linkend="booting"> about the Master Boot Sector (where the
|
||||
MBR is), Partition Boot Sectors, and the booting process,
|
||||
you may have been wondering just exactly where on your hard
|
||||
disk that nifty boot manager is going to live. Well, some
|
||||
boot managers are small enough to fit entirely within the
|
||||
Master Boot Sector (Cylinder 0, Head 0, Sector 0) along with
|
||||
the partition table. Others need a bit more room and
|
||||
actually extend a few sectors past the Master Boot Sector in
|
||||
the Cylinder 0 Head 0 track, since that's typically
|
||||
free…typically.</para>
|
||||
|
||||
<para>That's the catch. Some operating systems (FreeBSD
|
||||
included) let you start their partitions right after the
|
||||
Master Boot Sector at Cylinder 0, Head 0, Sector 2 if you
|
||||
want. In fact, if you give FreeBSD's sysinstall a disk with
|
||||
an empty chunk up front or the whole disk empty, that's
|
||||
where it'll start the FreeBSD partition by default (at least
|
||||
it did when I fell into this trap). Then when you go to
|
||||
install your boot manager, if it's one that occupies a few
|
||||
extra sectors after the MBR, it'll overwrite the front of
|
||||
the first partition's data. In the case of FreeBSD, this
|
||||
overwrites the disk label, and renders your FreeBSD
|
||||
partition unbootable.</para>
|
||||
|
||||
<para>The easy way to avoid this problem (and leave yourself
|
||||
the flexibility to try different boot managers later) is
|
||||
just to always leave the first full track on your disk
|
||||
unallocated when you partition your disk. That is, leave
|
||||
the space from Cylinder 0, Head 0, Sector 2 through Cylinder
|
||||
0, Head 0, Sector 63 unallocated, and start your first
|
||||
partition at Cylinder 0, Head 1, Sector 1. For what it's
|
||||
worth, when you create a DOS partition at the front of your
|
||||
disk, DOS leaves this space open by default (this is why
|
||||
some boot managers assume it's free). So creating a DOS
|
||||
partition up at the front of your disk avoids this problem
|
||||
altogether. I like to do this myself, creating 1 Meg DOS
|
||||
partition up front, because it also avoids my primary DOS
|
||||
drive letters shifting later when I repartition.</para>
|
||||
|
||||
<para>For reference, the following boot managers use the
|
||||
Master Boot Sector to store their code and data:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>OS-BS 1.35</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Boot Easy</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>LILO</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>These boot managers use a few additional sectors after
|
||||
the Master Boot Sector:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>OS-BS 2.0 Beta 8 (sectors 2-5)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>OS/2's boot manager</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>What if your machine won't boot?</title>
|
||||
|
||||
<para>At some point when installing boot managers, you might
|
||||
leave the MBR in a state such that your machine won't boot.
|
||||
This is unlikely, but possible when re-FDISKing underneath
|
||||
an already-installed boot manager.</para>
|
||||
|
||||
<para>If you have a bootable DOS partition on your disk, you
|
||||
can boot off a DOS floppy, and run:</para>
|
||||
|
||||
<informalexample>
|
||||
<screen>A:\> <userinput>FDISK /MBR</>
|
||||
</screen>
|
||||
</informalexample>
|
||||
|
||||
<para>to put the original, simple DOS boot code back into the
|
||||
system. You can then boot DOS (and DOS only) off the hard
|
||||
drive. Alternatively, just re-run your boot manager
|
||||
installation program off a bootable floppy.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</article>
|
||||
@ -1,14 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,14 +0,0 @@
|
||||
# $FreeBSD$
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,16 +0,0 @@
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/articles/mh/Makefile,v 1.8 1999/09/06 06:52:37 peter Exp $
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
IMAGES= fig1.eps fig2.eps fig3.eps fig4.eps
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,838 +0,0 @@
|
||||
<!-- $FreeBSD: doc/en_US.ISO_8859-1/articles/vm-design/article.sgml,v 1.3 2001/01/24 11:50:30 ben Exp $ -->
|
||||
<!-- FreeBSD Documentation Project -->
|
||||
|
||||
<!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
]>
|
||||
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>Design elements of the FreeBSD VM system</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Matthew</firstname>
|
||||
|
||||
<surname>Dillon</surname>
|
||||
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>dillon@apollo.backplane.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<abstract>
|
||||
<para>The title is really just a fancy way of saying that I am going to
|
||||
attempt to describe the whole VM enchilada, hopefully in a way that
|
||||
everyone can follow. For the last year I have concentrated on a number
|
||||
of major kernel subsystems within FreeBSD, with the VM and Swap
|
||||
subsystems being the most interesting and NFS being ‘a necessary
|
||||
chore’. I rewrote only small portions of the code. In the VM
|
||||
arena the only major rewrite I have done is to the swap subsystem.
|
||||
Most of my work was cleanup and maintenance, with only moderate code
|
||||
rewriting and no major algorithmic adjustments within the VM
|
||||
subsystem. The bulk of the VM subsystem's theoretical base remains
|
||||
unchanged and a lot of the credit for the modernization effort in the
|
||||
last few years belongs to John Dyson and David Greenman. Not being a
|
||||
historian like Kirk I will not attempt to tag all the various features
|
||||
with peoples names, since I will invariably get it wrong.</para>
|
||||
</abstract>
|
||||
|
||||
<legalnotice>
|
||||
<para>This article was originally published in the January 2000 issue of
|
||||
<ulink url="http://www.daemonnews.org/">DaemonNews</ulink>. This
|
||||
version of the article may include updates from Matt and other authors
|
||||
to reflect changes in FreeBSD's VM implementation.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<sect1>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>Before moving along to the actual design let's spend a little time
|
||||
on the necessity of maintaining and modernizing any long-living
|
||||
codebase. In the programming world, algorithms tend to be more
|
||||
important than code and it is precisely due to BSD's academic roots that
|
||||
a great deal of attention was paid to algorithm design from the
|
||||
beginning. More attention paid to the design generally leads to a clean
|
||||
and flexible codebase that can be fairly easily modified, extended, or
|
||||
replaced over time. While BSD is considered an ‘old’
|
||||
operating system by some people, those of us who work on it tend to view
|
||||
it more as a ‘mature’ codebase which has various components
|
||||
modified, extended, or replaced with modern code. It has evolved, and
|
||||
FreeBSD is at the bleeding edge no matter how old some of the code might
|
||||
be. This is an important distinction to make and one that is
|
||||
unfortunately lost to many people. The biggest error a programmer can
|
||||
make is to not learn from history, and this is precisely the error that
|
||||
many other modern operating systems have made. NT is the best example
|
||||
of this, and the consequences have been dire. Linux also makes this
|
||||
mistake to some degree—enough that we BSD folk can make small
|
||||
jokes about it every once in a while, anyway. Linux's problem is simply
|
||||
one of a lack of experience and history to compare ideas against, a
|
||||
problem that is easily and rapidly being addressed by the Linux
|
||||
community in the same way it has been addressed in the BSD
|
||||
community—by continuous code development. The NT folk, on the
|
||||
other hand, repeatedly make the same mistakes solved by UNIX decades ago
|
||||
and then spend years fixing them. Over and over again. They have a
|
||||
severe case of ‘not designed here’ and ‘we are always
|
||||
right because our marketing department says so’. I have little
|
||||
tolerance for anyone who cannot learn from history.</para>
|
||||
|
||||
<para>Much of the apparent complexity of the FreeBSD design, especially in
|
||||
the VM/Swap subsystem, is a direct result of having to solve serious
|
||||
performance issues that occur under various conditions. These issues
|
||||
are not due to bad algorithmic design but instead rise from
|
||||
environmental factors. In any direct comparison between platforms,
|
||||
these issues become most apparent when system resources begin to get
|
||||
stressed. As I describe FreeBSD's VM/Swap subsystem the reader should
|
||||
always keep two points in mind. First, the most important aspect of
|
||||
performance design is what is known as “Optimizing the Critical
|
||||
Path”. It is often the case that performance optimizations add a
|
||||
little bloat to the code in order to make the critical path perform
|
||||
better. Second, a solid, generalized design outperforms a
|
||||
heavily-optimized design over the long run. While a generalized design
|
||||
may end up being slower than an heavily-optimized design when they are
|
||||
first implemented, the generalized design tends to be easier to adapt to
|
||||
changing conditions and the heavily-optimized design winds up having to
|
||||
be thrown away. Any codebase that will survive and be maintainable for
|
||||
years must therefore be designed properly from the beginning even if it
|
||||
costs some performance. Twenty years ago people were still arguing that
|
||||
programming in assembly was better than programming in a high-level
|
||||
language because it produced code that was ten times as fast. Today,
|
||||
the fallibility of that argument is obvious—as are the parallels
|
||||
to algorithmic design and code generalization.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>VM Objects</title>
|
||||
|
||||
<para>The best way to begin describing the FreeBSD VM system is to look at
|
||||
it from the perspective of a user-level process. Each user process sees
|
||||
a single, private, contiguous VM address space containing several types
|
||||
of memory objects. These objects have various characteristics. Program
|
||||
code and program data are effectively a single memory-mapped file (the
|
||||
binary file being run), but program code is read-only while program data
|
||||
is copy-on-write. Program BSS is just memory allocated and filled with
|
||||
zeros on demand, called demand zero page fill. Arbitrary files can be
|
||||
memory-mapped into the address space as well, which is how the shared
|
||||
library mechanism works. Such mappings can require modifications to
|
||||
remain private to the process making them. The fork system call adds an
|
||||
entirely new dimension to the VM management problem on top of the
|
||||
complexity already given.</para>
|
||||
|
||||
<para>A program binary data page (which is a basic copy-on-write page)
|
||||
illustrates the complexity. A program binary contains a preinitialized
|
||||
data section which is initially mapped directly from the program file.
|
||||
When a program is loaded into a process's VM space, this area is
|
||||
initially memory-mapped and backed by the program binary itself,
|
||||
allowing the VM system to free/reuse the page and later load it back in
|
||||
from the binary. The moment a process modifies this data, however, the
|
||||
VM system must make a private copy of the page for that process. Since
|
||||
the private copy has been modified, the VM system may no longer free it,
|
||||
because there is no longer any way to restore it later on.</para>
|
||||
|
||||
<para>You will notice immediately that what was originally a simple file
|
||||
mapping has become much more complex. Data may be modified on a
|
||||
page-by-page basis whereas the file mapping encompasses many pages at
|
||||
once. The complexity further increases when a process forks. When a
|
||||
process forks, the result is two processes—each with their own
|
||||
private address spaces, including any modifications made by the original
|
||||
process prior to the call to <function>fork()</function>. It would be
|
||||
silly for the VM system to make a complete copy of the data at the time
|
||||
of the <function>fork()</function> because it is quite possible that at
|
||||
least one of the two processes will only need to read from that page
|
||||
from then on, allowing the original page to continue to be used. What
|
||||
was a private page is made copy-on-write again, since each process
|
||||
(parent and child) expects their own personal post-fork modifications to
|
||||
remain private to themselves and not effect the other.</para>
|
||||
|
||||
<para>FreeBSD manages all of this with a layered VM Object model. The
|
||||
original binary program file winds up being the lowest VM Object layer.
|
||||
A copy-on-write layer is pushed on top of that to hold those pages which
|
||||
had to be copied from the original file. If the program modifies a data
|
||||
page belonging to the original file the VM system takes a fault and
|
||||
makes a copy of the page in the higher layer. When a process forks,
|
||||
additional VM Object layers are pushed on. This might make a little
|
||||
more sense with a fairly basic example. A <function>fork()</function>
|
||||
is a common operation for any *BSD system, so this example will consider
|
||||
a program that starts up, and forks. When the process starts, the VM
|
||||
system creates an object layer, let's call this A:</para>
|
||||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="fig1" format="EPS">
|
||||
</imageobject>
|
||||
|
||||
<textobject>
|
||||
<literallayout class="monospaced">+---------------+
|
||||
| A |
|
||||
+---------------+</literallayout>
|
||||
</textobject>
|
||||
|
||||
<textobject>
|
||||
<phrase>A picture</phrase>
|
||||
</textobject>
|
||||
</mediaobject>
|
||||
|
||||
<para>A represents the file—pages may be paged in and out of the
|
||||
file's physical media as necessary. Paging in from the disk is
|
||||
reasonable for a program, but we really don't want to page back out and
|
||||
overwrite the executable. The VM system therefore creates a second
|
||||
layer, B, that will be physically backed by swap space:</para>
|
||||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="fig2" format="EPS">
|
||||
</imageobject>
|
||||
|
||||
<textobject>
|
||||
<literallayout class="monospaced">+---------------+
|
||||
| B |
|
||||
+---------------+
|
||||
| A |
|
||||
+---------------+</literallayout>
|
||||
</textobject>
|
||||
</mediaobject>
|
||||
|
||||
<para>On the first write to a page after this, a new page is created in B,
|
||||
and its contents are initialized from A. All pages in B can be paged in
|
||||
or out to a swap device. When the program forks, the VM system creates
|
||||
two new object layers—C1 for the parent, and C2 for the
|
||||
child—that rest on top of B:</para>
|
||||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="fig3" format="EPS">
|
||||
</imageobject>
|
||||
|
||||
<textobject>
|
||||
<literallayout class="monospaced">+-------+-------+
|
||||
| C1 | C2 |
|
||||
+-------+-------+
|
||||
| B |
|
||||
+---------------+
|
||||
| A |
|
||||
+---------------+</literallayout>
|
||||
</textobject>
|
||||
</mediaobject>
|
||||
|
||||
<para>In this case, let's say a page in B is modified by the original
|
||||
parent process. The process will take a copy-on-write fault and
|
||||
duplicate the page in C1, leaving the original page in B untouched.
|
||||
Now, let's say the same page in B is modified by the child process. The
|
||||
process will take a copy-on-write fault and duplicate the page in C2.
|
||||
The original page in B is now completely hidden since both C1 and C2
|
||||
have a copy and B could theoretically be destroyed if it does not
|
||||
represent a 'real' file). However, this sort of optimization is not
|
||||
trivial to make because it is so fine-grained. FreeBSD does not make
|
||||
this optimization. Now, suppose (as is often the case) that the child
|
||||
process does an <function>exec()</function>. Its current address space
|
||||
is usually replaced by a new address space representing a new file. In
|
||||
this case, the C2 layer is destroyed:</para>
|
||||
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="fig4" format="EPS">
|
||||
</imageobject>
|
||||
|
||||
<textobject>
|
||||
<literallayout class="monospaced">+-------+
|
||||
| C1 |
|
||||
+-------+-------+
|
||||
| B |
|
||||
+---------------+
|
||||
| A |
|
||||
+---------------+</literallayout>
|
||||
</textobject>
|
||||
</mediaobject>
|
||||
|
||||
<para>In this case, the number of children of B drops to one, and all
|
||||
accesses to B now go through C1. This means that B and C1 can be
|
||||
collapsed together. Any pages in B that also exist in C1 are deleted
|
||||
from B during the collapse. Thus, even though the optimization in the
|
||||
previous step could not be made, we can recover the dead pages when
|
||||
either of the processes exit or <function>exec()</function>.</para>
|
||||
|
||||
<para>This model creates a number of potential problems. The first is that
|
||||
you can wind up with a relatively deep stack of layered VM Objects which
|
||||
can cost scanning time and memory when you take a fault. Deep
|
||||
layering can occur when processes fork and then fork again (either
|
||||
parent or child). The second problem is that you can wind up with dead,
|
||||
inaccessible pages deep in the stack of VM Objects. In our last example
|
||||
if both the parent and child processes modify the same page, they both
|
||||
get their own private copies of the page and the original page in B is
|
||||
no longer accessible by anyone. That page in B can be freed.</para>
|
||||
|
||||
<para>FreeBSD solves the deep layering problem with a special optimization
|
||||
called the “All Shadowed Case”. This case occurs if either
|
||||
C1 or C2 take sufficient COW faults to completely shadow all pages in B.
|
||||
Lets say that C1 achieves this. C1 can now bypass B entirely, so rather
|
||||
then have C1->B->A and C2->B->A we now have C1->A and C2->B->A. But
|
||||
look what also happened—now B has only one reference (C2), so we
|
||||
can collapse B and C2 together. The end result is that B is deleted
|
||||
entirely and we have C1->A and C2->A. It is often the case that B will
|
||||
contain a large number of pages and neither C1 nor C2 will be able to
|
||||
completely overshadow it. If we fork again and create a set of D
|
||||
layers, however, it is much more likely that one of the D layers will
|
||||
eventually be able to completely overshadow the much smaller dataset
|
||||
reprsented by C1 or C2. The same optimization will work at any point in
|
||||
the graph and the grand result of this is that even on a heavily forked
|
||||
machine VM Object stacks tend to not get much deeper then 4. This is
|
||||
true of both the parent and the children and true whether the parent is
|
||||
doing the forking or whether the children cascade forks.</para>
|
||||
|
||||
<para>The dead page problem still exists in the case where C1 or C2 do not
|
||||
completely overshadow B. Due to our other optimizations this case does
|
||||
not represent much of a problem and we simply allow the pages to be
|
||||
dead. If the system runs low on memory it will swap them out, eating a
|
||||
little swap, but that's it.</para>
|
||||
|
||||
<para>The advantage to the VM Object model is that
|
||||
<function>fork()</function> is extremely fast, since no real data
|
||||
copying need take place. The disadvantage is that you can build a
|
||||
relatively complex VM Object layering that slows page fault handling
|
||||
down a little, and you spend memory managing the VM Object structures.
|
||||
The optimizations FreeBSD makes proves to reduce the problems enough
|
||||
that they can be ignored, leaving no real disadvantage.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>SWAP Layers</title>
|
||||
|
||||
<para>Private data pages are initially either copy-on-write or zero-fill
|
||||
pages. When a change, and therefore a copy, is made, the original
|
||||
backing object (usually a file) can no longer be used to save a copy of
|
||||
the page when the VM system needs to reuse it for other purposes. This
|
||||
is where SWAP comes in. SWAP is allocated to create backing store for
|
||||
memory that does not otherwise have it. FreeBSD allocates the swap
|
||||
management structure for a VM Object only when it is actually needed.
|
||||
However, the swap management structure has had problems
|
||||
historically.</para>
|
||||
|
||||
<para>Under FreeBSD 3.x the swap management structure preallocates an
|
||||
array that encompasses the entire object requiring swap backing
|
||||
store—even if only a few pages of that object are swap-backed.
|
||||
This creates a kernel memory fragmentation problem when large objects
|
||||
are mapped, or processes with large runsizes (RSS) fork. Also, in order
|
||||
to keep track of swap space, a ‘list of holes’ is kept in
|
||||
kernel memory, and this tends to get severely fragmented as well. Since
|
||||
the 'list of holes' is a linear list, the swap allocation and freeing
|
||||
performance is a non-optimal O(n)-per-page. It also requires kernel
|
||||
memory allocations to take place during the swap freeing process, and
|
||||
that creates low memory deadlock problems. The problem is further
|
||||
exacerbated by holes created due to the interleaving algorithm. Also,
|
||||
the swap block map can become fragmented fairly easily resulting in
|
||||
non-contiguous allocations. Kernel memory must also be allocated on the
|
||||
fly for additional swap management structures when a swapout occurs. It
|
||||
is evident that there was plenty of room for improvement.</para>
|
||||
|
||||
<para>For FreeBSD 4.x, I completely rewrote the swap subsystem. With this
|
||||
rewrite, swap management structures are allocated through a hash table
|
||||
rather than a linear array giving them a fixed allocation size and much
|
||||
finer granularity. Rather then using a linearly linked list to keep
|
||||
track of swap space reservations, it now uses a bitmap of swap blocks
|
||||
arranged in a radix tree structure with free-space hinting in the radix
|
||||
node structures. This effectively makes swap allocation and freeing an
|
||||
O(1) operation. The entire radix tree bitmap is also preallocated in
|
||||
order to avoid having to allocate kernel memory during critical low
|
||||
memory swapping operations. After all, the system tends to swap when it
|
||||
is low on memory so we should avoid allocating kernel memory at such
|
||||
times in order to avoid potential deadlocks. Finally, to reduce
|
||||
fragmentation the radix tree is capable of allocating large contiguous
|
||||
chunks at once, skipping over smaller fragmented chunks. I did not take
|
||||
the final step of having an 'allocating hint pointer' that would trundle
|
||||
through a portion of swap as allocations were made in order to further
|
||||
guarantee contiguous allocations or at least locality of reference, but
|
||||
I ensured that such an addition could be made.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>When to free a page</title>
|
||||
|
||||
<para>Since the VM system uses all available memory for disk caching,
|
||||
there are usually very few truly-free pages. The VM system depends on
|
||||
being able to properly choose pages which are not in use to reuse for
|
||||
new allocations. Selecting the optimal pages to free is possibly the
|
||||
single-most important function any VM system can perform because if it
|
||||
makes a poor selection, the VM system may be forced to unnecessarily
|
||||
retrieve pages from disk, seriously degrading system performance.</para>
|
||||
|
||||
<para>How much overhead are we willing to suffer in the critical path to
|
||||
avoid freeing the wrong page? Each wrong choice we make will cost us
|
||||
hundreds of thousands of CPU cycles and a noticeable stall of the
|
||||
affected processes, so we are willing to endure a significant amount of
|
||||
overhead in order to be sure that the right page is chosen. This is why
|
||||
FreeBSD tends to outperform other systems when memory resources become
|
||||
stressed.</para>
|
||||
|
||||
<para>The free page determination algorithm is built upon a history of the
|
||||
use of memory pages. To acquire this history, the system takes advantage
|
||||
of a page-used bit feature that most hardware page tables have.</para>
|
||||
|
||||
<para>In any case, the page-used bit is cleared and at some later point
|
||||
the VM system comes across the page again and sees that the page-used
|
||||
bit has been set. This indicates that the page is still being actively
|
||||
used. If the bit is still clear it is an indication that the page is not
|
||||
being actively used. By testing this bit periodically, a use history (in
|
||||
the form of a counter) for the physical page is developed. When the VM
|
||||
system later needs to free up some pages, checking this history becomes
|
||||
the cornerstone of determining the best candidate page to reuse.</para>
|
||||
|
||||
<sidebar>
|
||||
<title>What if the hardware has no page-used bit?</title>
|
||||
|
||||
<para>For those platforms that do not have this feature, the system
|
||||
actually emulates a page-used bit. It unmaps or protects a page,
|
||||
forcing a page fault if the page is accessed again. When the page
|
||||
fault is taken, the system simply marks the page as having been used
|
||||
and unprotects the page so that it may be used. While taking such page
|
||||
faults just to determine if a page is being used appears to be an
|
||||
expensive proposition, it is much less expensive than reusing the page
|
||||
for some other purpose only to find that a process needs it back and
|
||||
then have to go to disk.</para>
|
||||
</sidebar>
|
||||
|
||||
<para>FreeBSD makes use of several page queues to further refine the
|
||||
selection of pages to reuse as well as to determine when dirty pages
|
||||
must be flushed to their backing store. Since page tables are dynamic
|
||||
entities under FreeBSD, it costs virtually nothing to unmap a page from
|
||||
the address space of any processes using it. When a page candidate has
|
||||
been chosen based on the page-use counter, this is precisely what is
|
||||
done. The system must make a distinction between clean pages which can
|
||||
theoretically be freed up at any time, and dirty pages which must first
|
||||
be written to their backing store before being reusable. When a page
|
||||
candidate has been found it is moved to the inactive queue if it is
|
||||
dirty, or the cache queue if it is clean. A separate algorithm based on
|
||||
the dirty-to-clean page ratio determines when dirty pages in the
|
||||
inactive queue must be flushed to disk. Once this is accomplished, the
|
||||
flushed pages are moved from the inactive queue to the cache queue. At
|
||||
this point, pages in the cache queue can still be reactivated by a VM
|
||||
fault at relatively low cost. However, pages in the cache queue are
|
||||
considered to be ‘immediately freeable’ and will be reused
|
||||
in an LRU (least-recently used) fashion when the system needs to
|
||||
allocate new memory.</para>
|
||||
|
||||
<para>It is important to note that the FreeBSD VM system attempts to
|
||||
separate clean and dirty pages for the express reason of avoiding
|
||||
unnecessary flushes of dirty pages (which eats I/O bandwidth), nor does
|
||||
it move pages between the various page queues gratuitously when the
|
||||
memory subsystem is not being stressed. This is why you will see some
|
||||
systems with very low cache queue counts and high active queue counts
|
||||
when doing a <command>systat -vm</command> command. As the VM system
|
||||
becomes more stressed, it makes a greater effort to maintain the various
|
||||
page queues at the levels determined to be the most effective. An urban
|
||||
myth has circulated for years that Linux did a better job avoiding
|
||||
swapouts than FreeBSD, but this in fact is not true. What was actually
|
||||
occurring was that FreeBSD was proactively paging out unused pages in
|
||||
order to make room for more disk cache while Linux was keeping unused
|
||||
pages in core and leaving less memory available for cache and process
|
||||
pages. I don't know whether this is still true today.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Pre-Faulting and Zeroing Optimizations</title>
|
||||
|
||||
<para>Taking a VM fault is not expensive if the underlying page is already
|
||||
in core and can simply be mapped into the process, but it can become
|
||||
expensive if you take a whole lot of them on a regular basis. A good
|
||||
example of this is running a program such as &man.ls.1; or &man.ps.1;
|
||||
over and over again. If the program binary is mapped into memory but
|
||||
not mapped into the page table, then all the pages that will be accessed
|
||||
by the program will have to be faulted in every time the program is run.
|
||||
This is unnecessary when the pages in question are already in the VM
|
||||
Cache, so FreeBSD will attempt to pre-populate a process's page tables
|
||||
with those pages that are already in the VM Cache. One thing that
|
||||
FreeBSD does not yet do is pre-copy-on-write certain pages on exec. For
|
||||
example, if you run the &man.ls.1; program while running <command>vmstat
|
||||
1</command> you will notice that it always takes a certain number of
|
||||
page faults, even when you run it over and over again. These are
|
||||
zero-fill faults, not program code faults (which were pre-faulted in
|
||||
already). Pre-copying pages on exec or fork is an area that could use
|
||||
more study.</para>
|
||||
|
||||
<para>A large percentage of page faults that occur are zero-fill faults.
|
||||
You can usually see this by observing the <command>vmstat -s</command>
|
||||
output. These occur when a process accesses pages in its BSS area. The
|
||||
BSS area is expected to be initially zero but the VM system does not
|
||||
bother to allocate any memory at all until the process actually accesses
|
||||
it. When a fault occurs the VM system must not only allocate a new page,
|
||||
it must zero it as well. To optimize the zeroing operation the VM system
|
||||
has the ability to pre-zero pages and mark them as such, and to request
|
||||
pre-zeroed pages when zero-fill faults occur. The pre-zeroing occurs
|
||||
whenever the CPU is idle but the number of pages the system pre-zeros is
|
||||
limited in order to avoid blowing away the memory caches. This is an
|
||||
excellent example of adding complexity to the VM system in order to
|
||||
optimize the critical path.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Page Table Optimizations</title>
|
||||
|
||||
<para>The page table optimizations make up the most contentious part of
|
||||
the FreeBSD VM design and they have shown some strain with the advent of
|
||||
serious use of <function>mmap()</function>. I think this is actually a
|
||||
feature of most BSDs though I am not sure when it was first introduced.
|
||||
There are two major optimizations. The first is that hardware page
|
||||
tables do not contain persistent state but instead can be thrown away at
|
||||
any time with only a minor amount of management overhead. The second is
|
||||
that every active page table entry in the system has a governing
|
||||
<literal>pv_entry</literal> structure which is tied into the
|
||||
<literal>vm_page</literal> structure. FreeBSD can simply iterate
|
||||
through those mappings that are known to exist while Linux must check
|
||||
all page tables that <emphasis>might</emphasis> contain a specific
|
||||
mapping to see if it does, which can achieve O(n^2) overhead in certain
|
||||
situations. It is because of this that FreeBSD tends to make better
|
||||
choices on which pages to reuse or swap when memory is stressed, giving
|
||||
it better performance under load. However, FreeBSD requires kernel
|
||||
tuning to accommodate large-shared-address-space situations such as
|
||||
those that can occur in a news system because it may run out of
|
||||
<literal>pv_entry</literal> structures.</para>
|
||||
|
||||
<para>Both Linux and FreeBSD need work in this area. FreeBSD is trying to
|
||||
maximize the advantage of a potentially sparse active-mapping model (not
|
||||
all processes need to map all pages of a shared library, for example),
|
||||
whereas Linux is trying to simplify its algorithms. FreeBSD generally
|
||||
has the performance advantage here at the cost of wasting a little extra
|
||||
memory, but FreeBSD breaks down in the case where a large file is
|
||||
massively shared across hundreds of processes. Linux, on the other hand,
|
||||
breaks down in the case where many processes are sparsely-mapping the
|
||||
same shared library and also runs non-optimally when trying to determine
|
||||
whether a page can be reused or not.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Page Coloring</title>
|
||||
|
||||
<para>We'll end with the page coloring optimizations. Page coloring is a
|
||||
performance optimization designed to ensure that accesses to contiguous
|
||||
pages in virtual memory make the best use of the processor cache. In
|
||||
ancient times (i.e. 10+ years ago) processor caches tended to map
|
||||
virtual memory rather than physical memory. This led to a huge number of
|
||||
problems including having to clear the cache on every context switch in
|
||||
some cases, and problems with data aliasing in the cache. Modern
|
||||
processor caches map physical memory precisely to solve those problems.
|
||||
This means that two side-by-side pages in a processes address space may
|
||||
not correspond to two side-by-side pages in the cache. In fact, if you
|
||||
aren't careful side-by-side pages in virtual memory could wind up using
|
||||
the same page in the processor cache—leading to cacheable data
|
||||
being thrown away prematurely and reducing CPU performance. This is true
|
||||
even with multi-way set-associative caches (though the effect is
|
||||
mitigated somewhat).</para>
|
||||
|
||||
<para>FreeBSD's memory allocation code implements page coloring
|
||||
optimizations, which means that the memory allocation code will attempt
|
||||
to locate free pages that are contiguous from the point of view of the
|
||||
cache. For example, if page 16 of physical memory is assigned to page 0
|
||||
of a process's virtual memory and the cache can hold 4 pages, the page
|
||||
coloring code will not assign page 20 of physical memory to page 1 of a
|
||||
process's virtual memory. It would, instead, assign page 21 of physical
|
||||
memory. The page coloring code attempts to avoid assigning page 20
|
||||
because this maps over the same cache memory as page 16 and would result
|
||||
in non-optimal caching. This code adds a significant amount of
|
||||
complexity to the VM memory allocation subsystem as you can well
|
||||
imagine, but the result is well worth the effort. Page Coloring makes VM
|
||||
memory as deterministic as physical memory in regards to cache
|
||||
performance.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Conclusion</title>
|
||||
|
||||
<para>Virtual memory in modern operating systems must address a number of
|
||||
different issues efficiently and for many different usage patterns. The
|
||||
modular and algorithmic approach that BSD has historically taken allows
|
||||
us to study and understand the current implementation as well as
|
||||
relatively cleanly replace large sections of the code. There have been a
|
||||
number of improvements to the FreeBSD VM system in the last several
|
||||
years, and work is ongoing.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Bonus QA session by Allen Briggs
|
||||
<email>briggs@ninthwonder.com</email></title>
|
||||
|
||||
<qandaset>
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>What is “the interleaving algorithm” that you
|
||||
refer to in your listing of the ills of the FreeBSD 3.x swap
|
||||
arrangments?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>FreeBSD uses a fixed swap interleave which defaults to 4. This
|
||||
means that FreeBSD reserves space for four swap areas even if you
|
||||
only have one, two, or three. Since swap is interleaved the linear
|
||||
address space representing the ‘four swap areas’ will be
|
||||
fragmented if you don't actually have four swap areas. For
|
||||
example, if you have two swap areas A and B FreeBSD's address
|
||||
space representation for that swap area will be interleaved in
|
||||
blocks of 16 pages:</para>
|
||||
|
||||
<literallayout>A B C D A B C D A B C D A B C D</literallayout>
|
||||
|
||||
<para>FreeBSD 3.x uses a ‘sequential list of free
|
||||
regions’ approach to accounting for the free swap areas.
|
||||
The idea is that large blocks of free linear space can be
|
||||
represented with a single list node
|
||||
(<filename>kern/subr_rlist.c</filename>). But due to the
|
||||
fragmentation the sequential list winds up being insanely
|
||||
fragmented. In the above example, completely unused swap will
|
||||
have A and B shown as ‘free’ and C and D shown as
|
||||
‘all allocated’. Each A-B sequence requires a list
|
||||
node to account for because C and D are holes, so the list node
|
||||
cannot be combined with the next A-B sequence.</para>
|
||||
|
||||
<para>Why do we interleave our swap space instead of just tack swap
|
||||
areas onto the end and do something fancier? Because it's a whole
|
||||
lot easier to allocate linear swaths of an address space and have
|
||||
the result automatically be interleaved across multiple disks than
|
||||
it is to try to put that sophistication elsewhere.</para>
|
||||
|
||||
<para>The fragmentation causes other problems. Being a linear list
|
||||
under 3.x, and having such a huge amount of inherent
|
||||
fragmentation, allocating and freeing swap winds up being an O(N)
|
||||
algorithm instead of an O(1) algorithm. Combined with other
|
||||
factors (heavy swapping) and you start getting into O(N^2) and
|
||||
O(N^3) levels of overhead, which is bad. The 3.x system may also
|
||||
need to allocate KVM during a swap operation to create a new list
|
||||
node which can lead to a deadlock if the system is trying to
|
||||
pageout pages in a low-memory situation.</para>
|
||||
|
||||
<para>Under 4.x we do not use a sequential list. Instead we use a
|
||||
radix tree and bitmaps of swap blocks rather than ranged list
|
||||
nodes. We take the hit of preallocating all the bitmaps required
|
||||
for the entire swap area up front but it winds up wasting less
|
||||
memory due to the use of a bitmap (one bit per block) instead of a
|
||||
linked list of nodes. The use of a radix tree instead of a
|
||||
sequential list gives us nearly O(1) performance no matter how
|
||||
fragmented the tree becomes.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>I don't get the following:</para>
|
||||
|
||||
<blockquote>
|
||||
<para>It is important to note that the FreeBSD VM system attempts
|
||||
to separate clean and dirty pages for the express reason of
|
||||
avoiding unnecessary flushes of dirty pages (which eats I/O
|
||||
bandwidth), nor does it move pages between the various page
|
||||
queues gratitously when the memory subsystem is not being
|
||||
stressed. This is why you will see some systems with very low
|
||||
cache queue counts and high active queue counts when doing a
|
||||
<command>systat -vm</command> command.</para>
|
||||
</blockquote>
|
||||
|
||||
<para>How is the separation of clean and dirty (inactive) pages
|
||||
related to the situation where you see low cache queue counts and
|
||||
high active queue counts in <command>systat -vm</command>? Do the
|
||||
systat stats roll the active and dirty pages together for the
|
||||
active queue count?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>Yes, that is confusing. The relationship is
|
||||
“goal” verses “reality”. Our goal is to
|
||||
separate the pages but the reality is that if we are not in a
|
||||
memory crunch, we don't really have to.</para>
|
||||
|
||||
<para>What this means is that FreeBSD will not try very hard to
|
||||
separate out dirty pages (inactive queue) from clean pages (cache
|
||||
queue) when the system is not being stressed, nor will it try to
|
||||
deactivate pages (active queue -> inactive queue) when the system
|
||||
is not being stressed, even if they aren't being used.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para> In the &man.ls.1; / <command>vmstat 1</command> example,
|
||||
wouldn't some of the page faults be data page faults (COW from
|
||||
executable file to private page)? I.e., I would expect the page
|
||||
faults to be some zero-fill and some program data. Or are you
|
||||
implying that FreeBSD does do pre-COW for the program data?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>A COW fault can be either zero-fill or program-data. The
|
||||
mechanism is the same either way because the backing program-data
|
||||
is almost certainly already in the cache. I am indeed lumping the
|
||||
two together. FreeBSD does not pre-COW program data or zero-fill,
|
||||
but it <emphasis>does</emphasis> pre-map pages that exist in its
|
||||
cache.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>In your section on page table optimizations, can you give a
|
||||
little more detail about <literal>pv_entry</literal> and
|
||||
<literal>vm_page</literal> (or should vm_page be
|
||||
<literal>vm_pmap</literal>—as in 4.4, cf. pp. 180-181 of
|
||||
McKusick, Bostic, Karel, Quarterman)? Specifically, what kind of
|
||||
operation/reaction would require scanning the mappings?</para>
|
||||
|
||||
<para>How does Linux do in the case where FreeBSD breaks down
|
||||
(sharing a large file mapping over many processes)?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>A <literal>vm_page</literal> represents an (object,index#)
|
||||
tuple. A <literal>pv_entry</literal> represents a hardware page
|
||||
table entry (pte). If you have five processes sharing the same
|
||||
physical page, and three of those processes's page tables actually
|
||||
map the page, that page will be represented by a single
|
||||
<literal>vm_page</literal> structure and three
|
||||
<literal>pv_entry</literal> structures.</para>
|
||||
|
||||
<para><literal>pv_entry</literal> structures only represent pages
|
||||
mapped by the MMU (one <literal>pv_entry</literal> represnts one
|
||||
pte). This means that when we need to remove all hardware
|
||||
references to a <literal>vm_page</literal> (in order to reuse the
|
||||
page for something else, page it out, clear it, dirty it, and so
|
||||
forth) we can simply scan the linked list of
|
||||
<literal>pv_entry</literal>'s associated with that
|
||||
<literal>vm_page</literal> to remove or modify the pte's from
|
||||
their page tables.</para>
|
||||
|
||||
<para>Under Linux there is no such linked list. In order to remove
|
||||
all the hardware page table mappings for a
|
||||
<literal>vm_page</literal> linux must index into every VM object
|
||||
that <emphasis>might</emphasis> have mapped the page. For
|
||||
example, if you have 50 processes all mapping the same shared
|
||||
library and want to get rid of page X in that library, you need to
|
||||
index into the page table for each of those 50 processes even if
|
||||
only 10 of them have actually mapped the page. So Linux is
|
||||
trading off the simplicity of its design against performance.
|
||||
Many VM algorithms which are O(1) or (small N) under FreeBSD wind
|
||||
up being O(N), O(N^2), or worse under Linux. Since the pte's
|
||||
representing a particular page in an object tend to be at the same
|
||||
offset in all the page tables they are mapped in, reducing the
|
||||
number of accesses into the page tables at the same pte offset
|
||||
will often avoid blowing away the L1 cache line for that offset,
|
||||
which can lead to better performance.</para>
|
||||
|
||||
<para>FreeBSD has added complexity (the <literal>pv_entry</literal>
|
||||
scheme) in order to increase performance (to limit page table
|
||||
accesses to <emphasis>only</emphasis> those pte's that need to be
|
||||
modified).</para>
|
||||
|
||||
<para>But FreeBSD has a scaling problem that Linux does not in that
|
||||
there are a limited number of <literal>pv_entry</literal>
|
||||
structures and this causes problems when you have massive sharing
|
||||
of data. In this case you may run out of
|
||||
<literal>pv_entry</literal> structures even though there is plenty
|
||||
of free memory available. This can be fixed easily enough by
|
||||
bumping up the number of <literal>pv_entry</literal> structures in
|
||||
the kernel config, but we really need to find a better way to do
|
||||
it.</para>
|
||||
|
||||
<para>In regards to the memory overhead of a page table verses the
|
||||
<literal>pv_entry</literal> scheme: Linux uses
|
||||
‘permanent’ page tables that are not throw away, but
|
||||
does not need a <literal>pv_entry</literal> for each potentially
|
||||
mapped pte. FreeBSD uses ‘throw away’ page tables but
|
||||
adds in a <literal>pv_entry</literal> structure for each
|
||||
actually-mapped pte. I think memory utilization winds up being
|
||||
about the same, giving FreeBSD an algorithmic advantage with its
|
||||
ability to throw away page tables at will with very low
|
||||
overhead.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question>
|
||||
<para>Finally, in the page coloring section, it might help to have a
|
||||
little more description of what you mean here. I didn't quite
|
||||
follow it.</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>Do you know how an L1 hardware memory cache works? I'll
|
||||
explain: Consider a machine with 16MB of main memory but only 128K
|
||||
of L1 cache. Generally the way this cache works is that each 128K
|
||||
block of main memory uses the <emphasis>same</emphasis> 128K of
|
||||
cache. If you access offset 0 in main memory and then offset
|
||||
offset 128K in main memory you can wind up throwing away the
|
||||
cached data you read from offset 0!</para>
|
||||
|
||||
<para>Now, I am simplifying things greatly. What I just described
|
||||
is what is called a ‘direct mapped’ hardware memory
|
||||
cache. Most modern caches are what are called
|
||||
2-way-set-associative or 4-way-set-associative caches. The
|
||||
set-associatively allows you to access up to N different memory
|
||||
regions that overlap the same cache memory without destroying the
|
||||
previously cached data. But only N.</para>
|
||||
|
||||
<para>So if I have a 4-way set associative cache I can access offset
|
||||
0, offset 128K, 256K and offset 384K and still be able to access
|
||||
offset 0 again and have it come from the L1 cache. If I then
|
||||
access offset 512K, however, one of the four previously cached
|
||||
data objects will be thrown away by the cache.</para>
|
||||
|
||||
<para>It is extremely important…
|
||||
<emphasis>extremely</emphasis> important for most of a processor's
|
||||
memory accesses to be able to come from the L1 cache, because the
|
||||
L1 cache operates at the processor frequency. The moment you have
|
||||
an L1 cahe miss and have to go to the L2 cache or to main memory,
|
||||
the processor will stall and potentially sit twidling its fingers
|
||||
for <emphasis>hundreds</emphasis> of instructions worth of time
|
||||
waiting for a read from main memory to complete. Main memory (the
|
||||
dynamic ram you stuff into a computer) is
|
||||
<emphasis>slow</emphasis>, when compared to the speed of a modern
|
||||
processor core.</para>
|
||||
|
||||
<para>Ok, so now onto page coloring: All modern memory caches are
|
||||
what are known as <emphasis>physical</emphasis> caches. They
|
||||
cache physical memory addresses, not virtual memory addresses.
|
||||
This allows the cache to be left alone across a process context
|
||||
switch, which is very important.</para>
|
||||
|
||||
<para>But in the UNIX world you are dealing with virtual address
|
||||
spaces, not physical address spaces. Any program you write will
|
||||
see the virtual address space given to it. The actual
|
||||
<emphasis>physical</emphasis> pages underlying that virtual
|
||||
address space are not necessarily physically contiguous! In fact,
|
||||
you might have two pages that are side by side in a processes
|
||||
address space which wind up being at offset 0 and offset 128K in
|
||||
<emphasis>physical</emphasis> memory.</para>
|
||||
|
||||
<para>A program normally assumes that two side-by-side pages will be
|
||||
optimally cached. That is, that you can access data objects in
|
||||
both pages without having them blow away each other's cache entry.
|
||||
But this is only true if the physical pages underlying the virtual
|
||||
address space are contiguous (insofar as the cache is
|
||||
concerned).</para>
|
||||
|
||||
<para>This is what Page coloring does. Instead of assigning
|
||||
<emphasis>random</emphasis> physical pages to virtual addresses,
|
||||
which may result in non-optimal cache performance , Page coloring
|
||||
assigns <emphasis>reasonably-contiguous</emphasis> physical pages
|
||||
to virtual addresses. Thus programs can be written under the
|
||||
assumption that the characteristics of the underlying hardware
|
||||
cache are the same for their virtual address space as they would
|
||||
be if the program had been run directly in a physical address
|
||||
space.</para>
|
||||
|
||||
<para>Note that I say ‘reasonably’ contiguous rather
|
||||
than simply ‘contiguous’. From the point of view of a
|
||||
128K direct mapped cache, the physical address 0 is the same as
|
||||
the physical address 128K. So two side-by-side pages in your
|
||||
virtual address space may wind up being offset 128K and offset
|
||||
132K in physical memory, but could also easily be offset 128K and
|
||||
offset 4K in physical memory and still retain the same cache
|
||||
performance characteristics. So page-coloring does
|
||||
<emphasis>not</emphasis> have to assign truly contiguous pages of
|
||||
physical memory to contiguous pages of virtual memory, it just
|
||||
needs to make sure it assigns contiguous pages from the point of
|
||||
view of cache performance and operation.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
</qandaset>
|
||||
</sect1>
|
||||
</article>
|
||||
@ -1,104 +0,0 @@
|
||||
%!PS-Adobe-2.0 EPSF-2.0
|
||||
%%Title: fig1.eps
|
||||
%%Creator: fig2dev Version 3.2.3 Patchlevel
|
||||
%%CreationDate: Sun Oct 8 19:54:25 2000
|
||||
%%For: nik@canyon.nothing-going-on.org (Nik Clayton)
|
||||
%%BoundingBox: 0 0 119 65
|
||||
%%Magnification: 1.0000
|
||||
%%EndComments
|
||||
/$F2psDict 200 dict def
|
||||
$F2psDict begin
|
||||
$F2psDict /mtrx matrix put
|
||||
/col-1 {0 setgray} bind def
|
||||
/col0 {0.000 0.000 0.000 srgb} bind def
|
||||
/col1 {0.000 0.000 1.000 srgb} bind def
|
||||
/col2 {0.000 1.000 0.000 srgb} bind def
|
||||
/col3 {0.000 1.000 1.000 srgb} bind def
|
||||
/col4 {1.000 0.000 0.000 srgb} bind def
|
||||
/col5 {1.000 0.000 1.000 srgb} bind def
|
||||
/col6 {1.000 1.000 0.000 srgb} bind def
|
||||
/col7 {1.000 1.000 1.000 srgb} bind def
|
||||
/col8 {0.000 0.000 0.560 srgb} bind def
|
||||
/col9 {0.000 0.000 0.690 srgb} bind def
|
||||
/col10 {0.000 0.000 0.820 srgb} bind def
|
||||
/col11 {0.530 0.810 1.000 srgb} bind def
|
||||
/col12 {0.000 0.560 0.000 srgb} bind def
|
||||
/col13 {0.000 0.690 0.000 srgb} bind def
|
||||
/col14 {0.000 0.820 0.000 srgb} bind def
|
||||
/col15 {0.000 0.560 0.560 srgb} bind def
|
||||
/col16 {0.000 0.690 0.690 srgb} bind def
|
||||
/col17 {0.000 0.820 0.820 srgb} bind def
|
||||
/col18 {0.560 0.000 0.000 srgb} bind def
|
||||
/col19 {0.690 0.000 0.000 srgb} bind def
|
||||
/col20 {0.820 0.000 0.000 srgb} bind def
|
||||
/col21 {0.560 0.000 0.560 srgb} bind def
|
||||
/col22 {0.690 0.000 0.690 srgb} bind def
|
||||
/col23 {0.820 0.000 0.820 srgb} bind def
|
||||
/col24 {0.500 0.190 0.000 srgb} bind def
|
||||
/col25 {0.630 0.250 0.000 srgb} bind def
|
||||
/col26 {0.750 0.380 0.000 srgb} bind def
|
||||
/col27 {1.000 0.500 0.500 srgb} bind def
|
||||
/col28 {1.000 0.630 0.630 srgb} bind def
|
||||
/col29 {1.000 0.750 0.750 srgb} bind def
|
||||
/col30 {1.000 0.880 0.880 srgb} bind def
|
||||
/col31 {1.000 0.840 0.000 srgb} bind def
|
||||
|
||||
end
|
||||
save
|
||||
newpath 0 65 moveto 0 0 lineto 119 0 lineto 119 65 lineto closepath clip newpath
|
||||
-143.0 298.0 translate
|
||||
1 -1 scale
|
||||
|
||||
/cp {closepath} bind def
|
||||
/ef {eofill} bind def
|
||||
/gr {grestore} bind def
|
||||
/gs {gsave} bind def
|
||||
/sa {save} bind def
|
||||
/rs {restore} bind def
|
||||
/l {lineto} bind def
|
||||
/m {moveto} bind def
|
||||
/rm {rmoveto} bind def
|
||||
/n {newpath} bind def
|
||||
/s {stroke} bind def
|
||||
/sh {show} bind def
|
||||
/slc {setlinecap} bind def
|
||||
/slj {setlinejoin} bind def
|
||||
/slw {setlinewidth} bind def
|
||||
/srgb {setrgbcolor} bind def
|
||||
/rot {rotate} bind def
|
||||
/sc {scale} bind def
|
||||
/sd {setdash} bind def
|
||||
/ff {findfont} bind def
|
||||
/sf {setfont} bind def
|
||||
/scf {scalefont} bind def
|
||||
/sw {stringwidth} bind def
|
||||
/tr {translate} bind def
|
||||
/tnt {dup dup currentrgbcolor
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
|
||||
bind def
|
||||
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
|
||||
4 -2 roll mul srgb} bind def
|
||||
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
|
||||
/$F2psEnd {$F2psEnteredState restore end} def
|
||||
|
||||
$F2psBegin
|
||||
%%Page: 1 1
|
||||
10 setmiterlimit
|
||||
0.06000 0.06000 sc
|
||||
% Polyline
|
||||
7.500 slw
|
||||
n 2400 4200 m 4050 4200 l 4050 4950 l 2400 4950 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 4050 4200 m
|
||||
4350 3900 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2400 4200 m 2700 3900 l 4350 3900 l 4350 4650 l
|
||||
4050 4950 l gs col0 s gr
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3225 4650 m
|
||||
gs 1 -1 sc (A) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
$F2psEnd
|
||||
rs
|
||||
@ -1,115 +0,0 @@
|
||||
%!PS-Adobe-2.0 EPSF-2.0
|
||||
%%Title: fig2.eps
|
||||
%%Creator: fig2dev Version 3.2.3 Patchlevel
|
||||
%%CreationDate: Sun Oct 8 19:55:31 2000
|
||||
%%For: nik@canyon.nothing-going-on.org (Nik Clayton)
|
||||
%%BoundingBox: 0 0 120 110
|
||||
%%Magnification: 1.0000
|
||||
%%EndComments
|
||||
/$F2psDict 200 dict def
|
||||
$F2psDict begin
|
||||
$F2psDict /mtrx matrix put
|
||||
/col-1 {0 setgray} bind def
|
||||
/col0 {0.000 0.000 0.000 srgb} bind def
|
||||
/col1 {0.000 0.000 1.000 srgb} bind def
|
||||
/col2 {0.000 1.000 0.000 srgb} bind def
|
||||
/col3 {0.000 1.000 1.000 srgb} bind def
|
||||
/col4 {1.000 0.000 0.000 srgb} bind def
|
||||
/col5 {1.000 0.000 1.000 srgb} bind def
|
||||
/col6 {1.000 1.000 0.000 srgb} bind def
|
||||
/col7 {1.000 1.000 1.000 srgb} bind def
|
||||
/col8 {0.000 0.000 0.560 srgb} bind def
|
||||
/col9 {0.000 0.000 0.690 srgb} bind def
|
||||
/col10 {0.000 0.000 0.820 srgb} bind def
|
||||
/col11 {0.530 0.810 1.000 srgb} bind def
|
||||
/col12 {0.000 0.560 0.000 srgb} bind def
|
||||
/col13 {0.000 0.690 0.000 srgb} bind def
|
||||
/col14 {0.000 0.820 0.000 srgb} bind def
|
||||
/col15 {0.000 0.560 0.560 srgb} bind def
|
||||
/col16 {0.000 0.690 0.690 srgb} bind def
|
||||
/col17 {0.000 0.820 0.820 srgb} bind def
|
||||
/col18 {0.560 0.000 0.000 srgb} bind def
|
||||
/col19 {0.690 0.000 0.000 srgb} bind def
|
||||
/col20 {0.820 0.000 0.000 srgb} bind def
|
||||
/col21 {0.560 0.000 0.560 srgb} bind def
|
||||
/col22 {0.690 0.000 0.690 srgb} bind def
|
||||
/col23 {0.820 0.000 0.820 srgb} bind def
|
||||
/col24 {0.500 0.190 0.000 srgb} bind def
|
||||
/col25 {0.630 0.250 0.000 srgb} bind def
|
||||
/col26 {0.750 0.380 0.000 srgb} bind def
|
||||
/col27 {1.000 0.500 0.500 srgb} bind def
|
||||
/col28 {1.000 0.630 0.630 srgb} bind def
|
||||
/col29 {1.000 0.750 0.750 srgb} bind def
|
||||
/col30 {1.000 0.880 0.880 srgb} bind def
|
||||
/col31 {1.000 0.840 0.000 srgb} bind def
|
||||
|
||||
end
|
||||
save
|
||||
newpath 0 110 moveto 0 0 lineto 120 0 lineto 120 110 lineto closepath clip newpath
|
||||
-174.0 370.0 translate
|
||||
1 -1 scale
|
||||
|
||||
/cp {closepath} bind def
|
||||
/ef {eofill} bind def
|
||||
/gr {grestore} bind def
|
||||
/gs {gsave} bind def
|
||||
/sa {save} bind def
|
||||
/rs {restore} bind def
|
||||
/l {lineto} bind def
|
||||
/m {moveto} bind def
|
||||
/rm {rmoveto} bind def
|
||||
/n {newpath} bind def
|
||||
/s {stroke} bind def
|
||||
/sh {show} bind def
|
||||
/slc {setlinecap} bind def
|
||||
/slj {setlinejoin} bind def
|
||||
/slw {setlinewidth} bind def
|
||||
/srgb {setrgbcolor} bind def
|
||||
/rot {rotate} bind def
|
||||
/sc {scale} bind def
|
||||
/sd {setdash} bind def
|
||||
/ff {findfont} bind def
|
||||
/sf {setfont} bind def
|
||||
/scf {scalefont} bind def
|
||||
/sw {stringwidth} bind def
|
||||
/tr {translate} bind def
|
||||
/tnt {dup dup currentrgbcolor
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
|
||||
bind def
|
||||
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
|
||||
4 -2 roll mul srgb} bind def
|
||||
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
|
||||
/$F2psEnd {$F2psEnteredState restore end} def
|
||||
|
||||
$F2psBegin
|
||||
%%Page: 1 1
|
||||
10 setmiterlimit
|
||||
0.06000 0.06000 sc
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3750 5100 m
|
||||
gs 1 -1 sc (B) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
% Polyline
|
||||
7.500 slw
|
||||
n 4871 5100 m 4879 5100 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 5400 m 4575 5400 l 4575 6150 l 2925 6150 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 4575 4650 m
|
||||
4875 4350 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 4650 m 4575 4650 l 4575 5400 l 2925 5400 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 4650 m 3225 4350 l 4875 4350 l 4875 5100 l
|
||||
4575 5400 l gs col0 s gr
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3750 5850 m
|
||||
gs 1 -1 sc (A) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
% Polyline
|
||||
n 4875 5100 m 4875 5850 l
|
||||
4575 6150 l gs col0 s gr
|
||||
$F2psEnd
|
||||
rs
|
||||
@ -1,133 +0,0 @@
|
||||
%!PS-Adobe-2.0 EPSF-2.0
|
||||
%%Title: fig3.eps
|
||||
%%Creator: fig2dev Version 3.2.3 Patchlevel
|
||||
%%CreationDate: Sun Oct 8 19:53:51 2000
|
||||
%%For: nik@canyon.nothing-going-on.org (Nik Clayton)
|
||||
%%BoundingBox: 0 0 120 155
|
||||
%%Magnification: 1.0000
|
||||
%%EndComments
|
||||
/$F2psDict 200 dict def
|
||||
$F2psDict begin
|
||||
$F2psDict /mtrx matrix put
|
||||
/col-1 {0 setgray} bind def
|
||||
/col0 {0.000 0.000 0.000 srgb} bind def
|
||||
/col1 {0.000 0.000 1.000 srgb} bind def
|
||||
/col2 {0.000 1.000 0.000 srgb} bind def
|
||||
/col3 {0.000 1.000 1.000 srgb} bind def
|
||||
/col4 {1.000 0.000 0.000 srgb} bind def
|
||||
/col5 {1.000 0.000 1.000 srgb} bind def
|
||||
/col6 {1.000 1.000 0.000 srgb} bind def
|
||||
/col7 {1.000 1.000 1.000 srgb} bind def
|
||||
/col8 {0.000 0.000 0.560 srgb} bind def
|
||||
/col9 {0.000 0.000 0.690 srgb} bind def
|
||||
/col10 {0.000 0.000 0.820 srgb} bind def
|
||||
/col11 {0.530 0.810 1.000 srgb} bind def
|
||||
/col12 {0.000 0.560 0.000 srgb} bind def
|
||||
/col13 {0.000 0.690 0.000 srgb} bind def
|
||||
/col14 {0.000 0.820 0.000 srgb} bind def
|
||||
/col15 {0.000 0.560 0.560 srgb} bind def
|
||||
/col16 {0.000 0.690 0.690 srgb} bind def
|
||||
/col17 {0.000 0.820 0.820 srgb} bind def
|
||||
/col18 {0.560 0.000 0.000 srgb} bind def
|
||||
/col19 {0.690 0.000 0.000 srgb} bind def
|
||||
/col20 {0.820 0.000 0.000 srgb} bind def
|
||||
/col21 {0.560 0.000 0.560 srgb} bind def
|
||||
/col22 {0.690 0.000 0.690 srgb} bind def
|
||||
/col23 {0.820 0.000 0.820 srgb} bind def
|
||||
/col24 {0.500 0.190 0.000 srgb} bind def
|
||||
/col25 {0.630 0.250 0.000 srgb} bind def
|
||||
/col26 {0.750 0.380 0.000 srgb} bind def
|
||||
/col27 {1.000 0.500 0.500 srgb} bind def
|
||||
/col28 {1.000 0.630 0.630 srgb} bind def
|
||||
/col29 {1.000 0.750 0.750 srgb} bind def
|
||||
/col30 {1.000 0.880 0.880 srgb} bind def
|
||||
/col31 {1.000 0.840 0.000 srgb} bind def
|
||||
|
||||
end
|
||||
save
|
||||
newpath 0 155 moveto 0 0 lineto 120 0 lineto 120 155 lineto closepath clip newpath
|
||||
-174.0 370.0 translate
|
||||
1 -1 scale
|
||||
|
||||
/cp {closepath} bind def
|
||||
/ef {eofill} bind def
|
||||
/gr {grestore} bind def
|
||||
/gs {gsave} bind def
|
||||
/sa {save} bind def
|
||||
/rs {restore} bind def
|
||||
/l {lineto} bind def
|
||||
/m {moveto} bind def
|
||||
/rm {rmoveto} bind def
|
||||
/n {newpath} bind def
|
||||
/s {stroke} bind def
|
||||
/sh {show} bind def
|
||||
/slc {setlinecap} bind def
|
||||
/slj {setlinejoin} bind def
|
||||
/slw {setlinewidth} bind def
|
||||
/srgb {setrgbcolor} bind def
|
||||
/rot {rotate} bind def
|
||||
/sc {scale} bind def
|
||||
/sd {setdash} bind def
|
||||
/ff {findfont} bind def
|
||||
/sf {setfont} bind def
|
||||
/scf {scalefont} bind def
|
||||
/sw {stringwidth} bind def
|
||||
/tr {translate} bind def
|
||||
/tnt {dup dup currentrgbcolor
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
|
||||
bind def
|
||||
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
|
||||
4 -2 roll mul srgb} bind def
|
||||
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
|
||||
/$F2psEnd {$F2psEnteredState restore end} def
|
||||
|
||||
$F2psBegin
|
||||
%%Page: 1 1
|
||||
10 setmiterlimit
|
||||
0.06000 0.06000 sc
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
4125 4350 m
|
||||
gs 1 -1 sc (C2) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
% Polyline
|
||||
7.500 slw
|
||||
n 4871 5100 m 4879 5100 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 5400 m 4575 5400 l 4575 6150 l 2925 6150 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 4575 4650 m
|
||||
4875 4350 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 4650 m 4575 4650 l 4575 5400 l 2925 5400 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 4875 3600 m 4875 5100 l
|
||||
4575 5400 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 4650 m 2925 3900 l 3225 3600 l
|
||||
4875 3600 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 3900 m 4425 3900 l 4575 3900 l
|
||||
4875 3600 l gs col0 s gr
|
||||
% Polyline
|
||||
n 4575 4650 m
|
||||
4575 3900 l gs col0 s gr
|
||||
% Polyline
|
||||
n 3750 4650 m 3750 3900 l
|
||||
4050 3600 l gs col0 s gr
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3750 5850 m
|
||||
gs 1 -1 sc (A) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3750 5100 m
|
||||
gs 1 -1 sc (B) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3375 4350 m
|
||||
gs 1 -1 sc (C1) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
% Polyline
|
||||
n 4875 5100 m 4875 5850 l
|
||||
4575 6150 l gs col0 s gr
|
||||
$F2psEnd
|
||||
rs
|
||||
@ -1,133 +0,0 @@
|
||||
%!PS-Adobe-2.0 EPSF-2.0
|
||||
%%Title: fig4.eps
|
||||
%%Creator: fig2dev Version 3.2.3 Patchlevel
|
||||
%%CreationDate: Sun Oct 8 19:55:53 2000
|
||||
%%For: nik@canyon.nothing-going-on.org (Nik Clayton)
|
||||
%%BoundingBox: 0 0 120 155
|
||||
%%Magnification: 1.0000
|
||||
%%EndComments
|
||||
/$F2psDict 200 dict def
|
||||
$F2psDict begin
|
||||
$F2psDict /mtrx matrix put
|
||||
/col-1 {0 setgray} bind def
|
||||
/col0 {0.000 0.000 0.000 srgb} bind def
|
||||
/col1 {0.000 0.000 1.000 srgb} bind def
|
||||
/col2 {0.000 1.000 0.000 srgb} bind def
|
||||
/col3 {0.000 1.000 1.000 srgb} bind def
|
||||
/col4 {1.000 0.000 0.000 srgb} bind def
|
||||
/col5 {1.000 0.000 1.000 srgb} bind def
|
||||
/col6 {1.000 1.000 0.000 srgb} bind def
|
||||
/col7 {1.000 1.000 1.000 srgb} bind def
|
||||
/col8 {0.000 0.000 0.560 srgb} bind def
|
||||
/col9 {0.000 0.000 0.690 srgb} bind def
|
||||
/col10 {0.000 0.000 0.820 srgb} bind def
|
||||
/col11 {0.530 0.810 1.000 srgb} bind def
|
||||
/col12 {0.000 0.560 0.000 srgb} bind def
|
||||
/col13 {0.000 0.690 0.000 srgb} bind def
|
||||
/col14 {0.000 0.820 0.000 srgb} bind def
|
||||
/col15 {0.000 0.560 0.560 srgb} bind def
|
||||
/col16 {0.000 0.690 0.690 srgb} bind def
|
||||
/col17 {0.000 0.820 0.820 srgb} bind def
|
||||
/col18 {0.560 0.000 0.000 srgb} bind def
|
||||
/col19 {0.690 0.000 0.000 srgb} bind def
|
||||
/col20 {0.820 0.000 0.000 srgb} bind def
|
||||
/col21 {0.560 0.000 0.560 srgb} bind def
|
||||
/col22 {0.690 0.000 0.690 srgb} bind def
|
||||
/col23 {0.820 0.000 0.820 srgb} bind def
|
||||
/col24 {0.500 0.190 0.000 srgb} bind def
|
||||
/col25 {0.630 0.250 0.000 srgb} bind def
|
||||
/col26 {0.750 0.380 0.000 srgb} bind def
|
||||
/col27 {1.000 0.500 0.500 srgb} bind def
|
||||
/col28 {1.000 0.630 0.630 srgb} bind def
|
||||
/col29 {1.000 0.750 0.750 srgb} bind def
|
||||
/col30 {1.000 0.880 0.880 srgb} bind def
|
||||
/col31 {1.000 0.840 0.000 srgb} bind def
|
||||
|
||||
end
|
||||
save
|
||||
newpath 0 155 moveto 0 0 lineto 120 0 lineto 120 155 lineto closepath clip newpath
|
||||
-174.0 370.0 translate
|
||||
1 -1 scale
|
||||
|
||||
/cp {closepath} bind def
|
||||
/ef {eofill} bind def
|
||||
/gr {grestore} bind def
|
||||
/gs {gsave} bind def
|
||||
/sa {save} bind def
|
||||
/rs {restore} bind def
|
||||
/l {lineto} bind def
|
||||
/m {moveto} bind def
|
||||
/rm {rmoveto} bind def
|
||||
/n {newpath} bind def
|
||||
/s {stroke} bind def
|
||||
/sh {show} bind def
|
||||
/slc {setlinecap} bind def
|
||||
/slj {setlinejoin} bind def
|
||||
/slw {setlinewidth} bind def
|
||||
/srgb {setrgbcolor} bind def
|
||||
/rot {rotate} bind def
|
||||
/sc {scale} bind def
|
||||
/sd {setdash} bind def
|
||||
/ff {findfont} bind def
|
||||
/sf {setfont} bind def
|
||||
/scf {scalefont} bind def
|
||||
/sw {stringwidth} bind def
|
||||
/tr {translate} bind def
|
||||
/tnt {dup dup currentrgbcolor
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add
|
||||
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
|
||||
bind def
|
||||
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
|
||||
4 -2 roll mul srgb} bind def
|
||||
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
|
||||
/$F2psEnd {$F2psEnteredState restore end} def
|
||||
|
||||
$F2psBegin
|
||||
%%Page: 1 1
|
||||
10 setmiterlimit
|
||||
0.06000 0.06000 sc
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3375 4350 m
|
||||
gs 1 -1 sc (C1) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
% Polyline
|
||||
7.500 slw
|
||||
n 4871 5100 m 4879 5100 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 5400 m 4575 5400 l 4575 6150 l 2925 6150 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 4575 4650 m
|
||||
4875 4350 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 4650 m 4575 4650 l 4575 5400 l 2925 5400 l
|
||||
cp gs col0 s gr
|
||||
% Polyline
|
||||
n 4875 4350 m 4875 5100 l
|
||||
4575 5400 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 4650 m 2925 3900 l 3225 3600 l
|
||||
4050 3600 l gs col0 s gr
|
||||
% Polyline
|
||||
n 3750 4650 m 3750 3900 l
|
||||
4050 3600 l gs col0 s gr
|
||||
% Polyline
|
||||
n 2925 3900 m
|
||||
3750 3900 l gs col0 s gr
|
||||
% Polyline
|
||||
n 3750 4650 m 4050 4350 l
|
||||
4875 4350 l gs col0 s gr
|
||||
% Polyline
|
||||
n 4050 4350 m
|
||||
4050 3600 l gs col0 s gr
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3750 5850 m
|
||||
gs 1 -1 sc (A) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
/Helvetica-Bold ff 180.00 scf sf
|
||||
3750 5100 m
|
||||
gs 1 -1 sc (B) dup sw pop 2 div neg 0 rm col0 sh gr
|
||||
% Polyline
|
||||
n 4875 5100 m 4875 5850 l
|
||||
4575 6150 l gs col0 s gr
|
||||
$F2psEnd
|
||||
rs
|
||||
@ -1,14 +0,0 @@
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/articles/programming-tools/Makefile,v 1.8 1999/09/06 06:52:38 peter Exp $
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.sgml
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,267 +0,0 @@
|
||||
<!-- $FreeBSD -->
|
||||
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
]>
|
||||
|
||||
<article>
|
||||
<articleinfo>
|
||||
<title>ZIP Drives</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Jason</firstname>
|
||||
<surname>Bacon</surname>
|
||||
|
||||
<affiliation>
|
||||
<address><email>acadix@execpc.com</email></address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</articleinfo>
|
||||
|
||||
<sect1>
|
||||
<title>ZIP Drive Basics</title>
|
||||
|
||||
<para>ZIP disks are high capacity, removable, magnetic disks, which can be
|
||||
read or written by ZIP drives from iomega corporation. ZIP disks are
|
||||
similar to floppy disks, except that they are much faster, and have a
|
||||
much greater capacity. While floppy disks typically hold 1.44
|
||||
megabytes, ZIP disks are available in two sizes, namely 100 megabytes
|
||||
and 250 megabytes. ZIP drives should not be confused with the
|
||||
super-floppy, a 120 megabyte floppy drive which also handles traditional
|
||||
1.44 megabyte floppies.</para>
|
||||
|
||||
<para>IOMEGA also sells a higher capacity, higher performance drive
|
||||
called the JAZZ drive. JAZZ drives come in 1 gigabyte and
|
||||
2 gigabyte sizes.</para>
|
||||
|
||||
<para>ZIP drives are available as internal or external units, using one
|
||||
of three interfaces:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>The SCSI (Small Computer Standard Interface) interface is the
|
||||
fastest, most sophisticated, most expandable, and most expensive
|
||||
interface. The SCSI interface is used by all types of computers
|
||||
from PC's to RISC workstations to minicomputers, to connect all
|
||||
types of peripherals such as disk drives, tape drives, scanners, and
|
||||
so on. SCSI ZIP drives may be internal or external, assuming your
|
||||
host adapter has an external connector.</para>
|
||||
|
||||
<note>
|
||||
<para>If you are using an external SCSI device, it is important
|
||||
never to connect or disconnect it from the SCSI bus while the
|
||||
computer is running. Doing so may cause file-system damage on the
|
||||
disks that remain connected.</para>
|
||||
</note>
|
||||
|
||||
<para>If you want maximum performance and easy setup, the SCSI
|
||||
interface is the best choice. This will probably require adding a
|
||||
SCSI host adapter, since most PC's (except for high-performance
|
||||
servers) don't have built-in SCSI support. Each SCSI host adapter
|
||||
can support either 7 or 15 SCSI devices, depending on the
|
||||
model.</para>
|
||||
|
||||
<para>Each SCSI device has it's own controller, and these
|
||||
controllers are fairly intelligent and well standardized, (the
|
||||
second `S' in SCSI is for Standard) so from the operating system's
|
||||
point of view, all SCSI disk drives look about the same, as do all
|
||||
SCSI tape drives, etc. To support SCSI devices, the operating
|
||||
system need only have a driver for the particular host adapter, and
|
||||
a generic driver for each type of device, i.e. a SCSI disk driver,
|
||||
SCSI tape driver, and so on. There are some SCSI devices that can
|
||||
be better utilized with specialized drivers (e.g. DAT tape drives),
|
||||
but they tend to work OK with the generic driver, too. It's just
|
||||
that the generic drivers may not support some of the special
|
||||
features.</para>
|
||||
|
||||
<para>Using a SCSI zip drive is simply a matter of determining which
|
||||
device file in the <filename>/dev</filename> directory represents
|
||||
the ZIP drive. This can be determined by looking at the boot
|
||||
messages while FreeBSD is booting (or in
|
||||
<filename>/var/log/messages</filename> after booting), where you'll
|
||||
see a line something like this:</para>
|
||||
|
||||
<programlisting>da1: <IOMEGA ZIP 100 D.13> Removable Direct Access SCSI-2 Device</programlisting>
|
||||
|
||||
<para>This means that the ZIP drive is represented by the file
|
||||
<filename>/dev/da1</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The IDE (Integrated Drive Electronics) interface is a low-cost
|
||||
disk drive interface used by many desktop PC's. Most IDE devices
|
||||
are strictly internal.</para>
|
||||
|
||||
<para>Performance of IDE ZIP drives is comparable to SCSI ZIP drives.
|
||||
(The IDE interface is not as fast as SCSI, but ZIP drives
|
||||
performance is limited mainly by the mechanics of the drive, not by
|
||||
the bus interface.)</para>
|
||||
|
||||
<para>The drawback of the IDE interface is the limitations it imposes.
|
||||
Most IDE adapters can only support 2 devices, and IDE interfaces are
|
||||
not typically designed for the long term. For example, the original
|
||||
IDE interface would not support hard disks with more than 1024
|
||||
cylinders, which forced a lot of people to upgrade their hardware
|
||||
prematurely. If you have plans to expand your PC by adding another
|
||||
disk, a tape drive, or scanner, you may want to invest in a SCSI
|
||||
host adapter and a SCSI ZIP drive to avoid problems in the
|
||||
future.</para>
|
||||
|
||||
<para>IDE devices in FreeBSD are prefixed with a <literal>w</literal>.
|
||||
For example, an IDE hard disk might be
|
||||
<filename>/dev/wd0</filename>, an IDE (ATAPI) cdrom might be
|
||||
<filename>/dev/wcd1</filename>, and so on.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The parallel port interface is popular for portable external
|
||||
devices such as external ZIP drives and scanners, because virtually
|
||||
every computer has a standard parallel port (usually used for
|
||||
printers). This makes things easy for people to transfer data
|
||||
between multiple computers by toting around their ZIP drive.</para>
|
||||
|
||||
<para>Performance will generally be slower than a SCSI or IDE ZIP
|
||||
drive, since it is limited by the speed of the parallel port.
|
||||
Parallel port speed varies considerably between various computers,
|
||||
and can often be configured in the system BIOS. Some machines
|
||||
will also require BIOS configuration to operate the parallel
|
||||
port in bidirectional mode. (Parallel ports were originally
|
||||
designed only for output to printers)</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Parallel ZIP: The <devicename>vpo</devicename> Driver</title>
|
||||
|
||||
<para>To use a parallel-port ZIP drive under FreeBSD, the
|
||||
<devicename>vpo</devicename> driver must be configured into the kernel.
|
||||
Parallel port ZIP drives also have a built-in SCSI controller. The vpo
|
||||
driver allows the FreeBSD kernel to communicate with the ZIP drive's
|
||||
SCSI controller through the parallel port.</para>
|
||||
|
||||
<para>Since the vpo driver is not a standard part of the kernel (as of
|
||||
FreeBSD 3.2), you will need to rebuild the kernel to enable this device.
|
||||
The process of building a kernel is outlined in detail in another
|
||||
section. The following steps outline the process in brief for the
|
||||
purpose of enabling the vpo driver:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Run <command>/stand/sysinstall</command>, and install the kernel
|
||||
source code on your system.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd /sys/i386/conf</userinput>
|
||||
&prompt.root; <userinput>cp GENERIC MYKERNEL</userinput></screen>
|
||||
|
||||
<para>Edit <filename>MYKERNEL</filename>, change the
|
||||
<literal>ident</literal> line to <literal>MYKERNEL</literal>, and
|
||||
uncomment the line describing the vpo driver.</para>
|
||||
|
||||
<para>If you have a second parallel port, you may need to copy the
|
||||
section for <literal>ppc0</literal> to create a
|
||||
<literal>ppc1</literal> device. The second parallel port usually
|
||||
uses IRQ 5 and address 378. Only the IRQ is required in the config
|
||||
file.</para>
|
||||
|
||||
<para>If you're root hard disk is a SCSI disk, you might run into a
|
||||
problem with probing order, which will cause the system to attempt
|
||||
to use the ZIP drive as the root device. This will cause a boot
|
||||
failure, unless you happen to have a FreeBSD root file-system on
|
||||
your ZIP disk! In this case, you will need to <quote>wire
|
||||
down</quote> the root disk, i.e. force the kernel to bind a
|
||||
specific device to <filename>/dev/da0</filename>, the root SCSI
|
||||
disk. It will then assign the ZIP disk to the next available SCSI
|
||||
disk, e.g. <literal>/dev/da1</literal>. To wire down your SCSI hard
|
||||
drive as <literal>da0</literal>, change the line
|
||||
|
||||
<programlisting>device da0</programlisting>
|
||||
|
||||
to
|
||||
|
||||
<programlisting>disk da0 at scbus0 target 0 unit 0</programlisting></para>
|
||||
|
||||
<para>You may need to change the target above to match the SCSI ID of
|
||||
your disk drive. You should also wire down the scbus0 entry to your
|
||||
controller. For example, if you have an Adaptec 15xx controller,
|
||||
you would change
|
||||
|
||||
<programlisting>controller scbus0</programlisting>
|
||||
|
||||
to
|
||||
|
||||
<programlisting>controller scbus0 at aha0</programlisting></para>
|
||||
|
||||
<para>Lastly, as long as you're editing the kernel config, you
|
||||
can take the opportunity to remove all the unnecessary drivers. This
|
||||
should be done with a great deal of caution, and only if you feel
|
||||
confident about making kernel modifications. Removing unnecessary
|
||||
drivers will reduce the kernel size, leaving more memory available
|
||||
for your applications. To determine which drivers are not needed,
|
||||
go to the end of the file <filename>/var/log/messages</filename>, and look for lines
|
||||
reading "not found". Then, comment out these devices in your config
|
||||
file. You can also change other options to reduce the size and
|
||||
increase the speed of your kernel. Read the section on rebuilding
|
||||
your kernel for more complete information.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Now it's time to compile the kernel:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/usr/sbin/config MYKERNEL</userinput>
|
||||
&prompt.root; <userinput>cd ../../compile/MYKERNEL</userinput>
|
||||
&prompt.root; <userinput>make clean depend && make all install</userinput></screen>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>After the kernel is rebuilt, you'll need to reboot. Make sure the
|
||||
ZIP drive is connected to the parallel port before the boot begins. You
|
||||
should see the ZIP drive show up in the boot messages as device vpo0 or
|
||||
vpo1, depending on which parallel port the drive is attached to. It
|
||||
should also show which device file the ZIP drive has been bound to. This
|
||||
will be <filename>/dev/da0</filename> if you have no other SCSI disks in
|
||||
the system, or <filename>/dev/da1</filename> if you have a SCSI hard
|
||||
disk wired down as the root device.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Mounting ZIP disks</title>
|
||||
|
||||
<para>To access the ZIP disk, you simply mount it like any other disk
|
||||
device. The file-system is represented as slice 4 on the device, so for
|
||||
SCSI or parallel ZIP disks, you would use:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount_msdos /dev/da1s4 /mnt</userinput></screen>
|
||||
|
||||
<para>For IDE ZIP drives, use:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount_msdos /dev/wd1s4 /mnt</userinput></screen>
|
||||
|
||||
<para>It will also be helpful to update <filename>/etc/fstab</filename> to
|
||||
make mounting easier. Add a line like the following, edited to suit your
|
||||
system:
|
||||
|
||||
<programlisting>/dev/da1s4 /zip msdos rw,noauto 0 0</programlisting>
|
||||
|
||||
and create the directory <filename>/zip</filename>.</para>
|
||||
|
||||
<para>Then, you can mount simply by typing
|
||||
|
||||
<screen>&prompt.root; <userinput>mount /zip</userinput></screen>
|
||||
|
||||
and unmount by typing
|
||||
|
||||
<screen>&prompt.root; <userinput>umount /zip</userinput></screen></para>
|
||||
|
||||
<para>For more information on the format of
|
||||
<filename>/etc/fstab</filename>, see &man.fstab.5;.</para>
|
||||
|
||||
<para>You can also create a FreeBSD file-system on the ZIP disk
|
||||
using &man.newfs.8;. However, the disk will only be usable on a FreeBSD
|
||||
system, or perhaps a few other Unix clones that recognize FreeBSD
|
||||
file-systems. (Definitely not DOS or Windows.)</para>
|
||||
</sect1>
|
||||
</article>
|
||||
@ -1,15 +0,0 @@
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/books/Makefile,v 1.9 2001/04/09 20:41:33 nik Exp $
|
||||
|
||||
SUBDIR = corp-net-guide
|
||||
SUBDIR+= design-44bsd
|
||||
SUBDIR+= developers-handbook
|
||||
SUBDIR+= faq
|
||||
SUBDIR+= fdp-primer
|
||||
SUBDIR+= handbook
|
||||
SUBDIR+= porters-handbook
|
||||
SUBDIR+= ppp-primer
|
||||
|
||||
ROOT_SYMLINKS= faq handbook
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,5 +0,0 @@
|
||||
#
|
||||
# $FreeBSD$
|
||||
#
|
||||
|
||||
DESTDIR?= ${DOCDIR}/en_US.ISO_8859-1/books/${.CURDIR:T}
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,25 +0,0 @@
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/books/design-44bsd/Makefile,v 1.2 2001/03/09 18:05:31 nik Exp $
|
||||
|
||||
DOC?= book
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= book.sgml
|
||||
|
||||
IMAGES= 08-01.eps
|
||||
IMAGES+= 08-02.eps
|
||||
IMAGES+= 08-03.eps
|
||||
IMAGES+= 08-04.eps
|
||||
IMAGES+= 08-05.eps
|
||||
IMAGES+= 08-06.eps
|
||||
|
||||
# Use the local DSSSL file
|
||||
DSLHTML?= ${.CURDIR}/freebsd.dsl
|
||||
DSLPRINT?= ${.CURDIR}/freebsd.dsl
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,18 +0,0 @@
|
||||
<!-- $FreeBSD: doc/en_US.ISO_8859-1/books/design-44bsd/freebsd.dsl,v 1.1 2001/03/09 18:05:31 nik Exp $ -->
|
||||
|
||||
<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
|
||||
<!ENTITY freebsd.dsl SYSTEM "../../share/sgml/freebsd.dsl" CDATA DSSSL>
|
||||
]>
|
||||
|
||||
<style-sheet>
|
||||
<style-specification use="docbook">
|
||||
<style-specification-body>
|
||||
|
||||
;; Keep the legalnotice together with the rest of the text
|
||||
(define %generate-legalnotice-link%
|
||||
#f)
|
||||
</style-specification-body>
|
||||
</style-specification>
|
||||
|
||||
<external-specification id="docbook" document="freebsd.dsl">
|
||||
</style-sheet>
|
||||
@ -1,20 +0,0 @@
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/books/design-44bsd/Makefile,v 1.1 2001/02/20 20:01:32 nik Exp $
|
||||
|
||||
DOC?= book
|
||||
|
||||
FORMATS?= html
|
||||
|
||||
IMAGES= fig1.eps fig2.eps
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= book.sgml
|
||||
|
||||
# Use the local DSSSL file
|
||||
DSLHTML?= ${.CURDIR}/freebsd.dsl
|
||||
DSLPRINT?= ${.CURDIR}/freebsd.dsl
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,340 +0,0 @@
|
||||
%!PS-Adobe-2.0 EPSF-1.2
|
||||
%%Title: fig1.ps
|
||||
%%Creator: groff version 1.15
|
||||
%%CreationDate: Fri Jun 30 09:50:25 2000
|
||||
%%For:sheldonh sheldonh
|
||||
%%Pages: 1
|
||||
%%DocumentFonts:
|
||||
%%BoundingBox: 71 687 446 781
|
||||
%%BeginPreview: 376 93 1 93
|
||||
% 0000000000003fffffe00000000000000000000000000000000000000000000000000000001ffffff8000000000000
|
||||
% 000000000007c000001f000000000000000000000000040000000000000000000000000003e0000007c00000000000
|
||||
% 00000000007800000000f0000000000000000000000000000000000000000000000000001c00000000380000000000
|
||||
% 000000000380000000000e00000000000000000000000180000000000000000000000000e000000000070000000000
|
||||
% 000000000c00000000000180000000000000000006496dc0000000000000000000000003000000000000e000000000
|
||||
% 000000003000000000000060000000000000000002ca6d0000000000000000000000000c0000000000001800000000
|
||||
% 0000000040000000002000100000000000000000035469000000000000000000000000300000000008000400000000
|
||||
% 00000001800080100860000c00000000000000000374c9000000000000000000000000400040040218000200000000
|
||||
% 000000020000f395ef600002000000000000000002674b000000000000000000000000800079c57bd8000100000000
|
||||
% 0000000400009893e9200001000000000000000000000000000000000000000000000100004c44fa48000080000000
|
||||
% 0000000800008a9309200001800000000000000000000000000000000000000000000200004544c248000040000000
|
||||
% 00000f0800008e932920000080000000000000000000000000000000000000000003c200004744ca480000400003c0
|
||||
% 00000fe80000f3d9c930000080000000000000000000000000000000000000000003fc000079e6724c0000200003fc
|
||||
% fffffff80000800000000000be7c78f9f1e3e7c78f9f1e3e7c78f9f1e3c7cf8f1f3ffc00004000000000003ffffffc
|
||||
% 00000c0800008000000000008000000000000000000000000000000000000000000384000040000000000020000380
|
||||
% 00000008000590000000000080000000000000000000000000000000000000000000020001c4000000000040000000
|
||||
% 00000008000795a79fef000080000000000000000000000000000000000000000000020001e569ef7f800040000000
|
||||
% 000000040004d2183f8c00010000000000000000000000000000000000000000000001000134861f66000080000000
|
||||
% 000000020004521830e70002000000000000000000000000000000000000000000000080011486183b800080000000
|
||||
% 000000010004533cb32900040000000000000000000000000000000000000000000000c00114cf394c800300000000
|
||||
% 00000000c00799e71def001800000000000000000000000000000000000000000000002001e679ce7f800400000000
|
||||
% 0000000030040000000000600000000000000000000000000000000000000000000000180100000000001800000000
|
||||
% 000000000c040000000001800000000000000000000000000000000000000000000000060100000000006000000000
|
||||
% 00000000030c000000000e00000000000000000000000000000000000000000000000001c300000000038000000000
|
||||
% 0000000000f000000000700000000000000000000000000000000000000000000000000038000000001c0000000000
|
||||
% 00000000000f00000007800000000000000000000000000000000000000000000000000007c0000003e00000000000
|
||||
% 000000000000ff800ff80000000000000000000000000000000000000000000000000000003fe007fc000000000000
|
||||
% 000000000000007ff000000000000000000000000000000000000000000000000000000000001ff800000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000018000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000018000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000018000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000018000000000000000
|
||||
% 000000000000000800000000000000000000000000000000000000000000000000000000000003c000000000000000
|
||||
% 000000000000000800000000000000000000000000000000000000000000000000000000000003c000000000000000
|
||||
% 000000000000000800000000000000000000000000000000000000000000000000000000000003c000000000000000
|
||||
% 000000000000000800000000000000000000000000000000000000000000000000000000000003c000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000008006000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 000000000000000800e002000000000000000000000000000000000000000000000000000000000000000000000000
|
||||
% 0000000000000008008002000000000000000000000000000000000000000000000000000000000000000000000000
|
||||
% 0000000000000008008007000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 000000000000000803def7800000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 00000000000000080122c4000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 00000000000000080146c6000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 000000000000000801448f000000000000000000000000000000000000000000000000000000000000000000000000
|
||||
% 0000000000000008037889800000000000000000000000000000000000000000000000000000000000000000000000
|
||||
% 0000000000000008020000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 00000000000000080a0000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 00000000000000080c0000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000008000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 000000000000003c000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 000000000000003c000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 000000000000003c000000000000000000000000000000000000000000000000000000000000000000000000000000
|
||||
% 000000000000003c000000000000000000000000000000000000000000000000000000000000000000000000000000
|
||||
% 0000000000000018000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000018000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000018000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 0000000000000018000000000000000000000000000000000000000000000000000000000000008000000000000000
|
||||
% 000000000000007fe000000000000000000000000000007fe0000000000000000000000000001ff800000000000000
|
||||
% 000000000000ff801ff0000000000000000000000000ff801ff000000000000080000000003fe007fc000000000000
|
||||
% 00000000000f0000000f80000000000000000000000f0000000f8000000000000000000007c0000003e00000000000
|
||||
% 0000000000f000000000700000000000000000000070000000007000000000003000000038000000001c0000000000
|
||||
% 000000000300000000000e000003bc73e47000000380000000000e000000073db8000001c000000000038000000000
|
||||
% 000000000c00008240800180000598b424b000000c0000824080018000000b19a00000060000002080006000000000
|
||||
% 000000003000008040800060000f19e839e00000300000804080006000001e19200000180000002000001800000000
|
||||
% 00000000c0000080408000180008190839000000c00000804080001800001019200000200000002000000400000000
|
||||
% 0000000100001ef647800004000f49ef11e0000100001ef64780000400001e49600000c0039a5fbd8f000300000000
|
||||
% 00000002000020924880000200000000000000020000209248800002000000000000008000a148a69f000080000000
|
||||
% 000000040000209248800001000000000000000400002092488000010000000000000100012148a298000080000000
|
||||
% 00000008000032924c8000008000000000000f88000032924c800000800000000003c200023348a699000040000000
|
||||
% 0000000800001c9267c000008000000000000ff800001c9267c00000800000000003fe0003deeebc8e000040000000
|
||||
% 000000080000000000000000bffffffffffffff80000000000000000be7cf1e7cf9ffc000000000000000020000000
|
||||
% 0000000800000000000000008000000000000e08000000000000000080000000000384000000000000000020000000
|
||||
% 0000000800041000000000008000000000000008000410000000000080000000000004000104000000000020000000
|
||||
% 00000008000795a79fef00008000000000000008000795a79fef0000800000000000020001e569ef7f800040000000
|
||||
% 000000080004d2183f8c000180000000000000080004d2183f8c000180000000000002000134861f66000040000000
|
||||
% 000000040004521830e7000100000000000000040004521830e700010000000000000100011486183b800080000000
|
||||
% 000000020004533cb329000200000000000000020004533cb329000200000000000000800114cf394c800100000000
|
||||
% 00000001000799e71def000c0000000000000001800799e71def000c000000000000004001e679ce7f800200000000
|
||||
% 00000000c0040000000000100000000000000000400400000000001000000000000000200100000000000400000000
|
||||
% 00000000300400000000006000000000000000003004000000000060000000000000001c0100000000001800000000
|
||||
% 000000000c0c00000000018000000000000000000c0c0000000001800000000000000003030000000000e000000000
|
||||
% 000000000380000000000e0000000000000000000380000000000e000000000000000000e000000000070000000000
|
||||
% 00000000007800000000f0000000000000000000007800000000f00000000000000000001c00000000380000000000
|
||||
% 0000000000078000001f0000000000000000000000078000001f0000000000000000000003e0000007c00000000000
|
||||
% 0000000000007ffdffe00000000000000000000000007ffdffe000000000000000000000001ffffff8000000000000
|
||||
% 0000000000000002000000000000000000000000000000020000000000000000000000000000000000000000000000
|
||||
%%EndImage
|
||||
%%EndPreview
|
||||
save
|
||||
countdictstack
|
||||
mark
|
||||
newpath
|
||||
/showpage {} def
|
||||
%%EndProlog
|
||||
%%Page 1 1
|
||||
%%+ font Times-Roman
|
||||
/setpacking where{
|
||||
pop
|
||||
currentpacking
|
||||
true setpacking
|
||||
}if
|
||||
/grops 120 dict dup begin
|
||||
/SC 32 def
|
||||
/A/show load def
|
||||
/B{0 SC 3 -1 roll widthshow}bind def
|
||||
/C{0 exch ashow}bind def
|
||||
/D{0 exch 0 SC 5 2 roll awidthshow}bind def
|
||||
/E{0 rmoveto show}bind def
|
||||
/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def
|
||||
/G{0 rmoveto 0 exch ashow}bind def
|
||||
/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
|
||||
/I{0 exch rmoveto show}bind def
|
||||
/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def
|
||||
/K{0 exch rmoveto 0 exch ashow}bind def
|
||||
/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
|
||||
/M{rmoveto show}bind def
|
||||
/N{rmoveto 0 SC 3 -1 roll widthshow}bind def
|
||||
/O{rmoveto 0 exch ashow}bind def
|
||||
/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
|
||||
/Q{moveto show}bind def
|
||||
/R{moveto 0 SC 3 -1 roll widthshow}bind def
|
||||
/S{moveto 0 exch ashow}bind def
|
||||
/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def
|
||||
/SF{
|
||||
findfont exch
|
||||
[exch dup 0 exch 0 exch neg 0 0]makefont
|
||||
dup setfont
|
||||
[exch/setfont cvx]cvx bind def
|
||||
}bind def
|
||||
/MF{
|
||||
findfont
|
||||
[5 2 roll
|
||||
0 3 1 roll
|
||||
neg 0 0]makefont
|
||||
dup setfont
|
||||
[exch/setfont cvx]cvx bind def
|
||||
}bind def
|
||||
/level0 0 def
|
||||
/RES 0 def
|
||||
/PL 0 def
|
||||
/LS 0 def
|
||||
/MANUAL{
|
||||
statusdict begin/manualfeed true store end
|
||||
}bind def
|
||||
/PLG{
|
||||
gsave newpath clippath pathbbox grestore
|
||||
exch pop add exch pop
|
||||
}bind def
|
||||
/BP{
|
||||
/level0 save def
|
||||
1 setlinecap
|
||||
1 setlinejoin
|
||||
72 RES div dup scale
|
||||
LS{
|
||||
90 rotate
|
||||
}{
|
||||
0 PL translate
|
||||
}ifelse
|
||||
1 -1 scale
|
||||
}bind def
|
||||
/EP{
|
||||
level0 restore
|
||||
showpage
|
||||
}bind def
|
||||
/DA{
|
||||
newpath arcn stroke
|
||||
}bind def
|
||||
/SN{
|
||||
transform
|
||||
.25 sub exch .25 sub exch
|
||||
round .25 add exch round .25 add exch
|
||||
itransform
|
||||
}bind def
|
||||
/DL{
|
||||
SN
|
||||
moveto
|
||||
SN
|
||||
lineto stroke
|
||||
}bind def
|
||||
/DC{
|
||||
newpath 0 360 arc closepath
|
||||
}bind def
|
||||
/TM matrix def
|
||||
/DE{
|
||||
TM currentmatrix pop
|
||||
translate scale newpath 0 0 .5 0 360 arc closepath
|
||||
TM setmatrix
|
||||
}bind def
|
||||
/RC/rcurveto load def
|
||||
/RL/rlineto load def
|
||||
/ST/stroke load def
|
||||
/MT/moveto load def
|
||||
/CL/closepath load def
|
||||
/FL{
|
||||
currentgray exch setgray fill setgray
|
||||
}bind def
|
||||
/BL/fill load def
|
||||
/LW/setlinewidth load def
|
||||
/RE{
|
||||
findfont
|
||||
dup maxlength 1 index/FontName known not{1 add}if dict begin
|
||||
{
|
||||
1 index/FID ne{def}{pop pop}ifelse
|
||||
}forall
|
||||
/Encoding exch def
|
||||
dup/FontName exch def
|
||||
currentdict end definefont pop
|
||||
}bind def
|
||||
/DEFS 0 def
|
||||
/EBEGIN{
|
||||
moveto
|
||||
DEFS begin
|
||||
}bind def
|
||||
/EEND/end load def
|
||||
/CNT 0 def
|
||||
/level1 0 def
|
||||
/PBEGIN{
|
||||
/level1 save def
|
||||
translate
|
||||
div 3 1 roll div exch scale
|
||||
neg exch neg exch translate
|
||||
0 setgray
|
||||
0 setlinecap
|
||||
1 setlinewidth
|
||||
0 setlinejoin
|
||||
10 setmiterlimit
|
||||
[]0 setdash
|
||||
/setstrokeadjust where{
|
||||
pop
|
||||
false setstrokeadjust
|
||||
}if
|
||||
/setoverprint where{
|
||||
pop
|
||||
false setoverprint
|
||||
}if
|
||||
newpath
|
||||
/CNT countdictstack def
|
||||
userdict begin
|
||||
/showpage{}def
|
||||
}bind def
|
||||
/PEND{
|
||||
clear
|
||||
countdictstack CNT sub{end}repeat
|
||||
level1 restore
|
||||
}bind def
|
||||
end def
|
||||
/setpacking where{
|
||||
pop
|
||||
setpacking
|
||||
}if
|
||||
grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72
|
||||
def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron
|
||||
/scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef
|
||||
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
|
||||
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
|
||||
/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent
|
||||
/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen
|
||||
/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon
|
||||
/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O
|
||||
/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex
|
||||
/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y
|
||||
/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft
|
||||
/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl
|
||||
/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut
|
||||
/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash
|
||||
/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen
|
||||
/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft
|
||||
/logicalnot/minus/registered/macron/degree/plusminus/twosuperior
|
||||
/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior
|
||||
/ordmasculine/guilsinglright/onequarter/onehalf/threequarters
|
||||
/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE
|
||||
/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
|
||||
/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
|
||||
/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn
|
||||
/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla
|
||||
/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis
|
||||
/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash
|
||||
/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def
|
||||
/Times-Roman@0 ENC0/Times-Roman RE/Times-Italic@0 ENC0/Times-Italic RE
|
||||
BP
|
||||
/F0 12/Times-Italic@0 SF(fork)141.534 58.984 Q 68.832 27.216 134.424
|
||||
90.408 DE .4 LW ST/F1 12/Times-Roman@0 SF(process)116.43 97.432 Q(child)
|
||||
121.632 89.368 Q 301.968 88.824 298.368 88.824 DL 308.808 88.824 305.208
|
||||
88.824 DL 315.576 88.824 311.976 88.824 DL 322.416 88.824 318.816 88.824
|
||||
DL 329.184 88.824 325.584 88.824 DL 336.024 88.824 332.424 88.824 DL
|
||||
342.792 88.824 339.192 88.824 DL 349.632 88.824 346.032 88.824 DL
|
||||
349.632 88.824 MT -7.2 1.8 RL 0 -3.6 RL CL BL 349.632 88.824 MT -7.2 1.8
|
||||
RL 0 -3.6 RL CL ST 68.832 27.216 262.44 90.408 DE ST(process)244.374
|
||||
97.432 Q(child)249.576 89.368 Q(process)365.982 97.432 Q(zombie)364.728
|
||||
89.368 Q 383.976 72.408 383.976 76.008 DL 383.976 65.928 383.976 69.528
|
||||
DL 383.976 59.448 383.976 63.048 DL 383.976 52.968 383.976 56.568 DL
|
||||
383.976 46.488 383.976 50.088 DL 383.976 40.008 383.976 43.608 DL
|
||||
383.976 40.008 MT 1.8 7.2 RL -3.6 0 RL CL BL 383.976 40.008 MT 1.8 7.2
|
||||
RL -3.6 0 RL CL ST 68.832 27.216 384.048 90.408 DE ST 72 24.816 99.216
|
||||
24.816 DL 99.216 24.816 MT -7.2 1.8 RL 0 -3.6 RL CL BL 99.216 24.816 MT
|
||||
-7.2 1.8 RL 0 -3.6 RL CL ST 445.608 24.816 418.392 24.816 DL 445.608
|
||||
24.816 MT -7.2 1.8 RL 0 -3.6 RL CL BL 445.608 24.816 MT -7.2 1.8 RL 0
|
||||
-3.6 RL CL ST 228.024 88.824 170.424 88.824 DL 228.024 88.824 MT -7.2
|
||||
1.8 RL 0 -3.6 RL CL BL 228.024 88.824 MT -7.2 1.8 RL 0 -3.6 RL CL ST F0
|
||||
-.24(ex)180.12 84.616 S(ecve).24 E 174.024 24.816 170.424 24.816 DL
|
||||
181.296 24.816 177.696 24.816 DL 188.64 24.816 185.04 24.816 DL 195.984
|
||||
24.816 192.384 24.816 DL 203.256 24.816 199.656 24.816 DL 210.6 24.816
|
||||
207 24.816 DL 217.872 24.816 214.272 24.816 DL 225.216 24.816 221.616
|
||||
24.816 DL 232.56 24.816 228.96 24.816 DL 239.832 24.816 236.232 24.816
|
||||
DL 247.176 24.816 243.576 24.816 DL 254.448 24.816 250.848 24.816 DL
|
||||
261.792 24.816 258.192 24.816 DL 269.136 24.816 265.536 24.816 DL
|
||||
276.408 24.816 272.808 24.816 DL 283.752 24.816 280.152 24.816 DL
|
||||
291.096 24.816 287.496 24.816 DL 298.368 24.816 294.768 24.816 DL
|
||||
305.712 24.816 302.112 24.816 DL 312.984 24.816 309.384 24.816 DL
|
||||
320.328 24.816 316.728 24.816 DL 327.672 24.816 324.072 24.816 DL
|
||||
334.944 24.816 331.344 24.816 DL 342.288 24.816 338.688 24.816 DL
|
||||
349.632 24.816 346.032 24.816 DL 349.632 24.816 MT -7.2 1.8 RL 0 -3.6 RL
|
||||
CL BL 349.632 24.816 MT -7.2 1.8 RL 0 -3.6 RL CL ST(wait)236.838 20.608
|
||||
Q -.24(ex)315.456 84.616 S(it).24 E 131.976 76.008 131.976 40.008 DL
|
||||
131.976 76.008 MT -1.8 -7.2 RL 3.6 0 RL CL BL 131.976 76.008 MT -1.8
|
||||
-7.2 RL 3.6 0 RL CL ST 68.832 27.216 134.424 25.608 DE ST F1(process)
|
||||
116.43 32.632 Q(parent)118.638 24.568 Q 68.832 27.216 384.048 25.608 DE
|
||||
ST(process)365.982 32.632 Q(parent)368.19 24.568 Q EP
|
||||
end
|
||||
%%Trailer
|
||||
cleartomark
|
||||
countdictstack exch sub { end } repeat
|
||||
restore
|
||||
%%EOF
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,18 +0,0 @@
|
||||
<!-- $FreeBSD: doc/en_US.ISO_8859-1/books/design-44bsd/freebsd.dsl,v 1.1 2001/03/09 18:05:31 nik Exp $ -->
|
||||
|
||||
<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
|
||||
<!ENTITY freebsd.dsl SYSTEM "../../share/sgml/freebsd.dsl" CDATA DSSSL>
|
||||
]>
|
||||
|
||||
<style-sheet>
|
||||
<style-specification use="docbook">
|
||||
<style-specification-body>
|
||||
|
||||
;; Keep the legalnotice together with the rest of the text
|
||||
(define %generate-legalnotice-link%
|
||||
#f)
|
||||
</style-specification-body>
|
||||
</style-specification>
|
||||
|
||||
<external-specification id="docbook" document="freebsd.dsl">
|
||||
</style-sheet>
|
||||
@ -1,38 +0,0 @@
|
||||
#
|
||||
# $FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/Makefile,v 1.3 2001/05/11 10:27:00 murray Exp $
|
||||
#
|
||||
# Build the FreeBSD Developers' Handbook.
|
||||
#
|
||||
|
||||
MAINTAINER=asmodai@FreeBSD.org
|
||||
|
||||
DOC?= book
|
||||
|
||||
FORMATS?= html-split
|
||||
|
||||
INSTALL_COMPRESSED?= gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
#
|
||||
# SRCS lists the individual SGML files that make up the document. Changes
|
||||
# to any of these files will force a rebuild
|
||||
#
|
||||
|
||||
# SGML content
|
||||
SRCS= book.sgml
|
||||
SRCS+= tools/chapter.sgml
|
||||
SRCS+= secure/chapter.sgml
|
||||
SRCS+= locking/chapter.sgml
|
||||
SRCS+= isa/chapter.sgml
|
||||
SRCS+= pci/chapter.sgml
|
||||
SRCS+= usb/chapter.sgml
|
||||
SRCS+= scsi/chapter.sgml
|
||||
SRCS+= x86/chapter.sgml
|
||||
SRCS+= vm/chapter.sgml
|
||||
SRCS+= dma/chapter.sgml
|
||||
SRCS+= ipv6/chapter.sgml
|
||||
|
||||
# Entities
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
@ -1,518 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/book.sgml,v 1.18 2001/05/14 01:36:20 murray Exp $
|
||||
-->
|
||||
|
||||
<!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
||||
<!ENTITY % bookinfo PUBLIC "-//FreeBSD//ENTITIES DocBook BookInfo Entities//EN">
|
||||
%bookinfo;
|
||||
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
||||
%man;
|
||||
<!ENTITY % chapters SYSTEM "chapters.ent"> %chapters;
|
||||
<!ENTITY % authors SYSTEM "../handbook/authors.ent"> %authors;
|
||||
<!ENTITY % mailing-lists SYSTEM "../handbook/mailing-lists.ent"> %mailing-lists;
|
||||
]>
|
||||
|
||||
<book>
|
||||
<bookinfo>
|
||||
<title>FreeBSD Developers' Handbook</title>
|
||||
|
||||
<corpauthor>The FreeBSD Documentation Project</corpauthor>
|
||||
|
||||
<pubdate>August 2000</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2000</year>
|
||||
<year>2001</year>
|
||||
<holder>The FreeBSD Documentation Project</holder>
|
||||
</copyright>
|
||||
|
||||
&bookinfo.legalnotice;
|
||||
|
||||
<abstract>
|
||||
<para>Welcome to the Developers' Handbook. This manual is a
|
||||
<emphasis>work in progress</emphasis> 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
|
||||
<ulink URL="http://www.FreeBSD.org/">FreeBSD World Wide Web
|
||||
server</ulink>. It may also be downloaded in a variety of
|
||||
formats and compression options from the <ulink
|
||||
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/doc">FreeBSD FTP
|
||||
server</ulink> or one of the numerous <ulink
|
||||
url="http://www.freebsd.org/handbook/mirrors-ftp.html">mirror
|
||||
sites</ulink>.</para>
|
||||
</abstract>
|
||||
</bookinfo>
|
||||
|
||||
<part id="introduction">
|
||||
<title>Introduction</title>
|
||||
|
||||
<chapter id="developmentplatform">
|
||||
<title>Developing on FreeBSD</title>
|
||||
|
||||
<para>This will need to discuss FreeBSD as a development
|
||||
platform, the vision of BSD, architectural overview, layout of
|
||||
/usr/src, history, etc.</para>
|
||||
|
||||
<para>Thank you for considering FreeBSD as your development
|
||||
platform! We hope it will not let you down.</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="bsdvision">
|
||||
<title>The BSD Vision</title>
|
||||
|
||||
<para></para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="archoverview">
|
||||
<title>Architectural Overview</title>
|
||||
|
||||
<para></para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="sourcelayout">
|
||||
<title>The Layout of /usr/src</title>
|
||||
|
||||
<para>The complete source code to FreeBSD is available from our
|
||||
public CVS repository. The source code is normally installed in
|
||||
<filename class=directory>/usr/src</filename> which contains the
|
||||
following subdirectories.</para>
|
||||
|
||||
<para>
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Directory</entry>
|
||||
<entry>Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><filename class=directory>bin/</filename></entry>
|
||||
<entry>Source for files in
|
||||
<filename>/bin</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>contrib/</filename></entry>
|
||||
<entry>Source for files from contributed software.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>crypto/</filename></entry>
|
||||
<entry>DES source</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>etc/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/etc</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>games/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/usr/games</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>gnu/</filename></entry>
|
||||
<entry>Utilities covered by the GNU Public License</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>include/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/usr/include</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class=directory>kerberosIV/</filename></entry>
|
||||
<entry>Source for Kerbereros version IV</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class=directory>kerberos5/</filename></entry>
|
||||
<entry>Source for Kerbereros version 5</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>lib/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/usr/lib</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>libexec/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/usr/libexec</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class=directory>release/</filename></entry>
|
||||
<entry>Files required to produce a FreeBSD release</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>sbin/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/sbin</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>secure/</filename></entry>
|
||||
<entry>FreeSec sources</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>share/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/sbin</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>sys/</filename></entry>
|
||||
<entry>Kernel source files</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename class=directory>tools/</filename></entry>
|
||||
<entry>Tools used for maintenance and testing of
|
||||
FreeBSD</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class=directory>usr.bin/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/usr/bin</filename></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename
|
||||
class=directory>usr.sbin/</filename></entry>
|
||||
<entry>Source for files in <filename
|
||||
class=directory>/usr/sbin</filename></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="Basics">
|
||||
<title>Basics</title>
|
||||
|
||||
&chap.tools;
|
||||
&chap.secure;
|
||||
|
||||
</part>
|
||||
|
||||
<part id="kernel">
|
||||
<title>Kernel</title>
|
||||
|
||||
<chapter id="kernelhistory">
|
||||
<title>History of the Unix Kernel</title>
|
||||
|
||||
<para>Some history of the Unix/BSD kernel, system calls, how do
|
||||
processes work, blocking, scheduling, threads (kernel),
|
||||
context switching, signals, interrupts, modules, etc.</para>
|
||||
|
||||
<para></para>
|
||||
</chapter>
|
||||
|
||||
&chap.locking;
|
||||
|
||||
</part>
|
||||
|
||||
<part id="memory">
|
||||
<title>Memory Management</title>
|
||||
|
||||
&chap.vm;
|
||||
&chap.dma;
|
||||
|
||||
<!-- <para>VM, paging, swapping, allocating memory, testing for
|
||||
memory leaks, mmap, vnodes, etc.</para> -->
|
||||
|
||||
</part>
|
||||
|
||||
<part id="iosystem">
|
||||
<title>I/O System</title>
|
||||
|
||||
<chapter id="ufs">
|
||||
<title>UFS</title>
|
||||
|
||||
<para>UFS, FFS, Ext2FS, JFS, inodes, buffer cache, labeling,
|
||||
locking, metadata, soft-updates, LFS, portalfs, procfs,
|
||||
vnodes, memory sharing, memory objects, TLBs, caching</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="ipc">
|
||||
<title>Interprocess Communication</title>
|
||||
|
||||
<chapter id="signals">
|
||||
<title>Signals</title>
|
||||
|
||||
<para>Signals, pipes, semaphores, message queues, shared memory,
|
||||
ports, sockets, doors</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="networking">
|
||||
<title>Networking</title>
|
||||
|
||||
<chapter id="sockets">
|
||||
<title>Sockets</title>
|
||||
|
||||
<para>Sockets, bpf, IP, TCP, UDP, ICMP, OSI, bridging,
|
||||
firewalling, NAT, switching, etc</para>
|
||||
|
||||
</chapter>
|
||||
|
||||
&chap.ipv6;
|
||||
|
||||
</part>
|
||||
|
||||
<part id="networkfs">
|
||||
<title>Network Filesystems</title>
|
||||
|
||||
<chapter id="afs">
|
||||
<title>AFS</title>
|
||||
|
||||
<para>AFS, NFS, SANs etc]</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="terminal">
|
||||
<title>Terminal Handling</title>
|
||||
|
||||
<chapter id="syscons">
|
||||
<title>Syscons</title>
|
||||
|
||||
<para>Syscons, tty, PCVT, serial console, screen savers,
|
||||
etc</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="sound">
|
||||
<title>Sound</title>
|
||||
|
||||
<chapter id="oss">
|
||||
<title>OSS</title>
|
||||
|
||||
<para>OSS, waveforms, etc</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="devicedrivers">
|
||||
<title>Device Drivers</title>
|
||||
|
||||
&chap.driverbasics;
|
||||
&chap.isa;
|
||||
&chap.pci;
|
||||
&chap.scsi;
|
||||
&chap.usb;
|
||||
|
||||
<chapter id="newbus">
|
||||
<title>NewBus</title>
|
||||
|
||||
<para>This chapter will talk about the FreeBSD NewBus
|
||||
architecture.</para>
|
||||
</chapter>
|
||||
|
||||
</part>
|
||||
|
||||
<part id="architectures">
|
||||
<title>Architectures</title>
|
||||
|
||||
&chap.x86;
|
||||
|
||||
<chapter id="alpha">
|
||||
<title>Alpha</title>
|
||||
|
||||
<para>Talk about the architectural specifics of
|
||||
FreeBSD/alpha.</para>
|
||||
|
||||
<para>Explanation of allignment errors, how to fix, how to
|
||||
ignore.</para>
|
||||
|
||||
<para>Example assembly language code for FreeBSD/alpha.</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="ia64">
|
||||
<title>IA-64</title>
|
||||
|
||||
<para>Talk about the architectural specifics of
|
||||
FreeBSD/ia64.</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="debuggingpart">
|
||||
<title>Debugging</title>
|
||||
|
||||
<chapter id="truss">
|
||||
<title>Truss</title>
|
||||
|
||||
<para>various descriptions on how to debug certain aspects of
|
||||
the system using truss, ktrace, gdb, kgdb, etc</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="compatibility">
|
||||
<title>Compatibility Layers</title>
|
||||
|
||||
<chapter id="linux">
|
||||
<title>Linux</title>
|
||||
|
||||
<para>Linux, SVR4, etc</para>
|
||||
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="appendices">
|
||||
<title>Appendices</title>
|
||||
|
||||
<bibliography>
|
||||
|
||||
<biblioentry id="COD" xreflabel="1">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Dave</firstname>
|
||||
<othername role="MI">A</othername>
|
||||
<surname>Patterson</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>John</firstname>
|
||||
<othername role="MI">L</othername>
|
||||
<surname>Hennessy</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright><year>1998</year><holder>Morgan Kaufmann Publishers,
|
||||
Inc.</holder></copyright>
|
||||
<isbn>1-55860-428-6</isbn>
|
||||
<publisher>
|
||||
<publishername>Morgan Kaufmann Publishers, Inc.</publishername>
|
||||
</publisher>
|
||||
<title>Computer Organization and Design</title>
|
||||
<subtitle>The Hardware / Software Interface</subtitle>
|
||||
<pagenums>1-2</pagenums>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="2">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>W.</firstname>
|
||||
<othername role="Middle">Richard</othername>
|
||||
<surname>Stevens</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright><year>1993</year><holder>Addison Wesley Longman,
|
||||
Inc.</holder></copyright>
|
||||
<isbn>0-201-56317-7</isbn>
|
||||
<publisher>
|
||||
<publishername>Addison Wesley Longman, Inc.</publishername>
|
||||
</publisher>
|
||||
<title>Advanced Programming in the Unix Environment</title>
|
||||
<pagenums>1-2</pagenums>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry xreflabel="3">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Marshall</firstname>
|
||||
<othername role="Middle">Kirk</othername>
|
||||
<surname>McKusick</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Keith</firstname>
|
||||
<surname>Bostic</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Michael</firstname>
|
||||
<othername role="MI">J</othername>
|
||||
<surname>Karels</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>John</firstname>
|
||||
<othername role="MI">S</othername>
|
||||
<surname>Quarterman</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright><year>1996</year><holder>Addison-Wesley Publishing Company,
|
||||
Inc.</holder></copyright>
|
||||
<isbn>0-201-54979-4</isbn>
|
||||
<publisher>
|
||||
<publishername>Addison-Wesley Publishing Company, Inc.</publishername>
|
||||
</publisher>
|
||||
<title>The Design and Implementation of the 4.4 BSD Operating System</title>
|
||||
<pagenums>1-2</pagenums>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="Phrack" xreflabel="4">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Aleph</firstname>
|
||||
<surname>One</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<title>Phrack 49; "Smashing the Stack for Fun and Profit"</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="StackGuard" xreflabel="5">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Chrispin</firstname>
|
||||
<surname>Cowan</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Calton</firstname>
|
||||
<surname>Pu</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Dave</firstname>
|
||||
<surname>Maier</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<title>StackGuard; Automatic Adaptive Detection and Prevention of
|
||||
Buffer-Overflow Attacks</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="OpenBSD" xreflabel="6">
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Todd</firstname>
|
||||
<surname>Miller</surname>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Theo</firstname>
|
||||
<surname>de Raadt</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<title>strlcpy and strlcat -- consistent, safe string copy and
|
||||
concatenation.</title>
|
||||
</biblioentry>
|
||||
|
||||
</bibliography>
|
||||
|
||||
</part>
|
||||
|
||||
</book>
|
||||
@ -1,61 +0,0 @@
|
||||
<!--
|
||||
Creates entities for each chapter in the FreeBSD Developer's
|
||||
Handbook. Each entity is named chap.foo, where foo is the value
|
||||
of the id attribute on that chapter, and corresponds to the name of
|
||||
the directory in which that chapter's .sgml file is stored.
|
||||
|
||||
Chapters should be listed in the order in which they are referenced.
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/chapters.ent,v 1.6 2001/05/11 10:20:33 murray Exp $
|
||||
-->
|
||||
|
||||
<!-- Part one -->
|
||||
<!-- No significant material yet, still in book.sgml -->
|
||||
|
||||
<!-- Part two -->
|
||||
<!ENTITY chap.tools SYSTEM "tools/chapter.sgml">
|
||||
<!ENTITY chap.secure SYSTEM "secure/chapter.sgml">
|
||||
|
||||
<!-- Part three -->
|
||||
<!ENTITY chap.locking SYSTEM "locking/chapter.sgml">
|
||||
|
||||
<!-- Part four -->
|
||||
<!ENTITY chap.vm SYSTEM "vm/chapter.sgml">
|
||||
<!ENTITY chap.dma SYSTEM "dma/chapter.sgml">
|
||||
|
||||
<!-- Part five -->
|
||||
<!-- No significant material yet, still in book.sgml -->
|
||||
|
||||
<!-- Part six -->
|
||||
<!-- No significant material yet, still in book.sgml -->
|
||||
|
||||
<!-- Part seven -->
|
||||
<!ENTITY chap.ipv6 SYSTEM "ipv6/chapter.sgml">
|
||||
|
||||
<!-- Part eight -->
|
||||
<!-- No significant material yet, still in book.sgml -->
|
||||
|
||||
<!-- Part nine -->
|
||||
<!-- No significant material yet, still in book.sgml -->
|
||||
|
||||
<!-- Part ten -->
|
||||
<!-- No significant material yet, still in book.sgml -->
|
||||
|
||||
<!-- Part eleven -->
|
||||
<!ENTITY chap.driverbasics SYSTEM "driverbasics/chapter.sgml">
|
||||
<!ENTITY chap.isa SYSTEM "isa/chapter.sgml">
|
||||
<!ENTITY chap.pci SYSTEM "pci/chapter.sgml">
|
||||
<!ENTITY chap.scsi SYSTEM "scsi/chapter.sgml">
|
||||
<!ENTITY chap.usb SYSTEM "usb/chapter.sgml">
|
||||
|
||||
<!-- Part twelve -->
|
||||
<!ENTITY chap.x86 SYSTEM "x86/chapter.sgml">
|
||||
|
||||
<!-- Part thirteen -->
|
||||
<!-- No significant material yet, still in book.sgml -->
|
||||
|
||||
<!-- Part fourteen -->
|
||||
<!-- No significant material yet, still in book.sgml -->
|
||||
|
||||
<!-- Part fifteen (appendices) -->
|
||||
<!ENTITY chap.bibliography SYSTEM "bibliography/chapter.sgml">
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,379 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/driverbasics/chapter.sgml,v 1.5 2001/04/09 08:42:04 murray Exp $
|
||||
-->
|
||||
|
||||
<chapter id="driverbasics">
|
||||
<title>Writing FreeBSD Device Drivers</title>
|
||||
|
||||
<para>This chapter was written by &a.murray; with selections from a
|
||||
variety of sources including the intro(4) man page by
|
||||
&a.joerg;.</para>
|
||||
|
||||
<sect1>
|
||||
<title>Introduction</title>
|
||||
<para>This chapter provides a brief introduction to writing device
|
||||
drivers for FreeBSD. A device in this context is a term used
|
||||
mostly for hardware-related stuff that belongs to the system,
|
||||
like disks, printers, or a graphics display with its keyboard.
|
||||
A device driver is the software component of the operating
|
||||
system that controls a specific device. There are also
|
||||
so-called pseudo-devices where a device driver emulates the
|
||||
behaviour of a device in software without any particular
|
||||
underlying hardware. Device drivers can be compiled into the
|
||||
system statically or loaded on demand through the dynamic kernel
|
||||
linker facility `kld'.</para>
|
||||
|
||||
<para>Most devices in a Unix-like operating system are accessed
|
||||
through device-nodes, sometimes also called special files.
|
||||
These files are usually located under the directory
|
||||
<filename>/dev</filename> in the file system hierarchy. Until
|
||||
devfs is fully integrated into FreeBSD, each device node must be
|
||||
created statically and independent of the existence of the
|
||||
associated device driver. Most device nodes on the system are
|
||||
created by running <command>MAKEDEV</command>.</para>
|
||||
|
||||
<para>Device drivers can roughly be broken down into two
|
||||
categories; character and network device drivers.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Dynamic Kernel Linker Facility - KLD</title>
|
||||
|
||||
<para>The kld interface allows system administrators to
|
||||
dynamically add and remove functionality from a running system.
|
||||
This allows device driver writers to load their new changes into
|
||||
a running kernel without constantly rebooting to test
|
||||
changes.</para>
|
||||
|
||||
<para>The kld interface is used through the following
|
||||
administrator commands :
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><simpara><command>kldload</command> - loads a new kernel
|
||||
module</simpara></listitem>
|
||||
<listitem><simpara><command>kldunload</command> - unloads a kernel
|
||||
module</simpara></listitem>
|
||||
<listitem><simpara><command>kldstat</command> - lists the currently loadded
|
||||
modules</simpara></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>Skeleton Layout of a kernel module</para>
|
||||
|
||||
<programlisting>/*
|
||||
* KLD Skeleton
|
||||
* Inspired by Andrew Reiter's Daemonnews article
|
||||
*/
|
||||
|
||||
#include <sys/types.h>
|
||||
#include <sys/module.h>
|
||||
#include <sys/systm.h> /* uprintf */
|
||||
#include <sys/errno.h>
|
||||
#include <sys/param.h> /* defines used in kernel.h */
|
||||
#include <sys/kernel.h> /* types used in module initialization */
|
||||
|
||||
/*
|
||||
* Load handler that deals with the loading and unloading of a KLD.
|
||||
*/
|
||||
|
||||
static int
|
||||
skel_loader(struct module *m, int what, void *arg)
|
||||
{
|
||||
int err = 0;
|
||||
|
||||
switch (what) {
|
||||
case MOD_LOAD: /* kldload */
|
||||
uprintf("Skeleton KLD loaded.\n");
|
||||
break;
|
||||
case MOD_UNLOAD:
|
||||
uprintf("Skeleton KLD unloaded.\n");
|
||||
break;
|
||||
default:
|
||||
err = EINVAL;
|
||||
break;
|
||||
}
|
||||
return(err);
|
||||
}
|
||||
|
||||
/* Declare this module to the rest of the kernel */
|
||||
|
||||
DECLARE_MODULE(skeleton, skel_loader, SI_SUB_KLD, SI_ORDER_ANY);</programlisting>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Makefile</title>
|
||||
|
||||
<para>FreeBSD provides a makefile include that you can use to
|
||||
quickly compile your kernel addition.</para>
|
||||
|
||||
<programlisting>SRCS=skeleton.c
|
||||
KMOD=skeleton
|
||||
|
||||
.include <bsd.kmod.mk></programlisting>
|
||||
|
||||
<para>Simply running <command>make</command> with this makefile
|
||||
will create a file <filename>skeleton.ko</filename> that can
|
||||
be loaded into your system by typing :
|
||||
<screen> &prompt.root
|
||||
kldload -v ./skeleton.ko
|
||||
</screen>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Accessing a device driver</title>
|
||||
|
||||
<para>Unix provides a common set of system calls for user
|
||||
applications to use. The upper layers of the kernel dispatch
|
||||
these calls to the corresponding device driver when a user
|
||||
accesses a device node. The <command>/dev/MAKEDEV</command>
|
||||
script makes most of the device nodes for your system but if you
|
||||
are doing your own driver development it may be necessary to
|
||||
create your own device nodes with <command>mknod</command>
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>Creating static device nodes</title>
|
||||
|
||||
<para>The <command>mknod</command> command requires four
|
||||
arguments to create a device node. You must specify the name
|
||||
of this device node, the type of device, the major number of
|
||||
the device, and the minor number of the device.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Dynamic device nodes</title>
|
||||
|
||||
<para>The device filesystem, or devfs, provides access to the
|
||||
kernel's device namespace in the global filesystem namespace.
|
||||
This eliminates the problems of potentially having a device
|
||||
driver without a static device node, or a device node without
|
||||
an installed device driver. Devfs is still a work in
|
||||
progress, but it is already working quite nice.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Character Devices</title>
|
||||
|
||||
<para>A character device driver is one that transfers data
|
||||
directly to and from a user process. This is the most common
|
||||
type of device driver and there are plenty of simple examples in
|
||||
the source tree.</para>
|
||||
|
||||
<para>This simple example pseudo-device remembers whatever values
|
||||
you write to it and can then supply them back to you when you
|
||||
read from it.</para>
|
||||
|
||||
<programlisting>/*
|
||||
* Simple `echo' pseudo-device KLD
|
||||
*
|
||||
* Murray Stokely
|
||||
*/
|
||||
|
||||
#define MIN(a,b) (((a) < (b)) ? (a) : (b))
|
||||
|
||||
#include <sys/types.h>
|
||||
#include <sys/module.h>
|
||||
#include <sys/systm.h> /* uprintf */
|
||||
#include <sys/errno.h>
|
||||
#include <sys/param.h> /* defines used in kernel.h */
|
||||
#include <sys/kernel.h> /* types used in module initialization */
|
||||
#include <sys/conf.h> /* cdevsw struct */
|
||||
#include <sys/uio.h> /* uio struct */
|
||||
#include <sys/malloc.h>
|
||||
|
||||
#define BUFFERSIZE 256
|
||||
|
||||
/* Function prototypes */
|
||||
d_open_t echo_open;
|
||||
d_close_t echo_close;
|
||||
d_read_t echo_read;
|
||||
d_write_t echo_write;
|
||||
|
||||
/* Character device entry points */
|
||||
static struct cdevsw echo_cdevsw = {
|
||||
echo_open,
|
||||
echo_close,
|
||||
echo_read,
|
||||
echo_write,
|
||||
noioctl,
|
||||
nopoll,
|
||||
nommap,
|
||||
nostrategy,
|
||||
"echo",
|
||||
33, /* reserved for lkms - /usr/src/sys/conf/majors */
|
||||
nodump,
|
||||
nopsize,
|
||||
D_TTY,
|
||||
-1
|
||||
};
|
||||
|
||||
typedef struct s_echo {
|
||||
char msg[BUFFERSIZE];
|
||||
int len;
|
||||
} t_echo;
|
||||
|
||||
/* vars */
|
||||
static dev_t sdev;
|
||||
static int len;
|
||||
static int count;
|
||||
static t_echo *echomsg;
|
||||
|
||||
MALLOC_DECLARE(M_ECHOBUF);
|
||||
MALLOC_DEFINE(M_ECHOBUF, "echobuffer", "buffer for echo module");
|
||||
|
||||
/*
|
||||
* This function acts is called by the kld[un]load(2) system calls to
|
||||
* determine what actions to take when a module is loaded or unloaded.
|
||||
*/
|
||||
|
||||
static int
|
||||
echo_loader(struct module *m, int what, void *arg)
|
||||
{
|
||||
int err = 0;
|
||||
|
||||
switch (what) {
|
||||
case MOD_LOAD: /* kldload */
|
||||
sdev = make_dev(<literal>&</literal>echo_cdevsw,
|
||||
0,
|
||||
UID_ROOT,
|
||||
GID_WHEEL,
|
||||
0600,
|
||||
"echo");
|
||||
/* kmalloc memory for use by this driver */
|
||||
/* malloc(256,M_ECHOBUF,M_WAITOK); */
|
||||
MALLOC(echomsg, t_echo *, sizeof(t_echo), M_ECHOBUF, M_WAITOK);
|
||||
printf("Echo device loaded.\n");
|
||||
break;
|
||||
case MOD_UNLOAD:
|
||||
destroy_dev(sdev);
|
||||
FREE(echomsg,M_ECHOBUF);
|
||||
printf("Echo device unloaded.\n");
|
||||
break;
|
||||
default:
|
||||
err = EINVAL;
|
||||
break;
|
||||
}
|
||||
return(err);
|
||||
}
|
||||
|
||||
int
|
||||
echo_open(dev_t dev, int oflags, int devtype, struct proc *p)
|
||||
{
|
||||
int err = 0;
|
||||
|
||||
uprintf("Opened device \"echo\" successfully.\n");
|
||||
return(err);
|
||||
}
|
||||
|
||||
int
|
||||
echo_close(dev_t dev, int fflag, int devtype, struct proc *p)
|
||||
{
|
||||
uprintf("Closing device \"echo.\"\n");
|
||||
return(0);
|
||||
}
|
||||
|
||||
/*
|
||||
* The read function just takes the buf that was saved via
|
||||
* echo_write() and returns it to userland for accessing.
|
||||
* uio(9)
|
||||
*/
|
||||
|
||||
int
|
||||
echo_read(dev_t dev, struct uio *uio, int ioflag)
|
||||
{
|
||||
int err = 0;
|
||||
int amt;
|
||||
|
||||
/* How big is this read operation? Either as big as the user wants,
|
||||
or as big as the remaining data */
|
||||
amt = MIN(uio->uio_resid, (echomsg->len - uio->uio_offset > 0) ? echomsg->len - uio->uio_offset : 0);
|
||||
if ((err = uiomove(echomsg->msg + uio->uio_offset,amt,uio)) != 0) {
|
||||
uprintf("uiomove failed!\n");
|
||||
}
|
||||
|
||||
return err;
|
||||
}
|
||||
|
||||
/*
|
||||
* echo_write takes in a character string and saves it
|
||||
* to buf for later accessing.
|
||||
*/
|
||||
|
||||
int
|
||||
echo_write(dev_t dev, struct uio *uio, int ioflag)
|
||||
{
|
||||
int err = 0;
|
||||
|
||||
/* Copy the string in from user memory to kernel memory */
|
||||
err = copyin(uio->uio_iov->iov_base, echomsg->msg, MIN(uio->uio_iov->iov_len,BUFFERSIZE));
|
||||
|
||||
/* Now we need to null terminate */
|
||||
*(echomsg->msg + MIN(uio->uio_iov->iov_len,BUFFERSIZE)) = 0;
|
||||
/* Record the length */
|
||||
echomsg->len = MIN(uio->uio_iov->iov_len,BUFFERSIZE);
|
||||
|
||||
if (err != 0) {
|
||||
uprintf("Write failed: bad address!\n");
|
||||
}
|
||||
|
||||
count++;
|
||||
return(err);
|
||||
}
|
||||
|
||||
DEV_MODULE(echo,echo_loader,NULL);</programlisting>
|
||||
|
||||
<para>To install this driver you will first need to make a node on
|
||||
your filesystem with a command such as : </para>
|
||||
|
||||
<screen>
|
||||
&prompt.root mknod /dev/echo c 33 0
|
||||
</screen>
|
||||
|
||||
<para>With this driver loaded you should now be able to type
|
||||
something like :</para>
|
||||
|
||||
<screen>
|
||||
&prompt.root echo -n "Test Data" > /dev/echo
|
||||
&prompt.root cat /dev/echo
|
||||
Test Data
|
||||
</screen>
|
||||
|
||||
<para>Real hardware devices in the next chapter..</para>
|
||||
|
||||
<para>Additional Resources
|
||||
<itemizedlist>
|
||||
<listitem><simpara><ulink
|
||||
url="http://www.daemonnews.org/200010/blueprints.html">Dynamic
|
||||
Kernel Linker (KLD) Facility Programming Tutorial</ulink> -
|
||||
<ulink url="http://www.daemonnews.org">Daemonnews</ulink> October 2000</simpara></listitem>
|
||||
<listitem><simpara><ulink
|
||||
url="http://www.daemonnews.org/200007/newbus-intro.html">How
|
||||
to Write Kernel Drivers with NEWBUS</ulink> - <ulink
|
||||
url="http://www.daemonnews.org">Daemonnews</ulink> July
|
||||
2000</simpara></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Network Drivers</title>
|
||||
|
||||
<para>Drivers for network devices do not use device nodes in order
|
||||
to be accessed. Their selection is based on other decisions
|
||||
made inside the kernel and instead of calling open(), use of a
|
||||
network device is generally introduced by using the system call
|
||||
socket(2).</para>
|
||||
|
||||
<para>man ifnet(), loopback device, Bill Paul's drivers,
|
||||
etc..</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,333 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
The FreeBSD SMP Next Generation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/locking/chapter.sgml,v 1.1 2000/11/29 04:15:17 jhb Exp $
|
||||
-->
|
||||
|
||||
<chapter id="locking">
|
||||
<title>Locking Notes</title>
|
||||
|
||||
<para><emphasis>This chapter is maintained by the FreeBSD SMP Next
|
||||
Generation Project
|
||||
<email>freebsd-smp@FreeBSD.org</email>.</emphasis></para>
|
||||
|
||||
|
||||
<para>This document outlines the locking used in the FreeBSD kernel
|
||||
to permit effective multi-processing within the kernel. Locking
|
||||
can be achieved via several means. Data structures can be
|
||||
protected by mutexes or &man.lockmgr.9; locks. A few variables
|
||||
are protected simply by always using atomic operations to access
|
||||
them.</para>
|
||||
|
||||
<sect1>
|
||||
<title>Mutexes</title>
|
||||
|
||||
<para>A mutex is simply a lock used to guarantee mutual exclusion.
|
||||
Specifically, a mutex may only be owned by one entity at a time.
|
||||
If another entity wishes to obtain a mutex that is already
|
||||
owned, it must wait until the mutex is released. In the FreeBSD
|
||||
kernel, mutexes are owned by processes.</para>
|
||||
|
||||
<para>Mutexes may be recursively acquired, but they are intended
|
||||
to be held for a short period of time. Specifically, one may
|
||||
not sleep while holding a mutex. If you need to hold a lock
|
||||
across a sleep, use a &man.lockmgr.9; lock.</para>
|
||||
|
||||
<para>Each mutex has several properties of interest:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Variable Name</term>
|
||||
<listitem>
|
||||
<para>The name of the <type>struct mtx</type> variable in
|
||||
the kernel source.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Logical Name</term>
|
||||
<listitem>
|
||||
<para>The name of the mutex assigned to it by
|
||||
<function>mtx_init</function>. This name is displayed in
|
||||
KTR trace messages and witness errors and warnings and is
|
||||
used to distinguish mutexes in the witness code.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Type</term>
|
||||
<listitem>
|
||||
<para>The type of the mutex in terms of the
|
||||
<constant>MTX_*</constant> flags. The meaning for each
|
||||
flag is related to its meaning as documented in
|
||||
&man.mutex.9;.</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><constant>MTX_DEF</constant></term>
|
||||
<listitem>
|
||||
<para>A sleep mutex</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><constant>MTX_SPIN</constant></term>
|
||||
<listitem>
|
||||
<para>A spin mutex</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><constant>MTX_COLD</constant></term>
|
||||
<listitem>
|
||||
<para>This mutex is initialized very early. Thus, it
|
||||
must be declared via
|
||||
<function>MUTEX_DECLARE</function>, and the
|
||||
<constant>MTX_COLD</constant> flag must be passed to
|
||||
<function>mtx_init</function>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><constant>MTX_TOPHALF</constant></term>
|
||||
<listitem>
|
||||
<para>This spin mutex does not disable
|
||||
interrupts.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><constant>MTX_NORECURSE</constant></term>
|
||||
<listitem>
|
||||
<para>This mutex is not allowed to recurse.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Protectees</term>
|
||||
<listitem>
|
||||
<para>A list of data structures or data structure members
|
||||
that this entry protects. For data structure members, the
|
||||
name will be in the form of
|
||||
<structname/structure name/.<structfield/member name/.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Dependent Functions</term>
|
||||
<listitem>
|
||||
<para>Functions that can only be called if this mutex is
|
||||
held.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<table frame="all" colsep="1" rowsep="1" pgwide="1">
|
||||
<title>Mutex List</title>
|
||||
|
||||
<tgroup cols="5">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Variable Name</entry>
|
||||
<entry>Logical Name</entry>
|
||||
<entry>Type</entry>
|
||||
<entry>Protectees</entry>
|
||||
<entry>Dependent Functions</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<!-- The scheduler lock -->
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>sched_lock</entry>
|
||||
<entry><quote>sched lock</quote></entry>
|
||||
<entry>
|
||||
<constant>MTX_SPIN</constant> |
|
||||
<constant>MTX_COLD</constant>
|
||||
</entry>
|
||||
<entry>
|
||||
<varname>_gmonparam</varname>,
|
||||
<varname>cnt.v_swtch</varname>,
|
||||
<varname>cp_time</varname>,
|
||||
<varname>curpriority</varname>,
|
||||
<structname/mtx/.<structfield/mtx_blocked/,
|
||||
<structname/mtx/.<structfield/mtx_contested/,
|
||||
<structname/proc/.<structfield/p_contested/,
|
||||
<structname/proc/.<structfield/p_blocked/,
|
||||
<structname/proc/.<structfield/p_flag/
|
||||
(<constant>P_PROFIL</constant> XXX,
|
||||
<constant>P_INMEM</constant>,
|
||||
<constant>P_SINTR</constant>,
|
||||
<constant>P_TIMEOUT</constant>,
|
||||
<constant>P_SWAPINREQ</constant> XXX,
|
||||
<constant>P_INMEN</constant> XXX),
|
||||
<structname/proc/.<structfield/p_nice/,
|
||||
<structname/proc/.<structfield/p_procq/,
|
||||
<structname/proc/.<structfield/p_blocked/,
|
||||
<structname/proc/.<structfield/p_estcpu/,
|
||||
<structname/proc/.<structfield/p_nativepri/,
|
||||
<structname/proc/.<structfield/p_priority/,
|
||||
<structname/proc/.<structfield/p_usrpri/,
|
||||
<structname/proc/.<structfield/p_rtprio/,
|
||||
<structname/proc/.<structfield/p_rqindex/,
|
||||
<structname/proc/.<structfield/p_stats->p_prof/,
|
||||
<structname/proc/.<structfield/p_stats->p_ru/,
|
||||
<structname/proc/.<structfield/p_stat/,
|
||||
<structname/proc/.<structfield/p_cpticks/
|
||||
<structname/proc/.<structfield/p_iticks/,
|
||||
<structname/proc/.<structfield/p_uticks/,
|
||||
<structname/proc/.<structfield/p_sticks/,
|
||||
<structname/proc/.<structfield/p_swtime/,
|
||||
<structname/proc/.<structfield/p_slptime/,
|
||||
<structname/proc/.<structfield/p_runtime/,
|
||||
<structname/proc/.<structfield/p_pctcpu/,
|
||||
<structname/proc/.<structfield/p_oncpu/,
|
||||
<structname/proc/.<structfield/p_asleep/,
|
||||
<structname/proc/.<structfield/p_wchan/,
|
||||
<structname/proc/.<structfield/p_wmesg/,
|
||||
<structname/proc/.<structfield/p_slpq/,
|
||||
<structname/proc/.<structfield/p_vmspace/
|
||||
(XXX - in <function>statclock</function>),
|
||||
<varname>pscnt</varname>,
|
||||
<varname>slpque</varname>,
|
||||
<varname>itqueuebits</varname>,
|
||||
<varname>itqueues</varname>,
|
||||
<varname>rtqueuebits</varname>,
|
||||
<varname>rtqueues</varname>,
|
||||
<varname>queuebits</varname>,
|
||||
<varname>queues</varname>,
|
||||
<varname>idqueuebits</varname>,
|
||||
<varname>idqueues</varname>,
|
||||
<varname>switchtime</varname>,
|
||||
</entry>
|
||||
<entry>
|
||||
<function>setrunqueue</function>,
|
||||
<function>remrunqueue</function>,
|
||||
<function>mi_switch</function>,
|
||||
<function>chooseproc</function>,
|
||||
<function>schedclock</function>,
|
||||
<function>resetpriority</function>,
|
||||
<function>updatepri</function>,
|
||||
<function>maybe_resched</function>,
|
||||
<function>cpu_switch</function>,
|
||||
<function>cpu_throw</function>
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
<!-- The vm86 pcb lock -->
|
||||
<row>
|
||||
<entry>vm86pcb_lock</entry>
|
||||
<entry><quote>vm86pcb lock</quote></entry>
|
||||
<entry>
|
||||
<constant>MTX_DEF</constant> |
|
||||
<constant>MTX_COLD</constant>
|
||||
</entry>
|
||||
<entry>
|
||||
<varname>vm86pcb</varname>
|
||||
</entry>
|
||||
<entry>
|
||||
<function>vm86_bioscall</function>
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
<!-- Giant -->
|
||||
<row>
|
||||
<entry>Giant</entry>
|
||||
<entry><quote>Giant</quote></entry>
|
||||
<entry>
|
||||
<constant>MTX_DEF</constant> |
|
||||
<constant>MTX_COLD</constant>
|
||||
</entry>
|
||||
<entry>nearly everything</entry>
|
||||
<entry>lots</entry>
|
||||
</row>
|
||||
|
||||
<!-- The callout lock -->
|
||||
<row>
|
||||
<entry>callout_lock</entry>
|
||||
<entry><quote>callout lock</quote></entry>
|
||||
<entry>
|
||||
<constant>MTX_SPIN</constant>
|
||||
</entry>
|
||||
<entry>
|
||||
<varname>callfree</varname>,
|
||||
<varname>callwheel</varname>,
|
||||
<varname>nextsoftcheck</varname>,
|
||||
<structname/proc/.<structfield/p_itcallout/,
|
||||
<structname/proc/.<structfield/p_slpcallout/,
|
||||
<varname>softticks</varname>,
|
||||
<varname>ticks</varname>
|
||||
</entry>
|
||||
<entry>
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Lock Manager Locks</title>
|
||||
|
||||
<para>Locks that are provided via the &man.lockmgr.9; interface
|
||||
are lock manager locks. These locks are reader-writer locks and
|
||||
may be held by a sleeping process.</para>
|
||||
|
||||
<table>
|
||||
<title>&man.lockmgr.9; Lock List</title>
|
||||
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Variable Name</entry>
|
||||
<entry>Protectees</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><varname>allproc_lock</varname></entry>
|
||||
<entry>
|
||||
<varname>allproc</varname>
|
||||
<varname>zombproc</varname>
|
||||
<varname>pidhashtbl</varname>
|
||||
<structname/proc/.<structfield/p_list/
|
||||
<structname/proc/.<structfield/p_hash/
|
||||
<varname>nextpid</varname>
|
||||
</entry>
|
||||
<entry><varname>proctree_lock</varname></entry>
|
||||
<entry>
|
||||
<structname/proc/.<structfield/p_children/
|
||||
<structname/proc/.<structfield/p_sibling/
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Atomically Protected Variables</title>
|
||||
|
||||
<para>An atomically protected variable is a special variable that
|
||||
is not protected by an explicit lock. Instead, all data
|
||||
accesses to the variables use special atomic operations as
|
||||
described in &man.atomic.9;. Very few variables are treated
|
||||
this way, although other synchronization primitives such as
|
||||
mutexes are implemented with atomically protected
|
||||
variables.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><varname>astpending</varname></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><structname/mtx/.<structfield/mtx_lock/</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
</chapter>
|
||||
@ -1,372 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/pci/chapter.sgml,v 1.2 2001/04/09 00:33:42 dd Exp $
|
||||
-->
|
||||
|
||||
<chapter id="pci">
|
||||
<title>PCI Devices</title>
|
||||
|
||||
<para>This chapter will talk about the FreeBSD mechanisms for
|
||||
writing a device driver for a device on a PCI bus.</para>
|
||||
|
||||
<sect1>
|
||||
<title>Probe and Attach</title>
|
||||
|
||||
<para>Information here about how the PCI bus code iterates through
|
||||
the unattached devices and see if a newly loaded kld will attach
|
||||
to any of them.</para>
|
||||
|
||||
<programlisting>/*
|
||||
* Simple KLD to play with the PCI functions.
|
||||
*
|
||||
* Murray Stokely
|
||||
*/
|
||||
|
||||
#define MIN(a,b) (((a) < (b)) ? (a) : (b))
|
||||
|
||||
#include <sys/types.h>
|
||||
#include <sys/module.h>
|
||||
#include <sys/systm.h> /* uprintf */
|
||||
#include <sys/errno.h>
|
||||
#include <sys/param.h> /* defines used in kernel.h */
|
||||
#include <sys/kernel.h> /* types used in module initialization */
|
||||
#include <sys/conf.h> /* cdevsw struct */
|
||||
#include <sys/uio.h> /* uio struct */
|
||||
#include <sys/malloc.h>
|
||||
#include <sys/bus.h> /* structs, prototypes for pci bus stuff */
|
||||
|
||||
#include <pci/pcivar.h> /* For get_pci macros! */
|
||||
|
||||
/* Function prototypes */
|
||||
d_open_t mypci_open;
|
||||
d_close_t mypci_close;
|
||||
d_read_t mypci_read;
|
||||
d_write_t mypci_write;
|
||||
|
||||
/* Character device entry points */
|
||||
|
||||
static struct cdevsw mypci_cdevsw = {
|
||||
mypci_open,
|
||||
mypci_close,
|
||||
mypci_read,
|
||||
mypci_write,
|
||||
noioctl,
|
||||
nopoll,
|
||||
nommap,
|
||||
nostrategy,
|
||||
"mypci",
|
||||
36, /* reserved for lkms - /usr/src/sys/conf/majors */
|
||||
nodump,
|
||||
nopsize,
|
||||
D_TTY,
|
||||
-1
|
||||
};
|
||||
|
||||
/* vars */
|
||||
static dev_t sdev;
|
||||
|
||||
/* We're more interested in probe/attach than with
|
||||
open/close/read/write at this point */
|
||||
|
||||
int
|
||||
mypci_open(dev_t dev, int oflags, int devtype, struct proc *p)
|
||||
{
|
||||
int err = 0;
|
||||
|
||||
uprintf("Opened device \"mypci\" successfully.\n");
|
||||
return(err);
|
||||
}
|
||||
|
||||
int
|
||||
mypci_close(dev_t dev, int fflag, int devtype, struct proc *p)
|
||||
{
|
||||
int err=0;
|
||||
|
||||
uprintf("Closing device \"mypci.\"\n");
|
||||
return(err);
|
||||
}
|
||||
|
||||
int
|
||||
mypci_read(dev_t dev, struct uio *uio, int ioflag)
|
||||
{
|
||||
int err = 0;
|
||||
|
||||
uprintf("mypci read!\n");
|
||||
return err;
|
||||
}
|
||||
|
||||
int
|
||||
mypci_write(dev_t dev, struct uio *uio, int ioflag)
|
||||
{
|
||||
int err = 0;
|
||||
|
||||
uprintf("mypci write!\n");
|
||||
return(err);
|
||||
}
|
||||
|
||||
/* PCI Support Functions */
|
||||
|
||||
/*
|
||||
* Return identification string if this is device is ours.
|
||||
*/
|
||||
static int
|
||||
mypci_probe(device_t dev)
|
||||
{
|
||||
uprintf("MyPCI Probe\n"
|
||||
"Vendor ID : 0x%x\n"
|
||||
"Device ID : 0x%x\n",pci_get_vendor(dev),pci_get_device(dev));
|
||||
|
||||
if (pci_get_vendor(dev) == 0x11c1) {
|
||||
uprintf("We've got the Winmodem, probe successful!\n");
|
||||
return 0;
|
||||
}
|
||||
|
||||
return ENXIO;
|
||||
}
|
||||
|
||||
/* Attach function is only called if the probe is successful */
|
||||
|
||||
static int
|
||||
mypci_attach(device_t dev)
|
||||
{
|
||||
uprintf("MyPCI Attach for : deviceID : 0x%x\n",pci_get_vendor(dev));
|
||||
sdev = make_dev(<literal>&</literal>mypci_cdevsw,
|
||||
0,
|
||||
UID_ROOT,
|
||||
GID_WHEEL,
|
||||
0600,
|
||||
"mypci");
|
||||
uprintf("Mypci device loaded.\n");
|
||||
return ENXIO;
|
||||
}
|
||||
|
||||
/* Detach device. */
|
||||
|
||||
static int
|
||||
mypci_detach(device_t dev)
|
||||
{
|
||||
uprintf("Mypci detach!\n");
|
||||
return 0;
|
||||
}
|
||||
|
||||
/* Called during system shutdown after sync. */
|
||||
|
||||
static int
|
||||
mypci_shutdown(device_t dev)
|
||||
{
|
||||
uprintf("Mypci shutdown!\n");
|
||||
return 0;
|
||||
}
|
||||
|
||||
/*
|
||||
* Device suspend routine.
|
||||
*/
|
||||
static int
|
||||
mypci_suspend(device_t dev)
|
||||
{
|
||||
uprintf("Mypci suspend!\n");
|
||||
return 0;
|
||||
}
|
||||
|
||||
/*
|
||||
* Device resume routine.
|
||||
*/
|
||||
|
||||
static int
|
||||
mypci_resume(device_t dev)
|
||||
{
|
||||
uprintf("Mypci resume!\n");
|
||||
return 0;
|
||||
}
|
||||
|
||||
static device_method_t mypci_methods[] = {
|
||||
/* Device interface */
|
||||
DEVMETHOD(device_probe, mypci_probe),
|
||||
DEVMETHOD(device_attach, mypci_attach),
|
||||
DEVMETHOD(device_detach, mypci_detach),
|
||||
DEVMETHOD(device_shutdown, mypci_shutdown),
|
||||
DEVMETHOD(device_suspend, mypci_suspend),
|
||||
DEVMETHOD(device_resume, mypci_resume),
|
||||
|
||||
{ 0, 0 }
|
||||
};
|
||||
|
||||
static driver_t mypci_driver = {
|
||||
"mypci",
|
||||
mypci_methods,
|
||||
0,
|
||||
/* sizeof(struct mypci_softc), */
|
||||
};
|
||||
|
||||
static devclass_t mypci_devclass;
|
||||
|
||||
DRIVER_MODULE(mypci, pci, mypci_driver, mypci_devclass, 0, 0);</programlisting>
|
||||
|
||||
<para>Additional Resources
|
||||
<itemizedlist>
|
||||
<listitem><simpara><ulink url="http://www.pcisig.org">PCI
|
||||
Special Interest Group</ulink></simpara></listitem>
|
||||
|
||||
<listitem><simpara>PCI System Architecture, Fourth Edition by
|
||||
Tom Shanley, et al.</simpara></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Bus Resources</title>
|
||||
|
||||
<para>FreeBSD provides an object-oriented mechanism for requesting
|
||||
resources from a parent bus. Almost all devices will be a child
|
||||
member of some sort of bus (PCI, ISA, USB, SCSI, etc) and these
|
||||
devices need to acquire resources from their parent bus (such as
|
||||
memory segments, interrupt lines, or DMA channels).</para>
|
||||
|
||||
<sect2>
|
||||
<title>Base Address Registers</title>
|
||||
|
||||
<para>To do anything particularly useful with a PCI device you
|
||||
will need to obtain the <emphasis>Base Address
|
||||
Registers</emphasis> (BARs) from the PCI Configuration space.
|
||||
The PCI-specific details of obtaining the BAR is abstracted in
|
||||
the <function>bus_alloc_resource()</function> function.</para>
|
||||
|
||||
<para>For example, a typical driver might have something similar
|
||||
to this in the <function>attach()</function> function. : </para>
|
||||
|
||||
<programlisting> sc->bar0id = 0x10;
|
||||
sc->bar0res = bus_alloc_resource(dev, SYS_RES_MEMORY, &(sc->bar0id),
|
||||
0, ~0, 1, RF_ACTIVE);
|
||||
if (sc->bar0res == NULL) {
|
||||
uprintf("Memory allocation of PCI base register 0 failed!\n");
|
||||
error = ENXIO;
|
||||
goto fail1;
|
||||
}
|
||||
|
||||
sc->bar1id = 0x14;
|
||||
sc->bar1res = bus_alloc_resource(dev, SYS_RES_MEMORY, &(sc->bar1id),
|
||||
0, ~0, 1, RF_ACTIVE);
|
||||
if (sc->bar1res == NULL) {
|
||||
uprintf("Memory allocation of PCI base register 1 failed!\n");
|
||||
error = ENXIO;
|
||||
goto fail2;
|
||||
}
|
||||
sc->bar0_bt = rman_get_bustag(sc->bar0res);
|
||||
sc->bar0_bh = rman_get_bushandle(sc->bar0res);
|
||||
sc->bar1_bt = rman_get_bustag(sc->bar1res);
|
||||
sc->bar1_bh = rman_get_bushandle(sc->bar1res);
|
||||
|
||||
</programlisting>
|
||||
|
||||
<para>Handles for each base address register are kept in the
|
||||
<structname>softc</structname> structure so that they can be
|
||||
used to write to the device later.</para>
|
||||
|
||||
<para>These handles can then be used to read or write from the
|
||||
device registers with the <function>bus_space_*</function>
|
||||
functions. For example, a driver might contain a shorthand
|
||||
function to read from a board specific register like this :
|
||||
</para>
|
||||
|
||||
<programlisting>uint16_t
|
||||
board_read(struct ni_softc *sc, uint16_t address) {
|
||||
return bus_space_read_2(sc->bar1_bt, sc->bar1_bh, address);
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>Similarly, one could write to the registers with : </para>
|
||||
|
||||
<programlisting>void
|
||||
board_write(struct ni_softc *sc, uint16_t address, uint16_t value) {
|
||||
bus_space_write_2(sc->bar1_bt, sc->bar1_bh, address, value);
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>These functions exist in 8bit, 16bit, and 32bit versions
|
||||
and you should use
|
||||
<function>bus_space_{read|write}_{1|2|4}</function>
|
||||
accordingly.</para>
|
||||
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Interrupts</title>
|
||||
|
||||
<para>Interrupts are allocated from the object-oriented bus code
|
||||
in a way similar to the memory resources. First an IRQ
|
||||
resource must be allocated from the parent bus, and then the
|
||||
interrupt handler must be setup to deal with this IRQ.</para>
|
||||
|
||||
<para>Again, a sample from a device
|
||||
<function>attach()</function> function says more than
|
||||
words.</para>
|
||||
|
||||
<programlisting>/* Get the IRQ resource */
|
||||
|
||||
sc->irqid = 0x0;
|
||||
sc->irqres = bus_alloc_resource(dev, SYS_RES_IRQ, &(sc->irqid),
|
||||
0, ~0, 1, RF_SHAREABLE | RF_ACTIVE);
|
||||
if (sc->irqres == NULL) {
|
||||
uprintf("IRQ allocation failed!\n");
|
||||
error = ENXIO;
|
||||
goto fail3;
|
||||
}
|
||||
|
||||
/* Now we should setup the interrupt handler */
|
||||
|
||||
error = bus_setup_intr(dev, sc->irqres, INTR_TYPE_MISC,
|
||||
my_handler, sc, &(sc->handler));
|
||||
if (error) {
|
||||
printf("Couldn't set up irq\n");
|
||||
goto fail4;
|
||||
}
|
||||
|
||||
sc->irq_bt = rman_get_bustag(sc->irqres);
|
||||
sc->irq_bh = rman_get_bushandle(sc->irqres);
|
||||
</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>DMA</title>
|
||||
<para>On the PC, peripherals that want to do bus-mastering DMA
|
||||
must deal with physical addresses. This is a problem since
|
||||
FreeBSD uses virtual memory and deals almost exclusively with
|
||||
virtual addresses. Fortunately, there is a function,
|
||||
<function>vtophys()</function> to help.</para>
|
||||
|
||||
<programlisting>#include <vm/vm.h>
|
||||
#include <vm/pmap.h>
|
||||
|
||||
#define vtophys(virtual_address) (...)
|
||||
</programlisting>
|
||||
|
||||
<para>The solution is a bit different on the alpha however, and
|
||||
what we really want is a function called
|
||||
<function>vtobus()</function>.</para>
|
||||
|
||||
<programlisting>#if defined(__alpha__)
|
||||
#define vtobus(va) alpha_XXX_dmamap((vm_offset_t)va)
|
||||
#else
|
||||
#define vtobus(va) vtophys(va)
|
||||
#endif
|
||||
</programlisting>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Deallocating Resources</title>
|
||||
|
||||
<para>It's very important to deallocate all of the resources
|
||||
that were allocated during <function>attach()</function>.
|
||||
Care must be taken to deallocate the correct stuff even on a
|
||||
failure condition so that the system will remain useable while
|
||||
your driver dies.</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,513 +0,0 @@
|
||||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/developers-handbook/secure/chapter.sgml,v 1.6 2001/06/02 23:24:10 dd Exp $
|
||||
-->
|
||||
|
||||
<chapter id="secure">
|
||||
<title>Secure Programming</title>
|
||||
|
||||
<para>This chapter was written by &a.murray;.</para>
|
||||
|
||||
<sect1><title>Synopsis</title>
|
||||
|
||||
<para>This chapter describes some of the security issues that
|
||||
have plagued Unix programmers for decades and some of the new
|
||||
tools available to help programmers avoid writing exploitable
|
||||
code.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="secure-philosophy"><title>Secure Design
|
||||
Methodology</title>
|
||||
|
||||
<para>Writing secure applications takes a very scrutinous and
|
||||
pessimistic outlook on life. Applications should be run with
|
||||
the principle of <quote>least privilege</quote> so that no
|
||||
process is ever running with more than the bare minimum access
|
||||
that it needs to accomplish its function. Previously tested
|
||||
code should be reused whenever possible to avoid common
|
||||
mistakes that others may have already fixed.</para>
|
||||
|
||||
<para>One of the pitfalls of the Unix environment is how easy it
|
||||
is to make assumptions about the sanity of the environment.
|
||||
Applications should never trust user input (in all its forms),
|
||||
system resources, inter-process communication, or the timing of
|
||||
events. Unix processes do not execute synchronously so logical
|
||||
operations are rarely atomic.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Buffer Overflows</title>
|
||||
|
||||
<para>Buffer Overflows have been around since the very
|
||||
beginnings of the Von-Neuman <xref linkend="COD"> architecture.
|
||||
|
||||
<indexterm><primary>buffer overflow</primary></indexterm>
|
||||
<indexterm><primary>Von-Neuman</primary></indexterm>
|
||||
|
||||
They first gained widespread notoriety in 1988 with the Morris
|
||||
Internet worm. Unfortunately, the same basic attack remains
|
||||
|
||||
<indexterm><primary>Morris Internet worm</primary></indexterm>
|
||||
|
||||
effective today. Of the 17 CERT security advisories of 1999, 10
|
||||
|
||||
<indexterm>
|
||||
<primary>CERT</primary><secondary>security advisories</secondary>
|
||||
</indexterm>
|
||||
|
||||
of them were directly caused by buffer-overflow software bugs.
|
||||
By far the most common type of buffer overflow attack is based
|
||||
on corrupting the stack.</para>
|
||||
|
||||
<indexterm><primary>stack</primary></indexterm>
|
||||
<indexterm><primary>arguments</primary></indexterm>
|
||||
|
||||
<para>Most modern computer systems use a stack to pass arguments
|
||||
to procedures and to store local variables. A stack is a last
|
||||
in first out (LIFO) buffer in the high memory area of a process
|
||||
image. When a program invokes a function a new "stack frame" is
|
||||
|
||||
<indexterm><primary>LIFO</primary></indexterm>
|
||||
<indexterm>
|
||||
<primary>process image</primary>
|
||||
<secondary>stack pointer</secondary>
|
||||
</indexterm>
|
||||
|
||||
created. This stack frame consists of the arguments passed to
|
||||
the function as well as a dynamic amount of local variable
|
||||
space. The "stack pointer" is a register that holds the current
|
||||
|
||||
<indexterm><primary>stack frame</primary></indexterm>
|
||||
<indexterm><primary>stack pointer</primary></indexterm>
|
||||
|
||||
location of the top of the stack. Since this value is
|
||||
constantly changing as new values are pushed onto the top of the
|
||||
stack, many implementations also provide a "frame pointer" that
|
||||
is located near the beginning of a stack frame so that local
|
||||
variables can more easily be addressed relative to this
|
||||
value. <xref linkend="COD"> The return address for function
|
||||
|
||||
<indexterm><primary>frame pointer</primary></indexterm>
|
||||
<indexterm>
|
||||
<primary>process image</primary>
|
||||
<secondary>frame pointer</secondary>
|
||||
</indexterm>
|
||||
<indexterm><primary>return address</primary></indexterm>
|
||||
<indexterm><primary>stack-overflow</primary></indexterm>
|
||||
|
||||
calls is also stored on the stack, and this is the cause of
|
||||
stack-overflow exploits since overflowing a local variable in a
|
||||
function can overwrite the return address of that function,
|
||||
potentially allowing a malicious user to execute any code he or
|
||||
she wants.</para>
|
||||
|
||||
<para>Although stack-based attacks are by far the most common,
|
||||
it would also be possible to overrun the stack with a heap-based
|
||||
(malloc/free) attack.</para>
|
||||
|
||||
<para>The C programming language does not perform automatic
|
||||
bounds checking on arrays or pointers as many other languages
|
||||
do. In addition, the standard C library is filled with a
|
||||
handful of very dangerous functions.</para>
|
||||
|
||||
<informaltable>
|
||||
<tgroup cols=2>
|
||||
<tbody>
|
||||
<row><entry><function>strcpy</function>(char *dest, const char
|
||||
*src)</entry>
|
||||
<entry><simpara>May overflow the dest buffer</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row><entry><function>strcat</function>(char *dest, const char
|
||||
*src)</entry>
|
||||
<entry><simpara>May overflow the dest buffer</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row><entry><function>getwd</function>(char *buf)</entry>
|
||||
<entry><simpara>May overflow the buf buffer</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row><entry><function>gets</function>(char *s)</entry>
|
||||
<entry><simpara>May overflow the s buffer</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row><entry><function>[vf]scanf</function>(const char *format,
|
||||
...)</entry>
|
||||
<entry><simpara>May overflow its arguments.</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row><entry><function>realpath</function>(char *path, char
|
||||
resolved_path[])</entry>
|
||||
<entry><simpara>May overflow the path buffer</simpara></entry>
|
||||
</row>
|
||||
|
||||
<row><entry><function>[v]sprintf</function>(char *str, const char
|
||||
*format, ...)</entry>
|
||||
<entry><simpara>May overflow the str buffer.</simpara></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<sect2><title>Example Buffer Overflow</title>
|
||||
|
||||
<para>The following example code contains a buffer overflow
|
||||
designed to overwrite the return address and skip the
|
||||
instruction immediately following the function call. (Inspired
|
||||
by <xref linkend="Phrack">)</para>
|
||||
|
||||
<programlisting>#include <sgmltag>stdio.h</sgmltag>
|
||||
|
||||
void manipulate(char *buffer) {
|
||||
char newbuffer[80];
|
||||
strcpy(newbuffer,buffer);
|
||||
}
|
||||
|
||||
int main() {
|
||||
char ch,buffer[4096];
|
||||
int i=0;
|
||||
|
||||
while ((buffer[i++] = getchar()) != '\n') {};
|
||||
|
||||
i=1;
|
||||
manipulate(buffer);
|
||||
i=2;
|
||||
printf("The value of i is : %d\n",i);
|
||||
return 0;
|
||||
}</programlisting>
|
||||
|
||||
<para>Let us examine what the memory image of this process would
|
||||
look like if we were to input 160 spaces into our little program
|
||||
before hitting return.</para>
|
||||
|
||||
<para>[XXX figure here!]</para>
|
||||
|
||||
<para>Obviously more malicious input can be devised to execute
|
||||
actual compiled instructions (such as exec(/bin/sh)).</para>
|
||||
</sect2>
|
||||
|
||||
<sect2><title>Avoiding Buffer Overflows</title>
|
||||
|
||||
<para>The most straightforward solution to the problem of
|
||||
stack-overflows is to always use length restricted memory and
|
||||
string copy functions. <function>strncpy</function> and
|
||||
<function>strncat</function> are part of the standard C library.
|
||||
|
||||
<indexterm>
|
||||
<primary>string copy functions</primary>
|
||||
<secondary>strncpy</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>string copy functions</primary>
|
||||
<secondary>strncat</secondary>
|
||||
</indexterm>
|
||||
|
||||
These functions accept a length value as a parameter which
|
||||
should be no larger than the size of the destination buffer.
|
||||
These functions will then copy up to `length' bytes from the
|
||||
source to the destination. However there are a number of
|
||||
problems with these functions. Neither function guarantees NUL
|
||||
termination if the size of the input buffer is as large as the
|
||||
|
||||
<indexterm><primary>NUL termination</primary></indexterm>
|
||||
|
||||
destination. The length parameter is also used inconsistently
|
||||
between strncpy and strncat so it is easy for programmers to get
|
||||
confused as to their proper usage. There is also a significant
|
||||
performance loss compared to <function>strcpy</function> when
|
||||
copying a short string into a large buffer since
|
||||
<function>strncpy</function> NUL fills up the the size
|
||||
specified.</para>
|
||||
|
||||
<para>In OpenBSD, another memory copy implementation has been
|
||||
|
||||
<indexterm><primary>OpenBSD</primary></indexterm>
|
||||
|
||||
created to get around these problem. The
|
||||
<function>strlcpy</function> and <function>strlcat</function>
|
||||
functions guarantee that they will always null terminate the
|
||||
destination string when given a non-zero length argument. For
|
||||
more information about these functions see <xref
|
||||
linkend="OpenBSD">. The OpenBSD <function>strlcpy</function> and
|
||||
<function>strlcat</function> instructions have been in FreeBSD
|
||||
since 3.3.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>string copy functions</primary>
|
||||
<secondary>strlcpy</secondary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<primary>string copy functions</primary>
|
||||
<secondary>strlcat</secondary>
|
||||
</indexterm>
|
||||
|
||||
<sect3><title>Compiler based run-time bounds checking</title>
|
||||
|
||||
<indexterm><primary>bounds checking</primary>
|
||||
<secondary>compiler-based</secondary></indexterm>
|
||||
|
||||
<para>Unfortunately there is still a very large assortment of
|
||||
code in public use which blindly copies memory around without
|
||||
using any of the bounded copy routines we just discussed.
|
||||
Fortunately, there is another solution. Several compiler
|
||||
add-ons and libraries exist to do Run-time bounds checking in
|
||||
C/C++.</para>
|
||||
|
||||
<indexterm><primary>StackGuard</primary></indexterm>
|
||||
<indexterm><primary>gcc</primary></indexterm>
|
||||
|
||||
<para>StackGuard is one such add-on that is implemented as a
|
||||
small patch to the gcc code generator. From the StackGuard
|
||||
website, http://immunix.org/stackguard.html :
|
||||
<blockquote><para>"StackGuard detects and defeats stack
|
||||
smashing attacks by protecting the return address on the stack
|
||||
from being altered. StackGuard places a "canary" word next to
|
||||
the return address when a function is called. If the canary
|
||||
word has been altered when the function returns, then a stack
|
||||
smashing attack has been attempted, and the program responds
|
||||
by emitting an intruder alert into syslog, and then
|
||||
halts."</para></blockquote>
|
||||
|
||||
<blockquote><para>"StackGuard is implemented as a small patch
|
||||
to the gcc code generator, specifically the function_prolog()
|
||||
and function_epilog() routines. function_prolog() has been
|
||||
enhanced to lay down canaries on the stack when functions
|
||||
start, and function_epilog() checks canary integrity when the
|
||||
function exits. Any attempt at corrupting the return address
|
||||
is thus detected before the function
|
||||
returns."</para></blockquote>
|
||||
</para>
|
||||
|
||||
<indexterm><primary>buffer overflow</primary></indexterm>
|
||||
|
||||
<para>Recompiling your application with StackGuard is an
|
||||
effective means of stopping most buffer-overflow attacks, but
|
||||
it can still be compromised.</para>
|
||||
|
||||
</sect3>
|
||||
|
||||
<sect3><title>Library based run-time bounds checking</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>bounds checking</primary>
|
||||
<secondary>library-based</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Compiler-based mechanisms are completely useless for
|
||||
binary-only software for which you cannot recompile. For
|
||||
these situations there are a number of libraries which
|
||||
re-implement the unsafe functions of the C-library
|
||||
(<function>strcpy</function>, <function>fscanf</function>,
|
||||
<function>getwd</function>, etc..) and ensure that these
|
||||
functions can never write past the stack pointer.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><simpara>libsafe</simpara></listitem>
|
||||
<listitem><simpara>libverify</simpara></listitem>
|
||||
<listitem><simpara>libparnoia</simpara></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Unfortunately these library-based defenses have a number
|
||||
of shortcomings. These libraries only protect against a very
|
||||
small set of security related issues and they neglect to fix
|
||||
the actual problem. These defenses may fail if the
|
||||
application was compiled with -fomit-frame-pointer. Also, the
|
||||
LD_PRELOAD and LD_LIBRARY_PATH environment variables can be
|
||||
overwritten/unset by the user.</para>
|
||||
</sect3>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1><title>SetUID issues</title>
|
||||
|
||||
<indexterm><primary>seteuid</primary></indexterm>
|
||||
|
||||
<para>There are at least 6 different IDs associated with any
|
||||
given process. Because of this you have to be very careful with
|
||||
the access that your process has at any given time. In
|
||||
particular, all seteuid applications should give up their
|
||||
privileges as soon as it is no longer required.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>user IDs</primary>
|
||||
<secondary>real user ID</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>user IDs</primary>
|
||||
<secondary>effective user ID</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The real user ID can only be changed by a superuser
|
||||
process. The <application>login</application> program sets this
|
||||
when a user initially logs in and it is seldom changed.</para>
|
||||
|
||||
<para>The effective user ID is set by the
|
||||
<function>exec()</function> functions if a program has its
|
||||
seteuid bit set. An application can call
|
||||
<function>seteuid()</function> at any time to set the effective
|
||||
user ID to either the real user ID or the saved set-user-ID.
|
||||
When the effective user ID is set by <function>exec()</function>
|
||||
functions, the previous value is saved in the saved set-user-ID.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="chroot"><title>Limiting your program's environment</title>
|
||||
|
||||
<indexterm><primary>chroot()</primary></indexterm>
|
||||
|
||||
<para>The traditional method of restricting a process
|
||||
is with the <function>chroot()</function> system call. This
|
||||
system call changes the root directory from which all other
|
||||
paths are referenced for a process and any child processes. For
|
||||
this call to succeed the process must have execute (search)
|
||||
permission on the directory being referenced. The new
|
||||
environment does not actually take effect until you
|
||||
<function>chdir()</function> into your new environment. It
|
||||
should also be noted that a process can easily break out of a
|
||||
chroot environment if it has root privilege. This could be
|
||||
accomplished by creating device nodes to read kernel memory,
|
||||
attaching a debugger to a process outside of the jail, or in
|
||||
many other creative ways.</para>
|
||||
|
||||
<para>The behavior of the <function>chroot()</function> system
|
||||
call can be controlled somewhat with the
|
||||
kern.chroot_allow_open_directories <command>sysctl</command>
|
||||
variable. When this value is set to 0,
|
||||
<function>chroot()</function> will fail with EPERM if there are
|
||||
any directories open. If set to the default value of 1, then
|
||||
<function>chroot()</function> will fail with EPERM if there are
|
||||
any directories open and the process is already subject to a
|
||||
<function>chroot()</function> call. For any other value, the
|
||||
check for open directories will be bypassed completely.</para>
|
||||
|
||||
<sect2><title>FreeBSD's jail functionality</title>
|
||||
|
||||
<indexterm><primary>jail</primary></indexterm>
|
||||
|
||||
<para>The concept of a Jail extends upon the
|
||||
<function>chroot()</function> by limiting the powers of the
|
||||
superuser to create a true `virtual server'. Once a prison is
|
||||
setup all network communication must take place through the
|
||||
specified IP address, and the power of "root privilege" in this
|
||||
jail is severely constrained.</para>
|
||||
|
||||
<para>While in a prison, any tests of superuser power within the
|
||||
kernel using the <function>suser()</function> call will fail.
|
||||
However, some calls to <function>suser()</function> have been
|
||||
changed to a new interface <function>suser_xxx()</function>.
|
||||
This function is responsible for recognizing or denying access
|
||||
to superuser power for imprisoned processes.</para>
|
||||
|
||||
<para>A superuser process within a jailed environment has the
|
||||
power to : </para>
|
||||
<itemizedlist>
|
||||
<listitem><simpara>Manipulate credential with
|
||||
<function>setuid</function>, <function>seteuid</function>,
|
||||
<function>setgid</function>, <function>setegid</function>,
|
||||
<function>setgroups</function>, <function>setreuid</function>,
|
||||
<function>setregid</function>, <function>setlogin</function></simpara></listitem>
|
||||
<listitem><simpara>Set resource limits with <function>setrlimit</function></simpara></listitem>
|
||||
<listitem><simpara>Modify some sysctl nodes
|
||||
(kern.hostname)</simpara></listitem>
|
||||
<listitem><simpara><function>chroot()</function></simpara></listitem>
|
||||
<listitem><simpara>Set flags on a vnode:
|
||||
<function>chflags</function>,
|
||||
<function>fchflags</function></simpara></listitem>
|
||||
<listitem><simpara>Set attributes of a vnode such as file
|
||||
permission, owner, group, size, access time, and modification
|
||||
time.</simpara></listitem>
|
||||
<listitem><simpara>Bind to privileged ports in the Internet
|
||||
domain (ports < 1024)</simpara></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><function>Jail</function> is a very useful tool for
|
||||
running applications in a secure environment but it does have
|
||||
some shortcomings. Currently, the IPC mechanisms have not been
|
||||
converted to the <function>suser_xxx</function> so applications
|
||||
such as MySQL can not be run within a jail. Superuser access
|
||||
may have a very limited meaning within a jail, but there is
|
||||
no way to specify exactly what "very limited" means.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2><title>POSIX.1e Process Capabilities</title>
|
||||
|
||||
<indexterm><primary>POSIX.1e Process Capabilities</primary></indexterm>
|
||||
<indexterm><primary>TrustedBSD</primary></indexterm>
|
||||
|
||||
<para>Posix has released a working draft that adds event
|
||||
auditing, access control lists, fine grained privileges,
|
||||
information labeling, and mandatory access control.</para>
|
||||
<para>This is a work in progress and is the focus of the <ulink
|
||||
url="http://www.trustedbsd.org">TrustedBSD</ulink> project. Some
|
||||
of the initial work has been committed to FreeBSD-current
|
||||
(cap_set_proc(3)).</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Trust</title>
|
||||
|
||||
<para>An application should never assume that anything about the
|
||||
users environment is sane. This includes (but is certainly not
|
||||
limited to) : user input, signals, environment variables,
|
||||
resources, IPC, mmaps, the file system working directory, file
|
||||
descriptors, the # of open files, etc.</para>
|
||||
|
||||
<indexterm><primary>positive filtering</primary></indexterm>
|
||||
<indexterm><primary>data validation</primary></indexterm>
|
||||
|
||||
<para>You should never assume that you can catch all forms of
|
||||
invalid input that a user might supply. Instead, your
|
||||
application should use positive filtering to only allow a
|
||||
specific subset of inputs that you deem safe. Improper data
|
||||
validation has been the cause of many exploits, especially with
|
||||
CGI scripts on the world wide web. For filenames you need to be
|
||||
extra careful about paths ("../", "/"), symbolic links, and
|
||||
shell escape characters.</para>
|
||||
|
||||
<indexterm><primary>Perl Taint mode</primary></indexterm>
|
||||
|
||||
<para>Perl has a really cool feature called "Taint" mode which
|
||||
can be used to prevent scripts for using data derived outside
|
||||
the program in an unsafe way. This mode will check command line
|
||||
arguments, environment variables, locale information, the
|
||||
results of certain syscalls (<function>readdir()</function>,
|
||||
<function>readlink()</function>,
|
||||
<function>getpwxxx()</function>, and all file input.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Race Conditions</title>
|
||||
|
||||
<para>A race condition is anomalous behavior caused by the
|
||||
unexpected dependence on the relative timing of events. In
|
||||
other words, a programmer incorrectly assumed that a particular
|
||||
event would always happen before another.</para>
|
||||
|
||||
<indexterm><primary>race conditions</primary>
|
||||
<secondary>signals</secondary></indexterm>
|
||||
|
||||
<indexterm><primary>race conditions</primary>
|
||||
<secondary>access checks</secondary></indexterm>
|
||||
|
||||
<indexterm><primary>race conditions</primary>
|
||||
<secondary>file opens</secondary></indexterm>
|
||||
|
||||
<para>Some of the common causes of race conditions are signals,
|
||||
access checks, and file opens. Signals are asynchronous events
|
||||
by nature so special care must be taken in dealing with them.
|
||||
Checking access with <function>access(2)</function> then
|
||||
<function>open(2)</function> is clearly non-atomic. Users can
|
||||
move files in between the two calls. Instead, privileged
|
||||
applications should <function>seteuid()</function> and then call
|
||||
<function>open()</function> directly. Along the same lines, an
|
||||
application should always set a proper umask before
|
||||
<function>open()</function> to obviate the need for spurious
|
||||
<function>chmod()</function> calls.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue