Temporini Matteo

La saga dei miei piccoli how-to sulle configurazioni di mrtg non finisce.

Questa volta mi serviva avere uno strumento per controllare il carico di lavoro del dns, dove per carico di lavoro non intento i carichi della CPU (già discussi nell’articolo sulla configurazione dell’snmp di questo sito).

Un buon parametro per effettuare questi contorlli su un DNS (Domain Name System) è il numero di query al minuto che vengono fatte, in tal modo è possibile avere una cronostoria e una rappresentazione di questo parametro che ci permette di valutare il numero delle richieste ed eventualmente evidenziare potenziali anomalie (es: un tetnativo di DDoS sulla porta 53 con un numero elevato di query).

Il numero di query sul dns non verrà generato a partire da un parametro snmp, bensì da uno script che effettua il parsing dei file di log del bind.

Per ottenere questi log dobbiamo modificare il file /etc/bind/named.conf.options (se avete un unico file probabilmente sarà /etc/named/named.conf o /etc/bind/named.conf) ed aggiungere le seguenti righe:

zone-statistics yes;
statistics-file "named.stats";

e rivviamo il named con

/etc/init.d/named restart

oppure

/etc/init.d/bind9 restart

a seconda della distribuzione che utilizzate. Ora all’interno del file /var/cache/bind/named.stats avrete delle statistiche sul numero di query per i singoli domini.

Il named ora è configurato correttamente, dobbiamo utilizzare i fati contenuti in nel file named.stats e utilizzarli con mrtg per generare i grafici.

Questo viene fatto utilizzando uno script (lo potete scaricare tramite wget).

Salviamo il file all’interno della cartella /etc/mrtg/ o dove avete le vostre configurazioni di mrtg ed editiamo il file /etc/mrtg/mymrtg.cfg aggiungendo quanto di seguito riportato

Target[mydomain_DNS]: `/etc/mrtg/dnsstats.pl`
Options[mydomain_DNS]: gauge,growright,nopercent,integer,unknaszero
Title[mydomain_DNS]: DNS Server
RouterUptime[mydomain_DNS]: public@localhost
MaxBytes[mydomain_DNS]: 32000
AbsMax[mydomain_DNS]: 64000
WithPeak[mydomain_DNS]: wmy
Colours[mydomain_DNS]: YELLOW #F9C000,RED #F90000,LIGHT YELLOW #FFFFBB,LIGTH RED #FF8080
ShortLegend[mydomain_DNS]:queries/m
YLegend[mydomain_DNS]: Qs per Minute
Legend1[mydomain_DNS]: Queries received over 1 minute
Legend2[mydomain_DNS]: Failed Queries received over 1 minute
Legend3[mydomain_DNS]: Maximal Queries over 5 minutes
Legend4[mydomain_DNS]: Maximal Failed Queries over 5 minutes
LegendI[mydomain_DNS]: Queries:
LegendO[mydomain_DNS]: Failures:
PageTop[mydomain_DNS]: <H1>DNS Info</H1><TABLE><TR><TD>System:</TD> <TD>mydomain</TD></TR><TR><TD>Maintainer:</TD> <TD>Matteo Temporini (temporini.matteo@gmail.com)</TD></TR><TR><TD>Description:</TD><TD>DNS Monitor</TD></TR><TR><TD>Details:</TD> <TD>Query Monitor</TD></TABLE>

Mi raccomando fate attenzione che l’ultimo parametro stia tutta sulla stessa riga o vi darà errore.

Ora non ci resta altro da fare che rigenerare l’index.html di mrtg con il nuovo parametro

indexmaker --output=/var/www/html/mymrtg/index.html /etc/mrtg/mymrtg.cfg

e gustarci i nostri grafici che vedete qua sotto

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.

Read the rest of this entry »

A chi non è mai capitato di porconare vedendosi una linux box con una bella scritta “kernel panic”, e oltre a questo incazzarsi perchè non si riesce nemmeno a scorrere la console per avere maggiori delucidazioni sugli errori che hanno portato al crash?
Ecco qua la soluzione ai nostri mai

echo "1" >/proc/sys/kernel/panic_on_oops

In questo modo prima di andare in crash la amcchina funziona ancora per pochi secondi in modo di dare tempo a klogd (ma penso funzioni anche per altro) di loggare tutti i dati che ci servono, e permetterci quindi di vedere in seguito con calma la causa del crash.

A seguito delle varie vicissitudini e il crescere delle esigenze del sito (quali?!?? non importa ;°D), ho deciso di passare ad un servizio superiore presso Eastitaly, attraverso il servizio di VPS messo a disposizione dell’azienda.

Ho preso un VPS-20 ospitato su un server con le seguenti caratteristiche:

Processore: Core 2 DUO a 2,13 GHZ

Ram: 4GB

Hard disk: Dischi in raid da 300Gb

Il mio piccolo VPS invece ha:

Disco: 20GB

Ram: 256MB

Sistema operativo: Fedora Core 5

Non ce la faccio più, è arrivata l’ennesima email di lagne di tophost… ma quelli cosa fanno invece di lavorare?

Mi rifiuto di pubblicarla, per quanto mi riguarda un hoster serio non dovrebbe mandare certe email ai clienti… oltre tutto senza alcun senso e motivo.

La cosa spassosa è che non avendo nulla da fare perdono anche tempo a SPIARE i propri clienti su twitter… ASSURDO!

Come consigliato da tophost consiglio la lattura dell’articolo di Stefano Epifan.

Segnalo inoltre:

Brainlog: La mia esperienza con TopHost

Pseudotecnico: Strategie comunicative? Brainstorming?

Luca Conti: quest’uomo viene spiato di continuo su twitter dallo staff di tophost!!! INCREDIBILE!!

Non finirò mai di stupirmi a leggere certe cose… Questo sito è ospitato presso Tophost e visto il prezzo esiguo che pago per il servizio se ogni tanto ho qualche down (anche 3-4 ore) sinceramente non mi lamento.

Non capisco la gente che prende questi servizi ci carica il sito aziendale e si incazza se ogni tanto non funziona niente… cioè per 10 euro l’anno che cosa pretendono? Se avessi un sito aziendale in cui perdo soldi se va down, mi prendo un bel servizio da 1000 euro l’anno dove posso pretendere giustamente di incazzarmi.

Ma fin qua nulla di strano… clienti che si lamentano… gente che rompe… diciamo i classici eventi che popolano la rete…

Ma si è mai sentito parlare di un provider che manda email di lamentele ai proprio clienti, perchè alcuni di loro parlano male dell’azienda sulla rete? Vi incollo di seguito la mail che è giunta a tutti i clienti del provider in questione…

“Un saluto a tutti, come prima cosa vi comunichiamo che i lavori miranti alla soluzione del problema che ha afflitto il nodo 03 vittima di alcuni crash sporadici manifestatisi a partire dal 15/08 stanno terminando, con l’occasione abbiamo anche aggiornato i vari software. Aspettiamo le prossime 24 ore ma il problema dovrebbe essere definitivamente rientrato.

Torniamo ora al “titolo” della nostra comunicazione, noi pensiamo di fare il nostro lavoro con la massima professionalità, pensiamo altresì che quella che all’inizio era solo un’utopia e cioè fornire un servizio di Hosting minimale ma completo ad un prezzo che fosse un punto di riferimento e che mettesse chiunque, anche il più squattrinato dei ragazzi nella condizione di avere un suo sito sia ormai una scommessa vinta: decine di migliaia di clienti complessivi, centinaia di nuovi al giorno.

Certo abbiamo problemi, come li hanno tutti dei quali siamo molto consci. Consentiteci anche una considerazione: in proporzione al nostro parco clienti la quantità dei problemi è comunque contenuto e vi assicuriamo che c’è un enorme lavoro dietro le quinte per migliorare l’affidabilità e la qualità dei nostri servizi.
Forte è l’impegno ogni giorno per fare meglio, ogni giorno per superarci.

Non possiamo comunque non rilevare come la disponibilita’ dei nostri servizi, nonostante i problemi che ci sono stati, nel loro complesso su base annuale per il periodo trascorso sia stata addirittura superiore ad alcuni altri Hoster più “blasonati” e “costosi” di noi.

Con questo post “estivo” però vogliamo rilevare come “in giro per la rete” ci siano dei “gruppetti” più o meno organizzati che “sparano a zero” nei nostri confronti con un’acredine ed una violenza degna della peggiore tifoseria della peggiore curva sud.

Abbiamo pensato di farne una recensione, si proprio noi li vogliamo recensire nella speranza che esista anche un solo nostro utente che si trova bene, nonostante tutto, con noi e che abbia voglia di spiegarglielo, magari direttamente a loro, in casa loro.

Si va dal “giornalista” radical-scic che si augura fallimenti e roghi:

http://www.pandemia.info/2005/11/06/tophost_la_telenovela_continua.html
http://www.pandemia.info/2005/10/31/tophost_e_in_come_ma_anchespli.html

a chi con molta classe è comunque attento agli antipasti per finire con una citazione di bella memoria: “el pueblo unido”
http://spin-off.sw4n.net/post/8994499
http://www.sw4n.net/2007/08/19/el-pueblo-unido/

a chi invece eccelle nel dono della sintesi ma non per questo perde in efficacia:
http://greenwich.tumblr.com/post/9025051

E come non citare poi tutti coloro che, animati da mille interessi parlano di noi in preda ad una specie di “delirio onirico” come se per loro fossimo “un’apparizione” minacciando diffide e azioni legali:
http://www.prozone.it/smf/index.php/topic,2032.msg16935.html#msg16935

E come dimenticare quelli che “parlano male si”, ma in maniera circostanziata e documentata”:
http://www.domainers.it/forum/viewtopic.php?t=33

E perchè tacere e non riportare la prosa di qualche “illuminato altruista” che vuole evitare il suo stesso dramma anche ad altri:
http://www.aggery.it/munnezza/tophost-hosting-revolution-ah-beh/

E per finire perchè non essere proprio noi a consigliarvi una “way out” per fuggire da tophost?
http://prioni.wordpress.com/2007/08/20/dedicato-a-chi-vuole-abbandonare-tophost/
con tanto di codice promozionale per l’affiliazione del caro “Ubuntista” che mentre aiuta i malcapitati a “fuggire da tophost” raggrenella anche la sua “birra”; bello in particolare il passaggio: “- il costo è ragionevole;”. è 10 volte quello di tophost e, permetteteci non è assolutamente 10 volte meglio !

Terminiamo questo post tra il serio ed il faceto saremmo curiosi di sapere se c’è almeno un uguale numero di clienti che ci stima e che apprezza il nostro lavoro, che è convinto che in tophost ci sono delle persone che lavorano seriamente e non dei “ragazzini che avendo perso le biglie hanno cambiato gioco e sono passati all’hosting”; e ci farebbe anche piacere che qualcuno di questi lo dicesse pubblicamente, magari in quegli stessi posti che abbiamo citato. Così giusto per capire se la nostra scelta di fornire un servizio di Hosting al prezzo più basso possibile (e al momento nessuno ha battuto la nostra offerta) sia stata giusta o sbagliata, apprezzata o detestata.

Per chi volesse anche solo dire la propria abbiamo attivato un topic sulla nostra area nel forum di Prozone:
http://www.prozone.it/smf/index.php/topic,2657.0.html

Rinnoviamo il saluto a tutti e un augurio di sfruttare al meglio gli ultimi giorni d’agosto. “

Ho sempre reputato il servizio di tophost abbastanza buono e professionale, ma questa mi sembra solamente una cosa ridicola e puerile, senza alcun senso… è una trovata per far parlare di più di se stessi? Aumentare le vendite o che altro?

Oltre a questo, nominare in un email indirizzata ai clienti i siti di altre persone addittandoli come sobillatori di fanatismo di massa, li reputo ridicoli e basta.

Consiglio anche la lettura del sito di “Luca Moretto” al riguardo di questo argomento.

Come al solito le problematiche al lavoro sono le più disparate, oggi mi sono dovuto occupare del tuning di un firewall che utilizzo sul lavoro.

Nello specifico per ragioni di comodità e facilità d’uso (purtroppo non sono l’unico a utilizzarei server e devo badare anche a questo aspetto), utilizzo firestarter.

Si tratta di un firewall molto semplice da utilizzare anche ai “non addetti ai lavori“, in quanto non si tratta altro che di un semplice front end grafico per iptables, assai più ostico da utilizzare per i principianti.

Questo breve documento non si occuperà pertanto di configurare il firewall (discretamene semplice anche senza documentazione) ma semplicemente spiegherà come apportare direttamente delle modifiche tramite iptables che sono escluse dalle casistiche previste dal frontend.

Il firewall l’ho configurato in un modo molto semplice, ho messo come policy di default tutto in drop, ed ho aggiunto le eccezioni per i servizi che mi interessavano.

Pertanto la mia situazione di partenza era che qualunque pacchetto inviato da e verso la macchina veniva scartato ad eccezione di: webserver, dns e posta.

Ora il problema che mi si era posto era il seguente: avevo dei simpatici “amici” che non avevano nulla da fare e ogni tanto senza preavviso iniziavano a dossare una macchina, e l’unica soluzione possibile senza dover intervenire sulla dorsale (di cui ovviamente non ho il minimo controllo) era di fare in modo che venissero scartate le connessioni di quella specifica rete.

La soluzione è stata molto semplice, con firestarter basta editare il file

[root@localhost ~]# nano /etc/firestarter/user-pre

e a questo punto aggiungere i comandi di iptables che ci interessavano, ad esempio

iptables -A INPUT -d 195.54.0.0/20 -j DROP
iptables -A INPUT -s 195.54.0.0/20 -j DROP
iptables -A OUTPUT -d 195.54.0.0/20 -j DROP
iptables -A OUTPUT -s 195.54.0.0/20 -j DROP
iptables -A FORWARD -d 195.54.0.0/20 -j DROP
iptables -A FORWARD -s 195.54.0.0/20 -j DROP

In tal modo vengono droppate tutte le connessioni che entrano, escono o solamente transitano su questa classe di ip.

Una volta aggiunte le righe che ci interessano basta dare un semplice

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

ed ecco fatto, il nostro piccolo firewall personalizzato

Ovviamente con questo metodo si possono creare tutte le policy che ci interessano tramite i comandi di iptables.

In questo breve articolo descriverò brevemente come configurare l’accesso ad una shell senza dover digitare ogni volta la password, tramite scambio di chiavi RSA sfruttando il protocollo OpenSSH.

Mi è tornata utile tale funzione per gestire un backup incrementale remoto tramite rsync (magari un giorno scrivo due righe anche su questo così magari qualcuno mi da qualche consiglio), appoggiandomi sul protocollo criptato fornito dal servizio OpenSSH.

Ipotizziamo di operare in una LAN nella sottorete 192.168.0.0/24 e che la macchina da cui vogliamo effettuare l’accesso senza password sia la 192.168.0.2, mentra quella su cui vogliamo loggarci senza password sia la 192.168.0.3.

Dalla macchina dalla quale ci si vuole connettere senza digitare la password (192.168.0.2), digitiamo il seguente comando per generare la chiave RSA

[root@192.168.0.2 ]# ssh-keygen -b 2048 -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
f7:ec:0d:c8:f4:df:7a:6c:2b:1d:a1:59:ee:c7:ae:a0 root@192.168.0.2

Ora copiamo la chiave che abbiamo generato nella macchina di destinazione

[root@192.168.0.2 ]# scp /root/.ssh/id_rsa.pub root@192.168.0.3:.

Logghiamoci ora nella macchina alla quale ci si vuole connettere senza utilizzare la password e digitiamo il seguente comando

[root@192.168.0.3 ]#cat /root/id_rsa.pub >> /root/.ssh/authorized_keys

Finito, adesso dalla macchina 192.168.0.2 potremo loggarci sulla 192.168.0.3 senza digitare alcunapassword, ma non viceversa.

Questa tecnica può essere usata per gestire le connessioni tramite rsync appoggiandosi al protocollo OpenSSH.

[root@192.168.0.2 ~]# ssh root@192.168.0.3
Last login: Thu Jul 19 15:20:29 2007 from 192.168.0.2
[root@192.168.0.3 ~]#

E’ di ieri l’annuncio… slackware 12 è stata finalmente rilasciata!!!

Ovviamente mi sono già affrettato per il download, è a casa prnta che aspetta nella speranza che mi funzioni sul nuovo fiammante notebook che ho preso… incorciamo le dita!

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.