diff --git a/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.sgml index b64ea6069a..ed8e11e0cc 100644 --- a/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,1942 +1,1959 @@ Jim Mock Umstrukturiert und aktualisiert von Jordan Hubbard Im Original von Poul-Henning Kamp John Polstra Nik Clayton Martin Heinen Übersetzt von Das Neueste und Beste Übersicht &os; wird zwischen einzelnen Releases konstant weiter entwickelt. Es gibt mehrere einfache Möglichkeiten, ein System auf dem aktuellen Stand der Entwicklung zu halten. Seien Sie jedoch gewarnt: Die neueste Version ist nicht für jeden geeignet! Dieses Kapitel hilft Ihnen bei der Entscheidung, ob Sie mit dem Entwicklungssystem Schritt halten oder ein Release verwenden wollen. Nachdem Sie dieses Kapitel gelesen haben, werden Sie den Unterschied der beiden Entwicklerversionen &os.stable; und &os.current; kennen, wissen, wie Sie Ihr System mit CVSup, CVS oder CTM aktualisieren. Wissen, wie Sie mit make world das komplette Basissystem wieder neu bauen und installieren können. Bevor Sie dieses Kapitel lesen, sollten Sie Ihr Netzwerk richtig konfiguriert haben () und wissen, wie Sie Software Dritter installieren (). &os.current; vs. &os.stable; -CURRENT -STABLE FreeBSD besitzt zwei Entwicklungszweige: &os.current; und &os.stable;. Dieser Abschnitt beschreibt beide Zweige und erläutert, wie Sie Ihr System auf dem aktuellen Stand eines Zweiges halten. Zuerst wird &os.current; vorgestellt, dann &os.stable;. &os.current; Beachten Sie im Folgenden, dass &os.current; die Spitze der Entwicklung von &os; ist. 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, überlegen Sie sich genau, ob Sie &os.current; benutzen wollen. Was ist &os.current;? Snapshot &os.current; besteht aus den neuesten Quellen des FreeBSD-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 gelöst, aber ob Sie mit &os.current; Schiffbruch erleiden oder die gewünschten Verbesserungen erhalten, kann von dem Zeitpunkt abhängen, an dem Sie sich den Quelltext besorgt haben! Wer braucht &os.current;? &os.current; wird hauptsächlich für 3 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. Weiterhin Leute, die Vorschläge zu Änderungen oder der generellen Entwicklung von &os; machen und Patches bereitstellen, um diese Vorschläge zu realisieren. Für Leute, die die Entwicklung im Auge behalten wollen, oder die Quellen zu Referenzzwecken (zum Beispiel darin lesen, aber nicht verwenden) benutzen wollen. Auch diese Gruppe macht Vorschläge oder steuert Quellcode bei. Was &os.current; <emphasis>nicht</emphasis> ist! Der schnellste Weg, neue Sachen vor dem offiziellen Release auszuprobieren. Bedenken Sie, dass der erste, der die neuen Sachen ausprobiert, auch der erste ist, der die neuen Fehler findet. Ein schneller Weg, um an Fehlerbehebungen (engl. bug fixes) zu kommen. Jede Version von &os.current; führt mit gleicher Wahrscheinlichkeit neue Fehler ein, mit der sie alte behebt. In irgendeiner Form offiziell unterstützt. Wir tun unser Bestes, um Leuten aus den drei legitimen Benutzergruppen von &os.current; zu helfen, aber wir haben einfach nicht die Zeit, technische Unterstützung zu erbringen. Das kommt nicht daher, dass wir kleinliche, gemeine Leute sind, die anderen nicht helfen wollen (wenn wir das wären, würden wir &os; nicht machen), wir können einfach nicht jeden Tag Hunderte Nachrichten beantworten und an &os; arbeiten! Vor die Wahl gestellt, &os; zu verbessern oder jede Menge Fragen zu experimentellem Code zu beantworten, haben sich die Entwickler für ersteres entschieden. Benutzen von &os.current; + + -CURRENT + benutzen + Es ist essentiell, die Mailinglisten &a.current; und &a.cvsall; zu lesen. Wenn Sie &a.current; nicht lesen, verpassen Sie die Kommentare anderer über den momentanen Zustand des Systems und rennen demzufolge in viele bekannte Probleme, die schon gelöst sind. Noch kritischer ist, dass Sie wichtige Bekanntmachungen verpassen, die erhebliche Auswirkungen auf die Stabilität Ihres Systems haben können. In der &a.cvsall; Mailingliste sehen Sie zu jeder Änderung das Commit-Log, das Informationen zu möglichen Seiteneffekten enthält. Um diese Listen zu lesen, senden Sie eine E-Mail mit dem folgenden Inhalt im Textkörper der Nachricht an &a.majordomo;: subscribe freebsd-current subscribe cvs-all Majordomo Sie können Majordomo auch den Text help schicken und erhalten dann eine ausführliche Hilfe, die beschreibt, wie Sie die verschiedenen Mailinglisten abonnieren bzw. wieder abbestellen. Beschaffen Sie sich die Quellen von ftp.FreeBSD.org. Sie haben dazu drei Möglichkeiten: cvsup cron -CURRENT Synchronisation mit CVSup Benutzen Sie cvsup mit einer geeigneten Sup-Datei. Dies ist die empfohlene Methode, da Sie die ganzen Quellen nur einmal herunterladen und danach nur noch Änderungen beziehen. Viele lassen cvsup aus cron heraus laufen, um ihre Quellen automatisch auf Stand zu bringen. Sie müssen die obige Sup-Datei anpassen und cvsup in Ihrer Umgebung konfigurieren. Sie können sich die Arbeit vereinfachen, indem Sie das folgende Kommando absetzen: &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages/Latest/cvsupit.tgz -CURRENT Herunterladen mit ftp Benutzen Sie ftp. Der Quellbaum für &os.current; ist unter ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/ erhältlich. Einige FTP-Spiegel unterstützen das Herunterladen von komprimierten mit tar gepackten Dateibäumen. Wenn Sie beispielsweise das Verzeichnis usr.bin/lex als tar-Datei herunterladen wollen, geben Sie Folgendes ein: ftp> cd usr.bin ftp> get lex.tar -CURRENT Synchronisation mit CTM CTM kommt in Frage, wenn Sie über eine schlechte Internet-Anbindung (hoher Preis oder nur E-Mail Zugriff) verfügen. Der Umgang mit CTM ist allerdings recht mühsam und Sie können beschädigte Dateien erhalten. Daher wird es selten benutzt, was wiederum dazu führt, dass es über längere Zeit nicht funktioniert. Wir empfehlen jedem mit einem 9600 bps oder schnellerem Modem, CVSup zu benutzen. Wenn Sie die Quellen einsetzen und nicht nur darin lesen wollen, besorgen Sie sich bitte 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. + + -CURRENT + übersetzen + Bevor Sie &os.current; übersetzen, sollten Sie sich das Makefile in /usr/src genau anschauen. Wenn Sie Ihr System das erste Mal aktualisieren, sollten Sie mindestens make world laufen lassen. Lesen Sie bitte die Mailingliste &a.current;, um über Änderungen im Installationsverfahren, die manchmal vor der Einführung eines neuen Releases notwendig sind, informiert zu sein. Seien Sie aktiv! Wenn Sie &os.current; laufen lassen, wollen wir wissen, was Sie darüber denken, besonders wenn Sie Verbesserungsvorschläge oder Fehlerbehebungen haben. 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;? Wenn Sie den FreeBSD Entwicklungsprozess, besonders im Hinblick auf das nächste Release, verfolgen oder dazu beitragen wollen, sollten Sie erwägen, &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 der FreeBSD Sicherheitshinweise beschreibt für jedes betroffene Release, Das stimmt nicht ganz. Obwohl wir alte FreeBSD Releases für einige Jahre unterstützen, können wir sie nicht ewig unterstützen. Eine vollständige Beschreibung der Sicherheitspolitik für alte FreeBSD Releases entnehmen Sie bitte http://www.FreeBSD.org/security/ wie sie einen sicherheitsrelevanten Fehler beheben. Wenn Sie den Entwicklungszweig aus Sicherheitsgründen verfolgen wollen, bedenken Sie, dass Sie neben Fehlerbehebungen auch eine Vielzahl unerwünschter Änderungen erhalten werden. Obwohl wir versuchen sicherzustellen, dass der &os.stable; Zweig sich jederzeit übersetzen lässt und läuft, können wir dafür keine Garantie übernehmen. Auch wenn Neuentwicklungen in &os.current; stattfinden, ist es jedoch so, dass mehr Leute &os.stable; benutzen als &os.current; 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 wichtig, dass Sie &os.stable; zuerst sorgfältig in einer Testumgebung austesten, bevor Sie Ihre Produktion auf &os.stable; migrieren. Wenn Sie dies nicht leisten können, empfehlen wir Ihnen, das aktuelle FreeBSD Release zu verwenden. Benutzen Sie dann den binären Update-Mechanismus, um auf neue Releases zu migrieren. Benutzen von &os.stable; -STABLE benutzen Lesen Sie Mailingliste &a.stable;, 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. In der &a.cvsall; Mailingliste sehen Sie zu jeder Änderung das Commit-Log, das Informationen zu möglichen Seiteneffekten enthält. Um diese Listen zu lesen, senden Sie eine E-Mail mit dem folgenden Inhalt im Textkörper der Nachricht an &a.majordomo;: subscribe freebsd-stable subscribe cvs-all Majordomo Sie können Majordomo auch den Text help schicken und erhalten dann eine ausführliche Hilfe, die beschreibt, wie Sie die verschiedenen Mailinglisten abonnieren bzw. wieder abbestellen. Wenn Sie ein neues System installieren und so aktuell wie möglich sein wollen, holen Sie sich einfach den neusten Snapshot von ftp://releng4.FreeBSD.org/pub/FreeBSD/ und installieren ihn wie ein normales Release. Wenn Sie schon ein älteres Release von &os; benutzen und mit dem Quellcode migrieren wollen, stehen Ihnen dazu ausgehend von ftp.FreeBSD.org drei Möglichkeiten zur Verfügung: + + cvsup + + + cron + -STABLE Synchronisation mit CVSup Benutzen Sie cvsup mit einer geeigneten Sup-Datei. Dies ist die empfohlene Methode, da Sie die ganzen Quellen nur einmal herunterladen und danach nur noch Änderungen beziehen. Viele lassen cvsup aus cron heraus laufen, um ihre - Quellen automatisch auf Stand zu bringen. Wenn Sie dazu + Quellen automatisch auf Stand zu bringen. Sie + müssen das oben erwähnte + supfile anpassen und cvsup konfigurieren. Wenn Sie dazu eine einfache Schnittstelle benötigen, geben sie Folgendes ein:
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages/Latest/cvsupit.tgz
 -STABLE Herunterladen mit ftp Benutzen Sie ftp. Der Quellbaum für &os.stable; ist unter ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ erhältlich. Einige FTP-Spiegel unterstützen das Herunterladen von komprimierten mit tar gepackten Dateibäumen. Wenn Sie beispielsweise das Verzeichnis usr.bin/lex als tar-Datei herunterladen wollen, geben Sie Folgendes ein: ftp> cd usr.bin ftp> get lex.tar -STABLE Synchronisation mit CTM Benutzen Sie CTM. Wenn Sie über keine schnelle und billige Internet-Anbindung verfügen, sollten Sie diese Methode in Betracht ziehen. Benutzen Sie cvsup oder ftp, wenn Sie schnellen Zugriff auf die Quellen brauchen und die Bandbreite keine Rolle spielt, andernfalls benutzen Sie CTM. -STABLE übersetzen Bevor Sie &os.stable; übersetzen, sollten Sie sich das Makefile in /usr/src genau anschauen. Wenn Sie Ihr System das erste Mal aktualisieren, sollten Sie mindestens make world laufen lassen. Lesen Sie bitte die Mailingliste &a.stable;, 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. Dazu bieten wir die Dienste AnonymousCVS, CVSup und CTM an. Obwohl es möglich ist, nur Teile des Quellbaums zu aktualisieren, ist die einzige unterstütze Migrationsprozedur, den kompletten Quellbaum zu aktualisieren und alles, das heißt das Userland (z.B. alle Programme in /bin und /sbin) und die Kernelquellen, neu zu übersetzen. Wenn Sie nur einen Teil der Quellen, zum Beispiel nur den Kernel oder nur die Programme aus dem Userland, aktualisieren, werden Sie oft Probleme haben, die von Übersetzungsfehlern über Kernel-Panics bis hin zu Beschädigungen Ihrer Daten reichen können. anonymous CVS Anonymous CVS und CVSup benutzen die Pull-Methode Von engl. to pull = ziehen. Der Client holt sich bei dieser Methode die Dateien ab. , um die Quellen zu aktualisieren. Im Fall von CVSup ruft der Benutzer oder ein cron-Skript cvsup auf, das wiederum mit einem cvsupd Server interagiert, um Ihre Quellen zu aktualisieren. Mit beiden Methoden erhalten Sie aktuelle Updates zu einem genau von Ihnen bestimmten Zeitpunkt. Sie können die Prozedur auf bestimmte Dateien oder Verzeichnisse einschränken, so dass Sie nur die Updates bekommen, die für Sie von Interesse sind. Die Updates werden zur Laufzeit, abhängig von den Sachen, die Sie schon haben und den Sachen, die Sie haben wollen, auf dem Server generiert. Anonymous CVS ist eine Erweiterung von CVS, die es Ihnen erlaubt, Änderungen direkt aus einem entfernten CVS-Repository zu ziehen. Anonymous CVS ist leichter zu handhaben als CVSup, doch ist letzteres sehr viel effizienter. CTM Im Gegensatz dazu vergleicht CTM Ihre 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 (es 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 Ihren Quellen vornimmt. Dieses Verfahren ist viel effizienter als CVSup und erzeugt auch weniger Last auf unseren Servern, da es die Push-Methode Von engl. to push = schieben. Der Server schickt dem Client die Dateien. verwendet. Es gibt natürlich noch weitere Unterschiede, die Sie beachten sollten. Wenn Sie unabsichtlich Teile Ihres Archivs löschen, wird das von CVSup wie Anonymous CVS erkannt und repariert. Wenn sich fehlerhafte Dateien in Ihrem Quellbaum befinden, löschen Sie diese einfach und synchronisieren erneut. CTM leistet das nicht, wenn Sie Teile des Quellbaums gelöscht haben und keine Sicherung besitzen, müssen Sie von neuem, das heißt vom letzten Basis-Delta, starten und die Änderungen wieder mit CTM nachziehen. Bau mit <command>make world</command> make world Wenn Sie Ihren lokalen Quellbaum mit einer bestimmten FreeBSD Version (&os.stable;, &os.current;, usw.) synchronisiert haben, können Sie diesen benutzen, um das System neu zu bauen. Erstellen Sie eine Sicherung! Es kann nicht oft genug betont werden, wie wichtig es ist, Ihr System zu sichern, bevor Sie die nachfolgenden Schritte ausführen. Obwohl der Neubau des Systems eine einfache Aufgabe ist, solange Sie sich an die folgende Anleitung halten, ist es unvermeidlich, dass Sie Fehler machen, oder Ihr System nicht mehr bootet, weil andere Fehler in den Quellbaum eingeführt haben. Stellen Sie sicher, dass Sie eine Sicherung erstellt haben und über eine Fixit-Floppy verfügen. Wahrscheinlich brauchen Sie sie nicht zu benutzen, 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 machen sie Fehler. Manchmal sind diese Fehler harmlos und lassen Ihr System eine Warnung ausgeben. Die Fehler können allerdings auch katastrophal sein und dazu führen, dass Sie Ihr System nicht mehr booten können, Dateisysteme beschädigt werden oder Schlimmeres passiert. Wenn solche 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. Wenn Sie &os.stable; oder &os.current; benutzen und nicht die Mailinglisten &a.stable; beziehungsweise &a.current; lesen, bringen Sie sich nur unnötig in Schwierigkeiten. Lesen Sie <filename>/usr/src/UPDATING</filename> Bevor Sie etwas anderes tun, lesen Sie bitte /usr/src/UPDATING (oder die entsprechende Datei, wenn Sie den Quellcode woanders installiert haben). Die Datei enthält wichtige Informationen zu Problemen, auf die Sie stoßen könnten oder gibt die Reihenfolge vor, in der Sie bestimmte Kommandos laufen lassen 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 Überprüfen Sie die Dateien /etc/defaults/make.conf und /etc/make.conf. Die erste enthält Vorgabewerte, von denen die meisten auskommentiert sind. Um diese während des Neubaus des Systems zu nutzen, tragen Sie die Werte in /etc/make.conf ein. Beachten Sie, dass alles, was Sie in /etc/make.conf eintragen, bei jedem Aufruf von make angezogen wird. Es ist also klug, hier etwas Sinnvolles einzutragen. Typischerweise wollen Sie die Zeilen, die CFLAGS und NOPROFILE enthalten, aus /etc/defaults/make.conf nach /etc/make.conf übertragen und dort aktivieren. Sehen Sie sich auch die anderen Definitionen, wie COPTFLAGS oder NOPORTDOCS an und entscheiden Sie, ob Sie diese aktivieren wollen. Aktualisieren Sie die Dateien in <filename>/etc</filename> Das Verzeichnis /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 FreeBSD Version. Einige der Konfigurationsdateien, besonders /etc/group, werden für den Normalbetrieb des Systems gebraucht. Es gab Fälle, in denen der Installationsteil von make world auf das Vorhandensein von bestimmten Accounts oder Gruppen angewiesen war, die aber zurzeit des Updates noch nicht vorhanden waren. Demzufolge kam es zu Problemen bei der Migration. Ein Beispiel dafür ist der vor kurzem hinzugefügte Benutzer smmsp. Die Installationsprozedur schlug an der Stelle fehl, an der mtree versuchte, /var/spool/clientmqueue anzulegen. Um dieses Problem zu umgehen, vergleichen Sie die Gruppen in /usr/src/etc/group mit den auf Ihrem System vorhandenen Gruppen. Wenn sich in dieser Datei neue Gruppen befinden, kopieren Sie diese nach /etc/group. Gruppen, die in /etc/group dieselbe GID wie in /usr/src/etc/group aber einen unterschiedlichen Namen haben, sollten Sie umbenennen. Seit 4.6-RELEASE besitzt &man.mergemaster.8; einen prä-buildworld Modus, der mit aktiviert wird. In diesem Modus werden nur Dateien verglichen, die für den Erfolg von buildworld oder installworld essentiell sind. Wenn Ihre alte Version von mergemaster die Option noch nicht unterstützt, nehmen Sie beim ersten Lauf die neue Version aus dem Quellbaum: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Wenn Sie besonders paranoid sind, sollten Sie Ihr System nach Dateien absuchen, die der Gruppe, die Sie umbenennen oder löschen, gehören: &prompt.root; find / -group GID -print Das obige Kommando zeigt alle Dateien an, die der Gruppe GID (dies kann entweder ein Gruppenname oder eine numerische ID sein) gehören. Wechseln Sie in den Single-User Modus Single-User Modus Sie können das System im Single-User Modus übersetzen. Abgesehen davon, dass dies etwas schneller ist, werden bei der Installation des Systems 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 Eine andere Methode übersetzt das System im Mehrbenutzermodus und wechselt für die Installation den Single-User Modus. Wenn Sie diese Methode benutzen wollen, warten Sie mit den folgenden Schritten, bis der Bau des Systems fertig ist und Sie mit installkernel oder installworld installieren wollen. Als Superuser können Sie mit dem folgenden Kommando ein laufendes System in den Single-User Modus bringen: &prompt.root; Alternativ können Sie das System mit der Option in den Single-User Modus booten. Setzen Sie dann die folgenden Kommandos ab: &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 Ihre CMOS-Uhr die lokale Zeit und nicht GMT an, dies erkennen Sie daran, dass date die falsche Zeit und eine flasche Zeitzone anzeigt, setzen Sie das folgende Kommando ab: &prompt.root; adjkerntz -i Dies stellt sicher, dass Ihre Zeitzone richtig eingestellt ist. Ohne dieses Kommando werden Sie vielleicht später Probleme bekommen. Entfernen Sie <filename>/usr/obj</filename> Die neugebauten Teile des Systems werden in der Voreinstellung unter /usr/obj gespeichert. Die Verzeichnisse dort spiegeln die Struktur unter /usr/src. Sie können den make world Prozess beschleunigen, indem Sie dieses Verzeichnis entfernen. Dies erspart Ihnen zudem einigen Ärger aufgrund von Abhängigkeiten. Einige Dateien unter /usr/obj sind vielleicht durch die -Option (siehe &man.chflags.1;) schreibgeschützt, die vor dem Löschen entfernt werden muss. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Übersetzen der Quellen Sichern der Ausgaben Für den Fall, dass etwas schief geht, sollten Sie die Ausgaben von &man.make.1; in einer Datei sichern, damit Sie eine Kopie der Fehlermeldung besitzen. Das mag Ihnen nicht helfen, den Fehler zu finden, kann aber anderen helfen, wenn Sie Ihr Problem in einer der &os;-Mailinglisten schildern. 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 Boot aufgeräumt werden kann. Ein geeigneteres Verzeichnis ist /var/tmp, wie im vorigen Beispiel gezeigt, oder das Heimatverzeichnis von root. Übersetzen und Installation 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 Zum Neubau der Welt benutzen Sie &man.make.1;. Dieses Kommando liest ein Makefile, das Anweisungen enthält, 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 -VARIABLE target In diesem Beispiel ist eine Option, die Sie an &man.make.1; weitergeben wollen. Eine Liste gültiger Optionen finden Sie in der &man.make.1; Manualpage. 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 -DNOPROFILE target Dieser Aufruf entspricht dem folgenden Eintrag in /etc/make.conf: NOPROFILE= 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 sind nicht für den Endanwender gedacht, sondern unterteilen den Bauprozess in eine Reihe von Einzelschritten. Im Regelfall müssen Sie &man.make.1; keine Parameter mitgeben, so dass Ihre Kommandozeile wie folgt aussehen wird: &prompt.root; make target In der &os; Version 2.2.5 wurde das Ziel world in zwei Ziele aufgespalten: buildworld und installworld. Tatsächlich ist das zuerst in &os.current; passiert und wurde dann irgendwann zwischen den Versionen 2.2.2 und 2.2.5 in &os.stable; eingebaut. Mit buildworld wird ein kompletter Baum unterhalb von /usr/obj gebaut, der mit installworld auf dem System installiert werden kann. Dies ist aus zwei Gründen nützlich. Erstens können Sie das System auf einem laufenden System bauen, da die Bauprozedur abgekapselt vom Rest des Systems 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 können Sie NFS benutzen, um mehrere Maschinen in Ihrem Netzwerk zu aktualisieren. Wenn Sie die Maschinen A, B und C aktualisieren wollen, 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, sollten Sie es wirklich nicht mehr benutzen. Um das System zu bauen, setzen Sie das folgende Kommando ab: &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 IO 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 absetzen: &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 in Ihrem Kernel konfiguriert ist, probieren Sie Werte zwischen 6 und 10 aus. Beachten Sie bitte, dass dies noch nicht richtig unterstützt wird und dass es bei einigen Änderungen am Quellbaum zu Fehlern kommen kann. Wenn Sie diesen Parameter benutzt haben und der Bau nicht funktioniert, bauen Sie bitte noch einmal ohne den Parameter, bevor Sie ein Problem melden. Laufzeiten make world Laufzeiten Die Laufzeit eines Baus wird von vielen Faktoren beeinflusst. Ein 500 MHz Pentium III braucht ungefähr zwei Stunden um &os.stable; zu bauen. Der Bau von &os.current; dauert etwas länger. Übersetzen und Installation des Kernels Kernel Übersetzen Um das Beste aus Ihrem System zu holen, sollten Sie einen neuen Kernel kompilieren. Praktisch gesehen ist das sogar notwendig, da sich einige Datenstrukturen geändert haben und Programme wie &man.ps.1; oder &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 Ihre 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 Sie mit GENERIC gebootet und sichergestellt haben, dass Ihr System funktioniert, können Sie einen neuen Kernel mit Ihrer Konfigurationsdatei bauen. Wenn Sie einen Update nach &os; 4.0 oder höher durchführen, sollten Sie den Kernel nicht mit der alten Methode, die in beschrieben ist, bauen. Stattdessen benutzen Sie die nachstehenden Kommandos (die neue Methode) nach dem Bau des Basissystems mit buildworld. Wenn Sie einen angepassten Kernel erstellen wollen und bereits über eine Konfigurationsdatei verfügen, hängen Sie einfach KERNCONF='MYKERNEL' an die gezeigten Kommandozeilen an. &prompt.root; cd /usr/src &prompt.root; make buildkernel &prompt.root; make installkernel 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 Einbenutzermodus ausführen. Wenn das nicht der Fall ist, sollten die beiden Kommandos problemlos im Mehrbenutzermodus laufen. Weitere Informationen über kern.securelevel finden Sie in &man.init.8; und &man.chflags.1; erläutert Optionen, die Sie auf Dateien setzen können. Wenn Sie ein Update auf eine &os; Version vor 4.0 durchführen, sollten Sie die alte Methode benutzen. Es ist allerdings empfohlen, dazu die frisch gebaute Version von &man.config.8; zu benutzen: &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME Booten Sie in den Single-User Modus Single-User Modus Um zu prüfen, ob der neue Kernel funktioniert, sollten Sie in den Single-User Modus booten. Folgen Sie dazu der Anleitung aus . Installation des Systems Wenn Sie make buildworld benutzt haben, um das System zu bauen, sollten Sie jetzt installworld benutzen, um es zu installieren. Rufen Sie dazu das folgende Kommando auf: &prompt.root; cd /usr/src &prompt.root; make installworld Wenn Sie mit dem make buildworld Kommando Variablen verwenden haben, müssen Sie dieselben Variablen auch bei dem make installworld Kommando angeben. Auf die anderen Optionen trifft das nur bedingt zu: darf mit installworld nicht benutzt werden. Sie haben zum Bauen die folgende Kommandozeile verwendet: &prompt.root; make -DNOPROFILE buildworld Bei der Installation setzen Sie dann das folgende Kommando ab: &prompt.root; make -DNOPROFILE installworld Würden Sie die Variable bei der Installation weglassen, so würde das System 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. Sie können diese Dateien mit &man.mergemaster.8; aktualisieren. Alternativ können Sie das auch manuell durchführen, obwohl wir diesen Weg nicht empfehlen. Egal welchen Weg Sie beschreiten, sichern Sie vorher den Inhalt von /etc für den Fall, dass etwas schief geht. <command>mergemaster</command> mergemaster Das Bourne-Shell Skript &man.mergemaster.8; hilft Ihnen dabei, die Unterschiede zwischen den Konfigurationsdateien in /etc und denen im Quellbaum unter /usr/src/etc zu finden. mergemaster ist der empfohlene Weg, Ihre Systemkonfiguration mit dem Quellbaum abzugleichen. Zwischen 3.3-RELEASE und 3.4-RELEASE wurde mergemaster in das Basissystem integriert, so dass es in allen -STABLE und -CURRENT Systemen seit der Version 3.3 vorhanden ist. Rufen Sie mergemaster einfach auf und schauen Sie zu. Ausgehend von / wird mergemaster einen virtuellen Root-Baum aufbauen und darin die neuen Konfigurationsdateien ablegen. Diese Dateien werden dann mit den auf Ihrem System installierten 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 einem 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. Sie können die aktuelle Datei auch überspringen, sie wird dann noch einmal angezeigt, nachdem alle anderen Dateien abgearbeitet wurden. Sie erhalten Hilfe, wenn Sie bei der Eingabeaufforderung von mergemaster ein eingeben. Wenn Sie die temporäre Datei löschen, geht mergemaster davon aus, dass Sie Ihre aktuelle Datei behalten möchten. Wählen Sie die Option bitte 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, indem 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 Ihnen &man.mergemaster.8; dieselbe Ausgabe, die Sie gesehen haben, bevor die Eingabeaufforderung ausgegeben wurde. Wenn &man.mergemaster.8; alle Systemdateien abgearbeitet hat, werden weitere Optionen abgefragt. Sie werden unter Umständen gefragt, ob Sie die Passwort-Datei neu bauen oder MAKEDEV laufen lassen wollen. Am Ende haben Sie die Möglichkeit, den Rest der 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, lesen Sie bitte im nächsten Abschnitt weiter. 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> Obwohl bei dieser Prozedur keine Dateien in /etc automatisch verändert werden, sollten Sie dessen Inhalt an einen sicheren Ort 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. Sie müssen die neuen Dateien in einem temporären Verzeichnis installieren. /var/tmp/root ist eine gute Wahl für das temporäre Verzeichnis, in dem auch noch einige Unterverzeichnisse angelegt werden müssen. &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 Im obigen Beispiel wurde die Fehlerausgabe nach /dev/null umgeleitet, um die Warnungen über nicht leere Verzeichnisse zu unterdrücken. /var/tmp/root enthält nun alle Dateien, die unterhalb von / installiert werden müssen. Sie müssen nun jede dieser Dateien mit den schon existierenden Dateien vergleichen. Einige der installierten Dateien unter /var/tmp/root beginnen mit einem /var/tmp/root/ und /var/tmp/root/root/. Abhängig davon, wann Sie dieses Handbuch lesen, können mehr Dateien dieser Art existieren. Verwenden Sie Benutzen Sie &man.diff.1; um Unterschiede zwischen zwei Dateien festzustellen. &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Das obige Kommando zeigt Ihnen die Unterschiede zwischen der installierten Version von /etc/shells und der neuen Version. Entscheiden Sie anhand der Unterschiede, ob Sie beide Dateien abgleichen oder die neue Version über die alte kopieren wollen. Versehen Sie das temporäre Verzeichnis mit einem Zeitstempel Wenn Sie das System oft neu bauen, müssen Sie /etc genauso oft aktualisieren. Dies kann mit der Zeit sehr lästig werden. Sie können das Verfahren beschleunigen, wenn Sie sich eine Kopie der Dateien behalten, die Sie zuletzt nach /etc installiert haben. Das folgende Verfahren zeigt Ihnen, wie das geht. 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. Wenn Sie dies zum Beispiel am 14.  Februar 1998 durchführten, hätten Sie die folgenden Kommandos abgesetzt: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Gleichen Sie die Änderungen entsprechend der Anleitung von oben ab. Wenn Sie fertig sind, entfernen Sie das Verzeichnis /var/tmp/root-19980214 nicht. Wenn Sie nun neue Quellen heruntergeladen und gebaut haben, folgen Sie bitte Schritt 1. Wenn Sie zwischen den Updates eine Woche gewartet haben, haben Sie nun ein Verzeichnis mit dem Namen /var/tmp/root-19980221. Sie können nun die Unterschiede, die sich in einer Woche ergeben haben, sehen, indem Sie &man.diff.1; rekursiv anwenden: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Üblicherweise sind die Differenzen, die Sie jetzt sehen, kleiner als die Differenzen zwischen /var/tmp/root-19980221/etc und /etc. Da die angezeigten Differenzen kleiner sind, ist es jetzt einfacher den Abgleich der Dateien durchzuführen. Sie können nun das älteste der beiden /var/tmp/root-* Verzeichnisse entfernen: &prompt.root; rm -rf /var/tmp/root-19980214 Wiederholen Sie diesen Prozess jedes Mal wenn Sie Dateien in /etc abgleichen müssen. Mit &man.date.1; können Sie den Verzeichnisnamen automatisch erzeugen: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Aktualisieren Sie <filename>/dev</filename> DEVFS DEVFS Wenn Sie DEVFS benutzen, brauchen Sie diesen Schritt nicht auszuführen. In den meisten Fällen bemerkt &man.mergemaster.8; wann es notwendig ist, Gerätedateien in /dev zu erstellen. Die folgenden Anweisungen zeigen Ihnen, wie Sie dies manuell durchführen. Um sicher zu gehen, besteht dieser Prozess aus mehreren Schritten. Kopieren Sie /var/tmp/root/dev/MAKEDEV nach /dev. &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev MAKEDEV Wenn Sie &man.mergemaster.8; benutzt haben, sollte MAKEDEV schon aktualisiert sein, obwohl es nicht schadet, das mit diff zu überprüfen und die Datei, wenn nötig, manuell zu kopieren. Sichern Sie jetzt die Dateiinformationen aus /dev. Sie brauchen die Rechte, Eigentümer, sowie die Major und Minor Nummern der Gerätedateien (die Zeitstempel sind nicht wichtig). Am besten erledigen Sie das mit &man.awk.1;: &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out Erstellen Sie alle Gerätedateien neu: &prompt.root; Sammeln Sie erneut die Dateiinformationen aus /dev, diesmal in der Datei /var/tmp/dev2.out ein. Vergleichen Sie beide Dateien und suchen Sie nach Geräten, die nicht erstellt wurden. Sie sollten keine finden, aber es ist besser das jetzt wirklich zu kontrollieren: &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out Wenn es doch fehlende Einträge gibt, sind dies wahrscheinlich fehlende Geräte für Slices. Diese können Sie mit einem Befehl wie dem folgenden wiederherstellen: &prompt.root; sh MAKEDEV sd0s1 Die genauen Geräte können bei Ihnen natürlich andere sein. Aktualisieren Sie <filename>/stand</filename> Dieser Schritt wurde nur der Vollständigkeit wegen aufgenommen. Sie können ihn komplett auslassen. Der Vollständigkeit halber wollen Sie vielleicht auch die Dateien in /stand aktualisieren. Alle Dateien in diesem Verzeichnis sind Hardlinks zu /stand/sysinstall. Dieses Programm ist statisch gelinkt, so dass es unabhängig von den Dateien in anderen Dateisystemen, insbesondere /usr, ist. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install Booten Sie sind nun am Ende der Prozedur angelangt. Nachdem Sie sich davon überzeugt haben, dass Ihr System funktioniert, booten Sie das System mit &man.fastboot.8;: &prompt.root; fastboot Ende Herzlichen Glückwunsch! Sie haben gerade erfolgreich Ihr &os; System aktualisiert. Es ist übrigens leicht einen Teil des Systems wiederherzustellen, für den Fall, dass Ihnen ein kleiner Fehler unterlaufen ist. Wenn Sie beispielsweise während des Updates oder Abgleichs /etc/magic aus Versehen gelöscht haben, wird &man.file.1; nicht mehr funktionieren. In diesem Fall können Sie das Problem mit dem folgenden Kommando beheben: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; 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 CVSup-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 (sowie Ihre statisch gelinkten Ergänzungen) 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 natürlich 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 Ihre Hardware und zeigt oft Probleme mit dem Speicher auf. Dies äußert sich darin, dass der Kompiler mit dem Erhalt von seltsamen Signalen abbricht. Es liegt garantiert ein Hardwarefehler vor, wenn ein neuer Übersetzungslauf an einer anderen Stelle abbricht. In diesem Fall können Sie nur einzelne Komponenten Ihres Systems tauschen, um zu bestimmen, welche Komponente den Fehler verursacht. Kann ich /usr/obj löschen, 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 der Bauprozedur entfernt. Es macht daher wenig Sinn, dieses Verzeichnis zu behalten und Sie setzen eine Menge Plattenplatz, momentan ungefähr 340 MB, frei, wenn Sie es löschen. Wenn Sie allerdings genau wissen, was Sie tun, können Sie diesen Schritt bei make world auslassen. Nachfolgende Bauprozeduren werden dadurch erheblich schneller, da die meisten Quelldateien nicht mehr neu übersetzt werden. 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 essentielle Werkzeuge, wie &man.gcc.1; und &man.make.1;, und die Systembibliotheken während des Bauprozesses neu erstellt (dies ist aber keine allgemein gültige Regel). Die neu erstellen Werkzeuge und Bibliotheken werden dann benutzt, um sich selbst noch einmal zu bauen, und wieder installiert. Anschließend wird das Gesamtsystem mit den neu erstellten Systemdateien gebaut. Wenn Sie sich im letzten Schritt befinden und Sie wissen, dass Sie dort sind, weil Sie durch die Ausgaben, die Sie ja sichern, der Bauprozedur gesehen haben, können Sie mit ziemlicher Sicherheit den Bau weiterführen: … Fehler beheben … &prompt.root; cd /usr/src &prompt.root; make -DNOCLEAN all Die Variable NOCLEAN verhindert, dass make world die vorher erstellten Dateien löscht. Das Sie sich im letzten Schritt der Bauprozedur befinden, erkennen Sie daran, dass Sie in der Ausgabe die folgenden Zeilen finden: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- Wenn Sie diese Meldung nicht finden, oder sich nicht sicher sind, dann ist es besser, noch einmal ganz von Vorne anzufangen. Wie kann ich den Bauprozesss 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. Noch besser ist es, diese Dateisysteme auf mehrere Festplatten mit &man.ccd.4; zu verteilen. Bauen Sie die profiled-Bibliotheken, die Sie wahrscheinlich sowieso nicht brauchen, nicht. /etc/make.conf sollte dazu NOPROFILE=true enthalten. Setzen Sie die CFLAGS in /etc/make.conf auf . Die Optimierungsstufe ist deutlich langsamer und die Performance-Unterschiede zwischen und sind vernachlässigbar klein. veranlasst den Kompiler Pipes anstelle von Dateien für die Kommunikation zu benutzen. Dies spart einige Plattenzugriffe, geht aber auf Kosten des Speichers. Benutzen Sie , um mehrere Prozesse parallel laufen zu lassen. Normalerweise beschleunigt dies den Bauprozess unabhängig davon, ob Sie ein Einprozessor oder Mehrprozessor System einsetzen. Sie können das Dateisystem /usr/src mit der Option einhängen. Dies verhindert, dass die Zugriffszeiten der Dateien aktualisiert werden (eine Information, die Sie vielleicht gar nicht brauchen). &prompt.root; mount -u -o noatime /usr/src Das Beispiel geht davon aus, dass sich /usr/src auf einem separaten Dateisystem befindet. Wenn das nicht der Fall ist, weil das Verzeichnis beispielsweise Teil des /usr Dateisystems ist, müssen Sie anstelle von /usr/src den Mountpoint des Dateisystems angeben. Das Dateisystem, in dem sich /usr/obj befindet, kann mit der Option eingehangen werden. Dies bewirkt, 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 Ihr 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 sich /usr/obj auf einem extra Dateisystem befindet, ist das kein Problem. Wenn sich allerdings auf diesem Dateisystem noch andere wertvolle Daten befinden, stellen Sie sicher, dass Sie aktuelle Sicherungen besitzen. &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. Das geht ganz einfach: &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. Nachdem Sie aufgeräumt haben, 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. Mike Meyer Beigetragen von Installation mehrerer Maschinen Wenn Sie mehrere Maschinen besitzen, die Sie 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 world 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 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 Nach diesen Vorbereitungen können Sie mit dem Bau beginnen. 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 ausgehend 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. diff --git a/de_DE.ISO8859-1/books/handbook/eresources/chapter.sgml b/de_DE.ISO8859-1/books/handbook/eresources/chapter.sgml index 1094c3e0b7..1a2ac987f4 100644 --- a/de_DE.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,2117 +1,2140 @@ Ressourcen im Internet Gedruckte Medien können mit der schnellen Entwicklung von FreeBSD nicht Schritt halten. Elektronische Medien sind häufig die einzige Möglichkeit, über aktuelle Entwicklungen informiert zu sein. Da FreeBSD ein Projekt von Freiwilligen ist, gibt die Benutzergemeinde selbst auch technische Unterstützung. Die Benutzergemeinde erreichen Sie am besten über E-Mail oder Usenet-News. Die wichtigsten Wege, auf denen Sie die FreeBSD Benutzergemeinde erreichen können, sind unten dargestellt. Wenn Sie weitere Ressourcen kennen, die hier fehlen, schicken Sie diese bitte an die Mailingliste &a.doc;, so dass sie hier aufgenommen werden können. Mailinglisten Obwohl viele FreeBSD Entwickler Usenet-News lesen, können wir nicht garantieren, dass Sie eine zügige Antwort auf Ihre Fragen bekommen, wenn Sie diese nur in einer der comp.unix.bsd.freebsd.* Gruppen stellen. Wenn Sie Ihre Fragen auf der passenden Mailingliste stellen, erreichen Sie sowohl die Entwickler wie auch die FreeBSD Benutzergemeinde und erhalten damit bessere (oder zumindest schnellere) Antworten. Die Chartas der verschiedenen Listen sind unten wiedergegeben. Bevor Sie sich einer Mailingliste anschließen oder E-Mails an eine Liste senden, lesen Sie bitte die Charta der Liste. Die meisten Mitglieder unserer Mailinglisten erhalten Hunderte E-Mails zum Thema FreeBSD pro Tag. Die Chartas und Regeln, die den Gebrauch der Listen beschreiben, garantieren die hohe Qualität der Listen. Die Listen würden ihren hohen Wert für das Projekt verlieren, wenn wir weniger Regeln aufstellen würden. Alle Mailinglisten werden archiviert und können auf dem FreeBSD World Wide Web Server durchsucht werden. Das nach Schlüsselwörtern durchsuchbare Archiv bietet die hervorragende Möglichkeit, Antworten auf häufig gestellte Fragen zu finden. Nutzen Sie bitte diese Möglichkeit bevor Sie Fragen auf einer Liste stellen. Beschreibung der Mailinglisten Allgemeine Listen: Jeder kann die folgenden allgemeinen Listen abonnieren (und ist dazu aufgefordert): Mailingliste Zweck cvs-all Änderungen im FreeBSD-Quellbaum freebsd-advocacy Verbreitung von FreeBSD freebsd-announce Wichtige Ereignisse und Meilensteine des Projekts freebsd-arch Architektur und Design von FreeBSD freebsd-bugbusters Diskussionen über die Pflege der FreeBSD Fehlerberichte-Datenbank und die dazu benutzten Werkzeuge freebsd-bugs Fehlerberichte freebsd-chat Nicht technische Themen, die die FreeBSD Gemeinschaft betreffen freebsd-config Entwicklung von Konfigurations- und Installations-Werkzeugen für FreeBSD freebsd-current Gebrauch von &os.current; freebsd-isp Themen, die Internet Service Provider betreffen, die FreeBSD benutzen freebsd-jobs Anstellung und Beratung im FreeBSD Umfeld freebsd-newbies Starthilfen für neue FreeBSD Benutzer freebsd-policy Grundsatzentscheidungen des FreeBSD Core Teams. Wenig Verkehr und nur zum Lesen freebsd-questions Benutzerfragen und technische Unterstützung freebsd-security-notifications Ankündigungen zum Thema Sicherheit freebsd-stable Gebrauch von &os.stable; freebsd-test Schicken Sie Testnachrichten an diese Liste anstelle der wirklichen Listen Technische Listen: Auf den folgenden Listen werden technische Diskussionen geführt. Bevor Sie eine der Listen abonnieren oder Nachrichten an sie schicken, lesen Sie sich bitte die Charta der Liste durch, da der Inhalt und Zweck dieser Listen genau festgelegt ist. Mailingliste Zweck freebsd-afs Portierung von AFS nach FreeBSD freebsd-aic7xxx Entwicklung von Adaptec AIC 7xxx Treibern freebsd-alpha Portierung von FreeBSD auf Alpha Maschinen freebsd-arm Portierung von FreeBSD auf ARM Prozessoren freebsd-atm Benutzung von ATM Netzen mit FreeBSD freebsd-audit Audit der FreeBSD Quellen freebsd-binup Design und Entwicklung eines Systems, das es erlaubt, ein FreeBSD System mit binären Paketen zu aktualisieren freebsd-cluster Benutzung von FreeBSD in einem Cluster freebsd-cvsweb Pflege von CVSWeb freebsd-database Diskussion über Datenbanken und Datenbankprogrammierung unter FreeBSD freebsd-doc Erstellen der FreeBSD Dokumentation freebsd-emulation Emulation anderer Systeme wie Linux, DOS oder Windows freebsd-firewire Technische Diskussion über FreeBSD Firewire (iLink, IEEE 1394) freebsd-fs Dateisysteme freebsd-gnome Portierung von GNOME und GNOME-Anwendungen freebsd-hackers Allgemeine technische Diskussionen freebsd-hardware Allgemeine Diskussion über Hardware, auf der FreeBSD läuft freebsd-i18n Internationalisierung von FreeBSD + + freebsd-ia32 + FreeBSD für die IA-32 (Intel x86) Platform + + freebsd-ia64 Portierung von FreeBSD auf Intels neue IA64 Systeme freebsd-ipfw Technische Diskussion über die Neubearbeitung der IP-Firewall Quellen freebsd-isdn Für Entwickler des ISDN Systems freebsd-java Für Java-Entwickler und Leute, die JDKs nach FreeBSD portieren freebsd-lfs Portierung von LFS nach FreeBSD freebsd-libh Das nächste Installations- und Paketsystem + + freebsd-mips + Portierung von FreeBSD zu MIPS + + freebsd-mobile Diskussionen über mobiles Rechnen freebsd-mozilla Portierung von Mozilla nach FreeBSD freebsd-multimedia Multimedia Anwendungen freebsd-new-bus Technische Diskussionen über die Architektur von Bussen freebsd-net Diskussion über Netzwerke und den TCP/IP Quellcode freebsd-openoffice Portierung von OpenOffice.org und StarOffice nach FreeBSD freebsd-platforms Portierungen von FreeBSD auf nicht-Intel Architekturen freebsd-ports Diskussion über die Ports-Sammlung freebsd-ppc Portierung von FreeBSD auf den PowerPC freebsd-qa Diskussion über Qualitätssicherung, normalerweise kurz vor einem Release freebsd-realtime Entwicklung von Echtzeiterweiterungen für FreeBSD freebsd-scsi Diskussion über das SCSI Subsystem freebsd-security Sicherheitsthemen freebsd-small Gebrauch von FreeBSD in eingebetteten Systemen freebsd-smp Diskussionen über das Design von asymmetrischen und symmetrischen Mehrprozessor-Programmen freebsd-sparc Portierung von FreeBSD auf SPARC Systeme + + freebsd-testing + Leistungs- und Stabilitätstests von FreeBSD + + freebsd-standards Konformität von FreeBSD mit den C99- und POSIX-Standards freebsd-tokenring Token Ring Unterstützung in FreeBSD Eingeschränkte Listen: Die folgenden Listen wenden sich an Zielgruppen mit speziellen Anforderungen und sind nicht für die Öffentlichkeit gedacht. Bevor Sie eine dieser Listen abonnieren, sollten Sie einige der technischen Listen abonniert haben, um mit den Umgangsformen vertraut zu sein. Mailingliste Zweck freebsd-core FreeBSD Core Team freebsd-hubs Betrieb von FreeBSD Spiegeln freebsd-install Entwicklung von Installations-Werkzeugen freebsd-user-groups Koordination von Benutzergruppen freebsd-vendors Koordination von Händlern vor einem Release freebsd-www Betreuer von www.FreeBSD.org Zusammenfassungen: Viele der oben aufgeführten Listen sind auch als Zusammenfassungen erhältlich. Neue Nachrichten werden solange gesammelt, bis ihre Größe 100 KB überschreitet und dann als eine E-Mail verschickt. Von den folgenden Listen gibt es Zusammenfassungen: Mailingliste cvs-all-digest freebsd-afs-digest freebsd-alpha-digest + + freebsd-arm-digest + + freebsd-chat-digest freebsd-current-digest freebsd-database-digest freebsd-hackers-digest + + freebsd-ia32-digest + + freebsd-ia64-digest freebsd-isdn-digest freebsd-java-digest freebsd-questions-digest freebsd-security-digest freebsd-sparc-digest freebsd-stable-digest freebsd-test-digest CVS Listen: Die folgenden Listen versenden die Log-Einträge zu Änderungen an verschiedenen Teilen des Quellbaums. Diese Listen sollen nur gelesen werden, schicken Sie bitte keine Nachrichten an eine der Listen. Mailingliste Teil des Quellbaums Beschreibung cvs-all /usr/src Alle Änderungen am Quellbaum Mailinglisten abonnieren Um eine Liste zu abonnieren, schicken Sie eine E-Mail mit dem folgenden Textkörper an &a.majordomo;: subscribe Liste [optionale Adresse] Die Mailingliste freebsd-announce abonnieren Sie zum Beispiel wie folgt: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce ^D Um eine Nachricht an eine Mailingliste zu schicken, schreiben Sie einfach eine E-Mail an <Liste@FreeBSD.org>. Die E-Mail wird dann an alle Mitglieder der Mailingliste verteilt. Beachten Sie, dass die Listen über &a.majordomo; abonniert werden, benutzen Sie dazu nicht die Adresse der Liste. Wenn Sie die Liste unter einem anderen Namen empfangen wollen, oder die Liste für eine lokale Mailingliste abonnieren (dafür sind wir übrigens sehr dankbar, da es unsere Ressourcen schont), geben Sie die Adresse, an die die Nachrichten geschickt werden sollen, mit an: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce local-announce@example.com ^D Ferner können Sie &a.majordomo; noch weitere Kommandos schicken, mit denen Sie Ihr Abonnement aufheben, die Mitglieder einer Liste einsehen oder eine Aufzählung der verfügbaren Listen erhalten. Eine vollständige Liste der Kommandos erhalten Sie, wenn Sie die folgende Nachricht versenden: &prompt.user; mail majordomo@FreeBSD.org help ^D Verwenden Sie bitte die technischen Listen ausschließlich für technische Diskussionen. Wenn Sie nur an wichtigen Ankündigungen interessiert sind, abonnieren Sie die Mailingliste &a.announce;, auf der nur wenige Nachrichten versendet werden. Chartas der Mailinglisten Alle FreeBSD Mailinglisten besitzen Grundregeln, die von jedem beachtet werden müssen. Für die ersten beiden Male, in denen ein Absender gegen diese Regeln verstößt, erhält er jeweils eine Warnung vom FreeBSD Postmaster postmaster@FreeBSD.org. Ein dritter Verstoß gegen die Regeln führt dazu, dass der Absender in allen FreeBSD Mailinglisten gesperrt wird und weitere Nachrichten von ihm nicht mehr angenommen werden. Wir bedauern sehr, dass wir solche Maßnahmen ergreifen müssen, aber heutzutage ist das Internet eine recht rauhe Umgebung, in der immer weniger Leute Rücksicht aufeinander nehmen. Die Regeln: Das Thema einer Nachricht soll der Charta der Liste, an die sie gesendet wird, entsprechen. Wenn Sie eine Nachricht an eine technische Liste schicken, sollte die Nachricht auch technische Inhalte haben. Fortwährendes Geschwätz oder Streit mindern den Wert der Liste für alle Mitglieder und wird nicht toleriert. Benutzen Sie &a.chat; für allgemeine Diskussionen über FreeBSD. Eine Nachricht sollte an nicht mehr als zwei Mailinglisten gesendet werden. Schicken Sie eine Nachricht nur dann an zwei Listen, wenn das wirklich notwendig ist. Viele Leute haben mehrere Mailinglisten abonniert und Nachrichten sollten nur zu ungewöhnlichen Kombinationen der Listen, wie -stable und -scsi, gesendet werden. Wenn Sie eine Nachricht erhalten, die im Cc-Feld mehrere Listen enthält, sollten Sie das Feld kürzen, bevor Sie eine Antwort darauf verschicken. Unabhängig von dem ursprünglichen Verteiler sind Sie für Ihre eigenen Mehrfach-Sendungen selbst verantwortlich. Persönliche Angriffe und Beschimpfungen sind in einer Diskussion nicht erlaubt. Dies gilt gleichermaßen für Benutzer wie Entwickler. Grobe Verletzungen der Netiquette, wie das Verschicken oder Zitieren von privater E-Mail ohne eine entsprechende Genehmigung, werden nicht gebilligt. Die Nachrichten werden aber nicht besonders auf Verletzungen der Netiquette untersucht. Es kann sein, dass eine Verletzung der Netiquette durchaus zu der Charta einer Liste passt, aber der Absender aufgrund der Verletzung eine Warnung erhält oder gesperrt wird. Werbung für Produkte oder Dienstleistungen, die nichts mit FreeBSD zu tun haben, sind verboten. Ist die Werbung als Spam verschickt worden, wird der Absender sofort gesperrt. Chartas einzelner Listen: FREEBSD-AFS Andrew File System Auf dieser Liste wird die Portierung des AFS von CMU/Transarc diskutiert. FREEBSD-ANNOUNCE Wichtige Ereignisse und Meilensteine Diese Liste ist für Personen, die nur an den wenigen Ankündigungen wichtiger Ereignisse interessiert sind. Die Ankündigungen betreffen Schnappschüsse und Releases, neue Merkmale von FreeBSD und die Suche nach freiwilligen Mitarbeitern. Auf der Liste herrscht wenig Verkehr und sie wird streng moderiert. FREEBSD-ARCH Architektur und Design von FreeBSD Auf dieser technischen Liste wird die FreeBSD Architektur diskutiert. Beispiele für angemessene Themen sind: Wie das Bausystem zu verändern ist, damit verschiedene Läufe gleichzeitig möglich sind. Was am VFS geändert werden muss, damit Heidemann Schichten eingesetzt werden können. Wie die Schnittstelle der Gerätetreiber angepasst werden muss, damit derselbe Treiber auf verschiedenen Bussen und Architekturen eingesetzt werden kann. Wie ein Netzwerktreiber geschrieben wird. FREEBSD-AUDIT Source Code Audit Project Dies ist die Liste des FreeBSD Source Code Audit Projects. Ursprünglich war vorgesehen, hier nur sicherheitsrelevante Änderungen zu diskutieren, doch ist die Charta auf alle Änderungen ausgedehnt worden. Zu dieser Liste werden viele Korrekturen gesandt, so dass sie für den normalen FreeBSD Benutzer von wenig Wert ist. Diskussionen über Sicherheit, die sich nicht auf die Änderung von Quellcode beziehen, finden auf der Mailingliste &a.security; statt. Auf der anderen Seite sind aber alle Entwickler aufgefordert, ihre Korrekturen zur Überprüfung an diese Liste zu senden. Dies trifft besonders auf Änderungen zu, in denen ein Fehler die Integrität des Gesamtsystems gefährdet. FREEBSD-BINUP FreeBSD Binary Update Project Auf dieser Liste wird das Design und die Implementierung von binup diskutiert. Weitere Themen sind Fehlerbehebungen, Fehlerberichte und Anfragen nach Neuerungen. Die CVS-Logmeldungen des Projekts werden ebenfalls auf diese Liste gesendet. FREEBSD-BUGBUSTERS Bearbeitung der Fehlerberichte Auf dieser Liste wird die Bearbeitung der Fehlerberichte (PR, engl. problem report) koordiniert. Sie dient dem Bugmeister und allen Leuten, die ein Interesse an der Datenbank der Fehlerberichte haben, als Diskussionsforum. Auf dieser Liste werden keine spezifischen Fehler, Fehlerbehebungen oder PRs diskutiert. FREEBSD-BUGS Fehlerberichte Auf dieser Liste werden Fehlerberichte gesammelt. Fehlerberichte sollten immer mit &man.send-pr.1; oder dem Web Formular erstellt werden. FREEBSD-CHAT Nicht technische Themen, die die FreeBSD Gemeinschaft betreffen Auf dieser Liste werden nicht-technische soziale Themen diskutiert, die nicht auf die anderen Listen passen. Hier kann diskutiert werden, ob Jordan wie ein Frettchen aus einem Zeichentrickfilm aussieht oder nicht, ob grundsätzlich in Großbuchstaben geschrieben werden soll, wer zuviel Kaffee trinkt, wo das beste Bier gebraut wird und wer Bier in seinem Keller braut. Gelegentlich können auf den technischen Listen wichtige Ereignisse wie Feste, Hochzeiten oder Geburten angekündigt werden, aber nachfolgende Nachrichten sollten auf die Liste &a.chat; gesendet werden. FREEBSD-CORE FreeBSD Core Team Dies ist eine interne Mailingliste des FreeBSD Core Teams. Wenn in einer wichtigen Angelegenheit, die FreeBSD betrifft, entschieden werden muss oder die Angelegenheit einer genauen Prüfung unterzogen werden muss, können Nachrichten an diese Liste gesendet werden. FREEBSD-CURRENT Gebrauch von &os.current; Diese Mailingliste ist für die Benutzer von &os.current; eingerichtet. Auf ihr finden sich Ankündigungen über Besonderheiten von -CURRENT, von denen Benutzer betroffen sind. Sie enthält weiterhin Anweisungen, wie man ein System auf -CURRENT hält. Jeder, der ein -CURRENT System besitzt, muss diese Liste lesen. Die Liste ist nur für technische Inhalte bestimmt. FREEBSD-CURRENT-DIGEST Gebrauch von &os.current; Dies ist die Zusammenfassung der Mailingliste &a.current;. Alle Nachrichten der Liste &a.current; werden gesammelt und in einer E-Mail versendet. Die Zusammenfassung ist nur zum Lesen gedacht, schicken Sie keine Nachrichten an diese Liste. FREEBSD-CVSWEB FreeBSD CVSweb Project Technische Diskussion über den Gebrauch, die Entwicklung und die Pflege von FreeBSD-CVSweb. FREEBSD-DOC Documentation Project Auf dieser Mailingliste werden Themen und Projekte diskutiert, die im Zusammenhang mit der Erstellung der FreeBSD Dokumentation stehen. The FreeBSD Documentation Project besteht aus den Mitgliedern dieser Liste. Diese Liste steht jedem offen, Sie sind herzlich eingeladen teilzunehmen und mitzuhelfen. FREEBSD-FIREWIRE Firewire (iLink, IEEE 1394) Auf dieser Liste wird das Design und die Implementierung eines Firewire-Subsystems (auch IEEE 1394 oder iLink) für FreeBSD diskutiert. Relevante Themen sind die Standards, Busse und ihre Protokolle, sowie Adapter, Karten und Chipsätze. Des Weiteren die Architektur und der Quellcode, die nötig sind, diese Geräte zu unterstützen. FREEBSD-FS Dateisysteme Diskussionen über FreeBSD Dateisysteme. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. FREEBSD-GNOME GNOME Diskussionen über die grafische Benutzeroberfläche GNOME. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. FREEBSD-IPFW IP Firewall Diskussionen über eine Neubearbeitung des IP-Firewall Quelltexts in FreeBSD. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. FREEBSD-IA64 Portierung von FreeBSD auf die IA64-Plattform Dies ist eine technische Liste für diejenigen, die FreeBSD auf die IA-64 Plattform von Intel portieren. Themen sind die Probleme bei der Portierung und deren Lösung. Interessierte, die der Diskussion folgen wollen, sind ebenfalls willkommen. FREEBSD-ISDN ISDN Subsystem Mailingliste für die Entwickler des ISDN Subsystems von FreeBSD. FREEBSD-JAVA Java Entwicklung Mailingliste, auf der die Entwicklung von Java Anwendungen für FreeBSD sowie die Portierung und Pflege von JDKs diskutiert wird. FREEBSD-HACKERS Technische Diskussionen Dies ist ein Forum für technische Diskussionen über FreeBSD. Leute, die aktiv an FreeBSD arbeiten, können hier Probleme und deren Lösungen diskutieren. Interessierte, die den Diskussionen folgen wollen, steht die Liste ebenfalls offen. Auf dieser Liste finden nur technische Diskussionen statt. FREEBSD-HACKERS-DIGEST Technische Diskussionen Dies ist die Zusammenfassung der Mailingliste &a.hackers;. Alle Nachrichten der Liste &a.hackers; werden gesammelt und in einer E-Mail versendet. Die Zusammenfassung ist nur zum Lesen gedacht, schicken Sie keine Nachrichten an diese Liste. FREEBSD-HARDWARE Allgemeine Diskussionen über Hardware Allgemeine Diskussionen über die Hardware, auf der FreeBSD läuft: Probleme und Ratschläge welche Hardware man kaufen sollte und welche nicht. FREEBSD-HUBS FreeBSD Spiegel Ankündigungen und Diskussionsforum für Leute, die FreeBSD Spiegel betreiben. FREEBSD-INSTALL Entwicklung von Installations-Werkzeugen Auf dieser Liste wird die Entwicklung von Installations-Werkzeugen für künftige Releases diskutiert. FREEBSD-ISP Themen für Internet Service Provider Diese Liste ist für Internet Service Provider (ISP), die FreeBSD benutzen. Auf dieser Liste finden nur technische Diskussionen statt. FREEBSD-NEWBIES Starthilfen für neue FreeBSD Benutzer Ein Forum für Aktivitäten von Neulingen, die anderswo nicht behandelt werden, wie selbständiges Lernen, Techniken zur Problemlösung, Suchen und Benutzen von Ressourcen, wo man Hilfe findet, wie Mailinglisten benutzt werden und welche Listen man abonnieren sollte, allgemeine Unterhaltungen und Geschichten, Berichte über Fehler, die man gemacht hat, Prahlen mit eigenen Erfolgen, Mitteilen von Ideen, moralische (aber keine technische) Unterstützung und wie man aktiver Teil der FreeBSD Gesellschaft wird. Fragen und Probleme werden auf der Liste &a.questions; behandelt, die Mailingliste &a.newbies; gibt neuen FreeBSD Benutzern die nötigen Starthilfen. FREEBSD-OPENOFFICE OpenOffice.org Portierung und Pflege von OpenOffice.org und StarOffice. FREEBSD-PLATFORMS Portierung auf nicht-Intel Plattformen Plattformübergreifende Themen und Vorschläge für die Portierung auf nicht-Intel Plattformen. Auf dieser Liste finden nur technische Diskussionen statt. FREEBSD-POLICY Grundsatzentscheidungen des Core Teams Diese Mailingliste ist für Grundsatzentscheidungen des FreeBSD Core Teams. Sie trägt wenige Nachrichten und ist nur zum Lesen gedacht. FREEBSD-PORTS Diskussion über die Ports-Sammlung Diskussionen über die FreeBSD Ports-Sammlung, neue Ports, Veränderungen am System der Ports-Sammlung. Die Liste dient auch der allgemeinen Koordination der Dinge, die die Ports-Sammlung betreffen. Auf dieser Liste finden nur technische Diskussionen statt. FREEBSD-QUESTIONS Benutzerfragen Auf dieser Mailingliste können Fragen über FreeBSD gestellt werden. Fragen Sie bitte nicht nach Anleitungen, wenn Sie nicht sicher sind, dass Ihre Frage wirklich technischer Natur ist. FREEBSD-QUESTIONS-DIGEST Benutzerfragen Dies ist die Zusammenfassung der Mailingliste &a.questions;. Die Nachrichten der Liste werden gesammelt und in einer E-Mail versendet. FREEBSD-SCSI SCSI Subsystem Diese Mailingliste ist für die Entwickler des SCSI Subsystems von FreeBSD. Auf dieser Liste finden nur technische Diskussionen statt. FREEBSD-SECURITY Sicherheitsthemen Sicherheitsthemen, die FreeBSD betreffen, wie DES, Kerberos, bekannte Sicherheitslöcher und Fehlerbehebungen. Stellen Sie bitte auf dieser Liste keine allgemeinen Fragen zum Thema Sicherheit. Willkommen sind allerdings Beiträge zur FAQ, das heißt eine Frage mit der passenden Antwort. Auf dieser Liste finden nur technische Diskussionen statt. FREEBSD-SECURITY-NOTIFICATIONS Ankündigungen zum Thema Sicherheit Ankündigungen über Sicherheitsprobleme von FreeBSD und deren Behebungen. Diese Liste ist kein Diskussionsforum, benutzen Sie &a.security;, um Sicherheitsthemen zu diskutieren. FREEBSD-SMALL Gebrauch von FreeBSD in eingebetteten Systemen. Diese Liste für ungewöhnlich kleine FreeBSD Installation oder den Einsatz von FreeBSD in eingebetteten Systemen gedacht. Auf dieser Liste finden nur technische Diskussionen statt. FREEBSD-STABLE Gebrauch von &os.stable;. Diese Mailingliste ist für die Benutzer von &os.stable; eingerichtet. Auf ihr finden sich Ankündigungen über Besonderheiten von -STABLE, von denen Benutzer betroffen sind. Sie enthält weiterhin Anweisungen, wie man ein System auf -STABLE hält. Jeder, der ein -STABLE System besitzt, muss diese Liste lesen. Die Liste ist nur für technische Inhalte bestimmt. FREEBSD-STANDARDS Konformität von FreeBSD mit den C99- und POSIX-Standards Dieses Forum ist für technische Diskussionen über die Konformität von FreeBSD mit den C99- und POSIX-Standards. FREEBSD-USER-GROUPS Koordination von Benutzergruppen Diese Liste ist für Koordinatoren lokaler Benutzergruppen und einem ausgesuchten Mitglied des Core Teams eingerichtet worden. Der Inhalt sollte Inhalte von Treffen und die Koordination von Projekten mehrerer Benutzergruppen beschränkt sein. FREEBSD-VENDORS Koordination von Händlern Koordination zwischen dem FreeBSD Projekt und Händlern, die Soft- und Hardware für FreeBSD verkaufen. Usenet-News Neben den Gruppen, die sich ausschließlich mit BSD beschäftigen, gibt es viele weitere in denen über FreeBSD diskutiert wird, oder die für FreeBSD Benutzer wichtig sind. Warren Toomey wkt@cs.adfa.edu.au stellte großzügig suchbare Archive einiger dieser Gruppen bereit. BSD spezifische Gruppen comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (Deutsch) fr.comp.os.bsd (Französisch) Weitere Unix Gruppen comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web Server http://www.FreeBSD.org/ — Hauptserver. http://www.ar.FreeBSD.org/ — Armenien. http://www.au.FreeBSD.org/ — Australien/1. http://www2.au.FreeBSD.org/ — Australien/2. http://www3.au.FreeBSD.org/ — Australien/3. http://www4.au.FreeBSD.org/ — Australien/4. http://www5.au.FreeBSD.org/ — Australien/5. http://www6.au.FreeBSD.org/ — Australien/6. http://http://freebsd.itworks.com.au/ — Australien/7. freebsd.unixtech.be/ — Belgien. http://www.br.FreeBSD.org/ — Brasilien/1. http://www2.br.FreeBSD.org/ — Brasilien/2. http://www3.br.FreeBSD.org/ — Brasilien/3. http://www.bg.FreeBSD.org/ — Bulgarien. http://www.cn.FreeBSD.org/ — China. http://www.dk.FreeBSD.org/ — Dänemark. http://www3.dk.FreeBSD.org/ — Dänemark/3. http://www.de.FreeBSD.org/ — Deutschland/1. http://www1.de.FreeBSD.org/ — Deutschland/2. http://www2.de.FreeBSD.org/ — Deutschland/3. http://www.ee.FreeBSD.org/ — Estland. http://www.fi.FreeBSD.org/ — Finnland. http://www2.fi.FreeBSD.org/ — Finnland/2. http://www.fr.FreeBSD.org/ — Frankreich. http://www.gr.FreeBSD.org/ — Griechenland. http://www.uk.FreeBSD.org/ — Großbritannien/1. http://www2.uk.FreeBSD.org/ — Großbritannien/2. http://www3.uk.FreeBSD.org/ — Großbritannien/3. http://www4.uk.FreeBSD.org/ — Großbritannien/4. http://www.hk.FreeBSD.org/ — Hong Kong. http://www.ie.FreeBSD.org/ — Irland. http://www2.ie.FreeBSD.org/ — Irland/2. http://www.is.FreeBSD.org/ — Island. http://www.il.FreeBSD.org/ — Israel. http://www.it.FreeBSD.org/ — Italien. http://www.gufi.org/mirrors/www.freebsd.org/data/ — Italien/2. http://www.jp.FreeBSD.org/www.FreeBSD.org/ — Japan. http://www.ca.FreeBSD.org/ — Kanada. http://www3.ca.FreeBSD.org/ — Kanada/3. http://www.kr.FreeBSD.org/ — Korea/1. http://www2.kr.FreeBSD.org/ — Korea/2. http://www3.kr.FreeBSD.org/ — Korea/3. http://www.lv.FreeBSD.org/ — Lettland. http://www.lt.FreeBSD.org/ — Litauen. http://rama.asiapac.net/freebsd/ — Malaysia. http://www.nz.FreeBSD.org/ — Neuseeland. http://www.nl.FreeBSD.org/ — Niederlande/1. http://www2.nl.FreeBSD.org/ — Niederlande/2. http://www.no.FreeBSD.org/ — Norwegen. http://www.no2.FreeBSD.org/ — Norwegen/2. http://www.FreeBSD.org.ph/ — Philippinen. http://www.at.FreeBSD.org/ — Österreich. http://www2.at.FreeBSD.org/ — Österreich/2. http://www.pl.FreeBSD.org/ — Polen/1. http://www2.pl.FreeBSD.org/ — Polen/2. http://www2.pt.FreeBSD.org/ — Portugal/2. http://www3.pt.FreeBSD.org/ — Portugal/3. http://www4.pt.FreeBSD.org/ — Portugal/4. http://www.ro.FreeBSD.org/ — Rumänien. http://www2.ro.FreeBSD.org/ — Rumänien/2. http://www3.ro.FreeBSD.org/ — Rumänien/3. http://www4.ro.FreeBSD.org/ — Rumänien/4. http://www.ru.FreeBSD.org/ — Russland/1. http://www2.ru.FreeBSD.org/ — Russland/2. http://www3.ru.FreeBSD.org/ — Russland/3. http://www4.ru.FreeBSD.org/ — Russland/4. http://www.sm.FreeBSD.org/ — San Marino. http://www.se.FreeBSD.org/ — Schweden. http://www.se2.FreeBSD.org/ — Schweden/2. http://www.ch.FreeBSD.org/ — Schweiz. http://www.ch2.FreeBSD.org/ — Schweiz/2. http://www.sg.FreeBSD.org/ — Singapur. http://www2.sg.FreeBSD.org/ — Singapur/2. http://www.sk.FreeBSD.org/ — Slowakische Republik. http://www.sk2.FreeBSD.org/ — Slowakische Republik/2. http://www.si.FreeBSD.org/ — Slowenien. http://www2.si.FreeBSD.org/ — Slowenien/2. http://www.es.FreeBSD.org/ — Spanien. http://www2.es.FreeBSD.org/ — Spanien/2. http://www3.es.FreeBSD.org/ — Spanien/3. http://www.za.FreeBSD.org/ — Südafrika/1. http://www2.za.FreeBSD.org/ — Südafrika/2. http://www.tw.FreeBSD.org/www.freebsd.org/data/ — Taiwan. http://www2.tw.FreeBSD.org/ — Taiwan/2. http://www3.tw.FreeBSD.org/ — Taiwan/3. http://www4.tw.FreeBSD.org/ — Taiwan/4. http://www.cz.FreeBSD.org/ — Tschechische Republik. http://www.tr.FreeBSD.org/ — Türkei. http://www.tr2.FreeBSD.org/ — Türkei/2. http://www.enderunix.org/freebsd/ — Türkei/3. http://www.ua.FreeBSD.org/www.freebsd.org/ — Ukraine/1. http://www2.ua.FreeBSD.org/ — Ukraine/2. http://www4.ua.FreeBSD.org/ — Ukraine/Crimea. http://www5.ua.FreeBSD.org/ — Ukraine/5. http://www.hu.FreeBSD.org/ — Ungarn. http://www.hu2.FreeBSD.org/ — Ungarn/2. http://www2.FreeBSD.org/ — USA/Texas. http://www3.FreeBSD.org/ — USA/3. http://www7.FreeBSD.org/ — USA/7. E-Mail Adressen Die folgenden Benutzergruppen stellen ihren Mitgliedern für die Arbeit an FreeBSD E-Mail Adressen zur Verfügung. Der aufgeführte Administrator behält sich das Recht vor, die Adresse zu sperren, wenn sie missbraucht wird. Domain Angebot Benutzergruppe Administrator ukug.uk.FreeBSD.org nur zum Weiterleiten freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Shell Accounts Die folgenden Benutzergruppen stellen Personen, die das FreeBSD Projekt aktiv unterstützen, Shell-Accounts zur Verfügung. Der aufgeführte Administrator behält sich das Recht vor, den Account zu sperren, wenn er missbraucht wird. Rechner Zugriff Angebot Administrator storm.uk.FreeBSD.org nur SSH lesender Zugriff auf CVS, persönliche Webseiten, E-Mail &a.brian; dogma.freebsd-uk.eu.org Telnet/FTP/SSH E-Mail, Webseiten, Anonymous FTP Lee Johnston lee@uk.FreeBSD.org