Intanto ricordo i link alla prima e alla seconda parte della guida:

• Parte 1
• Parte 2

Tornando a Nagios e Munin: l’uso dei check passivi può tornare utile se si va ad installare Nagios in una rete in cui è già presente Munin che, per chi non lo conoscesse, è un software che crea grafici di andamento di una lunga serie di servizi o aspetti dei server (anch’esso configurabile con agenti su vari server e un’applicazione centralizzata per la raccolta dei dati).
Se Munin non fosse già installato si può valutare una configurazione Nagios-centrica con i check effettuati da NRPE e i grafici fatti con NagiosGraph.

Nel mio caso era già presente Munin e ho quindi optato per la configurazione dei check passivi.

Configurazione del server (Nagios e nsca)

Si comincia come sempre installando i pacchetti necessari:

apt-get install libmcrypt-dev xinetd

Quindi si scarica NSCA dalla pagina degli addon di Nagios, si scompatta, si compila e si installa:

tar xzf nsca-2.7.2.tar.gz
cd nsca-2.7.2/
./configure prefix=/usr/local/nagios --with-nsca-user=nagios --with-nsca-grp=nagcmd
make all
cp -a src/nsca /usr/local/nagios/bin/
cp sample-config/nsca.cfg /usr/local/nagios/etc/
chown nagios:nagcmd /usr/local/nagios/etc/nsca.cfg
chmod g+r /usr/local/nagios/etc/nsca.cfg
cp sample-config/nsca.xinetd /etc/xinetd.d/nsca

Bisogna anche aggiungere al file /etc/services il servizio NSCA con la riga:

nsca    5667/tcp    # NSCA

Nel file /etc/xinetd.d/nsca bisogna modificare il parametro only_from per consentire l’accesso al server in cui gira Munin, poi possiamo riavviare xinetd.

Configurazione del client (send_nsca e Munin)

Nel client da cui arriveranno i check (ovvero dove gira Munin) bisogna ugualmente scaricare il pacchetto NSCA e compilarlo. Differisce l’installazione del binario che in questo caso è send_nsca e può essere posizionato dove si vuole (stessa cosa vale per il suo file di configurazione). Dato che nel mio caso Munin e Nagios sono sullo stesso server ho usato la directory di Nagios per ospitare questi file:

cp -a src/send_nsca /usr/local/nagios/bin/
cp sample-config/send_nsca.cfg /usr/local/nagios/etc/

Se i due software sono su server diversi potete impostare un metodo di cifratura nel file send_nsca.cfg e impostare una password (che deve essere la stessa sul server e sul client).

Proviamo adesso se send_nsca funziona. I check passivi consistono in una riga contenente:

HOSTNAME[tab]SERVIZIO[tab]CODICE[tab]DESCRIZIONE

quindi per fare un test possiamo creare un file con il contenuto:

hostAcaso   pippo   0   OK

e fare un test di connessione con:

/usr/local/nagios/bin/send_nsca localhost -c /usr/local/nagios/etc/send_nsca.cfg < test
1 data packet(s) sent to host successfully.

Nei log di Nagios troveremo:

nagios: Warning:  Passive check result was received for service 'pippo' on host 'hostAcaso', but the host could not be found!

Funziona! Non fatevi spaventare dal warning: Nagios ha ricevuto il check ma non ha nessun host corrispondente nella sua configurazione. Niente di male, glielo spiegheremo più tardi.

Possiamo quindi configurare Nagios per accettare i check passivi. Per farlo andiamo nel server e inseriamo nel file etc/objects/templates.cfg il template per un servizio che accetta sono check passivi:

define service{
 name                            passive-service
 use                             generic-service
 active_checks_enabled           0
 passive_checks_enabled          1
 flap_detection_enabled          0
 register                        0
 is_volatile                     0
 check_period                    24x7
 max_check_attempts              1
 normal_check_interval           5
 retry_check_interval            1
 check_freshness                 0
 contact_groups                  admins
 notification_options            w,u,c,r
 stalking_options                w,c,u
 notification_interval           120
 check_command                   check_dummy!0
}

Inseriamo poi nel file etc/objects/commands.cfg la definizione del comando check_dummy:

define command{
 command_name    check_dummy
 command_line    $USER1$/check_dummy $ARG1$
}

Fatto questo possiamo inserire un check di prova in un host:

define service{
 use                             passive-service
 host_name                       hostCheEsiste
 service_description             TestMessage
}

Una volta riavviato Nagios vedremo questo servizio in stato pending. Modificando il file di prima con:

hostCheEsiste    TestMessage    0     Messaggio di OK

ed eseguendo nuovamente:

/usr/local/nagios/bin/send_nsca localhost -c /usr/local/nagios/etc/send_nsca.cfg < test

possiamo mettere il servizio in stato di OK.

Per finire dobbiamo dire a Munin di chiamare Nagios quando qualcosa non va. Per farlo dobbiamo modificare il file munin.conf inserendo:

contacts nagios
contact.nagios.command /usr/local/nagios/bin/send_nsca -H localhost -c /usr/local/nagios/etc/send_nsca.cfg

Modificate le path secondo la vostra configurazione e inserite nel file send_nsca.cfg l’eventuale password per comunicare con NSCA.

Ma come funzionano in dettaglio gli avvertimenti di Munin?

Munin si basa su plugin e ognuno di essi ha dei limiti. Per vederli basta lanciare (in questo caso interrogo il plugin cpu):

munin-run cpu config

Nella risposta si possono individuare i limiti:

system.warning 60
system.critical 100

Tali limiti possono essere monitorati da munin-limits, un eseguibile che, per essere lanciato automaticamente, va inserito in crontab. Di base ne trovate una configurazione in /etc/cron.d/munin (se non c’è createlo). Io l’ho modificato così:

*/5 * * * *     munin if [ -x /usr/share/munin/munin-limits ]; then /usr/share/munin/munin-limits --force --contact nagios --contact old-nagios; fi

Quindi ogni 5 minuti fa il check e contatta Nagios per passargli il risultato.

L’ultima cosa da fare è adattare i limiti di ogni plugin secondo le proprie esigienze. Si possono definire in munin.conf per ogni host:

df._mapper_sda1_vm_root.warning      0:90
df._mapper_sda1_vm_root.critical     0:95
df.notify_alias     Disk usage

La logica con cui vengono definiti i limiti è un po’ cervellotica e dipende molto dal tipo di plugin. In questo caso ho usato df che controlla l’uso del disco.
Il limite di warning 0:90 viene superato se il limite è al di fuori di questo range (il range è 0:100). Ma a sua volta il limite critico è al di fuori del range 0:95. Il risultato è che il plugin entra in warning se la partizione è occupata tra il 90% e il 94% e in critical da 95% in sù.
Vi lascio divertire con gli altri plugin :)

Inseriamo in Nagios questi check

Ho già mostrato prima come inserire un check passivo in un host, ovvero:

define service{
 use                             passive-service
 host_name                       hostCheEsiste
 service_description             TestMessage
}

Per accettare un check passivo valido da Munin bisogna modificare service_description affinchè sia uguale al nome del servizio che definisce il plugin di Munin. Dato che hanno nomi non facilmente individuabili e che a volte contengono caratteri incompatibili con Nagios (ad esempio %) una cosa furba è rinominarli in munin.conf con .notify_alias (guardate qualche riga più in sù nel caso del df) e usare quell’alias in Nagios.

A questo punto la teoria è finita e non rimane altro da fare che iniziare a scrivere le definizioni dei check in Nagios e le configurazioni dei plugin in Munin, buon lavoro!

In questa seconda parte della guida illustrerò alcune configurazioni di base per i check di Nagios e l’uso dell’addon NRPE per check locali su sistemi remoti.

La struttura

In questa guida prenderò in considerazione la struttura qui si seguito che permette di illustrare vari tipi di configurazione:

Una panoramica sugli host e i servizi:

• Host A, server Linux con:
  • Server HTTP Apache
  • VMWare Server con una macchina virtuale E con un server Zimbra
• Host B, server Linux con:
  • Server HTTP Apache
  • Server MySQL

Quindi E dipende da C che a sua volta dipende da A. Invece D dipende da B.
Entrambi i server Apache rispondono sulle porte 80 e 443, l’interfaccia di amministrazione di VMWare Server risponde sulla porta 8333 (con SSL).
La macchina virtuale Zimbra fornisce i servizi SMTP, POP3 e le interfaccie di webmail e amministrazione (porta 7071).
Infine nella macchina B il server MySQL risponde solo sull’interfaccia locale, non è quindi possibile accedervi dall’esterno.

Negli esempi successivi gli elementi A, C ed E saranno del cliente Company A (dominio company-a.com) e B e D saranno del cliente Company B con dominio company-b.com.
I nomi host saranno i seguenti:

• A => web.company-a.com
  
• C (macchina virtuale) => mail.company-a.com
  
• B => web.company-b.com

Per un maggior dettaglio nella spiegazione delle singole configurazioni tenete sempre sott’occhio la guida ufficiale alla pagina Object Definitions.

Organizzazione dei file

Una volta installato Nagios seguendo la prima parte della guida, troverete tutte le configurazioni in /usr/local/nagios/etc. Il file che comanda è nagios.cfg il quale poi richiama tutti gli altri. È quindi possibile, e consigliabile, creare una gerarchia di file che possa poi più facilmente permettere di gestire tutte le configurazioni (senza perdersi per strada i vari pezzi).
Nel file nagios.cfg ci sono due direttive inerenti questo aspetto e sono cfg_file e cfg_dir. La prima indica direttamente un file da cui leggere ulteriori configurazioni, la seconda indica intere directory da cui saranno inclusi tutti i file che terminano con .cfg. Io consiglio di intervenire usando questa seconda direttiva, le cartelle che ho creato sono:

cfg_dir=/usr/local/nagios/etc/personalized_objects
cfg_dir=/usr/local/nagios/etc/servers
cfg_dir=/usr/local/nagios/etc/groups

Oltre alle due cartelle con le configurazioni dei server e dei gruppi, ho aggiunto una cartella in cui inserirò i template personalizzati, ad esempio con timeperiods o contact groups diversi da quelli standard.

Gruppi di host e servizi

È possibile definire dei gruppi di host (ad esempio a seconda dell’azienda di appartenenza o del tipo di hardware) e dei gruppi di servizi (server di posta, server web, ecc.). Personalmente inserisco queste configurazioni nella cartella groups.

Esempi di configurazione sono i seguenti:

define hostgroup{
    hostgroup_name     companyA-servers
    alias              Company A Servers
    members            mail.company-a.com,web.company-a.com
}
define hostgroup{
    hostgroup_name     companyB-servers
    alias              Company B Servers
    members            web.company-b.com
}
define servicegroup{
    servicegroup_name  web-servers
    alias              Web Servers
    members            web.company-a.com,HTTP,web.company-b.com,HTTP
}

In entrambi i casi gli host indicati in members devono ricalcare il nome con cui quegli host sono definiti (attributo host_name). Nel caso dei servizi, oltre al nome dell’host, deve essere indicato il nome del servizio (anche in questo caso deve essere uguale a quello inserito in service_description).

Definizione degli host

Iniziamo con la configurazione dei server. I file web.company-a.com.cfg, web.company-b.com.cfg e mail.company-a.com.cfg verranno creati nella cartella servers. Non c’è molto da spiegare, inserisco dei commenti direttamente nelle configurazioni:

web.company-a.com.cfg

define host {
    use             linux-server   ;   Template da cui ereditare
    host_name       web.company-a.com   ;   L'host name è ciò che viene usato per identificare l'host negli altri file
    alias           CompanyA Web Server
    address         1.2.3.4
    hostgroups      comapanyA-servers   ;   Come in hostgroup, tale configurazione può essere alternativa o in aggiunta
}

web.company-b.com.cfg

define host {
    use             linux-server
    host_name       web.company-b.com
    alias           CompanyB Web Server
    address         1.2.3.5
    hostgroups      comapanyB-servers
}

mail.company-a.com.cfg

define host {
    use             linux-server
    host_name       mail.company-a.com
    alias           CompanyA Web Server
    address         1.2.3.6
    hostgroups      comapanyA-servers
    parents         web.company-a.com   ;   L'host da cui questo host dipende
}

Definizione dei servizi

La definizione dei servizi è direttamente collegata ai plugin, ovvero usano questi ultimi per effettuare i check. In verità il valore dell’attributo check_command, anche se in genere ricalca il nome del plugin (i plugin sono nella cartella libexec), non lo indica direttamente ma ha una corrispondenza nel valore dell’attributo command_name nella definizione di un comando (file etc/objects/commands.cfg).

mail.company-a.com.cfg

define service {
 use                     generic-service
 host_name               mail.company-a.com
 service_description     SMTP
 check_command           check_smtp!-t 5
}
define service {
 use                     generic-service
 host_name               mail.company-a.com
 service_description     IMAP
 check_command           check_imap!-t 5
}
define service {
 use                     generic-service
 host_name               mail.company-a.com
 service_description     POP3
 check_command           check_pop!-t 5
}

Nella direttiva check_command viene indicato il tipo di comando da eseguire. Dopo il punto esclamativo vengono indicati gli argomenti. Se date uno sguardo a etc/objects/commands.cfg vedrete che gli argomenti vengono passati al plugin con $ARG1$, $ARG2$, ecc. In alcuni è presente soltanto un argomento, quindi nella definizione del servizio, dopo il punto esclamativo, devono essere indicati tutti gli argomenti (tipo ./check_dummy -t pippo -x pluto) mentre in altri comandi sono presenti più argomenti, spesso associati ad una specifica opzione (tipo ./check_dummy -t $ARG1$ -x $ARG2$). Nella definizione del servizio, più argomenti possono essere indicati con più punti esclamativi (tipo check_dummy!pippo!pluto). Per avere più informazioni su un plugin lanciatelo con libexec/check_dummy –help.

Un esempio di check un po’ più complesso può essere, ad esempio, quello necessario per controllare se l’interfaccia di amministrazione di Zimbra sta girando correttamente (HTTPS sulla porta 7071):

mail.company-a.com.cfg

define service{
 use                             generic-service
 host_name                       mail.comapany-a.com
 service_description             ZimbraAdmin
 check_command                   check_http!"-H mail.company-a.com -p 7071 -w 5 -c 15 --ssl"
}

Com’è facile intuire, con check_http è possibile quindi monitorare ogni singolo sito presente su un server web.

Ecco gli altri file necessari per la nostra configurazione:

web.company-a.com.cfg

define service{
 use                             generic-service
 host_name                       web.company-a.com
 service_description             HTTP
 check_command                   check_http   ;   Semplice check sulla porta 80
}

define service{
 use                             generic-service
 host_name                       web.company-a.com
 service_description             VMWareAdmin
 check_command                   check_http!"-H web.company-a.com -p 8333 -w 5 -c 15 --ssl"
}

web.company-b.com.cfg

define service{
 use                             generic-service
 host_name                       web.company-b.com
 service_description             HTTP
 check_command                   check_http
}

NRPE

L’ultima cosa che rimane da controllare è lo stato del server MySQL. Dato che il servizio risponde soltanto sull’interfaccia locale non è possibile controllarne direttamente lo stato dal server Nagios. L’addon NRPE fa proprio questo: installato sulla macchina da controllare, esegue dei check locali quando interrogato da Nagios.Il plugin da usare sul server è check_nrpe e l’argomento da passargli è il nome del check definito nel client, il quale a sua volta dovrà associare questo nome ad un check locale (quindi sul client dobbiamo installare i plugin).

Su entrambe le macchine va compilato  l’addon:

tar xzf nrpe-2.12.tar.gz
cd nrpe-2.12/
./configure --enable-ssl
make all

A questo punto l’installazione tra host e client differisce. Per l’installazione nel client dei plugin seguite la prima parte della guida.

Host

make install-plugin

e quindi bisogna creare il template del comando:

commands.cfg

define command {
 command_name    check_nrpe
 command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Client

Se non è installato, installate xinetd:

apt-get install xinetd

Installate quindi il demone

make install-daemon
make install-daemon-config
make install-xinetd

Aggiungete NRPE al file /etc/services:

nrpe 5666/tcp # NRPE

Aggiungete l’ip del server Nagios al file /etc/xinetd.d/nrpe (in questo caso un fittizio 4.3.2.1):

only_from = 127.0.0.1 4.3.2.1

Infine riavviate il server xinetd e controllate che NRPE sia in ascolto:

~# /etc/init.d/xinetd restart
~# netstat -at | grep nrpe
tcp        0      0 *:nrpe                  *:*                     LISTEN

A questo punto si può testare il servizio in locale con:

~# /usr/local/nagios/libexec/check_nrpe -H localhost
NRPE v2.12

Controllare MySQL

Arriviamo al nostro obiettivo: controllare che il server MySQL stia correttamente girando. Creiamo un utente MySQL non privilegiato:

mysql> CREATE USER 'nagiosCheck'@'localhost' IDENTIFIED BY 'some_pass';

Il check, lanciato da linea di comando, sarà il seguente:

~# /usr/local/nagios/libexec/check_mysql -u nagiosCheck -p some_pass
Uptime: 1061012  Threads: 2  Questions: 192277  Slow queries: 0  Opens: 198  Flush tables: 1  Open tables: 64  Queries per second avg: 0.181

Inseriamo quindi tale check in /usr/local/nagios/etc/nrpe.cfg:

command[check_mysql]=/usr/local/nagios/libexec/check_mysql -u nagiosCheck -p some_pass

Da notare che nel server Nagios il nome dell’argomento da passare a check_nrpe sarà check_mysql come definito tra le parentesi quadre.
A questo punto dal server Nagios si può testare il check remoto:

~# /usr/local/nagios/libexec/check_nrpe -H tomcat.mydomain.com -c check_mysql
Uptime: 1061534  Threads: 2  Questions: 192280  Slow queries: 0  Opens: 198  Flush tables: 1  Open tables: 64  Queries per second avg: 0.181

Se è tutto ok non resta che inserirlo tra i servizi dell’host B:

web.company-b.com.cfg

define service{
 use                             generic-service
 host_name                       web.company-b.com
 service_description             MySQL
 check_command                   check_nrpe!check_mysql
}

E questo conclude la configurazione della nostra rete di test. Nella prossima puntata spiegherò come configurare dei server slave per effettuare check passivi, necessari, ad esempio, in configurazioni di rete complesse in cui il server master non può direttamente raggiungere gli host da controllare (se l’host da controllare è all’interno di una LAN, per dirne una).

Leggi la prima parte della guida

Dopo aver configurato sistemi di monitoraggio per alcune P.A. e aziende, mi sono deciso a farlo anche per i miei server e descriverò in queste pagine ciò che ho fatto o sto ancora facendo.

Dividerò questa guida in più parti, per renderla più leggibile e per poter facilmente aggiungere nuove parti via via che incremento le funzionalità del sistema.

Questa prima parte descrive l’hardware scelto, l’installazione del sistema operativo e l’installazione base di Nagios.

Hardware

La scelta dell’hardware è caduta su un embedded acquistato (per circa 80€) su pcengines.ch ampiamente in grado di fornire la potenza necessaria allo scopo e con consumi estremamente limitati.

Nello specifico ecco le caratteristiche principali:

Oltre alla scheda ho acquistato anche il case (damn! non avevano quello rosa shocking!) e l’alimentatore.

Costo complessivo 101,31€ così distribuiti:

• Scheda: 72,23 €
• Case: 6,63 €
• Alimentatore: 4,05 €
• Spedizione: 18,40 €

A questo è necessario aggiungere una memoria CompactFlash (io ne ho usata una da 2GB), un lettore/scrittore di tali memorie e un adattatore seriale<=>USB (o soltanto un cavo seriale se avete una porta adatta). Attenzione al cavo seriale che deve essere RS-232 altrimenti la connessione non funziona.

Sistema operativo

Il sistema operativo scelto è Debian Voyage, una versione di Debian ottimizzata per le piattaforme embedded x86. La sua installazione sulla CompactFlash è estremamente semplice e veloce (per i dettagli vi rimando alla pagina wiki dedicata).
Una volta installato si può montare la memoria nella mainboard e agganciare il pc via seriale. Per visualizzare la console remota si può usare il software screen:

screen /dev/ttyUSB0 38400

Si può quindi alimentare la scheda e osservare il boot. Per accedere la prima volta a voyager usare l’utente root con password voyage.
Consiglio di configurare subito la rete con un ip statico (usate /etc/network/interfaces) e installare openssh-server che permetterà di lavorare in remoto con la console preferita.

Per prepararsi all’installazione di Nagios dobbiamo fare un po’ di cose:

apt-get install locales dialog build-essential apache2 libapache2-mod-php5 mailx postfix
addgroup --system nagios
adduser --system --no-create-home --home /usr/local/nagios --ingroup nagios --disabled-password nagios
addgroup --system nagcmd
usermod -a -G nagcmd nagios
usermod -a -G nagcmd www-data

Configuriamo Postfix con i parametri corretti per la nostra connessione e inseriamo in /etc/aliases l’alias per l’utente root:

postmaster: root
nagios: root
root: io@mio-dominio.com

e aggiorniamo:

newaliases

Anzichè Apache (un po’ oneroso in termini di memoria consumata) volevo usare Nginx ma per configurarlo per fornire pagine PHP è necessario lavorarci un po’, quindi lascio questa configurazione per il futuro (considererò anche l’eventuale uso di Lighttpd).

Nagios

Si può quindi iniziare a installare il software di monitoraggio, ovviamente Nagios. Per alcuni check potrebbero essere necessari alcuni pacchetti, eccone alcuni tra i più comuni:

apt-get install libgd2-xpm libgd2-xpm-dev libpng3 libpng3-dev libjpeg62 libjpeg-dev zlib1g zlib1g-dev libnet-snmp-perl snmp libssl-dev libpq-dev libmysqlclient15-dev smbclient qstat fping libradiusclient-ng-dev libldap2-dev

Scarichiamo Nagios Core in /usr/src e compiliamolo:

tar xzf nagios-3.2.0.tar.gz
cd nagios-3.2.0/
./configure --prefix=/usr/local/nagios --with-command-group=nagcmd --with-httpd-conf=/etc/apache2/conf.d/
make all
make install
make install-init
make install-commandmode
make install-config
make install-webconf

Per ulteriori informazioni seguite la guida ufficiale.
Compiliamo e installiamo anche i plugin, scaricati da qui:

tar xzf nagios-plugin-1.4.14.tar.gz
cd nagios-plugin-1.4.14
./configure  --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagios-group=nagios
make
make install

Creiamo adesso la password per l’accesso a Nagios:

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Se cambiate il nome utente sostituite tutte le occorrenze di nagiosadmin col nuovo utente nel file /usr/local/nagios/etc/cgi.cfg.
Aggiungiamo Nagios all’avvio del sistema:

update-rc.d nagios defaults

e iniziamo la configurazione. Una volta terminato, prima di lanciare o riavviare Nagios, possiamo verificare la correttezza della configurazione con:

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

La prima parte della guida termina qui, nella prossima vedremo come configurare i check di base e i controlli remoti con Nagios NRPE.

Leggi la seconda parte della guida

Debian Etch installation

Let’s start installing Debian Etch from businesscard and unchecking all the default packages (Desktop environment and Base system). After the reboot install some basic package:

OpenSSH is just an optional server, but i’m working on a VMWare virtual machine and an ssh console is more comfortable than the VMWare console :)

Softwares

Now download all the needed packages into /usr/src:

• OpenSSL 0.9.8i
• BerkeleyDB 4.6.21 (version 4.7 is unsupported from OpenLDAP)
• OpenLDAP 2.4.11
• Apache 2.2.9
• IMAP 2007b
• PHP 5.2.6
• Postfix 2.5 Patchlevel 5
• Dovecot 1.1.3

OpenSSL

BerkeleyDB

OpenLDAP

For this howto i’ll use dc=example,dc=com. Edit /usr/local/openldap/etc/openldap/slapd.conf including some schemas and setting the password for cn=Manager,dc=example,dc=com

Rename /usr/local/openldap/var/openldap-data/DB_CONFIG.example to /usr/local/openldap/var/openldap-data/DB_CONFIG and type:

to start the server.

Then create an ldif file (base.ldif) for the initial user:

and add it to the database:

Now let’s create some users, i’ll use these objects:

An example:

If you want to set these users as system users install libnss-ldap

and edit /etc/nsswitch.conf

and create the group:

You can verify with:

Apache

Edit /usr/local/apache2/conf/apache.conf and launch with:

IMAP

The IMAP library is needed from PHP to send email from the webmail.

PHP

First, download and unzip the mysql client libraries, then:

Edit apache.conf adding index.php to the default pages; if not present add this too:

Postfix

Create /etc/ld.so.conf.d/my_libraries.conf:

and launch ldconfig!

The gid and user 800 will be used for the virtual transport.

This is main.cf:

ldap-accounts.cf:

Remember to create an user for bindings and edit Postfix and Dovecot configurations to use it.
To verify the ldap file use postmap:

Start postfix with:

Dovecot

This is dovecot.conf:

and dovecot-ldap.conf:

Start dovecot with /usr/local/dovecot/sbin/dovecot

Webmail

I suggest Horde Framework or Roundcube

Webography

• OpenSSL
• BerkeleyDB
• OpenLDAP
• Apache
• IMAP
• PHP
• PHPLdapAdmin
• Postfix
• Dovecot

I passaggi per l’installazione sono solo due:

In coda al secondo comando verranno mostrate le indicazioni per concludere l’installazione, a quel punto basta fare il reload di Apache et voila’, mod_rails!

P.S. In coda aggiungo che, curiosamente, qualcuno si e’ dimenticato di pagare per il dominio rubyonrails.org (mi perdonerete se non aggiungo il link) tanto che adesso al suo posto si trova uno dei soliti siti spam del menga…

AGGIORNAMENTO
Inserito Passenger proprio ieri in Gentoo ~x86

Introduzione

Lo scopo della guida è configurare la scansione antivirus dei dati passanti per il proxy web.
Gli strumenti saranno il proxy Squid, il redirector SquidGuard e l’antivirus Clamav. Ad essi si aggiunge Apache2, a cui si appoggia lo script in Perl Viralator, che permette tutto il giochetto. Infine useremo una semplice regola di iptables.

Installazione degli strumenti necessari

Con Debian i pacchetti da installare sono: clamav-base clamav squid squidguard apache2.

Configurazione

Apache2

Apache deve gestire la scansione dei files da parte di Clamav attraverso lo script di Viralator.
L’unica modifica che ho apportato nel file di configurazione di default è stata il cambiamento del path degli script cgi a /var/www/cgi-bin in cui metterò poi lo script di Viralator.

Clamav

Clamav non necessita di alcuna configurazione post-installazione.
Potete provare la sua funzionalità con:

truelite-server:~# clamscan /*
LibClamAV Warning: ********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.  ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/faq.html ***
LibClamAV Warning: ********************************************************
LibClamAV Warning: ********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.  ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/faq.html ***
LibClamAV Warning: ********************************************************
/bin/bash: OK
/bin/cat: OK
/bin/chgrp: OK
/bin/chmod: OK
/bin/chown: OK
[...]

Non preoccupatevi dei messaggi minatori, vi avvertono solo che non avete l’ultima versione del programma (se, come me, usate Debian Sarge…)
Una cosa molto utile è impostare l’auto aggiornamento del database antivirus. Il metodo che ho ritenuto più giusto in fase di installazione è “a mano”, altrimenti potete usare il demone, che però girerà di continuo sul pc (utile per i server).
Per aggiornare a mano l’antivirus il comando è semplicemente:

macondo:~# freshclam
ClamAV update process started at Wed Nov  2 16:09:56 2005
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.84 Recommended version: 0.87
DON'T PANIC! Read http://www.clamav.net/faq.html
main.cvd is up to date (version: 34, sigs: 39625, f-level: 5, builder: tkojm)
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Current functionality level = 4, recommended = 5
DON'T PANIC! Read http://www.clamav.net/faq.html
daily.cvd is up to date (version: 1158, sigs: 1300, f-level: 6, builder: diego)
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Current functionality level = 4, recommended = 6
DON'T PANIC! Read http://www.clamav.net/faq.html

Anche qui niente panico, gli WARNING sono dovuti alla versione un po’ obsoleta del pacchetto.

SquidGuard

Il file di configurazione di SquidGuard è /etc/squid/squidGuard.conf.
La configurazione che vi propongo fa sì che la scansione avvenga solo su alcuni tipi di file.
Ecco come:

macondo:~# mkdir -p /etc/squid/squidGuard/db/deny
macondo:~# vi /etc/squid/squidGuard/db/deny/files

Ecco il contenuto del file files:

(\.exe$|\.com$|\.bat$|\.zip$|\.tgz$|\.gz$|\.bz2$)

Aggiungete tutte le estensioni di cui volete effettuare la scansione.
A questo punto modificate il file /etc/squid/squidGuard.conf:

dbhome /etc/squid/squidGuard/db
logdir /var/log/squid

dest files {
        expressionlist deny/files
}

acl {
        default {
                pass !files all
                redirect

http://[PROXY]/cgi-bin/viralator.cgi?url=%u

        }
}

Al posto di [PROXY] dovete mettere l’IP o l’hostname del proxy che provvederà a lanciare lo script viralator.cgi

Squid

Il file di configurazione di Squid è /etc/squid/squid.conf, il contenuto è questo:

#
# Redirect verso SquidGuard
#

redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
redirect_children 10

#
# Proxy trasparente
#

httpd_accel_port 80
httpd_accel_host virtual
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
httpd_accel_single_host off

#
# Resto della configurazione
#

hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_mem 256 MB
maximum_object_size 204800 KB
maximum_object_size_in_memory 32 KB
cache_dir ufs /var/spool/squid  1000 16 256
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern .               0       20%     4320
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl Safe_ports port 80          # http
acl Safe_ports port 20          # ftp
acl Safe_ports port 21          # ftp
acl Safe_ports port 22          # ssh
acl Safe_ports port 443 563     # https, snews
acl Safe_ports port 70          # gopher
acl Safe_ports port 110         # pop3
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 631         # cups
acl Safe_ports port 873         # rsync
acl Safe_ports port 901         # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

#
# ATTENZIONE: Modificare con l'ip della propria rete
#

acl our_networks src 192.168.10.0/255.255.255.0
http_access allow our_networks
http_access allow localhost
http_access deny all
http_reply_access allow all
icp_access allow all
coredump_dir /var/spool/squid
extension_methods REPORT MERGE MKACTIVITY CHECKOUT

Viralator

A questo punto potete scaricare il pacchetto di Viralator da http://viralator.sourceforge.net/ e scompattarlo.
Ai file scaricati sostituite questi file che ho modificato per correggere alcuni errori (i file derivano dalla versione 0.9.4).

Quindi copiate il file viralator.cgi in /var/www/cgi-bin (o comunque nel path per gli script cgi che avete impostato in Apache 2) e la cartella etc/viralator in /etc/viralator.

default_language -> italian.txt
servername -> [nome del server]
antivirus -> CLAMAV
virusscanner -> clamscan
scannerpath -> /usr/bin
viruscmd -> --verbose --stdout
alert -> FOUND
scannersummary -> true
downloads -> /var/www/downloads
downloadsdir -> /downloads
popupfast -> false
popupback -> true
popupwidth -> 600
popupheight -> 400
filechmod -> 644
secret -> [psw]
BAR -> img/bar.png
PROGRESS -> img/progress.png

Da notare la cartella /var/www/downloads per il download temporaneo. Create questa cartella e datele i giusti permessi affinchè Viralator (quindi Apache) possa scriverci:

macondo:~# mkdir /var/www/downloads
macondo:~# chown www-data.www-data /var/www/downloads
macondo:~# chmod 775 /var/www/downloads

Tale cartella dovrà essere raggiungibile via browser col path /downloads.
Controllate anche che i percorsi dei file di Clamav siano corretti e modificate anche [nome del server] e [psw].
Infine copiate i file bar.png e progress.png dalla cartella in cui avete scompattato Viralator ad una posizione raggiungibile dal browser.

IpTables

Eccoci alla fine, come preannunciato abbiamo bisogno solo di una semplice regola di IpTables. Il suo scopo è quello di creare un cosiddetto Proxy trasparente. Ovvero le richieste degli utenti saranno automaticamente girate verso la porta 3128 (Squid) senza che essi debbano configurare l’uso del proxy nel loro pc o browser.
La regola è la seguente:

macondo:~# iptables -t nat -A PREROUTING -i eth0 -p tcp -s 192.168.1.0/24 -d ! 192.168.1.0/24 --dport 80 -j REDIRECT --to-port 3128

In questo esempio la rete è 192.168.1.0/24, il proxy sarà in ascolto sull’interfaccia eth0 e la redirezione avverrà solo sui pacchetti la cui provenienza sia la rete e la loro destinazione invece non lo sia.

Riavvio e Test

Riavviate Apache e Squid, quindi potete provare la funzionalità del marchingegno tentando di scaricare qualche file la cui estensione sia tra quelle che abbiamo impostato in /etc/squid/squidGuard/db/deny/files.
Come potrete vedere sarà effettuata la scansione sul file e solo dopo vi sarà permesso di salvarlo sul vostro pc.
Sul sito di Viralator è anche possibile scaricare un falso virus come test, provate anche questo.

Errori comuni

Il file viene scaricato anche se infetto

Se Viralator non trova l’antivirus Clamav si comporta in maniera un po’ particolare, ovvero permette il download senza effettuare la scansione.
Fate quindi attenzione che nel file /etc/viralator/viralator.conf sia il path che il nome dell’eseguibile siano corretti.
Ad esempio nel file di configurazione originale viene cercato l’eseguibile clamdscan in /usr/local/bin. in Debian il file è clamscan e si trova il /usr/bin.

“You cannot download from this site! The given url is not valid. Please contact your system administrator for details.”

Le pagine indirizzate al vostro server proxy non devono essere girate dalla porta 80 alla 3128, state quindi attenti che nel comando di iptables l’opzione -d ! 192.168.1.0/24 sia corretta e l’ip della rete sia quello corretto.

FAQ

Per qualunque altra domanda guardate le FAQ nel sito di Viralator http://viralator.sourceforge.net/

Un’alternativa: SCAVR

Un analogo risultato dovrebbe essere ottenuto con SCAVR (Squid ClamAV Redirector, un progetto che non sembra essere molto maturo).
Gli strumenti necessari sono: Python, PyClamav, Clamav, Squid e SCAVR.

Python e PyClamav

In Debian dovreste aver già installato Python, altrimenti potete installalo insieme agli strumenti necessari alla compilazione dei nuovi moduli con:

macondo:~# apt-get install python2.3-setuptools

Serve anche il pacchetto di sviluppo di Clamav:

macondo:~# apt-get install libclamav-dev

A questo punto scaricare PyClamav e scompattatelo (il pacchetto Debian in testing e unstable non funziona sulla versione stabile per alcune dipendenze mancate).
Entrate quindi nella cartella, compilate e installate il modulo pyclamav:

macondo:~# python setup.py build
running build
running build_ext
building 'pyclamav' extension
creating build
creating build/temp.linux-i686-2.3
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include/python2.3 -c pyclamav.c -o build/temp.linux-i686-2.3/pyclamav.o
creating build/lib.linux-i686-2.3
gcc -pthread -shared build/temp.linux-i686-2.3/pyclamav.o -lclamav -o build/lib.linux-i686-2.3/pyclamav.so

macondo:~# python setup.py install
running install
running build
running build_ext
running install_lib
copying build/lib.linux-i686-2.3/pyclamav.so -> /usr/lib/python2.3/site-packages

A questo punto scaricate il pacchetto di SCAVR e sscompattatelo. Quindi spostate il file di configurazione nella cartella /etc/squid e lo script in una cartella di binari (es. /usr/local/bin).
Assicuratevi che lo script abbia i giusti permessi:

macondo:~# chmod +x /usr/local/bin/SquidClamAV_Redirector.py

Bene, bisogna modificare il file di configurazione /etc/squid/SquidClamAV_Redirector.conf secondo le proprie esigenze.

Adesso si può provare il funzionamento provando a lanciare lo sript:

macondo:~# /usr/local/bin/SquidClamAV_Redirector.py -c /etc/squid/SquidClamAV_Redirector.conf
LibClamAV Warning: ********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.  ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/faq.html ***
LibClamAV Warning: ********************************************************
LibClamAV Warning: ********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.  ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/faq.html ***
LibClamAV Warning: ********************************************************
[Ctrl-D per uscire]

Se non ricevete errori lo script sta funzionando.

Per finire non resta che configurare /etc/squid/squid.conf per la redirezione verso SCAVR, aggiungendo le righe seguenti:

redirect_program /usr/local/bin/SquidClamAV_Redirector.py -c /etc/squid/SquidClamAV_Redirector.conf
redirect_children 5

Finora non sono riuscito a farelo funzionare correttamente: lo script analizza effettivamente solo i file specificati ma, anche se contengono virus, vengono poi fatti scaricare sul client.

Risorse

Viralator
Clamav
Squid
SquidGuard
PyClamav
SCAVR
Apache ]]> http://www.tommyblue.it/2006/05/07/scansione-antivirus-on-the-fly-attraverso-il-proxy/feed/ 0 http://www.tommyblue.it/2006/05/07/apache2-in-ssl/ http://www.tommyblue.it/2006/05/07/apache2-in-ssl/#comments Sun, 07 May 2006 08:42:27 +0000 TommyBlue http://www.tommyblue.it/?p=394

Creazione del certificato

macondo:~# rm -rf /root/CertAuth
macondo:~# mkdir /root/CertAuth
macondo:~# chmod 700 /root/CertAuth
macondo:~# cd /root/CertAuth

macondo:~/CertAuth# /usr/lib/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 1024 bit RSA private key
...............++++++
..............................................................++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Italia
Locality Name (eg, city) []:Firenze
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tommyblue.it
Organizational Unit Name (eg, section) []:Tommyblue.it
Common Name (eg, YOUR name) []:Tommyblue
Email Address []:info@tommyblue.it

macondo:~/CertAuth# /usr/lib/ssl/misc/CA.pl -newreq
Generating a 1024 bit RSA private key
..................++++++
...++++++
writing new private key to 'newreq.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Italia
Locality Name (eg, city) []:Firenze
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tommyblue.it
Organizational Unit Name (eg, section) []:Tommyblue.it
Common Name (eg, YOUR name) []:Tommyblue
Email Address []:info@tommyblue.it

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Request (and private key) is in newreq.pem

macondo:~/CertAuth# /usr/lib/ssl/misc/CA.pl -sign
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            9b:49:17:c6:49:1a:09:7a
        Validity
            Not Before: Oct 25 17:01:48 2005 GMT
            Not After : Oct 25 17:01:48 2006 GMT
        Subject:
            countryName               = IT
            stateOrProvinceName       = Italia
            localityName              = Firenze
            organizationName          = Tommyblue.it
            organizationalUnitName    = Tommyblue.it
            commonName                = Tommyblue
            emailAddress              = info@tommyblue.it
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                FF:E0:BB:B6:A4:03:B7:8D:8F:32:51:3D:1D:A8:E9:84:5B:7C:4B:BA
            X509v3 Authority Key Identifier:
                keyid:6A:E5:B3:7D:68:BF:19:6F:E5:3D:5A:7D:23:90:3E:03:00:2A:41:23
                DirName:/C=IT/ST=Italia/L=Firenze/O=Tommyblue.it/OU=Tommyblue.it/CN=Tommyblue/emailAddress=info@tommyblue.it
                serial:9B:49:17:C6:49:1A:09:79

Certificate is to be certified until Oct 25 17:01:48 2006 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem

macondo:~/CertAuth# openssl rsa < newreq.pem > newkey.pem
Enter pass phrase:
writing RSA key

macondo:~/CertAuth# cp /root/CertAuth/demoCA/cacert.pem /etc/ssl/certs/cacert.pem
macondo:~/CertAuth# cp /root/CertAuth/newcert.pem /etc/ssl/certs/ldapcert.pem
macondo:~/CertAuth# cp /root/CertAuth/newkey.pem /etc/ssl/certs/ldapkey.pem
macondo:~/CertAuth# chmod 600 /root/CertAuth/newkey.pem

Configurazione di Apache2

Cominciamo aprendo, oltre alla porta 80, anche la porta 443

macondo:~# echo -e "Listen 80\nListen 443" > /etc/apache2/ports.conf

Quindi attiviamo i moduli ssl necessari:

macondo:~# ln -s /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-enabled/ssl.conf
macondo:~# ln -s /etc/apache2/mods-available/load.conf /etc/apache2/mods-enabled/ssl.load

Se adesso vogliamo che il nostro server sia raggiungibile sia in http che in https dobbiamo modificare il file /etc/apache2/sites-available/default:

NameVirtualHost *

diventa

NameVirtualHost *:80
NameVirtualHost *:443

La parte successiva (tra <VirtualHost *> e </VirtualHost>) deve essere replicata, sostituendo <VirtualHost *> con <VirtualHost *:80> in un caso e <VirtualHost *:443> nell’altro. Infine inserite le righe seguenti in <VirtualHost *:443>

 <VirtualHost *:443>
   <IfModule mod_ssl.c>
    SSLEngine on
    SSLCACertificateFile        /etc/ssl/certs/cacert.pem
    SSLCertificateFile          /etc/ssl/certs/ldapcert.pem
    SSLCertificateKeyFile       /etc/ssl/certs/ldapkey.pem
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
   </IfModule>
...
...
...

Se non lo fosse attiviamo il file appena modificato creando un link simbolico:

macondo:~# ln -s /etc/apache2/sites-available/default /etc/apache2/sites-enabled/000-default

Infine riavviamo Apache2:

macondo:~# /etc/init.d/apache2 restart