unix | Rev0lut1on 2.0 of my mind engine

Feb 19 2009

La psicologia della ricorrenza numerica: 1234567890 Day, il Bug del 2038 e altre celebrazioni numeriche

Alle ore 3:31:30 PM dello scorso venerdi 13 febbraio 2009 (in Italia, a causa del fuso orario, erano le 00:31:30 del 14 Febbraio 2009), l’orologio interno dei sistemi Unix (e quindi anche Mac OS X) ha raggiunto il valore, non indifferente, di 1234567890 secondi. Infatti, come è noto, nei sistemi operativi Unix e Unix-like il tempo viene rappresentato come offset in secondi rispetto alla mezzanotte (UTC) del 1º gennaio 1970 (definita epoca o Epoch Time). Quindi, contando il tempo a partire dall’Epoch Time ad oggi sono appunto passati 1.234.567.890 secondi. Questo tipo di rappresentazione ha il vantaggio che, oltre che ad essere compatta, è indipendente dai fusi orari, ed è quindi direttamente confrontabile anche tra calcolatori situati a grandi distanze geografiche tra loro, ed evita di dover effettuare aggiustamenti nel caso ad esempio di dati trasmessi da un fuso orario all’altro. L’unico svantaggio è che, per averne una rappresentazione sotto forma di data e ora locali, è necessario effettuare una conversione (sempre comunque lasciata al sistema operativo).

1234567890 Day

Sebbene, questo evento non abbia nulla di realmente universale (è stato un convenzione comune decidere di iniziare a far scandire arbitrariamente l’orologio interno del cuore dei sistemi operativi Unix dalla data del 1970, ma c’è chi nota come lo scandire dell’Epoch Time sia approssimativamente vicina allo sbarco sulla Luna), l’evento ha suscitato un valore mediatico minimo, ma, al contempo, ha coinvolto i geek più puri di tutto il mondo (dai syadmin ai consulenti IT fino ad arrivare al semplice appassionato di Linux), in una maniera che solo internet può regalare con la versione geek del capodanno dell’anno 2000.

Infatti, questa curiosa ricorrenza ha visto persino dei festeggiamenti “ufficiali” da parte di gruppi di utenza e di programmazione in tutto il mondo. Il sito che ha raccolto tutti questi eventi è stato 1234567890day.com con tanto di countdown in homepage, anche se, per la verità, per molti questa ricorrenza altro non era che una scusa per organizzare una vera e propria rimpatriata di amici amanti del pinguino.

La celebrazione di questo particolare evento è stata pianificata in diverse città di tutto il mondo (San Francisco, Vancouver, Seattle, Los Angeles, Nairobi, Vienna, Copenaghen, Budapest, Croazia, etc … ovviamente è mancata una località italiana).

Per chi, comunque, non era riuscito a festeggiare questa singolarità numerica in compagnia, non è mancato il supporto di Digg (con oltre 5005 diggs) e di Twitter che ha unito centinaia di followers (423 per l’appunto) uniti nei festeggiamenti davanti al proprio monitor, magari supportati dalla Desk clock from ThinkGeek, una sveglia capace di visualizzare la data e l’ora in diversi formati, tra cui, oltre quello standard, anche Esadecimale, Ottale, Binario, a Numeri Romani e, ovviamente, nel formato Unix Epoch Time.

In alternativa, il sito Cool Epoch Countdown ha fornito, e fornisce tuttora, in tempo reale lo scandire del tempo in Unix Time.

Se questi festeggiamenti vi sono sembrati assurdi, allora dovete sapere che le frasi più ricorrenti che giravano sulla blogosfera fino a qualche giorno primo, erano tutte di genere apocalittico, come questa:

It’s The End Of The World As We Know It!
There’s a fairly good chance the world is going to end tomorrow…at least the world of Unix

Ovviamente, quando si tratta di cose strane, anche Google ci mette lo zampino e per festeggiare il 1234567890 Day, Google ha proposto uno dei suoi Doodle riportante la scritta

$ date +%s …
1234567890

Per i non addetti ai lavori, “date +%s” è il comando da lanciare sul vostro terminale linux/unix like/mac os x per vedere visualizzata la data nel formato unix time. Per sapere a che ora e che giorno corrisponde una particolare data in unix time, è sufficiente lanciare questo script in Perl (ma potete anche visitare uno dei tanti siti di conversione data/unix time):

perl -e ‘print scalar localtime(1234567890),”\n”;’
Sat Feb 14 00:31:30 2009

Altre celebrazioni numeriche create ad hoc

E se nel lontano 09 Settembre 2001 (2001-09-09T01:46:40Z) si sono festeggiati a Copenhagen in Danimarca (presso il DKUUG), il primo 1.000.000.000 di secondi, allora vi farà piacere che che nel lontano 18 Maggio 2033 alle ore 03:33:20, ricorrerà la celebrazione del Secondo Billenium: 2000000000!

perl -e ‘print scalar localtime(2000000000),”\n”;’
Wed May 18 05:33:20 2033

La cosa buffa è che, giocando con questo piccolo script in Perl, ho scoperto che il 9 Agosto del 2005, è ricorso il Fibonacci Day dei sistemi Unix (ho sostituito la data in unix time con la Successione di Fibonacci, escluso lo zero iniziale, 1123581321):

perl -e ‘print scalar localtime(1123581321),”\n”;’
Tue Aug 9 11:55:21 2005

ma nessuno ne ha mai parlato (o sbaglio?). Forse era una ricorrenza da geek matematici, una specie ancora più rara dei normali geek!

Continuando, possiamo notare che, il 14 Novembre del 2014, si potrebbe festeggiare il Pi Greco Decimal Day per i sistemi Unix (prendendo in esame la prima parte decimale del pi greco):

perl -e ‘print scalar localtime(1415926535),”\n”;’
Fri Nov 14 01:55:35 2014

Come vedete, i motivi per festeggiare ce ne saranno molti ed è tutto frutto della psicologia della ricorrenza numerica. Un comportamento tutto tipico dell’essere umano, che si è dimostrato in tutta la sua potenza mediatica nell’anno 2000 (amplificato poi anche dal famoso Millennium Bug). Per l’uomo tutte le ricorrenze numeriche sono sempre affascinanti, come quando si prendono le misure della Piramide di Cheope della piana di Giza in Egitto e si scopre che dividendo il perimetro della Piramide per il doppio dell’altezza si ottiene un valore molto simile al pi-greco. O quando Joseph Seiss, un ecclesiastico americano, scrisse che le pietre della Piramide contenevano un sistema di numeri che indicavano misure, pesi, angoli, temperature, gradi, problemi geometrici e rilevamenti cosmici. Seiss fu sorpreso dalla ricorrente presenza nei suoi calcoli del numero 5!

E che dire della sequenza numerica 4 – 8 – 15 – 16 – 23 – 42, nota come Equazione di Valenzetti, che la DHARMA, nel mondo immaginario del serial televisivo Lost, aveva il compito di modificare per evitare la fine dell’umanità. In poco tempo finzione e realtà si sono fusi insieme, girando per internet e assumendo connotazioni di quasi-realtà.

Ovviamente alcune ricorrenze numeriche sono talmente singolari che appaiono dare un significato agli eventi più strani, dando una sorta di potere ai numeri che si trasformano in elementi cabalo-matematici.

Il Bug del 2038

Ma vi è un’altra data che i programmatori di tutto il mondo stanno aspettando, questa volta, con grande paura (come quella del Millennium Bug): è il 19 gennaio 2038 alle ore 03:14:07 AM. Dopo questo momento, il contatore supererebbe il valore massimo, e verrebbe considerato come un numero negativo. I computer leggeranno la data non come 2038 ma come 1901 (precisamente, le 20:45:52 di venerdì 13 dicembre 1901) causando errori di calcolo!

Il problema è noto da tempo a tutti e la causa del bug informatico dell’anno 2038 (“Year 2038” è chiamato anche “Y2038”, “Y2K38”, o “Y2.038K” nel linguaggio specialistico) è da imputarsi all’architettura a 32 bit di molte macchine unix attualmente esistenti che usano, come spiegato prima, la rappresentazione POSIX per calcolare il tempo (partendo dal numero di secondi a partire dal 1 gennaio 1970). Questo tipo di sistema è lo standard per i sistemi Unix, e colpisce anche software per altri sistemi operativi che siano stati sviluppati in C. Sulla maggior parte dei sistemi a 32 bit il valore del dato time_t usato per questo calcolo è un numero intero a 32 bit di tipo signed.

Infatti, se un programmatore crea una variabile di tipologia intero segnato per memorizzare un valore numerico, questo può essere come minimo -2147483648 e come massimo 2147483647. Un numero molto grande, ma che diventa un valore piccolissimo se lo trasformiamo in secondi. In 32 bit, infatti, ci stanno appena 136 anni! Usando questo sistema, la data più avanzata rappresentabile a partire dalle 00:00:00 del 1/1/1970 sono le 03:14:07 di giovedì 19/01/2038!

La cosa interessante è che il mondo POSIX comprende, oltre ai sistemi operativi derivati dal sistema UNIX (GNU/Linux, BSD, Solaris, Mac OS X), anche tutti i protocolli di rete UNIX style (http, ftp, etc). In parole povere, se le previsioni nefaste degli addetti ai lavori si avverassero, sarebbe anche la fine di internet (che funziona grazie a protocolli Unix) e dei principali server del globo (che utilizzano sistemi operativi derivati da Unix). Dopo quel secondo saremo proiettati nel 13 dicembre 1901 alle 20:45. Sicuramente questo sarà un problema da gestire da qui ai prossimi anni e richiederà un cambio epocale nella gestione del tempo e di tutto il resto nei sistemi Unix. In teoria la soluzione è semplice e già disponibile, e consiste nell’usare solo sistemi a 64 bit, come il 99% dei processori in commercio attualmente. Infatti, nei sistemi a 32 bit il limite massimo di un intero è (2^32) – 1, mentre in quelli a 64 bit è (2^64) – 1.

Come denunciato anche dal sito ufficiale, 2038bug.com, però, l’errore comune è quello di credere che il problema verrà risolto con la semplice adozione dei 64 bit, non considerando che i molti strumenti che utilizzano sistemi embedded (forni a microonde, ascensori, orologi da polso, ecc.), sono ancora a 8/16 bit e che molti database utilizzano, per i propri campi data, dei Timestamp a 32 bit.

Un aspetto curioso di questa faccenda è che su questo bug del 2038 è stata costruita la storia di John Titor, un fantomatico uomo del futuro (2036) tornato nel 1975 per recuperare un esemplare di IBM 5100 come sorta di moderna Stele di Rosetta, poiché sarebbe l’unica macchina capace di risolvere il bug che sconvolgerebbe il mondo.

Interessante come, anche in questo caso, Google ci abbia messo lo zampino, perché i più attenti avranno scoperto che la data di scadenza dei cookie di Google è il 17 gennaio 2038, due giorni prima della fine dell’Unix Epoch (solo dopo questa data il browser può procedere all’eliminazione dei dati contenuti nel cookie stesso).

Ovviamente c’è anche chi, per celebrare l’evento, ha iniziato vendere magliette con la fine dell’Unix Epoch, ma anche tazze e mousepad per ricordarvi che, la fine dei sistemi operativi come voi li conoscete, è vicina!

Se invece, volete verificare se il vostro sistema è immune o meno da questo bug, ecco il codice C da compilare:

#include <stdlib .h> #include <stdio .h> #include <unistd .h> #include <time .h> int main (int argc, char **argv) { time_t t; t = (time_t) 1000000000; printf (“%d, %s”, (int) t, asctime (gmtime (&t))); t = (time_t) (0x7FFFFFFF); printf (“%d, %s”, (int) t, asctime (gmtime (&t))); t++; printf (“%d, %s”, (int) t, asctime (gmtime (&t))); return 0; }

Questo semplice esempio in C mostra come l’aggiunta di un solo secondo al Timestamp ”Tue Jan 19 03:14:07 2038” lo tramuti in un sinistro venerdì 13 dicembre 1901. Quindi, se il vostro sistema è a 32 bit, dovrebbe produrre questo risultato:

1000000000, Sun Sep 9 01:46:40 2001
2147483647, Tue Jan 19 03:14:07 2038
-2147483648, Fri Dec 13 20:45:52 1901

Ecco una simulazione di quello che accadrebbe nel 2038 ai sistemi unix a 32 bit:

UPDATE: Ho appena scoperto che molti geek matematici festeggiano la giornata della radice quadrata che viene celebrata nella data in cui, sia il giorno che il mese, risultano essere la radice delle ultime due cifre dell’anno. L’ultima festività è occorsa il 03 Marzo 2009 (3/3/09 Square Root Day), ma beccare la radice giusta non è facile come sembra (sembra che capiti solo 9 volte in un secolo). Se vogliamo continuare a dare i numeri, l’ultimo giorno papabile prima di questo è stato infatti il due febbraio del 2004, che casualmente coincideva con il ‘giorno della marmotta’ americano. Per festeggiare di nuovo dovremo aspettare ben sette anni, esattamente il quattro aprile del 2016. Il primo a celebrare questo evento è stato, nella lontana radice dell’81, Ron Gordon.

Tag:2038, 42, blogosfera, bug, digg, fibonacci, geek, Google, Linux, lost, mac, perl, pi-greco, titor, twitter, unix

2 comments

Dic 5 2008

Come scaricare da Rapidshare da riga di comando con Linux o Mac OS X

Posted by Antonio Troise

Wget Rapidshare Alle volte può sembrare che, quando vengono proposte soluzioni a riga di comando, ci si voglia complicare le cose nonostante esistano decine di altri modi, molto più user friendly, semplici, efficaci e veloci. Vi starete chiedendo per quale motivo una persona vorrebbe scaricare un file da riga di comando piuttosto che usare una delle tanti utility grafiche e gratuite disponibili o, più semplicemente, usare il download manager del proprio browser, che qualunque esso sia, svolge già efficacemente il proprio lavoro?
Ebbene, la ricerca di queste soluzioni alternative avvengono semplicemente per necessità e non solo per il gusto di complicarsi la vita lanciandosi ogni volta in nuove sfide, o almeno è questo quello che accade a me!

Vi siete mai chiesti o vi siete mai trovati nella situazione di dover scaricare qualche file in parallelo? Ebbene, sicuramente avrete constatato un inevitabile rallentamento del sistema direttamente proporzionale al numero di download simultanei che vengono lanciati, sia perché, almeno in minima parte il processore deve gestire il trasferimento, sia perché la scrittura di più file contemporaneamente sull’hard disk (anche se in questo caso il concetto di simultaneità non è verosimile) impegnano il drive tanto da lasciare indietro le operazioni del sistema operativo.

Ebbene, la situazione potrebbe essere spiacevole se su quello stesso PC ci dovete lavorare. Ed è allora che vi viene in mente che forse potreste riutilizzare quel vecchio PC che non usate più, formattarlo, installarci sopra una qualsiasi distribuzione linux, e usarlo esclusivamente come Download Manager. Quindi, ogni qualvolta, vorrete scaricare un o più file da Rapidshare, basterà che vi colleghiate in telnet sul PC Muletto, aprite un file di testo, incollate le url dei file Rapidshare da scaricare, salvate il file e lanciate un piccolo script che eseguirà per voi tutto il lavoro, senza appesantire il sistema su cui state lavorando. Ovviamente, il sistema che adotterò, per essere il più leggero e flessibile possibile, non disporrà di una interfaccia grafica, bensì sarà esclusivamente a riga di comando, insomma da veri geek. Ma vi assicuro che questa è la soluzione inaspettatamente più semplice per risolvere il vostro problema di performance.

In questa sede, comunque, affronterò esclusivamente la soluzione che risolverà il problema di come scaricare un file da Rapidshare se si possiede un abbonamento Premium e quindi si potrà disporre di un utente e password che vi garantirà un servizio che può accettare più richieste di download contemporanee (anche se come vedremo più tardi ho deciso di non usarlo per non appesantire il vecchio PC Muletto) e che non richiede alcun tempo di attesa tra un download e il successivo.

Installare WGET

Per la mia soluzione userò wget, un potente comando per scaricare una pagina web o inviare richieste GET o POST, con o senza autenticazione. Se disponete di un sistema Unix/Linux, è molto probabile che lo troverete compilato e già pronto per essere eseguito. Se invece vi trovate su un sistema Mac OS X (Tiger o Leopard che sia), nonostante si abbia a disposizione nel sistema operativo una shell unix completa di tutti i maggiori comandi, l’unico a mancare sarà proprio wget. Ci sono alternative altrettanto valide, come curl o ftp (e, per chi se lo ricorda, anche lynx che col comando “lynx URL >dump.txt” è una variante alternativa), ma per i nostri scopi, wget è abbastanza flessibile e semplice tanto da essere necessario per creare il nostro script. Quindi, per chi non volesse passare per la fase di compilazione, qui potete scaricare la versione compilata per i sistemi Mac OS X 10.5.3 e superiori (quindi anche Tiger e Leopard): wget.zip. Una volta scaricato sarà già funzionante sul vostro sistema, ma per una installazione completa, lanciate questi comandi:

cd wget sudo su root (enter password) mv wget.1 /usr/share/man/man1 mv wgetrc /usr/local/etc mv wget /opt/local/bin/wget

e se fosse necessario, eseguirte un

export PATH=$PATH:/usr/local/bin

anche se nel file .profile della propria home directory dovrebbe già contenere il percorso settato, come qui mostrato:

echo $PATH | grep -q -s “/usr/local/bin” if [ $? -eq 1 ] ; then PATH=$PATH:/usr/local/bin export PATH fi

Ora che abbiamo installato wget sul nostro sistema Mac, questo si comporterà a tutti gli effetti come un sistema Linux, quindi d’ora in poi non farò alcuna distinzione tra i due sistemi operativi.

Creare lo script – STEP 1

Per la creazione dello script ho preso spunto da my-guides.net e in questa sede mi dedicherò a spiegarne il funzionamento del codice adattato alle mie esigenze.

Rapidshare, per l’autenticazione, usa i cookie HTTP, dei file di testo inviati da un server ad un Web client (di solito un browser) e poi rimandati indietro dal client al server, senza subire modifiche, ogni volta che il client accede allo stesso server, e sono usati per eseguire autenticazioni e tracking di sessioni e per memorizzare informazioni specifiche riguardanti gli utenti che accedono al server.
Quindi, la nostra prima operazione, sarà quella di autenticarsi sul server Rapidshare e di salvare i cookie che mi permetteranno, in seguito, di scaricare qualsiasi file dal sito di hosting file.
Attensione, lo STEP 1, andrà eseguito solo una volta, perché i cookie, a meno che non si proceda alla loro eliminazione manuale, verranno salvati in una cartella della vostra home directory.

Il comando da lanciare è il seguente:

wget \ –save-cookies ~/.cookies_rapidshare \ –post-data “login=USERNAME&password=PASSWORD” \ –no-check-certificate \ -O – \ https://ssl.rapidshare.com/cgi-bin/premiumzone.cgi \ > /dev/null

dove i parametri indicano:

–save-cookies: definisce dove salvare i cookies. Essendo dati più sensibili ho preferito creare un file nascosto (anche se ciò non garantisce la sicurezza del file)

–post-data: assegna il metodo POST (piuttosto che GET) per inviare al form di login i dati di username e password.
–no-check-certificate: non richiede la validazione del certificato che restituisce il server (Se state usando una versione di wget precedente alla 1.10.2 l’opzione –no-check-certificate non è necessaria)
-O: esegue il download della pagina html solo per ottenere i cookie e redirige l’output su /dev/null per non far comparire a video le righe del codice html.

Ovviamente, ricordatevi di sostuire USERNAME e PASSWORD con quelli del vostro account Rapidshare.

Creare lo script – STEP 2

Ora, ogni qualvolta dobbiamo scaricare un file da Rapidshare, dobbiamo digitare quanto segue:

wget -c –load-cookies ~/.cookies_rapidshare URL

dove il parametro -c si occupa di recuperare un eventuale download precedentemente interrotto che, quindi, ripartirò dal punto di arresto, mentre il parametro –load-cookies esegue un caricamento preventivo dei cookie precedentemente salvati per ottenere l’autorizzazione a scaricare, per poi, infine, dare in pasto la URL desiderata del file da scaricare. Però, nel momento in cui dovete scaricare più di un file, è evidente che dover scrivere ogni volta questa riga può essere noioso. Ecco perché ci troveremo a dover scrivere un piccolo script bash che automatizzerà il processo, dandogli in input le righe di un file urls.txt (che conterrà un file per ogni riga):

#!/bin/bash for url in `cat $1` do wget -c –load-cookies ~/.cookies_rapidshare $url done

Salvate il codice sopra come file downloader.sh e rendetelo eseguibile con il seguente comando:

chmod +x downloader.sh

Ora copiate tutti i link dei file Rapidshare (uno per riga) che volete scaricare e incollateli nel file urls.txt. Quindi, per scaricare tutti i file, basterà digitare questo semplice comando:

./downloader.sh urls.txt

Et Voilà! Il gioco è fatto e potete disporre di un sistema leggero, indipendente e autonomo per scaricare decine di file senza appesantire il vostro PC.

Scompattare un file RAR da riga di comando

Di solito i file su Rapidshare vengono compressi nel formato RAR e qualche volta sono anche protetti da password. Se volete completare l’opera, potete scaricare l’utility per riga di comando per Linux (o Mac) unRar 2.71 (ma esiste anche unrar della rarlab) e una volta decompresso

tar xfvz unrar-2.71.tar.gz

è possibile compilarlo entrando nella cartella unrar-2.71 appena creata e lanciando i comandi

make make install

Ora vi ritroverete il file eseguibile unrar nella directory /usr/local/bin/ e quindi accessibile da qualsiasi directory.

Tag:bash, curl, download, export, Linux, Mac os x, password, rapidshare, shell, unix, wget

0 comments

Ago 12 2008

Tips Mac: come aggiungere il suffisso DNS su Mac OS X

Posted by Antonio Troise

In una rete locale, solitamente, il DNS è utilizzato per denominare i nodi TCP/IP, come i computer Windows o gli host Unix, in modo da risolvere i nomi simbolici. Lo schema dei nomi è gerarchico e consiste di nomi come wks1.domain.com. Perché un nome di dominio sia qualificato, occorre che sia combinato con il nome dell’host, per creare quello che i gergo tecnico si chiama FQDN (Fully Qualified Domain Name), ovvero un nome di dominio non ambiguo che specifica la posizione assoluta di un nodo all’interno della gerarchia dell’albero DNS:

FQDN = nome di host + nome di dominio

Quindi, se il nome di dominio è STARGATE.COM, il nome FQDN per l’host WKS1 è il seguente:

FQDN = WKS1 + STARGATE.COM = WKS1.STARGATE.COM

Quando un computer ricorre ad una interrogazione DNS per risolvere un nome costituito da un semplice nome di host senza l’estensione di dominio, il nome di dominio del DNS primario è aggiunto di default al nome di host.
L’opzione, presente in qualsiasi sistema operativo, di aggiungere altri suffissi DNS rispetto a quello indicato dal DNS Primario configurato, serve ad indicare un elenco di suffissi DNS (nell’ordine desiderato) che possono essere aggiunti al nome di dominio non qualificato. Così, se il nome del computer è WKS1 e il nome di dominio è STARGATE.COM e si tenta di fare un telnet, o una qualsiasi altra connessione, al server col solo nome del computer WKS1:

telnet WKS1

il nome di host inizialmente cercato sarà WKS1.STARGATE.COM. Nel caso il nome di host non sia risolto, quindi, verranno scansionati tutti gli altri suffissi DNS alla ricerca di un risoluzione del nome FQDN.

Aggiungere il suffisso DNS su Mac OS X

Per abilitare questa possibilità su un sistema Mac OS X, basterà aprire le Preferenze di Sistema, cliccare sull’icona Network, e dopo aver selezionato la rete usata (Ethernet o Wi-Fi),

cliccare sul tasto Avanzate e, nella finestra che si aprirà, selezionare il tab DNS e nel campo Domini di ricerca aggiungere i suffissi di dominio desiderati:

Tag:dns, dominio, Mac os x, risoluzione, Tips, Tips Mac, unix, wi-fi, Windows

0 comments

Lug 7 2008

Automatizzare le operazioni del cPanel da shell unix con i comandi wget, ftp e curl: download automatico del DB Mysql e monitorare la banda disponibile

Posted by Antonio Troise

Il vantaggio di possedere un computer con Mac OS X è quello di avere sempre a disposizione, perché inclusa nativamente nel sistema operativo, una shell unix completa, per i più esperti, o Automator, per i meno esperti. Quest’ultimo strumento è una applicazione davvero potente perché consente di creare in maniera visuale, grazie ad un diagramma di flusso (workflow) e trascinando le azioni una dopo l’altra (drag & drop), programmi di automazione davvero complessi e articolati.

Ma dopo aver lavorato anni sui sistemi unix, avere sottomano una potente shell unix, è una tentazione di cui davvero non posso fare a meno. Infatti, con la semplice concatenazione di comandi (pipeline) come grep, sed e awk (altri comandi utili possono anche essere sort, uniq tail, head, cut e wc) in una sola riga, è possibile estrarre (scraping) informazioni da pagine web. Infatti, struttando il fatto che le pagine html sono, anche se in misura minora ad un più ordinato e formattato file xml, strutturate con i TAG, con pochi comandi è possibile fare del sano Web_scraping.

WGET

Il comando più potente da riga di comando per scaricare una pagina web o inviare richieste GET o POST, con o senza autenticazione è, come noto, WGET.
Per scaricare un file è possibile usare una sintassi tipo:

wget http://www.miosito.it/directory/file.zip

Ma la vera potenza di wget risiede nella possibilità di realizzare, con una sola riga di comando, un mirror ad un sito web.
Quindi per scaricare un intero sito in locale basta scrivere:

wget –mirror http://www.miosito.it/

mentre, per scaricare solo una pagina con tutti i link interni:

wget -r -np http://www.miosito.it/index.htm

Il problema è che sui sistemi MAC OS X, wget non è installato di default e, quindi, per chi non volesse passare per la fase di compilazione (anche se in giro esistono versioni già compilate per Tiger e Leopard) o, comunque, ha semplicemente la necessità di scaricare solo una file o una pagina web, allora è possibile usare una delle due alternative preinstallate su Mac OS X: ftp e curl.

FTP

Il comando FTP può essere usato anche per scaricare file HTTP.
La sintassi è molto semplice:

ftp http://www.miosito.it/directory/nomefile.html

Come vedremo, in seguito, per i nostri scopi molto spesso il comando FTP è più che sufficiente per la maggior parte delle operazioni comuni.

CURL

CURL è un tool da riga di comando estremamente potente perché permette di scaricare in maniera molto flessibile ed automatizzata un qualsiasi numero di files da internet, secondo i protocolli HTTP o FTP, e di visualizzarli a schermo o di scriverli su disco.
La sintassi semplice, simile a quella dell’FTP, è:

curl -O http://www.miosito.it/directory/nomefile.html

In realtà la sintassi completa è:

curl “URL del file da scaricare” -o “nome da assegnare al documento scaricato su disco”

Ma la vera flessibilità del comando nasce dalla possibilità di usare nella sintassi dell’URL le parentesi quadre per indicare una serie di URLs incrementali.
Per esempio una sintassi tipo:

curl “http://www.miosito.it/image/129-[2947-2996]_img.jpg” -o “immagine#1.jpg”

creerà in modo automatico tutti gli URLs compresi nell’intervallo numerico specificato, e scaricherà in successione i file corrispondenti. Ai files sull’HD verrà assegnato il nome specificato dopo la flag -o, usando l’indice #1 per creare nomi univoci, incrementati allo stesso modo della sorgente.
In poche parole la singola riga di cui sopra equivarrà ad aver digitato in successione tutti i comandi:

curl “http://www.miosito.it/image/129-2947_img.jpg” -o “immagine2947.jpg” curl “http://www.miosito.it/image/image/129-2948_img.jpg” -o “immagine2948.jpg” … curl “http://www.miosito.it/image/image/129-2996_img.jpg” -o “immagine2996.jpg”

Attenzione: il flag -O dell’ultimo esempio differisce dal flag con la o minuscola usato in precedenza, in quanto per nominare il file sul disco rigido usa lo stesso nome del file remoto.

La successione di URLs incrementali non deve essere necessariamente numerica, ma anche alfabetica, ad esempio [a-z]. Inoltre in uno stesso comando si possono combinare più indici incrementali (notate come nel nominare il file è possibile usare anche i due indici #1 e #2)

curl “http://www.any.org/archive[1996-1999]/volume[1-4].html” -o “archive#1-vol#2.html”

Monitorare la banda del proprio sito da riga di comando

Dati gli ultimi problemi di esaurimento della banda che hanno afflitto il mio sito, era evidente che una delle prime necessità che avevo era quello di monitorare costantemente la banda usata. Il problema è che, per farlo, dovevo ogni volta accedere al cPanel, il Pannello di Amministrazione del mio sito, dove, in un menu laterale, era possibile visualizzare la banda usata.

Allora ho deciso di crearmi un semplice script che, scaricasse la pagina html del mio cPanel, andasse a selezionare, con il comando grep, la riga che conteneva la frase “Monthly Bandwidth Transfer” e attraverso due comandi awk (i file separator usati in Awk sono relativi alla mia pagina cPanel e potrebbero variare a seconda delle diverse versioni e configurazioni del pannello di controllo), estrarre la banda usata:

ftp http://username:password@www.miosito.it:3456/frontend/x3/index.html grep “Monthly Bandwidth Transfer” index.html | awk ‘BEGIN {FS = “</td> “} {print $4}’ | awk ‘BEGIN {FS = “>”} {print $2}’ rm index.html

Come potete notare, per semplicità ho incluso, direttamente nella URL, lo username e la password per accedere al Pannello di Amministrazione. Questo è possibile solo perché il metodo di autenticazione del cPanel si basa su htpasswd ma ricordiamo che non è un metodo sicuro perché, oltre a lasciare memorizzati informazioni personali, nella barra degli indirizzi del proprio browser o nella history del terminale usato, si lasciano tracce anche nei vari proxy in cui si passa e nei log del webserver, oltre, come comunque avviene l’autenticazione classica se non passa per SSL, con un semplice sniffer.

Ci tengo a precisare che quello sopra illustrato è solo uno dei tanti modi per risolvere il problema: questo, in particolare, è il primo che mi è venuto a mente, forte delle decine di script shell realizzati negli anni. Ovviamente è possibile anche renderlo più complesso ed efficiente, parametrizzando username, password e url e, magari, notificando con una mail o con un messaggio a video (magari anche con Growl), quando la banda è prossima all’esaurimento. Il tutto ovviamente potrebbe anche essere inserito nel crontab di sistema in modo da girare ogni ora.

Per esempio, un metodo non ortodosso, sarebbe quello di visualizzare l’output non a video ma direttamente in TextEdit usando il comando open con le pipeline. Per farlo, ho riunito i tre comandi sopra elencati in un file bash di nome: monitora_banda.bash.
Quindi lanciando:

./monitora_banda.bash | open -e -f

avremo questo risultato:

Più in generale questo è il risultato del comando ‘open’ presente su Mac OS X.
Altri esempi, potrebbero essere:

curl ‘http://example.com/encodingerror.html’ | open -a ‘Hex Fiend’ -f curl ‘http://example.com/example.html’ | open -a ‘TextMate’ -f curl ‘http://example.com/example.png’ | open -a ‘Preview’ -f curl ‘http://example.com/example.m4v’ | open -a ‘QuickTime Player’ -f

Ma le possibilità, come vedete, sono infinite. Ma lo scopo di questo articolo era solo di illustrare alcuni metodi per automatizzare da riga di comando delle procedure. Il resto è lasciato all’inventiva di ciascuno di voi.

Download automatico del backup del DB Mysql

Il mio hosting non supporta il backup automatico del DB di Mysql perché non gestisce correttamente le schedulazioni di comandi da riga di comando. E’ per questo che ho realizzato un semplice script da inserire nel crontab, per scaricare quotidianamente il backup del proprio database.
Infatti, sempre nel cPanel, è presente una sezione “Backups” che permette di scaricare, manualmente e con un link statico, un full backup del sito, oppure un backup parziale del solo database Mysql o della sola home directory (il concetto esposto rimarrà comunque analogo per qualsiasi soluzione adottiate).
E’ evidente che, a questo punto, con un semplice comando, è possibile scaricare da terminale i backup:

ftp http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz Requesting http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz 401 Access Denied Still Working Username for `cPanel’: username Requesting http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz (with authorization) 2106 KB 849.95 KB/s 2156900 bytes retrieved in 00:02 (849.92 KB/s)

Basterà quindi inserirlo (con il comando crontab -e) nel crontab (se non siete esperti potrete usare il Easy Crontab Creation Tool) in modo da fargli scaricare il backup del DB, per esempio, ogni giorno alle ore 11:30 del mattino:

30 11 * * * * ftp http://username:password@www.miosito.it:3456/getsqlbackup/db.sql.gz

Attenzione: come ogni comando da terminale, FTP (ma lo stesso vale se usate WGET o CURL) andrà ad operare nella directory corrente di lavoro, quindi se volete archiviare i file scaricati in una directory apposita, spostatevici preventivamente con il comando cd nome_directory.
Inoltre, dovete tenere presente che tutti i downloads andranno a scrivere lo stesso file e, quindi, ogni giorno ci si ritroverà con solo l’ultimo file scaricato. Se avete intenzione di tenere traccia di tutti i backup scaricati, dovrete rinominare il file, per esempio, aggiungendoci un suffisso come la data di download (realizzabile o con il comando curl o con uno script bash).

Tag:automator, awk, backup, banda, bandwidth, bash, cpanel, curl, database, download, ftp, grep, html, ksh, Mac os x, Mysql, password, sed, shell, unix, url, wget

5 comments

Feb 25 2008

Tips Mac: Esecuzione manuale delle routine di manutenzione periodica di Mac OS X 10.5 Leopard

Posted by Antonio Troise

Cron In Mac OS X, come qualsiasi sistema BSD, ci sono tre routine di manutenzione che vengono eseguite periodicamente con scadenza diversa e che son utilizzate dal sistema per ripulirlo, automaticamente, da tutti i file di cache e di log che normalmente vengono creati durante la normale vita del sistema operativo.

In particolare, su Mac OS X 10.5 Leopard:

Tutti i giorni, alle ore 3:15 AM, viene eseguita la routine:
/etc/periodic/daily/500.daily

La routine giornaliera rimuove eventuali file temporanei non eliminati, i log di sistema più vecchi di una settimana e quelli del server http Apache integrato nel sistema operativo.
Una volta a settimana, alle ore 4:30 AM, viene eseguita la routine:
/etc/periodic/weekly/500.weekly

La routine settimanale ricostruisce i database utilizzati dai comandi locate e whatis ed elimina i log scaduti di vari server (ftp, lookupd, mail, netinfo).
Una volta al mese, alle ore 5:30 AM, viene eseguita la routine:
/etc/periodic/monthly/500.monthly

La routine mensile genera un resoconto dei login effettuati dai vari utenti della macchina ed elimina quelli dei mesi precedenti.

In Mac OS X Tiger e Leopard le routine di manutenzione sono avviate da launchd, il servizio di sistema cui è deputata, tra le altre cose, l’esecuzione automatica delle operazioni pianificate (in Mac OS X 10.3 Panther e precedenti, le funzioni di launchd erano svolte da SystemStarter e crontab). Se volete approfondire il funzionamento di launchd, vi consiglio la lettura di questo articolo in italiano davvero esauriente!

Gli orari e i giorni in cui vengono eseguite le tre routine sono definiti rispettivamente nei seguenti file xml:

/System/Library/LaunchDaemons/com.apple.periodic-daily.plist
/System/Library/LaunchDaemons/com.apple.periodic-weekly.plist
/System/Library/LaunchDaemons/com.apple.periodic-monthly.plist

dove è possibile trovare voci simile a questa:

<key>StartCalendarInterval</key> <dict> <key>Hour</key> <integer>3</integer> <key>Minute</key> <integer>15</integer> </dict>

In condizioni normali il sistema, quindi, alle 3:15, alle 4:30 (anche se sul mio sistema la routine settimanale compare sempre alle ore 3:15) o alle 5:30 di mattina ripulisce automaticamente tutti i file temporanei, senza che l’utente debba fare granché; purtroppo, però, questo è vero solo nel caso di sistemi desktop che sono, per la maggior parte del tempo accesi anche di notte (iMac, MacMini o Mac Pro), ma per i portatili (Macbook e Macbook Pro), purtroppo, non è sempre così perché di solito di notte sono quasi sempre spenti.

In teoria, nel caso in cui all’orario definito il computer fosse spento o in stop, launchd dovrebbe eseguire l’operazione pianificata alla successiva attivazione della macchina. A giudicare dai log (/var/log/daily.out, /var/log/weekly.out e /var/log/monthly.out), launchd nell’ultima versione di Mac OS X 10.5 Leopard sembra più rigoroso di Tiger nell’esecuzione di queste operazioni.

Se, però, volete avere un maggior controllo delle operazioni o semplicemente volete ripulire manualmente il vostro sistema allora avete sempre la possibilità di lanciare manualmente gli script di manutenzione.
Prendendo spunto dalle schedulazioni di sistema e dando un’occhiata al file “periodic” col comando:

more /usr/sbin/periodic

che accetta come argomenti i valori daily | weekly | monthly, è possibile decidere di eseguire manualmente le routine di manutenzione, lanciando i seguenti comandi nel Terminale (che trovate in Applicazioni/Utility/Terminale.app oppure cercando in Spotlight la voce “Terminale”)

sudo periodic daily
sudo periodic weekly
sudo periodic monthly

Altrimenti, se la riga di comando non fa per voi, si possono usare diverse utility gratuite come MacJanitor, Maintenance o sterMachine che permettono di avviare le routine di manutenzione periodica da GUI.

Tag:leopard, mac, unix

6 comments

Gen 8 2008

Tutto quello che avreste voluto sapere sul file system del futuro a 128 bit ZFS

Posted by Antonio Troise

ZFS Lo ZFS (Zettabyte File System) è il più moderno file system esistente e il più ricco di funzionalità innovative, anche se per contro, forse perché troppo rivoluzionario, è quello meno compatibile tra tutti. Infatti, concentrandoci solo sul mondo Mac (dato che per Windows ancora non è previsto alcuno sviluppo futuro), un disco formattato ZFS non verrà riconosciuto dal computer che non avrà almeno installato Mac OS 10.5 Leopard: quest’ultimo, però, riesce, almeno per ora, solamente a leggere il contenuto del disco ma non è ancora possibile scrivervi sopra (in pratica come avviene, nativamente, con i filesystem NTFS su Mac o, più semplicemente, per i CD-ROM di qualsiasi sistema operativo). In effetti mesi fa si supponeva che con Leopard vi fosse stato il supporto completo con ZFS ma, purtroppo Apple sta ancora sviluppando la funzionalità di scrittura sui dischi ZFS e ha promesso che in un aggiornamento successivo di Mac OS X 10.5 verrà aggiunta.

Dopo questa premessa, viene naturale chiedersi cosa abbia questo filesystem da far parlare tanto di sé. Innanzitutto occorre chiarire che un file system è un meccanismo mediante il quale è possibile immagazzinare e ordinare cartelle e documenti affinché sia facile, in un secondo momento, la ricerca e l’accesso ad essi.

ZFS è un file system open source moderno e potente sviluppato nei laboratori della Sun Microsystems nel 2004 per il suo sistema operativo Solaris ed è famoso per l’integrazione in un unico file system di diversi concetti presi da vari file system in un unico prodotto.
Nel giugno 2007 viene annunciata l’adozione di ZFS anche per il Mac OS X Leopard di Apple, notizia inizialmente smentita nel corso del WWDC07 da Brian Croll, senior director di product marketing per Mac OS, che ha dichiarato che “ZFS non ci sarà”, salvo poi smentire le smentita. ZFS non sarà comunque il file system principale di Mac OS 10.5 Leopard ma piuttosto affiancherà HFS+.

Si sta, inoltre, lavorando perché ZFS diventi, de facto, uno standard comune di filesystem Unix: è open-source e molti altri sistemi Unix o Unix-like (Solaris, FreeBSD, NetBSD, Linux) lo supportano o stanno lavorando per farlo. Il beneficio di uno standard comune è enorme, perché permetterebbe di lavorare tutti insieme per il miglioramento del futuro dell’informazione (storage). In effetti, sin’ora non si è mai avuto un file system comune a Windows, Linux e Mac. Infatti, una delle mancanze più sentite di Mac OS X, parlando di filesystem, è quella del supporto pieno ed ufficiale dell’ext3 di Linux e di NTFS di Microsoft (dovuto soprattutto agli alti costi in termini di ingegnerizzazione con un ritorno minimo negli investimenti). Chissà se con ZFS le cose cambieranno!

Se volessimo dire cosa è lo ZFS, una definizione veloce potrebbe essere questa:

ZFS è un nuovo tipo di file system che fornisce una semplice amministrazione, una approccio transazionale, una integrità del dato “end-to-end” e una immensa scalabilità (128-bit). ZFS non è un miglioramento “incrementale” alla tecnologia esistente, ma è un nuovo approccio alla gestione dei dati creato eliminando alcune assunzioni di base che risalevano a 20 anni fa.

Se non avete ancora chiaro il concetto, ecco le caratteristiche positive e negative del filesystem del futuro:

Tag:ext3, filesystem, leopard, Linux, Mac os x, ntfs, unix, zfs mac

4 comments

Set 1 2007

Come semplificare l’uso delle espressioni regolari con 4 interessanti servizi web gratuiti

Posted by Antonio Troise

Le espressioni regolari sono una sintassi attraverso la quale si possono rappresentare insiemi di stringhe e sono utilizzate principalmente per la ricerca e la sostituzione di porzioni del testo.
Sebbene fossero state formalizzate già fin dagli anni quaranta, le espressioni regolari entrarono nel mondo informatico per la prima volta alla fine degli anni sessanta, in ambiente Unix, con il famoso “global regular expression print”: grep.
Le espressioni regolari non ebbero grande diffusione ed utilizzo fino agli anni ottanta, quando fu inventato il linguaggio di programmazione Perl che permetteva nativamente l’uso di espressioni regolari.

La sintassi di base delle espressioni regolari in UNIX è stata ora definita obsoleta dal POSIX, ma è comunque molto usata a causa della sua diffusione. La maggior parte dei programmi che utilizzano le regexp, come grep e sed, usano il vecchio sistema.
Chi ha avuto qualche esperienza con le regexp, sa che la sintassi non è delle più semplici e mnemoniche. Per venire incontro a coloro che hanno a che fare con le espressioni regolari, ho pensato di raccogliere alcuni dei migliori servizi web gratuiti per la gestione della sintassi regexp.

Il migliore, secondo me, è RegexPal che ha da poco introdotto la gestione “on the fly” dei colori in base al match delle regexp.

Tag:grep, regexp, regular-expression, sed, unix

2 comments

Giu 15 2007

Mac OS X 10.5 Leopard sarà una vera e propria distribuzione Unix

Posted by Antonio Troise

Mac OS X è UNIX Che il sistema operativo Mac OS della Apple si basasse sul core di BSD (a partire da Mac OS X) era ben noto da tempo: infatti già Tiger aveva una shell unix, la sua bella ksh, e poteva far girare molti programmi compilati per linux. La novità più interessante, però, è che con la versione 10.5 diverrà a tutti gli effetti una vera e propria distribuzione unix, ma a differenza di quelle linux, non sarà a codice aperto. Anche se quest’ultimo aspetto non è da sottovalutare, il fatto, però, di avere tutti i requisiti per chiedere la certificazione “Open Brand UNIX 03 Registered Product”, significa che siamo di fronte ad una vera e propria rivoluzione.

Infatti, sembra che il grande lavoro fatto per Leopard sia stato da subito incentrato allo scopo di rispettare le specifiche SUSv3 e POSIX 1003.1 per le API C, le utility della shell, e i thread.

Quindi, sotto la sua interfaccia grafica accattivante, la semplicità, potenza e sicurezza di Mac OS X 10.5 Leopard deriva direttamente dalla sua solida base Unix!

Infine, nell’implementare tale nuovo pacchetto tecnologico, Apple ha varato Terminal 2, il nuovo terminale che, un’interfaccia rinnovata, permetterà di accedere ai programmi base Unix (senza dimenticare i comandi specifici di Darwin) e l’apertura di sessioni in tab (come nei browser).

[via boliboop]