diff --git a/de_DE.ISO8859-1/htdocs/releases/index.xml b/de_DE.ISO8859-1/htdocs/releases/index.xml index 9588eb6fdc..baa7e07ee4 100644 --- a/de_DE.ISO8859-1/htdocs/releases/index.xml +++ b/de_DE.ISO8859-1/htdocs/releases/index.xml @@ -1,431 +1,434 @@ - + ]> &title; $FreeBSD$

Es gibt 2 Arten von &os;-Versionen: "Produktion" sowie "Produktion (alt)". Die ersteren sind am besten für Anwender geeignet, die stets über die neuesten Funktionen verfügen wollen, während die letzteren sich an Anwender richten, die eine konservativere Updatestrategie verfolgen.

Zusätzlich wird unterschieden, wie lange diese Versionen vom Security Officer mit Sicherheitsupdates versorgt werden. Hier unterscheiden wir zwischen Versionen mit "normaler" und "erweiterter" Unterstützung.

Ausführliche Unterlagen im HTML-Format zu allen &os;-Versionen finden Sie auf der Seite Release Documentation.

Derzeit unterstützte Versionen

Alle Informationen zu derzeit unterstützten Versionen (Datum der Veröffentlichung, Versionsart, Ende der Unterstützung mit Sicherheitsupdates) finden Sie im Abschnitt Unterstützte FreeBSD-Versionen auf der Seite FreeBSD Sicherheit.

Aktuelle Version(en)

Produktion

Release &rel.current; (Dezember 2012) Announcement : Release Notes : Installation Instructions Hardware Notes : Readme : Errata

-

Release &rel2.current; (Februar 2011) +

Produktion (alt)

+ +

Release &rel2.current; (Juni 2013) Announcement : Release Notes : Installation Instructions : Hardware Notes : Readme : Errata

-

Produktion (alt)

- -

Release &rel3.current; (Februar 2011) - - Announcement : - Release Notes : - Hardware Notes : - Readme : - Errata -

-

Zukünftige Versionen

Den Zeitplan für zukünftige &os;-Versionen sowie ausführliche Informationen über die Vorgehensweise bei der Veröffentlichung einer neuen FreeBSD-Version finden Sie auf der englischen Seite Release Engineering.

Die aktuellen Snapshots von FreeBSD-STABLE und FreeBSD-CURRENT sind ebenfalls verfügbar. Weitere Informationen finden Sie unter FreeBSD Bezugsquellen.

Alte, nicht mehr unterstützte Versionen (End-of-Life-Versionen)

Alle Informationen zu diesen Versionen, darunter Datum der Veröffentlichung, Versionsart, Ende der Unterstützung mit Sicherheitsupdates (End-of-Life-Datum) finden Sie im Abschnitt Unterstützte FreeBSD-Versionen auf der Seite FreeBSD Sicherheit.

diff --git a/de_DE.ISO8859-1/htdocs/where.xml b/de_DE.ISO8859-1/htdocs/where.xml index 010f8b84c5..61a9a4d655 100644 --- a/de_DE.ISO8859-1/htdocs/where.xml +++ b/de_DE.ISO8859-1/htdocs/where.xml @@ -1,258 +1,265 @@ ]> &title; $FreeBSD$

Release Information

Detaillierte Beschreibung früherer, aktueller und künftiger Releases. Schauen Sie zuerst auf dieser Seite nach, wenn Sie die aktuelle FreeBSD-Version suchen.

FreeBSD installieren

FreeBSD kann von mehreren Medien installiert werden, beispielsweise von CD-ROM, DVD, Disketten, einer MS-DOS®-Partition, Bandlaufwerken, Anonymous-FTP und NFS. Bevor Sie FreeBSD herunterladen, lesen Sie bitte die Installationsanleitung.

FreeBSD kaufen

FreeBSD-CD-ROMs oder DVDs können bei FreeBSD Mall oder einem der anderen CD-ROM und DVD-Verleger erworben werden.

FreeBSD herunterladen

Wenn Sie FreeBSD über FTP oder HTTP beziehen wollen, suchen Sie in der Liste der FTP-Spiegelserver des Handbuchs einen Spiegelserver in Ihrer Nähe.

- + - +
Version & Plattform DistributionISOISO Release
Notes
Hardware
Notes
Installation
Notes
Errata
FreeBSD &rel.current;-RELEASE [Lesen] [Lesen] [Lesen] [Lesen]
amd64
(x86-64, x64)
[Distribution] [ISO]
i386 [Distribution] [ISO]
powerpc64 [Distribution] [ISO]
sparc64 [Distribution] [ISO]
FreeBSD &rel2.current;-RELEASE [Lesen] [Lesen] [Lesen] [Lesen]
amd64
(x86-64, x64)
[Distribution] [ISO]
i386 [Distribution] [ISO]
pc98 [Distribution] [ISO]

Hinweis: Wenn Sie nicht sicher sind, welche Plattform/Architektur Sie haben: Ist Ihr Rechner bereits mehrere Jahre alt, so brauchen Sie höchstwahrscheinlich die i386-Version. Ist hier Rechner hingegen aktueller, brauchen Sie vermutlich die amd64-Version.

&beta.desc;

Experimentelle Schnappschüsse von FreeBSD-CURRENT (&rel.head;-CURRENT) für Entwickler und Tester werden auf der Seite &os; Snapshot Releases zur Verfügung gestellt. Die Seite Release Information enthält Informationen über frühere, aktuelle und künftige Releases.

+ +

Alte (nicht mehr unterstützte) Versionen

+ +

Alte (nicht mehr unterstützte Versionen können vom + FTP-Archiv herunterladen werden.

+

Auf FreeBSD basierende Betriebssysteme

FreeBSD bildet die Basis für diverse kommerzielle oder als Open Source verfügbare Betriebssysteme. Die im Folgenden beschriebenen Systeme werden sehr häufig eingesetzt und sind für FreeBSD-Anwender besonders interessant.

Anwendungen und Werkzeuge

Die Ports-Sammlung

Die Ports-Sammlung enthält Anwendungen und Werkzeuge, die nach FreeBSD portiert wurden.

Wie Sie Ihre Lieblings-Software in die Ports-Sammlung integrieren, wird in Das FreeBSD Porter-Handbuch und in FreeBSD unterstützen beschrieben.

diff --git a/de_DE.ISO8859-1/share/xml/news.xml b/de_DE.ISO8859-1/share/xml/news.xml index cee060bc72..e69075e12d 100644 --- a/de_DE.ISO8859-1/share/xml/news.xml +++ b/de_DE.ISO8859-1/share/xml/news.xml @@ -1,2619 +1,2805 @@ $FreeBSD$ 2013 + + 8 + + + 6 + + + Halbjahres-Newsletter der &os; Foundation + verfügbar + +

Wir freuen uns, bekanntgeben zu dürfen, dass wir unseren + Newsletter für das erste Halbjahr 2013 veröffentlicht + haben. Lesen Sie den Newsletter, um sich darüber zu + informieren, wie die Foundation dabei hilft, &os; zum + besten verfügbaren Betriebssystem zu machen.

+ +

Informieren Sie sich über von uns gesponserte + Entwicklungsprojekte und Konferenzen sowie über + Entwickler- und Verkäufertreffen zur direkten + Kommunikation, über den Stand unserer Spendenkampagne + und vieles andere mehr.

+ +

Der Newsletter für das erste Halbjahr 2013 ist ab sofort + hier + verfügbar.

+
+
+ + + 5 + + + &os; 9.2-RC1 verfügbar + +

Der erste Release Candidate aus dem &os;-9.2-Releasezyklus ist + verfügbar. + ISO-Images für die Architekturen amd64, i386, ia64, powerpc, + powerpc64 sowie sparc64 sind inzwischen auf den meisten &os; + Spiegelservern vorhanden.

+
+
+
+ + + 7 + + + 29 + + + &os; 9.2-BETA2 verfügbar + +

Die zweite Betaversion aus dem &os;-9.2-Releasezyklus ist + verfügbar. + ISO-Images für die Architekturen amd64, i386, powerpc64 + sowie sparc64 sind inzwischen auf den meisten &os; + Spiegelservern vorhanden.

+
+
+ + + 22 + + + &os; 9.2-BETA1 verfügbar + +

Die erste Betaversion aus dem &os;-9.2-Releasezyklus ist + verfügbar. + ISO-Images für die Architekturen amd64, i386 sowie ia64 + sind inzwischen auf den meisten &os; + Spiegelservern vorhanden.

+
+
+ + + 16 + + + Statusreport April-Juni 2013 + +

Der Statusreport für die Monate April bis Juni 2013 mit + 33 Einträgen ist verfügbar.

+
+
+ + + 4 + + +

Neuer Committer: John Marino (ports)

+
+
+ + + 3 + + +

Neuer Committer: Luiz Otavio O Souza (src)

+
+
+ + + 2 + + + Bericht: BSDCan 2013 DevSummit + +

Ein Statusreport mit den Ergebnissen des BSDCan 2013 + &os; Developer Summits mit 6 Einträgen ist verfügbar.

+
+
+
+ 6 + + 25 + + +

Neuer Committer: Mark Felder (ports)

+
+
+ + + 19 + + + Happy Birthday &os;! + +

&os; ist seit heute 20 Jahre alt. + Am 19. Juni 1993 kündigten Jordan Hubbard, Rod Grimes sowie + and David Greenman die Entwicklung eines auf BSD 4.3 + basierenden Betriebssystems an.

+ +

&os; 1.0 basiert auf 386BSD 0.1 von Bill und Lynne Jolitz + und wurde im November 1993 veröffentlicht. Als Projektziel + wurde die Entwicklung eines schnellen, stabilen und + zuverlässigen Serverbetriebssystems für i386-Systeme + angegeben.

+ +

Seit damals hat sich &os; zur Basis von unzähligen Produkten + weiterentwickelt und unterstützt nun auch 64-Bit-Architekturen, + eingebundene Geräte sowie Desktopbenutzer.

+
+
+ + + 11 + + +

Neuer Committer: Veniamin Gvozdikov (ports)

+
+
+ + + 7 + + + &os; 8.4-RELEASE verfügbar + +

&os;  + 8.4-RELEASE ist verfügbar. Lesen Sie unbedingt + die Release Notes + (ausführliche + Version) sowie die Release Errata, + bevor Sie mit der Installation beginnen, um + sich über aktuelle Neuigkeiten und/oder eventuelle + Probleme im Umgang mit 8.4-RELEASE zu informieren. + Weitere Informationen zu verschiedenen FreeBSD-Versionen + finden Sie auf der Seite Release Information.

+
+
+ 4

Erweiterte Commit-Privilegien: Glen Barber (doc, ports, src)

5 27

Erweiterte Commit-Privilegien: Chris Rees (doc, ports)

14 Binärpakete wieder verfügbar

Sechs Monate sind seit dem Angriffsversuch auf die FreeBSD-Infrastruktur vergangen, als Folge dessen die Produktion von Binärpakete vorübergehend eingestellt werden musste. Wir freuen uns daher, bekanntgeben zu dürfen, dass nun alle Dienste (inklusive der Produktion von Binärpaketen) vollständig wiederhergestellt wurden.

Lesen Sie dazu bitte auch die offizielle Ankündigung.

12 Statusreport Januar - März 2013

Der Statusreport für die Monate Januar bis März 2013 mit 31 Einträgen ist ab sofort verfügbar.

9 &os; Foundation: Ed Maste ist neuer Director of Project Development

Die &os; Foundation freut sich, bekanntgeben zu dürfen, dass Ed Maste ab sofort in Teilzeit als Director of Project Development für die FreeBSD Foundation tätig ist. Ed war die zwei letzten Jahre im Vorstand der Foundation und hat den Vorstand verlassen, um seinen neuen Aufgabenbereich zu übernehmen.

Weitere Informationen zu dieser Neubesetzung finden Sie hier.

8 &os; 8.4-RC3 verfügbar

Der dritte Release Candidate aus dem &os;-8.4-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386 sowie pc98 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

4 29 Neuer technischer Mitarbeiter für die &os; Foundation: Edward Tomasz Napierała

Die &os; Foundation freut sich, bekanntgeben zu dürfen, dass mit Edward Tomasz Napierała ein weiterer technischer Mitarbeiter in Vollzeit für die Foundation tätig sein wird. Damit setzt die Foundation die für 2013 geplanten Investitionen in Personal fort.

Weitere Informationen hierzu finden Sie hier.

24

Neuer Committer: Alan Somers (src)

Das FreeBSD Project nimmt am Google Summer of Code 2013 teil

Das FreeBSD Project freut sich, bekanntgeben zu dürfen, das es auch dieses Jahr an Google's Summer of Code-Programm teilnimmt. Durch dieses Programm wird die Arbeit von Studenten im Rahmen von Open Source-Projekten gefördert. Das FreeBSD Project nimmt bereits zum neunten Mal hintereinander an diesem Programm teil und hat seit der ersten Teilnahme 2005 mehr als 150 Studenten erfolgreich durch deren Arbeiten begleitet.

Zu den erfolgreich abgeschlossenen Projekten gehören Verbesserungen an der Linux-ABI-Emulation, NFSv4 ACLs, TCP-Regressionstests, die Unterstützung für das FUSE-Dateisytem sowie zahlreiche andere Projekte. Viele Studenten, die an diesem Programm teilnahmen, sind inzwischen aktive FreeBSD-Entwickler und/oder nehmen (nicht zuletzt dank der Unterstützung der FreeBSD Foundation) weiterhin aktiv an verschiedenen FreeBSD-Veranstaltungen auf der ganzen Welt teil.

Wir laden alle Studenten ein, während des Sommers gegen Bezahlung an der Weiterentwicklung von &os; zu arbeiten! Weitere Informationen zu möglichen Projektvorschlägen sowie zum Ablauf finden sich auf der Seite FreeBSD Summer Projects.

22 &os; 8.4-RC2 verfügbar

Der zweite Release Candidate aus dem &os;-8.4-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386 sowie pc98 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

18

Erweiterte Commit-Privilegien: Cy Schubert (src, ports)

12

Neuer Committer: Hiren Panchasara (src)

10 &os; 8.4-RC1 verfügbar

Der erste Release Candidate aus dem &os;-8.4-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386 sowie pc98 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

3

Erweiterte Commit-Privilegien: Antoine Brodin (src, ports)

1

Neuer Committer: William Grzybowski (ports)

3 27

Erweiterte Commit-Privilegien: Tijl Coosemans (src, ports)

22 &os; 8.4-BETA1 verfügbar

Die erste BETA-Version aus dem &os;-8.4-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386 sowie pc98 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

14 Neuer technischer Mitarbeiter für die &os; Foundation: Konstantin Belousov

Die &os; Foundation freut sich, bekanntgeben zu dürfen, dass Konstantin Belousov als erster technischer Mitarbeiter in Vollzeit für die Foundation tätig sein wird. Dies ist ein wichtiger Meilenstein auf unserem Weg, FreeBSD auch 2013 zu unterstützen.

Weitere Informationen hierzu finden Sie hier.

12

Neues Mitglied im Ports Management Team: Bryan Drewery

3 Statusreport Oktober-Dezember 2012

Der Statusreport für die Monate Oktober bis Dezember 2012 mit 27 Einträgen ist verfügbar.

Statusreport Juli-September 2012

Der Statusreport für die Monate Juli bis September 2012 mit 12 Einträgen ist verfügbar.

2 10

Neuer Committer: Po-Chien Lin (ports)

1

Neuer Committer: Thomas-Martin Seck (ports)

1 23

Neuer Committer: Achim Leubner (src)

22

Neuer Committer: Dru Lavigne (doc)

16

Neuer Committer: Carl Delsey (src)

15

Erweiterte Commit-Privilegien: René Ladan (ports, full doc/www)

14

Neuer Committer: David Naylor (ports)

13 Statusreport April-Juni 2012

Der Statusreport für die Monate April bis Juni 2012 mit 17 Einträgen ist ab sofort verfügbar.

10 Ports-CVS: End-of-Life am 28. Februar 2013

Die Entwicklung von &os;-Ports erfolgt seit einiger Zeit ausschließlich in Subversion. Ab 28. Februar 2013 wird daher der &os;-Portsbaum nicht mehr nach CVS exportiert werden. Ab diesem Zeitpunkt wird es nicht mehr möglich sein, den Portsbaum via CVS, CVSup oder csup(1) zu aktualisieren. Anwendern, die diese Programme derzeit noch nutzen, wird empfohlen, künftig portsnap(8) einzusetzen. Alternativ können Sie Subversion auch direkt verwenden. Weitere Informationen zu diesem Thema finden sich in der offiziellen Ankündigung auf der Mailingliste freebsd-ports-announce.

Eine Anleitung zur Migration von CVSup oder csup(1) nach portsnap(8) finden Sie im &os;-Handbuch.

8 Faces of &os; ‐ Thomas Abthorpe

Wir freuen uns, Ihnen unsere nächste Geschichte aus der Reihe "Faces of &os;" präsentieren zu können. Diese Reihe erlaubt es uns zu zeigen, wie wir verschiedene Personen bei Ihrer Arbeit an/für &os; unterstützen. Diese Unterstützung besteht beispielsweise in der Finanzierung von Entwicklungsprojekten, der Organisation von Konferenzen, der Übernahme von Reisekosten sowie der allgemeinen Förderung von &os;.

Diesmal stellen wir Ihnen Thomas Abthorpe vor. Wir haben es ihm ermöglicht, an der BSDCan 2009, 2011 und 2012 teilzunehmen, indem wir uns an seinen Reisekosten beteiligt haben. Lesen Sie seine Geschichte hier.

7

Neuer Committer: Ian Lepore (src)

2012 12 31 &os; 9.1-RELEASE verfügbar

FreeBSD 9.1-RELEASE ist ab sofort verfügbar. Lesen Sie unbedingt die Release Notes (ausführliche Version) sowie die Release Errata, bevor Sie mit der Installation beginnen, um sich über aktuelle Neuigkeiten und/oder eventuelle Probleme im Umgang mit 9.1-RELEASE zu informieren. Weitere Informationen zu verschiedenen FreeBSD-Versionen finden Sie auf der Seite Release Information.

24

Neuer Committer: Kubilay Kocak (ports)

20 T&os; Foundation Newsletter Dezember 2012.

Die &os; Foundation hat ihren End-of-Year Newsletter für das Jahr 2012 veröffentlicht.

18

Neuer Committer: Mark Johnston (src)

PC-BSD 9.1 ist verfügbar

Das PC-BSD Team hat PC-BSD 9.1 veröffentlicht.

Neuer Committer: Steven Hartland (src)

17 Faces of &os; ‐ Dan Langille

Wir freuen uns, Ihnen unsere nächste Geschichte aus der Reihe "Faces of &os;" präsentieren zu können. Diese Reihe erlaubt es uns zu zeigen, wie wir verschiedene Personen bei Ihrer Arbeit an/für &os; unterstützen. Diese Unterstützung besteht beispielsweise in der Finanzierung von Entwicklungsprojekten, der Organisation von Konferenzen, der Übernahme von Reisekosten sowie der allgemeinen Förderung von &os;.

Diesmal stellen wir Ihnen Dan Langille vor. Wir unterstützen ihn seit 2006 durch das Sponsering der jährlichen BSDCan. Lesen Sie seine Geschichte hier.

12 Neuer Spendenrekord: Mehr als 650 neue Spenden über insgesamt $43.200 in nur 3 Tagen!

Aufmerksame Leser des Blogs der FreeBSD Foundation wissen, dass wir letzte Woche mit unserer jährlichen Spendenaktion begonnen haben, mit der wir in der Regel mehr als 50 Prozent aller Spenden erzielen. Weitere Informationen zu dieser Aktion finden Sie hier.

10 Faces of &os; ‐ Alberto Mijares

Wissen Sie, wie die &os; Foundation die &os;-Gemeinde im letzten Jahr unterstützt hat? Im Rahmen unserer jährlichen Spendenkampagne stellen wir Ihnen auf unserer Webseite, in unserem Blog sowie auf Facebook verschiedene Personen vor, die wir durch die Finanzierung von Entwicklungsprojekten, die Organisation von Konferenzen, die Übernahme von Reisekosten sowie die generelle Förderung von &os; unterstützt haben. Weitere Information finden Sie hier.

5 &os;-Spendenkampagne

Ihre Spenden haben uns dabei geholfen, &os; zum besten derzeit verfügbaren Betriebssystem zu machen. Indem Sie die &os; Foundation unterstützen, helfen Sie uns dabei, &os; als leistungsfähiges, sicheres und stabiles Betriebssystem weiterzuentwickeln.

Dank Personen wie Ihnen konnte die &os; Foundation das &os; Project sowie die &os;-Gemeinde in den letzten zwölf Jahren kontinuierlich unterstützen. Weitere Informationen zu unserer jährlichen Spendenkampagne finden Sie hier.

Die Webseite des &os; Projects verwendet ab sofort Google Analytics

Das &os; Project hat Google Analytics aktiviert, um anonymisierte Statistiken über die Nutzung der Webseiten zu erhalten. Weitere Informationen zu dieser Umstellung finden Sie in der offiziellen Ankündigung.

11 26

Neuer Committer: Takuya ASADA (src)

25

Neuer Committer: Barbara Guida (ports)

17 Angriffsversuch auf die FreeBSD-Infrastruktur

Am 11. November 2012 wurde ein unerlaubter Zugriff auf zwei Systeme innerhalb des FreeBSD.org-Clusters entdeckt. Wir konnten zwar keinen Hinweis darauf finden, dass Dateien manipuliert wurden, dennoch empfehlen wir allen Benutzern, den dazu erstellten Bericht zu lesen und selbst zu entscheiden, ob Handlungsbedarf besteht.

5

Neuer Committer: Bryan Venteicher (src)

4

Neuer Committer: Grzegorz Blach (ports)

3 &os; 9.1-RC3 verfügbar

Der dritte Release Candidate aus dem &os;-9.1-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386, sparc64 sowie powerpc64 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

10 24

Erweiterte Commit-Privilegien: Erwin Lansing (src, ports)

23

Neuer Committer: Simon J. Gerraty (src)

20

Erweiterte Commit-Privilegien: Eitan Adler (src, ports, doc)

19

Neues Mitglied im Ports Management Team: Bernhard Fröhlich

10 &os; 9.1-RC2 verfügbar

Der zweite Release Candidate aus dem &os;-9.1-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386, ia64, powerpc sowie powerpc64 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

9 15

Neuer Committer: Peter Jeremy (src)

13

Neuer Committer: Edson Brandi (doc/pt_BR, www/pt_BR)

10

Neuer Committer: Jason E. Hale (ports)

8 23 &os; 9.1-RC1 verfügbar

Der erste Release Candidate aus dem &os;-9.1-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386, powerpc64 sowie sparc64 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

21

Neuer Committer: Andrey Zonov (src)

1

Neuer Committer: Bryan Drewery (ports)

7 24 Neuer Core Team Secretary: <a href="mailto:pgj@FreeBSD.org">Gábor Páli</a>

Das &os; Core Team freut sich, bekanntgeben zu dürfen, dass Gábor Páli die Position des Core Team Secretary übernommen hat.

16 &os; 9.1-BETA1 verfügbar

Die erste Testversion aus dem &os;-9.1-Releasezyklus ist ab sofort verfügbar. ISO-Images für die Architekturen amd64, i386, powerpc64 sowie sparc64 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

11 Neues &os; Core Team gewählt

Das &os; Project freut sich, die Wahl des Core Teams 2012 bekanntgeben zu dürfen. Das &os; Core Team bildet den "Vorstand" des Projekts und ist für die Aufnahme neuer src-Committer, die Klärung von Meinungsverschiedenheiten unter den Committern, Politik und Verwaltung des Projekts sowie die Einrichtung von Unter-Komitees für verschiedene Aufgabenbereiche (Security Officer, Release Engineers, Port Managers, Webmasters und andere mehr) verantwortlich. Seit 2000 wird das Core Team alle zwei Jahre demokratisch durch die aktiven &os; Committer gewählt.

Weitere Informationen zur Wahl (sowie eine Liste der neuen Mitglieder des &os; Core Teams) finden Sie in der offiziellen Ankündigung.

3

Neuer Committer: Niclas Zeising (doc/www, ports)

6 19

Erweiterte Commit-Privilegien: Glen Barber (doc, ports)

4

Neuer Committer: Mateusz Guzik (src)

5 30

Neuer Committer: Jase Thew (ports)

29

Neuer Committer: Olivier Duchateau (ports)

28

Neuer Committer: Tom Judge (ports)

12 Statusreport Januar-März 2012

Der Statusreport für die Monate Januar bis März 2012 mit 27 Einträgen ist ab sofort verfügbar.

4 26

Neuer Committer: Isabell Long (doc/www)

22

Neuer Committer: Jeremie Le Hen (src)

18 &os; 8.3-RELEASE verfügbar

FreeBSD 8.3-RELEASE ist erschienen. Lesen Sie bitte die Release Notes und die Release Errata, bevor Sie mit der Installation beginnen, um sich über aktuelle Neuigkeiten und/oder eventuelle Probleme im Umgang mit 8.3-RELEASE zu informieren. Weitere Informationen zu verschiedenen FreeBSD-Versionen finden Sie auf der Seite Release Information.

Neuer Committer: Devin Teske (src)

15

Neuer Committer: Armin Pirkovitsch (ports)

13

Neuer Committer: Monthadar Al Jaberi (src)

12

Neuer Committer: Guido Falsi (ports)

2 &os; 8.3-RC2 Available

Der zweite Release Candidate aus dem &os;-8.3-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386 sowie pc98 sind inzwischen auf den meisten &os; Spiegelservern verfügbar.

3 23

Neuer Committer: Cherry G. Mathew (src)

12

Neuer Committer: Benjamin Kaduk (doc/www)

6 &os; 8.3-RC1 verfügbar

Der erste Release Candidate aus dem &os;-8.3-Releasezyklus ist verfügbar. ISO-Images für die Architekturen amd64, i386 sowie pc98 sind inzwischen auf den meisten &os; Spiegelservern verfügbar.

01

Neuer Committer: Alex Kozlov (ports)

2 20 &os; 8.3-BETA1 verfügbar

Die erste Testversion aus dem &os;-8.3-Releasezyklus ist ab sofort verfügbar. ISO-Images für die Plattformen amd64, i386 sowie pc98 sind inzwischen auf den meisten &os; Spiegelservern vorhanden.

16

Neuer Committer: Damjan Marion (src)

Neuer Committer: Ben Gray (src)

14

Erweiterte Commit-Privilegien: Sergey Kandaurov (src, doc)

7

Neuer Committer: Matthew Seaman (ports)

1 27

Neuer Committer: Davide Italiano (src)

Statusreport Oktober-Dezember 2011

Der Statusreport für die Monate Oktober bis Dezember 2011 mit 32 Einträgen ist ab sofort verfügbar.

12 &os; 9.0-RELEASE verfügbar

FreeBSD 9.0-RELEASE ist verfügbar. Lesen Sie bitte die Release Notes und die Release Errata, bevor Sie mit der Installation beginnen, um sich über aktuelle Neuigkeiten und/oder eventuelle Probleme im Umgang mit 9.0-RELEASE zu informieren. Weitere Informationen zu verschiedenen FreeBSD-Versionen finden Sie auf der Seite Release Information.

2011 12 16

Neuer Committer: Jason Helfman (ports)

9 &os; 9.0-RC3 verfügbar

Der dritte (und voraussichtlich letzte) Release Candidate aus dem &os;-9.0-Releasezyklus ist ab sofort verfügbar. ISO-Images für die Architekturen amd64, i386, ia64, powerpc, powerpc64 sowie sparc64 finden Sie wie immer auf unseren &os; Spiegelservern. Eine der zahlreichen neuen Funktionen in &os; 9.0 ist das neue Installationsprogramm. Wir bitten daher unser Nutzer, dieses zu testen, und eine Neuinstallation durchzuführen. Alternativ ist es aber auch möglich, ein System über freebsd-update(8) zu aktualisieren.

8

Neuer Committer: Pedro Giffuni (src)

2

Neues Mitglied im Ports Management Team: Beat Gätzi

11 30

Neuer Committer: Justin Hibbits (src)

17 &os; 9.0-RC2 verfügbar

Der zweite Release Candidate aus dem &os;-9.0-Releasezyklus ist ab sofort verfügbar. ISO-Images für die Architekturen amd64, i386, ia64, powerpc, powerpc64 sowie sparc64 finden Sie wie immer auf unseren &os; Spiegelservern. Eine der zahlreichen neuen Funktionen in &os; 9.0 ist das neue Installationsprogramm. Wir bitten daher unser Nutzer, dieses zu testen, und eine Neuinstallation durchzuführen. Alternativ ist es aber auch möglich, ein System über freebsd-update(8) zu aktualisieren.

12

Neuer Committer: Michael Scheidell (ports)

11

Neuer Committer: David Chisnall (src)

9

Neuer Committer: Ruslan Makhmatkhanov (ports)

8 Statusreport Juli-September 2011

Der Statusreport für die Monate Juli bis September 2011 mit 28 Einträgen ist ab sofort verfügbar.

10 23 &os; 9.0-RC1 verfügbar

Der erste Release Candidate aus dem &os;-9.0-Releasezyklus ist ab sofort verfügbar. ISO-Images für die Architekturen amd64, i386, ia64, powerpc, powerpc64 sowie sparc64 finden Sie wie immer auf unseren &os; Spiegelservern. Eine der zahlreichen neuen Funktionen in &os; 9.0 ist das neue Installationsprogramm. Wir bitten daher unser Nutzer, dieses zu testen, und eine Neuinstallation durchzuführen. Alternativ ist es aber auch möglich, ein System über freebsd-update(8) zu aktualisieren.

6

Neuer Committer: Alexander V. Chernikov (src)

9 28 &os; 9.0-BETA3 verfügbar

Die dritte BETA-Version aus dem &os;-9.0-Releasezyklus ist ab sofort verfügbar. ISO-Images für die Architekturen amd64, i386, ia64, powerpc, powerpc64 sowie sparc64 sind inzwischen auf den meisten &os; Spiegelservern vorhanden. Eine der zahlreichen neuen Funktionen in &os; 9.0 ist das neue Installationsprogramm. Wir bitten daher unser Nutzer, dieses zu testen, und eine Neuinstallation durchzuführen.

27

Neuer Committer: Jakub Klama (src)

19

Neuer Committer: Gleb Kurtsou (src)

18

Neuer Committer: Robert Millan (src)

14

Neuer Committer: Warren Block (doc/www)

Statusreport April-Juni 2011

Der Statusreport für die Monate April bis Juni 2011 mit 36 Einträgen ist ab sofort verfügbar.

13

Neuer Committer: Carlo Strub (ports)

7 &os; 9.0-BETA2 verfügbar

Die zweite BETA-Version aus dem &os;-9.0-Releasezyklus ist nun verfügbar. ISO-Images für die Architekturen amd64, i386, powerpc, powerpc64 sowie sparc64 sind inzwischen auf den meisten &os; Spiegelservern vorhanden. Eine der zahlreichen neuen Funktionen in &os; 9.0 ist das neue Installationsprogramm. Wir bitten daher unser Nutzer, dieses zu testen, und eine Neuinstallation durchzuführen.

8 22

Neuer Committer: Raphael Kubo da Costa (ports)

17

Neuer Committer: Eitan Adler (ports)

9 &os; Foundation Newsletter August 2011

Die &os; Foundation hat ihren ersten Newsletter für 2011 veröffentlicht, in dem sie beschreibt, wie sie das &os; Project seit Jahresbeginn unterstützt hat.

1 &os; 9.0-BETA1 verfügbar

Die erste BETA-Version aus dem &os;-9.0-Releasezyklus ist nun verfügbar. ISO-Images für die Architekturen amd64, i386, ia64, powerpc, powerpc64 sowie sparc64 sind inzwischen auf den meisten &os; Spiegelservern vorhanden. Eine der zahlreichen neuen Funktionen in &os; 9.0 ist das neue Installationsprogramm. Wir bitten daher unser Nutzer, dieses zu testen, und eine Neuinstallation durchzuführen.

7 17

Erweiterte Commit-Privilegien: Gavin Atkinson (src, doc)

15

Neuer Committer: Ryan Steinmetz (ports)

6 14

Neuer Committer: Grzegorz Bernacki (src)

13

Neuer Committer: Stephen Montgomery-Smith (ports)

11

Neuer Committer: Chris Rees (ports)

6 IPv6-Test-Images für &os;

Die &os; Foundation und iXsystems haben reine IPv6-Test-Images für &os; und PC-BSD bereitgestellt.

Neuer Committer: Julien Laffaye (ports)

5 25

Neuer Committer: Aleksandr Rybalko (src)

18

Neuer Committer: Ben Laurie (src)

12 Neuer Ports-Manager

Das Ports Management Team freut sich bekanntgeben zu können, dass Baptiste Daroussin als neues Mitglied in das Team aufgenommen wurde.

4 27 Statusreport Januar-März 2011

Der Statusreport für die Monate Januar bis März 2011 mit 34 Einträgen ist ab sofort verfügbar.

.
3 29

Neuer Committer: Artem Belevich (src)

27 Das FreeBSD Project nimmt am Google Summer of Code 2011 teil

Das FreeBSD Project freut sich, bekanntgeben zu dürfen, das es auch dieses Jahr an Google's Summer of Code-Programm teilnimmt. Durch dieses Programm wird die Arbeit von Studenten im Rahmen von Open Source-Projekten gefördert. Das FreeBSD Project nimmt bereits zum siebten Mal hintereinander an diesem Programm teil und hat seit der ersten Teilnahme 2005 mehr als 100 Studenten erfolgreich durch deren Arbeiten begleitet.

Zu den erfolgreich abgeschlossenen Projekten gehören Verbesserungen an der Linux-ABI-Emulation, NFSv4 ACLs, TCP-Regressionstests, die Unterstützung für das FUSE-Dateisytem sowie zahlreiche andere Projekte. Viele Studenten, die an diesem Programm teilnahmen, sind inzwischen aktive FreeBSD-Entwickler und/oder nehmen (nicht zuletzt dank der Unterstützung der FreeBSD Foundation) weiterhin aktiv an verschiedenen FreeBSD-Veranstaltungen auf der ganzen Welt teil.

Wir laden alle Studenten ein, während des Sommers gegen Bezahlung an der Weiterentwicklung von &os; zu arbeiten! Weitere Informationen zu möglichen Projektvorschlägen sowie zum Ablauf finden sich auf der Seite FreeBSD Summer Projects.

18

Neuer Committer: Sofian Brabez (ports)

13

Neuer Committer: Pawel Pekala (ports)

10

Das FreeBSD Ports Management Team freut sich, bekannt geben zu dürfen, dass Thomas Abthorpe ab sofort Mitglied des Teams ist.

5

Neuer Committer: Steven G. Kargl (src)

2 24 FreeBSD 8.2-RELEASE verfügbar

FreeBSD 8.2-RELEASE wurde veröffentlicht. Lesen Sie bitte die Release Notes und die Release Errata, bevor Sie mit der Installation beginnen, um sich über aktuelle Neuigkeiten und/oder eventuelle Probleme im Umgang mit 8.2-RELEASE zu informieren. Weitere Informationen zu verschiedenen FreeBSD-Versionen finden Sie auf der Seite Release Information.

FreeBSD 7.4-RELEASE verfügbar

FreeBSD 7.4-RELEASE wurde veröffentlicht. Lesen Sie bitte die Release Notes und die Release Errata, bevor Sie mit der Installation beginnen, um sich über aktuelle Neuigkeiten und/oder eventuelle Probleme im Umgang mit 7.4-RELEASE zu informieren. Weitere Informationen zu verschiedenen FreeBSD-Versionen finden Sie auf der Seite Release Information.

18

Erweiterte Commit-Privilegien: Martin Wilke (src, ports, doc)

3 &os; 7.4/8.2-RC3 verfügbar

Die dritten (und voraussichtlich letzten) Release Candidates der Releasezyklen von &os;-7.4/8.2 sind ab sofort verfügbar. 8.2-RC3 steht für die Architekturen amd64, i386, ia64, pc98, powerpc, sowie sparc64 bereit. 7.4-RC3 ist für die Architekturen amd64, i386, pc98, sowie sparc64 verfügbar. ISO-Images für diese Architekturen stehen inzwischen auf den meisten &os; Spiegelservern zum Download bereit. Weitere Informationen entnehmen Sie bitte der offiziellen Ankündigung.

1 25 Statusreport Oktober-Dezember 2010 verfügbar

Der Statusreport für die Monate Oktober bis December 2010 mit 37 Einträgen ist ab sofort verfügbar.

23 &os; 7.4-RC2 verfügbar

Der zweite Release Candidate aus dem &os;-7.4 Releasezyklus ist ab sofort verfügbar. ISO-Images für Tier-1-Architekturen stehen inzwischen auf den meisten &os; Spiegelservern zum Download bereit. Weitere Informationen entnehmen Sie bitte der offiziellen Ankündigung.

16 &os; 8.2-RC2 verfügbar

Der zweite Release Candidate aus dem &os;-8.2 Releasezyklus ist ab sofort verfügbar. ISO-Images für Tier-1-Architekturen stehen inzwischen auf den meisten &os; Spiegelservern zum Download bereit. Weitere Informationen entnehmen Sie bitte der offiziellen Ankündigung.

2010 12 27 &os; 7.4/8.2-RC1 verfügbar

Die ersten Release Candidates der Releasezyklen von &os;-7.4/8.2 sind ab sofort verfügbar. ISO-Images für Tier-1-Architekturen stehen inzwischen auf den meisten &os; Spiegelservern zum Download bereit. Weitere Informationen entnehmen Sie bitte der offiziellen Ankündigung.

16 &os; Foundation Newsletter Dezember 2010

Die &os; Foundation hat ihren End-of-Year Newsletter veröffentlicht, in dem sie beschreibt, wie sie das &os; Project und die &os;-Gemeinde 2010 unterstützt hat.

11 &os; 7.4/8.2-BETA1 verfügbar

Die ersten Testversionen der Releasezyklen von &os;-7.4/8.2 sind ab sofort verfügbar. ISO-Images für Tier-1-Architekturen stehen inzwischen auf den meisten &os; Spiegelservern zum Download bereit.

7

Neuer Committer: Florian Smeets (ports)

11 15

Neuer Committer: Eygene Ryabinkin (ports)

5

Neuer Committer: Zack Kirsch (src)

10 27 Statusreport Juli-September 2010 verfügbar

Der Statusreport für die Monate Juli bis September 2010 mit 55 Einträgen ist ab sofort verfügbar.

16

Neuer Committer: Frederic Culot (ports)

7

Neuer Committer: Jonathan Anderson (src)

5

Neuer Committer: Sergey Kandaurov (src)

9 25

Neuer Committer: Ganael Laplanche (ports)

21

Neuer Committer: Po-Chuan Hsieh (ports)

5

Neuer Committer: Andreas Tobler (src)

3

Neuer Committer: Steve Wills (ports)

8 31

Neuer Committer: Glen Barber (full doc/www)

30

Neuer Committer: Dimitry Andric (src)

1

Neuer Committer: Oliver Hauer (ports)

7 27 &os; Foundation Newsletter Juli 2010

Die &os; Foundation hat ihren Newsletter für Juli 2010 veröffentlicht, in dem sie beschreibt, wie sie das &os; Project und die &os;-Gemeinde in diesem Jahr bisher unterstützt hat.

Neuer Committer: Baptiste Daroussin (ports)

23 FreeBSD 8.1-RELEASE verfügbar

FreeBSD 8.1-RELEASE ist ab sofort verfügbar. Bitte lesen Sie die Release Notes sowie die Release Errata, bevor Sie die Installation beginnen, um sich über aktuelle Neuigkeiten oder Probleme beim Einsatz von &os; 8.1 zu informieren. Weitere Informationen zu den verschiedenen &os;-Versionen finden Sie auf der Seite Release Information.

22 Statusreport April-Juni 2010 verfügbar

Der Statusreport für die Monate April bis Juni 2010 mit 47 Einträgen ist ab sofort verfügbar.

21

Neuer Committer: Andrew Turner (src)

20 PC-BSD 8.1 verfügbar

PC-BSD 8.1 ist erschienen. Bei PC-BSD handelt es sich um ein erfolgreiches, auf FreeBSD basierendes Desktop-Betriebssystem, dessen Ziel es ist, einen einfach zu verwendenden Desktop bereitzustellen. Eine Liste aller neuen Funktionen bzw. aller Aktualisierungen seit der letzten Version finden Sie hier.

Die neue Version kann von der Projektseite heruntergeladen oder als DVD gekauft werden.

17

Neuer Committer: Tijl Coosemans (src)

15

Neuer Committer: Joseph S. Atkinson (ports)

14 Neues &os; Core Team gewählt

Das &os; Project freut sich, die Wahl des Core Teams 2010 bekanntgeben zu dürfen. Das &os; Core Team bildet den "Vorstand" des Projekts und ist für die Aufnahme neuer src-Committer, die Klärung von Meinungsverschiedenheiten unter den Committern, Politik und Verwaltung des Projekts sowie die Einrichtung von Unter-Komitees für verschiedene Aufgabenbereiche (Security Officer, Release Engineers, Port Managers, Webmasters und andere mehr) verantwortlich. Seit 2000 wird das Core Team alle zwei Jahre demokratisch durch die aktiven &os; Committer gewählt.

Weitere Informationen zur Wahl (sowie eine Liste der neuen Mitglieder des &os; Core Teams) finden Sie in der offiziellen Ankündigung.

2 &os; 8.1-RC2 verfügbar

Der zweite (und voraussichtlich letzte) Release Candidate aus dem &os;-8.1-Releasezyklus ist nun verfügbar. CD-ISO-Images für die Architekturen amd64, i386, ia64, powerpc, sowie sparc64 sind inzwischen auf den meisten &os; Spiegelservern vorhanden. Lesen Sie bitte auch die offizielle Ankündigung für weitere Informationen zu dieser neuen Version.

6 18 &os; 8.1-RC1 verfügbar

Der erste Release Candidate aus dem &os;-8.1-Releasezyklus ist nun verfügbar. ISO-Images für Tier-1-Architekturen finden Sie wie immer auf den verschiedenen &os; Spiegelservern. Lesen Sie bitte auch die offizielle Ankündigung für weitere Informationen zu dieser neuen Version.

10

Neuer Committer: Ashish SHUKLA (ports)

9

Neuer Committer: Brendan Fabeny (ports)

4

Neuer Committer: Matthew Fleming (src)

3

Neuer Committer: Andrey V. Elsukov (src)

Neuer Committer: Taras Korenko (doc/ru, www/ru)

5 29 &os; 8.1-BETA1 verfügbar

Die erste BETA-Version des &os;-8.1-Releasezyklus ist nun verfügbar. ISO-Images für Tier-1-Architekturen finden Sie wie immer auf den verschiedenen &os; Spiegelservern.

24 Google's Summer of Code gestartet

Das FreeBSD Project hat erneut zahlreiche qualitativ hochwertige Bewerbungen für eine Teilnahme an Google's Summer of Code erhalten. Heuer wurden 18 Projektvorschläge ausgewählt, die im Rahmen dieses Programms bearbeitet werden sollen. Bewerber, deren Projekte nicht ausgewählt wurden, möchten wir daran erinnern, dass das FreeBSD Project jederzeit dazu bereit ist, Studenten, die etwas über die Entwicklung von Betriebssystemen lernen wollen, über die Mailinglisten und Entwicklerforen des FreeBSD Projects zu unterstützen.

Weitere Informationen finden Sie in der offiziellen Ankündigung, die komplette Liste aller unterstützten Projekte hingegen im FreeBSD Summer of Code Wiki. Die Arbeit an den verschiedenen Projekten hat am 24. Mai 2010 begonnen. Wir möchten daher alle 18 neuen Studenten herzlich in unserer Gemeinschaft willkommen heißen.

19

Neuer Committer: Jayachandran C. (src)

4 29

Erweiterte Commit-Privilegien: Martin Matuška (src, ports)

22 Statusreport Januar-März 2010 verfügbar

Der Statusreport für die Monate Januar bis März 2010 mit 46 Einträgen ist ab sofort verfügbar.

20

Neuer Committer: Randi Harper (src)

19

Neuer Committer: Ryan Stone (src)

14

Neuer Committer: Ana Kukec (src)

11

Erweiterte Commit-Privilegien: René Ladan (doc-nl, ports)

Neuer Committer: Sahil Tandon (ports)

5

Neuer Committer: Giuseppe Pilichi (ports)

4 Das &os; Project beteiligt sich auch 2010 an Google's Summer of Code-Programm

Das &os; Project nimmt zum bereits sechsten Mal an Google's Summer of Code-Programm teil. Wir laden alle Studenten ein, während des Sommers gegen Bezahlung an der Weiterentwicklung von &os; zu arbeiten! Weitere Informationen (sowie ein Poster, das Sie an Ihrer Universität aufhängen können) finden sich auf der Seite &os; Summer Projects.

3 31

Neuer Committer: Bernhard Fröhlich (ports)

23 &os; 7.3-RELEASE verfügbar

&os; 7.3-RELEASE ist ab sofort verfügbar. Lesen Sie bitte die Release Notes und Release Errata, um sich über aktuelle Neuigkeiten und/oder eventuelle Probleme im Umgang mit &os; 7.3-RELEASE zu informieren. Weitere Informationen zu verschiedenen FreeBSD-Versionen finden Sie auf der Seite Release Information.

18 Neuer Ports Management Team Secretary: Thomas Abthorpe

Das &os; Ports Management Team freut sich, bekanntgeben zu dürfen, dass Thomas Abthorpe ab sofort die Postition des Ports Management Team Secretary bekleidet.

7

Reaktiviertes Commit-Bit: Niels Heinen (ports)

4 &os; 7.3-RC2 verfügbar

Der zweite Release Candidate des &os;-7.3-Releasezyklus ist verfügbar. ISO-Images für Tier-1-Architekturen finden Sie wie immer auf den verschiedenen &os; Spiegelservern.

3

Neuer Committer: Neel Natu (src)

2 22 PC-BSD 8.0 verfügbar

PC-BSD 8.0 ist erschienen. Bei PC-BSD handelt es sich um ein erfolgreiches, auf FreeBSD basierendes Desktop-Betriebssystem, dessen Ziel es ist, einen einfach zu verwendenden Desktop bereitzustellen. Eine Liste aller neuen Funktionen bzw. aller Aktualisierungen seit der letzten Version finden Sie hier.

Die neue Version kann von der Projektseite heruntergeladen oder als DVD gekauft werden.

15 &os; 7.3-RC1 verfügbar

Der erste Release Candidate des &os;-7.3-Releasezyklus ist nun verfügbar. ISO-Images für Tier-1-Architekturen finden Sie wie immer auf den verschiedenen &os; Spiegelservern.

12

Erweiterte Commit-Privilegien: Benedict Reuschling (kompletter doc/www-Bereich)

6

Neuer Committer: Bernhard Schmidt (src)

2 Erweiterte Commit-Privilegien: <a href="mailto:gabor@FreeBSD.org">Gábor Kövesdán</a> (src, ports, doc)

Gábor Kövesdán nahm 2008/2009 an Google's Summer of Code teil. Für seine Beiträge hat er nun Commit-Rechte für den Quellcode erhalten. Seine erste Aufgabe wird es sein, die Ergebnisse seiner Arbeit in den &os;-Quellcodebaum einzubringen.

1 30 &os; 7.3-BETA1 verfügbar

Die erste BETA-Version für &os; 7.3 ist ab sofort verfügbar. ISO-Images für Tier-1-Architekturen sind inzwischen auf den meisten &os; Spiegelservern verfügbar.

29

Neuer Committer: Bruce Cran (src)

28

Neuer Committer: Ulrich Spörlein (src)

26

Neuer Committer: Romain Tartière (ports)

Neuer Committer: Alberto Villa (ports)

17 Statusreport Oktober-Dezember 2009

Der Statusreport für die Monate Oktober-Dezember 2009 mit 38 Einträgen ist ab sofort verfügbar.

diff --git a/de_DE.ISO8859-1/share/xml/press.xml b/de_DE.ISO8859-1/share/xml/press.xml index 19898ce5f5..dc2c8da0aa 100644 --- a/de_DE.ISO8859-1/share/xml/press.xml +++ b/de_DE.ISO8859-1/share/xml/press.xml @@ -1,384 +1,401 @@ $FreeBSD$ 2013 + + + 6 + + + Fixing Network Attached Storage with commodity hardware + and BSD + http://boingboing.net/2013/06/23/fixing-network-attached-storag.html + Boing Boing + http://boingboing.net/ + 23. Juni 2013 + Ben Laurie +

Ben Laurie beschreibt, warum er ein proprietäres NAS durch ein + auf &os; basierendes NAS mit Standardhardware ersetzt hat.

+
+
+ 2 2012 - A BSD Year in Retrospective http://www.osnews.com/story/26787/2012_a_BSD_year_in_retrospective OSnews http://www.osnews.com/ 14. Februar 2013 Julian Djamil

Ein Rückblick auf die aufregenden Entwicklungen, die 2012 in der BSD-Betriebssystemfamilie stattgefunden haben. Näher eingegangen wird dabei auf FreeBSD, NetBSD, OpenBSD sowie DragonflyBSD.

1 A Decade of OS Access-control Extensibility https://queue.acm.org/detail.cfm?id=2430732 ACM Queue https://queue.acm.org/ 18. Januar 2013 Robert N. M. Watson

Wer sich näher mit der Absicherung von Betriebssystemen beschäftigt, ist erstaunt über die zahlreichen in der Praxis eingesetzten Modelle zur Zugangskontrolle.

2012 11 A world without Linux: Where would Apache, Microsoft — even Apple be today? http://www.infoworld.com/d/data-center/world-without-linux-where-would-apache-microsoft-even-apple-be-today-206680 Infoworld http://www.infoworld.com 12. November 2012 Paul Venezia

Hätte Linux nicht die Welt erobert, würden wir heute alle FreeBSD verwenden. Vielleicht sogar auf dem Desktop.

8 FreeBSD Now Supported on Windows Server Hyper-V Via Beta Release http://redmondmag.com/articles/2012/08/09/freebsd-beta-for-windows-server-hyper-v.aspx Redmondmag http://redmondmag.com 9. August 2012 Kurt Mackie

Microsoft hat heute die Betaversion eines Treibers veröffentlicht, mit der erstmals das frei verfügbare FreeBSD 8.2 in einer virtuellen Machine von Microsofts Hyper-V Server installiert werden kann.

6 X.Org 7.7 Goes Into FreeBSD, KMS Is Ready http://www.phoronix.com/scan.php?page=news_item&px=MTExNzY phoronix http://www.phoronix.com 11. Juni 2012 Michael Larabel

Obwohl X.Org 7.7 erst vor einer Woche erschienen ist, gibt es bereits aktualisierte FreeBSD-Installationspakete. Die FreeBSD-Entwickler bitten darum, ihnen beim Test dieser Pakete zu helfen.

Netflix Open Connect Network: FreeBSD, Not Linux http://www.phoronix.com/scan.php?page=news_item&px=MTExNDM phoronix http://www.phoronix.com 6. Juni 2012 Michael Larabel

Netflix hat mit Open Connect Network sein eigenes CDN (Content Distribution Network) angekündigt. Doch anstatt auf Linux zu setzen, wurde entschieden, FreeBSD als Basis zu verwenden.

5 Why Should You Use FreeBSD? Here's Some Reasons http://www.phoronix.com/scan.php?page=news_item&px=MTExMDg phoronix http://www.phoronix.com 31. Mai 2012 Michael Larabel

FreeBSD fragt, warum Sie FreeBSD verwenden. David Chisnall vom FreeBSD Project ist gerade dabei, das Werbematerial für dieses führende *BSD-Betriebssystem zu aktualisieren. Dazu stellt er auf den Mailinglisten die Frage: "Warum verwenden Sie FreeBSD?"

Colocation Provider NYI Launches East Coast Mirror for FreeBSD Foundation http://www.thewhir.com/web-hosting-news/colocation-provider-nyi-launches-east-coast-mirror-for-freebsd-foundation The WHIR http://www.thewhir.com 25. Mai 2012 Nicole Henderson

Der Hosting-Anbieter NYI hat die Installation eines an der US-Ostküste gelegenen Spiegelservers für die FreeBSD Foundation bekanntgegeben. "FreeBSD ist eine kritische Komponente in jedem unserer Geschäftsbereiche," erklärte Phillip Koblence, VP operations, NYI in einer Presseaussendung. "Wir sehen dieses Projekt als einen Weg, der FreeBSD-Gemeinde, deren Open Source-Projekte es uns erlauben, flexible Lösungen für unsere Kunden anzubieten, etwas zurück zu geben."

FreeBSD and Microsoft Hyper-V Interoperability Expected This Summer http://redmondmag.com/articles/2012/05/14/microsoft-hyperv-interoperability.aspx Redmondmag http://redmondmag.com 14. Mai 2012 Kurt Mackie

Microsoft und mehrere seiner Partnerfirmen sind dabei, ein Projekt abzuschliessen, dass Interoperabilität zwischen Windows Server Hyper-V und FreeBSD ermöglichen wird.

FreeBSD 10 To Use Clang Compiler, Deprecate GCC http://www.phoronix.com/scan.php?page=news_item&px=MTEwMjI phoronix http://www.phoronix.com 12. Mai 2012 Michael Larabel

Der GCC soll unter FreeBSD in naher Zukunft durch LLVM's Clang-Compiler ersetzt werden. Auch das Ziel eines GNU-freien C++11-Stacks ist deutlich näher gerückt. Das Ziel für FreeBSD 10 ist es, Clang als Standard-C/C++-Compiler einzusetzen, GCC als veraltet zu deklarieren und einen BSD-lizenzierten C++-Stack zu verwenden.

FreeBSD Achieved A Lot In Q1'2012 http://www.phoronix.com/scan.php?page=news_item&px=MTEwMjE phoronix http://www.phoronix.com 12. Mai 2012 Michael Larabel

In den ersten drei Monaten des Jahres 2012 gab es zahlreiche Fortschritte bei der Weiterentwicklung von FreeBSD. Dieser Artikel beschreibt einige Hightlights (basierend auf den Informationen des FreeBSD-Statusberichts).

4 FreeBSD Gets A New X.Org With Intel KMS http://www.phoronix.com/scan.php?page=news_item&px=MTA5MTc phoronix http://www.phoronix.com 23. April 2012 Michael Larabel

Das FreeBSD-Team hat ein Update für X.org angekündigt, dass die FreeBSD-Version auf X.org 7.5.2 aktualisiert und nun unter anderem auch Intel KMS unterstützt.

3 Most Reliable Hosting Company Sites in March 2012 http://news.netcraft.com/archives/2012/04/02/most-reliable-hosting-company-sites-in-march-2012.html Netcraft Ltd. http://www.netcraft.com/ 02. März 2012 Netcraft

Drei der 10 zuverlässigsten Webserver im März 2012 laufen unter FreeBSD.

2 PC-BSD 9 review ? to FreeBSD what Ubuntu is to Debian http://www.linuxuser.co.uk/reviews/pc-bsd-9-review-to-freebsd-what-ubuntu-is-to-debian/ Linux User & Developer http://www.linuxuser.co.uk 09. Februar 2012 Koen Vervloesem

PC-BSD bietet einen voll funktionsfähigen Desktop, der auf dem stabilen FreeBSD basiert und ist daher ideal für die ersten Schritte in die BSD-Welt.

1 [Review] FreeBSD 9.0 http://linuxconfig.net/review/freebsd-review/freebsd-9-0-review.html linuxconfig.net http://linuxconfig.net 10. Januar 2012 linuxconfig.net

Dieser Artikel bietet eine Einführung in verschiedene neue Funktionen von FreeBSD 9.0.

2011 11 Why aren't you using FreeBSD? http://www.infoworld.com/d/data-center/why-arent-you-using-freebsd-178119?page=0,0 Infoworld http://www.infoworld.com 11 November 2011 Paul Venezia

Paul Venezia beschreibt, warum er auf seinen Servern FreeBSD einsetzt.

9 FreeBSD: A Faster Platform For Linux Gaming Than Linux? http://www.phoronix.com/scan.php?page=article&item=linux_games_bsd Phoronix http://www.phoronix.com/ 07. September 2011

Michael Larabel zeigt, dass einige Linux-Programme unter FreeBSD schneller laufen als unter Linux selbst.

7 Most Reliable Hosting Company Sites in June 2011 http://news.netcraft.com/archives/2011/07/08/most-reliable-hosting-company-sites-in-june-2011.html Netcraft Ltd. http://www.netcraft.com/ 08. Juli 2011 Jennifer Cownie

Die drei zuverlässigsten Webserver im Juni 2011 laufen unter FreeBSD.

3 PC-BSD 8.2 review http://www.linuxbsdos.com/2011/03/03/pc-bsd-8-2-review/ LinuxBSDos.com http://www.linuxbsdos.com/ 03. März 2011 LinuxBSDos.com

LinuxBSDos.com testet die Installation (insbesondere die Optionen zur Verschlüsselung der Festplatte) sowie die Konfiguration und Administration (inklusive der Installation von Softwarepaketen Dritter über das eigene PBI-System) von PC-BSD 8.2.

2 FreeBSD 8.2 expands ZFS support http://itmanagement.earthweb.com/osrc/article.php/3926181/FreeBSD-82-Expands-ZFS-Support----Without-Oracle.htm Datamation.com http://itmanagement.earthweb.com/ 25. Februar 2011 Sean Michael Kerner

Der Autor betrachtet den aktuellen Status und gibt einen Ausblick auf die Zukunft von ZFS unter FreeBSD. Die Informationen in diesem Artikel basieren auf einem Interview, das die Webseite mit dem FreeBSD-Entwickler Josh Paetzel sowie Matt Olander von iXsystems.

2010 8 PC-BSD 8.1 review http://www.linuxbsdos.com/2010/08/17/pc-bsd-8-1-review/ LinuxBSDos.com http://www.linuxbsdos.com/ 17. August 2010 LinuxBSDos.com

LinuxBSDos.com beschreibt in diesem Artikel die Installation sowie die Konfiguration und Administration (inklusive der Installation von Softwarepaketen Dritter über das eigene PBI-System) von PC-BSD 8.1.

2 Health Check: FreeBSD - The unknown giant http://www.h-online.com/open/features/Health-Check-FreeBSD-The-unknown-giant-920248.html The H http://www.h-online.com/ 04. Februar 2010 Richard Hillesley

Richard Hillesley betrachtet die Geschichte von FreeBSD, die BSD-Lizenz, Beastie sowie die neuen Funktionen in FreeBSD 8.0.

diff --git a/de_DE.ISO8859-1/share/xml/release.l10n.ent b/de_DE.ISO8859-1/share/xml/release.l10n.ent index 5717ea8d06..4c408cb638 100644 --- a/de_DE.ISO8859-1/share/xml/release.l10n.ent +++ b/de_DE.ISO8859-1/share/xml/release.l10n.ent @@ -1,141 +1,153 @@ ]]> Version & Plattform Distribution ISO Statusseite FreeBSD &betarel2.current;-&betarel2.vers; [Lesen] amd64 [Distribution] [ISO] i386 [Distribution] [ISO] ia64 [Distribution] [ISO] powerpc [Distribution] [ISO] powerpc64 [Distribution] [ISO] sparc64 [Distribution] [ISO] '> ]]>

Beim Test der nächsten FreeBSD-Version&beta.plural; helfen

Unsere Entwickler und Release-Ingenieure bereiten die Veröffentlichung der nächsten FreeBSD-Version&beta.plural; vor. Wenn Sie beim Test der neuen Version&beta.plural; helfen wollen, können Sie diese herunterladen. Beachten Sie dabei aber, dass diese Versionen noch getestet werden müssen und daher für eine Produktivumgebung nicht geeignet sind.

- - + + - - + + + + + + + + + + + + + + + - - - + + + - - - + + + - -->
Version & Plattform Distribution ISO
FreeBSD &betarel.current;-&betarel.vers;
amd64
(x86-64, x64)
[Distribution][ISO][Distribution][ISO]
i386[Distribution][ISO][Distribution][ISO]
ia64[Distribution][ISO]
powerpc[Distribution][ISO]
sparc64[Distribution][ISO]powerpc64[Distribution][ISO]
powerpc64[Distribution][ISO]sparc64[Distribution][ISO]
&beta.second; '> ]]> diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml index f570dbf9d6..fcf74d2279 100644 --- a/en_US.ISO8859-1/articles/committers-guide/article.xml +++ b/en_US.ISO8859-1/articles/committers-guide/article.xml @@ -1,4658 +1,4658 @@ ]>
Committer's Guide The &os; Documentation Project 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 The &os; Documentation Project &tm-attrib.freebsd; &tm-attrib.coverity; &tm-attrib.ibm; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.general; $FreeBSD$ $FreeBSD$ This document provides information for the &os; committer community. All new committers should read this document before they start, and existing committers are strongly encouraged to review it from time to time. Almost all &os; developers have commit rights to one or more repositories. However, a few developers do not, and some of the information here applies to them as well. (For instance, some people only have rights to work with the Problem Report database). Please see for more information. This document may also be of interest to members of the &os; community who want to learn more about how the project works. Administrative Details Login Methods &man.ssh.1;, protocol 2 only Main Shell Host freefall.FreeBSD.org src/ Subversion Root svn+ssh://svn.FreeBSD.org/base (see also ). doc/ Subversion Root svn+ssh://svn.FreeBSD.org/doc (see also ). ports/ Subversion Root svn+ssh://svn.FreeBSD.org/ports (see also ). Internal Mailing Lists developers (technically called all-developers), doc-developers, doc-committers, ports-developers, ports-committers, src-developers, src-committers. (Each project repository has its own -developers and -committers mailing lists. Archives for these lists may be found in files /home/mail/repository-name-developers-archive and /home/mail/repository-name-committers-archive on the FreeBSD.org cluster.) Core Team monthly reports /home/core/public/monthly-reports on the FreeBSD.org cluster. Ports Management Team monthly reports /home/portmgr/public/monthly-reports on the FreeBSD.org cluster. Noteworthy src/ SVN Branches stable/8 (8.X-STABLE), stable/9 (9.X-STABLE), head (-CURRENT) &man.ssh.1; is required to connect to the project hosts. For more information, see . Useful links: &os; Project Internal Pages &os; Project Hosts &os; Project Administrative Groups Commit Bit Types The &os; repository has a number of components which, when combined, support the basic operating system source, documentation, third party application ports infrastructure, and various maintained utilities. When &os; commit bits are allocated, the areas of the tree where the bit may be used are specified. Generally, the areas associated with a bit reflect who authorized the allocation of the commit bit. Additional areas of authority may be added at a later date: when this occurs, the committer should follow normal commit bit allocation procedures for that area of the tree, seeking approval from the appropriate entity and possibly getting a mentor for that area for some period of time. Committer Type Responsible Tree Components src core@ src/, doc/ subject to appropriate review doc doceng@ doc/, src/ documentation ports portmgr@ ports/ Commit bits allocated prior to the development of the notion of areas of authority may be appropriate for use in many parts of the tree. However, common sense dictates that a committer who has not previously worked in an area of the tree seek review prior to committing, seek approval from the appropriate responsible party, and/or work with a mentor. Since the rules regarding code maintenance differ by area of the tree, this is as much for the benefit of the committer working in an area of less familiarity as it is for others working on the tree. Committers are encouraged to seek review for their work as part of the normal development process, regardless of the area of the tree where the work is occurring. Policy for <filename>doc/</filename> Committer Activity in <filename>src/</filename> doc committers may commit documentation changes to src files, such as man pages, READMEs, fortune databases, calendar files, and comment fixes without approval from a src committer, subject to the normal care and tending of commits. doc committers may commit minor src changes and fixes, such as build fixes, small features, etc, with an "Approved by" from a src committer. doc committers may seek an upgrade to a src commit bit by acquiring a mentor, who will propose the doc committer to core. When approved, they will be added to 'access' and the normal mentoring period will ensue, which will involve a continuing of Approved by for some period. "Approved by" is only acceptable from non-mentored src committers -- mentored committers can provide a "Reviewed by" but not an "Approved by". Subversion Primer It is assumed that you are already familiar with the basic operation of the version control systems in use. Traditionally this was CVS. Subversion is used for the src tree as of May 2008, the doc/www tree as of May 2012 and the ports tree as of July 2012. There is a list of things missing in Subversion when compared to CVS. The notes at might also be useful. Introduction The &os; source repository switched from CVS to Subversion on May 31st, 2008. The first real SVN commit is r179447. The &os; doc/www repository switched from CVS to Subversion on May 19th, 2012. The first real SVN commit is r38821. Part of the doc/www CVS to SVN conversion included an infrastructural change to the build process. The most notable change is the location of the &os; website www tree, which has been moved from www/lang/ to head/lang/htdocs/. The &os; ports repository switched from CVS to Subversion on July 14th, 2012. The first real SVN commit is r300894. There are mechanisms in place to automatically merge changes back from the Subversion src repository to the CVS repository for some &os; branches (releng/6 through releng/9), however this is purely to support pre-existing end-user installs and should not be relied upon, recommended or advertised. Future branches will not be exported to CVS at all. The ports repository was exported to CVS for a period of time to aid end user migration, but as of 28th February 2013 is no longer exported. Subversion is not that different from CVS when it comes to daily use, but there are differences. Subversion has a number of features that should make developers' lives easier. The most important advantage to Subversion (and the reason why &os; switched) is that it handles branches and merging much better than CVS does. Some of the principal differences are: Commits are atomic. Revision numbers apply across the repository—all files that were modified in the same commit have the same revision number. Branching and tagging are namespace operations. Directories are versioned. Files and directories can have arbitrary, versioned metadata attached to them. Files and directories can be copied, with full history tracking. No more contortions due to CVS weakness such as applying &man.patch.1; files at compile time in order to avoid touching vendor branch code. No more repo-copies. Subversion can be installed from the &os; Ports - Collection, by issuing the following commands: + Collection by issuing these commands: &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make clean install Getting Started There are a few ways to obtain a working copy of the tree from Subversion. This section will explain them. Direct Checkout The first is to check out directly from the main repository. For the src tree, use: &prompt.user; svn checkout svn+ssh://svn.freebsd.org/base/head /usr/src For the doc tree, use: &prompt.user; svn checkout svn+ssh://svn.freebsd.org/doc/head /usr/doc For the ports tree, use: &prompt.user; svn checkout svn+ssh://svn.freebsd.org/ports/head /usr/ports Though the remaining examples in this document are written with the workflow of working with the src tree in mind, the underlying concepts are the same for working with the doc and the ports tree. Ports related Subversion operations are listed in . The above command will check out a CURRENT source tree as /usr/src/, which can be any target directory on the local filesystem. Omitting the final argument of that command causes the working copy, in this case, to be named head, but that can be renamed safely. svn+ssh means the SVN protocol tunnelled over SSH. The name of the server is svn.freebsd.org, base is the path to the repository, and head is the subdirectory within the repository. If your &os; login name is different from your login name on your local machine, you must either include it in the URL (for example svn+ssh://jarjar@svn.freebsd.org/base/head), or add an entry to your ~/.ssh/config in the form: Host svn.freebsd.org User jarjar This is the simplest method, but it's hard to tell just yet how much load it will place on the repository. Subversion is much faster than CVS, however. The svn diff does not require access to the server as SVN stores a reference copy of every file in the working copy. This, however, means that Subversion working copies are very large in size. Checkout from a Mirror Check out a working copy from a mirror by substituting the mirror's URL for svn+ssh://svn.freebsd.org/base. This can be an official mirror or a mirror maintained by using svnsync. There is a serious disadvantage to this method: every time something is to be committed, a svn relocate to the master repository has to be done, remembering to svn relocate back to the mirror after the commit. Also, since svn relocate only works between repositories that have the same UUID, some hacking of the local repository's UUID has to occur before it is possible to start using it. Unlike with CVS, the hassle of a local svnsync mirror probably is not worth it unless the network connectivity situation or other factors demand it. If it is needed, see the end of this chapter for information on how to set one up. <literal>RELENG_*</literal> Branches and General Layout In svn+ssh://svn.freebsd.org/base, base refers to the source tree. Similarly, ports refers to the ports tree, and so on. These are separate repositories with their own change number sequences, access controls and commit mail. For the base repository, HEAD refers to the -CURRENT tree. For example, head/bin/ls is what would go into /usr/src/bin/ls in a release. Some key locations are: /head/ which corresponds to HEAD, also known as -CURRENT. /stable/n which corresponds to RELENG_n. /releng/n.n which corresponds to RELENG_n_n. /release/n.n.n which corresponds to RELENG_n_n_n_RELEASE. /vendor* is the vendor branch import work area. This directory itself does not contain branches, however its subdirectories do. This contrasts with the stable, releng and release directories. /projects and /user feature a branch work area, like in Perforce. As above, the /user directory does not contain branches itself. &os; Documentation Project Branches and Layout In svn+ssh://svn.freebsd.org/doc, doc refers to the repository root of the source tree. In general, most &os; Documentation Project work will be done within the head/ branch of the documentation source tree. &os; documentation is written and/or translated to various languages, each in a separate directory in the head/ branch. Each translation set contains several subdirectories for the various parts of the &os; Documentation Project. A few noteworthy directories are: /articles/ contains the source code for articles written by various &os; contributors. /books/ contains the source code for the different books, such as the &os; Handbook. /htdocs/ contains the source code for the &os; website. &os; Ports Tree Branches and Layout In svn+ssh://svn.freebsd.org/ports, - ports refers repository root of the + ports refers to the repository root of the ports tree. In general, most &os; port work will be done within the head/ branch of the ports tree which is the actual ports tree used to install software. Some other key locations are: /branches/RELENG_n_n_n which corresponds to RELENG_n_n_n is used to merge back security updates in preparation for a release. /tags/RELEASE_n_n_n which corresponds to RELEASE_n_n_n represents a release tag of the ports tree. /tags/RELEASE_n_EOL represents the end of life tag of a specific &os; branch. Daily Use This section will explain how to perform common day-to-day operations with Subversion. Help SVN has built in help documentation. It can be accessed by typing the following command: &prompt.user; svn help Additional information can be found in the Subversion Book. Checkout As seen earlier, to check out the &os; head branch: &prompt.user; svn checkout svn+ssh://svn.freebsd.org/base/head /usr/src At some point, more than just HEAD will probably be useful, for instance when merging changes to stable/7. Therefore, it may be useful to have a partial checkout of the complete tree (a full checkout would be very painful). To do this, first check out the root of the repository: &prompt.user; svn checkout --depth=immediates svn+ssh://svn.freebsd.org/base This will give base with all the files it contains (at the time of writing, just ROADMAP.txt) and empty subdirectories for head, stable, vendor and so on. Expanding the working copy is possible. Just change the depth of the various subdirectories: &prompt.user; svn up --set-depth=infinity base/head &prompt.user; svn up --set-depth=immediates base/release base/releng base/stable The above command will pull down a full copy of head, plus empty copies of every release tag, every releng branch, and every stable branch. If at a later date merging to 7-STABLE is required, expand the working copy: &prompt.user; svn up --set-depth=infinity base/stable/7 Subtrees do not have to be expanded completely. For instance, expanding only stable/7/sys and then later expand the rest of stable/7: &prompt.user; svn up --set-depth=infinity base/stable/7/sys &prompt.user; svn up --set-depth=infinity base/stable/7 Updating the tree with svn update will only update what was previously asked for (in this case, head and stable/7; it will not pull down the whole tree. Decreasing the depth of a working copy is not possible. Anonymous Checkout It is possible to anonymously check out the &os; repository with Subversion. This will give access to a - read-only tree that can be updated, but not committed - to. To do this, use the following command: + read-only tree that can be updated, but not committed back + to the main repository. To do this, use the following command: &prompt.user; svn co https://svn0.us-west.FreeBSD.org/base/head /usr/src Select the closest mirror and verify the mirror server certificate from the list of Subversion mirror sites. Updating the Tree To update a working copy to either the latest revision, or a specific revision: &prompt.user; svn update &prompt.user; svn update -r12345 Status To view the local changes that have been made to the working copy: &prompt.user; svn status To show local changes and files that are out-of-date do: &prompt.user; svn status --show-updates Editing and Committing Unlike Perforce, SVN does not need to be told in advance about file editing. svn commit works like the equivalent CVS command. To commit all changes in the current directory and all subdirectories: &prompt.user; svn commit To commit all changes in, for example, lib/libfetch/ and usr/bin/fetch/ in a single operation: &prompt.user; svn commit lib/libfetch usr/bin/fetch There is also a commit wrapper for the ports tree to handle the properties and sanity checking your changes: &prompt.user; /usr/ports/Tools/scripts/psvn commit Adding and Removing Files Before adding files, get a copy of auto-props.txt (there is also a ports tree specific version) and add it to ~/.subversion/config according to the instructions in the file. If you added something before reading this, use svn rm --keep-local for just added files, fix your config file and re-add them again. The initial config file is created when you first run a svn command, even something as simple as svn help. Files are added to a SVN repository with svn add. To add a file named foo, edit it, then: &prompt.user; svn add foo Most new source files should include a - $&os;$ string in the - new file. On commit, svn will expand + $&os;$ string near the start of the + file. On commit, svn will expand the $&os;$ string, adding the file path, revision number, date and time of commit, and the username of the committer. Files which cannot be modified may be committed without the $&os;$ string. Files can be removed with svn remove: &prompt.user; svn remove foo Subversion does not require deleting the file before using svn rm, and indeed complains if that happens. It is possible to add directories with svn add: &prompt.user; mkdir bar &prompt.user; svn add bar Although svn mkdir makes this easier by combining the creation of the directory and the adding of it: &prompt.user; svn mkdir bar Like files, directories are removed with svn rm. There is no separate command specifically for removing directories. &prompt.user; svn rm bar Copying and Moving Files This command creates a copy of foo.c named bar.c, with the new file also under version control: &prompt.user; svn copy foo.c bar.c The example above is equivalent to: &prompt.user; cp foo.c bar.c &prompt.user; svn add bar.c To move and rename a file: &prompt.user; svn move foo.c bar.c Log and Annotate svn log shows revisions and commit messages, most recent first, for files or directories. When used on a directory, all revisions that affected the directory and files within that directory are shown. svn annotate, or equally svn praise or svn blame, shows the most recent revision number and who committed that revision for each line of a file. Diffs svn diff displays changes to the working copy. Diffs generated by SVN are unified and include new files by default in the diff output. svn diff can show the changes between two revisions of the same file: &prompt.user; svn diff -r179453:179454 ROADMAP.txt It can also show all changes for a specific changeset. The following will show what changes were made to the current directory and all subdirectories in changeset 179454: &prompt.user; svn diff -c179454 . Reverting Local changes (including additions and deletions) can be reverted using svn revert. It does not update out-of-date files, but just replaces them with pristine copies of the original version. Conflicts If an svn update resulted in a merge conflict, Subversion will remember which files have conflicts and refuse to commit any changes to those files until explicitly told that the conflicts have been resolved. The simple, not yet deprecated procedure is the following: &prompt.user; svn resolved foo However, the preferred procedure is: &prompt.user; svn resolve --accept=working foo The two examples are equivalent. Possible values for --accept are: working: use the version in your working directory (which one presumes has been edited to resolve the conflicts). base: use a pristine copy of the version you had before svn update, discarding your own changes, the conflicting changes, and possibly other intervening changes as well. mine-full: use what you had before svn update, including your own changes, but discarding the conflicting changes, and possibly other intervening changes as well. theirs-full: use the version that was retrieved when you did svn update, discarding your own changes. Advanced Use Sparse Checkouts SVN allows sparse, or partial checkouts of a directory by adding to a svn checkout. Valid arguments to are: empty: the directory itself without any of its contents. files: the directory and any files it contains. immediates: the directory and any files and directories it contains, but none of the subdirectories' contents. infinity: anything. The --depth option applies to many other commands, including svn commit, svn revert, and svn diff. Since --depth is sticky, there is a --set-depth option for svn update that will change the selected depth. Thus, given the working copy produced by the previous example: &prompt.user; cd ~/freebsd &prompt.user; svn update --set-depth=immediates . The above command will populate the working copy in ~/freebsd with ROADMAP.txt and empty subdirectories, and nothing will happen when svn update is executed on the subdirectories. However, the following command will set the depth for head (in this case) to infinity, and fully populate it: &prompt.user; svn update --set-depth=infinity head Direct Operation Certain operations can be performed directly on the repository without touching the working copy. Specifically, this applies to any operation that does not require editing a file, including: log, diff mkdir remove, copy, rename propset, propedit, propdel merge Branching is very fast. The following command would be used to branch RELENG_8: &prompt.user; svn copy svn+ssh://svn.freebsd.org/base/head svn+ssh://svn.freebsd.org/base/stable/8 This is equivalent to the following set of commands which take minutes and hours as opposed to seconds, depending on your network connection: &prompt.user; svn checkout --depth=immediates svn+ssh://svn.freebsd.org/base &prompt.user; cd base &prompt.user; svn update --depth=infinity head &prompt.user; svn copy head stable/8 &prompt.user; svn commit stable/8 Merging with <acronym>SVN</acronym> This section deals with merging code from one branch to another (typically, from head to a stable branch). In all examples below, $FSVN refers to the location of the &os; Subversion repository, svn+ssh://svn.freebsd.org/base/. About Merge Tracking From the user's perspective, merge tracking information (or mergeinfo) is stored in a property called svn:mergeinfo, which is a comma-separated list of revisions and ranges of revisions that have been merged. When set on a file, it applies only to that file. When set on a directory, it applies to that directory and its descendants (files and directories) except for those that have their own svn:mergeinfo. It is not inherited. For instance, stable/6/contrib/openpam/ does not implicitly inherit mergeinfo from stable/6/, or stable/6/contrib/. Doing so would make partial checkouts very hard to manage. Instead, mergeinfo is explicitly propagated down the tree. For merging something into branch/foo/bar/, the following rules apply: If branch/foo/bar/ does not already have a mergeinfo record, but a direct ancestor (for instance, branch/foo/) does, then that record will be propagated down to branch/foo/bar/ before information about the current merge is recorded. Information about the current merge will not be propagated back up that ancestor. If a direct descendant of branch/foo/bar/ (for instance, branch/foo/bar/baz/) already has a mergeinfo record, information about the current merge will be propagated down to it. If you consider the case where a revision changes several separate parts of the tree (for example, branch/foo/bar/ and branch/foo/quux/), but you only want to merge some of it (for example, branch/foo/bar/), you will see that these rules make sense. If mergeinfo was propagated up, it would seem like that revision had also been merged to branch/foo/quux/, when in fact it had not been. Selecting the Source and Target Because of mergeinfo propagation, it is important to choose the source and target for the merge carefully to minimise property changes on unrelated directories. The rules for selecting the merge target (the directory that you will merge the changes to) can be summarized as follows: Never merge directly to a file. Never, ever merge directly to a file. Never, ever, ever merge directly to a file. Changes to kernel code should be merged to sys/. For instance, a change to the &man.ichwd.4; driver should be merged to sys/, not sys/dev/ichwd/. Likewise, a change to the TCP/IP stack should be merged to sys/, not sys/netinet/. Changes to code under etc/ should be merged at etc/, not below it. Changes to vendor code (code in contrib/, crypto/ and so on) should be merged to the directory where vendor imports happen. For instance, a change to crypto/openssl/util/ should be merged to crypto/openssl/. This is rarely an issue, however, since changes to vendor code are usually merged wholesale. Changes to userland programs should as a general rule be merged to the directory that contains the Makefile for that program. For instance, a change to usr.bin/xlint/arch/i386/ should be merged to usr.bin/xlint/. Changes to userland libraries should as a general rule be merged to the directory that contains the Makefile for that library. For instance, a change to lib/libc/gen/ should be merged to lib/libc/. There may be cases where it makes sense to deviate from the rules for userland programs and libraries. For instance, everything under lib/libpam/ is merged to lib/libpam/, even though the library itself and all of the modules each have their own Makefile. Changes to manual pages should be merged to share/man/manN/, for the appropriate value of N. Other changes to share/ should be merged to the appropriate subdirectory and not to share/ directly. Changes to a top-level file in the source tree such as UPDATING or Makefile.inc1 should be merged directly to that file rather than to the root of the whole tree. Yes, this is an exception to the first three rules. When in doubt, ask. If you need to merge changes to several places at once (for instance, changing a kernel interface and every userland program that uses it), merge each target separately, then commit them together. For instance, if you merge a revision that changed a kernel API and updated all the userland bits that used that API, you would merge the kernel change to sys, and the userland bits to the appropriate userland directories, then commit all of these in one go. The source will almost invariably be the same as the target. For instance, you will always merge stable/7/lib/libc/ from head/lib/libc/. The only exception would be when merging changes to code that has moved in the source branch but not in the parent branch. For instance, a change to &man.pkill.1; would be merged from bin/pkill/ in head to usr.bin/pkill/ in stable/7. Preparing the Merge Target Because of the mergeinfo propagation issues described earlier, it is very important that you never merge changes into a sparse working copy. You must always have a full checkout of the branch you will merge into. For instance, when merging from HEAD to 7, you must have a full checkout of stable/7: &prompt.user; cd stable/7 &prompt.user; svn up --set-depth=infinity The target directory must also be up-to-date and must not contain any uncommitted changes or stray files. Identifying Revisions Identifying revisions to be merged is a must. If the target already has complete mergeinfo, ask SVN for a list: &prompt.user; cd stable/6/contrib/openpam &prompt.user; svn mergeinfo --show-revs=eligible $FSVN/head/contrib/openpam If the target does not have complete mergeinfo, check the log for the merge source. Merging Now, let us start merging! The Principles Say you would like to merge: revision $R in directory $target in stable branch $B from directory $source in head $FSVN is svn+ssh://svn.freebsd.org/base Assuming that revisions $P and $Q have already been merged, and that the current directory is an up-to-date working copy of stable/$B, the existing mergeinfo looks like this: &prompt.user; svn propget svn:mergeinfo -R $target $target - /head/$source:$P,$Q Merging is done like so: &prompt.user; svn merge -c$R $FSVN/head/$source $target Checking the results of this is possible with svn diff. The svn:mergeinfo now looks like: &prompt.user; svn propget svn:mergeinfo -R $target $target - head/$source:$P,$Q,$R If the results are not exactly as shown, assistance may be required before committing as mistakes may have been made, or there may be something wrong with the existing mergeinfo, or there may be a bug in Subversion. Practical Example As a practical example, consider the following scenario: The changes to netmap.4 in r238987 is to be merged from CURRENT to 9-STABLE. The file resides in head/share/man/man4 and according to this is also where to do the merge. Note that in this example all paths are relative to the top of the svn repository. For more information on the directory layout, see . The first step is to inspect the existing mergeinfo. &prompt.user; svn propget svn:mergeinfo -R stable/9/share/man/man4 Take a quick note of how it looks before moving on to the next step; doing the actual merge: &prompt.user; svn merge -c r238987 svn+ssh://svn.freebsd.org/base/head/share/man/man4 stable/9/share/man/man4 --- Merging r238987 into 'stable/9/share/man/man4': U stable/9/share/man/man4/netmap.4 --- Recording mergeinfo for merge of r238987 into 'stable/9/share/man/man4': U stable/9/share/man/man4 Check that the revision number of the merged revision has been added. Once this is verified, the only thing left is the actual commit. &prompt.user; svn commit stable/9/share/man/man4 Merging into the Kernel (<filename class="directory">sys/</filename>) As stated above, merging into the kernel is different from merging in the rest of the tree. In many ways merging to the kernel is simpler because there is always the same merge target (sys/). Once svn merge has been executed, svn diff has to be run on the directory to check the changes. This may show some unrelated property changes, but these can be ignored. Next, build and test the kernel, and, once the tests are complete, commit the code as normal, making sure that the commit message starts with Merge r226222 from head, or similar. Precautions Before Committing As always, build world (or appropriate parts of it). Check the changes with svn diff and svn stat. Make sure all the files that should have been added or deleted were in fact added or deleted. Take a closer look at any property change (marked by a M in the second column of svn stat). Normally, no svn:mergeinfo properties should be anywhere except the target directory (or directories). If something looks fishy, ask for help. Committing Make sure to commit a top level directory to have the mergeinfo included as well. Do not specify individual files on the command line. For more information about committing files in general, see the relevant section of this primer. Vendor Imports with <acronym>SVN</acronym> Please read this entire section before starting a vendor import. Patches to vendor code fall into two categories: Vendor patches: these are patches that have been issued by the vendor, or that have been extracted from the vendor's version control system, which address issues which in your opinion cannot wait until the next vendor release. &os; patches: these are patches that modify the vendor code to address &os;-specific issues. The nature of a patch dictates where it should be committed: Vendor patches should be committed to the vendor branch, and merged from there to head. If the patch addresses an issue in a new release that is currently being imported, it must not be committed along with the new release: the release must be imported and tagged first, then the patch can be applied and committed. There is no need to re-tag the vendor sources after committing the patch. &os; patches should be committed directly to head. Preparing the Tree If importing for the first time after the switch to Subversion, flattening and cleaning up the vendor tree is necessary, as well as bootstrapping the merge history in the main tree. Flattening During the conversion from CVS to Subversion, vendor branches were imported with the same layout as the main tree. This means that the pf vendor sources ended up in vendor/pf/dist/contrib/pf. The vendor source is best directly in vendor/pf/dist. To flatten the pf tree: &prompt.user; cd vendor/pf/dist/contrib/pf &prompt.user; svn mv $(svn list) ../.. &prompt.user; cd ../.. &prompt.user; svn rm contrib &prompt.user; svn propdel -R svn:mergeinfo . &prompt.user; svn commit The propdel bit is necessary because starting with 1.5, Subversion will automatically add svn:mergeinfo to any directory that is copied or moved. In this case, as nothing is being merged from the deleted tree, they just get in the way. Tags may be flattened as well (3, 4, 3.5 etc.); the procedure is exactly the same, only changing dist to 3.5 or similar, and putting the svn commit off until the end of the process. Cleaning Up The dist tree can be cleaned up as necessary. Disabling keyword expansion is recommended, as it makes no sense on unmodified vendor code and in some cases it can even be harmful. OpenSSH, for example, includes two files that originated with &os; and still contain the original version tags. To do this: &prompt.user; svn propdel svn:keywords -R . &prompt.root; svn commit Bootstrapping Merge History If importing for the first time after the switch to Subversion, bootstrap svn:mergeinfo on the target directory in the main tree to the revision that corresponds to the last related change to the vendor tree, prior to importing new sources: &prompt.user; cd head/contrib/pf &prompt.user; svn merge --record-only svn+ssh://svn.freebsd.org/base/vendor/pf/dist@180876 . &prompt.user; svn commit Importing New Sources With two commits—one for the import itself and one for the tag—this step can optionally be repeated for every upstream release between the last import and the current import. Preparing the Vendor Sources Unlike in CVS where only the needed parts were imported into the vendor tree to avoid bloating the main tree, Subversion is able to store a full distribution in the vendor tree. So, import everything, but merge only what is required. A svn add is required to add any files that were added since the last vendor import, and svn rm is required to remove any that were removed since. Preparing sorted lists of the contents of the vendor tree and of the sources that are about to be imported is recommended, to facilitate the process. &prompt.user; cd vendor/pf/dist &prompt.user; svn list -R | grep -v '/$' | sort >../old &prompt.user; cd ../pf-4.3 &prompt.user; find . -type f | cut -c 3- | sort >../new With these two files, comm -23 ../old ../new will list removed files (files only in old), while comm -13 ../old ../new will list added files only in new. Importing into the Vendor Tree Now, the sources must be copied into dist and the svn add and svn rm commands should be used as needed: &prompt.user; cd vendor/pf/pf-4.3 &prompt.user; tar cf - . | tar xf - -C ../dist &prompt.user; cd ../dist &prompt.user; comm -23 ../old ../new | xargs svn rm &prompt.user; comm -13 ../old ../new | xargs svn --parents add If any directories were removed, they will have to be svn rmed manually. Nothing will break if they are not, but they will remain in the tree. Check properties on any new files. All text files should have svn:eol-style set to native. All binary files should have svn:mime-type set to application/octet-stream unless there is a more appropriate media type. Executable files should have svn:executable set to *. No other properties should exist on any file in the tree. Committing is now possible, however it is good practice to make sure that everything is OK by using the svn stat and svn diff commands. Tagging Once committed, vendor releases should be tagged for future reference. The best and quickest way to do this is directly in the repository: &prompt.user; svn cp svn+ssh://svn.freebsd.org/base/vendor/pf/dist svn+ssh://svn.freebsd.org/base/vendor/pf/4.3 Once that is complete, svn up the working copy of vendor/pf to get the new tag, although this is rarely needed. If creating the tag in the working copy of the tree, svn:mergeinfo results must be removed: &prompt.user; cd vendor/pf &prompt.user; svn cp dist 4.3 &prompt.user; svn propdel svn:mergeinfo -R 4.3 Merging to Head &prompt.user; cd head/contrib/pf &prompt.user; svn up &prompt.user; svn merge --accept=postpone svn+ssh://svn.freebsd.org/base/vendor/pf/dist . The --accept=postpone tells Subversion that it should not complain because merge conflicts will be taken care of manually. It is necessary to resolve any merge conflicts. This process is the same in SVN as in CVS. Make sure that any files that were added or removed in the vendor tree have been properly added or removed in the main tree. To check diffs against the vendor branch: &prompt.user; svn diff --no-diff-deleted --old=svn+ssh://svn.freebsd.org/base/vendor/pf/dist --new=. The --no-diff-deleted tells Subversion not to complain about files that are in the vendor tree but not in the main tree, i.e., things that would have previously been removed before the vendor import, like for example the vendor's makefiles and configure scripts. Using CVS, once a file was off the vendor branch, it was not able to be put back. With Subversion, there is no concept of on or off the vendor branch. If a file that previously had local modifications, to make it not show up in diffs in the vendor tree, all that has to be done is remove any left-over cruft like &os; version tags, which is much easier. If any changes are required for the world to build with the new sources, make them now, and keep testing until everything builds and runs perfectly. Committing the Vendor Import Committing is now possible! Everything must be committed in one go. If done properly, the tree will move from a consistent state with old code, to a consistent state with new code. From Scratch Importing into the Vendor Tree This section is an example of importing and tagging byacc into head. First, prepare the directory in vendor: &prompt.user; svn co --depth immediates $FSVN/vendor &prompt.user; cd vendor &prompt.user; svn mkdir byacc &prompt.user; svn mkdir byacc/dist Now, import the sources into the dist directory. Once the files are in place, svn add the new ones, then svn commit and tag the imported version. To save time and bandwidth, direct remote committing and tagging is possible: &prompt.user; svn cp -m "Tag byacc 20120115" $FSVN/vendor/byacc/dist $FSVN/vendor/byacc/20120115 Merging to <literal>head</literal> Due to this being a new file, copy it for the merge: &prompt.user; svn cp -m "Import byacc to contrib" $FSVN/vendor/byacc/dist $FSVN/head/contrib/byacc Working normally on newly imported sources is still possible. Reverting a Commit Reverting a commit to a previous version is fairly easy: &prompt.user; svn merge -r179454:179453 ROADMAP.txt &prompt.user; svn commit Change number syntax, with negative meaning a reverse change, can also be used: &prompt.user; svn merge -c -179454 ROADMAP.txt &prompt.user; svn commit This can also be done directly in the repository: &prompt.user; svn merge -r179454:179453 svn+ssh://svn.freebsd.org/base/ROADMAP.txt It is important to ensure that the mergeinfo is correct when reverting a file in order to permit svn mergeinfo --eligible to work as expected. Reverting the deletion of a file is slightly different. Copying the version of the file that predates the deletion is required. For example, to restore a file that was deleted in revision N, restore version N-1: &prompt.user; svn copy svn+ssh://svn.freebsd.org/base/ROADMAP.txt@179454 &prompt.user; svn commit or, equally: &prompt.user; svn copy svn+ssh://svn.freebsd.org/base/ROADMAP.txt@179454 svn+ssh://svn.freebsd.org/base Do not simply recreate the file manually and svn add it—this will cause history to be lost. Fixing Mistakes While we can do surgery in an emergency, do not plan on having mistakes fixed behind the scenes. Plan on mistakes remaining in the logs forever. Be sure to check the output of svn status and svn diff before committing. Mistakes will happen but, they can generally be fixed without disruption. Take a case of adding a file in the wrong location. The right thing to do is to svn move the file to the correct location and commit. This causes just a couple of lines of metadata in the repository journal, and the logs are all linked up correctly. The wrong thing to do is to delete the file and then svn add an independent copy in the correct location. Instead of a couple of lines of text, the repository journal grows an entire new copy of the file. This is a waste. Setting up a <application>svnsync</application> Mirror You probably do not want to do this unless there is a good reason for it. Such reasons might be to support many multiple local read-only client machines, or if your network bandwidth is limited. Starting a fresh mirror from empty would take a very long time. Expect a minimum of 10 hours for high speed connectivity. If you have international links, expect this to take 4 to 10 times longer. A far better option is to grab a seed file. It is large (~1GB) but will consume less network traffic and take less time to fetch than a svnsync will. This is possible in one of the following three ways: &prompt.user; rsync -va --partial --progress freefall:/home/peter/svnmirror-base-r179637.tbz2 . &prompt.user; rsync -va --partial --progress rsync://repoman.freebsd.org:50873/svnseed/svnmirror-base-r215629.tar.xz . &prompt.user; fetch ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/svnmirror-base-r221445.tar.xz Once you have the file, extract it to somewhere like home/svnmirror/base/. Then, update it, so that it fetches changes since the last revision in the archive: &prompt.user; svnsync sync file:///home/svnmirror/base You can then set that up to run from &man.cron.8;, do checkouts locally, set up a svnserve server for your local machines to talk to, etc. The seed mirror is set to fetch from svn://svn.freebsd.org/base. The configuration for the mirror is stored in revprop 0 on the local mirror. To see the configuration, try: &prompt.user; svn proplist -v --revprop -r 0 file:///home/svnmirror/base Use propset to change things. Committing High-<acronym>ASCII</acronym> Data Files that have high-ASCII bits are considered binary files in SVN, so the pre-commit checks fail and indicate that the mime-type property should be set to application/octet-stream. However, the use of this is discouraged, so please do not set it. The best way is always avoiding high-ASCII data, so that it can be read everywhere with any text editor but if it is not avoidable, instead of changing the mime-type, set the fbsd:notbinary property with propset: &prompt.user; svn propset fbsd:notbinary yes foo.data Maintaining a Project Branch A project branch is one that is synced to head (or another branch) is used to develop a project then commit it back to head. In SVN, dolphin branching is used for this. A dolphin branch is one that diverges for a while and is finally committed back to the original branch. During development code migration in one direction (from head to the branch only). No code is committed back to head until the end. Once you commit back at the end, the branch is dead (although you can have a new branch with the same name after you delete the branch if you want). As per http://people.freebsd.org/~peter/svn_notes.txt, work that is intended to be merged back into HEAD should be in base/projects/. If you are doing work that is beneficial to the &os; community in some way but not intended to be merged directly back into HEAD then the proper location is base/user/your-name/. This page contains further details. To create a project branch: &prompt.user; svn copy svn+ssh://svn.freebsd.org/base/head svn+ssh://svn.freebsd.org/base/projects/spif To merge changes from HEAD back into the project branch: &prompt.user; cd copy_of_spif &prompt.user; svn merge svn+ssh://svn.freebsd.org/base/head &prompt.user; svn commit It is important to resolve any merge conflicts before committing. Some Tips In commit logs etc., rev 179872 should be spelled r179872 as per convention. Do not remove and re-add the same file in a single commit as this will break the CVS exporter. Speeding up svn is possible by adding the following to ~/.ssh/config: Host * ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p ControlMaster auto ControlPersist yes and then typing mkdir ~/.ssh/sockets Checking out a working copy with a stock Subversion client without &os;-specific patches (OPTIONS_SET=FREEBSD_TEMPLATE) will mean that $FreeBSD$ tags will not be expanded. Once the correct version has been installed, trick Subversion into expanding them like so: &prompt.user; svn propdel -R svn:keywords . &prompt.user; svn revert -R . This will wipe out uncommitted patches. Conventions and Traditions As a new developer there are a number of things you should do first. The first set is specific to committers only. (If you are not a committer, e.g., have GNATS-only access, then your mentor needs to do these things for you.) Guidelines for Committers The .ent, .xml, and .xml files listed below exist in the &os; Documentation Project SVN repository at svn.FreeBSD.org/doc/. If you have been given commit rights to one or more of the repositories: Add your author entity to head/share/xml/authors.ent; this should be done first since an omission of this commit will cause the next commits to break the doc/ build. This is a relatively easy task, but remains a good first test of your version control skills. New files that do not have the FreeBSD=%H svn:keywords property will be rejected when attempting to commit them to the repository. Be sure to read regarding adding and removing files, in addition to verifying that ~/.subversion/config contains the necessary "auto-props" entries from auto-props.txt mentioned there. Do not forget to get mentor approval for these patches! Add yourself to the Developers section of the Contributors List (head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml) and remove yourself from the Additional Contributors section (head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml). Please note that entries are sorted by last name. Add an entry for yourself to head/share/xml/news.xml. Look for the other entries that look like A new committer and follow the format. You should add your PGP or GnuPG key to head/share/pgpkeys (and if you do not have a key, you should create one). Do not forget to commit the updated head/share/pgpkeys/pgpkeys.ent and head/share/pgpkeys/pgpkeys-developers.xml. Please note that entries are sorted by last name. &a.des.email; has written a shell script (head/share/pgpkeys/addkey.sh) to make this extremely simple. See the README file for more information. It is important to have an up-to-date PGP/GnuPG key in the Handbook, since the key may be required for positive identification of a committer, e.g., by the &a.admins; for account recovery. A complete keyring of FreeBSD.org users is available for download from http://www.FreeBSD.org/doc/pgpkeyring.txt. Add an entry for yourself to src/share/misc/committers-repository.dot, where repository is either doc, ports or src, depending on the commit privileges you obtained. Some people add an entry for themselves to ports/astro/xearth/files/freebsd.committers.markers. Some people add an entry for themselves to src/usr.bin/calendar/calendars/calendar.freebsd. If you already have an account at the &os; wiki, make sure your mentor moves you from the Contributors group to the Developers group. Otherwise, consider signing up for an account so you can publish projects and ideas you are working on. Once you get access to the wiki, you may add yourself to the How We Got Here and Irc Nicks pages. If you subscribe to &a.svn-src-all.name;, &a.svn-ports-all.name; or &a.svn-doc-all.name;, you will probably want to unsubscribe to avoid receiving duplicate copies of commit messages and their followups. All src commits should go to &os.current; first before being merged to &os.stable;. No major new features or high-risk modifications should be made to the &os.stable; branch. Guidelines for Everyone Whether or not you have commit rights: Introduce yourself to the other developers, otherwise no one will have any idea who you are or what you are working on. You do not have to write a comprehensive biography, just write a paragraph or two about who you are and what you plan to be working on as a developer in &os;. (You should also mention who your mentor will be). Email this to the &a.developers; and you will be on your way! Log into hub.FreeBSD.org and create a /var/forward/user (where user is your username) file containing the e-mail address where you want mail addressed to yourusername@FreeBSD.org to be forwarded. This includes all of the commit messages as well as any other mail addressed to the &a.committers; and the &a.developers;. Really large mailboxes which have taken up permanent residence on hub often get accidentally truncated without warning, so forward it or read it and you will not lose it. Due to the severe load dealing with SPAM places on the central mail servers that do the mailing list processing the front-end server does do some basic checks and will drop some messages based on these checks. At the moment proper DNS information for the connecting host is the only check in place but that may change. Some people blame these checks for bouncing valid email. If you want these checks turned off for your email you can place a file named .spam_lover in your home directory on freefall.FreeBSD.org to disable the checks for your email. If you are a developer but not a committer, you will not be subscribed to the committers or developers mailing lists; the subscriptions are derived from the access rights. Mentors All new developers also have a mentor assigned to them for the first few months. Your mentor is responsible for teaching you the rules and conventions of the project and guiding your first steps in the developer community. Your mentor is also personally responsible for your actions during this initial period. For committers: until your mentor decides (and announces with a forced commit to access) that you have learned the ropes and are ready to commit on your own, you should not commit anything without first getting your mentor's review and approval, and you should document that approval with an Approved by: line in the commit message. Preferred License for New Files Currently the &os; Project suggests and uses the following text as the preferred license scheme: /*- * Copyright (c) [year] [your name] * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``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 AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * [id for your version control system, if any] */ The &os; project strongly discourages the so-called "advertising clause" in new code. Due to the large number of contributors to the &os; project, complying with this clause for many commercial vendors has become difficult. If you have code in the tree with the advertising clause, please consider removing it. In fact, please consider using the above license for your code. The &os; project discourages completely new licenses and variations on the standard licenses. New licenses require the approval of the &a.core; to reside in the main repository. The more different licenses that are used in the tree, the more problems that this causes to those wishing to utilize this code, typically from unintended consequences from a poorly worded license. Project policy dictates that code under some non-BSD licenses must be placed only in specific sections of the repository, and in some cases, compilation must be conditional or even disabled by default. For example, the GENERIC kernel must be compiled under only licenses identical to or substantially similar to the BSD license. GPL, APSL, CDDL, etc, licensed software must not be compiled into GENERIC. Developers are reminded that in open source, getting "open" right is just as important as getting "source" right, as improper handling of intellectual property has serious consequences. Any questions or concerns should immediately be brought to the attention of the core team. Developer Relations If you are working directly on your own code or on code which is already well established as your responsibility, then there is probably little need to check with other committers before jumping in with a commit. If you see a bug in an area of the system which is clearly orphaned (and there are a few such areas, to our shame), the same applies. If, however, you are about to modify something which is clearly being actively maintained by someone else (and it is only by watching the repository-committers mailing list that you can really get a feel for just what is and is not) then consider sending the change to them instead, just as you would have before becoming a committer. For ports, you should contact the listed MAINTAINER in the Makefile. For other parts of the repository, if you are unsure who the active maintainer might be, it may help to scan the revision history to see who has committed changes in the past. &a.fenner.email; has written a nice shell script that can help determine who the active maintainer might be. It lists each person who has committed to a given file along with the number of commits each person has made. It can be found on freefall at ~fenner/bin/whodid. If your queries go unanswered or the committer otherwise indicates a lack of interest in the area affected, go ahead and commit it. If you are unsure about a commit for any reason at all, have it reviewed by -hackers before committing. Better to have it flamed then and there rather than when it is part of the repository. If you do happen to commit something which results in controversy erupting, you may also wish to consider backing the change out again until the matter is settled. Remember – with a version control system we can always change it back. Do not impugn the intentions of someone you disagree with. If they see a different solution to a problem than you, or even a different problem, it is not because they are stupid, because they have questionable parentage, or because they are trying to destroy your hard work, personal image, or &os;, but simply because they have a different outlook on the world. Different is good. Disagree honestly. Argue your position from its merits, be honest about any shortcomings it may have, and be open to seeing their solution, or even their vision of the problem, with an open mind. Accept correction. We are all fallible. When you have made a mistake, apologize and get on with life. Do not beat up yourself, and certainly do not beat up others for your mistake. Do not waste time on embarrassment or recrimination, just fix the problem and move on. Ask for help. Seek out (and give) peer reviews. One of the ways open source software is supposed to excel is in the number of eyeballs applied to it; this does not apply if nobody will review code. GNATS The &os; Project utilizes GNATS for tracking bugs and change requests. Be sure that if you commit a fix or suggestion found in a GNATS PR, you use edit-pr pr-number on freefall to close it. It is also considered nice if you take time to close any PRs associated with your commits, if appropriate. You can also make use of &man.send-pr.1; yourself for proposing any change which you feel should probably be made, pending a more extensive peer-review first. You can find out more about GNATS at: &os; Problem Report Handling Guidelines http://www.FreeBSD.org/support.html &man.send-pr.1; You can run a local copy of GNATS, and then integrate the &os; GNATS tree by creating an rsync mirror. Then you can run GNATS commands locally, allowing you to query the PR database without an Internet connection. Mirroring the GNATS Tree It is possible to mirror the GNATS database by installing net/rsync, and executing: &prompt.user; rsync -va rsync://bit0.us-west.freebsd.org/FreeBSD-bit/gnats . Useful Tools Other than edit-pr there are a collection of tools in ~gnats/tools/ on freefall which can make working with PRs much easier. open-pr, close-pr, take-pr, and feedback-pr take PR numbers as arguments and then ask you to select from a preexisting list of change reasons or let you type in your own. change-pr is a multi purpose tool that lets you make multiple changes at the same time with one command. For example, to assign PR 123456 to yourself type take-pr 123456. If you want to set the PR to patched awaiting an MFC at the same time use: change-pr -t -p -m "awaiting MFC" 123456 Who's Who Besides the repository meisters, there are other &os; project members and teams whom you will probably get to know in your role as a committer. Briefly, and by no means all-inclusively, these are: &a.doceng; doceng is the group responsible for the documentation build infrastructure, approving new documentation committers, and ensuring that the &os; website and documentation on the FTP site is up to date with respect to the CVS tree. It is not a conflict resolution body. The vast majority of documentation related discussion takes place on the &a.doc;. More details regarding the doceng team can be found in its charter. Committers interested in contributing to the documentation should familiarize themselves with the Documentation Project Primer. &a.ru.email; Ruslan is Mister &man.mdoc.7;. If you are writing a manual page and need some advice on the structure, or the markup, ask Ruslan. &a.bde.email; Bruce is the Style Police-Meister. When you do a commit that could have been done better, Bruce will be there to tell you. Be thankful that someone is. Bruce is also very knowledgeable on the various standards applicable to &os;. &a.re.members.email; These are the members of the &a.re;. This team is responsible for setting release deadlines and controlling the release process. During code freezes, the release engineers have final authority on all changes to the system for whichever branch is pending release status. If there is something you want merged from &os.current; to &os.stable; (whatever values those may have at any given time), these are the people to talk to about it. Hiroki is also the keeper of the release documentation (src/release/doc/*). If you commit a change that you think is worthy of mention in the release notes, please make sure he knows about it. Better still, send him a patch with your suggested commentary. &a.des.email; Dag-Erling is the &os; Security Officer and oversees the &a.security-officer;. &a.wollman.email; If you need advice on obscure network internals or are not sure of some potential change to the networking subsystem you have in mind, Garrett is someone to talk to. Garrett is also very knowledgeable on the various standards applicable to &os;. &a.committers; &a.svn-src-all.name;, &a.svn-ports-all.name; and &a.svn-doc-all.name; are the mailing lists that the version control system uses to send commit messages to. You should never send email directly to these lists. You should only send replies to this list when they are short and are directly related to a commit. &a.developers; All committers are subscribed to -developers. This list was created to be a forum for the committers community issues. Examples are Core voting, announcements, etc. The &a.developers; is for the exclusive use of &os; committers. In order to develop &os;, committers must have the ability to openly discuss matters that will be resolved before they are publicly announced. Frank discussions of work in progress are not suitable for open publication and may harm &os;. All &os; committers are reminded to obey the copyright of the original author(s) of &a.developers; mail. Do not publish or forward messages from the &a.developers; outside the list membership without permission of all of the authors. Copyright violators will be removed from the &a.developers;, resulting in a suspension of commit privileges. Repeated or flagrant violations may result in permanent revocation of commit privileges. This list is not intended as a place for code reviews or a replacement for the &a.arch;. In fact using it as such hurts the &os; Project as it gives a sense of a closed list where general decisions affecting all of the &os; using community are made without being open. Last, but not least never, never ever, email the &a.developers; and CC:/BCC: another &os; list. Never, ever email another &os; email list and CC:/BCC: the &a.developers;. Doing so can greatly diminish the benefits of this list. SSH Quick-Start Guide If you do not wish to type your password in every time you use &man.ssh.1;, and you use RSA or DSA keys to authenticate, &man.ssh-agent.1; is there for your convenience. If you want to use &man.ssh-agent.1;, make sure that you run it before running other applications. X users, for example, usually do this from their .xsession or .xinitrc. See &man.ssh-agent.1; for details. Generate a key pair using &man.ssh-keygen.1;. The key pair will wind up in your $HOME/.ssh/ directory. Send your public key ($HOME/.ssh/id_dsa.pub or $HOME/.ssh/id_rsa.pub) to the person setting you up as a committer so it can be put into the yourlogin file in /etc/ssh-keys/ on freefall. Now you should be able to use &man.ssh-add.1; for authentication once per session. This will prompt you for your private key's pass phrase, and then store it in your authentication agent (&man.ssh-agent.1;). If you no longer wish to have your key stored in the agent, issuing ssh-add -d will remove it. Test by doing something such as ssh freefall.FreeBSD.org ls /usr. For more information, see security/openssh, &man.ssh.1;, &man.ssh-add.1;, &man.ssh-agent.1;, &man.ssh-keygen.1;, and &man.scp.1;. &coverity.prevent; Availability for &os; Committers In January 2006, the &os; Foundation obtained a license for &coverity.prevent; from &coverity; Ltd. With this donation, all &os; developers can obtain access to Coverity Prevent analysis results of all &os; Project software. &os; developers who are interested in obtaining access to the analysis results of the automated Coverity Prevent runs, can find out more by logging into freefall and reading the relevant bits of the files: /usr/local/coverity/coverity_license.txt The license terms to which the &os; developers will have to agree in order to use &coverity.prevent; analysis results. /usr/local/coverity/coverity_announcement.txt The announcement posted to the developers' mailing list of the &os; Project. It contains useful information about the &os; Foundation and &coverity; Ltd., as well as signup information for registering with the &coverity.prevent; installation of the &os; Cluster. After reading and understanding the license terms of coverity_license.txt, all &os; developers who are interested in using the analysis results of &coverity.prevent; should read this file. /usr/local/coverity/coverity_readme.txt A short guide about fixes which are committed to the &os; source tree after being detected by &coverity.prevent; and analyzed by a &os; developer. The &os; Wiki includes a mini-guide for developers who are interested in working with the &coverity.prevent; analysis reports: . Please note that this mini-guide is only readable by &os; developers, so if you cannot access this page, you will have to ask someone to add you to the appropriate Wiki access list. Finally, all &os; developers who are going to use &coverity.prevent; are always encouraged to ask for more details and usage information, by posting any questions to the mailing list of the &os; developers. The &os; Committers' Big List of Rules Respect other committers. Respect other contributors. Discuss any significant change before committing. Respect existing maintainers (if listed in the MAINTAINER field in Makefile or in the MAINTAINER file in the top-level directory). Any disputed change must be backed out pending resolution of the dispute if requested by a maintainer. Security related changes may override a maintainer's wishes at the Security Officer's discretion. Changes go to &os.current; before &os.stable; unless specifically permitted by the release engineer or unless they are not applicable to &os.current;. Any non-trivial or non-urgent change which is applicable should also be allowed to sit in &os.current; for at least 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the &os.stable; branch as outlined for the maintainer in rule #5. Do not fight in public with other committers; it looks bad. If you must strongly disagree about something, do so only in private. Respect all code freezes and read the committers and developers mailing lists in a timely manner so you know when a code freeze is in effect. When in doubt on any procedure, ask first! Test your changes before committing them. Do not commit to anything under the src/contrib, src/crypto, or src/sys/contrib trees without explicit approval from the respective maintainer(s). As noted, breaking some of these rules can be grounds for suspension or, upon repeated offense, permanent removal of commit privileges. Individual members of core have the power to temporarily suspend commit privileges until core as a whole has the chance to review the issue. In case of an emergency (a committer doing damage to the repository), a temporary suspension may also be done by the repository meisters. Only a 2/3 majority of core has the authority to suspend commit privileges for longer than a week or to remove them permanently. This rule does not exist to set core up as a bunch of cruel dictators who can dispose of committers as casually as empty soda cans, but to give the project a kind of safety fuse. If someone is out of control, it is important to be able to deal with this immediately rather than be paralyzed by debate. In all cases, a committer whose privileges are suspended or revoked is entitled to a hearing by core, the total duration of the suspension being determined at that time. A committer whose privileges are suspended may also request a review of the decision after 30 days and every 30 days thereafter (unless the total suspension period is less than 30 days). A committer whose privileges have been revoked entirely may request a review after a period of 6 months has elapsed. This review policy is strictly informal and, in all cases, core reserves the right to either act on or disregard requests for review if they feel their original decision to be the right one. In all other aspects of project operation, core is a subset of committers and is bound by the same rules. Just because someone is in core this does not mean that they have special dispensation to step outside any of the lines painted here; core's special powers only kick in when it acts as a group, not on an individual basis. As individuals, the core team members are all committers first and core second. Details Respect other committers. This means that you need to treat other committers as the peer-group developers that they are. Despite our occasional attempts to prove the contrary, one does not get to be a committer by being stupid and nothing rankles more than being treated that way by one of your peers. Whether we always feel respect for one another or not (and everyone has off days), we still have to treat other committers with respect at all times, on public forums and in private email. Being able to work together long term is this project's greatest asset, one far more important than any set of changes to the code, and turning arguments about code into issues that affect our long-term ability to work harmoniously together is just not worth the trade-off by any conceivable stretch of the imagination. To comply with this rule, do not send email when you are angry or otherwise behave in a manner which is likely to strike others as needlessly confrontational. First calm down, then think about how to communicate in the most effective fashion for convincing the other person(s) that your side of the argument is correct, do not just blow off some steam so you can feel better in the short term at the cost of a long-term flame war. Not only is this very bad energy economics, but repeated displays of public aggression which impair our ability to work well together will be dealt with severely by the project leadership and may result in suspension or termination of your commit privileges. The project leadership will take into account both public and private communications brought before it. It will not seek the disclosure of private communications, but it will take it into account if it is volunteered by the committers involved in the complaint. All of this is never an option which the project's leadership enjoys in the slightest, but unity comes first. No amount of code or good advice is worth trading that away. Respect other contributors. You were not always a committer. At one time you were a contributor. Remember that at all times. Remember what it was like trying to get help and attention. Do not forget that your work as a contributor was very important to you. Remember what it was like. Do not discourage, belittle, or demean contributors. Treat them with respect. They are our committers in waiting. They are every bit as important to the project as committers. Their contributions are as valid and as important as your own. After all, you made many contributions before you became a committer. Always remember that. Consider the points raised under and apply them also to contributors. Discuss any significant change before committing. The repository is not where changes should be initially submitted for correctness or argued over, that should happen first in the mailing lists and the commit should only happen once something resembling consensus has been reached. This does not mean that you have to ask permission before correcting every obvious syntax error or manual page misspelling, simply that you should try to develop a feel for when a proposed change is not quite such a no-brainer and requires some feedback first. People really do not mind sweeping changes if the result is something clearly better than what they had before, they just do not like being surprized by those changes. The very best way of making sure that you are on the right track is to have your code reviewed by one or more other committers. When in doubt, ask for review! Respect existing maintainers if listed. Many parts of &os; are not owned in the sense that any specific individual will jump up and yell if you commit a change to their area, but it still pays to check first. One convention we use is to put a maintainer line in the Makefile for any package or subtree which is being actively maintained by one or more people; see http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/policies.html for documentation on this. Where sections of code have several maintainers, commits to affected areas by one maintainer need to be reviewed by at least one other maintainer. In cases where the maintainer-ship of something is not clear, you can also look at the repository logs for the file(s) in question and see if someone has been working recently or predominantly in that area. Other areas of &os; fall under the control of someone who manages an overall category of &os; evolution, such as internationalization or networking. See http://www.FreeBSD.org/administration.html for more information on this. Any disputed change must be backed out pending resolution of the dispute if requested by a maintainer. Security related changes may override a maintainer's wishes at the Security Officer's discretion. This may be hard to swallow in times of conflict (when each side is convinced that they are in the right, of course) but a version control system makes it unnecessary to have an ongoing dispute raging when it is far easier to simply reverse the disputed change, get everyone calmed down again and then try to figure out what is the best way to proceed. If the change turns out to be the best thing after all, it can be easily brought back. If it turns out not to be, then the users did not have to live with the bogus change in the tree while everyone was busily debating its merits. People very rarely call for back-outs in the repository since discussion generally exposes bad or controversial changes before the commit even happens, but on such rare occasions the back-out should be done without argument so that we can get immediately on to the topic of figuring out whether it was bogus or not. Changes go to &os.current; before &os.stable; unless specifically permitted by the release engineer or unless they are not applicable to &os.current;. Any non-trivial or non-urgent change which is applicable should also be allowed to sit in &os.current; for at least 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the &os.stable; branch as outlined in rule #5. This is another do not argue about it issue since it is the release engineer who is ultimately responsible (and gets beaten up) if a change turns out to be bad. Please respect this and give the release engineer your full cooperation when it comes to the &os.stable; branch. The management of &os.stable; may frequently seem to be overly conservative to the casual observer, but also bear in mind the fact that conservatism is supposed to be the hallmark of &os.stable; and different rules apply there than in &os.current;. There is also really no point in having &os.current; be a testing ground if changes are merged over to &os.stable; immediately. Changes need a chance to be tested by the &os.current; developers, so allow some time to elapse before merging unless the &os.stable; fix is critical, time sensitive or so obvious as to make further testing unnecessary (spelling fixes to manual pages, obvious bug/typo fixes, etc.) In other words, apply common sense. Changes to the security branches (for example, RELENG_7_0) must be approved by a member of the &a.security-officer;, or in some cases, by a member of the &a.re;. Do not fight in public with other committers; it looks bad. If you must strongly disagree about something, do so only in private. This project has a public image to uphold and that image is very important to all of us, especially if we are to continue to attract new members. There will be occasions when, despite everyone's very best attempts at self-control, tempers are lost and angry words are exchanged. The best thing that can be done in such cases is to minimize the effects of this until everyone has cooled back down. That means that you should not air your angry words in public and you should not forward private correspondence to public mailing lists or aliases. What people say one-to-one is often much less sugar-coated than what they would say in public, and such communications therefore have no place there - they only serve to inflame an already bad situation. If the person sending you a flame-o-gram at least had the grace to send it privately, then have the grace to keep it private yourself. If you feel you are being unfairly treated by another developer, and it is causing you anguish, bring the matter up with core rather than taking it public. Core will do its best to play peace makers and get things back to sanity. In cases where the dispute involves a change to the codebase and the participants do not appear to be reaching an amicable agreement, core may appoint a mutually-agreeable 3rd party to resolve the dispute. All parties involved must then agree to be bound by the decision reached by this 3rd party. Respect all code freezes and read the committers and developers mailing list on a timely basis so you know when a code freeze is in effect. Committing unapproved changes during a code freeze is a really big mistake and committers are expected to keep up-to-date on what is going on before jumping in after a long absence and committing 10 megabytes worth of accumulated stuff. People who abuse this on a regular basis will have their commit privileges suspended until they get back from the &os; Happy Reeducation Camp we run in Greenland. When in doubt on any procedure, ask first! Many mistakes are made because someone is in a hurry and just assumes they know the right way of doing something. If you have not done it before, chances are good that you do not actually know the way we do things and really need to ask first or you are going to completely embarrass yourself in public. There is no shame in asking how in the heck do I do this? We already know you are an intelligent person; otherwise, you would not be a committer. Test your changes before committing them. This may sound obvious, but if it really were so obvious then we probably would not see so many cases of people clearly not doing this. If your changes are to the kernel, make sure you can still compile both GENERIC and LINT. If your changes are anywhere else, make sure you can still make world. If your changes are to a branch, make sure your testing occurs with a machine which is running that code. If you have a change which also may break another architecture, be sure and test on all supported architectures. Please refer to the &os; Internal Page for a list of available resources. As other architectures are added to the &os; supported platforms list, the appropriate shared testing resources will be made available. Do not commit to anything under the src/contrib, src/crypto, and src/sys/contrib trees without explicit approval from the respective maintainer(s). The trees mentioned above are for contributed software usually imported onto a vendor branch. Committing something there, even if it does not take the file off the vendor branch, may cause unnecessary headaches for those responsible for maintaining that particular piece of software. Thus, unless you have explicit approval from the maintainer (or you are the maintainer), do not commit there! Please note that this does not mean you should not try to improve the software in question; you are still more than welcome to do so. Ideally, you should submit your patches to the vendor. If your changes are &os;-specific, talk to the maintainer; they may be willing to apply them locally. But whatever you do, do not commit there by yourself! Contact the &a.core; if you wish to take up maintainership of an unmaintained part of the tree. Policy on Multiple Architectures &os; has added several new architecture ports during recent release cycles and is truly no longer an &i386; centric operating system. In an effort to make it easier to keep &os; portable across the platforms we support, core has developed the following mandate:
Our 32-bit reference platform is &arch.i386;, and our 64-bit reference platform is &arch.sparc64;. Major design work (including major API and ABI changes) must prove itself on at least one 32-bit and at least one 64-bit platform, preferably the primary reference platforms, before it may be committed to the source tree.
The &arch.i386; and &arch.sparc64; platforms were chosen due to being more readily available to developers and as representatives of more diverse processor and system designs - big versus little endian, register file versus register stack, different DMA and cache implementations, hardware page tables versus software TLB management etc. The &arch.ia64; platform has many of the same complications that &arch.sparc64; has, but is still limited in availability to developers. We will continue to re-evaluate this policy as cost and availability of the 64-bit platforms change. Developers should also be aware of our Tier Policy for the long term support of hardware architectures. The rules here are intended to provide guidance during the development process, and are distinct from the requirements for features and architectures listed in that section. The Tier rules for feature support on architectures at release-time are more strict than the rules for changes during the development process.
Other Suggestions When committing documentation changes, use a spell checker before committing. For all SGML docs, you should also verify that your formatting directives are correct by running make lint. For all on-line manual pages, run manck (from ports) over the manual page to verify all of the cross references and file references are correct and that the man page has all of the appropriate MLINKs installed. Do not mix style fixes with new functionality. A style fix is any change which does not modify the functionality of the code. Mixing the changes obfuscates the functionality change when asking for differences between revisions, which can hide any new bugs. Do not include whitespace changes with content changes in commits to doc/ or www/. The extra clutter in the diffs makes the translators' job much more difficult. Instead, make any style or whitespace changes in separate commits that are clearly labeled as such in the commit message. Deprecating Features When it is necessary to remove functionality from software in the base system the following guidelines should be followed whenever possible: Mention is made in the manual page and possibly the release notes that the option, utility, or interface is deprecated. Use of the deprecated feature generates a warning. The option, utility, or interface is preserved until the next major (point zero) release. The option, utility, or interface is removed and no longer documented. It is now obsolete. It is also generally a good idea to note its removal in the release notes.
Support for Multiple Architectures &os; is a highly portable operating system intended to function on many different types of hardware architectures. Maintaining clean separation of Machine Dependent (MD) and Machine Independent (MI) code, as well as minimizing MD code, is an important part of our strategy to remain agile with regards to current hardware trends. Each new hardware architecture supported by &os; adds substantially to the cost of code maintenance, toolchain support, and release engineering. It also dramatically increases the cost of effective testing of kernel changes. As such, there is strong motivation to differentiate between classes of support for various architectures while remaining strong in a few key architectures that are seen as the &os; target audience. Statement of General Intent The &os; Project targets "production quality commercial off-the-shelf (COTS) workstation, server, and high-end embedded systems". By retaining a focus on a narrow set of architectures of interest in these environments, the &os; Project is able to maintain high levels of quality, stability, and performance, as well as minimize the load on various support teams on the project, such as the ports team, documentation team, security officer, and release engineering teams. Diversity in hardware support broadens the options for &os; consumers by offering new features and usage opportunities (such as support for 64-bit CPUs, use in embedded environments, etc.), but these benefits must always be carefully considered in terms of the real-world maintenance cost associated with additional platform support. The &os; Project differentiates platform targets into four tiers. Each tier includes a specification of the requirements for an architecture to be in that tier, as well as specifying the obligations of developers with regards to the platform. In addition, a policy is defined regarding the circumstances required to change the tier of an architecture. Tier 1: Fully Supported Architectures Tier 1 platforms are fully supported by the security officer, release engineering, and toolchain maintenance staff. New features added to the operating system must be fully functional across all Tier 1 architectures for every release (features which are inherently architecture-specific, such as support for hardware device drivers, may be exempt from this requirement). In general, all Tier 1 platforms must have build and Tinderbox support either in the FreeBSD.org cluster, or be easily available for all developers. Embedded platforms may substitute an emulator available in the &os; cluster for actual hardware. Tier 1 architectures are expected to be Production Quality with respects to all aspects of the &os; operating system, including installation and development environments. Tier 1 architectures are expected to be completely integrated into the source tree and have all features necessary to produce an entire system relevant for that target architecture. Tier 1 architectures generally have at least 6 active developers. Tier 1 architectures are expected to be fully supported by the ports system. All the ports should build on a Tier 1 platform, or have the appropriate filters to prevent the inappropriate ones from building there. The packaging system must support all Tier 1 architectures. To ensure an architecture's Tier 1 status, proponents of that architecture must show that all relevant packages can be built on that platform. Tier 1 embedded architectures must be able to cross-build packages on at least one other Tier 1 architecture. The packages must be the most relevant for the platform, but may be a non-empty subset of those that build natively. Tier 1 architectures must be fully documented. All basic operations need to be covered by the handbook or other documents. All relevant integration documentation must also be integrated into the tree, or readily available. Current Tier 1 platforms are &arch.i386; and &arch.amd64;. Tier 2: Developmental Architectures Tier 2 platforms are not supported by the security officer and release engineering teams. Platform maintainers are responsible for toolchain support in the tree. The toolchain maintainer is expected to work with the platform maintainers to refine these changes. Major new toolchain components are allowed to break support for Tier 2 architectures if the &os;-local changes have not been incorporated upstream. The toolchain maintainers are expected to provide prompt review of any proposed changes and cannot block, through their inaction, changes going into the tree. New features added to &os; should be feasible to implement on these platforms, but an implementation is not required before the feature may be added to the &os; source tree. New features that may be difficult to implement on Tier 2 architectures should provide a means of disabling them on those architectures. The implementation of a Tier 2 architecture may be committed to the main &os; tree as long as it does not interfere with production work on Tier 1 platforms, or substantially with other Tier 2 platforms. Before a Tier 2 platform can be added to the &os; base source tree, the platform must be able to boot multi-user on actual hardware. Generally, there must be at least three active developers working on the platform. Tier 2 architectures are usually systems targeted at Tier 1 support, but that are still under development. Architectures reaching end of life may also be moved from Tier 1 status to Tier 2 status as the availability of resources to continue to maintain the system in a Production Quality state diminishes. Well supported niche architectures may also be Tier 2. Tier 2 architectures may have some support for them integrated into the ports infrastructure. They may have cross compilation support added, at the discretion of portmgr. Some ports must built natively into packages if the package system supports that architecture. If not integrated into the base system, some external patches for the architecture for ports must be available. Tier 2 architectures can be integrated into the &os; handbook. The basics for how to get a system running must be documented, although not necessarily for every single board or system a Tier 2 architecture supports. The supported hardware list must exist and should be no more than a couple of months old. It should be integrated into the &os; documentation. Current Tier 2 platforms are &arch.arm;, &arch.ia64;, &arch.pc98;, &arch.powerpc;, and &arch.sparc64;. Tier 3: Experimental Architectures Tier 3 platforms are not supported by the security officer and release engineering teams. At the discretion of the toolchain maintainer, they may be supported in the toolchain. Tier 3 platforms are architectures in the early stages of development, for non-mainstream hardware platforms, or which are considered legacy systems unlikely to see broad future use. New Tier 3 systems will not be committed to the base source tree. Support for Tier 3 systems may be worked on in the &os; Perforce Repository, providing source control and easier change integration from the main &os; tree. Platforms that transition to Tier 3 status may be removed from the tree if they are no longer actively supported by the &os; developer community at the discretion of the release engineer. Tier 3 platforms may have ports support, either integrated or external, but do not require it. Tier 3 platforms must have the basics documented for how to build a kernel and how to boot it on at least one target hardware or emulation environment. This documentation need not be integrated into the &os; tree. Current Tier 3 platforms are &arch.mips; and &s390;. Tier 4: Unsupported Architectures Tier 4 systems are not supported in any form by the project. All systems not otherwise classified into a support tier are Tier 4 systems. Policy on Changing the Tier of an Architecture Systems may only be moved from one tier to another by approval of the &os; Core Team, which shall make that decision in collaboration with the Security Officer, Release Engineering, and toolchain maintenance teams. Ports Specific FAQ Adding a New Port How do I add a new port? First, please read the section about repository copies. The easiest way to add a new port is to use the addport script from your machine (located in the ports/Tools/scripts directory). It will add a port from the directory you specify, determining the category automatically from the port Makefile. It will also add an entry to the port's category Makefile. It was written by &a.mharo.email;, &a.will.email;, and &a.garga.email;. When sending questions about this script to the &a.ports;, please also CC &a.crees.email;, the current maintainer. Any other things I need to know when I add a new port? Check the port, preferably to make sure it compiles and packages correctly. This is the recommended sequence: &prompt.root; make install &prompt.root; make package &prompt.root; make deinstall &prompt.root; pkg_add package you built above &prompt.root; make deinstall &prompt.root; make reinstall &prompt.root; make package The Porters Handbook contains more detailed instructions. Use &man.portlint.1; to check the syntax of the port. You do not necessarily have to eliminate all warnings but make sure you have fixed the simple ones. If the port came from a submitter who has not contributed to the Project before, add that person's name to the Additional Contributors section of the &os; Contributors List. Close the PR if the port came in as a PR. To close a PR, just do edit-pr PR# on freefall and change the state from open to closed. You will be asked to enter a log message and then you are done. Removing an Existing Port How do I remove an existing port? First, please read the section about repository copies. Before you remove the port, you have to verify there are no other ports depending on it. Make sure there is no dependency on the port in the ports collection: The port's PKGNAME should appear in exactly one line in a recent INDEX file. No other ports should contain any reference to the port's directory or PKGNAME in their Makefiles Then, remove the port: Remove the port's files and directory with svn remove. Remove the SUBDIR listing of the port in the parent directory Makefile. Add an entry to ports/MOVED. Remove the port from ports/LEGAL if it is there. Alternatively, you can use the rmport script, from ports/Tools/scripts. This script was written by &a.vd.email;. When sending questions about this script to the &a.ports;, please also CC &a.crees.email;, the current maintainer. Re-adding a Deleted Port How do I re-add a deleted port? This is essentially the reverse of deleting a port. Figure out when the port was removed. Use this list and then copy the last living revision of the port: &prompt.user; cd /usr/ports/category &prompt.user; svn cp 'svn+ssh://svn.freebsd.org/ports/category/portname/@{YYYY-MM-DD}' portname Pick a date that is before the removal but after the last true commit. Perform whatever changes are necessary to make the port work again. If it was deleted because the distfiles are no longer available you will need to volunteer to host them yourself, or find someone else to do so. svn add or svn remove any appropriate files. Restore the SUBDIR listing of the port in the parent directory Makefile, and delete the entry from ports/MOVED. If the port had an entry in ports/LEGAL, restore it. svn commit these changes, preferably in one step. addport now detects when the port to add has previously existed, and should handle all except the ports/LEGAL step automatically. Repository Copies When do we need a repository copy? When you want to add a port that is related to any port that is already in the tree in a separate directory, you have to do a repository copy. Here related means it is a different version or a slightly modified version. Examples are print/ghostscript* (different versions) and x11-wm/windowmaker* (English-only and internationalized version). Another example is when a port is moved from one subdirectory to another, or when you want to change the name of a directory because the author(s) renamed their software even though it is a descendant of a port already in a tree. What do I need to do? With Subversion, a repo copy can be done by any committer: Doing a repo copy: First make sure that you were using an up to date ports tree and the target directory does not exist. Use svn move or svn copy to do the repo copy. Upgrade the copied port to the new version. Remember to change the LATEST_LINK so there are no duplicate ports with the same name. In some rare cases it may be necessary to change the PORTNAME instead of LATEST_LINK, but this should only be done when it is really needed — e.g., using an existing port as the base for a very similar program with a different name, or upgrading a port to a new upstream version which actually changes the distribution name, like the transition from textproc/libxml to textproc/libxml2. In most cases, changing LATEST_LINK should suffice. Add the new subdirectory to the SUBDIR listing in the parent directory Makefile. You can run make checksubdirs in the parent directory to check this. If the port changed categories, modify the CATEGORIES line of the port's Makefile accordingly Add an entry to ports/MOVED, if you remove the original port. Commit all changes on one commit. A forced commit is no longer needed with Subversion. When removing a port: Perform a thorough check of the ports collection for any dependencies on the old port location/name, and update them. Running grep on INDEX is not enough because some ports have dependencies enabled by compile-time options. A full grep -r of the ports collection is recommended. Remove the old port and the old SUBDIR entry. Add an entry to ports/MOVED. After repo moves (rename operations where a port is copied and the old location is removed): Follow the same steps that are outlined in the previous two entries, to activate the new location of the port and remove the old one. Ports Freeze What is a ports freeze? Before a release, it is necessary to restrict commits to the ports tree for a short period of time while the packages and the release itself are being built. This is to ensure consistency among the various parts of the release, and is called the ports freeze. For more information on the background and policies surrounding a ports freeze, see the Portmgr Quality Assurance page. What is a ports slush or feature freeze? During a release cycle the ports tree may be in a slush state instead of in a hard freeze. The goal during a slush is to reach a stable ports tree to avoid rebuilding large sets of packages for the release and to tag the tree. During this time sweeping changes are prohibited unless specifically permitted by portmgr. Complete details about what qualifies as a sweeping change can be found on the Portmgr Implementation page. The benefit of a slush as opposed to a complete freeze is that it allows maintainers to continue adding new ports, making routine version updates, and bug fixes to most existing ports, as long as the number of affected ports is minimal. For example, updating the shared library version on a port that many other ports depend on. How long is a ports freeze or slush? A freeze only lasts long enough to tag the tree. A slush usually lasts a week or two, but may last longer. What does it mean to me? During a ports freeze, you are not allowed to commit anything to the tree without explicit approval from the Ports Management Team. Explicit approval here means that you send a patch to the Ports Management Team for review and get a reply saying, Go ahead and commit it. Not everything is allowed to be committed during a freeze. Please see the Portmgr Quality Assurance page for more information. Note that you do not have implicit permission to fix a port during the freeze just because it is broken. During a ports slush, you are still allowed to commit but you must exercise more caution in what you commit. Furthermore a special note (typically Feature Safe: yes) must be added to the commit message. How do I know when the ports slush starts? The Ports Management Team will send out warning messages to the &a.ports; and &a.committers; announcing the start of the impending release, usually two or three weeks in advance. The exact starting time will not be determined until a few days before the actual release. This is because the ports slush has to be synchronized with the release, and it is usually not known until then when exactly the release will be rolled. When the slush starts, there will be another announcement to the &a.ports; and &a.committers;, of course. How do I know when the freeze or slush ends? A few hours after the release, the Ports Management Team will send out a mail to the &a.ports; and &a.committers; announcing the end of the ports freeze or slush. Note that the release being cut does not automatically indicate the end of the freeze. We have to make sure there will be no last minute snafus that result in an immediate re-rolling of the release. Creating a New Category What is the procedure for creating a new category? Please see Proposing a New Category in the Porter's Handbook. Once that procedure has been followed and the PR has been assigned to &a.portmgr;, it is their decision whether or not to approve it. If they do, it is their responsibility to do the following: Perform any needed moves. (This only applies to physical categories.) Update the VALID_CATEGORIES definition in ports/Mk/bsd.port.mk. Assign the PR back to you. What do I need to do to implement a new physical category? Upgrade each moved port's Makefile. Do not connect the new category to the build yet. To do this, you will need to: Change the port's CATEGORIES (this was the point of the exercise, remember?) The new category should be listed first. This will help to ensure that the PKGORIGIN is correct. Run a make describe. Since the top-level make index that you will be running in a few steps is an iteration of make describe over the entire ports hierarchy, catching any errors here will save you having to re-run that step later on. If you want to be really thorough, now might be a good time to run &man.portlint.1;. Check that the PKGORIGINs are correct. The ports system uses each port's CATEGORIES entry to create its PKGORIGIN, which is used to connect installed packages to the port directory they were built from. If this entry is wrong, common port tools like &man.pkg.version.1; and &man.portupgrade.1; fail. To do this, use the chkorigin.sh tool, as follows: env PORTSDIR=/path/to/ports sh -e /path/to/ports/Tools/scripts/chkorigin.sh. This will check every port in the ports tree, even those not connected to the build, so you can run it directly after the move operation. Hint: do not forget to look at the PKGORIGINs of any slave ports of the ports you just moved! On your own local system, test the proposed changes: first, comment out the SUBDIR entries in the old ports' categories' Makefiles; then enable building the new category in ports/Makefile. Run make checksubdirs in the affected category directories to check the SUBDIR entries. Next, in the ports/ directory, run make index. This can take over 40 minutes on even modern systems; however, it is a necessary step to prevent problems for other people. Once this is done, you can commit the updated ports/Makefile to connect the new category to the build and also commit the Makefile changes for the old category or categories. Add appropriate entries to ports/MOVED. Update the documentation by modifying the following: the list of categories in the Porter's Handbook www/en/ports/categories. Note that these are now displayed by sub-groups, as specified in www/en/ports/categories.descriptions. (Note: these are in the docs, not the ports, repository). If you are not a docs committer, you will need to submit a PR for this. Only once all the above have been done, and no one is any longer reporting problems with the new ports, should the old ports be deleted from their previous locations in the repository. It is not necessary to manually update the ports web pages to reflect the new category. This is now done automatically via your change to www/en/ports/categories and the daily automated rebuild of INDEX. What do I need to do to implement a new virtual category? This is much simpler than a physical category. You only need to modify the following: the list of categories in the Porter's Handbook www/en/ports/categories Miscellaneous Questions How do I know if my port is building correctly or not? First, go check . There you will find error logs from the latest package building runs on all supported platforms for the most recent branches. However, just because the port does not show up there does not mean it is building correctly. (One of the dependencies may have failed, for instance.) The relevant directories are available on pointyhat under /a/portbuild/<arch>/<major_version> so feel free to dig around. Each architecture and version has the following subdirectories: errors error logs from latest <major_version> run on <arch> logs all logs from latest <major_version> run on <arch> packages packages from latest <major_version> run on <arch> bak/errors error logs from last complete <major_version> run on <arch> bak/logs all logs from last complete <major_version> run on <arch> bak/packages packages from last complete <major_version> run on <arch> Basically, if the port shows up in packages, or it is in logs but not in errors, it built fine. (The errors directories are what you get from the web page.) I added a new port. Do I need to add it to the INDEX? No, INDEX is no longer stored in the SVN repository. The file can either be generated by running make index, or a pre-generated version can be downloaded with make fetchindex. Are there any other files I am not allowed to touch? Any file directly under ports/, or any file under a subdirectory that starts with an uppercase letter (Mk/, Tools/, etc.). In particular, the Ports Management Team is very protective of ports/Mk/bsd.port*.mk so do not commit changes to those files unless you want to face his wra(i)th. What is the proper procedure for updating the checksum for a port's distfile when the file changes without a version change? When the checksum for a port's distfile is updated due to the author updating the file without changing the port's revision, the commit message should include a summary of the relevant diffs between the original and new distfile to ensure that the distfile has not been corrupted or maliciously altered. If the current version of the port has been in the ports tree for a while, a copy of the old distfile will usually be available on the ftp servers; otherwise the author or maintainer should be contacted to find out why the distfile has changed. Issues Specific to Developers Who Are Not Committers A few people who have access to the &os; machines do not have commit bits. For instance, the project is willing to give access to the GNATS database to contributors who have shown interest and dedication in working on Problem Reports. Almost all of this document will apply to these developers as well (except things specific to commits and the mailing list memberships that go with them). In particular, we recommend that you read: Administrative Details Conventions You should get your mentor to add you to the Additional Contributors (doc/en_US.ISO8859-1/articles/contributors/contrib.additional.xml), if you are not already listed there. Developer Relations SSH Quick-Start Guide The &os; Committers' Big List of Rules Information About &ga; As of December 12, 2012, &ga; was enabled on the &os; Project website to collect anonymized usage statistics regarding usage of the site. The information collected is valuable to the &os; Documentation Project, in order to identify various problems on the &os; website. &ga; General Policy The &os; Project takes visitor privacy very seriously. As such, the &os; Project website honors the Do Not Track header before fetching the tracking code from Google. For more information, please see the &os; Privacy Policy. &ga; access is not arbitrarily allowed — access must be requested, voted on by the &a.doceng;, and explicitly granted. Requests for &ga; data must include a specific purpose. For example, a valid reason for requesting access would be to see the most frequently used web browsers when viewing &os; web pages to ensure page rendering speeds are acceptable. Conversely, to see what web browsers are most frequently used (without stating why) would be rejected. All requests must include the timeframe for which the data would be required. For example, it must be explicitly stated if the requested data would be needed for a timeframe covering a span of 3 weeks, or if the request would be one-time only. Any request for &ga; data without a clear, reasonable reason beneficial to the &os; Project will be rejected. Data Available Through &ga; A few examples of the types of &ga; data available include: Commonly used web browsers Page load times Site access by language Perks of the Job Unfortunately, there are not many perks involved with being a committer. Recognition as a competent software engineer is probably the only thing that will be of benefit in the long run. However, there are at least some perks: Free 4-CD and DVD Sets &os; committers can get a free 4-CD or DVD set at conferences from &os; Mall, Inc.. The sets are no longer available as a subscription due to the high shipment costs to countries outside the USA. Freenode IRC Cloaks &os; developers may request a cloaked hostmask for their account on the Freenode IRC network in the form of freebsd/developer/freefall name or freebsd/developer/NickServ name. To request a cloak, send an email to &a.eadler.email; with your requested hostmask and NickServ account name. Miscellaneous Questions Why are trivial or cosmetic changes to files on a vendor branch a bad idea? From now on, every new vendor release of that file will need to have patches merged in by hand. From now on, every new vendor release of that file will need to have patches verified by hand. How do I add a new file to a branch? To add a file onto a branch, simply checkout or update to the branch you want to add to and then add the file using the add operation as you normally would. This works fine for the doc and ports trees. The src tree uses SVN and requires more care because of the mergeinfo properties. See section 1.4.6 of the Subversion Primer for details. Refer to SubversionPrimer/Merging for details on how to perform an MFC. What meta information should I include in a commit message? As well as including an informative message with each commit you may need to include some additional information as well. This information consists of one or more lines containing the key word or phrase, a colon, tabs for formatting, and then the additional information. The key words or phrases are: PR: The problem report (if any) which is affected (typically, by being closed) by this commit. Submitted by: The name and e-mail address of the person that submitted the fix; for committers, just the username on the &os; cluster. Reviewed by: The name and e-mail address of the person or people that reviewed the change; for committers, just the username on the &os; cluster. If a patch was submitted to a mailing list for review, and the review was favorable, then just include the list name. Approved by: The name and e-mail address of the person or people that approved the change; for committers, just the username on the &os; cluster. It is customary to get prior approval for a commit if it is to an area of the tree to which you do not usually commit. In addition, during the run up to a new release all commits must be approved by the release engineering team. If these are your first commits then you should have passed them past your mentor first, and you should list your mentor, as in ``username-of-mentor (mentor)''. Obtained from: The name of the project (if any) from which the code was obtained. MFC after: If you wish to receive an e-mail reminder to MFC at a later date, specify the number of days, weeks, or months after which an MFC is planned. Security: If the change is related to a security vulnerability or security exposure, include one or more references or a description of the issue. Commit Log for a Commit Based on a PR You want to commit a change based on a PR submitted by John Smith containing a patch. The end of the commit message should look something like this. ... PR: foo/12345 Submitted by: John Smith <John.Smith@example.com> Commit Log for a Commit Needing Review You want to change the virtual memory system. You have posted patches to the appropriate mailing list (in this case, freebsd-arch) and the changes have been approved. ... Reviewed by: -arch Commit Log for a Commit Needing Approval You want to commit a change to a section of the tree with a MAINTAINER assigned. You have collaborated with the listed MAINTAINER, who has told you to go ahead and commit. ... Approved by: abc Where abc is the account name of the person who approved. Commit Log for a Commit Bringing in Code from OpenBSD You want to commit some code based on work done in the OpenBSD project. ... Obtained from: OpenBSD Commit Log for a Change to &os.current; with a Planned Commit to &os.stable; to Follow at a Later Date. You want to commit some code which will be merged from &os.current; into the &os.stable; branch after two weeks. ... MFC after: 2 weeks Where 2 is the number of days, weeks, or months after which an MFC is planned. The weeks option may be day, days, week, weeks, month, months, or may be left off (in which case, days will be assumed). In some cases you may need to combine some of these. Consider the situation where a user has submitted a PR containing code from the NetBSD project. You are looking at the PR, but it is not an area of the tree you normally work in, so you have decided to get the change reviewed by the arch mailing list. Since the change is complex, you opt to MFC after one month to allow adequate testing. The extra information to include in the commit would look something like PR: foo/54321 Submitted by: John Smith <John.Smith@example.com> Reviewed by: -arch Obtained from: NetBSD MFC after: 1 month How do I access people.FreeBSD.org to put up personal or project information? people.FreeBSD.org is the same as freefall.FreeBSD.org. Just create a public_html directory. Anything you place in that directory will automatically be visible under . Where are the mailing list archives stored? The mailing lists are archived under /g/mail which will show up as /hub/g/mail with &man.pwd.1;. This location is accessible from any machine on the &os; cluster. I would like to mentor a new committer. What process do I need to follow? See the New Account Creation Procedure document on the internal pages.
diff --git a/en_US.ISO8859-1/articles/releng/article.xml b/en_US.ISO8859-1/articles/releng/article.xml index 73bd395d1f..58d04fef88 100644 --- a/en_US.ISO8859-1/articles/releng/article.xml +++ b/en_US.ISO8859-1/articles/releng/article.xml @@ -1,1073 +1,1085 @@ The Release Engineering of Third Party Packages'> ]>
&os; Release Engineering November 2001 BSDCon Europe Murray Stokely I've been involved in the development of &os; based products since 1997 at Walnut Creek CDROM, BSDi, and now Wind River Systems. &os; 4.4 was the first official release of &os; that I played a significant part in.
murray@FreeBSD.org
&tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.intel; &tm-attrib.general; $FreeBSD$ 2013/02/26: This document is partially outdated and does not accurately describe the current release procedures of the &os; Release Engineering team. The &os; Release Engineering team is currently reviewing this document and will publish updated content soon. This paper describes the approach used by the &os; release engineering team to make production quality releases of the &os; Operating System. It details the methodology used for the official &os; releases and describes the tools available for those interested in producing customized &os; releases for corporate rollouts or commercial productization.
Introduction The development of &os; is a very open process. &os; is comprised of contributions from thousands of people around the world. The &os; Project provides Subversion Subversion, access to the general public so that others can have access to log messages, diffs (patches) between development branches, and other productivity enhancements that formal source code management provides. This has been a huge help in attracting more talented developers to &os;. However, I think everyone would agree that chaos would soon manifest if write access to the main repository was opened up to everyone on the Internet. Therefore only a select group of nearly 300 people are given write access to the Subversion repository. These committers FreeBSD committers are usually the people who do the bulk of &os; development. An elected Core Team &os; Core Team of developers provide some level of direction over the project. The rapid pace of &os; development makes the main development branch unsuitable for the everyday use by the general public. In particular, stabilizing efforts are required for polishing the development system into a production quality release. To solve this conflict, development continues on several parallel tracks. The main development branch is the HEAD or trunk of our Subversion tree, known as &os;-CURRENT or -CURRENT for short. A set of more stable branches are maintained, known as &os;-STABLE or -STABLE for short. All branches live in a master Subversion repository maintained by the &os; Project. &os;-CURRENT is the bleeding-edge of &os; development where all new changes first enter the system. &os;-STABLE is the development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into &os;-CURRENT and have been thoroughly tested by our user community. The term stable in the name of the branch refers to the presumed Application Binary Interface stability, which is promised by the project. This means that a user application compiled on an older version of the system from the same branch works on a newer system from the same branch. The ABI stability has improved greatly from the compared to previous releases. In most cases, binaries from the older STABLE systems run unmodified on newer systems, including HEAD, assuming that the system management interfaces are not used. - In the interim period between releases, monthly snapshots are + In the interim period between releases, weekly snapshots are built automatically by the &os; Project build machines and made available for download from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/. + class="resource">ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/. The widespread availability of binary release snapshots, and the tendency of our user community to keep up with -STABLE development with Subversion and make buildworld Rebuilding "world" helps to keep &os;-STABLE in a very reliable condition even before the quality assurance activities ramp up pending a major release. + In addition to installation ISO snapshots, weekly virtual + machine images are also provided for use with + VirtualBox, + qemu, or other popular emulation + software. The virtual machine images can be downloaded from + ftp://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/. + + The virtual machine images are approximately 150MB &man.xz.1; + compressed, and contain a 10GB sparse filesystem when attached to + a virtual machine. + Bug reports and feature requests are continuously submitted by users throughout the release cycle. Problems reports are entered into our GNATS database GNATS: The GNU Bug Tracking System through email, the &man.send-pr.1; application, or via the web interface provided at . To service our most conservative users, individual release branches were introduced with &os; 4.3. These release branches are created shortly before a final release is made. After the release goes out, only the most critical security fixes and additions are merged onto the release branch. In addition to source updates via Subversion, binary patchkits are available to keep systems on the - RELENG_X_Y + releng/X.Y branches updated. What this article describes The following sections of this article describe: The different phases of the release engineering process leading up to the actual system build. The actual build process. How the base release may be extended by third parties. Some of the lessons learned through the release of &os; 4.4. Future directions of development. Release Process New releases of &os; are released from the -STABLE branch at approximately four month intervals. The &os; release process begins to ramp up 70-80 days before the anticipated release date when the release engineer sends an email to the development mailing lists to remind developers that they only have 15 days to integrate new changes before the code freeze. During this time, many developers perform what have become known as MFC sweeps. MFC stands for Merge From CURRENT and it describes the process of merging a tested change from our -CURRENT development branch to our -STABLE branch. Project policy requires any change to be first applied to trunk, and merged to the -STABLE branches after sufficient external testing was done by -CURRENT users (developers are expected to extensively test the change before committing to -CURRENT, but it is impossible for a person to exercise all usages of the general-purpose operating system). Minimal MFC period is 3 days, which is typically used only for trivial or critical bugfixes. Code Review Sixty days before the anticipated release, the source repository enters a code freeze. During this - time, all commits to the -STABLE branch must be approved by the - &a.re;, the approval process is technically enforced by the + time, all commits to the -STABLE branch must be approved by + &a.re;. The approval process is technically enforced by a pre-commit hook. The kinds of changes that are allowed during this period include: Bug fixes. Documentation updates. Security-related fixes of any kind. Minor changes to device drivers, such as adding new Device IDs. Driver updates from the vendors. Any additional change that the release engineering team feels is justified, given the potential risk. Shortly after the code freeze is started, a BETA1 image is built and released for widespread testing. During the code freeze, at least one beta image or release candidate is released every two weeks until the final release is ready. During the days preceeding the final release, the release engineering team is in constant communication with the security-officer team, the documentation maintainers, and the port maintainers to ensure that all of the different components required for a successful release are available. After the quality of the BETA images is satisfying enough, and no large and potentially risky changes are planned, the release branch is created and Release Candidate (RC) images are built from the release branch, instead of the BETA images from the STABLE branch. Also, the freeze on the STABLE branch is lifted and release branch enters a hard code freeze where it becomes much harder to justify new changes to the system unless a serious bug-fix or security issue is involved. Final Release Checklist When several BETA images have been made available for widespread testing and all major issues have been resolved, the final release polishing can begin. Creating the Release Branch In all examples below, $FSVN refers to the location of the &os; Subversion repository, - svn+ssh://svn.freebsd.org/base/. + svn+ssh://svn.FreeBSD.org/base/. The layout of &os; branches in Subversion is described in the Committer's Guide. The first step in creating a branch is to identify the revision of the stable/X sources that you want to branch from. &prompt.root; svn log -v $FSVN/stable/9 The next step is to create the release branch &prompt.root; svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2 This branch can be checked out: &prompt.root; svn co $FSVN/releng/9.2 src Creating the releng branch and release tags is done by the Release Engineering Team. &os; Development Branch &os; 3.x STABLE Branch &os; 4.x STABLE Branch &os; 5.x STABLE Branch &os; 6.x STABLE Branch &os; 7.x STABLE Branch &os; 8.x STABLE Branch &os; 9.x STABLE Branch Bumping up the Version Number Before the final release can be tagged, built, and released, the following files need to be modified to reflect the correct version of &os;: doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml doc/en_US.ISO8859-1/books/porters-handbook/book.xml doc/share/xml/freebsd.ent src/Makefile.inc1 src/UPDATING src/gnu/usr.bin/groff/tmac/mdoc.local src/release/Makefile src/release/doc/en_US.ISO8859-1/share/xml/release.dsl src/release/doc/share/examples/Makefile.relnotesng src/release/doc/share/xml/release.ent src/share/examples/cvsup/standard-supfile src/sys/conf/newvers.sh src/sys/sys/param.h src/usr.sbin/pkg_install/add/main.c www/en/docs/man.xml www/en/cgi/ports.cgi ports/Tools/scripts/release/config The release notes and errata files also need to be adjusted for the new release (on the release branch) and truncated appropriately (on the stable/current branch): src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml src/release/doc/en_US.ISO8859-1/errata/article.xml Sysinstall should be updated to note the number of available ports and the amount of disk space required for the Ports Collection. &os; Ports Collection This information is currently kept in src/usr.sbin/sysinstall/dist.c. After the release has been built, a number of files should be updated to announce the release to the world. These files are relative to head/ within the doc/ subversion tree. share/images/articles/releng/branches-relengX.pic head/share/xml/release.ent en_US.ISO8859-1/htdocs/releases/* en_US.ISO8859-1/htdocs/releng/index.xml share/xml/news.xml Additionally, update the BSD Family Tree file: src/share/misc/bsd-family-tree Creating the Release Tag When the final release is ready, the following command will create the release/9.2.0 tag. &prompt.root; svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0 The Documentation and Ports managers are responsible for tagging their respective trees with the tags/RELEASE_9_2_0 tag. When the Subversion svn cp command is used to create a release tag, this identifies the source at a specific point in time. By creating tags, we ensure that future release builders will always be able to use the exact same source we used to create the official &os; Project releases. Release Building &os; releases can be built by anyone with a fast machine and access to a source repository. (That should be everyone, since we offer Subversion access ! See the Subversion section in the Handbook for details.) The only special requirement is that the &man.md.4; device must be available. If the device is not loaded into your kernel, then the kernel module should be automatically loaded when &man.mdconfig.8; is executed during the boot media creation phase. All of the tools necessary to build a release are available from the Subversion repository in src/release. These tools aim to provide a consistent way to build &os; releases. A complete release can actually be built with only a single command, including the creation of ISO images suitable for burning to CDROM or DVD, and an FTP install directory. &man.release.7; fully documents the src/release/generate-release.sh script which is used to build a release. generate-release.sh is a wrapper around the Makefile target: make release. Building a Release &man.release.7; documents the exact commands required to build a &os; release. The following sequences of commands can build an 9.2.0 release: &prompt.root; cd /usr/src/release &prompt.root; sh generate-release.sh release/9.2.0 /local3/release After running these commands, all prepared release files are available in /local3/release/R directory. The release Makefile can be broken down into several distinct steps. Creation of a sanitized system environment in a separate directory hierarchy with make installworld. Checkout from Subversion of a clean version of the system source, documentation, and ports into the release build hierarchy. Population of /etc and /dev in the chrooted environment. chroot into the release build hierarchy, to make it harder for the outside environment to taint this build. make world in the chrooted environment. Build of Kerberos-related binaries. Build GENERIC kernel. Creation of a staging directory tree where the binary distributions will be built and packaged. Build and installation of the documentation toolchain needed to convert the documentation source (SGML) into HTML and text documents that will accompany the release. Build and installation of the actual documentation (user manuals, tutorials, release notes, hardware compatibility lists, and so on.) Package up distribution tarballs of the binaries and sources. Create FTP installation hierarchy. (optionally) Create ISO images for CDROM/DVD media. For more information about the release build infrastructure, please see &man.release.7;. It is important to remove any site-specific settings from /etc/make.conf. For example, it would be unwise to distribute binaries that were built on a system with CPUTYPE set to a specific processor. Contributed Software (<quote>ports</quote>) The &os; Ports collection is a collection of over &os.numports; third-party software packages available for &os;. The &a.portmgr; is responsible for maintaining a consistent ports tree that can be used to create the binary packages that accompany official &os; releases. The release engineering activities for our collection of third-party packages is beyond the scope of this document. A separate article, &art.re.pkgs;, covers this topic in depth. Release ISOs Starting with &os; 4.4, the &os; Project decided to release all four ISO images that were previously sold on the BSDi/Wind River Systems/FreeBSD Mall official CDROM distributions. Each of the four discs must contain a README.TXT file that explains the contents of the disc, a CDROM.INF file that provides meta-data for the disc so that &man.sysinstall.8; can validate and use the contents, and a filename.txt file that provides a manifest for the disc. This manifest can be created with a simple command: /stage/cdrom&prompt.root; find . -type f | sed -e 's/^\.\///' | sort > filename.txt The specific requirements of each CD are outlined below. Disc 1 The first disc is almost completely created by make release. The only changes that should be made to the disc1 directory are the addition of a tools directory, and as many popular third party software packages as will fit on the disc. The tools directory contains software that allow users to create installation floppies from other operating systems. This disc should be made bootable so that users of modern PCs do not need to create installation floppy disks. If a custom kernel of &os; is to be included, then &man.sysinstall.8; and &man.release.7; must be updated to include installation instructions. The relevant code is contained in src/release and src/usr.sbin/sysinstall. Specifically, the file src/release/Makefile, and dist.c, dist.h, menus.c, install.c, and Makefile will need to be updated under src/usr.sbin/sysinstall. Optionally, you may choose to update sysinstall.8. Disc 2 The second disc is also largely created by make release. This disc contains a live filesystem that can be used from &man.sysinstall.8; to troubleshoot a &os; installation. This disc should be bootable and should also contain a compressed copy of the CVS repository in the CVSROOT directory and commercial software demos in the commerce directory. Discs 3 and 4 The remaining two discs contain additional software packages for &os;. The packages should be clustered so that a package and all of its dependencies are included on the same disc. More information about the creation of these discs is provided in the &art.re.pkgs; article. Multi-volume support Sysinstall supports multiple volume package installations. This requires that each disc have an INDEX file containing all of the packages on all volumes of a set, along with an extra field that indicates which volume that particular package is on. Each volume in the set must also have the CD_VOLUME variable set in the cdrom.inf file so that sysinstall can tell which volume is which. When a user attempts to install a package that is not on the current disc, sysinstall will prompt the user to insert the appropriate one. Distribution FTP Sites When the release has been thoroughly tested and packaged for distribution, the master FTP site must be updated. The official &os; public FTP sites are all mirrors of a master server that is open only to other FTP sites. This site is known as ftp-master. When the release is ready, the following files must be modified on ftp-master: /pub/FreeBSD/releases/arch/X.Y-RELEASE/ The installable FTP directory as output from make release. /pub/FreeBSD/ports/arch/packages-X.Y-release/ The complete package build for this release. /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools A symlink to ../../../tools. /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages A symlink to ../../../ports/arch/packages-X.Y-release. /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso The ISO images. The * is disc1, disc2, etc. Only if there is a disc1 and there is an alternative first installation CD (for example a stripped-down install with no windowing system) there may be a mini as well. For more information about the distribution mirror architecture of the &os; FTP sites, please see the Mirroring &os; article. It may take many hours to two days after updating ftp-master before a majority of the Tier-1 FTP sites have the new software depending on whether or not a package set got loaded at the same time. It is imperative that the release engineers coordinate with the &a.mirror-announce; before announcing the general availability of new software on the FTP sites. Ideally the release package set should be loaded at least four days prior to release day. The release bits should be loaded between 24 and 48 hours before the planned release time with other file permissions turned off. This will allow the mirror sites to download it but the general public will not be able to download it from the mirror sites. Mail should be sent to &a.mirror-announce; at the time the release bits get posted saying the release has been staged and giving the time that the mirror sites should begin allowing access. Be sure to include a time zone with the time, for example make it relative to GMT. CD-ROM Replication Coming soon: Tips for sending &os; ISOs to a replicator and quality assurance measures to be taken. Extensibility Although &os; forms a complete operating system, there is nothing that forces you to use the system exactly as we have packaged it up for distribution. We have tried to design the system to be as extensible as possible so that it can serve as a platform that other commercial products can be built on top of. The only rule we have about this is that if you are going to distribute &os; with non-trivial changes, we encourage you to document your enhancements! The &os; community can only help support users of the software we provide. We certainly encourage innovation in the form of advanced installation and administration tools, for example, but we cannot be expected to answer questions about it. Scripting <command>sysinstall</command> The &os; system installation and configuration tool, &man.sysinstall.8;, can be scripted to provide automated installs for large sites. This functionality can be used in conjunction with &intel; PXE to bootstrap systems from the network. Lessons Learned from &os; 4.4 The release engineering process for 4.4 formally began on August 1st, 2001. After that date all commits to the RELENG_4 branch of &os; had to be explicitly approved by the &a.re;. The first release candidate for the x86 architecture was released on August 16, followed by 4 more release candidates leading up to the final release on September 18th. The security officer was very involved in the last week of the process as several security issues were found in the earlier release candidates. A total of over 500 emails were sent to the &a.re; in little over a month. Our user community has made it very clear that the security and stability of a &os; release should not be sacrificed for any self-imposed deadlines or target release dates. The &os; Project has grown tremendously over its lifetime and the need for standardized release engineering procedures has never been more apparent. This will become even more important as &os; is ported to new platforms. Future Directions It is imperative for our release engineering activities to scale with our growing userbase. Along these lines we are working very hard to document the procedures involved in producing &os; releases. Parallelism - Certain portions of the release build are actually embarrassingly parallel. Most of the tasks are very I/O intensive, so having multiple high-speed disk drives is actually more important than using multiple processors in speeding up the make release process. If multiple disks are used for different hierarchies in the &man.chroot.2; environment, then the CVS checkout of the ports and doc trees can be happening simultaneously as the make world on another disk. Using a RAID solution (hardware or software) can significantly decrease the overall build time. Cross-building releases - Building IA-64 or Alpha release on x86 hardware? make TARGET=ia64 release. Regression Testing - We need better automated correctness testing for &os;. Installation Tools - Our installation program has long since outlived its intended life span. Several projects are under development to provide a more advanced installation mechanism. The libh project was one such project that aimed to provide an intelligent new package framework and GUI installation program. Acknowledgements I would like to thank Jordan Hubbard for giving me the opportunity to take on some of the release engineering responsibilities for &os; 4.4 and also for all of his work throughout the years making &os; what it is today. Of course the release would not have been possible without all of the release-related work done by &a.asami.email;, &a.steve.email;, &a.bmah.email;, &a.nik.email;, &a.obrien.email;, &a.kris.email;, &a.jhb.email; and the rest of the &os; development community. I would also like to thank &a.rgrimes.email;, &a.phk.email;, and others who worked on the release engineering tools in the very early days of &os;. This article was influenced by release engineering documents from the CSRG Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD , the NetBSD Project , NetBSD Developer Documentation: Release Engineering , and John Baldwin's proposed release engineering process notes. John Baldwin's &os; Release Engineering Proposal
diff --git a/en_US.ISO8859-1/books/fdp-primer/docbook-markup/chapter.xml b/en_US.ISO8859-1/books/fdp-primer/docbook-markup/chapter.xml index 0b21d3f964..dd987da928 100644 --- a/en_US.ISO8859-1/books/fdp-primer/docbook-markup/chapter.xml +++ b/en_US.ISO8859-1/books/fdp-primer/docbook-markup/chapter.xml @@ -1,2629 +1,2629 @@ DocBook Markup Introduction This chapter is an introduction to DocBook as it is used for &os; documentation. DocBook is a large and complex markup system, but the subset described here covers the parts that are most widely used for &os; documentation. While a moderate subset is covered, it is impossible to anticipate every situation. Please post questions that this document does not answer to the &a.doc;. DocBook was originally developed by HaL Computer Systems and O'Reilly & Associates to be a Document Type Definition (DTD) for writing technical documentation A short history can be found under http://www.oasis-open.org/docbook/intro.shtml#d0e41.. Since 1998 it is maintained by the DocBook Technical Committee. As such, and unlike LinuxDoc and XHTML, DocBook is very heavily oriented towards markup that describes what something is, rather than describing how it should be presented. The DocBook DTD is available from the Ports Collection in the textproc/docbook-xml-450 port. It is automatically installed as part of the textproc/docproj port. Formal Versus Informal Some elements may exist in two forms, formal and informal. Typically, the formal version of the element will consist of a title followed by the informal version of the element. The informal version will not have a title. Inline Versus Block In the remainder of this document, when describing elements, inline means that the element can occur within a block element, and does not cause a line break. A block element, by comparison, will cause a line break (and other processing) when it is encountered. &os; Extensions The &os; Documentation Project has extended the DocBook DTD with additional elements and entities. These additions serve to make some of the markup easier or more precise. Throughout the rest of this document, the term DocBook is used to mean the &os;-extended DocBook DTD. Most of these extensions are not unique to &os;, it was just felt that they were useful enhancements for this particular project. Should anyone from any of the other *nix camps (NetBSD, OpenBSD, Linux, …) be interested in collaborating on a standard DocBook extension set, please contact &a.doceng;. &os; Elements The additional &os; elements are not (currently) in the Ports Collection. They are stored in the &os; Subversion tree, as head/share/xml/freebsd.dtd. &os;-specific elements used in the examples below are clearly marked. &os; Entities This table shows some of the most useful entities available in the FDP. For a complete list, see the *.ent files in doc/share/xml. &os; Name Entities &os; &os; &os.stable; &os.stable; &os.current; &os.current; Manual Page Entities &man.ls.1; &man.ls.1; Usage: &man.ls.1; is the manual page for commandlscommand. &man.cp.1; &man.cp.1; Usage: The manual page for commandcpcommand is &man.cp.1;. &man.command.sectionnumber; link to command manual page in section sectionnumber Entities are defined for all the &os; manual pages. &os; Mailing List Entities &a.doc; &a.doc; Usage: A link to the &a.doc;. &a.questions; &a.questions; Usage: A link to the &a.questions;. &a.listname; link to listname Entities are defined for all the &os; mailing lists. &os; Document Link Entities &url.books.handbook; &url.books.handbook; Usage: A link to the ulink url="&url.books.handbook;/advanced-networking.html"Advanced Networkingulink chapter of the Handbook. &url.books.bookname; relative path to bookname Entities are defined for all the &os; books. &url.articles.committers-guide; &url.articles.committers-guide; Usage: A link to the ulink url="&url.articles.committers-guide;"Committer's Guideulink article. &url.articles.articlename; relative path to articlename Entities are defined for all the &os; articles. Other Operating System Name Entities &linux; &linux; The &linux; operating system. &unix; &unix; The &unix; operating system. &windows; &windows; The &windows; operating system. Miscellaneous Entities &prompt.root; &prompt.root; The root user prompt. &prompt.user; &prompt.user; A prompt for an unprivileged user. &postscript; &postscript; The &postscript; programming language. &tex; &tex; The &tex; typesetting language. &xorg; &xorg; The &xorg; open source X Window System. Formal Public Identifier (FPI) In compliance with the DocBook guidelines for writing FPIs for DocBook customizations, the FPI for the &os; extended DocBook DTD is: PUBLIC "-//FreeBSD//DTD DocBook V4.2-Based Extension//EN" Document Structure DocBook allows structuring documentation in several ways. The &os; Documentation Project uses two primary types of DocBook document: the book and the article. Books are organized into chapters. This is a mandatory requirement. There may be parts between the book and the chapter to provide another layer of organization. For example, the Handbook is arranged in this way. A chapter may (or may not) contain one or more sections. These are indicated with the sect1 element. If a section contains another section then use the sect2 element, and so on, up to sect5. Chapters and sections contain the remainder of the content. An article is simpler than a book, and does not use chapters. Instead, the content of an article is organized into one or more sections, using the same sect1 (and sect2 and so on) elements that are used in books. The nature of the document being written should be used to determine whether it is best marked up as a book or an article. Articles are well suited to information that does not need to be broken down into several chapters, and that is, relatively speaking, quite short, at up to 20-25 pages of content. Books are best suited to information that can be broken up into several chapters, possibly with appendices and similar content as well. The &os; tutorials are all marked up as articles, while this document, the FreeBSD FAQ, and the FreeBSD Handbook are all marked up as books, for example. Starting a Book The content of a book is contained within the book element. As well as containing structural markup, this element can contain elements that include additional information about the book. This is either meta-information, used for reference purposes, or additional content used to produce a title page. This additional information is contained within bookinfo. Boilerplate <sgmltag>book</sgmltag> with <sgmltag>bookinfo</sgmltag> book bookinfo titleYour Title Heretitle author firstnameYour first namefirstname surnameYour surnamesurname affiliation addressemailYour email addressemailaddress affiliation author copyright year1998year holder role="mailto:your email address"Your nameholder copyright releaseinfo$&os;$releaseinfo abstract paraInclude an abstract of the book's contents here.para abstract bookinfobook Starting an Article The content of the article is contained within the article element. As well as containing structural markup, this element can contain elements that include additional information about the article. This is either meta-information, used for reference purposes, or additional content used to produce a title page. This additional information is contained within articleinfo. Boilerplate <sgmltag>article</sgmltag> with <sgmltag>articleinfo</sgmltag> article articleinfo titleYour title heretitle author firstnameYour first namefirstname surnameYour surnamesurname affiliation addressemailYour email addressemailaddress affiliation author copyright year1998year holder role="mailto:your email address"Your nameholder copyright releaseinfo$&os;$releaseinfo abstract paraInclude an abstract of the article's contents here.para abstract articleinfoarticle Indicating Chapters Use chapter to mark up your chapters. Each chapter has a mandatory title. Articles do not contain chapters, they are reserved for books. A Simple Chapter chapter titleThe Chapter's Titletitle ... chapter A chapter cannot be empty; it must contain elements in addition to title. If you need to include an empty chapter then just use an empty paragraph. Empty Chapters chapter titleThis is An Empty Chaptertitle parapara chapter Sections Below Chapters In books, chapters may (but do not need to) be broken up into sections, subsections, and so on. In articles, sections are the main structural element, and each article must contain at least one section. Use the sectn element. The n indicates the section number, which identifies the section level. The first sectn is sect1. You can have one or more of these in a chapter. They can contain one or more sect2 elements, and so on, down to sect5. Sections in Chapters chapter titleA Sample Chaptertitle paraSome text in the chapter.para sect1 titleFirst Sectiontitlesect1 sect1 titleSecond Sectiontitle sect2 titleFirst Sub-Sectiontitle sect3 titleFirst Sub-Sub-Sectiontitlesect3 sect2 sect2 titleSecond Sub-Section (1.2.2)titlesect2 sect1 chapter Section numbers are automatically generated and prepended to titles when the document is rendered to an output format. The generated section numbers and titles from the example above will be: 1.1. First Section 1.2. Second Section 1.2.1. First Sub-Section 1.2.1.1. First Sub-Sub-Section 1.2.2. Second Sub-Section Subdividing Using <sgmltag>part</sgmltag> Elements parts introduce another level of organization between book and chapter with one or more parts. This cannot be done in an article. part titleIntroductiontitle chapter titleOverviewtitle ... chapter chapter titleWhat is FreeBSD?title ... chapter chapter titleHistorytitle ... chapter part Block Elements Paragraphs DocBook supports three types of paragraphs: formalpara, para, and simpara. Almost all paragraphs in &os; documentation use para. formalpara includes a title element, and simpara disallows some elements from within para. Stick with para. <sgmltag>para</sgmltag> Usage: paraThis is a paragraph. It can contain just about any other element.para Appearance: This is a paragraph. It can contain just about any other element. Block Quotations A block quotation is an extended quotation from another document that should not appear within the current paragraph. These are rarely needed. Blockquotes can optionally contain a title and an attribution (or they can be left untitled and unattributed). <sgmltag>blockquote</sgmltag> Usage: paraA small excerpt from the US Constitution:para blockquote titlePreamble to the Constitution of the United Statestitle attributionCopied from a web site somewhereattribution paraWe the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.para blockquote Appearance: A small excerpt from the US Constitution:
Preamble to the Constitution of the United States Copied from a web site somewhere We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
Tips, Notes, Warnings, Cautions, Important Information and Sidebars Extra information may need to be separated from the main body of the text. Typically this is meta information of which the user should be aware. Depending on the nature of the information, one of tip, note, warning, caution, and important should be used. Alternatively, if the information is related to the main text but is not one of the above, use sidebar. The circumstances in which to choose one of these elements over another is loosely defined by the DocBook documentation, which suggests: A Note is for information that should be heeded by all readers. An Important element is a variation on Note. A Caution is for information regarding possible data loss or software damage. A Warning is for information regarding possible hardware damage or injury to life or limb. <sgmltag>warning</sgmltag> Usage: warning paraInstalling FreeBSD may make you want to delete Windows from your hard disk.para warning Appearance: Installing FreeBSD may make you want to delete Windows from your hard disk. Lists and Procedures Information often needs to be presented as lists, or as a number of steps that must be carried out in order to accomplish a particular goal. To do this, use itemizedlist, orderedlist, or procedureThere are other types of list element in DocBook, but we are not concerned with those at the moment. itemizedlist and orderedlist are similar to their counterparts in HTML, ul and ol. Each one consists of one or more listitem elements, and each listitem contains one or more block elements. The listitem elements are analogous to HTML's li tags. However, unlike HTML, they are required. procedure is slightly different. It consists of steps, which may in turn consists of more steps or substeps. Each step contains block elements. <sgmltag>itemizedlist</sgmltag>, <sgmltag>orderedlist</sgmltag>, and <sgmltag>procedure</sgmltag> Usage: itemizedlist listitem paraThis is the first itemized item.para listitem listitem paraThis is the second itemized item.para listitem itemizedlist orderedlist listitem paraThis is the first ordered item.para listitem listitem paraThis is the second ordered item.para listitem orderedlist procedure step paraDo this.para step step paraThen do this.para step step paraAnd now do this.para step procedure Appearance: This is the first itemized item. This is the second itemized item. This is the first ordered item. This is the second ordered item. Do this. Then do this. And now do this. Showing File Samples Fragments of a file (or perhaps a complete file) are shown by wrapping them in the programlisting element. White space and line breaks within programlisting are significant. In particular, this means that the opening tag should appear on the same line as the first line of the output, and the closing tag should appear on the same line as the last line of the output, otherwise spurious blank lines may be included. <sgmltag>programlisting</sgmltag> Usage: paraWhen finished, the program will look like this:para programlisting#include &lt;stdio.h&gt; int main(void) { printf("hello, world\n"); }programlisting Notice how the angle brackets in the #include line need to be referenced by their entities instead of being included literally. Appearance: When finished, the program will look like this: #include <stdio.h> int main(void) { printf("hello, world\n"); } Callouts A callout is a visual marker for referring to a piece of text or specific position within an example. Callouts are marked with the co element. Each element must have a unique id assigned to it. After the example, include a calloutlist that describes each callout. <sgmltag>co</sgmltag> and <sgmltag>calloutlist</sgmltag> paraWhen finished, the program will look like this:para programlisting#include &lt;stdio.h&gt; co id="co-ex-include" int co id="co-ex-return" main(void) { printf("hello, world\n"); co id="co-ex-printf" }programlisting calloutlist callout arearefs="co-ex-include" paraIncludes the standard IO header file.para callout callout arearefs="co-ex-return" paraSpecifies that functionmain()function returns an int.para callout callout arearefs="co-ex-printf" paraThe functionprintf()function call that writes literalhello, worldliteral to standard output.para callout calloutlist Appearance: When finished, the program will look like this: #include <stdio.h> int main(void) { printf("hello, world\n"); } Includes the standard IO header file. Specifies that main() returns an int. The printf() call that writes hello, world to standard output. Tables Unlike HTML, DocBook does not need tables for layout purposes, as the stylesheet handles those issues. Instead, just use tables for marking up tabular data. In general terms (and see the DocBook documentation for more detail) a table (which can be either formal or informal) consists of a table element. This contains at least one tgroup element, which specifies (as an attribute) the number of columns in this table group. Within the tablegroup there is one thead element, which contains elements for the table headings (column headings), and one tbody which contains the body of the table. Both tgroup and thead contain row elements, which in turn contain entry elements. Each entry element specifies one cell in the table. <sgmltag>informaltable</sgmltag> Usage: informaltable pgwide="1" tgroup cols="2" thead row entryThis is Column Head 1entry entryThis is Column Head 2entry row thead tbody row entryRow 1, column 1entry entryRow 1, column 2entry row row entryRow 2, column 1entry entryRow 2, column 2entry row tbody tgroup informaltable Appearance: This is Column Head 1 This is Column Head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 Always use the pgwide attribute with a value of 1 with the informaltable element. A bug in Internet Explorer can cause the table to render incorrectly if this is omitted. Table borders can be suppressed by setting the frame attribute to none in the informaltable element. For example, informaltable frame="none". Tables Where <literal>frame="none"</literal> Appearance: This is Column Head 1 This is Column Head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 Examples for the User to Follow Examples for the user to follow are often necessary. Typically, these will consist of dialogs with the computer; the user types in a command, the user gets a response back, the user types another command, and so on. A number of distinct elements and entities come into play here. screen Everything the user sees in this example will be on the computer screen, so the next element is screen. Within screen, white space is significant. prompt, &prompt.root; and &prompt.user; Some of the things the user will be seeing on the screen are prompts from the computer (either from the operating system, command shell, or application). These should be marked up using prompt. As a special case, the two shell prompts for the normal user and the root user have been provided as entities. To indicate the user is at a shell prompt, use one of &prompt.root; and &prompt.user; as necessary. They do not need to be inside prompt. &prompt.root; and &prompt.user; are &os; extensions to DocBook, and are not part of the original DTD. userinput When displaying text that the user should type in, wrap it in userinput tags. It will be displayed differently than system output text. <sgmltag>screen</sgmltag>, <sgmltag>prompt</sgmltag>, and <sgmltag>userinput</sgmltag> Usage: screen&prompt.user; userinputls -1userinput foo1 foo2 foo3 &prompt.user; userinputls -1 | grep foo2userinput foo2 &prompt.user; userinputsuuserinput promptPassword: prompt &prompt.root; userinputcat foo2userinput This is the file called 'foo2'screen Appearance: &prompt.user; ls -1 foo1 foo2 foo3 &prompt.user; ls -1 | grep foo2 foo2 &prompt.user; su Password: &prompt.root; cat foo2 This is the file called 'foo2' Even though we are displaying the contents of the file foo2, it is not marked up as programlisting. Reserve programlisting for showing fragments of files outside the context of user actions.
In-line Elements Emphasizing Information To emphasize a particular word or phrase, use emphasis. This may be presented as italic, or bold, or might be spoken differently with a text-to-speech system. There is no way to change the presentation of the emphasis within the document, no equivalent of HTML's b and i. If the information being presented is important, then consider presenting it in important rather than emphasis. <sgmltag>emphasis</sgmltag> Usage: paraFreeBSD is without doubt emphasistheemphasis premiere &unix;-like operating system for the Intel architecture.para Appearance: FreeBSD is without doubt the premiere &unix;-like operating system for the Intel architecture. Acronyms Many computer terms are acronyms, words formed from the first letter of each word in a phrase. Acronyms are marked up into acronym elements. It is helpful to the reader when an acronym is defined on the first use, as shown in the example below. Acronyms Usage: paraRequest For Comments (acronymRFCacronym) 1149 defined the use of avian carriers for transmission of Internet Protocol (acronymIPacronym) data. The quantity of acronymIPacronym data currently transmitted in that manner is unknown.para Appearance: Request For Comments (RFC) 1149 defined the use of avian carriers for transmission of Internet Protocol (IP) data. The quantity of IP data currently transmitted in that manner is unknown. Quotations To quote text from another document or source, or to denote a phrase that is used figuratively, use quote. Most of the markup tags available for normal text are also available from within a quote. Quotations Usage: paraHowever, make sure that the search does not go beyond the quoteboundary between local and public administrationquote, as acronymRFCacronym 1535 calls it.para Appearance: However, make sure that the search does not go beyond the boundary between local and public administration, as RFC 1535 calls it. Keys, Mouse Buttons, and Combinations To refer to a specific key on the keyboard, use keycap. To refer to a mouse button, use mousebutton. And to refer to combinations of key presses or mouse clicks, wrap them all in keycombo. keycombo has an attribute called action, which may be one of click, double-click, other, press, seq, or simul. The last two values denote whether the keys or buttons should be pressed in sequence, or simultaneously. The stylesheets automatically add any connecting symbols, such as +, between the key names, when wrapped in keycombo. Keys, Mouse Buttons, and Combinations Usage: paraTo switch to the second virtual terminal, press keycombo action="simul"keycapAltkeycap keycapF1keycapkeycombo.para paraTo exit commandvicommand without saving changes, type keycombo action="seq"keycapEsckeycapkeycap:keycap keycapqkeycapkeycap!keycapkeycombo.para paraMy window manager is configured so that keycombo action="simul"keycapAltkeycap mousebuttonrightmousebutton keycombo mouse button is used to move windows.para Appearance: To switch to the second virtual terminal, press Alt F1. To exit vi without saving changes, type Esc : q !. My window manager is configured so that Alt right mouse button is used to move windows. Applications, Commands, Options, and Cites Both applications and commands are frequently referred to when writing documentation. The distinction between them is that an application is the name of a program or suite of programs that fulfill a particular task. A command is the filename of a program that the user can type and run at a command line. It is often necessary to show some of the options that a command might take. Finally, it is often useful to list a command with its manual section number, in the command(number) format so common in Unix manuals. Mark up application names with application. To list a command with its manual section number (which should be most of the time) the DocBook element is citerefentry. This will contain a further two elements, refentrytitle and manvolnum. The content of refentrytitle is the name of the command, and the content of manvolnum is the manual page section. This can be cumbersome to write, and so a series of general entities have been created to make this easier. Each entity takes the form &man.manual-page.manual-section;. The file that contains these entities is in doc/share/xml/man-refs.ent, and can be referred to using this FPI: PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN" Therefore, the introduction to &os; documentation will usually include this: <!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ <!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> %man; … ]> Use command when to include a command name in-line but present it as something the user should type in. Use option to mark up the options which will be passed to a command. When referring to the same command multiple times in close proximity, it is preferred to use the &man.command.section; notation to markup the first reference and use command to markup subsequent references. This makes the generated output, especially HTML, appear visually better. Applications, Commands, and Options Usage: paraapplicationSendmailapplication is the most widely used Unix mail application.para paraapplicationSendmailapplication includes the citerefentry refentrytitlesendmailrefentrytitle manvolnum8manvolnum citerefentry, &man.mailq.1;, and &man.newaliases.1; programs.para paraOne of the command line parameters to citerefentry refentrytitlesendmailrefentrytitle manvolnum8manvolnum citerefentry, option-bpoption, will display the current status of messages in the mail queue. Check this on the command line by running commandsendmail -bpcommand.para Appearance: Sendmail is the most widely used Unix mail application. Sendmail includes the sendmail 8 , &man.mailq.1;, and &man.newaliases.1; programs. One of the command line parameters to sendmail 8 , , will display the current status of messages in the mail queue. Check this on the command line by running sendmail -bp. Notice how the &man.command.section; notation is easier to follow. Files, Directories, Extensions To refer to the name of a file, a directory, or a file extension, use filename. <sgmltag>filename</sgmltag> Usage: paraThe XML source for the Handbook in English is found in filename class="directory"/usr/doc/en_US.ISO8859-1/books/handbook/filename. The first file is called filenamebook.xmlfilename in that directory. There is also a filenameMakefilefilename and a number of files with a filename.entfilename extension.para Appearance: The XML source for the Handbook in English can be found in /usr/doc/en/handbook/. The first file is called handbook.xml in that directory. There is also a Makefile and a number of files with a .ent extension. The Name of Ports &os; Extension These elements are part of the &os; extension to DocBook, and do not exist in the original DocBook DTD. To include the name of a program from the &os; Ports Collection in the document, use the filename tag with the role attribute set to package. Since ports can be installed in any number of locations, only include the category and the port name; do not include /usr/ports. <sgmltag>filename</sgmltag> Tag with <literal>package</literal> Role Usage: paraInstall the filename role="package"net/wiresharkfilename port to view network traffic.para Appearance: Install the net/wireshark port to view network traffic. Devices &os; Extension These elements are part of the &os; extension to DocBook, and do not exist in the original DocBook DTD. There are two names for devices: the device name as it appears in /dev, or the name of the device as it appears in the kernel. For this latter course, use devicename. Sometimes there is no choice. Some devices, such as network cards, do not have entries in /dev, or the entries are markedly different from their kernel device names. <sgmltag>devicename</sgmltag> Usage: paradevicenamesiodevicename is used for serial communication in FreeBSD. devicenamesiodevicename manifests through a number of entries in filename/devfilename, including filename/dev/ttyd0filename and filename/dev/cuaa0filename.para paraBy contrast, network devices such as devicenameed0devicename do not appear in filename/devfilename.para paraIn MS-DOS, the first floppy drive is referred to as devicenamea:devicename. In FreeBSD it is filename/dev/fd0filename.para Appearance: sio is used for serial communication in FreeBSD. sio manifests through a number of entries in /dev, including /dev/ttyd0 and /dev/cuaa0. By contrast, network devices such as ed0 do not appear in /dev. In MS-DOS, the first floppy drive is referred to as a:. In FreeBSD it is /dev/fd0. Hosts, Domains, IP Addresses, and So Forth &os; Extension These elements are part of the &os; extension to DocBook, and do not exist in the original DocBook DTD. Identification information for networked computers (hosts) can be marked up in several ways, depending on the nature of the information. All of them use hostid as the element, with the role attribute selecting the type of the marked up information. No role attribute, or role="hostname" With no role attribute (i.e., hostid.../hostid) the marked up information is the simple hostname, such as freefall or wcarchive. The hostname can be explicitly specified with role="hostname". role="domainname" The text is a domain name, such as FreeBSD.org or ngo.org.uk. There is no hostname component. role="fqdn" The text is a Fully Qualified Domain Name, with both hostname and domain name parts. role="ipaddr" The text is an IP address, probably expressed as a dotted quad. role="ip6addr" The text is an IPv6 address. role="netmask" The text is a network mask, which might be expressed as a dotted quad, a hexadecimal string, or as a / followed by a number (CIDR notation). role="mac" The text is an Ethernet MAC address, expressed as a series of 2 digit hexadecimal numbers separated by colons. <sgmltag>hostid</sgmltag> and Roles Usage: paraThe local machine can always be referred to by the name hostidlocalhosthostid, which will have the IP address hostid role="ipaddr"127.0.0.1hostid.para paraThe hostid role="domainname"FreeBSD.orghostid domain contains a number of different hosts, including hostid role="fqdn"freefall.FreeBSD.orghostid and hostid role="fqdn"bento.FreeBSD.orghostid.para paraWhen adding an acronymIPacronym alias to an interface (using commandifconfigcommand) emphasisalwaysemphasis use a netmask of hostid role="netmask"255.255.255.255hostid (which can also be expressed as hostid role="netmask"0xffffffffhostid).para paraThe acronymMACacronym address uniquely identifies every network card in existence. A typical acronymMACacronym address looks like hostid role="mac"08:00:20:87:ef:d0hostid.para Appearance: The local machine can always be referred to by the name localhost, which will have the IP address 127.0.0.1. The FreeBSD.org domain contains a number of different hosts, including freefall.FreeBSD.org and bento.FreeBSD.org. When adding an IP alias to an interface (using ifconfig) always use a netmask of 255.255.255.255 (which can also be expressed as 0xffffffff). The MAC address uniquely identifies every network card in existence. A typical MAC address looks like 08:00:20:87:ef:d0. Usernames &os; Extension These elements are part of the &os; extension to DocBook, and do not exist in the original DocBook DTD. To refer to a specific username, such as root or bin, use username. <sgmltag>username</sgmltag> Usage: paraTo carry out most system administration functions requires logging in as usernamerootusername.para Appearance: To carry out most system administration functions requires logging in as root. Email Addresses Email addresses are marked up as email elements. In the HTML output format, the wrapped text becomes a hyperlink to the email address. Other output formats that support hyperlinks may also make the email address into a link. <sgmltag>email</sgmltag> with a Hyperlink Usage: paraAn email address that does not actually exist, like emailnotreal@example.comemail, can be used as an example.para Appearance: An email address that does not actually exist, like notreal@example.com, can be used as an example. A &os;-specific extension allows setting the role attribute to nolink to prevent the creation of the hyperlink to the email address. <sgmltag>email</sgmltag> Without a Hyperlink Usage: paraSometimes a link to an email address like email role="nolink"notreal@example.comemail is not desired.para Appearance: Sometimes a link to an email address like notreal@example.com is not desired. Describing <filename>Makefile</filename>s &os; Extension These elements are part of the &os; extension to DocBook, and do not exist in the original DocBook DTD. Two elements exist to describe parts of Makefiles, maketarget and makevar. maketarget identifies a build target exported by a Makefile that can be given as a parameter to make. makevar identifies a variable that can be set (in the environment, on the command line with make, or within the Makefile) to influence the process. <sgmltag>maketarget</sgmltag> and <sgmltag>makevar</sgmltag> Usage: paraTwo common targets in a filenameMakefilefilename are maketargetallmaketarget and maketargetcleanmaketarget.para paraTypically, invoking maketargetallmaketarget will rebuild the application, and invoking maketargetcleanmaketarget will remove the temporary files (filename.ofilename for example) created by the build process.para paramaketargetcleanmaketarget may be controlled by a number of variables, including makevarCLOBBERmakevar and makevarRECURSEmakevar.para Appearance: Two common targets in a Makefile are all and clean. Typically, invoking all will rebuild the application, and invoking clean will remove the temporary files (.o for example) created by the build process. clean may be controlled by a number of variables, including CLOBBER and RECURSE. Literal Text Literal text, or text which should be entered verbatim, is often needed in documentation. This is text that is excerpted from another file, or which should be copied exactly as shown from the documentation into another file. Some of the time, programlisting will be sufficient to denote this text. But programlisting is not always appropriate, particularly when you want to include a portion of a file in-line with the rest of the paragraph. On these occasions, use literal. <sgmltag>literal</sgmltag> Usage: paraThe literalmaxusers 10literal line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support.para Appearance: The maxusers 10 line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support. Showing Items That the User <emphasis>Must</emphasis> Fill In There will often be times when the user is shown what to do, or referred to a file or command line, but cannot simply copy the example provided. Instead, they must supply some information themselves. replaceable is designed for this eventuality. Use it inside other elements to indicate parts of that element's content that the user must replace. <sgmltag>replaceable</sgmltag> Usage: screen&prompt.user; userinputman replaceablecommandreplaceableuserinputscreen Appearance: &prompt.user; man command replaceable can be used in many different elements, including literal. This example also shows that replaceable should only be wrapped around the content that the user is meant to provide. The other content should be left alone. Usage: paraThe literalmaxusers replaceablenreplaceableliteral line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support.para paraFor a desktop workstation, literal32literal is a good value for replaceablenreplaceable.para Appearance: The maxusers n line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support. For a desktop workstation, 32 is a good value for n. Showing <acronym>GUI</acronym> Buttons Buttons presented by a graphical user interface are marked with guibutton. To make the text look more like a graphical button, brackets and non-breaking spaces are added surrounding the text. <sgmltag>guibutton</sgmltag> Usage: paraEdit the file, then click guibutton[&nbsp;Save&nbsp;]guibutton to save the changes.para Appearance: Edit the file, then click [ Save ] to save the changes. Quoting System Errors System errors generated by &os; are marked with errorname. This indicates the exact error that appears. <sgmltag>errorname</sgmltag> Usage: screenerrornamePanic: cannot mount rooterrornamescreen Appearance: Panic: cannot mount root Images Image support in the documentation is somewhat experimental. The mechanisms described here are unlikely to change, but that is not guaranteed. To provide conversion between different image formats, the graphics/ImageMagick port must be installed. This port is not included in the textproc/docproj meta port, and must be installed separately. A good example of the use of images is the doc/en_US.ISO8859-1/articles/vm-design/ document. Examine the files in that directory to see how these elements are used together. Build different output formats to see how the format determines what images are shown in the rendered document. Image Formats Two image formats are currently supported. The type of image determines which format to use. Images that are primarily vector based, such as network diagrams, time lines, and similar, should be in EPS (Encapsulated Postscript) format. These images have a .eps extension. For bitmaps, such as screen captures, use the PNG (Portable Network Graphic) format. These images have the .png extension. These are the only formats in which images should be committed to the documentation repository. Use the appropriate format for each image. Documentation will often have a mix of EPS and PNG images. The Makefiles ensure that the correct format image is chosen depending on the output format used. Do not commit the same image to the repository in two different formats. The Documentation Project may eventually switch to using the SVG (Scalable Vector Graphic) format for vector images. However, the current state of SVG capable editing tools makes this impractical. Image File Locations Image files can be stored in one of several locations, depending on the document and image: In the same directory as the document itself, usually done for articles and small books that keep all their files in a single directory. In a subdirectory of the main document. Typically done when a large book uses separate subdirectories to organize individual chapters. When images are stored in a subdirectory of the main document directory, the subdirectory name must be included in their paths in the Makefile and the imagedata element. In a subdirectory of doc/share/images named after the document. For example, images for the Handbook are stored in doc/share/images/books/handbook. Images that work for multiple translations are stored in this upper level of the documentation file tree. Generally, these are images that can be used unchanged in non-English translations of the document. Image Markup Images are included as part of a mediaobject. The mediaobject can contain other, more specific objects. We are concerned with two, the imageobject and the textobject. Include one imageobject, and two textobject elements. The imageobject will point to the name of the image file without the extension. The textobject elements contain information that will be presented to the user as well as, or instead of, the image itself. Text elements are shown to the reader in several situations. When the document is viewed in HTML, text elements are shown while the image is loading, or if the mouse pointer is hovered over the image, or if a text-only browser is being used. In formats like plain text where graphics are not possible, the text elements are shown instead of the graphical ones. This example shows how to include an image called fig1.png in a document. The image is a rectangle with an A inside it: mediaobject imageobject imagedata fileref="fig1" imageobject textobject literallayout class="monospaced"+---------------+ | A | +---------------+literallayout textobject textobject phraseA picturephrase textobject mediaobject Include an imagedata element inside the imageobject element. The fileref attribute should contain the filename of the image to include, without the extension. The stylesheets will work out which extension should be added to the filename automatically. The first textobject contains a literallayout element, where the class attribute is set to monospaced. This is an opportunity to demonstrate ASCII art skills. This content will be used if the document is converted to plain text. Notice how the first and last lines of the content of the literallayout element butt up next to the element's tags. This ensures no extraneous white space is included. The second textobject contains a single phrase element. The contents of this phrase will become the alt attribute for the image when this document is converted to HTML. Image <filename>Makefile</filename> Entries Images must be listed in the Makefile in the IMAGES variable. This variable must contain the names of all the source images. For example, if there are three figures, fig1.eps, fig2.png, fig3.png, then the Makefile should have lines like this in it. … IMAGES= fig1.eps fig2.png fig3.png … or … IMAGES= fig1.eps IMAGES+= fig2.png IMAGES+= fig3.png … Again, the Makefile will work out the complete list of images it needs to build the source document, you only need to list the image files you provided. Images and Chapters in Subdirectories Be careful when separating documentation into smaller files in different directories (see ). Suppose there is a book with three chapters, and the chapters are stored in their own directories, called chapter1/chapter.xml, chapter2/chapter.xml, and chapter3/chapter.xml. If each chapter has images associated with it, place those images in each chapter's subdirectory (chapter1/, chapter2/, and chapter3/). However, doing this requires including the directory names in the IMAGES variable in the Makefile, and including the directory name in the imagedata element in the document document. For example, if the book has chapter1/fig1.png, then chapter1/chapter.xml should contain: mediaobject imageobject imagedata fileref="chapter1/fig1" imageobjectmediaobject The directory name must be included in the fileref attribute. The Makefile must contain: … IMAGES= chapter1/fig1.png … Links Links are also in-line elements. <literal>id</literal> Attributes Most DocBook elements accept an id attribute to give that part of the document a unique name. The id can be used as a target for a crossreference or link. Any portion of the document that will be a link target must have an id attribute. Assigning an id to all chapters and sections, even if there are no current plans to link to them, is a good idea. These ids can be used as unique anchor reference points by anyone referring to the HTML version of the document. <literal>id</literal> on Chapters and Sections chapter id="introduction" titleIntroductiontitle paraThis is the introduction. It contains a subsection, which is identified as well.para sect1 id="introduction-moredetails" titleMore Detailstitle paraThis is a subsection.para sect1 chapter Use descriptive values for id names. The values must be unique within the entire document, not just in a single file. In the example, the subsection id is constructed by appending text to the chapter id. This ensures that the ids are unique. It also helps both reader and anyone editing the document to see where the link is located within the document, similar to a directory path to a file. To allow the user to jump into a specific portion of the document, even in the middle of a paragraph or an example, use anchor. This element has no content, but takes an id attribute. <sgmltag>anchor</sgmltag> paraThis paragraph has an embedded anchor id="para1"link target in it. It will not show up in the document.para Crossreferences with <literal>xref</literal> xref provides the reader with a link to jump to another section of the document. The target id is specified in the linkend attribute, and xref generates the link text automatically. Using <sgmltag>xref</sgmltag> Assume that this fragment appears somewhere in a document that includes the id example shown above: paraMore information can be found in xref linkend="introduction".para paraMore specific information can be found in xref linkend="introduction-moredetails".para The link text will be generated automatically, looking like (emphasized text indicates the link text):
More information can be found in Chapter 1, Introduction. More specific information can be found in Section 1.1, More Details.
The link text is generated automatically from the chapter and section number and title elements. xref cannot link to an id attribute on an anchor element. The anchor has no content, so the xref cannot generate the link text.
Linking to the Same Document or Other Documents on the Web The link elements described here allow the writer to define the link text. It is very important to use descriptive link text to give the reader an idea of where the link will take them. Remember that DocBook can be rendered to multiple types of media. The reader may be looking at a printed book or other form of media where there are no links. If the link text is not descriptive enough, the reader may not be able to locate the linked section. Links to the Same Document link is used to create a link within the same document. The target id is specified in the linkend attribute. This element wraps content, which is used for the link text. Using <sgmltag>link</sgmltag> Assume that this fragment appears somewhere in a document that includes the id example. paraMore information can be found in the link linkend="introduction"sample introductionlink.para paraMore specific information can be found in the link linkend="introduction-moredetails"sample introduction with more detailslink section.para This output will be generated (emphasized text is used to show the link text):
More information can be found in the sample introduction. More specific information can be found in the sample introduction with more details section.
link can be used to include links to the id of an anchor element, since the link content defines the link text.
Linking to Other Documents on the Web The ulink is used to link to external documents on the web. The url attribute is the URL of the page that the link points to, and the content of the element is the text that will be displayed for the user to activate. <sgmltag>ulink</sgmltag> to a &os; Documentation Web Page Link to the book or article URL entity. To link to a specific chapter in a book, add a slash and the chapter file name, followed by an optional anchor within the chapter. For articles, link to the article URL entity, followed by an optional anchor within the article. URL entities can be found in doc/share/xml/urls.ent. Usage for book links: paraRead the ulink url="&url.books.handbook;/svn.html#svn-intro"SVN introductionulink, then pick the nearest mirror from the list of ulink - url="&url.books.handbook;/subversion-mirrors.html"Subversion + url="&url.books.handbook;/svn-mirrors.html"Subversion mirror sitesulink.para Appearance: Read the SVN introduction, then pick the nearest mirror from the list of Subversion + url="&url.books.handbook;/svn-mirrors.html">Subversion mirror sites. Usage for article links: paraRead this ulink url="&url.articles.bsdl-gpl;"article about the BSD licenseulink, or just the ulink url="&url.articles.bsdl-gpl;#intro"introductionulink.para Appearance: Read this article about the BSD license, or just the introduction. <sgmltag>ulink</sgmltag> to a &os; Web Page Usage: paraOf course, you could stop reading this document and go to the ulink url="&url.base;/index.html"FreeBSD home pageulink instead.para Appearance: Of course, you could stop reading this document and go to the FreeBSD home page instead. <sgmltag>ulink</sgmltag> to an External Web Page Usage: paraWikipedia has an excellent reference on ulink url="http://en.wikipedia.org/wiki/GUID_Partition_Table"GUID Partition Tablesulink.para Appearance: Wikipedia has an excellent reference on GUID Partition Tables. The link text can be omitted to show the actual URL: paraWikipedia has an excellent reference on GUID Partition Tables: ulink url="http://en.wikipedia.org/wiki/GUID_Partition_Table"ulink.para Appearance: Wikipedia has an excellent reference on GUID Partition Tables: .
diff --git a/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.xml b/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.xml index c749efcaa3..d492ffde43 100644 --- a/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.xml +++ b/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.xml @@ -1,560 +1,560 @@ Writing Style Tips Technical documentation can be improved by consistent use of several principles. Most of these can be classified into three goals: be clear, be complete, and be concise. These goals can conflict with each other. Good writing consists of a balance between them. Be Clear Clarity is extremely important. The reader may be a novice, or reading the document in a second language. Strive for simple, uncomplicated text that clearly explains the concepts. Avoid flowery or embellished speech, jokes, or colloquial expressions. Write as simply and clearly as possible. Simple text is easier to understand and translate. Keep explanations as short, simple, and clear as possible. Avoid empty phrases like in order to, which usually just means to. Avoid potentially patronizing words like basically. Avoid Latin terms like i.e. or cf., which may be unknown outside of academic or scientific groups. Write in a formal style. Avoid addressing the reader as you. For example, say copy the file to /tmp rather than you can copy the file to /tmp. Give clear, correct, tested examples. A trivial example is better than no example. A good example is better yet. Do not give bad examples, identifiable by apologies or sentences like but really it should never be done that way. Bad examples are worse than no examples. Give good examples, because even when warned not to use the example as shown, the reader will usually just use the example as shown. Avoid weasel words like should, might, try, or could. These words imply that the speaker is unsure of the facts, and create doubt in the reader. Similarly, give instructions as imperative commands: not you should do this, but merely do this. Be Complete Do not make assumptions about the reader's abilities or skill level. Tell them what they need to know. Give links to other documents to provide background information without having to recreate it. Put yourself in the reader's place, anticipate the questions they will ask, and answer them. Be Concise While features should be documented completely, sometimes there is so much information that the reader cannot easily find the specific detail needed. The balance between being complete and being concise is a challenge. One approach is to have an introduction, then a quick start section that describes the most common situation, followed by an in-depth reference section. Guidelines To promote consistency between the myriad authors of the &os; documentation, some guidelines have been drawn up for authors to follow. Use American English Spelling There are several variants of English, with different spellings for the same word. Where spellings differ, use the American English variant. color, not colour, rationalize, not rationalise, and so on. The use of British English may be accepted in the case of a contributed article, however the spelling must be consistent within the whole document. The other documents such as books, web site, manual pages, etc. will have to use American English. Do not use contractions Do not use contractions. Always spell the phrase out in full. Don't use contractions is wrong. Avoiding contractions makes for a more formal tone, is more precise, and is slightly easier for translators. Use the serial comma In a list of items within a paragraph, separate each item from the others with a comma. Separate the last item from the others with a comma and the word and. For example:
This is a list of one, two and three items.
Is this a list of three items, one, two, and three, or a list of two items, one and two and three? It is better to be explicit and include a serial comma:
This is a list of one, two, and three items.
Avoid redundant phrases Do not use redundant phrases. In particular, the command, the file, and man command are often redundant. For example, commands: Wrong: Use the command svn to update sources. Right: Use svn to update sources. Filenames: Wrong: … in the filename /etc/rc.local Right: … in /etc/rc.local Manual page references (the second example uses citerefentry with the &man.csh.1; entity):. Wrong: See man csh for more information. Right: See &man.csh.1;. Two spaces between sentences Always use two spaces between sentences, as it improves readability and eases use of tools such as Emacs. A period and spaces followed by a capital letter does not always mark a new sentence, especially in names. Jordan K. Hubbard is a good example. It has a capital H following a period and a space, and is certainly not a new sentence.
For more information about writing style, see Elements of Style, by William Strunk.
Style Guide To keep the source for the documentation consistent when many different people are editing it, please follow these style conventions. Letter Case Tags are entered in lower case, para, not PARA. Text that appears in SGML contexts is generally written in upper case, <!ENTITY…>, and <!DOCTYPE…>, not <!entity…> and <!doctype…>. - + Acronyms Acronyms should be defined the first time they appear in a document, as in: Network Time Protocol (NTP). After the acronym has been defined, use the acronym alone unless it makes more sense contextually to use the whole term. Acronyms are usually defined only once per chapter or per document. All acronyms should be enclosed in acronym tags. - + Indentation The first line in each file starts with no indentation, regardless of the indentation level of the file which might contain the current file. Opening tags increase the indentation level by two spaces. Closing tags decrease the indentation level by two spaces. Blocks of eight spaces at the start of a line should be replaced with a tab. Do not use spaces in front of tabs, and do not add extraneous whitespace at the end of a line. Content within elements should be indented by two spaces if the content runs over more than one line. For example, the source for this section looks like this: chapter title...title sect1 title...title sect2 titleIndentationtitle paraThe first line in each file starts with no indentation, emphasisregardlessemphasis of the indentation level of the file which might contain the current file.para ... sect2 sect1 chapter Configurations to help various text editors conform to these guidelines can be found in . - + Tag Style - + Tag Spacing Tags that start at the same indent as a previous tag should be separated by a blank line, and those that are not at the same indent as a previous tag should not: article lang='en' articleinfo titleNIStitle pubdateOctober 1999pubdate abstract para... ... ...para abstract articleinfo sect1 title...title para...para sect1 sect1 title...title para...para sect1 article - + Separating Tags Tags like itemizedlist which will always have further tags inside them, and in fact do not take character data themselves, are always on a line by themselves. Tags like para and term do not need other tags to contain normal character data, and their contents begin immediately after the tag, on the same line. The same applies to when these two types of tags close. This leads to an obvious problem when mixing these tags. When a starting tag which cannot contain character data directly follows a tag of the type that requires other tags within it to use character data, they are on separate lines. The second tag should be properly indented. When a tag which can contain character data closes directly after a tag which cannot contain character data closes, they co-exist on the same line. - + Whitespace Changes Do not commit changes to content at the same time as changes to formatting. When content and whitespace changes are kept separate, translation teams can easily see whether a change was content that must be translated or only whitespace. For example, if two sentences have been added to a paragraph so that the line lengths now go over 80 columns, first commit the change with the too-long lines. Then fix the line wrapping, and commit this second change. In the commit message for the second change, indicate that this is a whitespace-only change that can be ignored by translators. - + Non-Breaking Space Avoid line breaks in places where they look ugly or make it difficult to follow a sentence. Line breaks depend on the width of the chosen output medium. In particular, viewing the HTML documentation with a text browser can lead to badly formatted paragraphs like the next one: Data capacity ranges from 40 MB to 15 GB. Hardware compression … The general entity &nbsp; prohibits line breaks between parts belonging together. Use non-breaking spaces in the following places: between numbers and units: 57600&nbsp;bps between program names and version numbers: &os;&nbsp;9.2 between multiword names (use with caution when applying this to more than 3-4 word names like The &os; Brazilian Portuguese Documentation Project): Word List This list of words shows the correct spelling and capitalization when used in &os; documentation. If a word is not on this list, ask about it on the &a.doc;. Word XML Code Notes CD-ROM acronymCD-ROMacronym DoS (Denial of Service) acronymDoSacronym email file system IPsec Internet manual page mail server name server Ports Collection read-only Soft Updates Subversion applicationSubversionapplication Do not refer to the Subversion application as SVN in upper case. To refer to the command, use commandsvncommand. &unix; &unix; web server
diff --git a/en_US.ISO8859-1/books/fdp-primer/xml-primer/chapter.xml b/en_US.ISO8859-1/books/fdp-primer/xml-primer/chapter.xml index a7ff166cba..1a436f380b 100644 --- a/en_US.ISO8859-1/books/fdp-primer/xml-primer/chapter.xml +++ b/en_US.ISO8859-1/books/fdp-primer/xml-primer/chapter.xml @@ -1,1520 +1,1520 @@ XML Primer Most FDP documentation is written with markup languages based on XML. This chapter explains what that means, how to read and understand the documentation source, and the XML techniques used. Portions of this section were inspired by Mark Galassi's Get Going With DocBook. Overview In the original days of computers, electronic text was simple. There were a few character sets like ASCII or EBCDIC, but that was about it. Text was text, and what you saw really was what you got. No frills, no formatting, no intelligence. Inevitably, this was not enough. When text is in a machine-usable format, machines are expected to be able to use and manipulate it intelligently. Authors want to indicate that certain phrases should be emphasized, or added to a glossary, or made into hyperlinks. Filenames could be shown in a typewriter style font for viewing on screen, but as italics when printed, or any of a myriad of other options for presentation. It was once hoped that Artificial Intelligence (AI) would make this easy. The computer would read the document and automatically identify key phrases, filenames, text that the reader should type in, examples, and more. Unfortunately, real life has not happened quite like that, and computers still require assistance before they can meaningfully process text. More precisely, they need help identifying what is what. Consider this text:
- To remove /tmp/foo use + To remove /tmp/foo, use &man.rm.1;. &prompt.user; rm /tmp/foo
It is easy to see which parts are filenames, which are commands to be typed in, which parts are references to manual pages, and so on. But the computer processing the document cannot. For this we need markup. Markup is commonly used to describe adding value or increasing cost. The term takes on both these meanings when applied to text. Markup is additional text included in the document, distinguished from the document's content in some way, so that programs that process the document can read the markup and use it when making decisions about the document. Editors can hide the markup from the user, so the user is not distracted by it. The extra information stored in the markup adds value to the document. Adding the markup to the document must typically be done by a person—after all, if computers could recognize the text sufficiently well to add the markup then there would be no need to add it in the first place. This increases the cost (the effort required) to create the document. The previous example is actually represented in this document like this: - paraTo remove filename/tmp/foofilename use &man.rm.1;.para + paraTo remove filename/tmp/foofilename, use &man.rm.1;.para -screen&prompt.user; userinputrm /tmp/foouserinputscreen +screen&prompt.user; userinputrm /tmp/foouserinputscreen The markup is clearly separate from the content. Markup languages define what the markup means and how it should be interpreted. Of course, one markup language might not be enough. A markup language for technical documentation has very different requirements than a markup language that is intended for cookery recipes. This, in turn, would be very different from a markup language used to describe poetry. What is really needed is a first language used to write these other markup languages. A meta markup language. This is exactly what the eXtensible Markup Language (XML) is. Many markup languages have been written in XML, including the two most used by the FDP, XHTML and DocBook. Each language definition is more properly called a grammar, vocabulary, schema or Document Type Definition (DTD). There are various languages to specify an XML grammar, or schema. A schema is a complete specification of all the elements that are allowed to appear, the order in which they should appear, which elements are mandatory, which are optional, and so forth. This makes it possible to write an XML parser which reads in both the schema and a document which claims to conform to the schema. The parser can then confirm whether or not all the elements required by the vocabulary are in the document in the right order, and whether there are any errors in the markup. This is normally referred to as validating the document. Validation confirms that the choice of elements, their ordering, and so on, conforms to that listed in the grammar. It does not check whether appropriate markup has been used for the content. If all the filenames in a document were marked up as function names, the parser would not flag this as an error (assuming, of course, that the schema defines elements for filenames and functions, and that they are allowed to appear in the same place). Most contributions to the Documentation Project will be content marked up in either XHTML or DocBook, rather than alterations to the schemas. For this reason, this book will not touch on how to write a vocabulary.
Elements, Tags, and Attributes All the vocabularies written in XML share certain characteristics. This is hardly surprising, as the philosophy behind XML will inevitably show through. One of the most obvious manifestations of this philosophy is that of content and elements. Documentation, whether it is a single web page, or a lengthy book, is considered to consist of content. This content is then divided and further subdivided into elements. The purpose of adding markup is to name and identify the boundaries of these elements for further processing. For example, consider a typical book. At the very top level, the book is itself an element. This book element obviously contains chapters, which can be considered to be elements in their own right. Each chapter will contain more elements, such as paragraphs, quotations, and footnotes. Each paragraph might contain further elements, identifying content that was direct speech, or the name of a character in the story. It may be helpful to think of this as chunking content. At the very top level is one chunk, the book. Look a little deeper, and there are more chunks, the individual chapters. These are chunked further into paragraphs, footnotes, character names, and so on. Notice how this differentiation between different elements of the content can be made without resorting to any XML terms. It really is surprisingly straightforward. This could be done with a highlighter pen and a printout of the book, using different colors to indicate different chunks of content. Of course, we do not have an electronic highlighter pen, so we need some other way of indicating which element each piece of content belongs to. In languages written in XML (XHTML, DocBook, et al) this is done by means of tags. A tag is used to identify where a particular element starts, and where the element ends. The tag is not part of the element itself. Because each grammar was normally written to mark up specific types of information, each one will recognize different elements, and will therefore have different names for the tags. For an element called element-name the start tag will normally look like element-name. The corresponding closing tag for this element is element-name. Using an Element (Start and End Tags) XHTML has an element for indicating that the content enclosed by the element is a paragraph, called p. pThis is a paragraph. It starts with the start tag for the 'p' element, and it will end with the end tag for the 'p' element.p pThis is another paragraph. But this one is much shorter.p Some elements have no content. For example, in XHTML, a horizontal line can be included in the document. For these empty elements, XML introduced a shorthand form that is completely equivalent to the two-tag version: Using an Element Without Content XHTML has an element for indicating a horizontal rule, called hr. This element does not wrap content, so it looks like this: pOne paragraph.p hrhr pThis is another paragraph. A horizontal rule separates this from the previous paragraph.p The shorthand version consists of a single tag: pOne paragraph.p hr pThis is another paragraph. A horizontal rule separates this from the previous paragraph.p As shown above, elements can contain other elements. In the book example earlier, the book element contained all the chapter elements, which in turn contained all the paragraph elements, and so on. Elements Within Elements; <sgmltag>em</sgmltag> pThis is a simple emparagraphem where some of the emwordsem have been ememphasizedem.p The grammar consists of rules that describe which elements can contain other elements, and exactly what they can contain. People often confuse the terms tags and elements, and use the terms as if they were interchangeable. They are not. An element is a conceptual part of your document. An element has a defined start and end. The tags mark where the element starts and ends. When this document (or anyone else knowledgeable about XML) refers to the p tag they mean the literal text consisting of the three characters <, p, and >. But the phrase the p element refers to the whole element. This distinction is very subtle. But keep it in mind. Elements can have attributes. An attribute has a name and a value, and is used for adding extra information to the element. This might be information that indicates how the content should be rendered, or might be something that uniquely identifies that occurrence of the element, or it might be something else. An element's attributes are written inside the start tag for that element, and take the form attribute-name="attribute-value". In XHTML, the p element has an attribute called align, which suggests an alignment (justification) for the paragraph to the program displaying the XHTML. The align attribute can take one of four defined values, left, center, right and justify. If the attribute is not specified then the default is left. Using an Element with an Attribute p align="left"The inclusion of the align attribute on this paragraph was superfluous, since the default is left.p p align="center"This may appear in the center.p Some attributes only take specific values, such as left or justify. Others allow any value. Single Quotes Around Attributes p align='right'I am on the right!p Attribute values in XML must be enclosed in either single or double quotes. Double quotes are traditional. Single quotes are useful when the attribute value contains double quotes. Information about attributes, elements, and tags is stored in catalog files. The Documentation Project uses standard DocBook catalogs and includes additional catalogs for &os;-specific features. Paths to the catalog files are defined in an environment variable so they can be found by the document build tools. To Do… Before running the examples in this document, application software must be installed and the catalog environment variable configured. Install textproc/docproj from the &os; Ports Collection. This is a meta-port that downloads and installs the standard programs and supporting files needed by the Documentation Project. Add lines to the shell startup files to set SGML_CATALOG_FILES. When working on non-English versions of the documentation, replace en_US.ISO8859-1 with the appropriate directory for the target language. <filename>.profile</filename>, for &man.sh.1; and &man.bash.1; Users SGML_ROOT=/usr/local/share/xml SGML_CATALOG_FILES=${SGML_ROOT}/jade/catalog SGML_CATALOG_FILES=${SGML_ROOT}/docbook/4.1/catalog:$SGML_CATALOG_FILES SGML_CATALOG_FILES=${SGML_ROOT}/html/catalog:$SGML_CATALOG_FILES SGML_CATALOG_FILES=${SGML_ROOT}/iso8879/catalog:$SGML_CATALOG_FILES SGML_CATALOG_FILES=/usr/doc/share/xml/catalog:$SGML_CATALOG_FILES SGML_CATALOG_FILES=/usr/doc/en_US.ISO8859-1/share/xml/catalog:$SGML_CATALOG_FILES export SGML_CATALOG_FILES <filename>.cshrc</filename>, for &man.csh.1; and &man.tcsh.1; Users setenv SGML_ROOT /usr/local/share/xml setenv SGML_CATALOG_FILES ${SGML_ROOT}/jade/catalog setenv SGML_CATALOG_FILES ${SGML_ROOT}/docbook/4.1/catalog:$SGML_CATALOG_FILES setenv SGML_CATALOG_FILES ${SGML_ROOT}/html/catalog:$SGML_CATALOG_FILES setenv SGML_CATALOG_FILES ${SGML_ROOT}/iso8879/catalog:$SGML_CATALOG_FILES setenv SGML_CATALOG_FILES /usr/doc/share/xml/catalog:$SGML_CATALOG_FILES setenv SGML_CATALOG_FILES /usr/doc/en_US.ISO8859-1/share/xml/catalog:$SGML_CATALOG_FILES After making these changes, either log out and log back in again, or run the commands from the command line to set the variable values. Create example.xml, and enter this text: !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" html xmlns="http://www.w3.org/1999/xhtml" head titleAn Example XHTML Filetitle head body pThis is a paragraph containing some text.p pThis paragraph contains some more text.p p align="right"This paragraph might be right-justified.p body html Try to validate this file using an XML parser. textproc/docproj includes the xmllint validating parser. Use xmllint to validate the document: &prompt.user; xmllint --valid --noout example.xml xmllint returns without displaying any output, showing that the document validated successfully. See what happens when required elements are omitted. Delete the line with the title and /title tags, and re-run the validation. &prompt.user; xmllint --valid --noout example.xml example.xml:5: element head: validity error : Element head content does not follow the DTD, expecting ((script | style | meta | link | object | isindex)* , ((title , (script | style | meta | link | object | isindex)* , (base , (script | style | meta | link | object | isindex)*)?) | (base , (script | style | meta | link | object | isindex)* , title , (script | style | meta | link | object | isindex)*))), got () This shows that the validation error comes from the fifth line of the example.xml file and that the content of the head is the part which does not follow the rules of the XHTML grammar. Then xmllint shows the line where the error was found and marks the exact character position with a ^ sign. Replace the title element. The DOCTYPE Declaration The beginning of each document can specify the name of the DTD to which the document conforms. This DOCTYPE declaration is used by XML parsers to identify the DTD and ensure that the document does conform to it. A typical declaration for a document written to conform with version 1.0 of the XHTML DTD looks like this: !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" That line contains a number of different components. <! The indicator shows this is an XML declaration. DOCTYPE Shows that this is an XML declaration of the document type. html Names the first element that will appear in the document. PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" Lists the Formal Public Identifier (FPI) Formal Public Identifier for the DTD to which this document conforms. The XML parser uses this to find the correct DTD when processing this document. PUBLIC is not a part of the FPI, but indicates to the XML processor how to find the DTD referenced in the FPI. Other ways of telling the XML parser how to find the DTD are shown later. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" A local filename or a URL to find the DTD. > Ends the declaration and returns to the document. Formal Public Identifiers (<acronym>FPI</acronym>s) Formal Public Identifier It is not necessary to know this, but it is useful background, and might help debug problems when the XML processor can not locate the DTD. FPIs must follow a specific syntax: "Owner//Keyword Description//Language" Owner The owner of the FPI. The beginning of the string identifies the owner of the FPI. For example, the FPI "ISO 8879:1986//ENTITIES Greek Symbols//EN" lists ISO 8879:1986 as being the owner for the set of entities for Greek symbols. ISO 8879:1986 is the International Organization for Standardization (ISO) number for the SGML standard, the predecessor (and a superset) of XML. Otherwise, this string will either look like -//Owner or +//Owner (notice the only difference is the leading + or -). If the string starts with - then the owner information is unregistered, with a + identifying it as registered. ISO 9070:1991 defines how registered names are generated. It might be derived from the number of an ISO publication, an ISBN code, or an organization code assigned according to ISO 6523. Additionally, a registration authority could be created in order to assign registered names. The ISO council delegated this to the American National Standards Institute (ANSI). Because the &os; Project has not been registered, the owner string is -//&os;. As seen in the example, the W3C are not a registered owner either. Keyword There are several keywords that indicate the type of information in the file. Some of the most common keywords are DTD, ELEMENT, ENTITIES, and TEXT. DTD is used only for DTD files, ELEMENT is usually used for DTD fragments that contain only entity or element declarations. TEXT is used for XML content (text and tags). Description Any description can be given for the contents of this file. This may include version numbers or any short text that is meaningful and unique for the XML system. Language An ISO two-character code that identifies the native language for the file. EN is used for English. <filename>catalog</filename> Files With the syntax above, an XML processor needs to have some way of turning the FPI into the name of the file containing the DTD. A catalog file (typically called catalog) contains lines that map FPIs to filenames. For example, if the catalog file contained the line: PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "1.0/transitional.dtd" The XML processor knows that the DTD is called transitional.dtd in the 1.0 subdirectory of the directory that held catalog. Examine the contents of /usr/local/share/xml/dtd/xhtml/catalog.xml. This is the catalog file for the XHTML DTDs that were installed as part of the textproc/docproj port. <envar>SGML_CATALOG_FILES</envar> To locate a catalog, the XML processor must know where to look. Many feature command line parameters for specifying the path to one or more catalogs. In addition, SGML_CATALOG_FILES can be set to point to the files. This environment variable consists of a colon-separated list of catalog files (including their full path). Typically, the list includes these files: /usr/local/share/xml/docbook/4.1/catalog /usr/local/share/xml/html/catalog /usr/local/share/xml/iso8879/catalog /usr/local/share/xml/jade/catalog This was done earlier. Alternatives to <acronym>FPI</acronym>s Instead of using an FPI to indicate the DTD to which the document conforms (and therefore, which file on the system contains the DTD), the filename can be explicitly specified. The syntax is slightly different: !DOCTYPE html SYSTEM "/path/to/file.dtd" The SYSTEM keyword indicates that the XML processor should locate the DTD in a system specific fashion. This typically (but not always) means the DTD will be provided as a filename. Using FPIs is preferred for reasons of portability. If the SYSTEM identifier is used, then the DTD must be provided and kept in the same location for everyone. Escaping Back to <acronym>XML</acronym> Some of the underlying XML syntax can be useful within documents. For example, comments can be included in the document, and will be ignored by the parser. Comments are entered using XML syntax. Other uses for XML syntax will be shown later. XML sections begin with a <! tag and end with a >. These sections contain instructions for the parser rather than elements of the document. Everything between these tags is XML syntax. The DOCTYPE declaration shown earlier is an example of XML syntax included in the document. Comments Comments are an XML construct, and are normally only valid inside a DTD. However, as shows, it is possible to use XML syntax within the document. The delimiter for XML comments is the string --. The first occurrence of this string opens a comment, and the second closes it. <acronym>XML</acronym> Generic Comment <!-- This is inside the comment --> <!-- This is another comment --> <!-- This is one way of doing multiline comments --> <!-- This is another way of -- -- doing multiline comments --> XHTML users may be familiar with different rules for comments. In particular, it is often believed that the string <!-- opens a comment, and it is only closed by -->. This is not correct. Many web browsers have broken XHTML parsers, and will accept incorrect input as valid. However, the XML parsers used by the Documentation Project are more strict, and will reject documents with that error. Erroneous <acronym>XML</acronym> Comments <!-- This is in the comment -- THIS IS OUTSIDE THE COMMENT! -- back inside the comment --> The XML parser will treat this as though it were actually: <!THIS IS OUTSIDE THE COMMENT> That is not valid XML, and may give confusing error messages. To Do… Add some comments to example.xml, and check that the file still validates using xmllint. Add some invalid comments to example.xml, and see the error messages that xmllint gives when it encounters an invalid comment. Entities Entities are a mechanism for assigning names to chunks of content. As an XML parser processes a document, any entities it finds are replaced by the content of the entity. This is a good way to have re-usable, easily changeable chunks of content in XML documents. It is also the only way to include one marked up file inside another using XML. There are two types of entities for two different situations: general entities and parameter entities. General Entities General entities are used to assign names to reusable chunks of text. These entities can only be used in the document. They cannot be used in an XML context. To include the text of a general entity in the document, include &entity-name; in the text. For example, consider a general entity called current.version which expands to the current version number of a product. To use it in the document, write: paraThe current version of our product is &current.version;.para When the version number changes, edit the definition of the general entity, replacing the value. Then reprocess the document. General entities can also be used to enter characters that could not otherwise be included in an XML document. For example, < and & cannot normally appear in an XML document. The XML parser sees the < symbol as the start of a tag. Likewise, when the & symbol is seen, the next text is expected to be an entity name. These symbols can be included by using two predefined general entities: &lt; and &amp;. General entities can only be defined within an XML context. Such definitions are usually done immediately after the DOCTYPE declaration. Defining General Entities <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY current.version "3.0-RELEASE"> <!ENTITY last.version "2.2.7-RELEASE"> ]> The DOCTYPE declaration has been extended by adding a square bracket at the end of the first line. The two entities are then defined over the next two lines, the square bracket is closed, and then the DOCTYPE declaration is closed. The square brackets are necessary to indicate that the DTD indicated by the DOCTYPE declaration is being extended. Parameter Entities Parameter entities, like general entities, are used to assign names to reusable chunks of text. But parameter entities can only be used within an XML context. Parameter entity definitons are similar to those for general entities. However, parameter entries are included with %entity-name;. The definition also includes the % between the ENTITY keyword and the name of the entity. For a mnemonic, think Parameter entities use the Percent symbol. Defining Parameter Entities <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY % param.some "some"> <!ENTITY % param.text "text"> <!ENTITY % param.new "%param.some more %param.text"> <!-- %param.new now contains "some more text" --> ]> To Do… Add a general entity to example.xml. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY version "1.1"> ]> html xmlns="http://www.w3.org/1999/xhtml" head titleAn Example XHTML Filetitle head <!-- There may be some comments in here as well --> body pThis is a paragraph containing some text.p pThis paragraph contains some more text.p p align="right"This paragraph might be right-justified.p pThe current version of this document is: &version;p body html Validate the document using xmllint. Load example.xml into a web browser. It may have to be copied to example.html before the browser recognizes it as an XHTML document. Older browsers with simple parsers may not render this file as expected. The entity reference &version; may not be replaced by the version number, or the XML context closing ]< may not be recognized and instead shown in the output. The solution is to normalize the document with an XML normalizer. The normalizer reads valid XML and writes equally valid XML which has been transformed in some way. One way the normalizer transforms the input is by expanding all the entity references in the document, replacing the entities with the text that they represent. xmllint can be used for this. It also has an option to drop the initial DTD section so that the closing ]< does not confuse browsers: &prompt.user; xmllint --noent --dropdtd example.xml > example.html A normalized copy of the document with entities expanded is produced in example.html, ready to load into a web browser. Using Entities to Include Files Both general and parameter entities are particularly useful for including one file inside another. Using General Entities to Include Files Consider some content for an XML book organized into files, one file per chapter, called chapter1.xml, chapter2.xml, and so forth, with a book.xml that will contain these chapters. In order to use the contents of these files as the values for entities, they are declared with the SYSTEM keyword. This directs the XML parser to include the contents of the named file as the value of the entity. Using General Entities to Include Files <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY chapter.1 SYSTEM "chapter1.xml"> <!ENTITY chapter.2 SYSTEM "chapter2.xml"> <!ENTITY chapter.3 SYSTEM "chapter3.xml"> <!-- And so forth --> ]> html xmlns="http://www.w3.org/1999/xhtml" <!-- Use the entities to load in the chapters --> &chapter.1; &chapter.2; &chapter.3; html When using general entities to include other files within a document, the files being included (chapter1.xml, chapter2.xml, and so on) must not start with a DOCTYPE declaration. This is a syntax error because entities are low-level constructs and they are resolved before any parsing happens. Using Parameter Entities to Include Files Parameter entities can only be used inside an XML context. Including a file in an XML context can be used to ensure that general entities are reusable. Suppose that there are many chapters in the document, and these chapters were reused in two different books, each book organizing the chapters in a different fashion. The entities could be listed at the top of each book, but that quickly becomes cumbersome to manage. Instead, place the general entity definitions inside one file, and use a parameter entity to include that file within the document. Using Parameter Entities to Include Files Place the entity definitions in a separate file called chapters.ent and containing this text: <!ENTITY chapter.1 SYSTEM "chapter1.xml"> <!ENTITY chapter.2 SYSTEM "chapter2.xml"> <!ENTITY chapter.3 SYSTEM "chapter3.xml"> Create a parameter entity to refer to the contents of the file. Then use the parameter entity to load the file into the document, which will then make all the general entities available for use. Then use the general entities as before: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!-- Define a parameter entity to load in the chapter general entities --> <!ENTITY % chapters SYSTEM "chapters.ent"> <!-- Now use the parameter entity to load in this file --> %chapters; ]> html xmlns="http://www.w3.org/1999/xhtml" &chapter.1; &chapter.2; &chapter.3; html To Do… Use General Entities to Include Files Create three files, para1.xml, para2.xml, and para3.xml. Put content like this in each file: pThis is the first paragraph.p Edit example.xml so that it looks like this: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY version "1.1"> <!ENTITY para1 SYSTEM "para1.xml"> <!ENTITY para2 SYSTEM "para2.xml"> <!ENTITY para3 SYSTEM "para3.xml"> ]> html xmlns="http://www.w3.org/1999/xhtml" head titleAn Example XHTML Filetitle head body pThe current version of this document is: &version;p &para1; &para2; &para3; body html Produce example.html by normalizing example.xml. &prompt.user; xmllint --dropdtd --noent example.xml > example.html Load example.html into the web browser and confirm that the paran.xml files have been included in example.html. Use Parameter Entities to Include Files The previous steps must have completed before this step. Edit example.xml so that it looks like this: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ENTITY % entities SYSTEM "entities.ent"> %entities; ]> html xmlns="http://www.w3.org/1999/xhtml" head titleAn Example XHTML Filetitle head body pThe current version of this document is: &version;p &para1; &para2; &para3; body html Create a new file called entities.ent with this content: <!ENTITY version "1.1"> <!ENTITY para1 SYSTEM "para1.xml"> <!ENTITY para2 SYSTEM "para2.xml"> <!ENTITY para3 SYSTEM "para3.xml"> Produce example.html by normalizing example.xml. &prompt.user; xmllint --dropdtd --noent example.xml > example.html Load example.html into the web browser and confirm that the paran.xml files have been included in example.html. Marked Sections XML provides a mechanism to indicate that particular pieces of the document should be processed in a special way. These are called marked sections. Structure of a Marked Section <![KEYWORD[ Contents of marked section ]]> As expected of an XML construct, a marked section starts with <!. The first square bracket begins the marked section. KEYWORD describes how this marked section is to be processed by the parser. The second square bracket indicates the start of the marked section's content. The marked section is finished by closing the two square brackets, and then returning to the document context from the XML context with >. Marked Section Keywords <literal>CDATA</literal> These keywords denote the marked sections content model, and allow you to change it from the default. When an XML parser is processing a document, it keeps track of the content model. The content model describes the content the parser is expecting to see and what it will do with that content. The CDATA content model is one of the most useful. CDATA is for Character Data. When the parser is in this content model, it expects to see only characters. In this model the < and & symbols lose their special status, and will be treated as ordinary characters. When using CDATA in examples of text marked up in XML, remember that the content of CDATA is not validated. The included text must be check with other means. For example, the content could be written in another document, validated, and then pasted into the CDATA section. Using a <literal>CDATA</literal> Marked Section paraHere is an example of how to include some text that contains many literal&lt;literal and literal&amp;literal symbols. The sample text is a fragment of acronymXHTMLacronym. The surrounding text (para and programlisting) are from DocBook.para programlisting<![CDATA[pThis is a sample that shows some of the elements within acronymXHTMLacronym. Since the angle brackets are used so many times, it is simpler to say the whole example is a CDATA marked section than to use the entity names for the left and right angle brackets throughout.p ul liThis is a listitemli liThis is a second listitemli liThis is a third listitemli ul pThis is the end of the example.p]]>programlisting <literal>INCLUDE</literal> and <literal>IGNORE</literal> When the keyword is INCLUDE, then the contents of the marked section will be processed. When the keyword is IGNORE, the marked section is ignored and will not be processed. It will not appear in the output. Using <literal>INCLUDE</literal> and <literal>IGNORE</literal> in Marked Sections <![INCLUDE[ This text will be processed and included. ]]> <![IGNORE[ This text will not be processed or included. ]]> By itself, this is not too useful. Text to be removed from the document could be cut out, or wrapped in comments. It becomes more useful when controlled by parameter entities, yet this usage is limited to entity files. For example, suppose that documentation was produced in a hard-copy version and an electronic version. Some extra text is desired in the electronic version content that was not to appear in the hard-copy. Create an entity file that defines general entities to include each chapter and guard these definitions with a parameter entity that can be set to either INCLUDE or IGNORE to control whether the entity is defined. After these conditional general entity definitions, place one more definition for each general entity to set them to an empty value. This technique makes use of the fact that entity definitions cannot be overridden but the first definition always takes effect. So the inclusion of the chapter is controlled with the corresponding parameter entity. Set to INCLUDE, the first general entity definition will be read and the second one will be ignored. Set to IGNORE, the first definition will be ignored and the second one will take effect. Using a Parameter Entity to Control a Marked Section <!ENTITY % electronic.copy "INCLUDE"> <![%electronic.copy;[ <!ENTITY chap.preface SYSTEM "preface.xml"> ]]> <!ENTITY chap.preface ""> When producing the hard-copy version, change the parameter entity's definition to: <!ENTITY % electronic.copy "IGNORE"> To Do… Modify entities.ent to contain the following: <!ENTITY version "1.1"> <!ENTITY % conditional.text "IGNORE"> <![%conditional.text;[ <!ENTITY para1 SYSTEM "para1.xml"> ]]> <!ENTITY para1 ""> <!ENTITY para2 SYSTEM "para2.xml"> <!ENTITY para3 SYSTEM "para3.xml"> Normalize example.xml and notice that the conditional text is not present in the output document. Set the parameter entity guard to INCLUDE and regenerate the normalized document and the text will appear again. This method makes sense if there are more conditional chunks depending on the same condition. For example, to control generating printed or online text. Conclusion That is the conclusion of this XML primer. For reasons of space and complexity, several things have not been covered in depth (or at all). However, the previous sections cover enough XML to introduce the organization of the FDP documentation.
diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.xml b/en_US.ISO8859-1/books/handbook/config/chapter.xml index 1653f20602..004f4205fc 100644 --- a/en_US.ISO8859-1/books/handbook/config/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/config/chapter.xml @@ -1,3486 +1,3481 @@ Chern Lee Written by Mike Smith Based on a tutorial written by Matt Dillon Also based on tuning(7) written by Configuration and Tuning Synopsis system configuration system optimization One of the important aspects of &os; is proper system configuration. This chapter explains much of the &os; configuration process, including some of the parameters which can be set to tune a &os; system. After reading this chapter, you will know: How to efficiently work with file systems and swap partitions. The basics of rc.conf configuration and /usr/local/etc/rc.d startup scripts. How to configure and test a network card. How to configure virtual hosts on network devices. How to use the various configuration files in /etc. How to tune &os; using &man.sysctl.8; variables. How to tune disk performance and modify kernel limitations. Before reading this chapter, you should: Understand &unix; and &os; basics (). Be familiar with the basics of kernel configuration and compilation (). Initial Configuration Partition Layout partition layout /etc /var /usr Base Partitions When laying out file systems with &man.bsdlabel.8; or &man.sysinstall.8;, remember that hard drives transfer data faster from the outer tracks to the inner. Thus, smaller and heavier-accessed file systems should be closer to the outside of the drive, while larger partitions like /usr should be placed toward the inner parts of the disk. It is a good idea to create partitions in an order similar to: /, swap, /var, and /usr. The size of the /var partition reflects the intended machine's usage. This partition is used to hold mailboxes, log files, and printer spools. Mailboxes and log files can grow to unexpected sizes depending on the number of users and how long log files are kept. On average, most users rarely need more than about a gigabyte of free disk space in /var. Sometimes, a lot of disk space is required in /var/tmp. When new software is installed with &man.pkg.add.1;, the packaging tools extract a temporary copy of the packages under /var/tmp. Large software packages, like Firefox, OpenOffice or LibreOffice may be tricky to install if there is not enough disk space under /var/tmp. The /usr partition holds many of the files which support the system, including the &os; Ports Collection and system source code. At least 2 gigabytes is recommended for this partition. When selecting partition sizes, keep the space requirements in mind. Running out of space in one partition while barely using another can be a hassle. The Auto-defaults partition sizer used by &man.sysinstall.8; will sometimes select smaller than adequate /var and / partitions. Partition wisely and generously. Swap Partition swap sizing swap partition As a rule of thumb, the swap partition should be about double the size of physical memory (RAM) as the kernel's virtual memory (VM) paging algorithms are tuned to perform best when the swap partition is at least two times the size of main memory. Systems with minimal RAM may perform better with more swap. Configuring too little swap can lead to inefficiencies in the VM page scanning code and might create issues later if more memory is added. On larger systems with multiple SCSI disks or multiple IDE disks operating on different controllers, it is recommended that swap be configured on each drive, up to four drives. The swap partitions should be approximately the same size. The kernel can handle arbitrary sizes but internal data structures scale to 4 times the largest swap partition. Keeping the swap partitions near the same size will allow the kernel to optimally stripe swap space across disks. Large swap sizes are fine, even if swap is not used much. It might be easier to recover from a runaway program before being forced to reboot. Why Partition? Several users think a single large partition will be fine, but there are several reasons why this is a bad idea. First, each partition has different operational characteristics and separating them allows the file system to tune accordingly. For example, the root and /usr partitions are read-mostly, with few writes, while a lot of reads and writes could occur in /var and /var/tmp. By properly partitioning a system, fragmentation introduced in the smaller write heavy partitions will not bleed over into the mostly read partitions. Keeping the write loaded partitions closer to the disk's edge will increase I/O performance in the partitions where it occurs the most. While I/O performance in the larger partitions may be needed, shifting them more toward the edge of the disk will not lead to a significant performance improvement over moving /var to the edge. Finally, there are safety concerns. A smaller, neater root partition which is mostly read-only has a greater chance of surviving a bad crash. Core Configuration rc files rc.conf The principal location for system configuration information is /etc/rc.conf. This file contains a wide range of configuration information and it is read at system startup to configure the system. It provides the configuration information for the rc* files. The entries in /etc/rc.conf override the default settings in /etc/defaults/rc.conf. The file containing the default settings should not be edited. Instead, all system-specific changes should be made to /etc/rc.conf. A number of strategies may be applied in clustered applications to separate site-wide configuration from system-specific configuration in order to keep administration overhead down. The recommended approach is to place system-specific configuration into /etc/rc.conf.local. For example: /etc/rc.conf: sshd_enable="YES" keyrate="fast" defaultrouter="10.1.1.254" - /etc/rc.conf.local: hostname="node1.example.org" ifconfig_fxp0="inet 10.1.1.1/8" - Distribute /etc/rc.conf to every system using rsync or a similar program, while /etc/rc.conf.local remains unique. Upgrading the system using &man.sysinstall.8; or make world will not overwrite /etc/rc.conf, so system configuration information will not be lost. The configuration in /etc/rc.conf is parsed by &man.sh.1;. This allows system operators to create complex configuration scenarios. Refer to &man.rc.conf.5; for further information on this topic. Application Configuration Typically, installed applications have their own configuration files and syntax. It is important that these files be kept separate from the base system, so that they may be easily located and managed by the package management tools. /usr/local/etc Typically, these files are installed in /usr/local/etc. In the case where an application has a large number of configuration files, a subdirectory will be created to hold them. Normally, when a port or package is installed, sample configuration files are also installed. These are usually identified with a suffix such as .sample. If there are no existing configuration files for the application, they can be created by copying the sample files. For example, consider the contents of the directory /usr/local/etc/apache: -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default -rw-r--r-- 1 root wheel 12205 May 20 1998 magic -rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default -rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf -rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default The file sizes show that only srm.conf has been changed. A later update of the Apache port would not overwrite this changed file. Tom Rhodes Contributed by Starting Services services Many users install third party software on &os; from the Ports Collection and require the installed services to be started upon system initialization. Services, such as mail/postfix or www/apache22 are just two of the many software packages which may be started during system initialization. This section explains the procedures available for starting third party software. In &os;, most included services, such as &man.cron.8;, are started through the system start up scripts. Extended Application Configuration Now that &os; includes rc.d, configuration of application startup is easier and provides more features. Using the key words discussed in , applications can be set to start after certain other services and extra flags can be passed through /etc/rc.conf in place of hard coded flags in the start up script. A basic script may look similar to the following: #!/bin/sh # # PROVIDE: utility # REQUIRE: DAEMON # KEYWORD: shutdown . /etc/rc.subr name=utility rcvar=utility_enable command="/usr/local/sbin/utility" load_rc_config $name # # DO NOT CHANGE THESE DEFAULT VALUES HERE # SET THEM IN THE /etc/rc.conf FILE # utility_enable=${utility_enable-"NO"} pidfile=${utility_pidfile-"/var/run/utility.pid"} run_rc_command "$1" This script will ensure that the provided utility will be started after the DAEMON pseudo-service. It also provides a method for setting and tracking the process ID (PID). This application could then have the following line placed in /etc/rc.conf: utility_enable="YES" This method allows for easier manipulation of command line arguments, inclusion of the default functions provided in /etc/rc.subr, compatibility with &man.rcorder.8;, and provides for easier configuration via rc.conf. Using Services to Start Services Other services can be started using &man.inetd.8;. Working with &man.inetd.8; and its configuration is described in depth in . In some cases, it may make more sense to use &man.cron.8; to start system services. This approach has a number of advantages as &man.cron.8; runs these processes as the owner of the &man.crontab.5;. This allows regular users to start and maintain their own applications. The @reboot feature of &man.cron.8;, may be used in place of the time specification. This causes the job to run when &man.cron.8; is started, normally during system initialization. Tom Rhodes Contributed by Configuring &man.cron.8; cron configuration One of the most useful utilities in &os; is &man.cron.8;. This utility runs in the background and regularly checks /etc/crontab for tasks to execute and searches /var/cron/tabs for custom &man.crontab.5; files. These files store information about specific functions which &man.cron.8; is supposed to perform at certain times. Two different types of configuration files are used by &man.cron.8;: the system crontab and user crontabs. These formats only differ in the sixth field and later. In the system crontab, &man.cron.8; runs the command as the user specified in the sixth field. In a user crontab, all commands run as the user who created the crontab, so the sixth field is the last field; this is an important security feature. The final field is always the command to run. User crontabs allow individual users to schedule tasks without the need for root privileges. Commands in a user's crontab run with the permissions of the user who owns the crontab. The root user can have a user crontab just like any other user. The root user crontab is separate from the system crontab, /etc/crontab. Because the system crontab invokes the specified commands as root, there is usually no need to create a user crontab for root. Here is a sample entry from /etc/crontab: # /etc/crontab - root's crontab for FreeBSD # # $FreeBSD$ # # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin # #minute hour mday month wday who command # */5 * * * * root /usr/libexec/atrun Like most &os; configuration files, lines that begin with the # character are comments. A comment can be placed in the file as a reminder of what and why a desired action is performed. Comments cannot be on the same line as a command or else they will be interpreted as part of the command; they must be on a new line. Blank lines are ignored. The equals (=) character is used to define any environment settings. In this example, it is used to define the SHELL and PATH. If the SHELL is omitted, &man.cron.8; will use the default of &man.sh.1;. If the PATH is omitted, no default will be used and file locations will need to be absolute. This line defines a total of seven fields: minute, hour, mday, month, wday, who, and command. These are almost all self explanatory. minute is the time in minutes when the specified command will be run. hour is the hour when the specified command will be run. mday stands for day of the month and month designates the month. The wday option stands for day of the week. These fields must be numeric values, representing the twenty-four hour clock, or a *, representing all values for that field. The who field only exists in the system crontab. This field specifies which user the command should be run as. The last field is the command to be executed. This last line defines the values discussed above. This example has a */5 listing,followed by several more * characters. These * characters mean first-last, and can be interpreted as every time. In this example, &man.atrun.8; is invoked by root every five minutes, regardless of the day or month. Commands can have any number of flags passed to them; however, commands which extend to multiple lines need to be broken with the backslash \ continuation character. This is the basic setup for every &man.crontab.5;. However, field number six, which specifies the username, only exists in the system &man.crontab.5;. This field should be omitted for individual user &man.crontab.5; files. Installing a Crontab Do not use the procedure described here to edit and install the system crontab, /etc/crontab. Instead, use an editor and &man.cron.8; will notice that the file has changed and immediately begin using the updated version. See this FAQ entry for more information. To install a freshly written user &man.crontab.5;, use an editor to create and save a file in the proper format. Then, specify the file name with &man.crontab.1;: &prompt.user; crontab crontab-file In this example, crontab-file is the filename of a &man.crontab.5; that was previously created. To list installed &man.crontab.5; files, pass to &man.crontab.1;. Users who wish to begin their own crontab file from scratch, without the - use of a template, can use crontab -e. This - will invoke the default editor with an empty file. When this - file is saved, it will be automatically installed by + use of a template, can use crontab -e. + This will invoke the default editor with an empty file. When + this file is saved, it will be automatically installed by &man.crontab.1;. In order to remove a user &man.crontab.5; completely, use crontab -r. Tom Rhodes Contributed by Using &man.rc.8; Under &os; In 2002, &os; integrated the NetBSD &man.rc.8; system for - system initialization. The files listed in /etc/rc.d provide basic services - which can be controlled with the , - , and options - to &man.service.8;. For instance, &man.sshd.8; can be restarted - with the following command: + system initialization. The files listed in + /etc/rc.d provide basic + services which can be controlled with the + , , and + options to &man.service.8;. For + instance, &man.sshd.8; can be restarted with the following + command: &prompt.root; service sshd restart This procedure can be used to start services on a running system. Services will be started automatically at boot time as specified in &man.rc.conf.5;. For example, to enable &man.natd.8; at system startup, add the following line to /etc/rc.conf: natd_enable="YES" If a line is already present, change the NO to YES. The &man.rc.8; scripts will automatically load any dependent services during the next boot, as described below. Since the &man.rc.8; system is primarily intended to start and stop services at system startup and shutdown time, the , and options will only perform their action if the appropriate /etc/rc.conf variable is set. For instance, sshd restart will only work if sshd_enable is set to in /etc/rc.conf. To , or a service regardless of the settings in /etc/rc.conf, these commands should be prefixed with one. For instance, to restart &man.sshd.8; regardless of the current /etc/rc.conf setting, execute the following command: &prompt.root; service sshd onerestart To check if a service is enabled in /etc/rc.conf, run the appropriate &man.rc.8; script with . This example checks to see if &man.sshd.8; is enabled in /etc/rc.conf: &prompt.root; service sshd rcvar # sshd -$sshd_enable=YES +# +sshd_enable="YES" +# (default: "") The # sshd line is output from the above command, not a root console. To determine whether or not a service is running, use . For instance, to verify that &man.sshd.8; is running: &prompt.root; service sshd status sshd is running as pid 433. In some cases, it is also possible to a service. This attempts to send a signal to an individual service, forcing the service to reload its configuration files. In most cases, this means sending the service a SIGHUP signal. Support for this feature is not included for every service. The &man.rc.8; system is used for network services and it also contributes to most of the system initialization. For instance, when the /etc/rc.d/bgfsck script is executed, it prints out the following message: Starting background file system checks in 60 seconds. This script is used for background file system checks, which occur only during system initialization. Many system services depend on other services to function properly. For example, &man.yp.8; and other RPC-based services may fail to start until after the &man.rpcbind.8; service has started. To resolve this issue, information about dependencies and other meta-data is included in the comments at the top of each startup script. The &man.rcorder.8; program is used to parse these comments during system initialization to determine the order in which system services should be invoked to satisfy the dependencies. The following key word must be included in all startup scripts as it is required by &man.rc.subr.8; to enable the startup script: PROVIDE: Specifies the services this file provides. The following key words may be included at the top of each startup script. They are not strictly necessary, but are useful as hints to &man.rcorder.8;: REQUIRE: Lists services which are required for this service. The script containing this key word will run after the specified services. BEFORE: Lists services which depend on this service. The script containing this key word will run before the specified services. By carefully setting these keywords for each startup script, an administrator has a fine-grained level of control of the startup order of the scripts, without the need for runlevels used by some &unix; operating systems. Additional information can be found in &man.rc.8; and &man.rc.subr.8;. Refer to this article for instructions on how to create custom &man.rc.8; scripts. Marc Fonvieille Contributed by Setting Up Network Interface Cards network cards configuration Adding and configuring a network interface card (NIC) is a common task for any &os; administrator. Locating the Correct Driver network cards driver First, determine the model of the NIC and the chip it uses. &os; supports a wide variety of NICs. Check the Hardware Compatibility List for the &os; release to see if the NIC is supported. If the NIC is supported, determine the name of the &os; driver for the NIC. Refer to /usr/src/sys/conf/NOTES and /usr/src/sys/arch/conf/NOTES for the list of NIC drivers with some information about the supported chipsets. When in doubt, read the manual page of the driver as it will provide more information about the supported hardware and any known limitations of the driver. The drivers for common NICs are already present in the GENERIC kernel, meaning the NIC should show up during boot. In this example, two NICs using the &man.dc.4; driver are present on the system: dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38 000ff irq 15 at device 11.0 on pci0 miibus0: <MII bus> on dc0 bmtphy0: <BCM5201 10/100baseTX PHY> PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:a0:cc:da:da:da dc0: [ITHREAD] dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 miibus1: <MII bus> on dc1 bmtphy1: <BCM5201 10/100baseTX PHY> PHY 1 on miibus1 bmtphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: Ethernet address: 00:a0:cc:da:da:db dc1: [ITHREAD] If the driver for the NIC is not present in GENERIC, but a driver is available, the driver will need to be loaded before the NIC can be configured and used. This may be accomplished in one of two ways: The easiest way is to load a kernel module for the NIC using &man.kldload.8;. To also automatically load the driver at boot time, add the appropriate line to /boot/loader.conf. Not all NIC drivers are available as modules. Alternatively, statically compile support for the NIC into a custom kernel. Refer to /usr/src/sys/conf/NOTES, /usr/src/sys/arch/conf/NOTES and the manual page of the driver to determine which line to add to the custom kernel configuration file. For more information about recompiling the kernel, refer to . If the NIC was detected at boot, the kernel does not need to be recompiled. Using &windows; <acronym>NDIS</acronym> Drivers NDIS NDISulator &windows; drivers µsoft.windows; device drivers KLD (kernel loadable object) Unfortunately, there are still many vendors that do not provide schematics for their drivers to the open source community because they regard such information as trade secrets. Consequently, the developers of &os; and other operating systems are left with two choices: develop the drivers by a long and pain-staking process of reverse engineering or using the existing driver binaries available for µsoft.windows; platforms. &os; provides native support for the Network Driver Interface Specification (NDIS). It includes &man.ndisgen.8; which can be used to convert a &windowsxp; driver into a format that can be used on &os;. Because the &man.ndis.4; driver uses a &windowsxp; binary, it only runs on &i386; and amd64 systems. PCI, CardBus, PCMCIA, and USB devices are supported. To use &man.ndisgen.8;, three things are needed: &os; kernel sources. A &windowsxp; driver binary with a .SYS extension. A &windowsxp; driver configuration file with a .INF extension. Download the .SYS and .INF files for the specific NIC. Generally, these can be found on the driver CD or at the vendor's website. The following examples use W32DRIVER.SYS and W32DRIVER.INF. The driver bit width must match the version of &os;. For &os;/i386, use a &windows; 32-bit driver. For &os;/amd64, a &windows; 64-bit driver is needed. The next step is to compile the driver binary into a loadable kernel module. As root, use &man.ndisgen.8;: &prompt.root; ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS This command is interactive and prompts for any extra information it requires. A new kernel module will be generated in the current directory. Use &man.kldload.8; to load the new module: &prompt.root; kldload ./W32DRIVER_SYS.ko In addition to the generated kernel module, the ndis.ko and if_ndis.ko modules must be loaded. This should happen automatically when any module that depends on &man.ndis.4; is loaded. If not, load them manually, using the following commands: &prompt.root; kldload ndis &prompt.root; kldload if_ndis The first command loads the &man.ndis.4; miniport driver wrapper and the second loads the generated NIC driver. Check &man.dmesg.8; to see if there were any load errors. If all went well, the output should be similar to the following: ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps From here, ndis0 can be configured like any other NIC. To configure the system to load the &man.ndis.4; modules at boot time, copy the generated module, W32DRIVER_SYS.ko, to /boot/modules. Then, add the following line to /boot/loader.conf: W32DRIVER_SYS_load="YES" Configuring the Network Card network cards configuration Once the right driver is loaded for the NIC, the card needs to be configured. It may have been configured at installation time by &man.sysinstall.8;. To display the NIC configuration, enter the following command: &prompt.user; ifconfig dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX <full-duplex>) status: active dc1: flags=8802<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:db inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet 10baseT/UTP status: no carrier lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3<PERFORMNUD,ACCEPT_RTADV> In this example, the following devices were displayed: dc0: The first Ethernet interface. dc1: The second Ethernet interface. lo0: The loopback device. &os; uses the driver name followed by the order in which the card is detected at boot to name the NIC. For example, sis2 is the third NIC on the system using the &man.sis.4; driver. In this example, dc0 is up and running. The key indicators are: UP means that the card is configured and ready. The card has an Internet (inet) address, 192.168.1.3. It has a valid subnet mask (netmask), where 0xffffff00 is the same as 255.255.255.0. It has a valid broadcast address, 192.168.1.255. The MAC address of the card (ether) is 00:a0:cc:da:da:da. The physical media selection is on autoselection mode (media: Ethernet autoselect (100baseTX <full-duplex>)). In this example, dc1 is configured to run with 10baseT/UTP media. For more information on available media types for a driver, refer to its manual page. The status of the link (status) is active, indicating that the carrier signal is detected. For dc1, the status: no carrier status is normal when an Ethernet cable is not plugged into the card. If the &man.ifconfig.8; output had shown something similar to: dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da media: Ethernet autoselect (100baseTX <full-duplex>) status: active it would indicate the card has not been configured. The card must be configured as root. The NIC configuration can be performed from the command line with &man.ifconfig.8; but will not persist after a reboot unless the configuration is also added to /etc/rc.conf. Add a line for each NIC present on the system, as seen in this example: ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0" ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP" Replace dc0 and dc1 and the IP address information with the correct values for the system. Refer to the man page for the driver, &man.ifconfig.8;, and &man.rc.conf.5; for more details about the allowed options and the syntax of /etc/rc.conf. If the network was configured during installation, some entries for the NIC(s) may be already present. Double check /etc/rc.conf before adding any lines. If the network is not using DNS, edit /etc/hosts to add the names and IP addresses of of the hosts on the LAN, if they are not already there. For more information, refer to &man.hosts.5; and to /usr/share/examples/etc/hosts. If there is no DHCP server and access to the Internet is needed, manually configure the default gateway and the nameserver: &prompt.root; echo 'defaultrouter="your_default_router"' >> /etc/rc.conf &prompt.root; echo 'nameserver your_DNS_server' >> /etc/resolv.conf Testing and Troubleshooting Once the necessary changes to /etc/rc.conf are saved, a reboot can be used to test the network configuration and to verify that the system restarts without any configuration errors. Alternatively, apply the settings to the networking system with this command: &prompt.root; service netif restart If a default gateway has been set in /etc/rc.conf, also issue this command: &prompt.root; service routing restart Once the networking system has been relaunched, test the NICs. Testing the Ethernet Card network cards testing To verify that an Ethernet card is configured correctly, &man.ping.8; the interface itself, and then &man.ping.8; another machine on the LAN: &prompt.user; ping -c5 192.168.1.3 PING 192.168.1.3 (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms --- 192.168.1.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms &prompt.user; ping -c5 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms To test network resolution, use the host name instead of the IP address. If there is no DNS server on the network, /etc/hosts must first be configured. Troubleshooting network cards troubleshooting When troubleshooting hardware and software configurations, check the simple things first. Is the network cable plugged in? Are the network services properly configured? Is the firewall configured correctly? Is the NIC supported by &os;? Before sending a bug report, always check the Hardware Notes, update the version of &os; to the latest STABLE version, check the mailing list archives, and search the Internet. If the card works, yet performance is poor, read through &man.tuning.7;. Also, check the network configuration as incorrect network settings can cause slow connections. Some users experience one or two device timeout messages, which is normal for some cards. If they continue, or are bothersome, determine if the device is conflicting with another device. Double check the cable connections. Consider trying another card. To resolve watchdog timeout errors, first check the network cable. Many cards require a PCI slot which supports bus mastering. On some old motherboards, only one PCI slot allows it, usually slot 0. Check the NIC and the motherboard documentation to determine if that may be the problem. No route to host messages occur if the system is unable to route a packet to the destination host. This can happen if no default route is specified or if a cable is unplugged. Check the output of netstat -rn and make sure there is a - valid route to the host. If there is not, read . + valid route to the host. If there is not, read + . ping: sendto: Permission denied error messages are often caused by a misconfigured firewall. If a firewall is enabled on &os; but no rules have been defined, the default policy is to deny all traffic, even - &man.ping.8;. Refer to for more information. + &man.ping.8;. Refer to + for more information. Sometimes performance of the card is poor or below average. In these cases, try setting the media selection mode from autoselect to the correct media selection. While this works for most hardware, it may or may not resolve the issue. Again, check all the network settings, and refer to &man.tuning.7;. Virtual Hosts virtual hosts IP aliases A common use of &os; is virtual site hosting, where one server appears to the network as many servers. This is achieved by assigning multiple network addresses to a single interface. A given network interface has one real address, and may have any number of alias addresses. These aliases are normally added by placing alias entries in /etc/rc.conf, as seen in this example: ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx" Alias entries must start with alias0 using a sequential number such as alias0, alias1, and so on. The configuration process will stop at the first missing number. The calculation of alias netmasks is important. For a given interface, there must be one address which correctly represents the network's netmask. Any other addresses which fall within this network must have a netmask of all - 1s, expressed as either 255.255.255.255 or 0xffffffff. + 1s, expressed as either + 255.255.255.255 or + 0xffffffff. For example, consider the case where the fxp0 interface is connected to two networks: 10.1.1.0 with a netmask of 255.255.255.0 and 202.0.75.16 with a netmask of 255.255.255.240. The system - is to be configured to appear in the ranges 10.1.1.1 through 10.1.1.5 and 202.0.75.17 through 202.0.75.20. Only the first address - in a given network range should have a real netmask. All the - rest (10.1.1.2 through 10.1.1.5 and 202.0.75.18 through 202.0.75.20) must be configured with - a netmask of 255.255.255.255. + is to be configured to appear in the ranges + 10.1.1.1 through + 10.1.1.5 and + 202.0.75.17 through + 202.0.75.20. Only the first + address in a given network range should have a real netmask. + All the rest (10.1.1.2 through + 10.1.1.5 and + 202.0.75.18 through + 202.0.75.20) must be configured + with a netmask of + 255.255.255.255. The following /etc/rc.conf entries configure the adapter correctly for this scenario: ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" - Niclas Zeising Contributed by Configuring the System Logger, <command>syslogd</command> system logging syslog &man.syslogd.8; System logging is an important aspect of system administration. It is used to detect hardware and software issues and errors in the system. It plays an important role in security auditing and incident response. System daemons without a controlling terminal usually log information to a system logging facility or other log file. This section describes how to configure and use the &os; system logger, &man.syslogd.8;, and how to perform log rotation and log management using &man.newsyslog.8;. Focus will be on setting up and using &man.syslogd.8; on a local machine. For more advanced setups using a separate loghost, see . Using <command>syslogd</command> In the default &os; configuration, &man.syslogd.8; is started at boot. This is controlled by the variable syslogd_enable in /etc/rc.conf. There are numerous application arguments that affect the behavior of &man.syslogd.8;. To change them, use syslogd_flags in /etc/rc.conf. Refer to &man.syslogd.8; for more information on the arguments, and &man.rc.conf.5;, - and for more information about + and + for more information about /etc/rc.conf and the &man.rc.8; subsystem. Configuring <command>syslogd</command> syslog.conf The configuration file, by default /etc/syslog.conf, controls what &man.syslogd.8; does with the log entries once they are received. There are several parameters to control the handling of incoming events, of which the most basic are facility and level. The facility describes which subsystem generated the message, such as the kernel or a daemon, and the level describes the severity of the event that occurred. This makes it possible to log the message to different log files, or discard it, depending on the facility and level. It is also possible to take action depending on the application that sent the message, and in the case of remote logging, the hostname of the machine generating the logging event. The configuration file for &man.syslogd.8; contains one line per action, and the syntax for each line is a selector field followed by an action field. The syntax of the selector field is facility.level which will match log messages from facility at level level or higher. It is also possible to add an optional comparison flag before the level to specify more precisely what is logged. Multiple selector fields can be used for the same action, and are separated with a semicolon (;). Using * will match everything. The action field denotes where to send the log message, such as to a file or remote log host. As an example, here is the default syslog.conf from &os;: # $&os;$ # # Spaces ARE valid field separators in this file. However, # other *nix-like systems still insist on using tabs as field # separators. If you are sharing this file between systems, you # may want to use only tabs as field separators here. # Consult the syslog.conf(5) manpage. *.err;kern.warning;auth.notice;mail.crit /dev/console *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog lpr.info /var/log/lpd-errs ftp.info /var/log/xferlog cron.* /var/log/cron *.=debug /var/log/debug.log *.emerg * # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log # uncomment this to enable logging of all log messages to /var/log/all.log # touch /var/log/all.log and chmod it to mode 600 before it will work #*.* /var/log/all.log # uncomment this to enable logging to a remote loghost named loghost #*.* @loghost # uncomment these if you're running inn # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice !ppp *.* /var/log/ppp.log !* Match all messages with a level of err or higher, as well as kern.warning, auth.notice and mail.crit, and send these log messages to the console (/dev/console). Match all messages from the mail facility at level info or above, and log the messages to /var/log/maillog. This line uses a comparison flag, = to only match messages at level debug, and log them in /var/log/debug.log. Here is an example usage of a program specification. This makes the rules following it only valid for the program in the program specification. In this case, this and the following lines log all messages from &man.ppp.8;, but no other programs, to /var/log/ppp.log. This example shows that there are plenty of levels and subsystems. The levels are, in order from most to least critical: emerg, alert, crit, err, warning, notice, info, and debug. The facilities are, in no particular order: auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, uucp, and local0 through local7. Be aware that other operating systems might have different facilities. With this knowledge, it is easy to add a new line to /etc/syslog.conf to log everything from the different daemons on level notice and higher to /var/log/daemon.log. Just add the following: daemon.notice /var/log/daemon.log For more information about the different levels and facilities, refer to &man.syslog.3; and &man.syslogd.8;. For more information about /etc/syslog.conf, its syntax, and more - advanced usage examples, see &man.syslog.conf.5; and . + advanced usage examples, see &man.syslog.conf.5; and + . Log Management and Rotation with <command>newsyslog</command> newsyslog newsyslog.conf log rotation log management Log files tend to grow quickly and accumulate steadily. This leads to the files being full of less immediately useful information while filling up the hard drive. Log management attempts to mitigate this. In &os;, &man.newsyslog.8; is used to manage log files. This program periodically rotates and compresses log files, and optionally creates missing log files and signals programs when log files are moved. The log files are not necessarily generated by &man.syslogd.8; as &man.newsyslog.8; works with any logs written from any program. While &man.newsyslog.8; is normally run from &man.cron.8;, it is not a system daemon. In the default configuration, it is run every hour. Configuring <command>newsyslog</command> To know which actions to take, &man.newsyslog.8; reads its configuration file, by default /etc/newsyslog.conf. This configuration file contains one line for each file that &man.newsyslog.8; manages. Each line states the file owner, permissions, when to rotate that file, optional flags that affect log rotation, such as compression, and programs to signal when the log is rotated. Here is the default configuration in &os;: # configuration file for newsyslog # $FreeBSD$ # # Entries which do not specify the '/pid_file' field will cause the # syslogd process to be signalled when that log file is rotated. This # action is only appropriate for log files which are written to by the # syslogd process (ie, files listed in /etc/syslog.conf). If there # is no process which needs to be signalled when a given log file is # rotated, then the entry for that file should include the 'N' flag. # # The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'. # # Note: some sites will want to select more restrictive protections than the # defaults. In particular, it may be desirable to switch many of the 644 # entries to 640 or 600. For example, some sites will consider the # contents of maillog, messages, and lpd-errs to be confidential. In the # future, these defaults may change to more conservative ones. # # logfilename [owner:group] mode count size when flags [/pid_file] [sig_num] /var/log/all.log 600 7 * @T00 J /var/log/amd.log 644 7 100 * J /var/log/auth.log 600 7 100 @0101T JC /var/log/console.log 600 5 100 * J /var/log/cron 600 3 100 * JC /var/log/daily.log 640 7 * @T00 JN /var/log/debug.log 600 7 100 * JC /var/log/kerberos.log 600 7 100 * J /var/log/lpd-errs 644 7 100 * JC /var/log/maillog 640 7 * @T00 JC /var/log/messages 644 5 100 @0101T JC /var/log/monthly.log 640 12 * $M1D0 JN /var/log/pflog 600 3 100 * JB /var/run/pflogd.pid /var/log/ppp.log root:network 640 3 100 * JC /var/log/security 600 10 100 * JC /var/log/sendmail.st 640 10 * 168 B /var/log/utx.log 644 3 * @01T05 B /var/log/weekly.log 640 5 1 $W6D0 JN /var/log/xferlog 600 7 100 * JC Each line starts with the name of the file to be rotated, optionally followed by an owner and group for both rotated and newly created files. The mode field sets the permissions on the log file and count denotes how many rotated log files should be kept. The size and when fields tell &man.newsyslog.8; when to rotate the file. A log file is rotated when either its size is larger than the size field, or when the time in the when filed has passed. * means that this field is ignored. The flags field gives &man.newsyslog.8; further instructions, such as how to compress the rotated file or to create the log file if it is missing. The last two fields are optional, and - specify the PID file of a process - and a signal number to send to that process when the file - is rotated. For more information on all fields, valid + specify the + PID file of a + process and a signal number to send to that process when the + file is rotated. For more information on all fields, valid flags, and how to specify the rotation time, refer to - &man.newsyslog.conf.5;. Since &man.newsyslog.8; is run - from &man.cron.8;, it can not rotate files more often than - it is run from &man.cron.8;. + &man.newsyslog.conf.5;. Since &man.newsyslog.8; is run from + &man.cron.8;, it can not rotate files more often than it is + run from &man.cron.8;. Configuration Files <filename class="directory">/etc</filename> Layout There are a number of directories in which configuration information is kept. These include: /etc Generic system-specific configuration information. /etc/defaults Default versions of system configuration files. /etc/mail Extra &man.sendmail.8; configuration and other MTA configuration files. /etc/ppp Configuration for both user- and kernel-ppp programs. /etc/namedb Default location for &man.named.8; data. Normally named.conf and zone files are stored here. /usr/local/etc Configuration files for installed applications. May contain per-application subdirectories. /usr/local/etc/rc.d &man.rc.8; scripts for installed applications. /var/db Automatically generated system-specific database files, such as the package database and the &man.locate.1; database. Hostnames hostname DNS <filename>/etc/resolv.conf</filename> resolv.conf - How a - &os; system accesses the Internet Domain Name System - (DNS) is controlled by + How a &os; system accesses the Internet Domain Name + System (DNS) is controlled by &man.resolv.conf.5;. The most common entries to /etc/resolv.conf are: nameserver The IP address of a name server the resolver should query. The servers are queried in the order listed with a maximum of three. search Search list for hostname lookup. This is normally determined by the domain of the local hostname. domain The local domain name. A typical /etc/resolv.conf looks like this: search example.com nameserver 147.11.1.11 nameserver 147.11.100.30 Only one of the search and domain options should be used. When using DHCP, &man.dhclient.8; usually rewrites /etc/resolv.conf with information received from the DHCP server. <filename>/etc/hosts</filename> hosts /etc/hosts is a simple text database which works in conjunction with DNS and NIS to provide host name to IP address mappings. Entries for local computers connected via a LAN can be added to this file for simplistic naming purposes instead of setting up a &man.named.8; server. Additionally, /etc/hosts can be used to provide a local record of Internet names, reducing the need to query external DNS servers for commonly accessed names. # $&os;$ # # # Host Database # # This file should contain the addresses and aliases for local hosts that # share this file. Replace 'my.domain' below with the domainname of your # machine. # # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/nsswitch.conf for the resolution order. # # ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain # # Imaginary network. #10.0.0.2 myname.my.domain myname #10.0.0.3 myfriend.my.domain myfriend # # According to RFC 1918, you can use the following IP networks for # private nets which will never be connected to the Internet: # # 10.0.0.0 - 10.255.255.255 # 172.16.0.0 - 172.31.255.255 # 192.168.0.0 - 192.168.255.255 # # In case you want to be able to connect to the Internet, you need # real official assigned numbers. Do not try to invent your own network # numbers but instead get one from your network provider (if any) or # from your regional registry (ARIN, APNIC, LACNIC, RIPE NCC, or AfriNIC.) # The format of /etc/hosts is as follows: [Internet address] [official hostname] [alias1] [alias2] ... For example: 10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2 Consult &man.hosts.5; for more information. Tuning with &man.sysctl.8; sysctl tuning with sysctl &man.sysctl.8; is used to make changes to a running &os; system. This includes many advanced options of the TCP/IP stack and virtual memory system that can dramatically improve performance for an experienced system administrator. Over five hundred system variables can be read and set using &man.sysctl.8;. At its core, &man.sysctl.8; serves two functions: to read and to modify system settings. To view all readable variables: &prompt.user; sysctl -a To read a particular variable, specify its name: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 To set a particular variable, use the variable=value syntax: &prompt.root; sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000 Settings of sysctl variables are usually either strings, - numbers, or booleans, where a a boolean is 1 + numbers, or booleans, where a boolean is 1 for yes or 0 for no. To automatically set some variables each time the machine boots, add them to /etc/sysctl.conf. For - more information, refer to &man.sysctl.conf.5; and . + more information, refer to &man.sysctl.conf.5; and + . <filename>sysctl.conf</filename> sysctl.conf sysctl The configuration file for &man.sysctl.8;, /etc/sysctl.conf, looks much like /etc/rc.conf. Values are set in a variable=value form. The specified values are set after the system goes into multi-user mode. Not all variables are settable in this mode. For example, to turn off logging of fatal signal exits and prevent users from seeing processes started by other users, the following tunables can be set in /etc/sysctl.conf: # Do not log fatal signal exits (e.g., sig 11) kern.logsigexit=0 # Prevent users from seeing information about processes that # are being run under another UID. security.bsd.see_other_uids=0 - Tom Rhodes Contributed by &man.sysctl.8; Read-only In some cases it may be desirable to modify read-only &man.sysctl.8; values, which will require a reboot of the system. For instance, on some laptop models the &man.cardbus.4; device will not probe memory ranges and will fail with errors similar to: cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 The fix requires the modification of a read-only &man.sysctl.8; setting. Add to /boot/loader.conf and reboot. Now &man.cardbus.4; should work properly. Tuning Disks The following section will discuss various tuning mechanisms and options which may be applied to disk devices. In many cases, disks with mechanical parts, such as SCSI drives, will be the bottleneck driving down the overall system performance. While a solution is to install a drive without mechanical parts, such as a solid state drive, mechanical drives are not going away anytime in the near future. When tuning disks, it is advisable to utilize the features of the &man.iostat.8; command to test various changes to the system. This command will allow the user to obtain valuable information on system IO. Sysctl Variables <varname>vfs.vmiodirenable</varname> vfs.vmiodirenable The vfs.vmiodirenable &man.sysctl.8; variable may be set to either 0 (off) or 1 (on). It is set to 1 by default. This variable controls how directories are cached by the system. Most directories are small, using just a single fragment (typically 1 K) in the file system and typically 512 bytes in the buffer cache. With this variable turned off, the buffer cache will only cache a fixed number of directories, even if the system has a huge amount of memory. When turned on, this &man.sysctl.8; allows the buffer cache to use the VM page cache to cache the directories, making all the memory available for caching directories. However, the minimum in-core memory used to cache a directory is the physical page size (typically 4 K) rather than 512  bytes. Keeping this option enabled is recommended if the system is running any services which manipulate large numbers of files. Such services can include web caches, large mail systems, and news systems. Keeping this option on will generally not reduce performance, even with the wasted memory, but one should experiment to find out. <varname>vfs.write_behind</varname> vfs.write_behind The vfs.write_behind &man.sysctl.8; variable defaults to 1 (on). This tells the file system to issue media writes as full clusters are collected, which typically occurs when writing large sequential files. This avoids saturating the buffer cache with dirty buffers when it would not benefit I/O performance. However, this may stall processes and under certain circumstances should be turned off. <varname>vfs.hirunningspace</varname> vfs.hirunningspace The vfs.hirunningspace &man.sysctl.8; variable determines how much outstanding write I/O may be queued to disk controllers system-wide at any given instance. The default is usually sufficient, but on machines with many disks, try bumping it up to four or five megabytes. Setting too high a value which exceeds the buffer cache's write threshold can lead to bad clustering performance. Do not set this value arbitrarily high as higher write values may add latency to reads occurring at the same time. There are various other buffer cache and VM page cache related &man.sysctl.8; values. Modifying these values is not recommended as the VM system does a good job of automatically tuning itself. <varname>vm.swap_idle_enabled</varname> vm.swap_idle_enabled The vm.swap_idle_enabled &man.sysctl.8; variable is useful in large multi-user systems with many active login users and lots of idle processes. Such systems tend to generate continuous pressure on free memory reserves. Turning this feature on and tweaking the swapout hysteresis (in idle seconds) via vm.swap_idle_threshold1 and vm.swap_idle_threshold2 depresses the priority of memory pages associated with idle processes more quickly then the normal pageout algorithm. This gives a helping hand to the pageout daemon. Only turn this option on if needed, because the tradeoff is essentially pre-page memory sooner rather than later which eats more swap and disk bandwidth. In a small system this option will have a determinable effect, but in a large system that is already doing moderate paging, this option allows the VM system to stage whole processes into and out of memory easily. <varname>hw.ata.wc</varname> hw.ata.wc Turning off IDE write caching reduces write bandwidth to IDE disks, but may sometimes be necessary due to data consistency issues introduced by hard drive vendors. The problem is that some IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives write data to disk out of order and will sometimes delay writing some blocks indefinitely when under heavy disk load. A crash or power failure may cause serious file system corruption. Check the default on the system by observing the hw.ata.wc &man.sysctl.8; variable. If IDE write caching is turned off, one can set this read-only variable to 1 in /boot/loader.conf in order to enable it at boot time. For more information, refer to &man.ata.4;. <literal>SCSI_DELAY</literal> (<varname>kern.cam.scsi_delay</varname>) kern.cam.scsi_delay kernel options SCSI DELAY The SCSI_DELAY kernel configuration option may be used to reduce system boot times. The defaults are fairly high and can be responsible for 15 seconds of delay in the boot process. Reducing it to 5 seconds usually works with modern drives. The kern.cam.scsi_delay boot time tunable should be used. The tunable and kernel configuration option accept values in terms of milliseconds and not seconds. Soft Updates Soft Updates &man.tunefs.8; To fine-tune a file system, use &man.tunefs.8;. This program has many different options. To toggle Soft Updates on and off, use: &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem A file system cannot be modified with &man.tunefs.8; while it is mounted. A good time to enable Soft Updates is before any partitions have been mounted, in single-user mode. Soft Updates is recommended for UFS file systems as it drastically improves meta-data performance, mainly file creation and deletion, through the use of a memory cache. There are two downsides to Soft Updates to be aware of. First, Soft Updates guarantee file system consistency in the case of a crash, but could easily be several seconds or even a minute behind updating the physical disk. If the system crashes, unwritten data may be lost. Secondly, Soft Updates delay the freeing of file system blocks. If the root file system is almost full, performing a major update, such as make installworld, can cause the file system to run out of space and the update to fail. More Details About Soft Updates Soft Updates details Meta-data updates are updates to non-content data like inodes or directories. There are two traditional approaches to writing a file system's meta-data back to disk. Historically, the default behavior was to write out meta-data updates synchronously. If a directory changed, the system waited until the change was actually written to disk. The file data buffers (file contents) were passed through the buffer cache and backed up to disk later on asynchronously. The advantage of this implementation is that it operates safely. If there is a failure during an update, meta-data is always in a consistent state. A file is either created completely or not at all. If the data blocks of a file did not find their way out of the buffer cache onto the disk by the time of the crash, &man.fsck.8; recognizes this and repairs the file system - by setting the file length to - 0. Additionally, the implementation is - clear and simple. The disadvantage is that meta-data - changes are slow. For example, rm -r - touches all the files in a directory sequentially, but each - directory change will be written synchronously to the - disk. This includes updates to the directory itself, to - the inode table, and possibly to indirect blocks allocated - by the file. Similar considerations apply for unrolling - large hierarchies using tar -x. + by setting the file length to 0. + Additionally, the implementation is clear and simple. The + disadvantage is that meta-data changes are slow. For + example, rm -r touches all the files in a + directory sequentially, but each directory change will be + written synchronously to the disk. This includes updates to + the directory itself, to the inode table, and possibly to + indirect blocks allocated by the file. Similar + considerations apply for unrolling large hierarchies using + tar -x. The second approach is to use asynchronous meta-data updates. This is the default for a UFS file system mounted with mount -o async. Since all meta-data updates are also passed through the buffer cache, they will be intermixed with the updates of the file content data. The advantage of this implementation is there is no need to wait until each meta-data update has been written to disk, so all operations which cause huge amounts of meta-data updates work much faster than in the synchronous case. This implementation is still clear and simple, so there is a low risk for bugs creeping into the code. The disadvantage is that there is no guarantee for a consistent state of the file system. If there is a failure during an operation that updated large amounts of meta-data, like a power failure or someone pressing the reset button, the file system will be left in an unpredictable state. There is no opportunity to examine the state of the file system when the system comes up again as the data blocks of a file could already have been written to the disk while the updates of the inode table or the associated directory were not. It is impossible to implement a &man.fsck.8; which is able to clean up the resulting chaos because the necessary information is not available on the disk. If the file system has been damaged beyond repair, the only choice is to reformat it and restore from backup. The usual solution for this problem is to implement dirty region logging, which is also referred to as journaling. Meta-data updates are still written synchronously, but only into a small region of the disk. Later on, they are moved to their proper location. Because the logging area is a small, contiguous region on the disk, there are no long distances for the disk heads to move, even during heavy operations, so these operations are quicker than synchronous updates. Additionally, the complexity of the implementation is limited, so the risk of bugs being present is low. A disadvantage is that all meta-data is written twice, once into the logging region and once to the proper location, so performance pessimization might result. On the other hand, in case of a crash, all pending meta-data operations can be either quickly rolled back or completed from the logging area after the system comes up again, resulting in a fast file system startup. Kirk McKusick, the developer of Berkeley FFS, solved this problem with Soft Updates. All pending meta-data updates are kept in memory and written out to disk in a sorted sequence (ordered meta-data updates). This has the effect that, in case of heavy meta-data operations, later updates to an item catch the earlier ones which are still in memory and have not already been written to disk. All operations are generally performed in memory before the update is written to disk and the data blocks are sorted according to their position so that they will not be on the disk ahead of their meta-data. If the system crashes, an implicit log rewind causes all operations which were not written to the disk appear as if they never happened. A consistent file system state is maintained that appears to be the one of 30 to 60 seconds earlier. The algorithm used guarantees that all resources in use are marked as such in their blocks and inodes. After a crash, the only resource allocation error that occurs is that resources are marked as used - which are actually free. &man.fsck.8; + which are actually free. &man.fsck.8; recognizes this situation, and frees the resources that are no longer used. It is safe to ignore the dirty state of the file system after a crash by forcibly mounting it with mount -f. In order to free resources that may be unused, &man.fsck.8; needs to be run at a later time. This is the idea behind the background &man.fsck.8;: at system startup time, only a snapshot of the file system is recorded and &man.fsck.8; is run afterwards. All file systems can then be mounted dirty, so the system startup proceeds in multi-user mode. Then, background &man.fsck.8; is scheduled for all file systems where this is required, to free resources that may be unused. File systems that do not use Soft Updates still need the usual foreground &man.fsck.8;. The advantage is that meta-data operations are nearly as fast as asynchronous updates and are faster than logging, which has to write the meta-data twice. The disadvantages are the complexity of the code, a higher memory consumption, and some idiosyncrasies. After a crash, the state of the file system appears to be somewhat older. In situations where the standard synchronous approach would have caused some zero-length files to remain after the &man.fsck.8;, these files do not exist at all with Soft Updates because neither the meta-data nor the file contents have been written to disk. Disk space is not released until the updates have been written to disk, which may take place some time after running &man.rm.1;. This may cause problems when installing large amounts of data on a file system that does not have enough free space to hold all the files twice. Tuning Kernel Limits tuning kernel limits File/Process Limits <varname>kern.maxfiles</varname> kern.maxfiles The kern.maxfiles &man.sysctl.8; variable can be raised or lowered based upon system requirements. This variable indicates the maximum number of file descriptors on the system. When the file descriptor table is full, file: table is full will show up repeatedly in the system message buffer, which can be viewed using &man.dmesg.8;. Each open file, socket, or fifo uses one file descriptor. A large-scale production server may easily require many thousands of file descriptors, depending on the kind and number of services running concurrently. In older &os; releases, the default value of kern.maxfiles is derived from in the kernel configuration file. kern.maxfiles grows proportionally to the value of . When compiling a custom kernel, consider setting this kernel configuration option according to the use of the system. From this number, the kernel is given most of its pre-defined limits. Even though a production machine may not have 256 concurrent users, the resources needed may be similar to a high-scale web server. The read-only &man.sysctl.8; variable kern.maxusers is automatically sized at boot based on the amount of memory available in the system, and may be determined at run-time by inspecting the value of kern.maxusers. Some systems require larger or smaller values of kern.maxusers and values of 64, 128, and 256 are not uncommon. Going above 256 is not recommended unless a huge number of file descriptors is needed. Many of the tunable values set to their defaults by kern.maxusers may be individually overridden at boot-time or run-time in /boot/loader.conf. Refer to &man.loader.conf.5; and /boot/defaults/loader.conf for more details and some hints. In older releases, the system will auto-tune maxusers if it is set to 0. The auto-tuning algorithm sets maxusers equal to the amount of memory in the system, with a minimum of 32, and a maximum of 384.. When setting this option, set maxusers to at least 4, especially if the system runs &xorg; or is used to compile software. The most important table set by maxusers is the maximum number of processes, which is set to - 20 + 16 * maxusers. If + 20 + 16 * maxusers. If maxusers is set to 1, there can only be 36 simultaneous processes, including the 18 or so that the system starts up at boot time and the 15 or so used by &xorg;. Even a simple task like reading a manual page will start up nine processes to filter, decompress, and view it. Setting maxusers to 64 allows up to 1044 simultaneous processes, which should be enough for nearly all uses. If, however, the proc table full error is displayed when trying to start another program, or a server is running with a large number of simultaneous users, increase the number and rebuild. maxusers does not limit the number of users which can log into the machine. It instead sets various table sizes to reasonable values considering the maximum number of users on the system and how many processes each user will be running. <varname>kern.ipc.somaxconn</varname> kern.ipc.somaxconn The kern.ipc.somaxconn &man.sysctl.8; variable limits the size of the listen queue for accepting new TCP connections. The default value of 128 is typically too low for robust handling of new connections on a heavily loaded web server. For such environments, it is recommended to increase this value to 1024 or higher. A service such as &man.sendmail.8;, or Apache may itself limit the listen queue size, but will often have a directive in its configuration file to adjust the queue size. Large listen queues do a better job of avoiding Denial of Service (DoS) attacks. Network Limits The NMBCLUSTERS kernel configuration option dictates the amount of network Mbufs available to the system. A heavily-trafficked server with a low number of Mbufs will hinder performance. Each cluster represents approximately 2 K of memory, so a value of 1024 represents 2 megabytes of kernel memory reserved for network buffers. A simple calculation can be done to figure out how many are needed. A web server which maxes out at 1000 simultaneous connections where each connection uses a 6 K receive and 16 K send buffer, requires approximately 32 MB worth of network buffers to cover the web server. A good rule of thumb is to multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. Values between 4096 and 32768 are recommended for machines with greater amounts of memory. Never specify an arbitrarily high value for this parameter as it could lead to a boot time crash. To observe network cluster usage, use with &man.netstat.1;. The kern.ipc.nmbclusters loader tunable should be used to tune this at boot time. Only older versions of &os; will require the use of the NMBCLUSTERS kernel &man.config.8; option. For busy servers that make extensive use of the &man.sendfile.2; system call, it may be necessary to increase the number of &man.sendfile.2; buffers via the NSFBUFS kernel configuration option or by setting its value in /boot/loader.conf (see &man.loader.8; for details). A common indicator that this parameter needs to be adjusted is when processes are seen in the sfbufa state. The &man.sysctl.8; variable kern.ipc.nsfbufs is read-only. This parameter nominally scales with kern.maxusers, however it may be necessary to tune accordingly. Even though a socket has been marked as non-blocking, calling &man.sendfile.2; on the non-blocking socket may result in the &man.sendfile.2; call blocking until enough struct sf_buf's are made available. <varname>net.inet.ip.portrange.*</varname> net.inet.ip.portrange.* The net.inet.ip.portrange.* - &man.sysctl.8; - variables control the port number ranges automatically bound - to TCP and UDP - sockets. There are three ranges: a low range, a default - range, and a high range. Most network programs use the - default range which is controlled by + &man.sysctl.8; variables control the port number ranges + automatically bound to TCP and + UDP sockets. There are three ranges: a + low range, a default range, and a high range. Most network + programs use the default range which is controlled by net.inet.ip.portrange.first and net.inet.ip.portrange.last, which default to 1024 and 5000, respectively. Bound port ranges are used for outgoing connections and it is possible to run the system out of ports under certain circumstances. This most commonly occurs when running a heavily loaded web proxy. The port range is not an issue when running a server which handles mainly incoming connections, such as a web server, or has a limited number of outgoing connections, such as a mail relay. For situations where there is a shortage of ports, it is recommended to increase net.inet.ip.portrange.last modestly. A value of 10000, 20000 or 30000 may be reasonable. Consider firewall effects when changing the port range. Some firewalls may block large ranges of ports, usually low-numbered ports, and expect systems to use higher ranges of ports for outgoing connections. For this reason, it is not recommended that the value of net.inet.ip.portrange.first be lowered. <literal>TCP</literal> Bandwidth Delay Product TCP Bandwidth Delay Product Limiting net.inet.tcp.inflight.enable TCP bandwidth delay product limiting can be enabled by setting the net.inet.tcp.inflight.enable &man.sysctl.8; variable to 1. This instructs the system to attempt to calculate the bandwidth delay product for each connection and limit the amount of data queued to the network to just the amount required to maintain optimum throughput. This feature is useful when serving data over modems, Gigabit Ethernet, high speed WAN links, or any other link with a high bandwidth delay product, especially when also using window scaling or when a large send window has been configured. When enabling this option, also set net.inet.tcp.inflight.debug to 0 to disable debugging. For production use, setting net.inet.tcp.inflight.min to at least 6144 may be beneficial. Setting high minimums may effectively disable bandwidth limiting, depending on the link. The limiting feature reduces the amount of data built up in intermediate route and switch packet queues and reduces the amount of data built up in the local host's interface queue. With fewer queued packets, interactive connections, especially over slow modems, will operate with lower Round Trip Times. This feature only effects server side data transmission such as uploading. It has no effect on data reception or downloading. Adjusting net.inet.tcp.inflight.stab is not recommended. This parameter defaults to 20, representing 2 maximal packets added to the bandwidth delay product window calculation. The additional window is required to stabilize the algorithm and improve responsiveness to changing conditions, but it can also result in higher &man.ping.8; times over slow links, though still much lower than without the inflight algorithm. In such cases, try reducing this - parameter to 15, - 10, or 5 and - reducing net.inet.tcp.inflight.min - to a value such as 3500 to get the - desired effect. Reducing these parameters should be done - as a last resort only. + parameter to 15, 10, + or 5 and reducing + net.inet.tcp.inflight.min to a value such + as 3500 to get the desired effect. + Reducing these parameters should be done as a last resort + only. Virtual Memory <varname>kern.maxvnodes</varname> A vnode is the internal representation of a file or directory. Increasing the number of vnodes available to the operating system reduces disk I/O. Normally, this is handled by the operating system and does not need to be changed. In some cases where disk I/O is a bottleneck and the system is running out of vnodes, this setting needs to be increased. The amount of inactive and free RAM will need to be taken into account. To see the current number of vnodes in use: &prompt.root; sysctl vfs.numvnodes vfs.numvnodes: 91349 To see the maximum vnodes: &prompt.root; sysctl kern.maxvnodes kern.maxvnodes: 100000 If the current vnode usage is near the maximum, try increasing kern.maxvnodes by a value of 1000. Keep an eye on the number of vfs.numvnodes. If it climbs up to the maximum again, kern.maxvnodes will need to be increased further. Otherwise, a shift in memory usage as reported by &man.top.1; should be visible and more memory should be active. Adding Swap Space Sometimes a system requires more swap space. There are three ways to increase swap space: add a new hard drive, enable swap over NFS, or create a swap file on an existing partition. For information on how to encrypt swap space, which options exist, and why it should be done, refer to . Swap on a New or Existing Hard Drive Adding a new hard drive for swap gives better performance than adding a partition on an existing drive. Setting up - partitions and hard drives is explained in while discusses partition + partitions and hard drives is explained in + while + discusses partition layouts and swap partition size considerations. Use &man.swapon.8; to add a swap partition to the system. For example: &prompt.root; swapon /dev/ada1s1b - It is possible to use any partition not currently mounted, even if it already contains data. Using &man.swapon.8; on a partition that contains data will overwrite and destroy that data. Make sure that the partition to be added as swap is really the intended partition before running &man.swapon.8;. To automatically add this swap partition on boot, add an entry to /etc/fstab: /dev/ada1s1b none swap sw 0 0 See &man.fstab.5; for an explanation of the entries in /etc/fstab. Swapping over <literal>NFS</literal> Swapping over NFS is only recommended when there is no local hard disk to swap to. NFS swapping will be limited by the available network bandwidth and puts an additional burden on &man.nfsd.8;. Swapfiles To create a swap file, specify its size. The following example creates a 64MB file named /usr/swap0. Creating a Swapfile on &os; - The GENERIC kernel already includes the memory disk driver (&man.md.4;) required for this operation. When building a custom kernel, make sure to include the following line in the custom configuration file: device md For information on building a custom kernel, refer to . First, create the swapfile /usr/swap0: &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Then, set proper permissions on /usr/swap0: &prompt.root; chmod 0600 /usr/swap0 Enable the swap file in /etc/rc.conf: swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. Reboot the machine or, to enable the swap file immediately, type: &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 Hiten Pandya Written by Tom Rhodes Power and Resource Management It is important to utilize hardware resources in an efficient manner. Before the Advanced Configuration and Power Interface (ACPI) was introduced, it was difficult and inflexible for operating systems to manage the power usage and thermal properties of a system. The hardware was managed by the BIOS and the user had less control and visibility into the power management settings. Some limited configurability was available via Advanced Power Management (APM). Power and resource management allows the operating system to monitor system limits and to possibly provide an alert if the system temperature increases unexpectedly. This section provides comprehensive information about - ACPI. References will be provided for further - reading. + ACPI. References will be provided for + further reading. What Is ACPI? ACPI APM ACPI is a standard written by an alliance of vendors to provide a standard interface for hardware resources and power management. It is a key element in Operating System-directed configuration and Power Management as it provides more control and flexibility to the operating system. Modern systems stretched the limits of the current Plug and Play interfaces prior to the introduction of ACPI. ACPI is the direct successor to APM. Shortcomings of Advanced Power Management The APM facility controls the power usage of a system based on its activity. The APM BIOS is supplied by the vendor and is specific to the hardware platform. An APM driver in the operating system mediates access to the APM Software Interface, which allows management of power levels. APM should still be used for systems manufactured at or before the year 2000. There are four major problems in APM. First, power management is done by the vendor-specific BIOS, separate from the operating system. For example, the user can set idle-time values for a hard drive in the APM BIOS so that, when exceeded, the BIOS spins down the hard drive without the consent of the operating system. Second, the APM logic is embedded in the BIOS, and it operates outside the scope of the operating system. This means that users can only fix problems in the APM BIOS by flashing a new one into the ROM, which is a dangerous procedure with the potential to leave the system in an unrecoverable state if it fails. Third, APM is a vendor-specific technology, meaning that there is a lot of duplication of efforts and bugs found in one vendor's BIOS may not be solved in others. Lastly, the APM BIOS did not have enough room to implement a sophisticated power policy or one that can adapt well to the purpose of the machine. The Plug and Play BIOS (PNPBIOS) was unreliable in many situations. PNPBIOS is 16-bit technology, so the operating system has to use 16-bit emulation in order to interface with PNPBIOS methods. The &os; APM driver is documented in &man.apm.4;. Configuring <acronym>ACPI</acronym> The &man.acpi.4; driver is loaded by default at start up by &man.loader.8; and should not be compiled into the kernel. The reasoning is that modules are easier to work with and do not require a kernel rebuild. This has the advantage of making testing easier. Another reason is that starting ACPI after a system has been brought up often does not work well. If experiencing problems, ACPI can be disabled altogether. This driver should not and can not be unloaded because the system bus uses it for various hardware interactions. ACPI can be disabled by rebooting after setting hint.acpi.0.disabled="1" in /boot/loader.conf or by setting this variable at the &man.loader.8; prompt. ACPI and APM cannot coexist and should be used separately. The last one to load will terminate if the driver notices the other is running. ACPI can be used to put the system into a sleep mode with &man.acpiconf.8;, the flag, and a 1-5 option. Most users only need 1 (quick suspend to RAM) or 3 (suspend to RAM). Option 5 performs a soft-off which is the same action as: &prompt.root; halt -p Other options are available via &man.sysctl.8;. Refer to &man.acpi.4; and &man.acpiconf.8; for more information. Nate Lawson Written by Peter Schultz With contributions from Tom Rhodes Using and Debugging &os; <acronym>ACPI</acronym> ACPI problems ACPI is a fundamentally new way of discovering devices, managing power usage, and providing standardized access to various hardware previously managed by the BIOS. Progress is being made toward ACPI working on all systems, but bugs in some motherboards' ACPI Machine Language (AML) bytecode, incompleteness in &os;'s kernel subsystems, and bugs in the &intel; ACPI-CA interpreter continue to appear. This section is intended to help users assist the &os; ACPI maintainers in identifying the root cause of problems and in debugging and developing a solution. Submitting Debugging Information Before submitting a problem, ensure the latest BIOS version is installed and, if available, the embedded controller firmware version. When submitting a problem, send the following information to freebsd-acpi@FreeBSD.org: Description of the buggy behavior, including system type and model and anything that causes the bug to appear. Note as accurately as possible when the bug began occurring if it is new. The output of &man.dmesg.8; after running boot -v, including any error messages generated by the bug. The &man.dmesg.8; output from boot -v with ACPI disabled, if disabling it helps to fix the problem. Output from sysctl hw.acpi. This lists which features the system offers. The URL to a pasted version of the ACPI Source Language (ASL). Do not send the ASL directly to the list as it can be very large. Generate a copy of the ASL by running this command: &prompt.root; acpidump -dt > name-system.asl Substitute the login name for name and manufacturer/model for system. For example, use njl-FooCo6000.asl. Most &os; developers watch &a.current;, but one should submit problems to &a.acpi.name; to be sure it is seen. Be patient when waiting for a response. If the bug is not - immediately apparent, submit a - PR using &man.send-pr.1;. When entering a - PR, include the same information as - requested above. This helps developers to track the problem - and resolve it. Do not send a PR without - emailing &a.acpi.name; first as it is likely that the problem - has been reported before. + immediately apparent, submit a PR using + &man.send-pr.1;. When entering a PR, + include the same information as requested above. This helps + developers to track the problem and resolve it. Do not send a + PR without emailing &a.acpi.name; first as + it is likely that the problem has been reported before. Background ACPI ACPI is present in all modern computers that conform to the ia32 (x86), ia64 (Itanium), and amd64 (AMD) architectures. The full standard has many features including CPU performance management, power planes control, thermal zones, various battery systems, embedded controllers, and bus enumeration. Most systems implement less than the full standard. For instance, a desktop system usually only implements bus enumeration while a laptop might have cooling and battery management support as well. Laptops also have suspend and resume, with their own associated complexity. An ACPI-compliant system has various components. The BIOS and chipset vendors provide various fixed tables, such as FADT, in memory that specify things like the APIC map (used for SMP), config registers, and simple configuration values. Additionally, a bytecode table, the Differentiated System Description Table DSDT, specifies a tree-like name space of devices and methods. The ACPI driver must parse the fixed tables, implement an interpreter for the bytecode, and modify device drivers and the kernel to accept information from the ACPI subsystem. For &os;, &intel; has provided an interpreter (ACPI-CA) that is shared with &linux; and NetBSD. The path to the ACPI-CA source code is src/sys/contrib/dev/acpica. The glue code that allows ACPI-CA to work on &os; is in src/sys/dev/acpica/Osd. Finally, drivers that implement various ACPI devices are found in src/sys/dev/acpica. Common Problems ACPI problems For ACPI to work correctly, all the parts have to work correctly. Here are some common problems, in order of frequency of appearance, and some possible workarounds or fixes. Mouse Issues In some cases, resuming from a suspend operation will cause the mouse to fail. A known work around is to add hint.psm.0.flags="0x3000" to /boot/loader.conf. If this does not work, consider sending a bug report using &man.send-pr.1;. Suspend/Resume ACPI has three suspend to RAM (STR) states, S1-S3, and one suspend to disk state (STD), called S4. S5 is soft off and is the normal state the system is in when plugged in but not powered up. S4 can be implemented in two separate ways. S4BIOS is a BIOS-assisted suspend to disk. S4OS is implemented entirely by the operating system. Start by checking sysctl hw.acpi for the suspend-related items. Here are the results for a Thinkpad: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0 Use acpiconf -s to test S3, S4OS, and S5. An of one (1), indicates S4BIOS support instead of S4 OS. When testing suspend/resume, start with S1, if supported. This state is most likely to work since it does not require much driver support. No one has implemented S2, which is similar to S1. Next, try S3. This is the deepest STR state and requires a lot of driver support to properly reinitialize the hardware. If there are problems resuming, email &a.acpi.name;. However, the problem may not be resolved quickly since due to the amount of drivers and hardware that need more testing and work. A common problem with suspend/resume is that many device drivers do not save, restore, or reinitialize their firmware, registers, or device memory properly. As a first attempt at debugging the problem, try: &prompt.root; sysctl debug.bootverbose=1 &prompt.root; sysctl debug.acpi.suspend_bounce=1 &prompt.root; acpiconf -s 3 This test emulates the suspend/resume cycle of all device drivers without actually going into S3 state. In some cases, problems such as losing firmware state, device watchdog time out, and retrying forever, can be captured with this method. Note that the system will not really enter S3 state, which means devices may not lose power, and many will work fine even if suspend/resume methods are totally missing, unlike real S3 state. Harder cases require additional hardware, such as a serial port and cable for debugging through a serial console, a Firewire port and cable for using &man.dcons.4;, and kernel debugging skills. To help isolate the problem, remove as many drivers from the kernel as possible. If it works, narrow down which driver is the problem by loading drivers until it fails again. Typically, binary drivers like nvidia.ko, display drivers, and USB will have the most problems while Ethernet interfaces usually work fine. If drivers can be properly loaded and unloaded, automate this by putting the appropriate commands in /etc/rc.suspend and /etc/rc.resume. Try setting to 0 if the display is messed up after resume. Try setting longer or shorter values for to see if that helps. Try loading a recent &linux; distribution to see if suspend/resume works on the same hardware. If it works on &linux;, it is likely a &os; driver problem. Narrowing down which driver causes the problem will assist developers in fixing the problem. Since the ACPI maintainers rarely maintain other drivers, such as sound or ATA, any driver problems should also be posted to the &a.current.name; list and mailed to the driver maintainer. Advanced users can include debugging &man.printf.3;s in a problematic driver to track down where in its resume function it hangs. Finally, try disabling ACPI and enabling APM instead. If suspend/resume works with APM, stick with APM, especially on older hardware (pre-2000). It took vendors a while to get ACPI support correct and older hardware is more likely to have BIOS problems with ACPI. System Hangs Most system hangs are a result of lost interrupts or an interrupt storm. Chipsets may have problems based on boot, how the BIOS configures interrupts before correctness of the APIC (MADT) table, and routing of the System Control Interrupt (SCI). interrupt storms Interrupt storms can be distinguished from lost interrupts by checking the output of vmstat -i and looking at the line that has acpi0. If the counter is increasing at more than a couple per second, there is an interrupt storm. If the system appears hung, try breaking to DDB ( CTRL ALT ESC on console) and type show interrupts. APIC disabling When dealing with interrupt problems, try disabling APIC support with hint.apic.0.disabled="1" in /boot/loader.conf. Panics Panics are relatively rare for ACPI and are the top priority to be fixed. The first step is to isolate the steps to reproduce the panic, if possible, and get a backtrace. Follow the advice for enabling options DDB and setting up a serial console in or setting up a &man.dump.8; partition. To get a backtrace in DDB, use tr. When handwriting the backtrace, get at least the last five and the top five lines in the trace. Then, try to isolate the problem by booting with ACPI disabled. If that works, isolate the ACPI subsystem by using various values of . See &man.acpi.4; for some examples. System Powers Up After Suspend or Shutdown First, try setting hw.acpi.disable_on_poweroff="0" in &man.loader.conf.5;. This keeps ACPI from disabling various events during the shutdown process. Some systems need this value set to 1 (the default) for the same reason. This usually fixes the problem of a system powering up spontaneously after a suspend or poweroff. Other Problems For other problems with ACPI, such as it not working with a docking station or devices not being detected, email a description to &a.acpi.name;. Some issues may be related to unfinished parts of the ACPI subsystem which might take a while to be implemented. Be patient and prepared to test patches. <acronym>ASL</acronym>, &man.acpidump.8;, and <acronym>IASL</acronym> ACPI ASL Some BIOS vendors provide incorrect or buggy bytecode. This is usually manifested by kernel console messages like this: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND Often, these problems may be resolved by updating the BIOS to the latest revision. Most console messages are harmless, but if there are other problems like the battery status is not working, these messages are a good place to start looking for problems. The bytecode, known as AML, is compiled from a source language called ASL. The AML is found in the table known as the DSDT. To get a copy of the system's ASL, use &man.acpidump.8;. Include both , to show the contents of the fixed tables, and , to disassemble the - AML. Refer to for an example syntax. + AML. Refer to + for an example + syntax. The simplest first check is to recompile the ASL to check for errors. Warnings can usually be ignored, but errors are bugs that will usually prevent ACPI from working correctly. To recompile the ASL, issue the following command: &prompt.root; iasl your.asl Fixing the <acronym>ASL</acronym> ACPI ASL The goal of &os; is for everyone to have working ACPI without any user intervention. At this point, workarounds are still being developed for common mistakes made by BIOS vendors. The µsoft; interpreter (acpi.sys and acpiec.sys) does not strictly check for adherence to the standard, and thus many BIOS vendors who only test ACPI under &windows; never fix their ASL. &os; developers continue to identify and document which non-standard behavior is allowed by µsoft;'s interpreter and replicate it so that &os; can work without forcing users to fix the ASL. As a workaround, and to help identify behavior, fix the ASL manually. If this works, send a &man.diff.1; of the old and new ASL so developers can possibly work around the buggy behavior in ACPI-CA. ACPI error messages Here is a list of common error messages, their cause, and how to fix them: Operating System Dependencies Some AML versions assume the user is running &windows;. To override this, set hw.acpi.osname="Windows 2001" in /boot/loader.conf, using the strings in the ASL. Missing Return Statements Some methods do not explicitly return a value as the standard requires. While ACPI-CA does not handle this, &os; has a workaround that allows it to return the value implicitly. Explicit return statements can be added where required if the value which should be returned is known. To force &man.iasl.8; to compile the ASL, use the flag. Overriding the Default <acronym>AML</acronym> After customizing your.asl, compile it with this command: &prompt.root; iasl your.asl Adding the flag forces creation of the AML, even if there are errors during compilation. Some errors, such as missing return statements, are automatically worked around by the interpreter. The default output filename for &man.iasl.8; is DSDT.aml. Load this file instead of the BIOS's buggy copy, which is still present in flash memory, by editing /boot/loader.conf as follows: acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml" Be sure to copy DSDT.aml to /boot. Getting Debugging Output from <acronym>ACPI</acronym> ACPI problems ACPI debugging The ACPI driver has a flexible debugging facility. A set of subsystems and the level of verbosity can be specified. The subsystems to debug are specified as layers and are broken down into ACPI-CA components (ACPI_ALL_COMPONENTS) and ACPI hardware support (ACPI_ALL_DRIVERS). The verbosity of debugging output is specified as the level and ranges from ACPI_LV_ERROR (just report errors) to ACPI_LV_VERBOSE (everything). The level is a bitmask so multiple options can be set at once, separated by spaces. In practice, a serial console should be used to log the output so it is not lost as the console message buffer flushes. A full list of the individual layers and levels is found in &man.acpi.4;. Debugging output is not enabled by default. To enable it, add options ACPI_DEBUG to the kernel configuration file if ACPI is compiled into the kernel. Add ACPI_DEBUG=1 to /etc/make.conf to enable it globally. If it is a module, recompile just the acpi.ko module as follows: &prompt.root; cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1 Install acpi.ko in /boot/kernel and add the desired level and layer to /boot/loader.conf. This example enables debug messages for all ACPI-CA components and all ACPI hardware drivers such as (CPU and LID. It only outputs error messages at the least verbose level. debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ERROR" If the required information is triggered by a specific event, such as a suspend and then resume, leave out changes to /boot/loader.conf and instead use &man.sysctl.8; to specify the layer and level after booting and preparing the system for the specific event. The variables which can be set using &man.sysctl.8; are named the same as the tunables in /boot/loader.conf. References More information about ACPI may be found in the following locations: The &a.acpi; The ACPI Mailing List Archives The old ACPI Mailing List Archives The ACPI 2.0 Specification &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;, and &man.acpidb.8; DSDT debugging resource. diff --git a/en_US.ISO8859-1/books/handbook/geom/chapter.xml b/en_US.ISO8859-1/books/handbook/geom/chapter.xml index 102f07593a..8fa6b4b1b8 100644 --- a/en_US.ISO8859-1/books/handbook/geom/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/geom/chapter.xml @@ -1,1348 +1,1656 @@ Tom Rhodes Written by GEOM: Modular Disk Transformation Framework Synopsis GEOM GEOM Disk Framework GEOM This chapter covers the use of disks under the GEOM framework in &os;. This includes the major RAID control utilities which use the framework for configuration. This chapter will not go into in depth discussion on how GEOM handles or controls I/O, the underlying subsystem, or code. This information is provided in &man.geom.4; and its various SEE ALSO references. This chapter is also not a definitive guide to RAID configurations and only GEOM-supported RAID classifications will be discussed. After reading this chapter, you will know: What type of RAID support is available through GEOM. How to use the base utilities to configure, maintain, and manipulate the various RAID levels. How to mirror, stripe, encrypt, and remotely connect disk devices through GEOM. How to troubleshoot disks attached to the GEOM framework. Before reading this chapter, you should: Understand how &os; treats disk devices. Know how to configure and install a new &os; kernel. GEOM Introduction GEOM permits access and control to classes, such as Master Boot Records and BSD labels, through the use of providers, or the special files in /dev. By supporting various software RAID configurations, GEOM transparently provides access to the operating system and operating system utilities. Tom Rhodes Written by Murray Stokely RAID0 - Striping GEOM Striping Striping combine several disk drives into a single volume. In many cases, this is done through the use of hardware controllers. The GEOM disk subsystem provides software support for RAID0, also known as disk striping. In a RAID0 system, data is split into blocks that get written across all the drives in the array. Instead of having to wait on the system to write 256k to one disk, a RAID0 system can simultaneously write 64k to each of four different disks, offering superior I/O performance. This performance can be enhanced further by using multiple disk controllers. Each disk in a RAID0 stripe must be of the same size, since I/O requests are interleaved to read or write to multiple disks in parallel. Disk Striping Illustration Creating a Stripe of Unformatted ATA Disks Load the geom_stripe.ko module: &prompt.root; kldload geom_stripe Ensure that a suitable mount point exists. If this volume will become a root partition, then temporarily use another mount point such as /mnt: &prompt.root; mkdir /mnt Determine the device names for the disks which will be striped, and create the new stripe device. For example, to stripe two unused and unpartitioned ATA disks with device names of /dev/ad2 and /dev/ad3: &prompt.root; gstripe label -v st0 /dev/ad2 /dev/ad3 Metadata value stored on /dev/ad2. Metadata value stored on /dev/ad3. Done. Write a standard label, also known as a partition table, on the new volume and install the default bootstrap code: &prompt.root; bsdlabel -wB /dev/stripe/st0 This process should create two other devices in /dev/stripe in addition to st0. Those include st0a and st0c. At this point, a file system may be created on st0a using newfs: &prompt.root; newfs -U /dev/stripe/st0a Many numbers will glide across the screen, and after a few seconds, the process will be complete. The volume has been created and is ready to be mounted. To manually mount the created disk stripe: &prompt.root; mount /dev/stripe/st0a /mnt To mount this striped file system automatically during the boot process, place the volume information in /etc/fstab. In this example, a permanent mount point, named stripe, is created: &prompt.root; mkdir /stripe &prompt.root; echo "/dev/stripe/st0a /stripe ufs rw 2 2" \ >> /etc/fstab The geom_stripe.ko module must also be automatically loaded during system initialization, by adding a line to /boot/loader.conf: &prompt.root; echo 'geom_stripe_load="YES"' >> /boot/loader.conf RAID1 - Mirroring GEOM Disk Mirroring RAID1 RAID1, or mirroring, is the technique of writing the same data to more than one disk drive. Mirrors are usually used to guard against data loss due to drive failure. Each drive in a mirror contains an identical copy of the data. When an individual drive fails, the mirror continues to work, providing data from the drives that are still functioning. The computer keeps running, and the administrator has time to replace the failed drive without user interruption. Two common situations are illustrated in these examples. The first creates a mirror out of two new drives and uses it as a replacement for an existing single drive. The second example creates a mirror on a single new drive, copies the old drive's data to it, then inserts the old drive into the mirror. While this procedure is slightly more complicated, it only requires one new drive. Traditionally, the two drives in a mirror are identical in model and capacity, but &man.gmirror.8; does not require that. Mirrors created with dissimilar drives will have a capacity equal to that of the smallest drive in the mirror. Extra space on larger drives will be unused. Drives inserted into the mirror later must have at least as much capacity as the smallest drive already in the mirror. The mirroring procedures shown here are non-destructive, but as with any major disk operation, make a full backup first. Metadata Issues Many disk systems store metadata at the end of each disk. Old metadata should be erased before reusing the disk for a mirror. Most problems are caused by two particular types of leftover metadata: GPT partition tables, and old &man.gmirror.8; metadata from a previous mirror. GPT metadata can be erased with &man.gpart.8;. This example erases both primary and backup GPT partition tables from disk ada8: &prompt.root; gpart destroy -F ada8 &man.gmirror.8; can remove a disk from an active mirror and erase the metadata in one step. Here, the example disk ada8 is removed from the active mirror gm4: &prompt.root; gmirror remove gm4 ada8 If the mirror is not running but old mirror metadata is still on the disk, use gmirror clear to remove it: &prompt.root; gmirror clear ada8 &man.gmirror.8; stores one block of metadata at the end of the disk. Because GPT partition schemes also store metadata at the end of the disk, mirroring full GPT disks with &man.gmirror.8; is not recommended. MBR partitioning is used here because it only stores a partition table at the start of the disk and does not conflict with &man.gmirror.8;. Creating a Mirror with Two New Disks In this example, &os; has already been installed on a single disk, ada0. Two new disks, ada1 and ada2, have been connected to the system. A new mirror will be created on these two disks and used to replace the old single disk. &man.gmirror.8; requires a kernel module, geom_mirror.ko, either built into the kernel or loaded at boot- or run-time. Manually load the kernel module now: &prompt.root; gmirror load Create the mirror with the two new drives: &prompt.root; gmirror label -v gm0 /dev/ada1 /dev/ada2 gm0 is a user-chosen device name assigned to the new mirror. After the mirror has been started, this device name will appear in /dev/mirror/. MBR and bsdlabel partition tables can now be created on the mirror with &man.gpart.8;. Here we show a traditional split-filesystem layout, with partitions for /, swap, /var, /tmp, and /usr. A single / filesystem and a swap partition will also work. Partitions on the mirror do not have to be the same size as those on the existing disk, but they must be large enough to hold all the data already present on ada0. &prompt.root; gpart create -s MBR mirror/gm0 &prompt.root; gpart add -t freebsd -a 4k mirror/gm0 &prompt.root; gpart show mirror/gm0 => 63 156301423 mirror/gm0 MBR (74G) 63 63 - free - (31k) 126 156301299 1 freebsd (74G) 156301425 61 - free - (30k) &prompt.root; gpart create -s BSD mirror/gm0s1 &prompt.root; gpart add -t freebsd-ufs -a 4k -s 2g mirror/gm0s1 &prompt.root; gpart add -t freebsd-swap -a 4k -s 4g mirror/gm0s1 &prompt.root; gpart add -t freebsd-ufs -a 4k -s 2g mirror/gm0s1 &prompt.root; gpart add -t freebsd-ufs -a 4k -s 1g mirror/gm0s1 &prompt.root; gpart add -t freebsd-ufs -a 4k mirror/gm0s1 &prompt.root; gpart show mirror/gm0s1 => 0 156301299 mirror/gm0s1 BSD (74G) 0 2 - free - (1.0k) 2 4194304 1 freebsd-ufs (2.0G) 4194306 8388608 2 freebsd-swap (4.0G) 12582914 4194304 4 freebsd-ufs (2.0G) 16777218 2097152 5 freebsd-ufs (1.0G) 18874370 137426928 6 freebsd-ufs (65G) 156301298 1 - free - (512B) Make the mirror bootable by installing bootcode in the MBR and bsdlabel and setting the active slice: &prompt.root; gpart bootcode -b /boot/mbr mirror/gm0 &prompt.root; gpart set -a active -i 1 mirror/gm0 &prompt.root; gpart bootcode -b /boot/boot mirror/gm0s1 Format the filesystems on the new mirror, enabling soft-updates. &prompt.root; newfs -U /dev/mirror/gm0s1a &prompt.root; newfs -U /dev/mirror/gm0s1d &prompt.root; newfs -U /dev/mirror/gm0s1e &prompt.root; newfs -U /dev/mirror/gm0s1f Filesystems from the original ada0 disk can now be copied onto the mirror with &man.dump.8; and &man.restore.8;. &prompt.root; mount /dev/mirror/gm0s1a /mnt &prompt.root; dump -C16 -b64 -0aL -f - / | (cd /mnt && restore -rf -) &prompt.root; mount /dev/mirror/gm0s1d /mnt/var &prompt.root; mount /dev/mirror/gm0s1e /mnt/tmp &prompt.root; mount /dev/mirror/gm0s1f /mnt/usr &prompt.root; dump -C16 -b64 -0aL -f - /var | (cd /mnt/var && restore -rf -) &prompt.root; dump -C16 -b64 -0aL -f - /tmp | (cd /mnt/tmp && restore -rf -) &prompt.root; dump -C16 -b64 -0aL -f - /usr | (cd /mnt/usr && restore -rf -) /mnt/etc/fstab must be edited to point to the new mirror filesystems: # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm0s1d /var ufs rw 2 2 /dev/mirror/gm0s1e /tmp ufs rw 2 2 /dev/mirror/gm0s1f /usr ufs rw 2 2 If the &man.gmirror.8; kernel module has not been built into the kernel, /mnt/boot/loader.conf is edited to load the module at boot: geom_mirror_load="YES" Reboot the system to test the new mirror and verify that all data has been copied. The BIOS will see the mirror as two individual drives rather than a mirror. Because the drives are identical, it does not matter which is selected to boot. See the Troubleshooting section if there are problems booting. Powering down and disconnecting the original ada0 disk will allow it to be kept as an offline backup. In use, the mirror will behave just like the original single drive. Creating a Mirror with an Existing Drive In this example, &os; has already been installed on a single disk, ada0. A new disk, ada1, has been connected to the system. A one-disk mirror will be created on the new disk, the existing system copied onto it, and then the old disk will be inserted into the mirror. This slightly complex procedure is required because &man.gmirror.8; needs to put a 512-byte block of metadata at the end of each disk, and the existing ada0 has usually had all of its space already allocated. Load the &man.gmirror.8; kernel module: &prompt.root; gmirror load Check the media size of the original disk with &man.diskinfo.8;: &prompt.root; diskinfo -v ada0 | head -n3 /dev/ada0 512 # sectorsize 1000204821504 # mediasize in bytes (931G) Create a mirror on the new disk. To make certain that the mirror capacity is not any larger than the original drive, &man.gnop.8; is used to create a fake drive of the exact same size. This drive does not store any data, but is used only to limit the size of the mirror. When &man.gmirror.8; creates the mirror, it will restrict the capacity to the size of gzero.nop, even if the new drive (ada1) has more space. Note that the 1000204821504 in the second line should be equal to ada0's media size as shown by &man.diskinfo.8; above. &prompt.root; geom zero load &prompt.root; gnop create -s 1000204821504 gzero &prompt.root; gmirror label -v gm0 gzero.nop ada1 &prompt.root; gmirror forget gm0 gzero.nop does not store any data, so the mirror does not see it as connected. The mirror is told to forget unconnected components, removing references to gzero.nop. The result is a mirror device containing only a single disk, ada1. After creating gm0, view the partition table on ada0. This output is from a 1 TB drive. If there is some unallocated space at the end of the drive, the contents may be copied directly from ada0 to the new mirror. However, if the output shows that all of the space on the disk is allocated like the following listing, there is no space available for the 512-byte &man.gmirror.8; metadata at the end of the disk. &prompt.root; gpart show ada0 => 63 1953525105 ada0 MBR (931G) 63 1953525105 1 freebsd [active] (931G) In this case, the partition table must be edited to reduce the capacity by one sector on mirror/gm0. The procedure will be explained later. In either case, partition tables on the primary disk should be copied first with the &man.gpart.8; backup and restore subcommands. &prompt.root; gpart backup ada0 > table.ada0 &prompt.root; gpart backup ada0s1 > table.ada0s1 These commands create two files, table.ada0 and table.ada0s1. This example is from a 1 TB drive: &prompt.root; cat table.ada0 MBR 4 1 freebsd 63 1953525105 [active] &prompt.root; cat table.ada0s1 BSD 8 1 freebsd-ufs 0 4194304 2 freebsd-swap 4194304 33554432 4 freebsd-ufs 37748736 50331648 5 freebsd-ufs 88080384 41943040 6 freebsd-ufs 130023424 838860800 7 freebsd-ufs 968884224 984640881 If the output of gpart show shows no free space at the end of the disk, the size of both the slice and the last partition must be reduced by one sector. Edit the two files, reducing the size of both the slice and last partition by one. These are the last numbers in each listing. &prompt.root; cat table.ada0 MBR 4 1 freebsd 63 1953525104 [active] &prompt.root; cat table.ada0s1 BSD 8 1 freebsd-ufs 0 4194304 2 freebsd-swap 4194304 33554432 4 freebsd-ufs 37748736 50331648 5 freebsd-ufs 88080384 41943040 6 freebsd-ufs 130023424 838860800 7 freebsd-ufs 968884224 984640880 If at least one sector was unallocated at the end of the disk, these two files can be used without modification. Now restore the partition table into mirror/gm0: &prompt.root; gpart restore mirror/gm0 < table.ada0 &prompt.root; gpart restore mirror/gm0s1 < table.ada0s1 Check the partition table with gpart show. This example has gm0s1a for /, gm0s1d for /var, gm0s1e for /usr, gm0s1f for /data1, and gm0s1g for /data2. &prompt.root; gpart show mirror/gm0 => 63 1953525104 mirror/gm0 MBR (931G) 63 1953525042 1 freebsd [active] (931G) 1953525105 62 - free - (31k) &prompt.root; gpart show mirror/gm0s1 => 0 1953525042 mirror/gm0s1 BSD (931G) 0 2097152 1 freebsd-ufs (1.0G) 2097152 16777216 2 freebsd-swap (8.0G) 18874368 41943040 4 freebsd-ufs (20G) 60817408 20971520 5 freebsd-ufs (10G) 81788928 629145600 6 freebsd-ufs (300G) 710934528 1242590514 7 freebsd-ufs (592G) 1953525042 63 - free - (31k) Both the slice and the last partition should have some free space at the end of each disk. Create filesystems on these new partitions. The number of partitions will vary, matching the partitions on the original disk, ada0. &prompt.root; newfs -U /dev/mirror/gm0s1a &prompt.root; newfs -U /dev/mirror/gm0s1d &prompt.root; newfs -U /dev/mirror/gm0s1e &prompt.root; newfs -U /dev/mirror/gm0s1f &prompt.root; newfs -U /dev/mirror/gm0s1g Make the mirror bootable by installing bootcode in the MBR and bsdlabel and setting the active slice: &prompt.root; gpart bootcode -b /boot/mbr mirror/gm0 &prompt.root; gpart set -a active -i 1 mirror/gm0 &prompt.root; gpart bootcode -b /boot/boot mirror/gm0s1 Adjust /etc/fstab to use the new partitions on the mirror. Back up this file first by copying it to /etc/fstab.orig. &prompt.root; cp /etc/fstab /etc/fstab.orig Edit /etc/fstab, replacing /dev/ada0 with mirror/gm0. # Device Mountpoint FStype Options Dump Pass# /dev/mirror/gm0s1a / ufs rw 1 1 /dev/mirror/gm0s1b none swap sw 0 0 /dev/mirror/gm0s1d /var ufs rw 2 2 /dev/mirror/gm0s1e /usr ufs rw 2 2 /dev/mirror/gm0s1f /data1 ufs rw 2 2 /dev/mirror/gm0s1g /data2 ufs rw 2 2 If the &man.gmirror.8; kernel module has not been built into the kernel, edit /boot/loader.conf to load it: geom_mirror_load="YES" Filesystems from the original disk can now be copied onto the mirror with &man.dump.8; and &man.restore.8;. Note that it may take some time to create a snapshot for each filesystem dumped with dump -L. &prompt.root; mount /dev/mirror/gm0s1a /mnt &prompt.root; dump -C16 -b64 -0aL -f - / | (cd /mnt && restore -rf -) &prompt.root; mount /dev/mirror/gm0s1d /mnt/var &prompt.root; mount /dev/mirror/gm0s1e /mnt/usr &prompt.root; mount /dev/mirror/gm0s1f /mnt/data1 &prompt.root; mount /dev/mirror/gm0s1g /mnt/data2 &prompt.root; dump -C16 -b64 -0aL -f - /usr | (cd /mnt/usr && restore -rf -) &prompt.root; dump -C16 -b64 -0aL -f - /var | (cd /mnt/var && restore -rf -) &prompt.root; dump -C16 -b64 -0aL -f - /data1 | (cd /mnt/data1 && restore -rf -) &prompt.root; dump -C16 -b64 -0aL -f - /data2 | (cd /mnt/data2 && restore -rf -) Restart the system, booting from ada1. If everything is working, the system will boot from mirror/gm0, which now contains the same data as ada0 had previously. See the Troubleshooting section if there are problems booting. At this point, the mirror still consists of only the single ada1 disk. After booting from mirror/gm0 successfully, the final step is inserting ada0 into the mirror. When ada0 is inserted into the mirror, its former contents will be overwritten by data on the mirror. Make certain that mirror/gm0 has the same contents as ada0 before adding ada0 to the mirror. If there is something wrong with the contents copied by &man.dump.8; and &man.restore.8;, revert /etc/fstab to mount the filesystems on ada0, reboot, and try the whole procedure again. &prompt.root; gmirror insert gm0 ada0 GEOM_MIRROR: Device gm0: rebuilding provider ada0 Synchronization between the two disks will start immediately. &man.gmirror.8; status shows the progress. &prompt.root; gmirror status Name Status Components mirror/gm0 DEGRADED ada1 (ACTIVE) ada0 (SYNCHRONIZING, 64%) After a while, synchronization will finish. GEOM_MIRROR: Device gm0: rebuilding provider ada0 finished. &prompt.root; gmirror status Name Status Components mirror/gm0 COMPLETE ada1 (ACTIVE) ada0 (ACTIVE) mirror/gm0 now consists of the two disks ada0 and ada1, and the contents are automatically synchronized with each other. In use, mirror/gm0 will behave just like the original single drive. Troubleshooting Problems with Booting BIOS Settings BIOS settings may have to be changed to boot from one of the new mirrored drives. Either mirror drive can be used for booting, as they contain identical data. Boot Problems If the boot stopped with this message, something is wrong with the mirror device: Mounting from ufs:/dev/mirror/gm0s1a failed with error 19. Loader variables: vfs.root.mountfrom=ufs:/dev/mirror/gm0s1a vfs.root.mountfrom.options=rw Manual root filesystem specification: <fstype>:<device> [options] Mount <device> using filesystem <fstype> and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) <empty line> Abort manual input mountroot> Forgetting to load the geom_mirror module in /boot/loader.conf can cause this problem. To fix it, boot from a &os; 9.0 or later installation media and choose Shell at the first prompt. Then load the mirror module and mount the mirror device: &prompt.root; gmirror load &prompt.root; mount /dev/mirror/gm0s1a /mnt Edit /mnt/boot/loader.conf, adding a line to load the mirror module: geom_mirror_load="YES" Save the file and reboot. Other problems that cause error 19 require more effort to fix. Enter ufs:/dev/ada0s1a at the boot loader prompt. Although the system should boot from ada0, another prompt to select a shell appears because /etc/fstab is incorrect. Press the Enter key at the prompt. Undo the modifications so far by reverting /etc/fstab, mounting filesystems from the original disk (ada0) instead of the mirror. Reboot the system and try the procedure again. Enter full pathname of shell or RETURN for /bin/sh: &prompt.root; cp /etc/fstab.orig /etc/fstab &prompt.root; reboot Recovering from Disk Failure The benefit of disk mirroring is that an individual disk can fail without causing the mirror to lose any data. In the above example, if ada0 fails, the mirror will continue to work, providing data from the remaining working drive, ada1. To replace the failed drive, shut down the system and physically replace the failed drive with a new drive of equal or greater capacity. Manufacturers use somewhat arbitrary values when rating drives in gigabytes, and the only way to really be sure is to compare the total count of sectors shown by diskinfo -v. A drive with larger capacity than the mirror will work, although the extra space on the new drive will not be used. After the computer is powered back up, the mirror will be running in a degraded mode with only one drive. The mirror is told to forget drives that are not currently connected: &prompt.root; gmirror forget gm0 Any old metadata should be cleared from the replacement disk. Then the disk, ada4 for this example, is inserted into the mirror: &prompt.root; gmirror insert gm0 /dev/ada4 Resynchronization begins when the new drive is inserted into the mirror. This process of copying mirror data to a new drive can take a while. Performance of the mirror will be greatly reduced during the copy, so inserting new drives is best done when there is low demand on the computer. Progress can be monitored with gmirror status, which shows drives that are being synchronized and the percentage of completion. During resynchronization, the status will be DEGRADED, changing to COMPLETE when the process is finished. + + + + + Warren + Block + Originally contributed by + + + + Software <acronym>RAID</acronym> Devices + + + GEOM + + + Software RAID Devices + Hardware-assisted RAID + + + Some motherboards and expansion cards add some simple + hardware, usually just a ROM, that allows the + computer to boot from a RAID array. After + booting, access to the RAID array is handled + by software running on the computer's main processor. This + hardware-assisted software + RAID gives RAID + arrays that are not dependent on any particular operating + system, and which are functional even before an operating system + is loaded. + + Several levels of RAID are supported, + depending on the hardware in use. See &man.graid.8; for a + complete list. + + &man.graid.8; requires the geom_raid.ko + kernel module, which is included in the + GENERIC kernel starting with &os; 9.1. + If needed, it can be loaded manually with + graid load. + + + Creating an Array + + Software RAID devices often have a menu + that can be entered by pressing special keys when the computer + is booting. The menu can be used to create and delete + RAID arrays. &man.graid.8; can also create + arrays directly from the command line. + + graid label is used to create a new + array. The motherboard used for this example has an Intel + software RAID chipset, so the Intel + metadata format is specified. The new array is given a label + of gm0, it is a mirror + (RAID1), and uses drives + ada0 and + ada1. + + + Some space on the drives will be overwritten when they + are made into a new array. Back up existing data + first! + + + &prompt.root; graid label Intel gm0 RAID1 ada0 ada1 +GEOM_RAID: Intel-a29ea104: Array Intel-a29ea104 created. +GEOM_RAID: Intel-a29ea104: Disk ada0 state changed from NONE to ACTIVE. +GEOM_RAID: Intel-a29ea104: Subdisk gm0:0-ada0 state changed from NONE to ACTIVE. +GEOM_RAID: Intel-a29ea104: Disk ada1 state changed from NONE to ACTIVE. +GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-ada1 state changed from NONE to ACTIVE. +GEOM_RAID: Intel-a29ea104: Array started. +GEOM_RAID: Intel-a29ea104: Volume gm0 state changed from STARTING to OPTIMAL. +Intel-a29ea104 created +GEOM_RAID: Intel-a29ea104: Provider raid/r0 for volume gm0 created. + + A status check shows the new mirror is ready for + use: + + &prompt.root; graid status + Name Status Components +raid/r0 OPTIMAL ada0 (ACTIVE (ACTIVE)) + ada1 (ACTIVE (ACTIVE)) + + The array device appears in + /dev/raid/. The first array is called + r0. Additional arrays, if present, + will be r1, + r2, and so on. + + The BIOS menu on some of these devices + can create arrays with special characters in their names. To + avoid problems with those special characters, arrays are given + simple numbered names like r0. To + show the actual labels, like gm0 in + the example above, use &man.sysctl.8;: + + &prompt.root; sysctl kern.geom.raid.name_format=1 + + + + Multiple Volumes + + Some software RAID devices support + more than one volume on an array. + Volumes work like partitions, allowing space on the physical + drives to be split and used in different ways. For example, + Intel software RAID devices support two + volumes. This example creates a 40 G mirror for safely + storing the operating system, followed by a 20 G + RAID0 (stripe) volume for fast temporary + storage: + + &prompt.root; graid label -S 40G Intel gm0 RAID1 ada0 ada1 +&prompt.root; graid add -S 20G gm0 RAID0 + + Volumes appear as additional + rX entries + in /dev/raid/. An array with two volumes + will show r0 and + r1. + + See &man.graid.8; for the number of volumes supported by + different software RAID devices. + + + + Converting a Single Drive to a Mirror + + Under certain specific conditions, it is possible to + convert an existing single drive to a &man.graid.8; array + without reformatting. To avoid data loss during the + conversion, the existing drive must meet these minimum + requirements: + + + + The drive must be partitioned with the + MBR partitioning scheme. + GPT or other partitioning schemes with + metadata at the end of the drive will be overwritten and + corrupted by the &man.graid.8; metadata. + + + + There must be enough unpartitioned and unused space at + the end of the drive to hold the &man.graid.8; metadata. + This metadata varies in size, but the largest occupies + 64 M, so at least that much free space is + recommended. + + + + If the drive meets these requirements, start by making a + full backup. Then create a single-drive mirror with that + drive: + + &prompt.root; graid label Intel gm0 RAID1 ada0 NONE + + &man.graid.8; metadata was written to the end of the drive + in the unused space. A second drive can now be inserted into + the mirror: + + &prompt.root; graid insert raid/r0 ada1 + + Data from the original drive will immediately begin to be + copied to the second drive. The mirror will operate in + degraded status until the copy is complete. + + + + Inserting New Drives into the Array + + Drives can be inserted into an array as replacements for + drives that have failed or are missing. If there are no + failed or missing drives, the new drive becomes a spare. For + example, inserting a new drive into a working two-drive mirror + results in a two-drive mirror with one spare drive, not a + three-drive mirror. + + In the example mirror array, data immediately begins to be + copied to the newly-inserted drive. Any existing information + on the new drive will be overwritten. + + &prompt.root; graid insert raid/r0 ada1 +GEOM_RAID: Intel-a29ea104: Disk ada1 state changed from NONE to ACTIVE. +GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-ada1 state changed from NONE to NEW. +GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-ada1 state changed from NEW to REBUILD. +GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-ada1 rebuild start at 0. + + + + Removing Drives from the Array + + Individual drives can be permanently removed from a + from an array and their metadata erased: + + &prompt.root; graid remove raid/r0 ada1 +GEOM_RAID: Intel-a29ea104: Disk ada1 state changed from ACTIVE to OFFLINE. +GEOM_RAID: Intel-a29ea104: Subdisk gm0:1-[unknown] state changed from ACTIVE to NONE. +GEOM_RAID: Intel-a29ea104: Volume gm0 state changed from OPTIMAL to DEGRADED. + + + + Stopping the Array + + An array can be stopped without removing metadata from the + drives. The array will be restarted when the system is + booted. + + &prompt.root; graid stop raid/r0 + + + + Checking Array Status + + Array status can be checked at any time. After a drive + was added to the mirror in the example above, data is being + copied from the original drive to the new drive: + + &prompt.root; graid status + Name Status Components +raid/r0 DEGRADED ada0 (ACTIVE (ACTIVE)) + ada1 (ACTIVE (REBUILD 28%)) + + Some types of arrays, like RAID0 or + CONCAT, may not be shown in the status + report if disks have failed. To see these partially-failed + arrays, add : + + &prompt.root; graid status -ga + Name Status Components +Intel-e2d07d9a BROKEN ada6 (ACTIVE (ACTIVE)) + + + + Deleting Arrays + + Arrays are destroyed by deleting all of the volumes from + them. When the last volume present is deleted, the array is + stopped and metadata is removed from the drives: + + &prompt.root; graid delete raid/r0 + + + + Deleting Unexpected Arrays + + Drives may unexpectedly contain &man.graid.8; metadata, + either from previous use or manufacturer testing. + &man.graid.8; will detect these drives and create an array, + interfering with access to the individual drive. To remove + the unwanted metadata: + + + + Boot the system. At the boot menu, select + 2 for the loader prompt. Enter: + + OK set kern.geom.raid.enable=0 +OK boot + + The system will boot with &man.graid.8; + disabled. + + + + Back up all data on the affected drive. + + + + As a workaround, &man.graid.8; array detection + can be disabled by adding + + kern.geom.raid.enable=0 + + to /boot/loader.conf. + + To permanently remove the &man.graid.8; metadata + from the affected drive, boot a &os; installation + CD-ROM or memory stick, and select + Shell. Use status + to find the name of the array, typically + raid/r0: + + &prompt.root; graid status + Name Status Components +raid/r0 OPTIMAL ada0 (ACTIVE (ACTIVE)) + ada1 (ACTIVE (ACTIVE)) + + Delete the volume by name: + + &prompt.root; graid delete raid/r0 + + If there is more than one volume shown, repeat the + process for each volume. After the last array has been + deleted, the volume will be destroyed. + + Reboot and verify data, restoring from backup if + necessary. After the metadata has been removed, the + kern.geom.raid.enable=0 entry in + /boot/loader.conf can also be + removed. + + + + + Mark Gladman Written by Daniel Gerzo Tom Rhodes Based on documentation by Murray Stokely <acronym>RAID</acronym>3 - Byte-level Striping with Dedicated Parity GEOM RAID3 RAID3 is a method used to combine several disk drives into a single volume with a dedicated parity disk. In a RAID3 system, data is split up into a number of bytes that are written across all the drives in the array except for one disk which acts as a dedicated parity disk. This means that reading 1024KB from a RAID3 implementation will access all disks in the array. Performance can be enhanced by using multiple disk controllers. The RAID3 array provides a fault tolerance of 1 drive, while providing a capacity of 1 - 1/n times the total capacity of all drives in the array, where n is the number of hard drives in the array. Such a configuration is mostly suitable for storing data of larger sizes such as multimedia files. At least 3 physical hard drives are required to build a RAID3 array. Each disk must be of the same size, since I/O requests are interleaved to read or write to multiple disks in parallel. Also, due to the nature of RAID3, the number of drives must be equal to 3, 5, 9, 17, and so on, or 2^n + 1. Creating a Dedicated <acronym>RAID</acronym>3 Array In &os;, support for RAID3 is implemented by the &man.graid3.8; GEOM class. Creating a dedicated RAID3 array on &os; requires the following steps. While it is theoretically possible to boot from a RAID3 array on &os;, that configuration is uncommon and is not advised. First, load the geom_raid3.ko kernel module by issuing the following command: &prompt.root; graid3 load Alternatively, it is possible to manually load the geom_raid3.ko module: &prompt.root; kldload geom_raid3.ko Create or ensure that a suitable mount point exists: &prompt.root; mkdir /multimedia/ Determine the device names for the disks which will be added to the array, and create the new RAID3 device. The final device listed will act as the dedicated parity disk. This example uses three unpartitioned ATA drives: ada1 and ada2 for data, and ada3 for parity. &prompt.root; graid3 label -v gr0 /dev/ada1 /dev/ada2 /dev/ada3 Metadata value stored on /dev/ada1. Metadata value stored on /dev/ada2. Metadata value stored on /dev/ada3. Done. Partition the newly created gr0 device and put a UFS file system on it: &prompt.root; gpart create -s GPT /dev/raid3/gr0 &prompt.root; gpart add -t freebsd-ufs /dev/raid3/gr0 &prompt.root; newfs -j /dev/raid3/gr0p1 Many numbers will glide across the screen, and after a bit of time, the process will be complete. The volume has been created and is ready to be mounted: &prompt.root; mount /dev/raid3/gr0p1 /multimedia/ The RAID3 array is now ready to use. Additional configuration is needed to retain the above setup across system reboots. The geom_raid3.ko module must be loaded before the array can be mounted. To automatically load the kernel module during system initialization, add the following line to /boot/loader.conf: geom_raid3_load="YES" The following volume information must be added to /etc/fstab in order to automatically mount the array's file system during the system boot process: /dev/raid3/gr0p1 /multimedia ufs rw 2 2 GEOM Gate Network Devices GEOM supports the remote use of devices, such as disks, CD-ROMs, and files through the use of the gate utilities. This is similar to NFS. To begin, an exports file must be created. This file specifies who is permitted to access the exported resources and what level of access they are offered. For example, to export the fourth slice on the first SCSI disk, the following /etc/gg.exports is more than adequate: 192.168.1.0/24 RW /dev/da0s4d This allows all hosts inside the specified private network access to the file system on the da0s4d partition. To export this device, ensure it is not currently mounted, and start the &man.ggated.8; server daemon: &prompt.root; ggated To mount the device on the client machine, issue the following commands: &prompt.root; ggatec create -o rw 192.168.1.1 /dev/da0s4d ggate0 &prompt.root; mount /dev/ggate0 /mnt The device may now be accessed through the /mnt mount point. However, this will fail if the device is currently mounted on either the server machine or any other machine on the network. When the device is no longer needed, unmount it with &man.umount.8;, similar to any other disk device. Labeling Disk Devices GEOM Disk Labels During system initialization, the &os; kernel creates device nodes as devices are found. This method of probing for devices raises some issues. For instance, what if a new disk device is added via USB? It is likely that a flash device may be handed the device name of da0 and the original da0 shifted to da1. This will cause issues mounting file systems if they are listed in /etc/fstab which may also prevent the system from booting. One solution is to chain SCSI devices in order so a new device added to the SCSI card will be issued unused device numbers. But what about USB devices which may replace the primary SCSI disk? This happens because USB devices are usually probed before the SCSI card. One solution is to only insert these devices after the system has been booted. Another method is to use only a single ATA drive and never list the SCSI devices in /etc/fstab. A better solution is to use glabel to label the disk devices and use the labels in /etc/fstab. Because glabel stores the label in the last sector of a given provider, the label will remain persistent across reboots. By using this label as a device, the file system may always be mounted regardless of what device node it is accessed through. glabel can create both transient and permanent labels. Only permanent labels are consistent across reboots. Refer to &man.glabel.8; for more information on the differences between labels. Label Types and Examples Permanent labels can be a generic or a file system label. Permanent file system labels can be created with &man.tunefs.8; or &man.newfs.8;. These types of labels are created in a sub-directory of /dev, and will be named according to the file system type. For example, UFS2 file system labels will be created in /dev/ufs. Generic permanent labels can be created with glabel label. These are not file system specific and will be created in /dev/label. Temporary labels are destroyed at the next reboot. These labels are created in /dev/label and are suited to experimentation. A temporary label can be created using glabel create. To create a permanent label for a UFS2 file system without destroying any data, issue the following command: &prompt.root; tunefs -L home /dev/da3 If the file system is full, this may cause data corruption. A label should now exist in /dev/ufs which may be added to /etc/fstab: /dev/ufs/home /home ufs rw 2 2 The file system must not be mounted while attempting to run tunefs. Now the file system may be mounted: &prompt.root; mount /home From this point on, so long as the geom_label.ko kernel module is loaded at boot with /boot/loader.conf or the GEOM_LABEL kernel option is present, the device node may change without any ill effect on the system. File systems may also be created with a default label by using the flag with newfs. Refer to &man.newfs.8; for more information. The following command can be used to destroy the label: &prompt.root; glabel destroy home The following example shows how to label the partitions of a boot disk. Labeling Partitions on the Boot Disk By permanently labeling the partitions on the boot disk, the system should be able to continue to boot normally, even if the disk is moved to another controller or transferred to a different system. For this example, it is assumed that a single ATA disk is used, which is currently recognized by the system as ad0. It is also assumed that the standard &os; partition scheme is used, with /, /var, /usr and /tmp, as well as a swap partition. Reboot the system, and at the &man.loader.8; prompt, press 4 to boot into single user mode. Then enter the following commands: &prompt.root; glabel label rootfs /dev/ad0s1a GEOM_LABEL: Label for provider /dev/ad0s1a is label/rootfs &prompt.root; glabel label var /dev/ad0s1d GEOM_LABEL: Label for provider /dev/ad0s1d is label/var &prompt.root; glabel label usr /dev/ad0s1f GEOM_LABEL: Label for provider /dev/ad0s1f is label/usr &prompt.root; glabel label tmp /dev/ad0s1e GEOM_LABEL: Label for provider /dev/ad0s1e is label/tmp &prompt.root; glabel label swap /dev/ad0s1b GEOM_LABEL: Label for provider /dev/ad0s1b is label/swap &prompt.root; exit The system will continue with multi-user boot. After the boot completes, edit /etc/fstab and replace the conventional device names, with their respective labels. The final /etc/fstab will look like this: # Device Mountpoint FStype Options Dump Pass# /dev/label/swap none swap sw 0 0 /dev/label/rootfs / ufs rw 1 1 /dev/label/tmp /tmp ufs rw 2 2 /dev/label/usr /usr ufs rw 2 2 /dev/label/var /var ufs rw 2 2 The system can now be rebooted. If everything went well, it will come up normally and mount will show: &prompt.root; mount /dev/label/rootfs on / (ufs, local) devfs on /dev (devfs, local) /dev/label/tmp on /tmp (ufs, local, soft-updates) /dev/label/usr on /usr (ufs, local, soft-updates) /dev/label/var on /var (ufs, local, soft-updates) Starting with &os; 7.2, the &man.glabel.8; class supports a new label type for UFS file systems, based on the unique file system id, ufsid. These labels may be found in /dev/ufsid and are created automatically during system startup. It is possible to use ufsid labels to mount partitions using /etc/fstab. Use glabel status to receive a list of file systems and their corresponding ufsid labels: &prompt.user; glabel status Name Status Components ufsid/486b6fc38d330916 N/A ad4s1d ufsid/486b6fc16926168e N/A ad4s1f In the above example, ad4s1d represents /var, while ad4s1f represents /usr. Using the ufsid values shown, these partitions may now be mounted with the following entries in /etc/fstab: /dev/ufsid/486b6fc38d330916 /var ufs rw 2 2 /dev/ufsid/486b6fc16926168e /usr ufs rw 2 2 Any partitions with ufsid labels can be mounted in this way, eliminating the need to manually create permanent labels, while still enjoying the benefits of device name independent mounting. UFS Journaling Through GEOM GEOM Journaling Beginning with &os; 7.0, support for UFS journals is available. The implementation is provided through the GEOM subsystem and is configured using &man.gjournal.8;. Journaling stores a log of file system transactions, such as changes that make up a complete disk write operation, before meta-data and file writes are committed to the disk. This transaction log can later be replayed to redo file system transactions, preventing file system inconsistencies. This method provides another mechanism to protect against data loss and inconsistencies of the file system. Unlike Soft Updates, which tracks and enforces meta-data updates, and snapshots, which create an image of the file system, a log is stored in disk space specifically for this task, and in some cases, may be stored on another disk entirely. Unlike other file system journaling implementations, the gjournal method is block based and not implemented as part of the file system. It is a GEOM extension. To enable support for gjournal, the &os; kernel must have the following option which is the default on &os; 7.0 and later: options UFS_GJOURNAL If journaled volumes need to be mounted during startup, the geom_journal.ko kernel module needs to be loaded, by adding the following line to /boot/loader.conf: geom_journal_load="YES" Alternatively, this function can be built into a custom kernel, by adding the following line in the kernel configuration file: options GEOM_JOURNAL Creating a journal on a free file system may now be done using the following steps. In this example, da4 is a new SCSI disk: &prompt.root; gjournal load &prompt.root; gjournal label /dev/da4 At this point, there should be a /dev/da4 device node and a /dev/da4.journal device node. A file system may now be created on this device: &prompt.root; newfs -O 2 -J /dev/da4.journal This command will create a UFS2 file system on the journaled device. mount the device at the desired point with: &prompt.root; mount /dev/da4.journal /mnt In the case of several slices, a journal will be created for each individual slice. For instance, if ad4s1 and ad4s2 are both slices, then gjournal will create ad4s1.journal and ad4s2.journal. For better performance, the journal may be kept on another disk. In this configuration, the journal provider or storage device should be listed after the device to enable journaling on. Journaling may also be enabled on current file systems by using tunefs. However, always make a backup before attempting to alter a file system. In most cases, gjournal will fail if it is unable to create the journal, but this does not protect against data loss incurred as a result of misusing tunefs. It is also possible to journal the boot disk of a &os; system. Refer to the article Implementing UFS Journaling on a Desktop PC for detailed instructions. diff --git a/en_US.ISO8859-1/books/handbook/l10n/chapter.xml b/en_US.ISO8859-1/books/handbook/l10n/chapter.xml index 544c8b7f91..51c669150b 100644 --- a/en_US.ISO8859-1/books/handbook/l10n/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/l10n/chapter.xml @@ -1,976 +1,978 @@ Andrey Chernov Contributed by Michael C. Wu Rewritten by Localization - <acronym>i18n</acronym>/<acronym>L10n</acronym> Usage and Setup Synopsis &os; is a distributed project with users and contributors located all over the world. This chapter discusses the internationalization and localization features of &os; that allow non-English speaking users to get real work done. Since there are many aspects of the i18n implementation in both the system and application levels, more specific sources of documentation are referred to, where applicable. After reading this chapter, you will know: + How different languages and locales are encoded on modern operating systems. + How to set the locale for a login shell. + How to configure the console for non-English languages. + - How to use Xorgeffectively + How to use Xorg effectively with different languages. + Where to find more information about writing i18n-compliant applications. Before reading this chapter, you should: Know how to install additional third-party applications. The Basics What Is <acronym>i18n</acronym>/<acronym>L10n</acronym>? internationalization localization localization The term internationalization has been shortened to i18n, which represents the number of letters between the first and the last letters of internationalization. L10n uses the same naming scheme, coming from localization. Combined together, i18n/L10n methods, protocols, and applications allow users to use languages of their choice. i18n applications are programmed using i18n kits under libraries. These allow developers to write a simple file and translate displayed menus and texts to each language. Why Use <acronym>i18n</acronym>/<acronym>L10n</acronym>? Using i18n/L10n allows a user to view, input, or process data in non-English languages. Which Languages Are Supported? i18n and L10n are not &os; specific. Currently, one can choose from most of the major languages, including but not limited to: Chinese, German, Japanese, Korean, French, Russian, and Vietnamese. Using Localization locale Localization settings are based on three main terms: Language Code, Country Code, and Encoding. Locale names are constructed from these parts as follows: LanguageCode_CountryCode.Encoding Language and Country Codes language codes country codes In order to localize a &os; system to a specific language, the user needs to determine the codes for the specific country and language as the country code tells applications which variation of the given language to use. The following are examples of language/country codes: Language/Country Code Description en_US English - United States ru_RU Russian for Russia zh_TW Traditional Chinese for Taiwan A complete listing of available locales can be found by typing: &prompt.user; locale -a - Encodings encodings ASCII Some languages use non-ASCII encodings that are 8-bit, wide, or multibyte characters. For more information on these encodings, refer to &man.multibyte.3;. Older applications do not recognize these encodings and mistake them for control characters. Newer applications usually recognize 8-bit characters. Depending on the implementation, users may be required to compile an application with wide or multibyte character support, or configure it correctly. To provide application support for wide or multibyte characters, the &os; Ports - Collection contains programs for several languages. + Collection contains programs for several languages. Refer to the i18n documentation in the respective &os; port. Specifically, the user needs to look at the application documentation to decide how to configure it correctly or to determine which compile options to use when building the port. Some things to keep in mind are: Language specific single C chars character sets such as ISO8859-1, ISO8859-15, KOI8-R, and CP437. These are described in &man.multibyte.3;. Wide or multibyte encodings such as EUC and Big5. The active list of character sets can be found at the IANA Registry. &os; uses Xorg-compatible locale encodings instead. In the &os; Ports Collection, i18n applications include i18n in their names for easy identification. However, they do not always support the language needed. Setting Locale Usually it is sufficient to export the value of the locale name as LANG in the login shell. This could be done in the user's ~/.login_conf or in the startup file of the user's shell: (~/.profile, ~/.bashrc, or ~/.cshrc). There is no need to set the locale subsets such as LC_CTYPE or LC_CTIME. Refer to language-specific &os; documentation for more information. Each user should set the following two environment variables in their configuration files: LANG for &posix; POSIX &man.setlocale.3; family functions MIME MM_CHARSET for applications' MIME character set These should be set in the user's shell configuration, the specific application configuration, and the Xorg configuration. Setting Locale Methods locale login class This section describes the two methods for setting locale. The first is recommended and assigns the - environment variables in the login class. The second + environment variables in the + login class. The second method adds the environment variable assignments to the - system's shell startup - file. + system's shell + startup file. Login Classes Method This method allows environment variables needed for locale name and MIME character sets to be assigned once for every possible shell instead of adding specific shell - assignments to each shell's startup file. User Level Setup can be - performed by each user while Administrator Level Setup + assignments to each shell's startup file. + User Level Setup can be + performed by each user while + Administrator Level Setup requires superuser privileges. User Level Setup This provides a minimal example of a .login_conf located in a user's home directory which has both variables set for the Latin-1 encoding: me:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO8859-1: Traditional Chinese BIG-5 encoding Here is an example of a user's .login_conf that sets the variables for Traditional Chinese in BIG-5 encoding. More variables are set because some applications do not correctly respect locale variables for Chinese, Japanese, and Korean. #Users who do not wish to use monetary units or time formats #of Taiwan can manually change each variable me:\ :lang=zh_TW.Big5:\ :setenv=LC_ALL=zh_TW.Big5:\ :setenv=LC_COLLATE=zh_TW.Big5:\ :setenv=LC_CTYPE=zh_TW.Big5:\ :setenv=LC_MESSAGES=zh_TW.Big5:\ :setenv=LC_MONETARY=zh_TW.Big5:\ :setenv=LC_NUMERIC=zh_TW.Big5:\ :setenv=LC_TIME=zh_TW.Big5:\ :charset=big5:\ :xmodifiers="@im=gcin": #Set gcin as the XIM Input Server See Administrator Level Setup and &man.login.conf.5; for more details. Administrator Level Setup Verify that the user's login class in /etc/login.conf sets the correct language: language_name|Account Type Description:\ :charset=MIME_charset:\ :lang=locale_name:\ :tc=default: The previous Latin-1 example would look like this: german|German Users Accounts:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO8859-1:\ :tc=default: Whenever this file is edited, execute the following command to update the capability database: &prompt.root; cap_mkdb /etc/login.conf Changing Login Classes with &man.vipw.8; vipw When using vipw to add new users, use language to set the language: user:password:1111:11:language:0:0:User Name:/home/user:/bin/sh Changing Login Classes with &man.adduser.8; adduser login class When using adduser to add new users, configure the language as follows: If all new users use the same language, set defaultclass = language in /etc/adduser.conf. Alternatively, input the specified language at this prompt: Enter login class: default []: when creating a new user using &man.adduser.8;. Another alternative is to use the following when creating a user that uses a different language than the one set in /etc/adduser.conf: &prompt.root; adduser -class language Changing Login Classes with &man.pw.8; pw If &man.pw.8; is used to add new users, call it in this form: &prompt.root; pw useradd user_name -L language Shell Startup File Method This method is not recommended because it requires a different setup for each shell. Use the Login Class Method instead. MIME locale To add the locale name and MIME character set, set the two environment variables shown below in the /etc/profile or /etc/csh.login shell startup files. This example sets the German language: In /etc/profile: LANG=de_DE.ISO8859-1; export LANG MM_CHARSET=ISO-8859-1; export MM_CHARSET Or in /etc/csh.login: setenv LANG de_DE.ISO8859-1 setenv MM_CHARSET ISO-8859-1 Alternatively, add the above settings to /usr/share/skel/dot.profile or /usr/share/skel/dot.login. To configure Xorg, add one of the following to ~/.xinitrc, depending upon the shell: LANG=de_DE.ISO8859-1; export LANG setenv LANG de_DE.ISO8859-1 - Console Setup For all single C chars character sets, set the correct console fonts in /etc/rc.conf for the language in question with: font8x16=font_name font8x14=font_name font8x8=font_name The font_name is taken from /usr/share/syscons/fonts, without the .fnt suffix. sysinstall keymap screenmap The keymap and screenmap for the single C chars character set can be set using sysinstall. Once inside sysinstall, choose Configure, then Console. Alternatively, add the following to /etc/rc.conf: scrnmap=screenmap_name keymap=keymap_name keychange="fkey_number sequence" The screenmap_name is taken from /usr/share/syscons/scrnmaps, without the .scm suffix. A screenmap with a corresponding mapped font is usually needed as a workaround for expanding bit 8 to bit 9 on a VGA adapter's font character matrix. This will move letters out of the pseudographics area if the screen font uses a bit 8 column. If moused is enabled in /etc/rc.conf, review the mouse cursor information in the next paragraph. moused By default, the mouse cursor of the &man.syscons.4; driver occupies the 0xd0-0xd3 range in the character set. If the language uses this range, move the cursor's range. To enable this workaround for &os;, add the following line to /etc/rc.conf: mousechar_start=3 The keymap_name in the above example is taken from /usr/share/syscons/keymaps, without the .kbd suffix. When uncertain as to which keymap to use, &man.kbdmap.1; can be used to test keymaps without rebooting. The keychange is usually needed to program function keys to match the selected terminal type because function key sequences cannot be defined in the key map. Be sure to set the correct console terminal type in /etc/ttys for all virtual terminal entries. Current pre-defined correspondences are: Character Set Terminal Type ISO8859-1 or ISO8859-15 cons25l1 ISO8859-2 cons25l2 ISO8859-7 cons25l7 KOI8-R cons25r KOI8-U cons25u CP437 (VGA default) cons25 US-ASCII cons25w For languages with wide or multibyte characters, use the correct &os; port in /usr/ports/language. Some applications appear as serial terminals to the system. Reserve enough terminals in /etc/ttys for both Xorg and the pseudo-serial console. Here is a partial list of applications for using other languages in the console: Language Location Traditional Chinese (BIG-5) chinese/big5con Japanese japanese/kon2-16dot or japanese/mule-freewnn Korean korean/han Xorg Setup Although Xorg is not installed with &os;, it can be installed from the Ports Collection. Refer to for more information on how to do this. This section discusses how to localize Xorg once it is installed. Application specific i18n settings such as fonts and menus can be tuned in ~/.Xresources. Displaying Fonts Xorg True Type font server - After installing x11-servers/xorg-server, install - the language's &truetype; fonts. Setting the correct locale - should allow users to view their selected language in - graphical application menus. + After installing + x11-servers/xorg-server, + install the language's &truetype; fonts. Setting the + correct locale should allow users to view their selected + language in graphical application menus. Inputting Non-English Characters X Input Method (XIM) The X Input Method (XIM) protocol is an input standard for Xorg clients. All Xorg applications should be written as XIM clients that take input from XIM input servers. There are several XIM servers available for different languages. Printer Setup Some single C chars character sets are hardware coded into printers. Wide or multibyte character sets require special setup using a utility such as apsfilter. Documents can be converted to &postscript; or PDF formats using language specific converters. Kernel and File Systems The &os; fast filesystem (FFS) is 8-bit clean, so it can be used with any single C chars character set. However, character set names are not stored in the filesystem as it is raw 8-bit and does not understand encoding order. Officially, FFS does not support any form of wide or multibyte character sets. However, some wide or multibyte character sets have independent patches for enabling support on FFS. Refer to the respective languages' web sites for more information and the patch files. DOS Unicode &os;'s support for the &ms-dos; filesystem has the configurable ability to convert between &ms-dos;, Unicode character sets, and chosen &os; filesystem character sets. Refer to &man.mount.msdosfs.8; for details. Compiling <acronym>i18n</acronym> Programs Many applications in the &os; Ports Collection have been ported with i18n support. Some of these include -i18n in the port name. These and many other programs have built in support for i18n and need no special consideration. MySQL However, some applications such as MySQL need to have their Makefile configured with the specific charset. This is usually done in the port's Makefile or by passing a value to configure in the source. Localizing &os; to Specific Languages Andrey Chernov Originally contributed by Russian Language (KOI8-R Encoding) localization Russian For more information about KOI8-R encoding, refer to KOI8-R References (Russian Net Character Set). Locale Setup To set this locale, put the following lines into each user's ~/.login_conf: me:My Account:\ :charset=KOI8-R:\ :lang=ru_RU.KOI8-R: - Console Setup Add the following lines to /etc/rc.conf: keymap="ru.koi8-r" scrnmap="koi8-r2cp866" font8x16="cp866b-8x16" font8x14="cp866-8x14" font8x8="cp866-8x8" mousechar_start=3 - For each ttyv entry in /etc/ttys, use cons25r as the terminal type. Printer Setup printers Since most printers with Russian characters come with hardware code page CP866, a special output filter is needed to convert from KOI8-R to CP866. &os; installs a default filter as /usr/libexec/lpr/ru/koi2alt. A Russian printer /etc/printcap entry should look like: lp|Russian local line printer:\ :sh:of=/usr/libexec/lpr/ru/koi2alt:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: Refer to &man.printcap.5; for a more detailed description. &ms-dos; and Russian Filenames The following example &man.fstab.5; entry enables support for Russian filenames in mounted &ms-dos; filesystems: /dev/ad0s2 /dos/c msdos rw,-Lru_RU.KOI8-R 0 0 selects the locale name. Refer to &man.mount.msdosfs.8; for more details. <application>Xorg</application> Setup - First, configure the non-X locale + First, configure the + non-X locale setup. When using &xorg;, install the x11-fonts/xorg-fonts-cyrillic package. Check the "Files" section in /etc/X11/xorg.conf. The following line must be added before any other FontPath entries: FontPath "/usr/local/lib/X11/fonts/cyrillic" Search the Ports Collection for more Cyrillic fonts. To activate a Russian keyboard, add the following to the "Keyboard" section of /etc/xorg.conf: Option "XkbLayout" "us,ru" Option "XkbOptions" "grp:toggle" Make sure that XkbDisable is commented out in that file. - For grp:toggle use Right - Alt, for + For grp:toggle use + Right Alt, for grp:ctrl_shift_toggle use CtrlShift. For grp:caps_toggle use CapsLock. The old CapsLock function is still available in LAT mode only using ShiftCapsLock. grp:caps_toggle does not work in &xorg; for some unknown reason. If the keyboard has &windows; keys, and some non-alphabetical keys are mapped incorrectly, add the following line to /etc/xorg.conf: - Option "XkbVariant" ",winkeys" + Option "XkbVariant" ",winkeys" The Russian XKB keyboard may not work with non-localized applications. + Minimally localized applications should call a XtSetLanguageProc (NULL, NULL, NULL); function early in the program. See KOI8-R for X Window for more instructions on localizing Xorg applications. Traditional Chinese Localization for Taiwan localization Traditional Chinese The &os;-Taiwan Project has a Chinese HOWTO for &os; at using many Chinese ports. The current editor for the &os; Chinese HOWTO is Shen Chuan-Hsing statue@freebsd.sinica.edu.tw. German Language Localization for All ISO 8859-1 Languages localization German Slaven Rezic eserte@cs.tu-berlin.de wrote a tutorial on using umlauts on &os;. The tutorial is written in German and is available at . Greek Language Localization localization Greek Nikos Kokkalis nickkokkalis@gmail.com has written a complete article on Greek support in &os;. It is available here, in Greek only, as part of - the official &os; Greek documentation. + url="&url.doc.base;/el_GR.ISO8859-7/articles/greek-language-support/index.html">here, + in Greek only, as part of the official &os; Greek + documentation. Japanese and Korean Language Localization localization Japanese localization Korean For Japanese, refer to , and for Korean, refer to . Non-English &os; Documentation Some &os; contributors have translated parts of the &os; documentation to other languages. They are available - through links on the main site or in + through links on the + main site or in /usr/share/doc. diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml index 9f10c154fd..693b0e797d 100644 --- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml @@ -1,2681 +1,2682 @@ Obtaining &os; CDROM and DVD Publishers CD and DVD Sets &os; CD and DVD sets are available from many online retailers:
&os; Mall, Inc. 2420 Sand Creek Rd C-1 #347 Brentwood, CA 94513 USA Phone: +1 925 240-6652 Fax: +1 925 674-0821 Email: info@freebsdmall.com WWW:
Dr. Hinner EDV Kochelseestr. 11 D-81371 München Germany Phone: (0177) 428 419 0 WWW:
Linux Distro UK 42 Wharfedale Road Margate CT9 2TB United Kingdom WWW:
The Linux Emporium The Techno Centre, Puma Way Parkside CV1 2TT United Kingdom Phone: +44 (0)247 615 8121 Fax: +44 1491 837016 WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Russia Phone: +7-812-3125208 Email: info@linuxcenter.ru WWW:
FTP Sites The official sources for &os; are available via anonymous FTP from a worldwide set of mirror sites. The site is well connected and allows a large number of connections to it, but you are probably better off finding a closer mirror site (especially if you decide to set up some sort of mirror site). Additionally, &os; is available via anonymous FTP from the following mirror sites. If you choose to obtain &os; via anonymous FTP, please try to use a site near you. The mirror sites listed as Primary Mirror Sites typically have the entire &os; archive (all the currently available versions for each of the architectures) but you will probably have faster download times from a site that is in your country or region. The regional sites carry the most recent versions for the most popular architecture(s) but might not carry the entire &os; archive. All sites provide access via anonymous FTP but some sites also provide access via other methods. The access methods available for each site are provided in parentheses after the hostname. &chap.mirrors.ftp.index.inc; &chap.mirrors.lastmod.inc; &chap.mirrors.ftp.inc; Anonymous CVS (Deprecated) Warning CVS has been deprecated by the project, and its use is not recommended. Subversion should be used instead. Using CTM CTM CTM is a method for keeping a remote directory tree in sync with a central one. It has been developed for usage with &os;'s source trees, though other people may find it useful for other purposes as time goes by. Little, if any, documentation currently exists at this time on the process of creating deltas, so contact the &a.ctm-users.name; mailing list for more information and if you wish to use CTM for other things. Why Should I Use <application>CTM</application>? CTM will give you a local copy of the &os; source trees. There are a number of flavors of the tree available. Whether you wish to track the entire CVS tree or just one of the branches, CTM can provide you the information. If you are an active developer on &os;, but have lousy or non-existent TCP/IP connectivity, or simply wish to have the changes automatically sent to you, CTM was made for you. You will need to obtain up to three deltas per day for the most active branches. However, you should consider having them sent by automatic email. The sizes of the updates are always kept as small as possible. This is typically less than 5K, with an occasional (one in ten) being 10-50K and every now and then a large 100K+ or more coming around. You will also need to make yourself aware of the various caveats related to working directly from the development sources rather than a pre-packaged release. This is particularly true if you choose the current sources. It is recommended that you read Staying current with &os;. What Do I Need to Use <application>CTM</application>? You will need two things: The CTM program, and the initial deltas to feed it (to get up to current levels). The CTM program has been part of &os; ever since version 2.0 was released, and lives in /usr/src/usr.sbin/ctm if you have a copy of the source available. The deltas you feed CTM can be had two ways, FTP or email. If you have general FTP access to the Internet then the following FTP sites support access to CTM: or see section mirrors. FTP the relevant directory and fetch the README file, starting from there. If you wish to get your deltas via email: Subscribe to one of the CTM distribution lists. &a.ctm-src-cur.name; supports the entire Subversion tree. &a.ctm-src-cur.name; supports the head of the development branch. &a.ctm-src-9.name; supports the 9.X release branch, etc.. (If you do not know how to subscribe yourself to a list, click on the list name above or go to &a.mailman.lists.link; and click on the list that you wish to subscribe to. The list page should contain all of the necessary subscription instructions.) When you begin receiving your CTM updates in the mail, you may use the ctm_rmail program to unpack and apply them. You can actually use the ctm_rmail program directly from a entry in /etc/aliases if you want to have the process run in a fully automated fashion. Check the ctm_rmail manual page for more details. No matter what method you use to get the CTM deltas, you should subscribe to the &a.ctm-announce.name; mailing list. In the future, this will be the only place where announcements concerning the operations of the CTM system will be posted. Click on the list name above and follow the instructions to subscribe to the list. Using <application>CTM</application> for the First Time Before you can start using CTM deltas, you will need to get to a starting point for the deltas produced subsequently to it. First you should determine what you already have. Everyone can start from an empty directory. You must use an initial Empty delta to start off your CTM supported tree. At some point it is intended that one of these started deltas be distributed on the CD for your convenience, however, this does not currently happen. Since the trees are many tens of megabytes, you should prefer to start from something already at hand. If you have a -RELEASE CD, you can copy or extract an initial source from it. This will save a significant transfer of data. You can recognize these starter deltas by the X appended to the number (src-cur.3210XEmpty.gz for instance). The designation following the X corresponds to the origin of your initial seed. Empty is an empty directory. As a rule a base transition from Empty is produced every 100 deltas. By the way, they are large! 70 to 80 Megabytes of gzip'd data is common for the XEmpty deltas. Once you have picked a base delta to start from, you will also need all deltas with higher numbers following it. Using <application>CTM</application> in Your Daily Life To apply the deltas, simply say: &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* CTM understands deltas which have been put through gzip, so you do not need to gunzip them first, this saves disk space. Unless it feels very secure about the entire process, CTM will not touch your tree. To verify a delta you can also use the flag and CTM will not actually touch your tree; it will merely verify the integrity of the delta and see if it would apply cleanly to your current tree. There are other options to CTM as well, see the manual pages or look in the sources for more information. That is really all there is to it. Every time you get a new delta, just run it through CTM to keep your sources up to date. Do not remove the deltas if they are hard to download again. You just might want to keep them around in case something bad happens. Even if you only have floppy disks, consider using fdwrite to make a copy. Keeping Your Local Changes As a developer one would like to experiment with and change files in the source tree. CTM supports local modifications in a limited way: before checking for the presence of a file foo, it first looks for foo.ctm. If this file exists, CTM will operate on it instead of foo. This behavior gives us a simple way to maintain local changes: simply copy the files you plan to modify to the corresponding file names with a .ctm suffix. Then you can freely hack the code, while CTM keeps the .ctm file up-to-date. Other Interesting <application>CTM</application> Options Finding Out Exactly What Would Be Touched by an Update You can determine the list of changes that CTM will make on your source repository using the option to CTM. This is useful if you would like to keep logs of the changes, pre- or post- process the modified files in any manner, or just are feeling a tad paranoid. Making Backups Before Updating Sometimes you may want to backup all the files that would be changed by a CTM update. Specifying the option causes CTM to backup all files that would be touched by a given CTM delta to backup-file. Restricting the Files Touched by an Update Sometimes you would be interested in restricting the scope of a given CTM update, or may be interested in extracting just a few files from a sequence of deltas. You can control the list of files that CTM would operate on by specifying filtering regular expressions using the and options. For example, to extract an up-to-date copy of lib/libc/Makefile from your collection of saved CTM deltas, run the commands: &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* For every file specified in a CTM delta, the and options are applied in the order given on the command line. The file is processed by CTM only if it is marked as eligible after all the and options are applied to it. Future Plans for <application>CTM</application> Tons of them: Use some kind of authentication into the CTM system, so as to allow detection of spoofed CTM updates. Clean up the options to CTM, they became confusing and counter intuitive. Miscellaneous Stuff There is a sequence of deltas for the ports collection too, but interest has not been all that high yet. CTM Mirrors CTM/&os; is available via anonymous FTP from the following mirror sites. If you choose to obtain CTM via anonymous FTP, please try to use a site near you. In case of problems, please contact the &a.ctm-users.name; mailing list. California, Bay Area, official source South Africa, backup server for old deltas Taiwan/R.O.C. If you did not find a mirror near to you or the mirror is incomplete, try to use a search engine such as alltheweb. Using <application>Subversion</application> Subversion Introduction As of July 2012, &os; uses Subversion (svn) as the primary version control system for storing all of &os;'s source code, documentation, and the Ports Collection. Subversion is generally a developer tool. Most users should use FreeBSD Update to update the &os; base system, and Portsnap to update the &os; Ports Collection. In Subversion, URLs are used to designate a repository, taking the form of protocol://hostname/path. Mirrors may support different protocols as specified below. The first component of the path is the &os; repository to access. There are three different repositories, base for the &os; base system source code, ports for the Ports Collection, and doc for documentation. For example, the URL svn://svn0.us-east.FreeBSD.org/ports/head/ specifies the main branch of the ports repository on the svn0.us-east.FreeBSD.org mirror, using the svn protocol. Installation Subversion must be installed before it can be used to check out the contents of any of the repositories. If a copy of the ports tree is already present, one can install Subversion like this: &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make install clean If the ports tree is not available, Subversion can be installed as a package: &prompt.root; pkg_add -r subversion If pkgng is being used to manage packages, Subversion can be installed with it instead: &prompt.root; pkg install devel/subversion Running <application>Subversion</application> The svn command is used to fetch a clean copy of the sources into a local directory. The files in this directory are called a local working copy. If the local directory already exists but was not created by svn, rename or delete it before the checkout. Checkout over an existing non-svn directory can cause conflicts between the existing files and those brought in from the repository. A checkout from a given repository is performed with a command like this: &prompt.root; svn checkout svn-mirror/repository/branch lwcdir where: svn-mirror is a URL for one of the Subversion mirror sites. repository is one of the Project repositories, i.e., base, ports, or doc. branch depends on the repository used. ports and doc are mostly updated in the head branch, while base maintains the latest version of -CURRENT under head and the respective latest versions of the -STABLE branches under stable/8 (for 8.x) and stable/9 (9.x). lwcdir is the target directory where the contents of the specified branch should be placed. This is usually /usr/ports for ports, /usr/src for base, and /usr/doc for doc. This example checks out the Ports Collection from the western US repository using the HTTPS protocol, placing the local working copy in /usr/ports. If /usr/ports is already present but was not created by svn, remember to rename or delete it before the checkout. &prompt.root; svn checkout https://svn0.us-west.FreeBSD.org/ports/head /usr/ports Because the initial checkout has to download the full branch of the remote repository, it can take a while. Please be patient. After the initial checkout, the local working copy can be updated by running: &prompt.root; svn update lwcdir To update /usr/ports created in the example above, use: &prompt.root; svn update /usr/ports The update is much quicker than a checkout, only transferring files that have changed. An alternate way of updating the local working copy after checkout is provided by the Makefile in the /usr/ports, /usr/src, and /usr/doc directories. Set SVN_UPDATE and use the update target. For example, to update /usr/src: &prompt.root; cd /usr/src &prompt.root; make update SVN_UPDATE=yes For More Information For other information about using Subversion, please see the Subversion Book, titled Version Control with Subversion, or the Subversion Documentation. <application>Subversion</application> Mirror Sites Subversion Repository Mirror Sites All mirrors carry all repositories. The master &os; Subversion server, svn.FreeBSD.org, is publicly accessible, read-only. That may change in the future, so users are encouraged to use one of the official mirrors. To view the &os; Subversion repositories through a browser, use http://svnweb.FreeBSD.org/. The &os; svn mirror network is still in its early days, and will likely change. Do not count on this list of mirrors being static. In particular, the SSL certificates of the servers will likely change at some point. Name Protocols Location SSL fingerprint svn0.us-west.FreeBSD.org svn, http, https USA, California SHA1 - 79:35:8F:CA:6D:34:D9:30:44:D1:00:AF:33:4D:E6:11:44:4D:15:EC + 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 svn0.us-east.FreeBSD.org svn, http, https, rsync USA, New Jersey SHA1 - 06:D1:23:DE:5E:7A:F7:2B:7A:7E:74:95:5F:54:8D:5C:B0:D6:2E:8F + 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 svn0.eu.FreeBSD.org svn, http, https, rsync Europe, UK SHA1 39:B0:53:35:CE:60:C7:BB:00:54:96:96:71:10:94:BB:CE:1C:07:A7 HTTPS is the preferred protocol, providing protection against another computer pretending to be the &os; mirror (commonly known as a man in the middle attack) or otherwise trying to send bad content to the end user. On the first connection to an HTTPS mirror, the user will be asked to verify the server fingerprint: Error validating server certificate for 'https://svn0.us-west.freebsd.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! + - The certificate hostname does not match. Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - - Valid: from Fri, 24 Aug 2012 22:04:04 GMT until Sat, 24 Aug 2013 22:04:04 GMT - - Issuer: clusteradm, FreeBSD.org, CA, US - - Fingerprint: 79:35:8f:ca:6d:34:d9:30:44:d1:00:af:33:4d:e6:11:44:4d:15:ec + - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT + - Issuer: clusteradm, FreeBSD.org, (null), CA, US (clusteradm@FreeBSD.org) + - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 (R)eject, accept (t)emporarily or accept (p)ermanently? Compare the fingerprint shown to those listed in the table above. If the fingerprint matches, the server security certificate can be accepted temporarily or permanently. A temporary certificate will expire after a single session with the server, and the verification step will be repeated on the next connection. Accepting the certificate permanently will store the authentication credentials in ~/.subversion/auth/ and the user will not be asked to verify the fingerprint again until the certificate expires. If HTTPS cannot be used due to firewall or other problems, SVN is the next choice, with slightly faster transfers. When neither can be used, use HTTP. Using CVSup (Deprecated) Introduction cvsup has been deprecated by the project, and its use is not recommended. Subversion should be used instead. CVSup is a software package for distributing and updating source trees from a master CVS repository on a remote server host. The &os; sources are maintained in a CVS repository on a central development machine in California. With CVSup, &os; users can easily keep their own source trees up to date. CVSup uses the so-called pull model of updating. Under the pull model, each client asks the server for updates, if and when they are wanted. The server waits passively for update requests from its clients. Thus all updates are instigated by the client. The server never sends unsolicited updates. Users must either run the CVSup client manually to get an update, or they must set up a cron job to run it automatically on a regular basis. The term CVSup, capitalized just so, refers to the entire software package. Its main components are the client cvsup which runs on each user's machine, and the server cvsupd which runs at each of the &os; mirror sites. The csup utility is a rewrite of the CVSup software in C. Its biggest advantage is, that it is faster and does not depend on the Modula-3 language, thus you do not need to install it as a requirement. Moreover you can use it out-of-the-box, since it is included in the base system. If you decided to use csup, just skip the steps on the installation of CVSup and substitute the references of CVSup with csup while following the remainder of this article. Installation The easiest way to install CVSup is to use the precompiled net/cvsup package from the &os; packages collection. If you prefer to build CVSup from source, you can use the net/cvsup port instead. But be forewarned: the net/cvsup port depends on the Modula-3 system, which takes a substantial amount of time and disk space to download and build. If you are going to be using CVSup on a machine which will not have &xorg; installed, such as a server, be sure to use the port which does not include the CVSup GUI, net/cvsup-without-gui. CVSup Configuration CVSup's operation is controlled by a configuration file called the supfile. There are some sample supfiles in the directory /usr/share/examples/cvsup/. The information in a supfile answers the following questions for CVSup: Which files do you want to receive? Which versions of them do you want? Where do you want to get them from? Where do you want to put them on your own machine? Where do you want to put your status files? In the following sections, we will construct a typical supfile by answering each of these questions in turn. First, we describe the overall structure of a supfile. A supfile is a text file. Comments begin with # and extend to the end of the line. Lines that are blank and lines that contain only comments are ignored. Each remaining line describes a set of files that the user wishes to receive. The line begins with the name of a collection, a logical grouping of files defined by the server. The name of the collection tells the server which files you want. After the collection name come zero or more fields, separated by white space. These fields answer the questions listed above. There are two types of fields: flag fields and value fields. A flag field consists of a keyword standing alone, e.g., delete or compress. A value field also begins with a keyword, but the keyword is followed without intervening white space by = and a second word. For example, release=cvs is a value field. A supfile typically specifies more than one collection to receive. One way to structure a supfile is to specify all of the relevant fields explicitly for each collection. However, that tends to make the supfile lines quite long, and it is inconvenient because most fields are the same for all of the collections in a supfile. CVSup provides a defaulting mechanism to avoid these problems. Lines beginning with the special pseudo-collection name *default can be used to set flags and values which will be used as defaults for the subsequent collections in the supfile. A default value can be overridden for an individual collection, by specifying a different value with the collection itself. Defaults can also be changed or augmented in mid-supfile by additional *default lines. With this background, we will now proceed to construct a supfile for receiving and updating the main source tree of &os;-CURRENT. Which files do you want to receive? The files available via CVSup are organized into named groups called collections. The collections that are available are described in the following section. In this example, we wish to receive the entire main source tree for the &os; system. There is a single large collection src-all which will give us all of that. As a first step toward constructing our supfile, we simply list the collections, one per line (in this case, only one line): src-all Which version(s) of them do you want? With CVSup, you can receive virtually any version of the sources that ever existed. That is possible because the cvsupd server works directly from the CVS repository, which contains all of the versions. You specify which one of them you want using the tag= and value fields. Be very careful to specify any tag= fields correctly. Some tags are valid only for certain collections of files. If you specify an incorrect or misspelled tag, CVSup will delete files which you probably do not want deleted. In particular, use only tag=. for the ports-* collections. The tag= field names a symbolic tag in the repository. There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today. contains branch tags that users might be interested in. When specifying a tag in CVSup's configuration file, it must be preceded with tag= (RELENG_8 will become tag=RELENG_8). Keep in mind that only the tag=. is relevant for the Ports Collection. Be very careful to type the tag name exactly as shown. CVSup cannot distinguish between valid and invalid tags. If you misspell the tag, CVSup will behave as though you had specified a valid tag which happens to refer to no files at all. It will delete your existing sources in that case. When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the value field. The &man.cvsup.1; manual page explains how to do that. For our example, we wish to receive &os;-CURRENT. We add this line at the beginning of our supfile: *default tag=. There is an important special case that comes into play if you specify neither a tag= field nor a date= field. In that case, you receive the actual RCS files directly from the server's CVS repository, rather than receiving a particular version. Developers generally prefer this mode of operation. By maintaining a copy of the repository itself on their systems, they gain the ability to browse the revision histories and examine past versions of files. This gain is achieved at a large cost in terms of disk space, however. Where do you want to get them from? We use the host= field to tell cvsup where to obtain its updates. Any of the CVSup mirror sites will do, though you should try to select one that is close to you in cyberspace. In this example we will use a fictional &os; distribution site, cvsup99.FreeBSD.org: *default host=cvsup99.FreeBSD.org You will need to change the host to one that actually exists before running CVSup. On any particular run of cvsup, you can override the host setting on the command line, with . Where do you want to put them on your own machine? The prefix= field tells cvsup where to put the files it receives. In this example, we will put the source files directly into our main source tree, /usr/src. The src directory is already implicit in the collections we have chosen to receive, so this is the correct specification: *default prefix=/usr Where should cvsup maintain its status files? The CVSup client maintains certain status files in what is called the base directory. These files help CVSup to work more efficiently, by keeping track of which updates you have already received. We will use the standard base directory, /var/db: *default base=/var/db If your base directory does not already exist, now would be a good time to create it. The cvsup client will refuse to run if the base directory does not exist. Miscellaneous supfile settings: There is one more line of boiler plate that normally needs to be present in the supfile: *default release=cvs delete use-rel-suffix compress release=cvs indicates that the server should get its information out of the main &os; CVS repository. This is virtually always the case, but there are other possibilities which are beyond the scope of this discussion. delete gives CVSup permission to delete files. You should always specify this, so that CVSup can keep your source tree fully up-to-date. CVSup is careful to delete only those files for which it is responsible. Any extra files you happen to have will be left strictly alone. use-rel-suffix is ... arcane. If you really want to know about it, see the &man.cvsup.1; manual page. Otherwise, just specify it and do not worry about it. compress enables the use of gzip-style compression on the communication channel. If your network link is T1 speed or faster, you probably should not use compression. Otherwise, it helps substantially. Putting it all together: Here is the entire supfile for our example: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all The <filename>refuse</filename> File As mentioned above, CVSup uses a pull method. Basically, this means that you connect to the CVSup server, and it says, Here is what you can download from me..., and your client responds OK, I will take this, this, this, and this. In the default configuration, the CVSup client will take every file associated with the collection and tag you chose in the configuration file. In order to download a partial tree, use the refuse file. The refuse file tells CVSup that it should not take every single file from a collection; in other words, it tells the client to refuse certain files from the server. The refuse file can be found (or, if you do not yet have one, should be placed) in base/sup/. base is defined in your supfile; our defined base is /var/db, which means that by default the refuse file is /var/db/sup/refuse. The refuse file has a very simple format; it simply contains the names of files or directories that you do not wish to download. For example: bin/ usr.bin/ Users who are on slow links or pay by the minute for their Internet connection will be able to save time as they will no longer need to download files that they will never use. For more information on refuse files and other neat features of CVSup, please view its manual page. Running <application>CVSup</application> You are now ready to try an update. The command line for doing this is quite simple: &prompt.root; cvsup supfile where supfile is of course the name of the supfile you have just created. Assuming you are running under X11, cvsup will display a GUI window with some buttons to do the usual things. Press the go button, and watch it run. Since you are updating your actual /usr/src tree in this example, you will need to run the program as root so that cvsup has the permissions it needs to update your files. Having just created your configuration file, and having never used this program before, that might understandably make you nervous. There is an easy way to do a trial run without touching your precious files. Just create an empty directory somewhere convenient, and name it as an extra argument on the command line: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest The directory you specify will be used as the destination directory for all file updates. CVSup will examine your usual files in /usr/src, but it will not modify or delete any of them. Any file updates will instead land in /var/tmp/dest/usr/src. CVSup will also leave its base directory status files untouched when run this way. The new versions of those files will be written into the specified directory. As long as you have read access to /usr/src, you do not even need to be root to perform this kind of trial run. If you are not running X11 or if you just do not like GUIs, you should add a couple of options to the command line when you run cvsup: &prompt.root; cvsup -g -L 2 supfile The tells CVSup not to use its GUI. This is automatic if you are not running X11, but otherwise you have to specify it. The tells CVSup to print out the details of all the file updates it is doing. There are three levels of verbosity, from to . The default is 0, which means total silence except for error messages. There are plenty of other options available. For a brief list of them, type cvsup -H. For more detailed descriptions, see the manual page. Once you are satisfied with the way updates are working, you can arrange for regular runs of CVSup using &man.cron.8;. Obviously, you should not let CVSup use its GUI when running it from &man.cron.8;. <application>CVSup</application> File Collections The file collections available via CVSup are organized hierarchically. There are a few large collections, and they are divided into smaller sub-collections. Receiving a large collection is equivalent to receiving each of its sub-collections. The hierarchical relationships among collections are reflected by the use of indentation in the list below. The most commonly used collection is src-all. cvs-all release=cvs The main &os; CVS repository, including the cryptography code. distrib release=cvs Files related to the distribution and mirroring of &os;. projects-all release=cvs Sources for the &os; projects repository. src-all release=cvs The main &os; sources, including the cryptography code. src-base release=cvs Miscellaneous files at the top of /usr/src. src-bin release=cvs User utilities that may be needed in single-user mode (/usr/src/bin). src-cddl release=cvs Utilities and libraries covered by the CDDL license (/usr/src/cddl). src-contrib release=cvs Utilities and libraries from outside the &os; project, used relatively unmodified (/usr/src/contrib). src-crypto release=cvs Cryptography utilities and libraries from outside the &os; project, used relatively unmodified (/usr/src/crypto). src-eBones release=cvs Kerberos and DES (/usr/src/eBones). Not used in current releases of &os;. src-etc release=cvs System configuration files (/usr/src/etc). src-games release=cvs Games (/usr/src/games). src-gnu release=cvs Utilities covered by the GNU Public License (/usr/src/gnu). src-include release=cvs Header files (/usr/src/include). src-kerberos5 release=cvs Kerberos5 security package (/usr/src/kerberos5). src-kerberosIV release=cvs KerberosIV security package (/usr/src/kerberosIV). src-lib release=cvs Libraries (/usr/src/lib). src-libexec release=cvs System programs normally executed by other programs (/usr/src/libexec). src-release release=cvs Files required to produce a &os; release (/usr/src/release). src-rescue release=cvs Statically linked programs for emergency recovery; see &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs System utilities for single-user mode (/usr/src/sbin). src-secure release=cvs Cryptographic libraries and commands (/usr/src/secure). src-share release=cvs Files that can be shared across multiple systems (/usr/src/share). src-sys release=cvs The kernel (/usr/src/sys). src-sys-crypto release=cvs Kernel cryptography code (/usr/src/sys/crypto). src-tools release=cvs Various tools for the maintenance of &os; (/usr/src/tools). src-usrbin release=cvs User utilities (/usr/src/usr.bin). src-usrsbin release=cvs System utilities (/usr/src/usr.sbin). distrib release=self The CVSup server's own configuration files. Used by CVSup mirror sites. gnats release=current The GNATS bug-tracking database. mail-archive release=current &os; mailing list archive. For More Information For the CVSup FAQ and other information about CVSup, see The CVSup Home Page. Most &os;-related discussion of CVSup takes place on the &a.hackers;. New versions of the software are announced there, as well as on the &a.announce;. For questions or bug reports about CVSup take a look at the CVSup FAQ. CVSup Sites CVSup servers for &os; are running at the following sites: &chap.mirrors.cvsup.index.inc; &chap.mirrors.lastmod.inc; &chap.mirrors.cvsup.inc; CVS Tags CVS has been deprecated by the project, and its use is not recommended. Subversion should be used instead. When obtaining or updating sources using cvs or CVSup, a revision tag must be specified. A revision tag refers to either a particular line of &os; development, or a specific point in time. The first type are called branch tags, and the second type are called release tags. Branch Tags All of these, with the exception of HEAD (which is always a valid tag), only apply to the src/ tree. The ports/, doc/, and www/ trees are not branched. HEAD Symbolic name for the main line, or &os;-CURRENT. Also the default when no revision is specified. In CVSup, this tag is represented by a . (not punctuation, but a literal . character). In CVS, this is the default when no revision tag is specified. It is usually not a good idea to checkout or update to CURRENT sources on a STABLE machine, unless that is your intent. RELENG_9 The line of development for &os;-9.X, also known as &os; 9-STABLE RELENG_9_1 The release branch for &os;-9.1, used only for security advisories and other critical fixes. RELENG_9_0 The release branch for &os;-9.0, used only for security advisories and other critical fixes. RELENG_8 The line of development for &os;-8.X, also known as &os; 8-STABLE RELENG_8_3 The release branch for &os;-8.3, used only for security advisories and other critical fixes. RELENG_8_2 The release branch for &os;-8.2, used only for security advisories and other critical fixes. RELENG_8_1 The release branch for &os;-8.1, used only for security advisories and other critical fixes. RELENG_8_0 The release branch for &os;-8.0, used only for security advisories and other critical fixes. RELENG_7 The line of development for &os;-7.X, also known as &os; 7-STABLE RELENG_7_4 The release branch for &os;-7.4, used only for security advisories and other critical fixes. RELENG_7_3 The release branch for &os;-7.3, used only for security advisories and other critical fixes. RELENG_7_2 The release branch for &os;-7.2, used only for security advisories and other critical fixes. RELENG_7_1 The release branch for &os;-7.1, used only for security advisories and other critical fixes. RELENG_7_0 The release branch for &os;-7.0, used only for security advisories and other critical fixes. RELENG_6 The line of development for &os;-6.X, also known as &os; 6-STABLE RELENG_6_4 The release branch for &os;-6.4, used only for security advisories and other critical fixes. RELENG_6_3 The release branch for &os;-6.3, used only for security advisories and other critical fixes. RELENG_6_2 The release branch for &os;-6.2, used only for security advisories and other critical fixes. RELENG_6_1 The release branch for &os;-6.1, used only for security advisories and other critical fixes. RELENG_6_0 The release branch for &os;-6.0, used only for security advisories and other critical fixes. RELENG_5 The line of development for &os;-5.X, also known as &os; 5-STABLE. RELENG_5_5 The release branch for &os;-5.5, used only for security advisories and other critical fixes. RELENG_5_4 The release branch for &os;-5.4, used only for security advisories and other critical fixes. RELENG_5_3 The release branch for &os;-5.3, used only for security advisories and other critical fixes. RELENG_5_2 The release branch for &os;-5.2 and &os;-5.2.1, used only for security advisories and other critical fixes. RELENG_5_1 The release branch for &os;-5.1, used only for security advisories and other critical fixes. RELENG_5_0 The release branch for &os;-5.0, used only for security advisories and other critical fixes. RELENG_4 The line of development for &os;-4.X, also known as &os; 4-STABLE. RELENG_4_11 The release branch for &os;-4.11, used only for security advisories and other critical fixes. RELENG_4_10 The release branch for &os;-4.10, used only for security advisories and other critical fixes. RELENG_4_9 The release branch for &os;-4.9, used only for security advisories and other critical fixes. RELENG_4_8 The release branch for &os;-4.8, used only for security advisories and other critical fixes. RELENG_4_7 The release branch for &os;-4.7, used only for security advisories and other critical fixes. RELENG_4_6 The release branch for &os;-4.6 and &os;-4.6.2, used only for security advisories and other critical fixes. RELENG_4_5 The release branch for &os;-4.5, used only for security advisories and other critical fixes. RELENG_4_4 The release branch for &os;-4.4, used only for security advisories and other critical fixes. RELENG_4_3 The release branch for &os;-4.3, used only for security advisories and other critical fixes. RELENG_3 The line of development for &os;-3.X, also known as 3.X-STABLE. RELENG_2_2 The line of development for &os;-2.2.X, also known as 2.2-STABLE. This branch is mostly obsolete. Release Tags These tags refer to a specific point in time when a particular version of &os; was released. The release engineering process is documented in more detail by the Release Engineering Information and Release Process documents. The src tree uses tag names that start with RELENG_ tags. The ports and doc trees use tags whose names begin with RELEASE tags. Finally, the www tree is not tagged with any special name for releases. RELENG_9_1_0_RELEASE &os; 9.1 RELENG_9_0_0_RELEASE &os; 9.0 RELENG_8_3_0_RELEASE &os; 8.3 RELENG_8_2_0_RELEASE &os; 8.2 RELENG_8_1_0_RELEASE &os; 8.1 RELENG_8_0_0_RELEASE &os; 8.0 RELENG_7_4_0_RELEASE &os; 7.4 RELENG_7_3_0_RELEASE &os; 7.3 RELENG_7_2_0_RELEASE &os; 7.2 RELENG_7_1_0_RELEASE &os; 7.1 RELENG_7_0_0_RELEASE &os; 7.0 RELENG_6_4_0_RELEASE &os; 6.4 RELENG_6_3_0_RELEASE &os; 6.3 RELENG_6_2_0_RELEASE &os; 6.2 RELENG_6_1_0_RELEASE &os; 6.1 RELENG_6_0_0_RELEASE &os; 6.0 RELENG_5_5_0_RELEASE &os; 5.5 RELENG_5_4_0_RELEASE &os; 5.4 RELENG_4_11_0_RELEASE &os; 4.11 RELENG_5_3_0_RELEASE &os; 5.3 RELENG_4_10_0_RELEASE &os; 4.10 RELENG_5_2_1_RELEASE &os; 5.2.1 RELENG_5_2_0_RELEASE &os; 5.2 RELENG_4_9_0_RELEASE &os; 4.9 RELENG_5_1_0_RELEASE &os; 5.1 RELENG_4_8_0_RELEASE &os; 4.8 RELENG_5_0_0_RELEASE &os; 5.0 RELENG_4_7_0_RELEASE &os; 4.7 RELENG_4_6_2_RELEASE &os; 4.6.2 RELENG_4_6_1_RELEASE &os; 4.6.1 RELENG_4_6_0_RELEASE &os; 4.6 RELENG_4_5_0_RELEASE &os; 4.5 RELENG_4_4_0_RELEASE &os; 4.4 RELENG_4_3_0_RELEASE &os; 4.3 RELENG_4_2_0_RELEASE &os; 4.2 RELENG_4_1_1_RELEASE &os; 4.1.1 RELENG_4_1_0_RELEASE &os; 4.1 RELENG_4_0_0_RELEASE &os; 4.0 RELENG_3_5_0_RELEASE &os;-3.5 RELENG_3_4_0_RELEASE &os;-3.4 RELENG_3_3_0_RELEASE &os;-3.3 RELENG_3_2_0_RELEASE &os;-3.2 RELENG_3_1_0_RELEASE &os;-3.1 RELENG_3_0_0_RELEASE &os;-3.0 RELENG_2_2_8_RELEASE &os;-2.2.8 RELENG_2_2_7_RELEASE &os;-2.2.7 RELENG_2_2_6_RELEASE &os;-2.2.6 RELENG_2_2_5_RELEASE &os;-2.2.5 RELENG_2_2_2_RELEASE &os;-2.2.2 RELENG_2_2_1_RELEASE &os;-2.2.1 RELENG_2_2_0_RELEASE &os;-2.2.0 <application>rsync</application> Sites The following sites make &os; available through the rsync protocol. The rsync utility works in much the same way as the &man.rcp.1; command, but has more options and uses the rsync remote-update protocol which transfers only the differences between two sets of files, thus greatly speeding up the synchronization over the network. This is most useful if you are a mirror site for the &os; FTP server, or the CVS repository. The rsync suite is available for many operating systems, on &os;, see the net/rsync port or use the package. Czech Republic rsync://ftp.cz.FreeBSD.org/ Available collections: ftp: A partial mirror of the &os; FTP server. &os;: A full mirror of the &os; FTP server. Netherlands rsync://ftp.nl.FreeBSD.org/ Available collections: &os;: A full mirror of the &os; FTP server. Russia rsync://ftp.mtu.ru/ Available collections: &os;: A full mirror of the &os; FTP server. &os;-gnats: The GNATS bug-tracking database. &os;-Archive: The mirror of &os; Archive FTP server. Sweden rsync://ftp4.se.freebsd.org/ Available collections: &os;: A full mirror of the &os; FTP server. Taiwan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Available collections: &os;: A full mirror of the &os; FTP server. United Kingdom rsync://rsync.mirrorservice.org/ Available collections: ftp.freebsd.org: A full mirror of the &os; FTP server. United States of America rsync://ftp-master.FreeBSD.org/ This server may only be used by &os; primary mirror sites. Available collections: &os;: The master archive of the &os; FTP server. acl: The &os; master ACL list. rsync://ftp13.FreeBSD.org/ Available collections: &os;: A full mirror of the &os; FTP server.
diff --git a/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml b/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml index b938aca64e..0d57931e90 100644 --- a/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml @@ -1,6334 +1,6309 @@ Murray Stokely Reorganized by Network Servers Synopsis - This chapter will cover some of the more frequently used - network services on &unix; systems. We will cover how to - install, configure, test, and maintain many different types of - network services. Example configuration files are included - throughout this chapter for you to benefit from. + This chapter covers some of the more frequently used + network services on &unix; systems. This includes + installing, configuring, testing, and maintaining + many different types of network services. Example + configuration files are included throughout this + chapter for reference. - After reading this chapter, you will know: + By the end of this chapter, readers will know: - How to manage the inetd daemon. - How to set up a network file system. + How to set up the Network File System + (NFS). - How to set up a network information server for sharing + How to set up the Network Information Server + (NIS) for centralizing and sharing user accounts. How to set &os; up to act as an LDAP server or client - - How to set &os; up to act as an LDAP - server or client - - How to set up automatic network settings using - DHCP. + DHCP. - How to set up a domain name server. + How to set up a Domain Name Server + (DNS). How to set up the Apache - HTTP Server. + HTTP Server. - How to set up a File Transfer Protocol (FTP) - Server. + How to set up a File Transfer Protocol + (FTP) server. How to set up a file and print server for &windows; clients using Samba. How to synchronize the time and date, and set up a - time server, with the NTP protocol. + time server using the Network Time Protocol + (NTP). How to configure the standard logging daemon, syslogd, to accept logs from remote hosts. - - Before reading this chapter, you should: + This chapter assumes a basic knowledge of: - Understand the basics of the - /etc/rc scripts. + /etc/rc scripts. - Be familiar with basic network terminology. + Network terminology. - Know how to install additional third-party + Installation of additional third-party software (). - Chern Lee Contributed by Updated by The &os; Documentation Project The <application>inetd</application> <quote>Super-Server</quote> Overview The &man.inetd.8; daemon is sometimes referred to as the Internet Super-Server because it manages connections for many services. When a connection is received by inetd, it determines which program the connection is destined for, spawns the particular process and delegates the socket to it (the program is invoked with the service socket as its standard input, output and error descriptors). Running inetd for servers that are not heavily used can reduce the overall system load, when compared to running each daemon individually in stand-alone mode. Primarily, inetd is used to spawn other daemons, but several trivial protocols are handled directly, such as chargen, auth, and daytime. This section will cover the basics in configuring inetd through its command-line options and its configuration file, /etc/inetd.conf. Settings inetd is initialized through - the &man.rc.8; system. The - inetd_enable option is set to - NO by default, but may be turned on - by sysinstall during installation, - depending on the configuration chosen by the user. - Placing: + the &man.rc.8; system. The inetd_enable + option is set to NO by default. It can be + enabled by placing: inetd_enable="YES" - or - - inetd_enable="NO" - - into - /etc/rc.conf will enable or disable - inetd starting at boot time. + into /etc/rc.conf. + inetd will now start at boot time. The command: &prompt.root; service inetd rcvar can be run to display the current effective setting. Additionally, different command-line options can be passed to inetd via the inetd_flags option. Command-Line Options Like most server daemons, inetd has a number of options that it can be passed in order to modify its behaviour. See the &man.inetd.8; manual page for the full list of options. Options can be passed to inetd using the inetd_flags option in /etc/rc.conf. By default, inetd_flags is set to -wW -C 60, which turns on TCP wrapping for inetd's services, and prevents any single IP address from requesting any service more than 60 times in any given minute. Although we mention rate-limiting options below, novice users may be pleased to note that these parameters usually do not need to be modified. These options may be useful if an excessive amount of connections are being established. A full list of options can be found in the &man.inetd.8; manual. -c maximum Specify the default maximum number of simultaneous invocations of each service; the default is unlimited. May be overridden on a per-service basis with the parameter. -C rate Specify the default maximum number of times a service can be invoked from a single IP address in one minute; the default is unlimited. May be overridden on a per-service basis with the parameter. -R rate Specify the maximum number of times a service can be invoked in one minute; the default is 256. A rate of 0 allows an unlimited number of invocations. -s maximum Specify the maximum number of times a service can be invoked from a single IP address at any one time; the default is unlimited. May be overridden on a per-service basis with the parameter. - + <filename>inetd.conf</filename> Configuration of inetd is done via the file /etc/inetd.conf. When a modification is made to /etc/inetd.conf, inetd can be forced to re-read its configuration file by running the command: Reloading the <application>inetd</application> Configuration File &prompt.root; service inetd reload Each line of the configuration file specifies an individual daemon. Comments in the file are preceded by a #. The format of each entry in /etc/inetd.conf is as follows: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments - An example entry for the &man.ftpd.8; daemon - using IPv4 might read: + An example entry for the &man.ftpd.8; daemon using IPv4 + might read: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name This is the service name of the particular daemon. It must correspond to a service listed in /etc/services. This determines which port inetd must listen to. If a new service is being created, it must be placed in /etc/services first. socket-type Either stream, dgram, raw, or seqpacket. stream must be used for connection-based, TCP daemons, while dgram is used for daemons utilizing the UDP transport protocol. protocol One of the following: Protocol Explanation + tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 Both TCP IPv4 and v6 udp46 Both UDP IPv4 and v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] indicates whether the daemon invoked from inetd is able to handle its own socket or not. socket types must use the option, while stream socket daemons, which are usually multi-threaded, should use . usually hands off multiple sockets to a single daemon, while spawns a child daemon for each new socket. The maximum number of child daemons inetd may spawn can be set using the option. If a limit of ten instances of a particular daemon is needed, a /10 would be placed after . Specifying /0 allows an unlimited number of children In addition to , two other options which limit the maximum connections from a single place to a particular daemon can be enabled. limits the number of connections from any particular IP address per minutes, e.g., a value of ten would limit any particular IP address connecting to a particular service to ten attempts per minute. limits the number of children that can be started on behalf on any single IP address at any moment. These options are useful to prevent intentional or unintentional excessive resource consumption and Denial of Service (DoS) attacks to a machine. In this field, either of or is mandatory. , and are optional. A stream-type multi-threaded daemon without any , or - limits - would simply be: nowait. + limits would simply + be: nowait. The same daemon with a maximum limit of ten daemons would read: nowait/10. - The same setup with a limit of twenty - connections per IP address per minute and a maximum - total limit of ten child daemons would read: + The same setup with a limit of twenty connections + per IP address per minute and a maximum total limit of + ten child daemons would read: nowait/10/20. These options are utilized by the default settings of the &man.fingerd.8; daemon, as seen here: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Finally, an example of this field with a maximum of 100 children in total, with a maximum of 5 for any one IP address would read: nowait/100/0/5. user This is the username that the particular daemon should run as. Most commonly, daemons run as the root user. For security purposes, it is common to find some servers running as the daemon user, or the least privileged nobody user. server-program The full path of the daemon to be executed when a connection is received. If the daemon is a service provided by inetd internally, then should be used. server-program-arguments This works in conjunction with by specifying the arguments, starting with argv[0], passed to the daemon on invocation. If mydaemon -d is the command line, mydaemon -d would be the value of . Again, if the daemon is an internal service, use here. Security Depending on the choices made at install time, many of inetd's services may be enabled by default. If there is no apparent need for a particular daemon, consider disabling it. Place a # in front of the daemon in question in - /etc/inetd.conf, and then reload the - inetd configuration. Some daemons, such as + /etc/inetd.conf, and then + reload the + inetd configuration. Some daemons, such as fingerd, may not be desired at all - because they provide - information that may be useful to an attacker. - - Some daemons are not security-conscious and have long, or - non-existent, timeouts for connection attempts. This allows - an attacker to slowly send connections to a particular daemon, - thus saturating available resources. It may be a good idea to - place , - or - limitations on certain - daemons if there are too many connections. + because they provide information that may be useful to an + attacker. + + Some daemons are not security-conscious and have long or + non-existent timeouts for connection attempts. An attacker + can send connections to a particular daemon, eventually + consuming available resources and resulting in a Denial of + Service (DoS). + max-connections-per-ip-per-minute, + max-child and + max-child-per-ip can be used to limit such + attacks. By default, TCP wrapping is turned on. Consult the &man.hosts.access.5; manual page for more information on placing TCP restrictions on various inetd invoked daemons. Miscellaneous daytime, time, echo, discard, chargen, and auth are all internally provided services of inetd. The auth service provides - identity network services, and is - configurable to a certain degree, whilst the others are simply - on or off. + identity network services, and is configurable to a certain + degree, whilst the others are simply on or off. Consult the &man.inetd.8; manual page for more in-depth information. Tom Rhodes Reorganized and enhanced by Bill Swingle Written by Network File System (NFS) NFS Among the many different file systems that FreeBSD supports is the Network File System, also known as NFS. NFS allows a system to share directories and files with others over a network. By using NFS, users and programs can access files on remote systems almost as if they were local files. Some of the most notable benefits that NFS can provide are: Local workstations use less disk space because commonly used data can be stored on a single machine and still remain accessible to others over the network. There is no need for users to have separate home directories on every network machine. Home directories could be set up on the NFS server and made available throughout the network. Storage devices such as floppy disks, CDROM drives, and &iomegazip; drives can be used by other machines on the network. This may reduce the number of removable media drives throughout the network. How <acronym>NFS</acronym> Works NFS consists of at least two main parts: a server and one or more clients. The client remotely accesses the data that is stored on the server machine. In order for this to function properly a few processes have to be configured and running. The server has to be running the following daemons: NFS server file server UNIX clients rpcbind mountd nfsd Daemon Description + nfsd The NFS daemon which services requests from the NFS clients. mountd The NFS mount daemon which carries out the requests that &man.nfsd.8; passes on to it. rpcbind This daemon allows NFS clients to discover which port the NFS server is using. The client can also run a daemon, known as nfsiod. The nfsiod daemon services the requests from the NFS server. This is optional, and improves performance, but is not required for normal and correct operation. See the &man.nfsiod.8; manual page for more information. Configuring <acronym>NFS</acronym> NFS configuration NFS configuration is a relatively straightforward process. The processes that need to be running can all start at boot time with a few modifications to /etc/rc.conf. On the NFS server, make sure that the following options are configured in the /etc/rc.conf file: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd runs automatically whenever the NFS server is enabled. On the client, make sure this option is present in /etc/rc.conf: nfs_client_enable="YES" The /etc/exports file specifies which file systems NFS should export (sometimes referred to as share). Each line in /etc/exports specifies a file system to be exported and which machines have access to that file system. Along with what machines have access to that file system, access options may also be specified. There are many such options that can be used in this file but only a few will be mentioned here. Other options are discussed in the &man.exports.5; manual page. Here are a few example /etc/exports entries: NFS export examples - The following examples give an idea of how to export - file systems, although the settings may be different depending - on the environment and network configuration. For instance, - to export the /cdrom directory to three + The following examples give an idea of how to export file + systems, although the settings may be different depending on + the environment and network configuration. For instance, to + export the /cdrom directory to three example machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in the /etc/hosts file. The flag makes the exported file system read-only. With this flag, the remote system will not be able to write any changes to the exported file system. /cdrom -ro host1 host2 host3 The following line exports /home to three hosts by IP address. This is a useful setup on a private network without a DNS server configured. Optionally the /etc/hosts file could be configured for internal hostnames; please review &man.hosts.5; for more information. The flag allows the subdirectories to be mount points. In other words, it will not mount the subdirectories but permit the client to mount only the directories that are required or needed. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 The following line exports /a so that two clients from different domains may access the file system. The flag allows the root user on the remote system to write data on the exported file system as root. If the -maproot=root flag is not specified, then even if a user has root access on the remote system, he will not be able to modify files on the exported file system. /a -maproot=root host.example.com box.example.org In order for a client to access an exported file system, the client must have permission to do so. Make sure the client is listed in /etc/exports. In /etc/exports, each line represents the export information for one file system to one host. A remote host can only be specified once per file system, and may only have one default entry. For example, assume that /usr is a single file system. The following /etc/exports would be invalid: # Invalid when /usr is one file system /usr/src client /usr/ports client One file system, /usr, has two lines specifying exports to the same host, client. The correct format for this situation is: /usr/src /usr/ports client The properties of one file system exported to a given host must all occur on one line. Lines without a client specified are treated as a single host. This limits how file systems may be exported; however, for most environments, this is not an issue. The following is an example of a valid export list, where /usr and /exports are local file systems: # Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # The client machines have root and can mount anywhere # on /exports. Anyone in the world can mount /exports/obj read-only /exports -alldirs -maproot=root client01 client02 /exports/obj -ro The mountd daemon must be forced to recheck the /etc/exports file whenever it has been modified, so the changes can take effect. This can be accomplished either by sending a HUP signal to the running daemon: &prompt.root; kill -HUP `cat /var/run/mountd.pid` or by invoking the mountd &man.rc.8; script with the appropriate parameter: &prompt.root; service mountd onereload Please refer to for more information about using rc scripts. - Alternatively, a reboot will make FreeBSD set everything - up properly. A reboot is not necessary though. - Executing the following commands as root - should start everything up. - - On the NFS server: + NFS services can now be started by running the following + command, on the NFS server, as + root: - &prompt.root; rpcbind -&prompt.root; nfsd -u -t -n 4 -&prompt.root; mountd -r + &prompt.root; service nfsd start On the NFS client: - &prompt.root; nfsiod -n 4 + &prompt.root; service nfsclient restart Now everything should be ready to actually mount a remote file system. In these examples the server's name will be server and the client's name will be - client. For testing or to temporarily - mount a remote file system execute a command like this as + client. For testing or to temporarily mount + a remote file system execute a command like this as root on the client: NFS mounting &prompt.root; mount server:/home /mnt This will mount the /home directory on the server at /mnt on the client. If everything is set up correctly, the server's files should be visible and available in the /mnt directory. - To permanently mount a remote file system - each time the computer boots, add the file system to the + To permanently mount a remote file system each time the + computer boots, add the file system to the /etc/fstab file. Here is an example: server:/home /mnt nfs rw 0 0 The &man.fstab.5; manual page lists all the available options. Locking Some applications (e.g., mutt) require file locking to operate correctly. In the case of NFS, rpc.lockd can be used for file locking. To enable it, add the following to the /etc/rc.conf file on both client and server (it is assumed that the NFS client and server are configured already): rpc_lockd_enable="YES" rpc_statd_enable="YES" Start the application by using: &prompt.root; service lockd start &prompt.root; service statd start If real locking between the NFS clients and NFS server is not required, it is possible to let the NFS client do locking locally by passing to &man.mount.nfs.8;. Refer to the &man.mount.nfs.8; manual page for further details. Practical Uses NFS has many practical uses. Some of the more common ones are listed below: NFS uses Set several machines to share a CDROM or other media among them. This is cheaper and often a more convenient method to install software on multiple machines. On large networks, it might be more convenient to configure a central NFS server in which to store all the user home directories. These home directories can then be exported to the network so that users would always have the same home directory, regardless of which workstation they log in to. Several machines could have a common /usr/ports/distfiles directory. This allows for quick access to the source files without downloading them on each machine. Wylie Stilwell Contributed by Chern Lee Rewritten by Automatic Mounts with <application>amd</application> amd automatic mounter daemon - &man.amd.8; (the automatic mounter daemon) - automatically mounts a - remote file system whenever a file or directory within that - file system is accessed. Filesystems that are inactive for a - period of time will also be automatically unmounted by - amd. Using + &man.amd.8; (the automatic mounter daemon) automatically + mounts a remote file system whenever a file or directory + within that file system is accessed. Filesystems that are + inactive for a period of time will also be automatically + unmounted by amd. Using amd provides a simple alternative to permanent mounts, as permanent mounts are usually listed in /etc/fstab. amd operates by attaching itself as an NFS server to the /host and /net directories. When a file is accessed within one of these directories, amd looks up the corresponding remote mount and automatically mounts it. /net is used to mount an exported file - system from an IP address, while /host - is used to mount an export from a remote hostname. + system from an IP address, while /host is + used to mount an export from a remote hostname. An access to a file within /host/foobar/usr would tell amd to attempt to mount the /usr export on the host foobar. Mounting an Export with <application>amd</application> The showmount command shows the - available mounts on a remote host. For example, to - view the mounts of a host named - foobar: + available mounts on a remote host. For example, to view the + mounts of a host named foobar: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr As seen in the example, the showmount shows /usr as an export. When changing directories to /host/foobar/usr, amd attempts to resolve the hostname foobar and automatically mount the desired export. amd can be started by the startup scripts by placing the following lines in /etc/rc.conf: amd_enable="YES" Additionally, custom flags can be passed to amd from the amd_flags option. By default, amd_flags is set to: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" The /etc/amd.map file defines the default options that exports are mounted with. The /etc/amd.conf file defines some of the more advanced features of amd. Consult the &man.amd.8; and &man.amd.conf.5; manual pages for more information. John Lind Contributed by Problems Integrating with Other Systems Certain Ethernet adapters for ISA PC systems have limitations which can lead to serious network problems, particularly with NFS. This difficulty is not specific to FreeBSD, but FreeBSD systems are affected by it. The problem nearly always occurs when (FreeBSD) PC systems are networked with high-performance workstations, such as those made by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some operations may succeed, but suddenly the server will seem to become unresponsive to the client, even though requests to and from other systems continue to be processed. This happens to the client system, whether the client is the FreeBSD system or the workstation. On many systems, there is no way to shut down the client gracefully once this problem has manifested itself. The only solution is often to reset the client, because the NFS situation cannot be resolved. Though the correct solution is to get a higher performance and capacity Ethernet adapter for the FreeBSD system, there is a simple workaround that will allow satisfactory operation. If the FreeBSD system is the server, include the option on the mount from the client. If the FreeBSD system is the client, then mount the NFS file system with the option . These options may be specified using the fourth field of the fstab entry on the client for automatic mounts, or by using the parameter of the &man.mount.8; command for manual mounts. It should be noted that there is a different problem, sometimes mistaken for this one, when the NFS servers and clients are on different networks. If that is the case, make certain that the routers are routing the necessary UDP information. In the following examples, fastws is the host (interface) name of a high-performance workstation, and freebox is the host (interface) name of a FreeBSD system with a lower-performance Ethernet adapter. Also, /sharedfs will be the exported NFS file system (see &man.exports.5;), and /project will be the mount point on the client for the exported file system. In all cases, note that additional options, such as or and may be desirable in the application. Examples for the FreeBSD system (freebox) as the client in /etc/fstab on freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 As a manual mount command on freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Examples for the FreeBSD system as the server in /etc/fstab on fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 As a manual mount command on fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Nearly any 16-bit Ethernet adapter will allow operation without the above restrictions on the read or write size. For anyone who cares, here is what happens when the failure occurs, which also explains why it is unrecoverable. NFS typically works with a block size of 8 K (though it may do fragments of smaller sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS block gets split into multiple Ethernet packets, even though it is still a single unit to the upper-level code, and must be received, assembled, and acknowledged as a unit. The high-performance workstations can pump out the packets which comprise the NFS unit one right after the other, just as close together as the standard allows. On the smaller, lower capacity cards, the later packets overrun the earlier packets of the same unit before they can be transferred to the host and the unit as a whole cannot be reconstructed or acknowledged. As a result, the workstation will time out and try again, but it will try again with the entire 8 K unit, and the process will be repeated, ad infinitum. By keeping the unit size below the Ethernet packet size limitation, we ensure that any complete Ethernet packet received can be acknowledged individually, avoiding the deadlock situation. Overruns may still occur when a high-performance workstations is slamming data out to a PC system, but with the better cards, such overruns are not guaranteed on NFS units. When an overrun occurs, the units affected will be retransmitted, and there will be a fair chance that they will be received, assembled, and acknowledged. Bill Swingle Written by Eric Ogren Enhanced by Udo Erdelhoff Network Information System (NIS/YP) What Is It? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS, which stands for Network Information Services, was developed by Sun Microsystems to centralize administration of &unix; (originally &sunos;) systems. It has now essentially become an industry standard; all major &unix; like systems (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, FreeBSD, etc) support NIS. yellow pages NIS NIS was formerly known as Yellow Pages, but because of trademark issues, Sun changed the name. The old term (and yp) is still often seen and used. NIS domains It is a RPC-based client/server system that allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location. Windows NT It is similar to the &windowsnt; domain system; although the internal implementation of the two are not at all similar, the basic functionality can be compared. <acronym>NIS</acronym>Terms and Processes - There are several terms and important user - processes that will be explained while attempting to - implement NIS on FreeBSD, regardless if the system is a - NIS server or a NIS client: + There are several terms and important user processes that + will be explained while attempting to implement NIS on + FreeBSD, regardless if the system is a NIS server or a NIS + client: rpcbind portmap Term Description + NIS domainname An NIS master server and all of its clients (including its slave servers) have a NIS domainname. Similar to an &windowsnt; domain name, the NIS domainname does not have anything to do with DNS. rpcbind Must be running in order to enable RPC (Remote Procedure Call, a network protocol used by NIS). If rpcbind is not running, it will be impossible to run an NIS server, or to act as an NIS client. ypbind Binds an NIS client to its NIS server. It will take the NIS domainname from the system, and using RPC, connect to the server. ypbind is the core of client-server communication in an NIS environment; if ypbind dies on a client machine, it will not be able to access the NIS server. ypserv Should only be running on NIS servers; this is the NIS server process itself. If &man.ypserv.8; dies, then the server will no longer be able to respond to NIS requests (hopefully, there is a slave server to take over for it). There are some implementations of NIS (but not the FreeBSD one), that do not try to reconnect to another server if the server it used before dies. Often, the only thing that helps in this case is to restart the server process (or even the whole server) or the ypbind process on the client. rpc.yppasswdd Another process that should only be running on NIS master servers; this is a daemon that will allow NIS clients to change their NIS passwords. If this daemon is not running, users will have to login to the NIS master server and change their passwords there. - How Does It Work? There are three types of hosts in an NIS environment: master servers, slave servers, and clients. Servers act as a central repository for host configuration information. Master servers hold the authoritative copy of this information, while slave servers mirror this information for redundancy. Clients rely on the servers to provide this information to them. Information in many files can be shared in this manner. The master.passwd, group, and hosts files are commonly shared via NIS. Whenever a process on a client needs information that would normally be found in these files locally, it makes a query to the NIS server that it is bound to instead. Machine Types A NIS master server NIS master server . This server, analogous to a &windowsnt; primary domain controller, maintains the files used by all of the NIS clients. The passwd, group, and other various files used by the NIS clients live on the master server. It is possible for one machine to be an NIS master server for more than one NIS domain. However, this will not be covered in this introduction, which assumes a relatively small-scale NIS environment. NIS slave servers NIS slave server . Similar to the &windowsnt; backup domain controllers, NIS slave servers maintain copies of the NIS master's data files. NIS slave servers provide the redundancy, which is needed in important environments. They also help to balance the load of the master server: NIS Clients always attach to the NIS server whose response they get first, and this includes slave-server-replies. NIS clients NIS client . NIS clients, like most &windowsnt; workstations, authenticate against the NIS server (or the &windowsnt; domain controller in the &windowsnt; workstations case) to log on. Using NIS/YP This section will deal with setting up a sample NIS environment. Planning Let us assume that an administrator of a small - university lab, which consists of 15 FreeBSD - machines, currently has no centralized point of - administration. Each machine has its own - /etc/passwd and + university lab, which consists of 15 FreeBSD machines, + currently has no centralized point of administration. Each + machine has its own /etc/passwd and /etc/master.passwd. These files are kept in sync with each other only through manual intervention; currently, a user is added to the lab, the - process must be ran on all 15 machines. - The lab would clearly benefit from the addition of two + process must be ran on all 15 machines. The lab would + clearly benefit from the addition of two NIS servers. Therefore, the configuration of the lab now looks something like: Machine name IP address Machine role + ellington 10.0.0.2 NIS master coltrane 10.0.0.3 NIS slave basie 10.0.0.4 Faculty workstation bird 10.0.0.5 Client machine cli[1-11] 10.0.0.[6-17] Other client machines If this is the first time a NIS scheme is being developed, it should be thoroughly planned ahead of time. Regardless of network size, several decisions need to be made as part of the planning process. Choosing a NIS Domain Name NIS domainname This might not be the normal domainname for the network. It is more accurately called the NIS domainname. When a client broadcasts its requests for info, it includes the name of the NIS domain that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts that are related in some way. Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can cause confusion when trying to debug network problems. The NIS domainname should be unique within the network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the acme-art NIS domain. For this example, assume the chosen name will be test-domain. SunOS However, some operating systems (notably &sunos;) use their NIS domain name as their Internet domain name. If one or more machines on the network have this restriction, it must be used as the Internet domain name for the NIS domain name. Physical Server Requirements There are several things to keep in mind when choosing a machine to use as a NIS server. One of the unfortunate things about NIS is the level of dependency the clients have on the server. If a client cannot contact the server for its NIS domain, very often the machine becomes unusable. The lack of user and group information causes most systems to temporarily freeze up. With this in mind be sure to choose a machine that will not be prone to being rebooted frequently, or one that might be used for development. The NIS server should ideally be a stand alone machine whose sole purpose in life is to be an NIS server. If the network is not very heavily used, it is acceptable to put the NIS server on a machine running other services, however; if the NIS server becomes unavailable, it will adversely affect all NIS clients. NIS Servers The canonical copies of all NIS information are stored on a single machine called the NIS master server. The databases used to store the information are called NIS maps. In FreeBSD, these maps are stored in /var/yp/[domainname] where [domainname] is the name of the NIS domain being served. A single NIS server can support several domains at once, therefore it is possible to have several such directories, one for each supported domain. Each domain will have its own independent set of maps. NIS master and slave servers handle all NIS requests with the ypserv daemon. ypserv is responsible for receiving incoming requests from NIS clients, translating the requested domain and map name to a path to the corresponding database file and transmitting data from the database back to the client. Setting Up a NIS Master Server NIS server configuration Setting up a master NIS server can be relatively straight forward, depending on environmental needs. &os; comes with support for NIS out-of-the-box. It only needs to be enabled by adding the following lines to /etc/rc.conf: - nisdomainname="test-domain" + nisdomainname="test-domain" - This line will set the NIS domainname to + This line will set the NIS domainname to test-domain upon network setup (e.g., after reboot). - nis_server_enable="YES" + nis_server_enable="YES" - This will tell FreeBSD to start up the NIS server + This will tell FreeBSD to start up the NIS server processes when the networking is next brought up. - nis_yppasswdd_enable="YES" + nis_yppasswdd_enable="YES" - This will enable the rpc.yppasswdd - daemon which, as mentioned above, will allow users to - change their NIS password from a client - machine. + This will enable the + rpc.yppasswdd daemon which, as + mentioned above, will allow users to change their NIS + password from a client machine. Depending on the NIS setup, additional entries may be required. See the section about NIS servers that are also NIS clients, below, for details. After setting up the above entries, run the command /etc/netstart as superuser. It will set up everything, using the values defined in /etc/rc.conf. As a last step, before initializing the NIS maps, start the ypserv daemon manually: &prompt.root; service ypserv start Initializing the NIS Maps NIS maps The NIS maps are database files, that are kept in the /var/yp directory. They are generated from configuration files in the /etc directory of the NIS master, with one exception: /etc/master.passwd. This is for a good reason, never propagate passwords for root and other administrative accounts to all the servers in the NIS domain. Therefore, - before the the NIS maps are initialized, configure the + before the NIS maps are initialized, configure the primary password files: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd It is advisable to remove all entries regarding system accounts (bin, tty, kmem, games, etc), as well as any accounts that do not need to be propagated to the NIS clients (for example root and any other UID 0 (superuser) accounts). Ensure the /var/yp/master.passwd is neither group or world readable (mode 600)! Use the chmod command, as appropriate. Tru64 UNIX When this task has been completed, it is time to initialize the NIS maps. FreeBSD includes a script named ypinit to do this (see its manual page for more information). Note that this script is available on most &unix; Operating Systems, but not on all. On Digital UNIX/Compaq Tru64 UNIX it is called ypsetup. Because we are generating maps for an NIS master, we are going to pass the option to ypinit. To generate the NIS maps run: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. -If you don't, something might not work. +If not, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. At this point, ypinit should have created /var/yp/Makefile from /var/yp/Makefile.dist. When created, this file assumes that the operating environment is a single server NIS system with only &os; machines. Since test-domain has a slave server as well, edit /var/yp/Makefile as well: ellington&prompt.root; vi /var/yp/Makefile You should comment out the line that says NOPUSH = "True" (if it is not commented out already). Setting up a NIS Slave Server NIS slave server Setting up an NIS slave server is even more simple than setting up the master. Log on to the slave server and edit the file /etc/rc.conf as you did before. The only difference is that we now must use the option when running ypinit. The option requires the name of the NIS master be passed to it as well, so our command line looks like: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. -If you don't, something might not work. +If not, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. -Don't forget to update map ypservers on ellington. +Remember to update map ypservers on ellington. There should be a directory called /var/yp/test-domain. Copies of the NIS master server's maps should be in this directory. These files must always be up to date. The following /etc/crontab entries on the slave servers should do the job: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid These two lines force the slave to sync its maps with the maps on the master server. These entries are not mandatory because the master server automatically attempts to push any map changes to its slaves; however, due to the importance of correct password information on other clients depending on the slave server, it is recommended to specifically force the password map updates frequently. This is especially important on busy networks where map updates might not always complete. Now, run the command /etc/netstart on the slave server as well, which again starts the NIS server. NIS Clients An NIS client establishes what is called a binding to a particular NIS server using the ypbind daemon. The ypbind command checks the system's default domain (as set by the domainname command), and begins broadcasting RPC requests on the local network. These requests specify the name of the domain for which ypbind is attempting to establish a binding. If a server that has been configured to serve the requested domain receives one of the broadcasts, it will respond to ypbind, which will record the server's address. If there are several servers available (a master and several slaves, for example), ypbind will use the address of the first one to respond. From that point on, the client system will direct all of its NIS requests to that server. ypbind will occasionally ping the server to make sure it is still up and running. If it fails to receive a reply to one of its pings within a reasonable amount of time, ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server. Setting Up a NIS Client NIS client configuration - Setting up a FreeBSD machine to be a NIS - client is fairly straightforward. + Setting up a FreeBSD machine to be a NIS client is + fairly straightforward. - Edit /etc/rc.conf - and add the following lines in order to set the NIS - domainname and start ypbind during - network startup: + Edit /etc/rc.conf and add the + following lines in order to set the NIS domainname and + start ypbind during network + startup: nisdomainname="test-domain" nis_client_enable="YES" To import all possible password entries from the NIS server, remove all user accounts from the /etc/master.passwd file and use vipw to add the following line to the end of the file: +::::::::: This line will afford anyone with a valid account in the NIS server's password maps an account. There are many ways to configure the NIS client by changing this line. See the - netgroups - section below for more information. For more - detailed reading see O'Reilly's book on + netgroups + section below for more information. For + more detailed reading see O'Reilly's book on Managing NFS and NIS. Keep in mind that at least one local account (i.e. not imported via NIS) must exist in /etc/master.passwd and this account should also be a member of the group wheel. If there is something wrong with NIS, this account can be used to log in remotely, become root, and fix things. To import all possible group entries from the NIS server, add this line to /etc/group: +:*:: To start the NIS client immediately, execute the following commands as the superuser: &prompt.root; /etc/netstart &prompt.root; service ypbind start After completing these steps, the command, ypcat passwd, should show the server's passwd map. NIS Security In general, any remote user may issue an RPC to &man.ypserv.8; and retrieve the contents of the NIS maps, provided the remote user knows the domainname. To prevent such unauthorized transactions, &man.ypserv.8; supports a feature called securenets which can be used to restrict access to a given set of hosts. At startup, &man.ypserv.8; will attempt to load the securenets information from a file called /var/yp/securenets. This path varies depending on the path specified with the option. This file contains entries that consist of a network specification and a network mask separated by white space. Lines starting with # are considered to be comments. A sample securenets file might look like this: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 If &man.ypserv.8; receives a request from an address that matches one of these rules, it will process the request normally. If the address fails to match a rule, the request will be ignored and a warning message will be logged. If the /var/yp/securenets file does not exist, ypserv will allow connections from any host. The ypserv program also has support for Wietse Venema's TCP Wrapper package. This allows the administrator to use the TCP Wrapper configuration files for access control instead of /var/yp/securenets. While both of these access control mechanisms provide some security, they, like the privileged port test, are vulnerable to IP spoofing attacks. All NIS-related traffic should be blocked at the firewall. Servers using /var/yp/securenets may fail to serve legitimate NIS clients with archaic TCP/IP implementations. Some of these implementations set all host bits to zero when doing broadcasts and/or fail to observe the subnet mask when calculating the broadcast address. While some of these problems can be fixed by changing the client configuration, other problems may force the retirement of the client systems in question or the abandonment of /var/yp/securenets. Using /var/yp/securenets on a server with such an archaic implementation of TCP/IP is a really bad idea and will lead to loss of NIS functionality for large parts of the network. TCP Wrappers The use of TCP Wrapper - increases the latency of the NIS server. The - additional delay may be long enough to cause timeouts in - client programs, especially in busy networks or with slow - NIS servers. If one or more of the client systems - suffers from these symptoms, convert the client - systems in question into NIS slave servers and force them - to bind to themselves. + increases the latency of the NIS server. The additional + delay may be long enough to cause timeouts in client + programs, especially in busy networks or with slow NIS + servers. If one or more of the client systems suffers from + these symptoms, convert the client systems in question into + NIS slave servers and force them to bind to + themselves. Barring Some Users from Logging On In our lab, there is a machine basie that is supposed to be a faculty only workstation. We do not want to take this machine out of the NIS domain, yet the passwd file on the master NIS server contains accounts for both faculty and students. What can we do? There is a way to bar specific users from logging on to a machine, even if they are present in the NIS database. To do this, add -username with - the correct number of colons like other entries to the - end of the /etc/master.passwd file on the - client machine, where username is - the username of the user to bar from logging in. - The line with the blocked user must be before the - + line for allowing NIS users. - This should preferably be done using vipw, - since vipw will sanity check the changes - to /etc/master.passwd, as well as - automatically rebuild the password database after - editing. For example, to bar user - bill from logging on to - basie: + the correct number of colons like other entries to the end of + the /etc/master.passwd file on the client + machine, where username is the + username of the user to bar from logging in. The line with + the blocked user must be before the + line + for allowing NIS users. This should preferably be done using + vipw, since vipw will + sanity check the changes to + /etc/master.passwd, as well as + automatically rebuild the password database after editing. + For example, to bar user bill from + logging on to basie: basie&prompt.root; vipw [add -bill::::::::: to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin -bill::::::::: +::::::::: basie&prompt.root; Udo Erdelhoff Contributed by Using Netgroups netgroups The method shown in the previous section works reasonably well for special rules in an environment with small numbers of users and/or machines. On larger networks, administrators will likely forget to bar some users from - logging onto sensitive machines, or may even have to - modify each machine separately, thus losing the main benefit - of NIS: centralized - administration. + logging onto sensitive machines, or may even have to modify + each machine separately, thus losing the main benefit of NIS: + centralized administration. The NIS developers' solution for this problem is called netgroups. Their purpose and semantics can be compared to the normal groups used by &unix; file systems. The main differences are the lack of a numeric ID and the ability to define a netgroup by including both user accounts and other netgroups. Netgroups were developed to handle large, complex networks with hundreds of users and machines. On one hand, this is a - Good Thing in such a situation. - On the other hand, this complexity makes it almost impossible - to explain netgroups with really simple examples. The example - used in the remainder of this section demonstrates this - problem. + Good Thing in such a situation. On the other hand, this + complexity makes it almost impossible to explain netgroups + with really simple examples. The example used in the + remainder of this section demonstrates this problem. Let us assume that the successful introduction of NIS in - the laboratory caught a superiors' interest. The next - task is to extend the NIS domain to cover some of the other - machines on campus. The two tables contain the names of the - new users and new machines as well as brief descriptions of - them. + the laboratory caught a superiors' interest. The next task is + to extend the NIS domain to cover some of the other machines + on campus. The two tables contain the names of the new users + and new machines as well as brief descriptions of them. User Name(s) Description alpha, beta Normal employees of the IT department charlie, delta The new apprentices of the IT department echo, foxtrott, golf, ... Ordinary employees able, baker, ... The current interns Machine Name(s) Description war, death, famine, pollution The most important servers deployed. Only the IT employees are allowed to log onto these machines. pride, greed, envy, wrath, lust, sloth Less important servers. All members of the IT department are allowed to login onto these machines. one, two, three, four, ... Ordinary workstations. Only the real employees are allowed to use these machines. trashcan A very old machine without any critical data. Even the intern is allowed to use this box. An attempt to implement these restrictions by separately blocking each user, would require the addition of the -user line to each system's passwd. One line for each user who is not allowed to login onto that system. Forgetting just one entry could cause significant trouble. It may be feasible to do this correctly during the initial setup; however, eventually someone will forget to add these lines for new users. Handling this situation with netgroups offers several advantages. Each user need not be handled separately; they - would be assigned to one or more netgroups and logins would - be allowed or forbidden for all members of the netgroup. - While adding a new - machine, login restrictions must be defined for all - netgroups. If a new user is added, they must be added - to one or more netgroups. Those changes are - independent of each other: no more for each combination - of user and machine do... If the NIS setup is planned - carefully, only one central configuration file - needs modification to grant or deny access to machines. + would be assigned to one or more netgroups and logins would be + allowed or forbidden for all members of the netgroup. While + adding a new machine, login restrictions must be defined for + all netgroups. If a new user is added, they must be added to + one or more netgroups. Those changes are independent of each + other: no more + for each combination of user and machine do... + If the NIS setup is planned carefully, only one central + configuration file needs modification to grant or deny access + to machines. The first step is the initialization of the NIS map - netgroup. &os;'s &man.ypinit.8; does not create this map - by default, but its NIS implementation will support it - after creation. To create an empty map, simply type + netgroup. &os;'s &man.ypinit.8; does not create this map by + default, but its NIS implementation will support it after + creation. To create an empty map, simply type ellington&prompt.root; vi /var/yp/netgroup and begin adding content. For our example, we need at least four netgroups: IT employees, IT apprentices, normal employees and interns. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP etc. are the names of the netgroups. Each bracketed group adds one or more user accounts to it. The three fields inside a group are: The name of the host(s) where the following items are - valid. If a hostname is not specified, the entry is - valid on all hosts. If a hostname is specified, it - will need to be micro-managed within this - configuration. + valid. If a hostname is not specified, the entry is valid + on all hosts. If a hostname is specified, it will need to + be micro-managed within this configuration. The name of the account that belongs to this netgroup. The NIS domain for the account. Accounts may be imported from other NIS domains into a netgroup. Each of these fields may contain wildcards. See &man.netgroup.5; for details. netgroups Netgroup names longer than 8 characters should not be - used, especially with machines running other - operating systems within the NIS domain. The names are - case sensitive; using capital letters for netgroup - names is an easy way to distinguish between user, machine - and netgroup names. + used, especially with machines running other operating + systems within the NIS domain. The names are case + sensitive; using capital letters for netgroup names is an + easy way to distinguish between user, machine and netgroup + names. Some NIS clients (other than &os;) cannot handle netgroups with a large number of entries. For example, some older versions of &sunos; start to cause trouble if a netgroup contains more than 15 entries. This limit may be circumvented by creating several sub-netgroups with 15 users or fewer and a real netgroup consisting of the sub-netgroups: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - Repeat this process if more than 225 - users will exist within a single netgroup. + Repeat this process if more than 225 users will exist + within a single netgroup. Activating and distributing the new NIS map is easy: ellington&prompt.root; cd /var/yp ellington&prompt.root; make This will generate the three NIS maps netgroup, netgroup.byhost and netgroup.byuser. Use &man.ypcat.1; to check if the new NIS maps are available: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser The output of the first command should resemble the contents of /var/yp/netgroup. The second command will not produce output without specified - host-specific netgroups. The third command may be used to - get the list of netgroups for a user. + host-specific netgroups. The third command may be used to get + the list of netgroups for a user. The client setup is quite simple. To configure the server - war, use - &man.vipw.8; to replace the line + war, use &man.vipw.8; to replace the + line +::::::::: with +@IT_EMP::::::::: Now, only the data for the users defined in the netgroup IT_EMP is imported into - war's password database and only - these users are allowed to login. + war's password database and only these users + are allowed to login. Unfortunately, this limitation also applies to the ~ function of the shell and all routines converting between user names and numerical user IDs. In - other words, cd - ~user will not work, - ls -l will show the numerical ID instead of - the username and find . -user joe -print - will fail with No such user. To fix - this, import all user entries - without allowing them to login into the + other words, + cd ~user will + not work, ls -l will show the numerical ID + instead of the username and + find . -user joe -print will fail with + No such user. To fix this, import all + user entries without allowing them to login into the servers. This can be achieved by adding another line to /etc/master.passwd. This line should contain: +:::::::::/sbin/nologin, meaning Import all entries but replace the shell with /sbin/nologin in the imported entries. It is possible to replace any field in the passwd entry by placing a default value in /etc/master.passwd. Make sure that the line +:::::::::/sbin/nologin is placed after +@IT_EMP:::::::::. Otherwise, all user accounts imported from NIS will have /sbin/nologin as their login shell. After this change, the NIS map will only need modification when a new employee joins the IT department. A similar approach for the less important servers may be used by replacing the old +::::::::: in their local version of /etc/master.passwd with something like this: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin The corresponding lines for the normal workstations could be: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin And everything would be fine until there is a policy change a few weeks later: The IT department starts hiring interns. The IT interns are allowed to use the normal workstations and the less important servers; and the IT - apprentices are allowed to login onto the main servers. - Add a new netgroup IT_INTERN, then add the - new IT interns to this netgroup and start to change the - configuration on each and every machine. As the old saying - goes: Errors in centralized planning lead to global + apprentices are allowed to login onto the main servers. Add a + new netgroup IT_INTERN, then add the new IT + interns to this netgroup and start to change the configuration + on each and every machine. As the old saying goes: + Errors in centralized planning lead to global mess. NIS' ability to create netgroups from other netgroups can be used to prevent situations like these. One possibility is the creation of role-based netgroups. For example, one might create a netgroup called BIGSRV to define the login restrictions for the important servers, another netgroup called SMALLSRV for the less important servers and a third netgroup called - USERBOX for the normal - workstations. Each of these netgroups contains the netgroups - that are allowed to login onto these machines. The new - entries for the NIS map netgroup should look like - this: + USERBOX for the normal workstations. Each + of these netgroups contains the netgroups that are allowed to + login onto these machines. The new entries for the NIS map + netgroup should look like this: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS This method of defining login restrictions works reasonably well when it is possible to define groups of machines with identical restrictions. Unfortunately, this is the exception and not the rule. Most of the time, the ability to define login restrictions on a per-machine basis is required. Machine-specific netgroup definitions are the other possibility to deal with the policy change outlined above. In this scenario, the /etc/master.passwd of each box contains two lines starting with +. The first of them adds a netgroup with the accounts allowed to login onto this machine, the second one adds all other accounts with /sbin/nologin as shell. It is a good idea to use the ALL-CAPS version of the machine name as the name of the netgroup. In other words, the lines should look like this: +@BOXNAME::::::::: +:::::::::/sbin/nologin - Once this task is completed on all the machines, - there is no longer a need to modify the local versions of + Once this task is completed on all the machines, there is + no longer a need to modify the local versions of /etc/master.passwd ever again. All further changes can be handled by modifying the NIS map. Here - is an example of a possible netgroup map for this - scenario with some additional goodies: + is an example of a possible netgroup map for this scenario + with some additional goodies: # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] If some kind of database is used to manage the user accounts, it may be possible to create the first part of the map using the database's reporting tools. This way, new users will automatically have access to the boxes. One last word of caution: It may not always be advisable to use machine-based netgroups. When deploying a couple of dozen or even hundreds of identical machines for student labs, role-based netgroups instead of machine-based netgroups may be used to keep the size of the NIS map within reasonable limits. Important Things to Remember There are still a couple of things administrators need to do differently now that machines are in an NIS environment. - Every time a new user is added to the lab, they - must be added to the master NIS server and the + Every time a new user is added to the lab, they must + be added to the master NIS server and the NIS maps will need rebuilt. If this step is omitted, the new user will not be able to login anywhere except on the NIS master. For example, if we needed to add a new user jsmith to the lab, we would: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain The user may also be added using adduser jsmith instead of pw useradd jsmith. - + Keep the administration accounts out of the NIS maps. This is undesirable as it will create a security risk. These users and passwords should not be propagated to all machines. Especially if these machines will have users whom should not have access to those accounts. + Keep the NIS master and slave secure, and minimize their downtime. If somebody either hacks or simply turns off these machines, they have effectively rendered many people without the ability to login to the lab. This is the chief weakness of any centralized administration system. If the NIS servers are not protected, there will be a lot of angry users and unhappy management! NIS v1 Compatibility &os;'s ypserv has some support for serving NIS v1 clients. &os;'s NIS implementation only uses the NIS v2 protocol; however, other implementations include support for the v1 protocol for backwards compatibility with older systems. The ypbind daemons supplied with these systems will attempt to establish a binding to an NIS v1 server even though they may never actually need it (and they may persist in broadcasting in search of one even after they receive a response from a v2 server). Note that while support for normal client calls is provided, this version of ypserv does not handle v1 map transfer requests. Additionally, it cannot be used as a master or slave in conjunction with older NIS servers that only support the v1 protocol. Fortunately, there probably are not any such servers still in use today. NIS Servers That Are Also NIS Clients Care must be taken when running ypserv in a multi-server domain where the server machines are also NIS clients. It is generally a good idea to force the servers to bind to themselves rather than allowing them to broadcast bind requests and possibly become bound to each other. Strange failure modes can result if one server goes down and others are dependent upon it. Eventually all the clients will time out and attempt to bind to other servers, but the delay involved can be considerable and the failure mode is still present since the servers might bind to each other all over again. A host may be forced to bind to a particular server by running ypbind with the flag. Add the following lines to /etc/rc.conf to enable this feature during every system boot: nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" See &man.ypbind.8; for further information. Password Formats NIS password formats One of the most common issues that people run into when trying to implement NIS is password format compatibility. If the NIS server is using DES encrypted passwords, it will only support clients that are also using DES. For example, if any &solaris; NIS clients exist on the network, there is a highly likelihood DES must be used for encrypted passwords. To check which format the servers and clients are using, look at /etc/login.conf. If the host is configured to use DES encrypted passwords, then the default class will contain an entry like this: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Further entries elided] Other possible values for the passwd_format capability include blf and md5 (for Blowfish and MD5 encrypted passwords, respectively). If any changes were made to /etc/login.conf, the login capability database must be rebuilt by running the following command as root: &prompt.root; cap_mkdb /etc/login.conf - The format of passwords already in - /etc/master.passwd will not be updated - until a user changes his password for the first time - after the login capability database is - rebuilt. + + The format of passwords already in + /etc/master.passwd will not be updated + until a user changes his password for the first time + after the login capability database is + rebuilt. + Next, in order to ensure that passwords are encrypted with - the chosen format, check that - the crypt_default in + the chosen format, check that the + crypt_default in /etc/auth.conf gives precedence to the chosen password format. To do this, place the chosen format - first in the list. For example, when using DES - encrypted passwords, the entry would be: + first in the list. For example, when using DES encrypted + passwords, the entry would be: crypt_default = des blf md5 Having followed the above steps on each of the &os; based - NIS servers and clients, verify that they all agree - on which password format is used within the network. If users - have trouble authenticating on an NIS client, this is a pretty - good place to start looking for possible problems. Remember: - to deploy an NIS server for a heterogeneous - network, they will probably have to use DES on all systems - because it is the lowest common standard. + NIS servers and clients, verify that they all agree on which + password format is used within the network. If users have + trouble authenticating on an NIS client, this is a pretty good + place to start looking for possible problems. Remember: to + deploy an NIS server for a heterogeneous network, they will + probably have to use DES on all systems because it is the + lowest common standard. Tom Rhodes Written by &os; and <acronym>LDAP</acronym> LDAP LDAP, the Lightweight Directory Access Protocol, is an application layer protocol used to access, modify, and authenticate (bind) using a distributed directory information service. Think of it as a phone or record book which stores several levels of hierarchical, homogeneous information. It is often used in networks where users often need access to several levels of internal information utilizing a single account. For example, email authentication, pulling employee contact information, and internal website authentication might all make use of a single user in the LDAP server's record base. This section will not provide a history or the implementation details of the protocol. These sections were authored to get an LDAP server and/or client configured both quickly and securely; however, any information base requires planning and this is no exception. Planning should include what type of information will be stored, what that information will be used for, whom should have access to said information, and how to secure this information from prying eyes. <acronym>LDAP</acronym> Terminology and Structure Before continuing, several parts of LDAP must be explained to prevent confusion. And confusion with this configuration is relatively simple. To begin, all directory entries consist of a group of attributes. Each of these attribute sets contain a name, a unique identifier known as a DN or distinguished name normally built from several other attributes such as the RDN. The RDN or relative distinguished name, is a more common name for the attribute. Like directories have absolute and relative paths, consider a DN as an absolute path and the RDN as the relative path. As an example, an entry might look like the following: &prompt.user; ldapsearch -xb "uid=trhodes,ou=users,o=example.com" # extended LDIF # # LDAPv3 # base <uid=trhodes,ou=users,o=example.com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # trhodes, users, example.com dn: uid=trhodes,ou=users,o=example.com mail: trhodes@example.com cn: Tom Rhodes uid: trhodes telephoneNumber: (xxx) xxx-xxxx # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 In this example, it is very obvious what the various attributes are; however, the cn attribute should be noticed. This is the RDN discussed previously. In addition, there is a unique user id provided here. It is common practice to have specific uid or uuids for entries to ease in any future migration. Configuring an <acronym>LDAP</acronym> Server LDAP Server To configure &os; to act as an LDAP server, the OpenLDAP port needs installed. This may be accomplished using the pkg_add command or by installing the net/openldap24-server port. Building the port is recommended as the administrator may select a great deal of options at this time and disable some options. In most cases, the defaults will be fine; however, this is the time to enable SQL support if needed. A few directories will be required from this point on, at minimal, a data directory and a directory to store the certificates in. Create them both with the following commands: &prompt.root; mkdir /var/db/openldap-data &prompt.root; mkdir /usr/local/etc/openldap/private Copy over the database configuration file: &prompt.root; cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG The next phase is to configure the SSL certificates. While creating certificates is discussed in the OpenSSL section in this book, a certificate authority is needed so a different method will be used. It is recommended that this section be reviewed prior to configuring to ensure correct information is entered during the certificate creation process below. The following commands must be executed in the /usr/local/etc/openldap/private directory. This is important as the file permissions will need to be restrictive and users should not have access to these files directly. To create the certificates, issues the following commands. &prompt.root; openssl req -days 365 -nodes -new -x509 -keyout ca.key -out ../ca.crt The entries for these may be completely generic except for the Common Name entry. This entry must have something different than the system hostname. If the entry is the hostname, it would be like the hostname is attempting to verify hostname. In cases with a self signed certificate like this example, just prefix the hostname with CA for certificate authority. The next task is to create a certificate signing request and a private key. To do this, issue the following commands: &prompt.root; openssl req -days 365 -nodes -new -keyout server.key -out server.csr During the certificate generation process, be sure to correctly set the common name attribute. After this has been completed, the key will need signed: &prompt.root; openssl x509 -req -days 365 -in server.csr -out ../server.crt -CA ../ca.crt -CAkey ca.key -CAcreateserial The final part of the certificate generation process is to generate and sign the client certificates: &prompt.root; openssl req -days 365 -nodes -new -keyout client.key -out client.csr &prompt.root; openssl x509 -req -days 3650 -in client.csr -out ../client.crt -CA ../ca.crt -CAkey ca.key Remember, again, to respect the common name attribute. This is a common cause for confusion during the first attempt to configure LDAP. In addition, ensure that a total of eight (8) new files have been generated through the proceeding commands. If so, the next step is to edit /usr/local/etc/openldap/slapd.conf and add the following options: TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCertificateFile /usr/local/etc/openldap/server.crt TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key TLSCACertificateFile /usr/local/etc/openldap/ca.crt In addition, edit /usr/local/etc/openldap/ldap.conf and add the following lines: TLS_CACERT /usr/local/etc/openldap/ca.crt TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3 While editing these this file, set the to the desired values, and uncomment all three of the , and options. In addition, set the to contain and . The resulting file should look similar to the following shown here: BASE dc=example,dc=com URI ldap:// ldaps:// SIZELIMIT 12 TIMELIMIT 15 #DEREF never TLS_CACERT /usr/local/etc/openldap/ca.crt TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3 A password for the server will need to be created as the default is extremely poor as is normal in this industry. To do this, issue the following command, sending the output to slapd.conf: &prompt.root; slappasswd -h "{SHA}" >> /usr/local/etc/openldap/slapd.conf There will be a prompt for entering the password and, if the process does not fail, a password hash will be added to the end of slapd.conf. The slappasswd understands several hashing formats, refer to the manual page for more information. Edit /usr/local/etc/openldap/slapd.conf and add the following lines: password-hash {sha} allow bind_v2 In addition, the in this file must be updated to match the from the previous configuration. The option should also be set. A good recommendation is something like . Before saving this file, place the option in front of the password output from the slappasswd and delete the old option above. The end result should look similar to this: TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCertificateFile /usr/local/etc/openldap/server.crt TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key TLSCACertificateFile /usr/local/etc/openldap/ca.crt rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g= Finally, enable the OpenLDAP service in rc.conf. At this time, setting up a URI and providing the group - and user to run as may be useful. - Edit /etc/rc.conf and add the following + and user to run as may be useful. Edit + /etc/rc.conf and add the following lines: slapd_enable="YES" slapd_flags="-4 -h ldaps:///" At this point the server should be ready to be brought up and tested. To perform this task, issue the following command: &prompt.root; service slapd start If everything was configured correctly, a search of the directory should show a successful connection with a single response as in this example: &prompt.root; ldapsearch -Z # extended LDIF # # LDAPv3 # base <dc=example,dc=com> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 3 result: 32 No such object # numResponses: 1 Considering the service should now be responding, as it is above, the directory may be populated using the ldapadd command. In this example, there is a file containing a list of users to be added to this particular directory. First, create a file to be imported with the following dataset: dn: dc=example,dc=com objectclass: dcObject objectclass: organization o: Example dc: Example dn: cn=Manager,dc=example,dc=com objectclass: organizationalRole cn: Manager To debug any of the following, stop the slapd service using the service command and start it using with debugging options. To accomplish this, issue the following command: &prompt.root; /usr/local/libexec/slapd -d -1 To import this datafile, issue the following command, assuming the file is import.ldif: &prompt.root; ldapadd -Z -D "cn=Manager,dc=example,dc=com" -W -f import.ldif There will be a request for the password specified earlier, and the output should look like this: - Enter LDAP Password: + Enter LDAP Password: adding new entry "dc=example,dc=com" adding new entry "cn=Manager,dc=example,dc=com" Verify the data was added by issuing a search on the server using ldapsearch. In this case the output should look like this: &prompt.user; ldapsearch -Z # extended LDIF # # LDAPv3 # base <dc=example,dc=com> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # example.com dn: dc=example,dc=com objectClass: dcObject objectClass: organization o: Example dc: Example # Manager, example.com dn: cn=Manager,dc=example,dc=com objectClass: organizationalRole cn: Manager # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2 It is of course advisable to read about the structure of LDAP directories and the various manual pages mentioned in this section. At this point, the server should be configured and functioning properly. Greg Sutter Written by Automatic Network Configuration (DHCP) What Is DHCP? Dynamic Host Configuration Protocol DHCP Internet Systems Consortium (ISC) DHCP, the Dynamic Host Configuration Protocol, describes the means by which a system can connect to a network and obtain the necessary information for communication upon that network. FreeBSD uses the OpenBSD dhclient taken from OpenBSD 3.7. All information here regarding dhclient is for use with either of the ISC or OpenBSD DHCP clients. The DHCP server is the one included in the ISC distribution. What This Section Covers This section describes both the client-side components of the ISC and OpenBSD DHCP client and server-side components of the ISC DHCP system. The client-side program, dhclient, comes integrated within FreeBSD, and the server-side portion is available from the net/isc-dhcp42-server port. The &man.dhclient.8;, &man.dhcp-options.5;, and &man.dhclient.conf.5; manual pages, in addition to the references below, are useful resources. How It Works UDP When dhclient, the DHCP client, is executed on the client machine, it begins broadcasting requests for configuration information. By default, these requests are on UDP port 68. The server replies on UDP 67, giving the client an IP address and other relevant network information such as netmask, router, and DNS servers. All of this information comes in the form of a DHCP lease and is only valid for a certain time (configured by the DHCP server maintainer). In this manner, stale IP addresses for clients no longer connected to the network can be automatically reclaimed. DHCP clients can obtain a great deal of information from the server. An exhaustive list may be found in &man.dhcp-options.5;. FreeBSD Integration &os; fully integrates the OpenBSD DHCP client, dhclient. DHCP client support is provided within both the installer and the base system, obviating the need for detailed knowledge of network configurations on any network that runs a DHCP server. sysinstall DHCP is supported by sysinstall. When configuring a network interface within sysinstall, the second question asked is: Do you want to try DHCP configuration of the interface?. Answering affirmatively will execute dhclient, and if successful, will fill in the network configuration information automatically. There are two things required to have the system use DHCP upon startup: DHCP requirements Make sure that the bpf device is compiled into the kernel. To do this, add device bpf to the kernel configuration file, and rebuild the kernel. For more information about building kernels, see . The bpf device is already part of the GENERIC kernel that is supplied with &os;, thus there is no need to build a custom kernel for DHCP. In the case of a custom kernel configuration file, this device must be present for DHCP to function properly. For those who are particularly security conscious, take note that bpf is also the device that allows packet sniffers to work correctly (although they still have to be run as root). bpf is required to use DHCP; however, the security sensitive types should probably not add bpf to the kernel in the expectation that at some point in the future the system will be using DHCP. By default, DHCP configuration on &os; runs in the background, or asynchronously. Other startup scripts continue to run while DHCP completes, speeding up system startup. Background DHCP works well when the DHCP server responds quickly to requests and the DHCP configuration process goes quickly. However, DHCP may take a long time to complete on some systems. If network services attempt to run before DHCP has completed, they will fail. Using DHCP in synchronous mode prevents the problem, pausing startup until DHCP configuration has completed. To connect to a DHCP server in the background while other startup continues (asynchronous mode), use the DHCP value in /etc/rc.conf: ifconfig_fxp0="DHCP" To pause startup while DHCP completes, use synchronous mode with the SYNCDHCP value: ifconfig_fxp0="SYNCDHCP" Replace the fxp0 shown in these examples with the name of the interface to be dynamically configured, as described in . When using a different file system location for dhclient, or if additional flags must be passed to dhclient, include (editing as necessary): dhclient_program="/sbin/dhclient" dhclient_flags="" DHCP server The DHCP server, dhcpd, is - included as part of the net/isc-dhcp42-server port in - the ports collection. This port contains the ISC DHCP - server and documentation. + included as part of the + net/isc-dhcp42-server + port in the ports collection. This port contains the ISC + DHCP server and documentation. Files DHCP configuration files /etc/dhclient.conf dhclient requires a configuration file, /etc/dhclient.conf. Typically the file contains only comments, the defaults being reasonably sane. This configuration file is described by the &man.dhclient.conf.5; manual page. /sbin/dhclient dhclient is statically linked and resides in /sbin. The &man.dhclient.8; manual page gives more information about dhclient. /sbin/dhclient-script dhclient-script is the FreeBSD-specific DHCP client configuration script. It is described in &man.dhclient-script.8;, but should not need any user modification to function properly. /var/db/dhclient.leases.interface The DHCP client keeps a database of valid leases in this file, which is written as a log. &man.dhclient.leases.5; gives a slightly longer description. Further Reading The DHCP protocol is fully described in RFC - 2131. An informational resource has also been set + 2131. An informational resource has also been set up at . Installing and Configuring a DHCP Server What This Section Covers This section provides information on how to configure a FreeBSD system to act as a DHCP server using the ISC (Internet Systems Consortium) implementation of the DHCP server. The server is not provided as part of &os;, and so the net/isc-dhcp42-server port must be installed to provide this service. See for more information on using the Ports Collection. DHCP Server Installation DHCP installation In order to configure the &os; system as a DHCP server, first ensure that the &man.bpf.4; device is compiled into the kernel. To do this, add device bpf to the kernel configuration file, and rebuild the kernel. For more information about building kernels, see . The bpf device is already part of the GENERIC kernel that is supplied with &os;, so there is no need to create a custom kernel in order to get DHCP working. Those who are particularly security conscious should note that bpf is also the device that allows packet sniffers to function correctly (although such programs still need privileged access). The bpf device is required to use DHCP, but if the sensitivity of the system's security is high, this device should not be included in the kernel purely because the use of DHCP may, at some point in the future, be desired. The next thing that is needed is to edit the sample dhcpd.conf which was installed by the net/isc-dhcp42-server port. By default, this will be /usr/local/etc/dhcpd.conf.sample, and you should copy this to /usr/local/etc/dhcpd.conf before proceeding to make changes. Configuring the DHCP Server DHCP dhcpd.conf dhcpd.conf is comprised of declarations regarding subnets and hosts, and is perhaps most easily explained using an example : option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } This option specifies the domain that will be provided to clients as the default search domain. See &man.resolv.conf.5; for more information on what this means. This option specifies a comma separated list of DNS servers that the client should use. The netmask that will be provided to clients. A client may request a specific length of time that a lease will be valid. Otherwise the server will assign a lease with this expiry value (in seconds). This is the maximum length of time that the server will lease for. Should a client request a longer lease, a lease will be issued, although it will only be valid for max-lease-time seconds. This option specifies whether the DHCP server should attempt to update DNS when a lease is accepted or released. In the ISC implementation, this option is required. This denotes which IP addresses should be used in the pool reserved for allocating to clients. IP addresses between, and including, the ones stated are handed out to clients. Declares the default gateway that will be provided to clients. The hardware MAC address of a host (so that the DHCP server can recognize a host when it makes a request). Specifies that the host should always be given the same IP address. Note that using a hostname is correct here, since the DHCP server will resolve the hostname itself before returning the lease information. Once the configuration of dhcpd.conf has been completed, enable the DHCP server in /etc/rc.conf, i.e., by adding: dhcpd_enable="YES" dhcpd_ifaces="dc0" Replace the dc0 interface name with the interface (or interfaces, separated by whitespace) that the DHCP server should listen on for DHCP client requests. Proceed to start the server by issuing the following command: &prompt.root; service isc-dhcpd start Any future changes to the configuration of the server will require the sending of a SIGTERM signal to dhcpd rather than a SIGHUP. It is definitely more simple to use &man.service.8; to completely restart the service. Files DHCP configuration files /usr/local/sbin/dhcpd dhcpd is statically linked and resides in /usr/local/sbin. The &man.dhcpd.8; manual page installed with the port gives more information about dhcpd. /usr/local/etc/dhcpd.conf dhcpd requires a configuration file, /usr/local/etc/dhcpd.conf before it will start providing service to clients. This file needs to contain all the information that should be provided to clients that are being serviced, along with information regarding the operation of the server. This configuration file is described by the &man.dhcpd.conf.5; manual page installed by the port. /var/db/dhcpd.leases The DHCP server keeps a database of leases it has issued in this file, which is written as a log. The manual page &man.dhcpd.leases.5;, installed by the port gives a slightly longer description. /usr/local/sbin/dhcrelay dhcrelay is used in advanced environments where one DHCP server forwards a request from a client to another DHCP server on a separate network. If this functionality is required, then install the net/isc-dhcp42-relay port. The &man.dhcrelay.8; manual page provided with the port contains more detail. Chern Lee Contributed by Tom Rhodes Daniel Gerzo Domain Name System (<acronym>DNS</acronym>) Overview BIND &os; utilizes, by default, a version of BIND (Berkeley Internet Name Domain), which is the most common implementation of the DNS protocol. DNS is the protocol through which names are mapped to IP addresses, and vice versa. For example, a query for www.FreeBSD.org will receive a reply with the IP address of The &os; Project's web server, whereas, a query for ftp.FreeBSD.org will return the IP address of the corresponding FTP machine. Likewise, the opposite can happen. A query for an IP address can resolve its hostname. It is not necessary to run a name server to perform DNS lookups on a system. &os; currently comes with BIND9 DNS server software by default. Our installation provides enhanced security features, a new file system layout and automated &man.chroot.8; configuration. DNS DNS is coordinated across the Internet through a somewhat complex system of authoritative root, Top Level Domain (TLD), and other smaller-scale name servers which host and cache individual domain information. Currently, BIND is maintained by the Internet Systems Consortium . Terminology To understand this document, some terms related to DNS must be understood. resolver reverse DNS root zone Term Definition Forward DNS Mapping of hostnames to IP addresses. Origin Refers to the domain covered in a particular zone file. named, BIND Common names for the BIND name server package within &os;. Resolver A system process through which a machine queries a name server for zone information. Reverse DNS Mapping of IP addresses to hostnames. Root zone The beginning of the Internet zone hierarchy. All zones fall under the root zone, similar to how all files in a file system fall under the root directory. Zone An individual domain, subdomain, or portion of the DNS administered by the same authority. zones examples Examples of zones: . is how the root zone is usually referred to in documentation. org. is a Top Level Domain (TLD) under the root zone. example.org. is a zone under the org. TLD. 1.168.192.in-addr.arpa is a zone referencing all IP addresses which fall under the 192.168.1.* IP address space. As one can see, the more specific part of a hostname appears to its left. For example, example.org. is more specific than org., as org. is more specific than the root zone. The layout of each part of a hostname is much like a file system: the /dev directory falls within the root, and so on. Reasons to Run a Name Server Name servers generally come in two forms: authoritative name servers, and caching (also known as resolving) name servers. An authoritative name server is needed when: One wants to serve DNS information to the world, replying authoritatively to queries. A domain, such as example.org, is registered and IP addresses need to be assigned to hostnames under it. An IP address block requires reverse DNS entries (IP to hostname). A backup or second name server, called a slave, will reply to queries. A caching name server is needed when: A local DNS server may cache and respond more quickly than querying an outside name server. - When one queries for www.FreeBSD.org, the resolver usually - queries the uplink ISP's name server, and - retrieves the reply. With a local, caching + When one queries for + www.FreeBSD.org, the resolver + usually queries the uplink ISP's name + server, and retrieves the reply. With a local, caching DNS server, the query only has to be made once to the outside world by the caching DNS server. Additional queries will not have to go outside the local network, since the information is - cached - locally. + cached locally. How It Works In &os;, the BIND daemon is called named. File Description &man.named.8; The BIND daemon. &man.rndc.8; Name server control utility. /etc/namedb Directory where BIND zone information resides. /etc/namedb/named.conf Configuration file of the daemon. Depending on how a given zone is configured on the server, - the files related to that zone can be found in the master, slave, or dynamic subdirectories of the - /etc/namedb directory. - These files contain the DNS information - that will be given out by the name server in response to - queries. + the files related to that zone can be found in the + master, + slave, or + dynamic subdirectories + of the /etc/namedb + directory. These files contain the DNS + information that will be given out by the name server in + response to queries. Starting BIND BIND starting Since BIND is installed by default, configuring it is relatively simple. The default named configuration is that of a basic resolving name server, running in a - &man.chroot.8; environment, and restricted to listening on - the local IPv4 loopback address (127.0.0.1). - To start the server one time with - this configuration, use the following command: + &man.chroot.8; environment, and restricted to listening on the + local IPv4 loopback address (127.0.0.1). To start the server + one time with this configuration, use the following + command: &prompt.root; service named onestart To ensure the named daemon is started at boot each time, put the following line into the /etc/rc.conf: named_enable="YES" There are obviously many configuration options for /etc/namedb/named.conf that are beyond the scope of this document. There are other startup options - for named on - &os;, take a look at the - named_* flags in - /etc/defaults/rc.conf and consult the - &man.rc.conf.5; manual page. The section is also a good + for named on &os;, take a look at + the named_* + flags in /etc/defaults/rc.conf and + consult the &man.rc.conf.5; manual page. The + section is also a good read. Configuration Files BIND configuration files Configuration files for named - currently reside in /etc/namedb directory and will - need modification before use unless all that is needed is a - simple resolver. This is where most of the configuration will - be performed. + currently reside in + /etc/namedb directory + and will need modification before use unless all that is + needed is a simple resolver. This is where most of the + configuration will be performed. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Refer to the named.conf(5) and named(8) man pages, and the documentation // in /usr/share/doc/bind9 for more details. // // If you are going to set up an authoritative server, make sure you // understand the hairy details of how DNS works. Even with // simple mistakes, you can break connectivity for affected parties, // or cause huge amounts of useless Internet traffic. options { // All file and path names are relative to the chroot directory, // if any, and should be fully qualified. directory "/etc/namedb/working"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // If named is being used only as a local resolver, this is a safe default. // For named to be accessible to the network, comment this option, specify // the proper IP address, or delete this option. listen-on { 127.0.0.1; }; // If you have IPv6 enabled on this system, uncomment this option for // use as a local resolver. To give access to the network, specify // an IPv6 address, or the keyword "any". // listen-on-v6 { ::1; }; // These zones are already covered by the empty zones listed below. // If you remove the related empty zones below, comment these lines out. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. /* forwarders { 127.0.0.1; }; */ // If the 'forwarders' clause is not empty the default is to 'forward first' // which will fall back to sending a query from your local server if the name // servers in 'forwarders' do not have the answer. Alternatively you can // force your name server to never initiate queries of its own by enabling the // following line: // forward only; // If you wish to have forwarding configured automatically based on // the entries in /etc/resolv.conf, uncomment the following line and // set named_auto_forward=yes in /etc/rc.conf. You can also enable // named_auto_forward_only (the effect of which is described above). // include "/etc/namedb/auto_forward.conf"; Just as the comment says, to benefit from an uplink's cache, forwarders can be enabled here. Under normal circumstances, a name server will recursively query the Internet looking at certain name servers until it finds the answer it is looking for. Having this enabled will have it query the uplink's name server (or name server provided) first, taking advantage of its cache. If the uplink name server in question is a heavily trafficked, fast name server, enabling this may be worthwhile. 127.0.0.1 will not work here. Change this IP address to a name server at the uplink. /* Modern versions of BIND use a random UDP port for each outgoing query by default in order to dramatically reduce the possibility of cache poisoning. All users are strongly encouraged to utilize this feature, and to configure their firewalls to accommodate it. AS A LAST RESORT in order to get around a restrictive firewall policy you can try enabling the option below. Use of this option will significantly reduce your ability to withstand cache poisoning attacks, and should be avoided if at all possible. Replace NNNNN in the example with a number between 49160 and 65530. */ // query-source address * port NNNNN; }; // If you enable a local name server, don't forget to enter 127.0.0.1 // first in your /etc/resolv.conf so this server will be queried. // Also, make sure to enable it in /etc/rc.conf. // The traditional root hints mechanism. Use this, OR the slave zones below. zone "." { type hint; file "/etc/namedb/named.root"; }; /* Slaving the following zones from the root name servers has some significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots 3. Greater resilience to any potential root server failure/DDoS On the other hand, this method requires more monitoring than the hints file to be sure that an unexpected failure mode has not incapacitated your server. Name servers that are serving a lot of clients will benefit more from this approach than individual hosts. Use with caution. To use this mechanism, uncomment the entries below, and comment the hint zone above. As documented at http://dns.icann.org/services/axfr/ these zones: "." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET are available for AXFR from these servers on IPv4 and IPv6: xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org */ /* zone "." { type slave; file "/etc/namedb/slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "/etc/namedb/slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; */ /* Serving the following zones locally will prevent any queries for these zones leaving your network and going to the root name servers. This has two significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots */ // RFCs 1912 and 5735 (and BCP 32 for localhost) zone "localhost" { type master; file "/etc/namedb/master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // RFC 1912-style zone for IPv6 localhost address zone "0.ip6.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; // "This" Network (RFCs 1912 and 5735) zone "0.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Private Use Networks (RFCs 1918 and 5735) zone "10.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Link-local/APIPA (RFCs 3927 and 5735) zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IETF protocol assignments (RFCs 5735 and 5736) zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // TEST-NET-[1-3] for Documentation (RFCs 5735 and 5737) zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Range for Documentation (RFC 3849) zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Domain Names for Documentation and Testing (BCP 32) zone "test" { type master; file "/etc/namedb/master/empty.db"; }; zone "example" { type master; file "/etc/namedb/master/empty.db"; }; zone "invalid" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.com" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.net" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.org" { type master; file "/etc/namedb/master/empty.db"; }; // Router Benchmark Testing (RFCs 2544 and 5735) zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IANA Reserved - Old Class E Space (RFC 5735) zone "240.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "241.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "242.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "243.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "244.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "245.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "246.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "247.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "248.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "249.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "250.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "251.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "252.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "253.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "254.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Unassigned Addresses (RFC 4291) zone "1.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "8.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "c.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "e.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "0.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "1.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "2.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "8.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "0.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "1.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "2.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Link Local (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Deprecated Site-Local Addresses (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "e.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "f.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IP6.INT is Deprecated (RFC 4159) zone "ip6.int" { type master; file "/etc/namedb/master/empty.db"; }; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example slave zone config entries. It can be convenient to become // a slave at least for the zone your own domain is in. Ask // your network administrator for the IP address of the responsible // master name server. // // Do not forget to include the reverse lookup zone! // This is named after the first bytes of the IP address, in reverse // order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6. // // Before starting to set up a master zone, make sure you fully // understand how DNS and BIND work. There are sometimes // non-obvious pitfalls. Setting up a slave zone is usually simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. /* An example dynamic zone key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "/etc/namedb/dynamic/example.org"; }; */ /* Example of a slave reverse zone zone "1.168.192.in-addr.arpa" { type slave; file "/etc/namedb/slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ In named.conf, these are examples of slave entries for a forward and reverse zone. For each new zone served, a new zone entry must be added to named.conf. For example, the simplest zone entry for example.org can look like: zone "example.org" { type master; file "master/example.org"; }; The zone is a master, as indicated by the statement, holding its zone information in /etc/namedb/master/example.org indicated by the statement. zone "example.org" { type slave; file "slave/example.org"; }; In the slave case, the zone information is transferred from the master name server for the particular zone, and saved in the file specified. If and when the master server dies or is unreachable, the slave name server will have the transferred zone information and will be able to serve it. Zone Files BIND zone files - An example master zone file for example.org (existing within - /etc/namedb/master/example.org) is as - follows: + An example master zone file for + example.org (existing + within /etc/namedb/master/example.org) + is as follows: $TTL 3600 ; 1 hour default TTL example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 300 ; Negative Response TTL ) ; DNS Servers IN NS ns1.example.org. IN NS ns2.example.org. ; MX Records IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 ; Aliases www IN CNAME example.org. Note that every hostname ending in a . is an exact hostname, whereas everything without a trailing . is relative to the origin. For example, ns1 is translated into ns1.example.org. The format of a zone file follows: recordname IN recordtype value DNS records The most commonly used DNS records: SOA start of zone authority NS an authoritative name server A a host address CNAME the canonical name for an alias MX mail exchanger PTR a domain name pointer (used in reverse DNS) example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 300 ) ; Negative Response TTL example.org. the domain name, also the origin for this zone file. ns1.example.org. the primary/authoritative name server for this zone. admin.example.org. the responsible person for this zone, email address with @ replaced. (admin@example.org becomes admin.example.org) 2006051501 the serial number of the file. This must be incremented each time the zone file is modified. Nowadays, many admins prefer a yyyymmddrr format for the serial number. 2006051501 would mean last modified 05/15/2006, the latter 01 being the first time the zone file has been modified this day. The serial number is important as it alerts slave name servers for a zone when it is updated. IN NS ns1.example.org. This is an NS entry. Every name server that is going to reply authoritatively for the zone must have one of these entries. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 The A record indicates machine names. As seen above, ns1.example.org would resolve to 192.168.1.2. IN A 192.168.1.1 - This line assigns IP address 192.168.1.1 to the current origin, - in this case example.org. + This line assigns IP address + 192.168.1.1 to the current + origin, in this case + example.org. www IN CNAME @ The canonical name record is usually used for giving aliases to a machine. In the example, www is aliased to the master machine whose name - happens to be the same as the domain name example.org (192.168.1.1). CNAMEs can never be - used together with another kind of record - for the same hostname. + happens to be the same as the domain name + example.org + (192.168.1.1). CNAMEs can + never be used together with another kind of record for the + same hostname. MX record IN MX 10 mail.example.org. - The MX record indicates which mail - servers are responsible for handling incoming mail for the - zone. mail.example.org is the - hostname of a mail server, and 10 is the priority of - that mail server. + The MX record indicates which mail servers are + responsible for handling incoming mail for the zone. + mail.example.org is the + hostname of a mail server, and 10 is the priority of that + mail server. One can have several mail servers, with priorities of 10, 20 and so on. A mail server attempting to deliver to example.org would first try the highest priority MX (the record with the lowest priority number), then the second highest, etc, until the mail can be properly delivered. For in-addr.arpa zone files (reverse DNS), the same format is used, except with PTR entries instead of A or CNAME. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 300 ) ; Negative Response TTL IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org. This file gives the proper IP address to hostname mappings for the above fictitious domain. It is worth noting that all names on the right side of a PTR record need to be fully qualified (i.e., end in a .). Caching Name Server BIND caching name server A caching name server is a name server whose primary role is to resolve recursive queries. It simply asks queries of its own, and remembers the answers for later use. <acronym - role="Domain Name Security Extensions">DNSSEC</acronym> + role="Domain Name Security + Extensions">DNSSEC BIND DNS security extensions Domain Name System Security Extensions, or DNSSEC for short, is a suite of specifications to protect resolving name servers from forged DNS data, such as spoofed DNS records. By using digital signatures, a resolver can verify the integrity of the record. Note that DNSSEC only provides integrity via digitally signing the Resource Records (RRs). It provides neither confidentiality nor protection against false end-user assumptions. This means that it cannot protect against people going to example.net instead of example.com. The only thing DNSSEC does is authenticate that the data has not been compromised in transit. The security of DNS is an important step in securing the Internet in general. For more in-depth details of how DNSSEC works, the relevant RFCs are a good place to start. See the list in . The following sections will demonstrate how to enable DNSSEC for an authoritative DNS server and a recursive (or caching) DNS server running BIND 9. While all versions of BIND 9 support DNSSEC, it is necessary to have at least version 9.6.2 in order to be able to use the signed root zone when validating DNS queries. This is because earlier versions lack the required algorithms to enable validation using the root zone key. It is strongly recommended to use the latest version of BIND 9.7 or later to take advantage of automatic key updating for the root key, as well as other features to automatically keep zones signed and signatures up to date. Where configurations differ between 9.6.2 and 9.7 and later, differences will be pointed out. Recursive <acronym>DNS</acronym> Server Configuration Enabling DNSSEC validation of queries performed by a recursive DNS server requires a few changes to named.conf. Before making these changes the root zone key, or trust anchor, must be acquired. Currently the root zone key is not available in a file format BIND understands, so it has to be manually converted into the proper format. The key itself can be obtained by querying the root zone for it using dig. By running &prompt.user; dig +multi +noall +answer DNSKEY . > root.dnskey the key will end up in root.dnskey. The contents should look something like this: . 93910 IN DNSKEY 257 3 8 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ) ; key id = 19036 . 93910 IN DNSKEY 256 3 8 ( AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt ) ; key id = 34525 Do not be alarmed if the obtained keys differ from this example. They might have changed since these instructions were last updated. This output actually contains two keys. The first key in the listing, with the value 257 after the DNSKEY record type, is the one needed. This value indicates - that this is a Secure Entry Point (SEP), commonly known - as a Key Signing Key (KSK). The second key, - with value 256, is a subordinate key, commonly called a Zone - Signing Key (ZSK). More on the - different key types later in . + that this is a Secure Entry Point + (SEP), commonly + known as a Key Signing Key + (KSK). The second + key, with value 256, is a subordinate key, commonly called a + Zone Signing Key + (ZSK). More on + the different key types later in + . Now the key must be verified and formatted so that BIND can use it. To verify the key, generate a DS RR set. Create a - file containing these RRs with + file containing these + RRs with &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds These records use SHA-1 and SHA-256 respectively, and should look similar to the following example, where the longer is using SHA-256. . IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 The SHA-256 RR can now be compared to the digest in https://data.iana.org/root-anchors/root-anchors.xml. To be absolutely sure that the key has not been tampered with the data in the XML file can be verified using the PGP signature in https://data.iana.org/root-anchors/root-anchors.asc. Next, the key must be formatted properly. This differs a little between BIND versions 9.6.2 and 9.7 and later. In version 9.7 support was added to automatically track changes to the key and update it as necessary. This is done using managed-keys as seen in the example below. When using the older version, the key is added using a trusted-keys statement and updates must be done manually. For BIND 9.6.2 the format should look like: trusted-keys { "." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; }; For 9.7 the format will instead be: managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; }; The root key can now be added to named.conf either directly or by including a file containing the key. After these steps, configure BIND to do DNSSEC validation on queries by editing named.conf and adding the following to the options directive: dnssec-enable yes; dnssec-validation yes; To verify that it is actually working use dig to make a query for a signed zone using the resolver just configured. A successful reply will contain the AD flag to indicate the data was authenticated. Running a query such as &prompt.user; dig @resolver +dnssec se ds should return the DS RR for the .se zone. In the flags: section the AD flag should be set, as seen in: ... ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ... The resolver is now capable of authenticating DNS queries. Authoritative <acronym>DNS</acronym> Server Configuration In order to get an authoritative name server to serve a DNSSEC signed zone a little more work is required. A zone is signed using cryptographic keys which must be generated. It is possible to use only one key for this. The preferred method however is to have a strong - well-protected Key Signing Key (KSK) that is - not rotated very often and a Zone Signing Key (ZSK) that is rotated more - frequently. Information on recommended operational - practices can be found in KSK) that is + not rotated very often and a Zone Signing Key + (ZSK) that is + rotated more frequently. Information on recommended + operational practices can be found in RFC 4641: DNSSEC Operational Practices. Practices regarding the root zone can be found in DNSSEC Practice Statement for the Root Zone KSK operator and DNSSEC Practice Statement for the Root Zone - ZSK operator. The KSK is used to build a - chain of authority to the data in need of validation and as - such is also called a Secure Entry Point (SEP) key. A message - digest of this key, called a Delegation Signer (DS) record, must be - published in the parent zone to establish the trust chain. - How this is accomplished depends on the parent zone owner. - The ZSK is used to sign the - zone, and only needs to be published there. - - To enable DNSSEC for the example.com zone depicted in - previous examples, the first step is to use + ZSK operator. The + KSK is used to + build a chain of authority to the data in need of validation + and as such is also called a Secure Entry Point + (SEP) key. A + message digest of this key, called a Delegation Signer + (DS) record, + must be published in the parent zone to establish the trust + chain. How this is accomplished depends on the parent zone + owner. The ZSK + is used to sign the zone, and only needs to be published + there. + + To enable DNSSEC for the + example.com zone depicted + in previous examples, the first step is to use dnssec-keygen to generate the KSK and ZSK key pair. This key pair can utilize different cryptographic algorithms. It is recommended to use RSA/SHA256 for the keys and 2048 bits key length should be enough. To generate - the KSK for example.com, run + the KSK for + example.com, run &prompt.user; dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com and to generate the ZSK, run &prompt.user; dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com dnssec-keygen outputs two files, the public and the private keys in files named similar to Kexample.com.+005+nnnnn.key (public) and Kexample.com.+005+nnnnn.private (private). The nnnnn part of the file name is a five digit key ID. Keep track of which key ID belongs to which key. This is especially important when - having more than one key in a zone. It is - also possible to rename the keys. For each - KSK file do: + having more than one key in a zone. It is also possible to + rename the keys. For each KSK file + do: &prompt.user; mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key &prompt.user; mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private For the ZSK files, substitute KSK for ZSK as necessary. The files can now be included in the zone file, using the $include statement. It should look something like this: $include Kexample.com.+005+nnnnn.KSK.key ; KSK $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK Finally, sign the zone and tell BIND to use the signed zone file. To sign a zone dnssec-signzone is used. The - command to sign the zone example.com, located in + command to sign the zone + example.com, located in example.com.db would look similar to &prompt.user; dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key The key supplied to the argument is the KSK and the other key file is the ZSK that should be used in the signing. It is possible to supply more than one KSK and ZSK, which will result in the zone being signed with all supplied keys. This can be needed to supply zone data signed using more than one algorithm. The output of dnssec-signzone is a zone file with all RRs signed. This output will end up in a file with the extension .signed, such as - example.com.db.signed. The DS records will also be - written to a separate file - dsset-example.com. - To use this signed zone just modify the zone directive in + example.com.db.signed. The + DS records will + also be written to a separate file + dsset-example.com. To use this signed + zone just modify the zone directive in named.conf to use example.com.db.signed. By default, the signatures are only valid 30 days, meaning that the zone needs to be resigned in about 15 days to be sure that resolvers are not caching records with stale signatures. It is possible to make a script and a cron job to do this. See relevant manuals for details. Be sure to keep private keys confidential, as with all cryptographic keys. When changing a key it is best to include the new key into the zone, while still signing with the old one, and then move over to using the new key to sign. After these steps are done the old key can be removed from the zone. Failure to do this might render the DNS data unavailable for a time, until the new key has propagated through the DNS hierarchy. For more information on key rollovers and other DNSSEC operational issues, see RFC 4641: DNSSEC Operational practices. Automation Using <acronym>BIND</acronym> 9.7 or Later Beginning with BIND version 9.7 a new feature called Smart Signing was introduced. This feature aims to make the key management and signing process simpler by automating parts of the task. - By putting the keys into a directory called a key - repository, and using the new option - auto-dnssec, it is possible to create a - dynamic zone which will be resigned as needed. To update - this zone use nsupdate with the - new option . + By putting the keys into a directory called a + key repository, and using the new + option auto-dnssec, it is possible to + create a dynamic zone which will be resigned as needed. To + update this zone use nsupdate + with the new option . rndc has also grown the ability to sign zones with keys in the key repository, using the option . To tell BIND to use this automatic signing and - zone updating for example.com, add the following - to named.conf: + zone updating for + example.com, add the + following to named.conf: zone example.com { type master; key-directory "/etc/named/keys"; update-policy local; auto-dnssec maintain; file "/etc/named/dynamic/example.com.zone"; }; After making these changes, generate keys for the zone as explained in , put those keys in the key repository given as the argument to the key-directory in the zone configuration and the zone will be signed automatically. Updates to a zone configured this way must be done using nsupdate, which will take care of re-signing the zone with the new data added. For further details, see and the BIND documentation. Security Although BIND is the most common implementation of DNS, there is always the issue of security. Possible and exploitable security holes are sometimes found. While &os; automatically drops named into a &man.chroot.8; environment; there are several other security mechanisms in place which could help to lure off possible DNS service attacks. - It is always good idea to read CERT's security + It is always good idea to read + CERT's security advisories and to subscribe to the &a.security-notifications; to stay up to date with the current Internet and &os; security issues. If a problem arises, keeping sources up to date and having a fresh build of named may help. Further Reading BIND/named manual pages: &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.1; &man.dnssec-signzone.8; &man.dnssec-keygen.8; Official ISC BIND Page Official ISC BIND Forum O'Reilly DNS and BIND 5th Edition Root DNSSEC DNSSEC Trust Anchor Publication for the Root Zone RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification RFC4033 - DNS Security Introduction and Requirements RFC4034 - Resource Records for the DNS Security Extensions RFC4035 - Protocol Modifications for the DNS Security Extensions RFC4641 - DNSSEC Operational Practices RFC 5011 - Automated Updates of DNS Security (DNSSEC Trust Anchors Murray Stokely Contributed by Apache HTTP Server web servers setting up Apache Overview &os; is used to run some of the busiest web sites in the world. The majority of web servers on the Internet are using the Apache HTTP Server. Apache software packages should be included on the &os; installation media. If Apache was not installed while - installing &os;, then it can be installed from the www/apache22 port. + installing &os;, then it can be installed from the + www/apache22 port. Once Apache has been installed successfully, it must be configured. - This section covers version 2.2.X of the - Apache HTTP Server as that is the - most widely used version for &os;. For more detailed - information beyond the scope of this document about - Apache 2.X, please see . - + + This section covers version 2.2.X of the + Apache HTTP Server as that is the + most widely used version for &os;. For more detailed + information beyond the scope of this document about + Apache 2.X, please see + . + Configuration Apache configuration file The main Apache HTTP Server configuration file is installed as /usr/local/etc/apache22/httpd.conf on &os;. This file is a typical &unix; text configuration file with comment lines beginning with the # character. A comprehensive description of all possible configuration options is outside the scope of this book, so only the most frequently modified directives will be described here. ServerRoot "/usr/local" This specifies the default directory hierarchy for the Apache installation. - Binaries are stored in the bin and - sbin subdirectories - of the server root, and configuration files are stored - in bin and + sbin + subdirectories of the server root, and configuration + files are stored in etc/apache. ServerAdmin you@your.address The address to which problems with the server should be emailed. This address also appears on some server-generated pages, such as error documents. ServerName www.example.com ServerName allows an administrator to set a host name which is sent back to clients for the server. This is useful if the host is different than the one that it is configured with (i.e., use www instead of the host's real name). DocumentRoot "/usr/local/www/apache22/data" DocumentRoot: The directory where documents will be served from. By default, all requests are taken from this directory, but symbolic links and aliases may be used to point to other locations. It is always a good idea to make backup copies of the Apache configuration file before making changes. When the configuration of Apache, is complete, save the file and verify the configuration using &man.apachectl.8;. To do this, issue apachectl configtest which should return Syntax OK. Running <application>Apache</application> Apache starting or stopping The www/apache22 port installs an &man.rc.8; script to aid in starting, stopping, and restarting Apache, which can be found in /usr/local/etc/rc.d/. To launch Apache at system startup, add the following line to /etc/rc.conf: apache22_enable="YES" If Apache should be started with non-default options, the following line may be added to /etc/rc.conf: apache22_flags="" The Apache configuration can be tested for errors after making subsequent configuration changes while httpd is running. This can be done by the &man.rc.8; script directly, or by the &man.service.8; utility by issuing one of the following commands: &prompt.root; service apache22 configtest It is important to note that the configtest is not an &man.rc.8; standard, and should not be expected to work for all &man.rc.8; startup scripts. If Apache does not report configuration errors, the Apache httpd can be started with &man.service.8;: &prompt.root; service apache22 start The httpd service can be tested by entering http://localhost in a web browser, replacing localhost with the fully-qualified domain name of the machine running httpd, if it is not the local machine. The default web page that is displayed is /usr/local/www/apache22/data/index.html. - Virtual Hosting Apache supports two different types of Virtual Hosting. The first method is Name-based Virtual Hosting. Name-based virtual hosting uses the clients HTTP/1.1 headers to figure out the hostname. This allows many different domains to share the same IP address. To setup Apache to use Name-based Virtual Hosting add an entry like the following to httpd.conf: NameVirtualHost * If the webserver was named www.domain.tld and a virtual domain for www.someotherdomain.tld then add the following entries to httpd.conf: <VirtualHost *> ServerName www.domain.tld DocumentRoot /www/domain.tld </VirtualHost> <VirtualHost *> ServerName www.someotherdomain.tld DocumentRoot /www/someotherdomain.tld </VirtualHost> Replace the addresses with the addresses needed and the path to the documents with what are being used. For more information about setting up virtual hosts, please consult the official Apache documentation at: . Apache Modules Apache modules There are many different Apache modules available to add functionality to the basic server. The FreeBSD Ports Collection provides an easy way to install Apache together with some of the more popular add-on modules. <application>mod_ssl</application> - web servers - secure + + web servers + secure + SSL cryptography The mod_ssl module uses the OpenSSL library to provide strong cryptography via the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols. This module provides everything necessary to request a signed certificate from a trusted certificate signing authority to run a secure web server on &os;. The mod_ssl module is built by default, but can be enabled by specifying -DWITH_SSL at compile time. Language Bindings There are Apache modules for most major scripting languages. These modules typically make it possible to write Apache modules entirely in a scripting language. They are also often used as a persistent interpreter embedded into the server that avoids the overhead of starting an external interpreter and the startup-time penalty for dynamic websites, as described in the next section. Dynamic Websites - web servers - dynamic + + web servers + dynamic + In the last decade, more businesses have turned to the Internet in order to enhance their revenue and increase exposure. This has also increased the need for interactive web content. While some companies, such as µsoft;, have introduced solutions into their proprietary products, the open source community answered the call. Modern options for dynamic web content include Django, Ruby on Rails, mod_perl2, and mod_php. Django Python Django Django is a BSD licensed framework designed to allow developers to write high performance, elegant web applications quickly. It provides an object-relational mapper so that data types are developed as Python objects, and a rich dynamic database-access API is provided for those objects without the developer ever having to write SQL. It also provides an extensible template system so that the logic of the application is separated from the HTML presentation. Django depends on mod_python, Apache, and an SQL database engine. The &os; Port will install all of these pre-requisites with the appropriate flags. Installing Django with <application>Apache2</application>, <application>mod_python3</application>, and <application>PostgreSQL</application> &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Once Django and these pre-requisites are installed, the application will need a Django project directory along with the Apache configuration to use the embedded Python interpreter. This will be the interpreter to call the application for specific URLs on the site. Apache Configuration for Django/mod_python A line must be added to the apache httpd.conf file to configure Apache to pass requests for certain URLs to the web application: <Location "/"> SetHandler python-program PythonPath "['/dir/to/the/django/packages/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails Ruby on Rails is another open source web framework that provides a full development stack and is optimized to make web developers more productive and capable of writing powerful applications quickly. It can be installed easily from the ports system. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean <application>mod_perl2</application> mod_perl2 Perl The Apache/Perl integration project brings together the full power of the Perl programming language and the Apache HTTP Server. With the mod_perl2 module it is possible to write Apache modules entirely in Perl. In addition, the persistent interpreter embedded in the server avoids the overhead of starting an external interpreter and the penalty of Perl start-up time. mod_perl2 is available in the www/mod_perl2 port. Tom Rhodes Written by <application>mod_php</application> mod_php PHP PHP, also known as PHP: Hypertext Preprocessor is a general-purpose scripting language that is especially suited for Web development. Capable of being embedded into HTML its syntax draws upon C, &java;, and Perl with the intention of allowing web developers to write dynamically generated webpages quickly. To gain support for PHP5 for the Apache web server, begin by installing the lang/php5 port. If the lang/php5 port is being installed for the first time, available OPTIONS will be displayed automatically. If a menu is not displayed, i.e., because the lang/php5 port has been installed some time in the past, it is always possible to bring the options dialog up again by running: &prompt.root; make config in the port directory. In the options dialog, check the APACHE option to build mod_php5 as a loadable module for the Apache web server. A lot of sites are still using PHP4 for various reasons (i.e., compatibility issues or already deployed web applications). If the mod_php4 is needed instead of mod_php5, then please use the lang/php4 port. The lang/php4 port supports many of the configuration and build-time options of the lang/php5 port. This will install and configure the modules required to support dynamic PHP applications. Check to ensure the following sections have been added to /usr/local/etc/apache22/httpd.conf: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Once completed, a simple call to the apachectl command for a graceful restart is needed to load the PHP module: &prompt.root; apachectl graceful For future upgrades of PHP, the make config command will not be required; the selected OPTIONS are saved automatically by the &os; Ports framework. The PHP support in &os; is extremely modular so the base install is very limited. It is very - easy to add support using the lang/php5-extensions port. - This port provides a menu driven interface to + easy to add support using the + lang/php5-extensions + port. This port provides a menu driven interface to PHP extension installation. Alternatively, individual extensions can be installed using the appropriate port. For instance, to add support for the MySQL database server to PHP5, simply install the port databases/php5-mysql. After installing an extension, the Apache server must be reloaded to pick up the new configuration changes: &prompt.root; apachectl graceful Murray Stokely Contributed by File Transfer Protocol (FTP) FTP servers Overview The File Transfer Protocol (FTP) provides users with a - simple way to transfer files to and from an FTP server. &os; - includes FTP - server software, ftpd, in the base - system. This makes setting up and administering an FTP server on FreeBSD - very straightforward. + simple way to transfer files to and from an + FTP server. + &os; includes + FTP server + software, ftpd, in the base system. + This makes setting up and administering an + FTP server on + FreeBSD very straightforward. Configuration The most important configuration step is deciding which accounts will be allowed access to the FTP server. A normal &os; system has a number of system accounts used for various daemons, but unknown users should not be allowed to log in with these accounts. The /etc/ftpusers file is a list of users disallowed any FTP access. By default, it includes the aforementioned system accounts, but it is possible to add specific users here that should not be allowed access to FTP. In some cases it may be desirable to restrict the access of some users without preventing them completely from using FTP. This can be accomplished with the /etc/ftpchroot file. This file lists users and groups subject to FTP access restrictions. The &man.ftpchroot.5; manual page has all of the details so it will not be described in detail here. FTP anonymous - To enable anonymous FTP access to the - server, create a user named - ftp on the &os; system. Users will then - be able to log on to the FTP server with a username of - ftp or anonymous and - with any password (by convention an email address for the user - should be used as the password). The FTP server will call - &man.chroot.2; when an anonymous user logs in, to restrict - access to only the home directory of the + To enable anonymous FTP access to the server, create a + user named ftp on the &os; system. Users + will then be able to log on to the FTP server with a username + of ftp or anonymous + and with any password (by convention an email address for the + user should be used as the password). The FTP server will + call &man.chroot.2; when an anonymous user logs in, to + restrict access to only the home directory of the ftp user. There are two text files that specify welcome messages to be displayed to FTP clients. The contents of the file /etc/ftpwelcome will be displayed to users before they reach the login prompt. After a successful login, the contents of the file /etc/ftpmotd will be displayed. Note that the path to this file is relative to the login environment, so the file ~ftp/etc/ftpmotd would be displayed for anonymous users. Once the FTP server has been configured properly, it must be enabled in /etc/inetd.conf. All that is required here is to remove the comment symbol # from in front of the existing ftpd line : ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l As explained in , the inetd configuration must be reloaded after this configuration file is changed. Please refer to for details on enabling inetd on the system. Alternatively, ftpd can also be started as a stand-alone server. In this case, it is sufficient to set the appropriate variable in /etc/rc.conf: ftpd_enable="YES" After setting the above variable, the stand-alone server will be started at the next reboot, or it can be started manually by executing the following command as root: &prompt.root; service ftpd start You can now log on to the FTP server by typing: &prompt.user; ftp localhost Maintaining syslog log files FTP The ftpd daemon uses &man.syslog.3; to log messages. By default, the system log daemon will put messages related to FTP in the /var/log/xferlog file. The location of the FTP log can be modified by changing the following line in /etc/syslog.conf: ftp.info /var/log/xferlog FTP anonymous Be aware of the potential problems involved with running - an anonymous FTP server. In particular, think - twice about allowing anonymous users to upload files. It may - turn out that the FTP site becomes a forum for the trade of - unlicensed commercial software or worse. If anonymous - FTP uploads are required, then verify the - permissions so that these files can not be read by other - anonymous users until they have been reviewed by an - administrator. - + an anonymous FTP server. In particular, think twice about + allowing anonymous users to upload files. It may turn out + that the FTP site becomes a forum for the trade of unlicensed + commercial software or worse. If anonymous FTP uploads are + required, then verify the permissions so that these files can + not be read by other anonymous users until they have been + reviewed by an administrator. Murray Stokely Contributed by File and Print Services for µsoft.windows; Clients (Samba) Samba server Microsoft Windows file server Windows clients print server Windows clients Overview Samba is a popular open source software package that provides file and print services for µsoft.windows; clients. Such clients can connect to and use &os; filespace as if it was a local disk drive, or &os; printers as if they were local printers. Samba software packages should be included on the &os; installation media. If they were not installed when first installing &os;, then they may be installed from the net/samba34 port or package. - Configuration A default Samba configuration file is installed as /usr/local/share/examples/samba34/smb.conf.default. This file must be copied to /usr/local/etc/smb.conf and customized before Samba can be used. The smb.conf file contains runtime configuration information for Samba, such as definitions of the printers and file system shares that will be shared with &windows; clients. The Samba package includes a web based tool called swat which provides a simple way of configuring the smb.conf file. Using the Samba Web Administration Tool (SWAT) The Samba Web Administration Tool (SWAT) runs as a daemon from inetd. Therefore, inetd must be enabled as shown in - , and - the following line in /etc/inetd.conf - should be uncommented before swat - can be used to configure - Samba: + , and the following line in + /etc/inetd.conf should be uncommented + before swat can be used to + configure Samba: swat stream tcp nowait/400 root /usr/local/sbin/swat swat As explained in , the inetd configuration must be reloaded after this configuration file is changed. Once swat has been enabled in inetd.conf, a web browser may be used to connect to . At first login, the system root account must be used. Once successfully logging on to the main Samba configuration page, the system documentation will be available, or configuration may - begin by clicking on the - Globals tab. The - Globals section corresponds to the + begin by clicking on the Globals tab. + The Globals section corresponds to the variables that are set in the [global] section of /usr/local/etc/smb.conf. Global Settings Whether swat is being used or /usr/local/etc/smb.conf is being edited - directly, the first directives encountered - when configuring Samba - are: + directly, the first directives encountered when configuring + Samba are: workgroup NT Domain-Name or Workgroup-Name for the computers that will be accessing this server. netbios name This sets the NetBIOS name by which a Samba server is known. By default it is the same as the first component of the host's DNS name. server string This sets the string that will be displayed with the net view command and some other networking tools that seek to display descriptive text about the server. Security Settings Two of the most important settings in /usr/local/etc/smb.conf are the security model chosen, and the backend password format for client users. The following directives control these options: security The two most common options here are security = share and security = user. If the clients use usernames that are the same as their usernames on the &os; machine then user level security should be used. This is the default security policy and it requires clients to first log on before they can access shared resources. In share level security, clients do not need to log onto the server with a valid username and password before attempting to connect to a shared resource. This was the default security model for older versions of Samba. passdb backend NIS+ LDAP SQL database Samba has several different backend authentication models. Clients may be authenticated with LDAP, NIS+, an SQL database, or a modified password file. The default authentication method is smbpasswd, and that is all that will be covered here. Assuming that the default smbpasswd backend is used, the /usr/local/etc/samba/smbpasswd file must be created to allow Samba to - authenticate clients. To provide - the &unix; user accounts access from &windows; clients, use - the following command: + authenticate clients. To provide the &unix; user accounts + access from &windows; clients, use the following + command: &prompt.root; smbpasswd -a username The recommended backend is now tdbsam, and the following command should be used to add user accounts: &prompt.root; pdbedit username Please see the Official Samba HOWTO for additional information about configuration options. With the basics outlined here, the minimal required start running Samba will be explained. Other documentation should be consulted in addition to the information here. Starting <application>Samba</application> The net/samba34 port adds a new startup script, which can be used to control Samba. To enable this script, so that it can be used for example to start, stop or restart Samba, add the following line to the /etc/rc.conf file: samba_enable="YES" Or, for fine grain control: nmbd_enable="YES" smbd_enable="YES" This will also configure Samba to automatically start at system boot time. It is possible then to start Samba at any time by typing: &prompt.root; service samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Please refer to for more information about using rc scripts. Samba actually consists of three separate daemons. Notice that both the nmbd and smbd daemons are started by the samba script. If winbind, name resolution services were enabled in smb.conf, the winbindd daemon will be started as well. Samba may be stopped at any time by typing: &prompt.root; service samba stop Samba is a complex software suite with functionality that allows broad integration with µsoft.windows; networks. For more information about functionality beyond the basic installation described here, please see . Tom Hukins Contributed by Clock Synchronization with NTP NTP Overview Over time, a computer's clock is prone to drift. The Network Time Protocol (NTP) is one way to ensure the clock stays accurate. Many Internet services rely on, or greatly benefit from, computers' clocks being accurate. For example, a web server may receive requests to send a file if it has been modified since a certain time. In a local area network environment, it is essential that computers sharing files from the same file server have synchronized clocks so that file timestamps stay consistent. Services such as &man.cron.8; also rely on an accurate system clock to run commands at the specified times. NTP ntpd - &os; ships with the &man.ntpd.8; NTP server which can - be used to query other NTP servers to set - the clock on the machine or provide time - services to others. + &os; ships with the &man.ntpd.8; + NTP server + which can be used to query other + NTP servers to + set the clock on the machine or provide time services to + others. Choosing Appropriate NTP Servers NTP choosing servers In order to synchronize the clock, one or more NTP servers must be defined. The network administrator or ISP may have set up an NTP server for this purpose—check their documentation to see if this is the case. There is an online list of publicly accessible NTP servers which may be referenced to find an NTP server nearest to the system. Take care to review the policy for any chosen servers, and ask for permission if required. Choosing several unconnected NTP servers is a good idea in case one of the servers being used becomes unreachable or its clock is unreliable. &man.ntpd.8; uses the responses it receives from other servers intelligently—it will favor unreliable servers less than reliable ones. Configuring The Machine NTP configuration Basic Configuration ntpdate - To synchronize the clock only when the - machine boots up, use &man.ntpdate.8;. This may be - appropriate for some desktop machines which are frequently - rebooted and only require infrequent synchronization, but - most machines should run &man.ntpd.8;. + To synchronize the clock only when the machine boots up, + use &man.ntpdate.8;. This may be appropriate for some + desktop machines which are frequently rebooted and only + require infrequent synchronization, but most machines should + run &man.ntpd.8;. Using &man.ntpdate.8; at boot time is also a good idea for machines that run &man.ntpd.8;. The &man.ntpd.8; program changes the clock gradually, whereas &man.ntpdate.8; sets the clock, no matter how great the difference between a machine's current clock setting and the correct time. To enable &man.ntpdate.8; at boot time, add ntpdate_enable="YES" to - /etc/rc.conf. Also - specify all synchronization servers and any - flags to be passed to &man.ntpdate.8; in - ntpdate_flags. + /etc/rc.conf. Also specify all + synchronization servers and any flags to be passed to + &man.ntpdate.8; in ntpdate_flags. General Configuration NTP ntp.conf NTP is configured by the /etc/ntp.conf file in the format described in &man.ntp.conf.5;. Here is a simple example: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift The server option specifies which servers are to be used, with one server listed on each line. If a server is specified with the prefer - argument, as with ntplocal.example.com, that server is - preferred over other servers. A response from a preferred - server will be discarded if it differs significantly from - other servers' responses, otherwise it will be used without - any consideration to other responses. The - prefer argument is normally used for NTP - servers that are known to be highly accurate, such as those - with special time monitoring hardware. + argument, as with + ntplocal.example.com, that + server is preferred over other servers. A response from a + preferred server will be discarded if it differs + significantly from other servers' responses, otherwise it + will be used without any consideration to other responses. + The prefer argument is normally used for + NTP servers that are known to be highly accurate, such as + those with special time monitoring hardware. The driftfile option specifies which file is used to store the system clock's frequency offset. The &man.ntpd.8; program uses this to automatically compensate for the clock's natural drift, allowing it to maintain a reasonably correct setting even if it is cut off from all external time sources for a period of time. The driftfile option specifies which file is used to store information about previous responses from the NTP servers being used. This file contains internal information for NTP. It should not be modified by any other process. Controlling Access to Your Server By default, the NTP server will be accessible to all hosts on the Internet. The restrict option in /etc/ntp.conf controls which machines can access the server. To deny all machines from accessing the NTP server, add the following line to /etc/ntp.conf: restrict default ignore This will also prevent access from the server to any servers listed in the local configuration. If there is a need to synchronise the NTP server with an external NTP server, allow only that specific server. See the &man.ntp.conf.5; manual for more information. - To allow machines within the - network to synchronize their clocks with the server, but - ensure they are not allowed to configure the server or used - as peers to synchronize against, add + To allow machines within the network to synchronize + their clocks with the server, but ensure they are not + allowed to configure the server or used as peers to + synchronize against, add restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap - instead, where 192.168.1.0 is an IP address on - the network and 255.255.255.0 is the network's - netmask. + instead, where + 192.168.1.0 is an IP address + on the network and + 255.255.255.0 is the + network's netmask. The /etc/ntp.conf file can contain multiple restrict options. For more details, see the Access Control Support subsection of &man.ntp.conf.5;. Running the NTP Server To ensure the NTP server is started at boot time, add the line ntpd_enable="YES" to /etc/rc.conf. To pass additional flags to &man.ntpd.8;, edit the ntpd_flags parameter in /etc/rc.conf. To start the server without rebooting the machine, run ntpd being sure to specify any additional parameters from ntpd_flags in /etc/rc.conf. For example: &prompt.root; ntpd -p /var/run/ntpd.pid Using <application>ntpd</application> with a Temporary Internet Connection The &man.ntpd.8; program does not need a permanent connection to the Internet to function properly. However, if there is a temporary connection that is configured to dial out on demand, it is a good idea to prevent NTP traffic from triggering a dial out or keeping the connection alive. PPP users can use the filter directives in /etc/ppp/ppp.conf. For example: set filter dial 0 deny udp src eq 123 # Prevent NTP traffic from initiating dial out set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Prevent incoming NTP traffic from keeping the connection open set filter alive 1 deny udp dst eq 123 # Prevent outgoing NTP traffic from keeping the connection open set filter alive 2 permit 0/0 0/0 - For more details see the PACKET - FILTERING section in &man.ppp.8; and the examples - in /usr/share/examples/ppp/. + For more details see the + PACKET FILTERING section in &man.ppp.8; and + the examples in + /usr/share/examples/ppp/. Some Internet access providers block low-numbered ports, preventing NTP from functioning since replies never reach the machine. Further Information Documentation for the NTP server can be found in /usr/share/doc/ntp/ in HTML format. Tom Rhodes Contributed by Remote Host Logging with <command>syslogd</command> Interacting with system logs is a crucial aspect of both security and system administration. Monitoring the log files of multiple hosts can get very unwieldy when these hosts are distributed across medium or large networks, or when they are parts of various different types of networks. In these cases, configuring remote logging may make the whole process a lot more comfortable. Centralized logging to a specific logging host can reduce some of the administrative burden of log file administration. Log file aggregation, merging and rotation may be configured in one location, using the native tools of &os;, such as &man.syslogd.8; and &man.newsyslog.8;. In the following example - configuration, host A, named logserv.example.com, will collect + configuration, host A, named + logserv.example.com, will collect logging information for the local network. Host - B, named logclient.example.com will pass + B, named + logclient.example.com will pass logging information to the server system. In live configurations, both hosts require proper forward and reverse DNS or entries in /etc/hosts. Otherwise, data will be rejected by the server. Log Server Configuration Log servers are machines configured to accept logging information from remote hosts. In most cases this is to ease configuration, in other cases it may just be a better administration move. Regardless of reason, there are a few requirements before continuing. A properly configured logging server has met the following minimal requirements: The firewall ruleset allows for UDP to be passed on port 514 on both the client and server; syslogd has been configured to accept remote messages from client machines; The syslogd server and all client machines must have valid entries for both forward and reverse DNS, or be properly configured in /etc/hosts. To configure the log server, the client must be listed in /etc/syslog.conf, and the logging facility must be specified: +logclient.example.com *.* /var/log/logclient.log More information on various supported and available facilities may be found in the &man.syslog.conf.5; manual page. Once added, all facility messages will be logged to the file specified previously, /var/log/logclient.log. The server machine must also have the following listing placed inside /etc/rc.conf: syslogd_enable="YES" syslogd_flags="-a logclient.example.com -v -v" The first option will enable the syslogd daemon on boot up, and the second option allows data from the specified client to be accepted on this server. The latter part, using , will increase the verbosity of logged messages. This is extremely useful for tweaking facilities as administrators are able to see what type of messages are being logged under which facility. Multiple options may be specified to allow logging from multiple clients. IP addresses and whole netblocks may also be specified, see the &man.syslog.3; manual page for a full list of possible options. Finally, the log file should be created. The method used does not matter, but &man.touch.1; works great for situations such as this: &prompt.root; touch /var/log/logclient.log At this point, the syslogd daemon should be restarted and verified: &prompt.root; service syslogd restart &prompt.root; pgrep syslog If a PID is returned, the server has been restarted successfully, and client configuration may begin. If the server has not restarted, consult the /var/log/messages log for any output. Log Client Configuration A logging client is a machine which sends log information to a logging server in addition to keeping local copies. Similar to log servers, clients must also meet a few minimum requirements: &man.syslogd.8; must be configured to send messages of specific types to a log server, which must accept them; The firewall must allow UDP packets through on port 514; Both forward and reverse DNS must be configured or have proper entries in the /etc/hosts. Client configuration is a bit more relaxed when compared to that of the servers. The client machine must have the following listing placed inside /etc/rc.conf: syslogd_enable="YES" syslogd_flags="-s -v -v" As before, these entries will enable the syslogd daemon on boot up, and increases the verbosity of logged messages. The option prevents logs from being accepted by this client from other hosts. Facilities describe the system part for which a message is generated. For an example, ftp and ipfw are both facilities. When log messages are generated for those two services, they will normally include those two utilities in any log messages. Facilities are accompanied with a priority or level, which is used to mark how important a log message is. The most common will be the warning and info. Please refer to the &man.syslog.3; manual page for a full list of available facilities and priorities. The logging server must be defined in the client's /etc/syslog.conf. In this instance, the @ symbol is used to send logging data to a remote server and would look similar to the following entry: *.* @logserv.example.com Once added, syslogd must be restarted for the changes to take effect: &prompt.root; service syslogd restart To test that log messages are being sent across the network, use &man.logger.1; on the client to send a message to syslogd: &prompt.root; logger "Test message from logclient" This message should now exist both in /var/log/messages on the client, and /var/log/logclient.log on the log server. Debugging Log Servers In certain cases, debugging may be required if messages are not being received on the log server. There are several reasons this may occur; however, the most common two are network connection issues and DNS issues. To test these cases, ensure both hosts are able to reach one another using the hostname specified in /etc/rc.conf. If this appears to be working properly, an alternation to the syslogd_flags option in /etc/rc.conf will be required. In the following example, /var/log/logclient.log is empty, and the /var/log/messages files indicate no reason for the failure. To increase debugging output, change the syslogd_flags option to look like the following example, and issue a restart: syslogd_flags="-d -a logclien.example.com -v -v" &prompt.root; service syslogd restart Debugging data similar to the following will flash on the screen immediately after the restart: logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; rejected in rule 0 due to name mismatch. It appears obvious the messages are being rejected due to a name mismatch. After reviewing the configuration bit by bit, it appears a typo in the following /etc/rc.conf line has an issue: syslogd_flags="-d -a logclien.example.com -v -v" The line should contain logclient, not logclien. After the proper alterations are made, a restart is issued with expected results: &prompt.root; service syslogd restart logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from logserv.example.com, msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; accepted in rule 0. logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2 Logging to FILE /var/log/logclient.log Logging to FILE /var/log/messages At this point, the messages are being properly received and placed in the correct file. Security Considerations As with any network service, security requirements should be considered before implementing this configuration. At times, log files may contain sensitive data about services enabled on the local host, user accounts, and configuration data. Network data sent from the client to the server will not be encrypted nor password protected. If a need for encryption exists, it might be possible to use security/stunnel, which will transmit data over an encrypted tunnel. Local security is also an issue. Log files are not encrypted during use or after log rotation. Local users may access these files to gain additional insight on system configuration. In those cases, setting proper permissions on these files will be critical. The &man.newsyslog.8; utility supports setting permissions on newly created and rotated log files. Setting log files to mode 600 should prevent any unwanted snooping by local users. diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.xml b/en_US.ISO8859-1/books/handbook/security/chapter.xml index 3c47c57dbe..9aecee43a6 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.xml @@ -1,3830 +1,3828 @@ Matthew Dillon Much of this chapter has been taken from the security(7) manual page by Security security Synopsis This chapter provides a basic introduction to system security concepts, some general good rules of thumb, and some advanced topics under &os;. Many of the topics covered here can be applied to system and Internet security in general. Securing a system is imperative to protect data, intellectual property, time, and much more from the hands of hackers and the like. &os; provides an array of utilities and mechanisms to protect the integrity and security of the system and network. After reading this chapter, you will know: Basic &os; system security concepts. The various crypt mechanisms available in &os;. How to set up one-time password authentication. How to configure TCP Wrappers for use with &man.inetd.8;. How to set up Kerberos on &os;. How to configure IPsec and create a VPN. How to configure and use OpenSSH on &os;. How to use filesystem ACLs. How to use portaudit to audit third party software packages installed from the Ports Collection. How to utilize &os; security advisories. What Process Accounting is and how to enable it on &os;. Understand the resource limits database and how to utilize it to control user resources. Before reading this chapter, you should: Understand basic &os; and Internet concepts. Additional security topics are covered elsewhere in this Handbook. For example, Mandatory Access Control is discussed in and Internet firewalls are discussed in . Introduction Security is a function that begins and ends with the system administrator. While &os; provides some inherent security, the job of configuring and maintaining additional security mechanisms is probably one of the single largest undertakings of the sysadmin. System security also pertains to dealing with various forms of attack, including attacks that attempt to crash, or otherwise make a system unusable, but do not attempt to compromise the root account. Security concerns can be split up into several categories: Denial of service attacks. User account compromises. Root compromise through accessible services. Root compromise via user accounts. Backdoor creation. DoS attacks Denial of Service (DoS) security DoS attacks Denial of Service (DoS) Denial of Service (DoS) A Denial of Service DoS attack is an action that deprives the machine of needed resources. Typically, DoS attacks are brute-force mechanisms that attempt to crash or otherwise make a machine unusable by overwhelming its services or network stack. Attacks on servers can often be fixed by properly specifying options to limit the load the servers incur on the system under adverse conditions. Brute-force network attacks are harder to deal with. This type of attack may not be able to take the machine down, but it can saturate the Internet connection. security account compromises A user account compromise is more common than a DoS attack. Many sysadmins still run unencrypted services, meaning that users logging into the system from a remote location are vulnerable to having their password sniffed. The attentive sysadmin analyzes the remote access logs looking for suspicious source addresses and suspicious logins. In a well secured and maintained system, access to a user account does not necessarily give the attacker access to root. Without root access, the attacker cannot generally hide his tracks and may, at best, be able to do nothing more than mess with the user's files or crash the machine. User account compromises are common because users tend not to take the precautions that sysadmins take. security backdoors There are potentially many ways to break root: the attacker may know the root password, the attacker may exploit a bug in a service which runs as root, or the attacker may know of a bug in a SUID-root program. An attacker may utilize a program known as a backdoor to search for vulnerable systems, take advantage of unpatched exploits to access a system, and hide traces of illegal activity. Security remedies should always be implemented with a multi-layered onion peel approach and can be categorized as follows: Secure root and staff accounts. Secure root–run servers and SUID/SGID binaries. Secure user accounts. Secure the password file. Secure the kernel core, raw devices, and filesystems. Quick detection of inappropriate changes made to the system. Paranoia. The next section covers these items in greater depth. Securing &os; security securing &os; This section describes methods for securing a &os; system against the attacks that were mentioned in the previous section. Securing the <username>root</username> Account &man.su.1; Most systems have a password assigned to the root account. Assume that this password is always at risk of being compromised. This does not mean that the password should be disabled as the password is almost always necessary for console access to the machine. However, it should not be possible to use this password outside of the console or possibly even with &man.su.1;. For example, setting the entries in /etc/ttys to insecure prevents root logins to the specified terminals. In &os;, root logins using &man.ssh.1; are disabled by default as PermitRootLogin is set to no in /etc/ssh/sshd_config. Consider every access method as services such as FTP often fall through the cracks. Direct root logins should only be allowed via the system console. wheel Since a sysadmin needs access to root, additional password verification should be configured. One method is to add appropriate user accounts to wheel in /etc/group. Members of wheel are allowed to &man.su.1; to root. Only those users who actually need to have root access should be placed in wheel. When using Kerberos for authentication, create a .k5login in the home directory of root to allow &man.ksu.1; to be used without having to place anyone in wheel. To lock an account completely, use &man.pw.8;: &prompt.root; pw lock staff This will prevent the specified user from logging in using any mechanism, including &man.ssh.1;. Another method of blocking access to accounts would be to replace the encrypted password with a single * character. This character would never match the encrypted password and thus blocks user access. For example, the entry for the following account: foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh could be changed to this using &man.vipw.8;: foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh This prevents foobar from logging in using conventional methods. This method for access restriction is flawed on sites using Kerberos or in situations where the user has set up keys with &man.ssh.1;. These security mechanisms assume that users are logging in from a more restrictive server to a less restrictive server. For example, if the server is running network services, the workstation should not be running any. In order for a workstation to be reasonably secure, run zero or as few services as possible and run a password-protected screensaver. Of course, given physical access to any system, an attacker can break any sort of security. Fortunately, many break-ins occur remotely, over a network, from people who do not have physical access to the system. Using Kerberos provides the ability to disable or change the password for a user in one place, and have it immediately affect all the machines on which the user has an account. If an account is compromised, the ability to instantly change the associated password on all machines should not be underrated. Additional restrictions can be imposed with Kerberos: a Kerberos ticket can be configured to timeout and the Kerberos system can require that the user choose a new password after a configurable period of time. Securing Root-run Servers and SUID/SGID Binaries sandboxes &man.sshd.8; The prudent sysadmin only enables required services and is aware that third party servers are often the most bug-prone. Never run a server that has not been checked out carefully. Think twice before running any service as root as many daemons can be run as a separate service account or can be started in a sandbox. Do not activate insecure services such as &man.telnetd.8; or &man.rlogind.8;. Another potential security hole is SUID-root and SGID binaries. Most of these binaries, such as &man.rlogin.1;, reside in /bin, /sbin, /usr/bin, or /usr/sbin. While nothing is 100% safe, the system-default SUID and SGID binaries can be considered reasonably safe. It is recommended to restrict SUID binaries to a special group that only staff can access, and to delete any unused SUID binaries. SGID binaries can be almost as dangerous. If an intruder can break an SGID-kmem binary, the intruder might be able to read /dev/kmem and thus read the encrypted password file, potentially compromising user accounts. Alternatively, an intruder who breaks group kmem can monitor keystrokes sent through ptys, including ptys used by users who login through secure methods. An intruder that breaks the tty group can write to almost any user's tty. If a user is running a terminal program or emulator with a keyboard-simulation feature, the intruder can potentially generate a data stream that causes the user's terminal to echo a command, which is then run as that user. Securing User Accounts User accounts are usually the most difficult to secure. Be vigilant in the monitoring of user accounts. Use of &man.ssh.1; and Kerberos for user accounts requires extra administration and technical support, but provides a good solution compared to an encrypted password file. Securing the Password File The only sure fire way is to star out as many passwords as possible and use &man.ssh.1; or Kerberos for access to those accounts. Even though the encrypted password file (/etc/spwd.db) can only be read by root, it may be possible for an intruder to obtain read access to that file even if the attacker cannot obtain root-write access. Security scripts should be used to check for and report changes to the password file as described in the Checking file integrity section. Securing the Kernel Core, Raw Devices, and Filesystems Most modern kernels have a packet sniffing device driver built in. Under &os; it is called bpf. This device is needed for DHCP, but can be removed in the custom kernel configuration file of systems that do not provide or use DHCP. &man.sysctl.8; Even if bpf is disabled, /dev/mem and /dev/kmem are still problematic. An intruder can still write to raw disk devices. An enterprising intruder can use &man.kldload.8; to install his own bpf, or another sniffing device, on a running kernel. To avoid these problems, run the kernel at a higher security level, at least security level 1. The security level of the kernel can be set in a variety of ways. The simplest way of raising the security level of a running kernel is to set kern.securelevel: &prompt.root; sysctl kern.securelevel=1 By default, the &os; kernel boots with a security level of -1. This is called insecure mode because immutable file flags may be turned off and all devices may be read from or written to. The security level will remain at -1 unless it is altered, either by the administrator or by &man.init.8;, because of a setting in the startup scripts. The security level may be raised during system startup by setting kern_securelevel_enable to YES in /etc/rc.conf, and the value of kern_securelevel to the desired security level. Once the security level is set to 1 or a higher value, the append-only and immutable files are honored, they cannot be turned off, and access to raw devices is denied. Higher levels restrict even more operations. For a full description of the effect of various security levels, refer to &man.security.7; and &man.init.8;. Bumping the security level to 1 or higher may cause a few problems to &xorg;, as access to /dev/io will be blocked, or to the installation of &os; built from source as installworld needs to temporarily reset the append-only and immutable flags of some files. In the case of &xorg;, it may be possible to work around this by starting &man.xdm.1; early in the boot process, when the security level is still low enough. Workarounds may not be possible for all secure levels or for all the potential restrictions they enforce. A bit of forward planning is a good idea. Understanding the restrictions imposed by each security level is important as they severely diminish the ease of system use. It will also make choosing a default setting much simpler and prevent any surprises. If the kernel's security level is raised to 1 or a higher value, it may be useful to set the schg flag on critical startup binaries, directories, script files, and everything that gets run up to the point where the security level is set. A less strict compromise is to run the system at a higher security level but skip setting the schg flag. Another possibility is to mount / and /usr read-only. It should be noted that being too draconian about what is permitted may prevent detection of an intrusion. Checking File Integrity One can only protect the core system configuration and control files so much before the convenience factor rears its ugly head. For example, using &man.chflags.1; to set the schg bit on most of the files in / and /usr is probably counterproductive, because while it may protect the files, it also closes an intrusion detection window. Security measures are useless or, worse, present a false sense of security, if potential intrusions cannot be detected. Half the job of security is to slow down, not stop, an attacker, in order to catch him in the act. The best way to detect an intrusion is to look for modified, missing, or unexpected files. The best way to look for modified files is from another, often centralized, limited-access system. Writing security scripts on the extra-security limited-access system makes them mostly invisible to potential attackers. In order to take maximum advantage, the limited-access box needs significant access to the other machines, usually either through a read-only NFS export or by setting up &man.ssh.1; key-pairs. Except for its network traffic, NFS is the least visible method, allowing the administrator to monitor the filesystems on each client box virtually undetected. If a limited-access server is connected to the client boxes through a switch, the NFS method is often the better choice. If a limited-access server is connected to the client boxes through several layers of routing, the NFS method may be too insecure and &man.ssh.1; may be the better choice. Once a limited-access box has been given at least read access to the client systems it is supposed to monitor, create the monitoring scripts. Given an NFS mount, write scripts out of simple system utilities such as &man.find.1; and &man.md5.1;. It is best to physically &man.md5.1; the client system's files at least once a day, and to test control files such as those found in /etc and /usr/local/etc even more often. When mismatches are found, relative to the base md5 information the limited-access machine knows is valid, it should alert the sysadmin. A good security script will also check for inappropriate SUID binaries and for new or deleted files on system partitions such as / and /usr. When using &man.ssh.1; rather than NFS, writing the security script is more difficult. For example, &man.scp.1; is needed to send the scripts to the client box in order to run them. The &man.ssh.1; client on the client box may already be compromised. Using &man.ssh.1; may be necessary when running over insecure links, but it is harder to deal with. A good security script will also check for changes to hidden configuration files, such as .rhosts and .ssh/authorized_keys, as these files might fall outside the purview of the MD5 check. For a large amount of user disk space, it may take too long to run through every file on those partitions. In this case, consider setting mount flags to disallow SUID binaries by using nosuid with &man.mount.8;. Scan these partitions at least once a week, since the objective is to detect a break-in attempt, whether or not the attempt succeeds. Process accounting (see &man.accton.8;) is a relatively low-overhead feature of &os; which might help as a post-break-in evaluation mechanism. It is especially useful in tracking down how an intruder broke into a system, assuming the file is still intact after the break-in has occurred. Finally, security scripts should process the log files, and the logs themselves should be generated in as secure a manner as possible and sent to a remote syslog server. An intruder will try to cover his tracks, and log files are critical to the sysadmin trying to track down the time and method of the initial break-in. One way to keep a permanent record of the log files is to run the system console to a serial port and collect the information to a secure machine monitoring the consoles. Paranoia A little paranoia never hurts. As a rule, a sysadmin can add any number of security features which do not affect convenience and can add security features that do affect convenience with some added thought. More importantly, a security administrator should mix it up a bit. If recommendations, such as those mentioned in this section, are applied verbatim, those methodologies are given to the prospective attacker who also has access to this document. Denial of Service Attacks Denial of Service (DoS) A DoS attack is typically a packet attack. While there is not much one can do about spoofed packet attacks that saturate a network, one can generally limit the damage by ensuring that the attack cannot take down servers by: Limiting server forks. Limiting springboard attacks such as ICMP response attacks and ping broadcasts. Overloading the kernel route cache. A common DoS attack scenario is to force a forking server to spawn so many child processes that the host system eventually runs out of memory and file descriptors, and then grinds to a halt. There are several options to &man.inetd.8; to limit this sort of attack. It should be noted that while it is possible to prevent a machine from going down, it is not generally possible to prevent a service from being disrupted by the attack. Read &man.inetd.8; carefully and pay specific attention to , , and . Spoofed IP attacks will circumvent to &man.inetd.8;, so typically a combination of options must be used. Some standalone servers have self-fork-limitation parameters. Sendmail provides , which tends to work better than trying to use Sendmail's load limiting options due to the load lag. Specify a MaxDaemonChildren when starting Sendmail which is high enough to handle the expected load, but not so high that the computer cannot handle that number of Sendmail instances. It is prudent to run Sendmail in queued mode using and to run the daemon (sendmail -bd) separate from the queue-runs (sendmail -q15m). For real-time delivery, run the queue at a much lower interval, such as , but be sure to specify a reasonable MaxDaemonChildren to prevent cascade failures. &man.syslogd.8; can be attacked directly and it is strongly recommended to use whenever possible, and otherwise. Be careful with connect-back services such as reverse-identd, which can be attacked directly. The reverse-ident feature of TCP Wrappers is not recommended for this reason. It is recommended to protect internal services from external access by firewalling them at the border routers. This is to prevent saturation attacks from outside the LAN, not so much to protect internal services from network-based root compromise. Always configure an exclusive firewall which denies everything by default except for traffic which is explicitly allowed. The range of port numbers used for dynamic binding in &os; is controlled by several net.inet.ip.portrange &man.sysctl.8; variables. Another common DoS attack, called a springboard attack, causes the server to generate responses which overloads the server, the local network, or some other machine. The most common attack of this nature is the ICMP ping broadcast attack. The attacker spoofs ping packets sent to the LAN's broadcast address with the source IP address set to the machine to attack. If the border routers are not configured to drop ping packets sent to broadcast addresses, the LAN generates sufficient responses to the spoofed source address to saturate the victim, especially when the attack is against several dozen broadcast addresses over several dozen different networks at once. A second common springboard attack constructs packets that generate ICMP error responses which can saturate a server's incoming network and cause the server to saturate its outgoing network with ICMP responses. This type of attack can crash the server by running it out of memory, especially if the server cannot drain the ICMP responses it generates fast enough. Use the &man.sysctl.8; variable net.inet.icmp.icmplim to limit these attacks. The last major class of springboard attacks is related to certain internal &man.inetd.8; services such as the UDP echo service. An attacker spoofs a UDP packet with a source address of server A's echo port and a destination address of server B's echo port, where server A and B on the same LAN. The two servers bounce this one packet back and forth between each other. The attacker can overload both servers and the LAN by injecting a few packets in this manner. Similar problems exist with the chargen port. These inetd-internal test services should remain disabled. Spoofed packet attacks may be used to overload the kernel route cache. Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache &man.sysctl.8; parameters. A spoofed packet attack that uses a random source IP will cause the kernel to generate a temporary cached route in the route table, viewable with netstat -rna | fgrep W3. These routes typically timeout in 1600 seconds or so. If the kernel detects that the cached route table has gotten too big, it will dynamically reduce the rtexpire but will never decrease it to less than rtminexpire. This creates two problems: The kernel does not react quickly enough when a lightly loaded server is suddenly attacked. The rtminexpire is not low enough for the kernel to survive a sustained attack. If the servers are connected to the Internet via a T3 or better, it may be prudent to manually override both rtexpire and rtminexpire via &man.sysctl.8;. Never set either parameter to zero as this could crash the machine. Setting both parameters to 2 seconds should be sufficient to protect the route table from attack. Access Issues with Kerberos and &man.ssh.1; &man.ssh.1; There are a few issues with both Kerberos and &man.ssh.1; that need to be addressed if they are used. Kerberos is an excellent authentication protocol, but there are bugs in the kerberized versions of &man.telnet.1; and &man.rlogin.1; that make them unsuitable for dealing with binary streams. By default, Kerberos does not encrypt a session unless is used whereas &man.ssh.1; encrypts everything. While &man.ssh.1; works well, it forwards encryption keys by default. This introduces a security risk to a user who uses &man.ssh.1; to access an insecure machine from a secure workstation. The keys themselves are not exposed, but &man.ssh.1; installs a forwarding port for the duration of the login. If an attacker has broken root on the insecure machine, he can utilize that port to gain access to any other machine that those keys unlock. It is recommended that &man.ssh.1; is used in combination with Kerberos whenever possible for staff logins and &man.ssh.1; can be compiled with Kerberos support. This reduces reliance on potentially exposed SSH keys while protecting passwords via Kerberos. Keys should only be used for automated tasks from secure machines as this is something that Kerberos is unsuited to. It is recommended to either turn off key-forwarding in the SSH configuration, or to make use of from=IP/DOMAIN in authorized_keys to make the key only usable to entities logging in from specific machines. Bill Swingle Parts rewritten and updated by DES, Blowfish, MD5, SHA256, SHA512, and Crypt security crypt crypt Blowfish DES MD5 SHA256 SHA512 Every user on a &unix; system has a password associated with their account. In order to keep these passwords secret, they are encrypted with a one-way hash, as they can be easily encrypted but not decrypted. The operating system itself does not know the password. It only knows the encrypted form of the password. The only way to get the plain-text password is by a brute force search of the space of possible passwords. Originally, the only secure way to encrypt passwords in &unix; was based on the Data Encryption Standard (DES). Since the source code for DES could not be exported outside the US, &os; had to find a way to both comply with US law and retain compatibility with other &unix; variants that used DES. The solution was MD5 which is believed to be more secure than DES. Recognizing the Crypt Mechanism Currently the library supports DES, MD5, Blowfish, SHA256, and SHA512 hash functions. To identify which encryption method &os; is set up to use, examine the encrypted passwords in /etc/master.passwd. Passwords encrypted with the MD5 hash are longer than those encrypted with the DES hash and begin with the characters $1$. Passwords starting with $2a$ are encrypted with the Blowfish hash function. DES password strings do not have any particular identifying characteristics, but they are shorter than MD5 passwords, and are coded in a 64-character alphabet which does not include the $ character, so a relatively short string which does not begin with a dollar sign is very likely a DES password. Both SHA256 and SHA512 begin with the characters $6$. The password format used for new passwords is controlled by the passwd_format login capability in /etc/login.conf, which takes values of des, md5, blf, sha256 or sha512. Refer to &man.login.conf.5; for more information about login capabilities. One-time Passwords one-time passwords security one-time passwords By default, &os; includes support for One-time Passwords In Everything (OPIE), which uses the MD5 hash by default. There are three different types of passwords. The first is the usual &unix; style or Kerberos password. The second is the one-time password which is generated by &man.opiekey.1; and accepted by &man.opiepasswd.1; and the login prompt. The final type of password is the secret password used by &man.opiekey.1;, and sometimes &man.opiepasswd.1;, to generate one-time passwords. The secret password has nothing to do with the &unix; password. They can be the same, but this is not recommended. OPIE secret passwords are not limited to 8 characters like old &unix; passwordsUnder &os; the standard login password may be up to 128 characters in length.. Passwords of six or seven word long phrases are fairly common. For the most part, the OPIE system operates completely independently of the &unix; password system. Besides the password, there are two other pieces of data that are important to OPIE. One is the seed or key, consisting of two letters and five digits. The other is the iteration count, a number between 1 and 100. OPIE creates the one-time password by concatenating the seed and the secret password, applying the MD5 hash as many times as specified by the iteration count, and turning the result into six short English words. These six English words are the one-time password. The authentication system (primarily PAM) keeps track of the last one-time password used, and the user is authenticated if the hash of the user-provided password is equal to the previous password. Because a one-way hash is used, it is impossible to generate future one-time passwords if a successfully used password is captured. The iteration count is decremented after each successful login to keep the user and the login program in sync. When the iteration count gets down to 1, OPIE must be reinitialized. There are a few programs involved in this process. &man.opiekey.1; accepts an iteration count, a seed, and a secret password, and generates a one-time password or a consecutive list of one-time passwords. In addition to initializing OPIE, &man.opiepasswd.1; is used to change passwords, iteration counts, or seeds. It takes either a secret passphrase, or an iteration count, seed, and a one-time password. The relevant credential files in /etc/opiekeys are examined by &man.opieinfo.1; which prints out the invoking user's current iteration count and seed. There are four different sorts of operations. The first is to use &man.opiepasswd.1; over a secure connection to set up one-time-passwords for the first time, or to change the password or seed. The second operation is to use &man.opiepasswd.1; over an insecure connection, in conjunction with &man.opiekey.1; over a secure connection, to do the same. The third is to use &man.opiekey.1; to log in over an insecure connection. The fourth is to use &man.opiekey.1; to generate a number of keys which can be written down or printed out to carry to insecure locations in order to make a connection to anywhere. Secure Connection Initialization To initialize OPIE for the first time, execute &man.opiepasswd.1;: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED At the Enter new secret pass phrase: or Enter secret password: prompt, enter a password or phrase. This is not the login password as this password is used to generate the one-time login keys. The ID line gives the parameters of the instance: the login name, iteration count, and seed. When logging in, the system will remember these parameters and display them, meaning that they do not have to be memorized. The last line gives the particular one-time password which corresponds to those parameters and the secret password. At the next login, this one-time password is the one to use. Insecure Connection Initialization To initialize or change the secret password over an insecure connection, a secure connection is needed to some place where &man.opiekey.1; can be run. This might be a shell prompt on a trusted machine. An iteration count is needed, where 100 is probably a good value, and the seed can either be specified or the randomly-generated one used. On the insecure connection, the machine being initialized, use &man.opiepasswd.1;: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY To accept the default seed, press Return. Before entering an access password, move over to the secure connection and give it the same parameters: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Switch back over to the insecure connection, and copy the generated one-time password over to the relevant program. Generating a Single One-time Password After initializing OPIE and logging in, a prompt like this will be displayed: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> otp-md5 498 gr4269 ext Password: The OPIE prompts provides a useful feature. If Return is pressed at the password prompt, the prompt will turn echo on and display what is typed. This can be useful when attempting to type in a password by hand from a printout. MS-DOS Windows MacOS At this point, generate the one-time password to answer this login prompt. This must be done on a trusted system where it is safe to run &man.opiekey.1;. There are versions of this command for &windows;, &macos; and &os;. This command needs the iteration count and the seed as command line options. Use cut-and-paste from the login prompt on the machine being logged in to. On the trusted system: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Once the one-time password is generated, continue to log in. Generating Multiple One-time Passwords Sometimes there is no access to a trusted machine or secure connection. In this case, it is possible to use &man.opiekey.1; to generate a number of one-time passwords beforehand. For example: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI The requests five keys in sequence, and specifies what the last iteration number should be. Note that these are printed out in reverse order of use. The really paranoid might want to write the results down by hand; otherwise, print the list. Each line shows both the iteration count and the one-time password. Scratch off the passwords as they are used. Restricting Use of &unix; Passwords OPIE can restrict the use of &unix; passwords based on the IP address of a login session. The relevant file is /etc/opieaccess, which is present by default. Refer to &man.opieaccess.5; for more information on this file and which security considerations to be aware of when using it. Here is a sample opieaccess: permit 192.168.0.0 255.255.0.0 This line allows users whose IP source address (which is vulnerable to spoofing) matches the specified value and mask, to use &unix; passwords at any time. If no rules in opieaccess are matched, the default is to deny non-OPIE logins. Tom Rhodes Written by TCP Wrappers TCP Wrappers TCP Wrappers extends the abilities of to provide support for every server daemon under its control. It can be configured to provide logging support, return messages to connections, and permit a daemon to only accept internal connections. While some of these features can be provided by implementing a firewall, TCP Wrappers adds an extra layer of protection and goes beyond the amount of control a firewall can provide. TCP Wrappers should not be considered a replacement for a properly configured firewall. TCP Wrappers should be used in conjunction with a firewall and other security enhancements. Initial Configuration To enable TCP Wrappers in &os;, ensure the &man.inetd.8; server is started from /etc/rc.conf with . Then, properly configure /etc/hosts.allow. Unlike other implementations of TCP Wrappers, the use of hosts.deny has been deprecated. All configuration options should be placed in /etc/hosts.allow. In the simplest configuration, daemon connection policies are set to either be permitted or blocked depending on the options in /etc/hosts.allow. The default configuration in &os; is to allow a connection to every daemon started with &man.inetd.8;. Basic configuration usually takes the form of daemon : address : action, where daemon is the daemon which &man.inetd.8; started, address is a valid hostname, IP address, or an IPv6 address enclosed in brackets ([ ]), and action is either allow or deny. TCP Wrappers uses a first rule match semantic, meaning that the configuration file is scanned in ascending order for a matching rule. When a match is found, the rule is applied and the search process stops. For example, to allow POP3 connections via the mail/qpopper daemon, the following lines should be appended to hosts.allow: # This line is required for POP3 connections: qpopper : ALL : allow After adding this line, &man.inetd.8; needs to be restarted: &prompt.root; service inetd restart Advanced Configuration TCP Wrappers provides advanced options to allow more control over the way connections are handled. In some cases, it may be appropriate to return a comment to certain hosts or daemon connections. In other cases, a log entry should be recorded or an email sent to the administrator. Other situations may require the use of a service for local connections only. This is all possible through the use of configuration options known as wildcards, expansion characters and external command execution. External Commands Suppose that a situation occurs where a connection should be denied yet a reason should be sent to the individual who attempted to establish that connection. That action is possible with . When a connection attempt is made, executes a shell command or script. An example exists in hosts.allow: # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." In this example, the message You are not allowed to use daemon from hostname. will be returned for any daemon not previously configured in the access file. This is useful for sending a reply back to the connection initiator right after the established connection is dropped. Any message returned must be wrapped in quote (") characters. It may be possible to launch a denial of service attack on the server if an attacker, or group of attackers, could flood these daemons with connection requests. Another possibility is to use . Like , implicitly denies the connection and may be used to run external shell commands or scripts. Unlike , will not send a reply back to the individual who established the connection. For example, consider the following configuration line: # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny This will deny all connection attempts from *.example.com and log the hostname, IP address, and the daemon to which access was attempted to /var/log/connections.log. This example uses the substitution characters %a and %h. Refer to &man.hosts.access.5; for the complete list. Wildcard Options The ALL option may be used to match every instance of a daemon, domain, or an IP address. Another wildcard is PARANOID which may be used to match any host which provides an IP address that may be forged. For example, PARANOID may be used to define an action to be taken whenever a connection is made from an IP address that differs from its hostname. In this example, all connection requests to &man.sendmail.8; which have an IP address that varies from its hostname will be denied: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny Using the PARANOID wildcard may severely cripple servers if the client or server has a broken DNS setup. Administrator discretion is advised. To learn more about wildcards and their associated functionality, refer to &man.hosts.access.5;. Before any of the specific configuration lines above will work, the first configuration line should be commented out in hosts.allow. Tillman Hodgson Contributed by Mark Murray Based on a contribution by <application>Kerberos5</application> Kerberos is a network add-on system/protocol that allows users to authenticate themselves through the services of a secure server. Kerberos can be described as an identity-verifying proxy system. It can also be described as a trusted third-party authentication system. After a user authenticates with Kerberos, their communications can be encrypted to assure privacy and data integrity. The only function of Kerberos is to provide the secure authentication of users on the network. It does not provide authorization functions (what users are allowed to do) or auditing functions (what those users did). It is recommended that Kerberos be used with other security methods which provide authorization and audit services. This section provides a guide on how to set up Kerberos as distributed for &os;. Refer to the relevant manual pages for more complete descriptions. For purposes of demonstrating a Kerberos installation, the various name spaces will be as follows: The DNS domain (zone) will be example.org. The Kerberos realm will be EXAMPLE.ORG. Use real domain names when setting up Kerberos even if it will run internally. This avoids DNS problems and assures inter-operation with other Kerberos realms. History Kerberos5 history Kerberos was created by MIT as a solution to network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. Kerberos is both the name of a network authentication protocol and an adjective to describe programs that implement it, such as Kerberos telnet. The current version of the protocol is version 5, described in RFC 1510. Several free implementations of this protocol are available, covering a wide range of operating systems. The Massachusetts Institute of Technology (MIT), where Kerberos was originally developed, continues to develop their Kerberos package. It is commonly used in the US as a cryptography product, and has historically been affected by US export regulations. The MIT Kerberos is available as the security/krb5 package or port. Heimdal Kerberos is another version 5 implementation, and was explicitly developed outside of the US to avoid export regulations. The Heimdal Kerberos distribution is available as a the security/heimdal package or port, and a minimal installation is included in the base &os; install. These instructions assume the use of the Heimdal distribution included in &os;. Setting up a Heimdal <acronym>KDC</acronym> Kerberos5 Key Distribution Center The Key Distribution Center (KDC) is the centralized authentication service that Kerberos provides. It is the computer that issues Kerberos tickets. The KDC is considered trusted by all other computers in the Kerberos realm, and thus has heightened security concerns. While running the Kerberos server requires very few computing resources, a dedicated machine acting only as a KDC is recommended for security reasons. To begin setting up a KDC, ensure that /etc/rc.conf contains the correct settings to act as a KDC. As required, adjust paths to reflect the system: kerberos5_server_enable="YES" kadmind5_server_enable="YES" Next, edit /etc/krb5.conf as follows: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG This /etc/krb5.conf implies that the KDC will use the fully-qualified hostname kerberos.example.org. Add a CNAME (alias) entry to the zone file to accomplish this if the KDC has a different hostname. For large networks with a properly configured DNS server, the above example could be trimmed to: [libdefaults] default_realm = EXAMPLE.ORG With the following lines being appended to the example.org zone file: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG For clients to be able to find the Kerberos services, it must have either a fully configured /etc/krb5.conf or a minimally configured /etc/krb5.conf and a properly configured DNS server. Next, create the Kerberos database which contains the keys of all principals encrypted with a master password. It is not required to remember this password as it will be stored in /var/heimdal/m-key. To create the master key, run &man.kstash.8; and enter a password. Once the master key has been created, initialize the database using kadmin -l. This option instructs &man.kadmin.8; to modify the local database files directly rather than going through the &man.kadmind.8; network service. This handles the chicken-and-egg problem of trying to connect to the database before it is created. At the &man.kadmin.8; prompt, use init to create the realm's initial database. Lastly, while still in &man.kadmin.8;, create the first principal using add. Stick to the default options for the principal for now, as these can be changed later with modify. Type ? at the &man.kadmin.8; prompt to see the available options. A sample database creation session is shown below: &prompt.root; kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx Next, start the KDC services. Run service kerberos start and service kadmind start to bring up the services. While there will not be any kerberized daemons running at this point, it is possible to confirm that the KDC is functioning by obtaining and listing a ticket for the principal (user) that was just created from the command-line of the KDC itself: &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: &prompt.user; klist Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG The ticket can then be revoked when finished: &prompt.user; kdestroy <application>Kerberos</application> Enabling a Server with Heimdal Services Kerberos5 enabling services First, copy /etc/krb5.conf from the KDC to the client computer in a secure fashion, such as &man.scp.1;, or physically via a removable media. Next, create /etc/krb5.keytab. This is the major difference between a server providing Kerberos enabled daemons and a workstation: the server must have a keytab. This file contains the server's host key, which allows it and the KDC to verify each others identity. It must be transmitted to the server in a secure fashion, as the security of the server can be broken if the key is made public. Typically, the keytab is transferred to the server using &man.kadmin.8;. This is handy because the host principal, the KDC end of the krb5.keytab, is also created using &man.kadmin.8;. A ticket must already be obtained and this ticket must be allowed to use the &man.kadmin.8; interface in the kadmind.acl. See the section titled Remote administration ininfo heimdal for details on designing access control lists. Instead of enabling remote &man.kadmin.8; access, the administrator can securely connect to the KDC via the local console or &man.ssh.1;, and perform administration locally using kadmin -l. After installing /etc/krb5.conf, use add --random-key from the Kerberos server. This adds the server's host principal. Then, use ext to extract the server's host principal to its own keytab. For example: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit Note that ext stores the extracted key in /etc/krb5.keytab by default. If &man.kadmind.8; is not running on the KDC and there is no access to &man.kadmin.8; remotely, add the host principal (host/myserver.EXAMPLE.ORG) directly on the KDC and then extract it to a temporary file to avoid overwriting the /etc/krb5.keytab on the KDC, using something like this: &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit The keytab can then be securely copied to the server using &man.scp.1; or a removable media. Be sure to specify a non-default keytab name to avoid overwriting the keytab on the KDC. At this point, the server can communicate with the KDC using krb5.conf and it can prove its own identity with krb5.keytab. It is now ready for the Kerberos services to be enabled. For this example, the &man.telnetd.8; service is enabled in /etc/inetd.conf and &man.inetd.8; has been restarted with service inetd restart: telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user The critical change is that the authentication type is set to user. Refer to &man.telnetd.8; for more details. <application>Kerberos</application> Enabling a Client with Heimdal Kerberos5 configure clients Setting up a client computer is easy as only /etc/krb5.conf is needed. Securely copy this file over to the client computer from the KDC. Test the client by attempting to use &man.kinit.1;, &man.klist.1;, and &man.kdestroy.1; from the client to obtain, show, and then delete a ticket for the principal created above. Kerberos applications should also be able to connect to Kerberos enabled servers. If that does not work but obtaining a ticket does, the problem is likely with the server and not with the client or the KDC. When testing a Kerberized application, try using a packet sniffer such as &man.tcpdump.1; to confirm that the password is not sent in the clear. Various non-core Kerberos client applications are available. The minimal installation in &os; installs &man.telnetd.8; as the only Kerberos enabled service. The Heimdal port installs Kerberos enabled versions of &man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;, and a few other less common programs. The MIT port also contains a full suite of Kerberos client applications. User Configuration Files: <filename>.k5login</filename> and <filename>.k5users</filename> .k5login .k5users Users within a realm typically have their Kerberos principal mapped to a local user account. Occasionally, one needs to grant access to a local user account to someone who does not have a matching Kerberos principal. For example, tillman@EXAMPLE.ORG may need access to the local user account webdevelopers. Other principals may also need access to that local account. The .k5login and .k5users files, placed in a user's home directory, can be used to solve this problem. For example, if .k5login with the following contents is placed in the home directory of webdevelopers, both principals listed will have access to that account without requiring a shared password.: tillman@example.org jdoe@example.org Refer to &man.ksu.1; for more information about .k5users. <application>Kerberos</application> Tips, Tricks, and Troubleshooting When using either the Heimdal or MIT KerberosKerberos5troubleshooting ports, ensure that the PATH lists the Kerberos versions of the client applications before the system versions. If all the computers in the realm do not have synchronized time settings, authentication may fail. describes how to synchronize clocks using NTP. MIT and Heimdal interoperate except for &man.kadmin.8;, which is not standardized. If the hostname is changed, the host/ principal must be changed and the keytab updated. This also applies to special keytab entries like the www/ principal used for Apache's www/mod_auth_kerb. All hosts in the realm must be both forward and reverse resolvable in DNS or, at a minimum, in /etc/hosts. CNAMEs will work, but the A and PTR records must be correct and in place. The error message for unresolvable hosts is not intuitive: Kerberos5 refuses authentication because Read req failed: Key table entry not found. Some operating systems that act as clients to the KDC do not set the permissions for &man.ksu.1; to be setuid root. This means that &man.ksu.1; does not work. This is not a KDC error. With MIT Kerberos, in order to allow a principal to have a ticket life longer than the default ten hours, use modify_principal at the &man.kadmin.8; prompt to change the maxlife of both the principal in question and the krbtgt principal. Then the principal can use kinit -l to request a ticket with a longer lifetime. When running a packet sniffer on the KDC to aid in troubleshooting while running &man.kinit.1; from a workstation, the Ticket Granting Ticket (TGT) is sent immediately upon running &man.kinit.1;, even before the password is typed. This is because the Kerberos server freely transmits a TGT to any unauthorized request. However, every TGT is encrypted in a key derived from the user's password. When a user types their password, it is not sent to the KDC, it is instead used to decrypt the TGT that &man.kinit.1; already obtained. If the decryption process results in a valid ticket with a valid time stamp, the user has valid Kerberos credentials. These credentials include a session key for establishing secure communications with the Kerberos server in the future, as well as the actual TGT, which is encrypted with the Kerberos server's own key. This second layer of encryption allows the Kerberos server to verify the authenticity of each TGT. To use long ticket lifetimes, such as a week, when using OpenSSH to connect to the machine where the ticket is stored, make sure that Kerberos is set to no in sshd_config or else tickets will be deleted at log out. Host principals can have a longer ticket lifetime. If the user principal has a lifetime of a week but the host being connected to has a lifetime of nine hours, the user cache will have an expired host principal and the ticket cache will not work as expected. When setting up krb5.dict to prevent specific bad passwords from being used as described in &man.kadmind.8;, remember that it only applies to principals that have a password policy assigned to them. The format used in krb5.dict is one string per line. Creating a symbolic link to /usr/share/dict/words might be useful. Differences with the <acronym>MIT</acronym> Port The major difference between MIT and Heimdal relates to &man.kadmin.8; which has a different, but equivalent, set of commands and uses a different protocol. If the KDC is MIT, the Heimdal version of &man.kadmin.8; cannot be used to administer the KDC remotely, and vice versa. The client applications may also use slightly different command line options to accomplish the same tasks. Following the instructions on the MIT Kerberos web site is recommended. Be careful of path issues: the MIT port installs into /usr/local/ by default, and the normal system applications run instead of MIT versions if PATH lists the system directories first. With the &os; MIT security/krb5 port, be sure to read /usr/local/share/doc/krb5/README.FreeBSD installed by the port to understand why logins via &man.telnetd.8; and klogind behave somewhat oddly. Correcting the incorrect permissions on cache file behavior requires that the login.krb5 binary be used for authentication so that it can properly change ownership for the forwarded credentials. The following edits should also be made to rc.conf: kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES" This is done because the applications for MIT Kerberos installs binaries in the /usr/local hierarchy. Mitigating Limitations Found in <application>Kerberos</application> Kerberos5 limitations and shortcomings <application>Kerberos</application> is an All or Nothing Approach Every service enabled on the network must be modified to work with Kerberos, or be otherwise secured against network attacks, or else the user's credentials could be stolen and re-used. An example of this would be Kerberos enabling all remote shells but not converting the POP3 mail server which sends passwords in plain text. <application>Kerberos</application> is Intended for Single-User Workstations In a multi-user environment, Kerberos is less secure. This is because it stores the tickets in /tmp, which is readable by all users. If a user is sharing a computer with other users, it is possible that the user's tickets can be stolen or copied by another user. This can be overcome with the -c command-line option or, preferably, the KRB5CCNAME environment variable. Storing the ticket in the user's home directory and using file permissions are commonly used to mitigate this problem. The KDC is a Single Point of Failure By design, the KDC must be as secure as its master password database. The KDC should have absolutely no other services running on it and should be physically secure. The danger is high because Kerberos stores all passwords encrypted with the same master key which is stored as a file on the KDC. A compromised master key is not quite as bad as one might fear. The master key is only used to encrypt the Kerberos database and as a seed for the random number generator. As long as access to the KDC is secure, an attacker cannot do much with the master key. Additionally, if the KDC is unavailable, network services are unusable as authentication cannot be performed. This can be alleviated with a single master KDC and one or more slaves, and with careful implementation of secondary or fall-back authentication using PAM. <application>Kerberos</application> Shortcomings Kerberos allows users, hosts and services to authenticate between themselves. It does not have a mechanism to authenticate the KDC to the users, hosts or services. This means that a trojanned &man.kinit.1; could record all user names and passwords. Filesystem integrity checking tools like security/tripwire can alleviate this. Resources and Further Information Kerberos5 external resources The Kerberos FAQ Designing an Authentication System: a Dialog in Four Scenes RFC 1510, The Kerberos Network Authentication Service (V5) MIT Kerberos home page Heimdal Kerberos home page Tom Rhodes Written by OpenSSL security OpenSSL The OpenSSL toolkit is included in &os;. It provides an encryption transport layer on top of the normal communications layer, allowing it to be intertwined with many network applications and services. Some uses of OpenSSL may include encrypted authentication of mail clients and web based transactions such as credit card payments. Many ports such as www/apache22, and mail/claws-mail offer compilation support for building with OpenSSL. In most cases, the Ports Collection will attempt to build the security/openssl port unless WITH_OPENSSL_BASE is explicitly set to yes. The version of OpenSSL included in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and Transport Layer Security v1 (TLSv1) network security protocols and can be used as a general cryptographic library. While OpenSSL supports the IDEA algorithm, it is disabled by default due to United States patents. To use it, the license should be reviewed and, if the restrictions are acceptable, the MAKE_IDEA variable must be set in /etc/make.conf. One of the most common uses of OpenSSL is to provide certificates for use with software applications. These certificates ensure that the credentials of the company or individual are valid and not fraudulent. If the certificate in question has not been verified by a Certificate Authority (CA), a warning is produced. A CA is a company, such as VeriSign, signs certificates in order to validate the credentials of individuals or companies. This process has a cost associated with it and is not a requirement for using certificates; however, it can put users at ease. Generating Certificates OpenSSL certificate generation To generate a certificate, the following command is available: &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name Notice the response directly after the Common Name prompt shows a domain name. This prompt requires a server name to be entered for verification purposes and placing anything but a domain name yields a useless certificate. Other options, such as the expire time and alternate encryption algorithms, are available. A complete list of options is described in &man.openssl.1;. Two files should now exist in the directory in which this command was issued. The certificate request, req.pem, may be sent to a CA who will validate the entered credentials, sign the request, and return the signed certificate. The second file is named cert.pem and is the private key for the certificate and should be protected at all costs. If this falls in the hands of others it can be used to impersonate the user or the server. In cases where a signature from a CA is not required, a self signed certificate can be created. First, generate the RSA key: &prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024 Next, generate the CA key: &prompt.root; openssl gendsa -des3 -out myca.key myRSA.key Use this key to create the certificate: &prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crt Two new files should appear in the directory: a certificate authority signature file, myca.key and the certificate itself, new.crt. These should be placed in a directory, preferably under /etc, which is readable only by root. Permissions of 0700 are appropriate and can be set using &man.chmod.1;. Using Certificates One use for a certificate is to encrypt connections to the Sendmail MTA. This prevents the use of clear text authentication for users who send mail via the local MTA. Some MUAs will display error if the user has not installed the certificate locally. Refer to the documentation included with the software for more information on certificate installation. To configure Sendmail, the following lines should be placed in the local .mc file: dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl In this example, /etc/certs/ stores the certificate and key files locally. After saving the edits, rebuild the local .cf file by typing make install within /etc/mail. Follow that up with make restart which should start the Sendmail daemon. If all went well, there will be no error messages in /var/log/maillog and Sendmail will show up in the process list. For a simple test, connect to the mail server using &man.telnet.1;: &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. If the STARTTLS line appears in the output, everything is working correctly. Nik Clayton
nik@FreeBSD.org
Written by
<acronym>VPN</acronym> over IPsec IPsec Hiten M. Pandya
hmp@FreeBSD.org
Written by
Understanding IPsec This section demonstrates the process of setting up IPsec. It assumes familiarity with the concepts of building a custom kernel (see ). IPsec is a protocol which sits on top of the Internet Protocol (IP) layer. It allows two or more hosts to communicate in a secure manner. The &os; IPsec network stack is based on the KAME implementation, which has support for both IPv4 and IPv6. IPsec ESP IPsec AH IPsec consists of two sub-protocols: Encapsulated Security Payload ESP): this protocol protects the IP packet data from third party interference by encrypting the contents using symmetric cryptography algorithms such as Blowfish and 3DES. Authentication Header (AH): this protocol protects the IP packet header from third party interference and spoofing by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated. ESP and AH can either be used together or separately, depending on the environment. VPN virtual private network VPN IPsec can either be used to directly encrypt the traffic between two hosts using Transport Mode or to build virtual tunnels using Tunnel Mode. The latter mode is more commonly known as a Virtual Private Network (VPN). Consult &man.ipsec.4; for detailed information on the IPsec subsystem in &os;. To add IPsec support to the kernel, add the following options to the custom kernel configuration file: kernel options IPSEC options IPSEC #IP security device crypto kernel options IPSEC_DEBUG If IPsec debugging support is desired, the following kernel option should also be added: options IPSEC_DEBUG #debug for IP security
<acronym>VPN</acronym> Between a Home and Corporate Network VPN creating There is no standard for what constitutes a VPN. VPNs can be implemented using a number of different technologies, each of which has their own strengths and weaknesses. This section presents the strategies used for implementing a VPN for the following scenario: There are at least two sites where each site is using IP internally. Both sites are connected to the Internet through a gateway that is running &os;. The gateway on each network has at least one public IP address. The internal addresses of the two networks can be either public or private IP addresses. However, the address space must not collide. For example, both networks cannot use 192.168.1.x. Tom Rhodes
trhodes@FreeBSD.org
Written by
Configuring IPsec on &os; To begin, security/ipsec-tools must be installed from the Ports Collection. This software provides a number of applications which support the configuration. The next requirement is to create two &man.gif.4; pseudo-devices which will be used to tunnel packets and allow both networks to communicate properly. As root, run the following commands, replacing internal and external with the real IP addresses of the internal and external interfaces of the two gateways: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 internal1 internal2 &prompt.root; ifconfig gif0 tunnel external1 external2 In this example, the corporate LAN's external IP address is 172.16.5.4 and its internal IP address is 10.246.38.1. The home LAN's external IP address is 192.168.1.12 and its internal private IP address is 10.0.0.5. If this is confusing, review the following example output from &man.ifconfig.8;: Gateway 1: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 Gateway 2: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 Once complete, both internal IP addresses should be reachable using &man.ping.8;: priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms corp-net# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms As expected, both sides have the ability to send and receive ICMP packets from the privately configured addresses. Next, both gateways must be told how to route packets in order to correctly send traffic from either network. The following command will achieve this goal: &prompt.root; corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0 &prompt.root; corp-net# route add net 10.0.0.0: gateway 10.0.0.5 &prompt.root; priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0 &prompt.root; priv-net# route add host 10.246.38.0: gateway 10.246.38.1 At this point, internal machines should be reachable from each gateway as well as from machines behind the gateways. Again, use &man.ping.8; to confirm: corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms priv-net# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms Setting up the tunnels is the easy part. Configuring a secure link is a more in depth process. The following configuration uses pre-shared (PSK) RSA keys. Other than the IP addresses, the /usr/local/etc/racoon/racoon.conf on both gateways will be identical and look similar to: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete padding # options are not to be changed { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # timing options. change as needed { counter 5; interval 20 sec; persend 1; # natt_keepalive 15 sec; phase1 30 sec; phase2 15 sec; } listen # address [port] that racoon will listening on { isakmp 172.16.5.4 [500]; isakmp_natt 172.16.5.4 [4500]; } remote 192.168.1.12 [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; # nat_traversal off; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 30 sec; dh_group 1; } } sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp) { # $network must be the two internal networks you are joining. pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; } For descriptions of each available option, refer to the manual page for racoon.conf. The Security Policy Database (SPD) needs to be configured so that &os; and racoon are able to encrypt and decrypt network traffic between the hosts. This can be achieved with a shell script, similar to the following, on the corporate gateway. This file will be used during system initialization and should be saved as /usr/local/etc/racoon/setkey.conf. flush; spdflush; # To the home network spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; Once in place, racoon may be started on both gateways using the following command: &prompt.root; /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log The output should be similar to the following: corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66) To ensure the tunnel is working properly, switch to another console and use &man.tcpdump.1; to view network traffic using the following command. Replace em0 with the network interface card as required: &prompt.root; tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 Data similar to the following should appear on the console. If not, there is an issue and debugging the returned data will be required. 01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc) At this point, both networks should be available and seem to be part of the same network. Most likely both networks are protected by a firewall. To allow traffic to flow between them, rules need to be added to pass packets. For the &man.ipfw.8; firewall, add the following lines to the firewall configuration file: ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log udp from any 500 to any The rule numbers may need to be altered depending on the current host configuration. For users of &man.pf.4; or &man.ipf.8;, the following rules should do the trick: pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any Finally, to allow the machine to start support for the VPN during system initialization, add the following lines to /etc/rc.conf: ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes"
Chern Lee Contributed by OpenSSH OpenSSH security OpenSSH OpenSSH is a set of network connectivity tools used to access remote machines securely. Additionally, TCP/IP connections can be tunneled/forwarded securely through SSH connections. OpenSSH encrypts all traffic to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. OpenSSH is maintained by the OpenBSD project and is installed by default in &os;. It is compatible with both SSH version 1 and 2 protocols. Advantages of Using <application>OpenSSH</application> When data is sent over the network in an unencrypted form, network sniffers anywhere in between the client and server can steal user/password information or data transferred during the session. OpenSSH offers a variety of authentication and encryption methods to prevent this from happening. Enabling the SSH Server OpenSSH enabling To see if &man.sshd.8; is enabled, check /etc/rc.conf for this line: sshd_enable="YES" This will start &man.sshd.8;, the daemon program for OpenSSH, the next time the system initializes. Alternatively, it is possible to use &man.service.8; to start OpenSSH now: &prompt.root; service sshd start The SSH Client OpenSSH client To use &man.ssh.1; to connect to a system running &man.sshd.8;, specify the username and host to log into: &prompt.root; ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: ******* SSH utilizes a key fingerprint system to verify the authenticity of the server when the client connects. The user is prompted to type yes when connecting for the first time. Future attempts to login are verified against the saved fingerprint key and the &man.ssh.1; client will display an alert if the saved fingerprint differs from the received fingerprint on future login attempts. The fingerprints are saved in ~/.ssh/known_hosts. By default, recent versions of &man.sshd.8; only accept SSH v2 connections. The client will use version 2 if possible and will fall back to version 1. The client can also be forced to use one or the other by passing it the or for version 1 or version 2, respectively. The version 1 compatibility is maintained in the client for backwards compatibility with older versions. Secure Copy OpenSSH secure copy &man.scp.1; Use &man.scp.1; to copy a file to or from a remote machine in a secure fashion. &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Since the fingerprint was already saved for this host in the previous example, it is verified when using &man.scp.1; here. The arguments passed to &man.scp.1; are similar to &man.cp.1;, with the file or files to copy in the first argument, and the destination in the second. Since the file is fetched over the network, through an SSH, connection, one or more of the file arguments takes the form . Configuration OpenSSH configuration The system-wide configuration files for both the OpenSSH daemon and client reside in /etc/ssh. ssh_config configures the client settings, while sshd_config configures the daemon. Each file has its own manual page which describes the available configuration options. &man.ssh-keygen.1; Instead of using passwords, &man.ssh-keygen.1; can be used to generate DSA or RSA keys to authenticate a user: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com &man.ssh-keygen.1; will create a public and private key pair for use in authentication. The private key is stored in ~/.ssh/id_dsa or ~/.ssh/id_rsa, whereas the public key is stored in ~/.ssh/id_dsa.pub or ~/.ssh/id_rsa.pub, respectively for the DSA and RSA key types. The public key must be placed in ~/.ssh/authorized_keys on the remote machine for both RSA or DSA keys in order for the setup to work. This setup allows connections to the remote machine based upon SSH keys instead of passwords. Many users believe that keys are secure by design and will use a key without a passphrase. This is dangerous behavior and the method an administrator may use to verify keys have a passphrase is to view the key manually. If the private key file contains the word ENCRYPTED the key owner is using a passphrase. While it may still be a weak passphrase, at least if the system is compromised, access to other sites will still require some level of password guessing. In addition, to better secure end users, the from may be placed in the public key file. For example, adding from="192.168.10.5 in the front of ssh-rsa or rsa-dsa prefix will only allow that specific user to login from that host IP. If a passphrase is used in &man.ssh-keygen.1;, the user will be prompted for the passphrase each time in order to use the private key. &man.ssh-agent.1; can alleviate the strain of repeatedly entering long passphrases, and is explored in . The various options and files can be different according to the OpenSSH version. To avoid problems, consult &man.ssh-keygen.1;. Using SSH Agent to Cache Keys To load SSH keys into memory for use, without needing to type the passphrase each time, use &man.ssh-agent.1; and &man.ssh-add.1;. Authentication is handled by &man.ssh-agent.1;, using the private key(s) that are loaded into it. Then, &man.ssh-agent.1; should be used to launch another application. At the most basic level, it could spawn a shell or a window manager. To use &man.ssh-agent.1; in a shell, start it with a shell as an argument. Next, add the identity by running &man.ssh-add.1; and providing it the passphrase for the private key. Once these steps have been completed, the user will be able to &man.ssh.1; to any host that has the corresponding public key installed. For example: &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &prompt.user; To use &man.ssh-agent.1; in &xorg;, a call to &man.ssh-agent.1; needs to be placed in ~/.xinitrc. This provides the &man.ssh-agent.1; services to all programs launched in &xorg;. An example ~/.xinitrc might look like this: exec ssh-agent startxfce4 This launches &man.ssh-agent.1;, which in turn launches XFCE, every time &xorg; starts. Once &xorg; has been restarted so that the changes can take effect, run &man.ssh-add.1; to load all of the SSH keys. <acronym>SSH</acronym> Tunneling OpenSSH tunneling OpenSSH has the ability to create a tunnel to encapsulate another protocol in an encrypted session. The following command tells &man.ssh.1; to create a tunnel for &man.telnet.1;: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; This example uses the following options: Forces &man.ssh.1; to use version 2 to connect to the server. Indicates no command, or tunnel only. If omitted, &man.ssh.1; initiates a normal session. Forces &man.ssh.1; to run in the background. Indicates a local tunnel in localport:remotehost:remoteport format. The login name to use on the specified remote SSH server. An SSH tunnel works by creating a listen socket on localhost on the specified port. It then forwards any connections received on the local host/port via the SSH connection to the specified remote host and port. In the example, port 5023 on localhost is forwarded to port 23 on localhost of the remote machine. Since 23 is used by &man.telnet.1;, this creates an encrypted &man.telnet.1; session through an SSH tunnel. This can be used to wrap any number of insecure TCP protocols such as SMTP, POP3, and FTP. Using &man.ssh.1; to Create a Secure Tunnel for SMTP &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP This can be used in conjunction with &man.ssh-keygen.1; and additional user accounts to create a more seamless SSH tunneling environment. Keys can be used in place of typing a password, and the tunnels can be run as a separate user. Practical <acronym>SSH</acronym> Tunneling Examples Secure Access of a POP3 Server In this example, there is an SSH server that accepts connections from the outside. On the same network resides a mail server running a POP3 server. To check email in a secure manner, create an SSH connection to the SSH server, and tunnel through to the mail server. &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** Once the tunnel is up and running, point the email client to send POP3 requests to localhost on port 2110. This connection will be forwarded securely across the tunnel to mail.example.com. Bypassing a Draconian Firewall Some network administrators impose firewall rules which filter both incoming and outgoing connections. For example, it might limit access from remote machines to ports 22 and 80 to only allow &man.ssh.1; and web surfing. This prevents access to any other service which uses a port other than 22 or 80. The solution is to create an SSH connection to a machine outside of the network's firewall and use it to tunnel to the desired service. &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* In this example, a streaming Ogg Vorbis client can now be pointed to localhost port 8888, which will be forwarded over to music.example.com on port 8000, successfully bypassing the firewall. The <varname>AllowUsers</varname> Option It is often a good idea to limit which users can log in and from where using AllowUsers. For example, to only allow root to log in from 192.168.1.32, add this line to /etc/ssh/sshd_config: AllowUsers root@192.168.1.32 To allow admin to log in from anywhere, list that username by itself: AllowUsers admin Multiple users should be listed on the same line, like so: AllowUsers root@192.168.1.32 admin It is important to list each user that needs to log into this machine; otherwise, they will be locked out. After making changes to /etc/ssh/sshd_config, tell &man.sshd.8; to reload its configuration file by running: &prompt.root; service sshd reload Further Reading The OpenSSH website. &man.ssh.1;, &man.scp.1;, &man.ssh-keygen.1;, &man.ssh-agent.1;, &man.ssh-add.1;, and &man.ssh.config.5; for client options. &man.sshd.8;, &man.sftp-server.8;, and &man.sshd.config.5; for server options. Tom Rhodes Contributed by Filesystem Access Control Lists (<acronym>ACL</acronym>)s ACL Filesystem Access Control Lists (ACLs) extend the standard &unix; permission model in a &posix;.1e compatible way. This permits an administrator to make use of and take advantage of a more sophisticated security model. The &os; GENERIC kernel provides ACL support for UFS file systems. Users who prefer to compile a custom kernel must include the following option in their custom kernel configuration file: options UFS_ACL If this option is not compiled in, a warning message will be displayed when attempting to mount a filesystem supporting ACLs. ACLs rely on extended attributes being enabled on the filesystem. Extended attributes are natively supported in UFS2. A higher level of administrative overhead is required to configure extended attributes on UFS1 than on UFS2. The performance of extended attributes on UFS2 is also substantially higher. As a result, UFS2 is recommended for use with ACLs. ACLs are enabled by the mount-time administrative flag, , which may be added to /etc/fstab. The mount-time flag can also be automatically set in a persistent manner using &man.tunefs.8; to modify a superblock ACLs flag in the filesystem header. In general, it is preferred to use the superblock flag for several reasons: The mount-time ACLs flag cannot be changed by a remount using . It requires a complete &man.umount.8; and fresh &man.mount.8;. This means that ACLs cannot be enabled on the root filesystem after boot. It also means that the disposition of a filesystem cannot be changed once it is in use. Setting the superblock flag will cause the filesystem to always be mounted with ACLs enabled, even if there is not an fstab entry or if the devices re-order. This prevents accidental mounting of the filesystem without ACLs enabled, which can result in the security problem of ACLs being improperly enforced. It is desirable to discourage accidental mounting without ACLs enabled, because nasty things can happen if ACLs are enabled, then disabled, then re-enabled without flushing the extended attributes. In general, once ACLs are enabled on a filesystem, they should not be disabled, as the resulting file protections may not be compatible with those intended by the users of the system, and re-enabling ACLs may re-attach the previous ACLs to files that have since had their permissions changed, resulting in unpredictable behavior. Filesystems with ACLs enabled will show a + (plus) sign in their permission settings when viewed. For example: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html In this example, directory1, directory2, and directory3 are all taking advantage of ACLs, whereas public_html is not. Making Use of <acronym>ACL</acronym>s Filesystem ACLs can be viewed using &man.getfacl.1;. For instance, to view the ACL settings on test: &prompt.user; getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- To change the ACL settings on this file, use &man.setfacl.1;: &prompt.user; setfacl -k test To remove all of the currently defined ACLs from a file or filesystem, one can use . However, the preferred method is to use as it leaves the basic fields required for ACLs to work. &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test In this example, is used to modify the default ACL entries. Since there were no pre-defined entries, as they were removed by the previous command, it restores the default options and assign the options listed. If a user or group is added which does not exist on the system, an Invalid argument error will be displayed. Tom Rhodes Contributed by Monitoring Third Party Security Issues portaudit In recent years, the security world has made many improvements to how vulnerability assessment is handled. The threat of system intrusion increases as third party utilities are installed and configured for virtually any operating system available today. Vulnerability assessment is a key factor in security. While &os; releases advisories for the base system, doing so for every third party utility is beyond the &os; Project's capability. There is a way to mitigate third party vulnerabilities and warn administrators of known security issues. A &os; add on utility known as portaudit exists solely for this purpose. The ports-mgmt/portaudit port polls a database, which is updated and maintained by the &os; Security Team and ports developers, for known security issues. To install portaudit from the Ports Collection: &prompt.root; cd /usr/ports/ports-mgmt/portaudit && make install clean During the installation, the configuration files for &man.periodic.8; will be updated, permitting portaudit output in the daily security runs. Ensure that the daily security run emails, which are sent to root's email account, are being read. No other configuration is required. After installation, an administrator can update the database and view known vulnerabilities in installed packages by invoking the following command: &prompt.root; portaudit -Fda The database is automatically updated during the &man.periodic.8; run. The above command is optional and can be used to manually update the database now. To audit the third party utilities installed as part of the Ports Collection at anytime, an administrator can run the following command: &prompt.root; portaudit -a portaudit will display messages for any installed vulnerable packages: Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. By pointing a web browser to the displayed URL, an administrator may obtain more information about the vulnerability. This will include the versions affected, by &os; port version, along with other web sites which may contain security advisories. portaudit is a powerful utility and is extremely useful when coupled with the portmaster port. Tom Rhodes Contributed by &os; Security Advisories &os; Security Advisories Like many production quality operating systems, &os; publishes Security Advisories. These advisories are usually mailed to the security lists and noted in the Errata only after the appropriate releases have been patched. This section explains what an advisory is, how to understand it, and what measures to take in order to patch a system. What Does an Advisory Look Like? &os; security advisories use the format seen in this example: ============================================================================= FreeBSD-SA-XX:XX.UTIL Security Advisory The FreeBSD Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person Affects: All releases of &os; &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) CVE Name: CVE-XXXX-XXXX For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background II. Problem Description III. Impact IV. Workaround V. Solution VI. Correction details VII. References The Topic field specifies the problem. It provides an introduction to the security advisory and notes the utility affected by the vulnerability. The Category refers to the affected part of the system which may be one of core, contrib, or ports. The core category means that the vulnerability affects a core component of the &os; operating system. The contrib category means that the vulnerability affects software contributed to the &os; Project, such as Sendmail. The ports category indicates that the vulnerability affects add on software available through the Ports Collection. The Module field refers to the component location. In this example, the sys module is affected; therefore, this vulnerability affects a component used within the kernel. The Announced field reflects the date the security advisory was published, or announced to the world. This means that the security team has verified that the problem exists and that a patch has been committed to the &os; source code repository. The Credits field gives credit to the individual or organization who noticed the vulnerability and reported it. The Affects field explains which releases of &os; are affected by this vulnerability. For the kernel, a quick look over the output from &man.ident.1; on the affected files will help in determining the revision. For ports, the version number is listed after the port name in /var/db/pkg. If the system does not sync with the &os; Subversion repository and is not rebuilt daily, chances are that it is affected. The Corrected field indicates the date, time, time offset, and release that was corrected. Reserved for the identification information used to look up vulnerabilities in the Common Vulnerabilities and Exposures database. The Background field gives information about the affected utility. Most of the time this is why the utility exists in &os;, what it is used for, and a bit of information on how the utility came to be. The Problem Description field explains the security hole in depth. This can include information on flawed code, or even how the utility could be maliciously used to open a security hole. The Impact field describes what type of impact the problem could have on a system. For example, this could be anything from a denial of service attack, to extra privileges available to users, or even giving the attacker superuser access. The Workaround field offers a workaround to system administrators who cannot upgrade the system due to time constraints, network availability, or other reasons. Security should not be taken lightly, and an affected system should either be patched or the workaround implemented. The Solution field offers instructions for patching the affected system. This is a step by step tested and verified method for getting a system patched and working securely. The Correction Details field displays the Subversion branch or release name with the periods changed to underscore characters. It also shows the revision number of the affected files within each branch. The References field usually offers sources of other information. This can include web URLs, books, mailing lists, and newsgroups. Tom Rhodes Contributed by Process Accounting Process Accounting Process accounting is a security method in which an administrator may keep track of system resources used and their allocation among users, provide for system monitoring, and minimally track a user's commands. This indeed has both positive and negative points. One of the positives is that an intrusion may be narrowed down to the point of entry. A negative is the amount of logs generated by process accounting, and the disk space they may require. This section walks an administrator through the basics of process accounting. Enabling and Utilizing Process Accounting Before using process accounting, it must be enabled using the following commands: - &prompt.root; touch /var/account/acct - -&prompt.root; accton /var/account/acct - -&prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf + &prompt.root; touch /var/account/acct +&prompt.root; chmod 600 /var/account/acct +&prompt.root; accton /var/account/acct +&prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf Once enabled, accounting will begin to track information such as CPU statistics and executed commands. All accounting logs are in a non-human readable format which can be viewed using &man.sa.8;. If issued without any options, &man.sa.8; prints information relating to the number of per-user calls, the total elapsed time in minutes, total CPU and user time in minutes, and the average number of I/O operations. To view information about commands being issued, use &man.lastcomm.1;. This command displays the commands issued by users on specific &man.ttys.5;. For example, this command prints out all known usage of &man.ls.1; by trhodes on the ttyp1 terminal: - &prompt.root; lastcomm ls - trhodes ttyp1 + &prompt.root; lastcomm ls trhodes ttyp1 - Many other useful options exist and are explained in the + Many other useful options exist and are explained in &man.lastcomm.1;, &man.acct.5;, and &man.sa.8;. Tom Rhodes Contributed by Resource Limits Resource limits For years, &os; has used a resource limits database controlled through a flat file, /etc/login.conf. While it has been discussed previously and is still supported, it is not the most optimal method of controlling resources. The flat file requires users to be divided into various group labels known as classes, which require changes not only to this flat file but also the password database. Potentially a single, more constrained user would require an additional label to be added, the resource database rebuilt using cap_mkdb, and edits made to /etc/master.passwd. In addition, the password database must be rebuilt using pwd_mkdb. This multi-step process could be very time consuming depending on how many users must be singled out. A new command in &os;, &man.rctl.8;, allows for a more fine grained method of controlling resources limits for users. This command will support much more than users, it will also set resource constraints on processes, jails, and the original login class. These advanced features provide administrators and users with methods to control resources through the command line and set rules on system initialization using a configuration file. To enable this feature, add these lines to GENERIC, or the custom kernel configuration file, and rebuild.: options RACCT options RCTL The entire system will need rebuilt. See , which will provide instructions - for the process. Once this is complete, the + for the process. Once this is complete, rctl may be used to set rules for the system. Rule syntax is simple, controlled through the use of a subject, a subject-id, resource, and action. Take the following example rule: user:trhodes:maxproc:deny=10/user This rule shows a basic premise of a rule, here the subject is user and the subject-id is trhodes. The maxproc is, of course, max number of processes, which is considered the resource. The action here is set to deny, which blocks any new processes from being created. In the previous example, the user, trhodes will be constrained to 10 (ten) processes and no greater. Other actions are available and could be log to the console, pass a notification to &man.devd.8;, or send a sigterm to the process. Some care must be taken while adding rules. The one above will unfortunately block my user from doing the most simple tasks after I have logged in and executed a screen session. When a resource limit has been hit, an error will be printed, as in this example: &prompt.user; man test /usr/bin/man: Cannot fork: Resource temporarily unavailable eval: Cannot fork: Resource temporarily unavailable For another example, &man.rctl.8; can be used to prevent a jail from exceeding a memory limit. This rule could be written as: &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail Rules may also persist across reboots if they have been added to /etc/rctl.conf. The format is a rule, without the preceding command. For example, the previous rule could be added like the following: # Block jail from using more than 2G memory: jail:httpd:memoryuse:deny=2G/jail To remove a rule, just ask rctl to remove it from the list: &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user The manual page shows a method for removing all rules; however, if removing all rules for a single user is required, this command may be issued: &prompt.root; rctl -r user:trhodes Many other resources exist which can be used to exert additional control over various subjects. See &man.rctl.8; to learn about them.
diff --git a/en_US.ISO8859-1/books/porters-handbook/book.xml b/en_US.ISO8859-1/books/porters-handbook/book.xml index 4f7be9cf9b..6b21bc464f 100644 --- a/en_US.ISO8859-1/books/porters-handbook/book.xml +++ b/en_US.ISO8859-1/books/porters-handbook/book.xml @@ -1,17049 +1,17148 @@ ]> FreeBSD Porter's Handbook The FreeBSD Documentation Project $FreeBSD$ 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 The FreeBSD Documentation Project &trademarks; &legalnotice; $FreeBSD$ Introduction The FreeBSD ports collection is the way almost everyone installs applications ("ports") on FreeBSD. Like everything else about FreeBSD, it is primarily a volunteer effort. It is important to keep this in mind when reading this document. In FreeBSD, anyone may submit a new port, or volunteer to maintain an existing port if it is unmaintained—you do not need any special commit privileges to do so. Making a New Port Yourself So, you are interested in making your own port or upgrading an existing one? Great! What follows are some guidelines for creating a new port for FreeBSD. If you want to upgrade an existing port, you should read this and then read . When this document is not sufficiently detailed, you should refer to /usr/ports/Mk/bsd.port.mk, which all port Makefiles include. Even if you do not hack Makefiles daily, it is well commented, and you will still gain much knowledge from it. Additionally, you may send specific questions to the &a.ports;. Only a fraction of the variables (VAR) that can be overridden are mentioned in this document. Most (if not all) are documented at the start of /usr/ports/Mk/bsd.port.mk; the others probably ought to be. Note that this file uses a non-standard tab setting: Emacs and Vim should recognize the setting on loading the file. Both &man.vi.1; and &man.ex.1; can be set to use the correct value by typing :set tabstop=4 once the file has been loaded. Looking for something easy to start with? Take a look at the list of requested ports and see if you can work on one (or more). Quick Porting This section tells you how to quickly create a new port. In many cases, it is not sufficient, so you will have to read further on into the document. First, get the original tarball and put it into DISTDIR, which defaults to /usr/ports/distfiles. The following assumes that the software compiled out-of-the-box, i.e., there was absolutely no change required for the port to work on your FreeBSD box. If you needed to change something, you will have to refer to the next section too. Writing the <filename>Makefile</filename> The minimal Makefile would look something like this: # $FreeBSD$ PORTNAME= oneko PORTVERSION= 1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.org COMMENT= Cat chasing a mouse all over the screen MAN1= oneko.1 MANCOMPRESSED= yes -USE_IMAKE= yes .include <bsd.port.mk> In some cases, the Makefile of an existing port may contain additional lines in the header, such as the name of the port and the date it was created. This additional information has been declared obsolete, and is being phased out. See if you can figure it out. Do not worry about the contents of the $FreeBSD$ line, it will be filled in automatically by SVN when the port is imported to our main ports tree. You can find a more detailed example in the sample Makefile section. Writing the Description Files There are two description files that are required for any port, whether they actually package or not. They are pkg-descr and pkg-plist. Their pkg- prefix distinguishes them from other files. <filename>pkg-descr</filename> This is a longer description of the port. One to a few paragraphs concisely explaining what the port does is sufficient. This is not a manual or an in-depth description on how to use or compile the port! Please be careful if you are copying from the README or manpage; too often they are not a concise description of the port or are in an awkward format (e.g., manpages have justified spacing, as it looks particularly bad with monospaced fonts). A well-written pkg-descr describes the port completely enough that users would not have to consult the documentation or visit the website to understand what the software does, how it can be useful, or what particularly nice features it has. Mentioning certain requirements like a graphical toolkit, heavy dependencies, runtime environment, or implementation languages help users decide whether this port will work for them. Include a URL to the official WWW homepage. Prepend one of the websites (pick the most common one) with WWW: (followed by single space) so that automated tools will work correctly. If the URI is the root of the website or directory, it should be terminated with a slash. If the listed webpage for a port is not available, try to search the Internet first to see if the official site moved, was renamed, or is hosted elsewhere. The following example shows how your pkg-descr should look: This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (etc.) WWW: http://www.oneko.org/ <filename>pkg-plist</filename> This file lists all the files installed by the port. It is also called the packing list because the package is generated by packing the files listed here. The pathnames are relative to the installation prefix (usually /usr/local. If you are using the MANn variables (as you should be), do not list any manpages here. If the port creates directories during installation, make sure to add @dirrm lines to remove them when the package is deleted. Here is a small example: bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko Refer to the &man.pkg.create.1; manual page for details on the packing list. It is recommended that you keep all the filenames in this file sorted alphabetically. It will make verifying the changes when you upgrade the port much easier. Creating a packing list manually can be a very tedious task. If the port installs a large numbers of files, creating the packing list automatically might save time. There is only one case when pkg-plist can be omitted from a port. If the port installs just a handful of files, and perhaps directories, the files and directories may be listed in the variables PLIST_FILES and PLIST_DIRS, respectively, within the port's Makefile. For instance, we could get along without pkg-plist in the above oneko port by adding the following lines to the Makefile: PLIST_FILES= bin/oneko \ lib/X11/app-defaults/Oneko \ lib/X11/oneko/cat1.xpm \ lib/X11/oneko/cat2.xpm \ lib/X11/oneko/mouse.xpm PLIST_DIRS= lib/X11/oneko Of course, PLIST_DIRS should be left unset if a port installs no directories of its own. The price for this way of listing port's files and directories is that you cannot use command sequences described in &man.pkg.create.1;. Therefore, it is suitable only for simple ports and makes them even simpler. At the same time, it has the advantage of reducing the number of files in the ports collection. Please consider using this technique before you resort to pkg-plist. Later we will see how pkg-plist and PLIST_FILES can be used to fulfill more sophisticated tasks. Creating the Checksum File Just type make makesum. The ports make rules will automatically generate the file distinfo. If a file fetched has its checksum changed regularly and you are certain the source is trusted (i.e., it comes from manufacturer CDs or documentation generated daily), you should specify these files in the IGNOREFILES variable. Then the checksum is not calculated for that file when you run make makesum, but set to IGNORE. Testing the Port You should make sure that the port rules do exactly what you want them to do, including packaging up the port. These are the important points you need to verify. pkg-plist does not contain anything not installed by your port pkg-plist contains everything that is installed by your port Your port can be installed multiple times using the reinstall target Your port cleans up after itself upon deinstall Recommended Test Ordering make install make package make deinstall pkg_add package-name make deinstall make reinstall make package make readme Make sure that there are not any warnings issued in any of the package and deinstall stages. After step 3, check to see if all the new directories are correctly deleted. Also, try using the software after step 4, to ensure that it works correctly when installed from a package. The most thorough way to automate these steps is via installing the ports tinderbox. This maintains jails in which you can test all of the above steps without changing the state of your running system. Please see ports/ports-mgmt/tinderbox for more information. Checking Your Port with <command>portlint</command> Please use portlint to see if your port conforms to our guidelines. The ports-mgmt/portlint program is part of the ports collection. In particular, you may want to check if the Makefile is in the right shape and the package is named appropriately. Submitting the New Port Before you submit the new port, make sure you have read the DOs and DON'Ts section. Now that you are happy with your port, the only thing remaining is to put it in the main &os; ports tree and make everybody else happy about it too. We do not need your work directory or the pkgname.tgz package, so delete them now. Next, assuming your port is called oneko, cd to the directory above where the oneko directory is located, and then type the following: shar `find oneko` > oneko.shar Include your oneko.shar file in a bug report and send it with the &man.send-pr.1; program (see Bug Reports and General Commentary for more information about &man.send-pr.1;). Be sure to classify the bug report as category ports and class change-request (Do not mark the report confidential!). Also add a short description of the program you ported to the Description field of the PR (e.g., perhaps a short version of the COMMENT), and add the shar file to the Fix field. You can make our work a lot easier, if you use a good description in the synopsis of the problem report. We prefer something like New port: <category>/<portname> <short description of the port> for new ports. If you stick to this scheme, the chance that someone will take a look at your PR soon is much better. One more time, do not include the original source distfile, the work directory, or the package you built with make package; and, do use &man.shar.1; for new ports, not &man.diff.1;. After you have submitted your port, please be patient. Sometimes it can take a few months before a port is included in &os;, although it might only take a few days. You can view the list of ports PRs waiting to be committed to &os;. Once we have looked at your port, we will get back to you if necessary, and put it in the tree. Your name will also be added to the list of Additional FreeBSD Contributors and other files. Slow Porting Ok, so it was not that simple, and the port required some modifications to get it to work. In this section, we will explain, step by step, how to modify it to get it to work with the ports paradigm. How Things Work First, this is the sequence of events which occurs when the user first types make in your port's directory. You may find that having bsd.port.mk in another window while you read this really helps to understand it. But do not worry if you do not really understand what bsd.port.mk is doing, not many people do... :-) The fetch target is run. The fetch target is responsible for making sure that the tarball exists locally in DISTDIR. If fetch cannot find the required files in DISTDIR it will look up the URL MASTER_SITES, which is set in the Makefile, as well as our main FTP site at , where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with FETCH, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in DISTDIR for future use and proceed. The extract target is run. It looks for your port's distribution file (typically a gzipped tarball) in DISTDIR and unpacks it into a temporary subdirectory specified by WRKDIR (defaults to work). The patch target is run. First, any patches defined in PATCHFILES are applied. Second, if any patch files named patch-* are found in PATCHDIR (defaults to the files subdirectory), they are applied at this time in alphabetical order. The configure target is run. This can do any one of many different things. If it exists, scripts/configure is run. If HAS_CONFIGURE or GNU_CONFIGURE is set, WRKSRC/configure is run. - - If USE_IMAKE is set, - XMKMF (default: xmkmf - -a) is run. - The build target is run. This is responsible for descending into the port's private working directory (WRKSRC) and building - it. If USE_GMAKE is set, GNU + it. If USES= gmake is set, GNU make will be used, otherwise the system make will be used. The above are the default actions. In addition, you can define targets pre-something or post-something, or put scripts with those names, in the scripts subdirectory, and they will be run before or after the default actions are done. For example, if you have a post-extract target defined in your Makefile, and a file pre-build in the scripts subdirectory, the post-extract target will be called after the regular extraction actions, and the pre-build script will be executed before the default build rules are done. It is recommended that you use Makefile targets if the actions are simple enough, because it will be easier for someone to figure out what kind of non-default action the port requires. The default actions are done by the bsd.port.mk targets do-something. For example, the commands to extract a port are in the target do-extract. If you are not happy with the default target, you can fix it by redefining the do-something target in your Makefile. The main targets (e.g., extract, configure, etc.) do nothing more than make sure all the stages up to that one are completed and call the real targets or scripts, and they are not intended to be changed. If you want to fix the extraction, fix do-extract, but never ever change the way extract operates! Additionally, the target post-deinstall is invalid and is not run by the ports infrastructure. Now that you understand what goes on when the user types make, let us go through the recommended steps to create the perfect port. Getting the Original Sources Get the original sources (normally) as a compressed tarball (foo.tar.gz or foo.tar.bz2) and copy it into DISTDIR. Always use mainstream sources when and where you can. You will need to set the variable MASTER_SITES to reflect where the original tarball resides. You will find convenient shorthand definitions for most mainstream sites in bsd.sites.mk. Please use these sites—and the associated definitions—if at all possible, to help avoid the problem of having the same information repeated over again many times in the source base. As these sites tend to change over time, this becomes a maintenance nightmare for everyone involved. If you cannot find a FTP/HTTP site that is well-connected to the net, or can only find sites that have irritatingly non-standard formats, you might want to put a copy on a reliable FTP or HTTP server that you control (e.g., your home page). If you cannot find somewhere convenient and reliable to put the distfile we can house it ourselves on ftp.FreeBSD.org; however, this is the least-preferred solution. The distfile must be placed into ~/public_distfiles/ of someone's freefall account. Ask the person who commits your port to do this. This person will also set MASTER_SITES to MASTER_SITE_LOCAL and MASTER_SITE_SUBDIR to their freefall username. If your port's distfile changes all the time without any kind of version update by the author, consider putting the distfile on your home page and listing it as the first MASTER_SITES. If you can, try to talk the port author out of doing this; it really does help to establish some kind of source code control. Hosting your own version will prevent users from getting checksum mismatch errors, and also reduce the workload of maintainers of our FTP site. Also, if there is only one master site for the port, it is recommended that you house a backup at your site and list it as the second MASTER_SITES. If your port requires some additional `patches' that are available on the Internet, fetch them too and put them in DISTDIR. Do not worry if they come from a site other than where you got the main source tarball, we have a way to handle these situations (see the description of PATCHFILES below). Modifying the Port Unpack a copy of the tarball in a private directory and make whatever changes are necessary to get the port to compile properly under the current version of &os;. Keep careful track of everything you do, as you will be automating the process shortly. Everything, including the deletion, addition, or modification of files should be doable using an automated script or patch file when your port is finished. If your port requires significant user interaction/customization to compile or install, you should take a look at one of Larry Wall's classic Configure scripts and perhaps do something similar yourself. The goal of the new ports collection is to make each port as plug-and-play as possible for the end-user while using a minimum of disk space. Unless explicitly stated, patch files, scripts, and other files you have created and contributed to the &os; ports collection are assumed to be covered by the standard BSD copyright conditions. Patching In the preparation of the port, files that have been added or changed can be picked up with a &man.diff.1; for later feeding to &man.patch.1;. Each patch you wish to apply should be saved into a file named patch-* where * indicates the pathname of the file that is patched, such as patch-Imakefile or patch-src-config.h. These files should be stored in PATCHDIR (usually files/, from where they will be automatically applied. All patches must be relative to WRKSRC (generally the directory your port's tarball unpacks itself into, that being where the build is done). To make fixes and upgrades easier, you should avoid having more than one patch fix the same file (e.g., patch-file and patch-file2 both changing WRKSRC/foobar.c). Note that if the path of a patched file contains an underscore (_) character, the patch needs to have two underscores instead in its name. For example, to patch a file named src/freeglut_joystick.c, the corresponding patch should be named patch-src-freeglut__joystick.c. Please only use characters [-+._a-zA-Z0-9] for naming your patches. Do not use any other characters besides them. Do not name your patches like patch-aa or patch-ab etc, always mention the path and file name in patch names. Do not put RCS strings in patches. SVN will mangle them when we put the files into the ports tree, and when we check them out again, they will come out different and the patch will fail. RCS strings are surrounded by dollar ($) signs, and typically start with $Id or $RCS. Using the recurse () option to &man.diff.1; to generate patches is fine, but please take a look at the resulting patches to make sure you do not have any unnecessary junk in there. In particular, diffs between two backup files, Makefiles when the port uses Imake or GNU configure, etc., are unnecessary and should be deleted. If you had to edit configure.in and run autoconf to regenerate configure, do not take the diffs of configure (it often grows to a few thousand lines!); define USE_AUTOTOOLS=autoconf:261 and take the diffs of configure.in. Also, try to minimize the amount of non-functional whitespace changes in your patches. It is common in the Open Source world for projects to share large amounts of a code base, but obey different style and indenting rules. If you take a working piece of functionality from one project to fix similar areas in another, please be careful: the resulting line patch may be full of non-functional changes. It not only increases the size of the SVN repository but makes it hard to find out what exactly caused the problem and what you changed at all. If you had to delete a file, then you can do it in the post-extract target rather than as part of the patch. Simple replacements can be performed directly from the port Makefile using the in-place mode of &man.sed.1;. This is very useful when you need to patch in a variable value. Example: post-patch: @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README Quite often, there is a situation when the software being ported, especially if it is primarily developed on &windows;, uses the CR/LF convention for most of its source files. This may cause problems with further patching, compiler warnings, scripts execution (/bin/sh^M not found), etc. To quickly convert all files from CR/LF to just LF, add USE_DOS2UNIX=yes to the port Makefile. A list of files to convert can be specified: USE_DOS2UNIX= util.c util.h If you want to convert a group of files across subdirectories, DOS2UNIX_REGEX can be used. Its argument is a find compatible regular expression. More on the format is in &man.re.format.7;. This option is useful for converting all files of a given extension, for example all source code files leaving binary files intact: USE_DOS2UNIX= yes DOS2UNIX_REGEX= .*\.(c|cpp|h) If you want to create a patch file based off of an existing file, you can copy it with an .orig extension, and then modify the original one. The makepatch target will write out an appropriate patch file to the files directory of the port. Configuring Include any additional customization commands in your configure script and save it in the scripts subdirectory. As mentioned above, you can also do this with Makefile targets and/or scripts with the name pre-configure or post-configure. Handling User Input If your port requires user input to build, configure, or install, you must set IS_INTERACTIVE in your Makefile. This will allow overnight builds to skip your port if the user sets the variable BATCH in his environment (and if the user sets the variable INTERACTIVE, then only those ports requiring interaction are built). This will save a lot of wasted time on the set of machines that continually build ports (see below). It is also recommended that if there are reasonable default answers to the questions, you check the PACKAGE_BUILDING variable and turn off the interactive script when it is set. This will allow us to build the packages for CDROMs and FTP. Configuring the Makefile Configuring the Makefile is pretty simple, and again we suggest that you look at existing examples before starting. Also, there is a sample Makefile in this handbook, so take a look and please follow the ordering of variables and sections in that template to make your port easier for others to read. Now, consider the following problems in sequence as you design your new Makefile: The Original Source Does it live in DISTDIR as a standard gzipped tarball named something like foozolix-1.2.tar.gz? If so, you can go on to the next step. If not, you should look at overriding any of the DISTVERSION, DISTNAME, EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, or DISTFILES variables, depending on how alien a format your port's distribution file is. In the worst case, you can simply create your own do-extract target to override the default, though this should be rarely, if ever, necessary. Naming The first part of the port's Makefile names the port, describes its version number, and lists it in the correct category. <makevar>PORTNAME</makevar> and <makevar>PORTVERSION</makevar> You should set PORTNAME to the base name of your port, and PORTVERSION to the version number of the port. <makevar>PORTREVISION</makevar> and <makevar>PORTEPOCH</makevar> <makevar>PORTREVISION</makevar> The PORTREVISION variable is a monotonically increasing value which is reset to 0 with every increase of PORTVERSION (i.e., every time a new official vendor release is made), and appended to the package name if non-zero. Changes to PORTREVISION are used by automated tools (e.g., &man.pkg.version.1;) to highlight the fact that a new package is available. PORTREVISION should be increased each time a change is made to the port which significantly affects the content or structure of the derived package. Examples of when PORTREVISION should be bumped: Addition of patches to correct security vulnerabilities, bugs, or to add new functionality to the port. Changes to the port Makefile to enable or disable compile-time options in the package. Changes in the packing list or the install-time behavior of the package (e.g., change to a script which generates initial data for the package, like ssh host keys). Version bump of a port's shared library dependency (in this case, someone trying to install the old package after installing a newer version of the dependency will fail since it will look for the old libfoo.x instead of libfoo.(x+1)). Silent changes to the port distfile which have significant functional differences, i.e., changes to the distfile requiring a correction to distinfo with no corresponding change to PORTVERSION, where a diff -ru of the old and new versions shows non-trivial changes to the code. Examples of changes which do not require a PORTREVISION bump: Style changes to the port skeleton with no functional change to what appears in the resulting package. Changes to MASTER_SITES or other functional changes to the port which do not affect the resulting package. Trivial patches to the distfile such as correction of typos, which are not important enough that users of the package should go to the trouble of upgrading. Build fixes which cause a package to become compilable where it was previously failing (as long as the changes do not introduce any functional change on any other platforms on which the port did previously build). Since PORTREVISION reflects the content of the package, if the package was not previously buildable then there is no need to increase PORTREVISION to mark a change. A rule of thumb is to ask yourself whether a change committed to a port is something which everyone would benefit from having (either because of an enhancement, fix, or by virtue that the new package will actually work at all), and weigh that against that fact that it will cause everyone who regularly updates their ports tree to be compelled to update. If yes, the PORTREVISION should be bumped. <makevar>PORTEPOCH</makevar> From time to time a software vendor or FreeBSD porter will do something silly and release a version of their software which is actually numerically less than the previous version. An example of this is a port which goes from foo-20000801 to foo-1.0 (the former will be incorrectly treated as a newer version since 20000801 is a numerically greater value than 1). The results of version number comparisons are not always obvious. &man.pkg.version.1; can be used to test the comparison of two version number strings. The pkgng equivalent is pkg version -t. For example: &prompt.user; pkg_version -t 0.031 0.29 > Or, for pkgng users: &prompt.user; pkg version -t 0.031 0.29 > The > output indicates that version 0.031 is considered greater than version 0.29, which may not have been obvious to the porter. In situations such as this, the PORTEPOCH version should be increased. If PORTEPOCH is nonzero it is appended to the package name as described in section 0 above. PORTEPOCH must never be decreased or reset to zero, because that would cause comparison to a package from an earlier epoch to fail (i.e., the package would not be detected as out of date): the new version number (e.g., 1.0,1 in the above example) is still numerically less than the previous version (20000801), but the ,1 suffix is treated specially by automated tools and found to be greater than the implied suffix ,0 on the earlier package. Dropping or resetting PORTEPOCH incorrectly leads to no end of grief; if you do not understand the above discussion, please keep after it until you do, or ask questions on the mailing lists. It is expected that PORTEPOCH will not be used for the majority of ports, and that sensible use of PORTVERSION can often preempt it becoming necessary if a future release of the software should change the version structure. However, care is needed by FreeBSD porters when a vendor release is made without an official version number — such as a code snapshot release. The temptation is to label the release with the release date, which will cause problems as in the example above when a new official release is made. For example, if a snapshot release is made on the date 20000917, and the previous version of the software was version 1.2, the snapshot release should be given a PORTVERSION of 1.2.20000917 or similar, not 20000917, so that the succeeding release, say 1.3, is still a numerically greater value. Example of <makevar>PORTREVISION</makevar> and <makevar>PORTEPOCH</makevar> Usage The gtkmumble port, version 0.10, is committed to the ports collection: PORTNAME= gtkmumble PORTVERSION= 0.10 PKGNAME becomes gtkmumble-0.10. A security hole is discovered which requires a local FreeBSD patch. PORTREVISION is bumped accordingly. PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1 PKGNAME becomes gtkmumble-0.10_1 A new version is released by the vendor, numbered 0.2 (it turns out the author actually intended 0.10 to actually mean 0.1.0, not what comes after 0.9 - oops, too late now). Since the new minor version 2 is numerically less than the previous version 10, the PORTEPOCH must be bumped to manually force the new package to be detected as newer. Since it is a new vendor release of the code, PORTREVISION is reset to 0 (or removed from the Makefile). PORTNAME= gtkmumble PORTVERSION= 0.2 PORTEPOCH= 1 PKGNAME becomes gtkmumble-0.2,1 The next release is 0.3. Since PORTEPOCH never decreases, the version variables are now: PORTNAME= gtkmumble PORTVERSION= 0.3 PORTEPOCH= 1 PKGNAME becomes gtkmumble-0.3,1 If PORTEPOCH were reset to 0 with this upgrade, someone who had installed the gtkmumble-0.10_1 package would not detect the gtkmumble-0.3 package as newer, since 3 is still numerically less than 10. Remember, this is the whole point of PORTEPOCH in the first place. <makevar>PKGNAMEPREFIX</makevar> and <makevar>PKGNAMESUFFIX</makevar> Two optional variables, PKGNAMEPREFIX and PKGNAMESUFFIX, are combined with PORTNAME and PORTVERSION to form PKGNAME as ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Make sure this conforms to our guidelines for a good package name. In particular, you are not allowed to use a hyphen (-) in PORTVERSION. Also, if the package name has the language- or the -compiled.specifics part (see below), use PKGNAMEPREFIX and PKGNAMESUFFIX, respectively. Do not make them part of PORTNAME. <makevar>LATEST_LINK</makevar> LATEST_LINK is used during package building to determine a shortened name to create links that can be used by pkg_add -r. This makes it possible to, for example, install the latest perl version by running pkg_add -r perl without knowing the exact version number. This name needs to be unique and obvious to users. In some cases, several versions of a program may be present in the ports collection at the same time. Both the index build and the package build system need to be able to see them as different, independent ports, although they may all have the same PORTNAME, PKGNAMEPREFIX, and even PKGNAMESUFFIX. In those cases, the optional LATEST_LINK variable should be set to a different value for all ports except the main one — see the lang/gcc46 and lang/gcc ports, and the www/apache* family for examples of its use. By setting NO_LATEST_LINK, no link will be generated, which may be an option for all but the main version. Note that how to choose a main version — most popular, best supported, least patched, and so on — is outside the scope of this handbook's recommendations; we only tell you how to specify the other ports' versions after you have picked a main one. Package Naming Conventions The following are the conventions you should follow in naming your packages. This is to have our package directory easy to scan, as there are already thousands of packages and users are going to turn away if they hurt their eyes! The package name should look like language_region-name-compiled.specifics-version.numbers. The package name is defined as ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Make sure to set the variables to conform to that format. FreeBSD strives to support the native language of its users. The language- part should be a two letter abbreviation of the natural language defined by ISO-639 if the port is specific to a certain language. Examples are ja for Japanese, ru for Russian, vi for Vietnamese, zh for Chinese, ko for Korean and de for German. If the port is specific to a certain region within the language area, add the two letter country code as well. Examples are en_US for US English and fr_CH for Swiss French. The language- part should be set in the PKGNAMEPREFIX variable. The first letter of the name part should be lowercase. (The rest of the name may contain capital letters, so use your own discretion when you are converting a software name that has some capital letters in it.) There is a tradition of naming Perl 5 modules by prepending p5- and converting the double-colon separator to a hyphen; for example, the Data::Dumper module becomes p5-Data-Dumper. Make sure that the port's name and version are clearly separated and placed into the PORTNAME and PORTVERSION variables. The only reason for PORTNAME to contain a version part is if the upstream distribution is really named that way, as in the textproc/libxml2 or japanese/kinput2-freewnn ports. Otherwise, the PORTNAME should not contain any version-specific information. It is quite normal for several ports to have the same PORTNAME, as the www/apache* ports do; in that case, different versions (and different index entries) are distinguished by the PKGNAMEPREFIX, PKGNAMESUFFIX, and LATEST_LINK values. If the port can be built with different hardcoded defaults (usually part of the directory name in a family of ports), the -compiled.specifics part should state the compiled-in defaults (the hyphen is optional). Examples are paper size and font units. The -compiled.specifics part should be set in the PKGNAMESUFFIX variable. The version string should follow a dash (-) and be a period-separated list of integers and single lowercase alphabetics. In particular, it is not permissible to have another dash inside the version string. The only exception is the string pl (meaning patchlevel), which can be used only when there are no major and minor version numbers in the software. If the software version has strings like alpha, beta, rc, or pre, take the first letter and put it immediately after a period. If the version string continues after those names, the numbers should follow the single alphabet without an extra period between them. The idea is to make it easier to sort ports by looking at the version string. In particular, make sure version number components are always delimited by a period, and if the date is part of the string, use the 0.0.yyyy.mm.dd format, not dd.mm.yyyy or the non-Y2K compliant yy.mm.dd format. It is important to prefix the version with 0.0. in case a release with an actual version number is made, which would of course be numerically less than yyyy. Here are some (real) examples on how to convert the name as called by the software authors to a suitable package name: Distribution Name PKGNAMEPREFIX PORTNAME PKGNAMESUFFIX PORTVERSION Reason mule-2.2.2 (empty) mule (empty) 2.2.2 No changes required EmiClock-1.0.2 (empty) emiclock (empty) 1.0.2 No uppercase names for single programs rdist-1.3alpha (empty) rdist (empty) 1.3.a No strings like alpha allowed es-0.9-beta1 (empty) es (empty) 0.9.b1 No strings like beta allowed mailman-2.0rc3 (empty) mailman (empty) 2.0.r3 No strings like rc allowed v3.3beta021.src (empty) tiff (empty) 3.3 What the heck was that anyway? tvtwm (empty) tvtwm (empty) pl11 Version string always required piewm (empty) piewm (empty) 1.0 Version string always required xvgr-2.10pl1 (empty) xvgr (empty) 2.10.1 pl allowed only when no major/minor version numbers gawk-2.15.6 ja- gawk (empty) 2.15.6 Japanese language version psutils-1.13 (empty) psutils -letter 1.13 Paper size hardcoded at package build time pkfonts (empty) pkfonts 300 1.0 Package for 300dpi fonts If there is absolutely no trace of version information in the original source and it is unlikely that the original author will ever release another version, just set the version string to 1.0 (like the piewm example above). Otherwise, ask the original author or use the date string (0.0.yyyy.mm.dd) as the version. Categorization <makevar>CATEGORIES</makevar> When a package is created, it is put under /usr/ports/packages/All and links are made from one or more subdirectories of /usr/ports/packages. The names of these subdirectories are specified by the variable CATEGORIES. It is intended to make life easier for the user when he is wading through the pile of packages on the FTP site or the CDROM. Please take a look at the current list of categories and pick the ones that are suitable for your port. This list also determines where in the ports tree the port is imported. If you put more than one category here, it is assumed that the port files will be put in the subdirectory with the name in the first category. See below for more discussion about how to pick the right categories. Current List of Categories Here is the current list of port categories. Those marked with an asterisk (*) are virtual categories—those that do not have a corresponding subdirectory in the ports tree. They are only used as secondary categories, and only for search purposes. For non-virtual categories, you will find a one-line description in the COMMENT in that subdirectory's Makefile. Category Description Notes accessibility Ports to help disabled users. afterstep* Ports to support the AfterStep window manager. arabic Arabic language support. archivers Archiving tools. astro Astronomical ports. audio Sound support. benchmarks Benchmarking utilities. biology Biology-related software. cad Computer aided design tools. chinese Chinese language support. comms Communication software. Mostly software to talk to your serial port. converters Character code converters. databases Databases. deskutils Things that used to be on the desktop before computers were invented. devel Development utilities. Do not put libraries here just because they are libraries—unless they truly do not belong anywhere else, they should not be in this category. dns DNS-related software. docs* Meta-ports for FreeBSD documentation. editors General editors. Specialized editors go in the section for those tools (e.g., a mathematical-formula editor will go in math). elisp* Emacs-lisp ports. emulators Emulators for other operating systems. Terminal emulators do not belong here—X-based ones should go to x11 and text-based ones to either comms or misc, depending on the exact functionality. finance Monetary, financial and related applications. french French language support. ftp FTP client and server utilities. If your port speaks both FTP and HTTP, put it in ftp with a secondary category of www. games Games. geography* Geography-related software. german German language support. gnome* Ports from the GNOME Project. gnustep* Software related to the GNUstep desktop environment. graphics Graphics utilities. hamradio* Software for amateur radio. haskell* Software related to the Haskell language. hebrew Hebrew language support. hungarian Hungarian language support. ipv6* IPv6 related software. irc Internet Relay Chat utilities. japanese Japanese language support. java Software related to the Java™ language. The java category must not be the only one for a port. Save for ports directly related to the Java language, porters are also encouraged not to use java as the main category of a port. kde* Ports from the KDE Project. kld* Kernel loadable modules. korean Korean language support. lang Programming languages. linux* Linux applications and support utilities. lisp* Software related to the Lisp language. mail Mail software. math Numerical computation software and other utilities for mathematics. mbone* MBone applications. misc Miscellaneous utilities Basically things that do not belong anywhere else. If at all possible, try to find a better category for your port than misc, as ports tend to get overlooked in here. multimedia Multimedia software. net Miscellaneous networking software. net-im Instant messaging software. net-mgmt Networking management software. net-p2p Peer to peer network applications. news USENET news software. palm Software support for the Palm™ series. parallel* Applications dealing with parallelism in computing. pear* Ports related to the Pear PHP framework. perl5* Ports that require Perl version 5 to run. plan9* Various programs from Plan9. polish Polish language support. ports-mgmt Ports for managing, installing and developing FreeBSD ports and packages. portuguese Portuguese language support. print Printing software. Desktop publishing tools (previewers, etc.) belong here too. python* Software related to the Python language. ruby* Software related to the Ruby language. rubygems* Ports of RubyGems packages. russian Russian language support. scheme* Software related to the Scheme language. science Scientific ports that do not fit into other categories such as astro, biology and math. security Security utilities. shells Command line shells. spanish* Spanish language support. sysutils System utilities. tcl* Ports that use Tcl to run. textproc Text processing utilities. It does not include desktop publishing tools, which go to print. tk* Ports that use Tk to run. ukrainian Ukrainian language support. vietnamese Vietnamese language support. windowmaker* Ports to support the WindowMaker window manager. www Software related to the World Wide Web. HTML language support belongs here too. x11 The X Window System and friends. This category is only for software that directly supports the window system. Do not put regular X applications here; most of them should go into other x11-* categories (see below). x11-clocks X11 clocks. x11-drivers X11 drivers. x11-fm X11 file managers. x11-fonts X11 fonts and font utilities. x11-servers X11 servers. x11-themes X11 themes. x11-toolkits X11 toolkits. x11-wm X11 window managers. xfce* Ports related to the Xfce desktop environment. zope* Zope support. Choosing the Right Category As many of the categories overlap, you often have to choose which of the categories should be the primary category of your port. There are several rules that govern this issue. Here is the list of priorities, in decreasing order of precedence: The first category must be a physical category (see above). This is necessary to make the packaging work. Virtual categories and physical categories may be intermixed after that. Language specific categories always come first. For example, if your port installs Japanese X11 fonts, then your CATEGORIES line would read japanese x11-fonts. Specific categories are listed before less-specific ones. For instance, an HTML editor should be listed as www editors, not the other way around. Also, you should not list net when the port belongs to any of irc, mail, news, security, or www, as net is included implicitly. x11 is used as a secondary category only when the primary category is a natural language. In particular, you should not put x11 in the category line for X applications. Emacs modes should be placed in the same ports category as the application supported by the mode, not in editors. For example, an Emacs mode to edit source files of some programming language should go into lang. Ports which install loadable kernel modules should have the virtual category kld in their CATEGORIES line. misc should not appear with any other non-virtual category. If you have misc with something else in your CATEGORIES line, that means you can safely delete misc and just put the port in that other subdirectory! If your port truly does not belong anywhere else, put it in misc. If you are not sure about the category, please put a comment to that effect in your &man.send-pr.1; submission so we can discuss it before we import it. If you are a committer, send a note to the &a.ports; so we can discuss it first. Too often, new ports are imported to the wrong category only to be moved right away. This causes unnecessary and undesirable bloat in the master source repository. Proposing a New Category As the Ports Collection has grown over time, various new categories have been introduced. New categories can either be virtual categories—those that do not have a corresponding subdirectory in the ports tree— or physical categories—those that do. The following text discusses the issues involved in creating a new physical category so that you can understand them before you propose one. Our existing practice has been to avoid creating a new physical category unless either a large number of ports would logically belong to it, or the ports that would belong to it are a logically distinct group that is of limited general interest (for instance, categories related to spoken human languages), or preferably both. The rationale for this is that such a change creates a fair amount of work for both the committers and also for all users who track changes to the Ports Collection. In addition, proposed category changes just naturally seem to attract controversy. (Perhaps this is because there is no clear consensus on when a category is too big, nor whether categories should lend themselves to browsing (and thus what number of categories would be an ideal number), and so forth.) Here is the procedure: Propose the new category on &a.ports;. You should include a detailed rationale for the new category, including why you feel the existing categories are not sufficient, and the list of existing ports proposed to move. (If there are new ports pending in GNATS that would fit this category, list them too.) If you are the maintainer and/or submitter, respectively, mention that as it may help you to make your case. Participate in the discussion. If it seems that there is support for your idea, file a PR which includes both the rationale and the list of existing ports that need to be moved. Ideally, this PR should also include patches for the following: Makefiles for the new ports once they are repocopied Makefile for the new category Makefile for the old ports' categories Makefiles for ports that depend on the old ports (for extra credit, you can include the other files that have to change, as per the procedure in the Committer's Guide.) Since it affects the ports infrastructure and involves not only performing repo-copies but also possibly running regression tests on the build cluster, the PR should be assigned to the &a.portmgr;. If that PR is approved, a committer will need to follow the rest of the procedure that is outlined in the Committer's Guide. Proposing a new virtual category should be similar to the above but much less involved, since no ports will actually have to move. In this case, the only patches to include in the PR would be those to add the new category to the CATEGORIES of the affected ports. Proposing Reorganizing All the Categories Occasionally someone proposes reorganizing the categories with either a 2-level structure, or some other kind of keyword structure. To date, nothing has come of any of these proposals because, while they are very easy to make, the effort involved to retrofit the entire existing ports collection with any kind of reorganization is daunting to say the very least. Please read the history of these proposals in the mailing list archives before you post this idea; furthermore, you should be prepared to be challenged to offer a working prototype. The Distribution Files The second part of the Makefile describes the files that must be downloaded in order to build the port, and where they can be downloaded from. <makevar>DISTVERSION/DISTNAME</makevar> DISTNAME is the name of the port as called by the authors of the software. DISTNAME defaults to ${PORTNAME}-${PORTVERSION}, so override it only if necessary. DISTNAME is only used in two places. First, the distribution file list (DISTFILES) defaults to ${DISTNAME}${EXTRACT_SUFX}. Second, the distribution file is expected to extract into a subdirectory named WRKSRC, which defaults to work/${DISTNAME}. Some vendor's distribution names which do not fit into the ${PORTNAME}-${PORTVERSION}-scheme can be handled automatically by setting DISTVERSION. PORTVERSION and DISTNAME will be derived automatically, but can of course be overridden. The following table lists some examples: DISTVERSION PORTVERSION 0.7.1d 0.7.1.d 10Alpha3 10.a3 3Beta7-pre2 3.b7.p2 8:f_17 8f.17 PKGNAMEPREFIX and PKGNAMESUFFIX do not affect DISTNAME. Also note that if WRKSRC is equal to work/${PORTNAME}-${PORTVERSION} while the original source archive is named something other than ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}, you should probably leave DISTNAME alone— you are better off defining DISTFILES than having to set both DISTNAME and WRKSRC (and possibly EXTRACT_SUFX). <makevar>MASTER_SITES</makevar> Record the directory part of the FTP/HTTP-URL pointing at the original tarball in MASTER_SITES. Do not forget the trailing slash (/)! The make macros will try to use this specification for grabbing the distribution file with FETCH if they cannot find it already on the system. It is recommended that you put multiple sites on this list, preferably from different continents. This will safeguard against wide-area network problems. We are even planning to add support for automatically determining the closest master site and fetching from there; having multiple sites will go a long way towards helping this effort. If the original tarball is part of one of the popular archives such as SourceForge, GNU, or Perl CPAN, you may be able refer to those sites in an easy compact form using MASTER_SITE_* (e.g., MASTER_SITE_SOURCEFORGE, MASTER_SITE_GNU and MASTER_SITE_PERL_CPAN). Simply set MASTER_SITES to one of these variables and MASTER_SITE_SUBDIR to the path within the archive. Here is an example: MASTER_SITES= ${MASTER_SITE_GNU} MASTER_SITE_SUBDIR= make Or you can use a condensed format: MASTER_SITES= GNU/make These variables are defined in /usr/ports/Mk/bsd.sites.mk. There are new entries added all the time, so make sure to check the latest version of this file before submitting a port. Several magic macros exist for popular sites with a predictable directory structure. For these, just use the abbreviation and the system will try to guess the correct subdirectory for you. MASTER_SITES= SF If the guess is incorrect, it can be overridden as follows. MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION} This can be also written as MASTER_SITES= SF MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} Popular Magic <makevar>MASTER_SITES</makevar> Macros Macro Assumed subdirectory APACHE_JAKARTA /dist/jakarta/${PORTNAME:S,-,,/,}/source BERLIOS /${PORTNAME:L} CHEESESHOP /packages/source/source/${DISTNAME:C/(.).*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/} DEBIAN /debian/pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME} GCC /pub/gcc/releases/${DISTNAME} GNOME /pub/GNOME/sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/} GNU /gnu/${PORTNAME} MOZDEV /pub/mozdev/${PORTNAME:L} PERL_CPAN /pub/CPAN/modules/by-module/${PORTNAME:C/-.*//} PYTHON /ftp/python/${PYTHON_PORTVERSION:C/rc[0-9]//} RUBYFORGE /${PORTNAME:L} SAVANNAH /${PORTNAME:L} SF /project/${PORTNAME:L}/${PORTNAME:L}/${PORTVERSION}
<makevar>EXTRACT_SUFX</makevar> If you have one distribution file, and it uses an odd suffix to indicate the compression mechanism, set EXTRACT_SUFX. For example, if the distribution file was named foo.tgz instead of the more normal foo.tar.gz, you would write: DISTNAME= foo EXTRACT_SUFX= .tgz The USE_BZIP2, USE_XZ and USE_ZIP variables automatically set EXTRACT_SUFX to .tar.bz2, .tar.xz or .zip as necessary. If neither of these are set then EXTRACT_SUFX defaults to .tar.gz. You never need to set both EXTRACT_SUFX and DISTFILES. <makevar>DISTFILES</makevar> Sometimes the names of the files to be downloaded have no resemblance to the name of the port. For example, it might be called source.tar.gz or similar. In other cases the application's source code might be in several different archives, all of which must be downloaded. If this is the case, set DISTFILES to be a space separated list of all the files that must be downloaded. DISTFILES= source1.tar.gz source2.tar.gz If not explicitly set, DISTFILES defaults to ${DISTNAME}${EXTRACT_SUFX}. <makevar>EXTRACT_ONLY</makevar> If only some of the DISTFILES must be extracted—for example, one of them is the source code, while another is an uncompressed document—list the filenames that must be extracted in EXTRACT_ONLY. DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz If none of the DISTFILES should be uncompressed then set EXTRACT_ONLY to the empty string. EXTRACT_ONLY= <makevar>PATCHFILES</makevar> If your port requires some additional patches that are available by FTP or HTTP, set PATCHFILES to the names of the files and PATCH_SITES to the URL of the directory that contains them (the format is the same as MASTER_SITES). If the patch is not relative to the top of the source tree (i.e., WRKSRC) because it contains some extra pathnames, set PATCH_DIST_STRIP accordingly. For instance, if all the pathnames in the patch have an extra foozolix-1.0/ in front of the filenames, then set PATCH_DIST_STRIP=-p1. Do not worry if the patches are compressed; they will be decompressed automatically if the filenames end with .gz or .Z. If the patch is distributed with some other files, such as documentation, in a gzipped tarball, you cannot just use PATCHFILES. If that is the case, add the name and the location of the patch tarball to DISTFILES and MASTER_SITES. Then, use the EXTRA_PATCHES variable to point to those files and bsd.port.mk will automatically apply them for you. In particular, do not copy patch files into the PATCHDIR directory—that directory may not be writable. The tarball will have been extracted alongside the regular source by then, so there is no need to explicitly extract it if it is a regular gzipped or compressed tarball. If you do the latter, take extra care not to overwrite something that already exists in that directory. Also, do not forget to add a command to remove the copied patch in the pre-clean target. Multiple Distribution Files or Patches from Different Sites and Subdirectories (<literal>MASTER_SITES:n</literal>) (Consider this to be a somewhat advanced topic; those new to this document may wish to skip this section at first). This section has information on the fetching mechanism known as both MASTER_SITES:n and MASTER_SITES_NN. We will refer to this mechanism as MASTER_SITES:n. A little background first. OpenBSD has a neat feature inside the DISTFILES and PATCHFILES variables which allows files and patches to be postfixed with :n identifiers. Here, n can be both [0-9] and denote a group designation. For example: DISTFILES= alpha:0 beta:1 In OpenBSD, distribution file alpha will be associated with variable MASTER_SITES0 instead of our common MASTER_SITES and beta with MASTER_SITES1. This is a very interesting feature which can decrease that endless search for the correct download site. Just picture 2 files in DISTFILES and 20 sites in MASTER_SITES, the sites slow as hell where beta is carried by all sites in MASTER_SITES, and alpha can only be found in the 20th site. It would be such a waste to check all of them if the maintainer knew this beforehand, would it not? Not a good start for that lovely weekend! Now that you have the idea, just imagine more DISTFILES and more MASTER_SITES. Surely our distfiles survey meister would appreciate the relief to network strain that this would bring. In the next sections, information will follow on the FreeBSD implementation of this idea. We improved a bit on OpenBSD's concept. Simplified Information This section tells you how to quickly prepare fine grained fetching of multiple distribution files and patches from different sites and subdirectories. We describe here a case of simplified MASTER_SITES:n usage. This will be sufficient for most scenarios. However, if you need further information, you will have to refer to the next section. Some applications consist of multiple distribution files that must be downloaded from a number of different sites. For example, Ghostscript consists of the core of the program, and then a large number of driver files that are used depending on the user's printer. Some of these driver files are supplied with the core, but many others must be downloaded from a variety of different sites. To support this, each entry in DISTFILES may be followed by a colon and a tag name. Each site listed in MASTER_SITES is then followed by a colon, and the tag that indicates which distribution files should be downloaded from this site. For example, consider an application with the source split in two parts, source1.tar.gz and source2.tar.gz, which must be downloaded from two different sites. The port's Makefile would include lines like . Simplified Use of <literal>MASTER_SITES:n</literal> with One File Per Site MASTER_SITES= ftp://ftp.example1.com/:source1 \ ftp://ftp.example2.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 Multiple distribution files can have the same tag. Continuing the previous example, suppose that there was a third distfile, source3.tar.gz, that should be downloaded from ftp.example2.com. The Makefile would then be written like . Simplified Use of <literal>MASTER_SITES:n</literal> with More Than One File Per Site MASTER_SITES= ftp://ftp.example1.com/:source1 \ ftp://ftp.example2.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 \ source3.tar.gz:source2 Detailed Information Okay, so the previous section example did not reflect your needs? In this section we will explain in detail how the fine grained fetching mechanism MASTER_SITES:n works and how you can modify your ports to use it. Elements can be postfixed with :n where n is [^:,]+, i.e., n could conceptually be any alphanumeric string but we will limit it to [a-zA-Z_][0-9a-zA-Z_]+ for now. Moreover, string matching is case sensitive; i.e., n is different from N. However, the following words cannot be used for postfixing purposes since they yield special meaning: default, all and ALL (they are used internally in item ). Furthermore, DEFAULT is a special purpose word (check item ). Elements postfixed with :n belong to the group n, :m belong to group m and so forth. Elements without a postfix are groupless, i.e., they all belong to the special group DEFAULT. If you postfix any elements with DEFAULT, you are just being redundant unless you want to have an element belonging to both DEFAULT and other groups at the same time (check item ). The following examples are equivalent but the first one is preferred: MASTER_SITES= alpha MASTER_SITES= alpha:DEFAULT Groups are not exclusive, an element may belong to several different groups at the same time and a group can either have either several different elements or none at all. Repeated elements within the same group will be simply that, repeated elements. When you want an element to belong to several groups at the same time, you can use the comma operator (,). Instead of repeating it several times, each time with a different postfix, we can list several groups at once in a single postfix. For instance, :m,n,o marks an element that belongs to group m, n and o. All the following examples are equivalent but the last one is preferred: MASTER_SITES= alpha alpha:SOME_SITE MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE MASTER_SITES= alpha:SOME_SITE,DEFAULT MASTER_SITES= alpha:DEFAULT,SOME_SITE All sites within a given group are sorted according to MASTER_SORT_AWK. All groups within MASTER_SITES and PATCH_SITES are sorted as well. Group semantics can be used in any of the following variables MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR, PATCH_SITE_SUBDIR, DISTFILES, and PATCHFILES according to the following syntax: All MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR and PATCH_SITE_SUBDIR elements must be terminated with the forward slash / character. If any elements belong to any groups, the group postfix :n must come right after the terminator /. The MASTER_SITES:n mechanism relies on the existence of the terminator / to avoid confusing elements where a :n is a valid part of the element with occurrences where :n denotes group n. For compatibility purposes, since the / terminator was not required before in both MASTER_SITE_SUBDIR and PATCH_SITE_SUBDIR elements, if the postfix immediate preceding character is not a / then :n will be considered a valid part of the element instead of a group postfix even if an element is postfixed with :n. See both and . Detailed Use of <literal>MASTER_SITES:n</literal> in <makevar>MASTER_SITE_SUBDIR</makevar> MASTER_SITE_SUBDIR= old:n new/:NEW Directories within group DEFAULT -> old:n Directories within group NEW -> new Detailed Use of <literal>MASTER_SITES:n</literal> with Comma Operator, Multiple Files, Multiple Sites and Multiple Subdirectories MASTER_SITES= http://site1/%SUBDIR%/ http://site2/:DEFAULT \ http://site3/:group3 http://site4/:group4 \ http://site5/:group5 http://site6/:group6 \ http://site7/:DEFAULT,group6 \ http://site8/%SUBDIR%/:group6,group7 \ http://site9/:group8 DISTFILES= file1 file2:DEFAULT file3:group3 \ file4:group4,group5,group6 file5:grouping \ file6:group7 MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ directory-one/:group6,DEFAULT \ directory The previous example results in the following fine grained fetching. Sites are listed in the exact order they will be used. file1 will be fetched from MASTER_SITE_OVERRIDE http://site1/directory-trial:1/ http://site1/directory-one/ http://site1/directory/ http://site2/ http://site7/ MASTER_SITE_BACKUP file2 will be fetched exactly as file1 since they both belong to the same group MASTER_SITE_OVERRIDE http://site1/directory-trial:1/ http://site1/directory-one/ http://site1/directory/ http://site2/ http://site7/ MASTER_SITE_BACKUP file3 will be fetched from MASTER_SITE_OVERRIDE http://site3/ MASTER_SITE_BACKUP file4 will be fetched from MASTER_SITE_OVERRIDE http://site4/ http://site5/ http://site6/ http://site7/ http://site8/directory-one/ MASTER_SITE_BACKUP file5 will be fetched from MASTER_SITE_OVERRIDE MASTER_SITE_BACKUP file6 will be fetched from MASTER_SITE_OVERRIDE http://site8/ MASTER_SITE_BACKUP How do I group one of the special variables from bsd.sites.mk, e.g., MASTER_SITE_SOURCEFORGE? See . Detailed Use of <literal>MASTER_SITES:n</literal> with <makevar>MASTER_SITE_SOURCEFORGE</makevar> MASTER_SITES= http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/} DISTFILES= something.tar.gz:sourceforge something.tar.gz will be fetched from all sites within MASTER_SITE_SOURCEFORGE. How do I use this with PATCH* variables? All examples were done with MASTER* variables but they work exactly the same for PATCH* ones as can be seen in . Simplified Use of <literal>MASTER_SITES:n</literal> with <makevar>PATCH_SITES</makevar> PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test What Does Change for Ports? What Does Not? All current ports remain the same. The MASTER_SITES:n feature code is only activated if there are elements postfixed with :n like elements according to the aforementioned syntax rules, especially as shown in item . The port targets remain the same: checksum, makesum, patch, configure, build, etc. With the obvious exceptions of do-fetch, fetch-list, master-sites and patch-sites. do-fetch: deploys the new grouping postfixed DISTFILES and PATCHFILES with their matching group elements within both MASTER_SITES and PATCH_SITES which use matching group elements within both MASTER_SITE_SUBDIR and PATCH_SITE_SUBDIR. Check . fetch-list: works like old fetch-list with the exception that it groups just like do-fetch. master-sites and patch-sites: (incompatible with older versions) only return the elements of group DEFAULT; in fact, they execute targets master-sites-default and patch-sites-default respectively. Furthermore, using target either master-sites-all or patch-sites-all is preferred to directly checking either MASTER_SITES or PATCH_SITES. Also, directly checking is not guaranteed to work in any future versions. Check item for more information on these new port targets. New port targets There are master-sites-n and patch-sites-n targets which will list the elements of the respective group n within MASTER_SITES and PATCH_SITES respectively. For instance, both master-sites-DEFAULT and patch-sites-DEFAULT will return the elements of group DEFAULT, master-sites-test and patch-sites-test of group test, and thereon. There are new targets master-sites-all and patch-sites-all which do the work of the old master-sites and patch-sites ones. They return the elements of all groups as if they all belonged to the same group with the caveat that it lists as many MASTER_SITE_BACKUP and MASTER_SITE_OVERRIDE as there are groups defined within either DISTFILES or PATCHFILES; respectively for master-sites-all and patch-sites-all. <makevar>DIST_SUBDIR</makevar> Do not let your port clutter /usr/ports/distfiles. If your port requires a lot of files to be fetched, or contains a file that has a name that might conflict with other ports (e.g., Makefile), set DIST_SUBDIR to the name of the port (${PORTNAME} or ${PKGNAMEPREFIX}${PORTNAME} should work fine). This will change DISTDIR from the default /usr/ports/distfiles to /usr/ports/distfiles/DIST_SUBDIR, and in effect puts everything that is required for your port into that subdirectory. It will also look at the subdirectory with the same name on the backup master site at ftp.FreeBSD.org. (Setting DISTDIR explicitly in your Makefile will not accomplish this, so please use DIST_SUBDIR.) This does not affect the MASTER_SITES you define in your Makefile. <makevar>ALWAYS_KEEP_DISTFILES</makevar> If your port uses binary distfiles and has a license that requires that the source code is provided with packages distributed in binary form, e.g., GPL, ALWAYS_KEEP_DISTFILES will instruct the &os; build cluster to keep a copy of the files specified in DISTFILES. Users of these ports will generally not need these files, so it is a good idea to only add the source distfiles to DISTFILES when PACKAGE_BUILDING is defined. Use of <makevar>ALWAYS_KEEP_DISTFILES</makevar> .if defined(PACKAGE_BUILDING) DISTFILES+= foo.tar.gz ALWAYS_KEEP_DISTFILES= yes .endif When adding extra files to DISTFILES, make sure you also add them to distinfo. Also, the additional files will normally be extracted into WRKDIR as well, which for some ports may lead to undesirable side effects and require special handling.
<makevar>MAINTAINER</makevar> Set your mail-address here. Please. :-) Note that only a single address without the comment part is allowed as a MAINTAINER value. The format used should be user@hostname.domain. Please do not include any descriptive text such as your real name in this entry—that merely confuses bsd.port.mk. The maintainer is responsible for keeping the port up to date, and ensuring the port works correctly. For a detailed description of the responsibilities of a port maintainer, refer to the The challenge for port maintainers section. Changes to the port will be sent to the maintainer of a port for review and approval before being committed. If the maintainer does not respond to an update request after two weeks (excluding major public holidays), then that is considered a maintainer timeout, and the update may be made without explicit maintainer approval. If the maintainer does not respond within three months, then that maintainer is considered absent without leave, and can be replaced as the maintainer of the particular port in question. Exceptions to this are anything maintained by the &a.portmgr;, or the &a.security-officer;. No unauthorized commits may ever be made to ports maintained by those groups. We reserve the right to modify the maintainer's submission to better match existing policies and style of the Ports Collection without explicit blessing from the submitter. Also, large infrastructural changes can result in a port being modified without the maintainer's consent. These kinds of changes will never affect the port's functionality. The &a.portmgr; reserves the right to revoke or override anyone's maintainership for any reason, and the &a.security-officer; reserves the right to revoke or override maintainership for security reasons. <makevar>COMMENT</makevar> This is a one-line description of the port. Please respect the following rules: Try to keep the COMMENT value at no longer than 70 characters, as this line will be used by the &man.pkg.info.1; utility to display a one-line summary of the port; Do not include the package name (or version number of the software); The comment should begin with a capital and end without a period; Do not start with an indefinite article (i.e., A or An); Names are capitalized (for example, Apache, JavaScript, Perl); For lists of words, use the Oxford comma (e.g., green, red, and blue); Spell check the text. Here is an example: COMMENT= Cat chasing a mouse all over the screen The COMMENT variable should immediately follow the MAINTAINER variable in the Makefile. <makevar>PORTSCOUT</makevar> Portscout is an automated distfile check utility for the &os; Ports Collection, described in detail in . The PORTSCOUT variable defines special conditions within which the Portscout distfile scanner should be restricted. Situations where the PORTSCOUT variable should be set include: When distfiles should be ignored, whether for specific versions, or specific minor revisions. For example, to exclude version 8.2 from distfile version checks because it is known to be broken, add: PORTSCOUT= ignore:8.2 When specific versions or specific major and minor revisions of a distfile should be checked. For example, if only version 0.6.4 should be monitored because newer versions have compatablity issues with &os;, add: PORTSCOUT= limit:^0\.6\.4 When URLs listing the available versions differ from the download URLs. For example, to limit distfile version checks to the download page for the databases/pgtune port, add: PORTSCOUT= site:http://pgfoundry.org/frs/?group_id=1000416 Dependencies Many ports depend on other ports. This is a very convenient feature of most Unix-like operating systems, including &os;. Multiple ports can share a common dependency, rather than bundling that dependency with every port or package that needs it. There are seven variables that can be used to ensure that all the required bits will be on the user's machine. There are also some pre-supported dependency variables for common cases, plus a few more to control the behavior of dependencies. <makevar>LIB_DEPENDS</makevar> This variable specifies the shared libraries this port depends on. It is a list of lib:dir:target tuples where lib is the name of the shared library, dir is the directory in which to find it in case it is not available, and target is the target to call in that directory. For example, LIB_DEPENDS= jpeg:${PORTSDIR}/graphics/jpeg will check for a shared jpeg library with any version, and descend into the graphics/jpeg subdirectory of your ports tree to build and install it if it is not found. The target part can be omitted if it is equal to DEPENDS_TARGET (which defaults to install). The lib part is a regular expression which is being looked up in the ldconfig -r output. Values such as intl.9 and intl.[5-7] are allowed. The first pattern, intl.9, will match only version 9 of intl, while intl.[5-7], will match any of: intl.5, intl.6 or intl.7. The dependency is checked twice, once from within the extract target and then from within the install target. Also, the name of the dependency is put into the package so that &man.pkg.add.1; will automatically install it if it is not on the user's system. <makevar>RUN_DEPENDS</makevar> This variable specifies executables or files this port depends on during run-time. It is a list of path:dir:target tuples where path is the name of the executable or file, dir is the directory in which to find it in case it is not available, and target is the target to call in that directory. If path starts with a slash (/), it is treated as a file and its existence is tested with test -e; otherwise, it is assumed to be an executable, and which -s is used to determine if the program exists in the search path. For example, RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:${PORTSDIR}/news/inn \ xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr will check if the file or directory /usr/local/news/bin/innd exists, and build and install it from the news/inn subdirectory of the ports tree if it is not found. It will also see if an executable called xmlcatmgr is in the search path, and descend into the textproc/xmlcatmgr subdirectory of your ports tree to build and install it if it is not found. In this case, innd is actually an executable; if an executable is in a place that is not expected to be in the search path, you should use the full pathname. The official search PATH used on the ports build cluster is /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin The dependency is checked from within the install target. Also, the name of the dependency is put into the package so that &man.pkg.add.1; will automatically install it if it is not on the user's system. The target part can be omitted if it is the same as DEPENDS_TARGET. A quite common situation is when RUN_DEPENDS is literally the same as BUILD_DEPENDS, especially if ported software is written in a scripted language or if it requires the same build and run-time environment. In this case, it is both tempting and intuitive to directly assign one to the other: RUN_DEPENDS= ${BUILD_DEPENDS} However, such assignment can pollute run-time dependencies with entries not defined in the port's original BUILD_DEPENDS. This happens because of &man.make.1;'s lazy evaluation of variable assignment. Consider a Makefile with USE_* variables, which are processed by ports/Mk/bsd.*.mk to augment initial build dependencies. For example, - USE_GMAKE=yes adds USES= gmake adds devel/gmake to BUILD_DEPENDS. To prevent such additional dependencies from polluting RUN_DEPENDS, take care to assign with expansion, i.e., expand the value before assigning it to the variable: RUN_DEPENDS:= ${BUILD_DEPENDS} <makevar>BUILD_DEPENDS</makevar> This variable specifies executables or files this port requires to build. Like RUN_DEPENDS, it is a list of path:dir:target tuples. For example, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip will check for an executable called unzip, and descend into the archivers/unzip subdirectory of your ports tree to build and install it if it is not found. build here means everything from extraction to compilation. The dependency is checked from within the extract target. The target part can be omitted if it is the same as DEPENDS_TARGET <makevar>FETCH_DEPENDS</makevar> This variable specifies executables or files this port requires to fetch. Like the previous two, it is a list of path:dir:target tuples. For example, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 will check for an executable called ncftp2, and descend into the net/ncftp2 subdirectory of your ports tree to build and install it if it is not found. The dependency is checked from within the fetch target. The target part can be omitted if it is the same as DEPENDS_TARGET. <makevar>EXTRACT_DEPENDS</makevar> This variable specifies executables or files this port requires for extraction. Like the previous, it is a list of path:dir:target tuples. For example, EXTRACT_DEPENDS= unzip:${PORTSDIR}/archivers/unzip will check for an executable called unzip, and descend into the archivers/unzip subdirectory of your ports tree to build and install it if it is not found. The dependency is checked from within the extract target. The target part can be omitted if it is the same as DEPENDS_TARGET. Use this variable only if the extraction does not already work (the default assumes gzip) and cannot be made to work using USE_ZIP or USE_BZIP2 described in . <makevar>PATCH_DEPENDS</makevar> This variable specifies executables or files this port requires to patch. Like the previous, it is a list of path:dir:target tuples. For example, PATCH_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract will descend into the java/jfc subdirectory of your ports tree to extract it. The dependency is checked from within the patch target. The target part can be omitted if it is the same as DEPENDS_TARGET. <makevar>USES</makevar> There several parameters exist for defining different kind of features and dependencies that the port in question uses. They can be specified by adding the following line to the Makefile of the port: USES= feature[:arguments] For the complete list of such values, please see . USES cannot be assigned after inclusion of bsd.port.pre.mk. <makevar>USE_<replaceable>*</replaceable></makevar> Several variables exist to define common dependencies shared by many ports. Their use is optional, but helps to reduce the verbosity of the port Makefiles. Each of them is styled as USE_*. These variables may be used only in the port Makefiles and ports/Mk/bsd.*.mk. They are not meant for user-settable options — use PORT_OPTIONS for that purpose. It is always incorrect to set any USE_* in /etc/make.conf. For instance, setting USE_GCC=3.4 would add a dependency on gcc34 for every port, including gcc34 itself! The <makevar>USE_<replaceable>*</replaceable></makevar> Variables Variable Means USE_BZIP2 The port's tarballs are compressed with bzip2. USE_ZIP The port's tarballs are compressed with zip. USE_GCC The port requires a specific version of gcc to build. The exact version can be specified with value such as 3.4. The minimal required version can be specified as 3.4+. The gcc from the base system is used when it satisfies the requested version, otherwise an appropriate gcc is compiled from ports and the CC and CXX variables are adjusted.
Variables related to gmake and the configure script are described in , while autoconf, automake and libtool are described in . Perl related variables are described in . X11 variables are listed in . deals with GNOME and with KDE related variables. documents Java variables, while contains information on Apache, PHP and PEAR modules. Python is discussed in , while Ruby in . provides variables used for SDL applications and finally, contains information on Xfce.
Minimal Version of a Dependency A minimal version of a dependency can be specified in any *_DEPENDS variable except LIB_DEPENDS using the following syntax: p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy The first field contains a dependent package name, which must match the entry in the package database, a comparison sign, and a package version. The dependency is satisfied if p5-Spiffy-0.26 or newer is installed on the machine. Notes on Dependencies As mentioned above, the default target to call when a dependency is required is DEPENDS_TARGET. It defaults to install. This is a user variable; it is never defined in a port's Makefile. If your port needs a special way to handle a dependency, use the :target part of the *_DEPENDS variables instead of redefining DEPENDS_TARGET. When you type make clean, its dependencies are automatically cleaned too. If you do not wish this to happen, define the variable NOCLEANDEPENDS in your environment. This may be particularly desirable if the port has something that takes a long time to rebuild in its dependency list, such as KDE, GNOME or Mozilla. To depend on another port unconditionally, use the variable ${NONEXISTENT} as the first field of BUILD_DEPENDS or RUN_DEPENDS. Use this only when you need to get the source of the other port. You can often save compilation time by specifying the target too. For instance BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract will always descend to the jpeg port and extract it. Circular Dependencies Are Fatal Do not introduce any circular dependencies into the ports tree! The ports building technology does not tolerate circular dependencies. If you introduce one, you will have someone, somewhere in the world, whose FreeBSD installation will break almost immediately, with many others quickly to follow. These can really be hard to detect; if in doubt, before you make that change, make sure you have done the following: cd /usr/ports; make index. That process can be quite slow on older machines, but you may be able to save a large number of people—including yourself— a lot of grief in the process. Problems Caused by Automatic Dependencies Dependencies must be declared either explicitly or by using the OPTIONS framework. Using other methods like automatic detection complicates indexing, which causes problems for port and package management. Wrong Declaration of an Optional Dependency .include <bsd.port.pre.mk> .if exists(${LOCALBASE}/bin/foo) LIB_DEPENDS= bar:${PORTSDIR}/foo/bar .endif The problem with trying to automatically add dependencies is that files and settings outside an individual port can change at any time. For example: an index is built, then a batch of ports are installed. But one of the ports installs the tested file. The index is now incorrect, because an installed port unexpectedly has a new dependency. The index may still be wrong even after rebuilding if other ports also determine their need for dependencies based on the existence of other files. Correct Declaration of an Optional Dependency OPTIONS_DEFINE= BAR BAR_DESC= Bar support .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MBAR} LIB_DEPENDS= bar:${PORTSDIR}/foo/bar .endif Testing option variables is the correct method. It will not cause inconsistencies in the index of a batch of ports, provided the options were defined prior to the index build. Simple scripts can then be used to automate the building, installation, and updating of these ports and their packages. <makevar>USE_</makevar> and <makevar>WANT_</makevar> USE_ variables are set by the port maintainer to define software on which this port depends. A port that needs Firefox would set USE_FIREFOX= yes Some USE_ variables can accept version numbers or other parameters. For example, a port that requires Apache 2.2 would set USE_APACHE= 22 For more control over dependencies in some cases, WANT_ variables are available to more precisely specify what is needed. For example, consider the mail/squirrelmail port. This port needs some PHP modules, which are listed in the USE_PHP variable: USE_PHP= session mhash gettext mbstring pcre openssl xml Those modules may be available in CLI or web versions, so the web version is selected with a WANT_ variable: WANT_PHP_WEB= yes Available USE_ and WANT_ variables are defined in the files in /usr/ports/Mk.
<makevar>MASTERDIR</makevar> If your port needs to build slightly different versions of packages by having a variable (for instance, resolution, or paper size) take different values, create one subdirectory per package to make it easier for users to see what to do, but try to share as many files as possible between ports. Typically you only need a very short Makefile in all but one of the directories if you use variables cleverly. In the sole Makefile, you can use MASTERDIR to specify the directory where the rest of the files are. Also, use a variable as part of PKGNAMESUFFIX so the packages will have different names. This will be best demonstrated by an example. This is part of japanese/xdvi300/Makefile; PORTNAME= xdvi PORTVERSION= 17 PKGNAMEPREFIX= ja- PKGNAMESUFFIX= ${RESOLUTION} : # default RESOLUTION?= 300 .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 400 @${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO_MSG} "Possible values are: 118, 240, 300 (default) and 400." @${FALSE} .endif japanese/xdvi300 also has all the regular patches, package files, etc. If you type make there, it will take the default value for the resolution (300) and build the port normally. As for other resolutions, this is the entire xdvi118/Makefile: RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include "${MASTERDIR}/Makefile" (xdvi240/Makefile and xdvi400/Makefile are similar). The MASTERDIR definition tells bsd.port.mk that the regular set of subdirectories like FILESDIR and SCRIPTDIR are to be found under xdvi300. The RESOLUTION=118 line will override the RESOLUTION=300 line in xdvi300/Makefile and the port will be built with resolution set to 118. Man Pages The MAN[1-9LN] variables will automatically add any manpages to pkg-plist (this means you must not list manpages in the pkg-plist—see generating PLIST for more). It also makes the install stage automatically compress or uncompress manpages depending on the setting of NO_MANCOMPRESS in /etc/make.conf. If your port tries to install multiple names for manpages using symlinks or hardlinks, you must use the MLINKS variable to identify these. The link installed by your port will be destroyed and recreated by bsd.port.mk to make sure it points to the correct file. Any manpages listed in MLINKS must not be listed in the pkg-plist. To specify whether the manpages are compressed upon installation, use the MANCOMPRESSED variable. This variable can take three values, yes, no and maybe. yes means manpages are already installed compressed, no means they are not, and maybe means the software already respects the value of NO_MANCOMPRESS so bsd.port.mk does not have to do anything special. - MANCOMPRESSED is automatically set to - yes if USE_IMAKE is set - and NO_INSTALL_MANPAGES is not set, and to - no otherwise. You do not have to - explicitly define it unless the default is not suitable for - your port. - If your port anchors its man tree somewhere other than PREFIX, you can use the MANPREFIX to set it. Also, if only manpages in certain sections go in a non-standard place, such as some perl modules ports, you can set individual man paths using MANsectPREFIX (where sect is one of 1-9, L or N). If your manpages go to language-specific subdirectories, set the name of the languages to MANLANG. The value of this variable defaults to "" (i.e., English only). Here is an example that puts it all together. MAN1= foo.1 MAN3= bar.3 MAN4= baz.4 MLINKS= foo.1 alt-name.8 MANLANG= "" ja MAN3PREFIX= ${PREFIX}/share/foobar MANCOMPRESSED= yes This states that six files are installed by this port; ${MANPREFIX}/man/man1/foo.1.gz ${MANPREFIX}/man/ja/man1/foo.1.gz ${PREFIX}/share/foobar/man/man3/bar.3.gz ${PREFIX}/share/foobar/man/ja/man3/bar.3.gz ${MANPREFIX}/man/man4/baz.4.gz ${MANPREFIX}/man/ja/man4/baz.4.gz Additionally ${MANPREFIX}/man/man8/alt-name.8.gz may or may not be installed by your port. Regardless, a symlink will be made to join the foo(1) manpage and alt-name(8) manpage. If only some manpages are translated, you can use several variables dynamically created from MANLANG content: MANLANG= "" de ja MAN1= foo.1 MAN1_EN= bar.1 MAN3_DE= baz.3 This translates into this list of files: ${MANPREFIX}/man/man1/foo.1.gz ${MANPREFIX}/man/de/man1/foo.1.gz ${MANPREFIX}/man/ja/man1/foo.1.gz ${MANPREFIX}/man/man1/bar.1.gz ${MANPREFIX}/man/de/man3/baz.3.gz Info Files If your package needs to install GNU info files, they should be listed in the INFO variable (without the trailing .info), one entry per document. These files are assumed to be installed to PREFIX/INFO_PATH. You can change INFO_PATH if your package uses a different location. However, this is not recommended. These entries contain just the path relative to PREFIX/INFO_PATH. For example, lang/gcc34 installs info files to PREFIX/INFO_PATH/gcc34, and INFO will be something like this: INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ... Appropriate installation/de-installation code will be automatically added to the temporary pkg-plist before package registration. Makefile Options Many applications can be built with optional or differing configurations. Examples include choice of natural (human) language, GUI versus command-line, or type of database to support. Users may need a different configuration than the default, so the ports system provides hooks the port author can use to control which variant will be built. Supporting these options properly will make users happy, and effectively provide two or more ports for the price of one. Knobs <makevar>WITH_<replaceable>*</replaceable></makevar> and <makevar>WITHOUT_<replaceable>*</replaceable></makevar> These variables are designed to be set by the system administrator. There are many that are standardized in the ports/KNOBS file. When creating a port, do not make knob names specific to a given application. For example in Avahi port, use WITHOUT_MDNS instead of WITHOUT_AVAHI_MDNS. You should not assume that a WITH_* necessarily has a corresponding WITHOUT_* variable and vice versa. In general, the default is simply assumed. Unless otherwise specified, these variables are only tested for being set or not set, rather than being set to a specific value such as YES or NO. Common <makevar>WITH_<replaceable>*</replaceable></makevar> and <makevar>WITHOUT_<replaceable>*</replaceable></makevar> Variables Variable Means - - WITHOUT_NLS - If set, says that internationalization is not - needed, which can save compile time. By default, - internationalization is used. - - WITH_OPENSSL_BASE Use the version of OpenSSL in the base system. WITH_OPENSSL_PORT Installs the version of OpenSSL from security/openssl, even if the base is up to date. - - - WITHOUT_X11 - Ports that can be built both with and - without X support are normally - built with X support. If this variable is - defined, then the version that does not have X - support will be built instead. -
Knob Naming Porters should use like-named knobs, both for the benefit of end-users and to help keep the number of knob names down. A list of popular knob names can be found in the KNOBS file. Knob names should reflect what the knob is and does. When a port has a lib-prefix in the PORTNAME the lib-prefix should be dropped in knob naming.
<makevar>OPTIONS</makevar> Background The OPTIONS_* variables give the user installing the port a dialog showing the available options, and then saves those options to /var/db/ports/${UNIQUENAME}/options. The next time the port is built, the options are reused. When the user runs make config (or runs make build for the first time), the framework checks for /var/db/ports/${UNIQUENAME}/options. If that file does not exist, the values of OPTIONS_* are used, and a dialog box is displayed where the options can be enabled or disabled. Then the options file is saved and the configured variables are used when building the port. If a new version of the port adds new OPTIONS, the dialog will be presented to the user with the saved values of old OPTIONS prefilled. make showconfig shows the saved configuration. Use make rmconfig to remove the saved configuration. Syntax OPTIONS_DEFINE contains a list of OPTIONS to be used. These are independent of each other and are not grouped: OPTIONS_DEFINE= OPT1 OPT2 Once defined, OPTIONS are described (optional, but strongly recommended): OPT1_DESC= Describe OPT1 OPT2_DESC= Describe OPT2 OPT3_DESC= Describe OPT3 OPT4_DESC= Describe OPT4 OPT5_DESC= Describe OPT5 OPT6_DESC= Describe OPT6 ports/Mk/bsd.options.desc.mk has descriptions for many common OPTIONS; there is usually no need to override these. When describing options, view it from the perspective of the user: What does it do? and Why would I want to enable this? Do not just repeat the name. For example, describing the NLS option as include NLS support does not help the user, who can already see the option name but may not know what it means. Describing it as Native Language Support via gettext utilities is much more helpful. OPTIONS can be grouped as radio choices, where only one choice from each group is allowed: OPTIONS_SINGLE= SG1 OPTIONS_SINGLE_SG1= OPT3 OPT4 OPTIONS can be grouped as radio choices, where none or only one choice from each group is allowed: OPTIONS_RADIO= RG1 OPTIONS_RADIO_RG1= OPT7 OPT8 OPTIONS can also be grouped as multiple-choice lists, where at least one option must be enabled: OPTIONS_MULTI= MG1 OPTIONS_MULTI_MG1= OPT5 OPT6 OPTIONS can also be grouped as multiple-choice lists, where none or any option can be enabled: OPTIONS_GROUP= GG1 OPTIONS_GROUP_GG1= OPT9 OPT10 OPTIONS are unset by default, unless they are listed in OPTIONS_DEFAULT: OPTIONS_DEFAULT= OPT1 OPT3 OPT6 OPTIONS definitions must appear before the inclusion of bsd.port.options.mk. The PORT_OPTIONS variable can only be tested after the inclusion of bsd.port.options.mk. Inclusion of bsd.port.pre.mk can be used instead, too, and is still widely used in ports written before the introduction of bsd.port.options.mk. But be aware that some variables will not work as expected after the inclusion of bsd.port.pre.mk, typically some USE_* flags. Simple Use of <makevar>OPTIONS</makevar> OPTIONS_DEFINE= FOO BAR FOO_DESC= Enable option foo BAR_DESC= Support feature bar OPTIONS_DEFAULT=FOO .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MFOO} CONFIGURE_ARGS+=--with-foo .else CONFIGURE_ARGS+=--without-foo .endif .if ${PORT_OPTIONS:MBAR} RUN_DEPENDS+= bar:${PORTSDIR}/bar/bar .endif .include <bsd.port.mk> Check for Unset Port <makevar>OPTIONS</makevar> .if ! ${PORT_OPTIONS:MEXAMPLES} CONFIGURE_ARGS+=--without-examples .endif Practical Use of <makevar>OPTIONS</makevar> OPTIONS_DEFINE= EXAMPLES OPTIONS_SINGLE= BACKEND OPTIONS_SINGLE_BACKEND= MYSQL PGSQL BDB OPTIONS_MULTI= AUTH OPTIONS_MULTI_AUTH= LDAP PAM SSL EXAMPLES_DESC= Install extra examples MYSQL_DESC= Use MySQL as backend PGSQL_DESC= Use PostgreSQL as backend BDB_DESC= Use Berkeley DB as backend LDAP_DESC= Build with LDAP authentication support PAM_DESC= Build with PAM support SSL_DESC= Build with OpenSSL support OPTIONS_DEFAULT= PGSQL LDAP SSL .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MPGSQL} USE_PGSQL= yes CONFIGURE_ARGS+= --with-postgres .else CONFIGURE_ARGS+= --without-postgres .endif .if ${PORT_OPTIONS:MICU} LIB_DEPENDS+= icuuc:${PORTSDIR}/devel/icu .endif .if ! ${PORT_OPTIONS:MEXAMPLES} CONFIGURE_ARGS+= --without-examples .endif # Check other OPTIONS .include <bsd.port.mk> Default Options The following options are always on by default. DOCS — build and install documentation. NLS — Native Language Support. EXAMPLES — build and install examples. IPV6 — IPv6 protocol support. There is no need to add these to OPTIONS_DEFAULT. To have them show up in the options selection dialog, however, they must be added to OPTIONS_DEFINE. Feature Auto-Activation When using a GNU configure script, keep an eye on which optional features are activated by auto-detection. Explicitly disable optional features you do not wish to be used by passing respective --without-xxx or --disable-xxx in CONFIGURE_ARGS. Wrong Handling of an Option .if ${PORT_OPTIONS:MFOO} LIB_DEPENDS+= foo:${PORTSDIR}/devel/foo CONFIGURE_ARGS+= --enable-foo .endif In the example above, imagine a library libfoo is installed on the system. The user does not want this application to use libfoo, so he toggled the option off in the make config dialog. But the application's configure script detects the library present in the system and includes its support in the resulting executable. Now when the user decides to remove libfoo from the system, the ports system does not protest (no dependency on libfoo was recorded) but the application breaks. Correct Handling of an Option .if ${PORT_OPTIONS:MFOO} LIB_DEPENDS+= foo:${PORTSDIR}/devel/foo CONFIGURE_ARGS+= --enable-foo .else CONFIGURE_ARGS+= --disable-foo .endif In the second example, the library libfoo is explicitly disabled. The configure script does not enable related features in the application, despite library's presence in the system. Under some circumstances, the shorthand conditional syntax can cause problems with complex constructs. If you receive errors such as Malformed conditional, an alternative syntax can be used. .if !empty(VARIABLE:MVALUE) # as an alternative to .if ${VARIABLE:MVALUE} + + Options Helpers + + There are some macros to help simplify conditional + values which differ based on the options set. + + If OPTIONS_SUB is set to + yes then each of the options added + to OPTIONS_DEFINE will be added to + PLIST_SUB, for example: + + OPTIONS_DEFINE= OPT1 +OPTIONS_SUB= yes + + is equivalent to: + + OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +PLIST_SUB+= OPT1="" +.else +PLIST_SUB+= OPT1="@comment " +.endif + + If X_CONFIGURE_ENABLE is set then + --enable-${X_CONFIGURE_ENABLE} + or --disable-${X_CONFIGURE_ENABLE} will + be added to CONFIGURE_ARGS depending on + the value of the optionX, for example: + + OPTIONS_DEFINE= OPT1 +OPT1_CONFIGURE_ENABLE= test + + is equivalent to: + + OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +CONFIGURE_ARGS+= --enable-test +.else +CONFIGURE_ARGS+= --disable-test +.endif + + If X_CONFIGURE_WITH is set then + --with-${X_CONFIGURE_WITH} + or --without-${X_CONFIGURE_WITH} will + be added to CONFIGURE_ARGS depending + on the status of the option X, + for example: + + OPTIONS_DEFINE= OPT1 +OPT1_CONFIGURE_WITH= test + + is equivalent to: + + OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +CONFIGURE_ARGS+= --with-test +.else +CONFIGURE_ARGS+= --without-test +.endif + + If X_CONFIGURE_ON is set then its value + will be appended to CONFIGURE_ARGS depending + on the status of the option X, for example: + + + OPTIONS_DEFINE= OPT1 +OPT1_CONFIGURE_ON= --add-test + + is equivalent to: + + OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +CONFIGURE_ARGS+= --add-test +.endif + + If X_CONFIGURE_OFF is set then its value + will be appended to CONFIGURE_ARGS depending + on the status of the option X, for example: + + + OPTIONS_DEFINE= OPT1 +OPT1_CONFIGURE_OFF= --no-test + + is equivalent to: + + OPTIONS_DEFINE= OPT1 +.include <bsd.port.options.mk> +.if ! ${PORT_OPTIONS:MOPT1} +CONFIGURE_ARGS+= --no-test +.endif + + If X_CMAKE_ON is set then its value + will be appended to CMAKE_ARGS depending + on the status of the option X, for example: + + + OPTIONS_DEFINE= OPT1 +OPT1_CMAKE_ON= -DTEST:BOOL=true + + is equivalent to: + + OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +CMAKE_ARGS+= -DTEST:BOOL=true +.endif + + If X_CMAKE_OFF is set then its value + will be appended to CMAKE_ARGS depending + on the status of the option X, for example: + + + OPTIONS_DEFINE= OPT1 +OPT1_CMAKE_OFF= -DTEST:BOOL=false + + is equivalent to: + + OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ! ${PORT_OPTIONS:MOPT1} +CMAKE_ARGS+= -DTEST:BOOL=false +.endif + + For any of the following variables: + + + + CFLAGS + + + + CXXFLAGS + + + + LDLAGS + + + + CONFIGURE_ENV + + + + MAKE_ENV + + + + USES + + + + DISTFILES + + + + If X_ABOVEVARIABLE is defined then + its value will be appended to + ABOVEVARIABLE depending on the status of + the option X, for example: + + OPTIONS_DEFINE= OPT1 +OPT1_USES= gmake +OPT1_CFLAGS= -DTEST + + is equivalent to: + + OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +USES+= gmake +CFLAGS+= -DTEST +.endif + + For any of the following dependency type: + + + + PKG_DEPENDS + + + + EXTRACT_DEPENDS + + + + PATCH_DEPENDS + + + + FETCH_DEPENDS + + + + BUILD_DEPENDS + + + + LIB_DEPENDS + + + + RUN_DEPENDS + + + + If X_ABOVEVARIABLE is defined then + its value will be appended to + ABOVEVARIABLE depending on the status + of the option X, for example: + + OPTIONS_DEFINE= OPT1 +OPT1_LIB_DEPENDS= liba.so:${PORTSDIR}/devel/a + + is equivalent to: + + OPTIONS_DEFINE= OPT1 + +.include <bsd.port.options.mk> + +.if ${PORT_OPTIONS:MOPT1} +LIB_DEPENDS+= liba.so:${PORTSDIR}/devel/a +.endif +
Specifying the Working Directory Each port is extracted in to a working directory, which must be writable. The ports system defaults to having the DISTFILES unpack in to a directory called ${DISTNAME}. In other words, if you have set: PORTNAME= foo PORTVERSION= 1.0 then the port's distribution files contain a top-level directory, foo-1.0, and the rest of the files are located under that directory. There are a number of variables you can override if that is not the case. <makevar>WRKSRC</makevar> The variable lists the name of the directory that is created when the application's distfiles are extracted. If our previous example extracted into a directory called foo (and not foo-1.0) you would write: WRKSRC= ${WRKDIR}/foo or possibly WRKSRC= ${WRKDIR}/${PORTNAME} <makevar>NO_WRKSUBDIR</makevar> If the port does not extract in to a subdirectory at all then you should set NO_WRKSUBDIR to indicate that. NO_WRKSUBDIR= yes Conflict Handling There are three different variables to register a conflict between packages and ports: CONFLICTS, CONFLICTS_INSTALL and CONFLICTS_BUILD. The conflict variables automatically set the variable IGNORE, which is more fully documented in . When removing one of several conflicting ports, it is advisable to retain the CONFLICTS entries in those other ports for a few months to cater for users who only update once in a while. <makevar>CONFLICTS_INSTALL</makevar> If your package cannot coexist with other packages (because of file conflicts, runtime incompatibilities, etc.), list the other package names in the CONFLICTS_INSTALL variable. You can use shell globs like * and ? here. Package names should be enumerated the same way they appear in /var/db/pkg. Please make sure that CONFLICTS_INSTALL does not match this port's package itself. Otherwise enforcing its installation with FORCE_PKG_REGISTER will no longer work. The CONFLICTS_INSTALL check is done after the build stage and prior to the install stage. <makevar>CONFLICTS_BUILD</makevar> If your port cannot be built if a certain port is already installed, list the other port names in the CONFLICTS_BUILD variable. You can use shell globs like * and ? here. Package names should be enumerated the same way they appear in /var/db/pkg. The CONFLICTS_BUILD check is done prior to the build stage. Build conflicts are not recorded in the resulting package. <makevar>CONFLICTS</makevar> If your port cannot be built if a certain port is already installed and the resulting package cannot coexist with the other package, list the other package name in the CONFLICTS variable. You can use shell globs like * and ? here. Packages names should be enumerated the same way they appear in /var/db/pkg. Please make sure that CONFLICTS_INSTALL does not match this port's package itself. Otherwise enforcing its installation with FORCE_PKG_REGISTER will no longer work. The CONFLICTS check is done prior to the build stage and prior to the install stage. Installing Files <makevar>INSTALL_*</makevar> Macros Do use the macros provided in bsd.port.mk to ensure correct modes and ownership of files in your own *-install targets. INSTALL_PROGRAM is a command to install binary executables. INSTALL_SCRIPT is a command to install executable scripts. INSTALL_LIB is a command to install shared libraries. INSTALL_KLD is a command to install kernel loadable modules. Some architectures do not like having the modules stripped, so use this command instead of INSTALL_PROGRAM. INSTALL_DATA is a command to install sharable data. INSTALL_MAN is a command to install manpages and other documentation (it does not compress anything). These are basically the install command with all the appropriate flags. Stripping Binaries and Shared Libraries Do not strip binaries manually unless you have to. All binaries should be stripped, but the INSTALL_PROGRAM macro will install and strip a binary at the same time (see the next section). The INSTALL_LIB macro does the same thing to shared libraries. If you need to strip a file, but wish to use neither INSTALL_PROGRAM nor INSTALL_LIB macros, ${STRIP_CMD} will strip your program or shared library. This is typically done within the post-install target. For example: post-install: ${STRIP_CMD} ${PREFIX}/bin/xdl Use the &man.file.1; command on the installed executable to check whether the binary is stripped or not. If it does not say not stripped, it is stripped. Additionally, &man.strip.1; will not strip a previously stripped program; it will instead exit cleanly. Installing a Whole Tree of Files Sometimes, there is a need to install a big number of files, preserving their hierarchical organization, i.e., copying over a whole directory tree from WRKSRC to a target directory under PREFIX. Two macros exist for this situation. The advantage of using these macros instead of cp is that they guarantee proper file ownership and permissions on target files. The first macro, COPYTREE_BIN, will set all the installed files to be executable, thus being suitable for installing into PREFIX/bin. The second macro, COPYTREE_SHARE, does not set executable permissions on files, and is therefore suitable for installing files under PREFIX/share target. post-install: ${MKDIR} ${EXAMPLESDIR} (cd ${WRKSRC}/examples && ${COPYTREE_SHARE} . ${EXAMPLESDIR}) This example will install the contents of examples directory in the vendor distfile to the proper examples location of your port. post-install: ${MKDIR} ${DATADIR}/summer (cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${DATADIR}/summer) And this example will install the data of summer months to the summer subdirectory of a DATADIR. Additional find arguments can be passed via the third argument to the COPYTREE_* macros. For example, to install all files from the first example except Makefiles, one can use the following command. post-install: ${MKDIR} ${EXAMPLESDIR} (cd ${WRKSRC}/examples && \ ${COPYTREE_SHARE} . ${EXAMPLESDIR} "! -name Makefile") Note that these macros does not add the installed files to pkg-plist. You still need to list them. Install Additional Documentation If your software has some documentation other than the standard man and info pages that you think is useful for the user, install it under PREFIX/share/doc. This can be done, like the previous item, in the post-install target. Create a new directory for your port. The directory name should reflect what the port is. This usually means PORTNAME. However, if you think the user might want different versions of the port to be installed at the same time, you can use the whole PKGNAME. Make the installation dependent on the variable DOCS option so that users can disable it in /etc/make.conf, like this: post-install: .if ${PORT_OPTIONS:MDOCS} ${MKDIR} ${DOCSDIR} ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR} .endif Here are some handy variables and how they are expanded by default when used in the Makefile: DATADIR gets expanded to PREFIX/share/PORTNAME. DATADIR_REL gets expanded to share/PORTNAME. DOCSDIR gets expanded to PREFIX/share/doc/PORTNAME. DOCSDIR_REL gets expanded to share/doc/PORTNAME. EXAMPLESDIR gets expanded to PREFIX/share/examples/PORTNAME. EXAMPLESDIR_REL gets expanded to share/examples/PORTNAME. The DOCS option only controls additional documentation installed in DOCSDIR. It does not apply to standard man pages and info pages. Things installed in DATADIR and EXAMPLESDIR are controlled by DATA and EXAMPLES options, respectively. These variables are exported to PLIST_SUB. Their values will appear there as pathnames relative to PREFIX if possible. That is, share/doc/PORTNAME will be substituted for %%DOCSDIR%% in the packing list by default, and so on. (See more on pkg-plist substitution here.) All conditionally installed documentation files and directories should be included in pkg-plist with the %%PORTDOCS%% prefix, for example: %%PORTDOCS%%%%DOCSDIR%%/AUTHORS %%PORTDOCS%%%%DOCSDIR%%/CONTACT %%PORTDOCS%%@dirrm %%DOCSDIR%% As an alternative to enumerating the documentation files in pkg-plist, a port can set the variable PORTDOCS to a list of file names and shell glob patterns to add to the final packing list. The names will be relative to DOCSDIR. Therefore, a port that utilizes PORTDOCS and uses a non-default location for its documentation should set DOCSDIR accordingly. If a directory is listed in PORTDOCS or matched by a glob pattern from this variable, the entire subtree of contained files and directories will be registered in the final packing list. If the DOCS option has been unset then files and directories listed in PORTDOCS would not be installed or added to port packing list. Installing the documentation at PORTDOCS as shown above remains up to the port itself. A typical example of utilizing PORTDOCS looks as follows: PORTDOCS= README.* ChangeLog docs/* The equivalents of PORTDOCS for files installed under DATADIR and EXAMPLESDIR are PORTDATA and PORTEXAMPLES, respectively. You can also use the pkg-message file to display messages upon installation. See the section on using pkg-message for details. The pkg-message file does not need to be added to pkg-plist. Subdirectories Under <makevar>PREFIX</makevar> Try to let the port put things in the right subdirectories of PREFIX. Some ports lump everything and put it in the subdirectory with the port's name, which is incorrect. Also, many ports put everything except binaries, header files and manual pages in a subdirectory of lib, which does not work well with the BSD paradigm. Many of the files should be moved to one of the following: etc (setup/configuration files), libexec (executables started internally), sbin (executables for superusers/managers), info (documentation for info browser) or share (architecture independent files). See &man.hier.7; for details; the rules governing /usr pretty much apply to /usr/local too. The exception are ports dealing with USENET news. They may use PREFIX/news as a destination for their files.
Special Considerations There are some more things you have to take into account when you create a port. This section explains the most common of those. Shared Libraries If your port installs one or more shared libraries, define a USE_LDCONFIG make variable, which will instruct a bsd.port.mk to run ${LDCONFIG} -m on the directory where the new library is installed (usually PREFIX/lib) during post-install target to register it into the shared library cache. This variable, when defined, will also facilitate addition of an appropriate @exec /sbin/ldconfig -m and @unexec /sbin/ldconfig -R pair into your pkg-plist file, so that a user who installed the package can start using the shared library immediately and de-installation will not cause the system to still believe the library is there. USE_LDCONFIG= yes If you need, you can override the default directory by setting the USE_LDCONFIG value to a list of directories into which shared libraries are to be installed. For example if your port installs shared libraries into PREFIX/lib/foo and PREFIX/lib/bar directories you could use the following in your Makefile: USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar Please double-check, often this is not necessary at all or can be avoided through -rpath or setting LD_RUN_PATH during linking (see lang/moscow_ml for an example), or through a shell-wrapper which sets LD_LIBRARY_PATH before invoking the binary, like www/seamonkey does. When installing 32-bit libraries on 64-bit system, use USE_LDCONFIG32 instead. Try to keep shared library version numbers in the libfoo.so.0 format. Our runtime linker only cares for the major (first) number. When the major library version number increments in the update to the new port version, all other ports that link to the affected library should have their PORTREVISION incremented, to force recompilation with the new library version. Ports with Distribution Restrictions Licenses vary, and some of them place restrictions on how the application can be packaged, whether it can be sold for profit, and so on. It is your responsibility as a porter to read the licensing terms of the software and make sure that the FreeBSD project will not be held accountable for violating them by redistributing the source or compiled binaries either via FTP/HTTP or CD-ROM. If in doubt, please contact the &a.ports;. In situations like this, the variables described in the following sections can be set. <makevar>NO_PACKAGE</makevar> This variable indicates that we may not generate a binary package of the application. For instance, the license may disallow binary redistribution, or it may prohibit distribution of packages created from patched sources. However, the port's DISTFILES may be freely mirrored on FTP/HTTP. They may also be distributed on a CD-ROM (or similar media) unless NO_CDROM is set as well. NO_PACKAGE should also be used if the binary package is not generally useful, and the application should always be compiled from the source code. For example, if the application has configuration information that is site specific hard coded in to it at compile time, set NO_PACKAGE. NO_PACKAGE should be set to a string describing the reason why the package should not be generated. <makevar>NO_CDROM</makevar> This variable alone indicates that, although we are allowed to generate binary packages, we may put neither those packages nor the port's DISTFILES onto a CD-ROM (or similar media) for resale. However, the binary packages and the port's DISTFILES will still be available via FTP/HTTP. If this variable is set along with NO_PACKAGE, then only the port's DISTFILES will be available, and only via FTP/HTTP. NO_CDROM should be set to a string describing the reason why the port cannot be redistributed on CD-ROM. For instance, this should be used if the port's license is for non-commercial use only. <makevar>NOFETCHFILES</makevar> Files defined in the NOFETCHFILES variable are not fetchable from any of the MASTER_SITES. An example of such a file is when the file is supplied on CD-ROM by the vendor. Tools which check for the availability of these files on the MASTER_SITES should ignore these files and not report about them. <makevar>RESTRICTED</makevar> Set this variable alone if the application's license permits neither mirroring the application's DISTFILES nor distributing the binary package in any way. NO_CDROM or NO_PACKAGE should not be set along with RESTRICTED since the latter variable implies the former ones. RESTRICTED should be set to a string describing the reason why the port cannot be redistributed. Typically, this indicates that the port contains proprietary software and that the user will need to manually download the DISTFILES, possibly after registering for the software or agreeing to accept the terms of an EULA. <makevar>RESTRICTED_FILES</makevar> When RESTRICTED or NO_CDROM is set, this variable defaults to ${DISTFILES} ${PATCHFILES}, otherwise it is empty. If only some of the distribution files are restricted, then set this variable to list them. Note that the port committer should add an entry to /usr/ports/LEGAL for every listed distribution file, describing exactly what the restriction entails. Examples The preferred way to state "the distfiles for this port must be fetched manually" is as follows: .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) IGNORE= may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR} .endif This both informs the user, and sets the proper metadata on the user's machine for use by automated programs. Note that this stanza must be preceded by an inclusion of bsd.port.pre.mk. Building Mechanisms Building Ports in Parallel The &os; ports framework supports parallel building using multiple make sub-processes, which allows SMP systems to utilize all of their available CPU power, allowing port builds to be faster and more effective. This is achieved by passing -jX flag to &man.make.1; running on vendor code. Unfortunately, not all ports handle parallel building well. Therefore it is required to explicitly enable this feature by adding MAKE_JOBS_SAFE=yes somewhere below the dependency declaration section of the Makefile. Another option for controlling this feature from the maintainer's point of view is the MAKE_JOBS_UNSAFE=yes variable. It is used when a port is known to be broken with -jX and a user forces the use of multi processor compilations for all ports in /etc/make.conf with the FORCE_MAKE_JOBS=yes variable. <command>make</command>, <command>gmake</command>, and <command>imake</command> If your port uses GNU make, - set USE_GMAKE=yes. + set USES= gmake. Variables for Ports Related to <application>gmake</application> Variable Means - USE_GMAKE + USES= gmake The port requires gmake to build. GMAKE The full path for gmake if it is not in the PATH.
If your port is an X application that creates Makefile files from Imakefile files using imake, then set - USE_IMAKE=yes. This will cause the + USES= imake. This will cause the configure stage to automatically do an xmkmf -a. If the flag is a problem for your port, set XMKMF=xmkmf. If the port uses imake but does not understand the install.man target, NO_INSTALL_MANPAGES=yes should be set. If your port's source Makefile has something else than all as the main build target, set ALL_TARGET accordingly. Same goes for install and INSTALL_TARGET.
<command>configure</command> Script If your port uses the configure script to generate Makefile files from Makefile.in files, set GNU_CONFIGURE=yes. If you want to give extra arguments to the configure script (the default argument is --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}), set those extra arguments in CONFIGURE_ARGS. Extra environment variables can be passed using CONFIGURE_ENV variable. Variables for Ports That Use <command>configure</command> Variable Means GNU_CONFIGURE The port uses configure script to prepare build. HAS_CONFIGURE Same as GNU_CONFIGURE, except default configure target is not added to CONFIGURE_ARGS. CONFIGURE_ARGS Additional arguments passed to configure script. CONFIGURE_ENV Additional environment variables to be set for configure script run. CONFIGURE_TARGET Override default configure target. Default value is ${MACHINE_ARCH}-portbld-freebsd${OSREL}.
Using <command>cmake</command> For ports that use CMake, define USES= cmake, or USES= cmake:outsource to build in a separate directory (see below). Variables for Ports That Use <command>cmake</command> Variable Means CMAKE_ARGS Port specific CMake flags to be passed to the cmake binary. CMAKE_BUILD_TYPE Type of build (CMake predefined build profiles). Default is Release, or Debug if WITH_DEBUG is set. CMAKE_ENV Environment variables to be set for cmake binary. Default is ${CONFIGURE_ENV}. CMAKE_SOURCE_PATH Path to the source directory. Default is ${WRKSRC}.
CMake supports the following build profiles: Debug, Release, RelWithDebInfo and MinSizeRel. Debug and Release profiles respect system *FLAGS, RelWithDebInfo and MinSizeRel will set CFLAGS to -O2 -g and -Os -DNDEBUG correspondingly. The lower-cased value of CMAKE_BUILD_TYPE is exported to the PLIST_SUB and should be used if port installs *.cmake files depending on the build type (see deskutils/strigi for an example). Please note that some projects may define their own build profiles and/or force particular build type by setting CMAKE_BUILD_TYPE in CMakeLists.txt files. In order to make a port for such a project respect CFLAGS and WITH_DEBUG, the CMAKE_BUILD_TYPE definitions must be removed from those files. Most CMake-based projects support an out-of-source method of building. The out-of-source build for a port can be requested by using the :outsource suffix. When enabled, CONFIGURE_WRKSRC, BUILD_WRKSRC and INSTALL_WRKSRC will be set to ${WRKDIR}/.build and this directory will be used to keep all files generated during configuration and build stages, leaving the source directory intact. <literal>USES= cmake</literal> Example The following snippet demonstrates the use of CMake for a port. CMAKE_SOURCE_PATH is not usually required, but can be set when the sources are not located in the top directory, or if only a subset of the project is intended to be built by the port. USES= cmake:outsource CMAKE_SOURCE_PATH= ${WRKSRC}/subproject
Using <command>scons</command> If your port uses SCons, define USE_SCONS=yes. Variables for Ports That Use <command>scons</command> Variable Means SCONS_ARGS Port specific SCons flags passed to the SCons environment. SCONS_BUILDENV Variables to be set in system environment. SCONS_ENV Variables to be set in SCons environment. SCONS_TARGET Last argument passed to SCons, similar to MAKE_TARGET.
To make third party SConstruct respect everything that is passed to SCons in SCONS_ENV (that is, most importantly, CC/CXX/CFLAGS/CXXFLAGS), patch the SConstruct so build Environment is constructed like this: env = Environment(**ARGUMENTS) It may be then modified with env.Append and env.Replace.
Using GNU Autotools Introduction The various GNU autotools provide an abstraction mechanism for building a piece of software over a wide variety of operating systems and machine architectures. Within the Ports Collection, an individual port can make use of these tools via a simple construct: USE_AUTOTOOLS= tool:version[:operation] ... At the time of writing, tool can be one of libtool, libltdl, autoconf, autoheader, automake or aclocal. version specifies the particular tool revision to be used (see devel/{automake,autoconf,libtool}[0-9]+ for valid versions). operation is an optional extension to modify how the tool is used. Multiple tools can be specified at once, either by including them all on a single line, or using the += Makefile construct. Finally, there is the special tool, called autotools, which is a convenience function to bring in all available versions of the autotools to allow for cross-development work. This can also be accomplished by installing the devel/autotools port. <command>libtool</command> Shared libraries using the GNU building framework usually use libtool to adjust the compilation and installation of shared libraries to match the specifics of the underlying operating system. The usual practice is to use copy of libtool bundled with the application. In case you need to use external libtool, you can use the version provided by The Ports Collection: USE_AUTOTOOLS= libtool:version[:env] With no additional operations, libtool:version tells the building framework to patch the configure script with the system-installed copy of libtool. The GNU_CONFIGURE is implied. Further, a number of make and shell variables will be assigned for onward use by the port. See bsd.autotools.mk for details. With the :env operation, only the environment will be set up. Finally, LIBTOOLFLAGS and LIBTOOLFILES can be optionally set to override the most likely arguments to, and files patched by, libtool. Most ports are unlikely to need this. See bsd.autotools.mk for further details. <command>libltdl</command> Some ports make use of the libltdl library package, which is part of the libtool suite. Use of this library does not automatically necessitate the use of libtool itself, so a separate construct is provided. USE_AUTOTOOLS= libltdl:version Currently, all this does is to bring in a LIB_DEPENDS on the appropriate libltdl port, and is provided as a convenience function to help eliminate any dependencies on the autotools ports outside of the USE_AUTOTOOLS framework. There are no optional operations for this tool. <command>autoconf</command> and <command>autoheader</command> Some ports do not contain a configure script, but do contain an autoconf template in the configure.ac file. You can use the following assignments to let autoconf create the configure script, and also have autoheader create template headers for use by the configure script. USE_AUTOTOOLS= autoconf:version[:env] and USE_AUTOTOOLS= autoheader:version which also implies the use of autoconf:version. Similarly to libtool, the inclusion of the optional :env operation simply sets up the environment for further use. Without it, patching and reconfiguration of the port is carried out. The additional optional variables AUTOCONF_ARGS and AUTOHEADER_ARGS can be overridden by the port Makefile if specifically requested. As with the libtool equivalents, most ports are unlikely to need this. <command>automake</command> and <command>aclocal</command> Some packages only contain Makefile.am files. These have to be converted into Makefile.in files using automake, and the further processed by configure to generate an actual Makefile. Similarly, packages occasionally do not ship with included aclocal.m4 files, again required to build the software. This can be achieved with aclocal, which scans configure.ac or configure.in. aclocal has a similar relationship to automake as autoheader does to autoconf, described in the previous section. aclocal implies the use of automake, thus we have: USE_AUTOTOOLS= automake:version[:env] and USE_AUTOTOOLS= aclocal:version which also implies the use of automake:version. Similarly to libtool and autoconf, the inclusion of the optional :env operation simply sets up the environment for further use. Without it, reconfiguration of the port is carried out. As with autoconf and autoheader, both automake and aclocal have optional argument variables, AUTOMAKE_ARGS and ACLOCAL_ARGS respectively, which may be overridden by the port Makefile if required. Using GNU <literal>gettext</literal> Basic Usage If your port requires gettext, set USES= gettext, and your port will inherit a dependency on devel/gettext. Other values for gettext usage are listed in . A rather common case is a port using gettext and configure. Generally, GNU configure should be able to locate gettext automatically. If it ever fails to, hints at the location of gettext can be passed in CPPFLAGS and LDFLAGS as follows: USES= gettext CPPFLAGS+= -I${LOCALBASE}/include LDFLAGS+= -L${LOCALBASE}/lib GNU_CONFIGURE= yes Of course, the code can be more compact if there are no more flags to pass to configure: USES= gettext GNU_CONFIGURE= yes Optional Usage Some software products allow for disabling NLS, e.g., through passing to configure. In that case, your port should use gettext conditionally, - depending on the status of WITHOUT_NLS. + depending on the status of the NLS option. For ports of low to medium complexity, you can rely on the following idiom: GNU_CONFIGURE= yes .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MNLS} USES+= gettext PLIST_SUB+= NLS="" .else CONFIGURE_ARGS+= --disable-nls PLIST_SUB+= NLS="@comment " .endif .include <bsd.port.mk> The next item on your to-do list is to arrange so that the message catalog files are included in the packing list conditionally. The Makefile part of this task is already provided by the idiom. It is explained in the section on advanced pkg-plist practices. In a nutshell, each occurrence of %%NLS%% in pkg-plist will be replaced by @comment  if NLS is disabled, or by a null string if NLS is enabled. Consequently, the lines prefixed by %%NLS%% will become mere comments in the final packing list if NLS is off; otherwise the prefix will be just left out. All you need to do now is insert %%NLS%% before each path to a message catalog file in pkg-plist. For example: %%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo In high complexity cases, you may need to use more advanced techniques than the recipe given here, such as dynamic packing list generation. Handling Message Catalog Directories There is a point to note about installing message catalog files. The target directories for them, which reside under LOCALBASE/share/locale, should rarely be created and removed by a port. The most popular languages have their respective directories listed in PORTSDIR/Templates/BSD.local.dist. The directories for many other languages are governed by the devel/gettext port. Consult its pkg-plist and see whether the port is going to install a message catalog file for a unique language. Using <application>Perl</application> If MASTER_SITES is set to MASTER_SITE_PERL_CPAN, then the preferred value of MASTER_SITE_SUBDIR is the top-level hierarchy name. For example, the recommended value for p5-Module-Name is Module. The top-level hierarchy can be examined at cpan.org. This keeps the port working when the author of the module changes. The exception to this rule is when the relevant directory does not exist or the distfile does not exist in that directory. In such case, using author's id as MASTER_SITE_SUBDIR is allowed. All of the tunable knobs below accept either YES or a version string like 5.8.0+. YES means that the port can be used with any of the supported Perl versions. If a port only works with specific versions of Perl, it can be indicated with a version string, specifying a minimum version (e.g., 5.7.3+), a maximum version (e.g., 5.8.0-) or an exact version (e.g., 5.8.3). Variables for Ports That Use <application>Perl</application> Variable Meaning USE_PERL5 The port uses Perl 5 to build and run. USE_PERL5_BUILD The port uses Perl 5 to build. USE_PERL5_RUN The port uses Perl 5 to run. PERL The full path of the Perl 5 interpreter, either in the system or installed from a port, but without the version number. Use this if you need to replace #!lines in scripts. PERL_CONFIGURE Configure using Perl's MakeMaker. It implies USE_PERL5. PERL_MODBUILD Configure, build and install using Module::Build. It implies PERL_CONFIGURE. Read only variables Means PERL_VERSION The full version of Perl installed (e.g., 5.8.9). PERL_LEVEL The installed Perl version as an integer of the form MNNNPP (e.g., 500809). PERL_ARCH Where Perl stores architecture dependent libraries. Defaults to ${ARCH}-freebsd. PERL_PORT Name of the Perl port that is installed (e.g., perl5). SITE_PERL Directory name where site specific Perl packages go. This value is added to PLIST_SUB.
Ports of Perl modules which do not have an official website should link to cpan.org in the WWW line of pkg-descr. The preferred URL form is http://search.cpan.org/dist/Module-Name/ (including the trailing slash). Do not use ${SITE_PERL} in dependency declarations. Doing so assumes that bsd.perl.mk has been included, which is not always true. Ports depending on this port will have incorrect dependencies if this port's files move later in an upgrade. The right way to declare Perl module dependencies is shown in the example below. Perl Dependency Example p5-IO-Tee>=0.64:${PORTSDIR}/devel/p5-IO-Tee
Using X11 X.Org Components The X11 implementation available in The Ports Collection is X.Org. If your application depends on X components, set USE_XORG to the list of required components. Available components, at the time of writing, are: bigreqsproto compositeproto damageproto dmx dmxproto dri2proto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx pciaccess pixman printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xbitmaps xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto xkbfile xkbui xmu xmuu xorg-server xp xpm xprintapputil xprintutil xproto xproxymngproto xrandr xrender xres xscrnsaver xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm. Always up-to-date list can be found in /usr/ports/Mk/bsd.xorg.mk. The Mesa Project is an effort to provide free OpenGL implementation. You can specify a dependency on various components of this project with USE_GL variable. Valid options are: glut, glu, glw, glew, gl and linux. For backwards compatibility, the value of yes maps to glu. USE_XORG Example USE_XORG= xrender xft xkbfile xt xaw USE_GL= glu Variables for Ports That Use X - USE_IMAKE + USES= imake The port uses imake. XMKMF Set to the path of xmkmf if not in the PATH. Defaults to xmkmf -a.
- - Variables for Depending on Individual Parts of - X11 - - - - - X_IMAKE_PORT - Port providing imake and - several other utilities used to build X11. - - - - X_LIBRARIES_PORT - Port providing X11 libraries. - - - - X_CLIENTS_PORT - Port providing X clients. - - - - X_SERVER_PORT - Port providing X server. - - - - X_FONTSERVER_PORT - Port providing font server. - - - - X_PRINTSERVER_PORT - Port providing print server. - - - - X_VFBSERVER_PORT - Port providing virtual framebuffer - server. - - - - X_NESTSERVER_PORT - Port providing a nested X server. - - - - X_FONTS_ENCODINGS_PORT - Port providing encodings for fonts. - - - - X_FONTS_MISC_PORT - Port providing miscellaneous bitmap - fonts. - - - - X_FONTS_100DPI_PORT - Port providing 100dpi bitmap fonts. - - - - X_FONTS_75DPI_PORT - Port providing 75dpi bitmap fonts. - - - - X_FONTS_CYRILLIC_PORT - Port providing cyrillic bitmap fonts. - - - - X_FONTS_TTF_PORT - Port providing &truetype; fonts. - - - - X_FONTS_TYPE1_PORT - Port providing Type1 fonts. - - - - X_MANUALS_PORT - Port providing developer oriented manual - pages - - - -
- Using X11-Related Variables - # Use some X11 libraries and depend on -# font server as well as cyrillic fonts. -RUN_DEPENDS= ${LOCALBASE}/bin/xfs:${X_FONTSERVER_PORT} \ - ${LOCALBASE}/lib/X11/fonts/cyrillic/crox1c.pcf.gz:${X_FONTS_CYRILLIC_PORT} - + # Use some X11 libraries USE_XORG= x11 xpm
Ports That Require Motif If your port requires a Motif library, define - USE_MOTIF in the + USES= motif in the Makefile. Default Motif implementation is x11-toolkits/open-motif. Users can choose x11-toolkits/lesstif instead by setting WANT_LESSTIF variable. The MOTIFLIB variable will be set by bsd.port.mk to reference the appropriate Motif library. Please patch the source of your port to use ${MOTIFLIB} wherever the Motif library is referenced in the original Makefile or Imakefile. There are two common cases: If the port refers to the Motif library as -lXm in its Makefile or Imakefile, simply substitute ${MOTIFLIB} for it. If the port uses XmClientLibs in its Imakefile, change it to ${MOTIFLIB} ${XTOOLLIB} ${XLIB}. Note that MOTIFLIB (usually) expands to -L/usr/local/lib -lXm or /usr/local/lib/libXm.a, so there is no need to add -L or -l in front. X11 Fonts If your port installs fonts for the X Window System, put them in LOCALBASE/lib/X11/fonts/local. Getting a Fake <envar>DISPLAY</envar> with Xvfb Some applications require a working X11 display for compilation to succeed. This pose a problem for machines that operate headless. When the following variable is used, the build infrastructure will start the virtual framebuffer X server. The working DISPLAY is then passed to the build. USE_DISPLAY= yes Desktop Entries Desktop entries (a Freedesktop standard) provide a way to automatically adjust desktop features when a new program is installed, without requiring user intervention. For example, newly-installed programs automatically appear in the application menus of compatible desktop environments. Desktop entries originated in the GNOME desktop environment, but are now a standard and also work with KDE and Xfce. This bit of automation provides a real benefit to the user, and desktop entries are encouraged for applications which can be used in a desktop environment. Using Predefined <filename>.desktop</filename> Files Ports that include predefined *.desktop files should include those files in pkg-plist and install them in the $LOCALBASE/share/applications directory. The INSTALL_DATA macro is useful for installing these files. Updating Desktop Database If a port has a MimeType entry in its portname.desktop, the desktop database must be updated after install and deinstall. To do this, define USES= desktop-file-utils. Creating Desktop Entries with the <makevar>DESKTOP_ENTRIES</makevar> Macro Desktop entries can be easily created for applications by using the DESKTOP_ENTRIES variable. A file named name.desktop will be created, installed, and added to the pkg-plist automatically. Syntax is: DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify The list of possible categories is available on the Freedesktop website. StartupNotify indicates whether the application is compatible with startup notifications. These are typically a graphic indicator like a clock that appear at the mouse pointer, menu, or panel to give the user an indication when a program is starting. A program that is compatible with startup notifications clears the indicator after it has started. Programs that are not compatible with startup notifications would never clear the indicator (potentially confusing and infuriating the user), and should have StartupNotify set to false so the indicator is not shown at all. Example: DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \ "${DATADIR}/xtra/graf/tome-128.png" \ "tome -v -g" "Application;Game;RolePlaying;" \ false
Using GNOME The FreeBSD/GNOME project uses its own set of variables to define which GNOME components a particular port uses. A comprehensive list of these variables exists within the FreeBSD/GNOME project's homepage. Using Qt Ports That Require Qt Variables for Ports That Use Qt USE_QT_VER The port uses the Qt toolkit. The only possible value is 3. Appropriate parameters are passed to configure script and make. USE_QT4 Specify tool and library dependencies for ports that use Qt 4. See Qt 4 component selection for more details. QT_PREFIX Set to the path where Qt installed to (read-only variable). MOC Set to the path of moc (read-only variable). Default set according to USE_QT_VER value. QTCPPFLAGS Additional compiler flags passed via CONFIGURE_ENV for Qt toolkit. Default set according to USE_QT_VER. QTCFGLIBS Additional libraries for linking passed via CONFIGURE_ENV for Qt toolkit. Default set according to USE_QT_VER. QTNONSTANDARD Suppress modification of CONFIGURE_ENV, CONFIGURE_ARGS, CPPFLAGS and MAKE_ENV.
Additional Variables for Ports That Use Qt 4.x UIC Set to the path of uic (read-only variable). QMAKE Set to the path of qmake (read-only variable). QMAKESPEC Set to the path of configuration file for qmake (read-only variable). QMAKEFLAGS Additional flags for qmake. QT_INCDIR Set to Qt 4 include directories (read-only variable). QT_LIBDIR Set to Qt 4 libraries path (read-only variable). QT_PLUGINDIR Set to Qt 4 plugins path (read-only variable).
When USE_QT_VER is set to 3, some useful settings are passed to the configure script: CONFIGURE_ARGS+= --with-qt-includes=${QT_PREFIX}/include \ --with-qt-libraries=${QT_PREFIX}/lib \ --with-extra-libs=${LOCALBASE}/lib \ --with-extra-includes=${LOCALBASE}/include CONFIGURE_ENV+= MOC="${MOC}" LIBS="${QTCFGLIBS}" \ QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}" CPPFLAGS+= ${QTCPPFLAGS} If USE_QT4 is set, the following settings are deployed: CONFIGURE_ARGS+= --with-qt-includes=${QT_INCDIR} \ --with-qt-libraries=${QT_LIBDIR} \ --with-extra-libs=${LOCALBASE}/lib \ --with-extra-includes=${LOCALBASE}/include CONFIGURE_ENV+= MOC="${MOC}" UIC="${UIC}" LIBS="${QTCFGLIBS}" \ QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}" QTDIR="${QT_PREFIX}" MAKE_ENV+= QMAKESPEC="${QMAKESPEC}" PLIST_SUB+= QT_INCDIR_REL=${QT_INCDIR_REL} \ QT_LIBDIR_REL=${QT_LIBDIR_REL} \ QT_PLUGINDIR_REL=${QT_PLUGINDIR_REL}
Component Selection (Qt 4.x Only) Individual Qt 4 tool and library dependencies must be specified in the USE_QT4 variable. Every component can be suffixed by either _build or _run, the suffix indicating whether the component should be depended on at buildtime or runtime, respectively. If unsuffixed, the component will be depended on at both build- and runtime. Usually, library components should be specified unsuffixed, tool components should be specified with the _build suffix and plugin components should be specified with the _run suffix. The most commonly used components are listed below (all available components are listed in _USE_QT4_ALL in /usr/ports/Mk/bsd.qt.mk): Available Qt 4 Library Components Name Description corelib core library (can be omitted unless the port uses nothing but corelib) gui graphical user interface library network network library opengl OpenGL library qt3support Qt 3 compatibility library qtestlib unit testing library script script library sql SQL library xml XML library
You can determine which libraries the application depends on, by running ldd on the main executable after a successful compilation. Available Qt 4 Tool Components Name Description moc meta object compiler (needed for almost every Qt application at buildtime) qmake Makefile generator / build utility rcc resource compiler (needed if the application comes with *.rc or *.qrc files) uic user interface compiler (needed if the application comes with *.ui files created by Qt Designer - in practice, every Qt application with a GUI)
Available Qt 4 Plugin Components Name Description iconengines SVG icon engine plugin (if the application ships SVG icons) imageformats imageformat plugins for GIF, JPEG, MNG and SVG (if the application ships image files)
Selecting Qt 4 Components In this example, the ported application uses the Qt 4 graphical user interface library, the Qt 4 core library, all of the Qt 4 code generation tools and Qt 4's Makefile generator. Since the gui library implies a dependency on the core library, corelib does not need to be specified. The Qt 4 code generation tools moc, uic and rcc, as well as the Makefile generator qmake are only needed at buildtime, thus they are specified with the _build suffix: USE_QT4= gui moc_build qmake_build rcc_build uic_build
Additional Considerations If the application does not provide a configure file but a .pro file, you can use the following: HAS_CONFIGURE= yes do-configure: @cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \ ${QMAKE} ${QMAKEFLAGS} PREFIX=${PREFIX} texmaker.pro Note the similarity to the qmake line from the provided BUILD.sh script. Passing CONFIGURE_ENV ensures qmake will see the QMAKESPEC variable, without which it cannot work. qmake generates standard Makefiles, so it is not necessary to write our own build target. Qt applications often are written to be cross-platform and often X11/Unix is not the platform they are developed on, which in turn often leads to certain loose ends, like: Missing additional include paths. Many applications come with system tray icon support, but neglect to look for includes and/or libraries in the X11 directories. You can tell qmake to add directories to the include and library search paths via the command line, for example: ${QMAKE} ${QMAKEFLAGS} PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \ LIBS+=-L${LOCALBASE}/lib sillyapp.pro Bogus installation paths. Sometimes data such as icons or .desktop files are by default installed into directories which are not scanned by XDG-compatible applications. editors/texmaker is an example for this - look at patch-texmaker.pro in the files directory of that port for a template on how to remedy this directly in the qmake project file.
Using KDE - - Variable Definitions (KDE 3.x Only) - - - Variables for Ports That Use KDE 3.x - - - - - USE_KDELIBS_VER - The port uses KDE libraries. It specifies the - major version of KDE to use and implies - USE_QT_VER of the appropriate - version. The only possible value is - 3. - - - - USE_KDEBASE_VER - The port uses KDE base. It specifies the major - version of KDE to use and implies - USE_QT_VER of the appropriate - version. The only possible value is - 3. - - - -
-
- KDE 4 Variable Definitions If your application depends on KDE 4.x, set USE_KDE4 to the list of required components. _build and _run suffixes can be used to force components dependency type (e.g., baseapps_run). If no suffix is set, a default dependency type will be used. If you want to force both types, add the component twice with both suffixes (e.g., automoc4_build automoc4_run). The most commonly used components are listed below (up-to-date components are documented at the top of /usr/ports/Mk/bsd.kde4.mk): Available KDE 4 Components Name Description kdehier Hierarchy of common KDE directories kdelibs KDE Developer Platform kdeprefix If set, port will be installed into ${KDE4_PREFIX} instead of ${LOCALBASE} sharedmime MIME types database for KDE ports automoc4 Automatic moc for Qt 4 packages akonadi Storage server for KDE-Pim soprano Qt 4 RDF framework strigi Desktop search daemon libkcddb KDE CDDB library libkcompactdisc KDE library for interfacing with audio CDs libkdeedu Libraries used by educational applications libkdcraw KDE LibRaw library libkexiv2 KDE Exiv2 library libkipi KDE Image Plugin Interface libkonq Konqueror core library libksane KDE SANE ("Scanner Access Now Easy") library pimlibs KDE-Pim libraries kate Text editor framework marble Virtual globe okular Universal document viewer korundum KDE Ruby bindings perlkde KDE Perl bindings pykde4 KDE Python bindings pykdeuic4 PyKDE user interface compiler smokekde KDE SMOKE libraries
KDE 4.x ports are installed into KDE4_PREFIX, which is - /usr/local/kde4 currently, to avoid - conflicts with KDE 3.x ports. This is achieved by + /usr/local/kde4 currently. + This is achieved by specifying the kdeprefix component, which overrides the default PREFIX. The ports however respect any PREFIX set via MAKEFLAGS environment variable and/or make arguments. <makevar>USE_KDE4</makevar> Example This is a simple example for a KDE 4 port. USES= cmake:outsource instructs the port to utilize CMake, a configuration tool widely used by KDE 4 projects (see for detailed usage). USE_KDE4 brings dependency on KDE libraries and makes port using automoc4 at build stage. Required KDE components and other dependencies can be determined through configure log. USE_KDE4 does not imply USE_QT4. If a port requires some Qt 4 components, they should be specified in USE_QT4. USES= cmake:outsource USE_KDE4= kdelibs kdeprefix automoc4 USE_QT4= moc_build qmake_build rcc_build uic_build
Using Java Variable Definitions If your port needs a Java™ Development Kit (JDK™) to either build, run or even extract the distfile, then it should define USE_JAVA. There are several JDKs in the ports collection, from various vendors, and in several versions. If your port must use one of these versions, you can define which one. The most current version, and &os; default is java/openjdk6. Variables Which May be Set by Ports That Use Java Variable Means USE_JAVA Should be defined for the remaining variables to have any effect. JAVA_VERSION List of space-separated suitable Java versions for the port. An optional "+" allows you to specify a range of versions (allowed values: 1.5[+] 1.6[+] 1.7[+]). JAVA_OS List of space-separated suitable JDK port operating systems for the port (allowed values: native linux). JAVA_VENDOR List of space-separated suitable JDK port vendors for the port (allowed values: freebsd bsdjava sun openjdk). JAVA_BUILD When set, it means that the selected JDK port should be added to the build dependencies of the port. JAVA_RUN When set, it means that the selected JDK port should be added to the run dependencies of the port. JAVA_EXTRACT When set, it means that the selected JDK port should be added to the extract dependencies of the port.
Below is the list of all settings a port will receive after setting USE_JAVA: Variables Provided to Ports That Use Java Variable Value JAVA_PORT The name of the JDK port (e.g., 'java/openjdk6'). JAVA_PORT_VERSION The full version of the JDK port (e.g., '1.6.0'). If you only need the first two digits of this version number, use ${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}. JAVA_PORT_OS The operating system used by the JDK port (e.g., 'native'). JAVA_PORT_VENDOR The vendor of the JDK port (e.g., 'openjdk'). JAVA_PORT_OS_DESCRIPTION Description of the operating system used by the JDK port (e.g., 'Native'). JAVA_PORT_VENDOR_DESCRIPTION Description of the vendor of the JDK port (e.g., 'OpenJDK BSD Porting Team'). JAVA_HOME Path to the installation directory of the JDK (e.g., '/usr/local/openjdk6'). JAVAC Path to the Java compiler to use (e.g., '/usr/local/openjdk6/bin/javac'). JAR Path to the jar tool to use (e.g., '/usr/local/openjdk6/bin/jar' or '/usr/local/bin/fastjar'). APPLETVIEWER Path to the appletviewer utility (e.g., '/usr/local/openjdk6/bin/appletviewer'). JAVA Path to the java executable. Use this for executing Java programs (e.g., '/usr/local/openjdk6/bin/java'). JAVADOC Path to the javadoc utility program. JAVAH Path to the javah program. JAVAP Path to the javap program. JAVA_KEYTOOL Path to the keytool utility program. JAVA_N2A Path to the native2ascii tool. JAVA_POLICYTOOL Path to the policytool program. JAVA_SERIALVER Path to the serialver utility program. RMIC Path to the RMI stub/skeleton generator, rmic. RMIREGISTRY Path to the RMI registry program, rmiregistry. RMID Path to the RMI daemon program rmid. JAVA_CLASSES Path to the archive that contains the JDK class files, ${JAVA_HOME}/jre/lib/rt.jar.
You may use the java-debug make target to get information for debugging your port. It will display the value of many of the forecited variables. Additionally, the following constants are defined so all Java ports may be installed in a consistent way: Constants Defined for Ports That Use Java Constant Value JAVASHAREDIR The base directory for everything related to Java. Default: ${PREFIX}/share/java. JAVAJARDIR The directory where JAR files should be installed. Default: ${JAVASHAREDIR}/classes. JAVALIBDIR The directory where JAR files installed by other ports are located. Default: ${LOCALBASE}/share/java/classes.
The related entries are defined in both PLIST_SUB (documented in ) and SUB_LIST.
Building with Ant When the port is to be built using Apache Ant, it has to define USE_ANT. Ant is thus considered to be the sub-make command. When no do-build target is defined by the port, a default one will be set that simply runs Ant according to MAKE_ENV, MAKE_ARGS and ALL_TARGET. This is similar to the - USE_GMAKE mechanism, which is documented + USES= gmake mechanism, which is documented in . Best Practices When porting a Java library, your port should install the JAR file(s) in ${JAVAJARDIR}, and everything else under ${JAVASHAREDIR}/${PORTNAME} (except for the documentation, see below). In order to reduce the packing file size, you may reference the JAR file(s) directly in the Makefile. Just use the following statement (where myport.jar is the name of the JAR file installed as part of the port): PLIST_FILES+= %%JAVAJARDIR%%/myport.jar When porting a Java application, the port usually installs everything under a single directory (including its JAR dependencies). The use of ${JAVASHAREDIR}/${PORTNAME} is strongly encouraged in this regard. It is up the porter to decide whether the port should install the additional JAR dependencies under this directory or directly use the already installed ones (from ${JAVAJARDIR}). Regardless of the type of your port (library or application), the additional documentation should be installed in the same location as for any other port. The JavaDoc tool is known to produce a different set of files depending on the version of the JDK that is used. For ports that do not enforce the use of a particular JDK, it is therefore a complex task to specify the packing list (pkg-plist). This is one reason why porters are strongly encouraged to use the PORTDOCS macro. Moreover, even if you can predict the set of files that will be generated by javadoc, the size of the resulting pkg-plist advocates for the use of PORTDOCS. The default value for DATADIR is ${PREFIX}/share/${PORTNAME}. It is a good idea to override DATADIR to ${JAVASHAREDIR}/${PORTNAME} for Java ports. Indeed, DATADIR is automatically added to PLIST_SUB (documented in ) so you may use %%DATADIR%% directly in pkg-plist. As for the choice of building Java ports from source or directly installing them from a binary distribution, there is no defined policy at the time of writing. However, people from the &os; Java Project encourage porters to have their ports built from source whenever it is a trivial task. All the features that have been presented in this section are implemented in bsd.java.mk. If you ever think that your port needs more sophisticated Java support, please first have a look at the bsd.java.mk SVN log as it usually takes some time to document the latest features. Then, if you think the support you are lacking would be beneficial to many other Java ports, feel free to discuss it on the &a.java;. Although there is a java category for PRs, it refers to the JDK porting effort from the &os; Java project. Therefore, you should submit your Java port in the ports category as for any other port, unless the issue you are trying to resolve is related to either a JDK implementation or bsd.java.mk. Similarly, there is a defined policy regarding the CATEGORIES of a Java port, which is detailed in .
Web Applications, Apache and PHP Apache Variables for Ports That Use Apache USE_APACHE The port requires Apache. Possible values: yes (gets any version), 22, 24, 22-24, 22+, etc. The default APACHE version is 22. More details are available in ports/Mk/bsd.apache.mk and at wiki.freebsd.org/Apache/. APXS Full path to the apxs binary. Can be overridden in your port. HTTPD Full path to the httpd binary. Can be overridden in your port. APACHE_VERSION The version of present Apache installation (read-only variable). This variable is only available after inclusion of bsd.port.pre.mk. Possible values: 22, 24. APACHEMODDIR Directory for Apache modules. This variable is automatically expanded in pkg-plist. APACHEINCLUDEDIR Directory for Apache headers. This variable is automatically expanded in pkg-plist. APACHEETCDIR Directory for Apache configuration files. This variable is automatically expanded in pkg-plist.
Useful Variables for Porting Apache Modules MODULENAME Name of the module. Default value is PORTNAME. Example: mod_hello SHORTMODNAME Short name of the module. Automatically derived from MODULENAME, but can be overridden. Example: hello AP_FAST_BUILD Use apxs to compile and install the module. AP_GENPLIST Also automatically creates a pkg-plist. AP_INC Adds a directory to a header search path during compilation. AP_LIB Adds a directory to a library search path during compilation. AP_EXTRAS Additional flags to pass to apxs.
Web Applications Web applications should be installed into PREFIX/www/appname. For your convenience, this path is available both in Makefile and in pkg-plist as WWWDIR, and the path relative to PREFIX is available in Makefile as WWWDIR_REL. The user and group of web server process are available as WWWOWN and WWWGRP, in case you need to change the ownership of some files. The default values of both are www. If you want different values for your port, use WWWOWN?= myuser notation, to allow user to override it easily. Do not depend on Apache unless the web app explicitly needs Apache. Respect that users may wish to run your web app on different web server than Apache. PHP Variables for Ports That Use PHP USE_PHP The port requires PHP. The value yes adds a dependency on PHP. The list of required PHP extensions can be specified instead. Example: pcre xml gettext DEFAULT_PHP_VER Selects which major version of PHP will be installed as a dependency when no PHP is installed yet. Default is 5. Possible values: 4, 5 IGNORE_WITH_PHP The port does not work with PHP of the given version. Possible values: 4, 5 USE_PHPIZE The port will be built as a PHP extension. USE_PHPEXT The port will be treated as a PHP extension, including installation and registration in the extension registry. USE_PHP_BUILD Set PHP as a build dependency. WANT_PHP_CLI Want the CLI (command line) version of PHP. WANT_PHP_CGI Want the CGI version of PHP. WANT_PHP_MOD Want the Apache module version of PHP. WANT_PHP_SCR Want the CLI or the CGI version of PHP. WANT_PHP_WEB Want the Apache module or the CGI version of PHP.
PEAR Modules Porting PEAR modules is a very simple process. Use the variables FILES, TESTS, DATA, SQLS, SCRIPTFILES, DOCS and EXAMPLES to list the files you want to install. All listed files will be automatically installed into the appropriate locations and added to pkg-plist. Include ${PORTSDIR}/devel/pear/bsd.pear.mk on the last line of the Makefile. Example Makefile for PEAR Class PORTNAME= Date PORTVERSION= 1.4.3 CATEGORIES= devel www pear MAINTAINER= example@domain.com COMMENT= PEAR Date and Time Zone Classes BUILD_DEPENDS= ${PEARDIR}/PEAR.php:${PORTSDIR}/devel/pear-PEAR RUN_DEPENDS:= ${BUILD_DEPENDS} FILES= Date.php Date/Calc.php Date/Human.php Date/Span.php \ Date/TimeZone.php TESTS= test_calc.php test_date_methods_span.php testunit.php \ testunit_date.php testunit_date_span.php wknotest.txt \ bug674.php bug727_1.php bug727_2.php bug727_3.php \ bug727_4.php bug967.php weeksinmonth_4_monday.txt \ weeksinmonth_4_sunday.txt weeksinmonth_rdm_monday.txt \ weeksinmonth_rdm_sunday.txt DOCS= TODO _DOCSDIR= . .include <bsd.port.pre.mk> .include "${PORTSDIR}/devel/pear/bsd.pear.mk" .include <bsd.port.post.mk>
Using Python The Ports Collection supports parallel installation of multiple Python versions. Ports should make sure to use a correct python interpreter, according to the user-settable PYTHON_VERSION variable. Most prominently, this means replacing the path to python executable in scripts with the value of PYTHON_CMD variable. Ports that install files under PYTHON_SITELIBDIR should use the pyXY- package name prefix, so their package name embeds the version of Python they are installed into. PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} Most Useful Variables for Ports That Use Python USE_PYTHON The port needs Python. Minimal required version can be specified with values such as 2.6+. Version ranges can also be specified, by separating two version numbers with a dash, e.g.: 2.6-2.7 USE_PYDISTUTILS Use Python distutils for configuring, compiling and installing. This is required when the port comes with setup.py. This overrides the do-build and do-install targets and may also override do-configure if GNU_CONFIGURE is not defined. PYTHON_PKGNAMEPREFIX Used as a PKGNAMEPREFIX to distinguish packages for different Python versions. Example: py24- PYTHON_SITELIBDIR Location of the site-packages tree, that contains installation path of Python (usually LOCALBASE). The PYTHON_SITELIBDIR variable can be very useful when installing Python modules. PYTHONPREFIX_SITELIBDIR The PREFIX-clean variant of PYTHON_SITELIBDIR. Always use %%PYTHON_SITELIBDIR%% in pkg-plist when possible. The default value of %%PYTHON_SITELIBDIR%% is lib/python%%PYTHON_VERSION%%/site-packages PYTHON_CMD Python interpreter command line, including version number. PYNUMERIC Dependency line for numeric extension. PYNUMPY Dependency line for the new numeric extension, numpy. (PYNUMERIC is deprecated by upstream vendor). PYXML Dependency line for XML extension (not needed for Python 2.0 and higher as it is also in base distribution). USE_TWISTED Add dependency on twistedCore. The list of required components can be specified as a value of this variable. Example: web lore pair flow USE_ZOPE Add dependency on Zope, a web application platform. Change Python dependency to Python 2.7. Set ZOPEBASEDIR containing a directory with Zope installation.
A complete list of available variables can be found in /usr/ports/Mk/bsd.python.mk.
Using <application>Tcl/Tk</application> The Ports Collection supports parallel installation of multiple Tcl/Tk versions. Ports should try to support at least the default Tcl/Tk version and higher with the USE_TCL and USE_TK variables. It is possible to specify the desired version of tcl with the WITH_TCL_VER variable. The Most Useful Variables for Ports That Use <application>Tcl/Tk</application> USE_TCL The port depends on the Tcl library (not the shell). Minimal required version can be specified with values such as 84+. Individual unsupported versions can be specified with the INVALID_TCL_VER variable. USE_TCL_BUILD The port needs Tcl only during the build time. USE_TCL_WRAPPER Ports that require the Tcl shell and do not require a specific tclsh version should use this new variable. The tclsh wrapper is installed on the system. The user can specify the desired tcl shell to use. WITH_TCL_VER User-defined variable that sets the desired Tcl version. UNIQUENAME_WITH_TCL_VER Like WITH_TCL_VER, but per-port. USE_TCL_THREADS Require a threaded build of Tcl/Tk. USE_TK The port depends on the Tk library (not the wish shell). Implies USE_TCL with the same value. For more information see the description of USE_TCL variable. USE_TK_BUILD Analog to the USE_TCL_BUILD variable. USE_TK_WRAPPER Analog to the USE_TCL_WRAPPER variable. WITH_TK_VER Analog to the WITH_TCL_VER variable and implies WITH_TCL_VER of the same value.
A complete list of available variables can be found in /usr/ports/Mk/bsd.tcl.mk.
Using Emacs This section is yet to be written. Using Ruby Useful Variables for Ports That Use Ruby Variable Description USE_RUBY The port requires Ruby. USE_RUBY_EXTCONF The port uses extconf.rb to configure. USE_RUBY_SETUP The port uses setup.rb to configure. RUBY_SETUP Set to the alternative name of setup.rb. Common value is install.rb.
The following table shows the selected variables available to port authors via the ports infrastructure. These variables should be used to install files into their proper locations. Use them in pkg-plist as much as possible. These variables should not be redefined in the port. Selected Read-Only Variables for Ports That Use Ruby Variable Description Example value RUBY_PKGNAMEPREFIX Used as a PKGNAMEPREFIX to distinguish packages for different Ruby versions. ruby18- RUBY_VERSION Full version of Ruby in the form of x.y.z. 1.8.2 RUBY_SITELIBDIR Architecture independent libraries installation path. /usr/local/lib/ruby/site_ruby/1.8 RUBY_SITEARCHLIBDIR Architecture dependent libraries installation path. /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6 RUBY_MODDOCDIR Module documentation installation path. /usr/local/share/doc/ruby18/patsy RUBY_MODEXAMPLESDIR Module examples installation path. /usr/local/share/examples/ruby18/patsy
A complete list of available variables can be found in /usr/ports/Mk/bsd.ruby.mk.
Using SDL The USE_SDL variable is used to autoconfigure the dependencies for ports which use an SDL based library like devel/sdl12 and x11-toolkits/sdl_gui. The following SDL libraries are recognized at the moment: sdl: devel/sdl12 gfx: graphics/sdl_gfx gui: x11-toolkits/sdl_gui image: graphics/sdl_image ldbad: devel/sdl_ldbad mixer: audio/sdl_mixer mm: devel/sdlmm net: net/sdl_net sound: audio/sdl_sound ttf: graphics/sdl_ttf Therefore, if a port has a dependency on net/sdl_net and audio/sdl_mixer, the syntax will be: USE_SDL= net mixer The dependency devel/sdl12, which is required by net/sdl_net and audio/sdl_mixer, is automatically added as well. If you use USE_SDL, it will automatically: Add a dependency on sdl12-config to BUILD_DEPENDS Add the variable SDL_CONFIG to CONFIGURE_ENV Add the dependencies of the selected libraries to the LIB_DEPENDS To check whether an SDL library is available, you can do it with the WANT_SDL variable: WANT_SDL= yes .include <bsd.port.pre.mk> .if ${HAVE_SDL:Mmixer}!="" USE_SDL+= mixer .endif .include <bsd.port.post.mk> Using <application>wxWidgets</application> This section describes the status of the wxWidgets libraries in the ports tree and its integration with the ports system. Introduction There are many versions of the wxWidgets libraries which conflict between them (install files under the same name). In the ports tree this problem has been solved by installing each version under a different name using version number suffixes. The obvious disadvantage of this is that each application has to be modified to find the expected version. Fortunately, most of the applications call the wx-config script to determine the necessary compiler and linker flags. The script is named differently for every available version. Majority of applications respect an environment variable, or accept a configure argument, to specify which wx-config script to call. Otherwise they have to be patched. Version Selection To make your port use a specific version of wxWidgets there are two variables available for defining (if only one is defined the other will be set to a default value): Variables to Select <application>wxWidgets</application> Versions Variable Description Default value USE_WX List of versions the port can use All available versions USE_WX_NOT List of versions the port can not use None
The following is a list of available wxWidgets versions and the corresponding ports in the tree: Available <application>wxWidgets</application> Versions Version Port 2.4 x11-toolkits/wxgtk24 2.6 x11-toolkits/wxgtk26 2.8 x11-toolkits/wxgtk28
The versions starting from 2.5 also come in Unicode version and are installed by a slave port named like the normal one plus a -unicode suffix, but this can be handled with variables (see ). The variables in can be set to one or more of the following combinations separated by spaces: <application>wxWidgets</application> Version Specifications Description Example Single version 2.4 Ascending range 2.4+ Descending range 2.6- Full range (must be ascending) 2.4-2.6
There are also some variables to select the preferred versions from the available ones. They can be set to a list of versions, the first ones will have higher priority. Variables to Select Preferred <application>wxWidgets</application> Versions Name Designed for WANT_WX_VER the port WITH_WX_VER the user
Component Selection There are other applications that, while not being wxWidgets libraries, are related to them. These applications can be specified in the WX_COMPS variable. The following components are available: Available <application>wxWidgets</application> Components Name Description Version restriction wx main library none contrib contributed libraries none python wxPython (Python bindings) 2.4-2.6 mozilla wxMozilla 2.4 svg wxSVG 2.6
The dependency type can be selected for each component by adding a suffix separated by a semicolon. If not present then a default type will be used (see ). The following types are available: Available <application>wxWidgets</application> Dependency Types Name Description build Component is required for building, equivalent to BUILD_DEPENDS run Component is required for running, equivalent to RUN_DEPENDS lib Component is required for building and running, equivalent to LIB_DEPENDS
The default values for the components are detailed in the following table: Default <application>wxWidgets</application> Dependency Types Component Dependency type wx lib contrib lib python run mozilla lib svg lib
Selecting <application>wxWidgets</application> Components The following fragment corresponds to a port which uses wxWidgets version 2.4 and its contributed libraries. USE_WX= 2.4 WX_COMPS= wx contrib
Unicode The wxWidgets library supports Unicode since version 2.5. In the ports tree both versions are available and can be selected with the following variables: Variables to Select Unicode in <application>wxWidgets</application> Versions Variable Description Designed for WX_UNICODE The port works only with the Unicode version the port WANT_UNICODE The port works with both versions but prefers the Unicode one the port WITH_UNICODE The port will use the Unicode version the user WITHOUT_UNICODE The port will use the normal version if supported (when WX_UNICODE is not defined) the user
Do not use WX_UNICODE for ports that can use both Unicode and normal versions. If you want the port to use Unicode by default define WANT_UNICODE instead.
Detecting Installed Versions To detect an installed version you have to define WANT_WX. If you do not set it to a specific version then the components will have a version suffix. The HAVE_WX variable will be filled after detection. Detecting Installed <application>wxWidgets</application> Versions and Components The following fragment can be used in a port that uses wxWidgets if it is installed, or an option is selected. WANT_WX= yes .include <bsd.port.pre.mk> .if defined(WITH_WX) || !empty(PORT_OPTIONS:MWX) || !empty(HAVE_WX:Mwx-2.4) USE_WX= 2.4 CONFIGURE_ARGS+= --enable-wx .endif The following fragment can be used in a port that enables wxPython support if it is installed or if an option is selected, in addition to wxWidgets, both version 2.6. USE_WX= 2.6 WX_COMPS= wx WANT_WX= 2.6 .include <bsd.port.pre.mk> .if defined(WITH_WXPYTHON) || !empty(PORT_OPTIONS:MWXPYTHON) || !empty(HAVE_WX:Mpython) WX_COMPS+= python CONFIGURE_ARGS+= --enable-wxpython .endif Defined Variables The following variables are available in the port (after defining one from ). Variables Defined for Ports That Use <application>wxWidgets</application> Name Description WX_CONFIG The path to the wxWidgets wx-config script (with different name) WXRC_CMD The path to the wxWidgets wxrc program (with different name) WX_VERSION The wxWidgets version that is going to be used (e.g., 2.6) WX_UNICODE If not defined but Unicode is going to be used then it will be defined
Processing in <filename>bsd.port.pre.mk</filename> If you need to use the variables for running commands right after including bsd.port.pre.mk you need to define WX_PREMK. If you define WX_PREMK, then the version, dependencies, components and defined variables will not change if you modify the wxWidgets port variables after including bsd.port.pre.mk. Using <application>wxWidgets</application> Variables in Commands The following fragment illustrates the use of WX_PREMK by running the wx-config script to obtain the full version string, assign it to a variable and pass it to the program. USE_WX= 2.4 WX_PREMK= yes .include <bsd.port.pre.mk> .if exists(${WX_CONFIG}) VER_STR!= ${WX_CONFIG} --release PLIST_SUB+= VERSION="${VER_STR}" .endif The wxWidgets variables can be safely used in commands when they are inside targets without the need of WX_PREMK. Additional <command>configure</command> Arguments Some GNU configure scripts can not find wxWidgets with just the WX_CONFIG environment variable set, requiring additional arguments. The WX_CONF_ARGS variable can be used for provide them. Legal Values for <makevar>WX_CONF_ARGS</makevar> Possible value Resulting argument absolute --with-wx-config=${WX_CONFIG} relative --with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}
Using <application>Lua</application> This section describes the status of the Lua libraries in the ports tree and its integration with the ports system. Introduction There are many versions of the Lua libraries and corresponding interpreters, which conflict between them (install files under the same name). In the ports tree this problem has been solved by installing each version under a different name using version number suffixes. The obvious disadvantage of this is that each application has to be modified to find the expected version. But it can be solved by adding some additional flags to the compiler and linker. Version Selection To make your port use a specific version of Lua there are two variables available for defining (if only one is defined the other will be set to a default value): Variables to Select <application>Lua</application> Versions Variable Description Default value USE_LUA List of versions the port can use All available versions USE_LUA_NOT List of versions the port can not use None
The following is a list of available Lua versions and the corresponding ports in the tree: Available <application>Lua</application> Versions Version Port 4.0 lang/lua4 5.0 lang/lua50 5.1 lang/lua
The variables in can be set to one or more of the following combinations separated by spaces: <application>Lua</application> Version Specifications Description Example Single version 4.0 Ascending range 5.0+ Descending range 5.0- Full range (must be ascending) 5.0-5.1
There are also some variables to select the preferred versions from the available ones. They can be set to a list of versions, the first ones will have higher priority. Variables to Select Preferred <application>Lua</application> Versions Name Designed for WANT_LUA_VER the port WITH_LUA_VER the user
Selecting the <application>Lua</application> Version The following fragment is from a port which can use Lua version 5.0 or 5.1, and uses 5.0 by default. It can be overridden by the user with WITH_LUA_VER. USE_LUA= 5.0-5.1 WANT_LUA_VER= 5.0
Component Selection There are other applications that, while not being Lua libraries, are related to them. These applications can be specified in the LUA_COMPS variable. The following components are available: Available <application>Lua</application> Components Name Description Version restriction lua main library none tolua Library for accessing C/C++ code 4.0-5.0 ruby Ruby bindings 4.0-5.0
There are more components but they are modules for the interpreter, not used by applications (only by other modules). The dependency type can be selected for each component by adding a suffix separated by a semicolon. If not present then a default type will be used (see ). The following types are available: Available <application>Lua</application> Dependency Types Name Description build Component is required for building, equivalent to BUILD_DEPENDS run Component is required for running, equivalent to RUN_DEPENDS lib Component is required for building and running, equivalent to LIB_DEPENDS
The default values for the components are detailed in the following table: Default <application>Lua</application> Dependency Types Component Dependency type lua lib for 4.0-5.0 (shared) and build for 5.1 (static) tolua build (static) ruby lib (shared)
Selecting <application>Lua</application> Components The following fragment corresponds to a port which uses Lua version 4.0 and its Ruby bindings. USE_LUA= 4.0 LUA_COMPS= lua ruby
Detecting Installed Versions To detect an installed version you have to define WANT_LUA. If you do not set it to a specific version then the components will have a version suffix. The HAVE_LUA variable will be filled after detection. Detecting Installed <application>Lua</application> Versions and Components The following fragment can be used in a port that uses Lua if it is installed, or an option is selected. WANT_LUA= yes .include <bsd.port.pre.mk> .if defined(WITH_LUA5) || !empty(PORT_OPTIONS:MLUA5) || !empty(HAVE_LUA:Mlua-5.[01]) USE_LUA= 5.0-5.1 CONFIGURE_ARGS+= --enable-lua5 .endif The following fragment can be used in a port that enables tolua support if it is installed or if an option is selected, in addition to Lua, both version 4.0. USE_LUA= 4.0 LUA_COMPS= lua WANT_LUA= 4.0 .include <bsd.port.pre.mk> .if defined(WITH_TOLUA) || !empty(PORT_OPTIONS:MTOLUA) || !empty(HAVE_LUA:Mtolua) LUA_COMPS+= tolua CONFIGURE_ARGS+= --enable-tolua .endif Defined Variables The following variables are available in the port (after defining one from ). Variables Defined for Ports That Use <application>Lua</application> Name Description LUA_VER The Lua version that is going to be used (e.g., 5.1) LUA_VER_SH The Lua shared library major version (e.g., 1) LUA_VER_STR The Lua version without the dots (e.g., 51) LUA_PREFIX The prefix where Lua (and components) is installed LUA_SUBDIR The directory under ${PREFIX}/bin, ${PREFIX}/share and ${PREFIX}/lib where Lua is installed LUA_INCDIR The directory where Lua and tolua header files are installed LUA_LIBDIR The directory where Lua and tolua libraries are installed LUA_MODLIBDIR The directory where Lua module libraries (.so) are installed LUA_MODSHAREDIR The directory where Lua modules (.lua) are installed LUA_PKGNAMEPREFIX The package name prefix used by Lua modules LUA_CMD The path to the Lua interpreter LUAC_CMD The path to the Lua compiler TOLUA_CMD The path to the tolua program
Telling the Port Where to Find <application>Lua</application> The following fragment shows how to tell a port that uses a configure script where the Lua header files and libraries are. USE_LUA= 4.0 GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}"
Processing in <filename>bsd.port.pre.mk</filename> If you need to use the variables for running commands right after including bsd.port.pre.mk you need to define LUA_PREMK. If you define LUA_PREMK, then the version, dependencies, components and defined variables will not change if you modify the Lua port variables after including bsd.port.pre.mk. Using <application>Lua</application> Variables in Commands The following fragment illustrates the use of LUA_PREMK by running the Lua interpreter to obtain the full version string, assign it to a variable and pass it to the program. USE_LUA= 5.0 LUA_PREMK= yes .include <bsd.port.pre.mk> .if exists(${LUA_CMD}) VER_STR!= ${LUA_CMD} -v CFLAGS+= -DLUA_VERSION_STRING="${VER_STR}" .endif The Lua variables can be safely used in commands when they are inside targets without the need of LUA_PREMK.
Using Xfce The USE_XFCE variable is used to autoconfigure the dependencies for ports which use an Xfce based library or application like x11-toolkits/libxfce4gui and x11-wm/xfce4-panel. The following Xfce libraries and applications are recognized at the moment: libexo: x11/libexo libgui: x11-toolkits/libxfce4gui libutil: x11/libxfce4util libmcs: x11/libxfce4mcs mcsmanager: sysutils/xfce4-mcs-manager panel: x11-wm/xfce4-panel thunar: x11-fm/thunar wm: x11-wm/xfce4-wm xfdev: dev/xfce4-dev-tools The following additional parameters are recognized: configenv: Use this if your port requires a special modified CONFIGURE_ENV to find its required libraries. -I${LOCALBASE}/include -L${LOCALBASE}/lib gets added to CPPFLAGS to CONFIGURE_ENV. Therefore, if a port has a dependency on sysutils/xfce4-mcs-manager and requires the special CPPFLAGS in its configure environment, the syntax will be: USE_XFCE= mcsmanager configenv Using Mozilla Variables for Ports That Use Mozilla USE_GECKO Gecko backend the port can handle. Possible values: libxul (libxul.so), seamonkey (libgtkembedmoz.so, deprecated, should not be used any more). USE_FIREFOX The port requires Firefox as a runtime dependency. Possible values: yes (get default version), 40, 36, 35. Default dependency is on version 40. USE_FIREFOX_BUILD The port requires Firefox as a buildtime dependency. Possible values: see USE_FIREFOX. This automatically sets USE_FIREFOX and assigns the same value. USE_SEAMONKEY The port requires SeaMonkey as a runtime dependency. Possible values: yes (get default version), 20, 11 (deprecated, should not be used any more). Default dependency is on version 20. USE_SEAMONKEY_BUILD The port requires SeaMonkey as a buildtime dependency. Possible values: see USE_SEAMONKEY. This automatically sets USE_SEAMONKEY and assigns the same value. USE_THUNDERBIRD The port requires Thunderbird as a runtime dependency. Possible values: yes (get default version), 31, 30 (deprecated, should not be used any more). Default dependency is on version 31. USE_THUNDERBIRD_BUILD The port requires Thunderbird as a buildtime dependency. Possible values: see USE_THUNDERBIRD. This automatically sets USE_THUNDERBIRD and assigns the same value.
A complete list of available variables can be found in /usr/ports/Mk/bsd.gecko.mk.
Using Databases Variables for Ports Using Databases Variable Means USE_BDB If variable is set to yes, add dependency on databases/db41 port. The variable may also be set to values: 40, 41, 42, 43, 44, 46, 47, 48, or 51. You can declare a range of acceptable values, USE_BDB=42+ will find the highest installed version, and fall back to 42 if nothing else is installed. USE_MYSQL If variable is set to yes, add dependency on databases/mysql55-client port. An associated variable, WANT_MYSQL_VER, may be set to values such as 323, 40, 41, 50, 51, 52, 55, or 60. USE_PGSQL If set to yes, add dependency on databases/postgresql90-client port. An associated variable, WANT_PGSQL_VER, may be set to values such as 83, 84, 90, 91 or 92. You can declare a minimum or maximum value; WANT_PGSQL_VER= 90+ will cause the port to depend on a minimum version of 9.0. USE_SQLITE If variable is set to yes, add dependency on databases/sqlite3 port. The variable may also be set to values: 3, 2.
More details are available in bsd.database.mk.
Starting and Stopping Services (<literal>rc</literal> Scripts) rc.d scripts are used to start services on system startup, and to give administrators a standard way of stopping, starting and restarting the service. Ports integrate into the system rc.d framework. Details on its usage can be found in the rc.d Handbook chapter. Detailed explanation of available commands is provided in &man.rc.8; and &man.rc.subr.8;. Finally, there is an article on practical aspects of rc.d scripting. One or more rc.d scripts can be installed: USE_RC_SUBR= doormand Scripts must be placed in the files subdirectory and a .in suffix must be added to their filename. Standard SUB_LIST expansions will be used for this file. Use of the %%PREFIX%% and %%LOCALBASE%% expansions is strongly encouraged as well. More on SUB_LIST in the relevant section. Prior to &os; 6.1-RELEASE, integration with &man.rcorder.8; is available by using USE_RCORDER instead of USE_RC_SUBR. However, use of this method is not necessary unless the port has an option to install itself in the base, or the service needs to run prior to the FILESYSTEMS rc.d script in the base. As of &os; 6.1-RELEASE, local rc.d scripts (including those installed by ports) are included in the overall &man.rcorder.8; of the base system. Example simple rc.d script: #!/bin/sh # $FreeBSD$ # # PROVIDE: doormand # REQUIRE: LOGIN # KEYWORD: shutdown # # Add the following lines to /etc/rc.conf.local or /etc/rc.conf # to enable this service: # # doormand_enable (bool): Set to NO by default. # Set it to YES to enable doormand. # doormand_config (path): Set to %%PREFIX%%/etc/doormand/doormand.cf # by default. . /etc/rc.subr name=doormand rcvar=doormand_enable load_rc_config $name : ${doormand_enable:="NO"} : ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"} command=%%PREFIX%%/sbin/${name} pidfile=/var/run/${name}.pid command_args="-p $pidfile -f $doormand_config" run_rc_command "$1" Unless there is a good reason to start the service earlier all ports scripts should use REQUIRE: LOGIN If the service runs as a particular user (other than root) this is mandatory. KEYWORD: shutdown is included in the script above because the mythical port we are using as an example starts a service, and should be shut down cleanly when the system shuts down. If the script is not starting a persistent service this is not necessary. For optional configuration elements the "=" style of default variable assignment is preferable to the ":=" style here, since the former sets a default value only if the variable is unset, and the latter sets one if the variable is unset or null. A user might very well include something like doormand_flags="" in their rc.conf.local file, and a variable substitution using ":=" would inappropriately override the user's intention. The _enable variable is not optional, and should use the ":" for the default. No new scripts should be added with the .sh suffix. Pre-Commit Checklist Before contributing a port with an rc.d script, and more importantly, before committing one, please consult the following checklist to be sure that it is ready. If this is a new file, does it have .sh in the file name? If so that should be changed to just file.in since new rc.d files may not end with that extension. Does the file have a $FreeBSD$ tag? Do the name of the file (minus .in), the PROVIDE line, and $name all match? The file name matching PROVIDE makes debugging easier, especially for &man.rcorder.8; issues. Matching the file name and $name makes it easier to figure out which variables are relevant in rc.conf[.local]. The latter is also what you might call “policy” for all new scripts, including those in the base system. Is the REQUIRE line set to LOGIN? This is mandatory for scripts that run as a non-root user. If it runs as root, is there a good reason for it to run prior to LOGIN? If not, it should run there so that we can loosely group local scripts to a point in &man.rcorder.8; after most everything in the base is already running. Does the script start a persistent service? If so, it should have KEYWORD: shutdown. Make sure there is no KEYWORD: FreeBSD present. This has not been necessary or desirable for years. It is also an indication that the new script was copy/pasted from an old script, so extra caution should be given to the review. If the script uses an interpreted language like perl, python, or ruby, make certain that command_interpreter is set appropriately. Otherwise, &prompt.root; service name stop will probably not work properly. See &man.service.8; for more information. Have all occurrences of /usr/local been replaced with %%PREFIX%%? Do the default variable assignments come after load_rc_config? Are there default assignments to empty strings? They should be removed, but double-check that the option is documented in the comments at the top of the file. Are things that are set in variables actually used in the script? Are options listed in the default name_flags things that are actually mandatory? If so, they should be in command_args. The option is a red flag (pardon the pun) here, since it is usually the option to “daemonize” the process, and therefore is actually mandatory. The name_flags variable should never be included in command_args (and vice versa, although that error is less common). Does the script execute any code unconditionally? This is frowned on. Usually these things can/should be dealt with through a start_precmd. All boolean tests should utilize the checkyesno function. No hand-rolled tests for [Yy][Ee][Ss], etc. If there is a loop (for example, waiting for something to start) does it have a counter to terminate the loop? We do not want the boot to be stuck forever if there is an error. Does the script create files or directories that need specific permissions, for example, a pid file that needs to be owned by the user that runs the process? Rather than the traditional &man.touch.1;/&man.chown.8;/&man.chmod.1; routine, consider using &man.install.1; with the proper command line arguments to do the whole procedure with one step. Adding Users and Groups Some ports require a certain user to be on the installed system. Choose a free UID from 50 to 999 and register it either in ports/UIDs (for users) or in ports/GIDs (for groups). Make sure you do not use a UID already used by the system or other ports. Please include a patch against these two files when you require a new user or group to be created for your port. Then you can use USERS and GROUPS variables in your Makefile, and the user will be automatically created when installing the port. USERS= pulse GROUPS= pulse pulse-access pulse-rt The current list of reserved UIDs and GIDs can be found in ports/UIDs and ports/GIDs. Ports That Rely on Kernel Sources Some ports (such as kernel loadable modules) need the kernel source files so that the port can compile. Here is the correct way to determine if the user has them installed: .if !exists(${SRC_BASE}/sys/Makefile) IGNORE= requires kernel sources to be installed .endif
Advanced <filename>pkg-plist</filename> Practices Changing <filename>pkg-plist</filename> Based on Make Variables Some ports, particularly the p5- ports, need to change their pkg-plist depending on what options they are configured with (or version of perl, in the case of p5- ports). To make this easy, any instances in the pkg-plist of %%OSREL%%, %%PERL_VER%%, and %%PERL_VERSION%% will be substituted for appropriately. The value of %%OSREL%% is the numeric revision of the operating system (e.g., 4.9). %%PERL_VERSION%% and %%PERL_VER%% is the full version number of perl (e.g., 5.8.9). Several other %%VARS%% related to port's documentation files are described in the relevant section. If you need to make other substitutions, you can set the PLIST_SUB variable with a list of VAR=VALUE pairs and instances of %%VAR%% will be substituted with VALUE in the pkg-plist. For instance, if you have a port that installs many files in a version-specific subdirectory, you can put something like OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} in the Makefile and use %%OCTAVE_VERSION%% wherever the version shows up in pkg-plist. That way, when you upgrade the port, you will not have to change dozens (or in some cases, hundreds) of lines in the pkg-plist. If your port installs files conditionally on the options set in the port, the usual way of handling it is prefixing the pkg-plist lines with a %%TAG%% and adding that TAG to the PLIST_SUB variable inside the Makefile with a special value of @comment, which makes package tools to ignore the line: .if defined(WITH_X11) PLIST_SUB+= X11="" .else PLIST_SUB+= X11="@comment " .endif and in the pkg-plist: %%X11%%bin/foo-gui This substitution (as well as addition of any manual pages) will be done between the pre-install and do-install targets, by reading from PLIST and writing to TMPPLIST (default: WRKDIR/.PLIST.mktmp). So if your port builds PLIST on the fly, do so in or before pre-install. Also, if your port needs to edit the resulting file, do so in post-install to a file named TMPPLIST. Another possibility to modify port's packing list is based on setting the variables PLIST_FILES and PLIST_DIRS. The value of each variable is regarded as a list of pathnames to write to TMPPLIST along with PLIST contents. Names listed in PLIST_FILES and PLIST_DIRS are subject to %%VAR%% substitution, as described above. Except for that, names from PLIST_FILES will appear in the final packing list unchanged, while @dirrm will be prepended to names from PLIST_DIRS. To take effect, PLIST_FILES and PLIST_DIRS must be set before TMPPLIST is written, i.e., in pre-install or earlier. Empty Directories Cleaning Up Empty Directories Do make your ports remove empty directories when they are de-installed. This is usually accomplished by adding @dirrm lines for all directories that are specifically created by the port. You need to delete subdirectories before you can delete parent directories. : lib/X11/oneko/pixmaps/cat.xpm lib/X11/oneko/sounds/cat.au : @dirrm lib/X11/oneko/pixmaps @dirrm lib/X11/oneko/sounds @dirrm lib/X11/oneko However, sometimes @dirrm will give you errors because other ports share the same directory. You can use @dirrmtry to remove only empty directories without warning. @dirrmtry share/doc/gimp This will neither print any error messages nor cause &man.pkg.delete.1; to exit abnormally even if ${PREFIX}/share/doc/gimp is not empty due to other ports installing some files in there. Creating Empty Directories Empty directories created during port installation need special attention. They will not get created when installing the package, because packages only store the files, and &man.pkg.add.1; creates directories for them as needed. To make sure the empty directory is created when installing the package, add this line to pkg-plist above the corresponding @dirrm line: @exec mkdir -p %D/share/foo/templates Configuration Files If your port installs configuration files to PREFIX/etc (or elsewhere) do not simply list them in the pkg-plist. That will cause &man.pkg.delete.1; to remove the files carefully edited by the user, and a re-installation will wipe them out. Instead, install sample file(s) with a filename.sample suffix. Then copy the sample file to the real configuration file name, if it does not already exist. On deinstall delete the configuration file, but only if it is identical to the .sample file. You need to handle this both in the port Makefile, and in the pkg-plist (for installation from the package). Example of the Makefile part: post-install: @if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \ ${CP} -p ${PREFIX}/etc/orbit.conf.sample ${PREFIX}/etc/orbit.conf ; \ fi For each configuration file, create the following three lines in pkg-plist: @unexec if cmp -s %D/etc/orbit.conf.sample %D/etc/orbit.conf; then rm -f %D/etc/orbit.conf; fi etc/orbit.conf.sample @exec if [ ! -f %D/etc/orbit.conf ] ; then cp -p %D/%F %B/orbit.conf; fi The order of these lines is important. On deinstallation, the sample file is compared to the actual configuration file. If these files are identical, no changes have been made by the user and the actual file can be safely deleted. Because the sample file must still exist for the comparison, the @unexec line comes before the sample configuration file name. On installation, if an actual configuration file is not already present, the sample file is copied to the actual file. The sample file must be present before it can be copied, so the @exec line comes after the sample configuration file name. To debug any issues, temporarily remove the -s flag to &man.cmp.1; for more output. See &man.pkg.create.1; for more information on %D and related substitution markers. If there is a very good reason not to install a working configuration file by default, leave the @exec line out of pkg-plist and add a message pointing out that the user must copy and edit the file before the software will work. Dynamic Versus Static Package List A static package list is a package list which is available in the Ports Collection either as a pkg-plist file (with or without variable substitution), or embedded into the Makefile via PLIST_FILES and PLIST_DIRS. Even if the contents are auto-generated by a tool or a target in the Makefile before the inclusion into the Ports Collection by a committer, this is still considered a static list, since it is possible to examine it without having to download or compile the distfile. A dynamic package list is a package list which is generated at the time the port is compiled based upon the files and directories which are installed. It is not possible to examine it before the source code of the ported application is downloaded and compiled, or after running a make clean. While the use of dynamic package lists is not forbidden, maintainers should use static package lists wherever possible, as it enables users to &man.grep.1; through available ports to discover, for example, which port installs a certain file. Dynamic lists should be primarily used for complex ports where the package list changes drastically based upon optional features of the port (and thus maintaining a static package list is infeasible), or ports which change the package list based upon the version of dependent software used (e.g., ports which generate docs with Javadoc). Maintainers who prefer dynamic package lists are encouraged to add a new target to their port which generates the pkg-plist file so that users may examine the contents. Automated Package List Creation First, make sure your port is almost complete, with only pkg-plist missing. Next, create a temporary directory tree into which your port can be installed, and install any dependencies. &prompt.root; mkdir /var/tmp/`make -V PORTNAME` &prompt.root; mtree -U -f `make -V MTREE_FILE` -d -e -p /var/tmp/`make -V PORTNAME` &prompt.root; make depends PREFIX=/var/tmp/`make -V PORTNAME` Store the directory structure in a new file. &prompt.root; (cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort > OLD-DIRS Create an empty pkg-plist file: &prompt.root; :>pkg-plist If your port honors PREFIX (which it should) you can then install the port and create the package list. &prompt.root; make install PREFIX=/var/tmp/`make -V PORTNAME` &prompt.root; (cd /var/tmp/`make -V PORTNAME` && find -d * \! -type d) | sort > pkg-plist You must also add any newly created directories to the packing list. &prompt.root; (cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort | comm -13 OLD-DIRS - | sort -r | sed -e 's#^#@dirrm #' >> pkg-plist Finally, you need to tidy up the packing list by hand; it is not all automated. Manual pages should be listed in the port's Makefile under MANn, and not in the package list. User configuration files should be removed, or installed as filename.sample. The info/dir file should not be listed and appropriate install-info lines should be added as noted in the info files section. Any libraries installed by the port should be listed as specified in the shared libraries section. Alternatively, use the plist script in /usr/ports/Tools/scripts/ to build the package list automatically. The plist script is a Ruby script that automates most of the manual steps outlined in the previous paragraphs. The first step is the same as above: take the first three lines, that is, mkdir, mtree and make depends. Then build and install the port: &prompt.root; make install PREFIX=/var/tmp/`make -V PORTNAME` And let plist create the pkg-plist file: &prompt.root; /usr/ports/Tools/scripts/plist -Md -m `make -V MTREE_FILE` /var/tmp/`make -V PORTNAME` > pkg-plist The packing list still has to be tidied up by hand as stated above. Another tool that might be used to create an initial pkg-plist is ports-mgmt/genplist. As with any automated tool, the resulting pkg-plist should be checked and manually edited as needed. The <filename>pkg-<replaceable>*</replaceable></filename> Files There are some tricks we have not mentioned yet about the pkg-* files that come in handy sometimes. <filename>pkg-message</filename> If you need to display a message to the installer, you may place the message in pkg-message. This capability is often useful to display additional installation steps to be taken after a &man.pkg.add.1; or to display licensing information. When some lines about the build-time knobs or warnings have to be displayed, use ECHO_MSG. The pkg-message file is only for post-installation steps. Likewise, the distinction between ECHO_MSG and ECHO_CMD should be kept in mind. The former is for printing informational text to the screen, while the latter is for command pipelining: update-etc-shells: @${ECHO_MSG} "updating /etc/shells" @${CP} /etc/shells /etc/shells.bak @( ${GREP} -v ${PREFIX}/bin/bash /etc/shells.bak; \ ${ECHO_CMD} ${PREFIX}/bin/bash) >/etc/shells @${RM} /etc/shells.bak The pkg-message file does not need to be added to pkg-plist. Also, it will not get automatically printed if the user is using the port, not the package, so you should probably display it from the post-install target yourself. <filename>pkg-install</filename> If your port needs to execute commands when the binary package is installed with &man.pkg.add.1; you can do this via the pkg-install script. This script will automatically be added to the package, and will be run twice by &man.pkg.add.1;: the first time as ${SH} pkg-install ${PKGNAME} PRE-INSTALL and the second time as ${SH} pkg-install ${PKGNAME} POST-INSTALL. $2 can be tested to determine which mode the script is being run in. The PKG_PREFIX environmental variable will be set to the package installation directory. See &man.pkg.add.1; for additional information. This script is not run automatically if you install the port with make install. If you are depending on it being run, you will have to explicitly call it from your port's Makefile, with a line like PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL. <filename>pkg-deinstall</filename> This script executes when a package is removed. This script will be run twice by &man.pkg.delete.1;. The first time as ${SH} pkg-deinstall ${PKGNAME} DEINSTALL and the second time as ${SH} pkg-deinstall ${PKGNAME} POST-DEINSTALL. <filename>pkg-req</filename> If your port needs to determine if it should install or not, you can create a pkg-req requirements script. It will be invoked automatically at installation/de-installation time to determine whether or not installation/de-installation should proceed. The script will be run at installation time by &man.pkg.add.1; as pkg-req ${PKGNAME} INSTALL. At de-installation time it will be run by &man.pkg.delete.1; as pkg-req ${PKGNAME} DEINSTALL. Changing the Names of <filename>pkg-<replaceable>*</replaceable></filename> Files All the names of pkg-* files are defined using variables so you can change them in your Makefile if need be. This is especially useful when you are sharing the same pkg-* files among several ports or have to write to one of the above files (see writing to places other than WRKDIR for why it is a bad idea to write directly into the pkg-* subdirectory). Here is a list of variable names and their default values. (PKGDIR defaults to ${MASTERDIR}.) Variable Default value DESCR ${PKGDIR}/pkg-descr PLIST ${PKGDIR}/pkg-plist PKGINSTALL ${PKGDIR}/pkg-install PKGDEINSTALL ${PKGDIR}/pkg-deinstall PKGREQ ${PKGDIR}/pkg-req PKGMESSAGE ${PKGDIR}/pkg-message Please change these variables rather than overriding PKG_ARGS. If you change PKG_ARGS, those files will not correctly be installed in /var/db/pkg upon install from a port. Making Use of <makevar>SUB_FILES</makevar> and <makevar>SUB_LIST</makevar> The SUB_FILES and SUB_LIST variables are useful for dynamic values in port files, such as the installation PREFIX in pkg-message. The SUB_FILES variable specifies a list of files to be automatically modified. Each file in the SUB_FILES list must have a corresponding file.in present in FILESDIR. A modified version will be created in WRKDIR. Files defined as a value of USE_RC_SUBR (or the deprecated USE_RCORDER) are automatically added to the SUB_FILES. For the files pkg-message, pkg-install, pkg-deinstall and pkg-req, the corresponding Makefile variable is automatically set to point to the processed version. The SUB_LIST variable is a list of VAR=VALUE pairs. For each pair %%VAR%% will get replaced with VALUE in each file listed in SUB_FILES. Several common pairs are automatically defined: PREFIX, LOCALBASE, DATADIR, DOCSDIR, EXAMPLESDIR, WWWDIR, and ETCDIR. Any line beginning with @comment will be deleted from resulting files after a variable substitution. The following example will replace %%ARCH%% with the system architecture in a pkg-message: SUB_FILES= pkg-message SUB_LIST= ARCH=${ARCH} Note that for this example, the pkg-message.in file must exist in FILESDIR. Example of a good pkg-message.in: Now it is time to configure this package. Copy %%PREFIX%%/share/examples/putsy/%%ARCH%%.conf into your home directory as .putsy.conf and edit it. Testing Your Port Running <command>make describe</command> Several of the &os; port maintenance tools, such as &man.portupgrade.1;, rely on a database called /usr/ports/INDEX which keeps track of such items as port dependencies. INDEX is created by the top-level ports/Makefile via make index, which descends into each port subdirectory and executes make describe there. Thus, if make describe fails in any port, no one can generate INDEX, and many people will quickly become unhappy. It is important to be able to generate this file no matter what options are present in make.conf, so please avoid doing things such as using .error statements when (for instance) a dependency is not satisfied. (See .) If make describe produces a string rather than an error message, you are probably safe. See bsd.port.mk for the meaning of the string produced. Also note that running a recent version of portlint (as specified in the next section) will cause make describe to be run automatically. Portlint Do check your work with portlint before you submit or commit it. portlint warns you about many common errors, both functional and stylistic. For a new (or repocopied) port, portlint -A is the most thorough; for an existing port, portlint -C is sufficient. Since portlint uses heuristics to try to figure out errors, it can produce false positive warnings. In addition, occasionally something that is flagged as a problem really cannot be done in any other way due to limitations in the ports framework. When in doubt, the best thing to do is ask on &a.ports;. Port Tools The ports-mgmt/porttools program is part of the Ports Collection. port is the front-end script, which can help you simplify the testing job. Whenever you want to test a new port or update an existing one, you can use port test to test your port, including the portlint checking. This command also detects and lists any files that are not listed in pkg-plist. See the following example: &prompt.root; port test /usr/ports/net/csup <makevar>PREFIX</makevar> and <makevar>DESTDIR</makevar> PREFIX determines where the port will be installed. It defaults to /usr/local, but can be set by the user to a custom path like /opt. Your port must respect the value of this variable. DESTDIR, if set by the user, determines the complete alternative environment, usually a jail or an installed system mounted somewhere other than /. A port will actually install into DESTDIR/PREFIX, and register with the package database in DESTDIR/var/db/pkg. As DESTDIR is handled automatically by the ports infrastructure with &man.chroot.8;, you do not need any modifications or any extra care to write DESTDIR-compliant ports. The value of PREFIX will be set to LOCALBASE (defaulting to /usr/local). If USE_LINUX_PREFIX is set, PREFIX will be LINUXBASE (defaulting to /compat/linux). Avoiding hard-coded /usr/local paths in the source makes the port much more flexible and able to cater to the needs of other sites. Often, this can be accomplished by simply replacing occurrences of /usr/local in the port's various Makefiles with ${PREFIX}. This variable is automatically passed down to every stage of the build and install processes. Make sure your application is not installing things in /usr/local instead of PREFIX. A quick test for such hard-coded paths is: &prompt.root; make clean; make package PREFIX=/var/tmp/`make -V PORTNAME` If anything is installed outside of PREFIX, the package creation process will complain that it cannot find the files. This test will not find hard-coded paths inside the port's files, nor will it verify that LOCALBASE is being used to correctly refer to files from other ports. The temporarily-installed port in /var/tmp/`make -V PORTNAME` should be tested for proper operation to make sure there are no problems with paths. PREFIX should not be set explicitly in a port's Makefile. Users installing the port may have set PREFIX to a custom location, and the port should respect that setting. Refer to programs and files from other ports with the variables mentioned above, not explicit pathnames. For instance, if your port requires a macro PAGER to have the full pathname of less, do not use a literal path of /usr/local/bin/less. Instead, use ${LOCALBASE}: -DPAGER=\"${LOCALBASE}/bin/less\" The path with LOCALBASE is more likely to still work if the system administrator has moved the whole /usr/local tree somewhere else. Tinderbox If you are an avid ports contributor, you might want to take a look at Tinderbox. It is a powerful system for building and testing ports based on the scripts used on Pointyhat. You can install Tinderbox using ports-mgmt/tinderbox port. Be sure to read supplied documentation since the configuration is not trivial. Visit the Tinderbox website for more details. Upgrading an Individual Port When you notice that a port is out of date compared to the latest version from the original authors, you should first ensure that you have the latest port. You can find them in the ports/ports-current directory of the &os; FTP mirror sites. However, if you are working with more than a few ports, you will probably find it easier to use Subversion or &man.portsnap.8; to keep your whole ports collection up-to-date, as described in the Handbook. This will have the added benefit of tracking all the ports' dependencies. The next step is to see if there is an update already pending. To do this, you have two options. There is a searchable interface to the FreeBSD Problem Report (PR) database (also known as GNATS). Select ports in the dropdown, and enter the name of the port. However, sometimes people forget to put the name of the port into the Synopsis field in an unambiguous fashion. In that case, you can try the FreeBSD Ports Monitoring System (also known as portsmon). This system attempts to classify port PRs by portname. To search for PRs about a particular port, use the Overview of One Port. If there is no pending PR, the next step is to send an email to the port's maintainer, as shown by make maintainer. That person may already be working on an upgrade, or have a reason to not upgrade the port right now (because of, for example, stability problems of the new version); you would not want to duplicate their work. Note that unmaintained ports are listed with a maintainer of ports@FreeBSD.org, which is just the general ports mailing list, so sending mail there probably will not help in this case. If the maintainer asks you to do the upgrade or there is no maintainer, then you have a chance to help out &os; by preparing the update yourself! Please do this by using the &man.diff.1; command in the base system. To create a suitable diff for a single patch, copy the file that needs patching to something.orig, save your changes to something and then create your patch: &prompt.user; diff -u something.orig something > something.diff Otherwise, you should either use the svn diff method () or copy the contents of the port to an entire different directory and use the result of the recursive &man.diff.1; output of the new and old ports directories (e.g., if your modified port directory is called superedit and the original is in our tree as superedit.bak, then save the result of diff -ruN superedit.bak superedit). Either unified or context diff is fine, but port committers generally prefer unified diffs. Note the use of the -N option—this is the accepted way to force diff to properly deal with the case of new files being added or old files being deleted. Before sending us the diff, please examine the output to make sure all the changes make sense. (In particular, make sure you first clean out the work directories with make clean). To simplify common operations with patch files, you can use /usr/ports/Tools/scripts/patchtool.py. Before using it, please read /usr/ports/Tools/scripts/README.patchtool. If the port is unmaintained, and you are actively using it yourself, please consider volunteering to become its maintainer. &os; has over 4000 ports without maintainers, and this is an area where more volunteers are always needed. (For a detailed description of the responsibilities of maintainers, refer to the section in the Developer's Handbook.) The best way to send us the diff is by including it via &man.send-pr.1; (category ports). If you are maintaining the port, be sure to put [maintainer update] at the beginning of your synopsis line and set the Class of your PR to maintainer-update. Otherwise, the Class of your PR should be change-request. Please mention any added or deleted files in the message, as they have to be explicitly specified to &man.svn.1; when doing a commit. If the diff is more than about 20KB, please compress and uuencode it; otherwise, just include it in the PR as is. Before you &man.send-pr.1;, you should review the Writing the problem report section in the Problem Reports article; it contains far more information about how to write useful problem reports. If your upgrade is motivated by security concerns or a serious fault in the currently committed port, please notify the &a.portmgr; to request immediate rebuilding and redistribution of your port's package. Unsuspecting users of &man.pkg.add.1; will otherwise continue to install the old version via pkg_add -r for several weeks. Once again, please use &man.diff.1; and not &man.shar.1; to send updates to existing ports! This helps ports committers understand exactly what is being changed. Now that you have done all that, you will want to read about how to keep up-to-date in . Using <literal>SVN</literal> to Make Patches If you can, please submit a &man.svn.1; diff — they are easier to handle than diffs between new and old directories. Plus it is easier for you to see what you have changed and to update your diff if something is modified in the Ports Collection from when you started to work on it until you submit your changes, or if the committer asks you to fix something. &prompt.user; cd ~/my_wrkdir &prompt.user; svn co https://svn0.us-west.FreeBSD.org/ports/head/dns/pdnsd &prompt.user; cd ~/my_wrkdir/pdnsd This can be anywhere you want, of course; building ports is not limited to within /usr/ports/. svn0.us-west.FreeBSD.org is a public SVN server. Select the closest mirror and verify the mirror server certificate from the list of Subversion mirror sites. While in the working directory, make any changes that you would usually make to the port. If you add or remove a file, use svn to track these changes: &prompt.user; svn add new_file &prompt.user; svn remove deleted_file Make sure that you check the port using the checklist in and . &prompt.user; svn status &prompt.user; svn update This will try to merge the differences between your patch and current SVN; watch the output carefully. The letter in front of each file name indicates what was done with it. See for a complete list. <literal>SVN</literal> Update File Prefixes U The file was updated without problems. G The file was updated without problems (you will only see this when working against a remote repository). M The file had been modified, and was merged without conflicts. C The file had been modified, and was merged with conflicts.
If you get C as a result of svn update it means something changed in the SVN repository and &man.svn.1; was not able to merge your local changes and those from the repository. It is always a good idea to inspect the changes anyway, since &man.svn.1; does not know anything about how a port should be, so it might (and probably will) merge things that do not make sense. The last step is to make a unified &man.diff.1; of the files against SVN: &prompt.user; svn diff > ../`basename ${PWD}`.diff Any files that have been removed should be explicitly mentioned in the PR, because file removal may not be obvious to the committer. Send your patch following the guidelines in .
The Files <filename>UPDATING</filename> and <filename>MOVED</filename> If upgrading the port requires special steps like changing configuration files or running a specific program, you should document this in the file /usr/ports/UPDATING. The format of an entry in this file is as follows: YYYYMMDD: AFFECTS: users of portcategory/portname AUTHOR: Your name <Your email address> Special instructions If you are including exact portmaster or portupgrading instructions, please make sure to get the shell escaping right. The /usr/ports/MOVED file is used to list moved or removed ports. Each line in the file is made up of the name of the port, where the port was moved to, when, and why. If the port was removed, the section detailing where it was moved to can be left blank. Each section must be separated by the | (pipe) character, like so: old name|new name (blank for deleted)|date of move|reason The date should be entered in the form YYYY-MM-DD. New entries should be added to the end of the file to keep it in chronological order. If a port was removed but has since been restored, delete the line in this file that states that it was removed. The changes can be validated with Tools/scripts/MOVEDlint.awk.
Ports Security Why Security is So Important Bugs are occasionally introduced to the software. Arguably, the most dangerous of them are those opening security vulnerabilities. From the technical viewpoint, such vulnerabilities are to be closed by exterminating the bugs that caused them. However, the policies for handling mere bugs and security vulnerabilities are very different. A typical small bug affects only those users who have enabled some combination of options triggering the bug. The developer will eventually release a patch followed by a new version of the software, free of the bug, but the majority of users will not take the trouble of upgrading immediately because the bug has never vexed them. A critical bug that may cause data loss represents a graver issue. Nevertheless, prudent users know that a lot of possible accidents, besides software bugs, are likely to lead to data loss, and so they make backups of important data; in addition, a critical bug will be discovered really soon. A security vulnerability is all different. First, it may remain unnoticed for years because often it does not cause software malfunction. Second, a malicious party can use it to gain unauthorized access to a vulnerable system, to destroy or alter sensitive data; and in the worst case the user will not even notice the harm caused. Third, exposing a vulnerable system often assists attackers to break into other systems that could not be compromised otherwise. Therefore closing a vulnerability alone is not enough: the audience should be notified of it in most clear and comprehensive manner, which will allow to evaluate the danger and take appropriate actions. Fixing Security Vulnerabilities While on the subject of ports and packages, a security vulnerability may initially appear in the original distribution or in the port files. In the former case, the original software developer is likely to release a patch or a new version instantly, and you will only need to update the port promptly with respect to the author's fix. If the fix is delayed for some reason, you should either mark the port as FORBIDDEN or introduce a patch file of your own to the port. In the case of a vulnerable port, just fix the port as soon as possible. In either case, the standard procedure for submitting your change should be followed unless you have rights to commit it directly to the ports tree. Being a ports committer is not enough to commit to an arbitrary port. Remember that ports usually have maintainers, whom you should respect. Please make sure that the port's revision is bumped as soon as the vulnerability has been closed. That is how the users who upgrade installed packages on a regular basis will see they need to run an update. Besides, a new package will be built and distributed over FTP and WWW mirrors, replacing the vulnerable one. PORTREVISION should be bumped unless PORTVERSION has changed in the course of correcting the vulnerability. That is you should bump PORTREVISION if you have added a patch file to the port, but you should not if you have updated the port to the latest software version and thus already touched PORTVERSION. Please refer to the corresponding section for more information. Keeping the Community Informed The VuXML Database A very important and urgent step to take as early after a security vulnerability is discovered as possible is to notify the community of port users about the jeopardy. Such notification serves two purposes. First, should the danger be really severe it will be wise to apply an instant workaround. E.g., stop the affected network service or even deinstall the port completely until the vulnerability is closed. Second, a lot of users tend to upgrade installed packages only occasionally. They will know from the notification that they must update the package without delay as soon as a corrected version is available. Given the huge number of ports in the tree a security advisory cannot be issued on each incident without creating a flood and losing the attention of the audience when it comes to really serious matters. Therefore security vulnerabilities found in ports are recorded in the FreeBSD VuXML database. The Security Officer Team members also monitor it for issues requiring their intervention. If you have committer rights you can update the VuXML database by yourself. So you will both help the Security Officer Team and deliver the crucial information to the community earlier. However, if you are not a committer, or you believe you have found an exceptionally severe vulnerability please do not hesitate to contact the Security Officer Team directly as described on the FreeBSD Security Information page. The VuXML database is an XML document. Its source file vuln.xml is kept right inside the port security/vuxml. Therefore the file's full pathname will be PORTSDIR/security/vuxml/vuln.xml. Each time you discover a security vulnerability in a port please add an entry for it to that file. Until you are familiar with VuXML, the best thing you can do is to find an existing entry fitting your case, then copy it and use it as a template. A Short Introduction to VuXML The full-blown XML format is complex, and far beyond the scope of this book. However, to gain basic insight on the structure of a VuXML entry you need only the notion of tags. XML tag names are enclosed in angle brackets. Each opening <tag> must have a matching closing </tag>. Tags may be nested. If nesting, the inner tags must be closed before the outer ones. There is a hierarchy of tags, i.e., more complex rules of nesting them. This is similar to HTML. The major difference is that XML is eXtensible, i.e., based on defining custom tags. Due to its intrinsic structure XML puts otherwise amorphous data into shape. VuXML is particularly tailored to mark up descriptions of security vulnerabilities. Now consider a realistic VuXML entry: <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <topic>Several vulnerabilities found in Foo</topic> <affects> <package> <name>foo</name> <name>foo-devel</name> <name>ja-foo</name> <range><ge>1.6</ge><lt>1.9</lt></range> <range><ge>2.*</ge><lt>2.4_1</lt></range> <range><eq>3.0b1</eq></range> </package> <package> <name>openfoo</name> <range><lt>1.10_7</lt></range> <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range> </package> </affects> <description> <body xmlns="http://www.w3.org/1999/xhtml"> <p>J. Random Hacker reports:</p> <blockquote cite="http://j.r.hacker.com/advisories/1"> <p>Several issues in the Foo software may be exploited via carefully crafted QUUX requests. These requests will permit the injection of Bar code, mumble theft, and the readability of the Foo administrator account.</p> </blockquote> </body> </description> <references> <freebsdsa>SA-10:75.foo</freebsdsa> <freebsdpr>ports/987654</freebsdpr> <cvename>CAN-2010-0201</cvename> <cvename>CAN-2010-0466</cvename> <bid>96298</bid> <certsa>CA-2010-99</certsa> <certvu>740169</certvu> <uscertsa>SA10-99A</uscertsa> <uscertta>SA10-99A</uscertta> <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> <url>http://j.r.hacker.com/advisories/1</url> </references> <dates> <discovery>2010-05-25</discovery> <entry>2010-07-13</entry> <modified>2010-09-17</modified> </dates> </vuln> The tag names are supposed to be self-explanatory so we shall take a closer look only at fields you will need to fill in by yourself: This is the top-level tag of a VuXML entry. It has a mandatory attribute, vid, specifying a universally unique identifier (UUID) for this entry (in quotes). You should generate a UUID for each new VuXML entry (and do not forget to substitute it for the template UUID unless you are writing the entry from scratch). You can use &man.uuidgen.1; to generate a VuXML UUID. This is a one-line description of the issue found. The names of packages affected are listed there. Multiple names can be given since several packages may be based on a single master port or software product. This may include stable and development branches, localized versions, and slave ports featuring different choices of important build-time configuration options. It is your responsibility to find all such related packages when writing a VuXML entry. Keep in mind that make search name=foo is your friend. The primary points to look for are as follows: the foo-devel variant for a foo port; other variants with a suffix like -a4 (for print-related packages), -without-gui (for packages with X support disabled), or similar; jp-, ru-, zh-, and other possible localized variants in the corresponding national categories of the ports collection. Affected versions of the package(s) are specified there as one or more ranges using a combination of <lt>, <le>, <eq>, <ge>, and <gt> elements. The version ranges given should not overlap. In a range specification, * (asterisk) denotes the smallest version number. In particular, 2.* is less than 2.a. Therefore an asterisk may be used for a range to match all possible alpha, beta, and RC versions. For instance, <ge>2.*</ge><lt>3.*</lt> will selectively match every 2.x version while <ge>2.0</ge><lt>3.0</lt> will not since the latter misses 2.r3 and matches 3.b. The above example specifies that affected are versions from 1.6 to 1.9 inclusive, versions 2.x before 2.4_1, and version 3.0b1. Several related package groups (essentially, ports) can be listed in the <affected> section. This can be used if several software products (say FooBar, FreeBar and OpenBar) grow from the same code base and still share its bugs and vulnerabilities. Note the difference from listing multiple names within a single <package> section. The version ranges should allow for PORTEPOCH and PORTREVISION if applicable. Please remember that according to the collation rules, a version with a non-zero PORTEPOCH is greater than any version without PORTEPOCH, e.g., 3.0,1 is greater than 3.1 or even than 8.9. This is a summary of the issue. XHTML is used in this field. At least enclosing <p> and </p> should appear. More complex mark-up may be used, but only for the sake of accuracy and clarity: No eye candy please. This section contains references to relevant documents. As many references as apply are encouraged. This is a FreeBSD security advisory. This is a FreeBSD problem report. This is a MITRE CVE identifier. This is a SecurityFocus Bug ID. This is a US-CERT security advisory. This is a US-CERT vulnerability note. This is a US-CERT Cyber Security Alert. This is a US-CERT Technical Cyber Security Alert. This is a URL to an archived posting in a mailing list. The attribute msgid is optional and may specify the message ID of the posting. This is a generic URL. It should be used only if none of the other reference categories apply. This is the date when the issue was disclosed (YYYY-MM-DD). This is the date when the entry was added (YYYY-MM-DD). This is the date when any information in the entry was last modified (YYYY-MM-DD). New entries must not include this field. It should be added upon editing an existing entry. Testing Your Changes to the VuXML Database Assume you just wrote or filled in an entry for a vulnerability in the package clamav that has been fixed in version 0.65_7. As a prerequisite, you need to install fresh versions of the ports ports-mgmt/portaudit, ports-mgmt/portaudit-db, and security/vuxml. To run packaudit you must have permission to write to its DATABASEDIR, typically /var/db/portaudit. To use a different directory set the DATABASEDIR environment variable to a different location. If you are working in a directory other than ${PORTSDIR}/security/vuxml set the VUXMLDIR environment variable to the directory where vuln.xml is located. First, check whether there already is an entry for this vulnerability. If there were such an entry, it would match the previous version of the package, 0.65_6: &prompt.user; packaudit &prompt.user; portaudit clamav-0.65_6 If there is none found, you have the green light to add a new entry for this vulnerability. &prompt.user; cd ${PORTSDIR}/security/vuxml &prompt.user; make newentry When you are done verify its syntax and formatting. &prompt.user; make validate You will need at least one of the following packages installed: textproc/libxml2, textproc/jade. Now rebuild the portaudit database from the VuXML file: &prompt.user; packaudit To verify that the <affected> section of your entry will match correct package(s), issue the following command: &prompt.user; portaudit -f /usr/ports/INDEX -r uuid Please refer to &man.portaudit.1; for better understanding of the command syntax. Make sure that your entry produces no spurious matches in the output. Now check whether the right package versions are matched by your entry: &prompt.user; portaudit clamav-0.65_6 clamav-0.65_7 Affected package: clamav-0.65_6 (matched by clamav<0.65_7) Type of problem: clamav remote denial-of-service. Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html> 1 problem(s) found. The former version should match while the latter one should not. Finally, verify whether the web page generated from the VuXML database looks like expected: &prompt.user; mkdir -p ~/public_html/portaudit &prompt.user; packaudit &prompt.user; lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html Dos and Don'ts Introduction Here is a list of common dos and don'ts that you encounter during the porting process. You should check your own port against this list, but you can also check ports in the PR database that others have submitted. Submit any comments on ports you check as described in Bug Reports and General Commentary. Checking ports in the PR database will both make it faster for us to commit them, and prove that you know what you are doing. <makevar>WRKDIR</makevar> Do not write anything to files outside WRKDIR. WRKDIR is the only place that is guaranteed to be writable during the port build (see installing ports from a CDROM for an example of building ports from a read-only tree). If you need to modify one of the pkg-* files, do so by redefining a variable, not by writing over it. <makevar>WRKDIRPREFIX</makevar> Make sure your port honors WRKDIRPREFIX. Most ports do not have to worry about this. In particular, if you are referring to a WRKDIR of another port, note that the correct location is WRKDIRPREFIXPORTSDIR/subdir/name/work not PORTSDIR/subdir/name/work or .CURDIR/../../subdir/name/work or some such. Also, if you are defining WRKDIR yourself, make sure you prepend ${WRKDIRPREFIX}${.CURDIR} in the front. Differentiating Operating Systems and OS Versions You may come across code that needs modifications or conditional compilation based upon what version of Unix it is running under. If you need to make such changes to the code for conditional compilation, make sure you make the changes as general as possible so that we can back-port code to older FreeBSD systems and cross-port to other BSD systems such as 4.4BSD from CSRG, BSD/386, 386BSD, NetBSD, and OpenBSD. The preferred way to tell 4.3BSD/Reno (1990) and newer versions of the BSD code apart is by using the BSD macro defined in sys/param.h. Hopefully that file is already included; if not, add the code: #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif to the proper place in the .c file. We believe that every system that defines these two symbols has sys/param.h. If you find a system that does not, we would like to know. Please send mail to the &a.ports;. Another way is to use the GNU Autoconf style of doing this: #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif Do not forget to add -DHAVE_SYS_PARAM_H to the CFLAGS in the Makefile for this method. Once you have sys/param.h included, you may use: #if (defined(BSD) && (BSD >= 199103)) to detect if the code is being compiled on a 4.3 Net2 code base or newer (e.g., FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and below). Use: #if (defined(BSD) && (BSD >= 199306)) to detect if the code is being compiled on a 4.4 code base or newer (e.g., FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above). The value of the BSD macro is 199506 for the 4.4BSD-Lite2 code base. This is stated for informational purposes only. It should not be used to distinguish between versions of FreeBSD based only on 4.4-Lite versus versions that have merged in changes from 4.4-Lite2. The __FreeBSD__ macro should be used instead. Use sparingly: __FreeBSD__ is defined in all versions of FreeBSD. Use it if the change you are making only affects FreeBSD. Porting gotchas like the use of sys_errlist[] versus strerror() are Berkeley-isms, not FreeBSD changes. In FreeBSD 2.x, __FreeBSD__ is defined to be 2. In earlier versions, it is 1. Later versions always bump it to match their major version number. If you need to tell the difference between a FreeBSD 1.x system and a FreeBSD 2.x or above system, usually the right answer is to use the BSD macros described above. If there actually is a FreeBSD specific change (such as special shared library options when using ld) then it is OK to use __FreeBSD__ and #if __FreeBSD__ > 1 to detect a FreeBSD 2.x and later system. If you need more granularity in detecting FreeBSD systems since 2.0-RELEASE you can use the following: #if __FreeBSD__ >= 2 #include <osreldate.h> # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif In the hundreds of ports that have been done, there have only been one or two cases where __FreeBSD__ should have been used. Just because an earlier port screwed up and used it in the wrong place does not mean you should do so too. <literal>__FreeBSD_version</literal> Values Here is a convenient list of __FreeBSD_version values as defined in sys/param.h: <literal>__FreeBSD_version</literal> Values Value Date Release 119411 2.0-RELEASE 199501, 199503 March 19, 1995 2.1-CURRENT 199504 April 9, 1995 2.0.5-RELEASE 199508 August 26, 1995 2.2-CURRENT before 2.1 199511 November 10, 1995 2.1.0-RELEASE 199512 November 10, 1995 2.2-CURRENT before 2.1.5 199607 July 10, 1996 2.1.5-RELEASE 199608 July 12, 1996 2.2-CURRENT before 2.1.6 199612 November 15, 1996 2.1.6-RELEASE 199612 2.1.7-RELEASE 220000 February 19, 1997 2.2-RELEASE (not changed) 2.2.1-RELEASE (not changed) 2.2-STABLE after 2.2.1-RELEASE 221001 April 15, 1997 2.2-STABLE after texinfo-3.9 221002 April 30, 1997 2.2-STABLE after top 222000 May 16, 1997 2.2.2-RELEASE 222001 May 19, 1997 2.2-STABLE after 2.2.2-RELEASE 225000 October 2, 1997 2.2.5-RELEASE 225001 November 20, 1997 2.2-STABLE after 2.2.5-RELEASE 225002 December 27, 1997 2.2-STABLE after ldconfig -R merge 226000 March 24, 1998 2.2.6-RELEASE 227000 July 21, 1998 2.2.7-RELEASE 227001 July 21, 1998 2.2-STABLE after 2.2.7-RELEASE 227002 September 19, 1998 2.2-STABLE after &man.semctl.2; change 228000 November 29, 1998 2.2.8-RELEASE 228001 November 29, 1998 2.2-STABLE after 2.2.8-RELEASE 300000 February 19, 1996 3.0-CURRENT before &man.mount.2; change 300001 September 24, 1997 3.0-CURRENT after &man.mount.2; change 300002 June 2, 1998 3.0-CURRENT after &man.semctl.2; change 300003 June 7, 1998 3.0-CURRENT after ioctl arg changes 300004 September 3, 1998 3.0-CURRENT after ELF conversion 300005 October 16, 1998 3.0-RELEASE 300006 October 16, 1998 3.0-CURRENT after 3.0-RELEASE 300007 January 22, 1999 3.0-STABLE after 3/4 branch 310000 February 9, 1999 3.1-RELEASE 310001 March 27, 1999 3.1-STABLE after 3.1-RELEASE 310002 April 14, 1999 3.1-STABLE after C++ constructor/destructor order change 320000 3.2-RELEASE 320001 May 8, 1999 3.2-STABLE 320002 August 29, 1999 3.2-STABLE after binary-incompatible IPFW and socket changes 330000 September 2, 1999 3.3-RELEASE 330001 September 16, 1999 3.3-STABLE 330002 November 24, 1999 3.3-STABLE after adding &man.mkstemp.3; to libc 340000 December 5, 1999 3.4-RELEASE 340001 December 17, 1999 3.4-STABLE 350000 June 20, 2000 3.5-RELEASE 350001 July 12, 2000 3.5-STABLE 400000 January 22, 1999 4.0-CURRENT after 3.4 branch 400001 February 20, 1999 4.0-CURRENT after change in dynamic linker handling 400002 March 13, 1999 4.0-CURRENT after C++ constructor/destructor order change 400003 March 27, 1999 4.0-CURRENT after functioning &man.dladdr.3; 400004 April 5, 1999 4.0-CURRENT after __deregister_frame_info dynamic linker bug fix (also 4.0-CURRENT after EGCS 1.1.2 integration) 400005 April 27, 1999 4.0-CURRENT after &man.suser.9; API change (also 4.0-CURRENT after newbus) 400006 May 31, 1999 4.0-CURRENT after cdevsw registration change 400007 June 17, 1999 4.0-CURRENT after the addition of so_cred for socket level credentials 400008 June 20, 1999 4.0-CURRENT after the addition of a poll syscall wrapper to libc_r 400009 July 20, 1999 4.0-CURRENT after the change of the kernel's dev_t type to struct specinfo pointer 400010 September 25, 1999 4.0-CURRENT after fixing a hole in &man.jail.2; 400011 September 29, 1999 4.0-CURRENT after the sigset_t datatype change 400012 November 15, 1999 4.0-CURRENT after the cutover to the GCC 2.95.2 compiler 400013 December 4, 1999 4.0-CURRENT after adding pluggable linux-mode ioctl handlers 400014 January 18, 2000 4.0-CURRENT after importing OpenSSL 400015 January 27, 2000 4.0-CURRENT after the C++ ABI change in GCC 2.95.2 from -fvtable-thunks to -fno-vtable-thunks by default 400016 February 27, 2000 4.0-CURRENT after importing OpenSSH 400017 March 13, 2000 4.0-RELEASE 400018 March 17, 2000 4.0-STABLE after 4.0-RELEASE 400019 May 5, 2000 4.0-STABLE after the introduction of delayed checksums. 400020 June 4, 2000 4.0-STABLE after merging libxpg4 code into libc. 400021 July 8, 2000 4.0-STABLE after upgrading Binutils to 2.10.0, ELF branding changes, and tcsh in the base system. 410000 July 14, 2000 4.1-RELEASE 410001 July 29, 2000 4.1-STABLE after 4.1-RELEASE 410002 September 16, 2000 4.1-STABLE after &man.setproctitle.3; moved from libutil to libc. 411000 September 25, 2000 4.1.1-RELEASE 411001 4.1.1-STABLE after 4.1.1-RELEASE 420000 October 31, 2000 4.2-RELEASE 420001 January 10, 2001 4.2-STABLE after combining libgcc.a and libgcc_r.a, and associated GCC linkage changes. 430000 March 6, 2001 4.3-RELEASE 430001 May 18, 2001 4.3-STABLE after wint_t introduction. 430002 July 22, 2001 4.3-STABLE after PCI powerstate API merge. 440000 August 1, 2001 4.4-RELEASE 440001 October 23, 2001 4.4-STABLE after d_thread_t introduction. 440002 November 4, 2001 4.4-STABLE after mount structure changes (affects filesystem klds). 440003 December 18, 2001 4.4-STABLE after the userland components of smbfs were imported. 450000 December 20, 2001 4.5-RELEASE 450001 February 24, 2002 4.5-STABLE after the usb structure element rename. 450004 April 16, 2002 4.5-STABLE after the sendmail_enable &man.rc.conf.5; variable was made to take the value NONE. 450005 April 27, 2002 4.5-STABLE after moving to XFree86 4 by default for package builds. 450006 May 1, 2002 4.5-STABLE after accept filtering was fixed so that is no longer susceptible to an easy DoS. 460000 June 21, 2002 4.6-RELEASE 460001 June 21, 2002 4.6-STABLE &man.sendfile.2; fixed to comply with documentation, not to count any headers sent against the amount of data to be sent from the file. 460002 July 19, 2002 4.6.2-RELEASE 460100 June 26, 2002 4.6-STABLE 460101 June 26, 2002 4.6-STABLE after MFC of `sed -i'. 460102 September 1, 2002 4.6-STABLE after MFC of many new pkg_install features from the HEAD. 470000 October 8, 2002 4.7-RELEASE 470100 October 9, 2002 4.7-STABLE 470101 November 10, 2002 Start generated __std{in,out,err}p references rather than __sF. This changes std{in,out,err} from a compile time expression to a runtime one. 470102 January 23, 2003 4.7-STABLE after MFC of mbuf changes to replace m_aux mbufs by m_tag's 470103 February 14, 2003 4.7-STABLE gets OpenSSL 0.9.7 480000 March 30, 2003 4.8-RELEASE 480100 April 5, 2003 4.8-STABLE 480101 May 22, 2003 4.8-STABLE after &man.realpath.3; has been made thread-safe 480102 August 10, 2003 4.8-STABLE 3ware API changes to twe. 490000 October 27, 2003 4.9-RELEASE 490100 October 27, 2003 4.9-STABLE 490101 January 8, 2004 4.9-STABLE after e_sid was added to struct kinfo_eproc. 490102 February 4, 2004 4.9-STABLE after MFC of libmap functionality for rtld. 491000 May 25, 2004 4.10-RELEASE 491100 June 1, 2004 4.10-STABLE 491101 August 11, 2004 4.10-STABLE after MFC of revision 20040629 of the package tools 491102 November 16, 2004 4.10-STABLE after VM fix dealing with unwiring of fictitious pages 492000 December 17, 2004 4.11-RELEASE 492100 December 17, 2004 4.11-STABLE 492101 April 18, 2006 4.11-STABLE after adding libdata/ldconfig directories to mtree files. 500000 March 13, 2000 5.0-CURRENT 500001 April 18, 2000 5.0-CURRENT after adding addition ELF header fields, and changing our ELF binary branding method. 500002 May 2, 2000 5.0-CURRENT after kld metadata changes. 500003 May 18, 2000 5.0-CURRENT after buf/bio changes. 500004 May 26, 2000 5.0-CURRENT after binutils upgrade. 500005 June 3, 2000 5.0-CURRENT after merging libxpg4 code into libc and after TASKQ interface introduction. 500006 June 10, 2000 5.0-CURRENT after the addition of AGP interfaces. 500007 June 29, 2000 5.0-CURRENT after Perl upgrade to 5.6.0 500008 July 7, 2000 5.0-CURRENT after the update of KAME code to 2000/07 sources. 500009 July 14, 2000 5.0-CURRENT after ether_ifattach() and ether_ifdetach() changes. 500010 July 16, 2000 5.0-CURRENT after changing mtree defaults back to original variant, adding -L to follow symlinks. 500011 July 18, 2000 5.0-CURRENT after kqueue API changed. 500012 September 2, 2000 5.0-CURRENT after &man.setproctitle.3; moved from libutil to libc. 500013 September 10, 2000 5.0-CURRENT after the first SMPng commit. 500014 January 4, 2001 5.0-CURRENT after <sys/select.h> moved to <sys/selinfo.h>. 500015 January 10, 2001 5.0-CURRENT after combining libgcc.a and libgcc_r.a, and associated GCC linkage changes. 500016 January 24, 2001 5.0-CURRENT after change allowing libc and libc_r to be linked together, deprecating -pthread option. 500017 February 18, 2001 5.0-CURRENT after switch from struct ucred to struct xucred to stabilize kernel-exported API for mountd et al. 500018 February 24, 2001 5.0-CURRENT after addition of CPUTYPE make variable for controlling CPU-specific optimizations. 500019 June 9, 2001 5.0-CURRENT after moving machine/ioctl_fd.h to sys/fdcio.h 500020 June 15, 2001 5.0-CURRENT after locale names renaming. 500021 June 22, 2001 5.0-CURRENT after Bzip2 import. Also signifies removal of S/Key. 500022 July 12, 2001 5.0-CURRENT after SSE support. 500023 September 14, 2001 5.0-CURRENT after KSE Milestone 2. 500024 October 1, 2001 5.0-CURRENT after d_thread_t, and moving UUCP to ports. 500025 October 4, 2001 5.0-CURRENT after ABI change for descriptor and creds passing on 64 bit platforms. 500026 October 9, 2001 5.0-CURRENT after moving to XFree86 4 by default for package builds, and after the new libc strnstr() function was added. 500027 October 10, 2001 5.0-CURRENT after the new libc strcasestr() function was added. 500028 December 14, 2001 5.0-CURRENT after the userland components of smbfs were imported. (not changed) 5.0-CURRENT after the new C99 specific-width integer types were added. 500029 January 29, 2002 5.0-CURRENT after a change was made in the return value of &man.sendfile.2;. 500030 February 15, 2002 5.0-CURRENT after the introduction of the type fflags_t, which is the appropriate size for file flags. 500031 February 24, 2002 5.0-CURRENT after the usb structure element rename. 500032 March 16, 2002 5.0-CURRENT after the introduction of Perl 5.6.1. 500033 April 3, 2002 5.0-CURRENT after the sendmail_enable &man.rc.conf.5; variable was made to take the value NONE. 500034 April 30, 2002 5.0-CURRENT after mtx_init() grew a third argument. 500035 May 13, 2002 5.0-CURRENT with Gcc 3.1. 500036 May 17, 2002 5.0-CURRENT without Perl in /usr/src 500037 May 29, 2002 5.0-CURRENT after the addition of &man.dlfunc.3; 500038 July 24, 2002 5.0-CURRENT after the types of some struct sockbuf members were changed and the structure was reordered. 500039 September 1, 2002 5.0-CURRENT after GCC 3.2.1 import. Also after headers stopped using _BSD_FOO_T_ and started using _FOO_T_DECLARED. This value can also be used as a conservative estimate of the start of &man.bzip2.1; package support. 500040 September 20, 2002 5.0-CURRENT after various changes to disk functions were made in the name of removing dependency on disklabel structure internals. 500041 October 1, 2002 5.0-CURRENT after the addition of &man.getopt.long.3; to libc. 500042 October 15, 2002 5.0-CURRENT after Binutils 2.13 upgrade, which included new FreeBSD emulation, vec, and output format. 500043 November 1, 2002 5.0-CURRENT after adding weak pthread_XXX stubs to libc, obsoleting libXThrStub.so. 5.0-RELEASE. 500100 January 17, 2003 5.0-CURRENT after branching for RELENG_5_0 500101 February 19, 2003 <sys/dkstat.h> is empty and should not be included. 500102 February 25, 2003 5.0-CURRENT after the d_mmap_t interface change. 500103 February 26, 2003 5.0-CURRENT after taskqueue_swi changed to run without Giant, and taskqueue_swi_giant added to run with Giant. 500104 February 27, 2003 cdevsw_add() and cdevsw_remove() no longer exists. Appearance of MAJOR_AUTO allocation facility. 500105 March 4, 2003 5.0-CURRENT after new cdevsw initialization method. 500106 March 8, 2003 devstat_add_entry() has been replaced by devstat_new_entry() 500107 March 15, 2003 Devstat interface change; see sys/sys/param.h 1.149 500108 March 15, 2003 Token-Ring interface changes. 500109 March 25, 2003 Addition of vm_paddr_t. 500110 March 28, 2003 5.0-CURRENT after &man.realpath.3; has been made thread-safe 500111 April 9, 2003 5.0-CURRENT after &man.usbhid.3; has been synced with NetBSD 500112 April 17, 2003 5.0-CURRENT after new NSS implementation and addition of POSIX.1 getpw*_r, getgr*_r functions 500113 May 2, 2003 5.0-CURRENT after removal of the old rc system. 501000 June 4, 2003 5.1-RELEASE. 501100 June 2, 2003 5.1-CURRENT after branching for RELENG_5_1. 501101 June 29, 2003 5.1-CURRENT after correcting the semantics of sigtimedwait(2) and sigwaitinfo(2). 501102 July 3, 2003 5.1-CURRENT after adding the lockfunc and lockfuncarg fields to &man.bus.dma.tag.create.9;. 501103 July 31, 2003 5.1-CURRENT after GCC 3.3.1-pre 20030711 snapshot integration. 501104 August 5, 2003 5.1-CURRENT 3ware API changes to twe. 501105 August 17, 2003 5.1-CURRENT dynamically-linked /bin and /sbin support and movement of libraries to /lib. 501106 September 8, 2003 5.1-CURRENT after adding kernel support for Coda 6.x. 501107 September 17, 2003 5.1-CURRENT after 16550 UART constants moved from <dev/sio/sioreg.h> to <dev/ic/ns16550.h>. Also when libmap functionality was unconditionally supported by rtld. 501108 September 23, 2003 5.1-CURRENT after PFIL_HOOKS API update 501109 September 27, 2003 5.1-CURRENT after adding kiconv(3) 501110 September 28, 2003 5.1-CURRENT after changing default operations for open and close in cdevsw 501111 October 16, 2003 5.1-CURRENT after changed layout of cdevsw 501112 October 16, 2003 5.1-CURRENT after adding kobj multiple inheritance 501113 October 31, 2003 5.1-CURRENT after the if_xname change in struct ifnet 501114 November 16, 2003 5.1-CURRENT after changing /bin and /sbin to be dynamically linked 502000 December 7, 2003 5.2-RELEASE 502010 February 23, 2004 5.2.1-RELEASE 502100 December 7, 2003 5.2-CURRENT after branching for RELENG_5_2 502101 December 19, 2003 5.2-CURRENT after __cxa_atexit/__cxa_finalize functions were added to libc. 502102 January 30, 2004 5.2-CURRENT after change of default thread library from libc_r to libpthread. 502103 February 21, 2004 5.2-CURRENT after device driver API megapatch. 502104 February 25, 2004 5.2-CURRENT after getopt_long_only() addition. 502105 March 5, 2004 5.2-CURRENT after NULL is made into ((void *)0) for C, creating more warnings. 502106 March 8, 2004 5.2-CURRENT after pf is linked to the build and install. 502107 March 10, 2004 5.2-CURRENT after time_t is changed to a 64-bit value on sparc64. 502108 March 12, 2004 5.2-CURRENT after Intel C/C++ compiler support in some headers and execve(2) changes to be more strictly conforming to POSIX. 502109 March 22, 2004 5.2-CURRENT after the introduction of the bus_alloc_resource_any API 502110 March 27, 2004 5.2-CURRENT after the addition of UTF-8 locales 502111 April 11, 2004 5.2-CURRENT after the removal of the getvfsent(3) API 502112 April 13, 2004 5.2-CURRENT after the addition of the .warning directive for make. 502113 June 4, 2004 5.2-CURRENT after ttyioctl() was made mandatory for serial drivers. 502114 June 13, 2004 5.2-CURRENT after import of the ALTQ framework. 502115 June 14, 2004 5.2-CURRENT after changing sema_timedwait(9) to return 0 on success and a non-zero error code on failure. 502116 June 16, 2004 5.2-CURRENT after changing kernel dev_t to be pointer to struct cdev *. 502117 June 17, 2004 5.2-CURRENT after changing kernel udev_t to dev_t. 502118 June 17, 2004 5.2-CURRENT after adding support for CLOCK_VIRTUAL and CLOCK_PROF to clock_gettime(2) and clock_getres(2). 502119 June 22, 2004 5.2-CURRENT after changing network interface cloning overhaul. 502120 July 2, 2004 5.2-CURRENT after the update of the package tools to revision 20040629. 502121 July 9, 2004 5.2-CURRENT after marking Bluetooth code as non-i386 specific. 502122 July 11, 2004 5.2-CURRENT after the introduction of the KDB debugger framework, the conversion of DDB into a backend and the introduction of the GDB backend. 502123 July 12, 2004 5.2-CURRENT after change to make VFS_ROOT take a struct thread argument as does vflush. Struct kinfo_proc now has a user data pointer. The switch of the default X implementation to xorg was also made at this time. 502124 July 24, 2004 5.2-CURRENT after the change to separate the way ports rc.d and legacy scripts are started. 502125 July 28, 2004 5.2-CURRENT after the backout of the previous change. 502126 July 31, 2004 5.2-CURRENT after the removal of kmem_alloc_pageable() and the import of gcc 3.4.2. 502127 August 2, 2004 5.2-CURRENT after changing the UMA kernel API to allow ctors/inits to fail. 502128 August 8, 2004 5.2-CURRENT after the change of the vfs_mount signature as well as global replacement of PRISON_ROOT with SUSER_ALLOWJAIL for the suser(9) API. 503000 August 23, 2004 5.3-BETA/RC before the pfil API change 503001 September 22, 2004 5.3-RELEASE 503100 October 16, 2004 5.3-STABLE after branching for RELENG_5_3 503101 December 3, 2004 5.3-STABLE after addition of glibc style &man.strftime.3; padding options. 503102 February 13, 2005 5.3-STABLE after OpenBSD's nc(1) import MFC. 503103 February 27, 2005 5.4-PRERELEASE after the MFC of the fixes in <src/include/stdbool.h> and <src/sys/i386/include/_types.h> for using the GCC-compatibility of the Intel C/C++ compiler. 503104 February 28, 2005 5.4-PRERELEASE after the MFC of the change of ifi_epoch from wall clock time to uptime. 503105 March 2, 2005 5.4-PRERELEASE after the MFC of the fix of EOVERFLOW check in vswprintf(3). 504000 April 3, 2005 5.4-RELEASE. 504100 April 3, 2005 5.4-STABLE after branching for RELENG_5_4 504101 May 11, 2005 5.4-STABLE after increasing the default thread stacksizes 504102 June 24, 2005 5.4-STABLE after the addition of sha256 504103 October 3, 2005 5.4-STABLE after the MFC of if_bridge 504104 November 13, 2005 5.4-STABLE after the MFC of bsdiff and portsnap 504105 January 17, 2006 5.4-STABLE after MFC of ldconfig_local_dirs change. 505000 May 12, 2006 5.5-RELEASE. 505100 May 12, 2006 5.5-STABLE after branching for RELENG_5_5 600000 August 18, 2004 6.0-CURRENT 600001 August 27, 2004 6.0-CURRENT after permanently enabling PFIL_HOOKS in the kernel. 600002 August 30, 2004 6.0-CURRENT after initial addition of ifi_epoch to struct if_data. Backed out after a few days. Do not use this value. 600003 September 8, 2004 6.0-CURRENT after the re-addition of the ifi_epoch member of struct if_data. 600004 September 29, 2004 6.0-CURRENT after addition of the struct inpcb argument to the pfil API. 600005 October 5, 2004 6.0-CURRENT after addition of the "-d DESTDIR" argument to newsyslog. 600006 November 4, 2004 6.0-CURRENT after addition of glibc style &man.strftime.3; padding options. 600007 December 12, 2004 6.0-CURRENT after addition of 802.11 framework updates. 600008 January 25, 2005 6.0-CURRENT after changes to VOP_*VOBJECT() functions and introduction of MNTK_MPSAFE flag for Giantfree filesystems. 600009 February 4, 2005 6.0-CURRENT after addition of the cpufreq framework and drivers. 600010 February 6, 2005 6.0-CURRENT after importing OpenBSD's nc(1). 600011 February 12, 2005 6.0-CURRENT after removing semblance of SVID2 matherr() support. 600012 February 15, 2005 6.0-CURRENT after increase of default thread stacks' size. 600013 February 19, 2005 6.0-CURRENT after fixes in <src/include/stdbool.h> and <src/sys/i386/include/_types.h> for using the GCC-compatibility of the Intel C/C++ compiler. 600014 February 21, 2005 6.0-CURRENT after EOVERFLOW checks in vswprintf(3) fixed. 600015 February 25, 2005 6.0-CURRENT after changing the struct if_data member, ifi_epoch, from wall clock time to uptime. 600016 February 26, 2005 6.0-CURRENT after LC_CTYPE disk format changed. 600017 February 27, 2005 6.0-CURRENT after NLS catalogs disk format changed. 600018 February 27, 2005 6.0-CURRENT after LC_COLLATE disk format changed. 600019 February 28, 2005 Installation of acpica includes into /usr/include. 600020 March 9, 2005 Addition of MSG_NOSIGNAL flag to send(2) API. 600021 March 17, 2005 Addition of fields to cdevsw 600022 March 21, 2005 Removed gtar from base system. 600023 April 13, 2005 LOCAL_CREDS, LOCAL_CONNWAIT socket options added to unix(4). 600024 April 19, 2005 &man.hwpmc.4; and related tools added to 6.0-CURRENT. 600025 April 26, 2005 struct icmphdr added to 6.0-CURRENT. 600026 May 3, 2005 pf updated to 3.7. 600027 May 6, 2005 Kernel libalias and ng_nat introduced. 600028 May 13, 2005 POSIX ttyname_r(3) made available through unistd.h and libc. 600029 May 29, 2005 6.0-CURRENT after libpcap updated to v0.9.1 alpha 096. 600030 June 5, 2005 6.0-CURRENT after importing NetBSD's if_bridge(4). 600031 June 10, 2005 6.0-CURRENT after struct ifnet was broken out of the driver softcs. 600032 July 11, 2005 6.0-CURRENT after the import of libpcap v0.9.1. 600033 July 25, 2005 6.0-STABLE after bump of all shared library versions that had not been changed since RELENG_5. 600034 August 13, 2005 6.0-STABLE after credential argument is added to dev_clone event handler. 6.0-RELEASE. 600100 November 1, 2005 6.0-STABLE after 6.0-RELEASE 600101 December 21, 2005 6.0-STABLE after incorporating scripts from the local_startup directories into the base &man.rcorder.8;. 600102 December 30, 2005 6.0-STABLE after updating the ELF types and constants. 600103 January 15, 2006 6.0-STABLE after MFC of pidfile(3) API. 600104 January 17, 2006 6.0-STABLE after MFC of ldconfig_local_dirs change. 600105 February 26, 2006 6.0-STABLE after NLS catalog support of csh(1). 601000 May 6, 2006 6.1-RELEASE 601100 May 6, 2006 6.1-STABLE after 6.1-RELEASE. 601101 June 22, 2006 6.1-STABLE after the import of csup. 601102 July 11, 2006 6.1-STABLE after the iwi(4) update. 601103 July 17, 2006 6.1-STABLE after the resolver update to BIND9, and exposure of reentrant version of netdb functions. 601104 August 8, 2006 6.1-STABLE after DSO (dynamic shared objects) support has been enabled in OpenSSL. 601105 September 2, 2006 6.1-STABLE after 802.11 fixups changed the api for the IEEE80211_IOC_STA_INFO ioctl. 602000 November 15, 2006 6.2-RELEASE 602100 September 15, 2006 6.2-STABLE after 6.2-RELEASE. 602101 December 12, 2006 6.2-STABLE after the addition of Wi-Spy quirk. 602102 December 28, 2006 6.2-STABLE after pci_find_extcap() addition. 602103 January 16, 2007 6.2-STABLE after MFC of dlsym change to look for a requested symbol both in specified dso and its implicit dependencies. 602104 January 28, 2007 6.2-STABLE after MFC of ng_deflate(4) and ng_pred1(4) netgraph nodes and new compression and encryption modes for ng_ppp(4) node. 602105 February 20, 2007 6.2-STABLE after MFC of BSD licensed version of &man.gzip.1; ported from NetBSD. 602106 March 31, 2007 6.2-STABLE after MFC of PCI MSI and MSI-X support. 602107 April 6, 2007 6.2-STABLE after MFC of ncurses 5.6 and wide character support. 602108 April 11, 2007 6.2-STABLE after MFC of CAM 'SG' peripheral device, which implements a subset of Linux SCSI SG passthrough device API. 602109 April 17, 2007 6.2-STABLE after MFC of readline 5.2 patchset 002. 602110 May 2, 2007 6.2-STABLE after MFC of pmap_invalidate_cache(), pmap_change_attr(), pmap_mapbios(), pmap_mapdev_attr(), and pmap_unmapbios() for amd64 and i386. 602111 June 11, 2007 6.2-STABLE after MFC of BOP_BDFLUSH and caused breakage of the filesystem modules KBI. 602112 September 21, 2007 6.2-STABLE after libutil(3) MFC's. 602113 October 25, 2007 6.2-STABLE after MFC of wide and single byte ctype separation. Newly compiled binary that references to ctype.h may require a new symbol, __mb_sb_limit, which is not available on older systems. 602114 October 30, 2007 6.2-STABLE after ctype ABI forward compatibility restored. 602115 November 21, 2007 6.2-STABLE after back out of wide and single byte ctype separation. 603000 November 25, 2007 6.3-RELEASE 603100 November 25, 2007 6.3-STABLE after 6.3-RELEASE. 603101 December 7, 2007 6.3-STABLE after fixing multibyte type support in bit macro. 603102 April 24, 2008 6.3-STABLE after adding l_sysid to struct flock. 603103 May 27, 2008 6.3-STABLE after MFC of the memrchr function. 603104 June 15, 2008 6.3-STABLE after MFC of support for :u variable modifier in make(1). 604000 October 4, 2008 6.4-RELEASE 604100 October 4, 2008 6.4-STABLE after 6.4-RELEASE. 700000 July 11, 2005 7.0-CURRENT. 700001 July 23, 2005 7.0-CURRENT after bump of all shared library versions that had not been changed since RELENG_5. 700002 August 13, 2005 7.0-CURRENT after credential argument is added to dev_clone event handler. 700003 August 25, 2005 7.0-CURRENT after memmem(3) is added to libc. 700004 October 30, 2005 7.0-CURRENT after solisten(9) kernel arguments are modified to accept a backlog parameter. 700005 November 11, 2005 7.0-CURRENT after IFP2ENADDR() was changed to return a pointer to IF_LLADDR(). 700006 November 11, 2005 7.0-CURRENT after addition of if_addr member to struct ifnet and IFP2ENADDR() removal. 700007 December 2, 2005 7.0-CURRENT after incorporating scripts from the local_startup directories into the base &man.rcorder.8;. 700008 December 5, 2005 7.0-CURRENT after removal of MNT_NODEV mount option. 700009 December 19, 2005 7.0-CURRENT after ELF-64 type changes and symbol versioning. 700010 December 20, 2005 7.0-CURRENT after addition of hostb and vgapci drivers, addition of pci_find_extcap(), and changing the AGP drivers to no longer map the aperture. 700011 December 31, 2005 7.0-CURRENT after tv_sec was made time_t on all platforms but Alpha. 700012 January 8, 2006 7.0-CURRENT after ldconfig_local_dirs change. 700013 January 12, 2006 7.0-CURRENT after changes to /etc/rc.d/abi to support /compat/linux/etc/ld.so.cache being a symlink in a readonly filesystem. 700014 January 26, 2006 7.0-CURRENT after pts import. 700015 March 26, 2006 7.0-CURRENT after the introduction of version 2 of &man.hwpmc.4;'s ABI. 700016 April 22, 2006 7.0-CURRENT after addition of &man.fcloseall.3; to libc. 700017 May 13, 2006 7.0-CURRENT after removal of ip6fw. 700018 July 15, 2006 7.0-CURRENT after import of snd_emu10kx. 700019 July 29, 2006 7.0-CURRENT after import of OpenSSL 0.9.8b. 700020 September 3, 2006 7.0-CURRENT after addition of bus_dma_get_tag function 700021 September 4, 2006 7.0-CURRENT after libpcap 0.9.4 and tcpdump 3.9.4 import. 700022 September 9, 2006 7.0-CURRENT after dlsym change to look for a requested symbol both in specified dso and its implicit dependencies. 700023 September 23, 2006 7.0-CURRENT after adding new sound IOCTLs for the OSSv4 mixer API. 700024 September 28, 2006 7.0-CURRENT after import of OpenSSL 0.9.8d. 700025 November 11, 2006 7.0-CURRENT after the addition of libelf. 700026 November 26, 2006 7.0-CURRENT after major changes on sound sysctls. 700027 November 30, 2006 7.0-CURRENT after the addition of Wi-Spy quirk. 700028 December 15, 2006 7.0-CURRENT after the addition of sctp calls to libc 700029 January 26, 2007 7.0-CURRENT after the GNU &man.gzip.1; implementation was replaced with a BSD licensed version ported from NetBSD. 700030 February 7, 2007 7.0-CURRENT after the removal of IPIP tunnel encapsulation (VIFF_TUNNEL) from the IPv4 multicast forwarding code. 700031 February 23, 2007 7.0-CURRENT after the modification of bus_setup_intr() (newbus). 700032 March 2, 2007 7.0-CURRENT after the inclusion of ipw(4) and iwi(4) firmware. 700033 March 9, 2007 7.0-CURRENT after the inclusion of ncurses wide character support. 700034 March 19, 2007 7.0-CURRENT after changes to how insmntque(), getnewvnode(), and vfs_hash_insert() work. 700035 March 26, 2007 7.0-CURRENT after addition of a notify mechanism for CPU frequency changes. 700036 April 6, 2007 7.0-CURRENT after import of the ZFS filesystem. 700037 April 8, 2007 7.0-CURRENT after addition of CAM 'SG' peripheral device, which implements a subset of Linux SCSI SG passthrough device API. 700038 April 30, 2007 7.0-CURRENT after changing &man.getenv.3;, &man.putenv.3;, &man.setenv.3; and &man.unsetenv.3; to be POSIX conformant. 700039 May 1, 2007 7.0-CURRENT after the changes in 700038 were backed out. 700040 May 10, 2007 7.0-CURRENT after the addition of &man.flopen.3; to libutil. 700041 May 13, 2007 7.0-CURRENT after enabling symbol versioning, and changing the default thread library to libthr. 700042 May 19, 2007 7.0-CURRENT after the import of gcc 4.2.0. 700043 May 21, 2007 7.0-CURRENT after bump of all shared library versions that had not been changed since RELENG_6. 700044 June 7, 2007 7.0-CURRENT after changing the argument for vn_open()/VOP_OPEN() from file descriptor index to the struct file *. 700045 June 10, 2007 7.0-CURRENT after changing &man.pam.nologin.8; to provide an account management function instead of an authentication function to the PAM framework. 700046 June 11, 2007 7.0-CURRENT after updated 802.11 wireless support. 700047 June 11, 2007 7.0-CURRENT after adding TCP LRO interface capabilities. 700048 June 12, 2007 7.0-CURRENT after RFC 3678 API support added to the IPv4 stack. Legacy RFC 1724 behavior of the IP_MULTICAST_IF ioctl has now been removed; 0.0.0.0/8 may no longer be used to specify an interface index. struct ipmreqn should be used instead. 700049 July 3, 2007 7.0-CURRENT after importing pf from OpenBSD 4.1 (not changed) 7.0-CURRENT after adding IPv6 support for FAST_IPSEC, deleting KAME IPSEC, and renaming FAST_IPSEC to IPSEC. 700050 July 4, 2007 7.0-CURRENT after converting setenv/putenv/etc. calls from traditional BSD to POSIX. 700051 July 4, 2007 7.0-CURRENT after adding new mmap/lseek/etc syscalls. 700052 July 6, 2007 7.0-CURRENT after moving I4B headers to include/i4b. 700053 September 30, 2007 7.0-CURRENT after the addition of support for PCI domains 700054 October 25, 2007 7.0-CURRENT after MFC of wide and single byte ctype separation. 700055 October 28, 2007 7.0-RELEASE, and 7.0-CURRENT after ABI backwards compatibility to the FreeBSD 4/5/6 versions of the PCIOCGETCONF, PCIOCREAD and PCIOCWRITE IOCTLs was MFCed, which required the ABI of the PCIOCGETCONF IOCTL to be broken again 700100 December 22, 2007 7.0-STABLE after 7.0-RELEASE 700101 February 8, 2008 7.0-STABLE after the MFC of m_collapse(). 700102 March 30, 2008 7.0-STABLE after the MFC of kdb_enter_why(). 700103 April 10, 2008 7.0-STABLE after adding l_sysid to struct flock. 700104 April 11, 2008 7.0-STABLE after the MFC of procstat(1). 700105 April 11, 2008 7.0-STABLE after the MFC of umtx features. 700106 April 15, 2008 7.0-STABLE after the MFC of &man.write.2; support to &man.psm.4;. 700107 April 20, 2008 7.0-STABLE after the MFC of F_DUP2FD command to &man.fcntl.2;. 700108 May 5, 2008 7.0-STABLE after some &man.lockmgr.9; changes, which makes it necessary to include sys/lock.h in order to use &man.lockmgr.9;. 700109 May 27, 2008 7.0-STABLE after MFC of the memrchr function. 700110 August 5, 2008 7.0-STABLE after MFC of kernel NFS lockd client. 700111 August 20, 2008 7.0-STABLE after addition of physically contiguous jumbo frame support. 700112 August 27, 2008 7.0-STABLE after MFC of kernel DTrace support. 701000 November 25, 2008 7.1-RELEASE 701100 November 25, 2008 7.1-STABLE after 7.1-RELEASE. 701101 January 10, 2009 7.1-STABLE after strndup merge. 701102 January 17, 2009 7.1-STABLE after cpuctl(4) support added. 701103 February 7, 2009 7.1-STABLE after the merge of multi-/no-IPv4/v6 jails. 701104 February 14, 2009 7.1-STABLE after the store of the suspension owner in the struct mount, and introduction of vfs_susp_clean method into the struct vfsops. 701105 March 12, 2009 7.1-STABLE after the incompatible change to the kern.ipc.shmsegs sysctl to allow to allocate larger SysV shared memory segments on 64bit architectures. 701106 March 14, 2009 7.1-STABLE after the merge of a fix for POSIX semaphore wait operations. 702000 April 15, 2009 7.2-RELEASE 702100 April 15, 2009 7.2-STABLE after 7.2-RELEASE. 702101 May 15, 2009 7.2-STABLE after ichsmb(4) was changed to use left-adjusted slave addressing to match other SMBus controller drivers. 702102 May 28, 2009 7.2-STABLE after MFC of the fdopendir function. 702103 June 06, 2009 7.2-STABLE after MFC of PmcTools. 702104 July 14, 2009 7.2-STABLE after MFC of the closefrom system call. 702105 July 31, 2009 7.2-STABLE after MFC of the SYSVIPC ABI change. 702106 September 14, 2009 7.2-STABLE after MFC of the x86 PAT enhancements and addition of d_mmap_single() and the scatter/gather list VM object type. 703000 February 9, 2010 7.3-RELEASE 703100 February 9, 2010 7.3-STABLE after 7.3-RELEASE. 704000 December 22, 2010 7.4-RELEASE 704100 December 22, 2010 7.4-STABLE after 7.4-RELEASE. 800000 October 11, 2007 8.0-CURRENT. Separating wide and single byte ctype. 800001 October 16, 2007 8.0-CURRENT after libpcap 0.9.8 and tcpdump 3.9.8 import. 800002 October 21, 2007 8.0-CURRENT after renaming kthread_create() and friends to kproc_create() etc. 800003 October 24, 2007 8.0-CURRENT after ABI backwards compatibility to the FreeBSD 4/5/6 versions of the PCIOCGETCONF, PCIOCREAD and PCIOCWRITE IOCTLs was added, which required the ABI of the PCIOCGETCONF IOCTL to be broken again 800004 November 12, 2007 8.0-CURRENT after agp(4) driver moved from src/sys/pci to src/sys/dev/agp 800005 December 4, 2007 8.0-CURRENT after changes to the jumbo frame allocator (rev 174247). 800006 December 7, 2007 8.0-CURRENT after the addition of callgraph capture functionality to &man.hwpmc.4;. 800007 December 25, 2007 8.0-CURRENT after kdb_enter() gains a "why" argument. 800008 December 28, 2007 8.0-CURRENT after LK_EXCLUPGRADE option removal. 800009 January 9, 2008 8.0-CURRENT after introduction of &man.lockmgr.disown.9; 800010 January 10, 2008 8.0-CURRENT after the &man.vn.lock.9; prototype change. 800011 January 13, 2008 8.0-CURRENT after the &man.VOP.LOCK.9; and &man.VOP.UNLOCK.9; prototype changes. 800012 January 19, 2008 8.0-CURRENT after introduction of &man.lockmgr.recursed.9;, &man.BUF.RECURSED.9; and &man.BUF.ISLOCKED.9; and the removal of BUF_REFCNT(). 800013 January 23, 2008 8.0-CURRENT after introduction of the ASCII encoding. 800014 January 24, 2008 8.0-CURRENT after changing the prototype of &man.lockmgr.9; and removal of lockcount() and LOCKMGR_ASSERT(). 800015 January 26, 2008 8.0-CURRENT after extending the types of the &man.fts.3; structures. 800016 February 1, 2008 8.0-CURRENT after adding an argument to MEXTADD(9) 800017 February 6, 2008 8.0-CURRENT after the introduction of LK_NODUP and LK_NOWITNESS options in the &man.lockmgr.9; space. 800018 February 8, 2008 8.0-CURRENT after the addition of m_collapse. 800019 February 9, 2008 8.0-CURRENT after the addition of current working directory, root directory, and jail directory support to the kern.proc.filedesc sysctl. 800020 February 13, 2008 8.0-CURRENT after introduction of &man.lockmgr.assert.9; and BUF_ASSERT functions. 800021 February 15, 2008 8.0-CURRENT after introduction of &man.lockmgr.args.9; and LK_INTERNAL flag removal. 800022 (backed out) 8.0-CURRENT after changing the default system ar to BSD &man.ar.1;. 800023 February 25, 2008 8.0-CURRENT after changing the prototypes of &man.lockstatus.9; and &man.VOP.ISLOCKED.9;, more specifically retiring the struct thread argument. 800024 March 1, 2008 8.0-CURRENT after axing out the lockwaiters and BUF_LOCKWAITERS functions, changing the return value of brelvp from void to int and introducing new flags for &man.lockinit.9;. 800025 March 8, 2008 8.0-CURRENT after adding F_DUP2FD command to &man.fcntl.2;. 800026 March 12, 2008 8.0-CURRENT after changing the priority parameter to cv_broadcastpri such that 0 means no priority. 800027 March 24, 2008 8.0-CURRENT after changing the bpf monitoring ABI when zerocopy bpf buffers were added. 800028 March 26, 2008 8.0-CURRENT after adding l_sysid to struct flock. 800029 March 28, 2008 8.0-CURRENT after reintegration of the BUF_LOCKWAITERS function and the addition of &man.lockmgr.waiters.9;. 800030 April 1, 2008 8.0-CURRENT after the introduction of the &man.rw.try.rlock.9; and &man.rw.try.wlock.9; functions. 800031 April 6, 2008 8.0-CURRENT after the introduction of the lockmgr_rw and lockmgr_args_rw functions. 800032 April 8, 2008 8.0-CURRENT after the implementation of the openat and related syscalls, introduction of the O_EXEC flag for the &man.open.2;, and providing the corresponding linux compatibility syscalls. 800033 April 8, 2008 8.0-CURRENT after added &man.write.2; support for &man.psm.4; in native operation level. Now arbitrary commands can be written to /dev/psm%d and status can be read back from it. 800034 April 10, 2008 8.0-CURRENT after introduction of the memrchr function. 800035 April 16, 2008 8.0-CURRENT after introduction of the fdopendir function. 800036 April 20, 2008 8.0-CURRENT after switchover of 802.11 wireless to multi-bss support (aka vaps). 800037 May 9, 2008 8.0-CURRENT after addition of multi routing table support (aka setfib(1), setfib(2)). 800038 May 26, 2008 8.0-CURRENT after removal of netatm and ISDN4BSD. Also, the addition of the Compact C Type (CTF) tools. 800039 June 14, 2008 8.0-CURRENT after removal of sgtty. 800040 June 26, 2008 8.0-CURRENT with kernel NFS lockd client. 800041 July 22, 2008 8.0-CURRENT after addition of arc4random_buf(3) and arc4random_uniform(3). 800042 August 8, 2008 8.0-CURRENT after addition of cpuctl(4). 800043 August 13, 2008 8.0-CURRENT after changing bpf(4) to use a single device node, instead of device cloning. 800044 August 17, 2008 8.0-CURRENT after the commit of the first step of the vimage project renaming global variables to be virtualized with a V_ prefix with macros to map them back to their global names. 800045 August 20, 2008 8.0-CURRENT after the integration of the MPSAFE TTY layer, including changes to various drivers and utilities that interact with it. 800046 September 8, 2008 8.0-CURRENT after the separation of the GDT per CPU on amd64 architecture. 800047 September 10, 2008 8.0-CURRENT after removal of VSVTX, VSGID and VSUID. 800048 September 16, 2008 8.0-CURRENT after converting the kernel NFS mount code to accept individual mount options in the nmount() iovec, not just one big struct nfs_args. 800049 September 17, 2008 8.0-CURRENT after the removal of &man.suser.9; and &man.suser.cred.9;. 800050 October 20, 2008 8.0-CURRENT after buffer cache API change. 800051 October 23, 2008 8.0-CURRENT after the removal of the &man.MALLOC.9; and &man.FREE.9; macros. 800052 October 28, 2008 8.0-CURRENT after the introduction of accmode_t and renaming of VOP_ACCESS 'a_mode' argument to 'a_accmode'. 800053 November 2, 2008 8.0-CURRENT after the prototype change of &man.vfs.busy.9; and the introduction of its MBF_NOWAIT and MBF_MNTLSTLOCK flags. 800054 November 22, 2008 8.0-CURRENT after the addition of buf_ring, memory barriers and ifnet functions to facilitate multiple hardware transmit queues for cards that support them, and a lockless ring-buffer implementation to enable drivers to more efficiently manage queuing of packets. 800055 November 27, 2008 8.0-CURRENT after the addition of Intel™ Core, Core2, and Atom support to &man.hwpmc.4;. 800056 November 29, 2008 8.0-CURRENT after the introduction of multi-/no-IPv4/v6 jails. 800057 December 1, 2008 8.0-CURRENT after the switch to the ath hal source code. 800058 December 12, 2008 8.0-CURRENT after the introduction of the VOP_VPTOCNP operation. 800059 December 15, 2008 8.0-CURRENT incorporates the new arp-v2 rewrite. 800060 December 19, 2008 8.0-CURRENT after the addition of makefs. 800061 January 15, 2009 8.0-CURRENT after TCP Appropriate Byte Counting. 800062 January 28, 2009 8.0-CURRENT after removal of minor(), minor2unit(), unit2minor(), etc. 800063 February 18, 2009 8.0-CURRENT after GENERIC config change to use the USB2 stack, but also the addition of fdevname(3). 800064 February 23, 2009 8.0-CURRENT after the USB2 stack is moved to and replaces dev/usb. 800065 February 26, 2009 8.0-CURRENT after the renaming of all functions in libmp(3). 800066 February 27, 2009 8.0-CURRENT after changing USB devfs handling and layout. 800067 February 28, 2009 8.0-CURRENT after adding getdelim(), getline(), stpncpy(), strnlen(), wcsnlen(), wcscasecmp(), and wcsncasecmp(). 800068 March 2, 2009 8.0-CURRENT after renaming the ushub devclass to uhub. 800069 March 9, 2009 8.0-CURRENT after libusb20.so.1 was renamed to libusb.so.1. 800070 March 9, 2009 8.0-CURRENT after merging IGMPv3 and Source-Specific Multicast (SSM) to the IPv4 stack. 800071 March 14, 2009 8.0-CURRENT after gcc was patched to use C99 inline semantics in c99 and gnu99 mode. 800072 March 15, 2009 8.0-CURRENT after the IFF_NEEDSGIANT flag has been removed; non-MPSAFE network device drivers are no longer supported. 800073 March 18, 2009 8.0-CURRENT after the dynamic string token substitution has been implemented for rpath and needed paths. 800074 March 24, 2009 8.0-CURRENT after tcpdump 4.0.0 and libpcap 1.0.0 import. 800075 April 6, 2009 8.0-CURRENT after layout of structs vnet_net, vnet_inet and vnet_ipfw has been changed. 800076 April 9, 2009 8.0-CURRENT after adding delay profiles in dummynet. 800077 April 14, 2009 8.0-CURRENT after removing VOP_LEASE() and vop_vector.vop_lease. 800078 April 15, 2009 8.0-CURRENT after struct rt_weight fields have been added to struct rt_metrics and struct rt_metrics_lite, changing the layout of struct rt_metrics_lite. A bump to RTM_VERSION was made, but backed out. 800079 April 15, 2009 8.0-CURRENT after struct llentry pointers are added to struct route and struct route_in6. 800080 April 15, 2009 8.0-CURRENT after layout of struct inpcb has been changed. 800081 April 19, 2009 8.0-CURRENT after the layout of struct malloc_type has been changed. 800082 April 21, 2009 8.0-CURRENT after the layout of struct ifnet has changed, and with if_ref() and if_rele() ifnet refcounting. 800083 April 22, 2009 8.0-CURRENT after the implementation of a low-level Bluetooth HCI API. 800084 April 29, 2009 8.0-CURRENT after IPv6 SSM and MLDv2 changes. 800085 April 30, 2009 8.0-CURRENT after enabling support for VIMAGE kernel builds with one active image. 800086 May 8, 2009 8.0-CURRENT after adding support for input lines of arbitrarily length in patch(1). 800087 May 11, 2009 8.0-CURRENT after some VFS KPI changes. The thread argument has been removed from the FSD parts of the VFS. VFS_* functions do not need the context any more because it always refers to curthread. In some special cases, the old behavior is retained. 800088 May 20, 2009 8.0-CURRENT after net80211 monitor mode changes. 800089 May 23, 2009 8.0-CURRENT after adding UDP control block support. 800090 May 23, 2009 8.0-CURRENT after virtualizing interface cloning. 800091 May 27, 2009 8.0-CURRENT after adding hierarchical jails and removing global securelevel. 800092 May 29, 2009 8.0-CURRENT after changing sx_init_flags() KPI. The SX_ADAPTIVESPIN is retired and a new SX_NOADAPTIVE flag is introduced in order to handle the reversed logic. 800093 May 29, 2009 8.0-CURRENT after adding mnt_xflag to struct mount. 800094 May 30, 2009 8.0-CURRENT after adding &man.VOP.ACCESSX.9;. 800095 May 30, 2009 8.0-CURRENT after changing the polling KPI. The polling handlers now return the number of packets processed. A new IFCAP_POLLING_NOCOUNT is also introduced to specify that the return value is not significant and the counting should be skipped. 800096 June 1, 2009 8.0-CURRENT after updating to the new netisr implementation and after changing the way we store and access FIBs. 800097 June 8, 2009 8.0-CURRENT after the introduction of vnet destructor hooks and infrastructure. 800097 June 11, 2009 8.0-CURRENT after the introduction of netgraph outbound to inbound path call detection and queuing, which also changed the layout of struct thread. 800098 June 14, 2009 8.0-CURRENT after OpenSSL 0.9.8k import. 800099 June 22, 2009 8.0-CURRENT after NGROUPS update and moving route virtualization into its own VImage module. 800100 June 24, 2009 8.0-CURRENT after SYSVIPC ABI change. 800101 June 29, 2009 8.0-CURRENT after the removal of the /dev/net/* per-interface character devices. 800102 July 12, 2009 8.0-CURRENT after padding was added to struct sackhint, struct tcpcb, and struct tcpstat. 800103 July 13, 2009 8.0-CURRENT after replacing struct tcpopt with struct toeopt in the TOE driver interface to the TCP syncache. 800104 July 14, 2009 8.0-CURRENT after the addition of the linker-set based per-vnet allocator. 800105 July 19, 2009 8.0-CURRENT after version bump for all shared libraries that do not have symbol versioning turned on. 800106 July 24, 2009 8.0-CURRENT after introduction of OBJT_SG VM object type. 800107 August 2, 2009 8.0-CURRENT after making the newbus subsystem Giant free by adding the newbus sxlock and 8.0-RELEASE. 800108 November 21, 2009 8.0-STABLE after implementing EVFILT_USER kevent filter. 800500 January 7, 2010 8.0-STABLE after __FreeBSD_version bump to make pkg_add -r use packages-8-stable. 800501 January 24, 2010 8.0-STABLE after change of the scandir(3) and alphasort(3) prototypes to conform to SUSv4. 800502 January 31, 2010 8.0-STABLE after addition of sigpause(3). 800503 February 25, 2010 8.0-STABLE after addition of SIOCGIFDESCR and SIOCSIFDESCR ioctls to network interfaces. These ioctl can be used to manipulate interface description, as inspired by OpenBSD. 800504 March 1, 2010 8.0-STABLE after MFC of importing x86emu, a software emulator for real mode x86 CPU from OpenBSD. 800505 May 18, 2010 8.0-STABLE after MFC of adding liblzma, xz, xzdec, and lzmainfo. 801000 June 14, 2010 8.1-RELEASE 801500 June 14, 2010 8.1-STABLE after 8.1-RELEASE. 801501 November 3, 2010 8.1-STABLE after KBI change in struct sysentvec, and implementation of PL_FLAG_SCE/SCX/EXEC/SI and pl_siginfo for ptrace(PT_LWPINFO) . 802000 December 22, 2010 8.2-RELEASE 802500 December 22, 2010 8.2-STABLE after 8.2-RELEASE. 802501 February 28, 2011 8.2-STABLE after merging DTrace changes, including support for userland tracing. 802502 March 6, 2011 8.2-STABLE after merging log2 and log2f into libm. 802503 May 1, 2011 8.2-STABLE after upgrade of the gcc to the last GPLv2 version from the FSF gcc-4_2-branch. 802504 May 28, 2011 8.2-STABLE after introduction of the KPI and supporting infrastructure for modular congestion control. 802505 May 28, 2011 8.2-STABLE after introduction of Hhook and Khelp KPIs. 802506 May 28, 2011 8.2-STABLE after addition of OSD to struct tcpcb. 802507 June 6, 2011 8.2-STABLE after ZFS v28 import. 802508 June 8, 2011 8.2-STABLE after removal of the schedtail event handler and addition of the sv_schedtail method to struct sysvec. 802509 July 14, 2011 8.2-STABLE after merging the SSSE3 support into binutils. 802510 July 19, 2011 8.2-STABLE after addition of RFTSIGZMB flag for rfork(2). 802511 September 9, 2011 8.2-STABLE after addition of automatic detection of USB mass storage devices which do not support the no synchronize cache SCSI command. 802512 September 10, 2011 8.2-STABLE after merging of re-factoring of auto-quirk. 802513 October 25, 2011 8.2-STABLE after merging of the MAP_PREFAULT_READ flag to mmap(2). 802514 November 16, 2011 8.2-STABLE after merging of addition of posix_fallocate(2) syscall. 802515 January 6, 2012 8.2-STABLE after merging of addition of the posix_fadvise(2) system call. 802516 January 16, 2012 8.2-STABLE after merging gperf 3.0.3 802517 February 15, 2012 8.2-STABLE after introduction of the new extensible sysctl(3) interface NET_RT_IFLISTL to query address lists (rev 231769). 803000 March 3, 2012 8.3-RELEASE. 803500 March 3, 2012 8.3-STABLE after branching releng/8.3 (RELENG_8_3). 804000 March 28, 2013 8.4-RELEASE. 804500 March 28, 2013 8.4-STABLE after 8.4-RELEASE. 900000 August 22, 2009 9.0-CURRENT. 900001 September 8, 2009 9.0-CURRENT after importing x86emu, a software emulator for real mode x86 CPU from OpenBSD. 900002 September 23, 2009 9.0-CURRENT after implementing the EVFILT_USER kevent filter functionality. 900003 December 2, 2009 9.0-CURRENT after addition of sigpause(3) and PIE support in csu. 900004 December 6, 2009 9.0-CURRENT after addition of libulog and its libutempter compatibility interface. 900005 December 12, 2009 9.0-CURRENT after addition of sleepq_sleepcnt(), which can be used to query the number of waiters on a specific waiting queue. 900006 January 4, 2010 9.0-CURRENT after change of the scandir(3) and alphasort(3) prototypes to conform to SUSv4. 900007 January 13, 2010 9.0-CURRENT after the removal of utmp(5) and the addition of utmpx (see getutxent(3)) for improved logging of user logins and system events. 900008 January 20, 2010 9.0-CURRENT after the import of BSDL bc/dc and the deprecation of GNU bc/dc. 900009 January 26, 2010 9.0-CURRENT after the addition of SIOCGIFDESCR and SIOCSIFDESCR ioctls to network interfaces. These ioctl can be used to manipulate interface description, as inspired by OpenBSD. 900010 March 22, 2010 9.0-CURRENT after the import of zlib 1.2.4. 900011 April 24, 2010 9.0-CURRENT after adding soft-updates journalling. 900012 May 10, 2010 9.0-CURRENT after adding liblzma, xz, xzdec, and lzmainfo. 900013 May 24, 2010 9.0-CURRENT after bringing in USB fixes for linux(4). 900014 June 10, 2010 9.0-CURRENT after adding Clang. 900015 July 22, 2010 9.0-CURRENT after the import of BSD grep. 900016 July 28, 2010 9.0-CURRENT after adding mti_zone to struct malloc_type_internal. 900017 August 23, 2010 9.0-CURRENT after changing back default grep to GNU grep and adding WITH_BSD_GREP knob. 900018 August 24, 2010 9.0-CURRENT after the pthread_kill(3) -generated signal is identified as SI_LWP in si_code. Previously, si_code was SI_USER. 900019 August 28, 2010 9.0-CURRENT after addition of the MAP_PREFAULT_READ flag to mmap(2). 900020 September 9, 2010 9.0-CURRENT after adding drain functionality to sbufs, which also changed the layout of struct sbuf. 900021 September 13, 2010 9.0-CURRENT after DTrace has grown support for userland tracing. 900022 October 2, 2010 9.0-CURRENT after addition of the BSDL man utilities and retirement of GNU/GPL man utilities. 900023 October 11, 2010 9.0-CURRENT after updating xz to git 20101010 snapshot. 900024 November 11, 2010 9.0-CURRENT after libgcc.a was replaced by libcompiler_rt.a. 900025 November 12, 2010 9.0-CURRENT after the introduction of the modularised congestion control. 900026 November 30, 2010 9.0-CURRENT after the introduction of Serial Management Protocol (SMP) passthrough and the XPT_SMP_IO and XPT_GDEV_ADVINFO CAM CCBs. 900027 December 5, 2010 9.0-CURRENT after the addition of log2 to libm. 900028 December 21, 2010 9.0-CURRENT after the addition of the Hhook (Helper Hook), Khelp (Kernel Helpers) and Object Specific Data (OSD) KPIs. 900029 December 28, 2010 9.0-CURRENT after the modification of the TCP stack to allow Khelp modules to interact with it via helper hook points and store per-connection data in the TCP control block. 900030 January 12, 2011 9.0-CURRENT after the update of libdialog to version 20100428. 900031 February 7, 2011 9.0-CURRENT after the addition of pthread_getthreadid_np(3). 900032 February 8, 2011 9.0-CURRENT after the removal of the uio_yield prototype and symbol. 900033 February 18, 2011 9.0-CURRENT after the update of binutils to version 2.17.50. 900034 March 8, 2011 9.0-CURRENT after the struct sysvec (sv_schedtail) changes. 900035 March 29, 2011 9.0-CURRENT after the update of base gcc and libstdc++ to the last GPLv2 licensed revision. 900036 April 18, 2011 9.0-CURRENT after the removal of libobjc and Objective-C support from the base system. 900037 May 13, 2011 9.0-CURRENT after importing the libprocstat(3) library and fuser(1) utility to the base system. 900038 May 22, 2011 9.0-CURRENT after adding a lock flag argument to VFS_FHTOVP(9). 900039 June 28, 2011 9.0-CURRENT after importing pf from OpenBSD 4.5. 900040 July 19, 2011 Increase default MAXCPU for FreeBSD to 64 on amd64 and ia64 and to 128 for XLP (mips). 900041 August 13, 2011 9.0-CURRENT after the implementation of Capsicum capabilities; fget(9) gains a rights argument. 900042 August 28, 2011 Bump shared libraries' version numbers for libraries whose ABI has changed in preparation for 9.0. 900043 September 2, 2011 Add automatic detection of USB mass storage devices which do not support the no synchronize cache SCSI command. 900044 September 10, 2011 Re-factor auto-quirk. 9.0-RELEASE. 900045 January 2, 2012 9-CURRENT after MFC of true/false from 1000002. 900500 January 2, 2012 9.0-STABLE. 900501 January 6, 2012 9.0-STABLE after merging of addition of the posix_fadvise(2) system call. 900502 January 16, 2012 9.0-STABLE after merging gperf 3.0.3 900503 February 15, 2012 9.0-STABLE after introduction of the new extensible sysctl(3) interface NET_RT_IFLISTL to query address lists (rev 231768). 900504 March 3, 2012 9.0-STABLE after changes related to mounting of filesystem inside a jail (rev 232728). 900505 March 13, 2012 9.0-STABLE after introduction of new tcp(4) socket options: TCP_KEEPINIT, TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT (rev 232945). 900506 May 22, 2012 9.0-STABLE after introduction of the quick_exit function and related changes required for C++11 (rev 235786). 901000 August 5, 2012 9.1-RELEASE. 901500 August 6, 2012 9.1-STABLE after branching releng/9.1 (RELENG_9_1). 901501 November 11, 2012 9.1-STABLE after LIST_PREV() added to queue.h (rev 242893) and KBI change in USB serial devices (rev 240659). 901502 November 28, 2012 9.1-STABLE after USB serial jitter buffer requires rebuild of USB serial device modules. 901503 February 21, 2013 9.1-STABLE after USB moved to the driver structure requiring a rebuild of all USB modules. Also indicates the presence of nmtree. 901504 March 15, 2013 9.1-STABLE after install gained -l, -M, -N and related flags and cat gained the -l option. 901505 June 13, 2013 9.1-STABLE after fixes in ctfmerge boostrapping (rev 249243). + + 902001 + August 3, 2013 + releng/9.2 branched from + stable/9 + (rev 253912). + + + + 902501 + August 2, 2013 + 9.2-STABLE after creation of + releng/9.2 branch + (rev 253913). + + 1000000 September 26, 2011 10.0-CURRENT. 1000001 November 4, 2011 10-CURRENT after addition of the posix_fadvise(2) system call. 1000002 December 12, 2011 10-CURRENT after defining boolean true/false in sys/types.h, sizeof(bool) may have changed (rev 228444). 10-CURRENT after xlocale.h was introduced (rev 227753). 1000003 December 16, 2011 10-CURRENT after major changes to carp(4), changing size of struct in_aliasreq, struct in6_aliasreq (rev 228571) and straitening arguments check of SIOCAIFADDR (rev 228574). 1000004 January 1, 2012 10-CURRENT after the removal of skpc(9) and the addition of memcchr(9) (rev 229200). 1000005 January 16, 2012 10-CURRENT after the removal of support for SIOCSIFADDR, SIOCSIFNETMASK, SIOCSIFBRDADDR, SIOCSIFDSTADDR ioctls (rev 230207). 1000006 January 26, 2012 10-CURRENT after introduction of read capacity data asynchronous notification in the cam(4) layer (rev 230590). 1000007 February 5, 2012 10-CURRENT after introduction of new tcp(4) socket options: TCP_KEEPINIT, TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT (rev 231025). 1000008 February 11, 2012 10-CURRENT after introduction of the new extensible sysctl(3) interface NET_RT_IFLISTL to query address lists (rev 231505). 1000009 February 25, 2012 10-CURRENT after import of libarchive 3.0.3 (rev 232153). 1000010 March 31, 2012 10-CURRENT after xlocale cleanup (rev 233757). 1000011 April 16, 2012 10-CURRENT import of LLVM/Clang 3.1 trunk r154661 (rev 234353). 1000012 May 2, 2012 10-CURRENT jemalloc import (rev 234924). 1000013 May 22, 2012 10-CURRENT after byacc import (rev 235788). 1000014 June 27, 2012 10-CURRENT after BSD sort becoming the default sort (rev 237629). 1000015 July 12, 2012 10-CURRENT after import of OpenSSL 1.0.1c (rev 238405). (not changed) July 13, 2012 10-CURRENT after the fix for LLVM/Clang 3.1 regression (rev 238429). 1000016 August 8, 2012 10-CURRENT after KBI change in &man.ucom.4; (rev 239179). 1000017 August 8, 2012 10-CURRENT after adding streams feature to the USB stack (rev 239214). 1000018 September 8, 2012 10-CURRENT after major rewrite of &man.pf.4; (rev 240233). 1000019 October 6, 2012 10-CURRENT after &man.pfil.9; KBI/KPI changed to supply packets in net byte order to AF_INET filter hooks (rev 241245). 1000020 October 16, 2012 10-CURRENT after the network interface cloning KPI changed and struct if_clone becoming opaque (rev 241610). 1000021 October 22, 2012 10-CURRENT after removal of support for non-MPSAFE filesystems and addition of support for FUSEFS (rev 241519, 241897). 1000022 October 22, 2012 10-CURRENT after the entire IPv4 stack switched to network byte order for IP packet header storage (rev 241913). 1000023 November 5, 2012 10-CURRENT after jitter buffer in the common USB serial driver code, to temporarily store characters if the TTY buffer is full. Add flow stop and start signals when this happens (rev 242619). 1000024 November 5, 2012 10-CURRENT after clang was made the default compiler on i386 and amd64 (rev 242624). 1000025 November 17, 2012 10-CURRENT after the sin6_scope_id member variable in struct sockaddr_in6 was changed to being filled by the kernel before passing the structure to the userland via sysctl or routing socket. This means the KAME-specific embedded scope id in sin6_addr.s6_addr[2] is always cleared in userland application (rev 243443). 1000026 January 11, 2013 10-CURRENT after install gained the -N flag (rev 245313). May also be used to indicate the presence of nmtree. 1000027 January 29, 2013 10-CURRENT after cat gained the -l flag (rev 246083). 1000028 February 13, 2013 10-CURRENT after USB moved to the driver structure requiring a rebuild of all USB modules (rev 246759). 1000029 March 4, 2013 10-CURRENT after the introduction of tickless callout facility which also changed the layout of struct callout (rev 247777). 1000030 March 12, 2013 10-CURRENT after KPI breakage introduced in the VM subsystem to support read/write locking (rev 248084). 1000031 April 26, 2013 10-CURRENT after the dst parameter of the ifnet if_output method was changed to take const qualifier (rev 249925). 1000032 May 1, 2013 10-CURRENT after the introduction of the accept4 (rev 250154) and pipe2 (rev 250159) system calls. 1000033 May 21, 2013 10-CURRENT after flex 2.5.37 import (rev 250881). 1000034 June 3, 2013 10-CURRENT after the addition of the following functions to libm: cacos, cacosf, cacosh, cacoshf, casin, casinf, casinh, casinhf, catan, catanf, catanh, catanhf, logl, log2l, log10l, log1pl, expm1l (rev 251294). 1000035 June 8, 2013 10-CURRENT after the introduction of the aio_mlock system call (rev 251526). 1000036 July 9, 2013 10-CURRENT after the addition of a new function to the kernel GSSAPI module's function call interface (rev 253049).
Note that 2.2-STABLE sometimes identifies itself as 2.2.5-STABLE after the 2.2.5-RELEASE. The pattern used to be year followed by the month, but we decided to change it to a more straightforward major/minor system starting from 2.2. This is because the parallel development on several branches made it infeasible to classify the releases simply by their real release dates. If you are making a port now, you do not have to worry about old -CURRENTs; they are listed here just for your reference.
Writing Something After <filename>bsd.port.mk</filename> Do not write anything after the .include <bsd.port.mk> line. It usually can be avoided by including bsd.port.pre.mk somewhere in the middle of your Makefile and bsd.port.post.mk at the end. Include either the bsd.port.pre.mk/bsd.port.post.mk pair or bsd.port.mk only; do not mix these two usages. bsd.port.pre.mk only defines a few variables, which can be used in tests in the Makefile, bsd.port.post.mk defines the rest. Here are some important variables defined in bsd.port.pre.mk (this is not the complete list, please read bsd.port.mk for the complete list). Variable Description ARCH The architecture as returned by uname -m (e.g., i386) OPSYS The operating system type, as returned by uname -s (e.g., FreeBSD) OSREL The release version of the operating system (e.g., 2.1.5 or 2.2.7) OSVERSION The numeric version of the operating system; the same as __FreeBSD_version. LOCALBASE The base of the local tree (e.g., /usr/local) PREFIX Where the port installs itself (see more on PREFIX). - If you have to define the variables - USE_IMAKE or + If you have to define the variable MASTERDIR, do so before including bsd.port.pre.mk. Here are some examples of things you can write after bsd.port.pre.mk: # no need to compile lang/perl5 if perl5 is already in system .if ${OSVERSION} > 300003 BROKEN= perl is in system .endif You did remember to use tab instead of spaces after BROKEN= and :-). Use the <function>exec</function> Statement in Wrapper Scripts If the port installs a shell script whose purpose is to launch another program, and if launching that program is the last action performed by the script, make sure to launch the program using the exec statement, for instance: #!/bin/sh exec %%LOCALBASE%%/bin/java -jar %%DATADIR%%/foo.jar "$@" The exec statement replaces the shell process with the specified program. If exec is omitted, the shell process remains in memory while the program is executing, and needlessly consumes system resources. Do Things Rationally The Makefile should do things simply and reasonably. If you can make it a couple of lines shorter or more readable, then do so. Examples include using a make .if construct instead of a shell if construct, not redefining do-extract if you can redefine EXTRACT* instead, and using GNU_CONFIGURE instead of CONFIGURE_ARGS += --prefix=${PREFIX}. If you find yourself having to write a lot of new code to try to do something, please go back and review bsd.port.mk to see if it contains an existing implementation of what you are trying to do. While hard to read, there are a great many seemingly-hard problems for which bsd.port.mk already provides a shorthand solution. Respect Both <makevar>CC</makevar> and <makevar>CXX</makevar> The port must respect both CC and CXX variables. What we mean by this is that the port must not set the values of these variables absolutely, overriding existing values; instead, it may append whatever values it needs to the existing values. This is so that build options that affect all ports can be set globally. If the port does not respect these variables, please add NO_PACKAGE=ignores either cc or cxx to the Makefile. An example of a Makefile respecting both CC and CXX variables follows. Note the ?=: CC?= gcc CXX?= g++ Here is an example which respects neither CC nor CXX variables: CC= gcc CXX= g++ Both CC and CXX variables can be defined on FreeBSD systems in /etc/make.conf. The first example defines a value if it was not previously set in /etc/make.conf, preserving any system-wide definitions. The second example clobbers anything previously defined. Respect <makevar>CFLAGS</makevar> The port must respect the CFLAGS variable. What we mean by this is that the port must not set the value of this variable absolutely, overriding the existing value; instead, it may append whatever values it needs to the existing value. This is so that build options that affect all ports can be set globally. If it does not, please add NO_PACKAGE=ignores cflags to the Makefile. An example of a Makefile respecting the CFLAGS variable follows. Note the +=: CFLAGS+= -Wall -Werror Here is an example which does not respect the CFLAGS variable: CFLAGS= -Wall -Werror The CFLAGS variable is defined on FreeBSD systems in /etc/make.conf. The first example appends additional flags to the CFLAGS variable, preserving any system-wide definitions. The second example clobbers anything previously defined. You should remove optimization flags from the third party Makefiles. System CFLAGS contains system-wide optimization flags. An example from an unmodified Makefile: CFLAGS= -O3 -funroll-loops -DHAVE_SOUND Using system optimization flags, the Makefile would look similar to the following example: CFLAGS+= -DHAVE_SOUND Threading Libraries The threading library must be linked to the binaries using a special flag -pthread on &os;. If a port insists on linking -lpthread directly, patch it to use -pthread. If building the port errors out with unrecognized option '-pthread', it may be desirable to use cc as linker by setting CONFIGURE_ENV to LD=${CC}. The -pthread option is not supported by ld directly. Feedback Do send applicable changes/patches to the original author/maintainer for inclusion in next release of the code. This will only make your job that much easier for the next release. <filename>README.html</filename> Do not include the README.html file. This file is not part of the SVN collection but is generated using the make readme command. If make readme fails, make sure that the default value of ECHO_MSG has not been modified by the port. Marking a Port Not Installable with <makevar>BROKEN</makevar>, <makevar>FORBIDDEN</makevar>, or <makevar>IGNORE</makevar> In certain cases users should be prevented from installing a port. To tell a user that a port should not be installed, there are several make variables that can be used in a port's Makefile. The value of the following make variables will be the reason that is given back to users for why the port refuses to install itself. Please use the correct make variable as each make variable conveys radically different meanings to both users, and to automated systems that depend on the Makefiles, such as the ports build cluster, FreshPorts, and portsmon. Variables BROKEN is reserved for ports that currently do not compile, install, or deinstall correctly. It should be used for ports where the problem is believed to be temporary. If instructed, the build cluster will still attempt to try to build them to see if the underlying problem has been resolved. (However, in general, the cluster is run without this.) For instance, use BROKEN when a port: does not compile fails its configuration or installation process installs files outside of ${LOCALBASE} does not remove all its files cleanly upon deinstall (however, it may be acceptable, and desirable, for the port to leave user-modified files behind) FORBIDDEN is used for ports that contain a security vulnerability or induce grave concern regarding the security of a FreeBSD system with a given port installed (e.g., a reputably insecure program or a program that provides easily exploitable services). Ports should be marked as FORBIDDEN as soon as a particular piece of software has a vulnerability and there is no released upgrade. Ideally ports should be upgraded as soon as possible when a security vulnerability is discovered so as to reduce the number of vulnerable FreeBSD hosts (we like being known for being secure), however sometimes there is a noticeable time gap between disclosure of a vulnerability and an updated release of the vulnerable software. Do not mark a port FORBIDDEN for any reason other than security. IGNORE is reserved for ports that should not be built for some other reason. It should be used for ports where the problem is believed to be structural. The build cluster will not, under any circumstances, build ports marked as IGNORE. For instance, use IGNORE when a port: compiles but does not run properly does not work on the installed version of &os; requires &os; kernel sources to build, but the user does not have them installed has a distfile which may not be automatically fetched due to licensing restrictions does not work with some other currently installed port (for instance, the port depends on www/apache20 but www/apache22 is installed) If a port would conflict with a currently installed port (for example, if they install a file in the same place that performs a different function), use CONFLICTS instead. CONFLICTS will set IGNORE by itself. If a port should be marked IGNORE only on certain architectures, there are two other convenience variables that will automatically set IGNORE for you: ONLY_FOR_ARCHS and NOT_FOR_ARCHS. Examples: ONLY_FOR_ARCHS= i386 amd64 NOT_FOR_ARCHS= ia64 sparc64 A custom IGNORE message can be set using ONLY_FOR_ARCHS_REASON and NOT_FOR_ARCHS_REASON. Per architecture entries are possible with ONLY_FOR_ARCHS_REASON_ARCH and NOT_FOR_ARCHS_REASON_ARCH. If a port fetches i386 binaries and installs them, IA32_BINARY_PORT should be set. If this variable is set, it will be checked whether the /usr/lib32 directory is available for IA32 versions of libraries and whether the kernel has IA32 compatibility compiled in. If one of these two dependencies is not satisfied, IGNORE will be set automatically. Implementation Notes The strings should not be quoted. Also, the wording of the string should be somewhat different due to the way the information is shown to the user. Examples: BROKEN= this port is unsupported on FreeBSD 5.x IGNORE= is unsupported on FreeBSD 5.x resulting in the following output from make describe: ===> foobar-0.1 is marked as broken: this port is unsupported on FreeBSD 5.x. ===> foobar-0.1 is unsupported on FreeBSD 5.x. Marking a Port for Removal with <makevar>DEPRECATED</makevar> or <makevar>EXPIRATION_DATE</makevar> Do remember that BROKEN and FORBIDDEN are to be used as a temporary resort if a port is not working. Permanently broken ports should be removed from the tree entirely. When it makes sense to do so, users can be warned about a pending port removal with DEPRECATED and EXPIRATION_DATE. The former is simply a string stating why the port is scheduled for removal; the latter is a string in ISO 8601 format (YYYY-MM-DD). Both will be shown to the user. It is possible to set DEPRECATED without an EXPIRATION_DATE (for instance, recommending a newer version of the port), but the converse does not make any sense. There is no set policy on how much notice to give. Current practice seems to be one month for security-related issues and two months for build issues. This also gives any interested committers a little time to fix the problems. Avoid Use of the <literal>.error</literal> Construct The correct way for a Makefile to signal that the port can not be installed due to some external factor (for instance, the user has specified an illegal combination of build options) is to set a non-blank value to IGNORE. This value will be formatted and shown to the user by make install. It is a common mistake to use .error for this purpose. The problem with this is that many automated tools that work with the ports tree will fail in this situation. The most common occurrence of this is seen when trying to build /usr/ports/INDEX (see ). However, even more trivial commands such as make maintainer also fail in this scenario. This is not acceptable. How to Avoid Using <literal>.error</literal> Assume that someone has the line USE_POINTYHAT=yes in make.conf. The first of the next two Makefile snippets will cause make index to fail, while the second one will not: .if USE_POINTYHAT .error "POINTYHAT is not supported" .endif .if USE_POINTYHAT IGNORE= POINTYHAT is not supported .endif Usage of <filename>sysctl</filename> The usage of sysctl is discouraged except in targets. This is because the evaluation of any makevars, such as used during make index, then has to run the command, further slowing down that process. Usage of &man.sysctl.8; should always be done with the SYSCTL variable, as it contains the fully qualified path and can be overridden, if one has such a special need. Rerolling Distfiles Sometimes the authors of software change the content of released distfiles without changing the file's name. You have to verify that the changes are official and have been performed by the author. It has happened in the past that the distfile was silently altered on the download servers with the intent to cause harm or compromise end user security. Put the old distfile aside, download the new one, unpack them and compare the content with &man.diff.1;. If you see nothing suspicious, you can update distinfo. Be sure to summarize the differences in your PR or commit log, so that other people know that you have taken care to ensure that nothing bad has happened. You might also want to contact the authors of the software and confirm the changes with them. Avoiding Linuxisms Do not use /proc if there are any other ways of getting the information, e.g., setprogname(argv[0]) in main() and then &man.getprogname.3; if you want to know your name. Do not rely on behaviour that is undocumented by POSIX. Do not record timestamps in the critical path of the application if it also works without. Getting timestamps may be slow, depending on the accuracy of timestamps in the OS. If timestamps are really needed, determine how precise they have to be and use an API which is documented to just deliver the needed precision. A number of simple syscalls (for example &man.gettimeofday.2;, &man.getpid.2;) are much faster on &linux; than on any other operating system due to caching and the vsyscall performance optimizations. Do not rely on them being cheap in performance-critical applications. In general, try hard to avoid syscalls if possible. Do not rely on &linux;-specific socket behaviour. In particular, default socket buffer sizes are different (call &man.setsockopt.2; with SO_SNDBUF and SO_RCVBUF, and while &linux;'s &man.send.2; blocks when the socket buffer is full, &os;'s will fail and set ENOBUFS in errno. If relying on non-standard behaviour is required, encapsulate it properly into a generic API, do a check for the behaviour in the configure stage, and stop if it is missing. Check the man pages to see if the function used is a POSIX interface (in the STANDARDS section of the man page). Do not assume that /bin/sh is bash. Ensure that a command line passed to &man.system.3; will work with a POSIX compliant shell. A list of common bashisms is available here. Do not #include <stdint.h> if inttypes.h is sufficient. This will ensure that the software builds on older versions of &os;. Check that headers are included in the POSIX or man page recommended way, e.g., sys/types.h is often forgotten, which is not as much of a problem for &linux; as it is for &os;. Compile threaded applications with -pthread, not -lpthread or variations thereof. Miscellanea The files pkg-descr and pkg-plist should each be double-checked. If you are reviewing a port and feel they can be worded better, do so. Do not copy more copies of the GNU General Public License into our system, please. Please be careful to note any legal issues! Do not let us illegally distribute software!
A Sample <filename>Makefile</filename> Here is a sample Makefile that you can use to create a new port. Make sure you remove all the extra comments (ones between brackets)! It is recommended that you follow this format (ordering of variables, empty lines between sections, etc.). This format is designed so that the most important information is easy to locate. We recommend that you use portlint to check the Makefile. [the header...just to make it easier for us to identify the ports.] # Created by: Satoshi Asami <asami@FreeBSD.org> [The optional Created by: line names the person who originally created the port. Note that the : is followed by a space and not a tab character. If this line is present, future maintainers should not change or remove it except at the original author's request.] # $FreeBSD$ [ ^^^^^^^^^ This will be automatically replaced with RCS ID string by SVN when it is committed to our repository. If upgrading a port, do not alter this line back to "$FreeBSD$". SVN deals with it automatically.] [section to describe the port itself and the master site - PORTNAME and PORTVERSION are always first, followed by CATEGORIES, and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR. PKGNAMEPREFIX and PKGNAMESUFFIX, if needed, will be after that. Then comes DISTNAME, EXTRACT_SUFX and/or DISTFILES, and then EXTRACT_ONLY, as necessary.] PORTNAME= xdvi PORTVERSION= 18.2 CATEGORIES= print [do not forget the trailing slash ("/")! if you are not using MASTER_SITE_* macros] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications PKGNAMEPREFIX= ja- DISTNAME= xdvi-pl18 [set this if the source is not in the standard ".tar.gz" form] EXTRACT_SUFX= .tar.Z [section for distributed patches -- can be empty] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [maintainer; *mandatory*! This is the person who is volunteering to handle port updates, build breakages, and to whom a users can direct questions and bug reports. To keep the quality of the Ports Collection as high as possible, we no longer accept new ports that are assigned to "ports@FreeBSD.org".] MAINTAINER= asami@FreeBSD.org COMMENT= A DVI Previewer for the X Window System [dependencies -- can be empty] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm:${PORTSDIR}/graphics/xpm [this section is for other standard bsd.port.mk variables that do not belong to any of the above] [If it asks questions during configure, build, install...] IS_INTERACTIVE= yes [If it extracts to a directory other than ${DISTNAME}...] WRKSRC= ${WRKDIR}/xdvi-new [If the distributed patches were not made relative to ${WRKSRC}, you may need to tweak this] PATCH_DIST_STRIP= -p1 [If it requires a "configure" script generated by GNU autoconf to be run] GNU_CONFIGURE= yes [If it requires GNU make, not /usr/bin/make, to build...] -USE_GMAKE= yes +USES= gmake [If it is an X application and requires "xmkmf -a" to be run...] -USE_IMAKE= yes +USES= imake [et cetera.] [non-standard variables to be used in the rules below] MY_FAVORITE_RESPONSE= "yeah, right" [then the special rules, in the order they are called] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [and then the epilogue] .include <bsd.port.mk> Keeping Up The &os; Ports Collection is constantly changing. Here is some information on how to keep up. FreshPorts One of the easiest ways to learn about updates that have already been committed is by subscribing to FreshPorts. You can select multiple ports to monitor. Maintainers are strongly encouraged to subscribe, because they will receive notification of not only their own changes, but also any changes that any other &os; committer has made. (These are often necessary to keep up with changes in the underlying ports framework—although it would be most polite to receive an advance heads-up from those committing such changes, sometimes this is overlooked or just simply impractical. Also, in some cases, the changes are very minor in nature. We expect everyone to use their best judgement in these cases.) If you wish to use FreshPorts, all you need is an account. If your registered email address is @FreeBSD.org, you will see the opt-in link on the right hand side of the webpages. For those of you who already have a FreshPorts account, but are not using your @FreeBSD.org email address, just change your email to @FreeBSD.org, subscribe, then change it back again. FreshPorts also has a sanity test feature which automatically tests each commit to the FreeBSD ports tree. If subscribed to this service, you will be notified of any errors which FreshPorts detects during sanity testing of your commits. The Web Interface to the Source Repository It is possible to browse the files in the source repository by using a web interface. Changes that affect the entire port system are now documented in the CHANGES file. Changes that affect individual ports are now documented in the UPDATING file. However, the definitive answer to any question is undoubtedly to read the source code of bsd.port.mk, and associated files. The &os; Ports Mailing List If you maintain ports, you should consider following the &a.ports;. Important changes to the way ports work will be announced there, and then committed to CHANGES. If this mailing list is too high volume you may consider following &a.ports-announce; which is moderated and has no discussion. The &os; Port Building Cluster on <hostid role="hostname">pointyhat.FreeBSD.org</hostid> One of the least-publicized strengths of &os; is that an entire cluster of machines is dedicated to continually building the Ports Collection, for each of the major OS releases and for each Tier-1 architecture. You can find the results of these builds at package building logs and errors. Individual ports are built unless they are specifically marked with IGNORE. Ports that are marked with BROKEN will still be attempted, to see if the underlying problem has been resolved. (This is done by passing TRYBROKEN to the port's Makefile.) Portscout: the &os; Ports Distfile Scanner The build cluster is dedicated to building the latest release of each port with distfiles that have already been fetched. However, as the Internet continually changes, distfiles can quickly go missing. Portscout, the &os; Ports distfile scanner, attempts to query every download site for every port to find out if each distfile is still available. Portscout can generate HTML reports and send emails about newly available ports to those who request them. Unless not otherwise subscribed, maintainers are asked to check periodically for changes, either by hand or using the RSS feed. Portscout's first page gives the email address of the port maintainer, the number of ports the maintainer is responsible for, the number of those ports with new distfiles, and the percentage of those ports that are out-of-date. The search function allows for searching by email address for a specific maintainer, and for selecting whether or not only out-of-date ports should be shown. Upon clicking on a maintainer's email address, a list of all of their ports is displayed, along with port category, current version number, whether or not there is a new version, when the port was last updated, and finally when it was last checked. A search function on this page allows the user to search for a specific port. Clicking on a port name in the list displays the FreshPorts port information. The &os; Ports Monitoring System Another handy resource is the FreeBSD Ports Monitoring System (also known as portsmon). This system comprises a database that processes information from several sources and allows it to be browsed via a web interface. Currently, the ports Problem Reports (PRs), the error logs from the build cluster, and individual files from the ports collection are used. In the future, this will be expanded to include the distfile survey, as well as other sources. To get started, you can view all information about a particular port by using the Overview of One Port. As of this writing, this is the only resource available that maps GNATS PR entries to portnames. (PR submitters do not always include the portname in their Synopsis, although we would prefer that they did.) So, portsmon is a good place to start if you want to find out whether an existing port has any PRs filed against it and/or any build errors; or, to find out if a new port that you may be thinking about creating has already been submitted. Appendices Values of <makevar>USES</makevar> Values of <makevar>USES</makevar> Feature Arguments Description &values.uses;
diff --git a/en_US.ISO8859-1/books/porters-handbook/uses.xml b/en_US.ISO8859-1/books/porters-handbook/uses.xml index d57292fce5..4aba6255b0 100644 --- a/en_US.ISO8859-1/books/porters-handbook/uses.xml +++ b/en_US.ISO8859-1/books/porters-handbook/uses.xml @@ -1,203 +1,219 @@ ada (none) Depends on an Ada-capable compiler, and sets CC accordingly. bison (none), build, run, both Implies that the port uses devel/bison in one way or another. By default, with no arguments or with the build argument, it implies bison as a build-time dependency, run implies a run-time dependency, and both implies both run-time and build-time dependencies. charsetfix (none) Prevents the port from installing charset.alias. This should be installed only by converters/libiconv. CHARSETFIX_MAKEFILEIN can be set to a path relative to WRKSRC if charset.alias is not installed by WRKSRC/Makefile.in. cmake (none), outsource The port will use CMake for configuring and building. With the outsource argument, an out-of-source build will be performed. For more information see . desktop-file-utils (none) Implies that the port uses the update-desktop-database from devel/desktop-file-utils. An extra post-install step will be run without interfering with any post-install steps already in the port Makefile. Lines will be inserted into the plist to run update-desktop-database on package install or removal. fuse (none) Implies the port will depend on the FUSE library and handle the dependency on the kernel module depending on the version of &os;. gettext (none), lib, build, run Implies that the port uses devel/gettext in one way or another. By default, with no arguments or with the lib argument, implies gettext with build-time and run-time dependencies, build implies a build-time dependency, and run implies a run-time dependency. + + gmake + (none) + Implies that the port uses devel/gmake as build-time + dependency. + + iconv (none) Implies that the port uses converters/libiconv as build-time and run-time dependency. + + imake + (none) + Implies that the port uses devel/imake as build-time + dependency. + + ncurses (none), base, port Implies that the port uses ncurses, and causes some useful variables to be set. pathfix (none) Look for the Makefile.in and configure files in the port's associated sources and fix common paths to make sure they respect the &os; hierarchy. pkgconfig (none), build, run, both Implies that the port uses devel/pkgconf in one way or another. With no arguments or with the build argument, it implies pkg-config as a build-time dependency; run implies a run-time dependency; and both implies both run-time and build-time dependencies. qmail (none), build, run, both, vars Implies that the port uses mail/qmail in one way or another. With the build argument, it implies qmail as a build-time dependency. run implies a run-time dependency. Using no argument or the both argument implies both run-time and build-time dependencies. vars will only set QMAIL variables for the port to use. readline (none), port Implies that the port uses readline as library dependency, and sets CPPFLAGS and LDFLAGS as necessary. shared-mime-info (none) Implies that the port uses update-mime-database from misc/shared-mime-info. This uses will automatically add a post-install step in such a way that the port itself still can specify there own post-install step if needed. It also insert lines into the plist for package install and removal to run update-mime-data with the correct arguments. shebangfix (none) A lot of software uses incorrect locations for script interpreters, most notably /usr/bin/perl and /bin/bash. This fixes shebang lines in scripts listed in SHEBANG_FILES. Currently Perl, Python, Bash, Ruby, and PHP are supported by default. To support another interpreter, set SHEBANG_LANG (for example SHEBANG_LANG=lua), then lua_OLD_CMD and lua_CMD. zenoss (none) Implies the port uses net-mgmt/zenoss in one way or another, but largely is used for building zenoss related zenpack ports. diff --git a/en_US.ISO8859-1/htdocs/administration.xml b/en_US.ISO8859-1/htdocs/administration.xml index fec8808939..a41ca6f169 100644 --- a/en_US.ISO8859-1/htdocs/administration.xml +++ b/en_US.ISO8859-1/htdocs/administration.xml @@ -1,489 +1,489 @@ ]> &title; $FreeBSD$

Introduction

This page lists teams, groups and individuals within the FreeBSD project with designated project roles and areas of responsibility, along with brief descriptions and contact information.


FreeBSD Core Team <core@FreeBSD.org>

The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. The Core Team is elected by the active developers in the project.

FreeBSD Documentation Engineering Team <doceng@FreeBSD.org>

The FreeBSD Documentation Engineering Team is responsible for defining and following up documentation goals for the committers in the Documentation project. The doceng team charter describes the duties and responsibilities of the Documentation Engineering Team in greater detail.

FreeBSD Port Management Team <portmgr@FreeBSD.org>

The primary responsibility of the FreeBSD Port Management Team is to ensure that the FreeBSD Ports Developer community provides a ports collection that is functional, stable, up-to-date and full-featured. Its secondary responsibility is to coordinate among the committers and developers who work on it. The portmgr team charter describes the duties and responsibilities of the Port Management Team in greater detail.


Primary Release Engineering Team <re@FreeBSD.org>

The Primary Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining releng/* branches, among other things. The release engineering team charter describes the duties and responsibilities of the Primary Release Engineering Team in greater detail.

Builders Release Engineering Team <re-builders@FreeBSD.org>

The builders release engineering team is responsible for building and packaging FreeBSD releases on the various supported platforms.


Donations Team <donations@FreeBSD.org>

The FreeBSD Donations Team is responsible for responding to donations offers, establishing donation guidelines and procedures, and coordinating donation offers with the FreeBSD developer community. A more detailed description of the duties of the Donations Team is available on the FreeBSD Donations Liaison page.

Marketing Team <marketing@FreeBSD.org>

Press contact, marketing, interviews, information.

Security Team <secteam@FreeBSD.org>

The FreeBSD Security Team (headed by the Security Officer) is responsible for keeping the community aware of bugs, exploits and security risks affecting the FreeBSD src and ports trees, and to promote and distribute information needed to safely run FreeBSD systems. Furthermore, it is responsible for resolving software bugs affecting the security of FreeBSD and issuing security advisories. The FreeBSD Security Officer Charter describes the duties and responsibilities of the Security Officer in greater detail.

Vendor Relations <vendor-relations@FreeBSD.org>

Vendor Relations is responsible for handling email from hardware and software vendors. Email sent to Vendor Relations is forwarded to the &os; Core Team in addition to the &os; Foundation.


Core Team Secretary <core-secretary@FreeBSD.org>

The FreeBSD Core Team Secretary is a non-voting member of the Core Team, responsible for documenting the work done by core, keeping track of the core agenda, direct contact with non-core members sending mail to core and to be an the interface to the admin team for committer/account approval. The Core Team Secretary is also responsible for writing and sending out monthly status reports to the FreeBSD Developer community, containing a summary of core's latest decisions and actions.

Port Management Team Secretary <portmgr-secretary@FreeBSD.org>

The FreeBSD Port Management Team Secretary is a non-voting member of the Port Management Team, responsible for documenting the work done by portmgr, keeping track of voting procedures, and to be an interface to the other teams, especially the admin and Core teams. The Port Management Team Secretary is also responsible for writing and sending out monthly status reports to the FreeBSD Developer community, containing a summary of portmgr's latest decisions and actions.

Security Team Secretary <secteam-secretary@FreeBSD.org>

The FreeBSD Security Team Secretary will make sure someone responds to incoming emails towards the Security Team. He will acknowledge receipt and keep track of the progress within the Security Team. If needed the Secretary will contact members of the Security Team to let them provide an update on ongoing items. Currently the Security Team Secretary does not handle Security Officer Team items.


Accounts Team <accounts@>

The Accounts Team is responsible for setting up accounts for new committers in the project. Requests for new accounts will not be acted upon without the proper approval from the appropriate entity.

Backups Administrators <backups@>

The Backups Administrators handle all backups on the FreeBSD cluster.

Bugmeisters & GNATS Administrators <bugmeister@FreeBSD.org>

The Bugmeisters and GNATS Administrators are responsible for ensuring that the maintenance database is in working order, that the entries are correctly categorised and that there are no invalid entries. They are also responsible for the problem report group.

Cluster Administrators <admins@>

The Cluster Administrators consists of the people responsible for administrating the machines that the project relies on for its distributed work and communication to be synchronised. It consists mainly of those people who have physical access to the servers. Issues concerning the projects infrastructure or setting up new machines should be directed to the cluster administrators. This team is led by the lead cluster administrator whose duties and responsbilities are described in the cluster administration charter in greater detail.

CVSup Mirror Site Coordinators <cvsup-master@FreeBSD.org>

The CVSup Mirror Site Coordinators coordinates all the CVSup mirror site adminstrators to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest CVSup mirror.

DNS Administrators <dnsadm@>

The DNS Administrators are responsible for managing DNS and related services.

FTP/WWW Mirror Site Coordinators <mirror-admin@FreeBSD.org>

The FTP/WWW Mirror Site Coordinators coordinate all the FTP/WWW mirror site adminstrators to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest FTP/WWW mirror.

Perforce Repository Administrators <perforce-admin@FreeBSD.org>

The Perforce Repository Administrators are responsible for administrating the FreeBSD perforce source repository and setting up new perforce accounts. All requests concerning new perforce accounts for non-committers should be directed to the perforce administrators.

Postmaster Team <postmaster@FreeBSD.org>

The Postmaster Team is responsible for mail being correctly delivered to the committers' email address, ensuring that the mailing lists work, and should take measures against possible disruptions of project mail services, such as having troll-, spam- and virus-filters.

Subversion Administrators <svnadm@>

The FreeBSD Subversion team is responsible for maintaining the health of the Subversion Repositories.

Webmaster Team <webmaster@FreeBSD.org>

The FreeBSD Webmaster Team is responsible for keeping the main FreeBSD web sites up and running. This means web server configuration, CGI scripts, fulltext and mailing list search. Anything web related, technical stuff belongs to the scope of the Webmaster Team, excluding bugs in the documentation.

diff --git a/en_US.ISO8859-1/htdocs/community/mailinglists.xml b/en_US.ISO8859-1/htdocs/community/mailinglists.xml index 2d7b581ee6..899cfa7d48 100644 --- a/en_US.ISO8859-1/htdocs/community/mailinglists.xml +++ b/en_US.ISO8859-1/htdocs/community/mailinglists.xml @@ -1,127 +1,127 @@ ]> &title; $FreeBSD$

Mailing lists are the primary communication channels for the FreeBSD community, and cover many topic areas.

Mailing list archives

You can search or browse the mailing list archives at www.FreeBSD.org. It is also possible to browse the mailing lists via the Mailman Web interface.

English Mailing lists

The English speaking mailing lists are listed in the FreeBSD Handbook.

Non-English Mailing lists

Several non-English mailing lists are also available:

If you create other FreeBSD mailing lists, let us know about them.

diff --git a/en_US.ISO8859-1/htdocs/donations/donors.xml b/en_US.ISO8859-1/htdocs/donations/donors.xml index 2a8845353f..544eea81de 100644 --- a/en_US.ISO8859-1/htdocs/donations/donors.xml +++ b/en_US.ISO8859-1/htdocs/donations/donors.xml @@ -1,2932 +1,2948 @@ ]> &title; $FreeBSD$

This page keeps a record of current hardware transactions taking place under the donations team. These are only completed or believed to be completed transactions. If something was offered but never shipped to anyone, please do not list it here. If you see any mistakes, please send an email to trhodes@FreeBSD.org so that I may correct it. Feel free to cc: donations@FreeBSD.org as well.

+ + + + + + + + + + + + + +
FROM ITEM TO STATUS
nsayer 4-port Zynx 'dc' NIC jlemon Unknown
Sebastian Trahm <inthisdefiance@gmx.net> Packet Engines G-NICII 1000SX/PCI will Received
donxc <donald.creel@verizon.net> ATI Rage Pro 128 anholt Shipped
Stephen Hoover <shoover@442spot.com> Pentium III 1GHz 133FSB, 512MB PC133 RAM, Asus TUSL2-C motherboard (815EP chipset), Intel 82559 (PILA8460B) 10/100 NIC, 52X CD-ROM, floppy, case w/250W power supply w/case fan kris Received
Salvatore Denaro <sdenaro@speakeasy.net> 512MB DDR ECC DIMM obrien Received
Frank Nikolajsen <frank@warpspace.com> Three 533MHz 21164A CPU PC164SX (AlphaPC) motherboards Ports Cluster (obrien/peter) Received
William Gnadt <wgnadt@rri-usa.org> PCMCIA CD-ROM drive (Addonics), USB 1.1 HD enclosure w/850MB HD imp, bsd CD-ROM shipped to imp, HD enclosure shipped to bsd
William Gnadt <wgnadt@rri-usa.org> Seagate Cheetah 10K RPM 9GB UW-SCSI HD Model: ST19101W / 68-pin connector, new dual-fan HD cooler dannyboy Received
William Gnadt <wgnadt@goliath.rri-usa.org> Dell Inspiron 3000 laptop (Pentium 266MHz, 64MB RAM, floppy and CD-ROM drives, docking station, PCMCIA Ethernet/modem card, extra power supply -- good condition imp Received
William Gnadt <wgnadt@goliath.rri-usa.org> PCMCIA cards: "New Media" 28.8 modem (unknown model #), Linksys 33.6 LANmodem (model PCMLM36), Linksys combo ethernet card (model EC2T), 3COM 3C905B Ethernet 10/100B-T network adapter (PCI) PCMCIA cards to imp, 3COM nic to silby PCMCIA cards shipped. 3COM nic shipped.
William Gnadt <wgnadt@goliath.rri-usa.org> 2.5" laptop HDs: Toshiba HDD2714 - 1443MB Toshiba HDD2731 - 1083MB darrenr Awaiting Shipment
William Gnadt <wgnadt@goliath.rri-usa.org> 68-pin M-M SCSI cable 1 meter (brand new) mwlucas Received
Simon Chang <schang@quantumslipstream.net> Dual Pentium Pro 200MHz (both CPUs and VRMs included), 128 MB of RAM 10-GB IDE hard disk drive, IDE CD-ROM drive, one old 3Com 3C509B-TPO network card will Received
gj pc164 (Alpha) sos Received
Michael Hembo <hembo@micron.dk> 4 * 512 MB PC133 SIMM (for ftp.FreeBSD.org) jesper Received
trhodes 40GB IDE HDD rwatson Received
jesper on behalf of TDC Tele Danmark AlphaStation 255/233 sos Received
<Aaron.Schroeder@qg.com> 384MB RAM for an AlphaStation 500 wilko Received
DEC/Compaq AS2100 SMP trevor Received
wilko, on behalf of Compaq DS10 murray, obrien, package cluster Received
wilko, on behalf of HP AlphaServer 1000A markm Received
Rolf Huisman Abit BP6 dual CPU mainboard wilko Received
Stefan Molnar <stefan@csudsu.com> Sun X6540A dual-channel Symbios 53C876 SCSI card (w/FCode) jake Received
obrien Hitachi ATAPI CDR-7730 cdrom drive sos Received
obrien DEC Alpha PWS 2MB B-cache module gallatin Received
obrien fxp(4), xl(4), pcn(4), dc(4) NIC's; Adaptec AHA-2940UW; Sun HD/68-pin UW-SCSI cable jake Received
obrien KVM Switch kris Received
obrien several AMD Athlon Slot-A 8[05]0 MHz CPUs gshapiro,gj,fjoe,wilko,mdodd all received
obrien AMD Athlon Slot-A 800 MHz CPU + Gigabyte GA-7IXE motherboard + 256 MB RAM kris Received
obrien 2x550 MHz Pentium-III system with 256MB RAM, CDROM, multiple NIC's scottl Received
obrien nVidia GeForce2 Pro, GeForce 256, Riva TNT2, Riva TNT AGP video cards. nVidia GeForce2 MX400, MX200, TNT2 PCI video cards. mdodd Received
obrien two Sun SPARCengine AXi "Panther" 300MHz UltraSparc-IIi with 256MB RAM, 9GB SCSI UW disk FreeBSD.org cluster, and scottl Received
obrien Sun Ultra-1 with 128MB RAM, CDROM, 2GB SCA disk scottl Received
obrien two fxp(4), one pcn(4) Ethernet cards rwatson Received
obrien AMD Slot-A 900 MHz CPU + Gigabyte GA-7IXE motherboard + 128MB RAM + 10 GB and 8 GB IDE disks + 3Com 905c-TX + nVidia GeForce2 GTS 64MB AGP video card jake Received
obrien Matrox G400 AGP dual-head, 2x Celeron 366 MHz socket-370 CPUs, Athlon 900 Slot-A CPU, PC100 DIMMs wilko Received
obrien Adaptec 3940UW njl Received
obrien two Aureal Vortex 2 sound card des and petef Received
obrien pair of AMD Opteron 246 CPUs kan Received
obrien pair of AMD Opteron 244 CPUs phk Received
obrien AMD Opteron 244 CPU sos Received
obrien AMD Athlon64 desktop: 3400+ CPU, 512MB RAM, IDE hard disk, 3Com 3c905c NIC, DVD-ROM drive, nVidia AGP video, floppy, case, power supply kris Received
obrien AMD Athlon64 desktop: 3200+ CPU, 512MB DDR333 RAM, two 60GB IDE hard disks, 3Com 3c996b gigE NIC, 3Com 3c905c NIC, DVD-ROM drive, nVidia GeForce2 GTS AGP video, floppy, case, power supply bde (shipped thru peter) Received
obrien AMD Athlon XP 2800+ Barton CPU bde (shipped thru peter) Received
obrien six 9GB SCSI LVD disks (2 SCA, 4 68-pin) scottl Received
obrien DEC Alpha 164SX motherboard, PC164SX 533 MHz CPU, 128MB ECC PC100 RAM, Adaptec AHA-2940UW SCSI controller, Matrox PCI video card ru Received (handcarried to .nl by marks, shipped to ru by wilko)
obrien AMD Opteron 850 CPU, 2 x AMD Opteron 254 CPU ru Received
obrien pair of AMD Athlon-MP 2400+ CPUs, Tyan K7 Thunder motherboard, power supply, 1MB DDR266 DIMM imp Received
obrien AMD Athlon64 3000+ CPU murray Received
obrien AMD Athlon64 3200+ CPU davidxu Received
obrien MSI AMD Athlon Slot-A motherboard, ATX form factor trhodes Received
obrien AMD Opteron 150 CPU, ASUS SK8N motherboard, 2GB RAM, DVD-ROM krion Received
obrien Pair of AMD Opteron 850 CPUs alc Received
gordont Sun Ultra-2 SMP 400 MHz with 1GB RAM, 2x 4GB SCA disks jake Received
gordont Sun Ultra-2 200 MHz with 512MB RAM, 2GB SCA disk obrien Received
Nick Jeffrey <nick@jeffrey.com> 2x 9GB SCA SCSI disks jake Received
kan Matrox Millennium II PCI video card nsouch Received
wilko Winbond ISDN card hm Received
wilko 21264/550 EV6 Alpha CPU obrien Received
wilko Athlon 850 Slot-A, 64MB DIMM fjoe Received
NcFTP Software / Mike Gleason <mgleason@ncftp.com> NcFTPd Server site license for FreeBSD.org jesper Received
Michael Dexter Yamaha SCSI CDRW drive wilko Received
wilko Cologne Chip Design PCI ISDN card and Compaq ISA ISDN card hm Received
William Gnadt <wgnadt@rri-usa.org> IBM Travelstar DJSA-210 Laptop Hard Drive, 10.06GB jesper Received
mbr 10 Gigabyte Hard Disk Drive sos Awaiting Shipment
The Open Group Single &unix; Specification (Version 3) books and CD-ROMs. mike (and -standards) Received
William Gnadt <wgnadt@rri-usa.org> SoundBlaster 128 PCI mike Received
Matt Douhan <mdouhan@fruitsalad.org> Two Sony AIT-1 tape drives will Received
William Gnadt <wgnadt@rri-usa.org> Toshiba MK6411MAT, 6495MB des Received
wilko, on behalf of HP AlphaServer 1000A phk Received
brueffer SMC Etherpower II (tx) NIC mux Received
Mike Tancsa, Sentex 2 remote machines:
releng4.sentex.ca: Intel Celeron CPU 2.00GHz (2000.35-MHz 686-class CPU) real memory = 528416768 (516032K bytes), 19595MB QUANTUM FIREBALLP LM20.5 UDMA66
releng5.sentex.ca: Intel Pentium III/Pentium III Xeon/Celeron (866.38-MHz 686-class CPU) real memory = 796852224 (759 MB), 19595MB QUANTUM FIREBALLP LM20.5 UDMA66
FreeBSD Security Team (nectar) In use
Mike Tancsa <mike@sentex.net> IBM smart cards (PCMCIA and serial port) des Received
fenner AST FourPort/XN ISA serial card jwd Received
Ryan Petersen <rpetersen@4imprint.com> Sun Microsystems Sparc Ultra 5 FreeBSD.org cluster Received
Chris Knight <chris@e-easy.com.au> 56K PCMCIA Data/Fax modem trhodes Received
wes Dual processor motherboard for Intel Celerons des Received
Craig Rodrigues <rodrigc@attbi.com> ATI Graphics Xpression PCI 2 MB nsouch Received
Gregory P. Smith <greg@electricrain.com> DEC Alpha PC164SX mobo+CPU, 2x 64MB ECC DIMM's, UW SCSI controller, 10/100 NIC wilko Received
gallatin Alpha 433au system will Received
Brian Cunnie <brian@cunnie.com> DDS-3 scsi tape drive (12GB raw/24GB compr), SCSI terminator, SCSI cable (50-pin hi-density single-ended), and several DDS-3 tapes. kris Received
unfurl Dual Pentium 550MHz system rwatson Received
James Pace <jepace@pobox.com> HP Omnibook 4000 ct 4/100, and an HP Omnibook 5000 cts 5/90 model 1200 imp Received
murray Hard copy of Docbook: The Definite Guide ceri Received
Christoph Franke <Franke.Christoph@gmx.de> 1.5GB SyJet gj Received
Christoph Franke <Franke.Christoph@gmx.de> IBM DDRS-39130 SCSI LVD/SE Harddisk des Received
Christoph Franke <Franke.Christoph@gmx.de> IBM DDRS-34560 SCSI SE Harddisk, Plextor PX-20TSi SCSI CDROM Drive ru Received
Christoph Franke <Franke.Christoph@gmx.de> IOMEGA Zip Drive SCSI 100 MB (incl. 2 Medias) phk Shipped
ETEK, Chalmers Compaq XP1000: DECchip 21264A-9 667MHz, 640MB RAM obrien Received
ceri A well-supported 4 serial port PCI card wilko Received
Mike Ray MIPS R4000 Microprocessor User's Manual jmallett Received
wilko 3 FC disks phk Received
wilko, on behalf of HP AlphaServer 4100 ticso Received
wilko, on behalf of HP AlphaStation 200 ceri Received
Brian Cunnie <brian@cunnie.com> 40+gb IDE drive eric Received
Jared_Valentine@3com.com crypto devices (pci, pcmcia, cardbus cards, CPUs with builtin crypto+support, 3Com 3CR990, 3CRFW102/103 PC Cards w/ 3DES sam Shipped?
Jared_Valentine@3com.com 3Com XJack Wireless PC Card imp Shipped?
Jared_Valentine@3com.com A 3Com 3XP 3CR990-TX Typhoon txp(4) card will Received
Jared_Valentine@3com.com A 3com 3CXFE575CT Cardbus NIC arved Received
wilko, on behalf of HP AlphaServer 4100 Fruitsalad.org; for KDE development Received
David Leimbach <leimy2k@mac.com> One SATA controller sos Shipped?
David Leimbach <leimy2k@mac.com> G3 (blue and white) for the PPC project obrien Shipped?
Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> 2 x 8gb IDE drives brueffer Received
Jonathan Drews <j.e.drews@att.net> New motherboard, 1GB DDR2100 RAM, LSI Logic Ultra160 SCSI controller, and two 18GB Maxtor 10K III disks for 2003 edition of cvsup12.FreeBSD.org will Received
Jim Dutton <jimd@siu.edu> 512MB of DDR2100 RAM will Received
www.servercommunity.de 2 IDE 3.5" 40GB for FreeBSD/alpha test machines wilko Received
Mike Miller HP Kayak XU (model D8430T) dual Pentium III 450MHz, 512MB RAM, 36GB, 15krpm IBM OEM SCSI drive, Matrox G200 video card, Intel gigabit and 10/100 NIC, Intel 440BX chip set deischen Received
Linuxtag FreeBSD Team Adaptec ANA 62022 NIC mux Received
Robin Brocks <robin.brocks@gmx.de> Two 256MB registered ECC PC133 DIMMs tmm Received
Michael Dexter serial-port Towitoko reader, and three crypto cards. des Received
Michael Dexter Sony VAIO subnotebook wilko Received
Michael Dexter HPT1540 SATA RAID controller, PATA-SATA dongles, 2 ATA controllers Sil0680 + Promise sos Received
www.servercommunity.de One of each of the following NICs: SIS 900, Dec 21143, NatSem 83820 mbr Received
Intel Corporation Commercial Intel C/C++ compiler license FreeBSD.org cluster (netchild) Received
wilko Fore ATM card des Received
www.servercommunity.de 20 Gigabyte IBM Laptop Hard Drive trhodes Received
www.servercommunity.de Pentium 4, 2,4 GHz, FSB800, 1 GB RAM Samsung PC3200, Altec DVD 16x/48x, 80 GB Maxtor IDE ATA133 (slightly used), 2 * 80 GB Maxtor SATA as RAID0, ATI Radeon 9200SE clone graphic card, 3,5" TEAC floppy, 420 Watt ATX be quit! ultra low noise power supply, and Athena CM03 case. netchild Received
Joe Altman PCI Sound card kris Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann two UltraSparc-II 300MHz (X1191A) CPU's obrien Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 128MB PC133 Registered ECC DIMM for Sun Blade 100 obrien Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 4x 128MB PC100 Registered ECC DIMM for Alpha UP2000 obrien Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann G4Port serial adapter for Apple G4 obrien Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Sun 13W3(male) to VGA 15pin(female) converter wilko Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 1 Intel EtherExpress 100 NIC, bulk, new
1 Seagate ST380011A, 80 GB IDE, new
1 50 PIN SCSI cable, new
1 Adaptec 2940 UW, used, tested
1 Seagate Streamer Travan 20 GB, used, tested
1 compu-shack SSW-503 5 port switch, 100 Mbit, new
lioux Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 8 GBic copper modules, FDDI concentrator, and two cables. phk 8GBic modules are in transet, others Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann SGI 1100 motherboard replacement rwatson Received
Artem Koltsov <email@NOSPAM.onepost.net> 1 PC100 128MB dimm njl Received
Artem Koltsov <email@NOSPAM.onepost.net> ATA100 PCI Card2 IDE ports with IDE 100 Cables, Ultra100, PROMISE TECHNOLOGY, ULTRA100 petef Received
Artem Koltsov <email@NOSPAM.onepost.net> SDRAM DIMM 128MB PC133 CL2, Micron Technology, CT16M64S4D7E.16T SDRAM DIMM 128MB PC133, SDRAM DIMM 128MB PC100, Motherboard S1598 Socket 7 with AMD K6 450MHz + IDE Cables, Trinity ATX, Tyan and AMD, S1598, and an IBM HDD IDE 9.1GB, DJNA-370910 fjoe Received
Artem Koltsov <email@NOSPAM.onepost.net> A PS2 Mouse 2 Buttons, M-S34,Compaq, 166861-001 and a PS2 Mouse 3 Buttons, M-CAC64, Labtec, 851680-0000 mikeh Received
Dynacom Tankers Mgmt LTD Sun Ultra 10 mux Received
Jon <juostaus@yahoo.com> Samsung 8x8x32 CDRW rwatson Received
wilko Abit BP6 mainboard incl. CPUs nsouch Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann SUN SPARC Clone 4x400MHz 1GB RAM 36GB RAID System krion Received
Sten Spans AlphaStation 500 philip Received
mjacob AlphaServer 4100 SMP the FreeBSD cluster at Yahoo! (via obrien) Still in holding pattern awaiting placement in cluster
trevor Sun Ultra 1 and GDM-17E20 jmg Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann A 13W3 Female To DB15HD Male adapter (Sun monitor to VGA) ceri Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann "XML in a Nutshell" (O'Reilly) and a PCMCIA WLan Adapter josef Received
wilko Digital NoName Alpha mainboard ru Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann External SCSI enclosure, 4 1.2GB SCSI disks le Received
Jon Noack <noackjr@alumni.rice.edu> Two 32-bit if_em Intel PRO/1000 MT Desktop Adapters rwatson Received
Remi <MrL0L@charter.net> Sony VAIO PCG818 njl (passed to imp when use has ended) Received by njl
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann BT878 PAL TV-card with a MSP340x/MSP341x alex Received
Christoph Franke <christoph@thefranke.net> Pentium IV 2.0 GHz, Asus P4B266, 1 GB Ram (Infineon CL2), Adaptec 29160 SCSI Controller, Tekram DC390-U2W SCSI Controller, Seagate 36 GB 10.000rpm HDD, Plextor Ultra-Plex 40 Max SCSI CDROM, Fujitsu GígaMO Drive (1,3 GB capacity incl. 4 media), Adaptec Duo Connect Firewire/USB 2.0 Controller, 3Com 905C Ethernet Card, Turtlebeach Santa Cruz Soundcard PCI, Floppy Drive, Chieftec Big Tower Case (Noise-Controlled) mlaier Received
"scottgannon@mail.ellijay.com" <scottgannon@ellijay.com> slot1 600MHz P3 CPU imp Received
Oliver Fuckner <Fuckner@strato-rz.de> 3Com 3CR990 Typhoon/Sidewinder (txp(4)) NIC. obrien Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Sun Enterprise 450, 2x250MHz Ultra Sparc CPUs, 512MB RAM, 2x36GB (Seagate ST336705LC 5063) SCSI disk drives, 1x4GB (Seagate ST34371W SUN4.2G 7462) SCSI disk drive and a Streamer DDS3-DAT (HP C1537A), Intel PRO/1000 (em(4)) NIC arved Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 256MB Ram (Sun Original #501-5691) krion Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 1U Rackmount Intel Celeron 2.6GHz, 533MHz compat. motherboard, 256MB PC2100 DDR 266MHz RAM, Savage8 3D Video Accelerator, 80GB 7200rpm ATA100 IDE Harddrive, Integrated 10/100 LAN VT8233 trhodes Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Athena CM-03 case silver with be quiet! 350 Watt ATX 1.3, Asus motherboard A7V600, Athlon XP 2800+ processor with Artic copper cooling, 512 MB Ram Infineon PC3200, AOpen DVD 1648 silver, Floppy silver, Seagate ST380011A 80 GB IDE, xelo GeForce2 MX400 josef Received
"Darrell" <skykitty@earthlink.net> Abit VP6 Motherboard w/raid, 2 Intel 1ghz CPUs, 1 gig PC 133 ram, Nvidia video card, Sound Blaster PCI sound card, DVD Player, CD-RW, Floppy Drive, Case, Power Supply mikeh Received
Aled Morris <aledm@qix.co.uk> Netgear GA302T NIC for testing bge(4) yar Received
wilko Fore ATM card philip Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Chicago Manual of Style, 15th Edition ceri Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Quantum Atlas 10KIII 3,5" 73,4 GB brueffer Received
Chris Knight <chris@easy-e.com.au> Several books, Assembly Step-by-step, TCP Illustrated Vol.2 and HTTP: The Definitive Guide. hmp Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Hitachi 5K80 (2,5", 80 GB), USB-to-serial adapter, 5.25" enclosure with USB2 and IEEE1394 ports, IEEE1394 PCI card netchild Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann External 60 GB USB2 disk le Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Fee for EuroBSDCon tutorial josef Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Funds for a laptop ceri Received
ceri Dual Pentium 3 motherboard plus processors vs Received
Network Appliance NetApp F825 filer with 2 terabytes of storage FreeBSD.org cluster Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 2 256MB DIMMs for AlphaStation DS10 wilko Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 4 256MB DIMMs for an AlphaPC164sx wilko Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann copy of the ANSI T1.617-1991 standard rik Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 3,5" Floppy Samsung with cable, CD-Rom Toshiba , 2 Intel XEON 1,8 GHz, socket 603 with cooler, 2 SCSI-3 68 pin-68 pin cable extern, 7 SCSI-disks 9,1 GB Seagate Barracuda ST319171 WC, 2 SCSI-disks 18,2 GB Seagate Barracuda ST318275FC fibre channel, 3 SCSI-disks 9,1 GB IBM DNES-309170 , 1 external SCSI-enclosure hot plug Chieftec CT-1034, 8 SCA-adaptors LVD, 1 QLogic fibre channel adapter, 1 Intel 1000 Pro MT NIC, 1 ICP Vortex SCSI raid controller GDT7519RN fibre channel, 1 Adaptec 39160 dual channel SCSI controller 64bit LVD, 1 SCSI-LVD 7+1 cable internal with terminator, 1 INTEL SHG2 DUAL XEON mainboard new, 2x 512MB DDR SDRAM's PC1600-CL2 Samsung M383L6420BT1-CA0 pjd Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 1 8 port Gigabit switch Netgear GS108, 1 new system: Athlon XP 2800+, 1 GB Ram (2 * 512 GB Infineon PC 3200), AOpen DVD 1648, Athena CM03 case silver, Floppy, Asrock motherboard, GForce 4, 80 GB Seagate IDE 3,5", 353 Watt Enermaxx power supply. mux Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 1 NetGear GA302 jesper Shipped
David <dave@hauan.org> 1 Alpha Motherboard kensmith Received
wilko Sun Creator3D UPA graphics card trhodes Received
Tunix B.V. ATX tabletop case for my AlphaPC 164sx wilko Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 16Mb flash for Cisco rik Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Cisco 2600 (64M memory/8M flash) + X.21 cable rik Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Entrance fee for the EuroBSDCon 2004 brueffer Received
Gavin Atkinson <gavin.atkinson at ury.york.ac.uk> Pair of fxp(4) cards ceri Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann NetGear GA302T bge(4) jesper Received
philip 2x Sun Ultra10 workstation will Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann

Hardware for laptop: Pentium III Mobile 600MHz CPU, 2 128MB PC100 SODIMM RAM, new battery, Netgear WG511T CardBus adapter

AMD64 desktop: ASUS SK8N motherboard, AMD Opteron 240 CPU, Arctic Cooling Silencer 64 Ultra TC, 2 512MB ECC RAM (Kingston), AOpen Combo drive (COM4824), 4 80GB IDE PATA, NVIDIA GeForce4 MX 440 AGP 8X video, 3.5" floppy, Athena CM03 case, 350 Watt Be Quiet! power supply, S/PDIF out module, 17" LCD monitor Acer AL1715

Hardware for Alpha: 4 128MB ECC RAM (Samsung), 18GB SCSI (Fujitsu MAA3182SC) with cable

RTL8139 Ethernet CardBus adapter, 2 Intel PRO/1000 MT desktop adapters, 5-port 100Mbps Ethernet switch

Flight to Germany and entrance fee for the EuroBSDCon 2004

ru Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 2 512MB ECC RAM (Kingston), 2 80GB SATA (Maxtor DiamondMax Plus 9) for RAID1, 2 80GB PATA, NVIDIA GeForce4 MX 440 AGP 8X video, ASUS SK8N motherboard, 350 Watt Enermax SLN power supply, 3.5" floppy, Toshiba DVD-ROM, Athena CM03 case, AMD Opteron CPU, Arctic Cooling Silencer 64 TC, set of reserve coolers phantom Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann SPEC JBB2000 benchmarking software phantom Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann keyboard with US layout josef Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Adaptec 39160 dual channel SCSI controller 64bit LVD, 36GB SCSI HDD (HITACHI DK32EJ36NSUN36G) markus Received
philip Sun Ultra10 workstation thierry Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 4 memory DIMMs for AlphaServer DS10 wilko Received
wilko AlphaStation 500 5/266 workstation dinoex Received
philip Sun Ultra10 workstation brueffer Received
wilko 2x Seagate Barracuda 9.1GB SCA SCSI disk philip Received
Absolight Entrance fee for the EuroBSDCon 2004 mat Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 2x Seagate ST 380011A, 3.5" disk clement Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 8x 64M Sun memory philip Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Netgear GS608 Gigabit Ethernet switch wilko Received
Sebastian Trahm <inthisdefiance@gmx.net> Specialix SX RS232 concentrator des Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Netgear GA302T Gigabit Ethernet NIC brueffer Received
Jürgen Dankoweit Madge Smart MK4 PCI Token Ring adapter philip Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Cisco 2600, NM-16A, 2x octopus serial cable philip Received
Warren Block <wblock@wonkity.com> Tecra 8000 imp Received
Michael Dexter Apple Power Macintosh G4 machine gallatin Received
Michael Dexter NCD Explora 451 PPC Thin Client obrien Received
Juergen Dankoweit <juergen.dankoweit@t-online.de> Unsupported CF-Card reader josef Received
pav Two O'Reilly security books josef Received
ds em(4) compatible gigE card, 1000baseTX (copper) interface wilko Received
keramida Copy of "Cascading Style Sheets: The Definitive Guide" (O'Reilly), ISBN 0-596-00525-3. ceri Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann PCMCIA FireWire controller brueffer Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann IBM Laptop AC Adapter mlaier Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 75 EUR (for ISP) josef Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Power Battery for IBM Thinkpad T20 glebius Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 40 Gb notebook HDD glebius Received
maxim The Design and Implementation of the FreeBSD Operating System glebius Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Funds for a laptop markus Received
ds Funds for a D-Link DWL-AG530 PCI card for ath(4) and wpa_supplicant testing. brooks Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann UltraSPARC IIi 300MHz CPU, 4.3G SCA disk, 18.2G SCA disk. philip Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Funds for a SATA HDD. ceri Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 2 Intel 100 MBit NICs, 1 be quiet! 350 Watt power supply, 1 DVD Toshiba SD-1912, 1 floppy TEAC FD-235HF, 2 Kingston KVR266X72RC25/512 (1 GB), 1 NVidia MX 4000 graphic card, 1 Ultra Silencer TC cooler, 1 AMD Opteron 144 1.8 GHz, 1 Asus SK8N mobo, 1 Seagate ST380011A HDD (80GB ATA). clement Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 1x Sun Ultra60, 768M memory, 2x SCA disk philip Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann AMD64 server : ASUS SK8N motherboard, AMD Opteron 144 1.8Ghz CPU, Arctic Cooling Silencer 64 Ultra TC, 2 512MB RAM (Kingston), 80GB IDE, ATI Rage 128 PRO ULTRA Video Controller simon Received
obrien 4x Athlon MP 2400+ CPUs with HSFs will Received
obrien 4x Opteron 844 CPU's alc Received
obrien 4x Opteron 875 dual-core CPU's alc Received
obrien Opteron 275 dual-core Tyan K8W system alc Received
obrien 2x Opteron 270 dual-core CPU's, Athlon64 3200+ CPU kan Received
obrien 2x Opteron 252 CPU's kensmith Received
obrien Athlon64 4600+ X2 dual-core and Athlon64 3800+, Gigabyte and Asus PCI-express motherboards scottl Received
obrien Quad Opteron 870 dual-core system jeffr Received
will 2x Athlon XP 2200+ CPUs with HSFs, 1 Sun Seagate 20GB HDD obrien Received
marcus 1 Maxtor Atlas 15K U320 8C018L0 SCSI disk for cvsup12 will Received
Jonathan Drews <jon.drews@gmail.com> 1 copy of the "Design and Implementation of the FreeBSD Operating System" via gift certificate will Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 4x Seagate ST173404LCV disks philip Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 1 copy of the "The AWK Programming Language" Aho, Alfred and 1 copy of the "Compilers" Aho, Alfred krion Received
LF.net Flight to Canada and accommodation fee for BSDCan 2005 krion Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann i386 machine : Athlon XP2800+, Asus A7V600, Seagate ST 380011A IDE, 80 GB, Maxtor Diamondmax 10 120 GB, NVidia Gforce 2 MX 400, 1 GB Ram (2 x Infineon 512 MB DDR, PC 2700), Compushack 100 MBit NIC, RTL 8139 clone. krion Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann 17" monitor LCD Acer 1715-sn krion Received
wilko Pentium Pro processor and heatsink des Received
Denis Kozjak and Daniel Seuffert ASUS A7M266-D, 2x AMD Athlon MP 2000+, 2x CPU Fan, 512 MB RAM, 400W PSU. marks Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Funds for a notebook philip Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Tyan Thunder SE7500WV2 dual Xeon board and 2 x 512 MB DDR PC 1600 registered DDR-ram. Peter Holm, Denmark Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Financial help with transportation to BSDCan. mlaier Received
Hartmut Obst <hartmut.obst@gmx.net> Q-Tec 5 Port Switch mlaier Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Netgear WG511T ath(4) card. wilko Received
Brennan Stehling <offwhite@gmail.com> Four Java books: The Java Virtual Machine Specification, Java Virtual Machine, Programming for the Java Virtual Machine and The Java Native Interface. glewis Received
Frank Seuberth - Rentable Hardware Systeme & Consulting <http://www.rentable-hardware.de/> 2x Sun Ultra 2 machines philip Received
Gary Jennejohn <gary@jennejohn.org> Fujitsu-Siemens Lifebook laptop with accessories. markm Received
Andreas Kohn <andreas.kohn@gmx.net> DEC PBXGA "TGA" card. marcel Received
ds SMP mainboard with 2x Xeon 1.8GHz plus RAM Peter Holm Received
wilko AlphaStation 600 ticso Received
wilko Adaptec AH-2940UW mwlucas Received
obrien 2x AMD Opteron 250 CPU's scottl Received
obrien Arima HDAMA dual processor motherboard + 2x AMD Opteron 250 CPU's imp Received
Markus Deubel <marcus.deubel@unix-resource.de> Sun Ultra 10 440 marius Received
Chris Elsworth <chris@shagged.org> Sun Fire v210 philip Received
ceri Apple USB keyboard (US layout) for my Mac Mini wilko Received
David Boyd SCSI enclosure, lots of hard drives, terminators, cables and accessories mwlucas Received
Mark <markh60@verizon.net> Cisco Catalyst 1900 switch trhodes Received
Alexis Lê-Quôc <alq666@gmail.com> One copy of "The Elements of Typographic Style" by Robert Bringhurst, Hartley & Marks Publishers; 3rd edition (2004). ISBN: 0-88179-206-3. blackend Received
Sun W. Kim from tekgems.com Gigabit NIC jcamou Received
Mark <markh60@verizon.net> CISCO 1900 Series switch trhodes Received
obrien 2 x AMD Opteron 275 CPU mlaier Received
obrien AMD64 mainboard plus Athlon64 3400 CPU wilko Received
wilko AMD64 mainboard, Athlon64 3400 CPU, 256MB RAM itetcu Received
Joe Altman <fj at panix dot com> ASUS mainboard plus P-III CPU and 512M; 2 graphics cards; various hard drives linimon Received
wilko AlphaStation 500 DIMMs ticso Received
imp Znyx quad dc(4) NIC wilko Received
Serge Vakulenko <vak at cronyx dot ru> Cronyx Tau-PCI/32 rik Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Funds for a hard drive and USB enclosure cperciva Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Logitech Cordless Desktop MX5000 Laser markus Received
Daniel <DS@praxisvermittlung24.de>, Seuffert & Waidmann Main server: 1U rackmount chassis, Intel Entry Server Board S845WD1-E, Pentium 4 2.53 GHz CPU, 2 512MB RAM, 2 150GB PATA FreeBSD Russian Documentation Project Received
Tamouh H. <tamouh@mediumcube.com> PC power supply kris Received
Sten Spans <sten@blinkenlights.nl> em(4) GbE card wilko Received
Chidananda Jayakeerti <ajchida@gmail.com> AMD Athlon64 desktop: ECS Nforce 4 motherboard, AMD Athlon64 3500+ CPU, 512MB DDR 400, 200GB SATA, 16x DVD-ROM, 8MB AGP video glewis Received
wilko AlphaPC164sx, 512MB RAM, 4.5GB SCSI disk, Qlogic SCSI HBA dunstan Received
trhodes USD 500 in cash for BSDCan trip. ru Received
hrs UltraSPARC laptop ru Received
asdf 4 SCSI hard drives marcel, thompsa, kan Received
Steve Quirk Sun Ultra 10 jkoshy Received
Paul Ghering <pghering@xs4all.nl> Asus AP1400R 1U server wilko Received
remko 4 Keytronic Lifetime Designer Keyboards flz Received
Mike Tancsa Four fiber em(4) NICs, two copper bge(4) NICs glebius, oleg, yar, ru Received
Paul Ghering <pghering@xs4all.nl> NatSemi Geode based Web/TV appliance sos Received
Paul Ghering <pghering@xs4all.nl> NatSemi Geode based Web/TV appliance markm Received
Paul Ghering <pghering@xs4all.nl> NatSemi Geode based Web/TV appliance wilko Received
netchild 3Com Wireless LAN 54 MBit adapter, Netgear RangeMax Wireless USB WPN111GR 108 MBit adapter, Anycom Blue USB-250 adapter hselasky Received
Martin Nilsson (Mullet Scandinavia AB) Seagate 80GB ATA disk, Samsung 512MB PC3200 RAM joel Received
lawrence 512MB RAM simon Received
Hans Beeksma multiple PCMCIA modems & NICs imp Shipped
Paul Ghering <pghering@xs4all.nl> via wilko NatSemi Geode based Web/TV appliance ariff Received
Justin Pessa Sun Netra X1 shaun Received
wilko various PCMCIA cards imp Received
Paul Ghering <pghering@xs4all.nl> via wilko NatSemi Geode based Web/TV appliance for the FreeNAS project Olivier Cochard-Labbe <olivier@freenas.org> Received
Joe Altman Linksys USB ethernet adapter wilko Received
Uwe Laverenz <uwe@laverenz.de> Ultrabay Slim battery for IBM ThinkPad T41p markus Received
Andrejs Guba (WiMAX) FUJITSU DISK DRIVE 2.5-inch 60GB SATA - MHV2060BH matteo Received
Andrejs Guba (WiMAX) U320 1 channel SCSI CARD - LSI Logic LSI20320C-HP U320 SCSI PCI-X 133MHz mjacob Received
Bryan Kaplan Dell Managed 2708 8-port gig switch glebius Received
Nicole Harrington and Picturetail.com Various SCSI drives, cables, and cards for mjacob, Dual P3 motherboard with chips and RAM for mpp, 146GB SCSI disk for glebius, various other system components (network cards, CPUs, CPU fans) waiting for other committers if/when they need it. All components delivered to trhodes. Received
netchild Pentium 4 2,4GHz CPU, Heatsink + CPU Cooler joel Received
rink 2 18GB SCA disks xride Received
markus Sun 100MBit SBus NIC shaun Received
Holger Jeromin D-Link DFE-570TX NIC njl Received
brueffer Adaptec ANA-62022 NIC danfe Received
Walter Kiel ECS ELITEGROUP 915P-A motherboard + CPU ade Received
Gareth Randall Sun Netra t1 philip Received
Garrett Cooper Seagate 73GB SCSI disk + 2x Adaptec 2940 U2W controllers and cables rink Received
Anand S Athreya & Srinivas Podila (Juniper) Dell E520 CPU jkoshy Received
Chess Griffin VIA EPIA-M system brueffer Received
Mariusz J. Handke SCSI disks + DIMMs wilko Received
Christoph Haas <ch@dorsia.de> Sun Ultra 60: 2x 450MHz UltraSPARC II, 2GB RAM, 2x 9GB SCSI drives, QLogic 2200F FC controller
Sun StorEdge T3 with 9x 36GB FC drives
markus Received
carvay hard drive mounting kit for Soekris net4801 arved Received
brueffer soekris vpn1401 simon Received
wilko Sun Ultra 5 rink Received
Daniel Austin <me@dan.me.uk> DIMMs plus ATA disks wilko Received
Daniel Austin <me@dan.me.uk> DIMMs plus ATA disks rink Received
Daniel Austin <me@dan.me.uk> ATA disks joel Received
Daniel Austin <me@dan.me.uk> WinTV PCI Tuner card gavin Received
Edwin Verplanke <edwin.verplanke@intel.com> Intel D3C6132 Software Development Platform jkoshy Received
Charles Smeijer AMD Opteron 250 CPU des Received
wilko Asus AP1400R 1U server rink Received
rpaulo VIA XinE Firewire OHCI (PCI) mlaier Received
Steve Rikli Ultra2 2x400Mhz, 2GB RAM, 2x72GB disks, CDROM linimon Received
Dax Kelson (Guru Labs) Nvidia Geforce 6800 GT rnoland Received
bms Netgear WGT634U gonzo Received
Mike Partin 4 x Dell 2550 dual P-III 2U servers
1 x Dell 6550 quad Xeon 4U server
2 x IBM Netfinity 400R dual P-III 1U servers
linimon Received
Colin Jensen 4.4BSD Manuals from O'Reilly marcel Received
Charles Smeijer HP/CPQ Gb NIC NC7770, PCI-X 133 HP p/n 284685-003 Rev 0G
HP/CPQ Gb NIC NC7770, PCI-X 133 HP p/n 284685-003 Rev 0E
HP/CPQ Dual port Gb NIC NC7170, PCI-X 133 HP p/n 313559-001 Rev 0A
SMC Fast ethernet USB NIC p/n 98-012084-585
IBM Gb NIC PCI-X 133 p/n 00P6130
HP DAT72 data cartridge 72 GB
ed Received
brooks 2 DDR400 256MB DIMMs wilko Received
Edson Brandi <ebrandi@fugspbr.org> BrookTree chipset TV Capture Card BT878 lioux Received
Charles Smeijer HP JetDirect 175x print server rpaulo Received
Gateworks Corporation Cambria GW2358-4 board rpaulo Received
Alexis Megas <megas@alum.rpi.edu> Sun Ultra Sparc 60 glewis Received
bms MPLS and Label Switching Networks book rpaulo Received
bms See MIPS Run book stas Received
Justin Settle Kuma Athlon 7750 jkim Received
Justin Settle HTPC Machine wxs Received
Justin Settle Soekris 5501 lstewart Received
gavin 3 Zip 100 drives
3 3ware cards
mav Received
Gareth Randall HP C1636-00100 SCSI tape drive cracauer Received
Ivan Jedek 2 Sun Fire V65 miwi (for pkg build cluster) Received
Gareth Randall USB card gj Received
Kyle Anderson (tummy.com) 6 SuperMicro servers brd (firewalls and infrastructure servers
for the new NYC FreeBSD co-location)
Received
Garrett Cooper Cisco 877WAGN router ehaupt Received
Garrett Cooper Linksys WRT160N wireless router dougb Received
grehan Apple XServe G5 portmgr (for pkg build cluster) Received
Garrett Cooper 2GB PC6400 DDR2 Corsair RAM module fjoe Received
sson PowerMac G4 stas Received
sson PowerMac G4 rnoland Received
Raymond Vetter Sun Ultra 5 gahr Received
jmallett Cavium Octeon MIPS gonzo Received
Raymond Vetter Sitecom CN-500 itetcu received
Raymond Vetter 3xIDE cables
FDD cable
VGA cable
serial cable
2xCAT7 ethernet cable
romain received
ds memory modules and hard disks pgj received
Raymond Vetter Netier NetXpress XL1000 rink received
Raymond Vetter IBM Thinkpad port replicator brueffer received
Andreas Thalau 512MB PC2700 SO-DIMM RAM module brueffer received
Andreas Thalau Sharp Zaurus SL-5500G itetcu received
Travis Thaxton Dell Optiplex 960 ade received
Travis Thaxton Dell 22" LCD monitor delphij received
Travis Thaxton Dell 22" LCD monitor dougb received
Olivier Cochard-Labbe Sun Blade 150 fjoe received
Andreas Thalau Level One GSW-0502T gigabit switch lme received
Raymond Vetter ATI Radeon 9800 fjoe received
Anton Shterenlikht 1x Asus WL-107g (Ralink RT2560 + RT2525, ral(4))
1x MSI CB54G2 (Ralink RT2560 + RT2525, ral(4))
1x Sitecom WL-112 (Ralink RT2560 + RT2525, ral(4))
1x Zonet ZEW1500 (PRISM GT/ISL3890, no driver)
1x Linksys WPC11v4 (Realtek RTL8180L, no driver)
bschmidt received
Garrett Cooper Core2Duo-based i386 machine bf received
Garrett Cooper PowerMac G5 dchagin received
Eimar Koort <eimar.koort@gmail.com> Sun Microsystems Sun Fire V210 marius received
wilko 4x 72GB FibreChannel disk for the sparc package building machine marius received
Jean-Michel Poure Feitian R-301 and ePass2003 arved received
Lyndon Nerenberg Sun Microsystems Sun Fire V100 tabthorpe received
Anton Shterenlikht Linksys WPC11 ver.3 (no driver)
US Robotics USR5410 (Texas Instruments, no driver)
Cisco Aironet 350 (no driver)
Linksys WPC54G ver3.1 (Broadcom BCM4318, bwi(4))
NEC CMZ-RT-WP (NEC CMZ-RT-WP, wi(4), unsupported)
Netgear WG111v2 (Realtek RTL8187L, urtw(4))
adrian received
Garrett Cooper Macbook 2.2GHz Santa Rosa marcel received
Garrett Cooper 2x 4GB 1333 DDR3 ECC RAM banks garga received
Marco Dola 2x Kingston KVR1333D3N9/2G RAM banks gavin received
Greg Larkin Belkin #F1D066 OmniView PS/2 KVM Switch
+ + 6 foot VGA cables
+ + 6 foot PS/2<->PS/2 keyboard/or mouse cables
bf received
Greg Larkin Mac G4 Cube 500Mhz PowerPC alfred received
diff --git a/en_US.ISO8859-1/htdocs/internal/machines.xml b/en_US.ISO8859-1/htdocs/internal/machines.xml index 6b78dc8df9..842cc13a56 100644 --- a/en_US.ISO8859-1/htdocs/internal/machines.xml +++ b/en_US.ISO8859-1/htdocs/internal/machines.xml @@ -1,425 +1,361 @@ ]> &title; $FreeBSD$

This page documents, for those with accounts on the FreeBSD.org network, just what machine resources are currently available and the sorts of jobs they are being provided for.

For a list of SSH host keys and their fingerprints for the public FreeBSD.org machines, please see this file.

Developer FreeBSD.org hosts

These systems are available for FreeBSD developer / committer use. Reference systems can be used for build tests etc.

- - - - + + + + - + - - - - + + + + - - + + - - - - - - -
Host OS Type Purpose
builder8-STABLEi386BSD/OS source holder,
- Build box for the FreeBSD documentation for the FTP site.
eris10-CURRENTia64Reference machine.
flame 10-CURRENT sparc64 Reference machine.
freefall8-STABLE10-CURRENT i386 GNATS/shell Logins.
pluto18-STABLEia64Reference machine; ia64 package building.nova9-STABLEsparc64Reference machine.
pluto29-CURRENTpluto9-STABLE ia64Reference machine; ia64 package building.
ref7-amd647-STABLEamd64 Reference machine.
ref8-amd64 8-STABLE amd64 Reference machine.
ref9-amd64 9-STABLE amd64 Reference machine.
ref10-amd64 10-CURRENT amd64 Reference machine.
ref10-i386 10-CURRENT i386 Reference machine.

Administrative FreeBSD.org hosts

These systems perform various administrative services. Most have restricted access.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HostOS Purpose
ftp-master8-STABLE FTP Master (stage server).
hub7-STABLE Mailing Lists and Mail services.
ipv6gw8-STABLE IPv6 tunnel router (peer is at ISC).
mx17-STABLE Inbound Mail services.
mx27-STABLE Outbound Mail services.
ns06-STABLE A FreeBSD.org authoritative DNS Server.
ns1, ns28-STABLE FreeBSD.org recursive DNS Server.
repoman7-STABLECVS Master repository.
skunkworks7-STABLE Perforce server.
sky8-STABLEVarious web services, such as wiki, reverse HTTP proxy etc.
spit (cvsup-master)6-STABLECVSup master mirror.
svn7-STABLE Subversion master repository.
www7-STABLE The www.FreeBSD.org Webserver.

Ports building cluster

The ports building cluster is primarily managed by the Ports Management team (portmgr).

Host OS Purpose
pointyhat 9-CURRENT All architectures package build master.
gohan10-13 9-STABLE amd64 package build cluster.
gohan18 8-STABLE portmgr testbed.
gohan61-62 9-STABLE amd64 package build cluster.

Hardware configurations

- - - - - - - + - - - - - - - - - - - - - - - - - -
Host Type Hardware
builder
flame Sun SPARC Sun Fire V120, UltraSparc-IIe 648MHz, 2GB Memory, sym SCSI controller, 2x 36G SCSI-3 disk, 2x Sun ERI 10/100 Ethernet.
freefall Intel x86 2x dual-core 2.80GHz Xeon (Pentium-IV family), 2GB Memory, Compaq Smart Array 5i SCSI RAID controller, 138 GB SCSI local storage, Broadcom-based Compaq NC7781 Gigabit Server Adapter NIC.
ftp-master Intel x86 2x dual-core 2.80GHz Xeon, 4GB Memory, LSI Logic PERC 4e/Di RAID adapter, 1.14T disk, 2x Intel PRO/1000 Ethernet NIC.
gohan10-13 Intel x86 2x1.8GHz quad-core Xeon L5320, 8GB Memory, Intel 63XXESB2 SATA300 controller, 1x160GB SAT300 drive, 2xIntel PRO/1000 NIC.
gohan18 Intel x86 2x1.8GHz quad-core Xeon L5320, 8GB Memory, LSILogic SAS/SATA controller, 1x160GB SAT300 drive, 2x Broadcom NetXtreme Gigabit Ethernet NIC.
gohan61-62 Intel x86 2x2.0GHz quad-core Intel Xeon L5335, 32GB Memory, Dell PERC 6 Megaraid SAS controller, 418GB local storage, 2x Broadcom NetXtreme II BCM5708 1000Base-T Ethernet NIC.
hub AMD64 MP 4x2.2GHz (dual CPU, dual core), 3GB Memory, Adaptec RAID Controller, 4x36GB U160 SCSI Disk, Broadcom Gigabit Ethernet.
mx1 Intel x86 MP 8x1.86GHz Xeon (dual CPU, quad core), 8GB Memory, Dell PERC 5/i RAID controller, 2x136GB SAS disks in RAID1, Broadcom NetXtreme Gigabit Ethernet adapter.
mx2 Intel x86 MP 2x2.8GHz Xeon, 1GB Memory, Compaq Smart Array 5i RAID controller, 2x34GB SCSI Disks in RAID1, Broadcom Gigabit Ethernet.
ns0, ns1, ns2 Intel x86 2.8GHz Xeon, 1GB Memory, Compaq Smart Array 5i RAID controller, 2x34GB SCSI Disks in RAID1, Broadcom Gigabit Ethernet.
pluto1, pluto2pluto IA-64 MP 2x900MHz Itanium2 (McKinley) - HP zx1 (pluto) chipset, 2GB Memory, LSILogic 1030 U320 SCSI controller (mpt), 1x36GB 10K RPM U160 SCSI drive, Broadcom BCM5701 Gigabit NIC.
pointyhat Intel EM64T MP 2x2.8GHz Intel Xeon (dualcore), 4GB Memory, Dell PERC 4 RAID controller, 1.1TB storage, Intel PRO/1000 Gigabitq NIC.
ref[7-10]-(amd64|i386) Intel EM64T MP Dell PowerEdge 2950, 2xIntel Xeon L5320 (8x1.86GHz), 8/16GB Memory, PERC 5/i RAID controller, 6x136GB SAS disks, Broadcom NetXtreme II BCM5708 NIC.
repomanAMD64 MP4x2.4GHz Opteron 280 (dual CPU, dual core), 8GB Memory, -HP Smart Array 6i RAID controller, -Broadcom BCM5704C Gigabit NIC.
skyIntel x86 MP2x2.4GHz Xeon, 2GB Memory, Compaq RAID 5, Broadcom Gigabit NIC.
spit  
www Intel x86 2x dual-core 2.80GHz Xeon, 1.5GB Memory, Compaq Smart Array 5i RAID controller, 2x34GB SCSI Disks in RAID1, 2x Broadcom Gigabit Ethernet NIC.

All machines are connected at 100Mbit/sec full-duplex to a dedicated Cisco 2948G switch with redundant gigabit uplinks. Internet connectivity and colocation is provided by Yahoo!. All systems have logged serial consoles and remote power management.

Administrative Policies

If the machine in question is "owned" by someone specific, please direct queries to them first when asking about administrative issues, this includes changes to user accounts or filesystem layout.

All new user accounts must be cleared with the admin staff, and are given only to FreeBSD developers, either in the docs, ports or general src hacking category. Accounts may be given to non-project developers if they have a specific need to test something of a truly experimental nature and need access to a FreeBSD machine for the purpose. See New Account Creation Procedure page for details on new accounts. Accounts are not given to the general public for "vanity domain" mail or other such uses. It would be a waste of time to ask. Thanks.

FreeBSD Internal Home diff --git a/en_US.ISO8859-1/htdocs/releases/9.2R/schedule.xml b/en_US.ISO8859-1/htdocs/releases/9.2R/schedule.xml index 9bf5f0039a..0791f9ae28 100644 --- a/en_US.ISO8859-1/htdocs/releases/9.2R/schedule.xml +++ b/en_US.ISO8859-1/htdocs/releases/9.2R/schedule.xml @@ -1,164 +1,164 @@ ]> &title; $FreeBSD$

Introduction

This is the release schedule for FreeBSD &local.rel;. For more information about the release engineering process, please see the Release Engineering section of the web site.

General discussions about the pending release and known issues should be sent to the public freebsd-stable mailing list. MFC requests should be sent to re@FreeBSD.org.

Schedule

- + - + - +
Action Expected Actual Description
Initial release schedule announcement - 23 June 2013 Release Engineers send announcement email to developers with a rough schedule.
Release schedule reminder 1 July 2013 4 July 2013 Release Engineers send reminder announcement e-mail to developers with updated schedule.
Code slush begins 6 July 2013 6 July 2013 Release Engineers announce that all further commits to the &local.branch.stable; branch will not require explicit approval, however new features should be avoided.
Code freeze begins 12 July 2013 12 July 2013 Release Engineers announce that all further commits to the &local.branch.stable; branch will require explicit approval. Certain blanket approvals will be granted for narrow areas of development, documentation improvements, etc.
BETA1 builds begin 19 July 2013 19 July 2013 First beta test snapshot.
BETA2 builds begin 26 July 2013-26 July 2013 Second beta test snapshot.
&local.branch.releng; branch 1 August 2013-3 August 2013 Subversion branch created; future release engineering proceeds on this branch.
RC1 builds begin 2 August 2013-3 August 2013 First release candidate.
RC2 builds begin 9 August 2013 - Second release candidate.
RC3 builds begin 16 August 2013 - Third release candidate.
RELEASE builds begin 23 August 2013 - 9.2-RELEASE built.
RELEASE announcement 31 August 2013 - 9.2-RELEASE press release.
Turn over to the secteam - - &local.branch.releng; branch is handed over to the FreeBSD Security Officer Team in one or two weeks after the announcement.

Additional Information

diff --git a/en_US.ISO8859-1/share/xml/release.l10n.ent b/en_US.ISO8859-1/share/xml/release.l10n.ent index 8d0b6babca..d304b108c0 100644 --- a/en_US.ISO8859-1/share/xml/release.l10n.ent +++ b/en_US.ISO8859-1/share/xml/release.l10n.ent @@ -1,156 +1,152 @@ ]]> Version & Platform Distribution ISO TODO List FreeBSD &betarel2.current;-&betarel2.vers; [View] [View] amd64
(x86-64, x64) [Distribution] [ISO] i386 [Distribution] [ISO] ia64 [Distribution] [ISO] powerpc [Distribution] [ISO] powerpc64 [Distribution] [ISO] sparc64 [Distribution] [ISO] '> ]]>

Help With The Next FreeBSD Release&beta.plural;

Our developers and release engineers are working on the the next release&beta.plural; of FreeBSD; if you wish to help with testing, please download the latest build&beta.plural;. Please note that these images are, by their very nature, intended for testing and should not be used in production environments.

- -
Version & Platform Distribution ISO
FreeBSD &betarel.current;-&betarel.vers;
amd64
(x86-64, x64)
[Distribution] [ISO]
i386 [Distribution] [ISO]
ia64 [Distribution] [ISO]
powerpc [Distribution] [ISO]
&beta.second; '> ]]> diff --git a/ja_JP.eucJP/articles/contributing/article.xml b/ja_JP.eucJP/articles/contributing/article.xml index b2065377c7..0d02324e0c 100644 --- a/ja_JP.eucJP/articles/contributing/article.xml +++ b/ja_JP.eucJP/articles/contributing/article.xml @@ -1,599 +1,601 @@
FreeBSD ¤Ø¤Î¹×¸¥ ¤³¤Îʸ½ñ¤Ï¡¢¸Ä¿Í¤äÃÄÂΤ¬ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ë¹×¸¥¤¹¤ë¤¿¤á¤Î¤¤¤¯¤Ä¤«¤ÎÊýË¡¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ Jordan Hubbard ´ó¹Æ: &tm-attrib.freebsd; &tm-attrib.ieee; &tm-attrib.general; $FreeBSD$ $FreeBSD$ ¹×¸¥ ¤¢¤Ê¤¿¤â FreeBSD ¤Î¤¿¤á¤Ë¹×¸¥¤·¤¿¤¯¤Ê¤ê¤Þ¤·¤¿¤«? ÁÇÀ²¤é¤·¤¤! FreeBSD ¤ÏÀ¸¤­»Ä¤ë¤¿¤á¤Ë¥æ¡¼¥¶¥Ù¡¼¥¹¤Î¹×¸¥¤ËÍê¤Ã¤Æ¤¤¤Þ¤¹¡£ ¤¢¤Ê¤¿¤Î¹×¸¥¤Ï´¶¼Õ¤µ¤ì¤ë¤À¤±¤Ç¤Ï¤Ê¤¯¡¢FreeBSD ¤¬À®Ä¹¤·Â³¤±¤ë¤¿¤á¤Ë¶Ë¤á¤Æ½ÅÍפʤâ¤Î¤Ê¤Î¤Ç¤¹! °ìÉô¤Î¿Í㤬ȯ¸À¤·¤Æ¤¤¤ë¤Î¤È¤ÏÈ¿ÂФˡ¢ ¹×¸¥¤ò¼õ¤±ÉÕ¤±¤Æ¤â¤é¤¦¤¿¤á¤ËÏÓÍø¤­¤Î¥×¥í¥°¥é¥Þ¡¼¤Ë¤Ê¤ë¤È¤« FreeBSD ¥³¥¢¥Á¡¼¥à¤Î¿Í¤È¿ÆÍ§¤Ë¤Ê¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£ ¿¤¯¤Î¤½¤·¤Æ±×¡¹Áý²Ã¤¹¤ëÀ¤³¦Ãæ¤Î¹×¸¥¼Ô㤬 FreeBSD ¤ò³«È¯¤·¤Æ¤ª¤ê¡¢ Èà¤é¤ÎǯÎð¡¢ÀìÌçµ»½ÑʬÌî¤Ï¿´ô¤ËÅϤäƤ¤¤Þ¤¹¡£ ¼ê¤Î¶õ¤¤¤Æ¤¤¤ë¿Í¤è¤ê¤âÀ®¤¹¤Ù¤­»Å»ö¤ÎÊý¤¬Â¿¤¯¡¢ ¤ª¼êÅÁ¤¤¤Ï¤¤¤Ä¤Ç¤â´¿·Þ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ï¥«¡¼¥Í¥ë¤ä»¶ºß¤·¤Æ¤¤¤ë¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤è¤ê¤â¡¢ ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à´Ä¶­¤ËÂФ·¤ÆÀÕǤ¤ò»ý¤Ã¤Æ¤¤¤Þ¤¹¡£ »ä¤¿¤Á¤Î TODO ¥ê¥¹¥È¤Ë¤Ïʸ½ñÀ°È÷¡¢¥Ù¡¼¥¿¥Æ¥¹¥È¡¢ ¥¤¥ó¥¹¥È¡¼¥é¤äÀìÌç²½¤µ¤ì¤¿¥¿¥¤¥×¤Î¥«¡¼¥Í¥ë³«È¯¤Î¹¥Îã¤ò¾Ò²ð¤¹¤ë¤Ê¤ÉÈó¾ï¤Ë¹­¤¤ÈϰϤκî¶È¤¬¤¢¤ê¤Þ¤¹¡£ ¤¢¤Ê¤¿¤Îµ»Ç½¥ì¥Ù¥ë¤äʬÌî¤Ë´Ø¤ï¤é¤º¡¢ ¥×¥í¥¸¥§¥¯¥È¤ò»Ù±ç¤Ç¤­¤ë¤³¤È¤¬É¬¤º²¿¤«¤¢¤ê¤Þ¤¹! FreeBSD ´ØÏ¢¤Î»ö¶È¤Ë·È¤ï¤ë¾¦¶ÈÃÄÂΤ¬»ä¤¿¤Á¤Ë¥³¥ó¥¿¥¯¥È¤¹¤ë¤³¤È¤â´¿·Þ¤·¤Æ¤¤¤Þ¤¹¡£ ¤¢¤Ê¤¿¤ÎÀ½Éʤò (FreeBSD ¾å¤Ç) ưºî¤µ¤»¤ë¤Ë¤Ï¡¢ ÆÃÊ̤ʳÈÄ¥¤¬É¬ÍפǤϤ¢¤ê¤Þ¤»¤ó¤«? ¤¢¤Þ¤ê¤Ë¤âÉ÷ÊѤï¤ê¤ÊÍ×µá¤Ç¤Ê¤±¤ì¤Ð¡¢ ¤½¤ì¤ò¼õ¤±Æþ¤ì¤ëÍѰդ¬»ä¤¿¤Á¤Ë¤¢¤ë¤È¤ï¤«¤ë¤Ï¤º¤Ç¤¹¡£ ÉղòÁÃͤΤ¢¤ëÀ½ÉʤǤ¹¤«? »ä¤¿¤Á¤ËÃΤ餻¤Æ¤¯¤À¤µ¤¤! ¿ʬ»ä¤¿¤Á¤Ï¡¢ ¤¢¤ëÌ̤ˤª¤¤¤Æ¶¦Æ±¤·¤Æºî¶È¤ò¤¹¤ë¤³¤È¤¬¤Ç¤­¤ë¤Ç¤·¤ç¤¦¡£ ¥Õ¥ê¡¼¥½¥Õ¥È¥¦¥§¥¢³¦¤Ï¡¢ ¥½¥Õ¥È¥¦¥§¥¢¤¬¤É¤Î¤è¤¦¤Ë³«È¯¤µ¤ì¡¢ ÈÎÇ䤵¤ì¡¢Êݼ餵¤ì¤Æ¤¤¤¯¤«¤Ë¤Ä¤¤¤Æ¡¢´û¸¤Î²¾Àâ¤ËÄ©À路¤Æ¤¤¤Þ¤¹¡£ ¾¯¤Ê¤¯¤È¤â¤â¤¦°ìÅÙ¹Íθ¤·¤Æ¤ß¤ë¤³¤È¤ò»ä¤¿¤Á¤Ï¶¯¤¯¤ª¾©¤á¤·¤Þ¤¹¡£ ²¿¤¬É¬Í×? ¼¡¤Î²ÝÂê¤È¥µ¥Ö¥×¥í¥¸¥§¥¯¥È¤Î°ìÍ÷¤Ï¡¢¿§¡¹¤Ê TODO ¥ê¥¹¥È¤È¥æ¡¼¥¶¤«¤é¤ÎÍ×µá¤ò¹ç¤ï¤»¤¿¤â¤Î¤Ç¤¹¡£ ¿Ê¹ÔÃæ¤ÎÈó¥×¥í¥°¥é¥Þ¸þ¤±¤Î²ÝÂê FreeBSD ¤Ë´Ø¤ï¤Ã¤Æ¤¤¤ëÃæ¤Ë¤Ï¡¢¥×¥í¥°¥é¥Þ¤Ç¤Ï¤Ê¤¤¿Í¤¬¤¿¤¯¤µ¤ó¤¤¤Þ¤¹¡£ ¥×¥í¥¸¥§¥¯¥È¤Ë¤Ï¡¢Ê¸½ñ¤ò½ñ¤¯¿Í¡¢Web ¥Ç¥¶¥¤¥Ê¡¢¥µ¥Ý¡¼¥È¤ò¹Ô¤¦¿Í¤¬¤¤¤Þ¤¹¡£ ¹×¸¥¤¹¤ë¤Î¤ËɬÍפʤΤϡ¢»þ´Ö¤ÎÅê»ñ¤È³Ø¤Ö°ÕÍߤǤ¹¡£ Äê´üŪ¤Ë FAQ ¤È¥Ï¥ó¥É¥Ö¥Ã¥¯¤òÄ̤·¤ÆÆÉ¤ó¤Ç¤ß¤Æ¤¯¤À¤µ¤¤¡£ ¤â¤·¤Þ¤º¤¤ÀâÌÀ¤ä¸Å¤¤»öÊÁ¤ä´°Á´¤Ë´Ö°ã¤Ã¤Æ¤¤¤ë¤³¤È¤Ê¤É¤¬¤¢¤ì¤Ð»äã¤Ë¶µ¤¨¤Æ¤¯¤À¤µ¤¤¡£ ¤µ¤é¤ËÎɤ¤¤Î¤Ï²æ¡¹¤Ë½¤Àµ°Æ¤òÁ÷¤ë¤³¤È¤Ç¤¹ (Docbook ¤Ï³Ø¤Ö¤Î¤Ë¤½¤ì¤Û¤ÉÆñ¤·¤¯¤¢¤ê¤Þ¤»¤ó¤¬¡¢ ¥×¥ì¥¤¥ó¥Æ¥­¥¹¥È¤Ç¤âÌäÂê¤Ï¤¢¤ê¤Þ¤»¤ó)¡£ FreeBSD ¤Îʸ½ñ¤ò¼«Ê¬¤ÎÊì¹ñ¸ì¤ËËÝÌõ¤¹¤ë¤Î¤ò¼êÅÁ¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ʸ½ñ¤¬¤¹¤Ç¤Ë¸ºß¤¹¤ì¤Ð¡¢¤â¤Ã¤Èʸ½ñ¤òËÝÌõ¤·¤¿¤ê¡¢ ¤½¤ÎËÝÌõ¤¬ºÇ¿·¤Î¾õÂÖ¤«¤É¤¦¤«³Îǧ¤¹¤ë¤Î¤ò¼êÅÁ¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤Þ¤º FreeBSD ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥×¥í¥¸¥§¥¯¥ÈÆþÌç¤Î ËÝÌõ¤Ë´Ø¤¹¤ë - FAQ (¤è¤¯¤¢¤ë¼ÁÌä¤È¤½¤ÎÅú¤¨) ¤ò°ìÆÉ¤·¤Æ¤¯¤À¤µ¤¤¡£ + FAQ (¤è¤¯¤¢¤ë¼ÁÌä¤È¤½¤ÎÅú¤¨) ¤ò°ìÆÉ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤È¤Ï¤¤¤Ã¤Æ¤â¡¢ ¤½¤¦¤¹¤ë¤³¤È¤Ë¤è¤Ã¤Æ¤¢¤Ê¤¿¤¬¤¹¤Ù¤Æ¤Î FreeBSD ʸ½ñ¤ÎËÝÌõ¤Ë·È¤ï¤ë¤è¤¦¤Ë¤Ê¤ë¤ï¤±¤Ç¤Ï¤Ê¤¤¤Ç¤¹¤«¤é¤Í¡£ — ¥Ü¥é¥ó¥Æ¥£¥¢¤È¤·¤Æ¡¢ ¿¾¯¤Ë´Ø¤ï¤é¤º¡¢¼«Ê¬¤¬¤ä¤í¤¦¤È»×¤¦¤À¤±¤ä¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤¤¤Ã¤¿¤ó狼¤¬ËÝÌõ¤ò»Ï¤á¤¿¤é¡¢ ¤¿¤¯¤µ¤ó¤Î¿Í㤬¤¤¤Ä¤À¤Ã¤Æ¶¨ÎϤ·¤Æ¤¯¤ì¤Þ¤¹¤«¤é¡£ ¤â¤·ËÝÌõ¤ËÈñ¤¹»þ´Ö¤ä¥¨¥Í¥ë¥®¡¼¤¬¸Â¤é¤ì¤Æ¤¤¤ë¤Ê¤é¡¢ ¤Þ¤º¥¤¥ó¥¹¥È¡¼¥ëÊýË¡¤ÎËÝÌõ¤«¤é¤ª´ê¤¤¤·¤Þ¤¹ (ÌõÃí: ¤Ê¤¼¤Ê¤é¡¢ ¤â¤Ã¤È¤âɬÍפȤµ¤ì¤Æ¤¤¤ëʸ½ñ¤¬¤½¤ì¤À¤«¤é¤Ç¤¹)¡£ ¤¿¤Þ¤Ë (¤â¤·¤¯¤ÏÄê´üŪ¤Ë) &a.questions; ¤ä &ng.misc; ¤òÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¤³¤ì¤Ï¡¢¤¢¤Ê¤¿¤Î»ý¤Ã¤Æ¤¤¤ëÀìÌçÃ챤ò¶¦Í­¤·¤¿¤ê¡¢ 狼¤¬Êú¤¨¤Æ¤¤¤ëÌäÂê¤ò²ò·è¤¹¤ë¤Î¤ËÈó¾ï¤ËÍ­¸ú¤Ê¤â¤Î¤Ë¤Ê¤êÆÀ¤ë¤³¤È¤Ç¤¹¡£ »þ¤Ë¤Ï¤¢¤Ê¤¿¼«¿È¤Ç¿·¤·¤¤¤³¤È¤ò³Ø¤Ö¤³¤È¤µ¤¨¤Ç¤­¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¤³¤ì¤é¤Î¥Õ¥©¡¼¥é¥à¤Ï¤ä¤ë¤Ù¤­¤³¤È¤Î¥¢¥¤¥Ç¥£¥¢¤Î¸»¤Ë¤â¤Ê¤êÆÀ¤ë¤Î¤Ç¤¹¡£ ¿Ê¹ÔÃæ¤Î¥×¥í¥°¥é¥Þ¸þ¤±¤Î²ÝÂê ¤³¤Î¥»¥¯¥·¥ç¥ó¤Çµó¤²¤ë²ÝÂê¤ÏËÄÂç¤Ê»þ´Ö¤ÎÅê»ñ¤Þ¤¿¤Ï FreeBSD ¤Î¥«¡¼¥Í¥ë¤Ë´Ø¤¹¤ë¿¼¤¤Ãμ±¡¢¤â¤·¤¯¤ÏξÊý¤òɬÍפȤ·¤Þ¤¹¡£ ¤·¤«¤·¤Ê¤¬¤é¡¢½µËö¥Ï¥Ã¥«¡¼ ¤ËŬ¤·¤¿Î©ÇɤʲÝÂê¤â¿ô¿¤¯¤¢¤ê¤Þ¤¹¡£ FreeBSD-CURRENT ¤ò±¿ÍѤ·¤Æ¤ª¤ê¡¢ ¾õÂÖ¤ÎÎɤ¤¥¤¥ó¥¿¡¼¥Í¥Ã¥ÈÀܳ¤¬¤¢¤ë¤Ê¤é¤Ð¡¢ current.FreeBSD.org ¤È¤¤¤¦°ìÆü¤Ë°ì²ó¥Õ¥ë¥ê¥ê¡¼¥¹¤ò¹Ô¤Ã¤Æ¤¤¤ë¥Þ¥·¥ó¤¬¤¢¤ê¤Þ¤¹ — »þ¤ª¤êºÇ¿·¤Î¥ê¥ê¡¼¥¹¤ò¤½¤³¤«¤é¥¤¥ó¥¹¥È¡¼¥ë¤·¡¢ ¤½¤Î²áÄø¤Ç²¿¤«ÌäÂ꤬¤¢¤ë¤Ê¤éÊó¹ð¤·¤Æ¤¯¤À¤µ¤¤¡£ &a.bugs; ¤òÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¤½¤³¤Ç¤Ï¤¢¤Ê¤¿¤¬·úÀßŪ¤Ê¥³¥á¥ó¥È¤òÉÕ¤±¤¿¤ê¥Æ¥¹¥È¤Ç¤­¤ë¥Ñ¥Ã¥Á¤¬Ä󶡤µ¤ì¤Æ¤¤¤ë¤è¤¦¤ÊÌäÂ꤬¤¢¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¤â¤·¤¯¤Ï¤½¤ì¤é¤ÎÌäÂê¤Î°ì¤Ä¤ò¤¢¤Ê¤¿¼«¿È¤Ç½¤Àµ¤¹¤ë¤³¤È¤µ¤¨¤Ç¤­¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¡£ -CURRENT ¤ËÀµ¤·¤¯Åö¤Æ¤é¤ì¤ë¤¬¤·¤Ð¤é¤¯·Ð¤Ã¤Æ¤â (Ä̾ï¤Ï 2, 3 ½µ´Ö) -STABLE ¤Ë¼è¤ê¹þ¤Þ¤ì¤Æ¤Ê¤¤¤è¤¦¤Ê¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤¬¤¢¤ë¤Ê¤é¤Ð¥³¥ß¥Ã¥¿¡¼¤ËÃúÇ«¤Ë»×¤¤½Ð¤µ¤»¤Æ¤¯¤À¤µ¤¤¡£ ´ó£¥½¥Õ¥È¥¦¥§¥¢¤ò¥½¡¼¥¹¥Ä¥ê¡¼¤Î src/contrib ¤Ë°Üư¤µ¤»¤Æ¤¯¤À¤µ¤¤¡£ src/contrib °Ê²¼¤Î¥³¡¼¥É¤¬ºÇ¿·¤Î¤â¤Î¤Ç¤¢¤ë¤«³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ·Ù¹ð¤ò¾ÜºÙ¤ËÊó¹ð¤¹¤ë¤è¤¦¤Ë¤·¤Æ¥½¡¼¥¹¥Ä¥ê¡¼Á´ÂÎ (¤â¤·¤¯¤Ï¤½¤Î°ìÉô) ¤ò¹½ÃÛ¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£ ¤½¤·¤Æ·Ù¹ð¤¬½Ð¤Ê¤¤¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ports ¤Ç¡¢gets() ¤ò»È¤Ã¤Æ¤¤¤ë¤È¤« malloc.h ¤ò¥¤¥ó¥¯¥ë¡¼¥É¤·¤Æ¤¤¤ë¤Ê¤É¤È¤¤¤Ã¤¿·Ù¹ð¤¬½Ð¤Ê¤¤¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤â¤·¤Ê¤ó¤é¤«¤Î ports ¤Ë´Ø¤ï¤Ã¤Æ¤¤¤Æ¡¢ &os; ¤Ë¸ÇÍ­¤ÎÊѹ¹¤¬É¬ÍפǤ¢¤ì¤Ð¡¢ ¤¢¤Ê¤¿¤Î¥Ñ¥Ã¥Á¤òºî¼Ô¤Ë¥Õ¥£¡¼¥É¥Ð¥Ã¥¯¤·¤Æ¤¯¤À¤µ¤¤ (¼¡¤Î¥Ð¡¼¥¸¥ç¥ó¤¬½Ð¤¿»þ¤Ë¤¢¤Ê¤¿¤¬³Ú¤Ë¤Ê¤ê¤Þ¤¹)¡£ - &posix; ¤Î¤è¤¦¤Ê¸ø¼°É¸½à¤Î¼Ì¤·¤òÆþ¼ê¤·¤Æ¤¯¤À¤µ¤¤¡£FreeBSD - C99 & POSIX ɸ½àŬ¹ç¥×¥í¥¸¥§¥¯¥È¤Î¥¦¥§¥Ö¥µ¥¤¥È¤Ë¡¢ - ¤½¤¦¤¤¤Ã¤¿É¸½à¤Ø¤Î¥ê¥ó¥¯¤¬¤¤¤¯¤Ä¤«¤¢¤ê¤Þ¤¹¡£ - FreeBSD ¤Îµóư¤òɸ½à¤¬Í׵᤹¤ë¤â¤Î¤ÈÈæ³Ó¤·¤Æ¤¯¤À¤µ¤¤¡£µóư¤¬°Û¤Ê¤ë¾ì¹ç¡¢ + &posix; ¤Î¤è¤¦¤Ê¸ø¼°É¸½à¤Î¼Ì¤·¤òÆþ¼ê¤·¤Æ¤¯¤À¤µ¤¤¡£ + FreeBSD + C99 & POSIX ɸ½àŬ¹ç¥×¥í¥¸¥§¥¯¥È + ¤Î¥¦¥§¥Ö¥µ¥¤¥È¤Ë¡¢¤½¤¦¤¤¤Ã¤¿É¸½à¤Ø¤Î¥ê¥ó¥¯¤¬¤¤¤¯¤Ä¤«¤¢¤ê¤Þ¤¹¡£ + FreeBSD ¤Îµóư¤òɸ½à¤¬Í׵᤹¤ë¤â¤Î¤ÈÈæ³Ó¤·¤Æ¤¯¤À¤µ¤¤¡£ + µóư¤¬°Û¤Ê¤ë¾ì¹ç¡¢ ÆÃ¤Ë¤½¤ì¤¬»ÅÍͤμè¤ë¤Ë­¤é¤Ê¤«¤Ã¤¿¤êʬ¤«¤ê¤Ë¤¯¤¤ºÙ¤«¤¤Éôʬ¤Ê¤é¡¢ ¾ã³²Êó¹ð¤òÄó½Ð¤·¤Æ¤¯¤À¤µ¤¤¡£¤Ç¤­¤ì¤Ð¤É¤¦½¤Àµ¤¹¤Ù¤­¤«ÌÀ¤é¤«¤Ë¤·¤Æ¡¢ ¾ã³²Êó¹ð¤Ë¥Ñ¥Ã¥Á¤ò¤Ä¤±¤Æ¤¯¤À¤µ¤¤¡£É¸½à¤¬´Ö°ã¤Ã¤Æ¤¤¤ë¤È´¶¤¸¤¿¤é¡¢ ɸ½à²½ÃÄÂΤˤ½¤Îµ¿Ìä¤òäý¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Î°ìÍ÷¤ËÄɲ乤ë²ÝÂê¤òÄ󰯤·¤Æ¤¯¤À¤µ¤¤! ¾ã³²Êó¹ð (PR; Problem Report) ¥Ç¡¼¥¿¥Ù¡¼¥¹¤Ë¤ª¤±¤ëºî¶È ¾ã³²Êó¹ð (PR) ¥Ç¡¼¥¿¥Ù¡¼¥¹ FreeBSD ¾ã³²Êó¹ð°ìÍ÷¤Ç¤Ï¡¢¸½ºßÌäÂê¤È¤Ê¤Ã¤Æ¤¤¤ë¾ã³²Êó¹ð¤È¡¢ FreeBSD ¤ÎÍøÍѼԤˤè¤Ã¤ÆÄó½Ð¤µ¤ì¤¿²þÎɤÎÍ×˾¤¹¤Ù¤Æ¤Î°ìÍ÷¤ò¸ø³«¤·¤Æ¤¤¤Þ¤¹¡£ ¾ã³²Êó¹ð¥Ç¡¼¥¿¥Ù¡¼¥¹¤Ë¤Ï¡¢ ¥×¥í¥°¥é¥Þ¸þ¤±¤ÈÈó¥×¥í¥°¥é¥Þ¸þ¤±¤Î²ÝÂ꤬¶¦¤Ë´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ open ¾õÂ֤ξ㳲Êó¹ð¤ò¸«¤Æ¡¢¶½Ì£¤ò°ú¤¯¤â¤Î¤¬¤¢¤ë¤«³Î¤«¤á¤Æ¤¯¤À¤µ¤¤¡£ ¤Ê¤«¤Ë¤Ï¡¢¾ã³²Êó¹ð¤ËÂФ¹¤ë½¤Àµ¤¬Å¬Àڤʤâ¤Î¤Ç¤¢¤ë¤«¤É¤¦¤«Ã±¤Ë¥Á¥§¥Ã¥¯¤¹¤ë¤À¤±¤Î¤È¤Æ¤â´Êñ¤Êºî¶È¤â¤¢¤ë¤Ç¤·¤ç¤¦¤·¡¢ ¤º¤Ã¤ÈÊ£»¨¤Ê¤â¤Î¤ä¡¢½¤Àµ¤¬´Þ¤Þ¤ì¤Æ¤¹¤é¤¤¤Ê¤¤¤â¤Î¤â¤¢¤ë¤Ç¤·¤ç¤¦¡£ ¤Þ¤º¡¢¤Þ¤Àï¤Ë¤â³ä¤êÅö¤Æ¤é¤ì¤Æ¤¤¤Ê¤¤¾ã³²Êó¹ð¤«¤éºî¶È¤ò»Ï¤á¤Æ¤¯¤À¤µ¤¤¡£ ¤â¤·¡¢Ã¯¤«Â¾¤Î¿Í¤Ë³ä¤êÅö¤Æ¤¬·è¤Þ¤Ã¤Æ¤¤¤ë¤±¤ì¤É¤â¼«Ê¬¤¬ºî¶È²Äǽ¤À¡¢ ¤È¤¤¤¦¾ã³²Êó¹ð¤¬¤¢¤ì¤Ð¡¢ºî¶È¤¬¤Ç¤­¤ë¤«¤É¤¦¤«¡¢ ³ä¤êÅö¤Æ¤é¤ì¤Æ¤¤¤ë¿Í¤ËÅŻҥ᡼¥ë¤ÇÌ䤤¹ç¤ï¤»¤Æ¤¯¤À¤µ¤¤¡£— ´û¤Ë¥Æ¥¹¥ÈÍѥѥåÁ¤¬ÍѰդµ¤ì¤Æ¤¤¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¤·¡¢ ¤è¤ê¿Ê¤ó¤À¹Í¤¨¤Ë´Ø¤·¤ÆµÄÏÀ¤¬¤Ç¤­¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¡£ <quote>¥¢¥¤¥Ç¥£¥¢</quote>¥Ú¡¼¥¸¤Î¹àÌÜ &os; ¥×¥í¥¸¥§¥¯¥È¤Ë¹×¸¥¤·¤¿¤¤¿Í¤Î¤¿¤á¤Ë ¥Ü¥é¥ó¥Æ¥£¥¢¤Î¤¿¤á¤Î &os; ¤Î¥×¥í¥¸¥§¥¯¥È¤È¥¢¥¤¥Ç¥£¥¢°ìÍ÷ ¤âÍѰդµ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤³¤Î°ìÍ÷¤Ï¾ï¤Ë¹¹¿·¤µ¤ì³¤±¤Æ¤ª¤ê¡¢¤½¤ì¤¾¤ì¤Î¥×¥í¥¸¥§¥¯¥È¤Ë¤Ä¤¤¤Æ¡¢ ¥×¥í¥°¥é¥Þ¤ÈÈó¥×¥í¥°¥é¥ÞξÊý¤Ë¸þ¤±¤¿¹àÌܤ¬¤¢¤ê¤Þ¤¹¡£ ¹×¸¥¤Î»ÅÊý °ìÈÌŪ¤Ë¡¢¥·¥¹¥Æ¥à¤Ø¤Î¹×¸¥¤Ï¼¡¤Î 5 ¤Ä¤Î¥«¥Æ¥´¥ê¤Î 1 ¤Ä°Ê¾å¤ËʬÎव¤ì¤Þ¤¹: ¥Ð¥°Êó¹ð¤È°ìÈÌŪ¤ÊÏÀɾ °ìÈÌŪ¤Êµ»½ÑŪ´Ø¿´»ö¤Ë´Ø¤¹¤ë¥¢¥¤¥Ç¥¢¤äÄó°Æ¤Ï &a.hackers; ¤Ø¥á¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£Æ±Íͤˡ¢¤³¤Î¤è¤¦¤Ê»öÊÁ¤Ë¶½Ì£¤Î¤¢¤ë (¤½¤·¤ÆËÄÂç¤Ê¥á¡¼¥ë! ¤ËÂѤ¨¤é¤ì¤ë) ¿Í¤Ï¡¢ &a.hackers; ¤Ë»²²Ã¤¹¤ë¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£ ¤³¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ä¾¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë´Ø¤¹¤ë¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï FreeBSD ¥Ï¥ó¥É¥Ö¥Ã¥¯¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥Ð¥°¤òȯ¸«¤·¤¿¤êÊѹ¹¤òÁ÷ÉÕ¤·¤è¤¦¤È¤·¤Æ¤¤¤ë¾ì¹ç¤Ï &man.send-pr.1; ¥×¥í¥°¥é¥à¤« ¥¦¥§¥Ö¥Ù¡¼¥¹¤Î send-pr ¤ò»ÈÍѤ·¤ÆÊó¹ð¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥Ð¥°¥ì¥Ý¡¼¥È¤Î³Æ¹àÌܤòËä¤á¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£65KB ¤òͤ¨¤ë¤Î¤Ç¤Ê¤±¤ì¤Ð¡¢ ¥ì¥Ý¡¼¥ÈÃæ¤ËľÀܥѥåÁ¤òÆþ¤ì¤Æ¤¯¤À¤µ¤Ã¤Æ·ë¹½¤Ç¤¹¡£ ¥Ñ¥Ã¥Á¤¬¥½¡¼¥¹¥Ä¥ê¡¼¤Ë¤¹¤°Å¬ÍѤǤ­¤ë¤â¤Î¤Ê¤é¤Ð¡¢ Êó¹ð¤Î³µÍ×¤Ë [PATCH] ¤È½ñ¤¤¤Æ¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£ ¥Ñ¥Ã¥Á¤òÆþ¤ì¤ë¾ì¹ç¡¢¥«¥Ã¥È&¥Ú¡¼¥¹¥È¤Ï¤·¤Ê¤¤¤Ç ¤¯¤À¤µ¤¤¡£ ¥«¥Ã¥È&¥Ú¡¼¥¹¥È¤Ç¤Ï¥¿¥Ö¤¬¥¹¥Ú¡¼¥¹¤ËŸ³«¤µ¤ì¤Æ¥Ñ¥Ã¥Á¤¬»È¤¤Êª¤Ë¤Ê¤é¤Ê¤¯¤Ê¤Ã¤Æ¤·¤Þ¤¤¤Þ¤¹¡£ ¥Ñ¥Ã¥Á¤¬ 20KB ¤òͤ¨¤ë¾ì¹ç¤Ï¡¢ ¤½¤ì¤é¤ò (&man.gzip.1; ¤ä &man.bzip2.1; ¤Ç) °µ½Ì¤·¡¢ °µ½Ì¤·¤¿¥Ñ¥Ã¥Á¤ò &man.uuencode.1; ¤ò»È¤Ã¤Æ¥Ð¥°Êó¹ð¤Ë´Þ¤á¤ë¤³¤È¤â¸¡Æ¤¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥ì¥Ý¡¼¥È¤¬¥Õ¥¡¥¤¥ê¥ó¥°¤µ¤ì¤ì¤Ð¡¢ ¥Ð¥°Êó¹ð¤Î³Îǧ¤È¥È¥é¥Ã¥­¥ó¥°ÈÖ¹æ¤ò¥á¡¼¥ë¤Ç¼õ¤±¼è¤ë¤Ï¤º¤Ç¤¹¡£ ¤³¤Î¥È¥é¥Ã¥­¥ó¥°ÈÖ¹æ¤ò³Ð¤¨¤Æ¤ª¤­¡¢ÌäÂê¤Ë´Ø¤¹¤ë¾ÜºÙ¾ðÊó¤ò &a.bugfollowup; ¤Ë¥á¡¼¥ë¤ÇÁ÷¤Ã¤Æ¹¹¿·¤Ç¤­¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£¤¿¤È¤¨¤Ð "Re: kern/3377" ¤Î¤è¤¦¤Ë¡¢ ¤³¤ÎÈÖ¹æ¤ò¥µ¥Ö¥¸¥§¥¯¥È¹Ô¤Ë»ÈÍѤ·¤Æ¤¯¤À¤µ¤¤¡£ ¤¹¤Ù¤Æ¤Î¥Ð¥°¥ì¥Ý¡¼¥È¤ÎÄɲþðÊó¤Ï¡¢ ¤³¤ÎÊýË¡¤ÇÁ÷ÉÕ¤µ¤ì¤Ê¤±¤ì¤Ð¤¤¤±¤Þ¤»¤ó¡£ ¤â¤·¥¿¥¤¥à¥ê¡¼¤Ë (¤¢¤Ê¤¿¤ÎÅŻҥ᡼¥ëÀܳ·ÁÂ֤ˤâ¤è¤ê¤Þ¤¹¤¬¡¢ 3 Æü¤«¤é 1 ½µ´Ö) ³Îǧ¤ò¼õ¤±¤È¤ì¤Ê¤¤¤È¤«¡¢²¿¤é¤«¤ÎÍýͳ¤Ç &man.send-pr.1; ¥³¥Þ¥ó¥É¤¬»ÈÍѤǤ­¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢&a.bugs; ¤Ø¥á¡¼¥ë¤òÁ÷¤ê¡¢ 狼Âå¤ê¤Ë¥Ð¥°Êó¹ð¤òÁ÷ÉÕ¤·¤Æ¤â¤é¤¦¤è¤¦¤¿¤º¤Í¤Æ¤¯¤À¤µ¤¤¡£ - Îɤ¤¾ã³²Êó¹ð¤ò½ñ¤¯ÊýË¡¤Ë¤Ä¤¤¤Æ¤Ï¤³¤Îʸ½ñ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ + Îɤ¤¾ã³²Êó¹ð¤ò½ñ¤¯ÊýË¡¤Ë¤Ä¤¤¤Æ¤Ï ¤³¤Îʸ½ñ + ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ʸ½ñ¤ÎÊѹ¹ ʸ½ñ¤Ë´Ø¤¹¤ëÄó°Æ Ê¸½ñ¤ÎÊѹ¹¤Ï &a.doc; ¤¬´ÆÆÄ¤·¤Æ¤¤¤Þ¤¹¡£ ´°Á´¤ÊÀâÌÀ¤Ï¡¢FreeBSD ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥×¥í¥¸¥§¥¯¥ÈÆþÌç¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ¥Ð¥°Êó¹ð¤È°ìÈÌŪ¤ÊÏÀɾ ¤Ëµ­½Ò¤µ¤ì¤Æ¤¤¤ë¤è¤¦¤Ë &man.send-pr.1; ¥³¥Þ¥ó¥É¤ò»ÈÍѤ·¤Æ¡¢Ä󰯤äÊѹ¹ (¤É¤ó¤Êº³ºÙ¤Ê¤â¤Î¤Ç¤â´¿·Þ¤·¤Þ¤¹!) ¤òÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¸½Â¸¤Î¥½¡¼¥¹¥³¡¼¥É¤ÎÊѹ¹ FreeBSD-CURRENT ¸½Â¸¤Î¥½¡¼¥¹¥³¡¼¥É¤Ø¤ÎÄɲäޤ¿¤ÏÊѹ¹¤Ï¡¢ ¤¤¤¯¤é¤«¥È¥ê¥Ã¥­¡¼¤Ê»Å»ö¤Ç¤¢¤ê¡¢FreeBSD ³«È¯¤Î¸½¾õ¤Ë¤¢¤Ê¤¿¤¬¤É¤ì¤À¤±Ä̤¸¤Æ¤¤¤ë¤«¤ËÂ礭¤¯°Í¸¤·¤Þ¤¹¡£ FreeBSD-CURRENT ¤È¤·¤ÆÃΤé¤ì¤ë FreeBSD ¤ÎÆÃÊ̤ʷÑ³Ū¥ê¥ê¡¼¥¹¤¬¤¢¤ê¤Þ¤¹¡£FreeBSD-CURRENT ¤Ï³«È¯¼Ô¤ÎÀѶËŪ¤Ê³èư¤ÎÊØµ¹¤Î¤¿¤á¤Ë¡¢ ¿§¡¹¤ÊÊýË¡¤ÇÍøÍѲÄǽ¤Ë¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£FreeBSD-CURRENT - ¤ÎÆþ¼ê¤È»ÈÍÑÊýË¡¤Ë¤Ä¤¤¤Æ¤Î¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤ÏFreeBSD ¥Ï¥ó¥É¥Ö¥Ã¥¯ - ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ + ¤ÎÆþ¼ê¤È»ÈÍÑÊýË¡¤Ë¤Ä¤¤¤Æ¤Î¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï FreeBSD + ¥Ï¥ó¥É¥Ö¥Ã¥¯ ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¸Å¤¤¥½¡¼¥¹¤ò¤â¤È¤Ëºî¶È¤¹¤ë¤È¡¢ »Äǰ¤Ê¤¬¤é¤¢¤Ê¤¿¤ÎÊѹ¹¤¬»þ¤È¤·¤Æ»þÂåÃÙ¤ì¤â¤·¤¯¤ÏÂ礭¤¯°Û¤Ê¤ë¤â¤Î¤Ë¤Ê¤Ã¤Æ¤·¤Þ¤Ã¤Æ¡¢ FreeBSD ¤ËºÆÅý¹ç¤¹¤ë¤Î¤Ïº¤Æñ¤Ë¤Ê¤ë¶²¤ì¤¬¤¢¤ê¤Þ¤¹¡£ ¥·¥¹¥Æ¥à¤Î¸½¾õ¤Ë´Ø¤¹¤ëµÄÏÀ¤¬¤ª¤³¤Ê¤ï¤ì¤Æ¤¤¤ë &a.announce; ¤È &a.current; ¤Ø»²²Ã¤¹¤ì¤Ð¡¢¤³¤Î²ÄǽÀ­¤òºÇ¾®¸Â¤Ë¤Ç¤­¤Þ¤¹¡£ ½½Ê¬¿·¤·¤¤¥½¡¼¥¹¤òÊѹ¹¤Î¥Ù¡¼¥¹¤Ë¤Ç¤­¤ë¤³¤È¤¬³Î¼Â¤Ë¤Ê¤Ã¤¿¤È²¾Äꤷ¤Æ¡¢ ¼¡¤Î¥¹¥Æ¥Ã¥×¤Ï FreeBSD ¤ÎÊݼéôÅö¼Ô¤ØÁ÷¤ëº¹Ê¬¥Õ¥¡¥¤¥ë¤ÎÀ¸À®¤Ç¤¹¡£¤³¤ì¤Ï &man.diff.1; ¥³¥Þ¥ó¥É¤ò»ÈÍѤ·¤Æ¤ª¤³¤Ê¤¤¤Þ¤¹¡£ º¹Ê¬¥Õ¥¡¥¤¥ë¤ÎÄó½Ð¤Ë¤ª¤¤¤Æ¹¥¤Þ¤·¤¤ &man.diff.1; ¤Î·Á¼°¤Ï¡¢ diff -u ¤Ë¤è¤êÀ¸À®¤µ¤ì¤ë unified diff ·Á¼°¤Ç¤¹¡£ diff &prompt.user; diff -u oldfile newfile ¤Þ¤¿¤Ï¡¢ &prompt.user; diff -u -r -N olddir newdir ¤Ç¡¢»ØÄꤵ¤ì¤¿¥½¡¼¥¹¥Õ¥¡¥¤¥ë¤Þ¤¿¤Ï¥Ç¥£¥ì¥¯¥È¥ê³¬ÁؤËÂФ¹¤ë unified diff ·Á¼°¤Îº¹Ê¬¤¬À¸À®¤µ¤ì¤Þ¤¹¡£ ¾Ü¤·¤¤ÀâÌÀ¤Ï &man.diff.1; ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ º¹Ê¬¥Õ¥¡¥¤¥ë (&man.patch.1; ¥³¥Þ¥ó¥É¤Ç¥Æ¥¹¥È¤Ç¤­¤Þ¤¹) ¤òºî¤Ã¤¿¤é¡¢¤½¤ì¤é¤ò FreeBSD ¤Ë´Þ¤á¤Æ¤â¤é¤¦¤è¤¦¥á¡¼¥ë¤ÇÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£¥Ð¥°Êó¹ð¤È°ìÈÌŪ¤ÊÏÀɾ ¤Ëµ­½Ò¤µ¤ì¤Æ¤¤¤ë¤è¤¦¤Ë &man.send-pr.1; ¥³¥Þ¥ó¥É¤ò»ÈÍѤ·¤Æ¤¯¤À¤µ¤¤¡£º¹Ê¬¥Õ¥¡¥¤¥ë¤À¤±¤ò &a.hackers; ¤ØÁ÷¤Ã¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£¸«²á¤´¤µ¤ì¤Æ¤·¤Þ¤¦¤Ç¤·¤ç¤¦¡£ ¤¢¤Ê¤¿¤ÎÄ󰯤ÏÂç´¿·Þ¤Ç¤¹ (¤³¤ì¤Ï¥Ü¥é¥ó¥Æ¥£¥¢¤Î¥×¥í¥¸¥§¥¯¥È¤Ç¤¹!)¡£ »ä¤¿¤Á¤Ï¿˻¤Ê¤Î¤Ç¤¹¤°¤Ë¼è¤ê¤«¤«¤ì¤Ê¤¤¤«¤â¤·¤ì¤Þ¤»¤ó¤¬¡¢ ¤½¤ì¤Þ¤Ç PR ¥Ç¡¼¥¿¥Ù¡¼¥¹¤Ë»Ä¤Ã¤Æ¤¤¤ë¤Ç¤·¤ç¤¦¡£ Êó¹ð¤Î³µÍ×¤Ë [PATCH] ¤È½ñ¤¤¤Æ¤¢¤Ê¤¿¤ÎÄ󰯤òɽÌÀ¤·¤Æ¤¯¤À¤µ¤¤¡£ uuencode ¤¢¤Ê¤¿¤¬¤½¤¦¤·¤¿Êý¤¬¤¤¤¤¤È»×¤¦¾ì¹ç (¤¿¤È¤¨¤Ð¡¢ ¥Õ¥¡¥¤¥ë¤ÎÄɲᢺï½ü¤Þ¤¿¤Ï̾¾ÎÊѹ¹¤Ê¤É)¡¢Êѹ¹¤ò tar ¥Õ¥¡¥¤¥ë¤Ë¤Þ¤È¤á¡¢&man.uuencode.1; ¥×¥í¥°¥é¥à¤Ë¤«¤±¤Æ¤¯¤À¤µ¤¤¡£&man.shar.1; ¥¢¡¼¥«¥¤¥Ö¤â´¿·Þ¤·¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð¡¢ºÆÇÛÉÛ¤ËŬÍѤµ¤ì¤ëÃøºî¸¢¤ÎÌäÂê¤Ë¼«¿®¤¬¤Ê¤¤¤È¤¤¤Ã¤¿¡¢ ¤¢¤Ê¤¿¤ÎÊѹ¹¤¬Èù̯¤ÊÀ­¼Á¤Î¤â¤Î¤Ç¤¢¤ë²ÄǽÀ­¤¬¤¢¤ì¤Ð¡¢ &man.send-pr.1; ¤ÇÄó½Ð¤¹¤ë¤è¤ê¤à¤·¤íľÀÜ &a.core; ¤ØÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£&a.core; °¸¤Î¥á¡¼¥ë¤Ï¡¢ Æü¡¹¤Î»Å»ö¤Î¤«¤Ê¤ê¤Î³ä¹ç¤ò FreeBSD ¤Ë³ä¤¤¤Æ¤¤¤ë¿Í¤¿¤Á¤Î¡¢ ¤è¤ê¾®¤µ¤Ê¥°¥ë¡¼¥×¤ËÆÏ¤­¤Þ¤¹¡£ ¤³¤Î¥°¥ë¡¼¥×¤â¤Þ¤¿¤È¤Æ¤âË»¤·¤¤¤³¤È¤ËÃí°Õ¤·¤Æ¡¢ ËÜÅö¤ËɬÍפʾì¹ç¤À¤±¥³¥¢¥Á¡¼¥à¤Ë¥á¡¼¥ë¤òÁ÷¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥³¡¼¥Ç¥£¥ó¥°¥¹¥¿¥¤¥ë¤Ë´Ø¤·¤Æ &man.intro.9; ¤ª¤è¤Ó &man.style.9; ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£¥³¡¼¥É¤òÄó½Ð¤¹¤ëÁ°¤Ë¤Ï¡¢ ¾¯¤Ê¤¯¤È¤â¤³¤Î¾ðÊó¤ò°Õ¼±¤·¤Æ¤ª¤¤¤Æ¤¯¤À¤µ¤ë¤è¤¦¤ª´ê¤¤¤·¤Þ¤¹¡£ ¿·¤¿¤Ê¥³¡¼¥É¤ä¤­¤ï¤á¤ÆÉղòÁÃͤι⤤¥Ñ¥Ã¥±¡¼¥¸ Â礭¤ÊʬÎ̤κî¶ÈÀ®²Ì¤Î¹×¸¥¤ä¡¢½ÅÍפʿ·¤·¤¤µ¡Ç½¤ò FreeBSD ¤ËÄɲ乤ë¾ì¹ç¤Ë¤Ï¡¢ÂçÄñ¡¢Êѹ¹ÅÀ¤ò tar ¥Õ¥¡¥¤¥ë¤Ë¤Þ¤È¤á¤Æ uuencode ¤·¤ÆÁ÷¤ë¤«¡¢¥¦¥§¥Ö¥µ¥¤¥È¤ä FTP ¥µ¥¤¥È¤Ø¥¢¥Ã¥×¥í¡¼¥É¤·¤Æ¥¢¥¯¥»¥¹¤Ç¤­¤ë¤è¤¦¤Ë¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ web ¤ä FTP ¥µ¥¤¥È¤¬ÍøÍѤǤ­¤Ê¤±¤ì¤Ð¡¢Å¬ÀÚ¤Ê FreeBSD ¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ç狼¤½¤ÎÊѹ¹¤ò¤ª¤¯¥µ¥¤¥È¤òÄ󶡤·¤Æ¤¯¤ì¤ë¤è¤¦Íê¤ó¤Ç¤¯¤À¤µ¤¤¡£ ÂçÎ̤Υ³¡¼¥É¤ò°·¤Ã¤Æ¤¤¤ë»þ¤Ï¡¢ ¾ï¤ËÃøºî¸¢¤Ë´Ø¤¹¤ëÈù̯¤ÊÌäÂ꤬½Ð¤Æ¤­¤Þ¤¹¡£ FreeBSD ¤Ë´Þ¤á¤ë¥³¡¼¥É¤ÎÃøºî¸¢¤È¤·¤Æ¼õ¤±Æþ¤ì¤ë¤³¤È¤¬¤Ç¤­¤ë¤Î¤Ï¡¢ °Ê²¼¤ÎÆó¤Ä¤Ç¤¹¡£ - BSD copyright - BSD ¥³¥Ô¡¼¥é¥¤¥È¡£ + BSD ¥³¥Ô¡¼¥é¥¤¥È BSD + ¥³¥Ô¡¼¥é¥¤¥È +¡£ ¤³¤Î¥³¥Ô¡¼¥é¥¤¥È¤Ï ¸¢Íø¤ËÇû¤é¤ì¤Ê¤¤ À­³Ê¤È¾¦ÍÑ´ë¶È¤Ë¤È¤Ã¤Æ°ìÈÌŪ¤ÊÌ¥ÎϤò¤â¤Ä¤¿¤á¤ËºÇ¤â¹¥¤Þ¤ì¤Þ¤¹¡£ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ï¾¦ÍÑÍøÍѤòÁˤó¤À¤ê¤»¤º¡¢²¿¤«¤ò FreeBSD ¤ØÅê»ñ¤¹¤ëµ¤¤Ë¤Ê¤Ã¤¿¾¦¶È´Ø·¸¼Ô¤Ë¤è¤ë»²²Ã¤òÀѶËŪ¤Ë¾©Î夷¤Þ¤¹¡£ - - GPL - GNU General Public License - + + + GPL + GNU General Public License + - - GNU General Public License - + + GNU General Public License + - GNU°ìÈ̸øÍ­»ÈÍѵöÂú¡¢¤Þ¤¿¤Ï GPL¡£ + GNU°ìÈ̸øÍ­»ÈÍѵöÂú¡¢¤Þ¤¿¤Ï GPL¡£ ¤³¤Î¥é¥¤¥»¥ó¥¹¤Ï¥³¡¼¥É¤ò¾¦ÍÑÌÜŪ¤Ë»ÈÍѤ¹¤ë¾ì¹ç¤Ë;ʬ¤ÊÅØÎϤ¬µá¤á¤é¤ì¤ë¤¿¤á¡¢ »ä¤¿¤Á¤Ë¤¢¤Þ¤êɾȽ¤¬Îɤ¤¤È¤¤¤¦¤ï¤±¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£¤·¤«¤·¡¢ »ä¤¿¤Á¤Ï´û¤Ë GPL ²¼¤Î¹âÉʼÁ¤Ê¥³¡¼¥É (¥³¥ó¥Ñ¥¤¥é¡¢¥¢¥»¥ó¥Ö¥é¡¢¥Æ¥­¥¹¥È¥Õ¥©¡¼¥Þ¥Ã¥¿Åù) ¤ÎÄ󶡤ò¼õ¤±¤Æ¤ª¤ê¡¢»ä¤¿¤Á¤Ï¸½ºß¤½¤ì¤òɬÍפȤ·¤Æ¤¤¤Þ¤¹¡£¤½¤Î¤¿¤á¡¢ ¤³¤Î¥é¥¤¥»¥ó¥¹¤Ë¤è¤ë¿·¤¿¤Ê¹×¸¥¤òµñÀ䤹¤ë¤È¤¤¤¦¤Î¤Ï¶ò¤«¤Ê¤³¤È¤Ç¤·¤ç¤¦¡£GPL ²¼¤Î¥³¡¼¥É¤Ï¥½¡¼¥¹¥Ä¥ê¡¼¤ÎÊ̤ÎÉôʬ¡¢¸½ºß¤Î¤È¤³¤í /sys/gnu ¤« /usr/src/gnu ¤ËÆþ¤Ã¤Æ¤¤¤Þ¤¹¡£ ¤½¤Î¤¿¤á¡¢GPL ¤¬ÌäÂê¤È¤Ê¤ë¤è¤¦¤Ê¿Í¤Ï¡¢ ï¤Ç¤â´Êñ¤Ë¤½¤ì¤È¤ï¤«¤ë¤è¤¦¤Ë¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£ ¤³¤ì°Ê³°¤Î¥¿¥¤¥×¤ÎÃøºî¸¢¤Ë¤è¤ë´ó£¤Ï¡¢FreeBSD ¤Ø´Þ¤á¤ë¤³¤È¤ò¹Íθ¤¹¤ëÁ°¤ËÃí°Õ¿¼¤¤¥ì¥Ó¥å¡¼¤ò¼õ¤±¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ÆÃ¤Ë¸ÂÄêŪ¤Ê¾¦ÍѤÎÃøºî¸¢¤¬Å¬ÍѤµ¤ì¤ë´ó£¤Ï°ìÈ̤˵ñÈݤµ¤ì¤Þ¤¹¡£¤·¤«¤·¡¢ ºî¼Ô¤¬ÆÈ¼«¤Î·ÐÏ©¤Ç¤½¤Î¤è¤¦¤ÊÊѹ¹¤òÇÛÉÛ¤¹¤ë¤³¤È¤Ï¾ï¤Ë¾©Î夵¤ì¤Æ¤¤¤Þ¤¹¡£ ¤¢¤Ê¤¿¤ÎºîÉÊ¤Ë BSD ¥¹¥¿¥¤¥ë ¤ÎÃøºî¸¢¤òÉÕ¤±¤ë¤Ë¤Ï¡¢ Êݸ¤¿¤¤¥½¡¼¥¹¥³¡¼¥É¥Õ¥¡¥¤¥ë¤¹¤Ù¤Æ¤Î°ìÈֺǽé¤Ë°Ê²¼¤Î¥Æ¥­¥¹¥È¤òÆþ¤ì¤Æ¡¢ %% ¤Î´Ö¤òŬÀڤʾðÊó¤ËÃÖ¤­´¹¤¨¤Æ¤¯¤À¤µ¤¤¡£ Copyright (c) %%ŬÀÚ¤Êǯ%% %%¤¢¤Ê¤¿¤Î̾Á°%%, %%¤¢¤Ê¤¿¤Î½£%% %%Í¹ÊØÈÖ¹æ%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%¤¢¤Ê¤¿¤Î̾Á°%% ``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 %%¤¢¤Ê¤¿¤Î̾Á°%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $&os;$ ÊØµ¹¤ò¤Ï¤«¤ë¤¿¤á¡¢ ¤³¤Î¥Æ¥­¥¹¥È¤Î¥³¥Ô¡¼¤Ï¼¡¤Î¾ì½ê¤ËÃÖ¤¤¤Æ¤¢¤ê¤Þ¤¹¡£ /usr/share/examples/etc/bsd-style-copyright ÌõÃí °Ê²¼¤Ï¿ÀÅÄÉÒ¹­»á¤è¤ê´ó£¤µ¤ì¤¿ bsd-style-copyright ¤ÎÆüËܸìÌõ¤Ç¤¹¡£ ¥½¡¼¥¹¥Õ¥¡¥¤¥ë¤Ë´Þ¤á¤ë¤â¤Î¤Ï¸¶Ê¸¤ÎÊý¤Ç¤¢¤ë¤³¤È¤ËÃí°Õ¤·¤Æ¤´ÍøÍѤ¯¤À¤µ¤¤¡£ ¤Þ¤¿¡¢¸¶Ê¸¤È¤Î´Ö¤Ë¼ñ»Ý¤Îº¹°Û¤¬À¸¤¸¤¿¾ì¹ç¡¢ ¸¶Ê¸¤ÎÆâÍÆ¤¬ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Î°Õ»×¤Ç¤¢¤ë¤â¤Î¤È¤·¤Þ¤¹¡£ Copyright (C) [ǯ] [¤¢¤Ê¤¿¤Î̾Á°] All rights reserved. ¥½¡¼¥¹¤È¥Ð¥¤¥Ê¥ê·Á¼°¤ÎºÆÇÛÉÛ¤ª¤è¤Ó»ÈÍѤϡ¢Êѹ¹¤Î̵ͭ¤Ë¤«¤«¤ï¤é¤º°Ê²¼¤Î ¾ò·ï¤òËþ¤¿¤¹¾ì¹ç¤Ë¸Â¤êµö²Ä¤µ¤ì¤ë: 1. ¥½¡¼¥¹¥³¡¼¥É¤ÎºÆÇÛÉۤϡ¢¾åµ­¤ÎÃøºî¸¢É½¼¨¡¦¤³¤Î¾ò·ï¤Î¥ê¥¹¥È¡¦²¼µ­¤Î ÈÝǧÀ¼ÌÀʸ¤òÊÝ»ý¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¡£ 2. ¥Ð¥¤¥Ê¥ê·Á¼°¤ÎºÆÇÛÉۤϾ嵭¤ÎÃøºî¸¢É½¼¨¡¦¤³¤Î¾ò·ï¤Î¥ê¥¹¥È¡¦²¼µ­¤Î ÈÝǧÀ¼ÌÀʸ¤ò¡¢ÇÛÉÛʪ¤È¶¦¤ËÄ󶡤µ¤ì¤ëʸ½ñ¤ª¤è¤Ó/¤Þ¤¿¤Ï¾¤Î»ñÎÁ¤ÎÃæ¤Ë ´Þ¤á¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¡£ (ÌõÃí:¤³¤³¤«¤é¡ÖÈÝǧÀ¼ÌÀʸ¡×¤Ç¤¹) ¤³¤Î¥½¥Õ¥È¥¦¥§¥¢¤Ï[¤¢¤Ê¤¿¤Î̾Á°]¤ª¤è¤Ó¹×¸¥¼Ô¤Ë¤è¤Ã¤Æ ``¤¢¤ë¤¬¤Þ¤Þ¤Î¾õÂÖ'' ¤ÇÄ󶡤µ¤ì¡¢¾¦ÉÊÀ­¤ÈÆÃÄê¤ÎÌÜŪ¤ËÂФ¹¤ëŬ¹çÀ­¤Ë¤Ä¤¤¤Æ¤Î°ÅÌÛ¤ÎÊݾڤËα¤Þ ¤é¤º¡¢¤¤¤«¤Ê¤ëÌÀ¼¨¤ª¤è¤Ó°ÅÌÛ¤ÎÊݾڤòǧ¤á¤Ê¤¤¡£[¤¢¤Ê¤¿¤Î̾Á°]¤ª¤è¤Ó¹×¸¥ ¼Ô¤Ï¡¢¤¢¤é¤æ¤ëľÀÜŪ¡¦´ÖÀÜŪ¡¦¶öȯŪ¡¦ÆÃ¼ìŪ¡¦Åµ·¿Åª¡¦É¬Á³Åª¤Ê»³² (Âå ÂØÀ½Éʤޤ¿¤ÏÂåÂØ¥µ¡¼¥Ó¥¹¤Î³ÍÆÀÈñ; ¸úÍÑ¡¦¥Ç¡¼¥¿¡¦Íø±×¤ÎÁÓ¼º; ¤Þ¤¿¤Ï¶È̳ ÃæÃǤò´Þ¤ß¡¢¤Þ¤¿¤½¤ì¤À¤±¤Ëα¤Þ¤é¤Ê¤¤Â»³²) ¤ËÂФ·¤Æ¡¢¤¿¤È¤¨¤É¤Î¤è¤¦¤Ë¤· ¤ÆÀ¸¤¸¤¿¤È¤·¤Æ¤â¡¢¤½¤·¤Æ¤³¤Î¥½¥Õ¥È¥¦¥§¥¢¤Î»ÈÍѤˤè¤Ã¤Æ¤É¤Î¤è¤¦¤Ë¤Ç¤¢¤ì À¸¤¸¤ë¡¢·ÀÌó¾å¤Ç¤¢¤í¤¦¤È¡¢¸·Ì©¤ÊÀÕǤÆâ¤Ç¤¢¤í¤¦¤È¡¢¤¢¤ë¤¤¤ÏÉÔÀµ¹Ô°Ù (²á ¼º¤ä¤½¤¦¤Ç¤Ê¤¤¾ì¹ç¤ò´Þ¤à) ¤Ë¤ª¤±¤ë¾ì¹ç¤Ç¤¢¤í¤¦¤È¤â¡¢¤¤¤«¤Ê¤ëÀÕǤÏÀ¾å¤â¡¢ ¤¿¤È¤¨¤½¤Î¤è¤¦¤Ê»³²¤Î²ÄǽÀ­¤¬Í½¸«¤µ¤ì¤Æ¤¤¤¿¤È¤·¤Æ¤â¡¢°ìÀÚ¤ÎÀÕǤ¤ò»ý¤¿ ¤Ê¤¤¡£ ËÝÌõ: ¿ÀÅÄÉÒ¹­ ¸æ¶¨ÎÏ (¸Þ½½²»½ç¡¦·É¾Îά): ÃÓÅĸ¦Æó¡¢ÆâÀî ´î¾Ï¡¢Æ£Â¼ ±Ñ¼£¡¢¤à¤é¤¿¤·¤å¤¦¤¤¤Á¤í¤¦ ÌÝÌî ²í°ì¡¢²£ÅÄ¡÷±§Å﵆ ¶âÁ¬¡¢¥Ï¡¼¥É¥¦¥§¥¢¤Þ¤¿¤Ï¥¤¥ó¥¿¡¼¥Í¥Ã¥È¥¢¥¯¥»¥¹ »ä¤¿¤Á¤Ï FreeBSD ¥×¥í¥¸¥§¥¯¥È¤ÎÌÜŪ¤ò¿Ê¤á¤ë¤¿¤á¤Î´óÉÕ¤ò¾ï¤Ë´î¤ó¤Ç¼õ¤±Æþ¤ì¤Æ¤¤¤Þ¤¹¡£ »ä¤¿¤Á¤Î¤è¤¦¤Ê¥Ü¥é¥ó¥Æ¥£¥¢³èư¤Ç¤Ï¡¢ ¤Á¤ç¤Ã¤È¤·¤¿¤³¤È¤¬Â礤¤ËÌòΩ¤Ä¤Î¤Ç¤¹! ¤Þ¤¿°ìÈÌŪ¤Ë¡¢»ä¤¿¤Á¤Ï¼«Á°¤Ç¼þÊÕµ¡´ï¤òÇ㤦»ñ¶â¤¬ÉÔ­¤·¤Æ¤¤¤ë¤¿¤á¡¢ ¼þÊÕµ¡´ï¤Î¥µ¥Ý¡¼¥È¤ò½¼¼Â¤µ¤»¤ë¤Î¤Ë¥Ï¡¼¥É¥¦¥§¥¢¤Î´óÉդϤȤƤâ½ÅÍפǤ¹¡£ »ñ¶â¤Î´óÉÕ The FreeBSD Foundation ¤Ï¡¢ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤ÎÌÜɸ¤ò¿ä¿Ê¤¹¤ë¤¿¤á¤ËÀßΩ¤µ¤ì¤¿¡¢ Èó±ÄÍø¤Î¡¢ÀǶâ¤òÌȽü¤µ¤ì¤¿ºâÃĤǤ¹¡£501(c)3 ¤ËŬ¹ç¤¹¤ëÃÄÂΤȤ·¤Æ¡¢ Foundation ¤Ï¥¢¥á¥ê¥«¹ç½°¹ñϢˮ½êÆÀÀǤʤé¤Ó¤Ë ¥³¥í¥é¥É½£½êÆÀÀǤò°ìÈ̤ËÌȽü¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ÌÈÀÇÃÄÂΤؤδóÉդϡ¢ ¿¤¯¤Î¾ì¹çϢˮÀ¯ÉܤβÝÀÇÂоݽêÆÀ¤«¤é¹µ½ü¤Ç¤­¤Þ¤¹¡£ ´óÉդϾ®ÀÚ¼ê¤Ç°Ê²¼¤ËÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£
The FreeBSD Foundation - 7321 Brockway Dr. + P.O. Box 20247, Boulder, - CO 80303 + CO 80308 USA
¤Þ¤¿¡¢´óÉդμõ¤±ÉÕ¤±¤ò PayPal ¤òÄ̤¸¤Æ web ·Ðͳ¤Ç¤Ç¤­¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤·¤¿¡£ ´óÉÕ¤ò¤¹¤ë¤Ë¤Ï¡¢The FreeBSD Foundation ¤Î web ¥µ¥¤¥È¤ò¤¼¤Ò¤´Í÷¤¯¤À¤µ¤¤¡£ The FreeBSD Foundation ¤Ë´Ø¤¹¤ë¤³¤ì°Ê¾å¤Î¾ðÊó¤Ï The FreeBSD Foundation -- an Introduction ¤ò¸«¤Æ¤¯¤À¤µ¤¤¡£ Foundation ¤Ø¤Î email ¤Ç¤ÎÏ¢Íí¤Ï bod@FreeBSDFoundation.org ¤Ø¤É¤¦¤¾¡£
¥Ï¡¼¥É¥¦¥§¥¢¤Î´ó£ ´ó£ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤ÏŬÀڤʻȤ¤Æ»¤Î¤¢¤ë¥Ï¡¼¥É¥¦¥§¥¢¤Î´óÉÕ¤ò´î¤ó¤Ç¼õ¤±Æþ¤ì¤Æ¤¤¤Þ¤¹¡£ ¥Ï¡¼¥É¥¦¥§¥¢¤ò´ó£¤·¤è¤¦¤È¤·¤Æ¤¤¤ë¤Ê¤é¡¢ ´ó£ÉʼõÉÕ»ö̳¶É¤ËÏ¢Íí¤·¤Æ¤¯¤À¤µ¤¤¡£
-
diff --git a/ja_JP.eucJP/books/handbook/bsdinstall/chapter.xml b/ja_JP.eucJP/books/handbook/bsdinstall/chapter.xml index ec602b3d22..e18be8deb5 100644 --- a/ja_JP.eucJP/books/handbook/bsdinstall/chapter.xml +++ b/ja_JP.eucJP/books/handbook/bsdinstall/chapter.xml @@ -1,2648 +1,2648 @@ Jim Mock ºÆ¹½À®¡¢ÉôʬŪ¤Ë½ñ¤­Ä¾¤·: Randy Pratt sysinstall ¤Î¥¦¥©¡¼¥¯¥¹¥ë¡¼¡¢¥¹¥¯¥ê¡¼¥ó¥·¥ç¥Ã¥È¡¢ ¤ª¤è¤Ó¤½¤Î¾¸¶¹Æ: Gavin Atkinson bsdinstall ¤Ë¸þ¤±¤¿²þÄû: Warren Block &os; ¤Î¥¤¥ó¥¹¥È¡¼¥ë (9.<replaceable>X</replaceable> °Ê¹ß¤Î¾ì¹ç) ¤³¤Î¾Ï¤Ç¤Ï installation &os; ¤Ç¤Ï¡¢¥Æ¥­¥¹¥È¥Ù¡¼¥¹¤Î»È¤¤¤ä¤¹¤¤¥¤¥ó¥¹¥È¡¼¥ë¥×¥í¥°¥é¥à¤¬ÍѰդµ¤ì¤Æ¤¤¤Þ¤¹¡£ &os; 9.0-RELEASE °Ê¹ß¤Ç¤Ï bsdinstall¡¢ &os; 9.0-RELEASE ¤è¤êÁ°¤Î¥ê¥ê¡¼¥¹¤Ç¤Ï sysinstall ¤È¸Æ¤Ð¤ì¤ë¥¤¥ó¥¹¥È¡¼¥ë¥×¥í¥°¥é¥à¤ò»È¤¤¤Þ¤¹¡£ ¤³¤Î¾Ï¤Ç¤Ï¡¢bsdinstall ¤Î»È¤¤Êý¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Þ¤¹¡£ sysinstall ¤ÎÍøÍѤˤĤ¤¤Æ¤Ï¡¢ ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ ¤³¤Î¾Ï¤òÆÉ¤à¤È¡¢°Ê²¼¤Î¤³¤È¤¬¤ï¤«¤ê¤Þ¤¹¡£ &os; ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤Îºî¤êÊý¡£ &os; ¤¬¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤ò¤É¤Î¤è¤¦¤Ëʬ³ä¤·¡¢»²¾È¤¹¤ë¤«¡£ bsdinstall ¤ò¤É¤Î¤è¤¦¤Ëµ¯Æ°¤¹¤ë¤«¡£ bsdinstall ¤¬Ê¹¤¤¤Æ¤¯¤ë¼ÁÌ䤬¤É¤Î¤è¤¦¤Ê°ÕÌ£¤Ç¤¢¤ê¡¢ ¤Þ¤¿¤É¤Î¤è¤¦¤ËÅú¤¨¤ì¤ÐÎɤ¤¤«¡£ ¤³¤Î¾Ï¤òÆÉ¤àÁ°¤Ë¡¢°Ê²¼¤Î¤³¤È¤ò³Îǧ¤·¤Æ²¼¤µ¤¤¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤·¤è¤¦¤È¤·¤Æ¤¤¤ë¥Ð¡¼¥¸¥ç¥ó¤ËÉÕ°¤·¤Æ¤¤¤ë¥µ¥Ý¡¼¥È¥Ï¡¼¥É¥¦¥§¥¢°ìÍ÷¤òÆÉ¤ß¡¢ ¤¢¤Ê¤¿¤Î»È¤Ã¤Æ¤¤¤ë¥Ï¡¼¥É¥¦¥§¥¢¤¬¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤ë¤«¤É¤¦¤«¤ò³Îǧ¤·¤Æ²¼¤µ¤¤¡£ ¤³¤Î¥¤¥ó¥¹¥È¡¼¥ë¤ÎÀâÌÀ½ñ¤Ï &i386; (PC ¸ß´¹) ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î¥³¥ó¥Ô¥å¡¼¥¿¤òÂоݤˤ·¤Æ¤¤¤Þ¤¹¡£ ¾¤Î¥×¥é¥Ã¥È¥Õ¥©¡¼¥à¤ËÆÃÍ­¤ÎÀâÌÀ¤Ë¤Ä¤¤¤Æ¤Ï¤½¤Î¤Ä¤ÉÌÀµ­¤·¤Æ¤¤¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥é¤È¤³¤Îʸ½ñ¤Çµ­½Ò¤·¤Æ¤¤¤ëÆâÍÆ¤Î´Ö¤Ë¤Ï¡¢ ¤¤¤¯¤é¤«¥º¥ì¤¬¤¢¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ¤³¤Î¾Ï¤òÀµ³Î¤ÇÃé¼Â¤Ê¼ê½ç½ñ¤È¤·¤Æ¤Ç¤Ï¤Ê¤¯¡¢ °ìÈÌŪ¤Ê¥¬¥¤¥É¤È¤·¤Æ¤´ÍøÍѤ¯¤À¤µ¤¤¡£ ¥Ï¡¼¥É¥¦¥§¥¢Í×·ï ºÇ¾®¹½À® &os; ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëºÇ¾®¹½À®¤Ï¡¢ &os; ¤Î¥Ð¡¼¥¸¥ç¥ó¤ä¥Ï¡¼¥É¥¦¥§¥¢¤Î¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Ë¤è¤Ã¤Æ°Û¤Ê¤ê¤Þ¤¹¡£ °Ê²¼¤ÎÀá¤Ç¤Ï¡¢ºÇ¾®¹½À®¤Ë¤Ä¤¤¤Æ¤Î¾ðÊó¤ò¤Þ¤È¤á¤Æ¤¤¤Þ¤¹¡£ ¤Þ¤¿¡¢&os; ¤Î¥¤¥ó¥¹¥È¡¼¥ëÊýË¡¤Ë¤è¤Ã¤Æ¡¢ Âбþ¤·¤Æ¤¤¤ë CDROM ¥É¥é¥¤¥Ö¤ä¡¢ ¾ì¹ç¤Ë¤è¤Ã¤Æ¤Ï¥Í¥Ã¥È¥ï¡¼¥¯¥¢¥À¥×¥¿¤¬É¬ÍפȤʤê¤Þ¤¹¡£ ¤³¤ì¤Ë´Ø¤·¤Æ¤Ï ¤ÇÀâÌÀ¤·¤Þ¤¹¡£ &os;/&arch.i386; &os;/&arch.i386; ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Ï¡¢ 486 °Ê¾å¤Î¥×¥í¥»¥Ã¥µ¤È¡¢ ¾¯¤Ê¤¯¤È¤â 64 MB ¤Î RAM ¤¬É¬ÍפǤ¹¡£ ºÇ¾®¤Î¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤Ï¡¢ ¾¯¤Ê¤¯¤È¤â 1.1 MB ¤Î¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤Î¶õ¤­ÍÆÎ̤¬É¬ÍפǤ¹¡£ ¸Å¤¤¥³¥ó¥Ô¥å¡¼¥¿¤Ç¤Ï¡¢ ®¤¤¥×¥í¥»¥Ã¥µ¤òÆþ¼ê¤¹¤ë¤è¤ê¡¢¤è¤ê¿¤¯¤Î RAM ¤ä¤è¤ê¿¤¯¤ÎÍÆÎ̤Υϡ¼¥É¥É¥é¥¤¥Ö¤òÍѰդ¹¤ë¤Û¤¦¤¬½ÅÍפǤ¹¡£ &os;/&arch.amd64; &os;/&arch.amd64; ¤ò¼Â¹Ô²Äǽ¤Ê¥×¥í¥»¥Ã¥µ¤Ë¤Ï 2 ¤Ä¤Î¥¯¥é¥¹¤¬¤¢¤ê¤Þ¤¹¡£ 1 ¤ÄÌܤΥ¯¥é¥¹¤Ï¡¢&amd.athlon;64, &amd.athlon;64-FX, &amd.opteron; ¤ä¤½¤ì¤è¤ê¿·¤·¤¤¥×¥í¥»¥Ã¥µ¤Ç¤¹¡£ ¤â¤¦ 1 ¤Ä¤Î¥¯¥é¥¹¤Ï¡¢ &intel; EM64T ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤òºÎÍѤ·¤Æ¤¤¤ë¥×¥í¥»¥Ã¥µ¤Ç¤¹¡£ ¤³¤ì¤é¤Î¥×¥í¥»¥Ã¥µ¤ÎÎã¤Ï¡¢ &intel; &core; 2 Duo, Quad, Extreme ¥×¥í¥»¥Ã¥µ¥Õ¥¡¥ß¥ê¡¢ &intel; &xeon; 3000, 5000, 7000 ·Ï¤Î¥×¥í¥»¥Ã¥µ¡¢ ¤ª¤è¤Ó &intel; &core; i3, i5, i7 ¥×¥í¥»¥Ã¥µ¤Ç¤¹¡£ nVidia nForce3 Pro-150 ¥Ù¡¼¥¹¤Î¥³¥ó¥Ô¥å¡¼¥¿¤ò»ÈÍѤ¹¤ë¤Ë¤Ï¡¢ BIOS ¤Î¥»¥Ã¥È¥¢¥Ã¥×¤ò»È¤Ã¤Æ¡¢IO APIC ¤ò̵¸ú¤Ë¤¹¤ë ɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¤â¤·¡¢¤³¤Î¤è¤¦¤Ê¥ª¥×¥·¥ç¥ó¤¬¤Ê¤±¤ì¤Ð¡¢ Âå¤ï¤ê¤Ë ACPI ¤ò̵¸ú¤Ë¤¹¤ëɬÍפ¬¤¢¤ë¤Ç¤·¤ç¤¦¡£ Pro-150 ¥Á¥Ã¥×¥»¥Ã¥È¤Ë¤Ï²óÈòºö¤¬¸«¤Ä¤«¤Ã¤Æ¤¤¤Ê¤¤¥Ð¥°¤¬¤¢¤ê¤Þ¤¹¡£ &os;/&arch.powerpc; &apple; &macintosh; ¤¹¤Ù¤Æ¤Î USB Æâ¢¤Î New World &apple; &macintosh; ¥·¥¹¥Æ¥à¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£ Ê£¿ô¤Î CPU ¤ò»ý¤Ä¥³¥ó¥Ô¥å¡¼¥¿¤Ï SMP ¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£ 32-bit ¥«¡¼¥Í¥ë¤Ï¡¢RAM ¤ÎºÇ½é¤Î 2 GB ¤À¤±¤òÍøÍѤǤ­¤Þ¤¹¡£ Blue & White PowerMac G3 ¤Ç¤Ï¡¢&firewire; ¤ËÂбþ¤·¤Æ¤¤¤Þ¤»¤ó¡£ &os;/&arch.sparc64; &os;/&arch.sparc64; ¤¬Âбþ¤·¤Æ¤¤¤ë¥Ï¡¼¥É¥¦¥§¥¢¤Î°ìÍ÷¤Ë¤Ä¤¤¤Æ¤Ï¡¢ FreeBSD/sparc64 ¥×¥í¥¸¥§¥¯¥È¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ¸½»þÅÀ¤Ç¤Ï¡¢ ¾¤Î¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤È¥Ç¥£¥¹¥¯¤Î¶¦Í­¤¬¤Ç¤­¤Ê¤¤¤Î¤Ç¡¢ &os;/&arch.sparc64; ÀìÍѤΥǥ£¥¹¥¯¤¬É¬ÍפǤ¹¡£ ¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤ë¥Ï¡¼¥É¥¦¥§¥¢ &os; ¤¬¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤ë¥Ï¡¼¥É¥¦¥§¥¢¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤ä¥Ç¥Ð¥¤¥¹¤Î°ìÍ÷¤Ï¡¢ ³Æ¥ê¥ê¡¼¥¹¤Î¥Ï¡¼¥É¥¦¥§¥¢¥Î¡¼¥È¤È¤·¤ÆÄ󶡤µ¤ì¤Þ¤¹¡£ ¤³¤Î¥É¥­¥å¥á¥ó¥È¤ÏÄ̾ï¥ê¥ê¡¼¥¹¥á¥Ç¥£¥¢¤Î¥ë¡¼¥È¥Ç¥£¥ì¥¯¥È¥ê¤Ë¤¢¤ë HARDWARE.TXT ¤È¤¤¤¦Ì¾Á°¤Î¥Õ¥¡¥¤¥ë¤Ç¸«¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¥Ï¡¼¥É¥¦¥§¥¢¥ê¥¹¥È¤Ï¡¢&os; ¤Î¥¦¥§¥Ö¥µ¥¤¥È¤Î ¥ê¥ê¡¼¥¹¾ðÊó ¤Î¥Ú¡¼¥¸¤Ë¤â¤¢¤ê¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë¹Ô¤¦ºî¶È ¥Ç¡¼¥¿¤Î¥Ð¥Ã¥¯¥¢¥Ã¥× &os; ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥³¥ó¥Ô¥å¡¼¥¿¤Ë»Ä¤µ¤ì¤Æ¤¤¤ë²ÁÃͤΤ¢¤ë¥Ç¡¼¥¿¤ò¤¹¤Ù¤Æ¥Ð¥Ã¥¯¥¢¥Ã¥×¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤½¤·¤Æ¡¢¥¤¥ó¥¹¥È¡¼¥ëºî¶È¤ò¿Ê¤á¤ëÁ°¤Ë¥Ð¥Ã¥¯¥¢¥Ã¥×¤¬Àµ¤·¤¯¼è¤ì¤Æ¤¤¤ë¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ &os; ¤Î¥¤¥ó¥¹¥È¡¼¥é¤Ï¡¢¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤ËÊѹ¹¤ò²Ã¤¨¤ëÁ°¤Ë³Îǧ¤òµá¤á¤Þ¤¹¤¬¡¢ °ìÅټºݤ˽ñ¤­¹þ¤àºî¶È¤¬»Ï¤Þ¤Ã¤Æ¤·¤Þ¤¦¤È¡¢ ¤â¤¦¸µ¤ËÌ᤹¤³¤È¤Ï¤Ç¤­¤Þ¤»¤ó¡£ &os; ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¾ì½ê¤Î·èÄê ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤¬ &os; ¤Î¤ß¤Ç¡¢ ¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤¹¤Ù¤Æ¤ò»È¤Ã¤Æ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¾ì¹ç¤Ë¤Ï¡¢ ¤³¤ÎÀá¤Î¸åȾ¤òÈô¤Ð¤¹¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤·¤«¤·¡¢¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤Ë &os; ¤È¾¤Î¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤ò¶¦Â¸¤µ¤»¤ëɬÍפ¬¤¢¤ë¾ì¹ç¤Ë¤Ï¡¢ ¥Ç¥£¥¹¥¯¥ì¥¤¥¢¥¦¥È¤Ë´Ø¤¹¤ë´ðËÜŪ¤ÊÉôʬ¤òÍý²ò¤·¤Æ¤ª¤¯É¬Íפ¬¤¢¤ê¤Þ¤¹¡£ &os;/&arch.i386; ¤ª¤è¤Ó &os;/&arch.amd64; ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Ç¤Î¥Ç¥£¥¹¥¯¥ì¥¤¥¢¥¦¥È ¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤òÊ£¿ô¤Î²ô¤Ëʬ³ä¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤³¤ì¤é¤Î²ô¤Ï ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó ¤È¸Æ¤Ð¤ì¤Þ¤¹¡£ ¥Ç¥£¥¹¥¯¤ò¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ëʬ³ä¤¹¤ëÊýË¡¤Ï 2 Ä̤ꤢ¤ê¤Þ¤¹¡£ ÅÁÅýŪ¤Ê Master Boot Record (MBR) ¤Ç¤Ï¡¢ ¥Ç¥£¥¹¥¯ 1 Âæ¤¢¤¿¤ê 4 ¤Ä¤Þ¤Ç¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥Æ¡¼¥Ö¥ë¤ò»ý¤Ä¤³¤È¤¬¤Ç¤­¤Þ¤¹ (Îò»ËŪ¤ÊÍýͳ¤Ë¤è¤ê¡¢&os; ¤Ï¡¢¤³¤ì¤é¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Î¤³¤È¤ò ¥¹¥é¥¤¥¹ ¤È¸Æ¤Ó¤Þ¤¹)¡£ Â礭¤Ê¥Ç¥£¥¹¥¯¤Ë¤È¤Ã¤Æ¡¢ºîÀ®¤Ç¤­¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Î¿ô¤¬ 4 ¤Ä¤È¤¤¤¦À©¸Â¤Ï¸ÂÄêŪ¤Ê¤Î¤Ç¡¢ ¥×¥é¥¤¥Þ¥ê¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Î 1 ¤Ä¤Ë³ÈÄ¥¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤Ç¤­¤Þ¤¹¡£ ÏÀÍý¥Ñ¡¼¥Æ¥£¥·¥ç¥ó ¤È¸Æ¤Ð¤ì¤ëÆÃÊ̤Υѡ¼¥Æ¥£¥·¥ç¥ó¤Ï¡¢ ¤³¤Î³ÈÄ¥¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ÎÆâÉô¤ËºîÀ®¤Ç¤­¤Þ¤¹¡£ ¤³¤ì¤Ï¡¢Â¿¾¯°·¤¤¤Ë¤¯¤¤¤â¤Î¤Ç¤¹¡£ GUID Partition Table (GPT) ¤Ï¡¢ ¥Ç¥£¥¹¥¯¤ò¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ëʬ¤±¤ë´Êñ¤Ç¿·¤·¤¤ÊýË¡¤Ç¤¹¡£ ÅÁÅýŪ¤Ê MBR ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥Æ¡¼¥Ö¥ë¤ÈÈæ¤Ù¤ë¤È¡¢ GPT ¤Ï¤Ï¤ë¤«¤ËËüǽ¤Ç¤¹¡£°ìÈÌŪ¤Ê GPT ¤Î¼ÂÁõ¤Ç¤Ï¡¢ 1 ¤Ä¤Î¥Ç¥£¥¹¥¯¤Ë 128 ¸Ä¤Þ¤Ç¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ÎºîÀ®¤¬²Äǽ¤Ç¤¹¡£ °·¤¤¤Ë¤¯¤¤ÏÀÍý¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Î¤è¤¦¤Ê²óÈòºö¤ÏɬÍפ¢¤ê¤Þ¤»¤ó¡£ &windows; XP ¤Î¤è¤¦¤Ê¸Å¤¤¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Ï¡¢ GPT ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤È¸ß´¹À­¤¬¤¢¤ê¤Þ¤»¤ó¡£ &os; ¤ò¤³¤Î¤è¤¦¤Ê¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤È¥Ç¥£¥¹¥¯¾å¤Ç¶¦Â¸¤µ¤»¤ë¾ì¹ç¤Ë¤Ï¡¢ MBR ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥Æ¡¼¥Ö¥ë¤ò»È¤¦É¬Íפ¬¤¢¤ê¤Þ¤¹¡£ &os; ¤Îɸ½à¤Î¥Ö¡¼¥È¥í¡¼¥À¤Ï¡¢¥×¥é¥¤¥Þ¥ê¤Þ¤¿¤Ï GPT ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹ (&os; ¤Îµ¯Æ°¥×¥í¥»¥¹¤Î¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¤ò¤´Í÷¤¯¤À¤µ¤¤)¡£ ¥Ç¥£¥¹¥¯¾å¤Î¤¹¤Ù¤Æ¤Î¥×¥é¥¤¥Þ¥ê¡¢¤â¤·¤¯¤Ï GPT ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤¬»È¤ï¤ì¤Æ¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¤½¤Î¤Ò¤È¤Ä¤ò &os; ¤Î¤¿¤á¤Ë³«Êü¤·¤Æ¤¯¤À¤µ¤¤¡£ &os; ¤ÎºÇ¾®¤Î¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤Ï¡¢1 GB ÄøÅ٤Υǥ£¥¹¥¯ÍÆÎ̤¬É¬ÍפǤ¹¡£ ¤·¤«¤·¡¢¤³¤ì¤Ï Èó¾ï¤Ë ¾®¤µ¤Ê¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤¢¤ê¡¢ ¼«Ê¬¤Î¥Õ¥¡¥¤¥ë¤òºîÀ®¤¹¤ë¥¹¥Ú¡¼¥¹¤Ï¤Û¤È¤ó¤É»Ä¤é¤Ê¤¤¤Ç¤·¤ç¤¦¡£ ¸½¼ÂŪ¤Ë¤Ï¡¢¥°¥é¥Õ¥£¥«¥ë¤Ê´Ä¶­¤¬É¬Íפʤ±¤ì¤Ð 3 GB¡¢ ¥°¥é¥Õ¥£¥«¥ë¥æ¡¼¥¶¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ò»ÈÍѤ¹¤ë¤Î¤Ç¤¢¤ì¤Ð 5 GB °Ê¾å¤ÏɬÍפǤ·¤ç¤¦¡£ ¥µ¡¼¥É¥Ñ¡¼¥Æ¥£À½¥½¥Õ¥È¥¦¥§¥¢¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤Ê¤é¤Ð¡¢ ¤µ¤é¤Ë¿¤¯¤Î¥¹¥Ú¡¼¥¹¤¬É¬Íפˤʤê¤Þ¤¹¡£ ¤µ¤Þ¤¶¤Þ¤Ê ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥µ¥¤¥º¤òÊѹ¹¤¹¤ë¥Õ¥ê¡¼¤ä¾¦ÍѤΥġ¼¥ë ¤òÍøÍѤǤ­¤Þ¤¹¡£ GParted Live ¤Ï¡¢GParted ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¨¥Ç¥£¥¿¤ò´Þ¤à´°Á´¤Ê¥é¥¤¥Ö CD ¤Ç¤¹¡£ ¿¤¯¤Î Linux Live CD ¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤Ç¤â GParted ¤òÍøÍѤǤ­¤Þ¤¹¡£ ¥Ç¥£¥¹¥¯¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤Ï¡¢ ¥Ç¥£¥¹¥¯¾å¤Î¥Ç¡¼¥¿¤ò²õ¤¹²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ ¥Ç¥£¥¹¥¯¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òÊѹ¹¤¹¤ëÁ°¤Ë¡¢ ɬ¤ºÁ´ÂΤΥХ寥¢¥Ã¥×¤ò¤È¤ê¡¢´°Á´À­¤ò¸¡¾Ú¤·¤Æ¤¯¤À¤µ¤¤¡£ µsoft; Vista ¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥µ¥¤¥º¤ÎÊѹ¹¤Ï¡¢Æñ¤·¤¤²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ ¤³¤Î¤è¤¦¤Êºî¶È¤ò¹Ô¤¦ºÝ¤Ï¡¢ Vista ¤Î¥¤¥ó¥¹¥È¡¼¥ë CDROM ¤ò¼ê¸µ¤ËÃÖ¤¤¤Æ¤ª¤¯¤³¤È¤ò¤ª´«¤á¤·¤Þ¤¹¡£ ´û¸¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò»ÈÍÑ ´û¤Ë &windows; ¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë 40 GB ¤Î¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤¬ 1 ÂæÀܳ¤µ¤ì¤Æ¤ª¤ê¡¢¤½¤Î¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤Ï¡¢ 20 GB ¤Î 2 ¤Ä¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ëʬ³ä¤µ¤ì¤Æ¤¤¤ë¤È²¾Äꤷ¤Þ¤¹¡£ &windows; ¤Ç¤Ï¡¢¤½¤ì¤¾¤ì C: ¤ª¤è¤Ó D: ¤È¸Æ¤Ó¤Þ¤¹¡£ C: ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ë¤Ï 10 GB ¤Î¥Ç¡¼¥¿¡¢ D: ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ë¤Ï 5 GB ¤Î¥Ç¡¼¥¿¤¬¤¢¤ë¤È¤·¤Þ¤¹¡£ D: ¤Ë¤¢¤ë¥Ç¡¼¥¿¤ò¤¹¤Ù¤Æ C: ¤Ë¥³¥Ô¡¼¤¹¤ì¤Ð¡¢ 2 ¤ÄÌܤΥѡ¼¥Æ¥£¥·¥ç¥ó¤ò²òÊü¤·¡¢&os; ¤Î¤¿¤á¤Ë»È¤¦¤³¤È¤¬¤Ç¤­¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£ ´û¸¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò½Ì¾®¤¹¤ë &windows; ¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë 40 GB ¤Î¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤¬ 1 ÂæÀܳ¤µ¤ì¤¿ PC ¤ò»ÈÍѤ·¤Æ¤¤¤ë¤È²¾Äꤷ¤Þ¤¹¡£ ¥Ç¥£¥¹¥¯¤Î¤¹¤Ù¤Æ¤ò 1 ¤Ä¤ÎÂ礭¤Ê¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤È¤·¤Æ»ÈÍѤ·¤Æ¤¤¤Þ¤¹¡£ &windows; ¤Ç¤Ï¡¢¤³¤Î 40 GB ¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò 1 ¤Ä¤Î C: ¥É¥é¥¤¥Ö¤È¤·¤ÆÉ½¼¨¤·¤Þ¤¹¡£ 15 GB ¤Î¥Ç¡¼¥¿¤¬¤¢¤ë¤È¤·¤Þ¤¹¡£ &windows; ¤¬ 20 GB ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¡¢ »Ä¤ê¤Î 20 GB ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò &os; ¤Ç»È¤¤¤¿¤¤¤È¤·¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤ò¹Ô¤¦¤Ë¤Ï¡¢2 ¤Ä¤ÎÊýË¡¤¬¤¢¤ê¤Þ¤¹¡£ &windows; ¤Î¥Ç¡¼¥¿¤ò¥Ð¥Ã¥¯¥¢¥Ã¥×¤·¡¢¥¤¥ó¥¹¥È¡¼¥ë»þ¤Ë 20 GB ¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤·¤ÆºÆ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¡£ Àè¤Ë½Ò¤Ù¤¿ GParted ¤ò¤Ï¤¸¤á¤È¤¹¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò½Ì¾®¤¹¤ë¥Ä¡¼¥ë¤ò»È¤Ã¤Æ¡¢ &windows; ¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò½Ì¾®¤·¡¢¥Õ¥ê¡¼¤Î¶õ´Ö¾å¤Ë¡¢ &os; ¤Î¤¿¤á¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤¹¤ë¡£ °Û¤Ê¤ë¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤ò´Þ¤à¥Ç¥£¥¹¥¯¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ç¤Ï¡¢ ¤É¤Î¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤âƱ»þ¤Ë¼Â¹Ô¤Ç¤­¤ë¤Î¤Ï 1 ¤Ä¤Ç¤¹¡£ Ê£¿ô¤Î¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤òƱ»þ¤Ë¼Â¹Ô¤¹¤ëÊýË¡¤Ë¤Ä¤¤¤Æ¤Ï¡¢ Virtualization ¤Î¾Ï¤ÇÀâÌÀ¤·¤Þ¤¹¡£ ¥Í¥Ã¥È¥ï¡¼¥¯¤Î¾ÜºÙ¤ò¤Þ¤È¤á¤ë &os; ¤Î¥¤¥ó¥¹¥È¡¼¥ëÊýË¡¤Ë¤è¤Ã¤Æ¤Ï¡¢¥Í¥Ã¥È¥ï¡¼¥¯¤ËÀܳ¤·¡¢ ¥Õ¥¡¥¤¥ë¤Î¥À¥¦¥ó¥í¡¼¥É¤¬É¬ÍפǤ¹¡£ ¥¤¡¼¥µ¥Í¥Ã¥È¤ËÀܳ (¤Þ¤¿¤Ï¡¢¥±¡¼¥Ö¥ë / DSL ¥â¥Ç¥à·Ðͳ¤Ç¥¤¡¼¥µ¥Í¥Ã¥È¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤òÍøÍѤ·¤ÆÀܳ) ¤¹¤ë¤¿¤á¤Ë¤Ï¡¢ ¥¤¥ó¥¹¥È¡¼¥ëÃæ¤Ë¤³¤ì¤é¤Î¾ðÊó¤òÆþÎϤ¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ DHCP ¤Ï¡¢ ¼«Æ°Åª¤Ë¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê¾ðÊó¤òÆÀ¤ë¤Î¤Ë¤è¤¯»È¤ï¤ì¤Þ¤¹¡£ DHCP ¤òÍøÍѤǤ­¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢ ¥·¥¹¥Æ¥à´ÉÍý¼Ô¤«¥×¥í¥Ð¥¤¥À¤Ë¥Í¥Ã¥È¥ï¡¼¥¯¾ðÊó¤òÌ䤤¹ç¤ï¤»¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¥Í¥Ã¥È¥ï¡¼¥¯¾ðÊó IP ¥¢¥É¥ì¥¹ ¥µ¥Ö¥Í¥Ã¥È¥Þ¥¹¥¯ ¥Ç¥Õ¥©¥ë¥È¥ë¡¼¥¿¤Î IP ¥¢¥É¥ì¥¹ ¥í¡¼¥«¥ë¥Í¥Ã¥È¥ï¡¼¥¯¤Î¥É¥á¥¤¥ó̾ DNS ¥µ¡¼¥Ð¤Î IP ¥¢¥É¥ì¥¹ &os; Errata ¤Î³Îǧ &os; ¥×¥í¥¸¥§¥¯¥È¤Ç¤Ï &os; ¤Î³Æ¥ê¥ê¡¼¥¹¤¬¤Ç¤­¤ë¸Â¤ê°ÂÄꤹ¤ë¤è¤¦ÅØÎϤ·¤Æ¤¤¤Þ¤¹¤¬¡¢ »þ¡¹¥Ð¥°¤¬È¯À¸¤·¤Æ¤·¤Þ¤¦¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£¶Ë¤Þ¤ì¤Ë¡¢ ȯÀ¸¤·¤¿¥Ð¥°¤¬¥¤¥ó¥¹¥È¡¼¥ë¥×¥í¥»¥¹¤Ë±Æ¶Á¤òÍ¿¤¨¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ¤³¤ì¤é¤ÎÌäÂê¤Ïȯ¸«¤µ¤ì²ò·è¤µ¤ì¤ë¤È¤È¤â¤Ë¡¢ &os; ¤Î¥¦¥§¥Ö¥µ¥¤¥È¤Î FreeBSD Errata ¤Ë·Ç¼¨¤µ¤ì¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤Ë´Ø¤·¤ÆÃí°Õ¤¹¤Ù¤­´ûÃΤÎÌäÂ̵꤬¤¤¤³¤È¤ò³Î¤«¤á¤ë¤¿¤á¤Ë¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÁ°¤Ë Errata ¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤¹¤Ù¤Æ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¾ðÊó¤ä Errata ¤Ï¡¢ &os; ¤Î¥¦¥§¥Ö¥µ¥¤¥È ¤Î ¥ê¥ê¡¼¥¹¾ðÊó ¤Î¹à¤Ç³Îǧ¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤Î½àÈ÷ &os; ¤Î¥¤¥ó¥¹¥È¡¼¥ë¤Ï¡¢ ¥¤¥ó¥¹¥È¡¼¥ëÍѤΠCD, DVD ¤Þ¤¿¤Ï USB ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤È¤È¤â¤Ë¡¢¥³¥ó¥Ô¥å¡¼¥¿¤òµ¯Æ°¤¹¤ë¤È¤³¤í¤«¤é»Ï¤Þ¤ê¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥é¤Ï¡¢¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Ç¼Â¹Ô¤Ç¤­¤ë¤è¤¦¤Ê¥×¥í¥°¥é¥à¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ &os; ¤Î¥¤¥ó¥¹¥È¡¼¥ë¥Õ¥¡¥¤¥ë¤ò¤¹¤Ù¤Æ´Þ¤ó¤Ç¤¤¤ëÄ̾ï¤Î¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤Ë²Ã¤¨¡¢ bootonly ¤òÍøÍѤǤ­¤Þ¤¹¡£ bootonly ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤Ï¡¢¥¤¥ó¥¹¥È¡¼¥ë¥Õ¥¡¥¤¥ë¤ò´Þ¤ó¤Ç¤¤¤Þ¤»¤ó¡£ ¤½¤Î¤«¤ï¤ê¡¢¥¤¥ó¥¹¥È¡¼¥ë¤ÎÅÓÃæ¤Ç¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤ò¥Í¥Ã¥È¥ï¡¼¥¯¤«¤é¥À¥¦¥ó¥í¡¼¥É¤·¤Þ¤¹¡£ ¤½¤Î¤¿¤á¡¢bootonly ¥¤¥ó¥¹¥È¡¼¥ë CD ¤Ï¾®¤µ¤¯¡¢ ¤Þ¤¿¡¢¥¤¥ó¥¹¥È¡¼¥ëÃæ¤ËɬÍפʥե¡¥¤¥ë¤À¤±¤ò¥À¥¦¥ó¥í¡¼¥É¤¹¤ë¤Î¤Ç¡¢ »ÈÍѤ¹¤ë¥Ð¥ó¥ÉÉý¤ò¸º¤é¤¹¤³¤È¤¬½ÐÍè¤Þ¤¹¡£ &os; ¤Î¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤Ï &os; ¥¦¥§¥Ö¥µ¥¤¥È ¤«¤éÆþ¼ê¤Ç¤­¤Þ¤¹¡£ &os; ¤ÎÆþ¤Ã¤Æ¤¤¤ë CDROM ¤ä DVD, USB ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤ò»ý¤Ã¤Æ¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¤³¤Î¾Ï¤òÈô¤Ð¤·¤Æ¤â¤«¤Þ¤¤¤Þ¤»¤ó¡£ &os; ¤Î CD ¤ª¤è¤Ó DVD ¥¤¥á¡¼¥¸¤Ï¡¢ µ¯Æ°²Äǽ¤Ê ISO ¥Õ¥¡¥¤¥ë¤Ç¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤Ë¤Ï¡¢°ìËç¤Î CD ¤Þ¤¿¤Ï DVD ¤¬¤¢¤ì¤Ð½½Ê¬¤Ç¤¹¡£ ¸½ºß»ÈÍѤ·¤Æ¤¤¤ë¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¡¢ ISO ¥¤¥á¡¼¥¸¤ò CD ¤Ë½ñ¤­¹þ¤à¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤òÍѤ¤¤Æ¡¢ µ¯Æ°²Äǽ¤Ê CD ¤Þ¤¿¤Ï DVD ¤òºîÀ®¤·¤Æ¤¯¤À¤µ¤¤¡£ µ¯Æ°²Äǽ¤Ê¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤òºîÀ®¤¹¤ë¾ì¹ç¤Ë¤Ï¡¢ °Ê²¼¤Î¼ê½ç¤Ë¤·¤¿¤¬¤Ã¤Æ¤¯¤À¤µ¤¤¡£ - + ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Î¥¤¥á¡¼¥¸¤Î¼èÆÀ &os; 9.0-RELEASE °Ê¹ß¤Î¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Î¥¤¥á¡¼¥¸¤Ï¡¢ ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/arch/arch/ISO-IMAGES/version/&os;-version-RELEASE-arch-memstick.img ¤Î ISO-IMAGES/ ¥Ç¥£¥ì¥¯¥È¥ê¤«¤é¥À¥¦¥ó¥í¡¼¥É¤Ç¤­¤Þ¤¹¡£ ¤³¤³¤Ç¡¢arch ¤È version ¤ÎÉôʬ¤ò¡¢ ¤½¤ì¤¾¤ì¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤È¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤ËÃÖ¤­´¹¤¨¤Æ¤¯¤À¤µ¤¤¡£ ¤¿¤È¤¨¤Ð¡¢&os;/&arch.i386; 9.0-RELEASE ¤Î¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Î¥¤¥á¡¼¥¸¤Ï¡¢ ¤«¤éÆþ¼ê¤Ç¤­¤Þ¤¹¡£ &os; 8.X °ÊÁ°¤Ç¤Ï¡¢ ¤³¤ì¤È¤Ï°Û¤Ê¤ë¥Ç¥£¥ì¥¯¥È¥ê¥Ñ¥¹¤¬»È¤ï¤ì¤Æ¤¤¤Þ¤¹¡£ &os; 8.X °ÊÁ°¤Î¥Ð¡¼¥¸¥ç¥ó¤Î¥À¥¦¥ó¥í¡¼¥É¤È¥¤¥ó¥¹¥È¡¼¥ë¤Î¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¥¤¥á¡¼¥¸¤Ë¤Ï¡¢.img ¤È¤¤¤¦³ÈÄ¥»Ò¤¬¤Ä¤¤¤Æ¤¤¤Þ¤¹¡£ISO-IMAGES/ ¥Ç¥£¥ì¥¯¥È¥ê¤Ë¤ÏÊ£¿ô¤Î°Û¤Ê¤ë¥¤¥á¡¼¥¸¤¬¤¢¤ê¡¢¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë &os; ¤Î¥Ð¡¼¥¸¥ç¥ó¤ä¡¢¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥Ï¡¼¥É¥¦¥§¥¢¤Ë¤è¤Ã¤Æ¡¢ ɬÍפʥե¡¥¤¥ë¤¬ÊѤï¤ê¤Þ¤¹¡£ °Ê²¼¤Îºî¶È¤Ë¤è¤Ã¤Æ¥Ç¡¼¥¿¤¬ ¾Ãµî ¤µ¤ì¤ë¤Î¤Ç¡¢ Àè¤Ë¿Ê¤àÁ°¤Ë¡¢»ÈÍѤ¹¤ë USB ¥¹¥Æ¥£¥Ã¥¯¤Ë¤¢¤ë¥Ç¡¼¥¿¤ò¥Ð¥Ã¥¯¥¢¥Ã¥×¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥¤¥á¡¼¥¸¥Õ¥¡¥¤¥ë¤ò¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Ë½ñ¤­¹þ¤à &os; ¤ò»È¤Ã¤Æ¥¤¥á¡¼¥¸¤ò½ñ¤­¹þ¤à °Ê²¼¤ÎÎã¤Ç¤Ï¡¢¥¤¥á¡¼¥¸¤ò½ñ¤­¹þ¤à¥Ç¥Ð¥¤¥¹¤ò /dev/da0 ¤È¤·¤Æ¤¤¤Þ¤¹¡£ Àµ¤·¤¤¥Ç¥Ð¥¤¥¹¤ò½ÐÎÏÀè¤ËÀßÄꤷ¤Æ¤¤¤ë¤³¤È¤ò½½Ê¬³Îǧ¤·¤Æ¤¯¤À¤¤¡£ ¤µ¤â¤Ê¤±¤ì¤Ð¡¢¸½ºß¤¢¤ë¥Ç¡¼¥¿¤òÇ˲õ¤·¤Æ¤·¤Þ¤¦¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£ &man.dd.1; ¤ò»È¤Ã¤Æ¥¤¥á¡¼¥¸¤ò½ñ¤­¹þ¤à .img ¥Õ¥¡¥¤¥ë¤Ï¡¢ Ä̾ï¤Î¥Õ¥¡¥¤¥ë¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Î´°Á´¤ÊÆâÍÆ¤Î ¥¤¥á¡¼¥¸ ¤Ç¤¹¡£ Ä̾ï¤Î¥Õ¥¡¥¤¥ë¤Î¤è¤¦¤Ê¥³¥Ô¡¼¤Ï ¤Ç¤­¤Þ¤»¤ó¡£&man.dd.1; ¤ò»ÈÍѤ·¤ÆÄ¾ÀÜ¥¿¡¼¥²¥Ã¥È¥Ç¥£¥¹¥¯¤Ë½ñ¤­¹þ¤àɬÍפ¬¤¢¤ê¤Þ¤¹¡£ &prompt.root; dd if=&os;-9.0-RELEASE-&arch.i386;-memstick.img of=/dev/da0 bs=64k &windows; ¤ò»È¤Ã¤Æ¥¤¥á¡¼¥¸¤ò½ñ¤­¹þ¤à ŬÀڤʥɥ饤¥Ö¥ì¥¿¡¼¤ò½ÐÎÏÀè¤ËÀßÄꤷ¤Æ¤¤¤ë¤³¤È¤ò½½Ê¬³Îǧ¤·¤Æ¤¯¤À¤¤¡£ ¤µ¤â¤Ê¤±¤ì¤Ð¡¢¸½ºß¤¢¤ë¥Ç¡¼¥¿¤òÇ˲õ¤·¤Æ¤·¤Þ¤¦¤Ç¤·¤ç¤¦¡£ <application>Image Writer for &windows;</application> ¤òÆþ¼ê¤¹¤ë Image Writer for &windows; ¤Ï¡¢ ¥¤¥á¡¼¥¸¥Õ¥¡¥¤¥ë¤ò¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤ËÀµ¤·¤¯½ñ¤­¹þ¤à¤³¤È¤Î¤Ç¤­¤ë¥Õ¥ê¡¼¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤Ç¤¹¡£ ¤«¤é¥À¥¦¥ó¥í¡¼¥É¤·¤Æ¡¢¥Õ¥©¥ë¥À¤ËŸ³«¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥¤¥á¡¼¥¸¥é¥¤¥¿¤ò»È¤Ã¤Æ¥¤¥á¡¼¥¸¤ò½ñ¤­¹þ¤à Win32DiskImager ¥¢¥¤¥³¥ó¤ò¥À¥Ö¥ë¥¯¥ê¥Ã¥¯¤·¤Æ¡¢¥×¥í¥°¥é¥à¤òµ¯Æ°¤·¤Þ¤¹¡£ Device ¤Î²¼¤Ëɽ¼¨¤µ¤ì¤ë¥Ç¥Ð¥¤¥¹¥ì¥¿¡¼¤¬¡¢ ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Î¥É¥é¥¤¥Ö¤Ç¤¢¤ë¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥Õ¥©¥ë¥À¤Î¥¢¥¤¥³¥ó¤ò¥¯¥ê¥Ã¥¯¤·¤Æ¡¢ ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Ë½ñ¤­¹þ¤à¥¤¥á¡¼¥¸¥Õ¥¡¥¤¥ë¤òÁªÂò¤·¤Þ¤¹¡£ [ Save ] ¤ò¥¯¥ê¥Ã¥¯¤·¤Æ¡¢ ¥¤¥á¡¼¥¸¥Õ¥¡¥¤¥ë¤Î̾Á°¤ò¥¢¥¯¥»¥×¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤¹¤Ù¤Æ¤¬Àµ¤·¤¯¹Ô¤ï¤ì¤¿¤«¤É¤¦¤«¡¢¤Þ¤¿¡¢ ¾¤Î¥¦¥£¥ó¥É¥¦¤Ç¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Î¥Õ¥©¥ë¥À¤¬³«¤«¤ì¤Æ¤¤¤Ê¤¤¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ½àÈ÷¤¬¤Ç¤­¤¿¤é¡¢[ Write ] ¤ò²¡¤·¤Æ¡¢ ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤Ë¥¤¥á¡¼¥¸¥Õ¥¡¥¤¥ë¤ò½ñ¤­¹þ¤ß¤Þ¤¹¡£ ¥Õ¥í¥Ã¥Ô¡¼¥Ç¥£¥¹¥¯¤«¤é¤Î¥¤¥ó¥¹¥È¡¼¥ë¤Ë¤Ï¡¢ ¤â¤Ï¤äÂбþ¤·¤Æ¤¤¤Þ¤»¤ó¡£ ¤³¤ì¤Ç &os; ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÍѰդ¬¤Ç¤­¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤Î³«»Ï ¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï¡¢¼¡¤Î¥á¥Ã¥»¡¼¥¸¤¬É½¼¨¤µ¤ì¤ë¤Þ¤Ç ¥¤¥ó¥¹¥È¡¼¥é¤Ï¥Ç¥£¥¹¥¯¤Ë²¿¤ÎÊѹ¹¤â²Ã¤¨¤Þ¤»¤ó¡£ Your changes will now be written to disk. If you have chosen to overwrite existing data, it will be PERMANENTLY ERASED. Are you sure you want to commit your changes? ¤³¤Î·Ù¹ð¤ÎÁ°¤Ç¤¢¤ì¤Ð¡¢ ¤¤¤Ä¤Ç¤â¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤ÎÆâÍÆ¤òÊѹ¹¤¹¤ë¤³¤È¤Ê¤¯¥¤¥ó¥¹¥È¡¼¥ë¤òÃæÃǤǤ­¤Þ¤¹¡£ ¤â¤·¡¢²¿¤«¤ò´Ö°ã¤Ã¤ÆÀßÄꤷ¤Æ¤·¤Þ¤Ã¤¿¤³¤È¤¬¿´Çۤʤé¤Ð¡¢ ºÇ¸å¤Î·Ù¹ð¤ÎÁ°¤Ëñ¤Ë¥³¥ó¥Ô¥å¡¼¥¿¤ò¥ª¥Õ¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ Èï³²¤ò»Ä¤µ¤º¤ËºÑ¤ß¤Þ¤¹¡£ µ¯Æ° &i386; ¤ª¤è¤Ó &arch.amd64; ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Ç¤Îµ¯Æ° ¤ÇÀâÌÀ¤µ¤ì¤Æ¤¤¤ë µ¯Æ° USB ¥¹¥Æ¥£¥Ã¥¯¤ò»ÈÍѤ¹¤ë¾ì¹ç¤Ë¤Ï¡¢¥³¥ó¥Ô¥å¡¼¥¿¤òΩ¤Á¾å¤²¤ëÁ°¤Ë¡¢ USB ¥¹¥Æ¥£¥Ã¥¯¤òÁÞÆþ¤·¤Æ¤¯¤À¤µ¤¤¡£ CDROM ¤«¤éµ¯Æ°¤¹¤ë¾ì¹ç¤Ë¤Ï¡¢¥³¥ó¥Ô¥å¡¼¥¿¤òΩ¤Á¾å¤²¡¢ ¤¹¤°¤Ë CDROM ¤òÁÞÆþ¤·¤Æ¤¯¤À¤µ¤¤¡£ CDROM ¤Þ¤¿¤Ï USB ¤«¤éµ¯Æ°¤¹¤ë¤è¤¦¤Ë¥³¥ó¥Ô¥å¡¼¥¿¤òÀßÄꤷ¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Îºî¶È¤Ï¡¢¥¤¥ó¥¹¥È¡¼¥ë¤ËÍѤ¤¤ë¥á¥Ç¥£¥¢¤Ë¤è¤Ã¤Æ°Û¤Ê¤ê¤Þ¤¹¡£ µ¯Æ°¤¹¤ë¥Ç¥Ð¥¤¥¹¤ò BIOS ¤ÇÀßÄê¤Ç¤­¤Þ¤¹¡£ ¤Û¤È¤ó¤É¤Î¥·¥¹¥Æ¥à¤Ç¤Ï¡¢Ä̾µ¯Æ°»þ¤Ë F10, F11, F12 ¤Þ¤¿¤Ï Escape ¥­¡¼¤ò²¡¤¹¤³¤È¤Ç¡¢µ¯Æ°¤¹¤ë¥Ç¥Ð¥¤¥¹¤òÁªÂò¤Ç¤­¤Þ¤¹¡£ ¤â¤·¡¢¥³¥ó¥Ô¥å¡¼¥¿¤¬¤¹¤Ç¤Ë¸ºß¤·¤Æ¤¤¤ë OS ¤òÆÉ¤ß¹þ¤ß¡¢ Ä̾ïÄ̤굯ư¤·¤Æ¤·¤Þ¤Ã¤¿¤Î¤Ç¤¢¤ì¤Ð¡¢ °Ê²¼¤Î¸¶°ø¤¬¹Í¤¨¤é¤ì¤Þ¤¹¡£ µ¯Æ°¥Ç¥£¥¹¥¯¤¬µ¯Æ°¥×¥í¥»¥¹¤Ë¤ª¤¤¤Æ½½Ê¬Áᤤ¥¿¥¤¥ß¥ó¥°¤ÇÁÞÆþ¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£ ¥Ç¥£¥¹¥¯¤ò¤½¤Î¤Þ¤Þ¤Ë¤·¤Æ¥³¥ó¥Ô¥å¡¼¥¿¤òºÆµ¯Æ°¤·¤Æ¤¯¤À¤µ¤¤¡£ ÀèÄø¤Î BIOS ¤ÎÊѹ¹¤¬Å¬Àڤ˹Ԥï¤ì¤Æ¤¤¤Þ¤»¤ó¡£ Àµ¤·¤¤¥ª¥×¥·¥ç¥ó¤òÀßÄꤷ¤Æ¤ä¤êľ¤·¤Æ¤¯¤À¤µ¤¤¡£ »ÈÍѤ·¤Æ¤¤¤ë BIOS ¤Ï¡¢ ´õ˾¤·¤Æ¤¤¤ë¥á¥Ç¥£¥¢¤«¤é¤Îµ¯Æ°¤ËÂбþ¤·¤Æ¤¤¤Þ¤»¤ó¡£ Plop Boot Manager ¤ò»È¤¦¤È¡¢¸Å¤¤¥³¥ó¥Ô¥å¡¼¥¿¤ò CD ¤ä USB ¥á¥Ç¥£¥¢¤«¤éµ¯Æ°¤Ç¤­¤Þ¤¹¡£ &os; ¤Ïµ¯Æ°¤ò³«»Ï¤·¤Þ¤¹¡£CDROM ¤«¤éµ¯Æ°¤·¤Æ¤¤¤ë¾ì¹ç¡¢ ¼¡¤Î¤è¤¦¤Ê²èÌ̤¬É½¼¨¤µ¤ì¤ë¤Ç¤·¤ç¤¦ (¥Ð¡¼¥¸¥ç¥ó¾ðÊó¤Ï¾Êά¤·¤Æ¤¤¤Þ¤¹)¡£ Booting from CD-ROM... 645MB medium detected CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 636kB/261056kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 syms=[0x4+0x6cac0+0x4+0x88e9d] \ &os; ¥Ö¡¼¥È¥í¡¼¥À¤Ë¤è¤ê¡¢°Ê²¼¤Î²èÌ̤¬É½¼¨¤µ¤ì¤Þ¤¹¡£
&os; ¥Ö¡¼¥È¥í¡¼¥À¥á¥Ë¥å¡¼
10 ÉôÖÂԤĤ«¡¢Enter ¤ò²¡¤·¤Æ¤¯¤À¤µ¤¤¡£
&macintosh; &powerpc; ¤Ç¤Îµ¯Æ° ¤Û¤È¤ó¤É¤Î¥³¥ó¥Ô¥å¡¼¥¿¤Ç¤Ï¡¢ µ¯Æ°Ãæ¤Ë¥­¡¼¥Ü¡¼¥É¤Î C ¤ò²¡¤·¤Æ¤ª¤¯¤È¡¢CD ¤«¤éµ¯Æ°¤·¤Þ¤¹¡£ Ê̤ÎÊýË¡¤Ç¤Ï Command Option O F ¡¢ ¤Þ¤¿¤Ï non-&apple; ¥­¡¼¥Ü¡¼¥É¤Ç¤Ï Windows Alt O F ¤ò²¡¤·¤Æ¤¯¤À¤µ¤¤¡£ 0 > ¥×¥í¥ó¥×¥È¤Ç boot cd:,\ppc\loader cd:0 ¤ÈÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£ ¥­¡¼¥Ü¡¼¥É¤Î¤Ê¤¤ Xserves ¤Ç¤Ï¡¢ Open Firmware ¤Ëµ¯Æ°¤¹¤ëÊýË¡¤Ë¤Ä¤¤¤Æ &apple;'s support web site ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ &sparc64; ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Ç¤Îµ¯Æ° ¤Û¤È¤ó¤É¤Î &sparc64; ¥·¥¹¥Æ¥à¤Ï¡¢ ¥Ç¥£¥¹¥¯¤«¤é¼«Æ°Åª¤Ëµ¯Æ°¤¹¤ë¤è¤¦¤ËÀßÄꤵ¤ì¤Æ¤¤¤Þ¤¹¡£ &os; ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤Ë¤Ï¡¢¥Í¥Ã¥È¥ï¡¼¥¯¤Þ¤¿¤Ï CDROM ¤«¤éµ¯Æ°¤¹¤ëɬÍפ¬¤¢¤ê¡¢¤½¤Î¤¿¤á¤Ë¤Ï PROM (OpenFirmware) ¤ËÆþ¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ PROM ¤ËÆþ¤ë¤Ë¤Ï¥·¥¹¥Æ¥à¤òºÆµ¯Æ°¤·¡¢ ¥Ö¡¼¥È¥á¥Ã¥»¡¼¥¸¤¬É½¼¨¤µ¤ì¤ë¤Þ¤ÇÂԤäƤ¯¤À¤µ¤¤¡£ ¥â¥Ç¥ë¤Ë¤è¤ê¤Þ¤¹¤¬¡¢°Ê²¼¤Î¤è¤¦¤Êɽ¼¨¤Ç¤¹¡£ Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2001 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.2, 128 MB memory installed, Serial #51090132. Ethernet address 0:3:ba:b:92:d4, Host ID: 830b92d4. ¤â¤·¥·¥¹¥Æ¥à¤¬¤³¤Î»þÅÀ¤Ç¥Ç¥£¥¹¥¯¤«¤éµ¯Æ°¤¹¤ë¤è¤¦¤Ç¤·¤¿¤é¡¢ ¥­¡¼¥Ü¡¼¥É¤«¤é L1A ¤Þ¤¿¤Ï StopA ¤ò²¡¤¹¤«¡¢¥·¥ê¥¢¥ë¥³¥ó¥½¡¼¥ë¤«¤é BREAK (¤¿¤È¤¨¤Ð¡¢&man.tip.1; ¤Þ¤¿¤Ï &man.cu.1; ¤Ç¤Ï ~#) ¤òÁ÷¿®¤·¤Æ¡¢ PROM ¥×¥í¥ó¥×¥È¤òɽ¼¨¤·¤Æ¤¯¤À¤µ¤¤¡£ ¼¡¤Î¤è¤¦¤Êɽ¼¨¤Ç¤¹¡£ ok ok {0} ñ°ì¤Î CPU ¤ò»ý¤Ä¥·¥¹¥Æ¥à¤Ç¤Î¥×¥í¥ó¥×¥È SMP ¥·¥¹¥Æ¥à¤Î¥×¥í¥ó¥×¥È¡£¿ô»ú¤Ï¥¢¥¯¥Æ¥£¥Ö¤Ê CPU ¤Î¿ô¡£ ¤³¤³¤Ç¡¢CDROM ¤ò¥É¥é¥¤¥Ö¤ËÁÞÆþ¤·¡¢ PROM ¥×¥í¥ó¥×¥È¤Ç boot cdrom ¤ÈÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£
¥Ç¥Ð¥¤¥¹¸¡½Ð·ë²Ì¤òºÆÉ½¼¨¤¹¤ë ²èÌ̤Ëɽ¼¨¤µ¤ì¤ë¿ôÉ´¹Ô¤Îʸ»úÎó¤Ï (¥Ð¥Ã¥Õ¥¡¤Ë) µ­²±¤µ¤ì¤Æ¤ª¤ê¡¢ ºÆÉ½¼¨¤¹¤ë¤³¤È¤¬½ÐÍè¤Þ¤¹¡£ ¥Ð¥Ã¥Õ¥¡¤òºÆÉ½¼¨¤¹¤ë¤Ë¤Ï¡¢Scroll Lock ¥­¡¼¤ò²¡¤·¤Þ¤¹¡£ ¤³¤ì¤Ç²èÌ̤ò¥¹¥¯¥í¡¼¥ë¤Ç¤­¤Þ¤¹¡£·ë²Ì¤ò¸«¤ë¤¿¤á¤Ë¤Ï¡¢Ìð°õ¥­¡¼¤â¤·¤¯¤Ï PageUp ¤« PageDown ¤ò»È¤¤¤Þ¤¹¡£ Scroll Lock ¤ò¤â¤¦°ìÅÙ²¡¤¹¤È¡¢¥¹¥¯¥í¡¼¥ë¤òÄä»ß¤·¤Þ¤¹¡£ ľ¤Á¤Ë¤³¤Îºî¶È¤ò¹Ô¤Ã¤Æ¡¢¥«¡¼¥Í¥ë¤¬¥Ç¥Ð¥¤¥¹¸¡½Ð¤ò¼Â¹Ô¤·¤Æ¤¤¤ë»þ¤Ë ²èÌ̤γ°¤Ëή¤ì¤¿Ê¸»úÎó¤òºÆÉ½¼¨¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤Ë¤è¤¯»÷¤¿²èÌ̤¬¸½¤ï¤ì¤ë¤Ç¤·¤ç¤¦¡£ ¤¿¤À¤·¡¢¤¢¤Ê¤¿¤Î¥³¥ó¥Ô¥å¡¼¥¿¤ËÅëºÜ¤µ¤ì¤Æ¤¤¤ë¥Ç¥Ð¥¤¥¹¤Ë¤è¤Ã¤Æ¡¢ ɽ¼¨¤µ¤ì¤ëʸ»úÎó¤Ï°Û¤Ê¤ê¤Þ¤¹¡£
ŵ·¿Åª¤Ê¥Ç¥Ð¥¤¥¹¸¡½Ð·ë²Ì¤ÎÎã Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0 r225473M: Sun Sep 11 16:07:30 BST 2011 root@psi:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz (2527.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x8e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 2926649344 (2791 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <TOSHIB A0064 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 <Version 2.0> irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <TOSHIB A0064> on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, b6690000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 cpu0: <ACPI CPU> on acpi0 ACPI Warning: Incorrect checksum in table [ASF!] - 0xFE, should be 0x9A (20110527/tbutils-282) cpu1: <ACPI CPU> on acpi0 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0 vgapci0: <VGA-compatible display> port 0xcff8-0xcfff mem 0xff400000-0xff7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: <Intel GM45 SVGA controller> on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory vgapci1: <VGA-compatible display> mem 0xffc00000-0xffcfffff at device 2.1 on pci0 pci0: <simple comms> at device 3.0 (no driver attached) em0: <Intel(R) PRO/1000 Network Connection 7.2.3> port 0xcf80-0xcf9f mem 0xff9c0000-0xff9dffff,0xff9fe000-0xff9fefff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:1c:7e:6a:ca:b0 uhci0: <Intel 82801I (ICH9) USB controller> port 0xcf60-0xcf7f irq 16 at device 26.0 on pci0 usbus0: <Intel 82801I (ICH9) USB controller> on uhci0 uhci1: <Intel 82801I (ICH9) USB controller> port 0xcf40-0xcf5f irq 21 at device 26.1 on pci0 usbus1: <Intel 82801I (ICH9) USB controller> on uhci1 uhci2: <Intel 82801I (ICH9) USB controller> port 0xcf20-0xcf3f irq 19 at device 26.2 on pci0 usbus2: <Intel 82801I (ICH9) USB controller> on uhci2 ehci0: <Intel 82801I (ICH9) USB 2.0 controller> mem 0xff9ff800-0xff9ffbff irq 19 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: <Intel 82801I (ICH9) USB 2.0 controller> on ehci0 hdac0: <Intel 82801I High Definition Audio Controller> mem 0xff9f8000-0xff9fbfff irq 22 at device 27.0 on pci0 pcib1: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0 pci1: <ACPI PCI bus> on pcib1 iwn0: <Intel(R) WiFi Link 5100> mem 0xff8fe000-0xff8fffff irq 16 at device 0.0 on pci1 pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0 pci2: <ACPI PCI bus> on pcib2 pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0 pci4: <ACPI PCI bus> on pcib3 pcib4: <ACPI PCI-PCI bridge> at device 30.0 on pci0 pci5: <ACPI PCI bus> on pcib4 cbb0: <RF5C476 PCI-CardBus Bridge> at device 11.0 on pci5 cardbus0: <CardBus bus> on cbb0 pccard0: <16-bit PCCard bus> on cbb0 isab0: <PCI-ISA bridge> at device 31.0 on pci0 isa0: <ISA bus> on isab0 ahci0: <Intel ICH9M AHCI SATA controller> port 0x8f58-0x8f5f,0x8f54-0x8f57,0x8f48-0x8f4f,0x8f44-0x8f47,0x8f20-0x8f3f mem 0xff9fd800-0xff9fdfff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported ahcich0: <AHCI channel> at channel 0 on ahci0 ahcich1: <AHCI channel> at channel 1 on ahci0 ahcich2: <AHCI channel> at channel 4 on ahci0 acpi_lid0: <Control Method Lid Switch> on acpi0 battery0: <ACPI Control Method Battery> on acpi0 acpi_button0: <Power Button> on acpi0 acpi_acad0: <AC Adapter> on acpi0 acpi_toshiba0: <Toshiba HCI Extras> on acpi0 acpi_tz0: <Thermal Zone> on acpi0 attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: <Enhanced SpeedStep Frequency Control> on cpu0 p4tcc0: <CPU Frequency Thermal Control> on cpu0 est1: <Enhanced SpeedStep Frequency Control> on cpu1 p4tcc1: <CPU Frequency Thermal Control> on cpu1 Timecounters tick every 1.000 msec hdac0: HDA Codec #0: Realtek ALC268 hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) pcm0: <HDA Realtek ALC268 PCM #0 Analog> at cad 0 nid 1 on hdac0 pcm1: <HDA Realtek ALC268 PCM #1 Analog> at cad 0 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: <Intel> at usbus0 uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 ugen1.1: <Intel> at usbus1 uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 ugen2.1: <Intel> at usbus2 uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2 ugen3.1: <Intel> at usbus3 uhub3: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen2.2: <vendor 0x0b97> at usbus2 uhub8: <vendor 0x0b97 product 0x7761, class 9/0, rev 1.10/1.10, addr 2> on usbus2 ugen1.2: <Microsoft> at usbus1 ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: <Hitachi HTS543225L9SA00 FBEOC43C> ATA-8 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ums0: <Microsoft Microsoft 3-Button Mouse with IntelliEyeTM, class 0/0, rev 1.10/3.00, addr 2> on usbus1 SMP: AP CPU #1 Launched! cd0 at ahcich1 bus 0 scbus2 target 0 lun 0 cd0: <TEAC DV-W28S-RT 7.0C> Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, ums0: 3 buttons and [XYZ] coordinates ID=0 UDMA2, ATAPI 12bytes, PIO 8192bytes) cd0: cd present [1 x 2048 byte records] ugen0.2: <Microsoft> at usbus0 ukbd0: <Microsoft Natural Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2> on usbus0 kbd2 at ukbd0 uhid0: <Microsoft Natural Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2> on usbus0 Trying to mount root from cd9660:/dev/iso9660/FREEBSD_INSTALL [ro]...
ðǰ¤Ë¸¡½Ð·ë²Ì¤ò¥Á¥§¥Ã¥¯¤·¤Æ¡¢¤¢¤Ê¤¿¤¬Í½´ü¤·¤¿¤¹¤Ù¤Æ¤Î¥Ç¥Ð¥¤¥¹¤ò &os; ¤¬¸¡½Ð¤Ç¤­¤¿»ö¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£¥Ç¥Ð¥¤¥¹¤¬¸«¤Ä¤«¤é¤Ê¤«¤Ã¤¿¾ì¹ç¡¢ ¸¡½Ð·ë²Ì¤ØÉ½¼¨¤µ¤ì¤Þ¤»¤ó¡£ ¥«¡¼¥Í¥ë¥â¥¸¥å¡¼¥ë ¤ò¹½ÃÛ¤¹¤ë¤³¤È¤Ç¡¢ GENERIC ¥«¡¼¥Í¥ë¤Ë´Þ¤Þ¤ì¤Æ¤¤¤Ê¤¤¥Ç¥Ð¥¤¥¹¤Î¥µ¥Ý¡¼¥È¤òÄɲäǤ­¤Þ¤¹¡£ ¥Ç¥Ð¥¤¥¹¸¡½Ð¸å¡¢ ¤¬É½¼¨¤µ¤ì¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤Ï¡¢&os; ¤Î¥¤¥ó¥¹¥È¡¼¥ë¡¢ live CD¡¢¤Þ¤¿¤Ï &os; ¥·¥§¥ë¤Ø¤Î¥¢¥¯¥»¥¹¤Î 3 ¤Ä¤ÎÌÜŪ¤ËÍøÍѽÐÍè¤Þ¤¹¡£ Ìð°õ¥­¡¼¤ò»È¤Ã¤Æ¥ª¥×¥·¥ç¥ó¤òÁªÂò¤·¡¢ Enter ¤ò²¡¤·¤Æ¤¯¤À¤µ¤¤¡£
¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤ÎÁªÂò¥â¡¼¥É
¤³¤³¤Ç [ Install ] ¤òÁªÂò¤¹¤ë¤È¡¢¥¤¥ó¥¹¥È¡¼¥ëºî¶È¤¬»Ï¤Þ¤ê¤Þ¤¹¡£
<application>bsdinstall</application> ¤Î¾Ò²ð bsdinstall ¤Ï¡¢&a.nwhitehorn.email; ¤Ë¤è¤ê½ñ¤«¤ì¤¿¡¢ ¥Æ¥­¥¹¥È¥Ù¡¼¥¹¤Î¥¤¥ó¥¹¥È¡¼¥ë¥×¥í¥°¥é¥à¤Ç¤¹¡£ 2011 ǯ¤Î &os; 9.0 ¤ÇƳÆþ¤µ¤ì¤Þ¤·¤¿¡£ &a.kmoore.email; ¤Î pc-sysinstall ¤Ï¡¢ PC-BSD ¤Ë´Þ¤Þ¤ì¤Æ¤ª¤ê¡¢ &os; ¤Î¥¤¥ó¥¹¥È¡¼¥ë ¤Ë¤â»ÈÍѤǤ­¤Þ¤¹¡£ bsdinstall ¤Èº®Æ±¤µ¤ì¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹¤¬¡¢ ¤³¤Î 2 ¤Ä¤Î¥¤¥ó¥¹¥È¡¼¥é¤Ë¤Ï´Ø·¸¤Ï¤¢¤ê¤Þ¤»¤ó¡£ bsdinstall ¤Î¥á¥Ë¥å¡¼¤Ï¡¢¥«¡¼¥½¥ë¥­¡¼¡¢ Enter, Tab, Space Åù¤ÇÁàºî¤·¤Þ¤¹¡£ ¥­¡¼ÇÛÎó¥á¥Ë¥å¡¼¤ÎÁªÂò »ÈÍѤ·¤Æ¤¤¤ë¥·¥¹¥Æ¥à¤Î¥³¥ó¥½¡¼¥ë¤Ë¤â¤è¤ê¤Þ¤¹¤¬¡¢ bsdinstall ¤Ï¡¢ ºÇ½é¤Ë¥Ç¥Õ¥©¥ë¥È°Ê³°¤Î¥­¡¼¥Ü¡¼¥É¥ì¥¤¥¢¥¦¥È»È¤¦¤«¤É¤¦¤«¤ò¿Ò¤Í¤Æ¤­¤Þ¤¹¡£
¥­¡¼¥Þ¥Ã¥×¤ÎÁªÂò
[ YES ] ¤òÁªÂò¤¹¤ë¤È¡¢ °Ê²¼¤Î¥­¡¼¥Ü¡¼¥ÉÁªÂò²èÌ̤¬É½¼¨¤µ¤ì¤Þ¤¹¡£ ¤½¤¦¤Ç¤Ê¤±¤ì¤Ð¡¢¤³¤ÎÁªÂò¥á¥Ë¥å¡¼¤Ïɽ¼¨¤µ¤ì¤º¡¢ ¥Ç¥Õ¥©¥ë¥È¤Î¥­¡¼¥Ü¡¼¥É¥Þ¥Ã¥×¤¬»È¤ï¤ì¤Þ¤¹¡£
¥­¡¼¥Ü¡¼¥É¥á¥Ë¥å¡¼¤ÎÁªÂò
¥·¥¹¥Æ¥à¤Î¥­¡¼¥Ü¡¼¥É¤ËºÇ¤â¶á¤¤¥­¡¼¥Þ¥Ã¥×¤ò¾å²¼¤Î¥«¡¼¥½¥ë¥­¡¼¤ÇÁª¤Ó¡¢ Enter ¥­¡¼¤ò²¡¤·¤Æ¤¯¤À¤µ¤¤¡£ Esc ¤ò²¡¤¹¤È¡¢ ¥Ç¥Õ¥©¥ë¥È¤Î¥­¡¼¥Ü¡¼¥É¥Þ¥Ã¥×¤ò»È¤¦¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤É¤Î¥­¡¼¥Ü¡¼¥É¥Þ¥Ã¥×¤òÁª¤Ù¤Ð¤è¤¤¤«¤ï¤«¤é¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢ United States of America ISO-8859-1 ¥­¡¼¥Þ¥Ã¥×¤òÁª¤Ö¤È¤è¤¤¤Ç¤·¤ç¤¦¡£
¥Û¥¹¥È̾¤ÎÀßÄê ¼¡¤Ë bsdinstall ¤Ï¡¢ ¿·¤·¤¯¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥·¥¹¥Æ¥à¤ËÍ¿¤¨¤ë¥Û¥¹¥È̾¤ÎÆþÎϤ˰ܤê¤Þ¤¹¡£
¥Û¥¹¥È̾¤ÎÀßÄê
ÆþÎϤ¹¤ë¥Û¥¹¥È̾¤Ï¡¢ machine3.example.com ¤Î¤è¤¦¤Ë´°Á´½¤¾þ¤Î¥Û¥¹¥È̾¤ÇÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£
¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥³¥ó¥Ý¡¼¥Í¥ó¥È¤ÎÀßÄê ¼¡¤Ë¡¢ bsdinstall ¤Ï¡¢¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥ª¥×¥·¥ç¥ó¤Î¥³¥ó¥Ý¡¼¥Í¥ó¥È¤ÎÁªÂò¤Ë°Ü¤ê¤Þ¤¹¡£
¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥³¥ó¥Ý¡¼¥Í¥ó¥È¤ÎÀßÄê
¤É¤Î¥³¥ó¥Ý¡¼¥Í¥ó¥È¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤«¤Ï¡¢ ¥·¥¹¥Æ¥à¤ÎÍÑÅÓ¤ÈÍѰդµ¤ì¤Æ¤¤¤ë¥Ç¥£¥¹¥¯ÍÆÎ̤˰͸¤·¤Þ¤¹¡£ &os; ¥«¡¼¥Í¥ë¤È¥æ¡¼¥¶¥é¥ó¥É (Áí¾Î ¤Ï base system) ¤Ï¡¢ ¾ï¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤Î¥¿¥¤¥×¤Ë¤è¤Ã¤Æ¤Ïɽ¼¨¤µ¤ì¤Ê¤¤¥³¥ó¥Ý¡¼¥Í¥ó¥È¤â¤¢¤ê¤Þ¤¹¡£ ¥ª¥×¥·¥ç¥ó¤Î¥³¥ó¥Ý¡¼¥Í¥ó¥È doc - ÄɲäÎʸ½ñ¡£Â¿¤¯¤ÏÎò»ËŪ¤Ê¶½Ì£¤Î¤â¤Î¤Ç¤¹¡£ &os; ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥×¥í¥¸¥§¥¯¥È¤¬Ä󶡤·¤Æ¤¤¤ëʸ½ñ¤Ï¡¢ ¤¢¤È¤Ç¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ games - fortune, rot13 ¤Ê¤É¤ÎÅÁÅýŪ¤Ê BSD ¥²¡¼¥à¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Þ¤¹¡£ lib32 - 32-bit ¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤ò 64-bit ÈǤΠ&os; ¤Ç¼Â¹Ô¤¹¤ëºÝ¤ËɬÍפȤʤë¸ß´¹¥é¥¤¥Ö¥é¥ê¡£ ports - &os; Ports Collection Ports Collection ¤Ï¡¢ ¥½¥Õ¥È¥¦¥§¥¢¤Î¥¤¥ó¥¹¥È¡¼¥ë¤ò´Êñ¤Ë¹Ô¤¦ÊýË¡¤òÄ󶡤·¤Þ¤¹¡£ Ports Collection ¤Ï¡¢ ¥½¥Õ¥È¥¦¥§¥¢¤ò¥³¥ó¥Ñ¥¤¥ë¤¹¤ë¤Î¤ËɬÍפʥ½¡¼¥¹¥³¡¼¥É¤ò´Þ¤ó¤Ç¤¤¤Þ¤»¤ó¡£ ¥µ¡¼¥É¥Ñ¡¼¥Æ¥£À½¥½¥Õ¥È¥¦¥§¥¢¥Ñ¥Ã¥±¡¼¥¸¤Î¥À¥¦¥ó¥í¡¼¥É¡¢ ¥³¥ó¥Ñ¥¤¥ë¡¢¥¤¥ó¥¹¥È¡¼¥ë¤ò¼«Æ°²½¤¹¤ë¤è¤¦¤ËÀ߷פµ¤ì¤¿¥Õ¥¡¥¤¥ë¤Î½¸¤Þ¤ê¤Ç¤¹¡£ Ports Collection ¤Î»È¤¤Êý¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¤ÇÀâÌÀ¤·¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¥×¥í¥°¥é¥à¤Ï¡¢ ¥·¥¹¥Æ¥à¤Î¥Ç¥£¥¹¥¯¤Ë½½Ê¬¤Ê¶õ¤­ÍÆÎ̤¬¤¢¤ë¤«¤É¤¦¤«¤ò³Îǧ¤·¤Ê¤¤¤Î¤Ç¡¢ ¤³¤Î¥ª¥×¥·¥ç¥ó¤òÁªÂò¤¹¤ëºÝ¤Ë¤Ï¡¢ ¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤ÎÍÆÎ̤¬½½Ê¬¤¢¤ë¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ &os; 9.0 ¤Ç¤Ï¡¢Ports Collection ¤¬É¬ÍפȤ¹¤ëÍÆÎ̤ϡ¢ Ìó &ports.size; ¤Ç¤¹¡£ ¤è¤êºÇ¿·¤Î &os; ¤Î¥Ð¡¼¥¸¥ç¥ó¤Ç¤Ï¡¢ °ÂÁ´¤Î¤¿¤á¤Ë¤â¤¦¾¯¤·Â礭¤Ê¥µ¥¤¥º¤òÁÛÄꤷ¤Æ¤¯¤À¤µ¤¤¡£ src - ¥·¥¹¥Æ¥à¤Î¥½¡¼¥¹¥³¡¼¥É &os; ¤Ë¤Ï¡¢ ¥«¡¼¥Í¥ë¤È¥æ¡¼¥¶¥é¥ó¥ÉξÊý¤Î¥½¡¼¥¹¥³¡¼¥É¤¬ÉÕ°¤·¤Æ¤¤¤Þ¤¹¡£ ¤Û¤È¤ó¤É¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤ÏɬÍפȤ·¤Þ¤»¤ó¤¬¡¢ ¥½¡¼¥¹¤ÇÄ󶡤µ¤ì¤Æ¤¤¤ë¥½¥Õ¥È¥¦¥§¥¢ (¥Ç¥Ð¥¤¥¹¥É¥é¥¤¥Ð¤ä¥«¡¼¥Í¥ë¥â¥¸¥å¡¼¥ë¤Ê¤É) ¤Ë¤è¤Ã¤Æ¤Ï¥³¥ó¥Ñ¥¤¥ë»þ¡¢ ¤Þ¤¿¤Ï &os; ¤½¤Î¤â¤Î¤ò³«È¯¤¹¤ë¾ì¹ç¤ËɬÍפȤʤê¤Þ¤¹¡£ ¤¹¤Ù¤Æ¤Î¥½¡¼¥¹¥Ä¥ê¡¼¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤Ë¤Ï 1 GB ¤Î¥Ç¥£¥¹¥¯ÍÆÎ̤òɬÍפȤ·¤Þ¤¹¡£ ¤Þ¤¿¡¢&os; ¥·¥¹¥Æ¥àÁ´ÂΤΥ³¥ó¥Ñ¥¤¥ë¤Ë¤Ï¡¢ ¤µ¤é¤Ë 5 GB ¤ÎÍÆÎ̤¬É¬ÍפǤ¹¡£
¥Í¥Ã¥È¥ï¡¼¥¯¤«¤é¤Î¥¤¥ó¥¹¥È¡¼¥ë bootonly ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤Ï¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¥Õ¥¡¥¤¥ë¤ò´Þ¤ó¤Ç¤¤¤Þ¤»¤ó¡£ bootonly ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤ò»È¤¦¾ì¹ç¤Ë¤Ï¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯·Ðͳ¤Ç¥Õ¥¡¥¤¥ë¤ò¥À¥¦¥ó¥í¡¼¥É¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
¥Í¥Ã¥È¥ï¡¼¥¯¤«¤é¤Î¥¤¥ó¥¹¥È¡¼¥ë
¤Ë¼¨¤µ¤ì¤Æ¤¤¤ë¤è¤¦¤Ë¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯Àܳ¤ÎÀßÄ꤬½ª¤ï¤Ã¤Æ¤¤¤ì¤Ð¡¢¥ß¥é¡¼¥µ¥¤¥È¤¬ÁªÂò¤µ¤ì¤Þ¤¹¡£ ¥ß¥é¡¼¥µ¥¤¥È¤Ï¡¢&os; ¥Õ¥¡¥¤¥ë¤Î¥³¥Ô¡¼¤ò¥­¥ã¥Ã¥·¥å¤·¤Æ¤¤¤Þ¤¹¡£ &os; ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥³¥ó¥Ô¥å¡¼¥¿¤ÈƱ¤¸Ãϰè¤Î¥ß¥é¡¼¥µ¥¤¥È¤òÁª¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¥¿¡¼¥²¥Ã¥È¥³¥ó¥Ô¥å¡¼¥¿¤Î¶á¤¯¤Ë¥ß¥é¡¼¤¬¤¢¤ë¤È¡¢ ¥Õ¥¡¥¤¥ë¤Î¥À¥¦¥ó¥í¡¼¥É¤ÏÁ᤯½ª¤ï¤ë¤Î¤Ç¡¢¥¤¥ó¥¹¥È¡¼¥ë¤Î»þ´Ö¤¬Ã»¤¯¤Ê¤ê¤Þ¤¹¡£
¥ß¥é¡¼¥µ¥¤¥È¤ÎÁªÂò
¥¤¥ó¥¹¥È¡¼¥ë¥Õ¥¡¥¤¥ë¤ò¥í¡¼¥«¥ë¥á¥Ç¥£¥¢¤ËÍѰդǤ­¤¿¤é¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤ÏÀè¤Ë¿Ê¤ß¤Þ¤¹¡£
¥Ç¥£¥¹¥¯Îΰè¤Î³ä¤êÅö¤Æ &os; ¤Ø¥Ç¥£¥¹¥¯Îΰè¤ò³ä¤êÅö¤Æ¤ë¤Ë¤Ï 3 ¤Ä¤ÎÊýË¡¤¬¤¢¤ê¤Þ¤¹¡£ Guided ¤Ë¤è¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Îʬ³äÊýË¡¤Ç¤Ï¡¢ ¥Ç¥£¥¹¥¯¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò¼«Æ°Åª¤ËÀßÄꤷ¤Þ¤¹¡£ °ìÊý Manual ¤Ë¤è¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Îʬ³äÊýË¡¤Ï¡¢ ¹âÅÙ¤ÊÃ챤ò»ý¤Ä¥æ¡¼¥¶¸þ¤±¤Ç¡¢ ¥«¥¹¥¿¥Þ¥¤¥º¤·¤¿¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤Ç¤­¤Þ¤¹¡£ 3 ¤ÄÌܤÎÊýË¡¤È¤·¤Æ¡¢¥·¥§¥ë¤òÍøÍѤ·¡¢&man.gpart.8;, &man.fdisk.8;, &man.bsdlabel.8; ¤Î¤è¤¦¤Ê¥³¥Þ¥ó¥É¥é¥¤¥ó¤Î¥×¥í¥°¥é¥à¤ò¼Â¹Ô¤¹¤ëÊýË¡¤¬¤¢¤ê¤Þ¤¹¡£
¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Îʬ³ä¤Ë Guided ¤È Manual ¤Î¤É¤Á¤é¤òÍѤ¤¤ë¤«¤ÎÁªÂò
Guided ¤Ë¤è¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Îʬ³ä Ê£¿ô¤Î¥Ç¥£¥¹¥¯¤¬Àܳ¤µ¤ì¤Æ¤¤¤ë¾ì¹ç¤Ë¤Ï¡¢ &os; ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥Ç¥£¥¹¥¯¤òÁªÂò¤·¤Æ¤¯¤À¤µ¤¤¡£
Ê£¿ô¤Î¥Ç¥£¥¹¥¯¤«¤éÁªÂò¤¹¤ë
¥Ç¥£¥¹¥¯¤Î¤¹¤Ù¤Æ¡¢¤Þ¤¿¤Ï°ìÉô¤ò &os; ¤Ë³ä¤êÅö¤Æ¤Þ¤¹¡£ [ Entire Disk ] ¤òÁªÂò¤¹¤ë¤È¡¢ °ìÈÌŪ¤Ê¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥ì¥¤¥¢¥¦¥È¤¬ºîÀ®¤µ¤ì¤Þ¤¹¡£ [ Partition ] ¤òÁªÂò¤¹¤ë¤È¡¢ ¥Ç¥£¥¹¥¯¤Î»ÈÍѤ·¤Æ¤¤¤Ê¤¤Îΰè¤Ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥ì¥¤¥¢¥¦¥È¤òºîÀ®¤·¤Þ¤¹¡£
Entire Disk ¤Þ¤¿¤Ï Partition ¤ÎÁªÂò
¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Î¥ì¥¤¥¢¥¦¥È¤òºîÀ®¤·¤¿¤é¡¢ Àµ¤·¤¯ºîÀ®¤Ç¤­¤Æ¤¤¤ë¤«¤É¤¦¤«Ãí°Õ¿¼¤¯³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ´Ö°ã¤¤¤òȯ¸«¤·¤¿¤é¡¢ [ Revert ] ¤òÁªÂò¤·¤Æ¡¢ ľÁ°¤ËºîÀ®¤·¤¿¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò¥ê¥»¥Ã¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤Þ¤¿¡¢[ Auto ] ¤òÁªÂò¤¹¤ë¤È¡¢ ¼«Æ°Åª¤Ë¤â¤¦°ìÅÙ &os; ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤·¤Þ¤¹¡£ ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò¼êư¤ÇºîÀ®¡¢Êѹ¹¡¢ºï½ü¤Ç¤­¤Þ¤¹¡£ Àµ¤·¤¯¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®½ÐÍ褿¤é¡¢ [ Finish ] ¤òÁªÂò¤·¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤ò¿Ê¤á¤Æ¤¯¤À¤µ¤¤¡£
ºîÀ®¤µ¤ì¤¿¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Î³Îǧ
Manual ¤Ë¤è¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Îʬ³ä Manual ¤Ë¤è¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Îʬ³ä¤Ç¤Ï¡¢ ľÀܥѡ¼¥Æ¥£¥·¥ç¥ó¥¨¥Ç¥£¥¿¤¬µ¯Æ°¤·¤Þ¤¹¡£
Manual ¤Ë¤è¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Îʬ³ä
¥É¥é¥¤¥Ö (¤³¤ÎÎã¤Ç¤Ï ada0) ¤òÁª¤Ó¡¢ [ Create ] ¤òÁªÂò¤¹¤ë¤È¡¢ partitioning scheme ¤òÁªÂò¤¹¤ë¥á¥Ë¥å¡¼¤¬É½¼¨¤µ¤ì¤Þ¤¹¡£
¼êư¤Ç¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤¹¤ë
PC ¸ß´¹¤Î¥³¥ó¥Ô¥å¡¼¥¿¤Ç¤Ï¡¢Ä̾ï GPT ¤Ë¤è¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥óʬ³ä¤¬ºÇ¤âŬÀÚ¤ÊÁªÂò¤È¤Ê¤ê¤Þ¤¹¡£ GPT ¤ËÂбþ¤·¤Æ¤¤¤Ê¤¤¤è¤¦¤Ê¸Å¤¤ PC ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Ç¤Ï¡¢ MBR ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò»È¤¦É¬Íפ¬¤¢¤ê¤Þ¤¹¡£ ¾¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¹¥­¡¼¥à¤Ï¡¢»È¤¦¤³¤È¤¬¤Þ¤ì¤Ç¤¢¤Ã¤¿¤ê¡¢ ¸Å¤¤¥³¥ó¥Ô¥å¡¼¥¿¤ÇÍѤ¤¤é¤ì¤Þ¤¹¡£ ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¹¥­¡¼¥à ¾Êά·Á ÀâÌÀ APM Apple ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥Þ¥Ã¥×¡£ &powerpc; &macintosh; ¤Ç»È¤ï¤ì¤Þ¤¹¡£ BSD MBR ¤òÍѤ¤¤Ê¤¤ BSD ¥é¥Ù¥ë¡£¤·¤Ð¤·¤Ð "dangerously dedicated mode" ¤È¸Æ¤Ð¤ì¤Þ¤¹¡£ &man.bsdlabel.8; ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ GPT GUID ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥Æ¡¼¥Ö¥ë MBR Master Boot Record PC98 MBR ¤Î°¡¼ï¡£NEC PC-98 ¥³¥ó¥Ô¥å¡¼¥¿¤Ç»È¤ï¤ì¤Þ¤¹¡£ VTOC8 Volume Table Of Contents¡£ Sun SPARC64 ¤ª¤è¤Ó UltraSPARC ¥³¥ó¥Ô¥å¡¼¥¿¤Ç»È¤ï¤ì¤Þ¤¹¡£
¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¹¥­¡¼¥à¤òÁªÂò¤·¤ÆºîÀ®¤·¤¿¸å¤Ç¡¢ ¤â¤¦°ìÅÙ [ Create ] ¤òÁªÂò¤¹¤ë¤È¡¢ ¿·¤·¤¤¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤¬ºîÀ®¤µ¤ì¤Þ¤¹¡£
¼êư¤Ç¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤¹¤ë
ɸ½à¤Î &os; GPT ¤Î¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤Ï¡¢ ¾¯¤Ê¤¯¤È¤â 3 ¤Ä¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤¬»È¤ï¤ì¤Þ¤¹¡£ ɸ½àŪ¤Ê &os; <acronym>GPT</acronym> ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó freebsd-boot - &os; ¥Ö¡¼¥È¥³¡¼¥É¡£ freebsd-ufs - &os; UFS ¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¡£ freebsd-swap - &os; ¥¹¥ï¥Ã¥×¶õ´Ö¡£ ¾¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó·Á¼°¤Ë freebsd-zfs ¤¬¤¢¤ê¤Þ¤¹¡£ ¤³¤ì¤Ï &os; ZFS ¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ò´Þ¤á¤ë¤¿¤á¤Î¤â¤Î¤Ç¤¹¡£ The Z File System (ZFS) ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ÍøÍѲÄǽ¤Ê GPT ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¿¥¤¥×¤Ë¤Ä¤¤¤Æ¤Ï¡¢&man.gpart.8; ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ Ê£¿ô¤Î¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò»È¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ /, /var, /tmp ¤½¤·¤Æ /usr ¤È¤¤¤Ã¤¿ÅÁÅýŪ¤Ê¥Ñ¡¼¥Æ¥£¥·¥ç¥óʬ³ä¤Î¥ì¥¤¥¢¥¦¥È¤ò¹¥¤à¿Í¤â¤¤¤Þ¤¹¡£ ¥ì¥¤¥¢¥¦¥È¤ÎÎ㤬 ¤Ë¤¢¤ê¤Þ¤¹¡£ ¥µ¥¤¥º¤òÆþÎϤ¹¤ëºÝ¤Ë¡¢ K (¥­¥í¥Ð¥¤¥È)¡¢M (¥á¥¬¥Ð¥¤¥È)¡¢ G (¥®¥¬¥Ð¥¤¥È) ¤È¤¤¤Ã¤¿Ä̾ï¤Î¾Êά·Á¤ò»ÈÍѽÐÍè¤Þ¤¹¡£ ¥»¥¯¥¿¤òŬÀÚ¤ËÇÛÃÖ¤¹¤ë¤³¤È¤Ç¡¢ ºÇÎɤΥѥե©¡¼¥Þ¥ó¥¹¤òÆÀ¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤Þ¤¿¡¢¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥µ¥¤¥º¤ò 4K ¥Ð¥¤¥È¤Î¶ö¿ôÇܤˤ¹¤ë¤È¡¢ 512 ¥Ð¥¤¥È¤Þ¤¿¤Ï 4K ¥Ð¥¤¥È¤Î¥»¥¯¥¿¤Ç¥É¥é¥¤¥Ö¤¬ÇÛÃÖ¤·¤ä¤¹¤¯¤Ê¤ê¤Þ¤¹¡£ °ìÈÌŪ¤Ë¡¢ 4K ¤Î¶ö¿ôÇܤξì½ê¤«¤é¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤¬³«»Ï¤¹¤ë¤è¤¦¤ËÀßÄꤹ¤ë´Êñ¤ÊÊýË¡¤Ï¡¢ 1M ¤Þ¤¿¤Ï 1G ¤Î¶ö¿ôÇܤΥѡ¼¥Æ¥£¥·¥ç¥ó¥µ¥¤¥º¤òÍѤ¤¤ë¤³¤È¤Ç¤¹¡£ ¤¿¤À¤·¡¢Îã³°¤¬¤¢¤ê¡¢¸½ºß¤Î¤È¤³¤í freebsd-boot ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ï¡¢ ¥Ö¡¼¥È¥³¡¼¥É¤ÎÀ©¸Â¤Ë¤è¤ê 512K °Ê²¼¤Ç¤¢¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ò»ý¤Ä¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ç¤Ï¡¢ ¥Þ¥¦¥ó¥È¥Ý¥¤¥ó¥È¤¬É¬ÍפȤʤê¤Þ¤¹¡£ 1 ¤Ä¤Î UFS ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤À¤±¤òºîÀ®¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¥Þ¥¦¥ó¥È¥Ý¥¤¥ó¥È¤Ï / ¤È¤Ê¤ê¤Þ¤¹¡£ ƱÍÍ¤Ë label ¤ÎºîÀ®¤âɬÍפǤ¹¡£ ¥é¥Ù¥ë¤ÏºîÀ®¤·¤¿¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òǧ¼±¤¹¤ë¤¿¤á¤Î̾Á°¤Ç¤¹¡£ ¥É¥é¥¤¥Ö̾¤äÈÖ¹æ¤Ï¡¢ ¥É¥é¥¤¥Ö¤¬Ê̤Υ³¥ó¥È¥í¡¼¥é¤ä¥Ý¡¼¥È¤ËÀܳ¤µ¤ì¤ë¤ÈÊѤï¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¤¬¡¢ ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥é¥Ù¥ë¤ÏÊѤï¤ê¤Þ¤»¤ó¡£ /etc/fstab ¤Î¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤ÎÃæ¤Ç¡¢ ¥É¥é¥¤¥Ö̾¤ä¥Ñ¡¼¥Æ¥£¥·¥ç¥óÈÖ¹æ¤Ç¤Ï¤Ê¤¯¡¢¥é¥Ù¥ë¤ò»²¾È¤¹¤ë¤³¤È¤Ë¤è¤ê¡¢ ¥·¥¹¥Æ¥à¤¬¥Ï¡¼¥É¥¦¥§¥¢¤ÎÊѹ¹¤ËÂФ·¤Æ¡¢¤è¤ê´²ÍƤˤʤê¤Þ¤¹¡£ GPT ¤Î¥é¥Ù¥ë¤Ï¡¢¥Ç¥£¥¹¥¯¤¬Àܳ¤µ¤ì¤ë¤È /dev/gpt/ ¤Ë¸½¤ì¤Þ¤¹¡£Â¾¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¹¥­¡¼¥à¤Ç¤ÏÊ̤Υé¥Ù¥ë¤È¤Ê¤ê¡¢ /dev/ °Ê²¼¤Î°Û¤Ê¤ë¥Ç¥£¥ì¥¯¥È¥ê¤Ë¥é¥Ù¥ë¤¬¸½¤ì¤Þ¤¹¡£ Ʊ¤¸Ì¾Á°¤Ë¤è¤ë¾×ÆÍ¤òÈò¤±¤ë¤¿¤á¡¢ ¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ËÂФ·¡¢°ì°ÕŪ¤Ê̾Á°»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¥³¥ó¥Ô¥å¡¼¥¿Ì¾¡¢»ÈÍÑ¡¢°ÌÃÖ¾ðÊó¤òɽ¤¹Ã±¸ì¤ò¥é¥Ù¥ë¤ËÄɲäǤ­¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð¡¢¸¦µæ¼¼¤Î¥³¥ó¥Ô¥å¡¼¥¿¤Î UFS ¤Î¥ë¡¼¥È¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò "labroot" ¤Þ¤¿¤Ï "rootfs-lab" ¤È¤·¤Þ¤¹¡£ ÅÁÅýŪ¤Ê¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Î¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤¹¤ë¡£ ÅÁÅýŪ¤Ê¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥ì¥¤¥¢¥¦¥È (/, /var, /tmp ¤ª¤è¤Ó /usr ¥Ç¥£¥ì¥¯¥È¥ê¤¬³Æ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ÎÊ̤Υե¡¥¤¥ë¥·¥¹¥Æ¥à) ¤òºîÀ®¤¹¤ë¤Ë¤Ï¡¢ GPT ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¹¥­¡¼¥à¤òºîÀ®¤·¡¢ ¤½¤Î¸å¡¢¼¨¤µ¤ì¤Æ¤¤¤ë¤è¤¦¤Ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òºîÀ®¤·¤Æ¤¯¤À¤µ¤¤¡£ ¼¨¤µ¤ì¤Æ¤¤¤ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥µ¥¤¥º¤Ï 20G ¤Î¥Ç¥£¥¹¥¯ÍѤǤ¹¡£ ¥Ç¥£¥¹¥¯¤Ë¤è¤ê¿¤¯¤ÎÍÆÎ̤¬¤¢¤ì¤Ð¡¢swap ¤Þ¤¿¤Ï /var ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤òÂ礭¤¯¼è¤ë¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£ ¤³¤³¤Ç¼¨¤µ¤ì¤Æ¤¤¤ë¥é¥Ù¥ë¤Ë¤Ï¡¢"example" ¤ò°ÕÌ£¤¹¤ë ex ¤¬ÉÕ¤±¤é¤ì¤Æ¤¤¤Þ¤¹¤¬¡¢ ¼ÂºÝ¤Ë¤Ï¾å¤ÇÀâÌÀ¤·¤¿¤è¤¦¤Ë¡¢ ¤³¤ì¤È¤ÏÊ̤Υæ¥Ë¡¼¥¯¤Ê¥é¥Ù¥ë¤ò¤Ä¤±¤Æ¤¯¤À¤µ¤¤¡£ &os; ¤Î gptboot ¤Ï¡¢ ¥Ç¥Õ¥©¥ë¥È¤Ç¤ÏºÇ½é¤Ë¸«¤Ä¤«¤Ã¤¿ UFS ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤¬¡¢ / ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤Ç¤¢¤ë¤³¤È¤òÁ°Æ¬¤È¤·¤Æ¤¤¤Þ¤¹¡£ ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¿¥¤¥× ¥µ¥¤¥º ¥Þ¥¦¥ó¥È¥Ý¥¤¥ó¥È ¥é¥Ù¥ë freebsd-boot 512K freebsd-ufs 2G / exrootfs freebsd-swap 4G exswap freebsd-ufs 2G /var exvarfs freebsd-ufs 1G /tmp extmpfs freebsd-ufs ¥Ç¥Õ¥©¥ë¥È (¥Ç¥£¥¹¥¯¤Î»Ä¤ê¤Î¤¹¤Ù¤Æ¤ÎÍÆÎÌ) /usr exusrfs ¥«¥¹¥¿¥à¥Ñ¡¼¥Æ¥£¥·¥ç¥ó ¤òºîÀ®¤·¤¿¤é [ Finish ] ¤òÁªÂò¤·¤Æ¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤òÀè¤Ë¿Ê¤ó¤Ç¤¯¤À¤µ¤¤¡£
¥¤¥ó¥¹¥È¡¼¥ëÁàºî¤Î³ÎÄê ¥¤¥ó¥¹¥È¡¼¥ë¤Ë¤è¤ë¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤Ø¤ÎÊѹ¹¤òÃæ»ß¤¹¤ë¤Ê¤é¡¢ ¤³¤³¤¬ºÇ¸å¤Î¥Á¥ã¥ó¥¹¤Ç¤¹¡£
ºÇ¸å¤Î³Îǧ
[ Commit ] ¤òÁªÂò¤·¤Æ¡¢ Enter ¥­¡¼¤ò²¡¤¹¤È¥¤¥ó¥¹¥È¡¼¥ë¤¬³«»Ï¤·¤Þ¤¹¡£ ¤â¤·Êѹ¹¤¬É¬ÍפǤ¢¤ì¤Ð¡¢ [ Back ] ¤òÁªÂò¤·¤Æ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¥¨¥Ç¥£¥¿¤Þ¤ÇÌá¤Ã¤Æ¤¯¤À¤µ¤¤¡£ [ Revert & Exit ] ¤òÁªÂò¤¹¤ë¤È¡¢ ¥Ï¡¼¥É¥É¥é¥¤¥Ö¤Ø¤ÎÊѹ¹¤Ê¤·¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤ò½ªÎ»¤Ç¤­¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤Ë¤«¤«¤ë»þ´Ö¤Ï¡¢¤É¤Î¥Ç¥£¥¹¥È¥ê¥Ó¥å¡¼¥·¥ç¥ó¤òÁª¤ó¤À¤«¡¢ ¤É¤Î¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤ò»È¤Ã¤¿¤«¡¢ ¤½¤·¤Æ¥³¥ó¥Ô¥å¡¼¥¿¤Î®Å٤ˤâ°Í¸¤·¤Þ¤¹¡£ ¿Ê¹Ô¾õ¶·¤òɽ¤¹¥á¥Ã¥»¡¼¥¸¤¬Ã༡ɽ¼¨¤µ¤ì¤Þ¤¹¡£ ¤Þ¤ººÇ½é¤Ë¡¢¥¤¥ó¥¹¥È¡¼¥é¤Ï¡¢¥Ç¥£¥¹¥¯¤Ë¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¾ðÊó¤ò½ñ¤­¹þ¤ß¡¢ newfs ¤ò¼Â¹Ô¤·¤Æ¥Ñ¡¼¥Æ¥£¥·¥ç¥ó¤ò½é´ü²½¤·¤Þ¤¹¡£ ¥Í¥Ã¥È¥ï¡¼¥¯·Ðͳ¤Ç¤Î¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤Ï¡¢ bsdinstall ¤Ï¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤ËɬÍפÊÇÛÉÛ¥Õ¥¡¥¤¥ë¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤Þ¤¹¡£
ÇÛÉÛ¥Õ¥¡¥¤¥ë¤Î¥À¥¦¥ó¥í¡¼¥É
¼¡¤Ë¡¢¥À¥¦¥ó¥í¡¼¥É¤ÎºÝ¤Ë¥¨¥é¡¼¤¬´Þ¤Þ¤ì¤Ê¤«¤Ã¤¿¤«¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤«¤é¤ÎÆÉ¤ß¼è¤êÃæ¤ËÆÉ¤ß´Ö°ã¤¤¤¬µ¯¤­¤Ê¤«¤Ã¤¿¤«¤É¤¦¤«Åù¡¢ ÇÛÉÛ¥Õ¥¡¥¤¥ë¤Î´°Á´À­¤Î¸¡¾Ú¤¬¹Ô¤ï¤ì¤Þ¤¹¡£
ÇÛÉÛ¥Õ¥¡¥¤¥ë¤Î¸¡¾Ú
ºÇ¸å¤Ë¡¢¸¡¾Ú¤µ¤ì¤¿ÇÛÉÛ¥Õ¥¡¥¤¥ë¤¬¥Ç¥£¥¹¥¯¤Ø¼è¤ê½Ð¤µ¤ì¤Þ¤¹¡£
ÇÛÉÛ¥Õ¥¡¥¤¥ë¤Î¼è¤ê½Ð¤·
ɬÍפÊÇÛÉÛ¥Õ¥¡¥¤¥ë¤¬¤¹¤Ù¤Æ¼è¤ê½Ð¤µ¤ì¤¿¤é¡¢ bsdinstall ¤Ï¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¸å¤Îºî¶È () ¤Ë¿Ê¤ß¤Þ¤¹¡£
¥¤¥ó¥¹¥È¡¼¥ë¸å¤Îºî¶È &os; ¤Î¥¤¥ó¥¹¥È¡¼¥ë¤¬´°Î»¤·¤¿¤é¡¢ ¤µ¤Þ¤¶¤Þ¤Ê¥ª¥×¥·¥ç¥ó¤ÎÀßÄê¤Ë°Ü¤ê¤Þ¤¹¡£ ¿·¤·¤¯¥¤¥ó¥¹¥È¡¼¥ë¤·¤¿ &os; ¤òµ¯Æ°¤¹¤ëÁ°¤Ë¡¢ ºÇ¸å¤Î¥á¥Ë¥å¡¼¤Î configuration ¥ª¥×¥·¥ç¥ó¤Î¹àÌÜ¤ËÆþ¤ê¤Ê¤ª¤¹¤³¤È¤Ç¤â¡¢ ¥ª¥×¥·¥ç¥ó¤ÎÀßÄê¤òÊѹ¹¤Ç¤­¤Þ¤¹¡£ <username>root</username> ¥Ñ¥¹¥ï¡¼¥É¤ÎÀßÄê root ¤Î¥Ñ¥¹¥ï¡¼¥É¤òÀßÄꤹ¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¥Ñ¥¹¥ï¡¼¥É¤òÆþÎϤ·¤Æ¤¤¤ëºÝ¤Ë¡¢ÆþÎϤ·¤Æ¤¤¤ëʸ»ú¤Ï²èÌ̤Ëɽ¼¨¤µ¤ì¤Þ¤»¤ó¡£ ¥Ñ¥¹¥ï¡¼¥É¤ÎÆþÎϸ塢¤â¤¦°ìÅÙÆþÎϤ¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¤³¤ì¤ÏÆþÎϥߥ¹¤òËɤ°¤¿¤á¤Ç¤¹¡£
<username>root</username> ¥Ñ¥¹¥ï¡¼¥É¤ÎÀßÄê
¥Ñ¥¹¥ï¡¼¥É¤ÎÆþÎϤËÀ®¸ù¤·¤¿¤é¡¢¥¤¥ó¥¹¥È¡¼¥ë¤Ï¼¡¤Ë¿Ê¤ß¤Þ¤¹¡£
¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ÎÀßÄê bootonly ¤Ë¤è¤ë¥¤¥ó¥¹¥È¡¼¥ëºî¶È¤Î°ìÉô¤È¤·¤Æ¡¢ ¤¹¤Ç¤Ë¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê¤ò½ª¤¨¤Æ¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¤³¤Îºî¶È¤òÈô¤Ð¤¹¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¼¡¤Ë¡¢¥³¥ó¥Ô¥å¡¼¥¿¤¬Ç§¼±¤·¤¿¤¹¤Ù¤Æ¤Î¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤¬É½¼¨¤µ¤ì¤Þ¤¹¡£ ÀßÄꤹ¤ë¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤òÁª¤ó¤Ç¤¯¤À¤µ¤¤¡£
¥¤¡¼¥µ¥Í¥Ã¥È¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ÎÁªÂò
¥ï¥¤¥ä¥ì¥¹¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ÎÀßÄê ¥ï¥¤¥ä¥ì¥¹¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤òÁªÂò¤·¤¿¤Î¤Ç¤¢¤ì¤Ð¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯¤ËÀܳ¤¹¤ë¤è¤¦¤Ë¥ï¥¤¥ä¥ì¥¹Ç§¾Ú¤ª¤è¤Ó¥»¥­¥å¥ê¥Æ¥£¥Ñ¥é¥á¡¼¥¿¤ÎÆþÎϤ¬É¬ÍפȤʤê¤Þ¤¹¡£ ¥ï¥¤¥ä¥ì¥¹¥Í¥Ã¥È¥ï¡¼¥¯¤Ï Service Set Identifier (SSID) ¤Ë¤è¤Ã¤Æ¼±Ê̤µ¤ì¤Þ¤¹¡£ SSID ¤Ï¡¢¤½¤ì¤¾¤ì¤Î¥Í¥Ã¥È¥ï¡¼¥¯¤ËÍ¿¤¨¤é¤ì¤ë¡¢Ã»¤¯¡¢°ì°ÕŪ¤Ê̾Á°¤Ç¤¹¡£ ¤Û¤È¤ó¤É¤Î¥ï¥¤¥ä¥ì¥¹¥Í¥Ã¥È¥ï¡¼¥¯¤Ï¡¢ Á÷¿®¥Ç¡¼¥¿¤ò°Å¹æ²½¤·¤Æ¡¢¾ðÊó¤òÅðݤ«¤éÊݸ¤Þ¤¹¡£ WEP ¤Î¤è¤¦¤Ê¸Å¤¤°Å¹æ¤Î°ÂÁ´À­¤ÏÄ㤤¤Î¤Ç¡¢ WPA2 °Å¹æ¤ò¶¯¤¯Á¦¤á¤Þ¤¹¡£ ¥ï¥¤¥ä¥ì¥¹¥Í¥Ã¥È¥ï¡¼¥¯¤ØÀܳ¤¹¤ëºÇ½é¤Î¥¹¥Æ¥Ã¥×¤Ï¡¢ ¥ï¥¤¥ä¥ì¥¹¥¢¥¯¥»¥¹¥Ý¥¤¥ó¥È¤Î¥¹¥­¥ã¥ó¤Ç¤¹¡£
¥ï¥¤¥ä¥ì¥¹¥¢¥¯¥»¥¹¥Ý¥¤¥ó¥È¤Î¥¹¥­¥ã¥ó
¥¹¥­¥ã¥ó¤Ç¸«¤Ä¤«¤Ã¤¿ SSID ¤Î°ìÍ÷¤¬¡¢ ¤½¤Î¥Í¥Ã¥È¥ï¡¼¥¯¤ÇÍøÍѤǤ­¤ë°Å¹æ²½¤Î¥¿¥¤¥×¤ÎÀâÌÀ¤È¤È¤â¤Ëɽ¼¨¤µ¤ì¤Þ¤¹¡£ ¤â¤·¡¢´üÂÔ¤·¤¿ SSID ¤¬°ìÍ÷¤Ëɽ¼¨¤µ¤ì¤Ê¤¤¤Î¤Ç¤¢¤ì¤Ð¡¢ [ Rescan ] ¤òÁªÂò¤·¤Æ¤â¤¦°ìÅÙ¥¹¥­¥ã¥ó¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤â¤·¡¢´üÂÔ¤·¤¿¥Í¥Ã¥È¥ï¡¼¥¯¤¬É½¼¨¤µ¤ì¤Ê¤¤¤Î¤Ç¤¢¤ì¤Ð¡¢ Àܳ¤Î¤¿¤á¤Î¥¢¥ó¥Æ¥Ê¤ä¥³¥ó¥Ô¥å¡¼¥¿¤ò¥¢¥¯¥»¥¹¥Ý¥¤¥ó¥È¤Î¶á¤¯¤Ë°Üư¤µ¤»¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£ ¤½¤Î¸å¤â¤¦°ìÅÙ¥¹¥­¥ã¥ó¤·¤Æ¤¯¤À¤µ¤¤¡£
¥ï¥¤¥ä¥ì¥¹¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÁªÂò
¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÁªÂò¸å¡¢¥ï¥¤¥ä¥ì¥¹¥Í¥Ã¥È¥ï¡¼¥¯¤ËÀܳ¤¹¤ë¤¿¤á¤Î°Å¹æ¾ðÊó¤òÆþÎϤ·¤Þ¤¹¡£ WPA2 ¤Ç¤Ï¡¢ ¥Ñ¥¹¥ï¡¼¥É (Pre-Shared Key ¤Þ¤¿¤Ï PSK ¤È¤â¸Æ¤Ð¤ì¤Þ¤¹) ¤Î¤ß¤¬É¬ÍפǤ¹¡£ ¥»¥­¥å¥ê¥Æ¥£¾å¤Î´ÑÅÀ¤«¤é¡¢ÆþÎϥܥ寥¹¤ËÆþÎϤ·¤¿Ê¸»ú¤Ï¥¢¥¹¥¿¥ê¥¹¥¯¤Çɽ¼¨¤µ¤ì¤Þ¤¹¡£
WPA2 ¤Î¥»¥Ã¥È¥¢¥Ã¥×
¥ï¥¤¥ä¥ì¥¹¥Í¥Ã¥È¥ï¡¼¥¯¤òÁªÂò¸å¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê¤ÏÀܳ¾ðÊó¤ÎÆþÎϤ˿ʤߤޤ¹¡£
IPv4 ¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê IPv4 ¥Í¥Ã¥È¥ï¡¼¥¯¤ò»È¤¦¤«¤É¤¦¤«¤òÁªÂò¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ì¤Ï¡¢¥Í¥Ã¥È¥ï¡¼¥¯Àܳ¤ÎºÇ¤â°ìÈÌŪ¤Ê¥¿¥¤¥×¤Ç¤¹¡£
IPv4 ¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÁªÂò
IPv4 ¤ÎÀßÄêÊýË¡¤Ï 2 Ä̤ꤢ¤ê¤Þ¤¹¡£ DHCP ¤Ï¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ò¼«Æ°Åª¤ËŬÀÚ¤ËÀßÄꤹ¤ëÊýË¡¤Ç¡¢ ¿ä¾©¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ Static ÀßÄê¤Ç¤Ï¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯¾ðÊó¤ò¼êư¤ÇÆþÎϤ¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ŬÅö¤Ê¥Í¥Ã¥È¥ï¡¼¥¯¾ðÊó¤òÆþÎϤ·¤Æ¤âư¤«¤Ê¤¤¤Î¤Ç¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯´ÉÍý¼Ô¤Þ¤¿¤Ï¥µ¡¼¥Ó¥¹¥×¥í¥Ð¥¤¥À¤«¤é ¤Ë¼¨¤µ¤ì¤Æ¤¤¤ë¾ðÊó¤òÆþ¼ê¤·¤Æ¤¯¤À¤µ¤¤¡£ IPv4 DHCP ¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê DHCP ¥µ¡¼¥Ð¤òÍøÍѤǤ­¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ [ Yes ] ¤òÁªÂò¤·¤Æ¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ÎÀßÄê¤ò¼«Æ°Åª¤Ë¹Ô¤Ã¤Æ¤¯¤À¤µ¤¤¡£
IPv4 DHCP ÀßÄê¤ÎÁªÂò
ÀÅŪ¤Ê IPv4 ¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê ÀÅŪ¤Ê¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ÎÀßÄê¤Ç¤Ï¡¢ ¤¤¤¯¤Ä¤«¤Î IPv4 ¾ðÊó¤òÆþÎϤ¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
IPv4 Static ÀßÄê
IP Address - ¥³¥ó¥Ô¥å¡¼¥¿¤Ë¼êư¤ÇÍ¿¤¨¤ë IP ¥¢¥É¥ì¥¹¤Ç¤¹¡£ ¤³¤Î¥¢¥É¥ì¥¹¤Ï°ì°ÕŪ¤Ê¤â¤Î¤Ç¤¢¤ëɬÍפ¬¤¢¤ê¡¢ ¥í¡¼¥«¥ë¥Í¥Ã¥È¥ï¡¼¥¯¾å¤Î¾¤Î¥Í¥Ã¥È¥ï¡¼¥¯µ¡´ï¤Ç»È¤ï¤ì¤Æ¤¤¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£ Subnet Mask - ¥í¡¼¥«¥ë¥Í¥Ã¥È¥ï¡¼¥¯¤ÇÍѤ¤¤é¤ì¤ë¥µ¥Ö¥Í¥Ã¥È¥Þ¥¹¥¯¤Ç¤¹¡£ °ìÈÌŪ¤Ë¤Ï 255.255.255.0 ¤Ç¤¹¡£ Default Router - ¤³¤Î¥Í¥Ã¥È¥ï¡¼¥¯¤Î¥Ç¥Õ¥©¥ë¥È¥ë¡¼¥¿¤Î IP ¥¢¥É¥ì¥¹¤Ç¤¹¡£ ¤³¤ì¤Ï¡¢Ä̾ï¥ë¡¼¥¿¤«¡¢ ¥í¡¼¥«¥ë¥Í¥Ã¥È¥ï¡¼¥¯¤ò¥¤¥ó¥¿¡¼¥Í¥Ã¥È¤ØÀܳ¤¹¤ë¥Í¥Ã¥È¥ï¡¼¥¯µ¡´ï¤Î¤³¤È¤Ç¤¹¡£ ¥Ç¥Õ¥©¥ë¥È¥²¡¼¥È¥¦¥§¥¤ ¤È¤â¸Æ¤Ð¤ì¤Þ¤¹¡£
IPv6 ¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê IPv6 ¤Ï¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê¤Î¿·¤·¤¤ÊýË¡¤Ç¤¹¡£ IPv6 ¤¬ÍøÍѤǤ­¡¢´õ˾¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ [ Yes ] ¤òÁªÂò¤·¤Æ¤¯¤À¤µ¤¤¡£
IPv6 ¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê
IPv6 ¤ÎÀßÄê¤Ë´Ø¤·¤Æ¤â 2 ¤Ä¤ÎÊýË¡¤¬¤¢¤ê¤Þ¤¹¡£ SLAAC (StateLess Address AutoConfiguration) ¤Ï¡¢¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ò¼«Æ°Åª¤ËŬÀÚ¤ËÀßÄꤷ¤Þ¤¹¡£ Static ÀßÄê¤Ç¤Ï¡¢¥Í¥Ã¥È¥ï¡¼¥¯¾ðÊó¤ò¼êư¤ÇÆþÎϤ¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ IPv6 Stateless Address Autoconfiguration SLAAC ¤Ç¤Ï¡¢IPv6 ¥Í¥Ã¥È¥ï¡¼¥¯¥³¥ó¥Ý¡¼¥Í¥ó¥È¤¬¥í¡¼¥«¥ë¥ë¡¼¥¿¤«¤é¼«Æ°ÀßÄê¤Ë´Ø¤¹¤ë¾ðÊó¤ò¥ê¥¯¥¨¥¹¥È¤Ç¤­¤ë¤è¤¦¤Ë¤·¤Þ¤¹¡£ ¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï¡¢ RFC4862 ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£
IPv6 SLAAC ÀßÄê¤ÎÁªÂò
ÀÅŪ¤Ê IPv6 ¥Í¥Ã¥È¥ï¡¼¥¯¤ÎÀßÄê ÀÅŪ¤Ê¥Í¥Ã¥È¥ï¡¼¥¯¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤ÎÀßÄê¤Ç¤Ï¡¢ IPv6 ¤ÎÀßÄê¤Ë´Ø¤¹¤ë¾ðÊó¤òÆþÎϤ¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£
IPv6 static ÀßÄê
IPv6 Address - ¤³¤Î¥³¥ó¥Ô¥å¡¼¥¿¤Ë³ä¤êÅö¤Æ¤é¤ì¤¿ IP ¥¢¥É¥ì¥¹¤Ç¤¹¡£ ¼êư¤ÇÀßÄꤷ¤Þ¤¹¡£ ¤³¤Î¥¢¥É¥ì¥¹¤Ï°ì°ÕŪ¤Ê¤â¤Î¤Ç¤¢¤ëɬÍפ¬¤¢¤ê¡¢ ¥í¡¼¥«¥ë¥Í¥Ã¥È¥ï¡¼¥¯¾å¤Î¾¤Î¥Í¥Ã¥È¥ï¡¼¥¯µ¡´ï¤Ç»È¤ï¤ì¤Æ¤¤¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£ Default Router - ¤³¤Î¥Í¥Ã¥È¥ï¡¼¥¯¤Î¥Ç¥Õ¥©¥ë¥È¥ë¡¼¥¿¤Î IPv6 ¥¢¥É¥ì¥¹¤Ç¤¹¡£ ¤³¤ì¤Ï¡¢Ä̾ï¥ë¡¼¥¿¤«¡¢ ¥í¡¼¥«¥ë¥Í¥Ã¥È¥ï¡¼¥¯¤ò¥¤¥ó¥¿¡¼¥Í¥Ã¥È¤ØÀܳ¤¹¤ë¥Í¥Ã¥È¥ï¡¼¥¯µ¡´ï¤Î¤³¤È¤Ç¤¹¡£ ¥Ç¥Õ¥©¥ë¥È¥²¡¼¥È¥¦¥§¥¤ ¤È¤â¸Æ¤Ð¤ì¤Þ¤¹¡£
<acronym role="Domain Name System">DNS</acronym> ¤ÎÀßÄê Domain Name System (¤Þ¤¿¤Ï DNS) ¥ê¥¾¥ë¥Ð¤Ï¡¢¥Û¥¹¥È̾¤È¥Í¥Ã¥È¥ï¡¼¥¯¥¢¥É¥ì¥¹¤òÊÑ´¹¤·¤Þ¤¹¡£ ¤¹¤Ç¤Ë DHCP ¤Þ¤¿¤Ï SLAAC ¤ò¥Í¥Ã¥È¥ï¡¼¥¯¤Î¼«Æ°ÀßÄê¤Ë»È¤Ã¤¿¤Î¤Ç¤¢¤ì¤Ð¡¢ ¥ê¥¾¥ë¥Ð¤ÎÀßÄê¤Ï¤¹¤Ç¤Ë¹Ô¤ï¤ì¤Æ¤¤¤Þ¤¹¡£¤½¤¦¤Ç¤Ê¤±¤ì¤Ð¡¢Search ¥Õ¥£¡¼¥ë¥É¤Ë¥í¡¼¥«¥ë¥Í¥Ã¥È¥ï¡¼¥¯¤Î¥É¥á¥¤¥ó̾¤òÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£ DNS #1 ¤ª¤è¤Ó DNS #2 ¤Ï¡¢ ¥í¡¼¥«¥ë DNS ¥µ¡¼¥Ð¤Î IP ¥¢¥É¥ì¥¹¤Ç¤¹¡£ ¾¯¤Ê¤¯¤È¤â¡¢1 ¤Ä¤Î DNS ¥µ¡¼¥Ð¤ÏɬÍפǤ¹¡£
DNS ¤ÎÀßÄê
¥¿¥¤¥à¥¾¡¼¥ó¤ÎÀßÄê »ÈÍѤ·¤Æ¤¤¤ë¥³¥ó¥Ô¥å¡¼¥¿¤Î¥¿¥¤¥à¥¾¡¼¥ó¤òÀßÄꤹ¤ë¤³¤È¤Ç¡¢ Ãϰè¤Ë¤è¤ë»þ¹ï¤Î°ã¤¤¤¬¼«Æ°Åª¤ËÄ´À°¤µ¤ì¡¢ ¥¿¥¤¥à¥¾¡¼¥ó¤Ë´ØÏ¢¤·¤¿µ¡Ç½¤¬Å¬Àڤ˼è¤ê°·¤ï¤ì¤Þ¤¹¡£ ¤³¤³¤Ç¤ÎÎã¤Ç¤Ï¡¢¥³¥ó¥Ô¥å¡¼¥¿¤¬ United States ¤Î Eastern ¥¿¥¤¥à¥¾¡¼¥ó¤Ë¤¢¤ë¤â¤Î¤È¤·¤Þ¤¹¡£ ¼ÂºÝ¤ÎÃÏÍýŪ°ÌÃÖ¤òÁªÂò¤·¤Æ¤¯¤À¤µ¤¤¡£
¥í¡¼¥«¥ë¤Þ¤¿¤Ï UTC ¥¯¥í¥Ã¥¯¤ÎÁªÂò
¥³¥ó¥Ô¥å¡¼¥¿¤Î¥¯¥í¥Ã¥¯¤ÎÀßÄê¤Ë¤·¤¿¤¬¤¤¡¢ [ Yes ] ¤Þ¤¿¤Ï¡¢ [ No ] ¤òÁªÂò¤·¡¢Enter ¤ò²¡¤·¤¯¤À¤µ¤¤¡£ UTC ¤È¥í¡¼¥«¥ë¥¿¥¤¥à¤Î¤É¤Á¤é¤òÁª¤Ö¤Ù¤­¤«¤ï¤«¤é¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢ [ No ] ¤òÁªÂò¤·¤Æ¡¢¤è¤ê°ìÈÌŪ¤Ê¥í¡¼¥«¥ë¥¿¥¤¥à¤ËÀßÄꤷ¤Æ¤¯¤À¤µ¤¤¡£
Ãϰè¤ÎÁªÂò
Ìð°õ¥­¡¼¤ò»È¤Ã¤Æ¡¢Å¬ÀÚ¤ÊÃϰè¤òÁªÂò¤·¡¢ Enter ¤ò²¡¤·¤Æ¤¯¤À¤µ¤¤¡£
¹ñ̾¤ÎÁªÂò
Ìð°õ¥­¡¼¤ò»È¤Ã¤Æ¡¢Å¬Àڤ˹ñ̾¤òÁª¤Ó¡¢ Enter ¤ò²¡¤·¤Æ¤¯¤À¤µ¤¤¡£
¥¿¥¤¥à¥¾¡¼¥ó¤ÎÁªÂò
Ìð°õ¥­¡¼¤ò»È¤Ã¤ÆÅ¬Àڤʥ¿¥¤¥à¥¾¡¼¥ó¤òÁªÂò¤·¡¢ Enter ¤ò²¡¤·¤Æ¤¯¤À¤µ¤¤¡£
¥¿¥¤¥à¥¾¡¼¥ó¤Î³ÎÄê
¥¿¥¤¥à¥¾¡¼¥ó¤Î¾Êά·Á¤¬Àµ¤·¤¤¤«¤É¤¦¤«¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ÌäÂ꤬¤Ê¤¤¤è¤¦¤Ç¤¢¤ì¤Ð Enter ¤ò²¡¤·¤Æ¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¸å¤ÎÀßÄê¤ò³¤±¤Æ¤¯¤À¤µ¤¤¡£
Í­¸ú¤Ë¤¹¤ë¥µ¡¼¥Ó¥¹¤ÎÁªÂò ¥Ö¡¼¥È»þ¤Ëµ¯Æ°¤¹¤ë¥·¥¹¥Æ¥à¥µ¡¼¥Ó¥¹¤òÄɲäÇÍ­¸ú¤Ë½ÐÍè¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥µ¡¼¥Ó¥¹¤Ï¤¹¤Ù¤Æ¥ª¥×¥·¥ç¥ó¤Ç¤¹¡£
ÄɲäÇÍ­¸ú¤Ë¤¹¤ë¥µ¡¼¥Ó¥¹¤ÎÁªÂò
ÄɲäΥµ¡¼¥Ó¥¹ sshd - °ÂÁ´¤Ê¥ê¥â¡¼¥È¥¢¥¯¥»¥¹¤Î¤¿¤á¤Î¥»¥­¥å¥¢¥·¥§¥ë (SSH) ¥Ç¡¼¥â¥ó moused - ¥·¥¹¥Æ¥à¤Î¥³¥ó¥½¡¼¥ë¤Ç¡¢ ¥Þ¥¦¥¹¤òÍøÍѤǤ­¤ë¤è¤¦¤Ë¤·¤Þ¤¹¡£ ntpd - ¼«Æ°»þ¹ïƱ´ü¤Î¥Í¥Ã¥È¥ï¡¼¥¯¥×¥í¥È¥³¥ë (NTP) ¥Ç¡¼¥â¥ó powerd - ÅŸ»¤Î´ÉÍý¤ª¤è¤Ó¥¨¥Í¥ë¥®¡¼¤òÀáÌ󤹤뤿¤á¤ÎÅŸ»¥³¥ó¥È¥í¡¼¥ë¥æ¡¼¥Æ¥£¥ê¥Æ¥£
¥¯¥é¥Ã¥·¥å¥À¥ó¥×¤ÎÀßÄê ¼¡¤Ë bsdinstall ¤Ï¡¢ ¥¯¥é¥Ã¥·¥å¥À¥ó¥×¤ÎÀßÄê¤Ë°Ü¤ê¤Þ¤¹¡£ ¥·¥¹¥Æ¥à¤Î¥Ç¥Ð¥Ã¥°¤ò¹Ô¤¦¾å¤Ç¡¢ ¥¯¥é¥Ã¥·¥å¥À¥ó¥×¤Ë¤è¤êÆÀ¤é¤ì¤ë¾ðÊó¤ÏÈó¾ï¤ËÍ­ÍѤǤ¹¡£ ²Äǽ¤Ç¤¢¤ì¤Ð¥¯¥é¥Ã¥·¥å¥À¥ó¥×¤òÍ­¸ú¤Ë¤¹¤ë¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£ [ Yes ] ¤òÁªÂò¤·¤Æ¥¯¥é¥Ã¥·¥å¥À¥ó¥×¤òÍ­¸ú¤Ë¤¹¤ë¤«¡¢¤Þ¤¿¤Ï [ No ] ¤òÁªÂò¤·¤Æ¥¯¥é¥Ã¥·¥å¥À¥ó¥×¤ò̵¸ú²½¤·¡¢Àè¤Ë¿Ê¤ó¤Ç¤¯¤À¤µ¤¤¡£
¥¯¥é¥Ã¥·¥å¥À¥ó¥×¤ÎÀßÄê
¥æ¡¼¥¶¤ÎÄɲà ¥·¥¹¥Æ¥à¤Ë root ¤Ç¥í¥°¥¤¥ó¤¹¤ë¤³¤È¤òÈò¤±¤ë¤¿¤á¡¢ ¥¤¥ó¥¹¥È¡¼¥ë»þ¤Ë¤Ï¡¢¾¯¤Ê¤¯¤È¤â°ì¿Í¤Î¥æ¡¼¥¶¤òÄɲ䷤Ƥ¯¤À¤µ¤¤¡£ root ¸¢¸Â¤Ç¤Ï¡¢¼Â¹Ô¤ËÂФ·¤ÆÀ©¸Â¤¬¤Ê¤¯¡¢¤Þ¤¿¡¢ Êݸ¤ì¤Þ¤»¤ó¡£ Ä̾ï¤Î¥æ¡¼¥¶¤Ç¥í¥°¥¤¥ó¤¹¤ë¤³¤È¤Ë¤è¤ê¡¢ °ÂÁ´¤Ç¥»¥­¥å¥ê¥Æ¥£Åª¤Ë´í¸±¤¬¾¯¤Ê¤¯¤Ê¤ê¤Þ¤¹¡£ [ Yes ] ¤òÁªÂò¤·¡¢ ¿·¤·¤¤¥æ¡¼¥¶¤òÄɲ䷤Ƥ¯¤À¤µ¤¤¡£
¿·¤·¤¤¥æ¡¼¥¶¤Î¥¢¥«¥¦¥ó¥È¤ÎºîÀ®
Äɲä¹¤ë¥æ¡¼¥¶¤Î¾ðÊó¤òÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£
¥æ¡¼¥¶¾ðÊó¤ÎÆþÎÏ
¥æ¡¼¥¶¤Î¾ðÊó Username - ¥í¥°¥¤¥ó»þ¤Î¥æ¡¼¥¶Ì¾¤òÆþÎϤ·¤Þ¤¹¡£Åµ·¿Åª¤Ê¤â¤Î¤Ç¤Ï¡¢ ¥Õ¥¡¡¼¥¹¥È¥Í¡¼¥à¤ÎºÇ½é¤Îʸ»ú¤È¥é¥¹¥È¥Í¡¼¥à¤òÁȤ߹ç¤ï¤»¤Þ¤¹¡£ Full name - ¥æ¡¼¥¶¤Î¥Õ¥ë¥Í¡¼¥à Uid - ¥æ¡¼¥¶ ID Èֹ档 Ä̾ï¤Ï¡¢¥·¥¹¥Æ¥à¤¬¼«Æ°Åª¤Ë³ä¤êÅö¤Æ¤ë¤è¤¦¤Ë¡¢ ¶õÍó¤Î¤Þ¤Þ¤Ë¤·¤Þ¤¹¡£ Login group - ¿·¤·¤¤¥æ¡¼¥¶¤Î¥í¥°¥¤¥ó¥°¥ë¡¼¥×¡£ ¶õÍó¤Î¤Þ¤Þ¤Ë¤¹¤ë¤È¡¢¼«Æ°Åª¤Ë³ä¤êÅö¤Æ¤é¤ì¤Þ¤¹ Invite user into other groups? - ¥æ¡¼¥¶¤òÊ̤Υ°¥ë¡¼¥×¤Î¥á¥ó¥Ð¡¼¤È¤·¤ÆÄɲ乤뤫¤É¤¦¤«¡£ Login class - ¶õÍó¤Ë¤¹¤ë¤È¥Ç¥Õ¥©¥ë¥È¤ÎÀßÄê¤Ë¤Ê¤ê¤Þ¤¹¡£ Shell - ¥æ¡¼¥¶¤Î¥í¥°¥¤¥ó¥·¥§¥ë¡£ ¤³¤ÎÎã¤Ç¤Ï &man.csh.1; ¤ËÀßÄꤵ¤ì¤Æ¤¤¤Þ¤¹¡£ Home directory - ¥æ¡¼¥¶¤Î¥Û¡¼¥à¥Ç¥£¥ì¥¯¥È¥ê¡£ Ä̾ï¤Ï¡¢¥Ç¥Õ¥©¥ë¥È¤Î¾ì½ê¤¬Å¬ÀڤǤ¹¡£ Home directory permissions - ¥æ¡¼¥¶¤Î¥Û¡¼¥à¥Ç¥£¥ì¥¯¥È¥ê¤Î¸¢¸Â¡£ Ä̾ï¤Ï¡¢¥Ç¥Õ¥©¥ë¥È¤¬Å¬ÀڤǤ¹¡£ Use password-based authentication? - Ä̾ï¤Ï "yes" ¤Ç¤¹¡£ Use an empty password? - Ä̾ï¤Ï "no" ¤Ç¤¹¡£ Use a random password? - Ä̾ï¤Ï "no" ¤Ç¤¹¡£ Enter password - ¥æ¡¼¥¶¤Î¥Ñ¥¹¥ï¡¼¥É¤Ç¤¹¡£ ÆþÎϤ·¤Æ¤¤¤ëʸ»ú¤Ï²èÌ̤Ëɽ¼¨¤µ¤ì¤Þ¤»¤ó¡£ Enter password again - ³Îǧ¤Î¤¿¤á¡¢¥Ñ¥¹¥ï¡¼¥É¤ò¤â¤¦°ìÅÙÆþÎϤ·¤Þ¤¹¡£ Lock out the account after creation? - Ä̾ï¤Ï "no" ¤Ç¤¹¡£ ¤¹¤Ù¤Æ¤òÆþÎϤ·¤¿¤é¡¢¥µ¥Þ¥ê¤¬É½¼¨¤µ¤ì¡¢ Àµ¤·¤¤¤«¤É¤¦¤«¤Î³Îǧ¤òµá¤á¤é¤ì¤Þ¤¹¡£ ÆþÎϤ·¤¿¾ðÊó¤Ë´Ö°ã¤¤¤¬¤¢¤ì¤Ð¡¢ no ¤òÆþÎϤ·¤Æ¤â¤¦°ìÅÙºî¶È¤ò¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤¹¤Ù¤Æ¤¬Àµ¤·¤¯ÆþÎϤµ¤ì¤Æ¤¤¤ì¤Ð¡¢ yes ¤òÆþÎϤ·¤Æ¡¢¿·¤·¤¤¥æ¡¼¥¶¤òºîÀ®¤·¤Æ¤¯¤À¤µ¤¤¡£
¥æ¡¼¥¶¤ª¤è¤Ó¥°¥ë¡¼¥×¤Î´ÉÍý¤ò½ªÎ»¤¹¤ë
¤µ¤é¤Ë¥æ¡¼¥¶¤òÄɲ乤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ "Add another user?" ¤Î¼ÁÌä¤ËÂФ·¡¢ yes ¤òÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£ no ¤òÆþÎϤ¹¤ë¤È¡¢¥æ¡¼¥¶¤ÎÄɲ䬽ª¤ï¤ê¡¢¼¡¤Ë¿Ê¤ß¤Þ¤¹¡£ ¥æ¡¼¥¶¤ÎÄɲä䡢¥æ¡¼¥¶´ÉÍý¤Î¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£
ºÇ¸å¤ÎÀßÄê ¤¹¤Ù¤Æ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¡¢ÀßÄ꤬½ª¤ï¤Ã¤¿¸å¤Ë¡¢ ºÇ¸å¤ËÀßÄê¤ò½¤Àµ¤¹¤ëµ¡²ñ¤¬Í¿¤¨¤é¤ì¤Þ¤¹¡£
ºÇ¸å¤ÎÀßÄê
¥¤¥ó¥¹¥È¡¼¥ë¤ò´°Î»¤¹¤ëÁ°¤Ë¡¢ ¤³¤Î¥á¥Ë¥å¡¼¤ò»È¤Ã¤ÆÊѹ¹¡¢¤Þ¤¿¤Ï¡¢ÄɲäÎÀßÄê¤ò¹Ô¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ºÇ½ª¤ÎÀßÄꥪ¥×¥·¥ç¥ó Add User - ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ Root Password - ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ Hostname - ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ Network - ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ Services - ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ Time Zone - ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ Handbook - &os; ¥Ï¥ó¥É¥Ö¥Ã¥¯ (¸½ºß¤¢¤Ê¤¿¤¬ÆÉ¤ó¤Ç¤¤¤ë¤³¤Îʸ¾Ï¤Î¤³¤È¤Ç¤¹) ¤Î¥À¥¦¥ó¥í¡¼¥É¤È¥¤¥ó¥¹¥È¡¼¥ë¡£ ºÇ¸å¤ÎÀßÄê¤ò´°Î»¸å¡¢Exit ¤òÁª¤ó¤Ç¥¤¥ó¥¹¥È¡¼¥ë¤ò½ªÎ»¤·¤Æ¤¯¤À¤µ¤¤¡£
Manual Configuration
¿·¤·¤¤¥·¥¹¥Æ¥à¤òºÆµ¯Æ°¤¹¤ëÁ°¤Ë¡¢ bsdinstall ¤ÏÄɲäÎÀßÄ꤬ɬÍפ«¤É¤¦¤«¤ò¿Ò¤Í¤Æ¤­¤Þ¤¹¡£ [ Yes ] ¤òÁªÂò¤·¤Æ¿·¤·¤¤¥·¥¹¥Æ¥à¤Î¥·¥§¥ë¤ËÆþ¤ë¤«¡¢¤Þ¤¿¤Ï [ No ] ¤òÁªÂò¤·¤Æ¡¢¥¤¥ó¥¹¥È¡¼¥ë¤ÎºÇ¸å¤Î¥¹¥Æ¥Ã¥×¤Ë¿Ê¤ó¤Ç¤¯¤À¤µ¤¤¡£
¥¤¥ó¥¹¥È¡¼¥ë¤Î½ªÎ»
¤â¤·ÄɲäÎÀßÄê¤ä¡¢ÆÃÊ̤ʥ»¥Ã¥È¥¢¥Ã¥×¤¬É¬ÍפʤΤǤ¢¤ì¤Ð¡¢ [ Live CD ] ¤òÁª¤ó¤Ç¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤ò Live CD ¥â¡¼¥É¤Çµ¯Æ°¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤¬½ª¤ï¤Ã¤¿¤é¡¢ [ Reboot ] ¤òÁª¤ó¤Ç¡¢ ¥³¥ó¥Ô¥å¡¼¥¿¤òºÆµ¯Æ°¤·¡¢¿·¤·¤¤ &os; ¥·¥¹¥Æ¥à¤òư¤«¤·¤Æ¤¯¤À¤µ¤¤¡£ ºÆµ¯Æ°¤¹¤ëÁ°¤Ë¤Ï¡¢Ëº¤ì¤º¤Ë &os; ¥¤¥ó¥¹¥È¡¼¥ë CD, DVD ¤Þ¤¿¤Ï USB ¥á¥â¥ê¥¹¥Æ¥£¥Ã¥¯¤ò³°¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤µ¤â¤Ê¤¤¤È¡¢¤â¤¦°ìÅÙ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤«¤éµ¯Æ°¤·¤Æ¤·¤Þ¤¤¤Þ¤¹¡£
&os; ¤Îµ¯Æ°¤È¥·¥ã¥Ã¥È¥À¥¦¥ó &os;/&arch.i386; ¤Îµ¯Æ° &os; ¤Îµ¯Æ°»þ¤Ë¤Ï¡¢Â¿¤¯¤Î¥á¥Ã¥»¡¼¥¸¤¬²èÌ̤Ëɽ¼¨¤µ¤ì¤Þ¤¹¡£ ¤Û¤È¤ó¤É¤Ï¡¢²èÌ̾夫¤é¥¹¥¯¥í¡¼¥ë¤·¤Æ¸«¤¨¤Ê¤¯¤Ê¤Ã¤Æ¤·¤Þ¤¤¤Þ¤¹¤¬¡¢ ¤³¤ì¤ÏÀµ¾ï¤Ç¤¹¡£¥·¥¹¥Æ¥à¤Îµ¯Æ°¤¬½ª¤ï¤Ã¤¿¸å¤Ç¡¢ ¥í¥°¥¤¥ó¥×¥í¥ó¥×¥È¤¬É½¼¨¤µ¤ì¤Þ¤¹¡£ ²èÌ̾夫¤é¥¹¥¯¥í¡¼¥ë¤·¤Æ¾Ã¤¨¤Æ¤·¤Þ¤Ã¤¿¥á¥Ã¥»¡¼¥¸¤Ï Scroll-Lock ¤ò²¡¤·¡¢ scroll-back buffer ¤Ç¡¢¤ß¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ PgUp, PgDn ¤½¤·¤ÆÌð°õ¥­¡¼¤Ç¥á¥Ã¥»¡¼¥¸¤ÎÆâÍÆ¤ò¸«¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ Scroll-Lock ¤ò¤â¤¦°ìÅÙ²¡¤¹¤È¡¢²èÌ̤Υí¥Ã¥¯¤ò³°¤·¡¢ Ä̾ï¤Î²èÌ̤ËÌá¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ login: ¥×¥í¥ó¥×¥È¤Ç¡¢ ¥¤¥ó¥¹¥È¡¼¥ë»þ¤ËÄɲä·¤¿¥æ¡¼¥¶Ì¾¤òÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ÎÎã¤Ç¤Ï¡¢asample ¤Ç¤¹¡£ ɬÍפΤʤ¤¸Â¤ê¡¢root ¤Ç¤Î¥í¥°¥¤¥ó¤òÈò¤±¤Æ¤¯¤À¤µ¤¤¡£ ¾å¤Ç¼¨¤·¤¿ scroll-back buffer ¤Ç¤Ï¡¢¥Ð¥Ã¥Õ¥¡¤ÎÍÆÎÌÀ©¸Â¤Ë¤è¤ê¡¢ ¤¹¤Ù¤Æ¤¬É½¼¨¤µ¤ì¤Ê¤¤¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¥í¥°¥¤¥ó¤Î¸å¤Ë¥×¥í¥ó¥×¥È¤«¤é¥³¥Þ¥ó¥É¥é¥¤¥ó¤Ç dmesg | less ¤ÈÆþÎϤ¹¤ë¤³¤È¤Ë¤è¤Ã¤Æ¡¢¤¹¤Ù¤Æ¤ò¸«¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ³Îǧ¸å¤Ë q ¤ò²¡¤¹¤È¡¢¥³¥Þ¥ó¥É¥é¥¤¥ó¤ËÌá¤ê¤Þ¤¹¡£ ŵ·¿Åª¤Ê¥Ö¡¼¥È¥á¥Ã¥»¡¼¥¸ (¥Ð¡¼¥¸¥ç¥ó¾ðÊó¤Ï¾Êά¤·¤Æ¤¤¤Þ¤¹) Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3007.77-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0x783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2> Features2=0x209<SSE3,MON,SSSE3> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> real memory = 536805376 (511 MB) avail memory = 491819008 (469 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <VBOX VBOXAPIC> ioapic0: Changing APIC ID to 1 ioapic0 <Version 1.1> irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <VBOX VBOXXSDT> on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: <ACPI CPU> on acpi0 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0 isab0: <PCI-ISA bridge> at device 1.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <Intel PIIX4 UDMA33 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 ata0: <ATA channel 0> on atapci0 ata1: <ATA channel 1> on atapci0 vgapci0: <VGA-compatible display> mem 0xe0000000-0xe0ffffff irq 18 at device 2.0 on pci0 em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.3> port 0xd010-0xd017 mem 0xf0000000-0xf001ffff irq 19 at device 3.0 on pci0 em0: Ethernet address: 08:00:27:9f:e0:92 pci0: <base peripheral> at device 4.0 (no driver attached) pcm0: <Intel ICH (82801AA)> port 0xd100-0xd1ff,0xd200-0xd23f irq 21 at device 5.0 on pci0 pcm0: <SigmaTel STAC9700/83/84 AC97 Codec> ohci0: <OHCI (generic) USB controller> mem 0xf0804000-0xf0804fff irq 22 at device 6.0 on pci0 usbus0: <OHCI (generic) USB controller> on ohci0 pci0: <bridge> at device 7.0 (no driver attached) acpi_acad0: <AC Adapter> on acpi0 atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 attimer0: <AT timer> port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: <AT realtime clock> at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 ppc0: cannot reserve I/O port range Timecounters tick every 10.000 msec pcm0: measured ac97 link rate at 485193 Hz em0: link state changed to UP usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: <Apple> at usbus0 uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: <VBOX CD-ROM 1.0> Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: <VBOX HARDDISK 1.0> ATA-6 device ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) ada0: 12546MB (25694208 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 Timecounter "TSC" frequency 3007772192 Hz quality 800 Root mount waiting for: usbus0 uhub0: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ada0p2 [rw]... Setting hostuuid: 1848d7bf-e6a4-4ed4-b782-bd3f1685d551. Setting hostid: 0xa03479b2. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p2: clean, 2620402 free (714 frags, 327461 blocks, 0.0% fragmentation) Mounting local file systems:. vboxguest0 port 0xd020-0xd03f mem 0xf0400000-0xf07fffff,0xf0800000-0xf0803fff irq 20 at device 4.0 on pci0 vboxguest: loaded successfully Setting hostname: machine3.example.com. Starting Network: lo0 em0. lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> ether 08:00:27:9f:e0:92 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active Starting devd. Starting Network: usbus0. DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 10.0.2.2 bound to 192.168.1.142 -- renewal in 43200 seconds. add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 32-bit compatibility ldconfig path: /usr/lib32 Creating and/or trimming log files. Starting syslogd. No core dumps found. Clearing /tmp (X related). Updating motd:. Configuring syscons: blanktime. Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: 10:a0:f5:af:93:ae:a3:1a:b2:bb:3c:35:d9:5a:b3:f3 root@machine3.example.com The key's randomart image is: +--[RSA1 1024]----+ | o.. | | o . . | | . o | | o | | o S | | + + o | |o . + * | |o+ ..+ . | |==o..o+E | +-----------------+ Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: 7e:1c:ce:dc:8a:3a:18:13:5b:34:b5:cf:d9:d1:47:b2 root@machine3.example.com The key's randomart image is: +--[ DSA 1024]----+ | .. . .| | o . . + | | . .. . E .| | . . o o . . | | + S = . | | + . = o | | + . * . | | . . o . | | .o. . | +-----------------+ Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Thu Oct 6 19:15:31 MDT 2011 FreeBSD/amd64 (machine3.example.com) (ttyv0) login: Ä㮤ʥޥ·¥ó¤Ç¤Ï¡¢ RSA ¤ª¤è¤Ó DSA ¥­¡¼¤òºîÀ®¤¹¤ë¤Î¤Ë¾¯¡¹»þ´Ö¤¬¤«¤«¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¤³¤ì¤Ï¥¤¥ó¥¹¥È¡¼¥ë¸å¤ÎºÇ½é¤Îµ¯Æ°»þ¤Ë¡¢sshd ¤Î¥»¥Ã¥È¥¢¥Ã¥×¤¬¼«Æ°Åª¤Ë³«»Ï¤¹¤ë»þ¤Ë¼Â¹Ô¤µ¤ì¤Þ¤¹¡£ ¤½¤Î¸å¤Îµ¯Æ°¤Ï¤è¤ê®¤¯¤Ê¤ë¤Ç¤·¤ç¤¦¡£ &os; ¤Ï¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï¡¢¥°¥é¥Õ¥£¥«¥ë¤Ê´Ä¶­¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Þ¤»¤ó¤¬¡¢ ¿¤¯¤Î¤â¤Î¤òÍøÍѤǤ­¤Þ¤¹¡£ ¤òÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ &os; ¤Î¥·¥ã¥Ã¥È¥À¥¦¥ó ŬÀÚ¤Ë &os; ¤ò¥·¥ã¥Ã¥È¥À¥¦¥ó¤¹¤ë¤³¤È¤Ï¡¢ ¥Ï¡¼¥É¥¦¥§¥¢¤ò¥À¥á¡¼¥¸¤«¤é¼é¤Ã¤¿¤ê¡¢¥Ç¡¼¥¿¤ÎÊݸî¤Ë¤Ä¤Ê¤¬¤ê¤Þ¤¹¡£ ¤¿¤ÀÅŸ»¤òÍ¤È¤¤¤¦¤³¤È¤Ï¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£ wheel ¥°¥ë¡¼¥×¤Î¥á¥ó¥Ð¤È¤Ê¤Ã¤Æ¤¤¤ë¥æ¡¼¥¶¤Ï¡¢ ¥³¥Þ¥ó¥É¥é¥¤¥ó¤«¤é su ¤ÈÆþÎϤ·¡¢ root ¥Ñ¥¹¥ï¡¼¥É¤òÆþÎϤ·¤Æ root ¤È¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤Þ¤¿¤Ï root ¤È¤·¤Æ¥í¥°¥¤¥ó¤·¡¢ shutdown -p now ¤ò»ÈÍѤ·¤Þ¤¹¡£¥·¥¹¥Æ¥à¤ÏÀµ¤·¤¯¥·¥ã¥Ã¥È¥À¥¦¥ó¤·¡¢ÅŸ»¤¬Íî¤Á¤Þ¤¹¡£ Ctrl Alt Del ¤È¤¤¤¦¥­¡¼¤ÎÁȹ礻¤ò»È¤Ã¤Æ¥·¥¹¥Æ¥à¤ò¥ê¥Ö¡¼¥È¤¹¤ë¤³¤È¤â¤Ç¤­¤Þ¤¹¤¬¡¢ Ä̾ï¤Î±¿ÍѤˤª¤¤¤Æ¤³¤ì¤Ï¿ä¾©¤µ¤ì¤Þ¤»¤ó¡£
¥È¥é¥Ö¥ë¥·¥å¡¼¥Æ¥£¥ó¥° ¥¤¥ó¥¹¥È¡¼¥ë ¥È¥é¥Ö¥ë¥·¥å¡¼¥Æ¥£¥ó¥° ¤³¤ÎÀá¤Ç¤Ï¡¢¥¤¥ó¥¹¥È¡¼¥ë¤ÎºÝ¤Î¡¢ ¤³¤ì¤Þ¤ÇÊó¹ð¤µ¤ì¤¿¶¦Ä̤ÎÌäÂê¤ËÂФ¹¤ë²ò·è¤Î¤¿¤á¤Î¾ðÊ󤬽ñ¤¤¤Æ¤¢¤ê¤Þ¤¹¡£ ¤Ê¤Ë¤«¤ª¤«¤·¤¤¤È¤­¤Ë¤Ï²¿¤ò¤¹¤ì¤Ð¤è¤¤¤Ç¤·¤ç¤¦¤« PC ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î¤µ¤Þ¤¶¤Þ¤ÊÀ©¸Â¤Ë¤è¤ê¡¢ 100% ³Î¼Â¤Ë¸¶°ø¤òÆÍ¤­»ß¤á¤ë¤³¤È¤ÏÉÔ²Äǽ¤Ç¤¹¤¬¡¢ ¼ºÇÔ¤·¤¿»þ¤Ë¤¤¤¯¤Ä¤«¤Ç¤­¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë &os; ¤Î¥Ð¡¼¥¸¥ç¥ó¤Î ¥Ï¡¼¥É¥¦¥§¥¢¥Î¡¼¥È ¤òÄ´¤Ù¤Æ¡¢ »È¤Ã¤Æ¤¤¤ë¥Ï¡¼¥É¥¦¥§¥¢¤ËÂбþ¤·¤Æ¤¤¤ë¤«¤É¤¦¤«¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤â¤·¥Ï¡¼¥É¥¦¥§¥¢¤¬¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤ë¤Ë¤â¤«¤«¤ï¤é¤º¡¢ ưºî¤·¤Ê¤«¤Ã¤¿¤ê¾¤ÎÌäÂêÅÀ¤¬¤¢¤ë»þ¤Ï¡¢¥«¥¹¥¿¥à¥«¡¼¥Í¥ë ¤ò¹½ÃÛ¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£GENERIC ¥«¡¼¥Í¥ë¤Ë´Þ¤Þ¤ì¤Æ¤¤¤Ê¤¤¥Ç¥Ð¥¤¥¹¤Î¥µ¥Ý¡¼¥È¤òÄɲ乤뤳¤È¤¬¤Ç¤­¤Þ¤¹¡£ µ¯Æ°¥Ç¥£¥¹¥¯¤Î¥«¡¼¥Í¥ë¤Ç¤Ï¡¢¤Û¤È¤ó¤É¤Î¥Ï¡¼¥É¥¦¥§¥¢¥Ç¥Ð¥¤¥¹¤Î IRQ, IO ¥¢¥É¥ì¥¹¡¢ DMA ¥Á¥ã¥Í¥ë¤¬¹©¾ì½Ð²Ù»þ¤Î¾õÂ֤Ǥ¢¤ë¤ÈÀßÄꤵ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤â¤·¥Ï¡¼¥É¥¦¥§¥¢¤ÎÀßÄ꤬Êѹ¹¤µ¤ì¤Æ¤¤¤ë¤È¡¢ ¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤òÊÔ½¸¤·¡¢ ºÆ¥³¥ó¥Ñ¥¤¥ë¤ò¹Ô¤Ê¤Ã¤Æ¡¢¤³¤ì¤é¤ÎÃͤò &os; ¤ËÀßÄꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ¸ºß¤·¤Ê¤¤¥Ç¥Ð¥¤¥¹¤òǧ¼±¤·¤Æ¤·¤Þ¤¦¤³¤È¤Ë¤è¤ê¡¢ ¤½¤Î¸å¼ÂºÝ¤Ë¸ºß¤¹¤ë¥Ç¥Ð¥¤¥¹¤Îǧ¼±¤ò¼ºÇÔ¤·¤Æ¤·¤Þ¤¦¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ¤³¤Î¤è¤¦¤Ê¾ì¹ç¤Ï¾×ÆÍ¤·¤Æ¤¤¤ë¥É¥é¥¤¥Ð¤ò̵¸ú¤Ë¤·¤Þ¤¹¡£ ¤¤¤¯¤Ä¤«¤Î¥¤¥ó¥¹¥È¡¼¥ë¾å¤ÎÌäÂê¤Ï¤µ¤Þ¤¶¤Þ¤Ê¥Ï¡¼¥É¥¦¥§¥¢ÁõÃ֤Ρ¢ ÆÃ¤Ë¥Þ¥¶¡¼¥Ü¡¼¥É¤Î¥Õ¥¡¡¼¥à¥¦¥§¥¢¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤Ç²óÈò¤Þ¤¿¤Ï´ËϤ¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¥Þ¥¶¡¼¥Ü¡¼¥É¤Î¥Õ¥¡¡¼¥à¥¦¥§¥¢¤Ï BIOS ¤È¸Æ¤Ð¤ì¤ë¤³¤È¤â¤¢¤ê¡¢ ¿¤¯¤Î¥Þ¥¶¡¼¥Ü¡¼¥É¤Þ¤¿¤Ï¥³¥ó¥Ô¥å¡¼¥¿À½Â¤¥á¡¼¥«¡¼¤Ï¡¢ ¥¢¥Ã¥×¥Ç¡¼¥È¤ä¥¢¥Ã¥×¥°¥ì¡¼¥É¾ðÊó¤òºÜ¤»¤Æ¤¤¤ë¥¦¥§¥Ö¥µ¥¤¥È¤òÍѰդ·¤Æ¤¤¤Þ¤¹¡£ Ä̾À½Â¤¥á¡¼¥«¡¼¤Ï¡¢ ½ÅÍפʹ¹¿·¤Î¤è¤¦¤Ê¤½¤ì¤Ê¤ê¤ÎÍýͳ¤¬¤Ê¤¤¸Â¤ê¡¢¥Þ¥¶¡¼¥Ü¡¼¥É¤Î BIOS ¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤Ï¹Ô¤ï¤Ê¤¤¤è¤¦¿ä¾©¤·¤Æ¤¤¤Þ¤¹¡£ ¥¢¥Ã¥×¥Ç¡¼¥È¤Î²áÄø¤Ç¼ºÇÔ¤¹¤ë²ÄǽÀ­¤¬¤¢¤ê¡¢ ¤½¤Î¾ì¹ç BIOS ¤¬ÉÔ´°Á´¤Ê¾õÂ֤ˤʤꡢ ¥³¥ó¥Ô¥å¡¼¥¿¤¬Æ°ºî¤·¤Ê¤¤¸¶°ø¤È¤Ê¤êÆÀ¤ë¤«¤é¤Ç¤¹¡£ ¥È¥é¥Ö¥ë¥·¥å¡¼¥Æ¥£¥ó¥°¤Ë´Ø¤¹¤ë Q & A µ¯Æ°»þ¤Î¥Ï¡¼¥É¥¦¥§¥¢¸¡½Ð¤Ç¡¢¥·¥¹¥Æ¥à¤¬¥Ï¥ó¥°¥¢¥Ã¥×¤·¤Þ¤¹¡£ ¤Þ¤¿¤Ï¡¢¥¤¥ó¥¹¥È¡¼¥ëÃæ¤Ë¥·¥¹¥Æ¥à¤¬¤ª¤«¤·¤¯¤Ê¤ê¤Þ¤¹¡£ i386, amd64 ¤ª¤è¤Ó ia64 ¥×¥é¥Ã¥È¥Õ¥©¡¼¥à¤Ë¤ª¤¤¤Æ¡¢ &os; ¤Ï¥·¥¹¥Æ¥à¤ÎÀßÄê¤ò¼ê½õ¤±¤¹¤ë¥·¥¹¥Æ¥à ACPI ¥µ¡¼¥Ó¥¹¤ò¡¢ µ¯Æ°»þ¤Ë¸¡½Ð¤µ¤ì¤¿¾ì¹ç¤Ë¹­¤¯»È¤¤¤Þ¤¹¡£ »Äǰ¤Ê¤¬¤é¡¢¤Þ¤À¤¤¤¯¤Ä¤«¤ÎÉÔ¶ñ¹ç¤¬¡¢ ACPI ¥É¥é¥¤¥Ð¤È¥·¥¹¥Æ¥à¤Î¥Þ¥¶¡¼¥Ü¡¼¥É¤ª¤è¤Ó BIOS ¥Õ¥¡¡¼¥à¥¦¥§¥¢Î¾Êý¤Ë¸ºß¤·¤Æ¤¤¤Þ¤¹¡£ µ¯Æ°¥¹¥Æ¡¼¥¸ 3 ¤Ë¤ª¤¤¤Æ¡¢¥Ò¥ó¥È¾ðÊó hint.acpi.0.disabled ¤ò°Ê²¼¤Î¤è¤¦¤ËÀßÄꤹ¤ë¤È ACPI ¤ò̵¸ú¤Ë¤Ç¤­¤Þ¤¹¡£ set hint.acpi.0.disabled="1" ¤³¤ÎÀßÄê¤Ï¥·¥¹¥Æ¥à¤¬µ¯Æ°¤¹¤ë¤¿¤Ó¤Ë¥ê¥»¥Ã¥È¤µ¤ì¤ë¤Î¤Ç¡¢ /boot/loader.conf ¥Õ¥¡¥¤¥ë¤Ë hint.acpi.0.disabled="1" ¤òÄɲ䷤Ƥ¯¤À¤µ¤¤¡£ ¥Ö¡¼¥È¥í¡¼¥À¤Î¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¤ÇÀâÌÀ¤·¤Þ¤¹¡£ Live CD ¤ò»È¤¦ &os; ¤Î live CD ¤Ï¡¢¥á¥¤¥ó¤Î¥¤¥ó¥¹¥È¡¼¥ë¥×¥í¥°¥é¥à¤ÈƱ¤¸ CD ¤Ë´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Ë &os; ¤ò»È¤ª¤¦¤«¤É¤¦¤«¹Í¤¨¤Æ¤¤¤ëÊý¤ä¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÁ°¤Ëµ¡Ç½¤ò»î¤·¤Æ¸«¤¿¤¤¤È»×¤Ã¤Æ¤¤¤ëÊý¤ËÍ­ÍѤǤ¹¡£ live CD ¤ò»È¤¦ºÝ¤Ï¡¢°Ê²¼¤Î¤³¤È¤Ëµ¤¤ò¤Ä¤±¤Æ¤¯¤À¤µ¤¤¡£ ¥·¥¹¥Æ¥à¤Ë¥¢¥¯¥»¥¹¤¹¤ëºÝ¤Ë¤Ï¡¢Ç§¾Ú¤òµá¤á¤é¤ì¤Þ¤¹¡£ ¥æ¡¼¥¶Ì¾¤Ï root¡¢¥Ñ¥¹¥ï¡¼¥É¤Ï¶õÍó¤È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥·¥¹¥Æ¥à¤Ï CD ¤«¤éµ¯Æ°¤¹¤ë¤¿¤á¡¢ ¥Ï¡¼¥É¥Ç¥£¥¹¥¯¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤¿¥·¥¹¥Æ¥à¤ËÈæ¤Ù¡¢ ¥Ñ¥Õ¥©¡¼¥Þ¥ó¥¹¤Ï¤«¤Ê¤êÃÙ¤¤²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ live CD ¤Î¥æ¡¼¥¶¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤Ï¥³¥Þ¥ó¥É¥×¥í¥ó¥×¥È¤Ç¤¹¡£ ¥°¥é¥Õ¥£¥«¥ë¤Ê¥æ¡¼¥¶¥¤¥ó¥¿¥Õ¥§¡¼¥¹¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£
diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml index d96c6bb4b9..4b707da9ad 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml @@ -1,3183 +1,3215 @@ Jim Mock ºÆ¹½À®¡¢ºÆÊÔÀ®¤ª¤è¤Ó²þÄû: Jordan Hubbard ¸¶ºî: Poul-Henning Kamp John Polstra Nik Clayton &os; ¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤È¥¢¥Ã¥×¥°¥ì¡¼¥É ¤³¤Î¾Ï¤Ç¤Ï ¤¢¤ë¥ê¥ê¡¼¥¹¤«¤é¼¡¤Î¥ê¥ê¡¼¥¹¤Þ¤Ç¤Î´ü´Ö¤Ë¤â¡¢ &os; ¤Î³«È¯¤ÏµÙ¤ß¤Ê¤¯Â³¤±¤é¤ì¤Æ¤¤¤Þ¤¹¡£ ºÇ¿·¤Î³«È¯¥Ä¥ê¡¼¤ÈƱ´ü¤¹¤ë¤³¤È¤ò¹¥¤à¿Í¤â¤¤¤Þ¤¹¤·¡¢ ¸ø¼°¤Î¥ê¥ê¡¼¥¹ÈǤò¹¥¤ó¤Ç»È¤¦Êý¤â¤¤¤Þ¤¹¡£ ¤·¤«¤·¤Ê¤¬¤é¡¢¸ø¼°¤Î¥ê¥ê¡¼¥¹¤È¤¤¤¨¤É¤â¡¢ ¥»¥­¥å¥ê¥Æ¥£¤ä¾¤Î½ÅÍפʽ¤Àµ¤Î¤¿¤á¡¢»þ¤Ë¤Ï¥¢¥Ã¥×¥Ç¡¼¥È¤ò¹Ô¤¦É¬Íפ¬¤¢¤ê¤Þ¤¹¡£ »ÈÍѤ·¤Æ¤¤¤ë¥Ð¡¼¥¸¥ç¥ó¤Ë´Ø¤ï¤é¤º¡¢&os; ¤Ï¡¢ ¼ê¸µ¤Î¥·¥¹¥Æ¥à¤òºÇ¿·¤Î³«È¯¥Ä¥ê¡¼¤ÈƱ´ü¤¹¤ë¤¿¤á¤ËɬÍפʥġ¼¥ë¤ò¤¹¤Ù¤ÆÍѰդ·¤Æ¤¤¤Þ¤¹¡£ ¤½¤·¤Æ¡¢¤³¤ì¤é¤Î¥Ä¡¼¥ë¤Ï¡¢&os; ¤Î¥Ð¡¼¥¸¥ç¥ó¤ò¥¢¥Ã¥×¥°¥ì¡¼¥É¤¹¤ë¤¿¤á¤Ë»È¤¨¤Þ¤¹¡£ ¤³¤Î¾Ï¤Ç¤Ï¡¢³«È¯¥Ö¥é¥ó¥Á¤òÄɤ¤¤«¤±¤ëÊýË¡¡¢¤ª¤è¤Ó¡¢&os; ¥·¥¹¥Æ¥à¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë´ðËÜŪ¤Ê¥Ä¡¼¥ë¤Ë¤Ä¤¤¤Æ²òÀ⤷¤Æ¤¤¤Þ¤¹¡£ ¤³¤Î¾Ï¤òÆÉ¤ó¤Çʬ¤«¤ë¤Î¤Ï: ¥·¥¹¥Æ¥à¤È Ports Collection ¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤ËÍѤ¤¤ë¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤Ë¤Ä¤¤¤Æ freebsd-update, Subversion ¤â¤·¤¯¤Ï CTM ¤ò»È¤Ã¤¿ &os; ¥·¥¹¥Æ¥à¤Î¹¹¿·ÊýË¡ ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥·¥¹¥Æ¥à¤È¡¢Êѹ¹¤¬¹Ô¤ï¤ì¤Æ¤¤¤Ê¤¤¾õÂ֤ȤÎÈæ³ÓÊýË¡¡£ Subversion ¤Þ¤¿¤Ï¥É¥­¥å¥á¥ó¥ÈÍѤΠports ¤ò»È¤Ã¤Æ¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥É¥­¥å¥á¥ó¥È¤òºÇ¿·¤Î¤â¤Î¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ëÊýË¡¡£ 2 ¤Ä¤Î³«È¯¥Ö¥é¥ó¥Á¡¢&os.stable; ¤È &os.current; ¤Î°ã¤¤ ¥Ù¡¼¥¹¥·¥¹¥Æ¥àÁ´ÂΤòºÆ¹½ÃÛ¤·¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÊýË¡ ¤³¤Î¾Ï¤òÆÉ¤àÁ°¤Ë¡¢°Ê²¼¤Î½àÈ÷¤ò¤·¤Þ¤·¤ç¤¦¡£ ¥Í¥Ã¥È¥ï¡¼¥¯Àܳ¤ÎŬÀÚ¤ÊÀßÄê () ¥µ¡¼¥É¥Ñ¡¼¥Æ¥£À½¤Î¥½¥Õ¥È¥¦¥§¥¢¤Î¥¤¥ó¥¹¥È¡¼¥ëÊýË¡¤Î½¬ÆÀ () ¤³¤Î¾Ï¤òÄ̤¸¤Æ¡¢ &os; ¤Î¥½¡¼¥¹¥³¡¼¥É¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤¿¤ê¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤Î¤Ë svn ¤¬ÍѤ¤¤é¤ì¤Þ¤¹¡£ ¤³¤Î¥³¥Þ¥ó¥É¤ò»È¤¦¤¿¤á¤Ë¤Ï¡¢devel/subversion port ¤Þ¤¿¤Ï package ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤ª¤¯É¬Íפ¬¤¢¤ê¤Þ¤¹¡£ Tom Rhodes ´ó¹Æ: Colin Percival ¥Ù¡¼¥¹¤È¤Ê¤Ã¤¿¥Î¡¼¥È¤ÎÄó¶¡: &os; Update Updating and Upgrading freebsd-update updating-upgrading ¥»¥­¥å¥ê¥Æ¥£¥Ñ¥Ã¥Á¤òŬÍѤ¹¤ë¤³¤È¤Ï¡¢¥³¥ó¥Ô¥å¡¼¥¿¥½¥Õ¥È¥¦¥§¥¢¡¢ ÆÃ¤Ë¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤ò´ÉÍý¤¹¤ë¾å¤Ç½ÅÍפÊÌò³ä¤ò²Ì¤¿¤·¤Þ¤¹¡£ ¤·¤«¤·¤Ê¤¬¤é¡¢&os; ¤Ë¤ª¤¤¤Æ¤Ï¡¢ ¤³¤Î¥×¥í¥»¥¹¤Ï´Êñ¤Ê¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¤Ç¤·¤¿¡£ ¥½¡¼¥¹¥³¡¼¥É¤Ë¥Ñ¥Ã¥Á¤òÅö¤Æ¡¢¥³¡¼¥É¤«¤é¥Ð¥¤¥Ê¥ê¤òºÆ¹½ÃÛ¤·¡¢ ¥Ð¥¤¥Ê¥ê¤òºÆ¤Ó¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤·¤¿¡£ ¸½ºß¤Î &os; ¤Ç¤Ï freebsd-update ¤È¸Æ¤Ð¤ì¤ë¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤¬Äɲ䵤졢¾õ¶·¤ÏÊѤï¤ê¤Þ¤·¤¿¡£ ¤³¤Î¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤Ï 2 ¤Ä¤Îµ¡Ç½¤ò»ý¤Ã¤Æ¤¤¤Þ¤¹¡£ Âè°ì¤Ë¡¢&os; ¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤Î¥Ó¥ë¥É¤ä¥¤¥ó¥¹¥È¡¼¥ë¤ò¹Ô¤¦¤³¤È¤Ê¤¯¡¢ ¥Ð¥¤¥Ê¥ê¤Ë¤è¤Ã¤Æ¥»¥­¥å¥ê¥Æ¥£¤ª¤è¤Ó eratta ¥¢¥Ã¥×¥Ç¡¼¥È¤Ç¤­¤Þ¤¹¡£ ÂèÆó¤Ë¡¢¤³¤Î¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤Ï¥Þ¥¤¥Ê¡¼¤ª¤è¤Ó¥á¥¸¥ã¡¼¥ê¥ê¡¼¥¹¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£ ¥Ð¥¤¥Ê¥ê¥¢¥Ã¥×¥Ç¡¼¥È¤Ï¡¢ ¥»¥­¥å¥ê¥Æ¥£¥Á¡¼¥à¤¬¥µ¥Ý¡¼¥È¤·¤Æ¤¤¤ë¤¹¤Ù¤Æ¤Î¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤È¥ê¥ê¡¼¥¹¤ÇÍøÍѤǤ­¤Þ¤¹¡£ ¿·¤·¤¤¥ê¥ê¡¼¥¹¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ëÁ°¤Ë¡¢ ¥¢¥Ã¥×¥Ç¡¼¥È¤·¤è¤¦¤È¤·¤Æ¤¤¤ë¥ê¥ê¡¼¥¹¤Î¥¢¥Ê¥¦¥ó¥¹¤ËÌܤòÄ̤·¡¢ ½ÅÍפʾðÊ󤬤ʤ¤¤«¤É¤¦¤«¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥ê¥ê¡¼¥¹¤Î¥¢¥Ê¥¦¥ó¥¹¤Ï ¤Ç³Îǧ¤Ç¤­¤Þ¤¹¡£ ¤â¤· crontab ¤ÎÃæ¤Ë &man.freebsd-update.8; ¤Îµ¡Ç½¤¬´Þ¤Þ¤ì¤Æ¤¤¤¿¤é¡¢ °Ê²¼¤Îºî¶È¤ò¹Ô¤¦¤Þ¤Ç¤Ï̵¸ú¤Ë¤·¤Æ¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£ ÀßÄê¥Õ¥¡¥¤¥ë /etc/freebsd-update.conf ¤ÎÀßÄê¤ò¥Ç¥Õ¥©¥ë¥È¤«¤é¤­¤áºÙ¤«¤¯Ä´À°¤·¤Æ¡¢ ¥¢¥Ã¥×¥Ç¡¼¥È¥×¥í¥»¥¹¤òÀ©¸æ¤¹¤ë¥æ¡¼¥¶¤â¤¤¤Þ¤¹¡£ ¤³¤Îºî¶È¤ÏÎɤ¯Ê¸½ñ²½¤µ¤ì¤Æ¤¤¤Þ¤¹¤¬¡¢ °Ê²¼¤Î¹àÌܤˤĤ¤¤Æ¤ÏÀâÌÀ¤¬É¬ÍפǤ·¤ç¤¦¡£ # Components of the base system which should be kept updated. Components src world kernel ¤³¤Î¥Ñ¥é¥á¡¼¥¿¤Ï¡¢&os; ¤Î¤É¤ÎÉôʬ¤òºÇ¿·¤Ë°Ý»ý¤¹¤ë¤«¤òÀßÄꤷ¤Þ¤¹¡£ ¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï¥½¡¼¥¹¥³¡¼¥É¡¢¥Ù¡¼¥¹¥·¥¹¥Æ¥àÁ´ÂΡ¢¤½¤·¤Æ¥«¡¼¥Í¥ë¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Þ¤¹¡£ Components ¤ËÀßÄê¤Ç¤­¤ë¹àÌܤϡ¢¥¤¥ó¥¹¥È¡¼¥ë»þ¤ËÁªÂò¤Ç¤­¤ë¤â¤Î¤ÈƱ¤¸¤Ç¤¹¡£ ¤¿¤È¤¨¤Ð¡¢¤³¤³¤Ç world/games ¤òÄɲ乤ë¤È¡¢ game ¤Ë¥Ñ¥Ã¥Á¤¬Åö¤¿¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£ src/bin ¤òÄɲ乤ë¤È¡¢ src/bin ¥½¡¼¥¹¥³¡¼¥É¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤òµö²Ä¤·¤Þ¤¹¡£ ¤³¤ÎÉôʬ¤Ë¤Ä¤¤¤Æ¤Ï¥Ç¥Õ¥©¥ë¥È¤Î¤Þ¤Þ¤Ë¤·¤Æ¤ª¤­¡¢ ¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¹àÌܤò¥æ¡¼¥¶¤¬¥ê¥¹¥È¤Ë²Ã¤¨¤ë·Á¤Ë¤¹¤ë¤Î¤¬¥Ù¥¹¥È¤Ç¤·¤ç¤¦¡£ ¥½¡¼¥¹¥³¡¼¥É¤È¥Ð¥¤¥Ê¥ê¤¬Æ±´ü¤·¤Æ¤¤¤Ê¤¤¤È¡¢ Èá»´¤Ê·ë²Ì¤ò¤â¤¿¤é¤¹²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /bin ¤ä /sbin Åù¤ÎÆÃÄê¤Î¥Ç¥£¥ì¥¯¥È¥ê¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤ÇÊѹ¹¤·¤Ê¤¤¤è¤¦¤Ë¡¢ ¤³¤ì¤é¤Î¥Ñ¥¹¤òÄɲ䷤Ƥ¯¤À¤µ¤¤¡£ ¤³¤Î¥ª¥×¥·¥ç¥ó¤Ï¡¢¥í¡¼¥«¥ë¤ÎÊѹ¹ÅÀ¤ò freebsd-update ¤¬¾å½ñ¤­¤¹¤ë¤³¤È¤òËɤ°ÌÜŪ¤Ë¤âÍøÍѤǤ­¤Þ¤¹¡£ # Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile ¤³¤Î¥ª¥×¥·¥ç¥ó¤Ï¡¢»ØÄꤷ¤¿¥Ç¥£¥ì¥¯¥È¥ê¤Ë¤¢¤ëÀßÄê¥Õ¥¡¥¤¥ë¤ò¡¢ ¥í¡¼¥«¥ë¤ÇÊѹ¹¤µ¤ì¤Æ¤¤¤Ê¤¤¾ì¹ç¤Î¤ß¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Þ¤¹¡£ ¥æ¡¼¥¶¤¬¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤òÊѹ¹¤·¤Æ¤¤¤ë¤È¡¢ ¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤Î¼«Æ°¥¢¥Ã¥×¥Ç¡¼¥È¤Ï̵¸ú¤Ë¤Ê¤ê¤Þ¤¹¡£ ¾¤Ë¡¢KeepModifiedMetadata ¤È¤¤¤¦Ê̤Υª¥×¥·¥ç¥ó¤¬Â¸ºß¤·¤Þ¤¹¡£ ¤³¤Î¥ª¥×¥·¥ç¥ó¤Ï¡¢freebsd-update ¤¬¥Þ¡¼¥¸Ãæ¤ËÊѹ¹ÅÀ¤òÊݸ¤¹¤ë¤è¤¦¤Ë¤·¤Þ¤¹¡£ # When upgrading to a new &os; release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ freebsd-update ¤¬¥Þ¡¼¥¸¤¹¤Ù¤­¥Õ¥¡¥¤¥ë¤¬Â¸ºß¤¹¤ë¥Ç¥£¥ì¥¯¥È¥ê¤Î°ìÍ÷¤Ç¤¹¡£ ¥Õ¥¡¥¤¥ë¤Î¥Þ¡¼¥¸¤Î¥×¥í¥»¥¹¤Ï¡¢ &man.mergemaster.8; ¤ÈƱÍÍ &man.diff.1; ¥Ñ¥Ã¥Á¤ÎϢ³¤Ç¤¹¤¬¡¢ ÁªÂò»è¤Ï¾¯¤Ê¤¯¡¢¥Þ¡¼¥¸¤ò¾µÇ§¤¹¤ë¤«¡¢¥¨¥Ç¥£¥¿¤òµ¯Æ°¤¹¤ë¤«¡¢ freebsd-update ¤òÃæÃǤ¹¤ë¤«¤É¤¦¤«¤òÁª¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¤â¤·¡¢¿´ÇÛ¤ÊÅÀ¤¬¤¢¤ì¤Ð¡¢ /etc ¤ò¥Ð¥Ã¥¯¥¢¥Ã¥×¤·¤Æ¤«¤é¥Þ¡¼¥¸¤ò¾µÇ§¤·¤Æ¤¯¤À¤µ¤¤¡£ mergemaster ¤Î¾ÜºÙ¤Ê¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¤Ç³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ # Directory in which to store downloaded updates and temporary # files used by &os; Update. # WorkDir /var/db/freebsd-update ¤³¤³¤Ç¤Ï¤¹¤Ù¤Æ¤Î¥Ñ¥Ã¥Á¤ä°ì¼¡¥Õ¥¡¥¤¥ë¤òÃÖ¤¯¥Ç¥£¥ì¥¯¥È¥ê¤ò»ØÄꤷ¤Æ¤¤¤Þ¤¹¡£ ¥Ð¡¼¥¸¥ç¥ó¤ò¥¢¥Ã¥×¥°¥ì¡¼¥É¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¤³¤Î¾ì½ê¤Ë¤Ï¾¯¤Ê¤¯¤È¤â¥®¥¬¥Ð¥¤¥È¤Î¶õ¤­ÍÆÎ̤¬É¬ÍפǤ¹¡£ # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which &os; Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no ¤³¤Î¥ª¥×¥·¥ç¥ó¤ò yes ¤ËÀßÄꤹ¤ë¤È¡¢ freebsd-update ¤Ï Components ¤Î¥ê¥¹¥È¤¬´°Á´¤ËÀµ¤·¤¤¤ÈȽÃǤ·¡¢ ¤³¤Î¥ê¥¹¥È°Ê³°¤ÎÊѹ¹ÅÀ¤Ë¤Ä¤¤¤Æ¤Ï¼è¤ê°·¤¤¤Þ¤»¤ó¡£ freebsd-update ¤Ï¡¢¸úΨŪ¤Ë Components ¥ê¥¹¥È¤Ë°¤¹¤ë¥Õ¥¡¥¤¥ë¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Þ¤¹¡£ ¥»¥­¥å¥ê¥Æ¥£¥Ñ¥Ã¥Á °Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤¹¤ë¤È¡¢&os; ¤Î¥»¥­¥å¥ê¥Æ¥£¥Ñ¥Ã¥Á¤¬¥À¥¦¥ó¥í¡¼¥É¤µ¤ì¡¢¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install ¥¢¥Ã¥×¥Ç¡¼¥È¤Ë¤è¤Ã¤Æ¥«¡¼¥Í¥ë¤Ë¥Ñ¥Ã¥Á¤¬Åö¤¿¤Ã¤¿¾ì¹ç¤Ë¤Ï¡¢ ¥Ñ¥Ã¥Á¤¬Åö¤¿¤Ã¤¿¥«¡¼¥Í¥ë¤Çµ¯Æ°¤¹¤ë¤è¤¦¤Ë¡¢ ¥·¥¹¥Æ¥à¤òºÆµ¯Æ°¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¤â¤·¤¯¤Ï¡¢¥·¥¹¥Æ¥à¤Ë¥Ñ¥Ã¥Á¤¬Åö¤Æ¤é¤ì¡¢ ËèÈդΠ&man.cron.8; ¥¸¥ç¥Ö¤È¤·¤Æ¡¢freebsd-update ¤ò¼Â¹Ô¤¹¤ë¤è¤¦¤Ë¡¢ °Ê²¼¤Î¥¨¥ó¥È¥ê¤ò /etc/crobntab ¤ËÄɲ䷤Ƥ¯¤À¤µ¤¤¡£ @daily root freebsd-update cron ¤³¤Î¥¨¥ó¥È¥ê¤Ï¡¢ËèÆü°ìÅÙ freebsd-update ¤ò¼Â¹Ô¤¹¤ë¤³¤È¤ò°ÕÌ£¤·¤Þ¤¹¡£ ¤È¶¦¤Ë¼Â¹Ô¤¹¤ë¤È¡¢ freebsd-update ¤Ï¥¢¥Ã¥×¥Ç¡¼¥È¤¬Â¸ºß¤¹¤ë¤È¤­¤À¤±³Îǧ¤·¤Þ¤¹¡£ ¥Ñ¥Ã¥Á¤¬Â¸ºß¤¹¤ë¤È¡¢ ¼«Æ°Åª¤Ë¥í¡¼¥«¥ë¥Ç¥£¥¹¥¯¤Ë¥À¥¦¥ó¥í¡¼¥É¤µ¤ì¤Þ¤¹¤¬¡¢Å¬ÍѤϤµ¤ì¤Þ¤»¤ó¡£ ¥À¥¦¥ó¥í¡¼¥É¤µ¤ì¤¿¥Ñ¥Ã¥Á¤ò³Îǧ¤·¡¢¼êư¤Ç¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëɬÍפΤ¢¤ë¤³¤È¤¬¡¢ root °¸¤Æ¤Ë¥á¡¼¥ë¤ÇÄÌÃΤµ¤ì¤Þ¤¹¡£ ¤¦¤Þ¤¯¹Ô¤«¤Ê¤«¤Ã¤¿¾ì¹ç¤Ë¤Ï¡¢freebsd-update ¤ò°Ê²¼¤Î¤è¤¦¤Ë¼Â¹Ô¤¹¤ë¤È¡¢ºÇ¸å¤ÎÊѹ¹¤Þ¤Ç¥í¡¼¥ë¥Ð¥Ã¥¯¤Ç¤­¤Þ¤¹¡£ &prompt.root; freebsd-update rollback ¥«¡¼¥Í¥ë¤Þ¤¿¤Ï¥«¡¼¥Í¥ë¥â¥¸¥å¡¼¥ë¤¬¥¢¥Ã¥×¥Ç¡¼¥È¤µ¤ì¤¿¾ì¹ç¤Ë¤Ï¡¢ ´°Î»¸å¤Ë¥·¥¹¥Æ¥à¤òºÆµ¯Æ°¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Îºî¶È¤Ë¤è¤Ã¤Æ¡¢&os; ¤¬¥Ð¥¤¥Ê¥ê¤ò¥á¥â¥ê¤ËÆÉ¤ß¹þ¤ß¤Þ¤¹¡£ freebsd-update ¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤¬¼«Æ°Åª¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¥«¡¼¥Í¥ë¤Ï GENERIC ¤Î¤ß¤Ç¤¹¡£ ¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¾ì¹ç¤Ë¤Ï¡¢ freebsd-update ¤¬Â¾¤ÎÉôʬ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤¿¸å¡¢ ¥«¡¼¥Í¥ë¤òºÆ¹½ÃÛ¤·¡¢¤â¤¦°ìÅÙ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¤·¤«¤·¤Ê¤¬¤é¡¢GENERIC ¥«¡¼¥Í¥ë¤¬ /boot/GENERIC ¤Ë¸ºß¤¹¤ë¾ì¹ç¤Ë¤Ï¡¢ ¸½ºß¤Î¥·¥¹¥Æ¥à¤Ç¼Â¹Ô¤µ¤ì¤Æ¤¤¤ë¥«¡¼¥Í¥ë¤Ç¤Ê¤¯¤È¤â¡¢ freebsd-update ¤Ë¤è¤ê¥¢¥Ã¥×¥Ç¡¼¥È¤µ¤ì¤Þ¤¹¡£ GENERIC ¥«¡¼¥Í¥ë¤ò¡¢¾ï¤Ë /boot/GENERIC ¤ËÃÖ¤¤¤Æ¤ª¤¯¤³¤È¤ÏÎɤ¤¹Í¤¨¤Ç¤¹¡£ ¤µ¤Þ¤¶¤Þ¤ÊÌäÂê¤ò²ò·è¤¹¤ëºÝ¤ä¡¢ ¤ËÀâÌÀ¤µ¤ì¤Æ¤¤¤ë¤è¤¦¤Ë¡¢ freebsd-update ¤òÍѤ¤¤Æ¥Ð¡¼¥¸¥ç¥ó¤ò¥¢¥Ã¥×¥°¥ì¡¼¥É¤¹¤ëºÝ¤Ë½õ¤±¤È¤Ê¤ê¤Þ¤¹¡£ /etc/freebsd-update.conf ¤Î¥Ç¥Õ¥©¥ë¥È¤ÎÀßÄê¤òÊѹ¹¤·¤Ê¤¤¸Â¤ê¡¢ freebsd-update ¤Ï¡¢ ¾¤Î¹¹¿·¤È¶¦¤Ë¥«¡¼¥Í¥ë¥½¡¼¥¹¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Þ¤¹¡£ ¿·¤·¤¤¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤ÎºÆ¹½ÃۤȺƥ¤¥ó¥¹¥È¡¼¥ë¤Ï¡¢ Ä̾ïÄ̤ê¹Ô¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ freebsd-update ¤Ï¡¢ ¾ï¤Ë¥«¡¼¥Í¥ë¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤È¤Ï¸Â¤ê¤Þ¤»¤ó¡£ freebsd-update install ¤Ë¤è¤Ã¤Æ¥«¡¼¥Í¥ë¥½¡¼¥¹¤¬Êѹ¹¤µ¤ì¤Ê¤«¤Ã¤¿¾ì¹ç¤Ë¤Ï¡¢ ¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤òºÆ¹½ÃÛ¤¹¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£ ¤·¤«¤·¤Ê¤¬¤é freebsd-update ¤Ï¡¢ /usr/src/sys/conf/newvers.sh ¤ò¾ï¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Þ¤¹¡£ ¤³¤ì¤Ï¡¢¸½ºß¤Î¥·¥¹¥Æ¥à¤Î¥Ñ¥Ã¥Á¥ì¥Ù¥ë¤ò uname -r ¤¬ -p ¤Çɽ¼¨¤¹¤ë»þ¤Ë¤³¤Î¥Õ¥¡¥¤¥ë¤¬»²¾È¤µ¤ì¤Þ¤¹¡£ ¤½¤Î¤¿¤á¡¢²¿¤âÊѹ¹¤µ¤ì¤Æ¤¤¤Ê¤¤¾ì¹ç¤Ç¤â¡¢¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤òºÆ¹½ÃÛ¤¹¤ë¤³¤È¤Ë¤è¤ê¡¢ &man.uname.1; ¤¬¥·¥¹¥Æ¥à¤ÎÀµ³Î¤Ê¥Ñ¥Ã¥Á¥ì¥Ù¥ë¤òÊó¹ð¤¹¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£ ³Æ¥·¥¹¥Æ¥à¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥¢¥Ã¥×¥Ç¡¼¥È¤ò¤¹¤Ð¤ä¤¯Çİ®¤Ç¤­¤ë¤è¤¦¤Ë¤Ê¤ë¤Î¤Ç¡¢ ÆÃ¤ËÊ£¿ô¤Î¥·¥¹¥Æ¥à¤ò´ÉÍý¤¹¤ë¤È¤­¤Ë½õ¤±¤È¤Ê¤ê¤Þ¤¹¡£ ¥á¥¸¥ã¡¼¤ª¤è¤Ó¥Þ¥¤¥Ê¡¼¥Ð¡¼¥¸¥ç¥ó¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É &os; ¤Î¥Þ¥¤¥Ê¡¼¥Ð¡¼¥¸¥ç¥ó´Ö¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¡¢ ¤¿¤È¤¨¤Ð¡¢&os; 9.0 ¤«¤é &os; 9.1 ¤Ø¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤Ï¡¢ ¥Þ¥¤¥Ê¡¼¥Ð¡¼¥¸¥ç¥ó ¥¢¥Ã¥×¥°¥ì¡¼¥É¤È¸Æ¤Ð¤ì¤Þ¤¹¡£ Ä̾ï¤Ï¡¢¥Þ¥¤¥Ê¡¼¥Ð¡¼¥¸¥ç¥ó¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤ò¹Ô¤Ã¤¿¸å¤Ç¤â¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤ÏÌäÂê¤Ê¤¯Æ°¤­¤Þ¤¹¡£ ¥á¥¸¥ã¡¼¥Ð¡¼¥¸¥ç¥ó ¥¢¥Ã¥×¥°¥ì¡¼¥É¤Ï¡¢ &os; 8.X ¤«¤é &os; 9.X ¤Ø¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤È¤¤¤Ã¤¿¡¢ &os; ¤Î¥á¥¸¥ã¡¼¥Ð¡¼¥¸¥ç¥ó¤¬ÊѤï¤ë¤è¤¦¤Ê¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î¤³¤È¤Ç¤¹¡£ ¥á¥¸¥ã¡¼¥Ð¡¼¥¸¥ç¥ó¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤Ç¤Ï¡¢ ¸Å¤¤¥ª¥Ö¥¸¥§¥¯¥È¥Õ¥¡¥¤¥ë¤ä¥é¥¤¥Ö¥é¥ê¤¬ºï½ü¤µ¤ì¡¢ ¤³¤ì¤é¤Ë°Í¸¤¹¤ë¿¤¯¤Î¥µ¡¼¥É¥Ñ¡¼¥Æ¥£À½¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤Ë±Æ¶Á¤òÍ¿¤¨¤ë²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¤¹¤Ù¤Æ¤Î ports ¤òºï½ü¤·¤ÆºÆ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤«¡¢ ¥á¥¸¥ã¡¼¥¢¥Ã¥×¥°¥ì¡¼¥É¸å¡¢ ports-mgmt/portmaster ¤È¤¤¤Ã¤¿¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤ò»È¤Ã¤Æ¥¢¥Ã¥×¥°¥ì¡¼¥É¤¹¤ë¤³¤È¤¬¿ä¾©¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤Î¥Ö¥ë¡¼¥È¥Õ¥©¡¼¥¹Åª¤ÊºÆ¹½Ãۤϡ¢ °Ê²¼¤Î¥³¥Þ¥ó¥É¤Ë¤è¤ê¹Ô¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ &prompt.root; portmaster -af ¤³¤Î¥³¥Þ¥ó¥É¤Ï¡¢¤¹¤Ù¤Æ¤Î ports ¤òŬÀڤ˺ƥ¤¥ó¥¹¥È¡¼¥ë¤·¤è¤¦¤È¤·¤Þ¤¹¡£ BATCH ´Ä¶­ÊÑ¿ô¤ò yes ¤ËÀßÄꤷ¤Æ¤ª¤¯¤È¡¢ ¥¢¥Ã¥×¥Ç¡¼¥È¥×¥í¥»¥¹¤ÎÅÓÃæ¤Î¼ÁÌä¤ËÂФ· yes ¤ÈÅú¤¨¤ë¤è¤¦¤Ë¤Ê¤ë¤Î¤Ç¡¢ ¥Ó¥ë¥É¥×¥í¥»¥¹¤Ç¤Î¼êưÁàºî¤ò¾Êά¤Ç¤­¤Þ¤¹¡£ ¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤Î¼è¤ê°·¤¤ ¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤ò»ÈÍѤ·¤Æ¤¤¤ë¾ì¹ç¤Ë¤Ï¡¢¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î¥×¥í¥»¥¹¤Ï¡¢ ´öʬʣ»¨¤È¤Ê¤ê¤Þ¤¹¡£ ¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î¼ê½ç¤Ï &os; ¤Î¥Ð¡¼¥¸¥ç¥ó¤Ë¤è¤Ã¤ÆÊѤï¤ê¤Þ¤¹¡£ &os; 8.X ¤Ë¤ª¤±¤ë¥«¥¹¥¿¥à¥«¡¼¥Í¥ë GENERIC ¥«¡¼¥Í¥ë¤¬ /boot/GENERIC ¤ËÃÖ¤«¤ì¤Æ¤¤¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¤â¤· GENERIC ¥«¡¼¥Í¥ë¤¬¥·¥¹¥Æ¥à¤Ë¸ºß¤·¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢ °Ê²¼¤Î¤É¤ì¤«¤ÎÊýË¡¤ÇÍѰդ·¤Æ¤¯¤À¤µ¤¤¡£ ¤¿¤À°ìÅÙ¤À¤±¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤ò¹½ÃÛ¤·¤¿¤Î¤Ç¤¢¤ì¤Ð¡¢ /boot/kernel.old ¤Ï GENERIC ¥«¡¼¥Í¥ë¤½¤Î¤â¤Î¤Ç¤¹¡£ ¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Î̾Á°¤ò /boot/GENERIC ¤Ø¤ÈÊѹ¹¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥³¥ó¥Ô¥å¡¼¥¿¤Ø¤ÎʪÍýŪ¤Ê¥¢¥¯¥»¥¹¤¬²Äǽ¤Ç¤¢¤ì¤Ð¡¢ °Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤¹¤ë¤³¤È¤Ç¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤«¤é GENERIC ¥«¡¼¥Í¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤­¤Þ¤¹¡£ &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC ¤³¤³¤Ç X.Y-RELEASE ¤ò¼ÂºÝ¤Î¥ê¥ê¡¼¥¹ÈÖ¹æ¤ËÃÖ¤­´¹¤¨¤Æ¤¯¤À¤µ¤¤¡£ GENERIC ¤Ï¡¢¥Ç¥Õ¥©¥ë¥È¤Ç /boot/GENERIC ¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ ¾åµ­¤ÎÊýË¡¤¬¤¹¤Ù¤Æ¼ºÇÔ¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ GENERIC ¥«¡¼¥Í¥ë¤ò¥½¡¼¥¹¤«¤éºÆ¹½ÃÛ¤·¤Æ¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/src &prompt.root; env DESTDIR=/boot/GENERIC make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null &prompt.root; mv /boot/GENERIC/boot/kernel/* /boot/GENERIC &prompt.root; rm -rf /boot/GENERIC/boot freebsd-update ¤Ï¡¢¤³¤Î¥«¡¼¥Í¥ë¤ò GENERIC ¥«¡¼¥Í¥ë¤È¤·¤Æ°·¤¤¤Þ¤¹¡£ GENERIC ¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤Ï¡¢ ¤È¤Ë¤«¤¯Êѹ¹¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£ ¤Þ¤¿¡¢ÆÃÊ̤ʥª¥×¥·¥ç¥ó¤ò»ØÄꤷ¤Ê¤¤¤Ç¹½ÃÛ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Î»þÅÀ¤Ç GENERIC ¥«¡¼¥Í¥ë¤ÇºÆµ¯Æ°¤¹¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£ &os; 9.X °Ê¹ß¤Î¥·¥¹¥Æ¥à¤Ë¤ª¤±¤ë¥«¥¹¥¿¥à¥«¡¼¥Í¥ë ¤¿¤À°ìÅÙ¤À¤±¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤ò¹½ÃÛ¤·¤¿¤Î¤Ç¤¢¤ì¤Ð¡¢ /boot/kernel.old ¤Ï GENERIC ¥«¡¼¥Í¥ë¤½¤Î¤â¤Î¤Ç¤¹¡£ ¤¿¤Àñ¤Ë¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Î̾Á°¤ò /boot/kernel ¤Ø¤ÈÊѹ¹¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥³¥ó¥Ô¥å¡¼¥¿¤Ø¤ÎʪÍýŪ¤Ê¥¢¥¯¥»¥¹¤¬²Äǽ¤Ç¤¢¤ì¤Ð¡¢ °Ê²¼¤Î¥³¥Þ¥ó¥É¤Ç¡¢¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤«¤é GENERIC ¥«¡¼¥Í¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤­¤Þ¤¹¡£ &prompt.root; mount /cdrom &prompt.root; cd /cdrom/usr/freebsd-dist &prompt.root; tar -C/ -xvf kernel.txz boot/kernel/kernel ¾åµ­¤ÎÊýË¡¤¬¼ºÇÔ¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ GENERIC ¥«¡¼¥Í¥ë¤ò¥½¡¼¥¹¤«¤éºÆ¹½ÃÛ¤·¤Æ¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/src &prompt.root; make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null freebsd-update ¤Ï¡¢¤³¤Î¥«¡¼¥Í¥ë¤ò GENERIC ¥«¡¼¥Í¥ë¤È¤·¤Æ°·¤¤¤Þ¤¹¡£ GENERIC ¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤Ï¡¢ ¤È¤Ë¤«¤¯Êѹ¹¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£ ¤Þ¤¿¡¢ÆÃÊ̤ʥª¥×¥·¥ç¥ó¤ò»ØÄꤷ¤Ê¤¤¤Ç¹½ÃÛ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Î»þÅÀ¤Ç GENERIC ¥«¡¼¥Í¥ë¤ÇºÆµ¯Æ°¤¹¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£ ¥¢¥Ã¥×¥°¥ì¡¼¥É¤ò¹Ô¤¦ freebsd-update ¤Ë¤è¤ë¥á¥¸¥ã¡¼¡¢¤Þ¤¿¤Ï¥Þ¥¤¥Ê¡¼¥Ð¡¼¥¸¥ç¥ó¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤Ç¤Ï¡¢ ¥ê¥ê¡¼¥¹¥Ð¡¼¥¸¥ç¥ó¤ò¥¿¡¼¥²¥Ã¥È¤Ë¤·¤Æ¼Â¹Ô¤·¤Þ¤¹¡£ °Ê²¼¤Î¥³¥Þ¥ó¥É¤Ï¡¢&os; 9.1 ¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Þ¤¹¡£ &prompt.root; freebsd-update -r 9.1-RELEASE upgrade ¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤¹¤ë¤È¡¢freebsd-update ¤ÏÀßÄê¥Õ¥¡¥¤¥ë¤È¸½ºß¤Î¥·¥¹¥Æ¥à¤òɾ²Á¤·¡¢ ¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤¿¤á¤ËɬÍפʾðÊó¤ò¼ý½¸¤·¤Þ¤¹¡£ ²èÌ̤ˤϡ¢¤É¤Î¥³¥ó¥Ý¡¼¥Í¥ó¥È¤¬Ç§¼±¤µ¤ì¡¢ ¤É¤Î¥³¥ó¥Ý¡¼¥Í¥ó¥È¤¬Ç§¼±¤µ¤ì¤Æ¤¤¤Ê¤¤¤È¤¤¤Ã¤¿¥ê¥¹¥È¤¬É½¼¨¤µ¤ì¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð°Ê²¼¤Î¤è¤¦¤Ëɽ¼¨¤µ¤ì¤Þ¤¹¡£ Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 9.0-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y ¤³¤³¤Ç¡¢freebsd-update ¤Ï¥¢¥Ã¥×¥°¥ì¡¼¥É¤ËɬÍפʤ¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤Þ¤¹¡£ ²¿¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¡¢¤É¤Î¤è¤¦¤Ë¿Ê¤à¤«¤È¤¤¤Ã¤¿¼ÁÌä¤ò¤µ¤ì¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹¡£ ¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤ò»È¤Ã¤Æ¤¤¤ë¤È¡¢ ¾åµ­¤Î¥¹¥Æ¥Ã¥×¤Ç°Ê²¼¤Î¤è¤¦¤Ê·Ù¹ð¤¬É½¼¨¤µ¤ì¤Þ¤¹¡£ WARNING: This system is running a "MYKERNEL" kernel, which is not a kernel configuration distributed as part of FreeBSD 9.0-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" ¤³¤Î»þÅÀ¤Ç¤Ï¤³¤Î·Ù¹ð¤ò̵»ë¤·¤Æ¤â¤«¤Þ¤¤¤Þ¤»¤ó¡£ ¥¢¥Ã¥×¥Ç¡¼¥È¤µ¤ì¤¿ GENERIC ¥«¡¼¥Í¥ë¤Ï¡¢ ¥¢¥Ã¥×¥°¥ì¡¼¥É¥×¥í¥»¥¹¤ÎÅÓÃæ¤ÇÍøÍѤµ¤ì¤Þ¤¹¡£ ¤¹¤Ù¤Æ¤Î¥Ñ¥Ã¥Á¤¬¥í¡¼¥«¥ë¥·¥¹¥Æ¥à¤Ø¥À¥¦¥ó¥í¡¼¥É¤µ¤ì¤¿¤é¡¢ ¼¡¤Ë¥Ñ¥Ã¥Á¤¬Å¬ÍѤµ¤ì¤Þ¤¹¡£ ¤³¤Î¥×¥í¥»¥¹¤Ë¤Ï»þ´Ö¤¬¤«¤«¤ê¤Þ¤¹¡£ ¤³¤Î»þ´Ö¤Ï¥³¥ó¥Ô¥å¡¼¥¿¤ÎÀ­Ç½¤È¥ï¡¼¥¯¥í¡¼¥É¤Ë°Í¸¤·¤Þ¤¹¡£ ¤½¤Î¸å¡¢ÀßÄê¥Õ¥¡¥¤¥ë¤¬¥Þ¡¼¥¸¤µ¤ì¤Þ¤¹¡£ ¤³¤Î¥×¥í¥»¥¹¤Ç¤Ï¡¢¥æ¡¼¥¶¤Ï¥Õ¥¡¥¤¥ë¤ò¥Þ¡¼¥¸¤¹¤ë¤«¡¢ ²èÌ̾å¤Ë¥¨¥Ç¥£¥¿¤òΩ¤Á¾å¤²¤Æ¼êư¤Ç¥Þ¡¼¥¸¤¹¤ë¤«¤ò¿Ò¤Í¤é¤ì¤Þ¤¹¡£ ¥×¥í¥»¥¹¤¬¿Ê¤à¤´¤È¤Ë¡¢À®¸ù¤·¤¿¥Þ¡¼¥¸¤Î¤¹¤Ù¤Æ¤Î·ë²Ì¤Î¾ðÊ󤬥桼¥¶¤Ë¼¨¤µ¤ì¤Þ¤¹¡£ ¥Þ¡¼¥¸¤Ë¼ºÇÔ¤·¤¿¤ê¡¢Ìµ»ë¤·¤¿¾ì¹ç¤Ë¤Ï¡¢¥×¥í¥»¥¹¤¬ÃæÃǤ·¤Þ¤¹¡£ ¥æ¡¼¥¶¤Ë¤è¤Ã¤Æ¤Ï /etc ¤Î¥Ð¥Ã¥¯¥¢¥Ã¥×¤ò¼è¤ê¡¢ master.passwd ¤ä group ¤Î¤è¤¦¤Ê½ÅÍפʥե¡¥¤¥ë¤ò¸å¤Ç¼êư¤Ç¥Þ¡¼¥¸¤¹¤ëÊý¤â¤¤¤Þ¤¹¡£ ¤¹¤Ù¤Æ¤Î¥Ñ¥Ã¥Á¤ÏÊ̤Υǥ£¥ì¥¯¥È¥ê¤Ç¥Þ¡¼¥¸¤µ¤ì¤Æ¤ª¤ê¡¢ ¤Þ¤À¡¢¥·¥¹¥Æ¥à¤Ë¤ÏÈ¿±Ç¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£ ¤¹¤Ù¤Æ¤Î¥Ñ¥Ã¥Á¤¬Àµ¤·¤¯Å¬ÍѤµ¤ì¡¢ ¤¹¤Ù¤Æ¤ÎÀßÄê¥Õ¥¡¥¤¥ë¤¬¥Þ¡¼¥¸¤µ¤ì¤Æ¥×¥í¥»¥¹¤¬¥¹¥à¡¼¥º¤Ë¿Ê¤ó¤À¤é¡¢ ¥æ¡¼¥¶¤Ï°Ê²¼¤Î¥³¥Þ¥ó¥É¤òÍѤ¤¤Æ¡¢ Êѹ¹ÅÀ¤ò¥Ç¥£¥¹¥¯¤ËÈ¿±Ç¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; freebsd-update install ¥Ñ¥Ã¥Á¤ÏºÇ½é¤Ë¥«¡¼¥Í¥ë¤È¥«¡¼¥Í¥ë¥â¥¸¥å¡¼¥ë¤ËÂФ·¤ÆÅö¤Æ¤é¤ì¤Þ¤¹¡£ ¤³¤³¤Ç¥³¥ó¥Ô¥å¡¼¥¿¤òºÆµ¯Æ°¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¥·¥¹¥Æ¥à¤¬¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤ò¼Â¹Ô¤·¤Æ¤¤¤ë¾ì¹ç¤Ë¤Ï¡¢ &man.nextboot.8; ¤ò»È¤Ã¤Æ¼¡²ó¤ÎºÆµ¯Æ°»þ¤Î¥«¡¼¥Í¥ë¤ò¡¢ ¥¢¥Ã¥×¥Ç¡¼¥È¤µ¤ì¤¿ /boot/GENERIC ¤ËÀßÄꤷ¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; nextboot -k GENERIC GENERIC ¥«¡¼¥Í¥ë¤ÇºÆµ¯Æ°¤¹¤ëÁ°¤Ë¡¢ ¥«¡¼¥Í¥ë¤Ë¥·¥¹¥Æ¥à¤¬Å¬Àڤ˵¯Æ°¤¹¤ë¤¿¤á¤ËɬÍפʤ¹¤Ù¤Æ¤Î¥É¥é¥¤¥Ð¤¬´Þ¤Þ¤ì¤Æ¤¤¤ë¤³¤È¡¢ ¤â¤·¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Æ¤¤¤ë¥³¥ó¥Ô¥å¡¼¥¿¤¬¥ê¥â¡¼¥È¤Ç¥¢¥¯¥»¥¹¤·¤Æ¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯Àܳ¤ËɬÍפʤ¹¤Ù¤Æ¤Î¥É¥é¥¤¥Ð¤â´Þ¤Þ¤ì¤Æ¤¤¤ë¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ÆÃ¤Ë¡¢¤³¤ì¤Þ¤Ç¼Â¹Ô¤·¤Æ¤¤¤ë¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤¬¡¢ ¥«¡¼¥Í¥ë¥â¥¸¥å¡¼¥ë¤È¤·¤ÆÄ󶡤µ¤ì¤Æ¤¤¤ë¥Ó¥ë¥É¥¤¥ó¤Îµ¡Ç½¤ò´Þ¤ó¤Ç¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¤³¤ì¤é¤Î¥â¥¸¥å¡¼¥ë¤ò°ì»þŪ¤Ë /boot/loader.conf ¤Îµ¡Ç½¤òÍѤ¤¤Æ¡¢ GENERIC ¤ËÆÉ¤ß¹þ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¥¢¥Ã¥×¥°¥ì¡¼¥É¥×¥í¥»¥¹¤¬½ª¤ï¤ë¤Þ¤Ç¤Ï¡¢ ½ÅÍפǤϤʤ¤¥µ¡¼¥Ó¥¹¤ò̵¸ú¤Ë¤¹¤ë¤È¤È¤â¤Ë¡¢ ɬÍפΤʤ¤¥Ç¥£¥¹¥¯¤ä¥Í¥Ã¥È¥ï¡¼¥¯¤Î¥Þ¥¦¥ó¥È¤Ê¤É¤âÈò¤±¤ë¤³¤È¤¬¿ä¾©¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¥¢¥Ã¥×¥Ç¡¼¥È¤µ¤ì¤¿¥«¡¼¥Í¥ë¤Ç¥³¥ó¥Ô¥å¡¼¥¿¤òºÆµ¯Æ°¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; shutdown -r now ¥·¥¹¥Æ¥à¤¬¥ª¥ó¥é¥¤¥ó¤ËÌá¤Ã¤¿¤é¡¢°Ê²¼¤Î¥³¥Þ¥ó¥É¤ò»È¤Ã¤Æ freebsd-update ¤òºÆ¤Ó¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥¢¥Ã¥×¥Ç¡¼¥È¥×¥í¥»¥¹¤Î¾õÂÖ¤ÏÊݸ¤µ¤ì¤Æ¤¤¤ë¤Î¤Ç¡¢ freebsd-update ¤ò¼Â¹Ô¤¹¤ë¤È¡¢ºÇ½é¤«¤é¤Ç¤Ï¤Ê¤¯¡¢ ¸Å¤¤¶¦Í­¥é¥¤¥Ö¥é¥ê¤È¥ª¥Ö¥¸¥§¥¯¥È¥Õ¥¡¥¤¥ë¤òºï½ü¤¹¤ë¥×¥í¥»¥¹¤«¤é»Ï¤Þ¤ê¤Þ¤¹¡£ &prompt.root; freebsd-update install »ÈÍѤ·¤Æ¤¤¤ë¥é¥¤¥Ö¥é¥ê¤Î¥Ð¡¼¥¸¥ç¥óÈÖ¹æ¤ÎÉÕ¤±¤é¤ìÊý¤Ë¤è¤Ã¤Æ¡¢ 3 ¤Ä¤Î¥¤¥ó¥¹¥È¡¼¥ë¥Õ¥§¡¼¥º¤¬ 2 ¤Ä¤Ë¤Ê¤ë¾ì¹ç¤â¤¢¤ê¤Þ¤¹¡£ ¥á¥¸¥ã¡¼¥Ð¡¼¥¸¥ç¥ó¥¢¥Ã¥×¥°¥ì¡¼¥É¸å¤Î ports ¤ÎºÆ¹½ÃÛ ¥á¥¸¥ã¡¼¥Ð¡¼¥¸¥ç¥ó¥¢¥Ã¥×¥°¥ì¡¼¥É¤ò¹Ô¤Ã¤¿¸å¤Ç¤Ï¡¢ ¤¹¤Ù¤Æ¤Î¥µ¡¼¥É¥Ñ¡¼¥Æ¥£À½¤Î¥½¥Õ¥È¥¦¥§¥¢¤òºÆ¹½ÃÛ¤·¡¢ ºÆ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¤³¤Îºî¶È¤¬É¬ÍפʤΤϡ¢¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥½¥Õ¥È¥¦¥§¥¢¤¬¡¢ ¥¢¥Ã¥×¥°¥ì¡¼¥É¤ÎºÝ¤Ëºï½ü¤µ¤ì¤¿¥é¥¤¥Ö¥é¥ê¤Ë°Í¸¤·¤Æ¤¤¤ë²ÄǽÀ­¤¬¤¢¤ë¤¿¤á¤Ç¤¹¡£ ports-mgmt/portupgrade ¤Ï¡¢¤³¤Î¥×¥í¥»¥¹¤ò¼«Æ°²½¤·¤Þ¤¹¡£ &prompt.root; portmaster -f ¤³¤Îºî¶È¤Î½ªÎ»¸å¡¢ºÇ¸å¤Ë¤â¤¦°ìÅÙ freebsd-update ¤ò¼Â¹Ô¤·¤Æ¡¢ ¤¹¤Ù¤Æ¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¥×¥í¥»¥¹¤Î¤ä¤ê»Ä¤·ºî¶È¤ò¹Ô¤¤¡¢ ¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î¥×¥í¥»¥¹¤ò´°Î»¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; freebsd-update install GENERIC ¥«¡¼¥Í¥ë¤ò°ì»þŪ¤ËÆÉ¤ß¹þ¤ó¤Ç¤¤¤¿¤Î¤Ç¤¢¤ì¤Ð¡¢ ¤³¤³¤Ç¡¢Ä̾ï¤ÎÊýË¡¤òÍѤ¤¤Æ¿·¤·¤¤¥«¥¹¥¿¥à¤ò¹½ÃÛ¤·¡¢¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥³¥ó¥Ô¥å¡¼¥¿¤òºÆµ¯Æ°¤·¡¢¿·¤·¤¤ &os; ¤òΩ¤Á¾å¤²¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ì¤Ç¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î¥×¥í¥»¥¹¤Ï´°Î»¤Ç¤¹¡£ ¥·¥¹¥Æ¥à¤Î¾õÂÖ¤ÎÈæ³Ó freebsd-update ¤òÍѤ¤¤Æ¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë &os; ¤Î¾õÂ֤ȡ¢ Àµ¤·¤¯Æ°ºî¤¹¤ë¤³¤È¤¬Ê¬¤«¤Ã¤Æ¤¤¤ë¾õÂ֤ȤòÈæ³Ó¤Ç¤­¤Þ¤¹¡£ ¤³¤Î¥ª¥×¥·¥ç¥ó¤Ï¡¢¥·¥¹¥Æ¥à¤Î¥æ¡¼¥Æ¥£¥ê¥Æ¥£¡¢¥é¥¤¥Ö¥é¥ê¡¢ ÀßÄê¥Õ¥¡¥¤¥ë¤òɾ²Á¤·¤Þ¤¹¡£ Èæ³Ó¤ò¹Ô¤¦¤Ë¤Ï¡¢°Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; freebsd-update IDS >> outfile.ids ¥³¥Þ¥ó¥É¥é¥¤¥ó̾¤Ï IDS ¤Ç¤¹¤¬¡¢ security/snort ¤Î¤è¤¦¤Ê¿¯Æþ¸¡ÃÎ¥·¥¹¥Æ¥à¤ÎËÜÅö¤ÎÃÖ¤­´¹¤¨¤Ë¤Ê¤ë¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ freebsd-update ¤Ï¥Ç¡¼¥¿¤ò¥Ç¥£¥¹¥¯¤ËÊݸ¤¹¤ë¤Î¤Ç¡¢ ÉÔÀµ¤ÊÊѹ¹¤¬¹Ô¤ï¤ì¤ë²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ kern.securelevel ¤È¡¢ freebsd-update ¤Î¥Ç¡¼¥¿¤ò»ÈÍѤ·¤Ê¤¤¤È¤­¤Ë¡¢ ÆÉ¤ß¼è¤ê¤Î¤ß¤Îµö²Ä°À­¤ËÀßÄꤵ¤ì¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ËÃÖ¤¯¤³¤È¤Ç¡¢ ÉÔÀµ¤ÊÊѹ¹¤Î²ÄǽÀ­¤òÄ㤯¤Ç¤­¤Þ¤¹¤¬¡¢ ¤è¤ê¤è¤¤²ò·èÊýË¡¤Ï¡¢ DVD ¤Þ¤¿¤Ï°ÂÁ´¤ËÊݸ¤µ¤ì¤Æ¤¤¤ë³°Éô USB ¥Ç¥£¥¹¥¯¤Î¤è¤¦¤Ê°ÂÁ´¤Ê¥Ç¥£¥¹¥¯¤È¥·¥¹¥Æ¥à¤òÈæ³Ó¤¹¤ë¤³¤È¤Ç¤¹¡£ ¤³¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤¹¤ë¤È¡¢¥·¥¹¥Æ¥à¤Ï¸¡ºº¤µ¤ì¡¢ ¥ê¥ê¡¼¥¹¥Õ¥¡¥¤¥ë¤Î &man.sha256.1; ¥Ï¥Ã¥·¥åÃͤȸ½ºß¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¤Î¥Ï¥Ã¥·¥åÃͤ¬¥Õ¥¡¥¤¥ë¤Î°ìÍ÷¤È¶¦¤Ë¡¢»ØÄꤷ¤¿ outfile.ids ¥Õ¥¡¥¤¥ë¤ËÁ÷¤é¤ì¤Þ¤¹¡£ ¤³¤ì¤é¤Î¹Ô¤Ï¶Ë¤á¤ÆÄ¹¤¤¤Î¤Ç¤¹¤¬¡¢½ÐÎÏ·Á¼°¤Ï´Êñ¤Ë¤¹¤°¤Ë²òÀϤǤ­¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð¡¢¤³¤ì¤é¤Î¥ê¥ê¡¼¥¹¤Ç°Û¤Ê¤Ã¤Æ¤¤¤ë¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤òÃΤꤿ¤¤¤Î¤Ç¤¢¤ì¤Ð¡¢ °Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf ¾å¤Îɽ¼¨Îã¤Ç¤Ï½ÐÎϤÏÀÚ¤ê¼Î¤Æ¤é¤ì¤Æ¤ª¤ê¡¢ ¼ÂºÝ¤Ë¤Ï¤â¤Ã¤È¿¤¯¤Î¥Õ¥¡¥¤¥ë¤¬Â¸ºß¤·¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤Ë¤Ï¡¢±¿ÍÑÃæ¤ËÊѹ¹¤µ¤ì¤ë¥Õ¥¡¥¤¥ë¤¬¤¢¤ê¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð¡¢/etc/passwd ¤Ï¥æ¡¼¥¶¤¬¥·¥¹¥Æ¥à¤ËÄɲ䵤ì¤ë¤ÈÊѹ¹¤µ¤ì¤Þ¤¹¡£ ¤Þ¤¿¡¢¥«¡¼¥Í¥ë¥â¥¸¥å¡¼¥ë¤Î¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤Ï¡¢ freebsd-update ¤Ë¤è¤ê¥¢¥Ã¥×¥Ç¡¼¥È¤µ¤ì¤ë¤¿¤á¡¢Êѹ¹¤µ¤ì¤Þ¤¹¡£ ¤³¤Î¤è¤¦¤ÊÆÃÊ̤ʥե¡¥¤¥ë¤ä¥Ç¥£¥ì¥¯¥È¥ê¤ò½ü³°¤¹¤ë¤Ë¤Ï¡¢ ¤½¤ì¤é¤ò /etc/freebsd-update.conf ¤Î IDSIgnorePaths ¥ª¥×¥·¥ç¥ó¤ËÄɲ䷤Ƥ¯¤À¤µ¤¤¡£ °ÊÁ°¤ËµÄÏÀ¤·¤¿ÊýË¡¤È¤ÏÊ̤ˡ¢ ¤³¤Î¥·¥¹¥Æ¥à¤òÆþǰ¤Ê¥¢¥Ã¥×¥°¥ì¡¼¥ÉÊýË¡¤Î°ìÉô¤È¤·¤ÆÍѤ¤¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ Tom Rhodes ´ó¹Æ: Colin Percival ¥Ù¡¼¥¹¤È¤Ê¤Ã¤¿¥Î¡¼¥È¤ÎÄó¶¡: Portsnap: Ports Collection ¥¢¥Ã¥×¥Ç¡¼¥È¥Ä¡¼¥ë ¥¢¥Ã¥×¥Ç¡¼¥È¤È¥¢¥Ã¥×¥°¥ì¡¼¥É Portsnap ¥¢¥Ã¥×¥Ç¡¼¥È¤È¥¢¥Ã¥×¥°¥ì¡¼¥É &os; ¤Î¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤Ë¤Ï¡¢ Ports Collection ¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë &man.portsnap.8; ¤¬¤¢¤ê¤Þ¤¹¡£ ¤³¤Î¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤Ï¡¢&os; ¤Î¥µ¥¤¥È¤ËÀܳ¤·¡¢¥»¥­¥å¥ê¥Æ¥£¥­¡¼¤ò¸¡¾Ú¤·¡¢ Ports Collection ¤ÎºÇ¿·ÈǤò¥À¥¦¥ó¥í¡¼¥É¤·¤Þ¤¹¡£ ¥»¥­¥å¥ê¥Æ¥£¥­¡¼¤Ï¡¢ ¥À¥¦¥ó¥í¡¼¥É¤·¤¿¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤Î¸¡¾Ú¤ËÍѤ¤¤é¤ì¤Þ¤¹¡£ ºÇ¿·¤Î Ports Collection ¥Õ¥¡¥¤¥ë¤ò¥À¥¦¥ó¥í¡¼¥É¤¹¤ë¤Ë¤Ï¡¢ °Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 9 mirrors found. Fetching snapshot tag from geodns-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Tue May 22 02:12:15 CEST 2012 to Wed May 23 16:28:31 CEST 2012. Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 3 metadata files... done. Fetching 90 patches.....10....20....30....40....50....60....70....80....90. done. Applying patches... done. Fetching 133 new ports or files... done. ¤³¤ÎÎã¤Ç¤Ï¡¢&man.portsnap.8; ¤¬¸½ºß¤Î ports ¤ËÂФ¹¤ë¥Ñ¥Ã¥Á¤ò¸«¤Ä¤±¡¢¸¡¾Ú¤·¤¿¤³¤È¤ò¼¨¤·¤Æ¤¤¤Þ¤¹¡£ ¤Þ¤¿¡¢¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤Ï°ÊÁ°¤Ë¼Â¹Ô¤·¤Æ¤¤¤ë¤³¤È¤â¼¨¤·¤Æ¤¤¤Þ¤¹¡£ ¤â¤·½é¤á¤Æ¼Â¹Ô¤·¤¿¤Î¤Ç¤¢¤ì¤Ð¡¢Ports Collection ¤Î¥À¥¦¥ó¥í¡¼¥É¤Î¤ß¤¬¹Ô¤ï¤ì¤Þ¤¹¡£ &man.portsnap.8; ¤¬ fetch ¤ËÀ®¸ù¤¹¤ë¤È¡¢ ¸¡¾Ú¤òÄ̤ä¿ Ports Collection ¤È¡¢ ¤½¤ì¤Ë³¤¯¥Ñ¥Ã¥Á¤¬¥í¡¼¥«¥ë¥·¥¹¥Æ¥à¤Ë¸ºß¤·¤Þ¤¹¡£ ¤Ï¤¸¤á¤Æ portsnap ¤ò¼Â¹Ô¤·¤¿»þ¤Ë¤Ï¡¢ extract ¤ò»È¤Ã¤Æ¡¢ ¥À¥¦¥ó¥í¡¼¥É¤·¤¿¥Õ¥¡¥¤¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; portsnap extract /usr/ports/.cvsignore /usr/ports/CHANGES /usr/ports/COPYRIGHT /usr/ports/GIDs /usr/ports/KNOBS /usr/ports/LEGAL /usr/ports/MOVED /usr/ports/Makefile /usr/ports/Mk/bsd.apache.mk /usr/ports/Mk/bsd.autotools.mk /usr/ports/Mk/bsd.cmake.mk ... ¤¹¤Ç¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë Ports Collection ¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤Ë¤Ï¡¢ portsnap update ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; portsnap update ¤³¤ì¤Ç¥¢¥Ã¥×¥Ç¡¼¥È¥×¥í¥»¥¹¤Ï´°Î»¤·¤Þ¤·¤¿¡£ ¹¹¿·¤µ¤ì¤¿ Ports Collection ¤ò»È¤Ã¤Æ¡¢ ¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤¿¤ê¡¢ ¥¢¥Ã¥×¥°¥ì¡¼¥É¤Ç¤­¤Þ¤¹¡£ fetch ¤ò»È¤¦¾ì¹ç¤Ë¤Ï¡¢ extract ¤ª¤è¤Ó update ¤òϢ³¤·¤Æ¹Ô¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ &prompt.root; portsnap fetch update ¤³¤Î¥³¥Þ¥ó¥É¤Ë¤è¤êºÇ¿·¤Î Ports Collection ¤¬¥À¥¦¥ó¥í¡¼¥É¤µ¤ì¡¢ /usr/ports °Ê²¼¤Ë¤¢¤ë¥í¡¼¥«¥ë¤Î Ports Collection ¤¬¥¢¥Ã¥×¥Ç¡¼¥È¤µ¤ì¤Þ¤¹¡£ ¥É¥­¥å¥á¥ó¥È¤Î¥¢¥Ã¥×¥Ç¡¼¥È Updating and Upgrading Documentation Updating and Upgrading ¥É¥­¥å¥á¥ó¥È¤Ï¡¢&os; ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Îɬ¿ÜÍ×ÁǤǤ¹¡£ &os; ¥É¥­¥å¥á¥ó¥È¥»¥Ã¥È¤ÎºÇ¿·¥Ð¡¼¥¸¥ç¥ó¤Ï¡¢&os; ¥¦¥§¥Ö¥µ¥¤¥È ¤«¤éÆþ¼ê¤Ç¤­¤Þ¤¹¤¬¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯Àܳ¤¬ÃÙ¤¤¡¢¤â¤·¤¯¤Ï¤Þ¤Ã¤¿¤¯Àܳ¤Ç¤­¤Ê¤¤¥æ¡¼¥¶¤â¤¤¤Þ¤¹¡£ ¥í¡¼¥«¥ë¤Î¥É¥­¥å¥á¥ó¥È¤òºÇ¿·¤Î &os; ¥É¥­¥å¥á¥ó¥È¥»¥Ã¥È¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ëÊýË¡¤¬¤¤¤¯¤Ä¤âÍѰդµ¤ì¤Æ¤¤¤Þ¤¹¡£ <application>Subversion</application> ¤òÍѤ¤¤¿¥É¥­¥å¥á¥ó¥È¤Î¥¢¥Ã¥×¥Ç¡¼¥ÈÊýË¡ &os; ¤Î¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤Ï¡¢ svn ¤òÍѤ¤¤ÆÆþ¼ê¤Ç¤­¤Þ¤¹¡£ ¤³¤ÎÀá¤Ç¤Ï°Ê²¼¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Þ¤¹¡£ ¥É¥­¥å¥á¥ó¥È¥Ä¡¼¥ë¥Á¥§¥¤¥ó¤Î¥¤¥ó¥¹¥È¡¼¥ëÊýË¡¡£ ¤³¤Î¥Ä¡¼¥ë¤Ï¡¢&os; ¤Î¥É¥­¥å¥á¥ó¥È¤ò¥½¡¼¥¹¤«¤éºÆ¹½ÃÛ¤¹¤ë¤Î¤ËɬÍפǤ¹¡£ svn ¤òÍѤ¤¤Æ¡¢ ¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ò /usr/doc °Ê²¼¤Ë¥À¥¦¥ó¥í¡¼¥É¤¹¤ëÊýË¡¡£ &os; ¥É¥­¥å¥á¥ó¥È¤ò¥½¡¼¥¹¤«¤éºÆ¹½ÃÛ¤·¡¢ /usr/share/doc °Ê²¼¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÊýË¡¡£ ¥É¥­¥å¥á¥ó¥È¤Î¥Ó¥ë¥É¥·¥¹¥Æ¥à¤Ë¤ª¤¤¤Æ¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤ë¥Ó¥ë¥É¥ª¥×¥·¥ç¥ó¤ÎÀâÌÀ¡£ ¤¿¤È¤¨¤Ð¡¢ËÝÌõ¤µ¤ì¤¿¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¤Î¤ß¤ò¹½ÃÛ¤¹¤ë¥ª¥×¥·¥ç¥ó¤ä¡¢ ¤¢¤ëÆÃÄê¤Î½ÐÎÏ¥Õ¥©¡¼¥Þ¥Ã¥È¤ò»ØÄꤹ¤ë¤è¤¦¤Ê¥ª¥×¥·¥ç¥ó¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Þ¤¹¡£ <application>svn</application> ¤ª¤è¤Ó¥É¥­¥å¥á¥ó¥È¥Ä¡¼¥ë¥Á¥§¥¤¥ó¤Î¥¤¥ó¥¹¥È¡¼¥ë &os; ¤Î¥É¥­¥å¥á¥ó¥È¤ò¥½¡¼¥¹¤«¤éºÆ¹½ÃÛ¤¹¤ë¤Ë¤Ï¡¢ ¥Ä¡¼¥ë¤Î¥³¥ì¥¯¥·¥ç¥ó¤¬É¬ÍפǤ¹¡£ ¤³¤ì¤é¤Î¥Ä¡¼¥ë¤Ï¿¤¯¤Î¥Ç¥£¥¹¥¯ÍÆÎ̤ò»ÈÍѤ¹¤ë¤¿¤á¡¢ &os; ¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤Î°ìÉô¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ¤Þ¤¿¡¢¤¹¤Ù¤Æ¤Î &os; ¥æ¡¼¥¶¤Ë¤È¤Ã¤ÆÍ­ÍѤȤ¤¤¦¤ï¤±¤Ç¤Ï¤Ê¤¯¡¢&os; ¤Î¤¿¤á¤Ë¿·¤·¤¤¥É¥­¥å¥á¥ó¥È¤ò³èȯ¤Ë¼¹É®¤·¤Æ¤¤¤ëÊý¤ä¡¢ ÉÑÈˤ˥ɥ­¥å¥á¥ó¥È¤ò¥½¡¼¥¹¤«¤é¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ëÊý¤Ë¸þ¤±¤¿¤â¤Î¤Ç¤¹¡£ svn ¤ò´Þ¤áɬÍפʥġ¼¥ë¤Ï¡¢ textproc/docproj ¥á¥¿ port ¤«¤é¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤­¤Þ¤¹¡£¤³¤Î port ¤Ï¡¢ &os; ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥×¥í¥¸¥§¥¯¥È¤Ë¤è¤ê³«È¯¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¥É¥­¥å¥á¥ó¥È¤Î &postscript; ¤ä PDF ÈǤ¬É¬Íפʤ±¤ì¤Ð¡¢¤«¤ï¤ê¤Ë textproc/docproj-nojadetex ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤³¤È¤â¹Í¤¨¤Æ¤è¤¤¤Ç¤·¤ç¤¦¡£ ¤³¤Î¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¤Î¥Ä¡¼¥ë¥Á¥§¥¤¥ó¤Ï¡¢ teTeX ¤È¸Æ¤Ð¤ì¤ëÁÈÈÇ¥¨¥ó¥¸¥ó¤ò½ü¤¤¤¿¤¹¤Ù¤Æ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Þ¤¹¡£ teTeX ¤ÏÂ礭¤Ê¥Ä¡¼¥ë¤Î¥³¥ì¥¯¥·¥ç¥ó¤Ç¤¹¡£ ¤½¤Î¤¿¤á¡¢¤â¤· PDF ½ÐÎϤòËÜÅö¤ËɬÍפȤ·¤Ê¤±¤ì¤Ð¡¢ ¤³¤Î¥Ä¡¼¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Ê¤¤¤³¤È¤Ï¤È¤Æ¤â¸­ÌÀ¤Ç¤¹¡£ ¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë °Ê²¼¤ÎÎã¤Ç¤Ï¡¢svn ¤ò»È¤Ã¤Æ western US ¥ß¥é¡¼¤«¤é HTTPS ¥×¥í¥È¥³¥ë¤òÍѤ¤¤Æ¡¢ ¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤Þ¤¹¡£ &prompt.root; svn checkout https://svn0.us-west.FreeBSD.org/doc/head /usr/doc ÍøÍѲÄǽ¤Ê Subversion ¥ß¥é¡¼¥µ¥¤¥È ¤ÎÃæ¤«¤é¤â¤Ã¤È¤â¶á¤¤¥ß¥é¡¼¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ºÇ½é¤Ë¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ò¥À¥¦¥ó¥í¡¼¥É¤¹¤ë¤Ë¤Ï¾¯¤·»þ´Ö¤¬¤«¤«¤ê¤Þ¤¹¡£ ¥À¥¦¥ó¥í¡¼¥É¤¬½ª¤ï¤ë¤Þ¤Ç¤ªÂÔ¤Á¤¯¤À¤µ¤¤¡£ ¥À¥¦¥ó¥í¡¼¥É¤·¤¿¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤Ë¤Ï¡¢ °Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; svn update /usr/doc ¥½¡¼¥¹¤òÆþ¼ê¤·¤¿¤é¡¢ /usr/doc/Makefile ¤ò»È¤¤¡¢ °Ê²¼¤Î¤è¤¦¤Ë¥É¥­¥å¥á¥ó¥È¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤³¤È¤â¤Ç¤­¤Þ¤¹¡£ &prompt.root; cd /usr/doc &prompt.root; make update ¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ÎÄ´À°²Äǽ¤Ê¥ª¥×¥·¥ç¥ó &os; ¤Î¥É¥­¥å¥á¥ó¥È¥»¥Ã¥È¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤È¥Ó¥ë¥É¥·¥¹¥Æ¥à¤Ï¡¢ ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¤Î°ìÉô¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤ò´Êñ¤Ë¤¹¤ë¥ª¥×¥·¥ç¥ó¤ä¡¢ ÆÃÄê¤ÎËÝÌõ¤Î¥Ó¥ë¥É¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥ª¥×¥·¥ç¥ó¤Ï¡¢¥·¥¹¥Æ¥àÁ´È̤Υª¥×¥·¥ç¥ó¤Ç¤¢¤ë /etc/make.conf ¤ä¡¢&man.make.1; ¤ËÍ¿¤¨¤ë¥³¥Þ¥ó¥É¥é¥¤¥ó¥ª¥×¥·¥ç¥ó¤ÇÀßÄê¤Ç¤­¤Þ¤¹¡£ ¥ª¥×¥·¥ç¥ó¤Ë¤Ï°Ê²¼¤Î¤è¤¦¤Ê¤â¤Î¤¬¤¢¤ê¤Þ¤¹¡£ DOC_LANG ¥Ó¥ë¥É¤ª¤è¤Ó¥¤¥ó¥¹¥È¡¼¥ë¤Î¸À¸ì¤ª¤è¤Ó¥¨¥ó¥³¡¼¥Ç¥£¥ó¥°¤Î°ìÍ÷¡£ ¤¿¤È¤¨¤Ð¡¢±Ñ¸ì¤Î¥É¥­¥å¥á¥ó¥È¤ò»ØÄꤹ¤ë¤Ë¤Ï en_US.ISO8859-1 ¤òÀßÄꤷ¤Þ¤¹¡£ FORMATS ¥Ó¥ë¥É¤ò¹Ô¤¦¥Õ¥©¡¼¥Þ¥Ã¥È¡¢¤Þ¤¿¤Ï½ÐÎÏ¥Õ¥©¡¼¥Þ¥Ã¥È¤Î°ìÍ÷¡£ ¸½ºß¤Ï html, html-split, txt, ps, pdf, ¤½¤·¤Æ rtf ¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£ DOCDIR ¥É¥­¥å¥á¥ó¥È¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¾ì½ê¡£¥Ç¥Õ¥©¥ë¥È¤Ï /usr/share/doc ¤Ç¤¹¡£ &os; ¤Î¥·¥¹¥Æ¥àÁ´È̤Υª¥×¥·¥ç¥ó¤Ë´ØÏ¢¤¹¤ë¤â¤Ã¤È¿¤¯¤Î make ÊÑ¿ô¤Ë¤Ä¤¤¤Æ¤Ï¡¢ &man.make.conf.5; ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ &os; ¥É¥­¥å¥á¥ó¥È¤Î¥Ó¥ë¥É¥·¥¹¥Æ¥à¤ÇÂбþ¤·¤Æ¤¤¤ë¤µ¤é¤Ê¤ë make ¤ÎÊÑ¿ô¤Ë´Ø¤·¤Æ¤Ï¡¢ ¿·¤·¤¤¹×¸¥¼Ô¤Î¤¿¤á¤Î &os; ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥×¥í¥¸¥§¥¯¥ÈÆþÌç ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥½¡¼¥¹¤«¤é &os; ¥É¥­¥å¥á¥ó¥È¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë ¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ÎºÇ¿·¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È¤ò /usr/doc ¤Ë¥À¥¦¥ó¥í¡¼¥É¤·¤¿¤é¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥É¥­¥å¥á¥ó¥È¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë½àÈ÷¤¬¤¹¤Ù¤ÆÀ°¤¤¤Þ¤·¤¿¡£ DOC_LANG ¤ÇÄêµÁ¤µ¤ì¤Æ¤¤¤ë¤¹¤Ù¤Æ¤Î¸À¸ì¤ò´°Á´¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤Ë¤Ï¡¢ °Ê²¼¤Î¤è¤¦¤ËÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/doc &prompt.root; make install clean ¤â¤·¡¢¤¢¤ëÆÃÄê¤Î¸À¸ì¤Î¤ß¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤·¤¿¤¤¤Î¤Ç¤¢¤ì¤Ð¡¢ /usr/doc ¥µ¥Ö¥Ç¥£¥ì¥¯¥È¥ê¤Ç°Ê²¼¤Î¤è¤¦¤Ë &man.make.1; ¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean FORMATS ¤òÀßÄꤷ¤Æ¡¢ °Ê²¼¤Î¤è¤¦¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë½ÐÎÏ·Á¼°¤ò»ØÄê¤Ç¤­¤Þ¤¹¡£ &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean ¥É¥­¥å¥á¥ó¥È¤òÊÔ½¸¤·¤¿¤ê¡¢ÄûÀµ¤·¤¿¤â¤Î¤òÄó½Ð¤¹¤ëÊýË¡¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¿·¤·¤¤¹×¸¥¼Ô¤Î¤¿¤á¤Î &os; ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥×¥í¥¸¥§¥¯¥ÈÆþÌç ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ Marc Fonvieille ¥Ù¡¼¥¹¤È¤Ê¤Ã¤¿ºî¶È: ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó ports Updating and Upgrading documentation package Updating and Upgrading ¤³¤ì¤Þ¤Ç¤Î¥»¥¯¥·¥ç¥ó¤Ç¤Ï¡¢¥½¡¼¥¹¥³¡¼¥É¤òÍѤ¤¤¿ &os; ¥É¥­¥å¥á¥ó¥È¤Î¥¢¥Ã¥×¥Ç¡¼¥ÈÊýË¡¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Æ¤­¤Þ¤·¤¿¡£ ¤¹¤Ù¤Æ¤Î &os; ¥·¥¹¥Æ¥à¤Ç¡¢ ¥½¡¼¥¹¤«¤é¥É¥­¥å¥á¥ó¥È¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤³¤È¤ÏÆñ¤·¤¤¤«¤âÃΤì¤Þ¤»¤ó¤·¡¢ ¤Ç¤­¤¿¤È¤·¤Æ¤â¸½¼ÂŪ¤Ç¤Ï¤Ê¤¤¤³¤È¤â¤¢¤ê¤Þ¤¹¡£ ¥É¥­¥å¥á¥ó¥È¤ò¥½¡¼¥¹¤«¤é¹½ÃÛ¤¹¤ë¤Ë¤Ï¡¢ ¤«¤Ê¤êÂ礭¤Ê¥Ä¡¼¥ë¤È¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤«¤é¹½À®¤µ¤ì¤ë ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥Ä¡¼¥ë¥Á¥§¥¤¥ó ¤¬É¬Íפʤ¿¤á¤Ç¤¹¡£ ¤Þ¤¿¡¢svn ¥ê¥Ý¥¸¥È¥ê¤«¤é¥½¡¼¥¹¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¡¢ ¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¤¿¥½¡¼¥¹¤«¤é¥É¥­¥å¥á¥ó¥È¤ò¼êư¤Ç¹½ÃÛ¤¹¤ëÊýË¡¤Ë¤Ä¤¤¤Æ¡¢ ¤½¤ì¤Ê¤ê¤Ë½ÏÃΤ·¤Æ¤¤¤ëɬÍפ⤢¤ê¤Þ¤¹¡£ ¤³¤ÎÀá¤Ç¤Ï¡¢¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë &os; ¤Î¥É¥­¥å¥á¥ó¥È¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤â¤¦°ì¤Ä¤ÎÊýË¡¤Ç¤¢¤ë¡¢ Ports Collection ¤òÍѤ¤¤¿ÊýË¡¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¡¢ °Ê²¼¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Þ¤¹¡£ ¹½ÃۺѤΥɥ­¥å¥á¥ó¥È¤Î¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤Æ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÊýË¡¡£ ¥í¡¼¥«¥ë¤Ç¤Î¹½ÃÛºî¶È¤ä¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥Ä¡¼¥ë¥Á¥§¥¤¥ó¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£ ¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ò¥À¥¦¥ó¥í¡¼¥É¤·¡¢ports ¥Õ¥ì¡¼¥à¥ï¡¼¥¯¤ò»È¤Ã¤Æ¹½ÃÛ¤¹¤ëÊýË¡¤Ç¤¹¡£ ¥Á¥§¥Ã¥¯¥¢¥¦¥È¤ª¤è¤Ó¹½ÃÛºî¶È¤¬´Êñ¤Ë¤Ê¤ê¤Þ¤¹¡£ &os; ¤Î¥É¥­¥å¥á¥ó¥È¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤³¤ì¤é¤ÎÊýË¡¤Ï¡¢ &a.doceng; ¤¬Ëè·î¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Æ¤¤¤ë ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó ports ¤Ë¤è¤ê¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤³¤ì¤é¤Î ports ¤Ï¡¢&os; Ports Collection ¤Î docs ¥«¥Æ¥´¥ê¤Ë¤Þ¤È¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£ ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó ports ¤Î¹½Ãۤȥ¤¥ó¥¹¥È¡¼¥ë ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó ports ¤Ç¤Ï¡¢ ports ¤Î¹½Ãۥե졼¥à¥ï¡¼¥¯¤¬ÍѤ¤¤é¤ì¤ë¤Î¤Ç¡¢ ¥É¥­¥å¥á¥ó¥È¤ò´Êñ¤Ë¹½ÃۤǤ­¤Þ¤¹¡£ ¤³¤Î ports ¤Ï¡¢¥É¥­¥å¥á¥ó¥È¤Î¥½¡¼¥¹¤ò¼«Æ°Åª¤Ë¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¡¢ ´Ä¶­ÊÑ¿ô¤ä¥³¥Þ¥ó¥É¥é¥¤¥ó¥ª¥×¥·¥ç¥ó¤òŬÀÚ¤ËÀßÄꤷ¤Æ &man.make.1; ¤ò¼Â¹Ô¤·¤Þ¤¹¡£ ¤Þ¤¿¡¢Â¾¤Î &os; port, package ¤Î¥¤¥ó¥¹¥È¡¼¥ë¤ÈƱÍͤ˴Êñ¤ÊÊýË¡¤Ç¡¢ ¥É¥­¥å¥á¥ó¥È¤Î¥¤¥ó¥¹¥È¡¼¥ë¤ä¥¢¥ó¥¤¥ó¥¹¥È¡¼¥ë¤ò¹Ô¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ Äɲäε¡Ç½¤È¤·¤Æ¡¢¤³¤Î ports ¤Ï ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥Ä¡¼¥ë¥Á¥§¥¤¥ó ports ¤Ø¤Î°Í¸¤òÍý²ò¤·¤Æ¤¤¤ë¤Î¤Ç¡¢ ¹½ÃÛ»þ¤Ë¤Ï¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥Ä¡¼¥ë¥Á¥§¥¤¥ó¤â¼«Æ°Åª¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó ports ¤Î¹½À®¤Ï°Ê²¼¤ÎÄ̤ê¤Ç¤¹¡£ ¥Þ¥¹¥¿ port, misc/freebsd-doc-en¡£ ¤¹¤Ù¤Æ¤Î±Ñ¸ìʸ½ñ¤Î ports ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Þ¤¹¡£ ¤¹¤Ù¤Æ¤Î¥É¥­¥å¥á¥ó¥È¤Î port, misc/freebsd-doc-all¡£ ¤³¤ì¤Ï¡¢¤¹¤Ù¤Æ¤ÎÍøÍѲÄǽ¤Ê¸À¸ì¤Î¤¹¤Ù¤Æ¤Î¥É¥­¥å¥á¥ó¥È¤ò¹½ÃÛ¤·¤Þ¤¹¡£ ³Æ¸À¸ì¤Î¤¿¤á¤Ë ¥¹¥ì¡¼¥Ö port ¤¬ÍѰդµ¤ì¤Æ¤¤¤Þ¤¹¡£¤¿¤È¤¨¤Ð¡¢misc/freebsd-doc-hu ¤Ï¥Ï¥ó¥¬¥ê¡¼¸ì¤Î¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó port ¤Ç¤¹¡£ ¤¿¤È¤¨¤Ð¡¢ ¤ÈƱ¤¸·Á¼°¤Ç¤¢¤ë¡¢ ±Ñ¸ìÈǤÎʬ³ä¤µ¤ì¤¿ HTML ·Á¼°¤ò¹½ÃÛ¤·¡¢ /usr/local/share/doc/freebsd ¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤Ë¤Ï°Ê²¼¤Î port ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean ¶¦Ä̤Υª¥×¥·¥ç¥ó ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó ports ¤Ë¤Ï¤¿¤¯¤µ¤ó¤Î¥ª¥×¥·¥ç¥ó¤¬ÍѰդµ¤ì¤Æ¤ª¤ê¡¢ °Ê²¼¤Î¤è¤¦¤Ë ports ¤Î¿¶¤ëÉñ¤¤¤ò¥Ç¥Õ¥©¥ë¥È¤ÎÀßÄ꤫¤éÊѹ¹¤Ç¤­¤Þ¤¹¡£ WITH_HTML HTML ·Á¼°¤ò¹½ÃÛ¤·¤Þ¤¹¡£ ³Æ¥É¥­¥å¥á¥ó¥È¤ËÂФ·¡¢Ã±°ìÈǤΠHTML ¥Õ¥¡¥¤¥ë¤¬¹½ÃÛ¤µ¤ì¤Þ¤¹¡£ À°·Á¤µ¤ì¤¿¥É¥­¥å¥á¥ó¥È¤Ï¡¢ article.html ¤ä book.html ¤È¤¤¤Ã¤¿Ì¾Á°¤Ç¡¢ ɬÍפ˱þ¤¸¤Æ²èÁü¤È¤È¤â¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ WITH_PDF &adobe; Portable Document Format (PDF) ¤ò¹½ÃÛ¤·¤Þ¤¹¡£ À°·Á¤µ¤ì¤¿¥É¥­¥å¥á¥ó¥È¤Ï¡¢ article.pdf ¤ä book.pdf ¤È¤¤¤Ã¤¿Ì¾Á°¤Ç¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ DOCBASE ¥É¥­¥å¥á¥ó¥È¤Î¥¤¥ó¥¹¥È¡¼¥ëÀè¤òÀßÄꤷ¤Þ¤¹¡£ ¥Ç¥Õ¥©¥ë¥È¤Î¥¤¥ó¥¹¥È¡¼¥ëÀè¤Ï /usr/local/share/doc/freebsd ¤Ç¤¹¡£ ¥Ç¥Õ¥©¥ë¥È¤Î¥¿¡¼¥²¥Ã¥È¥Ç¥£¥ì¥¯¥È¥ê¤Ï¡¢ svn ¤òÍѤ¤¤ëÊýË¡¤È¤Ï°Û¤Ê¤ê¤Þ¤¹¡£ ports ¤ÏÄ̾ï /usr/local ¥Ç¥£¥ì¥¯¥È¥ê°Ê²¼¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤ë¤¿¤á¤Ç¤¹¡£ PREFIX ÊÑ¿ô¤ò»È¤¦¤³¤È¤Ç¡¢ ¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê°Ê³°¤Ë¤â¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤­¤Þ¤¹¡£ °Ê²¼¤Ï¡¢¾åµ­¤ÎÊÑ¿ô¤òÍѤ¤¤Æ¥Ï¥ó¥¬¥ê¡¼¸ì¤Î¥É¥­¥å¥á¥ó¥È¤ò PDF ·Á¼°¤Ç¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÊýË¡¤Ç¤¹¡£ &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó package ¤ÎÍøÍÑ Á°Àá¤ÇÀâÌÀ¤·¤¿¡¢ ¥½¡¼¥¹¤«¤é¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó port ¤ò¹½ÃÛ¤¹¤ëÊýË¡¤Ç¤Ï¡¢ ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥Ä¡¼¥ë¥Á¥§¥¤¥ó¤ò¥í¡¼¥«¥ë¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëɬÍפ¬¤¢¤ê¡¢ ¤Þ¤¿¡¢ports ¤Î¹½ÃۤΤ¿¤á¤Ë¥Ç¥£¥¹¥¯ÍÆÎ̤òɬÍפȤ·¤Þ¤¹¡£ ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥Ä¡¼¥ë¥Á¥§¥¤¥ó¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¥ê¥½¡¼¥¹¤¬¤Ê¤¤¾ì¹ç¤ä¡¢ ¥½¡¼¥¹¤«¤é¹½ÃÛ¤¹¤ë¾ì¹ç¤Ë¤Ï¿¤¯¤Î¥Ç¥£¥¹¥¯ÍÆÎ̤òɬÍפȤ¹¤ë¤¿¤á¡¢ ¹½ÃۺѤߤΥɥ­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó ports ¤Î¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È¤¬ÍѰդµ¤ì¤Æ¤¤¤Þ¤¹¡£ &a.doceng; ¤Ï¡¢Ëè·î &os; ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó package ¤Î¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Æ¤¤¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥Ð¥¤¥Ê¥ê package ¤Ï¡¢¥·¥¹¥Æ¥à¤ËÍѰդµ¤ì¤Æ¤¤¤ë &man.pkg.add.1;, &man.pkg.delete.1; ¤Ê¤É¤Î package ´ÉÍý¥Ä¡¼¥ë¤òÍѤ¤¤Æ°·¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¥Ð¥¤¥Ê¥ê package ¤ò»È¤¦¤È¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¸À¸ì¤ËÍѰդµ¤ì¤Æ¤¤¤ë ¤¹¤Ù¤Æ ¤Î·Á¼°¤Î &os; ¥É¥­¥å¥á¥ó¥È¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð¡¢°Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤¹¤ë¤È¡¢ ¥Ï¥ó¥¬¥ê¡¼¸ì¤Î¥É¥­¥å¥á¥ó¥È¤ÎºÇ¿· package ¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ &prompt.root; pkg_add -r hu-freebsd-doc ¥É¥­¥å¥á¥ó¥È¤Î package ¤Ï¡¢Âбþ¤¹¤ë port ̾¤È¤Ï°Û¤Ê¤ê¡¢ lang-freebsd-doc ¤Î·Á¼°¤Ç̾Á°¤¬¤Ä¤±¤é¤ì¤Æ¤¤¤Þ¤¹¡£ ¤³¤³¤Ç¡¢lang ¤Ï¸À¸ì¥³¡¼¥É¤Îû½Ì·Á¤Ç¤¹¡£ ¥Ï¥ó¥¬¥ê¡¼¸ì¤Î¾ì¹ç¤Ï hu¡¢´ÊÂλú¤Î¾ì¹ç¤Ë¤Ï zh_cn ¤Ç¤¹¡£ ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó ports ¤Î¥¢¥Ã¥×¥Ç¡¼¥È ¾¤Î port ¤ÈƱÍͤˡ¢¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó port ¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤Ç¤­¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð¡¢°Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤¹¤ë¤È¡¢ports-mgmt/portupgrade ¤«¤é¡¢package ¤À¤±¤ò»È¤Ã¤Æ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥Ï¥ó¥¬¥ê¡¼¸ì¤Î¥É¥­¥å¥á¥ó¥È¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Þ¤¹¡£ &prompt.root; portmaster -PP hu-freebsd-doc ³«È¯¥Ö¥é¥ó¥Á¤òÄɤ¤¤«¤±¤ë -CURRENT -STABLE &os; ¤Ë¤ÏÆó¤Ä¤Î³«È¯¥Ö¥é¥ó¥Á¤¬¤¢¤ê¤Þ¤¹¡£ ¤½¤ì¤Ï &os.current; ¤È &os.stable; ¤Ç¤¹¡£ ¤³¤Î¾Ï¤Ç¤Ï¤½¤ì¤¾¤ì¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¡¢ ¤É¤Î¤è¤¦¤Ë¤·¤Æ¥·¥¹¥Æ¥à¤ÎÂбþ¤¹¤ë¥Ä¥ê¡¼¤òºÇ¿·¤Î¾õÂÖ¤ËÊݤĤ«¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Þ¤¹¡£ ¤Þ¤º¤Ï &os.current;¡¢¼¡¤Ë &os.stable; ¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Þ¤¹¡£ Ìõ: &a.hanai;¡¢1996 ǯ 11 ·î 6 Æü ºÇ¿·¤Î &os; ¤òÄɤ¤¤«¤±¤ë &os.current; ¤È¤Ï &os; ¤Î³«È¯¤Î ºÇÁ°Àþ ¤Ç¤¹¡£ &os.current; ¤Î¥æ¡¼¥¶¤Ï¹â¤¤µ»½ÑÎϤò»ý¤Ä¤³¤È¤¬Í׵ᤵ¤ì¡¢ ¼«Ê¬¤Î¥·¥¹¥Æ¥à¤¬Êú¤¨¤ëº¤Æñ¤ÊÌäÂê¤ò¼«ÎϤDzò·è¤Ç¤­¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ¤â¤· &os; ¤ò»È¤¤»Ï¤á¤¿¤Ð¤«¤ê¤Ê¤é¡¢ ¤³¤ì¤ò±¿ÍѤ¹¤ë¤³¤È¤Ë¤Ä¤¤¤Æ½½Ê¬¸¡Æ¤¤ò½Å¤Í¤¿Êý¤¬Îɤ¤¤Ç¤·¤ç¤¦¡£ &os.current; ¤Ã¤Æ¤Ê¤Ë? &os.current; ¤Ï &os; ¤ÎºÇ¿·¤Î¥½¡¼¥¹¥³¡¼¥É¤Ç¤¹¡£ Ãæ¤Ë¤Ï¸½ºß³«È¯ÅÓ¾å¤Î¥½¥Õ¥È¥¦¥§¥¢¡¢ ¼Â¸³Åª¤ÊÊѹ¹¡¢¤¢¤ë¤¤¤Ï²áÅÏŪ¤Êµ¡Ç½¤Ê¤É¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤Þ¤¿¡¢¤³¤ÎÃæ¤ËÆþ¤Ã¤Æ¤¤¤ëµ¡Ç½¤¬¤¹¤Ù¤Æ¡¢ ¼¡¤Î¸ø¼°¥ê¥ê¡¼¥¹¤ËÆþ¤ë¤È¤Ï¸Â¤ê¤Þ¤»¤ó¡£&os.current; ¤ò¥½¡¼¥¹¤«¤é¤Û¤ÜËèÆü¥³¥ó¥Ñ¥¤¥ë¤·¤Æ¤¤¤ë¿Í¤Ï¤¿¤¯¤µ¤ó¤¤¤Þ¤¹¤¬¡¢ »þ´ü¤Ë¤è¤Ã¤Æ¤Ï¥³¥ó¥Ñ¥¤¥ë¤µ¤¨¤Ç¤­¤Ê¤¤¾õÂ֤ˤʤäƤ¤¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹¡£ ¤³¤ì¤é¤ÎÌäÂê¤Ï²Äǽ¤Ê¸Â¤ê¿×®¤Ë²ò·è¤µ¤ì¤Þ¤¹¤¬¡¢ &os.current; ¤¬ÉÔ¹¬¤ò¤â¤¿¤é¤¹¤«¡¢ ¤½¤ì¤È¤âÈó¾ï¤ËÁÇÀ²¤é¤·¤¤µ¡Ç½¤ò¤â¤¿¤é¤¹¤«¤Ï¡¢ ¤Þ¤µ¤Ë¥½¡¼¥¹¥³¡¼¥É¤òƱ´ü¤·¤¿½Ö´Ö¤Ë¤è¤ë¤Î¤Ç¤¹! 郎 &os.current; ¤òɬÍפȤ·¤Æ¤ë¤Î? &os.current; ¤Ï¡¢ ¼¡¤Î 3 ¤Ä¤Î½ÅÍפʥ°¥ë¡¼¥×¤òÂоݤȤ·¤Æ¤¤¤Þ¤¹¡£ ¥½¡¼¥¹¥Ä¥ê¡¼¤Î¤¢¤ëÉôʬ¤Ë´Ø¤·¤Æ³èȯ¤Ëºî¶È¤·¤Æ¤¤¤ë &os; ¥³¥ß¥å¥Ë¥Æ¥£¤Î¥á¥ó¥Ð¡£ Èà¤é¤Ë¤È¤Ã¤Æ¤Ï ºÇ¿·¤Î¤â¤Î ¤Ë¤·¤Æ¤ª¤¯¤Î¤¬ ÀäÂФËɬÍפʤ³¤È¤Ê¤Î¤Ç¤¹¡£ ³èȯ¤Ë¥Æ¥¹¥È¤·¤Æ¤¤¤ë &os; ¥³¥ß¥å¥Ë¥Æ¥£¤Î¥á¥ó¥Ð¡£ Èà¤é¤Ï¡¢&os.current; ¤¬ ·òÁ´¤Ç¤¢¤ë ¤³¤È¤ò²Äǽ¤Ê¸Â¤êÊݾڤ¹¤ë¤¿¤á¤Ë¡¢ ¼ï¡¹¤ÎÌäÂê¤ò²ò·è¤¹¤ë¤Î¤Ë»þ´Ö¤òÀˤ·¤Þ¤Ê¤¤¿Í¡¹¤Ç¤¹¡£ ¤³¤ì¤é¤Î¥Æ¥¹¥¿¡¼¤Ï¡¢¤µ¤Þ¤¶¤Þ¤ÊÊѹ¹¤Ë´Ø¤¹¤ëÄ󰯤ä &os; ¤ÎÂç¤Þ¤«¤ÊÊý¸þÉÕ¤±¤ò¹Ô¤Ê¤¤¤¿¤¤¤È»×¤Ã¤Æ¤¤¤ë ¿Í¡¹¤Ç¤â¤¢¤ê¡¢¤½¤ì¤ò¼ÂÁõ¤¹¤ë¤¿¤á¤Î¥Ñ¥Ã¥Á¤òÄ󼨤·¤Þ¤¹¡£ ñ¤Ë¡¢¤µ¤Þ¤¶¤Þ¤Ê»ö¤ËÌܤò¸þ¤±¡¢ »²¹Í¤Î¤¿¤á¤ËºÇ¿·¤Î¥½¡¼¥¹¤ò»È¤¤¤¿¤¤¤È»×¤Ã¤Æ¤¤¤ë¿Í¡¹¡£ ¤³¤ì¤é¤Î¿Í¡¹¤Ï¤Þ¤¿¡¢ »þ¡¹¥³¥á¥ó¥È¤ä¥³¡¼¥É¤ò´ó¹Æ¤·¤Æ¤¯¤ì¤Þ¤¹¡£ &os.current; ¤Ë´üÂÔ¤·¤Æ¤Ï<emphasis>¤¤¤±¤Ê¤¤</emphasis>¤³¤È¤Ï? ¼¡¤Î¥ê¥ê¡¼¥¹¤ÎÁ°¤Ë¡¢ºÇ¤âÁ᤯¿·¤·¤¤µ¡Ç½¤òÆþ¼ê¤¹¤ë¤³¤È¡£ ¥ê¥ê¡¼¥¹Á°¤Îµ¡Ç½¤Ï½½Ê¬¤Ë¥Æ¥¹¥È¤µ¤ì¤Æ¤¤¤Ê¤¤¤¿¤á¡¢ ¥Ð¥°¤ò´Þ¤ó¤Ç¤¤¤¯²ÄǽÀ­¤¬Â礤¤Ë¤¢¤ê¤Þ¤¹¡£ ¥Ð¥°¤ò½¤Àµ¤¹¤ë¤¿¤á¤ÎÁÇÁᤤÊýË¡¡£ ¤¤¤«¤Ê¤ë¥³¥ß¥Ã¥È¤Ï¡¢ ¸µ¤«¤é¤¢¤ë¥Ð¥°¤ò½¤Àµ¤¹¤ë¤Î¤ÈƱ¤¸¤¯¡¢ ¿·¤·¤¤¥Ð¥°¤òÀ¸¤ß½Ð¤¹¤ª¤½¤ì¤¬¤¢¤ê¤Þ¤¹¡£ ¸ø¼°¤Î¥µ¥Ý¡¼¥È ¤Ï¤¢¤ê¤Þ¤»¤ó¡£ &os.current; ¤ò»È¤¦ &a.current.name; ¤È &a.svn-src-head.name;-CURRENT»ÈÍÑ ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È ¤Ë²Ã¤ï¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤µ¤Þ¤¶¤Þ¤Ê¿Í¤¬¥·¥¹¥Æ¥à¤Î¸½ºß¤Î¾õÂ֤ˤĤ¤¤Æ½Ò¤Ù¤Æ¤¤¤ë¥³¥á¥ó¥È¤ò¸«¤¿¤ê¡¢ ¥·¥¹¥Æ¥à¤òÀµ¾ï¤ËÊݤĤ¿¤á¤Î½ÅÍפʾðÊó¤ò¸«Æ¨¤µ¤Ê¤¤¤¿¤á¤Ë¡¢ ɬ¿Ü¤Î ¤³¤È¤Ç¤¹¡£ &a.svn-src-head.name; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ç¤Ï¡¢ ¤½¤ì¤¾¤ì¤ÎÊѹ¹¤Ë¤Ä¤¤¤Æ¤Î commit ¥í¥°¤¬µ­Ï¿¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤Þ¤¿¡¢¤½¤ì¤Ë´Ø¤·¤Æµ¯¤³¤êÆÀ¤ëÉûºîÍѤξðÊó¤òÆÀ¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¤Î¤Ç¡¢ »²²Ã¤¹¤ë²ÁÃͤΤ¢¤ë¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ç¤¹¡£ ¤³¤ì¤é¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ËÆþ¤ë¤Ë¤Ï¡¢ &a.mailman.lists.link; ¤ò¤¿¤É¤Ã¤Æ»²²Ã¤·¤¿¤¤¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ò¥¯¥ê¥Ã¥¯¤·¡¢ ¼ê½ç¤ÎÀâÌÀ¤Ë¤·¤¿¤¬¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¥½¡¼¥¹¥Ä¥ê¡¼Á´ÂΤÎÊѹ¹ÅÀ¤òÄɤ¤¤«¤±¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ &a.svn-src-all.name; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ò¹ØÆÉ¤·¤Æ¤¯¤À¤µ¤¤¡£ &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é¥½¡¼¥¹¤ÎÆþ¼ê¤¹¤ë¤Ë¤Ï¡¢°Ê²¼¤Î¤è¤¦¤Ê¤¤¤¯¤Ä¤«¤ÎÊýË¡¤¬¤¢¤ê¤Þ¤¹¡£ - svnSubversion ¤ò»È¤Ã¤Æ¡¢ + svn + Subversion + + + -CURRENT + Subversion + ¤ò»È¤Ã¤¿Æ±´ü + + ¤ò»È¤Ã¤Æ¡¢ ´õ˾¤¹¤ë³«È¯¥Ö¥é¥ó¥Á¡¢ ¤â¤·¤¯¤Ï¥ê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ÎÊýË¡¤Ï¡¢³«È¯Ãæ¤Î &os; ¥ê¥Ý¥¸¥È¥ê¤Ø¤Î¥¢¥¯¥»¥¹¤òÄ󶡤·¤Æ¤ª¤ê¡¢ ¿ä¾©¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ Subversion ¥ß¥é¡¼¥µ¥¤¥È ¤Î¤Ò¤È¤Ä¤Î head ¥Ö¥é¥ó¥Á¤«¤é - -CURRENT-CURRENTSubversion ¤ò»È¤Ã¤¿Æ±´ü ¥³¡¼¥É¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ + -CURRENT ¥³¡¼¥É¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥ê¥Ý¥¸¥È¥ê¥µ¥¤¥º¤Î´ÑÅÀ¤«¤é¡¢ ´õ˾¤¹¤ë¥µ¥Ö¥Ä¥ê¡¼¤Î¤ß¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤¹¤ë¤³¤È¤¬¿ä¾©¤µ¤ì¤Þ¤¹¡£ - CTM-CURRENTCTM ¤ò»È¤Ã¤¿Æ±´ü¤òÍѤ¤¤ë¡£ + CTM + -CURRENT + CTM ¤ò»È¤Ã¤¿Æ±´ü + ¤òÍѤ¤¤ë¡£ ÀܳÎÁ¤¬¹â³Û¤À¤Ã¤¿¤ê¡¢email ¤Ç¤Î¥¢¥¯¥»¥¹¤·¤«¤Ç¤­¤Ê¤¤¤è¤¦¤Ê¡¢ ¤¢¤Þ¤êÎɼÁ¤Ç¤Ê¤¤ TCP/IP Àܳ¤Î¾ì¹ç¤Ë¤Ï¡¢CTM - ¤òÍøÍѤ¹¤ë¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£¤¿¤À¤·¡¢Subversion + ¤òÍøÍѤ¹¤ë¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£¤¿¤À¤·¡¢ + Subversion ¤Û¤É¤Ë¤Ï¿®Íê¤Ï¤Ç¤­¤Þ¤»¤ó¡£ ¤½¤Î¤¿¤á¡¢¥¤¥ó¥¿¡¼¥Í¥Ã¥È¤ËÀܳ¤·¤Æ¤¤¤ë¥·¥¹¥Æ¥à¤Ç¤¢¤ì¤Ð¡¢ Subversion ¤òÍøÍѤµ¤ì¤ë¤³¤È¤ò¿ä¾©¤·¤Þ¤¹¡£ ¤â¤·¡¢¥½¡¼¥¹¤òį¤á¤ë¤À¤±¤Ç¤Ê¤¯¡¢ Áö¤é¤»¤ë¤¿¤á¤ËÆþ¼ê¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ °ìÉô¤À¤±Áª¤Ö¤Î¤Ç¤Ï¤Ê¤¯¡¢&os.current; ¤ÎÁ´ÂΤò¼ê¤ËÆþ¤ì¤Æ¤¯¤À¤µ¤¤¡£ ¥½¡¼¥¹¤Î¤µ¤Þ¤¶¤Þ¤ÊÉôʬ¤¬Â¾¤ÎÉôʬ¤Î¹¹¿·¤Ë°Í¸¤·¤Æ¤ª¤ê¡¢ °ìÉô¤Î¤ß¤ò¥³¥ó¥Ñ¥¤¥ë¤·¤è¤¦¤È¤¹¤ë¤È¡¢ ¤Û¤Ü´Ö°ã¤¤¤Ê¤¯ÌäÂ꤬µ¯¤­¤Þ¤¹¡£ - &os.current; ¤ò¥³¥ó¥Ñ¥¤¥ë-CURRENT¥³¥ó¥Ñ¥¤¥ë¤¹¤ëÁ°¤Ë + &os.current; ¤ò¥³¥ó¥Ñ¥¤¥ë + -CURRENT + ¥³¥ó¥Ñ¥¤¥ë + ¤¹¤ëÁ°¤Ë /usr/src/Makefile ¤òÃí°Õ¿¼¤¯ÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î½èÍý¤Î°ìÉô¤È¤·¤Æ¡¢ºÇ½é¤Ë ¿·¤·¤¤¥«¡¼¥Í¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤· ¤Æ¡¢world ¤òºÆ¹½ÃÛ ¤·¤Æ¤¯¤À¤µ¤¤¡£&a.current; ¤È /usr/src/UPDATING ¤òÆÉ¤á¤Ð¡¢ ¼¡¤Î¥ê¥ê¡¼¥¹¤Ø¸þ¤±¤Æ°Ü¤Ã¤Æ¤æ¤¯¤ËÅö¤¿¤Ã¤Æ¡¢ ¤È¤­¤É¤­É¬ÍפȤʤë´û¸¥·¥¹¥Æ¥à¤«¤é¤Î¿·¥·¥¹¥Æ¥à¤Î¹½ÃÛ¼ê½ç¤Ë¤Ä¤¤¤Æ¤ÎºÇ¿·¾ðÊ󤬯À¤é¤ì¤ë¤Ç¤·¤ç¤¦¡£ ¥¢¥¯¥Æ¥£¥Ö¤Ë¤Ê¤Ã¤Æ¤¯¤À¤µ¤¤! &os.current; ¤Î¥æ¡¼¥¶¤Ë¤Ï¡¢ ³ÈÄ¥¤ä¥Ð¥°ÄÙ¤·¤Ë´Ø¤·¤ÆÄ󰯤¹¤ë¤³¤È¤¬´«¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£ ¥³¡¼¥É¤òȼ¤¦Äó°Æ¤Ï¤â¤Ã¤È¤â´¿·Þ¤µ¤ì¤ë¤â¤Î¤Ç¤¹! °ÂÄêÈǤΠ&os; ¤ò»È¤¦ Ìõ: &a.jp.iwasaki; &os.stable; ¤Ã¤Æ¤Ê¤Ë? -STABLE &os.stable; ¤È¤ÏÄê´üŪ¤Ë¸ø³«¤µ¤ì¤ë¥ê¥ê¡¼¥¹¤òºîÀ®¤¹¤ë¤¿¤á¤Î³«È¯¥Ö¥é¥ó¥Á¤Ç¤¹¡£ ¤³¤Î¥Ö¥é¥ó¥Á¤Ë²Ã¤¨¤é¤ì¤ëÊѹ¹¤Ï¸¶Â§¤È¤·¤Æ¡¢ »öÁ°¤Ë &os.current; ¤Ç»î¸³¤º¤ß¤Ç¤¢¤ë¤È¤¤¤¦ÆÃħ¤¬¤¢¤ê¤Þ¤¹¡£ ¤¿¤À¤½¤¦¤Ç¤¢¤Ã¤Æ¤â¡¢ ¤³¤ì¤Ï³«È¯ÍÑ¥Ö¥é¥ó¥Á¤Î°ì¤Ä¤Ç¤¢¤ë¤È¤¤¤¦¤³¤È¤ËÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤Ä¤Þ¤ê¡¢¤¢¤ë»þÅÀ¤Ë¤ª¤±¤ë &os.stable; ¤Î¥½¡¼¥¹¤¬ ¤É¤ó¤Ê¾ì¹ç¤Ë¤â»È¤¨¤ë¤â¤Î¤Ç¤¢¤ë¤È¤Ï¸Â¤é¤Ê¤¤¤È¤¤¤¦¤³¤È¤Ç¤¹¡£ ¤³¤Î¥Ö¥é¥ó¥Á¤Ï¤â¤¦°ì¤Ä¤Î³«È¯¤Îή¤ì¤È¤¤¤¦¤À¤±¤Ç¤¢¤Ã¤Æ¡¢ ¥¨¥ó¥É¥æ¡¼¥¶¸þ¤±¤Î¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ 郎 &os.stable; ¤òɬÍפȤ·¤Æ¤¤¤ë¤Î? FreeBSD ¤Î³«È¯¥×¥í¥»¥¹¤Ë¶½Ì£¤¬¤¢¤Ã¤¿¤ê¡¢ ¤½¤ì¤ËÂФ¹¤ë¹×¸¥¤ò¹Í¤¨¤Æ¤¤¤Æ¡¢ÆÃ¤Ë¤½¤ì¤¬¼¡²ó¤Î ¥Ý¥¤¥ó¥È ¥ê¥ê¡¼¥¹¤Ë´Ø·¸¤¹¤ë¤â¤Î¤Ç¤¢¤ë¤Ê¤é &os.stable; ¤òÄɤ¦¤³¤È¤ò¹Í¤¨¤ë¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£ ¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤Ï &os.stable; ¥Ö¥é¥ó¥Á¤ËÂФ·¤Æ¹Ô¤Ê¤ï¤ì¤Þ¤¹¤¬¡¢ ¤½¤Î¤¿¤á¤Ë &os.stable; ¤òÄɤ¦É¬ÍפϤ¢¤ê¤Þ¤»¤ó¡£ ¤¹¤Ù¤Æ¤Î &os; ¥»¥­¥å¥ê¥Æ¥£´«¹ð¤Ë¤Ï EOL ¤Ë㤷¤Æ¤¤¤Ê¤¤¤¹¤Ù¤Æ¤Î¥ê¥ê¡¼¥¹¤ËÂФ¹¤ëÌäÂêÅÀ¤Î½¤ÀµÊýË¡¤¬ÀâÌÀ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¸½»þÅÀ¤Ç¤Î¸Å¤¤¥ê¥ê¡¼¥¹¤Î FreeBSD ¤Î¥»¥­¥å¥ê¥Æ¥£¥Ý¥ê¥·¡¼¤ÎÁ´ÀâÌÀ¤òÃΤë¤Ë¤Ï¡¢http://www.FreeBSD.org/ja/security/ ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¡£ &os.stable; ¥Ö¥é¥ó¥Á¤Ï¤¤¤Ä¤â¥³¥ó¥Ñ¥¤¥ë¤¬¤Ç¤­¡¢ °ÂÄê¤Ëưºî¤¹¤Ù¤­¤Ç¤¹¤¬¡¢ ¤½¤ì¤¬Êݾڤµ¤ì¤Æ¤¤¤ë¤È¤¤¤¦¤ï¤±¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ¤Þ¤¿¡¢¥³¡¼¥É¤Ï &os.stable; ¤Ë²Ã¤¨¤é¤ì¤ëÁ°¤Ë &os.current; ¤Ç³«È¯¤µ¤ì¤ë¤Î¤Ç¤¹¤¬¡¢&os.stable; ¤Î¥æ¡¼¥¶¤Ï &os.current; ¤è¤ê¤â¿¤¤¤¿¤á¡¢&os.current; ¤Çȯ¸«¤µ¤ì¤Ê¤«¤Ã¤¿¥Ð¥°¤¬ &os.stable; ¤Çȯ¸«¤µ¤ì¡¢ ¤È¤­¤É¤­¤½¤ì¤¬ÌäÂê¤È¤Ê¤ë¤³¤È¤¬¤¢¤ë¤Î¤ÏÈò¤±¤ë¤³¤È¤¬¤Ç¤­¤Þ¤»¤ó¡£ ¤³¤Î¤è¤¦¤ÊÍýͳ¤«¤é¡¢ÌÕÌÜŪ¤Ë &os.stable; ¤òÄɤ¤¤«¤±¤ë¤Ù¤­¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ÆÃ¤Ë¡¢ºÇ½é¤Ë³«È¯´Ä¶­¤â¤·¤¯¤Ï¥Æ¥¹¥È´Ä¶­¤Ç¥³¡¼¥É¤ò½½Ê¬¤Ë»î¸³¤»¤º¤Ë¡¢ ¥×¥í¥À¥¯¥·¥ç¥óÉʼÁ¤¬Í׵ᤵ¤ì¤ë¥µ¡¼¥Ð¤ò &os.stable; ¤Ë¥¢¥Ã¥×¥°¥ì¡¼¥É¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£ ¤â¤·»î¸³¤ò¤¹¤ë»ñ¸»Åª¤Ê;͵¤¬¤Ê¤¤¾ì¹ç¤Ï¡¢ ¥ê¥ê¡¼¥¹´Ö¤Î¥Ð¥¤¥Ê¥ê¥¢¥Ã¥×¥Ç¡¼¥Èµ¡Ç½¤òÍøÍѤ·¤Æ¡¢ ºÇ¿·¤Î FreeBSD ¥ê¥ê¡¼¥¹¤ò»È¤¦¤³¤È¤ò¿ä¾©¤·¤Þ¤¹¡£ &os.stable; ¤ò»È¤¦ -STABLE ÍøÍѤ¹¤ë &os.stable; ¤Î¹½Ãۤ˴ØÏ¢¤¹¤ë»öÊÁ¤ä¡¢ ¤½¤Î¾¤ÎÃí°Õ¤¹¤Ù¤­ÅÀ ¤Ë´Ø¤¹¤ë¾ðÊó¤òÆÀ¤ë¤¿¤á¤Ë¡¢ &a.stable.name; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë²Ã¤ï¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤Þ¤¿³«È¯¼Ô¤ÏµÄÏÀ¤Î;ÃϤ¬¤¢¤ë½¤Àµ¤äÊѹ¹¤ò¹Í¤¨¤Æ¤¤¤ë¾ì¹ç¤Ë¡¢ ¤³¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ç¸øÉ½¤·¡¢ Ä󰯤µ¤ì¤¿Êѹ¹¤Ë´Ø¤·¤ÆÌäÂ꤬À¸¤¸¤ë¤«¤É¤¦¤«¤òÊÖÅú¤¹¤ëµ¡²ñ¤ò¥æ¡¼¥¶¤ËÍ¿¤¨¤Þ¤¹¡£ Äɤ¤¤«¤±¤Æ¤¤¤ë¥Ö¥é¥ó¥Á¤Ë´ØÏ¢¤¹¤ë svn ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë»²²Ã¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤¿¤È¤¨¤Ð¡¢9-STABLE ¥Ö¥é¥ó¥Á¤òÄɤ¤¤«¤±¤Æ¤¤¤ë¥æ¡¼¥¶¤Ï &a.svn-src-stable-9.name; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë»²²Ã¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Î¥ê¥¹¥È¤Ç¤Ï¡¢ Êѹ¹¤¬¤Ê¤µ¤ì¤ë¤´¤È¤ËºîÀ®¤µ¤ì¤ë commit log ¤ä¤½¤ì¤Ëȼ¤¦ µ¯¤³¤ê¤¦¤ëÉûºîÍѤˤĤ¤¤Æ¤Î¾ðÊ󤬵­Ï¿¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ËÆþ¤ë¤Ë¤Ï¡¢ &a.mailman.lists.link; ¤ò¤¿¤É¤Ã¤Æ»²²Ã¤·¤¿¤¤¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ò¥¯¥ê¥Ã¥¯¤·¡¢ ¼ê½ç¤ÎÀâÌÀ¤Ë¤·¤¿¤¬¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¥½¡¼¥¹¥Ä¥ê¡¼Á´ÂΤÎÊѹ¹ÅÀ¤òÄɤ¤¤«¤±¤ë¤Ë¤Ï¡¢ &a.svn-src-all.name; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ò¹ØÆÉ¤·¤Æ¤¯¤À¤µ¤¤¡£ Ëè·î¸ø³«¤µ¤ì¤Æ¤¤¤ë &os.stable; ¤«¤é¥Ó¥ë¥É¤µ¤ì¤¿¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È¤Î¿·¤·¤¤¥·¥¹¥Æ¥à¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤Ë¤Ï¡¢ ¾ÜºÙ¤Ë¤Ä¤¤¤Æ¡¢ ¥¹¥Ê¥Ã¥×¥·¥ç¥Ã¥È ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ¤â¤·¤¯¤Ï¡¢¥ß¥é¡¼¥µ¥¤¥È¤«¤éºÇ¶á¤Î &os.stable; ¥ê¥ê¡¼¥¹¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¡¢²¼µ­¤ÎÀâÌÀ¤Ë½¾¤Ã¤ÆºÇ¿·¤Î &os.stable; ¤Î¥½¡¼¥¹¥³¡¼¥É¤Ë¹¹¿·¤¹¤ë¤³¤È¤â¤Ç¤­¤Þ¤¹¡£ ´û¤Ë &os; ¤Î°ÊÁ°¤Î¥ê¥ê¡¼¥¹¤¬Æ°¤¤¤Æ¤¤¤ë¥·¥¹¥Æ¥à¤ò &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é¥¢¥Ã¥×¥°¥ì¡¼¥É¤¹¤ë¤Ë¤Ï¡¢ °Ê²¼¤Î¤è¤¦¤Ê¤¤¤¯¤Ä¤«¤ÎÊýË¡¤¬¤¢¤ê¤Þ¤¹¡£ - svnSubversion ¤ò»È¤Ã¤Æ¡¢ + svn + Subversion + ¤ò»È¤Ã¤Æ¡¢ ´õ˾¤¹¤ë³«È¯¥Ö¥é¥ó¥Á¡¢ ¤â¤·¤¯¤Ï¥ê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¤ò¥Á¥§¥Ã¥¯¥¢¥¦¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ÎÊýË¡¤Ï¡¢³«È¯Ãæ¤Î &os; ¥ê¥Ý¥¸¥È¥ê¤Ø¤Î¥¢¥¯¥»¥¹¤òÄ󶡤·¤Æ¤ª¤ê¡¢ ¿ä¾©¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¥Ö¥é¥ó¥Á̾¤Ë¤Ä¤¤¤Æ¤Ï¡¢¸½ºß¤Î³«È¯¤Î¥Ø¥Ã¥É¥Ö¥é¥ó¥Á¤Ï head¡¢¤ª¤è¤Ó ¥ê¥ê¡¼¥¹¥¨¥ó¥¸¥Ë¥¢¥ê¥ó¥°¤Î¥Ú¡¼¥¸ ¤ÎÆÃÄê¤Î¥Ö¥é¥ó¥Á¤Ç¤Ï - stable/9¡¢¤Þ¤¿¤Ï + stable/9 + -STABLE + Subversion + ¤ò»È¤Ã¤¿Æ±´ü + ¡¢¤Þ¤¿¤Ï releng/9.0 ¤È¤Ê¤ê¤Þ¤¹¡£ - Subversion-STABLESubversion ¤ò»È¤Ã¤¿Æ±´ü ¤ò»È¤Ã¤Æ¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤¹¤ëºÝ¤Î URL ¤Î¥×¥ì¥Õ¥£¥Ã¥¯¥¹¤Ï¡¢Subversion ¥ß¥é¡¼¥µ¥¤¥È ¤ÇÀâÌÀ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¥ê¥Ý¥¸¥È¥ê¥µ¥¤¥º¤Î´ÑÅÀ¤«¤é¡¢ ´õ˾¤¹¤ë¥µ¥Ö¥Ä¥ê¡¼¤Î¤ß¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤¹¤ë¤³¤È¤¬¿ä¾©¤µ¤ì¤Þ¤¹¡£ ¥¤¥ó¥¿¡¼¥Í¥Ã¥È¤Ø¤ÎÀܳ¤Ë¹â®¤Ê²óÀþ¤òÍøÍѤǤ­¤Ê¤¤¤Î¤Ç¤¢¤ì¤Ð¡¢ - CTM-STABLECTM ¤ò»È¤Ã¤ÆÆ±´ü¤¹¤ë + CTM + -STABLE + CTM ¤ò»È¤Ã¤ÆÆ±´ü¤¹¤ë + ¤ò¸¡Æ¤¤·¤Æ¤ß¤Þ¤·¤ç¤¦¡£ - &os.stable;-STABLE¹½ÃÛ¡¢¥³¥ó¥Ñ¥¤¥ë ¤ò¥³¥ó¥Ñ¥¤¥ë¤¹¤ëÁ°¤Ë¡¢ + &os.stable; + -STABLE + ¹½ÃÛ¡¢¥³¥ó¥Ñ¥¤¥ë + ¤ò¥³¥ó¥Ñ¥¤¥ë¤¹¤ëÁ°¤Ë¡¢ /usr/src/Makefile ¤ò¤è¤¯ÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î½èÍý¤Î°ìÉô¤È¤·¤ÆºÇ½é¤Ë ¿·¤·¤¤¥«¡¼¥Í¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¡¢ world ¤òºÆ¹½ÃÛ ¤·¤Æ¤¯¤À¤µ¤¤¡£&a.stable; ¤È /usr/src/UPDATING ¤òÆÉ¤ó¤Ç¡¢ ¼¡¤Î¥ê¥ê¡¼¥¹¤Ø¸þ¤±¤Æ°Ü¤Ã¤Æ¤æ¤¯¤ËÅö¤¿¤Ã¤Æ¡¢ ¤È¤­¤É¤­É¬ÍפȤʤë´û¸¥·¥¹¥Æ¥à¤«¤é¤Î¿·¥·¥¹¥Æ¥à¤Î¹½ÃÛ¼ê½ç¤Ë¤Ä¤¤¤Æ¤ÎºÇ¿·¾ðÊó¤òÆÀ¤Æ¤¯¤À¤µ¤¤¡£ ¥½¡¼¥¹¤ÎƱ´ü Ìõ: &a.jp.iwasaki;¡¢1997 ǯ 9 ·î 13 Æü ¥¤¥ó¥¿¡¼¥Í¥Ã¥ÈÀܳ¤Þ¤¿¤ÏÅŻҥ᡼¥ë¤ò»ÈÍѤ·¤Æ¡¢&os; ¥×¥í¥¸¥§¥¯¥È¤Î¥½¡¼¥¹¤Î¤¢¤ë°ìÉôʬ¤Þ¤¿¤ÏÁ´ÂΤκǿ·¤òÄɤ¤¤«¤±¤ëÊýË¡¤Ï¿§¡¹¤¢¤ê¤Þ¤¹¡£ ´ðËÜŪ¤Ê¥µ¡¼¥Ó¥¹¤Ï Subversion ¤È CTM ¤Ç¤¹¡£ ¥½¡¼¥¹¥Ä¥ê¡¼¤Î°ìÉô¤òºÇ¿·¤Î¤â¤Î¤Ë¹¹¿·¤¹¤ë¤³¤È¤Ï²Äǽ¤Ç¤¹¡£ ¤¿¤À¤·¡¢¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤ë¥¢¥Ã¥×¥Ç¡¼¥È¼ê½ç¤Ï¡¢ ¥½¡¼¥¹¥Ä¥ê¡¼Á´ÂΤòºÇ¿·¤Î¤â¤Î¤Ë¹¹¿·¤·¡¢ /bin, /sbin ¤È¤¤¤Ã¤¿¥æ¡¼¥¶¶õ´Ö¤Çưºî¤¹¤ë¤â¤Î¡¢ ¤ª¤è¤Ó¥«¡¼¥Í¥ë¥½¡¼¥¹¤òºÆ¹½ÃÛ¤¹¤ë¤³¤È¤Î¤ß¤Ç¤¹¡£ ¥½¡¼¥¹¥Ä¥ê¡¼¤Î°ìÉô¤À¤±¤Ç¤¢¤Ã¤¿¤ê¡¢¥«¡¼¥Í¥ë¤À¤±¡¢ ¤â¤·¤¯¤Ï¥æ¡¼¥¶¥é¥ó¥É¤Î¥×¥í¥°¥é¥à¤À¤±¤ò¹¹¿·¤·¤¿¾ì¹ç¤Ï¡¢ ÌäÂ꤬À¸¤¸¤ë¤³¤È¤¬¤è¤¯¤¢¤ê¤Þ¤¹¡£ ¤³¤Î»þ¤ËȯÀ¸¤¹¤ëÌäÂê¤Ï¥³¥ó¥Ñ¥¤¥ë»þ¤Î¥¨¥é¡¼¤«¤é¥«¡¼¥Í¥ë¥Ñ¥Ë¥Ã¥¯¡¢ ¥Ç¡¼¥¿¤ÎÇ˲õ¤È¤µ¤Þ¤¶¤Þ¤Ç¤¹¡£ Subversion Subversion ¤Ï pull Ʊ´ü¥â¥Ç¥ë¤òºÎÍѤ·¤Æ¤¤¤Þ¤¹¡£ ¥æ¡¼¥¶ (¤Þ¤¿¤Ï cron ¥¹¥¯¥ê¥×¥È) ¤¬ svn ¤òµ¯Æ°¤·¡¢¥Õ¥¡¥¤¥ë¤òºÇ¿·¾õÂ֤ˤ·¤Þ¤¹¡£ Subversion ¤Ï¡¢ ¥í¡¼¥«¥ë¤Î¥½¡¼¥¹¥Ä¥ê¡¼¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ëºÇ¤â¹¥¤Þ¤·¤¤ÊýË¡¤Ç¤¹¡£ ¹¹¿·¾ðÊó¤Ï¤½¤Î»þÅÀ¤ÎºÇ¿·¤Î¤â¤Î¤Ç¤¢¤ê¡¢ ¥æ¡¼¥¶¤Ï¤¤¤Ä¥À¥¦¥ó¥í¡¼¥É¤¹¤ë¤«¤ò¥³¥ó¥È¥í¡¼¥ë¤·¤Þ¤¹¡£ ÆÃÄê¤Î¥Õ¥¡¥¤¥ë¤ä¥Ç¥£¥ì¥¯¥È¥ê¤Ë¸ÂÄꤷ¤Æ¹¹¿·¤¹¤ë¤³¤È¤â´Êñ¤Ë¤Ç¤­¤Þ¤¹¡£ ¹¹¿·¾ðÊó¤Ï¥µ¡¼¥Ð¤Ë¤è¤Ã¤ÆÁÇÁ᤯À¸À®¤µ¤ì¤Þ¤¹¡£ CTM °ìÊý¡¢CTM ¤Ï¤¢¤Ê¤¿¤¬»ý¤Ã¤Æ¤¤¤ë¥½¡¼¥¹¤È¥Þ¥¹¥¿¥¢¡¼¥«¥¤¥Ö¾å¤Ë ¤¢¤ë¤½¤ì¤È¤ÎÂÐÏÃŪ¤ÊÈæ³Ó¤ò¤ª¤³¤Ê¤¤¤Þ¤»¤ó¤·¡¢ ¤¢¤ë¤¤¤Ï¸þ¤³¤¦Â¦¤«¤éÊѹ¹ÅÀ¤ò pull ¤·¤¿¤ê¤â¤·¤Þ¤»¤ó¡£ ¤½¤Î¤«¤ï¤ê¤Ë¡¢Á°²ó¤Î¼Â¹Ô»þ¤«¤é¤ÎÊѹ¹¤òǧ¼±¤¹¤ë¥¹¥¯¥ê¥×¥È¤¬ ¥Þ¥¹¥¿ CTM ¥Þ¥·¥ó¾å¤Ç°ìÆü¤Ë¿ô²ó¼Â¹Ô¤µ¤ì¡¢ ¤¹¤Ù¤Æ¤ÎÊѹ¹¤ò compress ¤·¤ÆÄ̤·ÈÖ¹æ¤ò¿¶¤ê¡¢ ¤µ¤é¤ËÅŻҥ᡼¥ë¤Ç¡¢°õ»ú²Äǽ¤Ê ASCII ¥­¥ã¥é¥¯¥¿¤Î¤ß¤ÇžÁ÷¤Ç¤­¤ë¤è¤¦¤Ë¥¨¥ó¥³¡¼¥É¤·¤Þ¤¹¡£ ¼õ¿®¤·¤¿¸å¤Ï¡¢ ¤³¤ì¤é¤Î CTM ¤Î¥Ç¥ë¥¿ ¤Ï¼«Æ° Ū¤Ë¥Ç¥³¡¼¥É¡¢¸¡ºº¤·¤Æ¥æ¡¼¥¶¤Î¥½¡¼¥¹¤Î¥³¥Ô¡¼¤ËÊѹ¹¤òŬÍѤ¹¤ë &man.ctm.rmail.1; ¤Ë¤è¤Ã¤Æ½èÍý²Äǽ¤È¤Ê¤ê¤Þ¤¹¡£ ¤³¤Î½èÍý¤Ï Subversion ¤è¤ê¤º¤Ã¤È¸úΨŪ¤Ç¤¢¤ê¡¢pull ¥â¥Ç¥ë¤È¤¤¤¦¤è¤ê¤à¤·¤í push ¥â¥Ç¥ë¤Ç¤¢¤ë¤¿¤á¡¢ ¥µ¡¼¥Ð»ñ¸»¤ÎÉé²Ù¤Ï·Ú¤¯¤Ê¤ê¤Þ¤¹¡£ ¾¤Î¥È¥ì¡¼¥É¥ª¥Õ¤â¤¢¤ê¤Þ¤¹¡£ Subversion ¤Ç¤¢¤ì¤Ð¡¢ ¤¦¤Ã¤«¤ê¥í¡¼¥«¥ë¤Î¥¢¡¼¥«¥¤¥Ö¤Î°ìÉô¤ò¾Ã¤·¤Æ¤·¤Þ¤Ã¤Æ¤â¡¢ ²õ¤ì¤¿Éôʬ¤ò¸¡½Ð¤·¤ÆºÆ¹½ÃÛ¤·¤Æ¤¯¤ì¤Þ¤¹¡£ CTM ¤Ï¤³¤ì¤ò¤ä¤Ã¤Æ¤¯¤ì¤Þ¤»¤ó¡£ ¤â¤·¥½¡¼¥¹¥Ä¥ê¡¼¤Î°ìÉô¤ò¾Ã¤·¤Æ¤·¤Þ¤¤¡¢ ¤½¤·¤Æ¥Ð¥Ã¥¯¥¢¥Ã¥×¤ò¼è¤Ã¤Æ¤¤¤Ê¤¤¤Î¤Ç¤¢¤ì¤Ð¡¢ºÇ¿·¤Î CTM ¥Ù¡¼¥¹¥Ç¥ë¥¿ ¤òÍѤ¤¤Æ¡¢°ì¤«¤é¤ä¤êľ¤·¡¢ CTM ¤ò»È¤Ã¤Æ¤¹¤Ù¤Æ¤òºÆ¹½ÃÛ¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ <quote>world</quote> ¤ÎºÆ¹½ÃÛ world ¤ÎºÆ¹½ÃÛ &os.stable;¡¢&os.current; ¤Ê¤É¤Î &os; ¤Î¤É¤ì¤«ÆÃÄê¤Î¥Ð¡¼¥¸¥ç¥ó¤Ë¤Ä¤¤¤Æ¡¢ ¥í¡¼¥«¥ë¤Î¥½¡¼¥¹¥Ä¥ê¡¼¤òƱ´ü¤µ¤»¤¿¤é¡¢ ¤½¤Î¥½¡¼¥¹¥Ä¥ê¡¼¤ò»È¤Ã¤Æ¥·¥¹¥Æ¥à¤òºÆ¹½ÃۤǤ­¤Þ¤¹¡£ ¥Ð¥Ã¥¯¥¢¥Ã¥×¤ÎºîÀ® ¥·¥¹¥Æ¥à¤òºÆ¹½ÃÛ¤¹¤ëÁ°¤Ë¡¢ ¥Ð¥Ã¥¯¥¢¥Ã¥×¤òºîÀ®¤¹¤ë¤³¤È¤Î½ÅÍ×À­¤Ï¡¢ ¤¤¤¯¤é¶¯Ä´¤·¤Æ¤â¤·²á¤®¤ë¤È¸À¤¦¤³¤È¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ¥·¥¹¥Æ¥àÁ´ÂΤκƹ½ÃÛ¤È¤ÏÆñ¤·¤¤ºî¶È¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¤¬¡¢ ¤É¤ó¤Ê¤ËÃí°Õ¤·¤Æ¤¤¤¿¤È¤·¤Æ¤â¡¢ ¥½¡¼¥¹¥Ä¥ê¡¼¤½¤Î¤â¤Î¤Ë¼ê°ã¤¤¤¬¤¢¤Ã¤¿»þ¤Ë¤Ï¡¢ ¥·¥¹¥Æ¥à¤¬µ¯Æ°¤·¤Ê¤¯¤Ê¤Ã¤Æ¤·¤Þ¤¦¾õÂ֤ˤʤ뤳¤È¤¬¤¢¤ë¤Î¤Ç¤¹¡£ ¤Þ¤º¡¢¥Ð¥Ã¥¯¥¢¥Ã¥×¤¬¤­¤Á¤ó¤ÈºîÀ®¤µ¤ì¤Æ¤¤¤ë¤³¤È¤ò³Îǧ¤·¤Æ¡¢ µ¯Æ°²Äǽ¥¤¥ó¥¹¥È¡¼¥ë¥á¥Ç¥£¥¢¤òÍѰդ·¤Æ¤¯¤À¤µ¤¤¡£ ¿ʬ¡¢¤½¤ì¤ò»È¤¦¤³¤È¤Ï¤Ê¤¤¤È»×¤¤¤Þ¤¹¤¬¡¢ ¤¢¤È¤Ç¸å²ù¤¹¤ë¤³¤È¤Î¤Ê¤¤¤è¤¦¡¢Ç°¤Î¤¿¤áÍѰդ·¤Æ¤ª¤­¤Þ¤·¤ç¤¦¡£ ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë»²²Ã¤¹¤ë ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È ¤â¤È¤â¤È¡¢&os.stable; ¤È &os.current; ¤Î¥³¡¼¥É¥Ö¥é¥ó¥Á¤Ï¡¢ ³«È¯Ãæ¤Î¤â¤Î¤Ç¤¹¡£ &os; ¤Îºî¶È¤Ë¹×¸¥¤·¤Æ¤¯¤À¤µ¤Ã¤Æ¤¤¤ë¿Íã¤â¿Í´Ö¤Ç¤¹¤«¤é¡¢ »þ¤Ë¤Ï¥ß¥¹¤ò¤¹¤ë¤³¤È¤À¤Ã¤Æ¤¢¤ë¤Ç¤·¤ç¤¦¡£ ¤½¤Î¤è¤¦¤Ê´Ö°ã¤¤¤Ï¡¢ ñ¤Ë·Ù¹ð¤ò¼¨¤¹¸«´·¤ì¤Ê¤¤¿ÇÃÇ¥á¥Ã¥»¡¼¥¸¤ò¥·¥¹¥Æ¥à¤¬É½¼¨¤¹¤ë¤è¤¦¤Ê¡¢ ¤Þ¤Ã¤¿¤¯³²¤Î¤Ê¤¤¤â¤Î¤Ç¤¢¤ë¤³¤È¤â¤¢¤ì¤Ð¡¢¥·¥¹¥Æ¥à¤òµ¯Æ°¤Ç¤­¤Ê¤¯¤·¤¿¤ê¡¢ ¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤òÇ˲õ¤·¤Æ¤·¤Þ¤¦¤è¤¦¤Ê¡¢ ¶²¤í¤·¤¤·ë²Ì¤ò¾·¤¯¤â¤Î¤«¤âÃΤì¤Þ¤»¤ó¡£ ÌäÂ꤬À¸¤¸¤¿¾ì¹ç¡¢ ÌäÂê¤Î¾ÜºÙ¤È¡¢¤É¤Î¤è¤¦¤Ê¥·¥¹¥Æ¥à¤¬±Æ¶Á¤ò¼õ¤±¤ë¤«¤Ë¤Ä¤¤¤Æ½ñ¤«¤ì¤¿ Ãí°Õ (heads up) ¤Îµ­»ö¤¬Å¬Àڤʥ᡼¥ê¥ó¥°¥ê¥¹¥È¤ËÅê¹Æ¤µ¤ì¤Þ¤¹¡£ ¤½¤·¤Æ¡¢¤½¤ÎÌäÂ꤬²ò·è¤µ¤ì¤ë¤È¡¢ ÌäÂê²ò·è (all clear) ¤Î¥¢¥Ê¥¦¥ó¥¹µ­»ö¤¬Æ±ÍͤËÅê¹Æ¤µ¤ì¤Þ¤¹¡£ &os.stable; ¤ä &os.current; ¥Ö¥é¥ó¥Á¤òÄɿ路¤Æ¤¤¤ë¥æ¡¼¥¶¤Ç¡¢ &a.stable; ¤ä &a.current; ¤òÆÉ¤Þ¤Ê¤¤¤È¤¤¤¦¤Î¤Ï¡¢ ¼«¤éºÒÆñ¤ò¾·¤¯¤è¤¦¤Ê¤â¤Î¤Ç¤¹¡£ ÌõÃí: ¤³¤ì¤é¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ï±Ñ¸ì¤Ç¤ä¤ê¤È¤ê¤µ¤ì¤Æ¤¤¤ë¤¿¤á¡¢ ÆüËܸì¤Ç¤ÎÅê¹Æ¤Ï´¿·Þ¤µ¤ì¤Þ¤»¤ó¡£±Ñ¸ì¤Ç¤Î¤ä¤ê¤È¤ê¤¬¤Ç¤­¤Ê¤¤¿Í¤Ï¡¢ FreeBSD ͧ¤Î²ñ ¤Î±¿±Ä¤·¤Æ¤¤¤ë¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ò¤¢¤¿¤Ã¤Æ¤ß¤ë¤Î¤¬¤¤¤¤¤Ç¤·¤ç¤¦¡£ <command>make world</command> ¤Ï»È¤ï¤Ê¤¤¤³¤È ¸Å¤¤¥É¥­¥å¥á¥ó¥È¤ÎÃæ¤Ë¤Ï¡¢ make world ¤ò»È¤¦¤³¤È¤òÁ¦¤á¤Æ¤¤¤ë¤â¤Î¤¬¤¢¤ê¤Þ¤¹¡£ ¤³¤ì¤Ï¡¢½ÅÍפʼê½ç¤ò¤¤¤¯¤Ä¤«È´¤«¤·¤Æ¤·¤Þ¤¦¤Î¤Ç¡¢ ¥¨¥­¥¹¥Ñ¡¼¥È¤Ç¤Ê¤±¤ì¤Ð»È¤¦¤Ù¤­¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ¤Û¤Ü¤¢¤é¤æ¤ë¾ì¹ç¤Ë¤ª¤¤¤Æ¡¢make world ¤ò¼Â¹Ô¤¹¤ë¤Î¤Ï´Ö°ã¤Ã¤Æ¤ª¤ê¡¢ ¤³¤³¤ÇÀâÌÀ¤µ¤ì¤Æ¤¤¤ë¼ê½ç¤òÍѤ¤¤ë¤Ù¤­¤Ç¤¹¡£ ¥·¥¹¥Æ¥à¤ò¹¹¿·¤¹¤ëÀµ¼°¤ÊÊýË¡ ¥·¥¹¥Æ¥à¤ò¹¹¿·¤¹¤ëÁ°¤Ë¡¢ /usr/src/UPDATING ¤òÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¤³¤Î¥Õ¥¡¥¤¥ë¤Ë¤Ï¡¢ÍѰդ·¤¿¥½¡¼¥¹¥³¡¼¥É¤Ç buildworld ¤ò¹Ô¤¦Á°¤ËɬÍפʼê½ç¤¬½ñ¤«¤ì¤Æ¤¤¤Þ¤¹¡£ ¤½¤Î¸å¡¢°Ê²¼¤Î¼ê½ç¤òƧ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¤³¤ÎÀá¤ÇÀâÌÀ¤¹¤ë¥¢¥Ã¥×¥Ç¡¼¥È¤Î¥×¥í¥»¥¹¤Ï¡¢¸Å¤¤¥³¥ó¥Ñ¥¤¥é¡¢ ¸Å¤¤¥«¡¼¥Í¥ë¡¢¸Å¤¤ world¡¢¤½¤·¤Æ¸Å¤¤¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤«¤é¤Ê¤ë¡¢ ¸Å¤¤¥Ð¡¼¥¸¥ç¥ó¤Î &os; ¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤³¤È¤òÁÛÄꤷ¤Æ¤¤¤Þ¤¹¡£ ¤³¤³¤Ç world ¤Ï¡¢¥³¥¢¥·¥¹¥Æ¥à¤Î¥Ð¥¤¥Ê¥ê¡¢¥é¥¤¥Ö¥é¥ê¡¢ ¥×¥í¥°¥é¥ß¥ó¥°¥Õ¥¡¥¤¥ë¤ò°ÕÌ£¤·¤Þ¤¹¡£ ¥³¥ó¥Ñ¥¤¥é¤Ï world ¤Î°ìÉô¤Ç¤¹¤¬¡¢ ¤¤¤¯¤Ä¤«ÆÃÊ̤˵¤¤ò¤Ä¤±¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ¤Þ¤¿¡¢¤³¤ì¤é¤Î¥¹¥Æ¥Ã¥×¤Ç¤Ï¡¢ ¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤Î¥½¡¼¥¹¤ò¤¹¤Ç¤ËÆþ¼ê¤·¤Æ¤¤¤ë¤³¤È¤â²¾Äꤷ¤Æ¤¤¤Þ¤¹¡£ ¤â¤·¥·¥¹¥Æ¥à¤Î¥½¡¼¥¹¥³¡¼¥É¤¬¸Å¤¤¤è¤¦¤Ç¤·¤¿¤é¡¢ ¤òÆÉ¤ó¤Ç¡¢ ¥½¡¼¥¹¥³¡¼¥É¤ò¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤ØÆ±´ü¤¹¤ëÊýË¡¤Î¾ÜºÙ¤òÍý²ò¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥½¡¼¥¹¤«¤é¤Î¥·¥¹¥Æ¥à¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤Ï¡¢ Åö½éͽÁÛ¤·¤Æ¤¤¤¿¤â¤Î¤è¤ê¤È¤é¤¨¤¬¤¿¤¤¤â¤Î¤Ç¤¹¡£ Ť¤Ç¯·î¤Ë¤ª¤¤¤ÆÈò¤±¤é¤ì¤Ê¤¤°Í¸ÌäÂ꤬ȽÌÀ¤·¤¿¤¿¤á¡¢ &os; ¤Î³«È¯¼Ôã¤Ï¡¢¿ä¾©¤µ¤ì¤ë¥¢¥×¥í¡¼¥Á¤òÂ礭¤¯Êѹ¹¤·¤Þ¤·¤¿¡£ ¤³¤ÎÀá¤Ç¤Ï¡¢¸½ºß¿ä¾©¤µ¤ì¤Æ¤¤¤ë¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î¼ê½ç¤ÎÇØ¸å¤Ë¤¢¤ë¡¢ ÍýÏÀŪº¬µò¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Þ¤¹¡£ Ϣ³¤·¤¿¥¢¥Ã¥×¥Ç¡¼¥È¤Î¼ê½ç¤Ï¡¢°Ê²¼¤ÎÌäÂê¤ËÂбþ¤·¤Æ¤¤¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¸Å¤¤¥³¥ó¥Ñ¥¤¥é¤Ï¡¢ ¡¡ ¥Ð¥°¤ò´Þ¤ß¿·¤·¤¤¥«¡¼¥Í¥ë¤ò¥³¥ó¥Ñ¥¤¥ë¤Ç¤­¤Ê¤¤²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹ ¤½¤Î¤¿¤á¡¢¿·¤·¤¤¥«¡¼¥Í¥ë¤Î¹½Ãۤˤϡ¢ ¿·¤·¤¤¥³¥ó¥Ñ¥¤¥é¤ò»È¤¦É¬Íפ¬¤¢¤ê¤Þ¤¹¡£ ¤³¤È¤Î¤³¤È¤Ï¡¢¿·¤·¤¤¥«¡¼¥Í¥ë¤ò¹½ÃÛ¤¹¤ëÁ°¤Ë¡¢ ¿·¤·¤¤¥³¥ó¥Ñ¥¤¥é¤ò¹½ÃÛ¤·¤Æ¤¤¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤³¤È¤ò°ÕÌ£¤·¤Æ¤¤¤Þ¤¹¡£ ɬ¤º¤·¤â¡¢¿·¤·¤¤¥«¡¼¥Í¥ë¤ò¹½ÃÛ¤¹¤ëÁ°¤Ë¡¢¿·¤·¤¤¥³¥ó¥Ñ¥¤¥é¤¬ ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë ɬÍפ¬¤¢¤ë¤³¤È¤ò°ÕÌ£¤·¤Æ¤¤¤ë¤ï¤±¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ¿·¤·¤¤ world ¤Ï¡¢ ¿·¤·¤¤¥«¡¼¥Í¥ë¤Îµ¡Ç½¤Ë°Í¸¤·¤Æ¤¤¤ë²ÄǽÀ­¤¬¤¢¤ë¤¿¤á¡¢ ¿·¤·¤¤ world ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÁ°¤Ë¡¢ ¿·¤·¤¤¥«¡¼¥Í¥ë¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ¤³¤ì¤é 2 ¤Ä¤Î½ÅÍ×»ö¹à¤Ï¡¢ °Ê²¼¤ÎÀâÌÀ¤ÇÃæ¿´¤È¤Ê¤ë buildworld, buildkernel, installkernel, installworld ¤Î´ðËܤǤ¹¡£ ¾¤ÎÍýͳ¤Ë¤Ä¤¤¤Æ¤Ï°Ê²¼¤Ç¥ê¥¹¥È¥¢¥Ã¥×¤·¤Þ¤¹¡£ ¸Å¤¤ world ¤Ï¡¢¿·¤·¤¤¥«¡¼¥Í¥ë¤Ç¤ÏÀµ¤·¤¯Æ°¤«¤Ê¤¤¤«¤âÃΤì¤Þ¤»¤ó¡£ ¤½¤Î¤¿¤á¡¢¿·¤·¤¤¥«¡¼¥Í¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤¿¤é¡¢ ľ¤Á¤Ë¿·¤·¤¤ world ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ÀßÄê¤ÎÃæ¤Ë¤Ï¡¢¿·¤·¤¤ world ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëÁ°¤ËÊѹ¹¤¹¤Ù¤­¤â¤Î¤¬¤¢¤ê¤Þ¤¹¤¬¡¢ ¸Å¤¤ world ¤ò²õ¤¹²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ ¤½¤Î¤¿¤á¡¢°ìÈÌŪ¤ËÀßÄê¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤Ï¡¢ 2 ¤Ä¤Î¼ê½ç¤¬É¬ÍפǤ¹¡£ ¿¤¯¤Î¾ì¹ç¡¢¥¢¥Ã¥×¥Ç¡¼¥È¤Î¥×¥í¥»¥¹¤Ï¡¢¥Õ¥¡¥¤¥ë¤òÃÖ¤­´¹¤¨¤¿¤ê¡¢ ÄɲäΤߤò¹Ô¤¤¡¢¸Å¤¤¥Õ¥¡¥¤¥ë¤òºï½ü¤·¤Þ¤»¤ó¡£ ¤³¤Î¤³¤È¤¬ÌäÂê¤ò°ú¤­µ¯¤³¤¹²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ ¤½¤Î¤¿¤á¡¢¥¢¥Ã¥×¥Ç¡¼¥È¤Ë¤ª¤¤¤Æ¤Ï¡¢ ¼êư¤Çºï½ü¤¹¤Ù¤­¥Õ¥¡¥¤¥ë¤¬¤¢¤ë¤³¤È¤ò¡¢ ÆÃÄê¤Î¥¹¥Æ¥Ã¥×¤Ç»ØÄꤹ¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹¡£ ¤³¤ì¤Ï¾­Í輫ư²½¤µ¤ì¤ë¤«¤â¤·¤ì¤Ê¤¤¤·¡¢¤µ¤ì¤Ê¤¤¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¤³¤ì¤é¤òÇÛθ¤·¡¢°Ê²¼¤Î¿ä¾©¼ê½ç¤¬ºî¤é¤ì¤Þ¤·¤¿¡£ ¥¢¥Ã¥×¥Ç¡¼¥È¤ÎºÙ¤«¤¤¼ê½ç¤Ë¤ª¤¤¤Æ¤Ï¡¢Äɲäμê½ç¤¬É¬Íפˤʤ뤫¤â¤·¤ì¤Þ¤»¤ó¤¬¡¢ ¤³¤ÎÃæ¿´¤È¤Ê¤ë¥×¥í¥»¥¹¤Ï¡¢¤·¤Ð¤é¤¯¤Î´ÖÊѤï¤Ã¤Æ¤¤¤Þ¤»¤ó¡£ make buildworld ¿·¤·¤¤¥³¥ó¥Ñ¥¤¥é¤È´ØÏ¢¥Ä¡¼¥ë¤òºÇ½é¤Ë¥³¥ó¥Ñ¥¤¥ë¤·¡¢ ¤½¤Î¸å¡¢¿·¤·¤¤¥³¥ó¥Ñ¥¤¥é¤Ç¡¢ ¿·¤·¤¤ world ¤Î»Ä¤ê¤ÎÉôʬ¤ò¥³¥ó¥Ñ¥¤¥ë¤·¤Þ¤¹¡£ ¥³¥ó¥Ñ¥¤¥ë¤µ¤ì¤¿¤â¤Î¤Ï¡¢ /usr/obj ¤Ë³ÊǼ¤µ¤ì¤Þ¤¹¡£ make buildkernel ¤³¤³¤Ç¤Ï¡¢ /usr/obj ¤Ë¤¢¤ë ¿·¤·¤¤ ¥³¥ó¥Ñ¥¤¥é¤¬ÍѤ¤¤é¤ì¤Þ¤¹¡£ ¤³¤ì¤Ë¤è¤ê¡¢¥³¥ó¥Ñ¥¤¥é¤È¥«¡¼¥Í¥ë¤Î¥ß¥¹¥Þ¥Ã¥Á¤òËɤ°¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ make installkernel ¿·¤·¤¯¥¢¥Ã¥×¥Ç¡¼¥È¤µ¤ì¤¿¥«¡¼¥Í¥ë¤Çµ¯Æ°¤Ç¤­¤ë¤è¤¦¤Ë¡¢ ¿·¤·¤¤¥«¡¼¥Í¥ë¤È¥«¡¼¥Í¥ë¥â¥¸¥å¡¼¥ë¤ò¥Ç¥£¥¹¥¯¾å¤ËÇÛÃÖ¤·¤Þ¤¹¡£ ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤ÇºÆµ¯Æ° ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ï¡¢ ¤¹¤Ç¤Ë¼Â¹Ô¤µ¤ì¤Æ¤¤¤ë¥½¥Õ¥È¥¦¥§¥¢¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ëºÝ¤ÎÌäÂê¤òºÇ¾®¸Â¤Ë¤·¤Þ¤¹¡£ ¤Þ¤¿¡¢¿·¤·¤¤¥«¡¼¥Í¥ë¾å¤Ç¸Å¤¤ world ¤¬¼Â¹Ô¤µ¤ì¤ëºÝ¤ÎÌäÂê¤âºÇ¾®¸Â¤Ë¤·¤Þ¤¹¡£ mergemaster ¿·¤·¤¤ world ¤Ë¤ª¤±¤ëºÇ½é¤ÎÀßÄê¥Õ¥¡¥¤¥ë¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤ò¹Ô¤¤¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð¡¢¿·¤·¤¤¥æ¡¼¥¶¥°¥ë¡¼¥×¤ò¥·¥¹¥Æ¥à¤ËÄɲä·¤¿¤ê¡¢ ¥Ñ¥¹¥ï¡¼¥É¥Ç¡¼¥¿¥Ù¡¼¥¹¤ËÂФ·¡¢¿·¤·¤¤¥æ¡¼¥¶Ì¾¤òÄɲ乤뤫¤â¤·¤ì¤Þ¤»¤ó¡£ Á°²ó¤Î¥¢¥Ã¥×¥Ç¡¼¥È¸å¤Ë¡¢ ¿·¤·¤¤¥°¥ë¡¼¥×¤äÆÃÊ̤Υ·¥¹¥Æ¥à¤Î¥æ¡¼¥¶¥¢¥«¥¦¥ó¥È¤¬Äɲ䵤줿¾ì¹ç¤Ë¡¢ installworld ¤Î¥¹¥Æ¥Ã¥×¤Ç¡¢ ¿·¤·¤¯¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤¿¥·¥¹¥Æ¥à¤Î¥æ¡¼¥¶¤Þ¤¿¤Ï¥·¥¹¥Æ¥à¤Î¥°¥ë¡¼¥×̾¤òÌäÂê¤Ê¤¯»È¤¦¤³¤È¤¬¤Ç¤­¤ë¤è¤¦¤Ë¡¢ ¤³¤Îºî¶È¤¬¤È¤­¤É¤­É¬ÍפȤʤê¤Þ¤¹¡£ make installworld world ¤ò /usr/obj ¤«¤é¥³¥Ô¡¼¤·¤Þ¤¹¡£ ¤³¤ì¤Ç¡¢¥Ç¥£¥¹¥¯¤Ë¤Ï¿·¤·¤¤¥«¡¼¥Í¥ë¤È world ¤¬ÃÖ¤«¤ì¤¿¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£ mergemaster ¥Ç¥£¥¹¥¯¤Ë¿·¤·¤¤ world ¤¬ÃÖ¤«¤ì¤¿¤Î¤Ç¡¢ »Ä¤ê¤ÎÀßÄê¥Õ¥¡¥¤¥ë¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤·¤Þ¤¹¡£ make delete-old ¤³¤Î¥¿¡¼¥²¥Ã¥È¤Ï (»È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿) ¥Õ¥¡¥¤¥ë¤òºï½ü¤·¤Þ¤¹¡£ ¤â¤·»È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¥Õ¥¡¥¤¥ë¤¬¥Ç¥£¥¹¥¯¤Ë»Ä¤Ã¤Æ¤¤¤ë¤È¡¢ ÌäÂ꤬µ¯¤­¤ë²ÄǽÀ­¤¬¤¢¤ë¤¿¤á½ÅÍפʺî¶È¤Ç¤¹¡£ ¤¿¤È¤¨¤Ð¡¢¸Å¤¤ utmp.h ¤¬»Ä¤Ã¤Æ¤¤¤ë¤È¡¢ ¿·¤·¤¤ utmpx.h ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤¿¤È¤­¤Ë¡¢ ÌäÂ꤬µ¯¤­¤ë ports ¤¬¤¢¤ê¤Þ¤¹¡£ ºÆµ¯Æ° ¿·¤·¤¤¥«¡¼¥Í¥ë¡¢world ¤½¤·¤ÆÀßÄê¥Õ¥¡¥¤¥ë¤¬¥í¡¼¥É¤µ¤ì¤¿¤Î¤Ç¡¢ ºÆµ¯Æ°¤¬É¬ÍפǤ¹¡£ - make delete-old-libs + make + delete-old-libs »È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¥é¥¤¥Ö¥é¥ê¤¬¿·¤·¤¤¥é¥¤¥Ö¥é¥ê¤È¶¥¹ç¤¹¤ë¤³¤È¤òÈò¤±¤ë¤¿¤áºï½ü¤·¤Þ¤¹¡£ ¸Å¤¤¥é¥¤¥Ö¥é¥ê¤òºï½ü¤¹¤ëÁ°¤Ë¤¹¤Ù¤Æ¤Î ports ¤òºÆ¹½ÃÛ¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¤â¤·¡¢&os; ¤Î¤¢¤ë¥Ö¥é¥ó¥Á¤Î¤¢¤ë¥ê¥ê¡¼¥¹¤«¤é¡¢ Ʊ¤¸¥Ö¥é¥ó¥Á¤ÎºÇ¿·¥ê¥ê¡¼¥¹¤Ë¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð (¤¿¤È¤¨¤Ð 9.0 ¤«¤é 9.1)¡¢ ¤³¤Î¼ê½ç¤Ë¤·¤¿¤¬¤ï¤Ê¤¯¤Æ¤âÎɤ¤¤Ç¤·¤ç¤¦¡£ ¤Ê¤¼¤Ê¤é¤Ð¡¢¥³¥ó¥Ñ¥¤¥é¡¢¥«¡¼¥Í¥ë¡¢¥æ¡¼¥¶¥é¥ó¥É¡¢¤½¤·¤ÆÀßÄê¥Õ¥¡¥¤¥ë¤Î´Ö¤Ç¡¢ ½ÅÅ٤Υߥ¹¥Þ¥Ã¥Á¤¬µ¯¤­¤ë¤³¤È¤Ï¤¢¤Þ¤ê¹Í¤¨¤é¤ì¤Ê¤¤¤¿¤á¤Ç¤¹¡£ ¥Þ¥¤¥Ê¡¼¤Ê¥¢¥Ã¥×¥Ç¡¼¥È¤Ç¤Ï¡¢¿·¤·¤¤¥«¡¼¥Í¥ë¤Î¹½Ãۤȥ¤¥ó¥¹¥È¡¼¥ë¸å¤Ë¡¢ ¸Å¤¤¥¢¥×¥í¡¼¥Á¤Ç¤¢¤ë make world ¤òÍѤ¤¤Æ¤â¤¦¤Þ¤¯¤¤¤¯¤Ç¤·¤ç¤¦¡£ ¥á¥¸¥ã¡¼¥ê¥ê¡¼¥¹¤ò¤Þ¤¿¤¤¤À¥¢¥Ã¥×¥Ç¡¼¥È¤Ç¤Ï¡¢ ¤³¤ÎÊýË¡¤òÍѤ¤¤Ê¤¤¤È¡¢²¿¤é¤«¤ÎÌäÂê¤Ë¤Ö¤Ä¤«¤ë¤Ç¤·¤ç¤¦¡£ Â礭¤Ê¥¢¥Ã¥×¥°¥ì¡¼¥É¤Ë¤ª¤¤¤Æ¤Ï¡¢ installworld ¤ÎÁ°¤ËÆÃÄê¤Î¥Õ¥¡¥¤¥ë¤Î̾Á°¤ÎÊѹ¹¤äºï½ü¤¹¤ë¤È¤¤¤Ã¤¿¡¢ ÆÃÊ̤ÊÄɲäΥ¹¥Æ¥Ã¥×¤¬É¬ÍפȤʤ뤳¤È¤¬¤¢¤ê¤Þ¤¹¡£ /usr/src/UPDATING ¤òÃí°Õ¿¼¤¯ÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ÆÃ¤Ë¥Õ¥¡¥¤¥ë¤ÎºÇ¸å¤Ë¤Ï¡¢ ¸½ºß¿ä¾©¤µ¤ì¤Æ¤¤¤ë¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î¼ê½ç¤¬¾Ü¤·¤¯Àµ³Î¤ËÀâÌÀ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤³¤Î¼ê³¤­¤Ï¡¢ ³«È¯¼Ô¤¿¤Á¤¬¤¢¤ë¼ï¤Î¥ß¥¹¥Þ¥Ã¥Á¤ò´°Á´¤ËÈò¤±¤ë¤¿¤á¤Ë¡¢Ä¹¤¤Ç¯·î¤ò¤«¤±¤Æ¿Ê²½¤·¤Æ¤­¤Þ¤·¤¿¡£ ´ê¤ï¤¯¤Ð¡¢¤³¤Î¸½ºß¤Î¼ê½ç¤¬Ä¹¤¤´Ö°ÂÄꤷ¤Æ¤Û¤·¤¤¤â¤Î¤Ç¤¹¡£ ¤Þ¤È¤á¤ë¤È¡¢¸½ºß¡¢¥½¡¼¥¹¤«¤é¤Î &os; ¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤Ë¤ª¤¤¤Æ¿ä¾©¤µ¤ì¤Æ¤¤¤ëÊýË¡¤Ï°Ê²¼¤È¤Ê¤ê¤Þ¤¹¡£ &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now ¤Þ¤ì¤Ë buildworld ¤ÎÁ°¤Ë mergemaster -p ¤ò;ʬ¤Ë¼Â¹Ô¤¹¤ë¤³¤È¤¬É¬Íפʾì¹ç¤¬¤¢¤ê¤Þ¤¹¡£¤½¤Î¾ì¹ç¤Ï UPDATING ¤Ë¤½¤¦½ñ¤«¤ì¤Æ¤¤¤Þ¤¹¡£ &os; ¤Î¥á¥¸¥ã¡¼¥Ð¡¼¥¸¥ç¥ó¤ò¤Þ¤¿¤¤¤Ç¹¹¿·¤¹¤ë¤Î¤Ç¤Ê¤±¤ì¤Ð¡¢ Ä̾ï¤Ï¤³¤Î¼ê½ç¤ò¾Êά¤·¤Æ¤â¤Ê¤ó¤éÌäÂê¤Ê¤¤¤Ç¤·¤ç¤¦¡£ installkernel ¤¬Ìµ»ö¤Ë½ªÎ»¤·¤¿¤é¡¢¥í¡¼¥À¤Î¥×¥í¥ó¥×¥È¤«¤é boot -s ¤ò»È¤Ã¤Æ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤ÇΩ¤Á¾å¤²¤Æ¤¯¤À¤µ¤¤¡£ ¤½¤ì¤«¤é¡¢°Ê²¼¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; adjkerntz -i &prompt.root; mergemaster -p &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; make delete-old &prompt.root; reboot &prompt.root; make delete-old-libs ¤³¤Î¸å¤ÎÀâÌÀ¤òÆÉ¤ó¤Ç¤¯¤À¤µ¤¤ ¤³¤Î¸å¤ÎÀá¤Ç¤Ï¤½¤ì¤¾¤ì¤Î¥¹¥Æ¥Ã¥×¤Ë¤Ä¤¤¤Æ¾Ü¤·¤¯ÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ ÆÃ¤Ë¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤òÍøÍѤ¹¤ë¾ì¹ç¤Ë¤Ä¤¤¤ÆÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ <filename>/usr/src/UPDATING</filename> ¤òÆÉ¤à ¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ëÁ°¤Ë¡¢ /usr/src/UPDATING ¤òÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¤³¤Î¥Õ¥¡¥¤¥ë¤Ë¤ÏÀøºßŪ¤ÊÌäÂê¤ä ÆÃÄê¤Î¥³¥Þ¥ó¥É¤Î½ç¤Ê¤É¤Î½ÅÍפʾðÊó¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ UPDATING ¤¬¤³¤ÎÀá¤Ë½ñ¤«¤ì¤Æ¤¤¤ë¤â¤Î¤ÈÌ·½â¤·¤Æ¤¤¤ë»þ¤Ï UPDATING ¤òÍ¥À褷¤Æ¤¯¤À¤µ¤¤¡£ UPDATING ¤òÆÉ¤à¤È¤¤¤¦¤³¤È¤Ï¡¢ ŬÀڤʥ᡼¥ê¥ó¥°¥ê¥¹¥È¤ò¹ØÆÉ¤¹¤ëÂå¤ï¤ê¤Ë¤Ï¤Ê¤ê¤Þ¤»¤ó¡£ Æó¤Ä¤ÎÍ×µá¤ÏÁêÊäŪ¤Ê¤â¤Î¤ÇÇÓ¾Ū¤Ê¤â¤Î¤Ç¤Ï¤Ê¤¤¤Î¤Ç¤¹¡£ <filename>/etc/make.conf</filename> ¤Î³Îǧ make.conf &man.make.1; ¤Î¥ª¥×¥·¥ç¥ó¤ÎÀâÌÀ¤Ï¡¢&man.make.conf.5; ¤ä /usr/share/examples/etc/make.conf ¤Ë¤¢¤ê¤Þ¤¹¡£ ¤³¤ì¤é¤ÎÀßÄê¤ò /etc/make.conf ¤ËÄɲ䷤ơ¢ &man.make.1; ¤Î¼Â¹Ô¤ä¥×¥í¥°¥é¥à¤Î¹½ÃÛÊýË¡¤òÀßÄꤷ¤Æ¤¯¤À¤µ¤¤¡£ ¤¢¤ëÀßÄê¤òÊѹ¹¤·¤¿¤³¤È¤Ë¤è¤ê¡¢±Æ¶Á¤¬¹­¤¤ÈϰϤˤª¤è¤Ó¡¢ ¶Ã¤¯¤Ù¤­·ë²Ì¤ò¤â¤¿¤é¤¹²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ ξÊý¤Î¥Õ¥¡¥¤¥ë¤Ë½ñ¤«¤ì¤Æ¤¤¤ë¥³¥á¥ó¥È¤òÆÉ¤à¤³¤È¤È¡¢ ¥Ç¥Õ¥©¥ë¥È¤ÎÀßÄê¤Ï¡¢¥Ñ¥Õ¥©¡¼¥Þ¥ó¥¹¤È°ÂÁ´À­¤Î´ÑÅÀ¤«¤éÁª¤Ð¤ì¤Æ¤¤¤ë¤³¤È¤ò³Ð¤¨¤Æ¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£ /etc/make.conf ¤ÇÀßÄꤵ¤ì¤¿¥ª¥×¥·¥ç¥ó¤Ï¡¢ &man.make.1; ¤¬»È¤ï¤ì¤ëºÝ¤Ë¤Ï¾ï¤ËÍ­¸ú¤È¤Ê¤ê¤Þ¤¹¡£ Ports Collection ¤«¤é¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤ò¥³¥ó¥Ñ¥¤¥ë¤¹¤ë»þ¡¢ ¥æ¡¼¥¶¤¬½ñ¤¤¤¿ C ¥×¥í¥°¥é¥à¤ä &os; ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤ò¹½ÃÛ¤¹¤ëºÝ¤Ë±Æ¶Á¤òµÚ¤Ü¤·¤Þ¤¹¡£ <filename>/etc/src.conf</filename> ¤ò³Îǧ¤¹¤ë src.conf /etc/src.conf ¤Ï¡¢ ¥½¡¼¥¹¥³¡¼¥É¤òÍѤ¤¤¿¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Î¹½ÃۤˤĤ¤¤Æ¥³¥ó¥È¥í¡¼¥ë¤·¤Þ¤¹¡£ /etc/make.conf ¤È¤Ï°Û¤Ê¤ê¡¢ /etc/src.conf ¤Ë½ñ¤«¤ì¤¿ÀßÄê¤Ï¡¢ &os; ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤½¤Î¤â¤Î¤ò¹½ÃÛ¤¹¤ë¤È¤­¤Ë¤Î¤ß±Æ¶Á¤·¤Þ¤¹¡£ ¤³¤Î¥Õ¥¡¥¤¥ë¤ÇÀßÄê²Äǽ¤Ê¿¤¯¤Î¥ª¥×¥·¥ç¥ó¤Ë¤Ä¤¤¤Æ¤Ï¡¢ &man.src.conf.5; ¤Ëµ­½Ò¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ °ì¸«¤·¤¿¤È¤³¤í̵¸ú¤Ë¤µ¤ì¤Æ¤¤¤ë¡¢ »È¤ï¤ì¤Æ¤¤¤Ê¤¤¥«¡¼¥Í¥ë¥â¥¸¥å¡¼¥ë¤ä¥Ó¥ë¥É¥ª¥×¥·¥ç¥ó¤ËÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤È¤­¤É¤­Í½´ü¤·¤Ê¤«¤Ã¤¿¤ê¡¢¤ï¤º¤«¤Ê±Æ¶Á¤òÍ¿¤¨¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ <filename>/etc</filename> ¤Ë¤¢¤ë¥Õ¥¡¥¤¥ë¤Î¹¹¿· /etc ¤Ë¤Ï¡¢ ¥·¥¹¥Æ¥àµ¯Æ°»þ¤Ë¼Â¹Ô¤µ¤ì¤ë¥¹¥¯¥ê¥×¥È¤À¤±¤Ç¤Ê¤¯¡¢ ¥·¥¹¥Æ¥à¤ÎÀßÄê¤Ë´ØÏ¢¤¹¤ë¾ðÊó¤ÎÂçÉôʬ¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤½¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Ë´Þ¤Þ¤ì¤ë¥¹¥¯¥ê¥×¥È¤Ï¡¢ &os; ¤Î¥Ð¡¼¥¸¥ç¥ó¤Ë¤è¤Ã¤ÆÂ¿¾¯°Û¤Ê¤ê¤Þ¤¹¡£ ÀßÄê¥Õ¥¡¥¤¥ë¤Î¤Ê¤«¤Ë¤Ï¡¢/etc/group ¤Î¤è¤¦¤Ë²ÔÆ¯Ãæ¤Î¥·¥¹¥Æ¥à¤¬Æü¡¹ÍøÍѤ·¤Æ¤¤¤ë¤â¤Î¤â¤¢¤ê¤Þ¤¹¡£ make installworld ¤Ë¤è¤ë¥¤¥ó¥¹¥È¡¼¥ë¤ÎÃʳ¬¤Ç¤Ï¡¢ ÆÃÄê¤Î¥æ¡¼¥¶Ì¾¡¢¤¢¤ë¤¤¤Ï¥°¥ë¡¼¥×¤¬Â¸ºß¤·¤Æ¤¤¤ë¤³¤È¤ò Í׵᤹¤ë¾ìÌ̤¬¤¢¤ê¤Þ¤¹¡£¥·¥¹¥Æ¥à¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤ò¹Ô¤Ê¤¦ºÝ¤Ë¤Ï¡¢ ¤½¤ì¤é¤Î¥æ¡¼¥¶Ì¾¤ä¥°¥ë¡¼¥×¤¬ºï½ü¡¢ ¤¢¤ë¤¤¤ÏÊѹ¹¤µ¤ì¤ÆÂ¸ºß¤·¤Æ¤¤¤Ê¤¤²ÄǽÀ­¤¬¹Í¤¨¤é¤ì¤Þ¤¹¡£ make buildworld ¤Ë¤ª¤¤¤Æ¡¢ ¤½¤ì¤é¤Î¥æ¡¼¥¶Ì¾¤ä¥°¥ë¡¼¥×¤¬Â¸ºß¤¹¤ë¤«³Îǧ¤¬¹Ô¤ï¤ì¤ë¾ì¹ç¤â¤¢¤ê¤Þ¤¹¡£ ²ò·èÊýË¡¤Ï¡¢buildworld ¤ÎÁ°¤Ë ¤ò¤Ä¤±¤Æ &man.mergemaster.8; ¤ò¼Â¹Ô¤¹¤ë¤³¤È¤Ç¤¹¡£ ¤³¤ì¤ò¼Â¹Ô¤¹¤ë¤È¡¢buildworld ¤ä installworld ¤¬À®¸ù¤¹¤ë¤¿¤á¤ËɬÍפʥե¡¥¤¥ë¤À¤±¤òÈæ³Ó¤·¤Þ¤¹¡£ ̾Á°¤òÊѹ¹¤·¤¿¤ê¡¢ºï½ü¤·¤Æ¤·¤Þ¤Ã¤¿¥°¥ë¡¼¥×¤¬½êÍ­¤·¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¤ò¡¢ ¼¡¤Î¤è¤¦¤Ë¤·¤ÆÄ´¤Ù¤ë¤³¤È¤â¤Ç¤­¤Þ¤¹¡£ &prompt.root; find / -group GID -print ¤³¤Î¥³¥Þ¥ó¥É¤Ï¥°¥ë¡¼¥×̾¤â¤·¤¯¤Ï¿ô»ú¤Ç¼¨¤µ¤ì¤ë¥°¥ë¡¼¥× ID ¤Ç»ØÄꤵ¤ì¤¿¥°¥ë¡¼¥× GID ¤¬½êÍ­¤¹¤ë¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤òɽ¼¨¤·¤Þ¤¹¡£ ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ø¤Î°Ü¹Ô ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É ¥³¥ó¥Ñ¥¤¥ë¤Ï¡¢¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ç¹Ô¤Ê¤¦¤³¤È¤ò¹Í¤¨¤Æ¤¯¤À¤µ¤¤¡£ ¥·¥¹¥Æ¥à¤ÎºÆ¥¤¥ó¥¹¥È¡¼¥ë¤Ï½ÅÍפʥ·¥¹¥Æ¥à¥Õ¥¡¥¤¥ë¡¢ ¤¹¤Ù¤Æ¤Îɸ½à¥·¥¹¥Æ¥à¤Î¥Ð¥¤¥Ê¥ê¡¢¥é¥¤¥Ö¥é¥ê¡¢¥¤¥ó¥¯¥ë¡¼¥É¥Õ¥¡¥¤¥ë¤òÁàºî¤·¤Þ¤¹¡£ ²ÔÆ¯Ãæ¤Î¥·¥¹¥Æ¥à¤Ë (ÆÃ¤Ë¾¤Î¥æ¡¼¥¶¤¬¤½¤Î¥·¥¹¥Æ¥à¤Ë¥í¥°¥¤¥ó¤·¤Æ¤¤¤ë»þ¤Ë) ¤½¤Î¤è¤¦¤ÊÊѹ¹¤ò²Ã¤¨¤ë¤³¤È¤Ï¡¢¥È¥é¥Ö¥ë¤ò°ú¤­µ¯¤³¤¹¸¶°ø¤È¤Ê¤ê¤Þ¤¹¡£ ¥Þ¥ë¥Á¥æ¡¼¥¶¥â¡¼¥É ¤â¤¦°ì¤Ä¤ÎÊýË¡¤È¤·¤Æ¡¢¥Þ¥ë¥Á¥æ¡¼¥¶¥â¡¼¥É¤Ç¥·¥¹¥Æ¥à¤òºÆ¹½ÃÛ¤·¤Æ¡¢ ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ë°Ü¹Ô¤·¤Æ¤«¤é¤½¤ì¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¡¢ ¤È¤¤¤¦¤Î¤¬¤¢¤ê¤Þ¤¹¡£¤â¤·¤³¤Î¤è¤¦¤ÊÊýË¡¤Ç¹Ô¤Ê¤¤¤¿¤¤¾ì¹ç¤Ï¡¢ °Ê²¼¤Î¼ê½ç¤ò¹½ÃÛ¤¬´°Î»¤¹¤ë¤È¤³¤í¤Þ¤ÇÈô¤Ð¤·¤Æ¤¯¤À¤µ¤¤¡£ installkernel ¤â¤·¤¯¤Ï installworld ¤ò¼Â¹Ô¤¹¤ëºÝ¤Ë¡¢ ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ë°Ü¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; shutdown now ¤¢¤ë¤¤¤Ï¥·¥¹¥Æ¥à¤òºÆµ¯Æ°¤·¡¢¥Ö¡¼¥È¥×¥í¥ó¥×¥È¤«¤é single user ¥ª¥×¥·¥ç¥ó¤òÁªÂò¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Çµ¯Æ°¤·¤¿¸å¤Ï¡¢ ¥·¥§¥ë¥×¥í¥ó¥×¥È¤«¤é¼¡¤Î¤è¤¦¤Ë¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a ¤³¤ì¤Ï¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ò¥Á¥§¥Ã¥¯¤·¤¿¸å¡¢ / ¤òÆÉ¤ß½ñ¤­²Äǽ¤Ë¤·¤ÆºÆ¥Þ¥¦¥ó¥È¡¢ /etc/fstab ¤Ë»ØÄꤵ¤ì¤Æ¤¤¤ë¡¢ ¤½¤ì°Ê³°¤Î UFS ¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ò¤¹¤Ù¤Æ¥Þ¥¦¥ó¥È¤·¤Æ¤«¤é ¥¹¥ï¥Ã¥×¤òÍ­¸ú¤Ë¤·¤Þ¤¹¡£ CMOS ¥¯¥í¥Ã¥¯¤¬Ãϰè»þ´Ö¤ËÀßÄꤵ¤ì¤Æ¤¤¤Æ GMT ¤Ç¤Ï¤Ê¤¤¾ì¹ç (&man.date.1; ¤¬Àµ¤·¤¤»þ´Ö¤ÈÃϰè¤òɽ¼¨¤·¤Ê¤¤¤Ê¤éÅö¤Æ¤Ï¤Þ¤ê¤Þ¤¹)¡¢ ¼¡¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤¹¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; adjkerntz -i ¤³¤¦¤¹¤ì¤Ð¡¢ ³Î¼Â¤ËÃϰè»þ¹ï¤¬Àµ¤·¤¯ÀßÄꤵ¤ì¤Þ¤¹¡£ <filename>/usr/obj</filename> ¤Îºï½ü ¥·¥¹¥Æ¥à¤¬ºÆ¹½ÃÛ¤µ¤ì¤ë»þ¡¢¹½ÃÛ¤µ¤ì¤¿¤â¤Î¤Ï¥Ç¥Õ¥©¥ë¥È¤Ç /usr/obj °Ê²¼¤Î¥µ¥Ö¥Ç¥£¥ì¥¯¥È¥ê¤Ë³ÊǼ¤µ¤ì¤Þ¤¹¡£ ¤½¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Î²¼¤Ï /usr/src ¤ÈƱ¤¸¹½Â¤¤È¤Ê¤ê¤Þ¤¹¡£ ¤â¤·¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê¤¬Â¸ºß¤·¤Æ¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê¤òºï½ü¤·¤Æ¡¢ make buildworld ¤Î¹ÔÄø¤Ë¤«¤«¤ë»þ´Ö¤òû½Ì¤·¡¢ °Í¸ÌäÂê¤ËǺ¤Þ¤µ¤ì¤ë¤è¤¦¤Ê¥È¥é¥Ö¥ë¤ò²óÈò¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ /usr/obj °Ê²¼¤Î¥Õ¥¡¥¤¥ë¤Ë¤Ï¡¢Êѹ¹ÉÔ²Ä (immutable) ¥Õ¥é¥°¤¬¥»¥Ã¥È¤µ¤ì¤Æ¤¤¤ë¤â¤Î¤¬¤¢¤ë²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ ¤³¤Î¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤ÏºÇ½é¤Ë &man.chflags.1; ¤òÍѤ¤¤Æ¤«¤éºï½ü¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * ¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤ÎºÆ¹½ÃÛ ½ÐÎÏ¥á¥Ã¥»¡¼¥¸¤ÎÊݸ ¼Â¹Ô¤µ¤ì¤ë &man.make.1; ¤«¤é¤Î½ÐÎϤϡ¢¥Õ¥¡¥¤¥ë¤ËÊݸ¤¹¤ë¤ÈÎɤ¤¤Ç¤·¤ç¤¦¡£ ¤â¤·¡¢²¿¤«¾ã³²¤¬È¯À¸¤·¤¿¾ì¹ç¡¢¥¨¥é¡¼¥á¥Ã¥»¡¼¥¸¤Î¥³¥Ô¡¼¤ò &os; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ËÅê¹Æ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥Õ¥¡¥¤¥ë¤ËÊݸ¤¹¤ëºÇ¤â´Êñ¤ÊÊýË¡¤Ï¡¢&man.script.1; ¥³¥Þ¥ó¥É¤ò»È¤¤¡¢°ú¿ô¤Ë½ÐÎϤòÊݸ¤·¤¿¤¤¥Õ¥¡¥¤¥ë̾¤ò»ØÄꤹ¤ë¤³¤È¤Ç¤¹¡£ ¤³¤ì¤ò make world ¤ÎľÁ°¤Ë¹Ô¤Ê¤¤¡¢ºÆ¹½ÃÛ¤¬½ªÎ»¤·¤¿¤é °Ê²¼¤Î¤è¤¦¤Ë exit ¤ÈÆþÎϤ·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … /tmp ¤Ë½ÐÎϤòÊݸ¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£ ¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Ï¡¢¼¡¤ÎºÆµ¯Æ°¤Çºï½ü¤µ¤ì¤Æ¤·¤Þ¤¦²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£ ½ÐÎϤÎÊݸ¤Ë¤Ï¡¢/var/tmp ¤ä root ¤Î¥Û¡¼¥à¥Ç¥£¥ì¥¯¥È¥ê¤¬Å¬¤·¤Æ¤¤¤Þ¤¹¡£ ¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤Î¹½ÃÛ /usr/src ¤Ë¤Æ¡¢ ¼¡¤Î¤è¤¦¤Ë¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/src make world ¤òºÆ¹½ÃÛ¤¹¤ë¤Ë¤Ï¡¢&man.make.1; ¤ò»ÈÍѤ·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Î¥³¥Þ¥ó¥É¤Ï¡¢Makefile ¤«¤é¡¢ &os; ¤ò¹½À®¤¹¤ë¥×¥í¥°¥é¥à¤ÎºÆ¹½ÃÛÊýË¡¤ä¡¢ ¤É¤¦¤¤¤¦½çÈ֤Ǥ½¤ì¤é¤ò¹½ÃÛ¤¹¤Ù¤­¤«¤È¤¤¤Ã¤¿¤è¤¦¤Ê»Ø¼¨¤òÆÉ¤ß¹þ¤ß¤Þ¤¹¡£ ¥³¥Þ¥ó¥É¥é¥¤¥ó¤Î°ìÈÌŪ¤Ê½ñ¼°¤Ï¡¢¼¡¤Î¤È¤ª¤ê¤Ç¤¹¡£ &prompt.root; make -x -DVARIABLE target ¤³¤ÎÎã¤Ç¤Ï¡¢ ¤¬ &man.make.1; ¤ËÅϤµ¤ì¤ë¥ª¥×¥·¥ç¥ó¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤É¤Î¤è¤¦¤Ê¥ª¥×¥·¥ç¥ó¤¬ÍøÍѤǤ­¤ë¤«¤Ë¤Ä¤¤¤Æ¤Ï¡¢&man.make.1; ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤Ï¡¢ Makefile ¤ËÅϤµ¤ì¤ëÊÑ¿ô¤Ç¤¢¤ê¡¢ ¤³¤ÎÊÑ¿ô¤Ï Makefile ¤Îưºî¤ò¥³¥ó¥È¥í¡¼¥ë¤·¤Þ¤¹¡£ ¤Þ¤¿¡¢/etc/make.conf ¤ÇÀßÄꤵ¤ì¤ëÊÑ¿ô¤â ƱÍͤǤ¹¡£¤³¤ì¤ÏÊÑ¿ô¤òÀßÄꤹ¤ë¤â¤¦°ì¤Ä¤ÎÊýË¡¤È¤·¤ÆÍѰդµ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð°Ê²¼¤ÎÄ̤ê¤Ç¤¹¡£ &prompt.root; make -DNO_PROFILE target ¤Ï¡¢¥×¥í¥Õ¥¡¥¤¥ëÈǤΥ饤¥Ö¥é¥ê¤ò¹½ÃÛ¤·¤Ê¤¤¤³¤È¤ò»ØÄꤹ¤ë ¤â¤¦°ì¤Ä¤Îµ­Ë¡¤Ç¡¢/etc/make.conf Ãæ¤Î NO_PROFILE= true # Avoid compiling profiled libraries ¤Î¹Ô¤ËÂбþ¤·¤Þ¤¹¡£ target ¤Ï¡¢&man.make.1; ¤Ë ¤É¤Î¤è¤¦¤Ëưºî¤¹¤ë¤Î¤«¤ò»Ø¼¨¤¹¤ë¤¿¤á¤Î¤â¤Î¤Ç¤¹¡£ ³Æ Makefile ¤Ë¤Ï¡¢¿ô¿¤¯¤Î°Û¤Ê¤ë ¥¿¡¼¥²¥Ã¥È (target) ¤¬ÄêµÁ¤µ¤ì¤Æ¤¤¤Æ¡¢ »ØÄꤵ¤ì¤¿¥¿¡¼¥²¥Ã¥È¤Ë¤è¤Ã¤ÆÆ°ºî¤¬·è¤Þ¤ê¤Þ¤¹¡£ Makefile ¤Ë½ñ¤«¤ì¤Æ¤¤¤ë¥¿¡¼¥²¥Ã¥È¤Ë¤Ï¡¢ ¥·¥¹¥Æ¥à¤ÎºÆ¹½ÃÛ¤ËɬÍפÊÃʳ¬¤ò¡¢ ¿¤¯¤Î¤µ¤é¤ËºÙ¤«¤¤Ãʳ¬¤Ëʬ³ä¤¹¤ë¤¿¤á¡¢ ¹½ÃۤβáÄø¤ÇÍøÍѤµ¤ì¤ë¤â¤Î¤¬¤¢¤ê¤Þ¤¹¡£ ÂçÄñ¤Î¾ì¹ç¡¢&man.make.1; ¤Ë¥Ñ¥é¥á¡¼¥¿¤ò»ØÄꤹ¤ëɬÍפϤʤ¤¤Ç¤·¤ç¤¦¤«¤é¡¢ ¥³¥Þ¥ó¥É¥é¥¤¥ó¤Ï¼¡¤Î¤è¤¦¤Ê¤â¤Î¤Ë¤Ê¤ê¤Þ¤¹¡£ &prompt.root; make target ¤³¤³¤Ç¡¢target ¤Ï¡¢Â¿¤¯¤Î¥Ó¥ë¥É¥ª¥×¥·¥ç¥ó¤Î¤É¤ì¤«¤Ë¤Ê¤ê¤Þ¤¹¡£ ºÇ½é¤Î¥¿¡¼¥²¥Ã¥È¤Ï¤¤¤Ä¤â buildworld ¤Ë¤Ê¤ë¤Ç¤·¤ç¤¦¡£ ¤½¤Î̾Á°¤¬¼¨¤¹¤è¤¦¤Ë¡¢buildworld ¤Ï /usr/obj °Ê²¼¤Ë¿·¤·¤¤´°Á´¤Ê¥Ç¥£¥ì¥¯¥È¥ê¥Ä¥ê¡¼¤ò¹½ÃÛ¤·¡¢ installworld ¤Ï¡¢¤½¤Î¥Ä¥ê¡¼¤ò ¸½ºß¤Î¥Þ¥·¥ó¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤·¤Þ¤¹¡£ ÁªÂò»è¤¬Ê¬¤±¤é¤ì¤Æ¤¤¤ë¤³¤È¤Ï¡¢Æó¤Ä¤ÎÍýͳ¤«¤éÍ­ÍѤǤ¹¡£ ¤Þ¤ºÂè°ì¤Ë¡¢¹½ÃÛºî¶È¤Ï ²¿¤Ë¤â°Í¸¤»¤ºÆÈΩ¤·¤Æ¹Ô¤Ê¤ï¤ì¡¢ ²ÔÆ¯Ãæ¤Î¥·¥¹¥Æ¥à¤Ë¤Þ¤Ã¤¿¤¯±Æ¶Á¤òÍ¿¤¨¤Þ¤»¤ó¡£ ¤½¤Î¤¿¤á¡¢¥Þ¥ë¥Á¥æ¡¼¥¶¥â¡¼¥É¤Ç²ÔÆ¯Ãæ¤Î¥·¥¹¥Æ¥à¤Ç¤â¡¢²¿°ì¤Ä °­±Æ¶Á¤òÍ¿¤¨¤º¤Ë buildworld ¤ò ¼Â¹Ô¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤¿¤À¤·¡¢installworld ¤Ï ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ç¹Ô¤Ê¤¦¤³¤È¤ò¤ª¤¹¤¹¤á¤·¤Þ¤¹¡£ ÂèÆó¤Ë¡¢NFS ¥Þ¥¦¥ó¥È¤òÍøÍѤ¹¤ë¤³¤È¤Ç¡¢ ¥Í¥Ã¥È¥ï¡¼¥¯¾å¤ÎÊ£¿ô¤Î¥Þ¥·¥ó¤ò¥¢¥Ã¥×¥°¥ì¡¼¥É¤¹¤ë¤³¤È¤¬²Äǽ¤ÊÅÀ¤¬¤¢¤²¤é¤ì¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð»°Âæ¤Î¥Þ¥·¥ó¡¢ A, B, C ¤ò¥¢¥Ã¥×¥°¥ì¡¼¥É¤·¤¿¤¤¾ì¹ç¤Ë¤Ï¡¢¤Þ¤º¥Þ¥·¥ó A ¤Ç make buildworld ¤È make installworld ¤ò¼Â¹Ô¤·¤Þ¤¹¡£ ¤½¤ì¤«¤é¡¢¥Þ¥·¥ó B ¤È¥Þ¥·¥ó C ¤Ç¥Þ¥·¥ó A ¤Î /usr/src ¤È /usr/obj ¤ò NFS ¥Þ¥¦¥ó¥È¤·¡¢make installworld ¤È¤¹¤ë¤³¤È¤Ç¹½ÃۺѤߤΥ·¥¹¥Æ¥à¤ò³Æ¥Þ¥·¥ó¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤­¤Þ¤¹¡£ world ¥¿¡¼¥²¥Ã¥È¤âÍøÍѲÄǽ¤Ç¤¹¤¬¡¢ ¤³¤Î¥¿¡¼¥²¥Ã¥È¤ÎÍøÍѤϿ侩¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£ ¤½¤Î¤«¤ï¤ê¡¢¼¡¤Î¥³¥Þ¥ó¥É &prompt.root; make buildworld ¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£¤³¤³¤Ç make ¤Ë ¤ò¤Ä¤±¤ë¤È¡¢ Ʊ»þ¤ËÊ£¿ô¤Î¥×¥í¥»¥¹¤òÀ¸À®¤Ç¤­¤Þ¤¹¡£ ¤³¤Îµ¡Ç½¤Ï¥Þ¥ë¥Á CPU ¥Þ¥·¥ó¤ÇÆÃ¤Ë¸ú²Ì¤òȯ´ø¤·¤Þ¤¹¡£ ¹½ÃÛ²áÄø¤ÎÂçÉôʬ¤Ç¤Ï CPU À­Ç½¤Î¸Â³¦¤è¤ê I/O À­Ç½¤Î¸Â³¦¤ÎÊý¤¬ÌäÂê¤È¤Ê¤ë¤¿¤á¡¢¥·¥ó¥°¥ë CPU ¥Þ¥·¥ó¤Ë¤â¸ú²Ì¤¬¤¢¤ê¤Þ¤¹¡£ ÉáÄ̤Υ·¥ó¥°¥ë CPU ¥Þ¥·¥ó¤Ç°Ê²¼¤Î¥³¥Þ¥ó¥É &prompt.root; make -j4 buildworld ¤ò¼Â¹Ô¤¹¤ë¤È¡¢&man.make.1; ¤ÏºÇÂç 4 ¸Ä¤Þ¤Ç¤Î¥×¥í¥»¥¹¤òƱ»þ¤Ë¼Â¹Ô¤·¤Þ¤¹¡£ ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ËÅê¹Æ¤µ¤ì¤¿·Ð¸³Åª¤ÊÊó¹ð¤Ë¤è¤ë¤È¡¢ 4 ¸Ä¤È¤¤¤¦»ØÄ꤬ºÇ¤âÎɤ¤¥Ñ¥Õ¥©¡¼¥Þ¥ó¥¹¤ò¼¨¤¹¤è¤¦¤Ç¤¹¡£ ¤â¤·¡¢Ê£¿ô¤Î CPU ¤òÈ÷¤¨¤¿¥Þ¥·¥ó¤Ç SMP ÀßÄ꤬¹Ô¤Ê¤ï¤ì¤¿¥«¡¼¥Í¥ë¤ò ÍøÍѤ·¤Æ¤¤¤ë¤Ê¤é¡¢6 ¤«¤é 10 ¤Î´Ö¤ÎÃͤòÀßÄꤷ¡¢Â®ÅÙ¤¬¤É¤ì¤¯¤é¤¤ ¸þ¾å¤¹¤ë¤«³Îǧ¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£ ¥·¥¹¥Æ¥à¤Î¹½Ãۤˤ«¤«¤ë»þ´Ö world ¤ÎºÆ¹½ÃÛ »þ´Ö ¹½ÃÛ»þ´Ö¤ò·è¤á¤ëÍ×ÁǤϤµ¤Þ¤¶¤Þ¤¢¤ê¤Þ¤¹¤¬¡¢ ½½Ê¬¿·¤·¤¤¥Þ¥·¥ó¤Ç¤¢¤ì¤Ð¡¢ ¥È¥ê¥Ã¥¯¤ä¶áÆ»¤ò»È¤ï¤º¤ËÉáÄ̤˹½ÃÛ¤·¤¿¾ì¹ç¡¢&os.stable; ¤Î¹½ÃÛ¤Ë¤Ï 1, 2 »þ´Ö¤·¤«¤«¤«¤é¤Ê¤¤¤Ç¤·¤ç¤¦¡£ &os.current; ¤Î¹½Ãۤϡ¢¤â¤¦¾¯¤·»þ´Ö¤¬¤«¤«¤ê¤Þ¤¹¡£ ¿·¤·¤¤¥«¡¼¥Í¥ë¤Î¹½Ãۤȥ¤¥ó¥¹¥È¡¼¥ë ¥«¡¼¥Í¥ë (kernel) ¹½ÃÛ¡¢¥³¥ó¥Ñ¥¤¥ë ¿·¤·¤¤¥·¥¹¥Æ¥à¤ÎÁ´µ¡Ç½¤ò´°Á´¤ËÍøÍѤǤ­¤ë¤è¤¦¤Ë¤¹¤ë¤Ë¤Ï¡¢ ¥«¡¼¥Í¥ë¤òºÆ¹½ÃÛ¤·¤Æ¤¯¤À¤µ¤¤¡£ ºÆ¹½Ãۤϡ¢¤¢¤ë¼ï¤Î¥á¥â¥ê¹½Â¤ÂΤ¬Êѹ¹¤µ¤ì¤¿»þ¤Ë¤ÏÆÃ¤Ëɬ¿Ü¤Ç¤¢¤ê¡¢ &man.ps.1; ¤ä &man.top.1; ¤Î¤è¤¦¤Ê¥×¥í¥°¥é¥à¤Ï¡¢ ¥«¡¼¥Í¥ë¤È¥½¡¼¥¹¥³¡¼¥É¤Î¥Ð¡¼¥¸¥ç¥ó¤¬°ìÃפ·¤Ê¤¤¤ÈÀµ¾ï¤Ëưºî¤·¤Ê¤¤¤Ç¤·¤ç¤¦¡£ ºÇ¤â´Êñ¤Ç°ÂÁ´¤Ë¥«¡¼¥Í¥ë¤ÎºÆ¹½ÃÛ¤ò¹Ô¤Ê¤¦ÊýË¡¤Ï¡¢ GENERIC ¤ò»È¤Ã¤¿¥«¡¼¥Í¥ë¤ò¹½ÃÛ¡¦¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤³¤È¤Ç¤¹¡£ GENERIC ¤Ë¤Ï¤¢¤Ê¤¿¤¬É¬ÍפȤ¹¤ë¥Ç¥Ð¥¤¥¹¤¬¤¹¤Ù¤Æ´Þ¤Þ¤ì¤Æ¤¤¤Ê¤¤ ¤«¤âÃΤì¤Þ¤»¤ó¤¬¡¢¤¢¤Ê¤¿¤Î¥·¥¹¥Æ¥à¤ò¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ç µ¯Æ°¤µ¤»¤ë¤Î¤ËɬÍפʤâ¤Î¤Ï¤¹¤Ù¤ÆÆþ¤Ã¤Æ¤¤¤Þ¤¹¡£ ¤³¤ì¤Ï¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤Î¥·¥¹¥Æ¥à¤¬¤­¤Á¤ó¤Èưºî¤¹¤ë¤«¤É¤¦¤« Ä´¤Ù¤ëÎɤ¤ÊýË¡¤Î°ì¤Ä¤Ç¤¹¡£ GENERIC ¤Çµ¯Æ°¤·¤Æ¡¢ ¥·¥¹¥Æ¥à¤¬Àµ¾ï¤Ëưºî¤·¤Æ¤¤¤ë¤«¤É¤¦¤«¤ò³Î¤«¤á¤¿¤é¡¢ ¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤ò»È¤Ã¤Æ¿·¤·¤¤¥«¡¼¥Í¥ë¤ò¹½ÃÛ¤·¤Æ¤¯¤À¤µ¤¤¡£ &os; ¤Ç¤Ï¡¢¿·¤·¤¤¥«¡¼¥Í¥ë¤ò¹½ÃÛ¤¹¤ëÁ°¤Ë build world ¤ò¹Ô¤¦¤³¤È¤¬½ÅÍפǤ¹¡£ ´û¤Ë¤¢¤ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤ò»È¤Ã¤Æ¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤ò¹½ÃÛ¤¹¤ë¤Ë¤Ï¡¢ KERNCONF=MYKERNEL ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MYKERNEL &prompt.root; make installkernel KERNCONF=MYKERNEL kern.securelevel ¤ò 1 ¤è¤êÂ礭¤¯¤·¤Æ¤¤¤Æ¡¢ ¤«¤Ä ¥«¡¼¥Í¥ë¤Î¥Ð¥¤¥Ê¥ê¥Õ¥¡¥¤¥ë¤Ë noschg ¤Î¤è¤¦¤Ê¥Õ¥é¥°¤òÀßÄꤷ¤Æ¤¤¤ë¾ì¹ç¤Ï¡¢ installkernel ¤ò¹Ô¤¦¤Î¤Ë¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ë°Ü¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤½¤ì°Ê³°¤Î¾ì¹ç¤Ï¡¢ ¥Þ¥ë¥Á¥æ¡¼¥¶¥â¡¼¥É¤Ç¤³¤ì¤é¤Î¥³¥Þ¥ó¥É¤òÌäÂê¤Ê¤¯Æ°¤«¤»¤ë¤Ï¤º¤Ç¤¹¡£ kern.securelevel ¤Ë¤Ä¤¤¤Æ¾Ü¤·¤¯¤Ï &man.init.8; ¤ò¡¢¥Õ¥¡¥¤¥ë¤ÎÍÍ¡¹¤Ê¥Õ¥é¥°¤Ë¤Ä¤¤¤Æ¾Ü¤·¤¯¤Ï &man.chflags.1; ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤ÇºÆµ¯Æ°¤¹¤ë single-user mode ¿·¤·¤¤¥«¡¼¥Í¥ë¤¬Æ°ºî¤¹¤ë¤«¤É¤¦¤«¥Æ¥¹¥È¤¹¤ë¤¿¤á¤Ë¡¢ ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤ÇºÆµ¯Æ°¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ç¤Îµ¯Æ°¤Ï¡¢ ¤Ë½ñ¤«¤ì¤Æ¤¤¤ë¼ê½ç¤Ë½¾¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¿·¤·¤¤¥·¥¹¥Æ¥à¥Ð¥¤¥Ê¥ê¤Î¥¤¥ó¥¹¥È¡¼¥ë ¼¡¤Ë¡¢installworld ¤ò»È¤Ã¤Æ¿·¤·¤¤¥·¥¹¥Æ¥à¥Ð¥¤¥Ê¥ê¤Î¥¤¥ó¥¹¥È¡¼¥ë¤ò¹Ô¤Ê¤¤¤Þ¤¹¡£ &prompt.root; cd /usr/src &prompt.root; make installworld make buildworld ¤ËÊÑ¿ô¤ò»ØÄꤷ¤¿¾ì¹ç¤Ï¡¢Æ±¤¸»ØÄê¤ò make installworld ¤Ë¤â»ØÄꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ¤¿¤À¤· ¤Ï installworld ¤ÇÀäÂФ˻ȤäƤϤ¤¤±¤Þ¤»¤ó¡£ ¤¿¤È¤¨¤Ð°Ê²¼¤Î¤è¤¦¤Ë¼Â¹Ô¤·¤¿¤Ê¤é¡¢ &prompt.root; make -DNO_PROFILE buildworld °Ê²¼¤Î¤è¤¦¤Ë¤·¤Æ¥¤¥ó¥¹¥È¡¼¥ë¤·¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ &prompt.root; make -DNO_PROFILE installworld ¤â¤·¤½¤¦¤·¤Ê¤«¤Ã¤¿¾ì¹ç¡¢ make buildworld ¤ÎÃʳ¬¤Ç¹½ÃÛ¤µ¤ì¤Æ¤¤¤Ê¤¤ ¥×¥í¥Õ¥¡¥¤¥ëÈǥ饤¥Ö¥é¥ê¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤è¤¦¤È¤·¤Æ¤·¤Þ¤¦¤Ç¤·¤ç¤¦¡£ <command>make installworld</command> ¤Ç¹¹¿·¤µ¤ì¤Ê¤¤¥Õ¥¡¥¤¥ë¤Î¹¹¿· ¥·¥¹¥Æ¥à¤ÎºÆ¹½Ãۤϡ¢¤¤¤¯¤Ä¤«¤Î¥Ç¥£¥ì¥¯¥È¥ê¡¢ ÆÃ¤Ë¡¢/etc ¤ä /var ¤ä /usr ¤Ë¤ª¤¤¤Æ¡¢ ¿·µ¬¤ËƳÆþ¤µ¤ì¤¿¤ê¡¢Êѹ¹¤µ¤ì¤¿ÀßÄê¥Õ¥¡¥¤¥ë¤Ë¤è¤ë ¥Õ¥¡¥¤¥ë¤Î¹¹¿·¤Ï¹Ô¤Ê¤ï¤ì¤Þ¤»¤ó¡£ ¤³¤ì¤é¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Î¥Õ¥¡¥¤¥ë¤ò¹¹¿·¤¹¤ë¤â¤Ã¤È¤â´Êñ¤ÊÊýË¡¤Ï¡¢ &man.mergemaster.8; ¤ò»È¤¦¤³¤È¤Ç¤¹¡£ ɬ¤º /etc ¤Î¥Ð¥Ã¥¯¥¢¥Ã¥×¤ò¼è¤Ã¤ÆÉÔ¬¤Î»öÂÖ¤ËÈ÷¤¨¤Æ¤¯¤À¤µ¤¤¡£ Tom Rhodes ´ó¹Æ: <command>mergemaster</command> mergemaster &man.mergemaster.8; ¤Ï Bourne ¥·¥§¥ë¥¹¥¯¥ê¥×¥È¤Ç¡¢ /etc ¤Ë¤¢¤ëÀßÄê¥Õ¥¡¥¤¥ë¤È¥½¡¼¥¹¥Ä¥ê¡¼¤Î /usr/src/etc ¤Ë¤¢¤ëÀßÄê¥Õ¥¡¥¤¥ë¤Î°ã¤¤¤ò³Îǧ¤¹¤ë¤Î¤ò¼êÅÁ¤Ã¤Æ¤¯¤ì¤Þ¤¹¡£ ¤³¤ì¤ò»È¤¦¤Î¤¬¡¢¥½¡¼¥¹¥Ä¥ê¡¼¤Ë¤¢¤ëÀßÄê¥Õ¥¡¥¤¥ë¤Ë¥·¥¹¥Æ¥à¤ÎÀßÄê¥Õ¥¡¥¤¥ë¤ò ¹¹¿·¤¹¤ë¤¿¤á¤Ë¿ä¾©¤µ¤ì¤ëÊýË¡¤Ç¤¹¡£ »Ï¤á¤ë¤Ë¤Ï¡¢¥×¥í¥ó¥×¥È¤«¤é mergemaster ¤ÈÆþÎϤ·¤Æ¤¯¤À¤µ¤¤ mergemaster ¤Ï / ¤òµ¯ÅÀ¤È¤·¤¿°ì»þŪ¤Ê¥ë¡¼¥È´Ä¶­¤ò¹½ÃÛ¤·¡¢ ¤µ¤Þ¤¶¤Þ¤Ê¥·¥¹¥Æ¥àÀßÄê¥Õ¥¡¥¤¥ë¤ò (ÌõÃí: ¥Ç¥Õ¥©¥ë¥È¤Ç¤Ï /var/tmp/temproot ¤Ë) ÃÖ¤¤¤Æ¤¤¤­¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤Ï¸½ºß¥·¥¹¥Æ¥à¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¤ÈÈæ³Ó¤µ¤ì¤Þ¤¹¡£ °Û¤Ê¤ë¥Õ¥¡¥¤¥ë¤Ï &man.diff.1; ·Á¼°¤Ç¼¨¤µ¤ì¡¢ ¤Îµ­¹æ¤ÏÄɲäޤ¿¤ÏÊѹ¹¤µ¤ì¤¿¹Ô¤òɽ¤·¡¢ ¤Ï´°Á´¤Ëºï½ü¤µ¤ì¤¿¤«¿·¤·¤¯ÃÖ¤­´¹¤¨¤é¤ì¤¿¹Ô¤òɽ¤·¤Þ¤¹¡£ &man.diff.1; ¤Î½ñ¼°¤È¥Õ¥¡¥¤¥ë¤Î°ã¤¤¤Îɽ¼¨ÊýË¡¤Ë¤Ä¤¤¤Æ¤Î¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ï¡¢ &man.diff.1; ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ &man.mergemaster.8; ¤Ï°ã¤¤¤Î¤¢¤ë¥Õ¥¡¥¤¥ë¤ò¤½¤ì¤¾¤ì¼¨¤·¤Þ¤¹¡£ ¿·¤·¤¤¥Õ¥¡¥¤¥ë¤òºï½ü¤¹¤ë¤«¡¢ °ì»þ¥Õ¥¡¥¤¥ë¤ò¤½¤Î¤Þ¤Þ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤«¡¢ °ì»þ¥Õ¥¡¥¤¥ë¤È¸½ºß¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¤òÅý¹ç¤¹¤ë¤«¡¢ ¤â¤·¤¯¤Ï &man.diff.1; ¤Î·ë²Ì¤ò¤â¤¦°ìÅÙ¸«¤ë¤«ÁªÂò¤Ç¤­¤Þ¤¹¡£ °ì»þ¥Õ¥¡¥¤¥ë¤Îºï½ü¤òÁª¤Ö¤È¡¢&man.mergemaster.8; ¤Ë¸½ºß¤Î¥Õ¥¡¥¤¥ë¤òÊѹ¹¤·¤Ê¤¤¤Ç¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤òºï½ü¤»¤è¤ÈÅÁ¤¨¤Þ¤¹¡£ ¤³¤ÎÁªÂò¤Ï¡¢¸½ºß¤Î¥Õ¥¡¥¤¥ë¤òÊѹ¹¤¹¤ëÍýͳ¤¬Ê¬¤«¤é¤Ê¤¤¤Î¤Ç¤¢¤ì¤Ð¡¢ ¤ª´«¤á¤Ç¤­¤Þ¤»¤ó¡£ &man.mergemaster.8; ¤Î¥×¥í¥ó¥×¥È¤Ç ? ¤È¥¿¥¤¥×¤¹¤ì¤Ð¡¢ ¤¤¤Ä¤Ç¤â¥Ø¥ë¥×¤¬¸«¤é¤ì¤Þ¤¹¡£ ¥Õ¥¡¥¤¥ë¤Î¥¹¥­¥Ã¥×¤òÁª¤Ö¤È¡¢Â¾¤Î¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤ò½ª¤¨¤¿¤¢¤È¡¢ ¤â¤¦°ìÅÙ¤½¤Î¥Õ¥¡¥¤¥ë¤¬Ä󼨤µ¤ì¤Þ¤¹¡£ °ì»þ¥Õ¥¡¥¤¥ë¤ò¤½¤Î¤Þ¤Þ¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤³¤È¤òÁª¤Ö¤È¡¢ ¸½ºß¤Î¥Õ¥¡¥¤¥ë¤ò¿·¤·¤¤¥Õ¥¡¥¤¥ë¤ÇÃÖ¤­´¹¤¨¤Þ¤¹¡£ ¤Û¤È¤ó¤É¤Î¼ê¤ò²Ã¤¨¤Æ¤¤¤Ê¤¤¥Õ¥¡¥¤¥ë¤Ï¡¢ ¤³¤ì¤¬°ìÈ֤褤ÁªÂò¤Ç¤¹¡£ ¥Õ¥¡¥¤¥ë¤ÎÅý¹ç¤òÁª¤ó¤À¾ì¹ç¡¢ ¥Æ¥­¥¹¥È¥¨¥Ç¥£¥¿¤¬µ¯Æ°¤µ¤ì¡¢Î¾Êý¤Î¥Õ¥¡¥¤¥ë¤ÎÃæ¿È¤¬Ä󼨤µ¤ì¤Þ¤¹¡£ ²èÌ̾å¤ËʤÖξÊý¤Î¥Õ¥¡¥¤¥ë¤ò¸«¤Æ¿·¤·¤¤¥Õ¥¡¥¤¥ë¤òºîÀ®¤¹¤ë¤¿¤á¤ËξÊý¤«¤éɬÍפÊÉôʬ¤òÁªÂò¤·¡¢ 2 ¤Ä¤Î¥Õ¥¡¥¤¥ë¤òÅý¹ç¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ʤó¤Ç¤¤¤ë¥Õ¥¡¥¤¥ë¤òÈæ³Ó¤¹¤ë¤È¤­¡¢ l ¤Çº¸Â¦¤ÎÃæ¿È¤òÁªÂò¤·¡¢ r ¤Ç±¦Â¦¤ÎÃæ¿È¤òÁªÂò¤·¤Þ¤¹¡£ ºÇ½ª½ÐÎϤϺ¸±¦Î¾Êý¤ÎÉôʬ¤Ç¤Ç¤­¤¿¥Õ¥¡¥¤¥ë¤Ë¤Ê¤ë¤Ç¤·¤ç¤¦¡£ ¤³¤Î¥Õ¥¡¥¤¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤¿¤¤¤Æ¤¤¡¢¤³¤Î¥ª¥×¥·¥ç¥ó¤Ï¥æ¡¼¥¶¤¬ÀßÄê¤òÊѹ¹¤·¤¿¥Õ¥¡¥¤¥ë¤Ë»È¤ï¤ì¤Þ¤¹¡£ &man.diff.1; ¤Î·ë²Ì¤ò¤â¤¦°ìÅÙ¸«¤ë¡¢¤òÁªÂò¤¹¤ë¤È¡¢ ¤Á¤ç¤¦¤ÉÀè¤Û¤É &man.mergemaster.8; ¤¬ÁªÂò»è¤òɽ¼¨¤¹¤ëÁ°¤ÈƱ¤¸¤è¤¦¤Ë¡¢ ¥Õ¥¡¥¤¥ë¤ÎÁê°ÛÅÀ¤ò¸«¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ &man.mergemaster.8; ¤¬¥·¥¹¥Æ¥à¥Õ¥¡¥¤¥ë¤ÎÈæ³Ó¤ò½ª¤¨¤¿¤¢¤È¡¢ ¾¤Î¥ª¥×¥·¥ç¥ó¤Ë¤Ä¤¤¤Æ¤â¥×¥í¥ó¥×¥È¤¬É½¼¨¤µ¤ì¤Þ¤¹¡£ &man.mergemaster.8; ¤¬¡¢¥Ñ¥¹¥ï¡¼¥É¥Õ¥¡¥¤¥ë¤òºÆ¹½ÃÛ¤¹¤ë¤«¤É¤¦¤«¤ò¿Ò¤Í¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ºÇ¸å¤Ë»Ä¤Ã¤¿°ì»þ¥Õ¥¡¥¤¥ë¤òºï½ü¤¹¤ë¤«¤É¤¦¤«¤ò¿Ò¤Í¤Æ½ªÎ»¤·¤Þ¤¹¡£ ¼êư¤Ç¤Î¹¹¿· ¼êư¤Ç¹¹¿·¤¹¤ë¾ì¹ç¤Ë¤Ï¡¢Ã±¤Ë¥Õ¥¡¥¤¥ë¤ò /usr/src/etc ¤«¤é /etc ¤Ë ¥³¥Ô¡¼¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£Àµ¾ï¤Ëưºî¤·¤Ê¤¤¤Ç¤·¤ç¤¦¡£ ¥Õ¥¡¥¤¥ë¤ÎÃæ¤Ë¤Ï¡¢ ¥¤¥ó¥¹¥È¡¼¥ë¤È¤¤¤¦¼ê½ç¤òƧ¤Þ¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤â¤Î ¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ /usr/src/etc ¤Ï /etc ¤Ë¤½¤Î¤Þ¤ÞÃÖ¤­´¹¤¨¤é¤ì¤ë¤è¤¦¤Ê¥³¥Ô¡¼¤Ç¤Ï ¤Ê¤¤¤«¤é¤Ç¤¹¡£ ¤Þ¤¿¡¢/etc ¤Ë¤¢¤ë¤Ù¤­¥Õ¥¡¥¤¥ë¤Î¤¦¤Á¤Ç /usr/src/etc ¤Ë¤Ê¤¤¤â¤Î¤â¤¢¤ê¤Þ¤¹¡£ &man.mergemaster.8; ¤ò (´«¤á¤é¤ì¤¿Ä̤ê) »È¤Ã¤Æ¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢¼¡¤ÎÀá ¤Þ¤ÇÈô¤Ð¤·¤Æ¤â¤«¤Þ¤¤¤Þ¤»¤ó¡£ ¼êư¤Ç¹Ô¤¦ºÝ¤Î°ìÈÖ´Êñ¤ÊÊýË¡¤Ï¡¢ ¥Õ¥¡¥¤¥ë¤ò¿·¤·¤¤¥Ç¥£¥ì¥¯¥È¥ê¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤«¤é¡¢ °ÊÁ°¤Î¤â¤Î¤È°Û¤Ê¤Ã¤Æ¤¤¤ëÉôʬ¤òÄ´¤Ù¤Æ¹¹¿·ºî¶È¤ò¹Ô¤Ê¤¦¤³¤È¤Ç¤¹¡£ ´û¸¤Î <filename>/etc</filename> ¤ò¥Ð¥Ã¥¯¥¢¥Ã¥×¤¹¤ë ¤¿¤È¤¨¤Ð°Ê²¼¤Î¤è¤¦¤Ë¤·¤Æ¡¢ ´û¸¤Î /etc ¤ò¤É¤³¤«°ÂÁ´¤Ê¾ì½ê¤Ë¥³¥Ô¡¼¤·¤Æ¤ª¤­¤Þ¤·¤ç¤¦¡£ &prompt.root; cp -Rp /etc /etc.old ¤³¤³¤Ç¡¢ ¤ÏºÆµ¢Åª¤Ê¥³¥Ô¡¼¤ò¹Ô¤Ê¤¤¡¢ ¤Ï¥Õ¥¡¥¤¥ë¤Î¹¹¿·»þ´Ö¤ä½êÍ­¼Ô¤Ê¤É¤òÊݸ¤·¤Þ¤¹¡£ ¿·¤·¤¤ /etc ¤ä¤½¤Î¾¤Î¥Õ¥¡¥¤¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤¿¤á¤Î¡¢ ²¾¤Î¥Ç¥£¥ì¥¯¥È¥ê¤òºî¤Ã¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution ¾å¤ÎÎã¤Ï¡¢É¬Íפʥǥ£¥ì¥¯¥È¥ê¹½Â¤¤ò¤Ä¤¯¤ê¡¢¥Õ¥¡¥¤¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Þ¤¹¡£ /var/tmp/root °Ê²¼¤Ëºî¤é¤ì¤ë¡¢ ¤¿¤¯¤µ¤ó¤Î¶õ¤Î¥µ¥Ö¥Ç¥£¥ì¥¯¥È¥ê¤Ïºï½ü¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ °ìÈÖ´Êñ¤Ê¤ä¤êÊý¤Ï¡¢¼¡¤Î¤È¤ª¤ê¤Ç¤¹¡£ &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null ¤³¤ì¤Ï¶õ¥Ç¥£¥ì¥¯¥È¥ê¤ò¤¹¤Ù¤Æºï½ü¤·¤Þ¤¹¡£ ¶õ¤Ç¤Ê¤¤¥Ç¥£¥ì¥¯¥È¥ê¤Ë´Ø¤¹¤ë·Ù¹ð¤òÈò¤±¤ë¤¿¤á¤Ë¡¢ ɸ½à¥¨¥é¡¼½ÐÎÏ¤Ï /dev/null ¤Ë ¥ê¥À¥¤¥ì¥¯¥È¤µ¤ì¤Þ¤¹¡£ ¤³¤ÎÃʳ¬¤Î /var/tmp/root ¤Ë¤Ï¡¢ ËÜÍè / °Ê²¼¤Ë¤¢¤ë¤Ù¤­¥Õ¥¡¥¤¥ë¤¬¤¹¤Ù¤Æ´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£³Æ¥Õ¥¡¥¤¥ë¤ò½ç¤Ë¸«¤Æ¡¢ ´û¸¤Î¥·¥¹¥Æ¥à¤Ë¤¢¤ë¥Õ¥¡¥¤¥ë¤È°Û¤Ê¤ëÉôʬ¤òÄ´¤Ù¤Æ¤¯¤À¤µ¤¤¡£ /var/tmp/root °Ê²¼¤Ë¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤ë¥Õ¥¡¥¤¥ë¤ÎÃæ¤Ë¤Ï¡¢ . ¤«¤é»Ï¤Þ¤Ã¤Æ¤¤¤ë¤â¤Î¤¬¤¢¤ê¤Þ¤¹¡£ ls -a ¤ò»È¤Ã¤Æ³Î¤«¤á¤Æ¤¯¤À¤µ¤¤¡£ ¤â¤Ã¤È¤â´Êñ¤ÊÊýË¡¤Ï¡¢Æó¤Ä¤Î¥Õ¥¡¥¤¥ë¤òÈæ³Ó¤¹¤ë¥³¥Þ¥ó¥É &man.diff.1; ¤ò»È¤¦¤³¤È¤Ç¤¹¡£ &prompt.root; diff /etc/shells /var/tmp/root/etc/shells ¤³¤Î¥³¥Þ¥ó¥É¤Ï¡¢/etc/shells ¥Õ¥¡¥¤¥ë¤È ¿·¤·¤¤ /var/tmp/root/etc/shells ¥Õ¥¡¥¤¥ë¤Î°Û¤Ê¤ëÉôʬ¤òɽ¼¨¤·¤Þ¤¹¡£ ÆâÍÆ¤ò³Îǧ¤·¤Æ¡¢½ñ¤­´¹¤¨¤¿¤â¤Î¤ËÊѹ¹ÅÀ¤ò¥Þ¡¼¥¸¤¹¤ë¤«¡¢ ¤½¤ì¤È¤â´û¸¤Î¥Õ¥¡¥¤¥ë¤ò¿·¤·¤¤¤â¤Î¤Ç¾å½ñ¤­¤¹¤ë¤«¤òȽÃǤ·¤Æ¤¯¤À¤µ¤¤¡£ ¿·¤·¤¤ root ¥Ç¥£¥ì¥¯¥È¥ê (<filename class="directory">/var/tmp/root</filename>) ¤Î̾Á°¤Ë ¥¿¥¤¥à¥¹¥¿¥ó¥×¤òÉÕ¤±¤Æ¤ª¤¯¤È¡¢ °Û¤Ê¤ë¥Ð¡¼¥¸¥ç¥ó´Ö¤ÎÈæ³Ó¤ò³Ú¤Ë¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ÉÑÈˤ˥·¥¹¥Æ¥à¤ÎºÆ¹½ÃÛ¤ò¹Ô¤Ê¤¦¤È¤¤¤¦¤³¤È¤Ï¡¢ /etc ¤Î¹¹¿·¤â¤Þ¤¿¡¢ ÉÑÈˤ˹Ԥ¦É¬Íפ¬¤¢¤ë¤È¤¤¤¦¤³¤È¤Ç¤¹¡£ ¤³¤ì¤Ï¤Á¤ç¤Ã¤È¼ê´Ö¤Î¤«¤«¤ëºî¶È¤Ç¤¹¡£ ¤³¤Îºî¶È¤Ï¡¢¤¢¤Ê¤¿¤¬ /etc ¤Ë¥Þ¡¼¥¸¤·¤¿¡¢ ¿·¤·¤¯Êѹ¹¤µ¤ì¤¿¥Õ¥¡¥¤¥ë¤ÎºÇ¿·¤Î¥»¥Ã¥È¤Î¥³¥Ô¡¼¤òÊݸ¤·¤Æ¤ª¤¯¤³¤È¤Ç ÁÇÁ᤯¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ÉáÄÌ¤Ë make world ¤·¤Þ¤¹¡£ /etc ¤ä ¾¤Î¥Ç¥£¥ì¥¯¥È¥ê¤ò¹¹¿·¤·¤¿¤¯¤Ê¤Ã¤¿¤È¤­¤Ï¡¢¥¿¡¼¥²¥Ã¥È ¥Ç¥£¥ì¥¯¥È¥ê¤Ë¡¢¤½¤Î¤È¤­¤ÎÆüÉդ˴ð¤Å¤¯Ì¾Á°¤ò¤Ä¤±¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; mkdir /var/tmp/root-20130214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-20130214 \ distrib-dirs distribution ¾å¤ËÀâÌÀ¤µ¤ì¤Æ¤¤¤ë¤è¤¦¤Ë¡¢ ¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê¤«¤éÊѹ¹ÅÀ¤ò¥Þ¡¼¥¸¤·¤Þ¤¹¡£ ¤½¤Îºî¶È¤¬½ªÎ»¤·¤Æ¤â¡¢ /var/tmp/root-20130214 ¤òºï½ü¤·¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£ ºÇ¿·ÈǤΥ½¡¼¥¹¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤ÆºÆ¹½ÃÛ¤·¤¿¤é¡¢ ¥¹¥Æ¥Ã¥× 1 ¤Ë¤·¤¿¤¬¤Ã¤Æ¤¯¤À¤µ¤¤¡£º£Å٤ϡ¢ ¿·¤·¤¤ÆüÉÕ¤òÈ¿±Ç¤·¤¿¥Ç¥£¥ì¥¯¥È¥ê¤òºîÀ®¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ÎÎã¤Ç¤Ï¡¢/var/tmp/root-20130221 ¤È¤¤¤¦¿·¤·¤¤¥Ç¥£¥ì¥¯¥È¥ê¤ò¤Ä¤¯¤ê¤Þ¤¹¡£ &man.diff.1; ¤ò»ÈÍѤ·¡¢ Æó¤Ä¤Î¥Ç¥£¥ì¥¯¥È¥ê¤òÈæ³Ó¤¹¤ëºÆµ¢Åª diff ¤òºîÀ®¤¹¤ë¤³¤È¤Ç¡¢ °ì½µ´Ö¤Î´Ö¤Ë¹Ô¤Ê¤ï¤ì¤¿¥½¡¼¥¹¤Ø¤ÎÊѹ¹¤Ë¤è¤ëÁê°ãÅÀ¤òÄ´¤Ù¤Þ¤¹¡£ &prompt.root; cd /var/tmp &prompt.root; diff -r root-20130214 root-20130221 ¤³¤ì¤Ë¤è¤Ã¤ÆÊó¹ð¤µ¤ì¤ëÁê°ãÅÀ¤Ï¡¢ÂçÄñ¤Î¾ì¹ç¡¢/var/tmp/root-20130221/etc ¤È /etc ¤È¤ÎÁê°ãÅÀ¤ËÈæ¤Ù¤ÆÈó¾ï¤Ë¾¯¤Ê¤¤¤â¤Î¤Ë¤Ê¤ê¤Þ¤¹¡£ Áê°ãÅÀ¤¬¾¯¤Ê¤¤¤¿¤á¡¢Êѹ¹ÅÀ¤ò´û¸¤Î /etc ¤Ë¥Þ¡¼¥¸¤¹¤ë¤³¤È¤Ï¡¢Èæ³ÓÅªÍÆ°×¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤³¤³¤Þ¤Ç½ªÎ»¤·¤¿¤é¡¢ /var/tmp/root-* ¤ÎÆó¤Ä¤Î¤¦¤Á¡¢¸Å¤¤Êý¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Ïºï½ü¤·¤Æ¹½¤¤¤Þ¤»¤ó¡£ &prompt.root; rm -rf /var/tmp/root-20130214 ¤³¤Î¹©Äø¤ò¡¢ /etc ¤ØÊѹ¹ÅÀ¤ò¥Þ¡¼¥¸¤¹¤ëɬÍפ¬¤¢¤ë¤¿¤Ó¡¢·«¤êÊÖ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥Ç¥£¥ì¥¯¥È¥ê̾¤ÎÀ¸À®¤ò¼«Æ°²½¤¹¤ë¤Ë¤Ï¡¢&man.date.1; ¤òÍøÍѤ·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Anton Shterenlikht ¥Ù¡¼¥¹¤È¤Ê¤Ã¤¿¥Î¡¼¥È¤ÎÄó¶¡: »È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¥Õ¥¡¥¤¥ë¡¢¥Ç¥£¥ì¥¯¥È¥ê¤Îºï½ü Deleting obsolete files and directories &os; ¤Î³«È¯¥µ¥¤¥¯¥ë¤Ë¤ª¤¤¤Æ¡¢ ¥Õ¥¡¥¤¥ë¤ä¥·¥¹¥Æ¥à¤Î°ìÉô¤¬»È¤ï¤ì¤Ê¤¯¤Ê¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ¤½¤ì¤é¤Îµ¡Ç½¤¬Ê̤ξì½ê¤Ç¼ÂÁõ¤µ¤ì¤¿¤ê¡¢ ¥é¥¤¥Ö¥é¥ê¤Î¥Ð¡¼¥¸¥ç¥óÈֹ椬ÊѤï¤Ã¤¿¤ê¡¢ ¥·¥¹¥Æ¥à¤«¤é´°Á´¤Ëºï½ü¤µ¤ì¤ë¤³¤È¤¬¤¢¤ë¤¿¤á¤Ç¤¹¡£ ¥·¥¹¥Æ¥à¤Î¥¢¥Ã¥×¥Ç¡¼¥È»þ¤Ëºï½ü¤¬É¬Íפˤʤë¤Î¤Ï¡¢ ¸Å¤¤¥Õ¥¡¥¤¥ë¡¢¥é¥¤¥Ö¥é¥ê¤½¤·¤Æ¥Ç¥£¥ì¥¯¥È¥ê¤Ç¤¹¡£ ¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤òºï½ü¤¹¤ë¤³¤È¤Ç¡¢ µ­²±ÇÞÂΤä¥Ð¥Ã¥¯¥¢¥Ã¥×ÇÞÂΤˤª¤¤¤ÆÉÔɬÍפÊÍÆÎ̤òÀê¤á¤Æ¤¤¤ë¸Å¤¤¥Õ¥¡¥¤¥ë¤¬¡¢ ¥·¥¹¥Æ¥à¾å¤Ë»¶Í𤹤뤳¤È¤¬¤Ê¤¯¤Ê¤ê¤Þ¤¹¡£ ¤Þ¤¿¡¢¸Å¤¤¥é¥¤¥Ö¥é¥ê¤Î¥»¥­¥å¥ê¥Æ¥£¤ä°ÂÄêÀ­¤ËÌäÂ꤬¤¢¤ë¤È¡¢ ¥é¥¤¥Ö¥é¥ê¤ò¿·¤·¤¯¤·¤Æ¥·¥¹¥Æ¥à¤ò°ÂÄê¤Ê¾õÂ֤ˤ·¡¢ ¸Å¤¤¥é¥¤¥Ö¥é¥ê¤Ë¤è¤ê¥·¥¹¥Æ¥à¤¬¥¯¥é¥Ã¥·¥å¤¹¤ë¤³¤È¤òËɤ¬¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ »È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¥Õ¥¡¥¤¥ë¡¢¥Ç¥£¥ì¥¯¥È¥ê¡¢¥é¥¤¥Ö¥é¥ê¤Ï /usr/src/ObsoleteFiles.inc ¤Ë¤Þ¤È¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£°Ê²¼¤Î¼ê½ç¤Ë¤è¤ê¡¢ ¥¢¥Ã¥×¥°¥ì¡¼¥É¤Î²áÄø¤Ç¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤òºï½ü¤Ç¤­¤Þ¤¹¡£ - make - installworld + + make installworld ¤È¡¢¤½¤Î¸å¤Î mergemaster ¤¬Ìµ»ö¤Ë½ª¤ï¤Ã¤¿¤é¡¢ °Ê²¼¤ÎÊýË¡¤Ç»È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¥Õ¥¡¥¤¥ë¤ä¥é¥¤¥Ö¥é¥ê¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/src &prompt.root; make check-old ¸«¤Ä¤«¤Ã¤¿¸Å¤¤¥Õ¥¡¥¤¥ë¤Ï¡¢°Ê²¼¤Î¥³¥Þ¥ó¥É¤Çºï½ü¤Ç¤­¤Þ¤¹¡£ &prompt.root; make delete-old ¤½¤Î¾¤Î¥¿¡¼¥²¥Ã¥È¤Ë¤Ä¤¤¤Æ¤Ï /usr/src/Makefile ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ »È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¥Õ¥¡¥¤¥ë¤òºï½ü¤¹¤ëºÝ¡¢ ¥Õ¥¡¥¤¥ë¤´¤È¤Ë³Îǧ¤¬µá¤á¤é¤ì¤Þ¤¹¡£ ³Îǧ¤ò¾Êά¤·¡¢¼«Æ°Åª¤Ë¥Õ¥¡¥¤¥ë¤òºï½ü¤¹¤ë¤Ë¤Ï¡¢ °Ê²¼¤Î¤è¤¦¤Ë BATCH_DELETE_OLD_FILES ¤òÀßÄꤷ¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; make -DBATCH_DELETE_OLD_FILES delete-old yes ¤ò¥³¥Þ¥ó¥É¤Ø¥Ñ¥¤¥×¤Ç¤Ä¤Ê¤²¤Æ¤â¾Êά¤Ç¤­¤Þ¤¹¡£ &prompt.root; yes|make delete-old ºÆµ¯Æ° ¤¹¤Ù¤Æ¤¬¤¢¤ë¤Ù¤­Àµ¤·¤¤¾ì½ê¤Ë¸ºß¤¹¤ë¤³¤È¤ò¥Á¥§¥Ã¥¯¤·¤¿¤é¡¢ &man.shutdown.8; ¤ò¼Â¹Ô¤·¤Æ¥·¥¹¥Æ¥à¤òºÆµ¯Æ°¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; shutdown -r now »È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¥é¥¤¥Ö¥é¥ê¤Îºï½ü Warning »È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¥Õ¥¡¥¤¥ë¤òºï½ü¤¹¤ë¤È¡¢ ºï½ü¤·¤¿¥Õ¥¡¥¤¥ë¤Ë°Í¸¤·¤Æ¤¤¤¿¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤Ï²õ¤ì¤Æ¤·¤Þ¤¤¤Þ¤¹¡£ ÆÃ¤Ë¡¢¸Å¤¤¥é¥¤¥Ö¥é¥ê¤òºï½ü¤¹¤ë¾ì¹ç¤Ëµ¯¤³¤êÆÀ¤Þ¤¹¡£ Ä̾make delete-old-libs ¤ò¼Â¹Ô¤¹¤ëÁ°¤Ë¡¢ ¤³¤ì¤é¤Î¸Å¤¤¥é¥¤¥Ö¥é¥ê¤ò»È¤Ã¤Æ¤¤¤ë¥×¥í¥°¥é¥à¡¢ports¡¢ ¥é¥¤¥Ö¥é¥ê¤òºÆ¹½ÃÛ¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¶¦Í­¥é¥¤¥Ö¥é¥ê¤ò¥Á¥§¥Ã¥¯¤¹¤ë¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤È¤·¤Æ¡¢ - Ports Collection ¤Î sysutils/libchk ¤ä sysutils/bsdadminscripts + Ports Collection ¤Î + sysutils/libchk ¤ä + sysutils/bsdadminscripts ¤òÍøÍѤǤ­¤Þ¤¹¡£ »È¤ï¤ì¤Ê¤¯¤Ê¤Ã¤¿¶¦Í­¥é¥¤¥Ö¥é¥ê¤Ï¡¢ ¿·¤·¤¤¥é¥¤¥Ö¥é¥ê¤È¶¥¹ç¤·¡¢°Ê²¼¤Î¤è¤¦¤Ê¥á¥Ã¥»¡¼¥¸¤òɽ¼¨¤¹¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ /usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5 /usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5 ¤³¤ÎÌäÂê¤ò²ò·è¤¹¤ë¤Ë¤Ï¡¢ ¤Þ¤º¥é¥¤¥Ö¥é¥ê¤¬¤É¤Î port ¤Ë¤è¤Ã¤Æ¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤¿¤«¤òÄ´¤Ù¤Æ²¼¤µ¤¤¡£ &prompt.root; pkg_info -W /usr/local/lib/libtiff.so /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 &prompt.root; pkg_info -W /usr/local/lib/libXext.so /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 ¸«¤Ä¤«¤Ã¤¿ port ¤ò¥¢¥ó¥¤¥ó¥¹¥È¡¼¥ë¤·¡¢ ºÆ¹½ÃÛ¡¢ºÆ¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Î²áÄø¤Ï ports-mgmt/portmaster ¤Ç¼«Æ°²½¤Ç¤­¤Þ¤¹¡£ ¤¹¤Ù¤Æ¤Î ports ¤¬ºÆ¹½ÃÛ¤µ¤ì¡¢ ¸Å¤¤¥é¥¤¥Ö¥é¥ê¤¬¤É¤³¤Ë¤â»È¤ï¤ì¤Æ¤¤¤Ê¤¤¤³¤È¤ò³Îǧ¤·¤¿¤é¡¢ °Ê²¼¤Î¥³¥Þ¥ó¥É¤Ç¸Å¤¤¥é¥¤¥Ö¥é¥ê¤òºï½ü¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; make delete-old-libs ¤³¤³¤Þ¤ÇÍè¤ì¤Ð¡¢&os; ¥·¥¹¥Æ¥à¤Î¥¢¥Ã¥×¥°¥ì¡¼¥É¤ÏÀ®¸ù¤Ç¤¹¡£ ¤ª¤á¤Ç¤È¤¦¤´¤¶¤¤¤Þ¤¹¡£ ¤â¤·¤Á¤ç¤Ã¤È¤·¤¿ÌäÂ꤬¤¢¤Ã¤¿¾ì¹ç¤Ç¤â¡¢ ¥·¥¹¥Æ¥à¤Î°ìÉô¤òºÆ¹½ÃÛ¤¹¤ë¤Î¤Ï´Êñ¤Ç¤¹¡£ ¤¿¤È¤¨¤Ð¡¢¥¢¥Ã¥×¥°¥ì¡¼¥É¤ä /etc ¤Î¥Þ¡¼¥¸¤ÎÅÓÃæ¤Ç¸í¤Ã¤Æ /etc/magic ¤òºï½ü¤·¤Æ¤·¤Þ¤¤¡¢ ¤½¤Î·ë²Ì &man.file.1; ¤¬Æ°ºî¤·¤Ê¤¯¤Ê¤Ã¤Æ¤·¤Þ¤Ã¤¿¤è¤¦¤Ê¾ì¹ç¤Ë¤Ï¡¢ ¼¡¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤·¤Æ½¤Éü¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install ¼ÁÌä¤Ç¤¹¤«? Êѹ¹¤¬¹Ô¤Ê¤ï¤ì¤¿¤é¡¢¤½¤ÎÅ٤˥·¥¹¥Æ¥à¤ÎºÆ¹½ÃÛ¤¬É¬Íפˤʤë¤Î¤Ç¤·¤ç¤¦¤«? ¤½¤ì¤ÏÊѹ¹¤ÎÀ­¼Á¤Ë¤è¤ë¤Î¤Ç¡¢¤Ê¤ó¤È¤â¸À¤¨¤Þ¤»¤ó¡£ ¤¿¤È¤¨¤Ð¡¢svn ¤ò¼Â¹Ô¤·¤¿¤È¤­¡¢ ¼¡¤Ë¤¢¤²¤ë¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤¬¹¹¿·¤µ¤ì¤Æ¤¤¤¿¤È¤·¤Þ¤¹¡£ src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk ¤³¤Î¤È¤­¤Ë¤Ï¡¢²þ¤á¤Æ¥·¥¹¥Æ¥àÁ´ÂΤòºÆ¹½ÃÛ¤¹¤ëɬÍפϤʤ¤¤Ç¤·¤ç¤¦¡£ ¤½¤Î¤«¤ï¤ê¡¢Å¬Àڤʥµ¥Ö¥Ç¥£¥ì¥¯¥È¥ê¤Ë°Ü¤Ã¤Æ make all install ¤ò¹Ô¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤·¤«¤·¡¢¤¿¤È¤¨¤Ð src/lib/libc/stdlib ¤Î¤è¤¦¤ÊÂ礭¤ÊÊѹ¹¤¬¹Ô¤Ê¤ï¤ì¤¿¾ì¹ç¤Ë¤Ï¡¢ ¥·¥¹¥Æ¥àÁ´ÂΤòºÆ¹½ÃÛ¤¹¤ë¤«¡¢ ¾¯¤Ê¤¯¤È¤âÀÅŪ¤Ë¥ê¥ó¥¯¤µ¤ì¤Æ¤¤¤ë¤â¤Î¤òºî¤êľ¤¹É¬Íפ¬¤¢¤ê¤Þ¤¹¡£ ·ë¶É¤Î¤È¤³¤í¡¢ ¤É¤Î»þÅÀ¤Ç¸½ºß¤Î¥·¥¹¥Æ¥à¤ò¥¢¥Ã¥×¥°¥ì¡¼¥É¤¹¤ë¤«¤Ï¤¢¤Ê¤¿¤¬·è¤á¤ë¤³¤È¤Ç¤¹¡£ 2 ½µ´Ö¤´¤È¤Ë¥·¥¹¥Æ¥à¤òºÆ¹½ÃÛ¤·¡¢¤½¤Î 2 ½µ´Ö¤ÎÊѹ¹¤ò¼è¤ê¹þ¤à¥æ¡¼¥¶¤â¤¤¤Þ¤¹¤·¡¢ Êѹ¹¤Î¤¢¤Ã¤¿Éôʬ¤À¤±ºÆ¹½ÃÛ¤·¡¢ ¤¹¤Ù¤Æ¤Î°Í¸´Ø·¸¤ò³Î¤«¤á¤¿¤¤¤È¹Í¤¨¤ë¥æ¡¼¥¶¤â¤¤¤Þ¤¹¡£ ¤½¤ì¤é¤Ï¤É¤Î¤¯¤é¤¤¤ÎÉÑÅ٤ǥ¢¥Ã¥×¥°¥ì¡¼¥É¤·¤¿¤¤¤«¡¢ ¤½¤·¤Æ &os.stable; ¤« &os.current; ¤Î¤É¤Á¤é¤òÄɤ¤¤«¤±¤Æ¤¤¤ë¤Î¤«¤Ë¤è¤ê¤Þ¤¹¡£ - signal 11signal 11 + signal 11 + signal 11 + (¤â¤·¤¯¤Ï¾¤Î¥·¥°¥Ê¥ëÈÖ¹æ) ¤Î¥¨¥é¡¼¤¬¤¿¤¯¤µ¤ó½Ð¤Æ ¥³¥ó¥Ñ¥¤¥ë¤¬¼ºÇÔ¤·¤Þ¤¹¡£²¿¤¬µ¯¤³¤Ã¤Æ¤¤¤ë¤ó¤Ç¤·¤ç¤¦¤«? ¤³¤ì¤ÏÄ̾¥Ï¡¼¥É¥¦¥§¥¢¤ËÌäÂ꤬¤¢¤ë¤³¤È¤ò¼¨¤·¤Æ¤¤¤Þ¤¹¡£ ¥·¥¹¥Æ¥à¤ÎºÆ¹½Ãۤϡ¢¥Ï¡¼¥É¥¦¥§¥¢¤ËÂФ¹¤ëÉé²ÙÂѵ׻¤ò¹Ô¤Ê¤¦¤¿¤á¤Î Í­¸ú¤Ê¼êÃʤΰì¤Ä¤Ç¡¢¥á¥â¥ê¤Ë´Ø·¸¤¹¤ëÌäÂ꤬¤è¤¯Êó¹ð¤µ¤ì¤Þ¤¹¡£ ¤½¤ÎÂçÉôʬ¤Ï¡¢ ÉԲIJò¤Ê°Û¾ï½ªÎ»¤È¤Ê¤ë¤³¤È¤Çȯ¸«¤µ¤ì¤Þ¤¹¡£ ËÜÅö¤Ë¤³¤ÎÌäÂê¤Ë¤è¤ë¤â¤Î¤«¤É¤¦¤«¤Ï¡¢make ¤ò¤â¤¦°ìÅټ¹Ԥ·¡¢ °Û¤Ê¤ëÃʳ¬¤Ç°Û¾ï½ªÎ»¤¬È¯À¸¤¹¤ë¤«¡¢¤È¤¤¤¦¤³¤È¤«¤é³Îǧ¤Ç¤­¤Þ¤¹¡£ ¤³¤Î¥¨¥é¡¼¤ËÂбþ¤¹¤ë¤Ë¤Ï¡¢¥Þ¥·¥ó¤ÎÉôÉʤò¸ò´¹¤·¤Æ¡¢ ¤É¤ÎÉôʬ¤¬°­¤¤¤Î¤«¤òÄ´¤Ù¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£ ½ªÎ»¤·¤¿¤é /usr/obj ¤òºï½ü¤·¤Æ¤â¤«¤Þ¤¤¤Þ¤»¤ó¤«? °ì¸À¤ÇÅú¤¨¤ë¤Ê¤é¡Öºï½ü¤·¤Æ¤â¹½¤ï¤Ê¤¤¡×¤Ç¤¹¡£ /usr/obj ¤Ë¤Ï¡¢ ¥³¥ó¥Ñ¥¤¥ë¤ÎÃʳ¬¤ÇÀ¸À®¤µ¤ì¤¿ ¤¹¤Ù¤Æ¤Î¥ª¥Ö¥¸¥§¥¯¥È¥Õ¥¡¥¤¥ë¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹¡£ Ä̾ï make buildworld ¤ÎºÇ½é¤ÎÃʳ¬¤Ç¤Ï¡¢ ¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê¤òºï½ü¤·¤Æ¿·¤·¤¯¤Ä¤¯¤êľ¤¹¤è¤¦¤Ë¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£ ¹½ÃÛ½ªÎ»¸å¤â /usr/obj ¤òÊݸ¤·¤Æ¤ª¤¤¤Æ¤â¡¢¤¢¤Þ¤ê°ÕÌ£¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ºï½ü¤¹¤ì¤Ð¡¢¤À¤¤¤¿¤¤ 2 GB ¤Î¥Ç¥£¥¹¥¯¥¹¥Ú¡¼¥¹¤ò²òÊü¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ Îɤ¯Íý²ò¤ò¤·¤Æ¤¤¤ë¥æ¡¼¥¶¤Ç¤¢¤ì¤Ð¡¢ ¤³¤ÎÃʳ¬¤ò¾Êά¤·¤Æ make buildworld ¤ò¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤³¤¦¤¹¤ë¤È¡¢¤Û¤È¤ó¤É¤Î¥½¡¼¥¹¤ÏºÆ¥³¥ó¥Ñ¥¤¥ë¤µ¤ì¤Ê¤¤¤¿¤á¡¢ ¹½ÃۤϤ«¤Ê¤ê¹â®²½¤µ¤ì¤Þ¤¹¡£ ¤³¤ì¤Ï΢¤ò¤«¤¨¤»¤Ð¡¢¥Ç¥ê¥±¡¼¥È¤Ê°Í¸´Ø·¸¤ÎÌäÂê¤Ë¤è¤Ã¤Æ¡¢ ¥·¥¹¥Æ¥à¤Î¹½ÃÛ¤¬´ñ̯¤Ê¼ºÇԤ˽ª¤ï¤ë²ÄǽÀ­¤¬¤¢¤ë¤È¤¤¤¦¤³¤È¤Ç¤¹¡£ &os; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ç¤Ï¤·¤Ð¤·¤Ð¡¢¹½ÃۤμºÇÔ¤¬¡¢ ¤³¤ÎÃʳ¬¤Î¾Êά¤Ë¤è¤ë¤â¤Î¤À¤È¤¤¤¦¤³¤È¤òÍý²ò¤»¤º¤Ë ÉÔËþ¤ÎÀ¼¤ò¤¢¤²¤ë¿Í¤¬¤¤¤Þ¤¹¡£ ¹½ÃÛ¤òÃæÃǤ·¤¿¾ì¹ç¡¢¤½¤Î¹½ÃÛ¤òÅÓÃæ¤«¤éºÆ³«¤¹¤ë¤³¤È¤Ï¤Ç¤­¤Þ¤¹¤«? ¤½¤ì¤Ï¡¢ÌäÂ꤬µ¯¤³¤ë¤Þ¤Ç¤Ë¡¢ ¤É¤ì¤À¤±¤Îºî¶È¤ò½ª¤¨¤Æ¤¤¤ë¤«¤Ë¤è¤Ã¤ÆÊѤï¤ê¤Þ¤¹¡£ °ìÈÌŪ¤Ë make buildworld ¤Ï¡¢ &man.gcc.1; ¤ä &man.make.1; ¤Þ¤É¤Î´ðËÜŪ¤Ê¥Ä¡¼¥ë¤ä¡¢ ¥·¥¹¥Æ¥à¥é¥¤¥Ö¥é¥ê¤Î¿·¤·¤¤¥³¥Ô¡¼¤òºîÀ®¤·¤Þ¤¹¡£ ¤½¤Î¸å¡¢¤³¤ì¤é¤Î¥Ä¡¼¥ë¤ä¥é¥¤¥Ö¥é¥ê¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤«¤é¡¢ ¼«Ê¬¼«¿È¤ÎºÆ¹½Ãۤ˻Ȥï¤ì¡¢¤â¤¦°ìÅÙ¡¢¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Þ¤¹¡£ &man.ls.1; ¤ä &man.grep.1; ¤È¤¤¤Ã¤¿É¸½àŪ¤Ê¥æ¡¼¥¶¥×¥í¥°¥é¥à¤ò´Þ¤à¥·¥¹¥Æ¥àÁ´ÂΤ¬¡¢ ¤½¤Î¿·¤·¤¤¥·¥¹¥Æ¥à¥Õ¥¡¥¤¥ë¤òÍѤ¤¤Æºî¤êľ¤µ¤ì¤Þ¤¹¡£ ºÆ¹½ÃۤκǽªÃʳ¬¤Ç¤Ï¡¢ ¤Þ¤Ã¤¿¤¯°ÂÁ´¤Ë¼¡¤Î¤è¤¦¤Ë¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all ¤³¤ì¤Ï¡¢Á°²ó¤Î make buildworld ¤Îºî¶È¤ò¤ä¤êľ¤·¤Þ¤»¤ó¡£ ¼¡¤Î¥á¥Ã¥»¡¼¥¸ -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- ¤¬ make buildworld ¤Î½ÐÎϤˤ¢¤ë¾ì¹ç¤Ë¤Ï¡¢ ¾å¤Î¤è¤¦¤Ë¤·¤Æ¤â¤Û¤È¤ó¤É°­±Æ¶Á¤¬¸½¤ì¤ë¤³¤È¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ¤â¤·¤³¤Î¥á¥Ã¥»¡¼¥¸¤¬¤Ê¤¤¤È¤«¡¢¤è¤¯Ê¬¤«¤é¤Ê¤¤¤È¤¤¤¦¾ì¹ç¤Ë¤Ï¡¢ °ÂÁ´¤ò³ÎÊݤ·¡¢¸å²ù¤¹¤ë¤è¤¦¤Ê¤³¤È¤¬¤Ê¤¤¤è¤¦¡¢ ¥·¥¹¥Æ¥à¤ÎºÆ¹½ÃÛ¤òºÇ½é¤«¤é¤ä¤êľ¤·¤Þ¤·¤ç¤¦¡£ ¤É¤Î¤è¤¦¤Ë¤¹¤ì¤Ð make world ¤ò¹â®²½¤Ç¤­¤Þ¤¹¤«? ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Çư¤«¤·¤Æ¤¯¤À¤µ¤¤¡£ /usr/src ¤È /usr/obj ¤ò¡¢°Û¤Ê¤ë¥Ç¥£¥¹¥¯¾å¤ÎÊ̤Υե¡¥¤¥ë¥·¥¹¥Æ¥à¤ËÃÖ¤¤¤Æ¤¯¤À¤µ¤¤¡£ ¤Þ¤¿²Äǽ¤Ê¤é¤Ð¡¢ °Û¤Ê¤ë¥Ç¥£¥¹¥¯¥³¥ó¥È¥í¡¼¥é¤ËÀܳ¤µ¤ì¤¿¥Ç¥£¥¹¥¯¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤µ¤é¤Ë¹â®²½¤¹¤ë¤Ë¤Ï¡¢¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ò &man.ccd.4; ¤ò»È¤Ã¤Æ¡¢ Ê£¿ô¤Î¥Ç¥£¥¹¥¯¾å¤ËÃÖ¤¤¤Æ¤¯¤À¤µ¤¤¡£ /etc/make.conf ¤Ë NO_PROFILE=true ¤ò¥»¥Ã¥È¤·¤Æ¡¢ ¥×¥í¥Õ¥¡¥¤¥ëÈǤκîÀ®¤ò̵¸ú²½¤·¤Æ¤¯¤À¤µ¤¤¡£ &man.make.1; ¤Ë ¤ò»ØÄꤷ¤Æ¡¢Ê£¿ô¤Î¥×¥í¥»¥¹¤òÊÂÎó¤Ë¼Â¹Ô¤µ¤»¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ì¤Ï¡¢Ã±°ì¤Î¥×¥í¥»¥Ã¥µ¤Ç¤âÊ£¿ô¤Î¥×¥í¥»¥Ã¥µ¤Ç¤â¡¢ ƱÍͤ˲¸·Ã¤òÆÀ¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ /usr/src ¤Î¤¢¤ë¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ò¡¢ ¥ª¥×¥·¥ç¥ó¤òÉÕ¤±¤Æ¥Þ¥¦¥ó¥È¤â¤·¤¯¤ÏºÆ¥Þ¥¦¥ó¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ì¤Ï¡¢¤½¤Î¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ë¤ª¤¤¤Æ¡¢ ºÇ¸å¤Ë¥¢¥¯¥»¥¹¤µ¤ì¤¿»þ¹ï¤Î½ñ¤­¹þ¤ß¤òÍÞÀ©¤·¤Þ¤¹¡£ ¤ª¤½¤é¤¯¡¢¤³¤Î¾ðÊó¤¬É¬Íפˤʤ뤳¤È¤Ï¤Ê¤¤¤Ç¤·¤ç¤¦¡£ &prompt.root; mount -u -o noatime /usr/src ¾å¤ÎÎã¤Ï¡¢ /usr/src ¼«¿È¤¬ÆÈΩ¤·¤¿¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ç¤¢¤ë¤³¤È¤òÁÛÄꤷ¤Æ¤¤¤Þ¤¹¡£ ¤â¤· /usr ¤Î°ìÉô¤Ç¤¢¤ë¾ì¹ç¤Ë¤Ï¡¢ ¤«¤ï¤ê¤ËŬÀڤʥޥ¦¥ó¥È¥Ý¥¤¥ó¥È¤ò»ØÄꤹ¤·¤Æ¤¯¤À¤µ¤¤¡£ /usr/obj ¤Î¤¢¤ë¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤ò¡¢ ¥ª¥×¥·¥ç¥ó¤ò¤Ä¤±¤Æ¥Þ¥¦¥ó¥È¤â¤·¤¯¤ÏºÆ¥Þ¥¦¥ó¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ì¤Ë¤è¤Ã¤Æ¡¢¥Ç¥£¥¹¥¯¤Ø¤Î½ñ¤­¹þ¤ß¤¬È󯱴ü¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤Ä¤Þ¤ê¡¢½ñ¤­¹þ¤ßÌ¿Îá¤Ï¤¹¤°¤Ë´°Î»¤¹¤ë¤Î¤ËÂФ·¡¢ ¼ÂºÝ¤Ë¥Ç¡¼¥¿¤¬¥Ç¥£¥¹¥¯¤Ë½ñ¤­¹þ¤Þ¤ì¤ë¤Î¤Ï¡¢¤½¤Î¿ôÉøå¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤³¤ì¤Ë¤è¤Ã¤Æ¡¢½ñ¤­¹þ¤ß½èÍý¤Î°ì³ç²½¤¬²Äǽ¤Ë¤Ê¤ë¤¿¤á¡¢ ·àŪ¤Ê¥Ñ¥Õ¥©¡¼¥Þ¥ó¥¹¤Î¸þ¾å¤¬´üÂԤǤ­¤Þ¤¹¡£ ¤³¤Î¥ª¥×¥·¥ç¥ó¤ò»ØÄꤹ¤ë¤È¡¢¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ï ²õ¤ì¤ä¤¹¤¯¤Ê¤Ã¤Æ¤·¤Þ¤¦¤³¤È¤ËÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Î¥ª¥×¥·¥ç¥ó¤òÉÕ¤±¤Æ¤¤¤Æ¡¢ÆÍÁ³ÅŸ»¤¬Íî¤Á¤¿¾ì¹ç¤Ë¤Ï¡¢ ºÆµ¯Æ°¸å¤Ë¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤¬ÉüµìÉÔǽ¤Ë¤Ê¤ë²ÄǽÀ­¤¬ Èó¾ï¤Ë¹â¤¯¤Ê¤ê¤Þ¤¹¡£ ¤â¤·¡¢>/usr/obj ¤¬¡¢¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ë¤¢¤ëÍ£°ì¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Ç¤¢¤ì¤Ð¡¢ ¤³¤ì¤ÏÌäÂê¤Ë¤Ê¤ê¤Þ¤»¤ó¡£ ¤·¤«¤·¡¢Æ±¤¸¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ë¡¢Â¾¤Îµ®½Å¤Ê¥Ç¡¼¥¿¤òÃÖ¤¤¤Æ¤¤¤ë¤È¤­¤Ë¤Ï¡¢ ¤³¤Î¥ª¥×¥·¥ç¥ó¤òÍ­¸ú¤Ë¤¹¤ëÁ°¤Ë¡¢ ¥Ð¥Ã¥¯¥¢¥Ã¥×¤ò¤­¤Á¤ó¤È¼è¤Ã¤Æ¤ª¤­¤Þ¤·¤ç¤¦¡£ &prompt.root; mount -u -o async /usr/obj ¤â¤· /usr/obj ¼«¿È¤¬¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Ç¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢ ŬÀڤʥޥ¦¥ó¥È¥Ý¥¤¥ó¥È¤ò»Ø¤¹¤è¤¦¤Ë¡¢ ¾å¤ÎÎã¤Î̾Á°¤òÃÖ¤­´¹¤¨¤Æ¤¯¤À¤µ¤¤¡£ ¤Ê¤Ë¤«°­¤¤¤³¤È¤¬¤¢¤Ã¤¿¤é¤É¤¦¤¹¤ì¤Ð¤¤¤¤¤Ç¤¹¤«? ¼«Ê¬¤Î´Ä¶­¤ËÁ°¤Î¥Ó¥ë¥É¤Î;·×¤Ê¥´¥ß¤¬»Ä¤Ã¤Æ¤¤¤Ê¤¤¤³¤È¤ò¤Ï¤Ã¤­¤ê¤È³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir ¤¨¤¨¡¢make cleandir ¤ÏËÜÅö¤Ë 2 ²ó¼Â¹Ô¤¹¤ë¤Î¤Ç¤¹¡£ ¤½¤·¤Æ¡¢make buildworld ¤ò¹Ô¤¤¡¢ Á´¥×¥í¥»¥¹¤òºÇ½é¤«¤é¤ä¤êľ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤Þ¤ÀÌäÂ꤬¤¢¤ì¤Ð¡¢¥¨¥é¡¼¤È uname -a ¤Î½ÐÎϤò &a.questions; ¤ËÁ÷¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ÀßÄê¤Ë¤Ä¤¤¤Æ¤µ¤é¤Ë¼ÁÌ䤵¤ì¤Æ¤âÅú¤¨¤é¤ì¤ë¤è¤¦ÍѰդ·¤Æ¤¯¤À¤µ¤¤! Mike Meyer ´ó¹Æ: Ê£¿ô¤Î¥Þ¥·¥ó¤ÇÄɤ¤¤«¤±¤ë NFS Ê£¿ô¤Î¥Þ¥·¥ó¤Ë¥¤¥ó¥¹¥È¡¼¥ë Ê£¿ô¤Î¥³¥ó¥Ô¥å¡¼¥¿¤ÇƱ¤¸¥½¡¼¥¹¥Ä¥ê¡¼¤òÄɤ¤¤«¤±¤Æ¤¤¤Æ¡¢ Á´Éô¤Î¥Þ¥·¥ó¤Ë¥½¡¼¥¹¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤ÆÁ´Éô¤òºÆ¹½ÃÛ¤¹¤ë¤Î¤Ï¡¢ ¥Ç¥£¥¹¥¯¥¹¥Ú¡¼¥¹¡¢¥Í¥Ã¥È¥ï¡¼¥¯ÂÓ°è¡¢¤½¤·¤Æ CPU ¥µ¥¤¥¯¥ë¤Î̵Â̻Ȥ¤¤Ç¤¹¡£ ²ò·èºö¤Ï 1 ¤Ä¤Î¥Þ¥·¥ó¤Ë»Å»ö¤Î¤Û¤È¤ó¤É¤ò¤µ¤»¡¢ »Ä¤ê¤Î¥Þ¥·¥ó¤Ï NFS ·Ðͳ¤Ç¤½¤ì¤ò¥Þ¥¦¥ó¥È¤¹¤ë¡¢¤È¤¤¤¦¤â¤Î¤Ç¤¹¡£ ¤³¤Î¥»¥¯¥·¥ç¥ó¤Ç¤Ï¤½¤Î¤ä¤êÊý¤ò³µ´Ñ¤·¤Þ¤¹¡£ ½àÈ÷ ¤Þ¤º½é¤á¤Ë¡¢Æ±¤¸¥Ð¥¤¥Ê¥ê¤Çư¤«¤½¤¦¤È¤¹¤ë¥Þ¥·¥ó¤¿¤Á¤ò·è¤á¤Þ¤¹¡£ ¤³¤Î¥Þ¥·¥ó¤¿¤Á¤Î¤³¤È¤ò¥Ó¥ë¥É¥»¥Ã¥È¤È¸Æ¤Ó¤Þ¤¹¡£ ¤½¤ì¤¾¤ì¤Î¥Þ¥·¥ó¤Ï¥«¥¹¥¿¥à¥«¡¼¥Í¥ë¤ò»ý¤Ã¤Æ¤¤¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¤¬¡¢ Ʊ¤¸¥æ¡¼¥¶¥é¥ó¥É¥Ð¥¤¥Ê¥ê¤òư¤«¤½¤¦¤È¤¤¤¦¤Î¤Ç¤¹¡£ ¤³¤Î¥Ó¥ë¥É¥»¥Ã¥È¤«¤é¡¢ ¥Ó¥ë¥É¥Þ¥·¥ó¤È¤Ê¤ë¥Þ¥·¥ó¤ò 1 ÂæÁª¤Ó¤Þ¤¹¡£ ¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤È¥«¡¼¥Í¥ë¤ò¹½ÃÛ¤¹¤ë¤Î¤Ï¤³¤Î¥Þ¥·¥ó¤Ë¤Ê¤ê¤Þ¤¹¡£ ÍýÁÛŪ¤Ë¤Ï¡¢¤³¤Î¥Þ¥·¥ó¤Ï make buildworld ¤È make buildkernel ¤ò¼Â¹Ô¤¹¤ë¤Î¤Ë½½Ê¬¤Ê CPU ¤ò»ý¤Ã¤¿Â®¤¤¥Þ¥·¥ó¤Ç¤¢¤ë¤Ù¤­¤Ç¤¹¡£ ¥Æ¥¹¥È¥Þ¥·¥ó¤È¤Ê¤ë¤Ù¤­¥Þ¥·¥ó¤âÁª¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¹¹¿·¤µ¤ì¤¿¥½¥Õ¥È¥¦¥§¥¢¤ò»È¤¦Á°¤Ë¤½¤Î¥Þ¥·¥ó¤Ç¥Æ¥¹¥È¤¹¤ë¤Î¤Ç¤¹¡£ ¥Æ¥¹¥È¥Þ¥·¥ó¤Ï¤«¤Ê¤êŤ¤»þ´ÖÍî¤Á¤Æ¤¤¤Æ¤â ¤À¤¤¤¸¤ç¤¦¤Ö¤Ê¥Þ¥·¥ó¤Ç¤¢¤Ã¤¿¤Û¤¦¤¬¤¤¤¤¤Ç¤·¤ç¤¦¡£ ¥Ó¥ë¥É¥Þ¥·¥ó¤Ç¤â¤«¤Þ¤¤¤Þ¤»¤ó¤¬¡¢¥Ó¥ë¥É¥Þ¥·¥ó¤Ç¤¢¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£ ¤³¤Î¥Ó¥ë¥É¥»¥Ã¥È¤Î¥Þ¥·¥ó¤Ï¤¹¤Ù¤Æ /usr/obj ¤È /usr/src ¤òƱ¤¸¥Þ¥·¥ó¤ÎƱ¤¸¾ì½ê¤«¤é¥Þ¥¦¥ó¥È¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ÍýÁÛŪ¤Ë¤Ï¥Ó¥ë¥É¥Þ¥·¥ó¤Î 2 ¤Ä¤Î°ã¤¦¥É¥é¥¤¥Ö¾å¤Ë¤¢¤ë¤È¤è¤¤¤Î¤Ç¤¹¤¬¡¢ ¥Ó¥ë¥É¥Þ¥·¥ó¤Ë NFS ¥Þ¥¦¥ó¥È¤µ¤ì¤Æ¤¤¤Æ¤â¤«¤Þ¤¤¤Þ¤»¤ó¡£ ¥Ó¥ë¥É¥»¥Ã¥È¼«ÂΤ¬Ê£¿ô¤¢¤ë¾ì¹ç¤Ï¡¢ /usr/src ¤Ï¤Ò¤È¤Ä¤Î¥Ó¥ë¥É¥Þ¥·¥ó¾å¤Ë¤¢¤ë¤Ù¤­¤Ç¤¹¡£ ¾¤Î¥Þ¥·¥ó¤«¤é¤Ï¤½¤ì¤ò NFS ¥Þ¥¦¥ó¥È¤¹¤ë¤è¤¦¤Ë¤·¤Þ¤·¤ç¤¦¡£ ºÇ¸å¤Ë¥Ó¥ë¥É¥»¥Ã¥È¤Î¤¹¤Ù¤Æ¤Î¥Þ¥·¥ó¾å¤Î /etc/make.conf ¤È /etc/src.conf ¤¬¥Ó¥ë¥É¥Þ¥·¥ó¤È°ìÃפ·¤Æ¤¤¤ë¤³¤È¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤Ä¤Þ¤ê¡¢¥Ó¥ë¥É¥Þ¥·¥ó¤Ï¥Ó¥ë¥É¥»¥Ã¥È¤Î¤É¤Î¥Þ¥·¥ó¤â¥¤¥ó¥¹¥È¡¼¥ë¤·¤è¤¦¤È¤·¤Æ¤¤¤ë ¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤òÁ´Éô¥Ó¥ë¥É¤·¤Ê¤±¤ì¤Ð¤Ê¤é¤Ê¤¤¤È¤¤¤¦¤³¤È¤Ç¤¹¡£ ¤Þ¤¿¡¢³Æ¥Ó¥ë¥É¥Þ¥·¥ó¤Ï /etc/make.conf ¤Ë¤½¤ì¤¾¤ì¤Î¥Ó¥ë¥É¥Þ¥·¥ó¤Î¥«¡¼¥Í¥ë̾¤ò KERNCONF ¤Ç»ØÄꤷ¡¢ ¥Ó¥ë¥É¥Þ¥·¥ó¤Ï¼«Ê¬¼«¿È¤Î¥«¡¼¥Í¥ë¤«¤é½ç¤ËÁ´Éô¤Î¥«¡¼¥Í¥ë̾¤ò KERNCONF ¤Ë¥ê¥¹¥È¥¢¥Ã¥×¤·¤Æ¤¯¤À¤µ¤¤¡£ ³Æ¥Þ¥·¥ó¤Î¥«¡¼¥Í¥ë¤â¥Ó¥ë¥É¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ ¥Ó¥ë¥É¥Þ¥·¥ó¤Ï³Æ¥Þ¥·¥ó¤Î¥«¡¼¥Í¥ëÀßÄê¥Õ¥¡¥¤¥ë¤ò /usr/src/sys/arch/conf ¤Ë»ý¤Ã¤Æ¤¤¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ¥Ù¡¼¥¹¥·¥¹¥Æ¥à ¥Ó¥ë¥É¥Þ¥·¥ó¤Ë¤Æ¡¢ ¤Ë½ñ¤¤¤Æ¤¢¤ë¤è¤¦¤Ë¥«¡¼¥Í¥ë¤È¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤ò¹½ÃÛ¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤Ç¤â¡¢¤Þ¤À¥¤¥ó¥¹¥È¡¼¥ë¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£ ¥Ó¥ë¥É¤¬½ª¤ï¤Ã¤¿¤é¡¢¥Æ¥¹¥È¥Þ¥·¥ó¤Ë°Ü¤ê¡¢ ¥Ó¥ë¥É¤·¤¿¥«¡¼¥Í¥ë¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥Æ¥¹¥È¥Þ¥·¥ó¤¬ NFS ·Ðͳ¤Ç /usr/src ¤È /usr/obj ¤ò¥Þ¥¦¥ó¥È¤·¤Æ¤¤¤ë¤Ê¤é¡¢ ¥·¥ó¥°¥ë¥æ¡¼¥¶¤ÇºÆµ¯Æ°¤·¤¿¤È¤­¤Ë¥Í¥Ã¥È¥ï¡¼¥¯¤ò»È¤¨¤ë¤è¤¦¤Ë¤·¤Æ¡¢ ¤³¤ì¤é¤Î¥Ç¥£¥ì¥¯¥È¥ê¤ò¥Þ¥¦¥ó¥È¤¹¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤â¤Ã¤È¤â´Êñ¤ÊÊýË¡¤Ï¡¢ ¥Þ¥ë¥Á¥æ¡¼¥¶¥â¡¼¥É¤Çµ¯Æ°¤·¤Æ¡¢shutdown now ¤ò¼Â¹Ô¤·¤Æ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤Ë°Ü¹Ô¤¹¤ë¤³¤È¤Ç¤¹¡£ ¤½¤¦¤·¤¿¤é¡¢¥«¡¼¥Í¥ë¤È¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¡¢ ¤¤¤Ä¤â¤¹¤ë¤è¤¦¤Ë mergemaster ¤ò¼Â¹Ô¤·¤Æ¤¯¤À¤µ¤¤¡£ ½ª¤ï¤Ã¤¿¤é¡¢ ¥Æ¥¹¥È¥Þ¥·¥ó¤òºÆµ¯Æ°¤·¤ÆÄ̾ï¤Î¥Þ¥ë¥Á¥æ¡¼¥¶Æ°ºî¤ËÌᤷ¤Þ¤¹¡£ ¥Æ¥¹¥È¥Þ¥·¥ó¤Ë¤¢¤ë¤â¤Î¤¹¤Ù¤Æ¤¬¤Á¤ã¤ó¤Èư¤¤¤Æ¤¤¤ë³Î¿®¤¬ÆÀ¤é¤ì¤¿¤é¡¢ Ʊ¤¸¼ê½ç¤Ç¥Ó¥ë¥É¥»¥Ã¥È¤Î¾¤Î¥Þ¥·¥ó¤Ë¤â¿·¤·¤¤¥½¥Õ¥È¥¦¥§¥¢¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Þ¤¹¡£ Ports ports ¥Ä¥ê¡¼¤Ë¤âƱ¤¸¥¢¥¤¥Ç¥¢¤¬»È¤¨¤Þ¤¹¡£ ºÇ½é¤Ë½ÅÍפÊÅÀ¤Ï¡¢ ¥Ó¥ë¥É¥»¥Ã¥È¤Î¤¹¤Ù¤Æ¤Î¥Þ¥·¥ó¤ËƱ¤¸¥Þ¥·¥ó¤Î /usr/ports ¤ò¥Þ¥¦¥ó¥È¤¹¤ë¤³¤È¤Ç¤¹¡£ ¤½¤·¤Æ¡¢distfiles ¤ò¶¦Í­¤¹¤ë¤è¤¦¤Ë /etc/make.conf ¤òŬÀÚ¤ËÀßÄꤷ¤Þ¤¹¡£ NFS ¥Þ¥¦¥ó¥È¤Ë¤è¤Ã¤Æ¥Þ¥Ã¥×¤µ¤ì¤ë root ¥æ¡¼¥¶¤¬²¿¤Ç¤¢¤ì¡¢DISTDIR ¤Ï¤½¤Î¥æ¡¼¥¶¤¬½ñ¤­¹þ¤á¤ë¶¦Ä̤ζ¦Í­¥Ç¥£¥ì¥¯¥È¥ê¤ËÀßÄꤹ¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ³Æ¥Þ¥·¥ó¤Ï WRKDIRPREFIX ¤ò¼«Ê¬¤Î¥Þ¥·¥ó¤Î¥Ó¥ë¥É¥Ç¥£¥ì¥¯¥È¥ê¤ËÀßÄꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ºÇ¸å¤Ë¡¢packages ¤ò¥Ó¥ë¥É¤·¤ÆÇÛÉÛ¤¹¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢ DISTDIR ¤ÈƱ¤¸¤è¤¦¤Ë PACKAGES ¥Ç¥£¥ì¥¯¥È¥ê¤âÀßÄꤷ¤Æ¤¯¤À¤µ¤¤¡£ diff --git a/ja_JP.eucJP/books/handbook/mirrors/chapter.xml b/ja_JP.eucJP/books/handbook/mirrors/chapter.xml index f278287723..0820346482 100644 --- a/ja_JP.eucJP/books/handbook/mirrors/chapter.xml +++ b/ja_JP.eucJP/books/handbook/mirrors/chapter.xml @@ -1,2668 +1,2669 @@ &os; ¤ÎÆþ¼êÊýË¡ CDROM/DVD ½ÐÈÇ¼Ò CD/DVD ¥»¥Ã¥È &os; ¤Î CD/DVD ¥»¥Ã¥È¤Ï°Ê²¼¤Î¥ª¥ó¥é¥¤¥ó¶È¼Ô¤«¤éÆþ¼ê¤Ç¤­¤Þ¤¹¡£
&os; Mall, Inc. 2420 Sand Creek Rd C-1 #347 Brentwood, CA 94513 USA ÅÅÏÃ: +1 925 240-6652 Fax: +1 925 674-0821 Email: info@freebsdmall.com WWW:
Dr. Hinner EDV Kochelseestr. 11 D-81371 München Germany ÅÅÏÃ: (0177) 428 419 0 WWW:
Linux Distro UK 42 Wharfedale Road Margate CT9 2TB United Kingdom WWW:
The Linux Emporium The Techno Centre, Puma Way Parkside CV1 2TT United Kingdom ÅÅÏÃ: +44 (0)247 615 8121 Fax: +44 1491 837016 WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Russia ÅÅÏÃ: +7-812-3125208 Email: info@linuxcenter.ru WWW:
FTP ¥µ¥¤¥È &os; ¤Î¸ø¼°¤Ê¾ðÊó¤Ï anonymous FTP ¤Ë¤è¤Ã¤ÆÀ¤³¦Ãæ¤Î¥ß¥é¡¼¥µ¥¤¥È¤è¤êÆþ¼ê¤Ç¤­¤Þ¤¹¡£ ¥µ¥¤¥È¤ÏÀܳ¤¬Îɤ¯¡¢Â絬ÌϤÊÀܳ¤ò¼õ¤±ÉÕ¤±¤Æ¤¤¤Þ¤¹¤¬¡¢ ¤è¤ê¥Í¥Ã¥È¥ï¡¼¥¯Åª¤Ë¶á¤¤ ¥ß¥é¡¼¥µ¥¤¥È¤òõ¤·¤¿Êý¤¬Îɤ¤¤Ç¤·¤ç¤¦ (ÆÃ¤Ë¥ß¥é¡¼¥µ¥¤¥È¤Î¤è¤¦¤Ê¤â¤Î¤ò¹½ÃÛ¤·¤è¤¦¤È¤·¤¿¾ì¹ç¤Ï¤³¤ì¤Ë³ºÅö¤·¤Þ¤¹)¡£ ¤µ¤é¤Ë¡¢&os; ¤Ï°Ê²¼¤Î¥ß¥é¡¼¥µ¥¤¥È¤«¤é anonymous FTP ¤Ë¤è¤Ã¤ÆÆþ¼ê¤Ç¤­¤Þ¤¹¡£¤â¤· &os; ¤ò anonymous FTP ¤Ë¤è¤Ã¤Æ¼ê¤Ë¤¤¤ì¤ë¾ì¹ç¤Ï¡¢ ¶á¤¯¤Î¥µ¥¤¥È¤òÍøÍѤ¹¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ °ì¼¡¥ß¥é¡¼¥µ¥¤¥È ¤È¤·¤Æ¤¢¤²¤é¤ì¤Æ¤¤¤ë¥µ¥¤¥È¤Ë¤Ï¡¢ &os; ¤Î³Æ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤ÇÍøÍѲÄǽ¤Ê¤¹¤Ù¤Æ¤Î¥Ð¡¼¥¸¥ç¥ó¤Î¥¢¡¼¥«¥¤¥Ö°ì¼°¤¬ÍѰդµ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤¢¤Ê¤¿¤¬½»¤ó¤Ç¤¤¤ë¹ñ¤äÃϰè¤Ë¤Ï¡¢ ¤è¤ê¹â®¤Ë¥À¥¦¥ó¥í¡¼¥É¤Ç¤­¤ë¥µ¥¤¥È¤¬¤ª¤½¤é¤¯¤¢¤ë¤Ç¤·¤ç¤¦¡£ ³Æ¹ñ¤Î¥ß¥é¡¼¥µ¥¤¥È¤Ë¤Ï¡¢ ¿Íµ¤¤Î¤¢¤ë¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤ÎºÇ¿·¤Î¥Ð¡¼¥¸¥ç¥ó¤¬ÃÖ¤¤¤Æ¤¢¤ê¤Þ¤¹¤¬¡¢ &os; ¤Î¥¢¡¼¥«¥¤¥ÖÁ´ÂΤϤ⤷¤«¤¹¤ë¤È¤Ê¤¤¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¤¹¤Ù¤Æ¤Î¥µ¥¤¥È¤Ï anonymous FTP ¤Ë¤è¤ë¥¢¥¯¥»¥¹¤òÄ󶡤·¤Æ¤¤¤Þ¤¹¤¬¡¢ Ê̤ÎÊýË¡¤Ë¤è¤ë¥¢¥¯¥»¥¹¤òÄ󶡤·¤Æ¤¤¤ë¥µ¥¤¥È¤â¤¢¤ê¤Þ¤¹¡£ ³Æ¥µ¥¤¥È¤ÇÄ󶡤·¤Æ¤¤¤ë¥¢¥¯¥»¥¹ÊýË¡¤Ï¡¢ ¥Û¥¹¥È̾¤Ë³¤¯³ç¸Ì¤ÎÃæ¤Ëµ­ºÜ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ &chap.mirrors.ftp.index.inc; &chap.mirrors.lastmod.inc; &chap.mirrors.ftp.inc; Anonymous CVS (Èó¿ä¾©) Warning CVS ¤Ï¡¢¥×¥í¥¸¥§¥¯¥È¤Ë¤ª¤¤¤Æ»ÈÍѤµ¤ì¤Ê¤¯¤Ê¤Ã¤¿¤¿¤á¡¢ Èó¿ä¾©¤Ë¤Ê¤ê¤Þ¤·¤¿¡£¤«¤ï¤ê¤Ë Subversion ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ CTM ¤ò»È¤¦ CTM Ìõ: &a.hanai;¡¢1997 ǯ 9 ·î 13 Æü CTM ¤Ï¥ê¥â¡¼¥È¤Î¥Ç¥£¥ì¥¯¥È¥ê¥Ä¥ê¡¼¤òÃæ±û¤Î¥Ä¥ê¡¼¤ËƱ´ü¤µ¤»¤ë¤¿¤á¤Î ¼êÃʤǤ¹¡£ ¤³¤ì¤Ï &os; ¤Î¥½¡¼¥¹¥Ä¥ê¡¼¤ÎÇÛÉÛ¤ò¹Ô¤Ê¤¦¤¿¤á¤Ë³«È¯¤µ¤ì¤Þ¤· ¤¿¤¬¡¢»þ¤¬·Ð¤Ä¤Ë¤Ä¤ì¤ÆÊ̤ÎÌÜŪ¤Ë¤âÍ­ÍѤǤ¢¤ë¤³¤È¤¬¤ï¤«¤ë¤«¤â ¤·¤ì¤Þ¤»¤ó¡£ ¥Ç¥ë¥¿¤òºî¤ê½Ð¤¹½èÍý¤Ë´Ø¤¹¤ë¥É¥­¥å¥á¥ó¥È¤Ï¸½ºß¤Û¤È¤ó¤É ¤¢¤ê¤Þ¤»¤ó¡£½¾¤Ã¤Æ¡¢¤â¤·¤¢¤Ê¤¿¤¬CTM ¤ò¾¤Î¤³¤È¤Ë»È¤¤¤¿¤¤¤Ê¤é &a.ctm-users.name; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë¤µ¤é¤Ê¤ë¾ðÊó¤òÌ䤤¹ç¤ï¤»¤Æ¤¯¤À¤µ¤¤¡£ ¤Ê¤¼ <application>CTM</application> ¤ò»È¤¦¤Î? CTM ¤ò»È¤¦¤³¤È¤Ë¤è¤ê &os; ¥½¡¼¥¹¥Ä¥ê¡¼¤Î¥í¡¼¥«¥ë¥³¥Ô¡¼¤ò¼ê¤Ë¤¤¤ì¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¥½¡¼¥¹¥Ä¥ê¡¼¤¬»È¤¨¤ë¤³¤È¤ÎÌ¥ÎϤϿô¿¤¯¤¢¤ê¤Þ¤¹¡£´°Á´¤Ê cvs ¥Ä¥ê¡¼¤òÄɤ¤¤«¤±¤ë¤Ë¤·¤Æ¤â¡¢¤Ò¤È¤Ä¤Î¥Ö¥é¥ó¥Á¤òÄɤ¤¤«¤±¤ë ¤Ë¤·¤Æ¤â CTM ¤ÏɬÍפʾðÊó¤òÍ¿¤¨¤Æ¤¯¤ì¤Þ¤¹¡£ ¤â¤·¤¢¤Ê¤¿¤¬ &os; ¤Î¥¢¥¯¥Æ¥£¥Ö¤Ê³«È¯¼Ô¤Ç¤¢¤ë¤Ë¤â¤«¤«¤ï¤é¤º ¤ªÁÆËö¤Ê TCP/IP Àܳ¤·¤«»ý¤Ã¤Æ¤¤¤Ê¤«¤Ã¤¿¤ê¡¢¤Þ¤¿¤Ï TCP/IP Àܳ¤¬ ¹Ô¤Ê¤¨¤Ê¤¤¤È¤·¤¿¤é¡¢¤¢¤ë¤¤¤Ïñ¤ËÊѹ¹¤¬¼«Æ°Åª¤ËÁ÷¤é¤ì¤Æ¤­¤Æ ¤Û¤·¤¤¤È¤¤¤¦¤Î¤Ç¤¢¤ì¤Ð CTM ¤Ï¤½¤ó¤Ê¤¢¤Ê¤¿¤Î¤¿¤á¤Ë ºî¤é¤ì¤¿¤Î¤Ç¤¹¡£ ¥¢¥¯¥Æ¥£¥Ö¤Ê¥Ö¥é¥ó¥Á¤Ç¤Ï 1 Æü¤ËºÇÂç»°¤Ä¤Þ¤Ç¤Î¥Ç¥ë¥¿¤ò¼õ¤±¼è¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¤³¤ì¤¬¼«Æ°Åª¤Ë e-mail ¤ÇÁ÷¤é¤ì¤Æ¤¯¤ë¤È¤¤¤¦ÊýË¡¤ò ¤¼¤Ò¸¡Æ¤¤·¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£ ¥Ç¥ë¥¿¤Î¥µ¥¤¥º¤Ï¾ï¤Ë¤Ç¤­¤ë¤À¤±¾®¤µ¤¯Êݤ¿¤ì¤Æ¤¤¤Þ¤¹¡£ ÂçÄñ¤Î¾ì¹ç 5KB ¤è¤ê¤â¾®¤µ¤¯¡¢ ¤¿¤Þ¤Ë (10 ²ó¤Ë 1 ²óÄøÅÙ) 10-50KB ¤Ë¤Ê¤ê¡¢ ¤È¤­¤ª¤ê 100KB ¤«¤â¤Ã¤ÈÂ礭¤¯¤Ê¤ë¤Ç¤·¤ç¤¦¡£ ³«È¯¥½¡¼¥¹¤«¤éľÀÜ¤ËÆÀ¤é¤ì¤¿¤â¤Î¤ò»È¤¦¤³¤È¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¤¢¤é¤«¤¸¤á¥Ñ¥Ã¥±¡¼¥¸¤Ë¤µ¤ì¤¿¥ê¥ê¡¼¥¹¤È¤Ï°ã¤¤¡¢ ¤¤¤í¤¤¤í¤ÈÃí°Õ¤¹¤ë¤³¤È¤¬ ¤¢¤ê¤Þ¤¹¡£¤³¤ì¤ÏÆÃ¤Ë current ¤Î¥½¡¼¥¹¤òÁª¤ó¤Ç¤¤¤ë¤È¤­¤Ï½ÅÍפǤ¹¡£ ºÇ¿·¤Î &os; ¤òÄɤ¤¤«¤±¤ë¤òÆÉ¤à¤³¤È¤ò¤ª´«¤á¤·¤Þ¤¹¡£ <application>CTM</application>¤ò»È¤¦¤Ë¤Ï²¿¤¬É¬Í×? Æó¤Ä¤Î¤â¤Î¤¬É¬ÍפǤ·¤ç¤¦: CTM ¥×¥í¥°¥é¥à¤È¤½¤ì¤ËÍ¿¤¨¤ë (current ¥ì¥Ù¥ë¤òÆÀ¤ë¤¿¤á¤Î) ºÇ½é¤Î¥Ç¥ë¥¿¤Ç¤¹¡£ CTM ¥×¥í¥°¥é¥à¤Ï¥Ð¡¼¥¸¥ç¥ó 2.0 ¤Î¥ê¥ê¡¼¥¹°ÊÍè &os; ¤Î°ìÉô¤Ë¤Ê¤ê¤Þ¤·¤¿¡£ ¤â¤·¥½¡¼¥¹¤Î¥³¥Ô¡¼¤ò»ý¤Ã¤Æ¤¤¤ë¤Ê¤é /usr/src/usr.sbin/ctm¤Ë¤¢¤ê¤Þ¤¹¡£ ¤«¤éÆþ¼ê¤Ç¤­¤Þ¤¹¡£CTM ¤ËÍ¿¤¨¤ë ¥Ç¥ë¥¿ ¤ÏÆó¤Ä¤ÎÊýË¡¡¢FTP ¤Þ¤¿¤Ï e-mail¡¢ ¤ÇÆÀ¤ë¤³¤È ¤¬¤Ç¤­¤Þ¤¹¡£ ¤â¤·¥¤¥ó¥¿¡¼¥Í¥Ã¥È¤Ë FTP ¥¢¥¯¥»¥¹¤Ç¤­¤ë¤Ê¤é¡¢ ¼¡¤Î FTP ¥µ¥¤¥È: ¤Þ¤¿¤Ï¡¢¤½¤Î¥ß¥é¡¼¥µ¥¤¥È¤¬ CTM ¤Ø¤Î¥¢¥¯¥»¥¹¤ò¥µ¥Ý¡¼¥È¤·¤Þ¤¹¡£ ŬÀڤʥǥ£¥ì¥¯¥È¥ê¤Ë FTP ¤·¤Æ README ¥Õ¥¡¥¤¥ë¤òÆþ¼ê¤·¡¢¤½¤³¤«¤é¥¹¥¿¡¼¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ e-mail ¤Ë¤è¤Ã¤Æ¥Ç¥ë¥¿¤òÆÀ¤¿¤¤¤È¤¤¤¦¾ì¹ç¤Ï: CTM ÇÛÉۥ᡼¥ê¥ó¥°¥ê¥¹¥È¤Î¤¤¤º¤ì¤«¤Ë»²²Ã¤·¤Æ¤¯¤À¤µ¤¤¡£ &a.ctm-src-cur.name; ¤Ï´°Á´¤Ê Subversion ¥Ä¥ê¡¼¡¢ &a.ctm-src-cur.name; ¤Ï³«È¯Àèü¥Ö¥é¥ó¥Á¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£&a.ctm-src-9.name; ¤Ï 9.X ¥ê¥ê¡¼¥¹¤Î¥Ö¥é¥ó¥Á¤ËÂбþ¤·¤¿¤â¤Î¤Ç¤¹ (¤â¤·»²²ÃÊýË¡¤¬Ê¬¤«¤é¤Ê¤¤¾ì¹ç¤Ï¡¢¥á¡¼¥ê¥ó¥°¥ê¥¹¥È̾¤ò¥¯¥ê¥Ã¥¯¤¹¤ë¤«¡¢ &a.mailman.lists.link; ¤Ë¹Ô¤Ã¤Æ»²²Ã¤·¤¿¤¤¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ò¥¯¥ê¥Ã¥¯¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤Î¥Ú¡¼¥¸¤Ë¤Ï¡¢»²²Ã¼ê½ç¤¬¾Ü¤·¤¯½ñ¤«¤ì¤Æ¤¤¤Þ¤¹)¡£ ¥á¡¼¥ë¤Ç CTM ¤Ë¤è¤ë¹¹¿·¥Õ¥¡¥¤¥ë¤ò¼õ¤±¼è¤ê»Ï¤á¤ë¤È¡¢Ãæ¿È¤ò¼è¤ê½Ð¤·¤Æ»ÈÍÑ ¤¹¤ë¤¿¤á¤Ë ctm_rmail ¥×¥í¥°¥é¥à¤ò»È¤¦¤«¤â¤·¤ì¤Þ¤»¤ó¡£¤½¤ì¤ò´°Á´ ¤Ë¼«Æ°¤Ç¹Ô¤Ê¤¤¤¿¤¤¤Ê¤é¡¢/etc/aliases ¤«¤é ctm_rmail¥×¥í ¥°¥é¥à¤òľÀܻȤ¦¤³¤È¤â¤Ç¤­¤Þ¤¹¡£ ¤µ¤é¤Ë¾Ü¤·¤¤¤³¤È¤Ï ctm_rmail man¥Ú¡¼¥¸¤ò¸æÍ÷¤¯¤À¤µ¤¤¡£ ¤É¤ÎÊýË¡¤ò»È¤Ã¤Æ CTM ¥Ç¥ë¥¿¤òÆþ¼ê¤·¤Æ¤¤¤¿¤È¤·¤Æ¤â¡¢ &a.ctm-announce.name; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë¤Ï»²²Ã¤·¤Æ¤ª¤¯¤È¤¤¤¤¤Ç¤·¤ç¤¦¡£ ¤³¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ï¾­ÍèŪ¤Ë¤Ï CTM ¥·¥¹¥Æ¥à¤ÎÁàºî¤Ë´Ø¤¹¤ë ¥¢¥Ê¥¦¥ó¥¹¤¬¥Ý¥¹¥È¤µ¤ì¤ëÍ£°ì¤Î¾ì¤Ë¤Ê¤ë¤Ç¤·¤ç¤¦¡£ ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ë»²²Ã¤¹¤ë¤Ë¤Ï¡¢¾å¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È̾¤ò¥¯¥ê¥Ã¥¯¤·¤Æ¡¢ »²²Ã¼ê½ç¤Ë½¾¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤Ï¤¸¤á¤Æ <application>CTM</application> ¤ò»È¤¤»Ï¤á¤ë CTM ¥Ç¥ë¥¿¤ò»È¤¤»Ï¤á¤ë¤¿¤á¤Ë¤Ï¡¢¤³¤ì¤Ï°Ê¹ßºî¤é¤ì¤ëÁ´¤Æ¤Î ¥Ç¥ë¥¿¤Î½ÐȯÅÀ¤ò¼ê¤Ë¤¤¤ì¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ºÇ½é¤Ë¤¢¤Ê¤¿¤¬²¿¤ò¤¹¤Ç¤Ë»ý¤Ã¤Æ¤¤¤ë¤«¤ò¤Ï¤Ã¤­¤ê¤µ¤»¤Þ¤·¤ç¤¦¡£ ¤¹¤Ù¤Æ¤Î¿Í¤Ï ¶õ ¤Î¥Ç¥£¥ì¥¯¥È¥ê¤«¤é»Ï¤á¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ¥Ä¥ê¡¼¤ò¥µ¥Ý¡¼¥È¤·¤Æ¤ë¤¢¤Ê¤¿¤Î CTM ¤ò²ÔƯ¤¹¤ë¤¿¤á¤Ë¤Ï »ØÄꤷ¤¿ ¶õ ¤Î¥Ç¥ë¥¿¤ò»È¤¦É¬Íפ¬¤¢¤ê¤Þ¤¹¡£¤¤¤¯¤Ä¤«¤Îʬ´ôÅÀ ¤Ç¤Ï¡¢¤¢¤Ê¤¿¤ÎÅÔ¹ç¤Ë¤è¤ê CD Æâ¤ËʬÇÛ¤µ¤ì¤Æ¤¤¤ë ¥¹¥¿¡¼¥¿ ¥Ç¥ë¥¿¤ò»ÈÍѤǤ­¤ë¤è¤¦¤Ë¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£¤·¤«¤·¤Ê¤¬¤é¡¢¤³¤ì¤Ï ÉÑÈˤ˹Ԥï¤ì¤ë¤³¤È¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£ ŬÀڤʽÐȯÅÀ¤¬·è¤Þ¤ì¤Ð¡¢¤½¤Î½ÐȯÅÀ¤ò CTM ¤¬ °Ý»ý¤¹¤ë¥Ä¥ê¡¼¤ØÊÑ´¹¤¹¤ë¤¿¤á¤Î ¥¹¥¿¡¼¥¿ ½é´ü¥Ç¥ë¥¿¤ò»È¤¦É¬Íפ¬ ¤¢¤ê¤Þ¤¹¡£ °Ü¹Ô¥Ç¥ë¥¿¤ÏÈÖ¹æ¤Î¸å¤í¤Ë X ¤ò¤Ä¤±¤¿¤â¤Î¤¬¤½¤¦¤Ç¤¹ (¤¿¤È¤¨¤Ð src-cur.3210XEmpty.gz)¡£ X ¤Î¸å¤í¤ÏºÇ½é¤Î³«»Ï¥Ý¥¤¥ó¥È¤ËÂбþ¤·¤Þ¤¹¡£ Empty ¤Ï ¶õ¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Ç¤¹¡£ ¥ë¡¼¥ë¤È¤·¤Æ Empty ¤«¤é¤Î°Ü¹Ô¥Ç¥ë¥¿¤Ï 100 ¥Ç¥ë¥¿¤´¤È¤Ë ºî¤é¤ì¤Þ¤¹¡£¤Á¤Ê¤ß¤Ë¡¢ ¤³¤ì¤é¤ÏÈó¾ï¤ËÂ礭¤¯¤Ê¤ê¤Þ¤¹! XEmpty¤Î¥Ç¥ë¥¿¤Ï 70 ¤«¤é 80MB ¤Î gzip ¤Ç°µ½Ì¤µ¤ì¤¿¥Ç¡¼¥¿¤È¤¤¤¦¤Î¤¬ÉáÄ̤Ǥ¹¡£ °ìÅÙ¥¹¥¿¡¼¥È¤¹¤ë¤¿¤á¤Î¥Ù¡¼¥¹¥Ç¥ë¥¿¤òÆÀ¤ë¤È¡¢ ¤½¤ì¤Ë³¤¯Â¿¿ô¤Î¤¹¤Ù¤Æ¤Î¥Ç¥ë¥¿¤âɬÍפˤʤë¤Ç¤·¤ç¤¦¡£ <application>CTM</application> ¤òÆü¾ï¤Ç»È¤¦ ¥Ç¥ë¥¿¤òŬÍѤ¹¤ë¤¿¤á¤Ë¤Ï¡¢Ã±¤Ë &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* ¤È¤·¤Þ¤¹¡£ CTM ¤Ï¤É¤ì¤¬ gzip ¤µ¤ì¤Æ¤¤¤ë¤«Íý²ò¤·¤Þ¤¹¡£ ½¾¤Ã¤ÆºÇ½é¤Ë gunzip ¤·¤Æ¤ª¤¯É¬ÍפϤ¢¤ê¤Þ¤»¤ó¡£ ¥Ç¥£¥¹¥¯¤ÎÀáÌó¤Ë¤â¤Ê¤ê¤Þ¤¹¡£ Á´ÂΤνèÍý¤Ë´Ø¤·¤Æ³Î¿®¤¹¤ë¤Þ¤Ç¤Ï CTM ¤Ï (¥½¡¼¥¹) ¥Ä¥ê¡¼¤ËÂФ·¤Æ ²¿¤â¤·¤Þ¤»¤ó¡£¤Þ¤¿¡¢¥Ç¥ë¥¿¤ò³Î¤«¤á¤ë¤¿¤á¤Ë¤Ï ¥Õ¥é¥°¤ò»È¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤³¤Î¥Õ¥é¥°¤¬¤¢¤ë¤È CTM ¤Ï¥Ä¥ê¡¼¤ËÂФ·¤Æ¼ÂºÝ¤Ë¤Ï²¿¤â¹Ô¤Ê¤¤¤Þ¤»¤ó¡£ ñ¤Ë¥Ç¥ë¥¿¤Î´°Á´À­¤ò³Îǧ¤·¡¢ ¸½ºß¤Î¥Ä¥ê¡¼¤ËÌäÂê¤Ê¤¯»ÈÍѤǤ­¤ë¤«¤ò³Îǧ ¤¹¤ë¤À¤±¤Ç¤¹¡£ CTM ¤Ë¤Ï¾¤Ë¤â¥ª¥×¥·¥ç¥ó¤¬¤¢¤ê¤Þ¤¹¡£¾ÜºÙ¤Ë´Ø¤·¤Æ¤Ï ¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸¤ò»²¾È¤¹¤ë¤«¥½¡¼¥¹¤ò¸«¤Æ¤¯¤À¤µ¤¤¡£ °Ê¾å¤Ç¤ä¤ë¤³¤È¤ÏËÜÅö¤ËÁ´Éô¤Ç¤¹¡£ ¿·¤·¤¤¥Ç¥ë¥¿¤òÆþ¼ê¤·¤¿»þ¤Ë¤Ï¡¢ ¥½¡¼¥¹¤òºÇ¿·¤Î¤â¤Î¤Ë¤¹¤ë¤¿¤á¤Ë¤½¤ì¤ò CTM¤ËÄ̤¹¤À¤±¤Ç¤¹¡£ ¤â¤·¥Ç¥ë¥¿¤òºÆ¥À¥¦¥ó¥í¡¼¥É¤¹¤ë¤Î¤¬ ¹ü¤ÎÀÞ¤ì¤ëºî¶È¤Ç¤¢¤ì¤Ð¡¢¥Ç¥ë¥¿¤ò¾Ã¤µ¤Ê¤¤¤Ç¤ª¤¤¤Æ¤¯¤À¤µ¤¤¡£ ¤Ê¤Ë¤«¤ª¤«¤·¤Ê¤³¤È¤¬µ¯¤³¤Ã¤¿¾ì¹ç¤Ë¤ÏÃÖ¤¤¤Æ¤ª¤±¤ÐÎɤ«¤Ã¤¿ ¤È»×¤¦¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¤â¤·¥Õ¥í¥Ã¥Ô¡¼¥Ç¥£¥¹¥¯¤·¤«»ý¤Ã¤Æ¤¤¤Ê¤¤¾õ¶· ¤Ç¤¢¤Ã¤Æ¤â¥³¥Ô¡¼¤ò¼è¤ë¤Î¤Ë fdwrite ¤ò»È¤¦¤³¤È¤ò¹Í¤¨¤Æ¤¯¤À¤µ¤¤¡£ ¥í¡¼¥«¥ë¤ÎÊѹ¹¤òÊݸ¤¹¤ë ³«È¯¼Ô¤È¤·¤Æ¤Ï¥½¡¼¥¹¥Ä¥ê¡¼Ãæ¤Î¥Õ¥¡¥¤¥ë¤ò »È¤Ã¤Æ¼Â¸³¤·¤¿¤êÊѹ¹¤·¤¿¤¯ ¤Ê¤ë¤â¤Î¤Ç¤¹¡£ CTM ¤Ï¥í¡¼¥«¥ë¤ÎÊѹ¹¤òÀ©¸Â¤Ä¤­¤Ç¥µ¥Ý¡¼¥È¤·¤Þ¤¹: ¥Õ¥¡¥¤¥ë foo ¤Î¸ºß¤ò¥Á¥§¥Ã¥¯¤¹¤ëÁ°¤Ë¡¢ foo.ctm ¤ò»²¾È¤·¤Ë¤¤¤­¤Þ¤¹¡£ ¤³¤Î¥Õ¥¡¥¤¥ë¤¬Â¸ºß¤¹¤ë¾ì¹ç¡¢CTM ¤Ï foo ¤ÎÂå¤ê¤Ë¤³¤ì¤ò½èÍý¤·¤Þ¤¹¡£ ¤³¤Îưºî¤Ï¥í¡¼¥«¥ë¤ÎÊѹ¹¤òÊÝ»ý¤¹¤ë´Êñ¤Ê¼êÃʤò Ä󶡤·¤Þ¤¹: ñ¤ËÊѹ¹¤·¤¿¤¤¥Õ¥¡¥¤¥ë¤ò³ÈÄ¥»Ò .ctm ÉÕ¤­¤Î¥Õ¥¡¥¤¥ë̾¤Ç ¥³¥Ô¡¼¤¹¤ë¤À¤±¤Ç¤¹¡£¤¢¤È¤Ï¼«Í³¤Ë¥³¡¼¥É¤ò¥Ï¥Ã¥¯¤Ç¤­¡¢ .ctm ¥Õ¥¡¥¤¥ë¤ÎÊý¤Ï CTM ¤¬ºÇ¿·¾õÂÖ¤ËÊݤäƤ¯¤ì¤Þ¤¹¡£ <application>CTM</application> ¤Î¤½¤Î¾¤ÎÌÌÇò¤¤¥ª¥×¥·¥ç¥ó ¹¹¿·¤ÇÊѹ¹¤µ¤ì¤ë¥Õ¥¡¥¤¥ë¤òÀµ³Î¤ËÃΤë CTM ¤Î¥½¡¼¥¹¥ê¥Ý¥¸¥È¥ê¤ËÂФ¹¤ëÊѹ¹¤Î¥ê¥¹¥È¤ò ¥ª¥×¥·¥ç¥ó¤ò»È¤Ã¤Æ·èÄꤹ¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¤³¤ì¤Ï¡¢Êѹ¹¤Î¥í¥°¤òÊݸ¤·¤¿¤¤¡¢ Êѹ¹¤µ¤ì¤¿¥Õ¥¡¥¤¥ë¤ò¤Ê¤ó¤é¤«¤ÎÊýË¡¤Ç Á°¡¦¸å½èÍý¤·¤¿¤¤¡¢ ¤Þ¤¿¤Ïñ¤Ë¤³¤À¤ï¤ê¤¿¤¤¾ì¹ç¤Ë¤Ï¡¢ Ìò¤ËΩ¤Ä¤Ç¤·¤ç¤¦¡£ ¹¹¿·Á°¤Ë¥Ð¥Ã¥¯¥¢¥Ã¥×¤ò¼è¤ë CTM ¤Î¹¹¿·¤Ë¤è¤Ã¤ÆÊѹ¹¤µ¤ì¤ë¥Õ¥¡¥¤¥ë¤¹¤Ù¤Æ¤Î¥Ð¥Ã¥¯¥¢¥Ã¥×¤ò ¼è¤ê¤¿¤¯¤Ê¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ¥ª¥×¥·¥ç¥ó¤ò»ØÄꤹ¤ë¤È CTM ¤Ï ¥Ç¥ë¥¿¤ÇÊѹ¹¤µ¤ì¤ë¥Õ¥¡¥¤¥ë¤¹¤Ù¤Æ¤ò backup-file ¤È¤·¤Æ¥Ð¥Ã¥¯¥¢¥Ã¥×¤¹¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£ ¹¹¿·¤ÇÊѹ¹¤µ¤ì¤ë¥Õ¥¡¥¤¥ë¤òÀ©¸Â¤¹¤ë CTM ¤Î¹¹¿·¤ÎÈϰϤòÀ©¸Â¤·¤¿¤ê°ìÏ¢¤Î¥Ç¥ë¥¿¤Î¤«¤é ¤Û¤ó¤Î¿ô¥Õ¥¡¥¤¥ë¤òÃê½Ð¤·¤¿¤¯¤Ê¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ ¤È ¥ª¥×¥·¥ç¥ó¤òÍѤ¤Àµµ¬É½¸½¤ò»ØÄꤹ¤ë¤³¤È¤Ç¡¢ CTM ¤¬½èÍý¤¹¤ë¥Õ¥¡¥¤¥ë¤Î¥ê¥¹¥È¤òÀ©¸æ¤¹¤ë¤³¤È¤¬ ¤Ç¤­¤Þ¤¹¡£ Î㤨¤Ð¡¢lib/libc/Makefile ¤ÎºÇ¿·¤Î¥³¥Ô¡¼¤òÊݸ¤·¤Æ¤¢¤ë CTM ¥Ç¥ë¥¿¤Î¥³¥ì¥¯¥·¥ç¥ó¤«¤éÃê½Ð¤¹¤ë¤Ë¤Ï¡¢ °Ê²¼¤Î¥³¥Þ¥ó¥É¤ò¼Â¹Ô¤·¤Þ¤¹¡£ &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* CTM ¥Ç¥ë¥¿¤Ç»ØÄꤵ¤ì¤¿¥Õ¥¡¥¤¥ë¤´¤È¤Ë¡¢ ¤½¤·¤Æ ¥ª¥×¥·¥ç¥ó¤¬¥³¥Þ¥ó¥É¥é¥¤¥ó¤Ç»ØÄꤵ¤ì¤¿½ç½ø¤ÇŬÍѤµ¤ì¤Þ¤¹¡£ ¤¹¤Ù¤Æ¤Î ¤½¤·¤Æ ¥ª¥×¥·¥ç¥ó¤¬Å¬ÍѤµ¤ì¤¿¸å¤Ë¹¹¿·ÂоݤÈÁªÂò¤µ¤ì¤¿¾ì¹ç¤Ë¸Â¤ê¡¢ CTM ¤Ï¤½¤Î¥Õ¥¡¥¤¥ë¤ò½èÍý¤·¤Þ¤¹¡£ <application>CTM</application>¤Î¾­Íè·×²è ½ÅÍפʤâ¤Î ¤Ê¤ó¤é¤«¤Î CTM ¥·¥¹¥Æ¥à¤Ø¤Îǧ¾Úµ¡¹½¤òÍѤ¤¡¢ÉÔÀµ¤Ê CTM ¤Î¹¹¿·¤Î¸¡½Ð¤ò²Äǽ¤È¤¹¤ë¡£ CTM ¤Ø¤Î¥ª¥×¥·¥ç¥ó¤òÀ°Íý¤¹¤ë¡£¤µ¤â¤Ê¤¤¤Èº®Í𤷡¢ ľ´Ñ¤ËÈ¿¤·¤¿¤â¤Î¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤½¤Î¾ ports ¥³¥ì¥¯¥·¥ç¥ó¤ËÂФ¹¤ë¥Ç¥ë¥¿¤â¤¢¤ë¤Î¤Ç¤¹¤¬¡¢ ¤³¤ì¤Ë¶½Ì£¤ò»ý¤Ã¤Æ¤¤¤ë¿Í¤Ï¤Þ¤À¾¯¤Ê¤¤¤è¤¦¤Ç¤¹¡£ CTM ¥µ¥¤¥È CTM/&os; ¤Ï°Ê²¼¤Î¥ß¥é¡¼¥µ¥¤¥È¤«¤é anonymous FTP ¤Ë¤è¤Ã¤ÆÆþ¼ê¤Ç¤­¤Þ¤¹¡£ ¤â¤· CTM ¤ò anonymous FTP ¤Ë¤è¤Ã¤Æ¼ê¤Ë¤¤¤ì¤ë¾ì¹ç¤Ï¡¢ ¶á¤¯¤Î¥µ¥¤¥È¤òÍøÍѤ¹¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ²¿¤«ÌäÂ꤬¤¢¤ë¾ì¹ç¤Ï¡¢&a.ctm-users.name; ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ËÁêÃ̤·¤Æ¤¯¤À¤µ¤¤¡£ ¥«¥ê¥Õ¥©¥ë¥Ë¥¢¡¢¥µ¥ó¥Õ¥é¥ó¥·¥¹¥³¶áÊÕ¡¢ ¸ø¼°¤Ê¥½¡¼¥¹ Æî¥¢¥Õ¥ê¥«¡¢ctm¡¢sup¡¢ CVSup¤Ê¤É¤Î¸Å¤¤º¹Ê¬¥Õ¥¡¥¤¥ë¤Î¥Ð¥Ã¥¯¥¢¥Ã¥×¥µ¡¼¥Ð ÂæÏÑ/Ãæ²Ú̱¹ñ ¶á¤¯¤Ë¥ß¥é¡¼¥µ¥¤¥È¤¬¤Ê¤¤¾ì¹ç¤ä¥ß¥é¡¼¤¬ÉÔ´°Á´¤Ê¾ì¹ç¤Ï¡¢ alltheweb ¤Î¤è¤¦¤Ê¸¡º÷¥¨¥ó¥¸¥ó¤ò»È¤Ã¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£ <application>Subversion</application> ¤ò»È¤¦ Subversion ¤Ï¤¸¤á¤Ë 2012 ǯ 7 ·î¤«¤é¡¢&os; ¤Ï¤¹¤Ù¤Æ¤Î¥½¡¼¥¹¥³¡¼¥É¡¢¥É¥­¥å¥á¥ó¥È¡¢Ports Collection ¤ò´ÉÍý¤¹¤ë¥á¥¤¥ó¤Î¥Ð¡¼¥¸¥ç¥ó´ÉÍý¥·¥¹¥Æ¥à¤Ë Subversion (svn) ¤ò»È¤Ã¤Æ¤¤¤Þ¤¹¡£ °ìÈÌŪ¤Ë¤Ï Subversion ¤Ï³«È¯¼Ô¸þ¤±¤Î¥Ä¡¼¥ë¤Ç¤¹¡£ ÂçÉôʬ¤Î¥æ¡¼¥¶¤Ï¡¢&os; ¤Î¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤Ë FreeBSD Update¡¢ Ports Collection ¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤Ë¤Ï Portsnap ¤ò»È¤¦¤Ù¤­¤Ç¤·¤ç¤¦¡£ Subversion ¤Ç¤Ï¡¢¥ê¥Ý¥¸¥È¥ê¤Î»ØÄê¤Ë protocol://hostname/path ·Á¼°¤Î URL ¤òÍѤ¤¤Þ¤¹¡£ °Ê²¼¤Ëµ­ºÜ¤µ¤ì¤Æ¤¤¤ë¤è¤¦¤Ë¡¢ ¥ß¥é¡¼¥µ¥¤¥È¤Ï°Û¤Ê¤ëÊ£¿ô¤Î¥×¥í¥È¥³¥ë¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£ ¥¢¥¯¥»¥¹¤¹¤ë FreeBSD ¤Î¥ê¥Ý¥¸¥È¥ê¤Ï¡¢¥Ñ¥¹ (path) ¤ÎºÇ½é¤Ç»ØÄꤷ¤Þ¤¹¡£ ¥ê¥Ý¥¸¥È¥ê¤Ï 3 ¤Ä¤¢¤ê¤Þ¤¹¡£ base ¤Ï &os; ¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤Î¥½¡¼¥¹¥³¡¼¥É¡¢ ports ¤Ï Ports Collection¡¢ ¤½¤·¤Æ doc ¤Ï¥É¥­¥å¥á¥ó¥È¤Î¥ê¥Ý¥¸¥È¥ê¤Ç¤¹¡£ ¤¿¤È¤¨¤Ð¡¢ svn://svn0.us-east.FreeBSD.org/ports/head/ ¤È¤¤¤¦ URL ¤Ï¡¢svn ¥×¥í¥È¥³¥ë¤Ë¤è¤ë svn0.us-east.FreeBSD.org ¥ß¥é¡¼¾å¤Î ports ¥ê¥Ý¥¸¥È¥ê¤Î¥á¥¤¥ó¥Ö¥é¥ó¥Á¤ò¼¨¤·¤Æ¤¤¤Þ¤¹¡£ ¥¤¥ó¥¹¥È¡¼¥ë ¥ê¥Ý¥¸¥È¥ê¤ÎÃæ¿È¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤Ç¤­¤ë¤è¤¦¡¢»öÁ°¤Ë Subversion ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤·¤Æ¤ª¤¯É¬Íפ¬¤¢¤ê¤Þ¤¹¡£ ¤â¤·¡¢¤¹¤Ç¤Ë ports ¥Ä¥ê¡¼¤¬ÍѰդ·¤Æ¤¢¤ì¤Ð¡¢ °Ê²¼¤Î¤è¤¦¤Ë¤·¤Æ Subversion ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤­¤Þ¤¹¡£ &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make install clean ¤â¤· ports ¥Ä¥ê¡¼¤òÍøÍѤǤ­¤Ê¤±¤ì¤Ð¡¢package ¤«¤é Subversion ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤­¤Þ¤¹¡£ &prompt.root; pkg_add -r subversion ¤â¤·¡¢packages ¤Î´ÉÍý¤Ë pkgng ¤ò»È¤Ã¤Æ¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢¤«¤ï¤ê¤Ë°Ê²¼¤Î¤è¤¦¤Ë¤·¤Æ Subversion ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤Ç¤­¤Þ¤¹¡£ &prompt.root; pkg install devel/subversion <application>Subversion</application> ¤Î¼Â¹Ô svn ¥³¥Þ¥ó¥É¤ò»È¤Ã¤Æ¡¢ ɬÍפʥê¥Ý¥¸¥È¥ê¤Î¥½¡¼¥¹¥³¡¼¥É¤ò°Ê²¼¤Î¤è¤¦¤Ë¤·¤Æ¥À¥¦¥ó¥í¡¼¥É¤·¤Þ¤¹¡£ ¤³¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Ë¤¢¤ë¥Õ¥¡¥¤¥ë¤ò ¥í¡¼¥«¥ëºî¶È¥³¥Ô¡¼ ¤È¸Æ¤Ó¤Þ¤¹¡£ ¤¹¤Ç¤Ë¥í¡¼¥«¥ë¥Ç¥£¥ì¥¯¥È¥ê¤¬Â¸ºß¤·¤Æ¤¤¤Æ¤â¡¢ ¤½¤ì¤¬ svn ¤Ë¤è¤Ã¤ÆÀ¸À®¤µ¤ì¤¿¥Ç¥£¥ì¥¯¥È¥ê¤Ç¤Ê¤±¤ì¤Ð¡¢ ¥Á¥§¥Ã¥¯¥¢¥¦¥È¤¹¤ëÁ°¤Ë̾Á°¤òÊѹ¹¤¹¤ë¤«¡¢ºï½ü¤·¤Æ¤¯¤À¤µ¤¤¡£ svn °Ê³°¤ÎÊýË¡¤ÇÍѰդµ¤ì¤¿¥Ç¥£¥ì¥¯¥È¥ê¤Ç¥Á¥§¥Ã¥¯¥¢¥¦¥È¤¹¤ë¤È¡¢ ¤¹¤Ç¤Ë¸ºß¤¹¤ë¥Õ¥¡¥¤¥ë¤È¡¢ ¥ê¥Ý¥¸¥È¥ê¤«¤é»ý¤Ã¤Æ¤­¤¿¥Õ¥¡¥¤¥ë¤È¤Î´Ö¤Ç¾×ÆÍ¤¬µ¯¤­¤Æ¤·¤Þ¤¤¤Þ¤¹¡£ °Ê²¼¤Î¤è¤¦¤ËÆþÎϤ·¤Æ¡¢¥ê¥Ý¥¸¥È¥ê¤«¤é¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; svn checkout svn-mirror/repository/branch lwcdir ¤³¤³¤Ç¡¢repository, branch ¤ª¤è¤Ó root ¤Ï°Ê²¼¤Î¤È¤ª¤ê¤Ç¤¹¡£ svn-mirror ¤Ï¡¢ Subversion ¥ß¥é¡¼¥µ¥¤¥È ¤Î¤Ò¤È¤Ä¤Î URL ¤Ç¤¹¡£ repository ¤Ë¤Ï¡¢ ¥×¥í¥¸¥§¥¯¥È¤Î¥ê¥Ý¥¸¥È¥ê¡¢¤¹¤Ê¤ï¤Á base, ports, ¤Þ¤¿¤Ï doc ¤Î¤É¤ì¤«¤Ò¤È¤Ä¤ò»ØÄꤷ¤Þ¤¹¡£ branch ¤Ï¡¢»È¤¦¥ê¥Ý¥¸¥È¥ê¤Ë¤è¤ê¤Þ¤¹¡£ ports ¤ª¤è¤Ó doc ¤Ç¤Ï¡¢¤Û¤È¤ó¤É¤ÎÊѹ¹¤¬ head ¥Ö¥é¥ó¥Á¤Ç¹Ô¤ï¤ì¤Þ¤¹¡£ base ¥ê¥Ý¥¸¥È¥ê¤Ç¤Ï¡¢head ¥Ö¥é¥ó¥Á¤Ç -CURRENT ¤ÎºÇ¿·¥Ð¡¼¥¸¥ç¥ó¤ò´ÉÍý¤·¤Æ¤¤¤Þ¤¹¡£ -STABLE ¥Ö¥é¥ó¥Á¤ÎºÇ¿·¥Ð¡¼¥¸¥ç¥ó¤Ï¡¢8.x ¤Ï stable/8¡¢ 9.x ¤Ï stable/9 ¤Ç´ÉÍý¤·¤Æ¤¤¤Þ¤¹¡£ lwcdir ¤Ï¡¢ »ØÄꤷ¤¿¥Ö¥é¥ó¥Á¤ÎÃæ¿È¤¬ÃÖ¤«¤ì¤ë¥¿¡¼¥²¥Ã¥È¤Î¥Ç¥£¥ì¥¯¥È¥ê¤Ç¤¹¡£ Ä̾ï ports ¤Ï /usr/ports¡¢ base ¤Ï /usr/src¡¢ ¤½¤·¤Æ doc ¤Ç¤Ï /usr/doc ¤È»ØÄꤷ¤Þ¤¹¡£ °Ê²¼¤ÎÎã¤Ç¤Ï¡¢Ports Collection ¤ò western US ¥ê¥Ý¥¸¥È¥ê¤«¤é HTTPS ¥×¥í¥È¥³¥ë¤ò»È¤Ã¤Æ¡¢¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¤Þ¤¹¡£ ¤½¤·¤Æ¤½¤ì¤é¤Ï¡¢ /usr/ports ¤Î¥í¡¼¥«¥ëºî¶È¥³¥Ô¡¼¤ËÃÖ¤«¤ì¤Þ¤¹¡£ ¤â¤· /usr/ports ¤¬¤¹¤Ç¤Ë¸ºß¤·¤Æ¡¢ ¤½¤ì¤¬ svn ¤Ë¤è¤Ã¤ÆÀ¸À®¤µ¤ì¤¿¤â¤Î¤Ç¤Ê¤±¤ì¤Ð¡¢ ¥Á¥§¥Ã¥¯¥¢¥¦¥È¤¹¤ëÁ°¤Ë¡¢Ì¾Á°¤òÊѹ¹¤¹¤ë¤«ºï½ü¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; svn checkout https://svn0.us-west.FreeBSD.org/ports/head /usr/ports ½é¤á¤Æ¥Á¥§¥Ã¥¯¥¢¥¦¥È¤¹¤ëºÝ¤Ë¤Ï¡¢ ¥ê¥â¡¼¥È¥ê¥Ý¥¸¥È¥ê¤Î¤¹¤Ù¤Æ¤Î¥Ö¥é¥ó¥Á¤ò¥À¥¦¥ó¥í¡¼¥É¤¹¤ë¤Î¤Ç»þ´Ö¤¬¤«¤«¤ê¤Þ¤¹¡£ ¤É¤¦¤¾²æËý¤·¤Æ¤¯¤À¤µ¤¤¡£ ½é¤á¤Æ¤Î¥Á¥§¥Ã¥¯¥¢¥¦¥È¸å¤Ï¡¢ °Ê²¼¤ò¼Â¹Ô¤¹¤ë¤³¤È¤Ç¥í¡¼¥«¥ëºî¶È¥³¥Ô¡¼¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤Ç¤­¤Þ¤¹¡£ &prompt.root; svn update lwcdir ¤³¤ÎÎã¤ÇºîÀ®¤µ¤ì¤¿ /usr/ports ¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤Ë¤Ï¡¢ °Ê²¼¤Î¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; svn update /usr/ports ¥¢¥Ã¥×¥Ç¡¼¥È¤Ï¥Á¥§¥Ã¥¯¥¢¥¦¥È¤Ë¤¯¤é¤Ù¡¢ Êѹ¹ÅÀ¤Î¤¢¤ë¥Õ¥¡¥¤¥ë¤Î¤ß¤¬Å¾Á÷¤µ¤ì¤ë¤Î¤Ç¹â®¤Ç¤¹¡£ ¥Á¥§¥Ã¥¯¥¢¥¦¥È¸å¡¢¥í¡¼¥«¥ëºî¶È¥³¥Ô¡¼¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤â¤¦¤Ò¤È¤Ä¤ÎÊýË¡¤Ï¡¢ /usr/ports, /usr/src ¤Þ¤¿¤Ï /usr/doc ¥Ç¥£¥ì¥¯¥È¥ê¤Î Makefile ¤ÇÄ󶡤µ¤ì¤Æ¤¤¤Þ¤¹¡£ SVN_UPDATE ¤òÀßÄꤷ¤Æ update ¥¿¡¼¥²¥Ã¥È¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¤¿¤È¤¨¤Ð¡¢/usr/src ¤ò¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤Ë¤Ï¡¢°Ê²¼¤Î¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ &prompt.root; cd /usr/src &prompt.root; make update SVN_UPDATE=yes ¤è¤ê¾Ü¤·¤¤¾ðÊó Subversion ¤ÎÍøÍѤ˴ؤ¹¤ë¾¤Î¾ðÊó¤Ï¡¢Version Control with Subversion ¤ä Subversion Documentation ¤È¤¤¤Ã¤¿ Subversion Book ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ <application>Subversion</application> ¥ß¥é¡¼¥µ¥¤¥È Subversion Repository ¥ß¥é¡¼¥µ¥¤¥È ¤¹¤Ù¤Æ¤Î¥ß¥é¡¼¤Ï¤¹¤Ù¤Æ¤Î¥ê¥Ý¥¸¥È¥ê¤ò»ý¤Ã¤Æ¤¤¤Þ¤¹¡£ &os; Subversion ¥µ¡¼¥Ð¤Î¥Þ¥¹¥¿¤Ç¤¢¤ë svn.FreeBSD.org ¤Ï¡¢ ¸ø¤Ë¤ÏÆÉ¤ß½Ð¤·ÀìÍѤǥ¢¥¯¥»¥¹¤Ç¤­¤Þ¤¹¤¬¡¢ ¾­ÍèŪ¤Ë¤ÏÊѹ¹¤µ¤ì¤ëͽÄê¤Ç¤¹¤Î¤Ç¡¢ ¥ª¥Õ¥£¥·¥ã¥ë¥ß¥é¡¼¤ò»È¤¦¤³¤È¤¬¿ä¾©¤µ¤ì¤Þ¤¹¡£ ¥Ö¥é¥¦¥¶¤òÍѤ¤¤Æ &os; ¤Î Subversion ¥ê¥Ý¥¸¥È¥ê¤ò»²¾È¤¹¤ë¤Ë¤Ï¡¢http://svnweb.FreeBSD.org/ ¤òÍøÍѤ·¤Æ¤¯¤À¤µ¤¤¡£ &os; ¤Î svn ¥ß¥é¡¼¥Í¥Ã¥È¥ï¡¼¥¯¤Ï¡¢ ¤Þ¤À½é´ü¤ÎÃʳ¬¤Ë¤¢¤ë¤Î¤Ç¡¢º£¸åÊѹ¹¤µ¤ì¤ë¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ °Ê²¼¤Î¥ß¥é¡¼°ìÍ÷¤òÉÔÊѤʤâ¤Î¤È¤Ï¹Í¤¨¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£ ÆÃ¤Ë¡¢¥µ¡¼¥Ð¤Î SSL ¾ÚÌÀ½ñ¤Ï¡¢¤¤¤º¤ì¤«¤Î»þÅÀ¤ÇÊѹ¹¤Ë¤Ê¤ë¤Ç¤·¤ç¤¦¡£ ̾Á° ¥×¥í¥È¥³¥ë °ÌÃÖ SSL ¥Õ¥£¥ó¥¬¡¼¥×¥ê¥ó¥È svn0.us-west.FreeBSD.org svn, http, https USA, ¥«¥ê¥Õ¥©¥ë¥Ë¥¢ SHA1 - 79:35:8F:CA:6D:34:D9:30:44:D1:00:AF:33:4D:E6:11:44:4D:15:EC + 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 svn0.us-east.FreeBSD.org svn, http, https, rsync USA, ¥Ë¥å¡¼¥¸¥ã¡¼¥¸ SHA1 - 06:D1:23:DE:5E:7A:F7:2B:7A:7E:74:95:5F:54:8D:5C:B0:D6:2E:8F + 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 svn0.eu.FreeBSD.org svn, http, https, rsync Europe, UK SHA1 39:B0:53:35:CE:60:C7:BB:00:54:96:96:71:10:94:BB:CE:1C:07:A7 HTTPS ¤Ï¿ä¾©¤µ¤ì¤Æ¤¤¤ë¥×¥í¥È¥³¥ë¤Ç¤¹¡£ ¾¤Î¥³¥ó¥Ô¥å¡¼¥¿¤¬ &os; ¥ß¥é¡¼¤òÁõ¤¦ (°ìÈÌŪ¤Ë¤Ï ¥Þ¥ó¡¦¥¤¥ó¡¦¥¶¡¦¥ß¥É¥ë ¹¶·â¤È¤·¤ÆÃΤé¤ì¤Æ¤¤¤Þ¤¹) ¤³¤È¤ä¡¢ ¤â¤·¤¯¤Ï¡¢¥¨¥ó¥É¥æ¡¼¥¶¤ËÂФ·¹¥¤Þ¤·¤¯¤Ê¤¤ÆâÍÆ¤òÁ÷¤ê¤Ä¤±¤è¤¦¤È¤¤¤¦¤³¤È¤ËÂФ·Êݸî¤ò¹Ô¤¤¤Þ¤¹¡£ HTTPS ¥ß¥é¡¼¤Ø¤ÎºÇ½é¤ÎÀܳ¤ÎºÝ¤Ë¤Ï¡¢ ¥µ¡¼¥Ð¤Î ¥Õ¥£¥ó¥¬¡¼¥×¥ê¥ó¥È ¤Î³Îǧ¤òµá¤á¤é¤ì¤Þ¤¹¡£ Error validating server certificate for 'https://svn0.us-west.freebsd.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! + - The certificate hostname does not match. Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - - Valid: from Fri, 24 Aug 2012 22:04:04 GMT until Sat, 24 Aug 2013 22:04:04 GMT - - Issuer: clusteradm, FreeBSD.org, CA, US - - Fingerprint: 79:35:8f:ca:6d:34:d9:30:44:d1:00:af:33:4d:e6:11:44:4d:15:ec + - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT + - Issuer: clusteradm, FreeBSD.org, (null), CA, US (clusteradm@FreeBSD.org) + - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 (R)eject, accept (t)emporarily or accept (p)ermanently? ¥Õ¥£¥ó¥¬¡¼¥×¥ê¥ó¥È¤ò¾å¤Îɽ¤Î°ìÍ÷¤Î¤â¤Î¤È¾È¹ç¤·¤Æ¤¯¤À¤µ¤¤¡£ ¥Õ¥£¥ó¥¬¡¼¥×¥ê¥ó¥È¤¬°ìÃפ·¤¿¤é¡¢ ¥µ¡¼¥Ð¤Î¥»¥­¥å¥ê¥Æ¥£¾ÚÌÀ½ñ¤ò°ì»þŪ (permanently) ¤â¤·¤¯¤Ï¹±µ×Ū (temporarily) ¤Ë¼õ¤±Æþ¤ì¤Æ¤¯¤À¤µ¤¤¡£ °ì»þŪ¤Êǧ¾Ú¤Ç¤¢¤ì¤Ð¡¢¥µ¡¼¥Ð¤È¤Î°ì²ó¤Î¥»¥Ã¥·¥ç¥ó¤ÇÍ­¸ú´ü¸Â¤¬ÀÚ¤ì¤ë¤¿¤á¡¢ ¼¡²ó¤ÎÀܳ»þ¤Ë¤Ï¤â¤¦°ìÅÙ¸¡¾Ú¤¬¹Ô¤ï¤ì¤Þ¤¹¡£ ¹±¾ïŪ¤Êǧ¾Ú¤òÁª¤ó¤À¾ì¹ç¤Ë¤Ï¡¢Ç§¾Ú¤Î¤¿¤á¤Î¾ÚÌÀ½ñ¤¬ ~/.subversion/auth/ ¤ËÊݸ¤µ¤ì¡¢ Í­¸ú´ü¸Â¤¬ÀÚ¤ì¤ë¤Þ¤Ç¤Ï¡¢¥Õ¥£¥ó¥¬¡¼¥×¥ê¥ó¥È¤Î³Îǧ¤Ïµá¤á¤é¤ì¤Þ¤»¤ó¡£ ¥Õ¥¡¥¤¥¢¥¦¥©¡¼¥ë¤Þ¤¿¤Ï¾¤ÎÌäÂê¤Î¤¿¤á¡¢HTTPS ¤ò»È¤¨¤Ê¤±¤ì¤Ð¡¢Å¾Á÷®ÅÙ¤¬¤è¤ê¾¯¤·Áᤤ SVN ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ξÊý¤ò»È¤¨¤Ê¤¤¾ì¹ç¤Ë¤Ï¡¢ HTTP ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ CVSup ¤ò»È¤¦ (Èó¿ä¾©) Ìõ: &a.jp.iwasaki;¡¢1997 ǯ 2 ·î 27 Æü ¾Ò²ð cvsup ¤Ï¡¢ ¥×¥í¥¸¥§¥¯¥È¤Ë¤ª¤¤¤Æ»ÈÍѤµ¤ì¤Ê¤¯¤Ê¤Ã¤¿¤¿¤á¡¢ Èó¿ä¾©¤Ë¤Ê¤ê¤Þ¤·¤¿¡£ ¤«¤ï¤ê¤Ë Subversion ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ CVSup ¤Ï¡¢ ¥ê¥â¡¼¥È¤Î¥µ¡¼¥Ð¥Û¥¹¥È¤Ë¤¢¤ë¥Þ¥¹¥¿ CVS ¥ê¥Ý¥¸¥È¥ê¤«¤é ¥½¡¼¥¹¥Ä¥ê¡¼¤òÇÛÉÛ¤·¹¹¿·¤¹¤ë¤¿¤á¤Î ¥½¥Õ¥È¥¦¥§¥¢¥Ñ¥Ã¥±¡¼¥¸¤Ç¤¹¡£&os; ¤Î¥½¡¼¥¹¤Ï¡¢ ¥«¥ê¥Õ¥©¥ë¥Ë¥¢¤Ë¤¢¤ëÃæ¿´Åª¤Ê³«È¯¥Þ¥·¥ó¤Î CVS ¥ê¥Ý¥¸¥È¥ê¤Î Ãæ¤Ç¥á¥ó¥Æ¥Ê¥ó¥¹¤·¤Æ¤¤¤Þ¤¹¡£CVSup ¤ò»ÈÍѤ¹¤ë¤³¤È¤Ç¡¢&os; ¥æ¡¼¥¶¤Ï ´Êñ¤Ë¼«Ê¬¤Î¥½¡¼¥¹¥Ä¥ê¡¼¤òºÇ¿·¤Î¾õÂÖ¤Ë ¤·¤Æ¤ª¤¯¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ CVSup ¤Ï pull ¥â¥Ç¥ë¤È¤è¤Ð¤ì¤ë¹¹¿·¤Î¥â¥Ç¥ë¤òºÎÍѤ·¤Æ¤¤¤Þ¤¹¡£pull ¥â¥Ç¥ë¤Ç¤Ï¡¢ ³Æ¥¯¥é¥¤¥¢¥ó¥È¤¬¹¹¿·¤·¤¿¤¤¾ì¹ç¤Ë¹¹¿·¤·¤¿¤¤»þÅÀ¤Ç¡¢ ¥µ¡¼¥Ð¤Ë¹¹¿·¤ÎÌ䤤¹ç¤ï¤»¤ò¤ª¤³¤Ê¤¤¤Þ¤¹¡£ ¥µ¡¼¥Ð¤Ï¥¯¥é¥¤¥¢¥ó¥È¤«¤é¤Î ¹¹¿·¤ÎÍ×µá¤ò¼õ¤±¿È¤Î¾õÂÖ¤ÇÂÔ¤Á¤Þ¤¹¡£¤·¤¿¤¬¤Ã¤Æ¡¢ ¤¹¤Ù¤Æ¤Î¹¹¿·¤Ï¥¯¥é¥¤¥¢¥ó¥È¼çƳ¤Ç¤ª¤³¤Ê¤ï¤ì¤Þ¤¹¡£ ¥µ¡¼¥Ð¤ÏÍê¤Þ¤ì¤â¤·¤Ê¤¤¹¹¿·¾ðÊó¤òÁ÷¤ë¤è¤¦¤Ê¤³¤È¤Ï¤·¤Þ¤»¤ó¡£ ¥æ¡¼¥¶¤Ï CVSup ¥¯¥é¥¤¥¢¥ó¥È¤ò¼êư¤Ç¼Â¹Ô¤·¤Æ¹¹¿·¤ò¤ª¤³¤Ê¤¦¤«¡¢ cron ¥¸¥ç¥Ö¤òÀßÄꤷ¤ÆÄê´üŪ¤Ë¼«Æ°¼Â¹Ô¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ÍѸì CVSup ¤Î¤è¤¦¤ËÂçʸ»ú¤Çɽµ­¤·¤Æ¤¤¤ë¤â¤Î¤Ï¡¢¥½¥Õ¥È¥¦¥§¥¢¥Ñ¥Ã¥±¡¼¥¸ Á´ÂΤò»Ø¤·¤Þ¤¹¡£¼ç¤Ê¹½À®Êª¤Ï¡¢ ³Æ¥æ¡¼¥¶¥Þ¥·¥ó¤Ç¼Â¹Ô¤¹¤ë¥¯¥é¥¤¥¢¥ó¥È¤Ç¤¢¤ë cvsup¡¢&os; ¤Î³Æ¥ß¥é¡¼¥µ¥¤¥È¤Ç¼Â¹Ô¤¹¤ë¥µ¡¼¥Ð cvsupd ¤Ç¤¹¡£ csup ¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤Ï CVSup ¥½¥Õ¥È¥¦¥§¥¢¤ò C ¸À¸ì¤Ç½ñ¤­Ä¾¤·¤¿¤â¤Î¤Ç¤¹¡£ ½èÍý®ÅÙ¤¬Â®¤¯¡¢¤Þ¤¿¡¢Modula-3 ¸À¸ì¤ò»È¤ï¤Ê¤¤¤¿¤á¡¢ Modula-3 ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤»¤ó¡£ ¤µ¤é¤Ë¡¢¥Ù¡¼¥¹¥·¥¹¥Æ¥à¤Ë´Þ¤Þ¤ì¤Æ¤¤¤ë¤Î¤Ç¡¢ ¤¹¤°¤Ë»È¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ csup ¤ò»È¤¦¾ì¹ç¤Ï¡¢ CVSup ¤Î¥¤¥ó¥¹¥È¡¼¥ë¤ò¾Êά¤·¡¢ °Ê²¼¤Îʸ¾ÏÃæ¤Î CVSup ¤ò csup ¤ËÃÖ¤­¤«¤¨¤ÆÆÉ¤ó¤Ç¤¯¤À¤µ¤¤¡£ ¥¤¥ó¥¹¥È¡¼¥ë CVSup ¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ëºÇ¤â´Êñ¤ÊÊýË¡¤Ï¡¢&os; Ports ¥³¥ì¥¯¥·¥ç¥ó¤Î¥Ñ¥Ã¥±¡¼¥¸ ¤«¤é¥³¥ó¥Ñ¥¤¥ëºÑ¤ß¤Î net/cvsup ¥Ñ¥Ã¥±¡¼¥¸¤ò¥¤¥ó¥¹¥È¡¼¥ë¤¹¤ë¤³¤È¤Ç¤¹¡£ ¤â¤·¤¯¤Ï¡¢net/cvsup ¤Ç¤â¹½¤¤¤Þ¤»¤ó¡£ ¤¿¤À¤·¡¢net/cvsup ¤Ï Modula-3 ¥·¥¹¥Æ¥à¤Ë°Í¸¤·¤Æ¤¤¤Æ¡¢¹½Ãۤˤ«¤«¤ë»þ´Ö¡¢ ¥Ç¥£¥¹¥¯¥¹¥Ú¡¼¥¹¤ÏÈæ³ÓŪÂ礭¤¯¤Ê¤ê¤Þ¤¹¡£ ¤¿¤È¤¨¤Ð¥µ¡¼¥Ð¤Î¤è¤¦¤Ê &xorg; ¤¬¥¤¥ó¥¹¥È¡¼¥ë¤µ¤ì¤Æ¤¤¤Ê¤¤·×»»µ¡¤Ç CVSup ¤ò»È¤ª¤¦¤È¤·¤Æ¤¤¤ë¤Î¤Ç¤¢¤ì¤Ð¡¢É¬¤º CVSup GUI ¤¬´Þ¤Þ¤ì¤Æ¤¤¤Ê¤¤ net/cvsup-without-gui ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ CVSup ¤Î¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó CVSup ¤Îưºî¤Ï¡¢supfile ¤È¸Æ¤Ð¤ì¤ë¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤ÇÀ©¸æ¤·¤Þ¤¹¡£ supfile ¤Î¥µ¥ó¥×¥ë¤Ï¡¢¥Ç¥£¥ì¥¯¥È¥ê /usr/share/examples/cvsup/ ¤Î²¼¤Ë¤¢¤ê¤Þ¤¹¡£ supfile ¤Ë¤Ï°Ê²¼¤Î CVSup ¤Ë´Ø¤¹¤ë¼ÁÌ䤨¤ÎÅú¤¨¤òµ­½Ò¤·¤Þ¤¹: ¤É¤Î¥Õ¥¡¥¤¥ë¤ò¼õ¤±¼è¤ê¤¿¤¤¤Î¤«? ¤É¤Î¥Ð¡¼¥¸¥ç¥ó¤Î¤â¤Î¤¬Íߤ·¤¤¤Î¤«? ¤É¤³¤«¤éÆþ¼ê¤·¤¿¤¤¤Î¤«? ¼«Ê¬¤Î¥Þ¥·¥ó¤Î¤É¤³¤ËÃÖ¤­¤¿¤¤¤Î¤«? ¤É¤³¤Ë status ¥Õ¥¡¥¤¥ë¤òÃÖ¤­¤¿¤¤¤Î¤«? ¼¡¤Î¥»¥¯¥·¥ç¥ó¤Ç¡¢¤³¤ì¤é¤Î¼ÁÌä¤Ë½çÈÖ¤ËÅú¤¨¤Ê¤¬¤éŵ·¿Åª¤Ê supfile ¤òÁȤßΩ¤Æ¤Æ¤¤¤­¤Þ¤¹¡£ºÇ½é¤Ë supfile ¤ÎÁ´Âι½Â¤¤òÀâÌÀ¤·¤Þ¤¹¡£ supfile ¤Ï¥Æ¥­¥¹¥È¥Õ¥¡¥¤¥ë¤Ç¤¹¡£ ¥³¥á¥ó¥È¤Ï # ¤«¤é¹ÔËö¤Þ¤Ç¤Ç¤¹¡£ ¶õ¹Ô¤È¥³¥á¥ó¥È¤À¤±¤Î¹Ô¤Ï̵»ë¤·¤Þ¤¹¡£ »Ä¤ê¤Î³Æ¹Ô¤Ë¤Ï¡¢ ¥æ¡¼¥¶¤¬¼õ¤±¼è¤ê¤¿¤¤¥Õ¥¡¥¤¥ë·²¤Ë¤Ä¤¤¤Æµ­½Ò¤·¤Þ¤¹¡£ ¹Ô¤Î»Ï¤á¤Ï¡¢ ¥µ¡¼¥Ð¦¤ÇÄêµÁ¤·¤¿ÏÀÍýŪ¤Ê¥Õ¥¡¥¤¥ë¤Î¥°¥ë¡¼¥×¤Ç¤¢¤ë ¥³¥ì¥¯¥·¥ç¥ó ¤Î̾¾Î¤Ç¤¹¡£ ¥³¥ì¥¯¥·¥ç¥ó¤Î̾¾Î¤ò»ØÄꤷ¤Æ¡¢Íߤ·¤¤¥Õ¥¡¥¤¥ë·²¤ò ¥µ¡¼¥Ð¤ËÅÁ¤¨¤Þ¤¹¡£¥³¥ì¥¯¥·¥ç¥ó̾¤Î¸å¤Ë¤Ï¡¢ ¥Û¥ï¥¤¥È¥¹¥Ú¡¼¥¹¤Ç¶èÀÚ¤é¤ì¤¿ 0 ¸Ä°Ê¾å¤Î¥Õ¥£¡¼¥ë¥É¤¬Â³¤­¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥Õ¥£¡¼¥ë¥É¤¬¾åµ­¤Î¼ÁÌä¤ËÂФ¹¤ëÅú¤¨¤Ë¤Ê¤ê¤Þ¤¹¡£ ¥Õ¥£¡¼¥ë¥É¤Ë¤Ï 2 ¼ïÎढ¤ê¤Þ¤¹: flag ¥Õ¥£¡¼¥ë¥É¤È value ¥Õ¥£¡¼¥ë¥É¤Ç¤¹¡£flag ¥Õ¥£¡¼¥ë¥É¤Ï delete ¤ä compress ¤Î¤è¤¦¤Ê ñÆÈ¤Î¥­¡¼¥ï¡¼¥É¤«¤éÀ®¤ê¤Þ¤¹¡£¤Þ¤¿¡¢value ¥Õ¥£¡¼¥ë¥É¤â¥­¡¼¥ï¡¼¥É¤Ç»Ï¤Þ¤ê¤Þ¤¹¤¬¡¢ ¥­¡¼¥ï¡¼¥É¤Î¸å¤Ë¤Ï¥Û¥ï¥¤¥È¥¹¥Ú¡¼¥¹¤ÏÆþ¤é¤º¡¢ = ¤ÈÆó¤Ä¤á¤Îñ¸ì¤¬Â³¤­¤Þ¤¹¡£Î㤨¤Ð¡¢ release=cvs ¤Ï value ¥Õ¥£¡¼¥ë¥É¤Ç¤¹¡£ Ä̾supfile ¤Ë¤Ï¼õ¤±¼è¤ê¤¿¤¤¥³¥ì¥¯¥·¥ç¥ó¤ò°ì¤Ä°Ê¾å»ØÄꤷ¤Þ¤¹¡£ supfile ¤òÁȤßΩ¤Æ¤ë°ì¤Ä¤ÎÊýË¡¤È¤·¤Æ¡¢ ¥³¥ì¥¯¥·¥ç¥óËè¤Ë¤¹¤Ù¤Æ¤Î´Ø·¸¤Î ¤¢¤ë¥Õ¥£¡¼¥ë¥É¤òÌÀ¼¨Åª¤Ë»ØÄꤹ¤ëÊýË¡¤¬¤¢¤ê¤Þ¤¹¡£¤·¤«¤·¡¢ ¤³¤ì¤Ç¤Ï supfile ¤Î¤¹¤Ù¤Æ¤Î¥³¥ì¥¯¥·¥ç¥ó¤ËÂФ·¤Æ ¤Û¤È¤ó¤É¤Î¥Õ¥£¡¼¥ë¥É¤¬Æ±¤¸¤Ë¤Ê¤ë¤¿¤á¡¢ ¹Ô¤¬Èó¾ï¤ËŤ¯¤Ê¤Ã¤Æ¤·¤Þ¤¤ÉÔÊØ¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤³¤ì¤é¤ÎÌäÂê¤òÈò¤±¤ë¤¿¤á¡¢CVSup ¤Ç¤Ï¥Ç¥Õ¥©¥ë¥È¤ò»ØÄꤹ¤ë¤³¤È¤Î¤Ç¤­¤ë ¥á¥«¥Ë¥º¥à¤¬Ä󶡤µ¤ì¤Æ¤¤¤Þ¤¹¡£ÆÃ¼ì¤Êµ¼»÷¥³¥ì¥¯¥·¥ç¥ó̾ *default ¤Ç»Ï¤Þ¤ë¹Ô¤Ï¡¢ supfile Ãæ¤Î¸å³¤Î ¥³¥ì¥¯¥·¥ç¥ó¤ËÂФ·¤Æ»ÈÍѤ¹¤ë flag ¥Õ¥£¡¼¥ë¥É¤È value ¥Õ¥£¡¼¥ë¥É¤Î¥Ç¥Õ¥©¥ë¥È¤òÀßÄꤹ¤ë¤¿¤á¤ËÍøÍѤǤ­¤Þ¤¹¡£ ¸Ä¡¹¤Î¥³¥ì¥¯¥·¥ç¥ó¤Ç¸ÇÍ­¤ÎÃͤò»ØÄꤹ¤ë¤È¡¢ ¥Ç¥Õ¥©¥ë¥ÈÃͤò̵¸ú¤Ë¤Ç¤­¤Þ¤¹¡£¤Þ¤¿ ¹Ô¤òÄɲ乤ë¤È¡¢supfile ¤ÎÅÓÃæ¤«¤é¥Ç¥Õ¥©¥ë¥ÈÃͤÎÊѹ¹¤äÄɲ䬲Äǽ¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤³¤ì¤Þ¤Ç¤ÎͽÈ÷Ã챤ò´ð¤Ë¡¢ &os;-CURRENT ¤Î¥á¥¤¥ó¤Î¥½¡¼¥¹¥Ä¥ê¡¼¤ò¼õ¤±¼è¤Ã¤Æ¹¹¿·¤¹¤ë¤¿¤á¤Î supfile ¤òÁȤßΩ¤Æ¤Æ¤ß¤Þ¤·¤ç¤¦¡£ ¤É¤Î¥Õ¥¡¥¤¥ë¤ò¼õ¤±¼è¤ê¤¿¤¤¤Î¤«? CVSup ¤òÄ̤·¤ÆÆþ¼ê¤Ç¤­¤ë¥Õ¥¡¥¤¥ë¤Ï ¥³¥ì¥¯¥·¥ç¥ó ¤È¸Æ¤Ð¤ì¤ë̾Á°¤ÎÉÕ¤±¤é¤ì¤¿¥°¥ë¡¼¥×¤Ë¤Þ¤È¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£ ÍøÍѲÄǽ¤Ê¥³¥ì¥¯¥·¥ç¥ó¤Ë¤Ä¤¤¤Æ¤Ï ¸å¤ÎÀá¤ÎÃæ¤ÇÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ ¤³¤³¤Ç¤Ï¡¢&os; ¥·¥¹¥Æ¥à¤Î¥á¥¤¥ó¤Î¥½¡¼¥¹¥Ä¥ê¡¼Á´ÂÎ ¤ò¼õ¤±¼è¤ë¤¿¤á¤ÎÀßÄêÎã¤ò¾Ò²ð¤·¤Þ¤¹¡£ ¤¹¤Ù¤Æ¤ò´Þ¤à src-all ¤È¤¤¤¦Ã±°ì¤ÎÂ礭¤Ê¥³¥ì¥¯¥·¥ç¥ó¤¬¤¢¤ê¤Þ¤¹¡£ supfile ¤òÁȤßΩ¤Æ¤ëºÇ½é¤Î¥¹¥Æ¥Ã¥×¤È¤·¤Æ¡¢ ¤³¤ì¤é¤Î¥³¥ì¥¯¥·¥ç¥ó¤ò°ì¹Ô¤Ë°ì¤Ä¤º¤Äµ­½Ò¤·¤Þ¤¹ (¤³¤Î¾ì¹ç¤Ï°ì¹Ô¤À¤±¤Ç¤¹)¡£ src-all ¤É¤Î¥Ð¡¼¥¸¥ç¥ó¤Î¤â¤Î¤¬Íߤ·¤¤¤Î¤«? CVSup ¤ò»ÈÍѤ¹¤ë¤È¡¢ ¤«¤Ä¤ÆÂ¸ºß¤·¤Æ¤¤¤¿¤³¤È¤Î¤¢¤ë¡¢»ö¼Â¾å¤É¤Î¥Ð¡¼¥¸¥ç¥ó¤Î ¥½¡¼¥¹¤Ç¤â¼õ¤±¼è¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£¤³¤ì¤Ï cvsupd ¥µ¡¼¥Ð¤¬¤¹¤Ù¤Æ¤Î¥Ð¡¼¥¸¥ç¥ó¤ò´Þ¤à CVS ¥ê¥Ý¥¸¥È¥ê¤Ë´ð¤Å¤¤¤ÆÆ°ºî¤¹¤ë¤³¤È¤Ë¤è¤ê¡¢ ¼Â¸½¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ tag= ¤ª¤è¤Ó ¤Î value ¥Õ¥£¡¼¥ë¥É¤ò»ÈÍѤ·¤Æ¡¢ Íߤ·¤¤¥Ð¡¼¥¸¥ç¥ó¤Î °ì¤Ä¤ò»ØÄꤷ¤Þ¤¹¡£ tag= ¤Î¥Õ¥£¡¼¥ë¥É¤Î»ØÄê¤ÏÀµ³Î¤Ë¹Ô¤¦¤è¤¦¤Ë½½Ê¬Ãí°Õ ¤·¤Æ¤¯¤À¤µ¤¤¡£¤¤¤¯¤Ä¤«¤Î¥¿¥°¤ÏÆÃÄê¤Î¥³¥ì¥¯¥·¥ç¥ó¤Ë ÂФ·¤Æ¤Î¤ßÍ­¸ú¤Ç¤¹¡£ ¥¿¥°¤ÎÄ֤꤬°ã¤Ã¤Æ¤¤¤¿¤êÉÔŬÀڤʥ¿¥°¤ò»ØÄꤹ¤ë¤È¡¢ CVSup ¤Ï¥æ¡¼¥¶¤¬¾Ã¤· ¤¿¤¯¤Ê¤¤¥Õ¥¡¥¤¥ë¤Þ¤Çºï½ü¤·¤Æ¤·¤Þ¤¤¤Þ¤¹¡£ÆÃ¤Ë ports-* ¤Î¥³¥ì¥¯¥·¥ç¥ó ¤ËÂФ·¤Æ¤Ï tag=. ¤À¤± ¤ò»ØÄꤹ¤ë¤è¤¦¤Ë¤·¤Æ¤¯¤À¤µ¤¤¡£ tag= ¥Õ¥£¡¼¥ë¥É¤Ï¥ê¥Ý¥¸¥È¥êÃæ¤Î¥·¥ó¥Ü¥ê¥Ã¥¯¥¿¥°¤ò»ØÄꤷ¤Þ¤¹¡£ tag ¤Ë¤Ï revision tag ¤È branch tag ¤ÎÆó¼ïÎब¤¢¤ê¤Þ¤¹¡£ revision tag ¤ÏÆÃÄê¤Î¥ê¥Ó¥¸¥ç¥ó¤ò»Ø¤·¤Þ¤¹¡£¤³¤ì¤Ï¡¢ ËèÆüƱ¤¸¾õÂÖ¤ËÊݤĤ³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£°ìÊý branch tag ¤Ï¡¢ ¤¢¤ë»þÅÀ¤Ç¤Î³«È¯Ê¬Î®¤ÎºÇ¿·¤Î¥ê¥Ó¥¸¥ç¥ó¤ò»Ø¤·¤Þ¤¹¡£ branch tag ¤ÏÆÃÄê¤Î¥ê¥Ó¥¸¥ç¥ó¤ò»ØÄꤷ¤Æ¤¤¤ëÌõ¤Ç¤Ï¤Ê¤¤¤Î¤Ç¡¢ º£Æü¤ÈÌÀÆü¤Ç¤Ï °Û¤Ê¤ë¥ê¥Ó¥¸¥ç¥ó¤ò»²¾È¤¹¤ë¤³¤È¤Ë¤Ê¤ë¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¤Ë¤Ï¥æ¡¼¥¶¤¬¶½Ì£¤ò»ý¤Ä¤Ç¤¢¤í¤¦¥ê¥Ó¥¸¥ç¥ó¥¿¥°¤Î°ìÍ÷¤¬ºÜ¤»¤é¤ì¤Æ¤¤¤Þ¤¹¡£ CVSup ¤ÎÀßÄê¥Õ¥¡¥¤¥ëÃæ¤Ç¥¿¥°¤ò»ØÄꤹ¤ë»þ¤Ï¡¢ tag= ¤Ë³¤±¤Æ½ñ¤­¤Þ¤¹ (RELENG_8 ¤Ï tag=RELENG_8 ¤Ë¤Ê¤ê¤Þ¤¹)¡£ tag=. ¤À¤±¤¬ Ports Collection ¤Ë¤Ï ŬÀڤǤ¢¤ë¤³¤È¤ËÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£ tag ̾¤ò¼¨¤·¤¿Ä̤ê¤Ë¥¿¥¤¥×¤µ¤ì¤Æ¤¤¤ë¤«½½Ê¬Ãí°Õ¤·¤Æ¤¯ ¤À¤µ¤¤¡£CVSup ¤Ï tag ̾¤¬Àµ¤·¤¤¤«¤É¤¦¤«¤ò¸«Ê¬¤±¤ë¤³¤È¤Ï¤Ç¤­¤Þ¤»¤ó¡£tag ¤¬´Ö°ã¤Ã¤Æ¤¤¤¿¾ì¹ç¡¢ ¤¿¤Þ¤¿¤Þ¥Õ¥¡¥¤¥ë¤¬¤Þ¤Ã¤¿¤¯Â¸ºß¤·¤Ê¤¤Àµ¤·¤¤ tag ¤¬ »ØÄꤵ¤ì¤¿¤â¤Î¤È¤·¤ÆCVSup ¤Ïưºî¤·¤Þ¤¹¡£¤½¤Î¾ì¹ç¤Ï¡¢¸½ºß¤¢¤ë¥½¡¼¥¹¤¬ºï ½ü¤µ¤ì¤ë¤Ç¤·¤ç¤¦¡£ branch tag ¤ò»ØÄꤷ¤¿ºÝ¤Ë¤Ï¡¢ Ä̾ï¤Ï¤½¤Î³«È¯Ê¬Î®¤ÎºÇ¿·¥Ð¡¼¥¸¥ç¥ó¤Î ¥Õ¥¡¥¤¥ë¤ò¼õ¤±¼è¤ê¤Þ¤¹¡£ ¤¤¤¯¤é¤«Á°¤Î¥Ð¡¼¥¸¥ç¥ó¤ò¼õ¤±¼è¤ê¤¿¤¤¾ì¹ç¤Ï¡¢ ¤Î value ¥Õ¥£¡¼¥ë¥É¤ò»È¤Ã¤ÆÆüÉÕ¤ò»ØÄꤹ¤ë¤³¤È¤Ç¡¢ ¤³¤ì¤ò¼Â¸½¤¹¤ë¤³¤È¤¬ ¤Ç¤­¤Þ¤¹¡£&man.cvsup.1; ¤Î¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸¤Ç¡¢ ¤½¤ÎÊýË¡¤òÀâÌÀ¤·¤Æ¤¤¤Þ¤¹¡£ Îã¤È¤·¤Æ¡¢&os;-CURRENT ¤ò¼õ¤±¼è¤ê¤¿¤¤¤È¤·¤Þ¤¹¡£ ¼¡¤Î¹Ô¤ò supfile ¤Î»Ï¤á¤ËÄɲä·¤Þ¤¹: *default tag=. tag= ¥Õ¥£¡¼¥ë¥É¤â date= ¥Õ¥£¡¼¥ë¥É¤â»ØÄꤷ¤Ê¤«¤Ã¤¿¾ì¹ç¤Ë ư¤­½Ð¤¹½ÅÍ×¤ÊÆÃ¼ì¤Ê¥±¡¼¥¹¤¬¤¢¤ê¤Þ¤¹¡£¤½¤Î¥±¡¼¥¹¤Ç¤Ï¡¢ ÆÃÄê¤Î¥Ð¡¼¥¸¥ç¥ó¤Î ¥Õ¥¡¥¤¥ë¤ò¼õ¤±¼è¤ë¤Î¤Ç¤Ï¤Ê¤¯¡¢ ¥µ¡¼¥Ð¤Î CVS ¥ê¥Ý¥¸¥È¥ê¤«¤é¼ÂºÝ¤Î RCS ¥Õ¥¡¥¤¥ë¤òľÀܼõ¤±¼è¤ê¤Þ¤¹¡£ °ìÈÌŪ¤Ë³«È¯¼Ô¤Ï¤³¤Î½èÍý¤Î¥â¡¼¥É¤¬¹¥¤­¤Ê¤è¤¦¤Ç¤¹¡£ Èà¤é¤Î¥·¥¹¥Æ¥à¾å¤Ë¥ê¥Ý¥¸¥È¥ê¤½¤Î¤â¤Î¤Î ¥³¥Ô¡¼¤ò°Ý»ý¤¹¤ë¤³¤È¤Ç¡¢ ¥ê¥Ó¥¸¥ç¥óÍúÎò¤ò±ÜÍ÷¤·²áµî¤Î¥Ð¡¼¥¸¥ç¥ó¤Î ¥Õ¥¡¥¤¥ë¤ò¸¡ºº¤Ç¤­¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£¤·¤«¤·¡¢ ¤³¤ì¤Ë¤ÏÂ礭¤Ê¥Ç¥£¥¹¥¯¥¹¥Ú¡¼¥¹¤¬É¬Íפˤʤê¤Þ¤¹¡£ ¤É¤³¤«¤éÆþ¼ê¤·¤¿¤¤¤Î¤«? ¹¹¿·¾ðÊó¤ò¤É¤³¤«¤éÆþ¼ê¤¹¤ë¤«¤ò cvsup ¤ËÅÁ¤¨¤ë¤¿¤á¤Ë host= ¥Õ¥£¡¼¥ë¥É¤ò»ÈÍѤ·¤Þ¤¹¡£ CVSup ¥ß¥é¡¼¥µ¥¤¥È ¤Î¤É¤³¤«¤é¤Ç¤âÆþ¼ê¤Ç¤­¤Þ¤¹¤¬¡¢ ¥Í¥Ã¥È¾å¤Ç¤ÎºÇ´ó¤ê¤Î¥µ¥¤¥È¤òÁª¤Ö¤Ù¤­¤Ç¤·¤ç¤¦¡£ ¤³¤ÎÎã¤Ç¤Ï¡¢²¾ÁÛ¾å¤Î &os; ÇÛÉÛ¥µ¥¤¥È cvsup99.FreeBSD.org ¤ò»ÈÍѤ·¤Þ¤¹: *default host=cvsup99.FreeBSD.org CVSup ¤ò¼Â¹Ô¤¹¤ëÁ°¤Ë¥Û¥¹¥È̾¤ò ¼Âºß¤Î¤â¤Î¤ËÊѹ¹¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£¤É¤Î¤è¤¦¤Ë cvsup ¤ò¼Â¹Ô¤·¤Æ¤â¡¢¤³¤ÎÀßÄê¤Ï ¤ò »ÈÍѤ·¤Æ¥³¥Þ¥ó¥É¥é¥¤¥ó¤ÇÊѹ¹¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£ ¼«Ê¬¤Î¥Þ¥·¥ó¤Î¤É¤³¤ËÃÖ¤­¤¿¤¤¤Î¤«? prefix= ¥Õ¥£¡¼¥ë¥É¤Ï¡¢ cvsup ¤Ë¼õ¤±¼è¤Ã¤¿¥Õ¥¡¥¤¥ë¤ò¤É¤³¤ËÃÖ¤¯¤«¤òÅÁ¤¨¤Þ¤¹¡£ ¤³¤ÎÎã¤Ç¤Ï¡¢¥½¡¼¥¹¥Õ¥¡¥¤¥ë¤òľÀܥᥤ¥ó¤Î¥½¡¼¥¹¥Ä¥ê¡¼ /usr/src ¤ËÃÖ¤­¤Þ¤¹¡£ src ¥Ç¥£¥ì¥¯¥È¥ê¤Ï¤¹¤Ç¤Ë¥Õ¥¡¥¤¥ë¤ò¼õ¤±¼è¤ë¤¿¤á¤Ë ÁªÂò¤·¤¿¥³¥ì¥¯¥·¥ç¥ó¤Ç°ÅÌۤ˻ØÄꤷ¤Æ¤¤¤ë¤Î¤Ç¡¢ ¤³¤ì¤ÏÀµ¤·¤¤»ÅÍͤȤʤê¤Þ¤¹: *default prefix=/usr ¤É¤³¤Ë status ¥Õ¥¡¥¤¥ë¤òÃÖ¤­¤¿¤¤¤Î¤«? CVSup ¥¯¥é¥¤¥¢¥ó¥È¤Ï base ¥Ç¥£¥ì¥¯¥È¥ê¤È¸Æ¤Ð¤ì¤ë¾ì½ê¤Ë¡¢¤¢¤ë status ¥Õ¥¡¥¤¥ë¤ò°Ý»ý¤·¤Æ¤¤¤Þ¤¹¡£ ¤¹¤Ç¤Ë¼õ¤±¼è¤Ã¤¿¹¹¿·¾ðÊó¤òÄɽ¾¤·Â³¤±¤ë¤³¤È¤Ç¡¢ ¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤Ï CVSup ¤¬¤è¤ê¸ú²ÌŪ¤Ëưºî¤¹¤ë¤³¤È¤ò»Ù±ç¤·¤Þ¤¹¡£É¸½à¤Î base ¥Ç¥£¥ì¥¯¥È¥ê /var/db ¤ò»ÈÍѤ·¤Þ¤¹: *default base=/var/db base ¥Ç¥£¥ì¥¯¥È¥ê¤¬Â¸ºß¤·¤Ê¤¤¾ì¹ç¤ÏºîÀ®¤·¤Æ¤ª¤­¤Þ¤·¤ç¤¦¡£base ¥Ç¥£¥ì¥¯¥È¥ê¤¬Â¸ºß¤·¤Ê¤¤¾ì¹ç¡¢cvsup ¥¯¥é¥¤¥¢¥ó¥È¤Ï¼Â¹Ô¤òµñÈݤ·¤Þ¤¹¡£ ¤½¤Î¾¤â¤í¤â¤í¤Î supfile ¤ÎÀßÄê: Ä̾ï supfile ¤ËÆþ¤ì¤Æ¤ª¤¯¤Ù¤­¹Ô¤¬¤â¤¦°ì¤Ä¤¢¤ê¤Þ¤¹: *default release=cvs delete use-rel-suffix compress release=cvs ¤Ï¡¢¥µ¡¼¥Ð¤¬¥á¥¤¥ó¤Î &os; CVS ¥ê¥Ý¥¸¥È¥ê¤«¤é ¤½¤Î¾ðÊó¤ò¼èÆÀ¤¹¤ë¤è¤¦¤Ë»Ø¼¨¤·¤Þ¤¹¡£ ¤Û¤È¤ó¤É¤Î¾ì¹ç¤Ï¤³¤Î¤è¤¦¤Ë¤·¤Æ¤ª¤­¤Þ¤¹¤¬¡¢ ¤³¤³¤Ç¤ÎÀâÌÀ¤ÎÈÏáÆ¤ò¤³¤¨¤ë¤è¤¦¤Ê ¾õ¶·¤Ç¤Ï¾¤Î»ØÄê¤ò¤¹¤ë¤³¤È¤â²Äǽ¤Ç¤¹¡£ delete ¤Ï CVSup ¤Ë¥Õ¥¡¥¤¥ë¤òºï½ü¤¹¤ë¤³¤È¤òµö²Ä¤·¤Þ¤¹¡£ CVSup ¤¬ ¥½¡¼¥¹¥Ä¥ê¡¼¤ò´°Á´¤ËºÇ¿·¤Î¾õÂÖ¤Ë ÊݤƤë¤è¤¦¤Ë¤¹¤ë¤¿¤á¤Ë¤Ï¡¢¤³¤ì¤Ï¾ï¤Ë »ØÄꤷ¤Æ¤ª¤¯¤Ù¤­¤Ç¤·¤ç¤¦¡£ CVSup ¤Ï¡¢ ¤³¤ì¤é¤ÎÀÕǤÈϰϤΥե¡¥¤¥ë¤À¤±¤ò¿µ½Å¤Ëºï½ü¤·¤Þ¤¹¡£ ¤¿¤Þ¤¿¤Þ¸ºß¤¹¤ë¾¤Î;ʬ¤Ê¥Õ¥¡¥¤¥ë¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¤Þ¤Ã¤¿¤¯¼ê¤ò¤Ä¤±¤º¤Ë»Ä¤·¤Æ¤ª¤­¤Þ¤¹¡£ use-rel-suffix ¤Ï¡¢¡Ä¿ÀÈëŪ¤Ê¤â¤Î¤Ç¤¹¡£¤³¤ì¤Ë¤Ä¤¤¤ÆËÜÅö¤ËÃΤꤿ¤¤¿Í¤Ï¡¢ &man.cvsup.1; ¤Î¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ¤Ç¤Ê¤±¤ì¤Ð¡¢²¿¤â¹Í¤¨¤º¤Ë»ØÄꤷ¤Æ¤ß¤Æ¤¯¤À¤µ¤¤¡£ compress ¤ÏÄÌ¿®¥Á¥ã¥Í¥ë¤Ç gzip ·Á¼°¤Î°µ½Ì¤Î»ÈÍѤòÍ­¸ú¤Ë¤·¤Þ¤¹¡£ ¤´»ÈÍѤΥͥåȥ¥¯Àܳ¤¬ T1 speed °Ê¾å¤Ç¤¢¤ë¾ì¹ç¡¢ ¤³¤Î°µ½Ì¤ò»ÈÍѤ·¤Ê¤¤Êý¤¬¤è¤¤¤«¤â¤·¤ì¤Þ¤»¤ó¡£ ¤½¤¦¤Ç¤Ê¤¤¾ì¹ç¤Ï½½Ê¬¤ËÌò¤ËΩ¤Á¤Þ¤¹¡£ supfile ¤ÎÎã¤Î¤Þ¤È¤á: °Ê²¼¤Ï supfile ¤ÎÎã¤ÎÁ´ÂΤǤ¹: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all <filename>refuse</filename> ¥Õ¥¡¥¤¥ë ´û¤Ë½Ò¤Ù¤¿¤è¤¦¤Ë¡¢CVSup ¤Ï¼è¤ê´ó¤»Ë¡ (pull method)¤òÍѤ¤¤ë¤Î¤Ç¤¹¤¬¡¢ ¤³¤ì¤Ï´ðËÜŪ¤Ë¼¡¤Î¤è¤¦¤Ê¤³¤È¤ò°ÕÌ£¤·¤Þ¤¹¡£ ¤Þ¤º¤¢¤Ê¤¿¤¬ CVSup ¥µ¡¼¥Ð¤ËÀܳ¤·¤Þ¤¹¡£ ¤¹¤ë¤È¥µ¡¼¥Ð¤Ï ¤¢¤Ê¤¿¤¬¥À¥¦¥ó¥í¡¼¥É¤Ç¤­¤ë¤Î¤Ï¤³¤ì¤³¤ì¤Ç¤¹ ¤È¸À¤¤¤Þ¤¹¡£ ¤½¤ì¤ËÂФ·¡¢¤¢¤Ê¤¿¤¬»È¤Ã¤Æ¤¤¤ë¥¯¥é¥¤¥¢¥ó¥È¤Ï ¤ï¤«¤ê¤Þ¤·¤¿¡£ ¤Ç¤Ï¡¢¤³¤ì¤È¤³¤ì¤È¤³¤ì¤ò¤â¤é¤¤¤Þ¤¹ ¤ÈÅú¤¨¤Þ¤¹¡£ ¥Ç¥Õ¥©¥ë¥È¤ÎÀßÄê¤Î CVSup ¥¯¥é¥¤¥¢¥ó¥È¤Ï¡¢ ÀßÄê¥Õ¥¡¥¤¥ë¤ÇÁª¤ó¤À¥³¥ì¥¯¥·¥ç¥ó¤È¥¿¥°¤ËŬ¹ç¤¹¤ë¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤ò¼èÆÀ¤·¤Þ¤¹¡£ ¥Ä¥ê¡¼¤Î°ìÉô¤ò¥À¥¦¥ó¥í¡¼¥É¤¹¤ë¤Ë¤Ï¡¢ refuse ¥Õ¥¡¥¤¥ë¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ refuse ¥Õ¥¡¥¤¥ë¤Ï CVSup ¤ËÂФ·¡¢ ¥³¥ì¥¯¥·¥ç¥ó¤Ë´Þ¤Þ¤ì¤ë°ìÉô¤Î¥Õ¥¡¥¤¥ë¤ò¼èÆÀ¤¹¤ë¤³¤È¤òÅÁ¤¨¤Þ¤¹¡£ ¸À¤¤´¹¤¨¤ì¤Ð¡¢¤½¤ì¤Ï¥¯¥é¥¤¥¢¥ó¥È¤ËÂФ·¡¢ ¥µ¡¼¥Ð¤«¤éÍè¤ë°ìÉô¤Î¥Õ¥¡¥¤¥ë¤òµñÈݤ¹¤ë¤è¤¦»ØÄꤹ¤ë¤È¤¤¤¦¤³¤È¤Ç¤¹¡£ refuse ¥Õ¥¡¥¤¥ë¤Ï base/sup/ ¤Ë¤¢¤ê¤Þ¤¹ (¤â¤·¥Õ¥¡¥¤¥ë¤¬¤Ê¤¤¾ì¹ç¤Ë¤ÏºîÀ®¤·¤Æ¤¯¤À¤µ¤¤)¡£ base ¤Ï supfile Æâ¤ÇÄêµÁ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ »äã¤Ï base ¤Ë /var/db ¤òÄêµÁ¤·¤Æ¤¤¤Þ¤¹¡£¤Ä¤Þ¤ê¡¢ refuse ¥Õ¥¡¥¤¥ë¤Î¥Ç¥Õ¥©¥ë¥È¤Ï /var/db/sup/refuse ¤È¤¤¤¦¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£ refuse ¥Õ¥¡¥¤¥ë¤Î½ñ¼°¤Ï¡¢Ã±¤Ë¥À¥¦¥ó¥í¡¼¥É¤·¤¿¤¯¤Ê¤¤¥Õ¥¡¥¤¥ë¤ä ¥Ç¥£¥ì¥¯¥È¥ê¤Î̾Á°¤¬½ñ¤¤¤Æ¤¢¤ë¤À¤±¤ÎÈó¾ï¤Ë¥·¥ó¥×¥ë¤Ê¤â¤Î¤Ç¤¹¡£ ¤¿¤È¤¨¤Ð¡¢°Ê²¼¤Î¤è¤¦¤Ê refuse ¥Õ¥¡¥¤¥ë¤¬¹Í¤¨¤é¤ì¤Þ¤¹¡£ bin/ usr.bin/ ¤Þ¤Ã¤¿¤¯É¬ÍפȤ·¤Ê¤¤¥Õ¥¡¥¤¥ë¤ò¥À¥¦¥ó¥í¡¼¥É¤¹¤ëɬÍפ¬¤Ê¤¯¤Ê¤ê¡¢ ¥¤¥ó¥¿¡¼¥Í¥Ã¥ÈÀܳ¤Î²óÀþ¤¬ÃÙ¤«¤Ã¤¿¤ê½¾ÎÌÀ©¤Ç²Ý¶â¤µ¤ì¤Æ¤¤¤ë¿Í¤Ï»þ´Ö¤òÀáÌó¤Ç¤­¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£ refuse ¥Õ¥¡¥¤¥ë¤Î¾ÜºÙ¤ä CVSup ¤¬»ý¤Ä¤½¤Î¾¤ÎÊØÍø¤Êµ¡Ç½¤Ë´Ø¤·¤Æ¤Ï ¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£ <application>CVSup</application> ¤Î¼Â¹Ô ¤µ¤Æ¡¢¹¹¿·¤Î½àÈ÷¤¬¤Ç¤­¤Þ¤·¤¿¡£ ¤³¤ì¤ò¼Â¹Ô¤¹¤ë¥³¥Þ¥ó¥É¥é¥¤¥ó¤Ï¼Â¤Ë´Êñ¤Ç¤¹: &prompt.root; cvsup supfile ¤â¤Á¤í¤ó¡¢¤³¤³¤Ç¤Î supfile ¤ÏºîÀ®¤·¤¿¤Ð¤«¤ê¤Î supfile ¤Î¥Õ¥¡¥¤¥ë̾¤Ç¤¹¡£X11 ´Ä¶­¤Ç¼Â¹Ô¤¹¤ë¤â¤Î¤È²¾Äꤷ¤Æ¡¢cvsup ¤Ï Ä̾ï¤ÎÁàºî¤ËɬÍפʥܥ¿¥ó¤ò»ý¤Ä GUI ¥¦¥£¥ó¥É¥¦¤òɽ¼¨¤·¤Þ¤¹¡£ go ¥Ü¥¿¥ó¤ò²¡¤·¤Æ¡¢ ¼Â¹Ô¤ò´Æ»ë¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤³¤ÎÎã¤Ç¤Ï¼ÂºÝ¤Î /usr/src ¥Ä¥ê¡¼¤ò¹¹¿·¤·¤Æ¤¤¤ë¤Î¤Ç¡¢cvsup ¤Ë¥Õ¥¡¥¤¥ë¤ò¹¹¿·¤¹¤ë¤Î¤ËɬÍפʥѡ¼¥ß¥Ã¥·¥ç¥ó¤òÍ¿¤¨¤ë¤¿¤á¤Ë¡¢ ¥æ¡¼¥¶ root ¤Ç¼Â¹Ô¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ ¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤òºî¤Ã¤¿¤Ð¤«¤ê¤Ç¡¢ ¤·¤«¤â°ÊÁ°¤Ë¤³¤Î¥×¥í¥°¥é¥à¤ò¼Â¹Ô¤·¤¿¤³¤È¤¬¤Ê¤¤¤Î¤Ç¡¢ ¿À·Ð¼Á¤Ë¤Ê¤ë¤Î¤Ï̵Íý¤â¤Ê¤¤ÏäÀ¤È»×¤¤¤Þ¤¹¡£ ÂçÀڤʥե¡¥¤¥ë¤Ë¿¨¤é¤º¤Ë»î¤·¤Ë¼Â¹Ô¤¹¤ë´Êñ¤ÊÊýË¡¤¬¤¢¤ê¤Þ¤¹¡£ ¤É¤³¤«Å¬Åö¤Ê¾ì½ê¤Ë¶õ¤Î¥Ç¥£¥ì¥¯¥È¥ê¤òºîÀ®¤·¤Æ¡¢ ¥³¥Þ¥ó¥É¥é¥¤¥ó¤Î°ú¿ô¤Ç»ØÄꤹ¤ë¤À¤±¤Ç¤¹: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest »ØÄꤷ¤¿¥Ç¥£¥ì¥¯¥È¥ê¤Ï¡¢¤¹¤Ù¤Æ¤Î¹¹¿·¤µ¤ì¤ë¥Õ¥¡¥¤¥ë¤Î ¹¹¿·Àè¥Ç¥£¥ì¥¯¥È¥ê¤È¤·¤Æ»ÈÍѤ·¤Þ¤¹¡£ CVSup ¤Ï /usr/src ¤Î²¼¤Î¥Õ¥¡¥¤¥ë¤ò¸¡ºº¤·¤Þ¤¹¤¬¡¢ Êѹ¹¤äºï½ü¤Ï¤Þ¤Ã¤¿¤¯¤ª¤³¤Ê¤¤¤Þ¤»¤ó¡£¤«¤ï¤ê¤Ë /var/tmp/dest/usr/src ¤Ë¹¹¿·¤µ¤ì¤¿¤¹¤Ù¤Æ¤Î¥Õ¥¡¥¤¥ë¤¬ÃÖ¤«¤ì¤ë¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£ ¤³¤ÎÊýË¡¤Ç¼Â¹Ô¤·¤¿¾ì¹ç¤Ï¡¢CVSup ¤Ï base ¥Ç¥£¥ì¥¯¥È¥ê¤Î status ¥Õ¥¡¥¤¥ë¤ò¹¹¿·¤»¤º¤Ë¤½¤Î¤Þ¤Þ¤Ë¤·¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥Õ¥¡¥¤¥ë¤Î¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤Ï»ØÄꤵ¤ì¤¿¥Ç¥£¥ì¥¯¥È¥ê ¤Ë½ñ¤­¹þ¤Þ¤ì¤Þ¤¹¡£/usr/src ¤ÎÆÉ¤ß¼è¤êµö²Ä¤¬¤¢¤ë¸Â¤ê¡¢¤³¤Î¤è¤¦¤Ê»î¤·¼Â¹Ô¤Î¤¿¤á¤Ë¥æ¡¼¥¶ root ¤Ë¤Ê¤ëɬÍפϤ¢¤ê¤Þ¤»¤ó¡£ X11 ¤òÍøÍѤ·¤Æ¤¤¤Ê¤¤¤È¤«Ã±¤Ë GUI ¤¬µ¤¤ËÆþ¤é¤Ê¤¤¾ì¹ç¤Ï¡¢ cvsup µ¯Æ°»þ¤Ë¥³¥Þ¥ó¥É¥é¥¤¥ó¤Ë Æó¤Ä¤Û¤É¥ª¥×¥·¥ç¥ó¤òÄɲ乤ëɬÍפ¬¤¢¤ê¤Þ¤¹: &prompt.root; cvsup -g -L 2 supfile ¥ª¥×¥·¥ç¥ó¤Ï CVSup ¤Ë GUI ¤ò»ÈÍѤ·¤Ê¤¤¤è¤¦¤ËÅÁ¤¨¤Þ¤¹¡£X11 ¤òÍøÍѤ·¤Æ¤¤¤Ê¤¤¾ì¹ç¤Ë¤Ï¼«Æ°Åª¤Ë»ØÄꤵ¤ì¤Þ¤¹¤¬¡¢ ¤½¤¦¤Ç¤Ê¤¤¾ì¹ç¤ÏÌÀ¼¨Åª¤Ë»ØÄꤷ¤Þ¤¹¡£ ¥ª¥×¥·¥ç¥ó¤Ï cvsup ¤Ë¥Õ¥¡¥¤¥ë¹¹¿·Ãæ¤Î¾ÜºÙ¾ðÊó¤ò¥×¥ê¥ó¥È¥¢¥¦¥È ¤¹¤ë¤è¤¦¤ËÅÁ¤¨¤Þ¤¹¡£¾éĹÀ­¤Ë¤Ï ¤«¤é ¤Þ¤Ç¤Î»°¤Ä¤Î¥ì¥Ù¥ë¤¬¤¢¤ê¤Þ¤¹¡£ ¥Ç¥Õ¥©¥ë¥È¤Ï 0 ¤Ç¤¢¤ê¡¢¥¨¥é¡¼¥á¥Ã¥»¡¼¥¸°Ê³°¤Ï¤Þ¤Ã¤¿¤¯½ÐÎÏ ¤·¤Þ¤»¤ó¡£ ¤¿¤¯¤µ¤ó¤Î¾¤Î¥ª¥×¥·¥ç¥óÊÑ¿ô¤¬¤¢¤ê¤Þ¤¹¡£ ¤½¤ì¤é¤Î´Êñ¤Ê°ìÍ÷¤Ï cvsup -H ¤Çɽ¼¨¤µ¤ì¤Þ¤¹¡£ ¤è¤ê¾Ü¤·¤¤ÀâÌÀ¤Ï¥Þ¥Ë¥å¥¢¥ë¥Ú¡¼¥¸¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ưºî¤·¤Æ¤¤¤ë¹¹¿·¤ÎÊýË¡¤ËËþ­¤·¤¿¤é¡¢&man.cron.8; ¤ò»È¤Ã¤Æ CVSup ¤òÄê´üŪ¤Ë ¼Â¹Ô¤µ¤»¤ë½àÈ÷¤ò¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£cron ¤«¤éµ¯Æ°¤¹¤ëºÝ¤Ë¤Ï¡¢ ÌÀ¼¨Åª¤Ë CVSup ¤¬ GUI ¤ò»È¤ï¤Ê¤¤¤è¤¦¤Ë¤¹¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£ <application>CVSup</application> ¥Õ¥¡¥¤¥ë¥³¥ì¥¯¥·¥ç¥ó CVSup ·Ðͳ¤ÇÆþ¼ê¤Ç¤­¤ë¥Õ¥¡¥¤¥ë¥³¥ì¥¯¥·¥ç¥ó¤Ï ³¬ÁØÅª¤ËÁÈ¿¥²½¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤¤¤¯¤Ä¤«Â礭¤Ê¥³¥ì¥¯¥·¥ç¥ó¤¬¤¢¤ê¡¢ ¤½¤ì¤é¤Ï¾®¤µ¤Ê¥µ¥Ö¥³¥ì¥¯¥·¥ç¥ó¤Ë ʬ³ä¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ Â礭¤Ê¥³¥ì¥¯¥·¥ç¥ó¤Ï¡¢¤½¤Î¥µ¥Ö¥³¥ì¥¯¥·¥ç¥óËè¤Ë ¼õ¿®¤¹¤ë¤³¤È¤ÈƱ¤¸¤³¤È¤Ë¤Ê¤ê¤Þ¤¹¡£ ²¼¤Î°ìÍ÷¤Ç¤Ï¥³¥ì¥¯¥·¥ç¥ó´Ö¤Î³¬Áشط¸¤ò »ú²¼¤²¤·¤ÆÉ½¸½¤·¤Þ¤¹¡£ ºÇ¤â°ìÈÌŪ¤Ë»ÈÍѤ¹¤ë¥³¥ì¥¯¥·¥ç¥ó¤Ï src-all ¤Ç¤¹¡£ cvs-all release=cvs ¥á¥¤¥ó¤Î &os; CVS ¥ê¥Ý¥¸¥È¥ê¤Ç¤¢¤ê¡¢ °Å¹æ¤Î¥³¡¼¥É¤ò´Þ¤ó¤Ç¤¤¤Þ¤¹¡£ distrib release=cvs &os; ¤ÎÇÛÉۤȥߥ顼¤Ë´ØÏ¢¤¹¤ë¥Õ¥¡¥¤¥ë¤Ç¤¹¡£ projects-all release=cvs &os; ¥×¥í¥¸¥§¥¯¥È¤Î¥ê¥Ý¥¸¥È¥ê¤Î¥½¡¼¥¹¡£ src-all release=cvs ¥á¥¤¥ó¤Î &os; ¥½¡¼¥¹·²¤Ç¤¢¤ê¡¢ °Å¹æ¤Î¥³¡¼¥É¤ò´Þ¤ó¤Ç¤¤¤Þ¤¹¡£ src-base release=cvs /usr/src ¤Î¥È¥Ã¥×¤Ë¤¢¤ë¤½¤Î¾¤Î¥Õ¥¡¥¤¥ë¡£ src-bin release=cvs ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥É¤ÇɬÍ×¤Ê ¥æ¡¼¥¶¥æ¡¼¥Æ¥£¥ê¥Æ¥£ (/usr/src/bin)¡£ src-cddl release=cvs CDDL ¥é¥¤¥»¥ó¥¹¤Î¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤ª¤è¤Ó¥é¥¤¥Ö¥é¥ê (/usr/src/cddl)¡£ src-contrib release=cvs &os; ¥×¥í¥¸¥§¥¯¥È³°Éô¤«¤é¤Î ¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤ª¤è¤Ó¥é¥¤¥Ö¥é¥ê¡¢ Èæ³ÓŪ̵½¤Àµ (/usr/src/contrib)¡£ src-crypto release=cvs &os; ¥×¥í¥¸¥§¥¯¥È¤Î³°Éô¤Ç³«È¯¤µ¤ì¤¿°Å¹æ¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤È¥é¥¤¥Ö¥é¥ê¤Ç¡¢ ¤Û¤È¤ó¤É¤½¤Î¤Þ¤Þ¤Î·Á¤Ç»È¤ï¤ì¤Þ¤¹ (/usr/src/crypto)¡£ src-eBones release=cvs Kerberos ¤È DES (/usr/src/eBones) ¤Î¤³¤È¡£ ¸½ºß¤Î &os; ¥ê¥ê¡¼¥¹¤Ç¤Ï»È¤ï¤ì¤Æ¤¤¤Þ¤»¤ó¡£ src-etc release=cvs ¥·¥¹¥Æ¥à¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë (/usr/src/etc)¡£ src-games release=cvs ¥²¡¼¥à (/usr/src/games)¡£ src-gnu release=cvs GNU Public License ²¼¤Ë¤¢¤ë¥æ¡¼¥Æ¥£¥ê¥Æ¥£ (/usr/src/gnu)¡£ src-include release=cvs ¥Ø¥Ã¥À¥Õ¥¡¥¤¥ë (/usr/src/include)¡£ src-kerberos5 release=cvs Kerberos5 ¥»¥­¥å¥ê¥Æ¥£¥Ñ¥Ã¥±¡¼¥¸ (/usr/src/kerberos5)¡£ src-kerberosIV release=cvs KerberosIV ¥»¥­¥å¥ê¥Æ¥£¥Ñ¥Ã¥±¡¼¥¸ (/usr/src/kerberosIV)¡£ src-lib release=cvs ¥é¥¤¥Ö¥é¥ê (/usr/src/lib)¡£ src-libexec release=cvs ¥·¥¹¥Æ¥à¥×¥í¥°¥é¥à¤Ç¤¢¤ê¡¢ Ä̾ï¤Ï¾¤Î¥×¥í¥°¥é¥à¤«¤é¼Â¹Ô¤µ¤ì¤ë (/usr/src/libexec)¡£ src-release release=cvs &os; ¤Î release ¤ò¹½ÃÛ¤¹¤ë¤¿¤á¤ËɬÍפʥե¡¥¤¥ë (/usr/src/release)¡£ src-rescue release=cvs ¥·¥¹¥Æ¥àÉüµì¤Î¤¿¤á¤Î¥¹¥¿¥Æ¥£¥Ã¥¯¥ê¥ó¥¯¤µ¤ì¤Æ¤¤¤ë¶ÛµÞÍÑ¥×¥í¥°¥é¥à¡£ &man.rescue.8; ¤ò¤´Í÷¤¯¤À¤µ¤¤ (/usr/src/rescue)¡£ src-sbin release=cvs ¥·¥ó¥°¥ë¥æ¡¼¥¶¥â¡¼¥ÉÍѤΠ¥·¥¹¥Æ¥à¥æ¡¼¥Æ¥£¥ê¥Æ¥£ (/usr/src/sbin)¡£ src-secure release=cvs °Å¹æ²½¥é¥¤¥Ö¥é¥ê¤È¥³¥Þ¥ó¥É (/usr/src/secure)¡£ src-share release=cvs ¿Íͤʥ·¥¹¥Æ¥à´Ö¤Ç¶¦Í­²Äǽ¤Ê¥Õ¥¡¥¤¥ë (/usr/src/share)¡£ src-sys release=cvs ¥«¡¼¥Í¥ë (/usr/src/sys)¡£ src-sys-crypto release=cvs ¥«¡¼¥Í¥ëÍѤΰŹ楳¡¼¥É (/usr/src/sys/crypto)¡£ src-tools release=cvs &os; ¤ÎÊݼéÍѤο§¡¹¤Ê¥Ä¡¼¥ë (/usr/src/tools)¡£ src-usrbin release=cvs ¥æ¡¼¥¶¥æ¡¼¥Æ¥£¥ê¥Æ¥£ (/usr/src/usr.bin)¡£ src-usrsbin release=cvs ¥·¥¹¥Æ¥à¥æ¡¼¥Æ¥£¥ê¥Æ¥£ (/usr/src/usr.sbin)¡£ www release=cvs &os; WWW ¥µ¥¤¥È¤Î¥½¡¼¥¹¤Ç¤¹¡£ distrib release=self CVSup ¥µ¡¼¥Ð¼«¿È¤Î¥³¥ó¥Õ¥£¥°¥ì¡¼¥·¥ç¥ó¥Õ¥¡¥¤¥ë¤Ç¤¹¡£CVSup ¥ß¥é¡¼¥µ¥¤¥È¤¬»ÈÍѤ·¤Þ¤¹¡£ gnats release=current GNATS ¥Ð¥°¥È¥é¥Ã¥­¥ó¥°¥Ç¡¼¥¿¥Ù¡¼¥¹¤Ç¤¹¡£ mail-archive release=current &os; ´ØÏ¢¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î¥¢¡¼¥«¥¤¥Ö¡£ ¾ÜºÙ¤Ë¤Ä¤¤¤Æ CVSup ¤Î FAQ ¤ä CVSup ¤Ë´Ø¤¹¤ë¤½¤Î¾¤Î¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï The CVSup Home Page ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ CVSup ¤Î¤Û¤È¤ó¤É¤Î &os; ´ØÏ¢¤ÎµÄÏÀ¤Ï &a.hackers; ¤Ç¤ª¤³¤Ê¤ï¤ì¤Æ¤¤¤Þ¤¹¡£ ¥½¥Õ¥È¥¦¥§¥¢¤Î¿·¤·¤¤¥Ð¡¼¥¸¥ç¥ó¤Ï &a.announce; ¤Ç ¥¢¥Ê¥¦¥ó¥¹¤µ¤ì¤Þ¤¹¡£ CVSup ¤Ë´Ø¤¹¤ë¼ÁÌä¤ä¥Ð¥°Êó¹ð¤Ë¤Ä¤¤¤Æ¤Ï CVSup FAQ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ CVSup ¥µ¥¤¥È &os; ¤Î CVSup ¥µ¡¼¥Ð¤Ï°Ê²¼¤Î¥µ¥¤¥È¤Ç²ÔƯ¤·¤Æ¤¤¤Þ¤¹¡£ &chap.mirrors.cvsup.index.inc; &chap.mirrors.lastmod.inc; &chap.mirrors.cvsup.inc; CVS ¥¿¥° CVS ¤Ï¡¢¥×¥í¥¸¥§¥¯¥È¤Ë¤ª¤¤¤Æ»ÈÍѤµ¤ì¤Ê¤¯¤Ê¤Ã¤¿¤¿¤á¡¢ Èó¿ä¾©¤Ë¤Ê¤ê¤Þ¤·¤¿¡£ ¤«¤ï¤ê¤Ë Subversion ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ cvs ¤ä CVSup ¤ò»ÈÍѤ·¤Æ¥½¡¼¥¹¤òÆþ¼ê¤·¤¿¤êƱ´ü¤µ¤»¤¿¤ê¤¹¤ë¤È¤­¡¢ ¥ê¥Ó¥¸¥ç¥ó¥¿¥°¤ò»ØÄꤷ¤Ê¤±¤ì¤Ð¤Ê¤ê¤Þ¤»¤ó¡£ ¥ê¥Ó¥¸¥ç¥ó¥¿¥°¤Ï¡¢ÆÃÄê¤Î &os; ³«È¯¥Ö¥é¥ó¥Á¤«¡¢ ¤â¤·¤¯¤Ï¤¢¤ë»þ¹ï¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£Á°¼Ô¤ò ¥Ö¥é¥ó¥Á¥¿¥°¡¢ ¸å¼Ô¤ò ¥ê¥ê¡¼¥¹¥¿¥° ¤È¸Æ¤Ó¤Þ¤¹¡£ ¥Ö¥é¥ó¥Á¥¿¥° ¤³¤³¤Ë¤¢¤ë HEAD (¾ï¤ËÍ­¸ú¤Ê¥¿¥°) °Ê³°¤Î¤¹¤Ù¤Æ¤Î¥¿¥°¤Ï¡¢src/ ¤Î¤ß¤ËÍ­¸ú¤Ç¤¹¡£ ports/¡¢doc/¡¢ www/ ¥Ä¥ê¡¼¤Ï¡¢¥Ö¥é¥ó¥Á¤Ëʬ¤±¤é¤ì¤Æ¤¤¤Þ¤»¤ó¡£ HEAD ¼çÍ×Éô¤ò¤Ê¤¹Î®¤ì¡¢¤¹¤Ê¤ï¤Á &os;-CURRENT ¤Î¤¿¤á¤Î̾Á°¤Ç¤¹¡£¤Þ¤¿¡¢ ¤É¤Î¥ê¥Ó¥¸¥ç¥ó¤â»ØÄꤵ¤ì¤Ê¤«¤Ã¤¿¤È¤­¤Ë¤Ï¤³¤ì¤Ë¤Ê¤ê¤Þ¤¹¡£ CVSup ¤Ç¤Ï¡¢ ¤³¤Î¥¿¥°¤Ï . ¤Çɽ¤µ¤ì¤Þ¤¹ (¶çÆÉÅÀ¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£. ʸ»ú¤½¤Î¤â¤Î¤Ç¤¹)¡£ CVS ¤Ç¤Ï¤³¤ì¤¬¥ê¥Ó¥¸¥ç¥ó¥¿¥°¤¬»ØÄꤵ¤ì¤Ê¤«¤Ã¤¿»þ¤Î¥Ç¥Õ¥©¥ë¥È¤Ç¤¹¡£ STABLE ¤Ê·×»»µ¡¾å¤Ë CURRENT ¤Î¥½¡¼¥¹¤ò¥Á¥§¥¯¥¢¥¦¥È¤·¤¿¤ê¥¢¥Ã¥×¥Ç¡¼¥È¤¹¤ë¤Î¤Ï¡¢ »×¤¦¤È¤³¤í¤¬¤¢¤Ã¤Æ¤ä¤Ã¤Æ¤¤¤ë¤Î¤È¤¤¤¦¤Î¤Ç¤Ê¤±¤ì¤Ð¡¢ ¤è¤¤¹Í¤¨¤È¤Ï¤¤¤¨¤Þ¤»¤ó¡£ RELENG_9 &os;-9.X ¤Î³«È¯¤Î¤¿¤á¤Îή¤ì¤Ç¤¹¡£ &os; 9-STABLE ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤Þ¤¹¡£ RELENG_9_1 &os;-9.1 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä¡¢ ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_9_0 &os;-9.0 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_8 &os;-8.X ¤Î³«È¯¤Î¤¿¤á¤Îή¤ì¤Ç¤¹¡£ &os; 8-STABLE ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤Þ¤¹¡£ RELENG_8_3 &os;-8.3 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä¡¢ ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_8_2 &os;-8.2 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_8_1 &os;-8.1 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_8_0 &os;-8.0 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_7 &os;-7.X ¤Î³«È¯¤Î¤¿¤á¤Îή¤ì¤Ç¤¹¡£ &os; 7-STABLE ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤Þ¤¹¡£ RELENG_7_4 &os;-7.4 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_7_3 &os;-7.3 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_7_2 &os;-7.2 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_7_1 &os;-7.1 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_7_0 &os;-7.0 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_6 &os;-6.X ¤Î³«È¯¤Î¤¿¤á¤Îή¤ì¤Ç¤¹¡£ &os; 6-STABLE ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤Þ¤¹¡£ RELENG_6_4 &os;-6.4 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_6_3 &os;-6.3 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_6_2 &os;-6.2 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_6_1 &os;-6.1 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_6_0 &os;-6.0 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_5 &os;-5.X ¤Î³«È¯¤Î¤¿¤á¤Îή¤ì¤Ç¤¹¡£ &os; 5-STABLE ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤Þ¤¹¡£ RELENG_5_5 &os;-5.5 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_5_4 &os;-5.4 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_5_3 &os;-5.3 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_5_2 &os;-5.2 ¤ª¤è¤Ó &os;-5.2.1 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_5_1 &os;-5.1 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î¿¼¹ï¤Ê¥»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_5_0 &os;-5.0 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4 &os;-4.X ¤Î³«È¯¤Î¤¿¤á¤Îή¤ì¤Ç¤¹¡£ &os; 4-STABLE ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤Þ¤¹¡£ RELENG_4_11 &os;-4.11 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4_10 &os;-4.10 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4_9 &os;-4.9 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4_8 &os;-4.8 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4_7 &os;-4.7 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4_6 &os;-4.6 ¤ª¤è¤Ó &os;-4.6.2 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4_5 &os;-4.5 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4_4 &os;-4.4 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_4_3 &os;-4.3 ÍѤΥê¥ê¡¼¥¹¥Ö¥é¥ó¥Á¡£¥»¥­¥å¥ê¥Æ¥£´«¹ð¤ä ¤½¤Î¾¤Î½ÅÍפʥ»¥­¥å¥ê¥Æ¥£¾å¤Î½¤Àµ¤¬¤¢¤Ã¤¿¾ì¹ç¤Ë¤Î¤ß»È¤ï¤ì¤Þ¤¹¡£ RELENG_3 &os;-3.X ¤Î³«È¯¤Î¤¿¤á¤Îή¤ì¤Ç¤¹¡£ 3.X-STABLE ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤Þ¤¹¡£ RELENG_2_2 &os;-2.2.X ¤Î³«È¯¤Î¤¿¤á¤Îή¤ì¤Ç¤¹¡£2.2-STABLE ¤È¤·¤Æ¤âÃΤé¤ì¤Æ¤¤¤Þ¤¹¡£¤³¤Î¥Ö¥é¥ó¥Á¤ÏÂçÉôʬ¤¬ ¤¹¤¿¤ì¤Æ¤¤¤Þ¤¹¡£ ¥ê¥ê¡¼¥¹¥¿¥° ¤³¤ì¤é¤Î¥¿¥°¤Ï¡¢³Æ¥Ð¡¼¥¸¥ç¥ó¤Î &os; ¤¬¥ê¥ê¡¼¥¹¤µ¤ì¤¿»þÅÀ¤ËÂбþ¤·¤Æ¤¤¤Þ¤¹¡£ ¥ê¥ê¡¼¥¹¥¨¥ó¥¸¥Ë¥¢¥ê¥ó¥°¹©Äø¤Ï¡¢ Release Engineering Information ¤È Release Process ¤Ë¾ÜºÙ¤Ë¤Þ¤È¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£ src ¥Ä¥ê¡¼¤Ç¤Ï¡¢ RELENG_ ¤Ç»Ï¤Þ¤ë̾Á°¤Î¥¿¥°¤¬»È¤ï¤ì¤Æ¤¤¤Þ¤¹¡£ ports ¥Ä¥ê¡¼¤ª¤è¤Ó doc ¥Ä¥ê¡¼¤Ç¤Ï¡¢ RELEASE ¤Ç»Ï¤Þ¤ë̾Á°¤Î¥¿¥°¤¬»È¤ï¤ì¤Æ¤¤¤Þ¤¹¡£ ¤Ê¤ª¡¢www ¥Ä¥ê¡¼¤Ï¡¢ ¥ê¥ê¡¼¥¹¤ËºÝ¤·¤ÆÆÃÊ̤ʥ¿¥°¤¬ÉÕÍ¿¤µ¤ì¤ë¤³¤È¤Ï¤¢¤ê¤Þ¤»¤ó¡£ RELENG_9_1_0_RELEASE &os; 9.1 RELENG_9_0_0_RELEASE &os; 9.0 RELENG_8_3_0_RELEASE &os; 8.3 RELENG_8_2_0_RELEASE &os; 8.2 RELENG_8_1_0_RELEASE &os; 8.1 RELENG_8_0_0_RELEASE &os; 8.0 RELENG_7_4_0_RELEASE &os; 7.4 RELENG_7_3_0_RELEASE &os; 7.3 RELENG_7_2_0_RELEASE &os; 7.2 RELENG_7_1_0_RELEASE &os; 7.1 RELENG_7_0_0_RELEASE &os; 7.0 RELENG_6_4_0_RELEASE &os; 6.4 RELENG_6_3_0_RELEASE &os; 6.3 RELENG_6_2_0_RELEASE &os; 6.2 RELENG_6_1_0_RELEASE &os; 6.1 RELENG_6_0_0_RELEASE &os; 6.0 RELENG_5_5_0_RELEASE &os; 5.5 RELENG_5_4_0_RELEASE &os; 5.4 RELENG_4_11_0_RELEASE &os; 4.11 RELENG_5_3_0_RELEASE &os; 5.3 RELENG_4_10_0_RELEASE &os; 4.10 RELENG_5_2_1_RELEASE &os; 5.2.1 RELENG_5_2_0_RELEASE &os; 5.2 RELENG_4_9_0_RELEASE &os; 4.9 RELENG_5_1_0_RELEASE &os; 5.1 RELENG_4_8_0_RELEASE &os; 4.8 RELENG_5_0_0_RELEASE &os; 5.0 RELENG_4_7_0_RELEASE &os; 4.7 RELENG_4_6_2_RELEASE &os; 4.6.2 RELENG_4_6_1_RELEASE &os; 4.6.1 RELENG_4_6_0_RELEASE &os; 4.6 RELENG_4_5_0_RELEASE &os; 4.5 RELENG_4_4_0_RELEASE &os; 4.4 RELENG_4_3_0_RELEASE &os; 4.3 RELENG_4_2_0_RELEASE &os; 4.2 RELENG_4_1_1_RELEASE &os; 4.1.1 RELENG_4_1_0_RELEASE &os; 4.1 RELENG_4_0_0_RELEASE &os; 4.0 RELENG_3_5_0_RELEASE &os;-3.5 RELENG_3_4_0_RELEASE &os;-3.4 RELENG_3_3_0_RELEASE &os;-3.3 RELENG_3_2_0_RELEASE &os;-3.2 RELENG_3_1_0_RELEASE &os;-3.1 RELENG_3_0_0_RELEASE &os;-3.0 RELENG_2_2_8_RELEASE &os;-2.2.8 RELENG_2_2_7_RELEASE &os;-2.2.7 RELENG_2_2_6_RELEASE &os;-2.2.6 RELENG_2_2_5_RELEASE &os;-2.2.5 RELENG_2_2_2_RELEASE &os;-2.2.2 RELENG_2_2_1_RELEASE &os;-2.2.1 RELENG_2_2_0_RELEASE &os;-2.2.0 <application>rsync</application> ¥ß¥é¡¼¥µ¥¤¥È ¼¡¤Î¥µ¥¤¥È¤Ï¡¢&os; ¤ò rsync ¥×¥í¥È¥³¥ë¤ÇÄ󶡤·¤Æ¤¤¤Þ¤¹¡£ rsync ¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤Ï &man.rcp.1; ¥³¥Þ¥ó¥É¤È¤Û¤ÜƱ¤¸µ¡Ç½¤ò¼Â¸½¤¹¤ë¤â¤Î¤Ç¡¢ ¤³¤Á¤é¤ÎÊý¤¬Ë­É٤ʥª¥×¥·¥ç¥ó¤òÈ÷¤¨¡¢Á÷¤ê¦¤È¼õ¤±Â¦¤Îº¹Ê¬¤À¤±¤ò žÁ÷¤¹¤ë¤È¤¤¤¦ rsync ¥ê¥â¡¼¥È¹¹¿·¥×¥í¥È¥³¥ë¤ò»ÈÍѤ¹¤ë¤È¤¤¤¦ÅÀ¤¬°Û¤Ê¤ê¤Þ¤¹¡£ rsync ¤ò»È¤¦¤È¡¢¥Í¥Ã¥È¥ï¡¼¥¯·Ðͳ¤Ç¤ÎƱ´ü¤òÈó¾ï¤Ë¹â®¤Ë¹Ô¤Ê¤¦¤³¤È¤¬²Äǽ¤Ç¤¹¡£ ÆÃ¤Ë¡¢&os; FTP ¥µ¡¼¥Ð¤ä CVS ¥ê¥Ý¥¸¥È¥ê¤Î¥ß¥é¡¼¥µ¥¤¥È¤òºîÀ®¤¹¤ë»þ¤ËÊØÍø¤Ç¤·¤ç¤¦¡£ rsync ¤Ï¡¢Â¿¤¯¤Î¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Ç ÍøÍѤ¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£&os; ÈǤϡ¢ net/rsync ¤Î port ¤«¡¢package ¤ò»È¤Ã¤Æ¤¯¤À¤µ¤¤¡£ ¥Á¥§¥³¶¦Ï¹ñ rsync://ftp.cz.FreeBSD.org/ Ä󶡤·¤Æ¤¤¤ë¥³¥ì¥¯¥·¥ç¥ó: ftp: &os; FTP ¥µ¡¼¥Ð¤ÎÉôʬ¥ß¥é¡¼ &os;: &os; FTP ¥µ¡¼¥Ð¤ÎÁ´ÂΥߥ顼 ¥ª¥é¥ó¥À rsync://ftp.nl.FreeBSD.org/ Ä󶡤·¤Æ¤¤¤ë¥³¥ì¥¯¥·¥ç¥ó: &os;: &os; FTP ¥µ¡¼¥Ð¤ÎÁ´ÂΥߥ顼 ¥í¥·¥¢ rsync://ftp.mtu.ru/ Ä󶡤·¤Æ¤¤¤ë¥³¥ì¥¯¥·¥ç¥ó: &os;: &os; FTP ¥µ¡¼¥Ð¤ÎÁ´ÂΥߥ顼 &os;-gnats: GNATS ¥Ð¥°¥È¥é¥Ã¥­¥ó¥°¥Ç¡¼¥¿¥Ù¡¼¥¹ &os;-Archive: &os; ¥¢¡¼¥«¥¤¥Ö FTP ¥µ¡¼¥Ð¤Î¥ß¥é¡¼ ¥¹¥¦¥§¡¼¥Ç¥ó rsync://ftp4.se.freebsd.org/ Ä󶡤·¤Æ¤¤¤ë¥³¥ì¥¯¥·¥ç¥ó: &os;: &os; FTP ¥µ¡¼¥Ð¤ÎÁ´ÂΥߥ顼 ÂæÏÑ rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Ä󶡤·¤Æ¤¤¤ë¥³¥ì¥¯¥·¥ç¥ó: &os;: &os; FTP ¥µ¡¼¥Ð¤ÎÁ´ÂΥߥ顼 ¥¤¥®¥ê¥¹ rsync://rsync.mirrorservice.org/ Ä󶡤·¤Æ¤¤¤ë¥³¥ì¥¯¥·¥ç¥ó: ftp.freebsd.org: &os; FTP ¥µ¡¼¥Ð¤ÎÁ´ÂΥߥ顼 ¥¢¥á¥ê¥«¹ç½°¹ñ rsync://ftp-master.FreeBSD.org/ ¤³¤Î¥µ¡¼¥Ð¤Ï¡¢&os; ¤Î°ì¼¡¥ß¥é¡¼¥µ¥¤¥È¤È¤·¤Æ¤Î¤ß»È¤ï¤ì¤Æ¤¤¤Þ¤¹¡£ Ä󶡤·¤Æ¤¤¤ë¥³¥ì¥¯¥·¥ç¥ó: &os;: &os; FTP ¥µ¡¼¥Ð¤Î¥Þ¥¹¥¿¥¢¡¼¥«¥¤¥Ö acl: The &os; ¥Þ¥¹¥¿ ACL ¥ê¥¹¥È rsync://ftp13.FreeBSD.org/ Ä󶡤·¤Æ¤¤¤ë¥³¥ì¥¯¥·¥ç¥ó: &os;: &os; FTP ¥µ¡¼¥Ð¤ÎÁ´ÂΥߥ顼
diff --git a/ja_JP.eucJP/htdocs/community/mailinglists.xml b/ja_JP.eucJP/htdocs/community/mailinglists.xml index d17b2cf372..54c42d2acb 100644 --- a/ja_JP.eucJP/htdocs/community/mailinglists.xml +++ b/ja_JP.eucJP/htdocs/community/mailinglists.xml @@ -1,127 +1,127 @@ ]> - + &title; $FreeBSD$

¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ï¡¢FreeBSD ¥³¥ß¥å¥Ë¥Æ¥£¤Î¼çÍפʥ³¥ß¥å¥Ë¥±¡¼¥·¥ç¥ó¥Á¥ã¥ó¥Í¥ë¤Ç¡¢ Éý¹­¤¤ÏÃÂê¤ò¥«¥Ð¡¼¤·¤Æ¤¤¤Þ¤¹¡£

¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î¥¢¡¼¥«¥¤¥Ö

¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Î¥¢¡¼¥«¥¤¥Ö¤ò www.FreeBSD.org ¤Ë¤Æ ¸¡º÷¤·¤¿¤ê¡¢ ±ÜÍ÷¤Ç¤­¤Þ¤¹¡£ Mailman ¥¦¥§¥Ö¥¤¥ó¥¿¡¼¥Õ¥§¡¼¥¹¤«¤é ±ÜÍ÷¤¹¤ë¤³¤È¤â¤Ç¤­¤Þ¤¹¡£

±Ñ¸ì¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È

±Ñ¸ì¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤Ï¡¢ FreeBSD ¥Ï¥ó¥É¥Ö¥Ã¥¯¤Ë¤Þ¤È¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£

±Ñ¸ì°Ê³°¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È

¤¤¤¯¤Ä¤«¤Î±Ñ¸ì°Ê³°¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤â¤¢¤ê¤Þ¤¹¡£

¤³¤ì°Ê³°¤Ë FreeBSD ¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤òºî¤Ã¤¿»þ¤Ï¡¢ ²æ¡¹¤ËÃΤ餻¤Æ¤¯¤À¤µ¤¤¡£

diff --git a/ja_JP.eucJP/htdocs/internal/machines.xml b/ja_JP.eucJP/htdocs/internal/machines.xml index 78d1dfd2f5..360f75795a 100644 --- a/ja_JP.eucJP/htdocs/internal/machines.xml +++ b/ja_JP.eucJP/htdocs/internal/machines.xml @@ -1,425 +1,361 @@ ]> - + &title; $FreeBSD$

¤³¤Î¥Ú¡¼¥¸¤Ï¡¢FreeBSD.org ¥Í¥Ã¥È¥ï¡¼¥¯¾å¤Ë¥¢¥«¥¦¥ó¥È¤ò»ý¤Ã¤Æ¤¤¤ë¥æ¡¼¥¶¤Î¤¿¤á¤Ë¡¢ ¸½ºß¤É¤Î¤è¤¦¤Ê¥Þ¥·¥ó¥ê¥½¡¼¥¹¤¬ÍøÍѤǤ­¡¢ ¤Þ¤¿¤É¤Î¤è¤¦¤Ê¥µ¡¼¥Ó¥¹¤òÄ󶡤·¤Æ¤¤¤ë¤«¤Ë¤Ä¤¤¤Æ¤Þ¤È¤á¤Æ¤¤¤Þ¤¹¡£

¸ø³«¤µ¤ì¤Æ¤¤¤ë FreeBSD.org ¤Î¥Þ¥·¥ó¤Î SSH ¥Û¥¹¥È¸°¤È¤½¤Î»ØÌæ¤Î°ìÍ÷¤Ë¤Ä¤¤¤Æ¤Ï¡¢¤³¤Î¥Õ¥¡¥¤¥ë ¤ò»²¾È¤·¤Æ¤¯¤À¤µ¤¤¡£

³«È¯¼ÔÍѤΠFreeBSD.org ¥Û¥¹¥È

FreeBSD ³«È¯¼Ô/¥³¥ß¥Ã¥¿¡¼¤Ï¤³¤ì¤é¤Î¥·¥¹¥Æ¥à¤òÍøÍѤǤ­¤Þ¤¹¡£ ¥ê¥Õ¥¡¥ì¥ó¥¹¥·¥¹¥Æ¥à¤Ï¥Ó¥ë¥É¥Æ¥¹¥È¤Ê¤É¤ÎÌÜŪ¤ÇÍøÍѤǤ­¤Þ¤¹¡£

- - - - + + + + - + - - - - + + + + - - + + - - - - - - -
¥Û¥¹¥È OS ¥¿¥¤¥× ÌÜŪ
builder8-STABLEi386BSD/OS ¥½¡¼¥¹¥Û¥ë¥À
-FTP ¥µ¥¤¥ÈÍѤΠFreeBSD ¥É¥­¥å¥á¥ó¥Æ¡¼¥·¥ç¥ó¥Ó¥ë¥É¥Þ¥·¥ó
eris10-CURRENTia64¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó
flame 10-CURRENT sparc64 ¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó
freefall8-STABLE10-CURRENT i386 GNATS/shell ¥í¥°¥¤¥ó
pluto18-STABLEia64¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó; ia64 package ¥Ó¥ë¥Énova9-STABLEsparc64¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó
pluto29-CURRENTpluto9-STABLE ia64¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó; ia64 package ¥Ó¥ë¥É
ref7-amd647-STABLEamd64 ¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó
ref8-amd64 8-STABLE amd64 ¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó
ref9-amd64 9-STABLE amd64 ¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó
ref10-amd64 10-CURRENT amd64 ¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó
ref10-i386 10-CURRENT i386 ¥ê¥Õ¥¡¥ì¥ó¥¹¥Þ¥·¥ó

¥¢¥É¥ß¥Ë¥¹¥È¥ì¡¼¥·¥ç¥óÍѤΠFreeBSD.org ¥Û¥¹¥È

°Ê²¼¤Ï¡¢¤µ¤Þ¤¶¤Þ¤Ê¥¢¥É¥ß¥Ë¥¹¥È¥ì¡¼¥·¥ç¥ó¥µ¡¼¥Ó¥¹ÍѤΥ·¥¹¥Æ¥à¤Ç¤¹¡£ ¥·¥¹¥Æ¥à¤Î¤Û¤È¤ó¤É¤Ï¡¢¥¢¥¯¥»¥¹¤¬À©¸Â¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
¥Û¥¹¥ÈOS ÌÜŪ
ftp-master8-STABLE FTP ¥Þ¥¹¥¿ (¥¹¥Æ¡¼¥¸¥µ¡¼¥Ð)
hub7-STABLE ¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ª¤è¤Ó¥á¡¼¥ë¥µ¡¼¥Ó¥¹
ipv6gw8-STABLE IPv6 ¥È¥ó¥Í¥ë¥ë¡¼¥¿ (peer ¤Ï ISC)
mx17-STABLE ÅþÃå¥á¡¼¥ëÇÛÁ÷¥á¡¼¥ë¥µ¡¼¥Ð
mx27-STABLE ³°¸þ¤­¥á¡¼¥ëÇÛÁ÷¥á¡¼¥ë¥µ¡¼¥Ð
ns06-STABLE FreeBSD.org DNS ¥³¥ó¥Æ¥ó¥Ä¥µ¡¼¥Ð
ns1, ns28-STABLE FreeBSD.org DNS ¥­¥ã¥Ã¥·¥å¥µ¡¼¥Ð
repoman7-STABLECVS ¥Þ¥¹¥¿¥ê¥Ý¥¸¥È¥ê
skunkworks7-STABLE Perforce ¥µ¡¼¥Ð
sky8-STABLEwiki, HTTP ¥ê¥Ð¡¼¥¹¥×¥í¥­¥·¤Ê¤É¤Î¤µ¤Þ¤¶¤Þ¤Ê web ¥µ¡¼¥Ó¥¹
spit (cvsup-master)6-STABLECVSup ¥Þ¥¹¥¿¥ß¥é¡¼
svn7-STABLE Subversion ¥Þ¥¹¥¿¥ê¥Ý¥¸¥È¥ê
www7-STABLE www.FreeBSD.org ¥¦¥§¥Ö¥µ¡¼¥Ð

Ports ¥Ó¥ë¥É¥¯¥é¥¹¥¿

ports ¥Ó¥ë¥É¥¯¥é¥¹¥¿¤Ï¡¢¼ç¤Ë Ports Management team (portmgr) ¤¬´ÉÍý¤·¤Æ¤¤¤Þ¤¹¡£

¥Û¥¹¥È OS ÌÜŪ
pointyhat 9-CURRENT ¤¹¤Ù¤Æ¤Î¥¢¡¼¥­¥Æ¥¯¥Á¥ãÍѤΠpackage ¥Ó¥ë¥É¥Þ¥¹¥¿
gohan10-13 9-STABLE amd64 package ¥Ó¥ë¥É¥¯¥é¥¹¥¿
gohan18 8-STABLE portmgr Íѥƥ¹¥È¥Ù¥Ã¥É
gohan61-62 9-STABLE amd64 package ¥Ó¥ë¥É¥¯¥é¥¹¥¿

¥Ï¡¼¥É¥¦¥§¥¢¹½À®

- - - - - - - + - - - - - - - - - - - - - - - - - -
¥Û¥¹¥È ¥¿¥¤¥× ¥Ï¡¼¥É¥¦¥§¥¢
builder
flame Sun SPARC Sun Fire V120, UltraSparc-IIe 648MHz, 2GB Memory, sym SCSI controller, 2x 36G SCSI-3 disk, 2x Sun ERI 10/100 Ethernet.
freefall Intel x86 2x dual-core 2.80GHz Xeon (Pentium-IV family), 2GB Memory, Compaq Smart Array 5i SCSI RAID controller, 138 GB SCSI local storage, Broadcom-based Compaq NC7781 Gigabit Server Adapter NIC.
ftp-master Intel x86 2x dual-core 2.80GHz Xeon, 4GB Memory, LSI Logic PERC 4e/Di RAID adapter, 1.14T disk, 2x Intel PRO/1000 Ethernet NIC.
gohan10-13 Intel x86 2x1.8GHz quad-core Xeon L5320, 8GB Memory, Intel 63XXESB2 SATA300 controller, 1x160GB SAT300 drive, 2xIntel PRO/1000 NIC.
gohan18 Intel x86 2x1.8GHz quad-core Xeon L5320, 8GB Memory, LSILogic SAS/SATA controller, 1x160GB SAT300 drive, 2x Broadcom NetXtreme Gigabit Ethernet NIC.
gohan61-62 Intel x86 2x2.0GHz quad-core Intel Xeon L5335, 32GB Memory, Dell PERC 6 Megaraid SAS controller, 418GB local storage, 2x Broadcom NetXtreme II BCM5708 1000Base-T Ethernet NIC.
hub AMD64 MP 4x2.2GHz (dual CPU, dual core), 3GB Memory, Adaptec RAID Controller, 4x36GB U160 SCSI Disk, Broadcom Gigabit Ethernet.
mx1 Intel x86 MP 8x1.86GHz Xeon (dual CPU, quad core), 8GB Memory, Dell PERC 5/i RAID controller, 2x136GB SAS disks in RAID1, Broadcom NetXtreme Gigabit Ethernet adapter.
mx2 Intel x86 MP 2x2.8GHz Xeon, 1GB Memory, Compaq Smart Array 5i RAID controller, 2x34GB SCSI Disks in RAID1, Broadcom Gigabit Ethernet.
ns0, ns1, ns2 Intel x86 2.8GHz Xeon, 1GB Memory, Compaq Smart Array 5i RAID controller, 2x34GB SCSI Disks in RAID1, Broadcom Gigabit Ethernet.
pluto1, pluto2pluto IA-64 MP 2x900MHz Itanium2 (McKinley) - HP zx1 (pluto) chipset, 2GB Memory, LSILogic 1030 U320 SCSI controller (mpt), 1x36GB 10K RPM U160 SCSI drive, Broadcom BCM5701 Gigabit NIC.
pointyhat Intel EM64T MP 2x2.8GHz Intel Xeon (dualcore), 4GB Memory, Dell PERC 4 RAID controller, 1.1TB storage, Intel PRO/1000 Gigabitq NIC.
ref[7-10]-(amd64|i386) Intel EM64T MP Dell PowerEdge 2950, 2xIntel Xeon L5320 (8x1.86GHz), 8/16GB Memory, PERC 5/i RAID controller, 6x136GB SAS disks, Broadcom NetXtreme II BCM5708 NIC.
repomanAMD64 MP4x2.4GHz Opteron 280 (dual CPU, dual core), 8GB Memory, -HP Smart Array 6i RAID controller, -Broadcom BCM5704C Gigabit NIC.
skyIntel x86 MP2x2.4GHz Xeon, 2GB Memory, Compaq RAID 5, Broadcom Gigabit NIC.
spit  
www Intel x86 2x dual-core 2.80GHz Xeon, 1.5GB Memory, Compaq Smart Array 5i RAID controller, 2x34GB SCSI Disks in RAID1, 2x Broadcom Gigabit Ethernet NIC.

¤¹¤Ù¤Æ¤Î¥Þ¥·¥ó¤Ï¡¢¾éĹ¹½À®¤Î¥®¥¬¥Ó¥Ã¥È¥¢¥Ã¥×¥ê¥ó¥¯¤ò»ý¤ÄÀìÍѤΠCisco 2948G ¥¹¥¤¥Ã¥Á¤Ë 100Mbit/sec Á´Æó½Å¤ÇÀܳ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¥¤¥ó¥¿¡¼¥Í¥Ã¥È¤Ø¤ÎÀܳ¤È¥³¥í¥±¡¼¥·¥ç¥ó¤Ï Yahoo! ¤Ë¤è¤êÄ󶡤µ¤ì¤Æ¤¤¤Þ¤¹¡£ ¤¹¤Ù¤Æ¤Î¥·¥¹¥Æ¥à¤Ï¥·¥ê¥¢¥ë¥³¥ó¥½¡¼¥ë¤Ç·Ò¤¬¤Ã¤Æ¤¤¤Æ¡¢ ¥ê¥â¡¼¥È¤«¤éÅŸ»´ÉÍý¤ò¹Ô¤Ê¤¦¤³¤È¤¬¤Ç¤­¤Þ¤¹¡£

´ÉÍýÊý¿Ë

¤â¤·¤À¤ì¤«ÆÃÄê¤Î¤À¤ì¤«¤Ë¡È½ê°¡É¤·¤Æ¤¤¤ë¥Þ¥·¥ó¤Ë´Ø¤·¤Æ¼ÁÌ䤬¤¢¤ê¡¢ ¥æ¡¼¥¶¥¢¥«¥¦¥ó¥È¤ä¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¥ì¥¤¥¢¥¦¥È¤ÎÊѹ¹¤ò´Þ¤à´ÉÍý¾å¤ÎÌäÂê¤Ë¤Ä¤¤¤Æ¤Î¼ÁÌä¤Ç¤¢¤ì¤Ð¡¢ ¤Þ¤ºÈà¤é¤ËľÀÜÌä¹ç¤»¤Æ¤¯¤À¤µ¤¤¡£

¤¹¤Ù¤Æ¤Î¿·µ¬¥æ¡¼¥¶¥¢¥«¥¦¥ó¥È¤Ï´ÉÍý¥¹¥¿¥Ã¥Õ¤Ë¤è¤Ã¤Æ¾µÇ§¤µ¤ì¤Ê¤±¤ì¤Ð¤Ê¤é¤º¡¢ docs, ports, src ¥«¥Æ¥´¥ê¤Î¤¤¤º¤ì¤«¤Î FreeBSD ³«È¯¼Ô¤Ë¤Î¤ßÍ¿¤¨¤é¤ì¤Þ¤¹¡£ ¾åµ­¤Î³«È¯¼Ô°Ê³°¤Ç¤â¡¢ËÜÅö¤Ë¼Â¸³Åª¤Ê²¿¤é¤«¤Î¥Æ¥¹¥È¤¬É¬ÍפǤ¢¤ê¡¢ FreeBSD ¥Þ¥·¥ó¤Ë¥¢¥¯¥»¥¹¤¹¤ëɬÍפ¬¤¢¤ë¾ì¹ç¤Ë¤Ï¡¢¥¢¥«¥¦¥ó¥È¤¬Í¿¤¨¤é¤ì¤ë¤³¤È¤â¤¢¤ê¤Þ¤¹¡£ ¿·¤·¤¤¥¢¥«¥¦¥ó¥È¤Î¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï New Account Creation Procedure page ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£¥¢¥«¥¦¥ó¥È¤Ï¡¢"²Í¶õ¤Î¥É¥á¥¤¥ó" ¤È¤·¤Æ¤Î¥á¡¼¥ë¤ä¾¤Î»ÈÍѤʤɤΰìÈÌŪ¤ÊÌÜŪ¤Î¤¿¤á¤Ë¤ÏÍ¿¤¨¤é¤ì¤Þ¤»¤ó¤Î¤Ç¡¢ ¤³¤ì¤Ë´Ø¤·¤Æ¤ÏÌ䤤¹ç¤ï¤»¤·¤Ê¤¤¤Ç¤¯¤À¤µ¤¤¡£¤è¤í¤·¤¯¤ª´ê¤¤¤·¤Þ¤¹¡£

FreeBSD Internal ¥Û¡¼¥à diff --git a/ja_JP.eucJP/share/xml/news.xml b/ja_JP.eucJP/share/xml/news.xml index d23f99533b..da947d9fea 100644 --- a/ja_JP.eucJP/share/xml/news.xml +++ b/ja_JP.eucJP/share/xml/news.xml @@ -1,2658 +1,2694 @@ $FreeBSD$ 2013 + + 8 + + + 5 + + + &os; 9.2-RC1 ¸ø³« + +

&os;-9.2 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤«¤éºÇ½é¤Î¥ê¥ê¡¼¥¹¸õÊ䤬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ + amd64, i386, ia64, powerpc, powerpc64 ¤ª¤è¤Ó + sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; + ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« + ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

+
+
+
+ 7 + + 29 + + + &os; 9.2-BETA2 ¸ø³« + +

&os;-9.2 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤«¤é 2 ²óÌܤΠBETA ÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ + amd64, i386, powerpc64 ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î + ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; + ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« + ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

+
+
+ 22 &os; 9.2-BETA1 ¸ø³«

&os;-9.2 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ëºÇ½é¤Î BETA ÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386 ¤ª¤è¤Ó ia64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

16 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2013 ǯ 4 ·î - 6 ·î) ¸ø³«

2013 ǯ 4 ·î ¤«¤é 6 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (33 ¥¨¥ó¥È¥ê) ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£

4

¿·¥³¥ß¥Ã¥¿½¢Ç¤: John Marino (ports)

3

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Luiz Otavio O Souza (src)

2 BSDCan 2013 DevSummit ¥ê¥Ý¡¼¥È

BSDCan 2013 &os; ³«È¯¼Ô¥µ¥ß¥Ã¥È¤Î¥¹¥Ú¥·¥ã¥ë¥ì¥Ý¡¼¥È (6 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

6 25

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Mark Felder (ports)

19 ÃÂÀ¸Æü¤ª¤á¤Ç¤È¤¦ &os;!

ËÜÆü¡¢&os; ¤Ï 20 ºÐ ¤ò·Þ¤¨¤Þ¤·¤¿¡£ 1993 ǯ 6 ·î 19 Æü¡¢Jordan Hubbard, Rod Grimes ¤ª¤è¤Ó David Greenman ¤Ï¡¢BSD 4.3 ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤«¤é¿·¤·¤¤¥×¥í¥¸¥§¥¯¥È¤¬¥¹¥¿¡¼¥È¤·¤¿¤³¤È¤òÀ¤³¦¤Ë¥¢¥Ê¥¦¥ó¥¹¤·¤Þ¤·¤¿¡£

&os; ¤Ï¡¢Bill ¤È Lynne Jolitz ¤Î 386BSD 0.1 ¥ê¥ê¡¼¥¹¤«¤éÇÉÀ¸¤·¡¢1993 ǯ¤Î 11 ·î¤Ë 1.0 ¤¬¥ê¥ê¡¼¥¹¤µ¤ì¤Þ¤·¤¿¡£ ºÇ½é¤ÎÌÜɸ¤Ï¡¢¹â®¡¢°ÂÁ´¤Ç¤«¤Ä¿®ÍêÀ­¤Î¹â¤¤ i386 ¥·¥¹¥Æ¥à¤Î¥µ¡¼¥ÐÍÑ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤òºîÀ®¤¹¤ë¤³¤È¤Ç¤·¤¿¡£

¤½¤ì°Ê¹ß¡¢¿ô¤¨¤­¤ì¤Ê¤¤¤Û¤É¤Î¥×¥í¥À¥¯¥È¤Î¥Ð¥Ã¥¯¥Ü¡¼¥ó¤ËºÎÍѤµ¤ì¡¢ 64 ¥Ó¥Ã¥È¥·¥¹¥Æ¥à¡¢ÁȤ߹þ¤ß¥Ç¥Ð¥¤¥¹¤ª¤è¤Ó¥Ç¥¹¥¯¥È¥×¤ò¥µ¥Ý¡¼¥È¤¹¤ë¤Þ¤Ç¤ËÀ®Ä¹¤·¤Þ¤·¤¿¡£

11

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Veniamin Gvozdikov (ports)

7 &os; 8.4-RELEASE ¸ø³«

&os;  8.4-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë ¥ê¥ê¡¼¥¹¥Î¡¼¥È (¾ÜºÙÈÇ) ¤ª¤è¤Ó ¥ê¥ê¡¼¥¹ Errata ¤òÆÉ¤ß¡¢8.4 ¤Ë´Ø¤¹¤ëºÇ¿·¾ðÊó¤äÌäÂêÅÀ¤Ê¤É¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ &os; ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¥ê¥ê¡¼¥¹¾ðÊó ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

4

¥³¥ß¥Ã¥È¸¢¸Â¤Î³ÈÂç: Glen Barber (doc, ports, src)

5 27

¥³¥ß¥Ã¥È¸¢¸Â¤Î³ÈÂç: Chris Rees (doc, ports)

14 ¥Ð¥¤¥Ê¥ê packages ¤¬ºÆ¤ÓÍøÍѲÄǽ¤Ë

ºòǯ 11 ·î¤Ë¥»¥­¥å¥ê¥Æ¥£¥¤¥ó¥·¥Ç¥ó¥È¤¬È¯³Ð¤·¡¢ ¥×¥í¥¸¥§¥¯¥È¤Î¥Ð¥¤¥Ê¥ê package ¤¬ÍøÍѤǤ­¤Ê¤¯¤Ê¤Ã¤Æ¤«¤é 6 ¤«·î ¤¬²á¤®¤Æ¤·¤Þ¤¤¤Þ¤·¤¿¤¬¡¢ËÜÆü¡¢ ¤¹¤Ù¤Æ¤Î¥µ¡¼¥Ó¥¹¤¬Éü³è¤·¤¿¤³¤È¤ò¤´Êó¹ð¤·¤Þ¤¹¡£

¸ø¼°¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

12 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2013 ǯ 1 ·î - 3 ·î) ¸ø³«

2013 ǯ 1 ·î ¤«¤é 3 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (31 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

9 ¿· &os; Foundation ¥×¥í¥¸¥§¥¯¥È³«È¯¥Ç¥£¥ì¥¯¥¿½¢Ç¤: Ed Maste

The &os; Foundation ¤Ï¡¢Ed Maste ¤¬¿·¤·¤¯¥Ñ¡¼¥È¥¿¥¤¥à¤Î¥×¥í¥¸¥§¥¯¥È³«È¯¥Ç¥£¥ì¥¯¥¿¤Ë½¢Ç¤¤·¤¿¤³¤È¤ò¤ªÃΤ餻¤·¤Þ¤¹¡£ Ed ¤Ï 2 ǯ´Ö Foundation ¤Î¥Ü¡¼¥É¥á¥ó¥Ð¤Ç¤¢¤ê¤Þ¤·¤¿¤¬¡¢ ¤³¤Î¿·¤·¤¤¥Ý¥¸¥·¥ç¥ó¤Ø½¢Ç¤¤¹¤ë¤¿¤á¡¢¥Ü¡¼¥É¥á¥ó¥Ð¤òÂàǤ¤·¤Þ¤·¤¿¡£

³¤­¤òÆÉ¤à

8 &os; 8.4-RC3 ¸ø³«

&os;-8.4 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Î 3 ²óÌܤΥê¥ê¡¼¥¹¸õÊ䤬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386 ¤ª¤è¤Ó pc98 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

4 29 ¿· &os; Foundation ¥Æ¥¯¥Ë¥«¥ë¥¹¥¿¥Ã¥Õ: Edward Tomasz Napierała

The &os; Foundation ¤Ï¡¢ Edward Tomasz Napierała ¤¬Æó¿ÍÌܤΥƥ¯¥Ë¥«¥ë¥¹¥¿¥Ã¥Õ¤Ë²Ã¤ï¤Ã¤¿¤³¤È¤ò¤ªÃΤ餻¤·¤Þ¤¹¡£ ¤³¤ì¤Ï¡¢2013 ǯ¤Ë Foundation ¤¬·Ñ³¤·¤Æ¹Ô¤Ã¤Æ¤¤¤ë¥¹¥¿¥Ã¥Õ¤Ø¤ÎÅê»ñ¤Ë¤è¤ë¤â¤Î¤Ç¤¹¡£

³¤­¤òÆÉ¤à

24

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Alan Somers (src)

FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢Google Summer of Code 2013 ¤Ë»²²Ã¤·¤Þ¤¹

FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ï Google's 2013 Summer of Code ¥×¥í¥°¥é¥à¤Ë»²²Ã¤·¤Þ¤¹¡£ ¤³¤ì¤Ï²Æ¤Î´Ö¤Ë¾©³Ø¶â¤òÄ󶡤·¡¢ ¥ª¡¼¥×¥ó¥½¡¼¥¹¥×¥í¥¸¥§¥¯¥È¤Ë»²²Ã¤¹¤ë³ØÀ¸¤ò»Ù±ç¤¹¤ë¥×¥í¥°¥é¥à¤Ç¤¹¡£ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Î»²²Ã¤Ïº£Ç¯¤Ç 9 ǯÌܤȤʤê¤Þ¤¹¡£ 2005 ǯ¤«¤é 2012 ǯ¤Î´Ö¡¢ Ť¤²Æ¤Î´ü´Ö¤Î¥³¡¼¥Ç¥£¥ó¥°¥×¥í¥¸¥§¥¯¥È¤òÄ̤·¤Æ 150 ¿Í¤ò±Û¤¨¤ë³ØÀ¸¤ò»ØÆ³¤·¤Æ¤­¤Þ¤·¤¿¡£

¤³¤ì¤Þ¤Ç¤ËÀ®¸ù¤·¤¿¥×¥í¥¸¥§¥¯¥È¤Ë¤Ï¡¢ Linux ABI ¸ß´¹µ¡Ç½¤Î²þÁ±¡¢NFSv4 ACLs, TCP ¥ì¥°¥ì¥Ã¥·¥ç¥ó¥Æ¥¹¥È¡¢ FUSE ¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Î¥µ¥Ý¡¼¥È¤¬¤¢¤ê¡¢ ¤½¤Î¾¤Ë¤â¿ô¤¨ÀÚ¤ì¤Ê¤¤¥×¥í¥¸¥§¥¯¥È¤¬¤¢¤ê¤Þ¤¹¡£ ¿¤¯¤Î³ØÀ¸¤Ï FreeBSD ¤Î³«È¯¼Ô¤Ë¤Ê¤ê¡¢ FreeBSD Foundation ¤Î·Ñ³Ū¤Ê»Ù±ç¤òÄ̤¸¤Æ¡¢À¤³¦Ãæ¤Ç³«ºÅ¤µ¤ì¤Æ¤¤¤ë FreeBSD ¤Î³«È¯¼Ô¤Î¥¤¥Ù¥ó¥È¤Ë¤â»²²Ã¤·¤Æ¤¤¤Þ¤¹¡£

²æ¤³¤½¤Ï¡¢¤È»×¤¦Êý¤Ï¤¼¤Ò¤È¤â±þÊ礷¤Æ¤¯¤À¤µ¤¤! ¿½¤·¹þ¤ß¤äÄù¤áÀÚ¤ê¤Ê¤É¡¢¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï FreeBSD Summer Projects ¥Ú¡¼¥¸ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

22 &os; 8.4-RC2 ¸ø³«

&os;-8.4 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Î 2 ²óÌܤΥê¥ê¡¼¥¹¸õÊ䤬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386 ¤ª¤è¤Ó pc98 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

18

¥³¥ß¥Ã¥È¸¢¸Â¤Î³ÈÂç: Cy Schubert (src, ports)

12

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Hiren Panchasara (src)

10 &os; 8.4-RC1 ¸ø³«

&os;-8.4 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î¥ê¥ê¡¼¥¹¸õÊ䤬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386 ¤ª¤è¤Ó pc98 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

3

¥³¥ß¥Ã¥È¸¢¸Â¤Î³ÈÂç: Antoine Brodin (src, ports)

1

¿·¥³¥ß¥Ã¥¿½¢Ç¤: William Grzybowski (ports)

3 27

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: Tijl Coosemans (src, ports)

22 &os; 8.4-BETA1 ¸ø³«

&os;-8.4 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î¥Æ¥¹¥È¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386 ¤ª¤è¤Ó pc98 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

14 The &os; Foundation ¤Ë¿·¤·¤¯¥Æ¥¯¥Ë¥«¥ë¥¹¥¿¥Ã¥Õ¤¬²Ã¤ï¤ê¤Þ¤·¤¿ (Konstantin Belousov)

The &os; Foundation ¤Ï¡¢ Konstantin Belousov ¤ò½é¤á¤Æ¤Î¥Õ¥ë¥¿¥¤¥à¤Î¥Æ¥¯¥Ë¥«¥ë¥¹¥¿¥Ã¥Õ¤È¤·¤Æ¸ÛÍѤ·¤¿¤³¤È¤ò¤ªÃΤ餻¤·¤Þ¤¹¡£ ¤³¤ì¤Ï¡¢2013 ǯ¤Î¥¹¥¿¥Ã¥Õ¤ËÂФ¹¤ë Foundation ¤ÎÅê»ñ¤ÎÃæ¤Ç½ÅÂç¤Ê½ÐÍè»ö¤Ç¤¹¡£

³¤­¤òÆÉ¤à

12

Bryan Drewery ¤¬¡¢¿·¤·¤¯ Ports Management ¥Á¡¼¥à¤Î¥á¥ó¥Ð¡¼¤Ë²Ã¤ï¤ê¤Þ¤·¤¿¡£

3 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2012 ǯ 10 ·î - 12 ·î) ¸ø³«

2012 ǯ 10 ·î ¤«¤é 12 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (27 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2012 ǯ 7 ·î - 9 ·î) ¸ø³«

2012 ǯ 7 ·î ¤«¤é 9 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (12 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

2 10

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Po-Chien Lin (ports)

1

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Thomas-Martin Seck (ports)

1 23

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Achim Leubner (src)

22

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Dru Lavigne (doc)

16

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Carl Delsey (src)

15

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: René Ladan (ports, full doc/www)

14

¿·¥³¥ß¥Ã¥¿½¢Ç¤: David Naylor (ports)

13 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2012 ǯ 4 ·î - 6 ·î) ¸ø³«

2012 ǯ 4 ·î ¤«¤é 6 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (17 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

10 Ports CVS ¤Ï 2013 ǯ 2 ·î 28 Æü¤Ë¥µ¥Ý¡¼¥È½ªÎ»

¸½ºß¡¢&os; ports ¤Î³«È¯¤Ï Subversion ¤Ç¹Ô¤ï¤ì¤Æ¤¤¤Þ¤¹¡£ ports ¥Ä¥ê¡¼¤Î CVS ¤Ø¤Î¥¨¥¯¥¹¥Ý¡¼¥È¤Ï¡¢2013 ǯ 2 ·î 28 Æü¤ò¤â¤Ã¤ÆÄä»ß¤·¤Þ¤¹¡£ ¤½¤Î¤¿¤á¡¢¤³¤ÎÆü¤ò²á¤®¤ë¤È¡¢ CVS, CVSup ¤Þ¤¿¤Ï csup(1) ¤Ë¤è¤ë ports ¥Ä¥ê¡¼¤Î¥¢¥Ã¥×¥Ç¡¼¥È¤Ï¤Ç¤­¤Þ¤»¤ó¡£ CVS, CVSup ¤ª¤è¤Ó csup(1) ¤ò»È¤Ã¤Æ¤¤¤ë¤¹¤Ù¤Æ¤Î¥æ¡¼¥¶¤Ï portsnap(8) ¤Ø¤È°Ü¹Ô¤·¡¢ Ports Collection ¤ò¥Á¥§¥Ã¥¯¥¢¥¦¥È¤·¤Æ´ÉÍý¤¹¤ë¤³¤È¤¬É¬Íפʥ桼¥¶¤ÏľÀÜ Subversion ¤ò»È¤¦¤³¤È¤¬¿ä¾©¤µ¤ì¤Þ¤¹¡£ ¾ÜºÙ¤Ê¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢&os; ports ¥¢¥Ê¥¦¥ó¥¹¥á¡¼¥ê¥ó¥°¥ê¥¹¥È ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

CVSup ¤ä csup(1) ¤«¤é portsnap(8) ¤Ø¤Î°Ü¹Ô¤Ë´Ø¤¹¤ë¥¬¥¤¥É¤Ï¡¢&os; ¥Ï¥ó¥É¥Ö¥Ã¥¯ ¤Ë¤â¤¢¤ê¤Þ¤¹¡£

8 Faces of &os; ‐ Thomas Abthorpe

Faces of &os; ¥·¥ê¡¼¥º¤Î¼¡¤Î¥¹¥È¡¼¥ê¡¼¤ò¾Ò²ð¤·¤Þ¤¹¡£ ¤³¤Î¥·¥ê¡¼¥º¤Ç¤Ï¡¢&os; ¤Ë¹×¸¥¤·¡¢ ¥×¥í¥¸¥§¥¯¥È¤Î³«È¯¡¢¥«¥ó¥Õ¥¡¥ì¥ó¥¹¤Î±¿±Ä¤ä¥«¥ó¥Õ¥¡¥ì¥ó¥¹¤Ø¤ÎιÈñ¡¢¤½¤·¤Æ &os; ¤Î»Ù»ý¤ËÂФ·¤ÆÊä½õ¤ò¼õ¤±¤¿¡¢ ¤µ¤Þ¤¶¤Þ¤Ê¿Í¡¹¤Ë¥¹¥Ý¥Ã¥È¥é¥¤¥È¤òÅö¤Æ¤Æ¤¤¤Þ¤¹¡£

Thomas Abthorpe ¤ò¤´¾Ò²ð¤·¤Þ¤¹¡£ ¤ï¤ì¤ï¤ì¤Ï¡¢Èब BSDCan 2009, 2011 ¤ª¤è¤Ó 2012 ¤Ø»²²Ã¤¹¤ë¤¿¤á¤ÎιÈñ¤òÊä½õ¤·¤Þ¤·¤¿¡£ Èà¤Î¥¹¥È¡¼¥ê¡¼¤ò ¤³¤³ ¤Ç¤´Í÷¤¯¤À¤µ¤¤¡£

7

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ian Lepore (src)

2012 12 31 &os; 9.1-RELEASE ¸ø³«

FreeBSD 9.1-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë ¥ê¥ê¡¼¥¹¥Î¡¼¥È (¥ê¥ê¡¼¥¹¥Î¡¼¥È¤Î¾ÜºÙÈÇ) ¤ª¤è¤Ó Errata ¤òÆÉ¤ó¤Ç¡¢9.1 ¤Ë´Ø¤¹¤ëºÇ¿·¾ðÊó¤äÌäÂêÅÀ¤Ê¤É¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ FreeBSD ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¥ê¥ê¡¼¥¹¾ðÊó ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

24

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Kubilay Kocak (ports)

20 The &os; Foundation ¤«¤é End-of-Year ¥Ë¥å¡¼¥¹¥ì¥¿¡¼¤¬È¯¹Ô¤µ¤ì¤Þ¤·¤¿¡£

The &os; Foundation ¤Ï¡¢2012 ǯ¤Î End-of-Year ¥Ë¥å¡¼¥¹¥ì¥¿¡¼ ¤òȯ¹Ô¤·¤Þ¤·¤¿¡£

18

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Mark Johnston (src)

PC-BSD 9.1 ¤¬¥ê¥ê¡¼¥¹¤µ¤ì¤Þ¤·¤¿

PC-BSD ¥Á¡¼¥à¤«¤é PC-BSD 9.1 ¤¬¥ê¥ê¡¼¥¹¤µ¤ì¤Þ¤·¤¿ (¥¢¥Ê¥¦¥ó¥¹)¡£

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Steven Hartland (src)

17 Faces of &os; ‐ Dan Langille

Faces of &os; ¥·¥ê¡¼¥º¤Î¼¡¤Î¥¹¥È¡¼¥ê¡¼¤Ë¤Ä¤¤¤Æ¤´¾Ò²ð¤·¤Þ¤¹¡£ ¤³¤Î¥·¥ê¡¼¥º¤Ï¡¢ ¥×¥í¥¸¥§¥¯¥È¤Î³«È¯¡¢¥«¥ó¥Õ¥¡¥ì¥ó¥¹¤Î±¿±Ä¤ä¥«¥ó¥Õ¥¡¥ì¥ó¥¹¤Ø¤ÎιÈñ¡¢¤½¤·¤Æ &os; ¤Î»Ù»ý¤ËÂФ·¤ÆÊä½õ¤ò¼õ¤±¤¿¡¢ ¤µ¤Þ¤¶¤Þ¤Ê¿Í¡¹¤Ë¥¹¥Ý¥Ã¥È¥é¥¤¥È¤òÅö¤Æ¤ëÎɤ¤µ¡²ñ¤È¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£

Dan Langille ¤Î¥±¡¼¥¹¤Ë¤Ä¤¤¤Æ¤´¾Ò²ð¤·¤Þ¤¹¡£ ¤ï¤ì¤ï¤ì¤Ï¡¢2006 ǯ¤«¤éÈब BSDCan ¤Ë»²²Ã¤¹¤ë¤¿¤á¤Î¥¹¥Ý¥ó¥µ¡¼¤È¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£ Èà¤Î¥¹¥È¡¼¥ê¡¼¤Ï ¤³¤³ ¤Ç¤´Í÷¤¯¤À¤µ¤¤¡£

12 Stunning News Website Fundraising Contribution: 3 Æü´Ö¤Ç¿·¤¿¤Ë 650 ¤òͤ¨¤ëÊý¡¹¤Ë¤è¤Ã¤Æ $43,200 ±ß¤â¤Î´óÉí¤¬¹Ô¤ï¤ì¤Þ¤·¤¿!

¤ï¤ì¤ï¤ì¤Î¥Ö¥í¥°¤Î·üÌ¿¤Ê¤ëÆÉ¼Ô¤Ç¤¢¤ì¤Ð¡¢ Àè½µ¤«¤é &os; Foundation's annual year-end fundraising ¤¬³«»Ï¤µ¤ì¤¿¤³¤È¤ò¤´Â¸ÃΤǤ·¤ç¤¦¡£ Ëèǯ¤³¤Î¥­¥ã¥ó¥Ú¡¼¥óÃæ¤Ë¡¢50% ¤òͤ¨¤ë´óÉí¤¬¹Ô¤ï¤ì¤Þ¤¹¡£Â³¤­¤òÆÉ¤à

10 Faces of &os; ‐ Alberto Mijares

&os; ¥³¥ß¥å¥Ë¥Æ¥£¤Ø¤Î¥µ¥Ý¡¼¥È¤¬¡¢ ¶ñÂÎŪ¤Ë¤É¤Î¤è¤¦¤ËÌòΩ¤Ã¤Æ¤¤¤ë¤«¤´Â¸ÃΤǤ·¤ç¤¦¤«¡© year-end fundraising ¥­¥ã¥ó¥Ú¡¼¥ó¤È¤¢¤ï¤»¡¢ ¤ï¤ì¤ï¤ì¤Î¥¦¥§¥Ö¥µ¥¤¥È¤ä¥Ö¥í¥°¡¢Facebook ¥Ú¡¼¥¸¤Ë¤ª¤¤¤Æ¡¢¥×¥í¥¸¥§¥¯¥È¤Î³«È¯¡¢ ¥«¥ó¥Õ¥¡¥ì¥ó¥¹¤Î±¿±Ä¤ä¥«¥ó¥Õ¥¡¥ì¥ó¥¹¤Ø¤ÎιÈñ¡¢¤½¤·¤Æ &os; ¤Î»Ù»ý¤ËÂФ·¤ÆÊä½õ¤ò¼õ¤±¤¿¡¢ ¤µ¤Þ¤¶¤Þ¤Ê¿Í¡¹¤Ë¥¹¥Ý¥Ã¥È¥é¥¤¥È¤òÅö¤Æ¤Æ¤ß¤¿¤¤¤È»×¤¤¤Þ¤¹¡£Â³¤­¤òÆÉ¤à

5 &os; Year-End Fundraising Campaign

¤¢¤Ê¤¿¤«¤é¤Î´óÉդϡ¢&os; ¤¬ÍøÍѤǤ­¤ëºÇÎɤΠOS ¤È¤Ê¤ë½õ¤±¤È¤Ê¤ê¤Þ¤¹! The &os; Foundation ¤ËÅê»ñ¤¹¤ë¤³¤È¤Ç¡¢&os; ¤¬¹âÀ­Ç½¡¢°ÂÁ´¡¢ °ÂÄꤷ¤¿¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Ç¤¢¥ê³¤±¤ë¤¿¤á¤Î¼ê½õ¤±¤È¤Ê¤ê¤Þ¤¹¡£

The &os; Foundation ¤Ï¡¢¤¢¤Ê¤¿¤Î¤è¤¦¤Ê¿Í¡¹¤Î¤ª¤«¤²¤Ç¡¢ 12 ǯ¤Ë¤âÅϤê &os; ¥×¥í¥¸¥§¥¯¥È¤ò»Ù±ç¤Ç¤­¤ë¤³¤È¤ò¸Ø¤ê¤Ë»×¤¤¤Þ¤¹¡£Â³¤­¤òÆÉ¤à

5 &os; ¥×¥í¥¸¥§¥¯¥È¤Î¥¦¥§¥Ö¥µ¥¤¥È¤Ë¤ª¤¤¤Æ¡¢Google ¥¢¥Ê¥ê¥Æ¥£¥¯¥¹¤Î»ÈÍѤò³«»Ï¤·¤Þ¤·¤¿¡£

&os; ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢ ¥¦¥§¥Ö¥µ¥¤¥È¤ÎÍøÍѤ˴ؤ·¡¢Æ¿Ì¾²½¤µ¤ì¤¿Åý·×¾ðÊó¤Î¼ý½¸¤ò¡¢ Google ¥¢¥Ê¥ê¥Æ¥£¥¯¥¹¤òÍѤ¤¤Æ³«»Ï¤·¤Þ¤·¤¿¡£ ¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï¸ø¼° ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

11 26

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Takuya ASADA (src)

25

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Barbara Guida (ports)

17 FreeBSD ¤Î³«È¯¡¦ÇÛÉÛ¥Þ¥·¥ó·²¤Ø¤ÎÉÔÀµ¿¯ÆþȯÀ¸¤Ë¤Ä¤¤¤Æ

11 ·î 11Æü (Æü)¡¢FreeBSD.org ¥¯¥é¥¹¥¿¤Ë¤¢¤ë 2 Âæ¤Î¥Þ¥·¥ó¤Ë ¤ª¤¤¤ÆÉÔÀµ¿¯Æþ¤¬³Îǧ¤µ¤ì¤Þ¤·¤¿¡£FreeBSD ÍøÍѼԤ˱ƶÁ¤ò¤ª¤è¤Ü¤¹¤è¤¦¤ÊÊѹ¹¤¬²Ã¤¨¤é¤ì¤¿·ÁÀפϸ«¤Ä¤«¤Ã¤Æ¤¤¤Þ¤»¤ó¤¬¡¢ http://www.freebsd.org/ja/news/2012-compromise.html ¤Ë½ñ¤«¤ì¤Æ¤¤¤ëÊó¹ð¤ò°ìÆÉ¤¤¤¿¤À¤­¡¢ ɬÍפÊÂбþ¤ò¤È¤ë¤è¤¦¤Ë¤ª´ê¤¤¤¤¤¿¤·¤Þ¤¹¡£

5

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Bryan Venteicher (src)

4

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Grzegorz Blach (ports)

3 &os; 9.1-RC3 ¸ø³«

&os;-9.1 ¥ê¥ê¡¼¥¹¤Ë¸þ¤±¤Æ 3 ²óÌܤΥê¥ê¡¼¥¹¸õÊäÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ &os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ë¤ª¤¤¤Æ¡¢amd64, i386, sparc64 ¤ª¤è¤Ó powerpc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬ ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

10 24

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: Erwin Lansing (src, ports)

23

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Simon J. Gerraty (src)

20

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: Eitan Adler (src, ports, doc)

19

¿· Ports Managemet ¥Á¡¼¥à¥á¥ó¥Ð: Bernhard Fröhlich

10 &os; 9.1-RC2 ¸ø³«

&os;-9.1 ¥ê¥ê¡¼¥¹¤Ë¸þ¤±¤Æ 2 ²óÌܤΥê¥ê¡¼¥¹¸õÊäÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ &os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ë¤ª¤¤¤Æ¡¢amd64, i386, ia64, powerpc ¤ª¤è¤Ó powerpc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬ ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

9 15

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Peter Jeremy (src)

13

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Edson Brandi (doc/pt_BR, ww/pt_BR)

10

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Jason E. Hale (ports)

8 23 &os; 9.1-RC1 ¸ø³«

&os;-9.1 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î¥ê¥ê¡¼¥¹¸õÊäÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ &os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ë¤ª¤¤¤Æ¡¢amd64, i386 ¤ª¤è¤Ó powerpc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬ ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

21

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Andrey Zonov (src)

1

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Bryan Drewery (ports)

7 24 ¿·¥³¥¢¥Á¡¼¥à Secretary ½¢Ç¤: <a href="mailto:pgj@FreeBSD.org">Gábor Páli</a>

&os; ¥³¥¢¥Á¡¼¥à¤Ï¡¢Gábor Páli ¤¬ ¥³¥¢¥Á¡¼¥à Secretary ¤Ë½¢Ç¤¤·¤¿¤³¤È¤ò¤ªÃΤ餻¤·¤Þ¤¹¡£

16 &os; 9.1-BETA1 ¸ø³«

&os;-9.1 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î¥Æ¥¹¥È¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386, powerpc64 ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢ &os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

11 ¿·¤·¤¤ &os; ¥³¥¢¥Á¡¼¥à¤¬Áª½Ð¤µ¤ì¤Þ¤·¤¿

&os; ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢ 2012 ¥³¥¢¥Á¡¼¥àÁªµó¤Î½ªÎ»¤ò¤ªÃΤ餻¤·¤Þ¤¹¡£ &os; ¥³¥¢¥Á¡¼¥à¤Ï¡¢"¼èÄùÌò" ¤Ë¤¢¤¿¤ë¤â¤Î¤Ç¡¢ ¿·¤·¤¤ src ¥³¥ß¥Ã¥¿¤Î¾µÇ§¡¢³«È¯¼Ô´Ö¤ËÂÐΩ¤¬¤¢¤Ã¤¿¾ì¹ç¤ÎÄ´Ää¡¢ ÆÃÄê¤ÎÈϰϤΥµ¥Ö¥³¥ß¥Ã¥¿ (¥»¥­¥å¥ê¥Æ¥£¥ª¥Õ¥£¥µ¡¢¥ê¥ê¡¼¥¹¥¨¥ó¥¸¥Ë¥¢¡¢ port ¥Þ¥Í¡¼¥¸¥ã¡¢¥¦¥§¥Ö¥Þ¥¹¥¿¤Ê¤É) ¤ÎǤ̿¡¢ ¤Þ¤¿¡¢É¬Íפʺݤϡ¢´ÉÍý¤äÊý¿Ë¤Î·èÄê¤ò¹Ô¤¤¤Þ¤¹¡£ ¥³¥¢¥Á¡¼¥à¤Ï¡¢2000 ǯ¤«¤é 2 ǯ¤ª¤­¤Ë &os; ¤Î³«È¯¼Ô¤Ë¤è¤êÁª¤Ð¤ì¤Æ¤¤¤Þ¤¹¡£

Áªµó¤Î¾ÜºÙ (¤ª¤è¤Ó¿·¤·¤¤¥³¥¢¥Á¡¼¥à¤Î¥á¥ó¥Ð¤Î°ìÍ÷) ¤Ë¤Ä¤¤¤Æ¤Ï¡¢¸ø¼° ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

3

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Niclas Zeising (doc/www, ports)

6 19

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: Glen Barber (doc, ports)

4

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Mateusz Guzik (src)

5 30

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Jase Thew (ports)

29

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Olivier Duchateau (ports)

28

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Tom Judge (ports)

12 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2012 ǯ 1 ·î - 3 ·î) ¸ø³«

2012 ǯ 1 ·î ¤«¤é 3 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (27 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

4 26

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Isabell Long (doc/www)

22

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Jeremie Le Hen (src)

18 &os; 8.3-RELEASE ¸ø³«

FreeBSD 8.3-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë ¥ê¥ê¡¼¥¹¥Î¡¼¥È ¤ä Errata ¤òÆÉ¤ó¤Ç¡¢8.3 ¤Ë´Ø¤¹¤ëºÇ¿·¾ðÊó¤äÌäÂêÅÀ¤Ê¤É¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ FreeBSD ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¥ê¥ê¡¼¥¹¾ðÊó ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Devin Teske (src)

15

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Armin Pirkovitsch (ports)

13

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Monthadar Al Jaberi (src)

12

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Guido Falsi (ports)

2 &os; 8.3-RC2 ¸ø³«

&os;-8.3 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ë 2 ²óÌܤΥê¥ê¡¼¥¹¸õÊäÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386 ¤ª¤è¤Ó pc98 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬ &os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

3 23

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Cherry G. Mathew (src)

12

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Benjamin Kaduk (doc/www)

6 &os; 8.3-RC1 ¸ø³«

&os;-8.3 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ëºÇ½é¤Î¥ê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386 ¤ª¤è¤Ó pc98 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢ &os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

01

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Alex Kozlov (ports)

2 20 &os; 8.3-BETA1 ¸ø³«

&os;-8.3 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î¥Æ¥¹¥È¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386 ¤ª¤è¤Ó pc98 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢ &os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£

16

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Damjan Marion (src)

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ben Gray (src)

14

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: Sergey Kandaurov (src, doc)

7

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Matthew Seaman (ports)

1 27

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Davide Italiano (src)

³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2011 ǯ 10 ·î - 12 ·î) ¸ø³«

2011 ǯ 10 ·î ¤«¤é 12 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (32 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

12 &os; 9.0-RELEASE ¸ø³«

FreeBSD 9.0-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë ¥ê¥ê¡¼¥¹¥Î¡¼¥È ¤ä Errata ¤òÆÉ¤ó¤Ç¡¢9.0 ¤Ë´Ø¤¹¤ëºÇ¿·¾ðÊó¤äÌäÂêÅÀ¤Ê¤É¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ FreeBSD ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¥ê¥ê¡¼¥¹¾ðÊó ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

2011 12 16

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Jason Helfman (ports)

9 &os; 9.0-RC3 ¸ø³«

&os;-9.0 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Î 3 ²óÌÜ (¤½¤·¤Æ¡¢¤ª¤½¤é¤¯ºÇ¸å) ¤Î¥ê¥ê¡¼¥¹¸õÊäÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386, ia64, powerpc, powerpc64 ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; ¥ß¥é¡¼¥µ¥¤¥È ¤Ç ¸ø³« ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£ 9.0 ¤ÇÄɲ䵤ì¤ë¤¿¤¯¤µ¤ó¤Î¿·¤·¤¤µ¡Ç½¤ÎÃæ¤Ç¡¢ ¿·¤·¤¤¥¤¥ó¥¹¥È¡¼¥é¤Î»î¸³¤¬ÆÃ¤ËɬÍפǤ¹¡£ ¤¼¤Ò¡¢¥Æ¥¹¥È´Ä¶­¤Ç¿·¤·¤¤¥¤¥ó¥¹¥È¡¼¥é¤ò»î¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤¢¤ë¤¤¤Ï freebsd-update(8) ¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤òÍøÍѤ·¤Æ¡¢ ¸½ºß¤Î¥·¥¹¥Æ¥à¤ò¥¢¥Ã¥×¥°¥ì¡¼¥É¤·¤Æ¤¯¤À¤µ¤¤¡£

8

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Pedro Giffuni (src)

2

¿· Ports Manager ½¢Ç¤: Beat Gätzi

11 30

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Justin Hibbits (src)

17 &os; 9.0-RC2 ¸ø³«

&os;-9.0 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Î 2 ²óÌܤΥê¥ê¡¼¥¹¸õÊäÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386, ia64, powerpc, powerpc64 ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤¬¡¢&os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£ 9.0 ¤ÇÄɲ䵤ì¤ë¤¿¤¯¤µ¤ó¤Î¿·¤·¤¤µ¡Ç½¤Î¤Ò¤È¤Ä¤Ç¤¢¤ë¿·¥¤¥ó¥¹¥È¡¼¥é¤Î»î¸³¤¬É¬ÍפǤ¹¡£ ¤¼¤Ò¡¢¥Æ¥¹¥È´Ä¶­¤Ç¿·¤·¤¤¥¤¥ó¥¹¥È¡¼¥é¤ò»î¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤¢¤ë¤¤¤Ï freebsd-update(8) ¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤òÍøÍѤ·¤Æ¡¢ ¸½ºß¤Î¥·¥¹¥Æ¥à¤«¤é¥¢¥Ã¥×¥°¥ì¡¼¥É¤·¤Æ¤¯¤À¤µ¤¤¡£

12

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Michael Scheidell (ports)

11

¿·¥³¥ß¥Ã¥¿½¢Ç¤: David Chisnall (src)

9

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ruslan Makhmatkhanov (ports)

8 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2011 ǯ 7 ·î - 9 ·î) ¸ø³«

2011 ǯ 7 ·î ¤«¤é 9 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (28 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

10 23 &os; 9.0-RC1 ¸ø³«

&os;-9.0 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î¥ê¥ê¡¼¥¹¸õÊäÈǤ¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386, ia64, powerpc, powerpc64 ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£ 9.0 ¤ÇÄɲ䵤ì¤ë¤¿¤¯¤µ¤ó¤Î¿·¤·¤¤µ¡Ç½¤Î¤¦¤Á¡¢ ¿·¤·¤¯Æ³Æþ¤µ¤ì¤ë¥¤¥ó¥¹¥È¡¼¥é¤Î¥Æ¥¹¥È¤¬ÆÃ¤ËɬÍפǤ¹¡£ ¤¼¤Ò¡¢¥Æ¥¹¥È´Ä¶­¤Ç¿·¤·¤¤¥¤¥ó¥¹¥È¡¼¥é¤ò»î¤·¤Æ¤¯¤À¤µ¤¤¡£ ¤¢¤ë¤¤¤Ï freebsd-update(8) ¥æ¡¼¥Æ¥£¥ê¥Æ¥£¤òÍøÍѤ·¤Æ¡¢ ¸½ºß¤Î¥·¥¹¥Æ¥à¤«¤é¥¢¥Ã¥×¥°¥ì¡¼¥É¤·¤Æ¤¯¤À¤µ¤¤¡£

6

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Alexander V. Chernikov (src)

9 28 &os; 9.0-BETA3 ¸ø³«

&os;-9.0 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Î 3 ²óÌܤΥƥ¹¥È¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386, powerpc, powerpc64 ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤ò &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£ 9.0 ¤ÇÄɲ䵤ì¤ë¤¿¤¯¤µ¤ó¤Î¿·¤·¤¤µ¡Ç½¤Î¤¦¤Á¡¢ ¿·¤·¤¯Æ³Æþ¤µ¤ì¤ë¥¤¥ó¥¹¥È¡¼¥é¤Î¥Æ¥¹¥È¤¬ÆÃ¤ËɬÍפȹͤ¨¤Æ¤¤¤Þ¤¹¡£ ¤¼¤Ò¡¢¥Æ¥¹¥È´Ä¶­¤Ç¿·¤·¤¤¥¤¥ó¥¹¥È¡¼¥é¤ò»î¤·¤Æ¤¯¤À¤µ¤¤¡£

27

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Jakub Klama (src)

19

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Gleb Kurtsou (src)

18

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Robert Millan (src)

14

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Warren Block (doc/www)

³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2011 ǯ 4 ·î - 6 ·î) ¸ø³«

2011 ǯ 4 ·î ¤«¤é 6 ·î¤Î³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (36 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

13

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Carlo Strub (ports)

7 &os; 9.0-BETA2 ¸ø³«

&os;-9.0 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Î 2 ²óÌܤΥƥ¹¥È¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386, powerpc, powerpc64 ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤ò &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£ 9.0 ¤Ç¤Ï¤¿¤¯¤µ¤ó¤Î¿·¤·¤¤µ¡Ç½¤¬Äɲ䵤ì¤ëͽÄê¤Ç¤¹¤¬¡¢ ÆÃ¤Ë¿·¤·¤¯Æ³Æþ¤µ¤ì¤ë¥¤¥ó¥¹¥È¡¼¥é¤Î¥Æ¥¹¥È¤¬É¬Íפȹͤ¨¤Æ¤¤¤Þ¤¹¡£ ¥Æ¥¹¥È´Ä¶­¤Ë¤ª¤¤¤Æ¡¢¿·¤·¤¤¥¤¥ó¥¹¥È¡¼¥é¤ò¤ª»î¤·¤¯¤À¤µ¤¤¡£

8 22

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Raphael Kubo da Costa (ports)

17

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Eitan Adler (ports)

9 &os; Foundation ¥Ë¥å¡¼¥¹¥ì¥¿¡¼ (2011 ǯ 8 ·î) ȯ¹Ô

&os; Foundation ¤Ï¡¢º£Ç¯ºÇ½é¤Î 2011 Ç¯Ãæ´ü¥Ë¥å¡¼¥¹¥ì¥¿¡¼ ¤òȯ¹Ô¤·¤Þ¤·¤¿¡£ ¤³¤Î¥Ë¥å¡¼¥¹¥ì¥¿¡¼¤Ç¤Ï¡¢&os; ¥×¥í¥¸¥§¥¯¥È¤ËÂФ¹¤ë &os; Foundation ¤Î»Ù±ç¤¬¤Þ¤È¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£

1 &os; 9.0-BETA1 ¸ø³«

&os;-9.0 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î¥Æ¥¹¥È¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386, ia64, powerpc, powerpc64 ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤ò &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£ 9.0 ¤Ç¤Ï¿·¤·¤¤µ¡Ç½¤¬¤¿¤¯¤µ¤óÄɲ䵤ì¤Þ¤·¤¿¡£ ¤³¤ì¤é¤Î¿·¤·¤¤µ¡Ç½¤ÎÃæ¤Ç¡¢ ÆÃ¤Ë¥Æ¥¹¥È¤·¤ÆÄº¤­¤¿¤¤¤È¹Í¤¨¤Æ¤¤¤ë¤Î¤¬¿·¤·¤¤¥¤¥ó¥¹¥È¡¼¥é¤Ç¤¹¡£ ¤¼¤Ò¤È¤â¡¢¥Æ¥¹¥È´Ä¶­¤Ç 1 ¤«¤é¥¤¥ó¥¹¥È¡¼¥ë¤ò¹Ô¤¤¡¢ ¿·¤·¤¤¥¤¥ó¥¹¥È¡¼¥é¤ò»î¤·¤Æ¤¯¤À¤µ¤¤¡£

7 17

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: Gavin Atkinson (src, doc)

15

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ryan Steinmetz (ports)

6 14

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Grzegorz Bernacki (src)

13

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Stephen Montgomery-Smith (ports)

11

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Chris Rees (ports)

6 IPv6-only &os; ¥Æ¥¹¥È¥¤¥á¡¼¥¸

&os; Foundation ¤È iXsystems ¤Ï¡¢ FreeBSD ¤ª¤è¤Ó PC-BSD ¤Î IPv6-only ¥Æ¥¹¥È¥¤¥á¡¼¥¸¤ò ¥¢¥Ê¥¦¥ó¥¹ ¤·¤Þ¤·¤¿¡£

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Julien Laffaye (ports)

5 25

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Aleksandr Rybalko (src)

18

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ben Laurie (src)

12 ¿· Port Manager ½¢Ç¤

Baptiste Daroussin ¤¬¡¢¿·¤·¤¯ Ports Management ¥Á¡¼¥à¤Î¥á¥ó¥Ð¡¼¤Ë²Ã¤ï¤ê¤Þ¤·¤¿¡£

4 27 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2011 ǯ 1 ·î - 3 ·î) ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

2011 ǯ 1 ·î ¤«¤é 3 ·î¤Ë¤ª¤±¤ë³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (34 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

3 29

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Artem Belevich (src)

27 FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢Google Summer of Code 2011 ¤Ë»²²Ã¤·¤Þ¤¹

FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢Google's 2011 Summer of Code ¥×¥í¥°¥é¥à¤Ë»²²Ã¤·¤Þ¤¹¡£ ¤³¤Î¥×¥í¥°¥é¥à¤Ï²Æ¤Î´Ö¤Ë¾©³Ø¶â¤òÄ󶡤·¡¢ ¥ª¡¼¥×¥ó¥½¡¼¥¹¥×¥í¥¸¥§¥¯¥È¤Ë»²²Ã¤¹¤ë³ØÀ¸¤ò»Ù±ç¤·¤Þ¤¹¡£ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ë¤È¤Ã¤Æº£Ç¯¤¬ 7 ǯÌܤλ²²Ã¤È¤Ê¤ê¡¢ 2005 ǯ¤«¤é 2010 ǯ¤Î´Ö¡¢ ²Æ¤ÎŤ¤´ü´Ö¤Î¥³¡¼¥Ç¥£¥ó¥°¥×¥í¥¸¥§¥¯¥È¤òÄ̤·¤Æ 100 ¿Í¤ò±Û¤¨¤ë³ØÀ¸¤Î»ØÆ³¤ËÀ®¸ù¤·¤Æ¤¤¤Þ¤¹¡£

¤³¤ì¤Þ¤Ç¤ËÀ®¸ù¤·¤¿¥×¥í¥¸¥§¥¯¥È¤Ë¤Ï¡¢ Linux ABI ¸ß´¹µ¡Ç½¤Î²þÁ±¡¢NFSv4 ACLs, TCP ¥ì¥°¥ì¥Ã¥·¥ç¥ó¥Æ¥¹¥È¡¢ FUSE ¥Õ¥¡¥¤¥ë¥·¥¹¥Æ¥à¤Î¥µ¥Ý¡¼¥È¤¬¤¢¤ê¡¢ ¤½¤Î¾¤Ë¤â¿ô¤¨ÀÚ¤ì¤Ê¤¤¥×¥í¥¸¥§¥¯¥È¤¬¤¢¤ê¤Þ¤¹¡£ ¿¤¯¤Î³ØÀ¸¤Ï FreeBSD ¤Î³«È¯¼Ô¤Ë¤Ê¤ê¡¢ FreeBSD Foundation ¤Î·Ñ³Ū¤Ê»Ù±ç¤òÄ̤¸¤Æ¡¢À¤³¦Ãæ¤Ç³«ºÅ¤µ¤ì¤Æ¤¤¤ë FreeBSD ¤Î³«È¯¼Ô¤Î¥¤¥Ù¥ó¥È¤Ë¤â»²²Ã¤·¤Æ¤¤¤Þ¤¹¡£

²æ¤³¤½¤Ï¡¢¤È»×¤¦Êý¤Ï¤¼¤Ò¤È¤â±þÊ礷¤Æ¤¯¤À¤µ¤¤¡£ ¿½¤·¹þ¤ß¤äÄù¤áÀÚ¤ê¤Ê¤É¡¢¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï FreeBSD Summer Projects ¥Ú¡¼¥¸ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

18

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Sofian Brabez (ports)

13

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Pawel Pekala (ports)

10

FreeBSD Ports Management Team ¤Ï¡¢ Thomas Abthorpe ¤¬¤¹¤Ù¤Æ¤ÎÅêɼ¸¢¤ò¤â¤Ä¥á¥ó¥Ð¡¼¤Ë½¢Ç¤¤·¤¿¤³¤È¤ò¤ªÃΤ餻¤·¤Þ¤¹¡£

5

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Steven G. Kargl (src)

2 24 FreeBSD 8.2-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

FreeBSD 8.2-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë ¥ê¥ê¡¼¥¹¥Î¡¼¥È ¤ª¤è¤Ó Errata ¤òÆÉ¤ó¤Ç¡¢8.2 ¤Ë´Ø¤¹¤ëºÇ¿·¾ðÊó¤äÌäÂêÅÀ¤Ê¤É¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ FreeBSD ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¥ê¥ê¡¼¥¹¾ðÊó ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

FreeBSD 7.4-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

FreeBSD 7.4-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë ¥ê¥ê¡¼¥¹¥Î¡¼¥È ¤ª¤è¤Ó Errata ¤òÆÉ¤ó¤Ç¡¢7.4 ¤Ë´Ø¤¹¤ëºÇ¿·¾ðÊó¤äÌäÂêÅÀ¤Ê¤É¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ FreeBSD ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¥ê¥ê¡¼¥¹¾ðÊó ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

18

¥³¥ß¥Ã¥È¸¢¸Â¤Î³ÈÂç: Martin Wilke (src, ports, doc)

3 &os; 7.4/8.2-RC3 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-7.4/8.2 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ë 3 ²óÌܤΠ(¤ª¤½¤é¤¯ºÇ¸å¤Î) ¥ê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ 8.2-RC3 ¤Ï amd64, i386, ia64, pc98, powerpc ¤½¤·¤Æ sparc64 ¤Î¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤ÇÍøÍѤǤ­¤Þ¤¹¡£ 7.4-RC3 ¤Ï amd64, i386, pc98 ¤½¤·¤Æ sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤ÇÍøÍѤǤ­¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é¥À¥¦¥ó¥í¡¼¥É¤Ç¤­¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢¸ø¼°¤Î ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

1 25 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2010 ǯ 10 ·î - 12 ·î) ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

2010 ǯ 10 ·î ¤«¤é 12 ·î¤Ë¤ª¤±¤ë³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (37 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

23 &os; 7.4-RC2 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-7.4 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ë 2 ²óÌܤΥê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é¥À¥¦¥ó¥í¡¼¥É¤Ç¤­¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢¸ø¼°¤Î ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

16 &os; 8.2-RC2 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-8.2 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ë 2 ²óÌܤΥê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é¥À¥¦¥ó¥í¡¼¥É¤Ç¤­¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢¸ø¼°¤Î ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

2010 12 27 &os; 7.4/8.2-RC1 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-7.4/8.2 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ëºÇ½é¤Î¥ê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é¥À¥¦¥ó¥í¡¼¥É¤Ç¤­¤Þ¤¹¡£ ¤³¤ì¤é¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¸ø¼°¤Î ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

16 &os; Foundation ¥Ë¥å¡¼¥¹¥ì¥¿¡¼ (2010 ǯ 12 ·î) ¤¬È¯¹Ô¤µ¤ì¤Þ¤·¤¿

&os; Foundation ¤Ï End-of-Year ¥Ë¥å¡¼¥¹¥ì¥¿¡¼ ¤òȯ¹Ô¤·¤Þ¤·¤¿¡£ ¤³¤Î¥Ë¥å¡¼¥¹¥ì¥¿¡¼¤Ç¤Ï¡¢¥×¥í¥¸¥§¥¯¥È¤ª¤è¤Ó¥³¥ß¥å¥Ë¥Æ¥£¤ËÂФ¹¤ë 2010 ǯ¤Î»Ù±ç¤Ë¤Ä¤¤¤Æ¤Þ¤È¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£

11 &os; 7.4/8.2-BETA1 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-7.4/8.2 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î BETA ¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£

7

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Florian Smeets (ports)

11 15

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Eygene Ryabinkin (ports)

5

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Zack Kirsch (src)

10 27 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2010 ǯ 7 ·î - 9 ·î) ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

2010 ǯ 7 ·î ¤«¤é 9 ·î¤Ë¤ª¤±¤ë³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (55 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

16

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Frederic Culot (ports)

7

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Jonathan Anderson (src)

5

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Sergey Kandaurov (src)

9 25

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ganael Laplanche (ports)

21

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Po-Chuan Hsieh (ports)

5

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Andreas Tobler (src)

3

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Steve Wills (ports)

8 31

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Glen Barber (full doc/www)

30

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Dimitry Andric (src)

1

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Oliver Hauer (ports)

7 27 &os; Foundation ¥Ë¥å¡¼¥¹¥ì¥¿¡¼ (2010 ǯ 7 ·î) ¤¬È¯¹Ô¤µ¤ì¤Þ¤·¤¿

&os; Foundation ¤Ï 2010 Ç¯Ãæ´ü¥Ë¥å¡¼¥¹¥ì¥¿¡¼ ¤òȯ¹Ô¤·¤Þ¤·¤¿¡£ ¤³¤Î¥Ë¥å¡¼¥¹¥ì¥¿¡¼¤Ç¤Ï¡¢&os; Foundation ¤¬ &os; ¥×¥í¥¸¥§¥¯¥È¤ËÂФ·¤Æ¹Ô¤Ã¤Æ¤­¤¿»Ù±ç¤Ë¤Ä¤¤¤Æ¤Þ¤È¤á¤é¤ì¤Æ¤¤¤Þ¤¹¡£

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Baptiste Daroussin (ports)

23 FreeBSD 8.1-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

FreeBSD 8.1-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë ¥ê¥ê¡¼¥¹¥Î¡¼¥È ¤ª¤è¤Ó Errata ¤òÆÉ¤ó¤Ç¡¢8.1 ¤Ë¤Ä¤¤¤Æ¤ÎºÇ¿·¾ðÊó¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ FreeBSD ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¥ê¥ê¡¼¥¹¾ðÊó ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

22 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2010 ǯ 4 ·î - 6 ·î) ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

2010 ǯ 4 ·î ¤«¤é 6 ·î¤Ë¤ª¤±¤ë³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (47 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

21

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Andrew Turner (src)

20 PC-BSD 8.1 ¤¬¥ê¥ê¡¼¥¹¤µ¤ì¤Þ¤·¤¿

PC-BSD 8.1 ¤¬¥ê¥ê¡¼¥¹¤µ¤ì¤Þ¤·¤¿¡£ PC-BSD ¤Ï¡¢FreeBSD ¥Ù¡¼¥¹¤Î¥Ç¥¹¥¯¥È¥Ã¥×¥ª¥Ú¥ì¡¼¥·¥ç¥ó¥·¥¹¥Æ¥à¤Ç¡¢ ¥«¥¸¥å¥¢¥ë¤Ê¥³¥ó¥Ô¥å¡¼¥¿¥æ¡¼¥¶¤¬¥Ç¥¹¥¯¥È¥Ã¥×¥·¥¹¥Æ¥à¤ò´Êñ¤Ë»È¤¨¤ë¤³¤È¤òÌܻؤ·¤Æ¤¤¤Þ¤¹¡£ °ÊÁ°¤Î¥Ð¡¼¥¸¥ç¥ó¤«¤é¤Î¿·¤·¤¤µ¡Ç½¤ä¹¹¿·¤Î°ìÍ÷¤Ï ¤³¤³ ¤Ë¤¢¤ê¤Þ¤¹¡£

¿·¤·¤¤¥ê¥ê¡¼¥¹¤ò ¥À¥¦¥ó¥í¡¼¥É ¤·¤¿¤ê DVD ¤ò ¹ØÆþ ¤Ç¤­¤Þ¤¹¡£

17

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Tijl Coosemans (src)

15

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Joseph S. Atkinson (ports)

14 ¿·¤·¤¤ &os; ¥³¥¢¥Á¡¼¥à¤¬Áª½Ð¤µ¤ì¤Þ¤·¤¿

&os; ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢ 2010 ¥³¥¢¥Á¡¼¥àÁªµó¤Î½ªÎ»¤ò¤ªÃΤ餻¤·¤Þ¤¹¡£ &os; ¥³¥¢¥Á¡¼¥à¤Ï¡¢"¼èÄùÌò" ¤Ë¤¢¤¿¤ë¤â¤Î¤Ç¤¹¡£ ¿·¤·¤¤ src ¥³¥ß¥Ã¥¿¤Î¾µÇ§¡¢³«È¯¼Ô´Ö¤ÎÂÐΩ¤¬¤¢¤Ã¤¿¾ì¹ç¤ÎÄ´Ää¡¢ ÆÃÄê¤ÎÈϰϤΥµ¥Ö¥³¥ß¥Ã¥¿ (¥»¥­¥å¥ê¥Æ¥£¥ª¥Õ¥£¥µ¡¢¥ê¥ê¡¼¥¹¥¨¥ó¥¸¥Ë¥¢¥ê¥ó¥°¡¢ port ¥Þ¥Í¡¼¥¸¥ã¡¢¥¦¥§¥Ö¥Þ¥¹¥¿¤Ê¤É) ¤ÎǤ̿¡¢ ¤Þ¤¿¡¢É¬Íפʺݤϡ¢´ÉÍý¤ª¤è¤ÓÊý¿Ë¤Î·èÄê¤ò¹Ô¤¤¤Þ¤¹¡£ ¥³¥¢¥Á¡¼¥à¤Ï¡¢2000 ǯ¤«¤é 2 ǯ¤ª¤­¤Ë &os; ¤Î³«È¯¼Ô¤Ë¤è¤êÁª¤Ð¤ì¤Æ¤¤¤Þ¤¹¡£

Áªµó¤Î¾ÜºÙ (¤ª¤è¤Ó¿·¤·¤¤¥³¥¢¥Á¡¼¥à¤Î¥á¥ó¥Ð¤Î°ìÍ÷) ¤Ë¤Ä¤¤¤Æ¤Ï¡¢ ¸ø¼° ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

2 &os; 8.1-RC2 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-8.1 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ë 2 ²óÌܤΠ(¤½¤·¤Æ¤ª¤½¤é¤¯ºÇ¸å¤Î) ¥ê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ amd64, i386, ia64, powerpc ¤ª¤è¤Ó sparc64 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î CD ISO ¥¤¥á¡¼¥¸¤Ï¡¢¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é¥À¥¦¥ó¥í¡¼¥É¤Ç¤­¤Þ¤¹¡£ ËÜ¥ê¥ê¡¼¥¹¤Î¾ÜºÙ¤Ë¤Ä¤¤¤Æ¤Ï¡¢¸ø¼° ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

6 18 &os; 8.1-RC1 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-8.1 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ëºÇ½é¤Î¥ê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£

10

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ashish SHUKLA (ports)

9

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Brendan Fabeny (ports)

4

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Matthew Fleming (src)

3

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Andrey V. Elsukov (src)

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Taras Korenko (doc/ru, www/ru)

5 29 &os; 8.1-BETA1 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-8.1 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î BETA ¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£

24 Google Summer of Code ¥×¥í¥¸¥§¥¯¥È¤¬»Ï¤Þ¤ê¤Þ¤·¤¿

FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢º£Ç¯¤â Google's Summer of Code ¥×¥í¥°¥é¥à¤Ë»²²Ã¤¹¤ë³ØÀ¸¤¿¤Á¤«¤é¤Î¼Á¤Î¹â¤¤±þÊç¤ò¼õ¤±¤Þ¤·¤¿¡£ º£Ç¯¤Ï¡¢¤³¤Î¥×¥í¥°¥é¥à¤Î°ì´Ä¤È¤·¤Æ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤È°ì½ï¤Ë³«È¯¤ò¹Ô¤¦ 18 ¿Í¤Î³ØÀ¸¤ÎÄ󰯤¬ºÎÍѤµ¤ì¤Þ¤·¤¿¡£ º£Ç¯ºÎÍѤµ¤ì¤Ê¤«¤Ã¤¿¥×¥í¥¸¥§¥¯¥È¤ËÂФ·¤Æ¤â¡¢ FreeBSD ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢ ¤¤¤Ä¤Ç¤âÄ̾ï¤Î¥³¥ß¥å¥Ë¥Æ¥£¤Î¥á¡¼¥ê¥ó¥°¥ê¥¹¥È¤ä³«È¯¥Õ¥©¡¼¥é¥à¤òÄ̤·¤Æ¡¢ ³ØÀ¸¤¿¤Á¤¬¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Î³«È¯¤ò¤è¤ê¿¤¯³Ø¤Ù¤ë¤è¤¦¤Ë¼ê½õ¤±¤ò¤·¤¿¤¤¤È¹Í¤¨¤Æ¤¤¤Þ¤¹¡£

¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢¸ø¼° ¥¢¥Ê¥¦¥ó¥¹ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ Áª¤Ð¤ì¤¿³ØÀ¸¤Î¥×¥í¥¸¥§¥¯¥È°ìÍ÷¤Ï¡¢FreeBSD Summer of Code wiki ¤Ë¤¢¤ê¤Þ¤¹¡£ ¥³¡¼¥Ç¥£¥ó¥°¤Ï 5 ·î 24 Æü¤«¤é³«»Ï¤·¤Þ¤¹¡£ 18 ¿Í¤Î³ØÀ¸¤¿¤Á¤¬¿·¤·¤¯²æ¡¹¤Î¥³¥ß¥å¥Ë¥Æ¥£¤Ø»²²Ã¤¹¤ë¤³¤È¤ò°ì½ï¤Ë´¿·Þ¤·¤Æ¤¯¤À¤µ¤¤¡£

19

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Jayachandran C. (src)

4 29

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: Martin Matuška (src, ports)

22 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2010 ǯ 1 ·î - 3 ·î)

2010 ǯ 1 ·î ¤«¤é 3 ·î¤Ë¤ª¤±¤ë³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (46 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

20

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Randi Harper (src)

19

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ryan Stone (src)

14

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ana Kukec (src)

11

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: René Ladan (doc-nl, ports)

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Sahil Tandon (ports)

5

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Giuseppe Pilichi (ports)

4 &os; ¥×¥í¥¸¥§¥¯¥È¤Ï Google Summer of Code 2010 ¤Ë»²²Ã¤·¤Þ¤¹

&os; ¥×¥í¥¸¥§¥¯¥È¤Ï¡¢6 ǯϢ³¤Ç Google Summer of Code ¥×¥í¥°¥é¥à¤Ë»²²Ã¤·¤Þ¤¹¡£ Âç³ØÀ¸¤äÂç³Ø±¡À¸¤Î¤ß¤Ê¤µ¤ó¤Ï¤³¤Î¾©³Ø¶â¤Ë±þÊ礷¤Æ¡¢ ¤³¤Î²Æ¤Ï &os; ¥ª¥Ú¥ì¡¼¥Æ¥£¥ó¥°¥·¥¹¥Æ¥à¤Î²þÎɤËÌÀ¤±Êë¤ì¤Æ¤¯¤À¤µ¤¤! ¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï¡¢ &os; Summer of code ¥Ú¡¼¥¸ ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£ ¤³¤Î¥Ú¡¼¥¸¤Ë¤Ï¥Ý¥¹¥¿¡¼¤â¤¢¤ë¤Î¤Ç¡¢¶á¤¯¤ÎÂç³Ø¤ËÄ¥¤Ã¤Æ¤¯¤À¤µ¤¤¤Í!

3 31

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Bernhard Fröhlich (ports)

23 FreeBSD 7.3-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

FreeBSD 7.3-RELEASE ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ ¥¤¥ó¥¹¥È¡¼¥ëÁ°¤Ë ¥ê¥ê¡¼¥¹¥Î¡¼¥È ¤ª¤è¤Ó Errata ¤òÆÉ¤ó¤Ç¡¢7.3 ¤Ë¤Ä¤¤¤Æ¤ÎºÇ¿·¾ðÊó¤ò³Îǧ¤·¤Æ¤¯¤À¤µ¤¤¡£ FreeBSD ¤Î¥ê¥ê¡¼¥¹¤Ë´Ø¤¹¤ë¤è¤ê¾Ü¤·¤¤¾ðÊó¤Ë¤Ä¤¤¤Æ¤Ï ¥ê¥ê¡¼¥¹¾ðÊó ¤ò¤´Í÷¤¯¤À¤µ¤¤¡£

18 ¿· Ports Management Team Secretary ½¢Ç¤: <a href="mailto:tabthorpe@FreeBSD.org">Thomas Abthorpe</a>

&os; Ports Management Team ¤Ï¡¢Thomas Abthorpe ¤Î Ports Management Team Secretary ½¢Ç¤¤ò¤ªÃΤ餻¤·¤Þ¤¹¡£

7

¥³¥ß¥Ã¥¿Éüµ¢: Niels Heinen (ports)

4 &os; 7.3-RC2 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-7.3 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ë 2 ²óÌܤΠ¥ê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£

3

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Neel Natu (src)

2 22 PC-BSD 8.0 ¤¬¥ê¥ê¡¼¥¹¤µ¤ì¤Þ¤·¤¿

PC-BSD 8.0 ¤¬¥ê¥ê¡¼¥¹¤µ¤ì¤Þ¤·¤¿¡£ PC-BSD ¤Ï¡¢FreeBSD ¥Ù¡¼¥¹¤Î¥Ç¥¹¥¯¥È¥Ã¥×¥ª¥Ú¥ì¡¼¥·¥ç¥ó¥·¥¹¥Æ¥à¤Ç¡¢ ¥«¥¸¥å¥¢¥ë¤Ê¥³¥ó¥Ô¥å¡¼¥¿¥æ¡¼¥¶¤¬¥Ç¥¹¥¯¥È¥Ã¥×¥·¥¹¥Æ¥à¤ò´Êñ¤Ë»È¤¨¤ë¤³¤È¤òÌܻؤ·¤Æ¤¤¤Þ¤¹¡£ °ÊÁ°¤Î¥Ð¡¼¥¸¥ç¥ó¤«¤é¤Î¿·¤·¤¤µ¡Ç½¤ä¹¹¿·¤Î°ìÍ÷¤Ï ¤³¤³ ¤Ë¤¢¤ê¤Þ¤¹¡£

¿·¤·¤¤¥ê¥ê¡¼¥¹¤ò ¥À¥¦¥ó¥í¡¼¥É ¤·¤¿¤ê DVD ¤ò ¹ØÆþ ¤Ç¤­¤Þ¤¹¡£

15 &os; 7.3-RC1 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-7.3 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤Ë¤ª¤±¤ëºÇ½é¤Î¥ê¥ê¡¼¥¹¸õÊäÈǤΥӥë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£

12

¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: Benedict Reuschling (full doc/www)

6

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Bernhard Schmidt (src)

2 ¥³¥ß¥Ã¥È¸¢¤ÎÈϰϤγÈÂç: <a href="mailto:gabor@FreeBSD.org">Gábor Kövesdán</a> (src, ports, doc)

Gábor Kövesdán ¤Ï¡¢2008/2009 ǯ¤Î Google Summer of Code ¤Ë»²²Ã¤·¡¢¤³¤Î³èư¤Ë¤è¤ê¡¢¥½¡¼¥¹¥³¡¼¥É¤ËÂФ¹¤ë¥³¥ß¥Ã¥È¸¢¤òÍ¿¤¨¤é¤ì¤Þ¤·¤¿¡£ ºÇ½é¤Îºî¶È¤Ï¡¢GSoC ¤Î·ë²Ì¤ò¥Ä¥ê¡¼¤ËÈ¿±Ç¤µ¤»¤ëͽÄê¤Ç¤¹¡£

1 30 &os; 7.3-BETA1 ¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿

&os;-7.3 ¥ê¥ê¡¼¥¹¥µ¥¤¥¯¥ë¤ÎºÇ½é¤Î BETA ¥Ó¥ë¥É¤¬¸ø³«¤µ¤ì¤Þ¤·¤¿¡£ Tier-1 ¥¢¡¼¥­¥Æ¥¯¥Á¥ã¤Î ISO ¥¤¥á¡¼¥¸¤Ï¡¢ ¤Û¤È¤ó¤É¤Î &os; ¥ß¥é¡¼¥µ¥¤¥È ¤«¤é Æþ¼ê ¤Ç¤­¤Þ¤¹¡£

29

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Bruce Cran (src)

28

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Ulrich Spörlein (src)

26

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Romain Tartière (ports)

¿·¥³¥ß¥Ã¥¿½¢Ç¤: Alberto Villa (ports)

17 ³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (2009 ǯ 10 ·î - 12 ·î)

2009 ǯ 10 ·î ¤«¤é 12 ·î¤Ë¤ª¤±¤ë³«È¯¿ÊĽ¥ì¥Ý¡¼¥È (38 ¥¨¥ó¥È¥ê) ¤¬ ¸ø³« ¤µ¤ì¤Þ¤·¤¿¡£

2002 1 12 Íè¤ë 4.5 ¥ê¥ê¡¼¥¹Íѥƥ¹¥È¥¬¥¤¥É

FreeBSD 4.5 ¥ê¥ê¡¼¥¹¥¨¥ó¥¸¥Ë¥¢¥ê¥ó¥°¥Á¡¼¥à¤Ï Íè¤ë FreeBSD 4.5 ¥ê¥ê¡¼¥¹ÍѤΠ¥Æ¥¹¥È¥¬¥¤¥É ¤ò¸ø³«¤·¤Þ¤·¤¿¡£ 4.5 ¤¬º£¤Þ¤Ç¤Ë¤Ê¤¤°ÂÄêÀ­¤ò»ý¤Á¡¢¹âÀ­Ç½¤ò¼¨¤¹¤è¤¦¤Ë ²æ¡¹¤ò»Ù±ç¤·¤Æ¤¯¤À¤µ¤¤¡£

10 ¿·¥Á¥å¡¼¥È¥ê¥¢¥ë: "FreeBSD ¤Ç¥æ¡¼¥íµ­¹æ"

Aaron Kaplan ¤Ï FreeBSD ¤Ç¿·¤·¤¤ ¥æ¡¼¥íµ­¹æ¤ò»È¤¦ ÍѤ˥·¥¹¥Æ¥à¤òÀßÄꤹ¤ëÊýË¡¤ò µ­½Ò¤·¤¿µ­»ö¤ò´ó¹Æ¤·¤Æ¤¯¤ì¤Þ¤·¤¿¡£

diff --git a/ja_JP.eucJP/share/xml/release.l10n.ent b/ja_JP.eucJP/share/xml/release.l10n.ent index 0aeee734ba..ef24d4a003 100644 --- a/ja_JP.eucJP/share/xml/release.l10n.ent +++ b/ja_JP.eucJP/share/xml/release.l10n.ent @@ -1,156 +1,150 @@ ¥Ð¡¼¥¸¥ç¥ó¤È¥×¥é¥Ã¥È¥Õ¥©¡¼¥à ÇÛÉÛ¸µ ISO TODO List FreeBSD &betarel2.current;-&betarel2.vers; [View] [View] amd64
(x86-64, x64) [ÇÛÉÛ¸µ] [ISO] i386 [ÇÛÉÛ¸µ] [ISO] ia64 a href="&url.rel;/ia64/ia64/&betarel2.current;-&betarel2.vers;">[ÇÛÉÛ¸µ] [ISO] powerpc [ÇÛÉÛ¸µ] [ISO] powerpc64 [ÇÛÉÛ¸µ] [ISO] sparc64 [ÇÛÉÛ¸µ] [ISO] '> ]]>

¼¡²ó¤Î FreeBSD ¥ê¥ê¡¼¥¹¤ò¼êÅÁ¤¦

»ä¤¿¤Á¤Î³«È¯¼Ô¤È¥ê¥ê¡¼¥¹¥¨¥ó¥¸¥Ë¥¢Ã£¤Ï¡¢ FreeBSD ¤Î¼¡¤Î¥ê¥ê¡¼¥¹¤Ë¸þ¤±¤Æºî¶È¤ò¹Ô¤Ã¤Æ¤¤¤Þ¤¹¡£ ¥Æ¥¹¥È¤Ë¶½Ì£¤¬¤¢¤ë¤Î¤Ê¤é¡¢ºÇ¿·¤Î¥Ó¥ë¥É¤ò¥À¥¦¥ó¥í¡¼¥É¤·¤Æ¤¯¤À¤µ¤¤¡£ ÅöÁ³¤Î¤³¤È¤Ç¤¹¤¬¡¢¤³¤ì¤é¤Î¥¤¥á¡¼¥¸¤Ï¥Æ¥¹¥ÈÌÜŪ¤Ç¤¢¤ê¡¢ ¶È̳´Ä¶­¤Ç¤Ï»ÈÍѤ¹¤Ù¤­¤Ç¤Ï¤Ê¤¤¤È¸À¤¦¤³¤È¤ËÃí°Õ¤·¤Æ¤¯¤À¤µ¤¤¡£

- - -
¥Ð¡¼¥¸¥ç¥ó¤È¥×¥é¥Ã¥È¥Õ¥©¡¼¥à ÇÛÉÛ¸µ ISO
FreeBSD &betarel.current;-&betarel.vers;
amd64
(x86-64, x64)
[ÇÛÉÛ¸µ] [ISO]
i386 [ÇÛÉÛ¸µ] [ISO]
ia64 [ÇÛÉÛ¸µ] [ISO]
&beta.second; '> ]]> diff --git a/ru_RU.KOI8-R/articles/contributing/article.xml b/ru_RU.KOI8-R/articles/contributing/article.xml index 048bed79af..42e7bbf8bb 100644 --- a/ru_RU.KOI8-R/articles/contributing/article.xml +++ b/ru_RU.KOI8-R/articles/contributing/article.xml @@ -1,551 +1,551 @@
õÞÁÓÔÉÅ × ÐÒÏÅËÔÅ FreeBSD ÷ ÜÔÏÊ ÓÔÁÔØÅ ÏÐÉÓÁÎÙ ÒÁÚÌÉÞÎÙÅ ÓÐÏÓÏÂÙ, ËÏÔÏÒÙÍÉ ÏÔÄÅÌØÎÙÅ ÌÉÃÁ É ÏÒÇÁÎÉÚÁÃÉÊ ÍÏÇÕÔ ÐÒÉÎÑÔØ ÕÞÁÓÔÉÅ × ðÒÏÅËÔÅ FreeBSD. äÖÏÒÄÁÎ èÁÂÂÁÒÄ ôÅËÓÔ ÐÒÅÄÏÓÔÁ×ÉÌ &tm-attrib.freebsd; &tm-attrib.ieee; &tm-attrib.general; $FreeBSD$ $FreeBSD$ ÕÞÁÓÔÉÅ éÔÁË, ×Ù ÈÏÔÉÔÅ ×ÎÅÓÔÉ Ó×ÏÊ ×ËÌÁÄ ×Ï FreeBSD? üÔÏ ×ÅÌÉËÏÌÅÐÎÏ! öÉÚÎÅÓÐÏÓÏÂÎÏÓÔØ FreeBSD ÏÓÎÏ×ÁÎÁ ÎÁ ÐÏÍÏÝÉ Å£ ÐÏÌØÚÏ×ÁÔÅÌÅÊ. ÷ÁÛÁ ÐÏÍÏÝØ ÎÅ ÔÏÌØËÏ ÐÒÉÎÉÍÁÅÔÓÑ, ÏÎÁ ÖÉÚÎÅÎÎÏ ÎÅÏÂÈÏÄÉÍÁ ÄÌÑ ÐÒÏÄÏÌÖÅÎÉÑ ÒÏÓÔÁ FreeBSD. îÅÓÍÏÔÒÑ ÎÁ Õ×ÅÒÅÎÉÑ ÎÅËÏÔÏÒÙÈ ÌÀÄÅÊ, ×ÁÍ ÎÅ ÎÕÖÎÏ ÂÙÔØ ÇÅÎÉÁÌØÎÙÍ ÐÒÏÇÒÁÍÍÉÓÔÏÍ ÉÌÉ ÐÅÒÓÏÎÏÊ, ÌÉÞÎÏ Ó×ÑÚÁÎÎÏÊ Ó ÒÕËÏ×ÏÄÑÝÅÊ ÇÒÕÐÐÏÊ FreeBSD, ÞÔÏÂÙ ×ÁÛÁ ÐÏÍÏÝØ ÂÙÌÁ ÐÒÉÎÑÔÁ. FreeBSD ÒÁÚÒÁÂÁÔÙ×ÁÅÔ ÂÏÌØÛÏÅ É Õ×ÅÌÉÞÉ×ÁÀÝÅÅÓÑ ËÏÌÉÞÅÓÔ×Ï ÕÞÁÓÔÎÉËÏ× ÓÏ ×ÓÅÇÏ ÍÉÒÁ, ÓÁÍÏÇÏ ÒÁÚÎÏÇÏ ×ÏÚÒÁÓÔÁ É ÒÁÚÎÙÈ ÏÂÌÁÓÔÅÊ ÔÅÈÎÉÞÅÓËÏÊ ÜËÓÐÅÒÔÉÚÙ. òÁÂÏÔÙ, ËÏÔÏÒÕÀ ÎÅÏÂÈÏÄÉÍÏ ÓÄÅÌÁÔØ, ×ÓÅÇÄÁ ÂÏÌØÛÅ, ÞÅÍ ÒÁÚÒÁÂÏÔÞÉËÏ×, ÍÏÇÕÝÉÈ Å£ ×ÙÐÏÌÎÉÔØ, É ÄÏÐÏÌÎÉÔÅÌØÎÁÑ ÐÏÍÏÞØ ×ÓÅÇÄÁ ÐÒÉ×ÅÔÓÔ×ÕÅÔÓÑ. ðÒÏÅËÔ FreeBSD ÚÁÎÉÍÁÅÔÓÑ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ × ÃÅÌÏÍ, Á ÎÅ ÔÏÌØËÏ ÑÄÒÏÍ ÉÌÉ ÎÅÓËÏÌØËÉÍÉ ÏÔÄÅÌØÎÙÍÉ ÕÔÉÌÉÔÁÍÉ. ôÁËÉÍ ÏÂÒÁÚÏÍ, × ÎÁÛÅÍ TODO-ÓÐÉÓËÅ ÛÉÒÏËÉÊ ÓÐÅËÔÒ ÚÁÄÁÞ: ÏÔ ÄÏËÕÍÅÎÔÁÃÉÉ, ÂÅÔÁ-ÔÅÓÔÉÒÏ×ÁÎÉÑ É ÐÒÅÚÅÎÔÁÃÉÊ ÄÏ ÐÒÏÇÒÁÍÍÙ ÕÓÔÁÎÏ×ËÉ ÓÉÓÔÅÍÙ É ÓÐÅÃÉÆÉÞÅÓËÉÈ ÒÁÚÒÁÂÏÔÏË ÕÒÏ×ÎÑ ÑÄÒÁ. ìÀÄÉ ÌÀÂÏÇÏ ÕÒÏ×ÎÑ ÐÒÁËÔÉÞÅÓËÉ × ÌÀÂÏÊ ÏÂÌÁÓÔÉ ÏÐÒÅÄÅÌ£ÎÎÏ ÓÍÏÇÕÔ ÐÏÍÏÞØ ÐÒÏÅËÔÕ. ëÏÍÍÅÒÞÅÓËÉÅ ÓÔÒÕËÔÕÒÙ, Ó×ÑÚÁÎÎÙÅ Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ FreeBSD, ÔÁËÖÅ ÐÒÉÇÌÁÛÁÀÔÓÑ Ë ÄÉÁÌÏÇÕ. îÕÖÎÙ ÌÉ ×ÁÍ ÏÓÏÂÙÅ ÒÁÓÛÉÒÅÎÉÑ, ÄÌÑ ÒÁÂÏÔÙ ×ÁÛÅÇÏ ÐÒÏÄÕËÔÁ? ÷Ù Õ×ÉÄÉÔÅ, ÞÔÏ ÍÙ ÏÔ×ÅÞÁÅÍ ÎÁ ×ÁÛÉ ÚÁÐÒÏÓÙ, ÅÓÌÉ ÏÎÉ ÎÅ ÓÌÉÛËÏÍ ÎÅÏÂÙÞÎÙ. ÷Ù ÒÁÂÏÔÁÅÔÅ ÎÁÄ ÄÏÐÏÌÎÉÔÅÌØÎÙÍÉ ÐÒÏÄÕËÔÁÍÉ? äÁÊÔÅ ÎÁÍ ÚÎÁÔØ! íÙ ÓÍÏÖÅÍ ÒÁÂÏÔÁÔØ ×ÍÅÓÔÅ ÎÁÄ ÎÅËÏÔÏÒÙÍÉ ÅÇÏ ÁÓÐÅËÔÁÍÉ. íÉÒ Ó×ÏÂÏÄÎÏÇÏ ÐÒÏÇÒÁÍÍÎÏÇÏ ÏÂÅÓÐÅÞÅÎÉÑ ÓÔÁ×ÉÔ ÐÏÄ ÓÏÍÎÅÎÉÅ ÍÎÏÇÉÅ ÓÕÝÅÓÔ×ÕÀÝÉÅ ÐÒÅÄÓÔÁ×ÌÅÎÉÑ Ï ÔÏÍ, ËÁË ÐÒÏÇÒÁÍÍÎÏÇÏ ÏÂÅÓÐÅÞÅÎÉÅ ÒÁÚÒÁÂÁÔÙ×ÁÅÔÓÑ, ÐÒÏÄÁ£ÔÓÑ É ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ, É ÍÙ ÎÁÓÔÏÑÔÅÌØÎÏ ÐÒÏÓÉÍ ×ÁÓ ÐÏÓÍÏÔÒÅÔØ ÎÁ ÎÅÇÏ ÅÝ£ ÒÁÚ. þÔÏ ÎÕÖÎÏ ÷ ÓÌÅÄÕÀÝÅÍ ÐÅÒÅÞÎÅ ÐÒÅÄÓÔÁ×ÌÅÎÙ ÚÁÄÁÞÉ É ÐÏÄÐÒÏÅËÔÙ, Ñ×ÌÑÀÝÉÅÓÑ ÎÅËÏÔÏÒÙÍ ÏÔÒÁÖÅÎÉÅÍ ÒÁÚÌÉÞÎÙÈ ÓÐÉÓËÏ× TODO É ÚÁÐÒÏÓÏ× ÐÏÌØÚÏ×ÁÔÅÌÅÊ. ôÅËÕÝÉÅ ÚÁÄÁÞÉ ÎÅ ÄÌÑ ÐÒÏÇÒÁÍÍÉÓÔÏ× íÎÏÇÉÅ ÌÀÄÉ, Ó×ÑÚÁÎÎÙÅ Ó FreeBSD, ÎÅ Ñ×ÌÑÀÔÓÑ ÐÒÏÇÒÁÍÍÉÓÔÁÍÉ. ÷ ðÒÏÅËÔÅ ÕÞÁÓÔ×ÕÀÔ ÓÏÚÄÁÔÅÌÉ ÄÏËÕÍÅÎÔÁÃÉÉ, Web-ÄÉÚÁÊÎÅÒÙ É ÓÐÅÃÉÁÌÉÓÔÙ ÐÏ ÐÏÄÄÅÒÖËÅ ÐÏÌØÚÏ×ÁÔÅÌÅÊ. ÷ÓÅ, ÞÔÏ ÉÍ ÎÕÖÎÏ ÄÌÑ ÕÞÁÓÔÉÑ, ÜÔÏ Ó×Ï£ ×ÒÅÍÑ É ÖÅÌÁÎÉÅ ÕÞÉÔØÓÑ. ðÅÒÉÏÄÉÞÅÓËÉ ÞÉÔÁÊÔÅ FAQ É òÕËÏ×ÏÄÓÔ×Ï. åÓÌÉ ÞÔÏ-ÔÏ ÏÐÉÓÁÎÏ ÐÌÏÈÏ, ÕÓÔÁÒÅÌÏ ÉÌÉ ÄÁÖÅ ÐÏÌÎÏÓÔØÀ ÎÅÐÒÁ×ÉÌØÎÏ, ÄÁÊÔÅ ÎÁÍ ÚÎÁÔØ. åÝ£ ÌÕÞÛÅ, ÅÓÌÉ ×Ù ÐÒÉÛÌ£ÔÅ ÎÁÍ ÉÓÐÒÁ×ÌÅÎÉÅ (×ÙÕÞÉÔØ Docbook ÎÅ ÔÁË ÓÌÏÖÎÏ, ÎÏ É ÐÒÏÔÉ× ÐÏÓÌÁÎÉÊ × ÆÏÒÍÁÔÅ ASCII ÎÉËÔÏ ×ÏÚÒÁÖÁÔØ ÎÅ ÂÕÄÅÔ). ðÏÍÏÇÉÔÅ ÐÅÒÅ×ÅÓÔÉ ÄÏËÕÍÅÎÔÁÃÉÀ FreeBSD ÎÁ ×ÁÛ ÒÏÄÎÏÊ ÑÚÙË. åÓÌÉ ÄÏËÕÍÅÎÔÁÃÉÑ ÎÁ ×ÁÛÅÍ ÑÚÙËÅ ÕÖÅ ÓÕÝÅÓÔ×ÕÅÔ, ×Ù ÍÏÖÅÔÅ ÐÏÍÏÞØ ÐÅÒÅ×ÅÓÔÉ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ÄÏËÕÍÅÎÔÙ ÉÌÉ ÐÒÏ×ÅÒÉÔØ, ÎÅ ÕÓÔÁÒÅÌÉ ÌÉ ÐÅÒÅ×ÏÄÙ. ðÅÒ×ÙÍ ÄÅÌÏÍ ×ÚÇÌÑÎÉÔÅ ÎÁ FAQ ÐÏ ÐÅÒÅ×ÏÄÁÍ × õÞÅÂÎÉËÅ ÐÒÏÅËÔÁ ÄÏËÕÍÅÎÔÉÒÏ×ÁÎÉÑ FreeBSD. ÷ÁÓ ÎÅ ÐÒÉÚÙ×ÁÀÔ ÐÅÒÅ×ÅÓÔÉ ×ÓÅ ÄÏËÕÍÅÎÔÙ FreeBSD — ËÁË ÄÏÂÒÏ×ÏÌÅÃ, ×Ù ÍÏÖÅÔÅ ÄÅÌÁÔØ ÓÔÏÌØËÏ ÐÅÒÅ×ÏÄÏ×, ÓËÏÌØËÏ ÚÁÈÏÔÉÔÅ. åÓÌÉ ËÔÏ-ÔÏ ÎÁÞÁÌ ÐÅÒÅ×ÏÄ, ÄÒÕÇÉÅ ×ÓÅÇÄÁ ÐÒÉÓÏÅÄÉÎÑÔÓÑ. åÓÌÉ Õ ×ÁÓ ÅÓÔØ ×ÒÅÍÑ É ÖÅÌÁÎÉÅ ÐÅÒÅ×ÅÓÔÉ ÏÄÎÕ ÞÁÓÔØ ÄÏËÕÍÅÎÔÁÃÉÉ, ÐÏÖÁÌÕÊÓÔÁ, ÐÅÒÅ×ÅÄÉÔÅ ÉÎÓÔÒÕËÃÉÉ ÐÏ ÕÓÔÁÎÏ×ËÅ. ÷ÒÅÍÑ ÏÔ ×ÒÅÍÅÎÉ (ÉÌÉ ÄÁÖÅ ÒÅÇÕÌÑÒÎÏ) ÞÉÔÁÊÔÅ &a.questions; É &ng.misc;. ÷ÁÍ ÍÏÖÅÔ ÐÏÎÒÁ×ÉÔØÓÑ ÄÅÌÉÔØÓÑ Ó×ÏÉÍ ÏÐÙÔÏÍ É ÐÏÍÏÇÁÔØ ÌÀÄÑÍ ÒÅÛÁÔØ ÉÈ ÐÒÏÂÌÅÍÙ; ÉÎÏÇÄÁ ×Ù ÓÍÏÖÅÔÅ ÕÚÎÁÔØ ÄÌÑ ÓÅÂÑ ÞÔÏ-ÔÏ ÎÏ×ÏÅ! üÔÉ ÆÏÒÕÍÙ ÍÏÇÕÔ ÔÁËÖÅ ÓÔÁÔØ ÉÓÔÏÞÎÉËÏÍ ÉÄÅÊ, ÎÁÄ ËÏÔÏÒÙÍÉ ×ÁÍ ÓÔÏÉÔ ÐÏÒÁÂÏÔÁÔØ. ôÅËÕÝÉÅ ÚÁÄÁÞÉ ÄÌÑ ÐÒÏÇÒÁÍÍÉÓÔÏ× âÏÌØÛÉÎÓÔ×Ï ÚÁÄÁÞ, ÐÅÒÅÞÉÓÌÅÎÎÙÈ ÚÄÅÓØ, ÔÒÅÂÕÀÔ ÌÉÂÏ ÚÎÁÞÉÔÅÌØÎÙÈ ÚÁÔÒÁÔ ×ÒÅÍÅÎÉ, ÌÉÂÏ ÇÌÕÂÏËÉÈ ÚÎÁÎÉÊ ÑÄÒÁ FreeBSD, ÌÉÂÏ ÔÏÇÏ É ÄÒÕÇÏÇÏ. ïÄÎÁËÏ ÉÍÅÅÔÓÑ ÔÁËÖÅ ÍÎÏÇÏ ÐÏÌÅÚÎÙÈ ÚÁÄÁÞ, ËÏÔÏÒÙÅ ÐÏÄÏÊÄÕÔ ÄÌÑ ×ÏÓËÒÅÓÎÙÈ ÈÁËÅÒÏ×. åÓÌÉ ×Ù ÒÁÂÏÔÁÅÔÅ Ó FreeBSD-CURRENT É ÏÂÌÁÄÁÅÔÅ ÈÏÒÏÛÉÍ ÐÏÄËÌÀÞÅÎÉÅÍ Ë Internet, ÔÏ ÓÕÝÅÓÔ×ÕÅÔ ÍÁÛÉÎÁ current.FreeBSD.org, ËÏÔÏÒÁÑ ÓÔÒÏÉÔ ÐÏÌÎÙÊ ÒÅÌÉÚ ÅÖÅÄÎÅ×ÎÏ—ÓÅÊÞÁÓ É ×ÓÅÇÄÁ. ðÏÐÒÏÂÕÊÔÅ ÕÓÔÁÎÏ×ÉÔØ ÓÁÍÙÊ ÐÏÓÌÅÄÎÉÊ ÒÅÌÉÚ Ó ÜÔÏÊ ÍÁÛÉÎÙ É ÓÏÏÂÝÉÔÅ ÏÂÏ ×ÓÅÈ ÏÂÎÁÒÕÖÅÎÎÙÈ ÐÒÉ ÜÔÏÍ ÏÛÉÂËÁÈ. þÉÔÁÊÔÅ &a.bugs;. úÄÅÓØ ÍÏÖÅÔ ×ÓÔÒÅÔÉÔØÓÑ ÐÒÏÂÌÅÍÁ, ËÏÔÏÒÕÀ ×Ù ÓÍÏÖÅÔÅ ËÏÎÓÔÒÕËÔÉ×ÎÏ ÐÒÏËÏÍÍÅÎÔÉÒÏ×ÁÔØ ÉÌÉ ÐÁÔÞÉ, ËÏÔÏÒÙÅ ×Ù ÍÏÖÅÔÅ ÐÒÏÔÅÓÔÉÒÏ×ÁÔØ. ìÉÂÏ ×Ù ÍÏÖÅÔÅ ÄÁÖÅ ÐÏÐÙÔÁÔØÓÑ ÉÓÐÒÁ×ÉÔØ ËÁËÕÀ-ÔÏ ÐÒÏÂÌÅÍÕ ÓÁÍÏÓÔÏÑÔÅÌØÎÏ. åÓÌÉ ×Ù ÚÎÁÅÔÅ Ï ÓÕÝÅÓÔ×Ï×ÁÎÉÉ ËÁËÉÈ-ÌÉÂÏ ÉÓÐÒÁ×ÌÅÎÉÊ ÏÛÉÂÏË, ÕÓÐÅÛÎÏ ÐÒÉÍÅΣÎÎÙÈ Ë -CURRENT, ÎÏ ÅÝ£ ÎÅ ÐÅÒÅÎÅÓ£ÎÎÙÈ × -STABLE ÐÏÓÌÅ ÄÏÓÔÁÔÏÞÎÏ ÂÏÌØÛÏÇÏ ÉÎÔÅÒ×ÁÌÁ ×ÒÅÍÅÎÉ (ÏÂÙÞÎÏ ÎÅÓËÏÌØËÏ ÎÅÄÅÌØ), ÎÁÐÒÁרÔÅ ËÏÍÍÉÔÔÅÒÕ ×ÅÖÌÉ×ÏÅ ÎÁÐÏÍÉÎÁÎÉÅ. ðÅÒÅÎÏÓ ÓÔÏÒÏÎÎÅÇÏ ÐÒÏÇÒÁÍÍÎÏÇÏ ÏÂÅÓÐÅÞÅÎÉÑ × ËÁÔÁÌÏÇ src/contrib ÄÅÒÅ×Á ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ×. ðÒÏ×ÅÒËÁ ÁËÔÕÁÌØÎÏÓÔÉ ËÏÄÁ × ËÁÔÁÌÏÇÅ src/contrib. ðÏÓÔÒÏÅÎÉÅ ÉÚ ÄÅÒÅ×Á ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ× (ÉÌÉ Å£ ÞÁÓÔÉ) Ó ×ËÌÀÞÅÎÉÅÍ ÒÅÖÉÍÁ ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÐÒÅÄÕÐÒÅÖÄÅÎÉÊ, ÉÚÂÁ×ÌÅÎÉÅ ÏÔ ÎÉÈ. éÓÐÒÁ×ÌÅÎÉÅ ÐÒÅÄÕÐÒÅÖÄÅÎÉÊ ÏÔ ÐÏÒÔÏ×, ËÏÔÏÒÙÅ ÉÓÐÏÌØÚÕÀÔ ÎÅÄÏÐÕÓÔÉÍÙÅ ×ÙÚÏ×Ù ÔÉÐÁ gets() ÉÌÉ ×ËÌÀÞÁÀÔ ÆÁÊÌ ÏÂßÑ×ÌÅÎÉÊ malloc.h. åÓÌÉ ×Ù ÓÏÚÄÁ×ÁÌÉ ÐÏÒÔÙ É ×ÁÍ ÐÒÉÈÏÄÉÌÏÓØ ÄÅÌÁÔØ ÓÐÅÃÉÆÉÞÎÙÅ ÄÌÑ &os; ÉÓÐÒÁ×ÌÅÎÉÑ, ÐÏÛÌÉÔÅ ×ÁÛÉ ÐÁÔÞÉ Á×ÔÏÒÁÍ ÏÒÉÇÉÎÁÌØÎÏÇÏ ÐÒÏÇÒÁÍÍÎÏÇÏ ÏÂÅÓÐÅÞÅÎÉÑ (ÜÔÏ ÕÐÒÏÓÔÉÔ ×ÁÍ ÖÉÚÎØ ÐÒÉ ×ÙÐÕÓËÅ ÓÌÅÄÕÀÝÅÊ ×ÅÒÓÉÉ). îÁÊÄÉÔÅ ËÏÐÉÉ ÏÆÉÃÉÁÌØÎÙÈ ÓÔÁÎÄÁÒÔÏ×, ÎÁÐÒÉÍÅÒ, &posix;. ÷Ù ÍÏÖÅÔÅ ÎÁÊÔÉ ÎÅÓËÏÌØËÏ ÓÓÙÌÏË ÎÁ ÎÉÈ ÎÁ ÓÔÒÁÎÉÃÅ Web-ÓÁÊÔÁ ðÒÏÅËÔÁ ÓÏÏÔ×ÅÔÓÔ×ÉÑ FreeBSD ÓÔÁÎÄÁÒÔÁÍ C99 & POSIX. óÒÁ×ÎÉÔÅ ÐÏ×ÅÄÅÎÉÅ FreeBSD Ó ÔÅÍ, ÞÔÏ ÏÐÒÅÄÅÌÅÎÏ ÓÔÁÎÄÁÒÔÏÍ. åÓÌÉ ÒÅÁËÃÉÑ ÏÔÌÉÞÁÅÔÓÑ, ÏÓÏÂÅÎÎÏ × ÎÅÚÎÁÞÉÔÅÌØÎÙÈ ÉÌÉ ÎÅÐÏÎÑÔÎÙÈ ÒÁÚÄÅÌÁÈ ÓÐÅÃÉÆÉËÁÃÉÉ, ÎÁÐÒÁרÔÅ Ï ÜÔÏÍ PR. åÓÌÉ ÍÏÖÅÔÅ, ÎÁÊÄÉÔÅ, ËÁË ÉÓÐÒÁ×ÉÔØ ÜÔÏ É ×ËÌÀÞÉÔÅ × PR ÐÁÔÞ. åÓÌÉ ×Ù ÐÏÌÁÇÁÅÔÅ, ÞÔÏ × ÓÔÁÎÄÁÒÔÅ ÅÓÔØ ÏÛÉÂËÁ, ÎÁÐÒÁרÔÅ ÚÁÐÒÏÓ ÅÇÏ ÒÁÚÒÁÂÏÔÞÉËÁÍ. ðÒÅÄÌÏÖÉÔÅ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ÚÁÄÁÞÉ ÄÌÑ ÜÔÏÇÏ ÓÐÉÓËÁ! òÁÂÏÔÁ Ó ÂÁÚÏÊ ÓÏÏÂÝÅÎÉÊ Ï ÏÛÉÂËÁÈ PR ÂÁÚÁ ÓÏÏÂÝÅÎÉÊ Ï ÏÛÉÂËÁÈ óÐÉÓÏË ÓÏÏÂÝÅÎÉÊ Ï ÏÛÉÂËÁÈ FreeBSD ÓÏÄÅÒÖÉÔ ×ÓÅ ÁËÔÕÁÌØÎÙÅ ÓÏÏÂÝÅÎÉÑ Ï ÐÒÏÂÌÅÍÁÈ É ÚÁÐÒÏÓÙ ÎÁ ÕÌÕÞÛÅÎÉÑ, ËÏÔÏÒÙÅ ÂÙÌÉ ÐÏÓÌÁÎÙ ÐÏÌØÚÏ×ÁÔÅÌÑÍÉ FreeBSD. âÁÚÁ ÄÁÎÎÙÈ PR ÓÏÄÅÒÖÉÔ ÚÁÄÁÞÉ ËÁË ÄÌÑ ÐÒÏÇÒÁÍÍÉÓÔÏ×, ÔÁË É ÎÅ ÄÌÑ ÎÉÈ. ðÒÏÓÍÏÔÒÉÔÅ ÏÔËÒÙÔÙÅ PR, ÎÁÊÄÉÔÅ ÔÅ, ÞÔÏ ÐÒÉ×ÌÅËÕÔ ×ÁÛÅ ×ÎÉÍÁÎÉÅ. îÅËÏÔÏÒÙÅ ÉÚ ÎÉÈ ÍÏÇÕÔ ÂÙÔØ ÏÞÅÎØ ÐÒÏÓÔÙÍÉ, ÔÒÅÂÕÀÝÉÍÉ ÌÉÛØ ÅÝ£ ÏÄÎÏÊ ÐÁÒÙ ÇÌÁÚ, ÞÔÏÂÙ ÐÏÓÍÏÔÒÅÔØ É ÐÏÄÔ×ÅÒÄÉÔØ, ÞÔÏ ÐÒÅÄÌÁÇÁÅÍÏÅ × PR ÉÓÐÒÁ×ÌÅÎÉÅ ÄÏÓÔÁÔÏÞÎÏ. äÒÕÇÉÅ ÍÏÇÕÔ ÂÙÔØ ÇÏÒÁÚÄÏ ÓÌÏÖÎÅÅ É ÄÁÖÅ ×Ï×ÓÅ ÎÅ ÓÏÄÅÒÖÁÔØ ÉÓÐÒÁ×ÌÅÎÉÑ. îÁÞÎÉÔÅ Ó ÔÅÈ PR, ËÏÔÏÒÙÅ ÎÉËÏÍÕ ÅÝ£ ÎÅ ÎÁÚÎÁÞÅÎÙ. åÓÌÉ PR ÕÖÅ ÚÁ ËÅÍ-ÔÏ ÚÁËÒÅÐÌÅÎÏ, ÎÏ ÓÏÄÅÒÖÉÔ ÐÒÏÂÌÅÍÕ, ËÏÔÏÒÕÀ ×Ù ÍÏÖÅÔÅ ÒÅÛÉÔØ, ÎÁÐÒÁרÔÅ ÐÏ ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÅ ÐÉÓØÍÏ ÞÅÌÏ×ÅËÕ, ËÏÔÏÒÏÍÕ ÎÁÚÎÁÞÅÎÏ ÜÔÏ PR, É ÓÐÒÏÓÉÔÅ, ÍÏÖÅÔÅ ÌÉ ×Ù ÐÏÒÁÂÏÔÁÔØ ÎÁÄ ÎÅÊ—Õ ÎÉÈ ÕÖÅ ÍÏÖÅÔ ÇÏÔÏ× ÐÁÔÞ ÄÌÑ ÔÅÓÔÉÒÏ×ÁÎÉÑ ÉÌÉ ËÁËÉÅ-ÔÏ ÉÄÅÉ, ËÏÔÏÒÙÅ ÍÏÖÎÏ ×ÍÅÓÔÅ ÏÂÓÕÄÉÔØ. ÷ÙÂÅÒÉÔÅ ÏÄÉÎ ÉÚ ÐÕÎËÔÏ× ÓÏ ÓÔÒÁÎÉÞËÉ <quote>ÉÄÅÊ</quote> óÐÉÓÏË ÐÒÏÅËÔÏ× É ÉÄÅÊ ÄÌÑ ÄÏÂÒÏ×ÏÌØÃÅ× ÔÁËÖÅ ÄÏÓÔÕÐÅÎ ÄÌÑ ÌÀÄÅÊ, ÖÅÌÁÀÝÉÈ ÐÏÍÏÞØ ÐÒÏÅËÔÕ &os;. óÐÉÓÏË ÐÏÓÔÏÑÎÎÏ ÏÂÎÏ×ÌÑÅÔÓÑ É ÓÏÄÅÒÖÉÔ ÐÕÎËÔÙ, ËÁË ÄÌÑ ÐÒÏÇÒÁÍÍÉÓÔÏ×, ÔÁË É ÄÌÑ ÎÅ ÐÒÏÇÒÁÍÍÉÓÔÏ×, Ó ÉÎÆÏÒÍÁÃÉÅÊ Ï ËÁÖÄÏÍ ÐÒÏÅËÔÅ. ëÁË ÐÒÉÎÑÔØ ÕÞÁÓÔÉÅ × ÒÁÂÏÔÅ èÁÒÁËÔÅÒ ÕÞÁÓÔÉÑ × ÒÁÂÏÔÅ ÎÁÄ ÓÉÓÔÅÍÏÊ ÏÂÙÞÎÏ ÐÏÄÐÁÄÁÅÔ ÐÏÄ ÏÄÎÕ ÉÌÉ ÎÅÓËÏÌØËÏ ÉÚ ÓÌÅÄÕÀÝÉÈ 5 ËÁÔÅÇÏÒÉÊ: óÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ É ÏÔÚÙ×Ù ÏÂÝÅÇÏ ÈÁÒÁËÔÅÒÁ éÄÅÉ ÉÌÉ ÐÏÖÅÌÁÎÉÑ ÏÂÝÅÇÏ ÔÅÈÎÉÞÅÓËÏÇÏ ÈÁÒÁËÔÅÒÁ ÄÏÌÖÎÙ ÎÁÐÒÁ×ÌÑÔØÓÑ ÐÏ ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÅ × ÁÄÒÅÓ &a.hackers;. ðÏÄÏÂÎÙÍ ÖÅ ÏÂÒÁÚÏÍ ÔÏÔ, ËÔÏ ÉÎÔÅÒÅÓÕÅÔÓÑ ÔÁËÉÍÉ ×ÅÝÁÍÉ (É ÕÓÔÏÊÞÉ× Ë ÂÏÌØÛÏÍÕ ÐÏÔÏËÕ ÐÏÞÔÙ!) ÍÏÖÅÔ ÐÏÄÐÉÓÁÔØÓÑ ÎÁ ÓÐÉÓÏË ÒÁÓÓÙÌËÉ &a.hackers;. ïÂÒÁÔÉÔÅÓØ Ë òÕËÏ×ÏÄÓÔ×Õ FreeBSD ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÄÏÐÏÌÎÉÔÅÌØÎÏÊ ÉÎÆÏÒÍÁÃÉÉ Ï ÜÔÏÍ É ÄÒÕÇÉÈ ÓÐÉÓËÁÈ ÒÁÓÓÙÌËÉ. åÓÌÉ ×Ù ÎÁÛÌÉ ÏÛÉÂËÕ ÉÌÉ ÐÒÅÄÌÁÇÁÅÔÅ ×ÎÅÓÔÉ ËÁËÏÅ-ÔÏ ËÏÎËÒÅÔÎÏÅ ÉÓÐÒÁ×ÌÅÎÉÅ, ÐÏÖÁÌÕÊÓÔÁ, ÏÔÐÒÁרÔÅ ÓÏÏÂÝÅÎÉÅ ÐÒÉ ÐÏÍÏÝÉ ÐÒÏÇÒÁÍÍÙ &man.send-pr.1; ÉÌÉ Å£ Web-ÜË×É×ÁÌÅÎÔÁ. ðÏÓÔÁÒÁÊÔÅÓØ ÚÁÐÏÌÎÉÔØ ×ÓÅ ÐÏÌÑ × ÓÏÏÂÝÅÎÉÉ Ï ÏÛÉÂËÅ. åÓÌÉ ÅÇÏ ÒÁÚÍÅÒ ÏÎÏ ÎÅ ÐÒÅ×ÙÛÁÅÔ 65 ëÂÁÊÔ, ×ËÌÀÞÉÔÅ ×ÓÅ ÐÁÔÞÉ ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏ × ÓÏÏÂÝÅÎÉÅ. åÓÌÉ ÐÁÔÞ ÐÒÅÄÎÁÚÎÁÞÅÎ ÄÌÑ ÄÅÒÅ×Á ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ×, ÐÏÍÅÓÔÉÔÅ [PATCH] × ÔÅÍÅ ÓÏÏÂÝÅÎÉÑ. ðÒÉ ×ËÌÀÞÅÎÉÉ ÐÁÔÞÅÊ ÎÅ ÉÓÐÏÌØÚÕÊÔÅ ÔÅÈÎÉËÕ cut-and-paste, ÐÏÔÏÍÕ ÞÔÏ ÐÒÉ ÜÔÏÍ ÓÉÍ×ÏÌÙ ÔÁÂÕÌÑÃÉÉ ÐÒÅÏÂÒÁÚÕÀÔÓÑ × ÐÒÏÂÅÌÙ É ÐÁÔÞ ÓÔÁÎÏ×ÉÔÓÑ ÎÅÐÒÉÇÏÄÎÙÍ Ë ÉÓÐÏÌØÚÏ×ÁÎÉÀ. åÓÌÉ ÏÂß£Í ÐÁÔÞÅÊ ÐÒÅ×ÙÛÁÅÔ 20 ëÂÁÊÔ, ÌÕÞÛÅ ×ËÌÀÞÁÔØ ÉÈ × ÓÏÏÂÝÅÎÉÅ × ÓÖÁÔÏÍ ×ÉÄÅ, ÄÌÑ ÞÅÇÏ ÕÐÁËÕÊÔÅ ÉÈ (ÎÁÐÒÉÍÅÒ, ÐÒÉ ÐÏÍÏÝÉ &man.gzip.1; ÉÌÉ &man.bzip2.1;) É ÏÂÒÁÂÏÔÁÊÔÅ ÁÒÈÉ× ÕÔÉÌÉÔÏÊ &man.uuencode.1;. ðÏÓÌÅ ÏÔÐÒÁ×ËÉ ÓÏÏÂÝÅÎÉÑ ×Ù ÄÏÌÖÎÙ ÐÏÌÕÞÉÔØ ÐÏÄÔ×ÅÒÖÄÅÎÉÅ É ÎÏÍÅÒ ÄÌÑ ÏÔÓÌÅÖÉ×ÁÎÉÑ. óÏÈÒÁÎÉÔÅ ÜÔÏÔ ÎÏÍÅÒ, ÞÔÏÂÙ ÉÓÐÏÌØÚÏ×ÁÔØ ÅÇÏ × ÄÁÌØÎÅÊÛÅÍ ÐÒÉ ÎÁÐÒÁ×ÌÅÎÉÉ ÐÏÄÒÏÂÎÏÓÔÅÊ Ï ÐÒÏÂÌÅÍÅ ÐÏ ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÅ ÎÁ ÁÄÒÅÓ &a.bugfollowup;. éÓÐÏÌØÚÕÊÔÅ ÎÏÍÅÒ × ËÁÞÅÓÔ×Å ÔÅÍÙ ÐÉÓØÍÁ, ÎÁÐÒÉÍÅÒ, "Re: kern/3377". äÏÐÏÌÎÉÔÅÌØÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÌÀÂÏÍ ÓÏÏÂÝÅÎÉÉ Ï ÏÛÉÂËÅ ÄÏÌÖÎÁ ÎÁÐÒÁ×ÌÑÔØÓÑ ÜÔÉÍ ÓÐÏÓÏÂÏÍ. åÓÌÉ ×Ù ÎÅ ÐÏÌÕÞÉÌÉ ÐÏÄÔ×ÅÒÖÄÅÎÉÑ × ÔÅÞÅÎÉÅ ÒÁÚÕÍÎÏÇÏ ÐÅÒÉÏÄÁ ×ÒÅÍÅÎÉ (ÏÔ 3 ÄÎÅÊ ÄÏ ÎÅÄÅÌÉ, × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ×ÁÛÅÇÏ ÐÏÄËÌÀÞÅÎÉÑ Ë ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÙ) ÉÌÉ ÐÏ ËÁËÏÊ-ÔÏ ÐÒÉÞÉÎÅ ÎÅ ÍÏÖÅÔÅ ×ÏÓÐÏÌØÚÏ×ÁÔØÓÑ ËÏÍÁÎÄÏÊ &man.send-pr.1;, ÔÏ ÍÏÖÅÔÅ ÐÏÐÒÏÓÉÔØ ËÏÇÏ-ÎÉÂÕÄØ ÎÁÐÒÁ×ÉÔØ ÓÏÏÂÝÅÎÉÅ ÚÁ ×ÁÓ ÎÁ ÁÄÒÅÓ &a.bugs;. ðÒÏÞÔÉÔÅ ÔÁËÖÅ ÜÔÕ ÓÔÁÔØÀ, ÞÔÏÂÙ ÕÚÎÁÔØ, ËÁË ÐÉÓÁÔØ ÈÏÒÏÛÉÅ ÓÏÏÂÝÅÎÉÑ Ï ÐÒÏÂÌÅÍÁÈ. éÚÍÅÎÅÎÉÑ × ÄÏËÕÍÅÎÔÁÃÉÉ ÐÏÓÙÌËÁ ÄÏËÕÍÅÎÔÁÃÉÉ éÚÍÅÎÅÎÉÑ × ÄÏËÕÍÅÎÔÁÃÉÉ ÏÂÓÕÖÄÁÀÔÓÑ × &a.doc;. ðÏÖÁÌÕÊÓÔÁ, ÐÏÓÍÏÔÒÉÔÅ õÞÅÂÎÉË ðÒÏÅËÔÁ ÄÏËÕÍÅÎÔÉÒÏ×ÁÎÉÑ FreeBSD ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÐÏÌÎÙÈ ÉÎÓÔÒÕËÃÉÊ. ðÏÓÙÌÁÊÔÅ Ó×ÏÉ ÐÏÖÅÌÁÎÉÑ É ÉÚÍÅÎÅÎÉÑ (ÐÒÉÎÉÍÁÀÔÓÑ ÄÁÖÅ ÓÁÍÙÅ ÎÅÂÏÌØÛÉÅ!) ÐÒÉ ÐÏÍÏÝÉ &man.send-pr.1;, ËÁË ÜÔÏ ÏÐÉÓÁÎÏ × ÒÁÚÄÅÌÅ Ï ÓÏÏÂÝÅÎÉÑÈ Ï ÏÛÉÂËÁÈ É ÏÂÝÉÈ ÐÏÖÅÌÁÎÉÑÈ. éÚÍÅÎÅÎÉÑ Ë ÉÍÅÀÝÅÍÕÓÑ ÉÓÈÏÄÎÏÍÕ ËÏÄÕ FreeBSD-CURRENT äÏÂÁ×ÌÅÎÉÅ ÎÏ×ÏÇÏ ÉÓÈÏÄÎÏÇÏ ËÏÄÁ ÉÌÉ ×ÎÅÓÅÎÉÅ ÉÚÍÅÎÅÎÉÊ × ÓÕÝÅÓÔ×ÕÀÝÉÊ Ñ×ÌÑÅÔÓÑ ÎÅ ÔÁËÏÊ ÐÒÏÓÔÏÊ ÚÁÄÁÞÅÊ, É ÚÁ×ÉÓÉÔ ×Ï ÍÎÏÇÏÍ ÏÔ ÔÏÇÏ, ÎÁÓËÏÌØËÏ ×Ù ÄÁÌÅËÉ ÏÔ ÔÅËÕÝÅÇÏ ÓÏÓÔÏÑÎÉÑ ÒÁÚÒÁÂÏÔÏË ×Ï FreeBSD. óÕÝÅÓÔ×ÕÀÔ ÓÐÅÃÉÁÌØÎÙÅ ÐÒÏÍÅÖÕÔÏÞÎÙÅ ÒÅÌÉÚÙ FreeBSD, ÉÚ×ÅÓÔÎÙÅ ËÁË FreeBSD-CURRENT, ËÏÔÏÒÙÅ ÄÏÓÔÕÐÎÙ ÎÅÓËÏÌØËÉÍÉ ÒÁÚÎÙÍÉ ÓÐÏÓÏÂÁÍÉ, ÕÄÏÂÎÙÍÉ ÒÁÚÒÁÂÏÔÞÉËÁÍ, ÁËÔÉ×ÎÏ ÒÁÂÏÔÁÀÝÉÍ ÎÁÄ ÓÉÓÔÅÍÏÊ. ïÂÒÁÔÉÔÅÓØ Ë òÕËÏ×ÏÄÓÔ×Õ FreeBSD ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÄÏÐÏÌÎÉÔÅÌØÎÏÊ ÉÎÆÏÒÍÁÃÉÉ Ï ÐÏÌÕÞÅÎÉÉ É ÉÓÐÏÌØÚÏ×ÁÎÉÉ FreeBSD-CURRENT. åÓÌÉ ×Ù ÒÁÂÏÔÁÅÔÅ Ó ÎÅÓËÏÌØËÏ ÕÓÔÁÒÅ×ÛÉÍÉ ÉÓÈÏÄÎÙÍÉ ÔÅËÓÔÁÍÉ, ÔÏ ×ÁÛÉ ÉÚÍÅÎÅÎÉÑ ÉÎÏÇÄÁ ÍÏÇÕÔ ÏËÁÚÁÔØÓÑ ÕÖÅ ÎÅÎÕÖÎÙÍÉ ÉÌÉ ÓÌÉÛËÏÍ ÂÏÌØÛÉÍÉ, ÞÔÏÂÙ ÐÏ×ÔÏÒÎÏ ÉÎÔÅÇÒÉÒÏ×ÁÔØ ÉÈ ×Ï FreeBSD. õÍÅÎØÛÉÔØ ÔÁËÏÊ ÒÉÓË ÍÏÖÎÏ, ÐÏÄÐÉÓÁ×ÛÉÓØ ÎÁ ÓÐÉÓËÉ ÒÁÓÓÙÌËÉ &a.announce; É &a.current;, × ËÏÔÏÒÙÈ ÏÂÓÕÖÄÁÅÔÓÑ ÔÅËÕÝÅÅ ÓÏÓÔÏÑÎÉÅ ÓÉÓÔÅÍÙ. ðÒÅÄÐÏÌÏÖÉÍ, ÞÔÏ ×Ù ÓÍÏÇÌÉ ÐÏÌÕÞÉÔØ ÁËÔÕÁÌØÎÙÅ ÉÓÈÏÄÎÙÅ ÔÅËÓÔÙ, ÎÁ ÂÁÚÅ ËÏÔÏÒÙÈ ÄÅÌÁÌÉ Ó×ÏÉ ÉÚÍÅÎÅÎÉÑ. ôÏÇÄÁ ÓÌÅÄÕÀÝÉÍ ÛÁÇÏÍ Ñ×ÌÑÅÔÓÑ ÓÏÚÄÁÎÉÅ ÎÁÂÏÒÁ ÆÁÊÌÏ×, ÏÔÒÁÖÁÀÝÉÈ ×ÁÛÉ ÉÚÍÅÎÅÎÉÑ ÄÌÑ ÉÈ ÐÏÓÙÌËÉ ÔÅÍ, ËÔÏ ÏÔ×ÅÞÁÅÔ ÚÁ ÐÏÄÄÅÒÖËÕ FreeBSD. üÔÏ ÄÅÌÁÅÔÓÑ ÐÒÉ ÐÏÍÏÝÉ ËÏÍÁÎÄÙ &man.diff.1;. ðÒÅÄÐÏÞÔÉÔÅÌØÎÙÍ ÆÏÒÍÁÔÏÍ &man.diff.1; ÄÌÑ ÐÏÓÙÌËÉ ÐÁÔÞÅÊ Ñ×ÌÑÅÔÓÑ ÕÎÉÆÉÃÉÒÏ×ÁÎÎÁÑ ×ÙÄÁÞÁ, ÓÏÚÄÁ×ÁÅÍÁÑ ËÏÍÁÎÄÏÊ diff -u. diff ë ÐÒÉÍÅÒÕ: &prompt.user; diff -u oldfile newfile ÉÌÉ &prompt.user; diff -u -r -N olddir newdir ÓÏÚÄÁÓÔ ÎÁÂÏÒ ÐÁÔÞÅÊ × ÕÎÉÆÉÃÉÒÏ×ÁÎÎÏÍ ÆÏÒÍÁÔÅ ÄÌÑ ËÏÎËÒÅÔÎÏÇÏ ÆÁÊÌÁ Ó ÉÓÈÏÄÎÙÍ ÔÅËÓÔÏÍ ÉÌÉ ÄÌÑ ÉÅÒÁÒÈÉÉ ËÁÔÁÌÏÇÏ×. äÏÐÏÌÎÉÔÅÌØÎÕÀ ÉÎÆÏÒÍÁÃÉÀ ÍÏÖÎÏ ÎÁÊÔÉ × &man.diff.1;. ðÏÓÌÅ ÔÏÇÏ, ËÁË ×Ù ÐÏÌÕÞÉÌÉ ÎÁÂÏÒ diff-ÆÁÊÌÏ× (ËÏÔÏÒÙÅ ×Ù ÍÏÖÅÔÅ ÐÒÏÔÅÓÔÉÒÏ×ÁÔØ ËÏÍÁÎÄÏÊ &man.patch.1;), ×Ù ÄÏÌÖÎÙ ÐÒÉÓÌÁÔØ ÉÈ ÄÌÑ ×ËÌÀÞÅÎÉÑ ×Ï FreeBSD. ÷ÏÓÐÏÌØÚÕÊÔÅÓØ ÐÒÏÇÒÁÍÍÏÊ &man.send-pr.1;, ËÁË ÜÔÏ ÏÐÉÓÁÎÏ × ÒÁÚÄÅÌÅ Ï ÓÏÏÂÝÅÎÉÑÈ Ï ÏÛÉÂËÁÈ É ÏÂÝÉÈ ÚÁÍÅÞÁÎÉÑÈ. îÅ ÐÏÓÙÌÁÊÔÅ diff-ÆÁÊÌÙ × ÓÐÉÓÏË ÒÁÓÓÙÌËÉ &a.hackers;, ÏÎÉ ÂÕÄÕÔ ÐÏÔÅÒÑÎÙ! îÁÍ ÏÞÅÎØ ÎÕÖÎÁ ×ÁÛÁ ÐÏÍÏÝØ (ÜÔÏ ÄÏÂÒÏ×ÏÌØÎÙÊ ÐÒÏÅËÔ!); ÉÚ-ÚÁ ÎÁÛÅÊ ÚÁÎÑÔÏÓÔÉ ÍÙ ÎÅ ÓÍÏÖÅÍ ÒÁÓÓÍÏÔÒÅÔØ ÅÇÏ ÓÒÁÚÕ, É ÏÎ ÂÕÄÅÔ ÎÁÈÏÄÉÔØÓÑ × ÂÁÚÅ ÄÁÎÎÙÈ PR, ÐÏËÁ ÍÙ ÎÅ ÓÄÅÌÁÅÍ ÜÔÏ. õËÁÖÉÔÅ ÎÁ ×ÁÛÕ ÐÏÓÙÌËÕ, ×ËÌÀÞÉ× ÓÔÒÏËÕ [PATCH] × ÔÅÍÕ ÓÏÏÂÝÅÎÉÑ. uuencode åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÜÔÏ ÎÕÖÎÏ (Ë ÐÒÉÍÅÒÕ, ×Ù ÄÏÂÁ×ÌÑÌÉ, ÕÄÁÌÑÌÉ ÉÌÉ ÐÅÒÅÉÍÅÎÏ×Ù×ÁÌÉ ÆÁÊÌÙ), ÔÏ ÏÂßÅÄÉÎÉÔÅ ×ÁÛÉ ÉÚÍÅÎÅÎÉÑ × tar-ÆÁÊÌ É ÏÂÒÁÂÏÔÁÊÔÅ ÅÇÏ ÐÒÏÇÒÁÍÍÏÊ &man.uuencode.1;. ðÒÉÎÉÍÁÀÔÓÑ ÔÁËÖÅ É ÁÒÈÉ×Ù, ÓÏÚÄÁÎÎÙÅ ÐÒÏÇÒÁÍÍÏÊ &man.shar.1;. åÓÌÉ ×ÁÛÅ ÉÚÍÅÎÅÎÉÅ ÐÏÔÅÎÃÉÁÌØÎÏ ÍÏÖÅÔ ÏËÁÚÁÔØÓÑ ÓÏÍÎÉÔÅÌØÎÙÍ, ÎÁÐÒÉÍÅÒ, ×Ù ÎÅ Õ×ÅÒÅÎÙ × ÏÔÓÕÔÓÔ×ÉÉ ÌÉÃÅÎÚÉÏÎÎÙÈ ÏÇÒÁÎÉÞÅÎÉÊ ÏÔÎÏÓÉÔÅÌØÎÏ ÅÇÏ ÒÁÓÐÒÏÓÔÒÁÎÅÎÉÑ, ÔÏ ×Ù ÄÏÌÖÎÙ ÐÏÓÌÁÔØ ÅÇÏ ÎÁÐÒÑÍÕÀ × ÓÐÉÓÏË ÒÁÓÓÙÌËÉ &a.core;, Á ÎÅ ÞÅÒÅÚ &man.send-pr.1;. ÷ ÓÐÉÓËÅ ÒÁÓÓÙÌËÉ &a.core; ÕÞÁÓÔ×ÕÅÔ ÇÏÒÁÚÄÏ ÍÅÎØÛÅÅ ËÏÌÉÞÅÓÔ×Ï ÌÀÄÅÊ, ËÏÔÏÒÙÅ ×ÙÐÏÌÎÑÀÔ ÏÓÎÏ×ÎÕÀ ÅÖÅÄÎÅ×ÎÕÀ ÒÁÂÏÔÕ ÎÁÄ FreeBSD. úÁÍÅÔØÔÅ, ÞÔÏ ÜÔÁ ÇÒÕÐÐÁ ÔÁËÖÅ ÏÞÅÎØ ÚÁÎÑÔÁ, ÔÁË ÞÔÏ ÓÀÄÁ ÐÉÓØÍÁ ÎÕÖÎÏ ÐÏÓÙÌÁÔØ ÔÏÌØËÏ × ÓÌÕÞÁÅ ÄÅÊÓÔ×ÉÔÅÌØÎÏÊ ÎÅÏÂÈÏÄÉÍÏÓÔÉ. ðÏÖÁÌÕÊÓÔÁ, ÏÂÒÁÔÉÔÅÓØ Ë ÓÐÒÁ×ËÅ ÐÏ &man.intro.9; É &man.style.9; ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÎÅËÏÔÏÒÏÊ ÉÎÆÏÒÍÁÃÉÉ Ï ÓÔÉÌÅ ËÏÄÉÒÏ×ÁÎÉÑ. íÙ ÎÁÄÅÅÍÓÑ, ÞÔÏ ×Ù ÈÏÔÑ ÂÙ ÐÒÉÍÅÔÅ ÜÔÕ ÉÎÆÏÒÍÁÃÉÀ Ë Ó×ÅÄÅÎÉÀ ÐÅÒÅÄ ÔÅÍ, ËÁË ÐÒÉÓÌÁÔØ ÎÁÍ Ó×ÏÊ ËÏÄ. îÏ×ÙÊ ËÏÄ ÉÌÉ ÂÏÌØÛÉÅ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ÐÁËÅÔÙ ÷ ÓÌÕÞÁÅ ÚÎÁÞÉÔÅÌØÎÏÇÏ ÏÂߣÍÁ ÐÒÉÓÌÁÎÎÏÇÏ ×ÁÍÉ ËÏÄÁ É ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÊ ÒÁÂÏÔÙ, ÌÉÂÏ ÄÏÂÁ×ÌÅÎÉÑ Ë FreeBSD ×ÁÖÎÏÊ ÎÏ×ÏÊ ÆÕÎËÃÉÉ, ÓÔÁÎÏ×ÉÔÓÑ ÐÒÁËÔÉÞÅÓËÉ ×ÓÅÇÄÁ ÎÅÏÂÈÏÄÉÍÏ ÐÏÓÙÌÁÔØ ÉÚÍÅÎÅÎÉÑ × ×ÉÄÅ tar-ÆÁÊÌÏ×, ÏÂÒÁÂÏÔÁÎÎÙÈ uuencode, ÉÌÉ ÐÅÒÅÄÁ×ÁÔØ ÉÈ ÎÁ Web-ÓÁÊÔ ÉÌÉ FTP-ÓÅÒ×ÅÒ ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÄÒÕÇÉÍÉ ÌÀÄØÍÉ. åÓÌÉ Õ ×ÁÓ ÎÅÔ ÄÏÓÔÕÐÁ Ë Web- ÉÌÉ FTP-ÓÅÒ×ÅÒÁÍ, ÐÏÐÒÏÓÉÔÅ × ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÍ ÓÐÉÓËÅ ÒÁÓÓÙÌËÅ FreeBSD ËÏÇÏ-ÎÉÂÕÄØ ÒÁÚÍÅÓÔÉÔØ ÉÚÍÅÎÅÎÉÑ ÚÁ ×ÁÓ. ðÒÉ ÒÁÂÏÔÅ Ó ÂÏÌØÛÉÍ ÏÂߣÍÏÍ ËÏÄÁ ÎÅÉÚÂÅÖÎÏ ×ÏÚÎÉËÁÅÔ ×ÏÐÒÏÓ Ï ÓÏÂÌÀÄÅÎÉÉ Á×ÔÏÒÓËÉÈ ÐÒÁ×. äÏÐÕÓÔÉÍÙÍÉ ÌÉÃÅÎÚÉÏÎÎÙÍÉ ÓÏÇÌÁÛÅÎÉÑÍÉ ÄÌÑ ËÏÄÁ, ×ËÌÀÞÁÅÍÏÇÏ ×Ï FreeBSD, Ñ×ÌÑÀÔÓÑ ÓÌÅÄÕÀÝÉÅ: - ÌÉÃÅÎÚÉÏÎÎÏÅ ÓÏÇÌÁÛÅÎÉÅ BSD - - ìÉÃÅÎÚÉÏÎÎÏÅ ÓÏÇÌÁÛÅÎÉÅ BSD. ïÎÏ Ñ×ÌÑÅÔÓÑ ÓÁÍÙÍ + ìÉÃÅÎÚÉÏÎÎÏÅ ÓÏÇÌÁÛÅÎÉÅ BSDÌÉÃÅÎÚÉÏÎÎÏÅ + ÓÏÇÌÁÛÅÎÉÅ BSD. ïÎÏ Ñ×ÌÑÅÔÓÑ ÓÁÍÙÍ ÐÒÅÄÐÏÞÔÉÔÅÌØÎÙÍ ÉÚ-ÚÁ ÏÔÓÕÔÓÔ×ÉÑ ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÕÓÌÏ×ÉÊ É ÏÂÝÅÊ ÐÒÉ×ÌÅËÁÔÅÌØÎÏÓÔÉ ÄÌÑ ËÏÍÍÅÒÞÅÓËÉÈ ËÏÍÐÁÎÉÊ. ðÒÏÅËÔ FreeBSD ÄÁÌ£Ë ÏÔ ÔÏÇÏ, ÞÔÏÂÙ ×ÙÓÔÕÐÁÔØ ÐÒÏÔÉ× ËÏÍÍÅÒÞÅÓËÏÇÏ ÉÓÐÏÌØÚÏ×ÁÎÉÑ, ÎÏ ÁËÔÉ×ÎÏ ÐÏÐÕÌÑÒÉÚÉÒÕÅÔ ÔÁËÏÅ ÐÅÒÅÓÅÞÅÎÉÅ ËÏÍÍÅÒÞÅÓËÉÈ ÉÎÔÅÒÅÓÏ×, ËÏÔÏÒÏÅ ÐÏÚ×ÏÌÉÔ ÐÏÓÔÅÐÅÎÎÏ ÚÁÐÕÓÔÉÔØ ÍÅÈÁÎÉÚÍ ÉÎ×ÅÓÔÉÃÉÊ ×Ï FreeBSD. + GPL GNU General Public License GNU General Public License - GNU General Public License, ÉÌÉ GPL. üÔÏ + GNU General Public License, ÉÌÉ GPL. üÔÏ ÌÉÃÅÎÚÉÏÎÎÏÅ ÓÏÇÌÁÛÅÎÉÅ ÎÅ ÏÞÅÎØ ÐÏÐÕÌÑÒÎÏ Õ ÎÁÓ ÉÚ-ÚÁ ÏÂߣÍÁ ÔÒÅÂÏ×ÁÎÉÊ, ËÏÔÏÒÙÅ ÎÕÖÎÏ ×ÙÐÏÌÎÑÔØ ×ÓÅÍ, ËÔÏ ÓÏÂÉÒÁÅÔÓÑ ÉÓÐÏÌØÚÏ×ÁÔØ ËÏÄ × ËÏÍÍÅÒÞÅÓËÉÈ ÃÅÌÑÈ. ïÄÎÁËÏ, ÕÞÉÔÙ×ÁÑ ÁÂÓÏÌÀÔÎÏÅ ÐÒÅ×ÏÓÈÏÄÓÔ×Ï ÏÂߣÍÁ ÜÔÏÇÏ ËÏÄÁ (ËÏÍÐÉÌÑÔÏÒ, ÁÓÓÅÍÂÌÅÒ, ÉÎÓÔÒÕÍÅÎÔÙ ÆÏÒÍÁÔÉÒÏ×ÁÎÉÑ ÔÅËÓÔÁ É ÔÁË ÄÁÌÅÅ) ÂÙÌÏ ÂÙ ÇÌÕÐÏ ÏÔËÁÚÙ×ÁÔØÓÑ ÏÔ ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÒÁÚÒÁÂÏÔÏË, ÐÏÄÐÁÄÁÀÝÉÈ ÐÏÄ ÄÅÊÓÔ×ÉÅ ÜÔÏÊ ÌÉÃÅÎÚÉÉ. ëÏÄ, ÒÁÓÐÒÏÓÔÒÁÎÑÅÍÙÊ ÐÏ ÕÓÌÏ×ÉÑÍ ÌÉÃÅÎÚÉÏÎÎÏÇÏ ÓÏÇÌÁÛÅÎÉÑ GPL ÔÁËÖÅ ÒÁÚÍÅÝÁÅÔÓÑ × ÏÔÄÅÌØÎÏÊ ÞÁÓÔÉ ÄÅÒÅ×Á ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ×, × /sys/gnu ÉÌÉ /usr/src/gnu, É ÐÏÜÔÏÍÕ ÌÅÇËÏ ÉÄÅÎÔÉÆÉÃÉÒÕÅÔÓÑ ×ÓÑËÉÍ, ÄÌÑ ËÏÇÏ GPL ÐÒÅÄÓÔÁ×ÌÑÅÔ ÐÒÏÂÌÅÍÕ. òÁÚÒÁÂÏÔËÉ, ÐÏÄÐÁÄÁÀÝÉÅ ÐÏÄ ÄÅÊÓÔ×ÉÅ ÄÒÕÇÉÈ ÔÉÐÏ× ÌÉÃÅÎÚÉÏÎÎÙÈ ÓÏÇÌÁÛÅÎÉÊ, ÄÏÌÖÎÙ ÂÙÔØ ÔÝÁÔÅÌØÎÏ ÐÒÏÓÍÏÔÒÅÎÙ ÐÅÒÅÄ ÐÒÉÎÑÔÉÅÍ ÒÅÛÅÎÉÑ Ï ÉÈ ×ËÌÀÞÅÎÉÉ ×Ï FreeBSD. òÁÚÒÁÂÏÔËÉ, ÎÁ ËÏÔÏÒÙÅ ÒÁÓÐÒÏÓÔÒÁÎÑÀÔÓÑ Ö£ÓÔËÉÅ ÏÇÒÁÎÉÞÅÎÉÑ ËÏÍÍÅÒÞÅÓËÉÈ ÌÉÃÅÎÚÉÏÎÎÙÈ ÓÏÇÌÁÛÅÎÉÊ, ÏÂÙÞÎÏ ÏÔ×ÅÒÇÁÀÔÓÑ, Á Á×ÔÏÒÁÍ ×ÓÅÇÄÁ ÐÒÅÄÌÁÇÁÅÔÓÑ ÒÁÓÐÒÏÓÔÒÁÎÑÔØ ÐÏÄÏÂÎÙÅ ÉÚÍÅÎÅÎÉÑ ÐÏ ÓÏÂÓÔ×ÅÎÎÙÍ ËÁÎÁÌÁÍ. äÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÎÁ ×ÁÛÕ ÒÁÂÏÔÕ ÒÁÓÐÒÏÓÔÒÁÎÑÌÉÓØ ÕÓÌÏ×ÉÑ ÌÉÃÅÎÚÉÏÎÎÏÇÏ ÏÇÒÁÎÉÞÅÎÉÑ × ÓÔÉÌÅ BSD, ÒÁÚÍÅÓÔÉÔÅ ÓÌÅÄÕÀÝÉÊ ÔÅËÓÔ × ÓÁÍÏÍ ÎÁÞÁÌÅ ËÁÖÄÏÇÏ ÆÁÊÌÁ Ó ÉÓÈÏÄÎÙÍÉ ÔÅËÓÔÁÍÉ, ËÏÔÏÒÙÅ ×Ù ÈÏÔÉÔÅ ÚÁÝÉÔÉÔØ, ÚÁÍÅÎÉ× ÔÅËÓÔ ÍÅÖÄÕ %% ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÊ ÉÎÆÏÒÍÁÃÉÅÊ: Copyright (c) %%ÐÏÌÎÙÅ_ÎÏÍÅÒÁ_ÇÏÄÏ×%% %%×ÁÛÅ_ÉÍÑ%%, %%×ÁÛ_ÛÔÁÔ%% %%×ÁÛ_ÐÏÞÔÏ×ÙÊ_ÉÎÄÅËÓ%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $&os;$ äÌÑ ×ÁÛÅÇÏ ÕÄÏÂÓÔ×Á ËÏÐÉÑ ÜÔÏÇÏ ÔÅËÓÔÁ ÒÁÚÍÅÝÅÎÁ × ÆÁÊÌÅ /usr/share/examples/etc/bsd-style-copyright. äÅÎØÇÉ, ÏÂÏÒÕÄÏ×ÁÎÉÅ ÉÌÉ Internet-ÄÏÓÔÕÐ íÙ ×ÓÅÇÄÁ Ó ÕÄÏ×ÏÌØÓÔ×ÉÅÍ ÐÒÉÍÅÍ ÍÁÔÅÒÉÁÌØÎÕÀ ÐÏÍÏÝØ, ÎÕÖÎÕÀ ÄÌÑ ÄÁÌØÎÅÊÛÅÇÏ ÓÕÝÅÓÔ×Ï×ÁÎÉÑ ðÒÏÅËÔÁ FreeBSD, Á × ÄÏÂÒÏ×ÏÌØÎÏÍ ÐÒÏÅËÔÅ, ÔÉÐÁ ÎÁÛÅÇÏ ÍÁÌÅÎØËÁÑ ÐÏÍÏÝØ ÍÏÖÅÔ ÐÏÓÌÕÖÉÔØ ÄÏÌÇÏ! âÅÚ×ÏÚÍÅÚÄÎÁÑ ÐÅÒÅÄÁÞÁ ×ÙÞÉÓÌÉÔÅÌØÎÏÊ ÔÅÈÎÉËÉ ÔÁËÖÅ ÏÞÅÎØ ×ÁÖÎÁ ÄÌÑ ÒÁÓÛÉÒÅÎÉÑ ÓÐÉÓËÁ ÐÏÄÄÅÒÖÉ×ÁÅÍÏÇÏ ÐÅÒÉÆÅÒÉÊÎÏÇÏ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ÔÁË ËÁË ÏÂÙÞÎÏ Õ ÎÁÓ ÎÅÔ ÓÒÅÄÓÔ× ÄÌÑ ÓÁÍÏÓÔÏÑÔÅÌØÎÏÇÏ ÅÇÏ ÐÒÉÏÂÒÅÔÅÎÉÑ. æÉÎÁÎÓÏ×ÁÑ ÐÏÍÏÝØ The FreeBSD Foundation Ñ×ÌÑÅÔÓÑ ÎÅËÏÍÍÅÒÞÅÓËÏÊ ÏÒÇÁÎÉÚÁÃÉÅÊ, ÏÓ×ÏÂÏÖÄ£ÎÎÏÊ ÏÔ ÕÐÌÁÔÙ ÎÁÌÏÇÏ×, ÓÏÚÄÁÎÎÏÊ Ó ÃÅÌØÀ ÒÅÁÌÉÚÁÃÉÉ ÃÅÌÅÊ ðÒÏÅËÔÁ FreeBSD. ëÁË ÏÒÇÁÎÉÚÁÃÉÑ ÔÉÐÁ 501(c)3, æÏÎÄ ÏÂÙÞÎÏ ÏÓ×ÏÂÏÖÄÁÅÔÓÑ ÏÔ ÆÅÄÅÒÁÌØÎÏÇÏ ÎÁÌÏÇÁ óûá ÎÁ ÐÒÉÂÙÌØ. óÕÍÍÙ ÂÅÚ×ÏÚÍÅÚÄÎÙÈ ÐÏÖÅÒÔ×Ï×ÁÎÉÊ ÔÁËÉÍ ÏÒÇÁÎÉÚÁÃÉÑÍ ÞÁÓÔÏ ×ÙÞÉÔÁÀÔÓÑ ÉÚ ÏÂÝÅÊ ÓÕÍÍÙ ÎÁÌÏÇÏÏÂÌÁÇÁÅÍÏÊ ÐÒÉÂÙÌÉ. æÉÎÁÎÓÏ×ÁÑ ÐÏÍÏÝØ ÍÏÖÅÔ ÂÙÔØ ÎÁÐÒÁ×ÌÅÎÁ × ×ÉÄÅ ÞÅËÏ× ÎÁ ÁÄÒÅÓ:
The FreeBSD Foundation P.O. Box 20247 Boulder, CO 80308 USA
The FreeBSD Foundation ÔÅÐÅÒØ ÍÏÖÅÔ ÐÒÉÎÉÍÁÔØ ÐÏÍÏÝØ ÞÅÒÅÚ Web ÐÏ ÓÉÓÔÅÍÅ PayPal. äÌÑ ÎÁÐÒÁ×ÌÅÎÉÑ ÐÏÍÏÝÉ, ÐÏÖÁÌÕÊÓÔÁ, ÐÏÓÅÔÉÔÅ Web-ÓÁÊÔ æÏÎÄÁ. äÏÐÏÌÎÉÔÅÌØÎÕÀ ÉÎÆÏÒÍÁÃÉÀ Ï æÏÎÄÅ FreeBSD ÍÏÖÎÏ ÎÁÊÔÉ ÎÁ ÓÔÒÁÎÉÃÅ, ÓÏÄÅÒÖÁÝÅÊ ××ÏÄÎÕÀ ÉÎÆÏÒÍÁÃÉÉ Ï æÏÎÄÅ FreeBSD. äÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÏÂÒÁÔÉÔØÓÑ × æÏÎÄ ÐÏ ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÅ, ÎÁÐÉÛÉÔÅ ÐÉÓØÍÏ ÎÁ ÁÄÒÅÓ bod@FreeBSDFoundation.org.
ðÏÍÏÝØ × ×ÉÄÅ ÏÂÏÒÕÄÏ×ÁÎÉÑ ÂÅÚ×ÏÚÍÅÚÄÎÁÑ ÐÏÍÏÝØ ðÒÏÅËÔ FreeBSD Ó ÕÄÏ×ÏÌØÓÔ×ÉÅ ÐÒÉÍÅÔ ÐÏÍÏÝØ × ×ÉÄÅ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ËÏÔÏÒÏÍÕ ÏÎ ÎÁÊÄ£Ô ÈÏÒÏÛÅÅ ÐÒÉÍÅÎÅÎÉÅ. åÓÌÉ ×Ù ÚÁÉÎÔÅÒÅÓÏ×ÁÎÙ × ÐÅÒÅÄÁÞÅ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ÐÏÖÁÌÕÊÓÔÁ, ÏÂÒÁÔÉÔÅÓØ Ë òÕËÏ×ÏÄÓÔ×Õ ãÅÎÔÒÁ ÐÏÖÅÒÔ×Ï×ÁÎÉÊ.
diff --git a/ru_RU.KOI8-R/articles/cvs-freebsd/article.xml b/ru_RU.KOI8-R/articles/cvs-freebsd/article.xml index 5667839049..12098a40de 100644 --- a/ru_RU.KOI8-R/articles/cvs-freebsd/article.xml +++ b/ru_RU.KOI8-R/articles/cvs-freebsd/article.xml @@ -1,736 +1,736 @@
îÁÓÔÒÏÊËÁ ÈÒÁÎÉÌÉÝÁ CVS - ÐÏÄÈÏÄ FreeBSD Stijn Hoop
stijn@win.tue.nl
2001 2002 2003 Stijn Hoop $FreeBSD$ $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; ÷ ÜÔÏÊ ÓÔÁÔØÅ ÏÐÉÓÁÎÙ ÛÁÇÉ, ËÏÔÏÒÙÅ Ñ ÐÒÅÄÐÒÉÎÑÌ ÄÌÑ ÎÁÓÔÒÏÊËÉ ÈÒÁÎÉÌÉÝÁ CVS, ÉÓÐÏÌØÚÕÀÝÅÇÏ ÔÅ ÖÅ ÓÁÍÙÅ ÓËÒÉÐÔÙ, ÞÔÏ ÉÓÐÏÌØÚÕÀÔÓÑ × ÐÒÏÅËÔÅ FreeBSD × ÉÈ ÎÁÓÔÒÏÊËÅ. üÔÏ ÉÍÅÅÔ ÎÅËÏÔÏÒÙÅ ÐÒÅÉÍÕÝÅÓÔ×Á ÐÅÒÅÄ ÓÔÁÎÄÁÒÔÎÏÊ ÎÁÓÔÒÏÊËÏÊ CVS, × ÔÏÍ ÞÉÓÌÅ ÂÏÌÅÅ ÔÏÞÎÙÊ ËÏÎÔÒÏÌØ ÄÏÓÔÕÐÁ Ë ÄÅÒÅ×Õ ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ× É ÐÏÓÙÌËÕ ÓÏÄÅÒÖÁÔÅÌØÎÙÈ ÓÏÏÂÝÅÎÉÊ ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÙ ÐÒÉ ËÁÖÄÏÍ ËÏÍÍÉÔÅ.
÷×ÅÄÅÎÉÅ âÏÌØÛÉÎÓÔ×Ï ÐÒÏÇÒÁÍÍÎÙÈ ÐÒÏÅËÔÏ× Ó ÏÔËÒÙÔÙÍ ËÏÄÏÍ ÉÓÐÏÌØÚÕÀÔ CVS × ËÁÞÅÓÔ×Å ÓÉÓÔÅÍÙ ÕÐÒÁ×ÌÅÎÉÑ ÉÓÈÏÄÎÙÍ ËÏÄÏÍ. èÏÔÑ CVS ×ÅÓØÍÁ ÈÏÒÏÛÁ × ÜÔÏÍ ËÁÞÅÓÔ×Å, Õ ÎÅ£ ÅÓÔØ Ó×ÏÉ ÎÅÕÄÏÂÓÔ×Á É ÎÅÄÏÓÔÁÔËÉ. ïÄÎÉÍ ÉÚ ÎÉÈ Ñ×ÌÑÅÔÓÑ ÔÏ, ÞÔÏ ÓÏ×ÍÅÓÔÎÏÅ ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÄÅÒÅ×Á ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ× Ó ÄÒÕÇÉÍÉ ÒÁÚÒÁÂÏÔÞÉËÁÍÉ ÍÏÖÅÔ ÂÙÓÔÒÏ ÐÒÉ×ÅÓÔÉ Ë ËÏÛÍÁÒÎÙÍ ÐÒÏÂÌÅÍÁÍ ÐÒÉ ÁÄÍÉÎÉÓÔÒÉÒÏ×ÁÎÉÉ, ÏÓÏÂÅÎÎÏ ÅÓÌÉ ËÔÏ-ÔÏ ÚÁÈÏÞÅÔ ÚÁÝÉÔÉÔØ ÞÁÓÔÉ ÄÅÒÅ×Á ÏÔ ÏÂÝÅÄÏÓÔÕÐÎÏÓÔÉ. FreeBSD Ñ×ÌÑÅÔÓÑ ÏÄÎÉÍ ÉÚ ÐÒÏÅËÔÏ×, ÉÓÐÏÌØÚÕÀÝÉÍ CVS. úÄÅÓØ ÔÁËÖÅ ÉÍÅÅÔ ÂÏÌØÛÏÅ ËÏÌÉÞÅÓÔ×Ï ÒÁÚÒÁÂÏÔÞÉËÏ×, ÒÁÚÂÒÏÓÁÎÎÙÈ ÐÏ ×ÓÅÍÕ ÍÉÒÕ. ïÎÉ ÒÁÚÒÁÂÏÔÁÌÉ ÎÅËÏÔÏÒÙÅ - ÓËÒÉÐÔÙ, ÏÂÌÅÇÞÁÀÝÉÅ ÕÐÒÁ×ÌÅÎÉÅ ÈÒÁÎÉÌÉÝÅÍ. îÅÄÁ×ÎÏ ÜÔÉ ÓËÒÉÐÔÙ ÂÙÌÉ - ÐÅÒÅÓÍÏÔÒÅÎÙ É ÐÒÉ×ÅÄÅÎÙ × ÐÏÒÑÄÏË äÖÏÚÅÆÏÍ ëÁÒÔÁÕÚÅÒÏÍ (Joseph - Karthauser), × ÃÅÌÑÈ ÏÂÌÅÇÞÅÎÉÑ ÉÈ ÉÓÐÏÌØÚÏ×ÁÎÉÑ × ÄÒÕÇÉÈ ÐÒÏÅËÔÁÈ. ÷ ÜÔÏÊ + ÓËÒÉÐÔÙ, ÏÂÌÅÇÞÁÀÝÉÅ ÕÐÒÁ×ÌÅÎÉÅ ÈÒÁÎÉÌÉÝÅÍ. îÅÄÁ×ÎÏ &a.joe.email; + ÐÅÒÅÓÍÏÔÒÅÌ É ÐÒÉ×ÅÌ × ÐÏÒÑÄÏË ÜÔÉ ÓËÒÉÐÔÙ + × ÃÅÌÑÈ ÏÂÌÅÇÞÅÎÉÑ ÉÈ ÉÓÐÏÌØÚÏ×ÁÎÉÑ × ÄÒÕÇÉÈ ÐÒÏÅËÔÁÈ. ÷ ÜÔÏÊ ÓÔÁÔØÅ ÏÐÉÓÁÎ ÏÄÉÎ ÉÚ ÍÅÔÏÄÏ× ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÎÏ×ÙÈ ÓËÒÉÐÔÏ×. þÔÏÂÙ ÉÚ×ÌÅÞØ ÍÁËÓÉÍÕÍ ÉÎÆÏÒÍÁÃÉÉ ÉÚ ÜÔÏÊ ÓÔÁÔØÉ, ×Ù ÄÏÌÖÎÙ ×ÌÁÄÅÔØ ÏÓÎÏ×ÎÙÍÉ ÍÅÔÏÄÁÍÉ ÒÁÂÏÔÙ Ó CVS. ðÅÒ×ÏÎÁÞÁÌØÎÁÑ ÎÁÓÔÒÏÊËÁ îÁ×ÅÒÎÏÅ, ÌÕÞÛÅ ÓÎÁÞÁÌÁ ×ÙÐÏÌÎÉÔØ ÜÔÕ ÐÒÏÃÅÄÕÒÕ Ó ÐÕÓÔÙÍ ÔÅÓÔÏ×ÙÍ ÈÒÁÎÉÌÉÝÅÍ, ÞÔÏÂÙ ÐÏÎÑÔØ ×ÓÅ ÐÏÓÌÅÄÓÔ×ÉÑ ×ÁÛÉÈ ÄÅÊÓÔ×ÉÊ. ëÁË ÏÂÙÞÎÏ × ÔÁËÉÈ ÓÌÕÞÁÑÈ, Õ ×ÁÓ ÄÏÌÖÎÙ ÉÍÅÔØÓÑ Ó×ÅÖÉÅ ÞÉÔÁÅÍÙÅ ÒÅÚÅÒ×ÎÙÅ ËÏÐÉÉ! éÎÉÃÉÁÌÉÚÁÃÉÑ ÈÒÁÎÉÌÉÝÁ ðÅÒ×ÙÍ ÄÅÌÏÍ ÐÒÉ ÎÁÓÔÒÏÊËÅ ÎÏ×ÏÇÏ ÈÒÁÎÉÌÉÝÁ ÎÅÏÂÈÏÄÉÍÏ ÅÇÏ ÉÎÉÃÉÁÌÉÚÉÒÏ×ÁÔØ, ÄÌÑ ÞÅÇÏ ×ÙÄÁÔØ CVS ÔÁËÕÀ ËÏÍÁÎÄÕ: &prompt.user; cvs -d path-to-repository init òÅÚÕÌØÔÁÔÏÍ ÅÅ ×ÙÐÏÌÎÅÎÉÑ ÂÕÄÅÔ ÓÏÚÄÁÎÎÙÊ CVS ÓÌÕÖÅÂÎÙÊ ËÁÔÁÌÏÇ CVSROOT, × ËÏÔÏÒÏÍ ×ÙÐÏÌÎÑÅÔÓÑ ×ÓÑ ÎÁÓÔÒÏÊËÁ. çÒÕÐÐÁ ÐÏÌØÚÏ×ÁÔÅÌÅÊ ÈÒÁÎÉÌÉÝÁ ôÅÐÅÒØ ÍÙ ÓÏÚÄÁÄÉÍ ÇÒÕÐÐÕ, ËÏÔÏÒÁÑ ÂÕÄÅÔ ×ÌÁÄÅÔØ ÈÒÁÎÉÌÉÝÅÍ. ÷ ÜÔÏÊ ÇÒÕÐÐÅ ÄÏÌÖÎÙ ÐÒÉÓÕÔÓÔ×Ï×ÁÔØ ×ÓÅ ËÏÍÍÉÔÔÅÒÙ, ÄÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÏÎÉ ÍÏÇÌÉ ÐÉÓÁÔØ × ÈÒÁÎÉÌÉÝÅ. äÌÑ ÜÔÏÊ ÇÒÕÐÐÙ ÍÙ ÐÒÉÍÅÍ ÓÔÁÎÄÁÒÔÎÏÅ ÄÌÑ FreeBSD ÎÁÚ×ÁÎÉÅ ncvs. &prompt.root; pw groupadd ncvs úÁÔÅÍ ×Ù ÄÏÌÖÎÙ ÐÒÉ ÐÏÍÏÝÉ ËÏÍÁÎÄÙ &man.chown.8; ÓÍÅÎÉÔØ ×ÌÁÄÅÌØÃÁ É ÇÒÕÐÐÕ ÄÌÑ ÔÏÌØËÏ ÞÔÏ ÄÏÂÁ×ÌÅÎÎÏÇÏ ËÁÔÁÌÏÇÁ: &prompt.root; chown -R :ncvs path-to-your-repository üÔÏ ÎÕÖÎÏ ÄÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÎÉËÔÏ ÎÅ ÍÏÇ ÚÁÐÉÓÙ×ÁÔØ × ÈÒÁÎÉÌÉÝÅ, ÎÅ Ñ×ÌÑÑÓØ ÞÌÅÎÏÍ ÇÒÕÐÐÙ. ðÏÌÕÞÅÎÉÅ ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ× ôÅÐÅÒØ ×ÁÍ ÎÕÖÎÏ ÐÏÌÕÞÉÔØ ËÁÔÁÌÏÇ CVSROOT ÉÚ ÈÒÁÎÉÌÉÝÁ FreeBSD. ðÒÏÝÅ ×ÓÅÇÏ ÜÔÏ ÄÅÌÁÅÔÓÑ ÉÚ×ÌÅÞÅÎÉÅÍ Ó ÁÎÏÎÉÍÎÏÇÏ ÚÅÒËÁÌÁ CVS FreeBSD. ïÂÒÁÔÉÔÅÓØ Ë ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÊ ÇÌÁ×Å òÕËÏ×ÏÄÓÔ×Á ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÄÏÐÏÌÎÉÔÅÌØÎÏÊ ÉÎÆÏÒÍÁÃÉÉ. íÙ ÂÕÄÅÍ ÐÏÌÁÇÁÔØ, ÞÔÏ ÉÓÈÏÄÎÙÅ ÔÅËÓÔÙ ÈÒÁÎÑÔÓÑ × ÐÏÄËÁÔÁÌÏÇÅ CVSROOT-freebsd ÔÅËÕÝÅÇÏ ËÁÔÁÌÏÇÁ. ëÏÐÉÒÏ×ÁÎÉÅ ÓËÒÉÐÔÏ× FreeBSD ôÅÐÅÒØ ÍÙ ÓËÏÐÉÒÕÅÍ ÉÓÈÏÄÎÙÅ ÔÅËÓÔÙ FreeBSD ÉÚ CVSROOT × ÎÁÛÅ ÈÒÁÎÉÌÉÝÅ. åÓÌÉ ×Ù ÚÎÁËÏÍÙ Ó CVS, ÔÏ ÄÌÑ ×ÁÓ ÍÏÖÅÔ ÉÍÅÔØ ÓÍÙÓÌ ÐÏÐÙÔÁÔØÓÑ ÉÍÐÏÒÔÉÒÏ×ÁÔØ ÓËÒÉÐÔÙ, ÞÔÏÂÙ ÏÂÌÅÇÞÉÔØ ÓÉÎÈÒÏÎÉÚÁÃÉÀ Ó ÐÏÓÌÅÄÕÀÝÉÍÉ ×ÅÒÓÉÑÍÉ. ïÄÎÁËÏ ÐÒÉ ÜÔÏÍ ÏËÁÚÙ×ÁÅÔÓÑ, ÞÔÏ CVS ÉÍÅÅÔ × ÜÔÏÊ ÏÂÌÁÓÔÉ ÎÅÄÏÓÔÁÔÏË: ÐÒÉ ÉÍÐÏÒÔÉÒÏ×ÁÎÉÉ ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ× × ËÁÔÁÌÏÇ CVSROOT ÏÎÁ ÎÅ ÂÕÄÅÔ ÏÂÎÏ×ÌÑÔØ ÎÅÏÂÈÏÄÉÍÙÅ ÁÄÍÉÎÉÓÔÒÁÔÉ×ÎÙÅ ÆÁÊÌÙ. þÔÏÂÙ × ÜÔÏÍ ÕÂÅÄÉÔØÓÑ, ×ÁÍ ÎÕÖÎÏ ÐÒÏ×ÅÒÉÔØ ËÁÖÄÙÊ ÆÁÊÌ ÐÏÓÌÅ ÉÍÐÏÒÔÉÒÏ×ÁÎÉÑ, ÐÒÉ ÜÔÏÍ ÓÍÙÓÌ cvs import ÔÅÒÑÅÔÓÑ. ðÏÜÔÏÍÕ ÒÅËÏÍÅÎÄÕÅÍÙÍ ÍÅÔÏÄÏÍ Ñ×ÌÑÅÔÓÑ ÐÒÏÓÔÏÅ ËÏÐÉÒÏ×ÁÎÉÅ ÓËÒÉÐÔÏ×. îÅ ÉÍÅÅÔ ÚÎÁÞÅÎÉÑ, ËÁË ×Ù ÏÔÎÏÓÉÔÅÓØ Ë ÐÒÅÄÙÄÕÝÅÍÕ ÐÁÒÁÇÒÁÆÕ—ÒÅÚÕÌØÔÁÔ ÏÄÉÎ É ÔÏÔ ÖÅ. ðÒÏÓÔÏ ÐÏÍÅÓÔÉÔÅ ×ÁÛ CVSROOT É ÓËÏÐÉÒÕÊÔÅ ÆÁÊÌÙ FreeBSD ÐÏ×ÅÒÈ ×ÁÛÉÈ ÌÏËÁÌØÎÙÈ (ÎÅÉÚÍÅÎÅÎÎÙÈ) ËÏÐÉÊ: &prompt.user; cvs -d path-to-your-repository checkout CVSROOT &prompt.user; cd CVSROOT &prompt.user; cp ../CVSROOT-freebsd/* . &prompt.user; cvs add * úÁÍÅÔÉÍ, ÞÔÏ ×Ù, ÓËÏÒÅÅ ×ÓÅÇÏ, ÐÏÌÕÞÉÔÅ ÎÅÓËÏÌØËÏ ÐÒÅÄÕÐÒÅÖÄÅÎÉÊ Ï ÔÏÍ, ÞÔÏ ÎÅËÏÔÏÒÙÅ ËÁÔÁÌÏÇÉ ÎÅ ÂÙÌÉ ÓËÏÐÉÒÏ×ÁÎÙ; ÜÔÏ ÎÏÒÍÁÌØÎÏ, ×ÁÍ ÏÎÉ ÎÅ ÎÕÖÎÙ. óËÒÉÐÔÙ ôÅÐÅÒØ Õ ×ÁÓ ÅÓÔØ ÒÁÂÏÞÉÊ ËÁÔÁÌÏÇ É ÔÏÞÎÁÑ ËÏÐÉÑ ÓËÒÉÐÔÏ×, ËÏÔÏÒÙÅ ÉÓÐÏÌØÚÕÀÔÓÑ × ÐÒÏÅËÔÅ FreeBSD ÄÌÑ ÒÁÂÏÔÙ Ó ÈÒÁÎÉÌÉÝÅÍ. äÁÌÅÅ ÓÌÅÄÕÅÔ ËÒÁÔËÏÅ ÏÐÉÓÁÎÉÅ ÎÁÚÎÁÞÅÎÉÑ ËÁÖÄÏÇÏ ÆÁÊÌÁ. access - ÐÏ ÕÍÏÌÞÁÎÉÀ ÐÒÉ ÓÔÁÎÄÁÒÔÎÏÊ ÎÁÓÔÒÏÊËÅ ÜÔÏÔ ÆÁÊÌ ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ. ïÎ ÐÒÉÍÅÎÑÅÔÓÑ × ÓÐÅÃÉÆÉÞÎÙÈ ÄÌÑ ÐÒÏÅËÔÁ FreeBSD ÎÁÓÔÒÏÊËÁÈ, ÇÄÅ ÏÎ ÕÐÒÁ×ÌÑÅÔ ÄÏÓÔÕÐÏÍ Ë ÈÒÁÎÉÌÉÝÕ. ÷Ù ÍÏÖÅÔÅ ÕÄÁÌÉÔØ ÜÔÏÔ ÆÁÊÌ, ÅÓÌÉ ×Ù ÎÅ ÓÏÂÉÒÁÅÔÅÓØ ÉÓÐÏÌØÚÏ×ÁÔØ ÔÁËÕÀ ÎÁÓÔÒÏÊËÕ. avail - ÜÔÏÔ ÆÁÊÌ ÕÐÒÁ×ÌÑÅÔ ÄÏÓÔÕÐÏÍ Ë ÈÒÁÎÉÌÉÝÕ. ÷ ÎÅÍ ×Ù ÍÏÖÅÔÅ ÕËÁÚÁÔØ ÇÒÕÐÐÙ ÌÀÄÅÊ, ËÏÔÏÒÙÍ ÒÁÚÒÅÛÅÎ ÄÏÓÔÕÐ Ë ÈÒÁÎÉÌÉÝÕ, Á ÔÁËÖÅ ÚÁÐÒÅÔÉÔØ ËÏÍÍÉÔÙ ÎÁ ÕÒÏ×ÎÅ ËÁÔÁÌÏÇÏ×. ÷Ù ÄÏÌÖÎÙ ÐÏÄÎÁÓÔÒÏÉÔØ ÅÇÏ ÔÁË, ÞÔÏÂÙ ÏÎ ÓÏÄÅÒÖÁÌ ÇÒÕÐÐÙ É ËÁÔÁÌÏÇÉ, ÉÍÅÀÝÉÅÓÑ × ×ÁÛÅÍ ÈÒÁÎÉÌÉÝÅ. cfg.pm - ÜÔÏÔ ÆÁÊÌ ÁÎÁÌÉÚÉÒÕÅÔ ×ÁÛÕ ËÏÎÆÉÇÕÒÁÃÉÀ É ÓÏÄÅÒÖÉÔ ÎÁÓÔÒÏÊËÉ ÐÏ ÕÍÏÌÞÁÎÉÀ. ÷Ù ÎÅ ÄÏÌÖÎÙ ÉÚÍÅÎÑÔØ ÜÔÏÔ ÆÁÊÌ. ÷ÍÅÓÔÏ ÜÔÏÇÏ ÒÁÚÍÅÝÁÊÔÅ ×ÁÛÉ ÉÚÍÅÎÅÎÉÑ × ËÏÎÆÉÇÕÒÁÃÉÉ × ÆÁÊÌÅ cfg_local.pm. cfg_local.pm - ÜÔÏÔ ÆÁÊÌ ÓÏÄÅÒÖÉÔ ×ÓÅ ÎÁÓÔÒÁÉ×ÁÅÍÙÅ ÐÁÒÁÍÅÔÒÙ ÓÉÓÔÅÍÙ. ÷Ù ÄÏÌÖÎÙ ÎÁÓÔÒÁÉ×ÁÔØ ×ÓÅ ÐÁÒÁÍÅÔÒÙ ÚÄÅÓØ, ÎÁÐÒÉÍÅÒ, ËÕÄÁ ÐÏÓÙÌÁÅÔÓÑ ÐÏÞÔÁ ÐÒÉ ËÏÍÍÉÔÅ, Ó ËÁËÉÈ ÈÏÓÔÏ× ÍÏÖÎÏ ×ÙÐÏÌÎÑÔØ ËÏÍÍÉÔÙ, É ÐÒÏÞÅÅ. îÉÖÅ ÄÁÅÔÓÑ ÂÏÌÅÅ ÐÏÌÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÜÔÏÍ. checkoutlist - ÜÔÉ ÆÁÊÌÙ ÐÅÒÅÞÉÓÌÑÀÔ ×ÓÅ ÆÁÊÌÙ, ÕÐÒÁ×ÌÑÅÍÙÅ CVS × ÜÔÏÍ ËÁÔÁÌÏÇÅ. ÷Ù ÄÏÌÖÎÙ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÅÇÏ ÄÌÑ ÕÄÁÌÅÎÉÑ ÎÅËÏÔÏÒÙÈ ÓÐÅÃÉÆÉÞÎÙÈ ÄÌÑ FreeBSD ÆÁÊÌÏ×. commit_prep.pl - ÜÔÏÔ ÓËÒÉÐÔ ×ÙÐÏÌÎÑÅÔ ÒÁÚÌÉÞÎÙÅ ÐÒÏ×ÅÒËÉ ÐÅÒÅÄ ×ÙÐÏÌÎÅÎÉÅÍ ËÏÍÍÉÔÁ, × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÔÏÇÏ, ×ËÌÀÞÉÌÉ ÌÉ ×Ù ÉÈ × cfg_local.pm. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÅÇÏ ÔÒÏÇÁÔØ. commitcheck - ÜÔÏÔ ÓËÒÉÐÔ ×ÙÚÙ×ÁÅÔÓÑ ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏ ÉÚ CVS. óÎÁÞÁÌÁ ÏÎ ÐÒÏ×ÅÒÑÅÔ, Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ cvs_acls.pl, ÉÍÅÅÔ ÌÉ ËÏÍÍÉÔÅÒ ÄÏÓÔÕÐ Ë ÕËÁÚÁÎÎÏÊ ÞÁÓÔÉ ÄÅÒÅ×Á, Á ÚÁÔÅÍ ÚÁÐÕÓËÁÅÔ commit_prep.pl ÄÌÑ ×ÙÐÏÌÎÅÎÉÑ ÒÁÚÌÉÞÎÙÈ ÐÒÏ×ÅÒÏË ÐÅÒÅÄ ËÏÍÍÉÔÏÍ. åÓÌÉ ÏÎÉ ×ÙÐÏÌÎÉÌÉÓØ ÎÏÒÍÁÌØÎÏ, ÔÏ CVS ÐÏÚ×ÏÌÉÔ ×ÙÐÏÌÎÉÔØ ËÏÍÍÉÔ. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. commitinfo - ÜÔÏÔ ÆÁÊÌ ÉÓÐÏÌØÚÕÅÔÓÑ × CVS ÄÌÑ ÏÐÒÅÄÅÌÅÎÉÑ ÔÏÇÏ, ËÁËÏÊ ÓËÒÉÐÔ ÚÁÐÕÓËÁÔØ ÐÅÒÅÄ ËÏÍÍÉÔÏÍ—× ÄÁÎÎÏÍ ÓÌÕÞÁÅ commitcheckl. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. config - ËÏÎÆÉÇÕÒÁÃÉÏÎÎÙÊ ÆÁÊÌ ÄÌÑ ÜÔÏÇÏ ÈÒÁÎÉÌÉÝÁ. ÷Ù ÄÏÌÖÎÙ ÉÚÍÅÎÑÔØ ÅÇÏ ÐÒÉ ÎÅÏÂÈÏÄÉÍÏÓÔÉ, ÎÏ ÂÏÌØÛÉÎÓÔ×Ï ÁÄÍÉÎÉÓÔÒÁÔÏÒÏ× ÍÏÇÕÔ ÏÓÔÁ×ÉÔØ ×ÓÅ ÎÁÓÔÒÏÊËÉ ÐÏ ÕÍÏÌÞÁÎÉÀ. äÏÐÏÌÎÉÔÅÌØÎÕÀ ÉÎÆÏÒÍÁÃÉÀ Ï ÐÁÒÁÍÅÔÒÁÈ, ËÏÔÏÒÙÅ ÍÏÇÕÔ ÂÙÔØ ÚÄÅÓØ ÚÁÄÁÎÙ, ÍÏÖÎÏ ÎÁÊÔÉ × ÒÕËÏ×ÏÄÓÔ×Å ÐÏ CVS. cvs_acls.pl - ÜÔÏÔ ÓËÒÉÐÔ ÉÄÅÎÔÉÆÉÃÉÒÕÅÔ ÐÏÌØÚÏ×ÁÔÅÌÑ É ÔÏ, ÉÍÅÅÔ ÌÉ ÏÎ ÄÏÓÔÕÐ Ë ÄÅÒÅ×Õ. üÔÏ ÄÅÌÁÅÔÓÑ ÎÁ ÏÓÎÏ×Å ÉÎÆÏÒÍÁÃÉÉ × ÆÁÊÌÅ avail. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. cvsignore - ÜÔÏÔ ÆÁÊÌ ÐÅÒÅÞÉÓÌÑÅÔ ÆÁÊÌÙ, ËÏÔÏÒÙÅ CVS ÎÅ ÄÏÌÖÎÁ ÐÏÍÅÝÁÔØ × ÈÒÁÎÉÌÉÝÅ. ÷Ù ÍÏÖÅÔÅ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÅÇÏ ÐÏ Ó×ÏÅÍÕ ÕÓÍÏÔÒÅÎÉÀ. âÏÌÅÅ ÐÏÌÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÜÔÏÍ ÆÁÊÌÅ ÎÁÈÏÄÉÔÓÑ × ÒÕËÏ×ÏÄÓÔ×Å ÐÏ CVS. cvswrappers - ÜÔÏÔ ÆÁÊÌ ÉÓÐÏÌØÚÕÅÔÓÑ × CVS ÄÌÑ ×ËÌÀÞÅÎÉÑ ÉÌÉ ×ÙËÌÀÞÅÎÉÑ ÒÁÓÛÉÒÅÎÉÑ ËÌÀÞÅ×ÙÈ ÓÌÏ×, ÉÌÉ ÄÏÌÖÅÎ ÌÉ ÆÁÊÌ ÓÞÉÔÁÔØÓÑ ÂÉÎÁÒÎÙÍ. ÷Ù ÍÏÖÅÔÅ ÒÅÄÁËÔÉÒÏ×ÁÔØ ÅÇÏ ÐÏ Ó×ÏÅÍÕ ÕÓÍÏÔÒÅÎÉÀ. âÏÌÅÅ ÐÏÌÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÜÔÏÍ ÆÁÊÌÅ ÎÁÈÏÄÉÔÓÑ × ÒÕËÏ×ÏÄÓÔ×Å ÐÏ CVS. éÍÅÊÔÅ ××ÉÄÕ, ÞÔÏ ÏÐÃÉÉ CVS -t É -f ÎÅËÏÒÒÅËÔÎÏ ÒÁÂÏÔÁÀÔ × ÒÅÖÉÍÅ ËÌÉÅÎÔ/ÓÅÒ×ÅÒ. edithook - ÜÔÏÔ ÆÁÊÌ ÂÏÌØÛÅ ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ, ÎÏ ÏÓÔÁ×ÌÅÎ ÐÏ ÉÓÔÏÒÉÞÅÓËÉÍ ÐÒÉÞÉÎÁÍ. ÷Ù ÍÏÖÅÔÅ ÓÐÏËÏÊÎÏ ÕÄÁÌÉÔØ ÜÔÏÔ ÆÁÊÌ. editinfo - CVS ÉÓÐÏÌØÚÕÅÔ ÜÔÏÔ ÆÁÊÌ ÄÌÑ ÎÁÓÔÒÏÊËÉ ÒÅÄÁËÔÏÒÁ. FreeBSD ÎÅ ÉÓÐÏÌØÚÕÅÔ ÜÔÕ ÆÕÎËÃÉÏÎÁÌØÎÏÓÔØ, ÔÁË ËÁË ÏÂÒÁÂÏÔËÁ ÓÏÏÂÝÅÎÉÊ ÄÌÑ ÖÕÒÎÁÌÁ ×ÙÐÏÌÎÑÅÔÓÑ × ÆÁÊÌÁÈ verifymsg É logcheck. üÔÏ ÐÒÏÉÓÈÏÄÉÔ ÐÏ ÔÏÊ ÐÒÉÞÉÎÅ, ÞÔÏ editinfo ÎÅËÏÒÒÅËÔÎÏ ÒÁÂÏÔÁÅÔ × ÒÅÖÉÍÅ ËÌÉÅÎÔ/ÓÅÒ×ÅÒ, ÉÌÉ × ÓÌÕÞÁÑÈ ËÏÇÄÁ ÉÓÐÏÌØÚÕÀÔÓÑ ÏÐÃÉÉ -m ÉÌÉ -F. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. exclude - × ÜÔÏÍ ÆÁÊÌÅ ÐÅÒÅÞÉÓÌÅÎÙ ÒÅÇÕÌÑÒÎÙÅ ×ÙÒÁÖÅÎÉÑ, ÉÓÐÏÌØÚÕÅÍÙÅ commit_prepl.pl ÄÌÑ ×ÙÄÅÌÅÎÉÑ ÆÁÊÌÏ×, × ËÏÔÏÒÙÈ ÍÏÇÕÔ ÎÅ ÓÏÄÅÒÖÁÔØÓÑ ÚÁÇÏÌÏ×ËÉ Ó ÎÏÍÅÒÏÍ ×ÅÒÓÉÉ. ÷ ÎÁÓÔÒÏÊËÅ FreeBSD ×ÓÅ ÆÁÊÌÙ ÓÏÄÅÒÖÁÝÉÅÓÑ × ÈÒÁÎÉÌÉÝÅ ÄÏÌÖÎÙ ÉÍÅÔØ ÚÁÇÏÌÏ×ÏË Ó ×ÅÒÓÉÅÊ (ÔÉÐÁ $FreeBSD$). ÷ÓÅ ÆÁÊÌÙ Ó ÉÍÅÎÁÍÉ, ËÏÔÏÒÙÅ ÓÏÏÔ×ÅÔÓÔ×ÕÀÔ ÏÄÎÏÊ ÉÚ ÓÔÒÏË ÜÔÏÇÏ ÆÁÊÌÁ, ÉÓËÌÀÞÁÀÔÓÑ ÉÚ ÐÒÏ×ÅÒËÉ. ÷Ù ÄÏÌÖÎÙ ÄÏÂÁ×ÉÔØ ×ÙÒÁÖÅÎÉÑ × ÜÔÏÔ ÆÁÊÌ, ÅÓÌÉ ×Ù ÐÏÍÅÝÁÅÔÅ × ÈÒÁÎÉÌÉÝÅ ÆÁÊÌÙ, ËÏÔÏÒÙÅ ÎÅ ÍÏÇÕÔ ÉÍÅÔØ ÚÁÇÏÌÏ×ËÉ Ó ×ÅÒÓÉÑÍÉ. äÌÑ ÃÅÌÅÊ ÕÓÔÁÎÏ×ËÉ ÓËÒÉÐÔÏ× ÌÕÞÛÉÍ ÒÅÛÅÎÉÅÍ ÍÏÖÅÔ ÏËÁÚÁÔØÓÑ ÉÓËÌÀÞÅÎÉÅ CVSROOT/ ÉÚ ÐÒÏ×ÅÒËÉ ÚÁÇÏÌÏ×ËÏ×. log_accum.pl - ÜÔÏ ÓËÒÉÐÔ, ËÏÔÏÒÙÊ ÐÒÉÎÉÍÁÅÔ ÖÕÒÎÁÌØÎÏÅ ÓÏÏÂÝÅÎÉÅ × ×ÉÄÅ, ÄÁÎÎÏÍ ÓËÒÉÐÔÏÍ logcheck, É ÄÏÂÁ×ÌÑÅÔ ÅÇÏ Ë ÆÁÊÌÕ ÖÕÒÎÁÌÁ × ÈÒÁÎÉÌÉÝÅ ÄÌÑ ÈÒÁÎÅÎÉÑ ÒÅÚÅÒ×ÎÏÊ ËÏÐÉÉ. ïÎ ÔÁËÖÅ ÏÔÒÁÂÁÔÙ×ÁÅÔ ÐÏÓÙÌËÕ ÓÏÏÂÝÅÎÉÑ ÐÏ ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÅ ÎÁ ÁÄÒÅÓ, ËÏÔÏÒÙÊ ×Ù ÚÁÄÁÄÉÔÅ (× ÆÁÊÌÅ cfg_local.pm). ïÎ ÐÏÄËÌÀÞÁÅÔÓÑ Ë CVS ÞÅÒÅÚ loginfo. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. logcheck - ÐÒÉ ËÏÍÍÉÔÅ ÜÔÏÔ ÆÁÊÌ ÁÎÁÌÉÚÉÒÕÅÔ ÓÏÏÂÝÅÎÉÅ ÄÌÑ ÖÕÒÎÁÌÁ, ËÏÔÏÒÏÅ ÓÏÓÔÁ×ÌÑÀÔ ËÏÍÍÉÔÔÅÒÙ, É ÐÙÔÁÅÔÓÑ ÅÇÏ ÎÅËÏÔÏÒÙÍ ÏÂÒÁÚÏÍ ÕÌÕÞÛÉÔØ. ïÎ ÐÏÄËÌÀÞÁÅÔÓÑ Ë CVS ÞÅÒÅÚ logcheck. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. üÔÏÔ ÓËÒÉÐÔ ÚÁ×ÉÓÉÔ ÏÔ ÒÑÄÁ ÌÏËÁÌØÎÙÈ ÍÏÄÉÆÉËÁÃÉÊ CVS, ÓÄÅÌÁÎÎÙÊ ×Ï FreeBSD: ÜÔÁ ×ÅÒÓÉÑ ÞÉÔÁÅÔ ÖÕÒÎÁÌØÎÏÅ ÓÏÏÂÝÅÎÉÅ ÐÏ×ÔÏÒÎÏ ÐÏÓÌÅ ÔÏÇÏ, ËÁË ÜÔÏÔ ÓËÒÉÐÔ ÅÇÏ ÍÏÄÉÆÉÃÉÒÕÅÔ. óÔÁÎÄÁÒÔÎÁÑ ×ÅÒÓÉÑ CVS ÜÔÏÇÏ ÎÅ ÄÅÌÁÅÔ, ÞÔÏ ÄÅÌÁÅÔ ÜÔÏÔ ÓËÒÉÐÔ ÂÅÓÐÏÌÅÚÎÙÍ, ÔÁË ËÁË ÏÎ ÎÅ ÍÏÖÅÔ ÍÏÄÉÆÉÃÉÒÏ×ÁÔØ ÖÕÒÎÁÌØÎÏÅ ÓÏÏÂÝÅÎÉÅ, ÈÏÔÑ ÍÏÖÅÔ ÐÒÏ×ÅÒÉÔØ ÅÇÏ ÎÁ ÐÒÅÄÍÅÔ ÐÒÁ×ÉÌØÎÏÓÔÉ ÓÉÎÔÁËÓÉÓÁ. CVS ×ÅÒÓÉÉ 1.11.2 É ×ÙÛÅ ÍÏÖÅÔ ÂÙÔØ ÎÁÓÔÒÏÅÎ, ÞÔÏ ÉÍÅÔØ ÐÏ×ÅÄÅÎÉÅ ÐÏÄÏÂÎÏÅ FreeBSD, ÐÕÔÅÍ ÕÓÔÁÎÏ×ËÉ ÏÐÃÉÉ RereadLogAfterVerify=always × ÆÁÊÌÅ config. loginfo - ÜÔÏÔ ÆÁÊÌ ÉÓÐÏÌØÚÕÅÔÓÑ CVS ÄÌÑ ÕÐÒÁ×ÌÅÎÉÑ ÔÏÇÏ, ËÕÄÁ ÐÏÓÙÌÁÅÔÓÑ ÐÒÏÔÏËÏÌØÎÁÑ ÉÎÆÏÒÍÁÃÉÑ. ó ÐÏÍÏÝØÀ ÜÔÏÇÏ ÆÁÊÌÁ ÐÏÄËÌÀÞÁÅÔÓÑ log_accum.pl. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. modules - ÜÔÏÔ ÆÁÊÌ ÓÏÈÒÁÎÑÅÔ Ó×Ï£ ÔÒÁÄÉÃÉÏÎÎÏÅ ÎÁÚÎÁÞÅÎÉÅ × CVS. ÷Ù ÄÏÌÖÎÙ ÕÄÁÌÉÔØ ÍÏÄÕÌÉ FreeBSD ÉÚ ÓÔÁÎÄÁÒÔÎÏÊ ×ÅÒÓÉÉ. ÷Ù ÍÏÖÅÔÅ ÒÅÄÁËÔÉÒÏ×ÁÔØ ÜÔÏÔ ÆÁÊÌ ÐÏ Ó×ÏÅÍÕ ÕÓÍÏÔÒÅÎÉÀ. âÏÌÅÅ ÐÏÌÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÜÔÏÍ ÆÁÊÌÅ ÎÁÈÏÄÉÔÓÑ × ÒÕËÏ×ÏÄÓÔ×Å ÐÏ CVS. notify - ÜÔÏÔ ÆÁÊÌ ÉÓÐÏÌØÚÕÅÔÓÑ × CVS × ÔÏÍ ÓÌÕÞÁÅ, ÅÓÌÉ ËÔÏ-ÔÏ ÚÁÄÁÓÔ ÏÔÓÌÅÖÉ×ÁÎÉÅ ÆÁÊÌÁ. üÔÏ ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ × ÈÒÁÎÉÌÉÝÅ FreeBSD. ÷Ù ÍÏÖÅÔÅ ÒÅÄÁËÔÉÒÏ×ÁÔØ ÅÇÏ ÐÏ Ó×ÏÅÍÕ ÕÓÍÏÔÒÅÎÉÀ. âÏÌÅÅ ÐÏÌÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÜÔÏÍ ÆÁÊÌÅ ÎÁÈÏÄÉÔÓÑ × ÒÕËÏ×ÏÄÓÔ×Å ÐÏ CVS. options - ÜÔÏÔ ÆÁÊÌ ÓÐÅÃÉÆÉÞÅÎ ÄÌÑ ×ÅÒÓÉÉ CVS ÏÔ FreeBSD, ÎÏ ÔÁËÖÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ ×ÅÒÓÉÅÊ ÄÌÑ Debian. ïÎ ÓÏÄÅÒÖÉÔ ËÌÀÞÅ×ÏÅ ÓÌÏ×Ï ÄÌÑ ÒÁÓÛÉÒÅÎÉÑ × ÚÁÇÏÌÏ×ËÁÈ ×ÅÒÓÉÊ. ÷Ù ÄÏÌÖÎÙ ÚÁÍÅÎÉÔØ ÜÔÏ ÎÁ ËÌÀÞÅ×ÏÅ ÓÌÏ×Ï, ËÏÔÏÒÏÅ ×Ù ÚÁÄÁÌÉ × ÆÁÊÌÅ cfg_local.pm (ÅÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ ÜÔÕ ×ÏÚÍÏÖÎÏÓÔØ, ËÏÔÏÒÁÑ × ÎÁÓÔÏÑÝÅÅ ×ÒÅÍÑ ÓÐÅÃÉÆÉÞÎÁ ÄÌÑ FreeBSD). rcsinfo - ÜÔÏÔ ÆÁÊÌ ÏÔÏÂÒÁÖÁÅÔ ËÁÔÁÌÏÇÉ × ÈÒÁÎÉÌÉÝÅ ÎÁ ÆÁÊÌÙ ÛÁÂÌÏÎÏ×, ËÁË ÎÁÐÒÉÍÅÒ rcstemplate. ðÏ ÕÍÏÌÞÁÎÉÀ FreeBSD ÉÓÐÏÌØÚÕÅÔ ÏÄÉÎ ÛÁÂÌÏÎ ÄÌÑ ×ÓÅÇÏ ÈÒÁÎÉÌÉÝÁ. ÷Ù ÍÏÖÅÔÅ ÄÏÂÁ×ÌÑÔØ ÄÒÕÇÉÅ Ë ÜÔÏÍÕ ÆÁÊÌÕ ÐÏ Ó×ÏÅÍÕ ÕÓÍÏÔÒÅÎÉÀ. rcstemplate - ÜÔÏÔ ÆÁÊÌ Ñ×ÌÑÅÔÓÑ ÁËÔÕÁÌØÎÙÍ ÆÁÊÌÏÍ ÛÁÂÌÏÎÁ, ËÏÔÏÒÙÊ ×ÉÄÑÔ ËÏÍÍÉÔÔÅÒÙ, ËÏÇÄÁ ÐÏÍÅÝÁÀÔ ÞÔÏ-ÔÏ × ÈÒÁÎÉÌÉÝÅ. ÷Ù ÄÏÌÖÎÙ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÅÇÏ ÄÌÑ ÏÐÉÓÁÎÉÑ ÒÁÚÌÉÞÎÙÈ ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÐÁÒÁÍÅÔÒÏ×, ËÏÔÏÒÙÅ ×Ù ÏÐÒÅÄÅÌÉÌÉ × cfg_local.pm. tagcheck - ÜÔÉ ÆÁÊÌÙ ÕÐÒÁ×ÌÑÀÔ ÄÏÓÔÕÐÏÍ Ë ÓÏÚÄÁÎÉÀ ÍÅÔÏË × ÈÒÁÎÉÌÉÝÅ. óÔÁÎÄÁÒÔÎÁÑ ÄÌÑ FreeBSD ×ÅÒÓÉÑ ÎÅ ÐÏÚ×ÏÌÑÅÔ ÓÏÚÄÁ×ÁÔØ ÍÅÔËÉ Ó ÉÍÅÎÁÍÉ ÔÉÐÁ RELENG* ÉÚ-ÚÁ ÐÅÒÅÓÅÞÅÎÉÑ Ó ÐÒÏÃÅÓÓÏÍ ÓÏÚÄÁÎÉÑ ÒÅÌÉÚÏ×. ÷Ù ÄÏÌÖÎÙ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÜÔÏÔ ÆÁÊÌ ÐÏ ×ÁÛÅÍÕ ÕÓÍÏÔÒÅÎÉÀ. taginfo - ÜÔÏÔ ÆÁÊÌ ÓÔÁ×ÉÔ × ÓÏÏÔ×ÅÔÓÔ×ÉÅ ÏÐÅÒÁÃÉÉ Ó ÍÅÔËÁÍÉ ÎÁÄ ËÁÔÁÌÏÇÁÍÉ ÈÒÁÎÉÌÉÝÁ ÓËÒÉÐÔÁÍ ÕÐÒÁ×ÌÅÎÉÑ ÄÏÓÔÕÐÏÍ, ÎÁÐÒÉÍÅÒ tagcheck. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. unwrap - ÜÔÏÔ ÓËÒÉÐÔ ÎÕÖÅÎ ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÊ ÏÂÒÁÔÎÏÊ ÏÂÒÁÂÏÔËÉ (unwrap) Ä×ÏÉÞÎÙÈ ÆÁÊÌÏ× (ÐÏÓÍÏÔÒÉÔÅ cvswrappers) ÐÒÉ ÉÚ×ÌÅÞÅÎÉÉ. üÔÏ ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ × ÔÅËÕÝÅÊ ÎÁÓÔÒÏÊËÅ FreeBSD ÐÏ ÐÒÉÞÉÎÅ ÔÏÇÏ, ÞÔÏ ÎÅ ÒÁÂÏÔÁÅÔ Ó ËÏÎÆÉÇÕÒÁÃÉÅÊ ËÌÉÅÎÔ/ÓÅÒ×ÅÒ. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. verifymsg - ÜÔÏÔ ÆÁÊÌ ÓÔÁ×ÉÔ × ÓÏÏÔ×ÅÔÓÔ×ÉÅ ËÁÔÁÌÏÇÁÍ ÈÒÁÎÉÌÉÝÁ ÓËÒÉÐÔÙ ×ÔÏÒÉÞÎÏÊ ÏÂÒÁÂÏÔËÉ ÖÕÒÎÁÌØÎÙÈ ÓÏÏÂÝÅÎÉÊ, ÎÁÐÒÉÍÅÒ logcheck. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. wrap - ÜÔÏÔ ÓËÒÉÐÔ ÍÏÖÅÔ ÂÙÔØ ÉÓÐÏÌØÚÏ×ÁÎ ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÊ ÏÂÒÁÂÏÔËÉ (wrap) Ä×ÏÉÞÎÙÈ ÆÁÊÌÏ× (ÐÏÓÍÏÔÒÉÔÅ cvswrappers) ÐÒÉ ÐÏÍÅÝÅÎÉÉ × ÈÒÁÎÉÌÉÝÅ. üÔÏ ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ × ÔÅËÕÝÅÊ ÎÁÓÔÒÏÊËÅ FreeBSD, ÐÏ ÐÒÉÞÉÎÅ ÔÏÇÏ, ÞÔÏ ÎÅ ÒÁÂÏÔÁÅÔ Ó ËÏÎÆÉÇÕÒÁÃÉÅÊ ËÌÉÅÎÔ/ÓÅÒ×ÅÒ. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. îÁÓÔÒÏÊËÁ ÓËÒÉÐÔÏ× óÌÅÄÕÀÝÉÍ ÛÁÇÏÍ Ñ×ÌÑÅÔÓÑ ÎÁÓÔÒÏÊËÁ ÓËÒÉÐÔÏ× ÔÁË, ÞÔÏÂÙ ÏÎÉ ÒÁÂÏÔÁÌÉ × ×ÁÛÉÈ ÕÓÌÏ×ÉÑÈ. ÷Ù ÄÏÌÖÎÙ ÐÒÏÓÍÏÔÒÅÔØ ×ÓÅ ÆÁÊÌÙ × ËÁÔÁÌÏÇÅ É ×ÙÐÏÌÎÉÔØ ×ÁÛÉ ÎÁÓÔÒÏÊËÉ. ÷ ÞÁÓÔÎÏÓÔÉ, ×Ù ÍÏÖÅÔ ÐÏÔÒÅÂÏ×ÁÔØÓÑ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÓÌÅÄÕÀÝÉÅ ÆÁÊÌÙ: åÓÌÉ ×Ù ÎÅ ÈÏÔÉÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÓÐÅÃÉÆÉÞÎÙÅ ÄÌÑ FreeBSD ×ÏÚÍÏÖÎÏÓÔÉ ÓËÒÉÐÔÏ×, ÔÏ ×Ù ÍÏÖÅÔÅ ÂÅÚ ÐÏÓÌÅÄÓÔ×ÉÊ ÕÄÁÌÉÔØ ÆÁÊÌ access: &prompt.user; cvs rm -f access ïÔÒÅÄÁËÔÉÒÕÊÔÅ avail ÔÁË, ÞÔÏÂÙ ÏÎ ÓÏÄÅÒÖÁÌ ÒÁÚÌÉÞÎÙÅ ËÁÔÁÌÏÇÉ ÈÒÁÎÉÌÉÝÁ, ÄÏÓÔÕÐÏÍ Ë ËÏÔÏÒÙÍ ×Ù ÈÏÔÉÔÅ ÕÐÒÁ×ÌÑÔØ. ïÂÑÚÁÔÅÌØÎÏ ÓÏÈÒÁÎÉÔÅ ÓÔÒÏÞËÕ avail||CVSROOT, ÉÎÁÞÅ ×Ù ÚÁÂÌÏËÉÒÕÅÔÅ ÓÁÍÉ ÓÅÂÑ ÎÁ ÓÌÅÄÕÀÝÅÍ ÛÁÇÅ. äÒÕÇÉÍÉ ÐÁÒÁÍÅÔÒÁÍÉ, ËÏÔÏÒÙÅ ×Ù ÍÏÖÅÔÅ ÄÏÂÁ×ÉÔØ × ÜÔÏÔ ÆÁÊÌ, Ñ×ÌÑÀÔÓÑ ÇÒÕÐÐÙ ËÏÍÍÉÔÔÅÒÏ×. ðÏ ÕÍÏÌÞÁÎÉÀ FreeBSD ÉÓÐÏÌØÚÕÅÔ ÆÁÊÌ access ÄÌÑ ÐÅÒÅÞÉÓÌÅÎÉÑ ×ÓÅÈ ËÏÍÍÉÔÔÅÒÏ×, ÎÏ ×Ù ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÌÀÂÏÊ ÆÁÊÌ. ÷Ù ÍÏÖÅÔÅ ÔÁËÖÅ ÄÏÂÁ×ÉÔØ ÇÒÕÐÐÙ, ÅÓÌÉ ÈÏÔÉÔÅ (ÓÉÎÔÁËÓÉÓ ÏÐÉÓÁÎ × ÎÁÞÁÌÅ ÆÁÊÌÁ cvs_acls.pl). ïÔÒÅÄÁËÔÉÒÕÊÔÅ ÆÁÊÌ cfg_local.pm ÔÁË, ÞÔÏÂÙ ÏÎ ÓÏÄÅÒÖÁÌ ÐÁÒÁÍÅÔÒÙ, ËÏÔÏÒÙÅ ×Ù ÈÏÔÉÔÅ. ÷ ÞÁÓÔÎÏÓÔÉ, ×Ù ÄÏÌÖÎÙ ×ÚÇÌÑÎÕÔØ ÎÁ ÔÁËÉÅ ÐÕÎËÔÙ ÎÁÓÔÒÏÊËÉ: %TEMPLATE_HEADERS - ÏÎÉ ÏÂÒÁÂÁÔÙ×ÁÀÔÓÑ ÓËÒÉÐÔÁÍÉ ×ÅÄÅÎÉÑ ÐÒÏÔÏËÏÌÁ, É ×ÓÔÁ×ÌÑÀÔÓÑ ÎÉÖÅ ÐÏÞÔÏ×ÏÇÏ ÓÏÏÂÝÅÎÉÑ, ÅÓÌÉ ÏÎÉ ÐÒÉÓÕÔÓÔ×ÕÀÔ É ÎÅ Ñ×ÌÑÀÔÓÑ ÐÕÓÔÙÍÉ × ÓÏÏÂÝÅÎÉÉ ÐÒÉ ËÏÍÍÉÔÅ. ÷Ù ÍÏÖÅÔÅ, ÎÁ×ÅÒÎÏÅ, ÕÄÁÌÉÔØ ÓÔÒÏËÉ PR É MFC after. é, ËÏÎÅÞÎÏ, ×Ù ÍÏÖÅÔÅ ÄÏÂÁ×ÉÔØ Ó×ÏÉ ÓÏÂÓÔ×ÅÎÎÙÅ. $MAIL_BRANCH_HDR - ÅÓÌÉ ×Ù ÈÏÔÉÔÅ × ËÁÖÄÏÅ ÓÏÏÂÝÅÎÉÅ ÐÒÉ ËÏÍÍÉÔÅ ×ÓÔÁ×ÌÑÔØ ÚÁÇÏÌÏ×ÏË, ÏÐÉÓÙ×ÁÀÝÉÊ ×ÅÔËÕ, × ËÏÔÏÒÕÀ ÂÙÌ ×ÙÐÏÌÎÅÎ ËÏÍÍÉÔ, ÚÁÄÁÊÔÅ ÜÔÏ × ÓÏÏÔ×ÅÔÓÔ×ÉÉ Ó ×ÁÛÉÍ ÏËÒÕÖÅÎÉÅÍ. éÌÉ ÏÓÔÁרÔÅ ÜÔÏ ÐÕÓÔÙÍ, ÅÓÌÉ ÎÅ ÈÏÔÉÔÅ ÉÍÅÔØ ÔÁËÏÊ ÚÁÇÏÌÏ×ÏË. @COMMIT_HOSTS - ÚÁÄÁÊÔÅ ÚÄÅÓØ ÓÐÉÓÏË ÈÏÓÔÏ×, Ó ËÏÔÏÒÙÈ ÍÏÖÎÏ ×ÙÐÏÌÎÑÔØ ËÏÍÍÉÔÙ. $MAILADDRS - ÚÁÄÁÊÔÅ ÚÄÅÓØ ÁÄÒÅÓ ÁÄÍÉÎÉÓÔÒÁÔÏÒÁ ÉÌÉ ÓÐÉÓËÁ, × ËÏÔÏÒÙÊ ÄÏÌÖÎÙ ÎÁÐÒÁ×ÌÑÔØÓÑ ÐÏÞÔÏ×ÙÅ ÓÏÏÂÝÅÎÉÑ ÐÒÉ ËÏÍÍÉÔÅ. @LOG_FILE_MAP - ÉÚÍÅÎÉÔÅ ÜÔÏÔ ÍÁÓÓÉ× ÐÏ Ó×ÏÅÍÕ ÕÓÍÏÔÒÅÎÉÀ - ËÁÖÄÏÅ ÒÅÇÕÌÑÒÎÏÅ ×ÙÒÁÖÅÎÉÅ ÓÒÁ×ÎÉ×ÁÅÔÓÑ Ó ËÁÔÁÌÏÇÏÍ ËÏÍÍÉÔÁ, É ÐÒÏÔÏËÏÌØÎÏÅ ÓÏÏÂÝÅÎÉÅ ÐÒÉ ËÏÍÍÉÔÅ ÓÏÈÒÁÎÑÅÔÓÑ × ÐÏÄËÁÔÁÌÏÇÅ commitlogs × ÕËÁÚÁÎÎÏÍ ÆÁÊÌÅ. $COMMITCHECK_EXTRA - ÅÓÌÉ ×Ù ÎÅ ÈÏÔÉÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÓÐÅÃÉÆÉÞÎÙÅ ÄÌÑ FreeBSD ÐÒÏ×ÅÒËÉ ÄÏÓÔÕÐÁ, ÔÏ ×Ù ÄÏÌÖÎÙ ÕÄÁÌÉÔØ ÏÐÒÅÄÅÌÅÎÉÑ $COMMITCHECK_EXTRA ÉÚ ÜÔÏÇÏ ÆÁÊÌÁ. éÚÍÅÎÅÎÉÅ ÐÁÒÁÍÅÔÒÁ $IDHEADER ÇÁÒÁÎÔÉÒÏ×ÁÎÎÏ ÒÁÂÏÔÁÅÔ ÔÏÌØËÏ ÎÁ ÐÌÁÔÆÏÒÍÁÈ FreeBSD; ÜÔÏ ÚÁ×ÉÓÉÔ ÏÔ ÓÐÅÃÉÆÉÞÎÙÈ ÄÌÑ FreeBSD ÍÏÄÉÆÉËÁÃÉÊ × CVS. ÷Ù ÍÏÖÅÔÅ ÐÒÏ×ÅÒÉÔØ cfg.pm ÎÁ ÐÒÅÄÍÅÔ ÔÏÇÏ, ËÁËÉÅ ÄÒÕÇÉÅ ÐÁÒÁÍÅÔÒÙ ÍÏÇÕÔ ÂÙÔØ ÉÚÍÅÎÅÎÙ, ÎÏ ÐÅÒÅÞÉÓÌÅÎÎÏÅ ×ÙÛÅ Ñ×ÌÑÅÔÓÑ ÄÏÓÔÁÔÏÞÎÙÍ ÐÏÄÍÎÏÖÅÓÔ×ÏÍ. ïÔÒÅÄÁËÔÉÒÕÊÔÅ exclude ÄÌÑ ÕÄÁÌÅÎÉÑ ÓÐÅÃÉÆÉÞÎÙÈ ÄÌÑ FreeBSD ÚÁÐÉÓÅÊ (ÎÁÐÒÉÍÅÒ, ×ÓÅÈ ÓÔÒÏË, ËÏÔÏÒÙÅ ÎÁÞÉÎÁÀÔÓÑ Ó ^ports/ É ÔÁË ÄÁÌÅÅ). âÏÌÅÅ ÔÏÇÏ, ÚÁËÏÍÍÅÎÔÉÒÕÊÔÅ ÓÔÒÏËÉ, ÎÁÞÉÎÁÀÝÉÅÓÑ Ó ^CVSROOT/, É ÄÏÂÁרÔÅ ÏÄÎÕ ÓÔÒÏËÕ ÔÏÌØËÏ Ó ^CVSROOT/. ðÏÓÌÅ ÕÓÔÁÎÏ×ËÉ ÏÂÒÁÂÏÔÞÉËÁ (wrapper) ×Ù ÍÏÖÅÔÅ ÄÏÂÁ×ÉÔØ Ó×ÏÉ ÚÁÇÏÌÏ×ËÉ Ë ÆÁÊÌÁÍ × ËÁÔÁÌÏÇÅ CVSROOT É ×ÏÓÓÔÁÎÏ×ÉÔØ ÜÔÉ ÓÔÒÏËÉ, ÎÏ ÔÅÐÅÒØ ÏÎÉ ÂÕÄÕÔ ÉÍÅÔØ ÓÍÙÓÌ, ÔÏÌØËÏ ËÏÇÄÁ ×Ù ÐÏÐÙÔÁÅÔÅÓØ ×ÙÐÏÌÎÉÔØ ËÏÍÍÉÔ ÐÏÚÖÅ. ïÔÒÅÄÁËÔÉÒÕÊÔÅ ÆÁÊÌ modules É ÕÄÁÌÉÔÅ ×Ó£, ÞÔÏ ÏÔÎÏÓÉÔÓÑ Ë FreeBSD. äÏÂÁרÔÅ ÓÏÂÓÔ×ÅÎÎÙÅ ÍÏÄÕÌÉ, ÅÓÌÉ ÈÏÔÉÔÅ. üÔÏÔ ÛÁÇ ÎÅÏÂÈÏÄÉÍ, ÅÓÌÉ ÔÏÌØËÏ ×Ù ÚÁÄÁÌÉ ÚÎÁÞÅÎÉÅ ÄÌÑ $IDHEADER × cfg_local.pm (ÞÔÏ ÒÁÂÏÔÁÅÔ ÔÏÌØËÏ ÐÒÉ ÉÓÐÏÌØÚÏ×ÁÎÉÉ ÍÏÄÉÆÉÃÉÒÏ×ÁÎÎÏÊ ×Ï FreeBSD ×ÅÒÓÉÉ CVS). ïÔÒÅÄÁËÔÉÒÕÊÔÅ ÆÁÊÌ options ÔÁË, ÞÔÏÂÙ ÏÎ ÓÏÏÔ×ÅÔÓÔ×Ï×ÁÌ ÍÅÔËÅ, ËÏÔÏÒÕÀ ×Ù ÚÁÄÁÌÉ × cfg_local.pm. çÌÏÂÁÌØÎÙÊ ÐÏÉÓË É ÚÁÍÅÎÁ FreeBSD ÎÁ ×ÁÛÕ ÍÅÔËÕ ÄÏÌÖÎÙ ÓÒÁÂÏÔÁÔØ. ïÔÒÅÄÁËÔÉÒÕÊÔÅ ÆÁÊÌ rcstemplate ÔÁË, ÞÔÏÂÙ ÏÎ ÓÏÄÅÒÖÁÌ ÔÅ ÖÅ ÓÁÍÙÅ ËÌÀÞÅ×ÙÅ ÓÌÏ×Á, ÞÔÏ ÚÁÄÁÎÙ × cfg_local.pm. ïÐÃÉÏÎÁÌØÎÏ ÕÄÁÌÉÔÅ ÐÒÏ×ÅÒËÉ FreeBSD ÉÚ tagcheck. ÷Ù ÍÏÖÅÔÅ ÐÒÏÓÔÏ ÄÏÂÁ×ÉÔØ exit 0 × ÎÁÞÁÌÏ ÆÁÊÌÁ, ÞÔÏÂÙ ÚÁÐÒÅÔÉÔØ ×ÓÅ ÐÒÏ×ÅÒËÉ ÐÒÉ ÕÓÔÁÎÏ×ËÅ ÍÅÔËÉ. ðÏÓÌÅÄÎÉÍ ÄÅÊÓÔ×ÉÅÍ, ËÏÔÏÒÏÅ ÎÕÖÎÏ ÓÄÅÌÁÔØ ÐÅÒÅÄ ÔÅÍ, ËÁË ÚÁËÏÎÞÉÔØ ÒÁÂÏÔÕ, Ñ×ÌÑÅÔÓÑ ÐÒÏ×ÅÒËÁ ÔÏÇÏ, ÞÔÏ ÐÒÏÔÏËÏÌÙ ËÏÍÍÉÔÏ× ÍÏÇÕÔ ÓÏÈÒÁÎÑÔØÓÑ. ðÏ ÕÍÏÌÞÁÎÉÀ ÏÎÉ ÓÏÈÒÁÎÑÀÔÓÑ × ÈÒÁÎÉÌÉÝÅ, × ÐÏÄËÁÔÁÌÏÇÅ commitlogs ËÁÔÁÌÏÇÁ CVSROOT. üÔÏÔ ËÁÔÁÌÏÇ ÄÏÌÖÅÎ ÂÙÔØ ÓÏÚÄÁÎ, ÔÁË ÞÔÏ ×ÙÐÏÌÎÉÔÅ ÓÌÅÄÕÀÝÅÅ: &prompt.user; mkdir commitlogs &prompt.user; cvs add commitlogs á ÔÅÐÅÒØ, ÐÏÓÌÅ ÔÝÁÔÅÌØÎÏÊ ÐÒÏ×ÅÒËÉ, ×Ù ÄÏÌÖÎÙ ×ÙÐÏÌÎÉÔØ ËÏÍÍÉÔ ×ÁÛÉÈ ÉÚÍÅÎÅÎÉÊ. õÂÅÄÉÔÅÓØ, ÞÔÏ ×Ù ÄÁÌÉ ÓÁÍÉ ÓÅÂÅ ÄÏÓÔÕÐ Ë ËÁÔÁÌÏÇÕ CVSROOT × ×ÁÛÅÍ avail ÄÏ ÔÏÇÏ, ËÁË ÅÇÏ ÄÅÌÁÔØ, ÔÁË ËÁË × ÐÒÏÔÉ×ÎÏÍ ÓÌÕÞÁÅ ×Ù ÚÁÂÌÏËÉÒÕÅÔÅ ÓÁÍÉ ÓÅÂÑ. ôÁË ÞÔÏ ÕÂÅÄÉÔÅÓØ, ÞÔÏ ×Ó£ ÉÍÅÎÎÏ ÔÁË, ËÁË ×Ù É ÐÒÅÄÐÏÌÁÇÁÌÉ, Á ÚÁÔÅÍ ×ÙÐÏÌÎÉÔÅ ÓÌÅÄÕÀÝÅÅ: &prompt.user; cvs commit -m '- Initial FreeBSD scripts commit' ôÅÓÔÉÒÏ×ÁÎÉÅ ÎÁÓÔÒÏÊËÉ ÷Ù ÇÏÔÏ×Ù Ë ÐÅÒ×ÏÍÕ ÔÅÓÔÉÒÏ×ÁÎÉÀ: ÐÒÉÎÕÄÉÔÅÌØÎÏÍÕ ËÏÍÍÉÔÕ × ÆÁÊÌ avail, ÞÔÏÂÙ ÕÂÅÄÉÔØÓÑ, ÞÔÏ ×Ó£ ÒÁÂÏÔÁÅÔ ÔÁË, ËÁË ÏÖÉÄÁÌÏÓØ. &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' avail åÓÌÉ ×Ó£ ÒÁÂÏÔÁÅÔ, ÐÏÚÄÒÁ×ÌÑÅÍ! ôÅÐÅÒØ Õ ×ÁÓ ÉÍÅÅÔÓÑ ÒÁÂÏÔÁÀÝÁÑ ÎÁÓÔÒÏÊËÁ ÓËÒÉÐÔÏ× FreeBSD ÄÌÑ ×ÁÛÅÇÏ ÈÒÁÎÉÌÉÝÁ. åÓÌÉ CVS ×Ó£ ÅÝ£ Ï Þ£Í-ÔÏ ÓÏÏÂÝÁÅÔ, ×ÅÒÎÉÔÅÓØ É ÐÒÏ×ÅÒØÔÅ, ×ÓÅ ÌÉ ×ÙÛÅÕÐÏÍÑÎÕÔÙÅ ÛÁÇÉ ÂÙÌÉ ×ÙÐÏÌÎÅÎÙ ÐÒÁ×ÉÌØÎÏ. óÐÅÃÉÆÉÞÎÁÑ ÄÌÑ FreeBSD ÎÁÓÔÒÏÊËÁ ðÒÏÅËÔ FreeBSD ÓÁÍ ÐÏ ÓÅÂÅ ÉÓÐÏÌØÚÕÅÔ ÎÅÓËÏÌØËÏ ÄÒÕÇÕÀ ÎÁÓÔÒÏÊËÕ, × ËÏÔÏÒÏÊ ÔÁËÖÅ ÉÓÐÏÌØÚÕÀÔÓÑ ÆÁÊÌÙ ÉÚ ÐÏÄËÁÔÁÌÏÇÁ freebsd ËÁÔÁÌÏÇÁ FreeBSD CVSROOT. ðÒÏÅËÔ ÉÓÐÏÌØÚÕÅÔ ÉÈ ÉÚ-ÚÁ ÂÏÌØÛÏÇÏ ËÏÌÉÞÅÓÔ×Á ËÏÍÍÉÔÔÅÒÏ×, ËÏÔÏÒÙÅ ×ÓÅ ÄÏÌÖÎÙ ÂÙÔØ × ÏÄÎÏÊ É ÔÏÊ ÖÅ ÇÒÕÐÐÅ. ðÏÜÔÏÍÕ ÂÙÌ ÎÁÐÉÓÁÎ ÐÒÏÓÔÏÊ ÏÂÒÁÂÏÔÞÉË, ÐÒÏ×ÅÒÑÀÝÉÊ, ÞÔÏ ÌÀÄÉ ÉÍÅÀÔ ÐÒÁ×ÉÌØÎÙÅ ÐÒÁ×Á ÎÁ ×ÙÐÏÌÎÅÎÉÅ ËÏÍÍÉÔÁ, Á ÚÁÔÅÍ ÕÓÔÁÎÁ×ÌÉ×ÁÀÝÉÊ ÉÄÅÎÔÉÆÉËÁÔÏÒ ÇÒÕÐÐÙ, ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÉÊ ÉÄÅÎÔÉÆÉËÁÔÏÒÕ ÈÒÁÎÉÌÉÝÁ. åÓÌÉ ×ÁÛÅÍÕ ÈÒÁÎÉÌÉÝÕ ÜÔÏ ÔÏÖÅ ÎÕÖÎÏ, ÔÏ ÛÁÇÉ ÄÌÑ ×ÙÐÏÌÎÅÎÉÑ ÜÔÏÇÏ ÏÐÉÓÁÎÙ ÎÉÖÅ. îÏ ÓÎÁÞÁÌÁ ÏÂÚÏÒ Ó×ÑÚÁÎÎÙÈ Ó ÜÔÉÍ ÆÁÊÌÏ×. æÁÊÌÙ, ÉÓÐÏÌØÚÕÅÍÙÅ × ÎÁÓÔÒÏÊËÅ FreeBSD access - ÜÔÏÔ ÆÁÊÌ ÕÐÒÁ×ÌÑÅÔ ÉÎÆÏÒÍÁÃÉÅÊ Ï ÄÏÓÔÕÐÅ. ÷Ù ÄÏÌÖÎÙ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÜÔÏÔ ÆÁÊÌ ÄÌÑ ×ËÌÀÞÅÎÉÑ ×ÓÅÈ ÕÞÁÓÔÎÉËÏ× ×ÁÛÅÇÏ ÐÒÏÅËÔÁ. freebsd/commitmail.pl - ÜÔÏÔ ÆÁÊÌ ÂÏÌØÛÅ ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ, ÎÏ ÏÓÔÁ×ÌÅÎ ÐÏ ÉÓÔÏÒÉÞÅÓËÉÍ ÐÒÉÞÉÎÁÍ. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. freebsd/cvswrap.c - ÜÔÏ ÉÓÈÏÄÎÙÊ ÔÅËÓÔ ÏÂÒÁÂÏÔÞÉËÁ CVS, ËÏÔÏÒÙÊ ×ÁÍ ÎÕÖÎÏ ÕÓÔÁÎÏ×ÉÔØ, ÞÔÏÂÙ ÐÒÏ×ÅÒËÉ ÄÏÓÔÕÐÁ ÒÅÁÌØÎÏ ÚÁÒÁÂÏÔÁÌÉ. äÏÐÏÌÎÉÔÅÌØÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÜÔÏÍ ÎÉÖÅ. ÷Ù ÄÏÌÖÎÙ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÍÁÒÛÒÕÔÙ × ÍÁËÒÏÓÁÈ ACCESS É REALCVS ÔÁË, ÞÔÏÂÙ ÏÎÉ ÓÏÏÔ×ÅÔÓÔ×Ï×ÁÌÉ ×ÁÛÅÊ ÎÁÓÔÒÏÊËÅ. freebsd/mailsend.c - ÜÔÏÔ ÆÁÊÌ ÎÕÖÅÎ × ÎÁÓÔÒÏÊËÅ FreeBSD ÄÌÑ ÓÐÉÓËÏ× ÒÁÓÓÙÌËÉ. ÷ÁÍ ÎÅ ÎÕÖÎÏ ÔÒÏÇÁÔØ ÜÔÏÔ ÆÁÊÌ. ðÒÏÃÅÄÕÒÁ ïÔÒÅÄÁËÔÉÒÕÊÔÅ ÆÁÊÌ access ÔÁË, ÞÔÏÂÙ ÏÎ ÓÏÄÅÒÖÁÌ ÔÏÌØËÏ ×ÁÛÅ ÉÍÑ ÐÏÌØÚÏ×ÁÔÅÌÑ. ïÔÒÅÄÁËÔÉÒÕÊÔÅ cvswrap.c ÔÁË, ÞÔÏÂÙ ÏÎ ÓÏÄÅÒÖÁÌ ÐÒÁ×ÉÌØÎÙÊ ÍÁÒÛÒÕÔ ÄÌÑ ×ÁÛÅÊ ÎÁÓÔÒÏÊËÉ. üÔÏ ÏÐÒÅÄÅÌÅÎÏ × ÍÁËÒÏÓÅ ÐÏ ÉÍÅÎÉ ACCESS. ÷Ù ÄÏÌÖÎÙ ÔÁËÖÅ ÉÚÍÅÎÉÔØ ÒÁÓÐÏÌÏÖÅÎÉÅ ÒÅÁÌØÎÏÇÏ ×ÙÐÏÌÎÉÍÏÇÏ ÆÁÊÌÁ cvs, ÅÓÌÉ ÏÎÏ ÎÅ ÐÏÄÈÏÄÉÔ Ë ×ÁÛÅÊ ÓÉÔÕÁÃÉÉ. äÌÑ ÓÔÁÎÄÁÒÔÎÏÇÏ cvswrap.c ÐÒÅÄÐÏÌÁÇÁÅÔÓÑ, ÞÔÏ ÏÎ ÚÁÍÅÎÉÔ ÏÂÝÅÓÉÓÔÅÍÎÕÀ ËÏÍÁÎÄÕ cvs, ËÏÔÏÒÁÑ ÂÕÄÅÔ ÐÅÒÅÍÅÝÅÎÁ × /usr/bin/ncvs. ÷ ÍÏ£Í ÜËÚÅÍÐÌÑÒÅ cvswrap.c ÐÏÍÅÝÅÎÏ ÓÌÅÄÕÀÝÅÅ: #define ACCESS "/local/cvsroot/CVSROOT/access" #define REALCVS "/usr/bin/ncvs" óÌÅÄÕÀÝÉÍ ÛÁÇÏÍ Ñ×ÌÑÅÔÓÑ ÕÓÔÁÎÏ×ËÁ ÏÂÒÁÂÏÔÞÉËÁ ÄÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÐÒÏ×ÅÒÉÔØ ÐÒÁ×ÉÌØÎÏÓÔØ ÕÓÔÁÎÏ×ËÉ ÇÒÕÐÐÙ ÐÒÉ ×ÙÐÏÌÎÅÎÉÉ ËÏÍÍÉÔÁ. éÓÈÏÄÎÙÅ ÔÅËÓÔÙ ÄÌÑ ÜÔÏÇÏ ÒÁÚÍÅÝÅÎÙ × cvswrap.c ÉÚ ×ÁÛÅÇÏ CVSROOT. ïÔËÏÍÐÉÌÉÒÕÊÔÅ ÉÓÈÏÄÎÙÅ ÔÅËÓÔÙ, ËÏÔÏÒÙÅ ×Ù ÒÅÄÁËÔÉÒÏ×ÁÌÉ ÄÌÑ ×ËÌÀÞÅÎÉÑ ÐÒÁ×ÉÌØÎÙÈ ÐÕÔÅÊ: &prompt.user; cc -o cvs cvswrap.c á ÚÁÔÅÍ ÕÓÔÁÎÏ×ÉÔÅ ÉÈ (ÄÌÑ ÜÔÏÇÏ ×Ù ÄÏÌÖÎÙ ÂÙÔØ ÐÏÌØÚÏ×ÁÔÅÌÅÍ root): &prompt.root; mv /usr/bin/cvs /usr/bin/ncvs &prompt.root; mv cvs /usr/bin/cvs &prompt.root; chown root:ncvs /usr/bin/cvs /usr/bin/ncvs &prompt.root; chmod o-rx /usr/bin/ncvs &prompt.root; chmod u-w,g+s /usr/bin/cvs ðÒÉ ÜÔÏÍ ÏÂÒÁÂÏÔÞÉË ÂÕÄÅÔ ÕÓÔÁÎÏ×ÌÅÎ ÐÏ ÕÍÏÌÞÁÎÉÀ ËÁË ËÏÍÁÎÄÁ cvs, ÞÔÏ ÇÁÒÁÎÔÉÒÕÅÔ ×ÓÅÍÉ, ÉÓÐÏÌØÚÕÀÝÉÍÉ ÈÒÁÎÉÌÉÝÅ, ÐÏÌÕÞÅÎÉÅ ÐÒÁ×ÉÌØÎÙÈ ÕÒÏ×ÎÅÊ ÄÏÓÔÕÐÁ. ôÅÐÅÒØ ×Ù ÍÏÖÅÔÅ ÕÂÒÁÔØ ×ÓÅÈ ÉÚ ×ÁÛÅÊ ÇÒÕÐÐÙ ÈÒÁÎÉÌÉÝÁ. ÷Ó£ ÕÐÒÁ×ÌÅÎÉÅ ÄÏÓÔÕÐÏÍ ×ÙÐÏÌÎÑÅÔÓÑ ×ÁÛÉÍ ÏÂÒÁÂÏÔÞÉËÏÍ, É ÏÎ ÂÕÄÅÔ ÕÓÔÁÎÁ×ÌÉ×ÁÔØ ÐÒÁ×ÉÌØÎÕÀ ÇÒÕÐÐÕ ÄÌÑ ÄÏÓÔÕÐÁ. ôÅÓÔÉÒÏ×ÁÎÉÅ ÎÁÓÔÒÏÊËÉ ôÅÐÅÒØ ×ÁÛ ÏÂÒÁÂÏÔÞÉË ÄÏÌÖÅÎ ÂÙÔØ ÕÓÔÁÎÏ×ÌÅÎ. ëÏÎÅÞÎÏ, ×Ù ÍÏÖÅÔÅ ÐÒÏÔÅÓÔÉÒÏ×ÁÔØ ÅÇÏ, ×ÙÐÏÌÎÉ× ÐÒÉÎÕÄÉÔÅÌØÎÙÊ ËÏÍÍÉÔ × ÆÁÊÌ access: &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' access é ÓÎÏ×Á, ÅÓÌÉ ÜÔÏ ÎÅ ÓÒÁÂÏÔÁÅÔ, ÐÒÏ×ÅÒØÔÅ, ÐÒÁ×ÉÌØÎÏ ÌÉ ÂÙÌÉ ×ÙÐÏÌÎÅÎÙ ×ÓÅ ×ÙÛÅÐÅÒÅÞÉÓÌÅÎÎÙÅ ÛÁÇÉ.
diff --git a/ru_RU.KOI8-R/articles/hubs/article.xml b/ru_RU.KOI8-R/articles/hubs/article.xml index 996870ba5b..7354c78e81 100644 --- a/ru_RU.KOI8-R/articles/hubs/article.xml +++ b/ru_RU.KOI8-R/articles/hubs/article.xml @@ -1,1170 +1,1170 @@
ðÏÄÄÅÒÖËÁ ÚÅÒËÁÌ FreeBSD Jun Kuriyama
kuriyama@FreeBSD.org
Valentino Vaschetto
logo@FreeBSD.org
Daniel Lang
dl@leo.org
Ken Smith
kensmith@FreeBSD.org
äÍÉÔÒÉÊ íÏÒÏÚÏ×ÓËÉÊ ðÅÒÅ×ÏÄ ÎÁ ÒÕÓÓËÉÊ ÑÚÙË:
&tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.general; $FreeBSD$ $FreeBSD$ òÁÂÏÞÉÊ ×ÁÒÉÁÎÔ ÓÔÁÔØÉ, ÏÐÉÓÙ×ÁÀÝÅÊ ÐÒÏÃÅÓÓ ÓÏÚÄÁÎÉÑ É ÐÏÄÄÅÒÖËÉ ÚÅÒËÁÌÁ FreeBSD É ÁÄÒÅÓÏ×ÁÎÎÏÊ ÁÄÍÉÎÉÓÔÒÁÔÏÒÁÍ ÚÅÒËÁÌ.
îÁ ÔÅËÕÝÉÊ ÍÏÍÅÎÔ ÚÁÑ×ËÉ ÎÁ ÐÏÄËÌÀÞÅÎÉÅ ÎÏ×ÙÈ ÚÅÒËÁÌ ÎÅ ÐÒÉÎÉÍÁÀÔÓÑ. ëÏÎÔÁËÔÎÁÑ ÉÎÆÏÒÍÁÃÉÑ ëÏÏÒÄÉÎÁÔÏÒÙ ÓÉÓÔÅÍÙ ÚÅÒËÁÌ ÄÏÓÔÕÐÎÙ ÐÏ ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÅ ÐÏ ÁÄÒÅÓÕ mirror-admin@FreeBSD.org. ðÏÍÉÍÏ ÜÔÏÇÏ, ÓÕÝÅÓÔ×ÕÅÔ &a.hubs;. ôÒÅÂÏ×ÁÎÉÑ Ë ÚÅÒËÁÌÁÍ FreeBSD äÉÓËÏ×ÏÅ ÐÒÏÓÔÒÁÎÓÔ×Ï ïÄÎÉÍ ÉÚ ÎÁÉÂÏÌÅÅ ×ÁÖÎÙÈ ÔÒÅÂÏ×ÁÎÉÊ Ñ×ÌÑÅÔÓÑ ÄÉÓËÏ×ÏÅ ÐÒÏÓÔÒÁÎÓÔ×Ï. ÷ ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÎÁÂÏÒÁ ÒÅÌÉÚÏ×, ÁÒÈÉÔÅËÔÕÒ É ÓÔÅÐÅÎÉ ÐÏÌÎÏÔÙ ÚÅÒËÁÌÁ ×ÁÍ ÍÏÖÅÔ ÐÏÔÒÅÂÏ×ÁÔØÓÑ ÏÇÒÏÍÎÙÊ ÏÂßÅÍ ÄÉÓËÁ. îÅ ÌÉÛÎÉÍ ÂÕÄÅÔ ÐÏÍÎÉÔØ, ÞÔÏ ÏÆÉÃÉÁÌØÎÏÅ ÚÅÒËÁÌÏ, ÓËÏÒÅÅ ×ÓÅÇÏ, ÄÏÌÖÎÏ ÂÙÔØ ÐÏÌÎÙÍ. òÅÐÏÚÉÔÏÒÉÊ CVS É ×ÅÂ-ÓÔÒÁÎÉÃÙ ×ÓÅÇÄÁ ÄÏÌÖÎÙ ÚÅÒËÁÌÉÒÏ×ÁÔØÓÑ ÐÏÌÎÏÓÔØÀ. ëÒÏÍÅ ÔÏÇÏ, ÕÞÔÉÔÅ, ÞÔÏ ÐÒÉ×ÏÄÉÍÙÅ ÏÃÅÎËÉ ÏÂßÅÍÁ ÏÔÎÏÓÑÔÓÑ Ë ÓÏÓÔÏÑÎÉÀ ÎÁ ÍÏÍÅÎÔ ÐÏÓÌÅÄÎÅÇÏ ÒÅÄÁËÔÉÒÏ×ÁÎÉÑ ÄÁÎÎÏÊ ÓÔÁÔØÉ (&rel2.current;-RELEASE/&rel.current;-RELEASE). äÁÌØÎÅÊÛÉÊ ÐÒÏÃÅÓÓ ÒÁÚÒÁÂÏÔËÉ É ÐÏÓÌÅÄÕÀÝÉÅ ÒÅÌÉÚÙ ÔÏÌØËÏ Õ×ÅÌÉÞÁÔ ÔÒÅÂÕÅÍÙÊ ÏÂßÅÍ. ëÒÏÍÅ ÔÏÇÏ, ÒÁÚÕÍÎÏ ÂÕÄÅÔ ÚÁÒÅÚÅÒ×ÉÒÏ×ÁÔØ ÎÅËÏÔÏÒÏÅ (10-20%) ÄÏÐÏÌÎÉÔÅÌØÎÏÅ ÐÒÏÓÔÒÁÎÓÔ×Ï ÓÐÏËÏÊÓÔ×ÉÑ ÒÁÄÉ. ÷ÏÔ ÎÅËÏÔÏÒÙÅ ÏÃÅÎËÉ ÏÂßÅÍÁ: ðÏÌÎÏÅ ÚÅÒËÁÌÏ FTP: 1.0 TB òÅÐÏÚÉÔÏÒÉÊ CVS: 5.4 GB ëÏÍÐÌÅËÔ ÉÚÍÅÎÅÎÉÊ CTM: 3.2 GB ÷ÅÂ-ÓÔÒÁÎÉÃÙ: 463 MB ôÅËÕÝÅÅ ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÄÉÓËÁ ÚÅÒËÁÌÏÍ FTP ÍÏÖÎÏ ÐÏÓÍÏÔÒÅÔØ ÎÁ ftp://ftp.FreeBSD.org/pub/FreeBSD/dir.sizes. ôÒÅÂÏ×ÁÎÉÑ Ë ÓÅÔÅ×ÏÊ Ó×ÑÚÎÏÓÔÉ É ÐÒÏÐÕÓËÎÏÊ ÓÐÏÓÏÂÎÏÓÔÉ òÁÚÕÍÅÅÔÓÑ, Õ ×ÁÓ ÄÏÌÖÎÏ ÂÙÔØ ÐÏÄËÌÀÞÅÎÉÅ Ë ÉÎÔÅÒÎÅÔ. ôÒÅÂÕÅÍÁÑ ÐÒÏÐÕÓËÎÁÑ ÓÐÏÓÏÂÎÏÓÔØ ×ÁÛÉÈ ËÁÎÁÌÏ× ÚÁ×ÉÓÉÔ ÏÔ ÐÒÅÄÐÏÌÁÇÁÅÍÏÇÏ ÐÒÏÆÉÌÑ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ×ÁÛÅÇÏ ÚÅÒËÁÌÁ. åÓÌÉ ×Ù ÓÏÂÉÒÁÅÔÅÓØ ËÏÐÉÒÏ×ÁÔØ ÎÅËÏÔÏÒÙÅ ÞÁÓÔÉ FreeBSD ÄÌÑ ÌÏËÁÌØÎÏÇÏ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÎÁ ×ÁÛÅÊ ÍÁÛÉÎÅ ÉÌÉ × ÉÎÔÒÁÎÅÔÅ, ÔÒÅÂÏ×ÁÎÉÑ ÍÏÇÕÔ ÂÙÔØ ÍÎÏÇÏ ÍÑÇÞÅ, ÞÅÍ ÄÌÑ ÐÕÂÌÉÞÎÏÇÏ ÚÅÒËÁÌÁ. äÌÑ ÏÆÉÃÉÁÌØÎÏÇÏ ÚÅÒËÁÌÁ ÎÅÏÂÈÏÄÉÍÁÑ ÐÒÏÐÕÓËÎÁÑ ÓÐÏÓÏÂÎÏÓÔØ Õ×ÅÌÉÞÉ×ÁÅÔÓÑ ÅÝÅ ÂÏÌØÛÅ. íÙ ÍÏÖÅÍ ÄÁÔØ ÌÉÛØ ÏÞÅÎØ ÇÒÕÂÙÅ ÏÃÅÎËÉ: úÅÒËÁÌÏ ÄÌÑ ÌÏËÁÌØÎÏÇÏ ÄÏÓÔÕÐÁ: ÆÁËÔÉÞÅÓËÉ ÍÉÎÉÍÕÍ ÎÅ ÏÐÒÅÄÅÌÅÎ, ÎÏ ËÁÎÁÌ ÛÉÒÉÎÏÊ ÍÅÎÅÅ 2 Mbps ÍÏÖÅÔ ÓÄÅÌÁÔØ ÐÒÏÃÅÓÓ ÏÂÎÏ×ÌÅÎÉÑ ÍÕÞÉÔÅÌØÎÏ ÍÅÄÌÅÎÎÙÍ. îÅÏÆÉÃÉÁÌØÎÏÅ ÐÕÂÌÉÞÎÏÅ ÚÅÒËÁÌÏ: 34 Mbps ×ÙÇÌÑÄÉÔ ÎÅÐÌÏÈÏ ÄÌÑ ÎÁÞÁÌÁ. ïÆÉÃÉÁÌØÎÏÅ ÚÅÒËÁÌÏ: ÒÅËÏÍÅÎÄÕÅÔÓÑ ËÁÎÁÌ ÛÉÒÉÎÏÊ ÂÏÌÅÅ 100 Mbps; ËÒÏÍÅ ÔÏÇÏ, ×ÁÛÁ ÍÁÛÉÎÁ ÄÏÌÖÎÁ ÓÔÏÑÔØ ËÁË ÍÏÖÎÏ ÂÌÉÖÅ Ë ÇÒÁÎÉÞÎÙÍ ÍÁÒÛÒÕÔÉÚÁÔÏÒÁÍ ×ÁÛÅÊ ÓÅÔÉ. óÉÓÔÅÍÎÙÅ ÔÒÅÂÏ×ÁÎÉÑ, ÐÒÏÃÅÓÓÏÒ É ÐÁÍÑÔØ üÔÉ ÔÒÅÂÏ×ÁÎÉÑ × ÐÅÒ×ÕÀ ÏÞÅÒÅÄØ ÏÐÒÅÄÅÌÑÀÔÓÑ ÍÁËÓÉÍÁÌØÎÙÍ ÏÖÉÄÁÅÍÙÍ ËÏÌÉÞÅÓÔ×ÏÍ ËÌÉÅÎÔÏ× (ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÓÑ ÁÄÍÉÎÉÓÔÒÁÔÏÒÏÍ ÓÅÒ×ÅÒÁ). ôÁËÖÅ, ÎÁ ÔÒÅÂÕÅÍÙÅ ÒÅÓÕÒÓÙ ×ÌÉÑÅÔ ÓÐÉÓÏË ÓÅÒ×ÉÓÏ×, ËÏÔÏÒÙÅ ×Ù ÂÕÄÅÔÅ ÐÒÅÄÏÓÔÁ×ÌÑÔØ. úÅÒËÁÌÁ FTP É/ÉÌÉ HTTP ÎÅ ÔÒÅÂÕÀÔ ÏÓÏÂÅÎÎÏ ÍÎÏÇÏ ÒÅÓÕÒÓÏ×. âÕÄØÔÅ ÎÁ ÞÅËÕ, ÅÓÌÉ ÐÌÁÎÉÒÕÅÔÅ ÐÒÅÄÏÓÔÁ×ÌÑÔØ rsync. ÷ÙÂÏÒ rsync ÍÏÖÅÔ ÉÍÅÔØ ÏÇÒÏÍÎÏÅ ×ÌÉÑÎÉÅ ÎÁ ÔÒÅÂÏ×ÁÎÉÑ Ë ÁÐÐÁÒÁÔÎÙÍ ÒÅÓÕÒÓÁÍ, ÐÏÓËÏÌØËÕ rsync ÐÒÉÚÎÁÎ "ÐÒÏÖÏÒÌÉ×ÙÍ" ÐÏ ÐÁÍÑÔÉ. ÷ÏÔ ÎÅËÏÔÏÒÙÅ ÓÏ×ÅÔÙ ÐÏ ËÏÎÆÉÇÕÒÁÃÉÉ ÁÐÐÁÒÁÔÎÏÊ ÞÁÓÔÉ ÓÅÒ×ÅÒÁ: äÌÑ ÕÍÅÒÅÎÎÏ ÐÏÓÅÝÁÅÍÏÇÏ ÓÁÊÔÁ, ÐÒÅÄÏÓÔÁ×ÌÑÀÝÅÇÏ Rsync, ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ ÐÒÏÃÅÓÓÏÒ Ó ÞÁÓÔÏÔÏÊ 800MHz - 1 GHz É ÐÏ ËÒÁÊÎÅÊ ÍÅÒÅ 512MB ÐÁÍÑÔÉ. óËÏÒÅÅ ×ÓÅÇÏ, ÄÁÎÎÁÑ ËÏÎÆÉÇÕÒÁÃÉÑ ÍÏÖÅÔ ÓÞÉÔÁÔØÓÑ ÍÉÎÉÍÁÌØÎÏÊ ÄÌÑ ÏÆÉÃÉÁÌØÎÏÇÏ ÚÅÒËÁÌÁ. äÌÑ ÒÅÇÕÌÑÒÎÏ ÐÏÓÅÝÁÅÍÏÇÏ ÓÁÊÔÁ ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÂÏÌØÛÅ ÐÁÍÑÔÉ (ÈÏÒÏÛÉÍ ÓÔÁÒÔÏÍ ÂÕÄÅÔ 2GB) É ÂÏÌØÛÅ ÐÒÏÃÅÓÓÏÒÎÏÊ ÍÏÝÎÏÓÔÉ, ÞÔÏ ÍÏÖÅÔ ÏÚÎÁÞÁÔØ ÔÒÅÂÏ×ÁÎÉÅ ÍÎÏÇÏÐÒÏÃÅÓÓÏÒÎÏÊ (SMP) ÐÌÁÔÆÏÒÍÙ. ëÒÏÍÅ ÔÏÇÏ, ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÂÙÓÔÒÁÑ ÄÉÓËÏ×ÁÑ ÐÏÄÓÉÓÔÅÍÁ, × ÐÅÒ×ÕÀ ÏÞÅÒÅÄØ, ÄÌÑ ÒÁÂÏÔÙ Ó ÒÅÐÏÚÉÔÏÒÉÅÍ CVS (ËÒÁÊÎÅ ÒÅËÏÍÅÎÄÕÅÍ RAID). ëÏÎÔÒÏÌÌÅÒ SCSI, ÏÂÏÒÕÄÏ×ÁÎÎÙÊ ÓÏÂÓÔ×ÅÎÎÏÊ ÐÁÍÑÔØÀ, ÔÁËÖÅ ÍÏÖÅÔ ÏÝÕÔÉÍÏ ÕÓËÏÒÉÔØ ÐÒÏÃÅÓÓ, ÐÏÓËÏÌØËÕ ÂÏÌØÛÁÑ ÞÁÓÔØ ÓÅÒ×ÉÓÏ× Ó×ÑÚÁÎÁ Ó ÂÏÌØÛÉÍ ËÏÌÉÞÅÓÔ×ÏÍ ÄÉÓËÏ×ÙÈ ÚÁÐÒÏÓÏ× ÎÅÂÏÌØÛÏÇÏ ÒÁÚÍÅÒÁ. ðÒÅÄÏÓÔÁ×ÌÑÅÍÙÅ ÓÅÒ×ÉÓÙ ÷ÓÑËÏÅ ÚÅÒËÁÌÏ ÄÏÌÖÎÏ ÐÒÅÄÏÓÔÁ×ÌÑÔØ ÎÁÂÏÒ ÏÓÎÏ×ÎÙÈ ÓÅÒ×ÉÓÏ×. ðÏÍÉÍÏ ÔÒÅÂÕÅÍÏÇÏ ÍÉÎÉÍÁÌØÎÏÇÏ ÎÁÂÏÒÁ, ÓÕÝÅÓÔ×ÕÀÔ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ÓÅÒ×ÉÓÙ, ËÏÔÏÒÙÅ ÁÄÍÉÎÉÓÔÒÁÔÏÒ ÓÅÒ×ÅÒÁ ÍÏÖÅÔ ÐÏÖÅÌÁÔØ ÐÒÅÄÏÓÔÁ×ÌÑÔØ. üÔÏÔ ÒÁÚÄÅÌ ÏÐÉÓÙ×ÁÅÔ, ËÁËÉÅ ÓÅÒ×ÉÓÙ ×Ù ÍÏÖÅÔÅ ÐÒÅÄÏÓÔÁ×ÌÑÔØ, É ËÁËÉÅ ÄÅÊÓÔ×ÉÑ ÄÌÑ ÜÔÏÇÏ ÐÏÔÒÅÂÕÀÔÓÑ ÏÔ ×ÁÓ. FTP (ÔÒÅÂÕÅÔÓÑ ÄÌÑ FTP ÚÅÒËÁÌÁ) üÔÏ ÏÄÉÎ ÉÚ ÎÁÉÂÏÌÅÅ ÂÁÚÏ×ÙÈ ÓÅÒ×ÉÓÏ×; ÅÇÏ ÐÒÅÄÏÓÔÁ×ÌÅÎÉÅ ÔÒÅÂÕÅÔÓÑ ÄÌÑ ËÁÖÄÏÇÏ ÚÅÒËÁÌÁ, ÒÁÓÐÒÏÓÔÒÁÎÑÀÝÅÇÏ ÆÁÊÌÙ FreeBSD ÐÏ FTP. äÏÓÔÕÐ ÐÏ FTP ÄÏÌÖÅÎ ÂÙÔØ ÁÎÏÎÉÍÎÙÍ, É ÎÅ ÄÏÌÖÎÙ ÐÒÉÍÅÎÑÔØÓÑ ËÁËÉÅ-ÌÉÂÏ ÏÇÒÁÎÉÞÅÎÉÑ ÐÏ ÓÏÏÔÎÏÛÅÎÉÀ ÏÂßÅÍÁ ÐÅÒÅÄÁÎÏ/ÐÒÉÎÑÔÏ (ÞÔÏ ×ÏÏÂÝÅ Ñ×ÌÑÅÔÓÑ, ÎÁ ÎÁÛ ×ÚÇÌÑÄ, ÓÔÒÁÎÎÙÍ ÐÏÄÈÏÄÏÍ). úÁËÁÞËÁ (upload) ÆÁÊÌÏ× ÎÁ ÓÅÒ×ÅÒ ÎÅ ÔÒÅÂÕÅÔÓÑ (É ÄÏÌÖÎÁ ÂÙÔØ ÚÁÐÒÅÝÅÎÁ × ÒÁÚÄÅÌÅ FreeBSD). ëÒÏÍÅ ÔÏÇÏ, ÁÒÈÉ× ÆÁÊÌÏ× FreeBSD ÄÏÌÖÅÎ ÂÙÔØ ÄÏÓÔÕÐÅÎ Ó ÐÕÔÅÍ /pub/FreeBSD. äÌÑ ÐÒÅÄÏÓÔÁ×ÌÅÎÉÑ ÁÎÏÎÉÍÎÏÇÏ FTP ÄÏÓÔÕÐÁ ÍÏÖÅÔ ÂÙÔØ ÉÓÐÏÌØÚÏ×ÁÎ ÃÅÌÙÊ ÒÑÄ ÐÒÏÇÒÁÍÍ (ÐÅÒÅÞÉÓÌÅÎÙ × ÁÌÆÁ×ÉÔÎÏÍ ÐÏÒÑÄËÅ): /usr/libexec/ftpd: ÂÁÚÏ×ÙÊ FTP-ÄÁÅÍÏÎ FreeBSD. îÅ ÚÁÂÕÄØÔÅ ÐÒÏÞÉÔÁÔØ &man.ftpd.8;. ftp/ncftpd: ËÏÍÍÅÒÞÅÓËÉÊ ÐÁËÅÔ, Ó×ÏÂÏÄÅÎ ÄÌÑ ÉÓÐÏÌØÚÏ×ÁÎÉÑ × ÕÞÅÂÎÙÈ ÃÅÌÑÈ. ftp/oftpd: FTP-ÄÁÅÍÏÎ, ÎÁÐÉÓÁÎÎÙÊ × ÏÓÎÏ×ÎÏÍ Ó ÔÏÞËÉ ÚÒÅÎÉÑ ÚÁÝÉÝÅÎÎÏÓÔÉ. ftp/proftpd: íÏÄÕÌØÎÙÊ É ÏÞÅÎØ ÇÉÂËÉÊ FTP-ÄÁÅÍÏÎ. ftp/pure-ftpd: åÝÅ ÏÄÉÎ FTP-ÄÁÅÍÏÎ, ÒÁÚÒÁÂÏÔÁÎÎÙÊ Ó ÐÏÚÉÃÉÊ ÚÁÝÉÝÅÎÎÏÓÔÉ. ftp/twoftpd: óÍ. ÐÒÅÄÙÄÕÝÉÊ ÐÕÎËÔ. ftp/vsftpd: ÏÞÅÎØ ÚÁÝÉÝÅÎÎÙÊ (very secure) ftpd. ftp/wu-ftpd: ftpd ÏÔ ÷ÁÛÉÎÇÔÏÎÓËÏÇÏ õÎÉ×ÅÒÓÉÔÅÔÁ (Washington University). îÅÓËÏÌØËÏ ÐÏÔÅÒÑÌ ÐÏÐÕÌÑÒÎÏÓÔØ ÉÚ-ÚÁ ÂÏÌØÛÏÇÏ ËÏÌÉÞÅÓÔ×Á ÎÁÊÄÅÎÎÙÈ × ÐÒÏÛÌÏÍ ÏÛÉÂÏË ÚÁÝÉÔÙ. åÓÌÉ ×Ù ÒÅÛÉÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÅÇÏ, ÐÏÍÎÉÔÅ Ï ÎÅÏÂÈÏÄÉÍÏÓÔÉ ÏÔÓÌÅÖÉ×ÁÎÉÑ ÏÂÎÏ×ÌÅÎÉÊ. ftpd, proftpd, wu-ftpd É, ×ÏÚÍÏÖÎÏ, ncftpd Ñ×ÌÑÀÔÓÑ ÎÁÉÂÏÌÅÅ ÞÁÓÔÏ ×ÓÔÒÅÞÁÀÝÉÍÉÓÑ FTP ÓÅÒ×ÅÒÁÍÉ. ðÒÏÞÉÅ ÒÁÓÐÒÏÓÔÒÁÎÅÎÙ ÓÒÅÄÉ ÓÕÝÅÓÔ×ÕÀÝÉÈ ÚÅÒËÁÌ × ÓÕÝÅÓÔ×ÅÎÎÏ ÍÅÎØÛÅÊ ÓÔÅÐÅÎÉ. äÏÐÏÌÎÉÔÅÌØÎÙÍ ÐÏ×ÏÄÏÍ ÄÌÑ ÒÁÓÓÍÏÔÒÅÎÉÑ ÍÏÖÅÔ Ñ×ÌÑÔØÓÑ ×ÏÚÍÏÖÎÏÓÔØ ÇÉÂËÏ ÏÇÒÁÎÉÞÉ×ÁÔØ ËÏÌÉÞÅÓÔ×Ï ÏÄÎÏ×ÒÅÍÅÎÎÙÈ ÓÏÅÄÉÎÅÎÉÊ, ÞÔÏ ÐÏÍÏÖÅÔ ×ÁÍ ÕÄÅÒÖÁÔØ × ÎÕÖÎÙÈ ÒÁÍËÁÈ ÐÏÔÒÅÂÌÅÎÉÅ ÐÒÏÐÕÓËÎÏÊ ÓÐÏÓÏÂÎÏÓÔÉ ×ÁÛÉÈ ËÁÎÁÌÏ× É ÍÁÛÉÎÎÙÅ ÒÅÓÕÒÓÙ. Rsync (ÎÅÏÂÑÚÁÔÅÌØÎÙÊ ÓÅÒ×ÉÓ ÄÌÑ FTP ÚÅÒËÁÌÁ) Rsync ÞÁÓÔÏ ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÐÒÅÄÏÓÔÁ×ÌÅÎÉÑ ÄÏÓÔÕÐÁ Ë FTP-ÏÂÌÁÓÔÉ FreeBSD, ÞÔÏÂÙ ÄÒÕÇÉÅ ÚÅÒËÁÌÁ ÍÏÇÌÉ ÓÉÎÈÒÏÎÉÚÉÒÏ×ÁÔØÓÑ ÐÏ ×ÁÛÅÍÕ. ðÒÏÔÏËÏÌ rsync ×Ï ÍÎÏÇÏÍ ÏÔÌÉÞÁÅÔÓÑ ÏÔ FTP, × ÞÁÓÔÎÏÓÔÉ, ÏÎ ÇÏÒÁÚÄÏ ÇÕÍÁÎÎÅÅ Ó ÔÏÞËÉ ÚÒÅÎÉÑ ÐÒÏÐÕÓËÎÏÊ ÓÐÏÓÏÂÎÏÓÔÉ ËÁÎÁÌÏ×, ÐÏÓËÏÌØËÕ ÎÅ ÔÒÅÂÕÅÔ ÐÅÒÅÄÁÞÉ ÉÚÍÅÎÅÎÎÏÇÏ ÆÁÊÌÁ ÃÅÌÉËÏÍ (ÐÅÒÅÄÁÀÔÓÑ ÌÉÛØ ÒÁÚÌÉÞÉÑ). ÷ÚÁÍÅÎ Rsync ÔÒÅÂÕÅÔ ÚÎÁÞÉÔÅÌØÎÙÈ ÏÂßÅÍÏ× ÐÁÍÑÔÉ. òÁÚÍÅÒ ËÁÖÄÏÇÏ ÐÒÏÃÅÓÓÁ ÚÁ×ÉÓÉÔ ÏÔ ÒÁÚÍÅÒÁ ÓÉÎÈÒÏÎÉÚÉÒÕÅÍÏÇÏ ÍÏÄÕÌÑ (× ÏÓÎÏ×ÎÏÍ ÏÔ ËÏÌÉÞÅÓÔ×Á ÄÉÒÅËÔÏÒÉÊ É ÆÁÊÌÏ×). Rsync ÍÏÖÅÔ ÉÓÐÏÌØÚÏ×ÁÔØ × ËÁÞÅÓÔ×Å ÔÒÁÎÓÐÏÒÔÎÏÇÏ ÐÒÏÔÏËÏÌÁ rsh ÉÌÉ ssh (ÐÏ ÕÍÏÌÞÁÎÉÀ); ÔÁËÖÅ, ÍÏÖÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ×ÎÕÔÒÅÎÎÉÊ ÐÒÏÔÏËÏÌ rsync (ÜÔÏÔ ÍÅÔÏÄ ÐÒÅÄÐÏÞÔÉÔÅÌÅÎ ÄÌÑ ÐÕÂÌÉÞÎÙÈ rsync-ÓÅÒ×ÅÒÏ×). ðÏÄÄÅÒÖÉ×ÁÅÔÓÑ Á×ÔÏÒÉÚÁÃÉÑ ËÌÉÅÎÔÏ× É ÒÁÚÌÉÞÎÙÅ ÏÇÒÁÎÉÞÅÎÉÑ. äÌÑ ÐÒÏÔÏËÏÌÁ rsync ÓÕÝÅÓÔ×ÕÅÔ ÅÄÉÎÓÔ×ÅÎÎÙÊ ÐÁËÅÔ: net/rsync HTTP (ÔÒÅÂÕÅÔÓÑ ÄÌÑ ×ÅÂ-ÓÔÒÁÎÉÃ, ÄÏÐÏÌÎÉÔÅÌÅÎ ÄÌÑ FTP ÚÅÒËÁÌ) åÓÌÉ ×Ù ÈÏÔÉÔÅ ÐÏÄÄÅÒÖÉ×ÁÔØ ÚÅÒËÁÌÏ ×ÅÂ-ÓÔÒÁÎÉà FreeBSD, ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÕÓÔÁÎÏ×ÉÔØ ×ÅÂ-ÓÅÒ×ÅÒ. äÏÐÏÌÎÉÔÅÌØÎÏ, ×Ù ÍÏÖÅÔÅ ÐÒÅÄÏÓÔÁ×ÌÑÔØ HTTP ÄÏÓÔÕÐ Ë FTP-ÎÁÂÏÒÕ ÆÁÊÌÏ× FreeBSD. ÷ÙÂÏÒ ×ÅÂ-ÓÅÒ×ÅÒÁ ÏÓÔÁÅÔÓÑ ÎÁ ÕÓÍÏÔÒÅÎÉÅ ÁÄÍÉÎÉÓÔÒÁÔÏÒÁ ÚÅÒËÁÌÁ. îÅËÏÔÏÒÙÅ ÉÚ ÎÁÉÂÏÌÅÅ ÐÏÐÕÌÑÒÎÙÈ ×ÅÂ-ÓÅÒ×ÅÒÏ× ÐÅÒÅÞÉÓÌÅÎÙ ÎÉÖÅ. www/apache13: Apache — ÓÁÍÙÊ ÛÉÒÏËÏ ÒÁÓÐÒÏÓÔÒÁΣÎÎÙÊ × éÎÔÅÒÎÅÔÅ ×ÅÂ-ÓÅÒ×ÅÒ, ÁËÔÉ×ÎÏ ÉÓÐÏÌØÚÕÅÍÙÊ ÐÒÏÅËÔÏÍ FreeBSD. ÷Ù ÍÏÖÅÔÅ ÔÁËÖÅ ÉÓÐÏÌØÚÏ×ÁÔØ ×ÅÂ-ÓÅÒ×ÅÒ Apache ÓÌÅÄÕÀÝÅÇÏ ÐÏËÏÌÅÎÉÑ, ÄÏÓÔÕÐÎÙÊ × ËÏÌÌÅËÃÉÉ ÐÏÒÔÏ× ËÁË www/apache22. www/thttpd: äÌÑ ÏÂÓÌÕÖÉ×ÁÎÉÑ ÂÏÌØÛÏÇÏ ËÏÌÉÞÅÓÔ×Á ÚÁÐÒÏÓÏ× Ë ÓÔÁÔÉÞÅÓËÉÍ ÄÏËÕÍÅÎÔÁÍ ÓÅÒ×ÅÒ thttpd ÍÏÖÅÔ ÏËÁÚÁÔØÓÑ ÂÏÌÅÅ ÜÆÆÅËÔÉ×ÎÙÍ, ÞÅÍ Apache. thttpd ÏÔÌÉÞÎÏ ÏÐÔÉÍÉÚÉÒÏ×ÁÎ ÐÏ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ ÐÒÉ ÒÁÂÏÔÅ ÐÏÄ FreeBSD. www/boa: Boa — ÅÝÅ ÏÄÎÁ ÁÌØÔÅÒÎÁÔÉ×Á thttpd É Apache. üÔÏÔ ÓÅÒ×ÅÒ ÄÏÌÖÅÎ ÂÙÔØ ÏÝÕÔÉÍÏ ÂÏÌÅÅ ×ÙÓÏËÏÐÒÏÉÚ×ÏÄÉÔÅÌØÎÙÍ, ÞÅÍ Apache, ÄÌÑ ÐÏÌÎÏÓÔØÀ ÓÔÁÔÉÞÅÓËÉÈ ÓÔÒÁÎÉÃ. îÁ ×ÒÅÍÑ ÎÁÐÉÓÁÎÉÑ ÄÁÎÎÏÇÏ ÄÏËÕÍÅÎÔÁ, ×ÐÒÏÞÅÍ, ÏÎ ÎÅ ÔÁË ÈÏÒÏÛÏ ÏÐÔÉÍÉÚÉÒÏ×ÁÎ ÐÏÄ FreeBSD, ËÁË thttpd. CVSup (ÖÅÌÁÔÅÌÅÎ ÄÌÑ ÚÅÒËÁÌ ÒÅÐÏÚÉÔÏÒÉÑ CVS) CVSup ÐÒÅÄÏÓÔÁ×ÌÑÅÔ ÏÞÅÎØ ÜÆÆÅËÔÉ×ÎÙÊ ÍÅÈÁÎÉÚÍ ÒÁÓÐÒÏÓÔÒÁÎÅÎÉÑ ÆÁÊÌÏ×. ïÎ ÒÁÂÏÔÁÅÔ ÐÏÄÏÂÎÏ rsync É ÂÙÌ ÒÁÚÒÁÂÏÔÁÎ ÓÐÅÃÉÁÌØÎÏ ÄÌÑ ÉÓÐÏÌØÚÏ×ÁÎÉÑ Ó ÒÅÐÏÚÉÔÏÒÉÑÍÉ CVS. åÓÌÉ ×Ù ÐÌÁÎÉÒÕÅÔÅ ÐÒÅÄÏÓÔÁ×ÌÑÔØ ÄÏÓÔÕÐ Ë ÒÅÐÏÚÉÔÏÒÉÀ CVS FreeBSD, ÓÔÏÉÔ ÄÅÌÁÔØ ÜÔÏ ÐÏÓÒÅÄÓÔ×ÏÍ CVSup. ðÏÍÉÍÏ ÜÔÏÇÏ, ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ AnonCVS, FTP, rsync ÉÌÉ HTTP, ÎÏ ÉÓÐÏÌØÚÏ×ÁÎÉÅ CVSup ÎÁÉÂÏÌÅÅ ÒÁÚÕÍÎÏ. á×ÔÏÒÏÍ CVSup Ñ×ÌÑÅÔÓÑ &a.jdp.email;. CVSup ÎÅÐÒÏÓÔÏ ÕÓÔÁÎÏ×ÉÔØ ÎÁ ÐÌÁÔÆÏÒÍÅ, ÏÔÌÉÞÎÏÊ ÏÔ FreeBSD, ÐÏÓËÏÌØËÕ ÏÎ ÎÁÐÉÓÁÎ ÎÁ ÑÚÙËÅ Modula-3 É ÔÒÅÂÕÅÔ - ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÇÏ ÏËÒÕÖÅÎÉÑ. äÖÏÎ ðÏÌÓÔÒÁ ÓÏÚÄÁÌ ÕÓÅÞÅÎÎÕÀ ×ÅÒÓÉÀ M3, + ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÇÏ ÏËÒÕÖÅÎÉÑ. &a.jdp; ÓÏÚÄÁÌ ÕÓÅÞÅÎÎÕÀ ×ÅÒÓÉÀ M3, ÄÏÓÔÁÔÏÞÎÕÀ ÄÌÑ ÒÁÂÏÔÙ CVSup, ËÏÔÏÒÕÀ ÎÁÍÎÏÇÏ ÐÒÏÝÅ ÕÓÔÁÎÏ×ÉÔØ. ðÏÄÒÏÂÎÏÓÔÉ ÍÏÖÎÏ ÐÒÏÞÉÔÁÔØ ÚÄÅÓØ: Ezm3. ïÔÎÏÓÑÝÉÅÓÑ Ë ÔÅÍÅ ÐÁËÅÔÙ: net/cvsup: ðÏÒÔ CVSup (ËÌÉÅÎÔ É ÓÅÒ×ÅÒ), ÔÒÅÂÕÀÝÉÊ ÄÌÑ ÓÂÏÒËÉ ÐÁËÅÔ lang/ezm3. net/cvsup-mirror: îÁÂÏÒ ÄÌÑ CVSup-ÚÅÒËÁÌÁ, ÔÒÅÂÕÀÝÉÊ net/cvsup-without-gui, É ËÏÎÆÉÇÕÒÉÒÕÀÝÉÊ ÅÇÏ × ÐÒÏÃÅÓÓÅ ÕÓÔÁÎÏ×ËÉ. ÷ÏÚÍÏÖÎÏ, ÎÅËÏÔÏÒÙÍ ÁÄÍÉÎÉÓÔÒÁÔÏÒÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÄÒÕÇÏÊ ÎÁÂÏÒ ÕÓÔÁÎÏ×ÏË. íÏÖÅÔ ÔÁËÖÅ ÏËÁÚÁÔØÓÑ ÐÏÌÅÚÎÙÍ ÐÁËÅÔ net/cvsup-without-gui. åÓÌÉ ×Ù ÐÒÅÄÐÏÞÉÔÁÅÔÅ ÐÁËÅÔ, ÓÏÂÒÁÎÎÙÊ ÓÔÁÔÉÞÅÓËÉ, ÚÁÇÌÑÎÉÔÅ ÐÏ ÜÔÏÊ ÓÓÙÌËÅ. üÔÁ ÓÔÒÁÎÉÃÁ ×ÓÅ ÅÝÅ ÏÐÉÓÙ×ÁÅÔ ÏÛÉÂËÕ S1G. ÷ÏÚÍÏÖÎÏ, × ÂÕÄÕÝÅÍ äÖÏÎ ÓÏÚÄÁÓÔ ÕÎÉ×ÅÒÓÁÌØÎÙÊ ÓÁÊÔ ÄÌÑ ÚÁÇÒÕÚËÉ ÓÔÁÔÉÞÅÓËÉ ÓÏÂÒÁÎÎÙÈ ×ÁÒÉÁÎÔÏ× CVSup ÄÌÑ ÒÁÚÌÉÞÎÙÈ ÐÌÁÔÆÏÒÍ. ðÒÉ ÐÏÍÏÝÉ CVSup ÍÏÖÎÏ ÒÁÓÐÒÏÓÔÒÁÎÑÔØ ÌÀÂÙÅ ËÏÌÌÅËÃÉÉ ÆÁÊÌÏ× (ÎÅ ÔÏÌØËÏ ÒÅÐÏÚÉÔÏÒÉÉ CVS), ÏÄÎÁËÏ ÅÇÏ ËÏÎÆÉÇÕÒÁÃÉÑ ÍÏÖÅÔ ÂÙÔØ ÎÅÐÒÏÓÔÏÊ. éÚ×ÅÓÔÎÏ, ÞÔÏ CVSup ÐÏÔÒÅÂÌÑÅÔ ÏÝÕÔÉÍÏÅ ËÏÌÉÞÅÓÔ×Ï ÐÒÏÃÅÓÓÏÒÎÏÇÏ ×ÒÅÍÅÎÉ ËÁË ÎÁ ÓÅÒ×ÅÒÅ, ÔÁË É ÎÁ ËÌÉÅÎÔÅ, ÐÏÓËÏÌØËÕ ÓÒÁ×ÎÉ×ÁÅÔ ÂÏÌØÛÏÅ ËÏÌÉÞÅÓÔ×Ï ÆÁÊÌÏ×. AnonCVS (ÄÏÐÏÌÎÉÔÅÌÅÎ ÄÌÑ ÚÅÒËÁÌ ÒÅÐÏÚÉÔÏÒÉÑ CVS) åÓÌÉ ×Ù ËÏÐÉÒÕÅÔÅ ÒÅÐÏÚÉÔÏÒÉÊ CVS, ÍÏÖÎÏ ÄÏÐÏÌÎÉÔÅÌØÎÏ ÐÒÅÄÏÓÔÁ×ÉÔØ Ë ÎÅÍÕ ÁÎÏÎÉÍÎÙÊ ÄÏÓÔÕÐ. äÌÑ ÎÁÞÁÌÁ, ÐÒÅÄÕÐÒÅÖÄÅÎÉÅ: ÓÐÒÏÓ ÎÁ ÜÔÏÔ ÓÅÒ×ÉÓ ÎÅ ÔÁË ÕÖ ×ÅÌÉË, ÐÏÄÇÏÔÏ×ËÁ ÅÇÏ ÔÒÅÂÕÅÔ ÎÅËÏÔÏÒÏÇÏ ÏÐÙÔÁ, É, ÎÁËÏÎÅÃ, ×Ù ÄÏÌÖÎÙ ÚÎÁÔØ, ÞÔÏ ÄÅÌÁÅÔÅ. óÕÝÅÓÔ×ÕÅÔ Ä×Á ÏÓÎÏ×ÎÙÈ ÓÐÏÓÏÂÁ ÕÄÁÌÅÎÎÏÇÏ ÄÏÓÔÕÐÁ Ë ÒÅÐÏÚÉÔÏÒÉÀ CVS: ÞÅÒÅÚ pserver É ÞÅÒÅÚ ssh (ÄÏÓÔÕÐ ÞÅÒÅÚ rsh ÍÙ ÒÁÓÓÍÁÔÒÉ×ÁÔØ ÎÅ ÂÕÄÅÍ). äÌÑ ÁÎÏÎÉÍÎÏÇÏ ÄÏÓÔÕÐÁ ÎÁÉÂÏÌÅÅ ÐÏÄÈÏÄÉÔ pserver; ×ÐÒÏÞÅÍ, ÎÅËÏÔÏÒÙÅ ÓÁÊÔÙ ÄÁÀÔ ÄÏÓÔÕÐ É ÐÏÓÒÅÄÓÔ×ÏÍ ssh. äÌÑ ÐÏÓÌÅÄÎÅÇÏ ÂÕÄÅÔ ÐÏÌÅÚÎÏÊ ÓÐÅÃÉÁÌØÎÁÑ ÐÒÏÇÒÁÍÍÁ, ÐÒÅÄÎÁÚÎÁÞÅÎÎÁÑ ÄÌÑ ÉÓÐÏÌØÚÏ×ÁÎÉÑ × ËÁÞÅÓÔ×Å ÛÅÌÌÁ ÄÌÑ ÕÞÅÔÎÏÊ ÚÁÐÉÓÉ ÁÎÏÎÉÍÎÏÇÏ ssh-ÄÏÓÔÕÐÁ. ïÎÁ ÉÓÐÏÌØÚÕÅÔ ×ÙÚÏ× chroot, ÐÏÜÔÏÍÕ ÒÅÐÏÚÉÔÏÒÉÊ CVS ÄÏÌÖÅÎ ÒÁÓÐÏÌÁÇÁÔØÓÑ ×ÎÕÔÒÉ ÄÏÍÁÛÎÅÇÏ ËÁÔÁÌÏÇÁ ÁÎÏÎÉÍÎÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ, ÞÔÏ ÐÒÉÅÍÌÅÍÏ ÎÅ ÄÌÑ ×ÓÅÈ ÓÁÊÔÏ×. äÁÎÎÏÅ ÏÇÒÁÎÉÞÅÎÉÅ ÎÅ ÒÁÓÐÒÏÓÔÒÁÎÑÅÔÓÑ ÎÁ ÄÏÓÔÕÐ ÞÅÒÅÚ pserver, ÏÄÎÁËÏ ÐÏÓÌÅÄÎÉÊ ×ÁÒÉÁÎÔ ÍÏÖÅÔ ÂÙÔØ Ó×ÑÚÁÎ Ó ÄÏÐÏÌÎÉÔÅÌØÎÙÍ ÒÉÓËÏÍ Ó ÔÏÞËÉ ÚÒÅÎÉÑ ÂÅÚÏÐÁÓÎÏÓÔÉ. îÉËÁËÉÈ ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÐÒÏÇÒÁÍÍ ÄÌÑ ÏÂÅÓÐÅÞÅÎÉÑ ÁÎÏÎÉÍÎÏÇÏ CVS-ÄÏÓÔÕÐÁ ÎÅ ÐÏÔÒÅÂÕÅÔÓÑ, ÐÏÓËÏÌØËÕ &man.cvs.1; ×ÈÏÄÉÔ × ÂÁÚÏ×ÕÀ ÐÏÓÔÁ×ËÕ FreeBSD. ÷ÁÍ ÎÕÖÎÏ ÂÕÄÅÔ ÒÁÚÒÅÛÉÔØ ÚÁÐÕÓË cvs ÉÚ inetd, ÄÌÑ ÞÅÇÏ ÎÅÏÂÈÏÄÉÍÏ ÄÏÂÁ×ÉÔØ × ÆÁÊÌ /etc/inetd.conf ÓÔÒÏËÕ ×ÉÄÁ cvspserver stream tcp nowait root /usr/bin/cvs cvs -f -l -R -T /anoncvstmp --allow-root=/home/ncvs pserver ïÂÒÁÔÉÔÅÓØ Ë ÓÔÒÁÎÉÃÅ ÓÐÒÁ×ÏÞÎÉËÁ &man.cvs.1; ÚÁ ÄÏÐÏÌÎÉÔÅÌØÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ ÐÏ ÏÐÃÉÑÍ. ëÒÏÍÅ ÔÏÇÏ, ÓÔÒÁÎÉÃÙ info ÐÏ CVS ÏÐÉÓÙ×ÁÀÔ, ËÁË ÕÄÏÓÔÏ×ÅÒÉÔØÓÑ × ÔÏÍ, ÞÔÏ ×Ù ÐÒÅÄÏÓÔÁ×ÌÑÅÔÅ ÄÏÓÔÕÐ ÔÏÌØËÏ ÄÌÑ ÞÔÅÎÉÑ. òÅËÏÍÅÎÄÕÅÔÓÑ ÓÏÚÄÁÔØ ÎÅÐÒÉ×ÉÌÅÇÉÒÏ×ÁÎÎÕÀ ÕÞÅÔÎÕÀ ÚÁÐÉÓØ, ÖÅÌÁÔÅÌØÎÏ Ó ÉÍÅÎÅÍ anoncvs. ðÏÔÒÅÂÕÅÔÓÑ ÔÁËÖÅ ÓÏÚÄÁÔØ ÆÁÊÌ passwd × ËÁÔÁÌÏÇÅ /home/ncvs/CVSROOT É ÕÓÔÁÎÏ×ÉÔØ ÐÁÒÏÌØ (ÐÕÓÔÏÊ ÉÌÉ anoncvs) ÄÌÑ ÐÏÌØÚÏ×ÁÔÅÌÑ anoncvs. óÏÚÄÁÎÉÅ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ /anoncvstmp × ÐÁÍÑÔÉ ÎÅ ÎÅÏÂÈÏÄÉÍÏ, ÎÏ ÒÅËÏÍÅÎÄÕÅÔÓÑ ÄÌÑ ÕÓËÏÒÅÎÉÑ ÒÁÂÏÔÙ: × ÎÅÊ &man.cvs.1; ÂÕÄÅÔ ÓÏÚÄÁ×ÁÔØ ×ÒÅÍÅÎÎÕÀ ÓÔÒÕËÔÕÒÕ ËÁÔÁÌÏÇÏ×, ËÏÔÏÒÁÑ ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ ÐÏ ÚÁ×ÅÒÛÅÎÉÉ ÏÐÅÒÁÃÉÉ, ÎÏ ÓÉÌØÎÏ ÚÁÍÅÄÌÑÅÔ ÒÁÂÏÔÕ, ÅÓÌÉ ÔÒÅÂÕÀÔÓÑ ÏÐÅÒÁÃÉÉ ÚÁÐÉÓÉ ÎÁ ÒÅÁÌØÎÙÊ ÄÉÓË. ðÒÉÍÅÒ ÏÐÉÓÁÎÉÑ ÔÁËÏÊ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ × ÆÁÊÌÅ /etc/fstab: /dev/da0s1b /anoncvstmp mfs rw,-s=786432,-b=4096,-f=512,-i=560,-c=3,-m=0,nosuid 0 0 üÔÉ ÕÓÔÁÎÏ×ËÉ (ÒÁÚÕÍÅÅÔÓÑ, ÔÝÁÔÅÌØÎÏ ÐÏÄÏÂÒÁÎÎÙÅ) ÐÒÅÄÌÏÖÉÌ &a.jdp.email;. ëÁË ×ÅÓÔÉ ÚÅÒËÁÌÏ FreeBSD ôÅÐÅÒØ ×ÁÍ ÉÚ×ÅÓÔÎÏ, ËÁËÁÑ ÐÏÔÒÅÂÕÅÔÓÑ ÍÁÛÉÎÁ É ËÁË ÐÒÅÄÏÓÔÁ×ÌÑÔØ ÓÅÒ×ÉÓÙ, ÎÏ ÎÅ ËÁË ÐÏÌÕÞÉÔØ ÉÈ ÓÁÍÏÍÕ. :-) ÷ ÜÔÏÍ ÒÁÚÄÅÌÅ ÏÐÉÓÙ×ÁÅÔÓÑ ÐÒÏÃÅÓÓ ×ÅÄÅÎÉÑ ÚÅÒËÁÌÁ É ÐÏÄÄÅÒÖÁÎÉÑ ÅÇÏ × ÁËÔÕÁÌØÎÏÍ ÓÏÓÔÏÑÎÉÉ, × ÔÏÍ ÞÉÓÌÅ ËÁËÉÅ ÉÎÓÔÒÕÍÅÎÔÙ ÉÓÐÏÌØÚÏ×ÁÔØ É ËÁËÉÅ ÓÁÊÔÙ ×ÙÂÉÒÁÔØ × ËÁÞÅÓÔ×Å ÉÓÔÏÞÎÉËÏ× ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ. FTP æÁÊÌÙ, ÄÏÓÔÕÐÎÙÅ ÐÏ FTP, ÓÏÓÔÁ×ÌÑÀÔ ÂÏÌØÛÕÀ ÞÁÓÔØ ÚÅÒËÁÌÁ. ïÎÉ ×ËÌÀÞÁÀÔ ÄÉÓÔÒÉÂÕÔÉ×ÎÙÅ ÎÁÂÏÒÙ, ÎÅÏÂÈÏÄÉÍÙÅ ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÐÏ ÓÅÔÉ, ×ÅÔ×É (branches), × ËÏÔÏÒÙÈ ÏÔÒÁÖÅÎÏ ÔÅËÕÝÅÅ ÓÏÓÔÏÑÎÉÅ ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ×, ÏÂÒÁÚÙ ISO ÄÌÑ ÚÁÐÉÓÉ ËÏÍÐÁËÔ-ÄÉÓËÏ× Ó ÄÉÓÔÒÉÂÕÔÉ×ÁÍÉ ÄÌÑ ÕÓÔÁÎÏ×ËÉ, ÏÂÒÁÚÁÍÉ ÖÉ×ÙÈ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ É ÐÁËÅÔÁÍÉ, ÄÅÒÅ×Ï ÐÏÒÔÏ×, ÉÓÈÏÄÎÙÅ ÄÉÓÔÒÉÂÕÔÉ×Ù ÄÌÑ ÓÂÏÒËÉ ÐÏÒÔÏ× É ËÕÞÕ ÇÏÔÏ×ÙÈ ÐÁËÅÔÏ×. é, ÒÁÚÕÍÅÅÔÓÑ, ×ÓÅ ×ÙÛÅÏÐÉÓÁÎÎÏÅ — ÄÌÑ ÒÁÚÎÙÈ ×ÅÒÓÉÊ FreeBSD É ÒÁÚÌÉÞÎÙÈ ÁÒÈÉÔÅËÔÕÒ. ðÒÉ ÐÏÍÏÝÉ ÐÒÏÇÒÁÍÍ ÄÌÑ FTP-ÚÅÒËÁÌÉÒÏ×ÁÎÉÑ äÌÑ ×ÙËÁÞÉ×ÁÎÉÑ ÆÁÊÌÏ× ×Ù ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÐÒÏÇÒÁÍÍÕ FTP-ÚÅÒËÁÌÉÒÏ×ÁÎÉÑ. ÷ÏÔ ÎÅËÏÔÏÒÙÅ ÉÚ ÎÁÉÂÏÌÅÅ ÞÁÓÔÏ ÉÓÐÏÌØÚÕÀÝÉÈÓÑ: ftp/mirror ftp/ftpmirror ftp/emirror ftp/spegla ftp/omi ftp/wget òÁÎÅÅ ÎÁÉÂÏÌÅÅ ÐÏÐÕÌÑÒÎÙÍ ×ÁÒÉÁÎÔÏÍ ÂÙÌ ftp/mirror, ÈÏÔÑ ÉÚ-ÚÁ ÔÏÇÏ, ÞÔÏ ÜÔÁ ÐÒÏÇÒÁÍÍÁ ÎÁÐÉÓÁÎÁ ÎÁ &man.perl.1;, ÓÕÝÅÓÔ×ÕÀÔ ÒÁÚÌÉÞÎÙÅ ÏÇÒÁÎÉÞÅÎÉÑ, × ÏÓÏÂÅÎÎÏÓÔÉ ÐÒÉ ÚÅÒËÁÌÉÒÏ×ÁÎÉÉ ÂÏÌØÛÉÈ ÆÁÊÌÏ×ÙÈ ÓÔÒÕËÔÕÒ, ÔÁËÉÈ ËÁË FreeBSD. õÔ×ÅÒÖÄÁÅÔÓÑ, ×ÐÒÏÞÅÍ, ÞÔÏ × ÔÅËÕÝÅÊ ×ÅÒÓÉÉ ÐÏÓÌÅÄÎÑÑ ÐÒÏÂÌÅÍÁ ÉÓÐÒÁ×ÌÅÎÁ ÚÁ ÓÞÅÔ ÄÏÐÏÌÎÉÔÅÌØÎÏÇÏ ÁÌÇÏÒÉÔÍÁ ÓÒÁ×ÎÅÎÉÑ ÓÔÒÕËÔÕÒÙ ËÁÔÁÌÏÇÏ×. ÷ÏÏÂÝÅ ÇÏ×ÏÒÑ, ÐÒÏÔÏËÏÌ FTP ÎÅ ÌÕÞÛÉÍ ÏÂÒÁÚÏÍ ÐÏÄÈÏÄÉÔ ÄÌÑ ÐÏÄÄÅÒÖËÉ ÚÅÒËÁÌÁ. éÚÍÅÎÅÎÎÙÊ ÆÁÊÌ ÐÅÒÅÄÁÅÔÓÑ ÃÅÌÉËÏÍ; ËÒÏÍÅ ÔÏÇÏ, ÎÅ×ÏÚÍÏÖÎÏ ÓÏÚÄÁÎÉÅ ÅÄÉÎÏÇÏ ÐÏÔÏËÁ ÄÁÎÎÙÈ, ËÏÔÏÒÙÊ ÍÏÇ ÂÙ ÐÏ×ÙÓÉÔØ ÜÆÆÅËÔÉ×ÎÏÓÔØ ÐÅÒÅÄÁÞÉ ÚÁ ÓÞÅÔ ÂÏÌØÛÏÇÏ TCP-ÏËÎÁ. ðÒÉ ÐÏÍÏÝÉ rsync âÏÌÅÅ ÜÆÆÅËÔÉ×ÎÙÍ ÂÕÄÅÔ ÓÉÎÈÒÏÎÉÚÁÃÉÑ FTP-ÏÂÌÁÓÔÉ ÐÒÉ ÐÏÍÏÝÉ rsync. äÌÑ ÜÔÏÇÏ ÓÌÅÄÕÅÔ ÕÓÔÁÎÏ×ÉÔØ ÐÁËÅÔ net/rsync, ËÏÔÏÒÙÊ ÂÙÌ ÏÐÉÓÁÎ × ÒÁÚÄÅÌÅ . ðÏÓËÏÌØËÕ ÄÏÓÔÕÐ ÐÏ ÐÒÏÔÏËÏÌÕ rsync ÎÅ Ñ×ÌÑÅÔÓÑ ÏÂÑÚÁÔÅÌØÎÙÍ, ×ÙÂÒÁÎÎÙÊ ×ÁÍÉ ÓÁÊÔ ÍÏÖÅÔ ÅÇÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÔØ. ÷ÏÚÍÏÖÎÏ, ×ÁÍ ÐÒÉÄÅÔÓÑ ÎÅÍÎÏÇÏ ÐÏÉÓËÁÔØ × ÓÅÔÅ×ÏÊ ÏËÒÅÓÔÎÏÓÔÉ ÚÅÒËÁÌÏ, ÐÏÄÄÅÒÖÉ×ÁÀÝÅÅ rsync. ðÏÓËÏÌØËÕ ÏÔ ËÏÌÉÞÅÓÔ×Á ËÌÉÅÎÔÏ× rsync ÏÝÕÔÉÍÏ ÚÁ×ÉÓÉÔ ÚÁÇÒÕÚËÁ ÓÅÒ×ÅÒÁ, ÂÏÌØÛÉÎÓÔ×Ï ÁÄÍÉÎÉÓÔÒÁÔÏÒÏ× ××ÏÄÑÔ ÏÇÒÁÎÉÞÅÎÉÑ ÄÏÓÔÕÐÁ. äÌÑ ÐÏÄÄÅÒÖÁÎÉÑ ÚÅÒËÁÌÁ ×ÁÍ ÓÌÅÄÕÅÔ Ó×ÑÚÁÔØÓÑ Ó ÁÄÍÉÎÉÓÔÒÁÔÏÒÏÍ ÓÁÊÔÁ, Ó ËÏÔÏÒÙÍ ×Ù ÂÕÄÅÔÅ ÓÉÎÈÒÏÎÉÚÉÒÏ×ÁÔØÓÑ, ÄÌÑ ÕÔÏÞÎÅÎÉÑ ÌÏËÁÌØÎÙÈ ÐÒÁ×ÉÌ É, ×ÏÚÍÏÖÎÏ, ÄÌÑ ×ÎÅÓÅÎÉÑ × ÎÉÈ ÉÓËÌÀÞÅÎÉÑ ÄÌÑ ×ÁÓ (ÐÏÓËÏÌØËÕ ×Ù ÔÁËÖÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÅ ÚÅÒËÁÌÏ). óÔÒÏËÁ ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ FreeBSD ÐÏ rsync ×ÙÇÌÑÄÉÔ ÐÒÉÍÅÒÎÏ ÔÁË: &prompt.user; rsync -vaz --delete ftp4.de.FreeBSD.org::FreeBSD/ /pub/FreeBSD/ úÁÇÌÑÎÉÔÅ × ÄÏËÕÍÅÎÔÁÃÉÀ ÐÏ rsync, ÔÁËÖÅ ÄÏÓÔÕÐÎÕÀ ÐÏ ÁÄÒÅÓÕ http://rsync.samba.org/ ÚÁ ÄÏÐÏÌÎÉÔÅÌØÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ ÐÏ ÒÁÚÌÉÞÎÙÍ ÏÐÃÉÑÍ rsync. ïÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ, ÞÔÏ × ÓÌÕÞÁÅ ÓÉÎÈÒÏÎÉÚÁÃÉÉ ÍÏÄÕÌÑ ÃÅÌÉËÏÍ (Á ÎÅ ÏÔÄÅÌØÎÏÇÏ ËÁÔÁÌÏÇÁ) ÎÅÏÂÈÏÄÉÍÏ Ñ×ÎÏ ÕËÁÚÁÔØ ÒÅÚÕÌØÔÉÒÕÀÝÉÊ ËÁÔÁÌÏÇ, ÐÏÔÏÍÕ ÞÔÏ ËÁÔÁÌÏÇ Ó ÉÍÅÎÅÍ ÍÏÄÕÌÑ (× ÄÁÎÎÏÍ ÓÌÕÞÁÅ "FreeBSD") ÎÅ ÓÏÚÄÁÅÔÓÑ. äÌÑ ÐÏÄÄÅÒÖÁÎÉÑ ÁËÔÕÁÌØÎÏÓÔÉ ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÓÏÚÄÁÔØ ÓËÒÉÐÔ ÄÌÑ ÚÁÐÕÓËÁ ÐÏÄÏÂÎÏÊ ËÏÍÁÎÄÙ ÉÚ &man.cron.8;. ðÒÉ ÐÏÍÏÝÉ CVSup îÅÍÎÏÇÉÅ ÓÁÊÔÙ, × ÐÅÒ×ÕÀ ÏÞÅÒÅÄØ ÃÅÎÔÒÁÌØÎÙÊ ftp-master.FreeBSD.org ÐÒÅÄÏÓÔÁ×ÌÑÀÔ ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ FTP-ÏÂÌÁÓÔÉ ÄÏÓÔÕÐ ÐÏ ÐÒÏÔÏËÏÌÕ CVSup. ÷ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ËÌÉÅÎÔ CVSup, ÐÒÅÄÐÏÞÔÉÔÅÌØÎÏ ÉÚ ÐÁËÅÔÁ net/cvsup (ÓÍ. ÔÁËÖÅ ). ðÒÉÍÅÒ ËÏÎÆÉÇÕÒÁÃÉÏÎÎÏÇÏ ÆÁÊÌÁ (supfile) ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ Ó ftp-master.FreeBSD.org: # # FreeBSD archive supfile from master server # *default host=ftp-master.FreeBSD.org *default base=/usr *default prefix=/pub #*default release=all *default delete use-rel-suffix *default umask=002 # If your network link is a T1 or faster, comment out the following line. #*default compress FreeBSD-archive release=all preserve óÕÄÑ ÐÏ ×ÓÅÍÕ, ÓÉÎÈÒÏÎÉÚÁÃÉÑ ÐÒÉ ÐÏÍÏÝÉ CVSup — ÌÕÞÛÉÊ ÐÏ ÜÆÆÅËÔÉ×ÎÏÓÔÉ ÓÐÏÓÏ ÐÏÄÄÅÒÖËÉ ÚÅÒËÁÌÁ, ÏÄÎÁËÏ ÏÎ ÄÏÓÔÕÐÅÎ ÌÉÛØ Ó ÎÅÂÏÌØÛÏÇÏ ÞÉÓÌÁ ÓÁÊÔÏ×. ðÒÏÞÔÉÔÅ ÄÏËÕÍÅÎÔÁÃÉÀ ÐÏ CVSup, ÎÁÐÒÉÍÅÒ, &man.cvsup.1;, É ÏÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ ÎÁ ÏÐÃÉÀ . ïÎÁ ÍÏÖÅÔ ÕÍÅÎØÛÉÔØ ÏÂßÅÍ ÏÐÅÒÁÃÉÊ ××ÏÄÁ-×Ù×ÏÄÁ, ÐÒÅÄÐÏÌÁÇÁÑ, ÞÔÏ ÚÁÐÉÓÁÎÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ËÁÖÄÏÍ ÆÁÊÌÅ ËÏÒÒÅËÔÎÁ. úÅÒËÁÌÉÒÏ×ÁÎÉÅ CVS ÒÅÐÏÚÉÔÏÒÉÑ óÕÝÅÓÔ×ÕÅÔ ÎÅÓËÏÌØËÏ ÓÐÏÓÏÂÏ× ÓÉÎÈÒÏÎÉÚÁÃÉÉ CVS ÒÅÐÏÚÉÔÏÒÉÑ. CVSup ÎÁÉÂÏÌÅÅ ÏÂÝÉÊ ÍÅÔÏÄ. éÓÐÏÌØÚÏ×ÁÎÉÅ CVSup ðÒÏÇÒÁÍÍÁ CVSup ÎÅÍÎÏÇÏ ÏÐÉÓÁÎÁ × ( É ). îÁÓÔÒÏÉÔØ CVSup ÚÅÒËÁÌÏ ÏÞÅÎØ ÐÒÏÓÔÏ. õÓÔÁÎÏ×ËÁ net/cvsup-mirror ÐÒÏ×ÅÒÉÔ, ÞÔÏ ×ÓÅ ÎÕÖÎÙÅ ÐÒÏÇÒÁÍÍÙ ÕÓÔÁÎÏ×ÌÅÎÙ É ÚÁÔÅÍ ÓÏÂÅÒÅÔ ×ÓÀ ÎÅÏÂÈÏÄÉÍÕÀ ÉÎÆÏÒÍÁÃÉÀ ÄÌÑ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ ÚÅÒËÁÌÁ. îÅ ÚÁÂÕÄØÔÅ ÐÏÞÉÔÁÔØ ÐÏÌÅÚÎÕÀ ÐÏÄÓËÁÚËÕ ÚÄÅÓØ. äÒÕÇÉÅ ÍÅÔÏÄÙ éÓÐÏÌØÚÏ×ÁÎÉÅ ÍÅÔÏÄÏ×, ÏÔÌÉÞÎÙÈ ÏÔ CVSup, ÎÅ ÒÅËÏÍÅÎÄÕÅÔÓÑ. ôÅÍ ÎÅ ÍÅÎÅÅ, ÍÙ ËÒÁÔËÏ ÕÐÏÍÑÎÅÍ ÉÈ. ðÏÓËÏÌØËÕ ÂÏÌØÛÁÑ ÞÁÓÔØ ÚÅÒËÁÌ ÄÁÅÔ ÄÏÓÔÕÐ Ë ÒÅÐÏÚÉÔÏÒÉÀ CVS × ÞÉÓÌÅ ÐÒÏÞÉÈ ÆÁÊÌÏ×, ÄÏÓÔÕÐÎÙÈ ÐÏ FTP, ÐÏ ÐÕÔÉ /pub/FreeBSD/development/FreeBSD-CVS, ÍÏÇÕÔ ÂÙÔØ ÉÓÐÏÌØÚÏ×ÁÎÙ: FTP Rsync HTTP AnonCVS ÎÅ ÍÏÖÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÄÌÑ ÚÅÒËÁÌÉÒÏ×ÁÎÉÑ CVS ÒÅÐÏÚÉÔÏÒÉÑ, ÔÁË ËÁË CVS ÎÅ ÒÁÚÒÅÛÁÅÔ ÓÁÍ ÄÏÓÔÕÐ Ë ÒÅÐÏÚÉÔÏÒÉÀ, Á ÔÏÌØËÏ Ë ÉÚ×ÌÅÞ£ÎÎÙÍ ×ÅÒÓÉÑÍ ÍÏÄÕÌÅÊ. úÅÒËÁÌÉÒÏ×ÁÎÉÅ ÓÔÒÁÎÉà WWW ìÕÞÛÉÍ ÓÐÏÓÏÂÏÍ ÂÕÄÅÔ ÉÚ×ÌÅÞÅÎÉÅ (check out) ÉÚ ÒÅÐÏÚÉÔÏÒÉÑ CVS ÍÏÄÕÌÑ www. ðÒÉ ÕÓÌÏ×ÉÉ ÎÁÌÉÞÉÑ Õ ×ÁÓ ËÏÐÉÉ ÒÅÐÏÚÉÔÏÒÉÑ, ×ÓÅ, ÞÔÏ ÄÌÑ ÜÔÏÇÏ ÐÏÔÒÅÂÕÅÔÓÑ — ×ÙÐÏÌÎÉÔØ ËÏÍÁÎÄÕ &prompt.user; cvs -d /home/ncvs co www É ÓÆÏÒÍÉÒÏ×ÁÔØ ÚÁÄÁÎÉÅ ÄÌÑ cron, ËÏÔÏÒÏÅ ÂÕÄÅÔ ÒÅÇÕÌÑÒÎÏ ×ÙÐÏÌÎÑÔØ ÏÐÅÒÁÃÉÀ cvs up -d -P, ÎÁÐÒÉÍÅÒ, ËÁÖÄÙÊ ÒÁÚ ÐÏÓÌÅ ÏÂÎÏ×ÌÅÎÉÑ ËÏÐÉÉ ÒÅÐÏÚÉÔÏÒÉÑ. òÁÚÕÍÅÅÔÓÑ, ÆÁÊÌÙ ÄÏÌÖÎÙ ÎÁÈÏÄÉÔØÓÑ × ÉÅÒÁÒÈÉÉ, ÄÏÓÔÕÐÎÏÊ ÄÌÑ ÐÕÂÌÉÞÎÏÇÏ ×ÅÂ-ÄÏÓÔÕÐÁ. íÙ ÓÏÚÎÁÔÅÌØÎÏ ÎÅ ÂÕÄÅÍ ÏÂÓÕÖÄÁÔØ ÚÄÅÓØ ÐÒÏÃÅÓÓ ÕÓÔÁÎÏ×ËÉ É ËÏÎÆÉÇÕÒÁÃÉÉ ×ÅÂ-ÓÅÒ×ÅÒÁ ÄÌÑ ÜÔÉÈ ÃÅÌÅÊ. åÓÌÉ Õ ×ÁÓ ÎÅÔ ÌÏËÁÌØÎÏÊ ËÏÐÉÉ ÒÅÐÏÚÉÔÏÒÉÑ, ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ CVSup ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ ËÏÐÉÉ ×ÅÂ-ÓÔÒÁÎÉÃ. ðÒÉÍÅÒ ËÏÎÆÉÇÕÒÁÃÉÉ ÍÏÖÎÏ ÎÁÊÔÉ × ÆÁÊÌÅ /usr/share/examples/cvsup/www-supfile. ðÒÉ×ÅÄÅÍ ÅÇÏ ÚÄÅÓØ: # # WWW module supfile for FreeBSD # *default host=cvsup3.de.FreeBSD.org *default base=/usr *default prefix=/usr/local *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. *default compress # This collection retrieves the www/ tree of the FreeBSD repository www éÓÐÏÌØÚÏ×ÁÎÉÅ ÐÁËÅÔÁ ftp/wget ÉÌÉ ÉÎÙÈ ÉÎÓÔÒÕÍÅÎÔÏ× ÄÌÑ ÓÏÚÄÁÎÉÑ ×ÅÂ-ÚÅÒËÁÌ ÎÅ ÒÅËÏÍÅÎÄÕÅÔÓÑ. úÅÒËÁÌÁ ÄÏËÕÍÅÎÔÁÃÉÉ FreeBSD ðÏÓËÏÌØËÕ ÍÎÏÇÉÅ ×ÅÂ-ÓÔÒÁÎÉÃÙ ÓÓÙÌÁÀÔÓÑ ÎÁ ÄÏËÕÍÅÎÔÁÃÉÀ, ÈÏÒÏÛÅÊ ÉÄÅÅÊ Ñ×ÌÑÅÔÓÑ ÐÏÄÄÅÒÖËÁ ÚÅÒËÁÌÁ ÄÏËÕÍÅÎÔÁÃÉÉ FreeBSD ÓÏ×ÍÅÓÔÎÏ Ó ÐÒÏÞÉÍÉ ÚÅÒËÁÌÁÍÉ. îÁÄÏ ÏÔÍÅÔÉÔØ, ÞÔÏ ÜÔÏÔ ÐÒÏÃÅÓÓ ÎÅ ÓÔÏÌØ ÔÒÉ×ÉÁÌÅÎ, ËÁË ÐÏÄÄÅÒÖËÁ ÚÅÒËÁÌÁ ×ÅÂ-ÓÔÒÁÎÉà ÓÁÍÉÈ ÐÏ ÓÅÂÅ. äÌÑ ÎÁÞÁÌÁ ×Ù ÄÏÌÖÎÙ ÓÏÚÄÁÔØ ËÏÐÉÀ ÉÓÈÏÄÎÙÈ ÔÅËÓÔÏ× ÄÏËÕÍÅÎÔÁÃÉÉ (ËÁË É ×Ï ÍÎÏÇÉÈ ÄÒÕÇÉÈ ÓÌÕÞÁÑÈ, ÄÌÑ ÜÔÏÇÏ ÐÒÅÄÐÏÞÔÉÔÅÌÅÎ CVSup). ÷ÏÔ ÐÒÉÍÅÒ ÆÁÊÌÁ ËÏÎÆÉÇÕÒÁÃÉÉ: # # FreeBSD documentation supfile # *default host=cvsup3.de.FreeBSD.org *default base=/usr *default prefix=/usr/share *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. #*default compress # This will retrieve the entire doc branch of the FreeBSD repository. # This includes the handbook, FAQ, and translations thereof. doc-all úÁÔÅÍ, ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÎÅÓËÏÌØËÏ ÐÁËÅÔÏ×. ë ÓÞÁÓÔØÀ, ÓÐÅÃÉÁÌØÎÏ ÄÌÑ ÜÔÏÇÏ ÓÕÝÅÓÔ×ÕÅÔ ÍÅÔÁ-ÐÏÒÔ textproc/docproj. ôÁËÖÅ, ÎÅÏÂÈÏÄÉÍÏ ÕÓÔÁÎÏ×ÉÔØ ÎÅËÏÔÏÒÙÅ ÐÅÒÅÍÅÎÎÙÅ ÏËÒÕÖÅÎÉÑ, ÎÁÐÒÉÍÅÒ SGML_CATALOG_FILES, É ÐÅÒÅÍÅÎÎÙÅ × ÆÁÊÌÅ /etc/make.conf, ÇÌÁ×ÎÙÍ ÏÂÒÁÚÏÍ ÐÅÒÅÍÅÎÎÕÀ DOC_LANG (ÉÓÐÏÌØÚÕÊÔÅ ÆÁÊÌ /usr/share/examples/make.conf ËÁË ÛÁÂÌÏÎ). ðÏÓÌÅ ÜÔÏÇÏ ÍÏÖÎÏ ×ÙÄÁÔØ ËÏÍÁÎÄÕ make × ÇÌÁ×ÎÏÍ ËÁÔÁÌÏÇÅ ÄÏËÕÍÅÎÔÁÃÉÉ (ÐÏ ÕÍÏÌÞÁÎÉÀ ÜÔÏ /usr/share/doc). ëÁË É ÐÒÅÖÄÅ, ÜÔÉ ËÁÔÁÌÏÇÉ ÄÏÌÖÎÙ ÂÙÔØ ÄÏÓÔÕÐÎÙ ÄÌÑ ×ÁÛÅÇÏ ×ÅÂ-ÓÅÒ×ÅÒÁ (ÐÒÏ×ÅÒØÔÅ, ÞÔÏ ÓÓÙÌËÉ ×ÅÄÕÔ × ÎÕÖÎÙÅ ÍÅÓÔÁ). ðÒÏÃÅÓÓ ÐÏÄÇÏÔÏ×ËÉ É ÐÏÓÔÒÏÅÎÉÑ ÄÏËÕÍÅÎÔÁÃÉÉ, Á ÔÁËÖÅ ÍÎÏÇÉÅ ÓÏÐÕÔÓÔ×ÕÀÝÉÅ ×ÏÐÒÏÓÙ, ÐÏÄÒÏÂÎÏ ÏÐÉÓÁÎ × ÄÏËÕÍÅÎÔÅ õÞÅÂÎÉË ÐÏ ðÒÏÅËÔÕ äÏËÕÍÅÎÔÉÒÏ×ÁÎÉÑ &os;. ðÒÏÞÔÉÔÅ ÜÔÏÔ ÄÏËÕÍÅÎÔ, × ÏÓÏÂÅÎÎÏÓÔÉ ÅÓÌÉ Õ ×ÁÓ ×ÏÚÎÉËÌÉ ÐÒÏÂÌÅÍÙ ÓÏ ÓÂÏÒËÏÊ ÓÔÁÎÄÁÒÔÎÏÇÏ ËÏÍÐÌÅËÔÁ ÄÏËÕÍÅÎÔÁÃÉÉ. ëÁË ÞÁÓÔÏ ÓÉÎÈÒÏÎÉÚÉÒÏ×ÁÔØÓÑ? ëÁÖÄÏÅ ÚÅÒËÁÌÏ ÄÏÌÖÎÏ ÒÅÇÕÌÑÒÎÏ ÏÂÎÏ×ÌÑÔØÓÑ. ÷ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ËÁËÏÊ-ÔÏ ÎÁÂÏÒ ÓËÒÉÐÔÏ×, ×ÙÐÏÌÎÑÅÍÙÈ ÐÏÓÒÅÄÓÔ×ÏÍ &man.cron.8;. ðÏÓËÏÌØËÕ ËÁÖÄÙÊ ÁÄÍÉÎÉÓÔÒÁÔÏÒ, ËÁË ÐÒÁ×ÉÌÏ, ÐÉÛÅÔ ÔÁËÉÅ ÓËÒÉÐÔÙ ÓÁÍ É ÎÁ Ó×ÏÊ ÌÁÄ, ÍÙ ÎÅ ÍÏÖÅÍ ×ÙÄÁÔØ ËÏÎËÒÅÔÎÙÈ ÕËÁÚÁÎÉÊ. ïÂÝÉÅ ÖÅ ÓÏ×ÅÔÙ ×ÙÇÌÑÄÑÔ ÔÁË: óÏÚÄÁÊÔÅ ÓËÒÉÐÔ Ó ËÏÍÁÎÄÏÊ, ËÏÔÏÒÁÑ ÚÁÐÕÓÔÉÔ ÎÕÖÎÏÅ ÐÒÉÌÏÖÅÎÉÅ ÄÌÑ ÏÂÎÏ×ÌÅÎÉÑ ÚÅÒËÁÌÁ. òÅËÏÍÅÎÄÕÅÍ ÉÓÐÏÌØÚÏ×ÁÔØ ÓËÒÉÐÔ ÎÁ ÑÚÙËÅ ÏÂÙÞÎÏÇÏ /bin/sh. äÏÂÁרÔÅ ËÏÍÁÎÄ ÐÅÒÅÎÁÐÒÁ×ÌÅÎÉÑ ×Ù×ÏÄÁ, ÞÔÏÂÙ ÚÁÐÉÓÁÔØ ÄÉÁÇÎÏÓÔÉËÕ ÒÁÂÏÔÙ × ÆÁÊÌ. ðÏÐÒÏÂÕÊÔÅ, ËÁË ×ÁÛ ÓËÒÉÐÔ ÒÁÂÏÔÁÅÔ. ðÏ ÚÁ×ÅÒÛÅÎÉÉ ÐÒÏ×ÅÒØÔÅ ÌÏÇÉ. ðÒÉ ÐÏÍÏÝÉ ÕÔÉÌÉÔÙ &man.crontab.1; ÄÏÂÁרÔÅ ×ÁÛ ÓËÒÉÐÔ × ÔÁÂÌÉÃÕ ÒÅÇÕÌÑÒÎÙÈ ÚÁÄÁÎÉÊ &man.crontab.5; ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ. üÔÏ ÄÏÌÖÅÎ ÂÙÔØ ÐÏÌØÚÏ×ÁÔÅÌØ, ÏÔÌÉÞÎÙÊ ÏÔ ÐÏÌØÚÏ×ÁÔÅÌÑ FTP-ÄÁÅÍÏÎÁ, ÞÔÏÂÙ ÆÁÊÌÙ × FTP-ÏÂÌÁÓÔÉ ÂÅÚ ÁÔÒÉÂÕÔÁ "ÞÔÅÎÉÅ ÄÌÑ ×ÓÅÈ" ÎÅ ÂÙÌÉ ÄÏÓÔÕÐÎÙ ÁÎÏÎÉÍÎÙÍ FTP-ÐÏÌØÚÏ×ÁÔÅÌÑÍ. äÁÎÎÏÅ Ó×ÏÊÓÔ×Ï ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÔÅÓÔÉÒÏ×ÁÎÉÑ ÐÅÒÅÄ ×ÙÈÏÄÏÍ ÎÏ×ÙÈ ÒÅÌÉÚÏ×, ÄÌÑ ÔÏÇÏ ÞÔÏÂÙ ÕÄÏÓÔÏ×ÅÒÉÔØÓÑ, ÞÔÏ ×ÓÅ ÏÆÉÃÉÁÌØÎÙÅ ÚÅÒËÁÌÁ ÓÏÄÅÒÖÁÔ ×ÓÅ ÎÅÏÂÈÏÄÉÍÙÅ ÆÁÊÌÙ Ë ÍÏÍÅÎÔÕ ÏÆÉÃÉÁÌØÎÏÇÏ ÏÂßÑ×ÌÅÎÉÑ ÒÅÌÉÚÁ. îÅËÏÔÏÒÙÅ ÒÅËÏÍÅÎÄÕÅÍÙÅ ÕÓÔÁÎÏ×ËÉ ÞÁÓÔÏÔÙ ÏÂÎÏ×ÌÅÎÉÑ: FTP-ÎÁÂÏÒ: ÒÁÚ × ÓÕÔËÉ ÒÅÐÏÚÉÔÏÒÉÊ CVS: ÒÁÚ × ÞÁÓ WWW-ÓÔÒÁÎÉÃÙ: ÒÁÚ × ÓÕÔËÉ ó ËÁËÏÇÏ ÓÅÒ×ÅÒÁ ÓÉÎÈÒÏÎÉÚÉÒÏ×ÁÔØÓÑ üÔÏ ×ÁÖÎÙÊ ×ÏÐÒÏÓ, ÔÁË ÞÔÏ ÍÙ ÐÏÐÙÔÁÅÍÓÑ ÐÏÑÓÎÉÔØ, ÏÔËÕÄÁ ÂÅÒÕÔÓÑ ÏÔ×ÅÔÙ. äÌÑ ÎÁÞÁÌÁ ÐÏ×ÔÏÒÉÍ ÅÝÅ ÎÅÓËÏÌØËÏ ÒÁÚ: ÎÉËÏÇÄÁ ÎÅ ÓÉÎÈÒÏÎÉÚÉÒÕÊÔÅÓØ Ó ftp.FreeBSD.org . ïÒÇÁÎÉÚÁÃÉÑ ÓÉÓÔÅÍÙ ÚÅÒËÁÌ úÅÒËÁÌÁ ÏÒÇÁÎÉÚÕÀÔÓÑ ÐÏ ÓÔÒÁÎÁÍ. éÍÅÎÁ ÈÏÓÔÏ× ×ÓÅÈ ÏÆÉÃÉÁÌØÎÙÈ ÚÅÒËÁÌ ÐÏÓÔÒÏÅÎÙ ÐÏ ÐÒÉÎÃÉÐÕ ftpN.CC.FreeBSD.org, ÇÄÅ CC (country code) — ÄÏÍÅÎ ×ÅÒÈÎÅÇÏ ÕÒÏ×ÎÑ ÓÔÒÁÎÙ, ÇÄÅ ÒÁÓÐÏÌÏÖÅÎÏ ÚÅÒËÁÌÏ, N — ÎÏÍÅÒ ÚÅÒËÁÌÁ × ÄÁÎÎÏÊ ÓÔÒÁÎÅ. üÔÏÔ ÖÅ ÐÒÉÎÃÉÐ ÐÒÉÍÅÎÉÍ Ë ÉÍÅÎÁÍ ÈÏÓÔÏ× cvsupN.CC.FreeBSD.org, wwwN.CC.FreeBSD.org É Ô.Ð. ëÒÏÍÅ ÔÏÇÏ, ÅÓÔØ ÚÅÒËÁÌÁ ÂÅÚ ÄÏÍÅÎÎÏÊ ÞÁÓÔÉ, ÏÂÏÚÎÁÞÁÀÝÅÊ ÓÔÒÁÎÕ. ÷ÓÅ ÏÎÉ ÉÍÅÀÔ ÏÞÅÎØ ÈÏÒÏÛÉÅ ×ÎÅÛÎÉÅ ËÁÎÁÌÙ É ÏÂÓÌÕÖÉ×ÁÀÔ ÂÏÌØÛÏÅ ÞÉÓÌÏ ÏÄÎÏ×ÒÅÍÅÎÎÙÈ ÓÏÅÄÉÎÅÎÉÊ. éÍÑ ftp.FreeBSD.org ÎÁ ÓÁÍÏÍ ÄÅÌÅ ÕËÁÚÙ×ÁÅÔ ÎÁ Ä×Å ÍÁÛÉÎÙ, ÏÄÎÁ ÉÚ ËÏÔÏÒÙÈ × ÎÁÓÔÏÑÝÅÅ ×ÒÅÍÑ ÎÁÈÏÄÉÔÓÑ × äÁÎÉÉ, Á ÄÒÕÇÁÑ × óûá. îÉ ÏÄÎÁ ÉÚ ÜÔÉÈ ÍÁÛÉÎ îå Ñ×ÌÑÅÔÓÑ ÏÓÎÏ×ÎÙÍ ÓÁÊÔÏÍ, É ÐÏÔÏÍÕ ÎÅ ÄÏÌÖÎÁ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ. íÁÓÓÁ ÄÏËÕÍÅÎÔÁÃÉÉ ÄÌÑ ÖÉ×ÙÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ ÕËÁÚÙ×ÁÅÔ ÎÁ ftp.FreeBSD.org, ÔÁË ÞÔÏ Á×ÔÏÍÁÔÉÞÅÓËÉÍ ÓÉÓÔÅÍÁÍ ×ÅÄÅÎÉÑ ÚÅÒËÁÌ ÓÌÅÄÕÅÔ ×ÙÂÉÒÁÔØ ÄÒÕÇÉÅ ÉÓÔÏÞÎÉËÉ ÓÉÎÈÒÏÎÉÚÁÃÉÉ. ëÒÏÍÅ ÔÏÇÏ, ÓÕÝÅÓÔ×ÕÅÔ ÉÅÒÁÒÈÉÑ ÚÅÒËÁÌ × ÔÅÒÍÉÎÁÈ ÉÈ ÕÄÁÌÅÎÎÏÓÔÉ ÏÔ ÃÅÎÔÒÁ, ÉÌÉ ÓÌÏÑÈ. ïÓÎÏ×ÎÙÅ ÓÁÊÔÙ ÍÏÇÕÔ ÂÙÔØ ÏÐÉÓÁÎÙ ËÁË úÅÒËÁÌÁ ÎÕÌÅ×ÏÇÏ ÓÌÏÑ. úÅÒËÁÌÁ, ÓÉÎÈÒÏÎÉÚÉÒÕÀÝÉÅÓÑ ÐÏ ÎÉÍ, ÓÞÉÔÁÀÔÓÑ ÓÌÏÅÍ 1, ÓÌÅÄÕÀÝÉÅ — ÓÌÏÅÍ 2 É Ô.Ä. ïÆÉÃÉÁÌØÎÙÅ ÓÁÊÔÙ ÐÒÉÇÌÁÛÁÀÔÓÑ ÎÁ ÎÉÚËÉÅ ÓÌÏÉ, ÏÄÎÁËÏ ÓÌÅÄÕÅÔ ÐÏÍÎÉÔØ, ÞÔÏ ÞÅÍ ÍÅÎØÛÅ ÎÏÍÅÒ ÓÌÏÑ, ÔÅÍ ×ÙÛÅ ÔÒÅÂÏ×ÁÎÉÑ Ë ÚÅÒËÁÌÕ, ËÁË ÂÙÌÏ ÏÐÉÓÁÎÏ × . ðÏÍÉÍÏ ÔÏÇÏ, ÄÏÓÔÕÐ Ë ÚÅÒËÁÌÁÍ 1 ÓÌÏÑ ÍÏÖÅÔ ÂÙÔØ ÏÇÒÁÎÉÞÅÎ; ÂÅÚÕÓÌÏ×ÎÏ ÏÇÒÁÎÉÞÅÎ ÄÏÓÔÕÐ Ë ÏÓÎÏ×ÎÙÍ ÓÁÊÔÁÍ. éÅÒÁÒÈÉÑ ÓÌÏÅ× ÎÅ ÏÔÒÁÖÁÅÔÓÑ × DNS É, ×ÏÏÂÝÅ ÇÏ×ÏÒÑ, ÎÉÇÄÅ (ËÒÏÍÅ ÍÁÓÔÅÒ-ÓÁÊÔÏ×) ÎÅ ÄÏËÕÍÅÎÔÉÒÏ×ÁÎÁ. ôÅÍ ÎÅ ÍÅÎÅÅ, ÏÆÉÃÉÁÌØÎÙÅ ÚÅÒËÁÌÁ Ó ÍÁÌÙÍÉ (1-4, ËÁË ÐÒÁ×ÉÌÏ) ÎÏÍÅÒÁÍÉ ÏÂÙÞÎÏ ÐÒÅÄÓÔÁ×ÌÑÀÔ ÐÅÒ×ÙÊ ÓÌÏÊ. (üÔÏ ÇÒÕÂÁÑ ÏÃÅÎËÁ, É ÎÉ × ËÏÅÍ ÓÌÕÞÁÅ ÎÅ ÐÒÁ×ÉÌÏ). ôÁË ÏÔËÕÄÁ ÖÅ ÍÎÅ ÓÉÎÈÒÏÎÉÚÉÒÏ×ÁÔØÓÑ? çÌÁ×ÎÏÅ — îå Ó ftp.FreeBSD.org. ëÏÒÏÔËÉÊ ÏÔ×ÅÔ: Ó ÚÅÒËÁÌÁ, ËÏÔÏÒÏÅ ÒÁÓÐÏÌÏÖÅÎÏ ÎÅÄÁÌÅËÏ ÏÔ ×ÁÓ × ÔÅÒÍÉÎÁÈ éÎÔÅÒÎÅÔ, É/ÉÌÉ ÄÏÓÔÕÐ Ë ËÏÔÏÒÏÍÕ ÎÁÉÌÕÞÛÉÊ. ñ ÈÏÞÕ ÐÏÌÕÞÉÔØ ËÏÐÉÀ ÚÅÒËÁÌÁ ÈÏÔØ ÏÔËÕÄÁ-ÎÉÂÕÄØ! åÓÌÉ Õ ×ÁÓ ÎÅÔ ËÁËÉÈ-ÌÉÂÏ ÓÐÅÃÉÁÌØÎÙÈ ÐÒÅÄÐÏÞÔÅÎÉÊ ÉÌÉ ÔÒÅÂÏ×ÁÎÉÊ, ÓÍ. . üÔÏ ÏÚÎÁÞÁÅÔ: ÷ÙÂÅÒÉÔÅ ÔÅ ÉÚ ÎÉÈ, Ó ËÏÔÏÒÙÍÉ ×ÁÍ ÒÁÂÏÔÁÔØ ÂÙÓÔÒÅÅ ×ÓÅÇÏ (ÍÅÎØÛÅÅ ÞÉÓÌÏ ÐÒÏÍÅÖÕÔÏÞÎÙÈ ÕÚÌÏ× É ×ÒÅÍÑ ÏÔËÌÉËÁ), É ËÏÔÏÒÙÅ ÐÒÅÄÏÓÔÁ×ÌÑÀÔ ÎÕÖÎÙÅ ×ÁÍ ÓÅÒ×ÉÓÙ (ÔÁËÉÅ ËÁË rsync ÉÌÉ CVSup). ó×ÑÖÉÔÅÓØ Ó ÁÄÍÉÎÉÓÔÒÁÔÏÒÁÍÉ ×ÙÂÒÁÎÎÏÇÏ ÓÅÒ×ÅÒÁ, ÏÐÉÛÉÔÅ ×ÁÛÉ ÚÁÐÒÏÓÙ É ÕÔÏÞÎÉÔÅ ÉÈ ÐÒÁ×ÉÌÁ. óËÏÎÆÉÇÕÒÉÒÕÊÔÅ ×ÁÛÅ ÚÅÒËÁÌÏ, ËÁË ÏÐÉÓÙ×ÁÌÏÓØ ×ÙÛÅ. ñ ÐÏÄÄÅÒÖÉ×ÁÀ ÏÆÉÃÉÁÌØÎÏÅ ÚÅÒËÁÌÏ, ËÁËÏÊ ÓÁÊÔ ÍÎÅ ×ÙÂÒÁÔØ? ÷ ÏÓÎÏ×ÎÏÍ, ÐÒÁ×ÉÌÁ, ÏÐÉÓÁÎÎÙÅ × , ÐÒÉÍÅÎÉÍÙ. äÏÐÏÌÎÉÔÅÌØÎÏ ÍÏÖÎÏ ÕÂÅÄÉÔØÓÑ, ÞÔÏ ×ÙÂÒÁÎÎÙÊ ÓÁÊÔ ÐÒÉÎÁÄÌÅÖÉÔ ÎÉÚËÏÍÕ ÓÌÏÀ. äÒÕÇÉÅ ÓÏÏÂÒÁÖÅÎÉÑ ÏÔÎÏÓÉÔÅÌØÎÏ ÏÆÉÃÉÁÌØÎÙÈ ÚÅÒËÁÌ ÏÐÉÓÁÎÙ × . íÎÅ ÎÕÖÅÎ ÄÏÓÔÕÐ Ë ÏÓÎÏ×ÎÙÍ ÓÁÊÔÁÍ! ðÒÉ ÎÁÌÉÞÉÉ ÄÏÓÔÁÔÏÞÎÙÈ ÐÒÉÞÉÎ ×Ù ÍÏÖÅÔÅ ÐÏÌÕÞÉÔØ ÄÏÓÔÕÐ Ë ÏÄÎÏÍÕ ÉÚ ÏÓÎÏ×ÎÙÈ ÓÁÊÔÏ×. äÏÓÔÕÐ Ë ÎÉÍ ÏÇÒÁÎÉÞÅÎ; ÓÕÝÅÓÔ×ÕÀÔ ÓÐÅÃÉÁÌØÎÙÅ ÐÒÁ×ÉÌÁ ÉÈ ÉÓÐÏÌØÚÏ×ÁÎÉÑ. îÁÌÉÞÉÅ Õ ×ÁÓ ÓÔÁÔÕÓÁ ÏÆÉÃÉÁÌØÎÏÇÏ ÚÅÒËÁÌÁ, ÂÅÚÕÓÌÏ×ÎÏ, Ñ×ÌÑÅÔÓÑ ÈÏÒÏÛÉÍ ÐÏÄÓÐÏÒØÅÍ. ÷ ÐÒÏÔÉ×ÎÏÍ ÓÌÕÞÁÅ ÕÂÅÄÉÔÅÓØ, ÞÔÏ ×ÁÛÁ ÓÔÒÁÎÁ ÄÅÊÓÔ×ÉÔÅÌØÎÏ ÎÕÖÄÁÅÔÓÑ ÅÝÅ × ÏÄÎÏÍ ÚÅÒËÁÌÅ. åÓÌÉ ÉÈ ÕÖÅ ÔÒÉ ÉÌÉ ÂÏÌÅÅ, ÓÎÁÞÁÌÁ Ó×ÑÖÉÔÅÓØ Ó ÁÄÍÉÎÉÓÔÒÁÔÏÒÏÍ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÊ ÚÏÎÙ DNS (hostmaster@CC.FreeBSD.org) ÉÌÉ ÎÁÐÉÛÉÔÅ × &a.hubs;. äÏÓÔÕÐ Ë ÏÄÎÏÍÕ ÉÚ ÍÁÓÔÅÒ-ÓÁÊÔÏ× ÉÌÉ ÐÏÄÈÏÄÑÝÅÍÕ ÚÅÒËÁÌÕ 1 ÕÒÏ×ÎÑ ×ÁÍ ÐÏÍÏÇÕÔ ÏÂÅÓÐÅÞÉÔØ ÔÅ ÖÅ, ËÔÏ ÐÏÍÏÇÁÌ ×ÁÍ ÐÏÌÕÞÉÔØ ÓÔÁÔÕÓ ÏÆÉÃÉÁÌØÎÏÇÏ ÚÅÒËÁÌÁ. ÷ ÓÌÕÞÁÅ ÎÅÕÄÁÞÉ Ó×ÑÖÉÔÅÓØ Ó mirror-admin@FreeBSD.org É ÐÏÐÒÏÓÉÔÅ ÐÏÍÏÝÉ Õ ÎÉÈ. óÕÝÅÓÔ×ÕÅÔ ÔÒÉ ÏÓÎÏ×ÎÙÈ ÓÁÊÔÁ ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ ÎÁÂÏÒÁ ÆÁÊÌÏ× FTP É ÏÄÉÎ ÄÌÑ ÒÅÐÏÚÉÔÏÒÉÑ CVS. ÷ÅÂ-ÓÔÒÁÎÉÃÙ É ÄÏËÕÍÅÎÔÁÃÉÑ ÈÒÁÎÑÔÓÑ × CVS, ÐÏÜÔÏÍÕ ÎÅ ÉÍÅÀÔ ÏÔÄÅÌØÎÙÈ ÏÓÎÏ×ÎÙÈ ÓÁÊÔÏ×. ftp-master.FreeBSD.org üÔÏ ÏÓÎÏ×ÎÏÊ ÓÅÒ×ÅÒ ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ FTP ÎÁÂÏÒÁ. ftp-master.FreeBSD.org ÐÏÄÄÅÒÖÉ×ÁÅÔ ÄÏÓÔÕÐ ÐÏ rsync É CVSup, × ÄÏÐÏÌÎÅÎÉÅ Ë FTP. éÓÐÏÌØÚÏ×ÁÎÉÅ ÜÔÉÈ ÐÒÏÔÏËÏÌÏ× ÏÐÉÓÁÎÏ × ÒÁÚÄÅÌÁÈ É . ðÒÉ×ÅÔÓÔ×ÕÅÔÓÑ ÐÒÅÄÏÓÔÁ×ÌÅÎÉÅ ÚÅÒËÁÌÁÍÉ 1 ÕÒÏ×ÎÑ ÄÏÓÔÕÐÁ Ë FTP-ÏÂÌÁÓÔÉ ÐÏ ÐÒÏÔÏËÏÌÕ rsync. cvsup-master.FreeBSD.org üÔÏ ÏÓÎÏ×ÎÏÊ ÓÅÒ×ÅÒ ÄÌÑ ÓÉÎÈÒÏÎÉÚÁÃÉÉ ÒÅÐÏÚÉÔÏÒÉÑ CVS. cvsup-master.FreeBSD.org ÏÂÅÓÐÅÞÉ×ÁÅÔ ÄÏÓÔÕÐ ÔÏÌØËÏ ÐÏ ÐÒÏÔÏËÏÌÕ CVSup. äÅÔÁÌÉ ÓÍ. × . äÌÑ ÐÏÌÕÞÅÎÉÑ ÄÏÓÔÕÐÁ Ë ÜÔÏÍÕ ÓÅÒ×ÅÒÕ ×ÁÍ ÎÕÖÎÏ Ó×ÑÚÁÔØÓÑ Ó &a.cvsup-master;. îÅ ÚÁÂÕÄØÔÅ ÓÎÁÞÁÌÁ ÐÒÏÞÉÔÁÔØ ðÒÁ×ÉÌÁ ÄÏÓÔÕÐÁ Ë ÃÅÎÔÒÁÌØÎÏÍÕ CVSup ÓÅÒ×ÅÒÕ FreeBSD! ðÏÄÇÏÔÏרÔÅ ÐÁÒÁÍÅÔÒÙ Á×ÔÏÒÉÚÁÃÉÉ, ËÁË ÏÐÉÓÁÎÏ ÚÄÅÓØ. îÅ ÚÁÂÕÄØÔÅ, ÞÔÏ × ËÁÞÅÓÔ×Å ÉÍÅÎÉ ÓÅÒ×ÅÒÁ ËÏÍÁÎÄÅ cvpasswd ÎÕÖÎÏ ÕËÁÚÁÔØ freefall.FreeBSD.org, ÎÅÓÍÏÔÒÑ ÎÁ ÔÏ, ÞÔÏ ÕÓÔÁÎÁ×ÌÉ×ÁÔØ ÓÏÅÄÉÎÅÎÉÅ ×Ù ÂÕÄÅÔÅ Ó cvsup-master.FreeBSD.org. ïÆÉÃÉÁÌØÎÙÅ ÚÅÒËÁÌÁ ïÆÉÃÉÁÌØÎÙÅ ÚÅÒËÁÌÁ ÏÂÌÁÄÁÀÔ ÓÌÅÄÕÀÝÉÍ Ó×ÏÊÓÔ×ÁÍÉ: a) ÉÍÅÀÔ ÚÁÐÉÓØ × ÄÏÍÅÎÅ FreeBSD.org (ÏÂÙÞÎÏ ÔÉÐÁ CNAME). b) ÐÒÉÓÕÔÓÔ×ÕÀÔ × ÓÐÉÓËÅ ÏÆÉÃÉÁÌØÎÙÈ ÚÅÒËÁÌ × òÕËÏ×ÏÄÓÔ×Å ÐÏ FreeBSD É ÄÒÕÇÏÊ ÄÏËÕÍÅÎÔÁÃÉÉ. îÁ ÎÁÓÔÏÑÝÉÊ ÍÏÍÅÎÔ ÜÔÏ ×ÓÅ, ÞÔÏ ÏÔÌÉÞÁÅÔ ÉÈ ÏÔ ÐÒÏÞÉÈ ÚÅÒËÁÌ. ïÆÉÃÉÁÌØÎÙÅ ÚÅÒËÁÌÁ ÎÅ ÏÂÑÚÁÔÅÌØÎÏ ÐÒÉÎÁÄÌÅÖÁÔ Ë ðÅÒ×ÏÍÕ ÕÒÏ×ÎÀ, ÏÄÎÁËÏ, ×ÒÑÄ ÌÉ ÍÏÖÎÏ ÎÁÊÔÉ ÚÅÒËÁÌÏ ÕÒÏ×ÎÑ 1, ÎÅ Ñ×ÌÑÀÝÅÅÓÑ ÏÆÉÃÉÁÌØÎÙÍ. ïÔÄÅÌØÎÙÅ ÔÒÅÂÏ×ÁÎÉÑ Ë ÏÆÉÃÉÁÌØÎÙÍ ÚÅÒËÁÌÁÍ 1 ÕÒÏ×ÎÑ ïÐÉÓÁÔØ ÔÒÅÂÏ×ÁÎÉÑ ÄÌÑ ×ÓÅÈ ÏÆÉÃÉÁÌØÎÙÈ ÚÅÒËÁÌ ÎÅ ÔÁË ÐÒÏÓÔÏ, ÐÏÓËÏÌØËÕ ÐÒÏÅËÔ FreeBSD ÄÏÓÔÁÔÏÞÎÏ ÍÑÇÏË × ÜÔÏÍ ÏÔÎÏÛÅÎÉÉ. îÅÓËÏÌØËÏ ÐÒÏÝÅ ÕËÁÚÁÔØ, ÞÔÏ ÔÒÅÂÕÅÔÓÑ ÏÔ ÏÆÉÃÉÁÌØÎÙÈ ÚÅÒËÁÌ ÕÒÏ×ÎÑ 1. ðÒÏÞÉÅ ÏÆÉÃÉÁÌØÎÙÅ ÚÅÒËÁÌÁ ÄÏÌÖÎÙ ÒÁÓÓÍÁÔÒÉ×ÁÔØ ÜÔÏÔ ÓÐÉÓÏË ËÁË ÎÁÓÔÏÊÞÉ×ÙÅ ÐÏÖÅÌÁÎÉÑ. óÌÅÄÕÀÝÅÅ ÏÔÎÏÓÉÔÓÑ × ÏÓÎÏ×ÎÏÍ Ë ÎÁÂÏÒÕ ÆÁÊÌÏ× FTP, ÐÏÓËÏÌØËÕ ÒÅÐÏÚÉÔÏÒÉÊ CVS ×ÓÅÇÄÁ ÄÏÌÖÅÎ ÚÅÒËÁÌÉÒÏ×ÁÔØÓÑ ÐÏÌÎÏÓÔØÀ, Á ×ÅÂ-ÓÔÒÁÎÉÃÙ ÐÒÅÄÓÔÁ×ÌÑÀÔ ÓÏÂÏÊ ÎÅÓËÏÌØËÏ ÏÓÏÂÙÊ ÓÌÕÞÁÊ. úÅÒËÁÌÁ 1 ÕÒÏ×ÎÑ ÄÏÌÖÎÙ: ÐÏÄÄÅÒÖÉ×ÁÔØ ÐÏÌÎÙÊ ÓÐÉÓÏË ÆÁÊÌÏ× ÐÒÅÄÏÓÔÁ×ÌÑÔØ ÄÏÓÔÕÐ ÄÌÑ ÄÒÕÇÉÈ ÚÅÒËÁÌ ÏÂÅÓÐÅÞÉ×ÁÔØ ÄÏÓÔÕÐ ÐÏ ÐÒÏÔÏËÏÌÁÍ FTP É rsync. ëÒÏÍÅ ÔÏÇÏ, ÁÄÍÉÎÉÓÔÒÁÔÏÒ ÔÁËÏÇÏ ÚÅÒËÁÌÁ ÄÏÌÖÅÎ ÂÙÔØ ÐÏÄÐÉÓÁÎ ÎÁ &a.hubs;. óÍ. ÚÄÅÓØ ÄÌÑ ÄÏÐÏÌÎÉÔÅÌØÎÏÊ ÉÎÆÏÒÍÁÃÉÉ Ï ÐÏÄÐÉÓËÅ. áÄÍÉÎÉÓÔÒÁÔÏÒÙ ÚÅÒËÁÌ, × ÏÓÏÂÅÎÎÏÓÔÉ 1 ÕÒÏ×ÎÑ, ÄÏÌÖÎÙ ÏÞÅÎØ ×ÎÉÍÁÔÅÌØÎÏ ÓÌÅÄÉÔØ ÚÁ ÇÒÁÆÉËÏÍ ÒÅÌÉÚÏ×. üÔÏ ÐÏÍÏÖÅÔ ÐÏÄÇÏÔÏ×ÉÔØÓÑ Ë ËÒÕÐÎÙÍ ×ÓÐÌÅÓËÁÍ ÎÁÇÒÕÚËÉ ÎÁ ÚÅÒËÁÌÏ, ËÏÔÏÒÙÅ ×ÓÅÇÄÁ ÐÒÏÉÓÈÏÄÑÔ ÐÏÓÌÅ ÏÞÅÒÅÄÎÏÇÏ ÒÅÌÉÚÁ. ëÒÏÍÅ ÔÏÇÏ, ×ÁÖÎÏ ÐÏÄÄÅÒÖÉ×ÁÔØ ÁËÔÕÁÌØÎÏÓÔØ ÚÅÒËÁÌ (× ÏÓÏÂÅÎÎÏÓÔÉ ÚÅÒËÁÌ ÕÒÏ×ÎÑ 1). åÓÌÉ úÅÒËÁÌÏ1 ÎÅ ÓÉÎÈÒÏÎÉÚÉÒÏ×ÁÌÏÓØ × ÔÅÞÅÎÉÅ ÄÌÉÔÅÌØÎÏÇÏ ×ÒÅÍÅÎÉ, ÔÏ ÚÅÒËÁÌÁ ÓÌÅÄÕÀÝÅÇÏ ÕÒÏ×ÎÑ ÂÕÄÕÔ ÓÉÎÈÒÏÎÉÚÉÒÏ×ÁÔØÓÑ ÐÏ ÕÓÔÁÒÅ×ÛÅÊ ÉÎÆÏÒÍÁÃÉÉ É Ô.Ä. ðÏÄÄÅÒÖÉ×ÁÊÔÅ ÁËÔÕÁÌØÎÏÓÔØ ×ÁÛÉÈ ÚÅÒËÁÌ! ëÁË ÓÔÁÔØ ÏÆÉÃÉÁÌØÎÙÍ ÚÅÒËÁÌÏÍ? îÁ ÔÅËÕÝÉÊ ÍÏÍÅÎÔ ÚÁÑ×ËÉ ÎÁ ÐÏÄËÌÀÞÅÎÉÅ ÎÏ×ÙÈ ÚÅÒËÁÌ ÎÅ ÐÒÉÎÉÍÁÀÔÓÑ. óÔÁÔÉÓÔÉËÁ ÎÅËÏÔÏÒÙÈ ÚÅÒËÁÌ ÷ÏÔ ÎÅÓËÏÌØËÏ ÓÓÙÌÏË ÎÁ ÓÔÁÔÉÓÔÉËÕ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÚÅÒËÁÌ óÔÁÔÉÓÔÉËÁ FTP ÓÁÊÔÏ× ftp.is.FreeBSD.org - hostmaster@is.FreeBSD.org - (ÚÁÇÒÕÚËÁ ËÁÎÁÌÁ) (FTP ÐÒÏÃÅÓÓÙ) (HTTP ÐÒÏÃÅÓÓÙ) ftp.cz.FreeBSD.org - cejkar@fit.vutbr.cz - (ÚÁÇÒÕÚËÁ ËÁÎÁÌÁ) (FTP ÐÒÏÃÅÓÓÙ) (rsync ÐÒÏÃÅÓÓÙ) ftp2.ru.FreeBSD.org - mirror@macomnet.ru - (Bandwidth) (HTTP and FTP users) óÔÁÔÉÓÔÉËÁ CVSup ÓÁÊÔÏ× cvsup[23456].jp.FreeBSD.org - kuriyama@FreeBSD.org - (CVSup ÐÒÏÃÅÓÓÙ) cvsup.cz.FreeBSD.org - cejkar@fit.vutbr.cz - (CVSup ÐÒÏÃÅÓÓÙ) cvsup4.ru.FreeBSD.org - maxim@FreeBSD.org - (CVSup ÐÒÏÃÅÓÓÙ)
diff --git a/ru_RU.KOI8-R/books/handbook/bsdinstall/chapter.xml b/ru_RU.KOI8-R/books/handbook/bsdinstall/chapter.xml index f2a4079037..cfe00915a3 100644 --- a/ru_RU.KOI8-R/books/handbook/bsdinstall/chapter.xml +++ b/ru_RU.KOI8-R/books/handbook/bsdinstall/chapter.xml @@ -1,2718 +1,2718 @@ Jim Mock òÅÓÔÒÕËÔÕÒÉÚÏ×ÁÌ, ÒÅÏÒÇÁÎÉÚÏ×ÁÌ É ÞÁÓÔÉÞÎÏ ÐÅÒÅÐÉÓÁÌ Randy Pratt óÏÚÄÁÎÉÅ ÉÚÏÂÒÁÖÅÎÉÊ, ÁÎÁÌÉÚ É ËÏÐÉÒÏ×ÁÎÉÅ ÏÂÝÅÊ ÓÔÒÕËÔÕÒÙ sysinstall: Gavin Atkinson ëÏÒÒÅËÔÉÒÏ×ËÁ ÐÏÄ bsdinstall: Warren Block Taras Korenko ðÅÒÅ×ÏÄ ÎÁ ÒÕÓÓËÉÊ ÑÚÙË: õÓÔÁÎÏ×ËÁ &os; ×ÅÒÓÉÊ 9.<replaceable>X</replaceable> É ÂÏÌÅÅ ÐÏÚÄÎÉÈ ëÒÁÔËÉÊ ÏÂÚÏÒ installation &os; ÐÏÓÔÁ×ÌÑÅÔÓÑ Ó ÐÒÏÓÔÏÊ × ÉÓÐÏÌØÚÏ×ÁÎÉÉ ÔÅËÓÔÏ×ÏÊ ÐÒÏÇÒÁÍÍÏÊ ÕÓÔÁÎÏ×ËÉ. &os; 9.0-RELEASE É ÂÏÌÅÅ ÐÏÚÄÎÉÅ ÕËÏÍÐÌÅËÔÏ×ÁÎÙ ÕÓÔÁÎÏ×ÝÉËÏÍ, ÎÁÚÙ×ÁÅÍÙÍ bsdinstall, × ÔÏ ×ÒÅÍÑ ËÁË × ÒÅÌÉÚÁÈ, ÐÒÅÄÛÅÓÔ×ÕÀÝÉÈ &os; 9.0-RELEASE, ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÉÓÐÏÌØÚÕÅÔÓÑ sysinstall. ÷ ÜÔÏÍ ÒÁÚÄÅÌÅ ÏÐÉÓÁÎÁ ÒÁÂÏÔÁ Ó ÐÒÏÇÒÁÍÍÏÊ bsdinstall. òÁÂÏÔÁ Ó ÕÓÔÁÎÏ×ÝÉËÏÍ sysinstall ÏÐÉÓÁÎÁ × . ðÏÓÌÅ ÐÒÏÞÔÅÎÉÑ ÜÔÏÇÏ ÒÁÚÄÅÌÁ ×Ù ÂÕÄÅÔÅ ÚÎÁÔØ: ëÁË ÓÏÚÄÁ×ÁÔØ ÕÓÔÁÎÏ×ÏÞÎÙÅ ÎÏÓÉÔÅÌÉ ÄÌÑ &os;. òÁÚÂÉÅÎÉÅ É ÉÍÅÎÏ×ÁÎÉÅ ÒÁÚÄÅÌÏ× ÖÅÓÔËÉÈ ÄÉÓËÏ× ×Ï &os;. ëÁË ÚÁÐÕÓÔÉÔØ bsdinstall. ÷ÏÐÒÏÓÙ, ÚÁÄÁ×ÁÅÍÙÅ ÕÔÉÌÉÔÏÊ bsdinstall, ÞÔÏ ÏÎÉ ÚÎÁÞÁÔ É ËÁË ÎÁ ÎÉÈ ÏÔ×ÅÞÁÔØ. ðÅÒÅÄ ÐÒÏÞÔÅÎÉÅÍ ÜÔÏÇÏ ÒÁÚÄÅÌÁ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ: ðÒÏÞÉÔÁÔØ ÓÐÉÓÏË ÐÏÄÄÅÒÖÉ×ÁÅÍÏÇÏ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ËÏÔÏÒÙÊ ÐÒÉÌÁÇÁÅÔÓÑ Ë ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÏÊ ×ÁÍÉ ×ÅÒÓÉÉ &os;, Á ÔÁËÖÅ ÕÂÅÄÉÔØÓÑ, ÞÔÏ ×ÁÛÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ. ÷ ÏÂÝÅÍ, ÜÔÉ ÉÎÓÔÒÕËÃÉÉ ÐÏ ÕÓÔÁÎÏ×ËÅ ÎÁÐÉÓÁÎÙ ÄÌÑ ÍÁÛÉÎ ÁÒÈÉÔÅËÔÕÒÙ &i386; (PC-ÓÏ×ÍÅÓÔÉÍÁÑ). ôÁÍ, ÇÄÅ ÜÔÏ ÎÅÏÂÈÏÄÉÍÏ, ÂÕÄÕÔ ÄÁÎÙ ÕËÁÚÁÎÉÑ ÄÌÑ ÄÒÕÇÉÈ ÐÌÁÔÆÏÒÍ. íÅÖÄÕ ÕÓÔÁÎÏ×ÝÉËÏÍ É ÜÔÉÍ ÄÏËÕÍÅÎÔÏÍ ÍÏÇÕÔ ÂÙÔØ ÎÅÚÎÁÞÉÔÅÌØÎÙÅ ÒÁÚÌÉÞÉÑ, ÐÏÜÔÏÍÕ ÉÓÐÏÌØÚÕÊÔÅ ÜÔÕ ÇÌÁ×Õ ËÁË ÏÂÝÅÅ ÒÕËÏ×ÏÄÓÔ×Ï, Á ÎÅ ËÁË ÔÏÞÎÕÀ ÐÏÛÁÇÏ×ÕÀ ÉÎÓÔÒÕËÃÉÀ. áÐÐÁÒÁÔÎÙÅ ÔÒÅÂÏ×ÁÎÉÑ íÉÎÉÍÁÌØÎÁÑ ËÏÎÆÉÇÕÒÁÃÉÑ íÉÎÉÍÁÌØÎÁÑ ÁÐÐÁÒÁÔÎÁÑ ËÏÎÆÉÇÕÒÁÃÉÑ, ÄÏÓÔÁÔÏÞÎÁÑ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;, ÚÁ×ÉÓÉÔ ÏÔ ×ÅÒÓÉÉ &os; É ÏÔ ÁÐÐÁÒÁÔÎÏÊ ÁÒÈÉÔÅËÔÕÒÙ. ëÒÁÔËÏÅ ÉÚÌÏÖÅÎÉÅ ÜÔÏÊ ÉÎÆÏÒÍÁÃÉÉ ÄÁÎÏ × ÓÌÅÄÕÀÝÉÈ ÒÁÚÄÅÌÁÈ. ÷ ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÓÐÏÓÏÂÁ ÕÓÔÁÎÏ×ËÉ &os; ×ÁÍ ÔÁËÖÅ ÍÏÖÅÔ ÐÏÔÒÅÂÏ×ÁÔØÓÑ ÐÏÄÄÅÒÖÉ×ÁÅÍÙÊ ÐÒÉ×ÏÄ CDROM, Á × ÎÅËÏÔÏÒÙÈ ÓÌÕÞÁÑÈ — ÓÅÔÅ×ÏÊ ÁÄÁÐÔÅÒ. ï ÜÔÏÍ ÂÕÄÅÔ ÓËÁÚÁÎÏ × . &os;/&arch.i386; äÌÑ &os;/&arch.i386; ÎÅÏÂÈÏÄÉÍ 486 ÐÒÏÃÅÓÓÏÒ ÉÌÉ ×ÙÛÅ, Á ÔÁËÖÅ — ËÁË ÍÉÎÉÍÕÍ 64 íâ ïúõ. äÌÑ ÓÁÍÏÊ ÍÉÎÉÍÁÌØÎÏÊ ÕÓÔÁÎÏ×ËÉ ÐÏÔÒÅÂÕÅÔÓÑ ÎÅ ÍÅÎÅÅ 1.1 çâ Ó×ÏÂÏÄÎÏÇÏ ÍÅÓÔÁ ÎÁ ÖÅÓÔËÏÍ ÄÉÓËÅ. äÌÑ ÕÓÔÁÒÅ×ÛÉÈ ËÏÍÐØÀÔÅÒÏ× ÂÏÌÅÅ ÜÆÆÅËÔÉ×ÎÙÍ ÓÐÏÓÏÂÏÍ ÐÏ×ÙÛÅÎÉÑ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ Ñ×ÌÑÅÔÓÑ Õ×ÅÌÉÞÅÎÉÅ ÏÂßÅÍÁ ïúõ É ÏÂßÅÍÁ ÖÅÓÔËÏÇÏ ÄÉÓËÁ, ÎÅÖÅÌÉ ÕÓÔÁÎÏ×ËÁ ÂÏÌÅÅ ÂÙÓÔÒÏÄÅÊÓÔ×ÕÀÝÅÇÏ ÐÒÏÃÅÓÓÏÒÁ. &os;/&arch.amd64; óÕÝÅÓÔ×ÕÅÔ Ä×Á ËÌÁÓÓÁ ÐÒÏÃÅÓÓÏÒÏ×, ÎÁ ËÏÔÏÒÙÈ ÍÏÖÅÔ ÒÁÂÏÔÁÔØ &os;/&arch.amd64;. ë ÐÅÒ×ÏÍÕ ÐÒÉÎÁÄÌÅÖÁÔ ÐÒÏÃÅÓÓÏÒÙ AMD64, ×ËÌÀÞÁÑ &amd.athlon;64, &amd.athlon;64-FX, &amd.opteron; É ÂÏÌÅÅ ÎÏ×ÙÅ. ëÏ ×ÔÏÒÏÍÕ ËÌÁÓÓÕ ÐÒÏÃÅÓÓÏÒÏ×, ÎÁ ËÏÔÏÒÙÈ ÒÁÂÏÔÁÅÔ &os;/&arch.amd64;, ÐÒÉÎÁÄÌÅÖÁÔ ÐÒÏÃÅÓÓÏÒÙ ÁÒÈÉÔÅËÔÕÒÙ &intel; EM64T. ðÅÒÅÞÅÎØ ÐÒÏÃÅÓÓÏÒÏ× ×ËÌÀÞÁÅÔ ÓÌÅÄÕÀÝÉÅ ÓÅÍÅÊÓÔ×Á: &intel; &core; 2 Duo, Quad, Extreme, ÓÅÍÅÊÓÔ×Á &intel; &xeon; 3000, 5000 É 7000, Á ÔÁËÖÅ   &intel; &core; i3, i5 É i7. åÓÌÉ ×ÁÛ ËÏÍÐØÀÔÅÒ ÐÏÓÔÒÏÅÎ ÎÁ ÞÉÐÓÅÔÅ nVidia nForce3 Pro-150, ÔÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÏÔËÌÀÞÉÔØ IO APIC × BIOS. åÓÌÉ ÄÌÑ ÜÔÏÇÏ ÎÅÔ ÏÐÃÉÉ × BIOS, ÏÔËÌÀÞÉÔÅ ACPI × ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÅ. ÷ ÞÉÐÓÅÔÅ Pro-150 ÓÏÄÅÒÖÁÔÓÑ ÏÛÉÂËÉ, ÄÌÑ ËÏÔÏÒÙÈ ÐÏËÁ ÎÅ ÓÕÝÅÓÔ×ÕÅÔ ÉÓÐÒÁ×ÌÅÎÉÊ. &os;/&arch.powerpc; &apple; &macintosh; ðÏÄÄÅÒÖÉ×ÁÀÔÓÑ ×ÓÅ ÁÍÅÒÉËÁÎÓËÉÅ ÓÉÓÔÅÍÙ &apple; &macintosh; Ó ×ÓÔÒÏÅÎÎÙÍ USB. äÌÑ ÍÎÏÇÏÐÒÏÃÅÓÓÏÒÎÙÈ ÍÁÛÉÎ ÅÓÔØ ÐÏÄÄÅÒÖËÁ SMP. ñÄÒÏ (32-ÂÉÔ) ÍÏÖÅÔ ÁÄÒÅÓÏ×ÁÔØ ÌÉÛØ ÐÅÒ×ÙÅ 2 çâ ïúõ. îÁ Blue & White PowerMac G3 ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ &firewire;. &os;/&arch.sparc64; ðÏÄÄÅÒÖÉ×ÁÅÍÙÅ &os;/&arch.sparc64; ÓÉÓÔÅÍÙ ÐÅÒÅÞÉÓÌÅÎÙ × ÐÒÏÅËÔÅ FreeBSD/sparc64. äÌÑ &os;/&arch.sparc64; ÔÒÅÂÕÅÔÓÑ ÏÔÄÅÌØÎÙÊ ÖÅÓÔËÉÊ ÄÉÓË. îÁ ÄÁÎÎÙÊ ÍÏÍÅÎÔ ÎÅÔ ×ÏÚÍÏÖÎÏÓÔÉ ÒÁÚÄÅÌÑÔØ ÄÉÓË Ó ÄÒÕÇÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ. ðÏÄÄÅÒÖÉ×ÁÅÍÏÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ áÒÈÉÔÅËÔÕÒÙ É ÕÓÔÒÏÊÓÔ×Á, ÐÏÄÄÅÒÖÉ×ÁÅÍÙÅ ËÁÖÄÙÍ ÒÅÌÉÚÏÍ &os;, ÐÅÒÅÞÉÓÌÅÎÙ × ÆÁÊÌÅ Hardware Notes. æÁÊÌ, ËÁË ÐÒÁ×ÉÌÏ, ÎÁÚÙ×ÁÅÔÓÑ HARDWARE.TXT, É ÒÁÓÐÏÌÁÇÁÅÔÓÑ × ËÏÒÎÅ×ÏÍ ËÁÔÁÌÏÇÅ ÕÓÔÁÎÏ×ÏÞÎÏÇÏ ÎÏÓÉÔÅÌÑ. ôÁËÖÅ ËÏÐÉÉ ÓÐÉÓËÁ ÐÏÄÄÅÒÖÉ×ÁÅÍÏÇÏ ÏÂÏÒÕÄÏ×ÁÎÉÑ ÎÁÈÏÄÑÔÓÑ ÎÁ ÓÔÒÁÎÉÃÅ Release Information ×Å ÓÁÊÔÁ &os;. ðÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ óÄÅÌÁÊÔÅ ÒÅÚÅÒ×ÎÙÅ ËÏÐÉÉ ÄÁÎÎÙÈ óÄÅÌÁÊÔÅ ÒÅÚÅÒ×ÎÙÅ ËÏÐÉÉ ×ÓÅÈ ×ÁÖÎÙÈ ÄÁÎÎÙÈ Ó ÔÏÇÏ ËÏÍÐØÀÔÅÒÁ, ÎÁ ËÏÔÏÒÙÊ ÐÌÁÎÉÒÕÅÔÓÑ ÕÓÔÁÎÏ×ËÁ &os;. ðÒÏ×ÅÒØÔÅ ÐÒÉÇÏÄÎÏÓÔØ ÒÅÚÅÒ×ÎÙÈ ËÏÐÉÊ ÄÏ ÎÁÞÁÌÁ ÕÓÔÁÎÏ×ËÉ. ðÅÒÅÄ ×ÎÅÓÅÎÉÅÍ ÉÚÍÅÎÅÎÉÊ ÎÁ ÄÉÓË ÉÎÓÔÁÌÌÑÔÏÒ &os; ÚÁÐÒÏÓÉÔ ÐÏÄÔ×ÅÒÖÄÅÎÉÅ, ÎÏ ËÁË ÔÏÌØËÏ ÉÚÍÅÎÅÎÉÑ ÂÕÄÕÔ ×ÎÅÓÅÎÙ, ÔÏ ÏÔÍÅÎÉÔØ ÉÈ ÕÖÅ ÂÕÄÅÔ ÎÅ×ÏÚÍÏÖÎÏ. òÅÛÉÔÅ ËÕÄÁ ÕÓÔÁÎÏ×ÉÔØ &os; åÓÌÉ &os; ÂÕÄÅÔ ÅÄÉÎÓÔ×ÅÎÎÏÊ ÕÓÔÁÎÏ×ÌÅÎÎÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ, É ÏÎÁ ÂÕÄÅÔ ÚÁÎÉÍÁÔØ ×ÅÓØ ÖÅÓÔËÉÊ ÄÉÓË, ÔÏ ÍÏÖÅÔÅ ÓÍÅÌÏ ÐÒÏÐÕÓÔÉÔØ ÜÔÏÔ ÒÁÚÄÅÌ. îÏ ÅÓÌÉ &os; ÂÕÄÅÔ ÒÁÚÄÅÌÑÔØ ÄÉÓË Ó ÄÒÕÇÉÍÉ ÏÐÅÒÁÃÉÏÎÎÙÍÉ ÓÉÓÔÅÍÁÍÉ, ÔÏ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ ×ÁÍ ÐÏÎÁÄÏÂÉÔÓÑ ÐÏÎÉÍÁÎÉÅ ÐÒÉÎÃÉÐÏ× ÒÁÚÂÉÅÎÉÑ ÄÉÓËÏ×. òÁÚÄÅÌÙ ÄÉÓËÁ ÄÌÑ &os;/&arch.i386; É &os;/&arch.amd64; ÷ÅÓØ ÏÂßÅÍ ÖÅÓÔËÉÈ ÄÉÓËÏ× ÍÏÖÅÔ ÂÙÔØ ÒÁÚÄÅÌÅÎ ÎÁ ÍÎÏÖÅÓÔ×Ï ÞÁÓÔÅÊ. üÔÉ ÞÁÓÔÉ ÎÁÚÙ×ÁÀÔÓÑ ÒÁÚÄÅÌÁÍÉ. åÓÔØ Ä×Á ÓÐÏÓÏÂÁ ÄÅÌÅÎÉÑ ÄÉÓËÁ ÎÁ ÒÁÚÄÅÌÙ. ôÒÁÄÉÃÉÏÎÎÙÊ ÓÐÏÓÏ — Master Boot Record (MBR) — ÈÒÁÎÉÔ ÔÁÂÌÉÃÕ ÒÁÚÄÅÌÏ×, ×ÍÅÝÁÀÝÕÀ ÄÏ ÞÅÔÙÒÅÈ ÐÅÒ×ÉÞÎÙÈ ÒÁÚÄÅÌÏ×. (ôÁË ÓÌÏÖÉÌÏÓØ ÉÓÔÏÒÉÞÅÓËÉ, ÞÔÏ ×Ï &os; ÜÔÉ ÒÁÚÄÅÌÙ ÎÁÚÙ×ÁÀÔÓÑ ÓÌÁÊÓÁÍÉ.) ÷ÏÚÍÏÖÎÙ ÓÉÔÕÁÃÉÉ, × ËÏÔÏÒÙÈ ÞÅÔÙÒÅ ÒÁÚÄÅÌÁ ÎÅÄÏÓÔÁÔÏÞÎÏ, ÐÏÜÔÏÍÕ ÏÄÉÎ ÉÚ ÐÅÒ×ÉÞÎÙÈ ÒÁÚÄÅÌÏ× ÍÏÖÅÔ ÂÙÔØ ÐÒÅ×ÒÁÝÅÎ × ÒÁÓÛÉÒÅÎÎÙÊ ÒÁÚÄÅÌ. ÷ÎÕÔÒÉ ÒÁÓÛÉÒÅÎÎÏÇÏ ÒÁÚÄÅÌÁ ÍÏÖÅÔ ÂÙÔØ ÓÏÚÄÁÎÏ ÎÅÓËÏÌØËÏ ÌÏÇÉÞÅÓËÉÈ ÒÁÚÄÅÌÏ×. òÅÚÕÌØÔÉÒÕÀÝÁÑ ÓÔÒÕËÔÕÒÁ ×ÙÇÌÑÄÉÔ ÎÅÍÎÏÇÏ ÎÅÕËÌÀÖÅ, ÎÏ ÔÁËÏ×Á ÏÎÁ ÅÓÔØ. óÏÚÄÁÎÉÅ ôÁÂÌÉÃÙ òÁÚÄÅÌÏ× GUID (GUID Partition Table, GPT) — ÜÔÏ ÂÏÌÅÅ ÎÏ×ÙÊ É ÐÒÏÓÔÏÊ ÓÐÏÓÏ ÄÅÌÅÎÉÑ ÄÉÓËÁ. ôÁËÖÅ ÎÏ×ÙÊ ÓÐÏÓÏ (GPT) ÐÏ ÓÒÁ×ÎÅÎÉÀ Ó ÔÒÁÄÉÃÉÏÎÎÙÍ ÓÐÏÓÏÂÏÍ ÒÁÚÂÉÅÎÉÑ (MBR) ÇÏÒÁÚÄÏ ÂÏÌÅÅ ÇÉÂËÉÊ. òÁÓÐÒÏÓÔÒÁΣÎÎÙÅ ÒÅÁÌÉÚÁÃÉÉ GPT ÐÏÚ×ÏÌÑÀÔ ÓÏÚÄÁ×ÁÔØ ÄÏ 128 ÒÁÚÄÅÌÏ× ÎÁ ÏÄÎÏÍ ÄÉÓËÅ, ÔÅÍ ÓÁÍÙÍ ÉÓËÌÀÞÁÑ ÎÅÏÂÈÏÄÉÍÏÓÔØ ÓÏÚÄÁÎÉÑ ÎÅÕÄÏÂÎÙÈ ÓÕÝÎÏÓÔÅÊ ÎÁÐÏÄÏÂÉÅ ÌÏÇÉÞÅÓËÉÈ ÄÉÓËÏ×. îÅËÏÔÏÒÙÅ ÓÔÁÒÙÅ ÏÐÅÒÁÃÉÏÎÎÙÅ ÓÉÓÔÅÍÙ, ÎÁÐÒÉÍÅÒ &windows; XP, ÎÅ ÓÏ×ÍÅÓÔÉÍÙ ÓÏ ÓÈÅÍÏÊ GPT. åÓÌÉ ÎÁ ÏÄÉÎ ÄÉÓË ÎÅÏÂÈÏÄÉÍÏ ÕÓÔÁÎÏ×ÉÔØ &os; ÓÏ×ÍÅÓÔÎÏ Ó ÔÁËÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ, ÔÏ ÓÌÅÄÕÅÔ ×ÏÓÐÏÌØÚÏ×ÁÔØÓÑ ÓÈÅÍÏÊ MBR. óÔÁÎÄÁÒÔÎÏÍÕ ÚÁÇÒÕÚÞÉËÕ &os; ÎÅÏÂÈÏÄÉÍ ÐÅÒ×ÉÞÎÙÊ ÒÁÚÄÅÌ (MBR) ÉÌÉ GPT ÒÁÚÄÅÌ. (ïÂÒÁÔÉÔÅÓØ Ë ÚÁ ÂÏÌÅÅ ÐÏÄÒÏÂÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ Ï ÐÒÏÃÅÓÓÅ ÚÁÇÒÕÚËÉ &os;.) åÓÌÉ ×ÓÅ ÐÅÒ×ÉÞÎÙÅ ÉÌÉ GPT ÒÁÚÄÅÌÙ ÕÖÅ ÚÁÄÅÊÓÔ×Ï×ÁÎÙ, ÔÏ ÄÌÑ &os; ÏÄÉÎ ÉÚ ÎÉÈ ÎÅÏÂÈÏÄÉÍÏ ÂÕÄÅÔ ÏÓ×ÏÂÏÄÉÔØ. íÉÎÉÍÁÌØÎÁÑ ÕÓÔÁÎÏ×ËÁ &os; ÚÁÎÉÍÁÅÔ ÎÉ ÍÎÏÇÏ ÎÉ ÍÁÌÏ — 1 çâ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á. ïÄÎÁËÏ, ÜÔÏ ÏÞÅÎØ ÍÉÎÉÍÁÌØÎÁÑ ÕÓÔÁÎÏ×ËÁ, ÐÒÁËÔÉÞÅÓËÉ ÎÅ ÏÓÔÁ×ÌÑÀÝÁÑ Ó×ÏÂÏÄÎÏÇÏ ÍÅÓÔÁ. âÏÌÅÅ ÒÅÁÌÉÓÔÉÞÎÙÍ ÍÉÎÉÍÕÍÏÍ Ñ×ÌÑÅÔÓÑ 3 çâ ÂÅÚ ÇÒÁÆÉÞÅÓËÏÊ ÐÏÄÓÉÓÔÅÍÙ, Á ÅÓÌÉ ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÇÒÁÆÉÞÅÓËÁÑ ÐÏÄÓÉÓÔÅÍÁ, ÔÏ 5 çâ ÉÌÉ ÂÏÌÅÅ. ó×ÏÂÏÄÎÏÅ ÐÒÏÓÔÒÁÎÓÔ×Ï ÔÁËÖÅ ÐÏÔÒÅÂÕÅÔÓÑ ÐÒÉÌÏÖÅÎÉÑÍ ÏÔ ÔÒÅÔØÉÈ ÌÉÃ. äÌÑ ÓÏÚÄÁÎÉÑ ÒÁÚÄÅÌÏ× ÓÕÝÅÓÔ×ÕÅÔ ÒÁÚÎÏÏÂÒÁÚÉÅ Ó×ÏÂÏÄÎÏ ÒÁÓÐÒÏÓÔÒÁÎÑÅÍÙÈ É ËÏÍÍÅÒÞÅÓËÉÈ ÕÔÉÌÉÔ. GParted Live ÜÔÏ Ó×ÏÂÏÄÎÏ ÒÁÓÐÒÏÓÔÒÁÎÑÅÍÙÊ ÚÁÇÒÕÚÏÞÎÙÊ ÄÉÓÔÒÉÂÕÔÉ×, × ËÏÔÏÒÙÊ ×ËÌÀÞÅÎ ÒÅÄÁËÔÏÒ ÒÁÚÄÅÌÏ× GParted. ôÁËÖÅ GParted ×ËÌÀÞÅÎ × ÍÎÏÇÉÅ ÄÒÕÇÉÅ ÄÉÓÔÒÉÂÕÔÉ×Ù Live CD ÏÔ Linux. õÔÉÌÉÔÙ ÄÌÑ ÓÏÚÄÁÎÉÑ ÒÁÚÄÅÌÏ× ÍÏÇÕÔ ÐÏ×ÒÅÄÉÔØ ×ÁÛÉ ÄÁÎÎÙÅ. ðÏÜÔÏÍÕ ÓÄÅÌÁÊÔÅ ÐÏÌÎÕÀ ÒÅÚÅÒ×ÎÕÀ ËÏÐÉÀ É ÐÒÏ×ÅÒØÔŠţ ÃÅÌÏÓÔÎÏÓÔØ ÐÅÒÅÄ ÍÏÄÉÆÉËÁÃÉÅÊ ÒÁÚÄÅÌÏ× ÄÉÓËÁ. ïÐÒÅÄÅÌÅÎÎÙÅ ÔÒÕÄÎÏÓÔÉ ÓÏÓÔÁ×ÌÑÅÔ ÉÚÍÅÎÅÎÉÅ ÒÁÚÍÅÒÏ× ÒÁÚÄÅÌÏ× µsoft; Vista. ÷ ÔÁËÉÈ ÓÌÕÞÁÑÈ ÍÏÖÅÔ ÐÒÉÇÏÄÉÔØÓÑ ÕÓÔÁÎÏ×ÏÞÎÙÊ CDROM ÏÔ ÓÁÍÏÊ µsoft; Vista. éÓÐÏÌØÚÏ×ÁÎÉÅ ÓÕÝÅÓÔ×ÕÀÝÅÇÏ ÒÁÚÄÅÌÁ ëÏÍÐØÀÔÅÒ Ó ïó &windows; ÉÍÅÅÔ ÖÅÓÔËÉÊ ÄÉÓË ÒÁÚÍÅÒÏÍ 40 çâ, ÄÉÓË ÒÁÚÂÉÔ ÎÁ Ä×Á ÒÁÚÄÅÌÁ ÐÏ 20 çâ. &windows; ÉÍÅÎÕÅÔ ÉÈ ÄÉÓËÁÍÉ C: É D:. îÁ ÄÉÓËÅ C: ÄÁÎÎÙÍÉ ÚÁÎÑÔÏ 10 çâ, Á ÎÁ ÄÉÓËÅ D: — 5 çâ. ðÅÒÅÍÅÝÅÎÉÅ ÄÁÎÎÙÈ Ó ÄÉÓËÁ D: ÎÁ ÄÉÓË C: ÏÓ×ÏÂÏÖÄÁÅÔ ×ÔÏÒÏÊ ÒÁÚÄÅÌ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;. õÍÅÎØÛÅÎÉÅ ÒÁÚÍÅÒÁ ÓÕÝÅÓÔ×ÕÀÝÅÇÏ ÒÁÚÄÅÌÁ ëÏÍÐØÀÔÅÒ Ó ïó &windows; ÉÍÅÅÔ ÖÅÓÔËÉÊ ÄÉÓË ÒÁÚÍÅÒÏÍ 40 çâ, ÎÁ ËÏÔÏÒÏÍ ÓÏÚÄÁÎ ÏÄÉÎ ÂÏÌØÛÏÊ ÒÁÚÄÅÌ, ÚÁÎÉÍÁÀÝÉÊ ×ÅÓØ ÖÅÓÔËÉÊ ÄÉÓË. &windows; ÉÍÅÎÕÅÔ ÜÔÏÔ ÒÁÚÄÅÌ ÄÉÓËÏÍ C:. îÁ ÜÔÏÍ ÒÁÚÄÅÌÅ ÄÁÎÎÙÅ ÚÁÎÉÍÁÀÔ 15 çâ. ëÏÎÅÞÎÁÑ ÃÅÌØ — ÏÔ×ÅÓÔÉ ÄÌÑ &windows; ÒÁÚÄÅÌ ÒÁÚÍÅÒÏÍ 20 çâ, Á ×ÔÏÒÏÊ ÒÁÚÄÅÌ ÒÁÚÍÅÒÏÍ 20 çâ ÚÁÄÅÊÓÔ×Ï×ÁÔØ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;. ðÏÄÏÂÎÏÅ ÐÅÒÅÒÁÓÐÒÅÄÅÌÅÎÉÅ ÍÏÖÎÏ ×ÙÐÏÌÎÉÔØ ÏÄÎÉÍ ÉÚ Ä×ÕÈ ÓÐÏÓÏÂÏ×: óÄÅÌÁÊÔÅ ÒÅÚÅÒ×ÎÕÀ ËÏÐÉÀ ÄÁÎÎÙÈ ×ÁÛÅÊ &windows;. äÁÌÅÅ, ÐÅÒÅÕÓÔÁÎÏ×ÉÔÅ &windows;, ÓÏÚÄÁ× ×Ï ×ÒÅÍÑ ÉÎÓÔÁÌÌÑÃÉÉ ÒÁÚÄÅÌ ÒÁÚÍÅÒÏÍ 20 çâ. éÓÐÏÌØÚÕÊÔÅ ÕÔÉÌÉÔÕ ÒÅÄÁËÔÉÒÏ×ÁÎÉÑ ÒÁÚÄÅÌÏ× (ÎÁÐÏÄÏÂÉÅ GParted) ÄÌÑ ÕÍÅÎØÛÅÎÉÑ ÒÁÚÄÅÌÁ &windows;, Á × ÏÓ×ÏÂÏÄÉ×ÛÅÍÓÑ ÐÒÏÓÔÒÁÎÓÔ×Å ÓÏÚÄÁÊÔÅ ÎÏ×ÙÊ ÒÁÚÄÅÌ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;. òÁÚÄÅÌÙ ÄÉÓËÁ, ÓÏÄÅÒÖÁÝÉÅ ÒÁÚÎÙÅ ÏÐÅÒÁÃÉÏÎÎÙÅ ÓÉÓÔÅÍÙ, ÄÅÌÁÀÔ ×ÏÚÍÏÖÎÏÊ ÚÁÇÒÕÚËÕ ÐÏ ×ÙÂÏÒÕ ÏÄÎÏÊ ÉÚ ÉÍÅÀÝÉÈÓÑ ÏÐÅÒÁÃÉÏÎÎÙÈ ÓÉÓÔÅÍ. áÌØÔÅÒÎÁÔÉ×ÎÙÊ ÓÐÏÓÏÂ, ÐÏÚ×ÏÌÑÀÝÉÊ ÚÁÇÒÕÖÁÔØ ÎÅÓËÏÌØËÏ ÏÐÅÒÁÃÉÏÎÎÙÈ ÓÉÓÔÅÍ × ÏÄÎÏ É ÔÏ ÖÅ ×ÒÅÍÑ, ÏÐÉÓÁÎ × ÒÁÚÄÅÌÅ, ÎÁÚÙ×ÁÅÍÏÍ virtualization. óÏÂÅÒÉÔÅ ÉÎÆÏÒÍÁÃÉÀ Ï ÓÅÔÅ×ÙÈ ÎÁÓÔÒÏÊËÁÈ îÅËÏÔÏÒÙÍ ×ÁÒÉÁÎÔÁÍ ÕÓÔÁÎÏ×ËÉ &os; ÄÌÑ ÚÁÇÒÕÚËÉ ÆÁÊÌÏ× ÎÅÏÂÈÏÄÉÍÏ ÎÁÌÉÞÉÅ ÓÏÅÄÉÎÅÎÉÑ Ó ÓÅÔØÀ. éÎÓÔÁÌÌÑÔÏÒ ÚÁÐÒÏÓÉÔ ÉÎÆÏÒÍÁÃÉÀ Ï ÐÏÄËÌÀÞÅÎÉÉ ÄÌÑ ÎÁÓÔÒÏÊËÉ ÓÏÅÄÉÎÅÎÉÑ Ó ÓÅÔØÀ ÞÅÒÅÚ ÉÎÔÅÒÆÅÊÓ Ethernet (ÞÅÒÅÚ ËÁÂÅÌØÎÙÊ ÍÏÄÅÍ ÉÌÉ Ë ÍÏÄÅÍ DSL Ó ÉÎÔÅÒÆÅÊÓÏÍ Ethernet). äÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÇÏ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ ÓÅÔÅ×ÙÈ ÉÎÔÅÒÆÅÊÓÏ× ÞÁÓÔÏ ÐÒÉÍÅÎÑÅÔÓÑ ÐÒÏÔÏËÏÌ DHCP. åÓÌÉ × ÐÏÄËÌÀÞÁÅÍÏÊ ÓÅÔÉ ÓÅÒ×ÉÓ DHCP ÏÔÓÕÔÓÔ×ÕÅÔ, ÉÎÆÏÒÍÁÃÉÀ Ï ÐÏÄËÌÀÞÅÎÉÉ Ë ÎÅÏÂÈÏÄÉÍÏ ×ÚÑÔØ Õ ÓÉÓÔÅÍÎÏÇÏ ÁÄÍÉÎÉÓÔÒÁÔÏÒÁ ÉÌÉ ÐÒÏ×ÁÊÄÅÒÁ éÎÔÅÒÎÅÔ. éÎÆÏÒÍÁÃÉÑ Ï ÐÏÄËÌÀÞÅÎÉÉ Ë ÓÅÔÉ IP ÁÄÒÅÓ íÁÓËÁ ÐÏÄÓÅÔÉ IP ÁÄÒÅÓ ÛÌÀÚÁ ÐÏ ÕÍÏÌÞÁÎÉÀ äÏÍÅÎÎÏÅ ÉÍÑ ÌÏËÁÌØÎÏÊ ÓÅÔÉ IP ÁÄÒÅÓ DNS ÓÅÒ×ÅÒÁ/ÓÅÒ×ÅÒÏ× ðÒÏ×ÅÒØÔÅ Ó×ÅÄÅÎÉÑ Ï ÏÂÎÁÒÕÖÅÎÎÙÈ ÏÛÉÂËÁÈ &os; èÏÔÑ ÐÒÏÅËÔ &os; ÂÏÒÅÔÓÑ ÚÁ ÔÏ, ÞÔÏÂÙ ËÁÖÄÙÊ ÒÅÌÉÚ &os; ÂÙÌ ÎÁÓÔÏÌØËÏ ÓÔÁÂÉÌØÎÙÍ, ÎÁÓËÏÌØËÏ ÜÔÏ ×ÏÚÍÏÖÎÏ, ÏÛÉÂËÉ ÐÏÒÏÊ ×ËÒÁÄÙ×ÁÀÔÓÑ × ÐÒÏÃÅÓÓ ÒÁÚÒÁÂÏÔËÉ. ÷ ÏÞÅÎØ ÒÅÄËÉÈ ÓÌÕÞÁÑÈ ÜÔÉ ÏÛÉÂËÉ ×ÌÉÑÀÔ ÎÁ ÐÒÏÃÅÓÓ ÕÓÔÁÎÏ×ËÉ. ëÁË ÔÏÌØËÏ ÜÔÉ ÐÒÏÂÌÅÍÙ ÏÂÎÁÒÕÖÉ×ÁÀÔÓÑ É ÉÓÐÒÁ×ÌÑÀÔÓÑ, ÉÈ ÏÐÉÓÁÎÉÅ ÐÏÐÁÄÁÅÔ × ÓÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ &os;, ÎÁÈÏÄÑÝÉÅÓÑ ÎÁ ÓÁÊÔÅ &os;. ðÒÏ×ÅÒØÔÅ ÓÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ ÐÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ É ÕÂÅÄÉÔÅÓØ, ÞÔÏ ÏÔÓÕÔÓÔ×ÕÀÔ ÐÒÏÂÌÅÍÙ, ËÏÔÏÒÙÅ ÍÏÇÕÔ ÚÁÔÒÏÎÕÔØ ÕÓÔÁÎÏ×ËÕ. éÎÆÏÒÍÁÃÉÑ Ï ×ÓÅÈ ÒÅÌÉÚÁÈ, ×ËÌÀÞÁÑ ÓÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ ËÁÖÄÏÇÏ ÒÅÌÉÚÁ, ÍÏÖÅÔ ÂÙÔØ ÎÁÊÄÅÎÁ ÎÁ ÓÔÒÁÎÉÃÅ ÉÎÆÏÒÍÁÃÉÉ Ï ÒÅÌÉÚÁÈ ×Å ÓÁÊÔÁ &os;. ðÏÄÇÏÔÏ×ËÁ ÕÓÔÁÎÏ×ÏÞÎÏÇÏ ÎÏÓÉÔÅÌÑ ÉÎÆÏÒÍÁÃÉÉ õÓÔÁÎÏ×ËÁ &os; ÎÁÞÉÎÁÅÔÓÑ Ó ÚÁÇÒÕÚËÉ ËÏÍÐØÀÔÅÒÁ Ó ÕÓÔÁÎÏ×ÏÞÎÏÇÏ ÎÏÓÉÔÅÌÑ, ÂÕÄØ ÔÏ CD, DVD ÉÌÉ USB ÆÌÅÛ-ÎÁËÏÐÉÔÅÌØ. éÎÓÔÁÌÌÑÔÏÒ — ÜÔÏ ÎÅ ÔÁ ÐÒÏÇÒÁÍÍÁ, ËÏÔÏÒÕÀ ÍÏÖÎÏ ÚÁÐÕÓÔÉÔØ ÉÚ ÄÒÕÇÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ. ÷ ÄÏÐÏÌÎÅÎÉÅ Ë ÓÔÁÎÄÁÒÔÎÏÍÕ ÕÓÔÁÎÏ×ÏÞÎÏÍÕ ÎÏÓÉÔÅÌÀ, ËÏÔÏÒÙÊ ÓÏÄÅÒÖÉÔ ËÏÐÉÉ ×ÓÅÈ ÕÓÔÁÎÏ×ÏÞÎÙÈ ÆÁÊÌÏ× &os;, ÔÁËÖÅ ÓÕÝÅÓÔ×ÕÅÔ ×ÁÒÉÁÎÔ, ÐÒÅÄÎÁÚÎÁÞÅÎÎÙÊ ÉÓËÌÀÞÉÔÅÌØÎÏ ÄÌÑ ÚÁÇÒÕÚËÉ É ÎÁÚÙ×ÁÅÍÙÊ bootonly. õÓÔÁÎÏ×ÏÞÎÙÊ ÎÏÓÉÔÅÌØ bootonly ÎÅ ÓÏÄÅÒÖÉÔ ËÏÐÉÊ ÉÎÓÔÁÌÌÑÃÉÏÎÎÙÈ ÆÁÊÌÏ×, Á ÚÁÇÒÕÖÁÅÔ ÉÈ ÉÚ ÓÅÔÉ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ. ðÏÜÔÏÍÕ ÏÂÒÁÚ bootonly CD ÇÏÒÁÚÄÏ ÍÅÎØÛÅ ÏÂßÅÍÏÍ, Á ÔÁËÖÅ ÐÒÉ ÅÇÏ ÉÓÐÏÌØÚÏ×ÁÎÉÉ ÚÁÇÒÕÖÁÀÔÓÑ ÌÉÛØ ÎÅÏÂÈÏÄÉÍÙÅ ÆÁÊÌÙ, ÔÅÍ ÓÁÍÙÍ ÕÍÅÎØÛÁÅÔÓÑ ÎÁÇÒÕÚËÁ ÎÁ ÓÅÔÅ×ÏÅ ÓÏÅÄÉÎÅÎÉÅ. ëÏÐÉÉ ÏÂÒÁÚÏ× ÕÓÔÁÎÏ×ÏÞÎÙÈ ÎÏÓÉÔÅÌÅÊ ÎÁÈÏÄÑÔÓÑ ÎÁ ×Å ÓÁÊÔÅ &os;. åÓÌÉ Õ ×ÁÓ ÕÖÅ ÉÍÅÅÔÓÑ ËÏÐÉÑ &os; ÎÁ CDROM, DVD, ÉÌÉ USB ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÅ, ÔÏ ÎÉÖÅÓÌÅÄÕÀÝÉÊ ÔÅËÓÔ ÍÏÖÎÏ ÏÐÕÓÔÉÔØ. CD- É DVD-ÏÂÒÁÚÙ &os; Ñ×ÌÑÀÔÓÑ ÚÁÇÒÕÚÏÞÎÙÍÉ. äÌÑ ÕÓÔÁÎÏ×ËÉ ÎÅÏÂÈÏÄÉÍ ÏÄÉÎ ÉÚ ÎÉÈ. úÁÐÉÛÉÔÅ ÏÂÒÁÚ ÎÁ CD ÉÌÉ DVD ÄÉÓË ÐÒÉ ÐÏÍÏÝÉ ÐÒÏÇÒÁÍÍÙ ÄÌÑ ÚÁÐÉÓÉ CD, ËÏÔÏÒÁÑ ÅÓÔØ × ×ÁÛÅÊ ÔÅËÕÝÅÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÅ. äÌÑ ÓÏÚÄÁÎÉÑ ÚÁÇÒÕÚÏÞÎÏÇÏ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÑ ×ÙÐÏÌÎÉÔÅ ÓÌÅÄÕÀÝÉÅ ÛÁÇÉ: - + ðÏÌÕÞÅÎÉÅ ÏÂÒÁÚÁ ÄÌÑ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÑ ïÂÒÁÚÙ ÄÌÑ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÑ ÄÌÑ &os; 9.0-RELEASE É ÂÏÌÅÅ ÐÏÚÄÎÉÈ ÍÏÇÕÔ ÂÙÔØ ÓËÁÞÁÎÙ Ó ËÁÔÁÌÏÇÁ ISO-IMAGES/ ÐÏ ÁÄÒÅÓÕ ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/arch/arch/ISO-IMAGES/version/&os;-version-RELEASE-arch-memstick.img. úÁÍÅÎÉÔÅ arch É version ÓÏÏÔ×ÅÔÓÔ×ÅÎÎÏ ÎÁ ÁÒÈÉÔÅËÔÕÒÕ É ÎÏÍÅÒ ×ÅÒÓÉÉ ËÏÔÏÒÕÀ ×Ù ÐÌÁÎÉÒÕÅÔÅ ÕÓÔÁÎÏ×ÉÔØ. îÁÐÒÉÍÅÒ, ÏÂÒÁÚÙ ÄÌÑ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÅÊ &os;/&arch.i386; 9.0-RELEASE ÎÁÈÏÄÑÔÓÑ ÎÁ . äÌÑ &os; 8.X É ÂÏÌÅÅ ÒÁÎÎÉÈ ×ÅÒÓÉÊ ÉÓÐÏÌØÚÕÅÔÓÑ ÉÎÏÊ ÐÕÔØ ËÁÔÁÌÏÇÏ×. äÅÔÁÌÉ ÚÁÇÒÕÚËÉ É ÕÓÔÁÎÏ×ËÉ &os; 8.X É ÂÏÌÅÅ ÒÁÎÎÉÈ ×ÅÒÓÉÊ ÏÐÉÓÁÎÙ × . éÍÑ ÏÂÒÁÚÁ ÄÌÑ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÑ ÉÍÅÅÔ ÓÕÆÆÉËÓ .img. ëÁÔÁÌÏÇ ISO-IMAGES/ ÓÏÄÅÒÖÉÔ ÏÐÒÅÄÅÌ£ÎÎÏÅ ËÏÌÉÞÅÓÔ×Ï ÒÁÚÎÙÈ ÏÂÒÁÚÏ×, É ×ÙÂÏÒ ËÏÎËÒÅÔÎÏÇÏ ÏÂÒÁÚÁ ÚÁ×ÉÓÉÔ ÏÔ ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÏÊ ×ÅÒÓÉÉ &os;, Á × ÎÅËÏÔÏÒÙÈ ÓÌÕÞÁÑÈ — É ÏÔ ÁÐÐÁÒÁÔÎÏÇÏ ÏÂÅÓÐÅÞÅÎÉÑ. ðÅÒÅÄ ÐÒÏÄÏÌÖÅÎÉÅÍ ÓÄÅÌÁÊÔÅ ÒÅÚÅÒ×ÎÕÀ ËÏÐÉÀ ÄÁÎÎÙÈ Ó ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÑ, ÔÁË ËÁË ÓÌÅÄÕÀÝÁÑ ÐÒÏÃÅÄÕÒÁ ÕÎÉÞÔÏÖÉÔ ÉÈ. úÁÐÉÓØ ÏÂÒÁÚÁ ÎÁ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌØ éÓÐÏÌØÚÏ×ÁÎÉÅ &os; ÄÌÑ ÚÁÐÉÓÉ ÏÂÒÁÚÁ ÷ ÎÉÖÅÓÌÅÄÕÀÝÅÍ ÐÒÉÍÅÒÅ ÐÏËÁÚÁÎÏ ÉÓÐÏÌØÚÏ×ÁÎÉÅ /dev/da0 × ËÁÞÅÓÔ×Å ÕÓÔÒÏÊÓÔ×Á, ÎÁ ËÏÔÏÒÏÅ ÐÒÏÉÚ×ÏÄÉÔÓÑ ÚÁÐÉÓØ. õÄÏÓÔÏ×ÅÒØÔÅÓØ × ÔÏÍ, ÞÔÏ ÃÅÌÅ×ÏÅ ÕÓÔÒÏÊÓÔ×Ï ×ÙÂÒÁÎÏ ×ÅÒÎÏ, ÉÎÁÞÅ ×Ù ÍÏÖÅÔÅ ÐÏ×ÒÅÄÉÔØ ÓÕÝÅÓÔ×ÕÀÝÉÅ ÄÁÎÎÙÅ. úÁÐÉÓØ ÏÂÒÁÚÁ ÐÒÉ ÐÏÍÏÝÉ &man.dd.1; æÁÊÌ .img ÎÅ Ñ×ÌÑÅÔÓÑ ÏÂÙÞÎÙÍ ÆÁÊÌÏÍ. üÔÏ ÏÂÒÁÚ ×ÓÅÇÏ ÓÏÄÅÒÖÉÍÏÇÏ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÑ. üÔÏÔ ÆÁÊÌ ÎÅ ÍÏÖÅÔ ÂÙÔØ ÐÒÏÓÔÏ ÓËÏÐÉÒÏ×ÁÎÎÙÍ ÐÏÄÏÂÎÏ ÏÂÙÞÎÏÍÕ ÆÁÊÌÕ, ÏÎ ÄÏÌÖÅÎ ÂÙÔØ ÚÁÐÉÓÁÎ ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏ ÎÁ ÃÅÌÅ×ÏÅ ÕÓÔÒÏÊÓÔ×Ï ÐÒÉ ÐÏÍÏÝÉ &man.dd.1;: &prompt.root; dd if=&os;-9.0-RELEASE-&arch.i386;-memstick.img of=/dev/da0 bs=64k éÓÐÏÌØÚÏ×ÁÎÉÅ &windows; ÄÌÑ ÚÁÐÉÓÉ ÏÂÒÁÚÁ õÄÏÓÔÏ×ÅÒØÔÅÓØ × ÐÒÁ×ÉÌØÎÏÓÔÉ ×ÙÂÏÒÁ ÂÕË×Ù ÄÉÓËÁ, ÕËÁÚÙ×ÁÅÍÏÊ ËÁË ÃÅÌÅ×ÏÅ ÕÓÔÒÏÊÓÔ×Ï, ÉÎÁÞÅ ×Ù ÐÅÒÅÚÁÐÉÛÅÔÅ É ÐÏ×ÒÅÄÉÔÅ ÓÕÝÅÓÔ×ÕÀÝÉÅ ÄÁÎÎÙÅ. ðÏÌÕÞÅÎÉÅ <application>Image Writer ÄÌÑ &windows;</application> Image Writer ÄÌÑ &windows; — ÜÔÏ Ó×ÏÂÏÄÎÏ ÒÁÓÐÒÏÓÔÒÁÎÑÅÍÏÅ ÐÒÉÌÏÖÅÎÉÅ, ÐÒÉ ÐÏÍÏÝÉ ËÏÔÏÒÏÇÏ ÍÏÖÎÏ ËÏÒÒÅËÔÎÏ ÚÁÐÉÓÁÔØ ÏÂÒÁÚ ÎÁ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌØ. óËÁÞÁÊÔÅ ÅÇÏ Ó É ÓÏÈÒÁÎÉÔÅ × ÌÀÂÕÀ ÄÉÒÅËÔÏÒÉÀ. úÁÐÉÓØ ÏÂÒÁÚÁ ÐÒÉ ÐÏÍÏÝÉ Image Writer ëÌÉËÎÉÔÅ Ä×ÁÖÄÙ ÎÁ ÉËÏÎËÅ Win32DiskImager ÄÌÑ ÚÁÐÕÓËÁ ÐÒÉÌÏÖÅÎÉÑ. õÄÏÓÔÏ×ÅÒØÔÅÓØ, ÞÔÏ ÂÕË×Á ÄÉÓËÁ, ÏÔÏÂÒÁÖÁÅÍÁÑ × ÂÏËÓÅ Device, ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ ÕÓÔÒÏÊÓÔ×Õ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÑ. ëÌÉËÎÉÔÅ ÎÁ ÉËÏÎËÅ Ó ÐÁÐËÏÊ É ×ÙÂÅÒÉÔÅ ÏÂÒÁÚ, ËÏÔÏÒÙÊ ÂÕÄÅÔ ÚÁÐÉÓÁÎ ÎÁ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌØ. îÁÖÍÉÔÅ ËÎÏÐËÕ [ Save ] ÄÌÑ ÐÏÄÔ×ÅÒÖÄÅÎÉÑ ×ÙÂÏÒÁ ÉÍÅÎÉ ÆÁÊÌÁ. ðÒÏ×ÅÒØÔÅ, ÞÔÏ ×Ó£ ×ÅÒÎÏ, Á ÔÁËÖÅ ÞÔÏ ÎÅÔ ÏÔËÒÙÔÙÈ ÄÉÒÅËÔÏÒÉÊ Ó ÆÌÅÛ-ÎÁËÏÐÉÔÅÌÑ × ÄÒÕÇÉÈ ÏËÎÁÈ. ëÏÇÄÁ ×Ó£ ÇÏÔÏ×Ï, ÎÁÖÍÉÔÅ ËÎÏÐËÕ [ Write ] ÄÌÑ ÚÁÐÉÓÉ ÏÂÒÁÚÁ ÎÁ ÆÌÅÛ-ÎÁËÏÐÉÔÅÌØ. õÓÔÁÎÏ×ËÁ Ó ÄÉÓËÅÔ ÂÏÌÅÅ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ. ôÅÐÅÒØ ×Ù ÇÏÔÏ×Ù ÎÁÞÁÔØ ÕÓÔÁÎÏ×ËÕ &os;. îÁÞÁÌÏ ÕÓÔÁÎÏ×ËÉ ðÏ ÕÍÏÌÞÁÎÉÀ, ÕÓÔÁÎÏ×ÝÉË ÎÅ ÉÚÍÅÎÑÅÔ ÄÁÎÎÙÅ ÎÁ ×ÁÛÉÈ ÄÉÓËÁÈ ÄÏ ÔÅÈ ÐÏÒ, ÐÏËÁ ×Ù ÎÅ Õ×ÉÄÉÔÅ ÓÌÅÄÕÀÝÅÅ ÓÏÏÂÝÅÎÉÅ: Your changes will now be written to disk. If you have chosen to overwrite existing data, it will be PERMANENTLY ERASED. Are you sure you want to commit your changes? õÓÔÁÎÏ×ËÁ ÍÏÖÅÔ ÂÙÔØ ÐÒÅÒ×ÁÎÁ × ÌÀÂÏÊ ÍÏÍÅÎÔ ÄÏ ÐÏÑ×ÌÅÎÉÑ ÜÔÏÇÏ ÐÒÅÄÕÐÒÅÖÄÅÎÉÑ, ÐÒÉ ÜÔÏÍ ÓÏÄÅÒÖÉÍÏÅ ÄÉÓËÏ× ÉÚÍÅÎÅÎÏ ÎÅ ÂÕÄÅÔ. åÓÌÉ ×Ù ÏÂÅÓÐÏËÏÅÎÙ ÔÅÍ, ÞÔÏ ÞÔÏ-ÔÏ ÂÙÌÏ ÎÁÓÔÒÏÅÎÏ ÎÅ×ÅÒÎÏ, ÔÏ ×Ù ÍÏÖÅÔÅ ÐÒÏÓÔÏ ×ÙËÌÀÞÉÔØ ËÏÍÐØÀÔÅÒ ÄÏ ÜÔÏÇÏ ÓÏÏÂÝÅÎÉÑ, ÐÒÉ ÜÔÏÍ ÎÉËÁËÉÈ ÐÏ×ÒÅÖÄÅÎÉÊ ÓÕÝÅÓÔ×ÕÀÝÉÈ ÄÁÎÎÙÈ ÎÅ ÐÒÏÉÚÏÊÄÅÔ. úÁÇÒÕÚËÁ úÁÇÒÕÚËÁ ÎÁ &i386; É &arch.amd64; åÓÌÉ ×Ù ÐÏÄÇÏÔÏ×ÉÌÉ ÚÁÇÒÕÚÏÞÎÙÊ USB-ÎÁËÏÐÉÔÅÌØ, ËÁË ÏÐÉÓÁÎÏ × , ÔÏ ×ÓÔÁרÔÅ ÅÇÏ × USB ÇÎÅÚÄÏ ÐÅÒÅÄ ×ËÌÀÞÅÎÉÅÍ ËÏÍÐØÀÔÅÒÁ. åÓÌÉ ×Ù ÚÁÇÒÕÖÁÅÔÅÓØ Ó CDROM, ÔÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÂÕÄÅÔ ×ËÌÀÞÉÔØ ËÏÍÐØÀÔÅÒ É ÐÒÉ ÐÅÒ×ÏÊ ×ÏÚÍÏÖÎÏÓÔÉ ×ÓÔÁ×ÉÔØ CD ÄÉÓË. îÁÓÔÒÏÊÔÅ ×ÁÛÕ ÍÁÛÉÎÕ ÎÁ ÚÁÇÒÕÚËÕ Ó CDROM ÉÌÉ Ó USB, × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÔÏÇÏ, ËÁËÏÅ ÕÓÔÒÏÊÓÔ×Ï ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÕÓÔÁÎÏ×ËÉ. îÁÓÔÒÏÊËÉ BIOS ÐÏÚ×ÏÌÑÀÔ ×ÙÂÒÁÔØ ËÏÎËÒÅÔÎÏÅ ÚÁÇÒÕÚÏÞÎÏÅ ÕÓÔÒÏÊÓÔ×Ï. âÏÌØÛÉÎÓÔ×Ï ÓÉÓÔÅÍ ÔÁËÖÅ ÐÒÅÄÏÓÔÁ×ÌÑÀÔ ×ÏÚÍÏÖÎÏÓÔØ ×ÙÂÒÁÔØ ÚÁÇÒÕÚÏÞÎÏÅ ÕÓÔÒÏÊÓÔ×Ï ×Ï ×ÒÅÍÑ ÚÁÐÕÓËÁ, ÞÁÓÔÏ ÜÔÁ ×ÏÚÍÏÖÎÏÓÔØ ÁËÔÉ×ÉÒÕÅÔÓÑ ÐÏ ÎÁÖÁÔÉÀ ËÌÁ×ÉÛÉ F10, F11, F12 ÉÌÉ Escape. åÓÌÉ ×ÁÛ ËÏÍÐØÀÔÅÒ ÚÁÇÒÕÖÁÅÔÓÑ ËÁË ÏÂÙÞÎÏ É ÚÁÐÕÓËÁÅÔ ÓÕÝÅÓÔ×ÕÀÝÕÀ ÏÐÅÒÁÃÉÏÎÎÕÀ ÓÉÓÔÅÍÕ, ÔÏ: äÉÓË ÎÅ ÂÙÌ ×ÓÔÁ×ÌÅÎ ÚÁÂÌÁÇÏ×ÒÅÍÅÎÎÏ. ïÓÔÁרÔÅ ÅÇÏ × ÐÒÉ×ÏÄÅ É ÐÏÐÒÏÂÕÊÔÅ ÐÅÒÅÚÁÇÒÕÚÉÔØ ×ÁÛ ËÏÍÐØÀÔÅÒ. òÁÎÅÅ ×ÎÅÓÅÎÎÙÅ ÉÚÍÅÎÅÎÉÑ × BIOS ÎÅ ÓÒÁÂÏÔÁÌÉ. ðÏÐÒÏÂÕÊÔÅ ÐÏ×ÔÏÒÉÔØ ÛÁÇ ÎÁÓÔÒÏÊËÉ BIOS ÐÏËÁ ÎÅ ÐÏÌÕÞÉÔÅ ÎÅÏÂÈÏÄÉÍÙÊ ÐÏÒÑÄÏË ÚÁÇÒÕÚËÉ. ÷ÁÛ ÎÙÎÅÛÎÉÊ BIOS ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔ ÚÁÇÒÕÚËÕ Ó ÉÍÅÀÝÅÇÏÓÑ ÚÁÇÒÕÚÏÞÎÏÇÏ ÎÁËÏÐÉÔÅÌÑ. ÷ ÜÔÏÍ ÓÌÕÞÁÅ ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ Plop Boot Manager ÄÌÑ ÚÁÇÒÕÚËÉ ÂÏÌÅÅ ÓÔÁÒÙÈ ÍÁÛÉÎ Ó CD ÉÌÉ USB. &os; ÎÁÞÎÅÔ ÚÁÇÒÕÖÁÔØÓÑ. åÓÌÉ ×Ù ÚÁÇÒÕÖÁÅÔÅÓØ Ó CDROM, ×Ù Õ×ÉÄÉÔÅ ÐÏÔÏË ÓÏÏÂÝÅÎÉÊ, ÐÏÄÏÂÎÙÊ ÓÌÅÄÕÀÝÅÍÕ (ÉÎÆÏÒÍÁÃÉÑ Ï ×ÅÒÓÉÑÈ ÏÐÕÝÅÎÁ): Booting from CD-ROM... 645MB medium detected CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 636kB/261056kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 syms=[0x4+0x6cac0+0x4+0x88e9d] \ ïÔÏÂÒÁÖÁÅÔÓÑ ÍÅÎÀ ÚÁÇÒÕÚÞÉËÁ &os;:
íÅÎÀ ÚÁÇÒÕÚÞÉËÁ &os;
÷ÙÖÄÉÔÅ ÄÅÓÑÔØ ÓÅËÕÎÄ ÉÌÉ ÎÁÖÍÉÔÅ Enter.
úÁÇÒÕÚËÁ &macintosh; &powerpc; îÁ ÂÏÌØÛÉÎÓÔ×Å ÍÁÛÉÎ ÕÄÅÒÖÉ×ÁÎÉÅ ËÌÁ×ÉÛÉ C ÎÁ ËÌÁ×ÉÁÔÕÒÅ ×Ï ×ÒÅÍÑ ÎÁÞÁÌØÎÏÊ ÚÁÇÒÕÚËÉ ÁËÔÉ×ÉÒÕÅÔ ÚÁÇÒÕÚËÕ Ó CD. éÎÁÞÅ, ÕÄÅÒÖÉ×ÁÊÔÅ Command Option O F , ÉÌÉ Windows Alt O F ÎÁ ÎÅ-&apple; ËÌÁ×ÉÁÔÕÒÁÈ. îÁ ÐÒÉÇÌÁÛÅÎÉÅ 0 > ××ÅÄÉÔÅ boot cd:,\ppc\loader cd:0 äÌÑ Xserves ÂÅÚ ËÌÁ×ÉÁÔÕÒ, ÏÚÎÁËÏÍØÔÅÓØ Ó ÚÁÇÒÕÚËÏÊ × Open Firmware, ËÏÔÏÒÁÑ ÏÐÉÓÁÎÁ ÎÁ ÓÁÊÔÅ ÐÏÄÄÅÒÖËÉ &apple;. úÁÇÒÕÚËÁ &sparc64; âÏÌØÛÉÎÓÔ×Ï ÓÉÓÔÅÍ &sparc64; ÎÁÓÔÒÏÅÎÙ ÎÁ Á×ÔÏÍÁÔÉÞÅÓËÕÀ ÚÁÇÒÕÚËÕ Ó ÖÅÓÔËÏÇÏ ÄÉÓËÁ. äÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÕÓÔÁÎÏ×ÉÔØ &os;, ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ×ÙÐÏÌÎÉÔØ ÚÁÇÒÕÚËÕ ÐÏ ÓÅÔÉ ÉÌÉ Ó CDROM, ÞÔÏ ÐÏÄÒÁÚÕÍÅ×ÁÅÔ ÐÏÌÕÞÅÎÉÅ ÄÏÓÔÕÐÁ Ë PROM (OpenFirmware). äÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÐÏÌÕÞÉÔØ ÄÏÓÔÕÐ Ë PROM, ÐÅÒÅÇÒÕÚÉÔÅ ÓÉÓÔÅÍÕ É ÄÏÖÄÉÔÅÓØ ÐÏÑ×ÌÅÎÉÑ ÚÁÇÒÕÚÏÞÎÙÈ ÓÏÏÂÝÅÎÉÊ. ÷ÉÄ ÓÏÏÂÝÅÎÉÊ ÚÁ×ÉÓÉÔ ÏÔ ÍÏÄÅÌÉ ÍÁÛÉÎÙ, ÎÏ ÄÏÌÖÅÎ ×ÙÇÌÑÄÅÔØ ÐÏÄÏÂÎÏ ÓÌÅÄÕÀÝÅÍÕ: Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2001 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.2, 128 MB memory installed, Serial #51090132. Ethernet address 0:3:ba:b:92:d4, Host ID: 830b92d4. åÓÌÉ ×ÁÛÁ ÓÉÓÔÅÍÁ ÐÒÏÄÏÌÖÁÅÔ ÚÁÇÒÕÖÁÔØÓÑ Ó ÖÅÓÔËÏÇÏ ÄÉÓËÁ, ÔÏ ÞÔÏÂÙ ÐÏÌÕÞÉÔØ ÐÒÉÇÌÁÛÅÎÉÅ PROM ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÎÁÖÁÔØ ÎÁ ËÌÁ×ÉÁÔÕÒÅ L1A ÉÌÉ StopA, ÉÌÉ ÖÅ ÐÏÓÌÁÔØ ÓÉÇÎÁÌ BREAK ÞÅÒÅÚ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ (ÉÓÐÏÌØÚÕÑ, ÎÁÐÒÉÍÅÒ, ~# × &man.tip.1; ÉÌÉ &man.cu.1;). ðÒÉÇÌÁÛÅÎÉÅ ×ÙÇÌÑÄÉÔ ÐÏÄÏÂÎÏ ÓÌÅÄÕÀÝÅÍÕ: ok ok {0} ðÒÉÇÌÁÛÅÎÉÅ, ÏÔÏÂÒÁÖÁÀÝÅÅÓÑ ÎÁ ÓÉÓÔÅÍÁÈ Ó ÏÄÎÉÍ ÃÅÎÔÒÁÌØÎÙÍ ÐÒÏÃÅÓÓÏÒÏÍ. ðÒÉÇÌÁÛÅÎÉÅ, ÏÔÏÂÒÁÖÁÀÝÅÅÓÑ ÎÁ ÍÎÏÇÏÐÒÏÃÅÓÓÏÒÎÙÈ (SMP) ÓÉÓÔÅÍÁÈ, ÃÉÆÒÁ ÕËÁÚÙ×ÁÅÔ ÎÁ ËÏÌÉÞÅÓÔ×Ï ÁËÔÉ×ÎÙÈ ÃÅÎÔÒÁÌØÎÙÈ ÐÒÏÃÅÓÓÏÒÏ×. îÁ ÜÔÏÍ ÜÔÁÐÅ ×ÓÔÁרÔÅ CDROM × ÐÒÉ×ÏÄ É ÎÁÂÅÒÉÔÅ boot cdrom × ÐÒÉÇÌÁÛÅÎÉÉ PROM.
ðÒÏÓÍÏÔÒ ÒÅÚÕÌØÔÁÔÁ ÏÐÒÅÄÅÌÅÎÉÑ ÕÓÔÒÏÊÓÔ× (device probe) ÷Ù×ÏÄÉÍÙÅ ÎÁ ÜËÒÁÎ ×Ï ×ÒÅÍÑ ÎÁÞÁÌØÎÏÊ ÚÁÇÒÕÚËÉ ÓÉÓÔÅÍÙ ÐÏÓÌÅÄÎÉÅ ÐÁÒÕ ÓÏÔÅÎ ÓÔÒÏË ÓÏÈÒÁÎÑÀÔÓÑ, É ÐÒÉ ÎÅÏÂÈÏÄÉÍÏÓÔÉ ÍÏÇÕÔ ÂÙÔØ ÐÒÏÓÍÏÔÒÅÎÙ. þÔÏÂÙ ÐÒÏÓÍÏÔÒÅÔØ ÓÏÄÅÒÖÉÍÏÅ ÂÕÆÅÒÁ, ÎÁÖÍÉÔÅ Scroll Lock. üÔÏ ×ËÌÀÞÉÔ ÒÅÖÉÍ ÂÕÆÅÒÁ ÐÒÏËÒÕÔËÉ. äÁÌÅÅ, ÄÌÑ ÐÒÏÓÍÏÔÒÁ ÓÏÈÒÁÎÅÎÎÙÈ ÓÏÏÂÝÅÎÉÊ ×Ù ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÉÌÉ ËÌÁ×ÉÛÉ PageUp É PageDown. þÔÏÂÙ ×ÙÊÔÉ ÉÚ ÒÅÖÉÍÁ ÐÒÏÓÍÏÔÒÁ ÂÕÆÅÒÁ ÎÁÖÍÉÔÅ ÅÝÅ ÒÁÚ Scroll Lock. ÷ËÌÀÞÉÔÅ ÐÒÏËÒÕÔËÕ ÜËÒÁÎÎÏÇÏ ÂÕÆÅÒÁ É ÐÒÏÓÍÏÔÒÉÔÅ ÓÏÏÂÝÅÎÉÑ, ËÏÔÏÒÙÅ ÂÙÌÉ ×ÙÔÅÓÎÅÎÙ Ó ÜËÒÁÎÁ ×Ï ×ÒÅÍÑ ÏÐÒÅÄÅÌÅÎÉÑ ÕÓÔÒÏÊÓÔ× ÑÄÒÏÍ. ÷Ù Õ×ÉÄÉÔÅ ÔÅËÓÔ, ÐÏÄÏÂÎÙÊ Ë , ÏÄÎÁËÏ ÅÇÏ ÓÏÄÅÒÖÉÍÏÅ ÂÕÄÅÔ ÏÔÌÉÞÁÔØÓÑ × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ËÏÍÐÌÅËÔÁ ÕÓÔÒÏÊÓÔ×, ÕÓÔÁÎÏ×ÌÅÎÎÙÈ × ×ÁÛ ËÏÍÐØÀÔÅÒ.
ôÉÐÉÞÎÙÊ ×Ù×ÏÄ ÓÏÏÂÝÅÎÉÊ ÏÐÒÅÄÅÌÅÎÉÑ ÕÓÔÒÏÊÓÔ× Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0 r225473M: Sun Sep 11 16:07:30 BST 2011 root@psi:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz (2527.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x8e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 2926649344 (2791 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <TOSHIB A0064 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 <Version 2.0> irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <TOSHIB A0064> on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, b6690000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 cpu0: <ACPI CPU> on acpi0 ACPI Warning: Incorrect checksum in table [ASF!] - 0xFE, should be 0x9A (20110527/tbutils-282) cpu1: <ACPI CPU> on acpi0 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0 vgapci0: <VGA-compatible display> port 0xcff8-0xcfff mem 0xff400000-0xff7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: <Intel GM45 SVGA controller> on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory vgapci1: <VGA-compatible display> mem 0xffc00000-0xffcfffff at device 2.1 on pci0 pci0: <simple comms> at device 3.0 (no driver attached) em0: <Intel(R) PRO/1000 Network Connection 7.2.3> port 0xcf80-0xcf9f mem 0xff9c0000-0xff9dffff,0xff9fe000-0xff9fefff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:1c:7e:6a:ca:b0 uhci0: <Intel 82801I (ICH9) USB controller> port 0xcf60-0xcf7f irq 16 at device 26.0 on pci0 usbus0: <Intel 82801I (ICH9) USB controller> on uhci0 uhci1: <Intel 82801I (ICH9) USB controller> port 0xcf40-0xcf5f irq 21 at device 26.1 on pci0 usbus1: <Intel 82801I (ICH9) USB controller> on uhci1 uhci2: <Intel 82801I (ICH9) USB controller> port 0xcf20-0xcf3f irq 19 at device 26.2 on pci0 usbus2: <Intel 82801I (ICH9) USB controller> on uhci2 ehci0: <Intel 82801I (ICH9) USB 2.0 controller> mem 0xff9ff800-0xff9ffbff irq 19 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: <Intel 82801I (ICH9) USB 2.0 controller> on ehci0 hdac0: <Intel 82801I High Definition Audio Controller> mem 0xff9f8000-0xff9fbfff irq 22 at device 27.0 on pci0 pcib1: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0 pci1: <ACPI PCI bus> on pcib1 iwn0: <Intel(R) WiFi Link 5100> mem 0xff8fe000-0xff8fffff irq 16 at device 0.0 on pci1 pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0 pci2: <ACPI PCI bus> on pcib2 pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0 pci4: <ACPI PCI bus> on pcib3 pcib4: <ACPI PCI-PCI bridge> at device 30.0 on pci0 pci5: <ACPI PCI bus> on pcib4 cbb0: <RF5C476 PCI-CardBus Bridge> at device 11.0 on pci5 cardbus0: <CardBus bus> on cbb0 pccard0: <16-bit PCCard bus> on cbb0 isab0: <PCI-ISA bridge> at device 31.0 on pci0 isa0: <ISA bus> on isab0 ahci0: <Intel ICH9M AHCI SATA controller> port 0x8f58-0x8f5f,0x8f54-0x8f57,0x8f48-0x8f4f,0x8f44-0x8f47,0x8f20-0x8f3f mem 0xff9fd800-0xff9fdfff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported ahcich0: <AHCI channel> at channel 0 on ahci0 ahcich1: <AHCI channel> at channel 1 on ahci0 ahcich2: <AHCI channel> at channel 4 on ahci0 acpi_lid0: <Control Method Lid Switch> on acpi0 battery0: <ACPI Control Method Battery> on acpi0 acpi_button0: <Power Button> on acpi0 acpi_acad0: <AC Adapter> on acpi0 acpi_toshiba0: <Toshiba HCI Extras> on acpi0 acpi_tz0: <Thermal Zone> on acpi0 attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: <Enhanced SpeedStep Frequency Control> on cpu0 p4tcc0: <CPU Frequency Thermal Control> on cpu0 est1: <Enhanced SpeedStep Frequency Control> on cpu1 p4tcc1: <CPU Frequency Thermal Control> on cpu1 Timecounters tick every 1.000 msec hdac0: HDA Codec #0: Realtek ALC268 hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) pcm0: <HDA Realtek ALC268 PCM #0 Analog> at cad 0 nid 1 on hdac0 pcm1: <HDA Realtek ALC268 PCM #1 Analog> at cad 0 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: <Intel> at usbus0 uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 ugen1.1: <Intel> at usbus1 uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 ugen2.1: <Intel> at usbus2 uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2 ugen3.1: <Intel> at usbus3 uhub3: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen2.2: <vendor 0x0b97> at usbus2 uhub8: <vendor 0x0b97 product 0x7761, class 9/0, rev 1.10/1.10, addr 2> on usbus2 ugen1.2: <Microsoft> at usbus1 ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: <Hitachi HTS543225L9SA00 FBEOC43C> ATA-8 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ums0: <Microsoft Microsoft 3-Button Mouse with IntelliEyeTM, class 0/0, rev 1.10/3.00, addr 2> on usbus1 SMP: AP CPU #1 Launched! cd0 at ahcich1 bus 0 scbus2 target 0 lun 0 cd0: <TEAC DV-W28S-RT 7.0C> Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, ums0: 3 buttons and [XYZ] coordinates ID=0 UDMA2, ATAPI 12bytes, PIO 8192bytes) cd0: cd present [1 x 2048 byte records] ugen0.2: <Microsoft> at usbus0 ukbd0: <Microsoft Natural Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2> on usbus0 kbd2 at ukbd0 uhid0: <Microsoft Natural Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2> on usbus0 Trying to mount root from cd9660:/dev/iso9660/FREEBSD_INSTALL [ro]...
÷ÎÉÍÁÔÅÌØÎÏ ÐÒÏÓÍÏÔÒÉÔÅ ×Ù×ÏÄ ÏÐÒÅÄÅÌÅÎÉÑ ÕÓÔÒÏÊÓÔ× É ÕÂÅÄÉÔÅÓØ, ÞÔÏ &os; ÏÂÎÁÒÕÖÉÌÁ ×ÓÅ ÏÖÉÄÁÅÍÙÅ ×ÁÍÉ ÕÓÔÒÏÊÓÔ×Á. åÓÌÉ ÕÓÔÒÏÊÓÔ×Ï ÎÅ ÂÙÌÏ ÎÁÊÄÅÎÏ, ÔÏ ÏÎÏ ÎÅ ÂÕÄÅÔ ÕÐÏÍÑÎÕÔÏ × ×Ù×ÏÄÅ. íÏÄÕÌÉ ÑÄÒÁ ÐÏÚ×ÏÌÑÀÔ ×ÁÍ ÄÏÂÁ×ÉÔØ ÐÏÄÄÅÒÖËÕ ÕÓÔÒÏÊÓÔ×, ÄÒÁÊ×ÅÒÁ ËÏÔÏÒÙÈ ÏÔÓÕÔÓÔ×ÕÀÔ × ÑÄÒÅ GENERIC. ðÏÓÌÅ ÐÒÏÃÅÄÕÒÙ ÏÐÒÅÄÅÌÅÎÉÑ ÕÓÔÒÏÊÓÔ× ×Ù Õ×ÉÄÉÔÅ . õÓÔÁÎÏ×ÏÞÎÙÊ ÎÏÓÉÔÅÌØ ÍÏÖÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÏÄÎÉÍ ÉÚ ÔÒ£È ÓÐÏÓÏÂÏ×: ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;, ËÁË Live CD, ÉÌÉ ÐÒÏÓÔÏ ÄÌÑ ÄÏÓÔÕÐÁ Ë ÏÂÏÌÏÞËÅ &os;. éÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ ÏÐÃÉÉ, Á Enter — ÄÌÑ ÐÏÄÔ×ÅÒÖÄÅÎÉÑ ×ÙÂÏÒÁ.
÷ÙÂÏÒ ×ÁÒÉÁÎÔÏ× ÒÁÂÏÔÙ ÕÓÔÁÎÏ×ÏÞÎÏÇÏ ÎÏÓÉÔÅÌÑ
÷ÙÂÏÒ ÏÐÃÉÉ [ Install ] ×ÙÚÏ×ÅÔ ÐÒÏÇÒÁÍÍÕ-ÕÓÔÁÎÏ×ÝÉË.
÷×ÅÄÅÎÉÅ × <application>bsdinstall</application> bsdinstall ÜÔÏ ÔÅËÓÔÏ×ÁÑ ÐÒÏÇÒÁÍÍÁ ÄÌÑ - ÕÓÔÁÎÏ×ËÉ &os;, ÓÏÚÄÁÎÎÁÑ &a.nwhitehorn.email; É ÐÒÅÄÓÔÁ×ÌÅÎÎÁÑ × 2011 ÇÏÄÕ - ÄÌÑ &os; 9.0. + ÕÓÔÁÎÏ×ËÉ &os;, ÓÏÚÄÁÎÎÁÑ &a.nwhitehorn.email; É ÐÒÅÄÓÔÁ×ÌÅÎÎÁÑ + × 2011 ÇÏÄÕ ÄÌÑ &os; 9.0. ÷ ËÏÍÐÌÅËÔÅ Ó PC-BSD - ÅÓÔØ ÐÒÏÇÒÁÍÍÁ pc-sysinstall ÏÔ &a.kmoore.email;, - ËÏÔÏÒÁÑ ÔÁËÖÅ ÍÏÖÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÄÌÑ pc-sysinstall ÏÔ + &a.kmoore.email;, ËÏÔÏÒÁÑ ÔÁËÖÅ ÍÏÖÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;. îÅÓÍÏÔÒÑ ÎÁ ÔÏ, ÞÔÏ ÜÔÕ ÐÒÏÇÒÁÍÍÕ ÐÕÔÁÀÔ Ó bsdinstall, ÏÂÅ ÏÎÉ ÍÅÖÄÕ ÓÏÂÏÊ ÎÉËÁË ÎÅ Ó×ÑÚÁÎÙ. óÉÓÔÅÍÁ ÍÅÎÀ bsdinstall ËÏÎÔÒÏÌÉÒÕÅÔÓÑ ËÌÁ×ÉÛÁÍÉ ÎÁ×ÉÇÁÃÉÉ, Á ÔÁËÖÅ Enter, Tab, Space É ÄÒÕÇÉÍÉ. ÷ÙÂÏÒ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ (Keymap) ÷ ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÉÓÐÏÌØÚÕÅÍÏÊ ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ, bsdinstall ÍÏÖÅÔ ÐÒÅÄÌÏÖÉÔØ ×ÙÂÒÁÔØ ÏÔÌÉÞÎÕÀ ÏÔ ÎÁÓÔÒÏÅÎÎÏÊ ÐÏ ÕÍÏÌÞÁÎÉÀ ÒÁÓËÌÁÄËÕ ËÌÁ×ÉÁÔÕÒÙ.
÷ÙÂÏÒ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ
åÓÌÉ ÎÁÖÁÔÁ ËÎÏÐËÁ [ YES ], ÏÔÏÂÒÁÚÉÔÓÑ ÓÌÅÄÕÀÝÅÅ ÍÅÎÀ ×ÙÂÏÒÁ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ. éÎÁÞÅ, ÜÔÏ ÍÅÎÀ ×ÙÂÏÒÁ ÏÔÏÂÒÁÖÅÎÏ ÎÅ ÂÕÄÅÔ, Á ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÒÁÓËÌÁÄËÁ ËÌÁ×ÉÁÔÕÒÙ ÐÏ ÕÍÏÌÞÁÎÉÀ.
íÅÎÀ ×ÙÂÏÒÁ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ
éÓÐÏÌØÚÕÑ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ É ËÌÁ×ÉÛÕ Enter ×ÙÂÅÒÉÔÅ ÒÁÓËÌÁÄËÕ, ËÏÔÏÒÁÑ ÎÁÉÂÏÌÅÅ ÂÌÉÚËÏ ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ ËÌÁ×ÉÁÔÕÒÅ, ÐÏÄËÌÀÞÅÎÎÏÊ Ë ÓÉÓÔÅÍÅ. îÁÖÁÔÉÅ Esc ÐÒÉ×ÅÄÅÔ Ë ×ÙÂÏÒÕ ÒÁÓËÌÁÄËÉ ÐÏ ÕÍÏÌÞÁÎÉÀ. ÷ÙÂÏÒ ÏÐÃÉÉ United States of America ISO-8859-1 ÔÏÖÅ Ñ×ÌÑÅÔÓÑ ÂÅÚÏÐÁÓÎÙÍ × ÔÏÍ ÓÌÕÞÁÅ, ÅÓÌÉ ×ÏÚÎÉËÁÀÔ ÔÒÕÄÎÏÓÔÉ Ó ÏÐÒÅÄÅÌÅÎÉÅÍ ÒÁÓËÌÁÄËÉ.
õÓÔÁÎÏ×ËÁ ÉÍÅÎÉ ÈÏÓÔÁ äÁÌÅÅ, bsdinstall ÐÒÅÄÌÏÖÉÔ ÕËÁÚÁÔØ ÉÍÑ ÈÏÓÔÁ ÄÌÑ ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÏÊ ÓÉÓÔÅÍÙ.
õÓÔÁÎÏ×ËÁ ÉÍÅÎÉ ÈÏÓÔÁ
÷×ÏÄÉÍÏÅ ÉÍÑ ÈÏÓÔÁ ÄÏÌÖÎÏ ÂÙÔØ ÐÏÌÎÙÍ (fully-qualified), ÎÁÐÒÉÍÅÒ: machine3.example.com.
÷ÙÂÏÒ ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÙÈ ËÏÍÐÏÎÅÎÔÏ× äÁÌÅÅ, bsdinstall ÐÒÅÄÌÏÖÉÔ ×ÙÂÒÁÔØ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ËÏÍÐÏÎÅÎÔÙ ÄÌÑ ÕÓÔÁÎÏ×ËÉ.
÷ÙÂÏÒ ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÙÈ ËÏÍÐÏÎÅÎÔÏ×
ïÐÒÅÄÅÌÅÎÉÅ ÐÅÒÅÞÎÑ ËÏÍÐÏÎÅÎÔÏ× ÄÌÑ ÕÓÔÁÎÏ×ËÉ × ÎÁÉÂÏÌØÛÅÊ ÍÅÒÅ ÚÁ×ÉÓÉÔ ÏÔ ÐÌÁÎÉÒÕÅÍÏÇÏ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÓÉÓÔÅÍÙ É ÏÔ ËÏÌÉÞÅÓÔ×Á ÄÏÓÔÕÐÎÏÇÏ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á. ñÄÒÏ É ÎÁÂÏÒ ÕÔÉÌÉÔ &os; (×ÍÅÓÔÅ ÎÁÚÙ×ÁÅÍÙÅ ÂÁÚÏ×ÏÊ ÓÉÓÔÅÍÏÊ) ÕÓÔÁÎÁ×ÌÉ×ÁÀÔÓÑ ×ÓÅÇÄÁ. ÷ ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÔÉÐÁ ÕÓÔÁÎÏ×ËÉ, ÎÅËÏÔÏÒÙÅ ÉÚ ÓÌÅÄÕÀÝÉÈ ËÏÍÐÏÎÅÎÔÏ× ÍÏÇÕÔ ÎÅ ÐÏÑ×ÌÑÔØÓÑ. äÏÐÏÌÎÉÔÅÌØÎÙÅ ËÏÍÐÏÎÅÎÔÙ doc - äÏÐÏÌÎÉÔÅÌØÎÁÑ ÄÏËÕÍÅÎÔÁÃÉÑ, ÐÒÅÉÍÕÝÅÓÔ×ÅÎÎÏ ÉÓÔÏÒÉÞÅÓËÏÇÏ ÈÁÒÁËÔÅÒÁ. äÏËÕÍÅÎÔÁÃÉÑ, ÐÒÅÄÏÓÔÁ×ÌÑÅÍÁÑ ðÒÏÅËÔÏÍ äÏËÕÍÅÎÔÉÒÏ×ÁÎÉÑ &os; ÍÏÖÅÔ ÂÙÔØ ÕÓÔÁÎÏ×ÌÅÎÁ ÐÏÚÖÅ. games - îÅÓËÏÌØËÏ ÔÒÁÄÉÃÉÏÎÎÙÈ ÉÇÒ BSD, × ÔÏÍ ÞÉÓÌÅ fortune, rot13, É ÄÒÕÇÉÅ. lib32 - âÉÂÌÉÏÔÅËÉ ÓÏ×ÍÅÓÔÉÍÏÓÔÉ ÄÌÑ ÚÁÐÕÓËÁ 32-ÂÉÔÎÙÈ ÐÒÉÌÏÖÅÎÉÊ ÎÁ 64-ÂÉÔÎÙÈ ×ÅÒÓÉÑÈ &os;. ports - ëÏÌÌÅËÃÉÑ ðÏÒÔÏ× &os;. ëÏÌÌÅËÃÉÑ ðÏÒÔÏ× — ÜÔÏ ÐÒÏÓÔÏÊ É ÕÄÏÂÎÙÊ ÓÐÏÓÏ ÕÓÔÁÎÏ×ËÉ ÐÒÏÇÒÁÍÍ. ïÎÁ ÎÅ ÓÏÄÅÒÖÉÔ ÉÓÈÏÄÎÙÈ ËÏÄÏ×, ÎÅÏÂÈÏÄÉÍÙÈ ÄÌÑ ËÏÍÐÉÌÑÃÉÉ ÐÒÉÌÏÖÅÎÉÊ. ëÏÌÌÅËÃÉÑ ðÏÒÔÏ× — ÜÔÏ ÍÎÏÖÅÓÔ×Ï ÆÁÊÌÏ×, ÐÒÉ ÐÏÍÏÝÉ ËÏÔÏÒÏÇÏ Á×ÔÏÍÁÔÉÚÉÒÕÅÔÓÑ ÚÁÇÒÕÚËÁ, ËÏÍÐÉÌÑÃÉÑ É ÕÓÔÁÎÏ×ËÁ ÐÒÏÇÒÁÍÍÎÙÈ ÐÁËÅÔÏ× ÓÔÏÒÏÎÎÉÈ ÒÁÚÒÁÂÏÔÞÉËÏ×. ÷ ÏÐÉÓÁÎÏ, ËÁË ÉÓÐÏÌØÚÏ×ÁÔØ ËÏÌÌÅËÃÉÀ ÐÏÒÔÏ×. ðÒÏÇÒÁÍÍÁ ÕÓÔÁÎÏ×ËÉ ÎÅ ÐÒÏ×ÅÒÑÅÔ ÎÁÌÉÞÉÅ Ó×ÏÂÏÄÎÏÇÏ ÍÅÓÔÁ. ðÏÜÔÏÍÕ ×ÙÂÉÒÁÊÔÅ ÜÔÕ ÏÐÃÉÀ ÌÉÛØ ÔÏÇÄÁ, ËÏÇÄÁ ÉÍÅÅÔÓÑ ÄÏÓÔÁÔÏÞÎÏ Ó×ÏÂÏÄÎÏÇÏ ÍÅÓÔÁ ÎÁ ÖÅÓÔËÏÍ ÄÉÓËÅ. þÔÏ ËÁÓÁÅÔÓÑ &os; 9.0, ëÏÌÌÅËÃÉÑ ðÏÒÔÏ× ÚÁÎÉÍÁÅÔ ÏËÏÌÏ &ports.size; ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á. õÞÔÉÔÅ, ÞÔÏ ÄÌÑ ÂÏÌÅÅ ÎÏ×ÙÈ ×ÅÒÓÉÊ &os; ÚÁÎÉÍÁÅÍÏÅ ëÏÌÌÅËÃÉÅÊ ðÏÒÔÏ× ÄÉÓËÏ×ÏÅ ÐÒÏÓÔÒÁÎÓÔ×Ï ÂÕÄÅÔ ÒÁÓÔÉ. src - éÓÈÏÄÎÙÊ ËÏÄ ÓÉÓÔÅÍÙ. &os; ÒÁÓÐÒÏÓÔÒÁÎÑÅÔÓÑ Ó ÐÏÌÎÙÍ ÉÓÈÏÄÎÙÍ ËÏÄÏÍ ËÁË ÄÌÑ ÑÄÒÁ, ÔÁË É ÄÌÑ ÐÒÏÇÒÁÍÍ ÂÁÚÏ×ÏÊ ÓÉÓÔÅÍÙ. äÌÑ ÂÏÌØÛÉÎÓÔ×Á ÐÒÉÌÏÖÅÎÉÊ ÉÓÈÏÄÎÙÊ ËÏÄ ÓÉÓÔÅÍÙ ÎÅ ÎÕÖÅÎ, ÏÄÎÁËÏ ÏÎ ÍÏÖÅÔ ÐÏÔÒÅÂÏ×ÁÔØÓÑ ÐÒÉ ÐÏÓÔÒÏÅÎÉÉ ÎÅËÏÔÏÒÙÈ ÐÒÏÇÒÁÍÍ, ÒÁÓÐÒÏÓÔÒÁÎÑÅÍÙÈ × ×ÉÄÅ ÉÓÈÏÄÎÙÈ ËÏÄÏ× (ÎÁÐÒÉÍÅÒ, ÄÒÁÊ×ÅÒÏ× ÉÌÉ ÍÏÄÕÌÅÊ ÑÄÒÁ), ÉÌÉ ÄÌÑ ÒÁÚÒÁÂÏÔËÉ &os;. ðÏÌÎÏÅ ÄÅÒÅ×Ï ÉÓÈÏÄÎÙÈ ËÏÄÏ× ÔÒÅÂÕÅÔ 1 çâ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á, ÐÅÒÅÓÂÏÒËÁ ×ÓÅÊ ÓÉÓÔÅÍÙ &os; ÔÒÅÂÕÅÔ ÄÏÐÏÌÎÉÔÅÌØÎÏ 5 çâ ÐÒÏÓÔÒÁÎÓÔ×Á.
õÓÔÁÎÏ×ËÁ ÐÏ ÓÅÔÉ õÓÔÁÎÏ×ÏÞÎÙÊ ÎÏÓÉÔÅÌØ bootonly ÎÅ ÓÏÄÅÒÖÉÔ ËÏÐÉÊ ÕÓÔÁÎÏ×ÏÞÎÙÈ ÆÁÊÌÏ×. ÷ ÓÌÕÞÁÅ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÔÁËÏÇÏ ÎÏÓÉÔÅÌÑ ÎÅÏÂÈÏÄÉÍÙÅ ÆÁÊÌÙ ÄÏÌÖÎÙ ÂÙÔØ ÐÏÌÕÞÅÎÙ ÚÁÇÒÕÚËÏÊ ÉÚ ÓÅÔÉ.
õÓÔÁÎÏ×ËÁ ÐÏ ÓÅÔÉ
ðÏÓÌÅ ÎÁÓÔÒÏÊËÉ ÓÅÔÅ×ÏÇÏ ÓÏÅÄÉÎÅÎÉÑ, ËÏÔÏÒÁÑ ÄÅÔÁÌØÎÏ ÏÐÉÓÁÎÁ × , ×ÙÂÉÒÁÅÔÓÑ ÚÅÒËÁÌÏ ÓÁÊÔÁ. úÅÒËÁÌÁ ÓÁÊÔÁ ÓÏÄÅÒÖÁÔ ËÏÐÉÉ ÆÁÊÌÏ× &os;. ÷ÙÂÅÒÉÔÅ ÚÅÒËÁÌÏ, ÒÁÚÍÅÝÅÎÎÏÅ × ÔÏÍ ÒÅÇÉÏÎÅ ÍÉÒÁ, ÞÔÏ É ËÏÍÐØÀÔÅÒ, ÎÁ ËÏÔÏÒÙÊ ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÓÑ &os;. åÓÌÉ ÚÅÒËÁÌÏ ÒÁÓÐÏÌÏÖÅÎÏ ÂÌÉÖÅ Ë ÃÅÌÅ×ÏÍÕ ËÏÍÐØÀÔÅÒÕ, ÔÏ ÆÁÊÌÙ ÍÏÇÕÔ ÂÙÔØ ÐÏÌÕÞÅÎÙ ÂÙÓÔÒÅÅ, ÔÅÍ ÓÁÍÙÍ ÕÍÅÎØÛÉÔÓÑ ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ.
÷ÙÂÏÒ ÚÅÒËÁÌÁ ÓÁÊÔÁ
äÁÌØÎÅÊÛÉÊ ÓÃÅÎÁÒÉÊ ÏÄÉÎÁËÏ× ÄÌÑ ×ÓÅÈ ÓÐÏÓÏÂÏ× ÕÓÔÁÎÏ×ËÉ.
÷ÙÄÅÌÅÎÉÅ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á åÓÔØ ÔÒÉ ÓÐÏÓÏÂÁ ÏÓÕÝÅÓÔ×ÉÔØ ÒÁÚÂÉÅÎÉÅ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á ÄÌÑ &os;. ûÁÂÌÏÎÎÏÅ (guided) ÒÁÚÂÉÅÎÉÅ Á×ÔÏÍÁÔÉÞÅÓËÉ ÎÁÓÔÒÁÉ×ÁÅÔ ÒÁÚÄÅÌÙ ÄÉÓËÁ, ÒÕÞÎÏÅ (manual) ÒÁÚÂÉÅÎÉÅ ÐÏÚ×ÏÌÑÅÔ ÏÐÙÔÎÙÍ ÐÏÌØÚÏ×ÁÔÅÌÑÍ ÓÏÚÄÁ×ÁÔØ ÒÁÚÄÅÌÙ ÓÏÇÌÁÓÎÏ Ó×ÏÉÍ ÔÒÅÂÏ×ÁÎÉÑÍ. é ÎÁËÏÎÅÃ, ÅÓÔØ ×ÏÚÍÏÖÎÏÓÔØ ×ÙÚ×ÁÔØ ËÏÍÁÎÄÎÙÊ ÉÎÔÅÒÐÒÅÔÁÔÏÒ, × ËÏÔÏÒÏÍ ÍÏÖÎÏ ÂÕÄÅÔ ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏ ÚÁÐÕÓËÁÔØ ÕÔÉÌÉÔÙ ÎÁÐÏÄÏÂÉÅ &man.gpart.8;, &man.fdisk.8; É &man.bsdlabel.8;.
÷ÙÂÏÒ ÓÐÏÓÏÂÁ ÒÁÚÂÉÅÎÉÑ: ÛÁÂÌÏÎÎÏÅ (guided) ÉÌÉ ÒÕÞÎÏÅ (manual)
ûÁÂÌÏÎÎÏÅ (guided) ÒÁÚÂÉÅÎÉÅ åÓÌÉ × ÓÉÓÔÅÍÅ ÅÓÔØ ÎÅÓËÏÌØËÏ ÄÉÓËÏ×, ÔÏ ×ÙÂÅÒÉÔÅ ÏÄÉÎ, ÎÁ ËÏÔÏÒÙÊ ÂÕÄÅÔ ÕÓÔÁÎÁ×ÌÉ×ÁÔØÓÑ &os;.
÷ÙÂÏÒ ÉÚ ÍÎÏÖÅÓÔ×Á ÄÉÓËÏ×
äÌÑ &os; ÍÏÖÅÔ ÂÙÔØ ×ÙÄÅÌÅÎ ×ÅÓØ ÄÉÓË ÉÌÉ ÔÏÌØËÏ ÅÇÏ ÞÁÓÔØ. åÓÌÉ ×ÙÂÉÒÁÅÔÓÑ [ Entire Disk ], ÔÏ ÓÏÚÄÁÅÔÓÑ ÓÔÁÎÄÁÒÔÎÏÅ ÒÁÚÂÉÅÎÉÅ, ÚÁÎÉÍÁÀÝÅÅ ×ÅÓØ ÄÉÓË. ÷ÙÂÒÁ× [ Partition ], ×Ù ÐÏÌÕÞÉÔÅ ÓÏÚÄÁÎÉÅ ÒÁÚÄÅÌÏ× × ÎÅÉÓÐÏÌØÚÕÅÍÏÊ ÏÂÌÁÓÔÉ ÄÉÓËÁ.
÷ÙÂÏÒ ×ÓÅÇÏ ÄÉÓËÁ ÉÌÉ ÒÁÚÄÅÌÁ
ðÏ ÚÁ×ÅÒÛÅÎÉÉ ÒÁÚÂÉÅÎÉÑ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á ×ÎÉÍÁÔÅÌØÎÏ ÐÒÏÓÍÏÔÒÉÔÅ ÒÅÚÕÌØÔÁÔ. åÓÌÉ ÂÙÌÁ ÄÏÐÕÝÅÎÁ ÏÛÉÂËÁ, ÔÏ ×ÁÍ ÐÒÅÄÏÓÔÁ×ÌÑÅÔÓÑ ×ÏÚÍÏÖÎÏÓÔØ ÌÉÂÏ ×ÅÒÎÕÔØ ËÏÎÆÉÇÕÒÁÃÉÀ Ë ÉÓÈÏÄÎÏÍÕ ÓÏÓÔÏÑÎÉÀ ÎÁÖÁ× [ Revert ], ÌÉÂÏ ×ÙÐÏÌÎÉÔØ Á×ÔÏÍÁÔÉÞÅÓËÏÅ ÐÅÒÅÒÁÚÂÉÅÎÉÅ ×ÙÂÒÁ× [ Auto ]. ôÁËÖÅ ÒÁÚÄÅÌÙ ÍÏÇÕÔ ÂÙÔØ ÓÏÚÄÁÎÙ, ÉÚÍÅÎÅÎÙ ÉÌÉ ÕÄÁÌÅÎÙ ×ÒÕÞÎÕÀ. åÓÌÉ ÒÅÚÕÌØÔÁÔ ÒÁÚÂÉÅÎÉÑ ËÏÒÒÅËÔÅÎ, ×ÙÂÅÒÉÔÅ [ Finish ] ÄÌÑ ÐÒÏÄÏÌÖÅÎÉÑ ÕÓÔÁÎÏ×ËÉ.
ðÒÏÓÍÏÔÒ ÓÏÚÄÁÎÎÙÈ ÒÁÚÄÅÌÏ×
òÕÞÎÏÅ (manual) ÒÁÚÂÉÅÎÉÅ òÕÞÎÏÅ ÒÁÚÂÉÅÎÉÅ ÎÁÞÉÎÁÅÔÓÑ Ó ÒÅÄÁËÔÏÒÁ ÒÁÚÄÅÌÏ×.
òÕÞÎÏÅ ÓÏÚÄÁÎÉÅ ÒÁÚÄÅÌÏ×
ðÅÒÅÍÅÝÅÎÉÅ ÐÏÄÓ×ÅÞÉ×ÁÎÉÑ ÎÁ ÉÍÑ ÕÓÔÒÏÊÓÔ×Á (× ÜÔÏÍ ÐÒÉÍÅÒÅ — ada0) É ×ÙÂÏÒ [ Create ] ÐÒÉ×ÅÄÅÔ ×ÁÓ Ë ÍÅÎÀ Ó ÐÅÒÅÞÎÅÍ ÓÈÅÍ ÒÁÚÂÉÅÎÉÑ.
÷ÙÂÏÒ ÓÈÅÍÙ ÒÁÚÂÉÅÎÉÑ
ëÁË ÐÒÁ×ÉÌÏ, ÓÈÅÍÁ GPT Ñ×ÌÑÅÔÓÑ ÎÁÉÂÏÌÅÅ ÐÏÄÈÏÄÑÝÅÊ ÄÌÑ PC-ÓÏ×ÍÅÓÔÉÍÙÈ ËÏÍÐØÀÔÅÒÏ×. äÌÑ ÂÏÌÅÅ ÓÔÁÒÙÈ ÏÐÅÒÁÃÉÏÎÎÙÈ ÓÉÓÔÅÍ, ËÏÔÏÒÙÅ ÎÅÓÏ×ÍÅÓÔÉÍÙ Ó GPT, ÍÏÖÅÔ ÐÏÔÒÅÂÏ×ÁÔØÓÑ ÒÁÚÂÉÅÎÉÅ MBR. ïÓÔÁÌØÎÙÅ ÓÈÅÍÙ ÒÁÚÂÉÅÎÉÑ × ÏÂÝÅÍ ÉÓÐÏÌØÚÕÀÔÓÑ ÄÌÑ ÎÅÒÁÓÐÒÏÓÔÒÁÎÅÎÎÙÈ ÉÌÉ ÓÔÁÒÙÈ ËÏÍÐØÀÔÅÒÎÙÈ ÓÉÓÔÅÍ. óÈÅÍÙ ÒÁÚÂÉÅÎÉÑ áÂÂÒÅ×ÉÁÔÕÒÁ ïÐÉÓÁÎÉÅ APM Apple Partition Map, ÉÓÐÏÌØÚÕÅÍÁÑ ÎÁ &powerpc; &macintosh;. BSD íÅÔËÉ BSD ÂÅÚ MBR, ÉÎÏÇÄÁ ÎÁÚÙ×ÁÅÍÙÅ dangerously dedicated mode. úÁ ÐÏÄÒÏÂÎÏÓÔÑÍÉ ÏÂÒÁÔÉÔÅÓØ Ë &man.bsdlabel.8;. GPT ôÁÂÌÉÃÁ ÒÁÚÄÅÌÏ× GUID. MBR Master Boot Record. PC98 òÁÚÎÏ×ÉÄÎÏÓÔØ MBR, ÉÓÐÏÌØÚÕÅÍÁÑ ËÏÍÐØÀÔÅÒÁÍÉ NEC PC-98. VTOC8 Volume Table Of Contents, ÉÓÐÏÌØÚÕÅÍÁÑ ËÏÍÐØÀÔÅÒÁÍÉ Sun SPARC64 É UltraSPARC.
ðÏÓÌÅ ÔÏÇÏ, ËÁË ÓÈÅÍÁ ÒÁÚÂÉÅÎÉÑ ÏÐÒÅÄÅÌÅÎÁ, ÐÏ×ÔÏÒÎÙÊ ×ÙÂÏÒ [ Create ] ÐÒÉ×ÏÄÉÔ Ë ÓÏÚÄÁÎÉÀ ÎÏ×ÙÈ ÒÁÚÄÅÌÏ× ÄÉÓËÁ.
óÏÚÄÁÎÉÅ ÎÏ×ÏÇÏ ÒÁÚÄÅÌÁ
óÔÁÎÄÁÒÔÎÁÑ ÕÓÔÁÎÏ×ËÁ &os; ÓÏ ÓÈÅÍÏÊ GPT ÓÏÚÄÁÓÔ ËÁË ÍÉÎÉÍÕÍ ÔÒÉ ÒÁÚÄÅÌÁ: óÔÁÎÄÁÒÔÎÙÅ <acronym>GPT</acronym> ÒÁÚÄÅÌÙ &os; freebsd-boot - ÚÁÇÒÕÚÏÞÎÙÊ ËÏÄ &os;. freebsd-ufs - ÆÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ UFS &os;. freebsd-swap - &os; ÏÂÌÁÓÔØ ÐÏÄËÁÞËÉ. ôÁËÖÅ ÎÅÏÂÈÏÄÉÍÏ ÕÐÏÍÑÎÕÔØ, ÞÔÏ ÄÌÑ ÒÁÚÄÅÌÏ×, ËÏÔÏÒÙÅ ÂÕÄÕÔ ÓÏÄÅÒÖÁÔØ ÆÁÊÌÏ×ÕÀ ÓÉÓÔÅÍÕ ZFS &os; ÓÌÅÄÕÅÔ ÚÁÄÅÊÓÔ×Ï×ÁÔØ ÔÉÐ ÒÁÚÄÅÌÁ freebsd-zfs. ïÂÒÁÔÉÔÅÓØ Ë . ó×ÅÄÅÎÉÑ Ï ÉÍÅÀÝÉÈÓÑ × ÎÁÌÉÞÉÉ ÔÉÐÁÈ ÒÁÚÄÅÌÏ× GPT ÓÏÄÅÒÖÁÔÓÑ × &man.gpart.8;. òÁÚÕÍÅÅÔÓÑ, ×ÏÚÍÏÖÎÏ ÓÏÚÄÁÎÉÅ ÂÏÌØÛÅÇÏ ËÏÌÉÞÅÓÔ×Á ÒÁÚÄÅÌÏ× Ó ÆÁÊÌÏ×ÙÍÉ ÓÉÓÔÅÍÁÍÉ, É ÎÅËÏÔÏÒÙÅ ÐÏÌØÚÏ×ÁÔÅÌÉ ÐÒÅÄÐÏÞÉÔÁÀÔ ×ÙÄÅÌÑÔØ ÏÔÄÅÌØÎÙÅ ÒÁÚÄÅÌÙ ÄÌÑ ÔÁËÉÈ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ, ËÁË /, /var, /tmp, É /usr. éÌÌÀÓÔÒÁÃÉÑ ÐÏÄÏÂÎÏÇÏ ÒÁÚÂÉÅÎÉÑ ÐÒÉ×ÅÄÅÎÁ × . ðÒÉ ÕËÁÚÁÎÉÉ ÒÁÚÍÅÒÏ× ÄÏÐÕÓËÁÅÔÓÑ ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÏÂÝÅÐÒÉÎÑÔÙÈ ÁÂÂÒÅ×ÉÁÔÕÒ, ÔÁËÉÈ ËÁË K ÄÌÑ ËÉÌÏÂÁÊÔ, M ÄÌÑ ÍÅÇÁÂÁÊÔ, ÉÌÉ G ÄÌÑ ÇÉÇÁÂÁÊÔ. äÏÌÖÎÏÅ ×ÙÒÁ×ÎÉ×ÁÎÉÅ ÓÅËÔÏÒÏ× ÏÂÅÓÐÅÞÉ×ÁÅÔ ÎÁÉÌÕÞÛÕÀ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔØ, Á ÓÏÚÄÁÎÉÅ ÒÁÚÄÅÌÏ× Ó ÒÁÚÍÅÒÁÍÉ, ËÒÁÔÎÙÍÉ 4 ëÂÁÊÔ, ÐÏÍÏÇÁÅÔ ÏÂÅÓÐÅÞÉÔØ ÐÒÁ×ÉÌØÎÏÅ ×ÙÒÁ×ÎÉ×ÁÎÉÅ ËÁË ÎÁ ÄÉÓËÁÈ Ó ÒÁÚÍÅÒÏÍ ÓÅËÔÏÒÁ 512 ÂÁÊÔ, ÔÁË É ÎÁ ÕÓÔÒÏÊÓÔ×ÁÈ Ó ÒÁÚÍÅÒÏÍ ÓÅËÔÏÒÁ 4 ëÂÁÊÔ. ÷ ÏÂÝÅÍ, ÚÁÄÁÎÉÅ ÒÁÚÍÅÒÏ×, ËÒÁÔÎÙÈ 1 íÂÁÊÔ ÉÌÉ 1 çÂÁÊÔ — ÜÔÏ ÎÁÉÂÏÌÅÅ ÐÒÏÓÔÏÊ ÓÐÏÓÏ ×ÙÐÏÌÎÉÔØ ×ÙÒÁ×ÎÉ×ÁÎÉÅ ÎÁÞÁÌ ÒÁÚÄÅÌÏ× ÎÁ ÐÏÚÉÃÉÀ, ËÒÁÔÎÕÀ 4 ëÂÁÊÔ. éÓËÌÀÞÅÎÉÅ: ÎÁ ÄÁÎÎÙÊ ÍÏÍÅÎÔ ÒÁÚÍÅÒ ÒÁÚÄÅÌÁ freebsd-boot ÎÅ ÄÏÌÖÅÎ ÐÒÅ×ÙÛÁÔØ 512 ëÂÁÊÔ ÉÚ-ÚÁ ÏÇÒÁÎÉÞÅÎÉÊ ÚÁÇÒÕÚÏÞÎÏÇÏ ËÏÄÁ. ÷ ÓÌÕÞÁÅ, ÅÓÌÉ ÒÁÚÄÅÌ ÂÕÄÅÔ ÓÏÄÅÒÖÁÔØ ÆÁÊÌÏ×ÕÀ ÓÉÓÔÅÍÕ, ÅÊ ÐÏÔÒÅÂÕÅÔÓÑ ÔÏÞËÁ ÍÏÎÔÉÒÏ×ÁÎÉÑ. åÓÌÉ ÐÌÁÎÉÒÕÅÔÓÑ ÓÏÚÄÁÔØ ÅÄÉÎÓÔ×ÅÎÎÙÊ ÒÁÚÄÅÌ UFS, ÔÏ ÔÏÞËÁ ÍÏÎÔÉÒÏ×ÁÎÉÑ ÄÏÌÖÎÁ ÂÙÔØ /. ôÁËÖÅ ÂÕÄÅÔ ÚÁÐÒÏÛÅÎÁ ÍÅÔËÁ. íÅÔËÁ — ÜÔÏ ÉÍÑ, ÐÒÉÓ×ÏÅÎÎÏÅ ÒÁÚÄÅÌÕ. éÍÑ ÕÓÔÒÏÊÓÔ×Á ÉÌÉ ÅÇÏ ÎÏÍÅÒ ÍÏÖÅÔ ÉÚÍÅÎÉÔØÓÑ ÅÓÌÉ ÕÓÔÒÏÊÓÔ×Ï ÂÕÄÅÔ ÐÏÄËÌÀÞÅÎÏ Ë ÄÒÕÇÏÍÕ ËÏÎÔÒÏÌÌÅÒÕ ÉÌÉ ÐÏÒÔÕ, Á ÍÅÔËÁ ÒÁÚÄÅÌÁ ÏÓÔÁÎÅÔÓÑ ÎÅÉÚÍÅÎÎÏÊ. óÓÙÌËÉ ÎÁ ÍÅÔËÉ ×ÍÅÓÔÏ ÉͣΠÕÓÔÒÏÊÓÔ× É ÎÏÍÅÒÏ× ÒÁÚÄÅÌÏ× × ÆÁÊÌÁÈ ÔÉÐÁ /etc/fstab ÄÅÌÁÀÔ ÓÉÓÔÅÍÕ ÂÏÌÅÅ ÔÏÌÅÒÁÎÔÎÏÊ Ë ÚÁÍÅÎÅ ÏÂÏÒÕÄÏ×ÁÎÉÑ. íÅÔËÉ GPT ÐÏÑ×ÌÑÀÔÓÑ ÐÏÓÌÅ ÐÏÄËÌÀÞÅÎÉÑ ÄÉÓËÁ × ËÁÔÁÌÏÇÅ /dev/gpt/. õ ÄÒÕÇÉÈ ÓÈÅÍ ÒÁÚÂÉÅÎÉÑ ÅÓÔØ Ó×ÏÉ ÏÓÏÂÅÎÎÏÓÔÉ ÐÏÄÄÅÒÖËÉ ÍÅÔÏË, É ÉÈ ÍÅÔËÉ ÒÁÓÐÏÌÁÇÁÀÔÓÑ × ÄÒÕÇÉÈ ÐÏÄËÁÔÁÌÏÇÁÈ ËÁÔÁÌÏÇÁ /dev/. ÷Ï ÉÚÂÅÖÁÎÉÅ ËÏÎÆÌÉËÔÏ× ÉÍÅÎ ÍÅÔÏË ÉÓÐÏÌØÚÕÊÔÅ ÕÎÉËÁÌØÎÙÅ ÉÍÅÎÁ ÄÌÑ ËÁÖÄÏÊ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ. îÅÓËÏÌØËÏ ÂÕË×, ×ÚÑÔÙÈ ÏÔ ÉÍÅÎÉ ËÏÍÐØÀÔÅÒÁ, ÅÇÏ ÎÁÚÎÁÞÅÎÉÑ ÉÌÉ ÒÁÚÍÅÝÅÎÉÑ ÍÏÖÅÔ ÂÙÔØ ÄÏÂÁ×ÌÅÎÏ Ë ÍÅÔËÅ. îÁÐÒÉÍÅÒ, ËÏÒÎÅ×ÏÍÕ ÒÁÚÄÅÌÕ UFS ÄÌÑ ËÏÍÐØÀÔÅÒÁ × ÌÁÂÏÒÁÔÏÒÉÉ ÍÏÖÎÏ ÐÒÉÓ×ÏÉÔØ ÍÅÔËÕ "labroot" ÉÌÉ "rootfs-lab". óÏÚÄÁÎÉÅ ÔÒÁÄÉÃÉÏÎÎÏÇÏ ÒÁÚÂÉÅÎÉÑ ÐÏÄ ÆÁÊÌÏ×ÙÅ ÓÉÓÔÅÍÙ. äÌÑ ÔÒÁÄÉÃÉÏÎÎÏÇÏ ÒÁÚÂÉÅÎÉÑ, × ËÏÔÏÒÏÍ ËÁÔÁÌÏÇÉ /, /var, /tmp É /usr ÐÒÅÄÓÔÁ×ÌÑÀÔ ÓÏÂÏÊ ÏÔÄÅÌØÎÙÅ ÆÁÊÌÏ×ÙÅ ÓÉÓÔÅÍÙ ÎÁ ÉÈ ÓÏÂÓÔ×ÅÎÎÙÈ ÒÁÚÄÅÌÁÈ, ÓÏÚÄÁÊÔÅ ÓÈÅÍÕ ÒÁÚÂÉÅÎÉÑ GPT, ÐÏÔÏÍ ÓÏÚÄÁÊÔÅ ÒÁÚÄÅÌÙ, ËÁË ÜÔÏ ÕËÁÚÁÎÏ ÎÉÖÅ. ðÏËÁÚÁÎÎÙÅ ÒÁÚÍÅÒÙ ÒÁÚÄÅÌÏ× Ñ×ÌÑÀÔÓÑ ÔÉÐÉÞÎÙÍÉ ÄÌÑ ÖÅÓÔËÏÇÏ ÄÉÓËÁ ÒÁÚÍÅÒÏÍ 20çÂ. åÓÌÉ ÄÉÓË ÂÏÌØÛÅÇÏ ÒÁÚÍÅÒÁ, ÔÏ ÂÕÄÅÔ ÕÍÅÓÔÎÙÍ ÏÔ×ÅÓÔÉ ÂÏÌØÛÅ ÍÅÓÔÁ ÄÌÑ ÒÁÚÄÅÌÁ ÐÏÄËÁÞËÉ ÉÌÉ ÄÌÑ ÒÁÚÄÅÌÁ Ó ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÏÊ /var. úÁÄÅÊÓÔ×Ï×ÁÎÎÙÅ × ÜÔÏÍ ÐÒÉÍÅÒÅ ÍÅÔËÉ ÉÍÅÀÔ ÐÒÅÆÉËÓ ex, ÏÔ ÓÌÏ×Á "example", ×ÁÍ ÖÅ ÒÅËÏÍÅÎÄÕÅÔÓÑ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÒÕÇÉÅ ÕÎÉËÁÌØÎÙÅ ÉÍÅÎÁ ÍÅÔÏË. ðÏ ÕÍÏÌÞÁÎÉÀ, ÚÁÇÒÕÚÞÉË gptboot &os; ÏÖÉÄÁÅÔ, ÞÔÏ ÐÅÒ×ÙÊ ÎÁÊÄÅÎÎÙÊ ÒÁÚÄÅÌ UFS ÂÕÄÅÔ ËÏÒÎÅ×ÙÍ ÒÁÚÄÅÌÏÍ (/). ôÉÐ ÒÁÚÄÅÌÁ òÁÚÍÅÒ ôÏÞËÁ ÍÏÎÔÉÒÏ×ÁÎÉÑ íÅÔËÁ freebsd-boot 512K freebsd-ufs 2G / exrootfs freebsd-swap 4G exswap freebsd-ufs 2G /var exvarfs freebsd-ufs 1G /tmp extmpfs freebsd-ufs ÓÏÇÌÁÛÁÊÔÅÓØ ÓÏ ÚÎÁÞÅÎÉÅÍ ÐÏ ÕÍÏÌÞÁÎÉÀ (ÏÓÔÁ×ÛÁÑÓÑ ÞÁÓÔØ ÏÂßÅÍÁ ÄÉÓËÁ) /usr exusrfs äÌÑ ÐÒÏÄÏÌÖÅÎÉÑ ÕÓÔÁÎÏ×ËÉ ÐÏ ÚÁ×ÅÒÛÅÎÉÉ ÓÏÚÄÁÎÉÑ ÎÅÏÂÈÏÄÉÍÙÈ ÒÁÚÄÅÌÏ× ×ÙÂÅÒÉÔÅ [ Finish ].
úÁ×ÅÒÛÅÎÉÅ ÕÓÔÁÎÏ×ËÉ óÌÅÄÕÀÝÉÊ ÛÁÇ — ×ÁÛ ÐÏÓÌÅÄÎÉÊ ÛÁÎÓ ÐÒÅÒ×ÁÔØ ÕÓÔÁÎÏ×ËÕ É ÐÒÅÄÏÔ×ÒÁÔÉÔØ ÉÚÍÅÎÅÎÉÅ ÄÁÎÎÙÈ ÎÁ ÖÅÓÔËÏÍ ÄÉÓËÅ.
úÁËÌÀÞÉÔÅÌØÎÏÅ ÐÏÄÔ×ÅÒÖÄÅÎÉÅ
äÌÑ ÐÒÏÄÏÌÖÅÎÉÑ ×ÙÂÅÒÉÔÅ [ Commit ]. åÓÌÉ ÎÅÏÂÈÏÄÉÍÏ ×ÎÅÓÔÉ ÉÚÍÅÎÅÎÉÑ, ÄÌÑ ×ÏÚ×ÒÁÝÅÎÉÑ Ë ÒÅÄÁËÔÏÒÕ ÒÁÚÄÅÌÏ× ÎÁÖÍÉÔÅ [ Back ]. ÷ÙÂÏÒ [ Revert & Exit ] ÄÁÅÔ ×ÏÚÍÏÖÎÏÓÔØ ×ÙÊÔÉ ÉÚ ÕÓÔÁÎÏ×ÝÉËÁ ÂÅÚ ×ÎÅÓÅÎÉÑ ÉÚÍÅÎÅÎÉÊ ÎÁ ÖÅÓÔËÉÊ ÄÉÓË. ðÒÏÄÏÌÖÉÔÅÌØÎÏÓÔØ ÕÓÔÁÎÏ×ËÉ ×ÁÒØÉÒÕÅÔÓÑ × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ×ÙÂÒÁÎÎÏÇÏ ÄÉÓÔÒÉÂÕÔÉ×Á, ÓÐÏÓÏÂÁ ÕÓÔÁÎÏ×ËÉ É ÂÙÓÔÒÏÄÅÊÓÔ×ÉÑ ËÏÍÐØÀÔÅÒÁ. äÁÌÅÅ ÐÏÓÌÅÄÕÅÔ ÏÞÅÒÅÄØ ÓÏÏÂÝÅÎÉÊ, ÉÎÆÏÒÍÉÒÕÀÝÉÈ Ï ÈÏÄÅ ÕÓÔÁÎÏ×ËÉ. ðÅÒ×ÙÍ ÄÅÌÏÍ ÕÓÔÁÎÏ×ÝÉË ÚÁÐÉÛÅÔ ÉÎÆÏÒÍÁÃÉÀ Ï ÒÁÚÄÅÌÁÈ ÎÁ ÄÉÓË É ÏÔÆÏÒÍÁÔÉÒÕÅÔ ÒÁÚÄÅÌÙ ÐÏÓÒÅÄÓÔ×ÏÍ newfs. åÓÌÉ ×ÙÐÏÌÎÑÅÔÓÑ ÕÓÔÁÎÏ×ËÁ ÐÏ ÓÅÔÉ, ÔÏ bsdinstall ÐÒÏÄÏÌÖÉÔ ÚÁÇÒÕÚËÕ ÎÅÏÂÈÏÄÉÍÙÈ ÆÁÊÌÏ× ÄÉÓÔÒÉÂÕÔÉ×Á.
úÁÇÒÕÚËÁ ÆÁÊÌÏ× ÄÉÓÔÒÉÂÕÔÉ×Á
äÁÌÅÅ ÐÏÓÌÅÄÕÅÔ ÐÒÏ×ÅÒËÁ ÃÅÌÏÓÔÎÏÓÔÉ ÆÁÊÌÏ× ÄÉÓÔÒÉÂÕÔÉ×Á, ÞÔÏÂÙ ÕÄÏÓÔÏ×ÅÒÉÔØÓÑ, ÞÔÏ ÏÎÉ ÎÅ ÂÙÌÉ ÐÏ×ÒÅÖÄÅÎÙ ×Ï ×ÒÅÍÑ ÚÁÇÒÕÚËÉ ÉÌÉ ÞÔÅÎÉÑ Ó ÕÓÔÁÎÏ×ÏÞÎÏÇÏ ÎÏÓÉÔÅÌÑ.
ðÒÏ×ÅÒËÁ ÆÁÊÌÏ× ÄÉÓÔÒÉÂÕÔÉ×Á
é × ÚÁËÌÀÞÅÎÉÅ, ÐÒÏ×ÅÒÅÎÎÙÅ ÆÁÊÌÙ ÒÁÓÐÁËÏ×Ù×ÁÀÔÓÑ ÎÁ ÄÉÓË.
éÚ×ÌÅÞÅÎÉÅ ÆÁÊÌÏ× ÄÉÓÔÒÉÂÕÔÉ×Á
ëÁË ÔÏÌØËÏ ÚÁÐÒÏÛÅÎÎÙÅ ÆÁÊÌÙ ÄÉÓÔÒÉÂÕÔÉ×Á ÒÁÓÐÁËÕÀÔÓÑ, bsdinstall ÐÒÉÓÔÕÐÉÔ Ë ×ÙÐÏÌÎÅÎÉÀ ÐÏÓÌÅÕÓÔÁÎÏ×ÏÞÎÙÈ ËÏÎÆÉÇÕÒÁÃÉÏÎÎÙÈ ÚÁÄÁÞ (ÓÍÏÔÒÉÔÅ ).
ðÏÓÌÅ ÕÓÔÁÎÏ×ËÉ ðÏÓÌÅ ÕÓÐÅÛÎÏÊ ÕÓÔÁÎÏ×ËÉ &os; ÐÏÓÌÅÄÕÀÔ ÍÅÎÀ ÎÁÓÔÒÏÊËÉ ÒÁÚÌÉÞÎÙÈ ÏÐÃÉÊ. îÁÓÔÒÏÊËÉ ÏÐÃÉÊ ÍÏÇÕÔ ÂÙÔØ ÉÚÍÅÎÅÎÙ ÐÕÔÅÍ ÐÏ×ÔÏÒÎÏÇÏ ×ÈÏÄÁ × ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÉÅ ÒÁÚÄÅÌÙ ÆÉÎÁÌØÎÏÇÏ ËÏÎÆÉÇÕÒÁÃÉÏÎÎÏÇÏ ÍÅÎÀ ÐÅÒÅÄ ÚÁÇÒÕÚËÏÊ × Ó×ÅÖÅÕÓÔÁÎÏ×ÌÅÎÎÕÀ ÓÉÓÔÅÍÕ &os;. õÓÔÁÎÏ×ËÁ ÐÁÒÏÌÑ ÐÏÌØÚÏ×ÁÔÅÌÑ <username>root</username> õÓÔÁÎÏ×ËÁ ÐÁÒÏÌÑ ÐÏÌØÚÏ×ÁÔÅÌÑ root — ÏÂÑÚÁÔÅÌØÎÁ. úÁÍÅÔØÔÅ, ÞÔÏ ×Ï ×ÒÅÍÑ ××ÏÄÁ ÐÁÒÏÌÑ ÎÁÂÉÒÁÅÍÙÅ ÓÉÍ×ÏÌÙ ÎÅ ÏÔÏÂÒÁÖÁÀÔÓÑ ÎÁ ÜËÒÁÎÅ. ðÏÓÌÅ ××ÏÄÁ ÂÕÄÅÔ ÚÁÐÒÏÛÅÎ ÐÏ×ÔÏÒÎÙÊ ××ÏÄ ÐÁÒÏÌÑ. üÔÏ ÐÏÍÏÇÁÅÔ ÐÒÅÄÏÔ×ÒÁÔÉÔØ ÏÐÅÞÁÔËÉ ÐÒÉ ÎÁÂÏÒÅ.
õÓÔÁÎÏ×ËÁ ÐÁÒÏÌÑ ÐÏÌØÚÏ×ÁÔÅÌÑ <username>root</username>
îÁÓÔÒÏÊËÉ ÏÐÃÉÊ ÐÒÏÄÏÌÖÁÔÓÑ ÐÏÓÌÅ ÕÓÐÅÛÎÏÊ ÕÓÔÁÎÏ×ËÉ ÐÁÒÏÌÑ.
îÁÓÔÒÏÊËÁ ÓÅÔÅ×ÙÈ ÉÎÔÅÒÆÅÊÓÏ× îÁÓÔÒÏÊËÁ ÓÅÔÅ×ÙÈ ÉÎÔÅÒÆÅÊÓÏ× ÂÕÄÅÔ ÏÐÕÝÅÎÁ × ÓÌÕÞÁÅ, ÅÓÌÉ ÏÎÁ ÕÖÅ ÂÙÌÁ ×ÙÐÏÌÎÅÎÁ ËÁË ÞÁÓÔØ ÐÏÄÇÏÔÏ×ËÉ ÐÒÉ ÕÓÔÁÎÏ×ËÅ bootonly. äÁÌÅÅ ÂÕÄÅÔ ÏÔÏÂÒÁÖÅÎ ÐÅÒÅÞÅÎØ ×ÓÅÈ ÓÅÔÅ×ÙÈ ÉÎÔÅÒÆÅÊÓÏ×, ÎÁÊÄÅÎÎÙÈ ÎÁ ËÏÍÐØÀÔÅÒÅ. ÷ÙÂÅÒÉÔÅ ÔÏÔ, ËÏÔÏÒÙÊ ÐÌÁÎÉÒÕÅÔÅ ÎÁÓÔÒÏÉÔØ.
÷ÙÂÅÒÉÔÅ ÓÅÔÅ×ÏÊ ÉÎÔÅÒÆÅÊÓ
îÁÓÔÒÏÊËÁ ÂÅÓÐÒÏ×ÏÄÎÏÇÏ ÓÅÔÅ×ÏÇÏ ÉÎÔÅÒÆÅÊÓÁ åÓÌÉ ×ÙÂÒÁÎ ÂÅÓÐÒÏ×ÏÄÎÏÊ ÓÅÔÅ×ÏÊ ÉÎÔÅÒÆÅÊÓ, ÔÏ ÄÌÑ ÐÏÄËÌÀÞÅÎÉÑ Ë ÓÅÔÉ ÐÏÔÒÅÂÕÅÔÓÑ ××ÅÓÔÉ ÐÁÒÁÍÅÔÒÙ ÓÅÔÅ×ÏÊ ÉÄÅÎÔÉÆÉËÁÃÉÉ É ÂÅÚÏÐÁÓÎÏÓÔÉ. âÅÓÐÒÏ×ÏÄÎÙÅ ÓÅÔÉ ÒÁÓÐÏÚÎÁÀÔÓÑ ÐÏ ÔÁË ÎÁÚÙ×ÁÅÍÏÍÕ Service Set Identifier, ÉÌÉ SSID. âÏÌØÛÉÎÓÔ×Ï ÂÅÓÐÒÏ×ÏÄÎÙÈ ÓÅÔÅÊ ÛÉÆÒÕÀÔ ÐÅÒÅÄÁ×ÁÅÍÙÅ ÄÁÎÎÙÅ ÞÔÏÂÙ ÚÁÝÉÔÉÔØ ÉÈ ÏÔ ÎÅÁ×ÔÏÒÉÚÉÒÏ×ÁÎÎÏÇÏ ÐÒÏÓÌÕÛÉ×ÁÎÉÑ. îÁÓÔÏÑÔÅÌØÎÏ ÒÅËÏÍÅÎÄÕÅÔÓÑ ÐÒÉÍÅÎÑÔØ ÓÔÁÎÄÁÒÔ WPA2. âÏÌÅÅ ÓÔÁÒÙÅ ÓÔÁÎÄÁÒÔÙ, ÎÁÐÒÉÍÅÒ WEP, ÎÅ ÏÂÅÓÐÅÞÉ×ÁÀÔ ÄÏÓÔÁÔÏÞÎÏÇÏ ÕÒÏ×ÎÑ ÂÅÚÏÐÁÓÎÏÓÔÉ. ðÅÒ×ÙÍ ÄÅÌÏÍ, ÐÒÉ ÐÏÄËÌÀÞÅÎÉÉ Ë ÂÅÓÐÒÏ×ÏÄÎÏÊ ÓÅÔÉ ÎÅÏÂÈÏÄÉÍÏ ×ÙÐÏÌÎÉÔØ ÐÏÉÓË ÂÅÓÐÒÏ×ÏÄÎÙÈ ÔÏÞÅË ÄÏÓÔÕÐÁ.
ðÏÉÓË ÂÅÓÐÒÏ×ÏÄÎÙÈ ÔÏÞÅË ÄÏÓÔÕÐÁ
óÐÉÓÏË ÎÁÊÄÅÎÎÙÈ ÓÅÔÅÊ ÂÕÄÅÔ ÓÏÄÅÒÖÁÔØ ÎÅÓËÏÌØËÏ SSID Ó ÏÐÉÓÁÎÉÅÍ ÔÉÐÏ× ÛÉÆÒÏ×ÁÎÉÑ, ÐÏÄÄÅÒÖÉ×ÁÅÍÙÈ ÏÂÎÁÒÕÖÅÎÎÙÍÉ ÂÅÓÐÒÏ×ÏÄÎÙÍÉ ÓÅÔÑÍÉ. åÓÌÉ ÉÓËÏÍÙÊ SSID ÎÅ ÐÏÑ×ÌÑÅÔÓÑ × ÓÐÉÓËÅ, ÔÏ ÚÁÐÕÓÔÉÔÅ ÓËÁÎÉÒÏ×ÁÎÉÅ ÐÏ×ÔÏÒÎÏ, ×ÙÂÒÁ× [ Rescan ]. åÓÌÉ ÉÓËÏÍÁÑ ÓÅÔØ ÓÎÏ×Á ÎÅ ÐÏÑ×ÉÔÓÑ × ÓÐÉÓËÅ, ÐÒÏ×ÅÒØÔÅ ÓÏÅÄÉÎÅÎÉÅ Ó ÁÎÔÅÎÎÏÊ ÉÌÉ ÐÏÐÒÏÂÕÊÔÅ ÒÁÚÍÅÓÔÉÔØ ËÏÍÐØÀÔÅÒ ÂÌÉÖÅ Ë ÔÏÞËÅ ÄÏÓÔÕÐÁ. úÁÐÕÓËÁÊÔÅ ÐÏ×ÔÏÒÎÙÊ ÐÏÉÓË ÐÏÓÌÅ ËÁÖÄÏÇÏ ×ÁÛÅÇÏ ÄÅÊÓÔ×ÉÑ.
÷ÙÂÏÒ ÂÅÓÐÒÏ×ÏÄÎÏÊ ÓÅÔÉ
ðÏÓÌÅ ×ÙÂÏÒÁ ÓÅÔÉ ÐÏÔÒÅÂÕÅÔÓÑ ××ÅÓÔÉ ÄÏÐÏÌÎÉÔÅÌØÎÕÀ ÉÎÆÏÒÍÁÃÉÀ Ï ÓÏÅÄÉÎÅÎÉÉ. äÌÑ WPA2 ÐÏÔÒÅÂÕÅÔÓÑ ÐÁÒÏÌØ (ÔÁËÖÅ ÉÚ×ÅÓÔÎÙÊ ËÁË Pre-Shared Key ÉÌÉ PSK). ÷ ÃÅÌÑÈ ÂÅÚÏÐÁÓÎÏÓÔÉ ÎÁÂÉÒÁÅÍÙÅ × ÐÏÌÅ ××ÏÄÁ ÐÁÒÏÌÑ ÓÉÍ×ÏÌÙ ÎÁ ÜËÒÁÎÅ ÏÔÏÂÒÁÖÁÀÔÓÑ Ú×ÅÚÄÏÞËÁÍÉ.
îÁÓÔÒÏÊËÁ WPA2
ðÏÓÌÅ ×ÙÂÏÒÁ ÂÅÓÐÒÏ×ÏÄÎÏÊ ÓÅÔÉ É ××ÏÄÁ ÓÏÐÕÔÓÔ×ÕÀÝÉÈ ÐÁÒÁÍÅÔÒÏ× ÂÅÚÏÐÁÓÎÏÓÔÉ ÐÏÓÌÅÄÕÅÔ ÎÁÓÔÒÏÊËÁ ÓÅÔÅ×ÙÈ ÐÒÏÔÏËÏÌÏ×.
îÁÓÔÒÏÊËÁ ÓÅÔÅ×ÙÈ ÐÒÏÔÏËÏÌÏ×: IPv4 ïÐÒÅÄÅÌÉÔÅÓØ, ÅÓÔØ ÌÉ ÎÅÏÂÈÏÄÉÍÏÓÔØ × ÐÏÄËÌÀÞÅÎÉÉ Ë ÓÅÔÉ IPv4. üÔÏ ÎÁÉÂÏÌÅÅ ÒÁÓÐÒÏÓÔÒÁΣÎÎÙÊ ÓÅÔÅ×ÏÊ ÐÒÏÔÏËÏÌ.
÷ÙÂÅÒÉÔÅ ÎÁÓÔÒÏÊËÕ ÐÒÏÔÏËÏÌÁ IPv4
óÕÝÅÓÔ×ÕÅÔ Ä×Á ÓÐÏÓÏÂÁ ÎÁÓÔÒÏÊËÉ ÐÒÏÔÏËÏÌÁ IPv4 ÎÁ ÓÅÔÅ×ÏÍ ÉÎÔÅÒÆÅÊÓÅ. óÅÒ×ÉÓ DHCP Á×ÔÏÍÁÔÉÞÅÓËÉ ÕÓÔÁÎÏ×ÉÔ ËÏÒÒÅËÔÎÕÀ ËÏÎÆÉÇÕÒÁÃÉÀ ÓÅÔÅ×ÏÇÏ ÉÎÔÅÒÆÅÊÓÁ, É ÜÔÏ — ÐÒÅÄÐÏÞÔÉÔÅÌØÎÙÊ ÓÐÏÓÏ ÎÁÓÔÒÏÊËÉ. óÔÁÔÉÞÅÓËÁÑ ËÏÎÆÉÇÕÒÁÃÉÑ ÔÒÅÂÕÅÔ ÒÕÞÎÏÇÏ ××ÏÄÁ ÎÁÓÔÒÏÅË ÐÒÏÔÏËÏÌÁ IPv4. îÅ ÐÙÔÁÊÔÅÓØ ××ÅÓÔÉ ÐÒÏÉÚ×ÏÌØÎÙÅ ÄÁÎÎÙÅ, ÏÎÉ ÒÁÂÏÔÁÔØ ÎÅ ÂÕÄÕÔ. ðÏÌÕÞÉÔÅ ÐÅÒÅÞÉÓÌÅÎÎÕÀ × ÉÎÆÏÒÍÁÃÉÀ Õ ÓÅÔÅ×ÏÇÏ ÁÄÍÉÎÉÓÔÒÁÔÏÒÁ ÉÌÉ ÐÏÓÔÁ×ÝÉËÁ ÕÓÌÕÇ éÎÔÅÒÎÅÔ. îÁÓÔÒÏÊËÁ ÐÒÏÔÏËÏÌÁ IPv4 ÎÁ ÓÅÔÅ×ÏÍ ÉÎÔÅÒÆÅÊÓÅ ÐÏÓÒÅÄÓÔ×ÏÍ DHCP åÓÌÉ × ÓÅÔÉ ÅÓÔØ ÓÅÒ×ÉÓ DHCP, ÔÏ ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÇÏ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ ÓÅÔÅ×ÏÇÏ ÉÎÔÅÒÆÅÊÓÁ ×ÙÂÅÒÉÔÅ [ Yes ].
÷ÙÂÏÒ ÎÁÓÔÒÏÊËÉ ÐÒÏÔÏËÏÌÁ IPv4 ÐÏÓÒÅÄÓÔ×ÏÍ DHCP
óÔÁÔÉÞÅÓËÁÑ ÎÁÓÔÒÏÊËÁ ÐÒÏÔÏËÏÌÁ IPv4 ÎÁ ÓÅÔÅ×ÏÍ ÉÎÔÅÒÆÅÊÓÅ óÔÁÔÉÞÅÓËÁÑ ÎÁÓÔÒÏÊËÁ ÓÅÔÅ×ÏÇÏ ÉÎÔÅÒÆÅÊÓÁ ÔÒÅÂÕÅÔ ××ÏÄÁ ÎÅËÏÔÏÒÏÊ ÉÎÆÏÒÍÁÃÉÉ Ï ÐÏÄËÌÀÞÅÎÉÉ IPv4.
óÔÁÔÉÞÅÓËÁÑ ÎÁÓÔÒÏÊËÁ IPv4 ÎÁ ÓÅÔÅ×ÏÍ ÉÎÔÅÒÆÅÊÓÅ
IP Address — ÁÄÒÅÓ IPv4, ËÏÔÏÒÙÊ ÄÏÌÖÅÎ ÂÙÔØ ÕÓÔÁÎÏ×ÌÅÎ ÎÁ ÜÔÏÍ ËÏÍÐØÀÔÅÒÅ. üÔÏÔ ÁÄÒÅÓ ÄÏÌÖÅÎ ÂÙÔØ ÕÎÉËÁÌØÎÙÍ É ÎÅ ÄÏÌÖÅÎ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÄÒÕÇÉÍ ÏÂÏÒÕÄÏ×ÁÎÉÅÍ × ÌÏËÁÌØÎÏÊ ÓÅÔÉ. Subnet Mask — ÍÁÓËÁ, ÉÓÐÏÌØÚÕÅÍÁÑ × ÌÏËÁÌØÎÏÊ ÓÅÔÉ. þÁÓÔÏ ÍÁÓËÁ ÉÍÅÅÔ ÚÎÁÞÅÎÉÅ 255.255.255.0. Default Router — IP ÁÄÒÅÓ ÍÁÒÛÒÕÔÉÚÁÔÏÒÁ ÄÌÑ ÜÔÏÇÏ ÐÏÄËÌÀÞÅÎÉÑ. ïÂÙÞÎÏ ÜÔÏÔ ÁÄÒÅÓ ÕÓÔÁÎÏ×ÌÅÎ ÎÁ ÍÁÒÛÒÕÔÉÚÁÔÏÒÅ ÉÌÉ ÉÎÏÍ ÓÅÔÅ×ÏÍ ÏÂÏÒÕÄÏ×ÁÎÉÉ, ËÏÔÏÒÏÅ ÓÏÅÄÉÎÑÅÔ ÌÏËÁÌØÎÕÀ ÓÅÔØ Ó ÓÅÔØÀ éÎÔÅÒÎÅÔ. ôÁËÖÅ ÉÚ×ÅÓÔÅÎ, ËÁË ÛÌÀÚ ÐÏ ÕÍÏÌÞÁÎÉÀ (default gateway).
îÁÓÔÒÏÊËÁ ÓÅÔÅ×ÙÈ ÐÒÏÔÏËÏÌÏ×: IPv6 IPv6 ÜÔÏ ÂÏÌÅÅ ÎÏ×ÙÊ ÓÅÔÅ×ÏÊ ÐÒÏÔÏËÏÌ. åÓÌÉ ÅÓÔØ ÎÅÏÂÈÏÄÉÍÏÓÔØ É ×ÏÚÍÏÖÎÏÓÔØ ÐÏÄËÌÀÞÅÎÉÑ Ë ÓÅÔÉ IPv6, ×ÙÂÅÒÉÔÅ × ÜÔÏÍ ÍÅÎÀ [ Yes ].
÷ÙÂÅÒÉÔÅ ÎÁÓÔÒÏÊËÕ ÐÒÏÔÏËÏÌÁ IPv6 ÎÁ ÓÅÔÅ×ÏÍ ÉÎÔÅÒÆÅÊÓÅ
äÌÑ ÐÒÏÔÏËÏÌÁ IPv6 ÔÁËÖÅ ×ÏÚÍÏÖÎÙ Ä×Á ÓÐÏÓÏÂÁ ÎÁÓÔÒÏÊËÉ ÓÅÔÅ×ÏÇÏ ÉÎÔÅÒÆÅÊÓÁ. SLAAC ÉÌÉ StateLess Address AutoConfiguration Á×ÔÏÍÁÔÉÞÅÓËÉ ÕÓÔÁÎÏ×ÉÔ ËÏÒÒÅËÔÎÙÅ ÎÁÓÔÒÏÊËÉ ÓÅÔÅ×ÏÇÏ ÉÎÔÅÒÆÅÊÓÁ. óÔÁÔÉÞÅÓËÁÑ ËÏÎÆÉÇÕÒÁÃÉÑ ÔÒÅÂÕÅÔ ÒÕÞÎÏÇÏ ××ÏÄÁ ÎÁÓÔÒÏÅË ÐÒÏÔÏËÏÌÁ IPv6. IPv6 SLAAC SLAAC ÐÏÚ×ÏÌÑÅÔ ÓÅÔÅ×ÏÍÕ ÜÌÅÍÅÎÔÕ ÚÁÐÒÏÓÉÔØ Õ ÌÏËÁÌØÎÏÇÏ ÍÁÒÛÒÕÔÉÚÁÔÏÒÁ ÎÅÏÂÈÏÄÉÍÕÀ ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÊ ÎÁÓÔÒÏÊËÉ ÉÎÆÏÒÍÁÃÉÀ. úÁ ÐÏÄÒÏÂÎÏÓÔÑÍÉ ÏÂÒÁÔÉÔÅÓØ Ë RFC4862.
÷ÙÂÅÒÉÔÅ ÎÁÓÔÒÏÊËÕ ÐÒÏÔÏËÏÌÁ IPv6 ÐÏÓÒÅÄÓÔ×ÏÍ SLAAC
óÔÁÔÉÞÅÓËÁÑ ÎÁÓÔÒÏÊËÁ ÐÒÏÔÏËÏÌÁ IPv6 ÎÁ ÓÅÔÅ×ÏÍ ÉÎÔÅÒÆÅÊÓÅ óÔÁÔÉÞÅÓËÁÑ ÎÁÓÔÒÏÊËÁ ÓÅÔÅ×ÏÇÏ ÉÎÔÅÒÆÅÊÓÁ ÔÒÅÂÕÅÔ ÒÕÞÎÏÇÏ ××ÏÄÁ ÉÎÆÏÒÍÁÃÉÉ Ï IPv6 ÐÏÄËÌÀÞÅÎÉÉ.
óÔÁÔÉÞÅÓËÁÑ ÎÁÓÔÒÏÊËÁ ÐÒÏÔÏËÏÌÁ IPv6
IPv6 Address — ××ÏÄÉÍÙÊ ×ÒÕÞÎÕÀ IP ÁÄÒÅÓ, ËÏÔÏÒÙÊ ÐÒÉÓ×ÏÅÎ ÜÔÏÍÕ ËÏÍÐØÀÔÅÒÕ. üÔÏÔ ÁÄÒÅÓ ÄÏÌÖÅÎ ÂÙÔØ ÕÎÉËÁÌØÎÙÍ É ÎÅ ÄÏÌÖÅÎ ÂÙÔØ ÚÁÎÑÔ ÄÒÕÇÉÍ ÏÂÏÒÕÄÏ×ÁÎÉÅÍ × ÌÏËÁÌØÎÏÊ ÓÅÔÉ. Default Router — IPv6 ÁÄÒÅÓ ÍÁÒÛÒÕÔÉÚÁÔÏÒÁ ÄÌÑ ÜÔÏÊ ÓÅÔÉ. ïÂÙÞÎÏ, ÜÔÏ ÁÄÒÅÓ ÍÁÒÛÒÕÔÉÚÁÔÏÒÁ ÉÌÉ ÄÒÕÇÏÇÏ ÓÅÔÅ×ÏÇÏ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ËÏÔÏÒÏÅ ÓÏÅÄÉÎÑÅÔ ÌÏËÁÌØÎÕÀ ÓÅÔØ Ó ÓÅÔØÀ éÎÔÅÒÎÅÔ. ôÁËÖÅ ÉÚ×ÅÓÔÅÎ ËÁË ÛÌÀÚ ÐÏ ÕÍÏÌÞÁÎÉÀ.
îÁÓÔÒÏÊËÁ òÅÚÏÌ×ÅÒÁ <acronym role="Domain Name System">DNS</acronym> Domain Name System (ÉÌÉ DNS) òÅÚÏÌ×ÅÒ ×ÙÐÏÌÎÑÅÔ ÐÒÅÏÂÒÁÚÏ×ÁÎÉÑ ÉÍÅÎ ÈÏÓÔÏ× × ÓÅÔÅ×ÙÅ ÁÄÒÅÓÁ, Á ÔÁËÖÅ ÐÒÅÏÂÒÁÚÏ×ÁÎÉÑ ÓÅÔÅ×ÙÈ ÁÄÒÅÓÏ× × ÉÍÅÎÁ ÈÏÓÔÏ×. åÓÌÉ ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÇÏ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ ÓÅÔÅ×ÏÇÏ ÉÎÔÅÒÆÅÊÓÁ ÉÓÐÏÌØÚÏ×ÁÌÓÑ DHCP ÉÌÉ SLAAC, ÔÏ ÉÎÆÏÒÍÁÃÉÑ Ï òÅÚÏÌ×ÅÒÅ ÍÏÖÅÔ ÕÖÅ ÐÒÉÓÕÔÓÔ×Ï×ÁÔØ × ÓÉÓÔÅÍÅ. éÎÁÞÅ, ×ÐÉÛÉÔÅ × ÐÏÌÅ Search ÉÍÑ ÌÏËÁÌØÎÏÇÏ ÄÏÍÅÎÁ. DNS #1 É DNS #2 — ÜÔÏ IP ÁÄÒÅÓÁ ÌÏËÁÌØÎÙÈ ÓÅÒ×ÅÒÏ× DNS. ðÏ ËÒÁÊÎÅÊ ÍÅÒÅ ÏÄÉÎ ÓÅÒ×ÅÒ ÄÏÌÖÅÎ ÂÙÔØ ÕËÁÚÁÎ.
ëÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÅ òÅÚÏÌ×ÅÒÁ DNS
õÓÔÁÎÏ×ËÁ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ õÓÔÁÎÏ×ËÁ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ ÄÌÑ ×ÁÛÅÊ ÍÁÛÉÎÙ ÐÏÚ×ÏÌÉÔ ÅÊ Á×ÔÏÍÁÔÉÞÅÓËÉ ËÏÒÒÅËÔÉÒÏ×ÁÔØ ×ÒÅÍÑ ÓÏÇÌÁÓÎÏ ÍÅÓÔÎÙÍ ÚÁËÏÎÁÍ É ÐÒÁ×ÉÌØÎÏ ×ÙÐÏÌÎÑÔØ ÏÓÔÁÌØÎÙÅ ÚÁ×ÉÓÉÍÙÅ ÏÔ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ ÆÕÎËÃÉÉ. äÁÎÎÙÊ ÐÒÉÍÅÒ ×ÅÒÅÎ ÄÌÑ ÍÁÛÉÎÙ, ÎÁÈÏÄÑÝÅÊÓÑ × ×ÏÓÔÏÞÎÏÍ ÞÁÓÏ×ÏÍ ÐÏÑÓÅ óÏÅÄÉÎÅÎÎÙÈ ûÔÁÔÏ×. òÁÚÕÍÅÅÔÓÑ, ×ÁÛÉ ÎÁÓÔÒÏÊËÉ ÄÏÌÖÎÙ ÓÏÏÔ×ÅÔÓÔ×Ï×ÁÔØ ×ÁÛÅÍÕ ÇÅÏÇÒÁÆÉÞÅÓËÏÍÕ ÍÅÓÔÏÐÏÌÏÖÅÎÉÀ.
÷ÙÂÏÒ ÍÅÓÔÎÏÇÏ ×ÒÅÍÅÎÉ ÉÌÉ ×ÒÅÍÅÎÉ UTC
÷ÙÂÅÒÉÔÅ [ Yes ] ÉÌÉ [ No ] ÓÏÇÌÁÓÎÏ ÔÏÍÕ, ËÁË ÎÁÓÔÒÏÅÎÙ ÞÁÓÙ ×ÁÛÅÇÏ ËÏÍÐØÀÔÅÒÁ, ÄÁÌÅÅ ÎÁÖÍÉÔÅ Enter. åÓÌÉ ×Ù ÎÅ ÚÎÁÅÔÅ ËÁËÏÅ ÚÎÁÞÅÎÉÅ ×ÙÂÒÁÔØ, UTC ÉÌÉ ÍÅÓÔÎÏÅ, ÔÏ ÎÁÖÍÉÔÅ [ No ] ÄÌÑ ÔÏÇÏ, ÞÔÏÂÙ ×ÙÂÒÁÔØ ÎÁÉÂÏÌÅÅ ÒÁÓÐÒÏÓÔÒÁΣÎÎÕÀ ËÏÎÆÉÇÕÒÁÃÉÀ — ÍÅÓÔÎÏÅ ×ÒÅÍÑ.
÷ÙÂÅÒÉÔÅ ÒÅÇÉÏÎ
óÏÏÔ×ÅÔÓÔ×ÕÀÝÉÊ ÒÅÇÉÏÎ ×ÙÂÉÒÁÅÔÓÑ ÐÒÉ ÐÏÍÏÝÉ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÐÏÄÔ×ÅÒÖÄÁÅÔÓÑ ÎÁÖÁÔÉÅÍ ËÌÁ×ÉÛÉ Enter.
÷ÙÂÅÒÉÔÅ ÓÔÒÁÎÕ
÷ÙÂÅÒÉÔÅ ÎÅÏÂÈÏÄÉÍÕÀ ÓÔÒÁÎÕ ÐÒÉ ÐÏÍÏÝÉ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÐÏÄÔ×ÅÒÄÉÔÅ ×ÙÂÏÒ ËÌÁ×ÉÛÅÊ Enter.
÷ÙÂÅÒÉÔÅ ÞÁÓÏ×ÏÊ ÐÏÑÓ
óÏÏÔ×ÅÔÓÔ×ÕÀÝÉÊ ÞÁÓÏ×ÏÊ ÐÏÑÓ ×ÙÂÉÒÁÅÔÓÑ ËÌÁ×ÉÛÁÍÉ ÎÁ×ÉÇÁÃÉÉ É ÐÏÄÔ×ÅÒÖÄÁÅÔÓÑ ÎÁÖÁÔÉÅÍ ËÌÁ×ÉÛÉ Enter.
ðÏÄÔ×ÅÒÖÄÅÎÉÅ ×ÙÂÏÒÁ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ
ðÏÄÔ×ÅÒÄÉÔÅ, ÞÔÏ ÁÂÂÒÅ×ÉÁÔÕÒÁ ÄÌÑ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ Ñ×ÌÑÅÔÓÑ ÐÒÉÅÍÌÅÍÏÊ. åÓÌÉ ÄÁÎÎÁÑ ÏÐÃÉÑ ÎÁÓÔÒÏÅÎÁ ×ÅÒÎÏ, ÔÏ ÎÁÖÍÉÔÅ ËÌÁ×ÉÛÕ Enter ÄÌÑ ÐÒÏÄÏÌÖÅÎÉÑ ÐÏÓÌÅÕÓÔÁÎÏ×ÏÞÎÏÇÏ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ.
áËÔÉ×ÉÒÏ×ÁÎÉÅ ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÓÅÔÅ×ÙÈ ÓÅÒ×ÉÓÏ× îÁ ÄÁÎÎÏÍ ÜÔÁÐÅ ÕÓÔÁÎÏ×ÝÉË ÐÒÅÄÌÁÇÁÅÔ ÏÔÍÅÔÉÔØ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ÓÅÔÅ×ÙÅ ÓÅÒ×ÉÓÙ, ËÏÔÏÒÙÅ ÂÕÄÕÔ ÚÁÐÕÓËÁÔØÓÑ ÐÒÉ ÚÁÇÒÕÚËÅ ÓÉÓÔÅÍÙ. ÷ÓÅ ÎÉÖÅÓÌÅÄÕÀÝÉÅ ÓÅÒ×ÉÓÙ ÎÅ Ñ×ÌÑÀÔÓÑ ÏÂÑÚÁÔÅÌØÎÙÍÉ.
÷ÙÂÏÒ ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÁËÔÉ×ÉÒÕÅÍÙÈ ÓÅÒ×ÉÓÏ×
äÏÐÏÌÎÉÔÅÌØÎÙÅ ÓÅÒ×ÉÓÙ sshd - Secure Shell (SSH) ÄÅÍÏÎ ÄÌÑ ÂÅÚÏÐÁÓÎÏÇÏ ÕÄÁÌÅÎÎÏÇÏ ÄÏÓÔÕÐÁ. moused - ïÂÅÓÐÅÞÉ×ÁÅÔ ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÍÙÛÉ × ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ. ntpd - Network Time Protocol (NTP) ÄÅÍÏÎ ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÊ ÓÉÎÈÒÏÎÉÚÁÃÉÉ ×ÒÅÍÅÎÉ. powerd - óÉÓÔÅÍÎÁÑ ÕÔÉÌÉÔÁ ÄÌÑ ËÏÎÔÒÏÌÑ ÐÏÔÒÅÂÌÑÅÍÏÊ ÍÏÝÎÏÓÔÉ É ÐÒÏÆÉÌÅÊ ÜÎÅÒÇÏÓÂÅÒÅÖÅÎÉÑ.
òÁÚÒÅÛÅÎÉÅ ÓÏÈÒÁÎÅÎÉÑ Á×ÁÒÉÊÎÙÈ ÄÁÍÐÏ× äÁÌÅÅ, bsdinstall ÚÁÐÒÏÓÉÔ, ÂÕÄÅÔ ÌÉ ÒÁÚÒÅÛÅÎÏ ÓÏÚÄÁÎÉÅ Á×ÁÒÉÊÎÙÈ ÄÁÍÐÏ× (crash dump) ÎÁ ÃÅÌÅ×ÏÊ ÓÉÓÔÅÍÅ. óÏÈÒÁÎÅÎÉÅ Á×ÁÒÉÊÎÙÈ ÄÁÍÐÏ× ÍÏÖÅÔ ÂÙÔØ ×ÅÓØÍÁ ÐÏÌÅÚÎÙÍ ÐÒÉ ÐÏÉÓËÅ ÎÅÐÏÌÁÄÏË × ÓÉÓÔÅÍÅ, ÐÏÜÔÏÍÕ ÐÏÌØÚÏ×ÁÔÅÌÑÍ ÒÅËÏÍÅÎÄÕÅÔÓÑ ÐÒÉ ×ÓÑËÏÊ ×ÏÚÍÏÖÎÏÓÔÉ ×ËÌÀÞÁÔØ ÓÏÈÒÁÎÅÎÉÅ Á×ÁÒÉÊÎÙÈ ÄÁÍÐÏ×. ÷ÙÂÅÒÉÔÅ [ Yes ] ÄÌÑ ÒÁÚÒÅÛÅÎÉÑ ÓÏÈÒÁÎÅÎÉÑ Á×ÁÒÉÊÎÙÈ ÄÁÍÐÏ× ÉÌÉ [ No ] ÄÌÑ ÏÔÍÅÎÙ ÉÈ ÓÏÈÒÁÎÅÎÉÑ É ÐÒÏÄÏÌÖÅÎÉÑ ÐÏÓÌÅÕÓÔÁÎÏ×ÏÞÎÏÊ ÎÁÓÔÒÏÊËÉ.
òÁÚÒÅÛÅÎÉÅ ÓÏÈÒÁÎÅÎÉÑ Á×ÁÒÉÊÎÙÈ ÄÁÍÐÏ×
äÏÂÁ×ÌÅÎÉÅ ÐÏÌØÚÏ×ÁÔÅÌÅÊ äÏÂÁ×ÌÅÎÉÅ ÈÏÔÑ ÂÙ ÏÄÎÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ × ÐÒÏÃÅÓÓÅ ÕÓÔÁÎÏ×ËÉ ÐÏÚ×ÏÌÉÔ ÜËÓÐÌÕÁÔÉÒÏ×ÁÔØ ÓÉÓÔÅÍÕ ÉÓËÌÀÞÁÑ ÎÅÏÂÈÏÄÉÍÏÓÔØ ×ÈÏÄÁ ÐÏÄ ÕÞÅÔÎÏÊ ÚÁÐÉÓØÀ root. òÁÂÏÔÁ × ÓÉÓÔÅÍÅ Ó ÐÒÁ×ÁÍÉ ÐÏÌØÚÏ×ÁÔÅÌÑ root ÏÓÏÂÅÎÎÁ ÔÅÍ, ÞÔÏ ÐÏ ÓÕÝÅÓÔ×Õ ÎÅÔ ÏÇÒÁÎÉÞÅÎÉÊ ÉÌÉ ÚÁÝÉÔÙ ÏÔ ÄÅÊÓÔ×ÉÊ ÐÏÌØÚÏ×ÁÔÅÌÑ. ÷ÈÏÄ ÐÏÄ ÏÂÙÞÎÙÍ ÐÏÌØÚÏ×ÁÔÅÌÅÍ Ñ×ÌÑÅÔÓÑ ÂÏÌÅÅ ÂÌÁÇÏÒÁÚÕÍÎÙÍ É ÂÅÚÏÐÁÓÎÙÍ. äÌÑ ÄÏÂÁ×ÌÅÎÉÑ ÎÏ×ÙÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ ×ÙÂÅÒÉÔÅ [ Yes ].
äÏÂÁ×ÌÅÎÉÅ ÐÏÌØÚÏ×ÁÔÅÌØÓËÉÈ ÕÞÅÔÎÙÈ ÚÁÐÉÓÅÊ
÷×ÅÄÉÔÅ ÉÎÆÏÒÍÁÃÉÀ Ï ÎÏ×ÏÍ ÐÏÌØÚÏ×ÁÔÅÌÅ.
÷×ÏÄ ÉÎÆÏÒÍÁÃÉÉ Ï ÐÏÌØÚÏ×ÁÔÅÌÅ
éÎÆÏÒÍÁÃÉÑ Ï ÐÏÌØÚÏ×ÁÔÅÌÅ Username — éÍÑ, ËÏÔÏÒÏÅ ÂÕÄÅÔ ÎÁÂÉÒÁÔØ ÐÏÌØÚÏ×ÁÔÅÌØ ÄÌÑ ×ÈÏÄÁ × ÓÉÓÔÅÍÕ. þÁÓÔÏ ÏÎÏ ÆÏÒÍÉÒÕÅÔÓÑ ÉÚ ÏÂßÅÄÉÎÅÎÎÙÈ ×ÍÅÓÔÅ ÐÅÒ×ÏÊ ÂÕË×Ù ÉÍÅÎÉ É ÆÁÍÉÌÉÉ. Full name — ðÏÌÎÏÅ ÉÍÑ ÐÏÌØÚÏ×ÁÔÅÌÑ. Uid — éÄÅÎÔÉÆÉËÁÔÏÒ ÐÏÌØÚÏ×ÁÔÅÌÑ. ïÂÙÞÎÏ ÜÔÏ ÐÏÌÅ ÎÅ ÚÁÐÏÌÎÑÅÔÓÑ, ÓÉÓÔÅÍÁ ÓÁÍÁ ÐÒÉÓ×ÏÉÔ ÅÍÕ ÚÎÁÞÅÎÉÅ. Login group — éÍÑ ÇÒÕÐÐÙ ÄÌÑ ÜÔÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ. ïÂÙÞÎÏ ÜÔÏ ÐÏÌÅ ÔÁËÖÅ ÎÅ ÚÁÐÏÌÎÑÅÔÓÑ, ÓÉÓÔÅÍÁ ÐÏÓÔÁ×ÉÔ ÚÎÁÞÅÎÉÅ ÐÏ ÕÍÏÌÞÁÎÉÀ. Invite user into other groups? — ðÅÒÅÞÅÎØ ÇÒÕÐÐ, × ËÏÔÏÒÙÅ ÂÕÄÅÔ ×ÎÅÓÅÎ ÐÏÌØÚÏ×ÁÔÅÌØ. Login class — ïÂÙÞÎÏ ÏÓÔÁ×ÌÑÅÔÓÑ ÐÕÓÔÙÍ ÄÌÑ ÐÒÉÎÑÔÉÑ ÚÎÁÞÅÎÉÑ ÐÏ ÕÍÏÌÞÁÎÉÀ. Shell — éÎÔÅÒÁËÔÉ×ÎÁÑ ÏÂÏÌÏÞËÁ ÄÌÑ ÜÔÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ. ÷ ÄÁÎÎÏÍ ÐÒÉÍÅÒÅ ÂÙÌÁ ×ÙÂÒÁÎÁ ÏÂÏÌÏÞËÁ &man.csh.1;. Home directory — äÏÍÁÛÎÉÊ ËÁÔÁÌÏÇ ÐÏÌØÚÏ×ÁÔÅÌÑ. ëÁË ÐÒÁ×ÉÌÏ, ÚÎÁÞÅÎÉÅ ÐÏ ÕÍÏÌÞÁÎÉÀ Ñ×ÌÑÅÔÓÑ ËÏÒÒÅËÔÎÙÍ. Home directory permissions — ðÒÁ×Á ÎÁ ÄÏÍÁÛÎÉÊ ËÁÔÁÌÏÇ ÐÏÌØÚÏ×ÁÔÅÌÑ. úÎÁÞÅÎÉÅ ÐÏ ÕÍÏÌÞÁÎÉÀ Ñ×ÌÑÅÔÓÑ ËÏÒÒÅËÔÎÙÍ × ÂÏÌØÛÉÎÓÔ×Å ÓÌÕÞÁÅ×. Use password-based authentication? — ïÂÙÞÎÏ "yes". Use an empty password? — ïÂÙÞÎÏ "no". Use a random password? — ïÂÙÞÎÏ "no". Enter password — ðÁÒÏÌØ ÄÌÑ ÜÔÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ. îÁÂÉÒÁÅÍÙÅ ÓÉÍ×ÏÌÙ ÎÅ ÏÔÏÂÒÁÖÁÀÔÓÑ ÎÁ ÜËÒÁÎÅ. Enter password again — ðÁÒÏÌØ ÎÅÏÂÈÏÄÉÍÏ ××ÅÓÔÉ ÅÝÅ ÒÁÚ (ÄÌÑ Ó×ÅÒËÉ). Lock out the account after creation? — ïÂÙÞÎÏ "no". ðÏÓÌÅ ÚÁÐÏÌÎÅÎÉÑ ÎÅÏÂÈÏÄÉÍÙÈ ÐÏÌÅÊ ÂÕÄÅÔ ÏÔÏÂÒÁÖÅÎ ÉÔÏÇ É ÓÉÓÔÅÍÁ ÐÅÒÅÓÐÒÏÓÉÔ, ËÏÒÒÅËÔÎÙ ÌÉ ××ÅÄ£ÎÎÙÅ ÄÁÎÎÙÅ. åÓÌÉ ×Ï ×ÒÅÍÑ ××ÏÄÁ ÉÎÆÏÒÍÁÃÉÉ ÂÙÌÁ ÄÏÐÕÝÅÎÁ ÏÛÉÂËÁ, ÔÏ ÎÅÏÂÈÏÄÉÍÏ ÏÔ×ÅÔÉÔØ no É ××ÅÓÔÉ ÄÁÎÎÙÅ ÅÝÅ ÒÁÚ. åÓÌÉ ×ÁÓ ×Ó£ ÕÓÔÒÁÉ×ÁÅÔ, ×ÙÂÅÒÉÔÅ yes ÄÌÑ ÓÏÚÄÁÎÉÑ ÎÏ×ÏÊ ÕÞÅÔÎÏÊ ÚÁÐÉÓÉ ÐÏÌØÚÏ×ÁÔÅÌÑ.
úÁÐÏÌÎÅÎÎÁÑ ÆÏÒÍÁ ××ÏÄÁ ÉÎÆÏÒÍÁÃÉÉ Ï ÎÏ×ÏÍ ÐÏÌØÚÏ×ÁÔÅÌÅ
ïÔ×ÅÔØÔÅ yes ÎÁ ×ÏÐÒÏÓ "Add another user?" ÅÓÌÉ ÎÅÏÂÈÏÄÉÍÏ ÄÏÂÁ×ÉÔØ ÄÒÕÇÉÅ ÕÞÅÔÎÙÅ ÚÁÐÉÓÉ. äÌÑ ÚÁ×ÅÒÛÅÎÉÑ ÄÏÂÁ×ÌÅÎÉÑ ÐÏÌØÚÏ×ÁÔÅÌÅÊ É ÐÒÏÄÏÌÖÅÎÉÑ ÐÏÓÌÅÕÓÔÁÎÏ×ÏÞÎÏÊ ÎÁÓÔÒÏÊËÉ ×ÙÂÅÒÉÔÅ no. úÁ ÂÏÌÅÅ ÄÅÔÁÌØÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ Ï ÕÐÒÁ×ÌÅÎÉÉ ÕÞÅÔÎÙÍÉ ÚÁÐÉÓÑÍÉ ÏÂÒÁÔÉÔÅÓØ Ë .
úÁ×ÅÒÛÅÎÉÅ ÎÁÓÔÒÏÊËÉ ðÏÓÌÅ ÔÏÇÏ, ËÁË ÕÓÔÁÎÏ×ËÁ É ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÅ ÚÁ×ÅÒÛÅÎÙ, ×ÁÍ ÐÒÅÄÏÓÔÁ×ÌÑÅÔÓÑ ÚÁËÌÀÞÉÔÅÌØÎÁÑ ×ÏÚÍÏÖÎÏÓÔØ ÐÏÄËÏÒÒÅËÔÉÒÏ×ÁÔØ ÎÁÓÔÒÏÊËÉ.
æÉÎÁÌØÎÏÅ ËÏÎÆÉÇÕÒÁÃÉÏÎÎÏÅ ÍÅÎÀ
éÓÐÏÌØÚÕÊÔÅ ÜÔÏ ÍÅÎÀ ÄÌÑ ×ÎÅÓÅÎÉÑ ÌÀÂÙÈ ÉÚÍÅÎÅÎÉÊ ÉÌÉ ÄÌÑ ×ÙÐÏÌÎÅÎÉÑ ÄÏÐÏÌÎÉÔÅÌØÎÏÇÏ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ ÐÅÒÅÄ ÚÁ×ÅÒÛÅÎÉÅÍ ÕÓÔÁÎÏ×ËÉ. ïÐÃÉÉ ÆÉÎÁÌØÎÏÇÏ ËÏÎÆÉÇÕÒÁÃÉÏÎÎÏÇÏ ÍÅÎÀ Add User — ïÐÉÓÁÎÏ × . Root Password — ïÐÉÓÁÎÏ × . Hostname — ïÐÉÓÁÎÏ × . Network — ïÐÉÓÁÎÏ × . Services — ïÐÉÓÁÎÏ × . Time Zone — ïÐÉÓÁÎÏ × . Handbook — úÁÇÒÕÚËÁ É ÕÓÔÁÎÏ×ËÁ òÕËÏ×ÏÄÓÔ×Á &os; (ËÏÔÏÒÏÅ ×Ù × ÄÁÎÎÙÊ ÍÏÍÅÎÔ ÞÉÔÁÅÔÅ). ðÏ ÚÁ×ÅÒÛÅÎÉÉ ÎÁÓÔÒÏÊËÉ ÄÌÑ ×ÙÈÏÄÁ ÉÚ ÆÉÎÁÌØÎÏÇÏ ËÏÎÆÉÇÕÒÁÃÉÏÎÎÏÇÏ ÍÅÎÀ ×ÙÂÅÒÉÔÅ Exit.
òÕÞÎÁÑ ÎÁÓÔÒÏÊËÁ
bsdinstall ÕÔÏÞÎÉÔ, ÅÓÔØ ÌÉ ËÁËÉÅ ÎÁÓÔÒÏÊËÉ, ËÏÔÏÒÙÅ ÎÅÏÂÈÏÄÉÍÏ ×ÙÐÏÌÎÉÔØ ÄÏ ÐÅÒÅÚÁÇÒÕÚËÉ × Ó×ÅÖÅÕÓÔÁÎÏ×ÌÅÎÎÕÀ ÓÉÓÔÅÍÕ. äÌÑ ×ÈÏÄÁ × ËÏÍÁÎÄÎÙÊ ÉÎÔÅÒÐÒÅÔÁÔÏÒ ÎÏ×ÏÊ ÓÉÓÔÅÍÙ ×ÙÂÅÒÉÔÅ [ Yes ], ÄÌÑ ÐÅÒÅÈÏÄÁ Ë ÐÏÓÌÅÄÎÅÍÕ ÛÁÇÕ ÕÓÔÁÎÏ×ËÉ ÎÁÖÍÉÔÅ [ No ].
úÁ×ÅÒÛÅÎÉÅ ÕÓÔÁÎÏ×ËÉ
åÓÌÉ ÎÅÏÂÈÏÄÉÍÏ ÄÁÌØÎÅÊÛÅÅ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÅ ÉÌÉ ÏÓÏÂÁÑ ÕÓÔÁÎÏ×ËÁ, ÔÏ ×ÙÂÏÒ [ Live CD ] ÚÁÇÒÕÚÉÔ ÕÓÔÁÎÏ×ÏÞÎÙÊ ÎÏÓÉÔÅÌØ × ÒÅÖÉÍ Live CD. ðÏÓÌÅ ÔÏÇÏ, ËÁË ÕÓÔÁÎÏ×ËÁ ÚÁ×ÅÒÛÅÎÁ, ÄÌÑ ÐÅÒÅÚÁÇÒÕÚËÉ ËÏÍÐØÀÔÅÒÁ É ÚÁÐÕÓËÁ ÎÏ×ÏÊ ÓÉÓÔÅÍÙ &os; ×ÙÂÅÒÉÔÅ [ Reboot ]. îÅ ÚÁÂÕÄØÔÅ ÉÚ×ÌÅÞØ ÕÓÔÁÎÏ×ÏÞÎÙÊ CD, DVD ÉÌÉ USB-ÎÁËÏÐÉÔÅÌØ, ÉÎÁÞÅ ËÏÍÐØÀÔÅÒ ÍÏÖÅÔ ÓÎÏ×Á Ó ÎÅÇÏ ÚÁÇÒÕÚÉÔØÓÑ.
úÁÇÒÕÚËÁ É ÚÁ×ÅÒÛÅÎÉÅ ÒÁÂÏÔÙ &os; (&os;/&arch.i386; Booting) úÁÇÒÕÚËÁ &os;/&arch.i386; ÷Ï ×ÒÅÍÑ ÚÁÇÒÕÚËÉ &os; ÏÔÏÂÒÁÖÁÅÔÓÑ ÍÎÏÖÅÓÔ×Ï ÉÎÆÏÒÍÁÃÉÏÎÎÙÈ ÓÏÏÂÝÅÎÉÊ. âÏÌØÛÉÎÓÔ×Ï ÉÚ ÎÉÈ ×ÙÔÅÓÎÉÔÓÑ ÚÁ ÐÒÅÄÅÌÙ ÜËÒÁÎÁ; ÜÔÏ ÎÏÒÍÁÌØÎÏ. ðÏ ÚÁ×ÅÒÛÅÎÉÉ ÚÁÇÒÕÚËÉ ÓÉÓÔÅÍÙ ÂÕÄÅÔ ÏÔÏÂÒÁÖÅÎÏ ÐÒÉÇÌÁÛÅÎÉÅ ËÏ ×ÈÏÄÕ (login prompt). óÏÏÂÝÅÎÉÑ, ËÏÔÏÒÙÅ ÐÅÒÅÍÅÓÔÉÌÉÓØ ÚÁ ÐÒÅÄÅÌÙ ÜËÒÁÎÁ, ÍÏÇÕÔ ÂÙÔØ ÐÒÏÓÍÏÔÒÅÎÙ: ÐÒÉ ÎÁÖÁÔÉÉ Scroll-Lock ×ËÌÀÞÁÅÔÓÑ ÒÅÖÉÍ ÂÕÆÅÒÁ ÐÒÏËÒÕÔËÉ. ëÌÁ×ÉÛÉ PgUp, PgDn, Á ÔÁËÖÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÍÏÇÕÔ ÂÙÔØ ÚÁÄÅÊÓÔ×Ï×ÁÎÙ ÄÌÑ ÐÒÏËÒÕÞÉ×ÁÎÉÑ ÂÕÆÅÒÁ. ðÏ×ÔÏÒÎÏÅ ÎÁÖÁÔÉÅ Scroll-Lock ÒÁÚÂÌÏËÉÒÕÅÔ ÄÉÓÐÌÅÊ É ×ÅÒÎÅÔ ÅÇÏ × ÎÏÒÍÁÌØÎÙÊ ÒÅÖÉÍ. îÁ ÐÒÉÇÌÁÛÅÎÉÅ login: ××ÅÄÉÔÅ ÄÏÂÁ×ÌÅÎÎÏÅ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ ÉÍÑ ÐÏÌØÚÏ×ÁÔÅÌÑ, × ÜÔÏÍ ÐÒÉÍÅÒÅ — asample. úÁ ÉÓËÌÀÞÅÎÉÅÍ ÓÌÕÞÁÅ× ËÒÁÊÎÅÊ ÎÅÏÂÈÏÄÉÍÏÓÔÉ ÉÚÂÅÇÁÊÔÅ ×ÈÏÄÁ ÐÏÄ ÕÞÅÔÎÏÊ ÚÁÐÉÓØÀ root. õÐÏÍÑÎÕÔÙÊ ×ÙÛÅ ÂÕÆÅÒ ÐÒÏËÒÕÔËÉ ÏÇÒÁÎÉÞÅÎ × ÒÁÚÍÅÒÅ, ÐÏÜÔÏÍÕ × ÎÅÇÏ ÍÏÇÕÔ ÕÍÅÝÁÔØÓÑ ÎÅ ×ÓÅ ÓÏÏÂÝÅÎÉÑ. ðÏÓÌÅ ×ÈÏÄÁ × ÓÉÓÔÅÍÕ ÂÏÌØÛÉÎÓÔ×Ï ÉÚ ÎÉÈ ÍÏÖÎÏ ÐÒÏÓÍÏÔÒÅÔØ ÐÏÄÁ× ËÏÍÁÎÄÕ dmesg | less ÉÚ ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÉ. äÌÑ ×ÏÚ×ÒÁÔÁ Ë ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÅ ÐÏÓÌÅ ÐÒÏÓÍÏÔÒÁ ÓÏÏÂÝÅÎÉÊ ÎÁÖÍÉÔÅ q. ôÉÐÉÞÎÙÅ ÓÏÏÂÝÅÎÉÑ ÚÁÇÒÕÚËÉ (ÉÎÆÏÒÍÁÃÉÑ Ï ×ÅÒÓÉÑÈ ÏÐÕÝÅÎÁ): Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3007.77-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0x783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2> Features2=0x209<SSE3,MON,SSSE3> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> real memory = 536805376 (511 MB) avail memory = 491819008 (469 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <VBOX VBOXAPIC> ioapic0: Changing APIC ID to 1 ioapic0 <Version 1.1> irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <VBOX VBOXXSDT> on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: <ACPI CPU> on acpi0 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0 isab0: <PCI-ISA bridge> at device 1.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <Intel PIIX4 UDMA33 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 ata0: <ATA channel 0> on atapci0 ata1: <ATA channel 1> on atapci0 vgapci0: <VGA-compatible display> mem 0xe0000000-0xe0ffffff irq 18 at device 2.0 on pci0 em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.3> port 0xd010-0xd017 mem 0xf0000000-0xf001ffff irq 19 at device 3.0 on pci0 em0: Ethernet address: 08:00:27:9f:e0:92 pci0: <base peripheral> at device 4.0 (no driver attached) pcm0: <Intel ICH (82801AA)> port 0xd100-0xd1ff,0xd200-0xd23f irq 21 at device 5.0 on pci0 pcm0: <SigmaTel STAC9700/83/84 AC97 Codec> ohci0: <OHCI (generic) USB controller> mem 0xf0804000-0xf0804fff irq 22 at device 6.0 on pci0 usbus0: <OHCI (generic) USB controller> on ohci0 pci0: <bridge> at device 7.0 (no driver attached) acpi_acad0: <AC Adapter> on acpi0 atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 attimer0: <AT timer> port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: <AT realtime clock> at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 ppc0: cannot reserve I/O port range Timecounters tick every 10.000 msec pcm0: measured ac97 link rate at 485193 Hz em0: link state changed to UP usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: <Apple> at usbus0 uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: <VBOX CD-ROM 1.0> Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: <VBOX HARDDISK 1.0> ATA-6 device ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) ada0: 12546MB (25694208 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 Timecounter "TSC" frequency 3007772192 Hz quality 800 Root mount waiting for: usbus0 uhub0: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ada0p2 [rw]... Setting hostuuid: 1848d7bf-e6a4-4ed4-b782-bd3f1685d551. Setting hostid: 0xa03479b2. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p2: clean, 2620402 free (714 frags, 327461 blocks, 0.0% fragmentation) Mounting local file systems:. vboxguest0 port 0xd020-0xd03f mem 0xf0400000-0xf07fffff,0xf0800000-0xf0803fff irq 20 at device 4.0 on pci0 vboxguest: loaded successfully Setting hostname: machine3.example.com. Starting Network: lo0 em0. lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> ether 08:00:27:9f:e0:92 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active Starting devd. Starting Network: usbus0. DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 10.0.2.2 bound to 192.168.1.142 -- renewal in 43200 seconds. add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 32-bit compatibility ldconfig path: /usr/lib32 Creating and/or trimming log files. Starting syslogd. No core dumps found. Clearing /tmp (X related). Updating motd:. Configuring syscons: blanktime. Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: 10:a0:f5:af:93:ae:a3:1a:b2:bb:3c:35:d9:5a:b3:f3 root@machine3.example.com The key's randomart image is: +--[RSA1 1024]----+ | o.. | | o . . | | . o | | o | | o S | | + + o | |o . + * | |o+ ..+ . | |==o..o+E | +-----------------+ Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: 7e:1c:ce:dc:8a:3a:18:13:5b:34:b5:cf:d9:d1:47:b2 root@machine3.example.com The key's randomart image is: +--[ DSA 1024]----+ | .. . .| | o . . + | | . .. . E .| | . . o o . . | | + S = . | | + . = o | | + . * . | | . . o . | | .o. . | +-----------------+ Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Thu Oct 6 19:15:31 MDT 2011 FreeBSD/amd64 (machine3.example.com) (ttyv0) login: îÁ ÍÅÄÌÅÎÎÙÈ ÍÁÛÉÎÁÈ ÇÅÎÅÒÉÒÏ×ÁÎÉÅ ËÌÀÞÅÊ RSA É DSA ÍÏÖÅÔ ÚÁÎÑÔØ ÏÝÕÔÉÍÏÅ ×ÒÅÍÑ. üÔÏ ÐÒÏÉÓÈÏÄÉÔ ÌÉÛØ ÐÒÉ ÐÅÒ×ÏÊ ÚÁÇÒÕÚËÅ ÎÏ×ÏÊ ÓÉÓÔÅÍÙ, É ÌÉÛØ × ÓÌÕÞÁÅ, ËÏÇÄÁ sshd ÎÁÓÔÒÏÅÎ ÎÁ Á×ÔÏÍÁÔÉÞÅÓËÉÊ ÚÁÐÕÓË. ðÏÓÌÅÄÕÀÝÉÅ ÚÁÇÒÕÚËÉ ÂÕÄÕÔ ÐÒÏÈÏÄÉÔØ ÂÙÓÔÒÅÅ. ðÏ ÕÍÏÌÞÁÎÉÀ ×Ï &os; ÎÅ ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÓÑ ÎÉËÁËÉÈ ÇÒÁÆÉÞÅÓËÉÈ ÏÂÏÌÏÞÅË, ÏÄÎÁËÏ × ÎÁÌÉÞÉÉ ÏÎÉ ÉÍÅÀÔÓÑ. úÁ ÂÏÌÅÅ ÐÏÄÒÏÂÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ ÏÂÒÁÔÉÔÅÓØ Ë . úÁ×ÅÒÛÅÎÉÅ ÒÁÂÏÔÙ &os; ëÏÒÒÅËÔÎÏÅ ÚÁ×ÅÒÛÅÎÉÅ ÒÁÂÏÔÙ ËÏÍÐØÀÔÅÒÁ Ó &os; ÐÏÍÏÇÁÅÔ ÚÁÝÉÔÉÔØ ÏÔ ÐÏ×ÒÅÖÄÅÎÉÊ ÎÅ ÔÏÌØËÏ ÄÁÎÎÙÅ, ÎÏ ÄÁÖÅ É ÁÐÐÁÒÁÔÎÏÅ ÏÂÅÓÐÅÞÅÎÉÅ. îÅ ÓÔÏÉÔ ÐÒÏÓÔÏ ×ÙËÌÀÞÁÔØ ÐÉÔÁÎÉÅ. åÓÌÉ ×Ù ×ÈÏÄÉÔÅ × ÇÒÕÐÐÕ wheel, ÔÏ ÓÔÁÎØÔÅ ÓÕÐÅÒÐÏÌØÚÏ×ÁÔÅÌÅÍ ÎÁÂÒÁ× × ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÅ ËÏÍÁÎÄÕ su É ××ÅÄÑ ÐÁÒÏÌØ ÐÏÌØÚÏ×ÁÔÅÌÑ root. éÌÉ ÖÅ, ×ÏÊÄÉÔÅ × ÓÉÓÔÅÍÕ ËÁË root É ÎÁÂÅÒÉÔÅ ËÏÍÁÎÄÕ shutdown -p now. óÉÓÔÅÍÁ ËÏÒÒÅËÔÎÏ ÚÁ×ÅÒÛÉÔ ÒÁÂÏÔÕ É ×ÙËÌÀÞÉÔÓÑ. ëÏÍÂÉÎÁÃÉÑ ËÌÁ×ÉÛ Ctrl Alt Del ÍÏÖÅÔ ÂÙÔØ ÚÁÄÅÊÓÔ×Ï×ÁÎÁ ÄÌÑ ÐÅÒÅÚÁÇÒÕÚËÉ ÓÉÓÔÅÍÙ, ÏÄÎÁËÏ ×Ï ×ÒÅÍÑ ÎÏÒÍÁÌØÎÏÊ ÒÁÂÏÔÙ ÐÏÌØÚÏ×ÁÔØÓÑ ÅÀ ÎÅ ÒÅËÏÍÅÎÄÕÅÔÓÑ.
òÅÛÅÎÉÅ ÐÒÏÂÌÅÍ ÕÓÔÁÎÏ×ËÁ ÒÅÛÅÎÉÅ ÐÒÏÂÌÅÍ îÉÖÅÓÌÅÄÕÀÝÉÊ ÒÁÚÄÅÌ ÏÐÉÓÙ×ÁÅÔ ÞÁÓÔÏ ×ÓÔÒÅÞÁÀÝÉÅÓÑ É ÓÏÏÂÝÅÎÎÙÅ ÐÏÌØÚÏ×ÁÔÅÌÑÍÉ ÐÒÏÂÌÅÍÙ, ×ÏÚÎÉËÁÀÝÉÅ × ÈÏÄÅ ÕÓÔÁÎÏ×ËÉ. þÔÏ ÄÅÌÁÔØ, ÅÓÌÉ ÞÔÏ-ÔÏ ÉÄÅÔ ÎÅ ÔÁË ðÏ ÐÒÉÞÉÎÅ ÒÁÚÌÉÞÎÙÈ ÏÇÒÁÎÉÞÅÎÉÊ ÁÒÈÉÔÅËÔÕÒÙ PC, ÏÐÒÅÄÅÌÅÎÉÅ ÐÅÒÉÆÅÒÉÊÎÙÈ ÕÓÔÒÏÊÓÔ× (device probing) ÎÅ ÍÏÖÅÔ ÂÙÔØ ÄÏÓÔÏ×ÅÒÎÙÍ ÎÁ ×ÓÅ 100%, ÏÄÎÁËÏ, ÅÓÔØ ÎÅÓËÏÌØËÏ ÛÁÇÏ×, ËÏÔÏÒÙÅ ×Ù ÍÏÖÅÔÅ ÐÒÅÄÐÒÉÎÑÔØ, ÅÓÌÉ ÏÐÒÅÄÅÌÅÎÉÅ ÚÁ×ÅÒÛÉÔÓÑ ÎÅÕÄÁÞÎÏ. ðÒÏÓÍÏÔÒÉÔÅ éÎÆÏÒÍÁÃÉÀ Ï ÏÂÏÒÕÄÏ×ÁÎÉÉ (Hardware Notes) ÄÌÑ ×ÁÛÅÊ ×ÅÒÓÉÉ &os; ÞÔÏÂÙ ÕÂÅÄÉÔØÓÑ, ÞÔÏ ×ÁÛÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ. åÓÌÉ ×ÁÛÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ, Á ÚÁ×ÉÓÁÎÉÑ ÉÌÉ ÄÒÕÇÉÅ ÐÒÏÂÌÅÍÙ ÐÒÏÄÏÌÖÁÀÔÓÑ, ÔÏ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÂÕÄÅÔ ÐÏÓÔÒÏÉÔØ ÓÏÂÓÔ×ÅÎÎÏÅ ÑÄÒÏ. üÔÏ ÐÏÚ×ÏÌÉÔ ×ÁÍ ÄÏÂÁ×ÉÔØ ÐÏÄÄÅÒÖËÕ ÕÓÔÒÏÊÓÔ×, ËÏÔÏÒÙÅ ÏÔÓÕÔÓÔ×ÕÀÔ × ÑÄÒÅ GENERIC. ñÄÒÏ ÎÁ ÕÓÔÁÎÏ×ÏÞÎÙÈ ÄÉÓËÁÈ ÓËÏÎÆÉÇÕÒÉÒÏ×ÁÎÏ ÉÓÈÏÄÑ ÉÚ ÐÒÅÄÐÏÌÏÖÅÎÉÑ, ÞÔÏ ÂÏÌØÛÉÎÓÔ×Ï ÕÓÔÒÏÊÓÔ× ÎÁÈÏÄÑÔÓÑ × ÎÁÓÔÒÏÊËÁÈ ÐÏ ÕÍÏÌÞÁÎÉÀ ËÁÓÁÔÅÌØÎÏ ÐÒÅÒÙ×ÁÎÉÊ, ÁÄÒÅÓÏ× ××ÏÄÁ/×Ù×ÏÄÁ, ËÁÎÁÌÏ× DMA. åÓÌÉ ×ÁÛÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÂÙÌÏ ÐÅÒÅÎÁÓÔÒÏÅÎÏ, ÔÏ ×ÁÍ ÓËÏÒÅÅ ×ÓÅÇÏ ÎÅÏÂÈÏÄÉÍÏ ÂÕÄÅÔ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ËÏÎÆÉÇÕÒÁÃÉÏÎÎÙÊ ÆÁÊÌ ÑÄÒÁ É ÐÅÒÅÓÏÂÒÁÔØ ÅÇÏ, ÞÔÏÂÙ ÓÏÏÂÝÉÔØ &os; Ï ÎÁÓÔÒÏÊËÁÈ, ÏÔÌÉÞÎÙÈ ÏÔ ÐÒÅÄÐÏÌÁÇÁÅÍÙÈ. ôÁËÖÅ ×ÏÚÍÏÖÎÙ ÓÌÕÞÁÉ, ËÏÇÄÁ ÐÒÏÃÅÄÕÒÁ ÏÐÒÅÄÅÌÅÎÉÑ (probe) ÄÌÑ ÏÔÓÕÔÓÔ×ÕÀÝÅÇÏ ÕÓÔÒÏÊÓÔ×Á ÐÒÉ×ÏÄÉÔ Ë ÓÂÏÀ ÐÒÏÃÅÄÕÒÙ ÏÐÒÅÄÅÌÅÎÉÑ ÄÌÑ ÄÒÕÇÏÇÏ ÕÓÔÒÏÊÓÔ×Á, ÐÒÉÓÕÔÓÔ×ÕÀÝÅÇÏ × ÁÐÐÁÒÁÔÎÏÊ ËÏÎÆÉÇÕÒÁÃÉÉ. ÷ ÜÔÏÍ ÓÌÕÞÁÅ ÎÅÏÂÈÏÄÉÍÏ ÏÔËÌÀÞÉÔØ ÐÒÏÃÅÄÕÒÕ (ÐÒÏÃÅÄÕÒÙ) ÏÐÒÅÄÅÌÅÎÉÑ ÄÌÑ ËÏÎÆÌÉËÔÕÀÝÅÇÏ ÄÒÁÊ×ÅÒÁ (ÄÒÁÊ×ÅÒÏ×). îÅËÏÔÏÒÏÅ ËÏÌÉÞÅÓÔ×Ï ÐÒÏÂÌÅÍ Ó ÕÓÔÁÎÏ×ËÏÊ ÍÏÖÅÔ ÂÙÔØ ÕÓÔÒÁÎÅÎÏ ÉÌÉ ÕÍÅÎØÛÅÎÏ ÐÕÔÅÍ ÏÂÎÏ×ÌÅÎÉÑ ×ÓÔÒÏÅÎÎÏÇÏ ÐÒÏÇÒÁÍÍÎÏÇÏ ÏÂÅÓÐÅÞÅÎÉÑ ÒÁÚÌÉÞÎÙÈ ÁÐÐÁÒÁÔÎÙÈ ËÏÍÐÏÎÅÎÔÏ×, ÏÓÏÂÅÎÎÏ — ÍÁÔÅÒÉÎÓËÏÊ ÐÌÁÔÙ. ÷ÓÔÒÏÅÎÎÏÅ ÐÒÏÇÒÁÍÍÎÏÅ ÏÂÅÓÐÅÞÅÎÉÅ ÍÁÔÅÒÉÎÓËÏÊ ÐÌÁÔÙ ÏÂÙÞÎÏ ÎÁÚÙ×ÁÅÔÓÑ BIOS. õ ÂÏÌØÛÉÎÓÔ×Á ÐÒÏÉÚ×ÏÄÉÔÅÌÅÊ ÍÁÔÅÒÉÎÓËÉÈ ÐÌÁÔ É ËÏÍÐØÀÔÅÒÏ× ÅÓÔØ Web-ÓÁÊÔÙ, ÓÏÄÅÒÖÁÝÉÅ ËÁË ÉÎÆÏÒÍÁÃÉÀ Ï ÏÂÎÏ×ÌÅÎÉÑÈ, ÔÁË É ÓÁÍÉ ÏÂÎÏ×ÌÅÎÉÑ. ÷ ÏÂÝÅÍ, ÐÒÏÉÚ×ÏÄÉÔÅÌÉ ÎÅ ÒÅËÏÍÅÎÄÕÀÔ ÏÂÎÏ×ÌÑÔØ BIOS ÍÁÔÅÒÉÎÓËÏÊ ÐÌÁÔÙ, ÅÓÌÉ ÎÁ ÔÏ ÎÅÔ ×ÅÓËÉÈ ÐÒÉÞÉÎ, ÎÁÐÒÉÍÅÒ, ÔÁËÉÈ ËÁË ÐÏÑ×ÌÅÎÉÅ ËÒÉÔÉÞÅÓËÉ ×ÁÖÎÏÇÏ ÏÂÎÏ×ÌÅÎÉÑ. ðÒÏÃÅÓÓ ÏÂÎÏ×ÌÅÎÉÑ ÍÏÖÅÔ ÐÏÔÅÒÐÅÔØ ÎÅÕÄÁÞÕ, ÔÅÍ ÓÁÍÙÍ ÏÓÔÁ×É× BIOS ÐÏ×ÒÅÖÄÅÎÎÙÍ, Á ËÏÍÐØÀÔÅÒ — ÎÅÒÁÂÏÞÉÍ. òÅÛÅÎÉÅ ÐÒÏÂÌÅÍ: ×ÏÐÒÏÓÙ É ÏÔ×ÅÔÙ íÏÑ ÓÉÓÔÅÍÁ ÚÁ×ÉÓÁÅÔ ×Ï ×ÒÅÍÑ ÚÁÇÒÕÚËÉ ÎÁ ÜÔÁÐÅ ÏÐÒÅÄÅÌÅÎÉÑ ÕÓÔÒÏÊÓÔ× (probing), ÉÌÉ ÏÎÁ ×ÅÄÅÔ ÓÅÂÑ ÓÔÒÁÎÎÏ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ. ëÁÓÁÔÅÌØÎÏ ÐÌÁÔÆÏÒÍ &arch.i386;, &arch.amd64; É &arch.ia64;: ÅÓÌÉ ×Ï ×ÒÅÍÑ ÚÁÇÒÕÚËÉ ÂÙÌÁ ÏÂÎÁÒÕÖÅÎÁ ÓÉÓÔÅÍÁ ACPI, ÔÏ &os; ÐÏ×ÓÅÍÅÓÔÎÏ ÉÓÐÏÌØÚÕÅÔ Å£ ÄÌÑ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ ÏÂÏÒÕÄÏ×ÁÎÉÑ. ë ÓÏÖÁÌÅÎÉÀ, ÄÏ ÓÉÈ ÐÏÒ ÓÕÝÅÓÔ×ÕÀÔ ÎÅÐÏÌÁÄËÉ ËÁË × ÄÒÁÊ×ÅÒÅ ACPI, ÔÁË É ÓÒÅÄÉ ÍÁÔÅÒÉÎÓËÉÈ ÐÌÁÔ É ÉÈ BIOS. ACPI ÍÏÖÅÔ ÂÙÔØ ÏÔËÌÀÞÅÎÁ ÐÕÔ£Í ÕÓÔÁÎÏ×ËÉ ÚÎÁÞÅÎÉÑ ÐÅÒÅÍÅÎÎÏÊ hint.acpi.0.disabled ÎÁ ÔÒÅÔØÅÍ ÜÔÁÐÅ ÚÁÇÒÕÚËÉ: set hint.acpi.0.disabled="1" üÔÏ ÚÎÁÞÅÎÉÅ ÓÂÒÁÓÙ×ÁÅÔÓÑ ËÁÖÄÙÊ ÒÁÚ ÐÒÉ ÚÁÇÒÕÚËÅ ÓÉÓÔÅÍÙ, ÐÏÜÔÏÍÕ ÓÔÒÏËÕ hint.acpi.0.disabled="1" ÎÅÏÂÈÏÄÉÍÏ ÄÏÂÁ×ÉÔØ × ÆÁÊÌ /boot/loader.conf. éÎÆÏÒÍÁÃÉÑ Ï ÚÁÇÒÕÚÞÉËÅ ÐÒÉ×ÅÄÅÎÁ × . éÓÐÏÌØÚÏ×ÁÎÉÅ Live CD &os; Live CD ÎÁÈÏÄÉÔÓÑ ÎÁ ÔÏÍ ÖÅ CD ÄÉÓËÅ, ÞÔÏ É ÕÓÔÁÎÏ×ÏÞÎÁÑ ÐÒÏÇÒÁÍÍÁ. üÔÏ ÕÄÏÂÎÏ ÄÌÑ ÔÅÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ, ËÏÔÏÒÙÅ ×Ó£ ÅÝÅ ÒÁÚÍÙÛÌÑÀÔ Ï ÐÒÉÇÏÄÎÏÓÔÉ ÄÌÑ ÎÉÈ ïó &os; É ÖÅÌÁÀÔ ÐÒÏ×ÅÒÉÔØ ÎÅËÏÔÏÒÙÅ ÆÕÎËÃÉÏÎÁÌØÎÙÅ ×ÏÚÍÏÖÎÏÓÔÉ ÄÏ ÎÁÞÁÌÁ ÕÓÔÁÎÏ×ËÉ. ðÒÉ ÒÁÂÏÔÅ Ó Live CD ÓÌÅÄÕÅÔ ÕÞÅÓÔØ ÓÌÅÄÕÀÝÅÅ: äÌÑ ÐÏÌÕÞÅÎÉÑ ÄÏÓÔÕÐÁ Ë ÓÉÓÔÅÍÅ ÎÅÏÂÈÏÄÉÍÏ ÏÓÕÝÅÓÔ×ÉÔØ ÁÕÔÅÎÔÉÆÉËÁÃÉÀ. äÏÐÕÓÔÉÍÏÅ ÉÍÑ ÐÏÌØÚÏ×ÁÔÅÌÑ — root, ÐÁÒÏÌØ — ÐÕÓÔÏÊ. ôÁË ËÁË ÓÉÓÔÅÍÁ ÒÁÂÏÔÁÅÔ ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏ Ó CD, ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔØ ÂÕÄÅÔ ÚÁÍÅÔÎÏ ÎÉÖÅ ÞÅÍ Õ ÓÉÓÔÅÍÙ, ÕÓÔÁÎÏ×ÌÅÎÎÏÊ ÎÁ ÖÅÓÔËÉÊ ÄÉÓË. Live CD ÐÒÅÄÏÓÔÁ×ÌÑÅÔ × ÒÁÓÐÏÒÑÖÅÎÉÅ ËÏÍÁÎÄÎÕÀ ÓÔÒÏËÕ, Á ÎÅ ÇÒÁÆÉÞÅÓËÉÊ ÉÎÔÅÒÆÅÊÓ.
diff --git a/ru_RU.KOI8-R/books/handbook/install/chapter.xml b/ru_RU.KOI8-R/books/handbook/install/chapter.xml index c408bf8250..af51f5ab70 100644 --- a/ru_RU.KOI8-R/books/handbook/install/chapter.xml +++ b/ru_RU.KOI8-R/books/handbook/install/chapter.xml @@ -1,4955 +1,4945 @@ Jim Mock òÅÓÔÒÕËÔÕÒÉÒÏ×ÁÌ, ÉÓÐÒÁ×ÉÌ É ÞÁÓÔÉÞÎÏ ÐÅÒÅÐÉÓÁÌ Randy Pratt ïÂÚÏÒ sysinstall, ÓËÒÉÎÛÏÔÙ É ÏÂÝÅÅ ÒÕËÏ×ÏÄÓÔ×Ï äÅÎÉÓ ðÅÐÌÉÎ ðÅÒÅ×ÏÄ ÎÁ ÒÕÓÓËÉÊ ÑÚÙË: õÓÔÁÎÏ×ËÁ &os; ×ÅÒÓÉÊ 8.<replaceable>X</replaceable> É ÂÏÌÅÅ ÒÁÎÎÉÈ ëÒÁÔËÉÊ ÏÂÚÏÒ ÕÓÔÁÎÏ×ËÁ FreeBSD ÐÏÓÔÁ×ÌÑÅÔÓÑ ÐÒÏÓÔÏÊ × ÉÓÐÏÌØÚÏ×ÁÎÉÉ ÔÅËÓÔÏ×ÏÊ ÐÒÏÇÒÁÍÍÏÊ ÕÓÔÁÎÏ×ËÉ. &os; 9.0-RELEASE É ÂÏÌÅÅ ÐÏÚÄÎÉÅ ÕËÏÍÐÌÅËÔÏ×ÁÎÙ ÕÓÔÁÎÏ×ÝÉËÏÍ, ÎÁÚÙ×ÁÅÍÙÍ bsdinstall, × ÔÏ ×ÒÅÍÑ ËÁË × ÒÅÌÉÚÁÈ, ÐÒÅÄÛÅÓÔ×ÕÀÝÉÈ 9.0-RELEASE, ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÐÒÉÍÅÎÑÅÔÓÑ sysinstall. ÷ ÜÔÏÊ ÇÌÁ×Å ÏÐÉÓÙ×ÁÅÔÓÑ ÉÓÐÏÌØÚÏ×ÁÎÉÅ sysinstall ÄÌÑ ÕÓÔÁÎÏ×ËÉ FreeBSD. òÁÂÏÔÁ Ó ÕÓÔÁÎÏ×ÝÉËÏÍ bsdinstall ÏÐÉÓÁÎÁ × . ðÒÏÞÔÑ ÜÔÕ ÇÌÁ×Õ, ×Ù ÕÚÎÁÅÔÅ: ëÁË ÓÏÚÄÁÔØ ÄÉÓËÅÔÙ ÄÌÑ ÕÓÔÁÎÏ×ËÉ FreeBSD. ëÁË FreeBSD ×ÉÄÉÔ É ÄÅÌÉÔ ÎÁ ÒÁÚÄÅÌÙ ÖÅÓÔËÉÅ ÄÉÓËÉ. ëÁË ÚÁÐÕÓÔÉÔØ sysinstall. ÷ÏÐÒÏÓÙ, ËÏÔÏÒÙÅ sysinstall ÚÁÄÁÓÔ ×ÁÍ, ÞÔÏ ÉÍÅÅÔÓÑ ××ÉÄÕ, É ËÁË ÏÔ×ÅÔÉÔØ ÎÁ ÜÔÉ ×ÏÐÒÏÓÙ. ðÅÒÅÄ ÐÒÏÞÔÅÎÉÅÍ ÜÔÏÊ ÇÌÁ×Ù ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ: ðÒÏÞÉÔÁÔØ ÉÎÆÏÒÍÁÃÉÀ Ï ÐÏÄÄÅÒÖÉ×ÁÅÍÏÍ ÏÂÏÒÕÄÏ×ÁÎÉÉ, ÐÏÓÔÁ×ÌÑÅÍÕÀ Ó ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÏÊ ×ÅÒÓÉÅÊ FreeBSD, É ÕÂÅÄÉÔØÓÑ, ÞÔÏ ×ÁÛÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ. ëÁË ÐÒÁ×ÉÌÏ, ÜÔÉ ÉÎÓÔÒÕËÃÉÉ ÐÏ ÕÓÔÁÎÏ×ËÅ ÎÁÐÉÓÁÎÙ ÄÌÑ &i386; (PC ÓÏ×ÍÅÓÔÉÍÙÈ) ËÏÍÐØÀÔÅÒÏ×. ëÏÇÄÁ ÜÔÏ ×ÏÚÍÏÖÎÏ, ÐÒÉ×ÏÄÑÔÓÑ ÉÎÓÔÒÕËÃÉÉ, ÓÐÅÃÉÆÉÞÎÙÅ ÄÌÑ ÄÒÕÇÉÈ ÐÌÁÔÆÏÒÍ. èÏÔÑ ÜÔÏ ÒÕËÏ×ÏÄÓÔ×Ï ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ × ÁËÔÕÁÌØÎÏÍ ÓÏÓÔÏÑÎÉÉ ÎÁÓÔÏÌØËÏ, ÎÁÓËÏÌØËÏ ÜÔÏ ×ÏÚÍÏÖÎÏ, ×Ù ÍÏÖÅÔÅ ÏÂÎÁÒÕÖÉÔØ ÎÅÂÏÌØÛÉÅ ÒÁÚÌÉÞÉÑ ÍÅÖÄÕ ÐÒÏÇÒÁÍÍÏÊ ÕÓÔÁÎÏ×ËÉ É ÔÅÍ, ÞÔÏ ÐÏËÁÚÁÎÏ ÚÄÅÓØ. ðÒÅÄÐÏÌÁÇÁÅÔÓÑ, ÞÔÏ ×Ù ÂÕÄÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÜÔÕ ÇÌÁ×Õ × ËÁÞÅÓÔ×Å ÏÂÝÅÇÏ ÒÕËÏ×ÏÄÓÔ×Á, Á ÎÅ ËÁË ÐÏÛÁÇÏ×ÕÀ ÉÎÓÔÒÕËÃÉÀ ÐÏ ÕÓÔÁÎÏ×ËÅ. áÐÐÁÒÁÔÎÙÅ ÔÒÅÂÏ×ÁÎÉÑ íÉÎÉÍÁÌØÎÁÑ ËÏÎÆÉÇÕÒÁÃÉÑ íÉÎÉÍÁÌØÎÁÑ ËÏÎÆÉÇÕÒÁÃÉÑ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os; ÚÁ×ÉÓÉÔ ÏÔ ×ÅÒÓÉÉ &os; É ÁÐÐÁÒÁÔÎÏÊ ÁÒÈÉÔÅËÔÕÒÙ. ëÒÁÔËÏÅ ÉÚÌÏÖÅÎÉÅ ÜÔÏÊ ÉÎÆÏÒÍÁÃÉÉ ÄÁÅÔÓÑ × ÐÏÓÌÅÄÕÀÝÉÈ ÒÁÚÄÅÌÁÈ. ÷ ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÍÅÔÏÄÁ, ×ÙÂÒÁÎÎÏÇÏ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;, ×ÁÍ ÍÏÖÅÔ ÐÏÔÒÅÂÏ×ÁÔØÓÑ ÐÏÄÄÅÒÖÉ×ÁÅÍÙÊ ÄÉÓËÏ×ÏÄ ÉÌÉ ÐÒÉ×ÏÄ CDROM, Á × ÎÅËÏÔÏÒÙÈ ÓÌÕÞÁÑÈ É ÓÅÔÅ×ÏÊ ÁÄÁÐÔÅÒ. üÔÁ ÓÉÔÕÁÃÉÑ ÂÕÄÅÔ ÏÐÉÓÁÎÁ × . áÒÈÉÔÅËÔÕÒÙ &os;/&arch.i386; É &os;/&arch.pc98; äÌÑ ×ÅÒÓÉÊ &os;/&arch.i386; É &os;/&arch.pc98; ÔÒÅÂÕÅÔÓÑ 486 ÐÒÏÃÅÓÓÏÒ ÉÌÉ ×ÙÛÅ, Á ÔÁËÖÅ ËÁË ÍÉÎÉÍÕÍ 24 MB ÐÁÍÑÔÉ. ÷ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ËÁË ÍÉÎÉÍÕÍ 150 MB Ó×ÏÂÏÄÎÏÇÏ ÍÅÓÔÁ ÎÁ ÄÉÓËÅ ÄÌÑ ÓÁÍÏÊ ÍÉÎÉÍÁÌØÎÏÊ ÕÓÔÁÎÏ×ËÉ. äÌÑ ÓÔÁÒÙÈ ËÏÎÆÉÇÕÒÁÃÉÊ, ËÁË ÐÒÁ×ÉÌÏ, ÂÏÌØÛÉÊ ÏÂßÅÍ ÐÁÍÑÔÉ É ÂÏÌØÛÉÊ ÏÂßÅÍ ÄÉÓËÁ ÂÏÌÅÅ ×ÁÖÅÎ, ÞÅÍ ÂÏÌÅÅ ÂÙÓÔÒÙÊ ÐÒÏÃÅÓÓÏÒ. &os;/&arch.amd64; óÕÝÅÓÔ×ÕÅÔ Ä×Á ËÌÁÓÓÁ ÐÒÏÃÅÓÓÏÒÏ×, ÎÁ ËÏÔÏÒÙÈ ÍÏÖÅÔ ÒÁÂÏÔÁÔØ &os;/&arch.amd64;. ë ÐÅÒ×ÏÍÕ ÐÒÉÎÁÄÌÅÖÁÔ ÐÒÏÃÅÓÓÏÒÙ AMD64, ×ËÌÀÞÁÑ &amd.athlon;64, &amd.athlon;64-FX, &amd.opteron; É ÂÏÌÅÅ ÎÏ×ÙÅ. ëÏ ×ÔÏÒÏÍÕ ËÌÁÓÓÕ ÐÒÉÎÁÄÌÅÖÁÔ ÐÒÏÃÅÓÓÏÒÙ ÁÒÈÉÔÅËÔÕÒÙ &intel; EM64T. óÒÅÄÉ ÎÉÈ ÍÏÖÎÏ ÎÁÚ×ÁÔØ ÓÅÍÅÊÓÔ×Á &intel; &core; 2 Duo, Quad, Extreme, Á ÔÁËÖÅ &intel; &xeon; 3000, 5000 É 7000 ÓÅÒÉÉ. åÓÌÉ ×ÁÛÁ ÓÉÓÔÅÍÁ ÏÓÎÏ×ÁÎÁ ÎÁ nVidia nForce3 Pro-150, ÎÅÏÂÈÏÄÉÍÏ ÏÔËÌÀÞÉÔØ IO APIC × BIOS. åÓÌÉ ÄÌÑ ÜÔÏÇÏ ÎÅÔ ÎÅÏÂÈÏÄÉÍÏÊ ÏÐÃÉÉ, ÏÔËÌÀÞÉÔÅ ACPI × ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÅ. ÷ ÞÉÐÓÅÔÅ Pro-150 ÓÏÄÅÒÖÁÔÓÑ ÏÛÉÂËÉ, ÄÌÑ ËÏÔÏÒÙÈ ÐÏËÁ ÎÅ ÓÕÝÅÓÔ×ÕÅÔ ÉÓÐÒÁ×ÌÅÎÉÊ. &os;/&arch.sparc64; äÌÑ ÕÓÔÁÎÏ×ËÉ &os;/&arch.sparc64;, ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÐÏÄÄÅÒÖÉ×ÁÅÍÁÑ ÐÌÁÔÆÏÒÍÁ (ÏÂÒÁÔÉÔÅÓØ Ë ). äÌÑ &os;/&arch.sparc64; ÐÏÔÒÅÂÕÅÔÓÑ ÏÔÄÅÌØÎÙÊ ÄÉÓË. ÷ ÎÁÓÔÏÑÝÅÅ ×ÒÅÍÑ ÄÉÓË ÎÅ×ÏÚÍÏÖÎÏ ÓÏ×ÍÅÓÔÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ Ó ÄÒÕÇÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ. ðÏÄÄÅÒÖÉ×ÁÅÍÏÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ óÐÉÓÏË ÐÏÄÄÅÒÖÉ×ÁÅÍÏÇÏ ÏÂÏÒÕÄÏ×ÁÎÉÑ ÐÏÓÔÁ×ÌÑÅÔÓÑ Ó ËÁÖÄÙÍ ÒÅÌÉÚÏÍ × &os; × ÉÎÆÏÒÍÁÃÉÉ Ï ÒÅÌÉÚÅ. üÔÏÔ ÄÏËÕÍÅÎÔ ÏÂÙÞÎÏ ÎÁÈÏÄÉÔÓÑ × ÆÁÊÌÅ HARDWARE.TXT, × ËÏÒÎÅ×ÏÍ ËÁÔÁÌÏÇÅ CDROM ÉÌÉ FTP ÄÉÓÔÒÉÂÕÔÉ×Á, ÉÌÉ ÍÅÎÀ ÄÏËÕÍÅÎÔÁÃÉÉ sysinstall. äÌÑ ÄÁÎÎÏÊ ÁÒÈÉÔÅËÔÕÒÙ × ÎÅÍ ÐÅÒÅÞÉÓÌÅÎÙ ÁÐÐÁÒÁÔÎÙÅ ÕÓÔÒÏÊÓÔ×Á, ÐÏÄÄÅÒÖÉ×ÁÅÍÙÅ ÄÁÎÎÙÍ ÒÅÌÉÚÏÍ &os;. ëÏÐÉÉ ÓÐÉÓËÏ× ÐÏÄÄÅÒÖÉ×ÁÅÍÏÇÏ ÏÂÏÒÕÄÏ×ÁÎÉÑ ÄÌÑ ÒÁÚÌÉÞÎÙÈ ÒÅÌÉÚÏ× É ÁÒÈÉÔÅËÔÕÒ ÔÁËÖÅ ÍÏÖÎÏ ÐÒÏÓÍÏÔÒÅÔØ ÎÁ ÓÔÒÁÎÉÃÅ éÎÆÏÒÍÁÃÉÉ Ï ÒÅÌÉÚÅ ×Å ÓÁÊÔÁ &os;. ðÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ óÏÂÅÒÉÔÅ ÉÎÆÏÒÍÁÃÉÀ Ï ËÏÍÐØÀÔÅÒÅ ðÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ &os; ÐÏÐÙÔÁÊÔÅÓØ ÓÏÂÒÁÔØ ÉÎÆÏÒÍÁÃÉÀ Ï ÕÓÔÒÏÊÓÔ×ÁÈ ËÏÍÐØÀÔÅÒÁ. ÷Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ &os; ÐÏËÁÖÅÔ ÉÎÆÏÒÍÁÃÉÀ Ï ÕÓÔÒÏÊÓÔ×ÁÈ (ÖÅÓÔËÉÈ ÄÉÓËÁÈ, ÓÅÔÅ×ÙÈ ËÁÒÔÁÈ, CDROM É Ô.Ä.) Ó ÎÏÍÅÒÏÍ ÍÏÄÅÌÉ É ÐÒÏÉÚ×ÏÄÉÔÅÌÅÍ. &os; ÔÁËÖÅ ÐÏÐÙÔÁÅÔÓÑ ÏÐÒÅÄÅÌÉÔØ ÐÒÁ×ÉÌØÎÕÀ ËÏÎÆÉÇÕÒÁÃÉÀ ÄÌÑ ÜÔÉÈ ÕÓÔÒÏÊÓÔ×, ×ËÌÀÞÁÑ ÉÎÆÏÒÍÁÃÉÀ Ï IRQ É ÐÏÒÔÁÈ ××ÏÄÁ-×Ù×ÏÄÁ. éÚ-ÚÁ ×ÏÚÍÏÖÎÙÈ ÐÒÏÂÌÅÍ Ó ÏÂÏÒÕÄÏ×ÁÎÉÅÍ ÜÔÏÔ ÐÒÏÃÅÓÓ ÎÅ ×ÓÅÇÄÁ ÚÁ×ÅÒÛÁÅÔÓÑ ÕÓÐÅÛÎÏ, É ×ÏÚÍÏÖÎÏ ×ÁÍ ÐÒÉÄÅÔÓÑ ÉÓÐÒÁ×ÌÑÔØ ÏÐÒÅÄÅÌÅÎÎÕÀ &os; ËÏÎÆÉÇÕÒÁÃÉÀ. åÓÌÉ Õ ×ÁÓ ÕÖÅ ÅÓÔØ ÕÓÔÁÎÏ×ÌÅÎÎÁÑ ÏÐÅÒÁÃÉÏÎÎÁÑ ÓÉÓÔÅÍÁ, ÎÁÐÒÉÍÅÒ &windows; ÉÌÉ Linux, ÎÅÐÌÏÈÏ ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÔØ ÅÅ ×ÏÚÍÏÖÎÏÓÔÉ ÄÌÑ ÐÒÏÓÍÏÔÒÁ ÎÁÓÔÒÏÅË ÏÂÏÒÕÄÏ×ÁÎÉÑ. åÓÌÉ ×Ù ÎÅ Õ×ÅÒÅÎÙ, ËÁËÉÅ ÎÁÓÔÒÏÊËÉ ËÁÒÔÙ ÒÁÓÛÉÒÅÎÉÑ ÉÓÐÏÌØÚÏ×ÁÔØ, ÍÏÖÅÔÅ ÎÁÊÔÉ ÉÈ ÎÁ ÓÁÍÏÊ ËÁÒÔÅ. þÁÓÔÏ ÉÓÐÏÌØÚÕÅÍÙÅ ÎÏÍÅÒÁ ÐÒÅÒÙ×ÁÎÉÊ 3, 5 É 7, ÐÏÒÔÙ ××ÏÄÁ- ×Ù×ÏÄÁ ÏÂÙÞÎÏ ÐÉÛÕÔÓÑ × ÛÅÓÔÎÁÄÃÁÔÅÒÉÞÎÏÍ ×ÉÄÅ, ÎÁÐÒÉÍÅÒ 0x330. íÙ ÒÅËÏÍÅÎÄÕÅÍ ÒÁÓÐÅÞÁÔÁÔØ ÜÔÕ ÉÎÆÏÒÍÁÃÉÀ ÐÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ &os;. ÷ÁÍ ÍÏÖÅÔ ÐÏÍÏÞØ ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÔÁÂÌÉÃÙ ×ÒÏÄÅ ÜÔÏÊ: ðÒÉÍÅÒ Ó×ÅÄÅÎÉÊ Ï ÏÂÏÒÕÄÏ×ÁÎÉÉ îÁÚ×ÁÎÉÅ ÕÓÔÒÏÊÓÔ×Á IRQ ðÏÒÔ ××ÏÄÁ-×Ù×ÏÄÁ ðÒÉÍÅÞÁÎÉÑ ðÅÒ×ÙÊ ÖÅÓÔËÉÊ ÄÉÓË ÎÅÔ ÎÅÔ 40 GB, Seagate, ÐÅÒ×ÙÊ IDE master CDROM ÎÅÔ ÎÅÔ ðÅÒ×ÙÊ IDE slave ÷ÔÏÒÏÊ ÖÅÓÔËÉÊ ÄÉÓË ÎÅÔ ÎÅÔ 20 GB, IBM, ×ÔÏÒÏÊ IDE master ðÅÒ×ÙÊ IDE ËÏÎÔÒÏÌÌÅÒ 14 0x1f0 óÅÔÅ×ÁÑ ËÁÒÔÁ ÎÅÔ ÎÅÔ &intel; 10/100 íÏÄÅÍ ÎÅÔ ÎÅÔ &tm.3com; 56K ÆÁËÓ-ÍÏÄÅÍ, COM1
ðÏÓÌÅ ÓÂÏÒÁ ÉÎÆÏÒÍÁÃÉÉ Ï ËÏÍÐÏÎÅÎÔÁÈ ËÏÍÐØÀÔÅÒÁ, ×Ù ÍÏÖÅÔÅ ÐÒÏ×ÅÒÉÔØ ÉÈ ÓÏÏÔ×ÅÔÓÔ×ÉÅ ÁÐÐÁÒÁÔÎÙÍ ÔÒÅÂÏ×ÁÎÉÑÍ ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÏÇÏ ÒÅÌÉÚÁ &os;.
óÄÅÌÁÊÔÅ ÒÅÚÅÒ×ÎÏÅ ËÏÐÉÒÏ×ÁÎÉÅ ÄÁÎÎÙÈ åÓÌÉ ËÏÍÐØÀÔÅÒ, ÎÁ ËÏÔÏÒÙÊ ×Ù ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÅ &os;, ÓÏÄÅÒÖÉÔ ×ÁÖÎÙÅ ÄÁÎÎÙÅ, ÕÂÅÄÉÔÅÓØ × ÎÁÌÉÞÉÉ ÒÅÚÅÒ×ÎÙÈ ËÏÐÉÊ É ÐÒÏ×ÅÒØÔÅ ÉÈ ÓÏÈÒÁÎÎÏÓÔØ ÐÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ. ÷Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ &os; ÚÁÐÒÏÓÉÔ ÐÏÄÔ×ÅÒÖÄÅÎÉÅ ÐÅÒÅÄ ÔÅÍ, ËÁË ÚÁÐÉÓÁÔØ ÄÁÎÎÙÅ ÎÁ ÄÉÓË, ÎÏ, ÅÓÌÉ ÐÒÏÃÅÓÓ ÚÁÐÕÝÅÎ, ÉÚÍÅÎÅÎÉÑ ÎÅÌØÚÑ ÏÔÍÅÎÉÔØ. òÅÛÉÔÅ ËÕÄÁ ÕÓÔÁÎÏ×ÉÔØ &os; åÓÌÉ ×Ù ÈÏÔÉÔÅ, ÞÔÏÂÙ &os; ÉÓÐÏÌØÚÏ×ÁÌÁ ×ÅÓØ ÖÅÓÔËÉÊ ÄÉÓË, ÎÅ Ï ÞÅÍ ÂÅÓÐÏËÏÉÔØÓÑ — ÍÏÖÅÔÅ ÐÒÏÐÕÓÔÉÔØ ÜÔÏÔ ÒÁÚÄÅÌ. ïÄÎÁËÏ, ÅÓÌÉ ÎÕÖÎÏ ÓÏ×ÍÅÝÁÔØ &os; Ó ÄÒÕÇÉÍÉ ÏÐÅÒÁÃÉÏÎÎÙÍÉ ÓÉÓÔÅÍÁÍÉ, ÎÅÏÂÈÏÄÉÍÏ ÉÍÅÔØ ÐÒÅÄÓÔÁ×ÌÅÎÉÅ ËÁË ÄÁÎÎÙÅ ÒÁÚÍÅÝÁÀÔÓÑ ÎÁ ÄÉÓËÅ É ËÁË ÜÔÏ ËÁÓÁÅÔÓÑ ×ÁÓ. òÁÚÄÅÌÙ ÄÉÓËÁ ÄÌÑ &os;/&arch.i386; äÉÓË ðë ÍÏÖÅÔ ÂÙÔØ ÐÏÄÅÌÅÎ ÎÁ ÏÔÄÅÌØÎÙÅ ÞÁÓÔÉ. üÔÉ ÞÁÓÔÉ ÎÁÚÙ×ÁÀÔ ÒÁÚÄÅÌÁÍÉ. ðÏÓËÏÌØËÕ × &os; ÔÁËÖÅ ÅÓÔØ ÒÁÚÄÅÌÙ, ÔÅÒÍÉÎÏÌÏÇÉÑ ÓÔÁÎÏ×ÉÔÓÑ ÚÁÐÕÔÁÎÎÏÊ, É ÐÏÜÔÏÍÕ ÜÔÉ ÞÁÓÔÉ ÄÉÓËÏ× ÎÁÚÙ×ÁÀÔÓÑ ÄÉÓËÏ×ÙÍÉ ÓÌÁÊÓÁÍÉ, ÉÌÉ ÐÒÏÓÔÏ ÓÌÁÊÓÁÍÉ × &os;. îÁÐÒÉÍÅÒ, ÕÔÉÌÉÔÁ &os; fdisk, ÉÍÅÀÝÁÑ ÄÅÌÏ Ó ÄÉÓËÏ×ÙÍÉ ÒÁÚÄÅÌÁÍÉ PC, ÏÂÒÁÝÁÅÔÓÑ ÓÏ ÓÌÁÊÓÁÍÉ Á ÎÅ Ó ÒÁÚÄÅÌÁÍÉ. ðÅÒ×ÏÎÁÞÁÌØÎÏ PC ÐÏÄÄÅÒÖÉ×ÁÌ ÔÏÌØËÏ ÞÅÔÙÒÅ ÒÁÚÄÅÌÁ ÎÁ ÄÉÓË. üÔÉ ÒÁÚÄÅÌÙ ÎÁÚÙ×ÁÀÔÓÑ ÇÌÁ×ÎÙÍÉ ÒÁÚÄÅÌÁÍÉ. þÔÏÂÙ ÏÂÏÊÔÉ ÜÔÏ ÏÇÒÁÎÉÞÅÎÉÅ É ÄÁÔØ ×ÏÚÍÏÖÎÏÓÔØ ÓÏÚÄÁ×ÁÔØ ÂÏÌÅÅ ÞÅÍ ÞÅÔÙÒÅ ÒÁÚÄÅÌÁ, ÂÙÌ ÓÏÚÄÁÎ ÎÏ×ÙÊ ÔÉÐ ÒÁÚÄÅÌÁ, ÒÁÓÛÉÒÅÎÎÙÊ ÒÁÚÄÅÌ. äÉÓË ÍÏÖÅÔ ÓÏÄÅÒÖÁÔØ ÔÏÌØËÏ ÏÄÉÎ ÒÁÓÛÉÒÅÎÎÙÊ ÒÁÚÄÅÌ. óÐÅÃÉÁÌØÎÙÅ ÒÁÚÄÅÌÙ, ÎÁÚÙ×ÁÅÍÙÅ ÌÏÇÉÞÅÓËÉÍÉ ÒÁÚÄÅÌÁÍÉ, ÍÏÇÕÔ ÂÙÔØ ÓÏÚÄÁÎÙ ×ÎÕÔÒÉ ÒÁÓÛÉÒÅÎÎÏÇÏ ÒÁÚÄÅÌÁ. ëÁÖÄÙÊ ÒÁÚÄÅÌ ÉÍÅÅÔ ID ÒÁÚÄÅÌÁ — ÎÏÍÅÒ, ËÏÔÏÒÙÊ ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÏÐÒÅÄÅÌÅÎÉÑ ÔÉÐÁ ÄÁÎÎÙÈ ÎÁ ÒÁÚÄÅÌÅ. &os; ÉÓÐÏÌØÚÕÅÔ ID ÒÁÚÄÅÌÁ 165. ëÁË ÐÒÁ×ÉÌÏ, ËÁÖÄÁÑ ÏÐÅÒÁÃÉÏÎÎÁÑ ÓÉÓÔÅÍÁ, ËÏÔÏÒÕÀ ×Ù ÉÓÐÏÌØÚÕÅÔÅ, ÏÐÒÅÄÅÌÑÅÔ ÒÁÚÄÅÌÙ Ó×ÏÉÍ ÓÐÏÓÏÂÏÍ. îÁÐÒÉÍÅÒ, &ms-dos; É ÅÅ ÐÏÔÏÍËÉ, ÔÁËÉÅ ËÁË &windows;, ÐÒÉÓ×ÁÉ×ÁÀÔ ËÁÖÄÏÍÕ ÇÌÁ×ÎÏÍÕ É ÌÏÇÉÞÅÓËÏÍÕ ÒÁÚÄÅÌÕ ÂÕË×Õ ÄÉÓËÁ, ÎÁÞÉÎÁÑ Ó C:. &os; ÎÕÖÎÏ ÕÓÔÁÎÁ×ÌÉ×ÁÔØ × ÇÌÁ×ÎÙÊ ÒÁÚÄÅÌ. &os; ÍÏÖÅÔ ÈÒÁÎÉÔØ ×ÓÅ Ó×ÏÉ ÄÁÎÎÙÅ, ×ËÌÀÞÁÑ ÓÏÚÄÁ×ÁÅÍÙÅ ×ÁÍÉ ÆÁÊÌÙ, ÎÁ ÜÔÏÍ ÏÄÎÏÍ ÒÁÚÄÅÌÅ. ôÅÍ ÎÅ ÍÅÎÅÅ, ÅÓÌÉ ÄÉÓËÏ× ÍÎÏÇÏ, ×Ù ÍÏÖÅÔÅ ÓÏÚÄÁÔØ ÒÁÚÄÅÌÙ &os; ÎÁ ×ÓÅÈ ÄÉÓËÁÈ ÉÌÉ ÎÁ ÎÅËÏÔÏÒÙÈ ÉÚ ÎÉÈ. ðÒÉ ÕÓÔÁÎÏ×ËÅ &os; ÄÏÌÖÅÎ ÂÙÔØ ÄÏÓÔÕÐÅÎ ÐÏ ËÒÁÊÎÅÊ ÍÅÒÅ ÏÄÉÎ ÒÁÚÄÅÌ. üÔÏ ÍÏÖÅÔ ÂÙÔØ ÞÉÓÔÙÊ, ÐÏÄÇÏÔÏ×ÌÅÎÎÙÊ ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÒÁÚÄÅÌ, ÉÌÉ ÒÁÚÄÅÌ Ó ÄÁÎÎÙÍÉ, ËÏÔÏÒÙÅ ÂÏÌØÛÅ ÎÅ ÎÕÖÎÙ. åÓÌÉ ×ÓÅ ÒÁÚÄÅÌÙ ÎÁ ÄÉÓËÅ ÕÖÅ ÉÓÐÏÌØÚÕÀÔÓÑ, ×Ù ÄÏÌÖÎÙ ÏÓ×ÏÂÏÄÉÔØ ÏÄÉÎ ÉÚ ÎÉÈ ÄÌÑ &os;, ÉÓÐÏÌØÚÕÑ ÐÒÏÇÒÁÍÍÙ, ÐÏÓÔÁ×ÌÑÅÍÙÅ Ó ÉÍÅÀÝÅÊÓÑ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ (ÎÁÐÒÉÍÅÒ, fdisk ÄÌÑ &ms-dos; ÉÌÉ &windows;). åÓÌÉ ÅÓÔØ ÒÅÚÅÒ×ÎÙÊ ÒÁÚÄÅÌ, ÉÓÐÏÌØÚÕÊÔÅ ÅÇÏ. ïÄÎÁËÏ, ×ÏÚÍÏÖÎÏ ÓÎÁÞÁÌÁ ÐÒÉÄÅÔÓÑ ÕÖÁÔØ ÏÄÉÎ ÉÌÉ ÎÅÓËÏÌØËÏ ÓÕÝÅÓÔ×ÕÀÝÉÈ ÒÁÚÄÅÌÏ×. &os; ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÎÕÖÅÎ ÄÉÓË ÎÅ ÍÅÎÅÅ 100 MB. ïÄÎÁËÏ, ÜÔÏ ÏÞÅÎØÍÉÎÉÍÁÌØÎÁÑ ÕÓÔÁÎÏ×ËÁ, ÐÒÉ ËÏÔÏÒÏÊ ÎÅ ÏÓÔÁÎÅÔÓÑ ÍÅÓÔÁ ÄÌÑ ×ÁÛÉÈ ÌÉÞÎÙÈ ÆÁÊÌÏ×. âÏÌÅÅ ÒÅÁÌØÎÙÊ ÏÂßÅÍ — 250 MB ÂÅÚ ÇÒÁÆÉÞÅÓËÏÊ ÏÂÏÌÏÞËÉ, É ÂÏÌÅÅ 350 MB Ó ÇÒÁÆÉÞÅÓËÏÊ ÏÂÏÌÏÞËÏÊ. åÓÌÉ ×Ù ÓÏÂÉÒÁÅÔÅÓØ ÕÓÔÁÎÁ×ÌÉ×ÁÔØ ÂÏÌØÛÏÅ ËÏÌÉÞÅÓÔ×Ï ÄÏÐÏÌÎÉÔÅÌØÎÏÇÏ ðï, ÐÏÎÁÄÏÂÉÔÓÑ ÅÝÅ ÂÏÌØÛÅ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á. - ÷Ù ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ËÏÍÍÅÒÞÅÓËÉÅ ÐÒÏÇÒÁÍÍÙ, - ÔÁËÉÅ ËÁË &partitionmagic;, - ÉÌÉ Ó×ÏÂÏÄÎÏ ÒÁÓÐÒÏÓÔÒÁÎÑÅÍÙÅ, ÔÁËÉÅ ËÁË - GParted, ÄÌÑ - ÉÚÍÅÎÅÎÉÑ ÒÁÚÍÅÒÁ ÒÁÚÄÅÌÏ× É ÏÓ×ÏÂÏÖÄÅÎÉÑ ÍÅÓÔÁ ÐÏÄ - &os;. - ëÁË &partitionmagic;, ÔÁË É - GParted ÓÐÏÓÏÂÎÙ ÒÁÂÏÔÁÔØ Ó + äÌÑ ÉÚÍÅÎÅÎÉÑ ÒÁÚÍÅÒÁ ÒÁÚÄÅÌÏ× É ÏÓ×ÏÂÏÖÄÅÎÉÑ ÍÅÓÔÁ ÐÏÄ &os; ×Ù + ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÐÒÏÇÒÁÍÍÕ GParted. + GParted ÓÐÏÓÏÂÎÁ ÒÁÂÏÔÁÔØ Ó ÒÁÚÄÅÌÁÍÉ NTFS. õÔÉÌÉÔÁ GParted ÄÏÓÔÕÐÎÁ ÎÁ ÎÅËÏÔÏÒÙÈ Live CD ÄÉÓÔÒÉÂÕÔÉ×ÁÈ Linux, ÎÁÐÒÉÍÅÒ: SystemRescueCD. ðÏÌØÚÏ×ÁÔÅÌÉ ÎÅÏÄÎÏËÒÁÔÎÏ ÓÔÁÌËÉ×ÁÌÉÓØ Ó ÐÒÏÂÌÅÍÁÍÉ ÐÒÉ ÉÚÍÅÎÅÎÉÉ ÒÁÚÍÅÒÏ× ÒÁÚÄÅÌÏ×, ÓÏÄÅÒÖÁÝÉÈ µsoft; Vista. ðÏÜÔÏÍÕ ÒÅËÏÍÅÎÄÕÅÔÓÑ ÄÅÒÖÁÔØ ÐÏÄ ÒÕËÏÊ ÉÎÓÔÁÌÌÑÃÉÏÎÎÙÊ ÄÉÓË Ó µsoft; Vista ×Ï ×ÒÅÍÑ ×ÙÐÏÌÎÅÎÉÑ ÐÏÄÏÂÎÙÈ ÏÐÅÒÁÃÉÊ. ëÁË É ÐÒÉ ÌÀÂÙÈ ÄÒÕÇÉÈ ÚÁÄÁÞÁÈ ÏÂÓÌÕÖÉ×ÁÎÉÑ ÖÅÓÔËÉÈ ÄÉÓËÏ×, ÎÁÓÔÏÑÔÅÌØÎÏ ÒÅËÏÍÅÎÄÕÅÔÓÑ ÚÁÒÁÎÅÅ ÓÄÅÌÁÔØ ÒÅÚÅÒ×ÎÙÅ ËÏÐÉÉ ÄÁÎÎÙÈ. îÅÐÒÁ×ÉÌØÎÏÅ ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÜÔÉÈ ÕÔÉÌÉÔ ÍÏÖÅÔ ÐÒÉ×ÅÓÔÉ Ë ÕÎÉÞÔÏÖÅÎÉÀ ÄÁÎÎÙÈ ÎÁ ÄÉÓËÅ. õÄÏÓÔÏ×ÅÒØÔÅÓØ × ÎÁÌÉÞÉÉ Ó×ÅÖÉÈ É ÉÓÐÒÁ×ÎÙÈ ÒÅÚÅÒ×ÎÙÈ ËÏÐÉÊ ÄÁÎÎÙÈ ÐÅÒÅÄ ÉÈ ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ. éÓÐÏÌØÚÏ×ÁÎÉÅ ÓÕÝÅÓÔ×ÕÀÝÅÇÏ ÒÁÚÄÅÌÁ ÂÅÚ ÉÚÍÅÎÅÎÉÑ ðÒÅÄÓÔÁרÔÅ ÞÔÏ × ËÏÍÐØÀÔÅÒÅ ÏÄÉÎ 4 GB ÄÉÓË, ÎÁ ËÏÔÏÒÏÍ ÕÖÅ ÕÓÔÁÎÏ×ÌÅÎÁ &windows;, É ÄÉÓË ÒÁÚÂÉÔ ÎÁ Ä×Á ÌÏÇÉÞÅÓËÉÈ ÄÉÓËÁ C: É D:, ËÁÖÄÙÊ ÐÏ 2 GB. 1 GB ÄÁÎÎÙÈ ÎÁ C:, É 0.5 GB ÄÁÎÎÙÈ ÎÁ D:. üÔÏ ÏÚÎÁÞÁÅÔ, ÞÔÏ ÄÉÓË ÓÏÓÔÏÉÔ ÉÚ Ä×ÕÈ ÒÁÚÄÅÌÏ×, ÐÏ ÏÄÎÏÍÕ ÎÁ ËÁÖÄÕÀ ÂÕË×Õ. ÷Ù ÍÏÖÅÔÅ ÓËÏÐÉÒÏ×ÁÔØ ×ÓÅ ÄÁÎÎÙÅ Ó D: ÎÁ C:, ÜÔÏ ÏÓ×ÏÂÏÄÉÔ ×ÔÏÒÏÊ ÒÁÚÄÅÌ ÄÌÑ &os;. óÖÁÔÉÅ ÓÕÝÅÓÔ×ÕÀÝÉÈ ÒÁÚÄÅÌÏ× ðÒÅÄÓÔÁרÔÅ, ÞÔÏ × ËÏÍÐØÀÔÅÒÅ ÏÄÉÎ 4 GB ÄÉÓË, ÎÁ ËÏÔÏÒÏÍ ÕÖÅ ÕÓÔÁÎÏ×ÌÅÎÁ &windows;. ðÒÉ ÕÓÔÁÎÏ×ËÅ &windows; ×Ù ÓÏÚÄÁÌÉ ÏÄÉÎ ÂÏÌØÛÏÊ ÒÁÚÄÅÌ, ÐÏÌÕÞÉ× ÐÒÉ ÜÔÏÍ ÄÉÓË C: ÒÁÚÍÅÒÏÍ 4 GB. ÷Ù ÉÓÐÏÌØÚÕÅÔÅ 1.5 GB, É ÈÏÔÉÔÅ ×ÙÄÅÌÉÔØ 2 GB ÄÌÑ &os;. äÌÑ ÕÓÔÁÎÏ×ËÉ &os; ÎÕÖÎÏ ×ÙÂÒÁÔØ: óÄÅÌÁÔØ ÒÅÚÅÒ×ÎÕÀ ËÏÐÉÀ &windows;, ÚÁÔÅÍ ÐÅÒÅÕÓÔÁÎÏ×ÉÔØ &windows;, ×ÙÄÅÌÉ× 2 GB ÐÏÄ ÅÅ ÒÁÚÄÅÌ. - éÓÐÏÌØÚÏ×ÁÔØ ÏÄÎÕ ÉÚ ÕÔÉÌÉÔ, ÔÁËÉÈ ËÁË - &partitionmagic;, ÏÐÉÓÁÎÎÕÀ - ×ÙÛÅ, ÄÌÑ ÓÖÁÔÉÑ ÒÁÚÄÅÌÁ &windows;. + éÓÐÏÌØÚÏ×ÁÔØ ÄÌÑ ÓÖÁÔÉÑ ÒÁÚÄÅÌÁ &windows; ÏÄÎÕ ÉÚ + ×ÙÛÅÏÐÉÓÁÎÎÙÈ ÕÔÉÌÉÔ. óÏÂÅÒÉÔÅ ÉÎÆÏÒÍÁÃÉÀ Ï ËÏÎÆÉÇÕÒÁÃÉÉ ÓÅÔÉ åÓÌÉ ×Ù ÈÏÔÉÔÅ ÐÏÄËÌÀÞÉÔØÓÑ Ë ÓÅÔÉ × ÐÒÏÃÅÓÓÅ ÕÓÔÁÎÏ×ËÉ &os; (ÎÁÐÒÉÍÅÒ, ÐÒÉ ÕÓÔÁÎÏ×ËÅ Ó FTP ÉÌÉ NFS ÓÅÒ×ÅÒÁ), ÎÕÖÎÏ ÚÎÁÔØ ËÏÎÆÉÇÕÒÁÃÉÀ ÓÅÔÉ. ÷ÁÍ ÂÕÄÅÔ ÐÒÅÄÌÏÖÅÎÏ ××ÅÓÔÉ ÜÔÕ ÉÎÆÏÒÍÁÃÉÀ, ÞÔÏÂÙ &os; ÓÍÏÇÌÁ ÐÏÄËÌÀÞÉÔØÓÑ Ë ÓÅÔÉ ÄÌÑ ÐÒÏÄÏÌÖÅÎÉÑ ÕÓÔÁÎÏ×ËÉ. ðÏÄËÌÀÞÅÎÉÅ Ë ÓÅÔÉ Ethernet, ÉÌÉ ÞÅÒÅÚ ËÁÂÅÌØÎÙÊ/DSL ÍÏÄÅÍ åÓÌÉ ×Ù ÐÏÄËÌÀÞÁÅÔÅÓØ Ë ÓÅÔÉ Ethernet, ÉÌÉ ÓÏÅÄÉÎÅÎÉÅ Ó ÉÎÔÅÒÎÅÔ ÐÏÄËÌÀÞÅÎÏ Ë Ethernet ÞÅÒÅÚ ËÁÂÅÌØÎÙÊ ÉÌÉ DSL ÍÏÄÅÍ, ÐÏÎÁÄÏÂÉÔÓÑ ÓÌÅÄÕÀÝÁÑ ÉÎÆÏÒÍÁÃÉÑ: IP ÁÄÒÅÓ IP ÁÄÒÅÓ ÛÌÀÚÁ ÐÏ ÕÍÏÌÞÁÎÉÀ éÍÑ ÈÏÓÔÁ IP ÁÄÒÅÓ DNS ÓÅÒ×ÅÒÁ íÁÓËÁ ÐÏÄÓÅÔÉ åÓÌÉ Õ ×ÁÓ ÎÅÔ ÜÔÏÊ ÉÎÆÏÒÍÁÃÉÉ, ÓÐÒÏÓÉÔÅ ÓÉÓÔÅÍÎÏÇÏ ÁÄÍÉÎÉÓÔÒÁÔÏÒÁ ÉÌÉ ÐÒÏ×ÁÊÄÅÒÁ ÉÎÔÅÒÎÅÔ. ïÎÉ ÍÏÇÕÔ ÓËÁÚÁÔØ, ÞÔÏ ÄÁÎÎÙÅ ÐÒÉÓ×ÁÉ×ÁÀÔÓÑ Á×ÔÏÍÁÔÉÞÅÓËÉ, Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ DHCP. åÓÌÉ ÜÔÏ ÔÁË, ÚÁÐÏÍÎÉÔÅ ÜÔÏ. ðÏÄÓÏÅÄÉÎÅÎÉÅ Ó ÐÏÍÏÝØÀ ÍÏÄÅÍÁ åÓÌÉ ×Ù ÄÏÚ×ÁÎÉ×ÁÅÔÅÓØ ÄÏ ÐÒÏ×ÁÊÄÅÒÁ Ó ÐÏÍÏÝØÀ ÏÂÙÞÎÏÇÏ ÍÏÄÅÍÁ, ×Ù ×ÓÅ ÖÅ ÓÍÏÖÅÔÅ ÕÓÔÁÎÏ×ÉÔØ &os; ÞÅÒÅÚ ÉÎÔÅÒÎÅÔ, ÎÏ ÜÔÏ ÚÁÊÍÅÔ ÏÞÅÎØ ÍÎÏÇÏ ×ÒÅÍÅÎÉ. ÷ÁÍ ÎÕÖÎÏ ÚÎÁÔØ: îÏÍÅÒ ÔÅÌÅÆÏÎÁ ÐÒÏ×ÁÊÄÅÒÁ COM ÐÏÒÔ, Ë ËÏÔÏÒÏÍÕ ÐÏÄËÌÀÞÅÎ ÍÏÄÅÍ éÍÑ ÐÏÌØÚÏ×ÁÔÅÌÑ É ÐÁÒÏÌØ ÕÞÅÔÎÏÊ ÚÁÐÉÓÉ ÄÌÑ ÄÏÓÔÕÐÁ × ÉÎÔÅÒÎÅÔ ðÒÏ×ÅÒØÔÅ Ó×ÅÄÅÎÉÑ Ï ÏÂÎÁÒÕÖÅÎÎÙÈ ÏÛÉÂËÁÈ &os; èÏÔÑ ÐÒÏÅËÔ &os; ÂÏÒÅÔÓÑ ÚÁ ÔÏ, ÞÔÏÂÙ ËÁÖÄÙÊ ÒÅÌÉÚ &os; ÂÙÌ ÎÁÓÔÏÌØËÏ ÓÔÁÂÉÌØÎÙÍ, ÎÁÓËÏÌØËÏ ÜÔÏ ×ÏÚÍÏÖÎÏ, ÏÛÉÂËÉ ÐÏÒÏÊ ×ËÒÁÄÙ×ÁÀÔÓÑ × ÐÒÏÃÅÓÓ ÒÁÚÒÁÂÏÔËÉ. ÷ ÏÞÅÎØ ÒÅÄËÉÈ ÓÌÕÞÁÑÈ ÜÔÉ ÏÛÉÂËÉ ×ÌÉÑÀÔ ÎÁ ÐÒÏÃÅÓÓ ÕÓÔÁÎÏ×ËÉ. ëÁË ÔÏÌØËÏ ÜÔÉ ÐÒÏÂÌÅÍÙ ÏÂÎÁÒÕÖÉ×ÁÀÔÓÑ É ÉÓÐÒÁ×ÌÑÀÔÓÑ, ÏÎÉ ÐÏÐÁÄÁÀÔ × ÓÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ &os;, ÎÁÈÏÄÑÝÉÅÓÑ ÎÁ ÓÁÊÔÅ &os;. ÷Ù ÍÏÖÅÔÅ ÐÒÏ×ÅÒÉÔØ ÓÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ ÐÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ, ÞÔÏÂÙ ÕÂÅÄÉÔØÓÑ, ÞÔÏ ÎÅ ÓÕÝÅÓÔ×ÕÅÔ ÐÒÏÂÌÅÍ, Ï ËÏÔÏÒÙÈ ÓÔÏÉÔ ÂÅÓÐÏËÏÉÔØÓÑ. éÎÆÏÒÍÁÃÉÑ Ï ÒÅÌÉÚÁÈ, ×ËÌÀÞÁÑ ÓÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ ËÁÖÄÏÇÏ ÒÅÌÉÚÁ, ÎÁÈÏÄÉÔÓÑ ÎÁ ÓÔÒÁÎÉÃÅ ÉÎÆÏÒÍÁÃÉÉ Ï ÒÅÌÉÚÁÈ ÓÁÊÔÁ &os;. ðÏÌÕÞÅÎÉÅ ÕÓÔÁÎÏ×ÏÞÎÙÈ ÆÁÊÌÏ× &os; ðÒÏÇÒÁÍÍÁ ÕÓÔÁÎÏ×ËÉ &os; ÍÏÖÅÔ ÕÓÔÁÎÏ×ÉÔØ &os; ÉÚ ÆÁÊÌÏ×, ÒÁÓÐÏÌÏÖÅÎÎÙÈ × ÏÄÎÏÍ ÉÚ ÓÌÅÄÕÀÝÉÈ ÍÅÓÔ: ìÏËÁÌØÎÙÊ ÄÉÓË CDROM ÉÌÉ DVD USB-ÎÁËÏÐÉÔÅÌØ òÁÚÄÅÌ &ms-dos; ÎÁ ×ÁÛÅÍ ËÏÍÐØÀÔÅÒÅ ìÅÎÔÁ SCSI ÉÌÉ QIC çÉÂËÉÅ ÄÉÓËÉ óÅÔØ FTP ÓÅÒ×ÅÒ (ÞÅÒÅÚ ÆÁÊÒ×ÏÌÌ ÉÌÉ HTTP ÐÒÏËÓÉ, ÅÓÌÉ ÐÏÔÒÅÂÕÅÔÓÑ) NFS ÓÅÒ×ÅÒ óÏÅÄÉÎÅÎÉÅ ÞÅÒÅÚ ÐÁÒÁÌÌÅÌØÎÙÊ ÉÌÉ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÙÊ ÐÏÒÔ åÓÌÉ ×Ù ËÕÐÉÌÉ &os; ÎÁ CD ÉÌÉ DVD, Õ ×ÁÓ ÕÖÅ ÅÓÔØ ×ÓÅ, ÞÔÏ ÎÕÖÎÏ, ÐÅÒÅÈÏÄÉÔÅ Ë ÓÌÅÄÕÀÝÅÍÕ ÒÁÚÄÅÌÕ (). åÓÌÉ Õ ×ÁÓ ÎÅÔ ÕÓÔÁÎÏ×ÏÞÎÙÈ ÆÁÊÌÏ× &os;, ÐÅÒÅÊÄÉÔÅ Ë , ËÏÔÏÒÙÊ ÏÐÉÓÙ×ÁÅÔ, ËÁË ÐÏÄÇÏÔÏ×ÉÔØÓÑ Ë ÕÓÔÁÎÏ×ËÅ &os; ÌÀÂÙÍ ÕËÁÚÁÎÎÙÍ ×ÙÛÅ ÓÐÏÓÏÂÏÍ. ðÏÓÌÅ ÐÒÏÞÔÅÎÉÑ ÜÔÏÇÏ ÒÁÚÄÅÌÁ, ×ÅÒÎÉÔÅÓØ ÓÀÄÁ É ÐÒÏÞÔÉÔÅ . ðÏÄÇÏÔÏ×ËÁ ÚÁÇÒÕÚÏÞÎÙÈ ÄÉÓËÏ× ðÒÏÃÅÓÓ ÕÓÔÁÎÏ×ËÉ &os; ÎÁÞÉÎÁÅÔÓÑ Ó ÚÁÇÒÕÚËÉ × ×ÁÛ ËÏÍÐØÀÔÅÒ ÐÒÏÇÒÁÍÍÙ ÕÓÔÁÎÏ×ËÉ &os; — ÜÔÁ ÐÒÏÇÒÁÍÍÁ ÎÅ ÚÁÐÕÓËÁÅÔÓÑ ÉÚ ÄÒÕÇÉÈ ÏÐÅÒÁÃÉÏÎÎÙÈ ÓÉÓÔÅÍ. ëÏÍÐØÀÔÅÒ ÏÂÙÞÎÏ ÚÁÇÒÕÖÁÅÔ ÏÐÅÒÁÃÉÏÎÎÕÀ ÓÉÓÔÅÍÕ, ÕÓÔÁÎÏ×ÌÅÎÎÕÀ ÎÁ ÖÅÓÔËÏÍ ÄÉÓËÅ, ÎÏ ÔÁËÖÅ ÍÏÖÅÔ ÂÙÔØ ÎÁÓÔÒÏÅÎ ÎÁ ÚÁÇÒÕÚËÕ Ó ÐÒÉ×ÏÄÁ CDROM ÉÌÉ Ó USB-ÎÁËÏÐÉÔÅÌÑ. åÓÌÉ Õ ×ÁÓ ÅÓÔØ &os; ÎÁ CDROM ÉÌÉ DVD (ËÕÐÌÅÎÎÙÊ ÉÌÉ ÚÁÐÉÓÁÎÎÙÊ ÓÁÍÏÓÔÏÑÔÅÌØÎÏ), É ËÏÍÐØÀÔÅÒ ÐÏÚ×ÏÌÑÅÔ ÚÁÇÒÕÚËÕ Ó CDROM ÉÌÉ DVD (ÏÂÙÞÎÏ ÜÔÏÔ ÐÕÎËÔ × BIOS ÎÁÚÙ×ÁÅÔÓÑ Boot Order ÉÌÉ ÞÔÏ-ÔÏ ×ÒÏÄÅ), ÍÏÖÅÔÅ ÐÒÏÐÕÓÔÉÔØ ÜÔÏÔ ÒÁÚÄÅÌ. ïÂÒÁÚÙ &os; CDROM É DVD Ñ×ÌÑÀÔÓÑ ÚÁÇÒÕÚÏÞÎÙÍÉ É ÍÏÇÕÔ ÂÙÔØ ÉÓÐÏÌØÚÏ×ÁÎÙ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os; ÂÅÚ ËÁËÏÊ-ÌÉÂÏ ÓÐÅÃÉÁÌØÎÏÊ ÐÏÄÇÏÔÏ×ËÉ. äÌÑ ÓÏÚÄÁÎÉÑ ÚÁÇÒÕÚÏÞÎÏÇÏ USB-ÄÉÓËÁ ×ÙÐÏÌÎÉÔÅ ÓÌÅÄÕÀÝÉÅ ÛÁÇÉ: ðÏÌÕÞÅÎÉÅ ÏÂÒÁÚÏ× ÄÌÑ USB-ÎÁËÏÐÉÔÅÌÑ úÁÇÒÕÚÏÞÎÙÅ ÏÂÒÁÚÙ ÄÌÑ USB-ÎÁËÏÐÉÔÅÌÑ ÄÌÑ &os; 8.X-RELEASE É ÂÏÌÅÅ ÒÁÎÎÉÈ ÍÏÖÎÏ ÎÁÊÔÉ × ËÁÔÁÌÏÇÅ ISO-IMAGES/ ÐÏ ÁÄÒÅÓÕ ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/arch/ISO-IMAGES/version/&os;-version-RELEASE-arch-memstick.img. úÁÍÅÎÉÔÅ arch É version ÉÍÅÎÅÍ ÁÒÈÉÔÅËÔÕÒÙ É ÎÏÍÅÒÏÍ ×ÅÒÓÉÉ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ, ËÏÔÏÒÕÀ ×Ù ÐÌÁÎÉÒÕÅÔÅ ÕÓÔÁÎÏ×ÉÔØ. îÁÐÒÉÍÅÒ, ÏÂÒÁÚÙ USB-ÎÁËÏÐÉÔÅÌÑ ÄÌÑ &os;/&arch.i386; &rel2.current;-RELEASE ÎÁÈÏÄÑÔÓÑ × . äÌÑ &os; ×ÅÒÓÉÊ 9.0-RELEASE É ÂÏÌÅÅ ÐÏÚÄÎÉÈ ÐÕÔØ ËÁÔÁÌÏÇÏ× ÏÔÌÉÞÁÅÔÓÑ ÏÔ ÐÒÉ×ÅÄÅÎÎÙÈ ×ÙÛÅ. äÅÔÁÌÉ ÚÁÇÒÕÚËÉ ÏÂÒÁÚÏ× É ÕÓÔÁÎÏ×ËÉ &os; 9.0-RELEASE É ÂÏÌÅÅ ÐÏÚÄÎÉÈ ÏÐÉÓÁÎÙ × . îÁÚ×ÁÎÉÅ ÆÁÊÌÁ ÏÂÒÁÚÁ ÚÁËÁÎÞÉ×ÁÅÔÓÑ ÎÁ .img. ëÁÔÁÌÏÇ ISO-IMAGES/ ÓÏÄÅÒÖÉÔ ÎÁÂÏÒ ÏÂÒÁÚÏ×, ÓÒÅÄÉ ËÏÔÏÒÙÈ ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ×ÙÂÒÁÔØ ÏÄÉÎ. ÷ÙÂÏÒ ÚÁ×ÉÓÉÔ ÏÔ ×ÅÒÓÉÉ ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÏÊ &os; É, × ÎÅËÏÔÏÒÙÈ ÓÌÕÞÁÑÈ, ÏÔ ÁÒÈÉÔÅËÔÕÒÙ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ÎÁ ËÏÔÏÒÏÅ ÂÕÄÅÔ ×ÙÐÏÌÎÑÔØÓÑ ÕÓÔÁÎÏ×ËÁ. ðÅÒÅÄ ÐÒÏÄÏÌÖÅÎÉÅÍ ÓÄÅÌÁÊÔÅ ÒÅÚÅÒ×ÎÕÀ ËÏÐÉÀ ÄÁÎÎÙÈ, ÎÁÈÏÄÑÝÉÈÓÑ ÎÁ ×ÁÛÅÍ USB-ÎÁËÏÐÉÔÅÌÅ, ÔÁË ËÁË ÐÏÓÌÅÄÕÀÝÉÅ ÄÅÊÓÔ×ÉÑ ÓÏÔÒÕÔ ×ÓÅ ÓÔÁÒÙÅ ÄÁÎÎÙÅ. úÁÐÉÓØ ÆÁÊÌÁ-ÏÂÒÁÚÁ ÎÁ USB-ÎÁËÏÐÉÔÅÌØ éÓÐÏÌØÚÏ×ÁÎÉÅ &os; ÄÌÑ ÚÁÐÉÓÉ ÆÁÊÌÁ-ÏÂÒÁÚÁ ÷ ÄÁÎÎÏÍ ÐÒÉÍÅÒÅ ÐÏÄÒÁÚÕÍÅ×ÁÅÔÓÑ, ÞÔÏ ÕÓÔÒÏÊÓÔ×Ï /dev/da0 Ñ×ÌÑÅÔÓÑ ÎÁÛÉÍ ÃÅÌÅ×ÙÍ ÕÓÔÒÏÊÓÔ×ÏÍ, ÎÁ ËÏÔÏÒÏÅ ÂÕÄÅÔ ÐÒÏÉÚ×ÏÄÉÔØÓÑ ÚÁÐÉÓØ ÏÂÒÁÚÁ. âÕÄØÔÅ ÐÒÅÄÅÌØÎÏ ×ÎÉÍÁÔÅÌØÎÙ, ÔÁË ËÁË, ÕËÁÚÁ× ÎÅ×ÅÒÎÏÅ ÕÓÔÒÏÊÓÔ×Ï, ×Ù ÕÎÉÞÔÏÖÉÔÅ ÓÕÝÅÓÔ×ÕÀÝÉÅ ÄÁÎÎÙÅ. úÁÐÉÓØ ÆÁÊÌÁ-ÏÂÒÁÚÁ ÐÒÉ ÐÏÍÏÝÉ &man.dd.1; æÁÊÌ .img ÎÅ Ñ×ÌÑÅÔÓÑ ÏÂÙËÎÏ×ÅÎÎÙÍ ÆÁÊÌÏÍ, ËÏÐÉÒÕÅÍÙÍ ÎÁ ÎÁËÏÐÉÔÅÌØ. üÔÏ ÏÂÒÁÚ ÓÏÄÅÒÖÉÍÏÇÏ ÄÉÓËÁ. üÔÏ ÚÎÁÞÉÔ, ÞÔÏ ×Ù ÎÅ ÍÏÖÅÔÅ ÐÒÏÓÔÏ ÓËÏÐÉÒÏ×ÁÔØ ÆÁÊÌÙ Ó ÄÉÓËÁ ÎÁ ÄÉÓË. ÷ÍÅÓÔÏ ËÏÐÉÒÏ×ÁÎÉÑ ×Ù ÄÏÌÖÎÙ ÉÓÐÏÌØÚÏ×ÁÔØ &man.dd.1; ÄÌÑ ÚÁÐÉÓÉ ÏÂÒÁÚÁ ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏ ÎÁ ÎÁËÏÐÉÔÅÌØ: &prompt.root; dd if=&os;-&rel2.current;-RELEASE-&arch.i386;-memstick.img of=/dev/da0 bs=64k åÓÌÉ ÏÔÏÂÒÁÖÁÅÔÓÑ ÏÛÉÂËÁ Operation not permitted, ÕÂÅÄÉÔÅÓØ, ÞÔÏ ÃÅÌÅ×ÏÅ ÕÓÔÒÏÊÓÔ×Ï ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ É ÎÅ ÐÒÉÍÏÎÔÉÒÏ×ÁÎÏ ×ÒÕÞÎÕÀ ÉÌÉ Á×ÔÏÍÁÔÉÞÅÓËÉ ËÁËÏÊ-ÌÉÂÏ ÐÏÌÅÚÎÏÊ ÕÔÉÌÉÔÏÊ. äÁÌÅÅ, ÐÏ×ÔÏÒÉÔÅ ÐÏÐÙÔËÕ ÅÝÅ ÒÁÚ. éÓÐÏÌØÚÏ×ÁÎÉÅ &windows; ÄÌÑ ÚÁÐÉÓÉ ÆÁÊÌÁ-ÏÂÒÁÚÁ õÄÏÓÔÏ×ÅÒØÔÅÓØ × ÔÏÍ, ÞÔÏ ×Ù ÉÓÐÏÌØÚÕÅÔÅ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÕÀ ÃÅÌÅ×ÏÍÕ ÕÓÔÒÏÊÓÔ×Õ ÂÕË×Õ ÄÉÓËÁ, ÉÎÁÞÅ ×Ù ÕÎÉÞÔÏÖÉÔÅ ÓÕÝÅÓÔ×ÕÀÝÉÅ ÄÁÎÎÙÅ. ðÏÌÕÞÅÎÉÅ ÐÒÉÌÏÖÅÎÉÑ <application>Image Writer for Windows</application> ðÒÉÌÏÖÅÎÉÅ Image Writer for Windows Ñ×ÌÑÅÔÓÑ Ó×ÏÂÏÄÎÏ ÒÁÓÐÒÏÓÔÒÁÎÑÅÍÙÍ ðï, ËÏÔÏÒÙÍ ÍÏÖÎÏ ËÏÒÒÅËÔÎÏ ÚÁÐÉÓÁÔØ ÆÁÊÌ-ÏÂÒÁÚ ÎÁ USB-ÎÁËÏÐÉÔÅÌØ. ðÏÓÅÔÉÔÅ ÓÔÒÁÎÉÃÕ , ÓËÁÞÁÊÔÅ É ÒÁÓÐÁËÕÊÔÅ ÐÒÉÌÏÖÅÎÉÅ. úÁÐÉÓØ ÆÁÊÌÁ-ÏÂÒÁÚÁ ÐÒÉ ÐÏÍÏÝÉ ÐÒÉÌÏÖÅÎÉÑ Image Writer äÌÑ ÚÁÐÕÓËÁ ÐÒÉÌÏÖÅÎÉÑ Ä×ÁÖÄÙ ÝÅÌËÎÉÔÅ ÍÙÛÅÊ ÉËÏÎËÕ Win32DiskImager. õÂÅÄÉÔÅÓØ, ÞÔÏ ÂÕË×Á ÄÉÓËÁ, ÏÔÏÂÒÁÖÁÅÍÁÑ × ×ÙÐÁÄÁÀÝÅÍ ÓÐÉÓËÅ Device ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ USB-ÎÁËÏÐÉÔÅÌÀ. ýÅÌËÎÉÔÅ ÍÙÛÅÊ ÎÁ ÉËÏÎËÕ Ó ÉÚÏÂÒÁÖÅÎÉÅÍ ÐÁÐËÉ É ×ÙÂÅÒÉÔÅ ÎÅÏÂÈÏÄÉÍÙÊ ÆÁÊÌ-ÏÂÒÁÚ. äÌÑ ÐÏÄÔ×ÅÒÖÄÅÎÉÑ ×ÙÂÏÒÁ ÉÍÅÎÉ ÆÁÊÌÁ ÎÁÖÍÉÔÅ ËÎÏÐËÕ Save. õÂÅÄÉÔÅÓØ, ÞÔÏ ×ÓÅ ××ÅÄ£ÎÎÙÅ ÄÁÎÎÙÅ ËÏÒÒÅËÔÎÙ, É ÞÔÏ × ÄÒÕÇÉÈ ÐÒÉÌÏÖÅÎÉÑÈ ÎÅÔ ÏÔËÒÙÔÙÈ ÐÁÐÏË ÉÌÉ ÆÁÊÌÏ×, ÎÁÈÏÄÑÝÉÈÓÑ ÎÁ ÃÅÌÅ×ÏÍ USB-ÎÁËÏÐÉÔÅÌÅ. é × ÚÁËÌÀÞÅÎÉÅ, ÝÅÌËÎÉÔÅ ËÎÏÐËÕ Write ÄÌÑ ÚÁÐÉÓÉ ÆÁÊÌÁ-ÏÂÒÁÚÁ ÎÁ ÎÁËÏÐÉÔÅÌØ. äÌÑ ÓÏÚÄÁÎÉÑ ÚÁÇÒÕÚÏÞÎÙÈ ÄÉÓËÅÔ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;/&arch.pc98; ÓÄÅÌÁÊÔÅ ÓÌÅÄÕÀÝÅÅ: ðÏÌÕÞÅÎÉÅ ÏÂÒÁÚÏ× ÚÁÇÒÕÚÏÞÎÙÈ ÄÉÓËÅÔ úÁÇÒÕÚÏÞÎÙÅ ÄÉÓËÅÔÙ &os;/&arch.pc98; ÍÏÇÕÔ ÂÙÔØ ÚÁËÁÞÁÎÙ ÉÚ ËÁÔÁÌÏÇÁ floppies ÐÏ ÁÄÒÅÓÕ ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/pc98/version-RELEASE/floppies/. úÁÍÅÎÉÔÅ version ÎÏÍÅÒÏÍ ×ÅÒÓÉÉ, ËÏÔÏÒÕÀ ×Ù ÈÏÔÉÔÅ ÕÓÔÁÎÏ×ÉÔØ. òÁÓÛÉÒÅÎÉÅ ÆÁÊÌÁ ÏÂÒÁÚÁ ÄÉÓËÅÔÙ — .flp. ëÁÔÁÌÏÇ floppies/ ÓÏÄÅÒÖÉÔ ÍÎÏÖÅÓÔ×Ï ÒÁÚÎÙÈ ÏÂÒÁÚÏ×. óËÁÞÁÊÔÅ boot.flp, Á ÔÁËÖÅ ÎÅÓËÏÌØËÏ ÆÁÊÌÏ× ÓÏÇÌÁÓÎÏ ÔÉÐÕ ÕÓÔÁÎÏ×ËÉ, ÔÁËÉÈ ËÁË kern.small* ÉÌÉ kern*. FTP ËÌÉÅÎÔ ÄÏÌÖÅÎ ÉÓÐÏÌØÚÏ×ÁÔØ ÂÉÎÁÒÎÙÊ ÒÅÖÉÍ ÄÌÑ ÚÁÇÒÕÚËÉ ÏÂÒÁÚÏ× ÄÉÓËÅÔ. îÅËÏÔÏÒÙÅ Web-ÂÒÁÕÚÅÒÙ ÉÓÐÏÌØÚÕÀÔ ÔÅËÓÔÏ×ÙÊ (ASCII) ÒÅÖÉÍ, ËÏÔÏÒÙÊ ÔÏÞÎÏ ÎÅ ÐÏÚ×ÏÌÉÔ ÚÁÇÒÕÚÉÔØÓÑ Ó ÜÔÉÈ ÄÉÓËÅÔ. ðÏÄÇÏÔÏ×ËÁ ÄÉÓËÅÔ îÅÏÂÈÏÄÉÍÏ ÐÏÄÇÏÔÏ×ÉÔØ ÐÏ ÏÄÎÏÊ ÄÉÓËÅÔÅ ÎÁ ËÁÖÄÙÊ ÚÁÇÒÕÖÅÎÎÙÊ ÏÂÒÁÚ. üÔÉ ÄÉÓËÅÔÙ ÄÏÌÖÎÙ ÂÙÔØ ÂÅÚ ÄÅÆÅËÔÏ×. ìÕÞÛÉÊ ÓÐÏÓÏ ÐÒÏ×ÅÒÉÔØ ÜÔÏ — ÏÔÆÏÒÍÁÔÉÒÏ×ÁÔØ ÄÉÓËÅÔÙ ÓÁÍÏÓÔÏÑÔÅÌØÎÏ. îÅ ÄÏ×ÅÒÑÊÔÅ ÚÁ×ÏÄÓËÏÍÕ ÆÏÒÍÁÔÉÒÏ×ÁÎÉÀ ÄÉÓËÅÔ. õÔÉÌÉÔÁ ÆÏÒÍÁÔÉÒÏ×ÁÎÉÑ × &windows; ÎÅ ÓÏÏÂÝÉÔ Ï ÎÁÌÉÞÉÉ ÐÌÏÈÉÈ ÓÅËÔÏÒÏ×, ÏÎÁ ÐÒÏÓÔÏ ÐÏÍÅÔÉÔ ÉÈ ËÁË ÐÌÏÈÉÅ É ÐÒÏÉÇÎÏÒÉÒÕÅÔ. óÏ×ÅÔÕÅÍ ÉÓÐÏÌØÚÏ×ÁÔØ ÎÏ×ÙÅ ÄÉÓËÅÔÙ ÅÓÌÉ ×Ù ×ÙÂÒÁÌÉ ÜÔÏÔ ÓÐÏÓÏ ÕÓÔÁÎÏ×ËÉ. åÓÌÉ ÐÒÉ ÐÏÐÙÔËÅ ÕÓÔÁÎÏ×ËÉ &os; ÐÒÏÇÒÁÍÍÁ ÕÓÔÁÎÏ×ËÉ ÒÕÛÉÔÓÑ, ÚÁ×ÉÓÁÅÔ, ÉÌÉ ÄÅÌÁÅÔ ÞÔÏ-ÔÏ ÎÅ ÔÁË, ÓÒÁÚÕ ÐÒÏ×ÅÒØÔÅ ÄÉÓËÅÔÙ. úÁÐÉÛÉÔÅ ÏÂÒÁÚÙ ÎÁ ÎÏ×ÙÅ ÄÉÓËÅÔÙ É ÐÏÐÙÔÁÊÔÅÓØ ÅÝÅ ÒÁÚ. úÁÐÉÓØ ÏÂÒÁÚÏ× ÎÁ ÄÉÓËÅÔÙ æÁÊÌÙ Ó ÒÁÓÛÉÒÅÎÉÅÍ .flp ÜÔÏ ÎÅ ÏÂÙÞÎÙÅ ÆÁÊÌÙ, ËÏÔÏÒÙÅ ÍÏÖÎÏ ÚÁÐÉÓÁÔØ ÎÁ ÄÉÓËÅÔÕ. üÔÏ ÏÂÒÁÚÙ ×ÓÅÇÏ ÓÏÄÅÒÖÉÍÏÇÏ ÄÉÓËÅÔÙ. üÔÏ ÏÚÎÁÞÁÅÔ, ÞÔÏ ×Ù ÎÅ ÍÏÖÅÔÅ ÐÒÏÓÔÏ ÓËÏÐÉÒÏ×ÁÔØ ÉÈ Ó ÏÄÎÏÊ ÄÉÓËÅÔÙ ÎÁ ÄÒÕÇÕÀ. ÷ÍÅÓÔÏ ÜÔÏÇÏ, ÎÕÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ ÓÐÅÃÉÁÌØÎÙÅ ÕÔÉÌÉÔÙ ÄÌÑ ÚÁÐÉÓÉ ÏÂÒÁÚÏ× ÎÁ ÄÉÓË. DOS åÓÌÉ ×Ù ÚÁÐÉÓÙ×ÁÅÔÅ ÄÉÓËÅÔÙ ÎÁ ËÏÍÐØÀÔÅÒÅ ÐÏÄ &ms-dos; / &windows;, ÉÓÐÏÌØÚÕÊÔÅ ÕÔÉÌÉÔÕ fdimage. åÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ ÏÂÒÁÚÙ Ó CDROM, É ÂÕË×Á ×ÁÛÅÇÏ CDROM E:, ÚÁÐÕÓÔÉÔÅ ÅÅ ÔÁË: E:\> tools\fdimage floppies\boot.flp A: ðÏ×ÔÏÒÉÔÅ ÜÔÕ ËÏÍÁÎÄÕ ÄÌÑ ËÁÖÄÏÇÏ ÆÁÊÌÁ .flp, ×ÓÔÁ×ÌÑÑ ÎÏ×ÕÀ ÄÉÓËÅÔÕ ËÁÖÄÙÊ ÒÁÚ, ÐÏÍÅÔØÔÅ ËÁÖÄÕÀ ÄÉÓËÅÔÕ ÉÍÅÎÅÍ ÆÁÊÌÁ, ËÏÔÏÒÙÊ ×Ù ÓËÏÐÉÒÏ×ÁÌÉ ÎÁ ÎÅÇÏ. éÚÍÅÎÉÔÅ ËÏÍÁÎÄÕ ÅÓÌÉ ÐÏÔÒÅÂÕÅÔÓÑ, × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÍÅÓÔÁ, ËÕÄÁ ×Ù ÐÏÍÅÓÔÉÌÉ ÆÁÊÌÙ .flp. åÓÌÉ Õ ×ÁÓ ÎÅÔ CDROM, fdimage ÍÏÖÅÔ ÂÙÔØ ÚÁÇÒÕÖÅÎÁ ÉÚ ËÁÔÁÌÏÇÁ tools FTP ÓÅÒ×ÅÒÁ &os;. åÓÌÉ ×Ù ÚÁÐÉÓÙ×ÁÅÔÅ ÄÉÓËÅÔÙ ÎÁ &unix; (ÎÁÐÒÉÍÅÒ, ÎÁ ÄÒÕÇÏÊ ÓÉÓÔÅÍÅ &os;), ÉÓÐÏÌØÚÕÊÔÅ ÕÔÉÌÉÔÕ &man.dd.1; ÄÌÑ ÚÁÐÉÓÉ ÏÂÒÁÚÏ× ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏ ÎÁ ÄÉÓËÅÔÙ. îÁÈÏÄÑÓØ × &os;, ÚÁÐÕÓÔÉÔÅ: &prompt.root; dd if=boot.flp of=/dev/fd0 ðÏÄ &os;, /dev/fd0 ÏÚÎÁÞÁÅÔ ÐÅÒ×ÙÊ ÇÉÂËÉÊ ÄÉÓË (ÄÉÓË A:). /dev/fd1 ÂÕÄÅÔ ÄÉÓËÏÍ B:, É ÔÁË ÄÁÌÅÅ. äÒÕÇÉÅ &unix; ÓÉÓÔÅÍÙ ÍÏÇÕÔ ÐÏ-ÄÒÕÇÏÍÕ ÉÍÅÎÏ×ÁÔØ ÕÓÔÒÏÊÓÔ×Á ÇÉÂËÉÈ ÄÉÓËÏ×, ×ÁÍ ×ÏÚÍÏÖÎÏ ÐÏÎÁÄÏÂÉÔÓÑ ÐÒÏÞÉÔÁÔØ ÄÏËÕÍÅÎÔÁÃÉÀ ÐÏ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÊ ÓÉÓÔÅÍÅ. ôÅÐÅÒØ ×Ù ÇÏÔÏ×Ù Ë ÕÓÔÁÎÏ×ËÅ &os;.
îÁÞÁÌÏ ÕÓÔÁÎÏ×ËÉ ëÁË ÐÒÁ×ÉÌÏ, ÐÒÏÇÒÁÍÍÁ ÕÓÔÁÎÏ×ËÉ ÎÅ ÂÕÄÅÔ ÐÒÏÉÚ×ÏÄÉÔØ ÎÉËÁËÉÈ ÉÚÍÅÎÅÎÉÊ ÎÁ ÄÉÓËÁÈ, ÐÏËÁ ÎÅ ×ÙÄÁÓÔ ÓÌÅÄÕÀÝÅÅ ÓÏÏÂÝÅÎÉÅ: Last Chance: Are you SURE you want continue the installation? If you're running this on a disk with data you wish to save then WE STRONGLY ENCOURAGE YOU TO MAKE PROPER BACKUPS before proceeding! We can take no responsibility for lost disk contents! õÓÔÁÎÏ×ËÁ ÍÏÖÅÔ ÂÙÔØ ÐÒÅÒ×ÁÎÁ × ÌÀÂÏÊ ÍÏÍÅÎÔ ÄÏ ÜÔÏÇÏ ÐÒÅÄÕÐÒÅÖÄÅÎÉÑ ÂÅÚ ËÁËÉÈ-ÌÉÂÏ ÉÚÍÅÎÅÎÉÊ ÎÁ ÖÅÓÔËÏÍ ÄÉÓËÅ. åÓÌÉ ×Ù ÓÞÉÔÁÅÔÅ, ÞÔÏ ÞÔÏ-ÔÏ ÎÁÓÔÒÏÉÌÉ ÎÅÐÒÁ×ÉÌØÎÏ, ÍÏÖÅÔÅ ÐÒÏÓÔÏ ×ÙËÌÀÞÉÔØ ËÏÍÐØÀÔÅÒ ÂÅÚ ÒÉÓËÁ ÞÔÏ-ÌÉÂÏ ÐÏ×ÒÅÄÉÔØ. úÁÇÒÕÚËÁ úÁÇÒÕÚËÁ &i386; ëÏÍÐØÀÔÅÒ ×ÙËÌÀÞÅÎ. ÷ËÌÀÞÉÔÅ ËÏÍÐØÀÔÅÒ. ðÏÓÌÅ ×ËÌÀÞÅÎÉÑ ÏÎ ÄÏÌÖÅÎ ÐÏËÁÚÁÔØ ÓÐÏÓÏ ×ÈÏÄÁ × ÍÅÎÀ ÕÓÔÁÎÏ×ËÉ BIOS, ËÁË ÐÒÁ×ÉÌÏ ÜÔÏ ËÌÁ×ÉÛÉ F2, F10, Del, ÉÌÉ Alt S . éÓÐÏÌØÚÕÅÔÅ ÔÅ ËÌÁ×ÉÛÉ, ËÏÔÏÒÙÅ ÐÏËÁÚÁÎÙ ÎÁ ÜËÒÁÎÅ. ÷ ÎÅËÏÔÏÒÙÈ ÓÌÕÞÁÑÈ ËÏÍÐØÀÔÅÒ ÍÏÖÅÔ ÐÏËÁÚÙ×ÁÔØ ËÁÒÔÉÎËÕ ÐÏÓÌÅ ÚÁÐÕÓËÁ. ëÁË ÐÒÁ×ÉÌÏ, ÎÁÖÁÔÉÅ Esc ÕÂÅÒÅÔ ËÁÒÔÉÎËÕ É ÐÏÚ×ÏÌÉÔ ×ÁÍ Õ×ÉÄÅÔØ ÎÅÏÂÈÏÄÉÍÕÀ ÉÎÆÏÒÍÁÃÉÀ. îÁÊÄÉÔÅ ÕÓÔÁÎÏ×ËÉ ÓÉÓÔÅÍÙ, ÕËÁÚÙ×ÁÀÝÉÅ ÅÊ Ó ËÁËÏÇÏ ÕÓÔÒÏÊÓÔ×Á ÚÁÇÒÕÖÁÔØÓÑ. ïÂÙÞÎÏ ÏÎÉ ÏÂÏÚÎÁÞÁÀÔÓÑ ËÁË Boot Order, É ÔÁÍ ËÁË ÐÒÁ×ÉÌÏ ÏÔÏÂÒÁÖÅÎ ÓÐÉÓÏË ÕÓÔÒÏÊÓÔ×, ÔÁËÉÈ ËÁË Floppy, CDROM, First Hard Disk, É ÔÁË ÄÁÌÅÅ. åÓÌÉ ×Ù ÚÁÇÒÕÖÁÅÔÅÓØ Ó CDROM, ÕÂÅÄÉÔÅÓØ, ÞÔÏ ÏÎ ×ÙÂÒÁÎ. åÓÌÉ ×Ù ÚÁÇÒÕÖÁÅÔÅÓØ Ó USB-ÎÏÓÉÔÅÌÑ ÉÌÉ Ó ÄÉÓËÅÔÙ, ÕÂÅÄÉÔÅÓØ, ÞÔÏ ×ÙÂÒÁÎÏ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÅ ÕÓÔÒÏÊÓÔ×Ï. åÓÌÉ ×Ù ÎÅ Õ×ÅÒÅÎÙ, ÐÏÓÍÏÔÒÉÔÅ ÒÕËÏ×ÏÄÓÔ×Ï Ë ËÏÍÐØÀÔÅÒÕ É/ÉÌÉ Ë ÅÇÏ ÍÁÔÅÒÉÎÓËÏÊ ÐÌÁÔÅ. óÄÅÌÁÊÔÅ ÉÚÍÅÎÅÎÉÑ, ÚÁÔÅÍ ÓÏÈÒÁÎÉÔÅ ÉÈ É ×ÙÊÄÉÔÅ. ëÏÍÐØÀÔÅÒ ÄÏÌÖÅÎ ÐÅÒÅÚÁÇÒÕÚÉÔØÓÑ. åÓÌÉ ×Ù ÐÏÄÇÏÔÏ×ÉÌÉ ÚÁÇÒÕÚÏÞÎÙÊ USB-ÎÏÓÉÔÅÌØ, ËÁË ÏÐÉÓÁÎÏ × , ×ÓÔÁרÔÅ ÅÇÏ × USB ÐÏÒÔ ÐÅÒÅÄ ×ËÌÀÞÅÎÉÅÍ ËÏÍÐØÀÔÅÒÁ. åÓÌÉ ×Ù ÚÁÇÒÕÖÁÅÔÅÓØ Ó CDROM, ÐÏÔÒÅÂÕÅÔÓÑ ÓÎÁÞÁÌÁ ×ËÌÀÞÉÔØ ËÏÍÐØÀÔÅÒ É ×ÓÔÁ×ÉÔØ ËÏÍÐÁËÔ-ÄÉÓË, ËÁË ÔÏÌØËÏ ÜÔÏ ÓÔÁÎÅÔ ×ÏÚÍÏÖÎÏ. äÌÑ &os;/&arch.pc98; ÓÕÝÅÓÔ×ÕÀÔ ÏÂÒÁÚÙ ÚÁÇÒÕÚÏÞÎÙÈ ÄÉÓËÅÔ, ÐÏÄÇÏÔÏ×ËÁ ËÏÔÏÒÙÈ ÏÐÉÓÁÎÁ × . ðÅÒ×ÁÑ ÄÉÓËÅÔÁ ÂÕÄÅÔ ÓÏÄÅÒÖÁÔØ boot.flp. äÌÑ ÚÁÇÒÕÚËÉ × ÐÒÏÇÒÁÍÍÕ ÕÓÔÁÎÏ×ËÉ ×ÓÔÁרÔÅ ÜÔÕ ÄÉÓËÅÔÕ × ÄÉÓËÏ×ÏÄ. åÓÌÉ ËÏÍÐØÀÔÅÒ ÚÁÐÕÓËÁÅÔÓÑ ËÁË ÏÂÙÞÎÏ, É ÚÁÇÒÕÖÁÅÔ ÓÕÝÅÓÔ×ÕÀÝÕÀ ÏÐÅÒÁÃÉÏÎÎÕÀ ÓÉÓÔÅÍÕ, ×ÏÚÍÏÖÎÙ ÓÌÅÄÕÀÝÉÅ ÐÒÉÞÉÎÙ: äÉÓË ÂÙÌ ×ÓÔÁ×ÌÅÎ ÎÅÄÏÓÔÁÔÏÞÎÏ ÒÁÎÏ × ÐÒÏÃÅÓÓÅ ÚÁÇÒÕÚËÉ. ïÓÔÁרÔÅ ÅÇÏ ×ÎÕÔÒÉ É ÐÅÒÅÇÒÕÚÉÔÅ ËÏÍÐØÀÔÅÒ. õÓÔÁÎÏ×ËÉ BIOS, ÉÚÍÅÎÅÎÎÙÅ ÒÁÎÅÅ, ÄÅÊÓÔ×ÕÀÔ ÎÅÐÒÁ×ÉÌØÎÏ. îÁÄÏ ÉÚÍÅÎÑÔØ ÉÈ, ÐÏËÁ ÏÎÉ ÎÅ ÚÁÒÁÂÏÔÁÀÔ. BIOS ×ÁÛÅÇÏ ËÏÍÐØÀÔÅÒÁ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔ ÚÁÇÒÕÚËÕ Ó ×ÙÂÒÁÎÎÏÇÏ ÔÉÐÁ ÎÏÓÉÔÅÌÑ. &os; ÎÁÞÎÅÔ ÚÁÇÒÕÚËÕ. åÓÌÉ ÚÁÇÒÕÚËÁ ÐÒÏÉÓÈÏÄÉÔ Ó CDROM, ×Ù Õ×ÉÄÉÔÅ ÞÔÏ-ÔÏ ×ÒÏÄÅ ÜÔÏÇÏ (ÉÎÆÏÒÍÁÃÉÑ Ï ×ÅÒÓÉÉ ÕÄÁÌÅÎÁ): Booting from CD-Rom... 645MB medium detected CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 636kB/261056kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 syms=[0x4+0x6cac0+0x4+0x88e9d] \ åÓÌÉ ÐÒÏÉÓÈÏÄÉÔ ÚÁÇÒÕÚËÁ Ó ÄÉÓËÅÔÙ, ×Ù Õ×ÉÄÉÔÅ ÞÔÏ-ÔÏ ×ÒÏÄÅ ÜÔÏÇÏ (ÉÎÆÏÒÍÁÃÉÑ Ï ×ÅÒÓÉÉ ÕÄÁÌÅÎÁ): Booting from Floppy... Uncompressing ... done BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/261120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /kernel text=0x277391 data=0x3268c+0x332a8 | Insert disk labelled "Kernel floppy 1" and press any key... óÌÅÄÕÑ ÉÎÓÔÒÕËÃÉÑÍ, ÕÂÅÒÉÔÅ ÄÉÓËÅÔÕ Ó boot.flp, ×ÓÔÁרÔÅ ÄÉÓËÅÔÕ Ó kern1.flp É ÎÁÖÍÉÔÅ Enter. úÁÇÒÕÚÉÔÅÓØ Ó ÐÅÒ×ÏÊ ÄÉÓËÅÔÙ; ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÏ ×ÓÔÁ×ÌÑÊÔÅ ÏÓÔÁÌØÎÙÅ ÄÉÓËÉ ÐÒÉ ÐÏÑ×ÌÅÎÉÉ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÇÏ ÐÒÉÇÌÁÛÅÎÉÑ. éÄÅÔ ÌÉ ÚÁÇÒÕÚËÁ Ó CDROM, ÉÌÉ Ó USB-ÎÏÓÉÔÅÌÑ, ÉÌÉ Ó ÄÉÓËÅÔÙ × ÐÒÏÃÅÓÓÅ ÚÁÇÒÕÚËÉ ÐÏÑ×ÉÔÓÑ ÍÅÎÀ ÚÁÇÒÕÚÞÉËÁ &os;:
&os; Boot Loader Menu
ðÏÄÏÖÄÉÔÅ ÄÅÓÑÔØ ÓÅËÕÎÄ ÉÌÉ ÎÁÖÍÉÔÅ Enter.
úÁÇÒÕÚËÁ &sparc64; âÏÌØÛÉÎÓÔ×Ï ÓÉÓÔÅÍ &sparc64; ÎÁÓÔÒÏÅÎÙ ÎÁ Á×ÔÏÍÁÔÉÞÅÓËÕÀ ÚÁÇÒÕÚËÕ Ó ÖÅÓÔËÏÇÏ ÄÉÓËÁ. äÌÑ ÔÏÇÏ, ÞÔÏÂÙ ÕÓÔÁÎÏ×ÉÔØ &os;, ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ×ÙÐÏÌÎÉÔØ ÚÁÇÒÕÚËÕ ÐÏ ÓÅÔÉ ÉÌÉ Ó ËÏÍÐÁËÔ-ÄÉÓËÁ, ÞÔÏ × Ó×ÏÀ ÏÞÅÒÅÄØ ÔÒÅÂÕÅÔ ÐÏÌÕÞÅÎÉÑ ÄÏÓÔÕÐÁ Ë PROM (OpenFirmware). þÔÏÂÙ ÐÏÌÕÞÉÔØ ÄÏÓÔÕÐ Ë PROM, ÐÅÒÅÚÁÇÒÕÚÉÔÅ ÓÉÓÔÅÍÕ É ÄÏÖÄÉÔÅÓØ ÐÏÑ×ÌÅÎÉÑ ÓÏÏÂÝÅÎÉÊ ÚÁÇÒÕÚÞÉËÁ. ðÏÓÌÅÄÎÉÅ ÚÁ×ÉÓÑÔ ÏÔ ÍÏÄÅÌÉ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ÎÏ, × ÏÂÝÅÍ, ×ÙÇÌÑÄÑÔ ÐÏÄÏÂÎÏ ÓÌÅÄÕÀÝÉÍ: Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2001 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.2, 128 MB memory installed, Serial #51090132. Ethernet address 0:3:ba:b:92:d4, Host ID: 830b92d4. åÓÌÉ ÎÁ ÄÁÎÎÏÍ ÜÔÁÐÅ ×ÁÛÁ ÓÉÓÔÅÍÁ ÐÒÏÄÏÌÖÁÅÔ ÚÁÇÒÕÖÁÔØÓÑ Ó ÄÉÓËÁ, ÔÏ ÄÌÑ ÄÏÓÔÕÐÁ Ë PROM ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÎÁÖÁÔØ ÎÁ ËÌÁ×ÉÁÔÕÒÅ ÓÏÞÅÔÁÎÉÑ ËÌÁ×ÉÛ L1A ÉÌÉ StopA, ÉÌÉ ÖÅ — ÐÏÓÌÁÔØ BREAK ÎÁ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÏÊ ËÏÎÓÏÌÉ (ÎÁÐÒÉÍÅÒ, ÎÁÂÒÁ× ~# × &man.tip.1; ÉÌÉ &man.cu.1;). ðÒÉÇÌÁÛÅÎÉÅ PROM ×ÙÇÌÑÄÉÔ ÐÏÄÏÂÎÏ ÓÌÅÄÕÀÝÅÍÕ: ok ok {0} ïÄÎÏÐÒÏÃÅÓÓÏÒÎÙÅ ÓÉÓÔÅÍÙ ×ÙÄÁÀÔ ÔÁËÏÅ ÐÒÉÇÌÁÛÅÎÉÅ. ðÒÉÇÌÁÛÅÎÉÅ, ÉÓÐÏÌØÚÕÅÍÏÅ ÍÎÏÇÏÐÒÏÃÅÓÓÏÒÎÙÍÉ ÓÉÓÔÅÍÁÍÉ: ÃÉÆÒÁ ÏÂÏÚÎÁÞÁÅÔ ÎÏÍÅÒ ÁËÔÉ×ÎÏÇÏ ÐÒÏÃÅÓÓÏÒÁ. îÁ ÜÔÏÊ ÓÔÁÄÉÉ ÎÅÏÂÈÏÄÉÍÏ ×ÓÔÁ×ÉÔØ CDROM × ÐÒÉ×ÏÄ É ÎÁÂÒÁÔØ boot cdrom × ÐÒÉÇÌÁÛÅÎÉÉ PROM.
ðÒÏÓÍÏÔÒ ÒÅÚÕÌØÔÁÔÏ× ÔÅÓÔÉÒÏ×ÁÎÉÑ ÕÓÔÒÏÊÓÔ× ðÏÓÌÅÄÎÉÅ ÎÅÓËÏÌØËÏ ÓÏÔÅÎ ÌÉÎÉÊ, ÏÔÏÂÒÁÖÅÎÎÙÅ ÎÁ ÜËÒÁÎÅ, ÓÏÈÒÁÎÑÀÔÓÑ É ÍÏÇÕÔ ÂÙÔØ ÐÒÏÓÍÏÔÒÅÎÙ. äÌÑ ÐÒÏÓÍÏÔÒÁ ÂÕÆÅÒÁ ÎÁÖÍÉÔÅ Scroll Lock. üÔÏ ×ËÌÀÞÉÔ ÐÒÏËÒÕÔËÕ ÜËÒÁÎÁ. ÷Ù ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÉÌÉ PageUp É PageDown ÄÌÑ ÐÒÏÓÍÏÔÒÁ ÒÅÚÕÌØÔÁÔÏ×. îÁÖÍÉÔÅ Scroll Lock ÅÝÅ ÒÁÚ ÄÌÑ ÏÔËÌÀÞÅÎÉÑ ÐÒÏËÒÕÔËÉ. óÄÅÌÁÊÔÅ ÜÔÏ ÓÅÊÞÁÓ ÄÌÑ ÐÒÏÓÍÏÔÒÁ ÔÅËÓÔÁ, ÕÛÅÄÛÅÇÏ ÚÁ ÜËÒÁÎ, ËÏÇÄÁ ÑÄÒÏ ÚÁËÏÎÞÉÌÏ ÔÅÓÔÉÒÏ×ÁÎÉÅ ÕÓÔÒÏÊÓÔ×. ÷Ù Õ×ÉÄÉÔÅ ÔÅËÓÔ ×ÒÏÄÅ , ÈÏÔÑ × ÄÅÔÁÌÑÈ ÏÎ ÂÕÄÅÔ ÏÔÌÉÞÁÔØÓÑ × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÕÓÔÒÏÊÓÔ×, ÉÍÅÀÝÉÈÓÑ × ×ÁÛÅÍ ËÏÍÐØÀÔÅÒÅ.
ôÉÐÉÞÎÙÊ ×Ù×ÏÄ Device Probe avail memory = 253050880 (247120K bytes) Preloaded elf kernel "kernel" at 0xc0817000. Preloaded mfs_root "/mfsroot" at 0xc0817084. md0: Preloaded image </mfsroot> 4423680 bytes at 0xc03ddcd4 md1: Malloc disk Using $PIR table, 4 entries at 0xc00fde60 npx0: <math processor> on motherboard npx0: INT 16 interface pcib0: <Host to PCI bridge> on motherboard pci0: <PCI bus> on pcib0 pcib1:<VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1 pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 irq 11 isab0: <VIA 82C586 PCI-ISA bridge> at device 7.0 on pci0 isa0: <iSA bus> on isab0 atapci0: <VIA 82C586 ATA33 controller> port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0 <VIA 83C572 USB controller> port 0xe400-0xe41f irq 10 at device 7.2 on pci 0 usb0: <VIA 83572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr1 uhub0: 2 ports with 2 removable, self powered pci0: <unknown card> (vendor=0x1106, dev=0x3040) at 7.3 dc0: <ADMtek AN985 10/100BaseTX> port 0xe800-0xe8ff mem 0xdb000000-0xeb0003ff ir q 11 at device 8.0 on pci0 dc0: Ethernet address: 00:04:5a:74:6b:b5 miibus0: <MII bus> on dc0 ukphy0: <Generic IEEE 802.3u media interface> on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ed0: <NE2000 PCI Ethernet (RealTek 8029)> port 0xec00-0xec1f irq 9 at device 10. 0 on pci0 ed0 address 52:54:05:de:73:1b, type NE2000 (16 bit) isa0: too many dependant configs (8) isa0: unexpected small tag 14 orm0: <Option ROM> at iomem 0xc0000-0xc7fff on isa0 fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5” drive> on fdc0 drive 0 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 atkbd0: <AT Keyboard> flags 0x1 irq1 on atkbdc0 kbd0 at atkbd0 psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: model Generic PS/@ mouse, device ID 0 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 pppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold plip0: <PLIP network interface> on ppbus0 ad0: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata0-master UDMA33 acd0: CD-RW <LITE-ON LTR-1210B> at ata1-slave PIO4 Mounting root from ufs:/dev/md0c /stand/sysinstall running as init on vty0
÷ÎÉÍÁÔÅÌØÎÏ ÐÒÏ×ÅÒØÔÅ ÒÅÚÕÌØÔÁÔÙ ÔÅÓÔÉÒÏ×ÁÎÉÑ ÕÓÔÒÏÊÓÔ× É ÕÂÅÄÉÔÅÓØ, ÞÔÏ &os; ÏÂÎÁÒÕÖÉÌÁ ×ÓÅ ÕÓÔÒÏÊÓÔ×Á, ËÁËÉÅ ÎÕÖÎÏ. åÓÌÉ ÕÓÔÒÏÊÓÔ×Ï ÎÅ ÎÁÊÄÅÎÏ, ÅÇÏ ÎÅ ÂÕÄÅÔ × ÓÐÉÓËÅ. óÏÂÓÔ×ÅÎÎÏÅ ÑÄÒÏ ÐÏÚ×ÏÌÑÅÔ ÄÏÂÁ×ÌÑÔØ ÐÏÄÄÅÒÖËÕ ÕÓÔÒÏÊÓÔ×, ÏÔÓÕÔÓÔ×ÕÀÝÉÈ × ÑÄÒÅ GENERIC, ÎÁÐÒÉÍÅÒ Ú×ÕËÏ×ÙÈ ËÁÒÔ. ðÏÓÌÅ ÐÒÏ×ÅÒËÉ ÁÐÐÁÒÁÔÎÙÈ ÕÓÔÒÏÊÓÔ×, ÐÏÑ×ÉÔÓÑ . éÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ ÓÔÒÁÎÙ, ÒÅÇÉÏÎÁ ÉÌÉ ÇÒÕÐÐÙ. úÁÔÅÍ ÎÁÖÍÉÔÅ Enter, ÐÒÏÉÚÏÊÄÅÔ ×ÙÂÏÒ ÓÔÒÁÎÙ.
íÅÎÀ ×ÙÂÏÒÁ ÓÔÒÁÎÙ
åÓÌÉ ×Ù ×ÙÂÒÁÌÉ ÓÔÒÁÎÕ United States, ÔÏ ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÎÁ ÓÔÁÎÄÁÒÔÎÁÑ ÁÍÅÒÉËÁÎÓËÁÑ ÒÁÓËÌÁÄËÁ ËÌÁ×ÉÁÔÕÒÙ, ÅÓÌÉ ÖÅ ÂÙÌÁ ×ÙÂÒÁÎÁ ÄÒÕÇÁÑ ÓÔÒÁÎÁ, ÔÏ ÏÔÏÂÒÁÚÉÔÓÑ ÓÌÅÄÕÀÝÅÅ ÍÅÎÀ. éÓÐÏÌØÚÕÑ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ, ×ÙÂÅÒÉÔÅ ÎÅÏÂÈÏÄÉÍÕÀ ÒÁÓËÌÁÄËÕ É ÎÁÖÍÉÔÅ Enter.
íÅÎÀ ×ÙÂÏÒÁ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ
ðÏÓÌÅ ÍÅÎÀ ×ÙÂÏÒÁ ÓÔÒÁÎÙ ÂÕÄÅÔ ÏÔÏÂÒÁÖÅÎÏ ÇÌÁ×ÎÏÅ ÍÅÎÀ sysinstall.
÷×ÅÄÅÎÉÅ × Sysinstall õÔÉÌÉÔÁ sysinstall ÜÔÏ ÐÒÏÇÒÁÍÍÁ ÕÓÔÁÎÏ×ËÉ, ÐÒÅÄÏÓÔÁ×ÌÑÅÍÁÑ ÐÒÏÅËÔÏÍ &os;. üÔÏ ËÏÎÓÏÌØÎÏÅ ÐÒÉÌÏÖÅÎÉÅ, ÒÁÚÄÅÌÅÎÎÏÅ ÎÁ ÎÅÓËÏÌØËÏ ÍÅÎÀ É ÜËÒÁÎÏ×, ËÏÔÏÒÙÅ ×Ù ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÌÑ ÎÁÓÔÒÏÊËÉ É ÕÐÒÁ×ÌÅÎÉÑ ÐÒÏÃÅÓÓÏÍ ÕÓÔÁÎÏ×ËÉ. íÅÎÀ sysinstall ÕÐÒÁ×ÌÑÅÔÓÑ ËÌÁ×ÉÛÁÍÉ ÎÁ×ÉÇÁÃÉÉ, Enter, Tab, ÐÒÏÂÅÌÏÍ, É ÄÒÕÇÉÍÉ. ðÏÄÒÏÂÎÏÅ ÏÐÉÓÁÎÉÅ ËÌÁ×ÉÛ É ÉÈ ÆÕÎËÃÉÊ ÓÏÄÅÒÖÉÔÓÑ × ÉÎÆÏÒÍÁÃÉÉ ÐÏ ÉÓÐÏÌØÚÏ×ÁÎÉÀ sysinstall. äÌÑ ÐÒÏÓÍÏÔÒÁ ÜÔÏÊ ÉÎÆÏÒÍÁÃÉÉ ÕÂÅÄÉÔÅÓØ, ÞÔÏ ×ÙÂÒÁÎÙ ÐÕÎËÔ Usage É ËÎÏÐËÁ [Select], ËÁË ÐÏËÁÚÁÎÏ ÎÁ , ÚÁÔÅÍ ÎÁÖÍÉÔÅ Enter. âÕÄÕÔ ÐÏËÁÚÁÎÙ ÉÎÓÔÒÕËÃÉÉ ÐÏ ÉÓÐÏÌØÚÏ×ÁÎÉÀ ÍÅÎÀ. ðÏÓÌÅ ÐÒÏÓÍÏÔÒÁ ÉÎÓÔÒÕËÃÉÊ, ÎÁÖÍÉÔÅ Enter ÄÌÑ ×ÏÚ×ÒÁÔÁ × ÇÌÁ×ÎÏÅ ÍÅÎÀ.
÷ÙÂÏÒ Usage × ÇÌÁ×ÎÏÍ ÍÅÎÀ Sysinstall
÷ÙÂÏÒ ÍÅÎÀ ÄÏËÕÍÅÎÔÁÃÉÉ (Doc) éÚ ÇÌÁ×ÎÏÇÏ ÍÅÎÀ ×ÙÂÅÒÉÔÅ ËÌÁ×ÉÛÁÍÉ ÎÁ×ÉÇÁÃÉÉ Doc É ÎÁÖÍÉÔÅ Enter.
÷ÙÂÏÒ ÍÅÎÀ ÄÏËÕÍÅÎÔÁÃÉÉ
âÕÄÅÔ ÏÔÏÂÒÁÖÅÎÏ ÍÅÎÀ ÄÏËÕÍÅÎÔÁÃÉÉ.
íÅÎÀ ÄÏËÕÍÅÎÔÁÃÉÉ Sysinstall
òÅËÏÍÅÎÄÕÅÔÓÑ ÐÒÏÞÉÔÁÔØ ÐÒÅÄÏÓÔÁ×ÌÑÅÍÕÀ ÄÏËÕÍÅÎÔÁÃÉÀ. äÌÑ ÐÒÏÓÍÏÔÒÁ ÄÏËÕÍÅÎÔÁ ×ÙÂÅÒÉÔÅ ÅÇÏ Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter. ðÏÓÌÅ ÐÒÏÞÔÅÎÉÑ ÄÏËÕÍÅÎÔÁ ÎÁÖÍÉÔÅ Enter ÄÌÑ ×ÏÚ×ÒÁÔÁ × ÍÅÎÀ ÄÏËÕÍÅÎÔÁÃÉÉ. äÌÑ ×ÏÚ×ÒÁÔÁ × ÇÌÁ×ÎÏÅ ÍÅÎÀ ×ÙÂÅÒÉÔÅ Exit Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter.
÷ÙÂÏÒ ÍÅÎÀ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ (Keymap) äÌÑ ÉÚÍÅÎÅÎÉÑ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ ×ÙÂÅÒÉÔÅ ÉÚ ÍÅÎÀ Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ Keymap É ÎÁÖÍÉÔÅ Enter. üÔÏ ÐÏÔÒÅÂÕÅÔÓÑ ÔÏÌØËÏ ÐÒÉ ÉÓÐÏÌØÚÏ×ÁÎÉÉ ÎÅÓÔÁÎÄÁÒÔÎÏÊ ÉÌÉ ÎÅ-US ËÌÁ×ÉÁÔÕÒÙ.
÷ÙÂÏÒ ÍÅÎÀ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ
òÁÚÌÉÞÎÙÅ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ ÍÏÇÕÔ ÂÙÔØ ×ÙÂÒÁÎÙ ÉÚ ÍÅÎÀ Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ, ÚÁÔÅÍ ÓÌÅÄÕÅÔ ÎÁÖÁÔØ Space. îÁÖÁÔÉÅ Space ÅÝÅ ÒÁÚ ÐÒÉ×ÅÄÅÔ Ë ÏÔÍÅÎÅ ×ÙÂÏÒÁ. ëÏÇÄÁ ÎÅÏÂÈÏÄÉÍÙÅ ÒÁÓËÌÁÄËÉ ÂÕÄÕÔ ×ÙÂÒÁÎÙ, ÐÅÒÅÊÄÉÔÅ ÎÁ &gui.ok; Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter. îÁ ÜËÒÁÎ ×Ù×ÅÄÅÎÁ ÔÏÌØËÏ ÞÁÓÔØ ÓÐÉÓËÁ. îÁÖÁ× Tab, ÍÏÖÎÏ ×ÙÂÒÁÔØ &gui.cancel;, ×ÅÒÎÕÔØÓÑ Ë ÒÁÓËÌÁÄËÅ ÐÏ ÕÍÏÌÞÁÎÉÀ É ÐÅÒÅÊÔÉ Ë ÇÌÁ×ÎÏÍÕ ÍÅÎÀ.
íÅÎÀ ÒÁÓËÌÁÄËÉ ËÌÁ×ÉÁÔÕÒÙ
ðÁÒÁÍÅÔÒÙ ÕÓÔÁÎÏ×ËÉ (Options) ÷ÙÂÅÒÉÔÅ ÐÕÎËÔ Options É ÎÁÖÍÉÔÅ Enter.
÷ÙÂÏÒ ÐÁÒÁÍÅÔÒÏ× ÕÓÔÁÎÏ×ËÉ
ðÁÒÁÍÅÔÒÙ Sysinstall
ðÁÒÁÍÅÔÒÙ ÐÏ ÕÍÏÌÞÁÎÉÀ ÏÂÙÞÎÏ ÕÓÔÒÁÉ×ÁÀÔ ÂÏÌØÛÉÎÓÔ×Ï ÐÏÌØÚÏ×ÁÔÅÌÅÊ É ÎÅ ÎÕÖÄÁÀÔÓÑ × ÉÚÍÅÎÅÎÉÉ. éÍÑ ÒÅÌÉÚÁ ÚÁ×ÉÓÉÔ ÏÔ ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÏÊ ×ÅÒÓÉÉ. ïÐÉÓÁÎÉÅ ×ÙÂÒÁÎÎÏÇÏ ÐÕÎËÔÁ ÂÕÄÅÔ ÐÏÑ×ÌÑÔØÓÑ ×ÎÉÚÕ ÜËÒÁÎÁ Ó ÓÉÎÅÊ ÐÏÄÓ×ÅÔËÏÊ. ïÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ, ÞÔÏ ÏÄÉÎ ÉÚ ÐÁÒÁÍÅÔÒÏ× — Use Defaults, ÏÚÎÁÞÁÅÔ ÓÂÒÏÓ ×ÓÅÈ ÐÁÒÁÍÅÔÒÏ× Ë ÚÎÁÞÅÎÉÑÍ ÐÏ ÕÍÏÌÞÁÎÉÀ. îÁÖÁÔÉÅ F1 ÏÔÏÂÒÁÚÉÔ ÓÐÒÁ×ËÕ ÐÏ ÒÁÚÌÉÞÎÙÍ ÐÁÒÁÍÅÔÒÁÍ. îÁÖÁÔÉÅÍ Q ÍÏÖÎÏ ÐÅÒÅÊÔÉ Ë ÇÌÁ×ÎÏÍÕ ÍÅÎÀ.
îÁÞÁÌÏ ÓÔÁÎÄÁÒÔÎÏÊ ÕÓÔÁÎÏ×ËÉ (Standard) ðÕÎËÔ Standard ÒÅËÏÍÅÎÄÕÅÔÓÑ ÄÌÑ ÎÏ×ÙÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ &unix; ÉÌÉ &os;. éÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ ÐÕÎËÔÁ Standard, Á ÚÁÔÅÍ ÎÁÖÍÉÔÅ Enter ÄÌÑ ÚÁÐÕÓËÁ ÕÓÔÁÎÏ×ËÉ.
îÁÞÁÌÏ ÓÔÁÎÄÁÒÔÎÏÊ ÕÓÔÁÎÏ×ËÉ
÷ÙÄÅÌÅÎÉÅ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á ÷ÁÛÁ ÐÅÒ×ÁÑ ÚÁÄÁÞÁ — ×ÙÄÅÌÉÔØ ÄÉÓËÏ×ÏÅ ÐÒÏÓÔÒÁÎÓÔ×Ï ÐÏÄ &os; É ÒÁÚÍÅÔÉÔØ ÅÇÏ, ÞÔÏÂÙ sysinstall ÍÏÇÌÁ ÅÇÏ ÐÏÄÇÏÔÏ×ÉÔØ. äÌÑ ÜÔÏÇÏ ×ÁÍ ÎÕÖÎÏ ÚÎÁÔØ, ËÁË &os; ÉÝÅÔ ÉÎÆÏÒÍÁÃÉÀ ÎÁ ÄÉÓËÅ. îÕÍÅÒÁÃÉÑ ÄÉÓËÏ× × BIOS - ðÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ É ÎÁÓÔÒÏÊËÏÊ &os; - ÎÕÖÎÏ ÐÏÚÁÂÏÔÉÔØÓÑ ËÏÅ Ï ÞÅÍ, ÏÓÏÂÅÎÎÏ ÅÓÌÉ - ÖÅÓÔËÉÈ ÄÉÓËÏ× ÎÅÓËÏÌØËÏ. + ðÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ É ÎÁÓÔÒÏÊËÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ ÎÅÏÂÈÏÄÉÍÏ + ÚÎÁÔØ, ËÁË &os; ÔÒÁËÔÕÅÔ ÐÒÅÄÏÓÔÁ×ÌÑÅÍÕÀ ÓÉÓÔÅÍÏÊ BIOS ÉÎÆÏÒÍÁÃÉÀ + Ï ÄÉÓËÁÈ É ÉÈ ÉÍÅÎÏ×ÅÎÉÉ. MS-DOS Microsoft Windows ÷ PC, ÒÁÂÏÔÁÀÝÅÍ ÐÏÄ BIOS-ÚÁ×ÉÓÉÍÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ, ÔÁËÏÊ ËÁË &ms-dos; ÉÌÉ µsoft.windows;, BIOS ÍÏÖÅÔ ÏÔÈÏÄÉÔØ ÏÔ ÏÂÙÞÎÏÇÏ ÐÏÒÑÄËÁ ÎÕÍÅÒÁÃÉÉ ÄÉÓËÏ×. üÔÏ ÐÏÚ×ÏÌÑÅÔ ÐÏÌØÚÏ×ÁÔÅÌÀ ÚÁÇÒÕÖÁÔØÓÑ ÎÅ ÔÏÌØËÏ Ó ÔÁË - ÎÁÚÙ×ÁÅÍÏÇÏ primary master ÄÉÓËÁ. üÔÏ ÏÓÏÂÅÎÎÏ - ÕÄÏÂÎÏ ÄÌÑ ÔÅÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ, ËÔÏ ÏÂÎÁÒÕÖÉÌ, ÞÔÏ ÐÒÏÓÔÅÊÛÉÊ É ÓÁÍÙÊ - ÄÅÛÅ×ÙÊ ÐÕÔØ ÄÅÌÁÔØ ÒÅÚÅÒ×ÎÕÀ ËÏÐÉÀ ÓÉÓÔÅÍÙ — ËÕÐÉÔØ ×ÔÏÒÏÊ - ÉÄÅÎÔÉÞÎÙÊ ÐÅÒ×ÏÍÕ ÖÅÓÔËÉÊ ÄÉÓË É ÒÅÇÕÌÑÒÎÏ ÄÅÌÁÔØ ËÏÐÉÉ ÐÅÒ×ÏÇÏ - ÄÉÓËÁ ÎÁ ×ÔÏÒÏÊ, ÉÓÐÏÌØÚÕÑ - Ghost - ÉÌÉ XCOPY. úÁÔÅÍ, ÅÓÌÉ ÐÅÒ×ÙÊ ÄÉÓË ×ÙÊÄÅÔ ÉÚ + ÎÁÚÙ×ÁÅÍÏÇÏ "primary master" ÄÉÓËÁ. üÔÏ ÏÓÏÂÅÎÎÏ + ÕÄÏÂÎÏ ÄÌÑ ÔÅÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ, ËÏÔÏÒÙÅ ÐÏËÕÐÁÀÔ ×ÔÏÒÏÊ + ÉÄÅÎÔÉÞÎÙÊ ÐÅÒ×ÏÍÕ ÖÅÓÔËÉÊ ÄÉÓË É ÒÅÇÕÌÑÒÎÏ ÄÅÌÁÀÔ ËÏÐÉÉ ÐÅÒ×ÏÇÏ + ÄÉÓËÁ ÎÁ ×ÔÏÒÏÊ. úÁÔÅÍ, ÅÓÌÉ ÐÅÒ×ÙÊ ÄÉÓË ×ÙÊÄÅÔ ÉÚ ÓÔÒÏÑ, ÂÕÄÅÔ ÚÁÒÁÖÅÎ ×ÉÒÕÓÏÍ ÉÌÉ ÐÏ×ÒÅÖÄÅÎ ÉÚ-ÚÁ ÓÂÏÑ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ, ÏÎ ÍÏÖÅÔ ÂÙÔØ ÌÅÇËÏ ×ÏÓÓÔÁÎÏ×ÌÅÎ ÐÕÔÅÍ ÌÏÇÉÞÅÓËÏÊ ÐÅÒÅÓÔÁÎÏ×ËÉ ÄÉÓËÏ× × BIOS. üÔÏ ×ÓÅ ÒÁ×ÎÏ ÞÔÏ ÐÅÒÅËÌÀÞÉÔØ ËÁÂÅÌÉ ÄÉÓËÏ×, ÎÏ ÂÅÚ ×ÓËÒÙÔÉÑ ËÏÒÐÕÓÁ. SCSI BIOS âÏÌÅÅ ÄÏÒÏÇÏÓÔÏÑÝÉÅ ÓÉÓÔÅÍÙ ÓÏ SCSI ËÏÎÔÒÏÌÌÅÒÁÍÉ ÚÁÞÁÓÔÕÀ ÉÍÅÀÔ ÒÁÓÛÉÒÅÎÉÑ BIOS, ÐÏÚ×ÏÌÑÀÝÉÅ ÓÈÏÄÎÙÍ ÐÕÔÅÍ ÍÅÎÑÔØ ÐÏÒÑÄÏË ÄÏ ÓÅÍÉ SCSI ÄÉÓËÏ×. ðÏÌØÚÏ×ÁÔÅÌÉ, ÐÒÉ×ÙËÛÉÅ ÐÏÌØÚÏ×ÁÔØÓÑ ÜÔÉÍÉ ÐÏÌÅÚÎÙÍÉ ÆÕÎËÃÉÑÍÉ, ÍÏÇÕÔ ÂÙÔØ ÕÄÉ×ÌÅÎÙ, ÞÔÏ ×Ï &os; ÒÅÚÕÌØÔÁÔÙ ÎÅ ÓÏ×ÐÁÄÁÀÔ Ó ÏÖÉÄÁÅÍÙÍÉ. &os; ÎÅ ÉÓÐÏÌØÚÕÅÔ BIOS, É ÎÅ ÚÎÁÅÔ Ï ÌÏÇÉÞÅÓËÏÍ ÏÔÏÂÒÁÖÅÎÉÉ ÄÉÓËÏ× × BIOS. üÔÏ ÍÏÖÅÔ ÐÒÉ×ÅÓÔÉ Ë ÏÞÅÎØ ÓÌÏÖÎÙÍ ÓÉÔÕÁÃÉÑÍ, ÏÓÏÂÅÎÎÏ ËÏÇÄÁ ÄÉÓËÉ ÉÍÅÀÔ ÏÄÉÎÁËÏ×ÕÀ ÇÅÏÍÅÔÒÉÀ É ÓÏÄÅÒÖÁÔ ÔÏÞÎÕÀ ËÏÐÉÀ ÄÁÎÎÙÈ ÄÒÕÇ ÄÒÕÇÁ. ðÒÉ ÉÓÐÏÌØÚÏ×ÁÎÉÉ &os; ×ÓÅÇÄÁ ×ÏÓÓÔÁÎÁ×ÌÉ×ÁÊÔÅ ÎÁÓÔÒÏÊËÉ BIOS Ë ÐÅÒ×ÏÎÁÞÁÌØÎÏÊ ÎÕÍÅÒÁÃÉÉ ÐÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ ÓÉÓÔÅÍÙ É ÏÓÔÁ×ÌÑÊÔÅ ÉÈ × ÔÁËÏÍ ×ÉÄÅ. åÓÌÉ ×ÁÍ ÐÏÎÁÄÏÂÉÔÓÑ ÐÅÒÅËÌÀÞÉÔØ ÄÉÓËÉ, ÓÄÅÌÁÊÔÅ ÜÔÏ, ÎÏ ÐÕÔÅÍ ÆÉÚÉÞÅÓËÏÇÏ ÐÅÒÅËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÑ, ×ÓËÒÙ× ËÏÒÐÕÓ, ÐÅÒÅËÌÀÞÉ× ÐÅÒÅÍÙÞËÉ É ËÁÂÅÌÉ. òÁÓÓËÁÚ Ï ÎÅÏÂÙËÎÏ×ÅÎÎÙÈ ÐÒÉËÌÀÞÅÎÉÑÈ ÆÁÊÌÏ× âÉÌÌÁ É æÒÅÄÁ: âÉÌÌ ÒÁÚÏÂÒÁÌ ÓÔÁÒÙÊ Wintel ËÏÍÐØÀÔÅÒ, ÞÔÏÂÙ ÓÄÅÌÁÔØ ÅÝÅ ÏÄÉÎ ËÏÍÐØÀÔÅÒ ÐÏÄ &os; ÄÌÑ æÒÅÄÁ. âÉÌÌ ÕÓÔÁÎÏ×ÉÌ ÏÄÉÎ SCSI ÄÉÓË ËÁË ÎÕÌÅ×ÏÅ ÕÓÔÒÏÊÓÔ×Ï SCSI É ÐÏÓÔÁ×ÉÌ ÎÁ ÎÅÇÏ &os;. æÒÅÄ ÎÁÞÁÌ ÉÓÐÏÌØÚÏ×ÁÔØ ÓÉÓÔÅÍÕ, ÎÏ ÞÅÒÅÚ ÎÅÓËÏÌØËÏ ÄÎÅÊ ÏÂÎÁÒÕÖÉÌ, ÞÔÏ ÓÔÁÒÙÊ SCSI ÄÉÓË ÓÏÏÂÝÁÅÔ Ï ÍÎÏÖÅÓÔ×Å ÓÂÏÅ× É ÓËÁÚÁÌ Ï ÜÔÏÍ âÉÌÌÕ. åÝÅ ÞÅÒÅÚ ÎÅÓËÏÌØËÏ ÄÎÅÊ âÉÌÌ ÒÅÛÉÌ, ÞÔÏ ÎÁÓÔÁÌÏ ×ÒÅÍÑ ÒÅÛÉÔØ ÐÒÏÂÌÅÍÕ, É ÄÏÓÔÁÌ ÔÁËÏÊ ÖÅ SCSI ÄÉÓË ÉÚ ÚÁÎÁÞËÉ × ËÌÁÄÏ×ËÅ. ðÅÒ×ÁÑ ÐÒÏ×ÅÒËÁ ÐÏ×ÅÒÈÎÏÓÔÉ ÐÏËÁÚÁÌÁ, ÞÔÏ ÄÉÓË ÒÁÂÏÔÁÅÔ ÎÏÒÍÁÌØÎÏ; âÉÌÌ ÕÓÔÁÎÏ×ÉÌ ÜÔÏÔ ÄÉÓË ËÁË ÞÅÔ×ÅÒÔÏÅ ÕÓÔÒÏÊÓÔ×Ï SCSI É ÓËÏÐÉÒÏ×ÁÌ ÏÂÒÁÚ ÄÉÓËÁ Ó ÎÕÌÅ×ÏÇÏ ÕÓÔÒÏÊÓÔ×Á ÎÁ ÞÅÔ×ÅÒÔÏÅ. ôÅÐÅÒØ, ËÏÇÄÁ ÎÏ×ÙÊ ÄÉÓË ÂÙÌ ÕÓÔÁÎÏ×ÌÅÎ É ÏÔÌÉÞÎÏ ÒÁÂÏÔÁÌ, âÉÌÌ ÒÅÛÉÌ ÞÔÏ ÎÅÐÌÏÈÏ ÂÙ ÎÁÞÁÔØ ÉÓÐÏÌØÚÏ×ÁÔØ ÅÇÏ, É Ó ÐÏÍÏÝØÀ ÆÕÎËÃÉÉ SCSI BIOS ÐÏÍÅÎÑÌ ÐÏÒÑÄÏË ÄÉÓËÏ×, ÞÔÏÂÙ ÓÉÓÔÅÍÁ ÍÏÇÌÁ ÇÒÕÚÉÔØÓÑ Ó ÞÅÔ×ÅÒÔÏÇÏ ÕÓÔÒÏÊÓÔ×Á SCSI. &os; ÚÁÇÒÕÚÉÌÁÓØ É ÒÁÂÏÔÁÌÁ ÂÅÚ ÐÒÏÂÌÅÍ. æÒÅÄ ÐÏÒÁÂÏÔÁÌ ÅÝÅ ÎÅÓËÏÌØËÏ ÄÎÅÊ, É ÓËÏÒÏ ÏÎÉ Ó âÉÌÌÏÍ ÒÅÛÉÌÉ, ÞÔÏ ÎÁÓÔÁÌÏ ×ÒÅÍÑ ÄÌÑ ÎÏ×ÏÇÏ ÐÒÉËÌÀÞÅÎÉÑ — ×ÒÅÍÑ ÏÂÎÏ×ÉÔØ ×ÅÒÓÉÀ &os;. âÉÌÌ ÕÄÁÌÉÌ ÎÕÌÅ×ÏÅ ÕÓÔÒÏÊÓÔ×Ï SCSI, ÐÏÔÏÍÕ ÞÔÏ ÏÎÏ ÐÏÄÇÌÀÞÉ×ÁÌÏ, É ÕÓÔÁÎÏ×ÉÌ ÎÁ ÅÇÏ ÍÅÓÔÏ ÔÁËÏÊ ÖÅ ÄÉÓË ÉÚ ÚÁÎÁÞËÉ. úÁÔÅÍ âÉÌÌ ÕÓÔÁÎÏ×ÉÌ ÎÏ×ÕÀ ×ÅÒÓÉÀ &os; ÎÁ ÎÏ×ÏÅ ÎÕÌÅ×ÏÅ ÕÓÔÒÏÊÓÔ×Ï SCSI ÉÓÐÏÌØÚÕÑ ÄÉÓËÅÔÙ æÒÅÄÁ Ó ÉÎÔÅÒÎÅÔ ÓÅÒ×ÅÒÁ FTP. õÓÔÁÎÏ×ËÁ ÐÒÏÛÌÁ ÏÔÌÉÞÎÏ. æÒÅÄ ÉÓÐÏÌØÚÏ×ÁÌ ÎÏ×ÕÀ ×ÅÒÓÉÀ &os; ÎÅÓËÏÌØËÏ ÄÎÅÊ É ÕÄÏÓÔÏ×ÅÒÉÌÓÑ, ÞÔÏ ÏÎÁ ×ÐÏÌÎÅ ÐÏÄÈÏÄÉÔ ÄÌÑ ÒÁÂÏÔÙ × ÉÎÖÅÎÅÒÎÏÍ ÏÔÄÅÌÅ. îÁÓÔÁÌÏ ×ÒÅÍÑ ÓËÏÐÉÒÏ×ÁÔØ ×ÓÅ ÁÒÈÉ×Ù ÓÏ ÓÔÁÒÏÇÏ ÄÉÓËÁ. æÒÅÄ ÓÍÏÎÔÉÒÏ×ÁÌ ÞÅÔ×ÅÒÔÏÅ ÕÓÔÒÏÊÓÔ×Ï SCSI (ÐÏÓÌÅÄÎÀÀ ËÏÐÉÀ ÓÔÁÒÏÊ ×ÅÒÓÉÉ &os;) É ÏÂÎÁÒÕÖÉÌ, ÞÔÏ ÎÉ ÏÄÎÏÇÏ ÉÚ ÅÇÏ ÄÒÁÇÏÃÅÎÎÙÈ ÆÁÊÌÏ× ÎÁ ÞÅÔ×ÅÒÔÏÍ ÕÓÔÒÏÊÓÔ×Å SCSI ÎÅÔ. ëÕÄÁ ÄÅÌÉÓØ ÄÁÎÎÙÅ? ëÏÇÄÁ âÉÌÌ ÓÄÅÌÁÌ ËÏÐÉÀ Ó ÎÕÌÅ×ÏÇÏ ÕÓÔÒÏÊÓÔ×Á SCSI ÎÁ ÞÅÔ×ÅÒÔÏÅ ÕÓÔÒÏÊÓÔ×Ï SCSI, ÏÎÏ ÓÔÁÌÏ ËÌÏÎÏÍ. ëÏÇÄÁ âÉÌÌ ÐÏÍÅÎÑÌ ÎÁÓÔÒÏÊËÉ SCSI BIOS, ÞÔÏÂÙ ÚÁÇÒÕÚÉÔØÓÑ Ó ÞÅÔ×ÅÒÔÏÇÏ ÕÓÔÒÏÊÓÔ×Á SCSI, ÏÎ ×ÓÅÇÏ ÌÉÛØ ÏÂÍÁÎÕÌ ÓÁÍ ÓÅÂÑ. &os; ×ÓÅ ÅÝÅ ÒÁÂÏÔÁÌÁ Ó ÎÕÌÅ×ÏÇÏ ÕÓÔÒÏÊÓÔ×Á SCSI. éÚÍÅÎÅÎÉÅ ÜÔÉÈ ÎÁÓÔÒÏÅË BIOS ÐÒÉ×ÅÌÏ Ë ÚÁÇÒÕÚËÅ ÞÁÓÔÉ ËÏÄÁ Boot É Loader Ó ×ÙÂÒÁÎÎÏÇÏ × BIOS ÄÉÓËÁ, ÎÏ ÐÏÓÌÅ ÚÁÇÒÕÚËÉ ÄÒÁÊ×ÅÒÏ× &os; ÎÁÓÔÒÏÊËÉ BIOS ÂÙÌÉ ÐÒÏÉÇÎÏÒÉÒÏ×ÁÎÙ, É &os; ×ÅÒÎÕÌÁÓØ Ë ÎÏÒÍÁÌØÎÏÊ ÎÕÍÅÒÁÃÉÉ. ëÁË ÐÏËÁÚÁÎÏ ÎÁ ÐÁÌØÃÁÈ, ÓÉÓÔÅÍÁ ÐÒÏÄÏÌÖÉÌÁ ÒÁÂÏÔÁÔØ Ó ÎÕÌÅ×ÙÍ ÕÓÔÒÏÊÓÔ×ÏÍ SCSI, É ×ÓÅ ÄÁÎÎÙÅ æÒÅÄÁ ÏÓÔÁÌÉÓØ ÔÁÍ, Á ÎÅ ÎÁ ÞÅÔ×ÅÒÔÏÍ ÕÓÔÒÏÊÓÔ×Å SCSI. ôÏ, ÞÔÏ ÓÉÓÔÅÍÁ ÇÒÕÚÉÌÁÓØ Ó ÞÅÔ×ÅÒÔÏÇÏ ÕÓÔÒÏÊÓÔ×Á SCSI, ÂÙÌÏ ×ÓÅÇÏ ÌÉÛØ ÏÂÍÁÎÕÔÙÍÉ ÏÖÉÄÁÎÉÑÍÉ. íÙ ÒÁÄÙ ÕÐÏÍÑÎÕÔØ, ÞÔÏ ÄÁÎÎÙÅ ÎÅ ÂÙÌÉ ÕÎÉÞÔÏÖÅÎÙ ÉÌÉ ÐÏ×ÒÅÖÄÅÎÙ ÐÒÉ ÎÁÛÅÍ ÉÓÓÌÅÄÏ×ÁÎÉÉ ÜÔÏÇÏ ÆÅÎÏÍÅÎÁ. óÔÁÒÏÅ ÎÕÌÅ×ÏÅ ÕÓÔÒÏÊÓÔ×Ï SCSI ÂÙÌÏ ×ÙÔÁÝÅÎÏ ÉÚ ÇÒÕÄÙ ÖÅÌÅÚÁ, É ×ÓÅ ÆÁÊÌÙ æÒÅÄÁ ×ÅÒÎÕÌÉÓØ Ë ÎÅÍÕ. èÏÔÑ × ÜÔÏÍ ÒÁÓÓËÁÚÅ ÂÙÌÉ ÉÓÐÏÌØÚÏ×ÁÎÙ SCSI ÄÉÓËÉ, Ó IDE ÄÉÓËÁÍÉ ×ÓÅ ÔÏÞÎÏ ÔÁË ÖÅ. óÏÚÄÁÎÉÅ ÓÌÁÊÓÏ× Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ FDisk ÷ÎÅÓÅÎÎÙÅ ×ÁÍÉ ÉÚÍÅÎÅÎÉÑ ÎÅ ÂÕÄÕÔ ÚÁÐÉÓÙ×ÁÔØÓÑ ÎÁ ÄÉÓË ÓÒÁÚÕ. åÓÌÉ ×Ù ÄÕÍÁÅÔÅ, ÞÔÏ ÓÄÅÌÁÌÉ ÏÛÉÂËÕ, É ÈÏÔÉÔÅ ÎÁÞÁÔØ ÓÎÁÞÁÌÁ, ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÍÅÎÀ ÄÌÑ ×ÙÈÏÄÁ ÉÚ sysinstall É ÐÏÐÒÏÂÏ×ÁÔØ ÅÝÅ ÒÁÚ ÉÌÉ ÎÁÖÁÔÉÅÍ U ×ÙÚ×ÁÔØ ÏÐÃÉÀ Undo (ÏÔÍÅÎÁ). åÓÌÉ ×Ù ÚÁÐÕÔÁÌÉÓØ É ÎÅ ÍÏÖÅÔÅ ×ÙÊÔÉ, ÐÒÏÓÔÏ ×ÙËÌÀÞÉÔÅ ËÏÍÐØÀÔÅÒ. ðÏÓÌÅ ÎÁÞÁÌÁ ÓÔÁÎÄÁÒÔÎÏÊ ÕÓÔÁÎÏ×ËÉ × sysinstall ÂÕÄÅÔ ÐÏËÁÚÁÎÏ ÜÔÏ ÓÏÏÂÝÅÎÉÅ: Message In the next menu, you will need to set up a DOS-style ("fdisk") partitioning scheme for your hard disk. If you simply wish to devote all disk space to FreeBSD (overwriting anything else that might be on the disk(s) selected) then use the (A)ll command to select the default partitioning scheme followed by a (Q)uit. If you wish to allocate only free space to FreeBSD, move to a partition marked "unused" and use the (C)reate command. [ OK ] [ Press enter or space ] îÁÖÍÉÔÅ Enter ËÁË ÐÒÅÄÌÁÇÁÅÔÓÑ. âÕÄÅÔ ÐÏËÁÚÁÎ ÓÐÉÓÏË ×ÓÅÈ ÖÅÓÔËÉÈ ÄÉÓËÏ×, ÏÂÎÁÒÕÖÅÎÎÙÈ ÑÄÒÏÍ ×Ï ×ÒÅÍÑ ÔÅÓÔÉÒÏ×ÁÎÉÑ ÕÓÔÒÏÊÓÔ×. ÐÏËÁÚÙ×ÁÅÔ ÐÒÉÍÅÒ ÓÉÓÔÅÍÙ Ó Ä×ÕÍÑ IDE ÄÉÓËÁÍÉ. ïÎÉ ÂÙÌÉ ÎÁÚ×ÁÎÙ ad0 É ad2.
÷ÙÂÅÒÉÔÅ ÄÉÓË ÄÌÑ FDisk
÷Ù ÍÏÖÅÔÅ ÂÙÔØ ÕÄÉ×ÌÅÎÙ, ÐÏÞÅÍÕ ÕÓÔÒÏÊÓÔ×Á ad1 ÚÄÅÓØ ÎÅÔ. ðÏÞÅÍÕ ÏÎÏ ÂÙÌÏ ÐÒÏÐÕÝÅÎÏ? ðÒÅÄÐÏÌÏÖÉÍ, ÞÔÏ Õ ×ÁÓ ÅÓÔØ Ä×Á ÖÅÓÔËÉÈ ÄÉÓËÁ IDE, ÏÄÉÎ master ÎÁ ÐÅÒ×ÏÍ ËÏÎÔÒÏÌÌÅÒÅ IDE, Á ×ÔÏÒÏÊ master ÎÁ ×ÔÏÒÏÍ ËÏÎÔÒÏÌÌÅÒÅ IDE. åÓÌÉ &os; ÐÒÏÎÕÍÅÒÕÅÔ ÉÈ × ÔÏÍ ÐÏÒÑÄËÅ, × ËÏÔÏÒÏÍ ÎÁÛÌÁ, ad0 É ad1, ×ÓÅ ÂÕÄÅÔ ÒÁÂÏÔÁÔØ. îÏ ÅÓÌÉ ×Ù ÄÏÂÁ×ÉÔÅ ÔÒÅÔÉÊ ÄÉÓË, ËÁË slave ÕÓÔÒÏÊÓÔ×Ï ÎÁ ÐÅÒ×ÙÊ ËÏÎÔÒÏÌÌÅÒ IDE, ÏÎ ÓÔÁÎÅÔ ad1, Á ÐÒÅÄÙÄÕÝÉÊ ad1 ÓÔÁÎÅÔ ad2. ðÏÓËÏÌØËÕ ÉÍÅÎÁ ÕÓÔÒÏÊÓÔ× (ÔÁËÉÈ ËÁË ad1s1a) ÉÓÐÏÌØÚÕÀÔÓÑ ÄÌÑ ÏÂÒÁÝÅÎÉÑ Ë ÆÁÊÌÏ×ÙÍ ÓÉÓÔÅÍÁÍ, ×Ù ÍÏÖÅÔÅ ×ÄÒÕÇ ÏÂÎÁÒÕÖÉÔØ, ÞÔÏ ÎÅËÏÔÏÒÙÅ ÉÚ ×ÁÛÉÈ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ ÂÏÌØÛÅ ÎÅ ÏÔÏÂÒÁÖÁÀÔÓÑ ÐÒÁ×ÉÌØÎÏ É ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÉÚÍÅÎÉÔØ ËÏÎÆÉÇÕÒÁÃÉÀ &os;. äÌÑ ÏÂÈÏÄÁ ÜÔÏÊ ÐÒÏÂÌÅÍÙ, ÑÄÒÏ ÍÏÖÅÔ ÂÙÔØ ÎÁÓÔÒÏÅÎÏ ÔÁË, ÞÔÏÂÙ ÉÍÅÎÏ×ÁÔØ IDE ÄÉÓËÉ ÎÁ ÏÓÎÏ×Å ÉÈ ÍÅÓÔÏÐÏÌÏÖÅÎÉÑ, Á ÎÅ ÐÏÒÑÄËÁ, × ËÏÔÏÒÏÍ ÏÎÉ ÂÙÌÉ ÎÁÊÄÅÎÙ. ó ÜÔÏÊ ÓÈÅÍÏÊ master ÄÉÓË ÎÁ ×ÔÏÒÏÍ ËÏÎÔÒÏÌÌÅÒÅ IDE ÂÕÄÅÔ ×ÓÅÇÄÁ ÕÓÔÒÏÊÓÔ×ÏÍ ad2, ÅÓÌÉ ÄÁÖÅ ÎÅÔ ÕÓÔÒÏÊÓÔ× ad0 ÉÌÉ ad1. üÔÏ ËÏÎÆÉÇÕÒÁÃÉÑ ÑÄÒÁ &os; ÐÏ ÕÍÏÌÞÁÎÉÀ, ÐÏÜÔÏÍÕ ÎÁ ÜËÒÁÎÅ ÐÏËÁÚÁÎÙ ad0 É ad2. õ ËÏÍÐØÀÔÅÒÁ, Ó ËÏÔÏÒÏÇÏ ÂÙÌ ×ÚÑÔ ÜÔÏÔ ÓÎÉÍÏË ÜËÒÁÎÁ, ÅÓÔØ ÐÏ ÏÄÎÏÍÕ IDE ÄÉÓËÕ ÎÁ ÏÂÅÉÈ master ËÁÎÁÌÁÈ IDE ËÏÎÔÒÏÌÌÅÒÏ× É ÎÉ ÏÄÎÏÇÏ ÄÉÓËÁ ÎÁ ËÁÎÁÌÁÈ slave. ÷Ù ÄÏÌÖÎÙ ×ÙÂÒÁÔØ ÄÉÓË, ÎÁ ËÏÔÏÒÙÊ ÈÏÔÉÔÅ ÕÓÔÁÎÏ×ÉÔØ &os;, É ÎÁÖÁÔØ &gui.ok;. úÁÐÕÓÔÉ×ÛÉÊÓÑ FDisk ÂÕÄÅÔ ×ÙÇÌÑÄÅÔØ ÐÒÉÍÅÒÎÏ ËÁË . üËÒÁÎ FDisk ÒÁÚÂÉÔ ÎÁ ÔÒÉ ÒÁÚÄÅÌÁ. ðÅÒ×ÙÊ ÒÁÚÄÅÌ, ÚÁÎÉÍÁÀÝÁÑ ÐÅÒ×ÙÅ Ä×Å ÌÉÎÉÉ ÜËÒÁÎÁ, ÐÏËÁÚÙ×ÁÅÔ ÐÏÄÒÏÂÎÕÀ ÉÎÆÏÒÍÁÃÉÀ Ï ×ÙÂÒÁÎÎÏÍ × ÄÁÎÎÙÊ ÍÏÍÅÎÔ ÄÉÓËÅ, ×ËÌÀÞÁÑ ÅÇÏ ÉÍÑ ×Ï &os;, ÇÅÏÍÅÔÒÉÀ É ÏÂÝÉÊ ÒÁÚÍÅÒ ÄÉÓËÁ. ÷ÔÏÒÏÊ ÒÁÚÄÅÌ ÐÏËÁÚÙ×ÁÅÔ ÉÍÅÀÝÉÅÓÑ × ÄÁÎÎÙÊ ÍÏÍÅÎÔ ÎÁ ÄÉÓËÅ ÓÌÁÊÓÙ, ÇÄÅ ÏÎÉ ÎÁÞÉÎÁÀÔÓÑ É ÚÁËÁÎÞÉ×ÁÀÔÓÑ, ÉÈ ÒÁÚÍÅÒ, ÉÍÑ, ËÏÔÏÒÏÅ ÉÍ ÄÁÌÁ &os;, ÏÐÉÓÁÎÉÅ É ÐÏÄÔÉÐ. îÁ ÜÔÏÍ ÐÒÉÍÅÒÅ ÐÏËÁÚÁÎÙ Ä×Á ÍÁÌÅÎØËÉÈ ÎÅÉÓÐÏÌØÚÏ×ÁÎÎÙÈ ÓÌÁÊÓÁ, ËÏÔÏÒÙÅ Ñ×ÌÑÀÔÓÑ ÁÒÔÅÆÁËÔÁÍÉ ÓÈÅÍÙ ÒÁÚÍÅÔËÉ ÄÉÓËÁ ÎÁ PC. ôÁËÖÅ ÐÏËÁÚÁÎ ÏÄÉÎ ÂÏÌØÛÏÊ FAT ÓÌÁÊÓ, ËÏÔÏÒÙÊ ÐÏÞÔÉ ×ÓÅÇÄÁ Ñ×ÌÑÅÔÓÑ ÄÉÓËÏÍ C: × &ms-dos; / &windows;, É ÄÏÐÏÌÎÉÔÅÌØÎÙÊ ÓÌÁÊÓ, ËÏÔÏÒÙÊ ÍÏÖÅÔ ÓÏÄÅÒÖÁÔØ ÄÉÓËÉ Ó ÄÒÕÇÉÍÉ ÂÕË×ÁÍÉ ÄÌÑ &ms-dos; / &windows;. ôÒÅÔÉÊ ÒÁÚÄÅÌ ÐÏËÁÚÙ×ÁÅÔ ËÏÍÁÎÄÙ, ÄÏÓÔÕÐÎÙÅ × FDisk.
ôÉÐÉÞÎÙÅ ÒÁÚÄÅÌÙ <command>fdisk</command> ÐÅÒÅÄ ÒÅÄÁËÔÉÒÏ×ÁÎÉÅÍ
÷ÁÛÉ ÄÅÊÓÔ×ÉÑ ÔÅÐÅÒØ ÂÕÄÕÔ ÚÁ×ÉÓÅÔØ ÏÔ ÔÏÇÏ, ËÁË ×Ù ÈÏÔÉÔÅ ÒÁÚÂÉÔØ ÄÉÓË ÎÁ ÓÌÁÊÓÙ. åÓÌÉ ×Ù ÈÏÔÉÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÌÑ &os; ×ÅÓØ ÄÉÓË (ÜÔÏ ÐÒÉ×ÅÄÅÔ Ë ÕÄÁÌÅÎÉÀ ×ÓÅÈ ÄÒÕÇÉÈ ÄÁÎÎÙÈ ÎÁ ÜÔÏÍ ÄÉÓËÅ ËÏÇÄÁ ×Ù ÐÏÄÔ×ÅÒÄÉÔÅ sysinstall ÐÒÏÄÏÌÖÅÎÉÅ ÐÒÏÃÅÓÓÁ ÕÓÔÁÎÏ×ËÉ), ÎÁÖÍÉÔÅ A, ÞÔÏ ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ ÏÐÃÉÉ éÓÐÏÌØÚÏ×ÁÔØ ×ÅÓØ ÄÉÓË (Use Entire Disk). óÕÝÅÓÔ×ÕÀÝÉÅ ÓÌÁÊÓÙ ÂÕÄÕÔ ÕÄÁÌÅÎÙ, É ÚÁÍÅÎÅÎÙ ÎÁ ÎÅÂÏÌØÛÕÀ ÏÂÌÁÓÔØ, ÐÏÍÅÞÅÎÎÕÀ ËÁË ÎÅÉÓÐÏÌØÚÕÅÍÁÑ (unused) (ÜÔÏ ÏÐÑÔØ ÖÅ ÁÒÔÅÆÁËÔ ÒÁÚÍÅÔËÉ ÄÉÓËÁ ðë), É ÏÄÉÎ ÂÏÌØÛÏÊ ÓÌÁÊÓ ÄÌÑ &os;. ëÏÇÄÁ ×Ù ÓÄÅÌÁÅÔÅ ÜÔÏ, ÎÕÖÎÏ ×ÙÂÒÁÔØ ×ÎÏר ÓÏÚÄÁÎÎÙÊ ÓÌÁÊÓ &os; ÉÓÐÏÌØÚÕÑ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ, Á ÚÁÔÅÍ ÎÁÖÁÔØ S, ÞÔÏÂÙ ÓÄÅÌÁÔØ ÓÌÁÊÓ ÚÁÇÒÕÚÏÞÎÙÍ. üËÒÁÎ ÂÕÄÅÔ ÐÏÈÏÖ ÎÁ . ïÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ, ÞÔÏ A × ËÏÌÏÎËÅ Flags ÏÚÎÁÞÁÅÔ, ÞÔÏ ÓÌÁÊÓ ÁËÔÉ×ÅÎ É Ó ÎÅÇÏ ÂÕÄÅÔ ÐÒÏÉÓÈÏÄÉÔØ ÚÁÇÒÕÚËÁ. åÓÌÉ ×Ù ÂÕÄÅÔÅ ÕÄÁÌÑÔØ ÓÕÝÅÓÔ×ÕÀÝÉÊ ÓÌÁÊÓ ÄÌÑ ÏÓ×ÏÂÏÖÄÅÎÉÑ ÍÅÓÔÁ ÐÏÄ &os;, ×ÙÂÅÒÉÔÅ ÓÌÁÊÓ, ÉÓÐÏÌØÚÕÑ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ, É ÎÁÖÍÉÔÅ D. úÁÔÅÍ ÍÏÖÅÔÅ ÎÁÖÁÔØ C, É ÐÏÌÕÞÉÔØ ÐÒÉÇÌÁÛÅÎÉÅ ÎÁ ××ÏÄ ÒÁÚÍÅÒÁ ÓÌÁÊÓÁ, ËÏÔÏÒÙÊ ×Ù ÈÏÔÉÔÅ ÓÏÚÄÁÔØ. ÷×ÅÄÉÔÅ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÅ ÚÎÁÞÅÎÉÅ É ÎÁÖÍÉÔÅ Enter. úÎÁÞÅÎÉÅ ÐÏ ÕÍÏÌÞÁÎÉÀ × ÜÔÏÍ ÐÏÌÅ ÏÚÎÁÞÁÅÔ ÎÁÉÂÏÌØÛÉÊ ÒÁÚÍÅÒ ÓÌÁÊÓÁ, ËÏÔÏÒÙÊ ÍÏÖÅÔ ÂÙÔØ ×ÙÂÒÁÎ; ÜÔÏ ÍÏÖÅÔ ÂÙÔØ ÎÁÉÂÏÌØÛÉÊ ÎÅÐÒÅÒÙ×ÎÙÊ ÂÌÏË ÎÅÒÁÚÍÅÞÅÎÎÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á ÉÌÉ ÒÁÚÍÅÒ ×ÓÅÇÏ ÖÅÓÔËÏÇÏ ÄÉÓËÁ. - åÓÌÉ ×Ù ÕÖÅ ÏÓ×ÏÂÏÄÉÌÉ ÍÅÓÔÏ ÄÌÑ &os; (×ÏÚÍÏÖÎÏ, ÉÓÐÏÌØÚÕÑ - ÕÔÉÌÉÔÕ ×ÒÏÄÅ &partitionmagic;), + åÓÌÉ ×Ù ÕÖÅ ÏÓ×ÏÂÏÄÉÌÉ ÍÅÓÔÏ ÄÌÑ &os;, ÔÏ ÍÏÖÅÔÅ ÎÁÖÁÔØ C ÄÌÑ ÓÏÚÄÁÎÉÑ ÎÏ×ÏÇÏ ÓÌÁÊÓÁ. âÕÄÅÔ ÔÁËÖÅ ÐÒÅÄÌÏÖÅÎÏ ××ÅÓÔÉ ÒÁÚÍÅÒ ÓÌÁÊÓÁ, ËÏÔÏÒÙÊ ×Ù ÈÏÔÉÔÅ ÓÏÚÄÁÔØ.
òÁÚÂÉÅÎÉÅ × Fdisk Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ ×ÓÅÇÏ ÄÉÓËÁ
ëÏÇÄÁ ÚÁËÏÎÞÉÔÅ, ÎÁÖÍÉÔÅ Q. éÚÍÅÎÅÎÉÑ ÂÕÄÕÔ ÓÏÈÒÁÎÅÎÙ × sysinstall, ÎÏ ÅÝÅ ÎÅ ÚÁÐÉÓÁÎÙ ÎÁ ÄÉÓË.
õÓÔÁÎÏ×ËÁ ÍÅÎÅÄÖÅÒÁ ÚÁÇÒÕÚËÉ (Boot Manager) ôÅÐÅÒØ ×ÁÍ ÐÒÅÄÌÁÇÁÅÔÓÑ ÕÓÔÁÎÏ×ÉÔØ ÍÅÎÅÄÖÅÒ ÚÁÇÒÕÚËÉ. ëÁË ÐÒÁ×ÉÌÏ, ÎÕÖÎÏ ×ÙÂÒÁÔØ ÕÓÔÁÎÏ×ËÕ ÍÅÎÅÄÖÅÒÁ ÚÁÇÒÕÚËÉ ÅÓÌÉ: õ ×ÁÓ ÂÏÌØÛÅ ÞÅÍ ÏÄÉÎ ÄÉÓË É ×Ù ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÅ &os; ÎÅ ÎÁ ÐÅÒ×ÙÊ ÄÉÓË. ÷Ù ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÅ &os; ×ÍÅÓÔÅ Ó ÄÒÕÇÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÎÁ ÏÄÉÎ É ÔÏÔ ÖÅ ÄÉÓË, É ÈÏÔÉÔÅ ×ÙÂÉÒÁÔØ ÐÒÉ ÚÁÇÒÕÚËÅ &os; ÉÌÉ ÄÒÕÇÕÀ ÏÐÅÒÁÃÉÏÎÎÕÀ ÓÉÓÔÅÍÕ. åÓÌÉ &os; ÅÄÉÎÓÔ×ÅÎÎÁÑ ÏÐÅÒÁÃÉÏÎÎÁÑ ÓÉÓÔÅÍÁ, ÕÓÔÁÎÏ×ÌÅÎÎÁÑ ÎÁ ÜÔÏÍ ËÏÍÐØÀÔÅÒÅ, É ÎÁÈÏÄÉÔÓÑ ÎÁ ÐÅÒ×ÏÍ ÖÅÓÔËÏÍ ÄÉÓËÅ, ÐÏÄÏÊÄÅÔ ÍÅÎÅÄÖÅÒ ÚÁÇÒÕÚËÉ Standard. ÷ÙÂÅÒÉÔÅ None ÅÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ ÍÅÎÅÄÖÅÒ ÚÁÇÒÕÚËÉ ÓÔÏÒÏÎÎÉÈ ÒÁÚÒÁÂÏÔÞÉËÏ×, ÓÐÏÓÏÂÎÙÊ ÚÁÇÒÕÚÉÔØ &os;. óÄÅÌÁÊÔÅ ×ÙÂÏÒ É ÎÁÖÍÉÔÅ Enter.
íÅÎÀ ÍÅÎÅÄÖÅÒÁ ÚÁÇÒÕÚËÉ Sysinstall
üËÒÁÎ ÐÏÄÓËÁÚËÉ, ×ÙÚÙ×ÁÅÍÙÊ ÐÏ ÎÁÖÁÔÉÀ F1, ÏÐÉÓÙ×ÁÅÔ ÐÒÏÂÌÅÍÙ, ËÏÔÏÒÙÅ ÍÏÇÕÔ ÂÙÔØ ×ÓÔÒÅÞÅÎÙ ÐÒÉ ÐÏÐÙÔËÅ ÓÏ×ÍÅÓÔÎÏÇÏ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÄÉÓËÁ ÏÐÅÒÁÃÉÏÎÎÙÍÉ ÓÉÓÔÅÍÁÍÉ.
óÏÚÄÁÎÉÅ ÓÌÁÊÓÏ× ÎÁ ÄÒÕÇÏÍ ÄÉÓËÅ åÓÌÉ ÄÉÓËÏ× ÂÏÌØÛÅ ÞÅÍ ÏÄÉÎ, ×ÅÒÎÉÔÅÓØ Ë ÜËÒÁÎÕ ×ÙÂÏÒÁ ÄÉÓËÏ× (Select Drives) ÐÏÓÌÅ ×ÙÂÏÒÁ ÍÅÎÅÄÖÅÒÁ ÚÁÇÒÕÚËÉ. åÓÌÉ ×Ù ÓÏÂÉÒÁÅÔÅÓØ ÕÓÔÁÎÁ×ÌÉ×ÁÔØ &os; ÂÏÌÅÅ ÞÅÍ ÎÁ ÏÄÉÎ ÄÉÓË, ÍÏÖÅÔÅ ×ÙÂÒÁÔØ ÄÒÕÇÏÊ ÄÉÓË É ÐÏ×ÔÏÒÉÔØ ÐÒÏÃÅÓÓ ÒÁÚÂÉÅÎÉÑ ÎÁ ÓÌÁÊÓÙ Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ FDisk. åÓÌÉ ×Ù ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÅ &os; ÎÅ ÎÁ ÐÅÒ×ÙÊ ÖÅÓÔËÉÊ ÄÉÓË, ÐÏÔÒÅÂÕÅÔÓÑ ÕÓÔÁÎÏ×ÉÔØ ÍÅÎÅÄÖÅÒ ÚÁÇÒÕÚËÉ &os; ÎÁ ÏÂÁ ÄÉÓËÁ.
÷ÙÈÏÄ ÉÚ ×ÙÂÏÒÁ ÄÉÓËÁ
ëÌÁ×ÉÛÁ Tab ÐÅÒÅËÌÀÞÁÅÔ ÍÅÖÄÕ ÐÏÓÌÅÄÎÉÍ ×ÙÂÒÁÎÎÙÍ ÄÉÓËÏÍ, &gui.ok;, É &gui.cancel;. îÁÖÍÉÔÅ Tab ÏÄÉÎ ÒÁÚ ÄÌÑ ×ÙÂÏÒÁ &gui.ok;, ÚÁÔÅÍ ÎÁÖÍÉÔÅ Enter ÄÌÑ ÐÒÏÄÏÌÖÅÎÉÑ ÕÓÔÁÎÏ×ËÉ.
óÏÚÄÁÎÉÅ ÒÁÚÄÅÌÏ× Ó ÐÏÍÏÝØÀ <application>Disklabel</application> ôÅÐÅÒØ ×Ù ÄÏÌÖÎÙ ÓÏÚÄÁÔØ ÎÅÓËÏÌØËÏ ÒÁÚÄÅÌÏ× ×ÎÕÔÒÉ ËÁÖÄÏÇÏ ÔÏÌØËÏ ÞÔÏ ÓÏÚÄÁÎÎÏÇÏ ÓÌÁÊÓÁ. úÁÐÏÍÎÉÔÅ, ÞÔÏ Õ ËÁÖÄÏÇÏ ÒÁÚÄÅÌÁ ÅÓÔØ ÂÕË×Á Ó a ÄÏ h, Á ÒÁÚÄÅÌÙ b, c, É d ÉÍÅÀÔ ÓÏÇÌÁÛÅÎÉÑ, ËÏÔÏÒÙÈ ×Ù ÄÏÌÖÎÙ ÐÒÉÄÅÒÖÉ×ÁÔØÓÑ. îÅËÏÔÏÒÙÅ ÐÒÉÌÏÖÅÎÉÑ ÍÏÇÕÔ ×ÙÉÇÒÙ×ÁÔØ ÏÔ ÏÐÒÅÄÅÌÅÎÎÙÈ ÓÈÅÍ ÒÁÚÄÅÌÏ×, ÏÓÏÂÅÎÎÏ ÅÓÌÉ Õ ×ÁÓ ÒÁÚÄÅÌÙ ÎÁ ÂÏÌÅÅ ÞÅÍ ÏÄÎÏÍ ÄÉÓËÅ. ôÅÍ ÎÅ ÍÅÎÅÅ, ÄÌÑ ×ÁÛÅÊ ÐÅÒ×ÏÊ ÕÓÔÁÎÏ×ËÉ &os; ÎÅ ÎÕÖÎÏ ÓÌÉÛËÏÍ ÕÇÌÕÂÌÑÔØÓÑ × ÐÒÉÎÃÉÐÙ ÒÁÚÂÉÅÎÉÑ ÄÉÓËÁ. âÏÌÅÅ ×ÁÖÎÏ ÕÓÔÁÎÏ×ÉÔØ &os; É ÎÁÞÁÔØ ÅÅ ÉÓÐÏÌØÚÏ×ÁÔØ. ÷Ù ×ÓÅÇÄÁ ÍÏÖÅÔÅ ÐÅÒÅÕÓÔÁÎÏ×ÉÔØ &os; ÄÌÑ ÉÚÍÅÎÅÎÉÑ ÓÈÅÍÙ ÒÁÚÄÅÌÏ×, ËÏÇÄÁ ÐÏÂÌÉÖÅ ÐÏÚÎÁËÏÍÉÔÅÓØ Ó ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ. üÔÁ ÓÈÅÍÁ ÐÏËÁÚÙ×ÁÅÔ ÞÅÔÙÒÅ ÒÁÚÄÅÌÁ — ÏÄÉÎ ÄÌÑ ÐÏÄËÁÞËÉ É ÔÒÉ ÄÌÑ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ. ðÌÁÎÉÒÏ×ÁÎÉÅ ÒÁÚÄÅÌÏ× ÄÌÑ ÐÅÒ×ÏÇÏ ÄÉÓËÁ òÁÚÄÅÌ æÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ òÁÚÍÅÒ ïÐÉÓÁÎÉÅ a / 1 GB ëÏÒÎÅ×ÁÑ ÆÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ. ìÀÂÁÑ ÄÒÕÇÁÑ ÆÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ ÂÕÄÅÔ ÓÍÏÎÔÉÒÏ×ÁÎÁ ÎÁ ÜÔÕ. 1 GB ÜÔÏ ÐÏÄÈÏÄÑÝÉÊ ÒÁÚÍÅÒ ÄÌÑ ÜÔÏÊ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ. ÷Ù ÎÅ ÂÕÄÅÔÅ ÈÒÁÎÉÔØ ÎÁ ÎÅÊ ÓÌÉÛËÏÍ ÍÎÏÇÏ ÄÁÎÎÙÈ, Á ÏÂÙÞÎÁÑ ÕÓÔÁÎÏ×ËÁ &os; ÒÁÚÍÅÓÔÉÔ ÚÄÅÓØ ÏËÏÌÏ 128 MB ÄÁÎÎÙÈ. ïÓÔÁ×ÛÅÅÓÑ ÐÒÏÓÔÒÁÎÓÔ×Ï ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ×ÒÅÍÅÎÎÙÈ ÆÁÊÌÏ×, Á ÔÁËÖÅ ÏÓÔÁ×ÌÑÅÔ ×ÏÚÍÏÖÎÏÓÔØ ÒÁÓÛÉÒÅÎÉÑ ÄÌÑ ÂÕÄÕÝÉÈ ×ÅÒÓÉÊ &os;, ËÏÔÏÒÙÍ ÍÏÖÅÔ ÐÏÎÁÄÏÂÉÔÓÑ ÂÏÌØÛÅ ÍÅÓÔÁ × /. b N/A 2-3 x RAM òÁÚÄÅÌ ÐÏÄËÁÞËÉ ÎÁÈÏÄÉÔÓÑ ÎÁ ÒÁÚÄÅÌÅ b. ÷ÙÂÏÒ ÐÒÁ×ÉÌØÎÏÇÏ ÒÁÚÍÅÒÁ ÒÁÚÄÅÌÁ ÐÏÄËÁÞËÉ ÜÔÏ ÎÅÍÎÏÇÏ ÉÓËÕÓÓÔ×Ï. èÏÒÏÛÉÊ ÐÒÁËÔÉÞÅÓËÉÊ ÓÐÏÓÏ ×ÙÂÒÁÔØ ÒÁÚÍÅÒ ÐÏÄËÁÞËÉ ÜÔÏ ÕÓÔÁÎÏ×ÉÔØ ÅÇÏ ÒÁ×ÎÙÍ Ä×ÕÍ ÉÌÉ ÔÒÅÍ ÒÁÚÍÅÒÁÍ ÄÏÓÔÕÐÎÏÊ ÆÉÚÉÞÅÓËÏÊ ÐÁÍÑÔÉ (RAM). äÏÌÖÎÏ ÂÙÔØ ÈÏÔÑ ÂÙ 64 MB ÐÏÄËÁÞËÉ; ÅÓÌÉ × ËÏÍÐØÀÔÅÒÅ ÍÅÎØÛÅ ÞÅÍ 32 MB ÐÁÍÑÔÉ — ÕÓÔÁÎÏ×ÉÔÅ ÒÁÚÍÅÒ ÐÏÄËÁÞËÉ ÒÁ×ÎÙÍ 64 MB. åÓÌÉ Õ ×ÁÓ ÂÏÌØÛÅ ÏÄÎÏÇÏ ÄÉÓËÁ, ÍÏÖÎÏ ÒÁÓÐÏÌÏÖÉÔØ ÐÏÄËÁÞËÕ ÎÁ ËÁÖÄÏÍ ÄÉÓËÅ. &os; ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÔØ ËÁÖÄÙÊ ÄÉÓË, ÞÔÏ ÓÅÒØÅÚÎÏ Õ×ÅÌÉÞÉÔ ÓËÏÒÏÓÔØ ÐÏÄËÁÞËÉ. ÷ ÜÔÏÍ ÓÌÕÞÁÅ, ÏÐÒÅÄÅÌÉÔÅ ÏÂÝÉÊ ÒÁÚÍÅÒ ÐÏÄËÁÞËÉ, ËÏÔÏÒÙÊ ×ÁÍ ÎÕÖÅÎ (ÎÁÐÒÉÍÅÒ, 128 MB), É ÐÏÄÅÌÉÔÅ ÅÇÏ ÎÁ ÞÉÓÌÏ ÉÍÅÀÝÉÈÓÑ ÄÉÓËÏ× (ÎÁÐÒÉÍÅÒ, Ä×Á) ÄÌÑ ÏÐÒÅÄÅÌÅÎÉÑ ÒÁÚÍÅÒÁ ÒÁÚÄÅÌÏ× ÐÏÄËÁÞËÉ, ËÏÔÏÒÙÅ ÎÕÖÎÏ ÒÁÚÍÅÓÔÉÔØ ÎÁ ËÁÖÄÏÍ ×ÁÛÅÍ ÄÉÓËÅ, × ÜÔÏÍ ÐÒÉÍÅÒÅ 64 MB ÎÁ ÄÉÓË. e /var 512 MB ëÁÔÁÌÏÇ /var ÓÏÄÅÒÖÉÔ ÆÁÊÌÙ, ËÏÔÏÒÙÅ ÐÏÓÔÏÑÎÎÏ ÍÅÎÑÀÔÓÑ; ÌÏÇÉ É ÄÒÕÇÉÅ ÁÄÍÉÎÉÓÔÒÁÔÉ×ÎÙÅ ÆÁÊÌÙ. íÎÏÇÉÅ ÉÚ ÜÔÉÈ ÆÁÊÌÏ× ÉÎÔÅÎÓÉ×ÎÏ ÞÉÔÁÀÔÓÑ É ÚÁÐÉÓÙ×ÁÀÔÓÑ × ÐÒÏÃÅÓÓÅ ÅÖÅÄÎÅ×ÎÏÊ ÒÁÂÏÔÙ &os;. òÁÚÍÅÝÅÎÉÅ ÉÈ ÎÁ ÏÔÄÅÌØÎÏÊ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÅ ÐÏÚ×ÏÌÑÅÔ &os; ÏÐÔÉÍÉÚÉÒÏ×ÁÔØ ÄÏÓÔÕÐ Ë ÜÔÉÍ ÆÁÊÌÁÍ ÂÅÚ ÚÁÔÒÁÇÉ×ÁÎÉÑ ÄÒÕÇÉÈ ËÁÔÁÌÏÇÏ×, ÎÅ ÉÍÅÀÝÉÈ ÔÁËÏÊ ÖÅ ÍÏÄÅÌÉ ÄÏÓÔÕÐÁ. f /usr ïÓÔÁÌØÎÁÑ ÞÁÓÔØ ÄÉÓËÁ (ÐÏ ËÒÁÊÎÅÊ ÍÅÒÅ — 8 GB) ÷ÓÅ ÄÒÕÇÉÅ ÆÁÊÌÙ ËÁË ÐÒÁ×ÉÌÏ ÈÒÁÎÑÔÓÑ × ËÁÔÁÌÏÇÅ /usr É ÅÇÏ ÐÏÄËÁÔÁÌÏÇÁÈ.
úÎÁÞÅÎÉÑ, ÐÒÉ×ÅÄ£ÎÎÙÅ ×ÙÛÅ, Ñ×ÌÑÀÔÓÑ ÐÒÉÍÅÒÎÙÍÉ É ÕÍÅÓÔÎÙ Ë ÉÓÐÏÌØÚÏ×ÁÎÉÀ ÌÉÛØ ÏÐÙÔÎÙÍÉ ÐÏÌØÚÏ×ÁÔÅÌÑÍÉ. ïÓÔÁÌØÎÙÍ — ÒÅËÏÍÅÎÄÕÅÔÓÑ ÐÒÉÍÅÎÑÔØ ÏÐÃÉÀ Á×ÔÏÍÁÔÉÞÅÓËÏÇÏ ÒÁÚÂÉÅÎÉÑ, ÎÁÚÙ×ÁÅÍÕÀ Auto Defaults × ÒÅÄÁËÔÏÒÅ ÒÁÚÄÅÌÏ× &os;. åÓÌÉ ×Ù ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÅ &os; ÂÏÌÅÅ ÞÅÍ ÎÁ ÏÄÉÎ ÄÉÓË, ×Ù ÄÏÌÖÎÙ ÔÁËÖÅ ÓÏÚÄÁÔØ ÒÁÚÄÅÌÙ × ÄÒÕÇÉÈ ÓÌÁÊÓÁÈ, ËÏÔÏÒÙÅ ÎÁÓÔÒÏÉÌÉ. ðÒÏÓÔÅÊÛÉÊ ÐÕÔØ ÓÄÅÌÁÔØ ÜÔÏ — ÓÏÚÄÁÔØ Ä×Á ÒÁÚÄÅÌÁ ÎÁ ËÁÖÄÏÍ ÄÉÓËÅ, ÏÄÉÎ ÄÌÑ ÐÏÄËÁÞËÉ, Á ÄÒÕÇÏÊ ÄÌÑ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ. òÁÚÍÅÔËÁ ÒÁÚÄÅÌÏ× ÄÌÑ ÏÓÔÁÌØÎÙÈ ÄÉÓËÏ× òÁÚÄÅÌ æÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ òÁÚÍÅÒ ïÐÉÓÁÎÉÅ b N/A óÍÏÔÒÉÔÅ ÏÐÉÓÁÎÉÅ ëÁË ÕÖÅ ÏÂÓÕÖÄÁÌÏÓØ, ×Ù ÍÏÖÅÔÅ ÒÁÓÐÒÏÓÔÒÁÎÉÔØ ÐÏÄËÁÞËÕ ÎÁ ËÁÖÄÙÊ ÄÉÓË. äÁÖÅ ÅÓÌÉ ÒÁÚÄÅÌ a Ó×ÏÂÏÄÅÎ, ÓÏÇÌÁÛÅÎÉÅ ÇÏ×ÏÒÉÔ Ï ÔÏÍ, ÞÔÏ ÐÏÄËÁÞËÁ ÎÁÈÏÄÉÔÓÑ ÎÁ ÒÁÚÄÅÌÅ b. e /diskn ïÓÔÁÌØÎÁÑ ÞÁÓÔØ ÄÉÓËÁ ïÓÔÁÌØÎÁÑ ÞÁÓÔØ ÄÉÓËÁ ÚÁÎÑÔÁ ÏÄÎÉÍ ÂÏÌØÛÉÍ ÒÁÚÄÅÌÏÍ. ïÎ ÌÅÇËÏ ÍÏÖÅÔ ÂÙÔØ ÐÏÍÅÝÅÎ ÎÁ ÒÁÚÄÅÌ a ×ÍÅÓÔÏ ÒÁÚÄÅÌÁ e. ïÄÎÁËÏ, ÓÏÇÌÁÛÅÎÉÅ ÇÏ×ÏÒÉÔ, ÞÔÏ ÒÁÚÄÅÌ a ÚÁÒÅÚÅÒ×ÉÒÏ×ÁÎ ÎÁ ÓÌÁÊÓÅ ÄÌÑ ËÏÒÎÅ×ÏÊ (/) ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ. ×Ù ÍÏÖÅÔÅ ÎÅ ÓÌÅÄÏ×ÁÔØ ÜÔÏÍÕ ÓÏÇÌÁÛÅÎÉÀ, ÎÏ ÐÒÏÇÒÁÍÍÁ sysinstall ÂÕÄÅÔ ÅÍÕ ÓÌÅÄÏ×ÁÔØ, ÐÏÜÔÏÍÕ ÐÒÉÎÑ× ÅÇÏ, ×Ù ÓÄÅÌÁÅÔÅ ÕÓÔÁÎÏ×ËÕ ÎÅÓËÏÌØËÏ ÐÒÏÝÅ. ÷Ù ÍÏÖÅÔÅ ÍÏÎÔÉÒÏ×ÁÔØ ÜÔÉ ÆÁÊÌÏ×ÙÅ ÓÉÓÔÅÍÙ Ë ÌÀÂÏÊ ÔÏÞËÅ; × ÜÔÏÍ ÐÒÉÍÅÒÅ ÐÒÅÄÌÁÇÁÅÔÓÑ ÓÍÏÎÔÉÒÏ×ÁÔØ ÉÈ ËÁË ËÁÔÁÌÏÇÉ /diskn, ÇÄÅ n ÜÔÏ ÎÏÍÅÒ, ËÏÔÏÒÙÊ ÕÎÉËÁÌÅÎ ÄÌÑ ËÁÖÄÏÇÏ ÄÉÓËÁ. îÏ ×Ù ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÒÕÇÕÀ ÓÈÅÍÕ, ÅÓÌÉ ÚÁÈÏÔÉÔÅ.
ôÅÐÅÒØ, ×ÙÂÒÁ× ÒÁÚÍÅÔËÕ ÒÁÚÄÅÌÏ×, ÍÏÖÅÔÅ ÐÒÉÓÔÕÐÉÔØ Ë ÉÈ ÓÏÚÄÁÎÉÀ × sysinstall. ÷Ù Õ×ÉÄÉÔÅ ÜÔÏ ÓÏÏÂÝÅÎÉÅ: Message Now, you need to create BSD partitions inside of the fdisk partition(s) just created. If you have a reasonable amount of disk space (1 GB or more) and don't have any special requirements, simply use the (A)uto command to allocate space automatically. If you have more specific needs or just don't care for the layout chosen by (A)uto, press F1 for more information on manual layout. [ OK ] [ Press enter or space ] îÁÖÍÉÔÅ Enter ÄÌÑ ÚÁÐÕÓËÁ ÒÅÄÁËÔÏÒÁ ÒÁÚÄÅÌÏ× FreeBSD, ÎÁÚÙ×ÁÅÍÏÇÏ Disklabel. ÐÏËÁÚÙ×ÁÅÔ ÜËÒÁÎ ÔÏÌØËÏ ÞÔÏ ÚÁÐÕÝÅÎÎÏÇÏ Disklabel. üËÒÁÎ ÐÏÄÅÌÅÎ ÎÁ ÔÒÉ ÒÁÚÄÅÌÁ. ðÅÒ×ÙÅ ÎÅÓËÏÌØËÏ ÌÉÎÉÊ ÐÏËÁÚÙ×ÁÀÔ ÉÍÑ ÄÉÓËÁ, Ó ËÏÔÏÒÙÍ ×Ù ÓÅÊÞÁÓ ÒÁÂÏÔÁÅÔÅ É ÓÌÁÊÓ, ÓÏÄÅÒÖÁÝÉÊ ÒÁÚÄÅÌ, ËÏÔÏÒÙÊ ×Ù ÓÏÚÄÁÅÔÅ (ÚÄÅÓØ Disklabel ÎÁÚÙ×ÁÅÔ ÜÔÏ ÉÍÅÎÅÍ ÒÁÚÄÅÌÁ (Partition name) ×ÍÅÓÔÏ ÉÍÅÎÉ ÓÌÁÊÓÁ). üÔÏÔ ÜËÒÁÎ ÔÁËÖÅ ÐÏËÁÚÙ×ÁÅÔ ÏÂßÅÍ Ó×ÏÂÏÄÎÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á ÎÁ ÓÌÁÊÓÅ, Ô.Å. ÐÒÏÓÔÒÁÎÓÔ×Ï, ×ÙÄÅÌÅÎÎÏÅ ÐÏÄ ÓÌÁÊÓ, ÎÏ ÅÝÅ ÎÅ ÏÔÄÁÎÎÏÅ ÐÏÄ ÒÁÚÄÅÌ. ÷ ÃÅÎÔÒÅ ÜËÒÁÎÁ ÐÏËÁÚÁÎÙ ÕÖÅ ÓÏÚÄÁÎÎÙÅ ÒÁÚÄÅÌÙ, ÉÍÅÎÁ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ, ÓÏÄÅÒÖÁÝÉÈÓÑ × ÒÁÚÄÅÌÁÈ, ÉÈ ÒÁÚÍÅÒ É ÎÅËÏÔÏÒÙÅ ÏÐÃÉÉ, ÐÒÉÍÅÎÑÅÍÙÅ ÐÒÉ ÓÏÚÄÁÎÉÑ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ. îÉÖÎÑÑ ÔÒÅÔØ ÜËÒÁÎÁ ÐÏËÁÚÙ×ÁÅÔ ÕÐÒÁ×ÌÑÀÝÉÅ ËÌÁ×ÉÛÉ, ÒÁÂÏÔÁÀÝÉÅ × Disklabel.
òÅÄÁËÔÏÒ Sysinstall Disklabel
Disklabel ÍÏÖÅÔ Á×ÔÏÍÁÔÉÞÅÓËÉ ÓÏÚÄÁÔØ ÒÁÚÄÅÌÙ É ÐÒÉÓ×ÏÉÔØ ÉÍ ÒÁÚÍÅÒÙ ÐÏ ÕÍÏÌÞÁÎÉÀ. úÎÁÞÅÎÉÑ ÒÁÚÍÅÒÏ× ÐÏ ÕÍÏÌÞÁÎÉÀ ×ÙÞÉÓÌÑÀÔÓÑ Ó ÐÏÍÏÝØÀ ×ÎÕÔÒÅÎÎÅÇÏ ÁÌÇÏÒÉÔÍÁ, ÉÓÈÏÄÑ ÉÚ ÅÍËÏÓÔÉ ÄÉÓËÁ. ðÏÐÒÏÂÕÊÔÅ ÜÔÏ, ÎÁÖÁ× A. ÷Ù Õ×ÉÄÉÔÅ ÜËÒÁÎ ËÁË ÎÁ . ÷ ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÒÁÚÍÅÒÁ ÄÉÓËÁ, ÚÎÁÞÅÎÉÑ ÐÏ ÕÍÏÌÞÁÎÉÀ ÍÏÇÕÔ ÐÏÄÈÏÄÉÔØ ÉÌÉ ÎÅ ÐÏÄÈÏÄÉÔØ ×ÁÍ. üÔÏ ÎÅ ÉÍÅÅÔ ÚÎÁÞÅÎÉÑ, ÅÓÌÉ ×Ù ÎÅ ÐÒÉÎÉÍÁÅÔÅ ÉÈ. ðÏ ÕÍÏÌÞÁÎÉÀ ÐÏÄ ËÁÔÁÌÏÇ /tmp ×ÙÄÅÌÑÅÔÓÑ ÓÏÂÓÔ×ÅÎÎÙÊ ÒÁÚÄÅÌ ×ÍÅÓÔÏ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÞÁÓÔÉ ÒÁÚÄÅÌÁ /. üÔÏ ÐÏÍÏÇÁÅÔ ÉÚÂÅÖÁÔØ ÚÁÐÏÌÎÅÎÉÑ ÒÁÚÄÅÌÁ / ×ÒÅÍÅÎÎÙÍÉ ÆÁÊÌÁÍÉ.
òÅÄÁËÔÏÒ Sysinstall Disklabel Ó ÕÓÔÁÎÏ×ËÁÍÉ ÐÏ ÕÍÏÌÞÁÎÉÀ
åÓÌÉ ×Ù ÒÅÛÉÌÉ ÎÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÒÁÚÄÅÌÙ ÐÏ ÕÍÏÌÞÁÎÉÀ É ÚÁÍÅÎÉÔØ ÉÈ ÎÁ Ó×ÏÉ, ÉÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ ÐÅÒ×ÏÇÏ ÒÁÚÄÅÌÁ, ÚÁÔÅÍ ÎÁÖÍÉÔÅ D ÄÌÑ ÅÇÏ ÕÄÁÌÅÎÉÑ. ðÏ×ÔÏÒÉÔÅ ÜÔÏ ÄÌÑ ÕÄÁÌÅÎÉÑ ×ÓÅÈ ÐÒÅÄÌÏÖÅÎÎÙÈ ÒÁÚÄÅÌÏ×. äÌÑ ÓÏÚÄÁÎÉÑ ÐÅÒ×ÏÇÏ ÒÁÚÄÅÌÁ (a, ÍÏÎÔÉÒÕÅÍÏÇÏ ËÁË / — root), ÕÂÅÄÉÔÅÓØ, ÞÔÏ ×ÙÂÒÁÎ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÉÊ ÓÌÁÊÓ ××ÅÒÈÕ ÜËÒÁÎÁ É ÎÁÖÍÉÔÅ C. ðÏÑ×ÉÔÓÑ ÄÉÁÌÏÇ, ÐÒÅÄÌÁÇÁÀÝÉÊ ×ÙÂÒÁÔØ ÒÁÚÍÅÒ ÎÏ×ÏÇÏ ÒÁÚÄÅÌÁ (ËÁË ÐÏËÁÚÁÎÏ ÎÁ ). ÷Ù ÍÏÖÅÔÅ ××ÅÓÔÉ ËÏÌÉÞÅÓÔ×Ï ÂÌÏËÏ× ÄÉÓËÁ, ÉÌÉ ËÏÌÉÞÅÓÔ×Ï ÍÅÇÁÂÁÊÔ Ó M ÐÏÓÌÅ ÎÏÍÅÒÁ, ÉÌÉ ÇÉÇÁÂÁÊÔ Ó G, ÉÌÉ ÃÉÌÉÎÄÒÏ× Ó C.
ó×ÏÂÏÄÎÏÅ ÍÅÓÔÏ ÄÌÑ ËÏÒÎÅ×ÏÇÏ ÒÁÚÄÅÌÁ
òÁÚÍÅÒ ÐÏ ÕÍÏÌÞÁÎÉÀ ÚÁÄÁÎ ÄÌÑ ÓÏÚÄÁÎÉÑ ËÏÒÎÅ×ÏÇÏ ÒÁÚÄÅÌÁ ÎÁ ×ÅÓØ ÓÌÁÊÓ. åÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ ÒÁÚÍÅÒÙ ÒÁÚÄÅÌÏ×, ÏÐÉÓÁÎÎÙÅ ÒÁÎÅÅ × ÐÒÉÍÅÒÅ, ÕÄÁÌÉÔÅ ÜÔÏ ÚÎÁÞÅÎÉÅ ÉÓÐÏÌØÚÕÑ Backspace, Á ÚÁÔÅÍ ××ÅÄÉÔÅ 512M, ËÁË ÐÏËÁÚÁÎÏ ÎÁ . úÁÔÅÍ ÎÁÖÍÉÔÅ &gui.ok;.
òÅÄÁËÔÉÒÏ×ÁÎÉÅ ÒÁÚÍÅÒÁ ËÏÒÎÅ×ÏÇÏ ÒÁÚÄÅÌÁ
ðÏÓÌÅ ÕËÁÚÁÎÉÑ ÒÁÚÍÅÒÁ ÒÁÚÄÅÌÁ ×ÁÍ ÂÕÄÅÔ ÚÁÄÁÎ ×ÏÐÒÏÓ, ÄÏÌÖÅÎ ÌÉ ÜÔÏÔ ÒÁÚÄÅÌ ÓÏÄÅÒÖÁÔØ ÆÁÊÌÏ×ÕÀ ÓÉÓÔÅÍÕ ÉÌÉ ÒÁÚÄÅÌ ÐÏÄËÁÞËÉ. äÉÁÌÏÇ ÐÏËÁÚÁÎ ÎÁ . ðÅÒ×ÙÊ ÒÁÚÄÅÌ ÂÕÄÅÔ ÓÏÄÅÒÖÁÔØ ÆÁÊÌÏ×ÕÀ ÓÉÓÔÅÍÕ, ÐÏÜÔÏÍÕ ÐÒÏ×ÅÒØÔÅ, ÞÔÏ ×ÙÂÒÁÎÁ FS É ÎÁÖÍÉÔÅ Enter.
÷ÙÂÏÒ ÔÉÐÁ ËÏÒÎÅ×ÏÇÏ ÒÁÚÄÅÌÁ
îÁËÏÎÅÃ, ÐÏÓËÏÌØËÕ ×Ù ÓÏÚÄÁÅÔÅ ÆÁÊÌÏ×ÕÀ ÓÉÓÔÅÍÕ, ÎÕÖÎÏ ÓËÁÚÁÔØ Disklabel ÇÄÅ ÆÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ ÂÕÄÅÔ ÓÍÏÎÔÉÒÏ×ÁÎÁ. äÉÁÌÏÇ ÐÏËÁÚÁÎ ÎÁ . ôÏÞËÁ ÍÏÎÔÉÒÏ×ÁÎÉÑ ËÏÒÎÅ×ÏÊ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ /, ÐÏÜÔÏÍÕ ××ÅÄÉÔÅ /, É ÎÁÖÍÉÔÅ Enter.
÷ÙÂÏÒ ÔÏÞËÉ ÍÏÎÔÉÒÏ×ÁÎÉÑ ËÏÒÎÅ×ÏÊ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ
îÁ ÜËÒÁÎÅ ÂÕÄÅÔ ÐÏËÁÚÁÎ ×ÎÏר ÓÏÚÄÁÎÎÙÊ ÒÁÚÄÅÌ. ÷ÁÍ ÎÕÖÎÏ ÐÏ×ÔÏÒÉÔØ ÜÔÕ ÐÒÏÃÅÄÕÒÕ ÄÌÑ ÄÒÕÇÉÈ ÒÁÚÄÅÌÏ×. ðÒÉ ÓÏÚÄÁÎÉÉ ÒÁÚÄÅÌÁ ÐÏÄËÁÞËÉ ×ÏÐÒÏÓÁ ÐÒÏ ÔÏÞËÕ ÍÏÎÔÉÒÏ×ÁÎÉÑ ÎÅ ÂÕÄÅÔ, ÐÏÓËÏÌØËÕ ÒÁÚÄÅÌ ÐÏÄËÁÞËÉ ÎÉËÏÇÄÁ ÎÅ ÍÏÎÔÉÒÕÅÔÓÑ. ëÏÇÄÁ ÂÕÄÅÔÅ ÓÏÚÄÁ×ÁÔØ ÐÏÓÌÅÄÎÉÊ ÒÁÚÄÅÌ, /usr, ÍÏÖÅÔÅ ÏÓÔÁ×ÉÔØ ÐÒÅÄÌÏÖÅÎÎÙÊ ÒÁÚÍÅÒ ËÁË ÅÓÔØ, ÞÔÏÂÙ ÉÓÐÏÌØÚÏ×ÁÔØ ×ÅÓØ ÏÓÔÁÔÏË ÓÌÁÊÓÁ. ðÏÓÌÅÄÎÉÊ ÜËÒÁÎ &os; ÒÅÄÁËÔÏÒÁ DiskLabel ÂÕÄÅÔ ÐÏÈÏÖ ÎÁ , ÈÏÔÑ ×ÁÛ ×ÙÂÏÒ ÚÎÁÞÅÎÉÊ ÍÏÖÅÔ ÂÙÔØ ÄÒÕÇÉÍ. îÁÖÍÉÔÅ Q, ÞÔÏÂÙ ×ÙÊÔÉ.
òÅÄÁËÔÏÒ Sysinstall Disklabel
÷ÙÂÏÒ ÕÓÔÁÎÁ×ÌÉ×ÁÅÍÙÈ ËÏÍÐÏÎÅÎÔÏ× ÷ÙÂÏÒ ÄÉÓÔÒÉÂÕÔÉ×ÎÏÇÏ ÎÁÂÏÒÁ (Distribution Set) ÷ÙÂÏÒ ÄÉÓÔÒÉÂÕÔÉ×ÎÏÇÏ ÎÁÂÏÒÁ ÚÁ×ÉÓÉÔ × ÏÓÎÏ×ÎÏÍ ÏÔ ÎÁÐÒÁ×ÌÅÎÉÑ ÂÕÄÕÝÅÇÏ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÓÉÓÔÅÍÙ É ÏÔ ÄÏÓÔÕÐÎÏÇÏ ÄÉÓËÏ×ÏÇÏ ÐÒÏÓÔÒÁÎÓÔ×Á. ðÒÅÄÕÓÔÁÎÏ×ÌÅÎÎÙÅ ÏÐÃÉÉ ×ÁÒØÉÒÕÀÔÓÑ ÏÔ ÎÁÉÍÅÎØÛÅÊ ×ÏÚÍÏÖÎÏÊ ËÏÎÆÉÇÕÒÁÃÉÉ ÄÏ ÐÏÌÎÏÊ ÕÓÔÁÎÏ×ËÉ. äÌÑ ÎÏ×ÉÞËÏ× × &unix; É/ÉÌÉ &os; ÌÕÞÛÉÍ ×ÙÂÏÒÏÍ ÂÕÄÅÔ ÏÄÎÁ ÉÚ ÜÔÉÈ ÐÒÅÄÕÓÔÁÎÏ×ÌÅÎÎÙÈ ÏÐÃÉÊ. îÁÓÔÒÏÊËÁ ÄÉÓÔÒÉÂÕÔÉ×ÎÏÇÏ ÎÁÂÏÒÁ ËÁË ÐÒÁ×ÉÌÏ ÎÕÖÎÁ ÂÏÌÅÅ ÏÐÙÔÎÙÍ ÐÏÌØÚÏ×ÁÔÅÌÑÍ. îÁÖÍÉÔÅ F1 ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÉÎÆÏÒÍÁÃÉÉ Ï ÄÉÓÔÒÉÂÕÔÉ×ÎÙÈ ÎÁÂÏÒÁÈ É ÉÈ ÓÏÄÅÒÖÉÍÏÍ. ðÏÓÌÅ ÐÒÏÓÍÏÔÒÁ ÐÏÍÏÝÉ ÎÁÖÍÉÔÅ Enter ÄÌÑ ×ÏÚ×ÒÁÔÁ Ë ÍÅÎÀ ×ÙÂÏÒÁ ÄÉÓÔÒÉÂÕÔÉ×ÎÏÇÏ ÎÁÂÏÒÁ. åÓÌÉ ÖÅÌÁÔÅÌØÎÏ ÎÁÌÉÞÉÅ ÇÒÁÆÉÞÅÓËÏÇÏ ÉÎÔÅÒÆÅÊÓÁ ÐÏÌØÚÏ×ÁÔÅÌÑ, ÔÏ ÚÁÄÁÞÉ ÎÁÓÔÒÏÊËÉ X ÓÅÒ×ÅÒÁ É ×ÙÂÏÒÁ ÄÅÓËÔÏÐÁ ÐÏ ÕÍÏÌÞÁÎÉÀ ÄÏÌÖÎÙ ÂÙÔØ ×ÙÐÏÌÎÅÎÙ ÐÏÓÌÅ ÕÓÔÁÎÏ×ËÉ &os;. âÏÌÅÅ ÐÏÄÒÏÂÎÁÑ ÉÎÆÏÒÍÁÃÉÑ ÐÏ ÕÓÔÁÎÏ×ËÅ É ÎÁÓÔÒÏÊËÅ X ÓÅÒ×ÅÒÁ ÎÁÈÏÄÉÔÓÑ × . åÓÌÉ ÐÌÁÎÉÒÕÅÔÓÑ ÐÅÒÅÓÂÏÒËÁ ÑÄÒÁ, ×ÙÂÅÒÉÔÅ ÏÐÃÉÀ, ×ËÌÀÞÁÀÝÕÀ ÉÓÈÏÄÎÙÅ ÔÅËÓÔÙ. éÎÆÏÒÍÁÃÉÑ Ï ÔÏÍ, ÚÁÞÅÍ ÐÅÒÅÓÏÂÉÒÁÔØ ÑÄÒÏ É ËÁË ÜÔÏ ÓÄÅÌÁÔØ, ÎÁÈÏÄÉÔÓÑ ÎÁ . ñÓÎÏ, ÞÔÏ ÎÁÉÂÏÌÅÅ ÕÎÉ×ÅÒÓÁÌØÎÁÑ ÓÉÓÔÅÍÁ ×ËÌÀÞÁÅÔ ×ÓÅ. åÓÌÉ ÍÅÓÔÁ ÎÁ ÄÉÓËÅ ÄÏÓÔÁÔÏÞÎÏ, ×ÙÂÅÒÉÔÅ All, ËÁË ÐÏËÁÚÁÎÏ ÎÁ É ÎÁÖÍÉÔÅ Enter. åÓÌÉ ÅÓÔØ ÓÏÍÎÅÎÉÑ ÏÔÎÏÓÉÔÅÌØÎÏ ÔÏÇÏ, È×ÁÔÉÔ ÌÉ ÄÉÓËÁ, ÉÓÐÏÌØÚÕÊÔÅ ÎÁÉÂÏÌÅÅ ÐÏÄÈÏÄÑÝÕÀ ÏÐÃÉÀ. îÅ ÂÅÓÐÏËÏÊÔÅÓØ Ï ÔÏÍ, ËÁËÏÊ ×ÙÂÏÒ ÂÕÄÅÔ ÎÁÉÌÕÞÛÉÍ, ÄÒÕÇÉÅ ÞÁÓÔÉ ÄÉÓÔÒÉÂÕÔÉ×Á ÍÏÇÕÔ ÂÙÔØ ÄÏÂÁ×ÌÅÎÙ ÐÏÓÌÅ ÕÓÔÁÎÏ×ËÉ.
÷ÙÂÏÒ ÄÉÓÔÒÉÂÕÔÉ×ÎÙÈ ÎÁÂÏÒÏ×
õÓÔÁÎÏ×ËÁ ëÏÌÌÅËÃÉÉ ðÏÒÔÏ× ðÏÓÌÅ ×ÙÂÏÒÁ ÐÏÄÈÏÄÑÝÅÇÏ ÄÉÓÔÒÉÂÕÔÉ×Á ÍÏÖÎÏ ÂÕÄÅÔ ×ÙÂÒÁÔØ ÕÓÔÁÎÏ×ËÕ ëÏÌÌÅËÃÉÉ ðÏÒÔÏ× &os;. ëÏÌÌÅËÃÉÑ ðÏÒÔÏ× — Ì£ÇËÉÊ É ÕÄÏÂÎÙÊ ÐÕÔØ ÕÓÔÁÎÏ×ËÉ ÐÒÏÇÒÁÍÍ. ëÏÌÌÅËÃÉÑ ðÏÒÔÏ× ÎÅ ÓÏÄÅÒÖÉÔ ÉÓÈÏÄÎÙÈ ËÏÄÏ× ÐÒÏÇÒÁÍÍ. üÔÏ ÎÁÂÏÒ ÆÁÊÌÏ×, ËÏÔÏÒÙÊ Á×ÔÏÍÁÔÉÚÉÒÕÅÔ ÚÁÇÒÕÚËÕ, ËÏÍÐÉÌÉÒÏ×ÁÎÉÅ É ÕÓÔÁÎÏ×ËÕ ÐÁËÅÔÏ× ÐÒÏÇÒÁÍÍÎÏÇÏ ÏÂÅÓÐÅÞÅÎÉÑ ÓÔÏÒÏÎÎÉÈ ÒÁÚÒÁÂÏÔÞÉËÏ×. ÐÏËÁÚÙ×ÁÅÔ, ËÁË ÉÓÐÏÌØÚÏ×ÁÔØ ëÏÌÌÅËÃÉÀ ðÏÒÔÏ×. ðÒÏÇÒÁÍÍÁ ÕÓÔÁÎÏ×ËÉ ÎÅ ÐÒÏ×ÅÒÑÅÔ, ÅÓÔØ ÌÉ ÄÏÓÔÁÔÏÞÎÏ ÍÅÓÔÁ. ÷ÙÂÅÒÉÔÅ ÜÔÕ ÏÐÃÉÀ ÔÏÌØËÏ × ÔÏÍ ÓÌÕÞÁÅ, ÅÓÌÉ ÅÇÏ ÄÏÓÔÁÔÏÞÎÏ. ÷ &os; &rel.current;, ëÏÌÌÅËÃÉÑ ðÏÒÔÏ× ÚÁÎÉÍÁÅÔ ÏËÏÌÏ &ports.size;. ÷ ÂÏÌÅÅ ÓÏ×ÒÅÍÅÎÎÙÈ ÒÅÌÉÚÁÈ ÜÔÏ ÚÎÁÞÅÎÉÅ ×ÓÅÇÄÁ ÂÏÌØÛÅ. User Confirmation Requested Would you like to install the FreeBSD ports collection? This will give you ready access to over &os.numports; ported software packages, at a cost of around &ports.size; of disk space when "clean" and possibly much more than that if a lot of the distribution tarballs are loaded (unless you have the extra CDs from a FreeBSD CD/DVD distribution available and can mount it on /cdrom, in which case this is far less of a problem). The ports collection is a very valuable resource and well worth having on your /usr partition, so it is advisable to say Yes to this option. For more information on the ports collection & the latest ports, visit: http://www.FreeBSD.org/ports [ Yes ] No ÷ÙÂÅÒÉÔÅ &gui.yes; ÄÌÑ ÕÓÔÁÎÏ×ËÉ ëÏÌÌÅËÃÉÉ ðÏÒÔÏ×, ÉÌÉ &gui.no;, ÞÔÏÂÙ ÐÒÏÐÕÓÔÉÔØ ÕÓÔÁÎÏ×ËÕ. îÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ÐÒÏÄÏÌÖÉÔØ. íÅÎÀ ×ÙÂÏÒÁ ÄÉÓÔÒÉÂÕÔÉ×ÎÙÈ ÎÁÂÏÒÏ× ÐÏÑ×ÉÔÓÑ ÏÐÑÔØ.
ðÏÄÔ×ÅÒÖÄÅÎÉÅ ×ÙÂÏÒÁ ÄÉÓÔÒÉÂÕÔÉ×ÎÏÇÏ ÎÁÂÏÒÁ
åÓÌÉ ×Ù ÓÏÇÌÁÓÎÙ Ó ×ÙÂÒÁÎÎÙÍÉ ÏÐÃÉÑÍÉ, ÐÅÒÅÍÅÓÔÉÔÅÓØ ÎÁ Exit, ÕÂÅÄÉÔÅÓØ, ÞÔÏ ×ÙÂÒÁÎ &gui.ok; É ÎÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ÐÒÏÄÏÌÖÉÔØ.
÷ÙÂÏÒ ÉÓÔÏÞÎÉËÁ ÄÌÑ ÕÓÔÁÎÏ×ËÉ ðÒÉ ÕÓÔÁÎÏ×ËÅ Ó CDROM ÉÌÉ DVD ÉÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ, ÄÌÑ ÐÅÒÅÈÏÄÁ Ë ÐÕÎËÔÕ Install from a FreeBSD CD/DVD. õÂÅÄÉÔÅÓØ, ÞÔÏ ×ÙÂÒÁÎ &gui.ok;, É ÎÁÖÍÉÔÅ Enter ÄÌÑ ÚÁÐÕÓËÁ ÕÓÔÁÎÏ×ËÉ. ðÒÉ ÄÒÕÇÉÈ ÍÅÔÏÄÁÈ ÕÓÔÁÎÏ×ËÉ ×ÙÂÅÒÉÔÅ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÕÀ ÏÐÃÉÀ É ÓÌÅÄÕÊÔÅ ÉÎÓÔÒÕËÃÉÑÍ. îÁÖÍÉÔÅ F1 ÄÌÑ ÐÒÏÓÍÏÔÒÁ ÓÐÒÁ×ËÉ ÐÏ ÉÓÔÏÞÎÉËÁÍ ÕÓÔÁÎÏ×ËÉ. îÁÖÍÉÔÅ Enter ÄÌÑ ×ÏÚ×ÒÁÔÁ Ë ÍÅÎÀ ×ÙÂÏÒÁ ÉÓÔÏÞÎÉËÁ ÕÓÔÁÎÏ×ËÉ.
÷ÙÂÏÒ ÉÓÔÏÞÎÉËÁ ÕÓÔÁÎÏ×ËÉ
òÅÖÉÍÙ ÕÓÔÁÎÏ×ËÉ Ó FTP installation network FTP åÓÔØ ÔÒÉ ÒÅÖÉÍÁ ÕÓÔÁÎÏ×ËÉ ÞÅÒÅÚ FTP, ËÏÔÏÒÙÅ ×Ù ÍÏÖÅÔÅ ×ÙÂÒÁÔØ: ÁËÔÉ×ÎÙÊ FTP, ÐÁÓÓÉ×ÎÙÊ FTP, ÉÌÉ ÞÅÒÅÚ HTTP ÐÒÏËÓÉ. áËÔÉ×ÎÙÊ FTP: Install from an FTP server ó ÜÔÏÊ ÏÐÃÉÅÊ ×ÓÅ ÚÁËÁÞËÉ ÐÏ FTP ÂÕÄÕÔ ×ÙÐÏÌÎÅÎÙ × ÁËÔÉ×ÎÏÍ ÒÅÖÉÍÅ. üÔÏÔ ÒÅÖÉÍ ÎÅ ÐÏÚ×ÏÌÑÅÔ ÒÁÂÏÔÁÔØ ÞÅÒÅÚ ÆÁÊÒ×ÏÌÌ, ÎÏ ÚÁÞÁÓÔÕÀ ÐÏÚ×ÏÌÑÅÔ ÒÁÂÏÔÁÔØ ÓÏ ÓÔÁÒÙÍÉ ÓÅÒ×ÅÒÁÍÉ FTP, ÎÅ ÐÏÄÄÅÒÖÉ×ÁÀÝÉÍÉ ÐÁÓÓÉ×ÎÙÊ ÒÅÖÉÍ. åÓÌÉ ÓÏÅÄÉÎÅÎÉÅ ÐÒÅÒÙ×ÁÅÔÓÑ × ÐÁÓÓÉ×ÎÏÍ ÒÅÖÉÍÅ (ÐÏ ÕÍÏÌÞÁÎÉÀ), ÐÏÐÒÏÂÕÊÔÅ ÁËÔÉ×ÎÙÊ! ðÁÓÓÉ×ÎÙÊ FTP: Install from an FTP server through a firewall FTP ðÁÓÓÉ×ÎÙÊ ÒÅÖÉÍ üÔÁ ÏÐÃÉÑ ÇÏ×ÏÒÉÔ sysinstall ÉÓÐÏÌØÚÏ×ÁÔØ ÐÁÓÓÉ×ÎÙÊ ÒÅÖÉÍ ÄÌÑ ÒÁÂÏÔÙ Ó FTP. ïÎ ÐÏÚ×ÏÌÑÅÔ ÒÁÂÏÔÁÔØ ÞÅÒÅÚ ÆÁÊÒ×ÏÌÌ, ÎÅ ÒÁÚÒÅÛÁÀÝÉÊ ×ÈÏÄÑÝÉÅ ÓÏÅÄÉÎÅÎÉÑ ÎÁ ÓÌÕÞÁÊÎÙÈ TCP ÐÏÒÔÁÈ. FTP ÞÅÒÅÚ HTTP ÐÒÏËÓÉ: Install from an FTP server through a http proxy FTP ÞÅÒÅÚ HTTP ÐÒÏËÓÉ üÔÁ ÏÐÃÉÑ ÇÏ×ÏÒÉÔ sysinstall ÉÓÐÏÌØÚÏ×ÁÔØ HTTP ÐÒÏÔÏËÏÌ (ËÁË Web-ÂÒÁÕÚÅÒ) ÄÌÑ ÒÁÂÏÔÙ Ó FTP ÞÅÒÅÚ ÐÒÏËÓÉ. ðÒÏËÓÉ ÂÕÄÅÔ ÔÒÁÎÓÌÉÒÏ×ÁÔØ ×ÓÅ ÚÁÐÒÏÓÙ É ÐÏÓÙÌÁÔØ ÉÈ ÎÁ FTP ÓÅÒ×ÅÒ. üÔÏ ÐÏÚ×ÏÌÑÅÔ ÐÒÏÈÏÄÉÔØ ÞÅÒÅÚ ÆÁÊÒ×ÏÌÌ, ÎÁ ËÏÔÏÒÏÍ FTP ÚÁÐÒÅÝÅÎ, ÎÏ ÅÓÔØ HTTP ÐÒÏËÓÉ. ÷ ÜÔÏÍ ÓÌÕÞÁÅ ÐÏÔÒÅÂÕÅÔÓÑ ÕËÁÚÁÔØ ÐÒÏËÓÉ É FTP ÓÅÒ×ÅÒ. äÌÑ ÒÁÂÏÔÙ Ó FTP ÞÅÒÅÚ ÐÒÏËÓÉ, ÎÅÏÂÈÏÄÉÍÏ ÐÏÍÅÓÔÉÔØ ÉÍÑ ÓÅÒ×ÅÒÁ ËÁË ÞÁÓÔØ ÉÍÅÎÉ ÐÏÌØÚÏ×ÁÔÅÌÑ ÐÏÓÌÅ ÚÎÁËÁ @. ðÒÏËÓÉ ÓÅÒ×ÅÒ ÏÂÍÁÎÅÔ ÎÁÓÔÏÑÝÉÊ ÓÅÒ×ÅÒ. îÁÐÒÉÍÅÒ, ÐÒÅÄÐÏÌÏÖÉÍ ÞÔÏ ×Ù ÈÏÔÉÔÅ ÐÒÏ×ÅÓÔÉ ÕÓÔÁÎÏ×ËÕ Ó ftp.FreeBSD.org, ÉÓÐÏÌØÚÕÑ FTP ÞÅÒÅÚ ÐÒÏËÓÉ foo.example.com, ÐÒÏÓÌÕÛÉ×ÁÀÝÅÍ ÐÏÒÔ 1234. ÷ ÜÔÏÍ ÓÌÕÞÁÅ, ×ÏÊÄÉÔÅ × ÍÅÎÀ ÐÁÒÁÍÅÔÒÏ×, ÕÓÔÁÎÏ×ÉÔÅ ÉÍÑ ÐÏÌØÚÏ×ÁÔÅÌÑ FTP ftp@ftp.FreeBSD.org, Á ×ÍÅÓÔÏ ÐÁÒÏÌÑ ××ÅÄÉÔÅ Ó×ÏÊ ÁÄÒÅÓ email. ÷ ËÁÞÅÓÔ×Å ÉÓÔÏÞÎÉËÁ ÕÓÔÁÎÏ×ËÉ ×ÙÂÅÒÉÔÅ FTP (ÉÌÉ ÐÁÓÓÉ×ÎÙÊ FTP, ÅÓÌÉ ÐÒÏËÓÉ ÅÇÏ ÐÏÄÄÅÒÖÉ×ÁÅÔ), É URL ftp://foo.example.com:1234/pub/FreeBSD. ôÁË ËÁË /pub/FreeBSD Ó ÓÅÒ×ÅÒÁ ftp.FreeBSD.org ÉÄÅÔ ÞÅÒÅÚ ÐÒÏËÓÉ foo.example.com, ×Ù ÓÍÏÖÅÔÅ ÐÒÏ×ÅÓÔÉ ÕÓÔÁÎÏ×ËÕ Ó ÜÔÏÇÏ ËÏÍÐØÀÔÅÒÁ (ÆÁÊÌÙ ÂÕÄÕÔ ÚÁÇÒÕÖÅÎÙ Ó ftp.FreeBSD.org ËÁË ÔÒÅÂÕÅÔÓÑ ÄÌÑ ÕÓÔÁÎÏ×ËÉ).
ðÏÄÔ×ÅÒÖÄÅÎÉÅ ÕÓÔÁÎÏ×ËÉ ôÅÐÅÒØ ÍÏÖÎÏ ÎÁÞÉÎÁÔØ ÕÓÔÁÎÏ×ËÕ. üÔÏ ÐÏÓÌÅÄÎÉÊ ÛÁÎÓ ÏÔÍÅÎÉÔØ ÕÓÔÁÎÏ×ËÕ, É ÔÁËÉÍ ÏÂÒÁÚÏÍ ÉÚÂÅÖÁÔØ ÉÚÍÅÎÅÎÉÊ ÎÁ ÖÅÓÔËÏÍ ÄÉÓËÅ. User Confirmation Requested Last Chance! Are you SURE you want to continue the installation? If you're running this on a disk with data you wish to save then WE STRONGLY ENCOURAGE YOU TO MAKE PROPER BACKUPS before proceeding! We can take no responsibility for lost disk contents! [ Yes ] No ÷ÙÂÅÒÉÔÅ &gui.yes; É ÎÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ÎÁÞÁÔØ. ÷ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ ÓÉÌØÎÏ ÚÁ×ÉÓÉÔ ÏÔ ×ÙÂÒÁÎÎÏÇÏ ÄÉÓÔÒÉÂÕÔÉ×ÎÏÇÏ ÎÁÂÏÒÁ, ÉÓÔÏÞÎÉËÁ ÕÓÔÁÎÏ×ËÉ É ÓËÏÒÏÓÔÉ ËÏÍÐØÀÔÅÒÁ. ðÏÑ×ÉÔÓÑ ÎÅÓËÏÌØËÏ ÓÏÏÂÝÅÎÉÊ Ï ÓÔÁÔÕÓÅ ÐÒÏÃÅÓÓÁ ÕÓÔÁÎÏ×ËÉ. õÓÔÁÎÏ×ËÁ ÂÕÄÅÔ ÚÁ×ÅÒÛÅÎÁ, ËÏÇÄÁ ÏÔÏÂÒÁÚÉÔÓÑ ÓÌÅÄÕÀÝÅÅ ÓÏÏÂÝÅÎÉÅ: Message Congratulations! You now have FreeBSD installed on your system. We will now move on to the final configuration questions. For any option you do not wish to configure, simply select No. If you wish to re-enter this utility after the system is up, you may do so by typing: /usr/sbin/sysinstall. [ OK ] [ Press enter or space ] îÁÖÍÉÔÅ Enter ÄÌÑ ÎÁÞÁÌÁ ÐÏÓÌÅÕÓÔÁÎÏ×ÏÞÎÏÊ ÎÁÓÔÒÏÊËÉ. ÷ÙÂÏÒ &gui.no; É ÎÁÖÁÔÉÅ Enter ÐÒÅÒ×ÅÔ ÐÒÏÃÅÓÓ ÕÓÔÁÎÏ×ËÉ, ÉÚÍÅÎÅÎÉÑ × ÓÉÓÔÅÍÕ ×ÎÅÓÅÎÙ ÎÅ ÂÕÄÕÔ. ðÏÑ×ÉÔÓÑ ÓÌÅÄÕÀÝÅÅ ÓÏÏÂÝÅÎÉÅ: Message Installation complete with some errors. You may wish to scroll through the debugging messages on VTY1 with the scroll-lock feature. You can also choose "No" at the next prompt and go back into the installation menus to retry whichever operations have failed. [ OK ] üÔÏ ÓÏÏÂÝÅÎÉÅ ÐÏÑ×ÉÌÏÓØ, ÐÏÓËÏÌØËÕ ÎÉÞÅÇÏ ÎÅ ÂÙÌÏ ÕÓÔÁÎÏ×ÌÅÎÏ. îÁÖÁÔÉÅ Enter ×ÅÒÎÅÔ ×ÁÓ × ÇÌÁ×ÎÏÅ ÍÅÎÀ ÕÓÔÁÎÏ×ËÉ, ÞÔÏÂÙ ×ÙÊÔÉ ÉÚ ÎÅÅ. ðÏÓÌÅ ÕÓÔÁÎÏ×ËÉ ðÏÓÌÅ ÕÓÐÅÛÎÏÊ ÕÓÔÁÎÏ×ËÉ ÎÅÏÂÈÏÄÉÍÏ ÎÁÓÔÒÏÉÔØ ÍÎÏÖÅÓÔ×Ï ÐÁÒÁÍÅÔÒÏ×. îÅËÏÔÏÒÙÅ ÐÁÒÁÍÅÔÒÙ ÍÏÇÕÔ ÂÙÔØ ÚÁÄÁÎÙ ÉÚ ÍÅÎÀ ÐÁÒÁÍÅÔÒÏ× ÐÏÓÌÅ ÕÓÔÁÎÏ×ËÉ, ÐÅÒÅÄ ÚÁÇÒÕÚËÏÊ ÕÓÔÁÎÏ×ÌÅÎÎÏÊ &os;, ÉÌÉ ÐÏÓÌÅ ÎÅÅ Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ sysinstall, ÇÄÅ ÎÁÄÏ ×ÙÂÒÁÔØ ÐÕÎËÔ Configure. îÁÓÔÒÏÊËÁ ÓÅÔÅ×ÙÈ ÕÓÔÒÏÊÓÔ× (Network Device Configuration) åÓÌÉ ×Ù ÎÁÓÔÒÁÉ×ÁÌÉ PPP ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÞÅÒÅÚ FTP, ÜÔÏÔ ÜËÒÁÎ ÎÅ ÐÏÑ×ÉÔÓÑ, É ÎÁÓÔÒÏÊËÕ ÍÏÖÎÏ ÂÕÄÅÔ ÐÒÏÉÚ×ÅÓÔÉ ÐÏÚÖÅ ËÁË ÏÐÉÓÁÎÏ ×ÙÛÅ. þÔÏÂÙ ÌÕÞÛÅ ÕÚÎÁÔØ Ï ÌÏËÁÌØÎÙÈ ÓÅÔÑÈ É ÎÁÓÔÒÏÊËÅ &os; × ËÁÞÅÓÔ×Å ÛÌÀÚÁ/ÍÁÒÛÒÕÔÉÚÁÔÏÒÁ, ÏÂÒÁÔÉÔÅÓØ Ë ÇÌÁ×Å óÌÏÖÎÙÅ ×ÏÐÒÏÓÙ ÒÁÂÏÔÙ × ÓÅÔÉ. User Confirmation Requested Would you like to configure any Ethernet or PPP network devices? [ Yes ] No äÌÑ ÎÁÓÔÒÏÊËÉ ÓÅÔÅ×ÏÇÏ ÕÓÔÒÏÊÓÔ×Á ×ÙÂÅÒÉÔÅ &gui.yes; É ÎÁÖÍÉÔÅ Enter. éÌÉ ÎÁÖÍÉÔÅ &gui.no;, ÞÔÏÂÙ ÐÒÏÄÏÌÖÉÔØ.
÷ÙÂÏÒ Ethernet ÕÓÔÒÏÊÓÔ×Á
÷ÙÂÅÒÉÔÅ ÉÎÔÅÒÆÅÊÓ ÄÌÑ ÎÁÓÔÒÏÊËÉ Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter. User Confirmation Requested Do you want to try IPv6 configuration of the interface? Yes [ No ] äÌÑ ÞÁÓÔÎÏÊ ÌÏËÁÌØÎÏÊ ÓÅÔÉ ÏÂÙÞÎÙÊ ÐÒÏÔÏËÏÌ ÉÎÔÅÒÎÅÔ (IPv4) ×ÐÏÌÎÅ ÄÏÓÔÁÔÏÞÅÎ, ÐÏÜÔÏÍÕ ×ÙÂÒÁÎÁ ËÎÏÐËÁ &gui.no; É ÎÁÖÁÔ Enter. åÓÌÉ ×Ù ÈÏÔÉÔÅ ÐÏÄÓÏÅÄÉÎÉÔØÓÑ Ë ÓÕÝÅÓÔ×ÕÀÝÅÊ ÓÅÔÉ IPv6 ÞÅÒÅÚ ÓÅÒ×ÅÒ RA, ×ÙÂÅÒÉÔÅ &gui.yes; É ÎÁÖÍÉÔÅ Enter. ðÏÉÓË RA ÓÅÒ×ÅÒÏ× ÚÁÊÍÅÔ ÎÅÓËÏÌØËÏ ÓÅËÕÎÄ. User Confirmation Requested Do you want to try DHCP configuration of the interface? Yes [ No ] åÓÌÉ DHCP (Dynamic Host Configuration Protocol) ÎÅ ÎÕÖÅÎ, ×ÙÂÅÒÉÔÅ &gui.no; Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter. ÷ÙÂÏÒ &gui.yes; ÚÁÐÕÓÔÉÔ dhclient, É, ÅÓÌÉ ×ÓÅ ÐÒÏÊÄÅÔ ÎÏÒÍÁÌØÎÏ, ÚÁÐÏÌÎÉÔ ÉÎÆÏÒÍÁÃÉÀ Ï ËÏÎÆÉÇÕÒÁÃÉÉ ÓÅÔÉ Á×ÔÏÍÁÔÉÞÅÓËÉ. ïÂÒÁÔÉÔÅÓØ Ë ÚÁ ÂÏÌÅÅ ÐÏÄÒÏÂÎÙÍÉ Ó×ÅÄÅÎÉÑÍÉ. óÌÅÄÕÀÝÉÊ ÜËÒÁÎ ËÏÎÆÉÇÕÒÁÃÉÉ ÓÅÔÉ ÐÏËÁÚÙ×ÁÅÔ ÎÁÓÔÒÏÊËÕ ÕÓÔÒÏÊÓÔ×Á Ethernet ÓÉÓÔÅÍÙ, ËÏÔÏÒÁÑ ÂÕÄÅÔ ÒÁÂÏÔÁÔØ ÛÌÀÚÏÍ ÄÌÑ ÌÏËÁÌØÎÏÊ ÓÅÔÉ.
îÁÓÔÒÏÊËÁ ÓÅÔÉ ÄÌÑ <replaceable>ed0</replaceable>
éÓÐÏÌØÚÕÊÔÅ Tab ÄÌÑ ×ÙÂÏÒÁ ÐÏÌÅÊ É ÚÁÐÏÌÎÅÎÉÑ ÉÈ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÉÍÉ ÄÁÎÎÙÍÉ: Host ðÏÌÎÏÅ ÉÍÑ ÈÏÓÔÁ, × ÜÔÏÍ ÐÒÉÍÅÒÅ k6-2.example.com. Domain éÍÑ ÄÏÍÅÎÁ, × ËÏÔÏÒÏÍ ÎÁÈÏÄÉÔÓÑ ×ÁÛ ËÏÍÐØÀÔÅÒ, × ÜÔÏÍ ÐÒÉÍÅÒÅ example.com. IPv4 Gateway IP ÈÏÓÔÁ, ÐÅÒÅÓÙÌÁÀÝÅÇÏ ÐÁËÅÔÙ ÎÁÒÕÖÕ ÌÏËÁÌØÎÏÊ ÓÅÔÉ. ÷ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÚÁÐÏÌÎÉÔØ ÅÇÏ, ÅÓÌÉ ÜÔÏ ËÏÍÐØÀÔÅÒ, ÐÏÄËÌÀÞÅÎÎÙÊ Ë ÓÅÔÉ. ïÓÔÁרÔÅ ÜÔÏ ÐÏÌÅ ÐÕÓÔÙÍ, ÅÓÌÉ ËÏÍÐØÀÔÅÒ Ñ×ÌÑÅÔÓÑ ÛÌÀÚÏÍ × ÉÎÔÅÒÎÅÔ ÄÌÑ ÓÅÔÉ. ûÌÀÚ IPv4 ÉÚ×ÅÓÔÅÎ ÔÁËÖÅ ËÁË ÛÌÀÚ ÐÏ ÕÍÏÌÞÁÎÉÀ ÉÌÉ ÍÁÒÛÒÕÔ ÐÏ ÕÍÏÌÞÁÎÉÀ. Name server IP ÁÄÒÅÓ ÍÅÓÔÎÏÇÏ ÓÅÒ×ÅÒÁ DNS. ÷ ÜÔÏÊ ÌÏËÁÌØÎÏÊ ÓÅÔÉ ÎÅÔ DNS ÓÅÒ×ÅÒÁ, ÐÏÜÔÏÍÕ ÉÓÐÏÌØÚÏ×ÁÎ IP ÁÄÒÅÓ DNS ÓÅÒ×ÅÒÁ ÐÒÏ×ÁÊÄÅÒÁ (208.163.10.2). IPv4 address IP ÁÄÒÅÓ, ÉÓÐÏÌØÚÏ×ÁÎÎÙÊ ÄÌÑ ÜÔÏÇÏ ÉÎÔÅÒÆÅÊÓÁ, 192.168.0.1 Netmask áÄÒÅÓ ÂÌÏËÁ, ÉÓÐÏÌØÚÏ×ÁÎÎÏÇÏ ÄÌÑ ÜÔÏÊ ÌÏËÁÌØÎÏÊ ÓÅÔÉ, ÜÔÏ 192.168.0.0 - 192.168.0.255. Ó ÍÁÓËÏÊ ÓÅÔÉ 255.255.255.0. äÏÐÏÌÎÉÔÅÌØÎÙÅ ÐÁÒÁÍÅÔÒÙ ÄÌÑ ifconfig ìÀÂÙÅ ÓÐÅÃÉÆÉÞÎÙÅ ÄÌÑ ÉÎÔÅÒÆÅÊÓÁ ÏÐÃÉÉ Ë ifconfig, ËÏÔÏÒÙÅ ×Ù ÈÏÔÉÔÅ ÄÏÂÁ×ÉÔØ. ÷ ÄÁÎÎÏÍ ÓÌÕÞÁÅ ÎÉÞÅÇÏ. éÓÐÏÌØÚÕÊÔÅ Tab ÄÌÑ ×ÙÂÏÒÁ &gui.ok; ÐÏÓÌÅ ÏËÏÎÞÁÎÉÑ ÎÁÓÔÒÏÊËÉ É ÎÁÖÍÉÔÅ Enter. User Confirmation Requested Would you like to bring the ed0 interface up right now? [ Yes ] No ÷ÙÂÏÒ &gui.yes; É ÎÁÖÁÔÉÅ Enter ××ÅÄÅÔ ËÏÍÐØÀÔÅÒ × ÓÅÔØ. ôÅÍ ÎÅ ÍÅÎÅÅ, ËÏÍÐØÀÔÅÒÕ ×ÓÅ ÅÝÅ ÔÒÅÂÕÅÔÓÑ ÐÅÒÅÚÁÇÒÕÚËÁ.
îÁÓÔÒÏÊËÁ ÛÌÀÚÁ (Configure Gateway) User Confirmation Requested Do you want this machine to function as a network gateway? [ Yes ] No åÓÌÉ ËÏÍÐØÀÔÅÒ ÂÕÄÅÔ ÛÌÀÚÏÍ ÄÌÑ ÌÏËÁÌØÎÏÊ ÓÅÔÉ, ÐÅÒÅÓÙÌÁÑ ÐÁËÅÔÙ ÍÅÖÄÕ ÄÒÕÇÉÍÉ ËÏÍÐØÀÔÅÒÁÍÉ, ×ÙÂÅÒÉÔÅ &gui.yes; É ÎÁÖÍÉÔÅ Enter. åÓÌÉ ÜÔÏ ÏÂÙÞÎÙÊ ËÏÍÐØÀÔÅÒ, ×ÙÂÅÒÉÔÅ &gui.no; É ÎÁÖÍÉÔÅ Enter ÄÌÑ ÐÒÏÄÏÌÖÅÎÉÑ. îÁÓÔÒÏÊËÁ ÓÅÒ×ÉÓÏ× ÉÎÔÅÒÎÅÔ (Configure Internet Services) User Confirmation Requested Do you want to configure inetd and the network services that it provides? Yes [ No ] åÓÌÉ ×ÙÂÒÁÎÁ &gui.no;, ÒÁÚÌÉÞÎÙÅ ÓÅÒ×ÉÓÙ, ÔÁËÉÅ ËÁË telnetd ÎÅ ÂÕÄÕÔ ÚÁÐÕÝÅÎÙ. üÔÏ ÏÚÎÁÞÁÅÔ, ÞÔÏ ÕÄÁÌÅÎÎÙÅ ÐÏÌØÚÏ×ÁÔÅÌÉ ÎÅ ÓÍÏÇÕÔ ÚÁÊÔÉ ÐÏ telnet ÎÁ ÜÔÏÔ ËÏÍÐØÀÔÅÒ. ìÏËÁÌØÎÙÅ ÐÏÌØÚÏ×ÁÔÅÌÉ ×ÓÅ ÖÅ ÓÍÏÇÕÔ ÚÁÈÏÄÉÔ ÎÁ ÕÄÁÌÅÎÎÙÅ ËÏÍÐØÀÔÅÒÙ ÐÏ telnet. üÔÉ ÓÅÒ×ÉÓÙ ÍÏÇÕÔ ÂÙÔØ ×ËÌÀÞÅÎÙ ÐÏÓÌÅ ÕÓÔÁÎÏ×ËÉ ÐÕÔÅÍ ÒÅÄÁËÔÉÒÏ×ÁÎÉÑ /etc/inetd.conf Ó ÐÏÍÏÝØÀ ×ÁÛÅÇÏ ÌÀÂÉÍÏÇÏ ÔÅËÓÔÏ×ÏÇÏ ÒÅÄÁËÔÏÒÁ. ïÂÒÁÝÁÊÔÅÓØ Ë ÚÁ ÂÏÌÅÅ ÐÏÄÒÏÂÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ. ÷ÙÂÅÒÉÔÅ &gui.yes; ÅÓÌÉ ÈÏÔÉÔÅ ÎÁÓÔÒÏÉÔØ ÜÔÉ ÓÅÒ×ÉÓÙ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ. ðÏÑ×ÉÔÓÑ ÄÏÐÏÌÎÉÔÅÌØÎÙÊ ÚÁÐÒÏÓ ÐÏÄÔ×ÅÒÖÄÅÎÉÑ: User Confirmation Requested The Internet Super Server (inetd) allows a number of simple Internet services to be enabled, including finger, ftp and telnetd. Enabling these services may increase risk of security problems by increasing the exposure of your system. With this in mind, do you wish to enable inetd? [ Yes ] No îÁÖÍÉÔÅ &gui.yes;, ÞÔÏÂÙ ÐÒÏÄÏÌÖÉÔØ. User Confirmation Requested inetd(8) relies on its configuration file, /etc/inetd.conf, to determine which of its Internet services will be available. The default FreeBSD inetd.conf(5) leaves all services disabled by default, so they must be specifically enabled in the configuration file before they will function, even once inetd(8) is enabled. Note that services for IPv6 must be separately enabled from IPv4 services. Select [Yes] now to invoke an editor on /etc/inetd.conf, or [No] to use the current settings. [ Yes ] No ÷ÙÂÏÒ &gui.yes; ÐÏÚ×ÏÌÉÔ ÄÏÂÁ×ÉÔØ ÓÅÒ×ÉÓÙ ÐÕÔÅÍ ÕÄÁÌÅÎÉÑ # ÐÅÒÅÄ ÎÁÞÁÌÏÍ ÓÔÒÏËÉ.
òÅÄÁËÔÉÒÏ×ÁÎÉÅ <filename>inetd.conf</filename>
ðÏÓÌÅ ÄÏÂÁ×ÌÅÎÉÑ ÎÕÖÎÙÈ ÓÅÒ×ÉÓÏ× ÎÁÖÁÔÉÅ Esc ÏÔÏÂÒÁÚÉÔ ÍÅÎÀ, ÐÏÚ×ÏÌÑÀÝÅÅ ×ÙÊÔÉ Ó ÓÏÈÒÁÎÅÎÉÅÍ ÉÚÍÅÎÅÎÉÊ.
îÁÓÔÒÏÊËÁ ×ÈÏÄÁ ÐÏ SSH SSH sshd User Confirmation Requested Would you like to enable SSH login? Yes [ No ] ÷ÙÂÏÒ &gui.yes; ÁËÔÉ×ÉÒÕÅÔ ÚÁÐÕÓË &man.sshd.8; — ÄÅÍÏÎÁ ÄÌÑ ÐÒÉÌÏÖÅÎÉÑ OpenSSH, ÞÔÏ × Ó×ÏÀ ÏÞÅÒÅÄØ ÐÏÚ×ÏÌÉÔ ÓÏÚÄÁ×ÁÔØ ÂÅÚÏÐÁÓÎÙÅ ÕÄÁÌ£ÎÎÙÅ ÓÏÅÄÉÎÅÎÉÑ c ×ÁÛÅÊ ÍÁÛÉÎÏÊ. úÁ ÂÏÌÅÅ ÄÅÔÁÌØÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ Ï OpenSSH ÏÂÒÁÔÉÔÅÓØ Ë . áÎÏÎÉÍÎÙÊ (Anonymous) FTP FTP ÁÎÏÎÉÍÎÙÊ User Confirmation Requested Do you want to have anonymous FTP access to this machine? Yes [ No ] úÁÐÒÅÝÅÎÉÅ ÁÎÏÎÉÍÎÏÇÏ FTP ÷ÙÂÏÒ ËÎÏÐËÉ ÐÏ ÕÍÏÌÞÁÎÉÀ &gui.no; É ÎÁÖÁÔÉÅ Enter ×ÓÅ ÖÅ ÐÏÚ×ÏÌÉÔ ÐÏÌØÚÏ×ÁÔÅÌÑÍ, ÉÍÅÀÝÉÍ ÕÞÅÔÎÙÅ ÚÁÐÉÓÉ Ó ÐÁÒÏÌÑÍÉ, ÉÓÐÏÌØÚÏ×ÁÔØ FTP ÄÌÑ ÄÏÓÔÕÐÁ Ë ËÏÍÐØÀÔÅÒÕ. òÁÚÒÅÛÅÎÉÅ ÁÎÏÎÉÍÎÏÇÏ FTP ëÔÏ ÕÇÏÄÎÏ ÓÍÏÖÅÔ ÐÏÌÕÞÉÔØ ÄÏÓÔÕÐ Ë ËÏÍÐØÀÔÅÒÕ, ÅÓÌÉ ×Ù ÒÁÚÒÅÛÉÔÅ ÁÎÏÎÉÍÎÙÅ ÓÏÅÄÉÎÅÎÉÑ FTP. ðÒÅÄ×ÁÒÉÔÅÌØÎÏ ÄÏÌÖÎÙ ÂÙÔØ ÒÁÓÓÍÏÔÒÅÎÙ ×ÏÚÍÏÖÎÙÅ ÐÒÏÂÌÅÍÙ Ó ÂÅÚÏÐÁÓÎÏÓÔØÀ. âÏÌÅÅ ÐÏÄÒÏÂÎÁÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÂÅÚÏÐÁÓÎÏÓÔÉ ÎÁÈÏÄÉÔÓÑ × . þÔÏÂÙ ÒÁÚÒÅÛÉÔØ ÁÎÏÎÉÍÎÙÊ FTP, ×ÙÂÅÒÉÔÅ &gui.yes;, ÉÓÐÏÌØÚÕÑ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ, É ÎÁÖÍÉÔÅ Enter. ïÔ ×ÁÓ ÐÏÔÒÅÂÕÅÔÓÑ ÄÏÐÏÌÎÉÔÅÌØÎÏÅ ÐÏÄÔ×ÅÒÖÄÅÎÉÅ: User Confirmation Requested Anonymous FTP permits un-authenticated users to connect to the system FTP server, if FTP service is enabled. Anonymous users are restricted to a specific subset of the file system, and the default configuration provides a drop-box incoming directory to which uploads are permitted. You must separately enable both inetd(8), and enable ftpd(8) in inetd.conf(5) for FTP services to be available. If you did not do so earlier, you will have the opportunity to enable inetd(8) again later. If you want the server to be read-only you should leave the upload directory option empty and add the -r command-line option to ftpd(8) in inetd.conf(5) Do you wish to continue configuring anonymous FTP? [ Yes ] No ÷ ÜÔÏÍ ÓÏÏÂÝÅÎÉÉ ÓËÁÚÁÎÏ: ÅÓÌÉ ×Ù ÈÏÔÉÔÅ ÒÁÚÒÅÛÉÔØ ÁÎÏÎÉÍÎÙÊ FTP ÄÏÓÔÕÐ, ÔÏ ×ÁÍ ÔÁËÖÅ ÐÒÉÄÅÔÓÑ ÁËÔÉ×ÉÒÏ×ÁÔØ (ÓÍ. ) ÓÁÍ ÓÅÒ×ÉÓ FTP × /etc/inetd.conf. ÷ÙÂÅÒÉÔÅ &gui.yes;, ÎÁÖÍÉÔÅ Enter, ÄÁÌÅÅ ÏÔÏÂÒÁÚÉÔÓÑ ÓÌÅÄÕÀÝÉÊ ÜËÒÁÎ:
îÁÓÔÒÏÊËÁ ÐÏ ÁÎÏÎÉÍÎÏÇÏ FTP ÐÏ ÕÍÏÌÞÁÎÉÀ
éÓÐÏÌØÚÕÑ Tab ÄÌÑ ×ÙÂÏÒÁ ÐÏÌÅÊ ××ÏÄÁ, ÚÁÐÏÌÎÉÔÅ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÕÀ ÉÎÆÏÒÍÁÃÉÀ: UID éÄÅÎÔÉÆÉËÁÔÏÒ, ËÏÔÏÒÙÊ ×Ù ÎÁÍÅÒÅ×ÁÅÔÅÓØ ÐÒÉÓ×ÏÉÔØ ÁÎÏÎÉÍÎÏÍÕ ÐÏÌØÚÏ×ÁÔÅÌÀ FTP. æÁÊÌÁÍ, ÚÁÇÒÕÖÅÎÎÙÍ ÎÁ FTP, ÂÕÄÅÔ ÐÒÉÓ×ÏÅÎ ÜÔÏÔ ÉÄÅÎÔÉÆÉËÁÔÏÒ. Group ÷ ÜÔÕ ÇÒÕÐÐÕ ÂÕÄÅÔ ×ÈÏÄÉÔØ ÁÎÏÎÉÍÎÙÊ ÐÏÌØÚÏ×ÁÔÅÌØ FTP. Comment óÔÒÏËÁ Ó ÏÐÉÓÁÎÉÅÍ ÁÎÏÎÉÍÎÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ; ÏÎÁ ÂÕÄÅÔ ×ÎÅÓÅÎÁ × /etc/passwd. FTP Root Directory þÁÓÔØ ÉÅÒÁÒÈÉÉ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ, × ËÏÔÏÒÏÊ ÂÕÄÕÔ ÈÒÁÎÉÔØÓÑ ÆÁÊÌÙ, ÄÏÓÔÕÐÎÙÅ ÁÎÏÎÉÍÎÏÍÕ ÐÏÌØÚÏ×ÁÔÅÌÀ FTP. Upload Subdirectory ðÏÄËÁÔÁÌÏÇ, ÄÏÓÔÕÐÎÙÊ ÎÁ ÚÁÐÉÓØ ÁÎÏÎÉÍÎÏÍÕ ÐÏÌØÚÏ×ÁÔÅÌÀ FTP. ëÏÒÎÅ×ÏÊ ËÁÔÁÌÏÇ FTP ÐÏ ÕÍÏÌÞÁÎÉÀ ÂÕÄÅÔ ÒÁÚÍÅÝÅÎ × /var. åÓÌÉ × ÎÅÍ ÐÒÅÄÐÏÌÏÖÉÔÅÌØÎÏ ÎÅ È×ÁÔÁÅÔ ÍÅÓÔÁ ÄÌÑ ÄÌÑ ÎÕÖÄ FTP, ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ ËÁÔÁÌÏÇ /usr, ×ÙÂÒÁ× ËÏÒÎÅ×ÏÊ ËÁÔÁÌÏÇ FTP (FTP root directory) /usr/ftp. ëÏÇÄÁ ÂÕÄÕÔ ×ÙÂÒÁÎÙ ÐÏÄÈÏÄÑÝÉÅ ÚÎÁÞÅÎÉÑ, ÎÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ÐÒÏÄÏÌÖÉÔØ. User Confirmation Requested Create a welcome message file for anonymous FTP users? [ Yes ] No åÓÌÉ ×Ù ×ÙÂÅÒÅÔÅ &gui.yes; É ÎÁÖÍÅÔÅ Enter, ÚÁÐÕÓÔÉÔÓÑ ÒÅÄÁËÔÏÒ, ÐÏÚ×ÏÌÑÀÝÉÊ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÓÏÏÂÝÅÎÉÅ FTP.
òÅÄÁËÔÉÒÏ×ÁÎÉÅ FTP Welcome Message
üÔÏÔ ÔÅËÓÔÏ×ÙÊ ÒÅÄÁËÔÏÒ ÎÁÚÙ×ÁÅÔÓÑ ee. éÓÐÏÌØÚÕÊÔÅ ÉÎÓÔÒÕËÃÉÉ, ÞÔÏÂÙ ÉÚÍÅÎÉÔØ ÓÏÏÂÝÅÎÉÅ, ÉÌÉ ÉÚÍÅÎÉÔÅ ÓÏÏÂÝÅÎÉÅ ÐÏÚÖÅ, ÉÓÐÏÌØÚÕÑ ×ÙÂÒÁÎÎÙÊ ×ÁÍÉ ÒÅÄÁËÔÏÒ. ïÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ, ÞÔÏ ÉÍÑ/ÒÁÓÐÏÌÏÖÅÎÉÅ ÆÁÊÌÁ ÐÏËÁÚÁÎÙ ×ÎÉÚÕ ÏËÎÁ ÒÅÄÁËÔÏÒÁ. îÁÖÍÉÔÅ Esc É ÐÏÑ×ÉÔÓÑ ÍÅÎÀ Ó ÐÕÎËÔÏÍ ÐÏ ÕÍÏÌÞÁÎÉÀ a) leave editor (×ÙÊÔÉ ÉÚ ÒÅÄÁËÔÏÒÁ). îÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ×ÙÊÔÉ É ÐÒÏÄÏÌÖÉÔØ. îÁÖÍÉÔÅ Enter ÅÝÅ ÒÁÚ, ÞÔÏÂÙ ÓÏÈÒÁÎÉÔØ ÉÚÍÅÎÅÎÉÑ, ÅÓÌÉ ÏÎÉ ÂÙÌÉ ÓÄÅÌÁÎÙ.
îÁÓÔÒÏÊËÁ ÓÅÔÅ×ÏÊ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ (Configure Network File System) óÅÔÅ×ÁÑ ÆÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ (Network File System, NFS) ÐÏÚ×ÏÌÑÅÔ ÓÏ×ÍÅÓÔÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ ÆÁÊÌÙ × ÓÅÔÉ. ëÏÍÐØÀÔÅÒ ÍÏÖÅÔ ÂÙÔØ ÎÁÓÔÒÏÅÎ ËÁË ÓÅÒ×ÅÒ, ËÌÉÅÎÔ, ÉÌÉ ËÁË ÔÏ É ÄÒÕÇÏÅ. ïÂÒÁÔÉÔÅÓØ Ë ÚÁ ÂÏÌÅÅ ÐÏÄÒÏÂÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ. óÅÒ×ÅÒ NFS (NFS Server) User Confirmation Requested Do you want to configure this machine as an NFS server? Yes [ No ] åÓÌÉ ×ÁÍ ÎÅ ÎÕÖÅÎ NFS ÓÅÒ×ÅÒ, ×ÙÂÅÒÉÔÅ &gui.no; É ÎÁÖÍÉÔÅ Enter. åÓÌÉ ×ÙÂÒÁÎ ÐÕÎËÔ &gui.yes;, ÐÏÑ×ÉÔÓÑ ÓÏÏÂÝÅÎÉÅ, ÇÏ×ÏÒÑÝÅÅ Ï ÔÏÍ, ÞÔÏ ÄÏÌÖÅÎ ÂÙÔØ ÓÏÚÄÁÎ ÆÁÊÌ exports. Message Operating as an NFS server means that you must first configure an /etc/exports file to indicate which hosts are allowed certain kinds of access to your local filesystems. Press [Enter] now to invoke an editor on /etc/exports [ OK ] îÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ÐÒÏÄÏÌÖÉÔØ. úÁÐÕÓÔÉÔÓÑ ÔÅËÓÔÏ×ÙÊ ÒÅÄÁËÔÏÒ, ÐÏÚ×ÏÌÑÀÝÉÊ ÓÏÚÄÁÔØ É ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ÆÁÊÌ exports.
òÅÄÁËÔÉÒÏ×ÁÎÉÅ <filename>exports</filename>
éÓÐÏÌØÚÕÊÔÅ ÉÎÓÔÒÕËÃÉÉ ÄÌÑ ÄÏÂÁ×ÌÅÎÉÑ ÜËÓÐÏÒÔÉÒÕÅÍÙÈ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ ÓÅÊÞÁÓ, ÉÌÉ ÐÏÚÄÎÅÅ Ó ÐÏÍÏÝØÀ ×ÙÂÒÁÎÎÏÇÏ ×ÁÍÉ ÔÅËÓÔÏ×ÏÇÏ ÒÅÄÁËÔÏÒÁ. ïÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ, ÞÔÏ ÉÍÑ/ÒÁÓÐÏÌÏÖÅÎÉÅ ÆÁÊÌÁ ÐÏËÁÚÁÎÙ ×ÎÉÚÕ ÏËÎÁ ÒÅÄÁËÔÏÒÁ. îÁÖÍÉÔÅ Esc É ÐÏÑ×ÉÔÓÑ ÍÅÎÀ Ó ÐÕÎËÔÏÍ ÐÏ ÕÍÏÌÞÁÎÉÀ a) leave editor. îÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ×ÙÊÔÉ É ÐÒÏÄÏÌÖÉÔØ.
ëÌÉÅÎÔ NFS (NFS Client) NFS ËÌÉÅÎÔ ÐÏÚ×ÏÌÑÅÔ ÏÒÇÁÎÉÚÏ×ÁÔØ ÄÏÓÔÕÐ Ë ÓÅÒ×ÅÒÁÍ NFS. User Confirmation Requested Do you want to configure this machine as an NFS client? Yes [ No ] ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ ×ÙÂÅÒÉÔÅ &gui.yes; ÉÌÉ &gui.no;, ËÁË ÐÏÔÒÅÂÕÅÔÓÑ, É ÎÁÖÍÉÔÅ Enter.
îÁÓÔÒÏÊËÉ ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ (System Console Settings) åÓÔØ ÎÅÓËÏÌØËÏ ÐÁÒÁÍÅÔÒÏ× ÄÌÑ ÎÁÓÔÒÏÊËÉ ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ. User Confirmation Requested Would you like to customize your system console settings? [ Yes ] No äÌÑ ÐÒÏÓÍÏÔÒÁ É ÎÁÓÔÒÏÊËÉ ÐÁÒÁÍÅÔÒÏ× ×ÙÂÅÒÉÔÅ &gui.yes; É ÎÁÖÍÉÔÅ Enter.
ðÁÒÁÍÅÔÒÙ ÎÁÓÔÒÏÊËÉ ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ
þÁÓÔÏ ÉÓÐÏÌØÚÕÅÍÁÑ ÏÐÃÉÑ ÜÔÏ ÈÒÁÎÉÔÅÌØ ÜËÒÁÎÁ (screen saver). éÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ Saver É ÎÁÖÍÉÔÅ Enter.
ðÁÒÁÍÅÔÒÙ ÈÒÁÎÉÔÅÌÑ ÜËÒÁÎÁ
÷ÙÂÅÒÉÔÅ ÐÏÄÈÏÄÑÝÉÊ ÈÒÁÎÉÔÅÌØ ÜËÒÁÎÁ Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter. ïÐÑÔØ ÐÏÑ×ÉÔÓÑ ÍÅÎÀ ÎÁÓÔÒÏÊËÉ ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ. ÷ÒÅÍÑ ÐÏ ÕÍÏÌÞÁÎÉÀ 300 ÓÅËÕÎÄ. äÌÑ ÉÚÍÅÎÅÎÉÑ ×ÒÅÍÅÎÎÏÇÏ ÉÎÔÅÒ×ÁÌÁ ×ÙÂÅÒÉÔÅ Saver ÅÝÅ ÒÁÚ. ÷ ÍÅÎÀ ÎÁÓÔÒÏÅË ÈÒÁÎÉÔÅÌÑ ÜËÒÁÎÁ ×ÙÂÅÒÉÔÅ Timeout Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter. ðÏÑ×ÉÔÓÑ ÍÅÎÀ:
÷ÒÅÍÅÎÎÏÊ ÉÎÔÅÒ×ÁÌ ÈÒÁÎÉÔÅÌÑ ÜËÒÁÎÁ
úÎÁÞÅÎÉÅ ÍÏÖÅÔ ÂÙÔØ ÉÚÍÅÎÅÎÏ, ÚÁÔÅÍ ×ÙÂÅÒÉÔÅ &gui.ok; É ÎÁÖÍÉÔÅ Enter ÄÌÑ ×ÏÚ×ÒÁÔÁ × ÍÅÎÀ ÎÁÓÔÒÏÊËÉ ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ.
÷ÙÈÏÄ ÉÚ ÍÅÎÀ ËÏÎÆÉÇÕÒÁÃÉÉ ËÏÎÓÏÌÉ
÷ÙÂÏÒ Exit É ÎÁÖÁÔÉÅ Enter ×ÅÒÎÅÔ ×ÁÓ Ë ÐÏÓÌÅÕÓÔÁÎÏ×ÏÞÎÏÊ ÎÁÓÔÒÏÊËÅ.
õÓÔÁÎÏ×ËÁ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ (Setting The Time Zone) õÓÔÁÎÏ×ËÁ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ ÎÁ ËÏÍÐØÀÔÅÒÅ ÐÏÚ×ÏÌÉÔ ÅÍÕ Á×ÔÏÍÁÔÉÞÅÓËÉ ×ÎÏÓÉÔØ ÐÏÐÒÁ×ËÉ Ë ÍÅÓÔÎÏÍÕ ×ÒÅÍÅÎÉ É ÐÒÁ×ÉÌØÎÏ ×ÙÐÏÌÎÑÔØ ÄÒÕÇÉÅ, Ó×ÑÚÁÎÎÙÅ Ó ÞÁÓÏ×ÙÍ ÐÏÑÓÏÍ ÆÕÎËÃÉÉ. ðÒÉÍÅÒ ÐÒÉ×ÅÄÅÎ ÄÌÑ ËÏÍÐØÀÔÅÒÁ, ÒÁÓÐÏÌÏÖÅÎÎÏÇÏ × ×ÏÓÔÏÞÎÏÍ ÞÁÓÏ×ÏÍ ÐÏÑÓÅ óÏÅÄÉÎÅÎÎÙÈ ûÔÁÔÏ×. ÷ÁÛ ×ÙÂÏÒ ÂÕÄÅÔ ÚÁ×ÉÓÅÔØ ÏÔ ×ÁÛÅÇÏ ÇÅÏÇÒÁÆÉÞÅÓËÏÇÏ ÐÏÌÏÖÅÎÉÑ. User Confirmation Requested Would you like to set this machine's time zone now? [ Yes ] No ÷ÙÂÅÒÉÔÅ &gui.yes; É ÎÁÖÍÉÔÅ Enter ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ. User Confirmation Requested Is this machine's CMOS clock set to UTC? If it is set to local time or you don't know, please choose NO here! Yes [ No ] ÷ÙÂÅÒÉÔÅ &gui.yes; ÉÌÉ &gui.no; × ÚÁ×ÉÓÉÍÏÓÔÉ ÏÔ ÎÁÓÔÒÏÅË ÞÁÓÏ× ËÏÍÐØÀÔÅÒÁ É ÎÁÖÍÉÔÅ Enter.
÷ÙÂÏÒ ÒÅÇÉÏÎÁ
óÏÏÔ×ÅÔÓÔ×ÕÀÝÉÊ ÒÅÇÉÏÎ ×ÙÂÒÁÎ Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÁÔ Enter.
÷ÙÂÏÒ ÓÔÒÁÎÙ
÷ÙÂÅÒÉÔÅ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÕÀ ÓÔÒÁÎÕ Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter.
÷ÙÂÏÒ ÞÁÓÏ×ÏÇÏ ÐÏÑÓÁ
÷ÙÂÒÁÎ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÉÊ ÞÁÓÏ×ÏÊ ÐÏÑÓ Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÁÔ Enter. Confirmation Does the abbreviation 'EDT' look reasonable? [ Yes ] No ðÒÁ×ÉÌØÎÏ ÂÕÄÅÔ ÓÏÇÌÁÓÉÔØÓÑ Ó ÎÁÚÎÁÞÅÎÉÅÍ ÁÂÂÒÅ×ÉÁÔÕÒÙ ×ÒÅÍÅÎÎÏÇÏ ÐÏÑÓÁ. åÓÌÉ ÏÎÁ ÐÏÄÈÏÄÉÔ, ÎÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ÐÒÏÄÏÌÖÉÔØ ÐÏÓÌÅÕÓÔÁÎÏ×ÏÞÎÕÀ ÎÁÓÔÒÏÊËÕ.
îÁÓÔÒÏÊËÁ ÍÙÛÉ (Mouse Settings) üÔÉ ÎÁÓÔÒÏÊËÉ ÐÏÚ×ÏÌÑÔ ×ÙÒÅÚÁÔØ É ×ÓÔÁ×ÌÑÔØ ÔÅËÓÔ × ËÏÎÓÏÌÉ É ÐÏÌØÚÏ×ÁÔÅÌØÓËÉÈ ÐÒÏÇÒÁÍÍÁÈ Ó ÐÏÍÏÝØÀ ÔÒÅÈËÎÏÐÏÞÎÏÊ ÍÙÛÉ. åÓÌÉ ÉÓÐÏÌØÚÕÅÔÓÑ Ä×ÕÈËÎÏÐÏÞÎÁÑ ÍÙÛØ, ÏÂÒÁÔÉÔÅÓØ Ë ÓÔÒÁÎÉÃÅ ÓÐÒÁ×ÏÞÎÉËÁ &man.moused.8; ÐÏÓÌÅ ÕÓÔÁÎÏ×ËÉ, ÞÔÏÂÙ ÕÚÎÁÔØ ÐÏÄÒÏÂÎÏÓÔÉ Ï ÜÍÕÌÑÃÉÉ ÔÒÅÈËÎÏÐÏÞÎÏÊ ÍÙÛÉ. üÔÏÔ ÐÒÉÍÅÒ ÐÒÉ×ÅÄÅÎ ÄÌÑ ÎÁÓÔÒÏÊËÉ ÎÅ-USB ÍÙÛÉ (ÎÁÐÒÉÍÅÒ ÍÙÛÉ ÄÌÑ ÐÏÒÔÁ PS/2 ÉÌÉ COM): User Confirmation Requested Does this system have a PS/2, serial, or bus mouse? [ Yes ] No ÷ÙÂÅÒÉÔÅ &gui.yes; ÄÌÑ PS/2 ÍÙÛÉ, ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÏÊ ÍÙÛÉ ÉÌÉ ÍÙÛÉ ÔÉÐÁ bus mouse. ÷ÙÂÅÒÉÔÅ &gui.no; ÄÌÑ USB ÍÙÛÉ É ÎÁÖÍÉÔÅ Enter.
÷ÙÂÏÒ ÐÒÏÔÏËÏÌÁ ÍÙÛÉ
éÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ Type É ÎÁÖÍÉÔÅ Enter.
õÓÔÁÎÏ×ËÁ ÐÒÏÔÏËÏÌÁ ÍÙÛÉ
÷ ÜÔÏÍ ÐÒÉÍÅÒÅ ÉÓÐÏÌØÚÏ×ÁÎÁ PS/2 ÍÙÛØ, ÐÏÜÔÏÍÕ ÐÏÄÏÊÄÅÔ ÐÒÏÔÏËÏÌ ÐÏ ÕÍÏÌÞÁÎÉÀ Auto. þÔÏÂÙ ÉÚÍÅÎÉÔØ ÐÒÏÔÏËÏÌ, ÉÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ ÄÒÕÇÏÇÏ ÐÕÎËÔÁ. õÂÅÄÉÔÅÓØ, ÞÔÏ ×ÙÂÒÁÎ &gui.ok;, É ÎÁÖÍÉÔÅ Enter ÄÌÑ ×ÙÈÏÄÁ ÉÚ ÍÅÎÀ.
îÁÓÔÒÏÊËÁ ÐÏÒÔÁ ÍÙÛÉ
éÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ Port É ÎÁÖÍÉÔÅ Enter.
õÓÔÁÎÏ×ËÁ ÐÏÒÔÁ ÍÙÛÉ
ë ÜÔÏÊ ÓÉÓÔÅÍÅ ÐÏÄËÌÀÞÅÎÁ ÍÙÛØ PS/2, ÐÏÜÔÏÍÕ ÐÏÄÈÏÄÉÔ ÚÎÁÞÅÎÉÅ ÐÏ ÕÍÏÌÞÁÎÉÀ PS/2. þÔÏÂÙ ÉÚÍÅÎÉÔØ ÐÏÒÔ, ÉÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter.
úÁÐÕÓË ÄÁÅÍÏÎÁ ÍÙÛÉ
îÁËÏÎÅÃ, ÉÓÐÏÌØÚÕÊÔÅ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ Enable, ÚÁÔÅÍ ÎÁÖÍÉÔÅ Enter ÄÌÑ ÚÁÐÕÓËÁ É ÔÅÓÔÉÒÏ×ÁÎÉÑ ÄÁÅÍÏÎÁ ÍÙÛÉ.
ðÒÏ×ÅÒËÁ ÄÁÅÍÏÎÁ ÍÙÛÉ
ðÏÄ×ÉÇÁÊÔÅ ËÕÒÓÏÒ ÐÏ ÜËÒÁÎÕ É ÕÂÅÄÉÔÅÓØ, ÞÔÏ ÏÎ Ä×ÉÖÅÔÓÑ ÐÒÁ×ÉÌØÎÏ. åÓÌÉ ÜÔÏ ÔÁË, ×ÙÂÅÒÉÔÅ &gui.yes; É ÎÁÖÍÉÔÅ Enter. åÓÌÉ ÎÅÔ, ÍÙÛØ ÎÅ ÂÙÌÁ ÐÒÁ×ÉÌØÎÏ ÎÁÓÔÒÏÅÎÁ — ×ÙÂÅÒÉÔÅ &gui.no; É ÐÏÐÒÏÂÕÊÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÒÕÇÉÅ ÏÐÃÉÉ ÎÁÓÔÒÏÊËÉ. ÷ÙÂÅÒÉÔÅ Exit Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter ÄÌÑ ×ÏÚ×ÒÁÔÁ Ë ÐÏÓÌÅÕÓÔÁÎÏ×ÏÞÎÏÊ ÎÁÓÔÒÏÊËÅ.
õÓÔÁÎÏ×ËÁ ÐÁËÅÔÏ× (Install Packages) ðÁËÅÔÙ — ÜÔÏ ÐÒÅËÏÍÐÉÌÉÒÏ×ÁÎÎÙÅ ÂÉÎÁÒÎÙÅ ÆÁÊÌÙ É ÜÔÏ ÕÄÏÂÎÙÊ ÓÐÏÓÏ ÕÓÔÁÎÏ×ËÉ ÐÒÏÇÒÁÍÍ. ÷ ËÁÞÅÓÔ×Å ÐÒÉÍÅÒÁ ÐÏËÁÚÁÎÁ ÕÓÔÁÎÏ×ËÁ ÏÄÎÏÇÏ ÐÁËÅÔÁ. åÓÌÉ ÐÏÔÒÅÂÕÅÔÓÑ, ÍÏÖÎÏ ÕÓÔÁÎÏ×ÉÔØ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ÐÁËÅÔÙ. ðÏÓÌÅ ÕÓÔÁÎÏ×ËÉ ÄÌÑ ÄÏÂÁ×ÌÅÎÉÑ ÐÁËÅÔÏ× ÍÏÖÅÔ ÂÙÔØ ÉÓÐÏÌØÚÏ×ÁÎÁ ËÏÍÁÎÄÁ sysinstall. User Confirmation Requested The FreeBSD package collection is a collection of hundreds of ready-to-run applications, from text editors to games to WEB servers and more. Would you like to browse the collection now? [ Yes ] No ÷ÙÂÏÒ [ Yes ] É ÎÁÖÁÔÉÅ Enter ÐÒÉ×ÅÄÅÔ Ë ÐÏÑ×ÌÅÎÉÀ ÜËÒÁÎÁ ×ÙÂÏÒÁ ÐÁËÅÔÏ×:
÷ÙÂÏÒ ËÁÔÅÇÏÒÉÉ ÐÁËÅÔÏ×
ôÏÌØËÏ ÐÁËÅÔÙ Ó ÔÅËÕÝÅÇÏ ÎÏÓÉÔÅÌÑ ÄÏÓÔÕÐÎÙ ÄÌÑ ÕÓÔÁÎÏ×ËÉ × ÌÀÂÏÅ ×ÒÅÍÑ. ÷ÓÅ ÄÏÓÔÕÐÎÙÅ ÐÁËÅÔÙ ÂÕÄÕÔ ÐÏËÁÚÁÎÙ ÅÓÌÉ ×ÙÂÒÁÔØ ËÁÔÅÇÏÒÉÀ All, ÍÏÖÎÏ ÔÁËÖÅ ×ÙÂÉÒÁÔØ ÏÔÄÅÌØÎÙÅ ËÁÔÅÇÏÒÉÉ. ðÅÒÅÊÄÉÔÅ Ë ×ÙÂÒÁÎÎÏÊ ËÁÔÅÇÏÒÉÉ Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter. ðÏÑ×ÉÔÓÑ ÍÅÎÀ, ÓÏÄÅÒÖÁÝÅÅ ÄÏÓÔÕÐÎÙÅ × ÄÁÎÎÏÊ ËÁÔÅÇÏÒÉÉ ÐÁËÅÔÙ.
÷ÙÂÏÒ ÐÁËÅÔÏ×
÷ÙÂÒÁÎÁ ÏÂÏÌÏÞËÁ bash. ÷ÙÂÅÒÉÔÅ ×ÓÅ ÎÅÏÂÈÏÄÉÍÙÅ ÐÁËÅÔÙ, ÐÅÒÅÍÅÝÁÑÓØ ÐÏ ÍÅÎÀ É ÎÁÖÉÍÁÑ ËÌÁ×ÉÛÕ ÐÒÏÂÅÌÁ ÎÁ ×ÙÂÉÒÁÅÍÙÈ ÐÁËÅÔÁÈ. ëÒÁÔËÏÅ ÏÐÉÓÁÎÉÅ ÐÁËÅÔÁ ÂÕÄÅÔ ÐÏÑ×ÌÑÔØÓÑ × ÎÉÖÎÅÊ ÌÅ×ÏÊ ÞÁÓÔÉ ÜËÒÁÎÁ. îÁÖÁÔÉÅ Tab ÐÅÒÅËÌÀÞÁÅÔ ÍÅÖÄÕ ÐÏÓÌÅÄÎÉÍ ×ÙÂÒÁÎÎÙÍ ÐÁËÅÔÏÍ, &gui.ok;, É &gui.cancel;. ðÏÓÌÅ ÔÏÇÏ, ËÁË ÂÕÄÅÔ ÚÁËÏÎÞÅÎÁ ÏÔÍÅÔËÁ ÐÁËÅÔÏ× ÄÌÑ ÕÓÔÁÎÏ×ËÉ, ÎÁÖÍÉÔÅ Tab ÏÄÉÎ ÒÁÚ ÄÌÑ ÐÅÒÅËÌÀÞÅÎÉÑ ÎÁ &gui.ok; É ÎÁÖÍÉÔÅ Enter ÄÌÑ ÐÅÒÅËÌÀÞÅÎÉÑ ÎÁ ÍÅÎÀ ×ÙÂÏÒÁ ÐÁËÅÔÏ×. îÁÖÉÍÁÑ ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ×ÌÅ×Ï ÉÌÉ ×ÐÒÁ×Ï, ÍÏÖÎÏ ÐÅÒÅËÌÀÞÁÔØÓÑ ÍÅÖÄÕ &gui.ok; É &gui.cancel;. üÔÏÔ ÍÅÔÏÄ ÍÏÖÅÔ ÂÙÔØ ÐÒÉÍÅÎÅÎ ÔÁËÖÅ ÄÌÑ ×ÙÂÏÒÁ &gui.ok; É ×ÏÚ×ÒÁÔÁ Ë ÍÅÎÀ ×ÙÂÏÒÁ ÐÁËÅÔÏ× ÎÁÖÁÔÉÅÍ Enter.
õÓÔÁÎÏ×ËÁ ÐÁËÅÔÏ×
éÓÐÏÌØÚÕÊÔÅ Tab É ËÌÁ×ÉÛÉ ÎÁ×ÉÇÁÃÉÉ ÄÌÑ ×ÙÂÏÒÁ [ Install ] É ÎÁÖÍÉÔÅ Enter. ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÐÏÄÔ×ÅÒÄÉÔØ ÕÓÔÁÎÏ×ËÕ ÐÁËÅÔÏ×:
ðÏÄÔ×ÅÒÖÄÅÎÉÅ ÕÓÔÁÎÏ×ËÉ ÐÁËÅÔÏ×
÷ÙÂÏÒ &gui.ok; É ÎÁÖÁÔÉÅ Enter ÚÁÐÕÓÔÉÔ ÕÓÔÁÎÏ×ËÕ ÐÁËÅÔÏ×. ÷Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ ÂÕÄÕÔ ×ÙÄÁ×ÁÔØÓÑ ÓÏÏÂÝÅÎÉÑ. ïÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ ÎÁ ×ÏÚÍÏÖÎÙÅ ÓÏÏÂÝÅÎÉÑ Ï ÏÛÉÂËÁÈ. ðÏÓÌÅ ÕÓÔÁÎÏ×ËÉ ÐÁËÅÔÏ× ÎÁÓÔÒÏÊËÁ ÐÒÏÄÏÌÖÉÔÓÑ. åÓÌÉ ×Ù ÎÅ ×ÙÂÒÁÌÉ ÎÉ ÏÄÉÎ ÉÚ ÐÁËÅÔÏ× É ÈÏÔÉÔÅ ×ÅÒÎÕÔØÓÑ Ë ÚÁ×ÅÒÛÅÎÉÀ ÎÁÓÔÒÏÊËÉ, ×ÙÂÅÒÉÔÅ Install × ÌÀÂÏÍ ÓÌÕÞÁÅ.
äÏÂÁ×ÌÅÎÉÅ ÐÏÌØÚÏ×ÁÔÅÌÅÊ/ÇÒÕÐÐ (Add Users/Groups) ÷ ÐÒÏÃÅÓÓÅ ÕÓÔÁÎÏ×ËÉ ÎÕÖÎÏ ÄÏÂÁ×ÉÔØ ÈÏÔÑ ÂÙ ÏÄÎÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ, ÞÔÏÂÙ ÉÓÐÏÌØÚÏ×ÁÔØ ÓÉÓÔÅÍÕ ÂÅÚ ×ÈÏÄÁ ÐÏÄ root. ëÏÒÎÅ×ÏÊ ËÁÔÁÌÏÇ ÏÂÙÞÎÏ ÍÁÌ É ÚÁÐÕÓË ÐÒÉÌÏÖÅÎÉÊ ÐÏÄ root ÂÙÓÔÒÏ ÚÁÐÏÌÎÉÔ ÅÇÏ. îÉÖÅ ÐÏËÁÚÁÎÏ ÐÒÅÄÕÐÒÅÖÄÅÎÉÅ: User Confirmation Requested Would you like to add any initial user accounts to the system? Adding at least one account for yourself at this stage is suggested since working as the "root" user is dangerous (it is easy to do things which adversely affect the entire system). [ Yes ] No ÷ÙÂÅÒÉÔÅ &gui.yes; É ÎÁÖÍÉÔÅ Enter, ÞÔÏÂÙ ÐÒÏÄÏÌÖÉÔØ ÄÏÂÁ×ÌÅÎÉÅ ÐÏÌØÚÏ×ÁÔÅÌÑ.
÷ÙÂÏÒ User (ÐÏÌØÚÏ×ÁÔÅÌØ)
÷ÙÂÅÒÉÔÅ User Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter.
÷ÏÄ ÉÎÆÏÒÍÁÃÉÉ Ï ÐÏÌØÚÏ×ÁÔÅÌÅ
ðÒÉ ×ÙÂÏÒÅ ÐÏÌÅÊ Ó ÐÏÍÏÝØÀ Tab × ÎÉÖÎÅÊ ÞÁÓÔÉ ÜËÒÁÎÁ ÂÕÄÅÔ ÐÏÑ×ÌÑÔØÓÑ ÏÐÉÓÁÎÉÅ, ÐÏÍÏÇÁÀÝÅÅ ××ÅÓÔÉ ÎÅÏÂÈÏÄÉÍÕÀ ÉÎÆÏÒÍÁÃÉÀ: ìÏÇÉÎ (Login ID) éÍÑ ÎÏ×ÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ (ÏÂÑÚÁÔÅÌØÎÏ). UID þÉÓÌÏ×ÏÊ ID (ÉÄÅÎÔÉÆÉËÁÔÏÒ) ÄÌÑ ÜÔÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ (ÏÓÔÁרÔÅ ÐÕÓÔÙÍ ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÇÏ ×ÙÂÏÒÁ). çÒÕÐÐÁ (Group) éÍÑ ÇÒÕÐÐÙ ÜÔÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ (ÏÓÔÁרÔÅ ÐÕÓÔÙÍ ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÇÏ ×ÙÂÏÒÁ). ðÁÒÏÌØ (Password) ðÁÒÏÌØ ÜÔÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ (ÚÁÐÏÌÎÑÊÔÅ ÜÔÏ ÐÏÌÅ Ó ÏÓÔÏÒÏÖÎÏÓÔØÀ!). ðÏÌÎÏÅ ÉÍÑ ðÏÌÎÏÅ ÉÍÑ ÐÏÌØÚÏ×ÁÔÅÌÑ (ËÏÍÍÅÎÔÁÒÉÊ). þÌÅÎ ÇÒÕÐÐ (Member groups) çÒÕÐÐÙ, Ë ËÏÔÏÒÙÍ ÐÒÉÎÁÄÌÅÖÉÔ ÐÏÌØÚÏ×ÁÔÅÌØ (Ô.Å. ÉÍÅÅÔ ÐÒÁ×Á ÄÏÓÔÕÐÁ). äÏÍÁÛÎÉÊ ËÁÔÁÌÏÇ (Home directory) äÏÍÁÛÎÉÊ ËÁÔÁÌÏÇ ÐÏÌØÚÏ×ÁÔÅÌÑ (ÏÓÔÁרÔÅ ÐÕÓÔÙÍ ÄÌÑ ×ÙÂÏÒÁ ÐÏ ÕÍÏÌÞÁÎÉÀ). ïÂÏÌÏÞËÁ (Login shell) ïÂÏÌÏÞËÁ ÐÏÌØÚÏ×ÁÔÅÌÑ, ÚÁÐÕÓËÁÅÍÁÑ ÐÒÉ ×ÈÏÄÅ × ÓÉÓÔÅÍÕ (ÏÓÔÁרÔÅ ÐÕÓÔÙÍ ÄÌÑ ÏÂÏÌÏÞËÉ ÐÏ ÕÍÏÌÞÁÎÉÀ, ÎÁÐÒÉÍÅÒ /bin/sh). ïÂÏÌÏÞËÁ ÂÙÌÁ ÉÚÍÅÎÅÎÁ Ó /bin/sh ÎÁ /usr/local/bin/bash ÄÌÑ ÉÓÐÏÌØÚÏ×ÁÎÉÑ bash, ËÏÔÏÒÁÑ ÂÙÌÁ ÐÅÒÅÄ ÜÔÉÍ ÕÓÔÁÎÏ×ÌÅÎÁ ÉÚ ÐÁËÅÔÁ. îÅ ÐÙÔÁÊÔÅÓØ ÉÓÐÏÌØÚÏ×ÁÔØ ÎÅÓÕÝÅÓÔ×ÕÀÝÕÀ ÏÂÏÌÏÞËÕ, ×Ù ÎÅ ÓÍÏÖÅÔÅ ×ÏÊÔÉ × ÓÉÓÔÅÍÕ. îÁÉÂÏÌÅÅ ÞÁÓÔÏ ÉÓÐÏÌØÚÕÅÍÁÑ × ÍÉÒÅ BSD ÏÂÏÌÏÞËÁ ÜÔÏ C shell, ËÏÔÏÒÕÀ ÍÏÖÎÏ ÏÂÏÚÎÁÞÉÔØ ËÁË /bin/tcsh. ðÏÌØÚÏ×ÁÔÅÌØ ÂÙÌ ÄÏÂÁ×ÌÅÎ × ÇÒÕÐÐÕ wheel, ÞÔÏÂÙ ÉÍÅÔØ ×ÏÚÍÏÖÎÏÓÔØ ÓÔÁÔØ ÓÕÐÅÒÐÏÌØÚÏ×ÁÔÅÌÅÍ Ó ÐÒÉ×ÉÌÅÇÉÑÍÉ root. ëÏÇÄÁ ×ÓÅ ÂÕÄÅÔ ××ÅÄÅÎÏ, ÎÁÖÍÉÔÅ &gui.ok; É ÍÅÎÀ ÕÐÒÁ×ÌÅÎÉÑ ÐÏÌØÚÏ×ÁÔÅÌÑÍÉ É ÇÒÕÐÐÁÍÉ (User and Group Management) ÐÏÑ×ÉÔÓÑ ÓÎÏ×Á:
÷ÙÈÏÄ ÉÚ ÍÅÎÀ ÕÐÒÁ×ÌÅÎÉÑ ÐÏÌØÚÏ×ÁÔÅÌÑÍÉ É ÇÒÕÐÐÁÍÉ
óÅÊÞÁÓ ÔÁËÖÅ ÍÏÖÎÏ ÄÏÂÁ×ÉÔØ ÇÒÕÐÐÙ, ÅÓÌÉ ÉÚ×ÅÓÔÎÏ, ÄÌÑ ÞÅÇÏ ÏÎÉ ÐÏÔÒÅÂÕÀÔÓÑ. éÎÁÞÅ × ÜÔÏ ÍÅÎÀ ÍÏÖÎÏ ×ÏÊÔÉ, ÚÁÐÕÓÔÉ× sysinstall ÐÏÓÌÅ ÏËÏÎÞÁÎÉÑ ÕÓÔÁÎÏ×ËÉ. ðÏÓÌÅ ÚÁ×ÅÒÛÅÎÉÑ ÄÏÂÁ×ÌÅÎÉÑ ÐÏÌØÚÏ×ÁÔÅÌÅÊ, ×ÙÂÅÒÉÔÅ Exit Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter ÄÌÑ ÐÒÏÄÏÌÖÅÎÉÑ ÕÓÔÁÎÏ×ËÉ.
õÓÔÁÎÏ×ËÁ ÐÁÒÏÌÑ <username>root</username> Message Now you must set the system manager's password. This is the password you'll use to log in as "root". [ OK ] [ Press enter or space ] îÁÖÍÉÔÅ Enter ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÐÁÒÏÌÑ root. îÅÏÂÈÏÄÉÍÏ Ä×Á ÒÁÚÁ ÐÒÁ×ÉÌØÎÏ ××ÅÓÔÉ ÐÁÒÏÌØ. éÚÌÉÛÎÅ ÕÐÏÍÉÎÁÔØ, ÞÔÏ ÄÏÌÖÎÁ ÂÙÔØ ×ÏÚÍÏÖÎÏÓÔØ ×ÏÓÓÔÁÎÏ×ÌÅÎÉÑ ÐÁÒÏÌÑ, ÅÓÌÉ ×Ù ÅÇÏ ÚÁÂÕÄÅÔÅ. ïÂÒÁÔÉÔÅ ×ÎÉÍÁÎÉÅ, ÞÔÏ ÎÉ ÎÁÂÉÒÁÅÍÙÊ ÐÁÒÏÌØ, ÎÉ Ú×ÅÚÄÏÞËÉ ÎÁ ÜËÒÁÎ ÎÅ ×ÙÄÁÀÔÓÑ. New password: Retype new password : õÓÔÁÎÏ×ËÁ ÐÒÏÄÏÌÖÉÔÓÑ ÐÏÓÌÅ ÕÓÐÅÛÎÏÇÏ ××ÏÄÁ ÐÁÒÏÌÑ. ÷ÙÈÏÄ ÉÚ ÕÓÔÁÎÏ×ËÉ (Exiting Install) åÓÌÉ ÎÕÖÎÏ ÎÁÓÔÒÏÉÔØ ÄÏÐÏÌÎÉÔÅÌØÎÙÅ ÓÅÔÅ×ÙÅ ÕÓÔÒÏÊÓÔ×Á, ÉÌÉ ÐÒÏÉÚ×ÅÓÔÉ ÄÒÕÇÉÅ ÎÁÓÔÒÏÊËÉ, ×Ù ÍÏÖÅÔÅ ÓÄÅÌÁÔØ ÜÔÏ ÓÅÊÞÁÓ ÉÌÉ ÐÏÓÌÅ ÕÓÔÁÎÏ×ËÉ Ó ÐÏÍÏÝØÀ sysinstall. User Confirmation Requested Visit the general configuration menu for a chance to set any last options? Yes [ No ] ÷ÙÂÅÒÉÔÅ &gui.no; Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter ÄÌÑ ×ÏÚ×ÒÁÔÁ Ë ÇÌÁ×ÎÏÍÕ ÍÅÎÀ ÕÓÔÁÎÏ×ËÉ.
÷ÙÈÏÄ ÉÚ ÕÓÔÁÎÏ×ËÉ
÷ÙÂÅÒÉÔÅ [X Exit Install] Ó ÐÏÍÏÝØÀ ËÌÁ×ÉÛ ÎÁ×ÉÇÁÃÉÉ É ÎÁÖÍÉÔÅ Enter. âÕÄÅÔ ÚÁÄÁÎ ×ÏÐÒÏÓ Ï ÐÏÄÔ×ÅÒÖÄÅÎÉÉ ×ÙÈÏÄÁ ÉÚ ÕÓÔÁÎÏ×ËÉ: User Confirmation Requested Are you sure you wish to exit? The system will reboot. [ Yes ] No ÷ÙÂÅÒÉÔÅ &gui.yes;. åÓÌÉ ×Ù ÚÁÇÒÕÖÁÌÉÓØ Ó ÐÒÉ×ÏÄÁ CDROM, ÓÌÅÄÕÀÝÅÅ ÓÏÏÂÝÅÎÉÅ ÎÁÐÏÍÎÉÔ ×ÁÍ Ï ÎÅÏÂÈÏÄÉÍÏÓÔÉ ÉÚ×ÌÅÞØ ÄÉÓË: Message Be sure to remove the media from the drive. [ OK ] [ Press enter or space ] CDROM ÚÁÂÌÏËÉÒÏ×ÁÎ, ÐÏËÁ ËÏÍÐØÀÔÅÒ ÎÅ ÎÁÞÎÅÔ ÐÅÒÅÇÒÕÖÁÔØÓÑ. CDROM ÂÕÄÅÔ ÒÁÚÂÌÏËÉÒÏ×ÁÎ É ÄÉÓË ÎÕÖÎÏ ÂÕÄÅÔ ÉÚ×ÌÅÞØ ÉÚ ÐÒÉ×ÏÄÁ (ÂÙÓÔÒÏ). ÷ÙÂÅÒÉÔÅ &gui.ok;. óÉÓÔÅÍÁ ÎÁÞÎÅÔ ÐÅÒÅÚÁÇÒÕÚËÕ, ÓÍÏÔÒÉÔÅ ÚÁ ÓÏÏÂÝÅÎÉÑÍÉ Ï ÏÛÉÂËÁÈ, ËÏÔÏÒÙÅ ÍÏÇÕÔ ÐÏÑ×ÉÔØÓÑ. úÁ ÐÏÄÒÏÂÎÏÓÔÑÍÉ ÐÏ ÐÒÏÃÅÓÓÕ ÚÁÇÒÕÚËÉ ÏÂÒÁÔÉÔÅÓØ Ë .
ôÏÍ òÏÄÅÓ ôÅËÓÔ ÐÒÅÄÏÓÔÁ×ÉÌ îÁÓÔÒÏÊËÁ ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÓÅÔÅ×ÙÈ ÓÅÒ×ÉÓÏ× îÁÓÔÒÏÊËÁ ÓÅÔÅ×ÙÈ ÓÅÒ×ÉÓÏ× ÍÏÖÅÔ ÂÙÔØ ÐÕÇÁÀÝÅÊ ÚÁÄÁÞÅÊ ÄÌÑ ÎÏ×ÙÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ, ÅÓÌÉ Õ ÎÉÈ ÎÅÔ ÏÐÙÔÁ × ÜÔÏÊ ÏÂÌÁÓÔÉ. òÁÂÏÔÁ × ÓÅÔÉ, ×ËÌÀÞÁÑ ÉÎÔÅÒÎÅÔ, ËÒÉÔÉÞÎÁ ÄÌÑ ÍÎÏÇÉÈ ÓÏ×ÒÅÍÅÎÎÙÈ ÏÐÅÒÁÃÉÏÎÎÙÈ ÓÉÓÔÅÍ, ×ËÌÀÞÁÑ &os;; ÏÞÅÎØ ×ÁÖÎÏ ÉÍÅÔØ ÎÅËÏÔÏÒÙÅ ÚÎÁÎÉÑ Ï ÄÏÐÏÌÎÉÔÅÌØÎÙÈ ÓÅÔÅ×ÙÈ ×ÏÚÍÏÖÎÏÓÔÑÈ &os;. îÁÓÔÒÁÉ×ÁÑ ÉÈ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ, ÐÏÌØÚÏ×ÁÔÅÌØ ÐÏÌÕÞÁÅÔ ÎÅËÏÔÏÒÕÀ ÉÎÆÏÒÍÁÃÉÀ Ï ÒÁÚÌÉÞÎÙÈ ÄÏÓÔÕÐÎÙÈ ÓÅÒ×ÉÓÁÈ. óÅÔÅ×ÙÅ ÓÅÒ×ÉÓÙ — ÜÔÏ ÐÒÏÇÒÁÍÍÙ, ÐÒÉÎÉÍÁÀÝÉÅ ÄÁÎÎÙÅ ÉÚ ÌÀÂÏÊ ÔÏÞËÉ ÓÅÔÉ. þÔÏÂÙ ÕÂÅÄÉÔØÓÑ, ÞÔÏ ÜÔÉ ÐÒÏÇÒÁÍÍÙ ÎÅ ÄÅÌÁÀÔ ÎÉÞÅÇÏ ×ÒÅÄÎÏÇÏ, ÔÒÅÂÕÅÔÓÑ ÏÓÏÂÏÅ ×ÎÉÍÁÎÉÅ. ë ÓÏÖÁÌÅÎÉÀ, ÐÒÏÇÒÁÍÍÉÓÔÙ ÎÅ ÓÏ×ÅÒÛÅÎÎÙ É ×ÒÅÍÑ ÏÔ ×ÒÅÍÅÎÉ ÄÏÐÕÓËÁÀÔ ÏÛÉÂËÉ × ÓÅÔÅ×ÙÈ ÓÅÒ×ÉÓÁÈ; ÜÔÉ ÏÛÉÂËÉ ÐÏÚ×ÏÌÑÀÔ ÁÔÁËÕÀÝÉÍ ×ÚÌÏÍÁÔØ ÉÈ É ÉÓÐÏÌØÚÏ×ÁÔØ × ÓÏÂÓÔ×ÅÎÎÙÈ ÃÅÌÑÈ. ÷ÁÖÎÏ, ÞÔÏÂÙ ×Ù ×ËÌÀÞÁÌÉ ÓÅÔÅ×ÙÅ ÓÅÒ×ÉÓÙ ÔÏÌØËÏ × ÔÏÍ ÓÌÕÞÁÅ, ÅÓÌÉ ÚÎÁÅÔÅ, ËÁËÉÅ ÓÅÒ×ÉÓÙ ÎÕÖÎÙ. ÷ ÓÌÕÞÁÅ ÓÏÍÎÅÎÉÊ ÌÕÞÛÅ ÎÅ ×ËÌÀÞÁÔØ ÓÅÒ×ÉÓ, ÐÏËÁ ÏÎ ÎÅ ÐÏÎÁÄÏÂÉÔÓÑ. ÷Ù ×ÓÅÇÄÁ ÍÏÖÅÔÅ ×ËÌÀÞÉÔØ ÅÇÏ ÐÏÚÖÅ, ÚÁÐÕÓÔÉ× sysinstall ÅÝÅ ÒÁÚ, ÉÌÉ ÉÓÐÏÌØÚÕÑ ×ÏÚÍÏÖÎÏÓÔÉ, ÐÒÅÄÏÓÔÁ×ÌÑÅÍÙÅ ÆÁÊÌÏÍ /etc/rc.conf. ÷ÙÂÏÒ ÏÐÃÉÉ Networking ÏÔÏÂÒÁÚÉÔ ÍÅÎÀ, ÐÏÈÏÖÅÅ ÎÁ ÜÔÏ:
÷ÅÒÈÎÑÑ ÞÁÓÔØ ÍÅÎÀ ÎÁÓÔÒÏÊËÉ ÓÅÔÉ (Network Configuration)
ðÅÒ×ÁÑ ÏÐÃÉÑ, Interfaces (ÉÎÔÅÒÆÅÊÓÙ), ÂÙÌÁ ÒÁÎÅÅ ÏÐÉÓÁÎÁ × , ÜÔÕ ÏÐÃÉÀ ÍÏÖÎÏ ÐÒÏÉÇÎÏÒÉÒÏ×ÁÔØ. ÷ÙÂÏÒ ÏÐÃÉÉ AMD ÄÏÂÁ×ÉÔ ÐÏÄÄÅÒÖËÕ BSD ÕÔÉÌÉÔÙ Á×ÔÏÍÁÔÉÞÅÓËÏÇÏ ÍÏÎÔÉÒÏ×ÁÎÉÑ. ïÎÁ ÏÂÙÞÎÏ ÉÓÐÏÌØÚÕÅÔÓÑ ×ÍÅÓÔÅ Ó ÐÒÏÔÏËÏÌÏÍ NFS (ÓÍÏÔÒÉÔÅ ÎÉÖÅ) ÄÌÑ Á×ÔÏÍÁÔÉÞÅÓËÏÇÏ ÍÏÎÔÉÒÏ×ÁÎÉÑ ÕÄÁÌÅÎÎÙÈ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ. úÄÅÓØ ÎÅ ÔÒÅÂÕÅÔÓÑ ÓÐÅÃÉÁÌØÎÏÊ ËÏÎÆÉÇÕÒÁÃÉÉ. óÌÅÄÕÀÝÁÑ ÌÉÎÉÑ ÜÔÏ ÏÐÃÉÑ ÆÌÁÇÉ AMD (flags). ëÏÇÄÁ ÜÔÁ ÏÐÃÉÑ ×ÙÂÒÁÎÁ, ÐÏÑ×ÉÔÓÑ ÍÅÎÀ ÄÌÑ ××ÏÄÁ ÓÐÅÃÉÆÉÞÎÙÈ ÆÌÁÇÏ× AMD. íÅÎÀ ÕÖÅ ÓÏÄÅÒÖÉÔ ÎÁÂÏÒ ÒÁÚÌÉÞÎÙÈ ÏÐÃÉÊ: -a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map ïÐÃÉÑ ÕËÁÚÙ×ÁÅÔ ÍÅÓÔÏÒÁÓÐÏÌÏÖÅÎÉÅ ÍÏÎÔÉÒÏ×ÁÎÉÑ ÓÉÓÔÅÍ ÐÏ ÕÍÏÌÞÁÎÉÀ, × ÜÔÏÍ ÐÒÉÍÅÒÅ /.amd_mnt. ïÐÃÉÑ ÕËÁÚÙ×ÁÅÔ log ÆÁÊÌ ÐÏ ÕÍÏÌÞÁÎÉÀ; ÔÅÍ ÎÅ ÍÅÎÅÅ, ÅÓÌÉ ÄÌÑ ×ÅÄÅÎÉÑ ÌÏÇÏ× ÉÓÐÏÌØÚÕÅÔÓÑ syslogd, ×ÓÅ ÌÏÇÉ ÏÔÐÒÁ×ÌÑÀÔÓÑ ÄÁÅÍÏÎÕ ÓÉÓÔÅÍÎÙÈ ÌÏÇÏ×. ëÁÔÁÌÏÇ /host ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÍÏÎÔÉÒÏ×ÁÎÉÑ ÜËÓÐÏÒÔÉÒÏ×ÁÎÎÙÈ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ Ó ÕÄÁÌÅÎÎÏÇÏ ÈÏÓÔÁ, Á /net ÄÌÑ ÍÏÎÔÉÒÏ×ÁÎÉÑ ÜËÓÐÏÒÔÉÒÏ×ÁÎÎÙÈ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ Ó IP ÁÄÒÅÓÁ. æÁÊÌ /etc/amd.map ÏÐÒÅÄÅÌÑÅÔ ÏÐÃÉÉ ÐÏ ÕÍÏÌÞÁÎÉÀ ÄÌÑ ÍÏÎÔÉÒÕÅÍÙÈ AMD ËÁÔÁÌÏÇÏ×. FTP ÁÎÏÎÉÍÎÙÊ ïÐÃÉÑ Anon FTP ÐÏÚ×ÏÌÑÅÔ ÐÏÌÕÞÉÔØ ÁÎÏÎÉÍÎÙÊ ÄÏÓÔÕÐ Ë FTP. ÷ÙÂÅÒÉÔÅ ÅÅ, ÞÔÏÂÙ ÓÄÅÌÁÔØ ÜÔÏÔ ËÏÍÐØÀÔÅÒ ÁÎÏÎÉÍÎÙÍ FTP ÓÅÒ×ÅÒÏÍ. ðÏÍÎÉÔÅ Ï ÒÉÓËÅ ÂÅÚÏÐÁÓÎÏÓÔÉ, ÓÏÚÄÁ×ÁÅÍÏÍ ÜÔÏÊ ÏÐÃÉÅÊ. âÕÄÅÔ ÏÔÏÂÒÁÖÅÎÏ ÅÝÅ ÏÄÎÏ ÍÅÎÀ ÄÌÑ ÒÁÚßÑÓÎÅÎÉÑ ÒÉÓËÁ ÂÅÚÏÐÁÓÎÏÓÔÉ É ÄÌÑ ÂÏÌÅÅ ÔÏÎËÏÊ ÎÁÓÔÒÏÊËÉ. ïÐÃÉÑ Gateway ÓÄÅÌÁÅÔ ËÏÍÐØÀÔÅÒ ÛÌÀÚÏÍ, ËÁË ÂÙÌÏ ÏÂßÑÓÎÅÎÏ ÒÁÎÅÅ. üÔÏÔ ÐÕÎËÔ ÍÏÖÅÔ ÂÙÔØ ÉÓÐÏÌØÚÏ×ÁÎ ÄÌÑ ÏÔÍÅÎÙ ÏÐÃÉÉ Gateway, ÅÓÌÉ ÏÎÁ ÂÙÌÁ ÏÛÉÂÏÞÎÏ ÕÓÔÁÎÏ×ÌÅÎÁ × ÐÒÏÃÅÓÓÅ ÕÓÔÁÎÏ×ËÉ. ïÐÃÉÀ Inetd ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÌÑ ÎÁÓÔÒÏÊËÉ ÉÌÉ ÐÏÌÎÏÇÏ ÏÔËÌÀÞÅÎÉÑ ÄÁÅÍÏÎÁ &man.inetd.8;, ËÁË ÂÙÌÏ ÏÐÉÓÁÎÏ ×ÙÛÅ. ïÐÃÉÑ Mail ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÎÁÓÔÒÏÊËÉ ÓÉÓÔÅÍÎÏÇÏ MTA ÐÏ ÕÍÏÌÞÁÎÉÀ (Mail Transfer Agent, ÁÇÅÎÔ ÐÅÒÅÄÁÞÉ ÐÏÞÔÙ). ÷ÙÂÏÒ ÜÔÏÊ ÏÐÃÉÉ ÐÒÉ×ÅÄÅÔ Ë ÐÏÑ×ÌÅÎÉÀ ÓÌÅÄÕÀÝÅÇÏ ÍÅÎÀ:
÷ÙÂÏÒ MTA ÐÏ ÕÍÏÌÞÁÎÉÀ
úÄÅÓØ ÐÒÅÄÏÓÔÁ×ÌÑÅÔÓÑ ×ÙÂÏÒ MTA ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÐÏ ÕÍÏÌÞÁÎÉÀ. MTA ÜÔÏ ÐÏÞÔÏ×ÙÊ ÓÅÒ×ÅÒ, ÄÏÓÔÁ×ÌÑÀÝÉÊ ÐÏÞÔÕ ÐÏÌØÚÏ×ÁÔÅÌÑÍ ÓÉÓÔÅÍÙ ÉÌÉ ÉÎÔÅÒÎÅÔ. ÷ÙÂÏÒ Sendmail ÐÒÉ×ÅÄÅÔ Ë ÕÓÔÁÎÏ×ËÅ ÐÏÐÕÌÑÒÎÏÇÏ ÓÅÒ×ÅÒÁ sendmail, MTA ÐÏ ÕÍÏÌÞÁÎÉÀ ÄÌÑ &os;. ïÐÃÉÑ Sendmail local ÎÁÓÔÒÏÉÔ sendmail × ËÁÞÅÓÔ×Å MTA ÐÏ ÕÍÏÌÞÁÎÉÀ, ÎÏ ÏÔËÌÀÞÉÔ ×ÏÚÍÏÖÎÏÓÔØ ÐÏÌÕÞÅÎÉÑ ×ÈÏÄÑÝÅÊ ÐÏÞÔÙ ÉÚ ÉÎÔÅÒÎÅÔ. äÒÕÇÉÅ MTA, ÐÒÅÄÓÔÁ×ÌÅÎÎÙÅ ÚÄÅÓØ, Postfix É Exim, ÄÅÊÓÔ×ÕÀÔ ÐÏÄÏÂÎÏ Sendmail. ïÂÁ ÏÎÉ ÄÏÓÔÁ×ÌÑÀÔ ÐÏÞÔÕ; ÔÅÍ ÎÅ ÍÅÎÅÅ, ÎÅËÏÔÏÒÙÅ ÐÏÌØÚÏ×ÁÔÅÌÉ ÐÒÅÄÐÏÞÉÔÁÀÔ ÜÔÉ ÁÌØÔÅÒÎÁÔÉ×Ù sendmail. ðÏÓÌÅ ×ÙÂÏÒÁ MTA ÉÌÉ ÐÒÏÐÕÓËÁ ÜÔÏÇÏ ÐÕÎËÔÁ ÐÏÑ×ÉÔÓÑ ÍÅÎÀ ÎÁÓÔÒÏÊËÉ ÓÅÔÉ ÓÏ ÓÌÅÄÕÀÝÅÊ ÏÐÃÉÅÊ, ËÌÉÅÎÔ NFS. ëÌÉÅÎÔ NFS ÐÏÚ×ÏÌÑÅÔ ÎÁÓÔÒÏÉÔØ ÓÉÓÔÅÍÕ ÄÌÑ ÓÏÅÄÉÎÅÎÉÑ Ó ÓÅÒ×ÅÒÏÍ ÞÅÒÅÚ NFS. óÅÒ×ÅÒ NFS ÄÁÅÔ ÄÒÕÇÉÍ ÍÁÛÉÎÁÍ ÄÏÓÔÕÐ Ë ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÅ ÞÅÒÅÚ ÐÒÏÔÏËÏÌ NFS. åÓÌÉ ÜÔÏ ÏÔÄÅÌØÎÏ ÓÔÏÑÝÉÊ ËÏÍÐØÀÔÅÒ, ÏÐÃÉÀ ÍÏÖÎÏ ÎÅ ×ÙÂÉÒÁÔØ. NFS ÍÏÖÅÔ ÐÏÔÒÅÂÏ×ÁÔØ ÄÏÐÏÌÎÉÔÅÌØÎÏÊ ÎÁÓÔÒÏÊËÉ ÐÏÚÖÅ; ÏÂÒÁÝÁÊÔÅÓØ Ë ÚÁ ÂÏÌÅÅ ÐÏÄÒÏÂÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ Ï ÎÁÓÔÒÏÊËÅ ÓÅÒ×ÅÒÁ É ËÌÉÅÎÔÁ. îÉÖÅ ÎÁÈÏÄÉÔÓÑ ÏÐÃÉÑ NFS ÓÅÒ×ÅÒ, ÐÏÚ×ÏÌÑÀÝÁÑ ×ÁÍ ÎÁÓÔÒÏÉÔØ ÓÉÓÔÅÍÕ ÄÌÑ ÒÁÂÏÔÙ × ËÁÞÅÓÔ×Å NFS ÓÅÒ×ÅÒÁ. ïÎÁ ÄÏÂÁ×ÌÑÅÔ ÔÒÅÂÕÅÍÕÀ ÉÎÆÏÒÍÁÃÉÀ ÄÌÑ ÚÁÐÕÓËÁ ÐÒÏÃÅÄÕÒÙ ×ÙÚÏ×Á ÕÄÁÌÅÎÎÙÈ ÓÅÒ×ÉÓÏ× RPC (remote procedure call services). RPC ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÏÒÇÁÎÉÚÁÃÉÉ ÓÏÅÄÉÎÅÎÉÑ ÍÅÖÄÕ ÈÏÓÔÁÍÉ É ÐÒÏÇÒÁÍÍÁÍÉ. óÌÅÄÕÀÝÁÑ ÓÔÒÏËÁ ÜÔÏ Ntpdate, ËÏÔÏÒÁÑ ÏÔ×ÅÞÁÅÔ ÚÁ ÓÉÎÈÒÏÎÉÚÁÃÉÀ ×ÒÅÍÅÎÉ. ëÏÇÄÁ ÜÔÁ ÏÐÃÉÑ ×ÙÂÒÁÎÁ, ÐÏÑ×ÉÔÓÑ ÐÒÉÂÌÉÚÉÔÅÌØÎÏ ÔÁËÏÅ ÍÅÎÀ:
îÁÓÔÒÏÊËÁ Ntpdate
÷ÙÂÅÒÉÔÅ ÉÚ ÜÔÏÇÏ ÍÅÎÀ ÂÌÉÖÁÊÛÉÊ Ë ×ÁÛÅÍÕ ÍÅÓÔÏÎÁÈÏÖÄÅÎÉÀ ÓÅÒ×ÅÒ. ÷ÙÂÏÒ ÂÌÉÖÁÊÛÅÇÏ ÓÅÒ×ÅÒÁ ÓÄÅÌÁÅÔ ÓÉÎÈÒÏÎÉÚÁÃÉÀ ×ÒÅÍÅÎÉ ÂÏÌÅÅ ÔÏÞÎÏÊ, ÐÏÓËÏÌØËÕ Õ ÂÏÌÅÅ ÄÁÌØÎÅÇÏ ÓÅÒ×ÅÒÁ ÍÏÖÅÔ ÂÙÔØ ÂÏÌÅÅ ÄÌÉÎÎÁÑ ÚÁÄÅÒÖËÁ ÓÏÅÄÉÎÅÎÉÑ. óÌÅÄÕÀÝÁÑ ÏÐÃÉÑ ÜÔÏ ×ÙÂÏÒ PCNFSD. üÔÁ ÏÐÃÉÑ ÕÓÔÁÎÁ×ÌÉ×ÁÅÔ ÐÁËÅÔ net/pcnfsd ÉÚ ëÏÌÌÅËÃÉÉ ðÏÒÔÏ×. üÔÏ ÐÏÌÅÚÎÁÑ ÕÔÉÌÉÔÁ, ÐÒÅÄÏÓÔÁ×ÌÑÀÝÁÑ ÓÅÒ×ÉÓÙ Á×ÔÏÒÉÚÁÃÉÉ NFS ÄÌÑ ÓÉÓÔÅÍ, × ËÏÔÏÒÙÈ ÓÏÂÓÔ×ÅÎÎÁÑ ÏÔÓÕÔÓÔ×ÕÅÔ, ÔÁËÉÈ ËÁË Microsoft &ms-dos;. ôÅÐÅÒØ ×Ù ÍÏÖÅÔÅ ÐÒÏËÒÕÔÉÔØ ÍÅÎÀ ÎÅÍÎÏÇÏ ×ÎÉÚ, ÞÔÏÂÙ Õ×ÉÄÅÔØ ÄÒÕÇÉÅ ÏÐÃÉÉ:
îÉÖÎÑÑ ÞÁÓÔØ ÍÅÎÀ ÎÁÓÔÒÏÊËÉ ÓÅÔÉ
õÔÉÌÉÔÙ &man.rpcbind.8;, &man.rpc.statd.8; É &man.rpc.lockd.8; ÄÌÑ ÕÄÁÌÅÎÎÏÇÏ ×ÙÚÏ×Á ÐÒÏÃÅÄÕÒ (Remote Procedure Calls, RPC). õÔÉÌÉÔÁ rpcbind ÕÐÒÁ×ÌÑÅÔ ÓÏÅÄÉÎÅÎÉÅÍ ÍÅÖÄÕ NFS ÓÅÒ×ÅÒÁÍÉ É ËÌÉÅÎÔÁÍÉ, ÏÎÁ ÔÒÅÂÕÅÔÓÑ ÓÅÒ×ÅÒÕ NFS ÄÌÑ ËÏÒÒÅËÔÎÏÊ ÒÁÂÏÔÙ. äÁÅÍÏÎ rpc.statd ×ÚÁÉÍÏÄÅÊÓÔ×ÕÅÔ Ó ÄÁÅÍÏÎÁÍÉ rpc.statd ÎÁ ÄÒÕÇÉÈ ÈÏÓÔÁÈ ÄÌÑ ÏÂÅÓÐÅÞÅÎÉÑ ÍÏÎÉÔÏÒÉÎÇÁ ÓÔÁÔÕÓÁ. ðÏÌÕÞÅÎÎÙÊ ÓÔÁÔÕÓ ÏÂÙÞÎÏ ÈÒÁÎÉÔÓÑ × ÆÁÊÌÅ /var/db/statd.status. ðÏÓÌÅÄÎÑÑ ÏÐÃÉÑ ÜÔÏ rpc.lockd, ËÏÔÏÒÁÑ, ÂÕÄÕÞÉ ×ÙÂÒÁÎÎÏÊ, ÐÒÅÄÏÓÔÁ×ÌÑÅÔ ÓÅÒ×ÉÓÙ ÂÌÏËÉÒÏ×ËÉ ÆÁÊÌÏ×. ïÎÁ ÏÂÙÞÎÏ ÉÓÐÏÌØÚÕÅÔÓÑ Ó rpc.statd ÄÌÑ ÏÔÓÌÅÖÉ×ÁÎÉÑ ÈÏÓÔÏ×, ÚÁÐÒÁÛÉ×ÁÀÝÉÈ ÂÌÏËÉÒÏ×ËÉ É ÞÁÓÔÏÔÙ ÜÔÉÈ ÚÁÐÒÏÓÏ×. èÏÔÑ Ä×Å ÐÏÓÌÅÄÎÉÅ ÏÐÃÉÉ ÐÒÅËÒÁÓÎÏ ÐÏÄÈÏÄÑÔ ÄÌÑ ÏÔÌÁÄËÉ, ÏÎÉ ÎÅ ÔÒÅÂÕÀÔÓÑ ÓÅÒ×ÅÒÁÍ É ËÌÉÅÎÔÁÍ NFS ÄÌÑ ËÏÒÒÅËÔÎÏÊ ÒÁÂÏÔÙ. îÉÖÅ × ÓÐÉÓËÅ ÏÐÃÉÊ ÎÁÈÏÄÉÔÓÑ Routed, ÄÁÅÍÏÎ ÍÁÒÛÒÕÔÉÚÁÃÉÉ. õÔÉÌÉÔÁ &man.routed.8; ÕÐÒÁ×ÌÑÅÔ ÓÅÔÅ×ÙÍÉ ÔÁÂÌÉÃÁÍÉ ÍÁÒÛÒÕÔÉÚÁÃÉÉ, ÏÂÎÁÒÕÖÉ×ÁÅÔ ÛÉÒÏËÏ×ÅÝÁÔÅÌØÎÙÅ ÍÁÒÛÒÕÔÉÚÁÔÏÒÙ, É ÐÒÅÄÏÓÔÁ×ÌÑÅÔ ËÏÐÉÀ ÔÁÂÌÉà ÍÁÒÛÒÕÔÉÚÁÃÉÉ ÌÀÂÏÍÕ ÆÉÚÉÞÅÓËÉ ÐÏÄËÌÀÞÅÎÎÏÍÕ Ë ÓÅÔÉ ÈÏÓÔÕ ÐÏ ÚÁÐÒÏÓÕ. üÔÏ ÏÂÙÞÎÏ ÉÓÐÏÌØÚÕÅÔÓÑ ËÏÍÐØÀÔÅÒÁÍÉ, Ñ×ÌÑÀÝÉÍÉÓÑ ÛÌÀÚÏÍ ÄÌÑ ÌÏËÁÌØÎÏÊ ÓÅÔÉ. ëÏÇÄÁ ÜÔÁ ÏÐÃÉÑ ×ÙÂÒÁÎÁ, ÐÏÑ×ÉÔÓÑ ÍÅÎÀ ×ÙÂÏÒÁ ÍÅÓÔÏÐÏÌÏÖÅÎÉÑ ÕÔÉÌÉÔÙ ÐÏ ÕÍÏÌÞÁÎÉÀ. úÎÁÞÅÎÉÅ ÐÏ ÕÍÏÌÞÁÎÉÀ ÕÖÅ ×ÙÂÒÁÎÏ, ÞÔÏÂÙ ÐÏÄÔ×ÅÒÄÉÔØ ÅÇÏ ÎÁÖÍÉÔÅ Enter. ðÏÑ×ÉÔÓÑ ÓÌÅÄÕÀÝÅÅ ÍÅÎÀ, ÚÁÐÒÁÛÉ×ÁÀÝÅÅ ÆÌÁÇÉ ÄÌÑ routed. ðÏ ÕÍÏÌÞÁÎÉÀ ÜÔÏ ÆÌÁÇ , ÏÎ ÄÏÌÖÅÎ ÕÖÅ ÂÙÔØ ÎÁ ÜËÒÁÎÅ. îÁ ÓÌÅÄÕÀÝÅÊ ÌÉÎÉÉ ÎÁÈÏÄÉÔÓÑ ÏÐÃÉÑ Rwhod, ×ÙÂÏÒ ËÏÔÏÒÏÊ ÐÒÉ×ÅÄÅÔ Ë ÚÁÐÕÓËÕ ÄÁÅÍÏÎÁ &man.rwhod.8; ÐÒÉ ÓÔÁÒÔÅ ÓÉÓÔÅÍÙ. õÔÉÌÉÔÁ rwhod ÐÅÒÉÏÄÉÞÅÓËÉ ÒÁÓÓÙÌÁÅÔ ÛÉÒÏËÏ×ÅÝÁÔÅÌØÎÙÅ ÓÉÓÔÅÍÎÙÅ ÓÏÏÂÝÅÎÉÑ ÐÏ ÓÅÔÉ ÉÌÉ ÓÏÂÉÒÁÅÔ ÉÈ × ÒÅÖÉÍÅ ÐÏÔÒÅÂÉÔÅÌÑ. äÏÐÏÌÎÉÔÅÌØÎÕÀ ÉÎÆÏÒÍÁÃÉÀ ÍÏÖÎÏ ÎÁÊÔÉ ÎÁ ÓÔÒÁÎÉÃÁÈ ÓÐÒÁ×ÏÞÎÉËÁ &man.ruptime.1; É &man.rwho.1;. óÌÅÄÕÀÝÁÑ ÐÅÒÅÄ ÐÏÓÌÅÄÎÅÊ ÏÐÃÉÅÊ × ÓÐÉÓËÅ ÜÔÏ ÄÁÅÍÏÎ &man.sshd.8;. üÔÏ ÓÅÒ×ÅÒ ÂÅÚÏÐÁÓÎÏÊ ÏÂÏÌÏÞËÉ (secure shell) ÉÚ OpenSSH É ÏÎ ÎÁÓÔÏÑÔÅÌØÎÏ ÒÅËÏÍÅÎÄÕÅÔÓÑ ÄÌÑ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ×ÍÅÓÔÏ ÓÔÁÎÄÁÒÔÎÙÈ ÓÅÒ×ÅÒÏ× telnet É FTP. óÅÒ×ÅÒ sshd ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÓÏÚÄÁÎÉÑ ÂÅÚÏÐÁÓÎÙÈ ÓÏÅÄÉÎÅÎÉÊ ÏÔ ÏÄÎÏÇÏ ÈÏÓÔÁ Ë ÄÒÕÇÏÍÕ Ó ÉÓÐÏÌØÚÏ×ÁÎÉÅÍ ÛÉÆÒÏ×ÁÎÉÑ. é ÎÁËÏÎÅÃ, ÏÐÃÉÑ TCP Extensions. ïÎÁ ×ËÌÀÞÁÅÔ ÒÁÓÛÉÒÅÎÉÑ TCP, ÏÐÒÅÄÅÌÅÎÎÙÅ × RFC 1323 É RFC 1644. èÏÔÑ ÄÌÑ ÍÎÏÇÉÈ ÈÏÓÔÏ× ÏÎÉ ÍÏÇÕÔ ÐÏ×ÙÓÉÔØ ÓËÏÒÏÓÔØ ÓÏÅÄÉÎÅÎÉÑ, Ó ÄÒÕÇÉÍÉ ÓÏÅÄÉÎÅÎÉÅ ÍÏÖÅÔ ÂÙÔØ ÏÂÏÒ×ÁÎÏ. äÌÑ ÓÅÒ×ÅÒÏ× ÜÔÉ ÒÁÓÛÉÒÅÎÉÑ ÎÅ ÒÅËÏÍÅÎÄÕÀÔÓÑ, ÎÏ ËÌÉÅÎÔÓËÉÍ ËÏÍÐØÀÔÅÒÁÍ ÍÏÇÕÔ ÄÁÔØ ÎÅËÏÔÏÒÙÅ ÐÒÅÉÍÕÝÅÓÔ×Á. ôÅÐÅÒØ, ÐÏÓÌÅ ÎÁÓÔÒÏÊËÉ ÓÅÔÅ×ÙÈ ÓÅÒ×ÉÓÏ×, ×Ù ÍÏÖÅÔÅ ÐÒÏËÒÕÔÉÔØ ÍÅÎÀ Ë ×ÅÒÈÎÅÍÕ ÐÕÎËÔÕ, X Exit, É ÐÅÒÅÊÔÉ Ë ÓÌÅÄÕÀÝÅÍÕ ÛÁÇÕ, ÉÌÉ ÖÅ ÐÒÏÓÔÏ ÐÏËÉÎÕÔØ sysinstall, Ä×ÁÖÄÙ ÎÁÖÁ× X Exit, Á ÐÏÓÌÅ — [X Exit Install].
úÁÇÒÕÚÏÞÎÙÊ ÐÒÏÃÅÓÓ &os; (&os; Bootup) úÁÇÒÕÚËÁ &os;/&arch.i386; åÓÌÉ ×ÓÅ ÐÒÏÊÄÅÔ ÎÏÒÍÁÌØÎÏ, ×Ù Õ×ÉÄÉÔÅ ÐÒÏËÒÕÞÉ×ÁÀÝÉÅÓÑ ÚÁ ÜËÒÁÎ ÓÏÏÂÝÅÎÉÑ, ÚÁÔÅÍ ÐÒÉÇÌÁÛÅÎÉÅ ËÏ ×ÈÏÄÕ × ÓÉÓÔÅÍÕ. ÷Ù ÍÏÖÅÔ ÐÒÏÓÍÏÔÒÅÔØ ÓÏÏÂÝÅÎÉÑ, ÎÁÖÁ× Scroll-Lock É ÉÓÐÏÌØÚÕÑ PgUp É PgDn. îÁÖÁÔÉÅ Scroll-Lock ÅÝÅ ÒÁÚ ×ÅÒÎÅÔ ×ÁÓ Ë ÐÒÉÇÌÁÛÅÎÉÀ. ÷ÓÅ ÓÏÏÂÝÅÎÉÅ ÍÏÖÅÔ ÎÅ ÏÔÏÂÒÁÚÉÔØÓÑ (ÏÇÒÁÎÉÞÅÎÉÅ ÂÕÆÅÒÁ), ÎÏ ÍÏÖÅÔ ÂÙÔØ ÐÒÏÓÍÏÔÒÅÎÏ ÐÕÔÅÍ ××ÏÄÁ ËÏÍÁÎÄÙ dmesg × ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÅ. ÷ÏÊÄÉÔÅ, ÉÓÐÏÌØÚÕÑ ÉÍÑ ÐÏÌØÚÏ×ÁÔÅÌÑ/ÐÁÒÏÌØ, ÄÏÂÁ×ÌÅÎÎÙÅ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ (rpratt × ÜÔÏÍ ÐÒÉÍÅÒÅ). éÚÂÅÇÁÊÔÅ ×ÈÏÄÁ ÐÏÄ root, ÅÓÌÉ ÜÔÏ ÎÅ ÔÒÅÂÕÅÔÓÑ. ôÉÐÉÞÎÙÅ ÓÏÏÂÝÅÎÉÑ ÐÒÉ ÚÁÇÒÕÚËÅ (ÉÎÆÏÒÍÁÃÉÑ Ï ×ÅÒÓÉÉ ÕÄÁÌÅÎÁ): Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping = 0 Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX> AMD Features=0x80000800<SYSCALL,3DNow!> real memory = 268435456 (262144K bytes) config> di sn0 config> di lnc0 config> di le0 config> di ie0 config> di fe0 config> di cs0 config> di bt0 config> di aic0 config> di aha0 config> di adv0 config> q avail memory = 256311296 (250304K bytes) Preloaded elf kernel "kernel" at 0xc0491000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc049109c. md0: Malloc disk Using $PIR table, 4 entries at 0xc00fde60 npx0: <math processor> on motherboard npx0: INT 16 interface pcib0: <Host to PCI bridge> on motherboard pci0: <PCI bus> on pcib0 pcib1: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on pci0 pci1: <PCI bus> on pcib1 pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 irq 11 isab0: <VIA 82C586 PCI-ISA bridge> at device 7.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <VIA 82C586 ATA33 controller> port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: <VIA 83C572 USB controller> port 0xe400-0xe41f irq 10 at device 7.2 on pci0 usb0: <VIA 83C572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered chip1: <VIA 82C586B ACPI interface> at device 7.3 on pci0 ed0: <NE2000 PCI Ethernet (RealTek 8029)> port 0xe800-0xe81f irq 9 at device 10.0 on pci0 ed0: address 52:54:05:de:73:1b, type NE2000 (16 bit) isa0: too many dependant configs (8) isa0: unexpected small tag 14 fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: <keyboard controller (i8042)> at port 0x60-0x64 on isa0 atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: <System console> at flags 0x1 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: plip0: <PLIP network interface> on ppbus0 lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port ppi0: <Parallel I/O> on ppbus0 ad0: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata0-master using UDMA33 ad2: 8063MB <IBM-DHEA-38451> [16383/16/63] at ata1-master using UDMA33 acd0: CDROM <DELTA OTC-H101/ST3 F/W by OIPD> at ata0-slave using PIO4 Mounting root from ufs:/dev/ad0s1a swapon: adding /dev/ad0s1b as swap device Automatic boot in progress... /dev/ad0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 48752 free (552 frags, 6025 blocks, 0.9% fragmentation) /dev/ad0s1f: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1f: clean, 128997 free (21 frags, 16122 blocks, 0.0% fragmentation) /dev/ad0s1g: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1g: clean, 3036299 free (43175 frags, 374073 blocks, 1.3% fragmentation) /dev/ad0s1e: filesystem CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 128193 free (17 frags, 16022 blocks, 0.0% fragmentation) Doing initial network setup: hostname. ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::5054::5ff::fede:731b%ed0 prefixlen 64 tentative scopeid 0x1 ether 52:54:05:de:73:1b lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 Additional routing options: IP gateway=YES TCP keepalive=YES routing daemons:. additional daemons: syslogd. Doing additional network setup:. Starting final network daemons: creating ssh RSA host key Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: cd:76:89:16:69:0e:d0:6e:f8:66:d0:07:26:3c:7e:2d root@k6-2.example.com creating ssh DSA host key Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: f9:a1:a9:47:c4:ad:f9:8d:52:b8:b8:ff:8c:ad:2d:e6 root@k6-2.example.com. setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout starting standard daemons: inetd cron sshd usbd sendmail. Initial rc.i386 initialization:. rc.i386 configuring syscons: blank_time screensaver moused. Additional ABI support: linux. Local package initialization:. Additional TCP options:. FreeBSD/i386 (k6-2.example.com) (ttyv0) login: rpratt Password: çÅÎÅÒÉÒÏ×ÁÎÉÅ ËÌÀÞÅÊ RSA É DSA ÍÏÖÅÔ ÚÁÎÑÔØ ÎÅËÏÔÏÒÏÅ ×ÒÅÍÑ ÎÁ ÍÅÄÌÅÎÎÙÈ ËÏÍÐØÀÔÅÒÁÈ. üÔÏ ÍÏÖÅÔ ÓÌÕÞÉÔØÓÑ ÔÏÌØËÏ ÐÒÉ ÐÅÒ×ÏÊ ÚÁÇÒÕÚËÅ Ó×ÅÖÅÕÓÔÁÎÏ×ÌÅÎÎÏÊ ÓÉÓÔÅÍÙ. ðÏÓÌÅÄÕÀÝÉÅ ÚÁÇÒÕÚËÉ ÂÕÄÕÔ ÂÙÓÔÒÅÅ. åÓÌÉ X ÓÅÒ×ÅÒ ÂÙÌ ÎÁÓÔÒÏÅÎ É ÂÙÌ ×ÙÂÒÁÎ ÄÅÓËÔÏÐ ÐÏ ÕÍÏÌÞÁÎÉÀ, ÏÎ ÍÏÖÅÔ ÂÙÔØ ÚÁÐÕÝÅÎ ÉÚ ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÉ ËÏÍÁÎÄÏÊ startx. úÁ×ÅÒÛÅÎÉÅ ÒÁÂÏÔÙ &os; (&os; Shutdown) ÷ÁÖÎÏ ÐÒÁ×ÉÌØÎÏ ÚÁ×ÅÒÛÁÔØ ÒÁÂÏÔÕ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ. îÅÌØÚÑ ÐÒÏÓÔÏ ×ÙËÌÀÞÁÔØ ÐÉÔÁÎÉÅ. óÎÁÞÁÌÁ ÎÕÖÎÏ ÓÔÁÔØ ÓÕÐÅÒÐÏÌØÚÏ×ÁÔÅÌÅÍ, ××ÅÄÑ × ËÏÍÁÎÄÎÏÊ ÓÔÒÏËÅ su É ÐÁÒÏÌØ root. üÔÏ ÓÒÁÂÏÔÁÅÔ ÔÏÌØËÏ ÅÓÌÉ ÐÏÌØÚÏ×ÁÔÅÌØ Ñ×ÌÑÅÔÓÑ ÞÌÅÎÏÍ ÇÒÕÐÐÙ wheel. éÌÉ ÚÁÊÄÉÔÅ ÐÏÄ root É ÉÓÐÏÌØÚÕÊÔÅ ËÏÍÁÎÄÕ shutdown -h now. The operating system has halted. Please press any key to reboot. íÏÖÎÏ ÂÅÚÏÐÁÓÎÏ ×ÙËÌÀÞÁÔØ ÐÉÔÁÎÉÅ ÐÏÓÌÅ ÔÏÇÏ, ËÁË ÂÕÄÅÔ ×ÙÐÏÌÎÅÎÁ ËÏÍÁÎÄÁ shutdown É ÐÏÑ×ÉÔÓÑ ÓÏÏÂÝÅÎÉÅ Please press any key to reboot. åÓÌÉ ×ÍÅÓÔÏ ×ÙËÌÀÞÅÎÉÑ ÐÉÔÁÎÉÑ ÂÕÄÅÔ ÎÁÖÁÔÁ ÌÀÂÁÑ ËÌÁ×ÉÛÁ, ÓÉÓÔÅÍÁ ÐÅÒÅÚÁÇÒÕÚÉÔÓÑ. ÷Ù ÔÁËÖÅ ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ ËÏÍÂÉÎÁÃÉÀ ËÌÁ×ÉÛ Ctrl Alt Del ÄÌÑ ÐÅÒÅÚÁÇÒÕÚËÉ ÓÉÓÔÅÍÙ, ÈÏÔÑ ÜÔÏ ÎÅ ÒÅËÏÍÅÎÄÕÅÔÓÑ × ÏÂÙÞÎÏÊ ÓÉÔÕÁÃÉÉ.
òÅÛÅÎÉÅ ÐÒÏÂÌÅÍ ÕÓÔÁÎÏ×ËÁ ÒÅÛÅÎÉÅ ÐÒÏÂÌÅÍ óÌÅÄÕÀÝÉÊ ÒÁÚÄÅÌ ÏÐÉÓÙ×ÁÅÔ ÏÓÎÏ×ÎÙÅ ÐÒÏÂÌÅÍÙ ÐÒÉ ÕÓÔÁÎÏ×ËÅ, Ï ËÏÔÏÒÙÈ ÏÂÙÞÎÏ ÓÏÏÂÝÁÀÔ ÐÏÌØÚÏ×ÁÔÅÌÉ. úÄÅÓØ ÔÁËÖÅ ÎÅÓËÏÌØËÏ ×ÏÐÒÏÓÏ× É ÏÔ×ÅÔÏ× ÏÔ ÔÅÈ, ËÔÏ ÈÏÞÅÔ ÎÁÓÔÒÏÉÔØ Ä×ÏÊÎÕÀ ÚÁÇÒÕÚËÕ &os; É &ms-dos; ÉÌÉ &windows;. þÔÏ ÄÅÌÁÔØ, ÅÓÌÉ ÞÔÏ-ÔÏ ÉÄÅÔ ÎÅ ÔÁË ðÏ ÐÒÉÞÉÎÅ ÒÁÚÌÉÞÎÙÈ ÏÇÒÁÎÉÞÅÎÉÊ ÁÒÈÉÔÅËÔÕÒÙ PC, ÎÅ×ÏÚÍÏÖÎÏ ÐÒÏÔÅÓÔÉÒÏ×ÁÔØ ÕÓÔÒÏÊÓÔ×Á ÄÏÓÔÏ×ÅÒÎÏ ÎÁ 100%, ÔÅÍ ÎÅ ÍÅÎÅÅ, ÅÓÔØ ÎÅÓËÏÌØËÏ ×ÅÝÅÊ, ËÏÔÏÒÙÅ ×Ù ÍÏÖÅÔÅ ÓÄÅÌÁÔØ, ÅÓÌÉ ÔÅÓÔÉÒÏ×ÁÎÉÅ ÚÁ×ÅÒÛÉÔÓÑ ÎÅÕÄÁÞÎÏ. ó×ÅÒØÔÅÓØ Ó éÎÆÏÒÍÁÃÉÅÊ Ï ÏÂÏÒÕÄÏ×ÁÎÉÉ ÄÌÑ ×ÁÛÅÊ ×ÅÒÓÉÉ &os;, ÞÔÏÂÙ ÕÂÅÄÉÔØÓÑ, ÞÔÏ ×ÁÛÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ. åÓÌÉ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ, ÎÏ ×ÓÅ ÖÅ ÐÒÏÉÓÈÏÄÑÔ ÚÁ×ÉÓÁÎÉÑ ÉÌÉ ×Ù ×ÓÔÒÅÔÉÌÉÓØ Ó ÄÒÕÇÉÍÉ ÐÒÏÂÌÅÍÁÍÉ, ÐÏÔÒÅÂÕÅÔÓÑ ÓÏÂÒÁÔØ ÓÏÂÓÔ×ÅÎÎÏÅ ÑÄÒÏ. üÔÏ ÐÏÚ×ÏÌÉÔ ×ÁÍ ÄÏÂÁ×ÉÔØ ÐÏÄÄÅÒÖËÕ ÁÐÐÁÒÁÔÎÙÈ ÕÓÔÒÏÊÓÔ×, ÏÔÓÕÔÓÔ×ÕÀÝÉÈ × ÑÄÒÅ GENERIC. ñÄÒÏ ÎÁ ÚÁÇÒÕÚÏÞÎÏÍ ÄÉÓËÅ ÎÁÓÔÒÏÅÎÏ × ÐÒÅÄÐÏÌÏÖÅÎÉÉ, ÞÔÏ Õ ÂÏÌØÛÉÎÓÔ×Á ÁÐÐÁÒÁÔÎÙÈ ÕÓÔÒÏÊÓÔ× IRQ, ÁÄÒÅÓÁ ××ÏÄÁ-×Ù×ÏÄÁ É ËÁÎÁÌÙ DMA ÕÓÔÁÎÏ×ÌÅÎÙ ÐÒÏÉÚ×ÏÄÉÔÅÌÅÍ Ë ÚÎÁÞÅÎÉÑÍ ÐÏ ÕÍÏÌÞÁÎÉÀ. åÓÌÉ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÂÙÌÏ ÐÅÒÅÎÁÓÔÒÏÅÎÏ, ×ÁÍ ÓËÏÒÅÅ ×ÓÅÇÏ ÐÏÔÒÅÂÕÅÔÓÑ ÏÔÒÅÄÁËÔÉÒÏ×ÁÔØ ËÏÎÆÉÇÕÒÁÃÉÀ ÑÄÒÁ É ÐÅÒÅËÏÍÐÉÌÉÒÏ×ÁÔØ ÅÇÏ, ÞÔÏÂÙ ÓÏÏÂÝÉÔØ FreeBSD, ÇÄÅ ÞÔÏ ÉÓËÁÔØ. ÷ÏÚÍÏÖÎÏ ÔÁËÖÅ, ÞÔÏ ÔÅÓÔÉÒÏ×ÁÎÉÅ ÕÓÔÒÏÊÓÔ×Á, ËÏÔÏÒÏÇÏ ÎÅÔ, ÐÒÉ×ÅÄÅÔ ÐÏÚÖÅ Ë ÏÛÉÂËÅ ÔÅÓÔÉÒÏ×ÁÎÉÑ ÓÕÝÅÓÔ×ÕÀÝÅÇÏ ÕÓÔÒÏÊÓÔ×Á. ÷ ÜÔÏÍ ÓÌÕÞÁÅ ÔÅÓÔÉÒÏ×ÁÎÉÅ ËÏÎÆÌÉËÔÕÀÝÅÇÏ ÄÒÁÊ×ÅÒÁ (ÄÒÁÊ×ÅÒÏ×) ÄÏÌÖÎÏ ÂÙÔØ ÚÁÐÒÅÝÅÎÏ. îÅËÏÔÏÒÙÅ ÐÒÏÂÌÅÍÙ ÕÓÔÁÎÏ×ËÉ ÍÏÖÎÏ ÏÂÏÊÔÉ ÉÌÉ ÕÍÅÎØÛÉÔØ, ÏÂÎÏ×É× ×ÓÔÒÏÅÎÎÏÅ ÐÒÏÇÒÁÍÍÎÏÅ ÏÂÅÓÐÅÞÅÎÉÅ ÒÁÚÌÉÞÎÙÈ ËÏÍÐÏÎÅÎÔ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ÏÓÏÂÅÎÎÏ ÍÁÔÅÒÉÎÓËÏÊ ÐÌÁÔÙ. ÷ÓÔÒÏÅÎÎÏÅ ÐÒÏÇÒÁÍÍÎÏÅ ÏÂÅÓÐÅÞÅÎÉÅ ÔÁËÖÅ ÎÁÚÙ×ÁÀÔ BIOS É Õ ÂÏÌØÛÉÎÓÔ×Á ÐÒÏÉÚ×ÏÄÉÔÅÌÅÊ ËÏÍÐØÀÔÅÒÏ× ÉÌÉ ÍÁÔÅÒÉÎÓËÉÈ ÐÌÁÔ ÅÓÔØ Web-ÓÁÊÔÙ, ÇÄÅ ÍÏÖÎÏ ÎÁÊÔÉ ÏÂÎÏ×ÌÅÎÉÑ É ÉÎÆÏÒÍÁÃÉÀ Ï ÏÂÎÏ×ÌÅÎÉÑÈ. âÏÌØÛÉÎÓÔ×Ï ÐÒÏÉÚ×ÏÄÉÔÅÌÅÊ ÎÁÓÔÏÑÔÅÌØÎÏ ÓÏ×ÅÔÕÀÔ ÎÅ ÏÂÎÏ×ÌÑÔØ BIOS ÐÏËÁ ÎÅ ×ÏÚÎÉËÎÅÔ ÓÅÒØÅÚÎÏÊ ÎÅÏÂÈÏÄÉÍÏÓÔÉ, ÎÁÐÒÉÍÅÒ ÐÏÑ×ÌÅÎÉÅ ËÒÉÔÉÞÅÓËÉ ×ÁÖÎÙÈ ÏÂÎÏ×ÌÅÎÉÊ. ðÒÏÃÅÓÓ ÏÂÎÏ×ÌÅÎÉÑ ÍÏÖÅÔ ÐÏÊÔÉ ÎÅ×ÅÒÎÏ, ÞÔÏ ÐÒÉ×ÅÄÅÔ Ë ÎÅÕÓÔÒÁÎÉÍÏÍÕ ÐÏ×ÒÅÖÄÅÎÉÀ ÍÉËÒÏÓÈÅÍÙ BIOS. éÓÐÏÌØÚÏ×ÁÎÉÅ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ &ms-dos; É &windows; ÷ ÎÁÓÔÏÑÝÅÅ ×ÒÅÍÑ, &os; ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔ ÆÁÊÌÏ×ÙÅ ÓÉÓÔÅÍÙ, ÓÖÁÔÙÅ Ó ÐÏÍÏÝØÀ ÐÒÏÇÒÁÍÍÙ Double Space™. ðÏÜÔÏÍÕ ÆÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ ÄÏÌÖÎÁ ÂÙÔØ ÒÁÚÖÁÔÁ, ÞÔÏÂÙ &os; ÓÍÏÇÌÁ ÐÏÌÕÞÉÔØ ÄÏÓÔÕÐ Ë ÄÁÎÎÙÍ. üÔÏ ÍÏÖÅÔ ÂÙÔØ ÓÄÅÌÁÎÏ Ó ÐÏÍÏÝØÀ ÐÒÉÌÏÖÅÎÉÑ Compression Agent, ÎÁÈÏÄÑÝÅÇÏÓÑ × ÍÅÎÀ ðÕÓË> ðÒÏÇÒÁÍÍÙ > óÉÓÔÅÍÎÙÅ. &os; ÐÏÄÄÅÒÖÉ×ÁÅÔ ÆÁÊÌÏ×ÙÅ ÓÉÓÔÅÍÙ &ms-dos; (ÉÎÏÇÄÁ ÎÁÚÙ×ÁÅÍÙÅ ÆÁÊÌÏ×ÙÍÉ ÓÉÓÔÅÍÁÍÉ FAT). ëÏÍÁÎÄÁ &man.mount.msdosfs.8; ×ËÌÀÞÁÅÔ ÔÁËÉÅ ÆÁÊÌÏ×ÙÅ ÓÉÓÔÅÍÙ × ÓÕÝÅÓÔ×ÕÀÝÕÀ ÉÅÒÁÒÈÉÀ, ÔÅÍ ÓÁÍÙÍ ÏÂÅÓÐÅÞÉ×ÁÑ ÄÏÓÔÕÐ Ë ÉÈ ÓÏÄÅÒÖÉÍÏÍÕ. ëÁË ÐÒÁ×ÉÌÏ, ÕÔÉÌÉÔÁ &man.mount.msdosfs.8; ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏ ÎÅ ×ÙÚÙ×ÁÅÔÓÑ; ×ÍÅÓÔÏ ÜÔÏÇÏ ÏÎÁ ×ÙÐÏÌÎÑÅÔÓÑ ÓÉÓÔÅÍÏÊ ÐÒÉ ÎÁÌÉÞÉÉ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÊ ÚÁÐÉÓÉ × /etc/fstab ÉÌÉ ÖÅ ×ÙÚÙ×ÁÅÔÓÑ ÕÔÉÌÉÔÏÊ &man.mount.8;, ÚÁÐÕÝÅÎÎÏÊ Ó ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÉÍÉ ÐÁÒÁÍÅÔÒÁÍÉ. îÉÖÅ ÐÒÉ×ÅÄÅÎ ÐÒÉÍÅÒ ÚÁÐÉÓÉ × /etc/fstab ÄÌÑ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ &ms-dos;: /dev/ad0sN /dos msdosfs rw 0 0 ëÁÔÁÌÏÇ /dos ÄÏÌÖÅÎ ÂÙÔØ ÓÏÚÄÁÎ ÚÁÒÁÎÅÅ. æÏÒÍÁÔ ÆÁÊÌÁ /etc/fstab ÐÏÄÒÏÂÎÏ ÏÐÉÓÁÎ × &man.fstab.5;. ôÁËÖÅ ÐÒÉ×ÅÄÅÍ ÐÒÉÍÅÒ ÍÏÎÔÉÒÏ×ÁÎÉÑ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÙ &ms-dos; ÐÏÓÒÅÄÓÔ×ÏÍ &man.mount.8;: &prompt.root; mount -t msdosfs /dev/ad0s1 /mnt ÷ ÜÔÏÍ ÐÒÉÍÅÒÅ ÆÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ &ms-dos; ÒÁÓÐÏÌÏÖÅÎÁ ÎÁ ÐÅÒ×ÏÍ ÒÁÚÄÅÌÅ ÐÅÒ×ÏÇÏ ÖÅÓÔËÏÇÏ ÄÉÓËÁ. ÷ÁÛÁ ËÏÎÆÉÇÕÒÁÃÉÑ ÍÏÖÅÔ ÂÙÔØ ÄÒÕÇÏÊ, ÐÒÏ×ÅÒØÔÅ ×Ù×ÏÄ ËÏÍÁÎÄ dmesg É mount. ïÎÉ ÄÏÌÖÎÙ ÐÒÅÄÏÓÔÁ×ÉÔØ ÄÏÓÔÁÔÏÞÎÏ ÉÎÆÏÒÍÁÃÉÉ ÄÌÑ ÏÐÒÅÄÅÌÅÎÉÑ ÎÁÚ×ÁÎÉÊ ÒÁÚÄÅÌÏ×. óÐÏÓÏ ÎÕÍÅÒÁÃÉÉ ÄÉÓËÏ×ÙÈ ÓÌÁÊÓÏ× (ÔÏ ÅÓÔØ, ÒÁÚÄÅÌÏ× × ÔÅÒÍÉÎÁÈ &ms-dos;) ÍÏÖÅÔ ÏÔÌÉÞÁÔØÓÑ ÏÔ ÓÐÏÓÏÂÁ, ÐÒÉÎÑÔÏÇÏ × ÄÒÕÇÉÈ ÏÐÅÒÁÃÉÏÎÎÙÈ ÓÉÓÔÅÍÁÈ. ÷ ÞÁÓÔÎÏÓÔÉ, ÒÁÓÛÉÒÅÎÎÙÍ ÒÁÚÄÅÌÁÍ &ms-dos; ÐÒÉÓ×ÁÉ×ÁÀÔÓÑ ÎÏÍÅÒÁ, ÓÌÅÄÕÀÝÉÅ ÚÁ ÐÅÒ×ÉÞÎÙÍÉ ÒÁÚÄÅÌÁÍÉ &ms-dos;. õÔÉÌÉÔÁ &man.fdisk.8; ÐÏÍÏÖÅÔ ÏÐÒÅÄÅÌÉÔØ, ËÁËÉÅ ÓÌÁÊÓÙ ÐÒÉÎÁÄÌÅÖÁÔ &os;, Á ËÁËÉÅ — ÄÒÕÇÉÍ ÏÐÅÒÁÃÉÏÎÎÙÍ ÓÉÓÔÅÍÁÍ. òÁÚÄÅÌÙ NTFS ÔÁËÖÅ ÍÏÖÎÏ ÓÍÏÎÔÉÒÏ×ÁÔØ ÐÏÈÏÖÉÍ ÓÐÏÓÏÂÏÍ, ÉÓÐÏÌØÚÕÑ ËÏÍÁÎÄÕ &man.mount.ntfs.8;. òÅÛÅÎÉÅ ÐÒÏÂÌÅÍ: ×ÏÐÒÏÓÙ É ÏÔ×ÅÔÙ íÏÑ ÓÉÓÔÅÍÁ ÚÁ×ÉÓÁÅÔ ÎÁ ÜÔÁÐÅ ÏÐÒÅÄÅÌÅÎÉÑ ÏÂÏÒÕÄÏ×ÁÎÉÑ ×Ï ×ÒÅÍÑ ÚÁÇÒÕÚËÉ, ÉÌÉ ÓÉÓÔÅÍÁ ×ÅÄÅÔ ÓÅÂÑ ÓÔÒÁÎÎÏ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ, ÉÌÉ ÖÅ ÎÅ ÏÐÒÅÄÅÌÑÅÔÓÑ ÐÒÉ×ÏÄ ÇÉÂËÏÇÏ ÄÉÓËÁ. îÁ ÁÒÈÉÔÅËÔÕÒÁÈ i386, amd64 É ia64 ÐÒÉ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÉ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ÏÂÎÁÒÕÖÅÎÎÏÇÏ ×Ï ×ÒÅÍÑ ÚÁÇÒÕÚËÉ, &os; ÐÏ×ÓÅÍÅÓÔÎÏ ÉÓÐÏÌØÚÕÅÔ ÓÉÓÔÅÍÕ ACPI. ë ÓÏÖÁÌÅÎÉÀ, ÄÏ ÓÉÈ ÐÏÒ ÎÁÈÏÄÑÔÓÑ ÎÅÐÏÌÁÄËÉ ËÁË × ÄÒÁÊ×ÅÒÅ ACPI, ÔÁË É × ÍÁÔÅÒÉÎÓËÉÈ ÐÌÁÔÁÈ, ÔÁË É × ÉÈ BIOS. éÓÐÏÌØÚÏ×ÁÎÉÅ ACPI ÍÏÖÎÏ ÏÔËÌÀÞÉÔØ ÕÓÔÁÎÏ×É× ÐÅÒÅÍÅÎÎÕÀ hint.acpi.0.disabled ÎÁ ÔÒÅÔØÅÍ ÜÔÁÐÅ ÚÁÇÒÕÚËÉ: set hint.acpi.0.disabled="1" üÔÁ ÎÁÓÔÒÏÊËÁ ÓÂÒÁÓÙ×ÁÅÔÓÑ ËÁÖÄÙÊ ÒÁÚ ÐÒÉ ÐÅÒÅÚÁÇÒÕÚËÅ ÓÉÓÔÅÍÙ, ÐÏÜÔÏÍÕ ÎÅÏÂÈÏÄÉÍÏ ÄÏÂÁ×ÉÔØ ÓÔÒÏËÕ hint.acpi.0.disabled="1" × ÆÁÊÌ /boot/loader.conf. éÎÆÏÒÍÁÃÉÑ Ï ÚÁÇÒÕÚÞÉËÅ ÐÒÉ×ÅÄÅÎÁ × . ÷ÙÐÏÌÎÑÅÔÓÑ ÐÅÒ×ÁÑ ÚÁÇÒÕÚËÁ ÐÏÓÌÅ ÕÓÔÁÎÏ×ËÉ &os;, ÑÄÒÏ ÚÁÇÒÕÖÁÅÔÓÑ É ÏÐÒÅÄÅÌÑÅÔ ÁÐÐÁÒÁÔÎÏÅ ÏÂÅÓÐÅÞÅÎÉÅ, ÎÏ ÚÁÇÒÕÚËÁ ÏÓÔÁÎÁ×ÌÉ×ÁÅÔÓÑ Ó ÓÏÏÂÝÅÎÉÅÍ ÔÉÐÁ: changing root device to ad1s1a panic: cannot mount root þÔÏ ÜÔÏ ÚÎÁÞÉÔ? þÔÏ ÍÏÖÎÏ ÓÄÅÌÁÔØ? é ÞÔÏ ÜÔÏ ÚÁ ÓÔÒÏËÁ ×ÉÄÁ bios_drive:interface(unit,partition)kernel_name, ÏÔÏÂÒÁÖÁÅÍÁÑ × ÐÒÉÇÌÁÛÅÎÉÉ ÚÁÇÒÕÚÞÉËÁ? üÔÏ ÄÒÅ×ÎÑÑ ÐÒÏÂÌÅÍÁ, ÐÒÏÑ×ÌÑÀÝÁÑÓÑ × ÓÌÕÞÁÑÈ, ËÏÇÄÁ ÚÁÇÒÕÚÏÞÎÙÊ ÄÉÓË ÎÅ Ñ×ÌÑÅÔÓÑ ÐÅÒ×ÙÍ ÄÉÓËÏÍ × ÓÉÓÔÅÍÅ. BIOS ÉÓÐÏÌØÚÕÅÔ Ó×ÏÀ ÓÈÅÍÕ ÎÕÍÅÒÁÃÉÉ ÄÉÓËÏ× ÐÏ ÓÒÁ×ÎÅÎÉÀ Ó &os;, É ÓÌÏÖÎÏ ÐÒÁ×ÉÌØÎÏ ÒÅÛÉÔØ, ËÁË ÓÏÏÔ×ÅÔÓÔ×ÕÀÔ ÜÔÉ ÎÕÍÅÒÁÃÉÉ. ÷ ÓÌÕÞÁÅ, ÅÓÌÉ ÚÁÇÒÕÚÏÞÎÙÊ ÄÉÓË ÎÅ Ñ×ÌÑÅÔÓÑ ÐÅÒ×ÙÍ ÄÉÓËÏÍ × ÓÉÓÔÅÍÅ, ÔÏ &os; ÐÏÔÒÅÂÕÅÔÓÑ ÎÅËÏÔÏÒÁÑ ÐÏÍÏÝØ. åÓÔØ Ä×Á ×ÏÚÍÏÖÎÙÈ ÓÌÕÞÁÑ, É × ÏÂÏÉÈ ×ÁÍ ÐÒÉÄÅÔÓÑ ÓÏÏÂÝÉÔØ &os; ÇÄÅ ÎÁÈÏÄÉÔÓÑ ËÏÒÎÅ×ÁÑ ÆÁÊÌÏ×ÁÑ ÓÉÓÔÅÍÁ. üÔÏ ÄÅÌÁÅÔÓÑ ÕËÁÚÁÎÉÅÍ ×ÒÕÞÎÕÀ ÓÌÅÄÕÀÝÉÈ ÄÁÎÎÙÈ: ÎÏÍÅÒÁ ÄÉÓËÁ (ÓÏÇÌÁÓÎÏ ÎÕÍÅÒÁÃÉÉ BIOS), ÔÉÐÁ ÄÉÓËÁ É ÎÏÍÅÒÁ ÄÉÓËÁ (ÓÏÇÌÁÓÎÏ ÏÐÒÅÄÅÌÅÎÉÑÍ &os;). ðÅÒ×ÙÊ ÓÌÕÞÁÊ: Õ ×ÁÓ ÉÍÅÅÔÓÑ Ä×Á IDE ÄÉÓËÁ, ËÁÖÄÙÊ ÉÚ ÎÉÈ ÓËÏÎÆÉÇÕÒÉÒÏ×ÁÎ ËÁË ÍÁÓÔÅÒ ÎÁ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÊ ÛÉÎÅ IDE, É ×Ù ÎÁÍÅÒÅ×ÁÅÔÅÓØ ÚÁÇÒÕÚÉÔØ &os; Ó ×ÔÏÒÏÇÏ ÄÉÓËÁ. BIOS ÏÐÒÅÄÅÌÑÅÔ ÜÔÉ ÄÉÓËÉ ËÁË disk 0 É disk 1, × ÔÏ ×ÒÅÍÑ ËÁË &os; ÏÐÒÅÄÅÌÑÅÔ ÉÈ ËÁË ad0 É ad2. &os; ÎÁÈÏÄÉÔÓÑ ÎÁ disk 1 (BIOS-ÎÕÍÅÒÁÃÉÑ), ÅÇÏ ÔÉÐ — ad É ÎÏÍÅÒ — 2 (ÐÏ ÄÁÎÎÙÍ &os;), ÓÌÅÄÏ×ÁÔÅÌØÎÏ, ÎÅÏÂÈÏÄÉÍÏ ÕËÁÚÁÔØ: 1:ad(2,a)kernel úÁÍÅÔØÔÅ, ÅÓÌÉ ×ÔÏÒÏÊ ÄÉÓË ÎÁÓÔÒÏÅÎ ËÁË ÐÏÄÞÉÎÅÎÎÙÊ (slave) ÎÁ ÐÅÒ×ÏÊ ÛÉÎÅ IDE, ÔÏ ÕËÁÚÁÎÉÅ ×ÙÛÅÐÒÉ×ÅÄ£ÎÎÏÇÏ ÎÅÏÂÑÚÁÔÅÌØÎÏ (Á ÐÏ ÓÕÝÅÓÔ×Õ, ÅÝÅ É ÎÅ×ÅÒÎÏ). ÷ÔÏÒÏÊ ÓÌÕÞÁÊ ÐÏÄÒÁÚÕÍÅ×ÁÅÔ ÚÁÇÒÕÚËÕ Ó ÄÉÓËÁ SCSI ÐÒÉ ÓÕÝÅÓÔ×ÕÀÝÉÈ × ÓÉÓÔÅÍÅ ÄÉÓËÁÈ IDE. ÷ ÜÔÏÍ ÓÌÕÞÁÅ, ÓÏÇÌÁÓÎÏ ÏÐÒÅÄÅÌÅÎÉÑÍ &os; ÎÏÍÅÒ ÄÉÓËÁ ÍÅÎØÛÅ, ÞÅÍ ÎÏÍÅÒ ÐÏ ÐÒÅÄÓÔÁ×ÌÅÎÉÑÍ BIOS. åÓÌÉ Õ ×ÁÓ ÅÓÔØ Ä×Á ÄÉÓËÁ IDE É ÄÉÓË SCSI, ÔÏ, ÓÏÇÌÁÓÎÏ BIOS, ÎÏÍÅÒ SCSI ÄÉÓËÁ — 2, Á ÓÏÇÌÁÓÎÏ &os;, ÔÉÐ — da É ÎÏÍÅÒ — 0, ÓÌÅÄÏ×ÁÔÅÌØÎÏ, ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ ÕËÁÚÁÔØ ÓÌÅÄÕÀÝÅÅ: 2:da(0,a)kernel ÞÔÏÂÙ ÓÏÏÂÝÉÔØ &os;, ÞÔÏ ×Ù ÎÁÍÅÒÅ×ÁÅÔÅÓØ ÚÁÇÒÕÚÉÔØ ÓÉÓÔÅÍÕ Ó ÄÉÓËÁ 2 ÐÏ ÎÕÍÅÒÁÃÉÉ BIOS, ËÏÔÏÒÙÊ Ñ×ÌÑÅÔÓÑ ÐÅÒ×ÙÍ ÄÉÓËÏÍ × ÓÉÓÔÅÍÅ. åÓÌÉ ÂÙ Õ ×ÁÓ ÂÙÌ ÏÄÉÎ ÄÉÓË IDE, ×ÁÍ ÂÙ ÐÒÉÛÌÏÓØ ÉÓÐÏÌØÚÏ×ÁÔØ 1: (ÐÏ ÎÕÍÅÒÁÃÉÉ BIOS). ïÐÒÅÄÅÌÉ× ×ÅÒÎÙÅ ÐÁÒÁÍÅÔÒÙ, ×ÎÅÓÉÔÅ ÉÈ × ÔÏÍ ×ÉÄÅ, ËÁË ×Ù ÉÈ ÎÁÂÉÒÁÌÉ, × ÆÁÊÌ /boot.config. åÓÌÉ ÎÅ ÕËÁÚÙ×ÁÅÔÓÑ ÉÎÁÞÅ, ÔÏ &os; ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÔØ ÓÏÄÅÒÖÉÍÏÅ ÜÔÏÇÏ ÆÁÊÌÁ ËÁË ÚÎÁÞÅÎÉÅ ÐÏ ÕÍÏÌÞÁÎÉÀ × ÐÒÉÇÌÁÛÅÎÉÉ boot:. ñ ÐÅÒÅÈÏÖÕ Ë ÚÁÇÒÕÚËÅ Ó ÖÅÓÔËÏÇÏ ÄÉÓËÁ ×ÐÅÒ×ÙÅ ÐÏÓÌÅ ÕÓÔÁÎÏ×ËÉ &os;, ÎÏ ÐÒÉÇÌÁÛÅÎÉÅ Boot Manager ×ÓÑËÉÊ ÒÁÚ ×Ù×ÏÄÉÔ ÔÏÌØËÏ F? × ÍÅÎÀ ÚÁÇÒÕÚÞÉËÁ, É ÎÁ ÜÔÏÍ ÚÁÇÒÕÚËÁ ÐÒÅÒÙ×ÁÅÔÓÑ. ðÒÉ ÕÓÔÁÎÏ×ËÅ &os; × ÒÅÄÁËÔÏÒÅ ÒÁÚÄÅÌÏ× ÂÙÌÁ ÕËÁÚÁÎÁ ÎÅ×ÅÒÎÁÑ ÇÅÏÍÅÔÒÉÑ ÖÅÓÔËÏÇÏ ÄÉÓËÁ. ÷ÅÒÎÉÔÅÓØ × ÒÅÄÁËÔÏÒ ÒÁÚÄÅÌÏ× É ÕËÁÖÉÔÅ ÄÅÊÓÔ×ÉÔÅÌØÎÕÀ ÇÅÏÍÅÔÒÉÀ ×ÁÛÅÇÏ ÖÅÓÔËÏÇÏ ÄÉÓËÁ. ÷ÁÍ ÐÒÉÄÅÔÓÑ ÐÅÒÅÕÓÔÁÎÏ×ÉÔØ ÚÁÎÏ×Ï &os;. åÓÌÉ ×Ù ÚÁÔÒÕÄÎÑÅÔÅÓØ ÏÐÒÅÄÅÌÉÔØ ×ÅÒÎÕÀ ÇÅÏÍÅÔÒÉÀ ÄÌÑ ×ÁÛÅÊ ÍÁÛÉÎÙ, ÔÏ ÓÄÅÌÁÊÔÅ ÓÌÅÄÕÀÝÅÅ: ÕÓÔÁÎÏ×ÉÔÅ ÎÅÂÏÌØÛÏÊ ÒÁÚÄÅÌ &ms-dos; ×ÎÁÞÁÌÅ ÄÉÓËÁ, Á &os; ÒÁÚÍÅÓÔÉÔÅ ÐÏÓÌÅ ÎÅÇÏ. õÓÔÁÎÏ×ÏÞÎÁÑ ÐÒÏÇÒÁÍÍÁ ÏÂÎÁÒÕÖÉÔ ÒÁÚÄÅÌ &ms-dos; É ÐÏÐÒÏÂÕÅÔ ÏÐÒÅÄÅÌÉÔØ ÚÎÁÞÅÎÉÅ ÇÅÏÍÅÔÒÉÉ ÐÏ ÜÔÏÍÕ ÒÁÚÄÅÌÕ, ÞÔÏ, ËÁË ÐÒÁ×ÉÌÏ, ÚÁ×ÅÒÛÁÅÔÓÑ ÕÓÐÅÈÏÍ. óÌÅÄÕÀÝÉÊ ÓÐÏÓÏ ÎÅ ÒÅËÏÍÅÎÄÕÅÔÓÑ, ÏÎ ÏÓÔÁ×ÌÅÎ ÚÄÅÓØ ÄÌÑ ÓÐÒÁ×ËÉ:
åÓÌÉ ×Ù ÕÓÔÁÎÁ×ÌÉ×ÁÅÔÅ ×ÙÄÅÌÅÎÎÙÊ ÓÅÒ×ÅÒ &os; ÉÌÉ ÒÁÂÏÞÕÀ ÓÔÁÎÃÉÀ, × ËÏÔÏÒÙÈ ×ÏÐÒÏÓÙ ÓÏ×ÍÅÓÔÎÏÇÏ ÓÕÝÅÓÔ×Ï×ÁÎÉÑ &ms-dos;, Linux ÉÌÉ ÉÎÏÊ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ × ÂÕÄÕÝÅÍ ÎÅ ×ÏÚÎÉËÎÕÔ, ÔÏ Õ ×ÁÓ ÅÓÔØ ×ÏÚÍÏÖÎÏÓÔØ ÉÓÐÏÌØÚÏ×ÁÔØ ×ÅÓØ ÄÉÓË (ÏÐÃÉÑ A × ÒÅÄÁËÔÏÒÅ ÒÁÚÄÅÌÏ×), ÐÏÓÌÅ ×ÙÂÏÒÁ ËÏÔÏÒÏÊ &os; ÚÁÊÍÅÔ ×ÅÓØ ÄÉÓË ÏÔ ÓÁÍÏÇÏ ÐÅÒ×ÏÇÏ ÄÏ ÓÁÍÏÇÏ ÐÏÓÌÅÄÎÅÇÏ ÓÅËÔÏÒÁ. ðÒÉ ÜÔÏÍ, ×ÓÅ ×ÏÐÒÏÓÙ ÇÅÏÍÅÔÒÉÉ ÄÉÓËÁ ÓÔÁÎÕÔ ÎÅÁËÔÕÁÌØÎÙÍÉ.
óÉÓÔÅÍÁ ÏÐÒÅÄÅÌÑÅÔ ÍÏÀ ÓÅÔÅ×ÕÀ ËÁÒÔÕ &man.ed.4;, ÎÏ Ñ ÐÏÓÔÏÑÎÎÏ ÐÏÌÕÞÁÀ ÓÏÏÂÝÅÎÉÑ device timeout. ÷ÏÚÍÏÖÎÏ ×ÁÛÁ ÓÅÔÅ×ÁÑ ËÁÒÔÁ ÎÁÈÏÄÉÔÓÑ ÎÅ ÎÁ ÔÏÍ IRQ, ËÏÔÏÒÏÅ ÕËÁÚÁÎÏ × ÆÁÊÌÅ /boot/device.hints. äÒÁÊ×ÅÒ &man.ed.4; ÐÏ ÕÍÏÌÞÁÎÉÀ ÎÅ ÉÓÐÏÌØÚÕÅÔ ÐÒÏÇÒÁÍÍÎÕÀ ËÏÎÆÉÇÕÒÁÃÉÀ (ÚÎÁÞÅÎÉÑ, ××ÏÄÉÍÙÅ ÕÔÉÌÉÔÏÊ EZSETUP × &ms-dos;), ÎÏ ÓÉÔÕÁÃÉÑ ÉÚÍÅÎÉÔÓÑ, ÅÓÌÉ ×Ù ÕËÁÖÅÔÅ -1 × ÚÎÁÞÅÎÉÉ ÈÉÎÔ-ÐÅÒÅÍÅÎÎÏÊ ÄÌÑ ÜÔÏÇÏ ÉÎÔÅÒÆÅÊÓÁ. ìÉÂÏ ÏÓÕÝÅÓÔ×ÉÔÅ ÒÕÞÎÏÅ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÅ ÕÓÔÒÏÊÓÔ×Á ÐÅÒÅËÌÀÞÅÎÉÅÍ ÄÖÁÍÐÅÒÏ× ÎÁ ËÁÒÔÅ (ÔÁËÖÅ ÍÏÖÅÔ ÐÏÔÒÅÂÏ×ÁÔØÓÑ ÉÚÍÅÎÅÎÉÅ ËÏÎÆÉÇÕÒÁÃÉÉ ÑÄÒÁ), ÌÉÂÏ ÖÅ ÓÍÅÎÉÔÅ ÚÎÁÞÅÎÉÅ IRQ ÎÁ -1, ÕÓÔÁÎÏ×É× ÐÅÒÅÍÅÎÎÕÀ hint.ed.0.irq="-1". üÔÏ ÕËÁÖÅÔ ÑÄÒÕ ÉÓÐÏÌØÚÏ×ÁÔØ ÐÒÏÇÒÁÍÍÎÏÅ ËÏÎÆÉÇÕÒÉÒÏ×ÁÎÉÅ. ôÁËÖÅ ×ÅÒÏÑÔÎÏ, ÞÔÏ ×ÁÛÁ ËÁÒÔÁ ÎÁÈÏÄÉÔÓÑ ÎÁ IRQ ÎÏÍÅÒ 9, ËÏÔÏÒÏÅ ÉÓÐÏÌØÚÕÅÔÓÑ ÓÏ×ÍÅÓÔÎÏ Ó IRQ ÎÏÍÅÒ 2, É ËÏÔÏÒÏÅ ÞÁÓÔÏ Ñ×ÌÑÅÔÓÑ ÐÒÉÞÉÎÏÊ ÐÒÏÂÌÅÍ (ÏÓÏÂÅÎÎÏ, ÅÓÌÉ ×ÁÛ VGA ÁÄÁÐÔÅÒ ÚÁÎÉÍÁÅÔ IRQ ÎÏÍÅÒ 2!). ðÏÓÔÁÒÁÊÔÅÓØ ÉÚÂÅÖÁÔØ ÉÓÐÏÌØÚÏ×ÁÎÉÑ IRQ ÎÏÍÅÒ 2 ÉÌÉ 9 ×ÏÏÂÝÅ. ëÏÇÄÁ sysinstall ÚÁÐÕÝÅÎ × ÔÅÒÍÉÎÁÌÅ X11, ÔÏ ÖÅÌÔÙÊ ÛÒÉÆÔ ÎÁ Ó×ÅÔÌÏ ÓÅÒÏÍ ÆÏÎÅ ÐÒÁËÔÉÞÅÓËÉ ÎÅ ÒÁÚÌÉÞÉÍ. åÓÔØ ÌÉ ÓÐÏÓÏ ÏÂÅÓÐÅÞÉÔØ ÌÕÞÛÉÊ ËÏÎÔÒÁÓÔ colorcontrast ÄÌÑ ÜÔÏÇÏ ÐÒÉÌÏÖÅÎÉÑ? åÓÌÉ ×Ù ÕÖÅ ÕÓÔÁÎÏ×ÉÌÉ X11, Á Ã×ÅÔÁ, ×ÙÂÉÒÁÅÍÙÅ ÐÏ ÕÍÏÌÞÁÎÉÀ ÕÔÉÌÉÔÏÊ sysinstall, ÄÅÌÁÀÔ ÔÅËÓÔ ÎÅÒÁÚÂÏÒÞÉ×ÙÍ × &man.xterm.1; ÉÌÉ &man.rxvt.1;, ÔÏ ÄÏÂÁרÔÅ ÓÌÅÄÕÀÝÕÀ ÓÔÒÏËÕ XTerm*color7: #c0c0c0 × ×ÁÛ ~/.Xdefaults É ×Ù ÐÏÌÕÞÉÔÅ ÂÏÌÅÅ Ô£ÍÎÙÊ ÆÏÎÏ×ÙÊ ÓÅÒÙÊ Ã×ÅÔ.
Valentino Vaschetto ðÒÅÄÏÓÔÁ×ÌÅÎÏ Marc Fonvieille ïÂÎÏ×ÉÌ òÁÓÛÉÒÅÎÎÏÅ ÒÕËÏ×ÏÄÓÔ×Ï ÐÏ ÕÓÔÁÎÏ×ËÅ üÔÏÔ ÒÁÚÄÅÌ ÏÐÉÓÙ×ÁÅÔ ÏÓÏÂÙÅ ÓÌÕÞÁÉ ÕÓÔÁÎÏ×ËÉ &os;. õÓÔÁÎÏ×ËÁ &os; ÎÁ ÓÉÓÔÅÍÕ ÂÅÚ ÍÏÎÉÔÏÒÁ ÉÌÉ ËÌÁ×ÉÁÔÕÒÙ ÕÓÔÁÎÏ×ËÁ ÂÅÚ ÍÏÎÉÔÏÒÁ (ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÁÑ ËÏÎÓÏÌØ) ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÁÑ ËÏÎÓÏÌØ üÔÏÔ ÔÉÐ ÕÓÔÁÎÏ×ËÉ ÎÁÚÙ×ÁÅÔÓÑ ÕÓÔÁÎÏ×ËÁ ÂÅÚ ÍÏÎÉÔÏÒÁ, ÐÏÔÏÍÕ ÞÔÏ ÎÁ ËÏÍÐØÀÔÅÒÅ, ÎÁ ËÏÔÏÒÙÊ ×Ù ÐÒÏÂÕÅÔÅ ÕÓÔÁÎÏ×ÉÔØ &os; ÉÌÉ ÎÅ ÐÏÄÓÏÅÄÉÎÅÎ ÍÏÎÉÔÏÒ, ÉÌÉ ÄÁÖÅ ÎÅÔ VGA ×ÙÈÏÄÁ. ÷Ù ÓÐÒÏÓÉÔÅ, ËÁË ÜÔÏ ×ÏÚÍÏÖÎÏ? éÓÐÏÌØÚÕÑ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ. ðÏÓÌÅÄÏ×ÁÔÅÌØÎÁÑ ËÏÎÓÏÌØ × Ó×ÏÅÊ ÏÓÎÏ×Å ÉÍÅÅÔ ÄÒÕÇÏÊ ËÏÍÐØÀÔÅÒ, ËÏÔÏÒÙÊ ÓÌÕÖÉÔ ÄÉÓÐÌÅÅÍ É ËÌÁ×ÉÁÔÕÒÏÊ ÄÌÑ ÓÉÓÔÅÍÙ. þÔÏÂÙ ÓÄÅÌÁÔØ ÜÔÏ, ÓÏÚÄÁÊÔÅ ÉÎÓÔÁÌÌÑÃÉÏÎÎÙÊ USB-ÎÁËÏÐÉÔÅÌØ, ËÁË ÏÐÉÓÁÎÏ × , ÉÌÉ ÓËÁÞÁÊÔÅ ÎÁÄÌÅÖÁÝÉÊ ÕÓÔÁÎÏ×ÏÞÎÙÊ ÏÂÒÁÚ ISO (ÏÐÉÓÁÎÏ × ). þÔÏÂÙ ÍÏÄÉÆÉÃÉÒÏ×ÁÔØ ÎÁÓÔÒÏÊËÉ ÉÓÔÏÞÎÉËÁ ÕÓÔÁÎÏ×ËÉ ÄÌÑ ÚÁÇÒÕÚËÉ Ó ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÏÊ ËÏÎÓÏÌÉ, ÓÌÅÄÕÊÔÅ ÜÔÏÊ ÉÎÓÔÒÕËÃÉÉ: úÁÇÒÕÚËÁ Ó USB-ÎÁËÏÐÉÔÅÌÑ Ó ×Ù×ÏÄÏÍ ÎÁ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ mount åÓÌÉ ×Ù ÐÒÏÉÚ×ÅÄÅÔÅ ÚÁÇÒÕÚËÕ Ó ÔÏÌØËÏ ÞÔÏ ÓÏÚÄÁÎÎÏÇÏ USB-ÎÁËÏÐÉÔÅÌÑ, &os; ÚÁÇÒÕÚÉÔÓÑ × ÎÏÒÍÁÌØÎÙÊ ÒÅÖÉÍ ÕÓÔÁÎÏ×ËÉ. íÙ ÈÏÔÉÍ, ÞÔÏÂÙ &os; ÚÁÇÒÕÚÉÌÁÓØ ÎÁ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ ÄÌÑ ÎÁÛÅÊ ÕÓÔÁÎÏ×ËÉ. þÔÏÂÙ ÓÄÅÌÁÔØ ÜÔÏ, ÓÍÏÎÔÉÒÕÊÔÅ USB-ÎÁËÏÐÉÔÅÌØ ÎÁ ×ÁÛÕ ÓÉÓÔÅÍÕ FreeBSD ÉÓÐÏÌØÚÕÑ ËÏÍÁÎÄÕ &man.mount.8;. &prompt.root; mount /dev/da0a /mnt éÚÍÅÎÉÔÅ ÎÁÚ×ÁÎÉÑ ÆÁÊÌÁ ÕÓÔÒÏÊÓÔ×Á É ÔÏÞËÉ ÍÏÎÔÉÒÏ×ÁÎÉÑ × ÓÏÏÔ×ÅÔÓÔ×ÉÉ ÓÏ ÚÎÁÞÅÎÉÑÍÉ ÄÌÑ ×ÁÛÅÊ ËÏÎÆÉÇÕÒÁÃÉÉ. ôÅÐÅÒØ ÎÅÏÂÈÏÄÉÍÏ ÎÁÓÔÒÏÉÔØ USB-ÎÁËÏÐÉÔÅÌØ ÄÌÑ ÚÁÇÒÕÚËÉ ÎÁ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ. ÷ ÆÁÊÌ loader.conf, ÎÁÈÏÄÑÝÉÊÓÑ ÎÁ ÆÁÊÌÏ×ÏÊ ÓÉÓÔÅÍÅ USB-ÎÁËÏÐÉÔÅÌÑ, ÄÏÂÁרÔÅ ÚÁÐÉÓØ, ÕÓÔÁÎÁ×ÌÉ×ÁÀÝÕÀ × ËÁÞÅÓÔ×Å ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ. &prompt.root; echo 'console="comconsole"' >> /mnt/boot/loader.conf äÁÌÅÅ, ËÏÇÄÁ ×ÁÛ USB-ÎÁËÏÐÉÔÅÌØ ÐÒÁ×ÉÌØÎÏ ÎÁÓÔÒÏÅÎ, ÒÁÚÍÏÎÔÉÒÕÊÔÅ ÅÇÏ Ó ÐÏÍÏÝØÀ ËÏÍÁÎÄÙ &man.umount.8;: &prompt.root; umount /mnt ôÅÐÅÒØ ÉÚ×ÌÅËÉÔÅ USB-ÎÁËÏÐÉÔÅÌØ É ÐÅÒÅÊÄÉÔÅ Ë ÔÒÅÔØÅÍÕ ÐÕÎËÔÕ ÜÔÏÊ ÉÎÓÔÒÕËÃÉÉ. úÁÇÒÕÚËÁ Ó CD Ó ×Ù×ÏÄÏÍ ÎÁ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ mount åÓÌÉ ×Ù ÐÒÏÉÚ×ÅÄÅÔÅ ÚÁÇÒÕÚËÕ Ó ÔÏÌØËÏ ÞÔÏ ÚÁÐÉÓÁÎÎÏÇÏ ÕÓÔÁÎÏ×ÏÞÎÏÇÏ CD ÄÉÓËÁ (ÐÏÄÒÏÂÎÏÓÔÉ ÓÏÚÄÁÎÉÑ ËÏÔÏÒÏÇÏ ÏÐÉÓÁÎÙ × ), &os; ÚÁÇÒÕÚÉÔÓÑ × ÎÏÒÍÁÌØÎÙÊ ÒÅÖÉÍ ÕÓÔÁÎÏ×ËÉ. ïÄÎÁËÏ, ×ÁÍ ÎÅÏÂÈÏÄÉÍÏ, ÞÔÏÂÙ &os; ÚÁÇÒÕÚÉÌÁÓØ ÎÁ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ. äÌÑ ÜÔÏÇÏ ÐÒÉÄÅÔÓÑ ÉÓÐÒÁ×ÉÔØ ISO ÏÂÒÁÚ ÚÁÒÁÎÅÅ, ÄÏ ÅÇÏ ÚÁÐÉÓÉ ÎÁ ÄÉÓË CD-R. ÷ ÐÒÉ×ÅÄ£ÎÎÏÍ ÄÁÌÅÅ ÐÒÉÍÅÒÅ ÐÏÄÒÁÚÕÍÅ×ÁÅÔÓÑ, ÞÔÏ ÐÏÄÇÏÔÏ×ËÕ ÏÂÒÁÚÁ ×Ù ×ÙÐÏÌÎÑÅÔÅ ÎÁ ×ÁÛÅÍ ×ÔÏÒÏÍ ËÏÍÐØÀÔÅÒÅ, ÒÁÂÏÔÁÀÝÅÍ ÐÏÄ ÕÐÒÁ×ÌÅÎÉÅÍ &os;. ôÁËÖÅ ÐÏÄÒÁÚÕÍÅ×ÁÅÔÓÑ, ÞÔÏ ÎÁ Î£Í ÅÓÔØ ÆÁÊÌ ÚÁÇÒÕÚÏÞÎÏÇÏ ISO ÏÂÒÁÚÁ, ÎÁÐÒÉÍÅÒ &os;-&rel.current;-RELEASE-i386-disc1.iso. éÚ×ÌÅËÉÔÅ ÉÚ ÏÂÒÁÚÁ ×ÓÅ ÆÁÊÌÙ ÕÔÉÌÉÔÏÊ &man.tar.1;: &prompt.root; mkdir /path/to/headless-iso &prompt.root; tar -C /path/to/headless-iso -pxvf &os;-&rel.current;-RELEASE-i386-disc1.iso ôÅÐÅÒØ ÎÅÏÂÈÏÄÉÍÏ ×ÎÅÓÔÉ ÎÅËÏÔÏÒÙÅ ÉÚÍÅÎÅÎÉÑ × ÎÁÂÏÒ ÆÁÊÌÏ× É ËÁÔÁÌÏÇÏ×, ÐÏÌÕÞÅÎÎÙÈ ÉÚ ÏÂÒÁÚÁ. äÏÂÁרÔÅ × ÆÁÊÌ loader.conf ÚÁÐÉÓØ, ÕÓÔÁÎÁ×ÌÉ×ÁÀÝÕÀ × ËÁÞÅÓÔ×Å ÓÉÓÔÅÍÎÏÊ ËÏÎÓÏÌÉ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ËÏÎÓÏÌØ. &prompt.root; echo 'console="comconsole"' >> /path/to/headless-iso/boot/loader.conf äÁÌÅÅ ÎÅÏÂÈÏÄÉÍÏ ÓÏÚÄÁÔØ ÎÏ×ÙÊ ÏÂÒÁÚ ISO ÉÚ ÉÚ×ÌÅÞÅÎÎÏÇÏ É ÉÓÐÒÁ×ÌÅÎÎÏÇÏ ÓÔÁÒÏÇÏ ÏÂÒÁÚÁ. äÌÑ ÜÔÏÇÏ ×ÏÓÐÏÌØÚÕÊÔÅÓØ ÕÔÉÌÉÔÏÊ &man.mkisofs.8; (ÐÏÒÔ sysutils/cdrtools): &prompt.root; mkisofs -v -b boot/cdboot -no-emul-boot -r -J -V "Headless_install" \ -o Headless-&os;-&rel.current;-RELEASE-i386-disc1.iso /path/to/headless-iso á ÔÅÐÅÒØ, ÉÍÅÑ × ÒÁÓÐÏÒÑÖÅÎÉÉ ÍÏÄÉÆÉÃÉÒÏ×ÁÎÎÙÊ ÎÏ×ÙÊ ÏÂÒÁÚ ISO, ÓÁÍÏÅ ×ÒÅÍÑ ÚÁÐÉÓÁÔØ ÅÇÏ ÎÁ ÄÉÓË CD-R ÐÒÉ ÐÏÍÏÝÉ ×ÁÛÅÊ ÌÀÂÉÍÏÊ ÐÒÏÇÒÁÍÍÙ ÄÌÑ ÚÁÐÉÓÉ ÄÉÓËÏ×. ðÏÄÓÏÅÄÉÎÅÎÉÅ ÎÕÌØ-ÍÏÄÅÍÎÏÇÏ ËÁÂÅÌÑ ÎÕÌØ-ÍÏÄÅÍÎÙÊ ËÁÂÅÌØ ôÅÐÅÒØ ÎÕÖÎÏ ÓÏÅÄÉÎÉÔØ Ä×Á ËÏÍÐØÀÔÅÒÁ ÎÕÌØ-ÍÏÄÅÍÎÙÍ ËÁÂÅÌÅÍ. ðÒÏÓÔÏ ÐÏÄÓÏÅÄÉÎÉÔÅ ÜÔÏÔ ËÁÂÅÌØ Ë ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÙÍ ÐÏÒÔÁÍ Ä×ÕÈ ËÏÍÐØÀÔÅÒÏ×. ïÂÙÞÎÙÊ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÙÊ ËÁÂÅÌØ ÎÅ ÂÕÄÅÔ ÒÁÂÏÔÁÔØ, ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÎÕÌØ-ÍÏÄÅÍÎÙÊ ËÁÂÅÌØ, ÐÏÓËÏÌØËÕ × ÎÅÍ ÎÅËÏÔÏÒÙÅ ÌÉÎÉÉ ÓÏÅÄÉÎÅÎÙ ÎÁËÒÅÓÔ. úÁÇÒÕÚËÁ ÄÌÑ ÕÓÔÁÎÏ×ËÉ îÁÓÔÁÌÏ ×ÒÅÍÑ ÎÁÞÁÔØ ÕÓÔÁÎÏ×ËÕ. ÷ÓÔÁרÔÅ USB-ÎÁËÏÐÉÔÅÌØ × ËÏÍÐØÀÔÅÒ, ÎÁ ËÏÔÏÒÙÊ ×Ù ÂÕÄÅÔÅ ÐÒÏÉÚ×ÏÄÉÔØ ÕÓÔÁÎÏ×ËÕ ÂÅÚ ÍÏÎÉÔÏÒÁ É ×ËÌÀÞÉÔÅ ÅÇÏ. åÓÌÉ ÖÅ ×Ù ÉÓÐÏÌØÚÕÅÔÅ ÚÁÇÒÕÚÏÞÎÙÊ CD ÄÉÓË, ×ÓÔÁרÔÅ ÅÇÏ × ÐÒÉ×ÏÄ ÐÏÓÌÅ ÔÏÇÏ, ËÁË ×ËÌÀÞÉÔÅ ÍÁÛÉÎÕ. ðÏÄËÌÀÞÅÎÉÅ Ë ËÏÍÐØÀÔÅÒÕ ÂÅÚ ÍÏÎÉÔÏÒÁ cu ôÅÐÅÒØ ×Ù ÍÏÖÅÔÅ ÐÏÄËÌÀÞÉÔØÓÑ Ë ÜÔÏÍÕ ËÏÍÐØÀÔÅÒÕ Ó ÐÏÍÏÝØÀ &man.cu.1;: &prompt.root; cu -l /dev/cuau0 üÔÏ ×ÓÅ! ôÅÐÅÒØ ×Ù ÍÏÖÅÔÅ ÕÐÒÁ×ÌÑÔØ ËÏÍÐØÀÔÅÒÏÍ ÂÅÚ ÍÏÎÉÔÏÒÁ ÞÅÒÅÚ ÓÅÓÓÉÀ cu. íÁÛÉÎÁ ÚÁÇÒÕÚÉÔ ÑÄÒÏ, Á ÚÁÔÅÍ ÐÏÑ×ÉÔÓÑ ×ÙÂÏÒ ÔÉÐÁ ÔÅÒÍÉÎÁÌÁ. ÷ÙÂÅÒÉÔÅ Ã×ÅÔÎÕÀ ËÏÎÓÏÌØ &os; É ÐÒÏ×ÏÄÉÔÅ ÕÓÔÁÎÏ×ËÕ! ðÏÄÇÏÔÏ×ËÁ ÓÏÂÓÔ×ÅÎÎÏÇÏ ÉÓÔÏÞÎÉËÁ ÕÓÔÁÎÏ×ËÉ þÔÏÂÙ ÎÅ ÐÏ×ÔÏÒÑÔØÓÑ, ÄÉÓË &os; × ÄÁÎÎÏÍ ÓÌÕÞÁÅ ÏÚÎÁÞÁÅÔ &os; CDROM ÉÌÉ DVD, ËÏÔÏÒÙÊ ×Ù ËÕÐÉÌÉ ÉÌÉ ÐÏÄÇÏÔÏ×ÉÌÉ ÓÁÍÏÓÔÏÑÔÅÌØÎÏ. íÏÖÅÔ ÂÙÔØ ÎÅÓËÏÌØËÏ ÓÉÔÕÁÃÉÊ, × ËÏÔÏÒÙÈ ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÐÏÄÇÏÔÏ×ÉÔØ ÓÏÂÓÔ×ÅÎÎÙÊ ÄÉÓË É/ÉÌÉ ÉÓÔÏÞÎÉË ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;. üÔÏ ÍÏÖÅÔ ÂÙÔØ ÆÉÚÉÞÅÓËÉÊ ÎÏÓÉÔÅÌØ, ÔÁËÏÊ ËÁË ÌÅÎÔÁ, ÉÌÉ ÉÓÔÏÞÎÉË, Ó ËÏÔÏÒÏÇÏ sysinstall ÓÍÏÖÅÔ ×ÚÑÔØ ÆÁÊÌÙ, ÔÁËÏÊ ËÁË ÌÏËÁÌØÎÙÊ ÓÅÒ×ÅÒ FTP, ÉÌÉ ÒÁÚÄÅÌ &ms-dos;. îÁÐÒÉÍÅÒ: õ ×ÁÓ ÅÓÔØ ÍÎÏÇÏ ËÏÍÐØÀÔÅÒÏ×, ÐÏÄÓÏÅÄÉÎÅÎÎÙÈ Ë ÌÏËÁÌØÎÏÊ ÓÅÔÉ, É ÏÄÉÎ ÄÉÓË Ó &os;. ÷Ù ÈÏÔÉÔÅ ÓÏÚÄÁÔØ ÌÏËÁÌØÎÙÊ ÓÅÒ×ÅÒ FTP, ÉÓÐÏÌØÚÕÑ ÓÏÄÅÒÖÉÍÏÅ ÄÉÓËÁ &os;, Á ÚÁÔÅÍ ÉÓÐÏÌØÚÏ×ÁÔØ Ó ×ÁÛÉÈ ËÏÍÐØÀÔÅÒÏ× ÜÔÏÔ ÌÏËÁÌØÎÙÊ ÓÅÒ×ÅÒ FTP ×ÍÅÓÔÏ ÐÏÄÓÏÅÄÉÎÅÎÉÑ Ë ÉÎÔÅÒÎÅÔ. õ ×ÁÓ ÅÓÔØ ÄÉÓË Ó &os;, É &os; ÎÅ ÒÁÓÐÏÚÎÁÅÔ ×ÁÛ CD/DVD ÐÒÉ×ÏÄ, Á &ms-dos; / &windows; ÒÁÓÐÏÚÎÁÅÔ. ÷Ù ÈÏÔÉÔÅ ÓËÏÐÉÒÏ×ÁÔØ ÆÁÊÌÙ ÕÓÔÁÎÏ×ËÉ &os; ÎÁ ÒÁÚÄÅÌ &ms-dos; ÜÔÏÇÏ ÖÅ ËÏÍÐØÀÔÅÒÁ É ÕÓÔÁÎÏ×ÉÔØ &os;, ÉÓÐÏÌØÚÕÑ ÜÔÉ ÆÁÊÌÙ. îÁ ËÏÍÐØÀÔÅÒÅ, ÎÁ ËÏÔÏÒÙÊ ×Ù ÈÏÔÉÔÅ ÐÒÏ×ÅÓÔÉ ÕÓÔÁÎÏ×ËÕ, ÎÅÔ ÎÉ ÐÒÉ×ÏÄÁ CD/DVD, ÎÉ ÓÅÔÅ×ÏÊ ËÁÒÔÙ, ÎÏ ×Ù ÍÏÖÅÔÅ ÐÏÄÓÏÅÄÉÎÉÔØÓÑ × Laplink-ÓÔÉÌÅ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÙÍ ÉÌÉ ÐÁÒÁÌÌÅÌØÎÙÍ ËÁÂÅÌÅÍ Ë ÄÒÕÇÏÍÕ ËÏÍÐØÀÔÅÒÕ, ÎÁ ËÏÔÏÒÏÍ ÏÎÉ ÅÓÔØ. ÷Ù ÈÏÔÉÔÅ ÓÏÚÄÁÔØ ÌÅÎÔÕ, ËÏÔÏÒÕÀ ÍÏÖÎÏ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;. óÏÚÄÁÎÉÅ ÕÓÔÁÎÏ×ÏÞÎÏÇÏ CDROM ÷ ÓÏÓÔÁ×Å ËÁÖÄÏÇÏ ÒÅÌÉÚÁ ÐÒÏÅËÔ &os; ÐÒÅÄÏÓÔÁ×ÌÑÅÔ ÄÏÓÔÕÐ ËÁË ÍÉÎÉÍÕÍ Ë Ä×ÕÍ ÏÂÒÁÚÁÍ CDROM (ISO images) ÄÌÑ ËÁÖÄÏÊ ÐÏÄÄÅÒÖÉ×ÁÅÍÏÊ ÁÒÈÉÔÅËÔÕÒÙ. üÔÉ ÏÂÒÁÚÙ ÍÏÇÕÔ ÂÙÔØ ÚÁÐÉÓÁÎÙ (ÐÒÏÖÖÅÎÙ) ÎÁ CD ÅÓÌÉ Õ ×ÁÓ ÅÓÔØ CD-ÒÅËÏÒÄÅÒ, Á ÚÁÔÅÍ ÉÓÐÏÌØÚÏ×ÁÎÙ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;. åÓÌÉ Õ ×ÁÓ ÅÓÔØ CD-ÒÅËÏÒÄÅÒ É ÄÅÛÅ×ÙÊ ËÁÎÁÌ ÉÎÔÅÒÎÅÔ, ÜÔÏ ÐÒÏÓÔÅÊÛÉÊ ÐÕÔØ ÕÓÔÁÎÏ×ÉÔØ &os;. óËÁÞÁÊÔÅ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÉÅ ISO ÏÂÒÁÚÙ ISO ÏÂÒÁÚÙ ÄÌÑ ËÁÖÄÏÇÏ ÒÅÌÉÚÁ ÍÏÇÕÔ ÂÙÔØ ÚÁÇÒÕÖÅÎÙ Ó ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-ÁÒÈÉÔÅËÔÕÒÁ/×ÅÒÓÉÑ ÉÌÉ Ó ÂÌÉÖÁÊÛÅÇÏ ÚÅÒËÁÌÁ. úÁÍÅÎÉÔÅ ÁÒÈÉÔÅËÔÕÒÁ É ×ÅÒÓÉÑ × ÓÏÏÔ×ÅÔÓÔ×ÉÉ ÁÒÈÉÔÅËÔÕÒÏÊ É ÎÏÍÅÒÏÍ ÒÅÌÉÚÁ ÓÏÏÔ×ÅÔÓÔ×ÅÎÎÏ. üÔÏÔ ËÁÔÁÌÏÇ ÏÂÙÞÎÏ ÓÏÄÅÒÖÉÔ ÓÌÅÄÕÀÝÉÅ ÏÂÒÁÚÙ: îÁÚ×ÁÎÉÑ ISO-ÏÂÒÁÚÏ× ÄÉÓËÏ× &os; É ÉÈ ÚÎÁÞÅÎÉÑ éÍÑ ÆÁÊÌÁ óÏÄÅÒÖÉÍÏÅ &os;-version-RELEASE-arch-bootonly.iso üÔÏÔ ÏÂÒÁÚ CD ÐÒÅÄÏÓÔÁ×ÌÑÅÔ ×ÏÚÍÏÖÎÏÓÔØ ÎÁÞÁÔØ ÐÒÏÃÅÓÓ ÕÓÔÁÎÏ×ËÉ, ÚÁÇÒÕÚÉ×ÛÉÓØ Ó ÄÉÓËÁ × ÐÒÉ×ÏÄÅ CD-ROM. ïÄÎÁËÏ, × Î£Í ÏÔÓÕÔÓÔ×ÕÀÔ ÁÒÈÉ×Ù, ÎÅÏÂÈÏÄÉÍÙÅ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os; Ó ÜÔÏÇÏ ÖÅ ÄÉÓËÁ. ðÏÄÒÁÚÕÍÅ×ÁÅÔÓÑ, ÞÔÏ ÎÅÏÂÈÏÄÉÍÙÅ ÆÁÊÌÙ ÂÕÄÕÔ ÓËÁÞÁÎÙ ÉÚ ÄÏÓÔÕÐÎÙÈ × ÓÅÔÉ ÉÓÔÏÞÎÉËÏ× (ÎÁÐÒÉÍÅÒ, c ÓÅÒ×ÅÒÁ FTP). &os;-version-RELEASE-arch-dvd1.iso.gz üÔÏÔ ÏÂÒÁÚ DVD ÓÏÄÅÒÖÉÔ ×Ó£ ÎÅÏÂÈÏÄÉÍÏÅ ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÂÁÚÏ×ÏÊ ÓÉÓÔÅÍÙ &os;, Á ÔÁËÖÅ — ÄÏËÕÍÅÎÔÁÃÉÀ É ÎÁÂÏÒ ÐÒÅËÏÍÐÉÌÉÒÏ×ÁÎÎÙÈ ÐÁËÅÔÏ×. ôÁËÖÅ ÏÂÒÁÚ ÐÏÄÄÅÒÖÉ×ÁÅÔ ×ÏÚÍÏÖÎÏÓÔØ ÚÁÇÒÕÚËÉ × ÒÅÖÉÍ livefs. &os;-version-RELEASE-arch-memstick.img üÔÏÔ ÏÂÒÁÚ ÐÒÅÄÎÁÚÎÁÞÅÎ ÄÌÑ ÓÏÚÄÁÎÉÑ ÚÁÇÒÕÚÏÞÎÙÈ USB-ÎÁËÏÐÉÔÅÌÅÊ. ôÁËÏÊ ÎÁËÏÐÉÔÅÌØ ÍÏÖÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ ÎÁ ÍÁÛÉÎÙ, ÐÏÄÄÅÒÖÉ×ÁÀÝÉÅ ÚÁÇÒÕÚËÕ Ó USB ÄÉÓËÏ×. USB-ÎÁËÏÐÉÔÅÌØ ÔÁËÖÅ ÍÏÖÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÄÌÑ Á×ÁÒÉÊÎÏÇÏ ×ÏÓÓÔÁÎÏ×ÌÅÎÉÑ ÓÉÓÔÅÍÙ (ÓÏÄÅÒÖÉÔ livefs). ÷ ÏÂÒÁÚÅ ÔÁËÖÅ ÉÍÅÀÔÓÑ ÐÁËÅÔÙ Ó ÄÏËÕÍÅÎÔÁÃÉÅÊ. &os;-version-RELEASE-arch-disc1.iso üÔÏÔ ÏÂÒÁÚ CD ÓÏÄÅÒÖÉÔ ÂÁÚÏ×ÕÀ ÓÉÓÔÅÍÕ &os; É ÎÁÂÏÒ ÐÁËÅÔÏ× Ó ÄÏËÕÍÅÎÔÁÃÉÅÊ. &os;-version-RELEASE-arch-disc2.iso üÔÏÔ ÏÂÒÁÚ CD ÓÏÄÅÒÖÉÔ ÐÁËÅÔÙ ÓÔÏÒÏÎÎÉÈ ÒÁÚÒÁÂÏÔÞÉËÏ×, ËÏÔÏÒÙÅ ÓÍÏÇÌÉ ÐÏÍÅÓÔÉÔØÓÑ ÎÁ ÄÉÓË. äÌÑ &os; 9.X ÐÏÄÏÂÎÙÅ ÏÂÒÁÚÙ ÎÅ ÓÏÚÄÁ×ÁÌÉÓØ. &os;-version-RELEASE-arch-disc3.iso åÝÅ ÏÄÉÎ ÏÂÒÁÚ CD, ÚÁÐÏÌÎÅÎÎÙÊ ÐÁËÅÔÁÍÉ ÓÔÏÒÏÎÎÉÈ ÒÁÚÒÁÂÏÔÞÉËÏ×. üÔÏÔ ÏÂÒÁÚ ÎÅ ÓÏÚÄÁ×ÁÌÓÑ ÄÌÑ &os; 9.X. &os;-version-RELEASE-arch-livefs.iso äÁÎÎÙÊ ÏÂÒÁÚ CD ÐÏÄÄÅÒÖÉ×ÁÅÔ ÚÁÇÒÕÚËÕ × ÒÅÖÉÍ Á×ÁÒÉÊÎÏÇÏ ×ÏÓÓÔÁÎÏ×ÌÅÎÉÑ ÓÉÓÔÅÍÙ (ÓÏÄÅÒÖÉÔ livefs) É ÎÅ ÐÒÅÄÎÁÚÎÁÞÅÎ ÄÌÑ ×ÙÐÏÌÎÅÎÉÑ ÕÓÔÁÎÏ×ËÉ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ Ó ÓÁÍÏÇÏ ÄÉÓËÁ.
÷Ù ÄÏÌÖÎÙ ÚÁÇÒÕÚÉÔØ ÌÉÂÏ ISO-ÏÂÒÁÚ bootonly, ÌÉÂÏ ÏÂÒÁÚ disc1. îÅ ÚÁÇÒÕÖÁÊÔÅ ÉÈ ÏÂÁ, ÔÁË ËÁË ÏÂÒÁÚ disc1 ÓÏÄÅÒÖÉÔ ×Ó£, ÞÔÏ ÅÓÔØ ÎÁ ISO-ÏÂÒÁÚÅ bootonly. éÓÐÏÌØÚÕÊÔÅ ISO-ÏÂÒÁÚ bootonly, ÅÓÌÉ ÄÏÓÔÕÐ × Internet ÄÌÑ ×ÁÓ ÏÂÈÏÄÉÔÓÑ ÎÅÄÏÒÏÇÏ. ïÎ ÐÏÚ×ÏÌÉÔ ×ÁÍ ÕÓÔÁÎÏ×ÉÔØ &os;, É ×Ù ÓÍÏÖÅÔÅ ÕÓÔÁÎÏ×ÉÔØ ×ÐÏÓÌÅÄÓÔ×ÉÉ ÐÒÏÇÒÁÍÍÙ ÓÔÏÒÏÎÎÉÈ ÐÒÏÉÚ×ÏÄÉÔÅÌÅÊ ÉÓÐÏÌØÚÕÑ ÓÉÓÔÅÍÕ ÐÏÒÔÏ×/ÐÁËÅÔÏ× (ÓÍÏÔÒÉÔÅ ) ÅÓÌÉ ÎÅÏÂÈÏÄÉÍÏ. éÓÐÏÌØÚÕÊÔÅ ÏÂÒÁÚ dvd1, ÅÓÌÉ ×Ù ÈÏÔÉÔÅ ÕÓÔÁÎÏ×ÉÔØ ÒÅÌÉÚ &os; É ÐÏÌÕÞÉÔØ ÄÏÓÔÁÔÏÞÎÙÊ ÎÁÂÏÒ ÐÒÏÇÒÁÍÍ ÓÔÏÒÏÎÎÉÈ ÐÒÏÉÚ×ÏÄÉÔÅÌÅÊ, ÒÁÓÐÏÌÏÖÅÎÎÙÈ ÎÁ ÜÔÏÍ ÄÉÓËÅ. äÏÐÏÌÎÉÔÅÌØÎÙÅ ÏÂÒÁÚÙ ÄÉÓËÏ× ÐÏÌÅÚÎÙ, ÎÏ ÎÅ ÎÅÏÂÈÏÄÉÍÙ, ÏÓÏÂÅÎÎÏ ÅÓÌÉ Õ ×ÁÓ ÅÓÔØ ×ÙÓÏËÏÓËÏÒÏÓÔÎÏÊ ÄÏÓÔÕÐ Ë ÉÎÔÅÒÎÅÔ.
úÁÐÉÓØ CD úÁÔÅÍ ×ÁÍ ÎÕÖÎÏ ÚÁÐÉÓÁÔØ ÏÂÒÁÚÙ CD ÎÁ ÄÉÓËÉ. åÓÌÉ ×Ù ÄÅÌÁÅÔÅ ÜÔÏ ÉÚ ÄÒÕÇÏÊ ÓÉÓÔÅÍÙ &os;, ÏÂÒÁÔÉÔÅÓØ Ë ÚÁ ÂÏÌÅÅ ÐÏÄÒÏÂÎÏÊ ÉÎÆÏÒÍÁÃÉÅÊ (× ÞÁÓÔÎÏÓÔÉ, É ). åÓÌÉ ×Ù ÄÅÌÁÅÔÅ ÜÔÏ × ÄÒÕÇÏÊ ÓÉÓÔÅÍÅ, ÐÏÔÒÅÂÕÅÔÓÑ ÉÓÐÏÌØÚÏ×ÁÔØ ÔÅ ÕÔÉÌÉÔÙ ÄÌÑ ÕÐÒÁ×ÌÅÎÉÑ CD-ÒÅËÏÒÄÅÒÏÍ, ËÏÔÏÒÙÅ ÅÓÔØ × ÜÔÏÊ ÓÉÓÔÅÍÅ. ïÂÒÁÚÙ ÄÉÓËÏ× ÐÒÅÄÏÓÔÁ×ÌÑÀÔÓÑ × ÓÔÁÎÄÁÒÔÎÏÍ ÆÏÒÍÁÔÅ ISO, ËÏÔÏÒÙÊ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ ÍÎÏÇÉÍÉ ÐÒÏÇÒÁÍÍÁÍÉ.
åÓÌÉ ×Ù ÉÎÔÅÒÅÓÕÅÔÅÓØ ÓÏÚÄÁÎÉÅÍ ÓÏÂÓÔ×ÅÎÎÙÈ ×ÁÒÉÁÎÔÏ× ÒÅÌÉÚÏ× &os;, ÐÏÖÁÌÕÊÓÔÁ, ÐÒÏÞÔÉÔÅ ÓÔÁÔØÀ Ï ðÒÏÃÅÓÓÅ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ×.
óÏÚÄÁÎÉÅ ÌÏËÁÌØÎÏÇÏ ÓÅÒ×ÅÒÁ FTP Ó &os; ÕÓÔÁÎÏ×ËÁ ÓÅÔØ FTP äÉÓË &os; ÓÆÏÒÍÉÒÏ×ÁÎ ÔÁË ÖÅ, ËÁË É ÓÅÒ×ÅÒ FTP. üÔÏ ÓÉÌØÎÏ ÕÐÒÏÝÁÅÔ ÓÏÚÄÁÎÉÅ ÌÏËÁÌØÎÏÇÏ ÓÅÒ×ÅÒÁ FTP, ËÏÔÏÒÙÊ ÍÏÖÅÔ ÂÙÔØ ÉÓÐÏÌØÚÏ×ÁÎ ÄÒÕÇÉÍÉ ËÏÍÐØÀÔÅÒÁÍÉ ×ÁÛÅÊ ÓÅÔÉ ÄÌÑ ÕÓÔÁÎÏ×ËÉ &os;. õÂÅÄÉÔÅÓØ, ÞÔÏ ÎÁ ËÏÍÐØÀÔÅÒÅ &os;, ÎÁ ËÏÔÏÒÏÍ ÂÕÄÅÔ ÕÓÔÁÎÏ×ÌÅÎ ÓÅÒ×ÅÒ FTP, CDROM ÎÁÈÏÄÉÔÓÑ × ÐÒÉ×ÏÄÅ É ÓÍÏÎÔÉÒÕÊÔÅ /cdrom. &prompt.root; mount /cdrom óÏÚÄÁÊÔÅ ÕÞÅÔÎÕÀ ÚÁÐÉÓØ ÄÌÑ anonymous FTP × /etc/passwd. óÄÅÌÁÊÔÅ ÜÔÏ, ÏÔÒÅÄÁËÔÉÒÏ×Á× /etc/passwd Ó ÐÏÍÏÝØÀ &man.vipw.8; É ÄÏÂÁ×É× ÜÔÕ ÓÔÒÏËÕ: ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent õÂÅÄÉÔÅÓØ ÞÔÏ ÓÅÒ×ÉÓ FTP ×ËÌÀÞÅÎ × /etc/inetd.conf. ÷ÓÑËÉÊ, ËÔÏ ÍÏÖÅÔ ÐÏÄÓÏÅÄÉÎÉÔØÓÑ ÐÏ ÓÅÔÉ Ë ×ÁÛÅÍÕ ËÏÍÐØÀÔÅÒÕ, ÍÏÖÅÔ ×ÙÂÒÁÔØ ÔÉÐ ÎÏÓÉÔÅÌÑ FTP É ÎÁÂÒÁÔØ ftp://×ÁÛ ËÏÍÐØÀÔÅÒ ÐÏÓÌÅ ×ÙÂÏÒÁ Other × ÍÅÎÀ ÓÅÒ×ÅÒÏ× FTP ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ. åÓÌÉ ÚÁÇÒÕÚÏÞÎÙÊ ÎÏÓÉÔÅÌØ (ÏÂÙÞÎÏ ÜÔÏ ÄÉÓËÅÔÙ) ÄÌÑ ×ÁÛÉÈ FTP-ËÌÉÅÎÔÏ× × ÔÏÞÎÏÓÔÉ ÎÅ ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ ×ÅÒÓÉÉ, ÎÁÈÏÄÑÝÅÊÓÑ ÎÁ ÌÏËÁÌØÎÏÍ ÓÅÒ×ÅÒÅ FTP, ÔÏ sysinstall ÎÅ ÐÏÚ×ÏÌÉÔ ×ÁÍ ÚÁ×ÅÒÛÉÔØ ÕÓÔÁÎÏ×ËÕ. åÓÌÉ ×ÅÒÓÉÉ ÐÏÈÏÖÉ É ×Ù ÈÏÔÉÔÅ ÜÔÏ Ñ×ÎÏ ÕËÁÚÁÔØ, ÔÏ ÐÅÒÅÊÄÉÔÅ × ÍÅÎÀ Options É ÚÁÍÅÎÉÔÅ ÎÁÚ×ÁÎÉÅ ÄÉÓÔÒÉÂÕÔÉ×Á ÎÁ any. üÔÏÔ ÐÏÄÈÏÄ ÈÏÒÏÛ ÄÌÑ ËÏÍÐØÀÔÅÒÁ × ×ÁÛÅÊ ÌÏËÁÌØÎÏÊ ÓÅÔÉ, ÚÁÝÉÝÅÎÎÏÇÏ Ó ÐÏÍÏÝØÀ ÆÁÊÒ×ÏÌÌÁ. ðÒÅÄÏÓÔÁ×ÌÅÎÉÅ ÓÅÒ×ÉÓÁ FTP ÄÒÕÇÉÍ ËÏÍÐØÀÔÅÒÁÍ ÞÅÒÅÚ ÉÎÔÅÒÎÅÔ (Á ÎÅ ÞÅÒÅÚ ÌÏËÁÌØÎÕÀ ÓÅÔØ) ÐÒÉ×ÌÅËÁÅÔ Ë ×ÁÛÅÍÕ ËÏÍÐØÀÔÅÒÕ ×ÎÉÍÁÎÉÅ ËÒÁËÅÒÏ× É ÄÒÕÇÉÈ ÌÉÃ, ÞØÅ ×ÎÉÍÁÎÉÅ ÎÅÖÅÌÁÔÅÌØÎÏ. íÙ ÎÁÓÔÏÑÔÅÌØÎÏ ÒÅËÏÍÅÎÄÕÅÍ ÐÒÉÄÅÒÖÉ×ÁÔØÓÑ ÐÒÁ×ÉÌØÎÏÊ ÐÏÌÉÔÉËÉ ÂÅÚÏÐÁÓÎÏÓÔÉ, ÅÓÌÉ ×Ù ÄÅÌÁÅÔÅ ÜÔÏ. óÏÚÄÁÎÉÅ ÄÉÓËÅÔ ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÕÓÔÁÎÏ×ËÁ ÄÉÓËÅÔÙ åÓÌÉ ×ÁÍ ÔÒÅÂÕÅÔÓÑ ×ÙÐÏÌÎÉÔØ ÕÓÔÁÎÏ×ËÕ Ó ÄÉÓËÅÔ (ÞÅÇÏ ÍÙ ÎÅ ÒÅËÏÍÅÎÄÕÅÍ ÄÅÌÁÔØ) ÉÌÉ ÐÏ ÐÒÉÞÉÎÅ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÍÏÇÏ ÏÂÏÒÕÄÏ×ÁÎÉÑ, ÉÌÉ ÐÒÏÓÔÏ ÐÏÔÏÍÕ, ÞÔÏ ×Ù ÎÅ ÌÀÂÉÔÅ ÐÒÏÓÔÙÈ ÐÕÔÅÊ, ÐÏÔÒÅÂÕÅÔÓÑ ÓÎÁÞÁÌÁ ÐÏÄÇÏÔÏ×ÉÔØ ÎÅÓËÏÌØËÏ ÄÉÓËÅÔ ÄÌÑ ÕÓÔÁÎÏ×ËÉ. ëÁË ÍÉÎÉÍÕÍ, ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÓÔÏÌØËÏ 1.44 MB ÄÉÓËÅÔ, ÓËÏÌØËÏ ÎÕÖÎÏ, ÞÔÏÂÙ ×ÍÅÓÔÉÔØ ×ÓÅ ÆÁÊÌÙ ÉÚ ËÁÔÁÌÏÇÁ base (base distribution). åÓÌÉ ×Ù ÐÏÄÇÏÔÁ×ÌÉ×ÁÅÔÅ ÜÔÉ ÄÉÓËÅÔÙ ÉÚ &ms-dos;, ÏÎÉ ÄÏÌÖÎÙ ÂÙÔØ ÏÔÆÏÒÍÁÔÉÒÏ×ÁÎÙ Ó ÐÏÍÏÝØÀ ËÏÍÁÎÄÙ &ms-dos; FORMAT. åÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ &windows;, ÉÓÐÏÌØÚÕÊÔÅ Explorer ÄÌÑ ÆÏÒÍÁÔÉÒÏ×ÁÎÉÑ ÄÉÓËÏ× (ËÌÉËÎÉÔÅ ÐÒÁ×ÏÊ ËÎÏÐËÏÊ ÍÙÛÉ ÎÁ ÄÉÓËÅ A: É ×ÙÂÅÒÉÔÅ Format). îÅ ÄÏ×ÅÒÑÊÔÅ ÚÁ×ÏÄÓËÏÍÕ ÆÏÒÍÁÔÉÒÏ×ÁÎÉÀ ÄÉÓËÅÔ. ïÔÆÏÒÍÁÔÉÒÕÊÔÅ ÉÈ ÅÝÅ ÒÁÚ ÓÁÍÏÓÔÏÑÔÅÌØÎÏ, ÐÒÏÓÔÏ ÄÌÑ Õ×ÅÒÅÎÎÏÓÔÉ. íÎÏÖÅÓÔ×Ï ÐÒÏÂÌÅÍ, Ï ËÏÔÏÒÙÈ ÓÏÏÂÝÁÌÉ ÎÁÛÉ ÐÏÌØÚÏ×ÁÔÅÌÉ, ÂÙÌÉ ÒÅÚÕÌØÔÁÔÏÍ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÎÅÐÒÁ×ÉÌØÎÏ ÏÔÆÏÒÍÁÔÉÒÏ×ÁÎÎÙÈ ÄÉÓËÏ×, ÐÏÜÔÏÍÕ ÍÙ ÓÅÊÞÁÓ ÏÂÒÁÝÁÅÍ ÎÁ ÜÔÏ ×ÎÉÍÁÎÉÅ. åÓÌÉ ×Ù ÓÏÚÄÁÅÔÅ ÏÂÒÁÚÙ ÎÁ ÄÒÕÇÏÍ ËÏÍÐØÀÔÅÒÅ &os;, ÆÏÒÍÁÔÉÒÏ×ÁÎÉÅ ×ÓÅ ÅÝÅ ÎÅ ÌÉÛÎÅ, ÈÏÔÑ ×ÁÍ ÎÅ ÐÏÔÒÅÂÕÅÔÓÑ ÓÏÚÄÁ×ÁÔØ ÆÁÊÌÏ×ÕÀ ÓÉÓÔÅÍÕ &ms-dos; ÎÁ ËÁÖÄÏÊ ÄÉÓËÅÔÅ. ÷Ù ÍÏÖÅÔÅ ÉÓÐÏÌØÚÏ×ÁÔØ bsdlabel É newfs ÄÌÑ ÓÏÚÄÁÎÉÑ ÎÁ ÎÉÈ ÆÁÊÌÏ×ÙÈ ÓÉÓÔÅÍ UFS, × ÓÌÅÄÕÀÝÅÊ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÏÓÔÉ (ÄÌÑ 3.5" 1.44 MB ÄÉÓËÅÔ): &prompt.root; fdformat -f 1440 fd0.1440 &prompt.root; bsdlabel -w fd0.1440 floppy3 &prompt.root; newfs -t 2 -u 18 -l 1 -i 65536 /dev/fd0 úÁÔÅÍ ×Ù ÍÏÖÅÔÅ ÓÍÏÎÔÉÒÏ×ÁÔØ ÉÈ É ÐÉÓÁÔØ ÎÁ ÎÉÈ ËÁË ÎÁ ÌÀÂÕÀ ÄÒÕÇÕÀ ÆÁÊÌÏ×ÕÀ ÓÉÓÔÅÍÕ. ðÏÓÌÅ ÆÏÒÍÁÔÉÒÏ×ÁÎÉÑ ÄÉÓËÅÔ ×ÁÍ ÐÏÔÒÅÂÕÅÔÓÑ ÓËÏÐÉÒÏ×ÁÔØ ÎÁ ÎÉÈ ÆÁÊÌÙ. æÁÊÌÙ ÄÉÓÔÒÉÂÕÔÉ×Á ÒÁÚÄÅÌÅÎÙ ÎÁ ÞÁÓÔÉ, ÒÁÚÍÅÒ ËÏÔÏÒÙÈ ÐÏÚ×ÏÌÑÅÔ ÌÅÇËÏ ÒÁÚÍÅÓÔÉÔØ ÐÑÔØ ÞÁÓÔÅÊ ÎÁ ÏÂÙÞÎÏÊ 1.44 MB ÄÉÓËÅÔÅ. úÁÐÏÌÎÉÔÅ ×ÓÅ ÄÉÓËÅÔÙ ÆÁÊÌÁÍÉ, ÐÏÍÅÝÁÑ ÓÔÏÌØËÏ ÆÁÊÌÏ× ÎÁ ÏÄÎÕ ÄÉÓËÅÔÕ, ÓËÏÌØËÏ ÕÍÅÓÔÉÔÓÑ, ÐÏËÁ Õ ×ÁÓ ÎÅ ÂÕÄÅÔ ×ÓÅÈ ÎÅÏÂÈÏÄÉÍÙÈ ËÏÍÐÏÎÅÎÔ ÄÉÓÔÒÉÂÕÔÉ×Á. ëÁÖÄÙÊ ËÏÍÐÏÎÅÎÔ ÄÏÌÖÅÎ ÒÁÓÐÏÌÁÇÁÔØÓÑ × ÐÏÄËÁÔÁÌÏÇÅ ÎÁ ÄÉÓËÅÔÅ, ÎÁÐÒÉÍÅÒ a:\base\base.aa, a:\base\base.ab, É ÔÁË ÄÁÌÅÅ. æÁÊÌ base.inf ÔÁËÖÅ ÎÅÏÂÈÏÄÉÍÏ ÐÏÍÅÓÔÉÔØ ÎÁ ÐÅÒ×ÕÀ ÄÉÓËÅÔÕ ÎÁÂÏÒÁ base. ðÒÏÞÉÔÁ× ÜÔÏÔ ÆÁÊÌ, ÕÓÔÁÎÏ×ÏÞÎÁÑ ÐÒÏÇÒÁÍÍÁ ÏÐÒÅÄÅÌÑÅÔ, ÓËÏÌØËÏ ÞÁÓÔÅÊ ÎÅÏÂÈÏÄÉÍÏ ÓËÏÐÉÒÏ×ÁÔØ É ÓÏÅÄÉÎÉÔØ ÄÌÑ ÓÂÏÒËÉ ÄÉÓÔÒÉÂÕÔÉ×Á. ëÁË ÔÏÌØËÏ × ÐÒÏÃÅÓÓÅ ÕÓÔÁÎÏ×ËÉ ÐÏÑ×ÉÔÓÑ ÜËÒÁÎ Media, ×ÙÂÅÒÉÔÅ Floppy É ÕÓÔÁÎÏ×ËÁ ÐÒÏÄÏÌÖÉÔÓÑ. õÓÔÁÎÏ×ËÁ Ó ÒÁÚÄÅÌÁ &ms-dos; ÕÓÔÁÎÏ×ËÁ Ó MS-DOS þÔÏÂÙ ÐÏÄÇÏÔÏ×ÉÔØÓÑ Ë ÕÓÔÁÎÏ×ËÅ Ó ÒÁÚÄÅÌÁ &ms-dos;, ÓËÏÐÉÒÕÊÔÅ ÆÁÊÌÙ Ó ÄÉÓÔÒÉÂÕÔÉ×Á × ËÁÔÁÌÏÇ freebsd ËÏÒÎÅ×ÏÇÏ ËÁÔÁÌÏÇÁ ÒÁÚÄÅÌÁ. îÁÐÒÉÍÅÒ, c:\freebsd. óÔÒÕËÔÕÒÁ ËÁÔÁÌÏÇÁ CDROM ÉÌÉ ÓÅÒ×ÅÒÁ FTP ÄÏÌÖÎÁ ÂÙÔØ × ÔÏÞÎÏÓÔÉ ×ÏÓÐÒÏÉÚ×ÅÄÅÎÁ × ÜÔÏÍ ËÁÔÁÌÏÇÅ, ÍÙ ÐÒÅÄÌÁÇÁÅÍ ÉÓÐÏÌØÚÏ×ÁÔØ ËÏÍÁÎÄÕ &ms-dos; xcopy ÅÓÌÉ ×Ù ËÏÐÉÒÕÅÔÅ ÄÉÓÔÒÉÂÕÔÉ× Ó CD. îÁÐÒÉÍÅÒ, ÞÔÏÂÙ ÐÏÄÇÏÔÏ×ÉÔØ ÍÉÎÉÍÁÌØÎÕÀ ÕÓÔÁÎÏ×ËÕ &os;: C:\> md c:\freebsd C:\> xcopy e:\bin c:\freebsd\bin\ /s C:\> xcopy e:\manpages c:\freebsd\manpages\ /s ðÒÅÄÐÏÌÁÇÁÅÔÓÑ, ÞÔÏ ÎÁ C: ÅÓÔØ Ó×ÏÂÏÄÎÏÅ ÍÅÓÔÏ, Á ÎÁ E: ÓÍÏÎÔÉÒÏ×ÁÎ CDROM. åÓÌÉ Õ ×ÁÓ ÎÅÔ CDROM, ÍÏÖÎÏ ÚÁÇÒÕÚÉÔØ ÄÉÓÔÒÉÂÕÔÉ× Ó ftp.FreeBSD.org. ëÁÖÄÙÊ ËÏÍÐÏÎÅÎÔ ÎÁÈÏÄÉÔÓÑ × Ó×ÏÅÍ ÓÏÂÓÔ×ÅÎÎÏÍ ËÁÔÁÌÏÇÅ, ÎÁÐÒÉÍÅÒ ËÏÍÐÏÎÅÎÔ base ÍÏÖÎÏ ÎÁÊÔÉ × ËÁÔÁÌÏÇÅ &rel.current;/base/. ÷ÓÅ ËÏÍÐÏÎÅÎÔÙ, ËÏÔÏÒÙÅ ×Ù ÂÕÄÅÔÅ ÕÓÔÁÎÁ×ÌÉ×ÁÔØ Ó ÒÁÚÄÅÌÁ &ms-dos; (É ÄÌÑ ËÏÔÏÒÙÈ Õ ×ÁÓ ÅÓÔØ ÍÅÓÔÏ), ÎÕÖÎÏ ÒÁÓÐÏÌÏÖÉÔØ × c:\freebsd — ÄÌÑ ÍÉÎÉÍÁÌØÎÏÊ ÕÓÔÁÎÏ×ËÉ ÎÕÖÎÁ ÔÏÌØËÏ ËÏÍÐÏÎÅÎÔÁ BIN. óÏÚÄÁÎÉÅ ÌÅÎÔÙ ÄÌÑ ÕÓÔÁÎÏ×ËÉ ÕÓÔÁÎÏ×ËÁ Ó ÌÅÎÔÙ QIC/SCSI õÓÔÁÎÏ×ËÁ Ó ÌÅÎÔÙ ÜÔÏ ×ÏÚÍÏÖÎÏ ÓÁÍÙÊ ÐÒÏÓÔÏÊ ÍÅÔÏÄ, ÕÓÔÕÐÁÀÝÉÊ ÔÏÌØËÏ ÕÓÔÁÎÏ×ËÅ Ó FTP ÉÌÉ CDROM. ðÒÏÇÒÁÍÍÁ ÕÓÔÁÎÏ×ËÉ ÍÏÖÅÔ ÎÁÊÔÉ ÎÁ ÌÅÎÔÅ ÆÁÊÌÙ, ËÏÔÏÒÙÅ ÚÁÐÉÓÁÎÙ ÎÁ ÎÅÅ Ó ÐÏÍÏÝØÀ tar. ðÏÓÌÅ ÐÏÌÕÞÅÎÉÑ ×ÓÅÈ ÆÁÊÌÏ× ÄÉÓÔÒÉÂÕÔÉ×Á, ËÏÔÏÒÙÅ ×ÁÍ ÎÕÖÎÙ, ÚÁÐÉÛÉÔÅ ÉÈ ÎÁ ÌÅÎÔÕ Ó ÐÏÍÏÝØÀ tar: &prompt.root; cd /freebsd/distdir &prompt.root; tar cvf /dev/rwt0 dist1 ... dist2 ëÏÇÄÁ ×Ù ÐÒÉÓÔÕÐÉÔÅ Ë ÕÓÔÁÎÏ×ËÅ, ÎÕÖÎÏ ÕÂÅÄÉÔØÓÑ × ÎÁÌÉÞÉÉ ÄÏÓÔÁÔÏÞÎÏÇÏ ÍÅÓÔÁ ×Ï ×ÒÅÍÅÎÎÏÍ ËÁÔÁÌÏÇÅ (ËÏÔÏÒÙÊ ÂÕÄÅÔ ÐÒÅÄÌÏÖÅÎÏ ×ÙÂÒÁÔØ), ÞÔÏÂÙ ÐÏÍÅÓÔÉÌÏÓØ ×ÓÅ ÓÏÄÅÒÖÉÍÏÅ ÚÁÐÉÓÁÎÎÏÊ ÌÅÎÔÙ. ðÏÓËÏÌØËÕ ÌÅÎÔÁ — ÕÓÔÒÏÊÓÔ×Ï ÎÅ-ÐÒÏÉÚ×ÏÌØÎÏÇÏ ÄÏÓÔÕÐÁ, ÜÔÏÔ ÍÅÔÏÄ ÕÓÔÁÎÏ×ËÉ ÔÒÅÂÕÅÔ ÎÅËÏÔÏÒÏÇÏ ÍÅÓÔÁ ×Ï ×ÒÅÍÅÎÎÏÍ ÈÒÁÎÉÌÉÝÅ. ðÒÉ ÎÁÞÁÌÅ ÕÓÔÁÎÏ×ËÉ ÌÅÎÔÁ ÄÏÌÖÎÁ ÂÙÔØ × ÐÒÉ×ÏÄÅ ÄÏ ÚÁÇÒÕÚËÉ Ó ÄÉÓËÅÔÙ. ÷ ÉÎÏÍ ÓÌÕÞÁÅ ÏÎÁ ÍÏÖÅÔ ÂÙÔØ ÎÅ ÎÁÊÄÅÎÁ ÐÒÉ ÔÅÓÔÉÒÏ×ÁÎÉÉ ÕÓÔÒÏÊÓÔ×. ðÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ ÐÏ ÓÅÔÉ ÕÓÔÁÎÏ×ËÁ ÓÅÔØ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÁÑ (PPP) ÕÓÔÁÎÏ×ËÁ ÓÅÔØ ÐÁÒÁÌÌÅÌØÎÁÑ (PLIP) ÕÓÔÁÎÏ×ËÁ ÓÅÔØ Ethernet åÓÔØ ÔÒÉ ×ÏÚÍÏÖÎÙÈ ÔÉÐÁ ÕÓÔÁÎÏ×ËÉ ÐÏ ÓÅÔÉ. Ethernet (ÓÔÁÎÄÁÒÔÎÙÊ Ethernet ËÏÎÔÒÏÌÌÅÒ), ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÙÊ ÐÏÒÔ (PPP), ÉÌÉ ÐÁÒÁÌÌÅÌØÎÙÊ ÐÏÒÔ (PLIP (laplink ËÁÂÅÌØ)). äÌÑ ÓÁÍÏÊ ÂÙÓÔÒÏÊ ÕÓÔÁÎÏ×ËÉ ÐÏ ÓÅÔÉ ÈÏÒÏÛÉÍ ×ÙÂÏÒÏÍ ÂÕÄÅÔ Ethernet ÁÄÁÐÔÅÒ! &os; ÐÏÄÄÅÒÖÉ×ÁÅÔ ÂÏÌØÛÉÎÓÔ×Ï PC Ethernet ËÁÒÔ; ÓÐÉÓÏË ÐÏÄÄÅÒÖÉ×ÁÅÍÙÈ ËÁÒÔ (É ÔÒÅÂÕÅÍÙÈ ÄÌÑ ÎÉÈ ÕÓÔÁÎÏ×ÏË) ÐÒÅÄÏÓÔÁ×ÌÑÅÔÓÑ × ÉÎÆÏÒÍÁÃÉÉ Ï ÏÂÏÒÕÄÏ×ÁÎÉÉ ÄÌÑ ËÁÖÄÏÇÏ ÒÅÌÉÚÁ &os;. åÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ ÏÄÎÕ ÉÚ ÐÏÄÄÅÒÖÉ×ÁÅÍÙÈ PCMCIA Ethernet ËÁÒÔ, ÕÂÅÄÉÔÅÓØ ÔÁËÖÅ, ÞÔÏ ÏÎÁ ÐÏÄËÌÀÞÅÎÁ ÐÅÒÅÄ ÔÅÍ, ËÁË ÎÏÕÔÂÕË ÂÕÄÅÔ ×ËÌÀÞÅÎ! ë ÓÏÖÁÌÅÎÉÀ, &os; × ÎÁÓÔÏÑÝÅÅ ×ÒÅÍÑ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔ ÇÏÒÑÞÅÅ ÐÏÄËÌÀÞÅÎÉÅ PCMCIA ËÁÒÔ ×Ï ×ÒÅÍÑ ÕÓÔÁÎÏ×ËÉ. ÷ÁÍ ÔÁËÖÅ ÐÏÔÒÅÂÕÅÔÓÑ ÚÎÁÔØ IP ÁÄÒÅÓ × ÓÅÔÉ, ÓÅÔÅ×ÕÀ ÍÁÓËÕ ÄÌÑ ËÌÁÓÓÁ ÐÏÄÓÅÔÉ, É ÉÍÑ ËÏÍÐØÀÔÅÒÁ. åÓÌÉ ×Ù ÄÅÌÁÅÔÅ ÕÓÔÁÎÏ×ËÕ ÞÅÒÅÚ ÓÏÅÄÉÎÅÎÉÅ PPP É Õ ×ÁÓ ÎÅÔ ÓÔÁÔÉÞÅÓËÏÇÏ IP, ÎÅ ÂÏÊÔÅÓØ, IP ÁÄÒÅÓ ÂÕÄÅÔ ÄÉÎÁÍÉÞÅÓËÉ ×ÙÄÅÌÅÎ ×ÁÍ ÐÒÏ×ÁÊÄÅÒÏÍ. óÉÓÔÅÍÎÙÊ ÁÄÍÉÎÉÓÔÒÁÔÏÒ ÍÏÖÅÔ ÐÏÄÓËÁÚÁÔØ ×ÁÍ, ËÁËÉÅ ÚÎÁÞÅÎÉÑ ÉÓÐÏÌØÚÏ×ÁÔØ ÄÌÑ ÄÁÎÎÏÊ ÕÓÔÁÎÏ×ËÉ ÐÏ ÓÅÔÉ. åÓÌÉ ×Ù ÂÕÄÅÔÅ ÏÂÒÁÝÁÔØÓÑ Ë ÄÒÕÇÉÍ ÈÏÓÔÁÍ ÐÏ ÉÍÅÎÉ, Á ÎÅ ÐÏ IP ÁÄÒÅÓÕ, ÐÏÎÁÄÏÂÉÔÓÑ ÔÁËÖÅ ÓÅÒ×ÅÒ DNS É, ×ÏÚÍÏÖÎÏ, ÁÄÒÅÓ ÛÌÀÚÁ (ÅÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ PPP, ÜÔÏ IP ÁÄÒÅÓ ×ÁÛÅÇÏ ÐÒÏ×ÁÊÄÅÒÁ), ÞÔÏÂÙ Ó×ÑÚÁÔØÓÑ Ó ÎÉÍ. åÓÌÉ ×Ù ÈÏÔÉÔÅ ÐÒÏÉÚ×ÏÄÉÔØ ÕÓÔÁÎÏ×ËÕ Ó FTP ÞÅÒÅÚ HTTP ÐÒÏËÓÉ, ÐÏÔÒÅÂÕÅÔÓÑ ÔÁËÖÅ ÁÄÒÅÓ ÐÒÏËÓÉ. åÓÌÉ ×Ù ÎÅ ÚÎÁÅÔÅ ÏÔ×ÅÔÏ× ÎÁ ×ÓÅ ÉÌÉ ÂÏÌØÛÉÎÓÔ×Ï ÜÔÉÈ ×ÏÐÒÏÓÏ×, Ó×ÑÖÉÔÅÓØ Ó ÓÉÓÔÅÍÎÙÍ ÁÄÍÉÎÉÓÔÒÁÔÏÒÏÍ ÉÌÉ ISP ÐÅÒÅÄ ÔÅÍ, ËÁË ÎÁÞÁÔØ ÜÔÏÔ ÔÉÐ ÕÓÔÁÎÏ×ËÉ. åÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ ÍÏÄÅÍ, PPP ÜÔÏ ËÏÎÅÞÎÏ ÐÏÞÔÉ ÅÄÉÎÓÔ×ÅÎÎÙÊ ×ÙÂÏÒ. õÂÅÄÉÔÅÓØ ÞÔÏ Õ ×ÁÓ ÅÓÔØ ÉÎÆÏÒÍÁÃÉÑ Ï ÐÒÏ×ÁÊÄÅÒÅ, ÔÁË ËÁË ÏÎÁ ÐÏÎÁÄÏÂÉÔÓÑ ÎÁ ÄÏ×ÏÌØÎÏ ÒÁÎÎÅÊ ÓÔÁÄÉÉ ÐÒÏÃÅÓÓÁ ÕÓÔÁÎÏ×ËÉ. åÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ PAP ÉÌÉ CHAP ÄÌÑ ÓÏÅÄÉÎÅÎÉÑ Ó ÐÒÏ×ÁÊÄÅÒÏÍ (ÄÒÕÇÉÍÉ ÓÌÏ×ÁÍÉ, ×Ù ÍÏÖÅÔÅ ÓÏÅÄÉÎÑÔØÓÑ Ó ÐÒÏ×ÁÊÄÅÒÏÍ ÉÚ &windows; ÂÅÚ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ÓËÒÉÐÔÁ), ×ÓÅ ÞÔÏ ×ÁÍ ÐÏÎÁÄÏÂÉÔÓÑ ÜÔÏ ××ÅÓÔÉ dial × ÐÒÉÇÌÁÛÅÎÉÉ ppp. éÎÁÞÅ ×ÁÍ ÎÕÖÎÏ ÚÎÁÔØ, ËÁË ÄÏÚ×ÏÎÉÔØÓÑ ÄÏ ÐÒÏ×ÁÊÄÅÒÁ Ó ÐÏÍÏÝØÀ AT ËÏÍÁÎÄ, ÓÐÅÃÉÆÉÞÎÙÈ ÄÌÑ ×ÁÛÅÇÏ ÍÏÄÅÍÁ, ÔÁË ËÁË ÐÒÏÇÒÁÍÍÁ ÄÏÚ×ÏÎÁ PPP ÐÒÅÄÏÓÔÁ×ÌÑÅÔ ÔÏÌØËÏ ÏÞÅÎØ ÐÒÏÓÔÏÊ ÜÍÕÌÑÔÏÒ ÔÅÒÍÉÎÁÌÁ. ïÂÒÁÔÉÔÅÓØ Ë ÒÕËÏ×ÏÄÓÔ×Õ user-ppp É FAQ ÄÌÑ ÐÏÌÕÞÅÎÉÑ ÂÏÌÅÅ ÐÏÄÒÏÂÎÙÈ Ó×ÅÄÅÎÉÊ. åÓÌÉ Õ ×ÁÓ ÐÒÏÂÌÅÍÙ, ÌÏÇÉ ÍÏÇÕÔ ÂÙÔØ ×Ù×ÅÄÅÎÙ ÎÁ ÜËÒÁÎ Ó ÐÏÍÏÝØÀ ËÏÍÁÎÄÙ set log local .... åÓÌÉ ÄÏÓÔÕÐÎÏ ÐÏÓÔÏÑÎÎÏÅ ÓÏÅÄÉÎÅÎÉÅ Ó ÄÒÕÇÏÊ ÍÁÛÉÎÏÊ &os;, ×Ù ÍÏÖÅÔÅ ÔÁËÖÅ ÐÏÄÕÍÁÔØ Ï ÕÓÔÁÎÏ×ËÅ ÞÅÒÅÚ ÐÁÒÁÌÌÅÌØÎÙÊ ÐÏÒÔ laplink ËÁÂÅÌÅÍ. óËÏÒÏÓÔØ ÓÏÅÄÉÎÅÎÉÑ ÞÅÒÅÚ ÐÁÒÁÌÌÅÌØÎÙÊ ÐÏÒÔ ÚÎÁÞÉÔÅÌØÎÏ ×ÙÛÅ, ÞÅÍ ÏÂÙÞÎÏ ×ÏÚÍÏÖÎÏ ÞÅÒÅÚ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÕÀ ÌÉÎÉÀ (ÄÏ 50 ËÂÁÊÔ/Ó), ÜÔÏ ÐÒÉ×ÅÄÅÔ Ë ÕÓËÏÒÅÎÉÀ ÕÓÔÁÎÏ×ËÉ. ðÅÒÅÄ ÕÓÔÁÎÏ×ËÏÊ ÞÅÒÅÚ NFS ÕÓÔÁÎÏ×ËÁ ÓÅÔØ NFS õÓÔÁÎÏ×ËÁ ÞÅÒÅÚ NFS ÏÞÅÎØ ÐÒÏÓÔÁ. ðÒÏÓÔÏ ÓËÏÐÉÒÕÊÔÅ ËÏÍÐÏÎÅÎÔÙ &os;, ËÏÔÏÒÙÅ ×ÁÍ ÎÕÖÎÙ, ÎÁ NFS ÓÅÒ×ÅÒ, Á ÚÁÔÅÍ ÕËÁÖÉÔÅ ÎÁ ÎÅÇÏ ÐÒÉ ×ÙÂÏÒÅ ÉÓÔÏÞÎÉËÁ ÕÓÔÁÎÏ×ËÉ NFS. åÓÌÉ ÜÔÏÔ ÓÅÒ×ÅÒ ÐÏÄÄÅÒÖÉ×ÁÅÔ ÔÏÌØËÏ ÐÒÉ×ÉÌÅÇÉÒÏ×ÁÎÎÙÅ ÐÏÒÔÙ (ÜÔÏ ËÁË ÐÒÁ×ÉÌÏ ÔÁË ÄÌÑ ÒÁÂÏÞÉÈ ÓÔÁÎÃÉÊ Sun), ÐÏÔÒÅÂÕÅÔÓÑ ÕÓÔÁÎÏ×ÉÔØ ÐÁÒÁÍÅÔÒ NFS Secure × ÍÅÎÀ Options ÐÅÒÅÄ ÔÅÍ, ËÁË ÎÁÞÁÔØ ÕÓÔÁÎÏ×ËÕ. åÓÌÉ Õ ×ÁÓ Ethernet ËÁÒÔÁ ÐÌÏÈÏÇÏ ËÁÞÅÓÔ×Á Ó ÎÉÚËÏÊ ÓËÏÒÏÓÔØÀ ÐÅÒÅÄÁÞÉ ÄÁÎÎÙÈ, ×Ù ×ÏÚÍÏÖÎÏ ÚÁÈÏÔÉÔÅ ÐÅÒÅËÌÀÞÉÔØ ÆÌÁÇ NFS Slow × Options. þÔÏÂÙ ÕÓÔÁÎÏ×ËÁ ÐÏ NFS ÒÁÂÏÔÁÌÁ, ÓÅÒ×ÅÒ ÄÏÌÖÅÎ ÐÏÄÄÅÒÖÉ×ÁÔØ ÍÏÎÔÉÒÏ×ÁÎÉÅ ÐÏÄËÁÔÁÌÏÇÏ×, ÎÁÐÒÉÍÅÒ, ÅÓÌÉ ÕÓÔÁÎÏ×ÏÞÎÙÊ ËÁÔÁÌÏÇ ÄÉÓÔÒÉÂÕÔÉ×Á &os; &rel.current; ÎÁÈÏÄÉÔÓÑ ÎÁ: ziggy:/usr/archive/stuff/FreeBSD, ziggy ÄÏÌÖÅÎ ÐÏÚ×ÏÌÑÔØ ÎÅÐÏÓÒÅÄÓÔ×ÅÎÎÏÅ ÍÏÎÔÉÒÏ×ÁÎÉÅ /usr/archive/stuff/FreeBSD, Á ÎÅ ÔÏÌØËÏ /usr ÉÌÉ /usr/archive/stuff. ÷ ÆÁÊÌÅ &os; /etc/exports ÜÔÏ ÕÐÒÁ×ÌÑÅÔÓÑ ÐÁÒÁÍÅÔÒÏÍ . äÒÕÇÉÅ NFS ÓÅÒ×ÅÒÙ ÍÏÇÕÔ ÉÍÅÔØ ÄÒÕÇÉÅ ÓÏÇÌÁÛÅÎÉÑ. åÓÌÉ ×Ù ÐÏÌÕÞÁÅÔÅ ÓÏÏÂÝÅÎÉÑ ÓÅÒ×ÅÒÁ permission denied, ÜÔÏ ÍÏÖÅÔ ÏÚÎÁÞÁÔØ, ÞÔÏ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÁÑ ÏÐÃÉÑ ÎÅ ×ËÌÀÞÅÎÁ.
diff --git a/ru_RU.KOI8-R/books/porters-handbook/Makefile b/ru_RU.KOI8-R/books/porters-handbook/Makefile index c9c08fd9e7..07f993d0af 100644 --- a/ru_RU.KOI8-R/books/porters-handbook/Makefile +++ b/ru_RU.KOI8-R/books/porters-handbook/Makefile @@ -1,35 +1,35 @@ # # The FreeBSD Russian Documentation Project # # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/porters-handbook/Makefile,v 1.7 2003/09/26 02:34:16 andy Exp $ # # Original reivision: 1.4 # # # Build the FreeBSD Porter's Handbook. # -MAINTAINER=andy@FreeBSD.org.ua +MAINTAINER=pluknet@FreeBSD.org DOC?= book FORMATS?= html-split INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= # # SRCS lists the individual XML files that make up the document. Changes # to any of these files will force a rebuild # # XML content SRCS= book.xml # Entities #SRCS+= ../../../en_US.ISO8859-1/books/handbook/authors.ent DOC_PREFIX?= ${.CURDIR}/../../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/share/pgpkeys/markm.key b/share/pgpkeys/markm.key new file mode 100644 index 0000000000..db3247b4a4 --- /dev/null +++ b/share/pgpkeys/markm.key @@ -0,0 +1,206 @@ + + + +uid Mark Murray +uid Mark Murray +uid Mark Murray + +pub 1024D/FB57D793 2000-01-20 + Key fingerprint = 3FB6 3D12 0CF0 611F 0441 CD18 CD0B 8A35 FB57 D793 +uid Mark R V Murray +uid Mark R V Murray +uid Mark R V Murray +uid Mark R V Murray +sub 2048g/EB82BBFC 2000-01-20 +]]> + diff --git a/share/pgpkeys/pgpkeys-developers.xml b/share/pgpkeys/pgpkeys-developers.xml index b60e196926..7d115aaa3a 100644 --- a/share/pgpkeys/pgpkeys-developers.xml +++ b/share/pgpkeys/pgpkeys-developers.xml @@ -1,1997 +1,2002 @@ &a.ariff.email; &pgpkey.ariff; &a.tabthorpe.email; &pgpkey.tabthorpe; &a.eadler.email; &pgpkey.eadler; &a.shaun.email; &pgpkey.shaun; &a.brix.email; &pgpkey.brix; &a.mandree.email; &pgpkey.mandree; &a.will.email; &pgpkey.will; &a.dim.email; &pgpkey.dim; &a.anholt.email; &pgpkey.anholt; &a.mva.email; &pgpkey.mva; &a.araujo.email; &pgpkey.araujo; &a.mat.email; &pgpkey.mat; &a.syuu.email; &pgpkey.syuu; &a.asami.email; &pgpkey.asami; &a.gavin.email; &pgpkey.gavin; &a.jsa.email; &pgpkey.jsa; &a.jadawin.email; &pgpkey.jadawin; &a.timur.email; &pgpkey.timur; &a.gjb.email; &pgpkey.gjb; &a.snb.email; &pgpkey.snb; &a.barner.email; &pgpkey.barner; &a.art.email; &pgpkey.art; &a.tobez.email; &pgpkey.tobez; &a.damien.email; &pgpkey.damien; &a.tdb.email; &pgpkey.tdb; &a.gblach.email; &pgpkey.gblach; &a.mbr.email; &pgpkey.mbr; &a.wblock.email; &pgpkey.wblock; &a.bvs.email; &pgpkey.bvs; &a.novel.email; &pgpkey.novel; &a.garga.email; &pgpkey.garga; &a.alexbl.email; &pgpkey.alexbl; &a.sbz.email; &pgpkey.sbz; &a.ebrandi.email; &pgpkey.ebrandi; &a.harti.email; &pgpkey.harti; &a.obraun.email; &pgpkey.obraun; &a.makc.email; &pgpkey.makc; &a.jmb.email; &pgpkey.jmb; &a.antoine.email; &pgpkey.antoine; &a.db.email; &pgpkey.db; &a.brueffer.email; &pgpkey.brueffer; &a.markus.email; &pgpkey.markus; &a.sbruno.email; &pgpkey.sbruno; &a.oleg.email; &pgpkey.oleg; &a.bushman.email; &pgpkey.bushman; &a.jchandra.email; &pgpkey.jchandra; &a.jcamou.email; &pgpkey.jcamou; &a.acm.email; &pgpkey.acm; &a.gahr.email; &pgpkey.gahr; &a.dchagin.email; &pgpkey.dchagin; &a.perky.email; &pgpkey.perky; &a.jon.email; &pgpkey.jon; &a.jonathan.email; &pgpkey.jonathan; &a.loader.email; &pgpkey.loader; &a.luoqi.email; &pgpkey.luoqi; &a.ache.email; &pgpkey.ache; &a.melifaro.email; &pgpkey.melifaro; &a.seanc.email; &pgpkey.seanc; &a.cjh.email; &pgpkey.cjh; &a.cjc.email; &pgpkey.cjc; &a.marcus.email; &pgpkey.marcus; &a.nik.email; &pgpkey.nik; &a.benjsc.email; &pgpkey.benjsc; &a.tijl.email; &pgpkey.tijl; &a.rakuco.email; &pgpkey.rakuco; &a.alc.email; &pgpkey.alc; &a.brucec.email; &pgpkey.brucec; &a.culot.email; &pgpkey.culot; &a.aaron.email; &pgpkey.aaron; &a.bapt.email; &pgpkey.bapt; &a.ceri.email; &pgpkey.ceri; &a.brd.email; &pgpkey.brd; &a.pjd.email; &pgpkey.pjd; &a.bsd.email; &pgpkey.bsd; &a.carl.email; &pgpkey.carl; &a.vd.email; &pgpkey.vd; &a.rdivacky.email; &pgpkey.rdivacky; &a.danfe.email; &pgpkey.danfe; &a.dd.email; &pgpkey.dd; &a.bdrewery.email; &pgpkey.bdrewery; &a.olivierd.email; &pgpkey.olivierd; &a.bruno.email; &pgpkey.bruno; &a.ale.email; &pgpkey.ale; &a.peadar.email; &pgpkey.peadar; &a.deischen.email; &pgpkey.deischen; &a.josef.email; &pgpkey.josef; &a.lme.email; &pgpkey.lme; &a.ue.email; &pgpkey.ue; &a.ru.email; &pgpkey.ru; &a.le.email; &pgpkey.le; &a.bf.email; &pgpkey.bf; &a.madpilot.email; &pgpkey.madpilot; &a.rafan.email; &pgpkey.rafan; &a.stefanf.email; &pgpkey.stefanf; &a.farrokhi.email; &pgpkey.farrokhi; &a.jedgar.email; &pgpkey.jedgar; &a.feld.email; &pgpkey.feld; &a.green.email; &pgpkey.green; &a.lioux.email; &pgpkey.lioux; &a.mdf.email; &pgpkey.mdf; &a.fanf.email; &pgpkey.fanf; &a.blackend.email; &pgpkey.blackend; &a.petef.email; &pgpkey.petef; &a.decke.email; &pgpkey.decke; &a.billf.email; &pgpkey.billf; &a.avg.email; &pgpkey.avg; &a.beat.email; &pgpkey.beat; &a.danger.email; &pgpkey.danger; &a.sjg.email; &pgpkey.sjg; &a.gibbs.email; &pgpkey.gibbs; &a.pfg.email; &pgpkey.pfg; &a.girgen.email; &pgpkey.girgen; &a.pgollucci.email; &pgpkey.pgollucci; &a.daichi.email; &pgpkey.daichi; &a.mnag.email; &pgpkey.mnag; &a.grehan.email; &pgpkey.grehan; &a.jamie.email; &pgpkey.jamie; &a.wg.email; &pgpkey.wg; &a.bar.email; &pgpkey.bar; &a.jmg.email; &pgpkey.jmg; &a.mjg.email; &pgpkey.mjg; &a.jhale.email; &pgpkey.jhale; &a.dannyboy.email; &pgpkey.dannyboy; &a.dhartmei.email; &pgpkey.dhartmei; &a.ohauer.email; &pgpkey.ohauer; &a.ehaupt.email; &pgpkey.ehaupt; &a.jhay.email; &pgpkey.jhay; &a.sheldonh.email; &pgpkey.sheldonh; &a.mikeh.email; &pgpkey.mikeh; &a.mheinen.email; &pgpkey.mheinen; &a.niels.email; &pgpkey.niels; &a.jh.email; &pgpkey.jh; &a.jgh.email; &pgpkey.jgh; &a.ghelmer.email; &pgpkey.ghelmer; &a.mux.email; &pgpkey.mux; &a.wen.email; &pgpkey.wen; &a.dhn.email; &pgpkey.dhn; &a.jhibbits.email; &pgpkey.jhibbits; &a.pho.email; &pgpkey.pho; &a.mich.email; &pgpkey.mich; &a.sunpoet.email; &pgpkey.sunpoet; &a.lwhsu.email; &pgpkey.lwhsu; &a.foxfair.email; &pgpkey.foxfair; &a.chinsan.email; &pgpkey.chinsan; &a.davide.email; &pgpkey.davide; &a.jkh.email; &pgpkey.jkh; &a.versus.email; &pgpkey.versus; &a.weongyo.email; &pgpkey.weongyo; &a.peterj.email; &pgpkey.peterj; &a.jinmei.email; &pgpkey.jinmei; &a.ahze.email; &pgpkey.ahze; &a.markj.email; &pgpkey.markj; &a.trevor.email; &pgpkey.trevor; &a.tj.email; &pgpkey.tj; &a.kan.email; &pgpkey.kan; &a.bjk.email; &pgpkey.bjk; &a.phk.email; &pgpkey.phk; &a.pluknet.email; &pgpkey.pluknet; &a.cokane.email; &pgpkey.cokane; &a.kato.email; &pgpkey.kato; &a.joe.email; &pgpkey.joe; &a.vkashyap.email; &pgpkey.vkashyap; &a.kris.email; &pgpkey.kris; &a.keramida.email; &pgpkey.keramida; &a.fjoe.email; &pgpkey.fjoe; &a.manolis.email; &pgpkey.manolis; &a.jkim.email; &pgpkey.jkim; &a.zack.email; &pgpkey.zack; &a.jceel.email; &pgpkey.jceel; &a.andreas.email; &pgpkey.andreas; &a.jkois.email; &pgpkey.jkois; &a.sergei.email; &pgpkey.sergei; &a.maxim.email; &pgpkey.maxim; &a.taras.email; &pgpkey.taras; &a.jkoshy.email; &pgpkey.jkoshy; &a.wkoszek.email; &pgpkey.wkoszek; &a.ak.email; &pgpkey.ak; &a.skreuzer.email; &pgpkey.skreuzer; &a.gabor.email; &pgpkey.gabor; &a.anchie.email; &pgpkey.anchie; &a.rik.email; &pgpkey.rik; &a.rushani.email; &pgpkey.rushani; &a.kuriyama.email; &pgpkey.kuriyama; &a.rene.email; &pgpkey.rene; &a.jlaffaye.email; &pgpkey.jlaffaye; &a.clement.email; &pgpkey.clement; &a.mlaier.email; &pgpkey.mlaier; &a.erwin.email; &pgpkey.erwin; &a.martymac.email; &pgpkey.martymac; &a.glarkin.email; &pgpkey.glarkin; &a.laszlof.email; &pgpkey.laszlof; &a.dru.email; &pgpkey.dru; &a.lawrance.email; &pgpkey.lawrance; &a.njl.email; &pgpkey.njl; &a.jlh.email; &pgpkey.jlh; &a.leeym.email; &pgpkey.leeym; &a.sam.email; &pgpkey.sam; &a.jylefort.email; &pgpkey.jylefort; &a.netchild.email; &pgpkey.netchild; &a.ae.email; &pgpkey.ae; &a.lesi.email; &pgpkey.lesi; &a.achim.email; &pgpkey.achim; &a.cel.email; &pgpkey.cel; &a.glewis.email; &pgpkey.glewis; &a.qingli.email; &pgpkey.qingli; &a.delphij.email; &pgpkey.delphij; &a.avatar.email; &pgpkey.avatar; &a.ijliao.email; &pgpkey.ijliao; &a.lulf.email; &pgpkey.lulf; &a.clive.email; &pgpkey.clive; &a.pclin.email; &pgpkey.pclin; &a.yzlin.email; &pgpkey.yzlin; &a.linimon.email; &pgpkey.linimon; &a.arved.email; &pgpkey.arved; &a.dryice.email; &pgpkey.dryice; &a.nemoliu.email; &pgpkey.nemoliu; &a.zml.email; &pgpkey.zml; &a.nox.email; &pgpkey.nox; &a.remko.email; &pgpkey.remko; &a.avl.email; &pgpkey.avl; &a.issyl0.email; &pgpkey.issyl0; &a.scottl.email; &pgpkey.scottl; &a.rmacklem.email; &pgpkey.rmacklem; &a.bmah.email; &pgpkey.bmah; &a.rm.email; &pgpkey.rm; &a.mtm.email; &pgpkey.mtm; &a.dwmalone.email; &pgpkey.dwmalone; &a.amdmi3.email; &pgpkey.amdmi3; &a.marino.email; &pgpkey.marino; &a.kwm.email; &pgpkey.kwm; &a.emaste.email; &pgpkey.emaste; &a.cherry.email; &pgpkey.cherry; &a.matusita.email; &pgpkey.matusita; &a.mm.email; &pgpkey.mm; &a.sem.email; &pgpkey.sem; &a.tmclaugh.email; &pgpkey.tmclaugh; &a.jmelo.email; &pgpkey.jmelo; &a.ken.email; &pgpkey.ken; + + &a.markm.email; + &pgpkey.markm; + + &a.dinoex.email; &pgpkey.dinoex; &a.sanpei.email; &pgpkey.sanpei; &a.rmh.email; &pgpkey.rmh; &a.stephen.email; &pgpkey.stephen; &a.marcel.email; &pgpkey.marcel; &a.kmoore.email; &pgpkey.kmoore; &a.marck.email; &pgpkey.marck; &a.mav.email; &pgpkey.mav; &a.lippe.email; &pgpkey.lippe; &a.rich.email; &pgpkey.rich; &a.knu.email; &pgpkey.knu; &a.tmm.email; &pgpkey.tmm; &a.max.email; &pgpkey.max; &a.maho.email; &pgpkey.maho; &a.yoichi.email; &pgpkey.yoichi; &a.trasz.email; &pgpkey.trasz; &a.dbn.email; &pgpkey.dbn; &a.bland.email; &pgpkey.bland; &a.gnn.email; &pgpkey.gnn; &a.simon.email; &pgpkey.simon; &a.rnoland.email; &pgpkey.rnoland; &a.anders.email; &pgpkey.anders; &a.lofi.email; &pgpkey.lofi; &a.obrien.email; &pgpkey.obrien; &a.olgeni.email; &pgpkey.olgeni; &a.philip.email; &pgpkey.philip; &a.jpaetzel.email; &pgpkey.jpaetzel; &a.pgj.email; &pgpkey.pgj; &a.hiren.email; &pgpkey.hiren; &a.hmp.email; &pgpkey.hmp; &a.fluffy.email; &pgpkey.fluffy; &a.sat.email; &pgpkey.sat; &a.np.email; &pgpkey.np; &a.rpaulo.email; &pgpkey.rpaulo; &a.mp.email; &pgpkey.mp; &a.roam.email; &pgpkey.roam; &a.den.email; &pgpkey.den; &a.csjp.email; &pgpkey.csjp; &a.gerald.email; &pgpkey.gerald; &a.jacula.email; &pgpkey.jacula; &a.jdp.email; &pgpkey.jdp; &a.krion.email; &pgpkey.krion; &a.sepotvin.email; &pgpkey.sepotvin; &a.markp.email; &pgpkey.markp; &a.alepulver.email; &pgpkey.alepulver; &a.thomas.email; &pgpkey.thomas; &a.hq.email; &pgpkey.hq; &a.dfr.email; &pgpkey.dfr; &a.lbr.email; &pgpkey.lbr; &a.crees.email; &pgpkey.crees; &a.rees.email; &pgpkey.rees; &a.bcr.email; &pgpkey.bcr; &a.trhodes.email; &pgpkey.trhodes; &a.benno.email; &pgpkey.benno; &a.beech.email; &pgpkey.beech; &a.matteo.email; &pgpkey.matteo; &a.roberto.email; &pgpkey.roberto; &a.rodrigc.email; &pgpkey.rodrigc; &a.guido.email; &pgpkey.guido; &a.rea.email; &pgpkey.rea; &a.ray.email; &pgpkey.ray; &a.niklas.email; &pgpkey.niklas; &a.bsam.email; &pgpkey.bsam; &a.marks.email; &pgpkey.marks; &a.bschmidt.email; &pgpkey.bschmidt; &a.wosch.email; &pgpkey.wosch; &a.ed.email; &pgpkey.ed; &a.das.email; &pgpkey.das; &a.scheidell.email; &pgpkey.scheidell; &a.schweikh.email; &pgpkey.schweikh; &a.matthew.email; &pgpkey.matthew; &a.tmseck.email; &pgpkey.tmseck; &a.stas.email; &pgpkey.stas; &a.johans.email; &pgpkey.johans; &a.bakul.email; &pgpkey.bakul; &a.gshapiro.email; &pgpkey.gshapiro; &a.arun.email; &pgpkey.arun; &a.wxs.email; &pgpkey.wxs; &a.nork.email; &pgpkey.nork; &a.syrinx.email; &pgpkey.syrinx; &a.vanilla.email; &pgpkey.vanilla; &a.ashish.email; &pgpkey.ashish; &a.bms.email; &pgpkey.bms; &a.demon.email; &pgpkey.demon; &a.jesper.email; &pgpkey.jesper; &a.scop.email; &pgpkey.scop; &a.anray.email; &pgpkey.anray; &a.flo.email; &pgpkey.flo; &a.glebius.email; &pgpkey.glebius; &a.kensmith.email; &pgpkey.kensmith; &a.ben.email; &pgpkey.ben; &a.des.email; &pgpkey.des; &a.sobomax.email; &pgpkey.sobomax; &a.asomers.email; &pgpkey.asomers; &a.brian.email; &pgpkey.brian; &a.sson.email; &pgpkey.sson; &a.nsouch.email; &pgpkey.nsouch; &a.ssouhlal.email; &pgpkey.ssouhlal; &a.loos.email; &pgpkey.loos; &a.uqs.email; &pgpkey.uqs; &a.rink.email; &pgpkey.rink; &a.vsevolod.email; &pgpkey.vsevolod; &a.zi.email; &pgpkey.zi; &a.rrs.email; &pgpkey.rrs; &a.murray.email; &pgpkey.murray; &a.vs.email; &pgpkey.vs; &a.rstone.email; &pgpkey.rstone; &a.xride.email; &pgpkey.xride; &a.marius.email; &pgpkey.marius; &a.cs.email; &pgpkey.cs; &a.clsung.email; &pgpkey.clsung; &a.gsutter.email; &pgpkey.gsutter; &a.metal.email; &pgpkey.metal; &a.ryusuke.email; &pgpkey.ryusuke; &a.garys.email; &pgpkey.garys; &a.nyan.email; &pgpkey.nyan; &a.sahil.email; &pgpkey.sahil; &a.tota.email; &pgpkey.tota; &a.romain.email; &pgpkey.romain; &a.sylvio.email; &pgpkey.sylvio; &a.itetcu.email; &pgpkey.itetcu; &a.mi.email; &pgpkey.mi; &a.gordon.email; &pgpkey.gordon; &a.lth.email; &pgpkey.lth; &a.jase.email; &pgpkey.jase; &a.lx.email; &pgpkey.lx; &a.fabient.email; &pgpkey.fabient; &a.thierry.email; &pgpkey.thierry; &a.thompsa.email; &pgpkey.thompsa; &a.flz.email; &pgpkey.flz; &a.jilles.email; &pgpkey.jilles; &a.ganbold.email; &pgpkey.ganbold; &a.tuexen.email; &pgpkey.tuexen; &a.andrew.email; &pgpkey.andrew; &a.ume.email; &pgpkey.ume; &a.ups.email; &pgpkey.ups; &a.bryanv.email; &pgpkey.bryanv; &a.nectar.email; &pgpkey.nectar; &a.avilla.email; &pgpkey.avilla; &a.nivit.email; &pgpkey.nivit; &a.ivoras.email; &pgpkey.ivoras; &a.stefan.email; &pgpkey.stefan; &a.kaiw.email; &pgpkey.kaiw; &a.adamw.email; &pgpkey.adamw; &a.peter.email; &pgpkey.peter; &a.nwhitehorn.email; &pgpkey.nwhitehorn; &a.miwi.email; &pgpkey.miwi; &a.nate.email; &pgpkey.nate; &a.swills.email; &pgpkey.swills; &a.twinterg.email; &pgpkey.twinterg; &a.wollman.email; &pgpkey.wollman; &a.joerg.email; &pgpkey.joerg; &a.davidxu.email; &pgpkey.davidxu; &a.emax.email; &pgpkey.emax; &a.bz.email; &pgpkey.bz; &a.zeising.email; &pgpkey.zeising; &a.phantom.email; &pgpkey.phantom; &a.sephe.email; &pgpkey.sephe; &a.zont.email; &pgpkey.zont; diff --git a/share/pgpkeys/pgpkeys.ent b/share/pgpkeys/pgpkeys.ent index a8f26eb565..e91e351264 100644 --- a/share/pgpkeys/pgpkeys.ent +++ b/share/pgpkeys/pgpkeys.ent @@ -1,433 +1,434 @@ + diff --git a/share/pgpkeys/tdb.key b/share/pgpkeys/tdb.key index de808285e0..0f4f09dd2b 100644 --- a/share/pgpkeys/tdb.key +++ b/share/pgpkeys/tdb.key @@ -1,152 +1,161 @@ uid Tim Bishop -uid Tim Bishop uid Tim Bishop -sub 4096g/7F886031 2000-10-07 +uid Tim Bishop +sub 4096R/25CEA948 2013-08-07 [expires: 2015-08-07] ]]> diff --git a/share/security/advisories/FreeBSD-SA-13:07.bind.asc b/share/security/advisories/FreeBSD-SA-13:07.bind.asc new file mode 100644 index 0000000000..0f698b237a --- /dev/null +++ b/share/security/advisories/FreeBSD-SA-13:07.bind.asc @@ -0,0 +1,121 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +============================================================================= +FreeBSD-SA-13:07.bind Security Advisory + The FreeBSD Project + +Topic: BIND remote denial of service + +Category: contrib +Module: bind +Announced: 2013-07-26 +Credits: Maxim Shudrak and the HP Zero Day Initiative, ISC +Affects: FreeBSD 8.4-RELEASE and FreeBSD 9.x +Corrected: 2013-07-26 22:53:17 UTC (stable/8, 8.4-STABLE) + 2013-07-26 22:40:17 UTC (releng/8.4, 8.4-RELEASE-p2) + 2013-07-26 22:43:09 UTC (stable/9, 9.2-BETA2) + 2013-07-26 22:40:23 UTC (releng/9.1, 9.1-RELEASE-p5) +CVE Name: CVE-2013-4854 + +For general information regarding FreeBSD Security Advisories, +including descriptions of the fields above, security branches, and the +following sections, please visit . + +I. Background + +BIND 9 is an implementation of the Domain Name System (DNS) protocols. +The named(8) daemon is an Internet Domain Name Server. The libdns +library is a library of DNS protocol support functions. + +II. Problem Description + +Due to a software defect a specially crafted query which includes +malformed rdata, could cause named(8) to crash with an assertion +failure and rejecting the malformed query. This issue affects both +recursive and authoritative-only nameservers. + +III. Impact + +An attacker who can send a specially crafted query could cause named(8) +to crash, resulting in a denial of service. + +IV. Workaround + +No workaround is available, but systems not running the named(8) service +and not using the base system DNS utilities are not affected. + +V. Solution + +Perform one of the following: + +1) Upgrade your vulnerable system to a supported FreeBSD stable or +release / security branch (releng) dated after the correction date. + +2) To update your vulnerable system via a source code patch: + +The following patches have been verified to apply to the applicable +FreeBSD release branches. + +a) Download the relevant patch from the location below, and verify the +detached PGP signature using your PGP utility. + +# fetch http://security.FreeBSD.org/patches/SA-13:07/bind.patch +# fetch http://security.FreeBSD.org/patches/SA-13:07/bind.patch.asc +# gpg --verify bind.patch.asc + +b) Execute the following commands as root: + +# cd /usr/src +# patch < /path/to/patch + +Recompile the operating system using buildworld and installworld as +described in . + +Restart the named daemon, or reboot the system. + +3) To update your vulnerable system via a binary patch: + +Systems running a RELEASE version of FreeBSD on the i386 or amd64 +platforms can be updated via the freebsd-update(8) utility: + +# freebsd-update fetch +# freebsd-update install + +VI. Correction details + +The following list contains the correction revision numbers for each +affected branch. + +Branch/path Revision +- ------------------------------------------------------------------------- +stable/8/ r253696 +releng/8.4/ r253692 +stable/9/ r253695 +releng/9.1/ r253693 +- ------------------------------------------------------------------------- + +To see which files were modified by a particular revision, run the +following command, replacing XXXXXX with the revision number, on a +machine with Subversion installed: + +# svn diff -cXXXXXX --summarize svn://svn.freebsd.org/base + +Or visit the following URL, replacing XXXXXX with the revision number: + + + +VII. References + +https://kb.isc.org/article/AA-01015 + + + +The latest revision of this advisory is available at +http://security.FreeBSD.org/advisories/FreeBSD-SA-13:07.bind.asc +-----BEGIN PGP SIGNATURE----- + +iEYEARECAAYFAlHzPpMACgkQFdaIBMps37Jb2ACdFqaNTTBFiOCuz30MJ5s85UVd +MzoAn2ebCjqULwyEbJaeTlck87NPfQWR +=RFf2 +-----END PGP SIGNATURE----- diff --git a/share/security/advisories/FreeBSD-SA-13:08.nfsserver.asc b/share/security/advisories/FreeBSD-SA-13:08.nfsserver.asc new file mode 100644 index 0000000000..f770400633 --- /dev/null +++ b/share/security/advisories/FreeBSD-SA-13:08.nfsserver.asc @@ -0,0 +1,120 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +============================================================================= +FreeBSD-SA-13:08.nfsserver Security Advisory + The FreeBSD Project + +Topic: Incorrect privilege validation in the NFS server + +Category: core +Module: nfsserver +Announced: 2013-07-26 +Credits: Rick Macklem, Christopher Key, Tim Zingelman +Affects: FreeBSD 8.3, FreeBSD 9.0 and FreeBSD 9.1 +Corrected: 2012-12-28 14:06:49 UTC (stable/9, 9.2-BETA2) + 2013-07-26 22:40:23 UTC (releng/9.1, 9.1-RELEASE-p5) + 2013-01-06 01:11:45 UTC (stable/8, 8.3-STABLE) + 2013-07-26 22:40:29 UTC (releng/8.3, 8.3-RELEASE-p9) +CVE Name: CVE-2013-4851 + +For general information regarding FreeBSD Security Advisories, +including descriptions of the fields above, security branches, and the +following sections, please visit . + +I. Background + +The Network File System (NFS) allows a host to export some or all of its +file systems so that other hosts can access them over the network and mount +them as if they were on local disks. FreeBSD includes both server and client +implementations of NFS. + +II. Problem Description + +The kernel incorrectly uses client supplied credentials instead of the one +configured in exports(5) when filling out the anonymous credential for a +NFS export, when -network or -host restrictions are used at the same time. + +III. Impact + +The remote client may supply privileged credentials (e.g. the root user) +when accessing a file under the NFS share, which will bypass the normal +access checks. + +IV. Workaround + +Systems that do not provide the NFS service are not vulnerable. Systems that +do provide the NFS service are only vulnerable when -mapall or -maproot is +used in combination with network and/or host restrictions. + +V. Solution + +Perform one of the following: + +1) Upgrade your vulnerable system to a supported FreeBSD stable or +release / security branch (releng) dated after the correction date. + +2) To update your vulnerable system via a source code patch: + +The following patches have been verified to apply to the applicable +FreeBSD release branches. + +a) Download the relevant patch from the location below, and verify the +detached PGP signature using your PGP utility. + +# fetch http://security.FreeBSD.org/patches/SA-13:08/nfsserver.patch +# fetch http://security.FreeBSD.org/patches/SA-13:08/nfsserver.patch.asc +# gpg --verify nfsserver.patch.asc + +b) Apply the patch. + +# cd /usr/src +# patch < /path/to/patch + +c) Recompile your kernel as described in + and reboot the +system. + +3) To update your vulnerable system via a binary patch: + +Systems running a RELEASE version of FreeBSD on the i386 or amd64 +platforms can be updated via the freebsd-update(8) utility: + +# freebsd-update fetch +# freebsd-update install + +VI. Correction details + +The following list contains the correction revision numbers for each +affected branch. + +Branch/path Revision +- ------------------------------------------------------------------------- +stable/8/ r245086 +releng/8.3/ r253694 +stable/9/ r244772 +releng/9.1/ r253693 +- ------------------------------------------------------------------------- + +To see which files were modified by a particular revision, run the +following command, replacing XXXXXX with the revision number, on a +machine with Subversion installed: + +# svn diff -cXXXXXX --summarize svn://svn.freebsd.org/base + +Or visit the following URL, replacing XXXXXX with the revision number: + + + +VII. References + + + +The latest revision of this advisory is available at +http://security.FreeBSD.org/advisories/FreeBSD-SA-13:08.nfsserver.asc +-----BEGIN PGP SIGNATURE----- + +iEYEARECAAYFAlHzPrkACgkQFdaIBMps37I9YACfSu4orRhgOhol8vacW9kF3ZGP +jtAAn0t2i14CMo1MT5MztI6RWX3hnUWZ +=xjf/ +-----END PGP SIGNATURE----- diff --git a/share/security/patches/SA-13:07/bind.patch b/share/security/patches/SA-13:07/bind.patch new file mode 100644 index 0000000000..f9aa87ece4 --- /dev/null +++ b/share/security/patches/SA-13:07/bind.patch @@ -0,0 +1,13 @@ +Index: contrib/bind9/lib/dns/rdata/generic/keydata_65533.c +=================================================================== +--- contrib/bind9/lib/dns/rdata/generic/keydata_65533.c (revision 253461) ++++ contrib/bind9/lib/dns/rdata/generic/keydata_65533.c (working copy) +@@ -176,7 +176,7 @@ + UNUSED(options); + + isc_buffer_activeregion(source, &sr); +- if (sr.length < 4) ++ if (sr.length < 16) + return (ISC_R_UNEXPECTEDEND); + + isc_buffer_forward(source, sr.length); diff --git a/share/security/patches/SA-13:07/bind.patch.asc b/share/security/patches/SA-13:07/bind.patch.asc new file mode 100644 index 0000000000..1a149567f0 --- /dev/null +++ b/share/security/patches/SA-13:07/bind.patch.asc @@ -0,0 +1,6 @@ +-----BEGIN PGP SIGNATURE----- + +iEYEABECAAYFAlHzPqUACgkQFdaIBMps37IIPgCgioXGAf1PRyZ0mSeCktSzxFeY +l+4An0YlRzZ8Xbt+CgxwIwyvGjLYpy9q +=tbCD +-----END PGP SIGNATURE----- diff --git a/share/security/patches/SA-13:08/nfsserver.patch b/share/security/patches/SA-13:08/nfsserver.patch new file mode 100644 index 0000000000..be91c0bdda --- /dev/null +++ b/share/security/patches/SA-13:08/nfsserver.patch @@ -0,0 +1,13 @@ +Index: sys/kern/vfs_export.c +=================================================================== +--- sys/kern/vfs_export.c (revision 253367) ++++ sys/kern/vfs_export.c (working copy) +@@ -208,7 +208,7 @@ + np->netc_anon = crget(); + np->netc_anon->cr_uid = argp->ex_anon.cr_uid; + crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, +- np->netc_anon->cr_groups); ++ argp->ex_anon.cr_groups); + np->netc_anon->cr_prison = &prison0; + prison_hold(np->netc_anon->cr_prison); + np->netc_numsecflavors = argp->ex_numsecflavors; diff --git a/share/security/patches/SA-13:08/nfsserver.patch.asc b/share/security/patches/SA-13:08/nfsserver.patch.asc new file mode 100644 index 0000000000..d33a26ea83 --- /dev/null +++ b/share/security/patches/SA-13:08/nfsserver.patch.asc @@ -0,0 +1,22 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +Index: sys/kern/vfs_export.c +=================================================================== +- --- sys/kern/vfs_export.c (revision 253367) ++++ sys/kern/vfs_export.c (working copy) +@@ -208,7 +208,7 @@ + np->netc_anon = crget(); + np->netc_anon->cr_uid = argp->ex_anon.cr_uid; + crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, +- - np->netc_anon->cr_groups); ++ argp->ex_anon.cr_groups); + np->netc_anon->cr_prison = &prison0; + prison_hold(np->netc_anon->cr_prison); + np->netc_numsecflavors = argp->ex_numsecflavors; +-----BEGIN PGP SIGNATURE----- + +iEYEARECAAYFAlHzPsQACgkQFdaIBMps37J36gCgglvXt5i1cg/+gvs4mHyJ+mrj +tesAn1Qli/x2FjqbQ++FPs8qF2Sc7Rxs +=kdhf +-----END PGP SIGNATURE----- diff --git a/share/xml/advisories.xml b/share/xml/advisories.xml index 8671ac9e1a..6ff2b8c55d 100644 --- a/share/xml/advisories.xml +++ b/share/xml/advisories.xml @@ -1,3512 +1,3529 @@ $FreeBSD$ 2013 + + 7 + + + 26 + + + FreeBSD-SA-13:08.nfsserver + + + + FreeBSD-SA-13:07.bind + + + + + 6 18 FreeBSD-SA-13:06.mmap 4 29 FreeBSD-SA-13:05.nfsserver 2 FreeBSD-SA-13:04.bind FreeBSD-SA-13:03.openssl 2 19 FreeBSD-SA-13:02.libc FreeBSD-SA-13:01.bind 2012 11 22 FreeBSD-SA-12:08.linux FreeBSD-SA-12:07.hostapd FreeBSD-SA-12:06.bind 8 6 FreeBSD-SA-12:05.bind 6 12 FreeBSD-SA-12:04.sysret FreeBSD-SA-12:03.bind 5 30 FreeBSD-SA-12:02.crypt 30 FreeBSD-SA-12:01.openssl 2011 12 23 FreeBSD-SA-11:10.pam FreeBSD-SA-11:09.pam_ssh FreeBSD-SA-11:08.telnetd FreeBSD-SA-11:07.chroot FreeBSD-SA-11:06.bind 9 28 FreeBSD-SA-11:05.unix FreeBSD-SA-11:04.compress FreeBSD-SA-11:03.bind 5 28 FreeBSD-SA-11:02.bind 4 20 FreeBSD-SA-11:01.mountd 2010 11 29 FreeBSD-SA-10:10.openssl 10 FreeBSD-SA-10:09.pseudofs 9 20 FreeBSD-SA-10:08.bzip2 7 13 FreeBSD-SA-10:07.mbuf 5 27 FreeBSD-SA-10:06.nfsclient FreeBSD-SA-10:05.opie FreeBSD-SA-10:04.jail 1 6 FreeBSD-SA-10:03.zfs FreeBSD-SA-10:02.ntpd FreeBSD-SA-10:01.bind 2009 12 3 FreeBSD-SA-09:17.freebsd-update FreeBSD-SA-09:16.rtld FreeBSD-SA-09:15.ssl 10 2 FreeBSD-SA-09:14.devfs FreeBSD-SA-09:13.pipe 7 29 FreeBSD-SA-09:12.bind 6 10 FreeBSD-SA-09:11.ntpd FreeBSD-SA-09:10.ipv6 FreeBSD-SA-09:09.pipe 4 22 FreeBSD-SA-09:08.openssl FreeBSD-SA-09:07.libc 3 23 FreeBSD-SA-09:06.ktimer 2 16 FreeBSD-SA-09:05.telnetd 1 13 FreeBSD-SA-09:04.bind FreeBSD-SA-09:03.ntpd 7 FreeBSD-SA-09:02.openssl FreeBSD-SA-09:01.lukemftpd 2008 12 23 FreeBSD-SA-08:13.protosw FreeBSD-SA-08:12.ftpd 11 24 FreeBSD-SA-08:11.arc4random 10 2 FreeBSD-SA-08:10.nd6 9 3 FreeBSD-SA-08:09.icmp6 FreeBSD-SA-08:08.nmount FreeBSD-SA-08:07.amd64 7 13 FreeBSD-SA-08:06.bind 4 17 FreeBSD-SA-08:05.openssh 2 14 FreeBSD-SA-08:04.ipsec FreeBSD-SA-08:03.sendfile 1 18 FreeBSD 6.3-RELEASE 14 FreeBSD-SA-08:02.libc FreeBSD-SA-08:01.pty 2007 11 29 FreeBSD-SA-07:10.gtar FreeBSD-SA-07:09.random 10 3 FreeBSD-SA-07:08.openssl 8 1 FreeBSD-SA-07:07.bind FreeBSD-SA-07:06.tcpdump 7 12 FreeBSD-SA-07:05.libarchive 5 23 FreeBSD-SA-07:04.file 4 26 FreeBSD-SA-07:03.ipv6 2 9 FreeBSD-SA-07:02.bind 1 15 FreeBSD 6.2-RELEASE 11 FreeBSD-SA-07:01.jail 2006 12 6 FreeBSD-SA-06:26.gtar FreeBSD-SA-06:25.kmem 11 8 FreeBSD-SA-06:24.libarchive 9 30 FreeBSD-SA-06:22.openssh 28 FreeBSD-SA-06:23.openssl 19 FreeBSD-SA-06:21.gzip 6 FreeBSD-SA-06:20.bind FreeBSD-SA-06:19.openssl 8 23 FreeBSD-SA-06:18.ppp 6 14 FreeBSD-SA-06:17.sendmail 5 31 FreeBSD-SA-06:16.smbfs FreeBSD-SA-06:15.ypserv 25 FreeBSD 5.5-RELEASE 9 FreeBSD 6.1-RELEASE 4 19 FreeBSD-SA-06:14.fpu 3 22 FreeBSD-SA-06:13.sendmail FreeBSD-SA-06:12.opie FreeBSD-SA-06:11.ipsec 1 FreeBSD-SA-06:10.nfs FreeBSD-SA-06:09.openssh 2 1 FreeBSD-SA-06:08.sack 1 25 FreeBSD-SA-06:07.pf FreeBSD-SA-06:06.kmem 18 FreeBSD-SA-06:05.80211 11 FreeBSD-SA-06:04.ipfw FreeBSD-SA-06:03.cpio FreeBSD-SA-06:02.ee FreeBSD-SA-06:01.texindex 2005 11 4 FreeBSD 6.0-RELEASE 10 11 FreeBSD-SA-05:21.openssl 9 7 FreeBSD-SA-05:20.cvsbug 7 27 FreeBSD-SA-05:19.ipsec FreeBSD-SA-05:18.zlib 20 FreeBSD-SA-05:17.devfs 6 FreeBSD-SA-05:16.zlib 6 29 FreeBSD-SA-05:15.tcp FreeBSD-SA-05:14.bzip2 FreeBSD-SA-05:13.ipfw 9 FreeBSD-SA-05:12.bind9 FreeBSD-SA-05:11.gzip FreeBSD-SA-05:10.tcpdump 5 13 FreeBSD-SA-05:09.htt 9 FreeBSD 5.4-RELEASE 6 FreeBSD-SA-05:08.kmem FreeBSD-SA-05:07.ldt FreeBSD-SA-05:06.iir 4 22 FreeBSD-SA-05:05.cvs 15 FreeBSD-SA-05:04.ifconf 6 FreeBSD-SA-05:03.amd64 4 FreeBSD-SA-05:02.sendfile 3 28 FreeBSD-SA-05:01.telnet 1 25 FreeBSD 4.11-RELEASE 2004 12 1 FreeBSD-SA-04:17.procfs 11 18 FreeBSD-SA-04:16.fetch 6 FreeBSD 5.3-RELEASE 10 4 FreeBSD-SA-04:15.syscons 9 19 FreeBSD-SA-04:14.cvs 6 30 FreeBSD-SA-04:13.linux 7 FreeBSD-SA-04:12.jailroute 5 27 FreeBSD 4.10-RELEASE 19 FreeBSD-SA-04:11.msync 19 FreeBSD-SA-04:10.cvs 5 FreeBSD-SA-04:09.kadmind FreeBSD-SA-04:08.heimdal 4 15 FreeBSD-SA-04:07.cvs 3 29 FreeBSD-SA-04:06.ipv6 17 FreeBSD-SA-04:05.openssl 2 FreeBSD-SA-04:04.tcp 2 26 FreeBSD 5.2.1-RELEASE 25 FreeBSD-SA-04:03.jail 05 FreeBSD-SA-04:02.shmat 1 30 FreeBSD-SA-04:01.mksnap_ffs 12 FreeBSD 5.2-RELEASE 2003 11 28 FreeBSD-SA-03:19.bind 10 27 FreeBSD 4.9-RELEASE 5 FreeBSD-SA-03:15.openssh 3 FreeBSD-SA-03:18.openssl FreeBSD-SA-03:17.procfs 2 FreeBSD-SA-03:16.filedesc 9 23 FreeBSD-SA-03:14.arp 17 FreeBSD-SA-03:13.sendmail 16 FreeBSD-SA-03:12.openssh 8 26 FreeBSD-SA-03:11.sendmail http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1170 10 FreeBSD-SA-03:10.ibcs2 http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1164 FreeBSD-SA-03:09.signal http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1163 3 FreeBSD-SA-03:08.realpath http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1158 6 9 FreeBSD 5.1-RELEASE 4 8 FreeBSD-SN-03:02 7 FreeBSD-SN-03:01 3 FreeBSD 4.8-RELEASE 3 30 FreeBSD-SA-03:07.sendmail http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1122 21 FreeBSD-SA-03:06.openssl http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1118 20 FreeBSD-SA-03:05.xdr http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1117 3 FreeBSD-SA-03:04.sendmail http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1112 2 24 FreeBSD-SA-03:03.syncookies http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1106 FreeBSD-SA-03:02.openssl http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1105 04 FreeBSD-SA-03:01.cvs http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1100 1 19 FreeBSD 5.0-RELEASE 07 FreeBSD-SA-02:44.filedesc http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1090 2002 11 15 FreeBSD-SA-02:43.bind http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1084 FreeBSD-SA-02:41.smrsh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1082 12 FreeBSD-SA-02:42.resolv http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1083 FreeBSD-SA-02:40.kadmind http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1081 10 10 FreeBSD 4.7-RELEASE FreeBSD-SN-02:06 9 16 FreeBSD-SA-02:39.libkvm http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1051 8 28 FreeBSD-SN-02:05 19 FreeBSD-SA-02:38.signed-error http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1041 15 FreeBSD 4.6.2-RELEASE 05 FreeBSD-SA-02:37.kqueue http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1033 FreeBSD-SA-02:36.nfs http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1032 FreeBSD-SA-02:35.ffs http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1031 FreeBSD-SA-02:33.openssl http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1023 01 FreeBSD-SA-02:34.rpc http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1024 7 31 FreeBSD-SA-02:32.pppd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1022 15 FreeBSD-SA-02:31.openssh 12 FreeBSD-SA-02:30.ktrace FreeBSD-SA-02:29.tcpdump 6 26 FreeBSD-SA-02:28.resolv 19 FreeBSD-SN-02:04 15 FreeBSD 4.6-RELEASE 5 29 FreeBSD-SA-02:27.rc FreeBSD-SA-02:26.accept 28 FreeBSD-SN-02:03 20 FreeBSD-SA-02:25.bzip2 FreeBSD-SA-02:24.k5su 13 FreeBSD-SN-02:02 4 22 FreeBSD-SA-02:23.stdio http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1021 18 FreeBSD-SA-02:22.mmap 17 FreeBSD-SA-02:21.tcpip http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/980 16 FreeBSD-SA-02:20.syncache http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/979 3 30 FreeBSD-SN-02:01 26 FreeBSD-SA-02:19.squid http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/960 18 FreeBSD-SA-02:18.zlib http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/978 12 FreeBSD-SA-02:17.mod_frontpage http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/954 FreeBSD-SA-02:16.netscape http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/953 FreeBSD-SA-02:15.cyrus-sasl http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/952 FreeBSD-SA-02:14.pam-pgsql http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/951 07 FreeBSD-SA-02:13.openssh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/945 2 21 FreeBSD-SA-02:12.squid http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/938 12 FreeBSD-SA-02:11.snmp http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/936 06 FreeBSD-SA-02:10.rsync http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/928 FreeBSD-SA-02:09.fstatfs http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/927 1 29 FreeBSD 4.5-RELEASE 24 FreeBSD-SA-02:08.exec http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/923 18 FreeBSD-SA-02:07.k5su http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/912 16 FreeBSD-SA-02:06.sudo http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/909 04 FreeBSD-SA-02:05.pine http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/894 FreeBSD-SA-02:04.mutt http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/893 FreeBSD-SA-02:03.mod_auth_pgsql http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/892 FreeBSD-SA-02:02.pw http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/891 FreeBSD-SA-02:01.pkg_add http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/898 2001 12 04 FreeBSD-SA-01:64.wu-ftpd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/870 02 FreeBSD-SA-01:63.openssh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/871 10 08 FreeBSD-SA-01:62.uucp FreeBSD-SA-01:61.squid 9 24 FreeBSD-SA-01:60.procmail 20 FreeBSD 4.4-RELEASE 04 FreeBSD-SA-01:59.rmuser 8 30 FreeBSD-SA-01:58.lpd 27 FreeBSD-SA-01:57.sendmail 23 FreeBSD-SA-01:56.tcp_wrappers 21 FreeBSD-SA-01:55.procfs 20 FreeBSD-SA-01:54.ports-telnetd 17 FreeBSD-SA-01:53.ipfw 06 FreeBSD-SA-01:52.fragment 7 30 FreeBSD-SA-01:51.openssl 27 FreeBSD-SA-01:50.windowmaker 23 FreeBSD-SA-01:49.telnetd 17 FreeBSD-SA-01:48.tcpdump 10 FreeBSD-SA-01:47.xinetd FreeBSD-SA-01:46.w3m FreeBSD-SA-01:45.samba FreeBSD-SA-01:44.gnupg FreeBSD-SA-01:43.fetchmail FreeBSD-SA-01:42.signal 09 FreeBSD-SA-01:41.hanterm 6 04 FreeBSD-SA-01:40.fts 5 02 FreeBSD-SA-01:39.tcp-isn 4 23 FreeBSD-SA-01:38.sudo FreeBSD-SA-01:37.slrn FreeBSD-SA-01:36.samba FreeBSD-SA-01:35.licq FreeBSD-SA-01:34.hylafax 20 FreeBSD 4.3-RELEASE 17 FreeBSD-SA-01:33.ftpd-glob 16 FreeBSD-SA-01:32.ipfilter 06 FreeBSD-SA-01:31.ntpd 3 22 FreeBSD-SA-01:30.ufs-ext2fs http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/738 12 FreeBSD-SA-01:29.rwhod http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/732 FreeBSD-SA-01:28.timed http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/731 FreeBSD-SA-01:27.cfengine http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/730 FreeBSD-SA-01:26.interbase http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/729 FreeBSD-SA-01:23.icecast http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/728 2 14 FreeBSD-SA-01:25.kerberosIV http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/716 12 FreeBSD-SA-01:24.ssh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/715 07 FreeBSD-SA-01:22.dc20ctrl http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/714 FreeBSD-SA-01:21.ja-elvis http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/713 FreeBSD-SA-01:20.mars_nwe http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/712 FreeBSD-SA-01:19.ja-klock http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/707 1 31 FreeBSD-SA-01:18.bind http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/706 29 FreeBSD-SA-01:17.exmh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/705 FreeBSD-SA-01:16.mysql http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/704 FreeBSD-SA-01:15.tinyproxy http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/703 FreeBSD-SA-01:14.micq http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/702 FreeBSD-SA-01:13.sort http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/701 FreeBSD-SA-01:12.periodic http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/700 FreeBSD-SA-01:11.inetd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/699 23 FreeBSD-SA-01:10.bind http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/698 FreeBSD-SA-01:09.crontab http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/697 FreeBSD-SA-01:08.ipfw http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/696 FreeBSD-SA-01:07.xfree86 15 FreeBSD-SA-01:06.zope http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/669 FreeBSD-SA-01:05.stunnel http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/668 FreeBSD-SA-01:04.joe http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/667 FreeBSD-SA-01:03.bash1 http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/666 FreeBSD-SA-01:02.syslog-ng http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/665 FreeBSD-SA-01:01.openssh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/664 2000 12 20 FreeBSD-SA-00:81.ethereal http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/651 FreeBSD-SA-00:80.halflifeserver http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/650 FreeBSD-SA-00:79.oops http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/649 FreeBSD-SA-00:78.bitchx http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/648 18 FreeBSD-SA-00:77.procfs http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/647 11 20 FreeBSD-SA-00:76.tcsh-csh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/628 FreeBSD-SA-00:75.php http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/627 FreeBSD-SA-00:74.gaim FreeBSD-SA-00:73.thttpd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/626 FreeBSD-SA-00:72.curl http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/625 FreeBSD-SA-00:71.mgetty http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/624 14 FreeBSD-SA-00:70.ppp-nat http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/623 FreeBSD-SA-00:69.telnetd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/622 13 FreeBSD-SA-00:68.ncurses http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/621 10 FreeBSD-SA-00:67.gnupg http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/620 06 FreeBSD-SA-00:66.netscape http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/619 FreeBSD-SA-00:65.xfce http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/618 FreeBSD-SA-00:64.global http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/617 01 FreeBSD-SA-00:63.getnameinfo http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/589 FreeBSD-SA-00:62.top http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/616 10 31 FreeBSD-SA-00:61.tcpdump http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/615 30 FreeBSD-SA-00:60.boa http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/586 FreeBSD-SA-00:59.pine http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/585 FreeBSD-SA-00:58.chpass http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/584 13 FreeBSD-SA-00:57.muh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/570 FreeBSD-SA-00:56.lprng http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/569 FreeBSD-SA-00:55.xpdf http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/568 FreeBSD-SA-00:54.fingerd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/567 06 FreeBSD-SA-00:52.tcp-iss http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/561 9 27 FreeBSD-SA-00:53.catopen http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/562 13 FreeBSD-SA-00:51.mailman http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/550 FreeBSD-SA-00:50.listmanager http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/549 FreeBSD-SA-00:49.eject http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/548 FreeBSD-SA-00:48.xchat http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/547 FreeBSD-SA-00:47.pine http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/546 FreeBSD-SA-00:46.screen http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/545 8 31 FreeBSD-SA-00:45.esound http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/526 28 FreeBSD-SA-00:44.xlock http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/523 FreeBSD-SA-00:43.brouted http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/520 FreeBSD-SA-00:42.linux http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/530 FreeBSD-SA-00:41.elf http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/527 FreeBSD-SA-00:40.mopd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/521 FreeBSD-SA-00:39.netscape http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/528 14 FreeBSD-SA-00:38.zope http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/525 FreeBSD-SA-00:37.cvsweb http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/524 FreeBSD-SA-00:36.ntop http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/531 FreeBSD-SA-00:35.proftpd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/522 FreeBSD-SA-00:34.dhclient http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/529 7 12 FreeBSD-SA-00:33.kerberosIV http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/488 05 FreeBSD-SA-00:32.bitchx http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/487 FreeBSD-SA-00:31.canna http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/486 FreeBSD-SA-00:30.openssh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/485 FreeBSD-SA-00:29.wu-ftpd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/489 FreeBSD-SA-00:28.majordomo http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/484 FreeBSD-SA-00:27.XFree86-4 http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/483 FreeBSD-SA-00:26.popper http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/482 FreeBSD-SA-00:24.libedit http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/481 6 19 FreeBSD-SA-00:23.ip-options http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/480 12 FreeBSD-SA-00:25.alpha-random http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/473 07 FreeBSD-SA-00:22.apsfilter http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/461 FreeBSD-SA-00:21.ssh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/459 5 26 FreeBSD-SA-00:20.krb5 http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/452 23 FreeBSD-SA-00:19.semconfig http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/451 09 FreeBSD-SA-00:18.gnapster.knapster http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/429 FreeBSD-SA-00:17.libmytinfo http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/442 FreeBSD-SA-00:16.golddig http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/439 4 24 FreeBSD-SA-00:15.imap-uw http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/438 FreeBSD-SA-00:14.imap-uw http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/441 19 FreeBSD-SA-00:13.generic-nqs http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/437 10 FreeBSD-SA-00:12.healthd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/436 FreeBSD-SA-00:11.ircii http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/440 3 15 FreeBSD-SA-00:10.orville-write http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/408 FreeBSD-SA-00:09.mtr http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/408 FreeBSD-SA-00:08.lynx http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/407 FreeBSD-SA-00:07.mh http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/411 01 FreeBSD-SA-00:06.htdig http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/403 2 28 FreeBSD-SA-00:05.mysql http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/402 19 FreeBSD-SA-00:04.delegate http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/392 FreeBSD-SA-00:03.asmon http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/391 1 24 FreeBSD-SA-00:02.procfs http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/380 19 FreeBSD-SA-00:01.make 1999 9 16 FreeBSD-SA-99:06.amd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/318 15 FreeBSD-SA-99:05.fts http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/313 FreeBSD-SA-99:04.core http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/312 05 FreeBSD-SA-99:03.ftpd http://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/311 04 FreeBSD-SA-99:02.profil FreeBSD-SA-99:01.chflags 1998 11 04 FreeBSD-SA-98:08.fragment 10 13 FreeBSD-SA-98:07.rst 6 10 FreeBSD-SA-98:06.icmp 04 FreeBSD-SA-98:05.nfs 02 FreeBSD-SA-98:04.mmap 5 14 FreeBSD-SA-98:03.ttcp 3 12 FreeBSD-SA-98:02.mmap 1997 12 09 FreeBSD-SA-97:06.f00f 01 FreeBSD-SA-98:01.land 10 29 FreeBSD-SA-97:05.open 8 19 FreeBSD-SA-97:04.procfs 4 07 FreeBSD-SA-97:03.sysinstall 3 26 FreeBSD-SA-97:02.lpd 2 05 FreeBSD-SA-97:01.setlocale 1 18 FreeBSD-SA-96:21.talkd 1996 12 16 FreeBSD-SA-96:20.stack-overflow 10 FreeBSD-SA-96:19.modstat 11 25 FreeBSD-SA-96:18.lpr 7 16 FreeBSD-SA-96:17.rzsz 12 FreeBSD-SA-96:16.rdist 04 FreeBSD-SA-96:15.ppp 6 28 FreeBSD-SA-96:12.perl 24 FreeBSD-SA-96:14.ipfw 05 FreeBSD-SA-96:13.comsat 5 21 FreeBSD-SA-96:11.man 17 FreeBSD-SA-96:10.mount_union FreeBSD-SA-96:09.vfsload 4 22 FreeBSD-SA-96:02.apache 21 FreeBSD-SA-96:08.syslog FreeBSD-SA-96:01.sliplogin 20 FreeBSD-SA-96:03.sendmail-suggestion diff --git a/share/xml/authors.ent b/share/xml/authors.ent index 3cddfc44cd..c467e97c0b 100644 --- a/share/xml/authors.ent +++ b/share/xml/authors.ent @@ -1,2271 +1,2271 @@ aaron@FreeBSD.org"> abial@FreeBSD.org"> ache@FreeBSD.org"> achim@FreeBSD.org"> acm@FreeBSD.org"> adam@FreeBSD.org"> adamw@FreeBSD.org"> ade@FreeBSD.org"> adrian@FreeBSD.org"> ae@FreeBSD.org"> ahasty@FreeBSD.org"> ahd@FreeBSD.org"> ahze@FreeBSD.org"> ak@FreeBSD.org"> akiyama@FreeBSD.org"> alane@FreeBSD.org"> alc@FreeBSD.org"> ale@FreeBSD.org"> alepulver@FreeBSD.org"> alex@FreeBSD.org"> alexbl@FreeBSD.org"> alfred@FreeBSD.org"> alm@FreeBSD.org"> am@FreeBSD.org"> ambrisko@FreeBSD.org"> amdmi3@FreeBSD.org"> amorita@FreeBSD.org"> amurai@FreeBSD.org"> anchie@FreeBSD.org"> anders@FreeBSD.org"> andre@FreeBSD.org"> andreas@FreeBSD.org"> andreast@FreeBSD.org"> andrew@FreeBSD.org"> andy@FreeBSD.org"> anholt@FreeBSD.org"> anray@FreeBSD.org"> antoine@FreeBSD.org"> araujo@FreeBSD.org"> archie@FreeBSD.org"> ariff@FreeBSD.org"> arr@FreeBSD.org"> art@FreeBSD.org"> arun@FreeBSD.org"> arundel@FreeBSD.org"> arved@FreeBSD.org"> asami@FreeBSD.org"> ashish@FreeBSD.org"> asmodai@FreeBSD.org"> asomers@FreeBSD.org"> assar@FreeBSD.org"> ats@FreeBSD.org"> attilio@FreeBSD.org"> avatar@FreeBSD.org"> avg@FreeBSD.org"> avilla@FreeBSD.org"> avl@FreeBSD.org"> awebster@pubnix.net"> az@FreeBSD.org"> babb@FreeBSD.org"> babkin@FreeBSD.org"> bakul@FreeBSD.org"> bapt@FreeBSD.org"> bar@FreeBSD.org"> barner@FreeBSD.org"> bbraun@FreeBSD.org"> bcr@FreeBSD.org"> bde@FreeBSD.org"> bdrewery@FreeBSD.org"> bean@FreeBSD.org"> beat@FreeBSD.org"> beech@FreeBSD.org"> ben@FreeBSD.org"> benjsc@FreeBSD.org"> benl@FreeBSD.org"> benno@FreeBSD.org"> bf@FreeBSD.org"> bgray@FreeBSD.org"> bhaga@FreeBSD.org"> billf@FreeBSD.org"> bjk@FreeBSD.org"> bk@FreeBSD.org"> blackend@FreeBSD.org"> bland@FreeBSD.org"> bmah@FreeBSD.org"> bmilekic@FreeBSD.org"> bms@FreeBSD.org"> bp@FreeBSD.org"> brandon@FreeBSD.org"> brd@FreeBSD.org"> brian@FreeBSD.org"> brix@FreeBSD.org"> brooks@FreeBSD.org"> brucec@FreeBSD.org"> brueffer@FreeBSD.org"> bruno@FreeBSD.org"> bryanv@FreeBSD.org"> bsam@FreeBSD.org"> bschmidt@FreeBSD.org"> bsd@FreeBSD.org"> bushman@FreeBSD.org"> bvs@FreeBSD.org"> bz@FreeBSD.org"> carl@FreeBSD.org"> carvay@FreeBSD.org"> cawimm@FreeBSD.org"> cbzimmer@FreeBSD.org"> cel@FreeBSD.org"> ceri@FreeBSD.org"> cg@FreeBSD.org"> charnier@FreeBSD.org"> chern@FreeBSD.org"> cherry@FreeBSD.org"> chinsan@FreeBSD.org"> chm@FreeBSD.org"> chmr@FreeBSD.org"> chris@FreeBSD.org"> chuckr@FreeBSD.org"> cjc@FreeBSD.org"> cjh@FreeBSD.org"> clement@FreeBSD.org"> clive@FreeBSD.org"> clsung@FreeBSD.org"> cognet@FreeBSD.org"> cokane@FreeBSD.org"> conklin@FreeBSD.org"> cp@FreeBSD.org"> cperciva@FreeBSD.org"> cpiazza@FreeBSD.org"> cracauer@FreeBSD.org"> crees@FreeBSD.org"> cs@FreeBSD.org"> csgr@FreeBSD.org"> cshumway@FreeBSD.org"> csjp@FreeBSD.org"> culot@FreeBSD.org"> cwt@FreeBSD.org"> cy@FreeBSD.org"> daichi@FreeBSD.org"> damien@FreeBSD.org"> dan@FreeBSD.org"> danfe@FreeBSD.org"> danger@FreeBSD.org"> danny@FreeBSD.org"> dannyboy@FreeBSD.org"> darrenr@FreeBSD.org"> das@FreeBSD.org"> davidc@FreeBSD.org"> davidch@FreeBSD.org"> davide@FreeBSD.org"> davidn@FreeBSD.org"> davidxu@FreeBSD.org"> db@FreeBSD.org"> dbaker@FreeBSD.org"> dbn@FreeBSD.org"> dburr@FreeBSD.org"> dchagin@FreeBSD.org"> dcs@FreeBSD.org"> dd@FreeBSD.org"> dds@FreeBSD.org"> deb@FreeBSD.org"> dec@FreeBSD.org"> decke@FreeBSD.org"> deischen@FreeBSD.org"> delphij@FreeBSD.org"> demon@FreeBSD.org"> den@FreeBSD.org"> des@FreeBSD.org"> dfr@FreeBSD.org"> dg@FreeBSD.org"> dhartmei@FreeBSD.org"> dhn@FreeBSD.org"> dhw@FreeBSD.org"> dick@FreeBSD.org"> dillon@FreeBSD.org"> dim@FreeBSD.org"> dima@FreeBSD.org"> dinoex@FreeBSD.org"> dirk@FreeBSD.org"> dmarion@FreeBSD.org"> dmlb@FreeBSD.org"> don@FreeBSD.org"> dougb@FreeBSD.org"> dru@FreeBSD.org"> dryice@FreeBSD.org"> ds@FreeBSD.org"> dt@FreeBSD.org"> dteske@FreeBSD.org"> dufault@FreeBSD.org"> dumbbell@FreeBSD.org"> dutchdaemon@FreeBSD.org"> dvl@FreeBSD.org"> dwcjr@FreeBSD.org"> dwhite@FreeBSD.org"> dwmalone@FreeBSD.org"> dyson@FreeBSD.org"> eadler@FreeBSD.org"> ebrandi@FreeBSD.org"> ed@FreeBSD.org"> edwin@FreeBSD.org"> ehaupt@FreeBSD.org"> eik@FreeBSD.org"> eivind@FreeBSD.org"> ejc@FreeBSD.org"> emaste@FreeBSD.org"> emax@FreeBSD.org"> emoore@FreeBSD.org"> eri@FreeBSD.org"> eric@FreeBSD.org"> erich@FreeBSD.org"> erik@FreeBSD.org"> erwin@FreeBSD.org"> fabient@FreeBSD.org"> fanf@FreeBSD.org"> farrokhi@FreeBSD.org"> feld@FreeBSD.org"> fenner@FreeBSD.org"> fjoe@FreeBSD.org"> flathill@FreeBSD.org"> flo@FreeBSD.org"> fluffy@FreeBSD.org"> flz@FreeBSD.org"> foxfair@FreeBSD.org"> fsmp@FreeBSD.org"> furuta@FreeBSD.org"> gabor@FreeBSD.org"> gad@FreeBSD.org"> gahr@FreeBSD.org"> gallatin@FreeBSD.org"> ganbold@FreeBSD.org"> garga@FreeBSD.org"> garys@FreeBSD.org"> gavin@FreeBSD.org"> gber@FreeBSD.org"> gblach@FreeBSD.org"> gclarkii@FreeBSD.org"> gehenna@FreeBSD.org"> gerald@FreeBSD.org"> ghelmer@FreeBSD.org"> gibbs@FreeBSD.org"> gioria@FreeBSD.org"> girgen@FreeBSD.org"> gj@FreeBSD.org"> gjb@FreeBSD.org"> glarkin@FreeBSD.org"> gleb@FreeBSD.org"> glebius@FreeBSD.org"> glewis@FreeBSD.org"> gnn@FreeBSD.org"> gonzo@FreeBSD.org"> gordon@FreeBSD.org"> gpalmer@FreeBSD.org"> graichen@FreeBSD.org"> green@FreeBSD.org"> grehan@FreeBSD.org"> greid@FreeBSD.org"> grog@FreeBSD.org"> groudier@FreeBSD.org"> gryphon@FreeBSD.org"> gshapiro@FreeBSD.org"> gsutter@FreeBSD.org"> guido@FreeBSD.org"> hanai@FreeBSD.org"> harti@FreeBSD.org"> helbig@FreeBSD.org"> hiren@FreeBSD.org"> hm@FreeBSD.org"> hmp@FreeBSD.org"> hoek@FreeBSD.org"> horikawa@FreeBSD.org"> hosokawa@FreeBSD.org"> hq@FreeBSD.org"> hrs@FreeBSD.org"> hselasky@FreeBSD.org"> hsu@FreeBSD.org"> ian@FreeBSD.org"> iedowse@FreeBSD.org"> ijliao@FreeBSD.org"> ikob@FreeBSD.org"> imp@FreeBSD.org"> imura@FreeBSD.org"> issei@FreeBSD.org"> issyl0@FreeBSD.org"> itetcu@FreeBSD.org"> itojun@FreeBSD.org"> ivoras@FreeBSD.org"> iwasaki@FreeBSD.org"> jacula@FreeBSD.org"> jadawin@FreeBSD.org"> jake@FreeBSD.org"> jamie@FreeBSD.org"> jamil@FreeBSD.org"> jase@FreeBSD.org"> jasone@FreeBSD.org"> jayanth@FreeBSD.org"> jb@FreeBSD.org"> jcamou@FreeBSD.org"> jceel@FreeBSD.org"> jchandra@FreeBSD.org"> jdp@FreeBSD.org"> jedgar@FreeBSD.org"> jeff@FreeBSD.org"> jeh@FreeBSD.org"> jehamby@FreeBSD.org"> jennifer@FreeBSD.org"> jesper@FreeBSD.org"> jesusr@FreeBSD.org"> jfieber@FreeBSD.org"> jfitz@FreeBSD.org"> jfv@FreeBSD.org"> jgh@FreeBSD.org"> jgreco@FreeBSD.org"> jh@FreeBSD.org"> jhale@FreeBSD.org"> jhay@FreeBSD.org"> jhb@FreeBSD.org"> jhibbits@FreeBSD.org"> jhs@FreeBSD.org"> jilles@FreeBSD.org"> jim@FreeBSD.org"> jimharris@FreeBSD.org"> jinmei@FreeBSD.org"> jkb@FreeBSD.org"> jkh@FreeBSD.org"> jkim@FreeBSD.org"> jkois@FreeBSD.org"> jkoshy@FreeBSD.org"> jlaffaye@FreeBSD.org"> jlemon@FreeBSD.org"> jlh@FreeBSD.org"> jlrobin@FreeBSD.org"> jls@FreeBSD.org"> jmacd@FreeBSD.org"> jmallett@FreeBSD.org"> jmas@FreeBSD.org"> jmb@FreeBSD.org"> jmelo@FreeBSD.org"> jmg@FreeBSD.org"> jmz@FreeBSD.org"> joe@FreeBSD.org"> joel@FreeBSD.org"> joerg@FreeBSD.org"> johan@FreeBSD.org"> johans@FreeBSD.org"> john@FreeBSD.org"> jon@FreeBSD.org"> jonathan@FreeBSD.org"> josef@FreeBSD.org"> jpaetzel@FreeBSD.org"> jraynard@FreeBSD.org"> jsa@FreeBSD.org"> jseger@FreeBSD.org"> jtc@FreeBSD.org"> julian@FreeBSD.org"> jvh@FreeBSD.org"> jwd@FreeBSD.org"> jylefort@FreeBSD.org"> kaiw@FreeBSD.org"> kan@FreeBSD.org"> kargl@FreeBSD.org"> karl@FreeBSD.org"> kato@FreeBSD.org"> kbyanc@FreeBSD.org"> keichii@FreeBSD.org"> keith@FreeBSD.org"> ken@FreeBSD.org"> kensmith@FreeBSD.org"> keramida@FreeBSD.org"> kevlo@FreeBSD.org"> kib@FreeBSD.org"> kientzle@FreeBSD.org"> kiri@FreeBSD.org"> kishore@FreeBSD.org"> kjc@FreeBSD.org"> kmacy@FreeBSD.org"> kmoore@FreeBSD.org"> knu@FreeBSD.org"> koitsu@FreeBSD.org"> koobs@FreeBSD.org"> krion@FreeBSD.org"> kris@FreeBSD.org"> kuku@FreeBSD.org"> kuriyama@FreeBSD.org"> kwm@FreeBSD.org"> lars@FreeBSD.org"> laszlof@FreeBSD.org"> lawrance@FreeBSD.org"> lbr@FreeBSD.org"> le@FreeBSD.org"> leeym@FreeBSD.org"> lesi@FreeBSD.org"> lev@FreeBSD.org"> lile@FreeBSD.org"> linimon@FreeBSD.org"> lioux@FreeBSD.org"> lippe@FreeBSD.org"> ljo@FreeBSD.org"> lkoeller@FreeBSD.org"> lme@FreeBSD.org"> loader@FreeBSD.org"> lofi@FreeBSD.org"> logo@FreeBSD.org"> loos@FreeBSD.org"> lstewart@FreeBSD.org"> lth@FreeBSD.org"> luigi@FreeBSD.org"> lulf@FreeBSD.org"> luoqi@FreeBSD.org"> lwhsu@FreeBSD.org"> lx@FreeBSD.org"> madpilot@FreeBSD.org"> maho@FreeBSD.org"> makc@FreeBSD.org"> mandree@FreeBSD.org"> manolis@FreeBSD.org"> marcel@FreeBSD.org"> marck@FreeBSD.org"> marcus@FreeBSD.org"> marino@FreeBSD.org"> marius@FreeBSD.org"> markj@FreeBSD.org"> markm@FreeBSD.org"> marko@FreeBSD.org"> markp@FreeBSD.org"> marks@FreeBSD.org"> markus@FreeBSD.org"> martin@FreeBSD.org"> martymac@FreeBSD.org"> mat@FreeBSD.org"> matk@FreeBSD.org"> matt@FreeBSD.org"> matteo@FreeBSD.org"> matthew@FreeBSD.org"> matusita@FreeBSD.org"> mav@FreeBSD.org"> max@FreeBSD.org"> maxim@FreeBSD.org"> mb@FreeBSD.org"> mbarkah@FreeBSD.org"> mbr@FreeBSD.org"> mckay@FreeBSD.org"> mckusick@FreeBSD.org"> mdf@FreeBSD.org"> mdodd@FreeBSD.org"> meganm@FreeBSD.rgo"> melifaro@FreeBSD.org"> metal@FreeBSD.org"> mezz@FreeBSD.org"> mharo@FreeBSD.org"> mheinen@FreeBSD.org"> mi@FreeBSD.org"> mich@FreeBSD.org"> mike@FreeBSD.org"> mikeh@FreeBSD.org"> mini@FreeBSD.org"> mita@FreeBSD.org"> miwi@FreeBSD.org"> mjacob@FreeBSD.org"> mjg@FreeBSD.org"> mks@FreeBSD.org"> mlaier@FreeBSD.org"> mm@FreeBSD.org"> mnag@FreeBSD.org"> mohans@FreeBSD.org"> monthadar@FreeBSD.org"> motoyuki@FreeBSD.org"> mp@FreeBSD.org"> mph@FreeBSD.org"> mpp@FreeBSD.org"> mr@FreeBSD.org"> msmith@FreeBSD.org"> mtaylor@FreeBSD.org"> mtm@FreeBSD.org"> murray@FreeBSD.org"> mux@FreeBSD.org"> mva@FreeBSD.org"> mwlucas@FreeBSD.org"> naddy@FreeBSD.org"> nakai@FreeBSD.org"> nate@FreeBSD.org"> nbm@FreeBSD.org"> nectar@FreeBSD.org"> neel@FreeBSD.org"> nemoliu@FreeBSD.org"> netchild@FreeBSD.org"> newton@FreeBSD.org"> n_hibma@FreeBSD.org"> niels@FreeBSD.org"> nik@FreeBSD.org"> niklas@FreeBSD.org"> nivit@FreeBSD.org"> njl@FreeBSD.org"> nobutaka@FreeBSD.org"> non@FreeBSD.org"> nork@FreeBSD.org"> novel@FreeBSD.org"> nox@FreeBSD.org"> np@FreeBSD.org"> nra@FreeBSD.org"> nsayer@FreeBSD.org"> nsj@FreeBSD.org"> nsouch@FreeBSD.org"> nwhitehorn@FreeBSD.org"> nyan@FreeBSD.org"> obraun@FreeBSD.org"> obrien@FreeBSD.org"> ohauer@FreeBSD.org"> okazaki@FreeBSD.org"> olah@FreeBSD.org"> oleg@FreeBSD.org"> olgeni@FreeBSD.org"> oliver@FreeBSD.org"> olivierd@FreeBSD.org"> olli@FreeBSD.org"> onoe@FreeBSD.org"> orion@FreeBSD.org"> osa@FreeBSD.org"> pat@FreeBSD.org"> patrick@FreeBSD.org"> paul@FreeBSD.org"> pav@FreeBSD.org"> pawel@FreeBSD.org"> pb@FreeBSD.org"> pclin@FreeBSD.org"> pdeuskar@FreeBSD.org"> pds@FreeBSD.org"> peadar@FreeBSD.org"> perky@FreeBSD.org"> petef@FreeBSD.org"> peter@FreeBSD.org"> peterj@FreeBSD.org"> pfg@FreeBSD.org"> pgj@FreeBSD.org"> pgollucci@FreeBSD.org"> phantom@FreeBSD.org"> philip@FreeBSD.org"> phk@FreeBSD.org"> pho@FreeBSD.org"> piero@FreeBSD.org"> pirzyk@FreeBSD.org"> piso@FreeBSD.org"> pjd@FreeBSD.org"> pluknet@FreeBSD.org"> proven@FreeBSD.org"> ps@FreeBSD.org"> pst@FreeBSD.org"> qingli@FreeBSD.org"> rafan@FreeBSD.org"> raj@FreeBSD.org"> rakuco@FreeBSD.org"> randi@FreeBSD.org"> ray@FreeBSD.org"> rdivacky@FreeBSD.org"> rea@FreeBSD.org"> rees@FreeBSD.org"> reg@FreeBSD.org"> remko@FreeBSD.org"> rene@FreeBSD.org"> rgrimes@FreeBSD.org"> ricardag@FreeBSD.org"> rich@FreeBSD.org"> rik@FreeBSD.org"> rink@FreeBSD.org"> rm@FreeBSD.org"> rmacklem@FreeBSD.org"> rmh@FreeBSD.org"> rnoland@FreeBSD.org"> rnordier@FreeBSD.org"> roam@FreeBSD.org"> robert@FreeBSD.org"> roberto@FreeBSD.org"> rodrigc@FreeBSD.org"> roger@FreeBSD.org"> romain@FreeBSD.org"> rpaulo@FreeBSD.org"> rpratt@FreeBSD.org"> rrs@FreeBSD.org"> rse@FreeBSD.org"> rsm@FreeBSD.org"> rstone@FreeBSD.org"> ru@FreeBSD.org"> rushani@FreeBSD.org"> rv@FreeBSD.org"> rvb@FreeBSD.org"> rwatson@FreeBSD.org"> ryusuke@FreeBSD.org"> sada@FreeBSD.org"> sah@FreeBSD.org"> sahil@FreeBSD.org"> sam@FreeBSD.org"> sanpei@FreeBSD.org"> sat@FreeBSD.org"> sbruno@FreeBSD.org"> sbz@FreeBSD.org"> scf@FreeBSD.org"> scheidell@FreeBSD.org"> schweikh@FreeBSD.org"> scop@FreeBSD.org"> scottl@FreeBSD.org"> scrappy@FreeBSD.org"> se@FreeBSD.org"> sean@FreeBSD.org"> seanc@FreeBSD.org"> sef@FreeBSD.org"> sem@FreeBSD.org"> semenu@FreeBSD.org"> sephe@FreeBSD.org"> sepotvin@FreeBSD.org"> sergei@FreeBSD.org"> sf@FreeBSD.org"> shafeeq@FreeBSD.org"> shaun@FreeBSD.org"> sheldonh@FreeBSD.org"> shiba@FreeBSD.org"> shige@FreeBSD.org"> shin@FreeBSD.org"> silby@FreeBSD.org"> simokawa@FreeBSD.org"> simon@FreeBSD.org"> sjg@FreeBSD.org"> skreuzer@FreeBSD.org"> skv@FreeBSD.org"> smace@FreeBSD.org"> smh@FreeBSD.org"> smkelly@FreeBSD.org"> smpatel@FreeBSD.org"> snb@FreeBSD.org"> sobomax@FreeBSD.org"> sos@FreeBSD.org"> sperber@FreeBSD.org"> sson@FreeBSD.org"> ssouhlal@FreeBSD.org"> adam@redprince.net"> stark@FreeBSD.org"> stas@FreeBSD.org"> stb@FreeBSD.org"> stefan@FreeBSD.org"> stefanf@FreeBSD.org"> stephane@FreeBSD.org"> stephen@FreeBSD.org"> steve@FreeBSD.org"> sumikawa@FreeBSD.org"> sunpoet@FreeBSD.org"> suz@FreeBSD.org"> swallace@FreeBSD.org"> swills@FreeBSD.org"> sylvio@FreeBSD.org"> syrinx@FreeBSD.org"> syuu@FreeBSD.org"> tabthorpe@FreeBSD.org"> tackerman@FreeBSD.org"> takawata@FreeBSD.org"> tanimura@FreeBSD.org"> taoka@FreeBSD.org"> taras@FreeBSD.org"> tdb@FreeBSD.org"> tedm@FreeBSD.org"> tegge@FreeBSD.org"> tg@FreeBSD.org"> thepish@FreeBSD.org"> theraven@FreeBSD.org"> thierry@FreeBSD.org"> thomas@FreeBSD.org"> thompsa@FreeBSD.org"> ticso@FreeBSD.org"> tijl@FreeBSD.org"> timur@FreeBSD.org"> tj@FreeBSD.org"> tjr@FreeBSD.org"> tmclaugh@FreeBSD.org"> tmm@FreeBSD.org"> tmseck@FreeBSD.org"> tobez@FreeBSD.org"> tom@FreeBSD.org"> tomsoft@FreeBSD.org"> torstenb@FreeBSD.org"> toshi@FreeBSD.org"> tota@FreeBSD.org"> trasz@FreeBSD.org"> trevor@FreeBSD.org"> trhodes@FreeBSD.org"> trociny@FreeBSD.org"> truckman@FreeBSD.org"> tshiozak@FreeBSD.org"> tuexen@FreeBSD.org"> tweten@FreeBSD.org"> twinterg@FreeBSD.org"> uch@FreeBSD.org"> ue@FreeBSD.org"> ugen@FreeBSD.org"> uhclem@FreeBSD.org"> ulf@FreeBSD.org"> ume@FreeBSD.org"> unfurl@FreeBSD.org"> ups@FreeBSD.org"> uqs@FreeBSD.org"> vanhu@FreeBSD.org"> vanilla@FreeBSD.org"> vd@FreeBSD.org"> versus@FreeBSD.org"> vg@FreeBSD.org"> viny@FreeBSD.org"> vkashyap@FreeBSD.org"> vs@FreeBSD.org"> vsevolod@FreeBSD.org"> vwe@FreeBSD.org"> wblock@FreeBSD.org"> wen@FreeBSD.org"> weongyo@FreeBSD.org"> wes@FreeBSD.org"> wg@FreeBSD.org"> whiteside@acm.org"> wilko@FreeBSD.org"> will@FreeBSD.org"> wjv@FreeBSD.org"> wkoszek@FreeBSD.org"> wolf@FreeBSD.org"> wollman@FreeBSD.org"> wosch@FreeBSD.org"> wpaul@FreeBSD.org"> wsalamon@FreeBSD.org"> wsanchez@FreeBSD.org"> wxs@FreeBSD.org"> wylie@magnesium.net"> xride@FreeBSD.org"> yar@FreeBSD.org"> yoichi@FreeBSD.org"> yokota@FreeBSD.org"> yongari@FreeBSD.org"> yzlin@FreeBSD.org"> zack@FreeBSD.org"> zarzycki@FreeBSD.org"> zec@FreeBSD.org"> zeising@FreeBSD.org"> zi@FreeBSD.org"> zml@FreeBSD.org"> znerd@FreeBSD.org"> zont@FreeBSD.org"> - + - + - + - - + + - + diff --git a/share/xml/events2013.xml b/share/xml/events2013.xml index 68a0a15936..6d30321f7b 100644 --- a/share/xml/events2013.xml +++ b/share/xml/events2013.xml @@ -1,136 +1,161 @@ $FreeBSD$ AsiaBSDCon 2013 http://2013.asiabsdcon.org/ 2013 3 14 2013 3 17 Japan Tokyo Tokyo University of Science AsiaBSDCon is a conference for users and developers on BSD based systems. The conference is for anyone developing, deploying and using systems based on FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, Darwin and MacOS X. AsiaBSDCon is a technical conference and aims to collect the best technical papers and presentations available to ensure that the latest developments in our open source community are shared with the widest possible audience. Central European BSD-Day 2013 http://bsdday.eu/2013 2013 4 6 2013 4 6 Italy Naples Institute of Biostructures and Bioimaging Watch out, another BSD-Day is rising: next April Beastie visits Naples to gather BSD people of Italy and Central Europe to meet up! This event is an excellent opportunity for BSD developers and enthusiasts to present their work to larger audiences, share their thoughts with their fellows and reach out for their potential partners. Traditionally, the event tries to avoid formalities as it does not require the speakers to submit papers or the attendees to register or pay an entry fee. However, the invited folks are encouraged to a give a brief talk on their favorite BSD topic. The goal is to motivate everybody, especially university students to see the benefits of our approach and take a chance on working with BSD systems. BSDCan 2013 http://www.bsdcan.org/ 2013 5 15 2013 5 18 Canada Ottawa University of Ottawa YouTube Playlist of Presentation Videos https://www.youtube.com/playlist?list=PLWW0CjV-TafZN1ArKy3j6X7YJ57_FFQ5e BSDCan is a developers conference with a strong focus on emerging technologies, research projects, and works in progress. It also features Userland infrastructure projects and invites contributions from both free software developers and those from commercial vendors. + + KyivBSD 2013 + http://en.kyivbsd.org.ua/ + + 2013 + 9 + 21 + + + 2013 + 9 + 21 + + + Ukraine + Kyiv + Taras Shevchenko National University of Kyiv + + We are glad to invite all to the fifth conference + placed in Kyiv! Kyiv is both historical landmark and urbanistic + city with many people interested in open source in general. + It is a good choice for local and foreign developers + to attend. + + EuroBSDcon 2013 http://2013.eurobsdcon.org/ 2013 9 26 2013 9 29 Malta St. Julian's Hilton Conference Centre We are happy to announce that the EuroBSDcon 2013 will be held on Saturday 28th and Sunday 29th of September 2013 (tutorials on Thursday 26th and Friday 27th) on Malta (St. Julian's area). The weather is great at about 26°C during the day and 20°C at night. The ocean is still warm from summer. Consider taking you family, wife, kids and spouse with you for a long weekend. The social event on Saturday evening will be a BBQ at a beautiful sandy beach. Family is invited too and children attend for free. A side program with sight seeing and a tour of the island is being organized at cost. diff --git a/share/xml/news.xml b/share/xml/news.xml index bdf8c75075..a7a482beff 100644 --- a/share/xml/news.xml +++ b/share/xml/news.xml @@ -1,2600 +1,2658 @@ $FreeBSD$ 2013 + + 8 + + + 6 + + + The &os; Foundation Semi-Annual Newsletter is + Now Available + +

We are pleased to announce the publication of our 2013 + Semi-Annual Newsletter! This is a chance for you to read + about what we are doing to help make &os; the best + operating system available.

+ +

Read about funded development projects to improve &os;, + sponsored conferences, developer and vendor summits to + create face-to-face opportunities, research, how we are + doing on our fundraising efforts, and so much more!

+ +

The 2013 semi-annual newsletter is available online here.

+
+
+ + + 5 + + + &os; 9.2-RC1 Available + +

The first RC build for the &os;-9.2 release cycle is + now available. ISO images for the amd64, i386, ia64, + powerpc, powerpc64 and sparc64 architectures are available + on most of our &os; + mirror sites.

+
+
+
+ 7 + + 29 + + + &os; 9.2-BETA2 Available + +

The second BETA build for the &os;-9.2 release cycle is + now available. ISO images for the amd64, i386, powerpc64 + and sparc64 architectures are available + on most of our &os; + mirror sites.

+
+
+ 22 &os; 9.2-BETA1 Available

The first BETA build for the &os;-9.2 release cycle is now available. ISO images for the amd64, i386 and ia64 architectures are available on most of our &os; mirror sites.

16 April-June, 2013 Status Report

The April-June, 2013 Status Report is now available with 33 entries.

4

New committer: John Marino (ports)

3

New committer: Luiz Otavio O Souza (src)

2 BSDCan 2013 DevSummit Report

A special status report on the results of the BSDCan 2013 &os; Developer Summit is now available with 6 entries.

6 25

New committer: Mark Felder (ports)

19 Happy Birthday &os;!

&os; celebrated its 20th birthday today. On June 19, 1993, Jordan Hubbard, Rod Grimes, and David Greenman announced to the world the creation of their new fork of the BSD 4.3 operating system.

&os; was derived from the 386BSD 0.1 release from Bill and Lynne Jolitz with its 1.0 release in Nov 1993. Its stated goals were to create a fast, stable, reliable server OS for i386 systems.

Since then, it has become the backbone of countless products and has grown to supporting 64bit computing, embedded devices, and desktop users.

11

New committer: Veniamin Gvozdikov (ports)

7 &os; 8.4-RELEASE Available

&os;  8.4-RELEASE is now available. Please be sure to check the Release Notes (detailed version) and Release Errata before installation for any late-breaking news and/or issues with 8.4. More information about &os; releases can be found on the Release Information page.

4

Enhanced commit privileges: Glen Barber (doc, ports, src)

5 27

Enhanced commit privileges: Chris Rees (doc, ports)

14 Binary Packages Are Available Again

Six months have passed since the November security incident which brought the Project's binary package building capacity offline; we are pleased to announce that all services are now restored.

Read the official announcement here.

12 January-March 2013 Status Report

The January to March 2013 Status Report is now available with 31 entries.

9 &os; Foundation Announces Ed Maste as New Director of Project Development

The &os; Foundation is pleased to announce Ed Maste's new role as the Foundation's part-time Director of Project Development. Ed has served on the Foundation's board for two years, and has stepped down in order to accept this new position.

Read more...

8 &os; 8.4-RC3 Available

The third RC build for the &os;-8.4 release cycle is now available. ISO images for the amd64, i386 and pc98 architectures are available on most of our &os; mirror sites.

4 29 New &os; Foundation Technical Staff Member: Edward Tomasz Napierała

The &os; Foundation is pleased to announce that Edward Tomasz Napierała has joined as its second member of technical staff. This is a continuation of the Foundation's plan to invest in staff in 2013.

Read more...

24

New committer: Alan Somers (src)

FreeBSD Project to participate in Google Summer of Code 2013

The FreeBSD Project is pleased to announce its participation In Google's 2013 Summer of Code program, which funds summer students to participate in open source projects. This will be the FreeBSD Project's ninth year in the program, having mentored over 150 successful students through summer-long coding projects between 2005 and 2012.

Past successful projects have included improvements to Linux ABI emulation, NFSv4 ACLs, TCP regression testing, FUSE file system support, and countless other projects. Many students go on to become FreeBSD developers, as well as participating in FreeBSD developer events around the world through continuing support from the FreeBSD Foundation.

Prospective participants are invited to apply; more information is available, including proposal and deadline information, on the FreeBSD Summer Projects page.

22 &os; 8.4-RC2 Available

The second RC build for the &os;-8.4 release cycle is now available. ISO images for the amd64, i386 and pc98 architectures are available on most of our &os; mirror sites.

18

Enhanced commit privileges: Cy Schubert (src, ports)

12

New committer: Hiren Panchasara (src)

10 &os; 8.4-RC1 Available

The first RC build for the &os;-8.4 release cycle is now available. ISO images for the amd64, i386 and pc98 architectures are available on most of our &os; mirror sites.

3

Enhanced commit privileges: Antoine Brodin (src, ports)

1

New committer: William Grzybowski (ports)

3 27

Enhanced commit privileges: Tijl Coosemans (src, ports)

22 &os; 8.4-BETA1 Available

The first BETA build for the &os;-8.4 release cycle is now available. ISO images for the amd64, i386 and pc98 architectures are available on most of our &os; mirror sites.

14 New &os; Foundation Technical Staff Member: Konstantin Belousov

The &os; Foundation is pleased to announce that Konstantin Belousov has been hired as its first full-time member of technical staff, a key milestone of the Foundation's investment in staff for 2013.

Read more...

12

New member for the Ports Management team: Bryan Drewery

3 October-December 2012 Status Report

The October to December 2012 Status Report is now available with 27 entries.

July-September 2012 Status Report

The July to September 2012 Status Report is now available with 12 entries.

2 10

New committer: Po-Chien Lin (ports)

1

New committer: Thomas-Martin Seck (ports)

1 23

New committer: Achim Leubner (src)

22

New committer: Dru Lavigne (doc)

16

New committer: Carl Delsey (src)

15

Enhanced commit privileges: René Ladan (ports, full doc/www)

14

New committer: David Naylor (ports)

13 April-June, 2012 Status Report

The April-June, 2012 Status Report is now available with 17 entries.

10 Ports CVS End of Life on February 28th 2013

The development of &os; ports is done in Subversion nowadays. By February 28th 2013, the &os; ports tree will no longer be exported to CVS. Therefore ports tree updates via CVS, CVSup or csup(1) will no longer be available after that date. All users who use CVS, CVSup or csup(1) to update the ports tree are encouraged to switch to portsnap(8) or for users which need more control over their ports collection checkout, use Subversion directly. More information are available in the announcement mail on the &os; ports announce mailing list.

A migration guide from CVSup or csup(1) to portsnap(8) is also available in the &os; Handbook.

8 Faces of &os; ‐ Thomas Abthorpe

We are excited to share our next story for our Faces of &os; Series. This is a chance for us to spotlight different people who contribute to &os; and have received funding from us to work on development projects, run conferences, travel to conferences, and advocate for &os;.

Let us introduce you to Thomas Abthorpe. We helped him attend BSDCan 2009, 2011, and 2012 by helping with his travel expenses. Read his story here.

7

New committer: Ian Lepore (src)

2012 12 31 &os; 9.1-RELEASE Available

FreeBSD 9.1-RELEASE is now available. Please be sure to check the Release Notes (detailed version) and Release Errata before installation for any late-breaking news and/or issues with 9.1. More information about FreeBSD releases can be found on the Release Information page.

24

New committer: Kubilay Kocak (ports)

20 The &os; Foundation End-of-Year Newsletter is Now Available.

We are pleased to announce the publication of The &os; Foundation's 2012 End-of-Year Newsletter.

18

New committer: Mark Johnston (src)

PC-BSD 9.1 is Released

The PC-BSD Team announces the availablilty of PC-BSD 9.1.

New committer: Steven Hartland (src)

17 Faces of &os; ‐ Dan Langille

We are excited to share our next story for our Faces of &os; Series. This is a chance for us to spotlight different people who contribute to &os; and have received funding from us to work on development projects, run conferences, travel to conferences, and advocate for &os;.

Let us introduce you to Dan Langille. We helped him by sponsoring BSDCan since 2006. Read his story here.

12 Stunning News Website Fundraising Contribution: Over 650 new donations raise $43,200 in three days!

Astute readers of our blog know that The &os; Foundation's annual year-end fundraising drive began last week. Every year over 50% of our donations arrive during this campaign. Read more...

10 Faces of &os; ‐ Alberto Mijares

Are you aware of the tangible benefits derived from our support of the &os; community? In conjunction with our year-end fundraising drive we are going to be spotlighting different people on our website, blog, and Facebook page who have received funding to work on development projects, run conferences, travel to conferences, and advocate for &os;. Read more...

5 &os; Year-End Fundraising Campaign

Your donations have helped make &os; the best OS available! By investing in The &os; Foundation you have helped us keep &os; a high-performance, secure, and stable operating system.

Thanks to people like you, the &os; Foundation has been proudly supporting the &os; Project and community for 12 years now. Read more...

&os; Project Website is Using Google Analytics

The &os; Project has enabled Google Analytics to collect anonymised statistics on web site use. More information can be found in the official announcement.

11 26

New committer: Takuya ASADA (src)

25

New committer: Barbara Guida (ports)

17 Security Incident on FreeBSD Infrastructure

On Sunday 11th of November, an intrusion was detected on two machines within the FreeBSD.org cluster. We have found no evidence of any modifications that would put any end user at risk. However, we do urge all users to read the report available at http://www.freebsd.org/news/2012-compromise.html and decide on any required actions themselves.

5

New committer: Bryan Venteicher (src)

4

New committer: Grzegorz Blach (ports)

3 &os; 9.1-RC3 Available

The third RC build for the &os;-9.1 release cycle is now available. ISO images for the amd64, i386, sparc64, and powerpc64 architectures are available on most of our &os; mirror sites.

10 24

Enhanced commit privileges: Erwin Lansing (src, ports)

23

New committer: Simon J. Gerraty (src)

20

Enhanced commit privileges: Eitan Adler (src, ports, doc)

19

New member for the Ports Management team: Bernhard Fröhlich.

10 &os; 9.1-RC2 Available

The second RC build for the &os;-9.1 release cycle is now available. ISO images for the amd64, i386, ia64, powerpc, and powerpc64 architectures are available on most of our &os; mirror sites.

9 15

New committer: Peter Jeremy (src)

13

New committer: Edson Brandi (doc/pt_BR, www/pt_BR)

10

New committer: Jason E. Hale (ports)

8 23 &os; 9.1-RC1 Available

The first RC build for the &os;-9.1 release cycle is now available. ISO images for the amd64, i386 and powerpc64 architectures are available on most of our &os; mirror sites.

21

New committer: Andrey Zonov (src)

1

New committer: Bryan Drewery (ports)

7 24 New Core Team Secretary: <a href="mailto:pgj@FreeBSD.org">Gábor Páli</a>

The &os; Core Team is glad to announce that Gábor Páli has assumed the role of Core Team Secretary.

16 &os; 9.1-BETA1 Available

The first BETA build for the &os;-9.1 release cycle is now available. ISO images for the architectures amd64, i386, powerpc64, and sparc64 are available on most of our &os; mirror sites.

11 New &os; Core Team elected

The &os; Project is pleased to announce the completion of the 2012 Core Team election. The &os; Core Team acts as the project's "board of directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, etc ...), and making any other administrative or policy decisions as needed. The Core Team has been elected by &os; developers every two years since 2000.

More information about the election (together with a list of the new members of the Core Team) can be found in the official announcement.

3

New committer: Niclas Zeising (doc/www, ports)

6 19

Enhanced commit privileges: Glen Barber (doc, ports)

4

New committer: Mateusz Guzik (src)

5 30

New committer: Jase Thew (ports)

29

New committer: Olivier Duchateau (ports)

28

New committer: Tom Judge (ports)

12 January-March, 2012 Status Report

The January-March, 2012 Status Report is now available with 27 entries.

4 26

New committer: Isabell Long (doc/www)

22

New committer: Jeremie Le Hen (src)

18 &os; 8.3-RELEASE Available

FreeBSD 8.3-RELEASE is now available. Please be sure to check the Release Notes and Release Errata before installation for any late-breaking news and/or issues with 8.3. More information about FreeBSD releases can be found on the Release Information page.

New committer: Devin Teske (src)

15

New committer: Armin Pirkovitsch (ports)

13

New committer: Monthadar Al Jaberi (src)

12

New committer: Guido Falsi (ports)

2 &os; 8.3-RC2 Available

The second release candidate build for the &os;-8.3 release cycle is now available. ISO images for the amd64, i386, and pc98 architectures are available on most of our &os; mirror sites.

3 23

New committer: Cherry G. Mathew (src)

12

New committer: Benjamin Kaduk (doc/www)

6 &os; 8.3-RC1 Available

The first RC build for the &os;-8.3 release cycle is now available. ISO images for the amd64, i386, and pc98 architectures are available on most of our &os; mirror sites.

01

New committer: Alex Kozlov (ports)

2 20 &os; 8.3-BETA1 Available

The first test build for the &os;-8.3 release cycle is now available. ISO images for the amd64, i386, and pc98 architectures are available on most of our &os; mirror sites.

16

New committer: Damjan Marion (src)

New committer: Ben Gray (src)

14

Enhanced commit privileges: Sergey Kandaurov (src, doc)

7

New committer: Matthew Seaman (ports)

1 27

New committer: Davide Italiano (src)

October-December, 2011 Status Report

The October-December, 2011 Status Report is now available with 32 entries.

12 &os; 9.0-RELEASE Available

FreeBSD 9.0-RELEASE is now available. Please be sure to check the Release Notes and Release Errata before installation for any late-breaking news and/or issues with 9.0. More information about FreeBSD releases can be found on the Release Information page.

2011 12 16

New committer: Jason Helfman (ports)

9 &os; 9.0-RC3 Available

The third (and probably last) RC build for the &os;-9.0 release cycle is now available. ISO images for the architectures amd64, i386, ia64, powerpc, powerpc64, and sparc64 are available on most of our &os; mirror sites. One of the many new features in 9.0 we would like to be tested is the new installer, so we encourage our users to do fresh installation on test systems. Alternatively, users upgrading existing systems may now do so using the freebsd-update(8) utility.

8

New committer: Pedro Giffuni (src)

2

New member for the Ports Management team: Beat Gätzi

11 30

New committer: Justin Hibbits (src)

17 &os; 9.0-RC2 Available

The second RC build for the &os;-9.0 release cycle is now available. ISO images for the architectures amd64, i386, ia64, powerpc, powerpc64, and sparc64 are available on most of our &os; mirror sites. One of the many new features in 9.0 we would like to be tested is the new installer, so we encourage our users to do fresh installation on test systems. Alternatively, users upgrading existing systems may now do so using the freebsd-update(8) utility.

12

New committer: Michael Scheidell (ports)

11

New committer: David Chisnall (src)

9

New committer: Ruslan Makhmatkhanov (ports)

8 July-September, 2011 Status Report

The July-September, 2011 Status Report is now available with 28 entries.

10 23 &os; 9.0-RC1 Available

The first RC build for the &os;-9.0 release cycle is now available. ISO images for the architectures amd64, i386, ia64, powerpc, powerpc64, and sparc64 are available on most of our &os; mirror sites. One of the many new features in 9.0 we would like to be tested is the new installer, so we encourage our users to do fresh installation on test systems. Alternatively, users upgrading existing systems may now do so using the freebsd-update(8) utility.

6

New committer: Alexander V. Chernikov (src)

9 28 &os; 9.0-BETA3 Available

The third BETA build for the &os;-9.0 release cycle is now available. ISO images for the architectures amd64, i386, ia64, powerpc, powerpc64, and sparc64 are available on most of our &os; mirror sites. One of the many new features in 9.0 we would like to be tested is the new installer, so we encourage our users to do fresh installation on test systems.

27

New committer: Jakub Klama (src)

19

New committer: Gleb Kurtsou (src)

18

New committer: Robert Millan (src)

14

New committer: Warren Block (doc/www)

April-June, 2011 Status Report

The April-June, 2011 Status Report is now available with 36 entries.

13

New committer: Carlo Strub (ports)

7 &os; 9.0-BETA2 Available

The second BETA build for the &os;-9.0 release cycle is now available. ISO images for the architectures amd64, i386, powerpc, powerpc64, and sparc64 are available on most of our &os; mirror sites. One of the many new features in 9.0 we would like to be tested is the new installer, so we encourage our users to do fresh installation on test systems.

8 22

New committer: Raphael Kubo da Costa (ports)

17

New committer: Eitan Adler (ports)

9 &os; Foundation August 2011 Newsletter

The &os; Foundation has published their first Semi-Annual 2011 newsletter which summarizes what they have done to help the &os; Project and community.

1 &os; 9.0-BETA1 Available

The first test build for the &os;-9.0 release cycle is now available. ISO images for the architectures amd64, i386, ia64, powerpc, powerpc64, and sparc64 are available on most of our &os; mirror sites. One of the many new features in 9.0 we would like to be tested is the new installer, so we encourage our users to do fresh installation on test systems.

7 17

Enhanced commit privileges: Gavin Atkinson (src, doc)

15

New committer: Ryan Steinmetz (ports)

6 14

New committer: Grzegorz Bernacki (src)

13

New committer: Stephen Montgomery-Smith (ports)

11

New committer: Chris Rees (ports)

6 IPv6-only &os; test images

&os; Foundation and iXsystems announce IPv6-only test images of FreeBSD and PC-BSD.

New committer: Julien Laffaye (ports)

5 25

New committer: Aleksandr Rybalko (src)

18

New committer: Ben Laurie (src)

12 New Port Manager

The Ports Management Team is pleased to announce Baptiste Daroussin as a new member.

4 27 January-March, 2011 Status Report

The January-March, 2011 Status Report is now available with 34 entries.

3 29

New committer: Artem Belevich (src)

27 FreeBSD Project to participate in Google Summer of Code 2011

The FreeBSD Project is pleased to announce its participation In Google's 2011 Summer of Code program, which funds summer students to participate in open source projects. This will be the FreeBSD Project's seventh year in the program, having mentored over 100 successful students through summer-long coding projects between 2005 and 2010.

Past successful projects have included improvements to Linux ABI emulation, NFSv4 ACLs, TCP regression testing, FUSE file system support, and countless other projects. Many students go on to become FreeBSD developers, as well as participating in FreeBSD developer events around the world through continuing support from the FreeBSD Foundation.

Prospective participants are invited to apply; more information is available, including proposal and deadline information, on the FreeBSD Summer Projects page.

18

New committer: Sofian Brabez (ports)

13

New committer: Pawel Pekala (ports)

10

The FreeBSD Ports Management Team is pleased to announce Thomas Abthorpe as a full voting member.

5

New committer: Steven G. Kargl (src)

2 24 FreeBSD 8.2-RELEASE Available

FreeBSD 8.2-RELEASE is now available. Please be sure to check the Release Notes and Release Errata before installation for any late-breaking news and/or issues with 8.2. More information about FreeBSD releases can be found on the Release Information page.

FreeBSD 7.4-RELEASE Available

FreeBSD 7.4-RELEASE is now available. Please be sure to check the Release Notes and Release Errata before installation for any late-breaking news and/or issues with 7.4. More information about FreeBSD releases can be found on the Release Information page.

18

Enhanced commit privileges: Martin Wilke (src, ports, doc)

3 &os; 7.4/8.2-RC3 Available

The third (and probably last) Release Candidate builds for the &os;-7.4/8.2 release cycles are now available. For 8.2-RC3 the amd64, i386, ia64, pc98, powerpc, and sparc64 architectures are available. For 7.4-RC3 the amd64, i386, pc98, and sparc64 architectures are available. ISO images for these architectures can be downloaded from most of the &os; mirror sites. Please see the official announcement for further details about these releases.

1 25 October-December, 2010 Status Report

The October-December, 2010 Status Report is now available with 37 entries.

23 &os; 7.4-RC2 Available

The second Release Candidate build for the &os;-7.4 release cycle is now available. ISO images for Tier-1 architectures can be downloaded from most of the &os; mirror sites. Please see the official announcement for further details about this release.

16 &os; 8.2-RC2 Available

The second Release Candidate build for the &os;-8.2 release cycle is now available. ISO images for Tier-1 architectures can be downloaded from most of the &os; mirror sites. Please see the official announcement for further details about this release.

2010 12 27 &os; 7.4/8.2-RC1 Available

The first Release Candidate builds for the &os;-7.4/8.2 release cycles are now available. ISO images for Tier-1 architectures can be downloaded from most of the &os; mirror sites. Please see the official announcement for further details about these releases.

16 &os; Foundation December 2010 Newsletter

The &os; Foundation has published their End-of-Year newsletter which summarizes what they have done in 2010 to help the &os; Project and community.

11 &os; 7.4/8.2-BETA1 Available

The first of the test builds for the &os;-7.4/8.2 release cycles is now available. ISO images for Tier-1 architectures are now available on most of the &os; mirror sites.

7

New committer: Florian Smeets (ports)

11 15

New committer: Eygene Ryabinkin (ports)

5

New committer: Zack Kirsch (src)

10 27 July-September, 2010 Status Report

The July-September, 2010 Status Report is now available with 55 entries.

16

New committer: Frederic Culot (ports)

7

New committer: Jonathan Anderson (src)

5

New committer: Sergey Kandaurov (src)

9 25

New committer: Ganael Laplanche (ports)

21

New committer: Po-Chuan Hsieh (ports)

5

New committer: Andreas Tobler (src)

3

New committer: Steve Wills (ports)

8 31

New committer: Glen Barber (full doc/www)

30

New committer: Dimitry Andric (src)

1

New committer: Oliver Hauer (ports)

7 27 &os; Foundation July 2010 Newsletter

The &os; Foundation has published their Semi-Annual July 2010 newsletter which summarizes what they have done to help the &os; Project and community.

New committer: Baptiste Daroussin (ports)

23 FreeBSD 8.1-RELEASE Available

FreeBSD 8.1-RELEASE is now available. Please be sure to check the Release Notes and Release Errata before installation for any late-breaking news and/or issues with 8.1. More information about FreeBSD releases can be found on the Release Information page.

22 April-June, 2010 Status Report

The April-June, 2010 Status Report is now available with 47 entries.

21

New committer: Andrew Turner (src)

20 PC-BSD 8.1 Released

PC-BSD 8.1 has been released. PC-BSD is a successful desktop operating system based on FreeBSD that focuses on providing an easy to use desktop system for casual computer users. A list of new features/updates since the last version can be found here.

The new release can be downloaded or purchased on DVD.

17

New committer: Tijl Coosemans (src)

15

New committer: Joseph S. Atkinson (ports)

14 New &os; Core Team elected

The &os; Project is pleased to announce the completion of the 2010 Core Team election. The &os; Core Team acts as the project's "board of directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, etc ...), and making any other administrative or policy decisions as needed. The Core Team has been elected by &os; developers every 2 years since 2000.

More information about the election (together with a list of the new members of the Core Team) can be found in the official announcement.

2 &os; 8.1-RC2 available

The second (and most likely final) Release Candidate build for the &os;-8.1 release cycle is now available. CD ISO images for the amd64, i386, ia64, powerpc, and sparc64 architectures can be downloaded from most of the &os; mirror sites. Please see the official announcement for further details about this release.

6 18 &os; 8.1-RC1 Available

The first Release Candidate build for the &os;-8.1 release cycle is now available. ISO images for Tier-1 architectures can be downloaded from most of the &os; mirror sites. Please see the official announcement for further details about this release.

10

New committer: Ashish SHUKLA (ports)

9

New committer: Brendan Fabeny (ports)

4

New committer: Matthew Fleming (src)

3

New committer: Andrey V. Elsukov (src)

New committer: Taras Korenko (doc/ru, www/ru)

5 29 &os; 8.1-BETA1 Available

The first of the test builds for the &os;-8.1 release cycle is now available. ISO images for Tier-1 architectures are now available on most of the &os; mirror sites.

24 Google Summer of Code Projects started

The FreeBSD Project again received many high quality applications from students participating in Google's Summer of Code program. This year 18 student proposals to work with the FreeBSD Project were accepted as part of this program. For those with projects that were not accepted this year, we'd like to note that the FreeBSD Project is always willing to help mentor students so they can learn more about operating system development through our normal community mailing lists and development forums.

Please read the official announcement for more information. The complete list of student projects selected for funding can be found in the FreeBSD Summer of Code wiki. Coding started on May 24, so please join us in welcoming the 18 new students to our community.

19

New committer: Jayachandran C. (src)

4 29

Enhanced commit privileges: Martin Matuška (src, ports)

22 January-March, 2010 Status Report

The January-March, 2010 Status Report is now available with 46 entries.

20

New committer: Randi Harper (src)

19

New committer: Ryan Stone (src)

14

New committer: Ana Kukec (src)

11

Enhanced commit privileges: René Ladan (doc-nl, ports)

New committer: Sahil Tandon (ports)

5

New committer: Giuseppe Pilichi (ports)

4 The &os; Project Participates in the Google Summer of Code 2010 Program

&os; Project is participating in Google's Summer of Code programme for a sixth year. Undergraduate and graduate students are invited to apply for a grant to spend the summer improving the &os; operating system! More information available on the &os; Summer of code page, including a poster to hang up at a university near you!

3 31

New committer: Bernhard Fröhlich (ports)

23 FreeBSD 7.3-RELEASE Available

FreeBSD 7.3-RELEASE is now available. Please be sure to check the Release Notes and Release Errata before installation for any late-breaking news and/or issues with 7.3. More information about FreeBSD releases can be found on the Release Information page.

18 New Ports Management Team Secretary: <a href="mailto:tabthorpe@FreeBSD.org">Thomas Abthorpe</a>

The &os; Ports Management Team is pleased to announce Thomas Abthorpe has assumed the role of Ports Management Team Secretary.

7

Returning committer: Niels Heinen (ports)

4 &os; 7.3-RC2 Available

The second Release Candidate build for the &os;-7.3 release cycle is now available. ISO images for Tier-1 architectures are now available on most of the &os; mirror sites.

3

New committer: Neel Natu (src)

2 22 PC-BSD 8.0 Released

PC-BSD 8.0 has been released. PC-BSD is a successful desktop operating system based on FreeBSD that focuses on providing an easy to use desktop system for casual computer users. A list of new features/updates since the last version can be found here.

The new release can be downloaded or purchased on DVD.

15 &os; 7.3-RC1 Available

The first Release Candidate build for the &os;-7.3 release cycle is now available. ISO images for Tier-1 architectures are now available on most of the &os; mirror sites.

12

Enhanced commit privileges: Benedict Reuschling (full doc/www)

6

New committer: Bernhard Schmidt (src)

2 Enhanced commit privileges: <a href="mailto:gabor@FreeBSD.org">Gábor Kövesdán</a> (src, ports, doc)

Gábor Kövesdán participated in Google Summer of Code 2008/2009 and for his work he has been given commit access to the source code. His first pieces of work will be bringing in the result of his summer work into the tree.

1 30 &os; 7.3-BETA1 Available

The first BETA build for the &os;-7.3 release cycle is now available. ISO images for Tier-1 architectures are now available on most of the &os; mirror sites.

29

New committer: Bruce Cran (src)

28

New committer: Ulrich Spörlein (src)

26

New committer: Romain Tartière (ports)

New committer: Alberto Villa (ports)

17 October-December, 2009 Status Report

The October-December, 2009 Status Report is now available with 38 entries.

diff --git a/share/xml/release.ent b/share/xml/release.ent index 78372ec9cc..f68f3e7762 100644 --- a/share/xml/release.ent +++ b/share/xml/release.ent @@ -1,86 +1,86 @@ - + diff --git a/share/xsl/freebsd-common.xsl b/share/xsl/freebsd-common.xsl index c6e32d8cce..6421c6b2a9 100644 --- a/share/xsl/freebsd-common.xsl +++ b/share/xsl/freebsd-common.xsl @@ -1,139 +1,141 @@ png . : , . + + 30