Index: head/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.xml (revision 48976) +++ head/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.xml (revision 48977) @@ -1,3306 +1,3249 @@ &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, welche Werkzeuge verwendet werden können, um das System und die Port-Sammlung zu aktualisieren. wissen, wie das System mit - freebsd-update, - Subversion oder - CTM aktualisiert wird. + 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 Einspielen von Sicherheitsaktualisierungen ist ein wichtiger Bestandteil bei der Wartung von Computersoftware, besonders wenn es um das Betriebssystem geht. Für lange Zeit war dieser Prozess unter &os; nicht einfach. Fehlerbehebungen mussten auf den Quellcode angewendet werden, danach wurde der Code zu neuen Binärdateien übersetzt und schliesslich mussten diese Dateien neu installiert werden. Das ist seit längerem nicht mehr der Fall, da &os; jetzt ein Werkzeug namens freebsd-update enthält. Dieses Werkzeug bringt zwei getrennte Funktionen mit sich. Die erste Funktion ermöglicht die Anwendung von Sicherheitsaktualisierungen im Binärformat auf das &os; Basissystem, ohne dieses neu zu übersetzen und zu installieren. Die zweite Funktion unterstützt Aktualisierungen zwischen Haupt- und Unterversionen. Binäre Aktualisierungen sind für alle Architekturen und Releases verfügbar, die aktuell vom &os; Security Team betreut werden. Vor der Aktualisierung auf eine neue Release-Version sollten die aktuellen Ankündigungen zu dem Release gelesen werden, da diese wichtige Informationen zu der gewünschten Version enthalten. Release 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 die folgende Aktion gestartet wird. Die Konfigurationsdatei Manche Anwender möchten sicherlich Einstellungen in der Standard-Konfigurationsdatei unter /etc/freebsd-update.conf vornehmen, um bessere Kontrolle über den gesamten Prozess zu besitzen. Die Optionen sind gut dokumentiert, jedoch benötigen die folgenden ein paar zusätzliche Erklärungen: # Components of the base system which should be kept updated. Components src world kernel Dieser Parameter kontrolliert, welche Teile von &os; auf dem aktuellen Stand gehalten werden sollen. In der Voreinstellung wird der Quellcode, das gesamte Basissystem sowie der Kernel aktualisiert. Die Komponenten sind die gleichen wie während der Installation. Das hinzufügen von world/games erlaubt es, Aktualisierungen für Spiele anzuwenden. Die Verwendung von src/bin erlaubt es, den Quellcode in src/bin aktuell zu halten. 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 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 Aktualisiert nur unmodifizierte Konfigurationsdateien in den angegebenen Verzeichnissen. Jede Änderung, die der Benutzer daran vorgenommen hat, wird die automatische Aktualisierung dieser Dateien ungültig machen. 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/ 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 Sicherheitsaktualisierungen für &os; können wie folgt heruntergeladen und installiert werden: &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install Wenn während 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: @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 heruntergeladen, aber nicht eingespielt. Der root-Benutzer bekommt eine Nachricht, damit die Korrekturen überprüft und 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 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. 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 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 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 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: &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. 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. Portsnap: Ein Werkzeug zur Aktualisierung der Ports-Sammlung TomRhodesGeschrieben von ColinPercivalBasierend auf bereitgestellten Mitschriften von BenedictReuschlingÜbersetzt von Updating and Upgrading Portsnap Updating and Upgrading Das Basissystem von &os; enthält &man.portsnap.8; zum Aktualisieren der Ports-Sammlung. Dieses Programm verbindet sich mit einem entfernten Rechner, überprüft den Sicherungsschlüssel und lädt eine neue Kopie der Ports-Sammlung herunter. Der Schlüssel wird verwendet, um die Integrität aller heruntergeladenen Dateien zu prüfen. Um die aktuellsten Dateien der Ports-Sammlung herunter zu laden, geben Sie das folgende Kommando ein: &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. Dieses Beispiel zeigt, dass &man.portsnap.8; mehrere Korrekturen für die aktuellen Ports-Daten gefunden und verifiziert hat. Es zeigt auch, dass das Programm zuvor schon einmal gestartet wurde. Wäre es das erste Mal, würde nur die Ports-Sammlung heruntergeladen werden. Wenn &man.portsnap.8; die fetch-Operation erfolgreich abgeschlossen hat, befinden sich die Ports-Sammlung und die dazugehörigen Korrekturen, welche die Überprüfung bestanden haben, auf dem lokalen System. Wenn portsnap das erste Mal ausgeführt wird, muss portsnap extract aufgerufen werden, um die Ports-Sammlung zu installieren: &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 ... Um eine bereits installierte Ports-Sammlung zu aktualisieren, verwenden Sie portsnap update: &prompt.root; portsnap update Der Prozess ist jetzt abgeschlossen und Anwendungen können mittels der aktuellen Ports-Sammlung installiert oder aktualisiert werden. Die Operationen fetch und extract oder update können auch nacheinander ausgeführt werden: &prompt.root; portsnap fetch update Dieser Befehl lädt die aktuelle Version der Ports-Sammlung herunter und aktualisiert anschließend die lokale Version unter /usr/ports. 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 verfügbar ist, verfügen manche Benutzer nur über eine langsame oder überhaupt keine Netzwerkverbindung. Es gibt mehrere Möglichkeiten, die lokale Kopie der Dokumentation durch die aktuelle &os;-Dokumentationssammlung zu aktualisieren. Verwenden von <application>Subversion</application> um die Dokumentation zu aktualisieren Die Dokumentationsquellen von &os; können mittels svn aktualisiert werden. Dieser Abschnitt beschreibt: Die Installation der Dokumentations-Werkzeugsammlung, welche die Werkzeuge enthält, die nötig sind, um die &os; Dokumentation aus den Quellen neu zu erstellen. Das Herunterladen einer Kopie der Dokumentationsquellen nach /usr/doc, unter Verwendung von svn. Den Bau der &os; Dokumentation aus den Quellen und die Installation unter /usr/share/doc. Manche der Optionen zum Erstellen, die vom System zum Bauen der Dokumentation unterstützt werden, z.B. die Optionen welche nur ein paar der unterschiedlichen Sprachübersetzungen der Dokumentation erstellen oder die Optionen, die ein bestimmtes Ausgabeformat auswählen. <application>svn</application> und die Werkzeugsammlung der Dokumentation installieren Die Erstellung der &os; Dokumentation aus den Quellen benötigt eine große Anzahl an Werkzeugen, die nicht Teil des &os; Basissystems sind, da sie eine große Menge Plattenplatz verbrauchen und nicht von allen &os;-Anwendern benötigt werden. Sie sind daher nur für diejenigen Benutzer sinnvoll, die aktiv neue Dokumentation für &os; schreiben oder häufig die Dokumentation aus den Quellen aktualisieren. Alle benötigten Werkzeuge, einschließlich svn sind im Meta-Port textproc/docproj vorhanden, der vom &os; Documentation Project entwickelt wurde. Wenn Sie die Dokumentation nicht als &postscript; oder PDF benötigen, können Sie alternativ die Installation des textproc/docproj-nojadetex-Ports in Erwägung ziehen. Diese Version der Dokumentations-Werkzeugsammlung enthält alles ausser das teTeX-Textsatzsystem. teTeX ist eine sehr grosse Sammlung an Werkzeugen, deshalb ist es vernünftig, deren Installation auszulassen, wenn die Ausgabe von PDF nicht unbedingt gebraucht wird. Die Dokumentationsquellen aktualisieren In diesem Beispiel wird svn verwendet, um eine saubere Kopie der Dokumentationsquellen über das HTTPS-Protokoll zu holen: &prompt.root; svn checkout https://svn.freebsd.org/doc/head/doc/head /usr/doc Benutzen Sie dazu einen der Spiegel aus Subversion Mirror Sites. Es dauert eine Weile, wenn die Dokumentationsquellen das allererste Mal heruntergeladen werden. Lassen Sie es laufen, bis es fertig ist. Zukünftige Aktualisierungen der Dokumentationsquellen können wie folgt durchgeführt werden: &prompt.root; svn update /usr/doc Nachdem die Quellen einmal ausgecheckt wurden, wird durch /usr/doc/Makefile ein alternativer Weg unterstützt, die Dokumentation zu aktualisieren. Geben Sie dazu die folgenden Befehle ein: &prompt.root; cd /usr/doc &prompt.root; make update Einstellbare Optionen der Dokumentationsquellen Das System zum aktualisieren und erstellen der &os;-Dokumentationssammlung unterstützt ein paar Optionen, welche den Prozess der Aktualisierung von Teilen der Dokumentation oder einer bestimmten Übersetzung erleichtert. Diese Optionen können entweder systemweit in /etc/make.conf gesetzt, oder als Kommandozeilenoptionen an &man.make.1; ü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, pdf, und rtf 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;. Für weitere make-Variablen, die vom System zum Erstellen der &os;-Dokumentation unterstützt werden, lesen Sie die Fibel für neue Mitarbeiter des &os;-Dokumentationsprojekts. Die &os;-Dokumentation aus den Quellen installieren 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, definiert in DOC_LANG, 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 &man.make.1; in einem sprachspezifischen Unterverzeichnis von /usr/doc aufgerufen werden: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean 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 Informationen zum Bearbeiten und Einreichen von Korrekturen finden Sie in der Fibel für neue Mitarbeiter des &os;-Dokumentationsprojekts. Verwendung von Dokumentations-Ports 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. Allerdings sind quellbasierte Aktualisierungen möglicherweise nicht für alle &os;-Systeme geeignet oder praktikabel. Das Erstellen der Dokumentationsquellen benötigt eine große Anzahl an Werkzeugen, Programmen und Hilfsmitteln, die documentation toolchain, einen gewissen Grad an Vertrautheit mit svn, ausgecheckte Quellen von einem Repository, sowie ein paar manuelle Schritte, um diese ausgecheckten Quellen zu bauen. Dieser Abschnitt beschreibt eine alternative Methode, in der die Ports-Sammlung verwendet wird und die es ermöglicht: vorgefertigte Schnappschüsse der Dokumentation herunterzuladen und zu installieren, ohne vorher die Werkzeugsammlung der Dokumentation installieren zu müssen. die Dokumentationsquellen herunterzuladen und durch das Ports-System erstellen zu lassen, was die Schritte zum Auschecken und Erstellen etwas erleichtert. Diese beiden Methoden der Aktualisierung der &os;-Dokumentation werden durch eine Menge von Dokumentations-Ports 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/). Erstellen und Installieren von Dokumentations-Ports Die Dokumentations-Ports nutzen das Ports-System, um das Erstellen von Dokumentation wesentlich einfacher zu machen. Es automatisiert den Prozess des Auscheckens der Dokumentationsquellen, aufrufen von &man.make.1; mit den passenden Umgebungsvariablen und Kommandozeilenoptionen und macht die Installation und Deinstallation von Dokumentation so einfach wie die Installation von jedem anderen Port oder Paket. Als zusätzliche Eigenschaft zeichnen sie eine Abhängigkeit zur Dokumentations-Werkzeugsammlung auf, wenn die Dokumentations-Ports lokal erstellt werden, weshalb diese auch automatisch mitinstalliert wird. Die Dokumentations-Ports sind wie folgt organisiert: Der Master-Port, misc/freebsd-doc-en, der alle englischen Dokumentations-Ports installiert. Der Alles-in-Einem-Port, misc/freebsd-doc-all, welcher die komplette Dokumentation in allen verfügbaren Sprachen erstellt und installiert. Es gibt noch einen Slave-Port für jede Übersetzung, beispielsweise misc/freebsd-doc-hu für Dokumentation in ungarischer Sprache. Um die englische Dokumentation zu bauen im getrennten HTML-Format in /usr/local/share/doc/freebsd zu installieren, installieren Sie den folgenden Port: &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean Gebräuchliche Schalter und Optionen Es gibt viele Optionen, die das Standardverhalten der Dokumentations-Ports verändern. 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 gegebenenfalls book.html, zuzüglich der Bilder gespeichert. WITH_PDF Erstellt das &adobe; Portable Document Format (PDF). Die formatierte Dokumentation wird als Datei mit dem Namen article.pdf, oder gegebenenfalls als book.pdf gespeichert. DOCBASE Legt den Pfad fest, wohin die Dokumentation installiert werden soll. Die Voreinstellung ist /usr/local/share/doc/freebsd. Der Standardpfad zum Verzeichnis unterscheidet sich von dem Verzeichnis, das von svn verwendet wird. Das liegt daran, dass Ports üblicherweise in /usr/local installiert werden. Dies kann durch die Verwendung von PREFIX überschrieben werden. Dieses Beispiel verwendet Variablen, um die ungarische Dokumentation als PDF zu installieren: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean Verwendung von Dokumentations-Paketen Das Erstellen der Dokumentations-Ports aus den Quellen, wie im vorherigen Abschnitt beschrieben, benötigt die lokale Installation der Dokumentations-Werkzeugsammlung und ein wenig Festplattenspeicher für das Bauen der Ports. Sollten die Ressourcen zum Bauen der Dokumentations-Werkzeugsammlung nicht zur Verfügung stehen, oder weil das erstellen zuviel Plattenplatz benötigen würde, ist es trotzdem möglich, bereits zuvor gebaute Schnappschüsse der Dokumentations-Ports zu installieren. &a.doceng; erstellt monatliche Schnappschüsse der Dokumentations-Pakete von &os;. Diese Binärpakete können mit jedem der mitgelieferten Paketwerkzeuge installiert werden, beispielsweise &man.pkg.add.1;, &man.pkg.delete.1; und so weiter. Wenn Binärpakete zu Einsatz kommen, wird die &os;-Dokumentation in allen verfügbaren Formaten in der gegebenen Sprache installiert. Zum Beispiel installiert das folgende Kommando das aktuelle, vorgefertigte Paket der ungarischen Dokumentation: &prompt.root; pkg_add -r 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. Dokumentations-Ports aktualisieren Dokumentations-Ports können wie jeder andere Port 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 und erläutert, wie Sie ein System auf dem aktuellen Stand eines Zweiges halten. Zuerst wird &os.current; vorgestellt, dann &os.stable;. &os.current; &os.current; ist die Spitze der Entwicklung von &os;. Benutzer von &os.current; sollten über sehr gute technische Fähigkeiten verfügen und in der Lage sein, schwierige Probleme alleine zu lösen. Wenn &os; neu für Sie ist, verwenden Sie besser &os.stable;. Was ist &os.current;? Snapshot &os.current; besteht aus den neuesten Quellen des &os;-Systems. Es enthält Sachen, an denen gerade gearbeitet wird, experimentelle Änderungen und Übergangsmechanismen, die im nächsten offiziellen Release der Software 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 nicht bauen lässt. Diese Probleme werden so schnell wie möglich behoben, aber ob Sie mit &os.current; Schiffbruch erleiden oder die gewünschten Verbesserungen erhalten, kann von dem Zeitpunkt abhängen, an dem der Quelltext synchronisiert wurde. Wer braucht &os.current;? &os.current; wird hauptsächlich für drei Interessengruppen zur Verfügung gestellt: Entwickler, die an einem Teil des Quellbaums arbeiten und daher über die aktuellen Quellen verfügen müssen. Tester, die bereit sind, Zeit in das Lösen von Problemen zu investieren und sicherstellen, dass &os.current; so stabil wie möglich bleibt. Diese Tester machen Vorschläge zu Änderungen oder der generellen Entwicklung von &os; und stellen Patches bereit, um diese Vorschläge zu realisieren. Für Leute, die die Entwicklung im Auge behalten wollen, oder die Quellen zu Referenzzwecken benutzen wollen. Auch diese Gruppe macht Vorschläge oder steuert Quellcode bei. Was &os.current; <emphasis>nicht</emphasis> ist! 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. Ein schneller Weg, um an Fehlerbehebungen (engl. bug fixes) zu kommen. Jede Fehlerbehebung führt mit gleicher Wahrscheinlichkeit neue Fehler ein, mit der sie alte behebt. In keiner Weise offiziell unterstützt. Benutzen von &os.current; 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. Beschaffen Sie sich die Quellen von einem &os;-Spiegel, mit einer der folgenden Methoden: Benutzen Sie svn, um den gewünschten Entwicklungs- oder Release-Zweig auszuchecken. Dies ist die empfohlene Methode für den Zugang zur Entwicklung von &os;. Checken Sie den -CURRENT Quelltext aus dem head-Zweig von einem der Subversion Mirror Sites aus. Aufgrund der Größe des Repositories ist es empfehlenswert, nur die gewünschten Teilbäume auszuchecken. - - - Benutzen Sie CTM, - wenn Sie über eine schlechte Internet-Anbindung - verfügen. CTM ist eine - Option, aber es ist nicht so zuverlässig wie - Subversion. Aus diesem - Grund ist Subversion die - empfohlene Methode für jedes System mit - Internet-Anbindung. - Wenn Sie die Quellen einsetzen und nicht nur darin lesen wollen, besorgen Sie sich die kompletten Quellen von &os.current; und nicht nur ausgesuchte Teile. Der Grund hierfür ist, dass die verschiedenen Teile der Quellen voneinander abhängen. Es ist ziemlich sicher, dass Sie in Schwierigkeiten geraten, wenn Sie versuchen, nur einen Teil der Quellen zu übersetzen. Lesen Sie /usr/src/Makefile sehr aufmerksam, bevor Sie -CURRENTübersetzen &os.current; übersetzen. Wenn Sie &os; das erste Mal aktualisieren, sollten Sie sowohl einen Kernel als auch das System neu installieren. 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, werden übrigens begeistert entgegengenommen! &os.stable; Was ist &os.stable;? -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. Wer braucht &os.stable;? 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. Auch wenn sicherheitsrelevante Fehlerbehebungen in den &os.stable; Zweig einfließen, müssen Sie deswegen noch lange nicht &os.stable; verfolgen. Jeder &os; Sicherheitshinweis beschreibt für jedes betroffene Release, wie der sicherheitsrelevante Fehler behoben wird. Eine vollständige Beschreibung der Sicherheitspolitik für alte &os; Releases entnehmen Sie http://www.FreeBSD.org/security/. 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. Benutzer, die keine Ressourcen haben, um diese Tests durchzuführen wird empfohlen, das aktuelle &os;-Release zu verwenden und den binären Update-Mechanismus zu nutzen, um auf neue Releases zu migrieren. Benutzen von &os.stable; -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 die Snapshot Website auf aktuelle Informationen überprüfen. Alternativ können Sie auch das neueste &os.stable;-Release von den Spiegeln beziehen und das System nach den folgenden Anweisungen aktualisieren. Es stehen mehrere Methoden zur Verfügung, um ein System mit einem älteren Release von einem der &os;-Spiegel zu aktualisieren. Benutzen Sie svn, um den gewünschten Entwicklungs- oder Release-Zweig auszuchecken. Dies ist die empfohlene Methode für den Zugang zur Entwicklung von &os;. Die Zweige umfassen head, für den aktuellen Entwicklungszweig, sowie weitere Zweige die auf der Release Engineering Seite beschrieben sind, wie beispielsweise stable/9 oder releng/9.0. Das bevorzugte URL-Präfix für Subversion zum Auschecken des Basissystems ist http://svn.freebsd.org/base/. Aufgrund der Größe des Repositories ist es empfehlenswert, nur die gewünschten Teilbäume auszuchecken. - - - - -STABLE - mit CTM synchronisieren - - - Wenn Sie über keine schnelle Internet-Anbindung - verfügen, sollten Sie die Nutzung von - CTM in Betracht - ziehen. - - Benutzen Sie Subversion, - wenn Sie schnellen Zugriff auf die Quellen brauchen und - die Bandbreite keine Rolle spielt, andernfalls benutzen - Sie CTM. - - - Lesen Sie /usr/src/Makefile sehr aufmerksam, bevor Sie &os.stable; übersetzen. Wenn Sie &os; das erste Mal aktualisieren, sollten Sie sowohl einen Kernel als auch das System neu installieren. 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. Die primären Dienste dafür - sind Subversion und - CTM. + 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. - - CTM - - CTM vergleicht die Quellen nicht - mit denen auf einem Server. Stattdessen läuft auf - dem Server ein Skript, das Änderungen an Dateien gegenüber - seinem vorigen Lauf bemerkt, die Änderungen komprimiert, mit - einer Sequenznummer versieht und für das Verschicken per E-Mail - kodiert. Dabei werden nur druckbare ASCII-Zeichen verwendet. - Wenn Sie diese CTM-Deltas erhalten haben, können - Sie sie mit &man.ctm.rmail.1; benutzen, welches die Deltas - dekodiert, verifiziert und dann die Änderungen an den Quellen - vornimmt. Dieses Verfahren ist viel effizienter als - Subversion und erzeugt auch weniger - Last auf den Servern, da es die - Push-Methode - - Von engl. to push = - schieben. Der Server schickt dem - Client die Dateien. - verwendet. - Es gibt noch weitere Unterschiede. Wenn ein Benutzer unabsichtlich Teile des Archivs löschen, wird das von - Subversion erkannt und repariert. - CTM leistet das nicht. Wenn ein - Benutzer Teile des Quellbaums gelöscht hat und keine Sicherung - besitzt, muss er von neuem, das heißt vom letzten - Basis-Delta, starten und die Änderungen wieder - mit CTM nachziehen. + Subversion erkannt und + repariert. Das komplette 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. Erstellen Sie eine Sicherungskopie! Es kann nicht oft genug betont werden, wie wichtig es ist, das System zu sichern, bevor die nachfolgenden Schritte ausgeführt werden. Obwohl der Neubau des Systems eine einfache Aufgabe ist, kann dennoch vorkommen, dass Fehler im Quellbaum dazu führen, dass das System nicht mehr bootet. Stellen Sie sicher, dass Sie eine Sicherung erstellt haben und über ein startfähiges Installationsmedium verfügen. Wahrscheinlich werden die Medien nicht benötigt, aber gehen Sie auf Nummer sicher! Abonnieren Sie die richtige Mailingliste Mailingliste Die &os.stable; und &os.current; Zweige befinden sich in ständiger Entwicklung. Die Leute, die zu &os; beitragen, sind Menschen und ab und zu machen sie Fehler. Manchmal sind diese Fehler harmlos und lassen das System eine Warnung ausgeben. Die Fehler können allerdings auch katastrophal sein und dazu führen, dass das System nicht mehr booten kann, oder Dateisysteme beschädigt werden. Wenn Probleme auftauchen, wird ein heads up an die passende Mailingliste geschickt, welches das Problem erklärt und die betroffenen Systeme benennt. Eine all clear Meldung wird versendet, wenn das Problem gelöst ist. Benutzer, die &os.stable; oder &os.current; benutzen und nicht die Mailinglisten &a.stable; beziehungsweise &a.current; lesen, bringen sich nur unnötig in Schwierigkeiten. 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. Richtig aktualisieren Bevor das System aktualisiert wird, lesen Sie /usr/src/UPDATING, um die für die Quellcodeversion nötigen Aufgaben zu erledigen, bevor das System neu gebaut wird. Danach kann das System mit den folgenden Schritten aktualisiert werden. Bei den hier dargestellten Aktualisierungsschritten wird davon ausgegangen, dass momentan eine alte &os;-Version verwendet wird, die aus einem alten Compiler, Kernel, sowie einem alten Basissystem und veralteten Konfigurationsdateien besteht. Mit Basissystem sind hier die zentralen Binärdateien, Bibliotheken und Entwicklerdateien gemeint. Der Compiler ist Teil des Basissystems, beinhaltet aber ein paar Besonderheiten. Es wird außerdem davon ausgegangen, dass bereits die Quellen für ein neues System bezogen wurden. Falls die Quellen nicht auf dem aktuellen Stand sind, lesen Sie , um detaillierte Hilfe über die Aktualisierung der Quellen zu erhalten. Die Aktualisierung des Systems aus den Quellen ist ein wenig ausgetüftelter als es zunächst den Anschein hat. Die Entwickler von &os; haben es über die Jahre für Nötig befunden, den vorgeschlagenen Ablauf ziemlich stark zu verändern, da neue Arten von unvermeidlichen Abhängigkeiten mit der Zeit ans Licht kamen. Der übrige Teil dieses Abschnitts beschreibt die Überlegungen hinter der aktuell empfohlenen Aktualisierungsreihenfolge. Jede erfolgreiche Aktualisierung muss sich mit den folgenden Sachverhalten auseinandersetzen: Der alte Compiler ist aufgrund von Fehlern möglicherweise nicht in der Lage, den neuen Kernel zu übersetzen. Deshalb sollte der neue Kernel mit dem neuen Compiler übersetzt werden, was bedeutet, dass der neue Compiler vor dem neuen Kernel gebaut werden muss. Das bedeutet nicht unbedingt, dass der neue Compiler auch installiert werden muss, bevor der neue Kernel gebaut wird. Das neue Basissystem benötigt eventuell neue Eigenschaften des Kernels. Also muss der neue Kernel installiert sein, bevor das neue Basissystem installiert wird. Diese ersten beiden Sachverhalte sind die Grundlage für die zentrale Sequenz von buildworld, buildkernel, installkernel und installworld, die in den folgenden Abschnitten beschrieben wird. Weitere Gründe für diese Vorgehensweise sind hier aufgeführt: 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 Grossteil Dateien oder fügt neue hinzu, bestehende Dateien werden nicht gelöscht. In wenigen Ausnahmefällen kann dies Probleme verursachen. Aus diesem Grund wird der Aktualisierungsprozess manchmal bestimmte Dateien zum manuellen Löschen vorschlagen. Dies wird eventuell in der Zukunft automatisch durchgeführt. Diese Bedenken haben zu der folgenden Reihenfolge geführt. Beachten Sie, dass der genaue Ablauf für bestimmte Aktualisierungen zusätzliche Schritte nach sich zieht, jedoch sollte der Kernprozess davon nicht beeinträchtigt werden: make buildworld Dieser Schritt übersetzt zuerst den neuen Compiler und ein paar damit zusammenhängende Werkzeuge und verwendet dann den neuen Compiler, um den Rest des Basissystems zu erstellen. Das Ergebnis landet dann in /usr/obj. make buildkernel Dieser Ansatz nutzt den neuen Compiler, der in /usr/obj abgelegt ist, um vor falschen Compiler-Kernel-Kombinationen zu schützen. make installkernel Platziert den neuen Kernel und Kernelmodule auf der Platte, was es erlaubt, mit dem frisch aktualisierten Kernel zu starten. Starten Sie das System neu in den Single-User-Modus. Der Single-User-Modus minimiert Probleme mit der Aktualisierung von Programmen, die bereits gestartet sind. Ebenso minimiert es Probleme, die mit der Verwendung des alten Basissystems und des neuen Kernels zu tun haben könnten. mergemaster -p Dieser Schritt aktualisiert ein paar initiale Konfigurationsdateien als Vorbereitung für das neue Basissystem. Beispielsweise fügt es neue Benutzergruppen zum System oder neue Benutzernamen in die Passwortdatenbank hinzu. Dies wird oftmals benötigt, wenn neue Gruppen oder bestimmte Systembenutzerkonten seit der letzten Aktualisierung hinzu gekommen sind, so dass der installworld-Schritt in der Lage ist, auf dem neu installierten System die Benutzer oder Systemgruppennamen ohne Probleme zu verwenden. make installworld Kopiert das Basissystem aus /usr/obj. Der neue Kernel und das neue Basissystem sind jetzt auf der Platte installiert. mergemaster Aktualisiert die verbleibenden Konfigurationsdateien, da nun das neue Basissystem auf der Platte ist. Starten Sie das System neu. Ein kompletter Systemneustart ist notwendig, um den neuen Kernel und das neue Basissystem mit den neuen Konfigurationsdateien zu laden. Beachten Sie, dass wenn Sie von einem Release des gleichen &os;-Zweigs auf ein aktuelleres Release des gleichen Zweigs, z.B. von 9.0 auf 9.1, aktualisieren, dann ist diese Vorgehensweise nicht unbedingt notwendig, da Sie nur sehr unwahrscheinlich in ungünstige Kombinationen zwischen Compiler, Kernel, Basissystem und den Konfigurationsdateien geraten werden. Die ältere Vorgehensweise von make world, gefolgt von der Erstellung und Installation des neuen Kernels funktioniert möglicherweise gut genug, um kleinere Aktualisierungen vorzunehmen. Wenn Sie allerdings zwischen Hauptversionen aktualisieren wollen und befolgen diese Schritte nicht, sollten Sie sich auf Probleme gefasst machen. Es ist auch wichtig zu wissen, dass viele Aktualisierungen spezielle und zusätzliche Schritte benötigen, wie beispielsweise das umbenennen oder löschen von bestimmten Dateien vor installworld. Lesen Sie /usr/src/UPDATING gründlich, besonders am Ende, wo die aktuell vorgeschlagene Aktualisierungssequenz explizit aufgelistet ist. Diese Prozedur hat sich mit der Zeit weiterentwickelt, da die Entwickler es für unmöglich erachtet haben, bestimmte Arten von Kombinationsproblemen vollständig auszuschliessen. Hoffentlich wird die aktuelle Aktualisierungsprozedur für lange Zeit stabil bleiben. Als Zusammenfassung ist hier nochmal die aktuell vorgeschlagene Vorgehensweise für die Aktualisierung von &os; aus den Quellen aufgelistet: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now Es gibt einige, sehr seltene Situationen, in denen Sie mergemaster -p zusätzlich ausführen müssen, bevor Sie das System mit buildworld bauen. Diese Situationen werden in UPDATING beschrieben. Solche Situationen treten aber in der Regel nur dann auf, wenn das &os;-System um eine oder mehrere Hauptversionen aktualisiert wird. Nachdem installkernel erfolgreich abgeschlossen wurde, starten Sie das System durch die Eingabe von boot -s am Loaderprompt im Single-User-Modus. Danach führen Sie die folgenden Kommandos aus: &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; reboot Lesen Sie bitte weiter Die folgenden Abschnitte beschreiben detailliert die einzelnen Schritte, insbesondere wenn eine angepasste Kernelkonfiguration verwendet wird. Lesen Sie <filename>/usr/src/UPDATING</filename> Lesen Sie vor der Aktualisierung /usr/src/UPDATING. Die Datei enthält wichtige Informationen zu potentiellen Problemen, und gibt die Reihenfolge vor, in der bestimmte Kommandos gestartet werden müssen. Die Anweisungen in UPDATING sind aktueller als die in diesem Handbuch. Im Zweifelsfall folgen Sie bitte den Anweisungen aus UPDATING. Das Lesen von UPDATING ersetzt nicht das Abonnieren der richtigen Mailingliste. Die beiden Voraussetzungen ergänzen sich, es reicht nicht aus, nur eine zu erfüllen. Überprüfen Sie <filename>/etc/make.conf</filename> make.conf Die verfügbaren &man.make.1;-Optionen werden in &man.make.conf.5; und /usr/share/examples/etc/make.conf dargestellt. Diese Einstellungen können in /etc/make.conf hinzugefügt werden, um das Verhalten von &man.make.1; beim Übersetzen von Programmen zu beeinflussen. Ä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. Die in /etc/make.conf gesetzten Optionen wirken sich bei jedem Aufruf von &man.make.1; aus, einschließlich der Übersetzung von Programmen aus der Ports-Sammlung, vom Benutzer geschriebene C-Programme oder beim Bau des &os;-Betriebssystems. <filename>/etc/src.conf</filename> überprüfen /etc/src.conf /etc/src.conf kontrolliert den Bau des Betriebssystems aus dem Quellcode. 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. Aktualisieren Sie die Dateien in <filename>/etc</filename> /etc enthält den Großteil der Konfigurationsdateien des Systems und Skripten, die beim Start des Systems ausgeführt werden. Einige dieser Skripten ändern sich bei einer Migration auf eine neue &os;-Version. Einige der Konfigurationsdateien, wie beispielsweise /etc/group, werden für den Normalbetrieb des Systems gebraucht. Es gab Fälle, in denen die Installationsroutine von make installworld auf bestimmte Accounts oder Gruppen angewiesen war. Bei einer Aktualisierung ist es jedoch wahrscheinlich, dass diese Accounts oder Gruppen noch nicht existieren. In einigen Fällen prüft make buildworld ob die Accounts oder Gruppen vorhanden sind. Um dieses Problem zu umgehen, rufen Sie &man.mergemaster.8; im prä-buildworld-Modus auf, der mit aktiviert wird. In diesem Modus werden nur Dateien verglichen, die für den Erfolg von buildworld oder installworld essentiell sind. Um im System nach Dateien zu suchen die der Gruppe gehören, die umbenannt oder gelöscht werden soll: &prompt.root; find / -group GID -print Dieses Kommando zeigt alle Dateien an, die der Gruppe GID gehören. Dies kann entweder ein Gruppenname oder eine numerische ID sein. Wechseln Sie in den Single-User-Modus Single-User-Modus Sie können das System im Single-User-Modus übersetzen. Bei der Installation des Systems werden viele wichtige Dateien, wie die Standard-Systemprogramme, die Bibliotheken und Include-Dateien, verändert. Sie bringen sich in Schwierigkeiten, wenn Sie diese Dateien auf einem laufenden System verändern, besonders dann, wenn zu dieser Zeit Benutzer auf dem System aktiv sind. Mehrbenutzermodus Bei dieser Methode übersetzen Sie das System im Mehrbenutzermodus und wechseln anschließend für die Installation in den Single-User-Modus. Wenn Sie diese Methode benutzen wollen, warten Sie mit den folgenden Schritten, bis der Bau des Systems abgeschlossen ist. Wechseln Sie dann in den Single-User-Modus, um installkernel oder installworld auszuführen. Mit dem folgenden Kommando kann ein laufendes System in den Single-User-Modus gebracht werden: &prompt.root; shutdown now Alternativ können Sie das System mit der Option single user in den Single-User-Modus booten. Geben Sie dann die folgenden Befehle am Single-User-Modus Shell-Prompt ein: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Die Kommandos überprüfen die Dateisysteme, hängen / wieder beschreibbar ein, hängen dann alle anderen UFS Dateisysteme aus /etc/fstab ein und aktivieren den Swap-Bereich. Zeigt die CMOS-Uhr die lokale Zeit und nicht GMT an (dies erkennen Sie daran, dass &man.date.1; die falsche Zeit und eine falsche Zeitzone anzeigt), setzen Sie das folgende Kommando ab: &prompt.root; adjkerntz -i Dies stellt sicher, dass die Zeitzone richtig eingestellt ist. Entfernen Sie <filename>/usr/obj</filename> Die neu gebauten Teile des Systems werden in der Voreinstellung unter /usr/obj gespeichert. Die Verzeichnisse dort spiegeln die Struktur unter /usr/src. Um den make buildworld Prozess zu beschleunigen und Ärger aufgrund von Abhängigkeiten zu vermeiden, können Sie dieses Verzeichnis entfernen. Einige Dateien unter /usr/obj haben vielleicht die -Option gesetzt, die zuvor mit &man.chflags.1; entfernt werden muss: &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Übersetzen der Quellen des Basissystems Sichern der Ausgaben Es ist ratsam, die Ausgaben von &man.make.1; 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 das Kommando &man.script.1; benutzen, dem Sie beim Aufruf als Parameter den Dateinamen für die Ausgaben mitgeben. Setzen Sie das 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 &prompt.root; make TARGET … Ausgaben des Kommandos … &prompt.root; exit Script done, … Sichern Sie die Ausgaben nicht in /tmp, da dieses Verzeichnis beim nächsten Reboot aufgeräumt werden kann. Ein geeigneteres Verzeichnis ist /var/tmp, oder das Heimatverzeichnis von root. Übersetzen des Basissystems Wechseln Sie in das Verzeichnis, in dem die Quellen liegen (in der Voreinstellung ist das /usr/src): &prompt.root; cd /usr/src make Benutzen Sie &man.make.1;, um das Basissystem neu zu bauen. Dieses Kommando liest Anweisungen aus einem Makefile, wechles beschreibt, wie die Programme, aus denen &os; besteht, zu bauen sind und in welcher Reihenfolge diese zu bauen sind. Ein typischer Aufruf von make sieht wie folgt aus: &prompt.root; make -x -DVARIABLE target In diesem Beispiel ist eine Option, die an &man.make.1; weitergegeben wird. Eine Liste gültiger Optionen finden Sie in &man.make.1;. Das Verhalten eines Makefiles wird von Variablen bestimmt. Mit setzen Sie eine Variable. Diese Variablen sind dieselben, die auch in /etc/make.conf gesetzt werden, dies ist nur ein alternativer Weg, Variablen zu setzen. Um zu verhindern, dass die profiled Bibliotheken gebaut werden, rufen Sie make wie folgt auf: &prompt.root; make -DNO_PROFILE target Dieser Aufruf entspricht dem folgenden Eintrag in /etc/make.conf: NO_PROFILE= true # Avoid compiling profiled libraries Jedes Makefile definiert einige Ziele, die festlegen, was genau zu tun ist. Mit target wählen Sie eins dieser Ziele aus. Einige Ziele im Makefile werden verwendet, um den Bauprozess in eine Reihe von Einzelschritten zu unterteilen. Im Regelfall müssen &man.make.1; keine Parameter mitgegeben werden, so dass die Kommandozeile wie folgt aussehen wird: &prompt.root; make target target steht dabei für die verschiedenen Ziele. Das erste Ziel sollte immer buildworld sein. Mit buildworld wird ein kompletter Baum unterhalb von /usr/obj gebaut, der mit installworld auf dem System installiert werden kann. Über separate Optionen zu verfügen, ist aus mehreren Gründen nützlich. Erstens können Sie das System gefahrlos auf einem laufenden System bauen, da die Bauprozedur vom Rest des Systems isoliert ist. Das System lässt sich im Mehrbenutzermodus ohne negative Seiteneffekte bauen. Die Installation mit installworld sollte aber immer noch im Single-User-Modus erfolgen. Zweitens kann NFS benutzt werden, um mehrere Maschinen in einem Netzwerk zu aktualisieren. Um die Maschinen A, B und C zu aktualisieren, lassen Sie make buildworld und make installworld auf A laufen. Auf den Maschinen B und C können Sie die Verzeichnisse /usr/src und /usr/obj von A einhängen und brauchen dort nur noch make installworld auszuführen, um die Bauresultate zu installieren. Obwohl das Ziel world noch existiert, sollte es wirklich nicht mehr benutzt werden. Benutzen Sie stattdessen: &prompt.root; make buildworld Mit können Sie make anweisen, mehrere Prozesse zu starten. Besonders effektiv ist das auf Mehrprozessor-Systemen. Da aber der Übersetzungsprozess hauptsächlich von I/O statt der CPU bestimmt wird, ist diese Option auch auf Einprozessor-Systemen nützlich. Auf einem typischen Einprozessor-System können Sie den folgenden Befehl eingeben: &prompt.root; make -j4 buildworld &man.make.1; wird dann bis zu vier Prozesse gleichzeitig laufen lassen. Erfahrungsberichte aus den Mailinglisten zeigen, dass dieser Aufruf typischerweise den besten Geschwindigkeitsgewinn bringt. Wenn Sie ein Mehrprozessor-System besitzen und SMP im Kernel konfiguriert ist, probieren Sie Werte zwischen 6 und 10 aus. Laufzeiten Bau des Basissystems Laufzeiten Die Laufzeit eines Baus wird von vielen Faktoren beeinflusst, ein aktuelles System benötigt aber etwa zwei Stunden um &os.stable; zu bauen. Der Bau von &os.current; dauert etwas länger. Übersetzen und Installation des Kernels Kernel Übersetzen Kompilieren Sie einen neuen Kernel, um den vollen Nutzen aus dem System zu ziehen. Praktisch gesehen ist das sogar notwendig, da sich einige Datenstrukturen geändert haben und Programme wie &man.ps.1; und &man.top.1; nur mit einem Kernel zusammen arbeiten, der auch zu dem entsprechenden Quellcode passt. Am einfachsten und sichersten bauen Sie dazu den GENERIC Kernel. Obwohl der GENERIC Kernel vielleicht nicht alle Geräte unterstützt, sollte er alles enthalten, um das System in den Single-User-Modus zu booten. Dies ist auch ein guter Test, um zu sehen, dass das System ordnungsgemäß funktioniert. Nachdem das System mit GENERIC gebootet wurde und sichergestellt ist, dass das System funktioniert, kann ein neuer Kernel basierend auf einer angepassten Konfigurationsdatei erstellt werden. In &os; müssen Sie das Basissystem neu bauen, bevor Sie einen neuen Kernel erstellen. Verwenden Sie KERNCONF=MYKERNEL, um einen Kernel mit einer vorhandenen, angepassten Konfigurationsdatei zu erstellen: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MYKERNEL &prompt.root; make installkernel KERNCONF=MYKERNEL Wenn kern.securelevel einen Wert größer als 1 besitzt und der Kernel mit noschg oder ähnlichen Optionen geschützt ist, müssen Sie installkernel im Single-User-Modus ausführen. Andernfalls laufen diese beiden Kommandos 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. Booten Sie in den Single-User-Modus Single-User-Modus Booten Sie in den Single-User-Modus, um zu prüfen ob der neue Kernel funktioniert. Folgen Sie dazu den Anweisungen aus . Installation des Systems Nun kann das neue System mit installworld installiert werden: &prompt.root; cd /usr/src &prompt.root; make installworld Wenn mit make buildworld Variablen verwendet werden, müssen dieselben Variablen auch bei make installworld angegeben werden. Auf die anderen Optionen trifft das nur bedingt zu: darf 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. Aktualisieren der von <command>make installworld</command> ausgelassenen Dateien Neue oder geänderte Konfigurationsdateien aus einigen Verzeichnissen, besonders /etc, /var und /usr werden bei der Installationsprozedur nicht berücksichtigt. Diese Dateien können einfach mit &man.mergemaster.8; aktualisiert werden. Sichern Sie /etc für den Fall, dass während der Aktualisierung etwas schief geht. <command>mergemaster</command> TomRhodesBeigetragen von mergemaster &man.mergemaster.8; ist ein Bourne-Shell Skript, das dabei behilflich ist die Unterschiede zwischen den Konfigurationsdateien in /etc und denen im Quellbaum unter /usr/src/etc zu finden. mergemaster ist der empfohlene Weg, die Systemkonfiguration mit dem Quellbaum abzugleichen. Um zu beginnen, rufen Sie mergemaster auf. Ausgehend von / wird mergemaster 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. &man.mergemaster.8; zeigt Ihnen jede geänderte Datei an und Sie haben die Wahl, die neue Datei (in mergemaster wird sie 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 &man.diff.1; 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. Wählen Sie die Option nur dann, wenn Sie keinen Grund sehen, die aktuelle Datei zu ändern. Wenn Sie die temporäre Datei installieren, wird Ihre 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, zeigt &man.mergemaster.8; dieselbe Ausgabe, die bereits vor der Eingabeaufforderung ausgegeben wurde. Wenn &man.mergemaster.8; 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. Manueller Abgleich der Konfigurationsdateien Wenn Sie den Abgleich lieber selbst ausführen wollen, beachten Sie bitte, dass Sie nicht einfach die Dateien aus /usr/src/etc nach /etc kopieren können. Einige dieser Dateien müssen zuerst installiert werden, bevor sie benutzt werden können. Das liegt daran, dass /usr/src/etc keine exakte Kopie von /etc ist. Zudem gibt es Dateien, die sich in /etc befinden aber nicht in /usr/src/etc. Wenn Sie, wie empfohlen, mergemaster benutzen, können Sie direkt in den nächsten Abschnitt wechseln. Am einfachsten ist es, wenn Sie die neuen Dateien in ein temporäres Verzeichnis installieren und sie nacheinander auf Differenzen zu den bestehenden Dateien durchsehen. Sichern Sie die Inhalte von <filename>/etc</filename> Es wird empfohlen, zuerst das bestehende /etc an einen sicheren Ort zu kopieren: &prompt.root; cp -Rp /etc /etc.old Mit wird rekursiv kopiert und erhält die Attribute der kopierten Dateien, wie Zugriffszeiten und Eigentümer. Erstellen Sie ein temporäres Verzeichnis für die Installation der neuen Dateien in /etc. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Die obigen Kommandos bauen die nötige Verzeichnisstruktur auf und installieren die neuen Dateien in diese Struktur. Unterhalb von /var/tmp/root wurden einige leere Verzeichnisse angelegt, die Sie am besten wie folgt entfernen: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Dadurch werden alle leeren Verzeichnisse entfernt. Um die Warnungen über nicht leere Verzeichnisse zu unterdrücken, wurde die Standardfehlerausgabe nach /dev/null umgeleitet. /var/tmp/root enthält nun alle Dateien, die unterhalb von / installiert werden sollten. Sie müssen nun jede dieser Dateien mit den schon existierenden Dateien des Systems vergleichen. Einige der installierten Dateien unter /var/tmp/root beginnen mit einem .. Verwenden Sie ls -a um sicherzustellen, dass Sie alle derartigen Dateien finden. Benutzen Sie &man.diff.1;, um zwei Dateien zu vergleichen: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Dieses Kommando zeigt die Unterschiede zwischen der installierten Version von /etc/shells und der neuen Version in /var/tmp/root/etc/shells. Entscheiden Sie anhand der Unterschiede, ob Sie beide Dateien abgleichen, oder die alte Version durch die neue Version ersetzen wollen. Versehen Sie das temporäre Verzeichnis <filename>/var/tmp/root</filename> mit einem Zeitstempel Wenn das System oft neu gebaut wird, muss auch /etc genauso oft aktualisiert werden. Dies kann mit der Zeit ein bisschen mühsam werden. Um diesen Prozess zu beschleunigen, behalten Sie eine Kopie der Dateien, die zuletzt nach /etc installiert wurden. Folgen Sie der normalen Prozedur um das System zu bauen. Wenn Sie /etc und die anderen Verzeichnisse aktualisieren wollen, geben Sie dem temporären Verzeichnis einen Namen, der das aktuelle Datum enthält. &prompt.root; mkdir /var/tmp/root-20130214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-20130214 \ distrib-dirs distribution Gleichen Sie die Änderungen entsprechend der Anleitung von oben ab. Wenn Sie fertig sind, entfernen Sie das Verzeichnis /var/tmp/root-20130214 nicht. Nachdem die neuen Quellen heruntergeladen und gebaut haben, folgen Sie Schritt 1. Erstellen Sie ein neues Verzeichnis mit einem aktuellen Datum. Dieses Beispiel verwendet /var/tmp/root-20130221. Vergleichen Sie die Unterschiede, die sich in einer Woche ergeben haben, indem Sie &man.diff.1; rekursiv anwenden: &prompt.root; cd /var/tmp &prompt.root; diff -r root-20130214 root-20130221 Üblicherweise sind diese Differenzen kleiner, als die Differenzen zwischen /var/tmp/root-20130221/etc und /etc. Da die angezeigten Differenzen kleiner sind, ist es jetzt einfacher den Abgleich der Dateien in /etc durchzuführen. Wenn Sie fertig sind, können Sie das ältere der beiden /var/tmp/root-* Verzeichnisse entfernen: &prompt.root; rm -rf /var/tmp/root-20130214 Wiederholen Sie diesen Prozess jedes Mal wenn Sie Dateien in /etc abgleichen müssen. Benutzen Sie &man.date.1;, um die Verzeichnisnamen automatisch zu erzeugen: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Veraltete Dateien, Verzeichnisse und Bibliotheken löschen Anton Shterenlikht Basiert auf Notizen von Veraltete Dateien, Verzeichnisse und Bibliotheken 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 deren Funktion nicht mehr benötigt wird. Dies kann sowohl Dateien und Verzeichnisse, aber auch Bibliotheken betreffen. Diese veralteten Dateien sollten daher entfernt werden, wenn das System aktualisiert wird. Der Vorteil besteht darin, 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. Folgen Sie den Anweisungen in . 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 Weitere interessante targets finden Sie in /usr/src/Makefile. 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 Das System neu starten Nachdem Sie sich davon überzeugt haben, dass alle Dateien an der richtigen Stelle sind, starten Sie das System mit &man.shutdown.8; neu: &prompt.root; shutdown -r now Löschen von veralteten Bibliotheken 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 Ports-Sammlung enthält Werkzeuge, die Bibliothek-Abhängigkeiten prüfen können: sysutils/libchk sowie sysutils/bsdadminscripts. 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 Herzlichen Glückwunsch! Sie haben gerade erfolgreich ein &os; System aktualisiert. Es ist leicht einen Teil des Systems wiederherzustellen, für den Fall, dass Ihnen ein kleiner Fehler unterlaufen ist. Wenn beispielsweise während des Updates oder Abgleichs /etc/magic aus Versehen gelöscht wurde, wird &man.file.1; 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 Fragen Muss ich wirklich immer alles neu bauen, wenn sich etwas geändert hat? Darauf gibt es keine einfache Antwort. Was zu tun ist, 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 oder mindestens die statisch gelinkten Teile des Systems neu bauen. Letztendlich ist das Ihre Entscheidung. Sie 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. Der Bau bricht mit vielen Signal 11-Fehlern (oder anderen Signalnummern) ab. Was ist da passiert? Signal 11 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. Dies äußert sich darin, dass der Compiler mit seltsamen Signalen abbricht. 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 getauscht werden, um zu bestimmen, welche Komponente den Fehler verursacht. Kann /usr/obj entfernt werden, wenn ich fertig bin? Kurze Antwort: Ja. In /usr/obj 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. Erfahrene Benutzer können make buildworld anweisen, diesen Schritt zu überspringen. Nachfolgende Bauprozeduren werden dadurch erheblich schneller, da die meisten Quelldateien nicht mehr neu übersetzt werden müssen. Dafür können aber subtile Abhängigkeitsprobleme entstehen, die dazu führen, dass der Bau auf merkwürdige Weise abbrechen kann. Dies führt häufig zu unnötigen Diskussionen auf den &os; Mailinglisten, wenn sich jemand über einen kaputten Bau beschwert, aber nicht sieht, dass er Probleme hat, weil er eine Abkürzung genommen hat. Kann ein abgebrochener Bau weitergeführt werden? Das hängt davon ab, wieweit der Bauprozess fortgeschritten ist. Üblicherweise werden durch make buildworld essentielle Werkzeuge, wie &man.gcc.1; und &man.make.1;, 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, einschließlich der normalen Benutzerprogramme wie &man.ls.1; und &man.grep.1;, mit den neu erstellten Systemdateien gebaut. Während der letzten Phase können Sie relativ gefahrlos folgende Kommandos ausführen: … Fehler beheben … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all Diese Variablen verhindern, dass make buildworld die vorher erstellten Dateien löscht. Das Sie sich im letzten Schritt der Bauprozedur befinden, erkennen Sie daran, dass Sie in der Ausgabe von make buildworld die folgenden Zeilen finden: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- Wenn diese Meldung nicht angezeigt wird, oder Sie sich nicht sicher sind, dann ist es besser, noch einmal ganz von Vorne anzufangen. Wie kann ich den Bauprozess beschleunigen? Bauen Sie im Single-User-Modus. Legen Sie /usr/src und /usr/obj in getrennte Dateisysteme auf unterschiedliche Festplatten. Benutzen Sie nach Möglichkeit auch getrennte Platten-Controller. Alternativ können diese Dateisysteme mit &man.ccd.4; auf mehrere Festplatten verteilt werden. Deaktivieren Sie den Bau der profiled-Bibliotheken, indem Sie NO_PROFILE=true in /etc/make.conf aufnehmen. Benutzen Sie make zusammen mit , um mehrere Prozesse parallel laufen zu lassen. Normalerweise beschleunigt dies den Bauprozess auf Einprozessor- und Mehrprozessorsystemen. Das Dateisystem /usr/src kann mit der Option eingehangen werden. Dies verhindert, dass die Zugriffszeiten der Dateien aktualisiert werden. &prompt.root; mount -u -o noatime /usr/src Das Beispiel geht davon aus, dass sich /usr/src auf einem separaten Dateisystem befindet. Wenn es Teil des /usr Dateisystems ist, muss dieses Dateisystem als Mountpoint angegeben werden. 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. &prompt.root; mount -u -o async /usr/obj Ersetzen Sie /usr/obj durch den Mountpoint des entsprechenden Dateisystems, wenn es sich nicht auf einem eigenen Dateisystem befindet. Was mache ich, wenn etwas nicht funktioniert? Stellen Sie sicher, dass sich in Ihrer 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 Ihrer Umgebung zu beantworten. Installation mehrerer Maschinen MikeMeyerBeigetragen von Wenn Sie mehrere Maschinen alle 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 Ihnen wie das geht. Voraussetzungen 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 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 sollte eine Maschine, eventuell der Bau-Master, sein, die über einen längeren Zeitraum nicht zur Verfügung stehen kann. Alle Maschinen der Baugruppe müssen /usr/obj und /usr/src von derselben Maschine an gleichem Ort einhängen. Idealerweise befinden sich die beiden Verzeichnisse auf dem Bau-Master auf verschiedenen Festplatten, sie können allerdings auch auf dem Bau-Master über NFS zur Verfügung gestellt werden. 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. Installation des Basissystems 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. Wenn diese Maschine /usr/src und /usr/obj über NFS bekommt, müssen Sie das Netzwerk im Single-User-Modus aktivieren und die beiden Dateisysteme einhängen. Am einfachsten ist dies, wenn Sie auf der Testmaschine vom Mehrbenutzermodus mit shutdown now in den Single-User-Modus wechseln. Sie können dann mit der normalen Prozedur den neuen Kernel und das System installieren und anschließend mergemaster laufen lassen. Wenn Sie damit fertig sind, können Sie die Maschine wieder in den Mehrbenutzermodus booten. Nachdem Sie sichergestellt haben, dass die Testmaschine einwandfrei funktioniert, wiederholen Sie diese Prozedur für jede Maschine in der Baugruppe. Die Ports-Sammlung Dasselbe Verfahren können Sie auch für die Ports-Sammlung anwenden. Zuerst müssen alle Maschinen einer Baugruppe /usr/ports von derselben Maschine über NFS zur Verfügung gestellt bekommen. Setzen Sie dann 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. Index: head/de_DE.ISO8859-1/books/handbook/mirrors/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/mirrors/chapter.xml (revision 48976) +++ head/de_DE.ISO8859-1/books/handbook/mirrors/chapter.xml (revision 48977) @@ -1,954 +1,595 @@ Bezugsquellen für &os; <acronym>CD</acronym> und <acronym>DVD</acronym> Sets Die &os;-CDs und -DVDs werden von verschiedenen Online-Händlern angeboten:
&os; Mall, Inc. 2420 Sand Creek Rd C-1 #347 Brentwood, CA 94513 USA Telefon: +1 925 240-6652 Fax: +1 925 674-0821 E-Mail: info@freebsdmall.com WWW: http://www.freebsdmall.com/
Getlinux 78 Rue de la Croix Rochopt Épinay-sous-Sénart 91860 France E-Mail: contact@getlinux.fr WWW: http://www.getlinux.fr/
Dr. Hinner EDV Kochelseestr. 11 D-81371 München Germany Telefon: (0177) 428 419 0 E-Mail: infow@hinner.de WWW: http://www.hinner.de/linux/freebsd.html
Linux Center Galernaya Street, 55 Saint-Petersburg 190000 Russia Telefon: +7-812-309-06-86 E-Mail: info@linuxcenter.ru WWW: http://linuxcenter.ru/shop/freebsd
<acronym>FTP</acronym>-Server Die offiziellen Quellen von &os; sind mit anonymous FTP über ein weltweites Netz von Spiegeln erhältlich. Die Seite ftp://ftp.FreeBSD.org/pub/FreeBSD/ ist über HTTP und FTP erreichbar. Sie besteht aus mehreren Servern, die von den Cluster-Administratoren des Projekts über GeoDNS betrieben wird, um Benutzer auf den nächsten verfügbaren Spiegel umzuleiten. Sie können &os; auch über anonymous FTP von den folgenden Spiegeln beziehen. Wenn Sie &os; über anonymous FTP beziehen wollen, wählen Sie bitte einen Spiegel in Ihrer Nähe. Die unter Haupt-Spiegel aufgeführten Spiegel stellen normalerweise das komplette &os;-Archiv (alle momentan erhältlichen Versionen für jede unterstützte Architektur) zur Verfügung. Wahrscheinlich geht es aber schneller, wenn Sie einen Spiegel in Ihrer Nähe benutzen. Die Länder-Spiegel stellen die neusten Versionen für die beliebtesten Architekturen bereit, sie stellen aber unter Umständen nicht das komplette &os;-Archiv bereit. Auf alle Server kann mit anonymous FTP zugegriffen werden, einige Server bieten auch andere Zugriffsmethoden an. Die zur Verfügung stehenden Zugriffsmethoden sind bei jedem Server in Klammern angegeben. &chap.mirrors.ftp.index.inc; &chap.mirrors.lastmod.inc; &chap.mirrors.ftp.inc; - - CTM - - - CTM - - - Mit CTM - Abkürzung für CVS Through eMail - - können Sie einen - entfernten Verzeichnisbaum mit einem zentralen Baum - synchronisieren. Es wurde extra zum Synchronisieren der &os; - Quellen entwickelt, obwohl es mit der Zeit vielleicht auch andere - Anwendungen geben wird. Zurzeit existiert leider so gut wie keine - Dokumentation zum Erstellen der Deltas. Wenn Sie Hilfe - benötigen oder CTM für - andere Zwecke einsetzen wollen, wenden Sie sich bitte an - die Mailingliste &a.ctm-users.name;. - - - Warum soll ich <application>CTM</application> benutzen? - - Mit CTM erhalten Sie eine lokale - Kopie des &os;-Quellbaums, den es in mehreren - Varianten gibt. Sie können das ganze - Repository oder nur einen Zweig spiegeln. Wenn Sie ein aktiver - &os;-Entwickler mit einer schlechten oder gar keiner TCP/IP - Verbindung sind, oder die Änderungen einfach automatisch - zugesandt bekommen wollen, dann ist CTM - das Richtige für Sie. Für die Zweige mit der - meisten Aktivität müssen Sie sich täglich bis zu drei - Deltas beschaffen, Sie sollten allerdings erwägen, die - Deltas automatisch über E-Mail zu beziehen. Die - Größe der Updates wird so klein wie möglich - gehalten. Normalerweise sind sie kleiner als 5 kB, manchmal - sind sie 10-50 kB groß (etwa jedes 10. Update) und ab - und an werden Sie auch einmal ein Update mit 100 kB oder - mehr erhalten. - - Sie sollten sich über die Vorbehalte gegen die - Verwendung der Quellen anstelle eines offiziellen Releases - bewusst sein. Das trifft besonders auf &os.current; zu, lesen - Sie dazu bitte den Abschnitt - &os.current;. - - - - Was brauche ich, um <application>CTM</application> zu - benutzen? - - Zwei Sachen: Das CTM Programm und - die initialen Deltas, von denen aus Sie auf die - aktuellen Stände kommen. - - CTM ist schon seit der - Version 2.0 Teil des &os;-Basissystems. Sie finden es in - /usr/src/usr.sbin/ctm, wenn Sie eine Kopie - der Quellen besitzen. - - Die Deltas, die CTM verarbeitet, - können Sie über FTP oder E-Mail beziehen. Wenn Sie - über einen FTP Zugang zum Internet verfügen, erhalten - Sie die Deltas unter der folgenden URL: - - - ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/ - - - Die Deltas werden auch von - CTM Spiegeln - bereitgehalten. - - Wechseln Sie in das passende Verzeichnisse zum Beispiel - src-cur für &os.current; und laden Sie - sich von dort die Deltas herunter. - - Sie können die Deltas auch über E-Mail - beziehen. - - Abonnieren Sie dazu eine der - CTM-Verteilerlisten. - Über &a.ctm-src-cur.name; erhalten Sie den kompletten - Subversion-Baum, über - &a.ctm-src-cur.name; erhalten Sie &os.current; und über - &a.ctm-src-9.name; erhalten Sie den &os; - 9.X-Zweig. Wenn Sie nicht wissen, wie Sie eine der - Mailinglisten abonnieren, folgen Sie einem der Verweise - von oben oder besuchen Sie die Seite &a.mailman.lists.link;. - Weitere Informationen erhalten Sie, wenn Sie dort - auf die gewünschte Liste klicken. - - Benutzen Sie ctm_rmail, um die - CTM Updates, die Sie per - E-Mail empfangen, auszupacken und anzuwenden. Wenn Sie diesen - Prozess automatisiert ablaufen lassen möchten, - können Sie dazu einen Eintrag in - /etc/aliases verwenden. Genauere - Informationen finden Sie in der Manualpage von - ctm_rmail. - - - Sie sollten die Mailingliste &a.ctm-announce.name; - abonnieren, egal wie Sie die - CTM-Deltas erhalten. - Ankündigungen, die den Betrieb des - CTM-Systems betreffen, werden - nur auf dieser Liste bekannt gegeben. Klicken Sie - auf den Namen der Liste oder besuchen Sie die Seite - &a.mailman.lists.link;, um diese Liste zu abonnieren. - - - - - Initialisieren von <application>CTM</application> - - Bevor Sie die CTM Deltas benutzen - können, brauchen Sie einen Startpunkt, auf den die - nachfolgenden Deltas angewendet werden. - - Sie können natürlich mit einem leeren Verzeichnis - beginnen. In diesem Fall benötigen Sie ein - XEmpty-Delta, mit dem Sie den - CTM-Verzeichnisbaum initialisieren. - Wenn Sie Glück haben, finden Sie ein - XEmpty-Delta, mit dem sie beginnen können, - auf einer der CDs Ihrer Distribution. - - Da die Verzeichnisbäume mehrere Megabyte groß - sind, sollten Sie nach Möglichkeit etwas schon vorhandenes - benutzen. Wenn Sie eine -RELEASE CD besitzen, können Sie - die Quellen von dieser CD benutzen. Sie ersparen sich damit das - Übertragen großer Datenmengen. - - Die Deltas, mit denen Sie beginnen können, enthalten ein - X in ihrem Namen, wie in - src-cur.3210XEmpty.gz. Hinter dem - X wird der Startpunkt der Deltas - angegeben, in diesem Fall steht Empty - für ein leeres Verzeichnis. Nach etwa 100 Deltas wird ein - neues XEmpty-Delta erstellt. - Mit ungefähr 75 Megabyte komprimierter Daten sind diese - XEmpty-Deltas übrigens sehr - groß. - - Nachdem Sie Ihren Startpunkt festgelegt haben, benötigen - Sie alle Deltas mit einer höheren Nummer. - - - - Benutzen von <application>CTM</application> - - Um ein Delta einzuspielen, benutzen Sie das folgende - Kommando: - - &prompt.root; cd /Pfad/zu/den/Quellen -&prompt.root; ctm -v -v /Pfad/zu/den/Deltas/src-xxx.* - - CTM kann mit Deltas arbeiten, die - mit gzip komprimiert wurden. Sie brauchen die - Deltas vorher nicht mit gunzip zu - dekomprimieren und sparen damit Plattenplatz. - - Ihr Quellbaum wird erst dann verändert, wenn - CTM die Deltas sauber verarbeiten - kann. Die Integrität der Deltas und ihre Anwendbarkeit auf - den Quellbaum lassen sich durch die Angabe des Schalters - -c überprüfen, - CTM ändert in diesem Fall Ihren - Quellbaum nicht. - - CTM verfügt über weitere - Kommandozeilenoptionen, Informationen dazu finden Sie in der - Manualpage oder dem Quellcode. - - Das war schon alles. Um Ihre Quellen aktuell zu halten, - verwenden Sie CTM jedes Mal, wenn Sie - neue Deltas bekommen. - - Löschen Sie die Deltas nicht, wenn Sie diese nur schwer - wieder beschaffen können. Behalten Sie sie für den - Fall, das etwas passiert. Auch wenn Sie nur Disketten besitzen, - sollten Sie erwägen, die Deltas mit - fdwrite zu sichern. - - - - Umgang mit lokalen Änderungen - - Entwickler wollen mit den Dateien im Quellbaum - experimentieren und diese verändern. In beschränkter - Weise werden lokale Änderungen von - CTM unterstützt. Wenn - CTM die Datei foo - bearbeiten will, überprüft es zuerst ob die Datei - foo.ctm existiert. Wenn diese Datei - existiert, werden Änderungen in ihr anstatt in - foo vorgenommen. - - Mit diesem Verfahren ist eine leichte Handhabung lokaler - Änderungen möglich. Kopieren Sie die Dateien, die Sie - ändern möchten, in Dateien, die das Suffix - .ctm tragen. Sie können dann - ungestört mit dem Quellcode arbeiten, während - CTM die - .ctm Dateien aktualisiert. - - - - Weitere <application>CTM</application>-Optionen - - - Was wird aktualisiert? - - Eine Liste der Änderungen, die - CTM an Ihrem Quellbaum vornehmen - wird, erhalten Sie, wenn Sie die Option - angeben. - - Das ist nützlich, wenn Sie Logs über die - Änderungen führen wollen, geänderte Dateien vor- - oder nachbearbeiten wollen, oder einfach ein bisschen - paranoid sind. - - - - Sicherungen vor einer Aktualisierung erstellen - - Sie wollen vielleicht die Dateien, die durch eine - CTM Aktualisierung verändert - werden, sichern. - - Mit weisen Sie - CTM an, alle Dateien, die durch ein - CTM Delta verändert - würden, nach backup-file zu - sichern. - - - - Dateien ausschließen - - Manchmal wollen Sie nur bestimmte Teile aktualisieren - oder nur bestimmte Dateien aus einer Folge - von Deltas extrahieren. - - Sie können die Liste der Dateien, mit denen - CTM arbeitet, einschränken, - indem Sie reguläre Ausdrücke mit den Optionen - und angeben. - - Wenn Sie eine aktuelle Kopie von - lib/libc/Makefile aus den gesicherten - CTM Deltas erhalten wollen, setzen - Sie das folgende Kommando ab: - - &prompt.root; cd /wo/Sie/es/auspacken/wollen/ -&prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* - - Die Optionen und - werden in der Reihenfolge angewandt, in der sie auf der - Kommandozeile angegeben wurden. Eine Datei wird nur dann von - CTM verarbeitet, wenn dies nach der - Anwendung der Optionen und - noch erlaubt ist. - - - - - Pläne für <application>CTM</application> - - Mehrere: - - - - Hinzufügen eines Authentifizierungsmechanismus, - damit gefälschte CTM-Deltas - erkannt werden können. - - - - Aufräumen der - CTM-Optionen, die mit der Zeit - unübersichtlich und irreführend wurden. - - - - - - Verschiedenes - - Es gibt Deltas für die Ports-Sammlung, die - aber nicht intensiv genutzt werden. - - - - CTM-Spiegel - - Die CTM-Deltas können Sie mit anonymous FTP von den folgenden - Spiegeln beziehen. Versuchen Sie bitte einen Spiegel in Ihrer - Nähe zu benutzen. - - Bei Problemen wenden Sie sich bitte an die - Mailingliste &a.ctm-users.name;. - - - - Kalifornien, Bay Area, Offizieller Server - - - - - ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CTM/ - - - - - - - Südafrika, Backup-Server für alte Deltas - - - - - ftp://ftp.za.FreeBSD.org/pub/FreeBSD/CTM/ - - - - - - - Taiwan/R.O.C. - - - - - ftp://ctm.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ - - - - ftp://ctm2.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ - - - - ftp://ctm3.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ - - - - - - - Wenn die Liste keinen Spiegel in Ihrer Nähe enthält - oder Sie Probleme mit dem ausgewählten Spiegel haben, versuchen - Sie einen Spiegel mit einer Suchmaschine, wie - alltheweb, zu - finden. - - Benutzen von <application>Subversion</application> Subversion Einführung Seit Juli 2012 nutzt &os; ausschließlich Subversion als Versionskontrollsystem zur Speicherung des gesamten &os; Quellcodes, der Dokumentation und der Ports-Sammlung. Subversion ist hauptsächlich ein Werkzeug für Entwickler. Die meisten Benutzer bevorzugen freebsd-update () um das &os; Basissystem zu aktualisieren, und portsnap () um die &os; Ports-Sammlung aktuell zu halten. Dieser Abschnitt zeigt, wie Subversion unter &os; installiert wird und wie Sie damit eine lokale Kopie des &os; Repositories erstellen. Weitere Informationen über die Benutzung von Subversion sind ebenfalls enthalten. Svnlite Mit svnlite enthält &os; bereits eine vereinfachte Version von Subversion. Der Port oder das Paket ist nur erforderlich, wenn die Python oder Perl API benötigt wird, oder eine neuere Version von Subversion gewünscht ist. Der einzige Unterschied zum normalen Subversion ist, dass der Name des Kommandos svnlite lautet. Installation Falls svnlite nicht verfügbar ist, oder die komplette Version von Subversion benötigt wird, muss das Programm installiert werden. Subversion kann aus der Ports-Sammlung installiert werden: &prompt.root; cd /usr/ports/devel/subversion &prompt.root;make install clean Subversion kann auch als Paket installiert werden: &prompt.root; pkg install subversion <application>Subversion</application> benutzen Der svn Befehl wird verwendet, um eine Kopie der Quellen in ein lokales Verzeichnis zu holen. Die Dateien in diesem Verzeichnis werden lokale Arbeitskopie genannt. Verschieben oder löschen Sie das lokale Verzeichnis bevor Sie checkout benutzen. In ein bestehendes nicht-svn Verzeichnis auszuchecken kann zu Konflikten zwischen den vorhandenen Dateien und denen aus dem Respository führen. In Subversion werden URLs in der Form von protocol://hostname/path verwendet, um ein Repository zu kennzeichnen. Die Spiegel können, wie unten angegeben, verschiedene Protokolle unterstützen. Die erste Komponente des Pfades ist das &os; Repository auf welches zugegriffen wird. Es gibt drei verschiedene Repositories. base für den Quellcode des &os; Basissystems, ports für die Ports-Sammlung und doc für die Dokumentation. Als Beispiel spezifiziert die URL svn://svn.FreeBSD.org/ports/head/ den Hauptzweig des Port-Repositories auf dem Mirror svn.FreeBSD.org, über das svn-Protokoll. Das Auschecken aus einem bestimmten Repository kann wie folgt durchgeführt werden: &prompt.root; svn checkout svn-mirror/repository/branch lcwdir wobei: svn-mirror eine URL für einen Mirror aus Subversion Mirror Sites ist. repository eines der Projekt-Repositories ist, z. B. base, ports oder doc. branch vom verwendeten Repository abhängt. ports und doc werden meist im head Zweig aktualisiert, während base die neueste Version von -CURRENT unter head und die jeweilige neueste Version des -STABLE Zweiges unter stable/8 (für 8.x), stable/9 (9.x) und stable/10 (10.x) verwaltet wird. lcwdir das Zielverzeichnis ist, in dem die Inhalte des angegebenen Zweiges plaziert werden sollen. Dies ist üblicherweise /usr/ports für ports, /usr/src für base, und /usr/doc für doc. Dieses Beispiel checkt die Ports-Sammlung aus dem Repositroy über das HTTPS-Protokoll aus, und speichert die Arbeitskopie unter /usr/ports. Wenn /usr/ports bereits vorhanden ist, aber nicht von svn erstellt wurde, denken Sie vor dem Auschecken daran, das Verzeichnis umzubenennen oder zu löschen. &prompt.root; svn checkout https://svn.FreeBSD.org/ports/head /usr/ports Dies kann eine Weile dauern, da beim ersten Auschecken der komplette Zweig vom entfernten Repository heruntergeladen werden muss. Bitte haben Sie Geduld. Nach dem ersten Auschecken können Sie Ihre lokale Arbeitskopie wie folgt aktualisieren: &prompt.root; svn update lcwdir Um /usr/ports aus dem oben erstellten Beispiel zu aktualisieren, benutzen Sie: &prompt.root; svn update /usr/ports Das Update ist viel schneller als ein Auschecken, da nur die Dateien übertragen werden müssen, die sich auch geändert haben. Eine alternative Möglichkeit zur Aktualisierung Ihrer Arbeitskopie nach dem Auschecken ist es, das bestehende Makefile in den Verzeichnissen /usr/ports, /usr/src, und /usr/doc zu nutzen. Setzen Sie dazu SVN_UPDATE und benutzen Sie das update Ziel. Zum Beispiel, um /usr/src zu aktualisieren: &prompt.root; cd /usr/src &prompt.root; make update SVN_UPDATE=yes <application>Subversion</application> Mirror Sites Subversion Repository Mirror Sites Das &os; Subversion Repository, svn.FreeBSD.org ist ein öffentlich zugängliches Netzwerk aus Spiegeln, das GeoDNS verwendet, um einen entsprechenden Backend-Server auszuwählen. Um das &os; Subversion Repository über einen Browser anzuzeigen, verwenden Sie http://svnweb.FreeBSD.org/. Die &os; Subversion Spiegel verwendeten zuvor selbst signierte SSL-Zertifikate, wie bereits in diesem Kapitel erwähnt wurde. Seit dem 14. Juli 2015 verwenden nun alle Spiegel offizielle SSL-Zertifikate, die von Subversion erkannt werden, wenn der Port security/ca_root_nss installiert ist. Die alten, selbst signierten Zertifikate sind noch verfügbar, gelten mittlerweile aber veraltet. Falls der Port security/ca_root_nss nicht installiert ist, finden Sie hier die SHA1- und SHA256-Fingerabdrücke: Hash Fingerabdruck SHA1 E9:37:73:80:B5:32:1B:93:92:94:98:17:59:F0:FA:A2:5F:1E:DE:B9 SHA256 D5:27:1C:B6:55:E6:A8:7D:48:D5:0C:F0:DA:9D:51:60:D7:42:6A:F2:05:F1:8A:47:BE:78:A1:3A:72:06:92:60 HTTPS ist das bevorzugte Protokoll, es schützt Sie vor anderen Computern, die vortäuschen, der &os;-Mirror zu sein (gemeinhin bekannt als man in the middle-Angriff), oder anderweitig versuchen schlechte Daten an den Endnutzer zu senden. Wenn https aufgrund von Firewall- oder anderen Problemen nicht verwendet werden kann, dann ist svn die nächste Wahl. Sollte beides nicht verfügbar sein, nutzen Sie http. Diejenigen, die immer noch die veralteten Servernamen verwenden, finden hier die entsprechenden SHA1- und SHA256-Fingerabdrücke: Hash Fingerabdruck SHA1 (veraltet) 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 SHA1 (veraltet) F6:44:AA:B9:03:89:0E:3E:8C:4D:4D:14:F0:27:E6:C7:C1:8B:17:C5 SHA256 (veraltet) 47:35:A9:09:A3:AB:FA:20:33:36:43:C5:1A:D6:E6:FB:EB:C0:C0:83:37:D4:46:9C:A0:AB:89:7F:C2:9C:4C:A3 SHA256 (veraltet) 48:3C:84:DB:7C:27:1B:FA:D5:0B:A0:D7:E0:4C:79:AA:A3:8E:A3:FA:84:E6:32:34:7D:EB:30:E6:11:01:CF:BE Wenn Sie einen dieser Fingerabdrücke sehen, bedeutet dass wahrscheinlich, dass ein veralteter Servername verwendet wird. Weiterführende Informationen Weitere Informationen über die Verwendung von Subversion finden Sie im Subversion Buch mit dem Namen Versionskontrolle mit Subversion, oder in der Subversion Dokumentation. Benutzen von <application>rsync</application> rsync wird ähnlich wie &man.rcp.1; verwendet, besitzt aber mehr Optionen und verwendet das rsync remote-update Protokoll, das nur geänderte Dateien überträgt und damit viel schneller als ein normaler Kopiervorgang ist. rsync ist sehr nützlich, wenn Sie einen &os;-FTP-Spiegel oder einen CVS-Spiegel betreiben. Das Programm ist für viele Betriebssysteme erhältlich, mit &os; können Sie den Port net/rsync oder das fertige Paket benutzen. Die folgenden Server stellen &os; über das rsync Protokoll zur Verfügung: Großbritannien rsync://rsync.mirrorservice.org/ Verfügbare Sammlungen: ftp.freebsd.org: Kompletter Spiegel des &os;-FTP-Servers. Niederlande rsync://ftp.nl.FreeBSD.org/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers. Russland rsync://ftp.mtu.ru/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers. &os;-Archive: Ein Spiegel des &os;-Archive-FTP-Servers. Schweden rsync://ftp4.se.freebsd.org/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers. Taiwan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers. Tschechische Republik rsync://ftp.cz.FreeBSD.org/ Verfügbare Sammlungen: ftp: Unvollständiger Spiegel des &os;-FTP-Servers. &os;: Vollständiger Spiegel des &os;-FTP-Servers. USA rsync://ftp-master.FreeBSD.org/ Dieser Server darf nur von primären Spiegeln benutzt werden. Verfügbare Sammlungen: &os;: Das Hauptarchiv des &os; FTP Servers. acl: Die primäre ACL-Liste. rsync://ftp13.FreeBSD.org/ Verfügbare Sammlungen: &os;: Kompletter Spiegel des &os;-FTP-Servers.