Visualizzazione post con etichetta baco. Mostra tutti i post
Visualizzazione post con etichetta baco. Mostra tutti i post

13 settembre 2012

Linux: il terrore scorre sul filo di...

xinput!
Programma di utilità che permette di monitorare la tastiera su X e che essendo disponibile per tutti gli utenti (e non solo per root) può essere lanciato da chiunque per monitorare anche l'input di password di root su qualunque console aperta sotto X(.org)!

Continua...

21 febbraio 2011

Calc, OpenOffice.org e l'annoso problema delle righe da ripetere in stampa

Da più di un anno un noiosissimo bug in Calc di OpenOffice.org mi rendeva la vita difficile nel produrre elenchi formattati: l'impossibilità di impostare le righe da ripetere su ogni foglio in stampa.
Andando alla funzione Formato -> Aree di stampa -> Modifica, nella casella Riga da ripetere sia digitando manualmente i valori che  selezionando la riga del foglio da stampare tramite l'apposito tasto posto all'estrema desta, il risultato era sempre lo stesso: cliccando sul tasto Ok si otteneva sempre il messaggio Riferimento foglio non valido.
Più di una volta ho cercato si Google senza trovare nulla, ma oggi mi sono imbattuto in un post sul forum di OpenOffice.org che mi ha risolto una volta e per sempre il problema! In soldoni, come riporta l'utente sbaturzio:
Allora: ho risolto facendo così:
* Menu -> Strumenti -> Opzioni -> OpenOffice.org Calc->Formula
* Attivo Usa nomi di funzione Inglesi

* premo Ok
Da questo momento in avanti la funzionalità Riga da ripetere lavora correttamente senza errori.
Posso anche riportare la checkbox Usa nomi di funzione Inglesi allo stato originale senza che Riga da ripetere torni a dare errori.
Posso testimoniare che la cosa ha funzionato anche sul mio OpenOffice.org 3.2.1 (OOO320m15 (Build:9492) 3.2.1.4).
Powered by ScribeFire.

Continua...

19 ottobre 2010

InAcceptabile comportamento di IE[5-8]

Un utente si lamentava che una delle nuove funzionalità di OPTA, viste in funzione sul mio PC, non funzionavano correttamente. Alla richiesta di visionare l'elenco dell'organico, invece di aprire la pagina con l'elenco, veniva sempre ed inesorabilmente scaricato l'elenco in formato CSV (opzione presente con un link nella pagina, assieme a quello analogo per ottenerlo come PDF).
click to enlarge
Inizio l'indagine constatando che la segnalazione proveniva da un'utente che usa IE8 (su Windows, of course), mentre con Firefox 3.6 (su Linux, obviously) tutto andava liscio come l'olio. Provo immediatamente con Firefox e con Chrome anche su Windows, ma lo strano comportamento non si presenta e l'elenco si visualizza correttamente.
Collego subito il problema con la gestione della respond_to del controller Rails relativo alla pagina: il codice, però, è scritto correttamente e poi: perché scarica proprio il CSV e non PDF?
Cerco un po' di documentazione in giro, mentre nel controller disabilito la gestione del formato CSV e faccio una nuova prova. Magicamente IE8 si comporta di nuovo normalmente. Mi risulta naturale cercare un tool (su Windows) per visionare le request inviata da IE8 al server. Trovo l'ottimo Fiddler (che potete vedere, figura precedente, nella parte alta della schermata).
Usandolo, noto come IE8 invii, nell'intestazione Accept, una marea di formati, fra cui application/vnd.ms-excel. Sembro essere sulla buona strada: ripristino la gestione del file CSV nel controller Rails e con l'aiuto di Fiddler forgio una request in cui elimino la voce application/vnd.ms-excel. Ora anche in IE8 ottengo l'elenco in formato HTML, come ci si sarebbe aspettato che fosse fin dall'inizio.
Nel frattempo le ricerche su internet mi avevano portato a questo articolo, Unacceptable Browser HTTP Accept Headers (Yes, You Safari and Internet Explorer) che mi apre la mente: la mia applicazione in Rails serve ad IE8 sempre prima il fomato CSV, semplicemente perché IE8 non invia il MIME-type text/html nell'Accept (provare per credere)!
Ulteriore conferma la ebbi leggendo il post Ruby on Rails and IE 8 - respond_to and HTTP accept headers.
Per la soluzione ho quindi inserito il seguente codice nelle viste Rails, al momento di creare il link:
par.merge!({:format => :html}) if request.env['HTTP_USER_AGENT'] =~ /MSIE/
dove par è l'hash utilizzato per la creazione dell'URI. In questo modo, per IE8 si forza esplicitamente il formato (HTML) richiesto, postponendo .html all'URI standard generato con Rails.
Powered by ScribeFire.

Continua...

19 febbraio 2010

CUPS 1.4.1 ed un baco malefico risolto

Con CUPS 1.4.1 ho avuto modo di imbattermi in un malefico bug con le stampanti condivise con SaMBa.
Il baco consiste nella richiesta continua delle credenziali per l'accesso alla stampante, anche se si è configurato correttamente l'accesso ad un dominio Windows da GNU/Linux.
Questo baco, molto sottile consiste nel fatto che CUPS 1.4.1 imposta (e reimposta dopo ogni stampa), nel file /etc/cups/printers.conf  l'attributo
AuthInfoRequired username,password

La soluzione al problema consiste nel commentare nel file tal riga e nel rendere tale file non modificabile: a tal fine non basta usare
[me@mybox]# chmod a-x /etc/cups/printers.conf
, in quanto CUPS riesce a reimpostare anche tali permessi, ma usare il meno noto (almeno a me)
[me@mybox]# chattr -i /etc/cups/printers.conf

Ecco di seguito tutto quello che c'è da fare:
[me@mybox]$ su
Password:
[me@mybox]# chattr -i /etc/cups/printers.conf
[me@mybox]# /etc/init.d/cups stop
[me@mybox]# vim -i /etc/cups/printers.conf

editare il file, ad es.
<defaultprinter theprinter="">
#AuthInfoRequired username,password
...
# eliminare la password e l'username quando il baco di CUPS 1.4.1 sparira'
DeviceURI smb://me:mypwd@MYDOMAIN/windoze/theprinter
...
</defaultprinter>

e poi
[me@mybox]# chattr +i /etc/cups/printers.conf
[me@mybox]# /etc/init.d/cups start

Powered by ScribeFire.

Continua...