Index: head/de_DE.ISO8859-1/articles/freebsd-update-server/article.xml =================================================================== --- head/de_DE.ISO8859-1/articles/freebsd-update-server/article.xml (revision 51670) +++ head/de_DE.ISO8859-1/articles/freebsd-update-server/article.xml (revision 51671) @@ -1,838 +1,838 @@ FreeBSD Update Server"> ]>
Einen eigenen &os; Update Server bauen JasonHelfman
&a.jgh.email;
 2009 2010 2011 2013 Jason Helfman &tm-attrib.freebsd; &tm-attrib.general; &tm-attrib.intel; &tm-attrib.amd; $FreeBSD$ $FreeBSD$ Dieser Artikel beschreibt den Bau eines internen &fbus.ap;. - Die freebsd-update-server + Die freebsd-update-server Software wurde von &a.cperciva.email;, emeritierter Security Officer von &os;, geschrieben. Benutzer, die es als vorteilhaft ansehen ihre Systeme über einen offiziellen Update-Server zu aktualisieren, können mit Hilfe eines selbst erstellten &fbus.ap; die Funktionalität über manuell optimierte &os; Releases oder über Bereitstellung eines lokalen Mirror, welcher schnellere Updates ermöglicht, erweitern. Übersetzt von &a.bhd.email;. Danksagung Dieser Artikel wurde anschließend im BSD Magazine gedruckt. Einführung Erfahrene Benutzer oder Administratoren sind häufig für etliche Maschinen oder Umgebungen verantwortlich. Sie verstehen die schwierigen Anforderungen und Herausforderungen der Aufrechterhaltung einer solchen Infrastruktur. Ein &fbus.ap; macht es einfacher, Sicherheits- und Software-Korrekturen für ausgewählte Test-Maschinen bereitzustellen, bevor diese dann auf den Produktionssystemen ausgerollt werden. Es bedeutet auch, dass eine Reihe von Systemen über das lokale Netzwerk, anstatt über eine langsame Internet-Verbindung, aktualisiert werden können. Dieser Artikel beschreibt die Vorgehensweise zum Erstellen eines eigenen &fbus.ap;. Voraussetzungen Für den Bau eines internen &fbus.ap; sollten einige Anforderungen erfüllt werden. Ein laufendes &os; System. Als Minimum, muss das zu verteilende Ziel-Release auf einer gleichen, oder höheren &os; Version gebaut werden. Ein Benutzerkonto mit mindestens 4 GB freiem Speicherplatz. Dies erlaubt die Erstellung der Updates für 7.1 und 7.2. Der genaue Platzbedarf kann sich aber von Version zu Version ändern. Ein &man.ssh.1; Konto auf einem entfernten System, um die später zu verteilenden Updates hochzuladen. Einen Webserver, wie Apache, wobei über die Hälfte des Platzes für den Bau benötigt wird. Als Beispiel benötigt der Bau von 7.1 und 7.2 insgesamt 4 GB. Der Speicherplatz, den der Webserver für die Verteilung dieser Updates benötigt, würde 2.6 GB betragen. Grundlegende Kenntnisse im Shell Skripting mit der Bourne Shell, &man.sh.1;. Konfiguration: Installation & Setup - Laden Sie die + Laden Sie die freebsd-update-server Software durch die Installation von devel/subversion sowie security/ca_root_nss, und starten Sie: &prompt.user; svn co https://svn.freebsd.org/base/user/cperciva/freebsd-update-build freebsd-update-server Passen Sie scripts/build.conf an Ihre Bedürfnisse an. Diese Datei wird bei jedem Bau mit einbezogen. Hier ist die Standardeinstellung für build.conf, welche Sie für Ihre Umgebung anpassen sollten. # Main configuration file for FreeBSD Update builds. The # release-specific configuration data is lower down in # the scripts tree. # Location from which to fetch releases export FTP=ftp://ftp2.freebsd.org/pub/FreeBSD/releases # Host platform export HOSTPLATFORM=`uname -m` # Host name to use inside jails export BUILDHOSTNAME=${HOSTPLATFORM}-builder.daemonology.net # Location of SSH key export SSHKEY=/root/.ssh/id_dsa # SSH account into which files are uploaded MASTERACCT=builder@wadham.daemonology.net # Directory into which files are uploaded MASTERDIR=update-master.freebsd.org Parameter, die zu berücksichtigen sind: Dies ist der Ort, von dem die ISO Abbilder (über die fetchiso() in scripts/build.subr) heruntergeladen werden. Der Ort ist nicht auf FTP URIs beschränkt. Jedes URI-Schema, welches von &man.fetch.1; unterstützt wird, sollte hier gut funktionieren. Anpassungen am fetchiso() Code können Sie vornehmen, indem Sie das Standardskript build.subr in den Release- und Architektur-spezifischen Bereich in scripts/RELEASE/ARCHITECTURE/build.subr kopieren und dort lokale Änderungen vornehmen. Der Name des Build-Hosts. Auf aktualisierten Systemen können Sie diese Information wie folgt ausgeben: &prompt.user; uname -v Der SSH Schlüssel für das Hochladen der Dateien auf den Update Server. Ein Schlüsselpaar kann durch die Eingabe von ssh-keygen -t dsa erstellt werden. Dieser Parameter ist jedoch optional; Standard Password Authentifizierung wird als Fallback-Methode benutzt wenn SSHKEY nicht definiert ist. Die &man.ssh-keygen.1; Manualpage enthält detaillierte Informationen zu SSH und die entsprechenden Schritte zur Erstellung und Verwendung von Schlüsseln. Benutzerkonto zum Hochladen von Dateien auf den Update-Server. Verzeichnis auf dem Update-Server, in welches die Dateien hochgeladen werden. Die Standard build.conf, die mit den freebsd-update-server Quellen ausgeliefert wird ist geeignet um &arch.i386; Releases von &os; zu bauen. Als Beispiel für den Aufbau eines Update-Servers für andere Architekturen beschreiben die folgenden Schritte die Konfiguration für &arch.amd64;: Erstellen Sie eine Bau-Umgebung für &arch.amd64;: &prompt.user; mkdir -p /usr/local/freebsd-update-server/scripts/7.2-RELEASE/amd64 Installieren Sie eine build.conf in das neu erstellte Verzeichnis. Die Konfigurationsoptionen für &os; 7.2-RELEASE auf &arch.amd64; sollten ähnlich wie die folgenden sein: # SHA256 hash of RELEASE disc1.iso image. export RELH=1ea1f6f652d7c5f5eab7ef9f8edbed50cb664b08ed761850f95f48e86cc71ef5 # Components of the world, source, and kernels export WORLDPARTS="base catpages dict doc games info manpages proflibs lib32" export SOURCEPARTS="base bin contrib crypto etc games gnu include krb5 \ lib libexec release rescue sbin secure share sys tools \ ubin usbin cddl" export KERNELPARTS="generic" # EOL date export EOL=1275289200 Der &man.sha256.1; Fingerabdruck für die gewünschte Version wird innerhalb der jeweiligen Release-Ankündigung veröffentlicht. Um die "End of Life" Nummer für die build.confzu generieren, beziehen Sie sich bitte auf "Estimated EOL" auf der &os; Security Webseite. Der Wert für EOL kann aus dem Datum, das auf der Webseite veröffentlicht ist, abgeleitet werden. Benutzen Sie dafür das Werkzeug &man.date.1;. Dazu ein Beispiel: &prompt.user; date -j -f '%Y%m%d-%H%M%S' '20090401-000000' '+%s' Den Update Code bauen Der erste Schritt ist das Ausführen von scripts/make.sh. Dieses Skript baut einige Binärdateien, erstellt Verzeichnisse und einen RSA Signaturschlüssel für die Genehmigung des Bau. In diesem Schritt müssen Sie auch eine Passphrase für die Erstellung des Signaturschlüssels angeben. &prompt.root; sh scripts/make.sh cc -O2 -fno-strict-aliasing -pipe findstamps.c -o findstamps findstamps.c: In function 'usage': findstamps.c:45: warning: incompatible implicit declaration of built-in function 'exit' cc -O2 -fno-strict-aliasing -pipe unstamp.c -o unstamp install findstamps ../bin install unstamp ../bin rm -f findstamps unstamp Generating RSA private key, 4096 bit long modulus ................................................................................++ ...................++ e is 65537 (0x10001) Public key fingerprint: 27ef53e48dc869eea6c3136091cc6ab8589f967559824779e855d58a2294de9e Encrypting signing key for root enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: Notieren Sie sich den Fingerabdruck des erzeugten Schlüssels. Dieser Wert wird in /etc/freebsd-update.conf für die binären Updates benötigt. An dieser Stelle sind wir bereit, den Bauprozess zu starten. &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/init.sh amd64 7.2-RELEASE Hier folgt ein Beispiel für einen ersten Bauprozess. &prompt.root; sh scripts/init.sh amd64 7.2-RELEASE Mon Aug 24 16:04:36 PDT 2009 Starting fetch for FreeBSD/amd64 7.2-RELEASE /usr/local/freebsd-update-server/work/7.2-RELE100% of 588 MB 359 kBps 00m00s Mon Aug 24 16:32:38 PDT 2009 Verifying disc1 hash for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 16:32:44 PDT 2009 Extracting components for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 16:34:05 PDT 2009 Constructing world+src image for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 16:35:57 PDT 2009 Extracting world+src for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 23:36:24 UTC 2009 Building world for FreeBSD/amd64 7.2-RELEASE Tue Aug 25 00:31:29 UTC 2009 Distributing world for FreeBSD/amd64 7.2-RELEASE Tue Aug 25 00:32:36 UTC 2009 Building and distributing kernels for FreeBSD/amd64 7.2-RELEASE Tue Aug 25 00:44:44 UTC 2009 Constructing world components for FreeBSD/amd64 7.2-RELEASE Tue Aug 25 00:44:56 UTC 2009 Distributing source for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:46:18 PDT 2009 Moving components into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:46:33 PDT 2009 Identifying extra documentation for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:47:13 PDT 2009 Extracting extra docs for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:47:18 PDT 2009 Indexing release for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:50:44 PDT 2009 Indexing world0 for FreeBSD/amd64 7.2-RELEASE Files built but not released: Files released but not built: Files which differ by more than contents: Files which differ between release and build: kernel|generic|/GENERIC/hptrr.ko kernel|generic|/GENERIC/kernel src|sys|/sys/conf/newvers.sh world|base|/boot/loader world|base|/boot/pxeboot world|base|/etc/mail/freebsd.cf world|base|/etc/mail/freebsd.submit.cf world|base|/etc/mail/sendmail.cf world|base|/etc/mail/submit.cf world|base|/lib/libcrypto.so.5 world|base|/usr/bin/ntpq world|base|/usr/lib/libalias.a world|base|/usr/lib/libalias_cuseeme.a world|base|/usr/lib/libalias_dummy.a world|base|/usr/lib/libalias_ftp.a ... Anschließend wird das Basissystem mit den dazugehörigen Patches erneut gebaut. Eine detaillierte Erklärung dazu finden Sie in scripts/build.subr. Während der zweiten Bauphase wird der Network Time Protocol Dienst, &man.ntpd.8;, ausgeschaltet. Per &a.cperciva.email;, emeritierter Security Officer von &os;, "Der - freebsd-update-server + freebsd-update-server Code muss Zeitstempel, welche in Dateien gespeichert sind, identifizieren, sodass festgestellt werden kann, welche Dateien aktualisiert werden müssen. Dies geschieht, indem zwei Builds erstellt werden die 400 Tage auseinander liegen und anschließend die Ergebnisse verglichen werden." Mon Aug 24 17:54:07 PDT 2009 Extracting world+src for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 00:54:34 UTC 2010 Building world for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 01:49:42 UTC 2010 Distributing world for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 01:50:50 UTC 2010 Building and distributing kernels for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 02:02:56 UTC 2010 Constructing world components for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 02:03:08 UTC 2010 Distributing source for FreeBSD/amd64 7.2-RELEASE Tue Sep 28 19:04:31 PDT 2010 Moving components into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:04:46 PDT 2009 Extracting extra docs for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:04:51 PDT 2009 Indexing world1 for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:08:04 PDT 2009 Locating build stamps for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:10:19 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:10:19 PDT 2009 Preparing to copy files into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:10:20 PDT 2009 Copying data files into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 12:16:57 PDT 2009 Copying metadata files into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 12:16:59 PDT 2009 Constructing metadata index and tag for FreeBSD/amd64 7.2-RELEASE Files found which include build stamps: kernel|generic|/GENERIC/hptrr.ko kernel|generic|/GENERIC/kernel world|base|/boot/loader world|base|/boot/pxeboot world|base|/etc/mail/freebsd.cf world|base|/etc/mail/freebsd.submit.cf world|base|/etc/mail/sendmail.cf world|base|/etc/mail/submit.cf world|base|/lib/libcrypto.so.5 world|base|/usr/bin/ntpq world|base|/usr/include/osreldate.h world|base|/usr/lib/libalias.a world|base|/usr/lib/libalias_cuseeme.a world|base|/usr/lib/libalias_dummy.a world|base|/usr/lib/libalias_ftp.a ... Schlussendlich wird der Bauprozess fertiggestellt. Values of build stamps, excluding library archive headers: v1.2 (Aug 25 2009 00:40:36) v1.2 (Aug 25 2009 00:38:22) @(#)FreeBSD 7.2-RELEASE #0: Tue Aug 25 00:38:29 UTC 2009 FreeBSD 7.2-RELEASE #0: Tue Aug 25 00:38:29 UTC 2009 root@server.myhost.com:/usr/obj/usr/src/sys/GENERIC 7.2-RELEASE Mon Aug 24 23:55:25 UTC 2009 Mon Aug 24 23:55:25 UTC 2009 ##### built by root@server.myhost.com on Tue Aug 25 00:16:15 UTC 2009 ##### built by root@server.myhost.com on Tue Aug 25 00:16:15 UTC 2009 ##### built by root@server.myhost.com on Tue Aug 25 00:16:15 UTC 2009 ##### built by root@server.myhost.com on Tue Aug 25 00:16:15 UTC 2009 Mon Aug 24 23:46:47 UTC 2009 ntpq 4.2.4p5-a Mon Aug 24 23:55:53 UTC 2009 (1) * Copyright (c) 1992-2009 The FreeBSD Project. Mon Aug 24 23:46:47 UTC 2009 Mon Aug 24 23:55:40 UTC 2009 Aug 25 2009 ntpd 4.2.4p5-a Mon Aug 24 23:55:52 UTC 2009 (1) ntpdate 4.2.4p5-a Mon Aug 24 23:55:53 UTC 2009 (1) ntpdc 4.2.4p5-a Mon Aug 24 23:55:53 UTC 2009 (1) Tue Aug 25 00:21:21 UTC 2009 Tue Aug 25 00:21:21 UTC 2009 Tue Aug 25 00:21:21 UTC 2009 Mon Aug 24 23:46:47 UTC 2009 FreeBSD/amd64 7.2-RELEASE initialization build complete. Please review the list of build stamps printed above to confirm that they look sensible, then run # sh -e approve.sh amd64 7.2-RELEASE to sign the release. Genehmigen Sie den Bau, wenn alles korrekt ist. Weitere Informationen zur korrekten Bestimmung finden Sie in der Quelldatei namens USAGE. Führen Sie, wie angegeben scripts/approve.sh aus. Dieser Schritt unterschreibt das Release und verschiebt die Komponenten an einen Sammelpunkt, wo sie für den Upload verwendet werden können. &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/mountkey.sh &prompt.root; sh -e scripts/approve.sh amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Signing build for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to patch source directories for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to upload staging area for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:07 PDT 2009 Updating databases for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE Nachdem der Genehmigungsprozess abgeschlossen ist, kann der Upload gestartet werden. &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/upload.sh amd64 7.2-RELEASE Wenn der Update-Code erneut hochgeladen werden muss, kann dies durch die Änderung des öffentlichen Distributionsverzeichnisses für das Ziel-Release und der Aktualisierung der Attribute für die hochgeladene Datei geschehen. &prompt.root; cd /usr/local/freebsd-update-server/pub/7.2-RELEASE/amd64 &prompt.root; touch -t 200801010101.01 uploaded Um die Updates zu verteilen, müssen die hochgeladenen Dateien im Document Root des Webservers liegen. Die genaue Konfiguration hängt von dem verwendeten Webserver ab. Für den Apache Webserver, beziehen Sie sich bitte auf das Kapitel Konfiguration des Apache Servers im Handbuch. Aktualisieren Sie KeyPrint und ServerName in der /etc/freebsd-update.conf des Clients und führen Sie das Update, wie im Kapitel &os; Update des Handbuchs beschrieben, aus. Damit &fbus.ap; ordnungsgemäß funktioniert, muss sowohl das current Release als auch das Release auf welches Sie aktualisieren wollen neu gebaut werden. Dies ist notwendig, um die Unterschiede von Dateien zwischen den beiden Releases bestimmen zu können. Zum Beispiel beim Upgrade eines &os; Systems von 7.1-RELEASE auf 7.2-RELEASE, müssen für beide Versionen Updates gebaut und auf den Webserver hochgeladen werden. Als Referenz wird der gesamte Verlauf von init.sh beigefügt. Eine Fehlerkorrektur erstellen Jedes Mal, wenn ein Sicherheits-Hinweis oder ein Fehler-Hinweis angekündigt wird, kann eine Fehlerkorrektur gebaut werden. Für dieses Beispiel wird 7.1-RELEASE benutzt. Für den Bau eines anderen Release werden ein paar Annahmen getroffen: Richten Sie die korrekte Verzeichnisstruktur für den ersten Bau ein. Führen Sie einen ersten Bau für 7.1-RELEASE aus. Erstellen Sie das Korrekturverzeichnis des jeweiligen Releases unter /usr/local/freebsd-update-server/patches/. &prompt.user; mkdir -p /usr/local/freebsd-update-server/patches/7.1-RELEASE/ &prompt.user; cd /usr/local/freebsd-update-server/patches/7.1-RELEASE Als Beispiel nehmen Sie die Korrektur für &man.named.8;. Lesen Sie den Hinweis und laden Sie die erforderliche Datei von &os; Sicherheits-Hinweise herunter. Weitere Informationen zur Interpretation der Sicherheitshinweise finden Sie im &os; Handbuch. - In der Sicherheits + In der Sicherheits Anweisung, nennt sich dieser Hinweis SA-09:12.bind. Nach dem Herunterladen der Datei, ist es erforderlich, die Datei auf einen geeigneten Patch-Level umzubenennen. Es steht Ihnen frei den Namen frei zu wählen, es wird jedoch nahegelegt, diesen im Einklang mit dem offiziellen &os; Patch-Level zu halten. Für diesen Bau folgen wir der derzeit gängigen Praxis von &os; und benennen sie p7. Benennen Sie die Datei um: &prompt.user; cd /usr/local/freebsd-update-server/patches/7.1-RELEASE/; mv bind.patch 7-SA-09:12.bind Wenn ein Patch-Level gebaut wird, wird davon ausgegangen, dass die bisherigen Korrekturen bereits vorhanden sind. Wenn der Bau läuft, werden alle Korrekturen aus dem Patchverzeichnis mit gebaut. Es können auch selbsterstellte Korrekturen zum Bau hinzugefügt werden. Benutzen Sie die Zahl Null, oder jede andere Zahl. Es liegt in der Verantwortung des Administrators des &fbus.ap; geeignete Maßnahmen zu treffen, um die Authentizität jeder Fehlerkorrektur zu überprüfen. An dieser Stelle sind wir bereit, einen Diff zu bauen. Die Software prüft zunächst, ob scripts/init.sh für das jeweilige Release gelaufen ist, bevor mit dem Bau des Diff begonnen wird. &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/diff.sh amd64 7.1-RELEASE 7 Es folgt ein Beispiel für einen Diff Bauprozess. &prompt.root; sh -e scripts/diff.sh amd64 7.1-RELEASE 7 Wed Aug 26 10:09:59 PDT 2009 Extracting world+src for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 17:10:25 UTC 2009 Building world for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:05:11 UTC 2009 Distributing world for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:06:16 UTC 2009 Building and distributing kernels for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:17:50 UTC 2009 Constructing world components for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:18:02 UTC 2009 Distributing source for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 11:19:23 PDT 2009 Moving components into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 11:19:37 PDT 2009 Extracting extra docs for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 11:19:42 PDT 2009 Indexing world0 for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 11:23:02 PDT 2009 Extracting world+src for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 18:23:29 UTC 2010 Building world for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 19:18:15 UTC 2010 Distributing world for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 19:19:18 UTC 2010 Building and distributing kernels for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 19:30:52 UTC 2010 Constructing world components for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 19:31:03 UTC 2010 Distributing source for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 12:32:25 PDT 2010 Moving components into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:32:39 PDT 2009 Extracting extra docs for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:32:43 PDT 2009 Indexing world1 for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:35:54 PDT 2009 Locating build stamps for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:36:58 PDT 2009 Reverting changes due to build stamps for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:37:14 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:37:14 PDT 2009 Preparing to copy files into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:37:15 PDT 2009 Copying data files into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:43:23 PDT 2009 Copying metadata files into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:43:25 PDT 2009 Constructing metadata index and tag for FreeBSD/amd64 7.1-RELEASE-p7 ... Files found which include build stamps: kernel|generic|/GENERIC/hptrr.ko kernel|generic|/GENERIC/kernel world|base|/boot/loader world|base|/boot/pxeboot world|base|/etc/mail/freebsd.cf world|base|/etc/mail/freebsd.submit.cf world|base|/etc/mail/sendmail.cf world|base|/etc/mail/submit.cf world|base|/lib/libcrypto.so.5 world|base|/usr/bin/ntpq world|base|/usr/include/osreldate.h world|base|/usr/lib/libalias.a world|base|/usr/lib/libalias_cuseeme.a world|base|/usr/lib/libalias_dummy.a world|base|/usr/lib/libalias_ftp.a ... Values of build stamps, excluding library archive headers: v1.2 (Aug 26 2009 18:13:46) v1.2 (Aug 26 2009 18:11:44) @(#)FreeBSD 7.1-RELEASE-p7 #0: Wed Aug 26 18:11:50 UTC 2009 FreeBSD 7.1-RELEASE-p7 #0: Wed Aug 26 18:11:50 UTC 2009 root@server.myhost.com:/usr/obj/usr/src/sys/GENERIC 7.1-RELEASE-p7 Wed Aug 26 17:29:15 UTC 2009 Wed Aug 26 17:29:15 UTC 2009 ##### built by root@server.myhost.com on Wed Aug 26 17:49:58 UTC 2009 ##### built by root@server.myhost.com on Wed Aug 26 17:49:58 UTC 2009 ##### built by root@server.myhost.com on Wed Aug 26 17:49:58 UTC 2009 ##### built by root@server.myhost.com on Wed Aug 26 17:49:58 UTC 2009 Wed Aug 26 17:20:39 UTC 2009 ntpq 4.2.4p5-a Wed Aug 26 17:29:42 UTC 2009 (1) * Copyright (c) 1992-2009 The FreeBSD Project. Wed Aug 26 17:20:39 UTC 2009 Wed Aug 26 17:29:30 UTC 2009 Aug 26 2009 ntpd 4.2.4p5-a Wed Aug 26 17:29:41 UTC 2009 (1) ntpdate 4.2.4p5-a Wed Aug 26 17:29:42 UTC 2009 (1) ntpdc 4.2.4p5-a Wed Aug 26 17:29:42 UTC 2009 (1) Wed Aug 26 17:55:02 UTC 2009 Wed Aug 26 17:55:02 UTC 2009 Wed Aug 26 17:55:02 UTC 2009 Wed Aug 26 17:20:39 UTC 2009 ... Die Updates werden angezeigt und warten auf Genehmigung. New updates: kernel|generic|/GENERIC/kernel.symbols|f|0|0|0555|0|7c8dc176763f96ced0a57fc04e7c1b8d793f27e006dd13e0b499e1474ac47e10| kernel|generic|/GENERIC/kernel|f|0|0|0555|0|33197e8cf15bbbac263d17f39c153c9d489348c2c534f7ca1120a1183dec67b1| kernel|generic|/|d|0|0|0755|0|| src|base|/|d|0|0|0755|0|| src|bin|/|d|0|0|0755|0|| src|cddl|/|d|0|0|0755|0|| src|contrib|/contrib/bind9/bin/named/update.c|f|0|10000|0644|0|4d434abf0983df9bc47435670d307fa882ef4b348ed8ca90928d250f42ea0757| src|contrib|/contrib/bind9/lib/dns/openssldsa_link.c|f|0|10000|0644|0|c6805c39f3da2a06dd3f163f26c314a4692d4cd9a2d929c0acc88d736324f550| src|contrib|/contrib/bind9/lib/dns/opensslrsa_link.c|f|0|10000|0644|0|fa0f7417ee9da42cc8d0fd96ad24e7a34125e05b5ae075bd6e3238f1c022a712| ... FreeBSD/amd64 7.1-RELEASE update build complete. Please review the list of build stamps printed above and the list of updated files to confirm that they look sensible, then run # sh -e approve.sh amd64 7.1-RELEASE to sign the build. Folgen Sie dem zuvor erwähnten Verfahren für die Genehmigung des Bauprozesses: &prompt.root; sh -e scripts/approve.sh amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Signing build for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to patch source directories for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to upload staging area for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:07 PDT 2009 Updating databases for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.1-RELEASE The FreeBSD/amd64 7.1-RELEASE update build has been signed and is ready to be uploaded. Remember to run # sh -e umountkey.sh to unmount the decrypted key once you have finished signing all the new builds. Nachdem Sie den Bau genehmigt haben, starten Sie den Upload der Software: &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/upload.sh amd64 7.1-RELEASE Als Referenz wird der gesamte Verlauf von diff.sh beigefügt. Tipps Wenn Sie ein selbst erstelltes Release über die native make release Prozedur bauen, wir der freebsd-update-server Code Ihr Release unterstützen. Als Beispiel können Sie ein Release ohne Ports oder Dokumentation bauen, indem Sie betreffende Funktionalität der Subroutinen findextradocs (), addextradocs () entfernen und eine Veränderung des Download-Verzeichnisses in fetchiso (), in scripts/build.subr. Als letzten Schritt ändern Sie den &man.sha256.1; Hash in build.conf für Ihr jeweiliges Release und Architektur damit Sie bereit sind, Ihr benutzerdefiniertes Release zu bauen. # Compare ${WORKDIR}/release and ${WORKDIR}/$1, identify which parts # of the world|doc subcomponent are missing from the latter, and # build a tarball out of them. findextradocs () { } # Add extra docs to ${WORKDIR}/$1 addextradocs () { } Durch das Hinzufügen von zu den buildworld und obj Zielen in scripts/build.subr kann die Verarbeitung, abhängig von der eingesetzten Hardware, beschleunigt werden. Die Benutzung dieser Optionen auf andere Ziele wird jedoch nicht empfohlen, da sie den Bau unzuverlässig machen können. > # Build the world log "Building world" cd /usr/src && make -j 2 ${COMPATFLAGS} buildworld 2>&1 # Distribute the world log "Distributing world" cd /usr/src/release && make -j 2 obj && make ${COMPATFLAGS} release.1 release.2 2>&1 Erstellen Sie einen geeigneten DNS SRV Datensatz für den Update-Server, und fügen Sie weitere Server mit verschiedenen Gewichtungen hinzu. Sie können diese Möglichkeit nutzen um Update-Mirror hinzuzufügen. Dieser Tipp ist jedoch nicht notwendig solange Sie keinen redundanten Service anbieten möchten. _http._tcp.update.myserver.com. IN SRV 0 2 80 host1.myserver.com. SRV 0 1 80 host2.myserver.com. SRV 0 0 80 host3.myserver.com.
Index: head/de_DE.ISO8859-1/books/handbook/config/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/config/chapter.xml (revision 51670) +++ head/de_DE.ISO8859-1/books/handbook/config/chapter.xml (revision 51671) @@ -1,3833 +1,3839 @@ 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. /etc/namedb Das Vorgabeverzeichnis, in dem Daten von &man.named.8; gehalten werden. Normalerweise werden hier named.conf und Zonendaten abgelegt. /usr/local/etc Installierte Anwendungen legen hier ihre Konfigurationsdateien ab. Dieses Verzeichnis kann Unterverzeichnisse für bestimmte Anwendungen enthalten. /usr/local/etc/rc.d &man.rc.8;-Skripten installierter Anwendungen. /var/db Automatisch generierte systemspezifische Datenbanken, wie die Paket-Datenbank oder die &man.locate.1;-Datenbank. Hostnamen hostname DNS <filename>/etc/resolv.conf</filename> resolv.conf Wie ein &os;-System auf das Internet Domain Name System (DNS) zugreift, wird in /etc/resolv.conf festgelegt. Die gebräuchlichsten Einträge in /etc/resolv.conf sind: nameserver Die IP-Adresse eines Nameservers, den der Resolver abfragen soll. Bis zu drei Server werden in der Reihenfolge, in der sie aufgezählt sind, abgefragt. search Suchliste mit Domain-Namen zum Auflösen von Hostnamen. Die Liste wird normalerweise durch den Domain-Teil des lokalen Hostnamens festgelegt. domain Der lokale Domain-Name. Beispiel für eine typische /etc/resolv.conf: search example.com nameserver 147.11.1.11 nameserver 147.11.100.30 Nur eine der Anweisungen search oder domain sollte benutzt werden. Wenn Sie DHCP benutzen, überschreibt &man.dhclient.8; für gewöhnlich /etc/resolv.conf mit den Informationen vom DHCP-Server. <filename>/etc/hosts</filename> hosts /etc/hosts ist eine einfache textbasierte Datenbank. Zusammen mit DNS und NIS stellt sie eine Abbildung zwischen Namen und IP-Adressen zur Verfügung. Anstatt &man.named.8; zu konfigurieren, können hier lokale Rechner, die über ein LAN verbunden sind, eingetragen werden. Lokale Einträge für gebräuchliche Internet-Adressen in /etc/hosts verhindern die Abfrage eines externen Servers und beschleunigen die Namensauflösung. # $&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. 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/eresources/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/eresources/chapter.xml (revision 51670) +++ head/de_DE.ISO8859-1/books/handbook/eresources/chapter.xml (revision 51671) @@ -1,2467 +1,2467 @@ Ressourcen im Internet Gedruckte Medien können mit der schnellen Entwicklung von &os; nicht Schritt halten. Elektronische Medien sind häufig die einzige Möglichkeit, über aktuelle Entwicklungen informiert zu sein. Da &os; ein Projekt von Freiwilligen ist, gibt die Benutzergemeinde selbst auch technische Unterstützung. Die Benutzergemeinde erreichen Sie am besten über E-Mail, Internetforen oder Usenet-News. Die wichtigsten Wege, auf denen Sie die &os;-Benutzergemeinde erreichen können, sind unten dargestellt. Schicken Sie weitere Ressourcen, die hier fehlen, an die Mailingliste des &a.doc;, damit diese hier aufgenommen werden können. Webseiten Die &os; Foren dienen als webbasiertes Diskussionsforum für Fragen und technische Diskussionen zu &os;. - Planet + Planet &os; bietet einen gesammelten Feed aus dutzenden von Blogs, die von den &os; Entwicklern geschrieben werden. Viele Entwickler nutzen dies, um schnell Aufzeichnungen darüber zu veröffentlichen, woran sie gerade arbeiten, welche neuen Erweiterungen es gibt und andere Arbeiten, die gerade im Gange sind. Der BSDConferences YouTube-Kanal beinhaltet eine Sammlung von qualitativ hochwertigen Videos von BSD Konferenzen aus der ganzen Welt. Dies ist eine ausgezeichnete Art und Weise, den Entwicklern beim Präsentieren von neuen Arbeiten an &os; zuzuschauen. Mailinglisten Die Mailinglisten sind der direkteste Weg, um Fragen an das gesamte &os; Publikum zu stellen oder eine technische Diskussion zu beginnen. Es existiert eine große Vielfalt von Listen mit einer Reihe von verschiedenen &os; Themen. Wenn Sie Fragen an die richtige Mailingliste richten können Sie viel eher mit einer passenden Antwort darauf rechnen. Die Chartas der verschiedenen Listen sind unten wiedergegeben. Bevor Sie sich einer Mailingliste anschließen oder E-Mails an eine Liste senden, lesen Sie bitte die Charta der Liste. Die meisten Mitglieder der Mailinglisten erhalten jeden Tag Hunderte E-Mails zum Thema &os;. Die Chartas und Regeln, die den Gebrauch der Listen beschreiben, garantieren die hohe Qualität der Listen. Die Listen würden ihren hohen Wert für das Projekt verlieren, wenn wir weniger Regeln aufstellen würden. Um zu testen, ob Sie eine Nachricht an eine &os;-Liste senden können, verwenden Sie bitte die Liste &a.test.name;. Schicken Sie derartige Nachrichten bitte nicht an eine der anderen Listen. Wenn Sie Sich nicht sicher sind, auf welcher Liste Sie Ihre Frage stellen sollen, sollten Sie den Artikel How to get best results from the FreeBSD-questions mailing list lesen. Bevor Sie eine Nachricht an eine Mailingliste senden, sollten Sie die korrekte Nutzung der Mailinglisten erlernen. Dazu gehört auch das Vermeiden von sich häufig wiederholenden Diskussionen (lesen Sie deshalb zuerst die Mailing List Frequently Asked Questions). Alle Mailinglisten werden archiviert und können auf dem &os; World Wide Web Server durchsucht werden. Das nach Schlüsselwörtern durchsuchbare Archiv bietet die hervorragende Möglichkeit, Antworten auf häufig gestellte Fragen zu finden. Nutzen Sie bitte diese Möglichkeit, bevor Sie Fragen auf einer Liste stellen. Beachten Sie auch, dass das zur Folge hat, dass die Nachrichten an die &os; Mailinglisten für die Ewigkeit erhalten bleiben. Wenn Sie am Schutz Ihrer Privatsphäre interessiert sind, ziehen Sie die Verwendung einer Wegwerf-E-Mail-Adresse in Betracht und schreiben Sie nur solche Nachrichten, die für die Öffentlichkeit bestimmt sind. Beschreibung der Mailinglisten Allgemeine Listen: Jeder kann die folgenden allgemeinen Listen abonnieren (und ist dazu aufgefordert): Mailingliste Zweck &a.advocacy.name; Verbreitung von &os; &a.announce.name; Wichtige Ereignisse und Meilensteine des Projekts (moderiert) &a.arch.name; Architektur und Design von &os; &a.bugbusters.name; Diskussionen über die Pflege der &os; Fehlerberichte-Datenbank und die dazu benutzten Werkzeuge &a.bugs.name; Fehlerberichte &a.chat.name; Nicht technische Themen, welche die &os;-Gemeinschaft betreffen &a.chromium.name; Diskussionen zum Einsatz von Chromium unter &os; &a.current.name; Gebrauch von &os.current; &a.isp.name; Für Internet-Service-Provider, die &os; benutzen &a.jobs.name; Anstellung und Beratung im &os;-Umfeld &a.questions.name; Benutzerfragen und technische Unterstützung &a.security-notifications.name; Ankündigungen zum Thema Sicherheit (moderiert) &a.stable.name; Gebrauch von &os.stable; &a.test.name; Schicken Sie Testnachrichten an diese Liste anstelle der wirklichen Listen Technische Listen: Auf den folgenden Listen werden technische Diskussionen geführt. Bevor Sie eine der Listen abonnieren oder Nachrichten an sie schicken, lesen Sie sich die Charta der Liste durch, da der Inhalt und Zweck dieser Listen genau festgelegt ist. Mailingliste Zweck &a.acpi.name; Entwicklung von ACPI &a.afs.name; Portierung von AFS nach &os; &a.amd64.name; Portierung von &os; auf AMD64-Systeme (moderiert) &a.apache.name; Diskussion über Ports, die mit Apache zusammenhängen. &a.arm.name; Portierung von &os; auf &arm;-Prozessoren &a.atm.name; Benutzung von ATM-Netzen mit &os; &a.bluetooth.name; &bluetooth; unter &os; verwenden &a.cloud.name; &os; auf Cloud-Plattformen (EC2, GCE, Azure, etc.) &a.cluster.name; Benutzung von &os; in einem Cluster &a.database.name; Diskussion über Datenbanken und Datenbankprogrammierung unter &os; &a.desktop.name; &os; als Desktop verwenden und verbessern &a.doc.name; Erstellen der &os;-Dokumentation &a.drivers.name; Gerätetreiber für &os; schreiben &a.dtrace.name; Entwicklung und Benutzung von DTrace unter &os; &a.eclipse.name; Für &os;-Anwender, welche die Eclipse IDE, deren Werkzeuge, Anwendungen und Ports einsetzen &a.elastic.name; Diskussion zu ElasticSearch unter &os; &a.embedded.name; &os; in eingebetteten Anwendungen einsetzen &a.emulation.name; Emulation anderer Systeme wie &linux;, &ms-dos; oder &windows; &a.enlightenment.name; Portierung von Enlightenment und Enlightenment-Applikationen &a.eol.name; Support für &os;-bezogene Software, die vom &os; Project offiziell nicht mehr unterstützt wird. &a.firewire.name; Technische Diskussion über &os; &firewire; (iLink, IEEE 1394) &a.fortran.name; Fortran unter &os; &a.fs.name; Dateisysteme &a.games.name; Unterstützung für Spiele unter &os; &a.gecko.name; Angelegenheiten zur Gecko Rendering Engine &a.geom.name; Diskussion über GEOM &a.git.name; Diskussionen zur Verwendung von git im &os; Project &a.gnome.name; Portierung von GNOME und GNOME-Anwendungen &a.hackers.name; Allgemeine technische Diskussionen &a.haskell.name; &os;-spezifische Haskell-Themen und Diskussionen &a.hardware.name; Allgemeine Diskussion über Hardware, auf der &os; läuft &a.i18n.name; Internationalisierung von &os; &a.ia32.name; &os; für die IA-32 (&intel; x86) Plattform &a.ia64.name; Portierung von &os; auf &intel;s neue IA64-Systeme &a.infiniband.name; Infiniband unter &os; &a.ipfw.name; Technische Diskussion über die Neubearbeitung der IP-Firewall Quellen &a.isdn.name; Für Entwickler des ISDN-Systems &a.java.name; Für &java; Entwickler und Leute, die &jdk;s nach &os; portieren &a.kde.name; Portierung von KDE und KDE-Anwendungen &a.lfs.name; Portierung von LFS nach &os; &a.mips.name; Portierung von &os; zu &mips; &a.mobile.name; Diskussionen über mobiles Rechnen &a.mono.name; Mono und C# Anwendungen auf &os; &a.multimedia.name; Multimedia Anwendungen &a.newbus.name; Technische Diskussionen über die Architektur von Bussen &a.net.name; Diskussion über Netzwerke und den TCP/IP Quellcode &a.numerics.name; Diskussionen über die Implementierung hochwertiger Funktionen in libm &a.office.name; Office-Anwendungen für &os; &a.performance.name; Fragen zur Optimierung der Leistung stark ausgelasteter Systeme &a.perl.name; Pflege der portierten Perl-Anwendungen. &a.pf.name; Diskussionen und Fragen zu packet filter als Firewallsystem. &a.pkg.name; Diskussionen über die Verwaltung von Binärpaketen und entsprechenden Werkzeugen &a.pkg-fallout.name; Protokolle von fehlgeschlagenen Paketbauvorgängen &a.pkgbase.name; Paketierung des &os;-Basissystems &a.platforms.name; Portierungen von &os; auf nicht-&intel; Architekturen &a.ports.name; Diskussion über die Ports-Sammlung &a.ports-announce.name; Wichtige Neuigkeiten und Anweisungen zur Ports-Sammlung (moderiert) &a.ports-bugs.name; Diskussion über Fehler und PRs der Ports &a.ppc.name; Portierung von &os; auf den &powerpc; &a.proliant.name; Technische Diskussionen zum Einsatz von &os; auf HP ProLiant-Serverplattformen &a.python.name; &os;-spezifische Diskussionen zu Python &a.rc.name; Diskussion über das rc.d-System sowie dessen Weiterentwicklung &a.realtime.name; Entwicklung von Echtzeiterweiterungen für &os; &a.ruby.name; &os;-spezifische Diskussionen zu Ruby &a.scsi.name; Diskussion über das SCSI-Subsystem &a.security.name; Sicherheitsthemen &a.small.name; Gebrauch von &os; in eingebetteten Systemen (obsolet; verwenden Sie stattdessen &a.embedded.name;) &a.snapshots.name; Ankündigungen für &os; Entwickler-Snapshots &a.sparc.name; Portierung von &os; auf &sparc; Systeme &a.standards.name; Konformität von &os; mit den C99- und &posix;-Standards &a.sysinstall.name; &man.sysinstall.8; Entwicklung &a.tcltk.name; &os; spezifische Tcl/TK Diskussionen &a.testing.name; Tests unter &os; &a.tex.name; Portierung von TeX und dessen Anwendungen nach &os; &a.threads.name; Leichtgewichtige Prozesse (Threads) in &os; &a.tilera.name; Diskussionen zur Portierung von &os; auf die Tilera-CPU-Familie &a.tokenring.name; Token-Ring Unterstützung in &os; &a.toolchain.name; Wartung der &os;-Toolchain &a.translators.name; Übersetzung von &os;-Dokumenten und Programmen. &a.transport.name; Diskussion über Transportprotokolle in &os; &a.usb.name; USB-Unterstützung in &os; &a.virtualization.name; Diskussion über verschiedene Virtualisierungsverfahren, die von &os; unterstützt werden &a.vuxml.name; Diskussion über die Infrastruktur von VuXML &a.x11.name; Wartung und Unterstützung von X11 auf &os; &a.xen.name; Diskussionen über die &os; Portierung auf &xen; - Implementierung und Verwendung &a.xfce.name; Portierung und Wartung von XFCE &a.zope.name; Zope für &os; - Portierung und Wartung Eingeschränkte Listen: Die folgenden Listen wenden sich an Zielgruppen mit speziellen Anforderungen und sind nicht für die Öffentlichkeit gedacht. Bevor Sie eine dieser Listen abonnieren, sollten Sie einige der technischen Listen abonniert haben, um mit den Umgangsformen vertraut zu sein. Mailingliste Zweck &a.hubs.name; Betrieb von &os;-Spiegeln &a.usergroups.name; Koordination von Benutzergruppen &a.wip-status.name; Status von in Arbeit befindlichen &os;-Tätigkeiten &a.wireless.name; Diskussionen zum 802.11-Stack sowie zur Entwicklung von Tools und Gerätetreibern Zusammenfassungen: Alle eben aufgezählten Listen sind auch in zusammengefasster Form (digest) erhältlich. In den Einstellungen Ihres Accounts legen Sie fest, in welcher Form Sie die Listen empfangen. SVN Listen: Die folgenden Listen versenden die Log-Einträge zu Änderungen an verschiedenen Teilen des Quellbaums. Diese Listen sollen nur gelesen werden, schicken Sie bitte keine Nachrichten an eine der Listen. Mailingliste Teil des Quellbaums Beschreibung &a.svn-doc-all.name; /usr/doc Änderungen im doc Subversion Repository (mit Ausnahme von user, projects und translations) &a.svn-doc-head.name; /usr/doc Änderungen im head-Zweig des doc Subversion Repository &a.svn-doc-projects.name; /usr/doc/projects Änderungen im projects-Bereich des doc Subversion Repository &a.svn-doc-svnadmin.name; /usr/doc Änderungen an den administrativen Skripten, Hooks und anderen Konfigurationsdateien des doc Subversion Repository &a.svn-ports-all.name; /usr/ports Alle Änderungen des ports Subverison Repository &a.svn-ports-head.name; /usr/ports Änderungen im head-Zweig des ports Subversion Repository &a.svn-ports-svnadmin.name; /usr/ports Änderungen an den administrativen Skripten, Hooks und anderen Konfigurationsdateien des ports Subversion Repository &a.svn-src-all.name; /usr/src Änderungen im src Subversion Repository (außer für user und projects) &a.svn-src-head.name; /usr/src Änderungen im head Zweig des src Subversion Repository (der &os;-CURRENT Zweig) &a.svn-src-projects.name; /usr/projects Änderungen im projects Bereich des src Subversion Repository &a.svn-src-release.name; /usr/src Änderungen im releases Bereich des src Subversion Repository &a.svn-src-releng.name; /usr/src Änderungen im releng Zweig des src Subversion Repository (der security / release engineering Zweige) &a.svn-src-stable.name; /usr/src Änderungen an allen stable Zweigen des src Subversion Repository &a.svn-src-stable-6.name; /usr/src Änderungen im stable/6 Zweig des src Subversion Repository &a.svn-src-stable-7.name; /usr/src Änderungen im stable/7 Zweig des src Subversion Repository &a.svn-src-stable-8.name; /usr/src Änderungen im stable/8 Zweig des src Subversion Repository &a.svn-src-stable-9.name; /usr/src Änderungen im stable/9 Zweig des src Subversion Repository &a.svn-src-stable-10.name; /usr/src Änderungen im stable/10 Zweig des src Subversion Repository &a.svn-src-stable-11.name; /usr/src Änderungen im stable/11 Zweig des src Subversion Repository &a.svn-src-stable-other.name; /usr/src Änderungen an älteren stable Zweigen des src Subversion Repository &a.svn-src-svnadmin.name; /usr/src Änderungen an den administrativen Skripten, hooks, und anderen Daten zur Konfiguration des src Subversion Repository &a.svn-src-user.name; /usr/src Änderungen am experimentellen user Bereich des src Subversion Repository &a.svn-src-vendor.name; /usr/src Änderungen am Herstellerbereich des src Subversion Repository Mailinglisten abonnieren Um eine Liste zu abonnieren, besuchen die Webseite &a.mailman.lists.link; und klicken dort auf die Liste, die Sie abonnieren wollen. Sie gelangen dann auf die Webseite der Liste, die weitere Anweisungen für diese Liste enthält. Um eine Nachricht an eine Mailingliste zu schicken, schreiben Sie einfach eine E-Mail an Liste@FreeBSD.org. Die E-Mail wird dann an alle Mitglieder der Mailingliste verteilt. Wenn Sie das Abonnement aufheben wollen, folgen Sie der URL, die am Ende jeder Mail der Liste angegeben ist. Sie können das Abonnement auch mit einer E-Mail an Liste-unsubscribe@FreeBSD.org aufheben. Verwenden Sie bitte die technischen Listen ausschließlich für technische Diskussionen. Wenn Sie nur an wichtigen Ankündigungen interessiert sind, abonnieren Sie die Mailingliste &a.announce;, auf der nur wenige Nachrichten versendet werden. Chartas der Mailinglisten Alle &os;-Mailinglisten besitzen Grundregeln, die von jedem beachtet werden müssen. Für die ersten beiden Male, in denen ein Absender gegen diese Regeln verstößt, erhält er jeweils eine Warnung vom &os;-Postmaster postmaster@FreeBSD.org. Ein dritter Verstoß gegen die Regeln führt dazu, dass der Absender in allen &os;-Mailinglisten gesperrt wird und weitere Nachrichten von ihm nicht mehr angenommen werden. Wir bedauern sehr, dass wir solche Maßnahmen ergreifen müssen, aber heutzutage ist das Internet eine recht rauhe Umgebung, in der immer weniger Leute Rücksicht aufeinander nehmen. Die Regeln: Das Thema einer Nachricht soll der Charta der Liste, an die sie gesendet wird, entsprechen. Wenn Sie eine Nachricht an eine technische Liste schicken, sollte die Nachricht auch technische Inhalte haben. Fortwährendes Geschwätz oder Streit mindern den Wert der Liste für alle Mitglieder und wird nicht toleriert. Benutzen Sie &a.chat; für allgemeine Diskussionen über &os;. Eine Nachricht sollte an nicht mehr als zwei Mailinglisten gesendet werden. Schicken Sie eine Nachricht nur dann an zwei Listen, wenn das wirklich notwendig ist. Viele Leute haben mehrere Mailinglisten abonniert und Nachrichten sollten nur zu ungewöhnlichen Kombinationen der Listen, wie -stable und -scsi, gesendet werden. Wenn Sie eine Nachricht erhalten, die im Cc-Feld mehrere Listen enthält, sollten Sie das Feld kürzen, bevor Sie eine Antwort darauf verschicken. Unabhängig von dem ursprünglichen Verteiler sind Sie für Ihre eigenen Mehrfach-Sendungen selbst verantwortlich. Persönliche Angriffe und Beschimpfungen sind in einer Diskussion nicht erlaubt. Dies gilt gleichermaßen für Benutzer wie Entwickler. Grobe Verletzungen der Netiquette, wie das Verschicken oder Zitieren von privater E-Mail ohne eine entsprechende Genehmigung, werden nicht gebilligt. Die Nachrichten werden aber nicht besonders auf Verletzungen der Netiquette untersucht. Es kann sein, dass eine Verletzung der Netiquette durchaus zu der Charta einer Liste passt, aber der Absender aufgrund der Verletzung eine Warnung erhält oder gesperrt wird. Werbung für Produkte oder Dienstleistungen, die nichts mit &os; zu tun haben, sind verboten. Ist die Werbung als Spam verschickt worden, wird der Absender sofort gesperrt. Chartas einzelner Listen: &a.acpi.name; Die Entwicklung von ACPI und Energieverwaltungsfunktionen. &a.afs.name; Andrew File System Auf dieser Liste wird die Portierung des AFS von CMU/Transarc diskutiert. &a.announce.name; Wichtige Ereignisse und Meilensteine Diese Liste ist für Personen, die nur an den wenigen Ankündigungen wichtiger Ereignisse interessiert sind. Die Ankündigungen betreffen Schnappschüsse und Releases, neue Merkmale von &os; und die Suche nach freiwilligen Mitarbeitern. Auf der Liste herrscht wenig Verkehr und sie wird streng moderiert. &a.arch.name; Architektur und Design von &os; Auf dieser technischen Liste wird die &os;-Architektur diskutiert. Beispiele für angemessene Themen sind: Wie das Bausystem zu verändern ist, damit verschiedene Läufe gleichzeitig möglich sind. Was am VFS geändert werden muss, damit Heidemann Schichten eingesetzt werden können. Wie die Schnittstelle der Gerätetreiber angepasst werden muss, damit derselbe Treiber auf verschiedenen Bussen und Architekturen eingesetzt werden kann. Wie ein Netzwerktreiber geschrieben wird. &a.bluetooth.name; &bluetooth; unter &os; Diese Liste diskutiert Probleme der Verwendung von &bluetooth; unter &os;. Designprobleme, Implementierungsdetails, Patches, Fehler- und Statusberichte, Verbesserungsvorschläge sowie alle anderen mit &bluetooth; zusammenhängenden Themen werden hier behandelt. &a.bugbusters.name; Bearbeitung der Fehlerberichte Auf dieser Liste wird die Bearbeitung der Fehlerberichte (PR, engl. problem report) koordiniert. Sie dient dem Bugmeister und allen Leuten, die ein Interesse an der Datenbank der Fehlerberichte haben, als Diskussionsforum. Auf dieser Liste werden keine spezifischen Fehler, Fehlerbehebungen oder PRs diskutiert. &a.bugs.name; Fehlerberichte Auf dieser Liste werden Fehlerberichte gesammelt. Fehlerberichte sollten immer mit der Web-Schnittstelle erstellt werden. &a.chat.name; Nicht technische Themen, welche die &os; Gemeinschaft betreffen Auf dieser Liste werden nicht-technische soziale Themen diskutiert, die nicht auf die anderen Listen passen. Hier kann diskutiert werden, ob Jordan wie ein Frettchen aus einem Zeichentrickfilm aussieht oder nicht, ob grundsätzlich in Großbuchstaben geschrieben werden soll, wer zuviel Kaffee trinkt, wo das beste Bier gebraut wird und wer Bier in seinem Keller braut. Gelegentlich können auf den technischen Listen wichtige Ereignisse wie Feste, Hochzeiten oder Geburten angekündigt werden, aber nachfolgende Nachrichten sollten auf die Liste &a.chat; gesendet werden. &a.chromium.name; Diskussionen zum Einsatz von Chromium unter &os; Auf dieser technischen Liste werden Fragen zur Entwicklung, zur Installation sowie zum Einsatz von Chromium unter &os; diskutiert. &a.cloud.name; &os; auf verschiedenen Cloud-Plattformen betreiben Diese Liste diskutiert &os; auf Amazon EC2, Google Compute Engine, Microsoft Azure und weiteren Cloud-Plattformen. &a.core.name; &os; Core Team Dies ist eine interne Mailingliste des &os; Core Teams. Wenn in einer wichtigen Angelegenheit, die &os; betrifft, entschieden werden muss oder die Angelegenheit einer genauen Prüfung unterzogen werden muss, können Nachrichten an diese Liste gesendet werden. &a.current.name; Gebrauch von &os.current; Diese Mailingliste ist für die Benutzer von &os.current; eingerichtet. Auf ihr finden sich Ankündigungen über Besonderheiten von -CURRENT, von denen Benutzer betroffen sind. Sie enthält weiterhin Anweisungen, wie man ein System auf -CURRENT hält. Jeder, der ein -CURRENT System besitzt, muss diese Liste lesen. Die Liste ist nur für technische Inhalte bestimmt. &a.desktop.name; &os; als Desktop verwenden und verbessern Dies ist ein Forum für Diskussionen um &os; auf dem Desktop. Es wird primär von Desktop-Portierern und Nutzern verwendet, um Probleme und Verbesserungen zu &os;s Einsatz auf dem Desktop zu besprechen. &a.doc.name; Auf dieser Mailingliste werden Themen diskutiert, die im Zusammenhang mit der Erstellung der &os; Dokumentation stehen. The &os; Documentation Project besteht aus den Mitgliedern dieser Liste. Diese Liste steht jedem offen, Sie sind herzlich eingeladen teilzunehmen und mitzuhelfen. &a.drivers.name; Gerätetreiber für &os; schreiben Ein Forum für technische Diskussionen über das Schreiben von Gerätetreibern für &os;. Daher werden hier vor allem Fragen behandelt, die sich um das Schreiben von Treibern, welche die APIs des Kernels nutzen, drehen. &a.dtrace.name; Entwicklung und Benutzung von DTrace unter &os; DTrace ist Bestandteil von &os; und stellt Laufzeitinformationen vom Kernel und Anwendungsprogrammen zur Verfügung. Diese Liste ist für Diskussionen von Entwicklern und Benutzern. &a.eclipse.name; Für &os;-Anwender, welche die Eclipse IDE deren Werkzeuge, Anwendungen und Ports einsetzen Das Ziel dieser Liste ist es, Unterstützung für all jene zu bieten, die mit der Installation, Verwendung, Entwicklung und Wartung der Eclipse-IDE sowie deren Werkzeugen und Anwendungen unter &os; zu tun haben. Außerdem wird Hilfe bei der Portierung der IDE und deren Plugins auf &os; geboten. Zusätzlich soll diese Liste einen Informationsaustausch zwischen der Eclipse- und der &os;-Gemeinde ermöglichen, von dem beide Seiten profitieren können. Obwohl sich diese Liste auf die Anforderungen von Anwendern konzentriert, möchte sie auch Entwickler unterstützen, die an der Entwicklung von &os;-spezifischen Anwendungen unter Nutzung des Eclipse-Frameworks arbeiten. &a.embedded.name; &os; in eingebetteten Anwendungen einsetzen Diese Liste diskutiert Themen im Zusammenhang mit dem Einsatz von ungewöhnlich kleinen und eingebetteten &os;-Installationen. Auf dieser Liste werden ausschließlich technische Diskussionen geführt. Unter eingebetteten Systemen versteht diese Liste Systeme, bei denen es sich nicht um Desktopsysteme handelt, und die in der Regel nur einem einzigen Zweck dienen (im Gegensatz zu Desktopsystemen, die für die Bewältigung verschiedenster Aufgaben geeignet sind). In die Gruppe der eingebetteten Systeme gehören beispielsweise Telefone, Netzwerkgeräte wie Router, Switche oder PBX-Systeme, PDAs, Verkaufsautomaten und andere mehr. &a.emulation.name; Emulation anderer Systeme wie &linux;, &ms-dos; oder &windows; Hier werden technische Diskussionen zum Einsatz von Programmen, die für andere Betriebssysteme geschrieben wurden, geführt. &a.enlightenment.name; Enlightenment Desktop-Umgebung für &os;-Systeme. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.eol.name; Support für &os;-bezogene Software, die vom &os; Project offiziell nicht mehr unterstützt wird. Diese Liste ist für all jene interessant, die Unterstützung für vom &os; Project offiziell nicht mehr (in Form von Security Advisories oder Patches) unterstützte Programme benötigen oder anbieten wollen. &a.firewire.name; &firewire; (iLink, IEEE 1394) Auf dieser Liste wird das Design und die Implementierung eines &firewire;-Subsystems (auch IEEE 1394 oder iLink) für &os; diskutiert. Relevante Themen sind die Standards, Busse und ihre Protokolle, sowie Adapter, Karten und Chipsätze. Des Weiteren die Architektur und der Quellcode, die nötig sind, diese Geräte zu unterstützen. &a.fortran.name; Fortran unter &os; Diese Liste ist für Diskussionen rund um Fortran-Ports unter &os;: Compiler, Bibliotheken, wissenschaftliche und technische Anwendungen von Laptops bis hin zu HPC-Clustern. &a.fs.name; Dateisysteme Diskussionen über &os;-Dateisysteme. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.games.name; Spiele unter &os; Eine Liste für technische Diskussionen im Zusammenhang mit Spielen unter &os;. Die Liste ist für Personen, die an Portierungen arbeiten und alternative Lösungen erörtern. Personen, die an technischen Diskussionen interessiert sind, sind ebenfalls willkommen. &a.gecko.name; Angelegenheiten zur Gecko Rendering Engine Dies ist ein Forum über Gecko-Anwendungen, die &os; verwenden. Die Diskussion dreht sich um die Portierung von Gecko-Anwendungen, deren Installation, die Entwicklung sowie deren Unterstützung innerhalb von &os;. &a.geom.name; GEOM Diskussion über GEOM und verwandte Implementierungen. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.git.name; Verwendung von git im &os; Project Diskussionen über die Verwendung von git in der &os; Infrastruktur. Personen, die einen Spiegel aufsetzen wollen, oder allgemeine Fragen zu git unter &os; haben, können hier Fragen stellen. &a.gnome.name; GNOME Diskussionen über die grafische Benutzeroberfläche GNOME. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.infiniband.name; Infiniband unter &os; Technische Liste mit Diskussionen über Infiniband, OFED und OpenSM unter &os;. &a.ipfw.name; IP Firewall Diskussionen über eine Neubearbeitung des IP-Firewall Quelltexts in &os;. Dies ist eine technische Liste, in der nur technische Inhalte erwartet werden. &a.ia64.name; Portierung von &os; auf die IA64-Plattform Dies ist eine technische Liste für diejenigen, die &os; auf die IA-64 Plattform von &intel; portieren. Themen sind die Probleme bei der Portierung und deren Lösung. Interessierte, die der Diskussion folgen wollen, sind ebenfalls willkommen. &a.isdn.name; ISDN Subsystem Mailingliste für die Entwickler des ISDN Subsystems von &os;. &a.java.name; &java; Entwicklung Mailingliste, auf der die Entwicklung von &java; Anwendungen für &os; sowie die Portierung und Pflege von &jdk;s diskutiert wird. &a.jobs.name; Stellenangebote und Stellengesuche In diesem Forum können Sie Stellenangebote und Stellengesuche, die mit &os; zu tun haben, aufgeben. Diese Mailingliste ist nicht der Ort, um über allgemeine Beschäftigungsprobleme zu diskutieren; dazu gibt es anderswo geeignete Foren. Beachten Sie bitte, dass diese Liste, wie die anderen FreeBSD.org-Listen, weltweit gelesen wird. Geben Sie daher bitte den Arbeitsort genau an. Geben Sie bitte auch an, ob Telearbeit möglich ist und ob Hilfen für einen Umzug angeboten werden. Benutzen Sie in der E-Mail bitte nur offene Formate – vorzugsweise nur das Textformat. Andere Formate, wie PDF oder HTML, werden von den Lesern akzeptiert. Nicht offene Formate wie µsoft; Word (.doc) werden vom Server der Liste abgelehnt. &a.hackers.name; Technische Diskussionen Dies ist ein Forum für technische Diskussionen über &os;. Leute, die aktiv an &os; arbeiten, können hier Probleme und deren Lösungen diskutieren. Interessierte, die den Diskussionen folgen wollen, steht die Liste ebenfalls offen. Auf dieser Liste finden nur technische Diskussionen statt. &a.hardware.name; Allgemeine Diskussionen über Hardware Allgemeine Diskussionen über die Hardware, auf der &os; läuft: Probleme und Ratschläge welche Hardware man kaufen sollte und welche nicht. &a.hubs.name; &os;-Spiegel Ankündigungen und Diskussionsforum für Leute, die &os;-Spiegel betreiben. &a.isp.name; Themen für Internet Service Provider Diese Liste ist für Internet Service Provider (ISP), die &os; benutzen. Auf dieser Liste finden nur technische Diskussionen statt. &a.mono.name; Mono und C# Anwendungen auf &os; Diese Liste beinhaltet Diskussionen über das Mono Entwicklungsframework auf &os;. Dies ist eine technische Mailingliste. Es ist für Personen gedacht, die aktiv an der Portierung von Mono oder C# Anwendungen auf &os; sind, um Probleme oder alternative Lösungen zu beratschlagen. Personen die der technischen Diskussion folgen möchten sind ebenso willkommen. &a.kde.name; KDE Diskussionen über KDE auf &os;-Systemen. Dies ist eine technische Liste, in der nur technische Inhalte diskutiert werden. &a.ops-announce.name; Projekt-Infrastruktur Ankündigungen Diese Liste für Leute gedacht, die an Veränderungen im Zusammenhang der &os;-Projekt Infrastruktur interessiert sind. Diese moderierte Liste wird ausschließlich für Ankündigungen verwendet. Sie können keine Anfragen an diese Liste stellen und erhalten somit auch keine Antworten. &a.performance.name; Diskussionsforum mit dem Ziel, die Leistung von &os; zu verbessern. Auf dieser Liste diskutieren Hacker, Systemadministratoren und andere Interessierte die Leistung von &os;. Zulässige Themen sind beispielsweise Systeme unter hoher Last, Systeme mit Leistungsproblemen oder Systeme, die Leistungsgrenzen von &os; überwinden. Jeder, der mithelfen will, die Leistung von &os; zu verbessern, sollte diese Liste abonnieren. Die Liste ist technisch anspruchsvoll und geeignet für erfahrene &os;-Benutzer, Hacker oder Administratoren, die &os; schnell, robust und skalierbar halten wollen. Auf der Liste werden Beiträge gesammelt oder Fragen nach ungelösten Problemen beantwortet. Sie ist kein Ersatz für das gründliche Studium der Dokumentation. &a.pf.name; Diskussionen und Fragen zu packet filter als Firewallsystem. &os;-spezifische Diskussionen zur Benutzung von packet filter (pf) als Firewallsystem. Sowohl technische Diskussionen als auch Anwenderfragen sind auf dieser Liste willkommen. Fragen zum ALTQ QoS Framework können ebenfalls gestellt werden. &a.pkg.name; Diskussionen über die Verwaltung von Binärpaketen und entsprechenden Werkzeugen Diskussionen über die Verwendung von Binärpaketen, Werkzeuge zur Paketverwaltung, Entwicklung und Unterstützung innerhalb von &os;, Verwaltung der Paket-Repositories und die Verwaltung von Paketen von Drittherstellern. Beachten Sie, dass diese Liste nicht geeignet ist, um Probleme über nicht gebaute Pakete zu melden. Diese Probleme werden im allgemeinen als Problem des Ports betrachtet. &a.pkg-fallout.name; Protokolle von fehlgeschlagenen Paketbauvorgängen Alle Fehlerprotokolle aus dem Paketcluster. &a.pkgbase.name; Paketierung des &os;-Basissystems Diskussion über die Implementierung und Probleme im Bezug auf die Paketierung des &os;-Basissystems. &a.platforms.name; Portierung auf nicht-&intel; Plattformen Plattformübergreifende Themen und Vorschläge für die Portierung auf nicht-&intel; Plattformen. Auf dieser Liste finden nur technische Diskussionen statt. &a.ports.name; Diskussion über die Ports-Sammlung Diskussionen über die &os;-Ports-Sammlung und die Infrastruktur der Sammlung. Die Liste dient auch der allgemeinen Koordination der Dinge, welche die Ports-Sammlung betreffen. Auf dieser Liste finden nur technische Diskussionen statt. &a.ports-bugs.name; Diskussion über Fehler in den Ports Diskussion über Fehler in der Ports-Sammlung (/usr/ports), neue Ports oder Änderungen an bestehenden Ports. Auf dieser Liste finden nur technische Diskussionen statt. &a.proliant.name; Technische Diskussionen zum Einsatz von &os; auf HP ProLiant-Serverplattformen Diese Mailingliste bietet technische Diskussionen zum Einsatz von &os; auf der ProLiant-Serverplattform von HP, darunter Fragen zu ProLiant-spezifischen Treibern, Konfigurationswerkzeugen sowie BIOS-Aktualisierungen. Daher ist sie die erste Anlaufstelle, um die Module hpasmd, hpasmcli, sowie hpacucli zu diskutieren. &a.python.name; Python unter &os; Diese technische Liste dient der Verbesserung der Python-Unterstützung unter &os;. Sie wird von Personen gelesen, die an der Portierung von Python, von Python-Modulen Dritter und von Zope nach &os; arbeiten. Personen, die diese technischen Diskussion verfolgen wollen, sind ebenfalls willkommen. &a.questions.name; Benutzerfragen Auf dieser Mailingliste können Fragen zu &os; gestellt werden. Fragen Sie bitte nicht nach Anleitungen, wenn Sie nicht sicher sind, dass Ihre Frage wirklich technischer Natur ist. &a.ruby.name; Ruby unter &os; Diese technische Liste dient der Verbesserung der Ruby-Unterstützung unter &os;. Sie wird von Personen gelesen, die an der Portierung von Ruby, von Bibliotheken Dritter und Frameworks arbeiten. Personen, die diese technischen Diskussionen verfolgen wollen, sind ebenfalls willkommen. &a.scsi.name; SCSI Subsystem Diese Mailingliste ist für die Entwickler des SCSI Subsystems von &os;. Auf dieser Liste finden nur technische Diskussionen statt. &a.security.name; Sicherheitsthemen Sicherheitsthemen, die &os; betreffen, wie DES, Kerberos, bekannte Sicherheitslöcher und Fehlerbehebungen. Stellen Sie bitte auf dieser Liste keine allgemeinen Fragen zum Thema Sicherheit. Willkommen sind allerdings Beiträge zur FAQ, das heißt eine Frage mit der passenden Antwort. Auf dieser Liste finden nur technische Diskussionen statt. &a.security-notifications.name; Ankündigungen zum Thema Sicherheit Ankündigungen über Sicherheitsprobleme von &os; und deren Behebungen. Diese Liste ist kein Diskussionsforum, benutzen Sie &a.security;, um Sicherheitsthemen zu diskutieren. &a.small.name; Gebrauch von &os; in eingebetteten Systemen. Diese Liste für ungewöhnlich kleine &os; Installation oder den Einsatz von &os; in eingebetteten Systemen gedacht. Auf dieser Liste finden nur technische Diskussionen statt. Diese Liste wurde durch &a.embedded.name; ersetzt. &a.snapshots.name; Ankündigungen für &os; Entwickler-Snapshots Diese Liste informiert über die Verfügbarkeit von neuen &os;-Snapshots aus den Zweigen head/ und stable/. &a.stable.name; Gebrauch von &os.stable;. Diese Mailingliste ist für die Benutzer von &os.stable; eingerichtet. -STABLE ist der Zweig, in dem die Entwicklung nach einen RELEASE stattfindet, einschließlich Fehlerkorrekturen und neuer Funktionen. Die ABI wird wegen Binärkompatibilitäten stabil gehalten. Auf der Liste finden sich Ankündigungen über Besonderheiten von -STABLE, von denen Benutzer betroffen sind. Sie enthält weiterhin Anweisungen, wie man ein System auf -STABLE hält. Jeder, der ein -STABLE System besitzt, muss diese Liste lesen. Die Liste ist nur für technische Inhalte bestimmt. &a.standards.name; Konformität von &os; mit den C99- und &posix; Standards Dieses Forum ist für technische Diskussionen über die Konformität von &os; mit den C99- und &posix;-Standards. &a.teaching.name; Unterrichten mit &os; Mailingliste, die das Unterrichten mit &os; diskutiert. &a.testing.name; Tests unter &os; Technische Liste, auf der Tests unter &os; diskutiert werden, einschließlich ATF/Kyua, der Test/Build-Infrastruktur, und Portierungen von anderen Betriebssystemen (NetBSD, ...) nach &os;. &a.tex.name; Portierung von TeX und dessen Anwendungen nach &os; Technische Liste für Diskussionen im Zusammenhang mit TeX und dessen Anwendungen unter &os;. Diese Liste ist für Menschen, die an der Portierung von TeX nach &os; arbeiten. Es werden aber auch Probleme und Lösungen erörtert. Personen, die an technischen Diskussionen interessiert sind, sind ebenfalls willkommen. &a.toolchain.name; Wartung der &os;-Toolchain Auf dieser Mailingliste werden alle Themen rund um die &os;-Toolchain diskutiert. Dazu gehören der Status von Clang und GCC, aber auch Fragen zu Programmen wie Assemblern, Linkern und Debuggern. &a.translators.name; Übersetzung von &os;-Dokumenten und Programmen Auf dieser Liste können Übersetzer von &os;-Dokumenten über die Methoden und Werkzeuge für die Übersetzung diskutieren. Neue Benutzer werden gebeten sich vorzustellen und die Sprache zu erwähnen, an dessen Übersetzung sie interessiert sind. &a.transport.name; Diskussion über Transportprotokolle in &os; Diese Liste behandelt die Probleme und das Design von &os;s Netzwerkstack, darunter auch TCP, SCTP und UDP. Andere Netzwerkthemen sollten auf der &a.net; diskutiert werden. &a.usb.name; USB-Unterstützung in &os;. Auf dieser Liste finden nur technische Diskussionen statt. &a.usergroups.name; Koordination von Benutzergruppen Diese Liste ist für Koordinatoren lokaler Benutzergruppen und einem ausgesuchten Mitglied des Core Teams eingerichtet worden. Der Inhalt sollte Inhalte von Treffen und die Koordination von Projekten mehrerer Benutzergruppen beschränkt sein. &a.virtualization.name; Diskussion über verschiedene Virtualisierungsverfahren, die von &os; unterstützt werden Eine Liste, auf der die verschiedenen Virtualisierungsverfahren, die von &os; unterstützt werden, diskutiert werden. Auf der einen Seite liegt der Fokus auf der Implementierung der zugrundeliegenden Funktionalitäten, ebenso wie das Hinzufügen neuer Eigenschaften. Auf der anderen Seite haben die Benutzer ein Forum, um Fragen bei Problemen zu stellen oder um ihre Anwendungsfälle zu besprechen. &a.wip-status.name; Status von in Arbeit befindlichen &os;-Tätigkeiten Diese Mailingliste kann dazu verwendet werden, eigene Kreationen und deren Fortschritt von &os;-verwandten Tätigkeiten anzukündigen. Die Nachrichten werden moderiert. Es wird empfohlen, die Nachricht "An:" eine mehr themenverwandte &os;-Liste zu senden und diese Liste nur in Blindkopie zu setzen. Auf diese Weise kann ihre in Arbeit befindliche Tätigkeit auch auf der themenverwandten Liste diskutiert werden, da auf dieser Liste keine Diskussionen erlaubt sind. Sehen Sie sich das Archiv der Liste für passende Nachrichten an. Redaktionelle Auszüge der Nachrichten an diese Liste werden eventuell alle paar Monate auf die &os; Webseite als Teil der Statusberichte https://www.freebsd.org/news/status/ gestellt. Weitere Beispiele und zurückliegende Berichte können Sie auch dort finden. &a.wireless.name; Diskussionen zum 802.11-Stack sowie zur Entwicklung von Tools und Gerätetreibern Die Mailingliste freebsd-wireless diskutiert Themen rund um den 802.11-Stack (sys/net80211). Besprochen werden die Entwicklung von Tools und Gerätetreibern sowie auftretende Probleme, neue Funktionen sowie die Wartung der existierenden Werkzeuge und Treiber. &a.xen.name; Diskussionen über die &os; Portierung auf &xen; - Implementierung und Verwendung Eine Liste, welche die &os; Portierung auf &xen; behandelt. Das erwartete Nachrichtenaufkommen ist klein genug, so dass es als Forum für sowohl technische Diskussionen über die Implementierung und Entwurfsdetails, als auch administrative Verteilaspekte ausgelegt ist. &a.xfce.name; XFCE Eine Liste, auf der Fragen zum Einsatz von XFCE unter &os; diskutiert werden. Es handelt sich um eine technische Mailingliste, die sich primär an Entwickler richtet, die aktiv an der Portierung von XFCE nach &os; arbeiten. Aber auch Nutzer, die einfach nur die technischen Diskussionen verfolgen wollen, sind willkommen. Diskutiert werden vor allem bei der Portierung auftretende Probleme und mögliche Lösungswege. &a.zope.name; Zope Ein Forum für Diskussionen darüber, wie man die Zope-Umgebung auf &os; portieren kann. Dies ist eine technische Mailingliste. Sie ist für Leute gedacht, die aktiv an der Portierung von Zope auf &os; arbeiten, um aufkommende Probleme oder alternative Lösungsansätze zu besprechen. Personen, die der technischen Diskussion folgen möchten, sind ebenfalls willkommen. Filter der Mailinglisten Um die Verbreitung von Spam, Viren und anderen nicht erwünschten E-Mails zu verhindern, werden auf den &os;-Mailinglisten Filter eingesetzt. Dieser Abschnitt beschreibt nur einen Teil der zum Schutz der Listen eingesetzten Filter. Auf den Mailinglisten sind nur die unten aufgeführten Anhänge erlaubt. Anhänge mit einem anderen MIME-Typ werden entfernt, bevor eine E-Mail an eine Liste verteilt wird. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Einige Mailinglisten erlauben vielleicht Anhänge mit anderem MIME-Typ. Für die meisten Mailinglisten sollte die obige Aufzählung aber richtig sein. Wenn eine E-Mail sowohl aus einer HTML-Version wie auch aus einer Text-Version besteht, wird die HTML-Version entfernt. Wenn eine E-Mail nur im HTML-Format versendet wurde, wird sie in reinen Text umgewandelt. Usenet-News Neben den Gruppen, die sich ausschließlich mit BSD beschäftigen, gibt es viele weitere in denen über &os; diskutiert wird, oder die für &os;-Benutzer wichtig sind. BSD spezifische Gruppen comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (deutsch) fr.comp.os.bsd (französisch) it.comp.os.bsd (italienisch) Weitere UNIX Gruppen comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.misc comp.unix.bsd X Window System comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.emulators.ms-windows.wine Offizielle Spiegel &chap.eresources.www.index.inc; &chap.mirrors.lastmod.inc; &chap.eresources.www.inc; Index: head/de_DE.ISO8859-1/books/handbook/multimedia/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/multimedia/chapter.xml (revision 51670) +++ head/de_DE.ISO8859-1/books/handbook/multimedia/chapter.xml (revision 51671) @@ -1,1755 +1,1755 @@ Multimedia Ross Lippert Überarbeitet von Übersicht &os; unterstützt viele unterschiedliche Soundkarten, die Benutzern den Genuss von Highfidelity-Klängen auf dem Computer ermöglichen. Dazu gehört unter anderem die Möglichkeit, Tonquellen in den Formaten MPEG Audio Layer 3 (MP3), Waveform Audio File (WAV), Ogg Vorbis und vielen weiteren Formaten aufzunehmen und wiederzugeben. Darüber hinaus enthält die &os; Ports-Sammlung Anwendungen, die das Bearbeiten von aufgenommenen Tonspuren, das Hinzufügen von Klangeffekten und die Kontrolle der angeschlossenen MIDI-Geräte erlauben. &os; unterstützt auch die Wiedergabe von Videos und DVDs. Die &os; Ports-Sammlung enthält Anwendungen, um verschiedene Video-Medien wiederzugeben, zu kodieren und zu konvertieren. Dieses Kapitel beschreibt die Einrichtung von Soundkarten, Video-Wiedergabe, TV-Tuner Karten und Scannern unter &os;. Es werden auch einige Anwendungen beschrieben, die für die Verwendung dieser Geräte zur Verfügung stehen. Dieses Kapitel behandelt die folgenden Punkte: Konfiguration einer Soundkarte in &os;. Fehlersuche bei Sound Einstellungen. Wiedergabe und Kodierung von MP3s und anderen Audio-Formaten. Vorbereitung des Systems für die Wiedergabe von Videos. Wiedergabe von DVDs, .mpg- und .avi-Dateien. Rippen von CDs und DVDs. Konfiguration von TV-Karten. Installation und Konfiguration von MythTV. Bevor Sie dieses Kapitel lesen, sollten Sie: Wissen, wie Sie Anwendungen installieren (). Soundkarten einrichten Moses Moore Von Marc Fonvieille Aktualisiert von Benedikt Köhler Übersetzt von Uwe Pierau PCI Soundkarten Bevor Sie die Konfiguration beginnen, sollten Sie in Erfahrung bringen welches Soundkartenmodell und welcher Chip benutzt wird. &os; unterstützt eine Reihe Soundkarten. Die Hardware-Notes zählen alle unterstützten Karten und deren Treiber für &os; auf. Kernel Konfiguration Um die Soundkarte benutzen zu können, muss der richtige Gerätetreiber geladen werden. Am einfachsten ist es, das Kernelmodul für die Soundkarte mit &man.kldload.8; zu laden. Dieses Beispiel lädt den Treiber für einen integrierten Chipsatz, basierend auf der Intel Spezifikation: &prompt.root; kldload snd_hda Um den Treiber automatisch beim Systemstart zu laden, fügen Sie folgende Zeile in /boot/loader.conf ein: snd_hda_load="YES" Weitere ladbare Soundmodule sind in /boot/defaults/loader.conf aufgeführt. Wenn Sie nicht sicher sind, welchen Gerätetreiber Sie laden müssen, laden Sie das Modul snd_driver: &prompt.root; kldload snd_driver Der Treiber snd_driver ist ein Meta-Treiber, der alle gebräuchlichen Treiber lädt und die Suche nach dem richtigen Treiber vereinfacht. Durch Hinzufügen des Meta-Treibers in /boot/loader.conf können alternativ alle Audio-Treiber geladen werden. Um zu ermitteln, welcher Treiber für die Soundkarte vom Meta-Treiber snd_driver geladen wurde, geben Sie cat /dev/sndstat ein. Soundkarten in der Kernelkonfiguration einrichten Die Unterstützung für die Soundkarte kann auch direkt in den Kernel kompiliert werden. Weitere Informationen über den Bau eines Kernels finden Sie im . Bei der Verwendung eines eigenen Kernels müssen Sie sicherstellen, dass der Treiber für das Audio-Framework in der Kernelkonfigurationsdatei vorhanden ist: device sound Als Nächstes muss die Unterstützung für die Soundkarte hinzugefügt werden. Um das Beispiel mit dem integrierten Intel Audio-Chipsatz aus dem vorherigen Abschnitt fortzusetzen, verwenden Sie die folgende Zeile in der Kernelkonfigurationsdatei: device snd_hda Lesen Sie die Manualpage des Treibers, um den entsprechenden Gerätenamen herauszufinden. Nicht PnP-fähige ISA-Soundkarten benötigen eventuell Einstellungen, wie IRQ und I/O-Port in /boot/device.hints. Während des Systemstarts liest der &man.loader.8; diese Datei und reicht die Einstellungen an den Kernel weiter. Für eine alte Creative &soundblaster; 16 ISA-Karte, die sowohl den &man.snd.sbc.4;- als auch den snd_sb16-Treiber benötigt, müssen die folgenden Zeilen in die Kernelkonfigurationsdatei eingetragen werden: device snd_sbc device snd_sb16 Wenn die Karte den I/O-Port 0x220 und IRQ 5 benutzt, müssen folgende Zeilen zusätzlich in /boot/device.hints hinzugefügt werden: hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x15" Die Syntax für /boot/device.hints wird in &man.sound.4;, sowie in der Manualpage des jeweiligen Treibers beschrieben. Das Beispiel verwendet die vorgegebenen Werte. Falls die Karteneinstellungen andere Werte vorgeben, müssen die Werte in der Kernelkonfiguration angepasst werden. Weitere Informationen zu dieser Soundkarte finden Sie in &man.snd.sbc.4;. Die Soundkarte testen Nachdem Sie den neuen Kernel gestartet oder das erforderliche Modul geladen haben, sollte die Soundkarte erkannt werden. Führen Sie dmesg | grep pcm aus, um dies zu überprüfen. Diese Ausgabe stammt von einem System mit einem integrierten Conexant CX20590 Chipsatz: pcm0: <NVIDIA (0x001c) (HDMI/DP 8ch)> at nid 5 on hdaa0 pcm1: <NVIDIA (0x001c) (HDMI/DP 8ch)> at nid 6 on hdaa0 pcm2: <Conexant CX20590 (Analog 2.0+HP/2.0)> at nid 31,25 and 35,27 on hdaa1 Der Status der Karte kann auch mit diesem Kommando geprüft werden: &prompt.root; cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: <NVIDIA (0x001c) (HDMI/DP 8ch)> (play) pcm1: <NVIDIA (0x001c) (HDMI/DP 8ch)> (play) pcm2: <Conexant CX20590 (Analog 2.0+HP/2.0)> (play/rec) default Die Ausgabe kann für jede Soundkarte anders aussehen. Wenn das Gerät pcm nicht erscheint, prüfen Sie die Kernelkonfigurationsdatei und stellen Sie sicher, dass der richtige Treiber geladen oder in den Kernel kompiliert wurde. Im nächsten Abschnitt werden häufig auftretende Probleme sowie deren Lösungen besprochen. Jetzt sollte die Soundkarte unter &os; funktionieren. Wenn ein CD- oder DVD-Laufwerk an die Soundkarte angeschlossen ist, können Sie jetzt mit &man.cdcontrol.1; eine CD abspielen: &prompt.user; cdcontrol -f /dev/acd0 play 1 Audio CDs besitzen eine spezielle Kodierung. Daher sollten sie nicht mit &man.mount.8; in das Dateisystem eingehangen werden. Es gibt viele Anwendungen, wie audio/workman, die eine bessere Benutzerschnittstelle besitzen. Zur Wiedergabe von MP3-Audiodateien kann audio/mpg123 installiert werden. Eine weitere schnelle Möglichkeit die Karte zu prüfen, ist es, Daten an das Gerät /dev/dsp zu senden: &prompt.user; cat Datei > /dev/dsp Für Datei kann eine beliebige Datei verwendet werden. Wenn Sie einige Geräusche hören, funktioniert die Soundkarte. Die Gerätedateien /dev/dsp* werden automatisch erzeugt, wenn sie das erste Mal benötigt werden. Werden sie nicht verwendet, sind sie hingegen nicht vorhanden und tauchen daher auch nicht in der Ausgabe von &man.ls.1; auf. Fehlerbehebung Device Node Gerätedatei I/O port IRQ DSP zeigt typische Fehlermeldungen sowie deren Lösungen: Typische Fehlermeldungen Fehler Lösung sb_dspwr(XX) timed out Der I/O-Port ist nicht korrekt angegeben. bad irq XX Der IRQ ist falsch angegeben. Stellen Sie sicher, dass der angegebene IRQ mit dem Sound IRQ übereinstimmt. xxx: gus pcm not attached, out of memory Es ist nicht genug Speicher verfügbar, um das Gerät zu betreiben. xxx: can't open /dev/dsp! Überprüfen Sie mit fstat | grep dsp ob eine andere Anwendung das Gerät geöffnet hat. Häufige Störenfriede sind esound oder die Sound-Unterstützung von KDE.
Moderne Grafikkarten beinhalten oft auch ihre eigenen Soundtreiber, um HDMI zu verwenden. Diese Audiogeräte werden manchmal vor der eigentlichen, separaten Soundkarte aufgeführt und dadurch nicht als das Standardgerät zum Abspielen von Tönen benutzt. Um zu prüfen, ob das der Fall ist, führen Sie dmesg aus und suchen Sie nach der Zeichenfolge pcm. Die Ausgabe sieht in etwa so aus: ... hdac0: HDA Driver Revision: 20100226_0142 hdac1: HDA Driver Revision: 20100226_0142 hdac0: HDA Codec #0: NVidia (Unknown) hdac0: HDA Codec #1: NVidia (Unknown) hdac0: HDA Codec #2: NVidia (Unknown) hdac0: HDA Codec #3: NVidia (Unknown) pcm0: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 0 nid 1 on hdac0 pcm1: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 1 nid 1 on hdac0 pcm2: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 2 nid 1 on hdac0 pcm3: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 3 nid 1 on hdac0 hdac1: HDA Codec #2: Realtek ALC889 pcm4: <HDA Realtek ALC889 PCM #0 Analog> at cad 2 nid 1 on hdac1 pcm5: <HDA Realtek ALC889 PCM #1 Analog> at cad 2 nid 1 on hdac1 pcm6: <HDA Realtek ALC889 PCM #2 Digital> at cad 2 nid 1 on hdac1 pcm7: <HDA Realtek ALC889 PCM #3 Digital> at cad 2 nid 1 on hdac1 ... In diesem Beispiel wurde die Grafikkarte (NVidia) vor der Soundkarte (Realtek ALC889) aufgeführt. Um die Soundkarte als Standardabspielgerät einzusetzen, ändern Sie hw.snd.default_unit auf die Einheit, welche für das Abspielen benutzt werden soll: &prompt.root; sysctl hw.snd.default_unit=n Hier repräsentiert n die Nummer der Soundkarte, die verwendet werden soll, in diesem Beispiel also 4. Sie können diese Änderung dauerhaft machen, indem Sie die folgende Zeile in /etc/sysctl.conf hinzufügen: hw.snd.default_unit=4 Mehrere Tonquellen abspielen Munish Chopra Beigetragen von Oft sollen mehrere Tonquellen gleichzeitig abgespielt werden. &os; verwendet dazu virtuelle Tonkanäle. Virtuelle Kanäle mischen die Tonquellen im Kernel, sodass mehrere Kanäle benutzt werden können, als von der Hardware unterstützt werden. Drei &man.sysctl.8; Optionen stehen zur Konfiguration der virtuellen Kanäle zur Verfügung: &prompt.root; sysctl dev.pcm.0.play.vchans=4 &prompt.root; sysctl dev.pcm.0.rec.vchans=4 &prompt.root; sysctl hw.snd.maxautovchans=4 Im Beispiel werden vier virtuelle Kanäle eingerichtet, eine im Normalfall ausreichende Anzahl. Sowohl dev.pcm.0.play.vchans=4 und dev.pcm.0.rec.vchans=4 sind die Anzahl der virtuellen Kanäle des Geräts pcm0, die fürs Abspielen und Aufnehmen verwendet werden und sie können konfiguriert werden, sobald das Gerät existiert. Da das Modul pcm unabhängig von den Hardware-Treibern geladen werden kann, gibt hw.snd.maxautovchans die Anzahl der virtuellen Kanäle an, die später eingerichtete Audiogeräte erhalten. Lesen Sie &man.pcm.4; für weitere Informationen. Die Anzahl der virtuellen Kanäle kann nicht geändert werden, solange das Gerät genutzt wird. Schließen Sie daher zuerst alle Programme wie Musikabspielprogramme oder Sound-Daemonen, die auf dieses Gerät zugreifen. Die korrekte pcm-Gerätedatei wird automatisch zugeteilt, wenn ein Programm das Gerät /dev/dsp0 anfordert. Den Mixer einstellen Josef El-Rayes Beigetragen von Die Voreinstellungen des Mixers sind im Treiber &man.pcm.4; fest kodiert. Es gibt zwar viele Anwendungen und Dienste, die den Mixer einstellen können und die eingestellten Werte bei jedem Start wieder setzen, am einfachsten ist es allerdings, die Standardwerte für den Mixer direkt im Treiber einzustellen. Der Mixer kann mit den entsprechenden Werten in /boot/device.hints eingestellt werden: hint.pcm.0.vol="50" Die Zeile setzt die Lautstärke des Mixers beim Laden des Moduls &man.pcm.4; auf den Wert 50. MP3-Audio Chern Lee Ein Beitrag von Benedikt Köhler Übersetzt von Dieser Abschnitt beschreibt einige unter &os; verfügbare MP3-Player. Zudem wird beschrieben, wie Audio-CDs gerippt und MP3s kodiert und dekodiert werden. MP3-Player Ein beliebter graphischer MP3-Player ist XMMS, welcher WinAmp-Skins und zusätzliche Plugins unterstützt. Die Benutzerschnittstelle ist leicht zu erlernen und enthält eine Playlist, einen graphischen Equalizer und vieles mehr. Diejenigen, die bereits mit WinAmp vertraut sind, werden XMMS sehr leicht zu benutzen finden. Unter &os; kann XMMS als Port oder Paket multimedia/xmms installiert werden. Das Paket audio/mpg123 ist ein alternativer, kommandozeilenorientierter MP3-Player. Nach der Installation kann die abzuspielende MP3-Datei auf der Kommandozeile angegeben werden. Geben Sie auch das entsprechende Soundkarte an, falls das System über mehrere Audiogeräte verfügt: &prompt.root; mpg123 -a /dev/dsp1.0 Foobar-GreatestHits.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3 version 1.18.1; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes Playing MPEG stream from Foobar-GreatestHits.mp3 ... MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo Weitere MP3-Player stehen in der &os; Ports-Sammlung zur Verfügung. <acronym>CD</acronym>-Audio Tracks rippen Bevor eine ganze CD oder einen CD-Track in das MP3-Format umgewandelt werden kann, müssen die Audiodaten von der CD auf die Festplatte gerippt werden. Dabei werden die CDDA (CD Digital Audio) Rohdaten in WAV-Dateien kopiert. Die Anwendung cdda2wav, die im sysutils/cdrtools Paket enthalten ist, kann zum Rippen der Audiodaten von CDs genutzt werden. Wenn die Audio CD in dem Laufwerk liegt, kann der folgende Befehl als root ausgeführt werden, um eine ganze CD in einzelne WAV-Dateien zu rippen: &prompt.root; cdda2wav -D 0,1,0 -B In diesem Beispiel bezieht sich der Schalter auf das SCSI-Gerät 0,1,0, das die zu rippende CD enthält. Benutzen Sie cdrecord -scanbus um die richtigen Geräteparameter für das System zu bestimmen. Um einzelne Tracks zu rippen, benutzen Sie wie folgt: &prompt.root; cdda2wav -D 0,1,0 -t 7 Um mehrere Tracks zu rippen, zum Beispiel die Tracks eins bis sieben, können Sie wie folgt einen Bereich angeben: &prompt.root; cdda2wav -D 0,1,0 -t 1+7 Wenn Sie von einem ATAPI (IDE) CD-ROM-Laufwerk rippen, geben Sie den Gerätenamen anstelle der SCSI-Gerätenummer an. Dieses Beispiel rippt Track 7 von einem IDE-Laufwerk: &prompt.root; cdda2wav -D /dev/acd0 -t 7 Alternativ können mit dd ebenfalls Audio-Stücke von ATAPI-Laufwerken kopiert werden. Dies wird in erläutert. MP3-Dateien kodieren und dekodieren Lame ist ein weitverbreiteter MP3-Encoder, der als Port audio/lame installiert werden kann. Wegen Patentproblemen ist kein Paket verfügbar. Der folgende Befehl konvertiert die gerippte WAV-Datei audio01.wav in audio01.mp3 um: &prompt.root; lame -h -b 128 --tt "Foo Liedtietel" --ta "FooBar Künstler" --tl "FooBar Album" \ --ty "2014" --tc "Gerippt und kodiert von Foo" --tg "Musikrichtung" audio01.wav audio01.mp3 128 kbits ist die gewöhnliche MP3-Bitrate, wohingegen die Bitraten 160 und 192 kbits eine höhere Qualität bieten. Je höher die Bitrate ist, desto mehr Speicherplatz benötigt die resultierende MP3-Datei. Die Option verwendet den higher quality but a little slower (höhere Qualität, aber etwas langsamer) Modus. Die Schalter, die mit beginnen, sind ID3-Tags, die in der Regel Informationen über das Lied enthalten und in die MP3-Datei eingebettet sind. Weitere Optionen können in der Manualpage von lame nachgelesen werden. Um aus MP3-Dateien eine Audio CD zu erstellen, müssen diese zuerst in ein nicht komprimiertes Format umgewandelt werden. Verwenden Sie XMMS um die Datei im WAV-Format zu schreiben und mpg123, um die MP3-Datei in rohe PCM-Audiodaten umzuwandeln. Um audio01.mp3 mit mpg123 umzuwandeln, geben Sie den Namen der PCM-Datei an: &prompt.root; mpg123 -s audio01.mp3 > audio01.pcm So verwenden Sie XMMS um eine MP3-Datei in das WAV-Format zu konvertieren: Mit <application>XMMS</application> in das <acronym>WAV</acronym>-Format konvertieren Starten Sie XMMS. Klicken Sie mit der rechten Maustaste, um das XMMS-Menu zu öffnen. Wählen Sie Preferences im Untermenü Options. Ändern Sie das Output-Plugin in Disk Writer Plugin. Drücken Sie Configure. Geben Sie ein Verzeichnis ein, in das Sie die unkomprimierte Datei schreiben wollen. Laden Sie die MP3-Datei wie gewohnt in XMMS mit einer Lautstärke von 100% und einem abgeschalteten EQ. Drücken Sie Play und es wird so aussehen, als spiele XMMS die MP3-Datei ab, aber keine Musik ist zu hören. Der Player überspielt die MP3-Datei in eine Datei. Vergessen Sie nicht, das Output-Plugin wieder in den Ausgangszustand zurückzusetzen um wieder MP3-Dateien anhören zu können. cdrecord kann mit beiden Formaten Audio-CDs erstellen. Der Dateikopf von WAV-Dateien erzeugt am Anfang des Stücks ein Knacken. Der Dateikopf mit dem Port oder Paket audio/sox entfernt werden: &prompt.user; sox -t wav -r 44100 -s -w -c 2 track.wav track.raw Lesen Sie , um mehr Informationen zur Benutzung von CD-Brennern mit &os; zu erhalten. Videos wiedergeben Ross Lippert Beigetragen von Bevor Sie beginnen, sollten Sie das Modell und den benutzten Chip der Videokarte kennen. Obwohl &xorg; viele Videokarten unterstützt, können nicht alle Karten Videos schnell genug wiedergeben. Eine Liste der Erweiterungen, die der &xorg;-Server für eine Videokarte unterstützt, erhalten Sie unter laufendem &xorg; mit xdpyinfo. Halten Sie eine kurze MPEG-Datei bereit, mit der Sie Wiedergabeprogramme und deren Optionen testen können. Da einige DVD-Spieler in der Voreinstellung das DVD-Gerät mit /dev/dvd ansprechen oder diesen Namen fest einkodiert haben, ist es vielleicht hilfreich symbolische Links auf die richtigen Geräte anzulegen: &prompt.root; ln -sf /dev/acd0 /dev/dvd Aufgrund der Beschaffenheit &man.devfs.5; gehen gesondert angelegte Links wie diese bei einem Neustart des Systems verloren. Damit die symbolischen Links automatisch beim Neustart des Systems angelegt werden, fügen Sie die folgende Zeile in /etc/devfs.conf ein: link acd0 dvd Das Entschlüsseln von DVDs erfordert den Aufruf bestimmter Funktionen, sowie Schreibzugriff auf das DVD-Gerät. &xorg; benutzt Shared-Memory und es wird empfohlen, die nachstehenden &man.sysctl.8;-Variablen auf die gezeigten Werte zu erhöhen: kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 Video-Schnittstellen XVideo SDL DGA Es gibt einige Möglichkeiten, Videos unter &xorg; abzuspielen. Welche Möglichkeit funktioniert, hängt stark von der verwendeten Hardware ab. Gebräuchliche Video-Schnittstellen sind: &xorg;: normale Ausgabe über Shared-Memory. XVideo: Eine Erweiterung der &xorg;-Schnittstelle, die Videos in jedem X11-Drawable anzeigen kann. Diese Erweiterung bietet auch auf leistungsschwachen Maschinen eine gute Qualität der Wiedergabe. Der nächste Abschnitt beschreibt, wie Sie feststellen, ob diese Erweiterung ausgeführt wird. SDL: Simple DirectMedia Layer ist eine portable Schnittstelle für verschiedene Betriebssysteme, mit denen Anwendungen plattformunabhängig und effizient Ton und Grafik benutzen können. SDL bietet eine hardwarenahe Schnittstelle, die manchmal schneller ist als die &xorg;-Schnittstelle. Unter &os; kann SDL über das Paket oder den Port devel/sdl20 installiert werden. DGA: Direct Graphics Access ist eine &xorg;-Erweiterung die es Anwendungen erlaubt, am &xorg;-Server vorbei direkt in den Framebuffer zu schreiben. Da die Anwendung und der &xorg;-Server auf gemeinsame Speicherbereiche zugreifen, müssen die Anwendungen unter dem Benutzer root laufen. Die DGA-Erweiterung kann mit &man.dga.1; getestet werden. Wenn DGA ausgeführt wird, ändert sich die Farbe des Bildschrims, wenn eine Taste gedrückt wird. Drücken Sie zum Beenden q. SVGAlib: Eine Schnittstelle zur Grafikausgabe auf der Konsole. XVideo Ob die Erweiterung läuft, entnehmen Sie der Ausgabe von xvinfo: &prompt.user; xvinfo XVideo wird untertsützt, wenn die Ausgabe in etwa wie folgt aussieht: X-Video Extension version 2.2 screen #0 Adaptor #0: "Savage Streams Engine" number of ports: 1 port base: 43 operations supported: PutImage supported visuals: depth 16, visualID 0x22 depth 16, visualID 0x23 number of attributes: 5 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_SATURATION" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_HUE" (range -180 to 180) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 1024 x 1024 Number of image formats: 7 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x36315652 (RV16) guid: 52563135-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x3e0, 0x7c00 id: 0x35315652 (RV15) guid: 52563136-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x7e0, 0xf800 id: 0x31313259 (Y211) guid: 59323131-0000-0010-8000-00aa00389b71 bits per pixel: 6 number of planes: 3 type: YUV (packed) id: 0x0 guid: 00000000-0000-0000-0000-000000000000 bits per pixel: 0 number of planes: 0 type: RGB (packed) depth: 1 red, green, blue masks: 0x0, 0x0, 0x0 Einige der aufgeführten Formate, wie YUV2 oder YUV12 existieren in machen XVideo-Implementierungen nicht. Dies kann zu Problemen mit einigen Spielern führen. XVideo wird wahrscheinlich von der Karte nicht unterstützt, wenn die Ausgabe wie folgt aussieht: X-Video Extension version 2.2 screen #0 no adaptors present Wenn die XVideo-Erweiterung auf der Karte nicht läuft, wird es nur etwas schwieriger, die Anforderungen für die Wiedergabe von Videos zu erfüllen. Video-Anwendungen Video-Anwendungen Dieser Abschnitt behandelt Anwendungen aus der &os;-Ports-Sammlung, die für die Wiedergabe von Videos genutzt werden können. <application>MPlayer</application> und <application>MEncoder</application> MPlayer ist ein auf Geschwindigkeit und Flexibilität ausgelegter Video-Spieler für die Kommandozeile mit optionaler graphischer Oberfläche. Weitere graphische Oberflächen für MPlayer stehen in der &os; Ports-Sammlung zur Verfügung. MPlayer MPlayer kann als Paket oder Port multimedia/mplayer installiert werden. Der Bau von MPlayer berücksichtigt die vorhandene Hardware und es können zahlreiche Optionen ausgewählt werden. Aus diesen Gründen ziehen es manche Benutzer vor, den Port zu übersetzen, anstatt das Paket zu installieren. Die Optionen sollten beim Bau des Ports überprüft werden, um dem Umfang der Unterstützung, mit dem der Port gebaut wird, zu bestimmen. Wenn eine Option nicht ausgewählt wird, ist MPlayer nicht in der Lage, diese Art von Video-Format wiederzugeben. Mit den Pfeiltasten und der Leertaste können die erforderlichen Formate ausgewählt werden. Wenn Sie fertig sind, drücken Sie Enter, um den Bau und die Installation fortzusetzen. In der Voreinstellung wird das Paket oder der Port das mplayer-Kommandozeilenprogramm und das graphische Programm gmplayer bauen. Um Videos zu dekodieren, installieren Sie den Port multimedia/mencoder. Aus lizenzrechtlichen Gründen steht ein Paket von MEncoder nicht zur Verfügung. MPlayer erstellt beim ersten Start ~/.mplayer im Heimatverzeichnis des Benutzers. Dieses Verzeichnis enthält die voreingestellten Konfigurationseinstellungen für den Benutzer. Dieser Abschnitt beschreibt nur ein paar wenige Anwendungsmöglichkeiten. Eine vollständige Beschreibung der zahlreichen Möglichkeiten finden Sie in der Manualpage von mplayer(1). Um die Datei testfile.avi abzuspielen, geben Sie die Video-Schnittstelle mit an: &prompt.user; mplayer -vo xv testfile.avi &prompt.user; mplayer -vo sdl testfile.avi &prompt.user; mplayer -vo x11 testfile.avi &prompt.root; mplayer -vo dga testfile.avi &prompt.root; mplayer -vo 'sdl:dga' testfile.avi Es lohnt sich, alle Option zu testen. Die erzielte Geschwindigkeit hängt von vielen Faktoren ab und variiert beträchtlich je nach eingesetzter Hardware. Wenn Sie eine DVD abspielen wollen, ersetzen Sie testfile.avi durch . N ist die Nummer des Stücks, das Sie abspielen wollen und Gerät gibt den Gerätenamen der DVD an. Das nachstehende Kommando spielt das dritte Stück von /dev/dvd: &prompt.root; mplayer -vo dga -dvd://3 /dev/dvd Das standardmäßig verwendete DVD-Laufwerk kann beim Bau des MPlayer-Ports mit der Option WITH_DVD_DEVICE=/pfad/zum/gerät festgelegt werden. Die Voreinstellung verwendet das Gerät /dev/cd0. Weitere Details finden Sie in Makefile.options des Ports. Die Tastenkombinationen zum Abbrechen, Anhalten und Weiterführen der Wiedergabe entnehmen Sie der Ausgabe von mplayer -h oder der mplayer(1) Manualpage. Weitere nützliche Optionen für die Wiedergabe sind zur Wiedergabe im Vollbild-Modus und zur Steigerung der Geschwindigkeit. Jeder Benutzer kann häufig verwendete Optionen in seine ~/.mplayer/config eintragen: vo=xv fs=yes zoom=yes mplayer kann verwendet werden, um DVD-Stücke in .vob-Dateien zu rippen. Das zweite Stück einer DVD wandeln Sie wie folgt in eine Datei um: &prompt.root; mplayer -dumpstream -dumpfile out.vob -dvd://2 /dev/dvd Die Ausgabedatei out.vob wird im MPEG-Format abgespeichert. Jeder Benutzer, der mehr Informationen über Video unter &unix; sammeln möchte, sollte mplayerhq.hu/DOCS konsultieren, da es technisch sehr informativ ist. Diese Dokumentation sollte ebenfalls studiert werden, bevor Fehlerberichte eingereicht werden. mencoder Vor der Verwendung von mencoder ist es hilfreich, sich mit den auf mplayerhq.hu/DOCS/HTML/en/mencoder.html beschriebenen Optionen vertraut zu machen. Es gibt unzählige Möglichkeiten die Qualität zu verbessern, die Bitrate zu verringern und Formate zu konvertieren. Einige davon haben erhebliche Auswirkungen auf die Geschwindigkeit. Falsche Kombinationen von Kommandozeilenparametern ergeben eventuell Dateien, die selbst mplayer nicht mehr wiedergeben kann. Hier ist ein Beispiel für eine einfache Kopie: &prompt.user; mencoder input.avi -oac copy -ovc copy -o output.avi Wenn Sie in eine Datei rippen, benutzen Sie die Option von mplayer. Um input.avi nach MPEG4 mit MPEG3 für den Ton zu konvertieren, muss zunächst der Port audio/lame installiert werden. Aus lizenzrechtlichen Gründen ist ein Paket nicht verfügbar. Wenn der Port installiert ist, geben Sie ein: &prompt.user; mencoder input.avi -oac mp3lame -lameopts br=192 \ -ovc lavc -lavcopts vcodec=mpeg4:vhq -o output.avi Die Ausgabedatei lässt sich mit Anwendungen wie mplayer oder xine abspielen. input.avi kann durch ersetzt und das Kommando als root ausgeführt werden, um ein DVD-Stück direkt zu konvertieren. Da vielleicht ein paar Versuche nötig sind, um das gewünschte Ergebnis zu erhalten, empfiehlt es sich das Stück zuerst in eine Datei zu schreiben und anschließend die Datei weiter zu bearbeiten. Der Video-Spieler <application>xine</application> xine ist ein Video-Spieler mit einer wiederverwendbaren Bibliothek und ein Programm, das durch Plugins erweitert werden kann. Es kann als Paket oder Port multimedia/xine installiert werden. Für einen reibungslosen Betrieb benötigt xine entweder eine schnelle CPU mit einer schnellen Grafikkarte, oder die XVideo-Erweiterung. Am schnellsten läuft xine mit der XVideo-Erweiterung. In der Voreinstellung startet xine eine grafische Benutzeroberfläche. Über die Menüs können dann bestimmte Dateien geöffnet werden. Alternativ kann xine auch über die Kommandozeile aufgerufen werden, um Dateien direkt wiederzugeben: &prompt.user; xine -g -p mymovie.avi Weitere Informationen und Tipps zur Fehlerbehebung finden Sie unter xine-project.org/faq. Die <application>Transcode</application>-Werkzeuge Transcode ist eine Sammlung von Werkzeugen zur Umwandlung von Video- und Audio-Dateien. Transcode mischt Video-Dateien und kann kaputte Video-Dateien reparieren. Die Werkzeuge werden als Filter verwendet, das heißt die Ein- und Ausgaben verwenden stdin/stdout. Unter &os; kann Transcode als Paket oder Port multimedia/transcode installiert werden. Viele Benutzer bevorzugen es den Port zu bauen, da er ein Menü bereitstellt, wo die entsprechenden Formate für den Bau ausgewählt werden können. Mit den Pfeiltasten und der Leertaste können die erforderlichen Formate ausgewählt werden. Wenn Sie fertig sind, drücken Sie Enter, um den Bau und die Installation fortzusetzen. Dieses Beispiel zeigt, wie eine DivX-Datei in eine PAL MPEG-1-Datei konvertiert wird: &prompt.user; transcode -i input.avi -V --export_prof vcd-pal -o output_vcd &prompt.user; mplex -f 1 -o output_vcd.mpg output_vcd.m1v output_vcd.mpa Die daraus resultierende MPEG-Datei, output_vcd.mpg, kann beispielsweise mit MPlayer abgespielt werden. Die Datei kann auch mit einem Programm wie multimedia/vcdimager oder sysutils/cdrdao als Video-CD auf eine CD-R gebrannt werden. Zusätzlich zu der Manualpage von transcode, sollten Sie auch die Informationen und Beispiele im transcoding.org/cgi-bin/transcode lesen. TV-Karten Josef El-Rayes Beigetragen von Marc Fonvieille Überarbeitet von TV-Karten Mit TV-Karten können Sie mit dem Rechner über Kabel oder Antenne fernsehen. Die meisten Karten besitzen einen RCA- oder S-Video-Eingang. Einige Karten haben auch einen FM-Radio-Empfänger. Der &man.bktr.4;-Treiber von &os; unterstützt PCI-TV-Karten mit einem Brooktree Bt848/849/878/879 Chip. Dieser Teiber unterstützt die meisten Pinnacle PCTV Karten. Die Karte sollte einen der unterstützten Empfänger besitzen, die in &man.bktr.4; aufgeführt sind. Den Treiber laden Um die Karte benutzen zu können, muss der &man.bktr.4;-Treiber geladen werden. Damit dies beim Systemstart automatisch erfolgt, muss die folgende Zeile in /boot/loader.conf hinzugefügt werden: bktr_load="YES" Alternativ kann der Treiber für die TV-Karte auch fest in den Kernel kompiliert werden. In diesem Fall müssen folgende Zeilen in die Kernelkonfigurationsdatei aufgenommen werden: device bktr device iicbus device iicbb device smbus Die zusätzlichen Treiber werden benötigt, da die Komponenten der Karte über einen I2C-Bus verbunden sind. Bauen und installieren Sie dann den neuen Kernel. Um den Treiber zu testen, muss das System neu gestartet werden. Während des Neustarts sollte die TV-Karte erkannt werden: bktr0: <BrookTree 848A> mem 0xd7000000-0xd7000fff irq 10 at device 10.0 on pci0 iicbb0: <I2C bit-banging driver> on bti2c0 iicbus0: <Philips I2C bus> on iicbb0 master-only iicbus1: <Philips I2C bus> on iicbb0 master-only smbus0: <System Management Bus> on bti2c0 bktr0: Pinnacle/Miro TV, Philips SECAM tuner. Abhängig von der verwendeten Hardware können die Meldungen natürlich anders aussehen. Die entdeckten Geräte lassen sich mit &man.sysctl.8; oder in der Kernelkonfigurationsdatei überschreiben. Wenn Sie beispielsweise einen Philips-SECAM-Empfänger erzwingen wollen, fügen Sie die folgende Zeile zur Kernelkonfigurationsdatei hinzu: options OVERRIDE_TUNER=6 Alternativ können Sie &man.sysctl.8; benutzen: &prompt.root; sysctl hw.bt848.tuner=6 Weitere Informationen zu den verschiedenen Kerneloptionen und &man.sysctl.8;-Parametern finden Sie in &man.bktr.4;. Nützliche Anwendungen Um die TV-Karte zu benutzen, installieren Sie eine der nachstehenden Anwendungen: multimedia/fxtv lässt das Fernsehprogramm in einem Fenster laufen und kann Bilder, Audio und Video aufzeichnen. multimedia/xawtv eine weitere TV-Anwendung mit vergleichbaren Funktionen. Mit audio/xmradio lässt sich der FM-Radio-Empfänger, der sich auf TV-Karten befindet, benutzen. Weitere Anwendungen finden Sie in der &os; Ports-Sammlung. Fehlersuche Wenn Sie Probleme mit der TV-Karte haben, prüfen Sie zuerst, ob der Video-Capture-Chip und der Empfänger vom &man.bktr.4;-Treiber unterstützt werden und ob Sie die richtigen Optionen verwenden. Weitere Hilfe zu unterstützten TV-Karten finden Sie auf der Mailingliste &a.multimedia.name;. MythTV MythTV ist eine beliebte Open Source PVR-Anwendung. Dieser Abschnitt beschreibt die Installation und Konfiguration von MythTV unter &os;. Weitere Informationen zur Benutzung von MythTV finden Sie unter mythtv.org/wiki. MythTV benötigt ein Frontend und ein Backend. Diese Komponenten können entweder auf dem gleichen System, oder auf unterschiedlichen Maschinen installiert werden. Das Frontend kann unter &os; über den Port oder das Paket multimedia/mythtv-frontend installiert werden. Zudem muss &xorg;, wie in beschrieben, installiert und konfiguriert sein. Idealerweise besitzt das System auch eine Videokarte, die X-Video Motion Compensation (XvMC) unterstützt, sowie optional eine LIRC-kompatible Fernbedienung. Benutzen Sie multimedia/mythtv, um sowohl das Frontend als auch das Backend zu installieren. Ein &mysql; Datenbank-Server ist ebenfalls erforderlich und sollte automatisch als Abhängigkeit installiert werden. Optional sollte das System einen Empfänger und ausreichend Speicherplatz haben, um die aufgezeichneten Daten speichern zu können. Hardware MythTV verwendet V4L um auf Videoeingabegeräte, wie Kodierer und Empfänger zuzugreifen. Unter &os; funktioniert MythTV am besten mit USB DVB-S/C/T Karten, die von multimedia/webcamd unterstützt werden, da dies eine V4L-Anwendung zur Verfügung stellt, die als Benutzerprogramm läuft. Jede DVB-Karte, die von webcamd unterstützt wird, sollte mit MythTV funktionieren, jedoch gibt es eine Liste von Karten, die unter + xlink:href="https://wiki.freebsd.org/WebcamCompat"> wiki.freebsd.org/WebcamCompat abgerufen werden kann. Es existieren auch Treiber für Hauppauge-Karten in den folgenden Paketen: multimedia/pvr250 und multimedia/pvrxxx, allerdings liefern diese nur eine Treiberschnittstelle, die nicht dem Standard entspricht und die nicht mit MythTV-Versionen grösser als 0.23 funktionieren. Aus lizenzrechtlichen Gründen ist ein Paket nicht verfügbar, sodass die beiden Ports übersetzt werden müssen. - Die + Die wiki.freebsd.org/HTPC enthält eine Liste von allen verfügbaren DVB-Treibern. MythTV Backend einrichten Geben Sie folgendes ein, um MythTV als Binärpaket zu installieren: &prompt.root; pkg install mythtv Alternativ können Sie den Port installieren: &prompt.root; cd /usr/ports/multimedia/mythtv &prompt.root; make install Richten Sie anschließend die MythTV-Datenbank ein: &prompt.root; mysql -uroot -p < /usr/local/share/mythtv/database/mc.sql Konfigurieren Sie dann das Backend: &prompt.root; mythtv-setup Zum Schluss starten Sie das Backend: &prompt.root; echo 'mythbackend_enable="YES"' >> /etc/rc.conf &prompt.root; service mythbackend start Scanner Marc Fonvieille Beigetragen von Scanner Unter &os; stellt SANE (Scanner Access Now Easy) aus der Ports-Sammlung eine einheitliche Schnittstelle (API) für den Zugriff auf Scanner bereit. SANE wiederum greift auf Scanner mithilfe einiger &os;-Treiber zu. &os; unterstützt sowohl SCSI- als auch USB-Scanner. Abhängig von der Schnittstelle des Scanners, werden unterschiedliche Treiber benötigt. Prüfen Sie vor der Konfiguration mithilfe der Liste der unterstützten Geräte ob der Scanner von SANE unterstützt wird. Dieses Kapitel beschreibt, wie Sie feststellen können, ob der Scanner von &os; erkannt wurde. Zudem enthält es einen Überblick über die Konfiguration und Verwendung von SANE unter &os;. Den Scanner überprüfen Im GENERIC-Kernel sind schon alle, für einen USB-Scanner notwendigen Treiber enthalten. Benutzer mit einem angepassten Kernel sollten sicherstellen, dass die Kernelkonfiguration die nachstehenden Zeilen enthält: device usb device uhci device ohci device ehci Um zu überprüfen ob der Scanner erkannt wird, schließen Sie den USB-Scanner an. Prüfen Sie dann mit &man.dmesg.8;, ob der Scanner in den Systemmeldungen erscheint: ugen0.2: <EPSON> at usbus0 In diesem Beispiel wurde ein &epson.perfection; 1650 USB-Scanner an /dev/ugen0.2 erkannt. Wenn der Scanner eine SCSI-Schnittstelle besitzt, ist die Kernelkonfiguration abhängig vom verwendeten SCSI-Controller. Der GENERIC-Kernel unterstützt die gebräuchlichen SCSI-Controller. Den richtigen Treiber finden Sie in /usr/src/sys/conf/NOTES. Neben dem SCSI-Treiber muss die Kernelkonfiguration noch die nachstehenden Zeilen enthalten: device scbus device pass Nachdem Sie einen Kernel gebaut und installiert haben, sollte der Scanner beim Neustart in den Systemmeldungen erscheinen: pass2 at aic0 bus 0 target 2 lun 0 pass2: <AGFA SNAPSCAN 600 1.10> Fixed Scanner SCSI-2 device pass2: 3.300MB/s transfers Wenn der Scanner während des Systemstarts ausgeschaltet war, können Sie die Geräteerkennung erzwingen, indem Sie den SCSI-Bus erneut absuchen. Verwenden Sie dazu camcontrol: &prompt.root; camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful Der Scanner sollte jetzt in der SCSI-Geräteliste erscheinen: &prompt.root; camcontrol devlist <IBM DDRS-34560 S97B> at scbus0 target 5 lun 0 (pass0,da0) <IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1) <AGFA SNAPSCAN 600 1.10> at scbus1 target 2 lun 0 (pass3) <PHILIPS CDD3610 CD-R/RW 1.00> at scbus2 target 0 lun 0 (pass2,cd0) Weitere Informationen über SCSI-Geräte unter &os; finden Sie in &man.scsi.4; und &man.camcontrol.8;. <application>SANE</application> konfigurieren SANE besteht aus zwei Teilen, den Backends (graphics/sane-backends) und den Frontends (graphics/sane-frontends oder graphics/xsane). Das Backend greift auf den Scanner zu. Lesen Sie http://www.sane-project.org/sane-supported-devices.html um herauszufinden, welches Backend welchen Scanner unterstützt. Die Frontends sind die Anwendungen, mit denen gescannt wird. graphics/sane-frontends installiert xscanimage, während graphics/xsane xsane installiert. Installieren Sie die beiden Komponenten als Paket: &prompt.root; pkg install xsane sane-frontends Alternativ können Sie die Komponenten aus der Ports-Sammlung installieren: &prompt.root; cd /usr/ports/graphics/sane-frontends &prompt.root; make install clean &prompt.root; cd /usr/ports/graphics/xsane &prompt.root; make install clean Nachdem Sie den Port oder das Paket graphics/sane-backends installiert haben, können Sie mit dem Befehl sane-find-scanner prüfen, ob SANE den Scanner erkennt: &prompt.root; sane-find-scanner -q found SCSI scanner "AGFA SNAPSCAN 600 1.10" at /dev/pass3 Die Ausgabe zeigt die Schnittstelle und die verwendete Gerätedatei des Scanners. Der Hersteller und das Modell können in der Ausgabe fehlen. Bei einigen USB-Scannern muss die Firmware geladen werden. Lesen Sie sane-find-scanner(1) und sane(7) für weitere Details. Als nächstes müssen Sie prüfen, ob der Scanner vom Frontend erkannt wird. Die SANE-Backends werden mit dem Kommandozeilenwerkzeug scanimage geliefert. Mit diesem Werkzeug können Sie sich Scanner anzeigen lassen und den Scan-Prozess von der Kommandozeile starten. Die Option zeigt die Scanner an. Das erste Beispiel ist für einen SCSI-Scanner, das zweite ist für einen USB-Scanner: &prompt.root; scanimage -L device `snapscan:/dev/pass3' is a AGFA SNAPSCAN 600 flatbed scanner &prompt.root; scanimage -L device 'epson2:libusb:/dev/usb:/dev/ugen0.2' is a Epson GT-8200 flatbed scanner Die Zeile 'epson2:libusb:/dev/usb:/dev/ugen0.2' im zweiten Beispiel nennt das Backend (epson2) und die Gerätedatei (/dev/ugen0.2), die der Scanner verwendet. Wenn scanimage den Scanner nicht erkennen kann, erscheint folgende Meldung: &prompt.root; scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Wenn das passiert, müssen Sie in der Konfigurationsdatei des Backends unterhalb von /usr/local/etc/sane.d/ den verwendeten Scanner eintragen. Wenn der Scanner &epson.perfection; 1650, der das Backend epson2 benutzt, nicht erkannt wurde, muss /usr/local/etc/sane.d/epson2.conf angepasst werden. Fügen Sie eine Zeile mit der Schnittstelle und dem Gerätenamen in die Datei ein. In diesem Beispiel wurde die nachstehende Zeile eingefügt: usb /dev/ugen0.2 Speichern Sie die Änderungen und prüfen Sie, ob der Scanner mit dem richtigen Backend und Gerätenamen erkannt wird: &prompt.root; scanimage -L device 'epson2:libusb:/dev/usb:/dev/ugen0.2' is a Epson GT-8200 flatbed scanner Wenn scanimage -L den Scanner erkannt hat, ist der Scanner eingerichtet und bereit, zu scannen. Obwohl scanimage von der Kommandozeile scannen kann, ist eine graphische Anwendung zum Scannen besser geeignet. SANE bietet ein einfaches und effizientes Werkzeug: xscanimage. Alternativ ist xsane, das über den Port oder das Paket graphics/xsane installiert wird, eine weitere beliebte graphische Anwendung. Dieses Frontend besitzt erweiterte Funktionen wie den Scan-Modus, eine Farbkorrektur und Batch-Scans. Beide Anwendungen lassen sich als GIMP-Plugin verwenden. Berechtigungen für den Scanner Wenn andere Benutzer den Scanner benutzen sollen, müssen sie Lese- und Schreibrechte auf die Gerätedatei des Scanners besitzen. Im vorherigen Beispiel wird die Datei /dev/ugen0.2 verwendet, die faktisch nur ein Symlink auf die echte Gerätedatei, /dev/usb/0.2.0 genannt, darstellt. Sowohl der Symlink als auch die Gerätedatei sind jeweils im Besitz der Gruppen wheel und operator. Damit ein Benutzer den Scanner benutzen kann, muss er Mitglied in einer der beiden Gruppen sein. Allerdings sollte aus Sicherheitsgründen genau überlegt werden, welche Benutzer zu welcher Gruppe hinzugefügt werden, besonders bei der Gruppe wheel. Eine bessere Lösung ist es, eine spezielle Gruppe für den Zugriff anzulegen und den Scanner für Mitglieder dieser Gruppe zugänglich zu machen. Dieses Beispiel erstellt eine Gruppe namens usb: &prompt.root; pw groupadd usb Anschließend muss der /dev/ugen0.2-Symlink und der Gerätename /dev/usb/0.2.0 für die Gruppe usb mit den Schreibrechten 0660 oder 0664 ausgestattet werden. All dies kann durch das Hinzufügen der folgenden Zeilen in /etc/devfs.rules erreicht werden: [system=5] add path ugen0.2 mode 0660 group usb add path usb/0.2.0 mode 0660 group usb Jetzt müssen nur noch Benutzer zur Gruppe usb hinzugefügt werden, um ihnen den Zugriff auf den Scanner zu erlauben: &prompt.root;pw groupmod usb -m joe Weitere Details finden Sie in &man.pw.8;. Index: head/de_DE.ISO8859-1/books/handbook/ports/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/ports/chapter.xml (revision 51670) +++ head/de_DE.ISO8859-1/books/handbook/ports/chapter.xml (revision 51671) @@ -1,1846 +1,1846 @@ Installieren von Anwendungen: Pakete und Ports Uwe Pierau Übersetzt von Björn Heidotting Überarbeitet von Übersicht Ports Pakete &os; enthält eine umfassende Sammlung von Systemwerkzeugen, die Teil des Basissystems sind. Darüber hinaus stellt &os; zwei sich ergänzende Methoden zur Installation von Drittanbieter-Software zur Verfügung: Die Ports-Sammlung zur Installation aus dem Quellcode sowie Pakete zur Installation von vorkompilierten binären Softwarepaketen. Beide Methoden können benutzt werden, um Anwendungen von lokalen Medien oder über das Netzwerk zu installieren. Dieses Kapitel behandelt die folgenden Themen: Den Unterschied zwischen binären Softwarepaketen und Ports. Wie man Drittanbieter-Software findet, die nach &os; portiert wurde. Wie Binärpakete mit pkg verwaltet werden. Den Bau von Drittanbieter-Software aus dem Quellcode mithilfe der Ports-Sammlung. Wie man die Dateien findet, die zusammen mit der Anwendung installiert wurden. Was zu tun ist, wenn die Installation einer Software fehlschlägt. Installation von Software Die typischen Schritte zur Installation von Drittanbieter-Software auf einem &unix; System sind: Download der Software, die als Quelltext oder im Binärformat vorliegen kann. Auspacken der Software. Dies ist typischerweise ein mit &man.compress.1;, &man.gzip.1;, &man.bzip2.1; oder &man.xz.1; komprimiertes Tar-Archiv. Durchsuchen der Dokumentation, die sich in INSTALL, README oder mehreren Dateien im Verzeichnis doc/ befindet, nach Anweisungen, wie die Software zu installieren ist. Kompilieren der Software, wenn sie als Quelltext vorliegt. Dazu muss vielleicht das Makefile angepasst, oder configure ausgeführt werden. Testen und installieren der Software. Ein &os;-Port ist eine Sammlung von Dateien, die das Kompilieren der Quelltexte einer Anwendung automatisieren. Die Dateien, die ein Port umfasst enthalten alle notwendigen Informationen um die Anwendung herunterzuladen, zu extrahieren, anzupassen und zu installieren. Wenn die Software nicht bereits für &os; angepasst und getestet wurde, muss vielleicht sogar der Quelltext angepasst werden, damit die Software funktioniert. Bislang wurden über &os.numports; Anwendungen von Drittanbietern nach &os; portiert. Falls möglich, werden diese Anwendungen als vorkompilierte Pakete zur Verfügung gestellt. Pakete können mit &os;s Paketverwaltungswerkzeugen manipuliert werden. Pakete und Ports beachten Abhängigkeiten zwischen Anwendungen. Wenn ein Paket oder die Ports-Sammlung benutzt wird, um eine Anwendung zu installieren, dann werden fehlende Bibliotheken zuerst installiert, sofern sie nicht schon vorher installiert waren. Ein &os;-Paket enthält vorkompilierte Kopien aller Befehle für eine Anwendung, sowie zusätzliche Konfigurationsdateien und Dokumentation. Pakete können mit den &man.pkg.8;-Befehlen, wie pkg install, manipuliert werden. Obwohl beide Technologien gleichartig sind, so haben Pakete und Ports jeweils ihre eigenen Stärken. Welche Technologie eingesetzt wird, hängt letzten Endes von den Anforderungen ab, die an eine bestimmte Anwendung gestellt werden. Vorteile von Paketen Das komprimierte Paket einer Anwendung ist normalerweise kleiner als das komprimierte Archiv der Quelltexte. Pakete müssen nicht mehr kompiliert werden. Dies ist ein Vorteil, wenn große Pakete wie Mozilla, KDE oder GNOME auf langsamen Maschinen installiert werden. Wenn Sie Pakete verwenden, brauchen Sie nicht zu verstehen, wie Software unter &os; kompiliert wird. Vorteile von Ports Da die Pakete auf möglichst vielen System laufen sollen, werden Optionen beim Übersetzen zurückhaltend gesetzt. Wird eine Anwendung über die Ports übersetzt, können die Optionen nach eigenen Bedürfnissen angepasst werden. Die Eigenschaften einiger Anwendungen werden über Optionen zum Zeitpunkt des Übersetzens festgelegt. Apache kann zum Beispiel über eine große Auswahl an eingebauten Optionen konfiguriert werden. Für einige Fälle existieren verschiedene Pakete einer Anwendung, die beim Übersetzen unterschiedlich konfiguriert wurden. Für Ghostscript gibt es ein ghostscript-Paket und ein ghostscript-nox11-Paket, die sich durch die Xorg Unterstützung unterscheiden. Das Erstellen von verschiedenen Paketen wird aber schnell unhandlich, wenn eine Anwendung mehr als ein oder zwei Optionen zum Zeitpunkt des Übersetzens besitzt. Die Lizenzbestimmungen mancher Software verbietet ein Verbreiten in binärer Form. Diese Software muss als Quelltext, der durch den Benutzer kompiliert werden muss, ausgeliefert werden. Einige Leute trauen binären Distributionen nicht, oder sie ziehen es vor den Quelltext zu lesen, um diesen nach möglichen Problemen zu durchsuchen. Der Quellcode wird benötigt, um individuelle Anpassungen anzuwenden. Wenn Sie über aktualisierte Ports informiert sein wollen, lesen Sie die Mailinglisten &a.ports; und &a.ports-bugs;. Bevor Sie eine Anwendung installieren, informieren Sie sich auf der Seite + xlink:href="https://vuxml.FreeBSD.org/"> über mögliche Sicherheitsprobleme mit der Anwendung, oder führen Sie pkg audit -F aus, um alle installierten Pakete auf bekannte Sicherheitslücken zu überprüfen. Der Rest dieses Kapitels beschreibt, wie man Software Dritter mit Paketen und Ports unter &os; installiert und verwaltet. Suchen einer Anwendung Die Anzahl der nach &os; portierten Anwendungen steigt ständig. Es gibt einige Wege, um nach Anwendungen zu suchen: Die &os;-Webseite stellt unter https://www.FreeBSD.org/ports/ eine aktuelle und durchsuchbare Liste aller Anwendungen zur Verfügung. Die Ports können nach dem Namen den Anwendung, oder über die Software-Kategorie durchsucht werden. FreshPorts Dan Langille verwaltet FreshPorts.org, das eine umfassende Suchfunktion bietet und Änderungen an den Anwendungen in der Ports-Sammlung verfolgt. Registrierte Benutzer können eine Merkliste erstellen, um automatisch eine E-Mail zu erhalten, sobald ein Port von dieser Liste aktualisiert wurde. SourceForge Wenn Sie bei der Suche nach einer bestimmten Anwendung nicht weiter kommen, versuchen Sie eine Webseite wie SourceForge.net oder GitHub.com. Schauen Sie dann auf der &os;-Webseite nach, ob die Anwendung portiert wurde. pkg search Das Paket Repository nach einer Anwendung durchsuchen: &prompt.root; pkg search subversion git-subversion-1.9.2 java-subversion-1.8.8_2 p5-subversion-1.8.8_2 py27-hgsubversion-1.6 py27-subversion-1.8.8_2 ruby-subversion-1.8.8_2 subversion-1.8.8_2 subversion-book-4515 subversion-static-1.8.8_2 subversion16-1.6.23_4 subversion17-1.7.16_2 Die Paketnamen enthalten jeweils die Versionsnummer. Wenn ein Port von python abhängt, wird auch die Versionsnummer von python ausgegeben, mit der die Anwendung gebaut wurde. Für einige Ports stehen sogar mehrere Versionen zur Verfügung. Im Fall von Subversion gibt es drei verschiedene Versionen, mit unterschiedlichen Optionen. In diesem Fall wird die Version von Subversion statisch gelinkt. Wenn Sie ein Paket installieren, ist es am besten den Ursprung des Ports anzugeben, also den Pfad in der Ports-Sammlung. Wiederholen Sie pkg search mit um den Ursprung der Pakete anzuzeigen: &prompt.root; pkg search -o subversion devel/git-subversion java/java-subversion devel/p5-subversion devel/py-hgsubversion devel/py-subversion devel/ruby-subversion devel/subversion16 devel/subversion17 devel/subversion devel/subversion-book devel/subversion-static Zudem unterstützt pkg search die Suche mit regulären Ausdrücken, nach exakten Treffern, nach der Beschreibung oder nach anderen Feldern in der Repository-Datenbank. Nach der Installation von ports-mgmt/pkg oder ports-mgmt/pkg-devel, finden Sie in &man.pkg-search.8; weitere Details. Wenn die Ports-Sammlung bereits installiert ist, gibt es mehrere Methoden, um die lokale Version dieser Port-Sammlung abzufragen. Verwenden Sie whereis Datei um herauszufinden, in welcher Kategorie ein Port ist, wobei Datei der Name des Programms ist, das installiert werden soll: &prompt.root; whereis lsof lsof: /usr/ports/sysutils/lsof Alternativ kann der &man.echo.1;-Befehl verwendet werden: &prompt.root; echo /usr/ports/*/*lsof* /usr/ports/sysutils/lsof Beachten Sie aber, dass dieser Befehl auch alle Dateien im Verzeichnis /usr/ports/distfiles findet, auf die der angegebene Suchbegriff passt. Ein weiterer Weg nach Software zu suchen besteht darin, die eingebaute Suchfunktion der Ports-Sammlung zu benutzen. Wechseln Sie dazu in das Verzeichnis /usr/ports, und rufen Sie make search name=Anwendungsname auf, wobei Anwendungsname der Name der Software ist. Um zum Beispiel nach lsof zu suchen: &prompt.root; cd /usr/ports &prompt.root; make search name=lsof Port: lsof-4.88.d,8 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Maint: ler@lerctr.org Index: sysutils B-deps: R-deps: Der integrierte Suchmechanismus verwendet eine Datei mit Index-Informationen. Erscheint eine Meldung, dass der INDEX benötigt wird, führen Sie make fetchindex aus, um die aktuelle Index-Datei herunterzuladen. Mit einem vorhandenen INDEX ist make search in der Lage, die gewünschte Suche durchzuführen. Die Path:-Zeile zeigt an, wo der Port zu finden ist. Um weniger Informationen zu erhalten, benutzen Sie die Funktion quicksearch: &prompt.root; cd /usr/ports &prompt.root; make quicksearch name=lsof Port: lsof-4.88.d,8 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Erweiterte Suchen führen Sie mit make search key=Text oder make quicksearch key=Text aus. Damit werden Portnamen, Kommentare, Beschreibungen und Abhängigkeiten nach Text durchsucht. Dies kann sehr nützlich sein, wenn der Name des Programms nicht bekannt ist. Bei der Verwendung von search und quicksearch wird Groß- und Kleinschreibung bei der Suche ignoriert. Die Suche nach LSOF wird dieselben Ergebnisse wie die Suche nach lsof liefern. Benutzen von <application>pkg</application> zur Verwaltung von Binärpaketen pkg ist der Nachfolger für die traditionellen Paketverwaltungswerkzeuge von &os;. Es bietet viele Funktionen, die den Umgang mit Binärpaketen schneller und einfacher machen. Wenn Sie lediglich vorgefertigte Binärpakete von den &os; Spiegeln benutzen möchten, ist pkg für die Verwaltung von Paketen ausreichend. Falls Sie jedoch die Software aus dem Quellcode bauen oder eigene Repositories verwenden, benötigen Sie ein separates Paketverwaltungswerkzeug. pkg ist kein Ersatz für diese Werkzeuge. Während diese Werkzeuge Drittanbieter-Software sowohl aus Binärpaketen als auch aus der Ports-Sammlung installieren können, so installiert pkg ausschließlich Binärpakete. Erste Schritte mit <application>pkg</application> &os; enthält ein Bootstrap-Programm, welches pkg zusammen mit den Manualpages installiert. pkg wurde für &os; Versionen ab 10.X entwickelt. Nicht alle &os; Versionen unterstüzen den folgenden Bootstrap Prozess. Eine aktuelle Liste finden Sie unter - . + . Andernfalls muss pkg aus der Ports-Sammlung oder als Binärpaket installiert werden. Um das Bootstrap Programm zu starten, geben Sie folgendes ein: &prompt.root; /usr/sbin/pkg Sie müssen eine Internetverbindung haben, damit der Bootstrap Prozess funktioniert. Um den Port zu installieren, geben Sie stattdessen folgendes ein: &prompt.root; cd /usr/ports/ports-mgmt/pkg &prompt.root; make &prompt.root; make install clean Bei der Aktualisierung eines bestehenden Systems, welches ursprünglich die alten pkg_* Werkzeuge verwendet hat, muss die Datenbank in das neue Format konvertiert werden, damit die neuen Werkzeuge wissen, welche Pakete bereits installiert sind. Sobald pkg installiert ist, muss die Paketdatenbank mit dem folgenden Befehl vom traditionellen Format in das neue Format konvertiert werden: &prompt.root; pkg2ng Auf neu installieren Systemen, auf denen noch keine Software von Drittanbietern installiert wurde, kann dieser Schritt entfallen. Die Konvertierung ist unwiderruflich. Sobald die Paketdatenbank in das Format von pkg umgewandelt wurde, sollten die traditionellen pkg_* Werkzeuge nicht mehr benutzt werden. Bei der Konvertierung der Paketdatenbank können Fehler ausgegeben werden, wenn die Inhalte auf die neue Version umgewandelt werden. Im Allgemeinen können diese Fehler ignoriert werden. Wenn pkg2ng fertig ist, wird eine Liste von Software ausgegeben, die nicht erfolgreich konvertiert werden konnte. Diese Anwendungen müssen manuell neu installiert werden. Um sicherzustellen, dass die Ports-Sammlung neue Pakete mit pkg und nicht mit den traditionellen Formaten registriert, muss in &os; 10.X und früheren Versionen folgende Zeile in /etc/make.conf hinzugefügt werden: WITH_PKGNG= yes In der Voreinstellung benutzt pkg die Pakete der &os;-Spiegel (das Repository). Wenn Sie ein eigenes Paket-Repository erstellen möchten, lesen Sie Weitere Konfigurationsoptionen für pkg sind in &man.pkg.conf.5; beschrieben. Informationen zur Bedienung von pkg ist in &man.pkg.8; verfügbar. Alternativ kann pkg ohne zusätzliche Argumente aufgerufen werden. Jedes Argument von pkg ist in seiner spezifischen Manualpage dokumentiert. Um beispielsweise die Manualpage von pkg install zu lesen, geben Sie einen der folgenden Befehle ein: &prompt.root; pkg help install &prompt.root; man pkg-install Der Rest dieses Abschnitts beschreibt die typischen Verwaltungsaufgaben für Binärpakete, die mit pkg erledigt werden können. Jedes gezeigte Kommando verfügt über Optionen, um das Verhalten anzupassen. Details und weitere Beispiele finden Sie in den Manualpages der einzelnen Kommandos. Informationen über installierte Pakete anzeigen Informationen über bereits installierte Pakete können mit pkg info angezeigt werden. Dabei wird, wenn keine weiteren Optionen angegeben werden, die Version und die Beschreibung aller Pakete oder eines einzelnen Pakets ausgegeben. Um zu ermitteln welche Version von pkg installiert ist, geben Sie folgendes ein: &prompt.root; pkg info pkg pkg-1.1.4_1 Installation und Deinstallation von Paketen Ein Binärpaket installieren Sie mit dem folgenden Befehl, wobei paketname der Name des zu installierenden Pakets ist: &prompt.root; pkg install paketname Dieser Befehl verwendet Daten aus dem Repository um zu bestimmen, welche Version der Software und welche Abhängigkeiten installiert werden müssen. Um beispielsweise curl zu installieren: &prompt.root; pkg install curl Updating repository catalogue /usr/local/tmp/All/curl-7.31.0_1.txz 100% of 1181 kB 1380 kBps 00m01s /usr/local/tmp/All/ca_root_nss-3.15.1_1.txz 100% of 288 kB 1700 kBps 00m00s Updating repository catalogue The following 2 packages will be installed: Installing ca_root_nss: 3.15.1_1 Installing curl: 7.31.0_1 The installation will require 3 MB more space 0 MB to be downloaded Proceed with installing packages [y/N]: y Checking integrity... done [1/2] Installing ca_root_nss-3.15.1_1... done [2/2] Installing curl-7.31.0_1... done Cleaning up cache files...Done Das neue Paket und jedes weitere Paket, das als Abhängigkeit installiert wurde, ist in der Liste der installierten Pakete zu sehen: &prompt.root; pkg info ca_root_nss-3.15.1_1 The root certificate bundle from the Mozilla Project curl-7.31.0_1 Non-interactive tool to get files from FTP, GOPHER, HTTP(S) servers pkg-1.1.4_6 New generation package manager Wird ein Paket nicht mehr benötigt, kann es mit pkg delete entfernt werden. Zum Beispiel: &prompt.root; pkg delete curl The following packages will be deleted: curl-7.31.0_1 The deletion will free 3 MB Proceed with deleting packages [y/N]: y [1/1] Deleting curl-7.31.0_1... done Installierte Pakete aktualisieren Installierte Pakete können mit diesem Kommando auf die neuesten Versionen aktualisiert werden: &prompt.root; pkg upgrade Dieses Kommando vergleicht und aktualisiert die installierten Versionen der Pakete mit denen im Repository. Installierte Pakete auditieren Regelmäßig werden Sicherheitslücken in Drittanbieter-Software entdeckt. pkg besitzt einen eingebauten Auditing-Mechanismus. Um die auf dem System installierte Software auf Sicherheitslücken zu prüfen, geben Sie folgenden Befehl ein: &prompt.root; pkg audit -F Automatisches Entfernen von nicht mehr benötigten Abhängigkeiten Das Entfernen eines Pakets kann möglicherweise Abhängigkeiten hinterlassen, die nicht mehr benötigt werden. Unnötige Pakete, die als Abhängigkeit von anderen Paketen installiert wurden, können automatisch erfasst und entfernt werden: &prompt.root; pkg autoremove Packages to be removed: ca_root_nss-3.15.1_1 The autoremoval will free 723 kB Proceed with autoremoval of packages [y/N]: y Deinstalling ca_root_nss-3.15.1_1... done Wiederherstellung der Paketdatenbank Im Gegensatz zum alten Paketverwaltungssystem beinhaltet pkg einen eigenen Mechanismus zur Sicherung der Paketdatenbank. Diese Funktionalität ist standardmäßig aktiviert. Um das Skript daran zu hindern, eine Sicherung der Paketdatenbank zu erstellen, muss in &man.periodic.conf.5; daily_backup_pkgdb_enable="NO" gesetzt werden. Um den Inhalt einer früheren Paketdatenbank wiederherzustellen, geben Sie folgendes Kommando ein und ersetzen Sie /path/to/pkg.sql durch den Speicherort der gesicherten Datenbank: &prompt.root; pkg backup -r /path/to/pkg.sql Wenn Sie eine Sicherung wiederherstellen, die von einem periodic Skript erstellt wurde, müssen Sie diese zuerst dekomprimieren. Um eine manuelle Sicherung der pkg Paketdatenbank zu erstellen, führen Sie den folgenden Befehl aus, und ersetzen Sie /path/to/pkg.sql durch einen geeigneten Dateinamen: &prompt.root; pkg backup -d /path/to/pkg.sql Alte Pakete entfernen Standardmäßig speichert pkg Pakete in einem Cache-Verzeichnis, welches in &man.pkg.conf.5; in der Variablen PKG_CACHEDIR definiert wird. Nur Kopien der neusten installierten Pakete werden beibehalten. Ältere Versionen von pkg haben alle Pakete aufbewahrt. Um diese veralteten Pakete zu entfernen, geben Sie folgendes ein: &prompt.root; pkg clean Um alle Pakte aus dem Cache-Verzeichnis zu löschen, geben Sie ein: &prompt.root; pkg clean -a Manipulation der Paket-Metadaten Bei Software aus der &os; Ports-Sammlung kann es vorkommen, dass die Hauptversionsnummer geändert wird. Dafür hat pkg ein eingebautes Kommando, um die Quelle eines Pakets zu aktualisieren. Dies ist nützlich, wenn zum Beispiel lang/php5 zu lang/php53 umbenannt wurde, damit lang/php5 jetzt die Version 5.4 integrieren kann. Um die Quelle des Pakets für das obige Beispiel zu ändern, geben Sie folgendes ein: &prompt.root; pkg set -o lang/php5:lang/php53 Ein weiteres Beispiel: Um lang/ruby18 auf lang/ruby19 zu aktualisieren, geben Sie folgendes ein: &prompt.root; pkg set -o lang/ruby18:lang/ruby19 In diesem letzten Beispiel wird die Quelle der Bibliotheken von libglut von graphics/libglut auf graphics/freeglut geändert: &prompt.root; pkg set -o graphics/libglut:graphics/freeglut Bei einem Wechsel der Paketquelle ist es notwendig, die Pakete neu zu installieren, welche von dem Paket abhängig sind, das seine Paketquelle geändert hat. Um eine Neuinstallation von abhängigen Paketen zu erzwingen, führen Sie folgenden Befehl aus: &prompt.root; pkg install -Rf graphics/freeglut Benutzen der Ports-Sammlung Die Ports-Sammlung ist eine Reihe von Makefiles, Patches und Beschreibungen. Die Dateien für den Bau und die Installation von einzelnen Anwendungen unter &os; werden als Port bezeichnet. In der Voreinstellung wird die Ports-Sammlung im Verzeichnis /usr/ports gespeichert. Bevor eine Anwendung aus den Ports erstellt werden kann, muss zuerst die Ports-Sammlung installiert werden. Wenn dies nicht bereits bei der Installation von &os; geschehen ist, benutzen Sie eine der beiden Methoden um sie zu installieren: Installation mit Portsnap &os;s Basissystem enthält mit Portsnap ein schnelles und benutzerfreundliches Werkzeug zur Installation der Ports-Sammlung und die bevorzugte Wahl für die meisten Benutzer. Dieses Programm stellt eine Verbindung zu einem &os;-Server her, überprüft den gesicherten Schlüssel und lädt eine aktuelle Kopie der Ports-Sammlung herunter. Der Schlüssel wird benötigt, um die Integrität der heruntergeladenen Dateien zu untersuchen. Laden Sie einen komprimierten Snapshot der Ports-Sammlung in /var/db/portsnap: &prompt.root; portsnap fetch Wenn Sie Portsnap das erste Mal verwenden, müssen Sie den Snapshot nach /usr/ports extrahieren: &prompt.root; portsnap extract Nach dem ersten Einsatz von Portsnap, kann /usr/ports wie folgt aktualisiert werden: &prompt.root; portsnap fetch &prompt.root; portsnap update Bei der Verwendung von fetch können die extract oder update Operationen nacheinander ausgeführt werden, etwa so: &prompt.root; portsnap fetch update Installation mit Subversion Wird mehr Kontrolle über die Ports-Sammlung benötigt, oder wenn die lokalen Änderungen beibehalten werden sollen, kann Subversion benutzt werden, um die Ports-Sammlung zu laden. Lesen Sie den Subversion Primer für eine detaillierte Beschreibung von Subversion. Subversion muss installiert sein, bevor die Ports-Sammlung geladen werden kann. Ist eine lokale Kopie der Ports-Sammlung bereits vorhanden, installieren Sie Subversion wie folgt: &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make install clean Wenn keine lokale Kopie der Ports-Sammlung vorhanden ist, oder pkg zur Verwaltung von Paketen benutzt wird, kann Subversion als Paket installiert werden: &prompt.root; pkg install subversion Laden Sie eine Kopie der Ports-Sammlung: &prompt.root; svn checkout https://svn.FreeBSD.org/ports/head /usr/ports Nach dem erstmaligen checkout mit Subversion kann /usr/ports wie folgt aktualisiert werden: &prompt.root; svn update /usr/ports Die Ports-Sammlung enthält eine Reihe von Verzeichnissen, die jeweils eine Softwarekategorie repräsentieren. Jede Kategorie hat für jede einzelne Anwendung ein weiteres Unterverzeichnis. Jedes Unterverzeichnis enthält Dateien, die &os; sagen, wie ein Programm kompiliert und installiert werden muss. Diese Dateien werden auch Port-Gerüst genannt. Jedes Port-Gerüst beinhaltet die folgenden Dateien und Verzeichnisse: Makefile: enthält Anweisungen, die spezifizieren, wie die Anwendung kompiliert wird und wohin die Komponenten installiert werden sollten. distinfo: enthält die Namen und die Prüfsummen der Dateien, die heruntergeladen werden müssen, um den Port zu bauen. files: dieses Verzeichnis enthält Patches, welche das Übersetzen und Installieren der Anwendung unter &os; ermöglichen. Zudem können noch weitere Dateien, die für die Übersetzung des Ports verwendet werden, enthalten sein. pkg-descr: enthält eine ausführlichere Beschreibung der Anwendung. pkg-plist: eine Liste aller Dateien, die durch diesen Port installiert werden. Außerdem sind hier Informationen enthalten, die zum Entfernen des Ports benötigt werden. Einige Ports beinhalten noch pkg-message oder weitere Dateien, die vom Port-System benutzt werden, um spezielle Situationen zu handhaben. Wenn Sie mehr über diese Dateien oder das Port-System erfahren wollen, lesen Sie das &os; Porter's Handbook. Ein Port enthält nicht den eigentlichen Quellcode, der auch als Distfile bekannt ist. Der heruntergeladene Quellcode wird automatisch nach /usr/ports/distfiles extrahiert. Ports installieren Ports installieren Dieser Abschnitt beschreibt die grundlegende Benutzung der Ports-Sammlung, um Software zu installieren oder zu deinstallieren. Eine ausführliche Beschreibung der einzelnen make-Targets finden Sie in &man.ports.7;. Stellen Sie sicher, dass die Ports-Sammlung aktuell ist, bevor Sie einen Port kompilieren. Informieren Sie sich vorher zusätzlich unter über + xlink:href="https://vuxml.FreeBSD.org/"> über mögliche Sicherheitsprobleme des zu installierenden Ports. Alternativ können Sie pkg audit -F ausführen, bevor Sie einen neuen Port installieren. Die täglich laufende Sicherheitsprüfung des Systems aktualisiert ebenfalls die Datenbank und prüft installierte Anwendungen auf vorhandene Sicherheitsprobleme. Weitere Informationen finden Sie in &man.pkg-audit.8; und &man.periodic.8;. Die Benutzung der Ports-Sammlung setzt eine funktionierende Internetverbindung und Superuser-Rechte voraus. Um einen Port zu installieren, wechseln Sie in das Verzeichnis des Ports, den Sie installieren möchten. Geben Sie dann make install am Prompt ein: &prompt.root; cd /usr/ports/sysutils/lsof &prompt.root; make install >> lsof_4.88D.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/. ===> Extracting for lsof-4.88 ... [Ausgabe des Auspackens weggelassen] ... >> Checksum OK for lsof_4.88D.freebsd.tar.gz. ===> Patching for lsof-4.88.d,8 ===> Applying FreeBSD patches for lsof-4.88.d,8 ===> Configuring for lsof-4.88.d,8 ... [configure-Ausgabe weggelassen] ... ===> Building for lsof-4.88.d,8 ... [Ausgabe der Übersetzung weggelassen] ... ===> Installing for lsof-4.88.d,8 ... [Ausgabe der Installation weggelassen] ... ===> Generating temporary packing list ===> Compressing manual pages for lsof-4.57 ===> Registering installation for lsof-4.57 ===> SECURITY NOTE: This port has installed the following binaries which execute with increased privileges. /usr/local/bin/lsof &prompt.root; Da lsof eine Anwendung ist, die mit erhöhten Rechten läuft, wird nach der Installation eine Sicherheitswarnung angezeigt. Sobald die Installation abgeschlossen ist, erscheint wieder der Prompt. Um die Suche nach Kommandos zu beschleunigen, speichern einige Shells eine Liste der verfügbaren Kommandos in den durch die Umgebungsvariable PATH gegebenen Verzeichnissen. Benutzer der tcsh müssen eventuell rehash eintippen, um die neu installierten Kommandos benutzen zu können, ohne den vollständigen Pfad anzugeben. Benutzer der Shell sh müssen stattdessen hash -r eintippen. Weitere Informationen finden Sie in der Dokumentation der jeweiligen Shell. Bei der Installation wird ein Arbeitsverzeichnis erstellt, das alle temporären Dateien enthält, die während des Bauvorgangs benötigt werden. Wenn dieses Verzeichnis nach der Installation entfernt wird, spart dies Plattenplatz und minimiert mögliche Probleme bei der Aktualisierung des Ports auf eine neuere Version: &prompt.root; make clean ===> Cleaning for lsof-4.88.d,8 &prompt.root; Sie können zwei Schritte sparen, wenn Sie bei der Kompilierung des Ports gleich make install clean eingeben. Port Installation anpassen Einige Ports bieten Optionen, mit denen zusätzliche Funktionen oder Sicherheitsoptionen eingestellt werden können. Beispiele dafür sind www/firefox, security/gpgme und mail/sylpheed-claws. Wenn ein Port von anderen Ports abhängig ist und diese über zusätzliche Abhängigkeiten und Optionen verfügen, wird mehrmals ein Menü ausgegeben, wo der Benutzer verschiedene Optionen wählen kann. Um dies zu vermeiden und die Konfiguration in einem Stück zu erledigen, wechseln Sie in das Verzeichnis des Ports und geben Sie make config-recursive ein. Führen Sie danach make install [clean] aus, um den Port zu kompilieren und zu installieren. Bei der Verwendung von config-recursive wird eine Liste von Ports, die konfiguriert werden, vom Target all-depends-list erstellt. Es wird empfohlen, make config-recursive so lange auszuführen, bis alle Optionen der abhängigen Ports definiert sind und keine Optionen und Menüs mehr erscheinen. Damit soll sichergestellt werden, dass alle Optionen konfiguriert wurden. Es gibt diverse Möglichkeiten, dieses Menü nach dem Bau eines Ports erneut aufzurufen, um Optionen zu entfernen, hinzuzufügen oder anzupassen. Sie können beispielsweise mit cd in das Verzeichnis des Ports wechseln und dort make config eingeben. Eine andere Möglichkeit ist make showconfig. Eine weitere Alternative bietet make rmconfig, das alle ursprünglich gewählten Optionen zurücksetzt und es Ihnen dadurch ermöglicht, die Konfiguration erneut zu beginnen. Die eben erwähnten Optionen werden ausführlich in &man.ports.7; beschrieben. Die Ports-Sammlung benutzt zum Herunterladen von Dateien &man.fetch.3;, das diverse Umgebungsvariablen unterstützt. Die Variablen FTP_PASSIVE_MODE, FTP_PROXY und FTP_PASSWORD müssen unter Umständen gesetzt werden, wenn das &os;-System hinter einer Firewall oder einem FTP/HTTP-Proxy arbeitet. Eine vollständige Liste der unterstützten Variablen finden Sie in &man.fetch.1;. Benutzer ohne eine ständige Internet-Verbindung können make fetch im Verzeichnis /usr/ports ausführen, um die benötigten Dateien herunterzuladen. Es ist auch möglich, make fetch nur in einem Teil des Baums, wie /usr/ports/net, aufzurufen. Die Dateien von allen abhängigen Ports werden mit diesem Kommando allerdings nicht heruntergeladen. Wenn Sie diese Dateien ebenfalls herunterladen wollen, benutzen Sie stattdessen make fetch-recursive. In einigen seltenen Fällen ist es erforderlich, die benötigten Dateien von einem anderen Ort als den im Port definierten MASTER_SITES herunterzuladen. Sie können MASTER_SITES mit dem folgenden Kommando überschreiben: &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE= \ ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch Die Variablen WRKDIRPREFIX und PREFIX überschreiben das voreingestellte Bau- und Zielverzeichnis. Zum Beispiel: &prompt.root; make WRKDIRPREFIX=/usr/home/example/ports install Dieses Kommando baut den Port unter /usr/home/example/ports und installiert ihn unter /usr/local. Die Variable PREFIX legt das Installations-Verzeichnis fest: &prompt.root; make PREFIX=/usr/home/example/local install In diesem Beispiel wird der Port unter /usr/ports gebaut und nach /usr/home/example/local installiert. Sie können beide Variablen auch zusammen benutzen: &prompt.root; make WRKDIRPREFIX=../ports PREFIX=../local install Alternativ können diese Variablen auch als Umgebungsvariablen gesetzt werden. In der Manualpage Ihrer Shell finden Sie Anweisungen, wie Umgebungsvariablen gesetzt werden. Entfernen installierter Ports Ports entfernen Installierte Ports können mit pkg delete wieder deinstalliert werden. Beispiele für dieses Kommando finden Sie in &man.pkg-delete.8;. Alternativ kann make deinstall im Verzeichnis des Ports aufgerufen werden: &prompt.root; cd /usr/ports/sysutils/lsof make deinstall ===> Deinstalling for sysutils/lsof ===> Deinstalling Deinstallation has been requested for the following 1 packages: lsof-4.88.d,8 Thee deinstallation will free 229 kB [1/1] Deleting lsof-4.88.d,8... done Es wird empfohlen die Nachrichten zu lesen, die ausgegeben werden, wenn ein Port deinstalliert wird. Wenn der Port noch Anwendungen hat, die von ihm abhängig sind, werdenn diese am Bildschirm angezeigt, aber die Deinstallation wird forgesetzt. In solchen Fällen ist es besser, die Anwendung neu zu installieren, um fehlende Abhängigkeiten zu vermeiden. Ports aktualisieren Ports aktualisieren Im Laufe der Zeit stehen neuere Versionen der Software in der Ports-Sammlung zur Verfügung. In diesem Abschnitt wird beschrieben, wie Sie bestimmen, welche Software aktualisiert werden kann und wie das Upgrade durchzuführen ist. Um festzustellen, ob neuere Versionen der installierten Ports verfügbar sind, stellen Sie sicher, dass die neueste Version der Ports-Sammlung installiert ist. Dies wird in und beschrieben. Führen Sie unter &os; 10 und neueren Versionen, bzw. auf Systemen die bereits mit pkg arbeiten, den folgenden Befehl aus, um eine Liste der installierten Ports zu erhalten für die eine aktuelle Version existiert: &prompt.root; pkg version -l "<" Mit &os; 9.X und älteren Versionen kann stattdessen dieser Befehl verwendet werden: &prompt.root; pkg_version -l "<" Lesen Sie zuerst /usr/ports/UPDATING, bevor Sie einen Port aktualisieren. In dieser Datei werden Probleme und zusätzlich durchzuführende Schritte bei der Aktualisierung einzelner Ports beschrieben. Dazu gehören solche Dinge wie geänderte Dateiformate, verschobene Konfigurationsdateien, aber auch Inkompatibilitäten zu einer Vorgängerversion. Notieren Sie sich alle Anweisungen der Ports, die aktualisiert werden müssen. Folgen Sie den Anweisungen, wenn Sie das Upgrade durchführen. Werkzeuge für die Aktualisierung und Verwaltung von Ports Ports upgrading-tools Die Ports-Sammlung enthält mehrere Werkzeuge, um die eigentliche Aktualisierung durchzuführen. Jedes hat seine Stärken und Schwächen. Historisch gesehen verwenden die meisten Installationen entweder Portmaster oder Portupgrade. Synth ist eine neuere Alternative. Es bleibt dem Systemadministrator überlassen, welches dieser Werkzeuge für ein bestimmtes System am besten geeignet ist. Es wird empfohlen, die Daten zu sichern, bevor Sie eines dieser Werkzeuge verwenden. Ports mit <application>Portmaster</application> aktualisieren portmaster ports-mgmt/portmaster ist ein sehr kleines Werkzeug zum Aktualisieren von Ports. Es wurde entwickelt, um mit den Werkzeugen aus dem &os; Basissystem zu arbeiten, ohne dabei von anderen Ports oder Datenbanken abhängig zu sein. Sie können das Programm aus der Ports-Sammlung installieren: &prompt.root; cd /usr/ports/ports-mgmt/portmaster &prompt.root; make install clean Portmaster teilt Ports in vier Kategorien ein: Root Port: hat keine Abhängigkeiten und andere Ports sind nicht von diesem Port abhängig. Trunk Port: hat keine Abhängigkeiten, aber andere Ports sind von diesem Port abhängig. Branch Port: hat Abhängigkeiten und andere Ports sind von diesem Port abhängig. Leaf Port: hat Abhängigkeiten, aber andere Ports sind nicht von diesem Port abhängig. Um eine Liste der installierten Ports anzuzeigen und nach neueren Versionen zu suchen, verwenden Sie: &prompt.root; portmaster -L ===>>> Root ports (No dependencies, not depended on) ===>>> ispell-3.2.06_18 ===>>> screen-4.0.3 ===>>> New version available: screen-4.0.3_1 ===>>> tcpflow-0.21_1 ===>>> 7 root ports ... ===>>> Branch ports (Have dependencies, are depended on) ===>>> apache22-2.2.3 ===>>> New version available: apache22-2.2.8 ... ===>>> Leaf ports (Have dependencies, not depended on) ===>>> automake-1.9.6_2 ===>>> bash-3.1.17 ===>>> New version available: bash-3.2.33 ... ===>>> 32 leaf ports ===>>> 137 total installed ports ===>>> 83 have new versions available Um alle installierten Ports zu aktualisieren, verwenden Sie folgenden Befehl: &prompt.root; portmaster -a In der Voreinstellung erzeugt Portmaster eine Sicherheitskopie, bevor ein installierter Port gelöscht wird. Ist die Installation der neuen Version erfolgreich, wird dieses Backup wieder gelöscht. Wollen Sie das Backup lieber manuell löschen, verwenden Sie die Option beim Aufruf von Portmaster. Durch die Verwendung von wird Portmaster im interaktiven Modus gestartet und fragt bei jedem zu aktualisierenden Port nach, wie weiter vorgegangen werden soll. Viele weitere Optionen stehen zur Verfügung. Lesen Sie die Manualpage von &man.portmaster.8; für weitere Einzelheiten in Bezug auf ihre Nutzung. Treten während der Aktualisierung Fehler auf, verwenden Sie die Option , um alle Ports zu aktualisieren beziehungsweise neu zu bauen: &prompt.root; portmaster -af Portmaster ist auch in der Lage, neue Ports zu installieren, wobei zuvor alle abhängigen Ports aktualisiert werden. Um diese Funktion zu nutzen, geben Sie den Pfad des Ports in der Ports-Sammlung an: &prompt.root; portmaster shells/bash Weitere Informationen über ports-mgmt/portmaster finden Sie in der Beschreibung pkg-descr. Ports mit Portupgrade aktualisieren portupgrade ports-mgmt/portupgrade ist ein weiteres Werkzeug zur Aktualisierung von Ports. Es installiert eine Reihe von Anwendungen, die für die Verwaltung von Ports verwendet werden können. Das Programm ist jedoch von Ruby abhängig. Um den Port zu installieren, geben Sie ein: &prompt.root; cd /usr/ports/ports-mgmt/portupgrade &prompt.root; make install clean Durchsuchen Sie vor jedem Update die Liste der installierten Ports mit pkgdb -F und beheben Sie alle gefundenen Probleme. Benutzen Sie portupgrade -a, um automatisch alle veralteten Ports auf dem System zu aktualisieren. Verwenden Sie zusätzlich den Schalter , wenn Sie individuell entscheiden wollen, ob ein Port aktualisiert werden soll: &prompt.root; portupgrade -ai Um nur eine spezifische Anwendung zu aktualisieren, verwenden Sie portupgrade Paketname. Es ist wichtig den Schalter zu benutzen, um zuvor alle Ports zu aktualisieren, die von dem gegebenen Anwendung abhängen. &prompt.root; portupgrade -R firefox Um Pakete anstelle von Ports zu installieren, verwenden Sie den Schalter . Mit dieser Option durchsucht Portupgrade die in der Umgebungsvariablen PKG_PATH aufgeführten Verzeichnisse nach Paketen. Sind lokal keine Pakete vorhanden, versucht Portupgrade die Pakete über das Netz herunterzuladen. Gibt es die Pakete weder lokal noch auf entfernten Rechnern, werden die Ports verwendet. Um die Nutzung von Ports gänzlich zu verhindern, benutzen Sie die Option . Portupgrade würde dann abbrechen, falls keine Pakete zur Verfügung stehen. &prompt.root; portupgrade -PP gnome3 Wenn Sie nur die Quelldateien des Ports, oder die Pakete mit herunterladen möchten, ohne die Anwendung zu bauen oder zu installieren, geben Sie den Schalter an. Weitere Informationen zu den verfügbaren Schaltern finden Sie in der Manualpage von &man.portupgrade.1;. Weitere Informationen über ports-mgmt/portupgrade finden Sie in der Beschreibung pkg-descr. Platzbedarf von Ports Ports Plattenplatz Die Nutzung der Ports-Sammlung wird im Laufe der Zeit viel Plattenplatz verschlingen. Nach dem Bau und der Installation eines Ports, wird make clean die temporären Arbeitsverzeichnisse work aufräumen. Portmaster wird dieses Verzeichnis nach der Installation eines Ports automatisch entfernen (es sei denn, die Option wird verwendet). Wenn Portupgrade installiert ist, wird der folgende Befehl alle Arbeitsverzeichnisse der lokalen Ports-Sammlung entfernen: &prompt.root; portsclean -C Zusätzlich werden sich im Laufe der Zeit zahlreiche veraltete Distfiles in /usr/ports/distfiles ansammeln. Mit Portupgrade können alle Distfiles gelöscht werden, die vom keinem Port mehr benötigt werden: &prompt.root; portsclean -D Portupgrade kann alle Distfiles löschen, die von keinem derzeit installierten Port benötigt werden: &prompt.root; portsclean -DD Wenn Portmaster installiert ist, benutzen Sie diesen Befehl: &prompt.root; portmaster --clean-distfiles In der Voreinstellung arbeitet dieses Programm interaktiv und fragt den Benutzer um Bestätigung, bevor ein Distfile gelöscht wird. Zusätzlich zu diesen Kommandos gibt es noch port-mgmt/pkg_cutleaves. Dieses Werkzeug automatisiert die Deinstallation von installierten Ports, die nicht weiter benötigt werden. Pakete mit <application>Poudriere</application> bauen Poudriere ist ein unter der BSD-Lizenz stehendes Werkzeug zum Erstellen und Testen von &os;-Paketen. Dieses Programm nutzt &os; Jails, um die Pakete in einer isolierten Umgebung zu bauen. Diese Jails können verwendet werden, um Pakete für andere Versionen von &os; zu bauen, oder um auf einem &arch.amd64;-System Pakete für i386 zu bauen. Sobald die Pakete gebaut sind, haben sie das gleiche Format wie auf den offiziellen Spiegeln. Die Pakete können dann mit &man.pkg.8; oder anderen Paketverwaltungswerkzeugen benutzt werden. Poudriere wird über das Paket oder den Port ports-mgmt/poudriere installiert. Die Installation beinhaltet eine Beispielkonfiguration in /usr/local/etc/poudriere.conf.sample. Kopieren Sie diese Datei nach /usr/local/etc/poudriere.conf. Bearbeiten Sie dann die kopierte Datei, um die Konfiguration anzupassen. Obwohl ZFS für poudriere nicht zwingend erforderlich ist, so hat die Nutzung doch einige Vorteile. Wird ZFS eingesetzt, muss in /usr/local/etc/poudriere.conf die Variable ZPOOL definiert, und die Variable FREEBSD_HOST auf einen nahe gelegenen Spiegel gesetzt werden. Die Definition von CCACHE_DIR erlaubt die Verwendung von devel/ccache, um die Bauzeit für häufig kompilierten Code verkürzen. Es kann vorteilhaft sein, die poudriere-Datasets in einem separaten Verzeichnis auf /poudriere einzuhängen. Die Werte der anderen Konfigurationsvariablen sind in der Regel angemessen und brauchen nicht geändert werden. Die Anzahl der Kerne im Prozessor wird verwendet um zu bestimmen, wie viele Bauprozesse parallel ausgeführt werden. Stellen Sie ausreichend virtuellen Speicher bereit, entweder in Form von RAM oder als Swap-Speicher. Ist der virtuelle Speicher aufgebraucht, bricht der Bauprozess ab und die Jails stürzen ab, was zu seltsamen Fehlermeldungen führt. Jails und Ports-Sammlung initialisieren Nach der Konfiguration muss poudriere initialisiert werden, damit es eine Jail mit der benötigten Ports-Sammlung startet. Geben Sie mit den Namen der Jail und mit die gewünschte &os;-Version an. Auf &os;/&arch.amd64;-Systemen kann die Architektur mit dem Schalter und i386 oder amd64 gesetzt werden. Der voreingestellte Wert für die Architektur können Sie sich mit uname anzeigen lassen. &prompt.root; poudriere jail -c -j 10amd64 -v 10.0-RELEASE ====>> Creating 10amd64 fs... done ====>> Fetching base.txz for FreeBSD 10.0-RELEASE amd64 /poudriere/jails/10amd64/fromftp/base.txz 100% of 59 MB 1470 kBps 00m42s ====>> Extracting base.txz... done ====>> Fetching src.txz for FreeBSD 10.0-RELEASE amd64 /poudriere/jails/10amd64/fromftp/src.txz 100% of 107 MB 1476 kBps 01m14s ====>> Extracting src.txz... done ====>> Fetching games.txz for FreeBSD 10.0-RELEASE amd64 /poudriere/jails/10amd64/fromftp/games.txz 100% of 865 kB 734 kBps 00m01s ====>> Extracting games.txz... done ====>> Fetching lib32.txz for FreeBSD 10.0-RELEASE amd64 /poudriere/jails/10amd64/fromftp/lib32.txz 100% of 14 MB 1316 kBps 00m12s ====>> Extracting lib32.txz... done ====>> Cleaning up... done ====>> Jail 10amd64 10.0-RELEASE amd64 is ready to be used &prompt.root; poudriere ports -c -p local ====>> Creating local fs... done ====>> Extracting portstree "local"... Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching public key from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Fetching snapshot generated at Tue Feb 11 01:07:15 CET 2014: 94a3431f0ce567f6452ffde4fd3d7d3c6e1da143efec76100% of 69 MB 1246 kBps 00m57s Extracting snapshot... done. Verifying snapshot integrity... done. Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Tue Feb 11 01:07:15 CET 2014 to Tue Feb 11 16:05:20 CET 2014. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 48 patches. (48/48) 100.00% done. done. Applying patches... done. Fetching 1 new ports or files... done. /poudriere/ports/tester/CHANGES /poudriere/ports/tester/COPYRIGHT [...] Building new INDEX files... done. poudriere kann auf einem einzelnen Rechner Ports mit mehreren Konfigurationen bauen, in mehreren Jails und aus unterschiedlichen Ports-Sammlungen. Spezifische Konfigurationen für diese Kombinationen werden Sets genannt. Lesen Sie den Abschnitt CUSTOMIZATION in &man.poudriere.8; für weitere Einzelheiten nach der Installation von port-mgmt/poudriere oder ports-mgmt/poudriere-devel. Die hier gezeigte Konfiguration verwendet eine einzelne Jail-, Port- und Set-spezifische make.conf in /usr/local/etc/poudriere.d. Der verwendete Dateiname in diesem Beispiel wird aus einer Kombination von Jailnamen, Portnamen und Setnamen zusammen gesetzt: 10amd64-local-workstation-make.conf. Die make.conf des Systems und diese neue Datei werden verwendet, um die make.conf für die Jail zu erzeugen. Die zu bauenden Pakete werden in 10amd64-local-workstation-pkglist eingetragen: editors/emacs devel/git ports-mgmt/pkg ... Die Optionen und Abhängigkeiten für die Ports werden wie folgt konfiguriert: &prompt.root; poudriere options -j 10amd64 -p local -z workstation -f 10amd64-local-workstation-pkglist Schließlich werden die Pakete gebaut und ein Paket-Repository erstellt: &prompt.root; poudriere bulk -j 10amd64 -p local -z workstation -f 10amd64-local-workstation-pkglist Während der Ausführung zeigt Ctrlt den aktuellen Status des Baus an. Poudriere speichert zudem Dateien in /poudriere/logs/bulk/jailname. Diese Dateien kann ein Webserver nutzen, um Informationen über den Bau anzuzeigen. Nach der Fertigstellung stehen die Pakete im poudriere Repository für die Installation zur Verfügung. Weitere Informationen zu poudriere finden Sie in &man.poudriere.8; und unter . Konfiguration des pkg-Clients für das Poudriere Repository Obwohl es möglich ist ein eigenes Repository zusammen mit dem offiziellen Repository zu nutzen, ist es manchmal sinnvoll das offizielle Repository zu deaktivieren. Dazu wird eine Konfigurationsdatei erstellt, welche die offizielle Konfigurationsdatei überschreibt. Erzeugen Sie dazu /usr/local/etc/pkg/repos/FreeBSD.conf mit dem folgenden Inhalt: FreeBSD: { enabled: no } Am einfachsten ist es, das poudriere Repository über HTTP zur Verfügung zu stellen. Setzen Sie einen Webserver auf, der die Dateien des Paketverzeichnisses ausliefert, zum Beispiel /usr/local/poudriere/data/packages/10amd64. 10amd64 bezeichnet dabei den Namen des Baus. Wenn die URL des Paket Repositories http://pkg.example.com/10amd64 ist, dann sollte die Konfiguration des Repositories in /usr/local/etc/pkg/repos/custom.conf wie folgt aussehen: custom: { url: "http://pkg.example.com/10amd64", enabled: yes, } Nach der Installation Unabhängig davon, ob die Software aus einem binären Paket oder aus einem Port installiert wird, benötigen die meisten Anwendungen von Drittanbietern ein gewisses Maß an Konfiguration, nachdem sie installiert wurden. Die folgenden Kommandos und Speicherorte helfen Ihnen dabei festzustellen, was mit der Anwendung zusammen installiert wurde. Die meisten Anwendungen installieren mindestens eine Konfigurationsdatei nach /usr/local/etc. Falls die Anwendung viele Konfigurationsdateien enthält, wird ein Unterverzeichnis erstellt um die Dateien zu speichern. Oft werden die Konfigurationsdateien mit einem Suffix wie beispielsweise .sample installiert. Die Konfigurationsdateien sollten überprüft und ggf. bearbeitet werden, um die Anforderungen des Systems zu erfüllen. Um eine Konfigurationsdatei zu bearbeiten, kopieren Sie diese zunächst ohne die Erweiterung .sample. Wenn die Anwendung Dokumentation zur Verfügung stellt, wird diese nach /usr/local/share/doc installiert. Viele Anwendungen installieren auch Manualpages. Diese Dokumentation sollten Sie lesen, bevor Sie fortfahren. Einige Anwendungen laufen als Dienst und müssen vor dem ersten Start in /etc/rc.conf eingetragen werden. Diese Anwendungen installieren meist ein Skript in /usr/local/etc/rc.d. Weitere Informationen finden Sie im . In der Voreinstellung führen Anwendungen weder ihr Startskript bei der Installation aus, noch führen sie ihr Stopskript während der Deinstallation aus. Diese Entscheidung bleibt dem einzelnen Systemadministrator überlassen. Benutzer der &man.csh.1; sollten rehash ausführen, um die neu installierten Programme nutzen zu können. Benutzen Sie pkg info, um die Dateien, Manualpages und Binaries zu ermitteln, die mit der Anwendung installiert wurden. Kaputte Ports Wenn sich ein Port nicht bauen oder installieren lässt, versuchen Sie folgendes: Stellen Sie fest, ob die Datenbank mit den Problemberichten bereits einen Lösungsvorschlag enthält. Ist dies der Fall, kann die vorgeschlagene Lösung getestet werden. Bitten Sie den Betreuer des Ports um Hilfe. Geben Sie dazu make maintainer ein oder lesen Sie das Makefile im Verzeichnis des Ports, um an die E-Mail-Adresse zu kommen. Vergessen Sie nicht die Zeile mit $FreeBSD: aus dem Makefile und die Ausgabe bis zur Fehlermeldung mitzuschicken. Einige Ports werden nicht von einer Einzelperson, sondern von einer Mailingliste betreut. Viele (aber nicht alle) dieser Adressen haben die Form freebsd-NameDerListe@FreeBSD.org. Denken Sie daran, wenn Sie Ihre Fragen formulieren. Dies gilt insbesondere für Ports, die von ports@FreeBSD.org betreut werden. Derartige Ports haben überhaupt keinen Betreuer. Korrekturen und Unterstützung kommen daher nur von Personen, die diese Mailingliste abonniert haben. Gerade in diesem Bereich werden jederzeit zusätzliche freiwillige Helfer benötigt! Erhalten Sie auf Ihre Anfrage keine Antwort, benutzen Sie Bugzilla, um einen Problembericht zu erstellen. Bevor Sie einen solchen Bericht erstellen, lesen Sie den Artikel Writing &os; Problem Reports. Reparieren Sie ihn! Das &os; Porter's Handbook enthält eine detaillierte Beschreibung des Portsystems. Damit sind Sie in der Lage, einen zeitweilig kaputten Port zu reparieren oder einen eigenen Port zu erstellen. Installieren Sie das Paket anstelle des Ports. Anweisungen hierzu finden Sie in . Index: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/security/chapter.xml (revision 51670) +++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml (revision 51671) @@ -1,4452 +1,4452 @@ Sicherheit Tom Rhodes Neu verfasst von Martin Heinen Übersetzt von Sicherheit Übersicht Sicherheit, ob nun physisch oder virtuell, ist ein so breit gefächertes Thema, dass sich eine ganze Industrie darum gebildet hat. Es wurden bereits hunderte Verfahren zur Sicherung von Systemen und Netzwerken verfasst, und als Benutzer von &os; ist es unumgänglich zu verstehen, wie Sie sich gegen Angreifer und Eindringlinge schützen können. In diesem Kapitel werden einige Grundlagen und Techniken diskutiert. Ein &os;-System implementiert Sicherheit in mehreren Schichten, und viele weitere Programme von Drittanbietern können zur Verbesserung der Sicherheit beitragen. Nachdem Sie dieses Kapitel gelesen haben, werden Sie: Grundlegende auf &os; bezogene Sicherheitsaspekte kennen. Die verschiedenen Verschlüsselungsmechanismen von &os; kennen. Wissen, wie Sie ein Einmalpasswörter zur Authentifizierung verwenden. TCP Wrapper für &man.inetd.8; einrichten können. Wissen, wie Sie Kerberos unter &os; einrichten. Wissen, wie Sie IPsec konfigurieren und ein VPN einrichten. Wissen, wie Sie OpenSSH unter &os; konfigurieren und benutzen. Wissen, wie Sie ACLs für Dateisysteme benutzen. pkg anwenden können, um Softwarepakete aus der Ports-Sammlung auf bekannte Sicherheitslücken hin zu überprüfen. Mit &os;-Sicherheitshinweisen umgehen können. Eine Vorstellung davon haben, was Prozessüberwachung (Process Accounting) ist und wie Sie diese Funktion unter &os; aktivieren können. Wissen, wie Sie Login-Klassen oder die Ressourcen-Datenbank benutzen, um die Ressourcen für Benutzer zu steuern. Bevor Sie dieses Kapitel lesen, sollten Sie Grundlegende Konzepte von &os; und dem Internet verstehen. Dieses Buch behandelt weitere Sicherheitsthemen. Beispielsweise werden verbindliche Zugriffskontrollen im und Firewalls im besprochen. Einführung Sicherheit ist die Verantwortung eines jeden Einzelnen. Ein schwacher Einstiegspunkt in einem System kann einem Eindringling Zugriff auf wichtige Informationen verschaffen, was sich verheerend auf das gesamte Netzwerk auswirken kann. Eines der Grundprinzipien der Informationssicherheit sind die Vertraulichkeit, Integrität und Verfügbarkeit von Informationssystemen. Diese Grundprinzipien sind ein fundamentales Konzept der Computer-Sicherheit, da Kunden und Benutzer erwarten, dass ihre Daten geschützt sind. Zum Beispiel erwartet ein Kunde, dass seine Kreditkarteninformationen sicher gespeichert werden (Vertraulichkeit), dass seine Aufträge nicht hinter den Kulissen geändert werden (Integrität) und dass er zu jeder Zeit Zugang zu seinen Informationen hat (Verfügbarkeit). Um diese Grundprinzipien zu implementieren, wenden Sicherheitsexperten das sogenannte Defense-in-Depth-Konzept an. Die Idee dahinter ist, mehrere Sicherheitsschichten zu addieren, so dass nicht die gesamte Systemsicherheit gefährdet ist, wenn eine einzelne Sicherheitsschicht kompromittiert wird. Beispielsweise ist es nicht ausreichend, ein Netzwerk oder ein System nur mit einer Firewall zu sichern. Der Systemadministrator muss auch Benutzerkonten überwachen, die Integrität von Binärdateien prüfen und sicherstellen, dass keine bösartigen Programme installiert sind. Um eine effektive Sicherheitsstrategie zu implementieren, muss man Bedrohungen verstehen und wissen, wie man sich dagegen verteidigen kann. Was ist eine Bedrohung, wenn es um Computer-Sicherheit geht? Bedrohungen beschränken sich nicht nur auf entfernte Angreifer, die sich unerlaubten Zugriff auf ein System verschaffen wollen. Zu den Bedrohungen zählen auch Mitarbeiter, bösartige Software, nicht autorisierte Netzwerkgeräte, Naturkatastrophen, Sicherheitslücken und sogar konkurrierende Unternehmen. Der Zugriff auf Netzwerke und Systeme erfolgt ohne Erlaubnis, manchmal durch Zufall, oder von entfernten Angreifern, und in einigen Fällen durch Industriespionage oder ehemalige Mitarbeiter. Als Anwender müssen Sie vorbereitet sein und auch zugeben, wenn ein Fehler zu einer Sicherheitsverletzung geführt hat. Melden Sie Probleme umgehend dem verantwortlichen Sicherheitspersonal. Als Administrator ist es wichtig, Bedrohungen zu kennen und darauf vorbereitet zu sein, mögliche Schäden zu mildern. Wenn Sicherheit auf Systeme angewendet wird, empfiehlt es sich mit der Sicherung der Benutzerkonten zu beginnen und dann die Netzwerkschicht zu sichern. Dabei ist zu beachten, dass die Sicherheitsrichtlinien des Systems und des Unternehmens eingehalten werden. Viele Unternehmen haben bereits eine Sicherheitsrichtlinie, welche die Konfiguration von technischen Geräten abdeckt. Die Richtlinie sollte die Konfiguration von Arbeitsplatzrechnern, Desktops, mobilen Geräten, Mobiltelefonen, Produktions- und Entwicklungsservern umfassen. In einigen Fällen ist bereits eine Standardvorgehensweise vorhanden. Fragen Sie im Zweifelsfall das Sicherheitspersonal. Der übrige Teil dieser Einführung beschreibt, wie einige grundlegende Sicherheitskonfigurationen auf einem &os;-System durchgeführt werden. Der Rest des Kapitels zeigt einige spezifische Werkzeuge, die verwendet werden können, um eine Sicherheitsrichtlinie auf einem &os;-System zu implementieren. Anmeldungen am System verhindern Ein guter Ausgangspunkt für die Absicherung des Systems ist die Prüfung der Benutzerkonten. Stellen Sie sicher, dass root ein starkes Passwort besitzt und dass dieses Passwort nicht weitergegeben wird. Deaktivieren Sie alle Konten, die keinen Zugang zum System benötigen. Es existieren zwei Methoden, um die Anmeldung über ein Benutzerkonto zu verweigern. Die erste Methode ist, das Konto zu sperren. Dieses Beispiel sperrt das Benutzerkonto toor: &prompt.root; pw lock toor Bei der zweiten Methode wird der Anmeldevorgang verhindert, indem die Shell auf /sbin/nologin gesetzt wird. Nur der Superuser kann die Shell für andere Benutzer ändern: &prompt.root; chsh -s /usr/sbin/nologin toor Die Shell /usr/sbin/nologin verhindert, dass dem Benutzer bei der Anmeldung am System eine Shell zugeordnet wird. Gemeinsame Nutzung von Benutzerkonten In manchen Fällen wird die Systemadministration auf mehrere Benutzer aufgeteilt. &os; bietet zwei Methoden, um solche Situationen zu handhaben. Bei der ersten und nicht empfohlenen Methode wird ein gemeinsames root Passwort der Mitglieder der Gruppe wheel verwendet. Hier gibt der Benutzer su und das Passwort für wheel ein, wenn er die Rechte des Superusers benötigt. Der Benutzer sollte dann nach der Beendigung der administrativen Aufgaben exit eingeben. Um einen Benutzer zu dieser Gruppe hinzuzufügen, bearbeiten Sie /etc/group und fügen Sie den Benutzer an das Ende des Eintrags wheel hinzu. Die Benutzer müssen durch Komma und ohne Leerzeichen getrennt werden. Die zweite und empfohlene Methode ein Benutzerkonto zu teilen wird über den Port oder das Paket security/sudo realisiert. Dieses Programm bietet zusätzliche Prüfungen, bessere Benutzerkontrolle und es kann auch konfiguriert werden, einzelnen Benutzern Zugriff auf bestimme, privilegierte Befehle zu gestatten. Benutzen Sie nach der Installation visudo, um /usr/local/etc/sudoers zu bearbeiten. Dieses Beispiel erstellt eine neue Gruppe webadmin und fügt das Benutzerkonto trhodes dieser Gruppe hinzu. Anschließend wird die Gruppe so konfiguriert, dass es Gruppenmitgliedern gestattet wird apache24 neu zu starten: &prompt.root; pw groupadd webadmin -M trhodes -g 6000 &prompt.root; visudo %webadmin ALL=(ALL) /usr/sbin/service apache24 * Passwort-Hashes Passwörter sind ein notwendiges Übel. Wenn sie verwendet werden müssen, sollten sie sehr komplex sein und dazu sollte eine leistungsfähige Hash-Funktion gewählt werden, um die Version des Passworts zu verschlüsseln, die in der Passwortdatenbank gespeichert wird. &os; unterstützt die Hash-Funktionen DES, MD5, SHA256, SHA512, sowie Blowfish Hash-Funktionen in seiner crypt()-Bibliothek. Das in der Voreinstellung verwendete SHA512 sollte nicht durch eine weniger sichere Hash-Funktion getauscht werden. Es kann jedoch durch den besseren Blowfish-Algorithmus ersetzt werden. Blowfish ist nicht Bestandteil von AES und ist nicht kompatibel mit allen Federal Information Processing Standards (FIPS). Die Verwendung wird in einigen Umgebungen vielleicht nicht gestattet. Um zu bestimmen, welche Hash-Funktion das Passwort eines Benutzers verschlüsselt, kann der Superuser den Hash für den Benutzer in der Passwortdatenbank von &os; nachsehen. Jeder Hash beginnt mit einem Zeichen, mit dem die verwendete Hash-Funktion identifiziert werden kann. Bei DES gibt es allerdings kein führendes Zeichen. MD5 benutzt das Zeichen $. SHA256 und SHA512 verwenden das Zeichen $6$. Blowfish benutzt das Zeichen $2a$. In diesem Beispiel wird das Passwort von dru mit dem Hash-Algorithmus SHA512 verschlüsselt, da der Hash mit $6$ beginnt. Beachten Sie, dass der verschlüsselte Hash und nicht das Passwort selbst, in der Passwortdatenbank gespeichert wird: &prompt.root; grep dru /etc/master.passwd dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh Der Hash-Mechanismus wird in der Login-Klasse des Benutzers festgelegt. In diesem Beispiel wird die voreingestellte Login-Klasse für den Benutzer verwendet. Der Hash-Algorithmus wird mit dieser Zeile in /etc/login.conf gesetzt: :passwd_format=sha512:\ Um den Algorithmus auf Blowfish zu ändern, passen Sie die Zeile wie folgt an: :passwd_format=blf:\ Führen Sie anschließend cap_mkdb /etc/login.conf aus, wie in beschrieben. Beachten Sie, dass vorhandene Passwort-Hashes durch diese Änderung nicht beeinträchtigt werden. Das bedeutet, dass alle Passwörter neu gehasht werden sollten, indem die Benutzer mit passwd ihr Passwort ändern. Für die Anmeldung auf entfernten Rechnern sollte eine Zwei-Faktor-Authentifizierung verwendet werden. Ein Beispiel für eine Zwei-Faktor-Authentifizierung ist etwas, was Sie besitzen (bspw. einen Schlüssel) und etwas, was Sie wissen (bspw. das Passwort für diesen Schlüssel). Da OpenSSH Teil des &os;-Basissystems ist, sollten alle Anmeldungen über das Netzwerk über eine verschlüsselte Verbindung mit einer schlüsselbasierten Authentifizierung stattfinden. Passwörter sollten hier nicht verwendet werden. Weitere Informationen finden Sie in . Kerberos-Benutzer müssen eventuell zusätzliche Änderungen vornehmen, um OpenSSH in Ihrem Netzwerk zu implementieren. Diese Änderungen sind in beschrieben. Durchsetzung einer Passwort-Richtlinie Die Durchsetzung einer starken Passwort-Richtlinie für lokale Benutzerkonten ist ein wesentlicher Aspekt der Systemsicherheit. In &os; kann die Länge, Stärke und Komplexität des Passworts mit den Pluggable Authentication Modules (PAM) implementiert werden. In diesem Abschnitt wird gezeigt, wie Sie die minimale und maximale Passwortlänge und die Durchsetzung von gemischten Zeichen mit dem Modul pam_passwdqc.so konfigurieren. Dieses Modul wird aufgerufen, wenn ein Benutzer sein Passwort ändert. Um dieses Modul zu konfigurieren, müssen Sie als Superuser die Zeile mit pam_passwdqc.so in /etc/pam.d/passwd auskommentieren. Anschließend bearbeiten Sie die Zeile, so dass sie den vorliegenden Passwort-Richtlinien entspricht: password requisite pam_passwdqc.so min=disabled,disabled,disabled,12,10 similar=deny retry=3 enforce=users Dieses Beispiel legt gleich mehrere Anforderungen für neue Passwörter fest. Die Einstellung min kontrolliert die Passwortlänge. Es verfügt über fünf Werte, weil dieses Modul fünf verschiedene Arten von Passwörtern definiert, basierend auf der Komplexität. Die Komplexität wird durch die Art von Zeichen definiert, die in einem Passwort vorhanden sind, wie zum Beispiel Buchstaben, Zahlen und Sonderzeichen. Die verschiedenen Arten von Passwörtern werden in &man.pam.passwdqc.8; beschrieben. In diesem Beispiel sind die ersten drei Arten von Passwörtern deaktiviert, was bedeutet, dass Passwörter, die dieser Komplexitätsstufe entsprechen, nicht akzeptiert werden, unabhängig von der Länge des Passworts. Die 12 legt eine Richtlinie von mindestens zwölf Zeichen fest, wenn das Passwort auch drei Arten von Komplexität aufweist. Die 10 legt eine Richtlinie fest, die auch Passwörter mit mindestens zehn Zeichen zulassen, wenn das Passwort Zeichen mit vier Arten von Komplexität aufweist. Die Einstellung similar verbietet Passwörter, die dem vorherigen Passwort des Benutzers ähnlich sind. Die Einstellung retry bietet dem Benutzer drei Möglichkeiten, ein neues Passwort einzugeben. Sobald diese Datei gespeichert wird, sehen Benutzer bei der Änderung ihres Passworts die folgende Meldung: &prompt.user; passwd Changing local password for trhodes Old Password: You can now choose the new password. A valid password should be a mix of upper and lower case letters, digits and other characters. You can use a 12 character long password with characters from at least 3 of these 4 classes, or a 10 character long password containing characters from all the classes. Characters that form a common pattern are discarded by the check. Alternatively, if noone else can see your terminal now, you can pick this as your password: "trait-useful&knob". Enter new password: Wenn ein Passwort nicht den Richtlinien entspricht, wird es mit einer Warnung abgelehnt und der Benutzer bekommt die Möglichkeit, es erneut zu versuchen, bis die Anzahl an Wiederholungen erreicht ist. Die meisten Passwort-Richtlinien erzwingen, dass Passwörter nach einer bestimmten Anzahl von Tagen ablaufen. Um dieses Limit in &os; zu konfigurieren, setzen Sie es für die Login-Klasse des Benutzers in /etc/login.conf. Die voreingestellte Login-Klasse enthält dazu ein Beispiel: # :passwordtime=90d:\ Um für diese Login-Klasse das Passwort nach 90 Tagen ablaufen zu lassen, entfernen Sie das Kommentarzeichen (#), speichern Sie die Änderungen und führen Sie cap_mkdb /etc/login.conf aus. Um das Passwort für einzelne Benutzer ablaufen zu lassen, geben Sie pw ein Ablaufdatum oder die Anzahl von Tagen, zusammen mit dem Benutzer an: &prompt.root; pw usermod -p 30-apr-2015 -n trhodes Wie zu sehen ist, wird das Ablaufdatum in der Form von Tag, Monat und Jahr angegeben. Weitere Informationen finden Sie in &man.pw.8;. Erkennen von Rootkits Ein Rootkit ist eine nicht autorisierte Software die versucht, Root-Zugriff auf ein System zu erlangen. Einmal installiert, wird diese bösartige Software normalerweise eine Hintertür für den Angreifer installieren. Realistisch betrachtet sollte ein durch ein Rootkit kompromittiertes System nach der Untersuchung von Grund auf neu installiert werden. Es besteht jedoch die enorme Gefahr, dass sogar das Sicherheitspersonal oder Systemingenieure etwas übersehen, was ein Angreifer dort platziert hat. Wird ein Rootkit erkannt, ist dies bereits ein Zeichen dafür, dass das System an einem bestimmten Zeitpunkt kompromittiert wurde. Meist neigen diese Art von Anwendungen dazu, sehr gut versteckt zu sein. Dieser Abschnitt zeigt das Werkzeug security/rkhunter, mit dem Rootkits erkannt werden können. Nach der Installation dieses Ports oder Pakets kann das System mit dem folgenden Kommando überprüft werden. Das Programm generiert eine ganze Menge Informationen und Sie werden diverse Male ENTER drücken müssen: &prompt.root; rkhunter -c Nachdem der Prozess abgeschlossen ist, wird eine Statusmeldung auf dem Bildschirm ausgegeben. Die Meldung enthält die Anzahl der überprüften Dateien, verdächtige Dateien, mögliche Rootkits und weitere Informationen. Während der Überprüfung erscheinen allgemeine Sicherheitswarnungen, zum Beispiel über versteckte Dateien, die Auswahl von OpenSSH-Protokollen und bekannte, anfällige Versionen installierter Anwendungen. Diese können nun direkt, oder nach detaillierter Analyse untersucht werden. Jeder Administrator sollte wissen, was auf den Systemen läuft, für die er verantwortlich ist. Werkzeuge von Drittanbietern, wie rkhunter oder sysutils/lsof, sowie native Befehle wie netstat oder ps, können eine große Menge an Informationen über das System anzeigen. Machen Sie sich Notizen darüber, was normal ist, und fragen Sie nach, wenn Ihnen etwas suspekt erscheint. Eine Beeinträchtigung zu verhindern ist ideal, aber die Erkennung einer Beeinträchtigung ist ein Muss. Überprüfung von Binärdateien Die Überprüfung von System- und Binärdateien ist wichtig, da sie Systemadministratoren Informationen über Systemänderungen zur Verfügung stellt. Eine Software, die das System auf Änderungen überwacht wird Intrustion Detection System (IDS) genannt. &os; bietet native Unterstützung für ein einfaches IDS-System. Obwohl die täglichen Sicherheits-E-Mails den Administrator über Änderungen in Kenntnis setzen, werden diese Informationen lokal gespeichert und es besteht die Möglichkeit, dass ein Angreifer diese Informationen manipulieren kann, um Änderungen am System zu verbergen. Daher ist es empfehlenswert, einen eigenen Satz an Signaturen zu erstellen und diese dann in einem schreibgeschützten Verzeichnis, oder vorzugsweise auf einem USB-Stick oder auf einem entfernten Server zu speichern. Das im Basissystem enthaltene Werkzeug mtree kann verwendet werden, um eine Spezifikation des Inhalts eines Verzeichnisses zu erzeugen. Hierbei wird ein Startwert (Seed) oder eine numerische Konstante benutzt, um die Spezifikation zu erstellen und um sicherzustellen, dass sich die Spezifikation nicht geändert hat. Dadurch kann festgestellt werden, ob eine Datei oder eine Binärdatei verändert wurde. Da ein Angreifer den Seed nicht kennt, ist es ihm fast unmöglich die Prüfsummen von Dateien zu manipulieren. Das folgende Beispiel generiert einen Satz mit SHA256-Prüfsummen für jede Binärdatei unterhalb von /bin und speichert diese Werte in einer versteckten Datei im Heimatverzeichnis von root unter dem Namen /root/.bin_chksum_mtree: &prompt.root; mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > /root/.bin_chksum_mtree &prompt.root; mtree: /bin checksum: 3427012225 3483151339707503 stellt den Seed dar. Diesen Wert sollten Sie sich merken, aber nicht mit anderen Personen teilen. Die Ausgabe von /root/.bin_chksum_mtree sollte ähnlich der folgenden sein: # user: root # machine: dreadnaught # tree: /bin # date: Mon Feb 3 10:19:53 2014 # . /set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none . type=dir mode=0755 nlink=2 size=1024 \ time=1380277977.000000000 \133 nlink=2 size=1170 time=1380277977.000000000 \ cksum=484492447 \ sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a cat size=12096 time=1380277975.000000000 cksum=3909216944 \ sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69 chflags size=8168 time=1380277975.000000000 cksum=3949425175 \ sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3 chio size=18520 time=1380277975.000000000 cksum=2208263309 \ sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964 chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7 Der Report enthält den Rechnernamen, das Datum und die Uhrzeit der Spezifikation, sowie den Namen des Benutzers, der die Spezifikation erstellt hat. Für jede Binärdatei im Verzeichnis gibt es eine Prüfsumme, Größe, Uhrzeit und einen SHA256-Hashwert. Um sicherzustellen, dass die binären Signaturen nicht verändert wurden, vergleichen Sie den Inhalt des aktuellen Verzeichnisses mit der zuvor erstellen Spezifikation. Speichern Sie die Ergebnisse in einer Datei. Dieses Kommando benötigt den Seed, der verwendet wurde um die ursprüngliche Spezifikation zu erstellen: &prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output &prompt.root; mtree: /bin checksum: 3427012225 Dies sollte die gleiche Prüfsumme für /bin produzieren, wie die ursprüngliche Spezifikation. Wenn keine Änderungen an den Binärdateien in diesem Verzeichnis aufgetreten sind, wird die Ausgabedatei /root/.bin_chksum_output leer sein. Um eine Änderung zu simulieren, ändern Sie mit touch das Datum von /bin/cat und führen Sie die Verifikation erneut aus: &prompt.root; touch /bin/cat &prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output &prompt.root; more /root/.bin_chksum_output cat changed modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014 Es wird empfohlen, Spezifikationen für Verzeichnisse zu erstellen, welche Binärdateien, Konfigurationsdateien und sensible Daten enthalten. In der Regel werden Spezifikationen für /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /etc und /usr/local/etc erstellt. Mit security/aide steht ein fortgeschrittenes IDS-System zur Verfügung, aber in den meisten Fällen bietet mtree die Funktionalität, die von Administratoren benötigt wird. Es ist jedoch sehr wichtig den Seed und die Prüfsummen in der Ausgabe vor böswilligen Benutzern verborgen zu halten. Weitere Informationen zu mtree finden Sie in &man.mtree.8;. System-Tuning für Sicherheit Unter &os; können viele Systemfunktionen mit sysctl konfiguriert werden. Dieser Abschnitt behandelt ein paar Sicherheitsmerkmale mit denen Denial of Service (DoS) verhindert werden sollen. Weitere Informationen über die Benutzung von sysctl und wie Werte vorübergehend oder auch permanent geändert werden können, finden Sie in . Jedes Mal wenn eine Einstellung mit sysctl geändert wird, vergrößert sich die Wahrscheinlichkeit eines unerwünschten Schadens, was die Verfügbarkeit des Systems beeinflusst. Alle Änderungen sollten überwacht und wenn möglich, vorher auf einem Testsystem ausprobiert werden, bevor sie auf einem Produktivsystem verwendet werden. In der Voreinstellung startet &os; in der Sicherheitsstufe (Securelevel) -1. Dieser Modus wird unsicherer Modus genannt, da die unveränderlichen Datei-Flags ausgeschaltet werden können und dadurch von allen Geräten gelesen und geschrieben werden kann. Solange die Einstellung nicht über sysctl oder in den Startskripten geändert wird, verbleibt die Sicherheitsstufe auf -1. Die Sicherheitsstufe kann während des Systemstarts erhöht werden. Dazu muss in /etc/rc.conf kern_securelevel_enable auf YES und kern_securelevel auf den gewünschten Wert gesetzt werden. Weitere Informationen zu diesen Einstellungen und den verfügbaren Sicherheitsstufen finden Sie in &man.security.7; und &man.init.8;. Das Erhöhen der Sicherheitsstufe kann zu Problemen mit &xorg; führen. Die Einstellungen net.inet.tcp.blackhole und net.inet.udp.blackhole können benutzt werden, um eingehende SYN-Pakete an geschlossenen Ports zu blockieren, ohne ein RST-Paket als Antwort zu senden. Standardmäßig wird jedoch ein RST-Paket gesendet, um zu zeigen, dass der Port geschlossen ist. Das ändern dieser Voreinstellung bietet einen gewissen Schutz gegen Portscans. Diese Portscans versuchen herauszufinden, welche Anwendungen auf einem System ausgeführt werden. Setzen Sie net.inet.tcp.blackhole auf 2 und net.inet.udp.blackhole auf 1. Weitere Informationen zu diesen Einstellungen finden Sie in &man.blackhole.4;. Die Einstellung net.inet.icmp.drop_redirect hilft dabei, sogenannte Redirect-Angriffe zu verhindern. Ein Redirect-Angriff ist eine Art von DoS, die massenhaft ICMP-Pakete Typ 5 versendet. Da solche Pakete nicht benötigt werden, setzen Sie net.inet.icmp.drop_redirect auf 1 und net.inet.ip.redirect auf 0. Source Routing zur Erfassung und zum Zugriff auf nicht-routbare Adressen im internen Netzwerk. Dies sollte deaktiviert werden, da nicht-routbare Adressen in der Regel nicht absichtlich geroutet werden. Um diese Funktion zu deaktivieren, setzen Sie net.inet.ip.sourceroute und net.inet.accept_sourceroute auf 0. Wenn ein Netzwerkgerät Nachrichten an alle Rechner in einem Subnetz senden muss, wird eine ICMP-Echo-Request Nachricht an die Broadcast-Adresse gesendet. Allerdings gibt es keinen guten Grund für externe Rechner, solche Nachrichten zu verschicken. Um alle externen Broadcast-Anfragen abzulehnen, setzen Sie net.inet.icmp.bmcastecho auf 0. Einige zusätzliche Einstellungen sind in &man.security.7; dokumentiert. Einmalpasswörter Einmalpasswörter Sicherheit Einmalpasswörter In der Voreinstellung unterstützt &os; One-time Passwords in Everything (OPIE). OPIE wurde konzipiert um Replay-Angriffe zu verhindern, bei dem ein Angreifer das Passwort eines Benutzers ausspäht und es benutzt, um Zugriff auf ein System zu erlangen. Da ein Passwort unter OPIE nur einmal benutzt wird, ist ein ausgespähtes Passwort für einen Angreifer nur von geringem Nutzen. OPIE verwendet eine sichere Hash-Funktion und ein Challenge/Response-System, um Passwörter zu verwalten. Die &os;-Implementation verwendet in der Voreinstellung die MD5-Hash-Funktion. OPIE verwendet drei verschiedene Arten von Passwörtern. Das erste ist das normale &unix;- oder Kerberos-Passwort. Das zweite ist das Einmalpasswort, das von opiekey generiert wird. Das dritte Passwort ist das geheime Passwort, das zum Erstellen der Einmalpasswörter verwendet wird. Das geheime Passwort steht in keiner Beziehung zum &unix;-Passwort und beide Passwörter sollten unterschiedlich sein. Es gibt noch zwei weitere Werte, die für OPIE wichtig sind. Der erste ist der Initialwert (engl. seed oder key), der aus zwei Buchstaben und fünf Ziffern besteht. Der zweite Wert ist der Iterationszähler, eine Zahl zwischen 1 und 100. OPIE generiert das Einmalpasswort, indem es den Initialwert und das geheime Passwort aneinander hängt und dann die MD5-Hash-Funktion so oft, wie durch den Iterationszähler gegeben, anwendet. Das Ergebnis wird in sechs englische Wörter umgewandelt, die das Einmalpasswort ergeben. Das Authentifizierungssystem (meistens PAM) merkt sich das zuletzt benutzte Einmalpasswort und der Benutzer ist authentifiziert, wenn die Hash-Funktion des Passworts dem vorigen Passwort entspricht. Da nicht umkehrbare Hash-Funktionen benutzt werden, ist es unmöglich, aus einem bekannten Passwort weitere gültige Einmalpasswörter zu berechnen. Der Iterationszähler wird nach jeder erfolgreichen Anmeldung um eins verringert und stellt so die Synchronisation zwischen Benutzer und Login-Programm sicher. Wenn der Iterationszähler den Wert 1 erreicht, muss OPIE neu initialisiert werden. Es gibt ein paar Programme, die in diesen Prozess einbezogen werden. Ein Einmalpasswort oder eine Liste von Einmalpasswörtern, die von &man.opiekey.1; durch Angabe eines Iterationszählers, eines Initalwertes und einem geheimen Passwort generiert wird. &man.opiepasswd.1; wird benutzt, um Passwörter, Iterationszähler oder Initialwerte zu ändern. &man.opieinfo.1; hingegen gibt den momentanen Iterationszähler und Initialwert eines Benutzers aus, den es aus /etc/opiekeys ermittelt. Dieser Abschnitt beschreibt vier verschiedene Arten von Tätigkeiten. Zuerst wird erläutert, wie Einmalpasswörter über eine gesicherte Verbindung konfiguriert werden. Als nächstes wird erklärt, wie opiepasswd über eine nicht gesicherte Verbindung eingesetzt wird. Als drittes wird beschrieben, wie man sich über eine nicht gesicherte Verbindung anmeldet. Die vierte Tätigkeit beschreibt, wie man eine Reihe von Schlüsseln generiert, die man sich aufschreiben oder ausdrucken kann, um sich von Orten anzumelden, die über keine gesicherten Verbindungen verfügen. <acronym>OPIE</acronym> initialisieren Um OPIE erstmals zu initialisieren, rufen Sie &man.opiepasswd.1; über eine gesicherte Verbindung auf: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED Die Option startet den Konsolen-Modus, der davon ausgeht, dass der Befehl von einem sicherem Ort ausgeführt wird. Dies kann beispielsweise der eigene Rechner sein, oder über eine mit SSH gesicherte Verbindung zum eigenen Rechner. Geben Sie das geheime Passwort ein, wenn Sie danach gefragt werden. Damit werden die Einmalpasswörter generiert. Dieses Passwort sollte schwer zu erraten sein und sich ebenfalls vom Passwort des Bentuzerkontos unterscheiden. Es muss zwischen 10 und 127 Zeichen lang sein. Prägen Sie sich dieses Passwort gut ein! Die Zeile, die mit ID beginnt, enthält den Login-Namen (unfrul), den voreingestellten Iterationszähler (499) und den Initialwert (to4268). Das System erinnert sich an diese Parameter und wird sie bei einem Anmeldeversuch anzeigen. Sie brauchen sich diese Dinge also nicht merken. Die letzte Zeile enthält das generierte Einmalpasswort, das aus den Parametern und dem geheimen Passwort ermittelt wurde. Bei der nächsten Anmeldung muss dann diese Einmalpasswort benutzt werden. Initialisierung über eine nicht gesicherte Verbindung Um Einmalpasswörter über eine nicht gesicherte Verbindung zu initialisieren, oder das geheime Passwort zu ändern, müssen Sie über eine gesicherte Verbindung zu einer Stelle verfügen, an der Sie opiekey ausführen können. Dies kann etwa die Eingabeaufforderung auf einer Maschine sein, der Sie vertrauen. Zudem müssen Sie einen Iterationszähler vorgeben (100 ist ein guter Wert) und einen Initialwert wählen, wobei Sie auch einen zufällig generierten benutzen können. Benutzen Sie &man.opiepasswd.1; über die ungesicherte Verbindung zu der Maschine, die Sie einrichten wollen: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY Drücken Sie Return, um die Vorgabe für den Initialwert zu akzeptieren. Bevor Sie nun das Zugriffspasswort (engl. access password) eingeben, rufen Sie über die gesicherte Verbindung opikey mit denselben Parametern auf: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Gehen Sie zurück zu der nicht gesicherten Verbindung und geben dort das eben generierte Einmalpasswort ein. Erzeugen eines einzelnen Einmalpasswortes Nachdem Sie OPIE eingerichtet haben, werden Sie beim nächsten Anmelden wie folgt begrüßt: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> otp-md5 498 gr4269 ext Password: OPIE besitzt eine nützliche Eigenschaft. Wenn Sie an der Eingabeaufforderung Return drücken, wird die echo-Funktion eingeschaltet, das heißt Sie sehen, was Sie tippen. Dies ist besonders nützlich, wenn Sie ein generiertes Passwort von einem Ausdruck abtippen müssen. MS-DOS Windows MacOS Jetzt müssen Sie das Einmalpasswort generieren, um der Anmeldeaufforderung nachzukommen. Dies muss auf einem gesicherten System geschehen, auf dem Sie &man.opiekey.1; ausführen können. Dieses Programm gibt es auch für &windows;, &macos; und &os;. Es benötigt den Iterationszähler sowie den Initialwert als Parameter, die Sie mittels cut-and-paste direkt von der Login-Aufforderung nehmen können. Auf dem sicheren System: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Sobald das Einmalpasswort generiert wurde, können Sie die Anmeldeprozedur fortsetzen. Erzeugen von mehreren Einmalpasswörtern Manchmal haben Sie keinen Zugriff auf eine sichere Maschine oder eine sichere Verbindung. In diesem Fall können Sie vorher mit &man.opiekey.1; einige Einmalpasswörter generieren. Zum Beispiel: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI Mit fordern Sie fünf Passwörter der Reihe nach an. Der letzte Iterationszähler wird durch gegeben. Beachten Sie bitte, dass die Passwörter in der umgekehrten Reihenfolge, in der sie zu benutzen sind, ausgeben werden. Wirklich paranoide Benutzer können sich jetzt die Passwörter aufschreiben oder ausdrucken. Sie sollten die Passwörter nach Gebrauch durchstreichen. Einschränken der Benutzung von System-Passwörtern OPIE kann die Verwendung von &unix;-Passwörtern abhängig von der IP-Adresse einschränken. Die dazu nötigen Einstellungen werden in /etc/opieaccess vorgenommen, die bei der Installation des Systems automatisch erzeugt wird. Weitere Informationen über diese Datei und Sicherheitshinweise zu ihrer Verwendung finden Sie in &man.opieaccess.5;. opieaccess könnte beispielsweise die folgende Zeile enthalten: permit 192.168.0.0 255.255.0.0 Diese Zeile erlaubt es Benutzern, die sich von einer der angegebenen IP-Adressen anmelden, ihr &unix;-Passwort zu verwenden. Beachten Sie bitte, dass eine IP-Adresse leicht gefälscht werden kann. Findet sich in opieaccess kein passender Eintrag, muss die Anmeldung mit OPIE erfolgen. TCP Wrapper Tom Rhodes Beigetragen von TCP Wrapper TCP Wrapper ist ein rechnerbasiertes Zugriffskontrollsystem, das die Fähigkeiten von erweitert. Beispielsweise können Verbindungen protokolliert, Nachrichten zurückgesandt oder nur interne Verbindungen angenommen werden. Weitere Informationen über TCP Wrapper und dessen Funktionen finden Sie in &man.tcpd.8;. TCP Wrapper sollten nicht als Ersatz für eine ordentlich konfigurierte Firewall angesehen werden. Stattdessen sollten TCP Wrapper in Verbindung mit einer Firewall und anderen Sicherheitsmechanismen eingesetzt werden, um bei der Umsetzung einer Sicherheitsrichtlinie eine weitere Sicherheitsschicht zu bieten. Konfiguration Um TCP Wrapper unter &os; zu aktivieren, fügen Sie die folgenden Zeilen in /etc/rc.conf ein: inetd_enable="YES" inetd_flags="-Ww" Anschließend muss /etc/hosts.allow richtig konfiguriert werden. Im Gegensatz zu anderen Implementierungen der TCP Wrapper wird unter &os; vom Gebrauch der Datei hosts.deny abgeraten. Die Konfiguration sollte sich vollständig in /etc/hosts.allow befinden. In der einfachsten Konfiguration werden Dienste abhängig von den Optionen in /etc/hosts.allow erlaubt oder gesperrt. Unter &os; wird in der Voreinstellung jeder von inetd gestartete Dienst erlaubt. Eine Konfigurationszeile ist wie folgt aufgebaut: Dienst : Adresse : Aktion. Dienst ist der von inetd gestartete Dienst (auch Daemon genannt). Die Adresse ist ein gültiger Rechnername, eine IP-Adresse oder eine IPv6-Adresse in Klammern ([ ]). Der Wert allow im Feld Aktion erlaubt Zugriffe, der Wert deny verbietet Zugriffe. Die Zeilen in hosts.allow werden für jede Verbindung der Reihe nach abgearbeitet. Trifft eine Zeile auf eine Verbindung zu, wird die entsprechende Aktion ausgeführt und die Abarbeitung ist beendet. Um beispielsweise einkommende POP3-Verbindungen für den Dienst mail/qpopper zu erlauben, sollte hosts.allow um die nachstehende Zeile erweitert werden: # This line is required for POP3 connections: qpopper : ALL : allow Jedes Mal, wenn diese Datei bearbeitet wird, muss inetd neu gestartet werden: &prompt.root; service inetd restart Erweiterte Konfiguration TCP Wrapper besitzen weitere Optionen, die bestimmen, wie Verbindungen behandelt werden. In einigen Fällen ist es gut, wenn bestimmten Rechnern oder Diensten eine Nachricht geschickt wird. In anderen Fällen soll vielleicht der Verbindungsaufbau protokolliert oder eine E-Mail an einen Administrator versandt werden. Oder ein Dienst soll nur für das lokale Netz bereitstehen. Dies alles ist mit so genannten Wildcards, Metazeichen und der Ausführung externer Programme möglich. Stellen Sie sich vor, eine Verbindung soll verhindert werden und gleichzeitig soll dem Rechner, der die Verbindung aufgebaut hat, eine Nachricht geschickt werden. Solch eine Aktion ist mit möglich. führt beim Verbindungsaufbau ein Kommando oder ein Skript aus. Ein Beispiel ist in hosts.allow enthalten: # Alle anderen Dienste sind geschützt ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." Für jeden Dienst, der nicht vorher in hosts.allow konfiguriert wurde, wird die Meldung You are not allowed to use daemon name from hostname. zurückgegeben. Dies ist nützlich, wenn die Gegenstelle sofort benachrichtigt werden soll, nachdem die Verbindung getrennt wurde. Der Text der Meldung muss in Anführungszeichen (") stehen. Ein so konfigurierter Server ist anfällig für Denial-of-Service-Angriffe. Ein Angreifer kann die gesperrten Dienste mit Verbindungsanfragen überfluten. Eine weitere Möglichkeit bietet . Wie verbietet die Verbindung und führt externe Kommandos aus. Allerdings sendet dem Rechner keine Rückmeldung. Sehen Sie sich die nachstehende Konfigurationsdatei an: # Verbindungen von example.com sind gesperrt: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny Damit sind Verbindungen von der Domain *.example.com gesperrt. Jeder Verbindungsaufbau wird zudem in /var/log/connections.log protokolliert. Das Protokoll enthält den Rechnernamen, die IP-Adresse und den Dienst, der angesprochen wurde. In diesem Beispiel wurden die Metazeichen %a und %h verwendet. Eine vollständige Liste der Metazeichen finden Sie in &man.hosts.access.5;. Die Wildcard ALL passt auf jeden Dienst, jede Domain oder jede IP-Adresse. Eine andere Wildcard ist PARANOID. Sie passt auf jeden Rechner, dessen IP-Adresse möglicherweise gefälscht ist. Dies ist beispielsweise der Fall, wenn der Verbindungsaufbau von einer IP-Adresse erfolgt, die nicht zu dem übermittelten Rechnernamen passt. In diesem Beispiel werden alle Verbindungsanfragen zu Sendmail abgelehnt, wenn die IP-Adresse nicht zum Rechnernamen passt: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny Die Wildcard PARANOID wird Verbindungen ablehnen, wenn der Client oder der Server eine fehlerhafte DNS-Konfiguration besitzt. Weitere Informationen über Wildcards und deren Funktion finden Sie in &man.hosts.access.5;. Wenn Sie neue Einträge zur Konfiguration hinzufügen, sollten Sie sicherstellen, dass nicht benötigte Einträge in hosts.allow auskommentiert werden. <application>Kerberos</application> Tillman Hodgson Beigetragen von Mark Murray Beruht auf einem Beitrag von Kerberos ist ein Netzwerk-Authentifizierungsprotokoll, das ursprünglich am Massachusetts Institute of Technology (MIT) entwickelt wurde. Es bietet die Möglichkeit zur sicheren Authentifizierung über ein potentiell unsicheres Netzwerk. Das Kerberos-Protokoll benutzt eine starke Kryptographie, um die Identität von Clients und Servern nachweisen zu können. Dabei werden keine unverschlüsselten Daten über das Netzewrk gesendet. Kerberos kann als eine Art Proxy zur Identitätsprüfung, oder als vertrauenswürdiges Authentifizierungssystem betrachtet werden. Kerberos hat nur eine Aufgabe: Die sichere Prüfung der Identität eines Benutzers (Authentifizierung) über das Netzwerk. Das System überprüft weder die Berechtigungen der Benutzer (Autorisierung), noch verfolgt es die durchgeführten Aktionen (Audit). Daher sollte Kerberos zusammen mit anderen Sicherheits-Systemen eingesetzt werden, die diese Funktionen bereitstellen. Die aktuelle Version des Protokolls ist Version 5, die in RFC 4120 beschrieben ist. Es existieren mehrere freie Implementierungen dieses Protokolls für eine Reihe von Betriebssystemen. Das MIT entwickelt auch weiterhin seine Kerberos-Version weiter. Es wird in den vereinigten Staaten als Kryptographie-Produkt eingesetzt und unterlag in der Vergangenheit US-Exportbeschränkungen. In &os; ist MIT-Kerberos als Port oder Paket security/krb5 verfügbar. Die Kerberos-Implementation von Heimdal wurde außerhalb der USA entwickelt und unterliegt daher keinen Export-Beschränkungen. Heimdal-Kerberos ist im Basissystem von &os; enthalten. Mit security/heimdal aus der Ports-Sammlung steht eine weitere Distribution, mit mehr konfigurierbaren Optionen zur Verfügung. Unter Kerberos werden Benutzer und Dienste als Prinzipale bezeichnet, die innerhalb einer administrativen Domäne, dem sogenannten Realm enthalten sind. Ein typisches Benutzer-Prinzipal hätte das Format user@REALM (Realms sind traditionell in Großbuchstaben). Die folgenden Anweisungen beschreiben, wie Sie das mit &os; gelieferte Heimdal-Kerberos einrichten. Die Beschreibung der Kerberos-Installation benutzt folgende Namensräume: Die DNS-Domain (Zone) heißt example.org. Das Kerberos-Realm heißt EXAMPLE.ORG. Benutzen Sie echte Domain-Namen, wenn Sie Kerberos einrichten. Damit vermeiden Sie DNS-Probleme und stellen die Zusammenarbeit mit anderen Kerberos-Realms sicher. Das Heimdal <acronym>KDC</acronym> einrichten Kerberos5 Key Distribution Center Kerberos authentifiziert Benutzer an einer zentralen Stelle: dem Key Distribution Center (KDC). Das KDC verteilt Tickets, mit denen ein Dienst die Identität eines Benutzers feststellen kann. Weil alle Mitglieder eines Kerberos-Realms dem KDC vertrauen, gelten für das KDC erhöhte Sicherheitsanforderungen. Der direkte Zugriff auf das KDC sollte daher eingeschränkt sein. Obwohl der Kerberos-Server wenig Ressourcen benötigt, sollte das KDC wegen der Sicherheitsanforderungen auf einem separaten Rechner installiert werden. Das KDC wird in /etc/rc.conf wie folgt aktiviert: kdc_enable="YES" kadmind_enable="YES" Danach wird /etc/krb5.conf wie folgt bearbeitet: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG Diese Einstellungen setzen voraus, dass der voll qualifizierte Name des KDCs kerberos.example.org ist. Der Rechnername des KDC muss im DNS auflösbar sein. In großen Netzwerken mit einem ordentlich konfigurierten DNS-Server kann die Datei aus dem obigen Beispiel verkürzt werden: [libdefaults] default_realm = EXAMPLE.ORG [domain_realm] .example.org = EXAMPLE.ORG Die Zonendatei von example.org muss dann die folgenden Zeilen enthalten: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG Damit die Clients die Kerberos-Dienste benutzen können, muss sie entweder eine vollständig konfigurierte /etc/krb5.conf enthalten, oder eine minimale Konfiguration und zusätzlich ein richtig konfigurierter DNS-Server. Im nächsten Schritt wird die Kerberos-Datenbank eingerichtet. Die Datenbank enthält die Schlüssel aller Prinzipale und ist mit einem Passwort geschützt. Dieses Passwort brauchen Sie sich nicht merken, da ein davon abgeleiteter Schlüssel in /var/heimdal/m-key gespeichert wird. Es wäre durchaus sinnvoll, ein 45-stelliges Zufallspasswort für diesen Zweck zu benutzten. Um den Schlüssel zu erstellen, rufen Sie kstash auf und geben Sie ein Passwort ein: &prompt.root; kstash Master key: xxxxxxxxxxxxxxxxxxxxxxx Verifying password - Master key: xxxxxxxxxxxxxxxxxxxxxxx Nachdem der Schlüssel erstellt wurde, sollte die Datenbank initialisiert werden. Das Kerberos-Werkzeug &man.kadmin.8; kann die Datenbank mit kadmin -l direkt bearbeiten, ohne dabei den Netzwerkdienst &man.kadmind.8; zu benutzen. An der Eingabeaufforderung von kadmin kann mit init die Datenbank des Realms initialisiert werden: &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: Zuletzt wird mit add das erste Prinzipal erstellt. Benutzen Sie die voreingestellten Optionen. Die Einstellungen können später mit modify verändert werden. An der Eingabeaufforderung von &man.kadmin.8; zeigt ? die verfügbaren Optionen an. kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx Jetzt können die KDC-Dienste mit service kdc start und service kadmind start gestartet werden. Obwohl zu diesem Zeitpunkt noch keine kerberisierten Dienste laufen, kann die Funktion des KDCs schon überprüft werden, indem Sie für den eben angelegten Benutzer ein Ticket anfordern: &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: Überprüfen Sie, ob das Ticket erfolgreich ausgestellt wurde: &prompt.user; klist Credentials cache: FILE: /tmp/krb5cc_1001 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 2013 Aug 28 01:37:58 2013 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG Nachdem der Test abgeschlossen ist, kann das temporäre Ticket zurückgezogen werden: &prompt.user; kdestroy <application>Kerberos</application>-Dienste auf dem Server einrichten Kerberos5 Dienste einrichten Bei der Konfiguration eines Servers für die Kerberos-Authentifizierung muss zuerst sichergestellt werden, dass /etc/krb5.conf richtig konfiguriert ist. Die Datei kann entweder vom KDC kopiert, oder auf dem neuen System generiert werden. Als nächstes muss auf dem Server die /etc/krb5.keytab erzeugt werden. Dies ist der Hauptbestandteil um Dienste zu kerberisieren und entspricht der Erzeugung eines geheimen Schlüssels zwischen dem Dienst und dem KDC. Das Geheimnis ist ein kryptographischer Schlüssel, der in einem keytab> abgelegt wird. Diese Datei enthält den Schlüssel des Servers, mit dem sich der Server und das KDC gegenseitig authentifizieren können. Sie muss in einer sicheren Art und Weise an den Server übertragen werden, da ansonsten die Sicherheit des Servers gefährdet ist, wenn z.B. die Schlüssel öffentlich werden. In der Regel wird die keytab auf einem vertrauenswürdigen Rechner mit kadmin erzeugt und anschließend sicher auf den Server übertragen, beispielsweise mit &man.scp.1;. Wenn die Sicherheitsrichtlinien es erlauben, kann die Datei auch direkt auf dem Server erzeugt werden. Es ist sehr wichtig, dass die keytab auf sichere Weise auf den Server übertragen wird. Wenn der Schlüssel einer anderen Partei bekannt wird, kann sich diese Partei den Benutzern als Server ausgeben! Da der Eintrag für das Host-Prinzipal für die KDC-Datenbank auch mit kadmin erstellt wird, ist es praktisch, kadmin direkt auf dem Server zu benutzen. Natürlich ist auch kadmin ein kerberisierter Dienst: ein Kerberos-Ticket ist erforderlich, um sich gegenüber dem Netzwerkdienst zu authentifizieren und um sicherzustellen, dass der Benutzer, der kadmin ausführt, tatsächlich vorhanden ist. kadmin wird nach dem Passwort fragen, um ein neues Ticket zu generieren. Das Prinzipal, das sich mit dem kadmin-Dienst authentifiziert, muss über die Zugriffskontrollliste kadmin.acl dazu berechtigt sein. Weitere Informationen über Zugriffskontrolllisten finden Sie in den Heimdal-Info-Seiten (info heimdal) im Abschnitt Remote administration. Wenn der Zugriff auf kadmin von entfernten Rechnern verboten ist, kann sich der Administrator entweder über die lokale Konsole oder über &man.ssh.1; mit dem KDC verbinden, um die lokale Administration mit kadmin -l durchzuführen. Nach der Installation von /etc/krb5.conf, können Sie das Kommando add --random-key in kadmin ausführen, um das Host-Prinzipal in die Datenbank zu schreiben. Das Kommando ext extrahiert den Schlüssel des Prinzipals in eine eigene keytab: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Principal expiration time [never]: Password expiration time [never]: Attributes []: kadmin> ext_keytab host/myserver.example.org kadmin> exit Beachten Sie, dass ext_keytab den extrahierten Schlüssel standardmäßig in /etc/krb5.keytab speichert. Das ist gut, wenn das Kommando auf dem kerberisierten Server ausgeführt wird, ansonsten sollte das Argument --keytab pfad/zur/datei benutzt werden, wenn die keytab an einen anderen Ort extrahiert wird: &prompt.root; kadmin kadmin> ext_keytab --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit Anschließend kann die erzeugte keytab sicher mit &man.scp.1; auf Server oder auf einen Wechseldatenträger kopiert werden. Geben Sie auf jeden Fall einen anderen Namen für die keytab an, um unnötige Schlüssel in der keytab des Systems zu vermeiden. Mit Hilfe der Datei krb5.conf kann der Server nun mit dem KDC kommunizieren und seine Identität mithilfe der Datei krb5.keytab nachweisen. Jetzt können die kerberisierten Dienste aktiviert werden. Einer der gebräuchlichsten Dienste ist &man.sshd.8;, der Kerberos über GSS-API unterstützt. Fügen Sie folgende Zeile in /etc/ssh/sshd_config ein: GSSAPIAuthentication yes Nach dieser Änderung muss &man.sshd.8; mit service sshd restart neu gestartet werden, damit die neue Konfiguration wirksam wird. <application>Kerberos</application> auf dem Client einrichten Kerberos5 Clients einrichten Genau wie der Server, benötigt auch der Client eine Konfiguration in /etc/krb5.conf. Kopien Sie die Datei (sicher) vom KDC auf den Client, oder schreiben Sie die Datei bei Bedarf einfach neu. Testen Sie den Client, indem Sie mit kinit Tickets anfordern, mit klist Tickets anzeigen und mit kdestroy Tickets löschen. Kerberos-Anwendungen sollten auch kerberisierte Server ansprechen können. Wenn das nicht funktioniert, Sie aber Tickets anfordern können, hat wahrscheinlich der kerberisierte Server ein Problem und nicht der Client oder das KDC. Im Falle eines kerberisierten &man.ssh.1; ist GSS-API in der Voreinstellung deaktiviert. Testen Sie daher mit ssh -o GSSAPIAuthentication=yes hostname. Wenn Sie die kerberisierten Anwendungen testen, können Sie einen Paket-Sniffer wie tcpdump benutzen, um sicherzustellen, dass keine sensiblen Informationen im Klartext übertragen werden. Es stehen verschiedene Kerberos-Anwendungen zur Verfügung. Die Anwendungen, die SASL benutzen, können dann auch GSS-API benutzen. Viele Arten von Anwendungen können Kerberos zur Authentifizierung verwenden, vom Jabber-Client bis zum IMAP-Client. .k5login .k5users Normalerweise wird ein Kerberos-Prinzipal auf ein lokales Benutzerkonto abgebildet. Manchmal wird aber Zugriff auf ein lokales Benutzerkonto benötigt, zu dem es keinen passenden Kerberos-Prinzipal gibt. Der Prinzipal tillman@EXAMPLE.ORG bräuchte beispielsweise Zugriff auf das Konto webdevelopers. Ebenso könnten andere Prinzipale auf dieses Konto zugreifen wollen. Die Dateien .k5login und .k5users im Heimatverzeichnis eines Benutzers können verwendet werden, um dieses Problem zu lösen. Mit der folgenden .k5login im Heimatverzeichnis des Benutzers webdevelopers haben beide Prinzipale auch ohne das gemeinsame Passwort Zugriff auf das Konto: tillmann@example.org jdoe@example.org Weitere Informationen zu .k5users finden Sie in &man.ksu.1;. Unterschiede zur <acronym>MIT</acronym>-Implementation Der Hauptunterschied zwischen der MIT- und der Heimdal-Implementation ist das Kommando kadmin. Die Befehlssätze des Kommandos (obwohl funktional gleichwertig) und das verwendete Protokoll unterscheiden sich in beiden Varianten. Das KDC lässt sich nur mit dem kadmin Kommando der passenden Kerberos-Variante verwalten. Für dieselbe Funktion können auch die Client-Anwendungen leicht geänderte Kommandozeilenoptionen besitzen. Folgen Sie der Anleitung auf http://web.mit.edu/Kerberos/www/. Achten Sie besonders auf den Suchpfad für Anwendungen. Der MIT-Port wird unter &os; standardmäßig in /usr/local/ installiert. Wenn die Umgebungsvariable PATH zuerst die Systemverzeichnisse enthält, werden die Systemprogramme anstelle der MIT-Programme ausgeführt. Wenn Sie MIT-Kerberos verwenden, sollten Sie außerdem folgende Änderungen an /etc/rc.conf vornehmen: kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_flags="" kerberos5_server_enable="YES" kadmind5_server_enable="YES" Tipps und Fehlersuche Während der Konfiguration und bei der Fehlersuche sollten die folgenden Punkte beachtet werden: Wenn Sie Heimdal- oder MIT-Kerberos benutzen, muss in der Umgebungsvariable PATH der Pfad zu den Kerberos-Programmen vor dem Pfad zu den Programmen des Systems stehen. Wenn die Clients im Realm ihre Uhrzeit nicht synchronisieren, schlägt vielleicht die Authentifizierung fehl. beschreibt, wie Sie mithilfe von NTP die Uhrzeiten synchronisieren. Wenn Sie den Namen eines Rechners ändern, müssen Sie auch den host/-Prinzipal ändern und die keytab aktualisieren. Dies betrifft auch spezielle Einträge wie den HTTP/-Prinzipal für Apaches www/mod_auth_kerb. Alle Rechner in einem Realm müssen vor- und rückwärts aufgelöst werden können. Entweder über DNS, zumindest aber über /etc/hosts. CNAME-Einträge im DNS funktionieren, aber die entsprechenden A- und PTR-Einträge müssen vorhanden und richtig sein. Wenn sich Namen nicht auflösen lassen, ist die Fehlermeldung nicht gerade selbstsprechend: Kerberos5 refuses authentication because Read req failed: Key table entry not found. Einige Betriebssysteme installieren ksu mit falschen Zugriffsrechten; es fehlt das Set-UID-Bit für root. Das hat zur Folge, dass ksu nicht funktioniert. Dies ist ein Fehler in den Zugriffsrechten und kein Fehler des KDCs. Wenn Sie für einen Prinzipal unter MIT-Kerberos Tickets mit einer längeren Gültigkeit als der vorgegebenen zehn Stunden einrichten wollen, müssen Sie zwei Sachen ändern. Benutzen Sie modify_principal am Prompt von &man.kadmin.8;, um die maximale Gültigkeitsdauer für den Prinzipal selbst und den Prinzipal krbtgt zu erhöhen. Das Prinzipal kann dann mit kinit -l ein Ticket mit einer längeren Gültigkeit beantragen. Mit einem Packet-Sniffer können Sie feststellen, dass Sie sofort nach dem Aufruf von kinit eine Antwort vom KDC bekommen – noch bevor Sie überhaupt ein Passwort eingegeben haben! Das ist in Ordnung: Das KDC händigt ein Ticket-Granting-Ticket (TGT) auf Anfrage aus, da es durch einen vom Passwort des Benutzers abgeleiteten Schlüssel geschützt ist. Wenn das Passwort eingegeben wird, wird es nicht zum KDC gesendet, sondern zum Entschlüsseln der Antwort des KDCs benutzt, die kinit schon erhalten hat. Wird die Antwort erfolgreich entschlüsselt, erhält der Benutzer einen Sitzungs-Schlüssel für die künftige verschlüsselte Kommunikation mit dem KDC und das TGT. Das TGT wiederum ist mit dem Schlüssel des KDCs verschlüsselt. Diese Verschlüsselung ist für den Benutzer völlig transparent und erlaubt dem KDC, die Echtheit jedes einzelnen TGT zu prüfen. Host-Prinzipale können Tickets mit längerer Gültigkeit besitzen. Wenn der Prinzipal eines Benutzers über ein Ticket verfügt, das eine Woche gültig ist, das Ticket des Host-Prinzipals aber nur neun Stunden gültig ist, funktioniert der Ticket-Cache nicht wie erwartet. Im Cache befindet sich dann ein abgelaufenes Ticket des Host-Prinzipals. Wenn Sie mit krb5.dict die Verwendung schlechter Passwörter verhindern wollen, wie in &man.kadmin.8; beschrieben, geht das nur mit Prinzipalen, denen eine Passwort-Policy zugewiesen wurde. Das Format von krb5.dict enthält pro Zeile ein Wort. Sie können daher einen symbolischen Link auf /usr/share/dict/words erstellen. Beschränkungen von <application>Kerberos</application> Kerberos5 Beschränkungen Kerberos muss ganzheitlich verwendet werden. Jeder über das Netzwerk angebotene Dienst muss mit Kerberos zusammenarbeiten oder auf anderen Wegen gegen Angriffe aus dem Netzwerk geschützt sein. Andernfalls können Berechtigungen gestohlen und wiederverwendet werden. Es ist beispielsweise nicht sinnvoll, für Remote-Shells Kerberos zu benutzen, dagegen aber POP3-Zugriff auf einem Mail-Server zu erlauben, da POP3 Passwörter im Klartext versendet. Das KDC ist verwundbar und muss daher genauso abgesichert werden, wie die auf ihm befindliche Passwort-Datenbank. Auf dem KDC sollten absolut keine anderen Dienste laufen und der Rechner sollte physikalisch gesichert sein. Die Gefahr ist groß, da Kerberos alle Passwörter mit einem Schlüssel, dem Haupt-Schlüssel, verschlüsselt. Der Haupt-Schlüssel wiederum wird in einer Datei auf dem KDC gespeichert. Ein kompromittierter Haupt-Schlüssel ist nicht ganz so schlimm wie allgemein angenommen. Der Haupt-Schlüssel wird nur zum Verschlüsseln der Passwort-Datenbank und zum Initialisieren des Zufallsgenerators verwendet. Solange der Zugriff auf das KDC abgesichert ist, kann ein Angreifer wenig mit dem Haupt-Schlüssel anfangen. Wenn das KDC nicht zur Verfügung steht, sind auch die Netzwerkdienste nicht benutzbar, da eine Authentifizierung nicht durchgeführt werden kann. Das KDC ist also ein optimales Ziel für einen Denial-of-Service Angriff. Sie können diesem Angriff entgegenwirken, indem Sie einen KDC-Master und einen oder mehrere Slaves verwenden. Der Rückfall auf ein sekundäres KDC mittels PAM-Authentifizierung muss sorgfältig eingerichtet werden. Mit Kerberos können sich Benutzer, Rechner und Dienste gegenseitig authentifizieren. Allerdings existiert kein Mechanismus, der das KDC gegenüber Benutzern, Rechnern oder Diensten authentifiziert. Ein verändertes kinit könnte beispielsweise alle Benutzernamen und Passwörter abfangen. Die von veränderten Programmen ausgehende Gefahr können Sie lindern, indem Sie die Integrität von Dateien mit Werkzeugen wie security/tripwire prüfen. Weiterführende Dokumentation Kerberos5 weiterführende Dokumentation The Kerberos FAQ Designing an Authentication System: a Dialogue in Four Scenes RFC 4120, The Kerberos Network Authentication Service (V5) MIT Kerberos-Seite Heimdal Kerberos-Seite OpenSSL Tom Rhodes Beigetragen von Sicherheit OpenSSL OpenSSL OpenSSL ist eine Open Source Implementierung der SSL und TLS-Protokolle. Es bietet eine verschlüsselte Transportschicht oberhalb der normalen Kommunikationsschicht und kann daher zusammen mit vielen Netzdiensten benutzt werden. Das in &os; integrierte OpenSSL stellt die Protokolle Secure Sockets Layer v2/v3 (SSLv2/SSLv3) und Transport Layer Security v1 (TLSv1) zur Verfügung. Die OpenSSL-Bibliotheken stellen kryptographische Funktionen bereit. Anwendungsbeispiele für OpenSSL sind die verschlüsselte Authentifizierung von E-Mail-Clients oder Web-Transaktionen wie das Bezahlen mit Kreditkarte. Einige Ports, wie www/apache24 und databases/portgresql91-server, haben eine Option für den Bau mit OpenSSL. &os; verfügt über zwei OpenSSL Versionen: eine im Basissystem, die andere aus der Ports-Sammlung. Der Benutzer kann mit Hilfe der folgenden Optionen wählen, welche Version in der Voreinstellung für andere Ports verwendet wird: WITH_OPENSSL_PORT: wenn diese Option gesetzt ist, wird der Port OpenSSL aus dem Port security/openssl verwenden, auch dann, wenn die Version im Basisystem aktueller ist. WITH_OPENSSL_BASE: wenn diese Option gesetzt ist, wird der Port mit OpenSSL aus dem Basissystem übersetzt. OpenSSL wird auch eingesetzt, um Zertifikate für Anwendungen bereitzustellen. Die Zertifikate stellen die Identität einer Firma oder eines Einzelnen sicher. Wenn ein Zertifikat nicht von einer Zertifizierungsstelle (Certificate Authority, CA) gegengezeichnet wurde, erhalten Sie normalerweise eine Warnung. Eine Zertifizierungsstelle ist eine Firma wie VeriSign, die Zertifikate von Personen oder Firmen gegenzeichnet und damit die Korrektheit der Zertifikate bestätigt. Diese Prozedur kostet Geld, ist aber keine Voraussetzung für den Einsatz von Zertifikaten, beruhigt aber sicherheitsbewusste Benutzer. Dieser Abschnitt beschreibt, wie Sie auf einem &os;-System Zertifikate erstellen und benutzen. beschreibt, wie Sie eine CA erstellen um die eigenen Zertifikate zu signieren. Weitere Informationen über SSL finden Sie im kostenlosen OpenSSL Cookbook. Zertifikate erzeugen OpenSSL Zertifikate erzeugen Um ein Zertifikat zu erzeugen, das von einer externen CA signiert werden soll, geben Sie folgenden Befehl und die angeforderten Informationen ein. Diese Informationen werden in das Zertifikat geschrieben. Für Common Name geben Sie den vollqualifizierten Namen des Systems ein, auf dem das Zertifikat später installiert wird. Wenn der Name nicht übereinstimmt, wird die Anwendung, die das Zertifikat überprüft, dem Benuzter eine Warnung anzeigen. Die Überprüfung würde fehlschlagen und das Zertifikat damit unbrauchbar machen. &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.key -sha256 -newkey rsa:2048 Generating a 2048 bit RSA private key ..................+++ .............................................................+++ writing new private key to 'cert.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:Another Name Bei der Erzeugung des Zertifikates können noch weitere Optionen, wie die Gültigkeitsdauer und alternative Verschlüsselungsalgorithmen, angegeben werden. &man.openssl.1; beschreibt die zur Verfügung stehenden Optionen. Das folgende Kommando erstellt zwei Dateien im aktuellen Verzeichnis: Die Anforderung für ein neues Zertifikat wird in req.pem gespeichert. Diese Datei können Sie an eine CA senden, wo die Angaben geprüft werden. Nach erfolgreicher Prüfung wird das Zertifikat signiert und an Sie zurückgesandt. cert.key, enthält den privaten Schlüssel für das Zertifikat und darf auch keine Fall in fremde Hände geraten, da ein Angreifer sonst in der Lage ist, anderen Personen oder Rechnern vorzugaukeln, dass es sich bei ihm um Sie handelt. Wenn Sie keine Signatur einer Zertifizierungsstelle benötigen, können Sie ein selbst signiertes Zertifikat erstellen. Erzeugen Sie dazu zuerst einen RSA-Schlüssel: &prompt.root; openssl genrsa -rand -genkey -out cert.key 2048 0 semi-random bytes loaded Generating RSA private key, 2048 bit long modulus .............................................+++ .................................................................................................................+++ e is 65537 (0x10001) Benutzen Sie diesen Schlüssel, um ein selbst signiertes Zertifikat zu erzeugen. Folgen Sie wieder den Anweisungen am Prompt: &prompt.root; openssl req -new -x509 -days 365 -key cert.key -out cert.crt -sha256 You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (e.g. server FQDN or YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Dieses Kommando erstellt zwei neue Dateien im aktuellen Verzeichnis: Der Schlüssel der Zertifizierungsstelle cert.key und das Zertifikat selbst, cert.crt. Sie sollten in einem Verzeichnis, vorzugsweise unterhalb von /etc/ssl/ abgelegt werden, das nur von root lesbar ist. Die Zugriffsrechte der Dateien können mit chmod auf 0700 gesetzt werden. Zertifikate benutzen Mit einem Zertifikat können beispielsweise die Verbindungen zu Sendmail verschlüsselt werden, um eine Klartext-Authentifizierung zu verhindern. Einige E-Mail-Programme geben Warnungen aus, wenn ein Zertifikat nicht lokal installiert ist. Weitere Informationen zur Installation von Zertifikaten finden Sie in der Dokumentation der entsprechenden Software. Unter &os; 10.0-RELEASE und neueren Versionen ist es möglich, ein selbst signiertes Zertifikat für Sendmail automatisch erzeugen zu lassen. Um diese Funktionalität zu aktivieren, fügen Sie die folgenden Zeilen in /etc/rc.conf ein: sendmail_enable="YES" sendmail_cert_enable="YES" sendmail_cert_cn="localhost.example.org" Dadurch wird automatisch ein selbst signiertes Zertifikat (/etc/mail/certs/host.cert), der Schlüssel für die CA (/etc/mail/certs/host.key und das Zertifikat der CA (/etc/mail/certs/cacert.pem erzeugt. Das Zertifikat wird den in festgelegten Common Name verwenden. Nachdem Sie die Änderungen gespeichert haben, starten Sie Sendmail neu: &prompt.root; service sendmail restart Wenn alles gut ging, erscheinen keine Fehlermeldungen in /var/log/maillog. Für einen einfachen Test, bauen Sie mit Hilfe von telnet eine Verbindung zum Mailserver auf: &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.14.7/8.14.7; Fri, 18 Apr 2014 11:50:32 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. Wenn die Zeile STARTTLS erscheint, hat alles funktioniert. <acronym>VPN</acronym> mit <acronym>IPsec</acronym> Nik Clayton
nik@FreeBSD.org
 Geschrieben von Hiten M. Pandya
hmp@FreeBSD.org
 Geschrieben von IPsec Internet Protocol Security (IPsec) ist ein Satz von Protokollen, die auf dem Internet-Protokoll (IP) aufbauen. Durch Authentifizierung und Verschlüsselung jedes einzelnen IP-Pakets, können mehrere Systeme geschützt miteinander kommunizieren. &os;s IPSsec Netzwerk-Stack basiert auf der http://www.kame.net Implementierung und unterstützt sowohl IPv4 als auch IPv6. IPsec ESP IPsec AH IPsec besteht aus den folgenden Protokollen: Encapsulated Security Payload (ESP): dieses Protokoll verschlüsselt IP-Pakete mit einem symmetrischen Verfahren wie Blowfish oder 3DES. Damit werden die Pakete vor Manipulationen Dritter geschützt. Authentication Header (AH): dieses Protokoll enthält eine kryptographische Prüfsumme, die sicher stellt, dass ein IP-Paket nicht verändert wurde. Der Authentication-Header folgt nach dem normalen IP-Header und erlaubt dem Empfänger eines IP-Paketes, dessen Integrität zu prüfen. IP Payload Compression Protocol (IPComp): dieses Protokoll versucht durch Komprimierung der IP-Nutzdaten die Menge der gesendeten Daten zu reduzieren und somit die Kommunikationsleistung zu verbessern. Diese Protokolle können, je nach Situation, zusammen oder einzeln verwendet werden. VPN Virtual Private Network VPN IPsec unterstützt zwei Modi: Der Transport-Modus verschlüsselt die Daten zwischen zwei Systemen. Der Tunnel-Modus verbindet zwei Subnetze miteinander. Durch einen Tunnel können dann verschlüsselte Daten übertragen werden. Ein Tunnel wird auch als Virtual-Private-Network (VPN) bezeichnet. Detaillierte Informationen über das IPsec-Subsystem von &os; finden Sie in &man.ipsec.4;. Seit &os; 11 ist IPsec in der Voreinstellung aktiviert. Um die Unterstützung für IPsec in älteren Versionen zu aktivieren, fügen Sie folgenden Optionen in die Kernelkonfigurationsdatei ein und erstellen Sie einen neuen Kernel, wie in beschrieben. Kerneloption IPSEC options IPSEC #IP security device crypto Kerneloption IPSEC_DEBUG Wenn Sie zur Fehlersuche im IPsec-Subsystem Unterstützung wünschen, sollten Sie die folgende Option ebenfalls aktivieren: options IPSEC_DEBUG #debug for IP security Der Rest dieses Kapitels beschreibt die Einrichtung eines IPsec-VPN zwischen einem Heimnetzwerk und einem Firmennetzwerk. Für das folgende Beispiel gilt: Beide Netzwerke sind über ein &os;-Gateway mit dem Internet verbunden. Der Gateway jedes Netzwerks besitzt mindestens eine externe IP-Adresse. In diesem Beispiel ist die externe IP-Adresse des Firmennetzwerks (LAN) 172.16.5.4 und das Heimnetzwerk (LAN) hat die externe IP-Adresse 192.168.1.12. Die intern verwendeten IP-Adressen können private oder öffentliche Adressen sein. Sie dürfen sich jedoch nicht überschneiden. Zum Beispiel sollten nicht beide Netze 192.168.1.x benutzen. In diesem Beispiel ist die interne IP-Adresse des Firmennetzwerks (LAN) 10.246.38.1 und das Heimnetzwerk (LAN) hat die interne IP-Adresse 10.0.0.5. Konfiguration eines <acronym>VPN</acronym> unter &os; Tom Rhodes
trhodes@FreeBSD.org
 Geschrieben von Als erstes muss security/ipsec-tools aus der Ports-Sammlung installiert werden. Diese Software enthält einige Anwendungen, die bei der Konfiguration von IPsec hilfreich sind. Als nächstes müssen zwei &man.gif.4;-Pseudogeräte angelegt werden, um die Pakete zu tunneln und dafür zu sorgen, dass beide Netzwerke richtig miteinander kommunizieren können. Geben Sie als root die folgenden Befehle ein, wobei Sie intern und extern durch die realen internen und externen IP-Adressen der Gateways ersetzen müssen: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 intern1 intern2 &prompt.root; ifconfig gif0 tunnel extern1 extern2 Überprüfen Sie mit ifconfig die Konfiguration auf beiden Gateways. Hier folgt die Ausgabe von Gateway 1: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 Hier folgt die Ausgabe von Gateway 2: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 Wenn Sie fertig sind, sollten beide internen Adressen über &man.ping.8; erreichbar sein: priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms corp-net# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms Wie erwartet, können nun beiden Seiten ICMP-Pakete von ihren privaten Adressen senden und empfangen. Als nächstes müssen beide Gateways so konfiguriert werden, dass sie die Pakete des anderen Netzwerkes richtig routen. Dazu werden folgende Befehle verwendet: corp-net&prompt.root; route add 10.0.0.0 10.0.0.5 255.255.255.0 corp-net&prompt.root; route add net 10.0.0.0: gateway 10.0.0.5 priv-net&prompt.root; route add 10.246.38.0 10.246.38.1 255.255.255.0 priv-net&prompt.root; route add host 10.246.38.0: gateway 10.246.38.1 Ab jetzt sollten die Rechner von den Gateways sowie von den Rechnern hinter den Gateways erreichbar sein. Dies können Sie wieder mit &man.ping.8; überprüfen: corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms priv-net# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms Das Konfigurieren der Tunnel ist der einfache Teil. Die Konfiguration einer sicheren Verbindung geht viel mehr in die Tiefe. Die folgende Konfiguration benutzt pre-shared (PSK) RSA-Schlüssel. Abgesehen von den IP-Adressen, sind beide /usr/local/etc/racoon/racoon.conf identisch und sehen ähnlich aus: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete padding # options are not to be changed { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # timing options. change as needed { counter 5; interval 20 sec; persend 1; # natt_keepalive 15 sec; phase1 30 sec; phase2 15 sec; } listen # address [port] that racoon will listen on { isakmp 172.16.5.4 [500]; isakmp_natt 172.16.5.4 [4500]; } remote 192.168.1.12 [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; # nat_traversal off; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 30 sec; dh_group 1; } } sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp) { # $network must be the two internal networks you are joining. pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; } Eine Beschreibung der verfügbaren Optionen finden Sie in der Manualpage von racoon.conf. Die Security Policy Database (SPD) muss noch konfiguriert werden, so dass &os; und racoon in der Lage sind den Netzwerkverkehr zwischen den Hosts zu ver- und entschlüsseln. Dies wird durch ein Shellskript ähnlich wie das folgende, das auf dem Firmennetzwerk-Gateway liegt, ausgeführt. Diese Datei wird während der Systeminitialisierung ausgeführt und sollte unter /usr/local/etc/racoon/setkey.conf gespeichert werden. flush; spdflush; # To the home network spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; Nachdem die Datei gespeichert wurde, kann racoon durch das folgende Kommando auf beiden Gateways gestartet werden: &prompt.root; /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log Die Ausgabe sollte so ähnlich aussehen: corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66) Um sicherzustellen, dass der Tunnel richtig funktioniert, wechseln Sie auf eine andere Konsole und benutzen Sie &man.tcpdump.1; mit dem folgenden Befehl, um sich den Netzwerkverkehr anzusehen. Tauschen Sie em0 durch die richtige Netzwerkkarte aus: &prompt.root; tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 Die Ausgabe der Konsole sollte dem hier ähneln. Wenn nicht, gibt es ein Problem und ein Debuggen der ausgegebenen Daten ist notwendig. 01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc) An diesem Punkt sollten beide Netzwerke verfügbar sein und den Anschein haben, dass sie zum selben Netzwerk gehören. Meistens sind beide Netzwerke durch eine Firewall geschützt. Um den Netzwerkverkehr zwischen den beiden Netzwerken zu erlauben, ist es notwendig Regeln zu erstellen. Für die &man.ipfw.8; Firewall fügen Sie folgende Zeilen in die Firewall-Konfigurationsdatei ein: ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log udp from any 500 to any Die Regelnummern müssen eventuell, je nach Hostkonfiguration, angepasst werden. Für Benutzer der &man.pf.4;- oder &man.ipf.8;-Firewall sollte folgendes funktionieren: pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any Zum Ende, um dem Computer den Start vom VPN während der Systeminitialisierung zu erlauben, fügen Sie folgende Zeilen in ihre /etc/rc.conf: ein ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes" OpenSSH Chern Lee Beigetragen von OpenSSH Sicherheit OpenSSH OpenSSH stellt Werkzeuge bereit, um sicher auf entfernte Maschinen zuzugreifen. Zusätzlich können TCP/IP-Verbindungen sicher durch SSH getunnelt oder weitergeleitet werden. OpenSSH verschlüsselt alle Verbindungen. Dadurch wird beispielsweise verhindert, dass die Verbindung abgehört oder übernommen (Hijacking) werden kann. Weitere Informationen zu OpenSSH finden Sie auf http://www.openssh.com/. Dieser Abschnitt enthält einen Überblick über die integrierten Client-Werkzeuge, mit denen Sie sicher auf entfernte Systeme zugreifen können, oder mit denen Sie sicher Dateien austauschen können. Der Abschnitt beschreibt auch die Konfiguration eines SSH-Servers auf einem &os;-System. Weitere Informationen finden Sie in den hier erwähnten Manualpages. Die SSH Client-Werkzeuge benutzen OpenSSH Client Benutzen Sie ssh zusammen mit einem Benutzernamen und einer IP-Adresse oder dem Hostnamen, um sich an einem SSH-Server anzumelden. Ist dies das erste Mal, dass eine Verbindung mit dem angegebenen Server hergestellt wird, wird der Benutzer aufgefordert, zuerst den Fingerabdruck des Servers zu prüfen: &prompt.root; ssh user@example.com The authenticity of host 'example.com (10.0.0.1)' can't be established. ECDSA key fingerprint is 25:cc:73:b5:b3:96:75:3d:56:19:49:d2:5c:1f:91:3b. Are you sure you want to continue connecting (yes/no)? yes Permanently added 'example.com' (ECDSA) to the list of known hosts. Password for user@example.com: user_password SSH speichert einen Fingerabdruck des Serverschlüssels um die Echtheit des Servers zu überprüfen, wenn der Client eine Verbindung herstellt. Wenn der Benutzer den Fingerabdruck mit yes bestätigt, wird eine Kopie des Schlüssels in .ssh/known_hosts im Heimatverzeichnis des Benutzers gespeichert. Zukünftige Verbindungen zu dem Server werden gegen den gespeicherten Fingerabdruck des Schlüssels geprüft und der Client gibt eine Warnung aus, wenn sich der empfangene Fingerabdruck von dem gespeicherten unterscheidet. Wenn dies passiert, sollte zunächst geprüft werden, ob sich der Schlüssel geändert hat, bevor die Verbindung hergestellt wird. In der Voreinstellung akzeptieren aktuelle Versionen von OpenSSH nur SSHv2 Verbindungen. Wenn möglich, wird der Client versuchen Version 2 zu verwenden, ist dies nicht möglich, fällt er auf Version 1 zurück. Der Client kann gezwungen werden, nur eine der beiden Versionen zu verwenden, indem die Option oder übergeben wird. Weitere Optionen sind in &man.ssh.1; beschrieben. OpenSSH secure copy &man.scp.1; Mit &man.scp.1; lassen sich Dateien in einer sicheren Weise auf entfernte Maschinen übertragen. Dieses Beispiel kopiert die Datei COPYRIGHT von einem entfernten System in eine Datei mit dem gleichen Namen auf das lokale System: &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT Password for user@example.com: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Da der Fingerabdruck für diesen Rechner bereits bestätigt wurde, wird er automatisch überprüft, bevor der Benutzer zur Eingabe des Passworts aufgefordert wird. Die Argumente, die scp übergeben werden, gleichen denen von cp in der Beziehung, dass die ersten Argumente die zu kopierenden Dateien sind und das letzte Argument den Bestimmungsort angibt. Da die Dateien über das Netzwerk kopiert werden, können ein oder mehrere Argumente die Form besitzen. Beachten Sie, das scp die Option verwendet um Dateien rekursiv zu kopieren, während cp benutzt. Mit sftp können Dateien über eine interaktive Sitzung kopiert werden. &man.sftp.1; beschreibt die verfügbaren Befehle, die während einer sftp-Sitzung zur Verfügung stehen. Schlüsselbasierte Authentifizierung Ein Client kann bei der Verbindung auch Schlüssel anstelle von Passwörtern verwenden. Benutzen Sie ssh-keygen um RSA-Schlüssel erzeugen. Geben Sie das entsprechende Protokoll an, wenn Sie einen öffentlichen und einen privaten Schlüssel erzeugen. Folgen Sie anschließend den Anweisungen des Programms. Es wird empfohlen, die Schlüssel mit einer einprägsamen, aber schwer zu erratenen Passphrase zu schützen. &prompt.user; ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: SHA256:54Xm9Uvtv6H4NOo6yjP/YCfODryvUU7yWHzMqeXwhq8 user@host.example.com The key's randomart image is: +---[RSA 2048]----+ | | | | | | | . o.. | | .S*+*o | | . O=Oo . . | | = Oo= oo..| | .oB.* +.oo.| | =OE**.o..=| +----[SHA256]-----+ Geben Sie hier die Passphrase ein. Diese darf auch Leer- und Sonderzeichen enthalten. Geben Sie die Passphrase zur Überprüfung erneut ein. Der private Schlüssel wird in ~/.ssh/id_rsa und der öffentliche Schlüssel in ~/.ssh/id_rsa.pub gespeichert. Der öffentliche Schlüssel muss zuerst auf den entfernten Rechner nach ~/.ssh/authorized_keys kopiert werden, damit die schlüsselbasierte Authentifizierung funktioniert. Viele Benutzer denken, dass die Verwendung von Schlüsseln generell sicher ist. Sie verwenden dann einen Schlüssel ohne eine Passphrase. Dies ist jedoch sehr gefährlich. Ein Administrator kann überprüfen, ob ein Schlüsselpaar mit einer Passphrase geschützt ist. Wenn die Datei mit dem privaten Schlüssel den Text ENCRYPTED enthält, dann hat der Benutzer eine Passphrase verwendet. Um die Benutzer zusätzlich zu schützen, kann ein from-Feld in der Datei des öffentlichen Schlüssels hinzugefügt werden. Zum Beispiel würde das Hinzufügen von from="192.168.10.5" vor dem ssh-rsa-Präfix dafür sorgen, dass sich ein bestimmter Benutzer nur noch von dieser IP-Adresse anmelden darf. Die Optionen und Dateinamen sind abhängig von der eingesetzten Version von OpenSSH. Die für das System gültigen Optionen finden Sie in &man.ssh-keygen.1;. Wenn bei der Erzeugung des Schlüssels eine Passphrase angegeben wurde, wird der Benutzer bei jeder Anmeldung am Server zur Eingabe der Passphrase aufgefordert. Mit &man.ssh-agent.1; und &man.ssh-add.1; ist es möglich, SSH-Schlüssel in den Speicher zu laden, damit die Passphrase nicht jedes Mal eingegeben werden muss. ssh-agent übernimmt die Authentifizierung mit den geladenen privaten Schlüsseln. ssh-agent kann dazu verwendet werden, ein anderes Programm zu starten, beispielsweise eine Shell oder einen Window-Manager. Um ssh-agent in einer Shell zu verwenden, muss es mit einer Shell als Argument aufgerufen werden. Die zu verwaltende Identität muss mit ssh-add sowie der Passphrase für den privaten Schlüssel übergeben werden. Danach kann sich der Benutzer mit ssh auf jedem Rechner anmelden, der einen entsprechenden öffentlichen Schlüssel besitzt. Dazu ein Beispiel: &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /usr/home/user/.ssh/id_rsa: Identity added: /usr/home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) &prompt.user; Geben Sie hier die Passphrase für den Schlüssel ein. Um ssh-agent unter &xorg; zu verwenden, muss ein Eintrag für das Programm in ~/.xinitrc aufgenommen werden. Dadurch können alle unter &xorg; gestarteten Programme die Dienste von ssh-agent nutzen. ~/.xinitrc könnte etwa so aussehen: exec ssh-agent startxfce4 Dadurch wird bei jedem Start von &xorg; zuerst ssh-agent aufgerufen, das wiederum XFCE startet. Nachdem diese Änderung durchgeführt wurde, muss &xorg; neu gestartet werden. Danach können Sie mit ssh-add die SSH-Schlüssel laden. <acronym>SSH</acronym>-Tunnel OpenSSH Tunnel Mit OpenSSH ist es möglich, einen Tunnel zu erstellen, in dem ein anderes Protokoll verschlüsselt übertragen wird. Im folgenden Kommando erzeugt ssh einen Tunnel für telnet: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; Dieses Beispiel verwendet die folgenden Optionen: Zwingt ssh dazu, die Version 2 des Protokolls zu verwenden, um sich mit dem Server zu verbinden. Zeigt an, dass ein Tunnel erstellt werden soll. Ohne diese Option würde ssh eine normale Sitzung öffnen. Zwingt ssh im Hintergrund zu laufen. Ein lokaler Tunnel wird in der Form localport:remotehost:remoteport angegeben. Die Verbindung wird dabei von dem lokalen Port localport auf einen entfernten Rechner weitergeleitet. Gibt den Anmeldenamen auf dem entfernten SSH-Server an. Ein SSH-Tunnel erzeugt einen Socket auf localhost und dem angegebenen lokalen Port. Jede Verbindung, die auf dem angegebenen Socket aufgemacht wird, wird dann auf den spezifizierten entfernten Rechner und Port weitergeleitet. Im Beispiel wird der lokale Port 5023 an die entfernte Maschine auf Port 23 weitergeleitet. Da der Port 23 für telnet reserviert ist, erzeugt das eine sichere &man.telnet.1;-Verbindung durch einen SSH-Tunnel. Wie in den folgenden Beispielen zu sehen ist, kann diese Vorgehensweise genutzt werden, um jedes unsichere TCP-Protokoll, wie SMTP, POP3 und FTP, weiterzuleiten. Einen sicheren Tunnel für <acronym>SMTP</acronym> erstellen &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP Zusammen mit ssh-keygen und zusätzlichen Benutzer-Accounts können leicht benutzbare SSH-Tunnel aufgebaut werden. Anstelle von Passwörtern können Schlüssel benutzt werden und jeder Tunnel kann unter einem eigenen Benutzer laufen. Sicherer Zugriff auf einen <acronym>POP3</acronym>-Server In diesem Beispiel gibt es einen SSH-Server, der Verbindungen von außen akzeptiert. Im selben Netzwerk befindet sich zudem noch ein Mail-Server, der POP3 spricht. Um E-Mails auf sichere Weise abzurufen, bauen Sie eine SSH-Verbindung zu dem SSH-Server im Netzwerk auf und tunneln von dort zum Mail-Server weiter. &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** Wenn Sie den Tunnel eingerichtet haben, konfigurieren Sie den Mail-Client so, dass er POP3 Anfragen zu localhost auf Port 2110 sendet. Diese Verbindung wird dann über den gesicherten Tunnel zu mail.example.com weitergeleitet. Umgehen einer Firewall Einige Firewalls filtern sowohl eingehende als auch ausgehende Verbindungen. Zum Beispiel könnte eine Firewall den Zugriff auf entfernte Rechner auf die Ports 22 und 80 beschränken, um lediglich SSH und Web-Inhalte zu erlauben. Dies würde den Zugriff auf Dienste verhindern, die nicht die Ports 22 oder 80 benutzen. Die Lösung hier ist es, eine SSH-Verbindung zu einer Maschine außerhalb der Firewall aufzumachen und durch diese zum gewünschten Dienst zu tunneln: &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* In diesem Beispiel benutzt ein Ogg Vorbis Client localhost und Port 8888. Die Verbindung wird dann zu music.example.com Port 8000 weitergeleitet. Die Firewall wurde somit erfolgreich umgangen. Den SSH-Server aktivieren OpenSSH aktivieren Neben den integrierten SSH Client-Werkzeugen, die zur Verfügung stehen, kann ein &os;-System auch als SSH-Server konfiguriert werden, um Verbindungen von anderen SSH-Clients zu akzeptieren. Benutzen Sie den Kommando &man.service.8;, um zu prüfen ob der sshd ausgeführt wird: &prompt.root; service sshd status Wenn der Dienst nicht ausgeführt wird, fügen Sie folgende Zeile in /etc/rc.conf ein: sshd_enable="YES" Diese Zeile startet sshd, den OpenSSH-Daemon, beim nächsten Systemstart. Geben Sie folgendes ein, um den Dienst jetzt zu starten: &prompt.root; service sshd start Wenn sshd erstmalig gestartet wird, werden die Host-Schlüssel des Systems erzeugt und der Fingerabdruck wird auf der Konsole angezeigt. Stellen Sie den Fingerabdruck den Benutzern zur Verfügung, sodass sie ihn überprüfen können, wenn sie das erste Mal eine Verbindung mit dem Server herstellen. &man.sshd.8; enthält die verfügbaren Optionen für den Start von sshd und weitere Informationen zur Authentifizierung, den Anmeldeprozess und die verschiedenen Konfigurationsdateien. Ab jetzt sollte sshd für alle Benutzer mit einem Benutzernamen und Kennwort zur Verfügung stehen. SSH Server Sicherheit Obwohl sshd das am weitesten verbreitete Remote-Administrations-Werkzeug ist, sind Brute-Force- und Drive-by-Angriffe auf öffentliche Netzwerke weit verbreitet. Daher stehen mehrere Optionen zur Verfügung, um diese Art von Angriffen zu verhindern. Diese Optionen werden in diesem Abschnitt beschrieben. Es ist in der Regel ein gute Idee, festzulegen, welche Benutzer sich von welchem Rechner aus anmelden können. Dies lässt sich beispielsweise über die Option AllowUsers festlegen. Soll sich etwa nur root vom Rechner mit der IP-Adresse 192.168.1.32 aus einwählen dürfen, würden Sie folgenden Eintrag in /etc/ssh/sshd_config aufnehmen: AllowUsers root@192.168.1.32 Damit sich admin von jedem Rechner aus anmelden kann, geben Sie nur den Benutzernamen an: AllowUsers admin Sie können auch mehrere Benutzer in einer Zeile aufführen: AllowUsers root@192.168.1.32 admin Nachdem Sie /etc/ssh/sshd_config angepasst haben, muss sshd seine Konfigurationsdateien neu einlesen. Dazu geben Sie Folgendes ein: &prompt.root; /etc/rc.d/sshd reload Wenn die Option AllowUsers verwendet wird, ist es wichtig, jeden Benutzer aufzulisten, der sich an diesem Rechner anmelden muss. Benutzer, die nicht in dieser Liste aufgeführt sind, dürfen sich nicht anmelden. Die Optionen für die Konfigurationsdatei von OpenSSH unterscheiden zwischen Groß- und Kleinschreibung. Wenn Sie eine Option falsch schreiben, so wird sie ingnoriert. Testen Sie immer die Änderungen, um sicherzustellen, dass sie wie erwartet funktionieren. Weitere Informationen zu den verfügbaren Optionen finden Sie in &man.sshd.config.5;. Darüber hinaus können Benutzer gezwungen werden, eine Zwei-Faktor-Authentifizierung mit einem öffentlichen und einem privaten Schlüssel zu benutzen. Bei Bedarf kann der Benutzer ein Schlüsselpaar mit &man.ssh-keygen.1; erzeugen und dem Administrator den öffentlichen Schlüssel zukommen lassen. Der Schlüssel wird, wie weiter oben beschrieben, in authorized_keys platziert. Um den Benutzer zu zwingen, ausschließlich Schlüssel zu benutzen, kann die folgende Option konfiguriert werden: AuthenticationMethods publickey Verwechseln Sie nicht /etc/ssh/sshd_config mit /etc/ssh/ssh_config (beachten Sie das zusätzliche d im ersten Dateinamen). Die erste Datei konfiguriert den Server und die zweite Datei konfiguriert den Client. &man.ssh.config.5; enthält eine Auflistung der verfügbaren Client-Einstellungen. Zugriffskontrolllisten für Dateisysteme (<acronym>ACL</acronym>) Tom Rhodes Beigetragen von ACL Zugriffskontrolllisten (Access Control Lists, ACL) erweitern die normalen Zugriffsrechte von &unix; Systemen auf eine kompatible (&posix;.1e) Weise und bieten feiner granulierte Sicherheitsmechanismen. Der GENERIC-Kernel von &os; bietet ACL-Unterstützung für UFS-Dateisysteme. Benutzer, die es vorziehen einen eigenen Kernel zu übersetzen, müssen die folgende Option in die Kernelkonfigurationsdatei aufnehmen: options UFS_ACL Das System gibt eine Warnung aus, wenn ein Dateisystem mit ACLs eingehangen werden soll und die Unterstützung für ACLs nicht im Kernel aktiviert ist. ACLs bauen auf den erweiterten Attributen auf, die von UFS2 standardmäßig unterstützt werden. Dieses Kapitel beschreibt, wie ACL-Unterstützung aktiviert wird. Zudem werden einige Anwendungsbeispiele vorgestellt. <acronym>ACL</acronym>-Unterstützung aktivieren Die Option in /etc/fstab aktiviert Zugriffskontrolllisten für ein Dateisystem. Die bevorzugte Möglichkeit ist die Verwendung von Zugriffskontrolllisten mit &man.tunefs.8; (Option ), im Superblock des Dateisystems festzuschreiben. Diese Möglichkeit hat mehrere Vorteile: Nochmaliges Einhängen eines Dateisystems (Option von &man.mount.8;) verändert den Status der Zugriffskontrolllisten nicht. Die Verwendung von Zugriffskontrolllisten kann nur durch Abhängen und erneutes Einhängen eines Dateisystems verändert werden. Das heißt auch, dass Zugriffskontrolllisten nicht nachträglich auf dem Root-Dateisystem aktiviert werden können. Die Zugriffskontrolllisten auf den Dateisystemen sind, unabhängig von den Optionen in /etc/fstab oder Namensänderungen der Geräte, immer aktiv. Dies verhindert auch, dass Zugriffskontrolllisten aus Versehen auf Dateisystemen ohne Zugriffskontrolllisten aktiviert werden. Es kann sein, dass sich der Status von Zugriffskontrolllisten später durch nochmaliges Einhängen des Dateisystems (Option von &man.mount.8;) ändern lässt. Die momentane Variante ist aber sicherer, da der Status der Zugriffskontrolllisten nicht versehentlich geändert werden kann. Allgemein sollten Zugriffskontrolllisten auf einem Dateisystem, auf dem sie einmal verwendet wurden, nicht deaktiviert werden, da danach die Zugriffsrechte falsch sein können. Werden Zugriffskontrolllisten auf einem solchen Dateisystem wieder aktiviert, werden die Zugriffsrechte von Dateien, die sich zwischenzeitlich geändert haben, überschrieben, was zu erneuten Problemen führt. Die Zugriffsrechte einer Datei werden durch ein + (Plus) gekennzeichnet, wenn die Datei durch Zugriffskontrolllisten geschützt ist: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html In diesem Beispiel sind die Verzeichnisse directory1, directory2 und directory3 durch Zugriffskontrolllisten geschützt, wohingegen das Verzeichnis public_html nicht geschützt ist. Zugriffskontrolllisten benutzen getfacl zeigt Zugriffskontrolllisten an. Das folgende Kommando zeigt die ACLs auf der Datei test: &prompt.user; getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- setfacl ändert oder entfernt ACLs auf Dateien. Um alle ACLs einer Datei zu entfernen, können Sie die Option benutzen. Es ist jedoch empfehlenswert die Option zu verwenden, da sie die erforderlichen Felder, die für ACLs benötigt werden, beibehält. &prompt.root; setfacl -k test Benutzen Sie um die Einträge der ACL zu verändern: &prompt.user; setfacl -m u:trhodes:rwx,g:web:r--,o::--- test In diesem Beispiel gab es keine vordefinierten Einträge, da sie durch den vorhergehenden Befehl entfernt wurden. Mit diesem Kommando werden die eben entfernten Zugriffskontrolllisten wiederhergestellt. Der Befehl gibt die Fehlermeldung Invalid argument aus, wenn Sie nicht existierende Benutzer oder Gruppen als Parameter angeben. Weitere Informationen zu den Optionen dieser Kommandos finden Sie in &man.getfacl.1; und &man.setfacl.1;. Sicherheitsprobleme in Software von Drittanbietern überwachen Tom Rhodes Beigetragen von pkg In den letzten Jahren wurden zahlreiche Verbesserungen in der Einschätzung und dem Umgang mit Sicherheitsproblemen erzielt. Die Gefahr von Einbrüchen in ein System wird aber immer größer, da Softwarepakete von Dritten auf nahezu jedem Betriebssystem installiert und konfiguriert werden. Die Einschätzung der Verletzlichkeit eines Systems ist ein Schlüsselfaktor für dessen Sicherheit. &os; veröffentlicht zwar Sicherheitshinweise (security advisories) für das Basissystem, das Projekt ist allerdings nicht dazu in der Lage, dies auch für die zahlreichen Softwarepakete von Dritten zu tun. Dennoch gibt es einen Weg, auch diese Programmpakete zu überwachen. Das &os; Dienstprogramm pkg enthält Optionen für genau diesen Anwendungsfall. pkg fragt dazu eine Datenbank auf bekannte Sicherheitsprobleme ab. Diese Datenbank wird vom &os; Security Team sowie den Ports-Entwicklern aktualisiert und gewartet. Anweisungen zur Installation von pkg finden Sie im . Die Installation enthält Konfigurationsdateien für &man.periodic.8;, welche die Datenbank von pkg verwaltet und aktualisiert. Diese Funktionalität wird aktiviert, wenn in &man.periodic.conf.5; die Variable daily_status_security_pkgaudit_enable auf YES gesetzt wird. Stellen Sie auf jeden Fall sicher, dass diese (an das E-Mail-Konto von root gesendeten) Sicherheitsberichte auch gelesen werden. Nach der Installation kann ein Administrator mit dem folgenden Kommando die Datenbank aktualisieren und sich die Sicherheitslücken in installierten Paketen anzeigen lassen: &prompt.root; pkg audit -F pkg zeigt dann die Schwachstellen in installierten Pakete an: Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: <https://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. Wenn Sie die angegebene URL über einen Internetbrowser aufrufen, erhalten Sie weitere Informationen über die bestehende Sicherheitslücke, wie die betroffenen Versionen, die Version des &os;-Ports sowie Hinweise auf weitere Seiten, die ebenfalls Sicherheitshinweise zu diesem Problem bieten. pkg ist ein mächtiges Werkzeug und insbesondere in Zusammenarbeit mit ports-mgmt/portmaster äußerst hilfreich. &os; Sicherheitshinweise Tom Rhodes Beigesteuert von &os; Sicherheitshinweise Wie viele andere Hersteller von hochwertigen Betriebssystemen, hat auch das &os;-Projekt ein Sicherheitsteam, das für die Bestimmung des End-of-Life (EoL) Datum verantwortlich ist. Das Sicherheitsteam stellt zudem sicher, dass Sicherheitsupdates für unterstützte Versionen, welche noch nicht ihr EoL erreicht haben, zur Verfügung gestellt werden. Weitere Informationen über das &os; Sicherheitsteam und den unterstützten Versionen finden Sie auf der Webseite &os; Security. Zu den Aufgaben des Sicherheitsteams zählt es, auf gemeldete Sicherheitslücken im &os;-Betriebssystem zu reagieren. Sobald eine Sicherheitslücke bestätigt wird, überprüft das Sicherheitsteam die notwendigen Schritte, um die Schwachstelle zu beheben und den Quellcode mit der Korrektur zu aktualisieren. Anschließend veröffentlicht es die Details in einem Sicherheitshinweis (Security Advisory). Die Sicherheitshinweise werden auf der &os; Webseite und auf den Mailinglisten &a.security-notifications.name;, &a.security.name; und &a.announce.name; veröffentlicht. Dieser Abschnitt beschreibt das Format eines &os; Sicherheitshinweises. Format eines Sicherheitshinweis Hier ist ein Beispiel für einen &os; Sicherheitshinweis: ============================================================================= -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:04.bind Security Advisory The FreeBSD Project Topic: BIND remote denial of service vulnerability Category: contrib Module: bind Announced: 2014-01-14 Credits: ISC Affects: FreeBSD 8.x and FreeBSD 9.x Corrected: 2014-01-14 19:38:37 UTC (stable/9, 9.2-STABLE) 2014-01-14 19:42:28 UTC (releng/9.2, 9.2-RELEASE-p3) 2014-01-14 19:42:28 UTC (releng/9.1, 9.1-RELEASE-p10) 2014-01-14 19:38:37 UTC (stable/8, 8.4-STABLE) 2014-01-14 19:42:28 UTC (releng/8.4, 8.4-RELEASE-p7) 2014-01-14 19:42:28 UTC (releng/8.3, 8.3-RELEASE-p14) CVE Name: CVE-2014-0591 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit <URL:http://security.FreeBSD.org/>. I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet Domain Name Server. II. Problem Description Because of a defect in handling queries for NSEC3-signed zones, BIND can crash with an "INSIST" failure in name.c when processing queries possessing certain properties. This issue only affects authoritative nameservers with at least one NSEC3-signed zone. Recursive-only servers are not at risk. III. Impact An attacker who can send a specially crafted query could cause named(8) to crash, resulting in a denial of service. IV. Workaround No workaround is available, but systems not running authoritative DNS service with at least one NSEC3-signed zone using named(8) are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 8.3, 8.4, 9.1, 9.2-RELEASE and 8.4-STABLE] # fetch http://security.FreeBSD.org/patches/SA-14:04/bind-release.patch # fetch http://security.FreeBSD.org/patches/SA-14:04/bind-release.patch.asc # gpg --verify bind-release.patch.asc [FreeBSD 9.2-STABLE] # fetch http://security.FreeBSD.org/patches/SA-14:04/bind-stable-9.patch # fetch http://security.FreeBSD.org/patches/SA-14:04/bind-stable-9.patch.asc # gpg --verify bind-stable-9.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>. Restart the applicable daemons, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r260646 releng/8.3/ r260647 releng/8.4/ r260647 stable/9/ r260646 releng/9.1/ r260647 releng/9.2/ r260647 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: -<URL:http://svnweb.freebsd.org/base?view=revision&revision=NNNNNN> +<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN> VII. References <URL:https://kb.isc.org/article/AA-01078> <URL:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0591> The latest revision of this advisory is available at <URL:http://security.FreeBSD.org/advisories/FreeBSD-SA-14:04.bind.asc> -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS1ZTYAAoJEO1n7NZdz2rnOvQP/2/68/s9Cu35PmqNtSZVVxVG ZSQP5EGWx/lramNf9566iKxOrLRMq/h3XWcC4goVd+gZFrvITJSVOWSa7ntDQ7TO XcinfRZ/iyiJbs/Rg2wLHc/t5oVSyeouyccqODYFbOwOlk35JjOTMUG1YcX+Zasg ax8RV+7Zt1QSBkMlOz/myBLXUjlTZ3Xg2FXVsfFQW5/g2CjuHpRSFx1bVNX6ysoG 9DT58EQcYxIS8WfkHRbbXKh9I1nSfZ7/Hky/kTafRdRMrjAgbqFgHkYTYsBZeav5 fYWKGQRJulYfeZQ90yMTvlpF42DjCC3uJYamJnwDIu8OhS1WRBI8fQfr9DRzmRua OK3BK9hUiScDZOJB6OqeVzUTfe7MAA4/UwrDtTYQ+PqAenv1PK8DZqwXyxA9ThHb zKO3OwuKOVHJnKvpOcr+eNwo7jbnHlis0oBksj/mrq2P9m2ueF9gzCiq5Ri5Syag Wssb1HUoMGwqU0roS8+pRpNC8YgsWpsttvUWSZ8u6Vj/FLeHpiV3mYXPVMaKRhVm 067BA2uj4Th1JKtGleox+Em0R7OFbCc/9aWC67wiqI6KRyit9pYiF3npph+7D5Eq 7zPsUdDd+qc+UTiLp3liCRp5w6484wWdhZO6wRtmUgxGjNkxFoNnX8CitzF8AaqO UWWemqWuz3lAZuORQ9KX =OQzQ -----END PGP SIGNATURE----- Jeder Sicherheitshinweis verwendet das folgende Format: Jeder Sicherheitshinweis wird mit dem PGP-Schlüssel des Sicherheitsbeauftragten unterzeichnet. Der öffentliche Schlüssel des Sicherheitsbeauftragten kann in überprüft werden. Der Name des Sicherheitshinweises beginnt immer mit FreeBSD-SA- (für FreeBSD Security Advisory), gefolgt vom Jahr im zweistelligen Format (14:), gefolgt von der Anzahl von Sicherheitshinweisen für dieses Jahr (04.), gefolgt vom Namen der Anwendung oder des betroffenen Subsystems (bind). Der hier gezeigte Sicherheitshinweis ist der vierte Hinweis für das Jahr 2014 und betrifft die Anwendung BIND. Das Feld Topic enthält eine Beschreibung der Schwachstelle. Das Feld Category beschreibt den betroffenen Systemteil. Mögliche Werte für dieses Feld sind core, contrib oder ports. Die Kategorie core gilt für Komponenten des &os;-Betriebssystems, die Kategorie contrib beschreibt zum Basissystem gehörende Software Dritter, beispielsweise BIND. Die Kategorie ports beschreibt Software, die Teil der Ports-Sammlung ist. Das Feld Module beschreibt die betroffene Komponente. Im diesem Beispiel ist das bind-Modul betroffen, dass heißt dieses Problem betrifft eine Anwendung aus dem Betriebssystem. Das Feld Announced gibt den Zeitpunkt der Bekanntgabe des Sicherheitshinweises an. Das bedeutet, dass das Sicherheitsteam das Problem bestätigt hat und das eine entsprechende Korrektur bereits im &os; Quellcode-Repository zur Verfügung steht . Das Feld Credits gibt die Person oder Organisation an, die das Sicherheitsproblem bemerkt und gemeldet hat. Das Feld Affects listet die &os;-Releases auf, die von dem Problem betroffen sind. Das Feld Corrected zeigt an, wann das Problem in welchem Release behoben wurde. Der Teil in Klammern zeigt an, in welchem Zweig die Aktualisierung eingeflossen ist und die entsprechende Versionsnummer und Patch-Level des Release. Der Patch-Level besteht aus dem Buchstaben p, gefolgt von einer Nummer. Dies erlaubt es dem Benutzer festzustellen, welche Korrekturen bereits auf dem System eingespielt wurden. Reserviert für Informationen, über die auf cve.mitre.org nach Sicherheitslücken gesucht werden kann. Im Feld Background wird das betroffene Modul beschrieben. Im Feld Problem Description wird das Sicherheitsproblem beschrieben. Hier wird fehlerhafter Code beschrieben oder geschildert, wie ein Werkzeug ausgenutzt werden könnte. Das Feld Impact beschreibt die Auswirkungen des Sicherheitsproblems auf ein System. Im Feld Workaround wird eine Umgehung des Sicherheitsproblems beschrieben. Die Umgehung ist für Administratoren gedacht, die das System aus Zeitnot, Netzwerk-technischen oder anderen Gründen nicht aktualisieren können. Das Feld Solution enthält eine getestete Schritt-für-Schritt Anleitung, die das Sicherheitsproblem behebt. Das Feld Correction Details enthält die Subversion-Tags der betroffenen Dateien zusammen mit zugehörigen Revisionsnummern, in denen das Problem behoben wurde. Im Feld References finden sich Verweise auf weitere Informationsquellen. Prozess-Überwachung Tom Rhodes Beigetragen von Prozess-Überwachung Prozess-Überwachung (Process accounting) ist ein Sicherheitsverfahren, bei dem ein Administrator verfolgt, welche Systemressourcen verwendet werden und wie sich diese auf die einzelnen Anwender verteilen. Dadurch kann das System überwacht werden und es ist sogar möglich, zu kontrollieren, welche Befehle ein Anwender eingibt. Die Überwachung von Prozessen hat sowohl Vor- als auch Nachteile. Positiv ist, dass man einen Einbruchsversuch bis an den Anfang zurückverfolgen kann. Von Nachteil ist allerdings, dass durch diesen Prozess Unmengen an Protokolldateien erzeugt werden, die auch dementsprechenden Plattenplatz benötigen. Dieser Abschnitt beschreibt die Grundlagen der Prozess-Überwachung. Wenn Sie eine differenzierte Prozess-Überwachung benötigen, lesen Sie . Die Prozess-Überwachung aktivieren und konfigurieren Bevor Sie die Prozess-Überwachung verwenden können, müssen Sie diese über die folgenden Befehle aktivieren: &prompt.root; touch /var/account/acct &prompt.root; chmod 600 /var/account/acct &prompt.root; accton /var/account/acct &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf Einmal aktiviert, wird sofort mit der Überwachung von CPU-Statistiken, Befehlen und anderen Vorgängen begonnen. Protokolldateien werden in einem nur von Maschinen lesbaren Format gespeichert und können mit sa aufgerufen werden. Ohne Optionen gibt sa Informationen wie die Anzahl der Aufrufe pro Anwender, die abgelaufene Zeit in Minuten, die gesamte CPU- und Anwenderzeit in Minuten und die durchschnittliche Anzahl der Ein- und Ausgabeoperationen aus. &man.sa.8; enthält eine Liste der Optionen, welche die Ausgabe steuern. Benutzen Sie lastcomm, um die von den Benutzern ausgeführten Befehle anzuzeigen. Dieses Beispiel zeigt die Nutzung von ls durch trhodes auf dem Terminal ttyp1: &prompt.root; lastcomm ls trhodes ttyp1 Zahlreiche weitere nützliche Optionen finden Sie &man.lastcomm.1;, &man.acct.5; sowie &man.sa.8;. Einschränkung von Ressourcen Tom Rhodes Beigetragen von Ressourcen einschränken &os; bietet dem Systemadministrator mehrere Möglichkeiten die System-Ressourcen, die ein einzelner Benutzer verwenden kann, einzuschränken. Festplatten-Kontingente schränken den Plattenplatz, der einem Benutzer zur Verfügung steht, ein. Kontingente werden im diskutiert. Quotas Benutzer einschränken Quotas Einschränkungen auf andere Ressourcen, wie CPU und Speicher, können über eine Konfigurationsdatei oder über die Kommandozeile konfiguriert werden. Traditionell werden Login-Klassen in /etc/login.conf definiert. Obwohl diese Methode immer noch untersützt wird, muss nach jeder Änderung an dieser Datei die Ressourcen-Datenbank neu gebaut werden. Zudem müssen Sie die notwendigen Änderungen in /etc/master.passwd vornehmen und die Passwort-Datenbnak neu bauen. Dieser Prozess kann, abhängig davon, wie viele Benutzer bearbeitet werden müssen, sehr zeitaufwändig sein. Beginnend mit &os; 9.0-RELEASE können mit rctl Ressourcen für Benutzer sehr detailliert gesteuert werden. Dieser Befehl unterstützt nicht nur die Kontrolle der Ressourcen für Benutzer, sondern auch die Beschränkung auf Prozesse und Jails. In diesem Abschnitt werden beide Methoden vorgestellt. Angefangen wird mit der traditionellen Methode. Login-Klassen konfigurieren Benutzer einschränken Accounts einschränken /etc/login.conf Bei der traditionellen Methode werden Login-Klassen und Ressourcenbeschränkungen in /etc/login.conf definiert. Jeder Benutzer kann einer Login-Klasse zugewiesen werden (standardmäßig default) und jede Login-Klasse ist mit einem Satz von Login-Fähigkeiten verbunden. Eine Login-Fähigkeit ist ein Name=Wert Paar, in dem Name die Fähigkeit bezeichnet und Wert ein beliebiger Text ist, der in Abhänigkeit von Name entsprechend verarbeitet wird. Immer wenn /etc/login.conf verändert wurde, muss die /etc/login.conf.db mit dem folgenden Kommando aktualisiert werden: &prompt.root; cap_mkdb /etc/login.conf Ressourcenbeschränkungen unterscheiden sich von normalen Login-Fähigkeiten zweifach. Erstens gibt es für jede Beschränkung ein aktuelles und ein maximales Limit. Das aktuelle Limit kann vom Benutzer oder einer Anwendung beliebig bis zum maximalen Limit verändert werden. Letzteres kann der Benutzer nur heruntersetzen. Zweitens gelten die meisten Ressourcenbeschränkungen für jeden vom Benutzer gestarteten Prozess. listet die gebräuchlichen Ressourcenbeschränkungen auf. Alle verfügbaren Ressourcenbeschränkungen und Fähigkeiten sind im Detail in &man.login.conf.5; beschrieben. Benutzer einschränken coredumpsize Benutzer einschränken cputime Benutzer einschränken filesize Benutzer einschränken maxproc Benutzer einschränken memorylocked Benutzer einschränken memoryuse Benutzer einschränken openfiles Benutzer einschränken sbsize Benutzer einschränken stacksize Ressourcenbeschränkungen für Login-Klassen Ressourcenbeschränkung Beschreibung coredumpsize Das Limit der Größe einer core-Datei, die von einem Programm generiert wird, unterliegt aus offensichtlichen Gründen anderen Limits der Festplattenbenutzung, zum Beispiel filesize oder Festplattenkontingenten. Es wird oft als weniger harte Methode zur Kontrolle des Festplattenplatz-Verbrauchs verwendet. Da Benutzer die core-Dateien selbst nicht erstellen und sie oft nicht löschen, kann diese Option davor schützen, dass kein Festplattenspeicher mehr zur Verfügung steht, sollte ein großes Programm abstürzen. cputime Die maximale Rechenzeit, die ein Prozess eines Benutzers verbrauchen darf. Überschreitet ein Prozess diesen Wert, wird er vom Kernel beendet. Beachten Sie, dass die Rechenzeit limitiert wird, nicht die prozentuale Prozessorenbenutzung, wie es in einigen Feldern von top und ps dargestellt wird. filesize Hiermit lässt sich die maximale Größe einer Datei bestimmen, die der Benutzer besitzen darf. Im Gegensatz zu Festplattenkontingenten ist diese Beschränkung nur für jede einzelne Datei gültig und nicht für den Platz, den alle Dateien eines Benutzers verwenden. maxproc Das ist die maximale Anzahl von Prozessen, die ein Benutzer starten darf, und beinhaltet sowohl Vordergrund- als auch Hintergrundprozesse. Dieser Wert nicht höher sein als das System-Limit, das in kern.maxproc angegeben ist. Vergessen Sie nicht, dass ein zu kleiner Wert den Benutzer in seiner Produktivität einschränken könnte, wenn beispielsweise ein großes Programm übersetzt wird oder viele Prozesse gestartet sind. memorylocked Dieses Limit gibt an, wie viel virtueller Speicher von einem Prozess maximal im Arbeitsspeicher festgesetzt werden kann (siehe auch &man.mlock.2;). Ein paar systemkritische Programme, wie &man.amd.8;, verhindern damit einen Systemzusammenbruch, der auftreten könnte, wenn sie aus dem Speicher genommen werden. memoryuse Bezeichnet den maximalen Speicher, den ein Prozess benutzen darf und beinhaltet sowohl Arbeitsspeicher-, als auch Swap-Benutzung. Es ist kein allübergreifendes Limit für den Speicherverbrauch, aber ein guter Anfang. openfiles Mit diesem Limit lässt sich die maximale Anzahl der von einem Prozess des Benutzers geöffneten Dateien festlegen. In &os; werden Dateien auch verwendet, um Sockets und >IPC>-Kanäle darzustellen. Setzen Sie es deshalb nicht zu niedrig. Das System-Limit ist in kern.maxfiles definiert. sbsize Dieses Limit beschränkt den Netzwerk-Speicher, den ein Benutzer verbrauchen darf. Es kann generell dazu benutzt werden Netzwerk-Verbindungen zu beschränken. stacksize Das ist die maximale Größe, auf die der Stack eines Prozesses heranwachsen darf. Das allein ist natürlich nicht genug, um den Speicher zu beschränken, den ein Programm verwenden darf. Es sollte deshalb in Verbindung mit anderen Limits verwendet werden.
Beim Setzen von Ressourcenbeschränkungen sind noch andere Dinge zu beachten: Von /etc/rc beim Hochfahren des Systems gestartete Prozesse werden der daemon Login-Klasse zugewiesen. Obwohl die voreingestellte /etc/login.conf sinnvolle Limits enthält, sind sie evtl. nicht für jedes System geeignet. Ein zu hohes Limit kann das System für Missbrauch anfällig machen, und ein zu niedriges Limit kann der Produktivität schaden. &xorg; beansprucht selbst eine Menge Ressourcen und verleitet die Benutzer dazu, mehrere Programme gleichzeitig laufen zu lassen. Bedenken Sie, dass viele Limits für einzelne Prozesse gelten und nicht für den Benutzer selbst. Setzt man zum Beispiel openfiles auf 50, kann jeder Prozess des Benutzers bis zu 50 Dateien öffnen. Dadurch ist die maximale Anzahl von Dateien, die von einem Benutzer geöffnet werden können, openfiles mal maxproc. Das gilt auch für den Speicherverbrauch. Weitere Informationen über Ressourcenbeschränkungen, Login-Klassen und -Fähigkeiten finden Sie in &man.cap.mkdb.1;, &man.getrlimit.2; und &man.login.conf.5;. Einschränkung von Ressourcen aktivieren und konfigurieren Seit &os; 10.2 wird rctl in der Voreinstellung vom Kernel unterstützt. Für ältere Versionen muss zunächst nach den Anweisungen in ein neuer Kernel erzeugt werden. Fügen Sie dazu folgende Zeilen in die Kernelkonfigurationsdatei ein: options RACCT options RCTL Sobald das System mit dem neuen Kernel gestartet wird, kann rctl benutzt werden, um die Regeln für das System festzulegen. Die Syntax der Regeln wird durch subject, subject-id, resource und action gesteuert, wie in diesem Beispiel zu sehen ist: user:trhodes:maxproc:deny=10/user Diese Regel zeigt den grundlegenden Aufbau, hier mit dem Subjekt user und der Subjekt-ID trhodes. maxproc definiert die Anzahl der Prozesse. Die Aktion deny verhindert, dass neue Prozesse erstellt werden. Im vorherigen Beispiel wurde für den Benutzer trhodes eine Beschränkung von 10 Prozessen konfiguriert. Zu den weiteren Aktionen zählen beispielsweise die Protokollierung auf der Konsole, Benachrichtigungen an &man.devd.8; oder das Senden eines SIGTERM an einen Prozess. Beim hinzufügen von Regeln müssen einige Dinge beachtet werden. Das obige Beispiel würde den Benutzer sogar daran hindern, einfachste Dinge zu tun, nachdem er sich anmeldet und eine screen Sitzung gestartet hat. Sobald die Begrenzung für eine Ressource erreicht ist, wird folgende Fehlermeldung ausgegeben: &prompt.root; man test /usr/bin/man: Cannot fork: Resource temporarily unavailable eval: Cannot fork: Resource temporarily unavailable &man.rctl.8; kann auch benutzt werden, um einer Jail eine Speichergrenze zuzuweisen. Eine solche Regel könnte wie folgt festgelegt werden: &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail Damit die Regeln auch nach einem Neustart erhalten bleiben, müssen sie in /etc/rctl.conf hinzugefügt werden. Dazu schreiben Sie einfach die Regel, ohne das vorhergehende Kommando. Zum Beispiel: # Block jail from using more than 2G memory: jail:httpd:memoryuse:deny=2G/jail Mit rctl können auch Regeln entfernt werden: &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user &man.rctl.8; zeigt auch eine Möglichkeit, alle Regeln zu entfernen. Falls es erforderlich ist alle Regeln für einen einzelnen Benutzer zu entfernen, kann dieser Befehl verwendet werden: &prompt.root; rctl -r user:trhodes Es gibt noch viele weitere Ressourcen, die verwendet werden können, um zusätzliche subjects zu kontrollieren. Weitere Informationen zu diesem Thema finden Sie in &man.rctl.8;. Gemeinsame Administration mit Sudo Tom Rhodes Beigetragen von Björn Heidotting Übersetzt von Sicherheit Sudo Systemadministratoren benötigen häufig die Möglichkeit, Benutzern erweiterte Berechtigungen zu gewähren, damit diese privilegierte Aufgaben ausführen können. Die Idee, dass Teammitglieder einen Zugang zu einem &os;-System zur Verfügung gestellt bekommen, um ihre spezifischen Aufgaben erledigen zu können, stellt den Administrator vor eine große Herausforderung. Diese Teammitglieder benötigen in der Regel nur einen eingeschränkten Zugang. Für manche Aufgaben werden jedoch die Rechte des Superusers benötigt. Zum Glück gibt es keinen Grund, diesen Mitgliedern einen solchen Zugang zu geben, da es Werkzeuge für genau diesen Anwendungsfall gibt. Bislang wurde in diesem Kapitel immer versucht, den Zugriff für autorisierte Benutzer zu gewähren und den Zugriff für nicht autorisierte Benutzer zu verhindern. Ein weiteres Problem entsteht, sobald autorisierte Benutzer Zugriff auf die Ressourcen des Systems haben. In vielen Fällen benötigen einige Benutzer Zugriff auf Startskripte von Anwendungen. In anderen Fällen muss eine Gruppe von Administratoren das System verwalten. Traditionell wird der Zugriff über Benutzer, Gruppen, Dateiberechtigungen und manchmal sogar &man.su.1; verwaltet. Und da immer mehr Anwendungen einen Zugriff brauchen und immer mehr Benutzer Zugriff auf die Systemressourcen benötigen, ist ein besserer Lösungsansatz erforderlich. Die am häufigsten verwendete Anwendung in solchen Fällen ist derzeit Sudo. Sudo erlaubt dem Administrator eine rigide Konfiguration des Zugriffs auf bestimmte Kommandos und stellt einige erweiterte Protokollfunktionen zur Verfügung. Dieses Werkzeug kann als Port oder Paket security/sudo installiert werden. Das Paket wird wie folgt installiert: &prompt.root; pkg install sudo Nach der Installation können Sie visudo benutzen, um die Konfiguration in einem Texteditor zu öffnen. Es wird ausdrücklich visudo empfohlen, da dieses Programm die Syntax auf Fehler überprüft, bevor die Konfigurationsdatei gespeichert wird. Die Konfigurationsdatei besteht aus mehreren kleinen Abschnitten, die eine umfangreiche Konfiguration ermöglichen. Im folgenden Beispiel soll der Webentwickler (user1) den Dienst webservice starten und stoppen dürfen. Um ihm dieses Recht zu gewähren, fügen Sie folgende Zeile an das Ende von /usr/local/etc/sudoers ein: user1 ALL=(ALL) /usr/sbin/service webservice * Der Benutzer kann jetzt webservice über dieses Kommando starten: &prompt.user; sudo /usr/sbin/service webservice start Diese Konfiguration gestattet den Zugriff auf den webservice für einen einzelnen Benutzer. Jedoch ist in den meisten Organisationen ein ganzes Team für die Verwaltung eines solchen Dienstes verantwortlich. Mit einer weiteren Zeile ist es möglich, einer ganzen Gruppe diesen Zugriff zu geben. Die folgenden Schritte erstellen eine Gruppe mit den entsprechenden Benutzern. Der Gruppe wird es dann ermöglicht, diesen Dienst zu verwalten: &prompt.root; pw groupadd -g 6001 -n webteam Nun werden die Benutzer mit Hilfe von &man.pw.8; in die Gruppe webteam hinzugefügt: &prompt.root; pw groupmod -m user1 -n webteam Zuletzt wird folgende Zeile in /usr/local/etc/sudoers hinzugefügt, damit jedes Mitglied von webteam den Dienst webservice verwalten kann: %webteam ALL=(ALL) /usr/sbin/service webservice * Im Gegensatz zu &man.su.1;, benötigt Sudo nur das Passwort des Benutzers. Benutzer, die mit Hilfe von Sudo Programme ausführen, müssen lediglich ihr eigenes Passwort eingeben. Dies ist sicherer und bietet eine bessere Kontrolle als &man.su.1;, wo der Benutzer das root-Passwort eingibt und damit alle Rechte von root erlangt. Viele Organisationen haben bereits auf eine Zwei-Faktor-Authentifizierung umgestellt. In diesen Fällen hat der Benutzer möglicherweise gar kein Passwort, welches er eingeben könnte. Sudo bietet für solche Fälle die Variable NOPASSWD. Wenn die Variable in die obige Konfiguration hinzugefügt wird, dürfen die Mitglieder der Gruppe webteam den Dienst verwalten, ohne ein Passwort eingeben zu müssen: %webteam ALL=(ALL) NOPASSWD: /usr/sbin/service webservice * Protokollierung Ein Vorteil von Sudo ist, dass Sitzungen protokolliert werden können. Mit den integrierten Protokollmechanismen und dem Befehl sudoreplay können alle über Sudo ausgelösten Befehle protokolliert und zu einem späteren Zeitpunkt überprüft werden. Um diese Funktion zu aktivieren, fügen Sie einen Eintrag für das Verzeichnis der Protokolle hinzu. Dieses Beispiel verwendet eine Benutzervariable. Weitere Informationen finden Sie in der Manualpage von sudoreplay. Defaults iolog_dir=/var/log/sudo-io/%{user} Dieses Verzeichnis wird automatisch nach der Konfiguration erstellt. Um auf der sicheren Seite zu sein, ist es am besten, das System die Verzeichnisse mit Standardberechtigungen erstellen zu lassen. Dieser Eintrag wird auch ein Protokoll für Administratoren erstellen, wenn diese den Befehl sudoreplay benutzen. Um dieses Verhalten zu ändern, kommentieren Sie die entsprechenden Zeilen in sudoers aus. Nachdem dieser Eintrag in die Datei sudoers hinzugefügt wurde, kann die Konfiguration der Benutzer für die Protokollierung aktualisiert werden. In dem gezeigten Beispiel würde der aktualisierte Eintrag für das webteam zusätzlich folgende Änderung benötigen: %webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice * Von nun an wird jede Änderung am webservice protokolliert, wenn sie von einem Mitglied der Gruppe webteam initiiert wurde. Eine Liste der Sitzungen kann wie folgt angezeigt werden: &prompt.root; sudoreplay -l Wenn Sie eine bestimmte Sitzung wiedergeben möchten, suchen Sie in der Ausgabe nach dem Eintrag TSID= und übergeben Sie den Wert ohne weitere Optionen an sudoreplay. Zum Beispiel: &prompt.root; sudoreplay user1/00/00/02 Obwohl die Sitzungen protokolliert werden, kann ein böswilliger Administrator wahllos die Sitzungsprotokolle löschen. Daher ist es eine gute Idee, eine tägliche Kontrolle mit einem Intrusion Detection System (IDS) oder einer ähnlichen Software durchzuführen, so dass andere Administratoren auf manuelle Änderungen aufmerksam gemacht werden. sudoreplay ist extrem erweiterbar. Lesen Sie die Dokumentation für weitere Informationen.