Logging fan alle foarkommende eveneminten is ien fan 'e wichtichste funksjes fan elk bedriuwsysteem. Logs kinne jo opkommende problemen oplosse, de wurking fan ynformaasjesystemen kontrolearje, en ek ynsidinten fan ynformaasjefeiligens ûndersykje. Zimbra OSE hâldt ek detaillearre logs fan har operaasje. Se befetsje alle gegevens fan serverprestaasjes oant it ferstjoeren en ûntfangen fan e-post troch brûkers. It lêzen fan de logs generearre troch Zimbra OSE is lykwols in nochal net-triviale taak. Yn dit artikel, mei in spesifyk foarbyld, sille wy jo fertelle hoe't jo Zimbra OSE-logs lêze kinne, lykas hoe't jo se sintralisearre kinne meitsje.
Zimbra OSE bewarret alle lokale logs yn 'e /opt/zimbra/log-map, en logs kinne ek fûn wurde yn it /var/log/zimbra.log-bestân. De wichtichste dêrfan is mailbox.log. It registrearret alle aksjes dy't foarkomme op 'e e-posttsjinner. Dizze omfetsje de oerdracht fan e-post, brûkersautentikaasjegegevens, mislearre oanmeldpogingen, en oaren. Ynstjoerings yn mailbox.log binne in tekststring dy't it tiidstip befettet wêrop it barren barde, it nivo fan it evenemint, it threadnûmer wêryn't it evenemint barde, de brûkersnamme en IP-adres, en ek in tekstbeskriuwing fan it evenemint .
It lognivo jout de graad fan ynfloed fan it evenemint op de operaasje fan de tsjinner oan. Standert binne d'r 4 evenemintnivo's: INFO, WARN, ERROR en FATAL. Litte wy nei alle nivo's sjen yn tanimmende folchoarder fan earnst.
- INFO - Eveneminten op dit nivo binne meastentiids bedoeld om te ynformearjen oer de fuortgong fan Zimbra OSE. Berjochten op dit nivo befetsje rapporten oer it oanmeitsjen of wiskjen fan in postfak, ensfh.
- WARN - eveneminten fan dit nivo ynformearje oer situaasjes dy't potinsjeel gefaarlik binne, mar hawwe gjin ynfloed op de wurking fan 'e tsjinner. Bygelyks, it WARN-nivo markearret in berjocht oer in mislearre brûker oanmeldpoging.
- ERROR - dit barrennivo yn it log ynformearret oer it foarkommen fan in flater dy't lokaal fan aard is en net bemuoit mei de wurking fan 'e tsjinner. Dit nivo kin in flater markearje wêryn de yndeksgegevens fan in yndividuele brûker beskeadige binne wurden.
- FATAL - dit nivo jout flaters oan wêrtroch't de tsjinner net normaal kin wurkje. Bygelyks, de FATAL nivo sil wêze foar in rekôr oanjout de ûnfermogen om te ferbinen mei de DBMS.
It logbestân fan de e-mailtsjinner wurdt elke dei bywurke. De lêste ferzje fan it bestân hat altyd de namme Mailbox.log, wylst logs foar in bepaalde datum in datum yn de namme hawwe en yn it argyf steane. Bygelyks mailbox.log.2020-09-29.tar.gz. Dit makket it folle makliker om aktiviteitslogboeken te meitsjen en troch logs te sykjen.
Foar it gemak fan de systeembehearder befettet de map /opt/zimbra/log/ oare logs. Se befetsje allinich yngongen dy't relatearje oan spesifike Zimbra OSE-eleminten. Bygelyks, audit.log befettet allinich records oer brûkersautentikaasje, clamd.log befettet gegevens oer de wurking fan it antyvirus, ensfh. Trouwens, in poerbêste metoade foar it beskermjen fan in Zimbra OSE-tsjinner tsjin ynbrekkers is , dy't gewoan wurket basearre op audit.log. It is ek in goede praktyk om in cron-taak ta te foegjen om it kommando út te fieren grep -ir "ûnjildich wachtwurd" /opt/zimbra/log/audit.logom deistige oanmeldfoutynformaasje te ûntfangen.
In foarbyld fan hoe't audit.log in twa kear ferkeard ynfierd wachtwurd toant en in suksesfolle oanmeldingspoging.
Logs yn Zimbra OSE kinne ekstreem nuttich wêze by it identifisearjen fan de oarsaken fan ferskate krityske mislearrings. Op it momint dat in krityske flater optreedt, hat de behearder meastentiids gjin tiid om de logs te lêzen. It is nedich om de tsjinner sa gau mooglik te herstellen. Lykwols, letter, as de tsjinner opnij is en in protte logs genereart, kin it lestich wêze om de fereaske yngong yn in grut bestân te finen. Om fluch in flaterrekord te finen, is it genôch om de tiid te witten wêryn't de tsjinner op 'e nij is opstart en in yngong te finen yn' e logs dy't fan dizze tiid datearje. De foarige yngong sil in rekord wêze fan 'e flater dy't barde. Jo kinne it flaterberjocht ek fine troch te sykjen nei it trefwurd FATAL.
Zimbra OSE-logs kinne jo ek net-krityske flaters identifisearje. Bygelyks, te finen handler útsûnderingen, kinne jo sykje foar handler útsûndering. Faak, flaters oanmakke troch handlers wurde beselskippe troch in stack trace dat ferklearret wat feroarsake de útsûndering. Yn gefal fan flaters mei e-postlevering, moatte jo jo sykopdracht begjinne mei it LmtpServer-kaaiwurd, en om te sykjen nei flaters relatearre oan de POP- of IMAP-protokollen, kinne jo de ImapServer- en Pop3Server-kaaiwurden brûke.
Logs kinne ek helpe by it ûndersykjen fan ynsidinten fan ynformaasjefeiligens. Litte wy nei in spesifyk foarbyld sjen. Op 20 septimber stjoerde ien fan de meiwurkers in mei firus besmette brief nei in klant. As gefolch dêrfan waarden de gegevens op 'e kompjûter fan' e kliïnt fersifere. De meiwurker swarret lykwols dat er neat stjoerd hat. As ûnderdiel fan it ûndersyk nei it ynsidint freget de bedriuwsfeiligenstsjinst fan de systeembehearder de logboeken fan de e-posttsjinner foar 20 septimber ferbûn mei de ûndersochte brûker. Mei tank oan it tiidstempel fynt de systeembehearder it nedige logbestân, ekstrakt de nedige ynformaasje en bringt it oer nei feiligensspesjalisten. Dy, op har beurt, sjoch der troch en fine dat it IP-adres wêrfan dizze brief waard ferstjoerd oerienkomt mei it IP-adres fan 'e kompjûter fan' e brûker. CCTV byldmateriaal befêstige dat de meiwurker wie op syn wurkplak doe't de brief waard ferstjoerd. Dizze gegevens wiene genôch om him te beskuldigjen fan it ynbrekken fan regels foar ynformaasjefeiligens en him te ûntslaan.
In foarbyld fan it ekstrahearjen fan records oer ien fan 'e akkounts fan it Mailbox.log-log yn in apart bestân
Alles wurdt folle komplisearre as it giet om multi-server ynfrastruktuer. Sûnt logs wurde sammele lokaal, wurkje mei harren yn in multi-server ynfrastruktuer is hiel ûngemaklik en dêrom is der in needsaak om sintralisearjen fan de kolleksje fan logs. Dit kin dien wurde troch in host yn te stellen om logs te sammeljen. D'r is gjin spesjale needsaak om in tawijd host ta te foegjen oan 'e ynfrastruktuer. Elke e-posttsjinner kin as knooppunt fungearje foar it sammeljen fan logs. Yn ús gefal sil dit de Mailstore01-knooppunt wêze.
Op dizze server moatte wy de folgjende kommando's ynfiere:
sudo su – zimbra
zmcontrol stop
exit
sudo /opt/zimbra/libexec/zmfixperms -e -vBewurkje it /etc/sysconfig/rsyslog-bestân, en set de SYSLOGD_OPTIONS="-r -c 2" yn
Bewurkje /etc/rsyslog.conf en uncomment de folgjende rigels:
$ModLoad iudp
$UDPServerRun 514
Fier de folgjende kommando's yn:
sudo /etc/init.d/rsyslog stop
sudo /etc/init.d/rsyslog start
sudo su – zimbra
zmcontrol start
exit
sudo /opt/zimbra/libexec/zmloggerinit
sudo /opt/zimbra/bin/zmsshkeygen
sudo /opt/zimbra/bin/zmupdateauthkeysJo kinne kontrolearje dat alles wurket mei it kommando zmprov gacf | grep zimbraLogHostname. Nei it útfieren fan it kommando moat de namme fan 'e host dy't logs sammelt wurde werjûn. Om it te feroarjen, moatte jo it kommando ynfiere zmprov mcf zimbraLogHostname mailstore01.company.ru.
Op alle oare ynfrastruktuerservers (LDAP, MTA en oare e-postwinkels), útfiere it kommando zmprov gacf |grep zimbraLogHostname om de namme te sjen fan de host wêrnei de logs wurde stjoerd. Om it te feroarjen kinne jo ek it kommando ynfiere zmprov mcf zimbraLogHostname mailstore01.company.ru
Jo moatte ek de folgjende kommando's op elke server ynfiere:
sudo su - zimbra
/opt/zimbra/bin/zmsshkeygen
/opt/zimbra/bin/zmupdateauthkeys
exit
sudo /opt/zimbra/libexec/zmsyslogsetup
sudo service rsyslog restart
sudo su - zimbra
zmcontrol restartHjirnei wurde alle logs opnommen op 'e server dy't jo opjûn hawwe, wêr't se maklik kinne wurde besjoen. Ek yn 'e Zimbra OSE-behearderkonsole, op it skerm mei ynformaasje oer de status fan servers, sil de rinnende Logger-tsjinst allinich foar de mailstore01-tsjinner werjûn wurde.
In oare hoofdpijn foar in behearder kin it folgjen fan in spesifike e-post wêze. Om't e-mails yn Zimbra OSE tagelyk troch ferskate ferskillende eveneminten geane: skennen troch antivirus, antispam, ensafuorthinne, foardat se aksepteare of ferstjoerd wurde, foar de behearder, as de e-post net oankomt, kin it frij problematysk wêze om te trace op hokker stadium it wie ferlern.
Om dit probleem op te lossen, kinne jo in spesjaal skript brûke, dat is ûntwikkele troch spesjalist foar ynformaasjefeiligens Viktor Dukhovny en oanrikkemandearre foar gebrûk troch Postfix-ûntwikkelders. Dit skript ferbynt yngongen út logs foar in spesifyk proses en lit jo hjirtroch alle yngongen dy't ferbûn binne mei it ferstjoeren fan in bepaalde brief fluch werjaan op basis fan syn identifier. It wurk is hifke op alle ferzjes fan Zimbra OSE, begjinnend fan 8.7. Hjir is de tekst fan it skript.
#! /usr/bin/perl
use strict;
use warnings;
# Postfix delivery agents
my @agents = qw(discard error lmtp local pipe smtp virtual);
my $instre = qr{(?x)
A # Absolute line start
(?:S+ s+){3} # Timestamp, adjust for other time formats
S+ s+ # Hostname
(postfix(?:-[^/s]+)?) # Capture instance name stopping before first '/'
(?:/S+)* # Optional non-captured '/'-delimited qualifiers
/ # Final '/' before the daemon program name
};
my $cmdpidre = qr{(?x)
G # Continue from previous match
(S+)[(d+)]:s+ # command[pid]:
};
my %smtpd;
my %smtp;
my %transaction;
my $i = 0;
my %seqno;
my %isagent = map { ($_, 1) } @agents;
while (<>) {
next unless m{$instre}ogc; my $inst = $1;
next unless m{$cmdpidre}ogc; my $command = $1; my $pid = $2;
if ($command eq "smtpd") {
if (m{Gconnect from }gc) {
# Start new log
$smtpd{$pid}->{"log"} = $_; next;
}
$smtpd{$pid}->{"log"} .= $_;
if (m{G(w+): client=}gc) {
# Fresh transaction
my $qid = "$inst/$1";
$smtpd{$pid}->{"qid"} = $qid;
$transaction{$qid} = $smtpd{$pid}->{"log"};
$seqno{$qid} = ++$i;
next;
}
my $qid = $smtpd{$pid}->{"qid"};
$transaction{$qid} .= $_
if (defined($qid) && exists $transaction{$qid});
delete $smtpd{$pid} if (m{Gdisconnect from}gc);
next;
}
if ($command eq "pickup") {
if (m{G(w+): uid=}gc) {
my $qid = "$inst/$1";
$transaction{$qid} = $_;
$seqno{$qid} = ++$i;
}
next;
}
# bounce(8) logs transaction start after cleanup(8) already logged
# the message-id, so the cleanup log entry may be first
#
if ($command eq "cleanup") {
next unless (m{G(w+): }gc);
my $qid = "$inst/$1";
$transaction{$qid} .= $_;
$seqno{$qid} = ++$i if (! exists $seqno{$qid});
next;
}
if ($command eq "qmgr") {
next unless (m{G(w+): }gc);
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
if (m{Gremoved$}gc) {
print delete $transaction{$qid}, "n";
}
}
next;
}
# Save pre-delivery messages for smtp(8) and lmtp(8)
#
if ($command eq "smtp" || $command eq "lmtp") {
$smtp{$pid} .= $_;
if (m{G(w+): to=}gc) {
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $smtp{$pid};
}
delete $smtp{$pid};
}
next;
}
if ($command eq "bounce") {
if (m{G(w+): .*? notification: (w+)$}gc) {
my $qid = "$inst/$1";
my $newid = "$inst/$2";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
}
$transaction{$newid} =
$_ . $transaction{$newid};
$seqno{$newid} = ++$i if (! exists $seqno{$newid});
}
next;
}
if ($isagent{$command}) {
if (m{G(w+): to=}gc) {
my $qid = "$inst/$1";
if (defined($transaction{$qid})) {
$transaction{$qid} .= $_;
}
}
next;
}
}
# Dump logs of incomplete transactions.
foreach my $qid (sort {$seqno{$a} <=> $seqno{$b}} keys %transaction) {
print $transaction{$qid}, "n";
}It skript is skreaun yn Perl en om it út te fieren moatte jo it opslaan yn in bestân collate.pl. collate.pl /var/log/zimbra.log | pgrep '[e-post beskerme]>'. It resultaat sil in sekwinsjele útfier fan rigels wêze mei ynformaasje oer de beweging fan 'e brief op' e tsjinner.
# collate.pl /var/log/zimbra.log | pgrep '<[email protected]>'
Oct 13 10:17:00 mail postfix/pickup[4089]: 4FF14284F45: uid=1034 from=********
Oct 13 10:17:00 mail postfix/cleanup[26776]: 4FF14284F45: message-id=*******
Oct 13 10:17:00 mail postfix/qmgr[9946]: 4FF14284F45: from=********, size=1387, nrcpt=1 (queue active)
Oct 13 10:17:00 mail postfix/smtp[7516]: Anonymous TLS connection established to mail.*******[168.*.*.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Oct 13 10:17:00 mail postfix/smtp[7516]: 4FF14284F45: to=*********, relay=mail.*******[168.*.*.4]:25, delay=0.25, delays=0.02/0.02/0.16/0.06, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 878833424CF)
Oct 13 10:17:00 mail postfix/qmgr[9946]: 4FF14284F45: removed
Oct 13 10:17:07 mail postfix/smtpd[21777]: connect from zimbra.******[168.*.*.4]
Oct 13 10:17:07 mail postfix/smtpd[21777]: Anonymous TLS connection established from zimbra.******[168.*.*.4]: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Oct 13 10:17:08 mail postfix/smtpd[21777]: 0CB69282F4E: client=zimbra.******[168.*.*.4]
Oct 13 10:17:08 mail postfix/cleanup[26776]: 0CB69282F4E: message-id=zimbra.******
Oct 13 10:17:08 mail postfix/qmgr[9946]: 0CB69282F4E: from=zimbra.******, size=3606, nrcpt=1 (queue active)
Oct 13 10:17:08 mail postfix/virtual[5291]: 0CB69282F4E: to=zimbra.******, orig_to=zimbra.******, relay=virtual, delay=0.03, delays=0.02/0/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
Oct 13 10:17:08 mail postfix/qmgr[9946]: 0CB69282F4E: removedFoar alle fragen yn ferbân mei Zextras Suite kinne jo kontakt opnimme mei de fertsjintwurdiger fan Zextras Ekaterina Triandafilidi fia e-post [e-post beskerme]
Boarne: www.habr.com