Das Speichern und Verwalten von Webserver-Zugriffslogs ist trivial: Man nutzt einfach die Directiven CustomLog und Errorlog im Apache und alles ist erledigt. Als ganz schlauer Admin mit SLES11 ruft man vielleicht noch eben ein
zypper -install webalizer
auf und schon hat man auch noch die Webstatistik impetto.
Gut. Das klappt wirklich so. Nämlich dann, wenn man auf einer Linuxkiste arbeitet und man vielleicht ein paar wenige, selbst verwaltete Webauftritte hat, die auch nicht so hohe Zugriffszahlen aufweisen…
Schluss mit dem Kinderkram!
Meine Ausgangslage sieht aber dann doch etwas anderes aus: Ich betreibe auf 5 Webservern über 600 Webauftritte von einigen Hundert verschiedener Kunden. Diese Webauftritte bestreiten das gesamte Spektrum von einfach bis komplex: Es gibt Webauftritte aus einer handvoll statischer Webseiten genauso wie Webauftritte die mit eigenen CMS- und Redaktionssystemen betrieben werden. (Dabei auch Performancefresser wie Typo3 und WordPress). Auch bei den Webauftritte die nicht auf Basis eines CMS oder Redaktionssystems funktionieren, verwendet die überwiegende Mehrzahl interaktive Skripten (PHP, Perl, Pyton, …).
Einige der Webauftritte verursachen mehrere Hundert GigabyteTraffik pro Monat. Bei ein paar dieser Webauftritte sind die Accesslogfiles pro Monat stets größer als 2 GB. Alles zusammen verzeichnet die Statistik etwa 1 Terabyte Traffik und 37 Millionen Zugriffe im Monat. Und ja, das ganze läuft wirklich auf nur 5 Servern (und zwar keine teuren Spezialserver, sondern inzwischen ältern Sunserver vom Typ SunFire T2000).
Das Ziel
Durch einen Load-Balancer soll ein Webauftritt von einem der 5 Server bedient werden. Dabei ist selbstverständlich vorher nicht klar welcher Webauftritt durch welchen Server behandelt wird. Jeder Server kann den Request annehmen und bearbeiten. Und beim nächsten Aufruf kann es der nächste Server sein.
Vom Filesystem her arbeiten alle auf denselben Bereich. (Wie das Fileystem redundant organisiert wird ist eine andere Geschichte).
Da jeder Webserver die Zugriffe bearbeiten kann, ist eine lokale Speicherung der Zugriffslogs ungeschickt. Sowohl ein Webmaster einer Domain der etwas nachprüfen will, als auch die automatisierte Auswertung mittels eines Statistikproggrammes wie Webalizer verlangen eine Datei, die alle Zugriffe auf den Webauftritte enthalten. Niemand will auf jedem einzelnen Server nachschauen müssen ob und was da etwa noch steht.
(Ganz abgesehen davon, daß meine Kunden gar keine Zugriffsberechtigung auf die Webserver bekommen).
Ziel ist also: Jeder Webauftritt braucht eine eigene Zugriffslog, die alle Zugriffe verzeichnet, egal welcher Webserver konkret den Request bearbeitete.
Und unter Umständen wird nicht nur die Zugriffslog benötigt, sondern auch die Errorlog.
Weitere Anforderungen:
Die Server sollen nicht auf eine technologische Basis beschränkt sein. Neben den jetzigen 5 Sun-Servern sollen auch andere Server mit anderen Betriebssystemen (SLES10, SLES11, Ubuntu, u.a.) zentral verwaltete Logdateien erstellen.
In Hinblick auf Bedenken des Datenschutzes hinsichtlich der Personenbeziehbarkeit von IP-Adressen sollten diese Rechneradressen anonymisiert werden, soweit dies möglich ist.
Umsetzung
Die Umsetzung erfolgt mit Hilfe eines zentralen Loghosts. Dieser nimmt alle Logmeldungen mit syslog-ng entgegen und schreibt sie in die Zieldateien. Die Webserver spielen dabei die Rolle der “Clients”. Diese senden die Nachrichten über syslog oder syslog-ng an den Loghost.
Bevor ich auf die Apache-Konfiguration eingehe, zunächst zur Konfiguration der Syslog-Dämonen.
Die Syslog-Clients: Die Webserver
Je nachdem auf welchem Betriebssystem gearbeitet wird, steht auf unseren Server entweder syslog oder syslog-ng zur Verfügung. Für den Loghost macht es keinen Unterschied, welche Software die Clients nutzen.
Clients mit syslog
Clients mit dem normalen Syslog brauchen folgende Zeilen in der Konfiguration syslog.conf:
local0.* @LOGHOST.HOSTNAME
local1.* @LOGHOST.HOSTNAME
local2.* @LOGHOST.HOSTNAME
local3.* @LOGHOST.HOSTNAME
Die Facilities local0, local2 werden verwendet für Errorlogs, während die Facilities local1 und local3 für Access-Logs genutzt werden.
Warum wir jeweils zwei Facilities verwenden erkläre ich weiter unten.
Clients mit syslog-ng
Wir modifizieren die Default syslog.conf um folgende Einträge:
Modifizierter Options-Bereich oben:
#
# Global options.
options {
long_hostnames(off);
time_reopen(10);
time_reap(360);
log_fifo_size(0);
sync(0);
perm(0640);
stats(3600);
log_msg_size(32768);
use_dns(no);
};
Innerhalb der üblichen Filter:
filter f_apache { facility(local0, local1,local2,local3)
and level(info); };
filter f_local { facility(local0, local1, local2, local3,
local4, local5, local6, local7) and
not filter(f_apache);
};
Und neu am Ende:
destination webserver { tcp("IP.ADRESSE.LOGHOST"); };
log { source(src); filter(f_apache); destination(webserver); };
Der Loghost
Mit folgender Konfiguration des syslog-ng’s wird dafür gesorgt, dass
- Access-Logdateien auf taeglicher Basis
- Errorlog-Dateien auf monatlicher Basis
entstehen. Die Dateien werden dabei in ein Logverzeichnis ( /proj.stand/log/access und /proj.stand/log/errors/ ) geschrieben. Im Falle der Errorlogs in ein Verzeichnis pro Monat im Falle der Accesslogs in ein Verzeichnis $Monat/$Tag.
Ein Aufräumskript sorgt dafuer, dass die Logdateien nach einer gewissen Zeit gelöscht werden.
Server-Konfiguration in /etc/syslog-ng/syslog.conf:
source net {
tcp(ip("0.0.0.0") port(514));
udp(ip("0.0.0.0") port(514));
};
Hier definieren wir die Quelle: Wir betrachten Syslogmessages die sowohl über UDP als auch über TCP kommen.
template t_accesslog {
template("$MSGONLY\n"); template_escape(no);
};
template t_errorlog {
template("$HOST $MSGONLY\n"); template_escape(no);
};
template t_hostactivity {
template("$STAMP\t$HOST\t$PROGRAM\t$FACILITY\n"); template_escape(no);
};
Diese drei Anweisungen definierten das Format der Messages wie sie gespeichert werden sollen.
destination d_apacheerror {
file("/proj.stand/logs/errors/$MONTH/$PROGRAM.log" template(t_errorlog));
};
destination d_apacheaccess {
file("/proj.stand/logs/access/$MONTH/$DAY/$PROGRAM.log" template(t_accesslog));
};
destination d_sn_apacheerror {
program("/proj.stand/bin/dest-error-filter.pl $MONTH" template(t_errorlog));
};
destination d_sn_apacheaccess {
program("/proj.stand/bin/dest-access-filter.pl $MONTH $DAY" template(t_accesslog));
};
destination d_hostactivity {
file("/proj.stand/logs/hostactivity/activity-$YEAR-$MONTH-$DAY.log" template(t_hostactivity));
};
destination netaccess {
file("/proj.stand/logs/unknown/$FULLHOST.log");
};
Die Destinations definieren wohin wir Zugriffe speichern wollen und welches Format diese dabei haben.
Zu beachten ist auch hier, daß ich im Falle der Error- und der Accesslogs jeweils zwei Varianten betrachte: destination d_apacheaccess vs. destination d_sn_apacheaccess und destination d_apacheerror vs. destination d_sn_apacheerror.
Im ersten Fall speichere ich die Logmessages direkt in eine Datei, in zweiten Fall sende ich die Messages an ein Programm. (Siehe weiter unten).
Die beiden letzten Destinations dienen nur noch zu Kontrollzwecken. Mit der Destination d_hostactivity{}, welche Server konkret Apache-Anfragen senden und also aktiv sind.
Damit kann ich beim Einsatz des Webclusters feststellen, ob einzelne Server überhaupt aktiv sind und wie häufig sie es in Relation zu anderen Servern sind. (Dadurch kann ich wiederrum Rueckschlüsse auf das LoadBalancing fuehren.)
Die Destination netaccess nutz ich dagegen um solche Hosts abzufangen, die Nachrichten an meinen Loghost senden, aber nicht in dem erlaubten Subnetz IP.WEBSERVER.SUBNETZ.0 sind.
Nun, da ich weiss, wohin gespeichert wird, muss ich noch die Filter definieren:
filter f_apacheerror {
facility(local0) and
level(info) and
netmask(IP.WEBSERVER.SUBNETZ.0/24);
};
filter f_apacheaccess {
facility(local1) and
level(info) and
netmask(IP.WEBSERVER.SUBNETZ.0/24);
};
filter f_sn_apacheerror {
facility(local2) and
level(info) and
netmask(IP.WEBSERVER.SUBNETZ.0/24);
};
filter f_sn_apacheaccess {
facility(local3) and
level(info) and
netmask(IP.WEBSERVER.SUBNETZ.0/24);
};
Die Filter definieren Bedingungen die in der folgende Verarbeitung des Syslogstreams zum Zuge kommen.
IP.WEBSERVER.SUBNETZ.0 enthält natürlich die IP-Adresse des Subnetzes in dem die eigenen Server stehen.
Wenn die jeweilige Filterbedingung erfüllt ist, dann wird die Messages an die Destination weitergeleitet:
log {
source(net);
filter(f_apacheerror);
destination(d_apacheerror);
destination(d_hostactivity);
flags(final);
};
log {
source(net);
filter(f_sn_apacheerror);
destination(d_sn_apacheerror);
destination(d_hostactivity);
flags(final);
};
log {
source(net);
filter(f_sn_apacheaccess);
destination(d_sn_apacheaccess);
destination(d_hostactivity);
flags(final);
};
log {
source(net);
filter(f_apacheaccess);
destination(d_apacheaccess);
destination(d_hostactivity);
flags(final);
};
log {
source(net);
destination(netaccess);
};
Damit ist die Syslog-Konfiguration für den Loghost vollständig.
(Bitte abernoch weiterlesen – bevor wir den syslog-ng restarten brauchen wir noch 2 Perlskripten. Diese hab ich weiter unten beschrieben).
Zur Erklärung der Facilities: Wie oben bereits geschrieben, werden die Facilities local0, local2 verwendet für Errorlogs, während die Facilities local1 und local3 für Access-Logs genutzt werden.
Warum aber die umständliche Trennung in jeweils zwei Paare mit weiteren Facilities? Normalerweise sollten doch local0 und local1 ausreichen. Denn so schreiben es ja schliesslich auch viele andere Dokumentation im Web zum Thema.
Die Antwort wird ersichtlich, wenn man an das Anfangsszenario denkt und dieses mal in den Apache-Webserver umsetzt. Wenn wir normalerweise für jeden Virtual Host eine eigene Acesslog und eine eigene Errorlog definieren wollen, tun wir dies wie folgt:
...
Errorlog "|/usr/bin/apache-error-logger.pl www.meine-domainname.tld"
TransferLog "|/usr/bin/apache-access-logger.pl www.meine-domainname.tld"
...
Was passiert nun, wenn wir dies in einem Apache eintragen, der über 600 Webauftritte verwaltet?
Die Antwort: Beim Start des Apaches werden nun nur für das Logging 1200 Prozesse gestartet, die während der Laufzeit des Apaches mitlaufen!
Damit ist klar, daß man diese Variante für richtiges MassVirtualHosting vergessen kann.
Wir brauchen dort eine bessere, performanceschonendere Lösung.
Wobei wir aber trotzdem diese Variante für “kleine” Server mit nur einem oder wenigen Webauftriotten trotzdem aktiviert lassen wollen.
Die Lösung: Wir definieren die Facilities local0 und local1 dafür auf diese Weise Logfiles zu sichern.
Für Apaches mit vielen Virtual Hosts, die auch alle geloggt werden sollen dagegen, nutzen wir local2 und local3 und machen die Log-Directiven in der Apache-Konfiguration anders.
Die Apache-Konfigurationen
Apache Konfiguration für Webserver mit Logdefinition pro VHOST (wenige VHOSTs)
Die Logs werden in den einzelnen VHOST-Eintraegen definiert.
...
Errorlog "|/usr/bin/apache-error-logger.pl www.meine-domainname.tld"
TransferLog "|/usr/bin/apache-access-logger.pl www.meine-domainname.tld"
...
Vorher wird das Logformat wie folgt global festgelegt:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
Durch die Einträge werden beim Start des Apache-Servers zwei Prozesse mit den Skripten /usr/bin/apache-access-logger.pl und /usr/bin/apache-error-logger.pl aufgerufen.
Dabei handelt es sich um zwei simple Perlskripten.
apache-access-logger.pl
#!/usr/bin/perl
use Sys::Syslog;
$SERVER_NAME = shift || 'www';
$PRIORITY = 'info';
$FACILITY = 'local1';
openlog($SERVER_NAME, 'ndelay', $FACILITY);
while() {
chomp;
if ($_ =~ /^(\d+\.\d+\.\d+\.\d+) /i) {
$_ =~ s/^(\d+\.\d+\.\d+)\.\d+ /$1.0 /gi;
# Anonymisieren der IP-Adresse.
# Nur die letzte Ziffer wird weggemacht
} else {
$_ =~ s/^[a-z0-9\-\.]*\.([a-z0-9\-]+)\.([a-z0-9\-]+) /$1.$2 /gi;
# Anonymisieren des Hostnamens
# nur die letzten beiden Bestandteile werden uebernommen
}
syslog($PRIORITY,$_);
}
closelog;
Es gibt eine rege Diskussion darüber ob die IP-Adresse, bzw. der Rechnername im Sinne des Datenschutzes erfasst werden darf oder nicht. Diese Diskussion soll jedoch hier nicht weiter ausgefuehrt werden.
Das obige Skript kürzt im Falle einer IP-Adresse diese ab dadurch das die letzte Ziffer auf 0 gesetzt wird. Falls dies weitergehenden Fordungen nicht genüge tut, kann die Regular Expression auch wie folgt geaendert werden:
$_ =~ s/^(\d+\.\d+)\.\d+\.\d+ /$1.0.0 /gi;
(Vgl: auch: ZENDAS: Erstellung anonymisierter Apache Logfiles)
Im Falle dass ein Rechnername angegeben ist, wird diese bis auf die Subdomain gekürzt.
apache-error-logger.pl
#!/usr/bin/perl
use Sys::Syslog;
$SERVER_NAME = shift || 'www';
$PRIORITY = 'info';
$FACILITY = 'local0';
# Sys::Syslog::setlogsock('unix');
openlog($SERVER_NAME, 'ndelay', $FACILITY);
while() {
chomp;
syslog($PRIORITY,$_);
}
closelog;
Anmerkung: Im Falle von Fehlern anonymisiere ich die Rechneradressen nicht! Denn Fehler sollten garnicht auftreten. Wenn diese auftreten, ist es notwendig alle Daten der Requests zu haben. Auch die vollständige IP-Adresse.
Apache Konfiguration für Webserver mit globaler Logdefinition (viele VHOSTs)
In dieser Variante enthalten die einzelnen VHOSTs keine eigene Log-Directiven. (Man kann dies aber durchaus trotzdem tun und somit beide Verfahren mischen. Dies macht zum Beispiel dann Sinn, wenn man fuer einzelne VHOSTS eine eigene Errorlog haben moechte).
Der Aufruf im Apache erfolgt über die globale Definition in solcher Form:
ErrorLog "|/usr/bin/apache-vhosterror-logger.pl MEIN_HOSTNAME"
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
CustomLog "|/usr/bin/apache-vhostaccess-logger.pl MEIN_HOSTNAME" vhost_combined
Auch hier hab ich zwei Perlskripten erstellt. Diese unterschieden sich von den beiden obigen nur dadurch, daß ich hier auf die Anonymisierung verzichte und andere Facilities angebe. (Die Anonymisierung erfolgt auf der Loghost-Seite, damit ich auf der Seite der Webserver etwas Performance spare. Selbst wenn es nur Mikrosekunden sind… ).
apache-vhostaccess-logger.pl
#!/usr/bin/perl
use Sys::Syslog;
$SERVER_NAME = shift || 'www';
$PRIORITY = 'info';
$FACILITY = 'local3';
openlog($SERVER_NAME, 'ndelay', $FACILITY);
while() {
chomp;
syslog($PRIORITY,$_);
}
closelog;
apache-vhosterror-logger.pl
#!/usr/bin/perl
use Sys::Syslog;
$SERVER_NAME = shift || 'www';
$PRIORITY = 'info';
$FACILITY = 'local2';
openlog($SERVER_NAME, 'ndelay', $FACILITY);
while() {
chomp;
syslog($PRIORITY,$_);
}
closelog;
Filter-Skripte auf Loghost für Apache Mass-VHosting
Auf dem LogHost müssen nun noch die Filterskripte definiert werden, die alle Nachrichten der Webserver erhalten.
Syslog-ng kann leider keine Ergebnisse von RegExps in dessen Filtern als Variable weiterverarbeiten. Deswegen wird dann als “Destination Driver” program() verwendet: “program() Forks and launches the specified program, and sends messages to its standard input.”
Diese Nachrichten enthalten im Falle der Accesslogs Dank der LogFormat-Angabe in der ersten Spalte die Angabe des Namen des Webauftritts.
Danach wird gefiltert.
dest-access-filter.pl
#!/usr/bin/perl
use IO::Handle;
$TARGET_DIR = "/proj.stand/logs/access/";
$MONTH = shift;
$DAY = shift;
my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime(time);
$mon++;
$MONTH = $mon if (not $MONTH);
$DAY = $mday if (not $DAY);
$SIG{ALRM} = sub { &doTimeout; };
alarm(60*60);
$daydir = $TARGET_DIR.$MONTH."/".$DAY;
$monthdir = $TARGET_DIR.$MONTH;
if (not (-d $monthdir)) {
mkdir($monthdir);
}
if (not (-d $daydir)) {
mkdir($daydir);
}
while() {
chomp;
# Bei Servern auf Basis von SUN wird u.a. durch die MSGId eine Spalte vor den
# Syslogeinztragen gestellt.
# Diese kann hier weggefiltert werden:
$_ =~ s/^\[ID ([^\]]*)\] //gi;
($vhost,$userhost,$rest) = split(/\s+/,$_,3);
if ($userhost =~ /^(\d+\.\d+\.\d+\.\d+)$/i) {
$userhost =~ s/^(\d+\.\d+\.\d+)\.\d+$/$1.0/gi;
# Anonymisieren der IP-Adresse.
# Nur die letzte Ziffer wird weggemacht
} else {
$userhost =~ s/^[a-z0-9\-\.]*\.([a-z0-9\-]+)\.([a-z0-9\-]+)$/$1.$2/gi;
# Anonymisieren des Hostnamens
# nur die letzten beiden Bestandteile werden uebernommen
}
$vhost = "unknown" if (not $vhost);
$target = $daydir."/".$vhost.".log";
open(my ($fh),">>$target");
$fh->autoflush(1);
print $fh "$userhost $rest\n";
$mday = (localtime(time))[3];
if ($mday != $DAY) {
exit;
}
}
exit;
sub doTimeout {
exit;
}
Zu Erwähnen sind die Timeouts und die Prüfung auf den Tageswechsel. Ebenso wie der Apache startet Syslog den Filterprozess einmal mit den beim Start geltenden Argumenten.
Wenn der Prozess nicht gestoppt wird, läuft dieser Prozess immer weiter. Auch über den Tageswechsel hinaus. Logmeldungen werden dann also ggf. in die falsche Datei gespeichert. Aus diesem Grund, und um zu viele offene Filehandles im Memory zu vermeiden, lass ich das Skript in regelmässigen Abständen und zum Tageswechsel sich selbst beenden. Syslog-NG wird dann den Prozess selbstständig neu starten. Dann aber mit jeweils aktuellen Parametern.
dest-error-filter.pl
#!/usr/bin/perl
use IO::Handle;
$TARGET_DIR = "/proj.stand/logs/errors/";
$MONTH = shift;
my $mon = (localtime(time))[4];
$mon++;
$MONTH = $mon if (not $MONTH);
$SIG{ALRM} = sub { &doTimeout; };
alarm(60*60);
# Das Skript soll sich einmal pro Stunde neu starten
$monthdir = $TARGET_DIR.$MONTH;
if (not (-d $monthdir)) {
mkdir($monthdir);
}
while() {
chomp;
$orig = $_;
if ($_ !~ /^\[/i) {
# Quellhost ist vor der Zeit angegeben
# Siehe Einstellung in syslog-ng: template()
($quellhost,$rest) = split(/\s+/,$_,2);
} else {
$rest = $_;
$quellhost = "unknown";
}
if ($orig =~ /\(server ([a-z0-9\-\.]+):*(\d*)\)/i) {
$vhost = $1;
} else {
$vhost = "";
}
if ($vhost) {
$target = $monthdir."/".$vhost.".log";
} else {
$target = $monthdir."/".$quellhost.".log";
}
local $fh;
if (not $tlist->{$target}->{'fh'}) {
open($fh,">>$target");
$fh->autoflush(1);
$tlist->{$target}->{'fh'} = $fh;
} else {
$fh = $tlist->{$target}->{'fh'};
}
if ($SHOW_SOURCEHOST) {
print $fh "$orig\n";
} else {
print $fh "$rest\n";
}
$mday = (localtime(time))[3];
if ($mday != $DAY) {
exit;
}
}
exit;
sub doTimeout { exit; }
Wie auch das Skript für die Accesslogs enthält der Filter für die Errorlogs ein Timeout und ein Exit bei dem Tageswechsel.
(Ich verwalte in diesem Skript die Dateihandles etwas anders als bei den Accesslogs, dies tut aber nichts zur Sache und hat als Grund nur das ich an der Stelle später besser diverse Debugausgaben einbauen kann).
Hinweise
Errorlog bei zentralen Logfiles
- Der Filter für globale Errorslogs filtert den $vhost-Namen optional nicht aus dem Logstream aus, da bei den Einsatz mit Load-Balancern es wichtig sein kann zu wissen, auf welchem Server ein Fehler passierte. Bei Access-Logs dagegen ist dies nicht notwendig.
- Bei globalen Errorlogs ist die Syntax etwas anders als bei Errorlogs in Virtual Hosts. Eine LogFormat-Directive für Errorlogs gibt es nicht. Aus der Manual:
“It is not possible to customize the error log by adding or removing information. However, error log entries dealing with particular requests have corresponding entries in the access log. For example, the above example entry corresponds to an access log entry with status code 403. Since it is possible to customize the access log, you can obtain more information about error conditions using that log file.
”
Im Falle von Verbindungen die über einen VHOST kommen der SSL verarbeitet, wird die Anfrage jedoch um den Servernamen ergänzt. Diese können wir nutzen, um doch noch wenigstens in diesen Fällen zu filtern.
Beispiel eines Errorlog-Streams der beim Skript ankommt:
AA.BB.CC.DD [Tue Dec 15 16:58:16 2009] [info] Client requested a 'session-resume' but we have no such session.
AA.BB.CC.DD [Tue Dec 15 16:58:16 2009] [info] Initial (No.1) HTTPS request received for child 7 (server www.mein-host.tld:443)
AA.BB.CC.DD[Tue Dec 15 16:58:16 2009] [info] Subsequent (No.2) HTTPS request received for child 7 (server www.mein-host.tld:443)
AA.BB.CC.DD [Tue Dec 15 16:58:31 2009] [info] [client AA.BB.CC.FF] (70007)The timeout specified has expired: SSL input filter read failed.
AA.BB.CC.DD [Tue Dec 15 16:58:31 2009] [info] [client AA.BB.CC.FF] Connection closed to child 7 with standard shutdown (server www.mein-host.tld:443)
Clients auf SLES
Auf SLES10 erfolgt die Bearbeitung der syslog.conf in der Datei /etc/syslog-ng/syslog.conf.in .
Die Änderungen werden danach aktiviert durch den Befehl
SuSEconfig --module syslog-ng
Auf SLES11 dagegen wird direkt in der /etc/syslog-ng/syslog.conf geändert und der Dämon schlicht über /etc/init.d/syslog restart neu gestartet.
Clients auf Solaris-Server
Per Default dendet der Syslog unter Solaris (seit SunOS 5.6 (Solaris 2.5.1) ) nachrichten im Format:
[ID msgid facility.priority] Nachricht
Beispiel:
Jul 9 10:13:06 u5 pseudo: [ID 129642 kern.info] pseudo-device: tod0
Jul 9 16:14:51 u5 login: [ID 644210 auth.notice] ROOT LOGIN /dev/console
Diese kommen auf dem Loghost dann in der $MSGONLY als solches an. Syslog-NG kann zwar danach filtern mit einer RegExp, jedoch kann syslog-ng den ID-Bestandteil leider nicht selbst entfernen.
Es gibt zwei Möglichkeiten für SUN-Admins:
- Man installiere syslog-ng auf dem Client
- Man konfiguriert das Format und hofft, das dieser Folgepatches überlebt ;)
Ich hab mich für letzteres entschieden. Denn da wir cfengine verwenden um unsere Konfiguration zu verwalten, dürfte damit auch bei wildgewordenen Patches nichts passieren.
Die Konfigurationsdatei für Nachrichtenformate in syslog unter Solaris ist die Datei
/kernel/drv/log.conf
Sie sieht per Default so aus:
name="log" parent="pseudo" instance="0"
msgid=1;
Zum Abschalten der MSGId ist der Wert
msgid=1;
einfach auf “0″ zu setzen. Damit diese Einstellung aktiv wird, ist ein Reboot notwendig.
Weitere Links und Quellen
man bedim len? 