Index: head/de_DE.ISO8859-1/books/handbook/config/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/config/chapter.xml (revision 48476) +++ head/de_DE.ISO8859-1/books/handbook/config/chapter.xml (revision 48477) @@ -1,3691 +1,3648 @@ Konfiguration und Tuning Chern Lee Geschrieben von Mike Smith Nach einem Tutorium von Matt Dillon Basiert ebenfalls auf tuning(7) von Martin Heinen Übersetzt von Übersicht System-Konfiguration System-Optimierung Die richtige Systemkonfiguration ist einer der wichtigsten Aspekte unter &os;. Dieses Kapitel beschreibt die Konfiguration von &os; sowie Maßnahmen zur Leistungssteigerung von &os;-Systemen. Nachdem Sie dieses Kapitel durchgearbeitet haben, werden Sie Folgendes wissen: Die Grundlagen der Konfiguration von rc.conf und die Skripte zum Starten von Anwendungen in /usr/local/etc/rc.d. Wie Sie Netzwerkkarten konfigurieren und testen. Wie Sie virtuelle Hosts und Netzwerkgeräte konfigurieren. Wie Sie die verschiedenen Konfigurationsdateien in /etc benutzen. Wie Sie mit &os; mit &man.sysctl.8;-Variablen einstellen können. Wie Sie die Platten-Performance einstellen und Kernel-Parameter modifizieren können. Bevor Sie dieses Kapitel lesen, sollten Sie die Grundlagen von &unix; und &os; () verstehen. Damit vertraut sein, wie Sie einen Kernel konfigurieren und kompilieren (). - - - - Konfiguration von Anwendungen - - Installierte Anwendungen haben typischerweise - eigene Konfigurationsdateien mit einer eigenen Syntax. Damit - diese Dateien leicht von der Paketverwaltung gefunden und - verwaltet werden können, ist es wichtig, sie vom Basissystem zu - trennen. - - /usr/local/etc - - Für gewöhnlich werden diese Dateien in - /usr/local/etc installiert. Besitzt - eine Anwendung viele Konfigurationsdateien, werden diese in - einem separaten Unterverzeichnis abgelegt. - - Wenn ein Port oder ein Paket installiert wird, werden - normalerweise auch Beispiele für die Konfigurationsdateien - installiert. Diese erkennt man gewöhnlich an dem Suffix - .sample. Wenn keine Konfigurationsdateien - für eine Anwendung existieren, werden sie durch Kopieren der - .sample Dateien erstellt. - - Als Beispiel sei - /usr/local/etc/apache gezeigt: - - -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf --rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default --rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf --rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default --rw-r--r-- 1 root wheel 12205 May 20 1998 magic --rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default --rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types --rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default --rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf --rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default - - Anhand der Dateigröße erkennen Sie, dass sich nur - srm.conf geändert hat. Eine spätere - Aktualisierung des Apache-Ports - überschreibt diese Datei nicht. Start von Diensten Tom Rhodes Beigetragen von Dienste Viele Benutzer installieren Software Dritter auf &os; mithilfe der Ports-Sammlung. Häufig soll die Software bei einem Systemstart mitgestartet werden. Beispielsweise sollen die Dienste mail/postfix oder www/apache22 nach einem Systemstart laufen. Dieser Abschnitt stellt die Startprozeduren für Software Dritter vor. Unter &os; werden die meisten der im System enthaltenen Dienste wie &man.cron.8; mithilfe von Systemskripten gestartet. Dienste über das <filename>rc.d</filename>-System starten Mit rc.d lässt sich der Start von Anwendungen besser steuern und es sind mehr Funktionen verfügbar. Mit den in besprochenen Schlüsselwörtern können Anwendungen in einer bestimmten Reihenfolge gestartet werden und Optionen können in rc.conf statt fest im Startskript der Anwendung festgelegt werden. Ein einfaches Startskript sieht wie folgt aus: #!/bin/sh # # PROVIDE: utility # REQUIRE: DAEMON # KEYWORD: shutdown . /etc/rc.subr name=utility rcvar=utility_enable command="/usr/local/sbin/utility" load_rc_config $name # # DO NOT CHANGE THESE DEFAULT VALUES HERE # SET THEM IN THE /etc/rc.conf FILE # utility_enable=${utility_enable-"NO"} pidfile=${utility_pidfile-"/var/run/utility.pid"} run_rc_command "$1" Dieses Skript stellt sicher, dass utility nach den DAEMON-Pseudodiensten gestartet wird. Es stellt auch eine Methode bereit, die Prozess-ID (PID) der Anwendung in einer Datei zu speichern. In /etc/rc.conf könnte für diese Anwendung die folgende Zeile stehen: utility_enable="YES" Die Methode erleichtert den Umgang mit Kommandozeilenargumenten, bindet Funktionen aus /etc/rc.subr ein, ist kompatibel zu &man.rcorder.8; und lässt sich über rc.conf leichter konfigurieren. Andere Arten, um Dienste zu starten Andere Dienste können über &man.inetd.8; gestartet werden. Die Konfiguration von &man.inetd.8; wird in ausführlich beschrieben. Systemdienste können auch mit &man.cron.8; gestartet werden. Dieser Ansatz hat einige Vorteile; nicht zuletzt, weil &man.cron.8; die Prozesse unter dem Eigentümer der crontab startet, ist es möglich, dass Dienste von normalen Benutzern gestartet und gepflegt werden können. Für die Zeitangabe in &man.cron.8; kann @reboot eingesetzt werden. Damit wird das Kommando gestartet, wenn &man.cron.8; kurz nach dem Systemboot gestartet wird. &man.cron.8; konfigurieren Tom Rhodes Beigetragen von cron konfigurieren Ein sehr nützliches Werkzeug von &os; ist cron. Dieses Programm läuft im Hintergrund und überprüft fortlaufend /etc/crontab und /var/cron/tabs. In diesen Dateien wird festgelegt, welche Programme zu welchem Zeitpunkt von cron ausgeführt werden sollen. Das Werkzeug verwendet zwei verschiedene Konfigurationsdateien: die System-crontab und die Benutzer-crontabs. Der einzige Unterschied zwischen beiden Formaten ist das sechste Feld. In der System-crontab gibt das sechste Feld den Benutzer an, mit dem cron das Kommando ausführen wird. In einer Benutzer-crontab werden alle Kommandos unter dem Benutzer ausgeführt, welcher die crontab erstellt hat. Hier ist das sechste Feld das letzte Feld. Dies ist ein wichtiges Sicherheitsmerkmal. Das letzte Feld bezeichnet immer das Kommando, das ausgeführt werden soll. Benutzer können mit Benutzer-crontabs ohne root-Rechte Befehle terminieren. Die Kommandos in Benutzer-crontabs laufen unter dem Benutzer, der die crontab erstellt hat. Der Benutzer root kann, wie jeder andere Benutzer, eine Benutzer-crontab besitzen. Die Benutzer-crontab von root ist nicht mit /etc/crontab, der System-crontab, zu verwechseln. Da die System-crontab die angegebenen Kommandos effektiv als root-Benutzer aufruft, besteht normalerweise keine Notwendigkeit eine eigene Benutzer-crontab für root zu erstellen. Hier ist ein Beispieleintrag aus der System-crontab, /etc/crontab: # /etc/crontab - root's crontab for FreeBSD # #$FreeBSD$ # # SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin # # #minute hour mday month wday who command # */5 * * * * root /usr/libexec/atrun Das Zeichen # am Zeilenanfang leitet, wie in den meisten Konfigurationsdateien, einen Kommentar ein. Benutzen Sie Kommentare, um die Funktion eines Eintrags zu erläutern. Kommentare müssen in einer extra Zeile stehen. Sie können nicht in derselben Zeile wie ein Kommando stehen, da sie sonst Teil des Kommandos wären. Leerzeilen in dieser Datei werden ignoriert. Umgebungsvariablen werden mit dem Gleichheits-Zeichen (=) festgelegt. Im Beispiel werden die Variablen SHELL, PATH und HOME definiert. Wenn die Variable SHELL nicht definiert wird, benutzt cron die Bourne Shell. Wird die Variable PATH nicht gesetzt, müssen alle Pfadangaben absolut sein, da es keinen Vorgabewert für PATH gibt. In dieser Zeile werden sieben Felder beschrieben: minute, hour, mday, month, wday, who und command. Die ersten Felder legen den Zeitpunkt fest, an dem ein Kommando laufen soll. Das Feld minute legt die Minute fest, das Feld hour die Stunde, das Feld mday den Tag des Monats. Im Feld month wird der Monat und im Feld wday der Wochentag festgelegt. Alle Felder müssen numerische Werte enthalten und die Zeitangaben sind im 24-Stunden-Format. Das Zeichen * repräsentiert dabei alle möglichen Werte für dieses Feld. Das Feld who gibt es nur in der Datei /etc/crontab und gibt den Account an, unter dem das Kommando laufen soll. Im letzten Feld wird schließlich das auszuführende Kommando angegeben. Diese Zeile definiert die Zeitpunkte an denen atrun laufen soll. Dieses Beispiel verwendet die Zeichenfolge */5 gefolgt von mehreren *-Zeichen. Das Zeichen * ist ein Platzhalter und steht für jede mögliche Zeit. Diese Zeile führt /usr/libexec/atrun unter dem root-Account alle fünf Minuten aus. Bei den Kommandos können beliebige Optionen angegeben werden. Wenn das Kommando zu lang ist und auf der nächsten Zeile fortgesetzt werden soll, muss am Ende der Zeile das Fortsetzungszeichen (\) angegeben werden. Bis auf das sechste Feld, das den Account angibt, sieht jede &man.crontab.5; so wie das Beispiel aus. Das sechste Feld existiert nur in der System-crontab. In den restlichen &man.crontab.5;-Dateien fehlt dieses Feld. <filename>crontab</filename> installieren Die nachstehende Prozedur gilt nur für Benutzer-crontabs. Die System-crontab kann mit einem Editor bearbeitet werden. cron bemerkt, dass sich die Datei geändert hat und wird die neue Version benutzen. Lesen Sie bitte auch die FAQ zur Meldung root: not found. Eine Benutzer-crontab, beispielsweise die Datei crontab-datei, können Sie mit jedem Editor erstellen. Die Benutzer-crontab installieren Sie mit dem nachstehenden Befehl: &prompt.root; crontab crontab-datei Das Argument zum Befehl &man.crontab.5; ist die vorher erstellte crontab-datei. Der Befehl crontab -l zeigt die installierte crontab-Datei an. Benutzer, die eine eigene crontab-Datei ohne Vorlage erstellen wollen, können den Befehl crontab -e verwenden. Dieser Befehl ruft einen Editor auf und installiert beim Verlassen des Editors die crontab-Datei. Wollen Sie die installierte Benutzer-crontab entfernen, rufen Sie den crontab -r. Dienste unter &os; verwalten Tom Rhodes Beigetragen von &os; verwendet die vom &man.rc.8;-System bereit gestellten Startskripten beim Systemstart und für die Verwaltung von Diensten. Die Skripte sind in /etc/rc.d abgelegt und bieten grundlegende Dienste an, die über die Optionen , und des &man.service.8; Kommandos kontrolliert werden können. Beispielsweise kann &man.sshd.8; mit dem nachstehenden Kommando neu gestartet werden: &prompt.root; service sshd restart Analog können Sie andere Dienste starten und stoppen. Normalerweise werden die Dienste beim Systemstart über Einträge in der Datei &man.rc.conf.5; automatisch gestartet. &man.natd.8; wird zum Beispiel mit dem folgenden Eintrag in /etc/rc.conf aktiviert: natd_enable="YES" Wenn dort bereits die Zeile existiert, ändern Sie in . Die &man.rc.8;-Skripten starten, wie unten beschrieben, auch abhängige Dienste. Da das &man.rc.8;-System primär zum automatischen Starten und Stoppen von Systemdiensten dient, funktionieren die Optionen , und nur, wenn die entsprechenden Variablen in /etc/rc.conf gesetzt sind. Beispielsweise funktioniert sshd restart nur dann, wenn in /etc/rc.conf die Variable sshd_enable auf gesetzt wurde. Wenn Sie die Optionen , oder unabhängig von den Einstellungen in /etc/rc.conf benutzen wollen, müssen Sie den Optionen mit dem Präfix one verwenden. Um beispielsweise sshd unabhängig von den Einstellungen in /etc/rc.conf neu zu starten, benutzen Sie das nachstehende Kommando: &prompt.root; service sshd onerestart Ob ein Dienst in /etc/rc.conf aktiviert ist, können Sie herausfinden, indem Sie das entsprechende &man.rc.8;-Skript mit der Option aufrufen. Dieses Beipiel prüft, ob der sshd-Dienst in /etc/rc.conf aktiviert ist: &prompt.root; service sshd rcvar # sshd # sshd_enable="YES" # (default: "") Die Zeile # sshd wird von dem Kommando ausgegeben; sie kennzeichnet nicht die Eingabeaufforderung von root. Ob ein Dienst läuft, kann mit abgefragt werden. Das folgende Kommando überprüft, ob sshd auch wirklich gestartet wurde: &prompt.root; service sshd status sshd is running as pid 433. Einige Dienste können über die Option neu initialisiert werden. Dazu wird dem Dienst über ein Signal mitgeteilt, dass er seine Konfigurationsdateien neu einlesen soll. Oft wird dazu das Signal SIGHUP verwendet. Beachten Sie aber, dass nicht alle Dienste diese Option unterstützen. Die meisten Systemdienste werden beim Systemstart vom &man.rc.8;-System gestartet. Zum Beispiel aktiviert das Skript /etc/rc.d/bgfsck die Prüfung von Dateisystemen im Hintergrund. Das Skript gibt die folgende Meldung aus, wenn es gestartet wird: Starting background file system checks in 60 seconds. Dieses Skript wird während des Systemstarts ausgeführt und führt eine Überprüfung der Dateisysteme im Hintergrund durch. Viele Systemdienste hängen von anderen Diensten ab. &man.yp.8; und andere RPC-basierende Systeme hängen beispielsweise von dem rpcbind-Dienst ab. Im Kopf der Startskripten befinden sich die Informationen über Abhängigkeiten von anderen Diensten und weitere Metadaten.Mithilfe dieser Daten bestimmt das Programm &man.rcorder.8; beim Systemstart die Startreihenfolge der Dienste. Folgende Schlüsselwörter müssen im Kopf aller Startskripten verwendet werden, da sie von &man.rc.subr.8; zum Aktivieren des Startskripts benötigt werden: PROVIDE: Gibt die Namen der Dienste an, die mit dieser Datei zur Verfügung gestellt werden. Die folgenden Schlüsselwörter können im Kopf des Startskripts angegeben werden. Sie sind zwar nicht unbedingt notwendig, sind aber hilfreich beim Umgang mit &man.rcorder.8;: REQUIRE: Gibt die Namen der Dienste an, von denen dieser Dienst abhängt. Ein Skript, das dieses Schlüsselwort enthält wird nach den angegebenen Diensten ausgeführt. BEFORE: Zählt Dienste auf, die auf diesen Dienst angewiesen sind. Ein Skript, dass dieses Schlüsselwort enthält wird vor den angegebenen Diensten ausgeführt. Durch das Verwenden dieser Schlüsselwörter kann ein Administrator die Startreihenfolge von Systemdiensten feingranuliert steuern, ohne mit den Schwierigkeiten des runlevel-Systems anderer &unix; Systeme kämpfen zu müssen. Weitere Informationen über das &man.rc.8;-System finden Sie in &man.rc.8; und &man.rc.subr.8;. Wenn Sie eigene rc.d-Skripte schreiben wollen, sollten Sie diesen Artikel lesen. Systemspezifische Konfiguration rc-Dateien rc.conf Informationen zur Systemkonfiguration sind hauptsächlich in /etc/rc.conf, die meist beim Start des Systems verwendet wird, abgelegt. Sie enthält die Konfigurationen für die rc* Dateien. In rc.conf werden die Vorgabewerte aus /etc/defaults/rc.conf überschrieben. Die Vorgabedatei sollte nicht editiert werden. Stattdessen sollten alle systemspezifischen Änderungen in rc.conf vorgenommen werden. Um den administrativen Aufwand gering zu halten, existieren in geclusterten Anwendungen mehrere Strategien, globale Konfigurationen von systemspezifischen Konfigurationen zu trennen. Der empfohlene Weg hält die globale Konfiguration in einer separaten Datei z.B. /etc/rc.conf.local. Zum Beispiel so: /etc/rc.conf: sshd_enable="YES" keyrate="fast" defaultrouter="10.1.1.254" /etc/rc.conf.local: hostname="node1.example.org" ifconfig_fxp0="inet 10.1.1.1/8" /etc/rc.conf kann dann auf jedes System mit rsync oder puppet verteilt werden, während /etc/rc.conf.local dabei systemspezifisch bleibt. Bei einem Upgrade des Systems mit &man.sysinstall.8; oder make world wird /etc/rc.conf nicht überschrieben, so dass die Systemkonfiguration erhalten bleibt. /etc/rc.conf wird von &man.sh.1; gelesen. Dies erlaubt es dem Systemadministrator, komplexe Konfigurationsszenarien zu erstellen. Lesen Sie &man.rc.conf.5;, um weitere Informationen zu diesem Thema zu erhalten. Einrichten von Netzwerkkarten Marc Fonvieille Beigetragen von Netzwerkkarten einrichten Die Konfiguration einer Netzwerkkarte gehört zu den alltäglichen Aufgaben eines &os; Administrators. Bestimmen des richtigen Treibers Netzwerkkarten Treiber Ermitteln Sie zunächst das Modell der Netzwerkkarte und den darin verwendeten Chip. &os; unterstützt eine Vielzahl von Netzwerkkarten. Prüfen Sie die Hardware-Kompatibilitätsliste für das &os; Release, um zu sehen ob die Karte unterstützt wird. Wenn die Karte unterstützt wird, müssen Sie den Treiber für die Karte bestimmen. /usr/src/sys/conf/NOTES und /usr/src/sys/arch/conf/NOTES enthalten eine Liste der verfügbaren Treiber mit Informationen zu den unterstützten Chipsätzen. Wenn Sie sich nicht sicher sind, ob Sie den richtigen Treiber ausgewählt haben, lesen Sie die Hilfeseite des Treibers. Sie enthält weitere Informationen über die unterstützten Geräte und bekannte Einschränkungen des Treibers. Die Treiber für gebräuchliche Netzwerkkarten sind schon im GENERIC-Kernel enthalten, so dass die Karte während des Systemstarts erkannt werden sollte. In diesem Beispiel findet das System zwei Karten, die den &man.dc.4;-Treiber benutzen: dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38 000ff irq 15 at device 11.0 on pci0 miibus0: <MII bus> on dc0 bmtphy0: <BCM5201 10/100baseTX PHY> PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:a0:cc:da:da:da dc0: [ITHREAD] dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30 000ff irq 11 at device 12.0 on pci0 miibus1: <MII bus> on dc1 bmtphy1: <BCM5201 10/100baseTX PHY> PHY 1 on miibus1 bmtphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: Ethernet address: 00:a0:cc:da:da:db dc1: [ITHREAD] Ist der Treiber für die Netzwerkkarte nicht in GENERIC enthalten, muss zunächst ein Treiber geladen werden, um die Karte konfigurieren und benutzen zu können. Dafür gibt es zwei Methoden: Am einfachsten ist es, das Kernelmodul für die Karte mit &man.kldload.8; zu laden. Um den Treiber automatisch beim Systemstart zu laden, fügen Sie die entsprechende Zeile in /boot/loader.conf ein. Es gibt nicht für alle Karten Kernelmodule. Alternativ kann der Treiber für die Karte fest in den Kernel eingebunden werden. Lesen Sie dazu /usr/src/sys/conf/NOTES, /usr/src/sys/arch/conf/NOTES und die Hilfeseite des Treibers, den Sie in den Kernel einbinden möchten, an. Die Übersetzung des Kernels wird in beschrieben. Wenn die Karte während des Systemstarts vom Kernel erkannt wurde, muss der Kernel nicht neu übersetzt werden. &windows;-<acronym>NDIS</acronym>-Treiber einsetzen NDIS NDISulator &windows;-Treiber µsoft.windows; Gerätetreiber KLD (kernel loadable object) Leider stellen nach wie vor viele Unternehmen die Spezifikationen ihrer Treiber der Open Source Gemeinde nicht zur Verfügung, weil sie diese Informationen als Geschäftsgeheimnisse betrachten. Daher haben die Entwickler von &os; und anderen Betriebssystemen nur zwei Möglichkeiten. Entweder versuchen sie in einem aufwändigen Prozess den Treiber durch Reverse Engineering nachzubauen, oder sie versuchen, die vorhandenen Binärtreiber der µsoft.windows;-Plattform zu verwenden. &os; bietet native Unterstützung für die Network Driver Interface Specification (NDIS). &man.ndisgen.8; wird benutzt, um einen &windowsxp;-Treiber in ein Format zu konvertieren, das von &os; verwendet werden kann. Da der &man.ndis.4;-Treiber einen &windowsxp;-Binärtreiber nutzt, kann er nur auf &i386;- und amd64-Systemen verwendet werden. Unterstützt werden PCI, CardBus, PCMCIA und USB-Geräte. Um den NDISulator zu verwenden, benötigen Sie drei Dinge: Die &os; Kernelquellen Den &windowsxp;-Binärtreiber mit der Erweiterung .SYS Die Konfigurationsdatei des &windowsxp;-Treibers mit der Erweiterung .INF Laden Sie die .SYS- und .INF-Dateien für die Karte. Diese befinden sich meistens auf einer beigelegten CD-ROM, oder können von der Internetseite des Herstellers heruntergeladen werden. In den folgenden Beispielen werden die Dateien W32DRIVER.SYS und W32DRIVER.INF verwendet. Die Architektur des Treibers muss zur jeweiligen Version von &os; passen. Benutzen Sie einen &windows; 32-bit Treiber für &os;/i386. Für &os;/amd64 wird ein &windows; 64-bit Treiber benötigt. Als Nächstes kompilieren Sie den binären Treiber, um ein Kernelmodul zu erzeugen. Dazu rufen Sie als root &man.ndisgen.8; auf: &prompt.root; ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS Dieses Kommando arbeitet interaktiv, benötigt es weitere Informationen, so fragt es Sie danach. Das Ergebnis ist ein neu erzeugtes Kernelmodul im aktuellen Verzeichnis. Benutzen Sie &man.kldload.8; um das neue Modul zu laden: &prompt.root; kldload ./W32DRIVER.ko Neben dem erzeugten Kernelmodul müssen auch die Kernelmodule ndis.ko und if_ndis.ko geladen werden. Dies passiert automatisch, wenn Sie ein von &man.ndis.4; abhängiges Modul laden. Andernfalls können die Module mit den folgenden Kommandos manuell geladen werden: &prompt.root; kldload ndis &prompt.root; kldload if_ndis Der erste Befehl lädt den &man.ndis.4;-Miniport-Treiber, der zweite das tatsächliche Netzwerkgerät. Überprüfen Sie die Ausgabe von &man.dmesg.8; auf eventuelle Fehler während des Ladevorgangs. Gab es dabei keine Probleme, sollte die Ausgabe wie folgt aussehen: ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps Ab jetzt kann das Gerät ndis0 wie jede andere Netzwerkkarte konfiguriert werden. Um die &man.ndis.4;-Module automatisch beim Systemstart zu laden, kopieren Sie das erzeugte Modul W32DRIVER_SYS.ko nach /boot/modules. Danach fügen Sie die folgende Zeile in /boot/loader.conf ein: W32DRIVER_SYS_load="YES" Konfiguration von Netzwerkkarten Netzwerkkarten einrichten Nachdem der richtige Treiber für die Karte geladen ist, muss die Karte konfiguriert werden. Unter Umständen ist die Karte schon während der Installation mit &man.bsdinstall.8; konfiguriert worden. Das nachstehende Kommando zeigt die Konfiguration der Netzwerkkarten an: &prompt.user; ifconfig dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX <full-duplex>) status: active dc1: flags=8802<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:db inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet 10baseT/UTP status: no carrier lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3<PERFORMNUD,ACCEPT_RTADV> Im Beispiel werden Informationen zu den folgenden Geräten angezeigt: dc0: Der erste Ethernet-Adapter. dc1: Der zweite Ethernet-Adapter. lo0: Das Loopback-Gerät. Der Name der Netzwerkkarte wird aus dem Namen des Treibers und einer Zahl zusammengesetzt. Die Zahl gibt die Reihenfolge an, in der die Geräte beim Systemstart erkannt wurden. Die dritte Karte, die den &man.sis.4; Treiber benutzt, würde beispielsweise sis2 heißen. Der Adapter dc0 aus dem Beispiel ist aktiv. Sie erkennen das an den folgenden Hinweisen: UP bedeutet, dass die Karte konfiguriert und aktiv ist. Der Karte wurde die Internet-Adresse (inet) 192.168.1.3 zugewiesen. Die Subnetzmaske ist richtig (0xffffff00 entspricht 255.255.255.0). Die Broadcast-Adresse 192.168.1.255 ist richtig. Die MAC-Adresse der Karte (ether) lautet 00:a0:cc:da:da:da. Die automatische Medienerkennung ist aktiviert (media: Ethernet autoselect (100baseTX <full-duplex>)). Der Adapter dc1 benutzt das Medium 10baseT/UTP. Weitere Informationen über die einstellbaren Medien entnehmen Sie der Hilfeseite des Treibers. Der Verbindungsstatus (status) ist active, das heißt es wurde ein Trägersignal entdeckt. Für dc1 wird status: no carrier angezeigt. Das ist normal, wenn kein Kabel an der Karte angeschlossen ist. Wäre die Karte nicht konfiguriert, würde die Ausgabe von &man.ifconfig.8; so aussehen: dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether 00:a0:cc:da:da:da media: Ethernet autoselect (100baseTX <full-duplex>) status: active Die Karte muss als Benutzer root konfiguriert werden. Die Konfiguration kann auf der Kommandozeile mit &man.ifconfig.8; erfolgen. Allerdings gehen diese Informationen bei einem Neustart verloren. Tragen Sie stattdessen die Konfiguration in /etc/rc.conf ein. Fügen Sie für jede Karte im System eine Zeile hinzu, wie in diesem Beispiel zu sehen: ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0" ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP" Ersetzen Sie dc0 und dc1 und die IP-Adressen durch die richtigen Werte für das System. Die Manualpages des Treibers und &man.ifconfig.8; enthalten weitere Einzelheiten über verfügbare Optionen. Die Syntax von /etc/rc.conf wird in &man.rc.conf.5; beschrieben. Wenn das Netz während der Installation konfiguriert wurde, existieren vielleicht schon Einträge für die Netzwerkkarte(n). Überprüfen Sie /etc/rc.conf bevor Sie weitere Zeilen hinzufügen. Wenn das Netzwerk kein DNS benutzt, können Sie in /etc/hosts die Namen und IP-Adressen der Rechner des LANs eintragen. Weitere Informationen entnehmen Sie &man.hosts.5; und /usr/share/examples/etc/hosts. Falls kein DHCP-Server zur Verfügung steht, Sie aber Zugang zum Internet benötigen, müssen Sie das Standard-Gateway und die Nameserver manuell konfigurieren: &prompt.root; echo 'defaultrouter="Ihr_Default_Gateway"' >> /etc/rc.conf &prompt.root; echo 'nameserver Ihr_DNS_Server' >> /etc/resolv.conf Test und Fehlersuche Nachdem die notwendigen Änderungen in /etc/rc.conf gespeichert wurden, kann das System neu gestartet werden, um die Konfiguration zu testen und zu überprüfen, ob das System ohne Fehler neu gestartet wurde. Alternativ können Sie mit folgenden Befehl die Netzwerkeinstellungen neu initialisieren: &prompt.root; service netif restart Falls in /etc/rc.conf ein Default-Gateway definiert wurde, müssen Sie auch den folgenden Befehl ausführen: &prompt.root; service routing restart Wenn das System gestartet ist, sollten Sie die Netzwerkkarten testen. Test der Ethernet-Karte Netzwerkkarten testen Um zu prüfen, ob die Ethernet-Karte richtig konfiguriert ist, testen Sie zunächst mit &man.ping.8; den Adapter selbst und sprechen Sie dann eine andere Maschine im LAN an. Zuerst, der Test des Adapters: &prompt.user; ping -c5 192.168.1.3 PING 192.168.1.3 (192.168.1.3): 56 data bytes 64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms --- 192.168.1.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms &prompt.user; ping -c5 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms Um die Namensauflösung zu testen, verwenden Sie den Namen der Maschine anstelle der IP-Adresse. Wenn kein DNS-Server im Netzwerk vorhanden ist, muss /etc/hosts entsprechend eingerichtet sein. Fehlersuche Netzwerkkarten Fehlersuche Fehler zu beheben, ist immer sehr mühsam. Indem Sie die einfachen Sachen zuerst prüfen, erleichtern Sie sich die Aufgabe. Steckt das Netwerkkabel? Sind die Netzwerkdienste richtig konfiguriert? Funktioniert die Firewall? Wird die Netwerkkarte von &os; unterstützt? Lesen Sie immer die Hardware-Informationen des Releases, bevor Sie einen Fehlerbericht einsenden. Aktualisieren Sie die &os;-Version auf die neueste -STABLE Version. Suchen Sie in den Archiven der Mailinglisten und im Internet nach bekannten Lösungen. Wenn die Karte funktioniert, die Verbindungen aber zu langsam sind, sollten Sie &man.tuning.7; lesen. Prüfen Sie auch die Netzwerkkonfiguration, da falsche Einstellungen die Ursache für langsame Verbindungen sein können. Wenn Sie viele device timeout Meldungen in den Systemprotokollen finden, prüfen Sie, dass es keinen Konflikt zwischen der Netzwerkkarte und anderen Geräten des Systems gibt. Überprüfen Sie nochmals die Verkabelung. Unter Umständen benötigen Sie eine andere Netzwerkkarte. Bei watchdog timeout Fehlermeldungen, kontrollieren Sie zuerst die Verkabelung. Überprüfen Sie dann, ob der PCI-Steckplatz der Karte Bus Mastering unterstützt. Auf einigen älteren Motherboards ist das nur für einen Steckplatz (meistens Steckplatz 0) der Fall. Lesen Sie in der Dokumentation der Karte und des Motherboards nach, ob das vielleicht die Ursache des Problems sein könnte. Die Meldung No route to host erscheint, wenn das System ein Paket nicht zustellen kann. Das kann vorkommen weil beispielsweise keine Default-Route gesetzt wurde oder das Netzwerkkabel nicht richtig steckt. Schauen Sie in der Ausgabe von netstat -rn nach, ob eine gültige Route zu dem Zielsystem existiert. Wenn nicht, lesen Sie . Die Meldung ping: sendto: Permission denied wird oft von einer falsch konfigurierten Firewall verursacht. Wenn keine Regeln definiert wurden, blockiert eine aktivierte Firewall alle Pakete, selbst einfache &man.ping.8;-Pakete. Weitere Informationen erhalten Sie in . Falls die Leistung der Karte schlecht ist, setzen Sie die Medienerkennung von autoselect (automatisch) auf das richtige Medium. In vielen Fällen löst diese Maßnahme Leistungsprobleme. Wenn nicht, prüfen Sie nochmal die Netzwerkeinstellungen und lesen Sie &man.tuning.7;. Virtual Hosts virtual hosts IP-Aliase Ein gebräuchlicher Zweck von &os; ist das virtuelle Hosting, bei dem ein Server im Netzwerk wie mehrere Server aussieht. Dies wird dadurch erreicht, dass einem Netzwerkinterface mehrere Netzwerk-Adressen zugewiesen werden. Ein Netzwerkinterface hat eine echte Adresse und kann beliebig viele alias Adressen haben. Die Aliase werden durch entsprechende alias Einträge in /etc/rc.conf festgelegt, wie in diesem Beispiel zu sehen ist: ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx" Beachten Sie, dass die Alias-Einträge mit alias0 anfangen müssen und weiter hochgezählt werden, das heißt alias1, alias2, und so weiter. Die Konfiguration der Aliase hört bei der ersten fehlenden Zahl auf. Die Berechnung der Alias-Netzwerkmasken ist wichtig. Für jedes Interface muss es eine Adresse geben, die die Netzwerkmaske des Netzwerkes richtig beschreibt. Alle anderen Adressen in diesem Netzwerk haben dann eine Netzwerkmaske, die mit 1 gefüllt ist, also 255.255.255.255 oder hexadezimal 0xffffffff. Als Beispiel betrachten wir den Fall, in dem fxp0 mit zwei Netzwerken verbunden ist: dem Netzwerk 10.1.1.0 mit der Netzwerkmaske 255.255.255.0 und dem Netzwerk 202.0.75.16 mit der Netzwerkmaske 255.255.255.240. Das System soll die Adressen 10.1.1.1 bis 10.1.1.5 und 202.0.75.17 bis 202.0.75.20 belegen. Nur die erste Adresse in einem Netzwerk sollte die richtige Netzwerkmaske haben. Alle anderen Adressen (10.1.1.2 bis 10.1.1.5 und 202.0.75.18 bis 202.0.75.20) müssen die Maske 255.255.255.255 erhalten. Die folgenden Einträge in /etc/rc.conf konfigurieren den Adapter entsprechend dem Beispiel: ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" Konfiguration des <application>syslogd</application> Servers Niclas Zeising Beigetragen von system logging syslog &man.syslogd.8; Das Aufzeichnen von Log-Meldungen ist ein wichtiger Aspekt der Systemadministration. Es wird nicht nur verwendet um Hard- und Softwarefehler ausfindig zu machen, auch zur Überwachung der Sicherheit und der Reaktion bei einem Zwischenfall spielen diese Aufzeichnungen eine wichtige Rolle. Systemdienste ohne kontrollierendes Terminal senden Meldungen in der Regel an einen Log-Server, oder schreiben sie in eine Logdatei. Dieser Abschnitt beschreibt die Konfiguration und Verwendung des &os; &man.syslogd.8; Servers, und diskutiert auch die Log-Rotation und das Management von Logdateien mit &man.newsyslog.8;. Der Fokus wird hierbei auf die Einrichtung und Benutzung eines &man.syslogd.8; auf dem lokalen Rechner gelegt. Für erweiterte Einstellungen und die Verwendung eines separaten Log-Servers lesen Sie bitte . Verwendung von <command>syslogd</command> In der Standardkonfiguration von &os; wird &man.syslogd.8; beim Booten automatisch gestartet. Dieses Verhalten wird über die Variable syslogd_enable in /etc/rc.conf gesteuert. Dazu gibt es noch zahlreiche Argumente, die das Verhalten von &man.syslogd.8; beeinflussen. Benutzen Sie zum verändern dieser Argumente syslogd_flags in /etc/rc.conf. Lesen Sie &man.syslogd.8; für weitere Informationen über die Argumente, und &man.rc.conf.5;, und wenn Sie mehr über /etc/rc.conf und das &man.rc.8;-Subsystem wissen möchten. Konfiguration von <command>syslogd</command> syslog.conf Die Konfigurationsdatei /etc/syslog.conf steuert, was &man.syslogd.8; mit Log-Meldungen macht, sobald sie empfangen werden. Es gibt verschiedene Parameter, die das Verhalten bei eingehenden Ereignissen kontrollieren. Zu den grundlegenden gehören facility und level. facility beschreibt das Subsystem, welches das Ereignis generiert hat. Beispielsweise der Kernel, oder ein Daemon. level hingegen beschreibt den Schweregrad des aufgetretenen Ereignisses. Dies macht es möglich, Meldungen in verschiedenen Logdateien zu protokollieren, oder Meldungen zu verwerfen, je nach Konfiguration von facility und level. Ebenfalls besteht die Möglichkeit auf Meldungen zu reagieren, die von einer bestimmten Anwendung stammen, oder von einem spezifischen Host erzeugt wurden. Die Konfigurationsdatei von &man.syslogd.8; enthält für jede Aktion eine Zeile. Die Syntax besteht aus einem Auswahlfeld, gefolgt von einem Aktionsfeld. Die Syntax für das Auswahlfeld ist facility.level. Dies entspricht Log-Meldungen von facility mit einem Level von level oder höher. Um noch präziser festzulegen was protokolliert wird, kann dem Level optional ein Vergleichsflag vorangestellt werden. Mehrere Auswahlen können, durch Semikolon (;) getrennt, für die gleiche Aktion verwendet werden. * wählt dabei alles aus. Das Aktionsfeld definiert, wohin die Log-Meldungen gesendet werden, beispielsweise in eine Datei oder zu einem entfernten Log-Server. Als Beispiel dient hier /etc/syslog.conf aus &os;: # $&os;$ # # Spaces ARE valid field separators in this file. However, # other *nix-like systems still insist on using tabs as field # separators. If you are sharing this file between systems, you$ # may want to use only tabs as field separators here. # Consult the syslog.conf(5) manpage. *.err;kern.warning;auth.notice;mail.crit /dev/console *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog lpr.info /var/log/lpd-errs ftp.info /var/log/xferlog cron.* /var/log/cron !-devd *.=debug /var/log/debug.log *.emerg * # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log # uncomment this to enable logging of all log messages to /var/log/all.log # touch /var/log/all.log and chmod it to mode 600 before it will work #*.* /var/log/all.log # uncomment this to enable logging to a remote loghost named loghost #*.* @loghost # uncomment these if you're running inn # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice # Uncomment this if you wish to see messages produced by devd # !devd # *.>=info !ppp *.* /var/log/ppp.log !* Selektiert alle Meldungen vom Level err, sowie kern.warning, auth.notice und mail.crit und schickt diese zur Konsole (/dev/console). Selektiert alle Meldungen von mail ab dem Level info oder höher und schreibt diese in /var/log/maillog. Diese Zeile benutzt das Vergleichsflag =, um nur Meldungen vom Level debug zu selektieren und schreibt diese in /var/log/debug.log. Hier ist ein Beispiel für die Nutzung einer Programmspezifikation. Die nachfolgenden Regeln sind dann nur für Programme gültig, welche der Programmspezifikation stehen. In diesem Fall landen alle Meldungen von ppp (und keinem anderen Programm) in /var/log/ppp.log. Dieses Beispiel zeigt, dass es jede Menge Level und Subsysteme gibt. Die Level, beginnend mit den höchst kritischen, hin zu den weniger kritischen, sind: emerg, alert, crit, err, warning, notice, info und debug. Die facilities, in beliebiger Reihenfolge, sind: auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, uucp, sowie local0 bis local7. Beachten Sie, dass andere Betriebssysteme hiervon abweichende facilities haben können. Mit diesem Wissen ist es nun einfach, eine weitere Zeile in /etc/syslog.conf hinzuzufügen, welche alle Meldungen von den unterschiedlichsten Dämonen mit einem Level von notice und höher in /var/log/daemon.log. Fügen Sie einfach folgendes hinzu: daemon.notice /var/log/daemon.log Für weitere Informationen zu verschiedenen Level und faclilities, lesen Sie &man.syslog.3; und &man.syslogd.8;. Weitere Informationen zu /etc/syslog.conf, dessen Syntax und erweiterten Anwendungsbeispielen, finden Sie in &man.syslog.conf.5; und . Log-Management und Rotation mit <command>newsyslog</command> newsyslog newsyslog.conf log rotation log management Log-Dateien können schnell wachsen, was viel Speicherplatz verbrauchen kann. Zudem wird es schwieriger, nützliche Informationen schnell zu finden. Log-Management versucht, diesen Effekt zu mildern. &os; verwendet &man.newsyslog.8; für die Verwaltung von Log-Dateien. Dieses Programm rotiert und komprimiert in regelmäßigen Abständen Log-Dateien. Optional kann es auch fehlende Log-Dateien erstellen und Programme benachrichtigen, wenn Log-Dateien verschoben wurden. Dabei müssen die Log-Dateien nicht unbedingt von &man.syslogd.8; stammen, &man.newsyslog.8; ist auch in der Lage, Nachrichten von anderen Programmen zu verarbeiten. Obwohl &man.newsyslog.8; normalerweise von &man.cron.8; aufgerufen wird, ist es kein Systemdämon. In der Standardkonfiguration wird dieser Job jede Stunde ausgeführt. Konfiguration von <command>newsyslog</command> Um zu wissen, welche Maßnahmen zu ergreifen sind, liest &man.newsyslog.8; seine Konfigurationsdatei, standardmäßig /etc/newsyslog.conf. Diese Konfigurationsdatei enthält eine Zeile für jede Datei, die von &man.newsyslog.8; verwaltet wird. Jede Zeile enthält Informationen über den Besitzer der Datei, die Dateiberechtigungen, wann die Datei rotiert wird, optionale Flags, welche die Log-Rotation beeinflussen (bspw. Komprimierung) und Programme, denen ein Signal geschickt wird, wenn Log-Dateien rotiert werden. Hier folgt die Standardkonfiguration in &os;: # configuration file for newsyslog # $&os;$ # # Entries which do not specify the '/pid_file' field will cause the # syslogd process to be signalled when that log file is rotated. This # action is only appropriate for log files which are written to by the # syslogd process (ie, files listed in /etc/syslog.conf). If there # is no process which needs to be signalled when a given log file is # rotated, then the entry for that file should include the 'N' flag. # # The 'flags' field is one or more of the letters: BCDGJNUXZ or a '-'. # # Note: some sites will want to select more restrictive protections than the # defaults. In particular, it may be desirable to switch many of the 644 # entries to 640 or 600. For example, some sites will consider the # contents of maillog, messages, and lpd-errs to be confidential. In the # future, these defaults may change to more conservative ones. # # logfilename [owner:group] mode count size when flags [/pid_file] [sig_num] /var/log/all.log 600 7 * @T00 J /var/log/amd.log 644 7 100 * J /var/log/auth.log 600 7 100 @0101T JC /var/log/console.log 600 5 100 * J /var/log/cron 600 3 100 * JC /var/log/daily.log 640 7 * @T00 JN /var/log/debug.log 600 7 100 * JC /var/log/kerberos.log 600 7 100 * J /var/log/lpd-errs 644 7 100 * JC /var/log/maillog 640 7 * @T00 JC /var/log/messages 644 5 100 @0101T JC /var/log/monthly.log 640 12 * $M1D0 JN /var/log/pflog 600 3 100 * JB /var/run/pflogd.pid /var/log/ppp.log root:network 640 3 100 * JC /var/log/devd.log 644 3 100 * JC /var/log/security 600 10 100 * JC /var/log/sendmail.st 640 10 * 168 B /var/log/utx.log 644 3 * @01T05 B /var/log/weekly.log 640 5 1 $W6D0 JN /var/log/xferlog 600 7 100 * JC Jede Zeile beginnt mit dem Namen der Datei, die rotiert werden soll, optional gefolgt von Besitzer und Gruppe für rotierende, als auch für neu erstellte Dateien. Das Feld mode definiert die Zugriffsrechte der Datei. count gibt an, wie viele rotierte Dateien aufbewahrt werden sollen. Anhand der size- und when-Flags erkennt newsyslog, wann die Datei rotiert werden muss. Eine Logdatei wird rotiert, wenn ihre Größe den Wert von size überschreitet, oder wenn die Zeit im when-Feld abgelaufen ist. Ein * bedeutet, dass dieses Feld ignoriert wird. Das flags-Feld gibt newsyslog weitere Instruktionen, zum Beispiel wie eine Datei zu rotieren ist, oder eine Datei zu erstellen falls diese nicht existiert. Die letzten beiden Felder sind optional und bestimmen die PID-Datei sowie wenn die Datei rotiert wird. Weitere Informationen zu allen Feldern, gültigen flags und wie Sie die Rotationszeit angeben können, finden Sie in &man.syslog.conf.5;. Denken Sie daran, dass newsyslog von cron aufgerufen wird und somit Dateien auch nur dann rotiert, wenn es von &man.cron.8; aufgerufen wird, und nicht häufiger. Konfigurationsdateien <filename>/etc</filename> Layout Konfigurationsdateien finden sich in einigen Verzeichnissen unter anderem in: /etc Enthält generelle systemspezifische Konfigurationsinformationen. /etc/defaults Default Versionen der Konfigurationsdateien. /etc/mail Enthält die &man.sendmail.8; Konfiguration und weitere MTA Konfigurationsdateien. /etc/ppp Hier findet sich die Konfiguration für die User- und Kernel-ppp Programme. /etc/namedb Das Vorgabeverzeichnis, in dem Daten von &man.named.8; gehalten werden. Normalerweise werden hier named.conf und Zonendaten abgelegt. /usr/local/etc Installierte Anwendungen legen hier ihre Konfigurationsdateien ab. Dieses Verzeichnis kann Unterverzeichnisse für bestimmte Anwendungen enthalten. /usr/local/etc/rc.d &man.rc.8;-Skripten installierter Anwendungen. /var/db Automatisch generierte systemspezifische Datenbanken, wie die Paket-Datenbank oder die &man.locate.1;-Datenbank. Hostnamen hostname DNS <filename>/etc/resolv.conf</filename> resolv.conf Wie ein &os;-System auf das Internet Domain Name System (DNS) zugreift, wird in /etc/resolv.conf festgelegt. Die gebräuchlichsten Einträge in /etc/resolv.conf sind: nameserver Die IP-Adresse eines Nameservers, den der Resolver abfragen soll. Bis zu drei Server werden in der Reihenfolge, in der sie aufgezählt sind, abgefragt. search Suchliste mit Domain-Namen zum Auflösen von Hostnamen. Die Liste wird normalerweise durch den Domain-Teil des lokalen Hostnamens festgelegt. domain Der lokale Domain-Name. Beispiel für eine typische /etc/resolv.conf: search example.com nameserver 147.11.1.11 nameserver 147.11.100.30 Nur eine der Anweisungen search oder domain sollte benutzt werden. Wenn Sie DHCP benutzen, überschreibt &man.dhclient.8; für gewöhnlich /etc/resolv.conf mit den Informationen vom DHCP-Server. <filename>/etc/hosts</filename> hosts /etc/hosts ist eine einfache textbasierte Datenbank. Zusammen mit DNS und NIS stellt sie eine Abbildung zwischen Namen und IP-Adressen zur Verfügung. Anstatt &man.named.8; zu konfigurieren, können hier lokale Rechner, die über ein LAN verbunden sind, eingetragen werden. Lokale Einträge für gebräuchliche Internet-Adressen in /etc/hosts verhindern die Abfrage eines externen Servers und beschleunigen die Namensauflösung. # $FreeBSD$ # # # Host Database # # This file should contain the addresses and aliases for local hosts that # share this file. Replace 'my.domain' below with the domainname of your # machine. # # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/nsswitch.conf for the resolution order. # # ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain # # Imaginary network. #10.0.0.2 myname.my.domain myname #10.0.0.3 myfriend.my.domain myfriend # # According to RFC 1918, you can use the following IP networks for # private nets which will never be connected to the Internet: # # 10.0.0.0 - 10.255.255.255 # 172.16.0.0 - 172.31.255.255 # 192.168.0.0 - 192.168.255.255 # # In case you want to be able to connect to the Internet, you need # real official assigned numbers. Do not try to invent your own network # numbers but instead get one from your network provider (if any) or # from your regional registry (ARIN, APNIC, LACNIC, RIPE NCC, or AfriNIC.) # /etc/hosts hat das folgende Format: [Internet Adresse] [Offizieller Hostname] [Alias1] [Alias2] ... Zum Beispiel: 10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2 Weitere Informationen entnehmen Sie bitte &man.hosts.5;. Einstellungen mit &man.sysctl.8; sysctl Einstellungen mit sysctl Mit &man.sysctl.8; können Sie Änderungen an einem laufenden &os;-System vornehmen. Unter anderem können Optionen des TCP/IP-Stacks oder des virtuellen Speichermanagements verändert werden. Unter der Hand eines erfahrenen Systemadministrators kann dies die Systemperformance erheblich verbessern. Über 500 Variablen können mit &man.sysctl.8; gelesen und gesetzt werden. Der Hauptzweck von &man.sysctl.8; besteht darin, Systemeinstellungen zu lesen und zu verändern. Alle auslesbaren Variablen werden wie folgt angezeigt: &prompt.user; sysctl -a Um eine spezielle Variable zu lesen, geben Sie den Namen an: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 Um eine Variable zu setzen, benutzen Sie die Syntax Variable= Wert: &prompt.root; sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000 Mit sysctl können Strings, Zahlen oder Boolean-Werte gesetzt werden. Bei Boolean-Werten steht 1 für wahr und 0 für falsch. Um die Variablen automatisch während des Systemstarts zu setzen, fügen Sie sie in /etc/sysctl.conf ein. Weitere Informationen finden Sie in der Hilfeseite &man.sysctl.conf.5; und in . <filename>sysctl.conf</filename> sysctl.conf sysctl /etc/sysctl.conf sieht ähnlich wie /etc/rc.conf aus. Werte werden in der Form Variable=Wert gesetzt. Die angegebenen Werte werden gesetzt, nachdem sich das System bereits im Mehrbenutzermodus befindet. Allerdings lassen sich im Mehrbenutzermodus nicht alle Werte setzen. Um das Protokollieren von fatalen Signalen abzustellen und Benutzer daran zu hindern, von anderen Benutzern gestartete Prozesse zu sehen, können Sie in /etc/sysctl.conf die folgenden Variablen setzen: # Do not log fatal signal exits (e.g. sig 11) kern.logsigexit=0 # Prevent users from seeing information about processes that # are being run under another UID. security.bsd.see_other_uids=0 Schreibgeschützte Variablen Tom Rhodes Contributed by Wenn schreibgeschützte &man.sysctl.8;-Variablen verändert werden, ist ein Neustart des Systems erforderlich. Beispielsweise hat &man.cardbus.4; auf einigen Laptops Schwierigkeiten, Speicherbereiche zu erkennen. Es treten dann Fehlermeldungen wie die folgende auf: cbb0: Could not map register memory device_probe_and_attach: cbb0 attach returned 12 Um dieses Problem zu lösen, muss eine schreibgeschützte &man.sysctl.8;-Variable verändert werden. Fügen Sie in /boot/loader.conf hinzu und starten Sie das System neu. Danach sollte &man.cardbus.4; fehlerfrei funktionieren. Tuning von Laufwerken Der folgende Abschnitt beschreibt die verschiedenen Methoden zur Feinabstimmung der Laufwerke. Oft sind mechanische Teile in Laufwerken, wie SCSI-Laufwerke, verbaut. Diese können einen Flaschenhals bei der Gesamtleistung des Systems darstellen. Sie können zwar auch ein Laufwerk ohne mechanische Teile einbauen, wie z.B. ein Solid-State-Drive, aber Laufwerke mit mechanischen Teilen werden auch in naher Zukunft nicht vom Markt verschwinden. Bei der Feinabstimmung ist es ratsam, die Funktionen von &man.iostat.8; zu verwenden, um verschiedene Änderungen zu testen und um nützliche IO-Informationen des Systems zu erhalten. Sysctl Variablen <varname>vfs.vmiodirenable</varname> vfs.vmiodirenable Die &man.sysctl.8;-Variable vfs.vmiodirenable besitzt in der Voreinstellung den Wert 1. Die Variable kann auf den Wert 0 (deaktiviert) oder 1 (aktiviert) gesetzt werden. Sie steuert, wie Verzeichnisse vom System zwischengespeichert werden. Die meisten Verzeichnisse sind klein und benutzen nur ein einzelnes Fragment, typischerweise 1 kB, im Dateisystem und 512 Bytes im Buffer-Cache. Ist die Variable deaktiviert, wird der Buffer-Cache nur eine limitierte Anzahl Verzeichnisse zwischenspeichern, auch wenn das System über sehr viel Speicher verfügt. Ist die Variable aktiviert, kann der Buffer-Cache den VM-Page-Cache benutzen, um Verzeichnisse zwischenzuspeichern. Der ganze Speicher steht damit zum Zwischenspeichern von Verzeichnissen zur Verfügung. Der Nachteil bei dieser Vorgehensweise ist, dass zum Zwischenspeichern eines Verzeichnisses mindestens eine physikalische Seite im Speicher, die normalerweise 4 kB groß ist, anstelle von 512 Bytes gebraucht wird. Es wird empfohlen, diese Option aktiviert zu lassen, wenn Sie Dienste zur Verfügung stellen, die viele Dateien manipulieren. Beispiele für solche Dienste sind Web-Caches, große Mail-Systeme oder Netnews. Die aktivierte Variable vermindert, trotz des verschwendeten Speichers, in aller Regel nicht die Leistung des Systems, obwohl Sie das nachprüfen sollten. <varname>vfs.write_behind</varname> vfs.write_behind In der Voreinstellung besitzt die &man.sysctl.8;-Variable vfs.write_behind den Wert 1 (aktiviert). Mit dieser Einstellung schreibt das Dateisystem anfallende vollständige Cluster, die besonders beim sequentiellen Schreiben großer Dateien auftreten, direkt auf das Medium aus. Dies verhindert, dass sich im Buffer-Cache veränderte Puffer (dirty buffers) ansammeln, die die I/O-Verarbeitung nicht mehr beschleunigen würden. Unter bestimmten Umständen blockiert diese Funktion allerdings Prozesse. Setzen Sie in diesem Fall die Variable vfs.write_behind auf den Wert 0. <varname>vfs.hirunningspace</varname> vfs.hirunningspace Die &man.sysctl.8;-Variable vfs.hirunningspace bestimmt systemweit die Menge ausstehender Schreiboperationen, die dem Platten-Controller zu jedem beliebigen Zeitpunkt übergeben werden können. Normalerweise können Sie den Vorgabewert verwenden. Auf Systemen mit vielen Platten kann der Wert aber auf 4 bis 5 Megabyte erhöht werden. Ein zu hoher Wert (größer als der Schreib-Schwellwert des Buffer-Caches) kann zu Leistungverlusten führen. Setzen Sie den Wert daher nicht zu hoch! Hohe Werte können auch Leseoperationen verzögern, die gleichzeitig mit Schreiboperationen ausgeführt werden. Es gibt weitere &man.sysctl.8;-Variablen, mit denen Sie den Buffer-Cache und den VM-Page-Cache beeinflussen können. Es wird nicht empfohlen, diese Variablen zu verändern, da das VM-System den virtuellen Speicher selbst sehr gut verwaltet. <varname>vm.swap_idle_enabled</varname> vm.swap_idle_enabled Die &man.sysctl.8;-Variable vm.swap_idle_enabled ist für große Mehrbenutzer-Systeme gedacht, auf denen sich viele Benutzer an- und abmelden und auf denen es viele Prozesse im Leerlauf (idle) gibt. Solche Systeme fragen kontinuierlich freien Speicher an. Wenn Sie die Variable vm.swap_idle_enabled aktivieren, können Sie die Auslagerungs-Hysterese von Seiten mit den Variablen vm.swap_idle_threshold1 und vm.swap_idle_threshold2 einstellen. Die Schwellwerte beider Variablen geben die Zeit in Sekunden an, in denen sich ein Prozess im Leerlauf befinden muss. Wenn die Werte so eingestellt sind, dass Seiten früher als nach dem normalen Algorithmus ausgelagert werden, verschafft das dem Auslagerungs-Prozess mehr Luft. Aktivieren Sie diese Funktion nur, wenn Sie sie wirklich benötigen: Die Speicherseiten werden eher früher als später ausgelagert. Der Platz im Swap-Bereich wird dadurch schneller verbraucht und die Plattenaktivitäten steigen an. Auf kleinen Systemen hat diese Funktion spürbare Auswirkungen. Auf großen Systemen, die sowieso schon Seiten auslagern müssen, können ganze Prozesse leichter in den Speicher geladen oder ausgelagert werden. <varname>hw.ata.wc</varname> hw.ata.wc Obwohl das Abstellen des IDE-Schreib-Zwischenspeichers die Bandbreite zum Schreiben auf die IDE-Festplatte verringert, kann es aus Gründen der Datenkonsistenz als notwendig angesehen werden. Das Problem ist, dass IDE-Platten keine zuverlässige Aussage über das Ende eines Schreibvorgangs treffen. Wenn der Schreib-Zwischenspeicher aktiviert ist, werden die Daten nicht in der Reihenfolge ihres Eintreffens geschrieben. Es kann sogar passieren, dass das Schreiben mancher Blöcke im Fall von starker Plattenaktivität auf unbefristete Zeit verzögert wird. Ein Absturz oder Stromausfall zu dieser Zeit kann die Dateisysteme erheblich beschädigen. Sie sollten den Wert der &man.sysctl.8;-Variable hw.ata.wc auf dem System überprüfen. Wenn der Schreib-Zwischenspeicher abgestellt ist, können Sie ihn beim Systemstart aktivieren, indem Sie die Variable in /boot/loader.conf auf den Wert 1 setzen. Weitere Informationen finden Sie in &man.ata.4;. <literal>SCSI_DELAY</literal> (<varname>kern.cam.scsi_delay</varname>) kern.cam.scsi_delay Kerneloptionen SCSI DELAY Mit der Kerneloption SCSI_DELAY kann die Dauer des Systemstarts verringert werden. Der Vorgabewert ist recht hoch und er verzögert den Systemstart um 15 oder mehr Sekunden. Normalerweise kann dieser Wert, insbesondere mit modernen Laufwerken, mit der &man.sysctl.8;-Variable kern.cam.scsi_delay auf 5 Sekunden heruntergesetzt werden. Die Variable sowie die Kerneloption verwenden für die Zeitangabe Millisekunden und nicht Sekunden. Soft Updates Soft Updates &man.tunefs.8; Mit &man.tunefs.8; lassen sich Feineinstellungen an Dateisystemen vornehmen. Das Programm hat verschiedene Optionen. Soft Updates werden wie folgt ein- und ausgeschaltet: &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem Ein eingehängtes Dateisystem kann nicht mit &man.tunefs.8; modifiziert werden. Soft Updates werden am besten im Single-User Modus aktiviert, bevor Partitionen eingehangen sind. Durch Einsatz eines Zwischenspeichers wird die Performance im Bereich der Metadaten, vorwiegend beim Anlegen und Löschen von Dateien, gesteigert. Es wird empfohlen, Soft Updates auf allen UFS-Dateisystemen zu aktivieren. Allerdings sollten Sie sich über die zwei Nachteile von Soft Updates bewusst sein: Erstens garantieren Soft Updates zwar die Konsistenz der Daten im Fall eines Absturzes, aber es kann passieren, dass das Dateisystem über mehrere Sekunden oder gar eine Minute nicht synchronisiert wurde. Nicht geschriebene Daten gehen dann vielleicht verloren. Zweitens verzögern Soft Updates die Freigabe von Datenblöcken. Eine größere Aktualisierung eines fast vollen Dateisystems, wie dem Root-Dateisystem, z.B. während eines make installworld, kann das Dateisystem vollaufen lassen. Dadurch würde die Aktualisierung fehlschlagen. Details über Soft Updates Soft Updates Details Bei einem Metadaten-Update werden die Inodes und Verzeichniseinträge aktualisiert auf die Platte zurückgeschrieben. Es gibt zwei klassische Ansätze, um die Metadaten des Dateisystems auf die Platte zu schreiben. Das historisch übliche Verfahren waren synchrone Updates der Metadaten, d. h. wenn eine Änderung an einem Verzeichnis nötig war, wurde anschließend gewartet, bis diese Änderung tatsächlich auf die Platte zurückgeschrieben worden war. Der Inhalt der Dateien wurde im Buffer Cache zwischengespeichert und später asynchron auf die Platte geschrieben. Der Vorteil dieser Implementierung ist, dass sie sicher funktioniert. Wenn während eines Updates ein Ausfall erfolgt, haben die Metadaten immer einen konsistenten Zustand. Eine Datei ist entweder komplett angelegt oder gar nicht. Wenn die Datenblöcke einer Datei im Fall eines Absturzes noch nicht den Weg aus dem Buffer Cache auf die Platte gefunden haben, kann &man.fsck.8; das Dateisystem reparieren, indem es die Dateilänge einfach auf 0 setzt. Außerdem ist die Implementierung einfach und überschaubar. Der Nachteil ist, dass Änderungen der Metadaten sehr langsam vor sich gehen. Ein rm -r beispielsweise fasst alle Dateien eines Verzeichnisses der Reihe nach an, aber jede dieser Änderungen am Verzeichnis (Löschen einer Datei) wird einzeln synchron auf die Platte geschrieben. Gleiches beim Auspacken großer Hierarchien mit tar -x. Der zweite Ansatz sind asynchrone Metadaten-Updates. Das ist der Standard, wenn UFS-Dateisysteme mit mount -o async eingehängt werden. Man schickt die Updates der Metadaten einfach auch noch über den Buffer Cache, sie werden also zwischen die Updates der normalen Daten eingeschoben. Vorteil ist, dass man nun nicht mehr auf jeden Update warten muss, Operationen, die zahlreiche Metadaten ändern, werden also viel schneller. Auch hier ist die Implementierung sehr einfach und wenig anfällig für Fehler. Nachteil ist, dass keinerlei Konsistenz des Dateisystems mehr gesichert ist. Wenn mitten in einer Operation, die viele Metadaten ändert, ein Ausfall erfolgt (Stromausfall, drücken des Reset-Schalters), dann ist das Dateisystem anschließend in einem unbestimmten Zustand. Niemand kann genau sagen, was noch geschrieben worden ist und was nicht mehr; die Datenblöcke einer Datei können schon auf der Platte stehen, während die inode Tabelle oder das zugehörige Verzeichnis nicht mehr aktualisiert worden ist. Man kann praktisch kein &man.fsck.8; mehr implementieren, das diesen Zustand wieder reparieren kann, da die dazu nötigen Informationen einfach auf der Platte fehlen. Wenn ein Dateisystem irreparabel beschädigt wurde, hat man nur noch die Möglichkeit es neu zu erzeugen und die Daten vom Backup zurückspielen. Der Ausweg aus diesem Dilemma ist ein dirty region logging, was auch als Journalling bezeichnet wird. Man schreibt die Metadaten-Updates zwar synchron, aber nur in einen kleinen Plattenbereich, die logging area. Von da aus werden sie dann asynchron auf ihre eigentlichen Bereiche verteilt. Da die logging area ein kleines zusammenhängendes Stückchen ist, haben die Schreibköpfe der Platte bei massiven Operationen auf Metadaten keine allzu großen Wege zurückzulegen, so dass alles ein ganzes Stück schneller geht als bei klassischen synchronen Updates. Die Komplexität der Implementierung hält sich ebenfalls in Grenzen, somit auch die Anfälligkeit für Fehler. Als Nachteil ergibt sich, dass Metadaten zweimal auf die Platte geschrieben werden müssen (einmal in die logging area, einmal an die richtige Stelle), so dass das im Falle regulärer Arbeit (also keine gehäuften Metadatenoperationen) eine Pessimisierung des Falls der synchronen Updates eintritt, es wird alles langsamer. Dafür hat man als Vorteil, dass im Falle eines Crashes der konsistente Zustand dadurch erzielbar ist, dass die angefangenen Operationen aus dem dirty region log entweder zu Ende ausgeführt oder komplett verworfen werden, wodurch das Dateisystem schnell wieder zur Verfügung steht. Die Lösung von Kirk McKusick, dem Schöpfer von Berkeley FFS, waren Soft Updates: die notwendigen Updates der Metadaten werden im Speicher gehalten und dann sortiert auf die Platte geschrieben (ordered metadata updates). Dadurch hat man den Effekt, dass im Falle massiver Metadaten-Änderungen spätere Operationen die vorhergehenden, noch nicht auf die Platte geschriebenen Updates desselben Elements im Speicher einholen. Alle Operationen, auf ein Verzeichnis beispielsweise, werden also in der Regel noch im Speicher abgewickelt, bevor der Update überhaupt auf die Platte geschrieben wird (die dazugehörigen Datenblöcke werden natürlich auch so sortiert, dass sie nicht vor ihren Metadaten auf der Platte sind). Im Fall eines Absturzes hat man ein implizites log rewind: alle Operationen, die noch nicht den Weg auf die Platte gefunden haben, sehen danach so aus, als hätten sie nie stattgefunden. Man hat so also den konsistenten Zustand von ca. 30 bis 60 Sekunden früher sichergestellt. Der verwendete Algorithmus garantiert dabei, dass alle tatsächlich benutzten Ressourcen auch in den entsprechenden Bitmaps (Block- und inode Tabellen) als belegt markiert sind. Der einzige Fehler, der auftreten kann, ist, dass Ressourcen noch als belegt markiert sind, die tatsächlich frei sind. &man.fsck.8; erkennt dies und korrigiert diese nicht mehr belegten Ressourcen. Die Notwendigkeit eines Dateisystem-Checks darf aus diesem Grunde auch ignoriert und das Dateisystem mittels mount -f zwangsweise eingebunden werden. Um noch allozierte Ressourcen freizugeben muss später ein &man.fsck.8; nachgeholt werden. Das ist dann auch die Idee des background fsck: beim Starten des Systems wird lediglich ein Schnappschuss des Filesystems gemacht, mit dem &man.fsck.8; dann später arbeiten kann. Alle Dateisysteme dürfen unsauber eingebunden werden und das System kann sofort in den Multiuser-Modus gehen. Danach wird ein Hintergrund-&man.fsck.8; für die Dateisysteme gestartet, die dies benötigen, um möglicherweise irrtümlich belegte Ressourcen freizugeben. Dateisysteme ohne Soft Updates benötigen natürlich immer noch den üblichen Vordergrund-&man.fsck.8;, bevor sie eingebunden werden können. Der Vorteil ist, dass die Metadaten-Operationen beinahe so schnell ablaufen wie im asynchronen Fall, also auch schneller als beim logging, das die Metadaten immer zweimal schreiben muss. Als Nachteil stehen dem die Komplexität des Codes, ein erhöhter Speicherverbrauch und einige spezielle Eigenheiten entgegen. Nach einem Absturz ist ein etwas älterer Stand auf der Platte – statt einer leeren, aber bereits angelegten Datei, wie nach einem herkömmlichen &man.fsck.8; Lauf, ist auf einem Dateisystem mit Soft Updates keine Spur der entsprechenden Datei mehr zu sehen, da weder die Metadaten noch der Dateiinhalt je auf die Platte geschrieben wurden. Weiterhin kann der Platz nach einem &man.rm.1; nicht sofort wieder als verfügbar markiert werden, sondern erst dann, wenn der Update auch auf die Platte vermittelt worden ist. Dies kann besonders dann Probleme bereiten, wenn große Datenmengen in einem Dateisystem installiert werden, das nicht genügend Platz hat, um alle Dateien zweimal unterzubringen. Einstellungen von Kernel Limits Einstellungen von Kernel Limits Datei und Prozeß Limits <varname>kern.maxfiles</varname> kern.maxfiles Abhängig von den Anforderungen an das System kann die &man.sysctl.8;-Variable kern.maxfiles erhöht oder gesenkt werden. Die Variable legt die maximale Anzahl von Dateideskriptoren auf dem System fest. Wenn die Dateideskriptoren aufgebraucht sind, werden Sie die Meldung file: table is full wiederholt im Puffer für Systemmeldungen sehen. Den Inhalt des Puffers können Sie sich mit &man.dmesg.8; anzeigen lassen. Jede offene Datei, jedes Socket und jede FIFO verbraucht einen Dateideskriptor. Auf dicken Produktionsservern können leicht Tausende Dateideskriptoren benötigt werden, abhängig von der Art und Anzahl der gleichzeitig laufenden Dienste. In älteren &os;-Versionen wurde die Voreinstellung von kern.maxfile aus der Kernelkonfigurationsoption maxusers bestimmt. kern.maxfiles wächst proportional mit dem Wert von maxusers. Wenn Sie einen angepassten Kernel kompilieren, empfiehlt es sich diese Option entsprechend der maximalen Benutzerzahl des Systems einzustellen. Obwohl auf einer Produktionsmaschine vielleicht nicht 256 Benutzer gleichzeitig angemeldet sind, können die benötigten Ressourcen ähnlich hoch wie bei einem großen Webserver sein. Die nur lesbare &man.sysctl.8;-Variable kern.maxusers wird beim Systemstart automatisch aus dem zur Verfügung stehenden Hauptspeicher bestimmt. Im laufenden Betrieb kann dieser Wert aus kern.maxusers ermittelt werden. Einige Systeme benötigen für diese Variable einen anderen Wert, wobei 64, 128 und 256 gewöhnliche Werte darstellen. Es wird nicht empfohlen, die Anzahl der Dateideskriptoren auf einen Wert größer 256 zu setzen, es sei denn, Sie benötigen wirklich eine riesige Anzahl von ihnen. Viele der von kern.maxusers auf einen Standardwert gesetzten Parameter können beim Systemstart oder im laufenden Betrieb in /boot/loader.conf angepasst werden. In &man.loader.conf.5; und /boot/defaults/loader.conf finden Sie weitere Details und Hinweise. Ältere &os;-Versionen setzen diesen Wert selbst, wenn Sie in der Konfigurationsdatei den Wert 0 Der verwendete Algorithmus setzt maxusers auf die Speichergröße des Systems. Der minimale Wert beträgt dabei 32, das Maximum ist 384. angeben. Wenn Sie den Wert selbst bestimmen wollen, sollten Sie maxusers mindestens auf 4 setzen. Dies gilt insbesondere dann, wenn Sie beabsichtigen, &xorg; zu benutzen oder Software zu kompilieren. Der wichtigste Wert, der durch maxusers bestimmt wird, die maximale Anzahl an Prozessen ist, die auf 20 + 16 * maxusers gesetzt wird. Wird maxusers auf 1 setzen, können gleichzeitig nur 36 Prozesse laufen, von denen ungefähr 18 schon beim Booten des Systems gestartet werden. Dazu kommen nochmals etwa 15 Prozesse beim Start von &xorg;. Selbst eine einfache Aufgabe wie das Lesen einer Manualpage benötigt neun Prozesse zum Filtern, Dekomprimieren und Betrachten der Datei. Für die meisten Benutzer sollte es ausreichen, maxusers auf 64 zu setzen, womit 1044 gleichzeitige Prozesse zur Verfügung stehen. Wenn Sie allerdings den Fehler proc table full beim Start eines Programms oder auf einem Server mit einer großen Benutzerzahl sehen, dann sollten Sie den Wert nochmals erhöhen und den Kernel neu bauen. Die Anzahl der Benutzer, die sich auf einem Rechner anmelden kann, wird durch maxusers nicht begrenzt. Der Wert dieser Variablen legt neben der möglichen Anzahl der Prozesse eines Benutzers weitere sinnvolle Größen für bestimmte Systemtabellen fest. <varname>kern.ipc.somaxconn</varname> kern.ipc.somaxconn Die &man.sysctl.8;-Variable kern.ipc.somaxconn beschränkt die Größe der Warteschlange (Listen-Queue) für neue TCP-Verbindungen. Der Vorgabewert von 128 ist normalerweise zu klein, um neue Verbindungen auf einem stark ausgelasteten Webserver zuverlässig zu handhaben. Auf solchen Servern sollte der Wert auf 1024 oder höher gesetzt werden. Dienste wie &man.sendmail.8; oder Apache können die Größe der Queue selbst einschränken. Oft gibt es die Möglichkeit, die Größe der Listen-Queue in einer Konfigurationsdatei einzustellen. Eine große Listen-Queue übersteht vielleicht auch einen Denial of Service Angriff (DoS). Netzwerk Limits Die Kerneloption NMBCLUSTERS schreibt die Anzahl der Netzwerkpuffer (Mbufs) fest, die das System besitzt. Eine zu geringe Anzahl Mbufs auf einem Server mit viel Netzwerkverkehr verringert die Leistung von &os;. Jeder Mbuf-Cluster nimmt ungefähr 2 kB Speicher in Anspruch, so dass ein Wert von 1024 insgesamt 2 Megabyte Speicher für Netzwerkpuffer im System reserviert. Wie viele Cluster benötigt werden, lässt sich durch eine einfache Berechnung herausfinden. Ein Webserver, der maximal 1000 gleichzeitige Verbindungen servieren soll, wobei jede der Verbindungen einen 6 kB großen Sendepuffer und einen 16 kB großen Empfangspuffer benötigt, braucht ungefähr 32 MB Speicher für Netzwerkpuffer. Als Daumenregel verdoppeln Sie diese Zahl, so dass sich für NMBCLUSTERS der Wert 2x32 MB / 2 kB= 64 MB / 2 kB= 32768 ergibt. Für Maschinen mit viel Speicher werden Werte zwischen 4096 und 32768 empfohlen. Unter keinen Umständen sollten Sie diesen Wert willkürlich erhöhen, da dies zu einem Absturz beim Systemstart führen kann. Verwenden Sie &man.netstat.1; mit um den Gebrauch der Netzwerkpuffer zu kontrollieren. Die Netzwerkpuffer können beim Systemstart mit der Loader-Variablen kern.ipc.nmbclusters eingestellt werden. Nur auf älteren &os;-Systemen müssen Sie die Kerneloption NMBCLUSTERS verwenden. Die Anzahl der &man.sendfile.2; Puffer muss auf ausgelasteten Servern, die den Systemaufruf &man.sendfile.2; oft verwenden, vielleicht erhöht werden. Dazu können Sie die Kerneloption NSFBUFS verwenden oder die Anzahl der Puffer in /boot/loader.conf (siehe &man.loader.8;) setzen. Die Puffer sollten erhöht werden, wenn Sie Prozesse im Zustand sfbufa sehen. Die schreibgeschützte &man.sysctl.8;-Variable kern.ipc.nsfbufs zeigt die Anzahl eingerichteten Puffer im Kernel. Der Wert dieser Variablen wird normalerweise von kern.maxusers bestimmt. Manchmal muss die Pufferanzahl jedoch manuell eingestellt werden. Auch wenn ein Socket nicht blockierend angelegt wurde, kann der Aufruf von &man.sendfile.2; blockieren, um auf freie struct sf_buf Puffer zu warten. <varname>net.inet.ip.portrange.*</varname> net.inet.ip.portrange.* Die &man.sysctl.8;-Variable net.inet.ip.portrange.* legt die Portnummern für TCP- und UDP-Sockets fest. Es gibt drei Bereiche: den niedrigen Bereich, den normalen Bereich und den hohen Bereich. Die meisten Netzprogramme benutzen den normalen Bereich. Dieser Bereich umfasst in der Voreinstellung die Portnummern 1024 bis 5000 und wird durch die Variablen net.inet.ip.portrange.first und net.inet.ip.portrange.last festgelegt. Die festgelegten Bereiche für Portnummern werden von ausgehenden Verbindungen benutzt. Unter bestimmten Umständen, beispielsweise auf stark ausgelasteten Proxy-Servern, sind alle Portnummern für ausgehende Verbindungen belegt. Bereiche für Portnummern spielen auf Servern keine Rolle, die hauptsächlich eingehende Verbindungen verarbeiten (wie ein normaler Webserver) oder nur eine begrenzte Anzahl ausgehender Verbindungen öffnen (beispielsweise ein Mail-Relay). Wenn keine freien Portnummern mehr vorhanden sind, sollte die Variable net.inet.ip.portrange.last langsam erhöht werden. Ein Wert von 10000, 20000 oder 30000 ist angemessen. Beachten Sie auch eine vorhandene Firewall, wenn Sie die Bereiche für Portnummern ändern. Einige Firewalls sperren große Bereiche (normalerweise aus den kleinen Portnummern) und erwarten, dass hohe Portnummern für ausgehende Verbindungen verwendet werden. Daher kann es erforderlich sein, den Wert von net.inet.ip.portrange.first zu erhöhen. <literal>TCP</literal> Bandwidth Delay Product Begrenzung TCP Bandwidth Delay Product Begrenzung net.inet.tcp.inflight.enable Die TCP Bandwidth Delay Product Begrenzung wird aktiviert, indem die &man.sysctl.8;-Variable net.inet.tcp.inflight.enable auf den Wert 1 gesetzt wird. Das System wird dadurch angewiesen, für jede Verbindung, das Produkt aus der Übertragungsrate und der Verzögerungszeit zu bestimmen. Dieses Produkt begrenzt die Datenmenge, die für einen optimales Durchsatz zwischengespeichert werden muss. Diese Begrenzung ist nützlich, wenn Sie Daten über Verbindungen mit einem hohen Produkt aus Übertragungsrate und Verzögerungszeit wie Modems, Gigabit-Ethernet oder schnellen WANs, zur Verfügung stellen. Insbesondere wirkt sich die Begrenzung aus, wenn die Verbindung die Option Window-scaling verwendet oder große Sende-Fenster (send window) benutzt. Schalten Sie die Debug-Meldungen aus, wenn Sie die Begrenzung aktiviert haben. Dazu setzen Sie die Variable net.inet.tcp.inflight.debug auf 0. Auf Produktions-Systemen sollten Sie zudem die Variable net.inet.tcp.inflight.min mindestens auf den Wert 6144 setzen. Allerdings kann ein zu hoher Wert, abhängig von der Verbindung, die Begrenzungsfunktion unwirksam machen. Die Begrenzung reduziert die Datenmenge in den Queues von Routern und Switches, sowie die Datenmenge in der Queue der lokalen Netzwerkkarte. Die Verzögerungszeit (Round Trip Time) für interaktive Anwendungen sinkt, da weniger Pakete zwischengespeichert werden. Dies gilt besonders für Verbindungen über langsame Modems. Die Begrenzung wirkt sich allerdings nur auf das Versenden von Daten aus (Uploads, Server). Auf den Empfang von Daten (Downloads) hat die Begrenzung keine Auswirkungen. Die Variable net.inet.tcp.inflight.stab sollte nicht angepasst werden. Der Vorgabewert der Variablen beträgt 20, das heißt es werden maximal zwei Pakete zu dem Produkt aus Übertragungsrate und Verzögerungszeit addiert. Dies stabilisiert den Algorithmus und verbessert die Reaktionszeit auf Veränderungen. Bei langsamen Verbindungen können sich aber die Laufzeiten der Pakete erhöhen (ohne diesen Algorithmus wären sie allerdings noch höher). In solchen Fällen können Sie versuchen, den Wert der Variablen auf 15, 10 oder 5 herabzusetzten. Gleichzeitig müssen Sie vielleicht auch net.inet.tcp.inflight.min auf einen kleineren Wert (beispielsweise 3500) setzen. Ändern Sie diese Variablen nur ab, wenn Sie keine anderen Möglichkeiten mehr haben. Virtueller Speicher (<foreignphrase>Virtual Memory</foreignphrase>) <varname>kern.maxvnodes</varname> Ein vnode ist die interne Darstellung einer Datei oder eines Verzeichnisses. Die Erhöhung der Anzahl der für das Betriebssystem verfügbaren vnodes verringert also die Schreib- und Lesezugriffe auf der Festplatte. vnodes werden im Normalfall vom Betriebssystem automatisch vergeben und müssen nicht manuell angepasst werden. In einigen Fällen stellt der Zugriff auf eine Platte allerdings einen Flaschenhals dar, daher sollten Sie in diesem Fall die Anzahl der möglichen vnodes erhöhen, um dieses Problem zu beheben. Beachten Sie dabei aber die Größe des inaktiven und freien Hauptspeichers. Um die Anzahl der derzeit verwendeten vnodes zu sehen, geben Sie Folgendes ein: &prompt.root; sysctl vfs.numvnodes vfs.numvnodes: 91349 Die maximal mögliche Anzahl der vnodes erhalten Sie durch die Eingabe von: &prompt.root; sysctl kern.maxvnodes kern.maxvnodes: 100000 Wenn sich die Anzahl der genutzten vnodes dem maximal möglichen Wert nähert, sollten Sie den Wert kern.maxvnodes zuerst um etwa 1000 erhöhen. Beobachten Sie danach die Anzahl der vom System genutzten vfs.numvnodes. Nähert sich der Wert wiederum dem definierten Maximum, müssen Sie kern.maxvnodes nochmals erhöhen. Sie sollten nun eine Änderung des Speicherverbrauches über &man.top.1; registrieren können und über mehr aktiven Speicher verfügen. Hinzufügen von Swap-Bereichen Manchmal benötigt ein System mehr Swap-Bereiche. Dieser Abschnitt beschreibt zwei Methoden, um Swap-Bereiche hinzuzufügen: auf einer bestehenden Partition oder auf einem neuen Laufwerk, und das Hinzufügen einer Swap-Datei auf einer existierenden Partition. Für Informationen zur Verschlüsselung von Swap-Partitionen, zu den dabei möglichen Optionen sowie zu den Gründen für eine Verschlüsselung des Auslagerungsspeichers lesen Sie . Swap auf einer neuen oder existierenden Festplatte Das Hinzufügen einer neuen Festplatte für Swap-Bereich bietet eine bessere Leistung, als das Hinzufügen einer Partition auf einem vorhandenem Laufwerk. Die Einrichtung von Partitionen und Laufwerken wird in beschrieben. diskutiert Aspekte über die Anordnung und Größe von Swap-Bereichen. Benutzen Sie &man.swapon.8; um eine Swap-Partition zum System hinzuzufügen. Zum Beispiel: &prompt.root; swapon /dev/ada1s1b Sie können jede Partition verwenden, sofern sie nicht schon eingehangen ist. Das gilt auch dann, wenn die Partition bereits Daten enthält. Wird &man.swapon.8; auf einer Partition ausgeführt die noch Daten enthält, werden die vorhandenen Daten überschrieben und sind unweigerlich verloren. Stellen Sie sicher, das die Partition, die Sie als Swap-Bereich hinzufügen möchten, wirklich die gewünschte Partition ist, bevor sie &man.swapon.8; ausführen. Um diese Swap-Partition automatisch beim Systemstart hinzuzufügen, fügen Sie einen Eintrag in /etc/fstab hinzu: /dev/ada1s1b none swap sw 0 0 Die einzelnen Einträge von /etc/fstab werden in &man.fstab.5; erläutert. Swap-Bereiche über <literal>NFS</literal> Swap-Bereiche über NFS sollten Sie nur dann einsetzen, wenn Sie über keine lokale Platte verfügen, da es durch die zur Verfügung stehende Bandbreite limitiert wird und außerdem den NFS-Server zusätzlich belastet. Swap-Dateien Sie können eine Datei festgelegter Größe als Swap-Bereich nutzen. Im folgenden Beispiel wird eine 64 MB große Datei mit dem Namen /usr/swap0 benutzt. Erstellen einer Swap-Datei Der GENERIC-Kernel unterstützt bereits RAM-Disks (&man.md.4;), welche für diese Aktion benötigt werden. Wenn Sie einen eigenen Kernel erstellen, vergewissern Sie sich, dass die folgende Zeile in der Kernelkonfigurationsdatei enthalten ist: device md Informationen, wie man einen eigenen Kernel erstellen kann, erhalten Sie in . Legen Sie die Swap-Datei /usr/swap0 an: &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Setzen Sie die richtigen Berechtigungen für /usr/swap0: &prompt.root; chmod 0600 /usr/swap0 Aktivieren Sie die Swap-Datei /etc/rc.conf: swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. Um die Swap-Datei zu aktivieren, führen Sie entweder einen Neustart durch oder geben das folgende Kommando ein: &prompt.root; mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0 Energie- und Ressourcenverwaltung Hiten Pandya Verfasst von Tom Rhodes Es ist wichtig, Hardware effizient einzusetzen. Vor der Einführung des Advanced Configuration and Power Interface (ACPI) konnten Stromverbrauch und Wärmeabgabe eines Systems nur schlecht von Betriebssystemen gesteuert werden. Die Hardware wurde vom BIOS gesteuert, was die Kontrolle der Energieverwaltung für den Anwender erschwerte. Das Advanced Power Management (APM) erlaubte es lediglich, einige wenige Funktionen zu steuern, obwohl die Überwachung von Energie- und Ressourcenverbrauch zu den wichtigsten Aufgaben eines Betriebssystems gehört, um auf verschiedene Ereignisse, beispielsweise einen unerwarteten Temperaturanstieg, reagieren können. Dieser Abschnitt erklärt das Advanced Configuration and Power Interface (ACPI). Was ist ACPI? ACPI APM Advanced Configuration and Power Interface (ACPI) ist ein Standard verschiedener Hersteller, der die Verwaltung von Hardware und Energiesparfunktionen festlegt. Die ACPI-Funktionen können von einem Betriebssystem gesteuert werden. Der Vorgänger des ACPI, APM, erwies sich in modernen Systemen als unzureichend. Mängel des Advanced Power Managements Das APM steuert den Energieverbrauch eines Systems auf Basis der Systemaktivität. Das APM-BIOS wird von dem Hersteller des Systems zur Verfügung gestellt und ist auf die spezielle Hardware angepasst. Der APM-Treiber des Betriebssystems greift auf das APM Software Interface zu, das den Energieverbrauch regelt. APM findet sich in der Regel nur noch in Systemen, die vor 2001 produziert wurden. Das APM hat hauptsächlich vier Probleme. Erstens läuft die Energieverwaltung unabhängig vom Betriebssystem in einem herstellerspezifischen BIOS. Beispielsweise kann das APM-BIOS die Festplatten nach einer konfigurierbaren Zeit ohne die Zustimmung des Betriebssystems herunterfahren. Zweitens befindet sich die ganze APM-Logik im BIOS; das Betriebssystem hat gar keine APM-Komponenten. Bei Problemen mit dem APM-BIOS muss das Flash-ROM aktualisiert werden. Diese Prozedur ist gefährlich, da sie im Fehlerfall das System unbrauchbar machen kann. Zum Dritten ist APM eine Technik, die herstellerspezifisch ist und nicht koordiniert wird. Fehler im BIOS eines Herstellers werden nicht unbedingt im BIOS anderer Hersteller korrigiert. Das letzte Problem ist, dass im APM-BIOS nicht genügend Platz vorhanden ist, um eine durchdachte oder eine auf den Zweck der Maschine zugeschnittene Energieverwaltung zu implementieren. Das Plug and Play BIOS (PNPBIOS) war ebenfalls unzureichend. Das PNPBIOS verwendet eine 16-Bit-Technik. Damit das Betriebssystem das PNPBIOS ansprechen kann, muss es in einer 16-Bit-Emulation laufen. Der APM-Treiber wird in &man.apm.4; beschrieben. Konfiguration des <acronym>ACPI</acronym> Das Modul &man.acpi.4; wird standardmäßig beim Systemstart vom &man.loader.8; geladen und sollte daher nicht fest in den Kernel eingebunden werden. Dadurch kann ein Modul ohne einen Neubau des Kernels leichter ersetzt und getestet werden. Das ACPI-Modul im laufenden Betrieb zu laden, führt oft nicht zum gewünschten Ergebnis. Treten bei Ihrem System Probleme auf, kann ACPI auch komplett deaktiviert werden. Dazu definieren Sie die Variable hint.acpi.0.disabled="1" in der Datei /boot/loader.conf. Alternativ können Sie die Variable auch am &man.loader.8;-Prompt eingeben. Das Modul kann im laufenden Betrieb nicht entfernt werden, da es zur Kommunikation mit der Hardware verwendet wird. ACPI und APM können nicht zusammen verwendet werden. Das zuletzt geladene Modul beendet sich, sobald es bemerkt, dass das andere Modul geladen ist. Mit &man.acpiconf.8; können Sie das System in einen Ruhemodus (sleep mode) versetzen. Es gibt verschiedene Modi (von 1 bis 5), die Sie auf der Kommandozeile mit angeben können. Für die meisten Anwender sind die Modi 1 und 3 völlig ausreichend. Der Modus 5 schaltet das System aus (Soft-off) und entspricht dem folgenden Befehl: &prompt.root; halt -p Verschiedene Optionen können als &man.sysctl.8;-Variablen gesetzt werden. Lesen Sie dazu &man.acpi.4; sowie &man.acpiconf.8;. <acronym>ACPI</acronym>-Fehlersuche Nate Lawson Verfasst von Peter Schultz Mit Beiträgen von Tom Rhodes ACPI Probleme mit ACPI ist ein gänzlich neuer Weg, um Geräte aufzufinden und deren Stromverbrauch zu regulieren. Weiterhin bietet ACPI einen einheitlichen Zugriff auf Geräte, die vorher vom BIOS verwaltet wurden. Es werden zwar Fortschritte gemacht, dass ACPI auf allen Systemen läuft, doch tauchen immer wieder Fehler auf: fehlerhafter Bytecode der ACPI-Machine-Language (AML) einiger Systemplatinen, ein unvollständiges &os;-Kernel-Subsystem oder Fehler im ACPI-CA-Interpreter von &intel;. Dieser Abschnitt hilft Benutzern, zusammen mit den Betreuern des &os;-ACPI-Subsystems, Fehlerquellen zu finden und Fehler zu beseitigen. Fehlerberichte einreichen Bevor Sie einen Fehlerbericht einreichen, stellen Sie bitte sicher, dass das BIOS und die Firmware des Controllers aktuell sind. Wenn Sie einen Fehlerbericht einsenden wollen, schicken Sie bitte die folgenden Informationen an die Mailingliste freebsd-acpi: Beschreiben Sie den Fehler und alle Umstände, unter denen der Fehler auftritt. Geben Sie ebenfalls den Typ und das Modell Ihres Systems an. Wenn Sie einen neuen Fehler entdeckt haben, versuchen Sie möglichst genau zu beschreiben, wann der Fehler das erste Mal aufgetreten ist. Die Ausgabe von &man.dmesg.8; nach der Eingabe von boot -v. Geben Sie auch alle Fehlermeldungen an, die erscheinen, wenn Sie den Fehler provozieren. Die Ausgabe von &man.dmesg.8; nach der Eingabe von boot -v und mit deaktiviertem ACPI, wenn das Problem ohne ACPI nicht auftritt. Die Ausgabe von sysctl hw.acpi. Dieses Kommando zeigt die vom System unterstützten ACPI-Funktionen an. Die URL, unter der die ACPI-Source-Language (ASL) liegt. Schicken Sie bitte nicht die ASL an die Mailingliste, da die ASL sehr groß sein kann. Eine Kopie der ASL erstellen Sie mit dem nachstehenden Befehl: &prompt.root; acpidump -td > name-system.asl Setzen Sie für name den Namen des Kontos und für system den Hersteller und das Modell des Systems ein. Zum Beispiel: njl-FooCo6000.asl. Obwohl die meisten Entwickler die Mailingliste &a.current.name; lesen, sollten Sie Fehlerberichte an die Liste &a.acpi.name; schicken. Seien Sie bitte geduldig; wir haben alle Arbeit außerhalb des Projekts. Wenn der Fehler nicht offensichtlich ist, bitten wir Sie vielleicht, einen offiziellen Fehlerbericht (PR) mit &man.send-pr.1; einzusenden. Geben Sie im Fehlerbericht bitte dieselben Informationen wie oben an. Mithilfe der PRs verfolgen und lösen wir Probleme. Senden Sie bitte keinen PR ein, ohne vorher den Fehlerbericht an die Liste &a.acpi.name; zu senden. Es kann sein, dass der Fehler schon von jemand anderem gemeldet wurde. <acronym>ACPI</acronym>-Grundlagen ACPI ACPI gibt es in allen modernen Rechnern der ia32- (x86), ia64- (Itanium) und amd64- (AMD) Architektur. Der vollständige Standard bietet Funktionen zur Steuerung und Verwaltung der CPU-Leistung, der Stromversorgung, von Wärmebereichen, Batterien, eingebetteten Controllern und Bussen. Auf den meisten Systemen wird nicht der vollständige Standard implementiert. Arbeitsplatzrechner besitzen meist nur Funktionen zur Verwaltung der Busse, während Notebooks Funktionen zur Temperaturkontrolle und Ruhezustände besitzen. Ein ACPI konformes System besitzt verschiedene Komponenten. Die BIOS- und Chipsatz-Hersteller stellen mehrere statische Tabellen bereit, zum Beispiel die Fixed-ACPI-Description-Table (FADT). Die Tabellen enthalten beispielsweise die mit SMP-Systemen benutzte APIC-Map, Konfigurationsregister und einfache Konfigurationen. Zusätzlich gibt es die Differentiated-System-Description-Table (DSDT), die Bytecode enthält. Die Tabelle ordnet Geräte und Methoden in einem baumartigen Namensraum an. Ein ACPI-Treiber muss die statischen Tabellen einlesen, einen Interpreter für den Bytecode bereitstellen und die Gerätetreiber im Kernel so modifizieren, dass sie mit dem ACPI-Subsystem kommunizieren. Für &os;, &linux; und NetBSD hat &intel; den Interpreter ACPI-CA, zur Verfügung gestellt. Der Quelltext zu ACPI-CA befindet sich im Verzeichnis src/sys/contrib/dev/acpica. Die Schnittstelle von ACPI-CA zu &os; befindet sich unter src/sys/dev/acpica/Osd. Treiber, die verschiedene ACPI-Geräte implementieren, befinden sich im Verzeichnis src/sys/dev/acpica. Häufige Probleme ACPI Probleme mit Damit ACPI richtig funktioniert, müssen alle Teile funktionieren. Im Folgenden finden Sie eine Liste mit Problemen und möglichen Umgehungen oder Fehlerbehebungen. Die Liste ist nach der Häufigkeit, mit der die Probleme auftreten, sortiert. Mausprobleme Es kann vorkommen, dass die Maus nicht mehr funktioniert, wenn Sie nach einem Suspend weiterarbeiten wollen. Ist dies bei Ihnen der Fall, reicht es meistens aus, den Eintrag hint.psm.0.flags="0x3000" in /boot/loader.conf aufzunehmen. Besteht das Problem weiterhin, sollten Sie einen Fehlerbericht senden. Suspend/Resume ACPI kennt drei Suspend-to-RAM-Zustände (STR): S1-S3. Es gibt einen Suspend-to-Disk-Zustand (STD): S4. Der Zustand S5 wird Soft-Off genannt. In diesem Zustand befindet sich ein Rechner, wenn die Stromversorgung angeschlossen ist, der Rechner aber nicht hochgefahren ist. Der Zustand S4 kann auf zwei Arten implementiert werden: S4BIOS und S4OS. Im ersten Fall wird der Suspend-to-Disk-Zustand durch das BIOS hergestellt im zweiten Fall alleine durch das Betriebssystem. Die Suspend-Zustände sind Ruhezustände, in denen der Rechner weniger Energie als im Normalbetrieb benötigt. Resume bezeichnet die Rückkehr zum Normalbetrieb. Die Suspend-Zustände können Sie mit dem Kommando sysctl hw.acpi ermitteln. Das Folgende könnte beispielsweise ausgegeben werden: hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0 Diese Ausgabe besagt, dass mit dem Befehl acpiconf -s die Zustände S3, S4OS und S5 eingestellt werden können. Hätte den Wert 1, gäbe es den Zustand S4BIOS anstelle von S4OS. Wenn Sie die Suspend- und Resume-Funktionen testen, fangen Sie mit dem S1-Zustand an, wenn er angeboten wird. Dieser Zustand wird am ehesten funktionieren, da der Zustand wenig Treiber-Unterstützung benötigt. Der Zustand S2 ist ähnlich wie S1, allerdings hat ihn noch niemand implementiert. Als nächstes sollten Sie den Zustand S3 ausprobieren. Dies ist der tiefste STR-Schlafzustand. Dieser Zustand ist auf massive Treiber-Unterstützung angewiesen, um die Geräte wieder richtig zu initialisieren. Wenn Sie Probleme mit diesem Zustand haben, können Sie die Mailingliste &a.acpi.name; anschreiben. Erwarten Sie allerdings nicht zu viel: Es gibt viele Treiber und Geräte, an denen noch gearbeitet und getestet wird. Ein häufiges Problem mit Suspend/Resume ist, dass viele Gerätetreiber ihre Firmware, Register und Gerätespeicher nicht korrekt speichern, wiederherstellen und/oder reinitialisieren. Um dieses Problem zu lösen, sollten Sie zuerst die folgenden Befehle ausführen: &prompt.root; sysctl debug.bootverbose=1 &prompt.root; sysctl debug.acpi.suspend_bounce=1 &prompt.root; acpiconf -s 3 Dieser Test emuliert einen Suspend/Resume-Zyklus für alle Geräte (ohne dass diese dabei wirklich in den Status S3 wechseln). In vielen Fällen reicht dies bereits aus, um Probleme (beispielsweise verlorener Firmware-Status, Timeouts, hängende Geräte) zu entdecken. Beachten Sie dabei, dass das Gerät bei diesem Test nicht wirklich in den Status S3 wechseln. Es kann also vorkommen, dass manche Geräte weiterhin mit Strom versorgt werden (dies wäre bei einem wirklichen Wechsel in den Status S3 NICHT möglich. Andere Geräte werden normal weiterarbeiten, weil sie über keine Suspend/Resume-Funktionen verfügen. Schwierigere Fälle können den Einsatz zusätzlicher Hardware (beispielsweise serielle Ports/Kabel für die Verbindung über eine serielle Konsole oder Firewire-Ports/Kabel für &man.dcons.4;) sowie Kenntnisse im Bereich Kerneldebugging erforderlich machen. Um das Problem einzugrenzen, entfernen Sie soviele Treiber wie möglich aus dem Kernel. Sie können das Problem isolieren, indem Sie einen Treiber nach dem anderen laden, bis der Fehler wieder auftritt. Typischerweise verursachen binäre Treiber wie nvidia.ko, Grafiktreiber und USB-Treiber die meisten Fehler, hingegen laufen Ethernet-Treiber für gewöhnlich sehr zuverlässig. Wenn ein Treiber zuverlässig geladen und entfernt werden kann, können Sie den Vorgang automatisieren, indem Sie die entsprechenden Kommandos in /etc/rc.suspend und /etc/rc.resume einfügen. In den Dateien finden Sie ein deaktiviertes Beispiel, das einen Treiber lädt und wieder entfernt. Ist die Bildschirmanzeige bei der Wiederaufnahme des Betriebs gestört, setzen Sie die Variable auf 0. Versuchen Sie auch, die Variable auf kürzere Zeitspannen zu setzen. Die Suspend- und Resume-Funktionen können Sie auch auf einer neuen &linux;-Distribution mit ACPI testen. Wenn es mit &linux; funktioniert, liegt das Problem wahrscheinlich bei einem &os;-Treiber. Es hilft uns, das Problem zu lösen, wenn Sie feststellen können, welcher Treiber das Problem verursacht. Beachten Sie bitte, dass die ACPI-Entwickler normalerweise keine anderen Treiber pflegen (beispielsweise Sound- oder ATA-Treiber). Es ist wohl das beste, die Ergebnisse der Fehlersuche an die Mailingliste &a.current.name; und den Entwickler des Treibers zu schicken. Erfahrene Benutzer können versuchen, den Fehler in der Resume-Funktion zu finden, indem sie einige &man.printf.3;-Anweisungen in den Code des fehlerhaften Treibers einfügen. Schließlich können Sie ACPI noch abschalten und stattdessen APM verwenden. Wenn die Suspend- und Resume-Funktionen mit APM funktionieren, sollten Sie besser APM verwenden (insbesondere mit alter Hardware von vor dem Jahr 2000). Die Hersteller benötigten einige Zeit, um ACPI korrekt zu implementieren, daher gibt es mit älterer Hardware oft ACPI-Probleme. Systemhänger Die meisten Systemhänger entstehen durch verlorene Interrupts oder einen Interrupt-Sturm. Probleme werden verursacht durch die Art, in der das BIOS Interrupts vor dem Systemstart konfiguriert, durch eine fehlerhafte APIC-Tabelle und durch die Zustellung des System-Control-Interrupts (SCI). Interrupt-Sturm Anhand der Ausgabe des Befehls vmstat -i können Sie verlorene Interrupts von einem Interrupt-Sturm unterscheiden. Untersuchen Sie die Ausgabezeile, die acpi0 enthält. Ein Interrupt-Sturm liegt vor, wenn der Zähler öfter als ein paar Mal pro Sekunde hochgezählt wird. Wenn sich das System aufgehangen hat, versuchen Sie mit der Tastenkombination Ctrl Alt Esc in den Debugger DDB zu gelangen. Geben Sie dort den Befehl show interrupts ein. APIC deaktivieren Wenn Sie Interrupt-Probleme haben, ist es vorerst wohl am besten, APIC zu deaktivieren. Tragen Sie dazu die Zeile hint.apic.0.disabled="1" in /boot/loader.conf ein. Abstürze (Panics) Panics werden so schnell wie möglich behoben; mit ACPI kommt es aber selten dazu. Zuerst sollten Sie die Panic reproduzieren und dann versuchen einen backtrace (eine Rückverfolgung der Funktionsaufrufe) zu erstellen. Richten Sie dazu den DDB über die serielle Schnittstelle (siehe ) oder eine gesonderte &man.dump.8;-Partition ein. In DDB können Sie den backtrace mit dem Kommando tr erstellen. Falls Sie den backtrace vom Bildschirm abschreiben müssen, schreiben Sie bitte mindestens die fünf ersten und die fünf letzten Zeile der Ausgabe auf. Versuchen Sie anschließend, das Problem durch einen Neustart ohne ACPI zu beseitigen. Wenn das funktioniert hat, können Sie versuchen, das verantwortliche ACPI-Subsystem durch Setzen der Variablen herauszufinden. Die Hilfeseite &man.acpi.4; enthält dazu einige Beispiele. Nach einem Suspend oder einem Stopp startet das System wieder Setzen Sie zuerst in /boot/loader.conf 0. Damit wird verhindert, dass ACPI während des Systemabschlusses die Bearbeitung verschiedener Ereignisse deaktiviert. Auf manchen Systemen muss die Variable den Wert 1 besitzen (die Voreinstellung). Normalerweise wird der unerwünschte Neustart des Systems durch Setzen dieser Variablen behoben. Andere Probleme Wenn Sie weitere Probleme mit ACPI haben (Umgang mit einer Docking-Station, nicht erkannte Geräte), schicken Sie bitte eine Beschreibung an die Mailingliste &a.acpi.name;. Allerdings kann es sein, dass einige Probleme von noch unvollständigen Teilen des ACPI-Subsystems abhängen und es etwas dauern kann bis diese Teile fertig sind. Seien Sie geduldig und rechnen Sie damit, Fehlerbehebungen zu testen. <acronym>ASL</acronym>, &man.acpidump.8; und <acronym>IASL</acronym> ACPI ASL Einige BIOS-Hersteller liefern einen fehlerhaften Bytecode aus. Dies erkennen Sie an Kernelmeldungen wie diesen: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND Oft können Sie das Problem dadurch lösen, dass Sie eine aktuelle BIOS-Version einspielen. Die meisten Meldungen auf der Konsole sind harmlos, wenn aber beispielsweise der Batteriestatus falsch angezeigt wird, können Sie in den Meldungen nach Problemen mit der AML-Machine-Language (AML) suchen. Der Bytecode der AML wird aus der ACPI-Source-Language (ASL) übersetzt und in einer Tabelle, der DSDT, abgelegt. Eine Kopie der ASL können Sie mit dem Befehl &man.acpidump.8; erstellen. Verwenden Sie mit diesem Befehl sowohl die Option (die Inhalte der statischen Tabellen anzeigen) als auch die Option (die AML in ASL zurückübersetzen). Ein Beispiel für die Syntax finden Sie in . Sie können einfach prüfen, ob sich die ASL übersetzen lässt. Für gewöhnlich können Sie Warnungen während des Übersetzens ignorieren. Fehlermeldungen führen normal dazu, dass ACPI fehlerhaft arbeitet. ASL übersetzen Sie mit dem nachstehenden Kommando: &prompt.root; iasl ihre.asl Die <acronym>ASL</acronym> reparieren ACPI ASL Es ist das Ziel von &os;, dass ACPI ohne Eingriffe des Benutzers läuft. Zurzeit werden allerdings noch Umgehungen für Fehler der BIOS-Hersteller entwickelt. Der µsoft;-Interpreter (acpi.sys und acpiec.sys) prüft die ASL nicht streng gegen den Standard. Daher reparieren BIOS-Hersteller, die ACPI nur unter &windows; testen, ihre ASL nicht. Die &os; Entwickler hoffen, dass sie das vom Standard abweichende Verhalten des µsoft;-Interpreters dokumentieren und in &os; replizieren können. Dadurch müssen Benutzer ihre ASL nicht selbst reparieren. Sie können Ihre ASL selbst reparieren, wenn Sie ein Problem umgehen und uns helfen möchten. Senden Sie bitte die mit &man.diff.1; erstellte Differenz zwischen alter und neuer ASL. Die Entwickler werden versuchen, den Interpreter ACPI-CA zu korrigieren. ACPI Fehlermeldungen Die nachfolgende Liste enthält häufige Fehlermeldungen, deren Ursache und eine Beschreibung, wie die Fehler korrigiert werden: Abhängigkeiten vom Betriebssystem Einige AMLs gehen davon aus, dass der Anwender eine &windows;-Versionen benutzt. Versuchen Sie das Betriebssystem, das Sie in der ASL finden, in /boot/loader.conf anzugeben: hw.acpi.osname="Windows 2001". Fehlende Return-Anweisungen Einige Methoden verzichten auf die vom Standard vorgeschriebene Rückgabe eines Wertes. Obwohl der Interpreter ACPI-CA dies nicht beheben kann, besitzt &os; die Möglichkeit, den Rückgabewert implizit zu setzen. Wenn Sie wissen, welcher Wert zurückgegeben werden muss, können Sie die fehlenden Return-Anweisungen selbst einsetzen. Die Option zwingt &man.iasl.8;, die ASL zu übersetzen. Überschreiben der vorgegebenen <acronym>AML</acronym> Nachdem Sie Ihre ASL in der Datei ihre.asl angepasst haben, übersetzen Sie die ASL wie folgt: &prompt.root; iasl ihre.asl Die Option erzwingt das Erstellen der AML auch dann, wenn während der Übersetzung Fehler auftreten. Einige Fehler, wie fehlende Return-Anweisungen, werden automatisch vom Interpreter umgangen. In der Voreinstellung erstellt der Befehl &man.iasl.8; die Ausgabedatei DSDT.aml. Wenn Sie diese Datei anstelle der fehlerhaften Kopie des BIOS laden wollen, editieren Sie /boot/loader.conf wie folgt: acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml" Stellen Sie bitte sicher, dass sich DSDT.aml in /boot befindet. <acronym>ACPI</acronym>-Meldungen zur Fehlersuche erzeugen ACPI Probleme mit ACPI Fehlersuche Der ACPI-Treiber besitzt flexible Möglichkeiten zur Fehlersuche. Sie können sowohl die zu untersuchenden Subsysteme als auch die zu erzeugenden Ausgaben festlegen. Die zu untersuchenden Subsysteme werden als so genannte layers angegeben. Die Subsysteme sind in ACPI-CA-Komponenten (ACPI_ALL_COMPONENTS) und ACPI-Hardware (ACPI_ALL_DRIVERS) aufgeteilt. Welche Meldungen ausgegeben werden, wird über level gesteuert. level reicht von ACPI_LV_ERROR (es werden nur Fehler ausgegeben) bis zu ACPI_LV_VERBOSE (alles wird ausgegeben). level ist eine Bitmaske, sodass verschiedene Stufen auf einmal (durch Leerzeichen getrennt) angegeben werden können. Die erzeugte Ausgabemenge passt vielleicht nicht in den Konsolenpuffer. In diesem Fall sollte die Ausgabe mithilfe einer seriellen Konsole gesichert werden. Die möglichen Werte für layers und level werden in &man.acpi.4; beschrieben. Die Ausgaben zur Fehlersuche sind in der Voreinstellung nicht aktiviert. Wenn ACPI im Kernel enthalten ist, fügen Sie options ACPI_DEBUG zur Kernelkonfigurationsdatei hinzu. Sie können die Ausgaben zur Fehlersuche global aktivieren, indem Sie in der Datei /etc/make.conf die Zeile ACPI_DEBUG=1 einfügen. Das Modul acpi.ko können Sie wie folgt neu übersetzen: &prompt.root; cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1 Installieren Sie anschließend acpi.ko im Verzeichnis /boot/kernel. In /boot/loader.conf stellen Sie level und layer ein. Das folgende Beispiel aktiviert die Ausgabe von Fehlern für alle ACPI-CA-Komponenten und alle ACPI-Hardwaretreiber (wie CPU, LID): debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ERROR" Wenn ein Problem durch ein bestimmtes Ereignis, beispielsweise den Start nach einem Ruhezustand, hervorgerufen wird, können Sie die Einstellungen für level und layer auch mit dem Kommando sysctl vornehmen. In diesem Fall müssen Sie /boot/loader.conf nicht editieren. Auf der Kommandozeile geben Sie über &man.sysctl.8; dieselben Variablennamen wie in /boot/loader.conf an. ACPI-Informationsquellen Weitere Informationen zu ACPI erhalten Sie an den folgenden Stellen: die &a.acpi; Mailingliste, die Archive der ACPI-Mailingliste: http://lists.FreeBSD.org/pipermail/freebsd-acpi/, die alten Archive der ACPI-Mailingliste: http://home.jp.FreeBSD.org/mail-list/acpi-jp/, die ACPI-Spezifikation (Version 2.0): http://acpi.info/spec.htm, &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8; und &man.acpidb.8;, DSDT debugging resource. Index: head/de_DE.ISO8859-1/books/handbook/ports/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/ports/chapter.xml (revision 48476) +++ head/de_DE.ISO8859-1/books/handbook/ports/chapter.xml (revision 48477) @@ -1,1918 +1,1925 @@ Installieren von Anwendungen: Pakete und Ports UwePierauÜbersetzt von Übersicht Ports Pakete &os; enthält eine umfassende Sammlung von Systemwerkzeugen, die Teil des Basissystems sind. Darüber hinaus stellt &os; zwei sich ergänzende Methoden zur Installation von Drittanbieter-Software zur Verfügung: Die Ports-Sammlung zur Installation aus dem Quellcode sowie Pakete zur Installation von vorkompilierten binären Softwarepaketen. Beide Methoden können benutzt werden, um Anwendungen von lokalen Medien oder über das Netzwerk zu installieren. Dieses Kapitel behandelt die folgenden Themen: Den Unterschied zwischen binären Softwarepaketen und Ports. Wie man Drittanbieter-Software findet, die nach &os; portiert wurde. Wie Binärpakete mit pkgng verwaltet werden. Den Bau von Drittanbieter-Software aus dem Quellcode mithilfe der Ports-Sammlung. Wie man die Dateien findet, die zusammen mit der Anwendung installiert wurden. Was zu tun ist, wenn die Installation einer Software fehlschlägt. Installation von Software Die typischen Schritte zur Installation von Drittanbieter-Software auf einem &unix; System sind: Download der Software, die als Quelltext oder im Binärformat vorliegen kann. Auspacken der Software. Dies ist typischerweise ein mit &man.compress.1;, &man.gzip.1; oder &man.bzip2.1; komprimiertes Tar-Archiv. Durchsuchen der Dokumentation, die sich in INSTALL, README oder mehreren Dateien im Verzeichnis doc/ befindet, nach Anweisungen, wie die Software zu installieren ist. Kompilieren der Software, wenn sie als Quelltext vorliegt. Dazu muss vielleicht das Makefile angepasst, oder configure ausgeführt werden. Testen und installieren der Software. Wenn die Software nicht speziell für &os; geschrieben wurde, muss vielleicht sogar der Quelltext angepasst werden, damit die Software funktioniert. Zurzeit werden über &os.numports; Anwendungen Dritter zur Verfügung gestellt. Ein &os;-Paket enthält vorkompilierte Kopien aller Befehle für eine Anwendung, sowie zusätzliche Konfigurationsdateien und Dokumentation. Pakete können mit den pkg-Befehlen, wie pkg install, manipuliert werden. Ein &os;-Port ist eine Sammlung von Dateien, die das Kompilieren der Quelltexte einer Anwendung automatisieren. Die Dateien, die ein Port umfasst enthalten alle notwendigen Informationen um die Anwendung herunterzuladen, zu extrahieren, anzupassen und zu installieren. Das Portsystem kann auch dazu benutzt werden, Pakete zu generieren, die mit den Paketverwaltungswerkzeugen von &os; manipuliert werden können. Pakete und Ports beachten Abhängigkeiten zwischen Anwendungen. Wenn ein Paket oder die Ports-Sammlung benutzt wird, um eine Anwendung zu installieren, dann werden fehlende Bibliotheken zuerst installiert, sofern sie nicht schon vorher installiert waren. Obwohl beide Technologien gleichartig sind, so haben Pakete und Ports jeweils ihre eigenen Stärken. Welche Technologie eingesetzt wird, hängt letzten Endes von den Anforderungen ab, die an eine bestimmte Anwendung gestellt werden. Vorteile von Paketen Das komprimierte Paket einer Anwendung ist normalerweise kleiner als das komprimierte Archiv der Quelltexte. Pakete müssen nicht mehr kompiliert werden. Dies ist ein Vorteil, wenn große Pakete wie Mozilla, KDE oder GNOME auf langsamen Maschinen installiert werden. Wenn Sie Pakete verwenden, brauchen Sie nicht zu verstehen, wie Software unter &os; kompiliert wird. Vorteile von Ports Da die Pakete auf möglichst vielen System laufen sollen, werden Optionen beim Übersetzen zurückhaltend gesetzt. Wird eine Anwendung über die Ports übersetzt, können die Optionen nach eigenen Bedürfnissen angepasst werden. Die Eigenschaften einiger Anwendungen werden über Optionen zum Zeitpunkt des Übersetzens festgelegt. Apache kann zum Beispiel über eine große Auswahl an eingebauten Optionen konfiguriert werden. Für einige Fälle existieren verschiedene Pakete einer Anwendung, die beim Übersetzen unterschiedlich konfiguriert wurden. Für Ghostscript gibt es ein ghostscript-Paket und ein ghostscript-nox11-Paket, die sich durch die Xorg Unterstützung unterscheiden. Das Erstellen von verschiedenen Paketen wird aber schnell unhandlich, wenn eine Anwendung mehr als ein oder zwei Optionen zum Zeitpunkt des Übersetzens besitzt. Die Lizenzbestimmungen mancher Software verbietet ein Verbreiten in binärer Form. Diese Software muss als Quelltext, der durch den Benutzer kompiliert werden muss, ausgeliefert werden. Einige Leute trauen binären Distributionen nicht, oder sie ziehen es vor den Quelltext zu lesen, um diesen nach möglichen Problemen zu durchsuchen. Der Quellcode wird benötigt, um individuelle Anpassungen anzuwenden. Wenn Sie über aktualisierte Ports informiert sein wollen, lesen Sie die Mailinglisten &a.ports; und &a.ports-bugs;. Bevor Sie eine Anwendung installieren, informieren Sie sich auf der Seite http://vuxml.FreeBSD.org/ über mögliche Sicherheitsprobleme mit der Anwendung, oder installieren Sie ports-mgmt/portaudit. Installierte Anwendungen können mit portaudit -F -a auf bekannte Sicherheitsprobleme untersucht werden. Der Rest dieses Kapitels beschreibt, wie man Software Dritter mit Paketen und Ports unter &os; installiert und verwaltet. Suchen einer Anwendung Die Anzahl der nach &os; portierten Anwendungen steigt ständig. Es gibt einige Wege, um nach Anwendungen zu suchen: Die &os;-Webseite stellt unter http://www.FreeBSD.org/ports/ eine aktuelle und durchsuchbare Liste aller Anwendungen zur Verfügung. Die Ports können nach dem Namen den Anwendung, oder über die Software-Kategorie durchsucht werden. FreshPorts Dan Langille verwaltet FreshPorts.org, das eine umfassende Suchfunktion bietet und Änderungen an den Anwendungen in der Ports-Sammlung verfolgt. Registrierte Benutzer können eine Merkliste erstellen, um automatisch eine E-Mail zu erhalten, sobald ein Port von dieser Liste aktualisiert wurde. Freecode Wenn Sie den Namen einer Anwendung nicht kennen, versuchen Sie eine Webseite wie Freecode.com, um eine passende Anwendung zu finden. Schauen Sie dann auf der &os;-Webseite nach, ob die Anwendung schon portiert wurde. Wenn die Ports-Sammlung bereits installiert ist, gibt es mehrere Methoden, um die lokale Version dieser Port-Sammlung abzufragen. Verwenden Sie whereis Datei um herauszufinden, in welcher Kategorie ein Port ist, wobei Datei der Name des Programms ist, das installiert werden soll: &prompt.root; whereis lsof lsof: /usr/ports/sysutils/lsof Alternativ kann der &man.echo.1;-Befehl verwendet werden: &prompt.root; echo /usr/ports/*/*lsof* /usr/ports/sysutils/lsof Beachten Sie aber, dass dieser Befehl auch alle Dateien im Verzeichnis /usr/ports/distfiles findet, auf die der angegebene Suchbegriff passt. Ein weiterer Weg nach Software zu suchen besteht darin, die eingebaute Suchfunktion der Ports-Sammlung zu benutzen. Wechseln Sie dazu in das Verzeichnis /usr/ports, und rufen Sie make search name=Anwendungsname auf, wobei Anwendungsname der Name der Software ist. Um zum Beispiel nach lsof zu suchen: &prompt.root; cd /usr/ports &prompt.root; make search name=lsof Port: lsof-4.88.d,8 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Maint: ler@lerctr.org Index: sysutils B-deps: R-deps: Der integrierte Suchmechanismus verwendet eine Datei mit Index-Informationen. Erscheint eine Meldung, dass der INDEX benötigt wird, führen Sie make fetchindex aus, um die aktuelle Index-Datei herunterzuladen. Mit einem vorhandenen INDEX ist make search in der Lage, die gewünschte Suche durchzuführen. Die Path:-Zeile zeigt an, wo der Port zu finden ist. Um weniger Informationen zu erhalten, benutzen Sie die Funktion quicksearch: &prompt.root; cd /usr/ports &prompt.root; make quicksearch name=lsof Port: lsof-4.88.d,8 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Erweiterte Suchen führen Sie mit make search key=Text oder make quicksearch key=Text aus. Damit werden Portnamen, Kommentare, Beschreibungen und Abhängigkeiten nach Text durchsucht. Dies kann sehr nützlich sein, wenn der Name des Programms nicht bekannt ist. Bei der Verwendung von search und quicksearch wird Groß- und Kleinschreibung bei der Suche ignoriert. Die Suche nach LSOF wird dieselben Ergebnisse wie die Suche nach lsof liefern. Benutzen von <application>pkgng</application> zur Verwaltung von Binärpaketen pkgng ist der Nachfolger für die traditionellen Paketverwaltungswerkzeuge von &os;. Es bietet viele Funktionen, die den Umgang mit Binärpaketen schneller und einfacher machen. pkgng ist kein Ersatz für die Portverwaltungswerkzeuge wie ports-mgmt/portmaster oder ports-mgmt/portupgrade. Während diese Werkzeuge Drittanbieter-Software sowohl aus Binärpaketen als auch aus der Ports-Sammlung installieren können, so installiert pkgng ausschließlich Binärpakete. Erste Schritte mit <application>pkgng</application> &os; 8.4 und nachfolgende Versionen enthalten ein Bootstrap-Programm, welches pkgng zusammen mit den Manualpages installiert. Um das Bootstrap Programm zu starten, geben Sie folgendes ein: &prompt.root; /usr/sbin/pkg Für ältere Versionen von &os; muss pkgng zunächst aus der Ports-Sammlung oder als Paket installiert werden. Um den Port zu installieren, geben Sie folgendes ein: &prompt.root; cd /usr/ports/ports-mgmt/pkg &prompt.root; make &prompt.root; make install clean Um das Paket zu installieren, geben Sie folgendes ein: &prompt.root; pkg_add -r pkg Sobald pkgng installiert ist, muss die Paketdatenbank mit dem folgenden Befehl vom traditionellen Format in das neue Format konvertiert werden: &prompt.root; pkg2ng Auf neu installieren Systemen, auf denen noch keine Software von Drittanbietern installiert wurde, kann dieser Schritt entfallen. Die Konvertierung ist unwiderruflich. Sobald die Paketdatenbank in das Format von pkgng umgewandelt wurde, sollten die traditionellen pkg_* Werkzeuge nicht mehr benutzt werden. Bei der Konvertierung der Paketdatenbank können Fehler ausgegeben werden, wenn die Inhalte auf die neue Version umgewandelt werden. Im Allgemeinen können diese Fehler ignoriert werden. Wenn pkg2ng fertig ist, wird eine Liste von Drittanbieter-Software ausgegeben, die nicht erfolgreich konvertiert werden konnte. Diese Anwendungen müssen manuell neu installiert werden. Um sicherzustellen, dass die &os; Ports-Sammlung neue Pakete mit pkgng und nicht mit den traditionellen Formaten registriert, muss in &os; 10.X und früheren Versionen folgende Zeile in /etc/make.conf hinzugefügt werden: WITH_PKGNG= yes Das pkgng Paketverwaltungssystem benutzt für die meisten Operationen ein Paket-Repository. Der Speicherort des Paket-Repositories wird in /usr/local/etc/pkg.conf oder der Umgebungsvariablen PACKAGESITE definiert. Weitere Konfigurationsoptionen für pkgng sind in &man.pkg.conf.5; beschrieben. Informationen zur Bedienung von pkgng ist in &man.pkg.8; verfügbar. Alternativ kann pkg ohne zusätzliche Argumente aufgerufen werden. Jedes Argument von pkgng ist in seiner spezifischen Manualpage dokumentiert. Um beispielsweise die Manualpage von pkg install zu lesen, geben Sie einen der folgenden Befehle ein: &prompt.root; pkg help install &prompt.root; man pkg-install Der Rest dieses Abschnitts beschreibt die typischen Verwaltungsaufgaben für Binärpakete, die mit pkgng erledigt werden können. Jedes gezeigte Kommando verfügt über Optionen, um das Verhalten anzupassen. Details und weitere Beispiele finden Sie in den Manualpages der einzelnen Kommandos. Informationen über installierte Pakete anzeigen Informationen über bereits installierte Pakete können mit pkg info angezeigt werden. Dabei wird, wenn keine weiteren Optionen angegeben werden, die Version und die Beschreibung aller Pakete oder eines einzelnen Pakets ausgegeben. Um zu ermitteln welche Version von pkgng installiert ist, geben Sie folgendes ein: &prompt.root; pkg info pkg pkg-1.1.4_1 Installation und Deinstallation von Paketen Ein Binärpaket installieren Sie mit dem folgenden Befehl, wobei paketname der Name des zu installierenden Pakets ist: &prompt.root; pkg install paketname Dieser Befehl verwendet Daten aus dem Repository um zu bestimmen, welche Version der Software und welche Abhängigkeiten installiert werden müssen. Um beispielsweise curl zu installieren: &prompt.root; pkg install curl Updating repository catalogue /usr/local/tmp/All/curl-7.31.0_1.txz 100% of 1181 kB 1380 kBps 00m01s /usr/local/tmp/All/ca_root_nss-3.15.1_1.txz 100% of 288 kB 1700 kBps 00m00s Updating repository catalogue The following 2 packages will be installed: Installing ca_root_nss: 3.15.1_1 Installing curl: 7.31.0_1 The installation will require 3 MB more space 0 MB to be downloaded Proceed with installing packages [y/N]: y Checking integrity... done [1/2] Installing ca_root_nss-3.15.1_1... done [2/2] Installing curl-7.31.0_1... done Cleaning up cache files...Done Das neue Paket und jedes weitere Paket, das als Abhängigkeit installiert wurde, ist in der Liste der installierten Pakete zu sehen: &prompt.root; pkg info ca_root_nss-3.15.1_1 The root certificate bundle from the Mozilla Project curl-7.31.0_1 Non-interactive tool to get files from FTP, GOPHER, HTTP(S) servers pkg-1.1.4_6 New generation package manager Wird ein Paket nicht mehr benötigt, kann es mit pkg delete entfernt werden. Zum Beispiel: &prompt.root; pkg delete curl The following packages will be deleted: curl-7.31.0_1 The deletion will free 3 MB Proceed with deleting packages [y/N]: y [1/1] Deleting curl-7.31.0_1... done Installierte Pakete aktualisieren Pakete die nicht mehr aktuell sind, können mit pkg version gefunden werden. &man.pkg-version.8; nutzt zur Identifikation der Paketversionen die lokale Ports-Sammlung, falls diese installiert ist. Ansonsten wird dazu das entfernte Repository benutzt. Installierte Pakete können mit pkg upgrade auf die neuesten Versionen aktualisiert werden. Mit diesem Befehl werden die installierten Versionen der Pakete mit denen im Repository verglichen. Es wird dann eine Liste der Anwendungen ausgegeben, für die neuere Versionen zur Verfügung stehen. Geben Sie y ein, um die Aktualisierung durchzuführen, oder n, um die Aktualisierung abzubrechen. Installierte Pakete auditieren Gelegentlich werden Sicherheitslücken in einer Drittanbieter-Software entdeckt. pkgng besitzt einen eingebauten Auditing-Mechanismus. Um die auf dem System installierte Software auf Sicherheitslücken zu prüfen, geben Sie folgenden Befehl ein: &prompt.root; pkg audit -F Automatisches Entfernen von nicht mehr benötigten Abhängigkeiten Das Entfernen eines Pakets kann möglicherweise Abhängigkeiten hinterlassen, die nicht mehr benötigt werden. Unnötige Pakete, die als Abhängigkeit von anderen Paketen installiert wurden, können automatisch erfasst und entfernt werden: &prompt.root; pkg autoremove Packages to be removed: ca_root_nss-3.15.1_1 The autoremoval will free 723 kB Proceed with autoremoval of packages [y/N]: y Deinstalling ca_root_nss-3.15.1_1... done Sicherung der Paketdatenbank Im Gegensatz zum alten Paketverwaltungssystem beinhaltet pkgng einen eigenen Mechanismus zur Sicherung der Paketdatenbank. Um den Inhalt der Paketdatenbank manuell zu sichern, geben Sie folgendes ein, und ersetzen Sie pkgng.db durch einen geeigneten Namen: &prompt.root; pkg backup -d pkgng.db Zusätzlich verfügt pkgng über ein &man.periodic.8;-Skript, das automatisch eine tägliche Sicherung der Paketdatenbank erstellt. Diese Funktionalität kann aktiviert werden, indem in &man.periodic.conf.5; daily_backup_pkgng_enable auf YES gesetzt ist. Um das Skript daran zu hindern, eine Sicherung der Paketdatenbank zu erstellen, muss in &man.periodic.conf.5; daily_backup_pkgdb_enable auf NO gesetzt werden. Um den Inhalt einer früheren Paketdatenbank wiederherzustellen, geben Sie folgendes ein: &prompt.root; pkg backup -r /path/to/pkgng.db Alte Pakete entfernen Standardmäßig speichert pkgng Pakete in einem Cache-Verzeichnis, welches in &man.pkg.conf.5; in der Variablen PKG_CACHEDIR definiert wird. Beim Upgrade der Pakete mit pkg upgrade, werden die alten Versionen der Pakete nicht automatisch entfernt. Um veraltete Pakete zu entfernen, geben Sie folgendes ein: &prompt.root; pkg clean Manipulation der Paket-Metadaten Bei Software aus der &os; Ports-Sammlung kann es vorkommen, dass die Hauptversionsnummer geändert wird. Dafür hat pkgng ein eingebautes Kommando, um die Quelle eines Pakets zu aktualisieren. Dies ist nützlich, wenn zum Beispiel lang/php5 zu lang/php53 umbenannt wurde, damit lang/php5 jetzt die Version 5.4 integrieren kann. Um die Quelle des Pakets für das obige Beispiel zu ändern, geben Sie folgendes ein: &prompt.root; pkg set -o lang/php5:lang/php53 Ein weiteres Beispiel: Um lang/ruby18 auf lang/ruby19 zu aktualisieren, geben Sie folgendes ein: &prompt.root; pkg set -o lang/ruby18:lang/ruby19 In diesem letzten Beispiel wird die Quelle der Bibliotheken von libglut von graphics/libglut auf graphics/freeglut geändert: &prompt.root; pkg set -o graphics/libglut:graphics/freeglut Bei einem Wechsel der Paketquelle ist es notwendig, die Pakete neu zu installieren, welche von dem Paket abhängig sind, das seine Paketquelle geändert hat. Um eine Neuinstallation von abhängigen Paketen zu erzwingen, führen Sie folgenden Befehl aus: &prompt.root; pkg install -Rf graphics/freeglut Benutzen der Ports-Sammlung Die Ports-Sammlung ist eine Reihe von Makefiles, Patches und Beschreibungen, die unter /usr/ports gespeichert sind. Diese Dateien werden für den Bau und die Installation von Anwendungen unter &os; verwendet. Bevor eine Anwendung aus den Ports erstellt werden kann, muss zuerst die Ports-Sammlung installiert werden. Wenn Sie dies nicht bereits bei der Installation von &os; getan haben, benutzen Sie eine der beiden Methoden um sie zu installieren: Installation mit Portsnap &os;s Basissystem enthält mit Portsnap ein schnelles und benutzerfreundliches Werkzeug zur Installation der Ports-Sammlung und die bevorzugte Wahl für die meisten Benutzer. Dieses Programm stellt eine Verbindung zu einem &os;-Server her, überprüft den gesicherten Schlüssel und lädt eine aktuelle Kopie der Ports-Sammlung herunter. Der Schlüssel wird benötigt, um die Integrität der heruntergeladenen Dateien zu untersuchen. Laden Sie einen komprimierten Snapshot der Ports-Sammlung in /var/db/portsnap: &prompt.root; portsnap fetch Wenn Sie Portsnap das erste Mal verwenden, müssen Sie den Snapshot nach /usr/ports extrahieren: &prompt.root; portsnap extract Nach dem ersten Einsatz von Portsnap, kann /usr/ports wie folgt aktualisiert werden: &prompt.root; portsnap fetch &prompt.root; portsnap update Bei der Verwendung von fetch können die extract oder update Operationen nacheinander ausgeführt werden, etwa so: &prompt.root; portsnap fetch update Installation mit Subversion Wird mehr Kontrolle über die Ports-Sammlung benötigt, oder wenn die lokalen Änderungen beibehalten werden sollen, kann Subversion benutzt werden, um die Ports-Sammlung zu laden. Lesen Sie den Subversion Primer für eine detaillierte Beschreibung von Subversion. Subversion muss installiert sein, bevor die Ports-Sammlung geladen werden kann. Ist eine lokale Kopie der Ports-Sammlung bereits vorhanden, installieren Sie Subversion wie folgt: &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make install clean Wenn keine lokale Kopie der Ports-Sammlung vorhanden ist, oder pkgng zur Verwaltung von Paketen benutzt wird, kann Subversion als Paket installiert werden: &prompt.root; pkg install subversion Laden Sie eine Kopie der Ports-Sammlung: &prompt.root; svn checkout https://svn.FreeBSD.org/ports/head /usr/ports Nach dem erstmaligen checkout mit Subversion kann /usr/ports wie folgt aktualisiert werden: &prompt.root; svn update /usr/ports Die Ports-Sammlung installiert eine Reihe von Verzeichnissen, die jeweils eine Softwarekategorie repräsentieren. Jede Kategorie hat für jede einzelne Anwendung ein weiteres Unterverzeichnis. Jedes Unterverzeichnis enthält Dateien, die &os; sagen, wie ein Programm kompiliert und installiert werden muss. Diese Dateien werden auch Port-Gerüst genannt. Jedes Port-Gerüst beinhaltet die folgenden Dateien und Verzeichnisse: Makefile: enthält Anweisungen, die spezifizieren, wie die Anwendung kompiliert wird und wohin die Komponenten installiert werden sollten. distinfo: enthält die Namen und die Prüfsummen der Dateien, die heruntergeladen werden müssen, um den Port zu bauen. files: dieses Verzeichnis enthält Patches, welche das Übersetzen und Installieren der Anwendung unter &os; ermöglichen. Zudem können noch weitere Dateien, die für die Übersetzung des Ports verwendet werden, enthalten sein. pkg-descr: enthält eine ausführlichere Beschreibung der Anwendung. pkg-plist: eine Liste aller Dateien, die durch diesen Port installiert werden. Außerdem sind hier Informationen enthalten, die zum Entfernen des Ports benötigt werden. Einige Ports beinhalten noch pkg-message oder weitere Dateien, die vom Port-System benutzt werden, um spezielle Situationen zu handhaben. Wenn Sie mehr über diese Dateien oder das Port-System erfahren wollen, lesen Sie das &os; Porter's Handbook. Ein Port enthält nicht den eigentlichen Quellcode, der auch als Distfile bekannt ist. Der heruntergeladene Quellcode wird automatisch nach /usr/ports/distfiles extrahiert. Ports installieren Ports installieren Dieser Abschnitt beschreibt die grundlegende Benutzung der Ports-Sammlung, um Software zu installieren oder zu deinstallieren. Eine ausführliche Beschreibung der einzelnen make-Targets finden Sie in &man.ports.7;. Stellen Sie sicher, dass die Ports-Sammlung aktuell ist, bevor Sie einen Port kompilieren. Informieren Sie sich vorher zusätzlich unter http://vuxml.FreeBSD.org/ über mögliche Sicherheitsprobleme des zu installierenden Ports. Alternativ können Sie pkg audit -F ausführen, bevor Sie einen neuen Port installieren. Die täglich laufende Sicherheitsprüfung des Systems aktualisiert ebenfalls die Datenbank und prüft installierte Anwendungen auf vorhandene Sicherheitsprobleme. Weitere Informationen finden Sie in &man.portaudit.1; und &man.periodic.8;. Die Benutzung der Ports-Sammlung setzt eine funktionierende Internetverbindung und Superuser-Rechte voraus. Um einen Port zu installieren, wechseln Sie in das Verzeichnis des Ports, den Sie installieren möchten. Geben Sie dann make install am Prompt ein: &prompt.root; cd /usr/ports/sysutils/lsof &prompt.root; make install >> lsof_4.88D.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/. ===> Extracting for lsof-4.88 ... [Ausgabe des Auspackens weggelassen] ... >> Checksum OK for lsof_4.88D.freebsd.tar.gz. ===> Patching for lsof-4.88.d,8 ===> Applying FreeBSD patches for lsof-4.88.d,8 ===> Configuring for lsof-4.88.d,8 ... [configure-Ausgabe weggelassen] ... ===> Building for lsof-4.88.d,8 ... [Ausgabe der Übersetzung weggelassen] ... ===> Installing for lsof-4.88.d,8 ... [Ausgabe der Installation weggelassen] ... ===> Generating temporary packing list ===> Compressing manual pages for lsof-4.57 ===> Registering installation for lsof-4.57 ===> SECURITY NOTE: This port has installed the following binaries which execute with increased privileges. /usr/local/bin/lsof &prompt.root; Da lsof eine Anwendung ist, die mit erhöhten Rechten läuft, wird nach der Installation eine Sicherheitswarnung angezeigt. Sobald die Installation abgeschlossen ist, erscheint wieder der Prompt. Um die Suche nach Kommandos zu beschleunigen, speichern einige Shells eine Liste der verfügbaren Kommandos in den durch die Umgebungsvariable PATH gegebenen Verzeichnissen. Benutzer der tcsh müssen eventuell rehash eintippen, um die neu installierten Kommandos benutzen zu können, ohne den vollständigen Pfad anzugeben. Benutzer der Shell sh müssen stattdessen hash -r eintippen. Weitere Informationen finden Sie in der Dokumentation der jeweiligen Shell. Bei der Installation wird ein Arbeitsverzeichnis erstellt, das alle temporären Dateien enthält, die während des Bauvorgangs benötigt werden. Wenn dieses Verzeichnis nach der Installation entfernt wird, spart dies Plattenplatz und minimiert mögliche Probleme bei der Aktualisierung des Ports auf eine neuere Version: &prompt.root; make clean ===> Cleaning for lsof-4.88.d,8 &prompt.root; Sie können zwei Schritte sparen, wenn Sie bei der Kompilierung des Ports gleich make install clean eingeben. Port Installation anpassen Einige Ports bieten Optionen, mit denen zusätzliche Funktionen oder Sicherheitsoptionen eingestellt werden können. Beispiele dafür sind www/firefox, security/gpgme und mail/sylpheed-claws. Wenn ein Port von anderen Ports abhängig ist und diese über zusätzliche Abhängigkeiten und Optionen verfügen, wird mehrmals ein Menü ausgegeben, wo der Benutzer verschiedene Optionen wählen kann. Um dies zu vermeiden, wechseln Sie in das Verzeichnis des Ports und geben Sie make config-recursive ein, um die Konfiguration an einem Stück zu erledigen. Führen Sie danach make install [clean] aus, um den Port zu kompilieren und zu installieren. Bei der Verwendung von config-recursive wird eine Liste von Ports, die konfiguriert werden, vom Target all-depends-list erstellt. Es wird empfohlen, make config-recursive so lange auszuführen, bis alle Optionen der abhängigen Ports definiert sind und keine Optionen und Menüs mehr erscheinen. Damit soll sichergestellt werden, dass alle Optionen konfiguriert wurden. Es gibt diverse Möglichkeiten, dieses Menü nach dem Bau eines Ports erneut aufzurufen, um Optionen zu entfernen, hinzuzufügen oder anzupassen. Sie können beispielsweise mit cd in das Verzeichnis des Ports wechseln und dort make config eingeben. Eine andere Möglichkeit ist make showconfig. Eine weitere Alternative bietet make rmconfig, das alle ursprünglich gewählten Optionen zurücksetzt und es Ihnen dadurch ermöglicht, die Konfiguration erneut zu beginnen. Die eben erwähnten Optionen werden ausführlich in &man.ports.7; beschrieben. Die Ports-Sammlung benutzt zum Herunterladen von Dateien &man.fetch.3;, das diverse Umgebungsvariablen unterstützt. Die Variablen FTP_PASSIVE_MODE, FTP_PROXY und FTP_PASSWORD müssen unter Umständen gesetzt werden, wenn das &os;-System hinter einer Firewall oder einem FTP/HTTP-Proxy arbeitet. Eine vollständige Liste der unterstützten Variablen finden Sie in &man.fetch.1;. Benutzer ohne eine ständige Internet-Verbindung können make fetch im Verzeichnis /usr/ports ausführen, um die benötigten Dateien herunterzuladen. Es ist auch möglich, make fetch nur in einem Teil des Baums, wie /usr/ports/net, aufzurufen. Die Dateien von allen abhängigen Ports werden mit diesem Kommando allerdings nicht heruntergeladen. Wenn Sie diese Dateien ebenfalls herunterladen wollen, benutzen Sie stattdessen make fetch-recursive. In einigen seltenen Fällen ist es erforderlich, die benötigten Dateien von einem anderen Ort als den im Port definierten MASTER_SITES herunterzuladen. Sie können MASTER_SITES mit dem folgenden Kommando überschreiben: &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE= \ ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch Die Variablen WRKDIRPREFIX und PREFIX überschreiben das voreingestellte Bau- und Zielverzeichnis. Zum Beispiel: &prompt.root; make WRKDIRPREFIX=/usr/home/example/ports install Dieses Kommando baut den Port unter /usr/home/example/ports und installiert ihn unter /usr/local. Die Variable PREFIX legt das Installations-Verzeichnis fest: &prompt.root; make PREFIX=/usr/home/example/local install In diesem Beispiel wird der Port unter /usr/ports gebaut und nach /usr/home/example/local installiert. Sie können beide Variablen auch zusammen benutzen: &prompt.root; make WRKDIRPREFIX=../ports PREFIX=../local install Alternativ können diese Variablen auch als Umgebungsvariablen gesetzt werden. In der Manualpage Ihrer Shell finden Sie Anweisungen, wie Umgebungsvariablen gesetzt werden. Entfernen installierter Ports Ports entfernen Installierte Ports können mit pkg delete wieder deinstalliert werden. Beispiele für dieses Kommando finden Sie in &man.pkg-delete.8;. Alternativ kann make deinstall im Verzeichnis des Ports aufgerufen werden: &prompt.root; cd /usr/ports/sysutils/lsof make deinstall ===> Deinstalling for sysutils/lsof ===> Deinstalling Deinstallation has been requested for the following 1 packages: lsof-4.88.d,8 Thee deinstallation will free 229 kB [1/1] Deleting lsof-4.88.d,8... done Es wird empfohlen die Nachrichten zu lesen, die ausgegeben werden, wenn ein Port deinstalliert wird. Wenn der Port noch Anwendungen hat, die von ihm abhängig sind, werdenn diese am Bildschirm angezeigt, aber die Deinstallation wird forgesetzt. In solchen Fällen ist es besser, die Anwendung neu zu installieren, um fehlende Abhängigkeiten zu vermeiden. Ports aktualisieren Ports aktualisieren Im Laufe der Zeit stehen neuere Versionen der Software in der Ports-Sammlung zur Verfügung. In diesem Abschnitt wird beschrieben, wie Sie bestimmen, welche Software aktualisiert werden kann und wie das Upgrade durchzuführen ist. Um festzustellen, ob neuere Versionen der installierten Ports verfügbar sind, stellen Sie sicher, dass die neueste Version der Ports-Sammlung installiert ist. Diese wird in Prozedur 5.1 und Prozedur 5.2 beschrieben. Führen Sie anschließend den folgenden Befehl aus, um eine Liste der Ports zu erhalten für die eine aktuelle Version existiert: &prompt.root; pkg version -l "<" Lesen Sie zuerst /usr/ports/UPDATING, bevor Sie einen Port aktualisieren. In dieser Datei werden Probleme und zusätzlich durchzuführende Schritte bei der Aktualisierung einzelner Ports beschrieben. Dazu gehören solche Dinge wie geänderte Dateiformate, verschobene Konfigurationsdateien, aber auch Inkompatibilitäten zu einer Vorgängerversion. Notieren Sie sich alle Anweisungen der Ports, die aktualisiert werden müssen. Folgen Sie den Anweisungen, wenn Sie das Upgrade durchführen. Ports mit <application>Portmaster</application> aktualisieren portmaster ports-mgmt/portmaster ist ein sehr kleines Werkzeug zum Aktualisieren von Ports. Es wurde entwickelt, um mit den in &os; integrierten Werkzeugen zu arbeiten, ohne dabei von anderen Ports oder Datenbanken abhängig zu sein. Sie können das Programm aus der Ports-Sammlung installieren: &prompt.root; cd /usr/ports/ports-mgmt/portmaster &prompt.root; make install clean Portmaster teilt Ports in vier Kategorien ein: Root Port: hat keine Abhängigkeiten und andere Ports sind nicht von diesem Port abhängig. Trunk Port: hat keine Abhängigkeiten, aber andere Ports sind von diesem Port abhängig. Branch Port: hat Abhängigkeiten und andere Ports sind von diesem Port abhängig. Leaf Port: hat Abhängigkeiten, aber andere Ports sind nicht von diesem Port abhängig. Um eine Liste der installierten Ports anzuzeigen und nach neueren Versionen zu suchen, verwenden Sie: &prompt.root; portmaster -L ===>>> Root ports (No dependencies, not depended on) ===>>> ispell-3.2.06_18 ===>>> screen-4.0.3 ===>>> New version available: screen-4.0.3_1 ===>>> tcpflow-0.21_1 ===>>> 7 root ports ... ===>>> Branch ports (Have dependencies, are depended on) ===>>> apache22-2.2.3 ===>>> New version available: apache22-2.2.8 ... ===>>> Leaf ports (Have dependencies, not depended on) ===>>> automake-1.9.6_2 ===>>> bash-3.1.17 ===>>> New version available: bash-3.2.33 ... ===>>> 32 leaf ports ===>>> 137 total installed ports ===>>> 83 have new versions available Um alle installierten Ports zu aktualisieren, verwenden Sie folgenden Befehl: &prompt.root; portmaster -a In der Voreinstellung erzeugt Portmaster eine Sicherheitskopie, bevor ein installierter Port gelöscht wird. Ist die Installation der neuen Version erfolgreich, wird dieses Backup wieder gelöscht. Wollen Sie das Backup lieber manuell löschen, verwenden Sie die Option beim Aufruf von Portmaster. Durch die Verwendung von wird Portmaster im interaktiven Modus gestartet und fragt bei jedem zu aktualisierenden Port nach, wie weiter vorgegangen werden soll. Viele weitere Optionen stehen zur Verfügung. Lesen Sie die Manualpage von &man.portmaster.8; für weitere Einzelheiten in Bezug auf ihre Nutzung. Treten während der Aktualisierung Fehler auf, verwenden Sie die Option , um alle Ports zu aktualisieren beziehungsweise neu zu bauen: &prompt.root; portmaster -af Portmaster ist auch in der Lage, neue Ports zu installieren, wobei zuvor alle abhängigen Ports aktualisiert werden. Um diese Funktion zu nutzen, geben Sie den Pfad des Ports in der Ports-Sammlung an: &prompt.root; portmaster shells/bash Ports mit Portupgrade aktualisieren portupgrade Ein weiteres Werkzeug zur Aktualisierung von Ports ist Portupgrade, welches als Paket oder Port ports-mgmt/portupgrade zur Verfügung steht. Dieses Programm installiert eine Reihe von Anwendungen, die für die Verwaltung von Ports verwendet werden können. Das Programm ist jedoch von Ruby abhängig. Um den Port zu installieren, geben Sie ein: &prompt.root; cd /usr/ports/ports-mgmt/portupgrade &prompt.root; make install clean Durchsuchen Sie vor jedem Update die Liste der installierten Ports mit pkgdb -F und beheben Sie alle gefundenen Probleme. Benutzen Sie portupgrade -a, um automatisch alle veralteten Ports auf dem System zu aktualisieren. Verwenden Sie zusätzlich den Schalter , wenn Sie individuell entscheiden wollen, ob ein Port aktualisiert werden soll: &prompt.root; portupgrade -ai Um nur eine spezifische Anwendung zu aktualisieren, verwenden Sie portupgrade Paketname. Es ist wichtig den Schalter zu benutzen, um zuvor alle Ports zu aktualisieren, die von dem gegebenen Anwendung abhängen. &prompt.root; portupgrade -R firefox Um Pakete anstelle von Ports zu installieren, verwenden Sie den Schalter . Mit dieser Option durchsucht Portupgrade die in der Umgebungsvariablen PKG_PATH aufgeführten Verzeichnisse nach Paketen. Sind lokal keine Pakete vorhanden, versucht Portupgrade die Pakete über das Netz herunterzuladen. Gibt es die Pakete weder lokal noch auf entfernten Rechnern, werden die Ports verwendet. Um die Nutzung von Ports gänzlich zu verhindern, benutzen Sie die Option . Portupgrade würde dann abbrechen, falls keine Pakete zur Verfügung stehen. &prompt.root; portupgrade -PP gnome2 Wenn Sie nur die Quelldateien des Ports, oder die Pakete mit herunterladen möchten, ohne die Anwendung zu bauen oder zu installieren, geben Sie den Schalter an. Weitere Informationen zu den verfügbaren Schaltern finden Sie in der Manualpage von &man.portupgrade.1;. Platzbedarf von Ports Ports Plattenplatz Die Nutzung der Ports-Sammlung wird im Laufe der Zeit viel Plattenplatz verschlingen. Nach dem Bau und der Installation eines Ports, wird make clean die temporären Arbeitsverzeichnisse work aufräumen. Portmaster wird dieses Verzeichnis automatisch entfernen, wenn die Option verwendet wird. Wenn Portupgrade installiert ist, wird dieser Befehl alle Arbeitsverzeichnisse der lokalen Ports-Sammlung entfernen: &prompt.root; portsclean -C Zusätzlich werden sich im Laufe der Zeit zahlreiche veraltete Distfiles in /usr/ports/distfiles ansammeln. Wenn Portupgrade installiert ist, können mit dem folgenden Befehl alle Distfiles gelöscht werden, die vom keinem Port mehr benötigt werden: &prompt.root; portsclean -D Mit Portupgrade können Sie alle Distfiles löschen, die von keinem derzeit installierten Port benötigt werden: &prompt.root; portsclean -DD Wenn Portmaster installiert ist, benutzen Sie diesen Befehl: &prompt.root; portmaster --clean-distfiles In der Voreinstellung arbeitet dieses Programm interaktiv und fragt den Benutzer um Bestätigung, bevor ein Distfile gelöscht wird. Zusätzlich zu diesen Kommandos gibt es noch port-mgmt/pkg_cutleaves. Dieses Werkzeug automatisiert die Deinstallation von installierten Ports, die nicht weiter benötigt werden. Pakete mit <application>Poudriere</application> bauen Poudriere ist ein unter der BSD-Lizenz stehendes Werkzeug zum Erstellen und Testen von &os;-Paketen. Dieses Programm nutzt &os; Jails, um die Pakete in einer isolierten Umgebung zu bauen. Diese Jails können verwendet werden, um Pakete für andere Versionen von &os; zu bauen, oder um auf einem &arch.amd64;-System Pakete für i386 zu bauen. Sobald die Pakete gebaut sind, haben sie das gleiche Format wie auf den offiziellen Spiegeln. Die Pakete können dann mit &man.pkg.8; oder anderen Paketverwaltungswerkzeugen benutzt werden. Poudriere wird über das Paket oder den Port ports-mgmt/poudriere installiert. Die Installation beinhaltet eine Beispielkonfiguration in /usr/local/etc/poudriere.conf.sample. Kopieren Sie diese Datei nach /usr/local/etc/poudriere.conf. Bearbeiten Sie dann die kopierte Datei, um die Konfiguration anzupassen. Obwohl ZFS für poudriere nicht zwingend erforderlich ist, so hat die Nutzung doch einige Vorteile. Wird ZFS eingesetzt, muss in /usr/local/etc/poudriere.conf die Variable ZPOOL definiert, und die Variable FREEBSD_HOST auf einen nahe gelegenen Spiegel gesetzt werden. Die Definition von CCACHE_DIR erlaubt die Verwendung von devel/ccache, um die Bauzeit für häufig kompilierten Code verkürzen. Es kann vorteilhaft sein, die poudriere-Datasets in einem separaten Verzeichnis auf /poudriere einzuhängen. Die Werte der anderen Konfigurationsvariablen sind in der Regel angemessen und brauchen nicht geändert werden. Die Anzahl der Kerne im Prozessor wird verwendet um zu bestimmen, wie viele Bauprozesse parallel ausgeführt werden sollen. Stellen Sie ausreichend virtuellen Speicher bereit, entweder in Form von RAM oder als Swap-Speicher. Ist der virtuelle Speicher aufgebraucht, bricht der Bauprozess ab und die Jails stürzen ab, was zu seltsamen Fehlermeldungen führt. Jails und Ports-Sammlung initialisieren Nach der Konfiguration muss poudriere initialisiert werden, damit es eine Jail mit der benötigten Ports-Sammlung startet. Geben Sie mit den Namen der Jail und mit die gewünschte &os;-Version an. Auf &os;/&arch.amd64;-Systemen kann die Architektur mit dem Schalter und i386 oder amd64 gesetzt werden. Der voreingestellte Wert für die Architektur können Sie sich mit uname anzeigen lassen. &prompt.root; poudriere jail -c -j 10amd64 -v 10.0-RELEASE ====>> Creating 10amd64 fs... done ====>> Fetching base.txz for FreeBSD 10.0-RELEASE amd64 /poudriere/jails/10amd64/fromftp/base.txz 100% of 59 MB 1470 kBps 00m42s ====>> Extracting base.txz... done ====>> Fetching src.txz for FreeBSD 10.0-RELEASE amd64 /poudriere/jails/10amd64/fromftp/src.txz 100% of 107 MB 1476 kBps 01m14s ====>> Extracting src.txz... done ====>> Fetching games.txz for FreeBSD 10.0-RELEASE amd64 /poudriere/jails/10amd64/fromftp/games.txz 100% of 865 kB 734 kBps 00m01s ====>> Extracting games.txz... done ====>> Fetching lib32.txz for FreeBSD 10.0-RELEASE amd64 /poudriere/jails/10amd64/fromftp/lib32.txz 100% of 14 MB 1316 kBps 00m12s ====>> Extracting lib32.txz... done ====>> Cleaning up... done ====>> Jail 10amd64 10.0-RELEASE amd64 is ready to be used &prompt.root; poudriere ports -c -p local ====>> Creating local fs... done ====>> Extracting portstree "local"... Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Feb 11 01:07:15 CET 2014: 94a3431f0ce567f6452ffde4fd3d7d3c6e1da143efec76100% of 69 MB 1246 kBps 00m57s Extracting snapshot... done. Verifying snapshot integrity... done. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Tue Feb 11 01:07:15 CET 2014 to Tue Feb 11 16:05:20 CET 2014. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 48 patches. (48/48) 100.00% done. done. Applying patches... done. Fetching 1 new ports or files... done. /poudriere/ports/tester/CHANGES /poudriere/ports/tester/COPYRIGHT [...] Building new INDEX files... done. poudriere kann auf einem einzelnen Rechner Ports mit mehreren Konfigurationen bauen, in mehreren Jails und aus unterschiedlichen Ports-Sammlungen. Spezifische Konfigurationen für diese Kombinationen werden Sets genannt. Lesen Sie den Abschnitt CUSTOMIZATION in &man.poudriere.8; für weitere Einzelheiten nach der Installation von port-mgmt/poudriere oder ports-mgmt/poudriere-devel. Die hier gezeigte Konfiguration verwendet eine einzelne Jail-, Port- und Set-spezifische make.conf in /usr/local/etc/poudriere.d. Der verwendete Dateiname in diesem Beispiel wird aus einer Kombination von Jailnamen, Portnamen und Setnamen zusammen gesetzt: 10amd64-local-workstation-make.conf. Die make.conf des Systems und diese neue Datei werden verwendet, um die make.conf für die Jail zu erzeugen. Die zu bauenden Pakete werden in 10amd64-local-workstation-pkglist eingetragen: editors/emacs devel/git ports-mgmt/pkg ... Die Optionen und Abhängigkeiten für die Ports werden wie folgt konfiguriert: &prompt.root; poudriere options -j 10amd64 -p local -z workstation -f 10amd64-local-workstation-pkglist Schließlich werden die Pakete gebaut und ein Paket-Repository erstellt: &prompt.root; poudriere bulk -j 10amd64 -p local -z workstation -f 10amd64-local-workstation-pkglist Ctrlt zeigt den aktuellen Status des Baus an. Poudriere speichert zudem Dateien in /poudriere/logs/bulk/jailname. Diese Dateien kann ein Webserver nutzen, um Informationen über den Bau anzuzeigen. Die Pakete stehen jetzt im poudriere Repository für die Installation zur Verfügung. Weitere Informationen zu poudriere finden Sie in &man.poudriere.8; und unter . Konfiguration des pkg-Clients für das Poudriere Repository Obwohl es möglich ist ein eigenes Repository zusammen mit dem offiziellen Repository zu nutzen, ist es manchmal sinnvoll das offizielle Repository zu deaktivieren. Dazu wird eine Konfigurationsdatei erstellt, welche die offizielle Konfigurationsdatei überschreibt. Erzeugen Sie dazu /usr/local/etc/pkg/repos/FreeBSD.conf mit dem folgenden Inhalt: FreeBSD: { enabled: no } Am einfachsten ist es, das poudriere Repository über HTTP zur Verfügung zu stellen. Setzen Sie einen Webserver auf, der die Dateien des Paketverzeichnisses ausliefert, zum Beispiel /usr/local/poudriere/data/packages/10amd64. 10amd64 bezeichnet dabei den Namen des Baus. Wenn die URL des Paket Repositories http://pkg.example.com/10amd64 ist, dann sollte die Konfiguration des Repositories in /usr/local/etc/pkg/repos/custom.conf wie folgt aussehen: custom: { url: "http://pkg.example.com/10amd64", enabled: yes, } Nach der Installation Unabhängig davon, ob die Software aus einem binären Paket oder aus einem Port installiert wird, benötigen die meisten Anwendungen von Drittanbietern ein gewisses Maß an Konfiguration, nachdem sie installiert wurden. Die folgenden Kommandos und Speicherorte helfen Ihnen dabei festzustellen, was mit der Anwendung zusammen installiert wurde. Die meisten Anwendungen installieren mindestens eine Konfigurationsdatei nach - /usr/local/etc. Die - Konfigurationsdateien sollten überprüft und ggf. bearbeitet - werden, um die Anforderungen des Systems zu erfüllen. + /usr/local/etc. Falls die Anwendung + viele Konfigurationsdateien enthält, wird ein + Unterverzeichnis erstellt um die Dateien zu speichern. Oft + werden die Konfigurationsdateien mit einem Suffix wie + beispielsweise .sample installiert. + Die Konfigurationsdateien sollten überprüft und ggf. + bearbeitet werden, um die Anforderungen des Systems zu + erfüllen. Um eine Konfigurationsdatei zu bearbeiten, + kopieren Sie diese zunächst ohne die Erweiterung + .sample. Wenn die Anwendung Dokumentation zur Verfügung stellt, wird diese nach /usr/local/share/doc installiert. Viele Anwendungen installieren auch Manualpages. Diese Dokumentation sollten Sie lesen, bevor Sie fortfahren. Einige Anwendungen laufen als Dienst und müssen vor dem ersten Start in /etc/rc.conf eingetragen werden. Diese Anwendungen installieren meist ein Skript in /usr/local/etc/rc.d. Weitere Informationen finden Sie im . Benutzer der &man.csh.1; sollten rehash ausführen, um die neu installierten Programme nutzen zu können. Benutzen Sie pkg info, um die Dateien, Manualpages und Binaries zu ermitteln, die mit der Anwendung installiert wurden. Kaputte Ports Wenn sich ein Port nicht bauen oder installieren lässt, versuchen Sie folgendes: Stellen Sie fest, ob die Datenbank mit den Problemberichten bereits einen Lösungsvorschlag enthält. Ist dies der Fall, kann die vorgeschlagene Lösung getestet werden. Bitten Sie den Betreuer des Ports um Hilfe. Geben Sie dazu make maintainer ein oder lesen Sie das Makefile im Verzeichnis des Ports, um an die E-Mail-Adresse zu kommen. Vergessen Sie nicht die Zeile mit $FreeBSD: aus dem Makefile und die Ausgabe bis zur Fehlermeldung mitzuschicken. Einige Ports werden nicht von einer Einzelperson, sondern von einer Mailingliste betreut. Viele (aber nicht alle) dieser Adressen haben die Form freebsd-NameDerListe@FreeBSD.org. Denken Sie daran, wenn Sie Ihre Fragen formulieren. Dies gilt insbesondere für Ports, die als Betreuer den Eintrag ports@FreeBSD.org aufweisen. Derartige Ports haben überhaupt keinen Betreuer. Korrekturen und Unterstützung kommen daher nur von Personen, die diese Mailingliste abonniert haben. Gerade in diesem Bereich werden jederzeit zusätzliche freiwillige Helfer benötigt! Erhalten Sie auf Ihre Anfrage keine Antwort, benutzen Sie Bugzilla, um einen Problembericht zu erstellen. Bevor Sie einen solchen Bericht erstellen, lesen Sie den Artikel Writing &os; Problem Reports. Reparieren Sie ihn! Das &os; Porter's Handbook enthält eine detaillierte Beschreibung des Portsystems. Damit sind Sie in der Lage, einen zeitweilig kaputten Port zu reparieren oder einen eigenen Port zu erstellen. Installieren Sie das Paket anstelle des Ports. Anweisungen hierzu finden Sie in .