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.

Oltre a permettervi di avere sotto controllo in real-time lo stato di tutte le macchine e di tutti i servizi, Nagios è in grado di avvisarvi (con e-mail, SMS, chat, ecc.) in caso di malfunzionamenti.

È inoltre possibile monitorare nel tempo lo stato dei sistemi e ottenere un numero incredibile di grafici e report.

Kreations Collective ha una vasta esperienza nell’installazione e nella configurazione di Nagios anche in grandi infrastrutture. Se per il vostro servizio non esiste un plugin di controllo, possiamo scriverne uno ad-hoc.

L’infrastruttura sistemistica include un firewall Endian Firewall, un PDC gestito da un server Samba, un server dedicato ai backup e una cluster di rendering che conta circa 30 server.

http://www.ilogo.it

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

Lo scopo del progetto è creare un software che analizzi i log di Postfix e li salvi su MySQL. Utile, ad esempio, per l’integrazione con un software di E-mail marketing in modo da verificare l’andamento delle campagne.

Il software, scritto in Ruby, è agli inizi ma le funzionalità di base ci sono ed è stabile, se siete interessati partecipate al suo sviluppo!

http://www.tesoridacastiglionfiorentino.it

La cosa più semplice da fare è avviare il pc con una live ubuntu e lanciare dalla riga di comando
ms-sys -w /dev/sda (da sostituire con il device corretto).

Questa è la soluzione che si trova ovunque in rete. Sfortunatamente (e questo in rete non c’è scritto ) le nuove verisone live di ubuntu non includono il pacchetto ms-sys (non lo si trova nei repository), io ho risolto così:

sostituire ARCH con i386 o amd64 in base all’architettura della live e DEVICE con l’identificativo del device corretto (in genere o hda o sda)


$ sudo -s
# wget http://ftp.it.debian.org/debian/pool/main/m/ms-sys/ms-sys_2.1.0-1_ARCH.deb
# dpkg -i ms-sys_2.1.0-1_*
# ms-sys -m /dev/DEVICE


A quetso punto basta riavviare e tutto funzionerà come ci si aspetta con l’avvio di windows.

I programmatori e i sistemisti di Kreations Collective hanno esperienza nella creazione di software per l’e-mail marketing e nella configurazione dei server necessari all’invio delle email.

Se sei interessato ad un preventivo o vuoi farci delle domande, contattaci dall’apposita pagina.

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

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