Installare Pipelight su Fedora 19

Nonostante venga oramai da anni visto da molti come un software morto e senza futuro, Silverlight a tutt'oggi continua a godere in rete di una discreta diffusione. Gli utenti Linux non hanno però mai avuto vita facile con questa tecnologia: Microsoft non ha mai rilasciato alcuna versione ufficiale per il pinguino e Moonlight, un'implementazione opensource dell'ambiente di Silverlight per Linux, ha chiuso i battenti da oltre due anni.
Di recente è nato un nuovo progetto, Pipelight, che promette di far girare la versione di Silverlight per Windows su Linux, tramite una versione di Wine modificata ad hoc con una serie di patch, colmando così il vuoto venutosi a creare con l'arresto dello sviluppo di Moonlight.

Pipelight, nonostante la giovane età, si è comportato molto bene nelle prove eseguite (non sono sicuro della riproduzione di contenuti protetti da DRM, che non ho potuto testare a fondo)
Per facilitare l'installazione agli utenti di Fedora ho realizzato una serie di pacchetti rpm che potete prelevare da questo repository dedicato
Ovviamente il tutto (sia pipelight che i mie rpm) va considerato estremamente sperimentale!

Per provare pipelight occorre innanzitutto attivare il repo, dando in un terminale:

# wget https://dl.dropboxusercontent.com/u/7141888/home_darkhado_pipelight/19/darkhado_pipelight.repo -P /etc/yum.repos.d/

Installiamo quindi il pacchetto con:

# yum install pipelight 

Nota: Oltre a pipelight verrà installata la versione di wine patchata, che andrà a sostituire completamente quella eventualmente già presente nella vostra macchina!

Per far funzionare correttamente il programma sono richiesti inoltri alcuni font per Windows, che però dovremo installare manualmente, poiché redistribuirli all'interno di un pacchetto binario significherebbe violare i termini della licenza Microsoft.
Per semplificare un poco la procedura ho inserito nel repo anche il pacchetto sorgente di msttcorefonts (realizzato partendo dal file spec disponibile qui)
Compilando ed installando tale pacchetto avremo tutti i font necessari. Eseguiamo in un terminale le seguenti istruzioni:

$ yumdownloader --source msttcorefonts
$ rpm -ihv msttcorefonts-2.5-1.src.rpm
$ cd ~/rpmbuild/SPECS/
# yum-builddep msttcorefonts-2.5-1.spec
$ rpmbuild -bb msttcorefonts-2.5-1.spec
# yum install ../RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm

 (Attenzione ai comandi da eseguire come user - $ - e quelli che invece richiedono i privilegi di root - # -)

Non ci resta che ora che aprire il nostro browser e verificare il comportamento di pipelight (personalmente consiglio di utilizzare Firefox che nelle mie prove ha risposto molto meglio rispetto a Chromium)

Alcuni link utili per fare qualche test:
http://www.microsoft.com/silverlight/iis-smooth-streaming/demo/
http://bubblemark.com/silverlight2.html
http://live.la7.it/dirette_tv/ 

EDIT:

Una cosa importantissima che avevo omesso è che è assolutamente essenziale non aver alcun browser aperto durante l'installazione di pipelight affinché questa possa concludersi con successo; in caso contrario ci ritroveremmo con il plugin non funzionante. 

É possibile comunque riparare facilmente l'installazione seguendo queste istruzioni

Installare Archlinux in una chroot su Fedora

Certamente saprete che esiste un gran varietà di soluzioni (VirtualBox, VMware, Boxes, etc) per installare ed eseguire una o più macchine virtuali all'interno del nostro sistema GNU/Linux.

Tutte però hanno gli svantaggi di essere avide di risorse e di offrire delle prestazioni per i i sistemi guest spesso tutt'altro che esaltanti.

In questo articolo vi illustrerò un metodo alternativo alla virtualizzazione "classica" che non fa ricorso a nessuno dei software citati sopra: installeremo il sistema guest non su un disco virtuale ma in una "chroot", ossia in una normalissima directory del nostro filesystem che all'occorrenza diventerà la root del nostro sistema virtuale.

I vantaggi più evidenti:

- sistema guest immediatamente disponibile, senza alcun tempo di caricamento aggiuntivo.

- prestazioni del guest pari a quelle dell'host.

- possibilità di eseguire all'interno del desktop del sistema host un applicativo del sistema guest, senza dover avviare un'ulteriore sessione grafica.

Vediamo ora come realizzare praticamente tutto questo installando, a titolo di esempio, Archlinux (guest) su una macchina Fedora (host).

L'uso dei termini "host" e "guest" vi risulterà forse un po' inappropriato, non trattandosi questa di una vera e propria virtualizzazione,  ma spero comunque che me lo concederete, un po' per comodità e un po' per la mancanza di vocaboli più consoni. :-)

Iniziamo con il prelevare l'ultima iso di Archlinux disponibile sul sito ufficiale (alla data in cui scrivo archlinux-2013.09.01-dual.iso)
Terminato il download, montiamo l'immagine in una directory di nostra scelta, ad esempio:

# mount archlinux-2013.09.01-dual.iso -o loop /mnt/img/

In base alla versione di Archlinux che desideriamo installare ci sposteremo nella directory i686 o x86_64
all'interno della iso montata.
32 bit:

$ cd /mnt/img/arch/i686/

64 bit:

$ cd /mnt/img/arch/x86_64/

Nelle directory troviamo un file root-image.fs.sfs, compresso con squashfs, che contiene l'immagine di una installazione Archlinux.
Scompattiamo il file in una directory a nostro piacere, ad esempio:

# unsquashfs -d /squashfs root-image.fs.sfs

(Nota: la destinazione, indicata con l'opzione -d, non deve essere già presente nel filesystem, altrimenti il comando fallirà)
Montiamo ora l'immagine presente nella directory appena creata:

# mount /squashfs/root-image.fs -o loop /mnt/arch/

Se diamo un:

 $ ls /mnt/arch/

possiamo verificare la presenza della struttura classica delle directory di un sistema GNU/Linux.

bin   dev  home  lost+found  opt   root  sbin  sys  usr
boot  etc  lib   mnt         proc  run   srv   tmp  var

Siamo pronti per completare l'installazione di Archlinux all'interno della nostra Fedora:

# mkdir /arch
# cp -a /mnt/arch/* /arch/

Prima di "avviare" Archlinux smontiamo le immagini e rimuoviamo tutto ciò che non ci serve più:

# rm -rf /squashfs/
# umount /mnt/img
# umonut /mnt/arch

Verifichiamo ora di avere svolto tutto correttamente; avviamo la chroot:

 # chroot /arch/

Proviamo a dare qualche comando esclusivo di Archlinux come:

# pacman -Q

o semplicemente un:

# cat /etc/issue 

 che ci restituirà:

Arch Linux \r (\l)

Non c'è dubbio, stiamo ora utilizzando Archlinux!! :-)
Il nostro lavoro tuttavia non è ancora finito, per rendere pienamente utilizzabile il sistema guest dovremo dedicarci ancora un po' alla sua configurazione.
Innanzitutto dovremo creare un utente con lo stesso id del nostro utente Fedora; questo ci servirà per eseguire correttamente applicazione grafiche e pulseaudio nella chroot.
Con tutta probabilità l'id dell'utente Fedora è 1000 (come da impostazione predefinita); verifichiamolo eseguendo in un nuovo terminale:

$ id -u

Nella chroot esiste già un utente con id 1000 (utente arch), ragion per cui dovremo innanzitutto eliminarlo prima di poter procedere alla creazione di un nuovo utente con questo id.
Rimuoviamo quindi l'utente arch:

# userdel arch
# rm -r /home/arch/

Creiamo ora un nuovo utente con lo stesso nome e lo stesso id dell'utente Fedora; ipotizzando di avere l'utente simone con id 1000 diamo:

# useradd -M -u 1000 -U simone

e assegniamo la password all'utente simone con:

# passwd simone

Anche l'utente root non ha ancora alcuna password, rimediamo con:

# passwd 

Usciamo temporaneamente dalla chroot semplicemente dando:

# exit

Per rientrare in Archlinux non useremo più semplicemente il comando chroot come abbiamo fatto in precedenza, ma lanceremo questo script:

 #/bin/sh
mount -t proc none /arch/proc
mount -t sysfs none /arch/sys
mount -o bind /dev /arch/dev
mount -o bind /dev/pts /arch/dev/pts
mount -o bind /var/run /arch/var/run
mount -o bind /var/lib/dbus /arch/var/lib/dbus
mount -o bind /tmp /arch/tmp
mount -o bind /home /arch/home
mount -o bind /dev/shm /arch/dev/shm
cp -Lf /etc/resolv.conf /arch/etc
chroot /arch

Questo è necessario per passare al sistema guest fondamentali informazioni circa l'hardware della nostra macchina, le partizioni, ecc., senza le quali nessun os Linux potrebbe funzionare correttamente.

In particolare l'opzione bind di mount serve in pratica proprio a condividere determinati mountpoint tra host e guest.

Salviamo lo script dandogli come nome start_chroot.sh dopodiché lanciamolo, sempre da root:

# start_chroot.sh

Rientrati nella chroot, dovremmo essere ora in grado di sfruttare finalmente appieno la nostra Archlinux!
Iniziamo con il mettere a punto pacman, il package manager di Archlinux.

# pacman-key --init
# pacman-key --populate archlinux

Proviamo quindi a lanciare un aggiornamento di sistema con:

# pacman -Syu

L'operazione dovrebbe andare a buon fine, segno che il package manager di Archlinux funziona a dovere.
Possiamo a questo punto installare nuovi pacchetti e personalizzare l'installazione a nostro piacimento.
Proviamo infine ad eseguire un applicazione grafica; switchate all'utente creato in precedenza ("simone" nel nostro esempio)

# su  simone

Come test eseguiamo magari un gioco o riproduciamo semplicemente un stream video da YouTube così da verificare che anche l'audio nella chroot funzioni a dovere.

Concludo l'articolo ricordando che per uscire in ogni momento dalla chroot basta digitare "exit" nel terminale.
Lo script che abbiamo visto in precedenza (start_chroot.sh) va lanciato unicamente al primo accesso alla chroot dopo il boot della macchina; i montaggi eseguiti dallo script restano infatti sempre attivi fino allo spegnimento. Per tutti i successivi utilizzi della chroot basterá dare:

# chroot /arch/

EDIT:
Se desiderate uno script più completo che sia anche in grado di smontare le directory condivise una volta terminato di lavorare nella chroot, potete utilizzare questo (realizzato modificando quello presente in questa pagina del wiki di Archlinux)

 #!/bin/bash
MOUNTPOINT=/arch
PIDFILE=/run/arch_chroot
case $1 in
  start)
    mount -t proc none $MOUNTPOINT/proc
    mount -t sysfs none $MOUNTPOINT/sys
    dirs=(/dev /dev/pts /dev/shm /var/run /var/lib/dbus /tmp /home )
    for d in "${dirs[@]}"; do
      mount -o bind $d $MOUNTPOINT$d
    done
    cp -Lf /etc/resolv.conf /arch/etc
    touch $PIDFILE
    ;;
  stop)
    dirs=(/dev/pts /dev/shm /dev /var/run /var/lib/dbus /tmp /home)
    umount $MOUNTPOINT/{sys,proc}
    for d in "${dirs[@]}"; do
      umount -l "$MOUNTPOINT$d"
    done
    rm -f $PIDFILE
    ;;
  *)
    echo "usage: $0 (start|stop)"
    exit 1
esac

Salviamo lo script con il nome arch_chroot, quindi per inizializzare la chroot daremo:

# arch_chroot start

Poi per entrare in Archlinux eseguiremo il solito

# chroot /arch

Una volta usciti dalla chroot con

# exit

Potremo smontare i mounpoint condivisi tra host e guest con:

# arch_chroot stop

Ottimizzare la compilazione su Fedora con distcc e ccache

In questa guida vedremo come installare e configurare distcc e ccache, due strumenti che permettono di abbreviare (e anche di parecchio) i tempi di compilazione.

Distcc è un programma ideato per distribuire i processi di compilazione tra più host all'interno di una rete; è quindi ovviamente necessario disporre di almeno due o più macchine della stessa architettura per potere usufruire dei benefici di questo strumento. In mancanza di questo requisito distcc diventa perfettamente inutile e non ha alcune senso installarlo.

Ccache invece (come riporta wikipedia nell'abbozzo dedicato al programma) "memorizza l'output della compilazione di un programma scritto in C/C++ così che la volta successiva la medesima compilazione possa essere evitata. Questo metodo velocizza di gran lunga il tempo di compilazione."

Vediamo ora come installarli e configurarli in modo da farli lavorare congiuntamente.
Partiamo da ccache:

# yum install ccache
$ source /etc/profile.d/ccache.sh

Se ora provate ad esempio a dare:

ll $(which g++)
lrwxrwxrwx. 1 root root 16  7 lug 23.04 /usr/lib64/ccache/g++ -> ../../bin/ccache

potete notare come il path di g++ (default /usr/bin/g++) sia stato cambiato e punti ora all'eseguibile di ccache. Questo ci garantisce che ogni processo di compilazione verrà gestito dal programma il quale stabilirà di volta in volta se andare a "pescare" i dati dalla sua cache o passare i sorgenti ai compilatori della GNU Compiler Collection.

Non occorrono ulteriori configurazione per usufruire dei vantaggi di ccache, semplicemente lanciate le vostre compilazioni nello stesso identico modo che seguivate prima dell'installazione del programma.

Passiamo all'installazione di distcc (qui le cose si complicano un pochino). Su tutte le macchine della nostra rete che vogliamo utilizzare per le compilazioni "condivise" iniziamo con il dare:

# yum install distcc-server

quindi editiamo la configurazione aprendo il file /etc/sysconfig/distccd.
Ipotizzando di disporre di due macchine con indirizzi 192.168.1.1 e 192.168.1.2 modificheremo il file in questo modo:

OPTIONS="--allow 192.168.1.0/24 --log-file=/var/tmp/distccd.log"
USER="nobody"

--allow 192.168.1.0/24 abilita tutti gli host appartenenti alla rete 192.168.1.x a connettersi al demone distccd.
--log-file abilita la creazione di un file di log. Senza questa opzione distccd invierà i suoi output esclusivamente al file /var/log/messages. Se desiderate che il log memorizzi esclusivamente eventuali messaggi di errore aggiungete l'opzione --log-level error.
USER="nobody" indica invece che il demone girerà con i privilegi dell'utente "nobody", il che dovrebbe garantirci un buon livello di sicurezza.
Se non specificato diversamente distccd girerà sulla porta 3632 (default). Potete indicare una porta differente con l'opzione --port. Dovrete però ricordavi anche di aggiornare opportunamente la configurazione del client (come vedremo più avanti)

Completiamo la configurazione di distcc lato server aprendo la porta 3632 nel firewall (ricordiamoci anche in questo caso di eseguire l'operazione su tutti gli host). Senza bisogno di ricorrere a firewall-config possiamo comodamente aggiornare le impostazioni di firewalld con un'unica istruzione:

# firewall-cmd --permanent --zone=$(firewall-cmd --get-default-zone) --add-port=3632/tcp

controlliamo che la porta 3632 sia stata effettivamente aggiunta all'elenco delle porte aperte:

 # firewall-cmd --permanent --zone=$(firewall-cmd --get-default-zone) --list-ports

Avviamo il demone distccd con:

# systemctl enable distccd
# systemctl start distccd

Il demone creerà una serie di sottoprocessi (di default pari al doppio delle cpu/core del sistema più uno) corrispondenti al numero massimo di compilazioni che possono essere eseguite parallelamente (quindi su un singole core avremo tre processi, su un dual core saranno invece cinque e così via). Possiamo verificarlo con:

$ ps -ef | grep distccd
nobody    3417     1  0 21:09 ?        00:00:00 /usr/bin/distccd --verbose --no-detach --daemon --allow 192.168.1.0/24 --log-file=/var/tmp/distccd.log
nobody    3418  3417  0 21:09 ?        00:00:00 /usr/bin/distccd --verbose --no-detach --daemon --allow 192.168.1.0/24 --log-file=/var/tmp/distccd.log
nobody    3419  3417  0 21:09 ?        00:00:00 /usr/bin/distccd --verbose --no-detach --daemon --allow 192.168.1.0/24 --log-file=/var/tmp/distccd.log
nobody    3420  3417  0 21:09 ?        00:00:00 /usr/bin/distccd --verbose --no-detach --daemon --allow 192.168.1.0/24 --log-file=/var/tmp/distccd.log
nobody    3421  3417  0 21:09 ?        00:00:00 /usr/bin/distccd --verbose --no-detach --daemon --allow 192.168.1.0/24 --log-file=/var/tmp/distccd.log

L'output riporta cinque demoni distccd, valore corretto per un macchina dual core. Possiamo anche forzare la creazione di un numero arbitrario di processi con l'opzione --jobs sempre nel file /etc/sysconfig/distccd.

Installiamo ora il client di distcc su una o più macchine che useremo per lanciare le attività di compilazione (ovvero il (o i) computer su cui eseguiremo i vari "make", "rpmbuild",ecc.). Da un terminale diamo:

# yum install distcc

Fatto questo dobbiamo far sapere a distcc quali sono gli host tra i quali distribuire i lavori di compilazione; per far questo è sufficiente indicare nel file /etc/distcc/hosts i relativi indirizzi ip. Continuando con il nostro esempio il nostro file hosts sarebbe così composto:

192.168.1.1 192.168.1.2

Non occorre specificare la porta se i nostri server girano su quella di default; in caso contrario è invece necessario specificarla con la sintassi [host]:[port], ad esempio:

192.168.1.1:1234 192.168.1.2:1234

All'interno sempre dello stesso file è inoltre possibile indicare alcune opzioni che permettono di modificare il comportamento di distcc. La più interessante è a mio avviso lzo (per le altre opzioni vi rimando direttamente alla lettura di man distcc) che, come intuibile, fa sì che tutti i dati vengano compressi prima di essere trasferiti da un host all'altro. Nel mio caso ho verificato che tale opzione permette un'ulteriore riduzione dei tempi di compilazione tutt'altro che trascurabile. Per attivare la compressione lzo, modificheremo il file hosts in questo modo:

192.168.1.1,lzo 192.168.1.2,lzo

Abbiamo praticamente terminato la nostra configurazione, l'unica cosa che ancora manca è quella di "legare" insieme distcc e ccache per creare un ambiente di compilazione ottimale; per far ciò ci basta la seguente istruzione:

 $ export CCACHE_PREFIX="distcc"

Vi consiglio di aggiungerla al vostro .bashrc in modo che venga eseguita automaticamente ad ogni login.

Non ci resta ora che effettuare qualche test per vedere come il nostro setup si comporta sul campo. Per misurare i tempi di compilazione possiamo usare il comando bash time:

$ time make
$ time rpmbuild -ba file.spec

Se usiamo make (come spesso avviene) per compilare un programma, è bene, per sfruttare al massimo le capacità di distcc, passare come numero di jobs la somma di tutti i demoni distccd della nostra rete. Cerco di spiegarmi meglio: abbiamo due host A e B; A è un singol core quindi può gestire al massimo n.3 processi di compilazione simultaneamente. B è invece un dual core quindi può arrivare a n.5 processi. Il valore quindi da passare a make è di 8 (3+5):

$ make -j 8

Utilizzare un numero superiore (in questo caso) ad 8 non avrebbe alcun senso, distcc automaticamente bloccherebbe le richieste eccedenti le capacità dei server.

Compilare più volte lo stesso programma provando opzioni differenti vi aiuterà a trovare la configurazione migliore per le vostre macchine. Prima di ogni test è però necessario pulire la cache di ccache, altrimenti i risultati dei vostri test risulterebbero completamente falsati.

Ccache permette infatti di ricompilare in maniere estremamente rapida un pacchetto compilato almeno già una volta, grazie alla sua capacità di memorizzazione dei risultati delle compilazioni precedenti. Questa feature utilissima va però "disattivata" in questo caso, pena avere dei risultati del tutto inaffidabili.

Ci basterà prima di ogni compilazione azzerare la cache con:

 $ ccache -C

Per monitorare in tempo reale l'avanzamento della compilazione e i trasferimenti dati tra le macchine possiamo lanciare distccmon-gnome o distccmon-text dall'host client.

Edit: alcuni tips&tricks
Nel file .rpmmacros nella vostra home è possibile impostare il numero di jobs predefinito che rpmbuild dovrà usare nella creazione dei pacchetti rpm: è sufficiente inserire il valore desiderato in corrispondenza del campo %_smp_mflags, ad esempio:

%_topdir %(echo $HOME)/rpmbuild
%_smp_mflags    -j12
...

Se desiderate eseguire una particolare compilazione senza l'uso di distcc vi basta "annullare" la variabile CCACHE_PREFIX impostata in precedenza:

$ env -u CCACHE_PREFIX rpmbuild -ba file.spec

Hot Corner in XFCE/LXDE

Abituato (per non dire assuefatto) agli "hot corner" di KDE quando mi trovo ad utilizzare desktop diversi, come LXDE o XFCE, spesso istintivamente sposto il puntatore del mouse negli angoli alti dello schermo a destra o sinistra, rispettivamente per tornare velocemente al desktop o per visualizzare l'elenco delle finestre aperte. Ma ovviamente non accade nulla di tutto questo :-)
"Hot corner", per chi non lo sapesse, è una funzione molto utile che permette di avviare determinati comandi e attività portando semplicemente il cursore del mouse verso gli angoli del nostro desktop.
Desideroso quindi di poter disporre di tale meccanismo anche al di fuori di KDE ho fatto alcune ricerche in rete e ho trovato un programma che fa esattamente al caso mio, brightside.

Una volta presente nei repo ufficiali di Fedora, il pacchetto è stato successivamente rimosso in seguito alla chiusura del progetto (anche lo stesso sito non è più raggiungibile da tempo). Anche se lo sviluppo è completamente fermo oramai da parecchi anni il programma, da quel che ho visto, continua comunque a funzionare bene.
Potete prelevare brightside dal mio repo su OBS, qui.
Gran parte del merito per la realizzazione di questo pacchetto va ad un altro utente di OBS Huaren Zhong, package maintainer molto attivo che vanta nel suo repo personale oltre 1.300 pacchetti! Io ho semplicemente importato il suo lavoro e applicato alcuni piccolo fix.

Dopo aver eseguito l'installazione, configuriamo il comportamento degli hot corner lanciando:

$ brightside-properties

Come potete vedere la procedura di configurazione è estremamente semplice e intuitiva: è sufficiente per ogni angolo dello schermo selezionare l'azione che desideriamo venga eseguita. Il programma offre già alcune attività predefinite (avvio dello screensaver, disattivazione dello schermo, mostra desktop, ecc.) oltre alla possibilità di immettere dei comandi personalizzati.

Ora ci manca solo di impostare l'avvio automatico del demone brightside; un metodo valido sia per XFCE che LXDE è il seguente:

$ mkdir -p $HOME/.config/autostart
$ cp /usr/share/applications/fedora-brightside.desktop $HOME/.config/autostart
$ sed -i 's/brightside-properties/brightside/' $HOME/.config/autostart/fedora-brightside.desktop

 

Accensione automatica del pc con RTC Alarm

RTC Alarm è un'interessante caratteristica, presente in tutte le motherboard oramai da parecchi anni, che permette di programmare in maniera automatica l'accensione dei nostri pc in date e orari da noi prestabiliti.
Mentre in passato era in genere possibile accedere direttamente alle impostazioni di RTC Alarm tramite la sezione Power Management del BIOS, i produttori di schede madri al giorno d'oggi sembra che preferiscono tenerle 'nascoste', nonostante continuino comunque a supportarle.

In Linux è possibile programmare facilmente il 'wakeup' automatico delle nostre macchine, bypassando l'accesso al BIOS, tramite l'utility rtcwake.
Gli utilizzatori di Fedora non avranno bisogno di installare questo programma, perché è sicuramente già presente facendo parte del pacchetto util-linux, assolutamente essenziale in un sistema GNU/Linux
I parametri da passare al programma sono fondamentalmente due: il tipo di standby e data e ora in cui il pc dovrà ripartire.
Le modalità di standby impostabili sono le seguenti: standby, mem, freeze, disk, off, no, on, disable e  show. 
Quella che preferisco e che in genere utilizzo è no. Con questa opzione semplicemente impostiamo l'orario del wakeup senza che venga attivata nessuna modalità di sospensione, il che significa che una volta dato il comando possiamo continuare a lavorare. Quando decideremo di chiudere la nostra sessione di lavoro lo faremo selezionando Iberna dal menu di logout del nostro display manager (gdm, kdm, lxdm ecc.) e non Spegni. Questo servirà a rendere effettiva la nostra accensione programmata.
Se non stiamo lavorando in X ma in un tty, dovremo allora spegnere il nostro pc con pm-hibernate oppure systemctl hibernate (da eseguire come utente root).
Per dettagli sulle altre modalità di standby vi invito a consultare direttamente il manuale di rtcwake (man rtcwake)
Il secondo parametro, come dicevamo, è l'effettivo orario di wakeup: il programma richiede che tale parametro sia formattato secondo lo Unix Time (o Posix Time), un sistema di rappresentazione del tempo largamente utilizzando nei sistemi Unix e Unix-like (come Linux) che si basa sul numero di secondi trascorsi a partire dalle ore 00:00:00 del 01 gennaio 1970 (la cosiddetta Unix Epoch).
La conversione del tempo in Unix time è estremamente semplice grazie al comando date e la sua opzione %s. Ad esempio, per visualizzare l'ora attuale del sistema in Unix time basta dare:

 $ date +%s
1375909919

Possiamo verifichiamo a cosa effettivamente corrisponde  "1375909919" dando:

$ date -d @1375909919
mer  7 ago 2013, 23.11.59, CEST

Ipotizziamo di voler programmare l'accensione della nostra macchina alle ore 8.00 di domani mattina; per calcolare il corrispondente Unix Time daremo:

$ date +%s -d 'tomorrow 08:00'
1375941600

Attiviamo quindi RTC alarm con:

# rtcwake -a -m no -t 1375941600
rtcwake: wakeup using /dev/rtc0 at Thu Aug  8 06:00:01 2013

Il fatto che il comando ci restituisca come orario "06:00" anziché "08:00" non è un errore come potrebbe sembrare. È semplicemente la rappresentazione secondo il Tempo Coordinato Universale o UTC ovvero il fuso orario di riferimento da cui si calcolano tutti gli altri fusi orari del mondo (a sua volta derivato dal GMT ( Greenwich Mean Time o Greenwich Meridian Time) e che systemd utilizza di default per l'orologio hardware del pc.

Per verificare la correttezza dell'orario di wakeup in base alle impostazioni locali della nostra macchina diamo:

# rtcwake -m show -l
alarm: on  Thu Aug  8 08:00:01 2013

che ci conferma che tutto è stato settato correttamente. Ricordiamoci di spegnere il nostro pc ibernandolo, per rendere attivo RTC Alarm.
A questo punto, compreso il meccanismo, diventa semplice scrivere degli script personalizzati in base alle nostre necessità: eccone ad esempio uno (da eseguire come root ogni giorno prima dello spegnimento) che programma il wakeup ogni mattina alle ore 07:45 del giorno successivo (esclusivamente dal lunedì al venerdì), in modo che al nostro arrivo in ufficio il pc sia acceso e pronto all'uso:

#!/bin/sh
if [[ $(date +%u) -gt 4 ]]; then
        DATE=$(date +%s -d 'next Monday 07:45')
else
        DATE=$(date +%s -d 'tomorrow 07:45')
fi
/sbin/rtcwake -a -m no -t $DATE

Qui potete trovare un dettagliato articolo sulla sintassi del comando date, in particolare per come indicare con facilità date future.  

  

Come scrivere le lettere accentate con le tastiere inglesi

Se siete programmatori o anche semplicemente utilizzate in modo abituale il terminale Linux e vi è capitato di provare una tastiera con layout inglese credo che ben difficilmente non l'abbiate trovata più comoda rispetto a quella italiana. L' unica pecca è la mancanza di tasti per le lettere accentate, inutilizzate nei paesi di lingua anglosassone.
Tra le varie alternative che ho provato senza dubbio la migliore, sia come semplicità di configurazione che immediatezza di utilizzo, è il ComposeKey di X.org. Grazie al ComposeKey è possibile scrivere le lettere accentate (e altri caratteri speciali) con delle combinazioni di tasti estremamente semplici sia da fare che da ricordare perché molto intuitive.
Ad es. per avere la lettera è ("e" con accento grave) dovremmo immettere la combinazione: AltGr + e + `
In modo analogo per avere la lettera ú ("u" con accento acuto) basterà dare: AltGr + u + '
Per scrivere ø (simbolo di diametro) inseriremo invece AltGr + o + /

Come potete vedere le combinazione sono assolutamente intuitive e non richiedono veramente alcuno sforzo per apprenderle.
Vediamo quindi come abilitare il ComposeKey, di default disabilitato.
Spostiamoci nella directory /etc/X11/xorg.conf.d/ e apriamo, da root, il file 00-keyboard.conf. Se il file non esiste sulla nostra macchina, lanciamo sempre da root:

# system-config-keyboard

quindi scegliamo il layout corretto della nostra tastiera e confermiamo con "Ok".
Sul mio notebook con tastiera Inglese (Regno Unito) il file appare così:

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "gb"
        Option "XkbModel" "pc105"
EndSection

Attiviamo il ComposeKey aggiungendo alla sezione "InputClass":

Option          "XkbOptions"    "compose:ralt"

Il file completo dopo le nostre modifiche risulterà quindi così:

 Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "gb"
        Option "XkbModel" "pc105"
        Option "XkbOptions"    "compose:ralt"
EndSection

"ralt" ovvero "right alt" (AltGr) è il tasto che ho scelto come avviatore delle sequenze di tasti perché lo ritengo il più comodo e "naturale". Se preferite usare altro siete naturalmente liberissimi di farlo, vi basta sostituire "ralt" con il tasto di vostra scelta, "rwin" per il tasto Windows di destra, "lctrl" per ctrl di sinistra e così via.

Terminate le modifiche riavviamo X per renderle effettive.

Potete trovare l'elenco completo dei caratteri speciali attivabili con ComposeKey nel file  /usr/share/X11/locale/en_US.UTF-8/Compose

Aggiornamento di thunderbird-attachment (versione 1.1)

Di recente vi avevo parlato di un mio piccolo progetto, thunderbird-attachment, un servizio per Dolphin per allegare e spedire file tramite Thunderbird. In questi giorni ho fatto alcune modifiche soprattutto per rendere ancora più semplice e immediata l'impostazione dell'indirizzo di default per l'invio delle mail.
Il file get_tb_id.pl è stato rimpiazzato da settbid il quale, oltre a mostrare l'elenco degli indirizzi email di Thundebird come il suo predecessore, permette di salvare in un file (in $HOME/.thunderbird-attachment) l'indirizzo che vogliamo utilizzare come default.
Ecco un esempio chiarificatore:

$ settbid
[1] id1 -> pippo@gmail.com
[2] id2 -> pluto@alice.it
[3] id3 -> paperino@localhost
:: please choose your default email address (type corresponding number)
:: [ q = quit progam ]
>2
:: "pluto@alice.it" (id2) is now the default sender address!
:: Bye

Non è più richiesta quindi la modifica manuale del file thunderbird-attachment.pl (da questa versione semplicemente thunderbird-attachment): il programma utilizzerà ora in maniera automatica l'id impostato con settbid

Se desiderate provare questa nuova versione su Fedora 19 scaricate da qui i pacchetti thunderbird-attachment e perl-MailIdentity (modulo richiesto per gestione del file di configurazione)

Creare il link a /dev/dvd in Fedora 19

Riporto qui essenzialmente quanto già scritto nell'ambito di una discussione sul forum Fedora Online con alcune integrazioni. Ad oggi in Fedora 19 (a differenza delle precedenti release) non è presente alcun meccanismo automatico per  la creazione del link /dev/dvd verso il dispositivo dvd (in genere /dev/sr0).
Questa lacuna è piuttosto seccante dal momento che la totalità dei media player punta di default verso questo link, di conseguenza ogni tentativo di avviare la riproduzione di un dvd video fallirà con errori del tipo "device not found" o "can't read from device".

Grazie alle proprietà di systemd è possibile risolvere facilmente questo problema creando un file di configurazione apposito nella directory  /etc/tmpfiles.d/. Tale file, eseguito ad ogni avvio del sistema, ricreerà il link "dimenticato" dagli sviluppatori di Fedora.

Individuiamo innanzitutto il nome esatto del nostro lettore dvd:

 $ cat /proc/sys/dev/cdrom/info  | grep name
   drive name:             sr0

Trovato il nome del dispositivo spostiamoci nella directory /etc/tmpfiles.d/ e creiamo un file dal nome dvd.conf il cui contenuto sarà il seguente:

L /dev/dvd - - - - /dev/sr0

Verifichiamo che il nostro file funzioni e che il symlink a /dev/dvd venga creato:

# systemctl start systemd-tmpfiles-setup-dev.service

Se abbiamo SELinux in modalità "Enforcing" (modalità di default) il comando provocherà un allarme e l'esecuzione verrà bloccata.
Per consentirla diamo:

# grep systemd-tmpfile /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Ripetiamo dunque il comando:

# systemctl start systemd-tmpfiles-setup-dev.service

A questo punto il nostro link dovrebbe essere stato creato, controlliamo con:

$ ls -l /dev/dvd

Se l'output che otteniamo è simile a questo:

 lrwxrwxrwx. 1 root root 8 24 lug 14.12 /dev/dvd -> /dev/sr0

significa che la procedura è andata a buon fine il link a /dev/dvd verrà automaticamente ricreato ad ogni boot di sistema.
Se siete interessati ad approfondire le potenzialità dei tmpfiles di systemd, vi consiglio questa esaustiva lettura

Come allegare file a Thunderbird direttamente da Dolphin (ovvero replicare il comando "Invia a destinatario di Posta" di Windows)

Un po' per necessità e un po' per gioco di recente ho scritto un servizio per Dolphin simile al ben noto "Invia a destinatario di Posta" che certamente avrete visto sui sistemi Windows.
Esiste già un servizio simile, Attach to Thunderbird, che però, forse anche perché non viene più aggiornato da tempo, non funziona in modo impeccabile: non è possibile allegare ad un nuovo messaggio più file contemporaneamente e inoltre fallisce del tutto in presenza di particolari caratteri al'interno del nome del file che desideriamo allegare.
Per questo motivo ho quindi preparato, con pochissime righe di Perl, una mia variante, partendo dal servizio già esistente; eccola in azione:

Se desiderate provare il servizio sulla vostra macchina, potete scaricarlo da qui.
L'installazione è semplicissima: scompattate l'archivio tar.xz  e copiate il file thunderbird-attachment.desktop nella cartella ~/.kde/share/kde4/services/.
Dopodiché copiate i file thunderbird-attachment.pl e get_tb_id.pl in ~/bin (oppure /usr/local/bin) e assicuratevi che siano eseguibili (è sufficiente un chmod 775 *.pl)
Lo script è pronto per essere utilizzato; per testarlo aprite Dolphin, selezionate uno o più file, quindi tasto dx del mouse e cliccate su Azioni->Invia E-mail con Thunderbird.

Il servizio usa di default come mail del mittente l'indirizzo associato all'id1 di Thunderbird. Se volete utilizzare un id diverso vi basta apre il file thunderbird-attachment.pl, posizionarvi alla riga n. 26 e  sostituire "id1" con quello di vostra scelta (id2, id3, ecc.)
Per verificare gli indirizzi disponibili e gli id associati, lanciate in un terminale:

$ get_tb_id.pl

Il comando richiede il modulo File::Slurp; se non è già presente nel vostro sistema installatelo con

 # yum install perl-File-Slurp

Il servizio è stato testato unicamente su Fedora 19, non dovrebbero comunque esserci problemi ad eseguirlo su distro diverse. Se così non fosse, segnalatemelo!

P.s. Ho creato anche un pacchetto rpm per Fedora 19, al fine di rendere ancora più agevole l'installazione; potere reperirlo qui

Abilitare il formato video h.264 in Chromium con Fedora

Chromium così come il suo derivato proprietario Chrome supporta pienamente i codec previsti dal sempre più popolare tag <video> introdotto con l'avvento di HTML5: Theora, WebM e h.264.

Tuttavia nella versione fornita da Fedora il formato video h.264 è stato disabilitato, perché trattasi di una tecnologia ancora coperta da brevetti software, nonostante il suo utilizzo sia di fatto gratuito ed esente da royalties (come dichiarato dalla MPEG LA, l'azienda che gestisce le licenze relative agli standard MPEG).

Questo "limite" del pacchetto di Fedora rientra comunque in un discorso più vasto e complesso della distribuzione di non voler supportare il codec h.264 a livello generale, decisione che è stata ed è tuttora oggetto di pesanti critiche e feroci diatribe. 

Celebre in tal senso, tra le altre, questa discussione dell'anno scorso nella mailing list di Fedora.
Tornando a Chromium, come avrete certamente già immaginato, per abilitare il supporto a H.264 occorre per forza di cose ricompilare il programma. L'operazione è in sé piuttosto semplice, il rovescio della medaglia è che la ricompilazione del browser, a secondo dell'hardware della vostra macchina, può richiedere anche diverse ore.
Quello che ad oggi è l'rpm ufficiale per Fedora non è adatto ai nostri scopi,  poiché il pacchetto non si basa sui sorgenti "vanilla" del browser ma bensì su una versione "clean", ripulita cioè di alcuni componenti, tra cui le preziose librerie richieste da h.264
Fortunatamente in rete ho trovato nei repository di Russian Fedora (un'interessantissima derivata) un pacchetto che fa proprio al caso nostro: esente dal difetto di cui sopra e che, con pochissime modifiche, può essere facilmente ricompilato.
Andiamo quindi sul sito del servizio Koji di Russian Fedora e preleviamo l'ultimo source rpm disponibile per Fedora 18. Alla data in qui sto scrivendo il pacchetto più recente è chromium-28.0.1500.52-1.fc18.R.src.rpm (attenzione che si tratta di un rpm di oltre 1GB!!)
Terminato il download, andiamo ad scompattare il pacchetto:

$ rpm -ihv chromium-28.0.1500.52-1.fc18.R.src.rpm

Entriamo ora nella cartella ~/rpmbuild/SPECS/ e con un editor di testo (nano, vim, gedit, kwrite, ecc.) apriamo il file chromium.spec, dopodichè localizziamo la seguente porzione di testo:

%build
export GYP_GENERATORS=make
build/gyp_chromium --depth=. \
-D linux_sandbox_path=%{_libdir}/%{name}/chrome-sandbox \
-D linux_sandbox_chrome_path=%{_libdir}/%{name}/chrome \
-D linux_link_gnome_keyring=0 \
-D use_gconf=0 \
-D werror='' \
-D use_system_sqlite=0 \
-D use_system_libxml=0 \
-D use_system_zlib=0 \
-D use_system_bzip2=1 \
-D use_system_libbz2=1 \
-D use_system_libpng=0 \
-D use_system_libjpeg=1 \
-D use_system_libevent=1 \
-D use_system_flac=1 \
-D use_system_vpx=1 \
-D use_system_speex=1 \
-D use_system_libusb=1 \
-D use_system_libexif=1 \
-D use_system_libsrtp=1 \
-D use_system_libmtp=1 \
-D use_system_opus=0 \
-D use_system_libwebp=1 \
-D use_system_harfbuzz=0 \
-D use_system_minizip=1 \
-D use_system_yasm=1 \
-D use_system_xdg_utils=1 \
-D build_ffmpegsumo=1 \
-D use_system_ffmpeg=0 \
-D use_pulseaudio=1 \
-D use_system_v8=0 \
-D linux_link_libpci=1 \
-D linux_link_gsettings=1 \
-D linux_link_libspeechd=1 \
-D linux_link_kerberos=1 \
-D linux_link_libgps=1 \
        -Dgoogle_api_key='AIzaSyD1hTe85_a14kr1Ks8T3Ce75rvbR1_Dx7Q' \
-Dgoogle_default_client_id='4139804441.apps.googleusercontent.com' \
-Dgoogle_default_client_secret='KDTRKEZk2jwT_7CDpcmMA--P' \

Come dicevo prima, le modifiche che occorre fare per attivare il fase di compilazione il supporto al codec h.264 sono tutt'altro che complicate; è sufficiente aggiungere i seguenti parametri al comando gyp_chromium:

        -D ffmpeg_branding=Chrome \
        -D proprietary_codecs=1 \

Fatta questa operazione il risultato finale sarà di questo tipo:

build/gyp_chromium --depth=. \
-D linux_sandbox_path=%{_libdir}/%{name}/chrome-sandbox \
-D linux_sandbox_chrome_path=%{_libdir}/%{name}/chrome \
-D linux_link_gnome_keyring=0 \
-D use_gconf=0 \
-D werror='' \
-D use_system_sqlite=0 \
-D use_system_libxml=0 \
-D use_system_zlib=0 \
-D use_system_bzip2=1 \
-D use_system_libbz2=1 \
-D use_system_libpng=0 \
-D use_system_libjpeg=1 \
-D use_system_libevent=1 \
-D use_system_flac=1 \
-D use_system_vpx=1 \
-D use_system_speex=1 \
-D use_system_libusb=1 \
-D use_system_libexif=1 \
-D use_system_libsrtp=1 \
-D use_system_libmtp=1 \
-D use_system_opus=0 \
-D use_system_libwebp=1 \
-D use_system_harfbuzz=0 \
-D use_system_minizip=1 \
-D use_system_yasm=1 \
-D use_system_xdg_utils=1 \
-D build_ffmpegsumo=1 \
-D use_system_ffmpeg=0 \
-D use_pulseaudio=1 \
-D use_system_v8=0 \
-D linux_link_libpci=1 \
-D linux_link_gsettings=1 \
-D linux_link_libspeechd=1 \
-D linux_link_kerberos=1 \
-D linux_link_libgps=1 \
-D ffmpeg_branding=Chrome \
-D proprietary_codecs=1 \
        -Dgoogle_api_key='AIzaSyD1hTe85_a14kr1Ks8T3Ce75rvbR1_Dx7Q' \
-Dgoogle_default_client_id='4139804441.apps.googleusercontent.com' \
-Dgoogle_default_client_secret='KDTRKEZk2jwT_7CDpcmMA--P' \

Salvate e chiudete il file. Se siete utilizzatori di chromium-pepper-flash e volete continuare ad usarlo con questo pacchetto alternativo di Chromium dovete sostituire il file  ~/rpmbuild/SOURCES/chromium-wrapper con la versione da me modificata e scaricabile da qui. In caso contrario ignorante tranquillamente questo passaggio.

Terminate le attività di modifica, passiamo alla compilazione; innanzitutto scarichiamo le dipendenze necessarie:

 $ sudo yum-builddep chromium.spec

Se siete su Fedora a 64 bit e il precedente comando vi restituisce l'errore:

Nessun pacchetto trovato per /lib/libz.so.1

installate il pacchetto zlib.i686 per risolverlo, dopodiché ripetete l'esecuzione del comando yum-builddep.
Fatto questo lanciamo finalmente la vera e propria compilazione del pacchetto:

$ rpmbuild -ba chromium.spec

Come detto in precedenza l'operazione potrebbe richiedere parecchio tempo, quindi mettetevi comodi :-)
Al termine, se tutto è andato per il verso giusto, troverete il pacchetto rpm di Chromiun in  ~/rpmbuild/RPMS/i686 o ~/rpmbuild/RPMS/x68_64, a seconda dell'architettura del vostro pc, pronto per essere installato.
Effettuiamo ora qualche test per verificare l'effettiva disponibilità del codec h.264; iniziamo con l'aprire la pagina della versione di prova HTML5 di youtube.
Ora in corrispondenza della voce h.264 dovrebbe esserci un segno di spunta verde e non più un punto esclamativo rosso.

Collegandovi alla pagina  HTML5 tests - video su quirksmode.org potete provare la riproduzione di uno spezzone di Big Buck Bunny in formato h.264 (oltre che WebM e Theora)
Vimeo dovrebbe ora consentirvi l'utilizzo del player HTML5 al posto di Flash. Aprite un qualunque video (ad esempio questo) e cliccate su Switch to HTML5 Player. Enjoy! :-)

P.s.
Per chi volesse provare questo pacchetto alternativo di Chromium, risparmiandosi l'avventura della ricompilazione, potete trovare nel mio repository personale (e sperimentale) il pacchetto compilato a 64 bit

EDIT:
Ho appena aggiunto anche la versione 32 bit. Non posso invece caricare nel repo (creato all'intero di un account dropbox free) il source rpm per ovvi motivi di spazio, sorry!

EDIT2 (27/07/13):
Aggiungo alcune informazioni che ritengo molto utili da sapere:
- Per la compilazione su x86_64 è richiesta una dipendenza che non è indicata nel file spec e senza la quale  la compilazione stessa fallisce: libstdc++.i686. Installate il pacchetto prima di procedere con rpmbuild.
- A partire da chromium-28.0.1500.71-1.1.fc19.R il team di Russian Fedora ha deciso di utilizzare di default Aura, la nuova interfaccia utente progettata per ChromeOS. In attesa che Aura diventi più maturo consiglio caldamente di disattivarne la compilazione: è sufficiente all'interno del file spec sostituire  use_aura=1 in use_aura=0.
Se invece volete provate Aura, sappiate che la vostra scelta causerà parecchi problemi a chromium: nessun plugin (eccetto chromium-pepper-flash) verrà caricato, non sarà possibile riprodurre video HTML5 a schermo intero e l'icona di chromium non verrà visualizzata nella barra delle finestre.

Vlc: riprendere automaticamente la riproduzione di un video grazie ad un plugin

Una feature che da anni gli utenti di Vlc chiedono è la possibilità di riprendere in maniera automatica la riproduzione di un video dal punto esatto in cui è stata precedentemente interrotta. Gli sviluppatori del celebre media player hanno però sempre fatto orecchie da mercante e di fatto questa caratteristica è a tutt'oggi ancora assente.
C'è però una buona notizia per coloro che desiderano questa feature: infatti, per colmare questa lacuna lo sviluppatore Artem Senichev ha da qualche mese reso disponibile un plugin che permette di aggiungere a Vlc il resume automatico dei video: sto parlando di vlc-srpos-plugin disponibile sia per sistemi Linux che per Windows.
Per facilitare il lavoro agli amici di Fedora che volessero provarlo, ho realizzato un pacchetto rpm pronto all'uso: potere recuperarlo dal mio repo Dropbox.
Attivate innanzitutto il repo dando:

 $ wget https://dl.dropbox.com/u/7141888/home_darkhado_extra/18/darkhado_extra.repo -O - | sudo tee /etc/yum.repos.d/darkhado_extra.repo

dopodiché potete installare il plugin con:

$ sudo yum install vlc-srpos-plugin

 Per renderlo però operativo occorre abilitarlo esplicitamente dalle preferenze di Vlc.
Avviate Vlc, quindi Strumenti -> Preferenze, poi in basso a sinistra: Mostra le impostazioni -> Tutto.
Cercate tra le voci sulla sinistra Interfacce di controllo dopodiché spuntate Save/restore position of the last played  files. Confermate con Salva e riavviate VLC per applicare le modifiche fatte.

Dalle prove che ho fatto il plugin sembra mantenere quello che promette, l'unico limite è che attualmente vengono salvate le informazioni di riproduzione esclusivamente degli ultimi 10 file aperti. A mio avviso questo valore dovrebbe essere comunque più che sufficiente per la maggior parte degli utenti

Installare FoFiX su Fedora

Dopo aver giocato parecchio a StepMania  ho recentemente eletto come mio gioco preferito per i necessari momenti di svago FoFiX, il celebre clone open di GuitarHero/RockBand e fork del defunto FretsOnFire.
Per paura di incorrere in possibili casi di violazione di brevetti software Fedora non include nei repo ufficiali questo gioco né altri giochi dello stesso tipo (ad esempio Performous)
Ho quindi provveduto personalmente alla creazione di un pacchetto funzionane per Fedora. Ho optato per prelevare direttamente la versione in sviluppo dal server git del progetto, dal momento che le release ufficiali sono un po' "attempate" (l'ultima stabile risale a dicembre 2009, mentre la prima alpha della futura 4.0.0 é del novembre 2010).
Essendo, come dicevo, ancora in sviluppo il gioco non è del tutto stabile al 100%, l'impostazione di alcuni settaggi con valori diversi da quelli di default può causare dei crash; comunque nel complesso si lascia giocare piuttosto bene.

Per rendere il gioco più piacevole e divertenti per pochi euro ho acquistato su ebay una chitarra per PS2 con relativo adattatore usb, il supporto per questi dispositivi è egregio. Se FoFiX vi appassiona vi consiglio di fare come me, non ve ne pentirete :-)
Per condividere il mio pacchetto con chi fosse interessato, ho creato appositamente un repository sperimentale (esclusivamente per Fedora 18) all'intero del mio account Dropbox; lo trovate qui
(non ho potuto utilizzare il mio repo principale su OBS per via della dipendenza di ffmpeg)

Per installare FoFiX sulla vosta macchina, copiate il file darkhado_extra.repo all'intero di /etc/yum.repos.d/
dopodiché date:

$ sudo yum install fofix

Ora non vi resta che impugnare la vostra chitarra ed esibirvi nei grandi assoli dei vostri rocker preferiti! :-)

Configurare l'invio delle mail di notifica di Cron su Fedora

Di default per i cronjob che producono dei messaggi di output, il demone crond tenta di inviare al proprietario del cronjob tale output tramite il comando sendmail.

In questa breve guida vedremo come configurare su Fedora un servizio di posta locale, con l'obiettivo di monitorare i comandi eseguiti per mezzo di cron.
Il metodo più semplice è senz'altro quello di installare exim, un mail server che Fedora offre già configurato a puntino e funzionante "out-of-the-box":

$ sudo yum install exim

Poiché ci sono diversi pacchetti in Fedora che forniscono il comando sendmail è opportuno verificare che quello offerto da exim sia impostato come default; diamo in un terminale:

$ sudo alternatives --config mta

nel caso in qui nel nostro sistema siano presenti più alternative di sendmail, riceveremo un output del genere:

 Ci sono 2 programmi che forniscono 'mta'.
  Selezione    Comando
-----------------------------------------------
* 1           /usr/sbin/sendmail.ssmtp
+ 2           /usr/sbin/sendmail.exim
Invio per mantenere l'attuale selezione[+], o inserire il numero di selezione: 

Se sendamail.exim non è l'mta di default digitate il numero corrispondente per renderlo tale. L'alternativa correntemente selezionata è evidenziata dal simbolo "+".
Verifichiamo che il nostro servizio di posta locale sia funzionante, provando ad inviarci una mail; scriviamo:

 sendmail $(whoami) << EOF

Dopodiché proseguiamo scrivendo il testo del nostro messaggio di prova:

> subject: Test Local Delivery
>
> Questo è un messaggo di prova!

Per terminare la composizione ed inviare il messaggio scriviamo:

> EOF

Per controlliamo che il messaggio sia stato effettivamente recapitato installiamo il programma mailx:

$ sudo yum install mailx

Dopodiché diamo in un terminale:

$ mail

Se tutto è andato per il verso giusto, dovremmo vedere un output di questo tipo:

Heirloom Mail version 12.5 7/5/10.  Type ? for help.
"/var/spool/mail/simone": 1 message 1 new
>N  1 Simone Sclavi         Sun Mar 17 16:01  15/622   "Test Local Delivery"
&  

segnale che il nostro servizio di posta locale è perfettamente funzionate e quindi utilizzabile da cron.
Un' ulteriore cosa utile che possiamo fare è quella di impostare un alias per l'utente root, fare cioè in modo, per comodità, che i messaggi destinati a root siano reindirizzati all' account di un utente di sistema ordinario. Per fare questo apriamo il file /etc/aliases e alla fine aggiungiamo questa riga:

root:           <nome utente>

Correggete <nome utente> con l'utente di sistema che dovrà ricevere le mail dell'utente root.
Per rendere effettivo l'alias creato, daremo:

$ sudo newaliases

Diversi client mail in Fedora sono in grado di gestire la posta locale; ad esempio se, come me, utilizzate Thunderbird vi sarà sufficiente aggiungere un nuovo account di tipo "Unix Mailspool (Movemail)".

Compilare un modulo senza ricompilare l'intero kernel Linux

Esiste una procedura molto semplice per compilare un modulo nativo non presente nel kernel della nostra distro; per far questo non è necessario ricompilare l'intero kernel, è possibile compilare direttamente il modulo o i moduli che ci interessano, tramite gli strumenti che gli sviluppatori ci mettono a disposizione.
In questa guida farò riferimento a Fedora 18, distro che ho utilizzato nei mie test; tuttavia la procedura, con l'eccezione della "preparazione" dei sorgenti, è in linea di massima valida per ogni altra distribuzione GNU/Linux.

Iniziamo verificando se il modulo che ci serve è stato effettivamente escluso dal kernel che stiamo utilizzando, onde evitarci un lavoro inutile; per far questo è sufficiente interrogare il file di configurazione del kernel, generalmente installato all'intero di /boot.
Se ad esempio volessimo controllare la presenza del modulo ntfs, ci basterebbe dare:

 $ grep -i ntfs /boot/config-$(uname -r)

Se l'output di risposta al nostro comando è questo:

# CONFIG_NTFS_FS is not set

è evidente che i package maintainer del kernel hanno effettuato la compilazione escludendo il supporto a tale modulo.

Procediamo quindi con l'installare i pacchetti necessari a compilare il modulo mancante:

$ sudo yum install yum-utils kernel-devel

Recuperiamo i sorgenti del kernel (nel momento in cui scrivo l'ultima release disponibile è la 3.8.2-206)

$ yumdownloader --source kernel

Scompattiamo il pacchetto con:

 $ rpm -ihv kernel-3.8.2-206.fc18.src.rpm

Installiamo le dipendenze di compilazione:

 $ sudo yum-builddep kernel-3.8.2-206.fc18.src.rpm

Scompattiamo i sorgenti e applichiamo le patch di Fedora, in modo da essere allineati con la versione fornita dalla distro:

 $ rpmbuild -bp --target=$(uname -m) ~/rpmbuild/SPECS/kernel.spec

Fatto questo all'interno della directory ~/rpmbuild/BUILD troveremo una sottodirectory contenente i sorgenti del kernel; spostiamoci al suo interno (nel mio caso, sistema 64bit e kernel 3.8.2-206):

$ cd ~/rpmbuild/BUILD/kernel-3.8.fc18/linux-3.8.2-206.fc18.x86_64/

Ipotizziamo di volere compilare il modulo ntfs visto prima; posizioniamoci nella relativa directory:

 $ cd fs/ntfs

Oltre ai sorgenti, nella directory troviamo un file Kconfig fondamentale per il nostro scopo; al suo interno sono specificate i parametri da passare a make per la compilazione. Apriamo Kconfig con un qualunque editor di testo facendo particolare attenzione alle voci "config" presenti nel file; troveremo:

config NTFS_FS
           tristate "NTFS file system support"
           [...]
 config NTFS_DEBUG
           bool "NTFS debugging support"
           [...]
config NTFS_RW
           bool "NTFS write support"
           [...]

"config NTS_FS" abilita la compilazione del modulo ntfs, "config NTFS_DEBUG" e "config NTFS_RW" sono invece parametri facoltativi che permettono di attivare funzionalità aggiunte ( rispettivamente l'abilitazione del debug e il montaggio dei filesystem NTFS in scrittura ).
Ora che abbiamo ottenuto tutte le informazioni che ci servivano, possiamo passare finalmente alla
compilazione del nostro modulo; per una compilazione "standard" senza opzioni aggiuntive è sufficiente dare:

 $ make -C /lib/modules/$(uname -r)/build M=$(pwd) CONFIG_NTFS_FS=m modules

 Invece se volessimo attivare tutte le opzioni di compilazione possibili daremo:

 $ make -C /lib/modules/$(uname -r)/build M=$(pwd) CONFIG_NTFS_FS=m CONFIG_NTFS_DEBUG=y CONFIG_NTFS_RW=y modules

Terminata la compilazione, possiamo installare il modulo con:

 $ sudo make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install

Per pulire la directory dai risultati delle nostre compilazioni scriviamo:

$ make -C /lib/modules/$(uname -r)/build M=$(pwd) clean

Proviamo a caricare il modulo per verificarne il corretto funzionamento:

$ sudo modprobe --verbose ntfs

Se ci viene restituito l'errore:

   modprobe: FATAL: Module ntfs not found.

eseguiamo:

$ sudo depmode -a

quindi proviamo a ripetere il caricamento del modulo con modprobe.
E' tutto! Come avete potuto notare, in pochi minuti e in maniera tutt'altro che complicata, siamo riusciti a compilare e installare un modulo nativo del kernel risparmiando un enorme quantità di tempo rispetto ad un completa ricompilazione.

Installare StepMania su Fedora da repository

Se, come me, siete appassionati di questo bellissimo gioco, vi farà piacere sapere che ho da pochissimo aggiunto i relativi pacchetti al mio repository online su OpenSUSE Build Service.
Ci sono però alcuni importanti limiti: poiché OBS gestisce unicamente pacchetti provenienti dai repo ufficiali di Fedora, ho dovuto compilare StepMania senza il supporto a ffmpeg e libmad.
La mancanza di ffmpeg significa nessun video riprodotto in background durante il gioco, mentre senza libmad non sarete in grado di utilizzare nessuna traccia audio in formato MP3, dettaglio sicuramente non trascurabile.
Ma andiamo con ordine; se volete installare il mio repo sulla vostra macchina, date da root:

# wget http://download.opensuse.org/repositories/home:darkhado/Fedora_17/home:darkhado.repo -O - | tee /etc/yum.repos.d/home\:darkhado.repo

Questo comando è valido esclusivamente se state utilizzando ancora Fedora 17, OBS non offre ancora la possibilità di creare repository per  la release 18 (aggiornerò l'articolo quando il supporto verrà introdotto, il che dovrebbe avvenire a breve).

---

Aggiornamento del 15/02/2013
È disponibile da qualche giorno anche il repo per Fedora 18; per installarlo date:

# wget http://download.opensuse.org/repositories/home:darkhado/Fedora_18/home:darkhado.repo -O - | tee /etc/yum.repos.d/home\:darkhado.repo

---

Nel repository oltre a StepMania potete trovare altri software che ho pacchettizzato per mie necessità e che potreste trovare utili (potete consultare l'elenco dei pacchetti disponibili qui)
Dopo aver aggiunto il repository per l'installazione del gioco è sufficiente dare:

# yum install stepmania

Come ho detto prima, in questo modo però installerete StepMania senza il supporto a mp3 e  filmati; se tale supporto vi serve ( e penso di sì ) dovrete ricompilarvi manualmente il pacchetto; tranquilli, è tutt'altro che complicato!
Cominciamo con l'installare mock (uno strumento che ci assisterà nella ricompilazione di StepMania) più i file di configurazione richiesti per il repo RPM Fusion Free (il repo che contiene ffmpeg e libmad):

# yum install mock-rpmfusion-free

Se non avete mai usato mock prima di ora, dovrete aggiungere il vostro utente all'omonimo gruppo 'mock':

# usermod -a -G  mock <utente>

Scarichiamo ora il pacchetto sorgente di StepMania:

$ yumdownloader --source stepmania

Al termine del download avremo un file dal nome stepmania-5.0-x.x.src.rpm, ad esempio stepmania-5.0-6.1.src.rpm (purtroppo OBS gestisce il tag "Release" unicamente secondo lo stile di OpenSUSE)
Possiamo ora passare alla ricompilazione del pacchetto con (se siamo su un sistema a 64bit):

$ mock -r fedora-17-x86_64-rpmfusion_free --with=mad --with=ffmpeg  stepmania-5.0-x.x.src.rpm

 Su una macchina a 32 bit daremo invece:

$ mock -r fedora-17-i386-rpmfusion_free [...]

Mock offre anche la possibilità di compilare pacchetti per release di Fedora differenti da quella installata; quindi, ad esempio, anche se stiamo utilizzando Fedora 17 nulla ci vieterebbe di creare un pacchetto di StepMania adatto per Fedora 18, nel qual caso daremo:

$ mock -r fedora-18-i386-rpmfusion_free [...]

Se tutto è andato a buon fine, al termine della compilazione troveremo i nostri nuovi pacchetti nella directory
  /var/lib/mock/fedora-<release>-<architettura>/result (ad esempio: /var/lib/mock/fedora-17-x86_64/result); sarà comunque mock stesso a fornirci il percorso esatto, stampandolo a video alla fine del processo di rebuild.
Dopo aver installato la versione ricompilata di StepMania, possiamo dire a yum di "bloccarla"; cioè di non installare eventuali futuri aggiornamenti onde preservare il pacchetto che abbiamo compilato con il prezioso supporto a ffmpeg e libmad.
Per fare questo è sufficiente aggiunger al file /etc/yum.conf la seguente riga:

 exclude=stepmania

Con questa istruzione vi sarà impossibile reinstallare o aggiornare StepMania ad una nuova versione tramite yum; qualora aveste queste esigenze ricordatevi di cancellare o commentare tale riga prima di procedere con queste operazioni.

Creare una live personalizzata di Fedora 18 (LXDE)

Fedora mette a disposizione una serie di strumenti per creare facilmente live cd personalizzati; in questo esempio vi mostrerò come realizzare un proprio "remix" di LXDE, includendo pacchetti non compresi nella live ufficiale.Le istruzioni possono essere facilmente adattate per creare la propria versione di qualunque spin di Fedora (KDE, XFCE, ecc.)

Iniziamo installando i pacchetti necessari:

# yum install fedora-kickstarts livecd-tools createrepo

  Creiamo la nostra directory di lavoro:

$ mkdir ~/iso
$ cd ~/iso

copiamo i file di configurazione ("kickstart") relativo alla spin di LXDE

 $ cp /usr/share/spin-kickstarts/fedora-livecd-lxde.ks .

Il file, a sua volta, richiede altri due file di configurazione, fedora-live-base.ks e fedora-live-minimization.ks. Potete verificarlo aprendo fedora-livecd-lxde.ks con un editor di testo e cercando le istruzioni %include.
Copiamo quindi i due file:

$ cp /usr/share/spin-kickstarts/{fedora-live-minimization.ks,fedora-live-base.ks} .

 Cominciamo il nostro lavoro di personalizzazione, aprendo il file fedora-live-base.ks e correggendo le impostazioni relative alla localizzazione; trovate all'inizio del file le seguenti righe:

lang en_US.UTF-8
keyboard us
timezone US/Eastern

Sostituite con:

lang it_IT.UTF-8
keyboard it
timezone Europe/Rome

dopodiché salvate e chiudete il file.
Passiamo ora alla parte più importante e interessante: l'aggiunta di pacchetti extra in base alle nostre preferenze.
In questo nostro esempio affronteremo tre possibili casi:

• aggiunta di pacchetti contenuti nei repo ufficiali
• aggiunta di pacchetti contenuti in repo NON ufficiali
• aggiunta di pacchetti non contenuti in nessun repo

Apriamo il file fedora-livecd-lxde.ks, cerchiamo il tag %packages  e inseriamo, al di sotto, il nome
dei pacchetti che vogliamo inserire nel nostro live cd (in aggiunta a quelli standard). Supponiamo, per esempio, di avere il seguente elenco:

%packages
motif
icedtea-web
adobe-release-i386
flash-plugin
ICAClient
skype
...

I pacchetti motif (necessario per ICAClient) e icedtea-web provengono dai repository ufficiali di Fedora, quindi non è richiesta alcuna configurazione aggiuntiva per l'inclusione nella nostra live. Possiamo aggiungere in questa sezione qualunque altro pacchetto ufficiale senza il minimo problema. Non è necessario preoccuparci nemmeno delle dipendenze: verranno risolte ed installate automaticamente in fase di creazione della nostra immagine iso (come vedremo più avanti)
Passiamo ora ad adobe-release-i386 e flash-plugin: i due pacchetti (ipotizziamo di essere in un sistema a 32 bit, in caso contrario vi servirà il pacchetto adobe-release-x86_64) non sono inclusi nei repo ufficiali, dobbiamo quindi indicare esplicitamente all'interno del nostro file kickstart l'indirizzo del repo extra da cui andare a prelevarli.
La procedura è semplicissima: spostiamoci all'inizio del file fedora-livecd-lxde.ks e sotto le istruzioni %include aggiungiamo la seguente riga:

repo --name=adobe-linux-i386 --baseurl=http://linuxdownload.adobe.com/linux/i386/

Le informazioni (--name e --baseurl) relativi ad eventuali altri repo extra che volete aggiungere, possono essere reperite all'intero della directory /etc/yum.repos.d/ (a patto che, ovviamente, stiate utilizzando tali repo sulla vostra Fedora).
Eccoci ora all'ultimo caso: ICAClient e skype. Come detto prima questi pacchetti non sono presenti nei repo ufficiali; dovremmo quindi creare un repo locale in cui andare a mettere gli rpm dei due software (dopo averli scaricati dai rispettivi siti)
Anche in questo caso la procedura è banale; creiamo la directory che conterrà il nostro repo locale:

$ mkdir ~/iso/myrepo/

e copiamo all'interno di myrepo i pacchetti che ci interessano. Al  termine diamo:

$ createrepo ~/iso/myrepo/

e il nostro repo è pronto! Non ci resta che aggiornare il file fedora-livecd-lxde.ks, aggiungendo la seguente riga:

repo --name=myrepo --baseurl=file:///home/utente/iso/myrepo

Ok, fatto questo siamo praticamente pronti a creare la nostra iso! Un problema che ho riscontrato è che la live si avvia con il layout di tastiera  en_US (inglese americano), anche dopo averlo settato su "it" nel file fedora-live-base.ks.
Si può correggere questo comportamento con un piccolo workaround: sempre all'interno del file fedora-livecd-lxde.ks cerchiamo la seguente porzione di testo:

cat > /etc/xdg/lxsession/LXDE/autostart << FOE
/usr/libexec/gam_server
@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
/usr/libexec/notification-daemon
FOE

e correggiamola in questo modo:

cat > /etc/xdg/lxsession/LXDE/autostart << FOE
/usr/libexec/gam_server
@lxpanel --profile LXDE
@pcmanfm --desktop --profile LXDE
/usr/libexec/notification-daemon
@setxkbmap it  <---aggiungere questa riga!
FOE

A questo punto non ci resta che lanciare la creazione della nostra iso: dalla directory ~/iso, come root, diamo:

# livecd-creator --verbose --config=./fedora-livecd-lxde.ks \
   --fslabel=Fedora-LiveCD  --cache=/var/cache/live

Al termine della operazione (che può richiedere diverso tempo) nella directory corrente troveremo la nostra immagine Fedora-LiveCD.iso pronta per essere masterizzata o scritta su un pendrive.

Se scegliete quest'ultima opzione, potete usare il comando livecd-iso-to-disk specificando il device di destinazione, ad esempio:

# livecd-iso-to-disk Fedora-LiveCD.iso /dev/sdb1

È tutto per questa prima mia guida sull'argomento, spero vi possa risultare utile! :-)

Aggiornamenti del pacchetto chromium-pepper-flash per Fedora

Potete scaricare da qui l'ultima versione disponibile del file chromium-pepper-flash.spec
Aggiornerò il file ad ogni nuovo rilascio stabile di Chrome, mantenendo per comodità inalterato il link di download.

 Per la compilazione del pacchetto seguite queste istruzioni

StepMania su Fedora: pacchetti disponibili per la versione 5.0 beta 1

Ecco qui i pacchetti aggiornati all'ultima versione di StepMania (5.0b1a) per gli utenti di Fedora 17:

StepMania-5.0b1a-1.fc17.x86_64.rpm

StepMania-5.0b1a-1.fc17.i686.rpm

StepMania-5.0b1a-1.fc17.src.rpm

Per istruzioni sulla installazione fate riferimento a questo articolo

Buon divertimento!

EDIT:
Per scaricare StepMania andate invece qui