Portare il DNS sulla nuvola.

Scritto da Andrea Posarelli il 31 Ottobre 2013 |

Il DNS è un servizio di per se’ leggero ma fondamentale per il funzionamento dei domini (e a cascata di molti altri servizi).
La necessità di concentrare la gestione del DNS di un dominio e non delegarlo al pannello del registrar è abbastanza intuibile: molti registrar = molti pannelli da amministrare, quindi dispersione di energie, tempo e risorse.

Sistema-di-DNS-secondario-esterno-(cloud)

Portarsi il DNS in “casa” d’altronde vorrebbe dire costruirci intorno una serie di ridondanze che evitino ogni tipo di blackout o interruzione di servizio e può essere considerato in molti casi un overkill.

Quello che propongo in questo piccolo “draft” (ingrandisci l’immagine) è un approccio “misto” che consiste nel costruirsi un DNS primario (Master) da gestire in proprio e che vada a popolare un DNS slave (o meglio ancora un cloud di DNS slave).
Ovviamente il master DNS in questo scenario NON può essere autoritativo per ovvi motivi (non è cioè raggiungibile 24/24 proprio per “design”).
Il trucco è quello di promuovere come autoritativo il DNS slave (configurato su un gestore terzo con una buona struttura).
Per farlo basta designarlo come tale nel pannello del nostro registrar quando andiamo a gestire i DNS del dominio (la nomenclatura dell’operazione varia da registrar a registrar ).

Questo approccio ci consente molteplici vantaggi a fronte di una piccola scomodità.
Vantaggi:
– Il master DNS  può stare ovunque ed essere messo offline quando vogliamo in quanto le zone secondarie (slaves), una volta popolate nel cloud, continueranno ad esistere e funzionare indipendentemente dalla raggiungibilità del nostro master DNS.
– Ciononostante ogni volta che vorremo fare una modifica a una zona presente nel nostro DNS potremo farla comodamente nel nostro master il quale automaticamente andrà ad eseguire le modifiche sui DNS slaves esterni.
– Un altro vantaggio considerevole è che il DNS “interno” che è il primario (ma appunto non autoritativo) può essere protetto e reso inaccessibile dall’esterno in modo semplice, con una regoletta nel firewall,  in quando dovrà accettare connessioni solo e soltanto dai DNS secondari.
– Di conseguenza non sarà neanche necessario provvedere a una infrastruttura per il DNS primario complessa ed estesa, come vedremo.
Svantaggi:
– Avremo a che fare con DUE pannelli/sistemi di gestione (se escludiamo quello dei vari registrars nei quali dobbiamo soltanto impostare i nameservers nel momento di registrarlo), e cioè quello del master DNS e quello dei DNS slaves nei quali dovremo definire comunque la prima volta il nome della zona e l’IP del DNS primario che abbiamo in casa, questo comporta anche che se una zona viene cancellata nel Master, essa dovrà comunque essere cancellata a mano anche nello slave. [continua…]. Leggi il resto »

Email Marketing, alcune considerazioni…

Scritto da Andrea Posarelli il 17 Gennaio 2013 |

19378216Non sono un uomo di marketing e mi intendo poco di pubblicità, ma poichè mi arrangio facendo il sistemista devo dire che ho visto direttamente le conseguenze pratiche sui server di posta di campagne di mass-mail sbagliate o fatte male da parte di clienti ansiosi di inviare le proprie comunicazioni ai loro rispettivi clienti.
Queste conseguenze si traducono in segnalazioni multiple da parte di persone giustamente arrabbiate per aver ricevuto messaggi di posta non richiesti, quando non addirittura sanzioni e IP di interi server e linee blacklistati nelle maggiori black list.

Credo molto nella diffusione della conoscenza e penso che ciò significhi anche educare al corretto uso degli strumenti in modo che tutti possano giovarsene ricevendone benefici invece di creare danno a sè stessi e agli altri.

Ecco quindi che ho tradotto in italiano una parte di un white paper di Mailchimp, uno dei più grandi provider leciti di mass mailing, che tiene molto alla propria reputazione visto che su queste cose ci campano.
Loro stessi mettono a disposizione una grande scorta di documenti pubblici sul loro sito [http://mailchimp.com/resources/] In particolare ho tradotto molto al volo la parte riguardante il mail marketing e le buone politiche da implementare per la creazione delle proprie liste di questo paper: Email Marketing Field Guide
Nel seguito dell’articolo la traduzione…
Gli utenti registrati possono stampare questo articolo in PDF, gli altri possono trovare il link da scaricare in fondo all’articolo

Leggi il resto »

Piattaforma Soekris

Scritto da Andrea Posarelli il 7 Giugno 2012 |

Vista frontale Abbiamo parlato di Alix come piattaforma ideale per piccoli gruppi di utenti (anche 20 e oltre a seconda del tipo di configurazione) votata alla installazione di Linux o FreeBSD e da dedicare all’utilizzo di firewall di rete.

Se si volesse fare il passo successivo e si volesse rimanere nell’ambito delle mother board dedicate ma comunque con processori Intel o compatibili, senza per questo comprare dispendiosi server o box artigianali, si può considerare Soekris come piattaforma. Leggi il resto »

Firewall Alix + PfSense

Scritto da Andrea Posarelli il 27 Marzo 2012 |

PfSense è una distribuzione software derivata da Mon0Wall (a sua volta basata su FreeBSD), che permette di costruirsi un firewall di grandi potenzialità e che a seconda del tipo di hardware che gli mettiamo a disposizione, può anche gestire reti complesse e di grandi dimensioni.

Per approfondire le caratteristiche di PfSense vi rimandiamo al sito che spiega nel dettaglio le features di questo prodotto.
Oggi vogliamo installare questo software su un particolare hardware, dimensionato per piccoli uffici e piccoli gruppi di persone (direi max. 10/20 utenti a seconda del lavoro che deve svolgere il firewall): le schede Alix di PCEngines. Leggi il resto »

Un piccolo risultato…

Scritto da Andrea Posarelli il 11 Novembre 2011 |

Dear Andrea Posarelli,

We are pleased to inform you that you have successfully passed the NETASQ ADMINISTRATOR Version 9 certification.

🙂

CERTIFICATO

Deploy con Munki

Scritto da Andrea Posarelli il 19 Agosto 2011 |

In un articolo precedente abbiamo trattato questa metodologia/tecnologia per l’installazione di applicativi su più macchine OsX dalle interessanti caratteristiche e sviluppata da Google per i suoi lab.

La caratteristica base è che il repository dei files può essere manutenuto su qualsiasi server Web (Apache), quindi può andare bene OsX ma anche Linux o un NAS.
Utilizzando il protocollo HTTP poi otteniamo alcuni vantaggi basilari: in particolar modo la velocità del deploy rispetto ad altri protocolli specifici o ad hoc, secondariamente un protocollo standard come HTTP non richiede di solito modifiche importanti sulle policy di sicurezza.
Per approfondire le caratteristiche comunque rimandiamo a questo articolo

Affrontiamo oggi un caso pratico sulla base della documentazione esistente.

Leggi il resto »

Debian + Proxmox su Apple Xserve

Scritto da Andrea Posarelli il 25 Maggio 2011 |

Prima di abbandonare al loro destino queste macchine che Apple ha deciso di non tenere più in produzione, voglio dare qualche indicazione su come ne ho recuperata una e l’ho messa al lavoro in modo interessante e un po diverso dal solito.

La macchina era un vecchio server web/ftp che nel momento di maggior gloria ha servito anche 200 domini. Da allora sono passati alcuni anni e i domini sono migrati in un server web Linux per una serie di motivi, tra i quali ha pesato molto l’assenza di un pannello di configurazione e deploy di clienti/servizi/utenti ecc come ne esistono invece in ambito Linux (Plesk, cPanel).
Abbiamo quindi ritirato la macchina dal Data Center nel quale era ospitata per decidere che farne.
La macchina e’ un XServe Late 2006, primissima versione Intel (codice Apple 1,1), con alimentazione ridondata (doppio alimentatore), un doppio Xeon 2,0 GHz dual core, 6GB di Ram, e sopra vi era installato un vetusto OsX Server 10.4.11.
Non abbiamo provato ad utilizzare un MacPro della stessa generazione (codice 1,1) in produzione dal 2006 al 2008, ma TEORICAMENTE dovrebbe funzionare in quanto si tratta di hardware analogo.
Avevamo davanti alcune possibilità: rimetterla in piedi con un Os Apple aggiornato e riutilizzarla come server Apple, oppure installarci Debian e poi inserirla nel Cluster Proxmox che abbiamo gia in funzione nel nostro Data Center. Opzione finale: una triste rottamazione…

Leggi il resto »