Old:Nagios: monitorare server e servizi: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (→‎Apache: corretto ordine direttive)
 
(26 versioni intermedie di 7 utenti non mostrate)
Riga 1: Riga 1:
= '''SERVER DI POSTA''' =
{{Old}}
== Introduzione ==
Nagios ([http://www.nagios.org Home Page]) è uno strumento molto usato ed utilissimo per il monitoraggio di server e servizi. All'inizio, per molti utenti, è un po' complicato da configurare, ma dopo aver capito il funzionamento risulterà semplice, potente e versatile, attributi necessari per questo genere di strumenti.
{{ Warningbox | Da Debian Lenny 5.0 in poi il pacchetto <code>nagios2</code> non è più presente nei repository. Al suo posto è stato inserito il più aggiornato <code>nagios3</code>.<br/>
Per queste versioni si consiglia pertanto di far riferimento alla guida aggiornata. [[Nagios: monitoraggio infrastruttura IT]] }}


== Installazione ==
La macchina su cui verrà installato Nagios è una Debian Etch. Installeremo la versione 2 di Nagios, con i relativi pacchetti per avere un maggior numero di plugin e immagini (vedremo dopo come usarle).


Per installare nagios è sufficiente un:
<pre>
#  apt-get install nagios2 nagios2-common nagios-plugins nagios-images nagios-plugins-basic  nagios-plugins-standard
</pre>


L'idea � quella di avere una connessione permanente a internet che pu� ricevere posta dall'esterno e gestire la posta interna alla lan ,quindi a meno che non abbiate gi� un dominio per prima cosa andare su www.dyndns.org o servizio analogo(www.no-ip.com), registratevi, sceglietevi un dominio (mandare le email a utente@123.231.201.178 non � proprio comodissimo, soprattutto quando il giorno dopo il numero cambia) e associatelo al vostro indirizzo ip. Se avete un ip dinamico, installate sul vostro computer un programmetto come ddclient (basta apt-gettarlo e rispondere alle domande) che aggiorna automaticamente l'indirizzo ip associato al dominio ogni volta che vi collegate.
Dopo aver scaricato (sono circa 3.5Mb) ed installato nagios provvediamo all'installazione di un web server (necessario per consultare la comoda [[web-interface]]); la mia scelta è ricaduta su apache2, anche perché il server in questione ospiterà applicazioni scritte in PHP. Procediamo ad installare apache2 con:
<pre>
# apt-get install apache2 libapache2-mod-php5
</pre>




== Configurazione ==
=== Apache ===
Al momento dell'installazione viene creato in modo automatico il file <code>/etc/apache2/conf.d/nagios2.conf</code> (il file è, a tutti gli effetti, un link simbolico al file <code>/etc/nagios2/apache2.conf</code>) con il seguente contenuto:
<pre>
# apache configuration for nagios 2.x
# note to users of nagios 1.x:
# throughout this file are commented out sections which preserve
# backwards compatibility with bookmarks/config for nagios 1.x.  simply
# look for lines following "nagios 1.x:" comments.


== POSTFIX ==
ScriptAlias /cgi-bin/nagios2 /usr/lib/cgi-bin/nagios2
ScriptAlias /nagios2/cgi-bin /usr/lib/cgi-bin/nagios2
# nagios 1.x:
#ScriptAlias /cgi-bin/nagios /usr/lib/cgi-bin/nagios2
#ScriptAlias /nagios/cgi-bin /usr/lib/cgi-bin/nagios2


Cominciamo con un server MTA, Mail Transport Agent, che riceve la posta (� quello che tiene aperta la porta 25 smtp in ricezione per intenderci). Si pu� scegliere tra exim, postfix, sendmail, qmail e altri. Scegliamo postfix perche � un buon compromesso in quanto a prestazioni, compatibilit�, flessibilit�, sicurezza.
# Where the HTML pages live
Alias /nagios2 /usr/share/nagios2/htdocs
# nagios 1.x:
#Alias /nagios /usr/share/nagios2/htdocs


''apt-get install postfix''
<DirectoryMatch (/usr/share/nagios2/htdocs|/usr/lib/cgi-bin/nagios2)>
Options FollowSymLinks


Installandolo verr� automaticamente rimosso un altro eventuale MTA gi� installato con apt, probabilmente exim o exim4 che � quello di default su debian.  
DirectoryIndex index.html


Debconf pone delle domande quando si installa postfix. Grazie a queste possiamo avere un server di posta gi� praticamente pronto, molto semplice certo, ma funzionante.
AllowOverride AuthConfig
Order Allow,Deny
Allow From All


Diamo una spiegazione delle varie schermate.
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /etc/nagios2/htpasswd.users
# nagios 1.x:
#AuthUserFile /etc/nagios/htpasswd.users
require valid-user
</DirectoryMatch>


Vi informa delle scelte possibili. Sono previste varie configurazioni; noi sceglieremo "Internet site using smarthost", che in pratica sarebbe l'avere un server che riceve posta e che la invia tutta ad un altro server (quello fornito dal nostro ISP per esempio). Premete ok per passare alla prossima schermata.
# Where the stylesheets (config files) reside
#Alias /nagios2/stylesheets /etc/nagios2/stylesheets
# nagios 1.x:
#Alias /nagios/stylesheets /etc/nagios2/stylesheets


Sciegliamo "Internet with smarthost"
# Enable this ScriptAlias if you want to enable the grouplist patch.
# See http://apan.sourceforge.net/download.html for more info
# It allows you to see a clickable list of all hostgroups in the
# left pane of the Nagios web interface
# XXX This is not tested for nagios 2.x use at your own peril
#ScriptAlias /nagios2/side.html /usr/lib/cgi-bin/nagios2/grouplist.cgi
# nagios 1.x:
#ScriptAlias /nagios/side.html /usr/lib/cgi-bin/nagios2/grouplist.cgi
</pre>
Il file contiene una bozza di configurazione per nagios che permette di raggiungere il servizio digitando, semplicemente <nowiki>http://IP/nagios2/</nowiki>. Questo sistema a me, personalmente, non piace, in quanto nagios sarebbe accessibile da qualsiasi sito ospitato sulla macchina, semplicemente digitando <nowiki>http://www.sito.it/nagios2/</nowiki>, non molto sicuro e pulito.


Mail name: sar� quello che appare dopo la chiocciola nell'indirizzo di posta. Ovviamente deve essere il nome valido del vostro server, dal momento che chi vi risponder� vi mander� la posta a quell'indirizzo.
Creeremo, quindi, un sottodominio dedicato a nagios, modificando il file nel seguente modo:
<pre>


SMTP relay host: qui indichiamo il server di posta a cui facciamo il relay. In parole semplici, quando inviamo una mail al nostro server, esso la spedir� a questo relay che poi la recapiter�. � necessario dato che molti bloccano l'arrivo di email da ip non ritenuti affidabili.
<VirtualHost *:80>
    ServerAdmin root@knio.it
#    DocumentRoot /var/www/nagios/
    ServerName nagios.knio.it


Other destinations to accept mail for: indirizzi che identificano questo server. Quando gli arriva una mail con questa destinazione, capir� che � lui il destinatario. Qua mettete il vostro nome di dominio.
    ErrorLog /var/log/apache2/nagios.knio.it_error.log
    CustomLog /var/log/apache2/nagios.knio.it_access.log combined


Local networks: quali reti sono abilitate a spedire mail. Non mettendo nulla postfix inserir� tutte le reti connesse.
    <Directory />
        AllowOverride All
        Options +Multiviews
        Options Indexes Includes FollowSymLinks MultiViews
        DirectoryIndex index index.html
    </Directory>


Meglio che inseriamo noi a mano localhost (127.0.0.0/8) e la nostra LAN (192.168.1.0/24) nel caso la nostra LAN sia 192.168.1.xxx.
    ScriptAlias /cgi-bin/nagios2 /usr/lib/cgi-bin/nagios2
    ScriptAlias /nagios2/cgi-bin /usr/lib/cgi-bin/nagios2


Use procmail for local delivery: rispondete SI, dato che useremo procmail.
   
    #Alias /nagios2/stylesheets /etc/nagios2/stylesheets
    Alias /nagios2 /usr/share/nagios2/htdocs
    # Enable this ScriptAlias if you want to enable the grouplist patch.
    # See http://apan.sourceforge.net/download.html for more info
    # It allows you to see a clickable list of all hostgroups in the
    # left pane of the Nagios web interface
    # XXX This is not tested for nagios 2.x use at your own peril
    #ScriptAlias /nagios2/side.html /usr/lib/cgi-bin/nagios2/grouplist.cgi
    <DirectoryMatch (/usr/share/nagios2/htdocs|/usr/lib/cgi-bin/nagios2)>
Options FollowSymLinks
DirectoryIndex index.html
AllowOverride AuthConfig
Order Allow,Deny
Allow From All
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /etc/nagios2/htpasswd.users
require valid-user
    </DirectoryMatch>
</VirtualHost>
</pre>


Mailbox size limit: dimensione massima della casella di posta. 0 significa illimitata. Impostatela a vostro piacimento.
Creiamo la Root Directory per questo sito con:
<pre>
# mkdir  /var/www/nagios
# chown -R www-data:www-data /var/www/nagios/
# touch /var/www/nagios/index.html
</pre>
la directory conterrà un file <code>index.html</code> vuoto, in questo file potremmo mettere o una pagina di benvenuto oppure un redirect alla directory contenente l'applicativo, a piacere.


Where should mail for root go: questa imposta un alias per l'utente root, dato che non pu� ricevere posta. Tutto quello che � indirizzato a lui andr� nella casella di un altro utente, non root, che scieglierete voi.
Ora manca solo una cosa da fare: aggiungere l'utente per l'accesso a nagios (operazione obbligatoria, pena un errore di tipo 500 quando si tenta di accedere all'applicazione).


In particolare occhio a mettere /24 in "local networks" e non /255 o altre robe strane che possono venirvi in mente. Se non sapete cosa vuol dire quel /24, tenete /24. Se sapete cosa vuol dire, non avete bisogno di spiegazioni.  
Per aggiungere l'utente usiamo il comando <code>htpasswd</code>:
<pre>
# htpasswd  -c  /etc/nagios2/htpasswd.users nagiosadmin
</pre>
alla richiesta di password, inseriamo una password a nostro piacimento.


Non preoccupatevi se vi sembra che "local networks" specifichi a postfix di ricevere posta solo da quei computer, in realt� dice a postfix di fare RELAY solo per la posta che arriva da quei computer, la posta che arriver� da internet la riceve lo stesso.
Ora possiamo testare la configurazione, ma prima è necessario riavviare Apache per rendere effettive le modifiche che abbiamo effettuato:
<pre>
# /etc/init.d/apache2 restart
</pre>


A questo punto dobbiamo fare solo dei piccoli ritocchi. Editiamo dunque il file di configurazione principale che si chiama ''/etc/postfix/main.cf''. Le voci da sistemare sono:
Collegandosi alla pagina <nowiki>http://nagios.knio.it/nagios2/</nowiki> ci verrà chiesto username/password per accedere a nagios, dopodiché ci verrà mostrata la schermata di default.


''myhostname'': controlliamo che ci sia il nome giusto. Vdi /etc/hostname
=== Nagios ===
==== Introduzione alla configurazione ====
La configurazione di nagios è situata, come da [[FHS]] in <code>/etc/nagios2/</code>. All'interno di questa directory sono presenti i seguenti file (e directory):
; cgi.cfg : il file contiene la configurazione dell'interfaccia web di nagios (quindi i percorsi dove trovare i file di configurazione ed alcuni comportamenti base; la configurazione dei permessi degli utenti e perfino i suoni da riprodurre in caso di problemi)
; commands.cfg : contiene la configurazione dei comandi eseguibili da nagios: check, notifiche ed altri
; conf.d : una directory che ha lo scopo di raccogliere i file di configurazione di tutti i vari host monitorati da nagios
; htpasswd.users : contiene (come abbiamo visto prima) le chiavi di accesso di tutti gli utenti che possono accedere all'interfaccia web di nagios (i permessi, per questi utenti, sono definiti in <code>cgi.cfg</code>)
; nagios.cfg : contiene la configurazione vera e propria del demone di nagios, la configurazione di default è corretta nella maggior parte dei casi
; resource.cfg : in questa guida non lo modificheremo
; stylesheets : directory per inserire i fogli di stile personalizzati (in questa guida non li useremo)


Poi in  ''/etc/aliases'' come da esempio giriamo tutti i messaggi di sistema all'utente se vogliamo ricevere tutto noi
==== Come gestire al meglio i file di configurazione ====
esempio:
Anche se la struttura dei file di configurazione è semplice, ci vuole molto poco a renderla una vera e propria accozzaglia di file. Ci sono varie scuole di pensiero su come gestire i file.


''haldaemon: root
La prima è quella di inserire, all'interno della directory <code>conf.d/</code> un file per ogni host, raggruppando, poi, gli host tramite gli hostgroup. La tecnica è valida e funzionale, a meno che non ci si trovi a gestire un numero eccessivo di host.
mail: root
news: root
proftpd: root
sync: root
root: nomeutente
''


La seconda tecnica, è quella di creare tante directory quanti sono i segmenti della rete, così da racchiudere i file di configurazione in directory meno popolate, così da rendere più facilmente individuabile un file.


nomeutentex � quello che verr� usato da chi vorr� inviare posta, ad esempio all'indirizzo nomeutente1@tuo.dominio.org. Si possono creare utenze che puntano ad altre utenze, nel senso: root che punta a utente1, e utente1 che punta ad utenteposta. Il vero e proprio database di postfix si chiama '/etc/aliases.db', che non va editato a mano. Per sincronizzarlo con le nostre modifiche, lanciamo il comando newaliases:
Personalmente trovo più comodo gestire la prima, con la seguente convenzione:
* ogni file ha la forma <code>'''type'''-'''name'''.cfg</code> dove '''type''' rappresenta la tipologia del file di configurazione (''host'' per un server, ''switch'' per uno switch di rete, ''router'' per un router, e così via...) e dove '''name''' è il nome univoco associato alla macchina (e usato anche all'interno di Nagios).
* i file contenenti i gruppi, le definizioni dei periodi e simili hanno una struttura <code>'''type'''.cfg</code> dove ''type'' può essere:
** '''contacts''': per le definizioni dei contatti
** '''timeperiods''': per le definizioni dei periodi
** '''extinfo''': per le definizioni delle informazioni aggiuntive
** '''hostgroups''': per la definizione dei gruppi di host
** '''services''': per la definizione dei gruppi di servizi


''newaliases''
Un'accortezza da adottare, inoltre, quando si modifica un file di configurazione è quella di effettuare un check di correttezza tramite il comando:
<pre>
# nagios -v /etc/nagios2/nagios.conf
</pre>
In questo modo si eviteranno [[downtime]] e si sarà sicuri che nagios ripartirà senza problemi (almeno legati alla sintassi dei file di configurazione...).


che non restituisce alcun output se tutto va bene. Nel caso vi spari fuori qualcosa tipo "duplicate entry:", editate di nuovo '/etc/aliases', eliminate il duplicato ed eseguite di nuovo il comando newaliases. Tenete presente che non � necessario che siano associati direttamente agli utenti di sistema normali.
==== Gli Host ====
Tramite gli '''[[host]]''' è possibile definire i PC, server, switch e tutte le altre apparecchiature presenti nella rete da monitorare. Saranno poi i '''servizi''' a determinare cosa monitorare effettivamente.


La definizione classica e minimale di un host è la seguente:
<pre>
define host{
  use        generic-host
  host_name  serverino
  alias      Server di Produzione
  address    192.168.0.15
}
</pre>


Qesto esempio riporta in parte la configurazione di /etc/postfix/main.cf :
I parametri della definizione sono i seguenti:
; use : permette di specificare un [[template]] da utilizzare all'interno del nostro host. L'utilizzo di un template permette di minimizzare i parametri necessari da passare ad un host. Il template che usiamo, per ora, è ''generic-host'' che è quello fornito di default in Debian. In seguito provvederemo a creare dei template che permetteranno uan suddivisione degli host in modo semplice ed immediato.
; host_name : l'[[hostname]] dell'host. Deve essere univoco, in quanto viene utilizzato all'interno di Nagios come nome univoco di un host. è buona pratica utilizzare l'hostname della macchina, in quanto permetterà, in seguito, di identificarla più facilmente. In caso di switch od altri componenti conviene identificarli nel seguente modo: '''switch-dmz''', '''firewall-dmz''', etc.
; alias : rappresenta il nome comune dell'host.
; address : l'indirizzo IP dell'host. Deve essere inserito solo l'indirizzo Primario, e non una lista di indirizzi! Se si vogliono monitorare più indirizzi IP o più servizi legati a più indirizzi IP, sarà opportuno o definire un altro host (non molto corretto) oppure aggiungere servizi in cui viene indicato, come parametro, l'indirizzo IP secondario.


''# appending .domain is the MUA's job.
Oltre a quelli specificati è possibile aggiungere questi parametri (per quelli utilizzati nel template rimando al sottocapitolo dedicato):
append_dot_mydomain = no
; parents <host_names> : permette di indicare, tramite un elenco di host separati da virgola, i "parenti" di quell'host (ad esempio switch, gateway, ecc). Utile per la rappresentazione grafica della struttura della rete
# Uncomment the next line to generate "delayed mail" warnings
; hostgroups <hostgroup_names> : permette di specificare i gruppi, sempre separati da virgola, a cui appartiene l'host.
# delay_warning_time = 4h
mydomain = nomeserver
myhostname = nomeserver.nomedominio.it
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = nomeserver, localhost.localdomain, localhost, nomeserver.nomedominio.it
myorigin = $mydomain
relayhost = out.virgilio.it
relay_domains = $mydestination
mynetworks = 127.0.0.0/8 192.168.0.0/24
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
disable_dns_lookups = yes
sender_canonical_maps = hash:/etc/postfix/sender_canonical
# aggiunta per mailscanner
# header_checks = regexp:/etc/postfix/header_checks
# aggiunta per server da DEBIANIZZATI
# mailbox_command = /usr/bin/spamc | procmail -a "&SENDER &RECIPIENT $EXTENSION"''


Come convenzione per la creazione di un host creeremo un file col formato '''/etc/nagios2/conf.d/hosts/hostname.cfg''' dove ''hostname'' va sostituito con l'hostname dell'host definito.


Le due parti aggiunte , lasciatele commentate fino alla fine altrimenti senza aver installato procmail , vi daranno errori.
==== I Servizi ====
I servizi vengono utilizzati per definire un controllo su un servizio presente su un determinato host. Possono essere associati ad un determinato host (utile per controlli specifici) oppure ad un hostgroup (utile per controlli generici o comunque monitoraggio di servizi standard).


Ora create i file per far corrispondere i vostri indirizzi email ai vostri utenti locali. Si tratta dei file'' /etc/postfix/sender_canonical'' (che contiene gli indirizzi che verranno inseriti nel campo from per ogni utente al posto di utente@vostra.macchina) .
Un servizio ha, normalmente, la seguente struttura:
<pre>
define service{
  use                  generic-service
  host_name            localhost
  service_description  Disk Space
  check_command        check_all_disks!20%!10%
}
</pre>


Questo � un esmpio ''/etc/postfix/sender_canonical'':
Dove vengono usati i seguenti parametri:
; use <service-template> : indica il template da utilizzare. Il template contiene tutti i parametri necessari per la configurazione del servizio. In caso di necessità, comunque, è possibile sovrascrivere un parametro presente nel template semplicemente ridefinendolo all'interno del servizio.
; host_name <hostname> : l'hostname specificato nella configurazione dell'host di cui si vuole monitorare il servizio
; service_description <description> : la descrizione ''umana'' del servizio
; check_command <command> : il [[#I_Comandi | comando]] da utilizzare per eseguire il controllo del servizio.


L'esempio sopra riportato associa il servizio ad un determinato host, ma è possibile associarlo ad un hostgroup, sostituendo la voce <code>host_name</code> con <code>hostgroup_name</code>.


''root root@myserver.it
Per i servizi verrà adottata la seguente convenzione:
gino gino.paoli@myserver.it
* se il servizio è dedicato ad un singolo host, viene inserito all'interno del file di configurazione dell'host
www-data security@myserver.it
* se il servizio è dedicato ad un hostgroup, invece, verrà inserito all'interno del file di definizione dell'[[#hostgroup | hostgroup]].
utente1 pierino@myserver.it
''


se modificate il file ''/etc/postfix/sender_canonical'' date:
==== I Comandi ====
I comandi rappresentano i mattoni su cui costruire i check dei sistemi. Essi possono essere specifici (ad esempio il check di funzionamento di un server [[IMAP]]) o generici (come il test dell'apertura di una porta [[TCP]]).


''postmap /etc/postfix/sender_canonical''
I comandi base sono definiti in <code>/etc/nagios2/commands.cfg</code>, mentre quelli installati tramite i plugin (i pacchetti ''nagios-plugins*'') sono contenuti in <code>/etc/nagios-plugins/config/</code>.


La sintassi per la definizione di un comando è la seguente:
<pre>define command{
  template      <templatename>
  name          <objectname>
  command_name  <commandname>
  command_line  <commandline>
}</pre>


Ora da un utente a vostra scelta provate a verificare se il server funziona
Dove:
; template <templatename> : permette di caricare un template (cioè un'altra definizione di comando da cui attingere i valori opzionali)
; command_name  <commandname> : il nome (univoco) del comando. Per convenzione, non potendo inserire spazi all'interno del nome, sostituiremo quest'ultimi con dei '''-'''.
; command_line  <commandline> : il percorso completo del comando (script o eseguibile) da lanciare, con gli eventuali parametri specificati.


Dovete a vare installato ''mail'' , altrimenti
===== Utilizzare quelli esistenti =====
Carpire il corretto utilizzo dei comandi può essere, a volte, un po' complesso. Per capire come utilizzare quelli definiti, possiamo adottare la seguente strategia:
''apt-get install mail''
* identifichiamo il percorso completo del comando da eseguire. In questo esempio ci riferiremo ai comandi contenuti in <code>/etc/nagios-plugins/config/http.cfg</code>. Il path del comando che viene richiamato è <code>/usr/lib/nagios/plugins/check_http</code>.
* visualizziamo l'output dell'help del comando:
<pre>
# /usr/lib/nagios/plugins/check_http -h
check_http (nagios-plugins 1.4.5) 1.96
Copyright (c) 1999 Ethan Galstad <nagios@nagios.org>
Copyright (c) 1999-2006 Nagios Plugin Development Team
        <nagiosplug-devel@lists.sourceforge.net>


con il comando ''mail''  esempio :
This plugin tests the HTTP service on the specified host. It can test
normal (http) and secure (https) servers, follow redirects, search for
strings and regular expressions, check connection times, and report on
certificate expiration times.


''nomeuser@nomeserver:~$ mail root
(invio)
Subject: test
(invio)
prova
(ctrl-D)
Cc: www-data
(invio)
nomeuser@nomeserver:~$''


potete inviare anche le mail verso indirizzi esterni
Usage: check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>]
      [-w <warn time>] [-c <critical time>] [-t <timeout>] [-L]
      [-a auth] [-f <ok | warn | critical | follow>] [-e <expect>]
      [-s string] [-l] [-r <regex> | -R <case-insensitive regex>] [-P string]
      [-m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>] [-A string] [-k string]
NOTE: One or both of -H and -I must be specified


se vi arrivano vuol dire che tutto funziona
Options:
-h, --help
    Print detailed help screen
-V, --version
    Print version information
-H, --hostname=ADDRESS
    Host name argument for servers using host headers (virtual host)
    Append a port to include it in the header (eg: example.com:5000)
-I, --IP-address=ADDRESS
    IP address or name (use numeric address if possible to bypass DNS lookup).
-p, --port=INTEGER
Port number (default: 80)
-4, --use-ipv4
    Use IPv4 connection
-6, --use-ipv6
    Use IPv6 connection
-S, --ssl
  Connect via SSL
-C, --certificate=INTEGER
  Minimum number of days a certificate has to be valid.
  (when this option is used the url is not checked.)


-e, --expect=STRING
    String to expect in first (status) line of server response (default:
HTTP/1.
    If specified skips all other status line logic (ex: 3xx, 4xx, 5xx processing)
-s, --string=STRING
    String to expect in the content
-u, --url=PATH
    URL to GET or POST (default: /)
URL to GET or POST (default: /)
,-P, --post=STRING    URL encoded http POST data
-N, --no-body
    Don't wait for document body: stop reading after headers.
    (Note that this still does an HTTP GET or POST, not a HEAD.)
-M, --max-age=SECONDS
    Warn if document is more than SECONDS old. the number can also be of
    the form "10m" for minutes, "10h" for hours, or "10d" for days.
-T, --content-type=STRING
    specify Content-Type header media type when POSTing


-l, --linespan
    Allow regex to span newlines (must precede -r or -R)
-r, --regex, --ereg=STRING
    Search page for regex STRING
-R, --eregi=STRING
    Search page for case-insensitive regex STRING
--invert-regex
    Return CRITICAL if found, OK if not


== PROCMAIL ==
-a, --authorization=AUTH_PAIR
    Username:password on sites with basic authentication
-A, --useragent=STRING
    String to be sent in http header as "User Agent"
-k, --header=STRING
    Any other tags to be sent in http header. Use multiple times for additional headers
-L, --link=URL
    Wrap output in HTML link (obsoleted by urlize)
-f, --onredirect=<ok|warning|critical|follow>
    How to handle redirected pages
-m, --pagesize=INTEGER<:INTEGER>
    Minimum page size required (bytes) : Maximum page size required (bytes)
-w, --warning=DOUBLE
    Response time to result in warning status (seconds)
-c, --critical=DOUBLE
    Response time to result in critical status (seconds)
-t, --timeout=INTEGER
    Seconds before connection times out (default: 10)
-v, --verbose
    Show details for command-line debugging (Nagios may truncate output)
Notes: This plugin will attempt to open an HTTP connection with the host.
Successful connects return STATE_OK, refusals and timeouts return STATE_CRITICAL
other errors return STATE_UNKNOWN.  Successful connects, but incorrect reponse
messages from the host result in STATE_WARNING return values.  If you are
checking a virtual server that uses 'host headers' you must supply the FQDN
(fully qualified domain name) as the [host_name] argument.
This plugin can also check whether an SSL enabled web server is able to
serve content (optionally within a specified time) or whether the X509
certificate is still valid for the specified number of days.
Examples: CHECK CONTENT: check_http -w 5 -c 10 --ssl www.verisign.com


When the 'www.verisign.com' server returns its content within 5 seconds,
a STATE_OK will be returned. When the server returns its content but exceeds
the 5-second threshold, a STATE_WARNING will be returned. When an error occurs,
a STATE_CRITICAL will be returned.


CHECK CERTIFICATE: check_http www.verisign.com -C 14


In questa guida ho preferito una configurazione in un unico file ,che per me � stata pi� semplice da gestire
When the certificate of 'www.verisign.com' is valid for more than 14 days,
e anche perch� il lavoro che dovevo svolgere io era semplice
a STATE_OK is returned. When the certificate is still valid, but for less than
14 days, a STATE_WARNING is returned. A STATE_CRITICAL will be returned when
the certificate is expired.


qui se non volete complicarvi la vita fate come ho fatto io , altrimenti leggetevi qualche guida e potrete capire un po meglio


Send email to nagios-users@lists.sourceforge.net if you have questions
regarding use of this software. To submit patches or suggest improvements,
send email to nagiosplug-devel@lists.sourceforge.net
</pre>
* confrontiamo la definizione del comando con l'help appena ottenuto:
<pre>
define command{
  command_name    check_http
  command_line    /usr/lib/nagios/plugins/check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$
}</pre>
in questo caso, si occuperà di controllare che ci sia un [[webserver]] funzionante sulla porta 80 dell'host di cui stiamo eseguendo il check (<code>$HOSTADDRESS$</code> e <code>$HOSTADDRESS$</code> sono delle Macro. Per approfondimenti consultare il paragrafo [[#Le Macro |Le Macro]]).


Postfix cos� sarebbe a posto, ma non possiamo ancora fare una prova, perch� manca procmail, un programma che smista la posta.  
Un altro esempio potrebbe essere il comando <code>check_disk</code>, che ha la seguente definizione:
<pre>define command{
        command_name    check_disk
        command_line    /usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -
p $ARG3$
}</pre>
In questo caso si tratta di un controllo locale (quindi viene effettuato sulla macchina su è installato Nagios), infatti non sono presenti le macro viste prima, ma al loro posto sono presenti <code>$ARG1$</code> <code>$ARG2$</code> e <code>$ARG3$</code>, che rappresentano i parametri passati, all'interno della configurazione dei servizi. In questo caso, la prima opzione (<code>-w</code>) imposta il livello di warning, la seconda (<code>-c</code>) imposta la soglia critica e il terzo (<code>-p</code>) indica la partizione su cui effettuare il controllo.


Postfix ne potrebbe anche fare a meno, ma con procmail si possono fare cose pi� belle, per esempio filtrare la posta mettendola in varie directory a seconda dell'user (fittizio) o a seconda della sorgente (vedi mailing list).  
Quando andremo a richiamare il comando all'interno della definizione del servizio, lo faremo in questo modo:
<pre>
define service{
        use                            generic-service
        host_name                      localhost
        service_description            Disk Space on /dev/hda1
        check_command                  check_all_disks!20%!10%!"/dev/hda1"
}</pre>
Com'è facilmente intuibile, il servizio controllerà la partizione ''/dev/hda1'' ed andrà in stato di warning quando ci sarà meno del 20% di spazio disponibile, ed in stato di errore critico quando ce ne sarà meno del 10%.  


Quindi installiamolo.
I parametri sono separati da un '''!''' e vanno indicati nell'ordine corretto (<code>$ARG1$</code> indica il primo parametri, e così via...)!


''apt-get install procmail''
===== Creare nuovi comandi =====
Per semplicità (e convenzione di questa guida) i comandi ''personalizzati'' verranno salvati in <code>/etc/nagios2/conf.d/commands.cfg</code> in modo da non modificare il file di configurazione di default di Nagios (cosa che tornerà utile in caso di aggiornamenti e/o migrazioni).


Il suo file di configurazione va messo nella home dell'utente per la posta, ovvero "utenteposta". Creiamolo con i giusti permessi:
==== I Gruppi di Host (hostgroup) ====
Un '''hostgroup''' è semplicemente un sistema per raggruppare più host in base a delle caratteristiche comuni (che spaziano dall'appartenenza ad una stessa sottorete all'erogazione di uno stesso tipo di servizio, ...).


''touch /home/utenteposta/.procmailrc
Una definizione standard di hostgroup è la seguente:
chmod 600 /home/utenteposta/.procmailrc
<pre>
chown utenteposta:usergroup /home/utenteposta/.procmailrc''
define hostgroup {
  hostgroup_name  http-servers
  alias            HTTP servers
  members          hostname1, hostname2
}
</pre>


Con i seguenti parametri:
; hostgroup_name <hostgroupname> : il nome (univoco e senza spazi) dell'hostgroup. Verrà utilizzato all'interno dei file di configurazione di nagios per fare riferimento a questo gruppo di host
; alias <alias> : un nome comprensibile (una breve descrizione) del gruppo
; members <hostname1, hostname2> : i membri (<code>members</code>) appartenenti al gruppo. <code>members</code> e <code>hostgroups</code> (visto in precedenza all'interno della sezione [[#Gli_Host |Gli Host]] hanno la stessa funzione, ma in più permettono di decidere come gestire l'assegnazione: tramite <code>members</code> viene inserita la lista degli host che fanno parte del gruppo, quindi l'associazione avviene all'interno del file che definisce l'hostgroup; tramite <code>hostgroups</code> l'associazione avviene all'interno del file di configurazione dell'host, in cui vengono indicati tutti i gruppi a cui appartiene. Personalmente ritengo più comodo il secondo metodo in quanto, in caso di rimozione di un host, col primo metodo bisognerebbe modificare tutti i file dei gruppi di cui l'host era membro, pena l'impossibilità di far ripartire nagios; inoltre, specificando tutti i gruppi a cui appartiene un host all'interno del proprio file di configurazione permette di avere sotto controllo l'appartenenza di uno specifico host ad un gruppo.


A questo punto occorre decidere come farlo , infatti in base alle proprie esigenze e alla complessit� del file
Per gli hostgroup si adotta la convenzione di inserirli nella directory <code>/etc/nagios2/conf.d/hostgroups/</code>, specificando per ogni gruppo un file con la sintassi <code>hostgroupname.cfg</code>.
� possibile seguire due tipi di configurazione del file.
I servizi dedicati a quell'hostgroup andranno, a loro volta, inseriti nel file di configurazione del gruppo di host, così come si è fatto per i servizi di un singolo host.


Esiste chi crea pi� file per filtri vari,diversi utenti e altro che poi fanno riferimento al file principale oppure chi mette tutti i comandi in un unico file.
==== I Gruppi di Servizi ====
==== I Contatti ====
==== I Timeperiod ====
==== Le notifiche ====
===== Notifiche via e-mail =====
===== Notifiche via SMS (vodafone) =====
===== Notifiche via SMS (gateway) =====


Per me la scelta del file unico � stata migliore dato che � molto semplice e in un solo file ho tutta la configurazione di procmail
== Varie ==
=== Nagios Checker ===
Nagios Checker ([https://addons.mozilla.org/it/firefox/addon/3607 Home Page]) è una comoda estensione per Firefox che permette di monitorare, direttamente dal browser, lo stato delle nostre macchine. In caso di problemi verrà mostrato un avviso (in rosso) e verrà riprodotto un suono di allarme. Tramite l'estensione sarà possibile, inoltre, accedere direttamente alla pagina dell'host (o del servizio) che danno problemi per approfondire. Un must!


Quello sotto � un esempio del mio file
== FAQ ==
=== Come posso aggiungere un altro utente a Nagios? ===
Per aggiungere un nuovo utente è necessario effettuare due passi:


''# ~/.procmailrc
1) creazione dell'account all'interno del file <code>/etc/nagios2/htpasswd.users</code>
SHELL=/bin/sh
<pre>
#log
# htpasswd /etc/nagios2/htpasswd.users nomeutente
VERBOSE = yes # impostare a no dopo il debug
</pre>
LOGABSTRACT = all # produce log MOLTO estesi, impostare a no in seguito
FORMAIL=/usr/bin/formail # path di formail, usato per processare alcune email
SENDMAIL=/usr/sbin/sendmail # path di sendmail
# File di log
#se tutto funziona dopo un p� potete commentarlo
LOGFILE=${HOME}/procmail.log
# Directory della posta
MAILDIR=${HOME}"/.Maildir"
# Cartella di default. Notare lo slash (/) alla fine che indica a Procmail
# di trattare la cartella in formato Maildir (compatibile con il server IMAP
# che configureremo) e non Mbox !!!
DEFAULT=${MAILDIR}/
YEAR=`date +%Y`
MONTH=`date +%m`
## SPAMASSASSIN ##
## Prima di consegnare le mail, le filtriamo tutte con spamassassin
:0fw:
| spamassassin
# Poi salviamo lo spam in una cartella a parte denominata Spam/
# Lo spam dientificato da un controllo negli header sul campo
# X-Spam-Status agiunto da spamassassin quando la mail viene analizzata
:0:
* ^X-Spam-Status: Yes
.Spam/
#utenti
:0:
* ^TO_nomeutente@nomedominio.it
nomeutente/.Maildir/`$FORMAIL -rt -xMessage-Id:`''


2) Inserire l'utente appena creato all'interno della configurazione di Nagios. Per fare questo bisogna modificare il file <code>/etc/nagios2/cgi.cfg</code> aggiungendo l'utente appena creato alle seguenti direttive (in base ai permessi che si vogliono dare al nuovo utente):
<pre>
authorized_for_system_information=nagiosadmin
authorized_for_configuration_information=nagiosadmin
authorized_for_system_commands=nagiosadmin
authorized_for_all_services=nagiosadmin
authorized_for_all_hosts=nagiosadmin
#authorized_for_all_services=nagiosadmin,guest
#authorized_for_all_hosts=nagiosadmin,guest
authorized_for_all_service_commands=nagiosadmin
authorized_for_all_host_commands=nagiosadmin
</pre>


Dopo le varie modifiche è necessario ricaricare la configurazione di nagios con un:
<pre>
# /etc/init.d/nagios2 reload
</pre>


........................................................................................................................................
{{Autori
 
|Autore=[[Utente:MaXeR|MaXeR]]
 
}}
':0:' marca l'inizio della sezione;
 
'* ^TO_' indica l'indirizzo email completo dell'utente;
 
 
La successiva riga indica la directory dove le mail di quell'utente verranno parcheggiate, e con che formato.
 
Quindi avremo ad esempio per ogni utente la parte prima indicata e correggerremo solo il finale
 
'':0:
* ^TO_nomeutente1@tuo.dominio.com
nomeutente1/.Maildir/`$FORMAIL -rt -xMessage-Id:`
 
:0:
* ^TO_nomeutente2@tuo.dominio.com
nomeutente2/.Maildir/`$FORMAIL -rt -xMessage-Id:`''
 
...
 
eccetera.
 
Nel caso arrivino mail che non soddisfano i filtri precedentemente applicati nel file di cfg di procmail possiamo scaricarle in una directory precisa aggiungendo queste 3 righe:
 
'':0:
 
* ^TO_
 
nomeutentex/.Maildir/`$FORMAIL -rt -xMessage-Id:`''
 
 
Precisazione: `$FORMAIL -rt -xMessage-Id:` serve ovviamente per dare un nome al file.
 
 
 
 
== SERVER IMAP ==
 
 
 
 
Bene, a questo punto abbiamo un sistema pronto, per quanto semplice, che riceve posta e la smista in directory. Non � ancora funzionante perch� le directory non gliele abbiamo ancora create, e prima di farlo dobbiamo scegliere un server IMAP o POP da usare, cio� il server a cui gli utenti si collegheranno per leggere la posta col loro client. In teoria potrebbero leggere la posta direttamente dal filesystem, ma non � molto comodo. Abbiamo varie possibilit�, fra cui due sono state prese in considerazione e spiegate: 'courier-imap' e 'dovecot'. Entrambi sono server IMAP, che ci consentono di tenere tutta la posta nel server senza scaricarla nel client. Quale scegliere? Beh, quello che preferite. Ovviamente sono gi� pronti e pacchettizzati in debian (dovecot per� c'� solo in debian sid in questo momento) quindi per installarli usamo al solito apt-get.
 
''apt-get install courier-imap fam''
 
Notare che con courier installiamo anche fam, File Alteration Monitor. Non � un elemento indispensabile, tuttavia courier � gi� pronto ad usarlo, permettendo che vari utenti possano condividere delle stesse directory e venir immediatamente avvisati dei cambiamenti. Ora che sono installati (o uno o l'altro) abbiamo a disposizione uno strumento che ci permette di finire il lavoro con procmail, cio� creare le directory organizzate correttamente.
 
 
=== CREAZIONE DIRECTORY PER OGNI UTENTE ===
 
 
Creiamo una directory per ogni utente che abbiamo specificato. Entriamo nella directory home dell'utente designato come root per la gestione delle email ('/home/utenteposta') e cominciamo.
 
 
''maildirmake.courier /home/utenteposta/.Maildir
chown -R utenteposta:usergroup /home/utenteposta/.Maildir
 
maildirmake.courier /home/utenteposta2/.Maildir
chown -R utenteposta2:usergroup /home/utenteposta2/.Maildir''
 
...
 
Ripetete quelle 2 righe di comando per ogni utente che avete aggiunto al file /etc/aliases, o comunque ogni utente che deve avere una casella di posta distinta.
 
Notate che impostiamo l'utente di tutto a utenteposta e i permessi a 700, cos� utenteposta sar� l'unico oltre a root a poter leggere la posta direttamente dal disco.
 
A questo punto si pu� gi� provare a vedere se il server riceve la posta e la mette nel posto giusto.
 
Ricordatevi di aprire la porta 25 sul vostro firewall se ne state usando uno, altrimenti non potrete ricevere posta dall'esterno:
 
''iptables -I INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT''
 
Aprite il vostro client di posta abituale, la vostra webmail preferita (o chiedete a qualche amico collegato a internet di farlo, cos� vedete se la posta arriva anche da fuori) e mandate un'email a nomeutente1@tuo.dominio.com. Se tutto va bene dentro a /home/utenteposta/nomeutente1/new/ trovate i files di testo corrispondenti a ciascuna email.
 
 
 
 
=== CREAZIONE DATABASE UTENTE ===
 
 
Come prima, dobbiamo creare il database degli utenti. Oltre a indicare chi si pu� loggare a imap, e guardare la posta, dobbiamo dirgli con quale password e qual'� la sua posta. Per fare questo creiamo un file, di tipo database GDBM o DB, che si chiama ''/etc/courier/userdb'':
 
''touch /etc/courier/userdb
chmod 600 /etc/courier/userdb
chown root:root /etc/courier/userdb''
 
Notate che non deve avere permessi alcuni per gli appartenenti del gruppo o per gli altri. Ora recuperiamo l'UID e il GID dell'utente utenteposta, andando a leggere ''/etc/passwd''
 
''grep utenteposta /etc/passwd
 
utenteposta:x:107:65534::/home/utenteposta:/bin/bash''
 
Bene, ora possiamo cominciare a inserire a mano i vari utenti. Usiamo un programma del pacchetto courier, che si chiama userdb.
 
''userdb "john@example.com" set home=/home/utenteposta/ mail=/home/utenteposta/.Maildir/ uid=107 gid=65534''
 
Ripetiamo l'operazione per ogni utente.
 
Manca da inserire la password, per�: lo facciamo con un altro programma che si chiama userdbpw, che ci chiede la password criptandola in md5sum:
 
''userdbpw -md5 | userdb "john@example.com" set imappw''
 
Ci chieder� di inserire la password due volte, senza farci vedere l'echo sul terminale, e la inserir� nel file userdb.
Notate che in questo modo le password salvate sul disco sono criptate, ma non quelle mandate dal client al server per l'autenticazione.
 
In quel caso bisogna usare un sistema diverso, di tipo CRAM-MD5 per esempio.
 
Compiliamo il database con il comando
 
''makeuserdb''
 
che creer� due file: ''userdb.dat'' contenente le informazioni tranne le password e 'userdbshadow.dat' che conterr� le password.
 
L'ultima cosa da fare abilitare l'uso di userdb: aprite il file ''/etc/courier/authdaemonrc'' e modificate:
 
''authmodulelist="authpam"''
 
in
 
''authmodulelist="authuserdb"''
 
Ora possiamo passare a configurare il demone di autenticazione di courier.
 
Esso verr� chiamato ogni volta che qualcuno tenta una connessione. Il suo file di configurazione si chiama ''/etc/courier/authdaemonrc'' ed � molto ben commentato... l'unica opzione da cambiare � 'authmodulelist'.
 
Qua indichiamo quale o quali moduli di autenticazione verranno usati, ovvero in che modo il demone deve recuperare la lista degli utenti e delle password.
 
Dal momento che abbiamo preparato un database DB, carichiamo il modulo authuserdb. Ora che abbiamo sistemato la parte di autenticazione, possiamo far partire il demone che se ne occupa, quindi:
 
''/etc/init.d/courier-authdaemon start''
 
Il file di configurazione di courier-imap si chiama ''/etc/courier/imapd''. Contiene gi� tutto quello che serve al demone per funzionare, quindi non lo modificheremo. L'unica opzione che val la pena guardare � ''ADDRESS'': essa indica quali indirizzi deve ascoltare.
 
Non so come inserire un range di indirizzi, quindi lasciamo 0 (prego qualcuno che lo sa di spiegarlo). Avviamo quindi il servizio.
 
''/etc/init.d/courier-imap start''
 
 
 
== FETCHMAIL ==
 
 
 
Fetchmail � un programma che diventa molto comodo quando si hanno altre caselle di posta e si vuole concentrare tutto su una.
 
Ha due modalit� di funzionamento, come demone e come normale programma ma noi lo useremo come demone per controllare ad intervalli profissati la presenza di posta.
 
Se c'� verr� scaricata e inoltrata al nostro server che provveder� a smistarla e a recapitarla nella casella locale.
 
Procediamo ad installarlo:
 
''apt-get install fetchmail''
 
Il file di configurazione lo dobbiamo creare in /etc, si chiamer� ''fetchmailrc''.
 
''touch /etc/fetchmailrc
chown fetchmail /etc/fetchmailrc
chmod 600 /etc/fetchmailrc''
 
La cosa pi� semplice da fare � un copia/incolla di questo file di esempio, che cmq � quello che uso io nel mio server.
 
Nei commenti c'� la spiegazione delle impostazioni (man fetchmailrc per informazioni ulteriori).
 
''# Intervallo di tempo che passa fra ogni controllo. 300 secondi = 5 minuti
# 180 = 3 minuti
#
set daemon 300
# Il log delle operazioni viene fatto tramite syslog
set syslog
# Utente a cui va a finire la posta se non ce ne sono altri disponibili
#
set postmaster "discarica@example.com"
# Evita di perdere le mail se succede un essore 4xx. Dall'altro lato,
# per�, gli errori 5xx diventano pi� pericolosi
#
set no bouncemail
# Non manda insulti a chi manda spam
#
set no spambounce
# Ignora le stringhe; potrebbero essere usate da script
#
set properties ""
# I default seguenti sono usati nelle connessioni ai vari server, ma
# possono venire sovrascritti dalle impostazioni locali
#
defaults:
# Aggiunge un header di debug
#
tracepolls
# Usa pop3 come protocollo di default
#
protocol POP3
# Ignora gli errori antispam di postfix, dato che � molto lontano
# dalla sicurezza usarli assieme all'opzione bouncemail
#
antispam -1
# Massimo numero di email da forwardare in un colpo
#
batchlimit 100
# Scarica tutte le email, anche quelle marcate come lette
#
fetchall
# Caselle di posta da controllare
#
poll mail.provider.it
username "user" password "pass"
is "john@example.com" here
#
poll in.virgilio.it timeout 60 with protocol imap
username "utente" there with password "xyzxyz"
is "nomeutentex@example.com" here options keep''
 
 
Come potete vedere la sinstassi del poll � molto varia. Nel primo esempio abbiamo una casella di posta che verr� controllata e le email che contiene verranno girate all'utente locale john@example.com. Nel secondo esempio vediamo la possibilit� di aggiungere altre opzioni, ad esempio un timeout oltre al quale fetchmail desiste dal contattare un server, oppure indicare esplicitamente un protocollo, e infine la possibilit� di lasciare le email nel server (keep).
 
Ce ne sono molte altre, la cosa migliore da fare � leggere le pagine di manuale.
 
La configurazione di fetchmail si esaurisce qui. Facciamo partire il servizio:
 
''/etc/init.d/fetchmail start''
 
andando a modificare anche in ''/etc/default/fetchmail''
 
mettendo :
 
''Italic text''start_daemon=yes
 
 
Adesso bisogna aggiungere alla configurazione di procmail 3 righe per dirgli dove mettere le email che sono state spedite all'utente "utente@virgilio.it", altrimenti le scarter�. Per fare questo andiamo ad editare il file che descrive gli utenti di procmail, ''/home/utenteposta/.pm/utenti.rc'', e aggiungiamo:
 
'':0:
 
* ^TO_utente@virgilio.it
 
nomeutentex/Maildir/`$FORMAIL -rt -xMessage-Id:`''
 
In questo modo le mail prelevate da quella casella di posta saranno recapitate nella casella locale dell'utente nomeutentex. Le modifiche a questo file si possono fare al volo senza riavviare procmail, e verranno prese immediatamente.
 
 
== MAILSCANNER SPAMASSASSIN CLAMAV AMAVISD-NEW RAZOR ==
 
 
 
a questo punto installiamo con :
 
''apt-get install mailscanner spamassassin clamav razor amavisd-new(opzionale)''
 
 
=== Spamassassin ===
 
 
Riguardo la configurazione di spamassassin io ho usato webmin ,anche se non c'� molto da fare .
 
Per settaggi particolari di spamassassin vi consiglio di dare un'occhiata al file ''/etc/spamassassin/local.cf'' oppure consultare il sito web http://www.yrex.com/spam/spamconfig.php che vi consente di creare un file di configurazione personalizzato rispondendo alle varie domande.
 
abilitiamo spamassassin modificando in ''/etc/default/spamassassin''
''ENABLE=1''
 
 
=== clamav ===
 
 
fa tutto da solo
 
 
 
=== mailscanner ===
 
 
dalla guida http://www.mailscanner.info/postfix.html
 
Stop Postfix usando il comando
 
' '/etc/init.d/postfix stop''
 
Nel file di configuratione di Postfix ''/etc/postfix/main.cf'' aggiungete questa linea:
 
''header_checks = regexp:/etc/postfix/header_checks''
 
create il file
 
''touch /etc/postfix/header_checks''
''chmod 644 /etc/postfix/header_checks''
 
adesso inserite dentro al file creato la segunete linea
 
''/^Received:/ HOLD''
 
Nel vostro MailScanner.conf file (probabilmente in /etc/MailScanner), avrete 5 settaggi da modificare
 
''Run As User = postfix''
''Run As Group = postfix''
''Incoming Queue Dir = /var/spool/postfix/hold''
''Outgoing Queue Dir = /var/spool/postfix/incoming''
''MTA = postfix''
''# per avere i rapporti in italiano''
''%report-dir% = /etc/MailScanner/reports/it''
 
 
 
Dovrete anche essere sicuri che postfix possa scrivere in
 
''chown postfix.postfix /var/spool/MailScanner/incoming''
''chown postfix.postfix /var/spool/MailScanner/quarantine''
''chown postfix.postfix /var/run/mailscanner''
''chown postfix.postfix /var/spool/MailScanner/''
''chown postfix.postfix /var/lib/Mailscanner/''
''chown postfix.postfix /var/lock/subsys/Mailscanner/''
 
 
 
A questo punto rilanciamo i servizi
 
''/etc/rc.d/init.d/''
''./postfix restart''
''./mailscanner restart''
 
 
 
== CLIENT IMAP ==
 
 
 
potete usare il client che piu vi aggrada, da thunderbir su win o evolution su linux
 
Per poter inviare la posta in locale dovrete usare :
 
''nomeutente@nomeserver.nomedominio''
 
esempio
 
''prova@server.pasticcio.it''
 
 
 
== WEBMAIL ==
 
 
Dovete avere i servizi ''apache2 , mysql , php4 o php5''
 
A questo punto per rendere pi� sicuro il sistema ho preferito non aprire la porta 143 (IMAP)
 
Io subito ho installato ilohamail , disponibile come pacchetto che si installa con apt-get ma io ho scelto di installarlo manualmete , dato che avevo avuto problemi con la configurazione , ho copiato l'intero contenuto del file tar.gz nella cartella HTML
 
Dopo le giuste configurazioni indirizzate il vostro browser su http://vostrosito/cartella ilohamail
 
dovreste vedere la finestra iniziale di accesso
 
Esistono altri programmi come http://openwebmail.org/ e altri ancora , questa � una vostra scelta
 
Ma adesso sto provando group office che sembra essere il migliore in circolazione.
 
Ottimo il servizio di posta con IMAP , una vera suite per ufficio con calendario e altro ancora , rubrica con vcard , davvero un bel prodotto .
 
L'installazione � semplice , basta seguire le informazioni all'interno del file
 
Si scompatta nella cartella web e in pochi passi sarete sbaloditi dalla grafica e dalla velocit�.
 
il sito -http://www.group-office.com/
 
il forum della versione free -http://www.group-office.com/forum/
 
dove scaricarlo -http://sourceforge.net/projects/group-office/

Versione attuale delle 13:01, 19 giu 2016

Emblem-important.png Attenzione. Questa guida è obsoleta. Viene mantenuta sul Wiki solo per motivi di natura storica e didattica.


Introduzione

Nagios (Home Page) è uno strumento molto usato ed utilissimo per il monitoraggio di server e servizi. All'inizio, per molti utenti, è un po' complicato da configurare, ma dopo aver capito il funzionamento risulterà semplice, potente e versatile, attributi necessari per questo genere di strumenti.

Warning.png ATTENZIONE
Da Debian Lenny 5.0 in poi il pacchetto nagios2 non è più presente nei repository. Al suo posto è stato inserito il più aggiornato nagios3.

Per queste versioni si consiglia pertanto di far riferimento alla guida aggiornata. Nagios: monitoraggio infrastruttura IT


Installazione

La macchina su cui verrà installato Nagios è una Debian Etch. Installeremo la versione 2 di Nagios, con i relativi pacchetti per avere un maggior numero di plugin e immagini (vedremo dopo come usarle).

Per installare nagios è sufficiente un:

#  apt-get install nagios2 nagios2-common nagios-plugins nagios-images nagios-plugins-basic  nagios-plugins-standard 

Dopo aver scaricato (sono circa 3.5Mb) ed installato nagios provvediamo all'installazione di un web server (necessario per consultare la comoda web-interface); la mia scelta è ricaduta su apache2, anche perché il server in questione ospiterà applicazioni scritte in PHP. Procediamo ad installare apache2 con:

# apt-get install apache2 libapache2-mod-php5


Configurazione

Apache

Al momento dell'installazione viene creato in modo automatico il file /etc/apache2/conf.d/nagios2.conf (il file è, a tutti gli effetti, un link simbolico al file /etc/nagios2/apache2.conf) con il seguente contenuto:

# apache configuration for nagios 2.x
# note to users of nagios 1.x:
#	throughout this file are commented out sections which preserve
#	backwards compatibility with bookmarks/config for nagios 1.x.  simply
#	look for lines following "nagios 1.x:" comments.

ScriptAlias /cgi-bin/nagios2 /usr/lib/cgi-bin/nagios2
ScriptAlias /nagios2/cgi-bin /usr/lib/cgi-bin/nagios2
# nagios 1.x:
#ScriptAlias /cgi-bin/nagios /usr/lib/cgi-bin/nagios2
#ScriptAlias /nagios/cgi-bin /usr/lib/cgi-bin/nagios2

# Where the HTML pages live
Alias /nagios2 /usr/share/nagios2/htdocs
# nagios 1.x:
#Alias /nagios /usr/share/nagios2/htdocs

<DirectoryMatch (/usr/share/nagios2/htdocs|/usr/lib/cgi-bin/nagios2)>
	Options FollowSymLinks

	DirectoryIndex index.html

	AllowOverride AuthConfig
	Order Allow,Deny
	Allow From All

	AuthName "Nagios Access"
	AuthType Basic
	AuthUserFile /etc/nagios2/htpasswd.users
	# nagios 1.x:
	#AuthUserFile /etc/nagios/htpasswd.users
	require valid-user
</DirectoryMatch>

# Where the stylesheets (config files) reside
#Alias /nagios2/stylesheets /etc/nagios2/stylesheets
# nagios 1.x:
#Alias /nagios/stylesheets /etc/nagios2/stylesheets

# Enable this ScriptAlias if you want to enable the grouplist patch.
# See http://apan.sourceforge.net/download.html for more info
# It allows you to see a clickable list of all hostgroups in the
# left pane of the Nagios web interface
# XXX This is not tested for nagios 2.x use at your own peril
#ScriptAlias /nagios2/side.html /usr/lib/cgi-bin/nagios2/grouplist.cgi
# nagios 1.x:
#ScriptAlias /nagios/side.html /usr/lib/cgi-bin/nagios2/grouplist.cgi

Il file contiene una bozza di configurazione per nagios che permette di raggiungere il servizio digitando, semplicemente http://IP/nagios2/. Questo sistema a me, personalmente, non piace, in quanto nagios sarebbe accessibile da qualsiasi sito ospitato sulla macchina, semplicemente digitando http://www.sito.it/nagios2/, non molto sicuro e pulito.

Creeremo, quindi, un sottodominio dedicato a nagios, modificando il file nel seguente modo:


<VirtualHost *:80>
    ServerAdmin root@knio.it
#    DocumentRoot /var/www/nagios/
    ServerName nagios.knio.it

    ErrorLog /var/log/apache2/nagios.knio.it_error.log
    CustomLog /var/log/apache2/nagios.knio.it_access.log combined

     <Directory />
         AllowOverride All
         Options +Multiviews
         Options Indexes Includes FollowSymLinks MultiViews
         DirectoryIndex index index.html
     </Directory>

    ScriptAlias /cgi-bin/nagios2 /usr/lib/cgi-bin/nagios2
    ScriptAlias /nagios2/cgi-bin /usr/lib/cgi-bin/nagios2

    
    #Alias /nagios2/stylesheets /etc/nagios2/stylesheets
    Alias /nagios2 /usr/share/nagios2/htdocs
    # Enable this ScriptAlias if you want to enable the grouplist patch.
    # See http://apan.sourceforge.net/download.html for more info
    # It allows you to see a clickable list of all hostgroups in the
    # left pane of the Nagios web interface
    # XXX This is not tested for nagios 2.x use at your own peril
    #ScriptAlias /nagios2/side.html /usr/lib/cgi-bin/nagios2/grouplist.cgi
    <DirectoryMatch (/usr/share/nagios2/htdocs|/usr/lib/cgi-bin/nagios2)>
	Options FollowSymLinks
	DirectoryIndex index.html
	AllowOverride AuthConfig
	Order Allow,Deny
	Allow From All
	AuthName "Nagios Access"
	AuthType Basic
	AuthUserFile /etc/nagios2/htpasswd.users
	require valid-user
    </DirectoryMatch>
</VirtualHost>

Creiamo la Root Directory per questo sito con:

# mkdir  /var/www/nagios
# chown -R www-data:www-data /var/www/nagios/
# touch /var/www/nagios/index.html

la directory conterrà un file index.html vuoto, in questo file potremmo mettere o una pagina di benvenuto oppure un redirect alla directory contenente l'applicativo, a piacere.

Ora manca solo una cosa da fare: aggiungere l'utente per l'accesso a nagios (operazione obbligatoria, pena un errore di tipo 500 quando si tenta di accedere all'applicazione).

Per aggiungere l'utente usiamo il comando htpasswd:

# htpasswd  -c  /etc/nagios2/htpasswd.users nagiosadmin

alla richiesta di password, inseriamo una password a nostro piacimento.

Ora possiamo testare la configurazione, ma prima è necessario riavviare Apache per rendere effettive le modifiche che abbiamo effettuato:

# /etc/init.d/apache2 restart

Collegandosi alla pagina http://nagios.knio.it/nagios2/ ci verrà chiesto username/password per accedere a nagios, dopodiché ci verrà mostrata la schermata di default.

Nagios

Introduzione alla configurazione

La configurazione di nagios è situata, come da FHS in /etc/nagios2/. All'interno di questa directory sono presenti i seguenti file (e directory):

cgi.cfg
il file contiene la configurazione dell'interfaccia web di nagios (quindi i percorsi dove trovare i file di configurazione ed alcuni comportamenti base; la configurazione dei permessi degli utenti e perfino i suoni da riprodurre in caso di problemi)
commands.cfg
contiene la configurazione dei comandi eseguibili da nagios: check, notifiche ed altri
conf.d
una directory che ha lo scopo di raccogliere i file di configurazione di tutti i vari host monitorati da nagios
htpasswd.users
contiene (come abbiamo visto prima) le chiavi di accesso di tutti gli utenti che possono accedere all'interfaccia web di nagios (i permessi, per questi utenti, sono definiti in cgi.cfg)
nagios.cfg
contiene la configurazione vera e propria del demone di nagios, la configurazione di default è corretta nella maggior parte dei casi
resource.cfg
in questa guida non lo modificheremo
stylesheets
directory per inserire i fogli di stile personalizzati (in questa guida non li useremo)

Come gestire al meglio i file di configurazione

Anche se la struttura dei file di configurazione è semplice, ci vuole molto poco a renderla una vera e propria accozzaglia di file. Ci sono varie scuole di pensiero su come gestire i file.

La prima è quella di inserire, all'interno della directory conf.d/ un file per ogni host, raggruppando, poi, gli host tramite gli hostgroup. La tecnica è valida e funzionale, a meno che non ci si trovi a gestire un numero eccessivo di host.

La seconda tecnica, è quella di creare tante directory quanti sono i segmenti della rete, così da racchiudere i file di configurazione in directory meno popolate, così da rendere più facilmente individuabile un file.

Personalmente trovo più comodo gestire la prima, con la seguente convenzione:

  • ogni file ha la forma type-name.cfg dove type rappresenta la tipologia del file di configurazione (host per un server, switch per uno switch di rete, router per un router, e così via...) e dove name è il nome univoco associato alla macchina (e usato anche all'interno di Nagios).
  • i file contenenti i gruppi, le definizioni dei periodi e simili hanno una struttura type.cfg dove type può essere:
    • contacts: per le definizioni dei contatti
    • timeperiods: per le definizioni dei periodi
    • extinfo: per le definizioni delle informazioni aggiuntive
    • hostgroups: per la definizione dei gruppi di host
    • services: per la definizione dei gruppi di servizi

Un'accortezza da adottare, inoltre, quando si modifica un file di configurazione è quella di effettuare un check di correttezza tramite il comando:

# nagios -v /etc/nagios2/nagios.conf

In questo modo si eviteranno downtime e si sarà sicuri che nagios ripartirà senza problemi (almeno legati alla sintassi dei file di configurazione...).

Gli Host

Tramite gli host è possibile definire i PC, server, switch e tutte le altre apparecchiature presenti nella rete da monitorare. Saranno poi i servizi a determinare cosa monitorare effettivamente.

La definizione classica e minimale di un host è la seguente:

define host{
   use         generic-host
   host_name   serverino
   alias       Server di Produzione
   address     192.168.0.15
}

I parametri della definizione sono i seguenti:

use
permette di specificare un template da utilizzare all'interno del nostro host. L'utilizzo di un template permette di minimizzare i parametri necessari da passare ad un host. Il template che usiamo, per ora, è generic-host che è quello fornito di default in Debian. In seguito provvederemo a creare dei template che permetteranno uan suddivisione degli host in modo semplice ed immediato.
host_name
l'hostname dell'host. Deve essere univoco, in quanto viene utilizzato all'interno di Nagios come nome univoco di un host. è buona pratica utilizzare l'hostname della macchina, in quanto permetterà, in seguito, di identificarla più facilmente. In caso di switch od altri componenti conviene identificarli nel seguente modo: switch-dmz, firewall-dmz, etc.
alias
rappresenta il nome comune dell'host.
address
l'indirizzo IP dell'host. Deve essere inserito solo l'indirizzo Primario, e non una lista di indirizzi! Se si vogliono monitorare più indirizzi IP o più servizi legati a più indirizzi IP, sarà opportuno o definire un altro host (non molto corretto) oppure aggiungere servizi in cui viene indicato, come parametro, l'indirizzo IP secondario.

Oltre a quelli specificati è possibile aggiungere questi parametri (per quelli utilizzati nel template rimando al sottocapitolo dedicato):

parents <host_names>
permette di indicare, tramite un elenco di host separati da virgola, i "parenti" di quell'host (ad esempio switch, gateway, ecc). Utile per la rappresentazione grafica della struttura della rete
hostgroups <hostgroup_names>
permette di specificare i gruppi, sempre separati da virgola, a cui appartiene l'host.

Come convenzione per la creazione di un host creeremo un file col formato /etc/nagios2/conf.d/hosts/hostname.cfg dove hostname va sostituito con l'hostname dell'host definito.

I Servizi

I servizi vengono utilizzati per definire un controllo su un servizio presente su un determinato host. Possono essere associati ad un determinato host (utile per controlli specifici) oppure ad un hostgroup (utile per controlli generici o comunque monitoraggio di servizi standard).

Un servizio ha, normalmente, la seguente struttura:

define service{
   use                   generic-service
   host_name             localhost
   service_description   Disk Space
   check_command         check_all_disks!20%!10%
}

Dove vengono usati i seguenti parametri:

use <service-template>
indica il template da utilizzare. Il template contiene tutti i parametri necessari per la configurazione del servizio. In caso di necessità, comunque, è possibile sovrascrivere un parametro presente nel template semplicemente ridefinendolo all'interno del servizio.
host_name <hostname>
l'hostname specificato nella configurazione dell'host di cui si vuole monitorare il servizio
service_description <description>
la descrizione umana del servizio
check_command <command>
il comando da utilizzare per eseguire il controllo del servizio.

L'esempio sopra riportato associa il servizio ad un determinato host, ma è possibile associarlo ad un hostgroup, sostituendo la voce host_name con hostgroup_name.

Per i servizi verrà adottata la seguente convenzione:

  • se il servizio è dedicato ad un singolo host, viene inserito all'interno del file di configurazione dell'host
  • se il servizio è dedicato ad un hostgroup, invece, verrà inserito all'interno del file di definizione dell' hostgroup.

I Comandi

I comandi rappresentano i mattoni su cui costruire i check dei sistemi. Essi possono essere specifici (ad esempio il check di funzionamento di un server IMAP) o generici (come il test dell'apertura di una porta TCP).

I comandi base sono definiti in /etc/nagios2/commands.cfg, mentre quelli installati tramite i plugin (i pacchetti nagios-plugins*) sono contenuti in /etc/nagios-plugins/config/.

La sintassi per la definizione di un comando è la seguente:

define command{
   template      <templatename>
   name          <objectname>
   command_name  <commandname>
   command_line  <commandline>
}

Dove:

template <templatename>
permette di caricare un template (cioè un'altra definizione di comando da cui attingere i valori opzionali)
command_name <commandname>
il nome (univoco) del comando. Per convenzione, non potendo inserire spazi all'interno del nome, sostituiremo quest'ultimi con dei -.
command_line <commandline>
il percorso completo del comando (script o eseguibile) da lanciare, con gli eventuali parametri specificati.
Utilizzare quelli esistenti

Carpire il corretto utilizzo dei comandi può essere, a volte, un po' complesso. Per capire come utilizzare quelli definiti, possiamo adottare la seguente strategia:

  • identifichiamo il percorso completo del comando da eseguire. In questo esempio ci riferiremo ai comandi contenuti in /etc/nagios-plugins/config/http.cfg. Il path del comando che viene richiamato è /usr/lib/nagios/plugins/check_http.
  • visualizziamo l'output dell'help del comando:
# /usr/lib/nagios/plugins/check_http -h
check_http (nagios-plugins 1.4.5) 1.96
Copyright (c) 1999 Ethan Galstad <nagios@nagios.org>
Copyright (c) 1999-2006 Nagios Plugin Development Team
        <nagiosplug-devel@lists.sourceforge.net>

This plugin tests the HTTP service on the specified host. It can test
normal (http) and secure (https) servers, follow redirects, search for
strings and regular expressions, check connection times, and report on
certificate expiration times.


Usage: check_http -H <vhost> | -I <IP-address> [-u <uri>] [-p <port>]
       [-w <warn time>] [-c <critical time>] [-t <timeout>] [-L]
       [-a auth] [-f <ok | warn | critical | follow>] [-e <expect>]
       [-s string] [-l] [-r <regex> | -R <case-insensitive regex>] [-P string]
       [-m <min_pg_size>:<max_pg_size>] [-4|-6] [-N] [-M <age>] [-A string] [-k string]
NOTE: One or both of -H and -I must be specified

Options:
 -h, --help
    Print detailed help screen
 -V, --version
    Print version information
 -H, --hostname=ADDRESS
    Host name argument for servers using host headers (virtual host)
    Append a port to include it in the header (eg: example.com:5000)
 -I, --IP-address=ADDRESS
    IP address or name (use numeric address if possible to bypass DNS lookup).
 -p, --port=INTEGER
 Port number (default: 80)
 -4, --use-ipv4
    Use IPv4 connection
 -6, --use-ipv6
    Use IPv6 connection
 -S, --ssl
   Connect via SSL
 -C, --certificate=INTEGER
   Minimum number of days a certificate has to be valid.
   (when this option is used the url is not checked.)

 -e, --expect=STRING
    String to expect in first (status) line of server response (default:
HTTP/1.
    If specified skips all other status line logic (ex: 3xx, 4xx, 5xx processing)
 -s, --string=STRING
    String to expect in the content
 -u, --url=PATH
    URL to GET or POST (default: /)
 URL to GET or POST (default: /)
,-P, --post=STRING    URL encoded http POST data
 -N, --no-body
    Don't wait for document body: stop reading after headers.
    (Note that this still does an HTTP GET or POST, not a HEAD.)
 -M, --max-age=SECONDS
    Warn if document is more than SECONDS old. the number can also be of
    the form "10m" for minutes, "10h" for hours, or "10d" for days.
 -T, --content-type=STRING
    specify Content-Type header media type when POSTing

 -l, --linespan
    Allow regex to span newlines (must precede -r or -R)
 -r, --regex, --ereg=STRING
    Search page for regex STRING
 -R, --eregi=STRING
    Search page for case-insensitive regex STRING
 --invert-regex
    Return CRITICAL if found, OK if not

 -a, --authorization=AUTH_PAIR
    Username:password on sites with basic authentication
 -A, --useragent=STRING
    String to be sent in http header as "User Agent"
 -k, --header=STRING
     Any other tags to be sent in http header. Use multiple times for additional headers
 -L, --link=URL
    Wrap output in HTML link (obsoleted by urlize)
 -f, --onredirect=<ok|warning|critical|follow>
    How to handle redirected pages
 -m, --pagesize=INTEGER<:INTEGER>
    Minimum page size required (bytes) : Maximum page size required (bytes)
 -w, --warning=DOUBLE
    Response time to result in warning status (seconds)
 -c, --critical=DOUBLE
    Response time to result in critical status (seconds)
 -t, --timeout=INTEGER
    Seconds before connection times out (default: 10)
 -v, --verbose
    Show details for command-line debugging (Nagios may truncate output)
Notes: This plugin will attempt to open an HTTP connection with the host.
 Successful connects return STATE_OK, refusals and timeouts return STATE_CRITICAL
 other errors return STATE_UNKNOWN.  Successful connects, but incorrect reponse
 messages from the host result in STATE_WARNING return values.  If you are
 checking a virtual server that uses 'host headers' you must supply the FQDN
 (fully qualified domain name) as the [host_name] argument.
 This plugin can also check whether an SSL enabled web server is able to
 serve content (optionally within a specified time) or whether the X509
 certificate is still valid for the specified number of days.
Examples: CHECK CONTENT: check_http -w 5 -c 10 --ssl www.verisign.com

 When the 'www.verisign.com' server returns its content within 5 seconds,
 a STATE_OK will be returned. When the server returns its content but exceeds
 the 5-second threshold, a STATE_WARNING will be returned. When an error occurs,
 a STATE_CRITICAL will be returned.

 CHECK CERTIFICATE: check_http www.verisign.com -C 14

 When the certificate of 'www.verisign.com' is valid for more than 14 days,
 a STATE_OK is returned. When the certificate is still valid, but for less than
 14 days, a STATE_WARNING is returned. A STATE_CRITICAL will be returned when
 the certificate is expired.


Send email to nagios-users@lists.sourceforge.net if you have questions
regarding use of this software. To submit patches or suggest improvements,
send email to nagiosplug-devel@lists.sourceforge.net
  • confrontiamo la definizione del comando con l'help appena ottenuto:
define command{
   command_name    check_http
   command_line    /usr/lib/nagios/plugins/check_http -H $HOSTADDRESS$ -I $HOSTADDRESS$
}

in questo caso, si occuperà di controllare che ci sia un webserver funzionante sulla porta 80 dell'host di cui stiamo eseguendo il check ($HOSTADDRESS$ e $HOSTADDRESS$ sono delle Macro. Per approfondimenti consultare il paragrafo Le Macro).

Un altro esempio potrebbe essere il comando check_disk, che ha la seguente definizione:

define command{
        command_name    check_disk
        command_line    /usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -
p $ARG3$
}

In questo caso si tratta di un controllo locale (quindi viene effettuato sulla macchina su è installato Nagios), infatti non sono presenti le macro viste prima, ma al loro posto sono presenti $ARG1$ $ARG2$ e $ARG3$, che rappresentano i parametri passati, all'interno della configurazione dei servizi. In questo caso, la prima opzione (-w) imposta il livello di warning, la seconda (-c) imposta la soglia critica e il terzo (-p) indica la partizione su cui effettuare il controllo.

Quando andremo a richiamare il comando all'interno della definizione del servizio, lo faremo in questo modo:

define service{
        use                             generic-service
        host_name                       localhost
        service_description             Disk Space on /dev/hda1
        check_command                   check_all_disks!20%!10%!"/dev/hda1"
}

Com'è facilmente intuibile, il servizio controllerà la partizione /dev/hda1 ed andrà in stato di warning quando ci sarà meno del 20% di spazio disponibile, ed in stato di errore critico quando ce ne sarà meno del 10%.

I parametri sono separati da un ! e vanno indicati nell'ordine corretto ($ARG1$ indica il primo parametri, e così via...)!

Creare nuovi comandi

Per semplicità (e convenzione di questa guida) i comandi personalizzati verranno salvati in /etc/nagios2/conf.d/commands.cfg in modo da non modificare il file di configurazione di default di Nagios (cosa che tornerà utile in caso di aggiornamenti e/o migrazioni).

I Gruppi di Host (hostgroup)

Un hostgroup è semplicemente un sistema per raggruppare più host in base a delle caratteristiche comuni (che spaziano dall'appartenenza ad una stessa sottorete all'erogazione di uno stesso tipo di servizio, ...).

Una definizione standard di hostgroup è la seguente:

define hostgroup {
   hostgroup_name   http-servers
   alias            HTTP servers
   members          hostname1, hostname2
}

Con i seguenti parametri:

hostgroup_name <hostgroupname>
il nome (univoco e senza spazi) dell'hostgroup. Verrà utilizzato all'interno dei file di configurazione di nagios per fare riferimento a questo gruppo di host
alias <alias>
un nome comprensibile (una breve descrizione) del gruppo
members <hostname1, hostname2>
i membri (members) appartenenti al gruppo. members e hostgroups (visto in precedenza all'interno della sezione Gli Host hanno la stessa funzione, ma in più permettono di decidere come gestire l'assegnazione: tramite members viene inserita la lista degli host che fanno parte del gruppo, quindi l'associazione avviene all'interno del file che definisce l'hostgroup; tramite hostgroups l'associazione avviene all'interno del file di configurazione dell'host, in cui vengono indicati tutti i gruppi a cui appartiene. Personalmente ritengo più comodo il secondo metodo in quanto, in caso di rimozione di un host, col primo metodo bisognerebbe modificare tutti i file dei gruppi di cui l'host era membro, pena l'impossibilità di far ripartire nagios; inoltre, specificando tutti i gruppi a cui appartiene un host all'interno del proprio file di configurazione permette di avere sotto controllo l'appartenenza di uno specifico host ad un gruppo.

Per gli hostgroup si adotta la convenzione di inserirli nella directory /etc/nagios2/conf.d/hostgroups/, specificando per ogni gruppo un file con la sintassi hostgroupname.cfg. I servizi dedicati a quell'hostgroup andranno, a loro volta, inseriti nel file di configurazione del gruppo di host, così come si è fatto per i servizi di un singolo host.

I Gruppi di Servizi

I Contatti

I Timeperiod

Le notifiche

Notifiche via e-mail
Notifiche via SMS (vodafone)
Notifiche via SMS (gateway)

Varie

Nagios Checker

Nagios Checker (Home Page) è una comoda estensione per Firefox che permette di monitorare, direttamente dal browser, lo stato delle nostre macchine. In caso di problemi verrà mostrato un avviso (in rosso) e verrà riprodotto un suono di allarme. Tramite l'estensione sarà possibile, inoltre, accedere direttamente alla pagina dell'host (o del servizio) che danno problemi per approfondire. Un must!

FAQ

Come posso aggiungere un altro utente a Nagios?

Per aggiungere un nuovo utente è necessario effettuare due passi:

1) creazione dell'account all'interno del file /etc/nagios2/htpasswd.users

# htpasswd /etc/nagios2/htpasswd.users nomeutente

2) Inserire l'utente appena creato all'interno della configurazione di Nagios. Per fare questo bisogna modificare il file /etc/nagios2/cgi.cfg aggiungendo l'utente appena creato alle seguenti direttive (in base ai permessi che si vogliono dare al nuovo utente):

authorized_for_system_information=nagiosadmin
authorized_for_configuration_information=nagiosadmin
authorized_for_system_commands=nagiosadmin
authorized_for_all_services=nagiosadmin
authorized_for_all_hosts=nagiosadmin
#authorized_for_all_services=nagiosadmin,guest
#authorized_for_all_hosts=nagiosadmin,guest
authorized_for_all_service_commands=nagiosadmin
authorized_for_all_host_commands=nagiosadmin

Dopo le varie modifiche è necessario ricaricare la configurazione di nagios con un:

# /etc/init.d/nagios2 reload




Guida scritta da: MaXeR Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized