Da qualche tempo mi sono chiesto come utilizzare in modo utile una mia chiavetta USB (da circa 1GB) che, una volta sostituita da una più capiente, era del tutto inutilizzata. Navigando su internet mi sono imbattuto in un articolo riguardante le “nuove” caratteristiche di Vista. Scorrendolo ho notato ad un certo punto che si faceva riferimento ad un metodo di autenticazione basato sull’uso di chiavette USB. Da bravo utente Linux mi sono subito informato se ci fosse una cosa simile anche per il pinguino, trovando piuttosto facilmente, un progetto davvero interessante chiamato pam-usb. Come dice il nome si tratta di un modulo per PAM (Pluggable Authentication Modules), che fornisce un metodo di autenticazione basato su un semplice drive USB in modo facile e veloce (necessita di pochissima configurazione).
In questo articolo prenderò in considerazione un sistema Debian, ovvero quello da me utilizzato utilizzo, quindi i passaggi da fare potrebbero essere un pò differenti a seconda della distribuzione usata.
Prima di tutto è necessario installare i pacchetti di base:
# apt-get install libpam-usb pamusb-tools
Il primo pacchetto contiene il modulo PAM vero e proprio e dipende, innanzitutto da PAM (pare ovvio), HAL (utilizzato per la rilevazione automatica delle penne USB) e pmount (uno strumento per montare periferiche “hotpluggabili” come utente normale). Il secondo pacchetto contiene alcuni strumenti per l’uso del modulo (configurazione, ecc…).
In alternativa è possibile scaricare i sorgenti dal sito (che nel momento in cui scrivo pare essere down) e compilare quelli (rispettando ovviamente tutte le dipendenze).
Una volta installato il tutto, è necessario configurarlo. Come già detto questa procedura è molto facile e intuitiva.
Per prima cosa è necessario impostare il modulo pam_usb.so come default per l’autenticazione. Per fare questo bisogna modificare i file di autenticazione di PAM nella cartella ‘/etc/pam.d’. Il file è ‘auth-common’, ma è anche possibile indicare solo alcuni servizi modificando il file appropriato (es ‘gdm’, ’su’, ecc…).
# nano /etc/pam.d/common-auth
Una volta aperto è necessario individuare la linea:
auth [success=1 default=ignore] pam_unix.so nullok_secure
(come già detto potrebbe variare un po’ a seconda del sistema, ma non ci dovrebbero essere grosse differenze)
E modificarla in:
auth requisite pam_usb.so auth [success=1 default=ignore] pam_unix.so nullok_secure
Oltre a ‘requisite’, che richiede la chiavetta obbligatoriamente e poi chiede anche la password dell’utente, sono disponibili altri due modi: ‘required’ che chiede la password anche nel caso che la chiavetta non sia inserita e ’sufficient’ che non richiede la password ma solo la chiavetta. A seconda delle vostre esigenze/preferenze scegliete quello che più vi aggrada.
(Piccola nota: la linea riguardante il modulo ‘pam_usb.so’ deve essere necessariamente posta prima delle altre, altrimenti il controllo sulla chiavetta USB verrebbe fatto soltanto dopo la richiesta della password, e risulterebbe un tantino inutile).
A questo punto pam-usb è impostato come predefinito. Il prossimo passo è quello di configurare una chiavetta per l’autenticazione utilizzando il tool di configurazione ‘pamusb-conf’.
# pamusb-conf --add-device USBPen Please select the device you wish to add. * Using "USB Flash Disk (USB_Flash_Disk_90711C0025D8-0:0)" (only option) Which volume would you like to use for storing data ? * Using "/dev/sdb1 (UUID: 41DF-30BA)" (only option) Name : USBPen Vendor : USB Model : Flash Disk Serial : USB_Flash_Disk_90711C0025D8-0:0 UUID : 41DF-30BA Save to /etc/pamusb.conf ? [Y/n]
Dove ‘USBPen’ sta per un nome a vostro piacimento. Se è l’unica chiavetta inserita (come nell’esempio) non dovrebbero esserci molti problemi, semplicemente digitate ‘y’ in modo che il programma modifichi automaticamente il file di configurazione, altrimenti è necessario indicare quale periferica si vuole utilizzare.
L’ultimo passo consiste nel definire quali utenti debbano essere autenticati tramite pam-usb sempre utilizzando ‘pamusb-conf’.
# pamusb-conf --add-user user
Which device would you like to use for authentication ?
* Using “USBPen” (only option)
User : user
Device : USBPen
Save to /etc/pamusb.conf ?
[Y/n]
Dove user sta per l'utente desiderato. Se è stata precedentemente configurata una sola periferica, come nell'esempio, semplicemente digitate 'y', altrimenti, come prima, è necessario scegliere quale chiavetta utilizzare.
Per verificare che tutto sia andato a buon fine è possibile utilizzare il tool 'pamusb-check'.
# pamusb-check user * Authentication request for user "root" (pamusb-check) * Device "MyDevice" is connected (good). * Performing one time pad verification... * Verification match, updating one time pads... * Access granted.
A questo punto è possibile riavviare il sistema (o più semplicemente terminare la sessione corrente, o anche utilizzare sudo) dopodichè, una volta arrivati alla schermata di login (che sia testuale o grafica tipo tramite gdm) e inserito il nome utente viene verificata la presenza della chiavetta, e poi, a seconda delle configurazioni (viste in precedenza) o viene richiesta la password dell'utente o procede direttamente al tentativo di login: se la chiavetta è presente il login riesce altrimenti no.
Se qualcosa fosse andato storto in fase di configurazione e non fosse possibile loggarsi, è possibile avviare il sistema in 'single user mode' modificando opportunamente la configurazione del proprio bootloader.
La configurazione di base a questo punto è finita.
pamusb-agent è uno degli strumenti del pacchetto pamusb-tools e permette di eseguire automaticamente comandi in caso di eventi particolari, generati in caso di estrazione o inserimento della chiavetta.
Nella guida ufficiale, viene menzionato come esempio l'avvio dello screensaver e il blocco del sistema una volta estratta la chiavetta.
Tutti i comandi devono essere inseriti nel file di configurazione '/etc/pamusb.conf'.
# nano /etc/pamusb.conf
Aggiungere un'azione è molto semplice, basta modificare la sezione riguardante l'utente desiderato (già creata automaticamente da pamusb-conf). La struttura base di ogni utente dovrebbe assomigliare a quella qui sotto:
<user id="user"> <device>USBPen</device> </user>
Ogni azione ha la seguente sintassi:
<agent event="[evento]">[comando]</agent>
Dove [evento] può essere 'lock' o 'unlock' e [comando] qualsiasi comando shell.
Per l'esempio dello screensaver citato prima (utilizzando GNOME):
<user id="user"> <device>USBPen</device> <agent event="lock">gnome-screensaver-command --lock</agent> <agent event="unlock">gnome-screensaver-command --deactivate</agent> </user>
Dopo aver configurato il necessario è possibile avviare pamusb-agent
$ pamusb-agent
oppure, come demone:
$ pamusb-agent --daemon
Per una lista completa delle sue opzioni vi rimando al suo manuale
$ man pamusb-agent
Nel caso si voglia disattivare pamusb, senza dover disinstallare e perdere tutta la configurazione, è sufficiente commentare la linea nel file '/etc/pam.d/common-auth' (o nei file modificati prima) riguardante il pamusb.
Quindi da
auth requisite pam_usb.so auth [success=1 default=ignore] pam_unix.so nullok_secure
A
#auth requisite pam_usb.so auth [success=1 default=ignore] pam_unix.so nullok_secure
Per quanto riguarda la sicurezza di pamusb c'è da dire che supporta pienamente i cosiddetti 'One Time Pad', in pratica, ad ogni autenticazione, viene generato una nuova chiave per l'autenticazione successiva, in modo che risulti più difficile per un attaccante determinare tale chiave. Pamusb in particolare usa un semplice algoritmo per generare una chiave casuale basato su poche righe di codice:
srand(getpid() * time(NULL)); for (i = 0; i < sizeof(magic); ++i) magic[i] = (char)rand();
Questo metodo, IMHO, risulta essere abbastanza sicuro: anche conoscendo il momento di login e logout dell'utente, sarebbe necessario conoscere l'id del processo (dato dalla funzione getpid()) per duplicare la chiave di autenticazione, cosa che, in base alle mie conoscenze, sarebbe possibile solo conoscendo innanzitutto l'id dell'utente che esegue pamusb (informazione abbastanza accessibile) e da lì risalire al processo stesso (a sistema bloccato non so come questo sia possibile se non avendo già accesso al sistema tramite una altro utente), sempre che il sistema non venga spento ad ogni logout, nel qual caso sarebbe impossibile risalire all'id del processo generatore della chiave di auatenticazione. Comunque per proteggersi da questo tipo di attacco, pamusb esegue un controllo anche sul campo venditore, su quello del modello e del numero seriale della periferica USB, riducendo notevolmente la probabilità di riproduzione 'artificiale' della periferica. Il problema si pone se la chiavetta USB utilizzata non ha un numero seriale, infatti, utilizzando un'altra chiavetta dello stesso venditore e dello stesso modello, e dopo aver generato la chiave di autorizzazione (che comunque risulta abbastanza difficile), un attaccante avrebbe facile accesso al sistema. La vulnerabilità principale però risiede nel modo in cui la chiavetta per l'accesso viene utilizzata: risulta abbastanza ovvio che se prestiamo la chiavetta con la chiave di accesso a qualcun altro, la sicurezza del nostro sistema viene compromessa inesorabilmente.
Come avete potuto vedere è davvero molto facile ottenere il supporto all'autenticazione via USB su Linux. Sul sito ufficiale (se mai dovesse tornare online) è presente la documentazione completa, perciò se necessitate di una funzione particolare non citata in questo articolo potete tranquillamente consultare quella. Dal punto di vista della sicurezza, risulta un programma abbastanza robusto (nonostante tutto e prendendo le dovute precauzioni), anche se non mi sento di consigliarlo per quelle realtà professionali in cui la sicurezza è un requisito importante (le mie considerazioni in questo campo possono non risultare poi così precise ed esatte, pamusb richiederebbe una analisi più approfondita da chi magari ne capisce di più); per sistemi per così dire 'amatoriali' ma anche per piccoli uffici risulta essere comunque una buona soluzione.
]]>In questo articolo parlerò nuovamente di una funzione del kernel Linux: se nell’articolo precedente era kexec, in questo sarà lguest.
lguest non è altro che un hypervisor molto leggero (circa 5000 linee di codice), che permette in modo molto semplice di creare un sistema di paravirtualizzazione (non permette una virtualizzazione completa) con Linux (che è l’unica architettura supportata).
È formato da due parti distinte, una parte kernel, rappresentata da un modulo ‘lg’ (è anche possibile compilarlo direttamente nel kernel) che si occupa del lavoro sporco e una parte user-space, l’hypervisor.
Il funzionamento di lguest è abbastanza semplice da comprendere, in quanto non impiega nessuna tecnica speciale come fanno altri sistemi tipo Xen.
Il cuore di tutto sta nel modulo del kernel che si occupa innanzitutto di allocare una porzione di meoria dinamica del kernel, in cui viene caricato un piccolo hypervisor incaricato di spostarsi dal kernel al sistema guest. Il processo di paravirtualizzazione viene compiuto grazie all’implementazione di paravirt_ops, che deve essere compilato nel kernel da eseguire come guest. Il modulo del kernel si occupa anche di fornire un’interfaccia tramite un file speciale posizionato in /dev/lguest. Il client in user-space, per creare un sistema guest, dovrà semplicemente scrivere un comando di inizializzazione in quel file indicando alcuni valori, come ad esempio dove trovare il kernel e la porzione di memoria da utilizzare.
A questo punto il client in user-space si occupa di allocare un tot di memoria virtuale che poi sarà mappata nel sistema guest come memoria fisica. In questa porzione viene caricato il kernel virtualizzato e poi l’user-space guest (in pratica il filesystem di root del sistema virtualizzato). Un semplice file può essere utilizzato per fornire al sistema guest un’immagine di un disco gestito dal client che si dovrà preoccuperà di spostare blocchi di dati nella memoria dinamica. Per quanto riguarda la rete, il creatore di lguest consiglia di utilizzare una periferica TAP configurata sul sistema host.
Per far partire il sistema guest, lg modifica opportunamente la page tables del kernel, per fare in modo che il sistema guest appena caricato
Bene o male questo è il funzionamento di lguest. Vediamo ora come mettere queste cose in pratica.
Iniziamo subito con la creazione di quello che sarà il filesystem di root del sistema guest. Sconsiglio vivamente di utilizzare una partizione esistente in quanto potrebbero sorgere problemi gravi.
Con questo procedimento verrà creato un sistema Debian da zero. È anche possibile trovare in rete immagini di altri sistemi (per quanto ne sappia, il team di Gentoo fornisce immagini di dischi con la distro preinstallata).
Prima di tutto creiamo il file nel quale verrà installato il sistema, come dimensione 1G dovrebbe bastare:
$ dd if=/dev/zero of=debian.img bs=1 count=1 seek=1G
Creiamo il filesystem:
# mke2fs -j -v debian.img
E montiamolo:
# mkdir /mnt/virtual # mount debian.img /mnt/virtual -o loop
(potrebbe essere necessario caricare il modulo per il loopback)
Per installare il sistema base utilizzeremo un tool, debootstrap, che si occupa di scaricare e installare i pacchetti basilari per il nostro sistema. Dopo averlo installato:
# debootstrap --verbose --arch i386 squeeze /mnt/virtual http://debian.fastweb.it/debian
Potete ovviamente configurarlo come volete, modificando l’architettura, la versione di debian e il repository da cui prelevare i pacchetti.
Ora abbiamo un sistema perfettamente funzionante, ma che richiede alcune configurazioni aggiuntive prima di poter essere utilizzato con lguest.
Perciò la prima cosa da fare è entrare nel sistema con chroot:
# chroot /mnt/virtual
Da cui:
# apt-get update
Per una configurazione terra terra (orario + lingua + password root):
# dpkg-reconfigure tzdata # apt-get install locales # dpkg-reconfigure locales # passwd root
Ora è necessario creare un device a blocchi che verrà utilizzato come console virtuale:
# mknod hvc0 c 229 0
e fare in modo che parta all’avvio modificando il file inittab:
# nano /etc/inittab
cambiando le linee che regolano l’avvio dei terminali:
1:2345:respawn:/sbin/getty hvc0 #2:2345:respawn:/sbin/getty tty2 #3:2345:respawn:/sbin/getty tty3 #4:2345:respawn:/sbin/getty tty4 #5:2345:respawn:/sbin/getty tty5 #6:2345:respawn:/sbin/getty tty6
Per finire creiamo un nuovo utente (chiamatelo pure come vi pare):
# adduser user
E poi usciamo
# exit
Il modo più semplice per eseguire lguest, come suggerisce il creatore stesso, è utilizzare lo stesso kernel sia come host che come guest.
Abbiamo però bisogno di una configurazione particolare, quindi verificate le seguenti impostazioni nel vostro kernel (se non sono presenti ricompilate):
CONFIG_EXPERIMENTAL=y CONFIG_PARAVIRT=y CONFIG_LGUEST_GUEST=y CONFIG_HIGHMEM64G=n CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_VIRTIO_BLK=m CONFIG_VIRTIO_NET=m CONFIG_TUN=m CONFIG_LGUEST=m
Nella cartella del kernel ‘Documentation/lguest’ è presente il client user-space, se non è stato compilato con il kernel, digitate ‘make’.
A questo punto abbiamo tutto il necessario per avviare lguest.
Per prima cosa è necessario caricare il modulo del kernel
# modprobe lg
Dopodichè, sempre dalla cartella di lguest
# ./lguest [mem] [kernel] --tunnet=[ip] --block=[rootfile] root=/dev/vda
Dove:
Dopo aver definito root, è possibile indicare altri valori da passare al kernel.
Un esempio di utilizzo:
# ./lguest 64 /boot/vmlinuz-`uname -r` --tunnet=192.168.1.38 --block=debian.img root=/dev/vda ro quiet
debian.img starebbe ad indicare il file che abbiamo creato prima, mentre come kernel è stato impostato quello attualmente in uso.
Se tutto è andato per il verso giusto, il nuovo kernel dovrebbe partire.
La caratteristica più interessante di lguest è senza dubbio la sua facilità di comprensione e di utilizzo. Essendo scritto in quasi 5000 righe di codice non ha certo funzionalità avanzate da farlo competere con altri grossi progetti di virtualizzazione come Xen o KVM ma è senza dubbio un ottimo punto di partenza per meglio comprendere la virtualizzazione. E comunque non si può certo dire che su Linux manchino soluzioni per la virtualizzazione.
]]>Semplicemente visualizza l’ultimo status dell’utente indicato.
]]>Su sistemi Linux alcuni dei pochi motivi per cui è necessario riavviare il sistema dipendono principalmente da: a) aggiornamento del kernel, b) crash dello stesso.
Personalmente ho sempre odiato il continuo bisogno di riavvio (spesso immotivato) in seguito ad un qualsiasi aggiornamento di software su sistemi Windows, è stata quindi una bella sorpresa per me scoprire che, come già detto, su Linux i riavvii sono molto rari.
Con l’aumentare della mia esperienza nell’uso di Linux, uno dei “lidi” su cui la mia curiosità si è posata è stato proprio il kernel. Dopo i miei primi e incerti tentativi di ricompilazione, credo di poter dire di aver raggiunto un ragguardevole livello di esperienza (per quanto un normale utente senza, ancora, nessuna istruzione accademica in materia possa raggiungere). Come a molti utenti Linux a me piace sperimentare, mi sono perciò spesso trovato a ricompilare uno stesso kernel diverse volte prima di raggiungere una configurazione che soddisfacesse pienamente le mie aspettative, e ovviamente a queste ricompilazioni seguivano necessariamente altrettanti riavvii del sistema. Questo fino a scoprire una interessante funzione del kernel Linux (entrata nel ramo principale di sviluppo già da diverso tempo): kexec.
Kexec permette, in poche parole, di riavviare un kernel da uno già in esecuzione senza dover necessariamente riavviare il sistema fisico.
Prima di partire però è necessario fare una piccola parentesi sul sistema di booting di Linux, questo per meglio comprendere come kexec funziona.
Il processo di boot ha due fasi principali, la fase del bootloader e quella del kernel, le quali possono essere suddivise a loro volta in diversi stadi.
La prima delle due, la fase bootloader, inizia quando un computer viene acceso fisicamente. Dopo qualche inizializzazioni, il controllo dell’avvio viene passato al BIOS (o firmware che dir si voglia), che ha il compito di determinare le varie periferiche connesse (memorie, dischi, ecc…). Il BIOS si occupa anche di avviare il bootloader dal master boot record (MBR), che, in base alla configurazione, farà decidere all’utente quale kernel avviare (la cosa è un pò più complicata, ma spiegare nei dettaglia il boot di Linux non è lo scopo di questo articolo). Ed è a questo pounto che si passa alla fase del kernel.
Dopo aver preso il controllo del boot, il kernel si occupa di esaminare le periferiche, caricare i driver necessari e inizializzarle. A questo punto vengono avviati i servizi di sistema che si occupano del resto (montare i filesystem, avviare i termiali, ecc…).
Per la fase di riavvio, prima di ritornare alla fase del bootloader, vengono prima terminati tutti i processi, smontati i filesystem e scaricati i driver (con conseguente spegnimento delle periferiche).
Kexec non è altro che una funzione del kernel Linux che permette di avviare un kernel da uno già avviato, saltando completamente la fase del bootloader sopra descritta, rendendo quindi la fase di riavvio molto più veloce. Si occupa, in altre parole, di caricare un nuovo kernel in memoria, terminare quello già in esecuzione e sostituirlo con quello caricato in precedenza.
Kexec si divide in due parti, la parte kernel, compilata direttamente con il kernel, che consiste in una serie di system call, e una parte user-space, chiamata kexec-tools (sono ovviamente necessarie entrambe).
Per verificare che il proprio kernel sia compilato con kexec, è sufficiente cercare nel file .config se la chiave CONFIG_KEXEC è impostata a ‘y’:
$ zgrep CONFIG_KEXEC /proc/config.gz
oppure
$ grep CONFIG_KEXEC /boot/config-`uname -r`
Mentre per la parte userspace è sufficiente installare kexec-tools
# apt-get install kexec-tools
oppure usando il proprio package manager preferito.
Prima di procedere con la parte pratica, vediamo più in dettaglio come funziona kexec. Innanzitutto è necessario sapere che il kernel Linux deve essere avviato da una posizione predefinita della memoria, perciò per avviare un nuovo kernel è necessario sovrascrivere quello precedente. Questo è eseguito in 4 passaggi:
I primi due passaggi sono effettuati durante il caricamento del kernel. Una volta caricato nella memoria utente, il kernel viene spostato nella memoria dinamica del kernel grazie all’uso della chiamata di sistema ’sys_kexec’.
Insieme ad esso viene allocato in memoria del codice assembly chiamato ‘reboot_code_buffer’, che si dovrà occupare di sovrascrivere il kernel in funzione con quello caricato in memoria, e poi farlo partire (terzo e quarto passaggio).
Dopo aver verificato che kexec sia correttamente compilato, e aver installato kexec-tools, vediamo ora come usare nella pratica questi strumenti.
Come già detto il primo passo è caricare il kernel in memoria (i primi due passaggi visti prima).
# kexec -l [nuovo-kernel] [args]
dove [nuovo-kernel] sta per l’immagine del kernel da caricare. I formati supportati sono: Beoboot-x86, elf-x86, bzImage-x86, multiboot-x86. Mentre [args] sta per gli argomenti specifici per i formati. Un esempio, utilizzando un kernel in formato bzImage, potrebbe essere:
# kexec -l /usr/src/linux/arch/i386/boot/bzImage --append="root=/dev/hdX"
Dove /dev/hdX sta per il filesystem di root. È possibile usare anche initrd:
# kexec -l /usr/src/linux/arch/i386/boot/bzImage --append="root=/dev/hdX" --initrd=/boot/initrd.img
Se siete indecisi su che argomenti passare al kernel potete dare un’occhiata al file ‘/proc/cmdline’ che indica i parametri dell’attuale kernel.
Per una lista di tutte le opzioni invece basta digitare:
$ man kexec
Ora non resta altro da fare che avviare il nuovo kernel.
# kexec -e
kexec avvia “alla brutta” il nuovo kernel senza fare lo shutdown correttamente, perciò consiglio di usare semplicemente il comando
# reboot
Che dovrebbe funzionare ugualmente (ad un certo punto, dovrebbe spuntare un scritta del tipo “rebooting with kexec” o qualcosa del genere).
Dopodichè il nuovo kernel dovrebbe partire, come se fosse un normale avvio del sistema.
Grazie a kexec, è possibile ridurre notevolmente i tempi di riavvio di un sistema, questo non solo beneficia uno sviluppatore che si trova a dover riavviare numerose volte, ma si applica molto bene anche a tutti quei sistemi in cui il downtime deve essere ridotto al minimo (la maggior parte dei sistemi enterprise quindi). Oltre che ovviamente a tutti quelli che come me vogliono solo imparare qualcosa di nuovo.
]]>Ora devo solo trovare un punto in questo blog in cui piazzare il codice…
]]>Steinberg’s Virtual Studio Technology (VST) è una tecnologia proprietaria per integrare effetti e sintetizzatori con programmi di editing audio. Esistono alternative open-source a VST (come LADSPA, architettura molto usata su Linux), ma spesso si vogliono utilizzare plugin VST di cui non esistono le controparti aperte LADSPA (ed è esattamente quello che mi è successo recentemente). La mia intenzione è quella di utilizzare un simulatore di amplificatore per basso (Heliant 1st Bass) su Linux in accopiata con Jackd e, ovviamente il mio basso. Il problema è che quello è un plugin VST, e non è quindi possibile utilizzarlo nativamente.
Ciò che andremo a fare perciò sarà emulare il plugin VST tramite Wine appogiandoci all’architettura DSSI.
Il primo passo è preparare il nostro sistema. Sono necessarie alcuni pacchetti come wine e libwine, e altri di sviluppo per il software che andremo a compilare dopo.
Come già detto, per emulare i plugin VST useremo Wine:
# apt-get install wine libwine-dev
Consiglio vivamente di utilizzare il pacchetto della propria distribuzione (in questo caso Debian) in quanto fornisce libwine separatamente.
Un’altra cosa di cui abbiamo bisogno è DSSI e del supporto a Jackd
# apt-get install dssi-dev dssi-utils dssi-host-jack
E ovviamente dei pacchetti base per la compilazione
# apt-get install build-essential checkinstall
più una serie di altre librerie di sviluppo:
# apt-get install libasound2-dev liblo0-dev
Pare ovvio ma lo devo dire… Jack deve essere installato.
A questo punto non ci resta che compilare ciò di cui abbiamo bisogno. Prima di tutto dobbiamo scaricare i sorgenti di dss-vst da qui (attualmente l’ultima versione e la 0.8). Poi ci serve l’SDK VST scaricabile dal sito ufficiale Steinberg (per fare questo è necessario registrarsi, il download è gratuito). Ciò di cui abbiamo bisogno è ‘VST Audio Plug-Ins SDK’ versione 2.4 (lo so che c’è anche la versione 3, ma non sono sicuro della compatibilità con dss-vst.
Estraiamo i sorgenti di dssi-vst e poi al suo interno anche la VST SDK. Bene, a questo punto tutte le dipendenze dovrebbero essere soddisfatte, perciò da terminale:
$ make # checkinstall Oppure # make install
Se l’nstallazione è riuscita senza intoppi dovremmo aver a disposizione il comando ‘vsthost’. Dopo aver avviato Jack (nel modo che preferite)
$ vsthost [percorso-plugin]
Dove [percorso-plugin] è il percorso al plugin desiderato.
Potrebbe essere utile settare la variabile VST_PATH prima di avviare vsthost
$ export "VST_PATH=[percorso-a-volontà]"
Vi lascio qualche link utile da cui scaricare plugin VST gratuitamente:
VST4Free – http://www.vst4free.com/
Free Plugin List – http://free-plugin-list.com/
Audio Mastermind Database – http://www.audiomastermind.com/browse-free_vst_plugins-5886988-1.html
Compilato alla Debian way senza nessun problema, e felice come una pasqua mi apprestavo ad installare i driver nVidia… ed è proprio a questo punto che sono iniziati i problemi.
Primo tentativo usando module-assistant e il pacchetto nvidia-kernel-source (185.18) da Sid… Fallito.
Secondo tentativo usando l’installer ufficiale nVidia (sempre 185.18)… Fallito.
Senza perdermi d’animo faccio un terzo tentativo usando l’installer nVidia ancora in beta (versione 192.32) ma anche questo fallisce.
A questo punto, insospettito, vado a guardare il log dell’installazione. L’errore riguardava una certa funzione init_MUTEX evidentemente modificata dalla patch RT. Cercando un pò su internet è saltato fuori che nell’ultima versione del kernel la patch non dichiarava più la suddetta funzione, rispetto alla precedente ovvero quella per la versione 2.6.29.
Continuando a cercare ho trovato anche un’ottima patch per risolvere il problema… vediamo ora come installarla.
La patch è la seguente:
diff -Naur NVIDIA-Linux-x86-190.32-orig/usr/src/nv/nv-linux.h NVIDIA-Linux-x86-190.32/usr/src/nv/nv-linux.h
--- NVIDIA-Linux-x86-190.32-orig/usr/src/nv/nv-linux.h 2009-09-02 11:54:49.000000000 +0100
+++ NVIDIA-Linux-x86-190.32/usr/src/nv/nv-linux.h 2009-09-17 21:05:45.000000000 +0100
@@ -742,20 +742,28 @@
#define nv_down(lock) down(&lock)
#define nv_up(lock) up(&lock)
+#if defined(CONFIG_PREEMPT_RT) && !defined(init_MUTEX)
+# define nv_spin_lock_init(lock) atomic_spin_lock_init(lock)
+# define nv_spin_lock_irqsave(lock, irq) atomic_spin_lock_irqsave(lock, irq)
+# define nv_spin_unlock_irqrestore(lock, irq) atomic_spin_unlock_irqrestore(lock, irq)
+#else
+# define nv_spin_lock_init(lock) spin_lock_init(lock)
+# define nv_spin_lock_irqsave(lock, irq) spin_lock_irqsave(lock, irq)
+# define nv_spin_unlock_irqrestore(lock, irq) spin_unlock_irqrestore(lock, irq)
+#endif
+
#if defined(CONFIG_PREEMPT_RT)
-#define NV_INIT_MUTEX(mutex) init_MUTEX(mutex)
+# if defined(init_MUTEX)
+# define nv_spinlock_t raw_spinlock_t
+# else
+# define nv_spinlock_t atomic_spinlock_t
+# endif
#else
-#if !defined(__SEMAPHORE_INITIALIZER) && defined(__COMPAT_SEMAPHORE_INITIALIZER)
-#define __SEMAPHORE_INITIALIZER __COMPAT_SEMAPHORE_INITIALIZER
-#endif
-#define NV_INIT_MUTEX(mutex) \
- { \
- struct semaphore __mutex = \
- __SEMAPHORE_INITIALIZER(*(mutex), 1); \
- *(mutex) = __mutex; \
- }
+# define nv_spinlock_t spinlock_t
#endif
+#define NV_INIT_MUTEX(mutex) sema_init(mutex, 1)
+
#if defined (KERNEL_2_4)
# define NV_IS_SUSER() suser()
# define NV_PCI_DEVICE_NAME(dev) ((dev)->name)
diff -Naur NVIDIA-Linux-x86-190.32-orig/usr/src/nv/os-interface.c NVIDIA-Linux-x86-190.32/usr/src/nv/os-interface.c
--- NVIDIA-Linux-x86-190.32-orig/usr/src/nv/os-interface.c 2009-09-02 11:54:48.000000000 +0100
+++ NVIDIA-Linux-x86-190.32/usr/src/nv/os-interface.c 2009-09-17 21:05:45.000000000 +0100
@@ -108,11 +108,7 @@
{
nv_stack_t *sp;
struct completion completion;
-#if defined(CONFIG_PREEMPT_RT)
- raw_spinlock_t lock;
-#else
- spinlock_t lock;
-#endif
+ nv_spinlock_t lock;
S032 count;
} os_sema_t;
@@ -148,7 +144,7 @@
os_sema = (os_sema_t *)*ppSema;
os_sema->sp = sp;
init_completion(&os_sema->completion);
- spin_lock_init(&os_sema->lock);
+ nv_spin_lock_init(&os_sema->lock);
os_sema->count = 1;
if (nv_os_smp_barrier_init())
@@ -199,18 +195,18 @@
os_sema_t *os_sema = (os_sema_t *)pSema;
unsigned long old_irq;
- spin_lock_irqsave(&os_sema->lock, old_irq);
+ nv_spin_lock_irqsave(&os_sema->lock, old_irq);
if (os_sema->count <= 0)
{
os_sema->count--;
- spin_unlock_irqrestore(&os_sema->lock, old_irq);
+ nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
wait_for_completion(&os_sema->completion);
}
else
{
os_sema->count--;
rm_disable_interrupts(os_sema->sp);
- spin_unlock_irqrestore(&os_sema->lock, old_irq);
+ nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
}
return RM_OK;
@@ -233,17 +229,17 @@
os_sema_t *os_sema = (os_sema_t *)pSema;
unsigned long old_irq;
- spin_lock_irqsave(&os_sema->lock, old_irq);
+ nv_spin_lock_irqsave(&os_sema->lock, old_irq);
if (os_sema->count <= 0)
{
- spin_unlock_irqrestore(&os_sema->lock, old_irq);
+ nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
return RM_ERROR;
}
else
{
os_sema->count--;
rm_disable_interrupts(os_sema->sp);
- spin_unlock_irqrestore(&os_sema->lock, old_irq);
+ nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
return RM_OK;
}
@@ -267,7 +263,7 @@
unsigned long old_irq;
BOOL doWakeup;
- spin_lock_irqsave(&os_sema->lock, old_irq);
+ nv_spin_lock_irqsave(&os_sema->lock, old_irq);
if (os_sema->count < 0)
{
doWakeup = TRUE;
@@ -278,7 +274,7 @@
rm_enable_interrupts(os_sema->sp);
}
os_sema->count++;
- spin_unlock_irqrestore(&os_sema->lock, old_irq);
+ nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
if (doWakeup)
complete(&os_sema->completion);
@@ -1383,7 +1379,7 @@
unsigned long oldIrql;
os_sema = (os_sema_t *) pSema;
- spin_lock_irqsave(&os_sema->lock, oldIrql);
+ nv_spin_lock_irqsave(&os_sema->lock, oldIrql);
return oldIrql;
}
@@ -1394,7 +1390,7 @@
unsigned long old_irq = (unsigned long) oldIrql;
os_sema = (os_sema_t *) pSema;
- spin_unlock_irqrestore(&os_sema->lock, old_irq);
+ nv_spin_unlock_irqrestore(&os_sema->lock, old_irq);
}
RM_STATUS NV_API_CALL os_get_address_space_info(Si riferisce alla versione beta dei driver (192.32) quindi è necessario scaricarli dal sito ufficiale (ATTENZIONE: come già detto è solo una versione beta… maneggiare con cura ;) ).
Il secondo passo è quello di estrarre i sorgenti, per fare ciò utilizzare l’opzione ‘-x’:
$ sh NVIDIA-Linux-x86-190.32-pkg1.run -x
Che dovrebbe aver creato una cartella omonima (senza il .run). Ora creiamo una copia (non si sa mai):
$ cp -r NVIDIA-Linux-x86-190.32-pkg1 NVIDIA-Linux-x86-190.32-orig
Nel mio caso ho salvato la suddetta patch come ‘patch-2.6.31-nvidia-192.32-rt.patch’ nella stessa cartella di quella estratta prima (es. se ho estratto la cartella dei driver in ‘Downloads/NVIDIA-Linux-x86-190.32-orig’ il percorso della patch dovrà essere ‘Downloads/patch-2.6.31-nvidia-192.32-rt.patch’).
L’ultimo passo è quello di applicare la patch (alla vecchia maniera):
$ cat patch-2.6.31-nvidia-192.32-rt.patch | patch -p0
Il cui output dovrebbe essere qualcosa tipo:
patching file NVIDIA-Linux-x86-190.32-orig/usr/src/nv/nv-linux.h patching file NVIDIA-Linux-x86-190.32-orig/usr/src/nv/os-interface.c
Se così non fosse, significherebbe che avete sbagliato qualcosa, perciò ripetete il procedimento da capo.
Ed ora possiamo tranquillamente installare i driver (dopo aver terminato Xorg):
$ sudo NVIDIA-Linux-x86-190.32-orig/nvidia-installer
Questo è tutto, dopo aver installato i driver è ovviamente necessario configurare Xorg, ma questa è un’altra storia, su interenet potete trovare pagine e pagine a riguardo.
]]>SoX (Sound eXchange) è uno strumento multipiattaforma di manipolazione di file audio. Con esso è possibile convertire e modificare (cambiare attributi, aggiungere effetti, ecc…) oltre 20 diversi formati audio.
Per una lista dei formati supportati, completa di informazioni:
$ sox --help-format all
SoX mette a disposizioni alcune semplici funzioni di sintetizzazione (o creazione) di file audio.
$ sox -n synth [lunghezza] [tipo] [frequenza]
Dove:
Un esempio può essere:
$ sox -r 16000 -n out.wav synth 5 triangle 300-3000
(NOTA: -r indica il sample rate e -n il file di output. È possibile utilizzare il formato preferito tra quelli disponibili)
SoX è molto utile nella conversione di file audio in diversi formati. Può individuare il formato dei file (sia in input che output) semplicemente dall’estensione del file stesso.
$ sox input.wav output.dat
Ma è anche possibile indicare i formati desiderati tramite l’opzione ‘-t’:
$ sox -t wav input -t dat output
Grazie a SoX è anche possibile aumentare o diminuire il volume di un file. Ad esempio, per aumentare:
$ sox -v 5.0 file.wav
Mentre per diminuire
$ sox -v -0.5 file.wav
Grazie all’opzione ‘-m’ è possibile combinare (o mixare) due file in uno unico
$ sox -m file1.wav file2.wav output.wav
In alternativa è anche disponibile il comando ’soxmix’
$ soxmix file1.wav file2.wav output.wav
L’opzione ‘trim’ serve a estrarre una data parte di file.
sox input.wav output.wav trim [inizio] [durata]
Dove:
Ad esempio:
sox input.wav output.wav trim 5 10
Estrae 10 secondi da inut.wav partendo dal quinto secondo.
Per aumentrae la velocità di un file audio è sufficiente utilizzare l’effetto ’speed’, indicando il fattore di “accellerazione”. Aumentando la velocità, automaticamente sarà ridotta la durata.
sox input.wav output.wav speed [fattore]
Ad esempio utilizzando un fattore di 2, la velocità viene raddoppiata, mentre la durata si dimezza.
È possibile aggiungere un effetto di fade-in e fade-out ad un file
$ sox input.wav output.wav fade [tipo] [lunghezza fade-in] [tempo di stop] [lunghezza fade-out]
Dove:
Dopo aver creato/modificato un file è anche possibile eseguirlo:
$ sox input.wav -t alsa
Oppure:
$ play input.wav
Questi sono solo alcune (diciamo le principali) delle innumerevoli funzionalità di SoX. Per ottenere un lista (completa di opzioni) di tutti gli effetti disponibili:
$ sox --help-effect all
Oltre che naturalmente
$ man sox
Le API sono diventate una caratteristica comune di molte delle applicazioni web più utilizzate (Twitter, Last.fm, YouTube, ecc…) in particolare le API REST (o RESTful). È in effetti davvero molto facile creare un’API di questo tipo, e allo stesso modo, e davvero molto facile implementarla in un programma di qualsiasi tipo e in qualsiasi linguaggio.
Prima di iniziare a buttare giù del codice è meglio forse fare un pò di chiarezza su cosa si intenda con la parola REST.
Innanzitutto è necessario dire che REST non è una prerogativa solamente delle API, si tratta più che altro di un concetto generale che si può applicare a diversi campi. Ma ovviamente, visto il titolo dell’articolo, ci occuperemo solo del campo delle API.
Come è facile intuire tutti i tipi di API hanno bisogno di accettare richieste da parte di client esterni. Facciamo finta (o anche no dipende dai casi) che voi abbiate la necessità di fornire un’API agli utenti del vostro sito, riguardante ad esempio l’inserimento di articoli sul sito. Normalmente in un’API RESTful è fornito un URL per accedere a tale API, nel nostro caso potrebbe essere qualcosa tipo /api/articoli o anche /api/articoli/[id] a seconda delle funzionalità che vogliamo fornire.
Innanzitutto è necessario decidere quali funzioni vogliamo implementare, ovvero quali funzioni vogliamo rendere disponibili agli utenti attraverso le API. Parlando di articoli alcune funzioni base potrebbero essere quelle di visualizzazione, creazione, modifica e eliminazione di articoli. Successivamente è necessario creare una sorta di architettura per definire il metodo di accesso dell’utente alle funzionalità che gli metteremo a disposizione. In questo, REST semplifica di molto la vita allo sviluppatore, in quanto utilizzando i metodi messi a disposizione da HTTP (GET, POST, PUT e DELETE), non è necessario inventarsi nulla di nuovo (ovvero un sacco di lavoro risparmiato). Per rendere più chiara questa idea è possibile associare ad ognuno di questi metodi un’azione specifica: GET -> mostra, POST -> crea, PUT -> aggiorna e DELETE -> elimina. Mettendo questo, insieme alle cose dette prima riguardo gli URL, possiamo riassumere il tutto così:
Come potete constatare, REST ha risolto in modo molto semplice un problema molto grosso.
Dopo aver visto come accettare richieste dai client, è ora necessario vedere in che modo inviare a questi client i dati che si aspettano di ricevere.
Una risposta tendenzialmente è formata da due parti, un codice di stato e il corpo vero e proprio contenente tutti i dati. Quest’ultima parte è abbastanza semplice da implementare. Innanzitutto è necessario decidere il formato di risposta in modo che tutti i client possano comprenderla; i più utilizzati sono essenzialmente XML e JSON (ma è possibile utilizzare anche RSS, tutto dipende da che tipo di dato è richiesto). Personalmente preferisco JSON, in quanto è molto facile lavorarci sia con Javascript che con PHP, ma se volete creare un’API veramente “robusta” potete anche implementare entrambi. L’utente dovrà solo dichiarare il formato voluto impostando il campo ‘Accept’ nell’header HTTP (es. ”Accept: application/xml”) oppure, pratica più utilizzata, impostando un estensione all’URL dell’API (es. “/api/articoli/[id].xml”).
Ed ora veniamo alla seconda parte, ovvero i codici di stato. Questi codici servono semplicemente ad informare il client riguardo lo stato delle loro richieste. Anche in questo caso REST e HTTP ci tornano molto utili in quanto possiamo semplicemente utilizzare codici di stato già definiti nelle specifiche di HTTP. La cosa bella di questa soluzione è che non è necessario inventarsi nulla di nuovo, il che si traduce in un altro sacco di lavoro risparmiato. Per esempio nel caso che ci sia un errore nella formulazione della richiesta da parte del client possiamo utilizzare il codice 400 (”Bad Request”), in caso di successo nella creazione di un articolo il codice 201 (”Created”) o ancora in caso di richiesta di un articolo inesistente il codice 404 (”Not Found”). Questi sono solo alcuni esempi, esistono molti altri codici e molte altre possibilità, a seconda del tipo di API che volete creare.
Credo che a questo punto sia chiaro a tutti quali siano i vantaggi che REST offre agli sviluppatori, in particolare quanto riesca a semplificare la vita a tutti (sia a chi si occupa di creare l’AP, sia a chi la utilizza) facendo rispiarmiare tempo e fatica.
]]>#!/bin/sh for filename in /tmp/* do echo $filename done;
Poche righe che mi sono spesso tornate molto utili. Ad esempio mi è capitato di dover convertire una serie di file wav (circa 80) in mp3. A mano risulta un lavoro immane, ma semplicemente sostituendo ‘echo’ con ‘lame’ nello script precedente ecco che qualsiasi cosa diventa possibile.
]]>