Se siete giunti a questo post pensando che tratti della nota distribuzione GNU/Linux Fedora mi spiace per voi, ma siete nel posto sbagliato.
Fedora Commons è un apprezzato progetto opensource per la creazione e gestione di librerie multimediali (almeno così è come me l’hanno venduto, ma sapete meglio di me che è sempre bene non fidarsi mai di commerciali e project manager…).

Durante il setup di una istanza di test dell’ultima versione disponsibile (3.7.1) sono incappato in un brutto errore, terminato il setup senza alcuna anomalia faccio partire l’istanza di Tomcat su cui è deployata l’applicazione e come risultato ottengo un catalina.out relativamente pulito e una tristissima homepage di amministrazione del servizio su cui campeggia una orribile errore 404 :(

In realtà nel catalina.out qualche problemino c’è proprio durante l’avvio dell’applicazione fedora.war (ma va?), così mi metto alla ricerca di dettagli nel log della suddetta in $FEDORA_HOME/server/logs/fedora.log, dove campeggia un gargantuesco errore di creazione di una delle tabelle (db MySQL nel mio caso).

Verificando sul db in effetti la creazione delle tabelle è ferma a quelle indicate nel log (ma va?) e le stesse sono prive di record.
Vista la banalità dell’errore (ma chi ha validato gli script di creazione del dbms?!?) ho corretto creando manualmente la tabella, poi cercando online ho trovato un gentile utente che suggerisce di definire sia come UNIQUE KEY che come PRIMARY KEY il campo rebuildDate usando la query:

CREATE TABLE fcrepoRebuildStatus (
  rebuildDate bigint NOT NULL,
  complete boolean NOT NULL,
  UNIQUE KEY rebuildDate (rebuildDate),
  PRIMARY KEY rebuildDate (rebuildDate)
);

Questa volta al riavvio tutto pare procedere per il meglio, se poi dovesse capitare che a forza di fare tentativi ed esperimenti fedora commons dovesse proprio incazzarsi non vi resta che lanciare l’apposito script di ricostruzione del database fedora-rebuild.sh (ricordatevi di definire le tre variabili d’ambiente sacre, JAVA_HOME, FEDORA_HOME e CATALINA_HOME).

Al termine potete godervi un fedora.log pulito e il servizio finalmente raggiungibile alla url http://server:9080/fedora/admin

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!

Un software open source che utilizzo parecchio sui miei sistemi e su quelli dei miei clienti è Collectd, che ormai è diventato il mio standard in fatto di storicizzazione dei valori di carico e dell’andamento delle risorse sui miei server linux.

Si tratta di un ottimo software che non ha dipendenze clamorose (giusto rrdtool per conservare i dati in formato rrd), che rileva i dati direttamente dal sistema (/proc) e che soprattutto non si appoggia ad altro, in particolare al protocollo SNMP (come ad esempio il celebre Cacti); insieme all’ottimo Collectd Graph Panel permette di tenere tutto sott’occhio tramite una comoda (e bella) interfaccia web based in php.

L’unico difetto di Collectd è che se utilizzato male tende a piegare lo storage più performante a causa dell’elevato numero di IOPS generati, il fenomeno è direttamente proporzionale al numero di database rrd utilizzati quindi si manifesta soprattutto se si utilizza il plugin network per centralizzare la raccolta dati su una singola macchina; il risultato è un server ridotto ad un 486 a causa dell’eccessiva sollecitazione del sottosistema di storage in termini di scritture.
Qui potete vederne un esempio, si tratta di poche decine di server per un totale di circa 3800 file rrd collezionati mediante plugin network con le impostazioni di default, in pratica un chiaro caso di “I/O Hell”

Per risolvere il problema occorre da una parte un po’ di buon senso e dall’altra un paio di semplici accorgimenti nel file di configurazione (/etc/collectd.conf).

1) Raccogliete i dati che servono, evitate il resto.
Sembrerà una banalità ma spesso di default sono attivi un sacco di plugin che in realtà su molte macchine non servono, se ad esempio state monitorando un server su cui vengono fatti accessi locali solo a scopo amministrativo, e questi vengono loggati altrove, che senso ha attivare il plugin users e generare degli rrd inutili?

2) Fate attenzione ai device del plugin disk.
I server connessi ad una san spesso si ritrovano con un gran numero di lun e di conseguenza di device di storage, se per giunta utilizzano LVM si generano una serie di altri device rilevati dal plugin “disk” (/dev/dm-*) che rappresentano i device map dei logical volumes, valutate se vi serve davvero monitorarli, ed eventualmente escludeteli limitandovi ai device fisici (es /dev/sd*)

3) Utilizzate il plugin rrdtool solo dove serve.
Se raccogliete i dati su un server centralizzato tramite plugin network è inutile (e ridondante) conservare gli stessi dati anche in locale, genererete il doppio degli IOPS (sulle interfacce di rete e sui device di storage locali) senza alcun reale beneficio (se volete un backup fatelo sul server che raccoglie tutti gli rrd…).

4) Utilizzate le opzioni CacheTimeout e CacheFlush del plugin rrdtool.
Queste sono la vera manna nel caso di I/O Hell, abilitando questi due parametri Collectd non scriverà ogni modifica ai file rrd istantaneamente ma la terrà in RAM per un certo numero di secondi (definito dal parametro CacheTimeout), al termine dei quali effettuerà un’unica scrittura. Il parametro CacheFlush forza la pulizia della cache dopo un certo numero di secondi, giusto per fare “pulizia” nel caso qualche server abbia smesso di rispondere oppure qualche rilevazione sia rimasta in sospeso per qualsiasi motivo.

Potete osservare l’impatto di queste modifiche nel grafico che segue

• I/O Hell (1)
• Rimozione dei plugin inutili e dei device poco significativi (2)
• Attivazione CacheTimeout con frequenza pari a 120″ (3)
• Attivazione CacheTimeout con frequenza pari a 300″ (4)

Come potete osservare il numero di IOPS si è DRASTICAMENTE ridotto, e soprattutto non si verifica più l’affollamento di scritture presente prima della modifica.
Come risultato il server finalmente è tornato ad avere tempi di risposta fulminei (in precedenza aprire la homepage di Collectd Graph Panel richiedeva una trentina di secondi buoni, generare una decina di grafici poteva richiedere anche un minuto o più) e il carico di sistema ne ha beneficiato.

L’unica conseguenza negativa di questa operazione è il fatto che i grafici non vengono più aggiornati in real time ma soltanto quando il plugin rrdtool salva i dati nei file rrd, un disagio tutto sommato accettabile considerando i benefici, senza contare che il ritardo è passibile di tuning in base al livello di carico e al numero di rrd file da gestire.

L’indicizzazione full text di IBM Domino è sempre stata, è, e sempre sarà una gran figata per tanti motivi, primi fra tutti l’oggettiva utilità e semplicità necessaria per implementarla.
Mentre altri prodotti (che mi piace etichettare come “polpettoni”) propongono servizi di indicizzazione invasivi, pesanti, estremamente complessi e dall’efficacia spesso risibile, l’indice full text di Domino è una delle tante certezze di questo prodotto, un paio di click e l’indice è pronto all’uso.

Recentemente mi è però capitato un piccolo problema proprio durante la generazione dell’indice di alcuni nsf, lanciato il processo l’indice non è stato creato creato (nemmeno la directory “<nomedb>.ft”) e nel log.nsf è comparso il seguente messaggio di errore estremamente “parlante”.

Una breve ricerca sul sito IBM mi ha portato alla seguente technote che spiega la motivazione dell’errore e suggerisce di aggiungere nel file notes.ini il parametro TEMP_INDEX_MAX_DOC=<number>, dove il valore della variabile corrisponde al numero di documenti ammessi nell’indice temporaneo che viene creato durante il processo di generazione dell’indice full text.

Veloce restart dell’istanza Domino e problema risolto!