Index: head/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.xml (revision 49284) +++ head/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.xml (revision 49285) @@ -1,2427 +1,2434 @@ &os; aktualisieren JimMockUmstrukturiert und aktualisiert von JordanHubbardIm Original von Poul-HenningKamp JohnPolstra NikClayton MartinHeinenÜbersetzt von Übersicht &os; wird zwischen einzelnen Releases ständig weiter entwickelt. Manche Leute bevorzugen die offiziellen Release-Versionen, während andere wiederum lieber auf dem aktuellen Stand der Entwicklung bleiben möchten. Wie dem auch sei, sogar offizielle Release-Versionen werden oft mit Sicherheitsaktualisierungen und anderen kritischen Fehlerbereinigungen versorgt. Unabhängig von der eingesetzten Version bringt &os; alle nötigen Werkzeuge mit, um das System aktuell zu halten und es innerhalb verschiedener Versionen zu aktualisieren. Dieses Kapitel beschreibt, wie man einem Entwicklungssystem folgen kann, sowie die grundlegenden Werkzeuge um &os; zu aktualisieren. Nachdem Sie dieses Kapitel gelesen haben, werden Sie wissen, wie das System mit freebsd-update oder Subversion aktualisiert wird. wissen, wie man das aktuell installierte System mit einer ursprünglichen Version vergleicht. wissen, wie die installierte Dokumentation mit Subversion oder Dokumentations-Ports aktualisiert wird. den Unterschied zwischen den beiden Entwicklungszweigen &os.stable; und &os.current; kennen. wissen, wie das komplette Basissystem neu gebaut und installiert wird. Bevor Sie dieses Kapitel lesen, sollten Sie das Netzwerk richtig konfiguriert haben (). wissen, wie Software Dritter installiert wird (). In diesem Kapitel wird svn verwendet, um die &os; Quellen zu beziehen und zu aktualisieren. Um es zu verwenden, muss zuerst der Port oder das Paket devel/subversion installiert werden. &os;-Update TomRhodesGeschrieben von ColinPercivalBasierend auf bereitgestellten Mitschriften von BenedictReuschlingÜbersetzt von Updating and Upgrading freebsd-update updating-upgrading Das zeitnahe Einspielen von Sicherheitsaktualisierungen und die Aktualisierung des Betriebssystems sind wichtige Aspekte der Systemadministration. &os; enthält das Werkzeug freebsd-update, mit dem Sie diese beiden Aufgaben erfüllen können. Dieses Werkzeug ermöglicht die Anwendung von Sicherheitsaktualisierungen im Binärformat auf das &os; Basissystem, ohne dieses neu zu übersetzen und zu installieren. Die Aktualisierungen im Binärformat sind für alle Architekturen und Versionen verfügbar, welche vom &os; Sicherheitsteam unterstützt werden. Eine Liste der unterstützten Versionen und der End-of-Life-Daten ist unter http://www.FreeBSD.org/security/ aufgeführt. freebsd-update unterstützt auch die Aktualisierung des Betriebssystems auf eine neuere Unterversion sowie eine Aktualisierung auf einen anderen Release-Zweig. Bevor Sie auf eine neue Version aktualisieren, sollten Sie die aktuellen Ankündigungen zu dem Release gelesen haben, da diese wichtige Informationen zu dem entsprechenden Release enthalten. Ankündigungen finden Sie unter http://www.FreeBSD.org/releases/. Wenn eine crontab existiert, welche die Eigenschaften von &man.freebsd-update.8; verwendet, muss diese deaktiviert werden, bevor das Betriebssystem aktualisiert wird. Dieser Abschnitt beschreibt die Verwendung der Konfigurationsdatei von freebsd-update. Es wird gezeigt wie Sie Sicherheitsaktualisierungen einspielen, oder wie Sie das Betriebssystem auf neuere Haupt- und Unterversionen aktualisieren können. Die Konfigurationsdatei In der Regel muss die Konfigurationsdatei von freebsd-update nicht bearbeitet werden. Manche Benutzer möchten die Standard-Konfigurationsdatei /etc/freebsd-update.conf trotzdem anpassen, um bessere Kontrolle über den gesamten Prozess zu besitzen. Die Kommentare in dieser Datei beschreiben die verfügbaren Optionen, jedoch benötigen die folgenden ein paar zusätzliche Erklärungen: # Components of the base system which should be kept updated. Components world kernel Dieser Parameter kontrolliert, welche Teile von &os; auf dem aktuellen Stand gehalten werden sollen. In der Voreinstellung wird das gesamte Basissystem sowie der Kernel aktualisiert. Es können auch einzelne Komponenten, wie src/base oder src/sys, angegeben werden. Die beste Einstellung ist, diese Option so zu belassen, da eine Änderung es bedingt, dass man als Benutzer jede Komponente auflisten muss, die aktualisiert werden soll. Dies könnte katastrophale Folgen nach sich ziehen, da der Quellcode und die Binärdateien dadurch nicht mehr synchron wären. # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /boot/kernel/linker.hints Fügen Sie Pfade wie /bin oder /sbin hinzu, um diese speziellen Verzeichnisse während des Aktualisierungsprozesses unberührt zu lassen. Diese Option kann verwendet werden, um zu verhindern, dass freebsd-update lokale Änderungen überschreibt. # 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 Diese Option aktualisiert nur unmodifizierte Konfigurationsdateien in den angegebenen Verzeichnissen. Jede Änderung, die der Benutzer daran vorgenommen hat, wird die automatische Aktualisierung dieser Dateien verhindern. Es gibt eine weitere Option KeepModifiedMetadata, die freebsd-update instruiert, die Änderungen während der Zusammenführung zu speichern. # 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/ /boot/device.hints Eine Liste von Verzeichnissen mit Konfigurationsdateien, in denen freebsd-update Zusammenführungen versuchen soll. Dieser Verschmelzungsprozess von Dateien ist eine Serie von &man.diff.1;-Korrekturen, ähnlich wie &man.mergemaster.8;, aber mit weniger Optionen. Die Änderungen werden entweder akzeptiert, oder öffnen einen Editor, oder freebsd-update bricht ab. Im Zweifelsfall sichern Sie /etc und akzeptieren einfach die Änderungen. Lesen Sie , um Informationen über mergemaster zu erhalten. # Directory in which to store downloaded updates and temporary # files used by &os; Update. # WorkDir /var/db/freebsd-update In diesem Verzeichnis werden alle Korrekturen und temporären Dateien abgelegt. Im Falle einer Versionsaktualisierung sollte diesem Verzeichnis mindestens ein Gigabyte Festplattenspeicher zur Verfügung stehen. # 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 Wenn diese Option auf yes gesetzt ist, wird freebsd-update annehmen, dass die Components-Liste vollständig ist und nicht versuchen, Änderungen ausserhalb dieser Liste zu tätigen. Tatsächlich wird freebsd-update versuchen, jede Datei zu aktualisieren, die zu der Components-Liste gehört. - Sicherheitsaktualisierungen + Sicherheitskorrekturen anwenden - Sicherheitsaktualisierungen für &os; können wie folgt - heruntergeladen und installiert werden: + Das Einspielen von &os; Sicherheitskorrekturen wurde + dahingehend vereinfacht, dass der Administrator nun das + gesamte System mit freebsd-update auf + dem aktuellen Stand halten kann. Weitere Informationen zu + &os; Sicherheitshinweisen finden Sie in . + Sicherheitskorrekturen für &os; können wie folgt + heruntergeladen und installiert werden. Das erste + Kommando prüft, ob noch ausstehende Korrekturen verfügbar + sind, und wenn dass der Fall ist, zeigt es welche Dateien + davon betroffen wären. Das zweite Kommando wird die + Korrekturen auf das System anwenden. + &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install - Wenn während Aktualisierung Korrekturen am Kernel + Wenn während der Aktualisierung Korrekturen am Kernel angewendet werden, muss das System neu gestartet werden, damit - der korrigierte Kernel gebootet wird. Andernfalls sollte das - System aktualisiert sein und freebsd-update - kann als nächtlicher &man.cron.8;-Job laufen, indem folgender - Eintrag in /etc/crontab hinzugefügt - wird: + der korrigierte Kernel gebootet wird. Wenn die Korrekturen + auf laufende Binärdateien angewendet werden, sollten die + betroffenen Anwendungen neu gestartet werden, damit die + korrigierte Version der Binärdatei geladen wird. + + Mit dem folgenden Eintrag in + /etc/crontab wird das System einmal + täglich nach Aktualisierungen suchen: @daily root freebsd-update cron - Dieser Eintrag besagt, dass - freebsd-update einmal am Tag ausgeführt - wird. Wenn es über ausgeführt wird, - prüft freebsd-update lediglich, ob - Aktualisierungen vorliegen. Wenn Korrekturen existieren, - werden diese automatisch auf die lokale Festplatte + Wenn Korrekturen existieren, werden diese automatisch heruntergeladen, aber nicht eingespielt. Der root-Benutzer bekommt eine - Nachricht, damit die Korrekturen überprüft und manuell - installiert werden können. + Nachricht, damit die Korrekturen überprüft und mit + freebsd-update install manuell installiert + werden können. Wenn etwas schief geht, kann freebsd-update den letzten Satz von Änderungen mit folgendem Befehl rückgängig machen: - &prompt.root; freebsd-update rollback + &prompt.root; freebsd-update rollback +Uninstalling updates... done. - Sobald dieser Vorgang abgeschlossen ist, sollte das System neu - gestartet werden, wenn der Kernel oder ein beliebiges Kernelmodul - geändert wurde. Dies ermöglicht es &os;, die neuen - Binärdateien in den Hauptspeicher zu laden. + Wie bereits erwähnt, sollte das System neu gestartet + werden, wenn der Kernel oder ein Kernelmodul verändert wurde. + Betroffene Anwendungen sollten neu gestartet werden, wenn + Binärdateien verändert wurden. Das freebsd-update-Werkzeug kann nur den GENERIC-Kernel automatisch aktualisieren. Wenn ein angepasster Kernel verwendet wird, muss dieser neu erstellt und installiert werden, nachdem - freebsd-update den Rest der Aktualisierungen + freebsd-update die Aktualisierungen durchgeführt hat. Allerdings wird freebsd-update den GENERIC-Kernel in /boot/GENERIC erkennen und aktualisieren, selbst wenn dies nicht der aktuell verwendete Kernel des Systems ist. Es ist eine gute Idee, immer eine Kopie des GENERIC-Kernels in /boot/GENERIC aufzubewahren. Das wird bei der Diagnose von verschiedenen Problemen eine grosse Hilfe sein, sowie bei der Durchführung von Versionsaktualisierungen mit freebsd-update, wie in beschrieben ist. Solange die Standardkonfiguration in /etc/freebsd-update.conf nicht geändert wurde, wird freebsd-update die aktualisierten Quellcodedateien des Kernels zusammen mit dem Rest der Neuerungen installieren. Die erneute Übersetzung und Installation eines neuen, angepassten Kernels kann dann auf die übliche Art und Weise durchgeführt werden. - Die Aktualisierungen, die über freebsd-update verteilt werden, betreffen nicht immer den Kernel. Es ist nicht notwendig, den angepassten - Kernel neu zu erstellen, wenn die Kernelquellen nicht durch die - Ausführung von freebsd-update install + Kernel neu zu erstellen, wenn die Kernelquellen nicht durch + freebsd-update install geändert wurden. Allerdings wird freebsd-update immer /usr/src/sys/conf/newvers.sh aktualisieren. Der aktuelle Patch-Level, der mit der -p-Nummer bei uname -r ausgegeben wird, wird aus dieser Datei ausgelesen. Die Neuinstallation des angepassten Kernels, selbst wenn - sich daran nichts geändert hat, erlaubt es &man.uname.1;, den + sich daran nichts geändert hat, erlaubt es uname, den aktuellen Patch-Level des Systems korrekt wiederzugeben. Dies ist besonders hilfreich, wenn mehrere Systeme gewartet werden, da es eine schnelle Einschätzung der installierten Aktualisierungen in jedem einzelnen System ermöglicht. - Aktualisierungen an Haupt- und Unterversionen Aktualisierungen einer Unterversion zur nächsten in &os; ist beispielsweise die Aktualisierung von &os; 9.0 auf &os; 9.1. In der Regel funktionieren die installierten Anwendungen weiterhin problemlos nach der Aktualisierung einer Unterversion. Eine Aktualisierung der Hauptversion ist besipielsweise - die Aktualisierung von &os; 8.X auf &os; 9.X. - Dieser Prozess entfernt alte Objekt-Dateien und Bibliotheken, - was dazu führt, dass die meisten Anwendungen von - Drittherstellern nicht mehr funktionieren. Nach der - Aktualisierung auf eine neue Hauptversion wird empfohlen, dass - alle installierten Ports entweder entfernt und neu - installiert werden, oder mit einem Werkzeug wie - ports-mgmt/portmaster aktualisiert werden. - Um die Neuerstellung aller installierten Anwendungen zu - erwzingen, benutzen Sie folgenden Befehl: + die Aktualisierung von &os; 9.X auf &os; 10.X. + Neue Hauptversionen verwenden andere Binärschnittstellen + (ABIs), was dazu führt, dass die meisten + Anwendungen von Drittherstellern nicht mehr funktionieren. + Nach der Aktualisierung auf eine neue Hauptversion müssen alle + installierten Ports neu installiert werden. Dazu kann + beispielsweise ports-mgmt/portmaster + benutzt werden. Benutzen Sie den folgenden Befehl, um alle + installierten Anwendungen neu zu installieren: &prompt.root; portmaster -af - Dies sorgt dafür, dass alles korrekt neu installiert wird. - Beachten Sie, dass das Setzen der - BATCH-Umgebungsvariable auf yes - während dieses Prozesses auf jede Eingabe mit - ja antwortet, was es nicht mehr notwendig macht, - manuell eingreifen zu müssen. + Dieser Befehl wird die Konfigurationen für jede Anwendung + anzeigen, und der Benutzer hat die Möglichkeit, die Optionen + anzupassen. Wenn Sie ausschließlich die voreingestellten + Optionen verwenden möchten, verwenden Sie mit dem obigen + Befehl den Parameter . Umgang mit angepassten Kerneln Wenn ein angepasster Kernel verwendet wird, ist der Aktualisierungsprozess ein wenig aufwändiger und das Vorgehen variiert je nach Version von &os;. Angepasste Kernel unter &os; 8.X Eine Kopie des GENERIC-Kernel wird benötigt und sollte in /boot/GENERIC abgelegt sein. Wenn der GENERIC-Kernel nicht im System vorhanden ist, kann er über eine der folgenden Methoden bezogen werden: Wenn ein angepasster Kernel erstmalig gebaut wurde, ist der Kernel in /boot/kernel.old in Wirklichkeit der GENERIC-Kernel. Benennen Sie dieses Verzeichnis in /boot/GENERIC um. Angenommen, ein direkter Zugriff auf die Maschine ist möglich, so kann eine Kopie des GENERIC-Kernels von den Installationsmedien installiert werden. Benutzen Sie dazu folgende Befehle: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC Ersetzen Sie X.Y-RELEASE durch die aktuelle Version des verwendeten Releases. Der GENERIC-Kernel wird standardmäßig in /boot/GENERIC installiert. Falls alle obigen Schritte fehlschlagen, kann der GENERIC-Kernel folgendermaßen aus den Quellen neu gebaut und installiert werden: &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 Damit dieser Kernel als GENERIC-Kernel von freebsd-update erkannt wird, darf die GENERIC-Konfigurationsdatei in keiner Weise geändert worden sein. Es wird ebenfalls empfohlen, dass dieser ohne irgendwelche speziellen Optionen erstellt wird. Der Neustart in den GENERIC-Kernel ist zu diesem Zeitpunkt nicht notwendig. Angepasste Kernel unter &os; 9.X und später Wenn ein angepasster Kernel erstmalig gebaut wurde, ist der Kernel in /boot/kernel.old in Wirklichkeit der GENERIC-Kernel. Benennen Sie einfach dieses Verzeichnis in /boot/GENERIC um. Angenommen, ein direkter Zugriff auf die Maschine ist möglich, so kann eine Kopie des GENERIC-Kernels von den Installationsmedien installiert werden. Benutzen Sie dazu folgende Befehle: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/usr/freebsd-dist &prompt.root; tar -C/ -xvf kernel.txz boot/kernel/kernel Wenn die oben genannten Optionen nicht verwendet werden können, kann der GENERIC-Kernel aus den Quellen neu gebaut und installiert werden: &prompt.root; cd /usr/src &prompt.root; make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null Damit dieser Kernel als GENERIC-Kernel von freebsd-update erkannt wird, darf die GENERIC-Konfigurationsdatei in keiner Weise geändert worden sein. Es wird ebenfalls empfohlen, dass dieser ohne irgendwelche speziellen Optionen erstellt wird. Der Neustart in den GENERIC-Kernel ist zu diesem Zeitpunkt nicht notwendig. Die Aktualisierung durchführen Aktualisierungen an Haupt- und Unterversionen können durchgeführt werden, wenn man freebsd-update eine Release-Version als Ziel übergibt. Beispielsweise wird das folgende Kommando das System auf &os; 9.1 aktualisieren: &prompt.root; freebsd-update -r 9.1-RELEASE upgrade Nachdem das Kommando empfangen wurde, überprüft freebsd-update die Konfigurationsdatei und das aktuelle System, um die nötigen Informationen für die Systemaktualisierung zu sammeln. Eine Bildschirmausgabe wird anzeigen, welche Komponenten erkannt und welche nicht erkannt wurden. Zum Beispiel: 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 An diesem Punkt wird freebsd-update versuchen, alle notwendigen Dateien für die Aktualisierung herunter zu laden. In manchen Fällen wird der Benutzer mit Fragen konfrontiert, um festzustellen, was installiert werden soll oder auf welche Art und Weise fortgesetzt werden soll. Wenn ein angepasster Kernel benutzt wird, produziert der vorherige Schritt eine Warnung ähnlich zu der folgenden: 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" Diese Warnung kann an dieser Stelle problemlos ignoriert werden. Der aktualisierte GENERIC-Kernel wird als ein Zwischenschritt im Aktualisierungsprozess verwendet. Nachdem alle Korrekturen auf das lokale System heruntergeladen wurden, werden diese eingespielt. Dieser Prozess kann eine gewisse Zeit in Anspruch nehmen, abhängig von der Geschwindigkeit und Auslastung der Maschine. Konfigurationsdateien werden ebenfalls zusammengefügt. Dieser Teil der Prozedur verlangt einige Benutzereingaben, da eine Datei möglicherweise von Hand zusammengefasst werden muss oder ein Editor erscheint auf dem Bildschirm zum manuellen bearbeiten. Die Ergebnisse von jeder erfolgreichen Zusammenfassung werden dem Benutzer angezeigt, während der Prozess weiter läuft. Eine fehlgeschlagene oder ignorierte Zusammenfassung wird den Prozess sofort beenden. Benutzer sollten eine Sicherung von /etc anlegen und wichtige Dateien später manuell vereinen, beispielsweise master.passwd oder group. Das System ist zu diesem Zeitpunkt noch nicht verändert worden, da alle Korrekturen und Vereinigungen in einem anderen Verzeichnis vorgenommen wurden. Wenn alle Korrekturen erfolgreich eingespielt, alle Konfigurationsdateien zusammengefügt wurden und es den Anschein hat, dass der Prozess problemlos verlaufen wird, müssen die Änderungen vom Anwender noch angewendet und auf die Platte geschrieben werden: &prompt.root; freebsd-update install Der Kernel und die Module werden zuerst aktualisiert. Zu diesem Zeitpunkt muss die Maschine neu gestartet werden. Wenn das System einen angepassten Kernel verwendet, benutzen Sie &man.nextboot.8;, um den Kernel für den nächsten Neustart auf /boot/GENERIC zu setzen: &prompt.root; nextboot -k GENERIC Bevor das System mit dem GENERIC-Kernel neu gestartet wird, vergewissern Sie sich, dass für den Neustart alle benötigten Treiber enthalten sind. Falls auf die Maschine aus der Ferne zugegriffen wird, stellen Sie sicher, dass das System ordnungsgemäß an das Netzwerk angeschlossen ist. Achten Sie besonders darauf, dass wenn der angepasste Kernel Funktionalität beinhaltet, die normalerweise von Kernelmodulen zur Verfügung gestellt werden, dass diese temporär über /boot/loader.conf in den GENERIC-Kernel übernommen werden. Zudem wird empfohlen, nicht benötigte Dienste, eingehängte Platten und verbundene Netzlaufwerke zu deaktivieren, bis der Aktualisierungsprozess abgeschlossen ist. Die Maschine sollte nun mit dem aktualisierten Kernel neu gestartet werden: &prompt.root; shutdown -r now Sobald das System wieder online ist, muss freebsd-update erneut gestartet werden. Der Zustand des Prozesses wurde zuvor gesichert und deshalb wird freebsd-update nicht von vorne beginnen, jedoch alle alten gemeinsam genutzten Bibliotheken und Objektdateien löschen. &prompt.root; freebsd-update install Abhängig davon, ob irgendwelche Bibliotheksversionen erhöht wurden, kann es sein, dass nur zwei Installationsphasen anstatt drei durchlaufen werden. Neubau der Ports nach einer Aktualisierung auf eine Hauptversion Nach der Aktualisierung auf eine Hauptversion, muss jegliche Drittanbieter-Software neu erstellt und installiert werden. Dies ist notwendig, da die installierte Software möglicherweise Abhängigkeiten zu Bibliotheken enthält, die während der Aktualisierung entfernt wurden. Dieser Prozess kann mit einem Werkzeug wie ports-mgmt/portmaster automatisiert werden: &prompt.root; portmaster -f Sobald dies abgeschlossen ist, beenden Sie den Aktualisierungsprozess mit einem letzten Aufruf von freebsd-update. Geben Sie den folgenden Befehl ein, um alle losen Enden des Aktualisierungsprozesses miteinander zu verknüpfen: &prompt.root; freebsd-update install Wenn der GENERIC-Kernel temporär Verwendung fand, ist dies der richtige Zeitpunkt, einen neuen, angepassten Kernel zu bauen und über die übliche Methode zu installieren. Booten Sie anschließend die Maschine in die neue &os;-Version. Der Prozess ist damit abgeschlossen. Vergleich des Systemzustands freebsd-update kann verwendet werden, um den Zustand der installierten &os;-Version gegenüber einer bekannten und funktionierenden Kopie zu vergleichen. Diese Option vergleicht die aktuelle Version von Systemwerkzeugen, Bibliotheken und Konfigurationsdateien. Um diesen Vergleich zu starten, geben Sie den folgenden Befehl ein: &prompt.root; freebsd-update IDS >> outfile.ids Obwohl der Befehlsname IDS lautet, ist dies kein Ersatz für ein echtes Intrusion Detection System wie security/snort. Da freebsd-update seine Daten auf Platte ablegt, ist die Möglichkeit von Verfälschungen offensichtlich. Obwohl diese Möglichkeit durch die Verwendung von kern.securelevel oder die Ablage von Daten auf einem Nur-Lese Dateisystem eingedämmt werden kann, besteht eine bessere Lösung darin, das System gegen ein gesichertes Medium, wie eine DVD oder einen externen, separat aufbewahrten USB-Plattenspeicher, zu vergleichen. Das System wird nun überprüft, und eine lange Liste von Dateien zusammen mit den &man.sha256.1;-Hashwerten, sowohl der von der Release-Version bekannte Wert als auch der des aktuell installierten Systems, in outfile.ids geschrieben. Die Zeilen in der Ausgabe sind extrem lang, aber das Ausgabeformat kann einfach verarbeitet werden. Um beispielsweise eine Liste von allen Dateien zu erhalten, die sich vom aktuellen Release unterscheiden, geben Sie das folgende Kommando ein: &prompt.root; cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf Diese Beispielausgabe wurde abgeschnitten, da noch viele weitere Dateien vorhanden sind. Einige Dateien wurden auf natürliche Art verändert. /etc/passwd wurde beispielsweise geändert, um Benutzer zum System hinzuzufügen. Andere Dateien, wie Kernelmodule, unterscheiden sich, weil freebsd-update diese aktualisiert hat. Um bestimmte Dateien oder Verzeichnisse auszuschließen, fügen Sie diese an die IDSIgnorePaths-Option in /etc/freebsd-update.conf an. Diese Vorgehensweise kann als Teil einer ausgeklügelten Aktualisierungsmethode benutzt werden, unabhängig von der zuvor angesprochenen Variante. Aktualisieren der Dokumentationssammlung BenedictReuschlingÜbersetzt von Updating and Upgrading Documentation Updating and Upgrading Dokumentation ein wichtiger Bestandteil des &os; Betriebssystems. Obwohl eine aktuelle Version der &os; Dokumentation jederzeit auf der &os; Webseite ( http://www.freebsd.org/doc/) verfügbar ist, kann es nützlich sein, eine lokale Kopie der &os; Webseite, Handbücher, FAQ und Artikel zu haben. Dieser Abschnitt beschreibt, wie Sie die &os; Dokumentation über die Quellen oder die &os; Ports-Sammlung aktuell halten. Informationen zum Bearbeiten und Einreichen von Korrekturen finden Sie in der Fibel für neue Mitarbeiter des &os;-Dokumentationsprojekts. Die &os;-Dokumentation aus den Quellen installieren Der Bau der &os; Dokumentation aus den Quellen erfordert einige Werkzeuge, die nicht Teil des Basissystems sind. Die erforderlichen Werkzeuge, darunter auch svn, können über den Port oder das Paket textproc/docproj installiert werden. Benutzen Sie nach der Installation svn, um eine saubere Kopie der Dokumentationsquellen zu holen: &prompt.root; svn checkout https://svn.FreeBSD.org/doc/head /usr/doc Es dauert eine Weile, bis die Quellen das allererste Mal heruntergeladen werden. Lassen Sie den Vorgang laufen, bis es fertig ist. Zukünftige Aktualisierungen der Dokumentationsquellen können wie folgt durchgeführt werden: &prompt.root; svn update /usr/doc Sobald ein aktueller Schnappschuss der Dokumentationsquellen nach /usr/doc heruntergeladen wurde, ist alles bereit für eine Aktualisierung der bestehenden Dokumentation. Eine komplette Aktualisierung aller Sprachen kann durch folgende Eingabe erreicht werden: &prompt.root; cd /usr/doc &prompt.root; make install clean Wenn nur eine Aktualisierung einer bestimmten Sprache gewünscht wird, kann make in einem sprachspezifischen Unterverzeichnis von /usr/doc aufgerufen werden: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make install clean Alternativ kann der folgende Befehl in /usr/doc oder einem sprachspezifischen Unterverzeichnis abgesetzt werden, um die Dokumentation zu aktualisieren: &prompt.root; make update Die zu installierenden Ausgabeformate können durch das Setzen von FORMATS angegeben werden: &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Es existieren ein paar Optionen, welche den Prozess der Aktualisierung von Teilen der Dokumentation oder einer bestimmten Übersetzung erleichtern. Diese Optionen können entweder systemweit in /etc/make.conf gesetzt, oder als Kommandozeilenoptionen an make übergeben werden. Zu den Optionen gehören: DOC_LANG Eine Liste von Sprachen und Kodierungen, die gebaut und installiert werden sollen, z.B. en_US.ISO8859-1, um nur die englische Dokumentation zu erhalten. FORMATS Ein einzelnes Format oder eine Liste von Ausgabeformaten, das gebaut werden soll. Momentan werden html, html-split, txt, ps und pdf unterstützt. DOCDIR Wohin die Dokumentation installiert werden soll. Der Standardpfad ist /usr/share/doc. Für weitere make-Variablen, die als systemweite Optionen in &os; unterstützt werden, lesen Sie &man.make.conf.5;. Die Dokumentation aus den Ports aktualisieren MarcFonvieilleBasierend auf der Arbeit von Updating and Upgrading documentation package Updating and Upgrading Im vorherigen Abschnitt wurde eine Methode gezeigt, wie die &os;-Dokumentation aus den Quellen gebaut werden kann. Dieser Abschnitt beschreibt eine alternative Methode, in der die Ports-Sammlung verwendet wird und die es ermöglicht: vorgefertigte Schnappschüsse der Dokumentation zu installieren, ohne vorher die Werkzeugsammlung der Dokumentation installieren zu müssen. die Dokumentationsquellen durch das Ports-System erstellen zu lassen, was die Schritte zum Auschecken und Erstellen etwas erleichtert. Diese Methoden der Aktualisierung der &os;-Dokumentation werden durch eine Menge von Dokumentations-Ports und Paketen unterstützt, die von &a.doceng; monatlich aktualisiert wird. Diese sind in der &os; Ports-Sammlung unter der Kategorie docs gelistet ( http://www.freshports.org/docs/). Die Dokumentations-Ports sind wie folgt organisiert: Das Paket oder der Port misc/freebsd-doc-en installiert die englische Dokumentation. Das Paket oder der Port misc/freebsd-doc-all installiert die komplette Dokumentation in allen verfügbaren Sprachen. Es gibt noch ein Paket oder einen Port für jede Übersetzung, beispielsweise misc/freebsd-doc-hu für die ungarische Dokumentation. Wenn Sie Pakete benutzen, wird die &os;-Dokumentation in allen verfügbaren Formaten der jeweiligen Sprache installiert. Das folgende Beispiel wird das aktuelle Paket der ungarischen Dokumentation installieren: &prompt.root; pkg install hu-freebsd-doc Pakete verwenden ein Format, welches sich von dem Namen des dazugehörigen Ports unterscheidet: lang-freebsd-doc. lang entspricht hier der Kurzform des Sprachcodes, z.B. hu für Ungarisch, oder zh_cn für vereinfachtes Chinesisch. Um das Format der Dokumentation zu bestimmen, muss anstelle des Pakets der Port gebaut werden. Das folgende Beispiel baut und installiert die englische Dokumentation: &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean Der Port enthält ein Konfigurationsmenü, in dem das Format ausgewählt werden kann. In der Voreinstellung sind html-split und pdf ausgewählt. Alternativ können bei der Erstellung eines Dokumentations-Ports verschiedene make-Optionen angegeben werden. Dazu gehören: WITH_HTML Erstellt das HTML-Format mit einer einzigen HTML-Datei pro Dokument. Die formatierte Dokumentation wird als Datei mit dem Namen article.html oder book.html gespeichert. WITH_PDF Die formatierte Dokumentation wird als Datei mit dem Namen article.pdf oder book.pdf gespeichert. DOCBASE Legt den Pfad fest, wohin die Dokumentation installiert werden soll. Die Voreinstellung ist /usr/local/share/doc/freebsd. Dieses Beispiel verwendet Variablen, um die ungarische Dokumentation als PDF in ein bestimmtes Verzeichnis zu installieren: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean Dokumentations-Ports oder -Pakete können nach den Anweisungen in aktualisiert werden. Beispielsweise aktualisiert das folgende Kommando die installierte ungarische Dokumentation mittels ports-mgmt/portmaster unter Verwendung von Paketen: &prompt.root; portmaster -PP hu-freebsd-doc Einem Entwicklungszweig folgen -CURRENT -STABLE &os; besitzt zwei Entwicklungszweige: &os.current; und &os.stable;. Dieser Abschnitt beschreibt beide Zweige sowie deren Interessengruppen und erläutert, wie ein System auf dem aktuellen Stand eines jeweiligen Zweiges gehalten wird. &os.current; &os.current; ist die allerneueste Entwicklung von &os;. Benutzer von &os.current; sollten über sehr gute technische Fähigkeiten verfügen. Benutzer mit weniger technischen Fähigkeiten sollten stattdessen &os.stable; benutzen, wenn sie einem Entwicklungszweig folgen möchten. &os.current; besteht aus den neuesten Quellen des &os;-Systems und enthält Sachen, an denen gerade gearbeitet wird, experimentelle Änderungen und Übergangsmechanismen, die im nächsten offiziellen Release enthalten sein können oder nicht. Obwohl &os.current; täglich von vielen Entwicklern gebaut wird, gibt es Zeiträume, in denen sich das System vielleicht nicht bauen lässt. Diese Probleme werden so schnell wie möglich behoben, aber ob Sie mit &os.current; eine Katastrophe erleben oder neue Funktionen erhalten, kann von dem Zeitpunkt abhängen, an dem der Quelltext synchronisiert wurde. &os.current; wird hauptsächlich für drei Interessengruppen zur Verfügung gestellt: Mitglieder der &os; Gemeinschaft, die aktiv an einem Teil des Quellbaums arbeiten. Mitglieder der &os; Gemeinschaft, die aktive Tester sind. Diese Personen sind bereit, Zeit in das Lösen von Problemen zu investieren, Vorschläge zu Änderungen oder der generellen Entwicklung von &os; zu machen und Fehlerkorrekturen einzureichen. Benutzer, die die Entwicklung im Auge behalten wollen, oder die Quellen zu Referenzzwecken benutzen wollen. Diese Gruppe macht auch Vorschläge oder steuert Quellcode bei. &os.current; ist nicht der schnellste Weg, neue Funktionen vor dem offiziellen Release auszuprobieren. Bedenken Sie, dass neue Funktionen noch nicht im vollen Umfang getestet wurden und daher höchstwahrscheinlich Fehler enthalten. Es ist auch nicht der schnellste Weg, um an Fehlerbehebungen (engl. bug fixes) zu kommen. Jede Fehlerbehebung führt mit gleicher Wahrscheinlichkeit neue Fehler ein, mit der sie alte behebt. &os.current; wird in keiner Weise offiziell unterstützt. -CURRENT benutzen Um &os.current; zu folgen: Lesen Sie die Mailinglisten &a.current.name; und &a.svn-src-head.name;. Dies ist notwendig, um die Kommentare über den akutellen Status des Systems und wichtige Mitteilungen zum aktuellen Zustand von &os.current; zu erfahren. Die &a.svn-src-head.name; Mailingliste erfasst die Commit-Logs für jede Änderung und enthält alle relevanten Informationen zu möglichen Seiteneffekten. Um diese Listen zu abonnieren, besuchen Sie &a.mailman.lists.link;, klicken Sie auf die gewünschte Liste und folgen Sie den Anweisungen. Wenn Sie die Änderungen am gesamten Quellbaum verfolgen möchten, abonnieren Sie die &a.svn-src-all.name; Liste. Synchronisieren Sie die Quellen für &os.current;. In der Regel wird svn benutzt, um die Quellen für -CURRENT aus dem Zweig head zu laden. Verwenden Sie dazu einen Subversion Spiegel aus . Aufgrund der Größe des Repositories ist es empfehlenswert, nur die gewünschten Teilbäume auszuchecken. Wenn Sie die Quellen einsetzen und nicht nur darin lesen wollen, laden Sie sich die kompletten Quellen von &os.current; und nicht nur ausgesuchte Teile. Lesen Sie /usr/src/Makefile sehr aufmerksam und folgen Sie den Anweisungen in . Lesen Sie die Mailingliste &a.current; und /usr/src/UPDATING, um über Änderungen im Installationsverfahren, die manchmal vor der Einführung eines neuen Releases notwendig sind, informiert zu sein. Seien Sie aktiv! Benutzer von &os.current; werden aufgefordert ihre Verbesserungsvorschläge oder Fehlerbehebungen einzureichen. Verbesserungsvorschläge, die Code enthalten, sind jederzeit herzlich willkommen. &os.stable; &os.stable; ist der Entwicklungszweig, auf dem Releases erstellt werden. Dieser Zweig ändert sich langsamer als &os.current; und alle Änderungen hier sollten zuvor in &os.current; ausgetestet sein. Beachten Sie, dass dies immer noch ein Entwicklungszweig ist und daher zu jedem Zeitpunkt die Quellen von &os.stable; verwendbar sein können oder nicht. &os.stable; ist Teil des Entwicklungsprozesses und nicht für Endanwender gedacht. Benutzer, die nicht über die notwendigen Ressourcen zum Testen verfügen, sollten stattdessen eine aktuelle Version von &os; verwenden. Wer daran interessiert ist den &os;-Entwicklungsprozess zu verfolgen oder dazu beizutragen, insbesondere im Hinblick auf das nächste Hauptversion, der sollte es in Erwägung ziehen, &os.stable; zu benutzen. Obwohl wir versuchen sicherzustellen, dass der &os.stable; Zweig sich jederzeit übersetzen lässt und lauffähig ist, können wir dafür keine Garantie übernehmen. Auch wenn Neuentwicklungen in &os.current; stattfinden, ist es jedoch so, dass mehr Leute &os.stable; anstelle von &os.current; benutzen und es daher unvermeidlich ist, dass Fehler und Grenzfälle erst in &os.stable; auffallen. Aus diesen Gründen empfehlen wir Ihnen nicht blindlings &os.stable; zu benutzen. Es ist besonders wichtig, dass &os.stable; zuerst sorgfältig in einer Testumgebung getestet wird, bevor die Produktion auf &os.stable; migriert. Um &os.stable; zu folgen: -STABLE benutzen Lesen Sie Mailingliste &a.stable.name;, damit Sie über Abhängigkeiten beim Bau von &os.stable; und Sachen, die besondere Aufmerksamkeit erfordern, informiert sind. Umstrittene Fehlerbehebungen oder Änderungen werden von den Entwicklern auf dieser Liste bekannt gegeben. Dies erlaubt es den Benutzern, Einwände gegen die vorgeschlagenen Änderungen vorzubringen. Abonnieren Sie die passende svn-Liste für den jeweiligen Branch, den Sie verfolgen. Wenn Sie beispielsweise den Zweig 9-STABLE verfolgen, lesen Sie die &a.svn-src-stable-9.name;. Diese Liste enthält zu jeder Änderung das Commit-Log, das Informationen zu möglichen Seiteneffekten enthält. Um diese Listen zu abonnieren, besuchen Sie die Seite &a.mailman.lists.link;. Klicken Sie auf die gewünschte Liste und folgenden Sie den Anweisungen. Wenn Sie daran interessiert sind, Änderungen am gesamten Quellbaum zu verfolgen, abonnieren Sie &a.svn-src-all.name;. Wenn Sie ein neues System installieren und dazu einen der monatlich aus &os.stable; erzeugten Snapshots verwenden wollen, sollten Sie zuerst www.freebsd.org/snapshots auf aktuelle Informationen überprüfen. Alternativ können Sie auch das neueste &os.stable;-Release von den &os; Spiegeln beziehen. Um ein bestehendes &os;-System auf &os.stable; zu aktualisieren, benutzen Sie svn, um den gewünschten Entwicklungs- oder Release-Zweig auszuchecken. Die Zweige, wie beispielsweise stable/9, sind unter www.freebsd.org/releng aufgeführt. Lesen Sie /usr/src/Makefile sehr aufmerksam bevor Sie &os.stable; aktualisieren und folgen Sie den Anweisungen in . Lesen Sie die Mailingliste &a.stable; und /usr/src/UPDATING, um über Änderungen im Installationsverfahren, die manchmal vor der Einführung eines neuen Releases notwendig sind, informiert zu sein. Synchronisation der Quellen Sie können eine Internet-Verbindung (oder E-Mail) dazu nutzen, Teile von &os;, wie die Quellen zu einzelnen Projekten, oder das Gesamtsystem, aktuell zu halten. Der primäre Dienst dafür ist Subversion. Obwohl es möglich ist, nur Teile des Quellbaums zu aktualisieren, ist die einzige unterstütze Migrationsprozedur, den kompletten Quellbaum zu aktualisieren und alles neu zu übersetzen. Dazu zählen alle Userland-Programme in /bin und /sbin, sowie die Kernelquellen. Wird hingegen nur ein Teil der Quellen, zum Beispiel nur der Kernel oder nur die Programme aus dem Userland aktualisiert, treten Probleme auf, die von Übersetzungsfehlern über Kernel-Panics bis hin zu Beschädigung von Daten reichen können. Subversion Subversion benutzt die Pull-Methode Von engl. to pull = ziehen. Der Client holt sich bei dieser Methode die Dateien ab. , um die Quellen zu aktualisieren. Der Benutzer, oder ein cron-Skript, ruft das Programm svn auf, das die Quellen aktualisiert. Subversion ist die empfohlene Methode, um die lokalen Quellen zu aktualisieren. Mit beiden Methoden erhalten Sie aktuelle Updates zu einem genau von Ihnen bestimmten Zeitpunkt. Es ist einfach, die Prozedur auf bestimmte Dateien oder Verzeichnisse einschränken. Die Updates werden zur Laufzeit generiert. Es gibt noch weitere Unterschiede. Wenn ein Benutzer unabsichtlich Teile des Archivs löschen, wird das von Subversion erkannt und repariert. Das Basissystem neu bauen Bau des Basissystems Sobald der lokalen Quellbaum mit einer bestimmten &os; Version, z.B. &os.stable; oder &os.current; synchronisiert wurde, kann dieser dazu benutzt werden das System neu zu bauen. Dieser Prozess wird auch als die Welt neu bauen bezeichnet. Bevor das System neu gebaut wird, müssen die folgende Aufgaben erledigt werden: Führen Sie diese Aufgaben aus, <emphasis>bevor</emphasis> das System neu gebaut wird Sichern Sie alle wichtigen Daten auf ein anderes System oder auf Wechselmedien und überprüfen Sie die Integrität der Sicherungskopie. Zudem sollten Sie bootfähige Installationsmedien zur Hand haben. Es kann nicht oft genug betont werden, wie wichtig es ist, vor dem Neubau des Systems eine Sicherung zu machen. Während der Neubau des Systems eine einfache Aufgabe ist, wird es zwangsläufig einmal vorkommen, dass Fehler im Quellcode dazu führen, dass das System nicht mehr bootet. Wahrscheinlich wird die Sicherungskopie nicht benötigt, aber gehen Sie auf Nummer sicher! Mailingliste Lesen Sie die neuesten Einträge in &a.stable; oder &a.current;, je nachdem welchen Zweig Sie folgen. Informieren Sie sich über bekannte Probleme und welche Systeme davon betroffen sind. Wenn ein Problem für den von Ihnen synchronisierten Code besteht, warten Sie auf eine all clear-Nachricht, die besagt, dass das Problem behoben wurde. Synchronisieren Sie dann die Quellen neu um sicherzustellen, dass die lokale Version die benötigten Korrekturen hat. Lesen Sie /usr/src/UPDATING für zusätzliche Aufgaben, die für diese Version des Quellcodes notwendig sind. Diese Datei enthält wichtige Informationen über potentielle Probleme. Gegebenenfalls müssen einige Kommandos in einer bestimmten Reihenfolge ausgeführt werden. Manche Aktualisierungen erfordern bestimmte zusätzliche Schritte, die ausgeführt werden müssen, bevor das System neu gebaut wird, wie beispielsweise das umbenennen oder löschen von bestimmten Datein. Diese Aufgaben sind am Ende der Datei aufgeführt. Die Anweisungen in UPDATING sind aktueller als die in diesem Handbuch. Im Zweifelsfall folgen Sie bitte den Anweisungen aus UPDATING. Verwenden Sie nicht <command>make world</command> Einige ältere Dokumentationen empfehlen make world für den Neubau. Das Kommando überspringt jedoch wichtige Schritte und sollte nur von Experten verwendet werden. In fast allen Fällen ist make world falsch. Benutzen Sie stattdessen die nachstehende Anleitung. Übersicht Dieser Prozess geht davon aus, dass ein System von einer älteren Version von &os; auf eine neuere Version aktualisiert wird. Der Quellcode für die neue Version wurde nach den Anweisungen in synchronisiert. Das Basissystem enthält den &os;-Kernel, die zentralen Binärdateien, Bibliotheken und Entwicklerdateien sowie einen integrierten Compiler. Die Reihenfolge, in der diese Komponenten gebaut werden, ist wichtig. Beispielsweise könnte der alte Compiler aufgrund von Fehlern nicht in der Lage sein, den neuen Kernel zu übersetzen. Da der neue Kernel mit dem neuen Compiler übersetzt wird, muss der neue Compiler gebaut, aber nicht notwendigerweise installiert werden, bevor der neue Kernel gebaut wird. Das neue Basissystem ist eventuell auf neue Funktionen des Kernels angewiesen. Aus diesem Grund muss der neue Kernel installiert sein, bevor das neue Basissystem installiert wird. Das alte Basissystem wird möglicherweise nicht korrekt mit dem neuen Kernel funktionieren, weshalb das neue Basissystem sofort nach der Installation des neuen Kernels installiert werden muss. Manche Änderungen an der Konfiguration müssen erledigt worden sein, bevor das neue Basissystem installiert wird, jedoch können andere die Funktionalität des alten Basissystems beeinträchtigen. Aus diesem Grund sind zwei verschiedene Schritte notwendig, um eine Aktualisierung der Konfiguration durchzuführen. Der Aktualisierungsprozess ersetzt zum Großteil Dateien oder fügt neue hinzu, bestehende Dateien werden nicht gelöscht. Da dieser Prozess Probleme verursachen kann, werden in /usr/src/UPDATING gegebenenfalls Dateien aufgelistet, die manuell entfernt werden müssen. Diese Bedenken haben zu einer empfohlenen Reihenfolge bei der Aktualisierung geführt, die im folgenden Prozess beschrieben wird. Es ist ratsam, die Ausgaben von make in einer Datei zu sichern. Wenn etwas schief geht, kann eine Kopie der Fehlermeldung zu einer der &os;-Mailinglisten gesendet werden. Dazu können Sie einfach script benutzen, dem Sie beim Aufruf als Parameter den Dateinamen für die Ausgaben mitgeben. Sichern Sie die Ausgaben nicht nach /tmp, da dessen Inhalt beim nächsten Neustart vielleicht verloren geht. Ein besserer Platz ist /var/tmp. Setzen Sie dieses Kommando unmittelbar vor dem Neubau ab und geben Sie exit ein, wenn der Bau abgeschlossen ist: &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out Zusammenfassung des Aktualisierungsprozesses Die verwendeten Kommandos sollten in der hier angegebenen Reihenfolge ausgeführt werden. Die Funktionen der einzelnen Kommandos werden in diesem Abschnitt beschrieben. Wenn der Bauprozess bereits einmal auf diesem System durchgeführt wurde, existiert vielleicht noch eine Kopie davon in /usr/obj. Um den neuen Bauprozess zu beschleunigen und Ärger aufgrund von Abhängigkeiten zu vermeiden, kann dieses Verzeichnis entfernt werden: &prompt.root; chflags -R noschg /usr/obj/* &prompt.root; rm -rf /usr/obj Übersetzen Sie zuerst den neuen Compiler und ein paar damit zusammenhängende Werkzeuge. Verwenden Sie dann den neuen Compiler, um den Rest des Basissystems zu erstellen. Das Ergebnis wird in /usr/obj abgelegt. &prompt.root; cd /usr/src &prompt.root; make buildworld Benutzen Sie den neuen Compiler aus /usr/obj, um sich vor falschen Compiler-Kernel-Kombinationen abzusichern. Dies ist notwendig, da sich einige Datenstrukturen geändert haben könnten und Programme wie &man.ps.1; und &man.top.1; nur mit einem Kernel zusammen arbeiten, der auch zu dem entsprechenden Quellcode passt. &prompt.root; make buildkernel Installieren Sie den neuen Kernel und die Kernelmodule, damit Sie den frisch aktualisierten Kernel starten können. Wenn kern.securelevel einen Wert größer als 1 besitzt und der Kernel mit noschg oder ähnlichen Optionen geschützt ist, müssen Sie zuerst in den Single-User-Modus wechseln. Andernfalls läuft dieses Kommando problemlos im Mehrbenutzermodus. Weitere Informationen über kern.securelevel finden Sie in &man.init.8;. Optionen, die auf Dateien gesetzt werden können, werden in &man.chflags.1; detailliert erläutert. &prompt.root; make installkernel Starten Sie das System in den Single-User-Modus, damit Probleme mit der Aktualisierung von Programmen, die bereits gestartet sind, minimiert werden. Ebenso minimiert dieser Modus Probleme, die mit der Verwendung des alten Basissystems und des neuen Kernels zu tun haben. &prompt.root; shutdown now Führen Sie folgende Befehle im Single-User-Modus aus, wenn das System mit einem UFS-Dateisystem formatiert ist: &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Wenn das System mit ZFS formatiert ist, führen Sie stattdessen folgende Befehle aus. In diesem Beispiel ist der Name des Pools zroot: &prompt.root; zfs set readonly=off zroot &prompt.root; zfs mount -a Optional: Wenn eine andere Tastaturbelegung als US-Englisch gewünscht wird, kann diese mit &man.kbdmap.1; angepasst werden: &prompt.root; kbdmap Führen Sie folgenden Befehl aus, wenn die CMOS-Uhr auf die lokale Zeit eingestellt ist (dies ist der Fall, wenn die Ausgabe von &man.date.1; nicht die richtige Zeit anzeigt): &prompt.root; adjkerntz -i Bei der Aktualisierung des Basissystems werden bestimmte Verzeichnisse, wie /etc, /var und /usr ausgelassen. Im nächsten Schritt werden ein paar initiale Konfigurationsdateien zur Vorbereitung für das neue Basissystem aktualisiert. Der folgende Befehl aktualisiert lediglich Dateien, die für das Gelingen von installworld unerlässlich sind. Beispielsweise können neue Gruppen, Systembenutzerkonten, oder neue Startskripten erstellt werden, die seit der letzten Aktualisierung hinzugefügt wurden. Dieser Schritt ist notwendig, damit installworld in der Lage ist, die neuen Konten, Gruppen und Skripten zu verwenden. Weitere Informationen zu diesem Befehl finden Sie in : &prompt.root; mergemaster -p Installieren Sie das neue Basissystem und die Systemdateien aus /usr/obj: &prompt.root; cd /usr/src &prompt.root; make installworld Aktualisieren Sie die verbleibenden Konfigurationsdateien: &prompt.root; mergemaster -iF Löschen Sie veraltete Dateien. Dieser Schritt ist wichtig, da alte Dateien manchmal Probleme bereiten, falls sie nicht entfernt werden: &prompt.root; make delete-old Nun wird ein Neustart benötigt, um den neuen Kernel und das neue Basissystem zu laden: &prompt.root; reboot Stellen Sie sicher, dass alle Ports neu gebaut wurden, bevor die alten Bibliotheken entfernt werden. Verwenden Sie dazu die Anweisungen aus . Entfernen Sie anschließend alle veralteten Bibliotheken um Konflikte mit den neuen Bibliotheken zu vermeiden. Weitere Informationen zu diesem Schritt finden Sie in . &prompt.root; make delete-old-libs Single-User Modus Wenn Sie eine Ausfallzeit des Systems in Kauf nehmen können, sollten sie das System im Single-User Modus bauen. Die Neuinstallation des Systems verändert viele wichtige Systemdateien, Systemwerkzeuge, Bibliotheken und Include-Dateien. Ändern Sie diese Dateien auf einem laufenden System, insbesondere mit aktiven Nutzern, kann dies große Probleme verursachen. Konfigurationsdateien make.conf Der Bauprozess verwendet verschiedene Konfigurationsdateien. Das Makefile in /usr/src legt fest, wie die Programme, aus denen &os; besteht, zu bauen sind und in welcher Reihenfolge diese zu bauen sind. Die verfügbaren Optionen für make werden in &man.make.conf.5; und /usr/share/examples/etc/make.conf beschrieben. Jede Option in /etc/make.conf beeinflusst das Verhalten von make beim Bau von Programmen. Die in /etc/make.conf gesetzten Optionen wirken sich bei jedem Aufruf von make aus, einschließlich beim Bau von Programmen aus der Ports-Sammlung, vom Benutzer geschriebene C-Programme oder beim Bau des &os;-Betriebssystems. Änderungen an einigen Einstellungen können weitreichende und unerwartete Auswirkungen nach sich ziehen. Lesen Sie die Kommentare in diesen beiden Ressourcen und beachten Sie, dass die Standardwerte aus einer Kombination von Leistung und Sicherheit gewählt wurden. /etc/src.conf Der Bau des Betriebssystems aus dem Quellcode wird von /etc/src.conf kontrolliert. Im Gegensatz zu /etc/make.conf greifen die Optionen in /etc/src.conf nur dann, wenn das &os; Betriebssystem selbst gebaut wird. Die vielen Optionen für diese Datei werden in &man.src.conf.5; beschrieben. Seien Sie vorsichtig mit dem Entfernen von scheinbar nicht mehr benötigten Kernelmodulen und Optionen. Manchmal gibt es unerwartete oder subtile Wechselwirkungen. Variablen und Ziele Ein typischer Aufruf von make sieht wie folgt aus: &prompt.root; make -x -DVARIABLE target In diesem Beispiel ist eine Option, die an make übergeben wird. Eine Liste gültiger Optionen finden Sie in &man.make.1;. Mit setzen Sie eine Variable. Das Verhalten der Makefile wird von Variablen bestimmt. Diese sind etweder in /etc/make.conf eingetragen, oder können an make übergeben werden. Das folgende Beispiel setzt eine Variable, die verhindert, dass die profiled Bibliotheken gebaut werden: &prompt.root; make -DNO_PROFILE target Dieser Aufruf entspricht dem folgenden Eintrag in /etc/make.conf: NO_PROFILE= true # Avoid compiling profiled libraries Das Ziel sagt make was zu tun ist und das Makefile definiert die verfügbaren Ziele. Einige Ziele werden verwendet, um den Bauprozess in eine Reihe von Einzelschritten zu unterteilen. Über separate Optionen zu verfügen, ist aus mehreren Gründen nützlich. Erstens erlaubt dies einen Bauprozess, der die Komponenten des laufenden Systems nicht beeinträchtigt. Deswegen können Sie buildworld gefahrlos im Mehrbenutzermodus laufen lassen. Die Installation mit installworld sollte aber immer noch im Single-User-Modus erfolgen. Zweitens kann, wie in beschrieben, NFS benutzt werden, um mehrere Maschinen in einem Netzwerk zu aktualisieren. Mit können Sie make anweisen, mehrere Prozesse zu starten. Da der Übersetzungsprozess hauptsächlich von I/O statt der CPU bestimmt wird, ist diese Option für Einprozessor- und Mehrprozessor-Systeme nützlich. Auf einem typischen Einprozessor-System können Sie den folgenden Befehl eingeben, um bis zu vier Prozesse gleichzeitig laufen zu lassen. Erfahrungsberichte aus den Mailinglisten zeigen, dass dieser Aufruf typischerweise den besten Geschwindigkeitsgewinn bringt: &prompt.root; make -j4 buildworld Wenn Sie ein Mehrprozessor-System besitzen, probieren Sie Werte zwischen 6 und 10 aus. Bau des Basissystems Laufzeiten Wenn mit make buildworld Variablen verwendet werden, müssen dieselben Variablen auch bei make installworld angegeben werden. Allerdings darf zusammen mit installworld nicht benutzt werden. Haben Sie zum Bauen die folgende Kommandozeile verwendet: &prompt.root; make -DNO_PROFILE buildworld dann installieren Sie das Ergebnis mit: &prompt.root; make -DNO_PROFILE installworld Andernfalls würde das System bei der Installation versuchen, die profiled Bibliotheken, die aber gar nicht gebaut wurden, zu installieren. Abgleich der Konfigurationsdateien TomRhodesBeigetragen von mergemaster - &os; enthält der &man.mergemaster.8; Bourne-Shell - Skript, das dabei behilflich ist die Unterschiede zwischen + &os; enthält das &man.mergemaster.8; Bourne-Shell + Skript, welches dabei behilflich ist die Unterschiede zwischen den Konfigurationsdateien in /etc und denen unter /usr/src/etc zu finden. Dies ist der empfohlene Weg, die Systemkonfiguration mit dem Quellbaum abzugleichen. - Es wird empfohlen, zuerst das bestehende + Es ist ratsam, zuerst das bestehende /etc an einen sicheren Ort zu kopieren. Mit wird rekursiv kopiert und erhält die Zugriffszeiten und Eigentümer der Dateien: &prompt.root; cp -Rp /etc /etc.old Beim Aufruf wird mergemaster ausgehend von / einen virtuellen Root-Baum aufbauen und darin die neuen Konfigurationsdateien ablegen. Diese Dateien werden dann mit den auf dem System installierten Dateien verglichen. Unterschiede zwischen den Dateien werden im &man.diff.1;-Format dargestellt. Neue oder geänderte Zeilen werden mit gekennzeichnet. Zeilen die gelöscht oder ersetzt werden, sind mit gekennzeichnet. Das Anzeigeformat wird in &man.diff.1; genauer erklärt. Als nächstes zeigt mergemaster jede geänderte Datei an und Sie haben die Wahl, die neue Datei (auch temporäre Datei genannt) zu löschen, sie unverändert zu installieren, den Inhalt der neuen Datei mit dem Inhalt der alten Datei abzugleichen, oder die Ausgabe noch einmal zu sehen. Wenn Sie die temporäre Datei löschen, geht mergemaster davon aus, dass Sie die aktuelle Datei unverändert behalten möchten. Die Auswahl dieser Option wird nicht empfohlen. Durch die Eingabe von ? können Sie jederzeit die Hilfe am Prompt von mergemaster aufrufen. Wenn Sie eine Datei überspringen, wird mergemaster diese am Ende erneut präsentieren. Wenn Sie die temporäre Datei installieren, wird die aktuelle Datei mit der neuen Datei überschrieben. Sie sollten alle unveränderten Konfigurationsdateien auf diese Weise aktualisieren. Wenn Sie sich entschließen den Inhalt beider Dateien abzugleichen, wird ein Texteditor aufgerufen, in dem Sie beide Dateien nebeneinander betrachten können. Mit der Taste l übernehmen Sie die aktuelle Zeile der links dargestellten Datei, mit der Taste r übernehmen Sie die Zeile der rechts dargestellten Datei. Das Ergebnis ist eine Datei, die aus Teilen der beiden ursprünglichen Dateien besteht und installiert werden kann. Dieses Verfahren wird gewöhnlich bei veränderten Dateien genutzt. Haben Sie sich entschieden die Differenzen noch einmal anzuzeigen, werden nochmals die Unterschiede in beiden Dateien angezeigt. Wenn mergemaster alle Systemdateien abgearbeitet hat, werden weitere Optionen abgefragt. Sie werden unter Umständen gefragt, ob die Passwort-Datei neu gebaut werden soll. Am Ende haben Sie die Möglichkeit, die restlichen temporären Dateien zu löschen. Veraltete Dateien und Bibliotheken löschen Anton Shterenlikht Basiert auf Notizen von Veraltete Dateien und Verzeichnisse löschen Aufgrund der ständigen Weiterentwicklung von &os; kann es dazu kommen, dass Dateien und deren Inhalte obsolet werden, weil deren Funktionalität entweder in anderen Dateien implementiert wurde, sich die Versionsnummer der Bibliothek geändert hat oder die Funktion aus dem System entfernt wurde. Dies kann sowohl Dateien und Verzeichnisse, aber auch Bibliotheken betreffen. Diese veralteten Dateien, Verzeichnisse und Bibliotheken sollten daher entfernt werden, wenn das System aktualisiert wird. Die stellt sicher, dass das System von nicht mehr benötigten Dateien befreit wird. Falls die obsolete Bibliothek Sicherheits- oder Stabilitätsprobleme aufweist, sollte das System ebenfalls aktualisiert werden, um das System sicher zu halten und/oder durch die fehlerhafte Bibliothek verursachte Systemabstürze zu vermeiden. Veraltete Dateien, Verzeichnisse und Bibliotheken sind in /usr/src/ObsoleteFiles.inc aufgelistet. Verwenden Sie die folgenden Anweisungen, um diese Dateien während der Systemaktualisierung zu entfernen. Nachdem Sie make installworld sowie mergemaster erfolgreich ausgeführt haben, überprüfen Sie das System auf veraltete Dateien und Bibliotheken: &prompt.root; cd /usr/src &prompt.root; make check-old Werden dabei veraltete Dateien gefunden, können diese mit dem folgenden Kommando entfernt werden: &prompt.root; make delete-old Bei jeder Datei wird nachgefragt, ob diese wirklich gelöscht werden soll. Es ist aber auch möglich, alle Dateien automatisch löschen zu lassen. Dies erreichen Sie, indem Sie die Umgebungsvariable BATCH_DELETE_OLD_FILES setzen: &prompt.root; make -DBATCH_DELETE_OLD_FILES delete-old Alternativ können Sie auch yes einsetzen und somit die Antwort yes an die einzelnen Abfragen weiterreichen: &prompt.root; yes | make delete-old Warnung Das Löschen veralteter Dateien kann dazu führen, dass Programme, die auf diese Dateien angewiesen sind, nicht mehr funktionieren. Dies gilt insbesondere für veraltete Bibliotheken. In den meisten Fällen ist es dann notwendig, Programme, Ports und Bibliotheken, welche die veraltete Bibliothek verwenden, neu zu bauen, bevor Sie den Befehl make delete-old-libs ausführen. Die Bibliothek-Abhängigkeiten können mit sysutils/libchk und sysutils/bsdadminscripts geprüft werden. Veraltete Bibliotheken können zu Konflikten mit neueren Bibliotheken führen und beispielsweise folgende Meldungen verursachen: /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 Um diese Probleme zu lösen, müssen Sie zuerst herausfinden, welcher Port die Bibliothek installiert hat: &prompt.root; pkg which /usr/local/lib/libtiff.so /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 &prompt.root; pkg which /usr/local/lib/libXext.so /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 Danach deinstallieren Sie den Port und bauen ihn neu, um ihn danach erneut zu installieren. Dieser Vorgang kann durch den Einsatz von ports-mgmt/portmaster automatisiert werden. Nachdem alle Ports neu gebaut wurden und keine alten alten Bibliotheken mehr verwenden werden, können Sie die alten Bibliotheken endgültig entfernen: &prompt.root; make delete-old-libs Falls etwas schief geht, ist es leicht einen Teil des Systems wiederherzustellen. Wenn beispielsweise während des Updates oder Abgleichs /etc/magic aus Versehen gelöscht wurde, wird file nicht mehr funktionieren. In diesem Fall kann das Problem mit dem folgenden Kommando behoben werden: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Häufige Fragen Muss ich wirklich immer alles neu bauen, wenn sich etwas geändert hat? Das hängt von den Änderungen ab. Es lohnt wahrscheinlich nicht, alles neu zu bauen, wenn sich bei einem svn-Lauf nur die folgenden Dateien geändert haben: 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 In diesem Fall können Sie in die entsprechenden Unterverzeichnisse wechseln und dort make all install ausführen. Wenn sich allerdings etwas Wichtiges, wie src/lib/libc/stdlib, geändert hat, sollten Sie die Welt neu bauen. Einige Benutzer sind vielleicht damit zufrieden, das System alle zwei Wochen neu zu bauen und in der Zwischenzeit die anfallenden Änderungen zu sammeln. Wenn Sie sich zutrauen, alle Abhängigkeiten zu erkennen, bauen Sie vielleicht auch nur die geänderten Sachen neu. Das hängt auch noch davon ab, wie oft Sie ein Update durchführen wollen und ob Sie &os.stable; oder &os.current; benutzen. Warum bricht der Bau mit vielen Signal 11signal 11 Fehlern (oder anderen Signalnummern) ab? Normalerweise zeigen diese Meldungen Hardwarefehler an. Ein Neubau der Welt ist ein guter Belastungstest für die Hardware und zeigt oft Probleme mit dem Speicher auf. Es liegt garantiert ein Hardwarefehler vor, wenn make neu gestartet wird und an einer anderen Stelle abbricht. In diesem Fall können nur einzelne Komponenten des Systems, angefangen mit dem RAM, getauscht werden, um zu bestimmen, welche Komponente den Fehler verursacht. Kann /usr/obj entfernt werden, wenn ich fertig bin? In diesem Verzeichnis werden alle Dateien abgelegt, die während der Übersetzungsphase erstellt wurden. Dieses Verzeichnis wird in einem der ersten Schritte von make buildworld entfernt. Es macht daher wenig Sinn, dieses Verzeichnis zu behalten. Zudem wird ungefähr 2 GB Plattenspeicher freigegeben, wenn dieses Verzeichnis gelöscht wird. Kann ein abgebrochener Bau weitergeführt werden? Das hängt davon ab, wieweit der Bauprozess fortgeschritten ist. Üblicherweise werden durch make buildworld essentielle Werkzeuge und die Systembibliotheken neu erstellt. Die neu erstellten Werkzeuge und Bibliotheken werden dann benutzt, um sich selbst noch einmal zu bauen, und wieder installiert. Anschließend wird das Gesamtsystem mit den neu erstellten Systemdateien gebaut. Während der letzten Phase können Sie relativ gefahrlos folgende Kommandos ausführen, ohne dabei die von make buildworld erzeugten Dateien zu löschen: &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all Wenn diese Meldung in der Ausgabe von make buildworld erscheint: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- dann können Sie den Befehl bedenkenlos ausführen. Wenn diese Meldung nicht angezeigt wird, dann ist es besser, noch einmal ganz von Vorne anzufangen. Ist es möglich, den Bauprozess zu beschleunigen? Es gibt mehrere Maßnahmen um den Bauprozess zu beschleunigen. Zum Beispiel kann der gesamte Prozess im Single-User-Modus ausgeführt werden. Dies verhindert jedoch, dass Benutzer Zugriff auf das System haben, bis der Prozess abgeschlossen ist. Die sorgfältige Planung von Dateisystemen oder die Verwendung von ZFS können auch einen Unterschied machen. Sie können erwägen, /usr/src und /usr/obj auf separate Dateisysteme zu legen. Wenn möglich, platzieren Sie die Dateisysteme auf separaten Festplatten mit getrennten Platten-Controllern. Verwenden Sie beim einhängen von /usr/src die Option , um die Aktualisierung der Dateizugriffe zu deaktivieren. Falls /usr/src nicht auf einem eigenen Dateisystem liegt, können Sie /usr abhängen und mit neu einhängen. Das Dateisystem, in dem sich /usr/obj befindet, kann mit eingehangen werden, so dass Schreibzugriffe auf die Platte asynchron stattfinden. Das heißt ein Schreibzugriff ist sofort beendet, die Daten werden allerdings erst einige Sekunden später geschrieben. Dadurch können Schreibzugriffe zusammengefasst werden, was einen erheblichen Geschwindigkeitszuwachs mit sich bringen kann. Beachten Sie, dass dies das Dateisystem anfälliger für Fehler macht. Im Fall eines Stromausfalls besteht eine erhöhte Wahrscheinlichkeit, dass das Dateisystem beim Start der Maschine zerstört ist. Wenn /usr/obj das einzige Verzeichnis auf auf diesem Dateisystem ist, stellt das kein Problem dar. Wenn sich allerdings auf diesem Dateisystem noch andere wertvolle Daten befinden, stellen Sie sicher, dass Sie über aktuelle Sicherungen verfügen. Deaktivieren Sie den Bau der profiled-Bibliotheken, indem Sie NO_PROFILE=true in /etc/make.conf eintragen. Benutzen Sie make zusammen mit , um mehrere Prozesse parallel laufen zu lassen. Normalerweise beschleunigt dies den Bauprozess auf Einprozessor- und Mehrprozessorsystemen. Was mache ich, wenn etwas nicht funktioniert? Stellen Sie zuerst sicher, dass sich in der Umgebung keine Reste eines vorherigen Baus befinden: &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 Ja, make cleandir muss wirklich zweimal aufgerufen werden. Danach starten Sie den Bauprozess wieder mit make buildworld. Wenn Sie immer noch Probleme haben, schicken Sie die Fehlermeldungen und die Ausgabe von uname -a an die Mailingliste &a.de.questions;. Bereiten Sie sich darauf vor, weitere Fragen zu der Umgebung zu beantworten. Installation mehrerer Maschinen MikeMeyerBeigetragen von Wenn Sie mehrere Maschinen auf dem gleichen Stand halten wollen, ist es eine Verschwendung von Ressourcen, die Quellen auf jeder Maschine vorzuhalten und zu übersetzen. Die Lösung dazu ist, eine Maschine den Großteil der Arbeit durchführen zu lassen und den anderen Maschinen das Ergebnis mit NFS zur Verfügung zu stellen. Dieser Abschnitt zeigt eine Methode dies zu tun. Weitere Informationen zu NFS finden Sie in . Stellen Sie zuerst eine Liste der Maschinen zusammen, die auf demselben Stand sein sollen. Wir nennen diese Maschinen die Baugruppe. Jede dieser Maschinen kann mit einem eigenen Kernel laufen, doch sind die Programme des Userlands auf allen Maschinen gleich. Wählen Sie aus der Baugruppe eine Maschine aus, auf der der Bau durchgeführt wird, den Bau-Master. Dies sollte eine Maschine sein, die über die nötigen CPU-Ressourcen für make buildworld und make installworld verfügt. Sie brauchen auch eine Testmaschine, auf der Sie die Updates testen, bevor Sie sie in Produktion installieren. Dies muss eine Maschine sein, die über einen längeren Zeitraum nicht zur Verfügung stehen kann. Alle Maschinen der Baugruppe müssen /usr/obj und /usr/src über NFS vom Bau-Master an gleichem Ort einhängen. Wenn Sie mehrere Baugruppen haben, sollte sich /usr/src auf einem Bau-Master befinden und über NFS für den Rest der Maschinen zur Verfügung gestellt werden. Stellen Sie sicher, dass /etc/make.conf und /etc/src.conf auf allen Maschinen einer Baugruppe mit der Datei des Bau-Masters übereinstimmt. Der Bau-Master muss jeden Teil des Systems bauen, den irgendeine Maschine der Baugruppe benötigt. Auf dem Bau-Master müssen in /etc/make.conf alle zu bauenden Kernel mit der Variablen KERNCONF bekannt gegeben werden. Geben Sie dabei den Kernel des Bau-Masters zuerst an. Für jeden zu bauenden Kernel muss auf dem Bau-Master die entsprechende Konfigurationsdatei unter /usr/src/sys/arch/conf abgelegt werden. Bauen Sie auf dem Bau-Master, wie in beschrieben, den Kernel und die Welt, installieren Sie aber nichts. Wechseln Sie auf die Testmaschine und installieren Sie den gerade gebauten Kernel. Hängen Sie auf der Testmaschine /usr/src und /usr/obj über NFS ein. Geben Sie dann shutdown now ein, um in den Single-User-Modus zu gelangen, von wo aus Sie den neuen Kernel und das System installieren. Lassen Sie anschließend mergemaster laufen. Wenn Sie fertig sind, booten Sie die Maschine wieder in den Mehrbenutzermodus. Nachdem Sie sichergestellt haben, dass die Testmaschine einwandfrei funktioniert, wiederholen Sie diese Prozedur für jede Maschine in der Baugruppe. Dasselbe Verfahren können Sie auch für die Ports-Sammlung anwenden. Zuerst müssen alle Maschinen einer Baugruppe /usr/ports über NFS zur Verfügung gestellt bekommen. Setzen Sie ein Verzeichnis für die Quellen auf, das sich alle Maschinen teilen. Dieses Verzeichnis können Sie in /etc/make.conf mit der Variablen DISTDIR angeben. Das Verzeichnis sollte für den Benutzer beschreibbar sein, auf den der Benutzer root vom NFS Subsystem abgebildet wird. Jede Maschine sollte noch WRKDIRPREFIX auf ein lokales Bauverzeichnis setzen. Wenn Sie vorhaben, Pakete zu bauen und zu verteilen, sollten Sie PACKAGES auf ein Verzeichnis mit den gleichen Eigenschaften wie DISTDIR setzen.