FreeBSD-Tipps: Syslog verwenden. Syslog - Netzwerk-Syslog Hauptprotokolldateien

Darüber hinaus werden Syntax-Highlighting, Tabu-Ergänzungen und verschiedene Nützlichkeiten in der Statusleiste unterstützt. Zu den Nachteilen gehören Instabilität des Verhaltens und Einfrieren. Hoffnung lnav wird sich aktiv weiterentwickeln, sehr nützliches Programm meiner Meinung nach.

Syslog-Protokoll und Software support bietet das Aufzeichnen von Informationen zu Ereignissen im Systemprotokoll (Protokolle, Systemkonsole) sowie deren Übertragung an den Protokollierungsserver über das Netzwerk, Sortierung und Verarbeitung je nach Quelle und Wichtigkeit der Meldungen. Dieser Artikel beschreibt das Syslog-Protokoll, seine Implementierung in Solaris und Linux (syslogd), Cisco IOS und Hilfstools: logrotate, logwatch.

Die Komponenten des Systems sind ein Nachrichtengenerator (Gerät oder Prozess), ein Austauschprotokoll, ein Nachrichtensammler (Sammler, Syslog-Server), Relays (Relay, empfängt Nachrichten von einem oder mehreren Generatoren und sendet an einen oder mehrere Collectors oder nachfolgende Relays) ). Der Generator (oder das Relais in Übertragung) weiß nicht, ob der Empfänger ein Relais oder ein Kollektor ist, er kann eine Nachricht an mehrere Empfänger senden, er kann die Nachricht selbst verarbeiten (z. B. durch Schreiben in eine Datei).

Das Syslog-Protokoll enthält keine Schutzmaßnahmen gegen Message-Spoofing. Schlimmer noch, die Verwendung von UDP ermöglicht es Angreifern, Nachrichten im Namen eines beliebigen Hosts zu senden. Das lokale Netzwerk muss durch einen Bildschirm (IOS ACL, ipchains) vor dem Empfang von Paketen mit gefälschten lokalen Adressen geschützt werden (was Sie jedoch nicht daran hindert, gefälschte Nachrichten von innen zu senden lokales Netzwerk) und vom Empfangen von Paketen außerhalb auf Port 514 / udp. Es gibt bekannte Fälle von Festplattenüberlauf mit falschen Meldungen.

Das Syslog-Protokoll und UDP bieten keine garantierte Zustellung (Nachrichten können während einer Netzwerküberlastung verloren gehen oder abgefangen werden, beschädigte Nachrichten werden ohne Vorwarnung gelöscht), die korrekte Zustellungsreihenfolge (die Nachricht über das Ende des Prozesses kann vor der Nachricht über seinen Start kommen ), vorrangige Zustellung.

Nachrichten werden nicht vertraulich behandelt, da sie im Klartext übertragen werden.

Wenn Sie beim Konfigurieren des Nachrichtengenerators die falsche Adresse des Kollektors oder Relais angeben, gibt es keine Fehlermeldungen - die Nachrichten werden gelöscht (oder in das Protokoll einer anderen Person geschrieben ;).

Ein Schutz gegen Durchschleifen der Nachrichtenübertragung durch falsch konfigurierte Relais ist nicht vorgesehen.

RFC 3195 schlägt ein neues Protokoll über TCP (syslog-conn, 601) vor, um die Zustellung in der richtigen Reihenfolge sicherzustellen. Die Umsetzung ist mir nicht bekannt. Eine monströse Mischung aus XML, Befehlen und Rückgabecodes im SMTP-Stil sowie MIME-Headern (BEEP), die in Standard-Syslog-Nachrichten eingeschlossen sind. Es werden zwei Modi verwendet - RAW (analog des aktuellen UDP-Protokolls) und COOKED (Nachrichten sind nach Feldern strukturiert). BEEP ermöglicht Authentifizierung, Integrität und Vertraulichkeit (SASL, TLS).

Der syslog-sign RFC schlägt vor, Authentifizierung, Sortierung, Nachrichtenintegrität und Erkennung fehlender Nachrichten bereitzustellen, indem spezielle Nachrichten generiert werden, die eine digitale Signatur eines Blocks früherer Nachrichten enthalten, das Standard-Syslog-Protokoll und -Format beibehalten und UDP verwenden. Wird von SHA1, OpenPGP DSA verwendet.

Port 514 / UDP wird zum Empfangen von Nachrichten verwendet. Es wird auch empfohlen, den Quellport 514 für die Nachrichtenübermittlung zu verwenden. Die Nachricht ist eine Textzeichenfolge und darf nicht länger als 1024 Byte sein, ansonsten darf sie abgeschnitten oder sogar verworfen werden. Sogar eine fehlerhafte Nachricht, die an Port 514 gesendet wird, sollte als Syslog-Nachricht betrachtet werden. Wenn das Relay die Nachricht jedoch weiterleitet, muss es Standardheader hinzufügen (gleichzeitig möglicherweise auf 1024 Bytes schneiden) - USER, NOTICE, seine lokale Zeit und den einfachen Namen der Nachrichtenquelle.

Die Nachricht beginnt mit einem PRI-Feld, das die Einrichtung und den Schweregrad der Nachricht codiert. Es folgen Zeit (TIMESTAMP), Leerzeichen, Hostname oder IP-Adresse in dezimaler Schreibweise (HOSTNAME), Leerzeichen, beliebiger Nachrichtentext (MSG) in US-ASCII (0x20 - 0x7e).

Der Hostname (einfach, nicht der FQDN!) wird dem Nachrichtengenerator als bekannt geschrieben. Verfügt das Gerät über mehrere Schnittstellen mit unterschiedlichen IP-Adressen, kann jede davon als Hostname oder Adresse verwendet werden.

Der Nachrichtentext (MSG) enthält normalerweise ein Tag (TAG), das das Programm oder den Prozess identifiziert, der die Nachricht ausgegeben hat, und den Nachrichtentext (CONTENT). Das Etikett kann lateinische Buchstaben und Zahlen enthalten. Der Anfang des Nachrichtentexts wird durch das erste Sonderzeichen identifiziert, normalerweise ein Doppelpunkt oder eine öffnende eckige Klammer. Cisco IOS verwendet beispielsweise die fortlaufende Nachrichtennummer gefolgt von einem Doppelpunkt als Label, und Unix verwendet den einfachen Programmnamen (der Nachrichtentext beginnt mit der Prozessnummer in eckigen Klammern und einem Doppelpunkt).

syslogd empfängt Nachrichten von Port 514 / UDP und von lokalen Quellen (Socket / dev / log) und leitet sie abhängig von der Quelle der Nachrichten und dem Schweregrad weiter. Ermöglicht die Ausgabe von Nachrichten an das Protokoll, die Ausgabe an die Konsole, an das Terminal und das Senden an einen anderen Server. Ein zusätzlicher Quelltyp MARK wird eingeführt (normale Marken, Info)

Jede Protokollzeile enthält einen einzelnen Nachrichteneintrag, der aus durch Leerzeichen getrennten Feldern besteht:

• Datum im Standardtextformat (TIMESTAMP-Feld aus der Syslog-Nachricht)
• Hostname (fqdn oder Kurzform, HOSTNAME-Feld aus der Syslog-Nachricht)
• Nachrichtentext (TAG- und CONTENT-Felder aus der Syslog-Nachricht)

Startparameter:

• -ein zusätzliche-hör-Buchse (nützlich für Daemons, die chroot ausführen; es können mehrere sein)
• -D(Debug-Modus)
• -F Konfigurationsdateiname (Default, /etc/syslog.conf)
• -h(Ändern Sie das übliche Verhalten, bei dem von entfernten Hosts empfangene Nachrichten nicht zum Schreiben auf den entfernten Host weitergeleitet werden, um Schleifen zu vermeiden)
• -l Host-Liste (eine Liste von Hosts, deren Namen nicht als FQDNs geschrieben werden sollen; durch Doppelpunkte getrennt)
• -m Protokoll (Intervall für regelmäßige temporäre Aufzeichnungen; standardmäßig - 20; wenn 0, dann überhaupt nicht tun)
• -n
• -P Hör-Steckdose (Default: / dev / log)
• -R(Erlauben Sie den Empfang von Nachrichten von entfernten Hosts; Firewall sollte leicht geöffnet sein; Syslog für 514 / udp sollte in / etc / services definiert sein)
• -S Domain-Liste (Strippen Sie die Namen der angegebenen Domänen von Hostnamen; durch Doppelpunkte getrennt; standardmäßig wird die Domäne, die der Domäne des Syslog-Servers entspricht, abgeschnitten)
• -v
• -x(Verbieten Sie die Bestimmung des Hostnamens anhand seiner Adresse, verhindert Deadlock, wenn auf demselben Host mit dem DNS-Server gearbeitet wird)

Verwendete Dateien:

• /etc/syslog.conf- Konfigurationsdatei (geändert beim Start durch Parameter -F)
• / dev / log- die Buchse zum Auslesen lokale Nachrichten(geändert beim Start durch Parameter -P)
• /var/run/syslogd.pid- Prozess ID

Reaktion auf Signale:

• SIGHUP - Neuinitialisierung (schließt alle Dateien, liest die Konfigurationsdatei erneut)
• SIGTERM - Herunterfahren
• SIGINT, SIGQUIT - Herunterfahren, wenn das Debuggen deaktiviert ist
• SIGUSR1 - Debugging aktivieren / deaktivieren (nur bei Verwendung des Schalters -d)

Läuft als root. Ändert die Dateiberechtigungen nicht. Wenn er gezwungen ist, eine Datei anzulegen, tut er dies mit 644 Rechten.Ist es notwendig, den Zugriff auf das Protokoll einzuschränken, muss die entsprechende Datei manuell erstellt werden (oder die Zugriffsrechte ändern). Schafft besondere Probleme logrotieren.

Es ist ein Satz von Nachrichtenweiterleitungsregeln. Jede Regel besteht aus einem Selektor und einer Aktion, die durch Tabulatoren (Solaris 5 auf älteren Systemen) oder Leerzeichen (Linux) getrennt sind. Nach dem Empfang einer Nachricht, die in das Protokoll geschrieben werden soll (von klogd, von einem lokalen oder entfernten Programm), prüft syslogd für jede Regel, ob die Nachricht dem vom Selektor angegebenen Muster entspricht. Gegebenenfalls wird die in der Regel angegebene Aktion ausgeführt. Für eine Nachricht m. eine beliebige Anzahl von Aktionen wurde ausgeführt (d. h. die Nachrichtenverarbeitung stoppt nicht beim ersten Erfolg).

Der Selektor besteht aus zwei Teilen, die durch einen Punkt getrennt sind: die Quelle der Nachricht und den Schweregrad. Groß- und Kleinbuchstaben sind gleich. Sie können auch Zahlen verwenden (siehe /usr/include/syslog.h). Zusätzlich zu den in syslog.3 definierten Quellen können Sie Markierung(reguläre Zeitstempel), Sicherheit(veraltetes Synonym für auth). Zusätzlich zu den in syslog.h definierten Schweregraden können Sie warnen(Synonym für Warnung), Error(Synonym für irren), Panik(Synonym für auftauchen). Nachrichten mit einer Ebene gleich oder höher als die im Selektor angegebene und eine Quelle, die der im Selektor angegebenen entspricht, werden als gültig betrachtet. Ein Stern vor einem Punkt entspricht einer beliebigen Quelle, nach einem Punkt - einer beliebigen Ebene. Wort keiner nach dem Punkt - kein Pegel für die angegebene Quelle. Sie können mehrere Quellen in einem Selektor angeben (durch Kommas getrennt). In einer Zeile können mehrere Selektoren angegeben werden. Die Semantik ist nicht klar: Wenn Sie positive Selektoren verwenden, dann ist die logische ODER wenn negativ ( keiner und ein Ausrufezeichen), dann das logische UND.

Im neuen syslogd (linux) kann dem Level ein Gleichheitszeichen vorangestellt werden - nur Nachrichten mit dem angegebenen Level (aber nicht mit dem höchsten) werden mit dem Selektor übereinstimmen; Ausrufezeichen - Nachrichten mit einem Level gleich oder höher stimmen nicht überein; Ausrufezeichen und gleich stimmen nicht mit Nachrichten überein, deren Ebene gleich der angegebenen ist.

Als Aktion können Sie Folgendes angeben:

• regulärer Dateiname (vollständiger Pfad vom Stammverzeichnis), Minus vor dem Namen deaktiviert die Datensatzsynchronisierung
• Named Channels - fifo (ein vertikaler Strich wird vor dem Namen platziert), der Channel selbst sollte erstellt, bevor syslogd mit dem Befehl mkfifo gestartet wird
• Terminal oder Konsole
• @hostname (Nachrichten für Remote-Logging senden)
• Liste der Benutzer (durch Kommas getrennt), an deren Endgeräte die Nachricht gesendet wird
• ein Sternchen, um eine Nachricht an alle Terminals zu senden (Wall)

Beim Parsen einer Konfigurationsdatei syslogd vergleicht die Adresse loghost(definiert in /etc/hosts, nicht über DNS) mit der Adresse Ihres Computers und definiert bei Übereinstimmung eine Variable LOGHOST... Danach wird syslog.conf durch den Makroprozessor m4 (1) geleitet. Grundsätzlich wird dies verwendet, damit auf Client- und Server-Hosts (aus Syslog-Sicht) dieselbe Konfigurationsdatei verwendet werden kann.

Start- und Stoppverfahren: /etc/init.d/syslog(Links dazu aus den Verzeichnissen /etc/rc?.d). Die Prozessnummer wird gespeichert in /etc/syslog.pid.

klogd liest Kernel-Nachrichten (entweder über /proc/kmsg oder Systemaufrufe), bestimmt den Level, übersetzt Befehlsadressen in Programmnamen und sendet eine Nachricht an syslogd.

Startparameter:

• -c-Ebene(Meldungen dieser Stufe und weniger schwerwiegende werden an Syslog gesendet und schwerwiegendere Meldungen werden an die Konsole ausgegeben; standardmäßig - 7; 0 kann nicht angegeben werden)
• -D(Debug-Modus)
• -F Dateiname (einloggen bei angegebene Datei statt Syslog)
• -ich(Modulsymbole in einem bereits laufenden klogd neu laden, muss jedes Mal verwendet werden, wenn ein Modul geladen oder entladen wird; hoffentlich tun die aktuellen Versionen von insmod, rmmod und modprobe dies von selbst)
• -ICH(Kernel- und Modulsymbole in bereits laufendem klogd neu laden)
• -k Dateiname (verwenden Sie die angegebene Datei als Kernel-Symboltabelle anstelle von /boot/System.map)
• -n(nicht in den Hintergrund gehen; zum Ausführen von init erforderlich)
• -Ö(einmaliger Modus - alle im Kernelpuffer angesammelten Nachrichten protokollieren und beenden)
• -P(Für alle Fälle, laden Sie die Modulsymboltabelle zum Zeitpunkt der Adressübersetzung neu - der Kernel kann dies möglicherweise nicht)
• -S(Verwenden Sie nur Systemaufrufe und gehen Sie nicht zu / proc / kmsg, um die Originalnachrichten abzurufen)
• -v(Version anzeigen und fertig stellen)
• -x(konvertieren Sie keine Adressen in Namen)
• -2 (Mitteilungen anormale Beendigung Kernel - Hoppla! -wird zweimal ausgegeben: vor der Umwandlung von Adressen in Namen - für ksymoops - und danach)

Kernel-Meldungsebenen (durch die Zahl in spitzen Klammern bestimmt und in den Syslog-Schweregrad konvertiert, unverändert bei der Dateiausgabe):

• KERN_EMERG - 0 (System ist unbrauchbar)
• KERN_ALERT - 1 (Es muss sofort gehandelt werden)
• KERN_CRIT - 2 (kritische Bedingungen)
• KERN_ERR - 3 (Fehlerbedingungen)
• KERN_WARNING - 4 (Warnbedingungen)
• KERN_NOTICE - 5 (normaler, aber signifikanter Zustand)
• KERN_INFO - 6 (informativ)
• KERN_DEBUG - 7 (Nachrichten auf Debug-Ebene)

Reaktion auf Signale:

• SIGINT, SIGKILL, SIGTERM und SIGHUP - Herunterfahren
• SIGTSTP - Protokollierung stoppen
• SIGCONT - Lebenslauf, möglicherweise einen anderen auswählen
Quelle der Nachrichten (/proc/kmsg oder Systemaufrufe)
• SIGUSR1 - Symbole von Modulen nachladen
• SIGUSR2 - Kernel- und Modulsymbole neu laden

Die Prozessnummer wird gespeichert in /var/run/klogd.pid.

Logging-Initialisierung: openlog- das Standardpräfix, das allen nachfolgenden Nachrichten hinzugefügt wird, wird angezeigt (normalerweise der Programmname, die Prozessnummer in eckigen Klammern und ein Doppelpunkt); Quelle und Optionen. schließenlog- Protokollierung beenden. syslog- Logging (gibt die Quelle, den Schweregrad und das Format des Strings wie in printf an).

logrotieren(Version 3.2-1 / 3.3.2-1 / 3.5.9) - Kampf gegen wachsende Protokolle: Rotation (Versionierung), Komprimierung, Löschung und Mailing. Läuft täglich von cron ( /etc/cron.daily/logrotate) und ermöglicht Ihnen, Protokolle zu verarbeiten, wenn sie die angegebene Größe oder das angegebene Zeitintervall überschreiten. Ermöglicht Ihnen, nicht nur Syslog-Protokolle, sondern auch alle anderen Programme zu verarbeiten. Optionen:

• [-D](Debug-Modus, es werden keine wirklichen Änderungen vorgenommen)
• [-F](Änderungen auch dann vornehmen, wenn logrotate die Notwendigkeit nicht sieht - es wird verwendet, wenn Änderungen in der Liste der verarbeiteten Protokolle vorgenommen werden)
• [-S Zustandsdateiname ] (der aktuelle Status der Protokolle wird standardmäßig zwischen den Läufen in dieser Datei gespeichert - /var/lib/logrotate.status)
• Konfigurationsdateinamen (Namen durch Leerzeichen getrennt; Reihenfolge ist wichtig; wenn ein Verzeichnisname angegeben wird, wird jede darin enthaltene Datei als Konfigurationsdatei betrachtet; RH verwendet eine Datei /etc/logrotate.conf und Verzeichnis /etc/logrotate.d)

Die Konfigurationsdatei definiert globale Parameter (einer pro Zeile), die die Standardparameter für alle Protokolle festlegen. Für jeden verarbeiteten Protokollstapel werden lokale Parameter angegeben: Der Basisdateiname wird angegeben, gefolgt von den lokalen Parametern in geschweiften Klammern, einer pro Zeile. Der Dateiname kann von Shell-Regeln in Anführungszeichen gesetzt werden, wenn er Leerzeichen oder andere Sonderzeichen enthält. Sie können mehrere Dateinamen oder Dateinamenmuster durch Leerzeichen getrennt angeben (Muster folgen auch Shell-Regeln). Die Verarbeitung jedes Abschnitts wird als eine einzelne Aktion behandelt. Zeilen, die mit dem Zeichen "#" beginnen, sind Kommentare. Die im Folgenden angegebenen Parameter Konfigurationsdateiüberschreiben Sie die Werte der Parameter, die in der vorherigen Datei angegeben sind. Lokale Parameter haben Vorrang vor globalen. Die Reihenfolge der Dateien im Konfigurationsverzeichnis ist undefiniert.

Optionen:

• Kompresse | nocompress(ältere Versionen sind mit gzip komprimiert oder nicht komprimiert)
• komprimierencmd(setzt das Komprimierungsprogramm, standardmäßig gzip)
• dekomprimierencmd(setzt das Dekompressionsprogramm standardmäßig - ungzip)
• komprimieren(setzt das Suffix für komprimierte Dateien)
• Komprimierungsoptionen(setzt die Parameter des Komprimierungsprogramms; die Voreinstellung ist "-9", also die maximale Komprimierung für gzip)
• kopierentruncate | nocopytruncate(normalerweise wird die alte Version umbenannt und erstellt eine neue Version Zeitschrift; Wenn dieser Parameter gesetzt ist, kopiert logrotate das Protokoll nach neue Datei und schneidet dann den alten ab; Wird verwendet, wenn das Programm, das das Journal erstellt, es nicht schließen kann; Aufzeichnungen, die in der Zeit zwischen Kopieren und Ausschneiden erstellt wurden, gehen verloren; Aber hilft es, wenn das Programm, das das Protokoll erstellt, statt im Append-Modus einfach mit einem internen Zeiger in eine Datei schreibt?)
• schaffen [ Zugangsrechte Eigentümer Gruppe] | nocreate(sofort nach Umbenennung alte Version log und vor dem Anruf nachdrehen ein neues Protokoll wird mit den angegebenen Attributen erstellt - Berechtigungen werden in Oktal gesetzt, wie in chmod.2; wenn keine Attribute angegeben sind, werden sie aus dem alten Protokoll übernommen)
• Täglich(Versionswechsel in der Serie erfolgt täglich)
• Verzögerungskomprimierung | Nodelaycompress(einige Programme schließen das Protokoll nicht sofort, in diesem Fall sollte die Komprimierung auf den nächsten Zyklus verschoben werden)
• Fehler Email (an wen Fehlerberichte gesendet werden sollen)
• Verlängerung Suffix (legt das Suffix, das den Dateinamen beim Rotieren hinzugefügt wird, vor dem Komprimierungssuffix)
• wenn leer | benachrichtigen(Versionen ändern, auch wenn die Datei leer ist; dies ist die Standardeinstellung)
• enthalten Dateiname | Verzeichnisname (Textlich eine Datei oder alle Dateien aus dem angegebenen Verzeichnis ersetzen; Unterverzeichnisse, spezielle Dateien und Dateien mit Suffixen aus der Ausschlussliste sind nicht enthalten; können nicht innerhalb eines Abschnitts verwendet werden)
• E-Mail die Anschrift | nomail(wenn ein Versionswechsel das Löschen des alten Logs erforderlich macht, dann an die angegebene Adresse senden)
• mailfirst(senden Sie nicht die gelöschte Version des Journals, sondern die erste)
• maillast(Sende die gelöschte Version des Protokolls; dies ist die Standardeinstellung)
• fehltok | nomissingok(keine Fehlermeldungen senden, wenn das Protokoll fehlt)
• monatlich(Versionswechsel erfolgt monatlich)
• altdir Verzeichnis | noolddir(Bei einer Versionsänderung wird das Protokoll in das angegebene Verzeichnis verschoben; sollte sich auf demselben physischen Gerät befinden)
• nachdrehen Endskript werden nach dem Upgrade-Prozess als Shell-Befehle ausgeführt)
• vordrehen(alle weiteren Zeilen bis zur Zeile Endskript werden vor dem Upgrade-Prozess ausgeführt)
• drehen Nummer (wie viele alte Versionen sollen behalten werden; wenn 0, dann keine)
• Größe Byte (Versionswechsel erfolgt, wenn die Größe des Protokolls die angegebene Anzahl überschritten hat; Sie können die Suffixe "k" - Kilobyte - und "M" - Megabyte verwenden)
• Sharedscripts | nosharedscripts(Befehle ausführen vordrehen und nachdrehen nur einmal für alle im Abschnitt beschriebenen Dateien)
• tabuext [+ ] Suffix-Liste (Angeben einer Liste von Suffix-Ausnahmen für enthalten; wenn das Pluszeichen angegeben ist, dann Addition, sonst Ersetzung; Voreinstellungen: .rpmorig, .rpmsave, .rpmnew, ", v", .swp und "~")
• wöchentlich(Versionswechsel erfolgt wöchentlich)

Im Lieferumfang RH /etc/logrotate.conf beschreibt die globalen Parameter und Parameter für /var/log/wtmp und /var/log/lastlog und verweist auf das Verzeichnis /etc/logrotate.d, in die jedes Paket lokale Parameter für seine Protokolle schreibt.

logwatch ist ein Framework zum Schreiben von Programmen (sogenannten Filtern), um nützliche Informationen aus zahlreichen, großen und unterschiedlichen Protokollen (nicht nur Syslog) zu extrahieren. Das "Paket" enthält mehrere Filter, die für Red Hat Linux entwickelt wurden (eine Art alte Version, da inetd anstelle von xinetd erwähnt wird), die Sie jedoch selbst an die jeweilige Situation anpassen müssen. Die letzte Änderung wurde vom Autor im September 2000 vorgenommen, sodass keine weiteren Entwicklungen abgewartet werden müssen.

Filter können in jeder Programmiersprache geschrieben werden, aber der Autor des Pakets bevorzugt Perl. Filter sollten so geschrieben werden, dass sie Daten von stdin lesen und das Ergebnis an stdout ausgeben. Vor dem Aufruf des Filters werden die Umgebungsvariablen gesetzt: LOGWATCH_DATE_RANGE, LOGWATCH_DETAIL_LEVEL, LOGWATCH_TEMP_DIR, LOGWATCH_DEBUG. Das Hauptprogramm ist ebenfalls in Perl geschrieben: /etc/log.d/scripts/logwatch.pl(/etc/log.d/logwatch, /usr/sbin/logwatch und /etc/cron.daily/00-logwatch sind symbolische Links dazu).

Verzeichnis /etc/log.d/conf/logfiles/ enthält Konfigurationsdateien von Protokollgruppen, in denen Aufzeichnungen von gepflegten Diensten gespeichert werden. Jede Gruppe wird in einer separaten Datei beschrieben Gruppenname.conf, die setzt:

• LogFile = Name der Datei, die das Protokoll enthält, oder Namensmuster; mehrere Namen oder Muster können angegeben werden; Namen m. relativ zu LogDir
• Archiv = der Name der Datei, die vom Logrotate der archivierten Version des Logs erstellt wurde, oder ein Benennungsmuster; mehrere Namen oder Muster können angegeben werden; Namen m. relativ zu LogDir
• Filternamen ( nur einmal, obwohl das andere angezeigt wird!) von /etc/log.d/scripts/shared/ als
  *Filtername = Optionen , um beispielsweise das Protokoll nach Datum zu filtern, wenn es im Standard-Syslog-Format geschrieben ist, verwenden Sie die Zeile:
  * ApplyStdDate =

Verzeichnis /etc/log.d/conf/services/ enthält die Konfigurationsdateien für die Dienste, deren Logeinträge logwatch verarbeitet. Jeder Service wird in einer separaten Datei beschrieben Dienstname.conf, die setzt:

• LogFile = Name der Log-Gruppe
• Namen filtern nach /etc/log.d/scripts/shared/ als
  *Filtername = Optionen vor dem Servicefilter
• $Umgebungsvariablenname = Bedeutung

Verzeichnis /etc/log.d/scripts/logfiles/ enthält Filter für die Verarbeitung von Log-Gruppen: Bei der Verarbeitung einer Gruppe von Logs werden alle Dateien im Verzeichnis /etc/log.d/scripts/logfiles/ Gruppenname werden als Filter verwendet.

Verzeichnis /etc/log.d/scripts/services/ enthält Filter zur Verarbeitung von Datensätzen bestimmter Dienste.

Verzeichnis /etc/log.d/scripts/shared/ enthält allgemeine Filter, die in Konfigurationsdateien für Protokollgruppen verwendet werden:

• applystddate - filtert das Log nach dem gewünschten Datum, wenn es im Syslog-Format geschrieben ist (hier und in privaten Filtern nach Datum, füge LANG = vor dem Aufrufdatum ein, sonst stimmt Mar in keiner Weise mit Mar überein;)
• expandrepeat - wandelt die Zeilen "Letzte Nachricht wiederholt" in die entsprechende Anzahl von Nachrichtenzeilen der vorherigen Zeile um
• onlycontains - hinterlässt nur die Protokollzeilen, die die angegebene Zeichenfolge enthalten (ich habe "$ *" in Anführungszeichen gesetzt)
• onlyservice - extrahiert aus den Syslog-Protokollzeilen, die sich auf den angegebenen Dienst beziehen (der Dienstname wird als Parameter übergeben)
• entfernen - lässt nur die Protokollzeilen im Syslog-Format zurück, die die angegebene Zeile nicht enthalten ( Ich habe "$ *" in Anführungszeichen gesetzt und remove1, remove2 usw. da ich nicht verstanden habe, wie man mehrere Untermuster für egrep in einer Zeile angibt; die Parameter werden übrigens in der Shell ersetzt, Sonderzeichen können also auch nicht verwendet werden)
• removeheaders - Standardfelder entfernen (Datum, Uhrzeit, Hostname, Service-Label und Prozessnummer)
• removeservice - extrahiert Zeilen aus dem Protokoll im Syslog-Format, die sich nicht auf den angegebenen Dienst beziehen (der Dienstname wird als Parameter übergeben)

Die Standardparameter sind in der Datei /etc/log.d/conf/logwatch.conf gespeichert (/etc/log.d/logwatch.conf hat einen symbolischen Link dazu), Kommentare, in denen Sie die Bedeutung der Parameter:

• LogDir - das Verzeichnis, zu dem die Dateinamen betrachtet werden
• MailTo - an wen der Bericht gesendet werden soll
• Drucken - Anstatt einen Bericht per Post zu senden, senden Sie ihn an stdout
• Speichern - Anstatt den Bericht per E-Mail zu senden, wird er in der angegebenen Datei gespeichert
• Archive - Verwenden Sie Versionen von Protokollen, die von logrotate generiert wurden
• Bereich - betrachtetes Zeitintervall: Alle, Heute, Gestern (der gestrige Kalendertag)
• Detail - Detailgrad des Berichts: von 0 bis 10 oder Niedrig, Mittel, Hoch
• Service - Alle oder Filtername aus /etc/log.d/scripts/services/ (mehrere Filter können angegeben werden)
• LogFile - Alle oder der Name der Log-Gruppe (mehrere Gruppen können angegeben werden)

Startparameter:

• --Detail Niveau (Detailgenauigkeit des Berichts: hoch, mittel oder niedrig)
• --Logdatei Gruppenprotokolle (nur die Protokolle dieser Gruppe verarbeiten; die Gruppe wird durch einen symbolischen Namen in der Konfigurationsdatei angegeben; mehrere Gruppen können angegeben werden)
• --Service Dienstname (nur die Einträge in den Logs verarbeiten, die sich auf diesen Dienst beziehen; der Dienst wird durch einen symbolischen Namen in der Konfigurationsdatei angegeben; mehrere Dienste können angegeben werden; Name Alle ruft die Verarbeitung von Datensätzen für alle Dienste auf)
• --drucken(Bericht an Standard)
• --mailto die Anschrift (Bericht an die angegebene Adresse senden)
• --speichern Dateiname (Schreiben Sie den Bericht in die angegebene Datei)
• --Archiv(nicht nur aktuelle Versionen von Logs verarbeiten, sondern auch alte Kopien, die von logrotate erstellt wurden)
• --Bereich Datumsintervall (Verarbeiten Sie nur die Einträge in den Protokollen, die sich auf das angegebene Zeitintervall beziehen: Gestern, Heute, Alle)

Der Hauptzweck besteht darin, die Datei 00-logwatch (beginnend bei "00", um vor logrotate ausgeführt zu werden) in das Verzeichnis /etc/cron.daily einzufügen, wodurch logwatch täglich mit Standardoptionen ausgeführt wird.

Leider sind alle Filter so konzipiert, dass die Protokolle auf demselben Host geschrieben werden, auf dem der Dienst ausgeführt wird.

Alle Protokolle werden auf einem Computer gespeichert (wenn Sie paranoide Tendenzen haben, können Sie Protokolle auf zwei Servern gleichzeitig aufzeichnen).

Die Entsprechung zwischen dem formalen Quellennamen und dem realen Gerät oder Programm:

• local0 - Cisco
• local3 - ftp (es gibt einen speziellen Quellnamen, aber Solaris 2.5 kennt ihn nicht)
• local4 - reserviert für Buchhaltung
• local5 - POP3 / IMAP
• local6 - tac_plus>

Auf dem Server sollte ein Bildschirm für Port 514 / udp geöffnet sein (Sie können die Quelladressen von Paketen einschränken, dies hilft jedoch nur bei Unfällen). Das Starten von syslogd (Parameter in /etc/rc.d/init.d/syslog oder /etc/sysconfig/syslog) muss mit den Tasten "-r -m 0" (und auch "-x", wenn derselbe Computer läuft) erfolgen DNS Server). Starten Sie klogd mit den Schaltern "-2 -c 1". Syslog.conf-Setup:

• * .crit - Nachrichten mit CRIT-Schweregrad und höher sollten an Terminals gesendet und in eine separate Datei (chmod 600) geschrieben werden, Ihre Nachrichten sollten an den Backup-Server gesendet werden; sendmail betrachtet Nachrichten über Probleme beim Mailempfang als kritisch
• kern - eine Kern-Datei für alle Nachrichtenebenen erstellen (chmod 600)
• mail - Erstellen Sie eine Maildatei für Nachrichten aller Ebenen (keine Synchronisation)
• auth, authpriv - Erstellen Sie eine sichere Datei für Nachrichten aller Ebenen (chmod 600)
• news - für jeden Schweregrad eine separate Datei im News-Verzeichnis erstellen (Debugging ohne Synchronisation)
• cron - Cron-Datei für Nachrichten aller Ebenen erstellen (cron in RH 6.2 und Solaris 2.5 kann Syslog nicht verwenden)
• local0 - Erstellen Sie eine separate Datei für jeden Schweregrad im Cisco-Verzeichnis (err und darunter ohne Synchronisation)
• local3 - für jeden Schweregrad eine separate Datei im FTP-Verzeichnis erstellen (Info und Debug ohne Synchronisation)
• local5 - imap.log-Datei für Nachrichten aller Ebenen erstellen
• local6 - Erstellen Sie eine tac_plus.log-Datei für Nachrichten aller Ebenen
• local7 - boot.log-Datei (Meldungen, wenn das System bootet und syslogd und klogd starten oder stoppen)
• alle Nachrichten ab INFO-Level, die nicht in eine der oben definierten Dateien gelangt sind, in die Nachrichtendatei schreiben (chmod 600)

Konfigurieren Sie auf Client-Computern Syslog so, dass alle Nachrichten an den Syslog-Server gesendet werden, Fehlermeldungen in /var /log / syslog dupliziert werden, kritische Statusmeldungen an die Konsole und Benutzerterminals dupliziert werden. Auf Linux-Rechnern werden auch Boot-Meldungen in die lokale Datei (local7, boot.log) geschrieben. Der Backup-Syslog-Server sollte kritische Nachrichten vom Netzwerk empfangen und in eine Datei schreiben (Lücke im Bildschirm, Startschalter "-r").

logrotate: ewig aufbewahren, Versionen so selten wie möglich wechseln (monatlich, außer squid), in separate Verzeichnisse kopieren (außer squid) und komprimieren (im verzögerten Modus, außer ftpd, linuxconf, sendfax), Fehler und gelöschte Dateien an mich senden. Match-Parameter für Syslog.

SERGEY SUPRUNOV

FreeBSD-Tipps: Syslog verwenden

- Entschuldigen Sie, Genossen, ich habe alle Züge aufgeschrieben!

„Das Büro schreibt“, sagte Ostap.

I. Ilf, E. Petrov "12 Stühle".

Die Protokollierung der Arbeit eines beliebigen Systems und vor allem des Servers ist einer der wichtigsten Bestandteile der Administration. In den Protokolldateien schauen wir zuerst, wenn es Probleme im System gibt. Daraus leiten wir die Zuversicht ab, dass dieses oder jenes Programm wie erwartet funktioniert. Bei der Entwicklung von Webanwendungen wird die Protokolldatei zur wichtigsten Quelle für Debugging-Informationen. Die Funktionen des syslog-Daemons, der für die Protokollierung von Systeminformationen verantwortlich ist, werden besprochen.

Was ist Syslog?

Syslog ist ein zentralisierter Dienst, der Protokollinformationen von verschiedenen Betriebssystemkomponenten und Benutzerprozessen sammelt und aufzeichnet. Programme von Drittanbietern können normalerweise selbst mit ihren Protokolldateien arbeiten, obwohl viele von ihnen so konfiguriert werden können, dass sie mit dem syslogd-Daemon arbeiten. Zu den Vorteilen der Verwendung von syslog gehört die Möglichkeit, den Prozess der Erfassung der erforderlichen Informationen mit einer einzigen Konfigurationsdatei zu steuern, was die Konsistenz der resultierenden Protokolldateien gewährleistet und somit deren Verwaltung vereinfacht.

Der syslog-Dienst wird vom syslogd-Daemon bereitgestellt, der beim Systemstart automatisch gestartet wird. Es befindet sich ständig im Speicher, wartet auf Nachrichten von anderen Prozessen und verarbeitet diese gemäß seinen Einstellungen.

Jede Nachricht ist durch eine Ebene und eine Einrichtung gekennzeichnet. Der Level gibt den Wichtigkeitsgrad der Nachricht im Hinblick auf die Funktionsfähigkeit des Systems an. Die Datei syslog.h definiert die folgenden Ebenen (Prioritäten):

Tabelle 1. Nachrichtenebenen

Tabelle 1 listet die Nachrichtenebenen in absteigender Reihenfolge auf. Diese Reihenfolge wird später bei der Erörterung der Syntax der Konfigurationsdatei benötigt.

Bezeichner der Nachrichtenebene, die in derselben Zeile stehen (z. B. emerg und panic) sind Synonyme und können beliebig verwendet werden. Panik, Fehler und Warnung (an zweiter Stelle in der Tabelle aufgeführt) sind jedoch veraltet und sollten beim Bearbeiten der Konfigurationsdatei vermieden werden. Verwenden Sie stattdessen emerg, err und warning.

Mögliche Quellen der Meldung sind in Tabelle 2 aufgeführt:

Tabelle 2. Nachrichtenquellen

Wenn Sie eine Anwendung für die Arbeit mit dem Syslog-Dienst konfigurieren, prüfen Sie, welche Einrichtung sie verwendet. Bei einigen Programmen können Sie die Quelle selbst angeben. Der clamd-Daemon (der Hauptprozess des clamav-Antivirus) verwendet beispielsweise standardmäßig local6, ermöglicht jedoch die Angabe einer anderen Quelle (der LogFacility-Parameter in der Konfigurationsdatei). In einigen Fällen kann es sinnvoll sein, seine Nachrichten mit Nachrichten von Mail-Diensten zu kombinieren und dabei LOG_MAIL als Quelle anzugeben.

Daemon-Startoptionen

Eine vollständige Liste der Startoptionen finden Sie auf der Manpage syslogd. Hier werden wir nur einige davon betrachten.

Syslog ist in der Lage, eingehende Nachrichten in Protokolldateien zu schreiben (die sich normalerweise im Verzeichnis / var / log befinden), sie an die Konsole oder ein angeschlossenes Benutzerterminal zu senden, an einen Remote-Host zu senden oder sie an ein externes Dienstprogramm weiterzuleiten wird bearbeitet.

Für das Netzwerk verwendet Syslog die Ports 514 (UDP und TCP). Gestartet ohne zusätzliche Parameter, syslogd überwacht diese Ports auf eingehende Nachrichten. Der Schalter -s deaktiviert eingehende Nachrichten, aber Sockets auf den Ports 514 werden weiterhin für ausgehende Verbindungen erstellt, damit syslogd Nachrichten an entfernte Hosts senden kann. Das Verdoppeln des Schlüssels (-ss) verweigert auch ausgehende Verbindungen.

Standardmäßig wird syslogd mit dem Schalter -s gestartet (siehe /etc/defaults/rc.conf, Parameter syslogd_flags), sodass eingehende Verbindungen verweigert werden. Wenn Sie den Syslog-Dienst Ihres Servers verwenden möchten, um mehrere Maschinen zu bedienen, fügen Sie die folgende Zeile zu /etc/rc.conf hinzu:

syslogd_flags = ””

Dadurch wird der in /etc/defaults/rc.conf festgelegte Wert überschrieben, sodass syslogd eingehende Verbindungen verarbeiten kann. In diesem Fall ist es natürlich notwendig, das erforderliche Sicherheitsniveau zu gewährleisten und auszuschließen, dass fremde Hosts etwas in Ihre Logs schreiben. Mit dem Schalter -a können Sie Einschränkungen für eingehende Verbindungen festlegen (siehe man syslogd). Auch eine richtig konfigurierte Firewall spielt eine wichtige Rolle.

Ein weiterer nützlicher Schalter -l ermöglicht es Ihnen, zusätzliche Socket-Dateien anzugeben, auf die syslogd zusätzlich zu der Standardeinstellung /var/run/log lauscht. Dieser Schalter ist beispielsweise erforderlich, damit syslog Programme verarbeiten kann, die in einer Chroot-Umgebung ausgeführt werden. So funktioniert named seit BIND 9. Unter FreeBSD 5.3 wird syslogd mit gestartet mit den folgenden Tasten:

# ps -Wachs | grep syslog

Syntax der Konfigurationsdatei

Die Protokollierung wird in der Datei /etc/syslog.conf konfiguriert. Es versteht sich von selbst, dass nur der Root-Benutzer es bearbeiten kann. Diese Datei enthält zwei Arten von Strings - nennen wir sie "Filter" und "Regeln".

Die Filterzeichenfolge gibt das Programm oder den Host an, von dem die folgenden Regeln auf Nachrichten angewendet werden sollen. Ein Filter wie "! Prog" (oder "#! Prog") zeigt an, dass sich die folgenden Zeilen auf die erzeugten Logs beziehen dieses Programm prog. Das Synonym für diesen Eintrag ist "! + Prog". Umgekehrt bedeutet die Zeile "! -Prog", dass die folgenden Regeln für alle Nachrichten gelten, außer denen, die vom Programm prog kommen. Es ist erlaubt, mehrere Programme durch Kommas getrennt aufzulisten, während das "+" oder "-" Zeichen auf die gesamte Liste angewendet wird.

Wenn die Filterzeichenfolge als "+ Hostname" angegeben ist, wird der angegebene Host als Quelle von Nachrichten verwendet, die von nachfolgenden Regeln verarbeitet werden. Wie bei Programmen zeigt das Symbol „-“ an, dass die Regeln für alle Nachrichten gelten, mit Ausnahme derjenigen, die vom angegebenen Host stammen. Sie können eine durch Kommas getrennte Liste von Hosts angeben.

Das als Programm oder Host angegebene Zeichen "*" überschreibt den zuvor eingestellten Filter. Das heißt, die nach einer solchen Zeile angegebenen Regeln gelten für alle Nachrichten. Filter mit Hostnamen oder Programmnamen sind voneinander unabhängig und können gleichzeitig arbeiten. Zum Beispiel:

# Die hier aufgeführten Regeln gelten für alle Nachrichten

Mein Gastgeber

# Regeln gelten für alle Nachrichten von my.host

Logger

# Regeln gelten für Nachrichten von Logger mit my.host (Hostfilter wird fortgesetzt)

# Regeln gelten für Nachrichten von su mit my.host

# Regeln gelten für Nachrichten von su von jedem Host (Hostfilter wird abgebrochen, Programmfilter wird fortgesetzt)

# Die Regeln werden auf alle Nachrichten angewendet (der Programmfilter wird auch aufgehoben)

Regelzeilen sehen so aus:

Einrichtung.CMPlevel-Ziel

Hier ist Facility die Quelle der Nachricht ("*" steht für beliebige Quellen), level ist die Ebene der Nachrichten, die gemäß dieser Regel verarbeitet werden. Das anstelle des Levels angegebene Service-Wort "none" weist an, Meldungen von dieser Quelle vollständig auszuschließen.

CMP - Vergleichsoperation (Symbole ">", "<», «=», «>=», «<=», а также символ отрицания «!»). Если символ сравнения не указан, подразумевается «больше или равно», то есть обрабатываются все сообщения уровня level и выше.

Ziel gibt an, wo diese Nachricht gespeichert werden soll. Dies kann eine Log-Datei sein (der vollständige Pfad wird angegeben, beginnend mit "/"), die Adresse des entfernten Servers (beginnend mit dem "@"-Symbol), ein Benutzername (Nachrichten werden an das Terminal gesendet, an das dieser Benutzer Ist verbunden). Außerdem kann die Nachricht zur Verarbeitung an ein externes Programm übergeben werden, für das das Pipe-Symbol "|" verwendet wird.

Ein paar Beispiele für Regeln

Alle Kernel-Nachrichten werden an die Datei kern.log gesendet.

kern.* /var/log/kern.log

Alle Fehlermeldungen sowie Emerg-, Alert- und Crit-Level-Meldungen werden in all-err.log abgelegt. Beachten Sie den Bindestrich vor dem Protokolldateinamen. Standardmäßig werden Nachrichten im Speicher gepuffert und auf die Festplatte geschrieben, wenn sich der Puffer füllt. Dies verringert die Belastung des Dateisystems, kann jedoch dazu führen, dass einige Informationen verloren gehen, wenn die Maschine abstürzt. Der Bindestrich vor dem Dateinamen veranlasst den syslogd-Daemon, Nachrichten sofort auf die Platte zu schreiben.

* .err - / var / log / all-err.log

Debug-Meldungen von Benutzerprozessen werden an das Terminal ausgegeben, mit dem der Benutzer vasya gerade verbunden ist.

user.debug vasya

Alle Nachrichten von Nachrichten- und E-Mail-Diensten werden an Port 514 der Maschine syslog.host.ru weitergeleitet.

Mail. *, Nachrichten. * @ syslog.host.ru

Alle Druckservice-Meldungen unterhalb der Warnung werden in der angegebenen Datei abgelegt. Wie bereits erwähnt, ist der Standardwert größer oder gleich dem Vergleich, und die! es invertiert und ersetzt es durch "weniger". Wenn Sie eine bestimmte Ebene ausschließen müssen, sollten Sie die Konstruktion "! =" verwenden.

lpr.!-Warnung /var/log/printers.log

Debug-Level-Meldungen (und nur Debug-Meldungen) mit Facility Level0 und Level3 werden an alle angeschlossenen Terminals ausgegeben.

level0, level3. = debuggen *

Time Service-Meldungen, die höher als kritisch (d. h. Emerg und Alert) und kleiner oder gleich Benachrichtigung (Notice, Info und Debug) sind, werden an die Terminals der ntpuser- und root-Benutzer gesendet.

ntp.>krit,<=notice ntpuser,root

Alle Warnmeldungen, außer von Mail-Diensten, werden in die Datei warn.log geschrieben.

*. = Warnung, mail.none /var/log/warn.log

In diesem Fall werden alle Nachrichten mit einem Level größer oder gleich crit an den Root-Benutzer gesendet.

* .krit | mail -s „kritische Nachricht“ root

Wie Sie sehen, ermöglicht das Konfigurationsdateiformat die Auflistung mehrerer Ebenen, Quellen und Ziele in einer Zeile, was die Konfiguration flexibler macht. Damit die Änderungen nach der Bearbeitung wirksam werden, müssen Sie ein HUP-Signal an den syslogd-Prozess senden:

# kill –HUP `cat/var/run/syslog.pid`

Es ist zu beachten, dass, wenn diese oder jene Nachricht unter die Aktion mehrerer Zeilen in der Konfigurationsdatei fällt, sie entsprechend jeder von ihnen verarbeitet wird. Beispiel:

mail.* / var / log / maillog

*. = err /var/log/error.log

In diesem Fall werden mail.err-Nachrichten sowohl an maillog als auch an error.log gesendet.

Konfigurationsdateistrategie

Zum Abschluss meiner Betrachtung der Konfigurationsdatei möchte ich noch ein paar Worte zu den Strategien für ihre Kompilierung sagen. Neben dem sehr beliebten „wenn es nur funktioniert“ gibt es zwei Hauptansätze, die wir bedingt „nach Quelle“ und „nach Zweck“ nennen.

• Die erste Strategie, die in einer Reihe von GNU/Linux-Distributionen zu beobachten ist, besteht darin, für jede Nachrichtenquelle eine andere Regel zu schreiben (oder eine Gruppe von Regeln, wenn Nachrichten unterschiedlicher Ebenen unterschiedlich verarbeitet werden sollen). Sein Vorteil ist die einfache Bestimmung, wo Nachrichten bestimmter Dienste geschrieben werden.
• Die Strategie „nach Ziel“ besteht darin, für jeden „Empfänger“ einer Nachricht, beispielsweise einer Datei, nach Möglichkeit nur eine Zeile zu erstellen. Dies ist insbesondere der Ansatz von FreeBSD. Dadurch können Sie leicht feststellen, welche Informationen in einer bestimmten Protokolldatei aufgezeichnet werden, aber beispielsweise müssen die Ziele für Kernel-Meldungen aus der gesamten Konfigurationsdatei gesammelt werden.

Logger-Dienstprogramm

Das System enthält ein Protokollierungsdienstprogramm, mit dem Sie Nachrichten direkt über die Befehlszeile an den Syslog-Dienst senden können. Es ist praktisch, es beim Testen von Konfigurationsregeln sowie beim Entwickeln von Skripten zum Protokollieren ihrer Arbeit zu verwenden. Beispiele:

user $ logger -p user.err „Fehler im Anwenderprogramm!“

user $ logger -h syslog.host.ru „Testen“

Das erste Beispiel sendet eine Benutzernachricht für eine Einrichtung auf Fehlerebene, die gemäß der Konfigurationsdatei verarbeitet wird. Der zweite Befehl sendet eine Nachricht an den Remote-Host, die Quelle und der Standardpegel werden auf user.notice gesetzt.

Verwendung von Rotationsmechanismen

Der oben erörterte Protokollierungsmechanismus bietet keine Art von Protokolldateiverwaltung. Nachrichten werden einfach nach den in der Konfigurationsdatei beschriebenen Regeln darin platziert. Dies bedeutet, dass die Protokolldateien ständig wachsen und, wenn nichts unternommen wird, früher oder später den gesamten verfügbaren Platz auf der entsprechenden Partition füllen. Um dies zu vermeiden, wird ein Rotationsmechanismus verwendet.

Sobald die Datei debug.log beispielsweise 100 MB überschreitet, wird sie in debug.log.0 umbenannt und in debug.log.0.bz2 gepackt. Stattdessen wird ein neues debug.log erstellt. Wenn die Größe der neuen Datei 100 MB erreicht, wird debug.log.0.bz2 in debug.log.1.bz2 umbenannt und das obige Verfahren wird wiederholt. Das System speichert nur eine bestimmte Anzahl von Archivdateien und löscht die ältesten. Das ist Rotation.

Newsyslog-Dienstprogramm

Unter FreeBSD ist das Dienstprogramm newsyslog für die Rotation verantwortlich, die standardmäßig zu Beginn jeder Stunde vom Cron-Daemon ausgeführt wird. Sie können den Rotationszeitraum ändern, indem Sie die Datei /etc/crontab bearbeiten.

Die im obigen Beispiel angegebenen Rotationsparameter (Dateigröße, Verpackung) sowie eine Reihe anderer werden in der Konfigurationsdatei /etc/newsyslog.conf festgelegt. Für jede Datei, die eine Rotation benötigt, enthält sie eine Zeile mit im Allgemeinen neun Feldern: Dateiname, Eigentümer und Gruppe, Zugriffsrechte, größte Zahl im Archivdateinamen, maximale Dateigröße, Rotationszeitraum, zusätzliche Flags und der Pfad zur PID-Datei der Anwendung, das Signal nach der Drehung zu senden, und die Nummer des zu sendenden Signals. (Möglicherweise müssen Sie ein Signal an einen Prozess senden, wenn der Prozess die Protokolldatei die ganze Zeit geöffnet hält; andernfalls stimmt der verwendete Dateideskriptor nicht mit der neu erstellten Datei überein.) Einige Felder können ausgelassen werden. Hier sind zwei Beispiele, vollständig und typisch:

/var/log/pflog root: Rad 600 3 100 * JB /var/run/pflog.pid 1

Nach dieser Regel muss die pflog-Datei unabhängig von der Uhrzeit („*“ im 6. Feld) überschrieben werden, sobald ihre Größe 100 MB überschreitet (5. Feld). Archivdateien haben Namen wie pflog.X.bz2 (pflog.0.bz2, pflog.1.bz2 usw.) und X darf nicht mehr als drei sein (Parameter 3 im 4. Feld). Das Flag J gibt an, dass die Archivdatei mit dem Dienstprogramm bzip2 komprimiert werden soll. Dank des B-Flags werden die Servicemeldungen zur Rotation nicht zu den archivierten und neu erstellten Dateien hinzugefügt, da die Datei als binär wahrgenommen wird. Die neu erstellte Datei wird dem Root-Benutzer und der Wheel-Gruppe gehören (dieses Feld hätte weggelassen werden können, da dies der Standardbesitzer ist). Die Berechtigungen werden auf rw ------- (numerischer Wert 600) gesetzt, was bedeutet, dass nur der Besitzer diese Datei lesen und schreiben kann. Schließlich wird ein 1-Signal (HUP) an den Prozess gesendet, dessen PID in /var/run/pflog.pid gespeichert ist, um seine Protokolldatei erneut zu öffnen.

/var/log/maillog 640 7 * @ T00 J

Diese Regel legt die Rotationsparameter für die Maillog-Datei fest: unabhängig von der Größe (ein Sternchen im 5. Feld) wird die Datei jede Nacht um 00:00 neu geschrieben (siehe man newsyslog.conf für eine detaillierte Beschreibung des Zeitformats) . Das Archiv muss gepackt werden, die letzten 8 Archive werden gespeichert (mit Zahlen von 0 bis einschließlich 7), die neu erstellte Datei wird dem Root-Benutzer gehören (Standardwert, daher wird das Besitzerfeld weggelassen) und hat rw-r ----- Berechtigungen.

Sie können die Dienstprogramme zcat und bzcat (für gzip bzw. bzip2) verwenden, um die gepackten Protokolldateien anzuzeigen. Midnight Commander ruft die entsprechenden Dienstprogramme automatisch auf.

Nach der Bearbeitung der Datei newsyslog.conf müssen nirgendwo Signale gesendet werden - die Konfiguration wird beim nächsten Aufruf von newsyslog erneut gelesen.

Beachten Sie, dass das Dienstprogramm newsyslog nicht an den syslogd-Daemon gebunden ist. Das heißt, es kann verwendet werden, um alle Dateien zu drehen, die es benötigen. Wenn die Rotation für Protokolle aktiviert ist, die die Anwendung selbst verwaltet (z. B. für Clamd- oder Squid-Protokolle), achten Sie besonders auf den Eigentümer und die Zugriffsrechte. Eine falsche Angabe kann dazu führen, dass eine Anwendung, die als unprivilegierter Benutzer gestartet wurde, nach der Rotation nicht in die neu erstellte Datei schreiben kann.

Zusammenfassen

Das Syslog-System ist ein sehr leistungsfähiges und effizientes Werkzeug zum Protokollieren verschiedener Ereignisse, die im System auftreten. Die Standardeinstellungen sind ziemlich ausgewogen und funktionieren für die meisten Systeme gut. Wenn Sie jedoch verstehen, wie syslog funktioniert, können Sie die Qualität der Protokollierung erheblich verbessern, indem Sie die Protokollierung an Ihre spezifischen Anforderungen anpassen.

Der syslogd-Daemon (System Logging-Deamon) bietet die Art der Protokollierung, die von den meisten Programmen unterstützt wird. Der Daemon syslogd schreibt Nachrichten in die Datei /var/log/syslog. Einträge in dieser Datei enthalten normalerweise folgende Felder: Datum und Uhrzeit, Host, Programm, Nachricht. Ein Beispiel für diese Datei ist unten dargestellt:

27. Januar 17:09:35 dhsilabs modprobe: modprobe: Kann das Modul sound-service-1-0 nicht finden

27. Januar 17:09:35 dhsilabs modprobe: modprobe: Kann "Modul Sound-Slot-1 nicht lokalisieren"

27. Januar 17:12:28 dhsilabs-Kernel: VFS: Festplattenwechsel auf Gerät ide1 erkannt (22.64)

27. Januar 17:12:31 dhsilabs-Kernel: ISO 9660 Erweiterungen: Microsoft Joliet Level 1

27. Januar 17:12:31 dhsilabs-Kernel: ISOFS: Wechsel zu sekundärem Root

27. Jan 17:12:32 dhsilabs-Kernel: VFS: Festplattenwechsel auf Gerät fd (2,0) erkannt

27. Januar 17:12:32 dhsilabs-Kernel: end_request: I / O-Fehler, dev 02:00 (floppy), Sektor 0

Aus dem vorletzten Eintrag können wir beispielsweise erfahren, dass es am 27. Januar 2002 um 17:12 Uhr einen Medienwechsel im fd-Gerät gab, der uns freundlicherweise vom Systemkernel gemeldet wurde (der "Programm"-Eintrag ist kernel) . Und das Medium (Floppy) erwies sich als beschädigt, wie der folgende Datensatz zeigt - ein Eingabe- / Ausgabefehler (I / O-Fehler, dev 02:00 (Floppy), Sektor 0).

Der syslogd-Daemon startet automatisch beim Systemstart. Das Skript /etc/rc.d/init.d/syslog soll es ausführen. Wie üblich können Sie den Daemon selbst mit folgendem Befehl starten: /etc/rc.d/init.d/syslog start und stop - /etc/rc.d/init.d/syslog stop. Um einen automatischen Download zu gewährleisten, müssen Sie einen symbolischen Link zu dieser Datei erstellen, zum Beispiel:

ls –s /etc/re.d/rc5.d/@S30syslog /etc/rc.d/init.d/syslog.

In diesem Fall stellen Sie sicher, dass der Daemon auf dem fünften Runlevel startet (automatischer Start des X Window). Wenn Sie Linux Mandrake verwenden, können Sie den automatischen Start mit dem Befehl drakxservices aktivieren und deaktivieren. Wenn Sie Linux Red Hat verwenden, aktivieren Sie den Autostart des Daemons mit dem Setup-Konfigurator. Der syslogd-Daemon kann mit den in der Tabelle aufgeführten Optionen gestartet werden. 5.7.

Tisch 5.7 sind nicht alle Daemon-Optionen aufgelistet. Die Bedeutung aller anderen Optionen können Sie dem Hilfesystem entnehmen, indem Sie den Befehl man syslogd eingeben.

Syslogd-Daemon-Optionen Tabelle 5.7

Wenn Sie ein Pipe-Symbol (|) vor dem Dateinamen platzieren, können Sie fifo (first in - first out, zuerst kam - zuerst kam heraus) oder benanntes Rohr als Empfänger für Nachrichten. Bevor Sie syslogd starten (oder neu starten), müssen Sie mit dem Befehl mkfifo ein Fifo erstellen. Manchmal werden Fifos zum Debuggen verwendet.

Terminal und Konsole

Terminal wie /dev/console.

Remote-Maschine

Um Nachrichten an einen anderen Host weiterzuleiten, stellen Sie dem Hostnamen ein @-Symbol voran. Beachten Sie, dass Nachrichten vom empfangenden Host nicht weitergeleitet werden. (damit diese Zuweisung auf dem Client und Server in der Datei funktioniert / usw / Dienstleistungen die Zeile muss geschrieben werden syslog 514 / udp, und UTP-Port 514 ist offen)

eine Liste von Benutzern

Durch Kommas getrennte Liste von Benutzern, die Nachrichten erhalten (wenn der Benutzer angemeldet ist). Dazu gehört oft der Root-Benutzer.

Alle registrierten Benutzer

Um alle registrierten Benutzer mit dem Wandbefehl zu benachrichtigen, verwenden Sie das Sternchen (*)-Symbol.

Ein Beispiel für eine unkomplizierte syslog.conf:

# Alle Kernel-Meldungen an die Konsole ausgeben. # kern.* /dev/console # Alle Protokolle auf Info-Ebene oder höher, außer E-Mail-Nachrichten, und # protokollieren keine Authentifizierungsnachrichten und Cron-Daemon-Nachrichten! * .info; mail.none; authpriv.none; cron.none / var / log / Messages # Nachrichten mit vertraulichen # Authentifizierungsinformationen unabhängig von ihrer Ebene in eine separate Datei schreiben. authpriv.*/var/log/secure # Alle Nachrichten aus dem Mailsystem sollten auch in eine separate Datei geschrieben werden. mail. * - / var / log / maillog # Scheduler-Meldungen in / var / log / cron cron protokollieren * / var / log / cron # Notfallnachrichten sollten sofort empfangen werden # alle Systembenutzer * .emerg * # Nachrichten speichern Nachrichten von crit level und höher in eine separate Datei. uucp, news.crit / var / log / spooler # Bootnachrichten in boot.log local7 speichern * /var/log/boot.log

Wie bei vielen Konfigurationsdateien lautet die Syntax wie folgt:

• Zeilen, die mit # beginnen, und Leerzeilen werden ignoriert.
• Das *-Symbol kann verwendet werden, um alle Kategorien oder alle Prioritäten anzuzeigen.
• Das spezielle Schlüsselwort none gibt an, dass für diese Aktion keine Protokollierung für diese Kategorie durchgeführt werden soll.
• Ein Bindestrich vor dem Dateinamen (wie in diesem Beispiel /var/log/maillog) weist darauf hin, dass das Log nicht nach jedem Eintrag synchronisiert werden soll. Im Falle eines Systemabsturzes können Informationen verloren gehen, aber das Deaktivieren der Synchronisierung verbessert die Leistung.

In der Syntax der Konfigurationsdatei können Sie Prioritäten setzen Unterschrift! um anzuzeigen, dass die Maßnahme nicht angewendet werden soll, ab dieser Stufe und höher... Ebenso kann Priorität eingeräumt werden Zeichen = um anzuzeigen, dass die Regel nur für diese Ebene gilt, oder != um anzuzeigen, dass die Regel für alle Ebenen außer dieser gilt. Nachfolgend sind einige Beispiele aufgeführt (viele weitere Beispiele finden Sie in man syslog.conf):

# Sende alle Kernel-Nachrichten an /var/log/kernel. # Alle kritischen und höheren Nachrichten an den entfernten Sysloger-Rechner und an die Konsole senden # Alle Info-, Hinweis- und Warnmeldungen an /var / log / kernel-info # kern senden * / Var / log / kernel kern.crit @sysloger kern .crit/dev/console kern.info;kern.!err/var/log/kernel-info # Sendet alle Mail-Systemnachrichten außer der Info-Ebene in /var/log/mail. mail. *; mail.! = info / var / log / mail

Ich habe versucht, die Arbeit von syslogd im Diagramm so anschaulich wie möglich darzustellen:

Starten des syslogd-Daemons

Starten des Logging-Daemons werden in der Phase der Systeminitialisierung mittels eines Skripts gestartet /etc/rc.d/init.d/syslog, um Startparameter einzustellen, muss dieses Skript jedoch nicht angepasst werden - ab Version 7.2 werden Startoptionen aus einer separaten Konfigurationsdatei gelesen /etc/sysconfig/syslog (/etc/default/syslogauf Debian).

Hier sind einige möglich Startoptionen für den syslogd-Daemon:

• -a / Ordner / Steckdose- Angabe eines zusätzlichen Listening-Sockets (vergessen Sie nicht, zuerst einen Socket zu erstellen)
• -D- Debug-Modus. In diesem Fall geht der Daemon nicht in den Hintergrund und sendet alle Nachrichten an das aktuelle Terminal;
• -F Konfigurationsdateiname... Gibt den Namen einer alternativen Konfigurationsdatei an, die anstelle der Standarddatei /etc/syslog.conf verwendet werden soll;
• -l Host-Liste- Einstellen einer Liste von Hosts, deren Namen nicht mit Angabe des vollständigen Domänennamens (FQDN - Full Qwalified Domain Name) aufgezeichnet werden sollen;
• -m Minuten- sysklogd, das ohne diese Option gestartet wird, protokolliert alle 20 Minuten Nachrichten der Kategorie Markierung (Zeitstempel). Mit der Option -m können Sie entweder das Intervall zwischen den Markierungen ändern oder die Ausgabe solcher Nachrichten vollständig abbrechen;
• -p Buchse- Setzen eines alternativen UNIX-Sockets (anstatt standardmäßig zuzuhören / dev / log);
• -R- Erlaubnis zum Empfangen von Nachrichten von entfernten Hosts;
• -x- Verbot der Bestimmung des Hostnamens anhand seiner Adresse, um ein Einfrieren zu verhindern, wenn auf demselben Host mit dem DNS-Server gearbeitet wird.
• -v- Version zeigen und Arbeit beenden

Nach dem Start des syslogd-Daemons wird eine Statusdatei generiert /var/lock/subsys/syslog Nulllänge und Datei mit Prozess-ID /var/run/syslogd.pid.

Verwenden des Befehls
kill -SIGNAL `cat/var/run/syslogd.pid`

kann gesendet werden zum syslogd-Daemon eines der folgenden Signale: SEUFZEND- Neustart des Dämons; SIGTERM- Abschluss der Arbeiten; SIGUSR1- Debug-Modus aktivieren / deaktivieren.

Es laufen tatsächlich zwei Logging-Daemons auf dem System - syslogd und klogd... Beide Daemons sind im Paket enthalten sysklod.

Der klogd-Daemon verantwortlich für die Protokollierung von Ereignissen in der Kern des Systems... Die Notwendigkeit eines separaten klogd-Daemons besteht darin, dass der Kernel die Standard-Syslog-Funktion nicht verwenden kann. Tatsache ist, dass die Standard-C-Bibliotheken (einschließlich der Bibliothek, die die Syslog-Funktion enthält) nur für die Verwendung bestimmt sind konventionelle Anwendungen... Da der Kernel auch Protokollierungsfunktionen benötigt, enthält er eigene Bibliotheken, die Anwendungen nicht zur Verfügung stehen. Daher verwendet der Kernel seinen eigenen Mechanismus zur Nachrichtengenerierung.

Der klogd-Daemon wurde entwickelt, um die Verarbeitung dieser Nachrichten zu organisieren. Im Prinzip kann er diese Verarbeitung völlig unabhängig und unabhängig von syslogd durchführen, indem er beispielsweise diese Nachrichten in eine Datei schreibt, aber in den meisten Fällen wird die Standardeinstellung klogd verwendet, die alle Nachrichten vom Kernel an denselben syslogd-Daemon sendet.

Automatische Rotation (Aktualisierung vollständiger Dateien) und Archivierung von Protokollen

Im Laufe der Zeit neigt die Protokolldatei dazu, zu wachsen, insbesondere bei intensiver Arbeit eines Dienstes. Dementsprechend müssen Sie in der Lage sein, die Größe der Protokolle zu steuern. Das geht mit logrotate-Befehle was normalerweise gemacht wird Cron-Daemon... In den folgenden Artikeln werde ich über die Arbeit von cron sprechen. Das Hauptziel logrotate-Befehle besteht darin, die Protokolle regelmäßig zu sichern und neue saubere Protokolle zu erstellen. Mehrere Protokollgenerationen werden aufbewahrt, und wenn das Protokoll der letzten Generation sein Ablaufdatum erreicht, kann es archiviert (komprimiert) werden. Das Ergebnis kann z. B. per Post an den Verantwortlichen für die Archivpflege gesendet werden.

Um die Reihenfolge der Rotation und Archivierung von Protokollen zu bestimmen, verwenden Sie Konfigurationsdatei /etc/logrotate.conf ... Für verschiedene Zeitschriften können Sie eine andere Häufigkeit einstellen, z. B. täglich, wöchentlich oder monatlich, außerdem können Sie die Anzahl der kumulierten Generationen anpassen und festlegen, ob Kopien von Archiven an die für die Archivierung verantwortliche Person gesendet werden und wenn ja, wann. Unten gezeigt Beispieldatei /etc/logrotate.conf:

# die "Standard"-Parameter werden zuerst gesetzt (globale Optionen) # aktualisieren Sie die Log-Dateien wöchentlich wöchentlich # führen Sie ein Archiv der Logs der letzten 4 Wochen rotieren 4 # erstellen Sie eine neue (leere) Datei nach der Rotation (Update) erstellen # unkommentieren wenn Sie möchten, dass die gespeicherten Dateien komprimiert wurden #komprimieren # Rotationseinstellungen aus dem angegebenen Verzeichnis aktivieren include /etc/logrotate.d # wtmp nicht speichern, oder btmp - Die Rotationseinstellungen für die Protokolldaten lauten wie folgt: / var / log / wtmp (missingok monatlich erstellen 0664 root utmp rotieren 1) / var / log / btmp (missingok monatlich erstellen 0664 root utmp rotieren 1) # spezifische Systemprotokolle können unten konfiguriert werden

Globale Optionen stehen am Anfang logrotate.conf-Datei... Sie werden standardmäßig verwendet, wenn an anderer Stelle nichts Genaueres angegeben ist. Im Beispiel erfolgt die Rotation der Stämme wöchentlich und Backups werden aufbewahrt für vier Wochen. Sobald das Journal rotiert wird, wird automatisch ein neues anstelle des alten Journals erstellt. Logrotate.conf-Datei kann Spezifikationen aus anderen Dateien enthalten. Es enthält also alle Dateien aus dem Verzeichnis /etc/logrotate.d.

Dieses Beispiel enthält auch spezielle Regeln für /var/log/wtmp und /var/log/btmp(Speicherung von Informationen über erfolgreiche und fehlgeschlagene Anmeldeversuche), die monatlich rotiert werden. Wenn die Dateien fehlen, wird keine Fehlermeldung angezeigt. Es wird eine neue Datei erstellt und nur ein Backup gespeichert.

In diesem Beispiel wird das Backup gelöscht, wenn es die neueste Generation erreicht, da nicht definiert ist, was damit geschehen soll.

Log-Backups können auch generiert werden, wenn Protokolle eine bestimmte Größe erreichen, und Skripts können aus Befehlssätzen generiert werden, die vor oder nach einer Sicherungsoperation ausgeführt werden. Beispiel:

/ var / log / Nachrichten (5 E-Mails drehen [E-Mail geschützt] Größe 100k postrotate / usr / bin / killall -HUP syslogd Endscript)

In diesem Beispiel ist die Drehung / var / log / Nachrichten erzeugt, wenn es 100 KB erreicht. Es werden fünf Backups gesammelt, und wenn das älteste Backup abläuft, wird es per E-Mail an . gesendet [E-Mail geschützt] Das Befehlswort postrotate ermöglicht es einem Skript, den syslogd-Daemon nach Abschluss der Rotation durch Senden eines HUP-Signals neu zu starten. Das Befehlswort endscript ist erforderlich, um das Skript zu beenden und auch, wenn das Prerotate-Skript verfügbar ist. Weitere Informationen finden Sie auf den Manpages von logrotate.

Optionen in der Konfigurationsdatei angegeben logrotate.conf:

• Kompresse| nocompress(ältere Versionen sind mit gzip komprimiert oder nicht komprimiert)
• komprimierencmd(setzt das Komprimierungsprogramm, standardmäßig gzip)
• dekomprimierencmd(setzt das Dekompressionsprogramm standardmäßig - ungzip)
• komprimieren(setzt das Suffix für komprimierte Dateien)
• Komprimierungsoptionen(setzt die Parameter des Komprimierungsprogramms; die Voreinstellung ist "-9", also die maximale Komprimierung für gzip)
• kopierentruncate| nocopytruncate(normalerweise wird die alte Version umbenannt und eine neue Version des Protokolls erstellt; wenn dieser Parameter gesetzt ist, kopiert logrotate das Protokoll in eine neue Datei und schneidet dann die alte ab; wird verwendet, wenn das Programm, das das Protokoll erstellt, es nicht schließen kann; Aufzeichnungen zwischen Kopieren und Kürzen gemacht werden, gehen verloren ; aber hilft es, wenn das Programm, das das Protokoll erstellt, anstelle des Append-Modus einfach mit einem internen Zeiger in eine Datei schreibt?)
• schaffen[Zugriffsrechtebesitzergruppe] | nocreate(unmittelbar nach dem Umbenennen der alten Version des Journals und vor dem Aufruf von postrotate wird ein neues Journal mit den angegebenen Attributen erstellt - Berechtigungen werden in Oktal gesetzt, wie in chmod.2; wenn keine Attribute angegeben sind, werden sie aus dem alten übernommen Tagebuch)
• Täglich(Versionswechsel in der Serie erfolgt täglich)
• Verzögerungskomprimierung| Nodelaycompress(einige Programme schließen das Protokoll nicht sofort, in diesem Fall sollte die Komprimierung auf den nächsten Zyklus verschoben werden)
• FehlerEmail(an wen Fehlerberichte gesendet werden sollen)
• VerlängerungSuffix(legt das Suffix, das den Dateinamen beim Rotieren hinzugefügt wird, vor dem Komprimierungssuffix)
• wenn leer| benachrichtigen(Versionen ändern, auch wenn die Datei leer ist; dies ist die Standardeinstellung)
• enthaltenDateiname| Verzeichnisname (textuell eine Datei oder alle Dateien aus dem angegebenen Verzeichnis ersetzen; Unterverzeichnisse, spezielle Dateien und Dateien mit Suffixen aus der Ausschlussliste sind nicht enthalten; können nicht innerhalb eines Abschnitts verwendet werden)
• E-Maildie Anschrift| nomail(wenn ein Versionswechsel das Löschen des alten Logs erforderlich macht, dann an die angegebene Adresse senden)
• mailfirst(senden Sie nicht die gelöschte Version des Journals, sondern die erste)
• maillast(Sende die gelöschte Version des Protokolls; dies ist die Standardeinstellung)
• fehltok| nomissingok(keine Fehlermeldungen senden, wenn das Protokoll fehlt)
• monatlich(Versionswechsel erfolgt monatlich)
• altdirVerzeichnis| noolddir(Bei einer Versionsänderung wird das Protokoll in das angegebene Verzeichnis verschoben; sollte sich auf demselben physischen Gerät befinden)
• nachdrehen(alle weiteren Zeilen bis zur Endscript-Zeile werden nach dem Versionswechsel als Shell-Befehle ausgeführt)
• vordrehen(alle weiteren Zeilen bis zur Endscript-Zeile werden vor dem Versionsänderungsprozess ausgeführt)
• drehenNummer(wie viele alte Versionen sollen behalten werden; wenn 0, dann keine)
• GrößeByte(Versionswechsel erfolgt, wenn die Größe des Protokolls die angegebene Anzahl überschritten hat; Sie können die Suffixe "k" - Kilobyte - und "M" - Megabyte verwenden)
• Sharedscripts| nosharedscripts(Führen Sie die Befehle prerotate und postrotate nur einmal für alle im Abschnitt beschriebenen Dateien aus)
• tabuext[+] Suffix-Liste(Angabe einer Liste von Suffix-Ausschlüssen für include; wenn das Pluszeichen angegeben ist, dann Addition, sonst Ersetzung; standardmäßig: .rpmorig, .rpmsave, .rpmnew, ", v", .swp und "~")
• wöchentlich(Versionswechsel erfolgt wöchentlich)

Durchsuchen und Überwachen von Protokollen

Log-Einträge enthalten normalerweise einen Zeitstempel, den Hostnamen, auf dem der beschriebene Prozess läuft, und den Prozessnamen. Protokolle anzeigen Sie können beispielsweise ein Paginierungsprogramm verwenden, weniger, können Sie mit dem Befehl nach bestimmten Einträgen (z. B. Kernel-Nachrichten eines bestimmten Daemons) suchen grep:

# weniger / var / log / Nachrichten # grep "ppp" / var / log / Nachrichten | tail 17. Dezember 16:34:25 proxy pppd: Verbindung beendet. 17. Dezember 16:34:25 proxy pppd: Beenden. 17. Dez. 16:35:57 proxy pppd: LCP von Peer beendet (^ P] kV ^ @

Der Computer funktioniert möglicherweise nicht die ganze Zeit und schaltet sich beispielsweise nachts aus. Daher werden in /var/log/messages vom Computerstart bis zum Herunterfahren zyklisch Aufzeichnungen gespeichert, dies erkennen Sie an den Meldungen:

17. Dez. 08:32:56 Syslog-Server syslogd 1.4-0: Neustart. 17. Dez. 08:32:56 Syslog-Server syslog: syslogd erfolgreich 17. Dez. 08:32:56 Syslog-Server Kernel: klogd 1.4-0, log source = / proc / kmsg gestartet. 17. Dez. 08:32:56 Syslog-Server Syslog: Start von klogd erfolgreich

17. Dez. 08:32:56 Syslog-Server-Kernel: Kernel-Befehlszeile: auto BOOT_IMAGE = linux ro root = 303 BOOT_FILE = / boot / vmlinuz-2.4.2-2 17. Dez. 08:32:56 Syslog-Server-Kernel: Speicher: 125652k / 130560k verfügbar (1365k Kernelcode, 4200k reserviert, 92k Daten, 236k Init, 0k Highmem) 17. Dez 08:32:56 Syslog-Server Kernel: CPU: Intel (R) Pentium (R) 4 CPU 1.60GHz stepping 02

Außerdem finden Sie in dieser Datei Informationen zum Plattenspeicher (einschließlich Informationen zur Plattengeometrie, Partitionsstruktur und verwendeten Interrupts), Informationen zu Peripheriegeräten, zum Starten einzelner Dienste und Dienste, Informationen zum Verbinden von Dateisystemen und Meldungen zur Benutzeranmeldung sowie Fehlermeldungen.

Manchmal kann es notwendig sein Überwachung von Systemprotokollen um nach aktuellen Ereignissen zu suchen. Sie können beispielsweise versuchen, ein seltenes Ereignis in dem Moment zu erfassen, in dem es passiert ist. In diesem Fall können Sie den Befehl Schwanz mit Option -F um den Inhalt des Syslogs zu verfolgen. Beispiel:

# tail -f / var / log / Nachrichten | grep syslog-server 17.12.16:46:09 syslog-server pppd: pptpd-logwtmp.so ip-up ppp0 maikop 94.77.0.150 17.12. 16:46:09 syslog-server pppd: Skript / etc / ppp / ip-up beendet (pid 12552), Status = 0x0 17. Dez 16:46:49 syslog-server pptpd: STRG: Client 85.175.197.65 Kontrollverbindung gestartet 17. Dez. 16:46:49 syslog-server pptpd: STRG: Aufruf starten (startet pppd, GRE öffnen) 17. Dez. 16:46:49 syslog-server pppd: Plugin /usr/lib/pptpd/pptpd-logwtmp.so geladen.

Neben den in /etc/syslog.conf angegebenen Protokolldateien gibt es noch weitere Dateien, beispielsweise eine Datei, die Informationen über den Systemstartvorgang vor dem Start von syslogd speichert, sowie Dateien, die ein Binärformat haben und Informationen speichern über die Benutzeranmeldung des letzten Eintrags, alle erfolgreichen Benutzeranmeldungen bzw. alle fehlgeschlagenen Benutzeranmeldungen. Außerdem kann das Verzeichnis /var/log/ die Protokolldateien solcher Daemons wie eines Webservers oder eines Proxyservers enthalten. Das Format dieser Dateien ähnelt den syslogd-Protokollen.

Abschließend möchte ich betonen, dass dieses Protokoll nicht sehr sicher ist, tk. syslog enthält keine Schutzmaßnahmen gegen Message-Spoofing. Schlimmer noch, die Verwendung von UDP ermöglicht es Angreifern, Nachrichten im Namen eines beliebigen Hosts zu senden. Ihr lokales Netzwerk sollte darauf abgeschirmt werden, Pakete mit gefälschten lokalen Adressen zu empfangen (obwohl dies Sie nicht daran hindert, gefälschte Nachrichten aus dem Inneren des lokalen Netzwerks zu senden) und Pakete von außen auf Port 514 / udp zu empfangen. Es gibt bekannte Fälle von Festplattenüberlauf mit falschen Meldungen.

Das Syslog-Protokoll und UDP bieten keine garantierte Zustellung (Nachrichten können während einer Netzwerküberlastung verloren gehen oder abgefangen werden, beschädigte Nachrichten werden ohne Vorwarnung gelöscht), die korrekte Zustellungsreihenfolge (die Nachricht über das Ende des Prozesses kann vor der Nachricht über seinen Start kommen ), vorrangige Zustellung.

Nachrichten werden nicht vertraulich behandelt, da sie im Klartext übertragen werden.

Wenn Sie beim Konfigurieren des Nachrichtengenerators die falsche Adresse des Kollektors oder Relais angeben, werden keine Fehlermeldungen angezeigt - die Nachrichten werden gelöscht (oder in das Protokoll einer anderen Person geschrieben).

Mehrere Projekte wurden vorgeschlagen, um das Syslog-Protokoll zu verbessern. RFC 3195 schlägt beispielsweise ein TCP-basiertes Protokollierungssystem (syslog-conn) vor, um sicherzustellen, dass Nachrichten in der richtigen Reihenfolge zugestellt werden. Das syslog-sign-Projekt schlägt vor, Authentifizierung, Sortierung, Nachrichtenintegrität und Erkennung fehlender Nachrichten bereitzustellen, indem spezielle Nachrichten generiert werden, die eine digitale Signatur des Blocks früherer Nachrichten enthalten, während das Standard-Syslog-Protokoll und -Format beibehalten und UDP verwendet wird.

Fassen wir zusammen:

Linux hat einen einzigen Daemon, der für die Protokollierung von Ereignissen auf dem lokalen System und auf Remote-Systemen verantwortlich ist. Alle Ereignisse werden vom /dev/log-Socket, UDP-Port - 514, sowie vom "Helfer" - dem klogd-Daemon, der Nachrichten vom Kernel sendet, gesammelt. Alle gesammelten Nachrichten werden vom syslogd-Daemon durch die Regeln in der Datei /etc/syslog.conf gefiltert und gemäß den Regeln an die entsprechenden Ziele verteilt. Protokolldateien werden regelmäßig „gekürzt“. Die Häufigkeit wird durch die Datei logrotate.conf und den Befehl logrotate bestimmt, der vom System-Scheduler - cron - ausgeführt wird.

Das ist alles für heute. Ich hoffe, ich habe alles so klar wie möglich beschrieben. Im Laufe der Zeit werde ich den Artikel ergänzen!

Grüße, Mc.Sim!