Dalla mia esperienza professionale ho notato che nella valutazione delle risorse per un server l’aspetto in assoluto più sottovalutato è lo storage.
Molte persone tendono a valutare il carico applicativo solo in termini computazionali e di occupazione ram, lo storage è sempre e solo considerato in termini quantitativi, al massimo vengono valutate misure per garantire continuità di servizio in caso di guasti (es array raid).

Eppure l’esperienza insegna che generalmente le cpu sono sovradimensionate (sono relativamente pochi gli ambiti in cui vengono spremute a dovere), idem per la ram (con la scusa che “costa poco” si tende sempre ad esagerare con questa risorsa), l’unica risorsa che ha mantenuto dei costi piuttosto elevati è lo storage, e guardacaso è proprio la risorsa su cui si tende a risparmiare.

C’è da dire che alla base di questa tendenza c’è anche una buona dose di ignoranza da parte di molti (presunti) specialisti che non sanno rilevare carico di I/O nemmeno quando ce l’hanno davanti al naso, anzi magari lo confondono con carico computazionale consigliando migrazioni a cpu ancora più potenti e quindi “più inutili”.

Rilevare carico di tipo IOWait non è difficile (quantomeno su sistemi operativi unix like), basta il semplice comando “top”…

…oppure i fantastici tool del package sysstat

…oppure software un po’ più complessi come Collectd (insieme al fantastico collectd graph panel).

Quello che risulta un po’ più ostico è risalire ai processi responsabili di questo carico, specialmente su macchine un po’ datate.

Sui server con sistemi operativi recenti (ad esempio da Rhel/CentOS 5.x in poi) questo compito è spaventosamente semplificato da uno dei tool che non deve mancare su nessun server, IOtop.

Su macchine più datate purtroppo non sempre è possibile utilizzare questi comodi strumenti, oppure a causa di policy di gestione particolarmente rigide non è proprio possibile installare altro software.
In questi casi occorre sfruttare quello che fornisce il buon vecchio kernel, anzitutto abilitando le funzioni di debugging di scrittura blocchi sui dispositivi di IO portando a 1 il parametro block_dump:

echo 1 > /proc/sys/vm/block_dump

Una volta effettuata questa operazione basta interrogare il kernel ed estrarre i dati utili al nostro scopo:

dmesg | egrep "READ|WRITE|dirtied" |  awk '{print $1}'|  sort | uniq -c | sort -rn | head -n 20

Il risultato è piuttosto chiaro e riporta i 20 processi (con tanto di pid tra parentesi) che generano il maggior carico di IO sul sistema da quando è stato attivato il debugging del kernel.

Al termine ricordatevi di riportare a zero il valore del parametro modificato precedentemente:

echo 0 > /proc/sys/vm/block_dump

A questo punto è possibile proseguire con l’indagine per scoprire per quale motivo il processo in questione sta impattando sul sottosistema di storage. Magari come me scoprirete qualche furbastro che alle 17:00 di venerdì ha pensato bene di lanciare un job particolarmente gravoso senza avvisare, e pensando che nessuno se ne accorgesse.

Ora vi lascio, devo preparare gli strumenti di tortura per l’interrogator… ehhhmm la verifica con l’utente lunedì prossimo ;)

Della serie “tips & tricks per tutti” parliamo di un’altro semplice trucchetto a costo zero utilissimo per evitare di fare tutte quelle cose che in gergo tecnico e strettamente sistemistico si definiscono MINCHIATE.

Lavorando prevalentemente su console testuali (es terminali virtuali di server GNU/Linux, magari via ssh) capita di aver aperto contemporaneamente parecchi terminali verso diverse macchine.
Lavorare in questo modo presenta innumerevoli vantaggi, è un modo veloce, snello e immediato per poter fare qualsiasi cosa in brevissimo tempo.
Ad un utente comune potrà sembrare arcaico ma vi assicuro che se dovessi riconvertirmi a sistemista Windows impazzirei, o quantomeno sarei molto meno produttivo dovendo tornare ad una interfaccia prevalentemente grafica, non a caso la prima cosa che faccio quando prendo in mano una macchina Windows è installare cygwin e OpenSSH.

A questo dettaglio tecnico aggiungete la classica disorganizzazione e arroganza del cliente tipico italiano (già, proprio quello che pretende le cose fatte “per ieri”), le offerte folli dei commerciali (avete presente l’espressione “vendere la pelle dell’orso prima di averlo ucciso”?), il caos imperante in qualsiasi CED, shakerate bene e otterrete un mix letale di pessime condizioni operative, in questa situazione capite bene che è molto facile confondere un terminale per un altro :(
Provate a immaginare il brivido che vi corre lungo la schiena appena vi siete accordi di aver droppato un database su un server di produzione anzichè quello di test…

Per evitare tutto questo, o per lo meno per renderlo meno probabile basta un semplicissimo accorgimento, personalizzare il prompt del terminale.
E’ sufficiente ad esempio aggiungere una label prima del prompt, magari di un colore differente a seconda della criticità del sistema come in questo esempio

Per fare questo è sufficiente modificare gli script di inizializzazione della bash per il proprio utente oppure per tutto il sistema, esportando opportunamente la variabile PS1 (Default interaction prompt).

Ad esempio per ottenere il prompt visibile nello screenshot su RedHat Enterprise o CentOS è sufficiente esportare la variabile con questo comando:

export PS1='\[\e[1;31m\][!!! PRODUZIONE !!!]\[\e[m\] [\u@\h \W]\$'

Per rendere la modifica attiva ad ogni login è sufficiente modificare gli script di init della bash (es .bashrc o .bash_profile nella propria home directory, oppure /etc/profile o /etc/bashrc, oppure aggiungere uno script in /etc/profile.d/) in modo che la variabile venga esportata come meglio preferite ad ogni login.

Mi capita sempre più spesso di incappare in utenti (sia colleghi che clienti) che si lamentano per una feature di IBM Lotus Notes che in linea teorica è gran comoda ma che in pochi utilizzano, ovvero la sincronizzazione della password dell’id Notes con la password del proprio utente Windows.

Quasi a nessuno passa per l’anticamera del cervello di cercare nell’help in linea come disabilitare questa feature, quei pochi che lo fanno si scontrano contro un banalissimo problema, ovvero l’opzione per disabilitare la feature in questione non risulta selezionabile.

Banalmente: File –> Security –> User Security…

A questo punto come vedete l’opzione “Log in to Notes using your operating system login” risulta non selezionabile

Per rendere l’opzione editabile è sufficiente (rullo di tamburi….) lanciare Notes con privilegi di amministrazione…
Chiudete quindi Notes, fate un banale click dx sull’icona di Notes e selezionare “esegui come amministratore”

Magicamente ora l’opzione incriminata risulta beatamente editabile…

Come disse qualcuno più famoso e saggio di me: RTFM!

Cygwin? Lo adoro, lo venero, costruirei una statua in ogni piazza a chi l’ha inventato!
Ops scusate, cominciamo dall’inizio, cos’è Cygwin lo trovate qui; cosa Cygwin fa è presto detto: rende più semplice la vita di ogni sistemista offrendo un livello di integrazione unico e praticamente totale tra sistemi Windows e Unix like.

In parole povere Cygwin permette di utilizzare su Windows tutto quel popò di software (molti dei quali ricadono nel calderone delle GNU Utils) che rendono i sistemi Unix like (quindi anche GNU/Linux) lo standard di fatto in ambito server.
Ad esempio il terminale Cygwin risulta infinitamente più integrato con Windows rispetto al semplice (e ottimo) Putty, grazie a Cygwin è possibile installare su Windows un’infinità di software e servizi (un esempio su tutti OpenSSH, ma potremmo parlare di Squid, X Window System e tanti altri) che sono standard di fatto e che su Windows non si trovano, oppure sono disponibili in modalità differenti e con differenti contratti di licenza.

Uno dei tanti vantaggi, anzi imho forse il principale vantaggio che offre Cygwin è quello di utilizzare le shell di Unix su Windows, ad esempio la celebre e mai abbastanza osannata bash shell.
Già sento l’eco dei lamenti dei fan Microsoft protagonisti di infiniti flame su “bash vs powershell”, non è questa la sede e non è questo l’argomento, è comunque un dato di fatto che la bash sia una shell semplice da usare, potente, estremamente versatile e soprattutto disponibile sia in ambito Unix che Windows, e questo grazie a Cygwin.
Quindi perchè complicarsi la vita utilizzando diverse sintassi quando usando la bash possiamo tranquillamente riciclare script tra sistemi operativi Unix like e Windows?

Una volta creato un bello script occorre anche farlo girare, ecco che quindi entra in gioco l’integrazione tra Cygwin e Windows, in particolare lo scheduler del sistema operativo Microsoft.
Il tutto è molto semplice, basta lanciare la bash passando uno script bash (oppure un semplice comando) e come argomento della stessa utilizzando l’opzione -c.

Ad esempio il seguente comando permette di comprimere con bzip2 i file presenti in C:\Apache\logs e che hanno nome che comincia per “access_log.” e “error_log.”, escludendo però i file che contengono nel nome la stringa “bz2” (quindi i file già compressi precedentemente); l’output della compressione è di tipo verboso e verrà salvato nella stessa directory in un log diverso per ogni giorno e avente nome compress.AAAMMGG.

c:\cygwin\bin\bash.exe -l -c "find /cygdrive/c/Apache/logs/ -type f -name "access_log.*" -o -name "error_log.*" | grep -v bz2 | xargs bzip2 -v >> /cygdrive/c/Apache/logs/compress.$(date +\%Y\%m\%d).log 2>&1"

Per schedulare il seguente comando con frequenza giornaliera basta creare un nuovo scheduled job

Specificare la frequenza con cui questo job dovrà girare

Infine specificare il comando desiderato come “Programma o script”

In questo modo il comando verrà eseguito ogni giorno alle ore 02:00, ovviamente si tratta di un esempio banale lungi dall’essere uno script completo e ben fatto per l’archiviazione di logs, è solo un esempio su come sia facile riciclare e schedulare script bash anche su Windows, ragione più che sufficiente per installare Cygwin su qualsiasi macchina su cui gira questo sistema operativo.

Oggi si sente un gran parlare di servizi di streaming audio per portarsi appresso tutta la propria musica ovunque ci si trovi, servizi tipo Spotify o altre vaccate simili promettono mari e monti, salvo poi ritrovarsi inondati da una tale quantità di brani da non saper più quale scegliere…

Se anzichè dipendere da questi servizi preferite “degooglelizzarvi” e portarvi davvero ovunque la VOSTRA musica, sul VOSTRO hardware, con i VOSTRI servizi, allora vi consiglio di dare un’occhiata a questo fantastico servizio che risponde al nome di Subsonic.

Subsonic è ufficialmente un server di streaming audio completamente free che vi permette di ascoltare i vostri mp3 usando una comoda interfaccia web oppure delle applicazioni dedicate (anche per dispositivi mobile).
Tecnicamente parlando si tratta di una applicazione java disponibile sia come comodo package .war da deployare su un servlet container a piacimento (es Apache Tomcat), oppure come setup omnicomprensivo (applicazione + jetty) per Windows, GNU/Linux RedHat (rpm), Debian/Ubuntu (deb) oppure MacOS (pkg).

Tutto quello che dovete fare è lanciare il setup, attendere il completamento dell’operazione e poi collegarvi sulla porta standard 4040 (ovviamente personalizzabile a piacimento), loggarvi come amministratore e configurare i pochi semplici parametri necessari al funzionamento (es la directory che contiene i propri mp3).
Per esporre il servizio online potete scegliere se nattare il servizio oppure esporlo mediante un reverse proxy (io ho scelto quest’ultima strada), per fare in modo che il servizio utilizzi il protocollo https dovete seguire le semplici istruzioni che trovate in coda a questa pagina.

Riguardo alle applicazioni mobile (ma non solo) avete solo l’imbarazzo della scelta, a questo link trovate tutte le possibili alternative free o a pagamento; per utilizzarle vi basta installare la vostra prescelta sul dispositivo, puntare alla url del vostro server Subsonic e inserire le credenziali per autenticarvi.

Infine per raggiungere il vostro server Subsonic dalla fida ADSL di casa vi basterà registrarvi su uno dei tanti servizi di dns dinamico, crearvi un hostname pubblico e fare in modo che questo venga costantemente aggiornato con il vostro ip dinamico mediante le apposite utility fornite dal provider del servizio.

Beccatevi il mio gioiellino appena installato… e già, sono un fan sfegatato dei Dire Straits ;)