Come “dirottare” i flussi di I/O in bash

In generale in Linux esistono tre flussi standard di Input Output che consentono di far dialogare l’utente con il terminale. Questi sono: lo stream di ingresso (stdin), che porta alle applicazioni e al sistema operativo i dati immessi dall’utente tramite una periferica di input (tastiera), lo stream di uscita (stdout), che stampa a schermo i messaggi delle applicazioni, ed infine lo stream degli errori (stderr), che stampa gli errori a schermo.

Ad ogni flusso è associato un valore numerico, detto file descriptor, ed è proprio questo che viene utilizzato negli script bash per consentirne la redirezione. Con quest’ultimo termine intendiamo lo spostamento di una serie di dati che transitano in un flusso, verso un altro flusso. Ad esempio è possibile spostare i messaggi di errore che le applicazioni stampano in stderr sullo stream di uscita e viceversa.

Vediamo più da vicino come si fa.

La seguente tabella mostra la relazione tra i flussi e i loro descrittori:

stream file number
stdin 0
stdout 1
stderr 2

In generale possiamo redirigere il flusso x sul flusso y utilizzando la sintassi

x>&y

Quindi, se vogliamo spostare tutti i messaggi di errore sul normale flusso d’uscita la sintassi sarà

2>&1

Il flusso stdout è considerato quello di default e, quando si trova a sinistra della redirezione può essere omesso. Ad esempio:

>&2

Se vogliamo redirigere un output su file possiamo usare la stessa sintassi appena descritta, a meno del carattere &. Così, ad esempio, se vogliamo salvare su file ciò che un programma stampa a schermo possiamo usare la seguente sintassi:

x>/path/del/file

dove x può essere 1 oppure 2.

Per concludere facciamo qualche esempio completo di utilizzo.
ls >&2   Sposta l’output del comando ls sullo stream degli errori
ls >&2 2>/dev/null   Sposta l’uscita di ls sul flusso degli errori e poi redirige quest’ultimo su /dev/null (non stampa niente a schermo)
ls 2>/dev/null   Impedisce la visualizzazione degli errori dirottandoli su /dev/null
ls >&0 | echo   Passa l’output di ls ad echo che provvede a stamparlo a schermo (la sola pipe tra processi non funziona in questo caso, provatelo! ls | echo)

Per una descrizione più approfondita rimando alla seguente pagina: http://www.tldp.org/LDP/abs/html/io-redirection.html

I migliori tool di rete per Android

android

In questo articolo voglio proporvi alcune applicazioni per Android orientate all’analisi di rete. Messe insieme rappresentano il coltellino svizzero di ogni analista di rete e la cosa più importante è che si trovano (quasi) tutte gratuitamente sul Play Store di Google!

Premetto che non posterò immagini delle app per evitare problemi legali, ma sarà presente un rimando alla pagina dedicata da cui potrà essere direttamente scaricata. Cominciamo a vederli.

I migliori tool di rete per Android prosegui la lettura »

Keyper: l’Arduino che inserisce le password al posto tuo

Come preannunciato, vi voglio presentare un progetto che ho messo a punto a Gennaio di quest’anno e che ho poi migliorato nei mesi successivi. Il suo nome è Keyper, nato dall’unione di Key + Keeper; il motivo è semplice: lo scopo del dispositivo è quello di memorizzare le password personali e di digitarle, ad esempio in una casella di testo di una pagina web, quando si preme un tasto.

Keyper_1

Keyper: l’Arduino che inserisce le password al posto tuo prosegui la lettura »

Il ritorno

Eccomi! Sono vivo eh 🙂

Finalmente mi sono laureato! Ora ho intenzione di riprendere a scrivere qualche articolo su questo blog. Inizierò sicuramente pubblicando due progetti che ho fatto con gli Arduino all’inizio di quest’anno e poi vedremo cos’altro bloggare. 😉

Non perdetevi gli articoli dei prossimi giorni!

Dropbox: facciamo partire il demone all’avvio del sistema

Dropbox è un servizio di storage online molto diffuso, che offre 2GB di spazio cloud gratuito espandibile fino a 16GB se si invitano amici.

L’installazione in un ambiente grafico non desta problemi: esistono pacchetti facilmente installabili su tutte le distribuzioni Debian based e Fedora based ed esiste anche un pacchetto per Arch Linux.

Il problema sussiste quando si cerca di avviare il demone in ambienti senza DE, come può essere un server. Il sito non specifica cosa bisogna fare per avviare il demone all’avvio del computer, ma dice qual’è l’eseguibile che fa partire il servizio. Sulla base di queste informazioni si può costruire un init script che faccia tutto il lavoro.
Dropbox: facciamo partire il demone all’avvio del sistema prosegui la lettura »

Call for Papers Linux Day 2012

È aperto il Call for Papers per il Linux Day di quest’anno. Sarà il Roma2LUG, in collaborazione con l’LSLUG, ad organizzare l’evento.

Invito chiunque abbia voglia di presentare un talk di visitare la pagina sul blog ufficiale per maggiori informazioni.

Bloccare l’accesso a file specifici tramite .htaccess

A volte può essere utile impedire in un web server il download e la visualizzazione di un determinato file o una categoria di file caratterizzati da un’estensione specifica. Un esempio può essere l’uso di SQLite: lasciare libera la possibilità di scaricare il database potrebbe compromettere la sicurezza dei dati registrati in esso. Per ovviare al problema si può applicare una direttiva nel file .htaccess che ne limiti l’accesso da parte di client remoti.

Di seguito è presentata la sezione che impedisce la visualizzazione di tutti i file con estensione .htaccess, .htpasswd, .ini, .log, .sh o .db:

<FilesMatch "\.(htaccess|htpasswd|ini|log|sh|db)$">
Order Allow,Deny
Deny from all
</FilesMatch>

Con un po’ di fantasia si può personalizzare il codice per far in modo che si adatti alle specifiche esigenze. Ad esempio, se volessimo bloccare l’accesso a tutte le immagini:

<FilesMatch "\.(gif|jpe?g|png)$">
Order Allow,Deny
Deny from all
</FilesMatch>

Oppure tutti i file admin.php, admin.html o admin.htm:

<FilesMatch "^admin\.(php|html|htm)$">
Order Allow,Deny
Deny from all
</FilesMatch>

In generale la direttiva FilesMatch accetta delle espressioni regolari come argomento. Per maggiori dettagli rimando alla pagina di documentazione ufficiale di Apache: http://httpd.apache.org/docs/current/mod/core.html#filesmatch.

Abilitare interpretazione .htaccess per Apache2 su Debian 6

I file .htaccess vengono usati nei siti Internet per “scavalcare” (override in inglese) la configurazione base del Web Server.

In un’installazione usuale di Apache avviene questo: all’avvio il demone legge il suo file di configurazione (httpd.conf, 000-default o default, in base alla distribuzione usata) determinando il comportamento da tenere in seguito ad una richiesta HTTP di un client. Prima di elaborare la risposta, però, verifica se nella cartella che contiene il file richiesto (ad esempio una pagina index.html), o nelle cartelle superiori, è presente anche il file .htaccess e in tal caso lo legge modificando a runtime la sua configurazione e quindi il suo comportamento.

La versione di Apache2 che viene installata dai repository ufficiali di Debian 6 (Squeeze) di default non permette la sovrascrittura della configurazione mediante .htaccess, ma si può abilitare. Ecco come:

  1. Per prima cosa occorre abilitare il modulo mod_rewrite:
    # a2enmod rewrite
    Quest’istruzione non fa altro che creare un link simbolico del file “/etc/apache2/mods-available/rewrite.load” in /etc/apache2/mods-enabled/rewrite.load”
  2. Successivamente bisogna imporre nella configurazione base di Apache di cercare eventuali file .htaccess ed interpretarli. È necessario modificare il file “/etc/apache2/sites-enabled/000-default” da così:

    [...]
    DocumentRoot /media/data/www
    <Directory /media/data/www>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
    </Directory>
    [...]

    A così:

    [...]
    DocumentRoot /media/data/www
    <Directory /media/data/www>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    Order allow,deny
    allow from all
    </Directory>
    [...]

    Il percorso definito in DocumentRoot e in <Directory …> devono essere uguali.
  3. Riavviate Apache e il gioco è fatto:
    # service apache2 restart

Buon San Valentino!

Molta gente afferma che la festa di San Valentino sia solo una trovata commerciale, mentre altri ci credono fermamente. In ogni caso io ne approfitto per mostrarvi cosa si può fare con un paio di variabili e un piano cartesiano:

Heart curve

L’espressione matematica da cui si ricava la curva è la seguente:

x^2 + ( y - \sqrt{|x|} )^2 = 1

Si può graficare utilizzando Wolfram|Alpha, oppure una matita e una paginata di conti… A voi la scelta :).

Altri modi per rappresentare matematicamente il cuore sono visibili qui.

Auguri a tutti gli innamorati!

Il mondo un po’ più RISC

Il recente articolo di Paolo Attivissimo riguardo la lezione tenuta da Cory Doctorow mi ha dato modo di esprimere un pensiero che mi è balenato per la testa negli ultimi tempi.

Parlando di calcolatori, con il passare del tempo il mercato si è spinto sempre più verso delle soluzioni integrate e soprattutto portatili, che hanno favorito lo sviluppo di architetture RISC a discapito delle vecchie e care CISC. Se con un PC si può fare di tutto, in un sistema embedded si è molto limitati.

Perché non si è rimasti nel mondo del Complex Instruction Set Computer? Semplice, perché consumano troppo. L’architettura che tutti conoscono come x86 non è altro che un vecchio, vecchissimo processore 80386 del 1985 a cui si sono aggiunte le istruzioni che con le nuove generazioni di computer diventavano indispensabili. Ovviamente questa continua ristrutturazione non ha certo giovato, ma ha garantito la retrocompatibilità. Ai giorni d’oggi un processore x86 consuma troppo per poter essere impiantato su un dispositivo tascabile ed è per questo che ci si è diretti verso delle alternative. Guarda un po’, l’alternativa ideale era l’architettura ARM. Completa, affidabile, efficiente dal punto di vista energetico e anche a basso consumo. Però è RISC, ha un set ridotto di istruzioni che lo rendono non proprio idoneo a quelle mansioni General Purpose che si affibbiavano al PC. Per un utente che usa il computer solo per navigare o controllare la posta non è un problema, ma lo diventa non appena si tenta di fare qualche operazione un po’ più complessa.

Recentemente sono emersi dei rumor di possibili PC con processore ARM. Alla luce di quanto detto, questo potrebbe portare alla morte dei computer come li conosciamo, a vantaggio di soluzioni “castrate“. L’acquisto della BeagleBoard mi ha dato modo di provare sul campo una distribuzione Linux tipicamente usata su un computer (Ubuntu), ricompilata per architettura armv7 (armhf). Beh i risultati sono disastrosi. È vero che non scalda ed è affidabile, ma è come mettere un motore Ferrari su una Fiat. Si vede come il collo di bottiglia sia proprio la potenza di calcolo, in quanto si manifestano blocchi del sistema durante operazioni di elaborazione dati.

Il mio consiglio quindi è di godere dei bei vecchi processori che scaldano come forni, ma con cui ci si può fare di tutto, almeno fin quando non verranno soppiantati dai più eleganti e carismatici RISC.