giovedì 27 marzo 2014

Utilizzare la chiavetta Sistri con Linux

Dopo anni di rinvi e proroghe il SISTRI, il Sistema di Controllo della Tracciabilità dei Rifiuti, è in fine entrato in vigore; per chi, come me, utilizza un o.s. Linux al lavoro si presenta quindi una nuova sfida, riuscire ad utilizzare la chiavetta usb ("token") con il pinguino.
Viene lecito chiedersi a cosa stavano pensando gli sviluppatori del Sistri mentre lavoravano alla versione per Linux (forse preferivano dedicare più tempo alla gestione di fondi neri che alla stesura del software ?), dal momento che per farla funzionare correttamente sono necessari diversi "tweaks".

Montiamo la chiavetta ed eccoci già di fronte alla prima difficoltà, sistri_linux non può essere eseguito perché di default i permessi di esecuzione su filesystem vfat sono inibiti. Non pensate di risolvere il problema con un chmod, è necessario impostare i permessi corretti in fase di mount del dispositivo. La cosa più comoda è quella di creare una voce ad hoc in /etc/fstab. Ecco cosa ho fatto per il mio token:
UUID=1098-B465          /mnt/sistri                     vfat    dmask=007,fmask=007,uid=1000,gid=1000,user,exec,noauto  0 0
Sostituite l'UUID con quello della della vostra chiavetta, per individuarlo date in un terminale:
 $ ls -l /dev/disk/by-uuid/
oppure
 # blkid
Verificate anche la correttezza di uid e gid per il vostro utente con:
$ echo "uid="$(id -u) && echo "gid="$(id -g)
Se provate ora a rimontare il token potrete notare che per tutti il file presenti è attivo il bit eseguibile:
$ find  /mnt/sistri/ -executable -type f
Possiamo a questo punto lanciare sistri_linux ... per renderci immediatamente conto che non funziona! Il programma sia avvia ma dopo pochi istanti restituisce questo errore: "Sono state riscontrate delle anomalie su questo dispositivo". L'unica anomalia acclarata è che (probabilmente a causa di un bug) sistri_linux non riesce a individuare il codice seriale del dispositivo e di conseguenza genera questo errore.

È comunque possibile bypassare facilmente questo problema con un semplice workaround: dimentichiamoci
di sistri_linux, spostiamoci in sistri/linux32. e lanciamo SistriTokenManager. Il software di gestione dovrebbe finalmente avviarsi correttamente senza riportare più messaggi di errore circa l'integrità del dispositivo.  Selezionando "Accedi al Sistema"  e immettendo le nostre credenziali di accesso siamo ora in grado di operare sul portale del Sistri.
Tutto a posto ? No, non ancora ... perché nel momento in cui tenterete di firmare i vostri movimenti riceverete questo nuovo messaggio: "Impossibile accedere al token".

Per correggere l'errore, è sufficiente copiare la cartella DigitalID sotto linux32, in questo modo:
$ mkdir -p /mnt/sistri/sistri/linux32/sistri/
$ cp -a /mnt/sistri/sistri/DigitalID/ /mnt/sistri/sistri/linux32/sistri/
Così facendo saremo in grado di firmare da Linux senza ulteriori noie.

La procedura qui descritta è stata testata su Fedora 20 & openSUSE 13.1, entrambi a 32 bit. La versione del software Sistri utilizzata è la 2.0.5, l'ultima attualmente disponibile (se sulla vostra chiavetta è installata una versione precedente, aggiornate il prima possibile).
Vi suggerisco caldamente di effettuare un backup completo della intera chiavetta prima di effettuare qualunque operazione indicata in questa guida. Comandi errate e modifiche inopportune possono rendere il token del tutto inutilizzabile; è quindi assolutamente necessario prestare la massima attenzione.

Update del 10/07/14
Dopo gli ultimi aggiornamenti usciti nel frattempo, il software Sistri funziona ora anche sotto Linux "out of the box" e pertanto le istruzioni esposte nella guida non sono più necessarie e non vanno più eseguite.
Resta solamente valido l'accorgimento di montare il token con i parametri indicati all'inizio del post. Senza di questi, come già spiegato, non sarete in grado di lanciare i file eseguibili.

giovedì 20 febbraio 2014

Installare DraftSight su Fedora 20

Per gli utenti Fedora installare DraftSight non è mai una cosa banale, tra conflitti con altri pacchetti e dipendenze mancanti.
In questa breve guida vi illustrerò come "correggere" con pochi semplicissimi passaggi, utilizzando rpmrebuild, l'rpm di DraftSight in modo da avere un pacchetto facilmente installabile e funzionante al 100%.

Preleviamo l'ultima versione di DraftSight disponibile alla data in cui sto scrivendo (20/02/14)
wget http://dl-ak.solidworks.com/nonsecure/draftsight/V1R5.0/draftSight.rpm 
Installiamo rpmrebuild:
# yum install rpmrebuild
Avviamo le attività di modifica del pacchetto con:
$ rpmrebuild -pe draftSight.rpm
rpmrebuild utilizza di default come editor vi, se lo desideriamo possiamo specificare un programma diverso tramite il parametro EDITOR. Ad esempio, ipotizzando di volere usare nano, daremo:
$ EDITOR=/usr/bin/nano rpmrebuild -pe draftSight.rpm
Ora cerchiamo ed eliminiamo queste due linee (così da risolvere i problemi di conflitto con altri pacchetti)
%dir %attr(0755, root, root) "/"
%dir %attr(0755, root, root) "/opt"
Individuiamo poi la sezione che contiene una lunga serie di istruzioni Requires e aggiungiamo queste altre righe (ovvero aggiungiamo le dipendenze necessarie mancanti)
Requires:       libaudio.so.2
Requires:       libGL.so.1
Requires:       libXrender.so.1
Requires:       libfontconfig.so.1
Requires:       libGLU.so.1
Salviamo le modifiche effettuate e usciamo dall'editor; rispondiamo poi "y" alla richiesta se continuare o meno.
Dopo qualche instante rpmrebuild terminerà la ricostruzione del pacchetto che verrà salvato in $HOME/rpmbuild/RPMS/i386
Potremo quindi procedere con l'installazione tramite il classico yum install e se tutto é stato fatto correttamente l'installazione andrà a buon fine senza alcun errore.
DraftSight per Fedora viene fornito esclusivamente in versione 32 bit; dovremo pertanto utilizzare questo pacchetto anche se siamo su un sistema a 64 bit.
Gli impazienti possono scaricare direttamente il pacchetto prodotto seguendo le istruzioni di questa guida da qui

lunedì 10 febbraio 2014

Chiusura del repository darkhado_pipelight

A partire da oggi il repository darkhado_pipelight, che forniva pipelight per Fedora 20, non è più attivo.
Il repo è di fatto divenuto inutile, dal momento che l'upstream fornisce ora ufficialmente anche i pacchetti per Fedora.
Invito chi ancora faceva uso del mio repo a rimuoverlo ed a installare pipelight seguendo queste istruzioni