Eccomi qui a distanza di un anno esatto ad affrontare l’ennesima migrazione del blog (che ormai somiglia sempre più a un ambiente di test per provider).

Dopo aver aver provato l’ottimo servizio di hosting di Siteground ho mio malgrado deciso di cambiare aria, non certo per la qualità del servizio (sempre ottima), ma per una pura questione di costi; al termine dell’anno promozionale l’hosting condiviso base di Siteground lievita a quasi 100 $ l’anno, decisamente troppo per il mio target.

A questo punto il dubbio amletico: hosting o vps?
OVH ha deciso di togliermi ogni dubbio in merito con una offerta che francamente ha del miracoloso, ovvero VPS Classic:

• 1 CPU Opteron 4284 3GHz
• 1 GB di ram
• 10 GB di storage
• banda e traffico a carrettate

…il tutto alla modica cifra di 2,43 € al mese iva inclusa.

Il servizio di primo acchito sembra essere ottimo, ordine e pagamenti semplici e immediati, tempo 5 minuti dal pagamento e sarete già connessi in ssh al vps.

L’interfaccia di amministrazione è pulita e molto funzionale, la schermata principale mostra le risorse della macchina, gli ip, lo stato dei servizi in ascolto (http, https, ssh, dns, smtp e raggiungibilità via ping) e poco altro.
Accedendo ai menù avanzati è possibile verificare l’andamento delle principali risorse in modo più dettagliato, riavviare, modificare la password di root (il che causa un riavvio del vps), modificare il contratto o rinnovarlo, e reinstallare il vps scegliendo tra diverse distribuzioni (Debian 6 e 7, CentOS 6, Ubuntu 13.10 e 14.04) o setup che comprendono alcuni dei cms più diffusi o pannelli di amministrazione.

Ovviamente non manca un comodo KVM che permette di accedere alla console del vps, giusto nel caso abbiate pasticciato un po’ con la rete e iptables.

Le performance sono… eh no, queste le vedremo prossimamente, diciamo che per ora sono più che soddisfatto :D

L’inventore di Cygwin meriterebbe una statua in ogni piazza, non è la prima volta che lo affermo ma non sarà di certo l’ultima.

Una delle innumerevoli features utilissime di questo fantastico software è il server X, indispensabile se lavorate su server GNU/Linux o Unix per poter utilizzare applicazioni che hanno una interfaccia grafica o richiedono un server grafico.
Qualcuno pensa che “il sistemista che non deve chiedere mai” può vivere di sola command line, in realtà però molti software enterprise ormai possono essere installati solo tramite installer grafici, pertanto un server X è ormai parte del corredo di sopravvivenza di qualsiasi sistemista.

L’installazione è estremamente semplice, scaricare dal sito https://www.cygwin.com/ l’ultima versione del setup di cygwin per l’architettura che preferite (x86 o x64), piazzatelo in una directory (es c:\cygwin\setup) e  lanciatelo.

1) Proseguite nei primi passi dove selezionare l’origine dei pacchetti (suggerisco “Install from Internet” se avete la possibilità di connettervi a web mediante protocollo http o ftp)
2) Selezionate la root di cygwin (es c:\cygwin)
3) Confermare la directory che conterrà i package scaricati (es c:\cygwin\setup)
4) Infine inserite l’eventuale proxy necessario per raggiungere il repository dei pacchetti di installazione e selezionate un mirror a piacimento.

Dopo avere scaricato l’elenco aggiornato dei package vi verrà mostrata la schermata riassuntiva dei pacchetti da installare, nell’angolo superiore sinistro troverete un’area di testo dove potete ricercare specifici pacchetti, quelli che dovrete installare per avere un server X funzionante sono:

• xorg-server
• xinit
• xorg-docs

Cercate ciascuno di questi e selezionateli per l’installazione cliccando sulla label “Skip”

Cliccate su Avanti per proseguire nel wizard, la schemata successiva mostrerà i pacchetti che saranno installati come dipendenze dei tra selezionati.

Installazione terminata

A questo punto tra i programmi installati dovrebbero essere comparsi il gruppo Cygwin-X contenente il collegamento per lanciare il server X (XWin Server), se provate a lanciarlo comparirà nel systray l’icona del server X avviato in background e si aprirà un terminale grafico (xterm).
Personalmente trovo questa cosa piuttosto noiosa, per eliminare l’apertura di xterm all’avvio del server X basta creare nella home del proprio utente il file nascosto .startxwinrc, per farlo aprite un terminale di cygwin e digitate “touch .startxwinrc”.

Un’altra cosa imho molto comoda è avviare il server X immediatamente al boot (o al login di del proprio utente), per farlo basta creare un collegamento nella folder Esecuzione automatica (per chi utilizza Windows 8 si trova sotto %AppData%\Microsoft\Windows\Start Menu\Programs\Startup) che lanci questo comando:

<ROOT DI CYGWIN>\bin\run.exe -p /usr/X11R6/bin XWin -multiwindow -clipboard -silent-dup-error

Prima di testare il nostro fiammante server X occorre un ultimo semplice passaggio, dobbiamo esportare la variabile DISPLAY, per farlo possiamo lanciare il comando “export DISPLAY=:0.0″ oppure modificare il file .bash_profile presente nella home del nostro utente (per fare in modo che la variabile venga esportata automaticamente all’apertura del terminale, ricordatevi di chiudere e riaprire il terminale stesso) inserendo in coda DISPLAY=:0.0

Finalmente ci siamo, provate a connettervi mediante ssh ad un server avendo l’accortezza di aggiungere l’opzione -X (oppure -Y se volete abilitare il forward trustato) e lanciate una qualsiasi applicazione grafica (es xeyes)

Bingo!

Lavorando su macchine GNU/Linux 9 volte su 10 ci si trova ad avere a che fare con la bash, e in molti casi diventa essenzialmente scavare nella history per recuperare comandi già lanciati o dimenticati risparmiando così parecchio tempo.

La history è conservata nella home di ciascun utente nel file nascosto .bash_history e per visualizzarne il contenuti è sufficiente lanciare il comando history, eventualmente greppando qualsiasi cosa possa servire:

In realtà questo modo di interrogare la history è spesso molto macchinoso e lento, può essere utile per documentare o per farsi un’idea su una serie di comandi lanciati in serie, ma per un uso “on the fly” della history è poco utile.

Esiste un altro modo molto più veloce e immediato che ho notato pochi conoscono (almeno all’interno della mia cerchia di colleghi, clienti e collaboratori), ovvero lo shortcut CTRL+R.

Usando questa veloce scorciatoia si abilita una ricerca inversa nella history, digitando il comando lanciato la bash precompila il resto utilizzando il record più recente della history che comincia con quanto è stato digitato, se occorre recuperare un comando più vecchio che inizia nello stesso modo basta premere di nuovo CTRL+R per passare ai precedenti.

Se invece preferite eliminare i record presenti nella history (perchè ad esempio contengono password o informazioni critiche che non dovrebbero essere visibili da altri utenti) potete cancellare il file ~/.bash_history oppure più elegantemente lanciare il comando “history -c”

May the bash be with you!

E’ da settimane ormai che vivo in crunch-mode, vorrei documentare tante cose che sto facendo (spesso 2, 3, 4, 19 contemporaneamente…) ma purtroppo qualcuno ha deciso che le giornate sono solo di 24h, per cui tra cibo+sonno e blog, scusate tanto, ma scelgo i primi.

Nel frattempo ne approfitto per far ingolosire qualche amico che so che segue queste sciagurate pagine :D

Una delle cose che spesso vengono sottovalutate nella configurazione dello storage in RAID con parità (tipicamente RAID5) è l’importanza della batteria tampone e conseguentemente la configurazione della cache write-back anzichè write-through.

Molti pensano che la batteria tampone sia una sorta di gadget, bello e soprattutto costoso, perchè diciamocela tutta, queste miserabili e banalissime batterie al litio sono care come il fuoco, e se esistesse una divinità della giustizia vedremmo fulmini cadere h24 sulle sedi di Adaptec, LSI, IBM, Dell, HP e tutte le altre società coinvolte in questo sanguionosissimo mercato…
Purtroppo l’utente medio (almeno questa è la mia esperienza frequentando varie realtà aziendali) è portato a pensare “Massì, è già tanto se abbiamo un controller raid hardware, noi non siamo così enterprise da aver persino bisogno della batteria…”. oppure “Ok, cosa cambiera mai con la batteria o senza… i dati sono comunque al sicuro”.

Tralasciamo i commenti su questa sensazione di finta sicurezza (“shit happens”, e non è questione di se, ma di quando…), il fatto è che le batterie tampone servono, e non solo per permettere la corretta esecuzioni delle transazioni di I/O, ma anche per una pura e semplice questione legata alle performance degli array con parità, più nello specifico le politiche di utilizzo della cache nell’esecuzioni delle attività di scrittura.
Non smetterò mai di lottare contro gli array RAID5 e RAID6, uno dei motivi per i quali osteggio questo genere di configurazione è la cosidetta write penalty, ovvero il sovraccarico di IOPS dovuto calcolo e salvataggio della parità durante ciascuna attività di scrittura; per tamponare questo handicap i controller dotati di batteria tampone utilizzano la cache del controller in modalità write-back (ovvero asincrona), in caso contrario utilizzano la più sicura modalità write-through (sincrona), per una spiegazione più esaustiva rimando a questa pagina di Wikipedia.

Se pensate che questa differenza possa essere marginale date un’occhiata al grafico che segue, queste sono le prestazioni di una lun su san IBM DS4300 con array raid5 composto da tre dischi SCSI Ultra320 da 10.000 rpm durante una banale import di uno schema Oracle 9 su GNU/Linux iniziata alle ore 01:00AM (non le 13:00).
San preistorica, server ancora più antiquato, storage malridotto, sistema operativo antidiluviano (RedHat Enterprise 3), tutte ottime ragioni per giustificare delle performance così basse, guardate però la differenza tra le prestazioni antecedenti alle ore 13:00 (batteria nuova in carica e cache write-through attiva) e dopo le ore 13:00 (batteria online e cache write-back)… non ho altro da aggiungere.