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 »

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 »

Proxmox (virtualizzazione)

Scritto da Andrea Posarelli il 3 Aprile 2011 |

Nel settore della virtualizzazione si stanno muovendo un sacco di attori, da VmWare (uno dei leader) a Microsoft (Hyper-V), passando per Citrix fino alle declinazioni Open Source (Xen, KVM, OpenVZ) ecc.

KVM in particolare essendo stato integrato nello sviluppo del Kernel di Linux, sembra essere candidato a rimpiazzare almeno Xen nelle preferenze degli utenti Linux. Red Hat Enterprise sta costruendoci intorno una sua soluzione “professionale”.

Come spesso accade a determinare una scelta piuttosto che un altra, oltre alla bontà intrinseca della tecnologia, buona parte della differenza la fanno gli strumenti di amministrazione (non a caso un vanto di VmWare).
A questo proposito una azienda europea, sta lavorando molto bene in questo settore producendo una distribuzione basata su Debian che include KVM e OpenVZ come tecnologie, aggiungendovi validi e intuitivi strumenti di amministrazione basati su Web. SI tratta di “Proxmox

Leggi il resto »

History command

Scritto da Andrea Posarelli il 14 Settembre 2010 |

Il comando History digitato nel terminale e’ molto utile, in quanto riporta tutti i comandi precedentemente digitati.

L’uso più frequente che si fa di solito dell’history file e’ quando richiamiamo un comando precedente dentro la shell, cliccando sulla freccia in alto.

La lunghezza dell’elenco e’ variabile e puo’ essere allungata o diminuita.
Se utilizzato insieme a grep diventa molto utile per trovare comandi digitati in precedenza di cui non si ricordano che parti o porzioni…

Non esiste un vero e proprio manuale come negli altri comandi classici da terminale, perche’ history e’ un comando della shell e non di sistema.

Per sapere le opzioni non si digita infatti man history, bensì: help history (…continua) Leggi il resto »

“Screen” command

Scritto da Andrea Posarelli il 16 Settembre 2009 |

Il comando screen risulta utile quando dobbiamo lanciare script da terminale su una macchina remota che necessitano di una elaborazione particolarmente complessa o lunga. in quel caso possiamo utilizzare il comando “screen” e poi lasciare chiudere tranquillamente la nostra sessione terminale, sicuri di poter controllare in seguito l’esito del comando. In pratica e’ come aprire un terminale in un altro terminale, dargli un nome e collegarsi ad esso quando si vuole. Su OsX dovrebbe essere installato de default, se nella vostra distribuzione Linux non c’e’ lo si puo’ installare richiamando il proprio package manager di riferimento, ad es. con yum su Fedora/RedHat o apt-get su Debian/Ubuntu:

Fedora/redhat: sudo yum install screen
Debian/Ubuntu: sudo apt-get install screen


Leggi il resto »

MacOsX package management system

Scritto da Andrea Posarelli il 11 Settembre 2009 |

mlogoGrazie alla base Unix di OsX, e’ possibile implementare sistemi di package management sullo stile di apt-get o rpm, divenuti popolari su Linux.

macports-logo-topQuesti sistemi consensono un notevole risparmio di tempo se si vuole installare software originariamente pensato per linux che di norma su OsX va ricompilato da zero, passando appunto dalla compilazione del codice sorgente.
Un esempio (tra i piu’ semplici in verita’) lo abbiamo visto proprio per l’installazione di wget.

inspector

Fink Commander

I sistemi di pacchettizzazione grazie ai loro repository di binari, sono comodi proprio perche’ evitano ove possibile, questa trafila potendo accedere direttamente alla versione binaria del programma da installare e mantenendo una centralizzazione del software installato con la possibilita’ di disinstallarlo a piacere.

Schermata 2009-09-08 a 17.17.38

Porticus

Su Mac i sistemi piu’ popolari sono Fink (una ripropositione vera e propria di apt-get) e i MacPorts che invece implementa un sistema di pacchettizzazione che deriva dall’ambiente BSD.
Entrambi i sistemi possono essere utilizzati senza problemi sia su Leopard che su Snow Leopard.
Entrambi dispongono di una comoda interfaccia grafica di gestione che consente di installare al volo programmi.
Personalmente preferisco il sistema di MacPorts.

Per quanto riguarda i programmi di gestione ne segnalo due free e due a pagamento: