Carlo Minucci a.k.a. Gecco

Da circa 3 anni sto usando e sviluppando a velocità bradipo un gestionale per tenere traccia degli interventi e delle riparazioni nei vari laboratori di computer che gestisco. Svariate volte mi è capitato che mi fosse segnalato un guasto che non potevo sistemare subito per un motivo o per un altro e io, viste le mie ristrette capacità mentali, spesso me ne dimenticavo o, ancora peggio, me lo scrivevo su un foglio di carta. Non sia mai che nel 2012 sia ancora costretto a scrivere su un foglio di carta.

Per questo motivo ho creato Gestiolus.

Esistono altri sistemi già pronti per la gestione dei ticket o cose simili, di prodotti ce ne sono tipo migliaia, ma li ho sempre trovati macchinosi e non immediati. Certo erano adatti comunque alle mie esigenze ma non mi soddisfacevano appieno.

Volevo un prodotto semplice e immediato, che facesse solo quello di cui ho bisogno, e poco più. Mi serviva anche avere un form scollegato dal sistema che potesse essere usato da tutti per segnalare l’intervento (in realtà questa funzione non l’ho ancora implementata).

All’indirizzo http://minucci.net/gestiolus-demo/ si può provare una demo funzionante.

Con Gestiolus è possibile aggiungere e rimuovere i laboratori o le aule su cui intervenire e tenere traccia di chi ha effettuato l’intervento. Alla fine è possibile generare dei report sul numero di interventi chiusi da un determinato nominativo.

E’ scritto in php e mysql, con qualche puntina di javascript, e potete scaricarlo da qua: http://code.google.com/p/gestiolus/

Occhio che c’è anche il git da cui prendere la versione più aggiornata.

ho a disposizione una macchina fotografica nikon D40 e, nei ritagli di tempo, ho provato a fare un video in timelapse. il risultato è questo:

per fare tutto quanto ho usato linux, debian, in questo modo:

innanzitutto dovete installare il pacchetto gphoto2, poi dovete impostare la macchina fotografica in modalità PTP, se rimane come usb mass storage non funziona. questo passaggio è fondamentale perchè io ci ho perso una buona mezzora a capire cosa non funzionasse

a questo punto, per fare le foto, bisogna dare questo comando:

gphoto2 –capture-image-and-download –interval 20

il cui funzionamento è talmente semplice che quasi mi vergogno a descriverlo. praticamente fa una foto ogni 20 secondi e poi la scarica sul computer, dandogli automaticamente un nome al file in progressione.

dopodichè ho ridimensionato le foto, perchè c’ha la risoluzione a manetta, per farlo ho prima installato il pacchetto imagemagick e dato questo comando:

mogrify -resize 1920×1080 *.jpg

che serve a ridimensionare tutte le foto a quella dimensione, ho usato questa risoluzione perchè è in fullhd

a questo punto bisogna unire tutte le foto in un filmato avi e per farlo ho usato mencoder, quindi ho installato il pacchetto di mencoder e, dato che c’ero, anche mplayer. per unire le foto in un unico filmato ho usato questo comando:

mencoder “mf://*.jpg” -mf type=jpg:fps=3 -ovc lavc -o video.avi

e il gioco è fatto anche se l’avi risultante, almeno su questo computer dell’anteguerra, non mi sembra in full hd. devo provarlo sulla tv di casa

siccome non nasco imparato nemmeno io mi va di citare le fonti da cui ho preso informazioni: qui, qui e qui.

RockEat aveva smesso di funzionare ma il team si è messo subito all’opera per trovare la soluzione fondendo insieme le menti. Con un brainstorming e un briefing via mail, e appontando un planning, si è arrivati a trovare nuovamente la soluzione.

In pratica hanno cambiato la PAROLASEGRETISSIMA, di cui parlavo anche nel post precedente a riguardo, con una nuova, che manterrò comunque segreta perchè mi piace l’idea di far parte di una elite di persone che ne sono al corrente.

Oltre ad aver cambiato la PAROLASEGRETISSIMA hanno aggiunto un header http per il referer, ovvero l’url da cui sei arrivato a una determinata pagina, il cui valore è l’url stesso del player flash. Se vi mettete a sbirciare dentro l’html è facile notare che il player flash è cambiato e ora è player3.swf.

Detto questo il resto è rimasto inalterato, bisogna sempre calcolarsi l’md5 dall’url del file con la PAROLASEGRETISSIMA in fondo.

Per fare il bullo ho voluto provare a fare uno script in bash su una sola riga per automatizzare lo scaricamento dei file, eccolo:

wget -O /tmp/site.html http://www.rockit.it/rivera/album/novembre-2011/19214 ; cat /tmp/site.html | grep “id_” | sed ‘s/id_/\n/g’ | sed ‘s/”><ul>/\n/g’ | awk ‘NR%2==0′ | awk -F”_” ‘{print “echo -n \”http://ww2.rockit.it/7mp3/” $2 “/” $1 “.mp3-PAROLASEGRETISSIMA\” | md5sum “}’ > /tmp/url.tmp ; sh /tmp/url.tmp | cut -f1 -d’ ‘ > /tmp/url.md5 ; cat /tmp/url.tmp | awk -F”\”" ‘{print $2}’ | awk -F”-” ‘{print $1}’ > /tmp/tmp.url ; paste -d ” ” /tmp/url.md5 /tmp/tmp.url > /tmp/url.tmp ; sed ‘s/\ /” /g’ /tmp/url.tmp | sed ‘s/^/wget –referer=http:\/\/www.rockit.it\/web\/js\/player3.swf –post-data rockitID=/’ /tmp/url.tmp > /tmp/wget.tmp ; sh /tmp/wget.tmp

Ovviamente dovete cambiare l’url dell’album. Funziona solo su Linux (su osx non so) e i file mp3 non li salva coi nomi corrispondenti ma va bene uguale, si presume che l’id3 tag dell’mp3 sia apposto.

Presto ci saranno in vendita le magliette di RockEat.

Un bel giorno la rete qua impazzì. I ping andavano a caso, i pacchetti si duplicavano, non arrivavano a destinazione, robe così. Un gran putiferio. Alla fine, dopo mille prove, siamo arrivati a dare la colpa ad un vecchio router 3com che usavamo come access point. Tolto questo affare dalla rete e tutto è tornato a funzionare regolarmente.

Questo affare poi è stato riposto in un armadio tra la roba non funzionante. A me dispiace vedere questi aggegi dimenticati e, visto che sono un fanatico di OpenWrt, ho provato a mettercelo visto che, nel sito, c’era la procedura per il modello 3CRWER100-75. In realtà io avevo un 3CRWER200-75, non so cosa cambi esattamente, so solo che la procedura ha funzionato regolarmente. Ed ecco quello che ho fatto io.

Innanzitutto tenetevi aprire la pagina apposita sul wiki, scaricatevi il kernel e il root fs, poi dovete installarvi un server tftp, io ho usato tftpd-hpa e ho installato anche putty. Di solito putty lo usavo su windows, ma ho scoperto che esiste anche per Linux. Putty serve semplicemente come terminale telnet, non ho usato il normale telnet già compreso in linux per motivi che spiegherò più avanti.

A questo punto dovete resettare il router per riportarlo alle impostazioni di fabbrica. Per fare questo basta tenere premuto il solito bottoncino e poi gli si da corrente e lo si tiene premuto per circa 10 secondi. Non so perchè ma l’ho dovuto rifare 3 volte.

Adesso il router torna all’impostazione di default e ha l’indirizzo 192.168.1.1, un ping ve lo confermerà, sempre che non abbiate in rete già un altro dispositivo con lo stesso indirizzo.

Ora non dovete fare altro che spegnere e riaccendere il router e lanciare il telnet sulla porta 9000 in un lasso di tempo indefinito in cui redboot ascolta su quella porta e vi da accesso al prompt. Facendolo a mano richiede culo e tempismo, roba che ci becchi tipo 1 volta su 10. Appena avuto accesso bisogna premere CTRL+C. Ed è proprio qua l’inceppo, pare che il telnet non riesco a mandare CTRL+C al prompt per qualche strambo motivo di tabella di caratteri o roba del genere, c’è in giro anche un hack usando netcat ma ho provato e non ha funzionato.

Ed ecco la mia elegante soluzione:

Innanzitto lanciate putty e configuratelo come in questa schermata

In pratica dovete settargli l’indirizzo ip, 192.168.1.1, la porta 9000, dirgli di usare il protocollo telnet e infine salvate la sessione. Io l’ho chiamato telnet9000.

A questo punto aprite il terminale e scrivete questo barbatrucco:

arping -f 192.168.1.1; putty -load telnet9000

Questo fa in modo che appena arping si accorge che l’ho desiderato, l’192.168.1.1, diventa attivo, lancia putty caricandogli, -load telnet9000, la sessione che abbiamo salvato prima: il succo del discorso è che fa il telnet sulla porta 9000 al momento giusto.

A questo punto dovreste avere una schermata di questo tipo:

ovvero siete arrivati al prompt di RedBoot, che è quello che ci interessa.

Ora, pre trasferire l’immagine del kernel e del rootfs, abbiamo bisogno di un server tftp da cui attigente.

Installate, come me, tftpd-hda, non perchè sia meglio di altri ma solo perchè sono riuscito a farlo funzionare alla svelta. Quindi

sudo apt-get install tftpd-hpa

(sudo perchè tanto lo so che usate tutti Ubuntu) poi create una directory per la root del server tftp, io per comodità l’ho creata nella root del file system, quindi /tftpboot, e gli date tutti i permessi del mondo di lettura e scrittura, sennò poi non il client non è contento.

Poi editate il file /etc/default/tftpd-hpa e fatelo diventare più o meno come questo:

# /etc/default/tftpd-hpa

TFTP_USERNAME=”tftp”
#TFTP_DIRECTORY=”/var/lib/tftpboot”
TFTP_DIRECTORY=”/tftpboot”
TFTP_ADDRESS=”192.168.1.101:69″
#TFTP_OPTIONS=”–secure”

L’indirizzo ip 192.168.1.101 non è casuale. Se tornate a putty e al prompt di RedBoot e scrivete

fsconfig -l

vi apparirà una roba tipo questa:

Praticamente RedBoot viene già di default con delle impostazioni sue: l’ip, il gateway e le altre robe. A noi interessa la riga:

Default server IP address: 192.168.1.101

che, praticamente, vuol dire che lui si aspetta che il server tftp sia su quell’indirizzo. Ora noi potremo andarci a leggere la documentazione di redboot e di fsconfig perchè un modo per cambiare quella voce c’è sicuramente, ma chi ce lo fa fare? Basta cambiare l’indirizzo ip della propria macchina che è molto più semplice Da qui spiegato il motivo del file di configurazione tftpd-hpa.

A questo punto siamo già un pezzo avanti e possiamo seguire pedissequamente la guida di OpenWrt. Quindi:

fis init

e premete y, poi, al prompt, scrivete:

load -r -b %{FREEMEMLO} /tftproot/openwrt-atheros-vmlinux.lzma
fis create -r 0×80041000 -e 0×80041000 vmlinux.bin.l7
load -r -b %{FREEMEMLO} /tftproot/openwrt-atheros-root.squashfs
fis free
fis create -l 0x2E0000 rootfs
fis list
reset

i due comando load hanno bisogno comunque del percorso assoluto, mistero, altrimenti se la prende a male e non trova il file. Se load ritorna errori di lettura vuol dire che non avete dati abbastanza permessi alla directory /tftproot, provate anche a dargli un chown -R nobody eventualmente.

Dopo il reset il router si riavvia e farà il boot con OpenWrt. Attenzione che il boot sarà un po’ più lento rispetto al firmware originale.

Per accedere telnettate l’192.168.1.1 e avrete accesso al prompt di OpenWrt, leggete le robe scritte, settando la password, con passwd, si imposta la password e si attiva automaticamente il server ssh.

Ora avete un router con OpenWrt e potete farci un po’ quello che vi pare

su rockit.it, sappiamo più o meno tutti, spesso mettono dei dischi da ascoltare in streaming, spesso in anteprima rispetto all’uscita del disco. questa è cosa buona e giusta, ma ho scoperto un modo per scaricarsi i file mp3 così da poterseli metterli anche nell’ipod, senza dover ascoltare quel determinato album in streaming.

trovare i file è semplice, prendendo come esempio l’album Legna dei Gazebo Penguins (che è comunque disponibile scaricarsi dal loro sito ufficiale), diamo un occhio al codice html.

il trucco sta nel trovare la stringa passata al lettore flash, esattamente questa riga javascript qua:

var so = new SWFObject(‘/mediaplayer/mp3player.swf?file=%2Fmediaplayer%2Frockit_pl.php%3Fx%3Da16253′,’mpl’,’240′,’22′,’9′);

come è facilmente intuibile il valore di file è un url encondato con i corrispondeti valori ascii per le slash, per il punto interrogativo e per l’uguale.

%2F corrisponde a /

%3F corrisponde a ?

%3D corrisponde a =

detto questo basta convertire quell’url e come risultato abbiamo:

/mediaplayer/rockit_pl.php?x=a16253

da qua è facile, abbiamo lo script rockit_pl.php che, probabilmente, richiamare dal database l’id col valore 16253 e poi ne genera un file xml formattato in maniera opportuna da passare al player in flash. la x è un nome di variabile che viene passata allo script in php, mentre la a prima del numero ignoro cosa sia ma, in fondo, non ci interessa.

aggiungendo prima dell’url il soffisso del dominio di rockit, ci viene restituito un comodo file xml e, aprendolo con un editor di testo qualsiasi, vediamo che sono disponibili tutti i link ai file mp3 e, quindi, disponibili al download.

il formato dei file magari è scomodo perchè, scaricandoli a mano, avremo tanti file chiamati play.mp3, ma questo ci interessa a poco.

salta subito all’occhio, almeno a me, che il numeretto passato allo script php è uguale a quello che compare nell’url della pagina con lo streaming, quindi basta prendere il numeretto da qualsiasi altra pagina con lo streaming, sostituirlo, e otteniamo il file xml.

ora capisco che tutto questo giro di roba è scomodo e complicato quindi ho preparato questo semplice script in bash, quindi funzionante solo con linux (o al massimo anche con macosx ma ha bisogno di wget che bisogna installare tramite i macports). ecco il codice:

echo "wget -O /tmp/xml.tmp http://www.rockit.it/mediaplayer/rockit_pl.php?x=" | tr 'n' 'a' > /tmp/rockit.xml && echo "http://www.rockit.it/album/16253/gazebo-penguins-legna" | cut -d "/" -f 5 >> /tmp/rockit.xml ; sh /tmp/rockit.xml ; cat /tmp/xml.tmp | egrep 'title>[0-9]|url' | sed 's/ /_/g' | sed "s/'//g" | sed 's/<title>/wget -O /' | sed 's/</title>/.mp3/' | sed 's/n//' | sed 's/" />//' | sed 's/<media:content_url="/"/' | sed 's/"_/>/";/' | tr 'n' ' ' > /tmp/download.mp3 ; sh /tmp/download.mp3

è tutto in una riga solo perchè volevo provare a fare il bullo ma non ci sono riuscito del tutto.

questo script ha bisogno dell’url della pagina dello streaming da cui estrapola il file xml, parsa gli url, e salva gli mp3 col nome giusto nella directory in cui si lancia lo script.

avrei voluto farlo in php per renderlo più agevole ma tutti i miei host non permettono la fopen() al di fuori dell’host per cui non so come aprire il file xml. poi con uno script in bash lo lancio e posso dimenticarmi che sta runnando fino alla fine del download.

tutto qua

update: l’aggiornamento lo trovate qua

Uso Google Chrome sempre con più piacere. Oramai, quasi, uso solamente le webapp disponibili nel Google Web Store, in cui c’è disponibile più o meno tutto di quello di cui ho bisogno, ma sentivo una grossa mancanza: un terminale ssh per connettermi da remoto ai miei server.

Dentro il webstore proprio non c’è una webapp del genere quindi, seguendo il motto chi fa da se fa per tre, me la sono fatta da solo.

E’ disponibile da qui.

Per farlo ho usato un terminale ssh scritto in java e rilasciato sotto GPL: jcterm.

L’icona l’ho presa su openclipart.

UPDATE: c’è anche un mio precedente articolo che illustra, per sommi capi, come fare una webapp: qui

sono appena tornato dal cinema dove ho visto habemus papam di nanni moretti. bello, brutto, si, no, non sa/non risponde… oltre al fenomeno dei seminaristi al cinema, non mi era mai capitato, oltre all’oramai andato moretti dei tempi d’oro (sempre comunque meglio rispetto alla stanza del figlio), oltre al ritratto dell’umanità del papa, oltre al punto dell’oceania, oltre ai canoni morettiani maturi, oltre alla coca cola annacquata… vorrei soffermarmi su un altro argomento scottante…

vorrei soffermarmi sul fattore religioso della cosa, ma da un altro punto di vista: i testimoni di geova.

l’opera del testimone di geova differisce poco dal tizio che tenta di venderti il folletto. quello che vuole fare il testimone di geova, in pratica, è convertirti. il che può dar fastidio come concetto, ma questo non vuol dire che debbano usare un processo di conversione fastidioso.

se io, ipoteticamente testimone di geova, voglio convertire un cristiano o un ateo, non gli vado a suonare a casa la domenica mattina per due semplici motivi: 1) se sono ateo, la domenica mattina sono solito dormire fino a tardi quindi disturbi, anche se sono sveglio; 2) se sono cristiano la domenica mattina sono a messa quindi citofoni inutilmente.

potremo anche tirare in causa il risparmio energetico: milioni di campanelli suonati inutilmente la domenica mattina, altro che lo stand by delle tv.

io d’altronde non ho mai citofonato a casa di sconosciuti dicendo “oh, se vuoi ti installo linux gratuitamente”.

ognuno è libero di diffondere le proprie idee: le scie chimiche, elvis vive, l’autopsia aliena, la torre di guarda, quello che volete… ma c’è modo e modo

quest’oggi vi parlerò di come bloccare facebook in una rete dietro smoothwall.

smoothwall è una distro linux che fa sia da firewall che da proxy. se vuoi aggiungete il dominio facebook.com ai domini da bloccare, il filtro è facilmente aggirabile mettendo all’inizio dell’url https invece del normale http. questo succede perchè il proxy non riesce a leggere gli url https, visto che sono criptati. l’unica soluzione che ho trovato è intervenire sulle voci dns: ovvero far corrispondere a facebook.com un altro indirizzo ip, nel mio caso l’ip della pagina della intranet interna.

ovviamente dovrete, in questo caso, fa funzionare smoothwall anche come server dns e impostare in tutti i client l’ip di smoothwall come dns. o in alternativa aggiungere a smoothwall una regola di iptables che richiama a se tutte le richieste dns.

e fino a qua ok, ma come automatizzare il processo ipotizzando che, per esempio, voglia bloccare facebook solo il mattino?

basta un semplice script messo nel crontab. la documentazione di smoothwall a riguardo non ne ho trovata, per cui ho dovuto fare un po’ di reverse e il risultato è questo:

#!/bin/bash

cp /var/smoothwall/urlfilter/blacklists/custom/blocked/domains.mattino /var/smoothwall/urlfilter/blacklists/custom/blocked/domains

killall -HUP squid

cp -f /var/smoothwall/hosts/config.facebook /var/smoothwall/hosts/config

cp -f /var/smoothwall/hosts/hosts.facebook /var/smoothwall/hosts/hosts

killall -HUP dnsmasq

e:

#!/bin/bash

cp /var/smoothwall/urlfilter/blacklists/custom/blocked/domains.pomeriggio /var/smoothwall/urlfilter/blacklists/custom/blocked/domains

killall -HUP squid

cp -f /var/smoothwall/hosts/config.normale /var/smoothwall/hosts/config

cp -f /var/smoothwall/hosts/hosts.normale /var/smoothwall/hosts/hosts

killall -HUP dnsmasq

il file config.facebook ha questa formattazione qua:

192.168.1.3,server,on,

192.168.1.3,facebook.com,on,

mentre dentro hosts.facebook

127.0.0.1 localhost

192.168.1.3 facebook.com

192.168.1.3 www www.facebook.com

basta fare due script, creare i file appositi nelle due dir, e aggiungere gli script al crontab.

e il gioco è fatto

sapete tutti del mio server pdc fatto con debian e samba che, tra l’altro, vavavuma.

sapete anche che sono un po’ pigro e, mentre configuravo il tutto, non ho avuto voglia di implementare ldap, il coso centralizzato per gestire gli utenti in maniera più performante e rapida.

tant’è che, per funzionare, samba ha bisogno che ci sia un determinato utente sia come utente linux che come utente samba (ldap viene usato per evitare questo, a cui possono attacarsi una marea di altre cose) e quindi, ogni volta che si aggiunge un utente bisogna aggiungerlo a mano su linux e su samba, con due comandi diversi: per un totale di 4, dico 4, inserimento di password (perchè come è noto tu inserisci la password e te la richiede per conferma). se è solo un utente va bene, ma quando devi immettere in maniera seriale, per dire, decine di utente comincia a essere un po’ una rottura, per cui ho fatto questo comodo script:

#!/bin/bash

while :

do

clear

echo “[Menu]”

echo “[n] nuovo utente”

echo “[c] nuovo utente per classe”

echo “[e] esci”

read scelta

clear

if [ "$scelta" == 'n' ]; then

echo “Username:”

read username

echo “Password:”

read password

useradd -d /dev/null -s /dev/null -p $password $username

echo -ne “$passwordn$passwordn” | smbpasswd -a -s $username

echo “Classe:”

read classe

mkdir /home/dati/studenti/$classe

mkdir /home/dati/studenti/$classe/$username

chown $username /home/dati/studenti/$classe/$username

chgrp $username /home/dati/studenti/$classe/$username

chmod 700 /home/dati/studenti/$classe/$username

elif [ "$scelta" == 'c' ]; then

echo “Username:”

read username

echo “Password:”

read password

useradd -d /dev/null -s /dev/null -p $password $username

echo -ne “$passwordn$passwordn” | smbpasswd -a -s $username

mkdir /home/dati/studenti/$username

chown $username /home/dati/studenti/$username

chgrp $username /home/dati/studenti/$username

chmod 700 /home/dati/studenti/$username

elif [ "$scelta" == 'e' ]; then

exit

fi

done

ovviamente è valido solo per il mio sistema visti i percorsi delle home degli utenti

ora la cosa da notare è la creazione dell’utente del sistema il quale richiede, ad useradd il passaggio della password già cryptata. ecco, sono stato una mattina intera a cercare di capire come venisse cryptata, ho trovato anche il comando per cryptarla usando l’hash giusto ma, rimane ancora un mistero, non ho capito come mai non corrispondesse a quella dentro /etc/shadow ma ho notato, per puro caso, che l’importante è che venga impostata nella maniera giusta quando si aggiunge l’utente a samba.

visto che comunque poi gli utenti di sistema non hanno la home e la shell impostata su /dev/null ho detto “chissenefrega, m’interessa solo di samba”

un altro “problema” è che la password, quando la inserisci, viene comunque visualizzata sul monitor e non ci sono gli asterischi, e anche in questo caso “chissenefrega”. anzi, è una feature visto che hai il riscontro visivo di averla inserita in maniera corretta, invece di doverla inserirla una seconda volta per conferma

quindi questo script funziona ma non in maniera impeccabile, diciamo che è un hack

avevo bisogno di un modo per trovare tutti gli ip attivi (ovvero i computer accesi) nella mia lan, così giusto per sapere quali sono i computer che lasciano accesi alla fine della giornata, ma anche durante.

vabbè, non è che ne avessi proprio bisogno assolutamente, ma giusto per poter dire che posso farlo.

cercando su internet ho trovato due possibilità: o usare il paccheto arp-scan, oppure nmap

la sintassi di arp-scan è semplice, tipo basta arp-scan -l, ma per rifinire meglio l’output ho fatto così:

arp-scan -l | grep 192 | awk {‘print $1′}

mentre per nmap:

nmap -sP 192.168.1.0/24 | grep “to be up” | awk {‘print $2′}

il risultato è praticamente identico solo che nmap è molto più accurato e mi printa anche degli host che per arp-scan non esistono (sono degli access point configurati come bridge per i ponti radio, quindi forse è quello il problema)

e ora vediamo i test di performance a confronto:

time arp-scan -l | grep 192 | awk {‘print $1′} | wc -l

26
real    0m1.659s

e con nmap:

time nmap -sP 192.168.1.0/24 | grep “to be up” | awk {‘print $2′} | wc -l

32
real    0m27.390s

come si può evincere nmap è più lento ma riconosce praticamente tutti gli host attivi.

a me la velocità non è che interessi granchè, visto che comunque lancio lo script dal crontab ogni 10 minuti. sacrifico un po’ di tempo per avere risultati più completi.