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

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

La soluzione esiste ed è interessante che comporti l’uso di un terzo software di emulazione: QEMU :-)

L’utility che ci serve è qemu-img che nell’installazione Mac si trova in /Applications/Q.app/Contents/MacOS/qemu-img

La conversione è molto semplice e non richiede troppo tempo:

cd /Applications/Q.app/Contents/MacOS/
./qemu-img convert /path2virtualbox/img2convert.vdi  /path2vmware/converted_img.vmdk

• Tesina sul gioco dell’8
• Tesina apprendimento – dataset diabetes

:g/^\s*#.*/d

mi resta da capire perché questa seconda regexp non funziona:

:g/^[# ]+.*/d

Ma veniamo ai fatti!

Apple Safari

Non c’ho mai avuto troppa confidenza. Per tutti un browser veloce, a me è sempre sembrato lento. Forse è solo una questione di feeling, ma per quanto, periodicamente, ci riprovi, non riesco a usarlo più di tanto (la stessa cosa mi succede con Mail). In particolare non riesco a trovarmi bene con le password salvate (troppo “incastrate” con quelle di sistema) e gli shortcut, che sono troppo cervellotici (direi una caratteristica di casa Cupertino). Anche la barra degli strumenti non mi convince: personalizzabile ma solo fino a un certo punto.
A quando le estensioni?
Sebbene il giudizio sembri totalmente negativo, Safari in un certo qualmodo mi intriga e so che il mio giudizio non è definitivo.

Google Chrome

Veloce e pratico. A Google sanno (s)fruttare l’esperienza fatta dagli altri (che tutto sommato è un pregio): vi trovo quasi tutte le cose che mi piacciono di Firefox. Non mi sono trovato troppo bene con i preferiti e la gestione dei download, perdipiù, ancora in beta, spesso crasha (riesce comunque sempre a recuperare i tab aperti). L’attuale (e temporanea) mancanza di estensioni mi limita troppo, motivo per cui è stato, per ora, messo nel cassetto.

Mozilla Firefox

Il vero motivo per cui nasce quest’articolo, punto di inizio e fine: usato per anni, l’ho “abbandonato” qualche settimana per testare gli altri browsers.
La scelta di cambiare è stata causata dalla sua lentezza nel caricarsi, sicuramente derivante da anni di lavoro in cui gliene ho fatte di tutti i colori, tra estensioni, about:config e altro.
Ma prima o poi, si sa, si torna a casa e così è stato anche stavolta: in queste settimane ho continuato comunque a usare Firefox per fini lavorativi, in particolare a “causa” delle estensioni Firebug, WebDeveloper e ColorZilla, ma dopo la fallita ricerca di alternative a estensioni come Delicious, la libera aggiunta di motori di ricerca e il tanto agognato feeling, sono tornato ad usarlo in pianta stabile, comunque con un occhio sempre puntato sui “rivali”.
Per chi non lo avesse ancora fatto, consiglio anche l’uso del suo figlioletto Flock.

Quindi?

Niente. Queste sono le mie impressioni, nel giudizio pesa sicuramente la scelta del sistema operativo Mac OSX “Snow Leopard”. Su Linux, oltre a non avere Safari, Chrome avrebbe dato sicuramente un’impressione migliore.
Invito chiunque voglia ad aggiungere i propri pareri su questi e altri browser

Ho recentemente configurato alcuni server per l’invio di email. Parte del lavoro ha riguardato la corretta configurazione di Postfix e del server DNS per evitare che le email inviate venissero rilevate come spam.
In una diversa guida spiegherò come ottimizzare la configurazione di Postfix per grandi quantità di email (≥1.000.000/mese). Dato che già in molti me lo hanno chiesto: no, non si tratta di server per l’invio di spam, ma server per il mail marketing (quando il servizio sarà pubblico potrò tranquillamente rivelarne il nome).

La configurazione ha riguardato tre punti principali:

• Impostazione del record A e del reverse address
• Impostazione di SPF
• Configurazione di DKIM e DomainKeys

Record A e Reverse Address

Per iniziare, il server SMTP deve avere un record DNS di tipo A associato. Quindi, ad esempio:

mailer1.mydomain.com IN A 12.34.56.78

Tale impostazione è a carico del proprietario del dominio mydomain.com (ovvero: voi).
Allo stesso tempo bisogna impostare il DNS inverso per una corretta risoluzione: infatti il server che riceverà una mail dall’ip 12.34.56.78, che dice di essere mailer1.mydomain.com, vorrà avere riscontro di tale associazione IP<=>Dominio. Effettuerà quindi una risoluzione DNS inversa che, nel caso in esempio, dovrà restituire mailer1.mydomain.com. Questa configurazione è a carico del fornitore della connettività e dell’ip, generalmente coloro che vi forniscono l’hosting.

Per verificare la corretta configurazione basta usare dig:

~$ dig +short mailer1.mydomain.com
12.34.56.78 

~$ dig +short -x 12.34.56.78
mailer1.mydomain.com.

Sender Policy Framework

Sebbene non nuovissimo, SPF è largamente utilizzato e una sua corretta configurazione permette già una certa sicurezza nel fatto che le mail inviate non vengano riconosciute come spam. Si tratta semplicemente di impostare un record DNS di tipo TXT indicante quali server sono autorizzati ad inviare email per tale dominio.

Le configurazioni possibili sono molte (potete consultarle nell’RFC 4404), nel nostro caso il record potrebbe essere:

v=spf1 mx ip4:12.34.56.78 ~all

Oltre alla versione (v=spf1), indica che gli host con associato un record MX per il dominio, oltre al server con ip 12.34.56.78, possono inviare email. Inoltre indica, con ~all, che tale configurazione comprende tutti i possibili host che inviano email per il dominio.

Potete utilizzare questo tool per creare i vostri record SPF.

DKIM e DomainKeys

DomainKeys e DKIM sono due sistemi per la verifica del mittente nel dominio e l’integrità del messaggio. Entrambi utilizzano il sistema a chiave pubblica/privata: la chiave pubblica è distribuita in un record DNS e la chiave privata viene utilizzata dal server SMTP per firmare l’email prima del suo invio. DomainKeys è nata in casa Yahoo (che, tra i grandi ISP, è l’unica che lo utilizza, a quanto ne so), DKIM (DomainKeys Identified Mail) è la sua evoluzione.

Nel mio caso uno tra i requisiti del server è quello di permettere la personalizzazione dei campi From e Reply-To mentre il collegamento col server di invio è rappresentato dal campo Return-Path valorizzato con il dominio del server. Data la difficoltà nell’impostare DomainKeys con tale configurazione e data la sua scarsa diffusione, mi sono intanto limitato alla configurazione di DKIM per la quale ho seguito questa guida con alcune modifiche.

Si inizia installando dkim-filter:

~$ sudo apt-get install dkim-filter

e generando le chiavi per il server con l’apposito tool

~$ dkim-genkey -s mailer1 -d mydomain.com -t

Dopo questo comando nel file mailer1.private vi sarà la chiave privata mentre nel file mailer1.txt una possibile configurazione per il record DNS:

mailer1._domainkey IN TXT "v=DKIM1; g=*; k=rsa; t=y; p=MIGfMA0GC[...cut...]8FsXOPbuUQIDAQAB" ; ----- DKIM mailer1 for mailalyzer.com

Sebbene questo record sia corretto, le opzioni sono molte e consiglio un’attenta lettura degli RFC (linkati sulla pagina dedicata di WikiPedia), in particolare potreste essere interessati a modificare “t=y;” in “t=;” dichiarando che il servizio di firma non è in fase di test. A tale record consiglio di aggiungerne un secondo, più generale:

_domainkey.mydomain.com. IN TXT "o=~"

che indica che non tutte le email generate dal dominio vengono firmate (l’alternativa è “o=-“).

A questo punto si prosegue con la configurazione del file /etc/default/dkim-filter. Basta decommentare una delle righe che specificano un socket. Io ho scelto di utilizzare:

SOCKET="inet:20209@localhost"

Proseguiamo quindi con /etc/dkim-filter.conf. Riporto tutte le configurazioni fatte, ricordandovi che tale configurazione è studiata per permettere la personalizzazione dei campi From e Reply-To (e quindi una sorta di configurazione multidominio):

Syslog                  yes
SyslogSuccess           yes
UMask                   022
UserID                  dkim-filter:dkim-filter
Socket                  inet:20209@localhost
Domain                  *
Selector                mailer1
AutoRestart             yes
Background              yes
Canonicalization        simple
DNSTimeout              5
Mode                    sv
SignatureAlgorithm      rsa-sha1
SubDomains              no
X-Header                yes
Statistics              /var/log/dkim-filter/dkim-stats
AllowSHA1Only           no
AlwaysAddARHeader       no
AutoRestartRate         10/1h
Canonicalization        simple/simple
KeyList                 /etc/mail/dkim/keylist
MTA                     MSA
On-Default              reject
On-BadSignature         reject
On-DNSError             tempfail
On-InternalError        accept
On-NoSignature          accept
On-Security             discard
PidFile                 /var/run/dkim-milter/dkim-milter.pid
RemoveOldSignatures     yes

Il file /etc/mail/dkim/keylist contiene:

*:mydomain.com:/etc/mail/dkim/keys/mydomain.com/mailer1

mentre il file /etc/mail/dkim/keys/mydomain.com/mailer1 contiene la chiave privata, ovvero il file mailer1.private precedentemente creato, spostato in una cartella adatta e con i giusti permessi:

~$ mv mailer1.private /etc/mail/dkim/keys/mydomain.com/mailer1
~$ chmod 600 /etc/mail/dkim/keys/mydomain.com/mailer1
~$ chown dkim-filter:dkim-filter /etc/mail/dkim/keys/mydomain.com/mailer1

Se il server di invio email riceverà email da altri server (di cui è quindi un relayhost) sarà necessario specificare quali sono i server “fidati”. Quindi nel file /etc/dkim-filter.conf bisogna aggiungere:

InternalHosts           /etc/mail/dkim/trusted-hosts

e bisogna creare il file /etc/mail/dkim/trusted-hosts contenente (uno per linea) gli indirizzi ip dei server (attenzione che contenga anche l’indirizzo ip di localhost, 127.0.0.1).

Per concludere è necessario configurare Postfix per firmare le email, aggiungendo nel file /etc/postfix/main.cf:

smtpd_milters = inet:localhost:20209
non_smtpd_milters = inet:localhost:20209
milter_protocol = 2
milter_default_action = accept

Adesso basta far partire i due demoni e si può provare ad inviare una email:

~$ sudo /etc/init.d/dkim-filter start
~$ sudo /etc/init.d/postfix start
~$ echo "Questa email è una prova" | mail -a "From: qualcosa@miodominio.it" -a "Reply-To: dilloame@dominio.it" -s "Email di test" recipient@dominioricevente.it -- -f mailer1@mydomain.com

In /var/log/mail.log potete verificare l’avvenuta firma:

Jan 18 00:26:35 mailer1 dkim-filter[21178]: XXXXXXXXXX "DKIM-Signature" header added

Se inviate la mail a un dominio yahoo.com o gmail.com potete verificare subito se la firma ha avuto successo. Ad esempio ecco l’header di una mail ricevuta da Yahoo:

Authentication-Results: mta1169.mail.mud.yahoo.com  from=miodominio.it; domainkeys=neutral (no sig); from=mydomain.com; dkim=pass (ok)

Questa prima guida è conclusa. Spero di riuscire a trovare a breve una soluzione per la configurazione di DomainKeys in modo da poter integrare questo articolo

L’utilità di avere i giochi in formato ISO è, ad esempio, quella di poterli poi caricare su un hard disk USB per lanciarli direttamente con HomeBrew Channel e USB Loader GX senza dover cambiare dvd in continuazione.

Dopo aver inserito il disco aprite Utility disco e selezionate il dvd. Quindi cliccate su Nuova immagine e salvate con le opzioni standard. Verrà creata un’immagine di tipo dmg.

Il secondo passaggio consiste nell’aprire il terminale e utilizzare questo comando:

hdiutil convert nomefile.dmg -format UDTO -o nomefile.iso

Al termine dell’operazione (pochi minuti rispetto all’interminabile creazione del file dmg) il file avrà estensione .iso.cdr. Rinominatelo .iso e, se volete, cambiate la regione del gioco utilizzando WiiJunkies.

Se poi volete caricare l’iso su un hard disk usb utilizzate WBFS for MacOS X