Michele Bologna

Tag: macos

  • Come eliminare iDisk dalla sidebar del Finder di OSX

    La sidebar del Finder di OSX mi è molto utile: inserisco i cosiddetti “bookmark” per raggiungere velocemente risorse o directory sul mio file-system che mi sono utili.

    Un bookmark scomodo che è presente nella mia sidebar è quello di iDisk. Perché scomodo? Non essendo abbonato a MobileMe, il servizio iDisk è inutile per me. Come fare a togliere il bookmark dalla sidebar?

    Il procedimento è molto semplice:

    • In una finestra qualsiasi del Finder, aprite le preferenze (shortcut: ⌘+ ,)
    • Andate alla scheda “Sidebar”
    • Deselezionate iDisk

    Chiudete e voilà, l’icona di iDisk non è più presente tra i bookmark della sidebar!

  • Perché il mio prossimo schermo non sarà un Apple Cinema Display

    Prima della fine del 2009 sono passato a Mac: la mia scelta è ricaduta su un notebook, in particolare sul MacBook Pro 13′; 13′ perché volevo un notebook portatile, e non un trasportabile da 15′ (o peggio, superiori). Non c’è che dire: dal punto di vista hardware, i componenti e le tecnologie utilizzate sono il top di gamma. Dal punto di vista software, ancora meglio: OSX è il miglior sistema operativo che io abbia mai usato (ok ok, Linux è arrivato secondo per un soffio).

    Durante l’utilizzo, l’unico difetto di cui mi sono accorto è un dead pixel nella parte sinistra dello schermo; il difetto è fastidioso e non ci sono cure, se non sostituire interamente il pannello LCD. Tutto sommato, l’esperienza con Mac è stata delle migliori e sicuramente il mio prossimo computer sarà di nuovo un Mac.

    Oltre che essere uno switcher per quanto riguarda il PC, sempre verso la fine del 2009 sono passato da Nokia ad iPhone: finalmente un telefono che funziona! Il mio vecchio Nokia E65 era un buon telefono, ma confrontato con iPhone ne esce sconfitto su tutti i fronti: utilizzo in WiFi, applicazioni, facilità d’uso (spesso quando utilizzo altri telefoni mi ritrovo a premere sullo schermo, per poi realizzare che non sono touch).

    Anche in questo caso l’esperienza con iPhone è più che positiva, e senz’altro il mio prossimo telefono sarà di nuovo un iPhone; su iPhone ho riscontrato lo stesso difetto che ho riscontrato per il Mac, ovvero un dead pixel. Ho subito chiamato l’assistenza tecnica e il mio telefono è stato sostituito con un telefono rigenerato (“come nuovo”) che non presenta il problema.

    Il prossimo acquisto che vorrei fare è uno schermo esterno per il MacBook Pro, da tenere a casa o in ufficio. La scelta ideale sarebbe Apple Cinema Display, un “compagno” ideale grazie alle sue funzionalità (MagSafe, DisplayPort nativa, etc.). Tuttavia non comprerò un Apple Cinema Display sostanzialmente perché non vorrei ritrovarmi (di nuovo) nella situazione di avere un dead pixel su un prodotto di fascia alta (come tutti i prodotti Apple). Non ho ancora deciso il modello che comprerò, ma ho già deciso i brand su cui mi concentrerò: Samsung, LG e Philips.

    Concludo ripetendo che la mia esperienza con i prodotti Apple è più che positiva, nonostante su due prodotti acquistati io abbia trovato due dead pixels. L’esperienza, in ogni caso, è [quasi] ottima: nei prossimi prodotti Apple che acquisterò spero che non ci siano altri dead pixels!

  • Configurare una VPN IPsec Cisco con il client integrato di OSX Snow Leopard e iPhone

    A volte mi capita di dovermi connettere a qualche rete che utilizza un concentratore enterprise VPN di Cisco usando il sistema operativo OSX (o da iPhone); in teoria dovrei utilizzare il client VPN di Cisco, ma da OSX Snow Leopard è presente un client integrato che permette di accedere alle reti VPN di Cisco che utilizzano IPsec, senza necessità di installare software aggiuntivo.

    In questo post vi spiegherò come fare il setup di una connessione VPN con Group Secret usando il client integrato di OSX. Nel caso utilizziate i certificati, il procedimento è ancora più semplice: basterà inserire il file dei certificati al posto del GroupName e del GroupSecret più avanti.

    Il requisito fondamentale di questo metodo è di avere a disposizione i parametri di connessione della VPN; in alternativa, è necessario avere a disposizione il file di configurazione (file che hanno estensione .pcf, di solito sono distribuiti dall’organizzazione che eroga il servizio VPN insieme al client VPN di Cisco).

    Procediamo passo-passo:

    1. Innanzitutto apriamo le impostazioni di sistema, poi andiamo su “Rete” e aggiungiamo una nuova connessione.
    2. Selezioniamo l’interfaccia VPN, il tipo Cisco IPsec e assegniamo un nome qualsiasi alla connessione e diamo OK.
    3. Apriamo con un editor (ad es. Textmate o Textedit) il file di configurazione con estensione pcf.
    4. Ora dovremo identificare nel file pcf i parametri che ci servono per la VPN:
      • Host=1.2.3.4. Indirizzo IP per la connessione (in questo caso 1.2.3.4). Inseriamolo nel primo campo, “Indirizzo del server remoto”
      • GroupName=mygroup. Il nome del gruppo VPN da inserire sotto “Impostazioni di autenticazione”
      • enc_GroupPwd=<stringa di caratteri>. Questa è il “Group secret”, ovvero la password condivisa del gruppo. La password è però cifrata, quindi avete due possibilità: richiedere la password in chiaro a chi fornisce il servizio VPN. Oppure, cercare su Internet un modo per decifrarla. Una volta ottenuta la password decifrata, inseritela nel campo “Group secret”, sempre sotto “Impostazioni di autenticazione”

      Riassumendo, nel caso di esempio siamo arrivati alla situazione descritta dalle figure a lato.

    5. Inseriamo username e password per la VPN, se necessario, e infine clicchiamo su Connect.

    La VPN sarà instaurata e potremo accedere alla rete protetta.

    Nel caso di iPhone il procedimento è simile: il menu di configurazione della VPN lo trovate sotto Impostazioni > Generale > VPN.

    Nel caso in cui riscontriate qualche problema, segnalatelo nei commenti!

  • MacOSX: come risolvere il problema dei fonts in Google Reader

    Da un po’ di tempo ho uno strano problema con Google Reader: la visualizzazione dei post in modalità “list view” ha problemi di visualizzazione, una sorta di sbavatura dei fonts che potete vedere nell’immagine a lato.

    Innanzitutto ho verificato che il problema risiedeva sul mio Mac:

    • Provando con Chrome e Firefox, il problema si ripresentava
    • Aumentando/diminuendo la dimensione dei fonts il problema scompariva

    Quindi mi sono messo alla ricerca di una soluzione online, e dopo spulciato forum e soluzioni alternative, riporto la soluzione che ha funzionato per il mio caso e che, di conseguenza, consiglio:

    • Aprite Font Book che si trova in /Applications (o usate Spotlight: ⌘+␣ e digitate “Font Book” );
    • Nella colonna “Collection”, selezionate tutti i fonts (⌘+A);
    • Dal menu “Edit”, selezionate “Resolv Duplicates”;
    • Riavviate OSX

    Con questo procedimento si resettano i font duplicati che creano una scorretta visualizzazione dell’aspetto di Google Reader. Una volta riavviato il sistema, riaprite Google Reader con il vostro browser preferito e finalmente non ci saranno più sbavature di fonts. Se invece il problema non si è risolto, lasciate pure un commento.

  • Creare un tunnel ssh dinamico con openssh (Linux, MacOSX, *BSD, UNIX-based OSes) e relativo use-case per Firefox

    Un po’ di tempo fa vi avevo spiegato come creare un tunnel ssh usando PuTTY, il client ssh per eccellenza su Windows.
    Ora, visto che ci siamo evoluti e siamo passati ad un sistema operativo che si basa su UNIX (come ad esempio Linux, MacOSX, Solaris, *BSD, o comunque una qualsiasi piattaforma che supporti openssh), vi spiegherò come creare un tunnel ssh usando questi sistemi operativi.

    Anche qui dobbiamo prima verificare due requisiti fondamentali:

    • di avere installato sulla macchina client (quella che deve usufruire del tunnel) openssh
    • di avere a disposizione una macchina server che metta a disposizione accesso ssh (openssh-server), che sia raggiungibile sulla porta 22/tcp (o se l’avete cambiata sapete anche su quale porta deve essere raggiungibile) e su cui abbiate utenza.

    Se avete bisogno di un tunnel ssh sono certo che sappiate come mettere in piedi queste due cose, e che sappiate già perché vi serve un tunnel ssh.

    Bene, continuiamo. Apriamo un terminale e digitiamo: ssh -D 31337 -f -C -q -N user@remoteserver

    dove user@remoteserver è il server che mette a disposizione l’accesso ssh e su cui abbiamo utenza con utente user. Vi sarà richiesto di inserire la password per l’utente user, inseritela e il tunnel verrà creato [se avete impostato l’accesso tramite chiavi asimmetriche, non dovrete digitare alcuna password].

    Veniamo alla spiegazione dei vari parametri, in modo che possiate customizzare il comportamento del tunnel:

    • -D 31337: imposta un tunnel che faccia il forward verso un indirizzo dinamico, impostato sulla porta specificata come argomento (in questo caso 31337/tcp)
    • -f: forza ssh ad andare in background dopo che abbiamo effettuato il login correttamente
    • -C: abilita la compressione
    • -q: disabilita gli warning dall’output
    • -N: non eseguire alcun comando remoto (visto che dobbiamo solo creare un tunnel)

    La creazione del tunnel è finita! Il vostro tunnel è attivo su localhost:31337 e se avete impostato tutto con criterio potete iniziare ad utilizzarlo.

    Un use-case interessante è configurare il browser Firefox per la navigazione facendo in modo che tutto il traffico sia routato attraverso il tunnel appena creato. Apriamo Firefox e digitiamo about:config nella barra dell’indirizzo. Digitate proxy nella barra del filtro, e vi comparirà la seguente schermata:

    Le voci a cui siamo interessati sono quelle marchiate da un bollino rosso, e dobbiamo modificarle a:

    • network.proxy.no_proxies_on : localhost, 127.0.0.1
    • network.proxy.socks : 127.0.0.1
    • network.proxy.socks_port : 31337. Questa opzione, come avete capito, specifica la porta su cui è attivo il tunnel
    • network.proxy.socks.remote_dns : true. Questa opzione è la più importante, perché permette di fare il forward delle richieste DNS all’host remoto. Consiglio di abilitarla.
    • network.proxy.socks_version : 5
    • network.proxy.type : 1. Questa opzione specifica se utilizzare le impostazioni appena definite per il tunnel (= 1) oppure no (= 0).

    Ora il test finale: usando Firefox controllate quale sia il vostro indirizzo IP. Se vi compare l’indirizzo del vostro server remoto, allora il tunnel funziona alla perfezione. Viceversa, c’è qualcosa di sbagliato nella vostra configurazione; ripartite dall’inizio e controllate che tutto sia configurato correttamente.

  • Come impostare ssh in modo che non richieda la password di accesso (chiavi asimmetriche per il login)

    Alcuni client ssh permettono di definire “sessioni salvate” di connessioni in modo che username e password vengano salvati e non vengano richiesti ad ogni connessione verso un host. Trovo che permettere all’utente di poter salvare la password sia profondamente sbagliato dal punto di vista della security, soprattutto se l’utente ha privilegi non indifferenti sulla macchina remota [ad esempio è nei sudoers].

    Detto questo, trovo anche che sia abbastanza noioso inserire la propria password ad ogni connessione. Ma non disperate: il meccanismo standard per risparmiarvi preziosi secondi esiste e ve lo spiegherò tra poco. Inoltre, il meccanismo standard è sicuro di per sé e non indebolisce la struttura di ssh perché utilizza un’autenticazione basata sulla crittografia asimmetrica.

    Innanzitutto: queste istruzioni sono per Linux e OSX. In futuro posterò anche le istruzioni per Windows/PuTTY.

    Obiettivo: loggarsi dalla macchina locale (local) alla macchina remota (remote) senza inserire la password

    Sulla macchina locale: generare le chiavi di autenticazione [1/2]

    Le chiavi di autenticazione sono composte da 2 chiavi, una pubblica e una privata. La chiave pubblica rappresenta la nostra identità nel mondo esterno. La chiave privata, invece, rappresenta la nostra chiave segreta, la nostra “password” [anche se è molto più lunga di una password].

    Per generare le chiavi bisogna dare questo comando:
    local$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/mbologna/.ssh/id_rsa):
    Accettate il path che vi viene proposto premendo Invio
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Vi consiglio fortemente di inserire una password a questo punto. Nonostante molte persone consiglino (sbagliando) di non inserire una password perché si ripeterebbe il problema di dover inserire una password, vi posso assicurare che impostare un ulteriore livello di sicurezza per poter accedere ad un file così delicato come la vostra chiave privata è più che consigliato [e per sfatare un falso mito: non è vero che bisogna reinserire la password, basta affidarsi a un’implementazione sicura di ssh-agent].

    Ora controllate che effettivamente il comando abbia creato le vostre chiavi:

    local$ ls -la .ssh/
    drwx------  2 mbologna mbologna   4096 2009-09-24 18:43 .
    drwx------ 55 mbologna mbologna   4096 2009-11-13 00:42 ..
    -rwx------  1 mbologna mbologna   1743 2009-08-04 16:52 id_rsa
    -rwx------  1 mbologna mbologna    433 2009-08-04 16:52 id_rsa.pub

    id_rsa contiene la vostra chiave privata, mentre id_rsa.pub contiene la vostra chiave pubblica.

    Sulla macchina remota: autorizzare l’autenticazione tramite chiave pubblica [2/2]

    Loggatevi sulla macchina remota inserendo la vostra password [per l’ultima volta :)]:

    local$ ssh username@remote
    A questo punto seguite i seguenti passi:

    • create una directory .ssh nella vostra home mkdir .ssh
    • impostate i permessi appropriati chmod 700 .ssh
    • spostatevi nella directory .ssh cd .ssh
    • create un file chiamato authorized_keys touch authorized_keys
    • impostate i permessi approppriati chmod 600 authorized keys
    • aprite il file authorized_keys con il vostro editor preferito [ad esempio vi] vi authorized_keys
    • copiate e incollate il contenuto del file ~/.ssh/id_rsa.pub presente su local nel file authorized_keys
    • fate un logout

    Abbiamo finito! Ora potete semplicemente loggarvi sulla macchina remote semplicemente con ssh username@remote

    Nota: se non volete digitare la password ogni volta che accedete alla vostra chiave privata, date un’occhiata a ssh-agent.

  • Safari: come aprire un link in un nuovo tab anziché in una nuova finestra

    Safari [e molti altri browser] hanno un comportamento che mi infastidisce quando tentano di aprire un link [come ad esempio questo] in una nuova finestra.

    Mi piace l’idea di avere una finestra unica del browser ma con molteplici tab: dopotutto i tab sono stati introdotti proprio per non avere più finestre aperte. Quindi, per forzare Safari ad aprire un nuovo link in un nuovo tab, anziché in una nuova finestra, si deve modificare il comportamento di Safari tramite il terminale [non preoccupatevi, nulla di trascendentale]. Le istruzioni per MacOSX sono le seguenti:

    • Premete command+space per lanciare Spotlight e digitate ‘terminale’, il top hit che avrete è l’applicazione del terminale. Lanciatela
    • Una volta aperto il terminale, vi basterà copiare-incollare il seguente comando:
      defaults write com.apple.Safari TargetedClicksCreateTabs -bool true
    • Riavviate Safari

    Ben fatto! Ora i link che si aprivano in una nuova finestra verranno aperti in un nuovo tab.

    • Ecco perché anche gli utenti di OSX hanno bisogno di un antivirus

      Di solito gli utenti Mac non installano un antivirus perché si crede che il sistema operativo OSX sia esente da virus. Infatti, la giustificazione è quella per cui “su OSX non esistono virus [vedi sito Apple], e se esistessero chiedono comunque la password di sudo/root prima di installarsi; basta non fornire la password a programmi sconosciuti!”.

      Ultimamente ho trovato un interessante articolo da parte di Sophos, la famosa società di sicurezza. In pratica, su un sito (di cui non riporto il link per ovvie ragioni) viene offerta la possibilità ad utenti Windows e Mac (!) di poter scaricare un codec HDTV/DTV. Il codec però si rivela un trojan horse. Ovviamente gli utenti Mac non potranno più utilizzare la giustificazione “basta non fornire la password”, in quanto è l’utente che vuole legittimamente (ed è sua intenzione) installare il codec, quindi fornirà sicuramente la password. Ed ecco che così il computer viene infettato!

      Nel video sottostante potete trovare tutta la descrizione grafica del processo: download, spacchettamento e installazione (bloccata dall’antivirus).


      Apple Mac malware: Caught on camera from Sophos Labs on Vimeo.

    • Python: uno script per eliminare i file Thumbs.db e le cartelle .DS_Store

      Windows XP crea automaticamente un file, chiamato Thumbs.db, in tutte le cartelle che visita per salvarne la visualizzazione (dettagli, anteprima, etc.). La stessa cosa fa OSX, creando addirittura (!) una cartella dal nome .DS_Store, contenente gli stessi attributi.

      Stanco di avere il mio hard disk pieno di questi file (in Vista la gestione di questi file è intelligentemente centralizzata), ho creato uno script Python che analizza ricorsivamente una directory (specificata dall’utente) e stampa tutte le posizioni di questi file e directory indesiderati.image

      Lo script richiede esattamente due argomenti: il path da cui si vuole iniziare ad analizzare ricorsivamente la presenza di file e directory indesiderate, e una stringa che conferma l’azione: nel caso in cui l’opzione sia delete, lo script cancella i file desiderati, altrimenti stamperà soltanto le loro posizioni.

      Esempio:
      python recursiveDeleteUnwantedFilesAndDir.py C:\ print

      stampa la posizione dei i files/directory indesiderati

      python recursiveDeleteUnwantedFilesAndDir.py C:\ delete

      stampa la posizione dei i files/directory indesiderati e li elimina dal disco

      Veniamo al codice sorgente:

      import os
import sys

def recursiveDeleteUnwantedFilesAndDir(path,action):
    for root, dirs, files in os.walk(path):
        for name in files:
            if name == 'Thumbs.db':
                print os.path.join(str(root),str(name))
                if action == 'delete':
                    os.remove(os.path.join(str(root),str(name)))
        for name in dirs:
            if name == '.DS_Store':
                print os.path.join(str(root),str(name))
                if action == 'delete':
                    os.removedirs(os.path.join(str(root),str(name)))

recursiveDeleteUnwantedFilesAndDir(sys.argv[1],sys.argv[2])

      Per scaricare lo script: recursiveDeleteUnwantedFilesAndDir.zip

    • Sulla barriera che impedisce a molte persone di fare lo switch a MacOSX

      Mi trovo nella situazione di acquistare un computer nuovo e mi sono fatto la domanda la fatidica domanda: “è il caso di passare a MacOSX?”

      Innanzitutto precisiamo un paio di cose:

      • Ho sempre utilizzato sistemi Windows (attualmente Vista) e Linux
      • Mi sono sempre trovato (quasi) bene con Windows (ehi Microsoft, sono qui!), poco bene invece con Linux (scomodo, macchinoso)
      • Ho chiesto a molte persone il loro parere su OSX: quasi tutti mi hanno risposto che è un sistema stabile, veloce, comodo; insomma, quasi tutti sono soddisfatti di questo sistema operativo

      Sorge però una “questione”: il sistema operativo è la base su cui faccio girare tutte le mie applicazioni; se cambio OS, tipicamente alcune applicazioni non ci saranno (un esempio? Microsoft Office 2007 [si, su Mac c’è il 2008, ma non è uguale]). Per non parlare delle altre applicazioni che mancano su Mac (macworld è un sito di utenti Mac!): a questo proposito molti giudicano alcuni programmi Mac non all’altezza del corrispettivo Windows, e dunque li emulano con VmWare – vedere per credere). Ma come posso sapere come mi troverò con OSX?

      • Un modo legale e funzionante per provare OSX su un computer non-Apple non esiste
      • Alcuni dicono: in “un centro Apple si può provare”; ok, anche a MediaWorld, ma come puoi provare/testare approfonditamente un OS in 1h con commessi/gente che ti passa vicino? Personalmente non ci riesco…
      • Apple potrebbe avere un bacino di utenti maggiore se solo aprisse OSX: basta pensare a tutti gli utenti (come me) che vogliono provare “qualcosa di nuovo”; e (questo ovviamente non posso dirlo, visto che non l’ho provato), OSX potrebbe avere anche maggior successo (o insuccesso). Ma giustamente, si dice che Apple vuol far funzionare OSX soltanto sulle proprie macchine (corretto, Apple prima di tutto è un produttore hardware).

      Ma allora come diffondere OSX? (ehi Apple, sono qui!)

      • Ad esempio, ad una versione demo di 10 giorni?
      • Una versione per computer non-Apple che sia limitata come prestazioni?
      • Altre idee?