Date: Fri, 27 May 2016 17:06:42 +0000 (UTC) From: Bjoern Heidotting <bhd@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48860 - head/de_DE.ISO8859-1/books/handbook/network-servers Message-ID: <201605271706.u4RH6gP0063202@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: bhd Date: Fri May 27 17:06:42 2016 New Revision: 48860 URL: https://svnweb.freebsd.org/changeset/doc/48860 Log: Update to r43725: Finish syslogd section. Clarify examples. Modified: head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml Fri May 27 16:49:05 2016 (r48859) +++ head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml Fri May 27 17:06:42 2016 (r48860) @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/network-servers/chapter.xml,v 1.103 2011/12/24 15:51:18 bcr Exp $ - basiert auf: r43714 + basiert auf: r43725 --> <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="network-servers"> <!-- @@ -93,7 +93,7 @@ </listitem> <listitem> - <para>Wissen, wie man den Standard-Protokollierungsdienst, + <para>Wissen, wie man den Standard-Protokollienst, <command>syslogd</command>, konfiguriert, um Protokolle von anderen Hosts zu akzeptieren.</para> </listitem> @@ -5626,7 +5626,7 @@ set filter alive 2 permit 0/0 0/0</progr sowohl was Sicherheit als auch Systemadministration anbelangt. Die Überwachung der Protokolldateien von mehreren Hosts kann sehr unhandlich werden. Die zentralisierte Protokollierung auf - einen bestimmten Protokollierungshost kann manche der + einen bestimmten Protokollserver kann manche der administrativen Belastungen bei der Verwaltung von Protokolldateien reduzieren.</para> @@ -5643,9 +5643,9 @@ set filter alive 2 permit 0/0 0/0</progr seine Protokollinformationen an den Server weiterleiten.</para> <sect2> - <title>Konfiguration des Protokollierungs-Servers</title> + <title>Konfiguration des Protokollservers</title> - <para>Ein Protokollierungs-Server ist ein System, das + <para>Ein Protokollserver ist ein System, das konfiguriert ist, Protokollinformationen von anderen Hosts zu akzeptieren. Bevor Sie diesen Server konfigurieren, prüfen Sie folgendes:</para> @@ -5653,7 +5653,7 @@ set filter alive 2 permit 0/0 0/0</progr <itemizedlist> <listitem> <para>Falls eine Firewall zwischen dem - Protokollierungs-Server und den -Clients steht, muss das + Protokollserver und den -Clients steht, muss das Regelwerk der Firewall <acronym>UDP</acronym> auf Port 514 sowohl auf Client- als auch auf Serverseite freigegeben werden.</para> @@ -5734,75 +5734,41 @@ syslogd_flags="-a logclient.example.com </sect2> <sect2> - <title>Konfiguration des Protokollierungs-Clients</title> + <title>Konfiguration des Protokollclients</title> - <para>Ein Protokollierungs-Client ist eine Maschine, die - Protokollinformationen an einen Protokollierungs-Server sendet, - zusätzlich zu ihren lokalen Kopien.</para> + <para>Ein Protokollclient sendet Protokollinformationen + an einen Protokollserver. Zusätzlich behält er eine + lokale Kopie seiner eigenen Protokolle.</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> + <para>Sobald der Server konfiguriert ist, bearbeiten Sie + <filename>/etc/rc.conf</filename> auf dem Client:</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 + <para>Der erste Eintrag aktiviert den + <command>syslogd</command>-Dienst während des Systemstarts. + Der zweite Eintrag erhöht 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>. Eine - vollständig Liste der verfügbaren Verbindungspfade und - Prioritäten finden Sie in &man.syslog.3;.</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> + <para>Als nächstes muss der Protokollserver in der + <filename>/etc/syslog.conf</filename> des Clients eingetragen + werden. In diesem Beispiel wird das + <literal>@</literal>-Symbol benutzt, um sämtliche + Protokolldaten an einen bestimmten Server zu senden:</para> <programlisting>*.* @logserv.example.com</programlisting> - <para>Einmal hinzugefügt, muss <command>syslogd</command> neu - gestartet werden, damit diese Änderungen wirksam werden:</para> + <para>Nachdem die Änderungs gespeichert wurden, muss + <command>syslogd</command> neu gestartet werden, damit die + Änderungen wirksam werden:</para> <screen>&prompt.root; <userinput>service 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> + eine Nachricht an <application>syslogd</application> zu schicken:</para> <screen>&prompt.root; <userinput><command>logger</command> "<replaceable>Test message from logclient</replaceable>"</userinput></screen> @@ -5813,32 +5779,41 @@ syslogd_flags="-s -v -v"</programlisting </sect2> <sect2> - <title>Fehlerbehebung beim Protokollierungs-Server</title> + <title>Fehlerbehebung beim Protokollserver</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> + <para>Wenn der Server keine Nachrichten empfängt, ist die + Ursache wahrscheinlich ein Netzwerkproblem, ein Problem bei + der Namensauflösung oder ein Tippfehler in einer + Konfigurationsdatei. Um die Ursache zu isolieren, müssen Sie + sicherstellen, dass sich Server und Client über den in + <filename>/etc/rc.conf</filename> konfigurierten Hostnamen per + <command>ping</command> erreichen können. Falls dies nicht + gelingt sollten Sie die Netzwerkverkablung überprüfen, + außerdem Firewallregeln sowie die Einträge für Hosts im + <acronym>DNS</acronym> und <filename>/etc/hosts</filename>. + Überprüfen Sie diese Dinge auf dem Server und dem Client, bis + der <command>ping</command> von beiden Hosts erfolgreich + ist.</para> + + <para>Wenn sich die Hosts gegenseitig per + <command>ping</command> erreichen können, der Server aber + immer noch keine Nachrichten empfängt, können Sie + vorübergehend die Ausführlichkeit der Protokollierung erhöhen, + um die Ursache für das Problem weiter einzugrenzen. In dem + folgenden Beispiel ist auf dem Server die Datei + <filename>/var/log/logclient.log</filename> leer und in der + Datei <filename>/var/log/messages</filename> auf dem Client + ist keine Ursache für das Problem erkennbar. Um nun die + Ausführlichkeit der Protokollierung zu erhöhen, passen Sie + auf dem Server den Eintrag <literal>syslogd_flags</literal> + an. Anschließend starten Sie den Dienst neu:</para> <programlisting>syslogd_flags="-d -a logclien.example.com -v -v"</programlisting> - <screen>&prompt.root; <userinput>service <command>syslogd</command> restart</userinput></screen> + <screen>&prompt.root; <userinput>service syslogd restart</userinput></screen> - <para>Fehlerausgabedaten ähnlich der Folgenden werden sofort nach dem - Neustart auf dem Bildschirm erscheinen:</para> + <para>Informationen wie diese werden sofort nach dem Neustart + auf der Konsole erscheinen:</para> <screen>logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted @@ -5849,19 +5824,14 @@ 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> + <para>In diesem Beispiel werden die Nachrichten aufgrund eines + fehlerhaften Namens abgewiesen. Der Hostname sollte + <literal>logclient</literal> und nicht + <literal>logclien</literal> sein. Beheben Sie den Tippfehler, + starten Sie den Dienst neu und überprüfen Sie die + Ergebnisse:</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>service <command>syslogd</command> restart</userinput> + <screen>&prompt.root; <userinput>service 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 @@ -5882,27 +5852,30 @@ Logging to FILE /var/log/messages</scree <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, - <package>security/stunnel</package> zu verwenden, - welches die Daten über einen verschlüsselten Tunnel - versendet.</para> + <para>Wie mit jedem Netzwerkdienst, müssen + Sicherheitsanforderungen in Betracht gezogen werden, bevor ein + Protokollserver eingesetzt wird. Manchmal enthalten + Protokolldateien sensitive Daten über aktivierte Dienste auf + dem lokalen Rechner, Benutzerkonten und Konfigurationsdaten. + Daten, die vom Client an den Server geschickt werden, sind + weder verschlüsselt noch mit einem Passwort geschützt. Wenn + ein Bedarf für Verschlüsselung besteht, ist es möglich + <package>security/stunnel</package> zu verwenden, welches die + Protokolldateien ü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. + Systemkonfiguration zu erlangen. Es ist 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> + verhindern, dass lokale Benutzer darin herumschnüffeln. + Zusätzliche Informationen finden Sie in + &man.newsyslog.conf.5;.</para> </sect2> </sect1>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201605271706.u4RH6gP0063202>