Posts Tagged ‘ OSX

mod_wsgi on OSX

It’s been quite a while since my last words on these pages. And yes, I’m writing in english, my bad english for a number of reasons… But this is out of scope, so let’s put away the dust and start to write something (hopefully) useful :)

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

anubis:httpd-2.2.21 fabio$ ./configure \
&& make \
&& sudo make install

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:

anubis:mod_wsgi-3.3 fabio$ ./configure \
--with-apxs="/usr/local/apache2/bin/apxs" \
--with-python="/Users/fabio/Sviluppo/python-2.7/bin/python" \
&& make \
&& sudo make install

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 :)

anubis:conf fabio$ sudo vi httpd.conf

and inside I added the following lines

Alias /media/ /Users/fabio/Sviluppo/booklibrary/media/

<directory /Users/fabio/Sviluppo/booklibrary/media>
Order deny,allow
Allow from all
</directory>

#MOD_WSGI
LoadModule wsgi_module modules/mod_wsgi.so

WSGIDaemonProcess books user=fabio group=staff python-path=/Users/fabio/Sviluppo/python-2.7/lib/python2.7/site-packages processes=2 threads=25

WSGIProcessGroup books

WSGIScriptAlias / /Users/fabio/Sviluppo/booklibrary/apache/booklibrary.wsgi
#WSGIScriptAlias /books /Users/fabio/Sviluppo/booklibrary/apache/test.wsgi

<directory /Users/fabio/Sviluppo/booklibrary/apache>
Order deny,allow
Allow from all
</directory>

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
The others are simply mappings and aliases which are almost straightforward.
Last but not least, the file .wsgi. I wrote 2 versions, one was a mere test of a correct installation of mod_wsgi in apache (test.wsgi):

import sys

def application(environ, start_response):
    status = '200 OK'
    output = 'It Works! -- Python executable at '+ sys.executable
    response_headers = [('Content-Type', 'text/plain'), ('Content-Length',   str(len(output)))]
    start_response(status, response_headers)
    return [output]

the other is the one which make the django app start:

import os
import sys

#sys.path.append('/usr/lib/python2.4/site-packages/django')
#/Users/fabio/Sviluppo/python-2.7/bin/
paths = ['/Users/fabio/Sviluppo',
        '/Users/fabio/Sviluppo/booklibrary']
for path in paths:
    if path not in sys.path:
        sys.path.append(path)

os.environ['DJANGO_SETTINGS_MODULE'] = 'booklibrary.settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

And that’s all ;)

iSync con Samsung SGH-E250

La cosa bella di un Mac è che presenta una rosa di software pronta all’uso. La cosa brutta è che non essendo software OpenSource spesso non è possibile personalizzare al meglio le funzionalità che più ci occorrono.

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

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

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

/Applications/iSync.app/Contents/PlugIns/ApplePhoneConduit.syncdevice/Contents/PlugIns/Samsung-E250.phoneplugin/Contents/Info.plist
/Applications/iSync.app/Contents/PlugIns/ApplePhoneConduit.syncdevice/Contents/PlugIns/Samsung-E250.phoneplugin/Contents/Resources/MetaClasses.plist

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 ;)

Dopo iWork ’09 anche Photoshop CS4…

Bisognava aspettarselo e molto probabilmente ci saranno anche altri prodotti compromessi. Il trojan è il OSX.Trojan.iServices.B e come spiega anche MacWorld:

“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 .

Trojan in iWork ’09

Ebbene, come spiego spesso a molti miei amici, il solo sistema operativo non garantisce la sicurezza, è soprattutto la consapevolezza di chi lo usa e gli accorgimenti che adotta che rendono il sistema una “roccaforte”.

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.