<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD German Documentation Project
$FreeBSD$
$FreeBSDde: de-docproj/books/handbook/network-servers/chapter.sgml,v 1.103 2011/12/24 15:51:18 bcr Exp $
basiert auf: 1.138
-->
<chapter id="network-servers">
<chapterinfo>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
<contrib>Überarbeitet von </contrib>
</author>
</authorgroup>
<!-- 23 July 2004 -->
<authorgroup>
<author>
<firstname>Johann</firstname>
<surname>Kois</surname>
<contrib>Übersetzt von </contrib>
</author>
</authorgroup>
</chapterinfo>
<title>Netzwerkserver</title>
<sect1 id="network-servers-synopsis">
<title>Übersicht</title>
<para>Dieses Kapitel beschreibt einige der häufiger verwendeten
Netzwerkdienste auf &unix;-Systemen. Beschrieben werden
Installation und Konfiguration sowie Test und Wartung
verschiedener Netzwerkdienste. Zusätzlich sind im ganzen
Kapitel Beispielkonfigurationsdateien vorhanden, von denen Sie
sicherlich profitieren werden.</para>
<para>Nachdem Sie dieses Kapitel gelesen haben, werden Sie</para>
<itemizedlist>
<listitem>
<para>Den <application>inetd</application>-Daemon konfigurieren
können.</para>
</listitem>
<listitem>
<para>Wissen, wie man ein Netzwerkdateisystem einrichtet.</para>
</listitem>
<listitem>
<para>Einen <foreignphrase>Network Information
Server</foreignphrase> einrichten können, um damit
Benutzerkonten im Netzwerk zu verteilen.</para>
</listitem>
<listitem>
<para>Rechner durch Nutzung von DHCP automatisch für ein
Netzwerk konfigurieren können.</para>
</listitem>
<listitem>
<para>In der Lage sein, einen <foreignphrase>Domain Name
Server</foreignphrase> einzurichten.</para>
</listitem>
<listitem>
<para>Den <application>Apache</application> HTTP-Server
konfigurieren können.</para>
</listitem>
<listitem>
<para>Wissen, wie man einen <foreignphrase>File Transfer
Protocol</foreignphrase> (FTP)-Server einrichtet.</para>
</listitem>
<listitem>
<para>Mit <application>Samba</application> einen Datei- und
Druckserver für &windows;-Clients konfigurieren
können.</para>
</listitem>
<listitem>
<para>Unter Nutzung des NTP-Protokolls Datum und Uhrzeit
synchronisieren sowie einen Zeitserver installieren
können.</para>
</listitem>
<listitem>
<para>Wissen, wie man den Standard-Protokollierungsdienst,
<command>syslogd</command>, konfiguriert, um Protokolle von
anderen Hosts zu akzeptieren.</para>
</listitem>
</itemizedlist>
<para>Bevor Sie dieses Kapitel lesen, sollten Sie</para>
<itemizedlist>
<listitem>
<para>Die Grundlagen der <filename>/etc/rc</filename>-Skripte
verstanden haben.</para>
</listitem>
<listitem>
<para>Mit der grundlegenden Netzwerkterminologie vertraut sein.</para>
</listitem>
<listitem>
<para>Wissen, wie man zusätzliche Softwarepakete von
Drittherstellern installiert (<xref linkend="ports"/>).</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="network-inetd">
<sect1info>
<authorgroup>
<author>
<firstname>Chern</firstname>
<surname>Lee</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<contrib>Aktualisiert vom </contrib>
<othername>&os; Documentation Project</othername>
</author>
</authorgroup>
</sect1info>
<title>Der <application>inetd</application>
<quote>Super-Server</quote></title>
<sect2 id="network-inetd-overview">
<title>Überblick</title>
<para>&man.inetd.8; wird manchmal auch als <quote>Internet
Super-Server</quote> bezeichnet, weil er Verbindungen für
mehrere Dienste verwaltet. Wenn eine Verbindung eintrifft,
bestimmt <application>inetd</application>, welches Programm
für die eingetroffene Verbindung zuständig ist,
aktiviert den entsprechenden Prozess und reicht den Socket an
ihn weiter (der Socket dient dabei als Standardein- und -ausgabe
sowie zur Fehlerbehandlung). Der Einsatz des
<application>inetd</application>-Daemons an Stelle
viele einzelner Daemonen kann auf nicht komplett ausgelasteten
Servern zu einer Verringerung der Systemlast führen.</para>
<para><application>inetd</application> wird vor allem dazu
verwendet, andere Daemonen zu aktivieren, einige Protokolle
werden aber auch direkt verwaltet. Dazu gehören
<application>chargen</application>,
<application>auth</application>, sowie
<application>daytime</application>.</para>
<para>Dieser Abschnitt beschreibt die Konfiguration von
<application>inetd</application> durch Kommandozeilenoptionen
sowie die Konfigurationsdatei
<filename>/etc/inetd.conf</filename>.</para>
</sect2>
<sect2 id="network-inetd-settings">
<title>Einstellungen</title>
<para><application>inetd</application> wird durch das
&man.rc.8;-System initialisiert. Die Option
<literal>inetd_enable</literal> ist in der Voreinstellung zwar
auf <literal>NO</literal> gesetzt, sie kann aber in
Abhängigkeit von der vom Benutzer bei der Installation
gewählten Konfiguration von
<application>sysinstall</application> aktiviert werden.
Die Verwendung von</para>
<programlisting>inetd_enable="YES"</programlisting>
<para>oder</para>
<programlisting>inetd_enable="NO"</programlisting>
<para>in <filename>/etc/rc.conf</filename> deaktiviert oder startet
<application>inetd</application> beim Systemstart. Über
den Befehl</para>
<screen>&prompt.root; <userinput>/etc/rc.d/inetd rcvar</userinput></screen>
<para>können Sie die aktuelle Konfiguration
abfragen.</para>
<para>Weitere Optionen können über die Option
<literal>inetd_flags</literal> an
<application>inetd</application> übergeben werden.</para>
</sect2>
<sect2 id="network-inetd-cmdline">
<title>Kommandozeilenoptionen</title>
<para>Wie die meisten anderen Server-Daemonen lässt
sich auch <application>inetd</application> über
verschiedene Optionen steuern. Die vollständige Syntax
für <application>inetd</application> lautet:</para>
<para><command>inetd</command> <option>[-d] [-l] [-w] [-W] [-c maximum] [-C rate] [-a address | hostname]
[-p filename] [-R rate] [-s maximum] [configuration file]</option></para>
<para>Die verschiedenen Optionen können über die Option
<literal>inetd_flags</literal> der Datei
<filename>/etc/rc.conf</filename> an
<application>inetd</application> übergeben werden. In
der Voreinstellung hat diese Option den Wert
<literal>-wW -C 60</literal>. Durch das Setzen dieser Werte
wird das TCP-Wrapping für alle
<application>inetd</application>-Dienste aktiviert.
Zusätzlich kann eine einzelne IP-Adresse jeden Dienst
nur maximal 60 Mal pro Minute anfordern.</para>
<para>Für Einsteiger ist es erfreulich, dass diese Parameter
in der Regel nicht angepasst werden müssen. Da diese
Parameter aber dennoch von Interesse sein können
(beispielsweise, wenn Sie eine enorme Anzahl von
Verbindungsanfragen erhalten), werden einige dieser
einschränkenden Parameter im Folgenden näher
erläutert. Eine vollständige Auflistung aller
Optionen finden Sie hingegen in &man.inetd.8;.</para>
<variablelist>
<varlistentry>
<term>-c maximum</term>
<listitem>
<para>Legt die maximale Anzahl von parallen Aufrufen eines
Dienstes fest; in der Voreinstellung gibt es keine
Einschränkung. Diese Einstellung kann für jeden
Dienst durch Setzen des <option>max-child</option>
-Parameters festgelegt werden.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-C rate</term>
<listitem>
<para>Legt fest, wie oft ein Dienst von einer einzelnen
IP-Adresse in einer Minute aufgerufen werden kann; in der
Voreinstellung gibt es keine Einschränkung. Dieser
Wert kann für jeden Dienst durch Setzen des
Parameters
<option>max-connections-per-ip-per-minute</option>
festgelegt werden.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-R rate</term>
<listitem>
<para>Legt fest, wie oft ein Dienst in der Minute aktiviert
werden kann; in der Voreinstellung sind dies 256
Aktivierungen pro Minute. Ein Wert von 0 erlaubt
unbegrenzt viele Aktivierungen.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-s maximum</term>
<listitem>
<para>Legt fest, wie oft ein Dienst in der Minute von einer
einzelnen IP-Adresse aus aktiviert werden kann; in der
Voreinstellung gibt es hier keine Beschränkung. Diese
Einstellung kann für jeden Dienst durch die Angabe
<option>max-child-per-ip</option> angepasst werden.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2 id="network-inetd-conf">
<!-- XXX Dieser Abschnitt ist etwas verwirrend und sollte mal überarbeitet werden. -->
<title><filename>inetd.conf</filename></title>
<para>Die Konfiguration von <application>inetd</application>
erfolgt über die Datei
<filename>/etc/inetd.conf</filename>.</para>
<para>Wenn <filename>/etc/inetd.conf</filename> geändert
wird, kann <application>inetd</application> veranlasst werden,
seine Konfigurationsdatei neu einzulesen.</para>
<example id="network-inetd-reread">
<title>Die <application>inetd</application>-Konfiguration neu
einlesen</title>
<screen>&prompt.root; <userinput>/etc/rc.d/inetd reload</userinput></screen>
</example>
<para>Jede Zeile der Konfigurationsdatei beschreibt jeweils einen
Daemon. Kommentare beginnen mit einem <quote>#</quote>. Ein
Eintrag der Datei <filename>/etc/inetd.conf</filename> hat
folgenden Aufbau:</para>
<programlisting>service-name
socket-type
protocol
{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]
user[:group][/login-class]
server-program
server-program-arguments</programlisting>
<para>Ein Eintrag für den IPv4 verwendenden
&man.ftpd.8;-Daemon könnte so aussehen:</para>
<programlisting>ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l</programlisting>
<variablelist>
<varlistentry>
<term>service-name</term>
<listitem>
<para>Der Dienstname eines bestimmten Daemons. Er muss
einem in <filename>/etc/services</filename> aufgelisteten
Dienst entsprechen. In dieser Datei wird festgelegt,
welchen Port <application>inetd</application> abhören
muss. Wenn ein neuer Dienst erzeugt wird, muss er zuerst
in die Datei <filename>/etc/services</filename>
eingetragen werden.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>socket-type</term>
<listitem>
<para>Entweder <literal>stream</literal>,
<literal>dgram</literal>, <literal>raw</literal>, oder
<literal>seqpacket</literal>. <literal>stream</literal>
muss für verbindungsorientierte TCP-Daemonen
verwendet werden, während <literal>dgram</literal>
das <acronym>UDP</acronym>-Protokoll verwaltet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>protocol</term>
<listitem>
<para>Eines der folgenden:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>Protokoll</entry>
<entry>Bedeutung</entry>
</row>
</thead>
<tbody>
<row>
<entry>tcp, tcp4</entry>
<entry>TCP (IPv4)</entry>
</row>
<row>
<entry>udp, udp4</entry>
<entry>UDP (IPv4)</entry>
</row>
<row>
<entry>tcp6</entry>
<entry>TCP (IPv6)</entry>
</row>
<row>
<entry>udp6</entry>
<entry>UDP (IPv6)</entry>
</row>
<row>
<entry>tcp46</entry>
<entry>TCP sowohl unter IPv4 als auch unter IPv6</entry>
</row>
<row>
<entry>udp46</entry>
<entry>UDP sowohl unter IPv4 als auch unter IPv6</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
</varlistentry>
<varlistentry>
<term>{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]</term>
<listitem>
<para><option>wait|nowait</option> gibt an, ob der von
<application>inetd</application> aktivierte Daemon seinen
eigenen Socket verwalten kann oder nicht.
<option>dgram</option>-Sockets müssen die Option
<option>wait</option> verwenden, während Daemonen mit
Stream-Sockets, die normalerweise auch aus mehreren
Threads bestehen, die Option <option>nowait</option>
verwenden sollten. Die Option <option>wait</option>
gibt in der Regel mehrere Sockets an einen einzelnen
Daemon weiter, während <option>nowait</option>
für jeden neuen Socket einen Childdaemon erzeugt.</para>
<para>Die maximale Anzahl an Child-Daemonen, die
<application>inetd</application> erzeugen kann, wird durch
die Option <option>max-child</option> festgelegt. Wenn
ein bestimmter Daemon 10 Instanzen benötigt, sollte
der Wert <literal>/10</literal> hinter die Option
<option>nowait</option> gesetzt werden. Geben Sie
hingegen den Wert <literal>/0</literal> an, gibt es
keine Beschränkung.</para>
<para>Zusätzlich zu <option>max-child</option> kann
die maximale Anzahl von Verbindungen eines Rechners mit
einem bestimmten Daemon durch zwei weitere Optionen
beschränkt werden. Die Option
<option>max-connections-per-ip-per-minute</option>
legt die maximale Anzahl von Verbindungsversuchen fest,
die von einer bestimmten IP-Adresse aus unternommen werden
können. Ein Wert von zehn würde die maximale
Anzahl von Verbindungsversuchen einer IP-Adresse mit einem
bestimmten Dienst auf zehn Versuche in der Minute
beschränken. Durch die Angabe der Option
<option>max-child-per-ip</option> können Sie hingegen
festlegen, wie viele Child-Daemonen von einer bestimmten
IP-Adresse aus gestartet werden können. Durch diese
Optionen lassen sich ein absichtlicher oder unabsichtlicher
Ressourcenverbrauch sowie die Auswirkungen eines
<literal>Denial of Service (DoS)</literal>-Angriffs auf
einen Rechner begrenzen.</para>
<para>Sie müssen hier entweder <option>wait</option>
oder <option>nowait</option> angeben. Die Angabe von
<option>max-child</option>,
<option>max-connections-per-ip-per-minute</option> und
<option>max-child-per-ip</option> ist hingegen
optional.</para>
<para>Ein multithread-Daemon vom Streamtyp ohne die Optionen
<option>max-child</option>,
<option>max-connections-per-ip-per-minute</option> oder
<option>max-child-per-ip</option> sieht so aus:
<literal>nowait</literal></para>
<para>Der gleiche Daemon mit einer maximal möglichen
Anzahl von 10 parallelen Daemonen würde so aussehen:
<literal>nowait/10</literal></para>
<para>Wird zusätzlich die Anzahl der möglichen
Verbindungen pro Minute für jede IP-Adresse auf
20 sowie die mögliche Gesamtzahl von Childdaemonen
auf 10 begrenzt, so sieht der Eintrag so aus:
<literal>nowait/10/20</literal></para>
<para>All diese Optionen werden vom
&man.fingerd.8;-Daemon bereits in der Voreinstellung
verwendet:</para>
<programlisting>finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s</programlisting>
<para>Will man die maximale Anzahl von Child-Daemonen auf
100 beschränken, wobei von jeder IP-Adresse aus
maximal 5 Child-Daemonen gestartet werden dürfen,
verwendet man den folgenden Eintrag:
<literal>nowait/100/0/5</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>user</term>
<listitem>
<para>Der Benutzername, unter dem der jeweilige Daemon
laufen soll. Meistens laufen Daemonen als User
<username>root</username>. Aus Sicherheitsgründen
laufen einige Server aber auch als User
<username>daemon</username>, oder als am wenigsten
privilegierter User <username>nobody</username>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>server-program</term>
<listitem>
<para>Der vollständige Pfad des Daemons, der eine
Verbindung entgegennimmt. Wird der Daemon von
<application>inetd</application> intern bereitgestellt,
sollte die Option <option>internal</option> verwendet
werden.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>server-program-arguments</term>
<listitem>
<para>Dieser Eintrag legt (gemeinsam mit
<option>server-program</option> und beginnend mit
<literal>argv[0]</literal>), die Argumente fest, die bei
der Aktivierung an den Daemon übergeben werden.
Wenn die Anweisung auf der Kommandozeile also
<command>mydaemon -d</command> lautet, wäre
<literal>mydaemon -d</literal> auch der Wert der Option
<option>server program arguments</option>. Wenn es sich
beim Daemon um einen internen Dienst handelt, sollte
wiederum die Option <option>internal</option> verwendet
werden.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2 id="network-inetd-security">
<title>Sicherheit</title>
<para>Abhängig von der bei der Installation festgelegten
Konfiguration werden viele der von
<application>inetd</application> verwalteten Dienste automatisch
aktiviert! Wenn Sie einen bestimmten Daemon nicht
benötigen, sollten Sie ihn deaktivieren! Dazu kommentieren
Sie den jeweiligen Daemon in <filename>/etc/inetd.conf</filename>
mit einem <quote>#</quote> aus, um danach die
<link linkend="network-inetd-reread">inetd-Konfiguration neu
einzulesen</link>. Einige Daemonen, zum Beispiel
<application>fingerd</application>, sollten generell deaktiviert
werden, da sie zu viele Informationen an einen potentiellen
Angreifer liefern.</para>
<para>Einige Daemonen haben unsichere Einstellungen, etwa
große oder nichtexistierende Timeouts für
Verbindungsversuche, die es einem Angreifer erlauben, über
lange Zeit langsam Verbindungen zu einem bestimmten Daemon
aufzubauen, um dessen verfügbare Ressourcen zu verbrauchen.
Es ist daher eine gute Idee, diese Daemonen durch die Optionen
<option>max-connections-per-ip-per-minute</option>,
<option>max-child</option> sowie
<option>max-child-per-ip</option> zu beschränken, wenn
Sie sehr viele Verbindungsversuche mit Ihrem System
registrieren.</para>
<para>TCP-Wrapping ist in der Voreinstellung aktiviert. Lesen Sie
&man.hosts.access.5;, wenn Sie weitere Informationen zum
Setzen von TCP-Beschränkungen für verschiedene von
<application>inetd</application> aktivierte Daemonen
benötigen.</para>
</sect2>
<sect2 id="network-inetd-misc">
<title>Verschiedenes</title>
<para>Bei <application>daytime</application>,
<application>time</application>,
<application>echo</application>,
<application>discard</application>,
<application>chargen</application>, und
<application>auth</application> handelt es sich um intern
von <application>inetd</application> bereitgestellte Dienste.
</para>
<para>Der <application>auth</application>-Dienst bietet
Identifizierungsdienste über das Netzwerk
an und ist bis zu einem bestimmten Grad konfigurierbar,
während die meisten anderen Dienste nur aktiviert
oder deaktiviert werden können.</para>
<para>Eine ausführliche Beschreibung finden Sie in
&man.inetd.8;.</para>
</sect2>
</sect1>
<sect1 id="network-nfs">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Reorganisiert und erweitert von </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Bill</firstname>
<surname>Swingle</surname>
<contrib>Geschrieben von </contrib>
</author>
</authorgroup>
</sect1info>
<title>NFS – Network File System</title>
<indexterm><primary>NFS</primary></indexterm>
<para>Eines der vielen von FreeBSD unterstützten Dateisysteme
ist das Netzwerkdateisystem, das auch als <acronym role="Network
File System">NFS</acronym>
bekannt ist. <acronym role="Network File System">NFS</acronym>
ermöglicht es einem System, Dateien und Verzeichnisse
über ein Netzwerk mit anderen zu teilen. Über
<acronym role="Network File System">NFS</acronym> können
Benutzer und Programme auf Daten entfernter Systeme zugreifen, und
zwar genauso, wie wenn es sich um lokale Daten handeln würde.
</para>
<para>Einige der wichtigsten Vorteile von <acronym>NFS</acronym>
sind:</para>
<itemizedlist>
<listitem>
<para>Lokale Arbeitsstationen benötigen weniger
Plattenplatz, da gemeinsam benutzte Daten nur auf einem
einzigen Rechner vorhanden sind. Alle anderen Stationen
greifen über das Netzwerk auf diese Daten zu.</para>
</listitem>
<listitem>
<para>Benutzer benötigen nur noch ein zentrales
Heimatverzeichnis auf einem <acronym>NFS</acronym>-Server.
Diese Verzeichnisse sind über das Netzwerk auf allen
Stationen verfügbar.</para>
</listitem>
<listitem>
<para>Speichergeräte wie Disketten-, CD-ROM- oder
&iomegazip;-Laufwerke können über das Netzwerk von
anderen Arbeitstationen genutzt werden. Dadurch sind für
das gesamte Netzwerk deutlich weniger Speichergeräte
nötig.</para>
</listitem>
</itemizedlist>
<sect2>
<title>Wie funktioniert <acronym>NFS</acronym>?</title>
<para><acronym>NFS</acronym> besteht aus zwei Hauptteilen: Einem
Server und einem oder mehreren Clients. Der Client greift
über das Netzwerk auf die Daten zu, die auf dem Server
gespeichert sind. Damit dies korrekt funktioniert, müssen
einige Prozesse konfiguriert und gestartet werden:</para>
<para>Der Server benötigt folgende Daemonen:</para>
<indexterm>
<primary>NFS</primary>
<secondary>Server</secondary>
</indexterm>
<indexterm>
<primary>Dateiserver</primary>
<secondary>Unix-Clients</secondary>
</indexterm>
<indexterm>
<primary><application>rpcbind</application></primary>
</indexterm>
<indexterm>
<primary><application>mountd</application></primary>
</indexterm>
<indexterm>
<primary><application>nfsd</application></primary>
</indexterm>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<colspec colwidth="1*"/>
<colspec colwidth="3*"/>
<thead>
<row>
<entry>Daemon</entry>
<entry>Beschreibung</entry>
</row>
</thead>
<tbody>
<row>
<entry><application>nfsd</application></entry>
<entry>Der <acronym>NFS</acronym>-Daemon. Er bearbeitet
Anfragen der <acronym>NFS</acronym>-Clients.</entry>
</row>
<row>
<entry><application>mountd</application></entry>
<entry>Der <acronym>NFS</acronym>-Mount-Daemon. Er
bearbeitet die Anfragen, die &man.nfsd.8; an ihn
weitergibt.</entry>
</row>
<row>
<entry><application>rpcbind</application></entry>
<entry> Der Portmapper-Daemon. Durch ihn erkennen die
<acronym>NFS</acronym>-Clients, welchen Port der
<acronym>NFS</acronym>-Server verwendet.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Der Client kann ebenfalls einen Daemon aufrufen, und zwar
den <application>nfsiod</application>-Daemon. Der
<application>nfsiod</application>-Daemon bearbeitet Anfragen vom
<acronym>NFS</acronym>-Server. Er ist optional und verbessert
die Leistung des Netzwerks. Für eine normale und korrekte
Arbeit ist er allerdings nicht erforderlich. Mehr erfahren
Sie in der Hilfeseite &man.nfsiod.8;.</para>
</sect2>
<sect2 id="network-configuring-nfs">
<title><acronym>NFS</acronym> einrichten</title>
<indexterm>
<primary>NFS</primary>
<secondary>einrichten</secondary>
</indexterm>
<para><acronym>NFS</acronym> lässt sich leicht
einrichten. Die nötigen Prozesse werden durch einige
Änderungen in <filename>/etc/rc.conf</filename> bei
jedem Systemstart gestartet.</para>
<para>Stellen Sie sicher, dass auf dem
<acronym>NFS</acronym>-Server folgende Optionen in der Datei
<filename>/etc/rc.conf</filename> gesetzt sind:</para>
<programlisting>rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"</programlisting>
<para><application>mountd</application> läuft automatisch,
wenn der <acronym>NFS</acronym>-Server aktiviert ist.</para>
<para>Auf dem Client muss in <filename>/etc/rc.conf</filename>
folgende Option gesetzt sein:</para>
<programlisting>nfs_client_enable="YES"</programlisting>
<para><filename>/etc/exports</filename> legt fest, welche
Dateisysteme <acronym>NFS</acronym> exportieren (manchmal auch
als <quote>teilen</quote> bezeichnet) soll. Jede Zeile in
<filename>/etc/exports</filename> legt ein Dateisystem sowie
die Arbeitsstationen, die darauf Zugriff haben, fest.
Außerdem ist es möglich, Zugriffsoptionen
festzulegen. Es gibt viele verschiedene Optionen, allerdings
werden hier nur einige von ihnen erwähnt. Wenn Sie
Informationen zu weiteren Optionen benötigen, lesen Sie
&man.exports.5;.</para>
<para>Nun folgen einige Beispieleinträge für
<filename>/etc/exports</filename>:</para>
<indexterm>
<primary>NFS</primary>
<secondary>Export von Dateisystemen</secondary>
</indexterm>
<para>Die folgenden Beispiele geben Ihnen Anhaltspunkte zum
Exportieren von Dateisystemen, obwohl diese Einstellungen
natürlich von Ihrer Arbeitsumgebung und Ihrer
Netzwerkkonfiguration abhängen. Das nächste
Beispiel exportiert das Verzeichnis <filename>/cdrom</filename>
für drei Rechner, die sich in derselben Domäne wie
der Server befinden oder für die entsprechende
Einträge in <filename>/etc/hosts</filename> existieren.
Die Option <option>-ro</option> kennzeichnet das
exportierte Dateisystem als schreibgeschützt. Durch dieses
Flag ist das entfernte System nicht in der Lage, das exportierte
Dateisystem zu verändern.</para>
<programlisting>/cdrom -ro host1 host2 host3</programlisting>
<para>Die nächste Zeile exportiert <filename>/home</filename>
auf drei durch IP-Adressen bestimmte Rechner. Diese Einstellung
ist nützlich, wenn Sie über ein privates Netzwerk ohne
<acronym>DNS</acronym>-Server verfügen. Optional
könnten interne Rechnernamen auch in
<filename>/etc/hosts</filename> konfiguriert werden.
Benötigen Sie hierzu weitere Informationen, lesen Sie bitte
&man.hosts.5;. Durch das Flag <option>-alldirs</option> wird es
möglich, auch Unterverzeichnisse als Mountpunkte
festzulegen. Dies bedeutet aber nicht, dass alle
Unterverzeichnisse eingehängt werden, vielmehr wird es dem
Client ermöglicht, nur diejenigen Verzeichnisse
einzuhängen, die auch benötigt werden.</para>
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
<para>Die nächste Zeile exportiert <filename>/a</filename>,
damit Clients von verschiedenen Domänen auf das Dateisystem
zugreifen können. Das <option>-maproot=root</option>-Flag
erlaubt es dem Benutzer <username>root</username> des entfernten
Systems, als <username>root</username> auf das exportierte
Dateisystem zu schreiben. Wenn dieses Flag nicht gesetzt ist,
kann selbst <username>root</username> nicht auf das exportierte
Dateisystem schreiben.</para>
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
<para>Damit ein Client auf ein exportiertes Dateisystem zugreifen
kann, muss ihm dies explizit gestattet werden. Stellen Sie also
sicher, dass der Client in <filename>/etc/exports</filename>
aufgeführt wird.</para>
<para>Jede Zeile in <filename>/etc/exports</filename> entspricht
der Exportinformation für ein Dateisystem auf einen
Rechner. Ein entfernter Rechner kann für jedes Dateisystem
nur einmal festgelegt werden, und kann auch nur einen
Standardeintrag haben. Nehmen wir an, dass
<filename>/usr</filename> ein einziges Dateisystem ist. Dann
wären folgende Zeilen ungültig:</para>
<programlisting>#Nicht erlaubt, wenn /usr ein einziges Dateisystem ist
/usr/src client
/usr/ports client</programlisting>
<para>Das Dateisystem <filename>/usr</filename> wird hier zweimal
auf den selben Rechner (<hostid>client</hostid>)
exportiert. Dies ist aber nicht zulässig. Der korrekte
Eintrag sieht daher so aus:</para>
<programlisting>/usr/src /usr/ports client</programlisting>
<para>Die Eigenschaften eines auf einen anderen Rechner
exportierten Dateisystems müssen alle in einer Zeile
stehen. Zeilen, in denen kein Rechner festgelegt wird, werden
als einzelner Rechner behandelt. Dies schränkt die
Möglichkeiten zum Export von Dateisystemen ein, für
die meisten Anwender ist dies aber kein Problem.</para>
<para>Eine gültige Exportliste, in der
<filename>/usr</filename> und <filename>/exports</filename>
lokale Dateisysteme sind, sieht so aus:</para>
<programlisting># Export src and ports to client01 and client02, but only
# client01 has root privileges on it
/usr/src /usr/ports -maproot=root client01
/usr/src /usr/ports client02
# The client machines have root and can mount anywhere
# on /exports. Anyone in the world can mount /exports/obj read-only
/exports -alldirs -maproot=root client01 client02
/exports/obj -ro</programlisting>
<para>Der Daemon <application>mountd</application> muss
die Datei <filename>/etc/exports</filename> nach jeder
Änderung neu einlesen, damit die Änderungen
wirksam werden. Dies kann durch das Senden des
HUP-Signals an den <command>mountd</command>-Prozess
erfolgen:</para>
<screen>&prompt.root; <userinput>kill -HUP `cat /var/run/mountd.pid`</userinput></screen>
<para>Alternativ können Sie das
<command>mountd</command>-&man.rc.8;-Skript auch mit dem
passenden Parameter aufrufen:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/mountd onereload</userinput></screen>
<para>Lesen Sie bitte <xref linkend="configtuning-rcd"/>
des Handbuchs für Informationen zum Einsatz der
rc-Skripte.</para>
<para>Eine weitere Möglichkeit, diese Änderungen zu
übernehmen, wäre der Neustart des Systems. Dies ist
allerdings nicht nötig. Wenn Sie die folgenden
Befehle als <username>root</username> ausführen, sollte
alles korrekt gestartet werden.</para>
<para>Auf dem <acronym>NFS</acronym>-Server:</para>
<screen>&prompt.root; <userinput>rpcbind</userinput>
&prompt.root; <userinput>nfsd -u -t -n 4</userinput>
&prompt.root; <userinput>mountd -r</userinput></screen>
<para>Auf dem <acronym>NFS</acronym>-Client:</para>
<screen>&prompt.root; <userinput>nfsiod -n 4</userinput></screen>
<para>Nun sollte alles bereit sein, um ein entferntes Dateisystem
einhängen zu können. In unseren Beispielen nennen wir
den Server <hostid>server</hostid>, den Client
<hostid>client</hostid>. Wenn Sie ein entferntes Dateisystem
nur zeitweise einhängen wollen, oder nur Ihre Konfiguration
testen möchten, führen Sie auf dem Client als
<username>root</username> einen Befehl ähnlich dem
folgenden aus:</para>
<indexterm>
<primary>NFS</primary>
<secondary>Dateisysteme einhängen</secondary>
</indexterm>
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
<para>Dadurch wird das Verzeichnis <filename>/home</filename> des
Servers auf dem Client unter <filename>/mnt</filename>
eingehängt. Wenn alles korrekt konfiguriert wurde, sehen
Sie auf dem Client im Verzeichnis <filename>/mnt</filename> alle
Dateien des Servers.</para>
<para>Wenn Sie ein entferntes Dateisystem nach jedem Systemstart
automatisch einhängen wollen, fügen Sie das
Dateisystem in <filename>/etc/fstab</filename> ein. Dazu ein
Beispiel:</para>
<programlisting>server:/home /mnt nfs rw 0 0</programlisting>
<para>Eine Beschreibung aller Optionen enthält
die Hilfeseite &man.fstab.5;.</para>
</sect2>
<sect2>
<title>Dateien sperren (<foreignphrase>Locking</foreignphrase>)</title>
<para>Einige Anwendungen (beispielsweise
<application>mutt</application>) erfordern die Sperrung von
Dateien, damit sie korrekt arbeiten. Verwenden Sie
<acronym>NFS</acronym>, so können Sie für die
Sperrung von Dateien <application>rpc.lockd</application>
einsetzen. Um diesen Daemon zu aktivieren, müssen Sie
in <filename>/etc/rc.conf</filename> (sowohl auf Client- als
auch auf Serverseite) folgende Zeilen aufnehmen (wobei
vorausgesetzt wird, dasss <acronym>NFS</acronym> auf beiden
Systemen bereits konfiguriert ist):</para>
<programlisting>rpc_lockd_enable="YES"
rpc_statd_enable="YES"</programlisting>
<para>Danach starten Sie die Anwendung zur Verwaltung der
Dateisperren durch folgenden Befehl:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/lockd start</userinput>
&prompt.root; <userinput>/etc/rc.d/statd start</userinput></screen>
<para>Benötigen Sie keine echten Dateisperren zwischen den
<acronym>NFS</acronym>-Clients und dem
<acronym>NFS</acronym>-Server, können Sie den
<acronym>NFS</acronym>-Client durch die Übergabe der
Option <option>-L</option> an &man.mount.nfs.8; zu einer lokalen
Sperrung von Dateien zwingen. Lesen Sie dazu auch die
Manualpage &man.mount.nfs.8;.</para>
</sect2>
<sect2>
<title>Praktische Anwendungen</title>
<para><acronym>NFS</acronym> ist in vielen Situationen
nützlich. Einige Anwendungsbereiche finden Sie in der
folgenden Liste:</para>
<indexterm>
<primary>NFS</primary>
<secondary>Anwendungsbeispiele</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para>Mehrere Maschinen können sich ein CD-ROM-Laufwerk
oder andere Medien teilen. Dies ist billiger und
außerdem praktischer, um Programme auf mehreren
Rechnern zu installieren.</para>
</listitem>
<listitem>
<para>In größeren Netzwerken ist es praktisch,
einen zentralen <acronym>NFS</acronym>-Server einzurichten,
auf dem die Heimatverzeichnisse der Benutzer gespeichert
werden. Diese Heimatverzeichnisse werden über das
Netzwerk exportiert. Dadurch haben die Benutzer immer das
gleiche Heimatverzeichnis zur Verfügung,
unabhängig davon, an welchem Arbeitsplatz sie sich
anmelden.</para>
</listitem>
<listitem>
<para>Verschiedene Rechner können auf ein gemeinsames
Verzeichnis <filename>/usr/ports/distfiles</filename>
zugreifen. Wenn Sie nun einen Port auf mehreren Rechnern
installieren wollen, greifen Sie einfach auf dieses
Verzeichnis zu, ohne die Quelldateien auf jede Maschine
zu kopieren.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="network-amd">
<sect2info>
<authorgroup>
<author>
<firstname>Wylie</firstname>
<surname>Stilwell</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Chern</firstname>
<surname>Lee</surname>
<contrib>Überarbeitet von </contrib>
</author>
</authorgroup>
</sect2info>
<title><application>AMD</application></title>
<indexterm><primary>amd</primary></indexterm>
<indexterm><primary>Automatic Mounter Daemon</primary></indexterm>
<para>&man.amd.8; (Automatic Mounter Daemon) hängt ein
entferntes Dateisystem automatisch ein,
wenn auf eine Datei oder ein Verzeichnis in diesem Dateisystem
zugegriffen wird. Dateisysteme, die über einen gewissen
Zeitraum inaktiv sind, werden von <application>amd</application>
automatisch abgehängt.
<application>amd</application> ist eine einfache
Alternative zum dauerhaften Einhängen von Dateisystemen
in <filename>/etc/fstab</filename>.</para>
<para>In der Voreinstellung stellt <application>amd</application>
die Verzeichnisse <filename>/host</filename> und
<filename>/net</filename> als NFS-Server bereit. Wenn auf eine
Datei in diesen Verzeichnissen zugegriffen wird, sucht
<application>amd</application> den entsprechenden Mountpunkt
und hängt das Dateisystem automatisch ein.
<filename>/net</filename> wird zum Einhängen von
exportierten Dateisystemen von einer IP-Adresse verwendet,
während <filename>/host</filename> zum Einhängen
von exportierten Dateisystemen eines durch seinen Namen
festgelegten Rechners dient.</para>
<para>Ein Zugriff auf eine Datei in
<filename>/host/foobar/usr</filename> würde
<application>amd</application> veranlassen,
das von <hostid>foobar</hostid> exportierte Dateisystem
<filename>/usr</filename> einzuhängen.</para>
<example>
<title>Ein exportiertes Dateisystem mit
<application>amd</application> in den Verzeichnisbaum
einhängen</title>
<para>Sie können sich die verfügbaren Mountpunkte
eines entfernten Rechners mit <command>showmount</command>
ansehen. Wollen Sie sich die Mountpunkte des Rechners
<hostid>foobar</hostid> ansehen, so verwenden Sie:</para>
<screen>&prompt.user; <userinput>showmount -e foobar</userinput>
Exports list on foobar:
/usr 10.10.10.0
/a 10.10.10.0
&prompt.user; <userinput>cd /host/foobar/usr</userinput></screen>
</example>
<para>Wie Sie an diesem Beispiel erkennen können, zeigt
<command>showmount</command> <filename>/usr</filename>
als exportiertes Dateisystem an. Wenn man in das Verzeichnis
<filename>/host/foobar/usr</filename> wechselt, versucht
<application>amd</application> den Rechnernamen
<hostid>foobar</hostid> aufzulösen und den gewünschten
Export in den Verzeichnisbaum einzuhängen.</para>
<para><application>amd</application> kann durch das Einfügen
der folgenden Zeile in <filename>/etc/rc.conf</filename>
automatisch gestartet werden:</para>
<programlisting>amd_enable="YES"</programlisting>
<para>Mit der Option <varname>amd_flags</varname> kann
<application>amd</application> angepasst werden.
Die Voreinstellung für <varname>amd_flags</varname> sieht
so aus:</para>
<programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"</programlisting>
<para><filename>/etc/amd.map</filename> legt die Standardoptionen
fest, mit denen exportierte Dateisysteme in den Verzeichnisbaum
eingehängt werden. <filename>/etc/amd.conf</filename>
hingegen legt einige der erweiterten Optionen von
<application>amd</application> fest.</para>
<para>Weitere Informationen finden Sie in den Hilfeseiten
&man.amd.8; und &man.amd.conf.5;.</para>
</sect2>
<sect2 id="network-nfs-integration">
<sect2info>
<authorgroup>
<author>
<firstname>John</firstname>
<surname>Lind</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
</sect2info>
<title>Integrationsprobleme mit anderen Systemen</title>
<para>Bestimmte ISA-Ethernetadapter haben Beschränkungen, die
zu ernsthaften Netzwerkproblemen, insbesondere mit NFS
führen können. Es handelt sich dabei nicht um ein
FreeBSD-spezifisches Problem, aber FreeBSD-Systeme sind davon
ebenfalls betroffen.</para>
<para>Das Problem tritt fast ausschließlich dann auf, wenn
(FreeBSD)-PC-Systeme mit Hochleistungsrechnern verbunden werden,
wie Systemen von Silicon Graphics, Inc. oder
Sun Microsystems, Inc. Das Einhängen via NFS
funktioniert problemlos, auch einige Dateioperationen
können erfolgreich sein. Plötzlich aber wird der
Server nicht mehr auf den Client reagieren, obwohl Anfragen von
anderen Rechnern weiterhin bearbeitet werden. Dieses
Problem betrifft stets den Client, egal ob es sich beim Client
um das FreeBSD-System oder den Hochleistungsrechner handelt.
Auf vielen Systemen gibt es keine Möglichkeit mehr, den
Client ordnungsgemäß zu beenden. Die einzige
Lösung ist es oft, den Rechner neu zu starten, da dieses
NFS-Problem nicht mehr behoben werden kann.</para>
<para>Die <quote>korrekte</quote> Lösung für dieses
Problem ist es, sich eine schnellere Ethernetkarte für
FreeBSD zu kaufen. Allerdings gibt es auch eine einfache und
meist zufriedenstellende Lösung, um dieses Problem zu
umgehen. Wenn es sich beim FreeBSD-System um den
<emphasis>Server</emphasis> handelt, verwenden Sie beim
Einhängen in den Verzeichnisbaum auf der Clientseite
zusätzlich die Option <option>-w=1024</option> . Wenn es
sich beim FreeBSD-System um den <emphasis>Client</emphasis>
handelt, dann hängen Sie das NFS-Dateisystem mit der
zusätzlichen Option <option>-r=1024</option> ein.
Diese Optionen können auf der Clientseite auch durch
das vierte Feld der Einträge in
<filename>/etc/fstab</filename> festgelegt werden, damit die
Dateisysteme automatisch eingehängt werden. Um die
Dateisysteme manuell einzuhängen, verwendet man bei
&man.mount.8; zusätzlich die Option
<option>-o</option>.</para>
<para>Es gibt ein anderes Problem, das oft mit diesem verwechselt
wird. Dieses andere Problem tritt auf, wenn sich über NFS
verbundene Server und Clients in verschiedenen Netzwerken
befinden. Wenn dies der Fall ist, stellen Sie
<emphasis>sicher</emphasis>, dass Ihre Router die
nötigen <acronym>UDP</acronym>-Informationen weiterleiten,
oder Sie werden nirgends hingelangen, egal was Sie machen.</para>
<para>In den folgenden Beispielen ist <hostid>fastws</hostid> der
Name des Hochleistungsrechners (bzw. dessen Schnittstelle),
<hostid>freebox</hostid> hingegen ist der Name des
FreeBSD-Systems, das über eine Netzkarte mit geringer
Leistung verfügt. <filename>/sharedfs</filename> ist das
exportierte NFS -Dateisystem (lesen Sie dazu auch
&man.exports.5;). Bei <filename>/project</filename> handelt es
sich um den Mountpunkt, an dem das exportierte Dateisystem auf
der Clientseite eingehängt wird. In allen Fällen
können zusätzliche Optionen, wie z.B.
<option>hard</option>, <option>soft</option> oder
<option>bg</option> wünschenswert sein.</para>
<para>FreeBSD als Client (eingetragen in
<filename>/etc/fstab</filename> auf <hostid>freebox</hostid>):
</para>
<programlisting>fastws:/sharedfs /project nfs rw,-r=1024 0 0</programlisting>
<para>Manuelles Einhängen auf
<hostid>freebox</hostid>:</para>
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
<para>&os; als Server (eingetragen in
<filename>/etc/fstab</filename> auf <hostid>fastws</hostid>):
</para>
<programlisting>freebox:/sharedfs /project nfs rw,-w=1024 0 0</programlisting>
<para>Manuelles Einhängen auf <hostid>fastws</hostid>:</para>
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
<para>Nahezu alle 16-bit Ethernetadapter erlauben Operationen
ohne obengenannte Einschränkungen auf die Lese- oder
Schreibgröße.</para>
<para>Für alle technisch Interessierten wird nun beschrieben,
was passiert, wenn dieser Fehler auftritt, und warum er
irreversibel ist. NFS arbeitet üblicherweise mit einer
<quote>Blockgröße</quote> von 8 kByte (obwohl
es kleinere Fragmente zulassen würde). Da die maximale
Rahmengröße von Ethernet 1500 Bytes
beträgt, wird der NFS-<quote>Block</quote> in einzelne
Ethernetrahmen aufgeteilt, obwohl es sich nach wie vor um eine
Einheit handelt, die auch als Einheit empfangen, verarbeitet
und <emphasis>bestätigt</emphasis> werden muss. Der
Hochleistungsrechner verschickt die Pakete, aus denen der
NFS-Block besteht, so eng hintereinander, wie es der Standard
erlaubt. Auf der anderen Seite (auf der sich die langsamere
Netzkarte befindet), überschreiben die späteren
Pakete ihre Vorgänger, bevor diese vom System verarbeitet
werden (Überlauf!). Dies hat zur Folge, dass der NFS-Block
nicht mehr rekonstruiert und bestätigt werden kann. Als
Folge davon glaubt der Hochleistungsrechner, dass der andere
Rechner nicht erreichbar ist (Timeout!) und versucht die
Sendung zu wiederholen. Allerdings wird wiederum der komplette
NFS-Block verschickt, so dass sich der ganze Vorgang wiederholt,
und zwar immer wieder (oder bis zum Systemneustart).</para>
<para>Indem wir die Einheitengröße unter der maximalen
Größe der Ethernetpakete halten, können wir
sicherstellen, dass jedes vollständig erhaltene
Ethernetpaket individuell angesprochen werden kann und vermeiden
die Blockierung des Systems.</para>
<para>Überläufe können zwar nach wie vor auftreten,
wenn ein Hochleistungsrechner Daten auf ein PC-System
transferiert. Durch die besseren (und schnelleren) Netzkarten
treten solche Überläufe allerdings nicht mehr
<emphasis>zwingend</emphasis> auf, wenn
NFS-<quote>Einheiten</quote> übertragen werden. Tritt nun
ein Überlauf auf, wird die betroffene Einheit erneut
verschickt, und es besteht eine gute Chance, dass sie nun
erhalten, verarbeitet und bestätigt werden kann.</para>
</sect2>
</sect1>
<sect1 id="network-nis">
<sect1info>
<authorgroup>
<author>
<firstname>Bill</firstname>
<surname>Swingle</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Eric</firstname>
<surname>Ogren</surname>
<contrib>Erweitert von </contrib>
</author>
<author>
<firstname>Udo</firstname>
<surname>Erdelhoff</surname>
</author>
</authorgroup>
</sect1info>
<title>NIS/YP – Network Information Service</title>
<sect2>
<title>Was ist NIS?</title>
<indexterm><primary>NIS</primary></indexterm>
<indexterm><primary>Solaris</primary></indexterm>
<indexterm><primary>HP-UX</primary></indexterm>
<indexterm><primary>AIX</primary></indexterm>
<indexterm><primary>Linux</primary></indexterm>
<indexterm><primary>NetBSD</primary></indexterm>
<indexterm><primary>OpenBSD</primary></indexterm>
<para><acronym role="Network Information Service">NIS</acronym>
wurde von Sun Microsystems entwickelt, um &unix;-Systeme
(ursprünglich &sunos;) zentral verwalten zu können.
Mittlerweile hat es sich zu einem Industriestandard entwickelt,
der von allen wichtigen &unix;-Systemen (&solaris;, HP-UX,
&aix;, Linux, NetBSD, OpenBSD, FreeBSD und anderen)
unterstützt wird.</para>
<indexterm>
<primary>yellow pages</primary>
<see>NIS</see>
</indexterm>
<para><acronym role="Network Information Service">NIS</acronym> war
ursprünglich als <emphasis>Yellow Pages</emphasis> bekannt,
aus markenrechtlichen Gründen wurde der Name aber
geändert. Die alte Bezeichnung (sowie die Abkürzung YP)
wird aber nach wie vor häufig verwendet.</para>
<indexterm>
<primary>NIS</primary>
<secondary>Domänen</secondary>
</indexterm>
<para>Bei NIS handelt es sich um ein RPC-basiertes
Client/Server-System. Eine Gruppe von Rechnern greift dabei
innerhalb einer NIS-Domäne auf gemeinsame
Konfigurationsdateien zu. Ein Systemadministrator wird dadurch
in die Lage versetzt, NIS-Clients mit minimalem Aufwand
einzurichten, sowie Änderungen an der Systemkonfiguration
von einem zentralen Ort aus durchzuführen.</para>
<indexterm>
<primary>Windows NT</primary>
</indexterm>
<para>Die Funktion entspricht dem Domänensystem von
&windowsnt;; auch wenn sich die interne Umsetzung unterscheidet,
sind die Basisfunktionen vergleichbar.</para>
</sect2>
<sect2>
<title>Wichtige Prozesse und Begriffe</title>
<para>Es gibt verschiedene Begriffe und Anwenderprozesse, auf die
Sie stoßen werden, wenn Sie NIS unter FreeBSD einrichten,
egal ob Sie einen Server oder einen Client konfigurieren:</para>
<indexterm>
<primary><application>rpcbind</application></primary>
</indexterm>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<colspec colwidth="1*"/>
<colspec colwidth="3*"/>
<thead>
<row>
<entry>Begriff</entry>
<entry>Beschreibung</entry>
</row>
</thead>
<tbody>
<row>
<entry>NIS-Domänenname</entry>
<entry>Ein NIS-Masterserver sowie alle Clients
(inklusive der Slaveserver) haben einen
NIS-Domänennamen. Dieser hat (ähnlich den
&windowsnt;-Domänennamen) nichts mit DNS zu tun.
</entry>
</row>
<row>
<entry><application>rpcbind</application></entry>
<entry>Muss laufen, damit RPC (Remote Procedure Call, ein
von NIS verwendetes Netzwerkprotokoll) funktioniert.
NIS-Server sowie Clients funktionieren ohne
<application>rpcbind</application> nicht.</entry>
</row>
<row>
<entry><application>ypbind</application></entry>
<entry><quote>Bindet</quote> einen NIS-Client an seinen
NIS-Server. Der Client bezieht den
NIS-Domänennamen vom System und stellt über
das RPC-Protokoll eine Verbindung zum NIS-Server her.
<application>ypbind</application> ist der zentrale
Bestandteil der Client-Server-Kommunikation in einer
NIS-Umgebung. Wird <application>>ypbind</application>
auf einem Client beendet, ist dieser nicht mehr in der
Lage, auf den NIS-Server zuzugreifen.</entry>
</row>
<row>
<entry><application>ypserv</application></entry>
<entry>Sollte nur auf dem NIS-Server laufen, da es sich um
den Serverprozess selbst handelt. Wenn &man.ypserv.8;
nicht mehr läuft, kann der Server nicht mehr auf
NIS-Anforderungen reagieren (wenn ein Slaveserver
existiert, kann dieser als Ersatz fungieren). Einige
NIS-Systeme (allerdings nicht das von FreeBSD) versuchen
allerdings erst gar nicht, sich mit einem anderen Server
zu verbinden, wenn der bisher verwendete Server nicht
mehr reagiert. Die einzige Lösung dieses Problems
besteht dann darin, den Serverprozess (oder gar den
Server selbst) oder den
<application>ypbind</application>-Prozess auf dem Client
neu zu starten.</entry>
</row>
<row>
<entry><application>rpc.yppasswdd</application></entry>
<entry>Ein weiterer Prozess, der nur auf dem
NIS-Masterserver laufen sollte. Es handelt sich um einen
Daemonprozess, der es NIS-Clients ermöglicht, sich
auf dem NIS-Masterserver anzumelden, um ihr Passwort zu
ändern.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<!-- XXX Missing: rpc.ypxfrd (not important, though) May only run
on the master -->
</sect2>
<sect2>
<title>Wie funktioniert NIS?</title>
<para>In einer NIS-Umgebung gibt es drei Rechnerarten:
Masterserver, Slaveserver und Clients. Server dienen als
zentraler Speicherort für Rechnerkonfigurationen.
Masterserver speichern die maßgebliche Kopie dieser
Informationen, während Slaveserver diese Informationen
aus Redundanzgründen spiegeln. Die Clients beziehen
ihre Informationen immer vom Server.</para>
<para>Auf diese Art und Weise können Informationen aus
verschiedenen Dateien von mehreren Rechnern gemeinsam
verwendet werden. <filename>master.passwd</filename>,
<filename>group</filename>, und <filename>hosts</filename>
werden oft gemeinsam über NIS verwendet. Immer, wenn
ein Prozess auf einem Client auf Informationen zugreifen will,
die normalerweise in lokalen Dateien vorhanden wären,
wird stattdessen eine Anfrage an den NIS-Server gestellt, an
den der Client gebunden ist.</para>
<sect3>
<title>Arten von NIS-Rechnern</title>
<itemizedlist>
<listitem>
<indexterm>
<primary>NIS</primary>
<secondary>Masterserver</secondary>
</indexterm>
<para>Ein <emphasis>NIS-Masterserver</emphasis> verwaltet,
ähnlich einem &windowsnt;-Domänencontroller, die
von allen NIS-Clients gemeinsam verwendeten Dateien.
<filename>passwd</filename>, <filename>group</filename>,
sowie verschiedene andere von den Clients verwendete
Dateien existieren auf dem Masterserver.</para>
<note><para>Ein Rechner kann auch für mehrere
NIS-Domänen als Masterserver fungieren. Dieser
Abschnitt konzentriert sich im Folgenden allerdings auf
eine relativ kleine NIS-Umgebung.</para></note>
</listitem>
<listitem>
<indexterm>
<primary>NIS</primary>
<secondary>Slaveserver</secondary>
</indexterm>
<para><emphasis>NIS-Slaveserver</emphasis>. Ähnlich
einem &windowsnt;-Backupdomänencontroller, verwalten
NIS-Slaveserver Kopien der Daten des NIS-Masterservers.
NIS-Slaveserver bieten die Redundanz, die für
kritische Umgebungen benötigt wird. Zusätzlich
entlasten Slaveserver den Masterserver: NIS-Clients
verbinden sich immer mit dem NIS-Server, der zuerst
reagiert. Dieser Server kann auch ein Slaveserver sein.
</para>
</listitem>
<listitem>
<indexterm>
<primary>NIS</primary>
<secondary>Client</secondary>
</indexterm>
<para><emphasis>NIS-Clients</emphasis>. NIS-Clients
identifizieren sich gegenüber dem NIS-Server
(ähnlich den &windowsnt;-Workstations), um sich am
Server anzumelden.</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2>
<title>NIS/YP konfigurieren</title>
<para>Dieser Abschnitt beschreibt an Hand eines Beispiels die
Einrichtung einer NIS-Umgebung.</para>
<sect3>
<title>Planung</title>
<para>Nehmen wir an, Sie seien der Administrator eines kleinen
Universitätsnetzes. Dieses Netz besteht aus
fünfzehn FreeBSD-Rechnern, für die derzeit keine
zentrale Verwaltung existiert, jeder Rechner hat also eine
eigene Version von <filename>/etc/passwd</filename> und
<filename>/etc/master.passwd</filename>. Diese Dateien werden
manuell synchron gehalten; legen Sie einen neuen Benutzer an,
so muss dies auf allen fünfzehn Rechnern manuell
erledigt werden (unter Verwendung von
<command>adduser</command>). Da diese Lösung sehr
ineffizient ist, soll das Netzwerk in Zukunft NIS verwenden,
wobei zwei der Rechner als Server dienen sollen.</para>
<para>In Zukunft soll das Netz also wie folgt aussehen:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="3">
<thead>
<row>
<entry>Rechnername</entry>
<entry>IP-Adresse</entry>
<entry>Rechneraufgabe</entry>
</row>
</thead>
<tbody>
<row>
<entry><hostid>ellington</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.2</hostid></entry>
<entry>NIS-Master</entry>
</row>
<row>
<entry><hostid>coltrane</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.3</hostid></entry>
<entry>NIS-Slave</entry>
</row>
<row>
<entry><hostid>basie</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.4</hostid></entry>
<entry>Workstation der Fakultät</entry>
</row>
<row>
<entry><hostid>bird</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.5</hostid></entry>
<entry>Clientrechner</entry>
</row>
<row>
<entry><hostid>cli[1-11]</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.[6-17]</hostid></entry>
<entry>Verschiedene andere Clients</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Wenn Sie NIS das erste Mal einrichten, ist es ratsam, sich
zuerst über die Vorgangsweise Gedanken zu machen.
Unabhängig von der Größe Ihres Netzwerks
müssen Sie stets einige Entscheidungen treffen.</para>
<sect4>
<title>Einen NIS-Domänennamen wählen</title>
<indexterm>
<primary>NIS</primary>
<secondary>Domänenname</secondary>
</indexterm>
<para>Dies muss nicht der <quote>Domainname</quote> sein. Es
handelt sich vielmehr um den <quote>NIS-Domainnamen</quote>.
Wenn ein Client Informationen anfordert, ist in dieser
Anforderung der Name der NIS-Domäne enthalten.
Dadurch weiß jeder Server im Netzwerk, auf welche
Anforderung er antworten muss. Stellen Sie sich den
NIS-Domänennamen als den Namen einer Gruppe von
Rechnern vor, die etwas gemeinsam haben.</para>
<para>Manchmal wird der Name der Internetdomäne auch
für die NIS-Domäne verwendet. Dies ist allerdings
nicht empfehlenswert, da dies bei der Behebung von Problemen
verwirrend sein kann. Der Name der NIS-Domäne sollte
innerhalb Ihres Netzwerks einzigartig sein. Hilfreich ist
es, wenn der Name die Gruppe der in ihr zusammengefassten
Rechner beschreibt. Die Kunstabteilung von Acme Inc.
hätte daher die NIS-Domäne
<quote>acme-art</quote>. Für unser Beispiel verwenden
wir den NIS-Domänennamen
<literal>test-domain</literal>.</para>
<indexterm><primary>SunOS</primary></indexterm>
<para>Es gibt jedoch auch Betriebssysteme (vor allem &sunos;),
die als NIS-Domänennamen den Name der
Internetdomäne verwenden. Wenn dies für einen
oder mehrere Rechner Ihres Netzwerks zutrifft,
<emphasis>müssen</emphasis> Sie den Namen der
Internetdomäne als Ihren NIS-Domänennamen
verwenden.</para>
</sect4>
<sect4>
<title>Anforderungen an den Server</title>
<para>Wenn Sie einen NIS-Server einrichten wollen, müssen
Sie einige Dinge beachten. Eine unangenehme Eigenschaft
von NIS ist die Abhängigkeit der Clients vom Server.
Wenn sich der Client nicht über den Server mit seiner
NIS-Domäne verbinden kann, wird der Rechner oft
unbenutzbar, da das Fehlen von Benutzer- und
Gruppeninformationen zum Einfrieren des Clients führt.
Daher sollten Sie für den Server einen Rechner
auswählen, der nicht regelmäßig neu
gestartet werden muss und der nicht für Testversuche
verwendet wird. Idealerweise handelt es sich um einen
alleinstehenden Rechner, dessen einzige Aufgabe es ist, als
NIS-Server zu dienen. Wenn Sie ein Netzwerk haben, das
nicht zu stark ausgelastet ist, ist es auch möglich,
den NIS-Server als weiteren Dienst auf einem anderen Rechner
laufen zu lassen. Denken Sie aber daran, dass ein Ausfall
des NIS-Servers <emphasis>alle</emphasis> NIS-Clients
betrifft.</para>
</sect4>
</sect3>
<sect3>
<title>NIS-Server</title>
<para>Die verbindlichen Kopien aller NIS-Informationen befinden
sich auf einem einzigen Rechner, dem NIS-Masterserver. Die
Datenbanken, in denen die Informationen gespeichert sind,
bezeichnet man als NIS-Maps. Unter FreeBSD werden diese
Maps unter <filename>/var/yp/[domainname]</filename>
gespeichert, wobei <filename>[domainname]</filename> der
Name der NIS-Domäne ist. Ein einzelner NIS-Server
kann gleichzeitig mehrere NIS-Domänen verwalten, daher
können auch mehrere Verzeichnisse vorhanden sein. Jede
Domäne verfügt über ein eigenes Verzeichnis
sowie einen eigenen, von anderen Domänen
unabhängigen Satz von NIS-Maps.</para>
<para>NIS-Master- und Slaveserver verwenden den
<command>ypserv</command>-Daemon, um NIS-Anfragen zu
bearbeiten. <command>ypserv</command> empfängt
eingehende Anfragen der NIS-Clients, ermittelt aus der
angeforderten Domäne und Map einen Pfad zur
entsprechenden Datenbank, und sendet die angeforderten
Daten von der Datenbank zum Client.</para>
<sect4>
<title>Einen NIS-Masterserver einrichten</title>
<indexterm>
<primary>NIS</primary>
<secondary>Serverkonfiguration</secondary>
</indexterm>
<para>Abhängig von Ihren Anforderungen ist die
Einrichtung eines NIS-Masterservers relativ einfach, da
NIS von FreeBSD bereits in der Standardkonfiguration
unterstützt wird. Sie müssen nur folgende
Zeilen in <filename>/etc/rc.conf</filename> einfügen:
</para>
<procedure>
<step>
<programlisting>nisdomainname="test-domain"</programlisting>
<para>Diese Zeile setzt den NIS-Domänennamen auf
<literal>test-domain</literal>, wenn Sie das Netzwerk
initialisieren (beispielsweise nach einem Systemstart).
</para>
</step>
<step>
<para><programlisting>nis_server_enable="YES"</programlisting>
Dadurch werden die NIS-Serverprozesse gestartet.</para>
</step>
<step>
<para><programlisting>nis_yppasswdd_enable="YES"</programlisting>
Durch diese Zeile wird der
<command>rpc.yppasswdd</command>-Daemon aktiviert, der,
wie bereits erwähnt, die Änderung von
NIS-Passwörtern von einem Client aus
ermöglicht.</para>
</step>
</procedure>
<note>
<para>In Abhängigkeit von Ihrer NIS-Konfiguration
können weitere Einträge erforderlich sein.
Weitere Informationen finden Sie im Abschnitt
<link linkend="nis-server-is-client">NIS-Server, die
auch als NIS-Clients arbeiten</link>.</para>
</note>
<para>Nachdem Sie obige Parameter konfiguriert haben, müssen
Sie nur noch <command>/etc/netstart</command> als Superuser
ausführen, um alles entsprechend Ihren Vorgaben in der
Datei <filename>/etc/rc.conf</filename> einzurichten.
Bevor Sie die NIS-Maps einrichten können, müssen Sie
nun noch den <application>ypserv</application>-Daemon
manuell starten:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/ypserv start</userinput></screen>
</sect4>
<sect4>
<title>Die NIS-Maps initialisieren</title>
<indexterm>
<primary>NIS</primary>
<secondary>maps</secondary>
</indexterm>
<para><emphasis>NIS-Maps</emphasis> sind Datenbanken, die
sich im Verzeichnis <filename>/var/yp</filename> befinden.
Sie werden am NIS-Masterserver aus den Konfigurationsdateien
unter <filename>/etc</filename> erzeugt. Einzige Ausnahme:
<filename>/etc/master.passwd</filename>. Dies ist auch
sinnvoll, da Sie die Passwörter für Ihr
<username>root</username>- oder andere
Administratorkonten nicht an alle Server der NIS-Domäne
verteilen wollen. Bevor Sie also die NIS-Maps des
Masterservers einrichten, sollten Sie Folgendes tun:</para>
<screen>&prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>vi master.passwd</userinput></screen>
<para>Entfernen Sie alle Systemkonten
(wie <username>bin</username>, <username>tty</username>,
<username>kmem</username> oder <username>games</username>),
sowie alle Konten, die Sie nicht an die NIS-Clients
weitergeben wollen (beispielsweise <username>root</username>
und alle Konten mit der UID 0 (=Superuser).</para>
<note><para>Stellen Sie sicher, dass
<filename>/var/yp/master.passwd</filename> weder von der
Gruppe noch von der Welt gelesen werden kann (Zugriffsmodus
600)! Ist dies nicht der Fall, ändern Sie dies mit
<command>chmod</command>.</para></note>
<indexterm><primary>Tru64 UNIX</primary></indexterm>
<para>Nun können Sie die NIS-Maps initialisieren.
FreeBSD verwendet dafür das Skript
<command>ypinit</command> (lesen Sie dazu auch
&man.ypinit.8;). Dieses Skript ist auf fast allen
UNIX-Betriebssystemen verfügbar. Bei
Digitals Unix/Compaq Tru64 UNIX nennt es sich allerdings
<command>ypsetup</command>. Da wir Maps für einen
NIS-Masterserver erzeugen, verwenden wir
<command>ypinit</command> mit der Option
<option>-m</option>. Nachdem Sie die beschriebenen
Aktionen durchgeführt haben, erzeugen Sie nun die
NIS-Maps:</para>
<screen>ellington&prompt.root; <userinput>ypinit -m test-domain</userinput>
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] <userinput>n</userinput>
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
master server : ellington
next host to add: <userinput>coltrane</userinput>
next host to add: <userinput>^D</userinput>
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct? [y/n: y] <userinput>y</userinput>
[..output from map generation..]
NIS Map update completed.
ellington has been setup as an YP master server without any errors.</screen>
<para>Dadurch erzeugt <command>ypinit</command>
<filename>/var/yp/Makefile</filename> aus der Datei
<filename>/var/yp/Makefile.dist</filename>.
Durch diese Datei wird festgelegt, dass Sie in einer
NIS-Umgebung mit nur einem Server arbeiten und dass alle
Clients unter FreeBSD laufen. Da
<literal>test-domain</literal> aber auch über einen
Slaveserver verfügt, müssen Sie
<filename>/var/yp/Makefile</filename> entsprechend anpassen:
</para>
<screen>ellington&prompt.root; <userinput>vi /var/yp/Makefile</userinput></screen>
<para>Sie sollten die Zeile</para>
<programlisting>NOPUSH = "True"</programlisting>
<para>auskommentieren (falls dies nicht bereits der Fall ist).</para>
</sect4>
<sect4>
<title>Einen NIS-Slaveserver einrichten</title>
<indexterm>
<primary>NIS</primary>
<secondary>Slaveserver</secondary>
</indexterm>
<para>Ein NIS-Slaveserver ist noch einfacher einzurichten als
ein Masterserver. Melden Sie sich am Slaveserver an und
ändern Sie <filename>/etc/rc.conf</filename> analog
zum Masterserver. Der einzige Unterschied besteht in der
Verwendung der Option <option>-s</option>, wenn Sie
<command>ypinit</command> aufrufen. Die Option
<option>-s</option> erfordert den Namen des
NIS-Masterservers, daher sieht unsere Ein- und Ausgabe wie
folgt aus:</para>
<screen>coltrane&prompt.root; <userinput>ypinit -s ellington test-domain</userinput>
Server Type: SLAVE Domain: test-domain Master: ellington
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] <userinput>n</userinput>
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred
coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.</screen>
<para>Sie sollten nun über das Verzeichnis
<filename>/var/yp/test-domain</filename> verfügen.
Die Kopien der NIS-Masterserver-Maps sollten sich in diesem
Verzeichnis befinden. Allerdings müssen Sie diese
auch aktuell halten. Die folgenden Einträge in
<filename>/etc/crontab</filename> erledigen diese Aufgabe:
</para>
<programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname
21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting>
<para>Diese zwei Zeilen zwingen den Slaveserver, seine Maps
mit denen des Masterservers zu synchronisieren. Diese
Einträge sind nicht zwar nicht unbedingt nötig,
da der Masterserver automatisch versucht, alle
Änderungen seiner NIS-Maps an seine
Slaveserver weiterzugeben. Da Passwortinformationen aber
auch für nur vom Slaveserver abhängige Systeme
vital sind,
ist es eine gute Idee, diese Aktualisierungen zu erzwingen.
Besonders wichtig ist dies in stark ausgelasteten Netzen,
in denen Map-Aktualisierungen unvollständig sein
könnten.</para>
<para>Führen Sie nun <command>/etc/netstart</command>
auch auf dem Slaveserver aus, um den NIS-Server erneut zu
starten.</para>
</sect4>
</sect3>
<sect3>
<title>NIS-Clients</title>
<para>Ein NIS-Client <literal>bindet</literal> sich unter
Verwendung des <command>ypbind</command>-Daemons an einen
NIS-Server. <command>ypbind</command> prüft die
Standarddomäne des Systems (die durch
<command>domainname</command> gesetzt wird), und beginnt
RPCs über das lokale Netzwerk zu verteilen (broadcast).
Diese Anforderungen legen den Namen der Domäne fest,
für die <command>ypbind</command> eine Bindung erzeugen
will. Wenn der Server der entsprechenden Domäne eine
solche Anforderung erhält, schickt er eine Antwort an
<command>ypbind</command>. <command>ybind</command> speichert
daraufhin die Adresse des Servers. Wenn mehrere Server
verfügbar sind (beispielsweise ein Master- und mehrere
Slaveserver), verwendet <command>ypbind</command> die erste
erhaltene Adresse. Ab diesem Zeitpunkt richtet der Client alle
Anfragen an genau diesen Server. <command>ypbind</command>
<quote>pingt</quote> den Server gelegentlich an, um
sicherzustellen, dass der Server funktioniert. Antwortet der
Server innerhalb eines bestimmten Zeitraums nicht (Timeout),
markiert <command>ypbind</command> die Domäne als
ungebunden und beginnt erneut, RPCs über das Netzwerk zu
verteilen, um einen anderen Server zu finden.</para>
<sect4>
<title>Einen NIS-Client konfigurieren</title>
<indexterm>
<primary>NIS</primary>
<secondary>Client konfigurieren</secondary>
</indexterm>
<para>Einen FreeBSD-Rechner als NIS-Client einzurichten, ist
recht einfach.</para>
<procedure>
<step>
<para>Fügen Sie folgende Zeilen in
<filename>/etc/rc.conf</filename> ein, um den
NIS-Domänennamen festzulegen, und um
<command>ypbind</command> bei der Initialisierung des
Netzwerks zu starten:</para>
<programlisting>nisdomainname="test-domain"
nis_client_enable="YES"</programlisting>
</step>
<step>
<para>Um alle Passworteinträge des NIS-Servers zu
importieren, löschen Sie alle Benutzerkonten in
<filename>/etc/master.passwd</filename> und fügen
mit <command>vipw</command> folgende Zeile am Ende der
Datei ein:</para>
<programlisting>+:::::::::</programlisting>
<note>
<para>Diese Zeile legt für alle gültigen
Benutzerkonten der NIS-Server-Maps einen Zugang an.
Es gibt verschiedene Wege, Ihren NIS-Client durch
Änderung dieser Zeile zu konfigurieren. Lesen
Sie dazu auch den Abschnitt über
<link linkend="netgroups">Netzgruppen</link> weiter
unten. Weitere detaillierte Informationen finden Sie
im Buch <literal>Managing NFS and NIS</literal> von
O'Reilly.</para>
</note>
<note>
<para>Sie sollten zumindest ein lokales Benutzerkonto,
das nicht über NIS importiert wird, in Ihrer
<filename>/etc/master.passwd</filename> behalten.
Dieser Benutzer sollte außerdem ein Mitglied der
Gruppe <groupname>wheel</groupname> sein. Wenn es
mit NIS Probleme gibt, können Sie diesen Zugang
verwenden, um sich anzumelden,
<username>root</username> zu werden und das Problem
zu beheben.</para>
</note>
</step>
<step>
<para>Um alle möglichen Gruppeneinträge vom
NIS-Server zu importieren, fügen sie folgende Zeile
in <filename>/etc/group</filename> ein:</para>
<programlisting>+:*::</programlisting>
</step>
</procedure>
<para>Um den NIS-Client sofort zu starten, führen Sie als
Superuser die folgenden Befehle aus:</para>
<screen>&prompt.root; <userinput>/etc/netstart</userinput>
&prompt.root; <userinput>/etc/rc.d/ypbind start</userinput></screen>
<para>Nachdem Sie diese Schritte erledigt haben, sollten Sie
mit <command>ypcat passwd</command> die
<literal>passwd-Map</literal> des NIS-Servers anzeigen
können.</para>
</sect4>
</sect3>
</sect2>
<sect2>
<title>Sicherheit unter NIS</title>
<indexterm>
<primary>NIS</primary>
<secondary>Sicherheit</secondary>
</indexterm>
<para>Im Allgemeinen kann jeder entfernte Anwender einen RPC an
&man.ypserv.8; schicken, um den Inhalt Ihrer NIS-Maps abzurufen,
falls er Ihren NIS-Domänennamen kennt. Um solche
unautorisierten Transaktionen zu verhindern, unterstützt
&man.ypserv.8; <quote>securenets</quote>, durch die man den
Zugriff auf bestimmte Rechner beschränken kann.
&man.ypserv.8; versucht, beim Systemstart die Informationen
über <literal>securenets</literal> aus der Datei
<filename>/var/yp/securenets</filename> zu laden.</para>
<note>
<para>Die Datei <filename>securenets</filename> kann auch
in einem anderen Verzeichnis stehen, das mit der Option
<option>-p</option> angegeben wird. Diese Datei
enthält Einträge, die aus einer Netzwerkadresse und
einer Netzmaske bestehen, die durch Leerzeichen getrennt
werden. Kommentarzeilen beginnen mit <quote>#</quote>.
<filename>/var/yp/securnets</filename> könnte
beispielsweise so aussehen:</para>
</note>
<programlisting># allow connections from local host -- mandatory
127.0.0.1 255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
# this includes the machines in the testlab
10.0.0.0 255.255.240.0</programlisting>
<para>Wenn &man.ypserv.8; eine Anforderung von einer zu diesen
Regeln passenden Adresse erhält, wird die Anforderung
bearbeitet. Gibt es keine passende Regel, wird die
Anforderung ignoriert und eine Warnmeldung aufgezeichnet. Wenn
<filename>/var/yp/securenets</filename> nicht vorhanden ist,
erlaubt <command>ypserv</command> Verbindungen von jedem Rechner
aus.</para>
<para><command>ypserv</command> unterstützt auch das
<application>TCP-Wrapper</application>-Paket von Wietse Venema.
Mit diesem Paket kann der Administrator für
Zugriffskontrollen die Konfigurationsdateien von
<application>TCP-Wrapper</application> anstelle von
<filename>/var/yp/securenets</filename> verwenden.</para>
<note>
<para>Während beide Kontrollmechanismen einige Sicherheit
gewähren, beispielsweise durch privilegierte Ports, sind
sie gegenüber <quote>IP spoofing</quote>-Attacken
verwundbar. Jeder NIS-Verkehr sollte daher von Ihrer Firewall
blockiert werden.</para>
<para>Server, die <filename>/var/yp/securenets</filename>
verwenden, können Schwierigkeiten bei der Anmeldung von
Clients haben, die ein veraltetes TCP/IP-Subsystem
besitzen. Einige dieser TCP/IP-Subsysteme setzen alle
Rechnerbits auf Null, wenn Sie einen
<literal>Broadcast</literal> durchführen und/oder
können die Subnetzmaske nicht auslesen, wenn sie die
Broadcast-Adresse berechnen. Einige Probleme können
durch Änderungen der Clientkonfiguration behoben werden.
Andere hingegen lassen sich nur durch das Entfernen des
betreffenden Rechners aus dem Netzwerk oder den Verzicht auf
<filename>/var/yp/securenets</filename> umgehen.</para>
<para>Die Verwendung von <filename>/var/yp/securenets</filename>
auf einem Server mit einem solch veralteten
TCP/IP-Subsystem ist eine sehr schlechte Idee, die zu
einem Verlust der NIS-Funktionalität für große
Teile Ihres Netzwerks führen kann.</para>
<indexterm>
<primary>TCP-Wrapper</primary>
</indexterm>
<para>Die Verwendung der <application>TCP-Wrapper</application>
verlangsamt die Reaktion Ihres NIS-Servers. Diese
zusätzliche Reaktionszeit kann in Clientprogrammen zu
Timeouts führen. Dies vor allem in Netzwerken, die
stark ausgelastet sind, oder nur über langsame NIS-Server
verfügen. Wenn ein oder mehrere Ihrer Clientsysteme
dieses Problem aufweisen, sollten Sie die betreffenden Clients
in NIS-Slaveserver umwandeln, und diese an sich selbst binden.
</para>
</note>
</sect2>
<sect2>
<title>Bestimmte Benutzer an der Anmeldung hindern</title>
<indexterm>
<primary>NIS</primary>
<secondary>Benutzer blockieren</secondary>
</indexterm>
<para>In unserem Labor gibt es den Rechner <hostid>basie</hostid>,
der nur für Mitarbeiter der Fakultät bestimmt ist.
Wir wollen diesen Rechner nicht aus der NIS-Domäne
entfernen, obwohl <filename>passwd</filename> des
NIS-Masterservers Benutzerkonten sowohl für
Fakultätsmitarbeiter als auch für Studenten
enthält. Was können wir also tun?</para>
<para>Es gibt eine Möglichkeit, bestimmte Benutzer an der
Anmeldung an einem bestimmten Rechner zu hindern, selbst wenn
diese in der NIS-Datenbank vorhanden sind. Dazu müssen
Sie lediglich an diesem Rechner den Eintrag
<literal>-<replaceable>Benutzername</replaceable></literal> an
das Ende von <filename>/etc/master.passwd</filename> setzen,
wobei <replaceable>Benutzername</replaceable> der zu
blockierende Benutzername ist. Diese Änderung sollte
bevorzugt durch <command>vipw</command> erledigt werden, da
<command>vipw</command> Ihre Änderungen an
<filename>/etc/master.passwd</filename> auf Plausibilität
überprüft und nach erfolgter Änderung die
Passwortdatenbank automatisch aktualisiert. Um also den
Benutzer <username>bill</username> an der Anmeldung am Rechner
<hostid>basie</hostid> zu hindern, gehen wir wie folgt vor:
</para>
<screen>basie&prompt.root; <userinput>vipw</userinput>
<userinput>[add -bill to the end, exit]</userinput>
vipw: rebuilding the database...
vipw: done
basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>
root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5::0:0:System &:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+:::::::::
-bill
basie&prompt.root;</screen>
</sect2>
<sect2 id="netgroups">
<sect2info>
<authorgroup>
<author>
<firstname>Udo</firstname>
<surname>Erdelhoff</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
</sect2info>
<title>Netzgruppen verwenden</title>
<indexterm><primary>Netzgruppen</primary></indexterm>
<para>Die im letzten Abschnitt beschriebene Methode eignet sich
besonders, wenn Sie spezielle Regeln für wenige
Benutzer oder wenige Rechner benötigen. In großen
Netzwerken werden Sie allerdings
<emphasis>mit Sicherheit</emphasis> vergessen, einige Benutzer
von der Anmeldung an bestimmten Rechnern auszuschließen.
Oder Sie werden gezwungen sein, jeden Rechner einzeln zu
konfigurieren. Dadurch verlieren Sie aber den Hauptvorteil von
NIS, die <emphasis>zentrale</emphasis> Verwaltung.</para>
<para>Die Lösung für dieses Problem sind
<emphasis>Netzgruppen</emphasis>. Ihre Aufgabe und Bedeutung
ist vergleichbar mit normalen, von UNIX-Dateisystemen
verwendeten Gruppen. Die Hauptunterschiede sind das Fehlen
einer numerischen ID sowie die Möglichkeit, Netzgruppen
zu definieren, die sowohl Benutzer als auch andere Netzgruppen
enthalten.</para>
<para>Netzgruppen wurden entwickelt, um große, komplexe
Netzwerke mit Hunderten Benutzern und Rechnern zu verwalten.
Sie sind also von Vorteil, wenn Sie von dieser Situation
betroffen sind. Andererseits ist es dadurch beinahe
unmöglich, Netzgruppen mit einfachen Beispielen zu
erklären. Das hier verwendete Beispiel veranschaulicht
dieses Problem.</para>
<para>Nehmen wir an, dass Ihre erfolgreiche Einführung von
NIS die Aufmerksamkeit Ihrer Vorgesetzten geweckt hat. Ihre
nächste Aufgabe besteht nun darin, Ihre NIS-Domäne
um zusätzliche Rechner zu erweitern. Die folgenden
Tabellen enthalten die neuen Benutzer und Rechner inklusive
einer kurzen Beschreibung.</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>Benutzername(n)</entry>
<entry>Beschreibung</entry>
</row>
</thead>
<tbody>
<row>
<entry><username>alpha</username>,
<username>beta</username></entry>
<entry>Beschäftigte der IT-Abteilung</entry>
</row>
<row>
<entry><username>charlie</username>,
<username>delta</username></entry>
<entry>Die neuen Lehrlinge der IT-Abteilung</entry>
</row>
<row>
<entry><username>echo</username>,
<username>foxtrott</username>,
<username>golf</username>, ...</entry>
<entry>Normale Mitarbeiter</entry>
</row>
<row>
<entry><username>able</username>,
<username>baker</username>, ...</entry>
<entry>Externe Mitarbeiter</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>Rechnername(n)</entry>
<entry>Beschreibung</entry>
</row>
</thead>
<tbody>
<row>
<!-- Names taken from "Good Omens" by Neil Gaiman and Terry
Pratchett. Many thanks for a brilliant book. -->
<entry><hostid>war</hostid>, <hostid>death</hostid>,
<hostid>famine</hostid>, <hostid>pollution</hostid></entry>
<entry>Ihre wichtigsten Server. Nur IT-Fachleute
dürfen sich an diesen Rechnern anmelden.</entry>
</row>
<row>
<!-- gluttony was omitted because it was too fat -->
<entry><hostid>pride</hostid>, <hostid>greed</hostid>,
<hostid>envy</hostid>, <hostid>wrath</hostid>,
<hostid>lust</hostid>, <hostid>sloth</hostid></entry>
<entry>Weniger wichtige Server. Alle Mitarbeiter der
IT-Abteilung dürfen sich auf diesen Rechnern
anmelden.</entry>
</row>
<row>
<entry><hostid>one</hostid>, <hostid>two</hostid>,
<hostid>three</hostid>, <hostid>four</hostid>, ...</entry>
<entry>Gewöhnliche Arbeitsrechner. Nur die
<emphasis>wirklichen</emphasis> Mitarbeiter dürfen
diese Rechner verwenden.</entry>
</row>
<row>
<entry><hostid>trashcan</hostid></entry>
<entry>Ein sehr alter Rechner ohne kritische Daten. Sogar
externe Mitarbeiter dürfen diesen Rechner
verwenden.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Wollten Sie diese Einschränkungen umsetzen, indem Sie
jeden Benutzer einzeln blockieren, müssten Sie auf jedem
System für jeden Benutzer eine entsprechende Zeile in
<filename>passwd</filename> einfügen. Wenn Sie nur einen
Eintrag vergessen, haben Sie ein Problem. Es mag noch angehen,
dies während der ersten Installation zu erledigen, im
täglichen Betrieb werden Sie allerdings
<emphasis>mit Sicherheit</emphasis> einmal vergessen, die
entsprechenden Einträge anzulegen. Vergessen Sie nicht:
Murphy war Optimist.</para>
<para>Die Verwendung von Netzgruppen hat in dieser Situation
mehrere Vorteile. Sie müssen nicht jeden Benutzer einzeln
verwalten; weisen Sie stattdessen den Benutzer einer Netzgruppe
zu und erlauben oder verbieten Sie allen Mitglieder dieser
Gruppe die Anmeldung an einem Server. Wenn Sie einen neuen
Rechner hinzufügen, müssen Sie
Zugangsbeschränkungen nur für die Netzgruppen
festlegen. Legen Sie einen neuen Benutzer an, müssen Sie
ihn nur einer oder mehrere Netzgruppen zuweisen. Diese
Veränderungen sind voneinander unabhängig; Anweisungen
der Form <quote>für diese Kombination aus Benutzer und
Rechner mache Folgendes ...</quote> sind nicht mehr nötig.
Wenn Sie die Einrichtung von NIS sorgfältig geplant haben,
müssen Sie nur noch eine zentrale Konfigurationsdatei
bearbeiten, um den Zugriff auf bestimmte Rechner zu erlauben
oder zu verbieten.</para>
<para>Der erste Schritt ist die Initialisierung der NIS-Maps
der Netzgruppe. &man.ypinit.8; kann dies unter FreeBSD nicht
automatisch durchführen. Sind die Maps aber erst einmal
erzeugt, werden sie jedoch von NIS problemlos unterstützt.
Um eine leere Map zu erzeugen, geben Sie Folgendes ein:</para>
<screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>
<para>Danach legen Sie die Einträge an. Für unser
Beispiel benötigen wir mindestens vier Netzgruppen:
IT-Beschäftige, IT-Lehrlinge, normale Beschäftigte
sowie Externe.</para>
<programlisting>IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
USERS (,echo,test-domain) (,foxtrott,test-domain) \
(,golf,test-domain)
INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
<para>Bei <literal>IT_EMP</literal>, <literal>IT_APP</literal>
usw. handelt es sich um Netzgruppennamen. In den Klammern
werden diesen Netzgruppen jeweils ein oder mehrere
Benutzerkonten hinzugefügt. Die drei Felder in der
Klammer haben folgende Bedeutung:</para>
<orderedlist>
<listitem>
<para>Der Name des Rechners, auf dem die folgenden Werte
gültig sind. Legen Sie keinen Rechnernamen fest, ist
der Eintrag auf allen Rechnern gültig. Dadurch
gehen Sie vielen Problemen aus dem Weg.</para>
</listitem>
<listitem>
<para>Der Name des Benutzerkontos, der zu dieser Netzgruppe
gehört.</para>
</listitem>
<listitem>
<para>Die NIS-Domäne für das Benutzerkonto. Sie
können Benutzerkonten von anderen NIS-Domänen in
Ihre Netzgruppe importieren, wenn Sie mehrere
NIS-Domänen verwalten.</para>
</listitem>
</orderedlist>
<para>Jedes Feld kann Wildcards enthalten. Die Einzelheiten
entnehmen Sie bitte &man.netgroup.5;.</para>
<note>
<indexterm><primary>Netzgruppen</primary></indexterm>
<para>Netzgruppennamen sollten nicht länger als 8 Zeichen
sein, vor allem dann, wenn Sie Rechner mit verschiedenen
Betriebssystemen in Ihrer NIS-Domäne haben. Es wird
zwischen Groß- und Kleinschreibung unterschieden.
Die Verwendung von Großbuchstaben für
Netzgruppennamen ermöglicht eine leichte Unterscheidung
zwischen Benutzern, Rechnern und Netzgruppen.</para>
<para>Einige NIS-Clients (dies gilt nicht für FreeBSD)
können keine Netzgruppen mit einer großen Anzahl
von Einträgen verwalten. Einige ältere Versionen
von &sunos; haben beispielsweise Probleme, wenn Netzgruppen
mehr als fünfzehn <emphasis>Einträge</emphasis>
enthalten. Sie können dieses Problem umgehen, indem Sie
mehrere Subnetzgruppen mit weniger als fünfzehn Benutzern
anlegen und diese Subnetzgruppen wiederum in einer Netzgruppe
zusammenfassen:</para>
<programlisting>BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...]
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
BIGGRP3 (,joe31,domain) (,joe32,domain)
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting>
<para>Sie können diesen Vorgang wiederholen, wenn Sie mehr
als 255 Benutzer in einer einzigen Netzgruppe benötigen.
</para>
</note>
<para>Das Aktivieren und Verteilen Ihre neuen NIS-Map ist
einfach:</para>
<screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
ellington&prompt.root; <userinput>make</userinput></screen>
<para>Dadurch werden die NIS-Maps <filename>netgroup</filename>,
<filename>netgroup.byhost</filename> und
<filename>netgroup.byuser</filename> erzeugt. Prüfen Sie
die Verfügbarkeit Ihrer neuen NIS-Maps mit &man.ypcat.1;.
</para>
<screen>ellington&prompt.user; <userinput>ypcat -k netgroup</userinput>
ellington&prompt.user; <userinput>ypcat -k netgroup.byhost</userinput>
ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
<para>Die Ausgabe des ersten Befehls gibt den Inhalt von
<filename>/var/yp/netgroup</filename> wieder. Der zweite Befehl
erzeugt nur dann eine Ausgabe, wenn Sie rechnerspezifische
Netzgruppen erzeugt haben. Der dritte Befehl gibt die
Netzgruppen nach Benutzern sortiert aus.</para>
<para>Die Einrichtung der Clients ist einfach. Sie müssen
lediglich auf dem Server <hostid>war</hostid>
&man.vipw.8; aufrufen und die Zeile</para>
<programlisting>+:::::::::</programlisting>
<para>durch</para>
<programlisting>+@IT_EMP:::::::::</programlisting>
<para>ersetzen.</para>
<para>Ab sofort werden nur noch die Daten der in der Netzgruppe
<literal>IT_EMP</literal> vorhandenen Benutzer in die
Passwortdatenbank von <hostid>war</hostid> importiert.
Nur diese Benutzer dürfen sich am Server anmelden.</para>
<para>Unglücklicherweise gilt diese Einschränkung auch
für die <literal>~</literal>-Funktion der Shell und
für alle Routinen, die auf Benutzernamen und numerische
Benutzer-IDs zugreifen. Oder anders formuliert,
<command>cd ~<replaceable>user</replaceable></command> ist nicht
möglich, <command>ls -l</command> zeigt die numerische
Benutzer-ID statt dem Benutzernamen und
<command>find . -user joe -print</command> erzeugt die
Fehlermeldung <errorname>No such user</errorname>. Um dieses
Problem zu beheben, müssen Sie alle Benutzereinträge
importieren, <emphasis>ohne ihnen jedoch zu erlauben, sich an
Ihrem Server anzumelden</emphasis>.</para>
<para>Dazu fügen Sie eine weitere Zeile in
<filename>/etc/master.passwd</filename> ein. Diese Zeile sollte
ähnlich der folgenden aussehen:</para>
<para><literal>+:::::::::/sbin/nologin</literal>, was in etwa
<quote>Importiere alle Einträge, aber ersetze die Shell in
den importierten Einträgen durch
<filename>/sbin/nologin</filename></quote> entspricht. Sie
können jedes Feld dieses Eintrages ersetzen, indem Sie
einen Standardwert in <filename>/etc/master.passwd</filename>
eintragen.</para>
<warning>
<para>Stellen Sie sicher, dass die Zeile
<literal>+:::::::::/sbin/nologin</literal>
<emphasis>nach</emphasis> der Zeile
<literal>+@IT_EMP:::::::::</literal> eingetragen ist. Sonst
haben alle via NIS importierten Benutzerkonten
<filename>/sbin/nologin</filename> als Loginshell.</para>
</warning>
<para>Danach müssen Sie nur mehr eine einzige NIS-Map
ändern, wenn ein neuer Mitarbeiter berücksichtigt
werden muss. Für weniger wichtige Server gehen Sie analog
vor, indem Sie den alten Eintrag <literal>+:::::::::</literal>
in den lokalen Versionen von
<filename>/etc/master.passwd</filename> durch folgende
Einträge ersetzen:</para>
<programlisting>+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin</programlisting>
<para>Die entsprechenden Zeilen für normale Arbeitsplätze
lauten:</para>
<programlisting>+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin</programlisting>
<para>Ab jetzt wäre alles wunderbar, allerdings ändert
sich kurz darauf die Firmenpolitik: Die IT-Abteilung beginnt
damit, externe Mitarbeiter zu beschäftigen. Externe
dürfen sich an normalen Arbeitsplätzen sowie an den
weniger wichtigen Servern anmelden. Die IT-Lehrlinge
dürfen sich nun auch an den Hauptservern anmelden. Sie
legen also die neue Netzgruppe <literal>IT_INTERN</literal> an,
weisen Ihr die neuen IT-Externen als Benutzer zu und beginnen
damit, die Konfiguration auf jedem einzelnen Rechner zu
ändern ... Halt. Sie haben gerade die alte Regel
<quote>Fehler in der zentralisierten Planung führen zu
globaler Verwirrung.</quote> bestätigt.</para>
<para>Da NIS in der Lage ist, Netzgruppen aus anderen Netzgruppen
zu bilden, lassen sich solche Situationen leicht vermeiden.
Eine Möglichkeit ist die Erzeugung rollenbasierter
Netzgruppen. Sie könnten eine Netzgruppe
<literal>BIGSRV</literal> erzeugen, um den Zugang zu
den wichtigsten Servern zu beschränken, eine weitere
Gruppe <literal>SMALLSRV</literal> für die weniger
wichtigen Server und eine dritte Netzgruppe
<literal>USERBOX</literal> für die normalen
Arbeitsplatzrechner. Jede dieser Netzgruppen enthält die
Netzgruppen, die sich auf diesen Rechnern anmelden dürfen.
Die Einträge der Netzgruppen in der NIS-Map sollten
ähnlich den folgenden aussehen:</para>
<programlisting>BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS</programlisting>
<para>Diese Methode funktioniert besonders gut, wenn Sie
Rechner in Gruppen mit identischen Beschränkungen einteilen
können. Unglücklicherweise ist dies die Ausnahme und
nicht die Regel. Meistens werden Sie die Möglichkeit zur
rechnerspezischen Zugangsbeschränkung benötigen.
</para>
<para>Rechnerspezifische Netzgruppen sind die zweite
Möglichkeit, um mit den oben beschriebenen Änderungen
umzugehen. In diesem Szenario enthält
<filename>/etc/master.passwd</filename> auf jedem Rechner zwei
mit <quote>+</quote> beginnende Zeilen. Die erste Zeile
legt die Netzgruppe mit den Benutzern fest, die sich auf diesem
Rechner anmelden dürfen. Die zweite Zeile weist allen
anderen Benutzern <filename>/sbin/nologin</filename> als Shell
zu. Verwenden Sie auch hier (analog zu den Netzgruppen)
Großbuchstaben für die Rechnernamen. Die Zeilen
sollten also ähnlich den folgenden aussehen:</para>
<programlisting>+@<replaceable>BOXNAME</replaceable>:::::::::
+:::::::::/sbin/nologin</programlisting>
<para>Wenn Sie dies für alle Rechner erledigt haben, werden
Sie die lokalen Versionen von
<filename>/etc/master.passwd</filename> nie mehr verändern
müssen. Alle weiteren Änderungen geschehen über
die NIS-Maps. Nachfolgend ein Beispiel für eine
mögliche Netzgruppen-Map, die durch einige Besonderheiten
erweitert wurde:</para>
<programlisting># Define groups of users first
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
DEPT1 (,echo,test-domain) (,foxtrott,test-domain)
DEPT2 (,golf,test-domain) (,hotel,test-domain)
DEPT3 (,india,test-domain) (,juliet,test-domain)
ITINTERN (,kilo,test-domain) (,lima,test-domain)
D_INTERNS (,able,test-domain) (,baker,test-domain)
#
# Now, define some groups based on roles
USERS DEPT1 DEPT2 DEPT3
BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR BIGSRV
FAMINE BIGSRV
# User india needs access to this server
POLLUTION BIGSRV (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH IT_EMP
#
# The anti-virus-machine mentioned above
ONE SECURITY
#
# Restrict a machine to a single user
TWO (,hotel,test-domain)
# [...more groups to follow]
</programlisting>
<para>Wenn Sie eine Datenbank verwenden, um Ihre Benutzerkonten zu
verwalten, sollten Sie den ersten Teil der NIS-Map mit Ihren
Datenbanktools erstellen können. Auf diese Weise haben
neue Benutzer automatisch Zugriff auf die Rechner.</para>
<para>Eine letzte Warnung: Es ist nicht immer ratsam,
rechnerbasierte Netzgruppen zu verwenden. Wenn Sie Dutzende
oder gar Hunderte identische Rechner einrichten müssen,
sollten Sie rollenbasierte Netzgruppen verwenden, um die
Grösse der NISs-Maps in Grenzen zu halten.</para>
</sect2>
<sect2>
<title>Weitere wichtige Punkte</title>
<para>Nachdem Sie Ihre NIS-Umgebung eingerichtet haben,
müssen Sie einige Dinge anders als bisher erledigen.</para>
<itemizedlist>
<listitem>
<para>Jedes Mal, wenn Sie einen neuen Benutzer anlegen wollen,
tun Sie dies <emphasis>ausschließlich</emphasis> am
NIS-Masterserver. Außerdem
<emphasis>müssen</emphasis> Sie anschließend die
NIS-Maps neu erzeugen. Wenn Sie diesen Punkt vergessen,
kann sich der neue Benutzer <emphasis>nur</emphasis> am
NIS-Masterserver anmelden. Wenn Sie also den neuen Benutzer
<username>jsmith</username> anlegen, gehen Sie
folgerndermassen vor:</para>
<screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>make test-domain</userinput></screen>
<para>Statt <command>pw useradd jsmith</command> könnten
Sie auch <command>adduser jsmith</command> verwenden.</para>
</listitem>
<listitem>
<para><emphasis>Tragen Sie die Administratorkonten nicht
in die NIS-Maps ein</emphasis>. Administratorkonten und
Passwörter dürfen nicht auf Rechnern verbreitet
werden, auf denen sich Benutzer anmelden können, die
auf diese Konten keine Zugriff haben sollen.</para>
</listitem>
<listitem>
<para><emphasis>Sichern Sie die NIS-Master- und Slaveserver
und minimieren Sie die Ausfallzeiten</emphasis>. Wenn
diese Rechner gehackt oder einfach nur ausgeschaltet werden,
haben viele Leute keinen Netzwerkzugriff mehr.</para>
<para>Dies ist die größte Schwäche
jeder zentralen Verwaltung. Wenn Sie Ihre NIS-Server nicht
schützen, werden Sie viele verärgerte Anwender
haben.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Kompatibilität zu NIS v1</title>
<indexterm>
<primary>NIS</primary>
<secondary>Kompatibilität zu NIS v1</secondary>
</indexterm>
<para><application>ypserv</application> unterstützt NIS v1
unter FreeBSD nur eingeschränkt. Die NIS-Implementierung
von FreeBSD verwendet nur NIS v2, andere Implementierungen
unterstützen aus Gründen der
Abwärtskompatibilität mit älteren Systemen auch
NIS v1. Die mit diesen Systemen gelieferten
<application>ypbind</application>-Daemonen versuchen, sich an
einen NIS-v1-Server zu binden (Dies selbst dann, wenn sie ihn
nie benötigen. Außerdem versuchen Sie auch dann,
einen v1-Server zu erreichen, wenn Sie zuvor eine Antwort von
einem v2-Server erhalten.). Während normale Clientaufrufe
unter FreeBSD unterstützt werden, sind Anforderungen zum
Transfer von v1-Maps nicht möglich. Daher kann FreeBSD
nicht als Client oder Server verwendet werden, wenn ein
NIS-Server vorhanden ist, der nur NIS v1 unterstützt.
Glücklicherweise sollte es heute keine Server mehr geben,
die nur NIS v1 unterstützen.</para>
</sect2>
<sect2 id="nis-server-is-client">
<title>NIS-Server, die auch als NIS-Clients arbeiten</title>
<para>Wenn Sie <application>ypserv</application> in einer
Multi-Serverdomäne verwenden, in der NIS-Server
gleichzeitig als NIS-Clients arbeiten, ist es eine gute Idee,
diese Server zu zwingen, sich an sich selbst zu binden. Damit
wird verhindert, dass Bindeanforderungen gesendet werden und
sich die Server gegenseitig binden. Sonst könnten seltsame
Fehler auftreten, wenn ein Server ausfällt, auf den andere
Server angewiesen sind. Letztlich werden alle Clients einen
Timeout melden, und versuchen, sich an andere Server zu binden.
Die dadurch entstehende Verzögerung kann beträchtlich
sein. Außerdem kann der Fehler erneut auftreten, da sich
die Server wiederum aneinander binden könnten.</para>
<para>Sie können einen Rechner durch die Verwendung von
<command>ypbind</command> sowie der Option <option>-S</option>
zwingen, sich an einen bestimmten Server zu binden. Um diesen
Vorgang zu automatisieren, können Sie folgende Zeilen in
<filename>/etc/rc.conf</filename> einfügen:</para>
<programlisting>nis_client_enable="YES" # run client stuff as well
nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</replaceable>"</programlisting>
<para>Lesen Sie &man.ypbind.8;, wenn Sie weitere Informationen
benötigen.</para>
</sect2>
<sect2>
<title>Passwortformate</title>
<indexterm>
<primary>NIS</primary>
<secondary>Passwortformate</secondary>
</indexterm>
<para>Unterschiedliche Passwortformate sind das Hauptproblem,
das beim Einrichten eines NIS-Servers auftreten kann.
Wenn der NIS-Server mit DES verschlüsselte Passwörter
verwendet, werden nur Clients unterstützt, die ebenfalls
DES benutzen. Wenn sich auf Ihrem Netzwerk beispielsweise
&solaris; NIS-Clients befinden, müssen die Passwörter
mit DES verschlüsselt werden.</para>
<para>Welches Format die Server und Clients verwenden,
steht in <filename>/etc/login.conf</filename>. Wenn ein
System Passwörter mit DES verschlüsselt,
enthält die <literal>default</literal>-Klasse einen
Eintrag wie den folgenden:</para>
<programlisting>default:\
:passwd_format=des:\
:copyright=/etc/COPYRIGHT:\
[weitere Einträge]</programlisting>
<para>Mögliche Werte für
<literal>passwd_format</literal> sind unter anderem
<literal>blf</literal> und <literal>md5</literal> (mit
Blowfish und MD5 verschlüsselte Passwörter).</para>
<para>Wenn die Datei <filename>/etc/login.conf</filename>
geändert wird, muss die Login-Capability Datenbank
neu erstellt werden. Geben Sie dazu als
<username>root</username> den folgenden Befehl ein:</para>
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
<note>
<para>Das Format der schon in
<filename>/etc/master.passwd</filename> befindlichen
Passwörter wird erst aktualisiert, wenn ein Benutzer
sein Passwort ändert, <emphasis>nachdem</emphasis>
die Datenbank neu erstellt wurde.</para>
</note>
<para>Damit die Passwörter auch im gewählten
Format abgespeichert werden, muss mit
<literal>crypt_default</literal> in der Datei
<filename>/etc/auth.conf</filename> die richtige
Priorität der Formate eingestellt werden. Das
gewählte Format sollte als Erstes in der Liste
stehen. Sollen die Passwörter mit DES verschlüsselt
werden, verwenden Sie den folgenden Eintrag:</para>
<programlisting>crypt_default = des blf md5</programlisting>
<para>Wenn Sie alle &os; NIS-Server und NIS-Clients entsprechend
den obigen Schritten eingestellt haben, wird im ganzen
Netzwerk dasselbe Passwortformat verwendet. Falls Sie
Probleme mit der Authentifizierung eines NIS-Clients
haben, kontrollieren Sie die verwendeten Passwortformate.
In einer heterogenen Umgebung werden Sie DES benutzen
müssen, da dies der meist unterstützte Standard
ist.</para>
</sect2>
</sect1>
<sect1 id="network-dhcp">
<sect1info>
<authorgroup>
<author>
<firstname>Greg</firstname>
<surname>Sutter</surname>
<contrib>Geschrieben von </contrib>
</author>
</authorgroup>
</sect1info>
<title>Automatische Netzwerkkonfiguration mit DHCP</title>
<sect2>
<title>Was ist DHCP?</title>
<indexterm>
<primary>Dynamic Host Configuration Protocol</primary>
<see>DHCP</see>
</indexterm>
<indexterm>
<primary>Internet Systems Consortium (ISC)</primary>
</indexterm>
<para>Über DHCP, das Dynamic Host Configuration Protocol,
kann sich ein System mit einem Netzwerk verbinden und die
für die Kommunikation mit diesem Netzwerk nötigen
Informationen beziehen. &os; verwendet den von
OpenBSD 3.7 stammenden <command>dhclient</command>.
Die Informationen in diesem Abschnitt
beziehen sich daher sowohl auf den <command>dhclient</command>
von ISC als auch auf den von OpenBSD. Als DHCP-Server wird
in beiden Fällen der DHCP-Server der ISC-Distribution
verwendet.</para>
</sect2>
<sect2>
<title>Übersicht</title>
<para>Dieser Abschnitt beschreibt sowohl die Clientseite des
ISC- als auch des OpenBSD-Clients sowie die
Serverseite des DHCP-Systems von ISC. Das Clientprogramm
<command>dhclient</command> ist in FreeBSD integriert, das
Serverprogramm kann über den Port
<filename role="package">net/isc-dhcp42-server</filename>
installiert werden. Weiter Informationen finden Sie in
&man.dhclient.8;, &man.dhcp-options.5; sowie
&man.dhclient.conf.5;.</para>
</sect2>
<sect2>
<title>Wie funktioniert DHCP?</title>
<indexterm><primary>UDP</primary></indexterm>
<para>Der DHCP-Client <command>dhclient</command> beginnt von
einem Clientrechner aus über den UDP-Port 68
Konfigurationsinformationen anzufordern. Der Server antwortet
auf dem UDP-Port 67, indem er dem Client eine IP-Adresse
zuweist und ihm weitere wichtige Informationen über das
Netzwerk, wie Netzmasken, Router und DNS-Server mitteilt. Diese
Informationen werden als
<firstterm>DHCP-Lease</firstterm> bezeichnet und
sind nur für eine bestimmte Zeit, die vom Administrator des
DHCP-Servers vorgegeben wird, gültig. Dadurch fallen
verwaiste IP-Adressen, deren Clients nicht mehr mit dem Netzwerk
verbunden sind, automatisch an den Server zurück.</para>
<para>DHCP-Clients können sehr viele Informationen von einem
DHCP-Server erhalten. Eine ausführliche Liste finden Sie
in &man.dhcp-options.5;.</para>
</sect2>
<sect2>
<title>Integration in FreeBSD</title>
<para>&os; verwendet den DHCP-Client von OpenBSD.
Sowohl während der Installation als
auch im Basissystem steht der DHCP-Client zur Verfügung.
In Netzen mit DHCP-Servern wird dadurch die Konfiguration von
Systemen erheblich vereinfacht.</para>
<indexterm>
<primary><application>sysinstall</application></primary>
</indexterm>
<para>DHCP wird von <application>sysinstall</application>
unterstützt. Wenn Sie eine Netzwerkkarte mit
<application>sysinstall</application> konfigurieren, lautet
die zweite Frage <quote>Do you want to try DHCP configuration
of the interface?</quote>. Wenn Sie diese Frage bejahen, wird
<command>dhclient</command> aufgerufen, und die Netzkarte wird
automatisch eingerichtet.</para>
<para>Um DHCP beim Systemstart zu aktivieren, müssen Sie zwei
Dinge erledigen:</para>
<indexterm>
<primary>DHCP</primary>
<secondary>Anforderungen</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para>Stellen Sie sicher, dass <devicename>bpf</devicename> in
Ihren Kernel kompiliert ist. Dazu fügen Sie die Zeile
<literal>device bpf</literal>
in Ihre Kernelkonfigurationsdatei ein und erzeugen einen
neuen Kernel. Weitere Informationen zur Kernelkonfiguration
finden Sie in <xref linkend="kernelconfig"/> des Handbuchs.
</para>
<para>Das Gerät <devicename>bpf</devicename> ist im
<filename>GENERIC</filename>-Kernel bereits enthalten.
Für die Nutzung von DHCP muss also kein angepasster
Kernel erzeugt werden.</para>
<note>
<para>Wenn Sie um die Sicherheit Ihres Systems besorgt
sind, sollten Sie wissen, dass
<devicename>bpf</devicename> auch zur Ausführung
von Paketsniffern erforderlich ist (obwohl diese dennoch
als <username>root</username> ausgeführt werden
müssen). <devicename>bpf</devicename>
<emphasis>muss</emphasis> vorhanden sein, damit DHCP
funktioniert. Sind Sie sehr sicherheitsbewusst, sollten
Sie <devicename>bpf</devicename> aus Ihrem Kernel
entfernen, wenn Sie DHCP nicht verwenden.</para>
</note>
</listitem>
<listitem>
<para>Standardmässig läuft die DHCP-Konfiguration
bei &os; im Hintergrund oder auch
<firstterm>asynchron</firstterm>. Andere Startskripte laufen
weiter, während DHCP fertig abgearbeitet wird, was den
Systemstart beschleunigt.</para>
<para>DHCP im Hintergrund funktioniert gut, wenn der DHCP-Server
schnell auf Anfragen antwortet und der
DHCP-Konfigurationsprozess ebenso schnell abläuft.
Jedoch kann DHCP eine lange Zeit benötigen, um auf
manchen Systemen fertig zu werden. Falls Netzwerkdienste
versuchen, vor DHCP zum Ende zu kommen, werden diese
fehlschlagen. Durch die Verwendung von DHCP im
<firstterm>asynchronen</firstterm>-Modus wird das Problem
verhindert, so dass die Startskripte pausiert werden, bis
die DHCP-Konfiguration abgeschlossen ist.</para>
<para>Um sich zu einem DHCP-Server im Hintergrund zu verbinden,
während andere Startskripte fortfahren
(asynchroner Modus), benutzen Sie den
<quote><literal>DHCP</literal></quote>-Wert in
<filename>/etc/rc.conf</filename>:</para>
<programlisting>ifconfig_<replaceable>fxp0</replaceable>="DHCP"</programlisting>
<para>Um den Start zu pausieren, damit DHCP vorher
abgeschlossen werden kann, benutzen Sie den synchronen Modus
mit dem Eintrag
<quote><literal>SYNCDHCP</literal></quote>:</para>
<programlisting>ifconfig_<replaceable>fxp0</replaceable>="SYNCDHCP"</programlisting>
<note>
<para>Ersetzen Sie <replaceable>fxp0</replaceable>, das
in diesen Beispielen verwendet wurde, durch den Namen Ihrer
Netzwerkschnittstelle, so wie es in <xref
linkend="config-network-setup"/> beschrieben ist.</para>
</note>
<para>Wenn Sie <command>dhclient</command> an einem anderen
Ort installiert haben, oder zusätzliche Flags an
<command>dhclient</command> übergeben wollen,
fügen Sie auch folgende (entsprechend angepasste)
Zeilen ein:</para>
<programlisting>dhclient_program="/sbin/dhclient"
dhclient_flags=""</programlisting>
</listitem>
</itemizedlist>
<indexterm>
<primary>DHCP</primary>
<secondary>Server</secondary>
</indexterm>
<para>Der DHCP-Server <application>dhcpd</application> ist als
Teil des Ports
<filename role="package">net/isc-dhcp42-server</filename>
verfügbar. Dieser Port enthält die komplette
ISC-DHCP-Distribution, inklusive der Dokumentation.</para>
</sect2>
<sect2>
<title>Dateien</title>
<indexterm>
<primary>DHCP</primary>
<secondary>Konfigurationsdateien</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para><filename>/etc/dhclient.conf</filename></para>
<para><command>dhclient</command> benötigt die
Konfigurationsdatei <filename>/etc/dhclient.conf</filename>.
Diese Datei enthält normalerweise nur Kommentare, da
die Vorgabewerte zumeist ausreichend sind. Lesen Sie dazu
auch &man.dhclient.conf.5;.</para>
</listitem>
<listitem>
<para><filename>/sbin/dhclient</filename></para>
<para><command>dhclient</command> ist statisch gelinkt und
befindet sich in <filename>/sbin</filename>. Weitere
Informationen finden Sie in &man.dhclient.8;.</para>
</listitem>
<listitem>
<para><filename>/sbin/dhclient-script</filename></para>
<para>Bei <command>dhclient-script</command> handelt es sich
um das FreeBSD-spezifische Konfigurationsskript des
DHCP-Clients. Es wird in &man.dhclient-script.8;
beschrieben und kann meist unverändert übernommen
werden.</para>
</listitem>
<listitem>
<para><filename>/var/db/dhclient.leases</filename></para>
<para>Der DHCP-Client verfügt über eine Datenbank,
die alle derzeit gültigen Leases enthält und als
Logdatei erzeugt wird. Weitere Informationen finden Sie in
&man.dhclient.8;.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Weitere Informationen</title>
<para>Das DHCP-Protokoll wird vollständig im
<ulink url="http://www.freesoft.org/CIE/RFC/2131/">RFC 2131</ulink>
beschrieben. Eine weitere, lehrreiche Informationsquelle
existiert unter
<ulink url="http://www.dhcp.org/"></ulink>.</para>
</sect2>
<sect2 id="network-dhcp-server">
<title>Einen DHCP-Server installieren und einrichten</title>
<sect3>
<title>Übersicht</title>
<para>Dieser Abschnitt beschreibt die Einrichtung eines
FreeBSD-Systems als DHCP-Server. Dazu wird die
DHCP-Implementation von ISC (Internet Systems Consortium)
verwendet.</para>
<para>Der DHCP-Server ist nicht im Basissystem von FreeBSD
enthalten, daher müssen Sie als Erstes den Port
<filename role="package">net/isc-dhcp42-server</filename>
installieren. Lesen Sie <xref linkend="ports"/>, wenn Sie
weitere Informationen zur Ports-Sammlung benötigen.
</para>
</sect3>
<sect3>
<title>Den DHCP-Server installieren</title>
<indexterm>
<primary>DHCP</primary>
<secondary>installieren</secondary>
</indexterm>
<para>Stellen Sie sicher, dass &man.bpf.4; in Ihren Kernel
kompiliert ist. Dazu fügen Sie die Zeile
<literal>device bpf</literal>
Ihre Kernelkonfigurationsdatei ein und erzeugen einen neuen
Kernel. Die Kernelkonfiguration wird in
<xref linkend="kernelconfig"/> beschrieben.</para>
<para>Das Gerät <devicename>bpf</devicename> ist im
<filename>GENERIC</filename>-Kernel bereits enthalten.
Für die Nutzung von DHCP muss also kein angepasster
Kernel erzeugt werden.</para>
<note>
<para>Wenn Sie um die Sicherheit Ihres Systems besorgt
sind, sollten Sie wissen, dass
<devicename>bpf</devicename> auch zur Ausführung
von Paketsniffern erforderlich ist (obwohl diese dennoch
als <username>root</username> ausgeführt werden
müssen). <devicename>bpf</devicename>
<emphasis>muss</emphasis> vorhanden sein, damit DHCP
funktioniert. Sind Sie sehr sicherheitsbewusst, sollten
Sie <devicename>bpf</devicename> aus Ihrem Kernel
entfernen, wenn Sie DHCP nicht verwenden.</para>
</note>
<para>Danach müssen Sie die vom Port
<filename role="package">net/isc-dhcp42-server</filename>
erzeugte Vorlage für <filename>dhcpd.conf</filename>
anpassen. Die bei der Installation erzeugte Datei
<filename>/usr/local/etc/dhcpd.conf.sample</filename>
sollten Sie nach
<filename>/usr/local/etc/dhcpd.conf</filename> kopieren,
bevor Sie Veränderungen vornehmen.</para>
</sect3>
<sect3>
<title>Den DHCP-Server einrichten</title>
<indexterm>
<primary>DHCP</primary>
<secondary>dhcpd.conf</secondary>
</indexterm>
<para><filename>dhcpd.conf</filename> besteht aus Festlegungen
zu Subnetzen und Rechnern und lässt sich am besten an
einem Beispiel erklären:</para>
<programlisting>option domain-name "example.com";<co id="domain-name"/>
option domain-name-servers 192.168.4.100;<co id="domain-name-servers"/>
option subnet-mask 255.255.255.0;<co id="subnet-mask"/>
default-lease-time 3600;<co id="default-lease-time"/>
max-lease-time 86400;<co id="max-lease-time"/>
ddns-update-style none;<co id="ddns-update-style"/>
subnet 192.168.4.0 netmask 255.255.255.0 {
range 192.168.4.129 192.168.4.254;<co id="range"/>
option routers 192.168.4.1;<co id="routers"/>
}
host mailhost {
hardware ethernet 02:03:04:05:06:07;<co id="hardware"/>
fixed-address mailhost.example.com;<co id="fixed-address"/>
}</programlisting>
<calloutlist>
<callout arearefs="domain-name">
<para>Diese Option beschreibt die Domäne, die den
Clients als Standardsuchdomäne zugewiesen wird.
Weitere Informationen finden Sie in man.resolv.conf.5;.
</para>
</callout>
<callout arearefs="domain-name-servers">
<para>Diese Option legt eine, durch Kommata getrennte
Liste von DNS-Servern fest, die von den Clients
verwendet werden sollen.</para>
</callout>
<callout arearefs="subnet-mask">
<para>Die den Clients zugewiesene Netzmaske.</para>
</callout>
<callout arearefs="default-lease-time">
<para>Ein Client kann eine Lease einer bestimmten Dauer
anfordern. Geschieht dies nicht, weist der Server eine
Lease mit einer vorgegebenen Ablaufdauer (in Sekunden)
zu.</para>
</callout>
<callout arearefs="max-lease-time">
<para>Die maximale Zeitdauer, für die der Server
Konfigurationsinformationen vergibt. Sollte ein Client
eine längere Zeitspanne anfordern, wird dennoch
nur der Wert <literal>max-lease-time</literal> in
Sekunden zugewiesen.</para>
</callout>
<callout arearefs="ddns-update-style">
<para>Diese Option legt fest, ob der DHCP-Server eine
DNS-Aktualisierung versuchen soll, wenn
Konfigurationsdateien vergeben oder zurückgezogen
werden. In der ISC-Implementation
<emphasis>muss</emphasis> diese Option gesetzt sein.
</para>
</callout>
<callout arearefs="range">
<para>Dadurch werden die IP-Adressen festgelegt, die den
Clients zugewiesen werden können. IP-Adressen
zwischen diesen Grenzen sowie die einschließenden
Adressen werden den Clients zugewiesen.</para>
</callout>
<callout arearefs="routers">
<para>Legt das Standard-Gateway fest, das den Clients
zugewiesen wird.</para>
</callout>
<callout arearefs="hardware">
<para>Die (Hardware-)MAC-Adresse eines Rechners (durch die
der DHCP-Server den Client erkennt, der eine Anforderung
an ihn stellt).</para>
</callout>
<callout arearefs="fixed-address">
<para>Einem Rechner soll immer die gleiche IP-Adresse
zugewiesen werden. Beachten Sie, dass hier auch ein
Rechnername gültig ist, da der DHCP-Server den
Rechnernamen auflöst, bevor er die
Konfigurationsinformationen zuweist.</para>
</callout>
</calloutlist>
<para>Nachdem Sie <filename>dhcpd.conf</filename> fertig
konfiguriert haben, sollten Sie den DHCP-Server aktivieren,
indem Sie folgende Zeilen in
<filename>/etc/rc.conf</filename> aufnehmen:</para>
<programlisting>dhcpd_enable="YES"
dhcpd_ifaces="dc0"</programlisting>
<para>Dabei müssen Sie den Geräteeintrag
<literal>dc0</literal> durch die Gerätedatei (mehrere
Gerätedateien müssen durch Leerzeichen getrennt
werden) ersetzen, die Ihr DHCP-Server auf Anfragen von
DHCP-Clients hin überwachen soll.</para>
<para>Danach können Sie den Server durch Eingabe des
folgenden Befehls starten:</para>
<screen>&prompt.root; <userinput>/usr/local/etc/rc.d/isc-dhcpd start</userinput></screen>
<para>Sollten Sie die Konfiguration Ihres Servers einmal
verändern müssen, reicht es nicht aus, ein
<literal>SIGHUP</literal>-Signal an
<application>dhcpd</application> zu senden, weil damit die
Konfiguration <emphasis>nicht</emphasis> erneut geladen wird
(im Gegensatz zu den meisten Daemonen). Sie müssen
den Prozess vielmehr mit dem Signal
<literal>SIGTERM</literal> stoppen, um ihn
anschließend neu zu starten.</para>
</sect3>
<sect3>
<title>Dateien</title>
<indexterm>
<primary>Server</primary>
<secondary>Konfigurationsdateien</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para><filename>/usr/local/sbin/dhcpd</filename></para>
<para><application>dhcpd</application> ist statisch
gelinkt und befindet sich in
<filename>/usr/local/sbin</filename>. Lesen Sie auch die
mit dem Port installierte Hilfeseite &man.dhcpd.8;, wenn
Sie weitere Informationen zu
<application>dhcpd</application> benötigen.</para>
</listitem>
<listitem>
<para><filename>/usr/local/etc/dhcpd.conf</filename></para>
<para><application>dhcpd</application> benötigt die
Konfigurationsdatei
<filename>/usr/local/etc/dhcpd.conf</filename>, damit
der Server den Clients seine Dienste anbieten kann.
Diese Datei muss alle Informationen enthalten, die an
die Clients weitergegeben werden soll. Außerdem
sind hier Informationen zur Konfiguration des Servers
enthalten. Die mit dem Port installierte Hilfeseite
&man.dhcpd.conf.5; enthält weitere Informationen.
</para>
</listitem>
<listitem>
<para><filename>/var/db/dhcpd.leases</filename></para>
<para>Der DHCP-Server hat eine Datenbank, die alle
vergebenen Leases enthält. Diese wird als Logdatei
erzeugt. Weitere Informationen finden Sie in der vom
Port installierten Hilfeseite &man.dhcpd.leases.5;.</para>
</listitem>
<listitem>
<para><filename>/usr/local/sbin/dhcrelay</filename></para>
<para><application>dhcrelay</application> wird in
komplexen Umgebungen verwendet, in denen ein DHCP-Server
eine Anfrage eines Clients an einen DHCP-Server in einem
separaten Netzwerk weiterleitet. Wenn Sie diese
Funktion benötigen, müssen Sie den Port
<filename role="package">net/isc-dhcp42-relay</filename>
installieren. Weitere Informationen zu diesem Thema
finden Sie in &man.dhcrelay.8;.</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
</sect1>
<sect1 id="network-dns">
<sect1info>
<authorgroup>
<author>
<firstname>Chern</firstname>
<surname>Lee</surname>
<contrib>Beigetragen von </contrib>
</author>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
</author>
<author>
<firstname>Daniel</firstname>
<surname>Gerzo</surname>
</author>
</authorgroup>
</sect1info>
<title><acronym>DNS</acronym> – Domain Name Service</title>
<sect2>
<title>Überblick</title>
<indexterm><primary>BIND</primary></indexterm>
<para>DNS ist das für die Umwandlung von Rechnernamen in
IP-Adressen zuständige Protokoll. &os; verwendet dazu
BIND (Berkeley Internet Name Domain), die am häufigsten
verwendete Implementierung von <acronym>DNS</acronym>).
Eine Anfrage nach <hostid
role="fqdn">www.FreeBSD.org</hostid> gibt die
<acronym>IP</acronym>-Adresse des &os;-Webservers, eine Anfrage
nach <hostid role="fqdn">ftp.FreeBSD.org</hostid> die
<acronym>IP</acronym>-Adresse des entsprechenden
<acronym>FTP-Servers</acronym> zurück. Der umgekehrte Weg
ist ebenso möglich, eine <acronym>IP</acronym>-Adresse
kann also auch in ihren Rechnernamen aufgelöst werden. Um
eine <acronym>DNS</acronym>-Abfrage durchzuführen, muss auf
dem jeweiligen Rechner kein Nameserver installiert sein.</para>
<para>&os; verwendet derzeit in der Voreinstellung
<acronym>BIND</acronym>9 als
<acronym>DNS</acronym>-Serversoftware. Unsere Installation
bietet Ihnen eine erhöhte Sicherheit, ein neues
Dateisystemlayout sowie eine automatisierte
&man.chroot.8;-Konfiguration.</para>
<indexterm><primary>DNS</primary></indexterm>
<para>Im Internet wird <acronym>DNS</acronym> durch ein komplexes
System von autoritativen Root-Nameservern,
Top Level Domain-Servern (<acronym>TLD</acronym>) sowie anderen
kleineren Nameservern verwaltet, die individuelle Rechnerinformationen
speichern und untereinander abgleichen.</para>
<para>Derzeit wird BIND vom Internet Systems Consortium
(<ulink url="https://www.isc.org/"></ulink>) verwaltet.</para>
</sect2>
<sect2>
<title>Begriffsbestimmungen</title>
<para>Um dieses Dokument besser verstehen zu können,
müssen einige <acronym>DNS</acronym>-spezifische
Begriffe genauer definiert werden.</para>
<indexterm><primary>Resolver</primary></indexterm>
<indexterm><primary>Reverse-DNS</primary></indexterm>
<indexterm><primary>Root-Zone</primary></indexterm>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<colspec colwidth="1*"/>
<colspec colwidth="3*"/>
<thead>
<row>
<entry>Begriff</entry>
<entry>Bedeutung</entry>
</row>
</thead>
<tbody>
<row>
<entry>Forward-<acronym>DNS</acronym></entry>
<entry>Rechnernamen in <acronym>IP</acronym>-Adressen
umwandeln.</entry>
</row>
<row>
<entry>Origin (Ursprung)</entry>
<entry>Die in einer bestimmten Zonendatei beschriebene
Domäne.</entry>
</row>
<row>
<entry><application>named</application>, BIND</entry>
<entry>Gebräuchliche Namen für das unter &os;
verwendete BIND-Nameserverpaket.</entry>
</row>
<row>
<entry>Resolver</entry>
<entry>Ein Systemprozess, durch den ein Rechner
Zoneninformationen von einem Nameserver anfordert.</entry>
</row>
<row>
<entry>Reverse-<acronym>DNS</acronym></entry>
<entry>die Umwandlung von <acronym>IP</acronym>-Adressen in
Rechnernamen</entry>
</row>
<row>
<entry>Root-Zone</entry>
<entry>Der Beginn der Internet-Zonenhierarchie. Alle
Zonen befinden sich innerhalb der Root-Zone. Dies ist
analog zu einem Dateisystem, in dem sich alle Dateien
und Verzeichnisse innerhalb des Wurzelverzeichnisses
befinden.</entry>
</row>
<row>
<entry>Zone</entry>
<entry>Eine individuelle Domäne, Unterdomäne,
oder ein Teil von <acronym>DNS</acronym>, der von der
gleichen Autorität verwaltet wird.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<indexterm>
<primary>Zonen</primary>
<secondary>Beispiele</secondary>
</indexterm>
<para>Es folgen nun einige Zonenbeispiele:</para>
<itemizedlist>
<listitem>
<para>Innerhalb der Dokumentation wird die Root-Zone in der
Regel mit <hostid>.</hostid> bezeichnet.</para>
</listitem>
<listitem>
<para><hostid>org.</hostid> ist eine Top level Domain
(<acronym>TLD</acronym>) innerhalb der Root-Zone.</para>
</listitem>
<listitem>
<para><hostid role="domainname">example.org.</hostid>
ist eine Zone innerhalb der
<hostid>org.</hostid>-<acronym>TLD</acronym>.</para>
</listitem>
<listitem>
<para><hostid>1.168.192.in-addr.arpa.</hostid> ist die Zone mit
allen IP-Adressen des <hostid
role="domainname">192.168.1.*</hostid>-IP-Bereichs.</para>
</listitem>
</itemizedlist>
<para>Wie man an diesen Beispielen erkennen kann, befindet sich
der spezifischere Teil eines Rechnernamens auf der linken Seite
der Adresse. <hostid role="domainname">example.org.</hostid>
beschreibt einen Rechner also genauer als <hostid>org.</hostid>,
während <hostid>org.</hostid> genauer als die Root-Zone
ist. Jeder Teil des Rechnernamens hat Ähnlichkeiten mit
einem Dateisystem, in dem etwa <filename>/dev</filename> dem
Wurzelverzeichnis untergeordnet ist.</para>
</sect2>
<sect2>
<title>Gründe für die Verwendung eines
Nameservers</title>
<para>Es gibt zwei Arten von Nameservern: Autoritative Nameserver
sowie zwischenspeichernde (cachende, auch bekannt als
auflösende) Nameserver.</para>
<para>Ein autoritativer Nameserver ist notwendig, wenn</para>
<itemizedlist>
<listitem>
<para>Sie anderen verbindliche
<acronym>DNS</acronym>-Auskünfte erteilen wollen.</para>
</listitem>
<listitem>
<para>eine Domain, beispielsweise
<hostid role="domainname">example.org</hostid>, registriert
wird, und den zu dieser Domain gehörenden Rechnern
<acronym>IP</acronym>-Adressen zugewiesen werden
müssen.</para>
</listitem>
<listitem>
<para>ein <acronym>IP</acronym>-Adressblock
reverse-<acronym>DNS</acronym>-Einträge benötigt,
um <acronym>IP</acronym>-Adressen in Rechnernamen
auflösen zu können.</para>
</listitem>
<listitem>
<para>ein Backup-Nameserver (auch Slaveserver genannt) oder
ein zweiter Nameserver auf Anfragen antworten soll.</para>
</listitem>
</itemizedlist>
<para>Ein cachender Nameserver ist notwendig, weil</para>
<itemizedlist>
<listitem>
<para>ein lokaler DNS-Server Daten zwischenspeichern und daher
schneller auf Anfragen reagieren kann als ein entfernter
Server.</para>
</listitem>
</itemizedlist>
<para>Wird nach <hostid role="fqdn">www.FreeBSD.org</hostid>
gesucht, leitet der Resolver diese Anfrage an den Nameserver des
ISPs weiter und nimmt danach das Ergebnis der
Abfrage entgegen. Existiert ein lokaler, zwischenspeichernder
<acronym>DNS</acronym>-Server, muss dieser die Anfrage nur einmal
nach außen weitergeben. Für alle weiteren Anfragen
ist dies nicht mehr nötig, da diese Information nun lokal
gespeichert ist.</para>
</sect2>
<sect2>
<title>Wie funktioniert <acronym>DNS</acronym>?</title>
<para>Unter &os; wird der BIND-Daemon als
<application>named</application> bezeichnet.</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>Datei</entry>
<entry>Beschreibung</entry>
</row>
</thead>
<tbody>
<row>
<entry><application>named</application></entry>
<entry>Der BIND-Daemon.</entry>
</row>
<row>
<entry>&man.rndc.8;</entry>
<entry>Das Steuerprogramm für
<application>named</application>.</entry>
</row>
<row>
<entry><filename class="directory">/etc/namedb</filename></entry>
<entry>Das Verzeichnis, in dem sich die Zoneninformationen
für BIND befinden.</entry>
</row>
<row>
<entry><filename>/etc/namedb/named.conf</filename></entry>
<entry>Die Konfigurationsdatei für
<application>named</application>.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Je nachdem, wie eine Zone auf dem Server konfiguriert wurde,
finden sich die zur Zone gehörendenden Dateien in den
Unterverzeichnissen <filename
class="directory">master</filename>, <filename
class="directory">slave</filename>, oder <filename
class="directory">dynamic</filename> des Verzeichnisses
<filename class="directory">/etc/namedb</filename>. Diese
Dateien enthalten die <acronym>DNS</acronym>-Informationen,
die der Nameserver für die Beantwortung von Anfragen
benötigt.</para>
</sect2>
<sect2>
<title>BIND starten</title>
<indexterm>
<primary>BIND</primary>
<secondary>Start</secondary>
</indexterm>
<para>Da BIND automatisch installiert wird, ist die Konfiguration
relativ einfach.</para>
<para>In der Voreinstellung wird ein in einer &man.chroot.8;-Umgebung
betriebener <application>named</application>-Server zur einfachen
Namensauflösung eingerichtet, der nur im lokalen
IPv4-Loopback-Adressbereich (127.0.0.1) lauscht. Um den Server
manuell zu starten, verwenden Sie den folgenden Befehl:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/named onestart</userinput></screen>
<para>Um den <application>named</application>-Daemon beim
Systemstart automatisch zu starten, fügen Sie folgende
Zeile in <filename>/etc/rc.conf</filename> ein:</para>
<programlisting>named_enable="YES"</programlisting>
<para><filename>/etc/namedb/named.conf</filename> bietet zahlreiche
Konfigurationsoptionen, die in diesem Dokument nicht alle
beschrieben werden können. Wollen Sie die Startoptionen
von <application>named</application> unter &os; anpassen, sollten
Sie sich die
<literal>named_<replaceable>*</replaceable></literal>-Flags in der
Datei <filename>/etc/defaults/rc.conf</filename> sowie die
Manualpage zu &man.rc.conf.5; näher ansehen. Zusätzliche
Informationen bietet Ihnen auch der Abschnitt <xref
linkend="configtuning-rcd"/> des Handbuchs.</para>
</sect2>
<sect2>
<title>Konfigurationsdateien</title>
<indexterm>
<primary>BIND</primary>
<secondary>Konfigurationsdateien</secondary>
</indexterm>
<para>Die Konfigurationsdateien von
<application>named</application> finden sich unter
<filename class="directory">/etc/namedb</filename> und müssen
in der Regel an Ihre Bedürfnisse angepasst werden. Es sei
denn, Sie benötigen nur einen einfachen Resolver. Ein
Großteil der Konfigurationsarbeiten erfolgt dabei in
diesem Verzeichnis.</para>
<sect3>
<title><filename>/etc/namedb/named.conf</filename></title>
<programlisting>// $FreeBSD$
//
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/share/doc/bind9 for more details.
//
// If you are going to set up an authoritative server, make sure you
// understand the hairy details of how DNS works. Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amounts of useless Internet traffic.
options {
// All file and path names are relative to the chroot directory,
// if any, and should be fully qualified.
directory "/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
listen-on { 127.0.0.1; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
// listen-on-v6 { ::1; };
// These zones are already covered by the empty zones listed below.
// If you remove the related empty zones below, comment these lines out.
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below. This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
/*
forwarders {
127.0.0.1;
};
*/
// If the 'forwarders' clause is not empty the default is to 'forward first'
// which will fall back to sending a query from your local server if the name
// servers in 'forwarders' do not have the answer. Alternatively you can
// force your name server to never initiate queries of its own by enabling the
// following line:
// forward only;
// If you wish to have forwarding configured automatically based on
// the entries in /etc/resolv.conf, uncomment the following line and
// set named_auto_forward=yes in /etc/rc.conf. You can also enable
// named_auto_forward_only (the effect of which is described above).
// include "/etc/namedb/auto_forward.conf";
</programlisting>
<para>Um vom Cache Ihres Internetproviders zu profitieren,
können hier <literal>forwarders</literal> aktiviert
werden. Normalerweise sucht ein Nameserver das Internet
rekursiv ab, bis er die gesuchte Antwort findet. Durch
diese Option wird stets der Nameserver Ihres
Internetproviders zuerst abgefragt, um von dessen
Cache zu profitieren. Wenn es sich um einen schnellen,
viel benutzten Nameserver handelt, kann dies zu einer
Geschwindigkeitssteigerung führen.</para>
<warning>
<para><hostid role="ipaddr">127.0.0.1</hostid> funktioniert
hier <emphasis>nicht</emphasis>. Ändern Sie diese
Adresse in einen Nameserver Ihres Einwahlproviders.</para>
</warning>
<programlisting> /*
Modern versions of BIND use a random UDP port for each outgoing
query by default in order to dramatically reduce the possibility
of cache poisoning. All users are strongly encouraged to utilize
this feature, and to configure their firewalls to accommodate it.
AS A LAST RESORT in order to get around a restrictive firewall
policy you can try enabling the option below. Use of this option
will significantly reduce your ability to withstand cache poisoning
attacks, and should be avoided if at all possible.
Replace NNNNN in the example with a number between 49160 and 65530.
*/
// query-source address * port NNNNN;
};
// If you enable a local name server, don't forget to enter 127.0.0.1
// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.
// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/etc/namedb/named.root"; };
/* Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server. Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts. Use with caution.
To use this mechanism, uncomment the entries below, and comment
the hint zone above.
As documented at http://dns.icann.org/services/axfr/ these zones:
"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
are availble for AXFR from these servers on IPv4 and IPv6:
xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/
/*
zone "." {
type slave;
file "/etc/namedb/slave/root.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
};
notify no;
};
zone "arpa" {
type slave;
file "/etc/namedb/slave/arpa.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
};
notify no;
};
*/
/* Serving the following zones locally will prevent any queries
for these zones leaving your network and going to the root
name servers. This has two significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
*/
// RFCs 1912 and 5735 (and BCP 32 for localhost)
zone "localhost" { type master; file "/etc/namedb/master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// RFC 1912-style zone for IPv6 localhost address
zone "0.ip6.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; };
// "This" Network (RFCs 1912 and 5735)
zone "0.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// Private Use Networks (RFCs 1918 and 5735)
zone "10.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// Link-local/APIPA (RFCs 3927 and 5735)
zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// IETF protocol assignments (RFCs 5735 and 5736)
zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// TEST-NET-[1-3] for Documentation (RFCs 5735 and 5737)
zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// IPv6 Range for Documentation (RFC 3849)
zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// Domain Names for Documentation and Testing (BCP 32)
zone "test" { type master; file "/etc/namedb/master/empty.db"; };
zone "example" { type master; file "/etc/namedb/master/empty.db"; };
zone "invalid" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.com" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.net" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.org" { type master; file "/etc/namedb/master/empty.db"; };
// Router Benchmark Testing (RFCs 2544 and 5735)
zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// IANA Reserved - Old Class E Space (RFC 5735)
zone "240.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "241.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "242.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "243.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "244.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "245.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "246.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "247.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "248.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "249.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "250.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "251.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "252.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "253.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "254.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// IPv6 Unassigned Addresses (RFC 4291)
zone "1.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "3.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "4.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "5.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "6.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "7.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "8.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "9.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "a.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "b.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "c.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "d.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "e.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "0.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "1.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "2.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "3.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "4.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "5.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "6.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "7.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "8.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "9.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "a.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "b.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "0.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "1.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "2.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "3.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "4.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "5.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "6.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "7.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// IPv6 ULA (RFC 4193)
zone "c.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "d.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// IPv6 Link Local (RFC 4291)
zone "8.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "9.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "a.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "b.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// IPv6 Deprecated Site-Local Addresses (RFC 3879)
zone "c.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "d.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "e.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
zone "f.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; };
// IP6.INT is Deprecated (RFC 4159)
zone "ip6.int" { type master; file "/etc/namedb/master/empty.db"; };
// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example slave zone config entries. It can be convenient to become
// a slave at least for the zone your own domain is in. Ask
// your network administrator for the IP address of the responsible
// master name server.
//
// Do not forget to include the reverse lookup zone!
// This is named after the first bytes of the IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6.
//
// Before starting to set up a master zone, make sure you fully
// understand how DNS and BIND work. There are sometimes
// non-obvious pitfalls. Setting up a slave zone is usually simpler.
//
// NB: Don't blindly enable the examples below. :-) Use actual names
// and addresses instead.
/* An example dynamic zone
key "exampleorgkey" {
algorithm hmac-md5;
secret "sf87HJqjkqh8ac87a02lla==";
};
zone "example.org" {
type master;
allow-update {
key "exampleorgkey";
};
file "/etc/named/dynamic/example.org";
};
*/
/* Example of a slave reverse zone
zone "1.168.192.in-addr.arpa" {
type slave;
file "/etc/namedb/slave/1.168.192.in-addr.arpa";
masters {
192.168.1.1;
};
};
*/</programlisting>
<para>Hierbei handelt es sich um Slave-Einträge für
eine Reverse- und Forward-DNS-Zone, die in der Datei
<filename>named.conf</filename> definiert sind.</para>
<para>Für jede neue Zone muss ein zusätzlicher Eintrag
in <filename>named.conf</filename> erstellt werden.</para>
<para>Ein einfacher Eintrag für eine Zone
<hostid role="domainname">example.org</hostid> könnte
beispielsweise so aussehen:</para>
<programlisting>zone "example.org" {
type master;
file "master/example.org";
}; </programlisting>
<para>Die Option <option>type</option> legt fest, dass es sich
um eine Master-Zone handelt, deren Zoneninformationen sich in
der Datei <filename>/etc/namedb/master/example.org</filename>
befinden. Diese Datei wird durch die Option
<option>file</option> festgelegt.</para>
<programlisting>zone "example.org" {
type slave;
file "slave/example.org";
}; </programlisting>
<para>Hier handelt es sich um einen Slaveserver, der seine
Informationen vom Masterserver der betreffenden Zone bezieht
und diese in der angegebenen Datei speichert. Wenn der
Masterserver nicht erreichbar ist, verfügt der
Slaveserver über die transferierten Zoneninformationen
und kann diese an andere Rechner weitergeben.</para>
</sect3>
<sect3>
<title>Zonendateien</title>
<indexterm>
<primary>BIND</primary>
<secondary>Zonendatei</secondary>
</indexterm>
<para>Die in der Datei
<filename>/etc/namedb/master/example.org</filename> definierte
Zonendatei für
<hostid role="domainname">example.org</hostid> könnte
etwa so aussehen:</para>
<programlisting>$TTL 3600 ; 1 hour default TTL
example.org. IN SOA ns1.example.org. admin.example.org. (
2006051501 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
300 ; Negative Response TTL
)
; DNS Servers
IN NS ns1.example.org.
IN NS ns2.example.org.
; MX Records
IN MX 10 mx.example.org.
IN MX 20 mail.example.org.
IN A 192.168.1.1
; Machine Names
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5
; Aliases
www IN CNAME example.org.</programlisting>
<para>Beachten Sie, dass jeder mit einem <quote>.</quote>
endende Rechnername ein exakter Rechnername ist, während
sich alles ohne einen abschließenden <quote>.</quote>
relativ auf den Ursprung bezieht. <literal>ns1</literal> steht
daher beispielsweise für
<literal>ns1.<replaceable>example.org.</replaceable></literal>.</para>
<para>Eine Zonendatei hat folgenden Aufbau:</para>
<programlisting>recordname IN recordtype value</programlisting>
<indexterm>
<primary>DNS</primary>
<secondary>Einträge</secondary>
</indexterm>
<para>Die am häufigsten verwendeten DNS-Einträge sind:</para>
<variablelist>
<varlistentry>
<term>SOA</term>
<listitem>
<para>Start der Zonenautorität</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NS</term>
<listitem>
<para>Ein autoritativer Nameserver</para>
</listitem>
</varlistentry>
<varlistentry>
<term>A</term>
<listitem><para>Eine Rechneradresse</para></listitem>
</varlistentry>
<varlistentry>
<term>CNAME</term>
<listitem>
<para>Der kanonische Name eines Alias</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MX</term>
<listitem><para>Mail Exchanger</para></listitem>
</varlistentry>
<varlistentry>
<term>PTR</term>
<listitem>
<para>Ein (bei Reverse-DNS verwendeter) Domain Name
Pointer</para>
</listitem>
</varlistentry>
</variablelist>
<programlisting>example.org. IN SOA ns1.example.org. admin.example.org. (
2006051501 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
300 ) ; Negative Response TTL</programlisting>
<variablelist>
<varlistentry>
<term><hostid role="domainname">example.org.</hostid></term>
<listitem><para>Der Name der Domäne und damit der
Ursprung dieser Zonendatei.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><hostid role="fqdn">ns1.example.org.</hostid></term>
<listitem><para>Der primäre/autoritative Nameserver
dieser Zone.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>admin.example.org.</literal></term>
<listitem><para>Die für diese Zone verantwortliche
Person. Das Zeichen <quote>@</quote> wird dabei
ersetzt (<email>admin@example.org</email> wird also zu
<literal>admin.example.org</literal>).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>2006051501</literal></term>
<listitem><para>Die Seriennummer der Datei. Sie muss
stets inkrementiert werden, wenn die Zonendatei
geändert wird. Viele Administratoren bevorzugen
ein <literal>JJJJMMTTRR</literal>-Format, um die
Seriennummer festzulegen.
<literal>2006051501</literal> steht also für
den 15.05.2006, die beiden letzten Stellen für die
erste Modifikation der Zonendatei an diesem Tag. Die
Seriennummer ist von großer Bedeutung, da
Slaveserver daran eine aktualisierte Zonendatei erkennen
können.</para>
</listitem>
</varlistentry>
</variablelist>
<programlisting>
IN NS ns1.example.org.</programlisting>
<para>Ein NS-Eintrag. Jeder Nameserver, der für eine Zone
verantwortlich ist, muss über einen solchen Eintrag
verfügen.</para>
<programlisting>
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5</programlisting>
<para>Der Eintrag <literal>A</literal> bezieht sich auf
Rechnernamen. <hostid role="fqdn">ns1.example.org</hostid>
würde also zu <hostid role="ipaddr">192.168.1.2</hostid>
aufgelöst werden.</para>
<programlisting>
IN A 192.168.1.1</programlisting>
<para>Diese Zeile weist die IP-Adresse
<hostid role="ipaddr">192.168.1.1</hostid> dem aktuellen
Ursprung, in unserem Fall also
<hostid role="domainname">example.org</hostid>, zu.</para>
<programlisting>
www IN CNAME @</programlisting>
<para>Der Eintrag für den kanonischen Namen wird dazu
verwendet, Aliase für einen Rechner zu vergeben. Im
Beispiel ist <hostid>www</hostid> ein Alias für den
<quote>Master</quote>-Rechner, dessen Name dem Domainnamen
<hostid role="domainname">example.org</hostid> (oder
<hostid role="ipaddr">192.168.1.1</hostid>) entspricht.
CNAMEs können daher niemals gleichzeitig mit einem
anderen Eintrag für denselben Hostname eingerichtet
werden.</para>
<indexterm>
<primary>MX-Eintrag</primary>
</indexterm>
<programlisting>
IN MX 10 mail.example.org.</programlisting>
<para>Die Option MX legt fest, welcher Mailserver für
eintreffende Mails der Zone verantwortlich ist.
<hostid role="fqdn">mail.example.org</hostid> ist der
Rechnername des Mailservers, der eine Priorität von 10
hat.</para>
<para>Es können auch mehrere Mailserver mit verschiedener
Priorität (10, 20, ...) vorhanden sein. Ein Mailserver,
der eine Mail an <hostid role="domainname">example.org</hostid>
verschicken will, verwendet zuerst den MX mit der höchsten
Priorität (das heißt den mit der niedrigsten
Prioritätsnummer), danach den mit der
nächsthöheren Priorität. Und dies solange,
bis die E-Mail zugestellt werden kann.</para>
<para>Für (bei Reverse-DNS verwendete)
<literal>in-addr.arpa</literal>-Zonendateien wird das gleiche
Format verwendet. Der einzige Unterschied besteht in der
Verwendung der Option PTR an Stelle der Optionen A und
CNAME.</para>
<programlisting>$TTL 3600
1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
2006051501 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
300 ) ; Negative Response TTL
IN NS ns1.example.org.
IN NS ns2.example.org.
1 IN PTR example.org.
2 IN PTR ns1.example.org.
3 IN PTR ns2.example.org.
4 IN PTR mx.example.org.
5 IN PTR mail.example.org.</programlisting>
<para>Durch diese Datei werden den Rechnernamen der fiktiven
Domäne IP-Adressen zugewiesen.</para>
<para>Beachten Sie bitte, dass es sich bei allen Namen auf der
rechten Seite eines PTR-Eintrags um absolute
(<emphasis>fully qualified</emphasis>) Domainnamen handeln
muss, die mit <quote>.</quote> enden.</para>
</sect3>
</sect2>
<sect2>
<title>Zwischenspeichernde (cachende) Nameserver</title>
<indexterm>
<primary>BIND</primary>
<secondary>Zwischenspeichernde Nameserver</secondary>
</indexterm>
<para>Ein cachender Nameserver hat primär die Aufgabe,
rekursive Abfragen aufzulösen. Er stellt lediglich
eigene Anfragen und speichert deren Ergebnisse ab.</para>
</sect2>
<sect2>
<title><acronym
role="Doman Name Security Extensions">DNSSEC</acronym></title>
<indexterm>
<primary>BIND</primary>
<secondary>DNS security extensions</secondary>
</indexterm>
<para>Domain Name System Security Extensions, oder kurz <acronym
role="Domain Name Security Extensions">DNSSEC</acronym>, ist eine
Sammlung von Spezifikationen, um auflösende Nameserver von
gefälschten <acronym>DNS</acronym>-Daten, wie beispielsweise
vorgetäuschte <acronym>DNS</acronym>-Einträge, zu
schützen. Durch die Verwendung von digitalen Signaturen kann
ein Resolver die Integrität des Eintrages
überprüfen. Wichtig dabei ist, dass <acronym
role="Domain Name Security Extensions">DNSSEC</acronym> nur die
Integrität über digital signierte Resource Records
(<acronym role="Resource Record">RR</acronym>e) bereitstellt.
Weder wird die Vertraulichkeit noch der Schutz vor falschen
Annahmen des Endbenutzers sichergestellt. Dies bedeutet, dass es
Leute nicht davor schützen kann, zu <hostid
role="domainname">example.net</hostid> anstatt zu <hostid
role="domainname">example.com</hostid> zu gelangen. Das
einzige, was <acronym>DNSSEC</acronym> tut, ist die
Authentifizierung, dass die Daten während der
Übertragung nicht verändert wurden. Die Sicherheit von
<acronym>DNS</acronym> ist ein wichtiger Schritt in der
generellen Absicherung des Internets. Für weitere,
tiefergehende Details über die Funktionsweise von
<acronym>DNSSEC</acronym> sind die dazugehörigen
<acronym>RFC</acronym>s ein guter Einstieg in die Thematik. Sehen
Sie sich dazu die Liste in <xref linkend="dns-read"/> an.</para>
<para>Der folgende Abschnitt wird zeigen, wie man
<acronym>DNSSEC</acronym> für einen autoritativen
<acronym>DNS</acronym>-Server und einen rekursiven (oder cachenden)
<acronym>DNS</acronym>-Server, der jeweils
<acronym>BIND</acronym> 9 verwenden, einrichten kann. Obwohl alle
Versionen von <acronym>BIND</acronym> 9 <acronym>DNSSEC</acronym>
unterstützen, ist es notwendig, mindestens die Version 9.6.2
zu verwenden, um in der Lage zu sein, die signierten Root-Zonen zu
benutzen, wenn <acronym>DNS</acronym>-Abfragen geprüft
werden. Der Grund dafür ist, dass früheren Versionen
die Algorithmen fehlen, um die Überprüfung des
Root-Zonenschlüssels zu aktivieren. Es wird dringend empfohlen,
die letzte Version von <acronym>BIND</acronym> 9.7 oder höher
einzusetzen, um von den Vorteilen der automatischen
Schlüsselaktualisierung des Root-Zonenschlüssels
Gebrauch zu machen, genauso wie andere Eigenschaften, um
automatisch Zonen signieren zu lassen und Signaturen aktuell zu
halten. Unterschiede zwischen den Versionen 9.6.2 und 9.7 und
höher werden an den betreffenden Stellen angesprochen.</para>
<sect3>
<title>Rekursive <acronym>DNS</acronym>-Server Konfiguration</title>
<para>Die Aktivierung der
<acronym>DNSSEC</acronym>-Überprüfung von Anfragen,
die von einem rekursiven <acronym>DNS</acronym>-Server
stammen, benötigt ein paar Änderungen in der
<filename>named.conf</filename>. Bevor man jedoch diese
Änderungen durchführt, muss der
Root-Zonenschlüssel oder Vertrauensanker erworben werden.
Momentan ist der Root-Zonenschlüssel nicht in einem
Dateiformat verfügbar, dass von <acronym>BIND</acronym>
benutzt werden kann, so dass dieser manuell in das richtige
Format konvertiert werden muss. Der Schlüssel selbst kann
durch Abfrage an die Root-Zone erhalten werden, indem man dazu
<application>dig</application> verwendet. Durch Aufruf
von</para>
<screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . > root.dnskey</userinput></screen>
<para>wird der Schlüssel in
<filename>root.dnskey</filename> abgelegt. Der Inhalt sollte
so ähnlich wie folgt aussehen:</para>
<programlisting>. 93910 IN DNSKEY 257 3 8 (
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
) ; key id = 19036
. 93910 IN DNSKEY 256 3 8 (
AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf
UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE
g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V
EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt
) ; key id = 34525</programlisting>
<para>Seien Sie nicht alarmiert, wenn der von Ihnen bezogene
Schlüssel anders als in diesem Beispiel aussieht. Diese
könnten sich in der Zwischenzeit geändert haben. In
dieser Ausgabe sind eigentlich zwei Schlüssel enthalten.
Der erste Schüssel mit dem Wert 257 nach dem
DNSKEY-Eintrag ist derjenige, der benötigt wird. Der
Wert zeigt an, dass es sich um einen sicheren Einstiegspunkt
(<acronym role="Secure Entry Point">SEP</acronym>), gemein
auch als Schlüsselsignierungsschlüssel (<acronym
role="Key Signing Key">KSK</acronym>) bekannt, handelt. Der
zweite Schüssel mit dem Wert 256 ist der untergeordnete
Schlüssel, im allgemeinen auch als
Zonen-Signaturschlüssel (<acronym
role="Zone Signing Key">ZSK</acronym>) bezeichnet. Weitere
Schlüsselarten werden später in <xref
linkend="dns-dnssec-auth"/> erläutert.</para>
<para>Nun muss der Schlüssel verifiziert und so formatiert
werden, dass <acronym>BIND</acronym> diesen verwenden kann.
Um den Schlüssel zu verifizieren, erzeugen Sie einen
<acronym role="Delegation Signer">DS</acronym> <acronym
role="Resource Record">RR</acronym>-Satz. Erstellen Sie eine
Datei, welche die <acronym
role="Resource Record">RR</acronym>s enthält,
mittels</para>
<screen>&prompt.user; <userinput>dnssec-dsfromkey -f root-dnskey . > root.ds</userinput></screen>
<para>Diese Einträge verwenden SHA-1 sowie SHA-256 und
sollten ähnlich zu folgendem Beispiel aussehen, in dem
der längere, SHA-256, benutzt wird.</para>
<programlisting>. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</programlisting>
<para>Der SHA-256 <acronym>RR</acronym> kann nun mit dem Abriss
in <ulink
url="https://data.iana.org/root-anchors/root-anchors.xml">https://data.iana.org/root-anchors/root-anchors.xml</ulink> verglichen werden. Um
absolut sicher zu sein, dass der Schlüssel nicht
zusammen mit den <acronym>XML</acronym>-Daten verändert
wurde, kann die Datei mittels der <acronym>PGP</acronym>
Signatur in <ulink
url="https://data.iana.org/root-anchors/root-anchors.asc">https://data.iana.org/root-anchors/root-anchors.asc</ulink> überprüft werden.</para>
<para>Als nächstes muss der Schlüssel in das passende
Format gebracht werden. Dies unterscheidet sich ein bisschen
von den <acronym>BIND</acronym> Versionen 9.6.2 und 9.7 und
höhere. In Version 9.7 wurde die Ünterstützung
zur automatischen Verfolgung und notwendigen Aktualisierung
von Änderungen am Schlüssel eingebaut. Dies wird
durch den Einsatz von <literal>managed-keys</literal>
erreicht, wie in dem Beispiel unten gezeigt ist. Wenn die
ältere Version eingesetzt wird, kann der Schlüssel
durch eine <literal>trusted-keys</literal>-Anweisung eingebaut
werden und die Aktualisierung muss händisch erfolgen.
In <acronym>BIND</acronym> 9.6.2 sollte das Format
folgendermassen aussehen:</para>
<programlisting>trusted-keys {
"." 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
};</programlisting>
<para>In 9.7 wird das Format stattdessen wie folgt
aussehen:</para>
<programlisting>managed-keys {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
};</programlisting>
<para>Der Root-Schlüssel kann nun zu
<filename>named.conf</filename> hinzugefügt werden,
entweder direkt oder durch Inkludierung der Datei, die den
Schlüssel enthält. Nachdem diese Schritte
absolviert sind, muss <acronym>BIND</acronym> konfiguriert
werden, um <acronym>DNSSEC</acronym>-Validierung für
Anfragen durchzuführen, indem
<filename>named.conf</filename> bearbeitet und die folgende
<literal>options</literal>-Direktive hinzugefügt
wird:</para>
<programlisting>dnssec-enable yes;
dnssec-validation yes;</programlisting>
<para>Um zu prüfen, dass es tatsächlich funktioniert,
benutzen Sie <application>dig</application>, um eine Anfrage
zu einer signierten Zone durch den Resolver, der gerade
konfiguriert wurde, zu stellen. Eine erfolgreiche Antwort
wird den <literal>AD</literal>-Eintrag aufweisen, um
anzudeuten, dass die Daten authentisiert sind. Eine Anfrage
wie</para>
<screen>&prompt.user; <userinput>dig @<replaceable>resolver</replaceable> +dnssec se ds </userinput></screen>
<para>sollte den <acronym>DS</acronym> <acronym>RR</acronym>
für die <literal>.se</literal>-Zone zurückgeben. In
dem Abschnitt <literal>flags:</literal> sollte der
<literal>AD</literal>-Eintrag gesetzt sein, wie im folgenden
zu sehen ist:</para>
<programlisting>...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
...</programlisting>
<para>Der Resolver ist nun in der Lage, Anfragen ans
<acronym>DNS</acronym> zu authentisieren.</para>
</sect3>
<sect3 id="dns-dnssec-auth">
<title>Autoritative <acronym>DNS</acronym>-Server
Konfiguration</title>
<para>Um einen autoritativen Nameserver dazu zu bringen, als
eine <acronym>DNSSEC</acronym>-signierte Zone zu fungieren,
ist ein wenig mehr Aufwand nötig. Eine Zone ist durch
kryptographische Schlüssel signiert, die erzeugt werden
müssen. Es ist möglich, nur einen Schlüssel
dazu zu verwenden. Die vorgeschlagene Methode ist jedoch,
einen starken, gut geschützten
Schlüsselsignierungsschlüssel (<acronym
role="Key Signing Key">KSK</acronym>) einzusetzen, der nicht
oft gewechselt wird und einen Zonensignierungsschlüssel
(<acronym role="Zone Signing Key">ZSK</acronym>), der
öfter ausgewechselt wird. Informationen zu
vorgeschlagenen Einsatzarten können in <ulink
url="http://tools.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym>
4641: <acronym>DNSSEC</acronym> Operational Practices</ulink>
nachgelesen werden. Einsatzszenarien, welche die Root-Zone
betreffen, finden Sie in <ulink
url="http://www.root-dnssec.org/wp-content/uploads/2010/06/icann-dps-00.txt"><acronym>DNSSEC</acronym> Practice Statement for the Root Zone
<acronym>KSK</acronym> operator</ulink> sowie <ulink
url="http://www.root-dnssec.org/wp-content/uploads/2010/06/vrsn-dps-00.txt"><acronym>DNSSEC</acronym> Practice Statement for the Root Zone
<acronym>ZSK</acronym> operator</ulink>. Der <acronym
role="Key Signing Key">KSK</acronym> wird dazu verwendet, um
eine Kette von Autorität für die Daten, die diese
Validierung benötigen, zu erschaffen und wird als solche
auch als sicherer Einstiegspunkt (<acronym
role="Secure Entry Point">SEP</acronym>)-Schlüssel
bezeichnet. Ein Nachrichtenabriss dieses Schlüssels,
der auch Delegation Signer (<acronym
role="Delegation Signer">DS</acronym>)-Eintrag genannt wird,
muss in der Elternzone veröffentlicht werden, um die
Vertrauenskette herzustellen. Wie dies erreicht wird,
hängt von dem Besitzer der Elternzone ab. Der <acronym
role="Zone Signing Key">ZSK</acronym> wird verwendet, um die
Zone zu signieren und muss nur dort öffentlich
zugänglich gemacht werden.</para>
<para>Um <acronym>DNSSEC</acronym> für die <hostid
role="domainname">example.com</hostid>-Zone, welche in den
vorherigen Beispielen verwendet wird, zu aktivieren, muss
als erster Schritt <application>dnssec-keygen</application>
benutzt werden, um das <acronym>KSK</acronym> und
<acronym>ZSK</acronym> Schlüsselpaar zu generieren.
Dieses Schlüsselpaar kann unterschiedliche
kryptographische Algorithmen nutzen. Es wird empfohlen,
RSA/SHA256 für die Schlüssel zu nutzen. Eine
Schlüssellänge von 2048 Bits sollte genügen.
Um den <acronym>KSK</acronym> für <hostid
role="domainname">example.com</hostid> zu generieren, geben
Sie</para>
<screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
<para>ein und um den <acronym>ZSK</acronym> zu erzeugen, setzen
Sie folgenden Befehl ab:</para>
<screen>&prompt.user; <userinput>dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen>
<para><application>dnssec-keygen</application> gibt zwei
Dateien aus, den öffentlichen und den privaten
Schlüssel und zwar in Dateinamen, die ähnlich
lauten wie <filename>Kexample.com.+005+nnnnn.key</filename>
(öffentlich) und
<filename>Kexample.com.+005+nnnnn.private</filename>
(privat). Der <literal>nnnnn</literal>-Teil des Dateinamens
ist eine fünfstellige Schlüsselkennung. Passen
Sie genau auf, welche Kennung zu welchem Schlüssel
gehört. Das ist besonders wichtig, wenn mehrere
Schlüssel in einer Zone vorliegen. Es ist auch
möglich, die Schlüssel umzubenennen. Für
jede <acronym>KSK</acronym>-Datei tun Sie folgendes:</para>
<screen>&prompt.user; <userinput>mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key</userinput>
&prompt.user; <userinput>mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private</userinput></screen>
<para>Für die <acronym>ZSK</acronym>-Dateien ersetzen Sie
<literal>KSK</literal> für <literal>ZSK</literal> wenn
nötig. Die Dateien können nun in der Zonendatei
inkludiert werden, indem die <literal>$include</literal>
Anweisung verwendet wird. Es sollte folgendermassen
aussehen:</para>
<programlisting>$include Kexample.com.+005+nnnnn.KSK.key ; KSK
$include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting>
<para>Schliesslich signieren Sie die Zone und weisen
<acronym>BIND</acronym> an, die signierte Zonendatei zu
benutzen. Um eine Zone zu signieren, wird
<application>dnssec-signzone</application> eingesetzt. Der
Befehl, um eine Zone <hostid
role="domainname">example.com</hostid> zu signieren, die in
<filename>example.com.db</filename> liegt, sollte
wie folgt aussehen:</para>
<screen>&prompt.user; <userinput>dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key</userinput></screen>
<para>Der Schlüssel, welcher mit dem Argument
<option>-k</option> übergeben wird, ist der
<acronym>KSK</acronym> und die andere Schlüsseldatei ist
der <acronym>ZSK</acronym>, welcher für die Signatur
benutzt werden soll. Es ist möglich, mehr als einen
<acronym>KSK</acronym> und <acronym>ZSK</acronym> anzugeben,
was das Ergebnis zur Folge hat, dass die Zone mit allen
übergebenen Schlüsseln signiert wird. Dies kann
dann benötigt werden, um Zonendaten mit mehr als einem
Algorithmus zur Signierung zu verwenden. Die Ausgabe von
<application>dnssec-signzone</application> ist eine
Zonendatei mit allen signierten <acronym>RR</acronym>s.
Diese Ausgabe wird in einer Datei mit der Endung
<literal>.signed</literal> abgelegt, wie beispielsweise
<filename>example.com.db.signed</filename>. Die <acronym
role="Delegation Signer">DS</acronym>-Einträge werden
ebenfalls in eine separate Datei
<filename>dsset-example.com</filename> geschrieben. Um diese
signierte Zone zu verwenden, ändern Sie die
Zonendirektive in <filename>named.conf</filename>, so dass
<filename>example.com.db.signed</filename> benutzt wird.
Standardmässig sind die Signaturen nur 30 Tage
gültig, was bedeutet, dass die Zone in etwa 15 Tagen
erneut signiert werden muss, um sicher zu stellen, dass
Resolver keine Einträge mit veralteten Signaturen
zwischenspeichern. Es ist möglich, ein Skript und einen
cron-Job zu schreiben, um dies zu erledigen. Lesen Sie dazu
die relevanten Anleitungen, um Details zu erfahren.</para>
<para>Stellen Sie sicher, dass die privaten Schlüssel
vertraulich bleiben, genau wie mit allen anderen
kryptographischen Schlüsseln auch. Wenn ein
Schlüssel geändert wird, ist es gute Praxis den
neuen Schlüssel in die Zone zu inkludieren, noch
während der alte Schlüssel noch zum signieren
eingesetzt wird, um dann auf den neuen Schlüssel zum
signieren zu wechseln. Nachdem diese Schritte erfolgt sind,
kann der alte Schlüssel aus der Zone entfernt werden.
Wenn das nicht geschieht, können
<acronym>DNS</acronym>-Daten für einige Zeit nicht
verfügbar sein, bis der neue Schlüssel durch die
<acronym>DNS</acronym>-Hierarchie propagiert wurde.
Für weitere Informationen bezüglich
Schlüsselübergabe und andere
<acronym>DNSSEC</acronym>-Einsatzszenarien lesen Sie <ulink
url="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym>
4641: <acronym>DNSSEC</acronym> Operational practices</ulink>.</para>
</sect3>
<sect3>
<title>Automatisierung mittels <acronym>BIND</acronym> 9.7 oder
höher</title>
<para>Beginnend mit der Version 9.7 von <acronym>BIND</acronym>
wurde eine neue Eigenschaft vorgestellt, die
<emphasis>Smart Signing</emphasis> genannt wird. Diese zielt
darauf ab, das Schlüsselmanagement und den
Signierungsprozess einfacher zu gestalten und zu
automatisieren. Durch ablegen der Schlüssel in ein
Verzeichnis, genannt <emphasis>key repository</emphasis>
und die Verwendung der neuen Option
<literal>auto-dnssec</literal>, ist es möglich eine
dynamische Zone zu erzeugen, welche dann erneut signiert
wird, wenn dazu der Bedarf besteht. Um diese Zone zu
aktualisieren, benutzen Sie
<application>nsupdate</application> mit der neuen Option
<option>-l</option>. Es hat also
<application>rndc</application> die Fähigkeit gewonnen,
Zonen mit Schlüsseln im Key Repository zu verwenden,
indem die Option <option>sign</option> eingesetzt wird. Um
<acronym>BIND</acronym> anzuweisen, diese automatische
Signierung und Zonenaktualisierung für <hostid
role="domainname">example.com</hostid> zu nutzen, fügen
Sie die folgenden Zeilen zur <filename>named.conf</filename>
hinzu:</para>
<programlisting>zone example.com {
type master;
key-directory "/etc/named/keys";
update-policy local;
auto-dnssec maintain;
file "/etc/named/dynamic/example.com.zone";
};</programlisting>
<para>Nachdem diese Änderungen durchgeführt wurden,
erzeugen Sie die Schlüssel für die Zone wie in
<xref linkend="dns-dnssec-auth"/> beschrieben wird, legen
diese Schlüssel im Key Repository ab, dass als Argument
<literal>key-directory</literal> in der Zonenkonfiguration
steht und die Zone wird automatisch signiert.
Aktualisierungen für eine Zone, die auf diese Art und
Weise konfiguriert wurde, muss mittels
<application>nsupdate</application> erfolgen, dass sich um
die erneute Signierung der Zone mit den hinzugefügten
Daten kümmern wird. Für weitere Details, lesen
Sie <xref linkend="dns-read"/> und die Dokumentation von
<acronym>BIND</acronym>.</para>
</sect3>
</sect2>
<sect2>
<title>Sicherheit</title>
<para>Obwohl BIND die am meisten verwendete (und kontrollierte)
Implementierung von DNS darstellt, werden dennoch manchmal neue
Sicherheitsprobleme entdeckt.</para>
<para>Zwar startet &os; <application>named</application>
automatisch in einer &man.chroot.8;-Umgebung, es gibt aber
noch weitere Sicherheitsmechanismen, mit denen Sie potentielle
<acronym>DNS</acronym>-Serviceattacken erschweren
können.</para>
<para>Es ist daher eine gute Idee, die Sicherheitshinweise von
<ulink url="http://www.cert.org/">CERT</ulink> zu lesen sowie
die Mailingliste &a.security-notifications; zu abonnieren, um
sich über Sicherheitsprobleme im Zusammenhang mit dem
Internet und FreeBSD zu informieren.</para>
<tip>
<para>Tritt ein Problem auf, kann es nie schaden, die
Quellen zu aktualisieren und <application>named</application>
neu zu kompilieren.</para>
</tip>
</sect2>
<sect2 id="dns-read">
<title>Weitere Informationsquellen</title>
<para>Hilfeseiten zu BIND/<application>named</application>:
&man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8;
&man.dnssec-signzone.8; &man.dnssec-keygen.8;</para>
<itemizedlist>
<listitem>
<para><ulink
url="https://www.isc.org/software/bind">Offizielle ISC-Seite
zu BIND</ulink></para>
</listitem>
<listitem>
<para><ulink
url="https://www.isc.org/software/guild">Offizielles Forum zu
ISC- BIND</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.oreilly.com/catalog/dns5/">O'Reilly
DNS and BIND 5th Edition</ulink></para>
</listitem>
<listitem>
<para><ulink
url="http://www.root-dnssec.org/documentation/">Root
<acronym>DNSSEC</acronym></ulink></para>
</listitem>
<listitem>
<para><ulink
url="http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html">
<acronym>DNSSEC</acronym> Vertrauensanker-Publikation für
die Root-Zone</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://tools.ietf.org/html/rfc1034">RFC1034
- Domain Names - Concepts and Facilities</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://tools.ietf.org/html/rfc1035">RFC1035
- Domain Names - Implementation and
Specification</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://tools.ietf.org/html/rfc4033">RFC4033
- DNS Security Introduction and Requirements</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://tools.ietf.org/html/rfc4034">RFC4034
- Resource Records for the DNS Security
Extensions</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://tools.ietf.org/html/rfc4035">RFC4035
- Protocol Modifications for the DNS Security
Extensions</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://tools.ietf.org/html/rfc4641">RFC4641
- DNSSEC Operational Practices</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://tools.ietf.org/html/rfc5011">RFC 5011
- Automated Updates of DNS Security (<acronym>DNSSEC</acronym>)
Trust Anchors</ulink></para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="network-apache">
<sect1info>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
</sect1info>
<title>Der Apache HTTP-Server</title>
<indexterm>
<primary>Webserver</primary>
<secondary>konfigurieren</secondary>
</indexterm>
<indexterm><primary>Apache</primary></indexterm>
<sect2>
<title>Überblick</title>
<para>Einige der weltgrößten Internetauftritte laufen
unter &os;. Die Mehrzahl der Webserver im Internet nutzt
den <application>Apache</application> HTTP-Server. Die
Installationspakete für den
<application>Apache</application> sollten auf Ihrem
Installationsmedium vorhanden sein. Wenn Sie den
<application>Apache</application> noch nicht installiert haben,
können Sie dies jederzeit über den Port
<filename role="package">www/apache13</filename> oder
<filename role="package">www/apache22</filename> nachholen.</para>
<para>Nachdem der <application>Apache</application> erfolgreich
installiert wurde, muss er noch konfiguriert werden.</para>
<note><para>Dieser Abschnitt beschreibt die Version 1.3.X des
<application>Apache</application> HTTP-Servers, da diese Version
unter &os; am häufigsten verwendet wird.
<application>Apache</application> 2.X bringt zwar viele
Verbesserungen mit sich, wird hier aber nicht beschrieben.
Sollten Sie an <application>Apache</application> 2.X
interessiert sein, informieren Sie sich bitte auf
<ulink url="http://httpd.apache.org/"></ulink>.</para></note>
</sect2>
<sect2>
<title>Konfiguration</title>
<indexterm><primary>Apache</primary>
<secondary>Konfigurationsdatei</secondary></indexterm>
<para>Der <application>Apache</application> HTTP-Server wird unter
&os; primär über die Datei
<filename>/usr/local/etc/apache/httpd.conf</filename>
konfiguriert. Bei dieser Datei handelt es sich um eine typische
&unix;-Konfigurationsdatei, in der Kommentarzeilen mit einem
<literal>#</literal>-Zeichen beginnen. Eine komplette
Beschreibung aller Optionen würde den Rahmen dieses
Handbuchs sprengen, daher beschreiben wir hier nur die am
häufigsten verwendeten Optionen.</para>
<variablelist>
<varlistentry>
<term><literal>ServerRoot "/usr/local"</literal></term>
<listitem>
<para>Legt das Standardwurzelverzeichnis für die
<application>Apache</application>-Installation fest.
Binärdateien werden in die Verzeichnisse
<filename class="directory">bin</filename> und
<filename class="directory">sbin</filename> unterhalb des
Serverwurzelverzeichnisses installiert, während sich
Konfigurationsdateien im Verzeichnis
<filename class="directory">etc/apache</filename>
befinden.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ServerAdmin you@your.address</literal></term>
<listitem>
<para>Die E-Mail-Adresse, an die Mitteilungen über
Serverprobleme geschickt werden sollen. Diese Adresse
erscheint auf vom Server erzeugten Seiten, beispielsweise
auf Fehlerseiten.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ServerName www.example.com</literal></term>
<listitem>
<para>Über die Option <literal>ServerName</literal>
können Sie einen Rechnernamen festlegen, den Ihr
Server an die Clients sendet, wenn sich dieser von
tatsächlichen Rechnernamen unterscheidet (sie
könnten etwa <hostid>www</hostid> statt des richtigen
Rechnernamens verwenden).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>DocumentRoot "/usr/local/www/data"</literal></term>
<listitem>
<para><literal>DocumentRoot</literal>: Das Verzeichnis, in
dem Sie Ihre Dokumente ablegen. In der Voreinstellung
befinden sich alle Seiten in diesem Verzeichnis, durch
symbolische Links oder Aliase lassen sich aber auch andere
Orte festlegen.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Es ist empfehlenswert, eine Sicherungskopie Ihrer
Konfigurationsdatei anzulegen, bevor Sie Änderungen
durchführen. Nachdem Sie die Konfiguration beendet
haben, können Sie den
<application>Apache</application> starten.</para>
<!-- sect3 for performance tuning directives? maxservers minservers -->
<!-- etc..?? -->
<!-- Advanced configuration section.
Performance tuning directives.
Log file format -->
</sect2>
<sect2>
<title>Den <application>Apache</application> betreiben</title>
<indexterm><primary>Apache</primary>
<secondary>Starten oder Beenden</secondary></indexterm>
<para>Der <application>Apache</application> wird, im Gegensatz zu
vielen anderen Netzwerkservern, nicht vom
<application>inetd</application>-Super-Server verwaltet, sondern
wird als eigenständiger Server betrieben, um die
Leistung für eintreffende HTTP-Anfragen von den Clients
(also von Internetbrowsern) zu verbessern. Gestartet, beendet
oder neu gestartet wird der Server über einen
Shellskript-Wrapper. Um den <application>Apache</application>
erstmals zu starten, geben Sie einfach Folgendes ein:</para>
<screen>&prompt.root; <userinput>/usr/local/sbin/apachectl start</userinput></screen>
<para>Wenn Sie den Server beenden wollen, geben Sie Folgendes ein:</para>
<screen>&prompt.root; <userinput>/usr/local/sbin/apachectl stop</userinput></screen>
<para>Wenn Sie die Konfigurationsdatei verändern, müssen
Sie den Server neu starten:</para>
<screen>&prompt.root; <userinput>/usr/local/sbin/apachectl restart</userinput></screen>
<para>Um den <application>Apache</application> ohne den Abbruch
bestehender Verbindungen neu zu starten, geben Sie Folgendes
ein:</para>
<screen>&prompt.root; <userinput>/usr/local/sbin/apachectl graceful</userinput></screen>
<para>Diese und weitere Optionen werden in
&man.apachectl.8; beschrieben.</para>
<para>Um den <application>Apache</application> beim Systemstart
zu starten, fügen Sie folgende Zeile in
<filename>/etc/rc.conf</filename> ein:</para>
<programlisting>apache_enable="YES"</programlisting>
<para>Um <application>Apache</application> 2.2 zu starten,
fügen Sie hingegen folgende Zeile ein:</para>
<programlisting>apache22_enable="YES"</programlisting>
<para>Wenn Sie während des Systemstarts weitere Parameter an
den
<application>Apache</application>-<command>httpd</command>-Daemon
übergeben wollen, können Sie diese durch eine
zusätzliche Zeile in <filename>rc.conf</filename>
angeben:</para>
<programlisting>apache_flags=""</programlisting>
<para>Nachdem der Webserver gestartet ist, können Sie sich
Ihre Internetseite ansehen, indem Sie in Ihren Browser die
Adresse <literal>http://localhost/</literal> eingeben. Die
vordefinierte Standardstartseite ist
<filename>/usr/local/www/data/index.html</filename>.</para>
</sect2>
<sect2>
<title>Virtual Hosting</title>
<para>Der <application>Apache</application> unterstützt zwei
Formen des <foreignphrase>Virtual Hostings</foreignphrase>. Die
erste Möglichkeit bezeichnet man als namenbasiertes
virtuelles Hosting. Dabei wird der HTTP/1.1-Header der Clients
dazu verwendet, den Rechnernamen zu bestimmen. Dadurch wird es
möglich, mehrere Domains unter der gleichen IP-Adresse zu
betreiben.</para>
<para>Damit der <application>Apache</application> namenbasierte
virtuelle Domains verwalten kann, fügen Sie die folgende
Zeile in <filename>httpd.conf</filename> ein:</para>
<programlisting>NameVirtualHost *</programlisting>
<para>Wenn Ihr Webserver
<hostid role="fqdn">www.domain.tld</hostid> heißt und Sie die
virtuelle Domain
<hostid role="fqdn">www.someotherdomain.tld</hostid> einrichten
wollen, ergänzen Sie <filename>httpd.conf</filename> um
folgende Einträge:</para>
<screen><VirtualHost *>
ServerName www.domain.tld
DocumentRoot /www/domain.tld
</VirtualHost>
<VirtualHost *>
ServerName www.someotherdomain.tld
DocumentRoot /www/someotherdomain.tld
</VirtualHost></screen>
<para>Ersetzen Sie dabei die Adressen sowie den Pfad zu den
Dokumenten durch Ihre eigenen Einstellungen.</para>
<para>Ausführliche Informationen zum Einrichten von
virtuellen Domains finden Sie in der offiziellen
<application>Apache</application>-Dokumentation unter
<ulink
url="http://httpd.apache.org/docs/vhosts/"></ulink>.</para>
</sect2>
<sect2>
<title>Häufig verwendete Apache-Module</title>
<indexterm><primary>Apache</primary>
<secondary>Module</secondary></indexterm>
<para>Es gibt viele verschiedene
<application>Apache</application>-Module, die den Server
um zusätzliche Funktionen erweitern. Die
FreeBSD-Ports-Sammlung ermöglicht es Ihnen, den
<application>Apache</application> gemeinsam mit einigen der
beliebtesten Zusatzmodule zu installieren.</para>
<sect3>
<title>mod_ssl</title>
<indexterm>
<primary>Webserver</primary>
<secondary>Verschlüsselung</secondary>
</indexterm>
<indexterm>
<primary>SSL</primary>
</indexterm>
<indexterm>
<primary>Verschlüsselung</primary>
</indexterm>
<para>Das Modul <application>mod_ssl</application> verwendet die
OpenSSL-Bibliothek, um, unter Nutzung der Protokolle Secure
Sockets Layer (SSL v2/v3) sowie Transport Layer Security
(TLS v1) starke Verschlüsselung zu ermöglichen.
Durch dieses Modul können Sie ein signiertes Zertifikat
von einer Zertifizierungsstelle anfordern, damit Sie einen
sicheren Webserver unter &os; betreiben können.</para>
<para>Wenn Sie den <application>Apache</application> 1.3.X noch
nicht installiert haben, können Sie über den
Port <filename
role="package">www/apache13-modssl</filename> eine
<application>Apache</application>-Version installieren, in die
<application>mod_ssl</application> als Modul einkompiliert
wurde. Bevorzugen Sie den
<application>Apache</application> 2.X, installieren Sie
stattdessen den Port
<filename role="package">www/apache22</filename>, bei dem die
SSL-Unterstützung bereits in der Voreinstellung aktiviert
ist.</para>
<!-- XXX add more information about configuring mod_ssl here. -->
<!-- Generating keys, getting the key signed, setting up your secure -->
<!-- web server! -->
</sect3>
<sect3>
<title>Skriptsprachen</title>
<para>Für die wichtigsten Skriptsprachen existieren Module,
die es erlauben, <application>Apache</application>-Module
nahezu vollständig in einer Skriptsprache zu programmieren.
Derartige Module dienen oft dazu, einen Sprach-Interpreter in
den Webserver einzubetten. Dadurch wird ein zusätzlicher
externer Interpreter überflüssig, was die Startzeit
von dynamischen Internetseiten deutlich verringert.</para>
</sect3>
</sect2>
<sect2>
<title>Dynamische Webseiten</title>
<indexterm><primary>Webserver</primary>
<secondary>dynamisch</secondary></indexterm>
<para>In den vergangenen Jahren haben immer mehr Unternehmen
das Internet als Mittel für die Steigerung ihrer
Einnahmen sowie für die Erhöhung ihrer Reichweite
entdeckt. Dadurch stieg auch die Nachfrage nach interaktiven
Internetinhalten. Neben einigen Unternehmen, darunter
µsoft;, die dafür proprietäre Produkte
entwickelt haben, hat auch die Open Source Community auf
diesen Umstand reagiert und unter anderem mit Django,
Ruby on Rails, <application>mod_perl</application>, und
<application>mod_php</application> Möglichkeiten zur
Generierung dynamischer Internetseiten geschaffen.</para>
<sect3>
<title>Django</title>
<indexterm><primary>Python</primary></indexterm>
<indexterm><primary>Django</primary></indexterm>
<para>Bei <foreignphrase>Django</foreignphrase> handelt es
sich um ein unter der BSD-Lizenz verfügbares
Framework zur schnellen Erstellung von mächtigen
Internet-Applikationen. Es beinhaltet einen
objekt-relationalen Mapper (wodurch Datentypen als
Phyton-Objekte entwickelt werden können) sowie eine
API für den dynamischen Datenbankzugriff auf diese
Objekte, ohne dass Entwickler jemals SQL-Code schreiben
müssen. Zusätzlich existiert ein umfangreiches
Template-System, wodurch die Programmlogik von der
HTML-Präsentation getrennt werden kann.</para>
<para>Django setzt das Modul
<application>mod_python</application>,
den <application>Apache</application>-Webserver sowie eine
SQL-Datenbank voraus. Für FreeBSD gibt es einen Port,
der alle Abhängigkeiten mit sinnvollen Optionen
konfiguriert und installiert.</para>
<example id="network-www-django-install">
<title>Django mit Apache2, mod_python3, und PostgreSQL
installieren</title>
<screen>&prompt.root; <userinput>cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL</userinput></screen>
</example>
<para>Nachdem Django (sowie die abhängigen Pakete)
installiert ist, müssen Sie ein Projektverzeichnis
erstellen. Danach konfigurieren Sie Apache so, dass
der eingebettete Python-Interpreter spezifische URLs
Ihrer Seiten aufruft.</para>
<example id="network-www-django-apache-config">
<title>Apache-Konfiguration für Django/mod_python</title>
<para>Sie müssen die Apache-Konfigurationsdatei
<filename>httpd.conf</filename> anpassen, damit Apache
Anfragen für bestimmte URLs an Ihre
Internet-Applikation übergibt:</para>
<screen><Location "/">
SetHandler python-program
PythonPath "['/dir/to/your/django/packages/'] + sys.path"
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonAutoReload On
PythonDebug On
</Location></screen>
</example>
</sect3>
<sect3>
<title>Ruby on Rails</title>
<indexterm><primary>Ruby on Rails</primary></indexterm>
<para>Bei <foreignphrase>Ruby on Rails</foreignphrase> handelt
es sich um ein weiteres, als Open Source verfügbares
Webframework. Es bietet einen kompletten Entwicklungsstack
und erlaubt es Webentwicklern, umfangreiche und mächtige
Applikationen in kurzer Zeit zu programmieren. Das
Framework kann über die Ports-Sammlung installiert
werden.</para>
<screen>&prompt.root; <userinput>cd /usr/ports/www/rubygem-rails; make all install clean</userinput></screen>
</sect3>
<sect3>
<title>mod_perl</title>
<indexterm>
<primary>mod_perl</primary>
<secondary>Perl</secondary>
</indexterm>
<para>Die Kombination <application>Apache</application>/Perl
vereinigt die Vorteile der Programmiersprache Perl und des
<application>Apache</application> HTTP-Servers. Durch
das Modul <application>mod_perl</application> ist es
möglich, vollständig in Perl geschriebene
<application>Apache</application>-Module zu erzeugen.
Da der Perl-Interpreter in den Server eingebettet wird,
müssen Sie weder einen externen Interpreter noch
Perl zusätzlich aufrufen.</para>
<para><application>mod_perl</application> ist in verschiedenen
Versionen erhältlich. Bevor Sie
<application>mod_perl</application> einsetzen,denken Sie
bitte daran, dass <application>mod_perl</application> 1.0
nur mit <application>Apache</application> 1.3 und
<application>mod_perl</application> 2.0 nur mit
<application>Apache</application> 2.X zusammenarbeitet.
<application>mod_perl</application> 1.0 kann über
den Port <filename role="package">www/mod_perl</filename>,
eine statisch kompilierte Version hingegen über den
Port <filename role="package">www/apache13-modperl</filename>
installiert werden. Für die Installation von
<application>mod_perl</application> 2.0 schließlich
verwenden Sie den Port <filename
role="package">www/mod_perl2</filename>.</para>
</sect3>
<sect3>
<sect3info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Geschrieben von </contrib>
</author>
</authorgroup>
</sect3info>
<title>mod_php</title>
<indexterm>
<primary>mod_php</primary>
<secondary>PHP</secondary>
</indexterm>
<para>Bei PHP, dem <quote>Hypertext Preprocessor</quote>,
handelt es sich um eine vielseitig verwendbare Skriptsprache,
die besonders für die Internetprogrammierung geeignet
ist. PHP kann in <acronym>HTML</acronym> eingebettet werden
und ähnelt von der Syntax her Sprachen wie C, &java; und
Perl. Das Hauptanliegen von PHP ist es, Internetprogrammierern
die rasche Erstellung von dynamisch erzeugten Internetseiten zu
ermöglichen.</para>
<para>Damit Ihr System <acronym>PHP</acronym>5 unterstützt,
müssen Sie als Erstes den <application>Apache</application>
Webserver über den Port
<filename role="package">lang/php5</filename>
installieren.</para>
<para>Wenn Sie den Port <filename role="package">lang/php5</filename>
das erste Mal installieren, werden die verfügbaren Optionen
(<literal>OPTIONS</literal>) automatisch angezeigt. Erscheint das
Konfigurationsmenü bei Ihnen nicht, so liegt dies daran,
dass Sie den Port <filename role="package">lang/php5</filename>
schon einmal auf Ihrem System installiert hatten. Es ist aber
jederzeit möglich, dieses Menü aus dem
Ports-Verzeichnis heraus über folgenden Befehl erneut
aufzurufen:</para>
<screen>&prompt.root; <userinput>make config</userinput></screen>
<para>In diesem Konfigurationsmenü müssen Sie die
Option <literal>APACHE</literal> auswählen, damit
<application>mod_php5</application> als ein vom
<application>Apache</application>-Webserver ladbares Modul
gebaut wird.</para>
<note>
<para>Viele Seiten verwenden nach wie vor (beispielsweise wegen
der benötigten Kompatibilität zu bereits
vorhandenen Web-Applikationen) <acronym>PHP</acronym>4.
Ist dies bei Ihnen der Fall, so müssen Sie statt
<application>mod_php5</application>
<application>mod_php4</application> über den Port
<filename role="package">lang/php4</filename> installieren.
Der Port <filename role="package">lang/php4</filename>
unterstützt viele der Konfigurations- und
Laufzeitoptionen von <filename
role="package">lang/php5</filename>.</para>
</note>
<para>Dieser Port installiert und konfiguriert die Module, die
für die Unterstützung von dynamischen
<acronym>PHP</acronym>-Anwendungen benötigt werden.
Stellen Sie danach sicher, dass Ihre
<filename>/usr/local/etc/apache/httpd.conf</filename> die
folgenden Abschnitte enthält:</para>
<programlisting>LoadModule php5_module libexec/apache/libphp5.so</programlisting>
<programlisting>AddModule mod_php5.c
<IfModule mod_php5.c>
DirectoryIndex index.php index.html
</IfModule>
<IfModule mod_php5.c>
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
</IfModule></programlisting>
<para>Nachdem dies erledigt ist, rufen Sie
<command>apachectl</command> auf, um das
<acronym>PHP</acronym>-Modul zu laden:</para>
<screen>&prompt.root; <userinput>apachectl graceful</userinput></screen>
<para>Bei künftigen Upgrades von <acronym>PHP</acronym>
wird <command>make config</command> nicht mehr benötigt,
da die von Ihnen ursprünglich ausgewählten
Optionen (<literal>OPTIONS</literal>) vom
&os;-Ports-Framework automatisch gespeichert werden.</para>
<para>Die <acronym>PHP</acronym>-Unterstützung von &os; ist
stark modular aufgebaut, daher verfügt eine
Basisinstallation nur über wenige Funktionen. Eine
Erweiterung um zusätzliche Funktionen ist allerdings sehr
einfach über den Port <filename
role="package">lang/php5-extensions</filename> möglich.
Der Port bietet Ihnen ein Auswahlmenü, über das Sie
verschiedene <acronym>PHP</acronym>-Erweiterungen installieren
können. Alternativ können Sie einzelne Erweiterungen
aber weiterhin direkt über den jeweiligen Port
installieren.</para>
<para>Um beispielsweise die Unterstützung des
Datenbankservers <application>MySQL</application> in
<acronym>PHP</acronym>5 zu aktivieren, installieren Sie
den Port <filename>databases/php5-mysql</filename>.</para>
<para>Nachdem Sie eine Erweiterung installiert haben,
müssen Sie den
<application>Apache</application>-Server neu starten, damit
die Erweiterung auch erkannt wird:</para>
<screen>&prompt.root; <userinput>apachectl graceful</userinput></screen>
<para>Ab nun wird <application>MySQL</application> von
<application>PHP</application> unterstützt.</para>
</sect3>
</sect2>
</sect1>
<sect1 id="network-ftp">
<sect1info>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
</sect1info>
<title>FTP – File Transfer Protocol</title>
<indexterm><primary>FTP-Server</primary></indexterm>
<sect2>
<title>Überblick</title>
<para>Das File Transfer Protocol (FTP) ermöglicht
auf einfache Art und Weise den Dateiaustausch mit einem
<acronym role="File Transfer Protocol">FTP</acronym>-Server.
Der
<acronym role="File Transfer Protocol">FTP</acronym>-Server
<application>ftpd</application> ist bei &os; bereits im
Basisystem enthalten. Daher sind Konfiguration und Betrieb
eines
<acronym role="File Transfer Protocol">FTP</acronym>-Servers
unter FreeBSD relativ einfach.</para>
</sect2>
<sect2>
<title>Konfiguration</title>
<para>Der wichtigste Punkt ist hier die Entscheidung darüber,
welche Benutzer auf Ihren FTP-Server zugreifen dürfen.
Ein FreeBSD-System verfügt über diverse
Systembenutzerkonten, um einzelnen Daemonen den Zugriff auf
das System zu ermöglichen. Anonyme Benutzer sollten sich
allerdings nicht über diese Benutzerkonten anmelden
dürfen. Die Datei <filename>/etc/ftpusers</filename>
enthält alle Benutzer, die vom FTP-Zugriff ausgeschlossen
sind. In der Voreinstellung gilt dies auch die gerade
erwähnten Systembenutzerkonten. Sie können über
diese Datei weitere Benutzer vom FTP-Zugriff
ausschließen.</para>
<para>Sie können den Zugriff für einige Benutzer
einschränken, ohne FTP komplett zu verbieten. Dazu
passen Sie <filename>/etc/ftpchroot</filename> entsprechend an.
Diese Datei enthält Benutzer und Gruppen sowie die für
sie geltenden FTP-Einschränkungen und wird in
&man.ftpchroot.5; ausführlich beschrieben.</para>
<indexterm>
<primary>FTP</primary>
<secondary>anonymous</secondary>
</indexterm>
<para>Wenn Sie einen anonymen FTP-Zugriff auf Ihren Server
ermöglichen wollen, müssen Sie den Benutzer
<username>ftp</username> auf Ihrem &os;-System anlegen.
Danach können sich Benutzer mit dem Benutzernamen
<username>ftp</username> oder <username>anonymous</username>
auf Ihrem FTP-Server anmelden. Das Passwort ist dabei
beliebig (allerdings wird dazu in der Regel eine E-Mail-Adresse
verwendet). Meldet sich ein anonymer Benutzer an, aktiviert
der FTP-Server &man.chroot.2;, um den Zugriff auf das
Heimatverzeichnis des Benutzers <username>ftp</username>
zu beschränken.</para>
<para>Es gibt zwei Textdateien, deren Inhalt Sie bei der Anmeldung
an Ihrem FTP-Server anzeigen lassen können. Der Inhalt von
<filename>/etc/ftpwelcome</filename> wird angezeigt, bevor der
Login-Prompt erscheint. Nach einer erfolgreichen Anmeldung wird
der Inhalt von <filename>/etc/ftpmotd</filename> angezeigt.
Beachten Sie aber, dass es dabei um einen Pfad relativ zur
Umgebung des anzumeldenden Benutzers handelt. Bei einer
anonymen Anmeldung würde also die Datei
<filename>~ftp/etc/ftpmotd</filename> angezeigt.</para>
<para>Nachdem Sie den FTP-Server konfiguriert haben, müssen
Sie Ihn in <filename>/etc/inetd.conf</filename> aktivieren.
Dazu müssen Sie lediglich das Kommentarsymbol
<quote>#</quote> am Beginn der bereits vorhandenen
<application>ftpd</application>-Zeile entfernen:</para>
<programlisting>ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l</programlisting>
<para>Nachdem Sie diese Änderung durchgeführt haben,
müssen Sie, wie in <xref linkend="network-inetd-reread"/>
beschrieben, die <application>inetd</application>-Konfiguration
neu einlesen. Lesen Sie bitte Abschnitt <xref
linkend="network-inetd-settings"/> des Handbuchs für weitere
Informationen zur Aktivierung von
<application>inetd</application> auf Ihren System.</para>
<para>Alternativ können Sie auch nur den
<application>ftpd</application>-Server starten. In diesem Fall
ist es ausreichend, die entsprechende Variable in der Datei
<filename>/etc/rc.conf</filename> zu setzen:</para>
<programlisting>ftpd_enable="YES"</programlisting>
<para>Nachdem Sie diese Variable gesetzt haben, wird künftig
beim Systemstart nur der FTP-Server gestartet. Alternativ
können Sie den Server auch manuell starten, indem Sie als
Benutzer <username>root</username> den folgenden Befehl
ausführen:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/ftpd start</userinput></screen>
<para>Danach können Sie sich auf Ihrem FTP-Server anmelden:</para>
<screen>&prompt.user; <userinput>ftp localhost</userinput></screen>
</sect2>
<sect2>
<title>Wartung</title>
<indexterm><primary>syslog</primary></indexterm>
<indexterm>
<primary>Logdateien</primary>
<secondary>FTP</secondary>
</indexterm>
<para>Der <application>ftpd</application>-Daemon verwendet
&man.syslog.3;, um Protokolldateien zu erstellen. In der
Voreinstellung werden alle FTP betreffenden Nachrichten
in die Datei <filename>/var/log/xferlog</filename>
geschrieben. Dies lässt sich aber durch das Einfügen
der folgenden Zeile in <filename>/etc/syslog.conf</filename>
ändern:</para>
<programlisting>ftp.info /var/log/xferlog</programlisting>
<indexterm>
<primary>FTP</primary>
<secondary>anonymous</secondary>
</indexterm>
<para>Beachten Sie, dass mit dem Betrieb eines anonymen
FTP-Servers verschiedene Sicherheitsrisiken verbunden sind.
Problematisch ist hier vor allem die Erlaubnis zum anonymen
Upload von Dateien. Dadurch könnte Ihr Server zur
Verbreitung von illegaler oder nicht lizensierter Software
oder noch Schlimmeren missbraucht werden. Wollen Sie
anonyme Uploads dennoch erlauben, sollten Sie die
Zugriffsrechte so setzen, dass solche Dateien erst nach Ihrer
Zustimmung von anderen Benutzern heruntergeladen werden
können.</para>
</sect2>
</sect1>
<sect1 id="network-samba">
<sect1info>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
</sect1info>
<title>Mit Samba einen Datei- und Druckserver für
µsoft.windows;-Clients einrichten</title>
<indexterm><primary>Samba-Server</primary></indexterm>
<indexterm><primary>Microsoft Windows</primary></indexterm>
<indexterm>
<primary>Dateiserver</primary>
<secondary>Windows-Clients</secondary>
</indexterm>
<indexterm>
<primary>Druckserver</primary>
<secondary>Windows-Clients</secondary>
</indexterm>
<sect2>
<title>Überblick</title>
<para><application>Samba</application> ist ein beliebtes
Open Source-Softwarepaket, das es Ihnen ermöglicht,
einen Datei- und Druckserver für
µsoft.windows;-Clients einzurichten. Clients können
sich dadurch mit einem FreeBSD-System verbinden und dessen
Speicherplatz oder dessen Drucker verwenden. Dies genauso, als
wenn es sich um lokale Drucker oder Festplatten handeln
würde.</para>
<para><application>Samba</application> sollte als Softwarepaket
auf Ihren Installationsmedien vorhanden sein. Wenn Sie
<application>Samba</application> noch nicht installiert haben,
können Sie dies jederzeit über den Port oder das
Paket <filename role="package">net/samba34</filename>
nachholen.</para>
<!-- mention LDAP, Active Directory, WinBIND, ACL, Quotas, PAM, .. -->
</sect2>
<sect2>
<title>Konfiguration</title>
<para>Die Standardkonfigurationsdatei von
<application>Samba</application> heißt
<filename>/usr/local/share/examples/samba34/smb.conf.default</filename>.
Diese Datei muss nach <filename>/usr/local/etc/smb.conf</filename>
kopiert und angepasst werden, bevor
<application>Samba</application> verwendet werden kann.</para>
<para>Die Datei <filename>smb.conf</filename> enthält
Laufzeitinformationen für
<application>Samba</application>, beispielsweise
Druckerdefinitionen oder
<foreignphrase>filesystem shares</foreignphrase>, also Bereiche
des Dateisystems, die Sie mit &windows;-Clients teilen wollen.
Die Konfiguration der Datei <filename>smb.conf</filename>
erfolgt webbasiert über das im
<application>Samba</application>-Paket enthaltene Programm
<application>swat</application>.</para>
<sect3>
<title>Das Samba Web Administration Tool (SWAT) verwenden</title>
<para>Das
<foreignphrase>Samba Web Administration Tool</foreignphrase>
(SWAT) wird als Daemon von <application>inetd</application>
aktiviert. Daher müssen Sie den Kommentar vor der
folgenden Zeile in <filename>/etc/inetd.conf</filename>
entfernen, bevor Sie <application>swat</application> zur
Konfiguration von <application>Samba</application> verwenden
können:</para>
<programlisting>swat stream tcp nowait/400 root /usr/local/sbin/swat swat</programlisting>
<para>Wie bereits in <xref linkend="network-inetd-reread"/>
beschrieben, müssen Sie die
<application>inetd</application>-Konfiguration neu einlesen,
nachdem Sie diese Änderung durchgeführt haben.</para>
<para>Nachdem <application>swat</application> in der Datei
<filename>inetd.conf</filename> aktiviert wurde, rufen Sie
in Ihrem Internetbrowser die Adresse
<ulink url="http://localhost:901"></ulink> auf und melden sich
mit dem <username>root</username>-Benutzerkonto an.</para>
<!-- XXX screenshots go here, loader is creating them -->
<para>Nachdem Sie sich erfolgreich angemeldet haben, wird die
Hauptkonfigurationseite von <application>Samba</application>
geladen. Sie können nun die Dokumentation lesen, oder
durch einen Klick auf die
<guimenu>Globals</guimenu>-Karteikarte mit der Konfiguration
beginnen. Die Einstellungen, die Sie hier vornehmen
können, entsprechen denen des Abschnitts
<literal>[global]</literal> von
<filename>/usr/local/etc/smb.conf</filename>.</para>
</sect3>
<sect3>
<title>Globale Einstellungen</title>
<para>Unabhängig davon, ob Sie
<application>swat</application> verwenden, oder
<filename>/usr/local/etc/smb.conf</filename> direkt
editieren, sollten Sie zuerst folgende Einstellungen
anpassen:</para>
<variablelist>
<varlistentry>
<term><literal>workgroup</literal></term>
<listitem>
<para>Der NT-Domänenname oder der Arbeitsgruppenname der
Rechner, die auf den Server Zugriff haben sollen.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>netbios name</literal></term>
<listitem>
<indexterm><primary>NetBIOS</primary></indexterm>
<para>Legt den NetBIOS-Namen fest, unter dem der
<application>Samba</application>-Server bekannt ist.
In der Regel handelt es sich dabei um den ersten
Teil des DNS-Namens des Servers.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>server string</literal></term>
<listitem>
<para>Legt die Beschreibung fest, die angezeigt werden
soll, wenn mit <command>net view</command> oder
über andere Netzwerkprogramme Informationen
über den Server angefordert werden.</para>
</listitem>
</varlistentry>
</variablelist>
</sect3>
<sect3>
<title>Samba absichern</title>
<para>Zwei der wichtigsten Einstellungen in
<filename>/usr/local/etc/smb.conf</filename> betreffen
das zu verwendende Sicherheitsmodell sowie das
Backend-Passwortformat für die Benutzer der
Samba-Clients. Folgende Optionen sind dafür
verantwortlich:</para>
<variablelist>
<varlistentry>
<term><literal>security</literal></term>
<listitem>
<para>Die häufigsten Optionen sind
<literal>security = share</literal> und
<literal>security = user</literal>. Wenn Ihre Clients
Benutzernamen verwenden, die den Benutzernamen auf Ihrem
&os;-Rechner entsprechen, dann sollten Sie die
Einstellung <foreignphrase>user level</foreignphrase>
verwenden. Dies ist auch die Standardeinstellung.
Allerdings ist es dazu erforderlich, dass sich die
Clients auf Ihrem Rechner anmelden, bevor sie auf
gemeinsame Ressourcen zugreifen können.</para>
<para>In der Einstellung
<foreignphrase>share level</foreignphrase> müssen
sich Clients nicht unter Verwendung eines gültigen
Logins auf Ihrem Rechner anmelden, bevor sie auf
gemeinsame Ressourcen zugreifen können. In
früheren <application>Samba</application>-Versionen
war dies die Standardeinstellung.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>passdb backend</literal></term>
<listitem>
<indexterm><primary>NIS+</primary></indexterm>
<indexterm><primary>LDAP</primary></indexterm>
<indexterm><primary>SQL database</primary></indexterm>
<para><application>Samba</application> erlaubt
verschiedene Backend-Authentifizierungsmodelle. Sie
können Clients durch LDAP, NIS+, eine SQL-Datenbank
oder eine Passwortdatei authentifizieren. In der
Voreinstellung wird <literal>smbpasswd</literal>
verwendet. Diese Methode wird im folgenden Abschnitt
näher beschrieben.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Wenn Sie <literal>smbpasswd</literal> verwenden, müssen
Sie die Datei <filename>/usr/local/etc/samba/smbpasswd</filename>
erzeugen, damit <application>Samba</application> in der Lage
ist, Clients zu authentifizieren. Wenn Sie auf Ihrem
&unix;-Rechner vorhandenen Benutzern den Zugriff von einem
&windows;-Client aus ermöglichen wollen, verwenden Sie den
folgenden Befehl:</para>
<screen>&prompt.root; <userinput>smbpasswd -a username</userinput></screen>
<note>
<para>Als Backend wird inzwischen <literal>tdbsam</literal>
empfohlen. Mit dem folgenden Befehl legen Sie neue
Benutzerkonten an:</para>
<screen>&prompt.root; <userinput><command>pdbedit <option>-a</option> <option>-u</option> <replaceable>username</replaceable></command></userinput></screen>
</note>
<para>Ausführliche Informationen zur Konfiguration
von <application>Samba</application> finden Sie im <ulink
url="http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/">
Official Samba HOWTO</ulink>. Sie sollten aber bereits
nach dem Lesen dieses Abschnitts in der Lage sein,
<application>Samba</application> zu starten.</para>
</sect3>
</sect2>
<sect2>
<title><application>Samba</application> starten</title>
<para>Der Port <filename role="package">net/samba34</filename>
legt ein neues Startskript an, mit dem
<application>Samba</application> gesteuert (also etwa
gestartet oder beendet) werden kann. Um dieses Skript
zu aktivieren, fügen Sie folgende Zeile in
<filename>/etc/rc.conf</filename> ein:</para>
<programlisting>samba_enable="YES"</programlisting>
<para>Alternativ können Sie auch die folgenden
beiden Einträge verwenden:</para>
<programlisting>nmbd_enable="YES"</programlisting>
<programlisting>smbd_enable="YES"</programlisting>
<note>
<para>Durch diese Einträge wird
<application>Samba</application> beim Systemstart
automatisch aktiviert.</para>
</note>
<para>Danach können Sie <application>Samba</application>
jederzeit durch folgenden Befehl starten:</para>
<screen>&prompt.root; <userinput>/usr/local/etc/rc.d/samba start</userinput>
Starting SAMBA: removing stale tdbs :
Starting nmbd.
Starting smbd.</screen>
<para>Weitere Informationen zu den rc-Startskripten finden
Sie im <xref linkend="configtuning-rcd"/> des Handbuchs.</para>
<para><application>Samba</application> verwendet drei Daemonen.
Beachten Sie, dass sowohl <application>nmbd</application> als
auch <application>smbd</application> durch das Skript
<filename>samba</filename> gestartet werden. Wenn Sie die
<foreignphrase>winbind name resolution services</foreignphrase>
in <filename>smb.conf</filename> aktiviert haben, wird
zusätzlich der <application>winbindd</application>-Daemon
gestartet.</para>
<para>Sie können <application>Samba</application> jederzeit
durch den folgenden Befehl beenden:</para>
<screen>&prompt.root; <userinput>/usr/local/etc/rc.d/samba stop</userinput></screen>
<para><application>Samba</application> ist ein komplexes
Softwarepaket mit umfassenden Funktionen, die eine weitreichende
Integration von µsoft.windows;-Netzwerken ermöglichen.
Für eine Beschreibung dieser Zusatzfunktionen sollten Sie
sich auf <ulink url="http://www.samba.org"></ulink> umsehen.</para>
</sect2>
</sect1>
<sect1 id="network-ntp">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Hukins</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
</sect1info>
<title>Die Uhrzeit mit NTP synchronisieren</title>
<indexterm><primary>NTP</primary></indexterm>
<sect2>
<title>Überblick</title>
<para>Da die interne Uhrzeit eines Computers nie ganz exakt ist,
wurde mit NTP
(<foreignphrase>Network Time Protocol</foreignphrase>) eine
Möglichkeit geschaffen, die exakte Uhrzeit zu ermitteln
und festzulegen.</para>
<para>Viele Internetdienste sind von einer exakten Uhrzeit
abhängig. Ein Webserver könnte beispielsweise die
Anforderung erhalten, eine Datei zu versenden, wenn sich diese
in einer bestimmten Zeitspanne geändert hat. In einem
lokalen Netzwerk ist es unbedingt notwendig, dass Rechner, die
Dateien von einem gemeinsamen Dateiserver beziehen, ihre
Uhrzeit synchronisieren, damit die Zeitstempel der Dateien
konstistent bleiben. Dienste wie &man.cron.8; führen
Befehle zu einem bestimmten Zeitpunkt aus. Ist die Uhrzeit
nicht korrekt, kann dies zu Problemen führen.</para>
<indexterm>
<primary>NTP</primary>
<secondary>ntpd</secondary>
</indexterm>
<para>&os; verwendet den &man.ntpd.8;-
<acronym role="Network Time Protocol">NTP</acronym>-Server,
um die genaue Uhrzeit von anderen
<acronym role="Network Time Protocol">NTP</acronym>-Servern
abzufragen, die eigene Systemzeit zu setzen, oder um diese
anderen Rechnern anzubieten.</para>
</sect2>
<sect2>
<title>Einen passenden NTP-Server auswählen</title>
<indexterm>
<primary>NTP</primary>
<secondary>Serverwahl</secondary>
</indexterm>
<para>Um die Uhrzeit zu synchronisieren, müssen Sie sich mit
einem
<acronym role="Network Time Protocol">NTP</acronym>-Server
verbinden. Ihr Netzwerkadministrator oder Ihr Internetprovider
haben vielleicht schon einen NTP-Server eingerichtet. Lesen Sie
deren Dokumentation, um dies zu überprüfen. Es gibt
im Internet eine
<ulink url="http://support.ntp.org/bin/view/Servers/WebHome">
Liste mit frei zugänglichen NTP-Servern</ulink>, aus der
Sie sich einen in Ihrer Nähe gelegenen Server
auswählen können. Beachten Sie aber auf jeden Fall
die Nutzungsbedingungen des entsprechenden Servers, und fragen
Sie um Erlaubnis, wenn dies nötig ist.</para>
<para>Die Auswahl von mehreren NTP-Servern kann sinnvoll sein,
wenn ein Server ausfällt oder falsche Zeiten liefert.
&man.ntpd.8; verwendet die Antworten anderer Server, um
zuverlässige Server zu bestimmen, die dann bevorzugt
abgefragt werden.</para>
</sect2>
<sect2>
<title>NTP unter &os; einrichten</title>
<indexterm>
<primary>NTP</primary>
<secondary>Konfiguration</secondary>
</indexterm>
<sect3>
<title>NTP aktivieren</title>
<indexterm><primary>ntpdate</primary></indexterm>
<para>Wenn Sie Ihre Uhrzeit nur beim Systemstart
synchronisieren wollen, können Sie &man.ntpdate.8;
verwenden. Für Desktoprechner, die regelmäßig
neu gestartet werden und keine ständige Synchronisation
benötigen, ist dies akzeptabel. In allen anderen
Fällen sollten Sie jedoch &man.ntpd.8; verwenden.</para>
<para>Die Ausführung von &man.ntpdate.8; während des
Systemstarts ist aber auch für Rechner, die &man.ntpd.8;
verwenden, sinnvoll. &man.ntpd.8; passt die Systemzeit nur
bei größeren Abweichungen an, während
&man.ntpdate.8; die Zeit immer synchronisiert, egal wie
groß die Differenz zwischen Systemzeit und korrekter
Zeit ist.</para>
<para>Um &man.ntpdate.8; beim Systemstart zu aktivieren,
fügen Sie den Eintrag
<literal>ntpdate_enable="YES"</literal> in
<filename>/etc/rc.conf</filename> ein. Außerdem müssen
Sie alle Server, mit denen Sie sich synchronisieren wollen,
sowie alle an &man.ntpdate.8; zu übergebenden Optionen
in den <varname>ntpdate_flags</varname> angeben.</para>
</sect3>
<sect3>
<title>NTP einrichten</title>
<indexterm>
<primary>NTP</primary>
<secondary>ntp.conf</secondary>
</indexterm>
<para>Die Konfiguration von NTP erfolgt über die Datei
<filename>/etc/ntp.conf</filename>, und wird in der
Hilfeseite &man.ntp.conf.5; beschrieben. Dazu ein
einfaches Beispiel:</para>
<programlisting>server ntplocal.example.com prefer
server timeserver.example.org
server ntp2a.example.net
driftfile /var/db/ntp.drift</programlisting>
<para>Die Option <literal>server</literal> legt die zu
verwendenden Server fest, wobei jeder Server in einer eigenen
Zeile steht. Wenn ein Server mit der Option
<literal>prefer</literal> versehen ist, wie dies hier bei
<hostid role="fqdn">ntplocal.example.com</hostid> der Fall
ist, wird dieser Server bevorzugt verwendet. Eine Antwort von
einem bevorzugten Server wird nur dann verworfen, wenn sie
signifikant von denen anderer Server abweicht, ansonsten wird
sie ohne Abfrage weiterer Server verwendet. Die Option
<literal>prefer</literal> wird gewöhnlich nur für
sehr zuverlässige und genaue Server verwendet, die
über eine spezielle Hardware zur Zeitüberwachung
verfügen.</para>
<para>Die Option <literal>driftfile</literal> legt fest, in
welcher Datei die Abweichungen der Systemuhr protokolliert
werden. &man.ntpd.8; verwendet diese Datei, um die Systemzeit
automatisch anzupassen, selbst wenn kurzzeitig kein NTP-Server
zur Synchronisation verfügbar ist.</para>
<para>Weiterhin legt die Option <literal>driftfile</literal> fest,
wo Informationen über frühere Antworten des von
Ihnen verwendeten NTP-Servers gespeichert werden sollen.
Diese Datei enthält NTP-interne Informationen, sie sollte
daher von anderen Prozessen nicht verändert werden.</para>
</sect3>
<sect3>
<title>Den Zugang zu Ihrem NTP-Server beschränken</title>
<para>In der Voreinstellung ist Ihr NTP-Server für alle
Rechner im Internet erreichbar. Über die Option
<literal>restrict</literal> in der Datei
<filename>/etc/ntp.conf</filename> können Sie den
Zugang zu Ihrem Server beschränken.</para>
<para>Wenn Sie alle Rechner vom Zugriff auf Ihren NTP-Server
ausschließen wollen, fügen Sie folgende Zeile in
<filename>/etc/ntp.conf</filename> ein:</para>
<programlisting>restrict default ignore</programlisting>
<note>
<para>Durch diesen Eintrag verhindern Sie den Zugriff Ihres
Servers auf alle auf Ihrem System konfigurierten Server.
Müssen Sie Ihren NTP-Server mit einem externen
NTP-Server synchronisieren, müssen Sie dies daher
dezidiert zulassen. Lesen Sie in diesem Fall die
Manualpage &man.ntp.conf.5;.</para>
</note>
<para>Wenn Sie nur Rechnern Ihres eigenen Netzwerks die
Synchronisation mit Ihrem NTP-Server erlauben, gleichzeitig
aber verhindern wollen, dass diese den NTP-Server
konfigurieren oder als Server für andere Rechner dienen
können, fügen Sie folgende Zeile ein:</para>
<programlisting>restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap</programlisting>
<para>Bei <hostid role="ipaddr">192.168.1.0</hostid> handelt es
sich um einen Rechner Ihres Netzwerks.
<hostid role="netmask">255.255.255.0</hostid> ist die
Netzmaske Ihres Netzwerks.</para>
<para><filename>/etc/ntp.conf</filename> kann verschiedene
<literal>restrict</literal>-Optionen enthalten.
Weiteres erfahren Sie im Abschnitt
<literal>Access Control Support</literal> der
Hilfeseite &man.ntp.conf.5;.</para>
</sect3>
</sect2>
<sect2>
<title>Den NTP-Server starten</title>
<para>Damit der NTP-Server beim Systemstart automatisch gestartet
wird, fügen Sie den Eintrag
<literal>ntpd_enable="YES"</literal> in
<filename>/etc/rc.conf</filename> ein. Wenn Sie weitere
Argumente an &man.ntpd.8; übergeben wollen, passen Sie
die Option <varname>ntpd_flags</varname> in der Datei
<filename>/etc/rc.conf</filename> entsprechend an.</para>
<para>Um den NTP-Server ohne einen Systemneustart zu starten,
rufen Sie <command>ntpd</command> mit den unter
<varname>ntpd_flags</varname> in
<filename>/etc/rc.conf</filename> festgelegten Parametern auf.
Hierzu ein Beispiel:</para>
<screen>&prompt.root; <userinput>ntpd -p /var/run/ntpd.pid</userinput></screen>
</sect2>
<sect2>
<title>ntpd mit einer Einwahlverbindung verwenden</title>
<para>&man.ntpd.8; benötigt keine ständige
Internetverbindung. Wenn Sie sich ins Internet einwählen,
ist es sinnvoll, zu verhindern, dass NTP-Verkehr eine Verbindung
aufbauen oder aufrechterhalten kann. Wenn Sie user-PPP
verwenden, können Sie dies in den
<literal>filter</literal>-Direktiven von
<filename>/etc/ppp/ppp.conf</filename> festlegen. Sehen Sie
sich dazu das folgende Beispiel ein:</para>
<programlisting>set filter dial 0 deny udp src eq 123
# Prevent NTP traffic from initiating dial out
set filter dial 1 permit 0 0
set filter alive 0 deny udp src eq 123
# Prevent incoming NTP traffic from keeping the connection open
set filter alive 1 deny udp dst eq 123
# Prevent outgoing NTP traffic from keeping the connection open
set filter alive 2 permit 0/0 0/0</programlisting>
<para>Weitere Informationen finden Sie im Abschnitt
<literal>PACKET FILTERING</literal> von &man.ppp.8; sowie in den
Beispielen unter <filename>/usr/share/examples/ppp/</filename>.</para>
<note><para>Einige Internetprovider blockieren Ports mit niedrigen
Nummern. In solchen Fällen funktioniert NTP leider
nicht, da Antworten eines NTP-Servers Ihren Rechner nicht
erreichen werden.</para></note>
</sect2>
<sect2>
<title>Weitere Informationen</title>
<para>Weiterführende Dokumentation (im HTML-Format)
zum NTP-Server finden Sie unter
<filename>/usr/share/doc/ntp/</filename>.</para>
</sect2>
</sect1>
<sect1 id="network-syslogd">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Beigetragen von </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Benedict</firstname>
<surname>Reuschling</surname>
<contrib>Übersetzt von </contrib>
</author>
</authorgroup>
</sect1info>
<title>Protokollierung von anderen Hosts mittels
<command>syslogd</command></title>
<para>Die Interaktion mit Systemprotokollen ist ein wichtiger Aspekt,
sowohl was Sicherheit als auch Systemadministration anbelangt.
Überwachen der Protokolldateien von mehreren Hosts kann sehr
unhandlich werden, wenn diese Hosts über mittlere oder grosse
Netze verteilt sind oder wenn sie Teile von unterschiedlichen Netzwerken
sind. In diesen Fällen macht die Konfiguration der Protokollierung
von anderen Hosts diesen Prozess wesentlich komfortabler.</para>
<para>Die zentralisierte Protokollierung auf einen bestimmten
Protokollierungshost kann manche der administrativen Belastungen der
Protokolldateiadministration reduzieren. Protokolldateiaggregation,
-zusammenführung und -rotation kann an einer zentralen Stelle mit
den &os;-eigenen Werkzeugen wie &man.syslogd.8; und &man.newsyslog.8;
konfiguriert werden. In der folgenden Beispielkonfiguration sammelt
Host <hostid>A</hostid>, genannt <hostid
role="fqdn">logserv.example.com</hostid>, Protokollinformationen für
das lokale Netzwerk. Host <hostid>B</hostid>, genannt
<hostid role="fqdn">logclient.example.com</hostid> wird seine
Protokollinformationen an den Server weiterleiten. In realen
Konfigurationen benötigen beide Hosts passende Vorwärts- und
Umkehr-Einträge im <acronym>DNS</acronym> oder
in <filename>/etc/hosts</filename>. Andernfalls werden die Daten vom
Server abgelehnt.</para>
<sect2>
<title>Konfiguration des Protokollierungs-Servers</title>
<para>Protokollierungs-Server sind Maschinen, die konfiguriert sind,
Protokollinformationen von anderen Hosts zu akzeptieren. In den
meisten Fällen wird dies zur Vereinfachung der Konfiguration
eingesetzt, in anderen Fällen ist es einfach nur ein Schritt in
eine bessere Verwaltung. Was auch immer die Gründe sind, ein paar
Anforderungen müssen vorher erfüllt sein.</para>
<para>Ein richtig konfigurierter Protokollierungs-Server muss minimal die
folgenden Anforderungen erfüllen:</para>
<itemizedlist>
<listitem>
<para>Das Regelwerk der Firewall muss <acronym>UDP</acronym> auf
Port 514 sowohl auf Client- als auch auf Serverseite
erlauben;</para>
</listitem>
<listitem>
<para>syslogd wurde so konfiguriert, dass es Nachrichten von anderen
Clientrechnern akzeptiert;</para>
</listitem>
<listitem>
<para>Der syslogd-Server und alle Clientrechner müssen
gültige Einträge für sowohl Vorwärts- als auch
Umkehr-<acronym>DNS</acronym> besitzen, oder in
<filename>/etc/hosts</filename> korrekt eingetragen sein.</para>
</listitem>
</itemizedlist>
<para>Um den Protokollierungs-Server zu konfigurieren, muss der Client in
<filename>/etc/syslog.conf</filename> eingetragen sein und der
Verbindungsweg der Protokollierung muss spezifiziert sein:</para>
<programlisting>+logclient.example.com
*.* /var/log/logclient.log</programlisting>
<note>
<para>Weitere Informationen zu den verschiedenen unterstützten
und verfügbaren <emphasis>Verbindungswegen</emphasis> finden
sich in der Manualpage &man.syslog.conf.5;.</para>
</note>
<para>Einmal hinzugefügt, werden alle Nachrichten über
den <literal>Verbindungsweg</literal> in die zuvor angegebene Datei,
<filename>/var/log/logclient.log</filename> protokolliert.</para>
<para>Der Server benötigt ausserdem die folgenden Zeilen in der
<filename>/etc/rc.conf</filename>:</para>
<programlisting>syslogd_enable="YES"
syslogd_flags="-a logclient.example.com -v -v"</programlisting>
<para>Die erste Option aktiviert den <command>syslogd</command>-Dienst
während des Systemstarts und die zweite Option erlaubt es, Daten
von dem spezifizierten Client auf diesem Server zu akzeptieren. Die
Verwendung von <option>-v -v</option> im letzten Teil erhöht die
Anzahl von Protokollnachrichten. Dies ist sehr hilfreich für die
Feineinstellung der Verbindungspfade, da Administratoren auf diese
Weise erkennen, welche Arten von Nachrichten unter welchen
Einstellungen protokolliert werden.</para>
<para>Mehrere <option>-a</option>-Optionen können angegeben werden,
um die Protokollierung von mehreren Clients zu erlauben.
<acronym>IP</acronym>-Adressen und ganze Netzblöcke können
ebenfalls spezifiziert werden. Lesen Sie dazu die
&man.syslog.3;-Manualpage, um eine vollständige Liste von
möglichen Optionen zu erhalten.</para>
<para>Zum Schluss muss noch die Protokolldatei erstellt werden. Auf
welche Weise dies geschieht ist nicht wichtig, aber in den meisten
Fällen funktioniert &man.touch.1; grossartig, wie hier
dargestellt:</para>
<screen>&prompt.root; <userinput>touch <filename>/var/log/logclient.log</filename></userinput></screen>
<para>Zu diesem Zeitpunkt sollte der <command>syslogd</command>-Dienst
neu gestartet und überprüft werden:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput>
&prompt.root; <userinput>pgrep syslog</userinput></screen>
<para>Wenn eine <acronym>PID</acronym> zurückgegeben wird, wurde
der Server erfolgreich neu gestartet und die Clientkonfiguration kann
beginnen. Wenn der Server nicht neu gestartet wurde, suchen Sie im
<filename>/var/log/messages</filename>-Protokoll nach eventuellen
Fehlermeldungen.</para>
</sect2>
<sect2>
<title>Konfiguration des Protokollierungs-Clients</title>
<para>Ein Protokollierungs-Client ist eine Maschine, die
Protokollinformationen an einen Protokollierungs-Server sendet,
zusätzlich zu ihren lokalen Kopien.</para>
<para>Ähnlich wie Protokollierungs-Server müssen Clients auch
ein paar minimale Anforderungen erfüllen:</para>
<itemizedlist>
<listitem>
<para>&man.syslogd.8; muss so konfiguriert sein, dass es Nachrichten
eines bestimmten Typs an einen Protokollierungs-Server schickt,
welcher diese akzeptieren muss;</para>
</listitem>
<listitem>
<para>Die Firewall muss <acronym>UDP</acronym>-Pakete durch Port 514
erlauben;</para>
</listitem>
<listitem>
<para>Sowohl Vorwärts- als auch Umkehr-<acronym>DNS</acronym>
muss konfiguriert sein oder es müssen passende Einträge in
<filename>/etc/hosts</filename> vorhanden sein.</para>
</listitem>
</itemizedlist>
<para>Die Clientkonfiguration ist ein bisschen entspannter, verglichen mit
der des Servers. Der Clientrechner muss ebenfalls die folgenden
Einträge in der <filename>/etc/rc.conf</filename> besitzen:</para>
<programlisting>syslogd_enable="YES"
syslogd_flags="-s -v -v"</programlisting>
<para>Wie zuvor aktivieren diese Einträge den
<command>syslogd</command>-Dienst während des Systemstarts und
erhöhen die Anzahl der Protokollnachrichten. Die Option
<option>-s</option> verhindert, dass dieser Client Protokolle von anderen
Hosts akzeptiert.</para>
<para>Verbindungspfade beschreiben den Systemteil, für den eine
Nachricht generiert wird. Beispielsweise sind <acronym>ftp</acronym> und
<acronym>ipfw</acronym> beides Verbindungspfade. Wenn
Protokollnachrichten für diese beiden Dienste generiert werden,
sind diese beiden Werkzeuge normalerweise in jeder Protokollnachricht
enthalten. Verbindungspfade sind mit einer Priorität oder Stufe
verbunden, die dazu verwendet wird, zu markieren, wie wichtig eine
Nachricht im Protokoll ist. Die Häftigste ist
<literal>warning</literal> und <literal>info</literal>. Bitte lesen Sie
die &man.syslog.3; Manualpage, um eine komplette Liste der
verfügbaren Verbindungspfade und Prioritäten zu
erhalten.</para>
<para>Der Protokollierungs-Server muss in der
<filename>/etc/syslog.conf</filename> des Clients eingetragen sein. In
diesem Beispiel wird das <literal>@</literal>-Symbol benutzt, um
Protokolldaten an einen anderen Server zu senden. Der Eintrag sieht wie
folgt aus:</para>
<programlisting>*.* @logserv.example.com</programlisting>
<para>Einmal hinzugefügt, muss <command>syslogd</command> neu
gestartet werden, damit diese Änderungen wirksam werden:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput></screen>
<para>Um zu testen, ob Protokollnachrichten über das Netzwerk
gesendet werden, kann &man.logger.1; auf dem Client benutzt werden, um
eine Nachricht an <command>syslogd</command> zu schicken:</para>
<screen>&prompt.root; <userinput>logger "<replaceable>Test message from logclient</replaceable>"</userinput></screen>
<para>Diese Nachricht sollte jetzt sowohl in
<filename>/var/log/messages</filename> auf dem Client, als auch in
<filename>/var/log/logclient.log</filename> auf dem Server vorhanden
sein.</para>
</sect2>
<sect2>
<title>Fehlerbehebung beim Protokollierungs-Server</title>
<para>In bestimmten Fällen ist die Fehlerbehebung notwendig, wenn
Nachrichten nicht auf dem Protokollierungs-Server empfangen werden. Es
gibt mehrere Gründe dafür, jedoch treten am häufigsten
Probleme bei der Netzwerkverbindung und beim <acronym>DNS</acronym> auf.
Um diese Fälle zu überprüfen, stellen Sie sicher, dass
beide Hosts in der Lage sind, sich gegenseitig über den Hostnamen zu
erreichen, der in <filename>/etc/rc.conf</filename> angegeben ist. Wenn
das funktioniert, ist möglicherweise eine Änderung der
<literal>syslogd_flags</literal>-Option in
<filename>/etc/rc.conf</filename> notwendig.</para>
<para>Im folgenden Beispiel ist <filename>/var/log/logclient.log</filename>
leer und die <filename>/var/log/messages</filename>-Dateien enthalten
keine Gründe für den Fehler. Um die Fehlerausgabe zu
erhöhen, ändern Sie die <literal>syslogd_flags</literal>-Option
so, dass diese wie in dem folgenden Beispiel aussieht und initiieren Sie
dann einen Neustart:</para>
<programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
<screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput></screen>
<para>Fehlerausgabedaten ähnlich der Folgenden werden sofort nach dem
Neustart auf dem Bildschirm erscheinen:</para>
<screen>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.</screen>
<para>Es scheint klar zu sein, dass die Nachrichten aufgrund eines
fehlerhaften Namens abgewiesen werden. Nach genauer Untersuchung der
Konfiguration, kommt ein Tippfehler in der folgenden Zeile der
<filename>/etc/rc.conf</filename> als Fehler in Betracht:</para>
<programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting>
<para>Die Zeile sollte <literal>logclient</literal> und nicht
<literal>logclien</literal> enthalten. Nachdem die entsprechenden
Veränderungen gemacht wurden, ist ein Neustart fällig, mit den
entsprechenden Ergebnissen:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput>
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</screen>
<para>Zu diesem Zeitpunkt werden die Nachrichten korrekt empfangen und in
die richtige Datei geschrieben.</para>
</sect2>
<sect2>
<title>Sicherheitsbedenken</title>
<para>Wie mit jedem Netzwerkdienst, müssen Sicherheitsanforderungen in
Betracht gezogen werden, bevor diese Konfiguration umgesetzt 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,
<filename role="package">security/stunnel</filename> zu verwenden,
welches die Daten über einen verschlüsselten Tunnel
versendet.</para>
<para>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. In diesen Fällen ist es absolut
notwendig, die richtigen Berechtigungen auf diesen Dateien zu setzen.
Das &man.newsyslog.8;-Werkzeug unterstützt das Setzen von
Berechtigungen auf gerade erstellte oder rotierte Protokolldateien.
Protokolldateien mit Zugriffsmodus <literal>600</literal> sollten
verhindern, dass lokale Benutzer darin herumschnüffeln.</para>
</sect2>
</sect1>
</chapter>