huawei logo

Quest’anno, a differenza dell’anno scorso (Condivisione connessione 3G via WiFi su Windows XP), ho deciso di installare il modem Huawei E220 sul mio iMac e condividere la connessione rendendola disponibile all’iPhone e al netbook.

Per prima cosa è necessario aggiornare il firmware del modem Huawei E220.

Dopo aver eseguito questa operazione collegate il modem alla porta USB del Mac. Ora aprite le “Preferenze di sistema“, poi “Network“. Dovreste vedere nell’elenco in colonna destra 3 nuove voci: HUAWEI Mobile, DIAG e PCUI.

HUAWEI Mobile - Impostazioni Network

Cliccate su HUAWEI Mobile ed inserite il numero di telefono secondo le impostazioni del vostro provider (nel mio caso Tim, il numero è *99#), poi Nome account e Password (per Tim lasciare vuoti, come da schermata sopra). Poi cliccate su Avanzate.
Nella finestra seguente selezionate il tab Modem e inserite:

HUAWEI Mobile - Impostazioni avanzate

Fornitore: Generico
Modello: GPRS (GSM/3G)
APN: (quello fornito dal vostro provider, per Tim: ibox.tim.it)
CID: 1

I DNS (secondo tab) vengono forniti in automatico dopo la connessione.
Nel tab PPP invece potrete personalizzare alcune impostazioni. Nel mio caso ho spuntato “Abilita resoconto dettagliato“.

A questo punto potete cliccare su OK per chiudere la schermata Avanzate e tornare alla schermata base delle impostazioni Network, cliccate su Collega (Connetti) e verificate il funzionamento della connessione.

Se tutto è andato a buon fine siete connessi, in caso contrario verificate ogni parametro con quelli forniti dal vostro provider (operatore telefonico).
Quanto descritto finora è stato personalmente verificato su Snow Leopard (OSX 10.6). Per sistemi operativi precedenti le schermate sono leggermente diverse ma i passi da eseguire e le impostazioni sono molto simili.

A questo punto mi mancava solo un tool in grado di monitorare al meglio la situazione, qualcosa in grado di tenere anche traccia del totale del traffico (inviato e ricevuto) generato. Dopo un po’ di ricerche ho trovato CheetahWatch dell’ottimo Patrick Quinn-Graham. Un piccolo grande tool dedicato ai modem Huawei USB. Una volta installato comparirà un’icona nella Menù bar la quale vi darà accesso alle informazioni (e impostazioni) fondamentali:

icona Menù bar

menù CheetahWatch

La voce di menù Status apre una piccola finestra con preziose informazioni sullo stato della connessione e sull’utilizzo di banda:

Status CheetahWatch

Patrick ha rilasciato i sorgenti di CheetahWatch sotto licenza BSD. Mi sono messo in contatto con lui per tradurre l’app in Italiano. Non appena avrò novità aggiornerò questo post.

Buona navigazione con l’ottimo e sempre grande Huawei E220!

Oggi ho deciso di risolvere, in ambiente di sviluppo (macchina locale), una volta per tutte il problema dell’installazione (via download diretto) di plugins, temi, ecc, di WordPress. Sviluppo su iMac 27′ su cui ho installato Zend Server CE (LAMP).

Ogni volta che, in locale ( in produzione, ad esempio, mai avuto problemi!), tentavo di installare un plugin, un tema o un aggiornamento mi ritrovavo di fronte alla schermata sopra. Oggi ho approfondito alcuni aspetti e ho scoperto che si tratta di un problema di permessi.

WordPress, durante questi processi di installazione, ha necessità di lavorare sul Filesystem. Deve poter scrivere e modificare i permessi/proprietari dei files. Se per qualsiasi motivo non riesce a fare questa operazione rimanda l’utente alla schermata sopra nel tentativo di eseguire l’operazione via FTP. In questa pagina è spiegato molto bene tutto il meccanismo, viene anche evidenziata la procedura che WP utilizza per verificare se può scrivere sul Filesystem (vedi sotto).

Su OSX in pratica avevo questo contrasto nei permessi:

L’utente daeomn del gruppo wheel è quello con cui WP scrive sul filesystem (in pratica l’utente utilizzato da Apache). La procedura che effettua la suddetta verifica è questa:

// The following code is from the get_filesystem_method()
// method in the wp-admin/includes/file.php file:
 
if( function_exists('getmyuid') && function_exists('fileowner') ){
    $temp_file = wp_tempnam();
    if ( getmyuid() == fileowner($temp_file) )
        $method = 'direct';
    unlink($temp_file);
}

Nel mio caso non dà esito positivo e quindi si finisce alla schermata di inserimento dei dati account FTP. In pratica l’utente dello script che scrive sul filesystem deve essere lo utente con cui apache viene eseguito. Nel mio caso sopra infatti non è così.

Come risolvere il problema?

Non so se quella scelta è la via corretta e nemmeno mi sono preoccupato di eventuali problemi relativi alla sicurezza (per i quali vi consiglio il plug-in WP-Security) perchè, come ho evidenziato sopra, si tratta della macchina di sviluppo interna.

La mia soluzione è stata quella di cambiare il proprietario dell’intera directory che ospita WordPress impostando daemon come utente e wheel come gruppo:

chown -R daemon:wheel m4ss

Problema risolto!

Come sistema di backup di GMail fino a qualche giorno fa utilizzavo un qualsiasi client IMAP (nello specifico Thunderbird) con le varie impostazioni per creare una copia in locale. Da tempo però avevo smesso di utilizzarlo come client email. La posta la leggo via web su GMail o via iPhone.

Mi son messo così alla ricerca di una soluzione un po’ più furba del dover aprire periodicamente Thunderbird. Ho trovato GMail Backup che, opportunamente configurato, esegue un backup incrementale quotidiano. La Time Machine fa il resto. Vediamo come.

Per prima cosa mi son creato una directory in Documenti/Backup chiamata GMail:
/Users/gullo/Documents/Backup/GMail/

In questa ho scompattato l’ultima versione di GMail Backup (al momento la 0.107) e ne ho creato una in cui posizionare il lunghissimo elenco di email: Backup. Poi un link simbolico che punta all’ultima versione di gmail-backup. In questo modo abbiamo:

iMacJazzo:GMail gullo$ pwd
/Users/gullo/Documents/Backup/GMail
iMacJazzo:GMail gullo$ ls -all
total 24
drwxr-xr-x      6 gullo  staff     204  3 Feb 13:58 .
drwxr-xr-x      4 gullo  staff     136  2 Feb 15:50 ..
-rw-r--r--@     1 gullo  staff    6148  3 Feb 14:00 .DS_Store
drwxr-xr-x  18598 gullo  staff  632332  3 Feb 14:20 backup
lrwxr-xr-x      1 gullo  staff      25  3 Feb 13:58 gmail-backup -> gmail-backup-0.107-linux/
drwxr-xr-x@    14 gullo  staff     476  3 Feb 14:19 gmail-backup-0.107-linux

In gmail-backup ho creato un file bash che esegue il backup incrementale:
makeBackup.sh

#!/bin/bash
DATASTART=`date -v -1d "+%Y%m%d"`
cd /Users/gullo/Documents/Backup/GMail/gmail-backup
./gmail-backup.sh backup ../backup/ xxxxxx@gmail.com passwd $DATASTART

La variabile DATASTART viene settata col giorno precedente rispetto al momento in cui lanciate lo script (con il formato corretto come richiesto da gmail-backup). In realtà gmail-backup effettua già un controllo tra ciò che ha già archiviato in locale e le novità presenti online ma se lanciate il comando senza alcuna data come parametro l’operazione può diventare estremamente lunga, soprattutto se avete qualche anno di email nel vostro account! Ecco perchè conviene impostare come parametro una data di partenza. Ci basta andare indietro di 1 giorno per avere la certezza di non perdere nulla.

Prima di passare alla pianificazione dello script ricordatevi di lanciare solo la prima volta il comando primo del parametro data:

./gmail-backup.sh backup ../backup/ xxxxxx@gmail.com passwd

In questo modo potrete creare il primo backup completo di tutte le email presenti in GMail, dalla prima all’ultima. Una volta concluso questo primo backup potremo pianificare l’operazione con launchd. A questo punto vi consiglio questo ottimo Tutorial su come pianificare operazioni con launchd su OSX.
La cartella backup (quella in cui archivierete il tutto) conterrà migliaia di file, uno per ogni email. La Time Machine farà il resto perchè, effettuando anch’essa backup incrementali, archivierà solo le email che di giorno in giorno verranno aggiunte nella suddetta directory.

Ultima consiglio: consultate la pagina delle FAQ nel caso in cui lo script dia errori. A me è risultata molto utile!!

Aggiornamento del 16/02/2011

In realtà mi sono accorto che la soluzione sopra è un po’ precaria: se non viene lanciata tutti i giorni si rischia di perdere qualche email. La soluzione corretta è memorizzare la data in cui il backup viene effettuato per poi recuperarla ogni volta, prima di procedere al nuovo backup.

In pratica il nuovo codice del file makeBackup.sh è:
makeBackup.sh

#!/bin/bash
DATASTART=`cat lastUpdate`
cd /Users/gullo/Documents/Backup/GMail/gmail-backup
./gmail-backup.sh backup ../backup/ xxxxxx@gmail.com passwd $DATASTART
date -v -1d "+%Y%m%d" > lastUpdate

Noterete che si fa riferimento ad un file di nome lastUpdate. Tale file viene creato automaticamente dopo la prima esecuzione dello script, poi semplicemente aggiornato alla fine di ogni backup. Il file memorizza la data del giorno precedente in modo da esser sicuri di recuperare tutto!

Aggiornamento del 19/01/2012

Da qualche giorno ho rilasciato un’App dedicata al backup di Gmail.
L’app è semplice e leggera, si installa nella Status Bar e, dopo una rapida configurazione, esegue in “silenzio” il backup. Puoi selezionare dove salvare il tutto e quando, se ogni ora o una volta al giorno ad un orario preciso.

Per chi non ha voglia di smanettare tra righe di comando e file di configurazione consiglio l’installazione di BackUp Gmail (disponibile sull’App Store).

Lavoro in ambiente OSX e uso Eclipse per scrivere codice e SmartSVN come client Subversion.
Avevo necessità di aprire un vecchio progetto (proveniente da macchina Windows) di un copia in locale prima di effettuare operazioni sul repository. Ho provato a fare un Relocate della copia locale in modo da poterlo poi sincronizzare con il repository ma ho ricevuto questo errore:

Relocate: Cannot rename file ‘/project/css/.svn/tmp/entries’ to ‘/project/css/. svn/entries’

La soluzione ai miei problemi l’ho trovata su StackOverflow dove si legge:

If you’re changing workspaces on OS X and you import an SVN-based project into your new workspace, some of your files may have the uchg flag set. SubClipse/SVN will not be able to update this project.

Effettivamente le cose stavano così anche nel mio caso e per sistemare correttamente il flag uchg (“user immutable flag“) basta dare il comando (al livello più alto della directory del progetto) da riga di comando:

chflags -R nouchg .

Stamattina mi dedico al nuovo (per me!) mondo dello sviluppo su iPhone e, perchè no, sul nuovo iPad.
In settimana mi sono iscritto all’iPhone Developer Program in modo da poter testare le App sviluppate direttamente sull’iPhone, installarle su altri 10o (per testarlo con gli amici) e distribuirle tramite Apple Store.

Vi segnalo due guide su devAPP (molto ben fatte!) sui passi fondamentali per poter iniziare:

• Acquistare la Licenza Developer
• Creare i certificati (Development e Distribution) per l’invio ad Apple

Rispetto alle guide qui sopra segnalo, come evidenziato in questo post sul Developers Forum, che, prima di procedere, dovete verificare di aver il certificato WWDR (Apple Worldwide Developer Relations Certification Authority). Le operazioni, procedendo senza aver prima installato questo certificato, non andranno a buon fine. Il WWDR lo trovate nella sezione Certificates del Program Portal (iPhone Developer Program).

Nel caso in cui aveste già installato il tutto (come da procedura della guida) senza il WWDR è necessario ripartire da zero. Per prima cosa dovete seguire quanto descritto nel suddetto post:

1 Delete the WWDR certificate and your developer certificates from Keychain Access
2 Ensure that the login keychain is set as the default keychain in Keychain Access
3 Download the WWDR certificate and add it to your keychain in the login section
4 Use Keychain Access to generate a CSR (Certificate Assistant… Request a Certificate…) for a developer
5 Submit the CSR to the Apple portal
6 When the developer certificate is ready, download it to your Mac and add it to your keychain in the login section
7 In the Apple portal, specify the unique device ID (UDID) of your iPhone or iPod touch. You can find the device’s UDID in the Window… Organizer section of Xcode. The ID is the 40 character “Identifier” string in the “Summary” tab (e.g. 4ada8edc85bfdd3947696cb3277a8c7f731fb6c3)
8 In the Apple portal, choose an App ID name. This can be anything, it is not related to any other data. However, the Bundle Identifier that you choose here MUST match the Bundle Identifier used in your Xcode .plist file, e.g. “com.mydomain”
9 In the Apple portal, create a provisioning profile. The 3 ingredients for this are the name(s) of your developer certificates, your unique device ID(s) (UDID(s)), and your App ID. When you download this file, it will have a .mobileprovision extension. After you have downloaded it, open it in Finder, and drag it to the Xcode icon in your dock. The profile should now appear in Xcode. To check, go to the Xcode “Window… Organizer” menu and look under “iPhone Development… Provisioning Profiles”. If all is ok, you should not see any yellow error messages, and your profile should appear in the “Name” list.
10 Do a clean build, so that previous precompiled headers and object files are deleted. In Xcode, choose “Build… Clean All Targets”, then “Build… Build and Run”. If your code compiles with no errors, Xcode will upload the app to your iPhone or iPod touch, using the USB cable attached to your device.

Infine ricordatevi di ripulire anche il vostro iPhone. Io ho seguito la procedura qui sopra diverse volte prima di trovare questo utilissimo post. Sul vostro iPhone quindi andate in Impostazioni -> Generale -> Profili e cancellateli, poi riprovate di nuovo.
Forza e coraggio… vedere la prima installazione creata da voi che gira sul proprio iPhone merita davvero!

Sto effettuando la migrazione da PC a Mac (OS X Snow Leopard). Su PC utilizzo il mitico PuTTY (programma che non smetterò mai di osannare!) per connettermi ai server in SSH con chiave pubblica. Su Mac non è necessario alcun software aggiuntivo essendo quest’ultimo basato su Unix, tuttavia sono state necessarie alcune operazioni elementari per poter ottenere la stessa operatività.

Per prima cosa ho dovuto convertire le mie chiavi pubbliche, generate a suo tempo da PuTTYgen, in modo che potessero essere usate da qualsiasi client OpenSSH. Per questo il buon PuTTYgen ci viene in aiuto. Per prima cosa è necessario importare la chiave .ppk (Conversions -> Import key). Una volta importata la chiave è possibile esportarla come OpenSSH key (Conversions -> Export OpenSSH key). Salvate poi la nuova key su una chiavetta usb e portatela su Mac.

Sul Mac ho spostato la key nell’apposita directory .ssh presente nella mia Home (/Users/myName). Sempre nella Home ho creato il file mySSH-Server1.sh con questo contenuto:

ssh -i /Users/myName/.ssh/myKey_ssh -p 922 myUser@xxx.xxx.xxx.xxx

In pratica chiamo ssh da riga di comando con:

• -i serve per agganciare la chiave appena salvata
• -p perchè non uso mai la porta standard 22 (così si escludono un pò di lamer)
• myUser@xxx.xxx.xxx.xxx è la classica chiamata ssh composta da user e indirizzo IP

Ho salvato il file e l’ho reso eseguibile con il comando:

chmod 700 mySSH-Server1.sh

Ho creato poi un Alias del file e l’ho posizionato sulla Scrivania in modo da averlo sempre a portata di click.
Appena lanciato, ssh mi ha fatto notare che i permessi della key non erano corretti e quindi li ho impostati:

chmod 600 .ssh/myKey_ssh

Dopodichè è partito, ho inserito la passphrase è via!