Munin: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
m (template Versioni compatibili (da template Autori e discussione))
 
(30 versioni intermedie di 11 utenti non mostrate)
Riga 1: Riga 1:
==Il superdemone inetd==
{{Versioni compatibili|Squeeze|Wheezy|Jessie}}
==Introduzione==
Munin è un sistema di monitoraggio di sistema avanzato, facilmente installabile e configurabile che offre una vasta gamma di monitor e supporta la raccolta di informazioni da più macchine.<br/>
(Ringrazio Keltik per avermelo involontariamente mostrato).


===Introduzione===
In questa guida vedremo come installarlo, configurandolo per monitorare due macchine: quella su cui è installato il server ed un desktop (in questo caso i dati verranno raccolti solo quando questa macchina sarà accesa).
Inetd ('''Internet Super-Server''') � un demone che ascolta sulle porte specificate nel suo file di configurazione e fa avviare il relativo servizio nel momento in cui viene fatta una richiesta. Esso controlla tramite dei wrappers i file '''/etc/hosts.allow''' e '''/etc/hosts.deny''' per verificare che la connessione sia consentita.


Viene chiamato superdemone proprio per questa sua funzione di controllo di altri demoni.
==Installazione==
Il programma è composto da:
; munin-node : il Client, che gestisce la raccolta di informazioni su una determinata macchina;
; munin : il Server, che si occupa di elaborare i dati, catalogarli, creare i grafici e le pagine HTML.


Il vantaggio di usarlo � di ottimizzare le risorse del sistema, avviando il demone che gestisce un determinato servizio solo quando ci sono effettive richieste.
Per installare il Server (necessario solo sulla macchina che raccoglierà i dati):
<pre>
# apt-get install munin munin-java-plugins munin-libvirt-plugins munin-plugins-extra apache2
</pre>


Sebbene possa essere usato per gestire quasi tutti i servizi � consigliabile farlo solo per quelli a basso e occasionale traffico.
Per installare il client (su tutte le macchine che vogliamo monitorare):
<pre>
# apt-get install munin-node munin-java-plugins munin-libvirt-plugins munin-plugins-extra
</pre>


===Installazione===
Durante l'installazione non è richiesto l'intervento dell'utente.
Se per qualche motivo il demone inetd non dovrebbe essere installato � sufficiente installarlo tramite APT. Inoltre consiglio l'installazione dei TCP wrappers:
<pre>$: apt-get install netkit-inetd tcpd</pre>


===Configurazine===
==Configurazione==
Per prima cosa � necessario modificare i permessi al file '''/etc/inetd.conf''' in modo che solo root abbia accesso:
===Node===
<pre>$: chmod 600 /etc/inetd.conf</pre>
La configurazione dei Client (o ''nodi'') è estremamente semplice ed automatizzata: è presente un comando che controlla la macchina alla ricerca di servizi monitorabili attraverso delle regole predefinite. È d'obbligo evidenziare il numero di monitor presenti, che spaziano dalla statistiche di sistema ''base'' (CPU, Memoria, [[Swap]]) fino a quelle dei servizi (MySql, Postfix, NFS, Apache, ecc).


Ogni riga di '''/etc/inetd.conf''' corrisponde ad un servizio che viene gestito da inetd. Se � commentata con un # il servizio non viene avviato e inetd non mette la relativa porta in listening. Esempio:
Su ogni ''nodo'' provvediamo a lanciare lo strumento di configurazione automatico, così da rilevare tutti i servizi/parametri di cui è possibile tenere traccia:
<pre>
# munin-node-configure
</pre>
il processo può impiegare un bel po' di tempo (soprattutto se la macchina è lenta); per controllare l'avanzamento del processo, consiglio di abilitare il debug:
<pre>
# munin-node-configure --debug
</pre>


<pre># These are standard services. 
al termine della procedura di riconoscimento verrà mostrata una tabella riassuntiva, simile alla seguente:
#
<pre>
#ftp    stream  tcp   nowait root /usr/sbin/tcpd in.ftpd -l -a  
Plugin                    | Used | Extra information
#telnet stream tcp   nowait root /usr/sbin/tcpd in.telnetd
------                    | ---- | -----------------
#
acpi                      | no  |
# Shell, login, exec, comsat and talk are BSD protocols.  
apache_accesses            | no  |
#  
apache_processes          | no  |
#shell stream tcp    nowait root    /usr/sbin/tcpd in.rshd  
apache_volume              | no  |
#login stream tcp    nowait root    /usr/sbin/tcpd in.rlogind  
apt                        | no  |
#exec stream   tcp    nowait root    /usr/sbin/tcpd in.rexecd  
apt_all                    | no  |
#comsat dgram   udp    wait    root    /usr/sbin/tcpd in.comsat  
courier_mta_mailqueue      | no  |
#talk   dgram   udp    wait    root    /usr/sbin/tcpd  in.talkd  
courier_mta_mailstats      | no  |
#ntalk   dgram  udp    wait    root    /usr/sbin/tcpd  in.ntalkd  
courier_mta_mailvolume    | no  |
#dtalk  stream  tcp    waut    nobody  /usr/sbin/tcpd  in.dtalkd</pre>
cps_                      | no   |
cpu                        | yes |
cupsys_pages              | yes |
df                        | yes |
df_abs                    | no  |
df_inode                  | yes |
entropy                    | yes |
exim_mailqueue            | no   |
exim_mailstats            | no  |
forks                      | yes |
fw_conntrack              | no  |
fw_forwarded_local        | no  |
fw_packets                | no  |
hddtemp_smartctl          | yes |
if_                        | yes | eth0
if_err_                    | yes  | eth0
interrupts                | yes |
iostat                    | yes |
ip_                        | no  |
ircu                      | no  |
irqstats                  | yes |
load                      | yes |
loggrep                    | no  |
memory                    | yes |
multips                    | no  |
munin_graph                | no  |
munin_update              | no  |
mysql_bytes                | yes |
mysql_isam_space_          | no  |
mysql_queries              | yes |
mysql_slowqueries          | yes |
mysql_threads              | yes |
netstat                    | yes |
nfs_client                | yes |
nfsd                      | yes |
ntp_                      | yes | mathfox_xs4all_nl
ntp_states                | no   |
open_files                | yes |
open_inodes                | yes |
ping_                      | no  |
port_                      | no  |
postfix_mailqueue          | yes |
postfix_mailstats          | no   |
postfix_mailvolume        | no  |
processes                  | yes |
ps_                        | no  |
psu_                      | no  |
sendmail_mailqueue        | no  |
sendmail_mailstats        | no  |
sendmail_mailtraffic      | no  |
sensors_                  | no  |
smart_                    | yes | hda
squid_cache                | no   |
squid_icp                  | no   |
squid_requests            | no  |
squid_traffic              | no  |
swap                      | yes |
sybase_space              | no  |
uptime                    | no  |
vlan_                      | no  |
vlan_inetuse_              | no  |
vlan_linkuse_              | no   |
vmstat                    | yes |
</pre>


Il formato tipico di ogni riga � il seguente:
Per le macchine diverse da quella che ospita il server, bisogna modificare le impostazioni di accesso per consentire le connessioni da parte di quest'ultimo. Per fare questo apriamo con un editor il file <code>'''/etc/munin/munin-node.conf'''</code>, ed aggiungiamo la seguente riga alla fine del file:
<pre>
allow ^192\.168\.0\.1$
</pre>
Il commento poco sopra il punto in cui abbiamo inserito questa stringa ci ricorda che si tratta di espressioni regolari, di conseguenza è necessario anteporre un backslash prima dei punti.


<pre>service type protocol wait user server cmdline</pre>
Per applicare le modifica apportate, riavviamo <code>munin-node</code>:
<pre>
# /etc/init.d/munin-node restart
</pre>


====Moduli====
Munin sfrutta un'architettura a plug-in per monitorare le varie componenti di sistema. Come abbiamo visto nel paragrafo precedente (vedi l'output di <code>munin-node-configure</code>) ce ne sono a disposizione moltissimi.


Un esempio pratico di una riga presente in '''/etc/inetd.conf''':
Munin-node altro non è che uno script che si preoccupa di lanciare i vari plug-in presenti all'interno della cartella <code>'''/etc/munin/plugins'''</code>. Notiamo subito che all'interno di questa directory non troviamo i veri e propri moduli, ma del link simbolici ad essi:
<pre>ftp stream tcp nowait root /usr/sbin/in.ftpd �l
<pre>
# ls -l /etc/munin/plugins |more
totale 0
lrwxrwxrwx  1 root root 28 2005-07-01 01:06 cpu -> /usr/share/munin/plugins/cpu
lrwxrwxrwx  1 root root 27 2005-07-01 01:06 df -> /usr/share/munin/plugins/df
lrwxrwxrwx  1 root root 33 2005-07-01 01:06 df_inode -> /usr/share/munin/plugins/df_inode
lrwxrwxrwx  1 root root 32 2005-07-01 01:06 entropy -> /usr/share/munin/plugins/entropy
[...]
</pre>
Quindi, per abilitare e/o disabilitare i moduli, è sufficiente creare/cancellare i link simbolici a <code>/usr/share/munin/plugins</code> presenti in <code>/etc/munin/plugins</code>.


ftp: nome del servizio
Se ad esempio voglio abilitare i moduli relativi ad '''apt''', sarà sufficiente il comando:
stream: indica il tipo
<pre>
tcp: indica il protocollo
# ln -s /usr/share/munin/plugins/apt* /etc/munin/plugins
nowait: indica se deve attendere
</pre>
user: indica l�utente che ha il privilegio di accesso
e, dopo aver creato i link:
server: indica dove si trova il programma
<pre>
cmdline:indica il nome dell�eseguibile e eventuali flag</pre>
# /etc/init.d/munin-node restart
</pre>


Inoltre inetd si appoggia su un altro file di configurazione dei servizi:
Nel caso si voglia testare l'effettivo funzionamento di un plugin, si può sfruttare il comando <code>munin-run</code> che lancia lo script coi permessi effettivi con cui verrà richiamato da munin.
Per esempio, si può testare il corretto funzionamento del plugin <code>postfix_mailstats</code> con:
<pre>
# munin-run postfix_mailstats
</pre>
Il comando, in questo caso, potrebbe dare errore (o restituire un valore pari a <code>U</code>) per via dei permessi insufficienti: è necessario essere root per poter accedere allo spool di posta e 'contare' i messaggi presenti. Per ovviare a questo problema è sufficiente modificare il file <code>/etc/munin/plugin-conf.d/plugins.conf</code> aggiungendo la seguente riga:
<pre>
[postfix_mailstats]
user root
</pre>
che indica, a munin, di eseguire lo script coi privilegi di root.


<pre>/etc/services
====Apache, un caso particolare====
File che assegna un nome di servizio alla relativa porta.
Parliamo un po' più dettagliatamente dei moduli relativi ad Apache: per abilitarli, infatti, non è sufficiente creare i link simbolici, ma abbiamo bisogno anche di metter mano alla configurazione di Apache.
Viene usato anche da altri programmi come file di riferimento.</pre>


Se si vogliono utilizzare i tcpwrapper per limitare l'accesso al servizio la riga sopra diventa:
Per monitorare Apache, Munin ha bisogno che <code>mod_status</code> venga caricato da httpd con la direttiva <code>ExtendedStatus On</code>. In Debian <code>mod_status</code> per Apache viene caricato di default, per cui dobbiamo solo preoccuparci di fare un piccolo aggiustamento alla sezione che lo riguarda.
<pre>ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd �l</pre>


Nelle distribuzioni Linux, solitamente inetd � gi� configurato per supportare i tcp wrappers.
Ecco come dobbiamo impostare in <code>httpd.conf</code> la sezione di <code>mod_status</code>:
<pre>
<IfModule mod_status.c>
  ExtendedStatus On
  <Location /server-status>
      SetHandler server-status
  </Location>
</IfModule>
</pre>
In questo modo munin può interrogare Apache direttamente tramite il protocollo HTTP.


===TCP wrappers===
Per verificare che <code>mod_status</code> sia effettivamente in funzione è sufficiente puntare il nostro browser all'indirizzo http://localhost/server-status.
I tcp wrapper '''TCPD''', sviluppati dall'olandese Wietse Venema, sono un layer software che permette il controllo e il filtro degli accessi a servizi del sistema, tipicamente gestiti con inetd.


In pratica da una configurazione:
{{box|Nota sulla sicurezza|È bene aggiungere alcune istruzioni relative alla sicurezza nella nostra configurazione di <code>mod_status</code>, in modo da renderlo accessibile unicamente attraverso il nostro indirizzo IP locale (127.0.0.1). per fare questo possiamo inserire all'interno dei tag <code><location></code> e <code></location></code>, subito al di sotto di <code>SetHandler server-status</code> queste istruzioni:
<pre>
Order Deny,Allow
    Deny from all
    Allow from 127.0.0.1
</pre>}}
Riavviamo Apache:
<pre>
# apachectl graceful
</pre>
e munin-node:
<pre>
# /etc/init-d/munin-node restart
</pre>


<pre>client -----> inetd -----> servizio</pre>
===Server===
La configurazione di default del server è più che sufficiente per un utilizzo normale di questo. Utilizza la directory <code>'''/var/www/munin/'''</code>, in cui inserisce tutte le pagine relative ai computer da monitorare. Questa directory, quindi, dovrà essere accessibile in scrittura dall'utente '''munin''', ed in lettura dall'utente '''www-data''' (supponendo l'utilizzo di Apache come webserver per visualizzare le statistiche). In particolare controlliamo che la directory <code>'''/var/www'''</code> abbia i permessi di esecuzione per l'utente ''nobody''.


Si passa ad una configurazione:
==== Debian Squeeze ====
A partire da Debian Squeeze la configurazione di Munin richiede qualche passaggio aggiuntivo.
<br/>
Innanzitutto dobbiamo tenere a mente che la directory utilizzata è diventata <code>'''/var/cache/munin/www'''</code> e che deve avere i corretti permessi:
<pre>
# chown -R munin:www-data /var/cache/munin/www/
</pre>
Se intendiamo visualizzare i grafici di Munin da una macchina diversa da localhost dobbiamo anche modificare il file:
<pre>
# nano /etc/munin/apache.conf
</pre>
e cambiare la sezione
<pre>
Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
        Order allow,deny
        Allow from localhost 127.0.0.0/8 ::1
</pre>
in qualcosa di simile a:
<pre>
Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
        Order allow,deny
        Allow from localhost 127.0.0.0/8 ::1
        Allow from 192.168.1.0/24
</pre>
dove ovviamente <code>192.168.1.0</code> corrisponde al nostro indirizzo di rete.<br/>
Ricordarsi di eseguire:
<pre># /etc/init.d/apache reload</pre>
per rendere effettive le modifiche.


<pre>client -----> inetd -----> TCPD -----> servizio</pre>
==== Debian Jessie ====
La versione di Apache è la 2.4.x e il controllo degli accessi Rule-Based prevede una configurazione differente.


Nella nuova configurazione i tcpwrappers possono limitare l'accesso al servizio secondo criteri configurabili ed hanno funzionalit� anti-spoofing e anti tcp seguence guessing. La configurazione dei tcp wrappers si fa essenzialmente in due file.
<pre>
Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
  Require all granted
    Require ip 192.168.1.0/24
    ..........
</Directory>
</pre>
vedere anche: [[Installare un ambiente LAMP: Linux, Apache2, SSL, MySQL, PHP5]] e [[Apache2: proteggere directory mediante autenticazione]]


Questo file permette di specificare quali servizi abilitare e da quali indirizzi IP:
====Aggiunta di Client====
<pre>/etc/hosts.allow</pre>
La configurazione del server è gestita tramite un file: <code>'''/etc/munin/munin.conf'''</code>.


Questo file permette di specificare come limitare l'accesso a specifici servizi:
La sezione che a noi interessa è l'ultima, dove vengono raccolti i dati dei ''nodi'' da monitorare. Ogni blocco rappresentate un ''nodo'', nel file di configurazione, ha la seguente struttura:
<pre>/etc/hosts.deny</pre>
<pre>
[nome_del_nodo]
    address <indirizzo_del_nodo>
    use_node_name <yes|no>
</pre>


===Comandi utili===
I parametri e le opzioni descritte hanno il seguente significato:
Per avviare, riavviare, fermare il servizio inetd:
; <code>nome_del_modulo</code> : indica il nome con cui verrà rappresentato il ''nodo'' (solo se <code>use_node_name</code> è <code>yes</code>). Munin raccoglie i nodi per domini di secondo livello, in una struttura ad albero.
<pre>$: /etc/rc.d/init.d/inetd start/stop/restart</pre>
; <code>address <indirizzo_del_nodo></code> : indica l'indirizzo (IP o URL) tramite il quale raggiungere il ''nodo''.


===Configurazioni utili===
Riporto un esempio di configurazione per il monitoraggio di due macchine:
Nega l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
<pre>
<pre>File da applicare: /etc/hosts.deny
[spirit.knio.it]
ALL:ALL@ALL,PARANOID</pre>
    address 127.0.0.1
    use_node_name yes


Consente l'accesso a tutti i client e controlla che ip - nome.host corrispondano:
[maxer.knio.it]
<pre>File da applicare: /etc/hosts.allow
    address 192.168.0.2
ALL: LOCAL 192.168.1.0/255.255.255.0</pre>
    use_node_name yes
</pre>


Permette l'accesso SSH all'host prova.it corrispondente all'IP 10.0.0.1
I dati contenuti in <code>'''/var/www/munin'''</code> sono aggiornati tramite il cron <code>'''/etc/cron.d/munin'''</code>, esattamente ogni 5 minuti.
<pre>File da applicare: /etc/hosts.allow
sshd: 10.0.0.1 prova.it</pre>


Manda una mail all'indirizzo specificato admin_mail ogni qualvolta qualcuno si connette attraverso il servizio telnet, indicando l'indirizzo del client (%a) e l'utente (%u), la lista di questi parametri � contenuta nella man page hosts_access.
== Autenticazione ==
<pre>File da applicare: /etc/hosts.allow
L'unico problema di Munin è che le nostre statistiche sono visibili a tutti. Occorre quindi prendere qualche precauzione.
in.telnetd : ALL@ALL : spawn ( /bin/mail -s "Connessione telnet da: %a %u" admin_mail ) & </pre>
<br/>
Abilitiamo innanzitutto il modulo <code>auth_digest</code> di Apache, per gestire le Digest Authentication, un metodo più sicuro che evita di trasmettere in chiaro la password:
<pre>
# a2enmod auth_digest
</pre>
Quindi ricarichiamo la configurazione di Apache:
<pre>
# /etc/init.d/apache2 force-reload
</pre>
Ora che Apache può gestire un'autenticazione sicura dobbiamo impostare un utente e una password per Munin:
<pre>
# htdigest -c /var/cache/munin/www/.htpasswd munin munin
</pre>
Ci verrà richiesta una password per l'utente "munin" appena creato; digitiamola due volte per conferma.<br/>
A questo punto non ci resta che modificare il file che definisce il Virtual Host di Apache per Munin, abilitando l'autenticazione digest:
<pre>
# nano /etc/munin/apache.conf
</pre>
e aggiungendo le righe seguenti tra i TAG <code><Directory />....</Directory></code>:
<pre>
<Directory />
      ...
     
      #Autenticazione
      AuthType Digest
      AuthName "munin"
      AuthUserFile  /var/www/munin/.htpasswd
      require valid-user
</Directory>
</pre>
Infine controlliamo l'attuale configurazione di Apache e riavviamolo:
<pre>
# apache2ctl -t
Syntax OK
# /etc/init.d/apache2 force-reload
</pre>


==Da inetd a Xinetd==
==Conclusioni==
===Differenze===
Munin, come visto, è uno strumento veramente utile, sia per la sua facilità di installazione, sia per il vasto numero di dati che è capace di monitorare. Le sue funzionalità, inoltre, sono ampliabili tramite plugin, così da poter adattare al meglio il servizio alle proprie esigenze.
A differenza del precedessore, xinetd (e'''x'''tended inetd):


:*Limita o regola l'accesso a determinati servizi senza ricorrere al Tcp Wrapper;
==Bookmark==
:*Offre un sistema di logging indipendente da syslog;
[http://munin-monitoring.org/ Home Page del progetto]
:*Permette di limitare l'accesso ai servizi in determinate ore della giornata;
<br/>
:*Supporta il protocollo Ipv6;
<br/>
:*Utilizza vari meccanismi che mitigano l'impatto di un attacco DOS.


===File di configurazione===
La configurazione del demone e dei servizi pu essere suddivisa in pi file non compatibili con i vecchi file di configurazione del demone inetd. Le directory contenenti i file di configurazione sono leggermente cambiate:
<pre>/etc/xinetd.conf
File di configurazione del demone


/etc/xinetd.d/*
{{Autori
Directory che contiene i singoli file dei servizi offerti da xinetd</pre>
|Autore = [[Utente:MaXeR|MaXeR]]
|Estesa_da =
:[[Utente:Ferdybassi|Ferdybassi]] 20:55, 4 apr 2011 (CEST)
|Verificata_da=
:[[Utente:porkyhttp|porkyhttp]] 17:04, 06 mag 2012 (CEST)
:People 21:04, 05 mag 2012 (CEST)
:[[Utente:Ferdybassi|Ferdybassi]] 16:19, 21 mag 2012 (CEST)
:[[Utente:nydebianized|nydebianized]] 07:12, 12 set 2015 (CEST)
|Numero_revisori=4
}}


Il file di configurazione di xinetd � un file di testo che indica i servizi gestiti da xinetd. Contiene delle sezioni, ognuna delle quali identifica un servizio, con la seguente sintassi:
[[Categoria:Monitoraggio]]
<pre>service service_name
{
    attribute assign_op [value] [value] [...]
    [...]
}</pre>
 
Dove i seguenti attributi indicano:
:* '''service_name'''  � l�indicazione di un servizio gestito da xinetd;
:* '''attribute'''  indica un attributo relativo al servizio service_name;
:* '''assign_op'''  � un operatore di assegnamento, e pu� essere = (specifica l�unico valore dell�attributo), += (aggiunge un valore all�attributo) o -= (rimuove un valore dall�attributo).
 
===Esempi di configurazione di Xinetd===
Di seguito sono riportati alcuni esempi pratici e semplici di un file di configurazione '''/etc/xinetd.conf''':
<pre>service shell
          {
                socket_type        = stream
                wait                = no
                user                = root
                instances          = UNLIMITED
                server              = /usr/etc/in.rshd
                log_on_success      += HOST RECORD
          }
 
service ftp                                                             
          {
                socket_type        = stream
                wait                = no
                nice                = 10
                user                = root
                server              = /usr/etc/in.ftpd
                server_args        = -l
                instances          = 4
                log_on_success      += DURATION HOST USERID
                access_times        = 2:00-9:00 12:00-24:00
          }</pre>
 
Per una guida dettagliata di ogni singolo parametro � possibile consultare il '''man''' una volta installato xinetd. Xinetd � un demone molto flessibile e tramite il suo file di configurazione � possibile specificare decine e decine di opzioni.
 
===Opzioni di Xinetd===
Le opzioni che possono essere utilizzate per la modalit� di funzionamento di xinetd sono le seguenti:
:* '''-d''' abilita la modalit� di debug;
:* '''-syslog syslog_facility''' imposta la facility relativa al system log44 secondo quanto specificato da syslog_facility;
:* '''-filelog logfile'''' indica di redirigere il log degli eventi di xinetd nel file logfile;
:* '''-f config_file''' indica il file di configurazione da considerare secondo quanto specificato da config_file (default /etc/xinetd.conf);
:* '''-pidfile pid_file''' indica di scrivere nel file pid_file il PID del processo lanciato;
:* '''-stayalive''' indica di rimanere in esecuzione anche se nel file di configurazione non � stato specificato nessun servizio;
:* '''-limit proc_limit''' imposta il numero massimo di processi che xinetd pu� lanciare secondo quanto specificato da proc_limit;
:* '''-logprocs limit''' imposta il numero massimo di daemon che possono essere lanciati in esecuzione per ogni utente, secondo quanto specificato da limit;
:* '''-version''' visualizza la versione di xinetd;
:* '''-inetd_compat''' indica di considerare anche il file di configurazione '''/etc/inetd.conf''' subito dopo '''/etc/xinetd.conf''';
:* '''-cc interval''' indica di controllare un controllo periodico del proprio stato ogni interval secondi;
 
Il processo xinetd effettua le operazioni elencate in corrsipondenza dei seguenti segnali:
 
:*'''SIGHUP''' rilegge il file di configurazione e termina l�esecuzione dei daemon relativi a servizi non pi� attivi (secondo quanto specificato nel file di configurazione);
:* '''SIGQUIT''' termina la sua esecuzione;
:* '''SIGTERM''' termina l�esecuzione di tutti i daemon prima di terminare anche la sua esecuzione;
:* '''SIGUSR1''' scrive il suo stato interno (dump) nel file '''/var/run/xinetd.dump''';
:* '''SIGIOT''' controlla la consistenza delle sue strutture dati, visualizzando quindi un messaggio relativo.
 
Autore: [[Utente:Net deity|Net deity]]
[[Categoria:Server]][[Categoria:Networking]]

Versione attuale delle 09:11, 7 lug 2019

Edit-clear-history.png Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.

Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.


Debian-swirl.png Versioni Compatibili

Debian 6 "squeeze"
Debian 7 "wheezy"
Debian 8 "jessie"

Introduzione

Munin è un sistema di monitoraggio di sistema avanzato, facilmente installabile e configurabile che offre una vasta gamma di monitor e supporta la raccolta di informazioni da più macchine.
(Ringrazio Keltik per avermelo involontariamente mostrato).

In questa guida vedremo come installarlo, configurandolo per monitorare due macchine: quella su cui è installato il server ed un desktop (in questo caso i dati verranno raccolti solo quando questa macchina sarà accesa).

Installazione

Il programma è composto da:

munin-node
il Client, che gestisce la raccolta di informazioni su una determinata macchina;
munin
il Server, che si occupa di elaborare i dati, catalogarli, creare i grafici e le pagine HTML.

Per installare il Server (necessario solo sulla macchina che raccoglierà i dati): 

# apt-get install munin munin-java-plugins munin-libvirt-plugins munin-plugins-extra apache2

Per installare il client (su tutte le macchine che vogliamo monitorare): 

# apt-get install munin-node munin-java-plugins munin-libvirt-plugins munin-plugins-extra

Durante l'installazione non è richiesto l'intervento dell'utente.

Configurazione

Node

La configurazione dei Client (o nodi) è estremamente semplice ed automatizzata: è presente un comando che controlla la macchina alla ricerca di servizi monitorabili attraverso delle regole predefinite. È d'obbligo evidenziare il numero di monitor presenti, che spaziano dalla statistiche di sistema base (CPU, Memoria, Swap) fino a quelle dei servizi (MySql, Postfix, NFS, Apache, ecc).

Su ogni nodo provvediamo a lanciare lo strumento di configurazione automatico, così da rilevare tutti i servizi/parametri di cui è possibile tenere traccia: 

# munin-node-configure

il processo può impiegare un bel po' di tempo (soprattutto se la macchina è lenta); per controllare l'avanzamento del processo, consiglio di abilitare il debug: 

# munin-node-configure --debug

al termine della procedura di riconoscimento verrà mostrata una tabella riassuntiva, simile alla seguente: 

Plugin                     | Used | Extra information
------                     | ---- | -----------------
acpi                       | no   |
apache_accesses            | no   |
apache_processes           | no   |
apache_volume              | no   |
apt                        | no   |
apt_all                    | no   |
courier_mta_mailqueue      | no   |
courier_mta_mailstats      | no   |
courier_mta_mailvolume     | no   |
cps_                       | no   |
cpu                        | yes  |
cupsys_pages               | yes  |
df                         | yes  |
df_abs                     | no   |
df_inode                   | yes  |
entropy                    | yes  |
exim_mailqueue             | no   |
exim_mailstats             | no   |
forks                      | yes  |
fw_conntrack               | no   |
fw_forwarded_local         | no   |
fw_packets                 | no   |
hddtemp_smartctl           | yes  |
if_                        | yes  | eth0
if_err_                    | yes  | eth0
interrupts                 | yes  |
iostat                     | yes  |
ip_                        | no   |
ircu                       | no   |
irqstats                   | yes  |
load                       | yes  |
loggrep                    | no   |
memory                     | yes  |
multips                    | no   |
munin_graph                | no   |
munin_update               | no   |
mysql_bytes                | yes  |
mysql_isam_space_          | no   |
mysql_queries              | yes  |
mysql_slowqueries          | yes  |
mysql_threads              | yes  |
netstat                    | yes  |
nfs_client                 | yes  |
nfsd                       | yes  |
ntp_                       | yes  | mathfox_xs4all_nl
ntp_states                 | no   |
open_files                 | yes  |
open_inodes                | yes  |
ping_                      | no   |
port_                      | no   |
postfix_mailqueue          | yes  |
postfix_mailstats          | no   |
postfix_mailvolume         | no   |
processes                  | yes  |
ps_                        | no   |
psu_                       | no   |
sendmail_mailqueue         | no   |
sendmail_mailstats         | no   |
sendmail_mailtraffic       | no   |
sensors_                   | no   |
smart_                     | yes  | hda
squid_cache                | no   |
squid_icp                  | no   |
squid_requests             | no   |
squid_traffic              | no   |
swap                       | yes  |
sybase_space               | no   |
uptime                     | no   |
vlan_                      | no   |
vlan_inetuse_              | no   |
vlan_linkuse_              | no   |
vmstat                     | yes  |

Per le macchine diverse da quella che ospita il server, bisogna modificare le impostazioni di accesso per consentire le connessioni da parte di quest'ultimo. Per fare questo apriamo con un editor il file /etc/munin/munin-node.conf, ed aggiungiamo la seguente riga alla fine del file: 

allow ^192\.168\.0\.1$

Il commento poco sopra il punto in cui abbiamo inserito questa stringa ci ricorda che si tratta di espressioni regolari, di conseguenza è necessario anteporre un backslash prima dei punti.

Per applicare le modifica apportate, riavviamo munin-node: 

# /etc/init.d/munin-node restart

Moduli

Munin sfrutta un'architettura a plug-in per monitorare le varie componenti di sistema. Come abbiamo visto nel paragrafo precedente (vedi l'output di munin-node-configure) ce ne sono a disposizione moltissimi.

Munin-node altro non è che uno script che si preoccupa di lanciare i vari plug-in presenti all'interno della cartella /etc/munin/plugins. Notiamo subito che all'interno di questa directory non troviamo i veri e propri moduli, ma del link simbolici ad essi: 

# ls -l /etc/munin/plugins |more
totale 0
lrwxrwxrwx  1 root root 28 2005-07-01 01:06 cpu -> /usr/share/munin/plugins/cpu
lrwxrwxrwx  1 root root 27 2005-07-01 01:06 df -> /usr/share/munin/plugins/df
lrwxrwxrwx  1 root root 33 2005-07-01 01:06 df_inode -> /usr/share/munin/plugins/df_inode
lrwxrwxrwx  1 root root 32 2005-07-01 01:06 entropy -> /usr/share/munin/plugins/entropy
[...]

Quindi, per abilitare e/o disabilitare i moduli, è sufficiente creare/cancellare i link simbolici a /usr/share/munin/plugins presenti in /etc/munin/plugins.

Se ad esempio voglio abilitare i moduli relativi ad apt, sarà sufficiente il comando: 

# ln -s /usr/share/munin/plugins/apt* /etc/munin/plugins

e, dopo aver creato i link: 

# /etc/init.d/munin-node restart

Nel caso si voglia testare l'effettivo funzionamento di un plugin, si può sfruttare il comando munin-run che lancia lo script coi permessi effettivi con cui verrà richiamato da munin. Per esempio, si può testare il corretto funzionamento del plugin postfix_mailstats con: 

# munin-run postfix_mailstats

Il comando, in questo caso, potrebbe dare errore (o restituire un valore pari a U) per via dei permessi insufficienti: è necessario essere root per poter accedere allo spool di posta e 'contare' i messaggi presenti. Per ovviare a questo problema è sufficiente modificare il file /etc/munin/plugin-conf.d/plugins.conf aggiungendo la seguente riga: 

[postfix_mailstats]
user root

che indica, a munin, di eseguire lo script coi privilegi di root.

Apache, un caso particolare

Parliamo un po' più dettagliatamente dei moduli relativi ad Apache: per abilitarli, infatti, non è sufficiente creare i link simbolici, ma abbiamo bisogno anche di metter mano alla configurazione di Apache.

Per monitorare Apache, Munin ha bisogno che mod_status venga caricato da httpd con la direttiva ExtendedStatus On. In Debian mod_status per Apache viene caricato di default, per cui dobbiamo solo preoccuparci di fare un piccolo aggiustamento alla sezione che lo riguarda.

Ecco come dobbiamo impostare in httpd.conf la sezione di mod_status: 

<IfModule mod_status.c>
  ExtendedStatus On
  <Location /server-status>
      SetHandler server-status
  </Location>
</IfModule>

In questo modo munin può interrogare Apache direttamente tramite il protocollo HTTP.

Per verificare che mod_status sia effettivamente in funzione è sufficiente puntare il nostro browser all'indirizzo http://localhost/server-status.

Info.png Nota sulla sicurezza
È bene aggiungere alcune istruzioni relative alla sicurezza nella nostra configurazione di mod_status, in modo da renderlo accessibile unicamente attraverso il nostro indirizzo IP locale (127.0.0.1). per fare questo possiamo inserire all'interno dei tag <location> e </location>, subito al di sotto di SetHandler server-status queste istruzioni: 
Order Deny,Allow
    Deny from all
    Allow from 127.0.0.1

Riavviamo Apache: 

# apachectl graceful

e munin-node: 

# /etc/init-d/munin-node restart

Server

La configurazione di default del server è più che sufficiente per un utilizzo normale di questo. Utilizza la directory /var/www/munin/, in cui inserisce tutte le pagine relative ai computer da monitorare. Questa directory, quindi, dovrà essere accessibile in scrittura dall'utente munin, ed in lettura dall'utente www-data (supponendo l'utilizzo di Apache come webserver per visualizzare le statistiche). In particolare controlliamo che la directory /var/www abbia i permessi di esecuzione per l'utente nobody.

Debian Squeeze

A partire da Debian Squeeze la configurazione di Munin richiede qualche passaggio aggiuntivo.
Innanzitutto dobbiamo tenere a mente che la directory utilizzata è diventata /var/cache/munin/www e che deve avere i corretti permessi: 

# chown -R munin:www-data /var/cache/munin/www/

Se intendiamo visualizzare i grafici di Munin da una macchina diversa da localhost dobbiamo anche modificare il file: 

# nano /etc/munin/apache.conf

e cambiare la sezione 

Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
        Order allow,deny
        Allow from localhost 127.0.0.0/8 ::1

in qualcosa di simile a: 

Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
        Order allow,deny
        Allow from localhost 127.0.0.0/8 ::1
        Allow from 192.168.1.0/24

dove ovviamente 192.168.1.0 corrisponde al nostro indirizzo di rete.
Ricordarsi di eseguire: 

# /etc/init.d/apache reload

per rendere effettive le modifiche.

Debian Jessie

La versione di Apache è la 2.4.x e il controllo degli accessi Rule-Based prevede una configurazione differente. 

Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
   Require all granted
    Require ip 192.168.1.0/24
    ..........
</Directory>

vedere anche: Installare un ambiente LAMP: Linux, Apache2, SSL, MySQL, PHP5 e Apache2: proteggere directory mediante autenticazione

Aggiunta di Client

La configurazione del server è gestita tramite un file: /etc/munin/munin.conf.

La sezione che a noi interessa è l'ultima, dove vengono raccolti i dati dei nodi da monitorare. Ogni blocco rappresentate un nodo, nel file di configurazione, ha la seguente struttura: 

[nome_del_nodo]
    address <indirizzo_del_nodo>
    use_node_name <yes|no>

I parametri e le opzioni descritte hanno il seguente significato:

nome_del_modulo
indica il nome con cui verrà rappresentato il nodo (solo se use_node_name è yes). Munin raccoglie i nodi per domini di secondo livello, in una struttura ad albero.
address <indirizzo_del_nodo>
indica l'indirizzo (IP o URL) tramite il quale raggiungere il nodo.

Riporto un esempio di configurazione per il monitoraggio di due macchine: 

[spirit.knio.it]
    address 127.0.0.1
    use_node_name yes

[maxer.knio.it]
    address 192.168.0.2
    use_node_name yes

I dati contenuti in /var/www/munin sono aggiornati tramite il cron /etc/cron.d/munin, esattamente ogni 5 minuti.

Autenticazione

L'unico problema di Munin è che le nostre statistiche sono visibili a tutti. Occorre quindi prendere qualche precauzione.
Abilitiamo innanzitutto il modulo auth_digest di Apache, per gestire le Digest Authentication, un metodo più sicuro che evita di trasmettere in chiaro la password: 

# a2enmod auth_digest

Quindi ricarichiamo la configurazione di Apache: 

# /etc/init.d/apache2 force-reload

Ora che Apache può gestire un'autenticazione sicura dobbiamo impostare un utente e una password per Munin: 

# htdigest -c /var/cache/munin/www/.htpasswd munin munin

Ci verrà richiesta una password per l'utente "munin" appena creato; digitiamola due volte per conferma.
A questo punto non ci resta che modificare il file che definisce il Virtual Host di Apache per Munin, abilitando l'autenticazione digest: 

# nano /etc/munin/apache.conf

e aggiungendo le righe seguenti tra i TAG <Directory />....</Directory>: 

<Directory />
       ...
       
       #Autenticazione
       AuthType Digest
       AuthName "munin"
       AuthUserFile  /var/www/munin/.htpasswd
       require valid-user
</Directory>

Infine controlliamo l'attuale configurazione di Apache e riavviamolo: 

# apache2ctl -t
Syntax OK
# /etc/init.d/apache2 force-reload

Conclusioni

Munin, come visto, è uno strumento veramente utile, sia per la sua facilità di installazione, sia per il vasto numero di dati che è capace di monitorare. Le sue funzionalità, inoltre, sono ampliabili tramite plugin, così da poter adattare al meglio il servizio alle proprie esigenze.

Bookmark

Home Page del progetto



Guida scritta da: MaXeR Swirl-auth100.png Guida Debianized
Estesa da:
Ferdybassi 20:55, 4 apr 2011 (CEST)
Verificata da:
porkyhttp 17:04, 06 mag 2012 (CEST)
People 21:04, 05 mag 2012 (CEST)
Ferdybassi 16:19, 21 mag 2012 (CEST)
nydebianized 07:12, 12 set 2015 (CEST)

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

Estratto da "https://guide.debianizzati.org/index.php?title=Munin&oldid=42978"