These days I’m experiencing Python and the web full-stack framework Django. They both are impressive, really: starting the development of a webapp is almost straightforward, if you have the time to read the really good documentation available at https://docs.djangoproject.com.

After a bit of exercise, I developed a tutorial application, and I wanted to deploy it with the Apache Web Server since django offers a built-in web server during the development phase (and it’s written in python). Since I’m using a mac, I got some troubles to get mod_wsgi working. So far nothing too much annoying, but I wasted a bit of time so I hope these words can save someone else’s time :-)

I was not happy to use the Apache httpd which come built-in in OSX, so I downloaded the latest release from the Apache site (http://www.apache.org/dyn/closer.cgi ) and built it from scratch. Ensure you have the development tools installed in your OS, if not you can download them from the Mac App Store getting Xcode 4 for free…

So after a successful compile of sources

I found my apache 2 server ready under the directory /usr/local/apache2.

The next thing, is to install mod_wsgi . If you don’t want to use the built-in osx httpd, you have to download the sources (http://code.google.com/p/modwsgi/wiki/DownloadTheSoftware), and build them from scratch. This time, take care of where is the apache installation (did just some moments before) and where is your python!

Since I’m using virtualenv, I was almost sure to activate the environment settings and build mod_wsgi from the shell was sufficient… So far this is not the case, I needed to provide the installation path to the configure script, otherwise it will continue to use the python built-in with OSX:

where /Users/fabio/Sviluppo/python-2.7/bin/python is the directory where I installed python 2.7 and django via virtualenv and pip.

It’s now time to configure Apache. Of course using vi :)

and inside I added the following lines

Since the django app is in my home directory, we must ensure apache is able to run the code. This is accomplished with the lines

• WSGIDaemonProcess books user=fabio group=staff …
• WSGIProcessGroup books

iSync è un’applicazione veramente ben fatta, mi ha dato subito soddisfazione con il mio vecchio Nokia 6600 per il quale, installando un agent sul cellulare stesso, tutto è andato alla grande. Con il Samsung SGH-E250, invece, il risultato era sempre lo stesso: dispositivo non supportato.

Con un po’ di ricerche con Google, però, ho visto che telefoni come il Samsung D900, che è molto simile nell’aspetto e nelle specifiche al mio, funzionano alacremente.

Sono andato dunque dentro la cartella di iSync ( /Applications/iSync.app/ ) a cercare qualcosa ed ho trovato appunto i driver del D900 dentro la cartella

/Applications/iSync.app/Contents/PlugIns/ApplePhoneConduit.syncdevice/Contents/PlugIns/Samsung-D900.phoneplugin

e mi son detto che magari come per le stampanti il mio telefono potrebbe funzionare con un driver di un altro molto simile a lui… E di fatti ha funzionato!

In sostanza mi sono limitato a copiare la cartella in

All’interno della cartella ho sostituito tutte le occorrenze di “D900″ con “E250″ nei seguenti file

ed infine ho rinominato il file (situato nella cartella /Applications/iSync.app/Contents/PlugIns/ApplePhoneConduit.syncdevice/Contents/PlugIns/Samsung-E250.phoneplugin/Contents/Resources/) com.samsung.D900.tiff in com.samsung.E250.tiff.

Certo, l’icona non è proprio la stessa però ci si avvicina molto ed è sempre meglio di niente :)

Avviando iSync la sincronizzazione è andata a buon fine, numeri di cellulare, indirizzi e-mail e compleanni sono stati caricati correttamente, solo le immagini personali non sono state caricate, ma direi che è accettabile anche questo :)

Il driver, ottenuto come sopra, per il Samsung SGH-E250 lo potete scaricare dal mio sito a questo link, ricordate però che non è ufficiale e che l’utilizzo è a vostro rischio e pericolo ;)

“The crack application installs a backdoor in the /var/tmp directory, copies an executable to /usr/bin/DivX and saves the root hash password in the file /var/root/.DivX, according to Intego. It then listens on a random TCP port and attemps to make repeated connections to two IP addresses. Intego concludes that the creator of the malware intends to be alerted through this method and may have the ability to connect to affected Macs and perform various actions remotely”

Non troppo tempo fa era apparsa, sul sito del supporto Apple, una pagina che consigliava l’utilizzo di software di protezione. La pagina risale al 2007, ma fu aggiornata anche nello scorso novembre. Lo scalpore generato, che definirei anche smisurato, fece sì che la pagina fosse rimossa… Forse era meglio tenerla, visto che i virus non sono l’unica minaccia circolante…

Chi non si ricordasse della vicenda può informarsi su questo link .

Secondo Engadget esiste una versione di iWork ’09 pirata, scaricata da diverse migliaia di utenti, che conterrebbe al suo interno un Trojan (OSX.Trojan.iServices) che guadagnerebbe accesso con permessi di root alla macchina OSX su cui è installato. Ciò permette l’accesso remoto alla macchina con la possibilità di installare componenti e manipolare le applicazioni già esistenti.

Da MacWorld (fonte dalla quale la notizia di engadget blog è tratta) ecco come controllare se si è infetti o meno:

“To check if you’ve been infected, look in /System/Library/StartupItems for an item named iWorkServices. If it exists, you’ve been infected with this Trojan horse.”

Ed ecco qual’è la vera differenza tra software “OpenSource/ClosedSource” e tra “gratuito/a pagamento”: dov’è la necessità di scaricare materiale pirata se liberamente disponibile? Quanto tempo si sarebbe impiegato ad identificare il trojan se il codice fosse stato open? Con questo non metto in dubbio l’elevata qualità dei prodotti Apple, è chiaro, manifesto solo i lati che apprezzo del software opensource.