Temporini Matteo » email http://www.temporini.net It's time to fix! Fri, 27 Jan 2012 23:21:23 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Virtual User con Postifx e spamassassin… come migliorare il controllo Antispam!! http://www.temporini.net/virtual-user-con-postifx-e-spamassassin-come-migliorare-il-controllo-antispam http://www.temporini.net/virtual-user-con-postifx-e-spamassassin-come-migliorare-il-controllo-antispam#comments Wed, 07 Apr 2010 15:09:53 +0000 admin http://www.temporini.net/?p=331 Un po’ di tempo fa ho scritto un articolo su come configurare Virtual Users And Domains With Postfix, Courier, MySQL (Ubuntu 8.04 LTS 64bit), ora a partire da questo articolo vediamo come poter migliorare l’identificazione dello spam tramite il comando sa-learn di spamassassin, e l’utilizzo dell’opzione –spam e –ham.

Innanzitutto facciamo una distinzione fra Spam [...]]]> Un po’ di tempo fa ho scritto un articolo su come configurare Virtual Users And Domains With Postfix, Courier, MySQL (Ubuntu 8.04 LTS 64bit), ora a partire da questo articolo vediamo come poter migliorare l’identificazione dello spam tramite il comando sa-learn di spamassassin, e l’utilizzo dell’opzione –spam e –ham.

Innanzitutto facciamo una distinzione fra Spam e Ham

Spam : sono le email indesiderate che non si vogliono ricevere, e che quindi vanno scartate, taggate o comunque a cui va fatto aumentare il valore di spam in caso di matching del contenuto con i nostri db di spam.

Ham: sono le mail buone (Ham = prosciutto BUONO!), le email che quindi vogliamo tenere.

Dalla nostra webmail, creiamo una cartella che si chiama Spam e che verrà quindi creata sul filesystem in una cartellina che si chiama .Spam

Ricordando brevemente la struttura delle directory che abbiamo assegnato per ogni email avremo una struttura simile alla seguente

ls -al /home/vmail/domain.tld/info

drwx------  6 vmail vmail 4096 2010-02-23 19:18 .Bozze
drwx------  6 vmail vmail 4096 2010-02-23 19:18 .Cestino
drwx------  2 vmail vmail 4096 2010-04-07 12:05 courierimapkeywords
-rw-r--r--  1 vmail vmail  105 2010-02-23 19:48 courierimapsubscribed
-rw-r--r--  1 vmail vmail 1193 2010-04-07 11:56 courierimapuiddb
drwx------  2 vmail vmail 4096 2010-04-07 12:01 cur
drwx------  6 vmail vmail 4096 2010-04-07 12:41 .Drafts
drwx------  2 vmail vmail 4096 2010-04-07 11:56 new
drwx------  6 vmail vmail 4096 2010-04-07 12:43 .Sent
drwx------  6 vmail vmail 4096 2010-02-23 15:53 .sent-mail
drwx------  6 vmail vmail 4096 2010-02-23 19:18 .Spam
drwx------  6 vmail vmail 4096 2010-02-23 19:51 .Templates
drwx------  2 vmail vmail 4096 2010-04-07 16:51 tmp
drwx------  6 vmail vmail 4096 2010-03-02 20:22 .Trash

Tutti le email di tutti i domini hanno questa struttura, quindi cosa succede…

Quando dalla nostra webmail vediamo che c’è un’email che ha passato i nostri antispam, non facciamo altro che dire “no questa email la sposto nella cartellina Spam!”. (da horde c’è un opzione che permette eventualmente di marcare un’email come spam e automaticamente spostarla in quella cartella).

A questo punto noi avremo che in:

/home/vmail/domain.tld/info/cur = avremo le mail buone (Ham)

mentre in

/home/vmail/domain.tld/info/.Spam = avremo le email di Spam

Sfruttando questo possiamo creare una regola ad hoc, per fare “imparare” a spamassassin, quali sono le mail buone e quali quelle cattive.

Mettiamo tutto in crontab per ottenere questo:

20 * * * * /usr/bin/sa-learn --spam /home/vmail/*/*/.Spam/* &> /dev/null
10 * * * * /usr/bin/sa-learn --ham /home/vmail/*/*/cur/* &> /dev/null

Ai 10  e 20 minuti di ogni ora verranno fatti gli aggiornamenti e il nostro sistema “imparerà” da noi quali sono le mail che non sono spam.

]]> http://www.temporini.net/virtual-user-con-postifx-e-spamassassin-come-migliorare-il-controllo-antispam/feed 0 Wrapper Sendmail http://www.temporini.net/wrapper-sendmail http://www.temporini.net/wrapper-sendmail#comments Fri, 23 Nov 2007 16:16:40 +0000 admin http://www.temporini.net/wrapper-sendmail Problema del giorno… quante volte capita che qualche script non sicuro (es. form php senza controlli di sicurezza sull’inserimento dei dati e conseguente invio di un’email), riempia le code dei nostri server di posta? A me sinceramente molto spesso (si pensi a qualcuno che crea uno script di “test” che basta lanciarlo e viene spedita [...]]]> Problema del giorno… quante volte capita che qualche script non sicuro (es. form php senza controlli di sicurezza sull’inserimento dei dati e conseguente invio di un’email), riempia le code dei nostri server di posta? A me sinceramente molto spesso (si pensi a qualcuno che crea uno script di “test” che basta lanciarlo e viene spedita un’email, lo script viene dimenticato li e trovato da qualche bontempone che si diverte a esguirlo centinaia di volte… voi direte “ma chi vuoi che lo faccia?!?!?!?” e io vi rispondo dicendo solo… “più di quanti si possa immaginare”).

Conseguenza di tutto questo sono ore perse a cercare qualche script, sito o altro responsabile del fattaccio, con conseguenti improperi verso ogni genere di essere vivente vi si presenti vicino.

Grazie ai consigli e all’aiuto di Marco Londero, abbiamo ideato un piccolo wrapper php che genera un log sulla posta che viene inviata trmamite il comando mail() di php, e aggiunge un header all’interno dell’email stessa in grado di permetterci di risalire al log desiderato e riuscire ad identificare meglio l’origine di un certo problema.

All’interno di tale log avremo una cosa molto importante, il path dello script che ha generato e inviato l’email in questione.

Siamo partiti a partire un wrapper trovato su groogsblog e tramite semplici modifiche siamo riusciti ad ottenere quel che ci serviva.

Una definizione di wrapper (giusto per capire di cosa si parla) potrebbe essere la seguente “Un wrapper è uno script di shell che incorpora una utility o un comando di sistema. Questo evita di dover digitare una serie di parametri che andrebbero passati manualmente a quel comando.”

Vediamo ora come installarlo.

Presupponiamo di utilizzare postfix (di fatto si potrebbe usare qualunqua altro sistema senza problemi),

cd /etc/postfix/

touch sendmail.php

chmod 775 sendmail.php

nano sendmail.php

A questo punto nel file sendmail.php inseriamo il codice del Wrapper, e salviamo il file.

Modifichiamo olra il file php.ini e permettiamo al wrapper di essere eseguito prima di sendmail (sarà il wrapper stesso dal suo interno a richiamare sendmail al momento opportuno).

nano /etc/php.ini

sostituiamo il valore di sendmail_path con il seguente

sendmail_path = /etc/postfix/sendmail.php

Prepariamo le directory che conterranno i log che che genererà il nostro simpatico wrapper

mkdir /var/log/phpmail
chown root:apache /var/log/phpmail
chmod 770 /var/log/phpmail

ed ora non ci resta altro che riavviare apache

/etc/init.d/apache2 restart

Date una controllata al file /var/log/httpd/error_log per vedere che sia tutto corretto e aspettate (o create uno script in php per testarlo), ora quando verrà inviata un’email da uno script in php accadranno due cose

1- nell’header dell’email vi sarà un campo nuovo che si chiama X-MsgID e che altro non è che il nome del file in /var/log/phpmail/ che contiene i dati dell’email inviata dal webserver

2- all’interno del file relativo all’header X-MsgID vi sarà un campo che indicherà il path dello script che ha inviato un’email

Riporto di seguito un esempio del contenuto del file di log di un’email

Body: 574 bytesDate: Fri, 23 Nov 2007 16:35:37 +0100
PWD: /var/www/vhost/XXX.TLD/home/html/phpBB2
Msg ID: ns3.eastitaly.it_20071123163537.4746f3495849d

Message:
———-
To: tusysweelszew@mail.ru
Subject: Welcome to www.XXX.TLD Forums
Reply-to: info@XXX.TLD
From: info@XXX.TLD
Return-Path: info@XXX.TLD
Message-ID: <aace212218a818186b114bcd1fe00573@www.XXX.TLD>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
Date: Fri, 23 Nov 2007 16:35:37 +0100
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: PHP
X-MimeOLE: Produced By phpBB2
X-MsgID: ns3.eastitaly.it_20071123163537.4746f3495849d
———-
Body: 574 bytes

Da questo log oltre a tutti i dati tipici di un’email si può notare la riga

PWD: /var/www/vhost/XXX.TLD/home/html/phpBB2

che non è altro che il path dello script che ha inviato l’email, chiaramente sarebbe più efficiente se vi fosse la possibilità di identificare direttamente il nome dello script, ma diciamo che già così gran parte dei problemi si riescono a isolare e identificare in breve tempo.

Un altra eventuali miglioria che si può apportare è di gestire tutto questo anzichè come file separati come un unico file di log, ma lo faremo col tempo e con la voglia come sempre ;)

Saluti

]]> http://www.temporini.net/wrapper-sendmail/feed 0 Configurazione snmp http://www.temporini.net/configurazione-snmp http://www.temporini.net/configurazione-snmp#comments Wed, 20 Jun 2007 09:21:43 +0000 admin http://www.temporini.net/archives/27 Questa breve guida spiega (o almeno ci prova) come configurare il servizio di snmp su un server linux, per il monitoraggio delle risorse. Provvede poi a integrare i dati raccolti tramite grafici generati con Mrtg.

Questa guida è stata sviluppata su sistemi Fedora Core 5, ma è facilmente adattabile (se non addirittura direttamente applicabile) anche [...]]]> Questa breve guida spiega (o almeno ci prova) come configurare il servizio di snmp su un server linux, per il monitoraggio delle risorse. Provvede poi a integrare i dati raccolti tramite grafici generati con Mrtg.

Questa guida è stata sviluppata su sistemi Fedora Core 5, ma è facilmente adattabile (se non addirittura direttamente applicabile) anche ad altri sistemi (Debian, Slackware con piccole modifiche inereti al sistema di pacchettizzazione).

1. Installazione e configurazione Snmpd

Per prima cosa provvediamo a installare il servizio snmpd tramite i pacchetti disponibili della nostra distribuzione:
[root@localhost ~] yum install net-snmp-utils net-snmp

per Debian i pacchetti si installano con il seguente comando

[root@localhost ~] apt-get install snmpd snmp

A questo punto controllate se il demone snmpd è stato lanciato
[root@localhost ~] ps -aux | grep snmpd

dovreste visualizzare qualcosa tipo

root 5512 0.0 2.3 5872 3012 pts/0 S 22:04 0:00 /usr/sbin/snmpd

Se il demone non è in esecuzione provare a lanciarlo a mano con il seguente comando

[root@localhost ~] /etc/init.d/snmpd restart

e ricontrollate il suo stato.

Per aggiungere lo script all’avvio della macchina basta eseguire
[root@localhost ~] chkconfig –level 345 snmpd on

Ora il demone snmpd è correttamente in esecuzione, proviamo a controllarne il corretto funzionamento tramite una semplice query sulle interfacce di rete:

[root@ns9 ~]# snmpwalk -v 1 -c public localhost IP-MIB::ipAdEntIfIndexIP-MIB::ipAdEntIfIndex.81.208.101.XXX = INTEGER: 2IP-MIB::ipAdEntIfIndex.127.0.0.1 = INTEGER: 1
IP-MIB::ipAdEntIfIndex.192.168.0.XXX = INTEGER: 3
[root@ns9 ~]#

Se tutto funziona correttamente, allora il demone è correttamente configurato, se doveste avere qualche problema, è meglio controllare il file di configurazione /etc/snmp/snmpd.conf

All’interno di questo file modifichiamo questa linea
com2sec notConfigUser default public

e sostituiamola con quella di seguito adattando ovviamente le subnet come preferite.

com2sec local localhost public
com2sec mynetwork 192.168.0.0/24 public

Scendendo ancora nel file cercate la stringa

group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser

e sostituitela con

group MyRWGroup v1 local
group MyRWGroup v2c local
group MyRWGroup usm local
group MyROGroup v1 mynetwork
group MyROGroup v2c mynetwork
group MyROGroup usm mynetwork

Cerchiamo ora la stringa seguente

view systemview included system

e sostituiamola con

view all included .1 80

Abbiamo quasi finito… cercate la stringa

access notConfigGroup “” any noauth exact systemview none none

e sostituitela con

access MyROGroup “” any noauth exact all none none
access MyRWGroup “” any noauth exact all all none

Ed ora l’ultima stringa da modificare
syslocation Unknown (edit /etc/snmp/snmpd.conf)
syscontact Root root@localhost (configure /etc/snmp/snmp.local.conf)

queste stringhe sono delle brevi stringhe descrittive per l’identificazione del vostro sistema, fondamentalmente potete scriverci cosa volete io ho messo questo

syslocation Linux (FEDORA_FC5), localhost
syscontact matteo@temporini.net

Bene ora se tutto è andato per il verso giusto, riavviate il demone snmp (/etc/init.d/snmpd restart) e provate a fare nuovamente la query (snmpwalk -v 1 -c public localhost IP-MIB::ipAdEntIfIndex) che a questo punto non dovrebbe darvi problemi.

2. Installazione e configurazione MRTG

Installiamo mrtg con il comando

[root@localhost ~]# yum install mrtg

analogamente per debian

[root@localhost ~]# apt-get install mrtg

A questo punto presuppongo che abbiate un webserver correttamente funzionante (io uso Apache ma non vi sono problemi a utilizzarne altri come ISS o Lighthttpd).

Presupponiamo che la root di apache stia in /var/www/html/ andiamo a creare la cartella che conterrà i nostri dati

[root@localhost ~]# mkdir -p /var/www/html/mymrtg/

ora eseguiamo il seguente comando per generare automaticamente il file di configurazione di mrtg

[root@localhost ~]# cfgmaker –global ‘WorkDir: /var/www/html/mymrtg’ –output /etc/mrtg/mymrtg.cfg public@localhost

e creiamo l’index.html del nostro sistema di monitoraggio

[root@localhost ~]# indexmaker –output=/var/www/html/mymrtg/index.html /etc/mrtg/mymrtg.cfg

(N.B.= — sono due trattini (-) vicini ma sembrano una linea unica se fate il cut & paste fate attenzione)

Ora è tutto pronto non ci resta che eseguie mrtg indicandogli il file di configurazione da utilizzare

[root@localhost ~]# env LANG=C /usr/bin/mrtg /etc/mrtg/mymrtg.cfg –logging /var/log/mrtg.log

In ambiente fedora è necessaria la stringa env LANG=C, su altri sistemi probabilmente questa variabile di ambiente è già settata in questo modo per cui potrebbe bastare solamente

[root@localhost ~]# /usr/bin/mrtg /etc/mrtg/mymrtg.cfg –logging /var/log/mrtg.log

A questo punto non rimane che vedere il risultato di tutto il nostro lavoro andando al seguente indirizzo http://www.your.com/mymrtg/ o http://localhost/mymrtg/

L’ultimo step da seguire consiste nel mettere in crontab l’esecuzione dello script di aggiornamento di mrtg, il modo più semplice per farlo è con il comando

[root@localhost ~]# crontab -e

Vi si aprirà una finestra e qui inseriteci

*/5 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/mymrtg.cfg –logging /var/log/mrtg.log

lo script verrà lanciato ogni 5 minuti, in tal modo i campionamenti verranno aggiornati sui nostri grafici in ogni 5 minuti. Qualora voleste avere stime più precise potete diminuire il tempo di campionamento ad 1 minuto ad esempio ottenendo così risultati più accurati.

3. Ulteriori risorse da monitorare

Quanto sino ad ora visto, permette di creare un piccolo sistema di monitoraggio per la banda utilizzata dai vari dispositivi di rete, in un tempo realtivamente ristretto e con una buona accuratezza (questo dipende ovviamente dall’intervallo di campionamento che si sceglie).

La domanda a questo punto che uno potrebbe porsi è “ma posso monitorare solo la banda o anche altre risorse?”.

Ovviamente la risposta è si, è possibile monitorare altri risorse di sistema, cosa che si è resa molto utile per identificare anomalie nei sitemi e risolverle (es.: utilizzi intensivi della cpu da parte di particolari processi in determinate ore della giornata).

Riporterò ora delle piccole porzioni di codice da aggiungere al file /etc/mrtg/myrtgc.cfg per aggiungere queste funzionalità.

3.1 Monitoraggio dell’utilizzo di CPU

#
# CPU Monitoring
# (Scaled so that the sum of all three values doesn’t exceed 100)
#

Target[server.cpu]:ssCpuRawUser.0&ssCpuRawUser.0:public@localhost + ssCpuRawSystem.0&ssCpuRawSystem.0:public@localhost + ssCpuRawNice.0&ssCpuRawNice.0:public@localhost
Title[server.cpu]: Server CPU Load
PageTop[server.cpu]: <H1>CPU Load – System, User and Nice Processes</H1>
MaxBytes[server.cpu]: 100
ShortLegend[server.cpu]: %
YLegend[server.cpu]: CPU Utilization
Legend1[server.cpu]: Current CPU percentage load
LegendI[server.cpu]: Used
LegendO[server.cpu]:
Options[server.cpu]: growright,nopercent
Unscaled[server.cpu]: ymwd

3.2 Monitoraggio dell’utilizzo della memoria totale rispetto a quella disponibile

#
# Memory Monitoring (Total Versus Available Memory)
#

Target[server.memory]: memAvailReal.0&memTotalReal.0:public@localhost
Title[server.memory]: Free Memory
PageTop[server.memory]: <H1>Free Memory</H1>
MaxBytes[server.memory]: 100000000000
ShortLegend[server.memory]: B
YLegend[server.memory]: Bytes
LegendI[server.memory]: Free
LegendO[server.memory]: Total
Legend1[server.memory]: Free memory, not including swap, in bytes
Legend2[server.memory]: Total memory
Options[server.memory]: gauge,growright,nopercent
kMG[server.memory]: k,M,G,T,P,X

3.3 Percentuale di utilizzo della Memoria

#
# Memory Monitoring (Percentage usage)
#
Title[server.mempercent]: Percentage Free Memory
PageTop[server.mempercent]: <H1>Percentage Free Memory</H1>
Target[server.mempercent]: ( memAvailReal.0&memAvailReal.0:public@localhost ) * 100 / ( memTotalReal.0&memTotalReal.0:public@localhost )
options[server.mempercent]: growright,gauge,transparent,nopercent
Unscaled[server.mempercent]: ymwd
MaxBytes[server.mempercent]: 100
YLegend[server.mempercent]: Memory %
ShortLegend[server.mempercent]: Percent
LegendI[server.mempercent]: Free
LegendO[server.mempercent]: Free
Legend1[server.mempercent]: Percentage Free Memory
Legend2[server.mempercent]: Percentage Free Memory

3.4. Nuove connessioni TCP

#
# New TCP Connection Monitoring (per minute)
#

Target[server.newconns]: tcpPassiveOpens.0&tcpActiveOpens.0:public@localhost
Title[server.newconns]: Newly Created TCP Connections
PageTop[server.newconns]: <H1>New TCP Connections</H1>
MaxBytes[server.newconns]: 10000000000
ShortLegend[server.newconns]: c/s
YLegend[server.newconns]: Conns / Min
LegendI[server.newconns]: In
LegendO[server.newconns]: Out
Legend1[server.newconns]: New inbound connections
Legend2[server.newconns]: New outbound connections
Options[server.newconns]: growright,nopercent,perminute

3.5 Connessioni TCP stabilite

#
# Established TCP Connections
#

Target[server.estabcons]: tcpCurrEstab.0&tcpCurrEstab.0:public@localhost
Title[server.estabcons]: Currently Established TCP Connections
PageTop[server.estabcons]: <H1>Established TCP Connections</H1>
MaxBytes[server.estabcons]: 10000000000
ShortLegend[server.estabcons]:
YLegend[server.estabcons]: Connections
LegendI[server.estabcons]: In
LegendO[server.estabcons]:
Legend1[server.estabcons]: Established connections
Legend2[server.estabcons]:
Options[server.estabcons]: growright,nopercent,gauge

3.6 Utilizzo del disco

L’utilizzo di questo parametro di monitoraggio richiede l’inserimento nel file /etc/snmp/snmpd.conf del seguente codice

disk /

con conseguente riavvio del demone snmpd
#
# Disk Usage Monitoring
#

Target[server.disk]: dskPercent.1&dskPercent.1:public@localhost
Title[server.disk]: Disk Partition Usage
PageTop[server.disk]: <H1>Spazio su disco utilizzato</H1>
MaxBytes[server.disk]: 100
ShortLegend[server.disk]: %
YLegend[server.disk]: Utilization
LegendI[server.disk]: Partizione /
Options[server.disk]: gauge,growright,nopercent
Unscaled[server.disk]: ymwd

3.7 Carichi della CPU

#
# Load Average
#

Target[server.loadavg]: laLoadInt.2&laLoadInt.3:public@localhost
MaxBytes[server.loadavg]: 5000
Title[server.loadavg]: Load Average * 100
PageTop[server.loadavg]:<h1>Load Average * 100</h1>
YLegend[server.loadavg]: Load Average
ShortLegend[server.loadavg]:
Legend1[server.loadavg]: Load average 5 min
Legend2[server.loadavg]: Load average 15 min
LegendI[server.loadavg]: 5min load avg
LegendO[server.loadavg]: 15min load avg
Options[server.loadavg]: nopercent,growright,noinfo,gauge

4. Monitoraggio del traffico email di Postfix

Un discorso a parte va fatto per quanto riguarda il monitoraggio sull’invio e la ricezione di email tramite postfix.

Grazie alla documentazione trovata in rete mi è stato possibile implmentare un sistema che permette di contare il numero di email inviate e ricevute dal server di posa, nell’arco di tempo dell’intervallo di campionamento (i famosi 5 minuti). Questo viene realizzato tramite il richiamo, da parte di mrtg, di alcuni script esterni che fanno quanto richiesto, una volta raccolti i dati vengono processati da mrtg per la generazione dei grafici.

Questi script che bisogna utilizzaresono scritti in perl per cui dovete installare alcuni moduli in perl tramite cpan, prima di fare questo installate ncftp che viene utilizzato da perl per scaricare i file, questo semplicemente usando il comando

[root@localhost ~]# yum install ncftp

analogamente per debian

[root@localhost ~]# apt-get install ncftp

a questo punto lanciate il comando cpan e dopo aver risposto a un po’ di domande, che vi chiederà lui per la corretta configurazione di della shell del perl (solitamente basta dare invio a tutte prendendo i parametri di default), eseguite il comando

[root@localhost ~]# cpan
Terminal does not support AddHistory.

cpan shell — CPAN exploration and modules installation (v1.7602)
ReadLine support available (try ‘install Bundle::CPAN’)

cpan> install File::Tail

una volta finita l’installazione di questo moduletto possiamo caricare i file in perl, son tre semplici file che dovete mettere in /usr/local/bin con i permessi di esecuzione

mrtg-mailstats.pl
mailstats.pl
update-mailstats.pl

A questo punto non ci rimane che lanciare il processo update-mailstats.pl (script che si occupa di tenere costantemente monitorato il traffico del mailserver) con il comando

[root@localhost ~]# /usr/local/bin/update-mailstats.pl &

con il comando mailstats.pl è possibile vedere le statistiche in tempo reale sul numero totale di messaggi inviati e ricevuti come nel seguente esempio

[root@localhost ~]# mailstats.pl
RECEIVED:smtp 98057
SENT:local 235
SENT:smtp 54423
SENT:virtual 42947
[root@localhost ~]#

Aggiungiamo nel file /etc/mrtg/mymrtg.cfg il seguente codice

#—————————————————————#
# MRTG mail cfg: Postfix mailstats plotting with MRTG #
#—————————————————————#
Target[postfix]: `/usr/local/bin/mrtg-mailstats.pl`
Options[postfix]: gauge, growright
Title[postfix]: Postfix Statistics
PageTop[postfix]: <H1>Postfix Statistics</H1>
MaxBytes[postfix]: 1000000
WithPeak[postfix]: dwmy
YLegend[postfix]: No. of messages
ShortLegend[postfix]: messages
LegendI[postfix]: Incoming:
LegendO[postfix]: Outgoing:
#—————————————————————#

rigeneriamo l’index di mrtg con il comando

[root@localhost ~]# indexmaker –output=/var/www/html/mymrtg/index.html /etc/mrtg/mymrtg.cfg

e abbiamo finito ;)

Ora dovreste vedere, man mano che i valori vengono campionati, i grafici anche sulle mail in ingresso e in uscita di postfix. Una tecnica simile penso sia molto semplice da utilizzare anche per altri programmi e risorse.

Se avete suggerimenti, scritiche miglioramenti, script o teniche per il monitoraggio di altre risorse di sistema, contattatemi.

]]> http://www.temporini.net/configurazione-snmp/feed 2