Index: head/de_DE.ISO8859-1/books/handbook/config/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/config/chapter.xml (revision 52476) +++ head/de_DE.ISO8859-1/books/handbook/config/chapter.xml (revision 52477) @@ -1,3831 +1,3831 @@ 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 (). 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. Jede Zeile in diesen Dateien definiert eine auszuführende Aufgabe, die auch als Cronjob bezeichnet wird. Das Werkzeug verwendet zwei verschiedene Konfigurationsdateien: die System-crontab, welche nicht verändert werden sollte und die Benutzer-crontabs, die nach Bedarf erstellt und geändert werden können. Das Format, dass von diesen beiden Dateien verwendet wird, ist in &man.crontab.5; dokumentiert. Das Format der System-crontab in /etc/crontab enthält das Feld who, das in der Benutzer-crontab nicht existiert. Dieses Feld gibt den Benutzer an, mit dem die Aufgabe ausgeführt wird. Die Aufgaben in den Benutzer-crontabs laufen unter dem Benutzer, der die crontab erstellt hat. Benutzer-crontabs erlauben es den Benutzern, ihre eigenen Aufgaben zu planen. Der Benutzer root kann auch seine eigene Benutzer-crontab haben, um Aufgaben zu planen, die nicht in der System-crontab existieren. 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 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 der System-crontab beschrieben: minute, hour, mday, month, wday, who und command. Das Feld minute legt die Minute fest in der die Aufgabe ausgeführt wird, 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 System-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 Werte für den Cronjob. Die Zeichenfolge */5 gefolgt von mehreren *-Zeichen bedeutet, dass /usr/libexec/atrun von root alle fünf Minuten aufgerufen wird. Bei den Kommandos können beliebig viele 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. Eine Benutzer-crontab erstellen Rufen Sie crontab im Editor-Modus auf, um eine Benutzer-crontab zu erstellen: &prompt.user; crontab -e Dies wird die crontab des Benutzers mit dem voreingestellten Editor öffnen. Wenn der Benutzer diesen Befehl zum ersten Mal ausführt, wird eine leere Datei geöffnet. Nachdem der Benutzer eine crontab erstellt hat, wird die Datei mit diesem Kommando zur Bearbeitung geöffnet. Es empfiehlt sich, die folgenden Zeilen an den Anfang der crontab-Datei hinzuzufügen, um die Umgebungsvariablen zu setzen und die einzelnen Felder zu beschreiben: SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin # Order of crontab fields # minute hour mday month wday command Fügen Sie dann für jedes Kommando oder Skript eine Zeile hinzu, mit der Angabe wann das Kommando ausgeführt werden soll. In diesem Beispiel wird ein Bourne Shell Skript täglich um 14:00 Uhr ausgeführt. Da der Pfad zum Skript nicht in PATH enthalten ist, wird der vollständige Pfad zum Skript angegeben: 0 14 * * * /usr/home/dru/bin/mycustomscript.sh Bevor Sie ein eigenes Skript verwenden, stellen Sie sicher, dass es ausführbar ist und dass es mit den wenigen Umgebungsvariablen von cron funktioniert. Um die Umgebung nachzubilden, die der obige cron-Eintrag bei der Ausführung verwenden würde, benutzen Sie dieses Kommando: &prompt.user; env -i SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/home/dru LOGNAME=dru /usr/home/dru/bin/mycustomscript.sh Die Umgebung von cron wird in &man.crontab.5; beschrieben. Es ist wichtig, dass sichergestellt wird, dass die Skripte in der Umgebung von cron korrekt arbeiten, besonders wenn Befehle enthalten sind, welche Dateien mit Wildcards löschen. Wenn Sie mit der Bearbeitung der crontab fertig sind, speichern Sie die Datei. Sie wird automatisch installiert und cron wird die darin enthalten Cronjobs zu den angegebenen Zeiten ausführen. Um die Cronjobs in einer crontab aufzulisten, verwenden Sie diesen Befehl: &prompt.user; crontab -l 0 14 * * * /usr/home/dru/bin/mycustomscript.sh Um alle Cronjobs einer Benutzer-crontab zu löschen, verwenden Sie diesen Befehl: &prompt.user; crontab -r remove crontab for dru? y 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 Beispiel 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 wird /etc/rc.conf nicht überschrieben, so dass die Systemkonfiguration erhalten bleibt. /etc/rc.conf und /etc/rc.conf.local werden 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. Die Systemmeldungen können Sie sich mit more /var/run/dmesg.boot ansehen. Mit der Leertaste können Sie durch den Text blättern. 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. Wenn es im LAN einen DHCP-Server gibt, fügen Sie einfach folgende Zeile hinzu: ifconfig_dc0="DHCP" Ersetzen Sie >dc0 durch die richtigen Werte für das System. Nachdem Sie die Zeile hinzugefügt haben, folgen Sie den Anweisungen in . Wenn das Netzwerk 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. Falls kein DHCP-Server zur Verfügung steht, müssen die Netzwerkkarten manuell konfiguriert werden. 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, &man.ifconfig.8; und &man.rc.conf.5; enthalten weitere Einzelheiten über verfügbare Optionen und die Syntax von /etc/rc.conf. 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. Fügen Sie dazu die Namen und IP-Adressen der Rechner im LAN in /etc/hosts hinzu, falls sie nicht bereits vorhanden sind. Weitere Informationen finden Sie in &man.hosts.5; und /usr/share/examples/etc/hosts. 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 Netzwerkkabel? Sind die Netzwerkdienste richtig konfiguriert? Funktioniert die Firewall? Wird die Netzwerkkarte 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" Dies kann mit einer durch Leerzeichen getrennten Liste von IP-Adressbereichen auch einfacher ausgedrückt werden. Die erste Adresse hat wieder die angegebene Netzwerkmaske und die zusätzlichen Adressen haben die Netzwerkmaske 255.255.255.255. ifconfig_fxp0_aliases="inet 10.1.1.1-5/24 inet 202.0.75.17-20/28" Konfiguration der Systemprotokollierung Niclas Zeising Beigetragen von system logging syslog &man.syslogd.8; Die Aufzeichnung und Kontrolle von Log-Meldungen ist ein wichtiger Aspekt der Systemadministration. Die Informationen werden 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. Die meisten Systemdienste und Anwendungen erzeugen Log-Meldungen. &os; stellt mit syslogd ein Werkzeug zur Verwaltung von Protokollen bereit. In der Voreinstellung wird syslogd beim Booten automatisch gestartet. Dieses Verhalten wird über die Variable syslogd_enable in /etc/rc.conf gesteuert. Dazu gibt es noch zahlreiche Argumente, die in der Variable syslogd_flags in /etc/rc.conf gesetzt werden können. Lesen Sie &man.syslogd.8; für weitere Informationen über die verfügbaren Argumente. Dieser Abschnitt beschreibt die Konfiguration und Verwendung des &os; Protokollservers, und diskutiert auch die Log-Rotation und das Management von Logdateien. Konfiguration der lokalen Protokollierung syslog.conf Die Konfigurationsdatei /etc/syslog.conf steuert, was syslogd mit Log-Meldungen macht, sobald sie empfangen werden. Es gibt verschiedene Parameter, die das Verhalten bei eingehenden Ereignissen kontrollieren. 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 !* In diesem Beispiel: Zeile 8 selektiert alle Meldungen vom Level err, sowie kern.warning, auth.notice und mail.crit und schickt diese zur Konsole (/dev/console). Zeile 12 selektiert alle Meldungen von mail ab dem Level info oder höher und schreibt diese in /var/log/maillog. Zeile 17 benutzt ein Vergleichsflag (=), um nur Meldungen vom Level debug zu selektieren und schreibt diese in /var/log/debug.log. Zeile 33 zeigt 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 werden alle Meldungen von ppp (und keinem anderen Programm) in /var/log/ppp.log geschrieben. Die verfügbaren 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. Um alle Meldungen vom Level notice und höher in /var/log/daemon.log zu protokollieren, fügen Sie folgenden Eintrag 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;. Management und Rotation von Logdateien newsyslog newsyslog.conf log rotation log management Logdateien können schnell wachsen und viel Speicherplatz belegen, was es schwieriger macht, nützliche Informationen zu finden. Log-Management versucht, diesen Effekt zu mildern. &os; verwendet newsyslog für die Verwaltung von Logdateien. Dieses in &os; integrierte Programm rotiert und komprimiert in regelmäßigen Abständen Logdateien. Optional kann es auch fehlende Logdateien erstellen und Programme benachrichtigen, wenn Logdateien verschoben wurden. Die Logdateien können von syslogd oder einem anderen Programm generiert werden. Obwohl newsyslog normalerweise von &man.cron.8; aufgerufen wird, ist es kein Systemdämon. In der Standardkonfiguration wird dieser Job jede Stunde ausgeführt. Um zu wissen, welche Maßnahmen zu ergreifen sind, liest newsyslog seine Konfigurationsdatei /etc/newsyslog.conf. Diese Konfigurationsdatei enthält eine Zeile für jede Datei, die von newsyslog 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 Logdateien rotiert werden. Hier folgt die Standardkonfiguration in &os;: # configuration file for newsyslog # $FreeBSD$ # # 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 Protokolldatei, 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 und wann die Datei rotiert wird. Weitere Informationen zu allen Feldern, gültigen Flags und wie Sie die Rotationszeit angeben können, finden Sie in &man.newsyslog.conf.5;. Denken Sie daran, dass newsyslog von &man.cron.8; aufgerufen wird und somit Dateien auch nur dann rotiert, wenn es von &man.cron.8; aufgerufen wird, und nicht häufiger. Protokollierung von anderen Hosts Tom Rhodes Beigetragen von Benedict Reuschling Übersetzt von Die Überwachung der Protokolldateien kann bei steigender Anzahl von Rechnern sehr unhandlich werden. Eine zentrale Protokollierung kann manche administrativen Belastungen bei der Verwaltung von Protokolldateien reduzieren. Die Aggregation, Zusammenführung und Rotation von Protokolldateien kann in &os; mit syslogd und newsyslog konfiguriert werden. In der folgenden Beispielkonfiguration sammelt Host A, genannt logserv.example.com, Protokollinformationen für das lokale Netzwerk. Host B, genannt logclient.example.com wird seine Protokollinformationen an den Server weiterleiten. Konfiguration des Protokollservers Ein Protokollserver ist ein System, welches Protokollinformationen von anderen Hosts akzeptiert. Bevor Sie diesen Server konfigurieren, prüfen Sie folgendes: Falls eine Firewall zwischen dem Protokollserver und den -Clients steht, muss das Regelwerk der Firewall UDP auf Port 514 sowohl auf Client- als auch auf Serverseite freigegeben werden. Der syslogd-Server und alle Clientrechner müssen gültige Einträge für sowohl Vorwärts- als auch Umkehr-DNS besitzen. Falls im Netzwerk kein DNS-Server vorhanden ist, muss auf jedem System die Datei /etc/hosts mit den richtigen Einträgen gepflegt werden. Eine funktionierende Namensauflösung ist zwingend erforderlich, ansonsten würde der Server die Protokollnachrichten ablehnen. Bearbeiten Sie /etc/syslog.conf auf dem Server. Tragen Sie den Namen des Clients ein, den Verbindungsweg und den Namen der Protokolldatei. Dieses Beispiel verwendet den Rechnernamen B, alle Verbindungswege, und die Protokolle werden in /var/log/logclient.log gespeichert. Einfache Server Konfiguration +logclient.example.com *.* /var/log/logclient.log Fügen Sie für jeden Client zwei Zeilen hinzu, falls Sie mehrere Clients in diese Datei aufnehmen. Weitere Informationen über die verfügbaren Verbindungswege finden Sie in &man.syslog.conf.5;. Konfigurieren Sie als nächstes /etc/rc.conf: syslogd_enable="YES" syslogd_flags="-a logclient.example.com -v -v" Der erste Eintrag startet syslogd während des Bootens. Der zweite Eintrag erlaubt es, Daten von dem spezifizierten Client auf diesem Server zu akzeptieren. Die Verwendung von erhöht die Anzahl von Protokollnachrichten. Dies ist hilfreich für die Feineinstellung der Verbindungswege, da Administratoren auf diese Weise erkennen, welche Arten von Nachrichten von welchen Verbindungswegen protokolliert werden. Mehrere -Optionen können angegeben werden, um die Protokollierung von mehreren Clients zu erlauben. IP-Adressen und ganze Netzblöcke können ebenfalls spezifiziert werden. Eine vollständige Liste der Optionen finden Sie in &man.syslogd.8;. Zum Schluss muss die Protokolldatei erstellt werden: &prompt.root; touch /var/log/logclient.log Zu diesem Zeitpunkt sollte syslogd neu gestartet und überprüft werden: &prompt.root; service syslogd restart &prompt.root; pgrep syslog Wenn eine PID zurückgegeben wird, wurde der Server erfolgreich neu gestartet und die Clientkonfiguration kann beginnen. Wenn der Server nicht neu gestartet wurde, suchen Sie in /var/log/messages nach dem Fehler. Konfiguration des Protokollclients Ein Protokollclient sendet Protokollinformationen an einen Protokollserver. Zusätzlich behält er eine lokale Kopie seiner eigenen Protokolle. Sobald der Server konfiguriert ist, bearbeiten Sie /etc/rc.conf auf dem Client: syslogd_enable="YES" syslogd_flags="-s -v -v" Der erste Eintrag aktiviert den syslogd-Dienst während des Systemstarts. Der zweite Eintrag erhöht die Anzahl der Protokollnachrichten. Die Option verhindert, dass dieser Client Protokolle von anderen Hosts akzeptiert. Als nächstes muss der Protokollserver in der /etc/syslog.conf des Clients eingetragen werden. In diesem Beispiel wird das @-Symbol benutzt, um sämtliche Protokolldaten an einen bestimmten Server zu senden: *.* @logserv.example.com Nachdem die Änderungs gespeichert wurden, muss syslogd neu gestartet werden, damit die Änderungen wirksam werden: &prompt.root; service syslogd restart Um zu testen, ob Protokollnachrichten über das Netzwerk gesendet werden, kann &man.logger.1; auf dem Client benutzt werden, um eine Nachricht an syslogd zu schicken: &prompt.root; logger "Test message from logclient" Diese Nachricht sollte jetzt sowohl in /var/log/messages auf dem Client, als auch in /var/log/logclient.log auf dem Server vorhanden sein. Fehlerbehebung beim Protokollserver Wenn der Server keine Nachrichten empfängt, ist die Ursache wahrscheinlich ein Netzwerkproblem, ein Problem bei der Namensauflösung oder ein Tippfehler in einer Konfigurationsdatei. Um die Ursache zu isolieren, müssen Sie sicherstellen, dass sich Server und Client über den in /etc/rc.conf konfigurierten Hostnamen mit ping erreichen lässt. Falls dies nicht gelingt sollten Sie die Netzwerkverkabelung überprüfen, außerdem Firewallregeln sowie die Einträge für Hosts im DNS und /etc/hosts. Überprüfen Sie diese Dinge auf dem Server und dem Client, bis der ping von beiden Hosts erfolgreich ist. Wenn sich die Hosts gegenseitig mit ping erreichen können, der Server aber immer noch keine Nachrichten empfängt, können Sie vorübergehend die Ausführlichkeit der Protokollierung erhöhen, um die Ursache für das Problem weiter einzugrenzen. In dem folgenden Beispiel ist auf dem Server die Datei /var/log/logclient.log leer und in der Datei /var/log/messages auf dem Client ist keine Ursache für das Problem erkennbar. Um nun die Ausführlichkeit der Protokollierung zu erhöhen, passen Sie auf dem Server den Eintrag syslogd_flags an. Anschließend starten Sie den Dienst neu: syslogd_flags="-d -a logclient.example.com -v -v" &prompt.root; service syslogd restart Informationen wie diese werden sofort nach dem Neustart auf der Konsole erscheinen: logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; rejected in rule 0 due to name mismatch. In diesem Beispiel werden die Nachrichten aufgrund eines fehlerhaften Namens abgewiesen. Der Hostname sollte logclient und nicht logclien sein. Beheben Sie den Tippfehler, starten Sie den Dienst neu und überprüfen Sie das Ergebnis: &prompt.root; service syslogd restart logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from logserv.example.com, msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; accepted in rule 0. logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2 Logging to FILE /var/log/logclient.log Logging to FILE /var/log/messages Zu diesem Zeitpunkt werden die Nachrichten korrekt empfangen und in die richtige Datei geschrieben. Sicherheitsbedenken Wie mit jedem Netzwerkdienst, müssen Sicherheitsanforderungen in Betracht gezogen werden, bevor ein Protokollserver eingesetzt wird. Manchmal enthalten Protokolldateien sensitive Daten über aktivierte Dienste auf dem lokalen Rechner, Benutzerkonten und Konfigurationsdaten. Daten, die vom Client an den Server geschickt werden, sind weder verschlüsselt noch mit einem Passwort geschützt. Wenn ein Bedarf für Verschlüsselung besteht, ist es möglich security/stunnel zu verwenden, welches die Protokolldateien über einen verschlüsselten Tunnel versendet. Lokale Sicherheit ist ebenfalls ein Thema. Protokolldateien sind während der Verwendung oder nach ihrer Rotation nicht verschlüsselt. Lokale Benutzer versuchen vielleicht, auf diese Dateien zuzugreifen, um zusätzliche Einsichten in die Systemkonfiguration zu erlangen. Es ist absolut notwendig, die richtigen Berechtigungen auf diesen Dateien zu setzen. Das Werkzeug newsyslog unterstützt das Setzen von Berechtigungen auf gerade erstellte oder rotierte Protokolldateien. Protokolldateien mit Zugriffsmodus 600 sollten verhindern, dass lokale Benutzer darin herumschnüffeln. Zusätzliche Informationen finden Sie in &man.newsyslog.conf.5;. 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. /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. # $&os;$ # # # 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 Leistungsverlusten 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 Absturzes 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 Dateisystems 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.soacceptqueue</varname> kern.ipc.soacceptqueue Die &man.sysctl.8;-Variable kern.ipc.soacceptqueue 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 optimalen 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 herabzusetzen. 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 Festplatte oder einer existierenden Partition Das Hinzufügen einer neuen Festplatte für den Swap-Bereich bietet eine bessere Leistung, als die Verwendung 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 swapon 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 swapon auf einer Partition ausgeführt die Daten enthält, werden die vorhandenen Daten überschrieben und sind unweigerlich verloren. Stellen Sie sicher, dass die Partition, die Sie als Swap-Bereich hinzufügen möchten, wirklich die gewünschte Partition ist, bevor Sie swapon 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. Weitere Informationen zu swapon finden Sie in &man.swapon.8;. Swap-Dateien erstellen Anstatt eine Partition zu verwenden, erstellen diese Beispiele eine 64 MB große Swap-Datei mit dem Namen /usr/swap0. Die Verwendung von Swap-Dateien macht es erforderlich, dass das Modul &man.md.4; entweder im Kernel vorhanden oder geladen wird, bevor Swap aktiviert ist. enthält Informationen zum Bau eines angepassten Kernels. Erstellen einer Swap-Datei unter &os; 10.<replaceable>X</replaceable> und neuer Erstellen Sie die Swap-Datei: &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Setzen Sie die richtigen Berechtigungen für die neue Datei: &prompt.root; chmod 0600 /usr/swap0 Fügen Sie einen Eintrag in /etc/fstab hinzu: md99 none swap sw,file=/usr/swap0,late 0 0 Das &man.md.4; Gerät md99 wird verwendet, damit die niedrigeren Gerätenummer für die interaktive Benutzung frei bleiben. Der Swap-Speicher wird nun automatisch beim Systemstart hinzugefügt. Benutzen Sie &man.swapon.8; um den Swap-Speicher direkt zu aktivieren: &prompt.root; swapon -aL Erstellen einer Swap-Datei unter &os; 9.<replaceable>X</replaceable> und älter Erstellen Sie die Swap-Datei /usr/swap0: &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 Setzen Sie die richtigen Berechtigungen für die neue Datei: &prompt.root; chmod 0600 /usr/swap0 Aktivieren Sie die Swap-Datei in /etc/rc.conf: swapfile="/usr/swap0" # Set to name of swap file Um die Swap-Datei sofort zu aktivieren, spezifizieren Sie ein speicherbasiertes Laufwerk. enthält weitere Informationen. &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. Energie- und Ressourcenverwaltung ermöglicht es dem System auf verschiedene Ereignisse, beispielsweise einen unerwarteten Temperaturanstieg, reagieren zu können. Eine frühe Spezifikation für die Energieverwaltung war das Advanced Power Management (APM). APM steuert den Energieverbrauch eines Systems auf Basis der Systemaktivität. Ursprünglich 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 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 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 in vielen Situationen ebenfalls unzureichend. Das PNPBIOS verwendet eine 16-Bit-Technik. Damit das Betriebssystem das PNPBIOS ansprechen kann, muss es in einer 16-Bit-Emulation laufen. &os; stellt einen APM-Treiber zur Verfügung, welcher für Systeme benutzt werden sollte, die vor dem Jahr 2000 hergestellt wurden. Der Treiber wird in &man.apm.4; beschrieben. ACPI APM Der Nachfolger von APM ist das Advanced Configuration and Power Interface (ACPI). ACPI ist ein Standard verschiedener Hersteller, welcher die Verwaltung von Hardware und Energiesparfunktionen festlegt. Die ACPI-Funktionen, die mehr Kontrolle und Flexibilität bieten, können vom Betriebssystem gesteuert werden. Dieser Abschnitt zeigt die Konfiguration von ACPI unter &os;. Zudem werden einige Tipps zur Fehlersuche vorgestellt und wie Sie Problemberichte einreichen können, sodass Entwickler ACPI-Probleme erfassen und beheben können. Konfiguration des <acronym>ACPI</acronym> Der &man.acpi.4;-Treiber wird standardmäßig beim Systemstart vom &man.loader.8; geladen und sollte daher nicht fest in den Kernel eingebunden werden. Der Treiber kann im laufenden Betrieb nicht entfernt werden, da er zur Kommunikation mit der Hardware verwendet wird. Falls jedoch Probleme auftreten, kann ACPI auch komplett deaktiviert werden. Dazu muss hint.acpi.0.disabled="1" in /boot/loader.conf gesetzt und anschließend das System neu gestartet werden. Alternativ können Sie diese Variable auch am &man.loader.8;-Prompt eingeben, wie in beschrieben. 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 acpiconf 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 Befehl halt -p. Verschiedene Optionen können mit sysctl gesetzt werden. Lesen Sie dazu &man.acpi.4; sowie &man.acpiconf.8;. Häufige Probleme 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. ACPI Probleme mit Damit ACPI richtig funktioniert, müssen alle Teile funktionieren. Im Folgenden finden Sie eine Liste mit Problemen und möglichen Abhilfen oder Korrekturen. Die Liste ist nach der Häufigkeit, mit der die Probleme auftreten, sortiert. Wenn eine Korrektur das Problem nicht behebt, finden Sie in Anweisungen, wie Sie einen Problembericht einreichen können. 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. Suspend/Resume ACPI kennt drei Suspend-to-RAM-Zustände (STR), S1-S3 sowie einen Suspend-to-Disk-Zustand (STD) S4. STD 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. 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. Benutzen Sie sysctl hw.acpi um die Suspend-Zustände zu ermitteln. Diese Beispielausgabe stammt von einem Thinkpad: 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, S4 und S5 eingestellt werden können. Hätte den Wert 1, gäbe es den Zustand S4BIOS anstelle von S4. 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. 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, entladen Sie soviele Treiber wie möglich. Wenn das funktioniert, laden Sie einen Treiber nach dem anderen, 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 1. 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. 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. BIOS mit fehlerhaftem Bytecode 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 suchen. Die voreingestellte <acronym>ASL</acronym> überschreiben Der BIOS-Bytecode, bekannt als ACPI Maschine Language (AML) wird aus der Sprache namens ACPI Source Language (ASL) übersetzt. Die AML ist in einer Tabelle, bekannt als Differentiated System Description Table (DSDT), abgelegt. ACPI ASL Es ist das Ziel von &os;, dass ACPI ohne Eingriffe des Benutzers läuft. Zurzeit werden allerdings noch Abhilfen 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. Um bei der Fehlersuche zu helfen und das Problem möglicherweise zu beheben, kann eine Kopie der ASL gemacht werden. Dazu nutzen Sie acpidump zusammen mit , um den Inhalt der Tabelle anzuzeigen und , um die AML zu zerlegen: &prompt.root; acpidump -td > my.asl 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 2009". Manche Abhilfen erfordern eine Anpassung von my.asl. Wenn diese Datei bearbeitet wird, erstellen Sie die neue ASL mit dem folgenden Befehl. Warnung können meistens ignoriert werden, aber Fehler verhindern die ordnungsgemäße Funktion von ACPI. &prompt.root; iasl -f my.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 &os; Interpreter umgangen. Die voreingestellte Ausgabedatei von iasl ist 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 und starten Sie das System neu. Wenn dadurch das Problem behoben wird, schicken Sie einen &man.diff.1; der alten und der neuen ASL an &a.acpi.name;, damit die Entwickler das Problem in acpica umgehen können. Abrufen und Einreichen von Informationen zur Fehlersuche Nate Lawson Geschrieben von Peter Schultz Mit Beiträgen von Tom Rhodes 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 layer angegeben und in Komponenten (ACPI_ALL_COMPONENTS) und ACPI-Hardware (ACPI_ALL_DRIVERS) aufgeteilt. Welche Meldungen ausgegeben werden, wird über level gesteuert. Die Level reichen von von ACPI_LV_ERROR (es werden nur Fehler ausgegeben) bis zu ACPI_LV_VERBOSE (alles wird ausgegeben). Das 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 Kopieren Sie anschließend acpi.ko ins 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-Komponenten und alle Hardwaretreiber: 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 sysctl dieselben Variablennamen wie in /boot/loader.conf an. ACPI Probleme mit Sobald Sie die Fehlerinformationen gesammelt haben, schicken Sie diese an &a.acpi.name;, sodass die Betreuer des &os;-ACPI-Subsystems diese Informationen zur Analyse und für die Entwicklung einer Lösung verwenden können. Bevor Sie einen Fehlerbericht an diese Mailingliste einreichen, stellen Sie bitte sicher, dass das BIOS und die Firmware des Controllers aktuell sind. Wenn Sie einen Fehlerbericht einsenden, fügen Sie bitte die folgenden Informationen ein: 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 dmesg nach der Eingabe von boot -v. Geben Sie auch alle Fehlermeldungen an, die erscheinen, wenn Sie den Fehler provozieren. Die Ausgabe von dmesg 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 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. + (PR) 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. Referenzen Weitere Informationen über ACPI finden Sie hier: Die &os; ACPI Mailingliste (https://lists.freebsd.org/pipermail/freebsd-acpi/) Die ACPI 2.0 Spezifikation (http://acpi.info/spec.htm) &man.acpi.4;, &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8; und &man.acpidb.8; Index: head/de_DE.ISO8859-1/books/handbook/mail/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/mail/chapter.xml (revision 52476) +++ head/de_DE.ISO8859-1/books/handbook/mail/chapter.xml (revision 52477) @@ -1,2161 +1,2161 @@ Elektronische Post (E-Mail) Bill Lloyd Ursprüglicher Text von Jim Mock Neugeschrieben von Robert Drehmel Übersetzt von Terminologie E-Mail Terminologie Das Akronym MTA steht für Mail Transfer Agent was übersetzt Mailübertragungs-Agent bedeutet. Während die Bezeichnung Server-Dämon die Komponente eines MTA benennt, die für eingehende Verbindungen zuständig ist, wird mit dem Begriff Mailer öfters die Komponente des MTA bezeichnet, die E-Mails versendet. Übersicht E-Mail Elektronische Post, besser bekannt als E-Mail, ist eine der am weit verbreitetsten Formen der Kommunikation heutzutage. Dieses Kapitel bietet eine grundlegende Einführung in das Betreiben eines E-Mail-Servers unter &os;. Ebenfalls wird der Versand und Empfang von E-Mails unter &os; behandelt. Eine umfassende Betrachtung zu diesem Thema finden Sie in den Büchern, die in aufgelistet sind. Dieses Kapitel behandelt die folgenden Punkte: Welche Software-Komponenten beim Senden und Empfangen von elektronischer Post involviert sind. Wo sich grundlegende Sendmail Konfigurationsdateien in &os; befinden. Den Unterschied zwischen entfernten und lokalen Postfächern. Wie man Versender von Spam daran hindern kann, E-Mail-Server illegalerweise als Weiterleitung zu verwenden. Wie man einen alternativen MTA installiert und konfiguriert, um Sendmail zu ersetzen. Wie man oft auftretende E-Mail-Server Probleme behebt. Wie E-Mails über einen Relay verschickt werden. Wie E-Mails über eine Einwahlverbindung gehandhabt werden. Wie SMTP-Authentifizierung einrichtet wird. Den Empfang und den Versand von E-Mails mithilfe von Programmen wie mutt. Wie E-Mails von einem entfernten Server mit POP oder IMAP abgeholt werden. Wie eingehende E-Mail automatisch gefiltert wird. Bevor Sie dieses Kapitel lesen, sollten Sie: Die Netzwerk-Verbindung richtig einrichten. (). Die DNS-Information für einen E-Mail-Server einstellen (). Wissen, wie man zusätzliche Dritthersteller-Software installiert (). E-Mail Komponenten POP IMAP DNS E-Mail-Server Dämonen Sendmail E-Mail-Server Dämonen Postfix E-Mail-Server Dämonen qmail E-Mail-Server Dämonen Exim E-Mails empfangen MX-Eintrag E-Mail-Server Es gibt fünf größere Komponenten die am Austausch von E-Mails beteiligt sind: der Mail User Agent (MUA), der Mail Transfer Agent (MTA), der Mail Host, ein entferntes oder lokales Postfach, sowie DNS. Dieser Abschnitt enthält eine Übersicht über diese Komponenten. Mail User Agent (MUA) Der Mail User Agent (MUA) ist das Benutzerprogramm zum Verfassen, Senden und Empfangen von E-Mails. Diese Anwendung kann ein Kommandozeilenprogramm sein, wie das in &os; enthaltene Programm mail, oder ein Programm aus der Ports-Sammlung wie beispielsweise mutt, alpine oder elm. In der Ports-Sammlung sind auch dutzende von grafischen Programmen verfügbar, darunter ClawsMail, Evolution und Thunderbird. Einige Unternehmen bieten auch ein Web-Mail-Programm an, das über einen Webbrowser verwaltet werden kann. Weitere Informationen zur Installation und Verwendung von MUAs unter &os; finden Sie im . Mail Transfer Agent (MTA) Der Mail Transfer Agent (MTA) ist ein E-Mail-Server Daemon, welcher für dem Empfang von eingehenden E-Mails und für den Versand von ausgehenden E-Mails verantwortlich ist. &os; wird mit Sendmail als Standard-MTA ausgeliefert, aber es unterstützt auch weitere E-Mail-Server, darunter Exim, Postfix und qmail. Die Konfiguration von Sendmail wird im beschrieben. Wenn Sie einen anderen MTA aus der Ports-Sammlung installieren, lesen Sie die Nachrichten die nach der Installation der Anwendung ausgegeben werden, wenn Sie &os; spezifische Informationen benötigen. Allgemeine Informationen zur Konfiguration finden Sie in der Regel auf der Webseite des Herstellers. Mail Host und Postfächer Der Mail Host ist für die Zustellung und das Empfangen von E-Mails für den Rechner oder eines Netzwerks zuständig. Der Mail Host empfängt alle E-Mails für eine Domäne und speichert diese entweder im voreingestellten mbox-Format, oder im Maildir-Format. Diese E-Mails können lokal mit einem Benutzerprogramm MUA gelesen werden. Mithilfe von Protokollen wie POP oder IMAP können die E-Mails auch von entfernten Rechnern gelesen werden. Wenn die E-Mails direkt auf dem Mail Host gelesen werden, wird kein POP- oder IMAP-Server benötigt. Um auf entfernte Postfächer zuzugreifen, wird ein Zugang zu einem POP- oder IMAP-Server benötigt. Beide Protokolle ermöglichen es Benutzern, auf ein entferntes Postfach zuzugreifen. IMAP bietet gegenüber POP einige Vorteiler. Dazu zählt die Fähigkeit eine Kopie aller Nachrichten auf einem entfernten Server zu speichern, sowie gleichzeitig ablaufende Aktualisierungen. IMAP kann auch über langsame Verbindungen nützlich sein, da nicht gleich die komplette Nachricht heruntergeladen wird. Weiterhin können E-Mails auf dem Server durchsucht werden, was den Datenverkehr zwischen Clients und dem Server minimiert. Die Ports-Sammlung enthält einige POP- und IMAP-Server, darunter mail/qpopper, mail/imap-uw, mail/courier-imap und mail/dovecot2. Beachten Sie, dass sowohl POP als auch IMAP Daten, wie den Benutzernamen und das Passwort, im Klartext übertragen. Um die Übermittlung von Daten über diese Protokolle zu schützen, können Sie Sitzungen über &man.ssh.1; () tunneln oder SSL () verwenden. Domain Name System (DNS) Das Domain Name System (DNS) und sein Daemon named spielen eine große Rolle bei der Auslieferung von E-Mails. Um E-Mails auszuliefern, fragt der MTA im DNS den Rechner ab, der E-Mails für das Zielsystem entgegennimmt. Der gleiche Vorgang läuft ab, wenn eine E-Mail von einem entfernten Server zum MTA zugestellt wird. Im DNS werden Rechnernamen auf IP-Adressen abgebildet. Daneben werden spezielle Informationen für das Mail-System gespeichert, die MX-Einträge (MX record) genannt werden. Der MX-Eintrag (von Mail eXchanger) gibt an, welche Rechner E-Mails für eine Domäne annehmen. Mit &man.host.1; können die MX-Einträge für eine Domäne abgefragt werden: &prompt.root; host -t mx FreeBSD.org FreeBSD.org mail is handled by 10 mx1.FreeBSD.org Weitere Informationen zu DNS und dessen Konfiguration finden Sie im . <application>Sendmail</application>-Konfigurationsdateien Christopher Shumway Beigesteuert von Sendmail Sendmail ist der standardmäßig in &os; installierte MTA. Es nimmt E-Mails von E-Mail-Benutzerprogrammen (MUA) entgegen und liefert diese zu den entsprechenden Mail Hosts, die in der Konfigurationsdatei definiert sind. Sendmail kann auch Netzwerkverbindungen annehmen und E-Mails an lokale Mailboxen, oder an andere Programme ausliefern. Die Konfigurationsdateien von Sendmail befinden sich in /etc/mail. In diesem Abschnitt werden diese Dateien im Detail beschrieben. /etc/mail/access /etc/mail/aliases /etc/mail/local-host-names /etc/mail/mailer.conf /etc/mail/mailertable /etc/mail/sendmail.cf /etc/mail/virtusertable /etc/mail/access Diese Datenbank bestimmt, welche Rechner oder IP-Adressen Zugriff auf den lokalen Mail-Server haben und welche Art von Zugriff ihnen gestattet wird. Rechner die als aufgelistet sind, was der Standard ist, sind berechtigt E-Mails zu diesem Rechner zu schicken, solange die endgültige Zieladresse der lokale Rechner ist. Rechner die als aufgelistet sind, werden abgelehnt. Rechner die als aufgelistet sind, wird es erlaubt Post für jede Zieladresse durch diesen Mail-Server zu senden. Rechner die als aufgelistet sind, bekommen ihre E-Mail mit einem speziellen Fehler zurück. Wenn ein Rechner als aufgelistet ist, wird Sendmail die aktuelle Suche abbrechen, ohne die E-Mail zu akzeptieren oder abzulehnen. E-Mails von Rechnern die als aufgelistet sind, werden vorerst zurückgehalten. Dem sendenden Rechner wird ein festgelegter Text als Grund für die Quarantäne zurückgeschickt. Beispiele für die Verwendung dieser Optionen für IPv4- und IPv6-Adressen finden Sie in der Beispielkonfiguration /etc/mail/access.sample: # $FreeBSD$ # # Mail relay access control list. Default is to reject mail unless the # destination is local, or listed in /etc/mail/local-host-names # ## Examples (commented out for safety) #From:cyberspammer.com ERROR:"550 We don't accept mail from spammers" #From:okay.cyberspammer.com OK #Connect:sendmail.org RELAY #To:sendmail.org RELAY #Connect:128.32 RELAY #Connect:128.32.2 SKIP #Connect:IPv6:1:2:3:4:5:6:7 RELAY #Connect:suspicious.example.com QUARANTINE:Mail from suspicious host #Connect:[127.0.0.3] OK #Connect:[IPv6:1:2:3:4:5:6:7:8] OK Um die Datenbank zu konfigurieren, verwenden Sie das im Beispiel gezeigte Format, um Einträge in /etc/mail/access hinzuzufügen, aber setzen Sie kein Kommentarsymbol (#) vor die Einträge. Erstellen Sie einen Eintrag für jeden Rechner, dessen Zugriff konfiguriert werden soll. E-Mail-Versender, die mit der linken Spalte der Tabelle übereinstimmen, sind betroffen von der Aktion in der rechten Spalte. Immer wenn diese Datei verändert wurde, muss die Datenbank aktualisiert und Sendmail neu gestartet werden: &prompt.root; makemap hash /etc/mail/access < /etc/mail/access &prompt.root; service sendmail restart /etc/mail/aliases Diese Datenbank enthält eine Liste der virtuellen Mailboxen, die in andere Benutzer, Dateien, Programme oder andere Aliase expandiert werden. Hier sind ein paar Beispiele, die das Dateiformat verdeutlichen: root: localuser ftp-bugs: joe,eric,paul bit.bucket: /dev/null procmail: "|/usr/local/bin/procmail" Der Name der Mailbox auf der linken Seite des Doppelpunkts wird mit den Zielen auf der rechten Seite ersetzt. Der erste Eintrag ersetzt die Mailbox root mit der Mailbox localuser, die dann in der Datenbank /etc/mail/aliases gesucht wird. Wird kein passender Eintrag gefunden, wird die Nachricht zum localuser geliefert. Der zweite Eintrag zeigt eine E-Mail-Verteilerliste. E-Mails an ftp-bugs werden zu den drei lokalen Mailboxen joe, eric und paul gesendet. Eine entfernte Mailbox kann auch als user@example.com angegeben werden. Der dritte Eintrag zeigt wie E-Mails in eine Datei geschrieben werden, in diesem Fall /dev/null. Der letzte Eintrag verdeutlicht das Senden von E-Mails an ein Programm. Hier wird die Nachricht über eine &unix; Pipe an /usr/local/bin/procmail gesendet. Weitere Informationen zu dem Format dieser Datei finden Sie in &man.aliases.5;. Wenn diese Datei geändert wird, muss newaliases ausgeführt werden, um die Datenbank zu aktualisieren. /etc/mail/sendmail.cf Dies ist die Hauptkonfigurations-Datei von Sendmail. Sie kontrolliert das allgemeine Verhalten von Sendmail, einschließlich allem vom Umschreiben von E-Mail Adressen bis hin zum Übertragen von Ablehnungsnachrichten an entfernte E-Mail-Server. Dementsprechend ist die Konfigurationsdatei ziemlich komplex. Glücklicherweise muss diese Datei selten für Standard E-Mail-Server geändert werden. Die Sendmail Hauptkonfigurationsdatei kann mit &man.m4.1; Makros erstellt werden, die Eigenschaften und Verhalten von Sendmail definieren. Einige der Details finden Sie in /usr/src/contrib/sendmail/cf/README. Wenn Änderungen an dieser Datei vorgenommen werden, muss Sendmail neu gestartet werden, damit die Änderungen Wirkung zeigen. /etc/mail/virtusertable Diese Datenbank ordnet Adressen für virtuelle Domänen und Benutzern reellen Mailboxen zu. Diese Mailboxen können lokal, auf entfernten Systemen, Aliase in /etc/mail/aliases oder eine Datei sein. Dadurch können mehrere virtuelle Domains auf einem Rechner gehostet werden. &os; enthält eine Beispielkonfiguration in /etc/mail/virtusertable.sample, die das Format genauer beschreibt. Das folgende Beispiel zeigt, wie benutzerdefinierte Einträge in diesem Format erstellt werden: root@example.com root postmaster@example.com postmaster@noc.example.net @example.com joe Diese Datei wird nach dem ersten übereinstimmenden Eintrag durchsucht. Wenn eine E-Mail-Adresse mit der Adresse auf der linken Seite übereinstimmt, wird sie dem Eintrag auf der rechten Seite zugeordnet. Der erste Eintrag in diesem Beispiel ordnet eine bestimmte E-Mail-Adresse einer lokalen Mailbox zu, während der zweite Eintrag eine bestimmte E-Mail-Adresse einer entfernten Mailbox zuordnet. Zuletzt wird jede E-Mail-Adresse von example.com, welche nicht mit einem der vorherigen Einträge übereinstimmt, mit dem letzten Eintrag übereinstimmen und der lokalen Mailbox joe zugeordnet. Benutzen Sie dieses Format, wenn Sie neue Einträge in /etc/mail/virtusertable hinzufügen. Jedes Mal, wenn diese Datei bearbeitet wurde, muss die Datenbank aktualisiert und Sendmail neu gestartet werden: &prompt.root; makemap hash /etc/mail/virtusertable < /etc/mail/virusertable &prompt.root; service sendmail restart /etc/mail/relay-domains In der standardmäßigen &os;-Installation wird Sendmail nur dazu konfiguriert, E-Mails von dem Rechner, auf dem es läuft, zu senden. Wenn zum Beispiel ein POP-Server installiert ist, können Benutzer ihre E-Mails von entfernten Standorten überprüfen. Sie werden jedoch keine E-Mails von außen verschicken können. Typischerweise wird ein paar Sekunden nach dem Versuch eine E-Mail von MAILER-DAEMON mit einer 5.7 Relaying Denied Fehlermeldung versendet werden. Die einfachste Lösung ist, wie im folgenden Beispiel gezeigt, den FQDN des Internet-Dienstanbieters und gegebenenfalls weitere Adressen in /etc/mail/relay-domains einzutragen: your.isq.example.com other.isp.example.net users.isp.example.org www.example.org Nachdem diese Datei erstellt oder editiert wurde, muss Sendmail mittels service sendmail restart neu gestartet werden. Ab jetzt wird jede E-Mail, die von einem in der Liste eingetragenen Rechner durch das System geschickt wird, ihr Ziel erreichen, vorausgesetzt der Benutzer hat einen Account auf dem System. Dies erlaubt es Benutzern aus der Ferne, E-Mails über das System zu versenden, ohne dem Massenversand (SPAM) die Tür zu öffnen. Wechseln des Mailübertragungs-Agenten Andrew Boothman Geschrieben von Gregory Neil Shapiro Informationen entnommen aus E-Mails geschrieben von E-Mail MTA, wechseln &os; enthält mit Sendmail bereits einen MTA, der für die ein- und ausgehenden E-Mails verantwortlich ist. Der Systemadministrator kann aber den MTA des Systems wechseln. Eine große Auswahl an alternativen MTAs ist in der Kategorie mail der &os; Ports-Sammlung verfügbar. Sobald ein neuer MTA installiert ist, können Sie die neue Software konfigurieren und testen, bevor Sie Sendmail ersetzen. Informationen über die Konfiguration des neu gewählten MTA finden Sie in der dazugehörigen Dokumentation. Sobald der neue MTA wie gewünscht funktioniert, benutzen Sie die Anweisungen in diesem Abschnitt, um Sendmail zu deaktivieren und stattdessen den neuen MTA zu verwenden. <application>Sendmail</application> deaktivieren Wenn der ausgehende Mail-Dienst von Sendmail deaktiviert ist, muss für den E-Mail-Versand ein alternatives System installiert werden. Andernfalls sind Systemfunktionen wie &man.periodic.8; nicht mehr in der Lage, ihre Resulate und Meldungen als E-Mail zu versenden. Aber auch viele andere Teile des Systems erwarten einen funktionalen MTA. Sind Programme auf die deaktivierten Sendmail-Binärdateien angewiesen, landen deren E-Mails ansonsten in einer inaktiven Sendmail-Warteschlange und können nicht ausgeliefert werden. Um Sendmail komplett zu deaktivieren, müssen folgende Zeilen in /etc/rc.conf hinzugefügt oder editiert werden: sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" Um lediglich die Funktion zum Empfang von E-Mails durch Sendmail zu deaktivieren, muss folgender Eintrag in /etc/rc.conf gesetzt werden: sendmail_enable="NO" Weitere Informationen zu den Startoptionen von Sendmail finden Sie in der Manualpage &man.rc.sendmail.8;. Den voreingestellten <acronym>MTA</acronym> ersetzen Wenn ein neuer MTA über die Ports-Sammlung installiert wird, werden auch die Startskripten installiert. Die Anweisungen zum starten dieser Skripte werden in den Paketnachrichten erwähnt. Bevor Sie den neuen MTA in Betrieb nehmen, stoppen Sie alle laufenden Sendmail-Prozesse. In diesem Beispiel werden alle notwendigen Dienste gestoppt und danach der Postfix Dienst gestartet: &prompt.root; service sendmail stop &prompt.root; service postfix start Damit der angegebene MTA automatisch beim Hochfahren des Systems gestartet wird, fügen Sie dessen Konfigurationszeile in /etc/rc.conf hinzu. Dieser Eintrag startet den Postfix MTA: postfix_enable="YES" Da Sendmail allgegenwärtig ist und manche Anwendungen einfach davon ausgehen es bereits installiert und konfiguriert, wird einige zusätzliche Konfiguration benötigt. Überprüfen Sie /etc/periodic.conf und stellen Sie sicher, dass diese Werte auf NO gesetzt werden. Wenn die Datei nicht existiert, erstellen Sie sie mit folgenden Einträgen: daily_clean_hoststat_enable="NO" daily_status_mail_enable="NO" daily_status_include_submit_mailq="NO" daily_submit_queuerun="NO" Viele alternative MTAs stellen ihre eigenen kompatiblen Implementierungen der Sendmail Kommandozeilen-Schnittstelle zur Verfügung, was die Verwendung als drop-in Ersatz für Sendmail vereinfacht. Allerdings versuchen einige MUAs Sendmails Standard-Dateien auszuführen, anstelle der Dateien des neuen MTAs. &os; verwendet /etc/mail/mailer.conf um die erwarteten Sendmail Dateien auf die neuen Dateien abzubilden. Weitere Informationen über diese Zuordnungen können in &man.mailwrapper.8; gefunden werden. In der Voreinstellung sieht /etc/mail/mailer.conf wie folgt aus: # $FreeBSD$ # # Execute the "real" sendmail program, named /usr/libexec/sendmail/sendmail # sendmail /usr/libexec/sendmail/sendmail send-mail /usr/libexec/sendmail/sendmail mailq /usr/libexec/sendmail/sendmail newaliases /usr/libexec/sendmail/sendmail hoststat /usr/libexec/sendmail/sendmail purgestat /usr/libexec/sendmail/sendmail Wenn eines der Kommandos auf der linken Seite ausgeführt werden soll, führt das System tatsächlich den damit verbundenen Befehl auf der rechten Seite aus. Mit diesem System lassen sich Programme, die für die Sendmail-Funktionen gestartet werden, leicht ändern. Einige MTAs aus der Ports-Sammlung können diese Datei aktualisieren. Zum Beispiel würde Postfix die Datei wie folgt aktualisieren: # # Execute the Postfix sendmail program, named /usr/local/sbin/sendmail # sendmail /usr/local/sbin/sendmail send-mail /usr/local/sbin/sendmail mailq /usr/local/sbin/sendmail newaliases /usr/local/sbin/sendmail Falls die Installation des MTA nicht automatisch /etc/mail/mailer.conf aktualisiert, bearbeiten Sie diese Datei in einem Texteditor, so dass auf die neuen Dateien verwiesen wird. Dieses Beispiel zeigt auf die Dateien, die von mail/ssmtp installiert wurden: sendmail /usr/local/sbin/ssmtp send-mail /usr/local/sbin/ssmtp mailq /usr/local/sbin/ssmtp newaliases /usr/local/sbin/ssmtp hoststat /usr/bin/true purgestat /usr/bin/true Sobald alles konfiguriert ist, wird empfohlen, das System neu zu starten. Ein Neustart bietet auch die Möglichkeit sicherzustellen, dass das System korrekt konfiguriert wurde, um den neuen MTA automatisch beim Hochfahren zu starten. Fehlerbehebung Hier finden sich ein paar häufig gestellte Fragen und ihre Antworten, die von der FAQ übernommen wurden. Warum muss ich einen FQDN (fully-qualified domain name / voll ausgeschriebenen Domänennamen) für meine Rechner verwenden? Vielleicht befindet sich der Rechner in einer anderen Domäne. Um beispielsweise von einem Rechner in foo.bar.edu einen Rechner namens mumble in der Domäne foo.bar.edu zu erreichen, geben Sie seinen voll ausgeschriebenen Domänennamen (FQDN) mumble.bar.edu, anstelle von mumble an. Das liegt daran, dass die aktuelle Version von BIND BIND, die mit &os; ausgeliefert wird, keine Standardabkürzungen für nicht komplett angegebene Domänennamen außerhalb der lokalen Domäne unterstützt. Daher muss ein nicht-qualifizierter Rechner, wie mumble, entweder als mumble.foo.bar.edu gefunden werden, oder er wird in der root Domäne gesucht. In älteren Versionen von BIND lief die Suche über mumble.bar.edu und mumble.edu. RFC 1535 erklärt, warum dieses Verhalten als schlechte Praxis oder sogar als Sicherheitsloch angesehen wird. Um das zu umgehen, setzen Sie die Zeile: search foo.bar.edu bar.edu anstatt der vorherigen domain foo.bar.edu in /etc/resolv.conf ein. Stellen Sie jedoch sicher, dass die Suchordnung nicht die Begrenzung von lokaler und öffentlicher Administration, wie RFC 1535 sie nennt, überschreitet. Wie kann ich einen E-Mail-Server auf einem Anwahl-PPPPPP Rechner betreiben? Sie wollen sich mit einem &os; E-Mail Gateway im LAN verbinden. Die PPP-Verbindung ist keine Standleitung. Ein Weg dies zu tun ist, von einem immer mit dem Internet verbundenen Server einen sekundären MX-DienstMX-Eintrag für die Domäne zur Verfügung gestellt zu bekommen. In diesem Beispiel heißt die Domäne example.com, und der Internet-Dienstanbieter hat example.net so eingestellt, dass er für die Domäne einen sekundären MX-Dienst zur Verfügung stellt: example.com. MX 10 bigco.com. MX 20 example.net. Nur ein Rechner sollte als Endempfänger angegeben sein. Sendmail fügen Sie Cw example.com zu /etc/sendmail.cf auf example.com hinzu. Wenn der MTA des Versenders versucht die E-Mail zuzustellen, wird es versuchen das System example.com über die PPP-Verbindung zu erreichen. Es kommt zu einer Zeitüberschreitung, wenn das Zielsystem offline ist. Der MTA wird die E-Mail automatisch der sekundären MX-Seite des Internet-Providers example.net zustellen. Die sekundäre MX-Seite wird periodisch versuchen, eine Verbindung zur primären MX-Seite example.com aufzubauen. Verwenden Sie etwas wie dies als Login-Skript: #!/bin/sh # Put me in /usr/local/bin/pppmyisp ( sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct pppmyisp Wenn Sie ein separates Login-Skript für einen Benutzer erstellen, benutzen Sie stattdessen sendmail -qRexample.com in dem oben gezeigten Skript. Das erzwingt die sofortige Verarbeitung der E-Mails in der Warteschlange für example.com Eine weitere Verfeinerung der Situation kann an diesem Beispiel von &a.isp; entnommen werden: > wir stellen einem Kunden den sekundären MX zur Verfügung. > Der Kunde verbindet sich mit unseren Diensten mehrmals am Tag > automatisch um die E-Mails zu seinem primären MX zu holen > (wir wählen uns nicht bei ihm ein, wenn E-Mails für seine > Domäne eintreffen). Unser sendmail sendet den Inhalt der > E-Mail-Warteschlange alle 30 Minuten. Momentan muss er 30 Minuten > eingewählt bleiben um sicher zu sein, dass alle seine E-Mails > beim primären MX eingetroffen sind. > > Gibt es einen Befehl, der sendmail dazu bringt, alle E-Mails sofort > zu senden? Der Benutzer hat natürlich keine root-Rechte auf > unserer Maschine. In der privacy flags Sektion von sendmail.cf befindet sich die Definition Opgoaway,restrictqrun Entferne restrictqrun um nicht-root Benutzern zu erlauben, die Verarbeitung der Nachrichten-Warteschlangen zu starten. Möglicherweise willst du auch die MX neu sortieren. Wir sind der primäre MX für unsere Kunden mit diesen Wünschen und haben definiert: # Wenn wir der beste MX für einen Rechner sind, versuche es direkt # anstatt einen lokalen Konfigurationsfehler zu generieren. OwTrue Auf diesem Weg liefern Gegenstellen direkt zu dir, ohne die Kundenverbindung zu versuchen. Dann sendest du zu deinem Kunden. Das funktioniert nur für Rechner, du musst also deinen Kunden dazu bringen, ihre E-Mail Maschine customer.com zu nennen, sowie hostname.customer.com im DNS. Setze einfach einen A-Eintrag in den DNS für customer.com. Weiterführende Themen Dieser Abschnitt behandelt kompliziertere Themen wie E-Mail-Konfiguration und Einrichtung von E-Mail für eine ganze Domäne. Grundlegende Konfiguration Mit der Software im Auslieferungszustand sollte es möglich sein, E-Mails an externe Rechner zu senden, vorausgesetzt /etc/resolv.conf ist konfiguriert, oder das Netzwerk hat Zugriff auf einen konfigurierten DNS-Server. Um E-Mails an den MTA auf dem Rechner auszuliefern, stehen zwei Möglichkeiten zur Auswahl: Betreiben Sie einen DNS-Server für die Domäne. Lassen Sie die E-Mails direkt über den FQDN des Rechners ausliefern. Um E-Mails direkt zu einem Rechner geliefert zu bekommen, wird eine permanente statische IP-Adresse (keine dynamische IP-Adresse) benötigt. Befindet sich das System hinter einer Firewall, muss diese den SMTP-Verkehr weiterleiten. Um E-Mails direkt am Rechner zu empfangen, muss eines der folgenden Dinge konfiguriert werden: Vergewissern Sie sich, dass der MXMX-Eintrag -Eintrag mit der kleinsten Nummer im DNS auf die statische IP-Adresse des Rechners zeigt. Stellen Sie sicher, dass für den Rechner kein MX-Eintrag im DNS existiert. Jede der erwähnten Konfigurationsmöglichkeiten erlaubt es, E-Mails direkt auf dem Rechner zu empfangen. Versuchen Sie das: &prompt.root; hostname example.FreeBSD.org &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX In diesem Beispiel sollte es funktionieren, E-Mails direkt an yourlogin@example.FreeBSD.org zu senden, vorausgesetzt dass Sendmail auf example.FreeBSD.org korrekt läuft. In diesem Beispiel: &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX example.FreeBSD.org mail is handled (pri=10) by devnull.FreeBSD.org Hier wird jede an den Rechner example.FreeBSD.org gesandte E-Mail auf hub unter dem gleichen Benutzernamen gesammelt, anstatt diese direkt zu Ihrem Rechner zu senden. Die obige Information wird von einem DNS-Server verwaltet. Der DNS-Eintrag, der die Information zum E-Mail-Routing enthält, ist der MX-Eintrag. Existiert kein MX-Eintrag, werden E-Mails direkt über die IP-Adresse an den Rechner geliefert. Der MX-Eintrag für freefall.FreeBSD.org sah einmal so aus: freefall MX 30 mail.crl.net freefall MX 40 agora.rdrop.com freefall MX 10 freefall.FreeBSD.org freefall MX 20 who.cdrom.com freefall hatte viele MX-Einträge. Die kleinste MX-Nummer definiert de Rechner, der die E-Mails direkt empfängt, wobei die anderen Rechner temporär E-Mails in Warteschlangen einreihen, falls freefall beschäftigt oder unerreichbar ist. Es ist sehr sinnvoll, dass stellvertretende MX-Seiten separate Internet-Verbindungen verwenden. Ihr ISP kann diesen Dienst zur Verfügung stellen. E-Mails für eine Domäne Wird ein MTA für ein Netzwerk konfiguriert, dann sollte jede E-Mail die an einen Rechner in dieser Domäne geschickt wird, an den MTA umgeleitet werden, damit die Benutzer ihre E-Mails vom zentralen Mail-Server empfangen können. Am einfachsten ist es, wenn Accounts mit gleichen Benutzernamen sowohl auf dem MTA, als auch auf dem System mit dem MUA existieren. Verwenden Sie &man.adduser.8;, um Benutzerkonten anzulegen. Der MTA muss auf jeder Workstation im Netzwerk als der zuständige Rechner für den E-Mail-Austausch gekennzeichnet werden. Dies wird in der DNS-Konfiguration über den MX-Eintrag gesteuert: example.FreeBSD.org A 204.216.27.XX ; Workstation MX 10 devnull.FreeBSD.org ; Mailhost Diese Einstellung wird E-Mails für die Workstations zum MTA weiterleiten, egal wo der A-Eintrag hinzeigt. Die E-Mails werden zum MX-Rechner gesendet. Diese Einstellung muss auf dem DNS-Server konfiguriert werden. Besitzt das Netzwerk keinen eigenen DNS-Server, kontaktieren Sie Ihren ISP oder DNS-Verwalter. Im Folgenden ist ein Beispiel für virtuelles E-Mail-Hosting. Nehmen wir an, dass für einen Kunden mit der Domäne customer1.org, alle E-Mails für customer1.org an mail.myhost.com gesendet werden sollen. Der entsprechende DNS-Eintrag sollte wie folgt aussehen: customer1.org MX 10 mail.myhost.com Wenn für die Domäne nur E-Mails verarbeitet werden sollen, wird für customer1.org kein A-Eintrag benötigt. Allerdings wird ein ping gegen customer1.org nur dann funktionieren, wenn ein A-Eintrag existiert. Teilen Sie dem MTA mit, für welche Domänen bzw. Hostnamen Post entgegengenommen werden soll. Die beiden folgenden Methoden funktionieren für Sendmail: Fügen Sie die Rechnernamen in /etc/mail/local-host-names hinzu, wenn FEATURE(use_cw_file) verwendet wird. Fügen Sie eine Zeile Cwyour.host.com in /etc/sendmail.cf hinzu. Ausgehende E-Mail über einen Relay versenden Bill Moran Beigetragen von In vielen Fällen möchte man E-Mail nur über einen Relay verschicken. Zum Beispiel: Der Rechner ist ein Arbeitsplatzrechner und benutzt - Programme wie &man.send-pr.1; über ein Relay des + Programme wie &man.mail.1; über ein Relay des ISP. Ein Server, der E-Mails nicht selbst verarbeitet, soll alle E-Mails zu einem Relay schicken. Obwohl jeder MTA diese Aufgabe erfüllen kann, ist es oft schwierig einen vollwertigen MTA so zu konfigurieren, dass er lediglich ausgehende E-Mails weiterleitet. Es ist übertrieben, Programme wie Sendmail und Postfix nur für diesen Zweck einzusetzen. Weiterhin kann es sein, dass die Bestimmungen des Internetzugangs es verbieten, einen eigenen Mail-Server zu betreiben. Um die hier beschriebenen Anforderungen zu erfüllen, installieren Sie einfach den Port mail/ssmtp: &prompt.root; cd /usr/ports/mail/ssmtp &prompt.root; make install replace clean Nach der Installation kann mail/ssmtp über /usr/local/etc/ssmtp/ssmtp.conf konfiguriert werden: root=yourrealemail@example.com mailhub=mail.example.com rewriteDomain=example.com hostname=_HOSTNAME_ Verwenden Sie eine gültige E-Mail-Adresse für root. Geben Sie für mail.example.com den Mail-Relay des ISPs an. Einige ISPs nennen den Relay Postausgangsserver oder SMTP-Server. Deaktivieren Sie Sendmail, einschließlich des Services für den Postausgang. Details finden Sie in . mail/ssmtp verfügt über weitere Optionen. Die Beispiele in /usr/local/etc/ssmtp oder die Manualpage von ssmtp enthalten weitere Informationen. Wird ssmtp wie hier beschrieben eingerichtet, können Anwendungen E-Mails von dem lokalen Rechner verschicken. Man verstößt damit auch nicht gegen Bestimmungen des ISPs und läuft nicht Gefahr, dass der Rechner zum Versenden von Spam missbraucht wird. E-Mail über Einwahl-Verbindungen Wird eine feste IP-Adresse verwendet, müssen die Standardeinstellungen wahrscheinlich gar nicht geändert werden. Stellen Sie den Hostnamen auf den entsprechend zugeordneten Internetnamen ein und Sendmail übernimmt das Übrige. Bei der Verwendung einer dynamisch zugewiesenen IP-Adresse und einer PPP-Wählverbindung mit dem Internet, hat man in der Regel ein Postfach auf dem Mailserver des ISP. In diesem Beispiel ist die Domäne des ISP example.net, der Benutzername ist user, der Rechnername ist bsd.home und der ISP erlaubt es, relay.example.net als Mail-Relayhost zu benutzen. Um Mails aus der Mailbox des ISPs abzuholen, muss ein gesondertes Programm aus der Ports-Sammlung installiert werden. mail/fetchmail ist eine gute Wahl, weil es viele verschiedene Protokolle unterstützt. Für gewöhnlich stellt der ISP POP zur Verfügung. Falls User-PPP verwendet wird, können durch folgenden Eintrag in /etc/ppp/ppp.linkup E-Mails automatisch abgerufen werden, sobald eine Verbindung zum Netz aufgebaut wird: MYADDR: !bg su user -c fetchmail Wird Sendmail benutzt, um E-Mails an nicht-lokale Benutzer zu versenden, konfigurieren Sie es so, dass die Warteschlange abgearbeitet wird, sobald eine Verbindung mit dem Internet besteht. Um dies zu erreichen, müssen folgende Zeilen nach dem fetchmail-Eintrag in /etc/ppp/ppp.linkup hinzugefügt werden. !bg su user -c "sendmail -q" In diesem Beispiel existiert auf bsd.home ein Benutzer user. Erstellen Sie auf bsd.home im Heimatverzeichnis von user die Datei .fetchmailrc mit folgender Zeile: poll example.net protocol pop3 fetchall pass MySecret; Diese Datei sollte für niemandem außer user lesbar sein, weil sie das Passwort MySecret enthält. Um Mails mit dem richtigen from:-Header zu versenden, müssen Sie Sendmail so konfigurieren, dass es user@example.net und nicht user@bsd.home benutzen soll und das alle Mails über relay.example.net versendet werden, um eine schnellere Übertragung von Mails zu gewährleisten. Die folgende .mc sollte ausreichen: VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home MASQUERADE_AS(`example.net')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(`SMART_HOST', `relay.example.net') Dmbsd.home define(`confDOMAIN_NAME',`bsd.home')dnl define(`confDELIVERY_MODE',`deferred')dnl Im vorherigen Abschnitt finden Sie Details dazu, wie Sie diese Datei in das Format sendmail.cf konvertieren können. Vergessen Sie nicht, Sendmail neu zu starten, nachdem sendmail.cf verändert wurde. SMTP-Authentifizierung James Gorham Geschrieben von Die Konfiguration von SMTP-Authentifizierung auf dem MTA bietet einige Vorteile. Die erforderliche Authentifizierung erhöht die Sicherheit von Sendmail und mobilen Benutzern, die auf entfernten Rechnern arbeiten. Diese Benutzer können denselben MTA verwenden, ohne jedes Mal das Benutzerprogramm neu konfigurieren zu müssen. Installieren Sie security/cyrus-sasl2 aus der Ports-Sammlung. Dieser Port verfügt über einige Optionen, die während der Übersetzung festgelegt werden. Für die in diesem Abschnitt beschriebene Methode zur SMTP-Authentifizierung muss die Option aktiviert werden. Nach der Installation von security/cyrus-sasl2 editieren Sie /usr/local/lib/sasl2/Sendmail.conf. Erstellen Sie die Datei, wenn sie nicht existiert und fügen Sie die folgende Zeile hinzu: pwcheck_method: saslauthd Als nächstes installieren Sie security/cyrus-sasl2-saslauthd, und fügen die folgende Zeile in /etc/rc.conf ein: saslauthd_enable="YES" Abschließend starten Sie den saslauthd-Dämon: &prompt.root; service saslauthd start Dieser Dämon agiert als Broker zwischen Sendmail und der &os;-passwd-Datenbank. Dadurch müssen zum Versenden von E-Mails keine zusätzlichen Accounts und Passwörter angelegt werden. Die Benutzer verwenden dasselbe Passwort zum Anmelden wie zum Verschicken von E-Mails. Fügen Sie danach in /etc/make.conf die folgenden Zeilen hinzu: SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 Beim Übersetzen von Sendmail werden damit die cyrus-sasl2-Bibliotheken benutzt. Stellen Sie daher vor dem Übersetzen von Sendmail sicher, dass cyrus-sasl2 installiert ist. Übersetzen Sie Sendmail mit den nachstehenden Kommandos: &prompt.root; cd /usr/src/lib/libsmutil &prompt.root; make cleandir && make obj && make &prompt.root; cd /usr/src/lib/libsm &prompt.root; make cleandir && make obj && make &prompt.root; cd /usr/src/usr.sbin/sendmail &prompt.root; make cleandir && make obj && make && make install Die Übersetzung sollte keine Probleme bereiten, wenn /usr/src nicht umfangreich verändert wurde und die benötigten Bibliotheken installiert sind. Nachdem Sendmail übersetzt und installiert wurde, editieren Sie /etc/mail/freebsd.mc beziehungsweise die lokale .mc-Datei. Viele Administratoren verwenden die Ausgabe von &man.hostname.1;, um der .mc einen eindeutigen Namen zu geben. Fügen Sie die folgenden Zeilen hinzu: dnl set SASL options TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl Diese Anweisungen konfigurieren die Methoden, die Sendmail zur Authentifizierung von Benutzern verwendet. Lesen Sie die Sendmail Dokumentation, wenn eine andere Methode als verwendet werden soll. Abschließend rufen Sie &man.make.1; in /etc/mail auf. Damit wird aus der .mc-Datei eine neue .cf-Datei erzeugt. Der Name ist entweder freebsd.cf oder der Name der lokalen .mc-Datei. make install restart installiert die Datei nach /etc/mail/sendmail.cf und startet Sendmail neu. Weitere Informationen zu diesem Vorgang entnehmen Sie bitte /etc/mail/Makefile. Um die Konfiguration zu testen, verwenden Sie einen MUA, um eine Testnachricht zu senden. Mail-Benutzerprogramm das Passwort für die Authentifizierung ein und versenden Sie zum Testen eine E-Mail. Zur Fehlersuche, setzen Sie den von Sendmail auf 13 und untersuchen die Fehlermeldungen in /var/log/maillog. Weitere Information finden Sie unter SMTP-Authentifizierung. E-Mail-Programme Marc Silver Beigetragen von Mail-User-Agents E-Mail-Programme Anwendungen, die E-Mails versenden und empfangen, werden als E-Mail-Programme oder Mail-User-Agents (MUA) bezeichnet. Mit der Entwicklung und Ausbreitung von E-Mail wachsen auch die E-Mail-Programme und bieten Benutzern mehr Funktionen und höhere Flexibilität. Die Kategorie mail der &os; Ports-Sammlung enthält zahlreiche E-Mail-Programme. Dazu gehören grafische Programme, wie beispielsweise Evolution oder Balsa und Konsolen basierte Programme wie mutt oder alpine. <command>mail</command> Das standardmäßig unter &os; installierte E-Mail-Programm ist &man.mail.1;. Das Programm ist konsolenorientiert und enthält alle Funktionen, die zum Versand und Empfang textbasierter E-Mails erforderlich sind. Es bietet eine begrenzte Unterstützung für Anhänge und kann auf lokale Postfächer zugreifen. mail kann nicht direkt auf POP- oder IMAP-Server zugreifen. Entfernte Postfächer können aber mit einer Anwendung wie fetchmail in eine lokale mbox geladen werden. Um E-Mails zu versenden oder zu empfangen, starten Sie einfach mail wie im nachstehenden Beispiel: &prompt.user; mail mail liest automatisch den Inhalt des Benutzer-Postfachs im Verzeichnis /var/mail. Sollte das Postfach leer sein, beendet sich mail mit der Nachricht, dass keine E-Mails vorhanden sind. Wenn E-Mails vorhanden sind, wird die Benutzeroberfläche gestartet und eine Liste der E-Mails angezeigt. Die E-Mails werden automatisch nummeriert wie im folgenden Beispiel gezeigt: Mail version 8.1 6/6/93. Type ? for help. "/var/mail/marcs": 3 messages 3 new >N 1 root@localhost Mon Mar 8 14:05 14/510 "test" N 2 root@localhost Mon Mar 8 14:05 14/509 "user account" N 3 root@localhost Mon Mar 8 14:05 14/509 "sample" Einzelne Nachrichten können nun durch Eingabe von t gefolgt von der Nummer der Nachricht gelesen werden. Im nachstehenden Beispiel wird die erste E-Mail gelesen: & t 1 Message 1: From root@localhost Mon Mar 8 14:05:52 2004 X-Original-To: marcs@localhost Delivered-To: marcs@localhost To: marcs@localhost Subject: test Date: Mon, 8 Mar 2004 14:05:52 +0200 (SAST) From: root@localhost (Charlie Root) Das ist eine Test-Nachricht. Antworte bitte! Wie in diesem Beispiel zu sehen ist, wird die Nachricht zusammen mit dem vollständigen Nachrichtenkopf angezeigt. Um die Liste der E-Mails erneut zu sehen, drücken Sie wieder die Taste h. Um auf eine E-Mail zu antworten, benutzen Sie entweder R oder r. R weist mail an, dem Versender der Nachricht zu antworten, während mit r allen Empfängern der Nachricht geantwortet wird. Den Kommandos kann die Zahl der E-Mail, auf die geantwortet werden soll, mitgegeben werden. Nachdem die Antwort E-Mail verfasst worden ist, sollte die Eingabe mit einem einzelnen Punkt (.) auf einer neuen Zeile abgeschlossen werden. Hierzu ein Beispiel: & R 1 To: root@localhost Subject: Re: test Danke, ich habe deine E-Mail erhalten. . EOT Neue E-Mails können mit m, gefolgt von der E-Mail-Adresse des Empfängers verschickt werden. Mehrere Empfänger werden durch Kommata (,) getrennt, angegeben. Der Betreff (subject) der Nachricht kann dann, gefolgt vom Inhalt der Nachricht eingegeben werden. Die Nachricht wird dann mit einem einzelnen Punkt (.) auf einer neuen Zeile abgeschlossen. & mail root@localhost Subject: Ich habe die E-Mails im Griff! Jetzt kann ich E-Mails versenden und empfangen ... :) . EOT Die Taste ? zeigt zu jeder Zeit einen Hilfetext an. Lesen Sie &man.mail.1;, wenn Sie weitere Hilfe zur Benutzung von mail erhalten möchten. &man.mail.1; wurde nicht für den Umgang mit Anhängen entworfen und kann daher sehr schlecht mit Anhängen umgehen. Neuere MUAs gehen wesentlich besser mit Anhängen um. Benutzer, die mail bevorzugen, werden vielleicht den Port converters/mpack zu schätzen wissen. <application>mutt</application> mutt ist ein leistungsfähiges E-Mail-Programm mit vielen Funktionen, darunter: mutt kann den Verlauf einer Diskussion (threading) darstellen. Unterstützung von PGP für das digitale signieren und verschlüsseln von E-Mail. MIME-Unterstützung. Maildir-Unterstützung. mutt lässt sich im höchsten Maße an lokale Bedürfnisse anpassen. Mehr über mutt erfahren Sie auf der Seite http://www.mutt.org. mutt kann über den Port mail/mutt installiert werden. Nachdem der Port installiert ist, kann mutt mit dem folgenden Befehl gestartet werden: &prompt.user; mutt mutt liest automatisch den Inhalt des Benutzer-Postfachs im Verzeichnis /var/mail. Sind keine E-Mails vorhanden, wartet mutt auf Benutzereingaben. Das folgende Beispiel zeigt, wie mutt eine Nachrichten-Liste darstellt: Um eine E-Mail zu lesen, wählen Sie die Nachricht einfach mit den Pfeiltasten aus und drücken Enter. mutt zeigt E-Mails wie folgt an: Änlich wie &man.mail.1;, kann auch mutt verwendet werden, um nur dem Absender, oder auch allen anderen Empfängern zu antworten. Um nur dem Absender der E-Mail zu antworten, drücken Sie r. Um sowohl dem Absender, als auch allen anderen Empfängern zu antworten, drücken Sie g. Zum Erstellen oder zum Beantworten von E-Mails ruft mutt den Editor &man.vi.1; auf. Jeder Benutzer kann diese Einstellung anpassen, indem die Variable editor in .muttrc im Heimatverzeichnis gesetzt wird, oder die Umgebungsvariable EDITOR entsprechend angepasst wird. Weitere Informationen zur Konfiguration von mutt finden Sie unter http://www.mutt.org/. Drücken Sie m, um eine neue Nachricht zu verfassen. Nachdem der Betreff (subject) eingegeben wurde, startet mutt den &man.vi.1; und die Nachricht kann verfasst werden. Wenn Sie fertig sind, speichern Sie die Nachricht und verlassen den &man.vi.1;. mutt wird dann wieder aktiv und zeigt eine Zusammenfassung der zu sendenden Nachricht an. Drücken Sie y, um die E-Mail zu versenden. Der nachstehende Bildschirmabzug zeigt die Zusammenfassung der E-Mail: mutt verfügt über eine umfangreiche Hilfestellung. Aus fast jedem Menü können Hilfeseiten mit ? aufgerufen werden. In der oberen Statuszeile werden zudem die verfügbaren Tastenkombinationen angezeigt. <application>alpine</application> alpine wendet sich an Anfänger bietet aber ebenfalls einige Funktionen für Profis. In der Vergangenheit wurden in alpine mehrere Schwachstellen gefunden. Die Schwachstellen gestatteten entfernten Benutzern, durch das Versenden einer besonders verfassten E-Mail, Programme auf dem lokalen System laufen zu lassen. Alle bekannten Schwachstellen sind beseitigt worden, doch wird im Quellcode von alpine ein sehr riskanter Programmierstil verwendet, sodass der &os;-Security-Officer von weiteren unbekannten Schwachstellen ausgeht. Benutzer installieren alpine auf eigene Verantwortung! Der Port mail/alpine enthält die aktuelle Version von alpine. Nach der Installation können Sie alpine mit dem nachstehenden Kommando starten: &prompt.user; alpine Beim ersten Start von alpine, zeigt das Programm eine Seite mit einer kurzen Einführung an. Um die alpine-Benutzer zu zählen, bitten die Entwickler auf dieser Seite um eine anonyme E-Mail. Sie können diese anonyme E-Mail senden, indem Sie Enter drücken oder den Begrüßungsbildschirm mit der Taste E verlassen, ohne die anonyme E-Mail zu senden. Der Begrüßungsbildschirm sieht wie folgt aus: Nach dem Begrüßungsbildschirm wird das Hauptmenü dargestellt, das sich mit den Pfeiltasten bedienen lässt. Über Tastenkombinationen können aus dem Hauptmenü neue E-Mails erstellt, Postfächer angezeigt und das Adressbuch verwaltet werden. Unterhalb des Menüs werden die Tastenkombinationen für die verfügbaren Aktionen angezeigt. In der Voreinstellung öffnet alpine das Verzeichnis inbox. Die Taste I oder der Menüpunkt MESSAGE INDEX führt zu einer Nachrichten-Liste: Die Liste zeigt die Nachrichten im Arbeitsverzeichnis. Sie können Nachrichten mit den Pfeiltasten markieren. Um eine Nachricht zu lesen, drücken Sie Enter. Im nächsten Bildschirmabzug sehen Sie, wie alpine eine Nachricht darstellt. Die unteren Bildschirmzeilen zeigen die verfügbaren Tastenkombinationen. Mit r können Sie zum Beispiel auf die gerade angezeigte Nachricht antworten. Zum Antworten auf eine E-Mail wird in alpine der Editor pico, der mit installiert wird, benutzt. pico ist leicht zu bedienen und gerade für Anfänger besser geeignet als &man.vi.1; oder &man.mail.1;. Die Antwort wird mit der Tastenkombination Ctrl X versendet. Vor dem Versand bittet alpine noch um eine Bestätigung. Über den Menüpunkt SETUP des Hauptmenüs können Sie alpine an Ihre Bedürfnisse anpassen. Erläuterungen dazu finden Sie auf der Seite http://www.washington.edu/pine/. E-Mails mit <application>fetchmail</application> abholen Marc Silver Beigetragen von fetchmail fetchmail ist ein vollwertiger IMAP- und POP-Client. Mit fetchmail können Benutzer E-Mails von entfernten IMAP- und POP-Servern in leichter zugängliche lokale Postfächer laden. fetchmail wird aus dem Port mail/fetchmail installiert. Das Programm bietet unter anderem folgende Funktionen: fetchmail beherrscht die Protokolle POP3, APOP, KPOP, IMAP, ETRN und ODMR. E-Mails können mit SMTP weiterverarbeitet werden. Dadurch ist garantiert, dass Filter, Weiterleitungen und Aliase weiterhin funktionieren. Das Programm kann als Dienst laufen und periodisch neue Nachrichten abrufen. fetchmail kann mehrere Postfächer abfragen und je nach Konfiguration die E-Mails an verschiedene lokale Benutzer zustellen. Dieser Abschnitt erklärt einige grundlegende Funktionen von fetchmail. Das Programm benötigt eine Konfigurationsdatei .fetchmailrc im Heimatverzeichnis des Benutzers. In dieser Datei werden Informationen über Server wie auch Benutzerdaten und Passwörter hinterlegt. Wegen des kritischen Inhalts dieser Datei ist es ratsam, diese nur für den Benutzer lesbar zu machen: &prompt.user; chmod 600 .fetchmailrc Die folgende .fetchmailrc zeigt, wie das Postfach eines einzelnen Benutzers mit POP heruntergeladen wird. fetchmail wird angewiesen, eine Verbindung zu example.com herzustellen und sich dort als Benutzer joesoap mit dem Passwort XXX anzumelden. Das Beispiel setzt voraus, dass der Benutzer joesoap auch auf dem lokalen System existiert. poll example.com protocol pop3 username "joesoap" password "XXX" Im folgenden Beispiel werden mehrere POP- und IMAP-Server benutzt. Wo notwendig, werden E-Mails auf andere lokale Konten umgeleitet: poll example.com proto pop3: user "joesoap", with password "XXX", is "jsoap" here; user "andrea", with password "XXXX"; poll example2.net proto imap: user "john", with password "XXXXX", is "myth" here; fetchmail kann als Dämon gestartet werden. Verwendet wird dazu die Kommandozeilenoption gefolgt von einer Zeitspanne in Sekunden, die angibt, wie oft die Server aus .fetchmailrc abgefragt werden sollen. Mit dem nachstehenden Befehl fragt fetchmail die Server alle 600 Sekunden ab: &prompt.user; fetchmail -d 600 Mehr über fetchmail erfahren Sie auf der Seite http://www.fetchmail.info/. E-Mails mit <application>procmail</application> filtern Marc Silver Beigetragen von procmail procmail ist ein mächtiges Werkzeug, mit dem sich eingehende E-Mails filtern lassen. Benutzer können Regeln für eingehende E-Mails definieren, die E-Mails zu anderen Postfächern oder anderen E-Mail-Adressen umleiten. procmail befindet sich im Port mail/procmail. procmail kann leicht in die meisten MTAs integriert werden. Lesen Sie dazu bitte die Dokumentation des verwendeten MTAs. Alternativ kann procmail in das E-Mail-System eingebunden werden, indem die nachstehende Zeile in die Datei .forward im Heimatverzeichnis eines Benutzers eingefügt wird: "|exec /usr/local/bin/procmail || exit 75" Der folgende Abschnitt zeigt einige einfache procmail-Regeln sowie eine kurze Beschreibung dessen, was sie tun. Regeln müssen in .procmailrc im Heimatverzeichnis des Benutzers eingefügt werden. Den Großteil dieser Regeln finden Sie auch in &man.procmailex.5;. Um E-Mails von user@example.com an die externe Adresse goodmail@example2.com weiterzuleiten: :0 * ^From.*user@example.com ! goodmail@example2.com Um E-Mails, die kürzer als 1000 Bytes sind, an goodmail@example2.com weiterzuleiten: :0 * < 1000 ! goodmail@example2.com Um E-Mails, die an alternate@example.com geschickt werden, im Postfach alternate zu speichern: :0 * ^TOalternate@example.com alternate Um E-Mails, die im Betreff Spam enthalten, nach /dev/null zu verschieben: :0 ^Subject:.*Spam /dev/null Zuletzt ein nützliches Rezept, das eingehende E-Mails von den &os;.org-Mailinglisten in ein separates Postfach für jede Liste einsortiert: :0 * ^Sender:.owner-freebsd-\/[^@]+@FreeBSD.ORG { LISTNAME=${MATCH} :0 * LISTNAME??^\/[^@]+ FreeBSD-${MATCH} }