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 »

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 »

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 »

Lion Server, Pro & Cons

Scritto da Andrea Posarelli il 16 agosto 2011 |

Insieme a Lion, Apple ha rilasciato la corrispondente versione “server” con parecchie novità. In questo articolo vogliamo approfondire tutte queste novità prendendo in considerazione i pro e i contro e cosa cambia per gli utenti della versione server.
La prima grossa novità proviene dal fatto che Lion Server non è distribuito come in precedenza, come un OsX a parte, ottimizzato per l’uso Server, ma è un pacchetto software che si installa su qualsiasi Lion a un costo che è una frazione del precedente (499€ contro gli attuali 39€)
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 »

Shock The “Munki”!

Scritto da Andrea Posarelli il 19 marzo 2011 |

Munki e’ un toolset di strumenti dedicato al deployement applicativo su OsX funzionante per pochi Mac fino a un numero considerevole, nell’ordine delle centinaia di macchine.
Esistono vari strumenti in grado di installare massivamente (deploy appunto) applicazioni su Mac.
Molti di questi tools sono commerciali, Munki invece e’ un progetto sviluppato da Google per i suoi laboratori (evidentemente hanno parecchi Mac da gestire) e rilasciato in licenza Apache 2.0 quindi come software libero.

Sostanzialmente si tratta di un repository di applicativi funzionante sotto http (per il repo-server basta un Apache, quindi va bene anche un Linux per es.) per l’installazione di programmi orientati al Mac (siano essi updates di sistema che programmi di terze parti), dalle caratteristiche interessanti. Leggi il resto »