JDownloader: Could not initialize NSS

Se usate JDownloader sotto Debian o Ubuntu con Java 6, dopo un dist-upgrade di questi giorni puo' capitare che non si riesca piu' a farlo partire.

Se proviamo a farlo partire da riga di comando otteniamo questo errore:
Exception in thread "AWT-EventQueue-0" java.security.ProviderException: Could not initialize NSS


e, piu' in basso, possiamo notare questa interessante riga:
Caused by: java.io.FileNotFoundException: /usr/lib/libnss3.so


Evidentemente, a causa di un bug, java non riesce piu' a trovare la libreria /usr/lib/libnss3.so, che in effetti non risulta essere in quella cartella.

La soluzione e' all'interno del file /etc/java-6-openjdk/security/nss.cfg, ma prima dobbiamo controllare in quale cartella e' contenuta la libreria che cerchiamo (puo' variare a seconda della distro linux).


Apriamo una finestra di terminale e digitiamo
locate libnss3.so


io, ad esempio, ho ottenuto questo risultato:
/usr/lib/firefox/libnss3.so
/usr/lib/i386-linux-gnu/libnss3.so
/usr/lib/i386-linux-gnu/libnss3.so.1d


e' evidente che, nel mio caso,  il percorso che mi interessa e' il secondo, quindi lo selezioniamo e lo copiamo.


Ora possiamo andare a modificare il file nss.cfg, ma prima creiamo una copia di sicurezza:
sudo cp /etc/java-6-openjdk/security/nss.cfg /etc/java-6-openjdk/security/nss.cfg.old


quindi possiamo editarlo con
gksu gedit /etc/java-6-openjdk/security/nss.cfg


la riga che ci interessa e' questa
nssLibraryDirectory = /usr/lib/

che io ho sostituito con

nssLibraryDirectory = /usr/lib/i386-linux-gnu/

e che voi sostituirete indicando il percorso copiato prima (senza la parte finale "libnss3.so", a noi interessa solo indicare il percorso dove trovarlo).

Salvate nss.cfg e lanciate JDownloader, che riprendera' a funzionare.

Server samba e link simbolici scomparsi in LAN

Un giorno mi sveglio e su Ubuntu 10.10 trovo un nuovo problema: accedendo ad una cartella condivisa col server samba, non vengono più visualizzati i link simbolici (o symlink).


Cercando un po' in giro apprendo che il problema è stato riscontrato su server Debian e Ubuntu, con client Leopard e SnowLeopard, e che presumibilmente il problema riguarderà anche altre distribuzioni di Linux.


Tranquilli, la soluzione è semplice, richiede una piccola modifica alla configurazione del server samba:

• Editate smb.conf, ad esempio digitando da terminale

          gksu gedit /etc/samba/smb.conf

• Nella sezione desiderata (o in “[global]”) aggiungete queste righe, o verificatene i valori:

          follow symlinks = yes
          wide links = yes
          unix extensions = no

• Salvate smb.conf
• Riavviate il server samba, digitando da terminale

          sudo service smbd restart

Fatto. Come per incanto, i link simbolici riappariranno nelle vostre cartelle condivise.

Ubuntu - Riconnettersi con VNC a vino dopo un riavvio da remoto

Il problema si verifica in combinazione con il login automatico: dopo un riavvio da remoto, non è più possibile riconnettersi a vino.

Questo succede perche' il portachiavi (keyring) di Gnome non viene avviato in modo automatico, e se non c'e' nessuno davanti al pc remoto a digitare la password, possiamo scordarci di riuscire a controllarlo nuovamente.

In attesa che questo bug venga corretto nelle nuove versioni di Ubuntu, possiamo usare un workaround che consiste nel non usare il portachiavi di Gnome per registrare la password di vino.

• aprite Sistema / Preferenze / Password e chiavi di cifratura
• sotto "Password: login", cliccate col tasto destro su "vino.local:5900" ed eliminatelo
• chiudete la finestra
• da riga di comando, digitate gconf-editor
• navigate in desktop / gnome / remote_access
• doppio click su vnc_password, nella finestra che appare inserite la password codificata in Base64, per convertirla potete usare questo sito
• chiudete gconf-editor
• riavviate il pc

Ecco fatto: ora, anche dopo un riavvio, potrete riconnettervi tranquillamente al vostro pc remoto.