quixote(parte8)

Andiamo a vedere come un applicazione Quixote si interfaccia ad un web server come APACHE.

Già abbiamo visto all’ inizio di questa guida ,come  scrivere la funzione Handler ,cioè quella

che si occupa appunto di interfacciare   un web-server ,nel nostro caso ,nel file mio.py, simple_server.

Abbiamo visto che importando appunto dal modulo Quixote simple_server.py  la funzione run(),

if __name__ == ‘__main__’:


run(create_publisher, host=’nome server web’, port=8080)

gli passiamo gli argomenti create_publisher , host   e port .

create_publisher che ritorna un istanza di Publisher() a cui passiamo un istanza della classe dirc() di tipo

Directory() che crea la root dir dell applicazione.

OIltre al simple_server.py ,lo stesso Quixote ci mette a disposizione altri moduli di server web in python.

Ad esempio Medusa_server.py Twisted_server.py ,tutti ci mettono a disposizione la funzione run()

a cui (come l’ esempio sopra) passiamo come argomento l Handler create_publisher().facile!

La cosa cambia un po se vogliamo interfacciare l handler ad un web server apache ,che è molto piu

flessibile , e conveniente usarlo in ambiti più complessi e diversificati.

Quixote possiede dei moduli  gia confezionati per un interfaccia CGI , e (meglio ancora)   FAST-CGI.

Per quanto riguarda cgi non dobbiamo configurare nulla ,APACHE  è gia pronto per eseguire file CGI nella

directory cgi-bin.

FCGI o FAST-CGI  che è una sorta di cgi ma piu performante,ha bisogno invece di configurare apache ,che di default non lo

contempla.Per installare fast-cgi ,probabilmente,tutte le distribuzioni linux ,(come la mia Fedora8) hanno nei loro

repository il modulo fast-cgi per Apache.Una volta installato il modulo,il sistema crea un file di configurazione (ricordatevi che gli

esempi sono eseguiti su Apache  2.2.8 ) /etc/httpd/conf.d/fcgid.conf, che lasceremo cosi com’è.

mentre nel file   httpd.conf scriviamo la direttiva :

ScriptAlias /fcgi-bin/ “/var/www/fcgi-bin/”

e

<Directory “/var/www/fcgi-bin”>
AllowOverride None
SetHandler fcgid-script
Options ExecCGI

Order allow,deny
Allow from all

</Directory>

Questo per rendere la directory raggiungibile in rete , ed adatta agli script  FCGI .

per i CGi ed FCGI  ,che appunto avranno estensione .cgi o .fcgi dicevamo basta guardare gli esempi

nella directory server di Quixote.Essi come per le interfacce ai  web server python descritti sopra

(medusa , Simple_server,  Twisted ) funzionano sempre allo stesso modo ,cioè definiscono

la funzione run() ,e noi, importandola nello script iniziale dell applicazione,gli passaremo l’ Handler

create_publisher , e creeremo cosi dinamicamente i contenuti.

Continuiamo ,premettendo che SCGI non possiamo testarlo dato che per fedora7 non ho trovato il modulo.

Perciò passiamo adesso al mod_python per apache.

Prima però devo ricordarvi che nel file dell handler dell applicazione Quixote (mio.py) alla fine del file

abbiamo quella condizione :

 if __name__ == ‘__main__’:

 run(create_publisher, host=’nome server web’, port=8080)

Questa adesso non  consideriamola ,questa serve solo nel caso noi avviamo l applicazione da shell con python

infatti all inizio del file abbiamo scritto:

from quixote.server.simple_server import run

Il metodo run di simple_server viene quindi usato solo se il nome del file viene

passato come argomento da liea di comando.In tutti glialtri casi la condizione

if __name__ == __main__: non è soddisfatta.

Dicevamo allora mod_python puo essere un valido modo per velocizzare l applicazione,

l interprete viene tenuto in memoria ,e quindi non necessitiamo di un invocazione di python

ad ogni request.

Per usare mod_python (che ricordiamo di provare prima di tutto ad installarlo dai repository)

la configurazione è tutta in httpd.conf di apache.

Dopo l’ installazione il sistema crea il file python.conf nella directory  /conf.d.All’ interno

vi troviamo le direttive per caricare il modulo:

LoadModule python_module modules/mod_python.so

Andiamo poi in httpd.conf  dove scriveremo altre direttive di configurazione ,a livello globale,

se abbiamo un solo nome per il web server.A livello di <VirtualHost> se abbiamo (come nel mio caso)

una configurazione di Apache  name-based (diversi nomi [appunto virtuali]su di un unico indirizzo IP).

Ed inseriamo le seguenti linee:

# LocationMatch indica l url a cui associare l avvio di mod_python,essos eguirà

#al nome del Virtualhost in cui settiamo la configurazione.Se il VirtualHost si

#chiama ad es. server_virtuale1 all indirizzo http://server_virtuale1/mod_p e tutte le sue sottodirectory

#(grazie all’ espressione regolare  che segue ) apache passa l’esecuzione a Python.

<LocationMatch “^/mod_p(/|$)”>
SetHandler python-program

#Sotto aggiungiamo la directory al path dove python cerca i moduli

PythonPath “sys.path + ['/var/www/html/dir_mio/e_quixote/']“

#L’ handler , che sarà messo a disposizione dal modulo di quixote
PythonHandler quixote.server.mod_python_handler

#E gli passiamo il publisher di create_publisher
PythonOption quixote-publisher-factory mio.create_publisher

PythonDebug On
</LocationMatch>

Adesso ogni volta che passiamo  per l url http://server_virtuale1/mod_p/* tutti gli url

che gli seguono saranno processati da Python .

Solo per conoscenza ,dico che mod_python non è solo un modulo per interpretare codice python senza chiamare l interprete
ad ogni invocazione come per i cgi.Ma mod_python è anche uno dei primi framework in python ,ed anche,
piuttosto  lineare e limpido nello sviluppo di applicazioni (anche se direi abbastanza a basso livello di astrazione).

Ultimo (ma non per questo meno funzionale ,anzi..) modo per interfacciare web server ad applicazioni Quixote,è

il modulo WSGI ,in questo caso per APACHE.

Una domanda  che leggo spesso su web, è :  “meglio mod_python ”  oppure   “mod_wsgi” ?.

WSGI è lo standard python per interfacciare applicazioni web ad un web server ,modo standard e portabile ,

perchè basta che un server implementi interfacce WSGI, come ce ne sono diversi scritti in python ,e come abbiamo moduli

per Apache  per Ngix per IIS.Con WSGI non dobbiamo modificare nulla ,il codice client funziona sempre ,lo stesso dicasi per il framework

basta che supporti WSGI come QUIXOTE , oppure ancora  Django ,Cherry.py,web.py ecc.

Inoltre mod_python è un framework vero e proprio ,mentre WSGI (mod_wsgi per apache) si preoccupa solo di interfacciare

al server web;ma lo fa in maniera egregia .Inoltre possiamo usare mod_wsgi allo stesso modo di mod_python

cioè come modulo apache , che carica in cache l’ interprete ,oppure possiamo configurarlo per farlo girare come ‘demone’

in questo caso creeremo un processo child di apache che gira con permessi propri che siamo noi a decidere.

In pratica possiamo far girare anche diverse applicazioni web attraverso interfacce wsgi che girano ognuna con permessi propri

e che vanno ad elaborare files specifici dell utente con i cui permessi gira l applicazione.

Tornando a Quixote , esso supporta WSGI tramite la classe QWIP nel file wsgi.py
Ci basta scrivere :

from quixote.wsgi import QWIP
e dopo il create_publisher

publisher = create_publisher()


application=QWIP(publisher)


ATTENZIONE
il nome application e obbligatorio altrimenti mod_wsgi non ricoonosce l interfaccia.
Ecco fatto adesso l apèplicazione Quixote funziona per qualsiasi server che implementi interfacce WSGI.
Adesso dobbiamo però configurare Apache.

Ricordate che io scrivevo del webserver apache con dei VirtualHost named based?  lo rammento perchè
faremo delle diverse configurazioni ,sui diversi VirtualHost.
Questo per configurare il server web affinchè avvii l’ interprete attraverso interfaccia WSGI , sia come modulo apache .
Cioè come  già si fa per mod_python , che carica in memoria l’ interprete , e sia come demone ,cioè lo facciamo giarere come processo CHILD di Apache.

Allora nel settore globale delle direttive del web server scriviamo:

#¹Questa sotto è la directory dove si trova il file  ‘file.wsgi’

#ATTENZIONE esso è equivalente al file HANDLER mio.py ,quello che inizializza l applicazione
#quello che abbiamo visto prima che contiene la funzione create_publisher(),che è quella la cui
#chiamata crea attraversop l istanza del Publisher() ,l albero dell aplicazione.
#La stessa cosa equivale per il file.wsgi solo che ho usato un altro file per i test wsgi ,solo
#per non mischiare le varie maniere di interfacciare il web server a quixote .
#Altrimenti avrei dovuto mettere in un solo file ,interfaccia CGI , Fast-CGI , mod_python WSGI ecc. Meglio di no.

WSGIScriptAlias  /test_wsgi  /var/www/html/dir_mio/file.wsgi
#la riga sotto serve per aggiungere una directory al path di ricerca
#moduli altrimenti la directory di lavoro corrente non veniva come di norma inclusa nel path.
#In quanto non appartenente al PYTHONPATH del sistema.

WSGIPythonPath   /var/www/html/dir_mio
#LA DIRETTIVA SOTTO E IMPORTANTE PERCHE AVVIANDO UN PROCESSO NON CHILD DI HTTPD CHE IN PRATICA
#GIRA CON PERMESSI DI ALTRO UTENTE NON RIESCE A CREARE IL FILE DI SOCKET NELLA DIRECTOORY DI DEFAULT /etc/httpd/logs
#PERCHE E UNA DIR PROTETTA SOLO  ROOT (CHE E L UTENTE CON CUI GIRA IL PROCESSO PADRE HTTPD) PUO ACCEDERVI.
#QUINDI SICCOME IL DEMONE WSGI CON PERMESSI UTENTE NON PUO ACCEDERVI ABBIAMO L ERRORE SERVICE TEMPRANELEY UNVAILABLE 503
#QUINDO SPOSTIAMO ATTRAVERSO LA DIRETTIVA SOTTO IL FILE DI SOCKET IN /VAR/RUN/WSGI

WSGISocketPrefix /var/run/wsgi

Quindi adesso abbiamo visto come configuarare apache per eseguire interfacce WSGI come modulo apache.
Adesso vediamo di farlo funzionare come Demone:
Andiamo nella sezione di un VirtualHost e scriviamo:

WSGIDaemonProcess gianluca user=gianluca group=gianluca processes=1 threads=25
WSGIProcessGroup gianluca

WSGIScriptAlias /wsgi1  /home/gianluca/myapp.wsgi

E, in una altro VirtualHost scriviamo:

WSGIDaemonProcess ftpd.homepc.it user=u_ftp group=ftp processes=1 threads=25
WSGIProcessGroup ftpd.homepc.it

WSGIScriptAlias /dm  /var/www/user_ftp_dir/myapp.wsgi

In queste 2 ultime configurazioni nell elenco dei processi ,ne troveremo 2 sotto HTTPD che girano come processi
figli di apache ,e con i permessi dell utente  gianluca ed u_ftp , in pratica le 2 applicazioni girano con i permessi
dei 2 relativi utenti , che sono utenti reali del sistema .
Potremo quindi lavorare nelle directory home proprietarie ,dove scrivere i file dell applicazione
ne abbiamo quindi anche dei vantaggi a livello di sicurezza e protezione dei dati.


1]ATTENZIONE ,il cancelletto che trovate sopra all inizio di alcune righe ,dove abbiamo le direttive WSGI per mod_wsgi apache.

esse sono dei commenti apache , infatti li ho ricopiati direttamente dal mio httpd.conf insieme alle direttive.

BUON LAVORO.

©Gianluca Fiorillo  2010

Questa guida  puo essere copiata e redistribuita gratuitamente , con il solo obbligo di citarne la fonte e l’ autore

Leave a Reply

Your email address will not be published.


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>