AZ Network Specialist

Per ISP che vogliono appoggiarsi a servizi di alta qualità
Per ISP che vogliono raggiungere nuovi obiettivi

Tanti Auguri!

Le festività Natalizie si avvicinano e in molti si godranno il meritato riposo. Nel periodo dal 25 Dicembre 2013 al 12 Gennaio 2014, i nostri uffici rimarranno chiusi anche se manterremo comunque un presidio tecnico per garantire continuità dei servizi: gli ordinari contatti via email, fax e telefono saranno sempre operativi, ma esclusivamente per richieste urgenti.

A tutti voi, i migliori auguri di Buon Natale e Felice Anno Nuovo!

Lo staff di AZNS

Buon Natale e Felice Anno Nuovo

Configurazione Protezione SSL Per Posta Elettronica

Sempre più persone stanno utilizzando connessioni protette su protocolli criptati per collegarsi ai nostri server di posta. Dato che la molteplicità di possibili settaggi può dare adito ad errori di configurazione, riassumiamo brevemente quali dati impostare.

Posta in arrivo con protocollo IMAPs

  • Nome server: mail.azcloud.it
  • Porta: 993
  • Tipo di sicurezza: SSL/TLS
  • Metodo di autenticazione: Password normale

Posta in arrivo con protocollo POP3s

  • Nome server: mail.azcloud.it
  • Porta: 995
  • Tipo di sicurezza: SSL/TLS
  • Metodo di autenticazione: Password normale

Posta in uscita con protocollo SMTPs

  • Nome server: smtp.azcloud.it
  • Porta: 465
  • Tipo di sicurezza: SSL/TLS
  • Metodo di autenticazione: Password normale

In particolare non è possibile utilizzare nomi di server personalizzati (ad es. mail.nomecliente.tld) per collegarsi in modalità protetta, pena una segnalazione di errore sul certificato da parte del browser. Ricordiamo, infine, che per autenticarsi sul server è necessario usare come nome utente l’intera casella email (ad es. utente@dominio.tld) e non solo il nome utente come spesso propongono i client di posta elettronica.

Le Query DNS Su Porta TCP

Fin dalla notte dei tempi abbiamo preso per assodato che le query rivolte verso un server DNS sono dirette sulla porta UDP 53. Poi, sappiamo che il trasferimento dei file di zona tra server DNS, invece, viaggiano sulla porta 53 TCP. In realtà manca qualcosa.

Il protocollo UDP porta un problema: visto che l’header non ha tutte le caratteristiche del TCP, sarebbe impossibile “unire” due o più pacchetti UDP, per cui è evidente che nasce un limite oggettivo sulla dimensione della risposta ad una query UDP che normalmente è settata a 512 Bytes.

Potrebbe accadere, però che una query debba avere un risultato più grande dei comuni 512 Bytes: ad esempio la crescente diffusione del protocollo DNSSEC oppure alcuni record TXT o SRV particolarmente grandi. Cosa fare?

L’rfc del DNS ci viene in soccorso con un escamotage semplice ed efficace: nel caso in cui il risultato di una query sia di dimensione maggiore dei canonici 512 Bytes, è possibile rispondere alla query con un record vuoto ma settando il bit TC dell’header a 1. Così facendo, si istruisce il client DNS a riproporre la query sulla porta 53 TCP in modo che sia possibile concatenare più pacchetti.

Questa modalità in un primo tempo è stata pesantemente criticata, tanto è vero che nell’rfc è ben specificato che un server DNS deve rispondere alle richieste UDP e può (facoltativo) rispondere alle richieste TCP. La critica nasce dal fatto che l’overhead del protocollo TCP rispetto all’UDP è maggiore e quindi tutto l’insieme server/rete viene stressato maggiormente.

Col passare del tempo, però, la potenza dei server è aumentata, così come la disponibilità di banda, per cui le iniziali critiche all’utilizzo del protocollo TCP al posto dell’UDP diventano poco influenti e si iniziano a valutare i benefici che questo cambiamento porterebbe. Il più evidente è che è più facile arginare un attacco di tipo DDOS su porta TCP e, visto il continuo aumento di questo tipo di attacco, la cosa è da tenere in considerazione.

Al momento, i più diffusi demoni DNS (Bind e PowerDNS) non consentono di “rigirare” tutte le query da UDP a TCP, è necessario creare un demone DNS ad hoc. Per la cronaca CloudFlare ha già provveduto a implementare questa funzionalità sui suoi server DNS e il servizio AlwaysResolve ha pianificato questa funzionalità nella prossima release.

Rails Model Non Persistente

Uno degli aspetti più apprezzati di buona parte dei framework moderni, è l’ActiveRecord: attraverso questo strumento è possibile gestire con grande facilità i dati attraverso moltissime funzioni quali la possibilità di gestire in maniera quasi automatizzata un database oppure effetturare controlli sintattici sui dati inseriti. In questi giorni, però, ho avuto la necessità di strutturare un model in Rails in cui tutti dati inseriti non devono essere persistenti e pertanto devono “morire” una volta utilizzati; per fare questo, sarebbe sufficiente creare una nuova classe che non eredita la classe ActiveRecord::Base, però, così facendo, si perdono le funzionalità di contollo automatico del form. Ho scartato anche l’idea di creare un model ActiveRecord senza campi e con solo attributi “attr_accessor”, perchè si crea comunque una tabella vuota nel DB e, per pulizia, è una cosa che non mi piace. Ecco come ho fatto io. Innanzi tutto ho creato un nuovo model chiamato “EphemeralModel” che eredita ActiveRecord::Base

EphemeralModelSource Article
1
2
3
4
5
6
class EphemeralModel < ActiveRecord::Base
    def self.columns() @columns ||= []; end
    def self.column(name, sql_type = nil, default = nil, null = true)
        columns << ActiveRecord::ConnectionAdapters::Column.new(name.to_s, default, sql_type.to_s, null)
    end
end

A questo punto possibile utilizzare la nuova classe come base per i nostri model non persistenti

NonPersistentEmail
1
2
3
4
class NonPersistentEmail < EphemeralModel
   column :email, :string
   validates_format_of :email, :with => /\A[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]+\z/
end

La classe NonPersistentEmail è una classe ActiveModel a tutti gli effetti, per cui possiamo utilizzala con la funzione “form_for”, oppure (come da esempio) aggiungere una validazione… solo che i dati inseriti nel form saranno utilizzabili solo per l’elaborazione e non saranno salvati nel database.

Il Nuovo Servizio AlwaysResolve

L’obiettivo è stato raggiunto: ci eravamo prefissi di far partire il servizio entro fine mese e ce l’abbiamo fatta. Pure con un giorno di anticipo, il che non guasta visto che si dice che, per scaramanzia, il venerdì non si deve iniziare nulla di nuovo. Bando alle ciancie, ecco qui AlwaysResolve: si tratta di un nuovo servizio che è basato su una infrastruttura di rete Anycast (cioè dove più server ospitati in diversi datacenter condividono il medesimo indirizzo IP attraverso multipli annunci BGP) la quale ospita i nostri server DNS. I nostri DNS hanno la caratteristica di essere “dinamici”, cioè avere tempi di aggiornamento bassissimi per cui ogni modifica ai record vieni immediatamente propagata senza che ci siano inutili tempi morti. Il servizio DDNS non è certo una novità, ci sono già molti altri fornitori sul mercato da parecchi anni: perchè crearne uno nuovo? Perchè i servizi di DNS Dinamico non fanno quello che vogliamo noi ma si limitano al solo servizio di DDNS. L’idea di AlwaysResolve è di utilizzare una tecnologia consolidata come quella del DNS Dinamico per gestire l’alta affidabilità multidatacenter di qualsiasi servizio web e, quindi, essere protetti sia da eventuali guasti di una intera infrastruttura, sia da attacchi di tipo DDOS. Questa funzionalità viene svolta da un sistema di check integrato che controlla costantemente il funzionamento del tuo server da più posizioni nel mondo e, in caso di guasto, modifica il record DNS di conseguenza. Completa il sistema, un servizio di cache hosting “ultima spiaggia” che scarica nottetempo una copia statica del sito e che entra in funzione nel caso in cui tutti i server siano irraggiungibili, in modo da non perdere alcun punteggio nell’indicizzazione sui motori di ricerca. Abbiamo deciso di creare tre diversi livelli di servizio:

  • Basic plan: consente di gestire due server in alta affidabilità ed, eventualmente, associare un servizio di cache “ultima spiaggia” in caso di guasto di entrambi i server.
  • Professional plan: consente di gestire più server in bilanciamento di carico escludendo automaticamente dal pool quelli irraggiungibili; anche in questo caso è possibile associare un servizio di cache “ultima spiaggia” in caso di guasto di tutti i server.
  • Enterprise plan: ancora in fase di ultimazione, permetterà di distribuire il carico sui server in base alla provenienza geografica del visitatore in modo da abbassare i tempi di latenza e offrire contenuti geolocalizzati in maniera automatica; anche in questo caso, ovviamente, sarà possibile associare un servizio di cache “ultima spiaggia” in caso di guasto di tutti i server.

Corredano i servizi a pagamento due servizi free:

  • Un servizio completamente gratuito di check speed url per verificare la velocità del tuo sito così come viene visto da tutto il mondo;
  • Un servizio DDNS classico con la funzionalità aggiuntiva di mostrare automaticamente una “pagina di cortesia” in caso di irraggiungibilità del server, offerto in modalità “pay with advertising” in cui il servizio durerà in base alla quantità di pubblicità che riuscirai a fare al nostro servizio.

AirTunes Con Linux

In un passato in cui utilizzavo un iMac come dispositivo desktop principale, acquistai una base Apple AirPort Express configurandola semplicemente come client della rete WiFi esistente in casa con un duplice scopo: collegare via Ethernet la mia nuova televisione in modo da sfruttare le caratteristiche “da mediacenter”, e collegarla tramite cavo audio all’Home Theatre per riprodurre in streaming le tracce audio di iTunes.

Francamente questa seconda funzionalità non l’ho mai sfruttata più di tanto, per cui quando ho deciso di abbandonare MacOS per avere Linux anche sul desktop, non ho mai approfondito come far funzionare lo streaming… ma recentemente mi sono preso la briga di trovare una soluzione.

Facendo qualche ricerca, ho scoperto che il sistema sonoro PulseAudio installato di default su Gnome, offre questa funzionalità integrata per cui sembrava cosa abbastanza semplice far funzionare tutto l’insieme: secondo teoria, andando in “Impostazioni audio” avrei dovuto vedere l’AirPort all’interno della scheda “Uscita” come dispositivo su cui riprodurre l’audio… ma ovviamente non era presente.

Il mio primo dubbio riguardava proprio PulseAudio: il protocollo di comunicazione che Apple chiama “AirTunes” in realtà si chiama “RAOP” e in alcune distribuzioni (ad es. Ubuntu) serve un plugin di PuseAudio per abilitarlo. Al contrario, su Arch Linux (la distro che uso sul desktop), il plugin RAOP è compilato all’interno di PulseAudio per cui non c’è nulla da installare.

La colpa è di qualcosa d’altro.

La colpa, infatti, era la mancanza di un altro componente: la compatibilità con il sistema Bonjour di Apple che consente “l’annuncio in rete” dei dispositivi. La compatibilità su Linux con il protocollo Bonjour è fornita dal demone Avahi, installato di default su buona parte delle distribuzioni. Una volta abilitato, il dispositivo AirPort è apparso magicamente nella lista dei dispositivi audio in uscita di PulseAudio.

Sembrava tutto fatto, però cercando di far emettere qualche suono al mio Home Theatre non si sentiva nulla… e il PulseAudio crashava inesorabilmente.

A questo punto ho riavviato PulseAudio in modalità debug per capire dove stesse il problema: dai messaggi ho visto che l’AirPort si annunciava con l’IP APIPA di classe 169.X.X.X al posto dell’IP della mia LAN casalinga (192.168.0.X per la cronaca) per cui il server PulseAudio non trovava il dispositivo e andava in crash. Francamente non capisco perchè l’AirPort si annuncia con quell’IP (o perchè il server PulseAudio vede solo quell’IP): nella mia rete c’è un server DHCP configurato per assegnare un IPv4 statico all’AirPort e, inoltre, gira un demone Radvd che assegna all’AirPort un indirizzo IPv6 statico.

Tra l’altro, in tutta sincerità, una volta abilitato il demone Avahi sul mio desktop, ho visto un aumento dei pacchetti di rete considerevole che, per come sono fatto, non mi è piaciuto.

Bene, visto che l’Avahi non mi soddisfa, che alternative abbiamo?

L’alternativa più semplice (e le cose semplici che funzionano a me piacciono particolarmente) è settare manualmente la periferica PulseAudio attraverso uno script da lanciare all’avvio della sessione Gnome:

1
2
#!/bin/bash
/usr/bin/pactl load-module module-raop-sink server=192.168.0.x

Grazie a questo semplice script, il sistema PulseAudio aggiungerà il device AirPort come “RAOP sink ‘192.168.0.x’”… e ora l’audio funziona.

Ho avuto un ultima difficoltà con il mio player preferito: Audacios.

Di default, Audacios usa come plugin di uscita Alsa e la qualità dell’audio in streaming sull’AirPort è a dir poco oscena! Basta settare come Plugin di uscita PulseAudio e come profondità di bit 32 per avere un audio di qualità anche sullo stereo.

La Mia Nuova Configurazione Cloud

Dall’inizio della mia esperienza con OpenNebula, ho provato parecchie soluzioni di storage, ma solo ora ho trovato una combinazione che soddisfa le mie esigenze di velocità, sicurezza e contenimento dei costi.

Innanzi tutto: non esiste mai la soluzione perfetta, ma esistono soluzioni diverse ciascuna delle quali si adatta meglio a risolvere un determinato problema. Nel mio caso, trattandosi di un cloud privato, l’esigenza principale è quella di avere una soluzione sufficientemente performate ma contnedo i costi.

Nel mio cloud privato, ho 5 server KVM che ospitano un totale di 20-30 VM: alcune sono stressanti solo per la CPU (mail scanner, DNS, ecc.), altre purtroppo generano molto traffico I/O (MySQL server per LAMP, Syslog server, ecc.): le seconde sono il problema, perche le soluzioni precedentemente adottate non hanno soddisfatto adeguatamente richieste di I/O.

La mia prima soluzione è stata quella di creare uno storage server che esportasse una partizione (c)LVM via AoE (che ha un overhead inferiore rispetto ad iSCSI): il carico di lavoro sul server era davvero elevato e la velocità di I/O non troppo veloce. Ok, ho imparato la lezione: se devi avere uno storage condiviso, non usare un server economico, ma usane uno ottimizzato per lo storage con dischi ad alta velocità, controller potenti con una buona dose di cache, LAN a 10GB… or semplicemente, compra una SAN FC ;-)

Il mio secondo test è stato con uno storage basato su MooseFS: qui ho ottenuto risultati contrastanti. Ho un cliente che è davvero soddisfatto delle prestaizione e ha all’attivo un cloud con 10 storage server e 10 Hypervisor XEN; nel mio private cloud, con solo 3 storage server (un master e 2 chunk) l’I/O è lento come nella prima soluzione: nessun beneficio dall’uso di due server in bilanciamentoe 2 porte LAN ad 1 Gb in bonding è un altro collo di bottiglia. La lezione che ho imparato qui: per avere uno storage cluster dalle prestazioni soddisfacenti è necessario usare parecchi server.

Il mio terzo ed ultimo setup che vi racconto ora è… non usare un solo storage condiviso, ma distribuirlo sui server HyperVisor.

Partiamo da una considerazione: i miei “vecchi” HyperVisor sono dei Dell R410 dotati di 2 CPU quad-core e 32 GB Ram; se riuscissi a far stare in un cabinet Rack da 1U, 2 Motherboard Mini-ITX con una CPU Core i7 (non esattamente come la CPU Xeon dell’R410 ma non troppo distante) e 16 GB Ram… avrei la stessa potenza di calcolo, nello stesso spazio divisa su due server. E se riuscissi a farci stare anche 2 dischi SATA ad alta velocità come i WD Velociraptor per le VM e due dischi SSD per il SO, potrei usare DRBD in modalità Attivo/Attivo con cLVM o GFS2 per avere uno storage in HA dalle prestazioni accettabili per le VMs instanziate in questo “double-server”.

Ora ho 4 mini-itx double server ciascuno con questa configurazione; in OpenNebula, ogni double-server viene visto come un “cluster” separato e il disco DRBD è il datastore associato al cluster.

Ovviamente non posso migrare una VM tra due cluster diversi, ma al momento questa soluzione risponde bene alle mie esigenze di velocità, il costo di ogni “double-server” è inferiore rispetto ad un vero server ad 1U e il consumo di energia elettrica nel datacenter è diminuito.

Sostituzione Storage Server

Come accenntato in questo articolo, stiamo per iniziare la progressiva sostituzione dei server più obsoleti (e quindi più esosi in termini di consumo elettrico) con apparecchi di nuova concezione basati su architettura Mini-ITX/Sandy Bridge più performanti e a basso consumo.

Lo scopo di questa iniziativa è di rendere il datacenter più ecosostenibile diminuendo drasticamente il consumo di elettricità sia per i server, sia per gli impianti di smaltimento del calore prodotto.

Nella settimana dal 4 al 10 marzo, saranno sostituiti i primi due apparecchi per cui potrebbero verificarsi brevi interruzioni di servizio durante lo spostamento delle VM interessate sui nuovi server.

Ci scusiamo anticipatamente per gli eventuali piccoli disservizi.

Alla Fine Non Ho Resistito

Come al solito dimostro di cedere alla voglia di cambiamento: cambio distribuzioni sul mio PC e motori del mio sito web, con la stessa frequenza con cu mi cambio i maglioni!
Ebbene, alla fine non ho resistito al richiamo della moda del momento: ecco spostato il mio blog sulla piattaforma Octopress.

Purtroppo (anzi per fortuna) i crescenti impegni non mi consentono di mantenere con la dovuta attenzione la piattaforma di blog realizzata a fine 2012 in Rails: le funzionalità aggiuntive quali l’integrazione con il CRM latitano per mancanza di tempo, l’importazione dei contenuti dal vecchio blog ancora di più…
A questo punto era necessaria una scelta razionale e non di cuore: abbandonare una piattaforma autocostruita per una di pubblico dominio che mantenesse le prerogative di leggerezza e funzionalità che non ho più trovato in Wordpress. In questo modo spero di avere più tempo per curare di più i contenuti piuttosto della forma.

Ammetto di non aver lavorato molto sulla grafica in quanto ho deciso di utilizzare il tema di default di Octopress che mi è sempre piaciuto molto sia per leggibiltà che per leggerezza; spero che questa nuova versione del sito piaccia anche a tutti voi!

Ma cos’è Octopress?
Octopress è un vecchio modo di fare siti, che però si addice bene alle necessità di velocità e semplicità dell’Internet moderno: a differenza dei CMS tradizionali che elaborano la singola pagina ad ogni richiesta, con Octopress si elabora tutto il contenuto del sito in locale una sola volta e si carica sul server il codice html già pronto. Si spostano quindi i tempi necessari per l’elaborazione delle pagine sul computer dell’autore del blog, sollevando i server da questo compito… a tutto beneficio della velocità del sito.
In pratica con Octopress si hanno a disposizione dei comandi scritti in Ruby che servono per “compilare” il blog. Difatti, sostanzialmente, si realizzano i contenuti del blog in locale con il linguaggio markdown e poi si lanciano i comandi di Octopress per trasformare i file markdown in file html statici. Ovviamente si hanno a disposizione temi, che non sono altro che dei semplici fogli di stile .css collegati alle pagine html: è attraverso questi css che il sito risuta gradevole esteticamente ed è “responsive”, quindi visualizzabile correttamente anche su dispositivi mobili con schermo ridotto.