Dalle analisi degli accessi noto con grande piacere che c’è sempre grande interesse riguardo ai server domestici, se preferite “muletti”.

Di recente il mio storico Epia 5000A ha subito un brutto colpo, una serie di guasti allo storage l’hanno costretto ad un down forzato, vista poi la difficoltà a reperire hard disk PATA sono stato costretto ad acquistare un adattatore IDE-SATA il quale a sua volta mi ha costretto a ritrasferire l’Epia nel primo storico case a causa di problemi di spazio (fisico stavolta).

Naturalmente nessun dato è stato perso grazie ai rigorosi piani di backup che ho implementato nel tempo, questa pausa però mi ha spinto a riflettere un po’ sul futuro del mio server domestico.
In tal senso l’esperienza con Raspberry PI è stata illuminante, le possibilità software sono pressochè le stesse del mio Epia x86, l’assorbimento è di gran lunga inferiore (meno di 1/5 in idle, addirittura circa 1/9 a pieno carico), la temperatura da dissipare pressochè trascurabile, gli ingombri ridottissimi, le performance simili.
L’unico aspetto limitante di Raspberry PI è lo storage, dover ricorrere ad un disco usb alimentato mediante un hub usb rappresenta un vero scoglio, o per lo meno trasformerebbe quello che oggi è un bel case ordinato e compatto in una foresta di mangrovie di cavi.

Una soluzione ci sarebbe, si tratta del progetto Fairywren, una mainboard mini-itx a cui connettere Raspberry PI con tutto l’occorrente per storage, rete, alimentazione, hub usb interno, un piccolo gioiellino che sta nascendo su Kickstarter e che rappresenterebbe una vera manna per chi come me vorrebbe usare Raspberry come server domestico.

Frequentando vari forum però mi è stato giustamente fatto notare che al di la dell’hype generato dal progetto Raspberry PI è basato su un SoC relativamente antiquato e piuttosto limitato in termini di risorse, idem per quanto riguarda progetti simili tipo BeagleBone.
Così sono venuto a conoscenza di altri progetti molto più interessante, magari meno rivolti alla ricerca o alla sperimentazione ma dotati di più risorse, insomma il perfetto punto di contatto tra le esigenze server e i vantaggi delle architetture ARM.

Due hanno attirato la mia attenzione, entrambi dotato di SoC Cortex A20 dual core, entrambi dotati di 1GB di ram DDR3 e un canale SATA, si tratta di:

Cubieboard 2

Olimex A20-OLinuXino-MICRO

Entrambi ottimi progetti, simili dal punto di vista hardware ma differenti come approccio e filosofia di base.
Cubieboard 2 ha al suo attivo una comunità abbastanza diffusa, un forum piuttosto popolato e un layout piuttosto compatto, OLinuXino A20 è meno diffuso, un layout più “affollato”, una comunità meno popolosa ma è dotato di un gran numero di interfacce GPIO (quindi molto più indicato per la ricerca e applicazioni pratiche, un approccio simile a Raspberry PI per intenderci), entrambi sono progetti open hardware.

Di per se sarei fortemente attratto da entrambi questi progetti, l’unico aspetto che mi lascia dubbioso è il layout di questi sistemi, bellissimo e compatto ma difficilmente integrabile con un case ordinato e altrettanto compatto, insomma se dovessi utilizzarli mi ritroverei con una foresta di mangrovie di cavi come con Raspberry PI

Quasi in risposta alle mia suppliche il team di Cubieboard ha annunciato un nuovo progetto open hardware chiamato Cubietruck che prevede:

• SoC A20 Cortex-A7 Dual Core
• 1 o 2 GB di ram
• canale SATA
• interfaccia di rete Gbps

ma soprattutto grande attenzione al layout, tanto da essere sovrapposto a quello di un hard disk da 2.5″, e addirittura pubblicando un prototipo di case veramente fantastico.

Mio al DAY1!!!

[EDIT]

Good news! Sembra che la produzione di Cubietruck stia per iniziare! Yuppi!!!! :)

Uno degli aspetti che più mi solletica dei server Dell è il loro eccellente parco software, sia per quanto riguarda gli aggiornamenti ma soprattutto riguardo ai sistemi di monitoring.

La punta di diamante del monitoraggio Dell è rappresentata dall’ottimo OMSA (OpenManage Server Administrator), disponibile per quasi tutti i sistemi operativi più diffusi, stabile e relativamente leggero (per lo meno per la disponibilità di risorse attuali).

Uno degli aspetti di OMSA che ho notato mette in difficoltà clienti e amministratori è la notifica di alert via email; l’approccio di Dell a tal proposito è votato alla più totale flessibilità, anzichè dedicare qualche stringata opzione per la definizione di SMTP, sender e destinatari OMSA permette di definire per ciascuna risorsa uno script che viene lanciato ogni volta che si verifica un alert relativo alla risorsa stessa.

Di default le risorse da monitorare non prevedono alcun alert (es Watchdog ASR).

Come vedete nel dettaglio ciascuna risorse prevede la possibilità di lanciare uno script locale.

Se vogliamo inviare una mail lo script è presto fatto.
Nel caso vi troviate a che fare con un server Windows basta utilizzare l’ottimo blat, potete prendere ad esempio lo script che ho utilizzato per la schedulazione di clamwin.
Per server con distribuzione GNU/Linux la soluzione è ancora più semplice, basta un banale script bash per inviare mail tramite il comando mail (es /etc/Dell/mail.sh).

#!/bin/sh
TESTO="Verificare lo stato del server"
echo $TESTO | mail -s "[OMSA] PROBLEMA SERVER" [email protected],[email protected]

Una volta creato lo script ricordate di dargli diritti di esecuzione (chmod +x /etc/Dell/mail.sh), nel caso dobbiate utilizzare un altro server per il relay SMTP fate riferimento alla documentazione dell’MTA utilizzato (es sendmail piuttosto che postfix).

Ora viene la parte pallosa, Dell OMSA prevede una serie di servizi per cui attivare le notifiche (giusto come esempio 34 su PowerEdge 2950, 38 su un R710), definirli uno a uno è un lavoro palloso, che diventa impossibile nel caso di troviate a che fare con decine di server.
Per fortuna ci viene in aiuto il set di utility command line di OMSA, con il comando “omreport system alertaction” potete verificare lo stato dei servizi.
Con il comando omconfig potete configurare tutti gli alert con un singolo comando sfruttando le poderose features della bash:

for device in $(omconfig system alertaction -? | grep "event=" | \ 
cut -d'=' -f 2 | awk '{print $1}') ; \
do omconfig system alertaction event=$device \ 
execappath=/etc/Dell/mail.sh ; \
done

Ecco fatto, gli alert per tutti i servizi sono configurati, non vi resta che tenere d’occhio la vostra email nella malaugurata ipotesi si rompa qualcosa.

E non lesinate sui contratti di supporto!!! :O

Giusto per ricordare cos’è lo storage serio a chi considera Qnap e Synology dispositivi professionali e performanti…

Finalmente sono riuscito a liberarmi dell’ultimo pezzo di hardware Razer, qualche giorno fa sono andato a ritirare dal fido Drako il mio nuovo mousepad Steelseries QCK.

A differenza del predecessore Razer Destructor questo QCK è un mousepad in tessuto, e come i più esperti sanno è un tipo di mousepad più adatto ai cosidetti high-senser.
Pippe mentali a parte si sta comportando davvero bene, il feedback iniziale è senz’altro positivo, sebbene l’attrito sia maggiore rispetto ai mousepad rigidi (come il Destructor), il QCK sembra avere un comportamento più omogeneo e costante, specialmente durante le lunghe sessioni dove l’accumularsi dello sporco tende a inficiare notevolmente le performance dei mousepad rigidi.

Tanto per fare un esempio, col Destructor ero costretto a pulire la superficie del mousepad almeno una volta la settimana, e già dopo qualche giorno potevo percepire gli iniziali effetti dello sporco, specialmente durante la stagione calda.
Questo QCK invece sembra “autopulente”, lo sporco si accumula (e avendo un colore scuro più uniforme tende a vedersi più facilmente) ma con una semplice “spazzolata” con la mano il mousepad torna lindo e come nuovo.

La superficie a contatto con il piano di appoggio è rivestita con un materiale gommoso antiscivolo, in rete ho visto che qualcuno ha aumentato l’attrito usando delle apposite fascette adesive in gomma antiscivolo, vista la stabilità generale credo che non sarà necessario dato che il mousepad è praticamente incollato alla scrivania.

Unico neo di questo prodotto è il packaging, essendo conservato arrotolato il mousepad tende a mantenere una forma ondulata, il mio esemplare per giunta è risultato spiegazzato lungo il profilo dove è stampato il logo Steelseries.
Niente che non si possa sistemare con un buon dizionario (consiglio il leggendario IL Castiglioni-Mariotti), da un prodotto che però si fregia della digitura “pro-gaming” mi sarei aspettato una cura maggiore su questo aspetto.

Considerando il prezzo (9.90 euro) mi sento di consigliarlo, vediamo come si comporterà nei mesi a venire.

Ho provato a misurare l’assorbimento elettrico di Raspberry PI.

Con il primo test ho cercato di misurare l’assorbimento elettrico in idle partendo da Raspberry spento ma alimentato, procedendo poi ad un avvio dello stesso fino al termine del boot di raspbian.

Con il secondo test ho cercato di misurare l’assorbimento sotto stress computazionale compilando i sorgenti di Quake 3.

Prossimamente cercherò di effettuare un ulteriore stress test includendo anche la componente GPU, stavo pensando ad una timedemo di Quake 3 (per il rendering 3D) e la decodifica mpeg con qualche filmato.