I passaggi sono piuttosto facili:
intanto bisogna collegarsi all’amministrazione di Zimbra e creare un utente nel dominio principale (nel mio caso redmine). Personalmente ho disattivato tutte le opzioni (posta, rubrica, documenti, ecc.) per questo utente, tanto serve solamente per il binding a LDAP.
Una volta creato possiamo provare che questo utente possa fare ricerche nell’albero:

ldapsearch -b ou=people,dc=tommyblue,dc=it -h zimbra.tommyblue.it -p 389 -D uid=redmine,ou=people,dc=tommyblue,dc=it -w s3cr3t uid

Se la ricerca funziona avete finito con Zimbra e potete passare a Redmine. Qui bisogna andare in Autenticazione LDAP e inserire i dati in questo modo:

• Nome: Zimbra (è solo descrittivo)
• Host: zimbra.tommyblue.it (l’host con Zimbra)
• Porta: 389
• Utente: uid=redmine,ou=people,dc=tommyblue,dc=it
• Password: s3cr3t
• DN Base: ou=people,dc=tommyblue,dc=it
• Creazione utente “al volo”: no
• Utente: uid
• Nome: givenName
• Cognome: sn
• Email: mail

Ecco uno screenshot per rendere il tutto più chiaro:

Per finire dovete creare un utente in Redmine selezionando come Modalità di Autenticazione quella appena creata e non quella interna.

Ovviamente è possibile replicare il procedimento per qualunque albero LDAP abbiate a disposizione.

Questa tecnica implica il montaggio di un obiettivo al contrario e si può fare in due modi: montando un obiettivo al contrario direttamente sul corpo macchina oppure montando normalmente un obiettivo e poi mondandoci sopra un altro obiettivo al contrario.
Per realizzare queste tecniche si possono usare anelli appositi o accrocchi più o meno artigianali; io ho acquistato un anello ad inversione per l’obiettivo singolo (10€) e ho attaccato 2 anelli Cokin serie P per ottenere una doppia filettatura maschio e aggangiare due obiettivi tra loro.

In entrambi i casi bisogna (ad esempio con un pezzetto di carta) tenere aperto il diaframma dell’obiettivo rovesciato altrimenti non entra luce a sufficienza per scatti “rapidi” (necessari se si fotografa qualcosa che non sta assolutamente fermo). Il contro è che l’area di messa a fuoco è veramente stretta, specialmente con i due obiettivi accoppiati (credetemi, è VERAMENTE stretta!). Ho letto che vi sono alcune tecniche per limitare questo effetto, dovrò fare qualche prova…

Utilizzando un solo obiettivo si ottengono risultati piuttosto buoni e si può fotografare anche a mano, con i due obiettivi accoppiati bisogna quasi obbligatoriamente utilizzare il cavalletto, ma l’ingrandimento è veramente incredibile! Per la messa a fuoco, dopo un primo abbozzo, muovo la testa leggermente avanti e indietro e mi aiuto con gli scatti multipli.

Per concludere ecco una serie di foto fatte ad una colonia di formiche, la prima è fatta con un 200mm per rendere meglio l’idea di quanto sia potente questa tecnica (basta fare un contronto con l’ultima foto). Per altre foto potete dare uno sguardo al set su Flickr.

Di base non ci sarebbe niente di strano dato che le ALIX sono x86-compatible, però non fanno boot da usb (e se anche lo facessero, non sono riuscito a rendere bootabile Endian su una penna usb…).

C’è quindi da fare un arzigogolo un po’ particolare: è necessario un pc a cui staccare gli hard disk e a cui attaccare la Compact Flash con il suo lettorino USB. A questo punto se si avvia da cdrom la iso di Endian, il s.o. trova solo la compact flash e la prende per il suo hard disk (sda), installandocisi.
Al termine basta, prima del primo riavvio, staccare la compact flash e attaccarla alla mobo ALIX. Sarà possibile proseguire la configurazione via web all’indirizzo ip indicato in fase di installazione.
NB: Se volete accedere al s.o. via seriale, ditelo all’installer durante uno dei passaggi dell’installazione.

Piuttosto facile, vero?
E infatti lo spippolo di ieri è durato troppo poco e al termine mi sono preso il tempo di provare qualche player di video HTML 5 utilizzando, per l’occasione, un video di pochi secondi realizzato al nuovo firewall mentre faceva il suo duro lavoro.

Se il vostro browser lo supporta, buona visione!

Nella foto qui sopra potete notare il caos ordinato sulla mia scrivania all’inizio della serata, chissà alla fine… :-)

Eppure ho sempre evitato di bloccare l’accesso al sito a chi (stolto!) utilizza ancora l’oggetto del male (ben il 21,3% dei visitatori…).

Oggi però ho scoperto Free the Foxes, un JS molto carino e personalizzabile che invita i possessori di browser non compatibili a scaricarne uno migliore.
Da questo momento, quindi, chi visita questo sito utilizzando IE 6 e 7 (rispettivamente il 5,8% e il 3,4%) riceverà un avvertimento.

E il vostro browser? Controllate cliccando qui!

Supponendo che abbiate già installato Rubygems, installare RVM è praticamente immediato:

~# gem install rvm
~# rvm-install

A questo punto si può installare una qualsiasi versione di Ruby con:

~# rvm install 1.9.2-head

e switchare tra le versioni con:

~# rvm use 1.9.2-head
~# ruby -v
ruby 1.9.2dev (2010-05-07 trunk 27656) [x86_64-darwin10.3.0]
~# rvm use default
~# ruby -v
ruby 1.8.7 (2009-06-08 patchlevel 173) [universal-darwin10.0]

Attenzione che ogni nuova installazione ha le sue gemme, quindi sarà necessario installare quelle richieste, nel mio caso, volendo utilizzare Ruby 1.9.2 per provare Rails 3:

~# rvm use 1.9.2-head
~# gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n
~# gem install rails --pre

Partigiano Ennio Sardelli “Fuoco”

Intendo che i miei tempi non funzionano in base alla sequenza lun-ven=lavoro e sab-dom=riposo, ma più in base ad una sequenza semicasuale.

Spesso infatti lavoro (o studio) il sabato e la domenica e ho dei giorni liberi durante la settimana. Ieri, ad esempio, ho passato un ottimo pomeriggio passeggiando per Monte Morello (era giovedì) e probabilmente passerò la domenica davanti alla shell.

Non fosse che è un casino far coincidere i propri impegni con quelli del resto del mondo, questa traslazione risulta molto interessante per i giorni liberi: quasi sempre il luogo in cui si va a bivaccare è praticamente vuoto e soprattutto si può scegliere il giorno di ferie in maniera più libera (evitando, ad esempio, la famosissima coppia unica domenica libera del mese <=> peggiore tempesta tropicale del secolo).

Su ESXi versione 4, per abilitare il server SSH basta effettuare questi passaggi:

1. Premere Alt+F1
2. Digitare unsupported (non vedrete nulla a schermo)
3. Verrà chiesta la password di root
4. Una volta entrati editare il file /etc/inetd.conf (usando vi o un altro editor)
5. Decommentare le riche riguardanti SSH (ovvero togliere il cancelletto #). Ci sono due righe riguardanti SSH, una per TCPv4 e una per TCPv6
6. Lanciare services.sh restart

Se dopo questi passaggi ancora non è possibile accedere bisogne identificare il PID di inetd (con ps aux | grep inetd) e poi riavviarlo con kill -HUP <pid>

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.mailalyzer.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