FreeBSD ist ein modernes Betriebssystem für Server, Desktops und eingebettete Systeme, das auf zahlreichen Plattformen läuft.

Es basiert auf dem „4.4BSD-Lite“-Release der U.C. Berkeley, mit einigen Erweiterungen aus „4.4BSD-Lite2“. Es basiert außerdem indirekt auf der von William Jolitz unter dem Namen „386BSD“ herausgebrachten Portierung des „Net/2“-Releases für i386™ der U.C. Berkeley. Allerdings ist nur sehr wenig vom ursprünglichen 386BSD Code übrig geblieben.

Unternehmen, Internet Service Provider, Forscher, Computerfachleute, Studenten und Privatnutzer auf der ganzen Welt benutzen FreeBSD für die Arbeit, die Ausbildung oder in der Freizeit.

Ausführlichere Informationen zu FreeBSD, finden Sie im FreeBSD Handbuch.

Das Ziel des FreeBSD Projects ist es, ein stabiles und schnelles Betriebssystem zur Verfügung zu stellen, das Sie für jeden Zweck verwenden können, ohne dabei irgendwelche Bedingungen in Kauf nehmen zu müssen.

Ja. Diese Einschränkungen regeln aber nicht, wie Sie mit dem Quellcode umgehen, sondern betreffen nur den Umgang mit dem FreeBSD Project an sich. Die Lizenz ist unter http://www.FreeBSD.org/copyright/freebsd-license.html verfübar und lässt sich wie folgt zusammenfassen:

Viele von uns haben erheblich zur Erstellung des Codes (und zum Projekt) beigetragen und hätten jetzt oder in Zukunft sicherlich nichts gegen einen geringen finanziellen Ausgleich einzuwenden, aber wir beabsichtigen definitiv nicht, darauf zu bestehen. Wir sind der Meinung, dass unsere „Mission“ zuerst und insbesondere darin besteht, allen und jedem Kommenden Code für welchen Zweck auch immer zur Verfügung zu stellen, damit der Code möglichst weit eingesetzt wird und den größtmöglichen Nutzen liefert. Das ist, so glauben wir, eines der fundamentalsten Ziele von freier Software und eines, das wir enthusiastisch unterstützen.

Der Code in unserem Quellbaum, der der GNU General Public License (GPL) oder der GNU Library General Public License (LGPL) unterliegt, ist mit zusätzlichen Bedingungen verknüpft, jedoch handelt es sich dabei lediglich um erzwungene Bereitstellung statt des sonst üblichen Gegenteils. Auf Grund der zusätzlichen Komplexität, die durch den kommerziellen Einsatz von GPL Software entstehen kann, bemühen wir uns jedoch, solche Software, wo möglich, durch solche, die der etwas lockereren FreeBSD Lizenz unterliegt, zu ersetzen.

In den meisten Fällen lautet die Antwort: Ja! Allerdings ist diese Frage nicht ganz so einfach, wie sie scheint.

Die meisten Anwender benutzen kein Betriebssystem, sondern Anwendungen. Die Anwendungen sind es, die das Betriebssystem benutzen. FreeBSD wurde entworfen, Anwendungen eine stabile und funktionsreiche Umgebung zu bieten. Es unterstützt viele unterschiedliche Web-Browser, Büroanwendungen, E-Mail-Programme, Grafik-Programme, Entwicklungsumgebungen, Netzwerk-Server, und vieles mehr. Die meisten dieser Anwendungen sind in der Ports-Sammlung verfügbar.

Wenn Sie eine Anwendung benutzen müssen, die es nur für ein bestimmtes Betriebssystem gibt, dann kommen Sie an diesem Betriebssystem nicht vorbei. Allerdings stehen die Chancen nicht schlecht, dass es eine vergleichbare Anwendung für FreeBSD gibt.

Wenn Sie von einem anderen UNIX® System zu FreeBSD wechseln, dürfte Ihnen vieles bekannt vorkommen. Wenn Ihr Hintergrund ein Betriebssystem wie Windows® oder MacOS®ist, sind Sie vielleicht an TrueOS interessiert, eine auf FreeBSD basierende Desktop-Distribution. Wenn Sie vorher noch nicht mit UNIX® gearbeitet haben, werden Sie zusätzliche Zeit investieren müssen, um den UNIX® Stil zu verstehen. Diese FAQ und das FreeBSD Handbuch sind die besten Startpunkte.

Es wird darauf hingewiesen, dass das englische Wort „free“ hier in den Bedeutungen „umsonst“ und „Sie können tun, was immer Sie möchten“ genutzt wird. Abgesehen von ein oder zwei Dingen, die Sie mit dem FreeBSD-Code nicht tun können (z.B. vorgeben, ihn geschrieben zu haben), können Sie damit tatsächlich tun, was auch immer Sie möchten.

James Howards Artikel, genannt The BSD Family Tree,, beschreibt sehr gut die Geschichte und die Unterschiede der BSD-Varianten.

Die meisten der BSDs teilen auch heute noch Patches und Code. Außerdem haben alle BSDs eine gemeinsame Herkunft.

Die Ziele von FreeBSD sind in F: 1.2 beschrieben. Die Ziele der anderen bekannten BSDs können wie folgt zusammengefasst werden:

Momentan gibt es zwei Entwicklungszweige, die für die Erstellung von Releases verwendet werden. Die 10.X-RELEASEs werden auf dem 10-STABLE-Zweig erstellt, die 9.X-RELEASEs auf dem 9-STABLE-Zweig.

Bis zur Veröffentlichung von FreeBSD 9.0 galt die 9.X-Serie als -STABLE. Seit FreeBSD 11.X gibt es für den Zweig 9.X nur mehr eine „erweiterte Unterstützung“ in der Form von Korrekturen von größeren Problemen, wie neu entdeckten Sicherheitsheitslücken.

Version 10.3 ist das aktuelle Release des 10-STABLE-Zweigs und ist im April 2016 erschienen. Version 9.3 ist das aktuelle Release aus dem 9-STABLE-Zweig und ist im Juli 2014 erschienen.

Releases werden nur alle paar Monate erstellt. Viele Leute halten ihre Systeme aktueller (lesen Sie die Fragen zu FreeBSD-CURRENT und FreeBSD-STABLE), aber das erfordert ein erhöhtes Engagement, da der Quellcode sich ständig verändern.

Weitere Informationen über FreeBSD-Releases finden Sie auf der Release Engineering Seite und in release(7).

FreeBSD-CURRENT ist die Entwicklungsversion des Betriebssystems, aus der zu gegebener Zeit der FreeBSD-STABLE-Zweig entstehen wird. Als solche ist sie lediglich für Entwickler, die am System mitarbeiten und für unentwegte Bastler von Interesse. Details zum Betrieb von -CURRENT finden Sie im entsprechenden Abschnitt des Handbuchs.

Falls Sie mit FreeBSD nicht vertraut sind, sollten Sie FreeBSD-CURRENT nicht verwenden. Dieser Zweig entwickelt sich manchmal sehr schnell weiter und kann gelegentlich nicht installierbar sein. Von Personen, die FreeBSD-CURRENT verwenden, wird erwartet, dass Sie dazu in der Lage sind, Probleme zu erkennen, zu analysieren und diese an das Projekt zurückzumelden.

Jeden Monat wird der aktuelle Entwicklungsstand in den Zweigen -CURRENT und -STABLE in einer Snapshot Release festgehalten. Die Ziele dieser Snapshot Releases sind:

Von keinem -CURRENT Snapshot kann „Produktionsqualität“ für beliebige Zwecke erwartet werden. Wenn Sie eine stabile und ausgetestete Version benötigen, sollten Sie ein vollständiges Release verwenden.

Snapshot-Releases sind auf der Snapshots-Seite verfügbar.

Offizielle Snapshots werden in regelmäßigen Abständen für jeden aktiven Zweig erstellt.

Zur der Zeit, als FreeBSD 2.0.5 herausgegeben wurde, wurde entschieden, die Entwicklung von FreeBSD zweizuteilen. Ein Zweig wurde -STABLE, der andere -CURRENT genannt. FreeBSD-STABLE ist der Entwicklungszweig aus dem die Hauptversionen erstellt werden. In diesem Zweig gehen nur Änderungen ein, wenn sie zuvor sorgfältig in FreeBSD-CURRENT getestet wurden. Gelegentlich können die Quellen für FreeBSD-STABLE möglicherweise nicht für den allgemeinen Gebrauch geeignet sein, da es Fehler enthalten können, die noch nicht in FreeBSD-CURRENT gefunden wurden. Benutzer, die nicht über genügend Ressourcen verfügen um zu testen, sollten stattdessen die aktuelle Version von FreeBSD verwenden. FreeBSD-CURRENT ist eine ununterbrochene Linie seitdem die Version 2.0 herausgegeben worden ist. Sie führt zu 11.0-RELEASE (und darüber hinaus). Weitere Informationen zu diesen Zweigen finden Sie unter „FreeBSD Release Engineering: Creating the Release Branch“, der Status der Zweige und der Zeitplan zur anstehenden Veröffentlichung kann auf der Seite Release Engineering Information gefunden werden.

11.0-STABLE ist der Zweig, auf den sich die Entwicklung von -STABLE zur Zeit konzentriert. Das neueste Release aus dem 11.0-STABLE-Zweig ist 11.0-RELEASE und ist im Oktober 2016 erschienen.

Aus dem 11-CURRENT-Zweig ist der aktiv entwickelte CURRENT-Zweig, aus dem die nächste FreeBSD-Generation entsteht. Weitere Informationen über diesen Zweig finden Sie unter Was ist FreeBSD-CURRENT?.

In der Regel gibt das Release Engineering Team <re@FreeBSD.org> alle 18 Monate eine neue Hauptversion und etwa alle 8 Monate eine Unterversion frei. Das Erscheinungsdatum einer Version wird frühzeitig bekanntgegeben, damit die am System arbeitenden Personen wissen, bis wann ihre Projekte abgeschlossen und getestet werden müssen. Vor jedem Release gibt es eine Testperiode um sicherzustellen, dass die neu hinzugefügten Features nicht die Stabilität des Releases beeinträchtigen. Viele Benutzer halten dies für einen großen Vorteil von FreeBSD, obwohl es manchmal frustrierend sein kann, so lange auf die Verfügbarkeit der aktuellsten Funktionen zu warten.

Weitere Informationen über die Entwicklung von Releases, sowie eine Übersicht über kommende Releases, erhalten Sie auf den Release Engineering Seiten der FreeBSD Webseite.

Für diejenigen, die ein wenig mehr Spannung möchten, werden täglich Snapshots herausgegeben, wie oben beschrieben.

Schlüsseldiskussionen, die das FreeBSD Project betreffen, wie z.B. über die generelle Ausrichtung des Projekts und darüber, wem es erlaubt sein soll, Code zum Quellbaum hinzuzufügen, werden innerhalb eines Core Teams von 9 Personen geführt. Es gibt ein weitaus größeres Team von über 350 Committern, die dazu autorisiert sind, Änderungen am FreeBSD Quellbaum durchzuführen.

Jedoch werden die meisten nicht-trivialen Änderungen zuvor in den Mailinglisten diskutiert und es bestehen keinerlei Einschränkungen darüber, wer sich an diesen Diskussionen beteiligen darf.

Jede bedeutende Ausgabe von FreeBSD ist per Anonymous-FTP vom FreeBSD FTP Server erhältlich:

Wo und wie Sie FreeBSD auf CD, DVD, und anderen Medien beziehen können, erfahren Sie im Handbuch.

Die Datenbank mit Problemberichten (PR, problem report) und Änderungsanfragen von Benutzern kann über die webbasierte PR-Abfrage-Schnittstelle abgefragt werden.

Über die webbasierte PR-Schnittstelle können Sie Problemberichte über einen Webbrowser einreichen.

Bevor Sie einen Fehler melden, sollten Sie zuerst Writing FreeBSD Problem Reports lesen, damit Sie wissen, wie Sie eine gute Fehlermeldung verfassen.

Im Zuge des FreeBSD Projekts sind diverse gute Dokumente entstanden, die unter der folgenden URL abgerufen werden können: http://www.FreeBSD.org/de/docs.html. Zusätzlich enthält die Bibliographie am Ende dieser FAQ und diejenige im Handbuch Verweise auf weitere empfohlene Bücher.

Ja. Werfen Sie einen Blick auf das Verzeichnis /pub/FreeBSD/doc/ auf dem FreeBSD FTP-Server. Dort finden Sie Dokumentation in vielen verschiedenen Formaten.

Die Dokumentation wurde nach verschiedenen Kriterien sortiert. Die Kriterien sind:

Nachdem Sie das Format und das Kompressionsverfahren ausgewählt haben, müssen Sie die komprimierten Dateien herunterladen, entpacken und an die richtigen Stellen kopieren.

Zum Beispiel finden Sie die mit bzip2(1) gepackte split-html Version der englischen FAQ in doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2. Um diese Datei herunterzuladen und auszupacken, sind die folgenden Schritte notwendig:

# fetch ftp://ftp.de.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2
# tar xvf book.html-split.tar.bz2

Wenn die Datei komprimiert ist, wird tar automatisch das entsprechende Format erkennen und die Datei korrekt dekomprimieren. Danach haben Sie eine Sammlung vieler kleiner .html Dateien. Die wichtigste Datei hat Namen index.html und enthält das Inhaltsverzeichnis, eine Einleitung und Verweise auf die anderen Teile des Dokumentes.

Lesen Sie den Handbucheintrag über Mailinglisten und den Handbucheintrag zu Newsgruppen.

Ja, die meisten großen IRC Netze bieten einen FreeBSD Chat-Channel:

Das FreeBSD Wiki enthält eine Liste mit IRC Kanälen.

Alle diese Kanäle unterscheiden sich voneinander und sind nicht miteinander verbunden. Ebenso unterscheiden sich die jeweiligen Chat-Stile, weshalb es sein kann, dass Sie zunächst alle Kanäle ausprobieren müssen, um den zu Ihrem Chat-Stil passenden zu finden.

Die offiziellen FreeBSD Foren befinden sich unter https://forums.FreeBSD.org/.

iXsystems, Inc., die Muttergesellschaft der FreeBSD Mall, bietet kommerziellen Support für FreeBSD und TrueOS sowie FreeBSD-spezifische Softwareentwicklung und Hilfe bei Optimierung Ihrer vorhandenen Installationen.

Die BSD Certification Group, Inc. bietet Zertifizierungen zur Systemadministration für DragonFly BSD, FreeBSD, NetBSD und OpenBSD. Besuchen Sie deren Webseite für weitere Informationen.

Wenn Ihre Firma oder Organisation ebenfalls Training und Support anbietet und hier genannt werden möchte, wenden Sie sich bitte an das FreeBSD Project.

Unter FreeBSD wird der Begriff amd64 für 64-Bit-kompatibel x86-Architekturen verwendet (auch als "x86-64" oder "x64" bekannt). Die meisten modernen Rechner sollten amd64 verwenden. Ältere Hardware sollte i386 verwenden. Wenn Sie FreeBSD auf einer nicht-x86-kompatible Architektur installieren, wählen Sie die Plattform, die am besten mit der verwendeten Hardware übereinstimmt.

Auf der Seite Download FreeBSD können Sie das [iso] für die entsprechende Hardware wählen.

Sie können eine der folgenden Dateien wählen:

pc98-Benutzer benötigen drei Floppy-Images: floppies/boot.flp, floppies/kern1.flp, floppies/kern2.flp, und floppies/mfsroot1.flp. Diese Images müssen mit Hilfe von Werkzeugen wie dd(1) auf Disketten kopiert werden.

Eine vollständige Anleitung für dieses Vorgehen und weitere Informationen zur Installation finden Sie im Handbucheintrag zur Installation von FreeBSD.

Stellen Sie sicher, dass Sie das Image im binary-Modus herunterladen, wenn Sie FTP verwenden.

Einige FTP-Clients benutzen als Voreinstellung den ascii-Modus und versuchen, alle Zeilenendezeichen an das Zielsystem anzupassen. Dadurch wird das Boot-Image fast immer unbrauchbar. Überprüfen Sie daher die SHA-256 Prüfsumme des heruntergeladenen Boot-Images: wenn diese nicht genau mit der Prüfsumme auf dem Server übereinstimmt, sollten Sie das Image verwerfen und den Download erneut versuchen.

Wenn Sie einen FTP-Client für die Kommandozeile benutzen, geben Sie am FTP-Prompt binary ein, nachdem Sie sich mit dem Server verbunden haben und bevor Sie das Image herunterladen.

Installationsanleitungen finden Sie im Handbucheintrag zur Installation von FreeBSD.

Der Betrieb von FreeBSD erfordert mindestens einen 486er Prozessor, 64 MB RAM sowie mindestens 1.1 GB an Festplattenspeicher.

Individuelle FreeBSD Installationsmedien können über den Bau eines Releases erzeugt werden. Folgen Sie den Anweisungen im Artikel Release Engineering.

Ja, vorausgesetzt Sie installieren zuerst Windows®. Der Bootmanager von FreeBSD kann dann entweder Windows® oder FreeBSD booten. Falls Sie Windows® nach FreeBSD installieren, wird es, ohne zu fragen, den Bootmanager überschreiben. Lesen Sie den nächsten Abschnitt, falls das passieren sollte.

Das hängt vom Bootmanager ab. Der FreeBSD Bootmanager kann mit boot0cfg(8) neu installiert werden. Benutzen Sie bspw. folgendes Kommando, um den auf der Platte ada0 wiederherzustellen:

# boot0cfg -B ada0

Der MBR Bootloader kann mit gpart(8) installiert werden:

# gpart bootcode -b /boot/mbr ada0

Für anspruchsvollere Situationen, u. a. mit GPT partitionierte Platten, lesen Sie gpart(8).

Dieses Problem wird üblicherweise durch ein falsch konfiguriertes CD-ROM verursacht. Bei vielen PCs ist das CD-ROM der Slave am zweiten IDE-Controller, ein Master ist nicht vorhanden. Laut ATAPI-Spezifikation ist diese Konfiguration ungültig, aber Windows® verletzt die Spezifikation und das BIOS ignoriert sie, wenn es von einem CD-ROM booten soll. Daher konnten Sie zwar vom CD-ROM booten, während FreeBSD es nicht für die Installation benutzen kann.

Um dieses Problem zu lösen, müssen Sie entweder das CD-ROM als Master an den IDE-Controller anschließen oder dafür sorgen, dass an dem vom CD-ROM genutzten IDE-Controller das CD-ROM als Slave und ein anderes Gerät als Master angeschlossen ist.

Im allgemeinen nicht. Es gibt keine Komponenten im Betriebssystem, welche das Vorhandensein des Quellcodes erfordern. Einge Ports, wie sysutils/lsof, werden aber nicht bauen solange der Quellcode nicht installiert ist. Insbesondere dann, wenn der Port ein Kernel-Modul erzeugt oder direkt mit den Strukturen des Kernels arbeitet, müssen die Quellen installiert werden.

Normalerweise nicht. Der GENERIC-Kernel enthält bereits die Treiber, die ein gewöhnlicher Rechner benötigt. freebsd-update(8), das Werkzeug zur binären Aktualisierung von FreeBSD, ist jedoch nicht in der Lage angepasste Kernel zu aktualisieren. Dies ist ein weiterer Grund, wenn möglich, den GENERIC-Kernel einzusetzen. Für Rechner mit wenig RAM, bspw. eingebettete Systeme, kann es sich lohnen einen kleinen, angepassten Kernel zu erstellen, der nur die erforderlichen Treiber enthält.

FreeBSD 9 und neuere Versionen verwenden voreingestellt SHA512. Für die Abwärtskompatibilität mit älteren Betriebssystemen werden auch noch die weniger sicheren DES Passwörter unterstützt. FreeBSD unterstützt auch noch die Passwort-Formate Blowfish und MD5. Welches Format für neue Benutzer verwendet wird, wird mit passwd_format in /etc/login.conf gesteuert. Mögliche Werte sind des, blf (falls verfügbar), oder md5. Weitere Informationen finden Sie in der Manualpage login.conf(5).

Für FFS Dateisysteme ist die Größe des Dateisystems durch den Arbeitsspeicher abhängig, der benötigt wird um das Dateisystem mit fsck(8) zu prüfen. fsck(8) benötigt pro Fragment ein Bit, was bei einer Fragmentgröße von 4 KB bis 32 MB Arbeitsspeicher pro Terrabyte Plattenspeicher entspricht. Das bedeutet, dass auf Architekturen, die Userland-Prozesse auf 2 GB beschränken (zum Beispiel bei i386™), fsck(8) ein Dateisystem von ~ 60 TB prüfen kann.

Wenn es kein fsck(8) Limit gäbe, würde die maximale Größe eines Dateisystems 2 ^ 64 (Blöcke) * 32 KB => 16 Exa * 32 KB => 512 ZettaBytes betragen.

Die maximale Größer einer einzelnen FFS-Datei würde mit einer Standard-Blockgröße von 32 KB in etwa 2 Petabyte betragen. Jeder 32 KB-Block kann auf bis zu 4096 Blöcke verweisen. Mit dreifacher Indirektion ist die Berechnung 32 KB * 12 + 32 KB * 4096 + 32 KB * 4096 ^ 2 + 32 KB * 4096 ^ 3. Eine Erhöhung der Blockgröße auf 64 KB wird die maximale Dateigröße um den Faktor 16 erhöhen.

Das System und der Kernel sind nicht synchron. Dies wird nicht unterstützt. Stellen Sie sicher, dass Sie make buildworld und make buildkernel zum Aktualisieren des Kernels benutzen.

Starten Sie das System und wählen Sie den Kernel während der zweiten Bootphase aus. Drücken Sie dazu eine beliebige Taste, wenn das Zeichen | erscheint und bevor der Loader gestartet wird.

Ja. bsdconfig bietet eine einfache Oberfläche zur Konfiguration von FreeBSD.

Das liegt sehr wahrscheinlich an den Unterschieden zwischen physikalischen und virtuellen Speicheradressen.

Bei moderner PC-Hardware ist es üblich, den Speicherbereich zwischen 3,5 und 4 Gigabyte für spezielle Aufgaben (normalerweise für PCI) zu reservieren. Dieser Adressbereich wird dabei verwendet, um auf PCI-Hardware zuzugreifen. Dadurch kann in diesem Speicherbereich kein physikalischer Speicher verwaltet werden.

Was mit dem in diesen Bereich gehörenden physikalischen Speicher passiert, hängt von der eingesetzten Hardware ab. Unglücklicherweise gibt es noch immer Hardware, die hier gar nichts macht. In diesem Fall ist das System nicht in der Lage, auf diese 500 MB des RAMs zuzugreifen.

Ein Großteil der Hardware ist aber inzwischen in der Lage, diesen Speicherbereich in einen höheren Speicherbereich umzulenken, damit Sie weiterhin darauf zugreifen können. Allerdings kann es durch dieses Umlenken zu verwirrenden Meldungen während des Systemstarts kommen.

Unter 32-Bit-Versionen von FreeBSD scheint dieser Speicherbereich nicht verfügbar zu sein, da er in einen Bereich oberhalb von 4 Gigabyte übertragen wurde, auf den ein 32-Bit-Kernel allerdings nicht zugreifen kann. In diesem Fall müssen Sie die PAE-Unterstützung in den Kernel kompilieren. Lesen Sie dazu auch die entsprechenden Einträge über Speicherbegrenzungen und unterschiedliche Speicherbegrenzungen auf verschiedenen Plattformen.

Verwenden Sie hingegen eine 64-Bit-Version von FreeBSD oder einen 32-Bit-Kernel mit aktivierter PAE-Unterstützung, ist FreeBSD in der Lage, diesen Speicherbereich korrekt zu erkennen und umzulenken, damit Sie weiterhin darauf zugreifen können. Allerdings wird, aufgrund der beschriebenen Umbelegung, in diesem Fall beim Systemstart mehr Speicher angezeigt, als tatsächlich auf dem System vorhanden ist. Dies ist aber normal und wird nach dem Ende des Systemstarts automatisch korrigiert.

Das Signal 11 wird generiert, wenn ein Prozess versucht, auf Speicher zuzugreifen, obwohl er vom Betriebssystem dazu nicht befugt wurde. Wenn das scheinbar zufällig immer wieder passiert, sollten Sie der Sache auf den Grund gehen.

Das Problem hat in der Regel eine der folgenden Ursachen:

Wenn der Fehler auftritt, wenn Sie ein Programm kompilieren aber dabei immer wieder an anderer Stelle auftritt, dann ist das ein ganz eindeutiger Hinweis, dass das Problem nicht bei FreeBSD liegt.

Nehmen wir zum Beispiel an, dass Sie make buildworld ausführen und die Kompilierung von ls.c in ls.o abbricht. Wenn Sie nochmal make buildworld ausführen und die Kompilierung an der gleichen Stelle abbricht, handelt es sich um einen Fehler im Quellcode. Aktualisieren Sie den Code und versuchen Sie es noch einmal. Wenn der Fehler jedoch an einer anderen Stelle auftritt, liegt das Problem mit an Sicherheit grenzender Wahrscheinlichkeit bei der Hardware.

Im ersten Fall können Sie einen Debugger wie z.B. gdb(1) benutzen, um die Stelle im Programm zu finden, an der auf eine falsche Adresse zugegriffen wird und danach den Fehler beheben.

Im zweiten Fall müssen Sie sicherstellen, dass das Problem nicht von der Hardware verursacht wird.

Typische Ursachen dafür sind:

Lesen Sie den Abschnitt Signal 11 für weitere Erklärungen. Es existiert eine ausführliche FAQ hierzu unter the SIG11 problem FAQ.

Wenn alle diese Schritte nicht helfen, ist es möglich, dass Sie einen Fehler in FreeBSD gefunden haben. Folgen Sie einfach diesen Anweisungen für die Erstellung eines Problem Reports.

Die Entwickler von FreeBSD interessieren sich für solchen Meldungen, allerdings brauchen Sie deutlich mehr Informationen als nur die Fehlermeldung. Kopieren Sie die kompletten Meldungen und lesen Sie anschließend den FAQ-Abschnitt über kernel panics. Erzeugen sie einen Kernel mit den zusätzlichen Daten zur Fehlersuche, und dann einen Backtrace. Das hört sich komplizierter an, als es ist. Sie brauchen keine Programmier-Erfahrung, Sie müssen einfach nur den Anweisungen folgen.

Der FreeBSD-Kernel beschränkt die Anzahl der gleichzeitig laufenden Prozesse. Die Anzahl errechnet sich aus dem Wert der kern.maxusers sysctl(8)-Variable. Auch andere Einstellungen wie die Anzahl der Puffer für Netzwerkoperationen werden durch kern.maxusers beeinflusst. Wenn das System stark belastet ist, sollten Sie den Wert von kern.maxusers erhöhen. Dadurch werden diverse Einstellungen des Systems angepasst und die maximale Anzahl gleichzeitig laufender Prozesse erhöht.

Um den Wert von kern.maxusers anzupassen, folgen Sie den Anweisungen im Abschnitt Datei und Prozeß Limits des Handbuchs. Dieser Abschnitt spricht zwar nur von Dateien, für Prozesse gelten aber die gleichen Beschränkungen.

Wenn das System nicht besonders stark ausgelastet ist und Sie einfach nur mehr gleichzeitig laufende Prozesse erlauben wollen, können Sie den Wert der Variable kern.maxproc in /boot/loader.conf anpassen. Um die Änderung zu aktivieren, müssen Sie das System neu starten. Wollen Sie das System zusätzlich optimieren, sollten Sie loader.conf(5) lesen. Wenn diese Prozesse von einem einzigen Benutzer ausgeführt werden, müssen Sie den Wert von kern.maxprocperuid ebenfalls erhöhen. Dieser Wert muss immer mindestens um eins geringer sein als der Wert von kern.maxproc, weil ein Systemprogramm, init(8), immer ausgeführt werden muss.

Die entfernte Maschine scheint den Terminaltyp auf etwas anderes als den Typ xterm, der von FreeBSD verlangt wird, zu setzen. Vielleicht hat aber auch der Kernel falsche Werte für die Breite und Höhe des Terminals.

Überprüfen Sie, ob der Wert der TERM-Umgebungsvariable xterm ist. Wenn das entfernte Gerät dies nicht unterstützt, versuchen Sie vt100.

Führen Sie stty -a aus, um zu überprüfen, was der Kernel für Terminalaußmaße eingestellt hat. Wenn diese Werte falsch sind, können sie mit stty rows RR cols CC geändert werden.

Falls x11/xterm installiert ist, können Sie alternativ auch resize ausführen, um die richtigen Einstellungen für das Terminal zu setzen.

Das Symptom: Nach dem Aufbau des TCP-Verbindung vergeht einige Zeit, bis endlich die Abfrage des Passwortes (bzw. der Login-Prompt bei telnet(1)) erscheint.

Das Problem: In den meisten Fällen versucht der Server die IP-Adresse des Clients in einen Rechnernamen zu übersetzen. Viele Server, darunter die Telnet und SSH-Server von FreeBSD, machen das, um den Hostnamen in eine Protokolldatei zu schreiben.

Die Lösung: wenn das Problem bei jedem Server auftritt, den Sie von dem Computer (dem Client) ansprechen, dann wird das Problem vom Client verursacht. Wenn das Problem aber nur auftritt, wenn jemand den Rechner (den Server) anspricht, dann liegt die Ursache beim Server.

Wenn das Problem vom Client verursacht wird, müssen Sie die Einträge im DNS korrigieren, damit der Server die IP-Adresse übersetzen kann. Wenn das Problem im lokalen Netzwerk auftritt, sollten Sie es als Problem des Servers behandeln und weiterlesen; wenn es allerdings im Internet auftritt, sollten Sie Ihren ISP kontaktieren.

Wenn das Problem vom Server im lokalen Netzwerk verursacht wird, dann müssen Sie den Server so konfigurieren, dass er die lokal genutzten IP-Adressen in Rechnernamen übersetzen kann. Weitere Informationen finden Sie in hosts(5) und named(8). Wenn dieses Problem im Internet auftritt, könnte die Ursache auch darin liegen, dass die Namensauflösung auf dem Server nicht funktioniert. Versuchen Sie, einen anderen Hostnamen wie z.B. www.yahoo.com aufzulösen. Wenn das nicht funktioniert, ist das System nicht richtig konfiguriert.

Haben Sie FreeBSD gerade erst installiert, kann es auch sein, dass die Domänen- und Nameserverinformationen noch nicht in /etc/resolv.conf vorhanden sind. Dadurch kommt es häufig zu Verzögerungen beim Einsatz von SSH, weil die Option UseDNS in /etc/ssh/sshd_config in der Voreinstellung auf yes gesetzt ist. Wenn dies der Fall, müssen Sie entweder die fehlenden Informationen in /etc/resolv.conf eintragen oder als temporäre Maßnahme UseDNS auf no setzen.

Diese Fehlermeldung besagt, dass die zur Verfügung stehenden Datei-Deskriptoren des Systems aufgebraucht sind. Was das genau bedeutet und wie Sie dieses Problem lösen können, steht im Abschnitt kern.maxfiles im Kapitel Einstellungen von Kernel Limits des Handbuchs.

Der Rechner verfügt über mehr als eine Uhr und FreeBSD benutzt leider die falsche.

Starten Sie dmesg(8) und achten Sie auf die Zeilen, in denen das Wort Timecounter vorkommt. Die von FreeBSD benutzte Uhr findet sich in der Zeile mit dem höchsten quality-Wert.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Sie können das überprüfen, indem Sie den Wert der sysctl(3)-Variablen kern.timecounter.hardware abfragen.

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Es kann sich um einen defekten ACPI-Timer handeln. Die einfachste Lösung besteht darin, den ACPI-Timer in /boot/loader.conf zu deaktivieren:

debug.acpi.disabled="timer"

Es ist aber auch durchaus möglich, dass das BIOS die TSC-Uhr ändert, um beispielsweise den CPU-Takt zu während des Batteriebetrieb zu ändern, oder im Stromsparmodus; leider bemerkt FreeBSD diese Änderungen nicht und daher scheint die Uhr falsch zu gehen.

In diesem Beispiel ist die Uhr i8254 ebenfalls verfügbar; um sie auszuwählen, muss ihr Name in die sysctl(3)-Variable kern.timecounter.hardware geschrieben werden.

# sysctl kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

Die Uhrzeit des Rechners sollte nun genauer funktionieren.

Damit diese Änderung automatisch beim Start des Systems durchgeführt wird, müssen Sie die folgende Zeile in /etc/sysctl.conf eintragen:

kern.timecounter.hardware=i8254

Ein Prozess wollte Speicher auf der Platte auslagern, und dieser Vorgang konnte nicht innerhalb von 20 Sekunden durchgeführt werden. Mögliche Gründe sind defekte Blöcke auf der Platte, falsche oder fehlerhafte Verkabelung sowie Probleme mit anderen Komponenten, die am Zugriff auf die Festplatte beteiligt sind. Wenn die Festplatte selbst fehlerhaft ist, sollten Sie entsprechende Meldungen in /var/log/messages und der Ausgabe von dmesg finden. Andernfalls sollten Sie die Kabel und Verbindungen überprüfen.

Der FreeBSD-Kernel benutzt eine Reihe von Ressource-Locks, um den Zugriff auf Ressourcen zu regeln. Wenn verschiedene Kernel-Threads versuchen mehrere Ressource-Locks zu bekommen, besteht immer die Gefahr eines Deadlocks. Hierbei haben zwei Threads einen der Resource-Locks erhalten und blockieren sich nun gegenseitig, weil sie darauf warten, dass der jeweils andere Thread den Resource-Lock wieder freigibt. Diese Art von Locking-Problem kann vermieden werden, indem alle Threads die Locks in der gleichen Reihenfolge erhalten.

In FreeBSD-CURRENT (nicht in STABLE- oder RELEASE-Zweigen) befindet sich das Diagnose-System witness(4), das potentielle Deadlocks in verschiedenen Teilen des Kernels zur Laufzeit erkennt. Das witness(4)-System versucht die Probleme zu erkennen und gibt die Meldung lock order reversal (auch bekannt als LOR) auf der Konsole aus.

Weil witness(4) sehr konservativ vorgeht, ist es ist möglich, ein False Positive (Fehlalarm) zu erhalten. Eine Meldung bedeutet nicht zwangsläufig, dass das System einen Deadlock hat; Stattdessen sollte es als Warnung verstanden werden, dass hier ein Deadlock passiert sein könnte.

Diese Meldung erscheint, wenn eine Funktion, die sich im Ruhemodus befindet, aufgerufen wird, während ein Mutex oder eine andere (nicht in den Ruhemodus versetzbare) Sperre aktiv war.

Der Grund dafür ist, dass ein Mutex nicht für längere Zeitspannen aktiv sein soll, sondern nur für die Synchronisation von Gerätetreibern mit dem Rest des Kernels während eines Interrupts. Unter FreeBSD dürfen Interrupts nicht in den Ruhemodus versetzt werden. Daher ist es von entscheidender Bedeutung, dass während des Bestehens eines Mutex kein Kernelsubsystem für einen längeren Zeitraum blockiert ist.

Um solche Fehler abzufangen, können Sicherungen (Assertions) in den Kernel eingebaut werden, die danach mit dem witness(4)-Subsystem interagieren. Dadurch wird (in Abhängigkeit der Systemkonfiguration) eine Warnung oder eine Fehlermeldung ausgegeben, falls der Aufruf einer Funktion während des Bestehens eines Mutex zu einer Blockierung führen kann.

Zusammenfassend kann man sagen, dass diese Warnungen in der Regel zwar nicht bedrohlich sind. Unter bestimmten Umständen kann es aber dennoch zu unerwünschten Nebenwirkungen, angefangen von einer Erhöhung der Reaktionszeit bis hin zu einem kompletten Einfrieren des Systems kommen.

Weitere Informationen zum Locking unter FreeBSD finden Sie in locking(9).

Dieser Fehler bedeutet nicht, dass touch(1) nicht auf dem System vorhanden ist. Vielmehr sind Dateien die Ursache, deren Erzeugungsdatum in der Zukunft liegt. Wenn die CMOS-Uhr auf die lokale Zeit eingestellt ist, müssen Sie adjkerntz -i verwenden, um die Kerneluhr anzupassen, wenn Sie in den Single-User-Modus booten.

Informationen zu auf FreeBSD portierten Anwendungen finden Sie auf der Ports-Seite. Die Liste enthält circa 24.000 Pakete und es werden ständig mehr. Sie sollten diese Liste daher im Auge behalten, oder die FreeBSD announcements Mailingliste abonnieren und regelmäßig auf neue Einträge prüfen.

Die meisten Ports sollten auf allen unterstützten FreeBSD Versionen lauffähig sein. Nicht funktionierende Ports sind als solche gekennzeichnet. Jedes mal, wenn ein FreeBSD Release erstellt wird, wird ein Snapshot der Ports-Sammlung in ports/ mitgeliefert.

FreeBSD unterstützt für die Installation komprimierte Binärpakete und Ports. Benutzen Sie pkg(7) um die Installation von Paketen zu steuern.

Die folgenden Methoden können verwendet werden:

Ja. Lesen Sie http://www.FreeBSD.org/java/ für weitere Informationen.

Wenn Sie eine FreeBSD-Version benutzen, die deutlich älter als das aktuelle -CURRENT oder -STABLE ist, könnte es sein, dass Sie zunächst die Ports-Sammlung aktualisieren müssen. Lesen Sie dazu Benutzen der Ports-Sammlung. Ist die Ports-Sammlung aktuell, könnte es sein, dass jemand eine Änderung am Port durchgeführt hat, die für -CURRENT funktioniert, den Port für -STABLE aber unbrauchbar gemacht hat. Bitte senden Sie einen Fehlerbericht. Von der Ports-Sammlung wird nämlich erwartet, dass sie sowohl auf -CURRENT als auch auf -STABLE funktioniert.

Stellen Sie zuerst sicher, dass die Ports-Sammlung aktuell ist. Fehler, die einen Bau von INDEX aus einer aktuellen Ports-Sammlung verhindern, sind sofort sichtbar und werden daher fast immer umgehend behoben.

Es gibt seltene Fälle, in denen INDEX nicht gebaut werden kann, wenn bestimmte WITH_* oder WITHOUT_* Variablen in make.conf gesetzt sind. Wenn Sie dieses Problem haben, sollten Sie diese make-Variablen deaktivieren und INDEX erneut bauen, bevor Sie das Problem an die FreeBSD Ports Mailingliste melden.

FreeBSD enthält zwar kein Programm, das die installierten Ports aktualisiert, allerdings existieren diverse Programme, die diesen Prozess etwas vereinfachen. Weiterhin können Sie zusätzliche Programme installieren, die Sie dabei unterstützen. Lesen Sie das Kapitel Benutzen der Ports-Sammlung im FreeBSD Handbuch.

Ja! Obwohl ein aktuelles System mit Software für eine ältere Version funktionieren wird, werden Sie mit zufälligen Abstürzen und nicht funktionierenden Ports zurückbleiben, sobald Sie anfangen, andere Ports zu installieren oder diejenigen, die Sie bereits haben, aktualisieren möchten.

Wenn das System aktualisiert wird, werden verschiedene Shared-Libraries, ladbare Module und andere Systembestandteile durch neuere Versionen ersetzt. Anwendungen, die gegen die älteren Versionen gelinkt sind, werden nicht starten oder in anderen Fällen nicht korrekt funktionieren.

Für weitere Informationen lesen Sie den Abschnitt FreeBSD-Update im FreeBSD Handbuch.

Generell nicht. Die FreeBSD-Entwickler tun ihr möglichstes, um die Binärkompatibilität über alle Veröffentlichungen mit der gleichen Hauptversionsnummer zu garantieren. Ausnahmen werden in den Release Notes dokumentiert und die darin enthaltenen Hinweise sollten befolgt werden.

Viele Leute müssen Shell-Programme schreiben, die auf vielen verschiedenen Systemen nutzbar sein müssen. Aus diesem Grund enthält der POSIX®-Standard eine sehr detaillierte Definition der Shell und der Hilfsprogramme. Die meisten Programme werden für die Bourne Shell (sh(1)) geschrieben; außerdem nutzen mehrere wichtige Schnittstellen (make(1), system(3), popen(3) und höhere Programmiersprachen wie Perl und Tcl) die Bourne Shell, um Befehle auszuführen. Da die Bourne Shell an so vielen Stellen und so häufig genutzt wird, muss sie die folgenden Anforderungen erfüllen: Schneller Start, ein klar definiertes Verhalten und ein geringer Speicherverbrauch.

Wir haben bei der vorliegenden Implementierung versucht, möglichst viele dieser Anforderungen zu erfüllen. Um /bin/sh nicht zu groß werden zu lassen, haben wir viele der Annehmlichkeiten der anderen Shells weggelassen. Aus diesem Grund gibt stehen die luxuriöseren Shells wie bash, scsh, tcsh(1) und zsh zur Verfügung. Vergleichen Sie den Speicherverbrauch der verschiedenen Shells, indem Sie ps -u aufrufen und sich die Angaben in den Spalten „VSZ“ und „RSS“ ansehen.

Installieren Sie zuerst den Port audio/timidity++. Danach müssen Sie manuell die GUS-Patche von Eric A. Welsh von http://alleg.sourceforge.net/digmid.html. installieren. Wenn TiMidity++ richtig installiert wurde, können Sie mit dem folgenden Kommando MIDI-Dateien in das WAV-Format konvertieren:

% timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid

Die WAV-Dateien können dann in andere Formate konvertiert werden oder (wie im FreeBSD Handbuch. beschrieben) auf Audio-CDs gebrannt werden.

Überhaupt nicht! Lesen Sie den Abschnitt zur Kernelkonfiguration im Handbuch.

FreeBSDs GENERIC-Kernels werden im Debug-Modus erstellt. Ein Debug-Kernel enthält viele zusätzliche Informationen für die Fehlersuche. In FreeBSD 11.0 und neueren Versionen werden diese Debug-Dateien in /usr/lib/debug/boot/kernel gespeichert. Ältere Versionen von FreeBSD speichern diese Dateien im selben Verzeichnis wie den Kernel, /boot/kernel. Bitte beachten Sie, dass die Verwendung eines Debug-Kernels die Performance des Systems nicht oder nur minimal reduziert; außerdem ist es für den Fall einer system panic sehr praktisch, einen Debug-Kernel zur Hand zu haben.

Wenn Ihnen allerdings der Plattenplatz ausgeht, gibt es verschiedene Möglichkeiten die Größe von /boot/kernel/ und /usr/lib/debug/ zu reduzieren.

Um die Kernel-Symbole nicht zu installieren, nehmen Sie folgende Zeile in /etc/src.conf auf:

WITHOUT_KERNEL_SYMBOLS=yes

Weitere Informationen finden Sie in src.conf(5).

Wenn Sie überhaupt keine Debug-Dateien erzeugen möchten, müssen Sie folgendes sicherstellen:

Jede der oben genannten Einstellungen bewirkt, dass der Kernel im Debug-Modus erstellt wird.

Um nur die angegebenen Module zu erstellen und zu installieren, nehmen Sie diese in /etc/make.conf auf:

MODULES_OVERRIDE= accf_http ipfw

Ersetzen Sie accf_httpd ipfw durch die gewünschten Module. Nur aufgelistete Module werden gebaut. Dies reduziert die Größe des Kernel-Verzeichnisses sowie die benötigte Zeit, um den Kernel zu übersetzen.

Um die Größe des Kernels weiter zu reduzieren, können nicht benötigte Geräte aus dem Kernel entfernt werden. F: 7.1 enthält weitere Informationen.

Um eine dieser Optionen in Kraft zu setzen, folgen Sie den Anweisungen zum Erstellen und Installieren eines neuen Kernels.

Der FreeBSD 11 amd64 Kernel (/boot/kernel/kernel) ist circa 25 MB groß.

Es gibt eine Reihe von möglichen Ursachen für dieses Problem:

Der Name des aktuell verwendeten Schedulers steht in der sysctl-Variablen kern.sched.name:

% sysctl kern.sched.name
kern.sched.name: ULE

kern.sched.quantum ist die maximale Anzahl Ticks, die ein Prozess im 4BSD-Scheduler ununterbrochen laufen kann.

Lesen Sie den Abschnitt Hinzufügen von Laufwerken im Handbuch.

Die beste Methode ist, das Betriebssystem auf der neuen Platte zu installieren und danach die Daten zu verschieben. Diese Methode ist sehr empfehlenswert, wenn Sie -STABLE über ein Release hinaus genutzt haben oder ein Release aktualisiert haben. Sie können boot0cfg(8) auf beiden Platten installieren und die beiden Versionen so lange parallel betreiben, bis Ihnen die neue Konfiguration gefällt. Wenn Sie dies tun wollen, können Sie im übernächsten Absatz erfahren, wie sie Ihre Daten verschieben können.

Alternativ können Sie die neue Platte entweder mit sade(8) oder gpart(8) partitionieren und labeln. Wenn die Festplatten mit MBR formatiert sind, kann booteasy auf beiden Festplatten mit boot0cfg(8) installiert werden, damit der Rechner nach dem Kopieren das alte oder neue System booten kann.

Sobald die neue Festplatte eingerichtet ist, können die Daten nicht einfach kopiert werden. Verwenden Sie stattdessen Werkzeuge, die Gerätedateien und Dateiattribute verstehen, z. B. dump(8). Obwohl empfohlen wird, die Daten im Einzelbenutzermodus zu verschieben, ist dies nicht zwingend erforderlich.

Wenn die Festplatten mit UFS formatiert sind, verwenden Sie ausschließlich dump(8) und restore(8), um das Root-Dateisystem zu verschieben. Diese Befehle sollten auch beim Verschieben einer einzelnen Partition in eine andere, leere Partition verwendet werden. Um die Daten einer UFS-Partition auf eine andere Partition zu verschieben, müssen Sie die folgenden Schritte ausführen:

Wenn Sie zum Beispiel das Root-Dateisystem auf /dev/ad1s1a verschieben wollen und diese derzeit auf /mnt gemountet ist, geben Sie folgendes ein:

# newfs /dev/ada1s1a
# mount /dev/ada1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -

Wenn Sie Partitionen mit dump umorganisieren wollen, bedeutet dies etwas mehr Arbeit. Wenn Sie eine Partition wie /var in die übergeordnete Partition verschieben wollen, müssen Sie zunächst eine neue Partition erzeugen, die die beiden alten Partitionen aufnehmen kann. Der zweite Schritt ist, wie oben beschrieben die übergeordnete Partition in die neue Partition zu verschieben. Im dritten und letzten Schritt verschieben Sie dann die untergeordnete Partition in das leere Verzeichnis, das im zweiten Schritt entstanden ist:

# newfs /dev/ada1s1a
# mount /dev/ada1s1a /mnt
# cd /mnt
# dump 0af - / | restore rf -
# cd var
# dump 0af - /var | restore rf -

Wenn Sie ein Verzeichnis aus einer Partition herauslösen wollen, also z.B. /var auf eine eigene Partition verlegen wollen, dann müssen Sie zunächst beide Partitionen anlegen. Danach müssen Sie die untergeordnete Partition im passenden Verzeichnis unterhalb des temporären mount points mounten und zum Abschluß die alte Partition verschieben:

# newfs /dev/ada1s1a
# newfs /dev/ada1s1d
# mount /dev/ada1s1a /mnt
# mkdir /mnt/var
# mount /dev/ada1s1d /mnt/var
# cd /mnt
# dump 0af - / | restore rf -

Zum Verschieben von Benutzerdaten stehen Werkzeuge wie cpio(1) und pax(1) zur Verfügung. Allerdings sind diese Programme dafür bekannt, dass sie die erweiterten Dateiattribute nicht verstehen, daher sollten Sie bei ihrem Einsatz aufpassen.

Die schnelle Antwort: Sie können Soft Updates bedenkenlos auf alle Partitionen benutzen.

Die ausführliche Antwort: Soft Updates besitzen zwei Eigenschaften, die auf bestimmten Partitionen unerwünscht sein können. Zum einen kann es bei einem Absturz des System auf einer Partition mit Soft Updates zum Datenverlust kommen. Die Partition ist zwar noch brauchbar, aber die Daten sind verloren. Weiterhin kann es durch Soft Updates zu einem zeitweisen Mangel an Plattenplatz kommen.

Bei der Benutzung von Soft Updates kann es bis zu dreißig Sekunden dauern, bis der Kernel Änderungen auf das physikalische Speichermedium schreibt. Wenn Sie eine große Datei löschen, ist diese Datei noch auf der Platte vorhanden, bis der Kernel die Löschoperation tatsächlich durchführt. Das kann zu einem sehr einfachen Problem führen: Stellen Sie sich vor, Sie löschen eine große Datei und legen gleich darauf eine andere große Datei an. Da die erste Datei noch nicht wirklich gelöscht wurde, ist eventuell nicht genug Platz für die zweite große Datei. Sie erhalten die Fehlermeldung, dass nicht genug freier Platz vorhanden ist, obwohl Sie gerade eben ausreichend Platz freigegeben haben. Ein paar Sekunden später funktioniert die Erstellung der Datei wie erwartet.

Wenn der Kernel ein Datenpaket annimmt und das System abstürzt, bevor die Daten auf die Platte geschrieben wurden, kann es zum Verlust oder zur Zerstörung von Daten kommen. Dieses Risiko ist nur sehr gering und normalerweise überschaubar.

Diese beiden Probleme betreffen alle Partitionen, die Soft Updates verwenden. Was bedeutet das für die Root-Partition?

Die wichtigen Daten auf der Root-Partition ändern sich nur sehr selten. Wenn das System in den 30 Sekunden nach einer solchen Änderung abstürzt, ist es möglich, das Daten verloren gehen. Dieses Risiko ist in den meisten Fällen unerheblich, aber es ist vorhanden. Wenn das zu viel Risiko ist, dann sollten Sie Soft Updates nicht auf der Root-Partition einsetzen.

/ war schon immer eine der kleinsten Partitionen. Wenn /tmp direkt auf / liegt, kann es zeitweise zu den oben beschriebenen Platzproblemen kommen. Um das Problem zu lösen, sollten sie einen symbolischen Link von /tmp nach /var/tmp legen.

Zudem sei noch angemerkt, dass dump(8) nicht im Live-Modus (-L) auf einem Dateisystem mit Journaled Soft Updates (SU+J) funktioniert.

FreeBSD unterstützt verschiedene fremde Dateisysteme:

FreeBSD unterstützt auch das Netzwerk-Dateisystem NFS. Die FreeBSD Ports-Sammlung bietet zudem einige FUSE-Anwendungen um weitere Dateisysteme zu unterstützen.

Die erweiterten DOS-Partitionen befinden sich hinter allen primären Partitionen. Wenn sich zum Beispiel eine Partition E als sekundäre DOS-Partition auf einem zweiten SCSI-Laufwerk befindet, wird eine Gerätedatei für Slice 5 in /dev erstellt. Um diese zu mounten:

# mount -t msdosfs /dev/da1s5 /dos/e

Ja. gbde(8) und geli(8). Lesen Sie dazu auch den Abschnitt Partitionen verschlüsseln im FreeBSD Handbuch.

Um FreeBSD mit GRUB zu booten, müssen Sie die folgenden Zeilen in Abhängigkeit der verwendeten Linux®-Distribution in /boot/grub/menu.lst oder /boot/grub/grub.conf aufnehmen.

title FreeBSD 9.1
	root (hd0,a)
	kernel /boot/loader

Dabei steht hd0,a für die Root-Partition der ersten Festplatte. Benötigen Sie auch die Slice-Nummer, so verwenden Sie einen Eintrag der Form hd0,2,a. In der Voreinstellung ist die Angabe der Slice-Nummer aber nicht nötig, da GRUB automatisch das erste Slice (das die Bezeichnung a hat) nutzt.

Installieren Sie LILO am Anfang der Linux®-Bootpartition, anstatt im Master Boot Record. Sie können LILO dann von BootEasy aus booten.

Wenn Sie Windows® und Linux® benutzen, wird dies ohnehin empfohlen, um es einfacher zu machen, Linux® wieder zu booten, wenn es nötig werden sollte, dass Sie Windows® neu installieren.

Ohne den Boot-Manager neu zu schreiben, gar nicht. Allerdings gibt es in der Kategorie sysutils der Ports-Sammlung diverse Boot-Manager, die diese Funktionalität bieten.

Wenn auf dem Laufwerk bereits ein Dateisystem existiert, können Sie folgendes Kommando benutzen:

# mount -t msdosfs /dev/da0s1 /mnt

Wenn das Laufwerk nur mit FreeBSD-Systemen verwendet wird, partitionieren Sie es mit UFS oder ZFS. Dies bietet Unterstützung für lange Dateinamen, eine verbesserte Leistung und Stabilität. Wenn das Laufwerk von anderen Betriebssystemen verwendet wird, ist bspw. msdosfs die bessere Wahl.

# dd if=/dev/zero of=/dev/da0 count=2
# gpart create -s GPT /dev/da0
# gpart add -t freebsd-ufs /dev/da0

Anschließend erstellen Sie ein neues Dateisystem:

# newfs /dev/da0p1

und mounten es:

# mount /dev/da0s1 /mnt

Es ist eine gute Idee einen Eintrag in /etc/fstab hinzuzufügen (siehe fstab(5)), sodass Sie in Zukunft einfach nur mount /mnt eingeben müssen:

/dev/da0p1 /mnt ufs rw,noauto 0 0

Sie müssen mount(8) mitteilen, was für ein Gerät Sie mounten wollen. Genauere Informationen dazu finden Sie im Abschnitt Einhängen von Daten-CDs des Handbuchs.

Das bedeutet im allgemeinen, dass sich keine CD im Laufwerk befindet, oder dass das Laufwerk auf dem Bus nicht sichtbar ist. Dieses Problem wird im Kapitel Einhängen von Daten-CDs des Handbuchs ausführlich diskutiert.

Wahrscheinlich werden auf der CD-ROM die „Joliet“ Erweiterungen für die Speicherung von Datei- und Verzeichnisnamen benutzt. Werfen Sie einen Blick in das Kapitel Einhängen von Daten-CDs im Handbuch.

Sie haben wahrscheinlich eine Datei direkt auf CD geschrieben, statt ein ISO 9660-Dateisystem erzeugt zu haben. Werfen Sie einen Blick in das Kapitel Einhängen von Daten-CDs im Handbuch.

Diese Information finden Sie im Abschnitt Daten auf ein ISO-Dateisystem schreiben des Handbuchs. Weitere Informationen über die Arbeit mit CD-ROMs finden Sie im Abschnitt Erstellen und Verwenden von CDs im Kapitel Speichermedien des Handbuchs.

Wenn Sie versuchen eine Audio-CD zu mounten, erhalten Sie die Meldung cd9660: /dev/acd0c: Invalid argument. Der Grund dafür ist, dass mount nur mit Dateisystemen arbeitet. Audio-CDs haben kein Dateisystem, sondern nur Daten. Wenn Sie eine Audio-CD auslesen wollen, brauchen Sie ein entsprechendes Programm wie z.B. den Port oder das Paket audio/xmcd.

Standardmäßig benutzt mount(8) den letzten (aktuellsten) Daten-Track der CD. Wenn Sie eine ältere Session benutzen wollen, müssen Sie diese mit der Option -s definieren. Weitere Informationen und Beispiele finden Sie in mount_cd9660(8).

Setzen Sie als root die sysctl-Variable vfs.usermount auf 1:

# sysctl vfs.usermount=1

Fügen Sie den Eintrag vfs.usermount=1 in /etc/sysctl.conf hinzu, damit die Einstellung beim nächsten Systemstart erneut gesetzt wird.

Benutzer dürfen nur Geräte mounten, auf die sie Leserechte haben. Um es Benutzern zu gestatten Geräte zu mounten, müssen die entsprechenden Berechtigungen in /etc/sysctl.conf gesetzt werden.

Wenn Sie zum Beispiel den Benutzern den Zugriff auf das erste USB-Laufwerk zu erlauben wollen:

# Allow all users to mount a USB drive.
	    own       /dev/da0       root:operator
	    perm      /dev/da0       0666

Alle Benutzer können nun Geräte, die sie lesen können, in ein Verzeichnis einbinden, das sie besitzen:

% mkdir ~/my-mount-point
% mount -t msdosfs /dev/da0 ~/my-mount-point

Das Aushängen eines Gerätes ist einfach:

% umount ~/my-mount-point

Die Aktivierung von vfs.usermount hat jedoch negative Auswirkungen auf Sicherheitsaspekte. Ein besserer Weg, um auf MS-DOS®-formatierte Datenträger zuzugreifen, ist die Benutzung des Pakets oder Ports emulators/mtools.

Der Grund liegt in der unterschiedlichen Funktionsweise der beiden Befehle. du durchläuft einen Dateibaum, ermittelt die Größe jeder einzelnen Datei, und gibt die Summe aus. df fragt lediglich das Dateisystem wie viel Platz noch frei ist. Das scheint zwar auf den ersten Blick sehr ähnlich zu sein; allerdings wird sich ein leeres Verzeichnis auf die Ausgabe von df auswirken, während es auf das Ergebnis von du keinen Einfluss hat.

Wenn Sie eine Datei löschen, während sie von einem Programm genutzt wird, wird diese Datei erst gelöscht, wenn sie vom Programm freigegeben wird. Allerdings wird die Datei sofort aus dem Verzeichnis entfernt. Sie können dieses Verhalten sehr einfach nachvollziehen. Dazu brauchen Sie nur eine Datei, die groß genug ist, um die Ausgabe von du und df zu beeinflussen. Bei der Größe aktueller Platten muss diese Datei schon sehr groß sein! Wenn Sie diese Datei löschen, während Sie sie sich in more anzeigen lassen, hat more kein Problem. Der Eintrag für die Datei wird lediglich aus dem Verzeichnis entfernt, damit kein anderes Programm mehr darauf zugreifen kann. Laut du ist die Datei verschwunden – es hat das Verzeichnis untersucht und die Datei nicht gefunden. Laut df ist die Datei aber vorhanden, da sie im Dateisystem immer noch Platz belegt. Sobald Sie more beenden, werden die Ergebnisse von du und df wieder übereinstimmen.

Die oben beschriebene Situation tritt sehr häufig auf Webservern auf. Viele Anwender installieren einen FreeBSD Webserver und vergessen die Rotation der Logdateien, bis irgendwann die Partition /var überläuft. Der Administrator löscht die Datei, aber das System beschwert sich immer noch über fehlenden Plattenplatz. Die Datei wird erst freigegeben, wenn der Webserver beendet und neu gestartet wird; dadurch kann das System den Plattenplatz freigeben. Um dies zu verhindern, sollten Sie newsyslog(8) einsetzen.

Bitte beachten Sie, dass die Freigabe des Plattenplatzes durch Soft Updates um bis zu 30 Sekunden verzögert werden kann.

Der Abschnitt Hinzufügen von Swap-Bereichen im Handbuch enthält hierzu eine Schritt-für-Schritt Anleitung.

Festplattenhersteller definieren ein Gigabyte als eine Milliarde Bytes, für FreeBSD ist ein Gigabyte hingegen 1.073.741.824 Bytes groß. Aus diesem Grund wird für eine Platte, die laut Herstellerangaben 80 GB groß ist, während des Bootvorgangs eine Größe von 76.319 MB angezeigt.

Beachten Sie auch, dass FreeBSD (in der Voreinstellung) 8 % des Plattenplatzes für sich reserviert.

Ein Teil jeder UFS Partition (8% in der Voreinstellung) ist für das Betriebssystem und den Benutzer root reserviert. df(1) rechnet diesen Teil bei der Ausgabe der Spalte Capacity nicht ein, so dass dort Werte über 100% angezeigt werden können. Die Anzahl der Blöcke in der Spalte Blocks ist ebenfalls um 8% größer als die Summe der benutzten und verfügbaren Blöcke (die Spalten Used und Avail).

Wie viel Platz reserviert wird, können Sie mit der Option -m von tunefs(8) einstellen.

FreeBSD 10.1 und ältere Versionen führen zu Beginn des Bootens einen Speichertest aus. Wenn das System wenig Arbeitsspeicher hat, dauert dieser Test nur wenige Sekunden. Systeme mit zehn oder hunderten von Gigabytes Arbeitsspeicher benötigen mehrere Minuten. Durch Hinzufügen von hw.memtest.tests=0 in /boot/loader.conf können Sie diesen Test deaktivieren.

Für weitere Informationen, lesen Sie loader.conf(5).

Für eine komfortable Nutzung werden mindestens 4 GB RAM empfohlen. Dies ist jedoch auch von der individuellen Auslastung abhängig.

Das ZIL (ZFS intent log) ist ein Schreib-Cache, der verwendet wird, um posix verpflichtende Schreib-Semantiken über Abstürze hinweg zu implementieren. Normalerweise werden Schreiboperationen in Transaktionsgruppen zusammengefasst und auf den Datenträger geschrieben („Transaction Group Commit“). Systemaufrufe wie fsync(2) benötigen jedoch eine Bestätigung, dass die Daten auf den Datenträger geschrieben wurden, bevor sie weitermachen. Das ZIL wird für Schreibvorgänge verwendet, welche zwar als gespeichert bestätigt, jedoch noch nicht als Teil einer Transaktion auf die Festplatte geschrieben wurden. Im Fall eines Systemabsturzes wird der letzte gültige Zeitstempel ermittelt und die fehlenden Daten werden aus dem ZIL zusammengesetzt.

In der Voreinstellung speichert ZFS das ZIL zusammen mit den anderen Daten innerhalb des Pools. Wenn eine Anwendung viele Schreiboperationen erzeugt, kann es die Gesamtleistung verbessern, wenn das ZIL auf einem separaten Gerät gespeichert wird, welches eine hohe Leistung bei synchronen, sequentiellen Schreibvorgängen erzielt. Bei geringerer Last bieten SSDs kaum eine Verbesserung.

Der L2ARC ist ein Lese-Cache, der auf einem schnellen Gerät, bspw. einer SSD, gespeichert wird. Die Daten in diesem Cache gehen bei einem Neustart verloren. Beachten Sie, dass primär RAM als Cache verwendet wird, und dass der L2ARC nur dann benötigt wird, wenn nicht genügend RAM verfügbar ist.

L2ARC benötigt Platz im ARC, um es zu indizieren. Ein Arbeitsbereich, der perfekt in den ARC passt, passt nicht mehr, wenn ein L2ARC verwendet wird, da ein Teil des ARC den L2ARC-Index beinhaltet und einen Teil des Arbeitsbereichs in den L2ARC schreibt, der langsamer als der RAM ist.

Im Allgemeinen nicht.

Deduplizierung benötigt sehr viel RAM und kann die Lese- und Schreibzugriffe auf die Festplatte verringern. Wenn Sie keine Daten speichern, die sehr stark dupliziert sind, bspw. Abbilder von virtuellen Maschinen oder Backups von Benutzern, dann ist es eher wahrscheinlich, dass Deplizierung mehr Schaden als Nutzen bringt. Zudem ist es nicht möglich, den Status der Deduplizierung umzukehren. Wenn Daten bei aktivierter Deduplizierung geschrieben werden, werden diese nach einer Deaktivierung der Deduplizierung erst wieder repliziert, nachdem die nächste Änderung stattfindet.

Deduplizierung kann auch zu einigen unerwarteten Situationen führen. Insbesondere kann das Löschen von Dateien viel langsamer sein.

Die könnte passieren, wenn der Pool zu 100% belegt ist. ZFS benötigt Platz auf der Festplatte, um Transaktionsmetadaten zu speichern. Um den Pool wieder benutzbar zu machen, kürzen Sie einfach die zu löschende Datei:

% truncate -s 0 unimportant-file

Dies funktioniert, weil keine neue Transaktion gestartet wird, stattdessen werden neue Ersatzblöcke erzeugt.

ZFS TRIM-Unterstützung wurde in FreeBSD 10-CURRENT mit Revision r240868 hinzugefügt. In die FreeBSD-STABLE Zweige wurde die Unterstützung mit r252162 und 251419 hinzugefügt.

ZFS TRIM ist in der Voreinstellung aktiviert, kann aber mit dem folgenden Eintrag in /etc/sysctl.conf deaktiviert werden:

vfs.zfs.trim_disable=1

/etc/defaults/rc.conf (siehe rc.conf(5)) ist die primäre Konfigurationsdatei. Die Startskripten des Systems, wie /etc/rc und /etc/rc.d (siehe rc(8)) inkludieren diese Datei. Ändern Sie diese Datei nicht! Wenn Sie den Wert einer der in /etc/defaults/rc.conf gesetzten Variablen ändern wollen, kopieren Sie die entsprechende Zeile nach /etc/rc.conf und ändern die Zeile dort.

Wenn Sie zum Beispiel den mitgelieferten DNS-Server named(8) aktivieren wollen, können Sie das folgende Kommando eingeben:

# echo 'named_enable="YES"' >> /etc/rc.conf

Wenn Sie lokale Server starten wollen, müssen Sie die Shellskripten im Verzeichnis /usr/local/etc/rc.d/ ablegen. Die Dateien sollten als ausführbar markiert sein und die Dateiberechtigungen 555 besitzen.

Benutzen Sie den Befehl adduser(8) und für kompliziertere Fälle den Befehl pw(8).

Um einen Benutzer wieder zu löschen, können Sie den Befehl rmuser(8) benutzen. Sie können, wenn nötig, auch pw(8) benutzen.

Dies geschieht in der Regel, wenn sie die crontab des Systems verändern. Das ist aber nicht der richtige Weg, weil die crontab des Systems ein anderes Format hat, als die crontabs der Benutzer. Die crontab des Systems enthält ein zusätzliches Feld für den Benutzer, welcher das Kommando ausführt. cron(8) geht davon aus, das der Benutzername das auszuführenden Kommando ist. Da ein solches Kommando jedoch nicht existiert, wird diese Meldung angezeigt.

Geben Sie das folgende ein um die zusätzliche, fehlerhafte crontab zu löschen:

# crontab -r

Das ist ein Sicherheitsmerkmal Wenn Sie mit su zu root oder jedem anderen Account mit Super-User-Privilegien wechseln wollen, müssen Sie Mitglied der Gruppe wheel sein. Wenn es dieses Merkmal nicht gäbe, könnte jeder, der einen Account auf dem System hat und zufällig das Passwort für root erfährt, mit Super-User-Rechten auf das System zugreifen.

Um einem Benutzer zu erlauben, mit su root zu werden, müssen Sie ihn mit pw zur Gruppe wheel hinzufügen:

# pw groupmod wheel -m lisa

Das obige Beispiel würde den Benutzer lisa zur Gruppe wheel hinzufügen.

Starten Sie das System mittels boot -s an der Loader-Eingabeaufforderung neu, um in den Single-User-Modus zu gelangen. Wenn Sie aufgefordert werden, den Pfadnamen der Shell einzugeben, drücken Sie einfach Enter. Geben Sie danach mount -urw / ein, um das Root-Dateisystem im Schreib/Lese-Modus zu mounten. Sie werden wahrscheinlich auch mount -a -t ufs ausführen müssen, um das Dateisystem mit Ihrem Lieblingseditor zu mounten. Wenn Ihr Lieblingseditor auf einem Netzwerklaufwerk liegt, müssen Sie entweder das Netzwerk von Hand konfigurieren oder einen Editor benutzen, der auf einem lokalen Laufwerk vorhanden ist, z.B. ed(1).

Wenn Sie einen bildschirmorientierten Editor wie zum Beispiel vi(1) oder emacs(1) benutzen wollen, werden Sie auch den Befehl export TERM=xterm ausführen müssen, damit diese Editoren die richtigen Einstellungen aus der Datenbank termcap(5) übernehmen.

Sobald Sie diese Schritte ausgeführt haben, können Sie den Fehler in /etc/rc.conf ganz normal beheben. Die Fehlermeldungen, die unmittelbar nach den Startmeldungen des Kernels angezeigt wurden, sollten die Nummer der Zeile mit dem Fehler melden.

Lesen Sie zur Problembehandlung das Kapitel Drucken im Handbuch.

Informationen dazu finden Sie im Kapitel Lokalisierung des Handbuchs, insbesondere im Abschnitt Einrichten der Konsole.

Ja, FreeBSD unterstützt IPC im Stil von System V einschließlich gemeinsamen Speicher, Nachrichten und Semaphoren bereits mit dem GENERIC-Kernel. Wenn Sie einen angepassten Kernel verwenden, können Sie die für Unterstützung die Kernelmodule sysvshm.ko, sysvsem.ko und sysvmsg.ko laden. Alternativ können Sie die folgenden Zeilen in die Kernelkonfigurationsdatei aufnehmen:

options    SYSVSHM          # enable shared memory
options    SYSVSEM          # enable for semaphores
options    SYSVMSG          # enable for messaging

Danach kompilieren und installieren Sie den neuen Kernel.

Der Sendmail Server ist der voreingestellte Mail-Server unter FreeBSD. Sie können ihn aber problemlos durch einen anderen MTA aus der Ports-Sammlung ersetzen, z.B. mail/exim, mail/postfix, oder mail/qmail. Diskussionen über die Vor- und Nachteile der einzelnen MTAs finden Sie auf den Mailinglisten.

Keine Panik! Starten Sie das System neu und geben Sie boot -s an der Eingabeaufforderung Boot: ein, um in den Single-User-Modus zu gelangen. Bei der Frage, welche Shell benutzt werden soll, drücken Sie einfach Enter. Nun erscheint die Eingabeaufforderung #. Geben Sie mount -urw / ein, um das Root-Dateisystem für Lese- und Schreibzugriffe zu mounten und dann mount -a um alle Dateisysteme zu mounten. Mit passwd root können Sie das Passwort für root ändern und mit exit(1) können Sie mit dem Booten fortfahren.

Falls Sie syscons(4) (der Standard-Treiber für die Konsole) benutzen, fügen Sie folgende Zeile in die Kernelkonfigurationsdatei ein und bauen und installieren Sie einen neuen Kernel:

options SC_DISABLE_REBOOT

Alternativ kann die folgende sysctl(8)-Variable gesetzt werden, ohne dass Sie das System dazu neu starten oder einen angepassten Kernel erstellen müssen:

# sysctl hw.syscons.kbd_reboot=0

Benutzen Sie diesen perl(1)-Befehl:

% perl -i.bak -npe 's/\r\n/\n/g' file(s)

Wobei file(s) eine oder mehrere zu verarbeitende(n) Datei(en) ist/sind. Die Änderungen erfolgen in der Originaldatei, die zuvor mit der Erweiterung .bak gesichert wird.

Alternativ können Sie den Befehl tr(1) benutzen:

% tr -d '\r' < dos-text-file > unix-file

dos-text-file ist die Datei, die den Text im DOS-Format enthält und unix-file wird die konvertierte Ausgabe enthalten. Diese Möglichkeit könnte etwas schneller sein, als die Benutzung von perl.

Die Verwendung von converters/dosunix aus der Ports-Sammlung stellt eine weitere Möglichkeit dar, DOS-Textdateien neu zu formatieren. Konsultieren Sie die Dokumentation für weitere Informationen.

Gehen Sie in den Single-User-Modus und dann zurück in den Multi-User-Modus:

# shutdown now
# return
# exit

Kurze Antwort: Das ist nur ein anderer Name. RC ist die Abkürzung für „Release Candidate“. Es bedeutet, dass ein neues Release bevorsteht. PRERELEASE bedeutet bei FreeBSD, dass der Quellcode zur Vorbereitung auf ein Release „ingefroren“ wurde (in einigen Releases wurde -BETA anstelle von -PRERELEASE verwendet).

Ausführliche Antwort: Bei FreeBSD gibt es zwei Quellen für Releases. Die Major Releases wie 9.0-RELEASE werden aus dem aktuellen Stand des Hauptzweiges der Entwicklung (besser bekannt als -CURRENT) erzeugt. Minor Releases wie 6.3-RELEASE oder 5.2-RELEASE stammen aus dem aktiven -STABLE Zweig. Seit 4.3-RELEASE gibt es nun auch einen eigenen Zweig für jede Release, der für die Leute gedacht ist, die ein sehr konservativ weiterentwickeltes System benötigen (normalerweise nur Sicherheitsaktualisierungen).

Bevor in einem Zweig ein Release erfolgt, muss in diesem Zweig ein bestimmter Prozess ablaufen. Ein Teil dieses Prozesses ist der „code freeze“, der Stop der Weiterentwicklung. Sobald dieser Schritt erfolgt ist, wird der Name des Zweiges geändert, um anzuzeigen, dass demnächst ein Release erfolgen wird. Wenn der Zweig zum Beispiel 6.2-STABLE genannt wurde, wird der Name in 6.3-PRERELEASE geändert, um dies zu verdeutlichen. Weiterhin ist das ein Zeichen, dass jetzt besonders intensiv getestet werden sollte. In dieser Phase können Fehler im Quellcode noch korrigiert werden. Wenn der Quellcode so weit „gereift“ ist, dass ein Release erstellt werden kann, wird der Name in 6.3-RC geändert, um genau dies anzuzeigen. In dieser Phase können nur noch extrem wichtige Korrekturen aufgenommen werden. Sobald das Release (in diesem Beispiel 6.3-RELEASE) erfolgt ist, wird der Zweig in 6.3-STABLE umbenannt.

Weitere Informationen über Versionsnummern und die verschiedenen Entwicklungszweige enthält der Artikel Release Engineering.

Kurze Antwort: die Sicherheitseinstellung (der securelevel) ist größer als 0. Sie müssen das System im Single-User-Modus starten, um den Kernel zu installieren.

Ausführliche Antwort: Wenn die Sicherheitseinstellung größer als 0 ist, erlaubt es FreeBSD nicht, die Systemeinstellungen zu ändern. Um den aktuellen Securelevel zu ermitteln, können Sie das folgende Kommando benutzen:

# sysctl kern.securelevel

Sie können die Sicherheitseinstellung im Mehrbenutzer-Modus nicht verringern. Sie müssen das System im Single-User-Modus starten, um den Kernel zu installieren oder den Securelevel in /etc/rc.conf zu ändern und anschließend das System neu starten. Lesen Sie Manualpage von init(8) für weitere Details zu securelevel. Zusätzliche Informationen zu /etc/rc.conf finden Sie in /etc/defaults/rc.conf und der Manualpage rc.conf(5).

Kurze Antwort: Die Sicherheitseinstellung (der securelevel) ist größer als 1. Sie müssen das System neu starten und die Systemzeit im Single-User-Modus verstellen.

Ausführliche Antwort: Wenn die Sicherheitseinstellung größer als 1 ist, erlaubt es FreeBSD nicht, die Systemzeit zu ändern. Um den aktuellen Securelevel zu ermitteln, können Sie das folgende Kommando benutzen:

# sysctl kern.securelevel

Sie können die Sicherheitseinstellung im Mehrbenutzer-Modus nicht verringern. Sie müssen das System im Single-User-Modus starten, um die Systemzeit oder den Securelevel in /etc/rc.conf zu ändern und anschließend das System neu starten. Lesen Sie Manualpage von init(8) für weitere Details zu securelevel. Zusätzliche Informationen zu /etc/rc.conf finden Sie in /etc/defaults/rc.conf und der Manualpage rc.conf(5).

Nein, das Programm hat kein Speicherleck und es verbraucht auch nicht 256 MB Speicher. rpc.statd projiziert nur einen übertrieben großen Speicherbereich in seinen eigenen Adressraum. Von einem rein technischen Standpunkt aus ist das nichts verwerfliches, allerdings verwirrt es Programme wie top(1) und ps(1).

rpc.statd(8) projiziert seine Statusdatei (die in /var liegt) in seinen Adressraum. Um die Probleme zu vermeiden, die bei einer Vergrößerung dieser Projektion entstehen könnten, wird gleich ein möglichst großer Speicherbereich benutzt. Dies kann man sehr schön im Quellcode sehen: Die Längenangabe beim Aufruf von mmap(2) ist 0x10000000, ein sechzehntel des Adressraums bei IA32, oder genau 256 MB.

Sie betreiben das System mit einer erhöhten Sicherheitsstufe. Senken Sie die Sicherheitsstufe und versuchen Sie es dann noch einmal. Weitere Informationen erhalten Sie im FAQ Eintrag über Sicherheitsstufen und in der Manualpage init(8).

vnlru schreibt vnodes auf Platte und gibt sie wieder frei, falls das System den Grenzwert kern.maxvnodes erreicht. Dieser Thread des Kernel tut meistens gar nichts und wird nur aktiv, wenn Sie extrem viel RAM haben und gleichzeitig auf viele zehntausende kleine Dateien zugreifen.

Seiten im Zustand Inactive werden oft auf Plattenspeicher geschrieben (sozusagen ein sync des VM-Systems). Wenn die CPU erkennen kann, das eine Seite unmodifiziert (clean) ist, kann auch eine Active-Seite auf den Plattenspeicher ausgeschrieben werden. In bestimmten Situationen ist es von Vorteil, wenn ein Block von VM-Seiten, unabhängig von seinem Zustand, ausgeschrieben werden kann. Die Inactive-Liste enthält wenig benutzte Seiten, die ausgeschrieben werden könnten. Seiten im Zustand Cached sind schon ausgeschrieben und stehen Prozessen für die Verwendung im alten oder in einem neuen Kontext zur Verfügung. Seiten im Zustand Cache sind nicht ausreichend geschützt und können während Unterbrechungen nicht benutzt werden.

Die eben beschriebene Behandlung von Speicherseiten kann durch weitere Zustände (wie das Busy-Flag) verändert werden.

Es gibt verschiedene Arten von „freiem Speicher“. Eine Art ist die Speichermenge, die sofort, ohne etwas auszulagern, zur Verfügung steht. Dies ist ungefähr die kumulierte Größe von Inactive und Free. Der gesamte VM-Bereich ist eine weitere Art des „freien Speichers“. Die Betrachtung ist komplex, hängt aber von der Größe des Swap-Bereichs und der Größe des Arbeitsspeichers ab. Es gibt weitere Definitionen für „freien Speicher“, die aber alle relativ nutzlos sind. Wichtig ist hingegen, dass wenig Seiten ausgelagert werden (paging) und der Swap-Bereich ausreichend groß ist.

Das Verzeichnis /var/empty wird von sshd(8) benötigt, wenn es mit „Privilege Separation“ ausgeführt wird. Das Verzeichnis /var/empty ist leer, gehört root und ist durch das Dateiattribut schg geschützt.

Um zu sehen wie newsyslog(8) reagiert, verwenden Sie das folgende Kommando:

% newsyslog -nrvv

Benutzen Sie tzsetup(8).

Das X Window System (oder auch nur X11) ist das am häufigsten verwendete Window System für UNIX®- und UNIX®-ähnliche Systeme, zu denen auch FreeBSD gehört. Der X Protokollstandard wird von der X.Org Foundation definiert und liegt aktuell in Version 11 Release 7.7 vor und wird häufig auch nur als X11 bezeichnet.

Das X Window System wurde für viele verschiedene Architekturen und Betriebssysteme implementiert. Eine serverseitige Implementierung wird dabei als X-Server bezeichnet.

Sie können Xorg wie folgt installieren:

Benutzen Sie den Meta-Port x11/xorg, der sämtliche Xorg Komponenten installiert.

Benutzen Sie x11/xorg-minimal, der nur die benötigten Komponenten installiert.

Sie können Xorg auch als Paket installieren:

# pkg install xorg

Lesen Sie nach erfolgreicher Installation von Xorg den Abschnitt X11 konfigurieren im FreeBSD Handbuch.

Das System läuft wahrscheinlich auf einer erhöhten Sicherheitsstufe (securelevel). X kann auf einer erhöhten Sicherheitsstufe nicht gestartet werden, weil X dazu Schreibzugriff auf io(4) benötigt. Lesen Sie dazu auch die Manualpage init(8).

Es gibt zwei Lösungen für dieses Problem: Setzen Sie die Sicherheitsstufe wieder zurück auf 0 oder starten Sie xdm(1) (oder einen alternativen Display Manager) während des Bootens, bevor die Sicherheitsstufe erhöht wird.

Der Abschnitt F: 11.10 enthält Informationen darüber, wie Sie xdm(1) beim Systemstart aktivieren können.

Wenn Sie den Standard-Konsolentreiber syscons(4) benutzen, können Sie FreeBSD so konfigurieren, dass auf jedem virtuellen Bildschirm ein Mauszeiger unterstützt wird. Um Konflikte mit X zu vermeiden, unterstützt syscons(4) ein virtuelles Gerät namens /dev/sysmouse. Alle Mausbewegungen und Mausklicks werden über moused(8) in das sysmouse(4) Gerät. Falls Sie die Maus auf einer oder mehreren virtuellen Konsolen und unter X benutzen wollen, sollten Sie zunächst F: 4.4.1 lesen und moused(8) konfigurieren.

Stellen Sie anschließend sicher, dass die folgenden Einträge in etc/X11/xorg.conf enthalten sind:

Section "InputDevice"
   Option          "Protocol" "SysMouse"
   Option          "Device" "/dev/sysmouse"
.....

Beginnend mit Xorg 7.4 werden Angaben im Abschnitt InputDevice von xorg.conf ignoriert. Stattdessen wird auf die automatisch ermittelten Werte zurückgegriffen. Um das alte Verhalten zu reaktivieren, fügen Sie die folgende Zeile entweder in den Abschnitt ServerLayout oder ServerFlags ein:

Option "AutoAddDevices" "false"

Einige Leute ziehen es vor, unter X /dev/mouse zu benutzen. Hierzu sollte /dev/mouse nach /dev/sysmouse (siehe sysmouse(4)) gelinkt werden, indem Sie die folgende Zeile in /etc/devfs.conf (siehe devfs.conf(5)) hinzufügen:

link    sysmouse    mouse

Die Verknüpfung kann durch Neustart von devfs(5) über das folgende Kommando (als root) erzeugt werden:

# service devfs restart

Dazu müssen Sie X nur mitteilen, dass Sie eine Maus mit 5 Tasten haben. Dazu fügen Sie die Zeilen Buttons 5 sowie ZAxisMapping 4 5 in den Abschnitt „InputDevice“ von /etc/X11/xorg.conf ein. Das Beispiel zeigt, wie ein solcher Abschnitt aussehen könnte.

Section "InputDevice"
   Identifier      "Mouse1"
   Driver          "mouse"
   Option          "Protocol" "auto"
   Option          "Device" "/dev/sysmouse"
   Option          "Buttons" "5"
   Option          "ZAxisMapping" "4 5"
EndSection

Wenn Sie die Maus in Emacs benutzen wollen, fügen Sie auch die folgenden Zeilen in ~/.emacs ein:

;; wheel mouse
(global-set-key [mouse-4] 'scroll-down)
(global-set-key [mouse-5] 'scroll-up)

Ja, aber damit es funktioniert, müssen Sie ein paar Dinge konfigurieren.

Damit Sie den Xorg synaptics Treiber benutzen können, müssen Sie zuerst moused_enable aus /etc/rc.conf entfernen.

Um synaptics zu aktivieren, fügen Sie die folgende Zeile in /boot/loader.conf ein:

hw.psm.synaptics_support="1"

Fügen Sie die folgende Zeile in /etc/X11/xorg.conf ein:

Section "InputDevice"
Identifier  "Touchpad0"
Driver      "synaptics"
Option      "Protocol" "psm"
Option      "Device" "/dev/psm0"
EndSection

Und fügen Sie die folgende Zeile in den Abschnitt „ServerLayout“ hinzu:

InputDevice    "Touchpad0" "SendCoreEvents"

Aus Sicherheitsgründen verbietet der X-Server in der Voreinstellung Verbindungen von entfernten Systemen.

Starten Sie den X mit der Option -listen_tcp, wenn Sie Verbindungen von entfernten Systemen erlauben wollen:

% startx -listen_tcp

Mit virtuellen Konsolen können Sie mehrere simultane Sitzungen auf einer Maschine laufen lassen, ohne so komplizierte Dinge wie die Einrichtung eines Netzwerkes oder die Benutzung von X zu benötigen.

Wenn das System startet, wird es nach der Anzeige aller Bootmeldungen eine Eingabeaufforderung auf dem Bildschirm anzeigen. Sie können dann auf der ersten virtuellen Konsole Ihren Benutzernamen und das Passwort eingeben und anfangen, zu arbeiten.

Um eine weitere Sitzung zu starten, vielleicht, um die Dokumentation zu einem Programm, das Sie gerade benutzen, einzusehen, oder, um Ihre Mails zu lesen, während Sie auf das Ende einer FTP-Übertragung warten. Drücken Sie AltF2 und Sie gelangen zur Anmelde-Aufforderung auf der zweiten virtuellen Konsole. Wenn Sie zurück zur ersten Sitzung möchten, drücken Sie Alt+F1.

Die Standardinstallation von FreeBSD bietet acht aktivierte virtuelle Konsolen. Mit Alt+F1, Alt+F2, Alt+F3 und so weiter wechseln Sie zwischen diesen virtuellen Konsolen.

Um weitere virtuelle Konsolen zu aktivieren, editieren Sie /etc/ttys (ttys(5)) und fügen Einträge für ttyv8 bis zu ttyvc nach dem Kommentar zu „Virtual terminals“ ein:

# Edit the existing entry for ttyv8 in /etc/ttys and change
# "off" to "on".
ttyv8   "/usr/libexec/getty Pc"         xterm  on secure
ttyv9   "/usr/libexec/getty Pc"         xterm  on secure
ttyva   "/usr/libexec/getty Pc"         xterm  on secure
ttyvb   "/usr/libexec/getty Pc"         xterm  on secure

Benutzen Sie so wenig oder so viele, wie Sie möchten. Je mehr virtuelle Terminals Sie benutzen, desto mehr Ressourcen werden gebraucht; das kann wichtig sein, wenn Sie 8 MB RAM oder weniger besitzen. Sie können auch secure in insecure ändern.

Um beispielsweise X und elf virtuelle Konsolen auszuführen, sollte die Einstellung für das virtuelle Terminal 12 wie folgt sein:

ttyvb   "/usr/libexec/getty Pc"         xterm  off secure

Sie können das System neu starten, um die virtuellen Konsolen zu aktivieren.

Benutzen Sie Strg+Alt+Fn um auf eine virtuelle Konsole umzuschalten. Mit Strg+Alt+F1 schalten Sie zur ersten virtuellen Konsole.

Sobald Sie auf eine virtuelle Konsole umgeschaltet haben, können Sie Alt+Fn benutzen, um zwischen den einzelnen virtuellen Konsolen umzuschalten.

Um zur X-Sitzung zurückzukehren, müssen Sie auf die virtuelle Konsole umschalten, auf der X läuft. Wenn Sie X über der Eingabeaufforderung mit startx gestartet haben, benutzt X die nächste freie virtuelle Konsole und nicht die Konsole, von der es gestartet wurde. Wenn Sie acht aktive virtuelle Konsolen haben, dann wird X die neunte benutzen und Sie können mit Alt+F9 umschalten.

Es gibt zwei Denkansätze, wie xdm(1) zu starten ist. Bei dem einen wird xdm unter Nutzung des mitgelieferten Beispiels über /etc/ttys (siehe ttys(5)) gestartet, während beim zweiten Ansatz rc.local (siehe rc(8)) oder das Skript X aus /usr/local/etc/rc.d verwendet wird. Beide Ansätze sind gleichwertig und der eine wird in Situationen funktionieren, in denen der andere es nicht tut. In beiden Fällen ist das Ergebnis das gleiche: X liefert eine graphische Anmeldeaufforderung.

Die ttys(5)-Methode hat den Vorteil, dass dokumentiert ist, auf welchem vty X gestartet wird und der Neustart des X-Servers beim Abmelden an init(8) übergeben wird. Die rc(8)-Methode erleichtert den Aufruf von kill xdm, falls Probleme beim Start des X-Servers auftreten sollten.

Beim Laden von rc(8), sollte xdm ohne irgendwelche Argumente (das heißt als Daemon) gestartet werden. xdm muss gestartet werden nachdem getty(8) läuft, andernfalls entsteht ein Konflikt zwischen getty und xdm und die Konsole bleibt gesperrt. Der beste Weg, um dies zu vermeiden, ist, das Skript für etwa zehn Sekunden anzuhalten und dann xdm zu starten.

Wenn Sie xdm durch einen Eintrag in /etc/ttys starten lassen, kann es zu einem Konflikt zwischen xdm und getty(8) kommen. Um dieses Problem zu vermeiden, sollten Sie die Nummer des vt in /usr/local/lib/X11/xdm/Xservers eintragen:

:0 local /usr/local/bin/X vt4

Diese Zeile führt dazu, dass der X Server /dev/ttyv3 nutzt. Die beiden Zahlen weichen voneinander ab: Der X-Server beginnt die Zählung der vty bei 1, während der FreeBSD-Kernel bei 0 beginnt.

Wenn X mit startx gestartet wird, werden die Zugriffsrechte für /dev/console nicht geändert, was dazu führt, dass Dinge wie xterm -C und xconsole nicht funktionieren.

Das hängt damit zusammen, wie die Zugriffsrechte für die Konsole standardmäßig gesetzt sind. Auf einem Mehrbenutzersystem möchte man nicht unbedingt, dass jeder Benutzer einfach auf die Systemkonsole schreiben kann. Für Benutzer, die sich auf einer Maschine direkt mit einem VTY anmelden, existiert die Datei fbtab(5), um derartige Probleme zu lösen.

In Kürze: sorgen Sie dafür, dass sich in der Datei /etc/fbtab (siehe fbtab(5)) eine nicht auskommentierte Zeile der folgenden Art befindet:

/dev/ttyv0 0600 /dev/console

Das sorgt dafür, dass wer auch immer sich auf /dev/ttyv0 anmeldet, auch die Konsole besitzt.

Ihre Maus und der Maustreiber sind vielleicht aus der Synchronisation geraten. In seltenen Fällen kann auch der Treiber irrtümlicherweise Synchronisationsprobleme melden:

psmintr: out of sync (xxxx != yyyy)

Falls das passiert, deaktivieren Sie den Code zur Überprüfung der Synchronisation, indem Sie die Treiberangaben für den PS/2-Maustreiber auf 0x100 setzen. Dazu fügen Sie einfach hint.psm.0.flags="0x100" in /boot/loader.conf ein und starten das System anschließend neu.

Geben Sie xmodmap -e "pointer = 3 2 1" ein. Fügen Sie dieses Kommando in ~/.xinitrc oder ~/.xsession hinzu, damit dies automatisch geschieht.

Die detaillierte Antwort auf diese Frage finden Sie im Abschnitt Willkommensbildschirme während des Bootvorgangs konfigurieren des FreeBSD Handbuchs.

Ja, Sie müssen lediglich mit xmodmap(1) festlegen, welche Aktion diese Tasten auslösen sollen.

Unter der Annahme, dass alle Windows-Tastaturen dem Standard entsprechen, lauten die Keycodes für die drei Tasten wie folgt:

Nach der folgenden Anweisung erzeugt die linke Windows-Taste ein Komma.

# xmodmap -e "keycode 115 = comma"

Um die neue Belegung der Windows-Tasten automatisch bei jedem Start von X zu erhalten, könnten entsprechende xmodmap Anweisungen in ~/.xinitrc einfügt werden. Die bevorzugte Variante ist aber, eine Datei mit dem Namen ~/.xmodmaprc zu erzeugen, die nur die Parameter für den Aufruf von xmodmap enthält. Wenn Sie mehrere Tasten umdefinieren wollen, muss jede Definition in eine eigene Zeile gesetzt werden. Weiterhin müssen Sie in ~/.xinitrc die folgende Zeile einfügen:

xmodmap $HOME/.xmodmaprc

Sie könnten die drei Tasten zum Beispiel mit den Funktionen F13, F14, und F15 belegen. Dadurch ist es sehr einfach, diese Tasten mit nützlichen Funktionen eines Programmes oder Desktops zu verknüpfen.

Um dies zu tun, fügen Sie die folgenden Zeilen in ~/.xmodmaprc ein.

keycode 115 = F13
keycode 116 = F14
keycode 117 = F15

Falls Sie zum Beispiel x11-wm/fvwm2 benutzen, können Sie ihn so einstellen, dass F13 das Fenster unter dem Mauszeiger minimiert bzw. maximiert. F14 holt das Fenster unter dem Mauszeiger in den Vordergrund bzw. ganz nach hinten, wenn es bereits im Vordergrund ist. F15 öffnet das Arbeitsplatz-Menü, auch wenn der Cursor nicht auf den Hintergrund zeigt. Dies ist extrem praktisch, wenn der gesamte Bildschirm von Fenster belegt wird.

Dieses Verhalten erhält man mit den folgenden Einträgen in ~/.fvwmrc:

Key F13        FTIWS    A        Iconify
Key F14        FTIWS    A        RaiseLower
Key F15        A        A        Menu Workplace Nop

Dies hängt davon ab, welche Version von Xorg und welche Grafikkarte Sie verwenden. Wenn Sie eine Karte mit nVidia-Chipsatz besitzen, benutzen Sie die binären Treiber für FreeBSD, indem Sie einen der folgenden Ports installieren:

Die aktuelle Version von nVidia-Karten wird durch den Port x11/nvidia-driver unterstützt.

Unterstützung für ältere Treiber finden Sie in x11/nvidia-driver-###

nVidia liefert detaillierte Informationen darüber, welche Karte von welchem Treiber unterstützt wird. Diese Information finden Sie auf der Website http://www.nvidia.com/object/IO_32667.html.

Für Matrox G200/400 können Sie den Port x11-servers/mga_hal benutzen.

Bei ATI Rage 128 und Radeon lesen Sie ati(4), r128(4) und radeon(4).

„Diskless Booting“ bedeutet, dass die FreeBSD-Maschine über ein Netzwerk gebootet wird und die notwendigen Dateien von einem Server anstatt von der Festplatte liest. Vollständige Details finden Sie im Handbucheintrag über den plattenlosen Betrieb.

Ja. Genaue Informationen zu diesem Thema finden Sie im Abschnitt Gateways und Routen des Handbuchkapitels Weiterführende Netzwerkthemen.

Personen, die diese Frage stellen, haben typischerweise zwei PCs zu Hause: einen mit FreeBSD und einen mit einer Windows®-Variante. Die Idee ist, die FreeBSD-Maschine an das Internet anzubinden, um in der Lage zu sein, von der Windows®-Maschine über die FreeBSD-Maschine auf das Internet zuzugreifen. Das ist tatsächlich nur ein Spezialfall der vorherigen Frage.

Wenn Sie eine Einwahlverbindung benutzen, müssen Sie ppp mit der Option -nat verwenden und in /etc/rc.conf die Variable gateway_enable auf YES setzen. Weitere Informationen erhalten Sie in ppp(8) oder im Abschnitt User-PPP des Handbuchs.

Wenn die Verbindung zum Internet über Ethernet erstellt wurde, müssen Sie natd(8) benutzen. Weitere Informationen dazu finden Sie im Abschnitt natd des Handbuchs.

Ja. ppp(8) bietet Unterstützung für eingehende und ausgehende Verbindungen.

Weitere Informationen finden Sie im Kapitel PPP im Handbuch.

Ja. Wenn Sie NAT über eine User-PPP-Verbindung einsetzen wollen, lesen Sie den Abschnitt PPP des Handbuchs. Wollen Sie NAT über eine andere Verbindung einsetzen, lesen Sie bitte den Abschnitt NAT Konfiguration im Handbuch.

Wenn sich die zweite Adresse im gleichen Subnetz befindet wie eine der Adressen, die bereits auf der Schnittstelle konfiguriert sind, benutzen Sie netmask 0xffffffff wie in diesem Beispiel:

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

Andernfalls geben sie die Adresse und die Netzmaske wie gewohnt an:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

Weitere Informationen finden Sie im FreeBSD Handbuch.

Einige Versionen des Linux® NFS-Codes akzeptieren Mount-Anfragen nur von einem privilegierten Port. Versuchen Sie den folgenden Befehl:

# mount -o -P linuxbox:/blah /mnt

Die häufigste Ursache für dieses Problem ist, dass Sie den Aufbau der /etc/exports nicht richtig verstanden haben. Lesen Sie exports(5) und das Kapitel NFS im Handbuch, speziell den Abschnitt Konfiguration von NFS.

Installieren Sie das Paket oder den Port net/mrouted und fügen Sie mrouted_enable="YES" in /etc/rc.conf hinzu, um den Dienst beim Booten zu starten.

Die Antwort hierzu finden Sie im FreeBSD Handbuch.

Wenn der Kernel mit der Option IPFIREWALL kompiliert wurde, müssen Sie beachten, dass die Standardrichtlinie alle Pakete, die nicht explizit zulässig sind, verweigert.

Wenn die Firewall unabsichtlich falsch konfiguriert wurde, stellen Sie die Netzwerkfunktionalität wieder her, indem Sie Folgendes als root eingeben:

# ipfw add 65534 allow all from any to any

Sie können in /etc/rc.conf auch firewall_type="open" setzen.

Weitere Informationen über die Konfiguration dieser Firewall finden Sie im Kapitel IPFW des Handbuchs.

Wahrscheinlich benötigen Sie Network Address Translation (NAT) und nicht die einfache Weiterleitung von Paketen. Die „fwd“-Regel leitet lediglich Pakete weiter; die Daten in den Paketen werden aber nicht verändert. Ein Beispiel:

01000 fwd 10.0.0.1 from any to foo 21

Wenn ein Paket mit dem Ziel foo die Maschine mit dieser Regel erreicht, wird das Paket an 10.0.0.1 weitergeleitet; die Zieladresse im Paket lautet aber immer noch foo! Die Zieladresse wird nicht in 10.0.0.1 geändert. Die meisten Rechner werden allerdings Pakete verwerfen, wenn die Zieladresse des Paketes nicht mit der Adresse des Rechners übereinstimmt. Das ist der Grund, warum eine „fwd“ Regel oft nicht den Effekt hat, den der Benutzer wollte. Dieses Verhalten ist aber kein Fehler, sondern erwünscht.

Wenn Sie einen Dienst auf eine andere Maschine umleiten wollen, sollten Sie die FAQ über die Umleitung von Diensten und die Manualpage natd(8) lesen. Auch in der Ports Sammlung sind diverse Hilfsprogramme für diesen Zweck enthalten.

Sie können für FTP und andere Dienste mit dem Paket oder Port sysutils/socket umleiten. Ersetzen sie die Befehlszeile für den Dienst in /etc/inetd.conf einfach so, dass stattdessen socket aufgerufen wird, wie in diesem Beispiel für ftpd zu sehen ist:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

wobei ftp.example.com und ftp entsprechend der Host und der Port sind, wohin umgeleitet werden soll.

Für FreeBSD gibt es drei Bandbreiten-Managementtools. dummynet(4) ist als Teil von ipfw(4) in FreeBSD integriert. ALTQ ist in FreeBSD Bestandteil von pf(4). Beim Bandbreiten-Manager von Emerging Technologies handelt es sich hingegen um ein kommerzielles Produkt.

Der Berkeley Paket Filter (bpf(4)) muss in den Kernel eingebunden werden, bevor er von einem Programm genutzt werden kann. Fügen Sie folgendes zur Kernelkonfigurationsdatei hinzu und erstellen Sie einen neuen Kernel:

device bpf        # Berkeley Packet Filter

Benutzen Sie die Programme aus dem Paket SMBFS. Es enthält einige Kernel-Erweiterungen und Benutzerprogramme. Die Programme und weitergehende Informationen sind unter mount_smbfs(8) im Basissystem verfügbar.

Diese Kernelmeldung deutet darauf hin, dass irgend jemand versucht, die Generierung von sehr vielen ICMP oder TCP reset (RST) Antworten zu provozieren. ICMP Antworten sind oft das Ergebnis von Verbindungsversuchen zu unbenutzten UDP Ports. TCP Resets werden generiert, wenn jemand versucht, eine Verbindung zu einem ungenutzten TCP Port aufzubauen. Die Meldungen können unter anderem durch die folgenden Ereignisse ausgelöst werden:

Die erste Zahl gibt an, wie viele Pakete vom Kernel ohne das Limit versendet worden wären; die zweite Zahl gibt das Limit an. Sie können das Limit mit der sysctl-Variable net.inet.icmp.icmplim einstellen. Im Beispiel wird das Limit auf 300 Pakete pro Sekunde gesetzt:

# sysctl net.inet.icmp.icmplim=300

Wenn Sie zwar die Begrenzung benutzen möchten, aber die Meldungen nicht in den Logdateien sehen möchten, können Sie die Meldungen mit der sysctl-Variable net.inet.icmp.icmplim_output abschalten:

# sysctl net.inet.icmp.icmplim_output=0

Falls Sie die Begrenzung ganz abschalten wollen, können Sie die sysctl-Variable net.inet.icmp.icmplim auf 0. Wir raten Ihnen aus den oben genannten Gründen dringend von diesem Schritt ab.

Ein Gerät im lokalen Ethernet verwendet eine MAC-Adresse in einem Format, das FreeBSD nicht kennt. Der wahrscheinlichste Grund ist, dass jemand Experimente mit einer Ethernet-Karte anstellt. Die Meldung tritt sehr häufig in Netzwerken mit Cable Modems auf. Die Meldung ist harmlos und sollte die Leistung des Systems nicht negativ beeinflussen.

Weil ein Paket unerwartet von außerhalb des Netzwerks empfangen wurde. Um die Nachrichten abzustellen, ändern Sie net.link.ether.inet.log_arp_wrong_iface auf 0.

„Sandkasten“ (sandbox) ist ein Ausdruck aus dem Bereich Sicherheit. Er hat zwei Bedeutungen:

UNIX® implementiert zwei Arten von Sandkästen - eine auf Prozessebene und die andere auf der Ebene der Benutzerkennung.

Jeder Prozess unter UNIX® ist komplett von allen anderen Prozessen abgeschirmt. Ein Prozess kann den Adressraum eines anderen Prozesses nicht modifizieren.

Ein UNIX® Prozess gehört einer bestimmten Benutzerkennung. Falls die Benutzerkennung nicht die von root ist, dient sie dazu, den Prozess von Prozessen anderer Benutzer abzuschirmen. Die Benutzerkennung wird außerdem dazu genutzt, Daten auf der Festplatte abzuschirmen.

Sicherheitsstufen (securelevel) sind ein Sicherheitsmechanismus, der im Kernel implementiert ist. Wenn die Sicherheitsstufe einen positiven Wert hat, verhindert der Kernel die Ausführung bestimmter Tätigkeiten; nicht einmal der Super-User (root) darf sie durchführen. Zurzeit können über die Sicherheitsstufen unter anderem die folgenden Tätigkeiten geblockt werden:

Das folgende Kommando kann benutzt werden, um die eingestellte Sicherheitsstufe eines aktiven Systems abzufragen:

# sysctl -n kern.securelevel

Die Ausgabe enthält den aktuellen Wert der Sicherheitsstufe. Wenn die Zahl positiv (größer als Null) ist, sind zumindest einige der Schutzmaßnahmen aktiviert.

Die Sicherheitsstufe eines laufenden Systems kann nicht verringert werden, da dies den Mechanismus nutzlos machen würde. Wenn Sie eine Tätigkeit ausführen müssen, bei der die Sicherheitsstufe nicht-positiv sein muss, dann müssen Sie die Variablen kern_securelevel und kern_securelevel_enable in /etc/rc.conf ändern und das System neustarten.

Weitere Informationen über die Sicherheitsstufen und was die Einstellungen bewirken, können Sie init(8) entnehmen.

BIND benutzt einen Port mit einer hohen, zufälligen Nummer für den Versand von Anfragen. Aktuelle Versionen wählen einen neuen, zufälligen UDP-Port für jede Anfrage. Das kann für manche Netzwerkkonfigurationen Probleme verursachen, besonders wenn eine Firewall eingehende UDP-Pakete auf bestimmten Ports blockiert. Wenn Sie durch eine solche Firewall wollen, können Sie die Optionen avoid-v4-udp-ports und avoid-v6-udp-ports ausprobieren, um ein zufälliges Auswählen von Portnummern innerhalb eines blockierten Bereiches zu verhindern.

Es ist eine sehr gute Angewohnheit, die Ausgaben von sockstat(1) durchzusehen und auf merkwürdige Dinge zu achten.

Aktuelle Versionen von Sendmail unterstützen eine Technik zur Einlieferung von Mails, die Port 587 nutzt. Diese Technik wird zwar noch nicht oft angewendet, erfreut sich aber ständig steigender Popularität.

Keine Panik. toor ist ein „alternativer“ Account für den Super-User (wenn man root rückwärts schreibt, erhält man toor). Dieser Account ist für die Verwendung mit einer alternativen Shell vorgesehen; damit ist es nicht mehr erforderlich, die Shell von root zu ändern. Dies ist wichtig, wenn eine Shell verwendet wird, die nicht zum Basissystem von FreeBSD gehört, zum Beispiel aus einem Port oder einem Paket. Diese Shells werden in der Regel in /usr/local/bin installiert und dieses Verzeichnis liegt standardmäßig auf einem anderen Dateisystem. Wenn die Shell von root in /usr/local/bin liegt und das Dateisystem, auf dem /usr/local/bin liegt nicht gemountet werden kann, kann sich root nicht mehr einloggen, um das Problem zu beheben. Es ist allerdings möglich, das System zu rebooten und das Problem im Single-User-Modus zu lösen, da man hier gefragt wird, welche Shell benutzt werden soll.

Einige Anwender benutzen toor mit einer alternativen Shell für die tägliche Arbeit und benutzen root (mit der Standard-Shell) für den Single-User-Modus und für Notfälle. Standardmäßig kann man sich nicht als toor anmelden, da der Account kein gültiges Passwort hat; Sie müssen sich also als root anmelden und ein Passwort für toor setzen, wenn Sie diesen Account benutzen wollen.

Lesen Sie zuerst ppp(8) und den Abschnitt zu PPP im Handbuch. Aktivieren Sie zur Fehlersuche die Protokollierung mit folgendem Befehl:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Dieser Befehl kann an der Eingabeaufforderung von ppp(8) eingegeben, oder in den Abschnitt default der Konfigurationsdatei /etc/ppp/ppp.conf eingetragen werden. Stellen Sie sicher, dass die Datei /etc/syslog.conf die folgenden Zeilen enthält und die Datei /var/log/ppp.log existiert:

!ppp
*.*        /var/log/ppp.log

Sie können nun in der Protokolldatei eine Menge darüber herausfinden, was geschieht. Es macht nichts, wenn die Einträge Ihnen gar nichts sagen. Wenn Sie jemandem um Hilfe bitten müssen, könnten sie für ihn von Nutzen sein.

Das liegt meistens daran, dass der Rechnername nicht aufgelöst werden kann. Um dieses Problem zu lösen, müssen Sie sicherstellen, dass /etc/hosts vom Resolver zuerst genutzt wird. Dazu muss in /etc/host.conf der Eintrag hosts an die erste Stelle gesetzt werden. Erstellen Sie dann für den lokalen Rechner einen Eintrag in /etc/hosts. Falls es kein lokales Netzwerk gibt, ändern Sie die localhost-Zeile:

127.0.0.1        foo.example.com foo localhost

Andernfalls fügen Sie einfach einen weiteren Eintrag für den lokalen Rechner hinzu. Weitere Informationen finden Sie in den entsprechenden Manualpages.

Wenn Sie fertig sind sollten Sie ping -c1 `hostname` erfolgreich ausführen können.

Überprüfen Sie zunächst, ob eine Standardroute existiert. Das folgende Kommando sollte zwei Einträge anzeigen:

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0

Wenn die Standardroute nicht erscheint, stellen Sie sicher, dass die Zeile HISADDR in /etc/ppp/ppp.conf hinzugefügt wurde.

Ein weiterer Grund dafür, dass die Zeile für die Standardroute fehlt, könnte der sein, dass Sie eine Standardroute in /etc/rc.conf eingetragen und die folgende Zeile in /etc/ppp/ppp.conf ausgelassen haben:

delete ALL

Lesen Sie in diesem Fall den Abschnitt Abschließende Systemkonfiguration des Handbuchs.

Dieser Fehler beruht für gewöhnlich auf einem fehlenden Abschnitt in /etc/ppp/ppp.linkup:

MYADDR:
  delete ALL
  add 0 0 HISADDR

Er ist nur notwendig, wenn Sie eine dynamische IP-Adresse besitzen oder die Adresse des Gateways nicht bekannt ist. Wenn Sie den interaktiven Modus benutzen, können Sie folgendes eingeben, nachdem Sie in den packet mode gelangt sind (den Paket Modus erkennen Sie an PPP im Prompt):

delete ALL
add 0 0 HISADDR

Weitere Informationen finden Sie im Abschnitt PPP und Dynamische IP-Adressen des Handbuchs.

Der Standardtimeout für PPP beträgt drei Minuten. Er kann durch die folgende Zeile eingestellt werden:

set timeout NNN

NNN gibt die Inaktivität in Sekunden an, bevor die Verbindung geschlossen wird. Falls NNN Null ist, wird die Verbindung niemals aufgrund eines Timeouts geschlossen. Es ist möglich, diesen Befehl in ppp.conf einzubinden, oder ihn an der Eingabeaufforderung im interaktiven Modus einzugeben. Durch eine Verbindung zum Server-Socket von ppp über telnet(1) oder pppctl(8) ist es auch möglich, den Timeout bei aktiver Verbindung anzupassen. Weitere Informationen finden Sie in der Manualpage ppp(8).

Falls Link-Quality-Reporting (LQR) konfiguriert wurde, ist es möglich, dass zu viele LQR-Pakete zwischen dem FreeBSD-System und dem verbundenen Rechner verloren gehen. ppp(8) folgert daraus, dass die Verbindung nicht in Ordnung ist und schließt sie. LQR ist standardmäßig deaktiviert und kann mit der folgenden Zeile aktiviert werden:

enable lqr

Wenn die Qualität der Telefonleitung zu schlecht oder beim Anschluss die Option Anklopfen aktiviert ist, kann es manchmal vorkommen, dass das Modem auflegt, weil es fälschlicherweise annimmt, dass es das Trägersignal verloren hat.

Bei den meisten Modems gibt es eine Einstellmöglichkeit, um anzugeben, wie tolerant es gegenüber vorübergehenden Verlusten des Trägersignals sein soll. Lesen Sie die Dokumentation des Modems für weitere Informationen.

Viele Leute machen Erfahrungen mit hängenden Verbindungen ohne erkennbaren Grund. Als erstes muss festgestellt werden, auf welcher Seite die Verbindung hängt.

Wenn Sie ein externes Modem benutzen, können Sie versuchen, ping(8) zu benutzen, um zu sehen, ob die TD-Anzeige aufleuchtet, wenn Daten übertragen werden. Falls sie aufleuchtet (und die RD-Anzeige nicht), liegt das Problem am anderen Ende. Falls TD nicht aufleuchtet, handelt es sich um ein lokales Problem. Bei einem internen Modem müssen Sie den Befehl set server in ppp.conf benutzen. Stellen Sie über pppctl(8) eine Verbindung zu ppp(8) her, wenn die Verbindung hängt. Falls die Netzwerkverbindung plötzlich wieder funktioniert (ppp wurde durch die Aktivität auf dem Diagnose-Socket wiederbelebt) oder Sie keine Verbindung bekommen (vorausgesetzt, der Befehl set socket wurde beim Start erfolgreich ausgeführt), handelt es sich um ein lokales Problem. Falls Sie eine Verbindung bekommen und die externe Verbindung weiterhin hängt, aktivieren Sie lokales asynchrones Logging mit set log local async und benutzen Sie ping(8) von einem anderen Fenster oder Bildschirm aus, um die externe Verbindung zu benutzen. Das asynchrone Logging zeigt, welche Daten über die Verbindung gesendet und empfangen werden. Falls Daten hinausgehen, aber nicht zurückkommen, handelt es sich um ein externes Problem.

Wenn Sie festgestellt haben, ob es sich um ein lokales oder um ein externes Problem handelt, haben Sie zwei Möglichkeiten:

Hier können Sie wenig tun. Die meisten ISPs werden ablehnen, Ihnen zu helfen, wenn Sie kein Betriebssystem von Microsoft® benutzen. Sie können enable lqr in /etc/ppp/ppp.conf angeben, wodurch ppp(8) ermöglicht wird, ein externes Versagen zu erkennen und aufzulegen. Jedoch ist diese Erkennung relativ langsam und deshalb nicht besonders nützlich.

Versuchen Sie zunächst, jegliche Datenkompression auszuschalten, indem Sie folgendes zur Konfiguration hinzufügen:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

Stellen Sie nun wieder eine Verbindung her, um festzustellen, ob sich etwas geändert hat. Falls es nun besser läuft oder falls das Problem vollständig behoben ist, versuchen Sie durch schrittweises Ändern der Einstellungen festzustellen, welche Einstellung den Unterschied bewirkt. Hierdurch erhalten Sie schlüssige Fakten für ein Gespräch mit dem ISP. Andererseits wird hierdurch offensichtlich, dass Sie kein Microsoft®-System benutzen.

Aktivieren Sie asynchrones Logging und warten Sie, bis die Verbindung wieder hängt, bevor Sie sich an den ISP wenden. Hierzu kann einiges an Plattenplatz nötig sein. Die Daten, die als letztes von dem Port gelesen wurden, könnten von Interesse sein. Für gewöhnlich handelt es sich um ASCII-Text, der sogar den Fehler beschreiben kann (Memory fault, Core dumped).

Falls der ISP hilfsbereit ist, sollte er in der Lage sein, an seinem Ende das Logging zu aktivieren und wenn das nächste Mal die Verbindung abbricht, könnte er Ihnen mitteilen, worin das Problem auf seiner Seite besteht.

In diesem Fall erstellen Sie am besten ppp(8) mit Debugging-Informationen neu und benutzen dann gdb(1), um von dem hängenden ppp-Prozess eine Aufzeichnung des Stacks zu erstellen. Um die ppp-Anwendung mit Debugging-Informationen zu übersetzen, geben Sie folgendes ein:

# cd /usr/src/usr.sbin/ppp
# env DEBUG_FLAGS='-g' make clean
# env DEBUG_FLAGS='-g' make install

Anschließend starten Sie ppp neu und warten darauf, dass es wieder hängt. Wenn die Debug-Version von ppp hängt, starten Sie gdb für den steckengebliebenen Prozess, indem Sie folgendes eingeben:

# gdb ppp `pgrep ppp`

An der Eingabeaufforderung von gdb können Sie die Befehle bt oder where benutzen, um eine Aufzeichnung des Stacks zu erhalten. Speichern Sie die Ausgabe der gdb-Sitzung und „trennen“ Sie den laufenden Prozess mit quit.

Nach dem Aufbau einer Verbindung kann es sein, dass Sie in der Logdatei gelegentlich Meldungen mit dem Hinweis magic is the same sehen. Manchmal sind diese Meldungen harmlos und manchmal bricht die eine oder andere Seite die Verbindung ab. Die meisten Implementierungen von PPP können dieses Problem nicht handhaben und Sie werden wiederholte Konfigurationsanforderungen und -bestätigungen in der Logdatei finden, bis ppp(8) schließlich aufgibt und die Verbindung beendet.

Dies geschieht normalerweise auf Servern mit langsamen Festplatten, bei denen ein getty(8) auf dem Port ausgeführt und ppp(8) nach dem Einloggen von einem Login-Skript oder einem Programm aus gestartet wird. Es wurde auch schon berichtet, dass dies bei der Benutzung von slirp regelmäßig auftritt. Der Grund hierfür ist, dass das ppp(8) auf der Client-Seite in der Zeit, die benötigt wird, getty(8) zu beenden und ppp(8) zu starten, bereits beginnt, Line Control Protocol (LCP) Pakete zu senden. Da ECHO auf dem Serverport weiterhin eingeschaltet ist, werden diese Pakete zum ppp(8) auf der Client-Seite „reflektiert“.

Ein Teil der LCP-Verhandlungen ist die Einrichtung einer „Magic Number“ für jede Seite der Verbindung, damit „Echos“ erkannt werden können. Das Protokoll besagt, dass, wenn der Partner versucht, die gleiche „Magic Number“ auszuhandeln, ein NAK zurückgesendet und eine neue „Magic Number“ gewählt werden soll. Während der Server das ECHO eingeschaltet hat, sendet der Client LCP Pakete, sieht die gleiche „Magic Number“ im reflektierten Paket und erzeugt ein NAK. Er sieht auch das reflektierte NAK (was bedeutet, dass ppp(8) seine „Magic Number“ ändern muss). Hierdurch wird eine Vielzahl von Änderungen der „Magic Number“ hervorgerufen, die sich allesamt im tty-Puffer des Servers ansammeln. Sobald ppp(8) auf dem Server startet, wird es mit Änderungen der „Magic Number“ überflutet und entscheidet, dass es sich zur Genüge mit den LCP-Verhandlungen beschäftigt hat und gibt auf. Und während sich der Client noch darüber freut, dass er keine weiteren Reflexionen sieht, wird ihm gemeldet, dass der Server auflegt.

Dies kann verhindert werden, indem dem Partner durch die folgende Zeile in ppp.conf erlaubt wird, mit der Verhandlung zu beginnen:

set openmode passive

Hierdurch wird ppp(8) mitgeteilt, darauf zu warten, dass der Server mit den LCP-Verhandlungen beginnt. Einige Server starten jedoch nie mit der Verhandlungen; falls dies der Fall ist, können Sie folgendes tun:

set openmode active 3

Hierdurch bleibt ppp(8) für drei Sekunden passiv und fängt dann erst an, LCP-Anforderungen zu senden. Falls der Partner während dieser Zeit beginnt, Anforderungen zu senden, wird ppp(8) direkt antworten und nicht erst, nachdem die drei Sekunden abgelaufen sind.

Es gibt derzeit eine Fehlfunktion in der Implementierung von ppp(8), die darin besteht, dass LCP-, CCP- und IPCP-Antworten nicht mit den ursprünglichen Anforderungen assoziiert werden. Für den Fall, dass eine Implementation von PPP mehr als sechs Sekunden langsamer ist, als die andere Seite, resultiert das darin, dass die andere Seite zwei weitere LCP-Konfigurationsanforderungen sendet, was fatale Auswirkungen hat.

Stellen Sie sich zwei Implementierungen A und B vor. A beginnt unmittelbar nach der Verbindung, LCP-Anforderungen zu senden und B benötigt sieben Sekunden, zu starten. Wenn B startet, hat A bereits drei LCP-Anforderungen gesendet. Wir nehmen an, dass ECHO ausgeschaltet ist; andernfalls würden wir Probleme mit der „Magic Number“ beobachten, wie bereits im vorherigen Abschnitt beschrieben. B sendet eine Anforderung und anschließend eine Bestätigung der ersten Anforderung von A. Dies führt dazu, dass A in den Zustand OPENED übergeht und eine Bestätigung (die erste) zurück an B sendet. In der Zwischenzeit sendet B zwei weitere Bestätigungen als Antwort auf die zusätzlichen Anforderungen, die von A gesendet worden sind, bevor B gestartet ist. B empfängt dann die erste Bestätigung von A und geht in den Zustand OPENED über. A empfängt die zweite Bestätigung von B, geht zurück in den Zustand REQ-SENT und sendet eine weitere (vierte) Anforderung entsprechend dem RFC. A empfängt dann die dritte Bestätigung und geht in den Zustand OPENED über. In der Zwischenzeit empfängt B die vierte Anforderung von A, wechselt in den Zustand ACK-SENT und sendet eine weitere (zweite) Anforderung und (vierte) Bestätigung entsprechend dem RFC. A erhält die Anforderung, geht in den Zustand REQ-SENT über, sendet eine weitere Anforderung, erhält unverzüglich die nächste Bestätigung und geht in OPENED über.

Das geht so lange weiter, bis eine Seite erkennt, dass man zu keinem Ergebnis gelangt und aufgibt.

Am besten verhindert man solche Situationen, indem man eine Seite als passiv konfiguriert, also dafür sorgt, dass eine Seite darauf wartet, dass die andere mit den Verhandlungen beginnt. Das kann durch den folgenden Befehl geschehen:

set openmode passive

Diese Option sollten Sie mit Vorsicht genießen. Folgenden Befehl sollten Sie benutzen, um die Wartezeit auf den Beginn der Verhandlungen des Partners von ppp(8) zu begrenzen:

set stopped N

Alternativ kann der folgende Befehl (wobei N die Wartezeit in Sekunden vor Beginn der Verhandlungen angibt) benutzt werden:

set openmode active N

Weitere Informationen finden Sie in der Manualpage.

Wenn Sie den Befehl shell oder ! benutzen, führt ppp(8) eine Shell aus (falls Sie Argumente übergeben haben, führt ppp(8) diese Argumente aus). Das Programm ppp wartet auf die Beendigung des Befehls, bevor es seine Arbeit fortsetzt. Falls Sie versuchen, die PPP-Verbindung während der Programmausführung zu benutzen, wird es so aussehen, als wäre die Verbindung eingefroren. Das liegt daran, dass ppp(8) auf die Beendigung des Befehls wartet.

Falls Sie solche Befehle verwenden möchten, benutzen Sie stattdessen den Befehl !bg. Hierdurch wird der angegebene Befehl im Hintergrund ausgeführt und ppp(8) kann fortfahren, die Verbindung zu bedienen.

Es gibt keine Möglichkeit für ppp(8), automatisch festzustellen, ob eine direkte Verbindung beendet worden ist. Das liegt an den Leitungen, die bei einem seriellen Nullmodem-Kabel benutzt werden. Wenn Sie diese Art der Verbindung verwenden, sollte LQR immer mit der folgenden Zeile aktiviert werden:

enable lqr

LQR wird standardmäßig akzeptiert, wenn es vom Partner ausgehandelt wird.

Falls ppp(8) unerwartet wählt, müssen Sie den Grund herausfinden und Wählfilter (dfilters) einsetzen, um dies zu verhindern.

Benutzen Sie die folgende Zeile, um den Grund herauszufinden:

set log +tcp/ip

Dadurch wird jeglicher Verkehr über die Verbindung protokolliert. Wenn das nächste mal unerwartet eine Verbindung hergestellt wird, wird der Grund zusammen mit einer hilfreichen Zeitangabe in der Logdatei gespeichert.

Sie können nun das Wählen aufgrund dieser Bedingungen verhindern. Normalerweise wird diese Art von Problemen durch Anfragen an den DNS verursacht. Um zu verhindern, dass DNS-Anfragen den Aufbau der Verbindung hervorrufen (das verhindert nicht, dass Pakete über eine bestehende Verbindung gesendet werden), benutzen Sie die folgenden Zeilen:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

Dies ist nicht immer brauchbar, weil es effektiv die Fähigkeit, auf Anforderung wählen zu können einschränkt - die meisten Programme müssen eine DNS-Anfrage durchführen, bevor Sie andere, das Netzwerk betreffenden Dinge tun können.

Im Fall von DNS sollten Sie versuchen, herauszufinden, welches Programm tatsächlich versucht, einen Hostnamen aufzulösen. Sehr oft handelt es sich hier um Sendmail. Sie sollten sicherstellen, dass Sie Sendmail in der Konfigurationsdatei sagen, dass es keine DNS-Anfragen durchführen soll. Weitere Details enthält der Abschnitt E-Mail über Einwahl-Verbindungen des Handbuchs. Sie könnten z.B. die folgende Zeile in die .mc-Datei einfügen:

define(`confDELIVERY_MODE', `d')dnl

Das veranlasst Sendmail dazu, alles in eine Warteschlange einzureihen, bis die Warteschlange verarbeitet wird (normalerweise alle 30 Minuten) oder wenn sendmail -q ausgeführt wird (z.B. aus /etc/ppp/ppp.linkup heraus).

Ich sehe ständig folgende Fehler in meiner Logdatei:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)

Das liegt daran, dass ppp(8) versucht, die Komprimierung Predictor1 auszuhandeln und der Partner über keinerlei Komprimierung verhandeln will. Die Meldungen sind harmlos, aber wenn Sie sie beseitigen möchten, können Sie die Komprimierung auch lokal ausschalten:

disable pred1

Um alle Zeilen der Modemkonversation zu protokollieren, müssen Sie folgendes einstellen:

set log +connect

Dies veranlasst ppp(8) dazu, alles bis zur letzten angeforderten „expect“-Zeile zu protokollieren.

Falls Sie die Geschwindigkeit der Verbindung erfahren möchten und PAP oder CHAP nutzen, müssen Sie sicherstellen, dass Sie ppp(8) so konfigurieren, die gesamte CONNECT-Zeile zu erwarten, etwa so:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Hier bekommen wir unser CONNECT, senden nichts, erwarten dann einen Line-Feed, der ppp(8) zwingt, die gesamte CONNECT-Antwort zu lesen.

Das Programm ppp analysiert jede Zeile seiner Konfigurationsdatei, damit es Zeichenketten wie z.B. set phone "123 456 789" korrekt interpretieren und zudem erkennen kann, dass es sich bei der Nummer tatsächlich nur um ein Argument handelt. Um das Zeichen " anzugeben, müssen Sie ihm einen Backslash (\) voranstellen.

Wenn der Chat-Interpreter jedes Argument analysiert, reinterpretiert er die Argumente, um irgendwelche speziellen Escape-Sequenzen wie z.B. \P oder \T zu finden. Das Ergebnis dieser Doppelanalyse ist, dass Sie daran denken müssen, die richtige Anzahl an Escape-Zeichen zu verwenden.

Falls Sie tatsächlich das Zeichen \ senden möchten, benutzen Sie etwas wie:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Woraus sich folgende Zeichen ergeben:

ATZ
OK
AT\X
OK

Oder:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"

Woraus sich folgende Zeichen ergeben:

ATZ
OK
ATDT1234567

FCS steht für Frame Check Sequence. Jedes PPP-Paket besitzt eine Checksumme, um sicherzustellen, dass die empfangenen Daten dieselben sind, wie die versendeten. Falls die FCS eines ankommenden Paketes fehlerhaft ist, wird das Paket verworfen und der Zähler HDLC FCS wird erhöht. Der HDLC-Fehlerwert kann durch den Befehl show hdlc angezeigt werden.

Falls die Leitung schlecht ist, oder falls der serielle Treiber Pakete verwirft, werden gelegentliche FCS-Fehler generiert. Normalerweise lohnt es sich nicht, sich hierüber Gedanken zu machen, obwohl das Kompressionsprotokoll hierdurch wesentlich langsamer wird.

Falls die Leitung einfriert, sobald die Verbindung steht, und viele FCS-Fehler auftreten, müssen Sie sicherstellen, dass das Modem keinen Software-Flow-Control (XON/XOFF) verwendet. Falls die Datenschnittstelle Software-Flow-Control verwenden muss, benutzen Sie den Befehl set accmap 0x000a0000, um ppp(8) zu sagen, dass es die Zeichen ^Q und ^S maskieren soll.

Ein weiterer Grund dafür, dass zu viele FCS-Fehler auftreten, könnte der sein, dass das andere Ende aufgehört hat, PPP zu sprechen. Aktivieren Sie async Logging, um festzustellen, ob es sich bei den eingehenden Daten tatsächlich um einen login- oder Shell-Prompt handelt. Wenn Sie am anderen Ende einen Shell-Prompt haben, ist es möglich, durch den Befehl close lcp gefolgt von term zu benutzen, um ppp(8) zu beenden, ohne die Verbindung zu beenden und Sie wieder mit der Shell auf dem entfernten Rechner verbinden.

Falls nichts in der Logdatei darauf hindeutet, warum die Verbindung beendet wurde, sollten Sie den Administrator oder ISP des externen Rechners fragen, warum die Sitzung beendet worden ist.

Falls alles andere fehlschlägt, senden Sie möglichst umfangreiche Informationen, einschließlich Ihrer Konfigurationsdateien, wie Sie ppp(8) starten, die relevanten Teile Ihrer Logdateien und die Ausgabe von netstat -rn (vor und nach Aufbau der Verbindung) an die FreeBSD general questions mailing list.

Es existiert eine Liste der unterstützten Karten im Abschnitt Serielle Datenübertragung des Handbuchs.

Die meisten auf den 16550 basierten PCI Multi-Port-Karten werden mühelos unterstützt.

Von einigen NoName-Nachbauten ist ebenfalls bekannt, dass sie funktionieren, speziell von den AST-kompatiblen.

In uart(4) und sio(4) finden Sie weitere Informationen zur Konfiguration solcher Karten.

Lesen Sie diesen Abschnitt des Handbuchs.

Wenn der FreeBSD Kernel bootet, testet er die seriellen Schnittstellen, für die er konfiguriert wurde. Sie können entweder aufmerksam die Bootmeldungen verfolgen, oder Sie führen den folgenden Befehl aus, nachdem das System hochgefahren ist und läuft:

% dmesg | grep -E "^sio[0-9]"
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A

Dieses Beispiel zeigt zwei serielle Schnittstellen. Die erste verwendet Port-Adresse 0x3f8, IRQ4 und hat einen 16550A UART Chip. Die zweite benutzt ebenfalls einen 16550A UART, jedoch Port-Adresse 0x2f8 und IRQ3. Modemkarten werden wie serielle Schnittstellen behandelt. Der einzige Unterschied ist, dass an diesen Schnittstellen immer ein Modem angeschlossen ist.

Der GENERIC-Kernel beinhaltet Unterstützung für zwei serielle Schnittstellen, die den im Beispiel genannten Port und IRQ verwenden. Wenn diese Einstellungen nicht richtig für das System sind, Sie Modemkarten hinzugefügt oder mehr serielle Schnittstellen haben als die Kernelkonfiguration zulässt, konfigurieren Sie den Kernel einfach neu. In dem Kapitel über die Kernelkonfiguration finden Sie mehr Details.

Die dritte serielle Schnittstelle, sio2 (COM3), ist /dev/cuad2 für Geräte mit abgehenden Verbindungen und /dev/ttyd2 für Geräte mit eingehenden Verbindungen. Was ist der Unterschied zwischen den beiden Geräteklassen?

Wird /dev/ttydX im blockierenden Modus geöffnet, wartet ein Prozess darauf, dass das entsprechende cuadX Gerät inaktiv und der Empfangssignalpegel aktiv ist. Wird das cuadX Gerät geöffnet, vergewissert es sich, dass die serielle Schnittstelle nicht bereits von dem ttydX Gerät in Gebrauch ist. Sollte die Schnittstelle verfügbar sein, „stiehlt“ es sie von dem ttydX Gerät. Das cuadX Gerät kümmert sich nicht um Trägersignalerkennung. Mit diesem Schema und einem automatisch antwortenden Modem, können sich Benutzer von aussen einloggen, Sie können weiterhin mit demselben Modem wählen und das System kümmert sich um die Konflikte.

Der Abschnitt über die Kernelkonfiguration bietet Informationen darüber, wie Sie den Kernel konfigurieren. Für eine Karte mit mehreren seriellen Schnittstellen, schreiben Sie eine sio(4) Zeile für jede serielle Schnittstelle auf der Karte in die Datei device.hints(5). Aber achten Sie darauf, den IRQ nur in einem der Einträge zu platzieren. Alle seriellen Schnittstellen auf der Karte sollten sich einen IRQ teilen. Daher sollten Sie den IRQ nur beim letzten Eintrag angeben. Aktivieren Sie auch die folgende Option in der Kernelkonfigurationsdatei:

options COM_MULTIPORT

Das folgende /boot/device.hints Beispiel ist geeignet für eine AST Karte mit 4 seriellen Schnittstellen, die IRQ 12 benutzt:

hint.sio.4.at="isa"
hint.sio.4.port="0x2a0"
hint.sio.4.flags="0x701"
hint.sio.5.at="isa"
hint.sio.5.port="0x2a8"
hint.sio.5.flags="0x701"
hint.sio.6.at="isa"
hint.sio.6.port="0x2b0"
hint.sio.6.flags="0x701"
hint.sio.7.at="isa"
hint.sio.7.port="0x2b8"
hint.sio.7.flags="0x701"
hint.sio.7.irq="12"

Die Flags zeigen an, dass die Master-Schnittstelle die Minor-Nummer 7 (0x700) hat und dass sich alle Schnittstellen einen IRQ (0x001) teilen.

See the Serial Communications section in the FreeBSD Handbook.

Lesen Sie dazu den Abschnitt über Einwählverbindungen im FreeBSD Handbuch.

Diese Information finden Sie im Abschnitt Terminals im FreeBSD Handbuch.

Die Programme tip(1) und cu(1) können auf das Verzeichnis /var/spool/lock nur über den Benutzer uucp und die Gruppe dialer zugreifen. Benutzen Sie die Gruppe dialer um zu kontrollieren, wer Zugriff auf das Modem oder entfernte Systeme hat. Fügen Sie diese Benutzerkonten einfach selbst zur Gruppe dialer hinzu.

Alternativ können Sie jeden Benutzer auf dem System tip(1) und cu(1) verwenden lassen, dazu müssen Sie folgendes eingeben:

# chmod 4511 /usr/bin/cu
# chmod 4511 /usr/bin/tip

FreeBSD lagert vorbeugend vollkommen untätige, unbenutzte Seiten aus dem Hauptspeicher in den Swap-Bereich aus, um mehr Hauptspeicher für die aktive Nutzung zur Verfügung zu stellen. Die spürbar höhere Nutzung des Swap-Speichers wird durch die effizientere Nutzung des Hauptspeichers wieder ausgeglichen.

Beachten Sie, dass FreeBSD in dieser Hinsicht zwar vorbeugend arbeitet, es entscheidet jedoch nicht willkürlich, Seiten auszulagern, wenn das System vollkommen untätig ist. Sie können feststellen, dass nicht alle Seiten des Systems ausgelagert wurden, nachdem das System eine Nacht lang nicht benutzt worden ist.

Die Antwort ist ganz einfach: Freier Speicher ist verschwendeter Speicher. Der FreeBSD Kernel verwendet den von den Programmen nicht genutzten Speicher automatisch für den Plattencache. Die in top(1) für Inact, Cache und Buf gemeldeten Werte stehen alle für zwischengespeicherte Daten mit unterschiedlichem Alter. Wenn das System wiederholt auf Daten zugreifen muss, braucht es nicht auf die langsame Platte zuzugreifen, da die Daten noch zwischengespeichert sind. Dadurch erhöht sich die Performance. Ganz generell ist es ein gutes Zeichen, wenn top(1) einen kleinen Wert bei Free anzeigt, solange der Wert nicht extrem klein ist.

Für symbolische Links gibt es keine separaten Zugriffsrechte und standardmäßig folgt chmod(1) dem Link, wenn möglich; die Zugriffsrechte für die Datei, auf die der symbolische Link zeigt, werden also verändert. Wenn Sie eine Datei mit dem Namen foo und einen auf diese Datei zeigenden symbolischen Link mit dem Namen bar haben, wird das folgende Kommando niemals einen Fehler melden.

% chmod g-w bar

Trotzdem werden die Zugriffsrechte für bar nicht geändert.

Wenn Sie die Zugriffsrechte in der Dateihierarchie an der Wurzeldatei anstatt der Datei selbst ändern möchten, müssen Sie entweder -H oder -L zusammen mit der Option -R benutzen. Lesen Sie chmod(1) und symlink(7) für weitere Informationen.

% chmod 555 foo/

Ja. Sie können emulators/doscmd verwenden, das über die FreeBSD Ports-Sammlung verfügbar ist.

Falls doscmd nicht ausreicht, können Sie den Port emulators/pcemu verwenden, der einen 8088 und genug BIOS-Funktionen emuliert, um DOS-Textanwendungen laufen zu lassen. Der Port benötigt das X Window System.

Die Ports-Sammlung enthält auch emulators/dosbox. Das Hauptaugenmerk liegt bei dieser Anwendung auf der Emulation alter DOS Spiele, deren Dateien sich im lokalen Dateisystem befinden.

Lesen Sie die Translation FAQ im FreeBSD Documentation Project Primer.

Das Mailsystem von FreeBSD.org verwendet einige der strengeren Überprüfungen von Postfix für eingehende Mails. Mails, bei denen es Anzeichen für Konfigurationsprobleme oder Spam gibt, werden nicht akzeptiert. Es gibt einige spezielle Anforderungen:

Damit die Mail auch ihr Ziel erreicht, hier ein paar weitere Ratschläge:

Falls Sie immer noch Probleme mit der E-Mail-Infratruktur von FreeBSD.org haben, schicken Sie eine Nachricht mit den Details an <postmaster@freebsd.org>. Fügen Sie Datum/Uhrzeit ein, damit die Logdateien überprüft werden können. Beachten Sie jedoch, dass die Mail-Logs nur eine Woche gespeichert werden. Vergewissern Sich sich auch, die Zeitzone oder einen Offset in UTC anzugeben.

Das FreeBSD Project bietet zwar keinen freien Zugang zu seinen Servern an; andere Firmen bieten jedoch frei zugängliche UNIX® Systeme. Die Kosten variieren und es kann sein, dass nicht alle Dienste zur Verfügung stehen.

Arbornet, Inc, auch als M-Net bekannt, bietet seit 1983 uneingeschränkten Zugang zu UNIX® Systemen. Zunächst wurde eine Altos-Maschine mit System III benutzt, 1991 erfolgte dann der Wechsel zu BSD/OS. Im Juni 2000 erfolgte ein erneuter Wechsel, diesmal zu FreeBSD. M-Net bietet Zugang mit telnet und SSH und den Zugang zur gesamten Software von FreeBSD. Allerdings ist der Zugriff auf das Netzwerk auf Mitglieder und Gönner beschränkt, die eine Spende an die nicht-kommerzielle Organisation geleistet haben. M-Net stellt zusätzlich ein Mailbox-System und einen interaktiven Chat zur Verfügung.

Er ist namenlos, es ist einfach „der BSD Daemon“. Wenn Sie ihm unbedingt einen Namen geben wollen, nennen Sie ihn „beastie“. Beachten Sie aber, dass „beastie“ wie „BSD“ ausgesprochen wird.

Weitere Informationen über den BSD daemon finden Sie auf seiner Homepage.

Eventuell. Der BSD Daemon unterliegt dem Copyright von Marshall Kirk McKusick. Lesen Sie sein Statement on the Use of the BSD Daemon Figure, wenn Sie genaue Informationen über die Einschränkungen bei der Nutzung brauchen.

Kurz gesagt, können Sie den BSD Daemon benutzen, solange es für einen privaten Zweck ist und die Nutzung geschmackvoll bleibt. Bevor Sie das Logo kommerziell nutzen, bitten Sie Kirk McKusick <mckusick@FreeBSD.org> um Erlaubnis. Weitere Informationen erhalten Sie auf BSD Daemon's home page

Einige Bilder in den Formaten Xfig und eps sind unter /usr/share/examples/BSD_daemon/ verfügbar.

Sehen Sie im FreeBSD-Glossar nach.

Die ganz, ganz kurze Antwort ist: Überhaupt nicht. Die etwas längere Antwort lautet: Nur weil Sie in der Lage sind, einen Fahrradschuppen zu bauen, müssen Sie noch lange nicht andere davon abhalten, nur weil Ihnen die Farbe nicht gefällt. Dies ist natürlich eine Metapher dafür, dass Sie nicht eine Diskussion über jede kleine Änderung beginnen sollen, nur weil Sie das können. Einige Leute behaupten sogar, dass die Anzahl der (nutzlosen) Kommentare über eine Änderung umgekehrt proportional zur Komplexität der Änderung ist.

Die noch längere und vollständigere Antwort ist, dass Poul-Henning Kamp <phk@FreeBSD.org> nach einen langen Diskussion über das Thema „Soll sleep(1) Sekundenbruchteile als Parameter akzeptieren?“ eine lange Mail mit dem Titel „A bike shed (any color will do) on greener grass...“ schrieb. Die einschlägigen Teile der Nachricht lauteten:

Q. Hat irgend jemand Temperaturmessungen durchgeführt, während FreeBSD läuft? Ich weiß, dass Linux® cooler läuft als DOS, habe aber niemals gesehen, dass FreeBSD erwähnt wurde. Es scheint sehr heiß zu laufen.

A. Nein, aber wir haben zahlreiche Geschmackstests mit Freiwilligen mit verbundenen Augen durchgeführt, denen außerdem zuvor 250 Mikrogramm LSD-25 verabreicht wurden. 35% der Freiwilligen sagte, dass FreeBSD nach Orange schmeckte, Linux® hingegen schmecke wie Purple Haze. Keine der Gruppen hat besondere Abweichungen der Temperatur erwähnt. Eventuell hätten wir sämtliche Ergebnisse dieser Untersuchung fortwerfen sollen, als wir festgestellt haben, dass zu viele der Freiwilligen den Raum während der Tests verlassen haben und dadurch die Ergebnisse verfälscht haben. Wir glauben, dass die meisten der Freiwilligen nun bei Apple sind und an ihrer neuen „scratch and sniff“ Oberfläche arbeiten. Es ist ein lustiges, altes Geschäft, in dem wir uns befinden!

Ernsthaft, FreeBSD benutzt die Instruktion HLT (halt), wenn das System untätig ist, wodurch der Energieverbrauch und dadurch die produzierte Wärme reduziert wird. Falls Sie auch ACPI (Advanced Configuration and Power Interface) konfiguriert haben, kann FreeBSD die CPU auch in einen Low-Power-Modus bringen.

Q. Gibt es irgend etwas „seltsames“, das FreeBSD tut, wenn der Kernel kompiliert wird, das dazu führt, dass der Speicher ein kratzendes Geräusch macht? Bei der Kompilierung (und auch für einen kurzen Moment nach der Erkennung des Floppy-Laufwerks beim Hochfahren), kommt ein seltsames kratzendes Geräusch von etwas, das die Speicherbänke zu sein scheinen.

A. Ja! In der BSD-Dokumentation finden Sie häufige Verweise auf „Daemons“ und was die meisten Leute nicht wissen, ist, dass diese sich auf echte, nicht-körperlichen Wesen beziehen, die Besitz von Ihrem Computer ergriffen haben. Das kratzende Geräusch, das von Ihrem Speicher kommt, ist in Wirklichkeit hochtöniges Flüstern, das unter den Daemons ausgetauscht wird, während Sie entscheiden, wie Sie die verschiedenen Systemadministrationsaufgaben, am besten erledigen.

Wenn Sie das Geräusch stört, wird ein fdisk /mbr aus DOS sie vertreiben, aber wundern Sie sich nicht, wenn sie feindlich reagieren und versuchen, Sie aufzuhalten. Wenn Sie während der Ausführung zu irgendeinem Zeitpunkt die teuflische Stimme von Bill Gates aus dem eingebauten Lautsprecher kommen hören, laufen Sie weg und sehen Sie sich auf keinen Fall um! Befreit von dem ausgleichenden Einfluss der BSD Dämonen sind die beiden Dämonen von DOS und Windows® oft dazu in der Lage, die totale Kontrolle über Ihre Maschine für die ewige Verdammung Ihrer Seele zurückzuerlangen. Da Sie jetzt die Wahrheit kennen, würden Sie es vorziehen, sich an die Geräusche zu gewöhnen, wenn Sie die Wahl hätten.

Eintausendeinhundertundneunundsechzig:

Dreiundzwanzig, die sich bei -CURRENT beschweren, dass das Licht aus ist;

Vier, die behaupten, dass es sich um ein Konfigurationsproblem handelt und dass solche Dinge wirklich nach -questions gehören;

Drei, die PRs hierzu einreichen, einer von ihnen wird falsch unter doc abgelegt und fristet sein Dasein im Dunkeln;

Einen, der eine ungetestete Glühbirne einreicht, wonach buildworld nicht mehr funktioniert, und sie dann fünf Minuten später wieder herausnimmt;

Acht, die die PR-Erzeuger beschimpfen, weil sie zu ihren PRs keine Patche hinzugefügt haben;

Fünf, die sich darüber beschweren, dass buildworld nicht mehr funktioniert;

Einunddreißig, die antworten, dass es bei ihnen funktioniert und dass sie die Aktualisierung wohl zu einigem ungünstigen Zeitpunkt durchgeführt haben;

Einen, der einen Patch für eine neue Glühbirne an -hackers schickt;

Einen, der sich beschwert, dass es vor drei Jahren Patches hierfür hatte, aber als er sie nach -CURRENT schickte, sind sie einfach ignoriert worden und er hatte schlechte Erfahrungen mit dem PR-System; nebenbei ist die vorgeschlagene Glühbirne nicht reflexiv;

Siebenunddreißig, die schreien, dass Glühbirnen nicht in das Basissystem gehören, dass Committer nicht das Recht haben, solche Dinge durchzuführen, ohne die Gemeinschaft zu konsultieren und WAS GEDENKT -CORE HIER ZU TUN!?

Zweihundert, die sich über die Farbe des Fahrradschuppens beschweren;

Drei, die darauf hinweisen, dass der Patch nicht mit style(9) übereinstimmt;

Siebzehn, die sich beschweren, dass die vorgeschlagene neue Glühbirne der GPL unterliegt;

Fünfhundertundsechsundachtzig, die sich in einen Streit über die vergleichbaren Vorteile der GPL, der BSD-Lizenz, der MIT-Lizenz, der NPL und der persönlichen Hygiene nichtgenannter FSF-Gründer verwickeln;

Sieben, die unterschiedliche Teile des Threads nach -chat und -advocacy weiterleiten;

Einer, der die vorgeschlagene Glühbirne einbaut, obwohl sie dunkler leuchtet, als die alte;

Zwei, die sie wieder ausbauen, und in einer wütenden Nachricht argumentieren, dass FreeBSD besser ganz im Dunkeln dasteht, als mit einer dämmerigen Glühbirne;

Sechsundvierzig, die sich lärmend wegen des Wiederausbaus der dämmerigen Glühbirne streiten und eine Erklärung von -core verlangen;

Elf, die eine kleinere Glühbirne beantragen, damit sie in ihr Tamagotchi passt, falls wir irgendwann beschließen, FreeBSD auf diese Plattform zu portieren;

Dreiundsiebzig, die sich über die SNR auf -hackers und -chat beschweren und aus Protest abmelden;

Dreizehn, die „unsubscribe“, „How do I unsubscribe?“ oder „Please remove me from the list“ gefolgt von der üblichen Fußzeile abschicken;

Einen, der eine funktionierende Glühbirne einbaut, während alle zu beschäftigt damit sind, mit jedem zu streiten, um es zu bemerken;

Einunddreißig, die herausstellen, dass die neue Glühbirne 0,364% heller leuchten würde, wenn sie mit TenDRA kompiliert werden würde (obwohl sie in einen Würfel umgeformt werden müsste) und dass FreeBSD deshalb nach TenDRA, anstatt nach GCC wechseln sollte;

Einen, der sich beschwert, dass bei der neuen Glühbirne die Verkleidung fehlt;

Neun (einschließlich der PR-Ersteller), die fragen „Was ist MFC?“;

Siebenundfünfzig, die sich zwei Wochen, nachdem die Birne gewechselt worden ist, darüber beschweren, dass das Licht aus war.

Nik Clayton <nik@FreeBSD.org> hat hinzugefügt:

Ich habe ziemlich hierüber gelacht.

Und dann dachte ich: „Halt, sollte in dieser Liste nicht irgendwo 'Einer, der es dokumentiert' sein?“

Und dann wurde ich erleuchtet :-)

Thomas Abthorpe <tabthorpe@FreeBSD.org> sagt: „Keine, echte FreeBSD Hacker fürchten sich nicht vor der Dunkelheit!“

Sie werden in einer speziellen Datensenke der CPU in Wärme umgewandelt, die dann über den Kühlkörper und den Lüfter abgeführt wird. Dies ist einer der Gründe für die Kühlung von CPUs; die Anwender gewöhnen sich an die schnelleren Prozessoren, gehen nicht mehr so sorgfältig mit Ihren Daten um und so landen immer mehr Daten in /dev/null, was zur Überhitzung der CPU führt. Wenn Sie /dev/null löschen (was die Datensenke ziemlich sicher abschaltet), wird Ihre CPU zwar nicht mehr so heiß, dafür wird Ihr System aber sehr schnell von den überzähligen Daten überladen und merkwürdige Effekte zeigen. Wenn Sie eine sehr schnell Netzwerkverbindung haben, können Sie Ihre CPU kühlen, indem sie Daten aus /dev/random lesen und in die Weite des Netzwerkes schicken; allerdings besteht hier die Gefahr der Überhitzung von Netzwerk und /. Außerdem dürfte Ihr ISP ziemlich wütend werden, da der größte Teil der Daten von seinen Geräten in Hitze umgewandelt werden wird; da ISPs aber über Klimaanlagen verfügen, sollte das kein großes Problem sein, solange Sie es nicht übertreiben.

Paul Robinson fügt hinzu:

Es gibt andere Mittel und Wege. Wie jeder gute Systemadministrator weiss, gehört es zum guten Ton, einigen Daten zum Bildschirm zu senden, damit die Leuchtkäferchen, die das Bild anzeigen, glücklich sind. Die Leuchtkäferchen werden nach der Farbe Ihrer Hüte (Rot, Grün, oder Blau) unterschieden und sie verstecken bzw. zeigen sich (wobei man die Farbe ihrer Hüte erkennen kann) bei jeder Nahrungsaufnahme. Grafikkarten wandeln Daten in Leuchkäfer-Nahrung um und schicken sie dann zu den Leuchtkäfern - teure Karten erzeugen bessere Nahrung und sorgen so für besseres Verhalten der Leuchtkäfer. Diese brauchen allerdings einen konstanten Stimulus - darum gibt es Bildschirmschoner.

Darum lautet mein Vorschlag, die zufälligen Daten einfach zum Bildschirm zu schicken, damit sie von den Leuchtkäfern verzehrt werden. Dabei entsteht keine Hitze, die Leuchtkäfer bleiben glücklich und man wird seine überflüssigen Daten sehr schnell los, auch wenn der Bildschirm etwas merkwürdig aussieht.

Übrigens: Als Ex-Admin eines großen ISPs, der so seine Probleme mit der Kühlung seines Rechenzentrums hatte, kann ich nur davon abraten, überflüssige Daten einfach in das Netzwerk zu schicken. Die Heinzelmännchen, die die Pakete verteilen und versenden, regen sich darüber ganz furchtbar auf.

Installieren Sie auf dem Rechner Ihres Kollegen games/sl und warten Sie, bis Ihr Kollege unbeabsichtigt sl für ls eingibt.

Lesen Sie das FreeBSD Architecture Handbook.

Allgemeines Wissen über UNIX® kann allerdings in den meisten Fällen auf FreeBSD angewendet werden.

Genauere Informationen finden Sie im Artikel FreeBSD unterstützen. Wir können Hilfe immer gut gebrauchen!

Derzeit existieren drei aktive/halbaktive Zweige im FreeBSD Subversion Repository. In früheren Zweigen ändert sich wenig, daher gibt es nur drei aktive Entwicklungszweige:

HEAD ist keine wirkliche Bezeichnung für einen Zweig. Es ist lediglich eine symbolische Konstante für den aktuellen, nicht verzweigten Entwicklungsstrom, auf den wir uns einfach als -CURRENT beziehen.

Derzeit steht -CURRENT für den 11.X-Entwicklungsstrom. Der 10-STABLE-Zweig (stable/10) wurde von -CURRENT im Januar 2014 und der 9-STABLE-Zweig (stable/9) im September 2011 von -CURRENT abgespalten.

Lesen Sie den Artikel FreeBSD unterstützen.

Und Danke, dass Sie darüber nachdenken!

Hier ist eine typische Kernel-Panic:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x40
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xf014a7e5
stack pointer           = 0x10:0xf4ed6f24
frame pointer           = 0x10:0xf4ed6f28
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 80 (mount)
interrupt mask          =
trap number             = 12
panic: page fault

Bei Meldungen wie dieser, reicht es nicht, sie einfach zu reproduzieren und sie einzusenden. Der Wert des Instruktionszeigers ist wichtig; leider ist er auch konfigurationsabhängig. Mit anderen Worten variieren die Werte abhängig von dem Kernel-Image, das Sie tatsächlich benutzen. Wenn Sie ein GENERIC Kernelimage von einem der Snapshots benutzen, dann ist es für jemand anderen möglich, die fehlerhafte Instruktion herauszufinden, aber wenn Sie einen angepassten Kernel benutzen, können nur Sie uns sagen, wo der Fehler auftrat.

Was Sie tun sollten, ist folgendes:

Wie dem auch sei, der beste Weg, den Grund für eine Panik herauszufinden, ist der, einen Crash-Dump festzuhalten und dann kgdb(1) zu benutzen, um den Stack im Crash-Dump zurückzuverfolgen.

Jedenfalls funktioniert die Methode wie folgt:

Der make(1)-Prozess wird zwei Kernel erstellen: /usr/obj/usr/src/sys/MYKERNEL/kernel und /usr/obj/usr/src/sys/MYKERNEL/kernel.debug. kernel wurde als /boot/kernel installiert, während kernel.debug als Quelle für Debuggersymbole für kgdb(1) benutzt werden kann.

Damit ein Crash-Dump erhalten bleibt, müssen Sie /etc/rc.config editieren und dumpdev so setzen, dass es entweder auf die Swap-Partition, oder auf AUTO zeigt. Das bewirkt, dass die rc(8)-Skripte den Befehl dumpon(8) benutzen, um Crash-Dumps zu ermöglichen. Sie können den Befehl auch manuell ausführen. Nach einer Panik kann der Crash-Dump mit savecore(8) wiederhergestellt werden; wenn dumpdev in /etc/rc.conf gesetzt ist, werden die rc(8)-Skripte savecore(8) automatisch ausführen und den Crash-Dump unter /var/crash ablegen.

Sobald der Crash-Dump wiederhergestellt wurde, können Sie den Stack zurückverfolgen:

% kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0
(kgdb) backtrace

Beachten Sie, dass es mehrere Seiten mit wertvollen Informationen geben könnte; idealerweise sollten Sie script(1) benutzen, um sie alle festzuhalten. Wenn Sie das vollständige Kernelimage mit allen Debugginginformationen benutzen, müssten Sie exakt die Zeile des Kernel-Quellcodes finden, wo die Panik aufgetreten ist. Für gewöhnlich müssen Sie den Stack von unten an zurückverfolgen, um die genaue Ereignisabfolge, die zum Crash führte, zurückzuverfolgen. Sie können kgdb(1) auch zum Ausdrucken der Inhalte verschiedener Variablen oder Strukturen benutzen, um den Systemstatus zum Zeitpunkt des Absturzes zu untersuchen.

Die ELF-Werkzeuge machen die in einem Executable definierten Symbole dem dynamischen Linker nicht standardmäßig sichtbar. Konsequenterweise werden dlsym()-Suchen nach Handlern aus Aufrufen von dlopen(NULL, flags) diese Symbole nicht finden können.

Wenn Sie mit dlsym() nach im Hauptexecutable eines Prozesses vorhandenen Symbolen suchen wollen, müssen Sie das Executable mit der Option --export-dynamic von ld(1) linken.

Standardmäßig beträgt der Adressraum des Kernels 1 GB (2 GB für PAE) auf i386. Wenn Sie einen netzwerkintensiven Server oder ZFS verwenden möchten, kann es sein, dass dies nicht ausreichend ist.

Fügen Sie die folgende Zeile zur Kernelkonfigurationsdatei hinzu, um den verfügbaren Speicher zu erhöhen und erstellen Sie dann einen neuen Kernel:

options KVA_PAGES=N

Um den richtigen Wert von N zu bestimmen, teilen Sie den gewünschte Größe des Adressraumes (in Megabyte) durch vier (z.B. beträgt er 512 für 2 GB).