1. Ctrl-Alt-Backspace

Questa è abbastanza facile, dato che a partire dalle Release Notes di ubuntu 10.04 si trova la guida per abilitare questo indispensabile comando. Per chi non è familiare con Ctrl-Alt-Backspace, è un comando che consente di forzare il riavvio del gdm (Gnome Display Manager) o detto ancora più semplicemente, il livello software che si occupa di creare il front end grafico: icone, finestre, sfondo… che di solito è l’unica fonte di crash e blocchi del pc.

1. Selezionare “Sistema” => “Preferenze” => “Tastiera”
2. Aprire il tab “Disposizioni”
3. Cliccare su “Opzioni”
4. Espandere “Sequenza di tasti per attivare il server X”
5. Spuntare “Control + Alt + Backspace”

2. Tenere sott’occhio l’output del kernel

Quando si ha a che fare con dell’hardware nuovo o magari mal supportato o ancora difettoso, può essere molto utile osservare lo standard output del kernel per vedere quali messaggi di errore vengono visualizzati.

E’ inoltre molto comodo avere una finestra sempre aperta ed aggiornata che segua continuamente i messaggi in modo da poter vedere… matrix che lavora!

Per fare questo mi sono creato un lanciatore (icona) sul desktop nel seguente modo:

1. Click con il destro sul desktop => “Crea lanciatore…”
2. Tipo: “Applicazione nel terminale”
3. Nome: “Dmesg watch”
4. Comando:

gksudo watch "dmesg | tail -20"

Creata l’icona, mi basta cliccarci sopra per tenere continuamente sott’occhio il kernel comodamente sul desktop. Ah, il programma chiede di inserire la password di root perchè deve essere eseguito dall’amministratore del sistema.

Se avete altri tips & tricks da suggerire, scriveteli nei commenti, io li inserirò nell’articolo.

A prescindere dal fatto che è scomodo dover, tutte le volte che si accende il computer, ripristinare il “muto” della propria scheda; esistono anche dei casi in cui non è possibile aprire l’applicazione con il mouse, dal desktop di gnome.

E’ infatti il caso in cui un cretino (a caso), dopo aver passato ore a settare il proprio media center basato su linux e xbmc, sdraiato sul divano, fa partire dal suo telecomando la visione di un film e non sente un bel niente.

Non ci sono versi, il cretino le prova tutte: abbassa ed alza il volume, mette e toglie il muto, riavvia xbmc, riavvia il computer… niente, la scheda audio è e rimane sempre in muto.

Allora sono passato alle maniere forti: prendo il portatile, accedo in ssh al media center ed apro “alsamixer”, tolgo il muto dalle periferiche e riprovo… niente, è ancora in muto. Perchè?

Mi tocca attaccare il mouse e la tastiera al media center, esco dalla sessione con xbmc e accedo a gnome. Levo la spunta da “muto” nel pannello e… magia, l’audio torna perfettamente funzionante. Se però contemporaneamente smanetto su alsamixer, quando metto in muto con gnome-volume-control non riesco più a ripristinarlo. Perchè?

Dopo tante domande, finalmente sono giunto ad una risposta.

Infatti ho scoperto che quando gnome-volume-control imposta il “muto”, agisce su 3 diversi canali: Master, Headphone e Speaker.

Per questo motivo, anche levando il muto solo da Master o Speaker, il simbolo di muto non va via da gnome  e l’audio non torna a funzionare.

Il motivo per cui però, il programma tende sempre a resettare lo stato della scheda audio mi è tutt’ora ignoto.

Comunque, per risolvere basta dare questi tre comandi da una console:

amixer -- set Master unmute
amixer -- set Headphone unmute
amixer -- set Speaker unmute

Volendo, per essere sicuri che tutto vada per il meglio, si può anche forzare amixer di settare i volumi al 100%:

amixer -- set Master playback 100% unmute
amixer -- set Headphone playback 100% unmute
amixer -- set Speaker playback 100% unmute

Per essere sicuro di non scordarmi nulla e di non dover più agire manualmente, la mia soluzione preferita è, come al solito, crearmi uno script… anzi due: uno per mettere in muto ed uno per levare il muto. E già che ci sono (a morte l’avarizia!) lo faccio anche colorato!
Ah, per risolvere il mio problemino in xbmc mi basta a questo punto far eseguire lo script ad ogni avvio del programma.

#!bin/sh

amixer -- set Master mute
amixer -- set Headphone mute
amixer -- set Speaker mute

echo "Master	 	\033[31;5;148m[MUTO]"
tput sgr0
echo "Headphone 	\033[31;5;148m[MUTO]"
tput sgr0
echo "Speaker		\033[31;5;148m[MUTO]"
tput sgr0

#!bin/sh

amixer -- set Master speaker 100% unmute
amixer -- set Headphone speaker 100% unmute
amixer -- set Speaker speaker 100% unmute

echo "Master	 	\033[38;5;148m[NON-MUTO]"
tput sgr0
echo "Headphone 	\033[38;5;148m[NON-MUTO]"
tput sgr0
echo "Speaker		\033[38;5;148m[NON-MUTO]"
tput sgr0

Edit 26/11/2009: ho corretto un errore negli script.

playback 100%

Che la bash (o console) sia un luogo magico, terra fertile per il proliferare di nerd, geek e folletti… beh è cosa risaputa (con mastercard).

Che esse-esse-acc-arsi * su di un server remoto per salvare files importantissimi sia una emozione unica… beh anche questo è cosa risaputa (con mastercard).

Ma controllare che ogni giorno, ogni ora, il proprio script si occupi in maniera veloce e leggera di fare i backup… non ha prezzo!

(*) ovvero aprire una shell sicura ** su di una macchina remota con ssh

(**) no, non è una pratica sessuale

Ok, veniamo al succo: due server. Uno principale su cui gli utenti salvano i loro files (magari attraverso samba) ed uno secondario, di backup, che è il clone del primo. Lo scopo è semplice, se il primo server salta, il secondo lo può sostituire all’istante. In più sul secondo server si possono eseguire operazioni di backup o altro, senza occupare risorse del primo, che così rimane tutto a disposizione degli utenti.

Per fare questo abbiamo bisogno di 4 cose:

1. uno script che sicronizzi i due server (rsync)
2. una sessione autenticata in ssh che permetta la sincronizzazione in maniera automatica
3. l’esecuzione automatica ad un orario prestabilito dello script
4. uno script che faccia i backup (anch’esso ad orari prestabiliti)

Cominciamo dal primo server (quello principale) che chiameremo server1.

Punto 1: Rsync

Il comando rsync è molto utile poichè permette la sincronizzazione di due directory tramite il confronto dei files e la copia esclusivamente dei cambiamenti tra le due cartelle. In pratica è come eseguire un scp (secure copy) tra due cartelle, ma con un notevole risparmio di banda dato che solo le modifiche vengono trasmesse (trasferimento incrementale).

rsync --delete -azv -e ssh [dir1] [dir2]

Dove naturalmente [dir1] e [dir2] sono le due cartelle da tenere “clonate”, con “–delete” vengono anche eliminati i files che sono stati cancellati dalla [dir1] e con “ssh” gli diciamo di utilizzare una sessione in ssh… appunto.

Per specificare che la [dir2] è remota si usa la sintassi:

utente@macchina:cartella

Bene, vediamo adesso lo script nel suo insieme:

#!/bin/sh

#Author: fry@nerdsopolis.net
#Description: Backup tramite rsync.

#Variabili
LOCAL=/srv/samba/pub
REMOTE=/srv/samba/backup
HOST=192.168.1.100
LOG=/srv/samba/backup.log
SYNCLOG=/srv/samba/backup.synclog

#Inizio log
echo $(date +"%d/%m/%Y") | cat >> $LOG
echo $(date +"%H:%M.%S") backup started... | cat >> $LOG

#Rsync
rsync --delete -azv -e ssh $LOCAL root@$HOST:$REMOTE | cat > $SYNCLOG

#Fine log
echo $(date +"%H:%M.%S") backup ended! | cat >> $LOG

Come si può vedere non ho fatto altro che specificare un po’ di variabili ed aggiungere un file di log che ci permette di fare del debug sull’esecuzione di rsync.

La cartella locale è /srv/samba/pub e quella remota è /srv/samba/backup sul server2 che ha indirizzo 192.168.1.100.

NB: lo script utilizza l’utente root su entrambi i server. Naturalmente tale opzione è sconsigliabile ma per il momento semplifica le cose!

Mettiamo lo script (che io ho chiamato semplicemente rsync_backup.sh) nella cartella

/usr/local/bin

su server1 e rendiamolo avviabile

chmod u+x /usr/local/bin/rsync_backup.sh

Ora se proviamo ad avviarlo

sh /usr/local/bin/rsync_backup.sh

ci verrà richiesta la password dell’utente root sul server2 (ed anche si accettare la chiave se è la prima volta che ci connettiamo in ssh a quella macchina).

Poichè però il nostro script dovrà essere eseguito automaticamente, non possiamo inserire a mano la password tutte le volte. E, prima che a qualcuno venga in mente, non vogliamo neanche far passare password in chiaro tutte le volte!

Punto 2: SSH senza password

Per automatizzare l’operazione di ssh tra il server1 ed il server2 dobbiamo fare in modo che il server2 si “fidi ciecamente” del server1 senza bisogno di una password. Come? Utilizzando una combinazione di chiavi pubbliche e private.

Senza scendere nel dettaglio mi limiterò a ricordarvi (dato che voi già lo sapete) che posso distribuire liberamente la mia chiave pubblica e tenere al sicuro la mia chiave privata. Grazie alla chiave pubblica chiunque potrà essere sicuro della mia identità fin tanto che deterrò la chiave privata.

Sul server1 generiamo la coppia di chiavi

ssh-keygen -t rsa

lasciando generare le chiavi nella directory predefinita e non inserendo nessuna password quando ci viene chiesto.

Ora andiamo nella cartella .ssh/ nella home del nostro utente, troveremo due files: id_rsa e id_rsa.pub.

Ovvero: id_rsa = chiave privata & id_rsa.pub = chiave pubblica

Inviamo la nostra chiave pubblica al server2

scp id_rsa.pub root@192.168.1.100:/root

ora andiamo sul server2 nella cartella /root dove troviamo il file che abbiamo appena copiato. Adesso controlliamo di avere una cartella che si chiama “.ssh”, se non c’è creiamola. Poi mettiamo la chiave pubblica nel file “autorized_keys” all’interno della directory.

mv id_rsa.pub .ssh/
cat id_rsa.pub >> authorized_keys
chmod 644 authorized_keys

Ok! Adesso qualsiasi accesso in ssh dal server1 al server2 avverrà senza richiesta di password e quindi se proviamo a lanciare nuovamente il nostro script dal server1, la sincronizzazione avverrà senza richiesta di input.

NB. Come detto prima, eseguire queste operazioni con l’utente root è altissimamente sconsigliato!

Punto 3: Crontab

Crontab gestisce tutte le operazioni pianificate sul nostro server. L’utilizzo è semplicissimo:

0 4 * * * /usr/local/bin/rsync_backup.sh

esegue il nostro script alle 4:00 di tutti i giorni.

Per maggiori dettagli su crontab vi rimando a wikipedia.

La stringa che abbiamo visto sopra andrà inserita all’interno della coda di crontab, tramite il comando

crontab -e

si aprirà un editor (se è la prima volta ci chiede anche che editor usare, io consiglio vim) dove scrivere la stringa (in vim per modificare si preme “i”) e dopo averla salvata (premere “:x”) possiamo controllare che sia stata inserita tramite

crontab -l

Punto 4: Backup

Mentre il nostro server1 si becca tutti gli accessi degli utenti, il server2 rimane dormiente tutto il giorno e viene utilizzato solo per qualche minuto verso le 4 di notte, quando riceve gli aggiornamenti.

Possiamo quindi pianificare su server2 in qualsiasi altro momento della giornata dei backup (totali o incrementali) da masterizzare o da copiare su altri dischi.

Ecco lo script che uso io (backup totali tramite tar)

#!/bin/sh

#Author: fry@nerdsopolis.net
#Description: Script per la creazione di backup automatico e rimozione
#             vecchi backup.

#Variabili
LOG=/srv/samba/backup.log
TARLOG=/srv/samba/backup.tarlog
BASE=/srv/samba/backup/
DIR=pub/

#Inizio log
echo $(date +"%d/%m/%Y") | cat >> $LOG
echo $(date +"%H:%M.%S") backup started... | cat >> $LOG

#Creazione del backup
cd $BASE
tar -zcvf $(date +"%y%m%d-%H%M").tar $DIR | cat > $TARLOG

#Eliminazione backup piu' vecchio
first=$(ls | grep tar | sort -n | head -1)
rm $first
echo $(date +"%H:%M.%S") deleted $first | cat >> $LOG

#Fine log
echo $(date +"%H:%M.%S") backup ended! | cat >> $LOG

In questo caso il mio script crea un archivio tar compresso di tutta la cartella /srv/samba/backup/pub e successivamente cancella il backup più vecchio.

Naturalmente questa tecnica ci consente di tenere in memoria (a seconda dello spazio sul disco) tanti backup che sono la “foto” della cartella in un determinato momento. Se ad esempio tengo 10 backup, lo script andrà a crearne uno nuovo e poi a cancellare il più vecchio, lasciandone sempre 10 sul mio disco. Per fare ciò però dovremo ricordarci di fargli fare prima 10 backup commentando per i primi 10 cicli la riga relativa alla cancellazione dei backup più vecchi.

Anche questo script, come il precendete va messo in /usr/local/bin e chmoddato in modo da essere eseguibile.

Ora sempre tramite crontab possiamo fare in modo che lo script sia eseguito una volta alla settimana, la domenica notte:

0 4 * * 0 /usr/local/bin/backup.sh

Fine. Se avete avuto la forza di seguire questo post fino a questa riga, significa che avete realemente bisogno di usare gli script per fare i backup.

Quindi perchè non andate oltre e li personalizzate per fare altre funzioni? Si sa, uno script tira l’altro!

>

Porto grandi notizie!

C’è un torneo che ci aspetta…

Concorso per la realizzazione di micrometraggi a tema libero in ambiente Open Source

Carissimi Nerds è arrivato il nostro momento, il Comune di Modena organizza un concorso per “micrometraggi” realizzati in ambiente Open Source.

Il termine per la consegna è per il 4 ottobre 2009, trovate tutte le informazioni sul sito di netgarage.

PS. dicesi “micrometraggio” un filmato della durata massima di due minuti… sono un po’ pochini!

La "madrina" della prossima festa di nerdsopolis!

Sembra incredibile. Uno passa le sue giornate a glorificare il software libero e poi scopre che proprio quel software funziona meglio con programmi non opensource. Cazzo.

E’ quello che mi è successo tentando di usare un programma di nome Ebox installato su Ubuntu Server 8.10.

Ebox è una interfaccia “browser-based” che permette il monitoraggio e la gestione di un server attraverso una connessione https. Un sitema piuttosto comodo nel caso si abbiano diversi server da tenere sott’occhio e non si abbia voglia di aprire una console ssh tutte le volte.

Peccato che, fin dall’inizio questo casso di ebox mi abbia dato dei problemi.

Leggendo la “Ubuntu Server Guide” sembra tutto facile… ed invece ho scoperto che:

1. Ebox ha dei problemi di installazione sulle repo ufficiali e quindi bisogna aggiungere in apt una repo aggiuntiva (eh vabè…) ricordandosi di mettere “intrepid” e non “hardy” come scritto sul sito ufficiale;
2. Bisogna importare manualmente la chiave della repo (non ho capito perchè..) per evitare un errore GPG;
3. All’avvio il modulo “logs” butta fuori una serie di errori python (e che cazzo);
4. Firefox 3.0 rileva come “untrusted” il certificato emesso dal server (guarda firefox che mi fido del mio server!);
5. Dulcis in fundo la connessione https funziona a singhiozzo con FF 3.0.

Insomma una vera e propria palla. Per un software che viene direttamente consigliato nella guida ufficiale Ubuntu Server non c’è male…

Vabbè, venendo al nocciolo della questione, la cosa che più mi aveva fatto incazzare era proprio l’impossibilità di visualizzare Ebox tramite Firefox ed essere costretto ad usare Iexplorer (dove tutto andava e va a meraviglia).

Fortunatamente ho scoperto come (temporaneamente) risolvere il problema di Connessione sicura fallita.

In primis bisogna creare una eccezione per accettare il certificato rilasciato da Ebox (si accede ad ebox aprendo l’indirizzo https://indirizzo del server/ebox)

1. Cliccare su “Oppure è possibile aggiungere un’eccezione”
2. Aggiungi eccezione…
3. Acquisisci certificato
4. Conferma eccezione di sicurezza

Vi faccio notare l'entità degli errori: Sito errato e Identità sconosciuta!

A questo punto viene visualizzato l’errore qui sotto, oppure la pagina di login senza immagini e grafica. Se provate a ricaricare qualche volta la pagina appariranno a caso o la pagina di errore o la pagina “mal caricata”… bello no?

L’errore visualizzato si riferisce a “ssl_error_rx_unexpected_change_cipher” e a quanto pare riguarda solo Windows XP.

Per risolvere quest’ultimo problema bisogna aprire “Strumenti”, poi “Opzioni…” e quindi “Avanzate”. A questo punto si deve disattivare il protocollo TLS 1.0:

Ora ricaricando nuovamente la pagina dovrebbe (alleluja!) comparire il login di Ebox.

Naturalmente il dump più recente che avevo fatto risaliva al 1980..

L’operazione di spostamento del db è comunque estremamamente facile: tutti i db e le tabelle sono in realtà memorizzati in directory e files.

Ecco come fare:

1. cp -R backup/var/lib/mysql/miodb /var/lib/mysql/
2. cd /var/lib/mysql
3. chown -R mysql.mysql miodb/

Nota bene:

• Il percorso dove mysql mette i propri files potrebbe essere diverso a seconda della distribuzione
• Io ho precedentemente montato il vecchio harddisk nella cartella /backup
• Ho spostato solo la cartella “miodb” e tutto il suo contenuto, attenzione a non spostare i files nella radice principale di mysql perchè potrebbero creare dei conflitti con quelli nuovi.
• Cambiare i permessi SOLO alla cartella che si è copiato. Per motivi di sicurezza le altre cartelle devono rimanere intatte.

Fatto. Ora aprendo phpmyadmin il buon vecchio database è al suo posto sano e salvo!

Server: Ubuntu 8.10 Intrepid Ibex

Disco 1:

Disk /dev/sda: 41.1 GB
Device Boot      Start         End      Blocks     Id  System
/dev/sda1 *        1        4905    39399381   83  Linux
/dev/sda2      4906        4998     747022+   5    Extended
/dev/sda5      4906        4998      746991   82    Linux swap

Disco 2:

Disk /dev/sdb: 80.0 GB
Device Boot      Start         End      Blocks     Id  System
/dev/sdb1            1        5223    41953716    c  W95 FAT32 (LBA)
/dev/sdb2      5224        9729    36194445    c  W95 FAT32 (LBA)

Fstab:

# /dev/sdb1
UUID=4939-5ABE  /srv/samba/pub1     vfat    user,rw,umask=000       0      0
# /dev/sdb2
UUID=4939-5AC1  /srv/samba/pub2     vfat    user,rw,umask=000       0       0

Come si vede, il primo disco è di sistema. Il secondo ha due partizioni che corrispondono a due distinte condivisioni, montate sotto /srv/samba.

Le directory dentro cui montare pub1 e pub2 le ho create usando:

#mkdir -p /srv/samba/pub1
#chown nobody.nogroup /srv/samba/pub1/

Samba:

Ho creato il file smb.conf.master facendo:

#cp smb.conf smb.conf.master

E ho modificato smb.conf.master con vim inserendo i seguenti parametri dentro a [global]:

workgroup = WORKGROUP
server string = %h (Ubuntu 8.10)
security = share
map to guest = bad user
usershare allow guests = yes

Poi ho inserito le cartelle condivise:

[Pub1]
comment = Cartella Pubblica 1
path = /srv/samba/pub1
browseable = yes
guest ok = yes
read only = no
create mask = 0755

Ho salvato il file e poi ho lanciato il comando:

#testparm -s smb.conf.master >smb.conf

(Naturalmente ho riavviato il pc dopo aver creato/modificato le partizioni, aggiornato i mounts e riavviato samba)

Funziona alla grande, senza nessuna pippa di autenticazione da parte Windows.

In merito suggerisco la lettura della guida di Ubuntu Server relativa a Samba.

Dopo giorni di smanettamenti vari con la scheda tv analogica, in questo post vi propongo un piccolo script che mi sono creato per poter registrare e programmare registrazioni dalla tv tramite mencoder. Insomma mi sono creato un piccolo videoregistratore digitale, molto più comodo del caro vecchio VHS! Ma meno figo del betamax…

Introduzione

Prima di tutto premetto che io in questo momento sul mio pc con ubuntu (hardy) per guardare normalmente la tv uso tvtime che è davvero un’ottimo programma. Semplice da usare, con un bel menu OSD e una discreta dose di impostazioni smanettabili. Il limite però è che non registra e non fa nessun tipo di timeshifting! Nel caso voi abbiate (a differenza di me) una scheda tv DVB-T o DVB-S allora vi consiglio di usare Kaffeine. Prima che si rompesse la mia, lo usavo ogni giorno e l’ho trovato veramente completo: EPG, registrazione immediata, programmata e timeshifting tutto in uno. Dato però che Kaffeine non sembra digerire la mia nuova (in realtà vecchia) scheda tv analogica, sono dovuto passare ad altro!

Una soluzione naturalmente da tenere in considerazione è quella di usare MythTV. Per chi ancora (ma dove vivi?!) non lo sapesse MythTV è un programma completissimo che permette di creare un sistema completo per la visione della tv, con registrazione e timeshifting, la visione di divx/xvid, la navigazione su internet e tanto altro. Il tutto con un semplice telecomando. MythTV è sicuramente la soluzione più completa per chi vuole dedicare un pc all’uso specifico come PVR (una sorta di clone del TiVo o un Windows MCE venuto bene), ma nel caso in cui l’uso della tv è sporadico e la registrazione avviene solo in certe occasioni, il programma risulta a mio parere un po’ troppo pesante ed invasivo (mille pacchetti e configurazioni eterne).

Requisiti

Lo script (recorder.sh) in pratica fa due cose: registra immediatamente dalla scheda tv oppure programma una registrazione futura.

I requisiti per poter usare questo script sono abbastanza semplici (per uno che usa la scheda tv sulla propria linux box): mencoder (che fa parte di mplayer ed è un favoloso compressore/decompressore/convertitore) e scantv (che fa parte di xawtv).

Configurazione e uso

Veniamo dunque al sodo.

Scantv è un semplice script che esegue, come si intuisce dal nome, una scansione sulla tabella delle frequenze o su tutte le frequenze alla ricerca dei canali tv e li sintonizza in modo che possano essere usati dal software Xawtv che è invece un (piuttosto bruttino e datato) visualizzatore di tv.

Il primo step è dunque (nel caso non l’abbiate già fatto) creare una tabella dei canali:

$ scantv -C /dev/vbi0 -o /home/francesco/.xawtv

Da notare che io devo usare “-C /dev/vbi0″ perchè di default scantv cerca solo su “/dev/vbi”. E che “/home/francesco” è la MIA home… metteteci la vostra! Ah, se volete una ricerca più completa usate anche il comando “-a”… però abbiate pazienza perchè così ci mette una vita!

Una volta conclusa la ricerca, aprendo il file .xawtv troverete una voce che collega un canale (in alcuni casi con il nome) ad una frequenza o un canale. Il canale non è altro che una frequenza prestabilita su una tabella che varia a seconda del paese. In linea di massima i canali tv sono sempre su un canale preciso. Se trovate la frequenza probabilmente si tratta di un canale locale o di qualcosa con una ricezione veramente pessima!

Ora vi consiglio di editare il file per eliminare i canali inutili e per mettere i nomi a quelli che non l’hanno. Per farlo vi basta usare un normale editor per le modifiche sul file .xawtv e xawtv per vedere il risultato. Ora passiamo alla registrazione!

NB. Purtroppo una limitazione piuttosto grave del sistema è che la scheda tv è accessibile solo da un processo per volta. Ciò significa che, se state guardando un canale (ad es. su tvtime) e fate contemporaneamente partire la registrazione (su un altro canale o anche sullo stesso), l’ultimo processo avviato esclude il precedente. Proprio come con un videoregistratore non possiamo cambiare canale mentre registriamo! E per vedere mentre si registra? Bè basta aprire il file video che il nostro fido recorder.sh sta creando con un player qualsiasi. In questo modo abbiamo anche una sorta di timeshifting dato che possiamo metterlo in pausa, mandarlo indietro o avanti (compatibilmente con la linea temporale!!) e farlo ripartire quando vogliamo mentre recorder.sh continua a salvare il flusso video.

L’uso dello script è piuttosto semplice:

$ ./recorder.sh [channel] [seconds] [options] [start]

Dove “channel” è il canale che trovate nel file che abbiamo creato prima (.xawtv), “seconds” sono i secondi della durata della registrazione, “start” è l’ora in HH:MM di inizio della registrazione. Come opzioni è possibile specificare “-f” per aprire immediatamente il file in corso di registrazione in mplayer, “-p” per programmare una registrazione futura (in tal caso è obbligatorio specificare anche “start”). Nel caso in cui “-p” non sia specificato la registrazione parte immediatamente, altrimenti crea una voce “cron” tramite il comando “at” che verrà eseguita nel momento prestabilito. Ad esempio:

$ recorder.sh 56 3600 -p 12:50

Metterà in coda una registrazione per le 12:50 sul canale 56 (che da me è Canale 5) della durata di 3600 secondi = 1 ora.

Lo script provvederà a creare un file, il cui nome è dato dal canale e dalla data e l’ora di inizio della registrazione, compresso in divx con l’audio in mp3. E il tutto in maniera automatica!

Lo script nel dettaglio

Naturalmente non mi aspetto che lo script funzioni o vi vada bene così com’è. Il mondo di linux, si sa, è bello perchè vario! Quindi a seconda della distro che state usando qualche impostazione potrebbe essere diversa… oppure la vostra scheda di acquisizione potrebbe funzionare in modo diverso… oppure ancora potreste volere aggiungere o togliere delle opzioni che io uso.

Dov’è il problema?! Basta smanettare sul codice!

In primo luogo premetto che alcune parti di questo script le ho fatte ispirandomi ad uno script simile che ho trovato da qualche parte su un forum (scusate ma non trovo più il link). Io però ho migliorato alcuni aspetti della compressione del video ed ho aggiunto una serie di opzioni, come il fatto di poter programmare la registrazione.

E’ molto importante controllare che i riferimenti alla scheda video e a quella audio siano corretti. Nel mio caso l’output video arriva da “/dev/video0″ e il sintonizzatore si trova su “/dev/vbi0″. Può darsi che a seconda della distro o a seconda del modulo usato per la vostra scheda queste devices siano in luoghi diversi. Potete controllare direttamente tramite mplayer se state usando gli indirizzi corretti. Ecco come:

$ mplayer tv:// -tv driver=v4l2:input=1:device=/dev/video0:norm=PAL

Un altro aspetto importante da considerare è l’input usato. Nel mio caso la scheda fornisce 3 input. Il primo (0) è l’ingresso composito, il secondo e il terzo (1 e 2) sono l’ingresso TV. Se selezionate un input sbagliato dovreste vedere nero o vedere del rumore video. Una modifica che probabilmente aggiungerò in futuro al mio script sarà la possibilità di impostare l’input in modo da poter usare la scheda per convertire vecchi vhs in digitale.

La seconda cosa importante da configurare (e che mi ha fatto impazzire) è l’imput audio. Ci sono due tipi di schede tv. Quelle che mandano l’audio direttamente su una periferica digitale e quelle che invece usano un cavetto di bypass. Di solito quest’ultime hanno un cavetto “jack maschio – jack maschio” che va collegato all’output della scheda tv e ad un input della scheda audio. In altri casi invece (come nella mia scheda) il bypass è interno e viene usato un cavetto che entra in uno degli input CD della scheda audio.

Nel mio caso se apro “tvtime”, l’audio viene direttamente dall’ingresso CD della scheda audio. Quindi devo intercettarlo dalla scheda audio attraverso ALSA per poterlo registrare. Una prova che potete fare per vedere se anche la vostra scheda funziona come la mia è aprire un canale qualsiasi in “tvtime” o in “xawtv” (o simili) e mettere in muto il canale CD nel mixer. Non dovreste sentire più nulla dalla tv.

Ora lanciate questo comando:

# aplay /dev/dsp1

Dove naturalmente “dsp1″ potrebbe essere nel vostro caso “dsp0″ o “dsp”…. Comunque dovreste sentire in qualità abbastanza pessima l’audio della vostra scheda tv. Bene quell’indirizzo corrisponde a “hw.[x]” in alsa.

Ok adesso vediamo lo script:

#!/bin/bash

echo "Recorder.sh a simple script for mencoder - version 1.2 (05/10/08)"
echo "Made by Ermete Trismegisto (www.nerdsopolis.org)"
echo "-------------------------------------"

if [ ! $1 ] & [ ! $2 ]
then
	echo "Usage: $0 [channel] [seconds] [option] [start]"
        echo "-------------------------------------"
	echo "Channel = channel number -> see scantv output"
	echo "Seconds = record lenght in seconds"
	echo "Option: -f = follow (see the file while recording)"
	echo "	      -p = planned (plan a recording)"
	echo "Start = time in HH:MM of start"
        echo "-------------------------------------"
	echo "Example: recorder.sh 56 3600 12:50"
	echo "It will plan a recording of 1 hour at 12:50 on channel 56"
        echo "-------------------------------------"
        exit
fi

WIDTH=640
HEIGHT=480
MENCODER=/usr/bin/mencoder
AT=/usr/bin/at
FILE="capture_${1}_$(date +%Y-%m-%d_%H:%M:%S).avi"
AUDIO="-oac mp3lame -lameopts cbr:br=128:mode=0"
VIDEO="-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1500:vhq -vf pp=lb"
DSP="alsa:adevice=hw.1"
TV=" -tv driver=v4l2:width=$WIDTH:height=$HEIGHT:input=1:device=/dev/video0:audiorate=32000:norm=PAL:channel=${1}:$DSP"
if [ "$3" = "-f" ]; then
	if [ $4 ]; then
		echo "ERROR: Start time is valid only for -p option"
		exit
	fi
	echo "Recording on channel ${1} for ${2} seconds... opening player"
	amixer set CD mute
	$MENCODER tv:// $TV $VIDEO $AUDIO -endpos ${2} -ffourcc divx -o $FILE & sleep 5 ; gmplayer $FILE
	amixer set CD unmute
	exit
fi
if [ "$3" = "-p" ]; then
	if [ ! $4 ]; then
		echo "ERROR: Start time missing"
		exit
	fi
	echo "Planned recording on channel ${1} at ${4} for ${2} seconds"
	echo amixer set CD mute | at ${4}
	echo $MENCODER tv:// $TV $VIDEO $AUDIO -endpos ${2} -ffourcc divx -o $FILE | at ${4}
	exit
fi
if [ !$3 ]; then
	echo "Instant recording on channel ${1} for ${2} seconds"
	amixer set CD mute
	$MENCODER tv:// $TV $VIDEO $AUDIO -endpos ${2} -ffourcc divx -o $FILE
	amixer set CD unmute
	exit
fi

Per poterlo usare vi basta copiarlo e incollarlo in file di testo e salvarlo come “recorder.sh”. Naturalmente ricordatevi dove lo salvate per poi poterlo eseguire!

Le impostazioni per la compressione dell’audio sono dentro alla variabile “AUDIO” mentre quelle per il video nella variabile “VIDEO”. Poi c’è il “DSP” (che dicevamo è la periferica audio) e “TV” che è la scheda da cui acquisire. Qualunque modifica allo script andrebbe fatta dunque in queste 4 variabili.

Come dicevo all’inizio, per finire, lo script può registrare istantaneamente oppure, se è stato specificato un’orario, mettere in coda l’azione usando il comando AT. Se viene impostata un’azione futura, è sempre possibile controllare che l’azione sia stata correttamente messa in coda da AT digitando:

$ atq

Ci sono alcune piccole cose che ho intenzione di modificare in questo script, come ad esempio la possibilità di scrivere la durata del programma in minuti o ore (adesso accetta solo secondi, quindi 1 ora è 3600 secondi) e la possibilità di fargli aprire direttamente il player per seguire la registrazione. Un’altra funzione utile potrebbe essere quella di fargli mettere in “mute” il canale del CD IN della scheda audio. Infatti adesso tutte le volte che verrà avviato mencoder partirà anche l’audio proveniente dalla TV.

Con l’aggiornamento alla versione 1.1 ho aggiunto due funzioni: la prima (-f) che apre automaticamente gmplayer sul file che si sta salvando; la seconda (attraverso amixer) che mette in muto il canale CD della scheda audio. In questo modo non si sente la tv mentre la si registra!

Quindi un uso tipico, in perfetto stile timeshifting è:

./recorder.sh 25 3600 -f

In questo modo recorder.sh farà partire la registrazione sul canale 25 per una durata massima di 1 ora e provvederà ad aprire mplayer e selezionare il file che si sta creando. Ora potete mettere in pausa la registrazione e riprenderla liberamente mentre lo script continua a registrare.

Se viene programmata una registrazione, ad esempio di notte, ricordatevi sempre di spegnere le casse del PC altrimenti potrebbe venirvi un infarto quando parte l’audio a tutto volume!

Conclusioni

Nel caso abbiate proposte di modifica o suggerimenti per farlo funzionare meglio, siate liberi di lasciare dei commenti!

Ah, l’ispirazione di questo script mi è stata data da questo ottimo post: link.

[post originale: 28 agosto 2008 - aggiornato il 10 ottobre 2008]

Molti di voi probabilmente lo conoscono, si tratta di un software di emulazione del sottosistema windows in ambiente linux. In pratica premette di emulare in tutto e per tutto le componenti audio e video di un pc win e di giocare perfettamente ai giochi basati sulle DirectX anche in linux. Comodo no? Non c’è neanche bisogno di creare una macchina virtuale.

Ma veniamo all’oggetto del mio post. Negli ultimi giorni qui a nerds city abbiamo parlato molto di videogames e quindi mi sento in dovere di parlarvi di quello che, per me, è in assoluto il miglior videogioco dell’era moderna (termine vago che indica l’avvento di windows e delle directx).

Penso che sia il migliore per una serie di motivi: la storia, lo stile narrativo, la grafica e la giocabilità.

La storia, abbastanza comune in stile noir, narra a grandi linee di un investigatore che cerca di farsi giustizia in una New York corrotta. I particolari sono però gustosi: una droga di nome valchiria che ci regala momenti di psichedelia, continui flashback alla morte della famiglia del protagonista, palazzi totalmente disabitati pieni di malavitosi, una tempesta di neve… tutte cose che sicuramente, se ci avete giocato, vi avranno fatto capire di cosa si tratta.

A differenza di moltissimi altri videogiochi del genere la storia non viene raccontata (nei momenti di non-gioco) da filmati, sono invece dei fumetti “interpretati” con suoni e voci che ci danno tutte le informazioni necessarie a seguire la narrazione. Fantastico! Anche perchè i fumetti sono veramente belli in stile un po’ “grunge” e le voci sono interpretate perfettamente da attori. Come dimenticare la voce del protagonista doppiata da Giorgio Melazzi (che molti conoscono anche come comico di Zelig).

La grafica era veramente favolosa, soprattuto nel sequel. Ricca di dettagli (si può sparare a qualunque oggetto, spostarlo, aprirlo) e di effetti di luce, il gioco rimane in mente soprattutto per qualche trucchetto usato per arricchire la narrazione. Indimenticabile la scena in cui per effetto di valchiria si entra in un tunnel che si allunga man mano che si cammina!

La giocabilità è secondo me al top per un videogame in terza persona. Prendendoci un po’ la mano, usando la bullettime, si riescono a fare delle mosse favolose. A volte si entra in una stanza e si riescono ad uccidere 5 nemici senza neanche venir colpiti una volta… Unico punto dolente è che dopo un po’ il gioco risulta troppo guidato. La porta da aprire è sempre una sola, la strada da seguire pure. Lasciatemi sognare per un attimo un Max Payne dove si può liberamente girare per il livello in stile Hitman…. Ops! Ho detto il nome del gioco… ma ormai lo avevate capito, no?!

Chiudo questa breve recensione con una notizia che ho appreso proprio cercando un po’ di link per il gioco. Quest’anno uscirà probabilmente (si parla di ottobre) il film di Max Payne… non vi siete anche voi un po’ rotti le palle di vedere film basati sui videogiochi? Io decisamente si.

Evviva i divx/xvid (e chi vuol intendere intenda).