Experimentalia

Stamattina il blogroll si è arricchita di un indirizzo che, in questo, momento reputo prezioso.

www.dns-oarc.net è l’indirizzo web di un centro di ricerca che si occupa dei DNS e da qualche giorno, anche se io l’ho scoperto solo, ora è disponibile un test per i server DSN.

Si tratta di un test che verifica l’applicazione di alcune patch di cui si è fatto un gran parlare qualche giorno fa, soprattutto per il verificarsi di un ipotetico 0-day; un giorno in cui tutti i maggiori sviluppatori di DNS avrebbero risolto alcune vulnerabilità da poco scoperte e largamente, se non universalmente, diffuse.

C’è una comoda pagina che permette di fare il test dei dns che un computer sta utilizzando, ma non finisce qui.

E’ possibile, infatti, da linea di comando, interrogare un qualunque dns.

Il comando è

dig @<dns-ip> +short porttest.dns-oarc.net TXT

dove, ovviamente <dns-ip> è l’ip del server dns da testare.

L’esito della risposta può essere POOR, FAIR o GOOD, la sua interpretazione dovrebbe essere semplice ma in caso ci fosse bisogno di ulteriori informazioni si può fare riferimento al post originale sul sito di dns-oarc.

Ovviamente ho testato i dns che uso normalmente (opendns) e sono risultati molto affidabili mentre i dns che mi vengono comunicati dal provider (alice) hanno comportamenti differenti: molto affidabile il principale, 85.37.17.52, mentre non affidabile il secondario 85.38.28.92.

E questo è tutto.

P.S.

Anche punto-informatico.it ha segnalato il problema e, tra i commenti all’articolo, si trova l’indirizzo di un altro sito che permette di testare i dns: www.doxpara.com

Una comodità che apprezzo particolarmente è la possibilità di  aprire una shell in una directory semplicemente facendoci click da nautilus.

Per questo, una delle prime cose che faccio dopo aver installato un sistema è inserire nella directory degli script di nautilus questo piccolo script che non fa altro che permettere di aprire una finestra del terminale con la current working directory settata alla directory selezionata in nautilus.

#!/bin/bash
# apre un terminale nella directory selezionata

ERR01="Il comando funziona sulla finestra corrente o su una singola directory"
ERR02="Solo le directory locali possono essere raggiunte"

protocol=`echo $NAUTILUS_SCRIPT_CURRENT_URI | cut -c -7`

if [ $protocol='file://' ]; then
file_count=`echo -en "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" | wc -l`
TARGET=`echo $NAUTILUS_SCRIPT_CURRENT_URI | cut -c 8-`

  if [ $file_count -gt 1 ]; then
    zenity --warning --text "$ERR01"    
  else
    if [ $file_count -eq 1 ]; then
      CANDIDATE=`echo -en "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" | head -n 1`
      if [ -d  $CANDIDATE ]; then
        TARGET=$CANDIDATE
      fi
    fi
    gnome-terminal --working-directory "$TARGET"
  fi
else
  zenity --warning --text "$ERR02"
fi

Stasera ho installato una nuova macchina per un amico e mentre personalizzavo il sistema mi è capitato tra le mani questo file che uso talmente tanto da considerarlo scontato ed ho pensato di utilizzarlo come spunto per questo piccolo post.

Non sarà l’ultimo grido in fatto di scripting ma è comodo e magari, oltre ad aiutare qualcun altro, può essere un piccolo spunto per cominciare ad esplorare la programmazione di Nautilus.

E questo è tutto.

Da bravo sviluppatore web la mia cassetta degli attrezzi contiene, tra le altre cose firebug e la web developer bar. Potete immaginare il mio entusiasmo quando appena aperta la pagina degli esempi di etxjs mi sono trovato davanti al messaggio: Attenzione, firebug causa problemi di performance ad extJs.

Se poi considerate che la frase – causa problemi di performance – è un eufemismo, vi lascio immaginare la mia strabordante contentezza.

Se le performance possono non essere un problema, potrete facilmente figurarvi il mio sconforto alla scoperta che anche l’esecuzione passo passo è inutilizzabile. Dopo qualche tentativo ed esplorazione tra i forum di supporto, le invettive dei diversi sviluppatori che si trovano davanti al problema (si, non sono solo) capisco, almeno credo di capire, che il problema è dovuto alle dimensioni dello script extJs.

Le 34343 linee di codice per la libreria sono troppe per firebug che, sul mio sistema non riesce a tracciare l’esecuzione quando quest’ultima arriva al file ext-all-debug.js.

Piuttosto che procedere alla cieca sperando di arrivare all’errore senza troppi blocchi, o almeno senza troppe pause troppo lunghe per la mia quasi infinita pazienza, ho pensato di sezionare la libreria in più file.

L’espediente sembra funzionare e quindi non mi resta altro che riportare il piccolo script che seziona la libreria principale e sperare che la cosa possa essere di aiuto a qualcuno.

#!/bin/bash
# checksum md5 del file ext-all-debug.js
EXT21_MD5SUM='b854fc982dcec3781f1beb9653f33234'
MD5_PATH=`which md5sum`
INPUT_MD5=`$MD5_PATH $1  | cut -f 1 -d \ `

if [ "$2" = "" ]
then
    DIR='.'
else
    DIR=$2
fi

if [ "$EXT21_MD5SUM" = "$INPUT_MD5" ]
then
    head $1 --lines 2036 > $DIR/ext-all-debug-p01.js
    head $1 --lines 5679 | tail --lines 3643 > $DIR/ext-all-debug-p02.js
    head $1 --lines 8125 | tail --lines 2446 > $DIR/ext-all-debug-p03.js
    head $1 --lines 10897 | tail --lines 2771 > $DIR/ext-all-debug-p04.js
    head $1 --lines 13672 | tail --lines 2775 > $DIR/ext-all-debug-p05.js
    head $1 --lines 16309 | tail --lines 2636 > $DIR/ext-all-debug-p06.js
    head $1 --lines 19076 | tail --lines 2766 > $DIR/ext-all-debug-p07.js
    head $1 --lines 21817 | tail --lines 2741 > $DIR/ext-all-debug-p08.js
    head $1 --lines 24851 | tail --lines 3034 > $DIR/ext-all-debug-p09.js
    head $1 --lines 27420 | tail --lines 2569 > $DIR/ext-all-debug-p10.js
    head $1 --lines 31057 | tail --lines 3637 > $DIR/ext-all-debug-p11.js
    tail $1 --lines 3285 > $DIR/ext-all-debug-p12.js
else
    echo -e ' Questo script funziona solamente con la versione 2.1 di extjs\n' \
         'In particolare seziona il file ext-all-debug.js'
fi

Come primo parametro va il path della libreria, ext-all-degub.js, come secondo il path dove andare a salvare i vari spezzoni.

Includere i tag script corrispondenti, salare, mettere in forno e debuggare quanto basta.

Questa mattina mi son svegliato, ed ho trovato un post stuzzicante che promette, e mantiene, di aggiungere alla linea di comando un semplice traduttore. Si tratta di uno script di una riga che si appoggia a http://www.wordreference.com per effettuare la traduzione.

Alla fine del post c’è la richiesta di spendere qualche minuto attorno a google ed al suo sistema di traduzioni per poter fare la stessa cosa.

una prima versione la trovate quì sotto, non si tratta più di un one line script perché ho l’ossessione di aggiungere parametri a tutto il codice che posso manipolare. Mi passerà.

Il codice non è elegantissimo ma più che qualche minuto non potevo assolutamente dedicargli.

#!/bin/bash
S='auto'
T='it'
if [ "$2" != "" ]; then
  S="$2"
fi
if [ "$3" != "" ]; the
  T="$3"
fi

lynx "http://translate.google.com/translate_t?sl=$S&tl=$T&text=$1" -dump | \
     grep "Suggest a better translation" -B2 | head --lines=1

I parametri sono semplicissimi da usare, ammesso di chiamare tran il file, basta invocarlo con la parola da tradurre come unico parametro. Google cercherà di individuare la lingua della parola e ne restituirà, se riesce, il corrispettivo in italiano.

In caso sia necessario allora si possono specificare anche il codice iso della parola da tradurre, ed il codice della lingua in cui tradurre, rispettivamente come secondo e terzo parametro.

Le migliorie possibili sono tante, ad esempio usare l’opzione -source invece che -dump in lynx in modo da essere sicuri di individuare la parola tradotta nell’html che google restituisce ma il tempo, per ora, è tiranno.

Promemoria:

Tutto un pomeriggio perso dietro ad un problema che, al giorno d’oggi, non dovrebbe neanche porsi:

No, non sto criticando Firefox, sto criticando me stesso che mi atteggio ad essere uno pseudoprogrammatore. Analisi dei flussi, pattern, programmazione agile (magari) e poi mi perdo in un bicchier d’acqua.

Mi è capitato che un banale script:

<script type="text/javascript" >
//<!--
var stats = "toolbar=no, location=no, directories=no, "
    stats +="status=yes, menubar=no, scrollbars=no, top=0, "
    stats +="resizable=no, width=1100, height=678, left=0";
window.open("indexFraming.php", "", stats);
window.opener=self;
self.close();
//-->
</script>

Venisse eseguito due volte da Firefox ed una volta sola da Internet Explorer 6. Non ho testato altri browser per mancanza di tempo e voglia. Chi volesse integrare con commenti è, al solito, benvenuto.

Racchiudere il codice all’interno di una funzione, anche anonima, ed eseguirlo al termine del caricamento della pagina, risolve il problema.

<script type="text/javascript" >
//<!--
window.onload=function () {
   var stats =  "toolbar=no, location=no, directories=no, "
       stats += "status=yes, menubar=no, scrollbars=no, top=0, "
       stats += "resizable=no, width=1100, height=678, left=0";
window.open("indexFraming.php", "", stats);
window.opener=self;
self.close();
}
//-->
</script>

E questo è tutto.

Oggi la sveglia non ha suonato, sono caduto dal letto di prima mattina, e, come scriveva Jack Torrance in Shining, il mattino ha l’oro in bocca. Ne approfitto per un rapido post.

Cercavo un sistema veloce per creare dei modelli di documento necessari a Nautilus per creare al volo particolari tipi di file, ne parlerei se non avessi l’impressione di aver scoperto l’acqua calda, quando mi sono imbattuto in una funzione del file manager che non conoscevo.

Veniamo al sodo:

Nell’aprire una directory (forse dovrei dire cartella ) Nautilus cerca un particolare file chiamato .hidden.

Se lo trova allora non visualizzerà quei file che sono elencati, uno per riga, al suo interno. Come esempio vi mostro il contenuto di quello che, al momento, presidia la mia home directory:

Templates
Desktop
eclipse
workspace

Questo sistema si assomma a quello classico nel mondo unix per la gestione dei file nascosti (che consiste nel far cominciare il loro nome con il carattere “.”) anche se, ovviamente,  è funzionale solo per gnome e per nautilus. Per quanto abbia cercato non so di altri file manager che sfruttino questo file.

La console, ovviamente, non tiene conto di .hidden ed i file vengono visualizzati normalmente.

Attivando l’opzione di Nautilus che permette di visualizzare i file nascosti allora salteranno fuori sia i file prefissati con un punto sia quelli elencati in .hidden.

Ora vi lascio perché questo post ha raggiunto le 237 parole, non fateci caso, però.

Ci siamo lasciati con l’amaro in bocca, vi avevo promesso giocolerie impreviste, si magari avrò anche esagerato, e vi ho lasciato dopo aver appena introdotto gli operatori di redirezione in bash.

Sono qui per rimediare e ci mettiamo subito a lavoro. La volta scorsa abbiamo parlato dei tre file descriptor predefiniti ma avevo anche accennato alla possibilità di avere anche altri file descriptor aperti. Per aprirne uno non bisogna far altro che reindirizzarlo dove meglio ci aggrada.

Per esempio provate a digitare il comando

echo “ciao 12″ >&12

Che genererà un messaggio di errore e poi provate a digitare un comando simile ma funzionante (anche se apparentemente inutile)

echo “Il comando di prima non funzionava, questo si” 12>&1 >&12; echo “anche questo non funziona” >&12

Non è inutile perché ci fa capire due cose: che i reindirizzamenti procedono da sinistra a destra e che i file descriptor non standard vengono chiusi al termine dell’esecuzione di un comando/script.

Per inciso, è possibile chiudere esplicitamente un file descriptor utilizzando la sintassi n>&- dove n è il file descriptor da chiudere.

Possiamo anche rendere permanente una redirezione, o l’apertura di un file descriptor utilizzando exec. Questo comando non fa altro che lanciare una shell che sostituisce quella attuale e, nel fare ciò è possibile aprire dei file descriptor o reindirizzarne altri.

Per provare quest’ultima affermazione proviamo a farci uno scherzo. Apriamo due terminali e lanciamo il comando tty che non fa altro che stampare a video lo pseudofile cui è connesso il terminale. Da X troverete che il risultato sarà qualcosa di simile a  /dev/pts/0 ed a /dev/pts/1 per l’altra finestra.

A questo punto in nella prima delle due invochiamo il comando exec >/dev/pts/X dove X deve essere l’id del terminale della seconda finestra e voilà, l’output della vostra prima console andrà a finire tutto nella seconda (ad eccezione dello standard error che non viene influenzato). Per tornare alla normalità bisognerà semplicemente ridare il comando facendo puntare la redirezione alla console legittima.

Vi lascio con un’ultimo trucco:

command 3>&1 1>&2 2>&3

che non fa altro che scambiare tra di loro i file descriptor di standard output e standard error, nel caso servisse.

E questo è tutto, per ora

In un precedente pezzo ho scritto qualche parola su tee e vi raccontavo che la sua principale limitazione era l’impossibilità di registrare quanto stava accadendo sullo standard error. Vista la natura introduttiva del pezzo ho preferito non tediarvi con le giocolerie possibili con i file descriptor e restare concentrato sul comando.

Ora è venuto il momento, nel frattempo ho studiato, di affrontare il problema e fare qualche gioco di prestigio con stderr e stdout. Tutto questo senza l’ausilio di altro che le nostre dita, una tastiera e la nostra amata, odiata,mai indifferente, bash. La carne al fuoco è tanta e quindi ho deciso di dividere il tutto in più parti.

Partiamo con un minuscolo script d’esempio per introdurre i file descriptor ed i comandi di redirezione.

#!/bin/bash
echo "Questo è un messaggio indirizzato allo standard error" 1>&2
echo "Questo è un messaggio indirizzato allo standard output" 1>&1

Non penso ci sia davvero bisogno di spiegare quello che fa . Mi preme solamente illustrare la sintassi >&d, ma, prima, parliamo dei file descriptor, che non sono altro che delle astrazioni, dei segnaposto, di file aperti in lettura o scrittura.

Ad ogni programma, anche agli script bash, a voler essere precisi alla shell che esegue lo script, sono associati almeno tre file descriptor: uno per l’input, stdin, uno per l’output, stdout, ed uno, stderr, per la segnalazione degli errori. Hanno, nell’ordine, indice 0, 1 e 2.

Bash mette a disposizione due operatori, il man li chiama metacaratteri, per la redirezione: < e >.

Il loro uso è semplice e lo conoscerete già, ad esempio

echo 'hello file!' > nome di un file

fa in modo che la shell invii ‘hello file!’ ad un file piuttosto che al mondo intero. Abbiamo appena rediretto l’output su file. Analogamente l’operatore < permette di redirigere l’input e quindi possiamo restituire al mondo il saluto che gli dobbiamo con cat < file.

Se pensate che sia sconveniente salutare il mondo apostrofandolo file provate con

sed “s/file/world/” file | cat

Utilizzando >& al posto del semplice > è possibile redirigere i file descriptor tra di loro piuttosto che su file presenti sul filesystem (non ho scritto disco perché sarebbe inesatto).

A questo punto possiamo interpretare il comando

echo "Questo è un messaggio indirizzato allo standard error" 1>&2

come invia allo standard outpu (è quello che fa echo) la stringa “Questo è un messaggio indirizzato allo standard error” e subito dopo aggiungiamo: a proposito, invia i dati che passano per standard output (1)  dove vanno a finire i dati destinati allo standard error (2). Solitamente si usa la versione >&2 che sottintende 1 (stdout) come file descriptor di partenza. Il secondo comando presente nello script poteva tranquillamente limitarsi a

echo "Questo è un messaggio indirizzato allo standard output"

ma se non sono prolisso non mi diverto.

La redirezione finisce qui, per ora, abbiamo tutti i concetti base per proseguire con i nostri esperimenti ma ho ormai scritto troppo e vi rimando ad un prossimo approfondimento.

Una la voglio perché il testo devo formattare, una mi serve perché voglio salvare… Mi fermo qui con la citazione perché più di tanto non riesco a fare.

Primo luglio, il sole splende, il caldo è afoso e mi trovo a scrivere di un set di mille, diconsi mille, icone da utilizzare per lo sviluppo di applicazioni web.

Non vi racconterò di come sia riuscito a trovare queste icone perché non me lo ricordo più, vi basti sapere che ci sono inciampato sopra durante i primi approcci con la libreria javascript extjs.

Comincerò subito con l’unica vera critica che si può avanzare: 16×16 pixel possono essere troppo pochi per una icona ed il suo creatore ha chiaramente scritto sul sito che non ha intenzione di ricreare il set a diversa risoluzione. Qualche prova con gimp mi ha confortato sulla possibilità di ridimensionare le icone a 24×24 pixel senza perdere troppo in definizione, devo ammettere di aver provato solamente con le icone che vedete nell’immagine che illustra questo post e che bisognerebbe fare dei test più estesi ma non ne ho, per ora, il tempo.

La licenza con cui sono distribuite è la Creative Commons Attribution e quindi non avete da fare altro che percorrere il link scaricare l’intero set e cominciare ad esplorarne le potenzialità (ricordate di rispettare l’attribuzione richiesta dalla licenza se le utilizzate per altro che non siano prove e test).

Io, da canto mio ho intenzione di utilizzarle per la creazione di una piccola applicazioncina per la generazione di sprites css. Questa, però, è un’altra storia di cui vi terrò informati via via che l’esperimento procede.