! diff -r 9f9a427a73eb -r 19129672444e GNUmakefile --- a/GNUmakefile Mon Nov 18 12:48:10 2013 +0400 +++ b/GNUmakefile Wed Nov 20 14:36:40 2013 +0400 @@ -74,7 +74,7 @@ dtd/news.dtd \ xslt/news.xslt \ -LANGS = en ru cn he ja tr +LANGS = en ru cn he ja tr it YEARS = 2012 2011 2010 2009 diff -r 9f9a427a73eb -r 19129672444e xml/i18n.xml --- a/xml/i18n.xml Mon Nov 18 12:48:10 2013 +0400 +++ b/xml/i18n.xml Wed Nov 20 14:36:40 2013 +0400 @@ -73,4 +73,15 @@ çeviren: + +e +scritto da +pubblicato da +tradotto da +Elenco alfabetico delle direttive +Questa traduzione potrebbe essere obsoleta. +Verifica la versione in inglese +per gli aggiornamenti piu' recenti. + + diff -r 9f9a427a73eb -r 19129672444e xml/it/GNUmakefile --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/GNUmakefile Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,13 @@ +DOCS = \ + faq \ + install \ + windows \ + events \ + syntax \ + control \ + hash \ + http/request_processing \ + http/server_names \ + http/configuring_https_servers \ + debugging_log \ + beginners_guide \ diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/beginners_guide.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/beginners_guide.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,454 @@ + + + + +

+ +

+ + +La presente guida fornisce una introduzione a nginx e descrive alcune +semplici funzionalità per il quale può essere utilizzato. +Nel seguito si presuppone che nginx sia gia' stato installato; +in caso contrario fare riferimento alla pagina +. +La presente guida spiega come avviare, come fermare e come ricaricare +la configurazione di nginx, descrive brevemente la struttura del file +di configurazione, spiega come configurare nginx per servire contenuti statici, +come configurarlo per l'uso come proxy server, +e come configurarlo per l'uso con un'applicazione FastCGI. + + + +nginx ha un processo master e numerosi processi worker: +lo scopo principale del processo master e' leggere e interpretare la configurazione, +e mantenere i processi worker attivi; +a loro volta, i processi worker si occupano di gestire effettivamente le richieste. +nginx utilizza un modello event-based e meccanismi dipendenti dal sistema operativo +per distribuire con efficienza le richieste fra i processi worker. +Il numero di processi worker e' definito nel file di configurazione, +e puo' sia essere fisso, +sia essere regolato automaticamente in base al numero di core CPU disponibili +(vedere ). + + + +La maniera in cui nginx e i suoi moduli lavorano e' determinata nel file di configurazione; +per default, tale file si chiama +nginx.conf +e si trova in una delle directory: +/usr/local/nginx/conf , +/etc/nginx , +/usr/local/etc/nginx . + + +

+ + +

+ + +Per far partire nginx, avviare il file eseguibile. +Una volta partito, nginx puo' essere controllato invocando l'eseguibile con il parametro +-s . +Usare la seguente sintassi: + +nginx -s signal + +Dove signal e' uno dei seguenti: + + +stop—arresto rapido + + +quit—arresto controllato + + +reload—ricaricamento della configurazione + + +reopen—riapertura del file di log + + +Ad esempio, per fermare il processo nginx ma attendendo che finisca di servire +le richieste correnti, va eseguito il seguente comando: + +nginx -s quit + +Questo comando dovrebbe essere eseguito dallo stesso utente che ha avviato nginx. + + + +Le modifiche al file di configurazione non saranno applicate sinche' +nginx non e' riavviato o non riceve il comando di ricaricamento della configurazione. +Per ricaricare la configurazione, eseguire: + +nginx -s reload + + + + +Quando il processo master riceve il segnale di ricaricamento della configurazione, +verifica la validita' sintattica e tenta di applicare la configurazione riportata nel relativo file. +Se ha successo, il processo master avvia nuovi processi worker e invia messaggi di chiusura a quelli vecchi, +che smettono di accettare nuove connessioni ma continuano a servire le richieste correnti sinche' non sono +state del tutto completate, dopo di che terminano. +Se la nuova configurazione non risulta corretta, oppure se non e' possibile applicarla, +il processo master continua a lavorare con la configurazione precedente. + + + +E' anche possibile inviare un segnale ai processi nginx tramite i normali comandi Unix, +quale ad esempio kill, che invia un segnale al processo individuato tramite il relativo ID; +per default, l'ID del processo master di nginx e' scritto nel file nginx.pid +nella directory +/usr/local/nginx/logs oppure +/var/run . +Ad esempio, se l'ID del processo master e' 1628, per inviare il segnale QUIT, +che causa l'arresto controllato, bisogna eseguire il comando: + +kill -s QUIT 1628 + +Per ottenere la lista di tutti in processi nginx, e' possibile usare vari comandi, +fra cui ad esempio ps +nella maniera seguente: + +ps -ax | grep nginx + +Per ulteriori informazioni su come inviare segnali a ngnix, fare riferimento a +. + + +

+ + +

+ + +nginx e' costituito da moduli che sono controllati da direttiva specificate +nel file di configurazione. +Le direttive possono essere semplici o a blocco. +Una direttiva semplice e' caratterizzata dal nome seguito da parametri separati da spazi, +e termina con punto e virgola (;). +Una direttiva a blocco ha la stessa struttura di una direttiva semplice, +ma, invece che con punto e virgola, termina con un insieme di istruzioni aggiuntive racchiuse +fra parentesi graffe ( { e } ). +Una direttiva che puo' avere altre direttive all'interno delle parentesi graffe e' chiamata +contesto (ad esempio: +, +, +, +e +). +Le direttive del file di configurazione che non sono all'interno di alcun +contesto sono considerate facenti parte del contesto +main. + + + +Le direttive events e http +appartengono al contesto main, la direttiva server +al contesto http, +la direttiva location al contesto server. + + + +Tutto cio' che in una riga segue il simbolo # e' considerato un commento. + + +

+ + +

+ + +Un compito importante di un web server e' costituito dal servizio +di file, quali immagini o pagine HTML statiche. +Di seguito si implementa un esempio in cui, a seconda della richiesta, +i file sono serviti prendendoli da varie directory locali: /data/www +(che puo' contenere file HTML) e /data/images +(che contiene immagini). +Per tale implementazione e' necessaria la modifica del file di configurazione, +con l'aggiunta, +all'interno di un blocco , +di un blocco +a sua volta contenente due blocchi . + + + +Anzitutto, creare le directory /data/www e /data/images, +e aggiungere nella prima un file index.html contenente un testo qualsiasi, +nella seconda una immagine a caso. + + + +Quindi, aprire il file di configurazione; +si puo' notare che contiene gia' diversi esempi di blocchi server, +per la maggior parte inattivati da commenti; +inattivare con commenti tutto il blocco http, e scriverne uno nuovo: + +http { + server { + } +} + +In generale, il file di configurazione puo' includere numerosi blocchi server, +distinti in base alla porta su cui +sono in ascolto e al +nome del server. +Una volta che nginx ha deciso quale server deve processare una data richiesta, +confronta l'URI presente nell'header della stessa con i parametri delle direttive +location definite all'interno del blocco server. + + + +Aggiungere il seguente blocco location +al blocco server: + +location / { + root /data/www; +} + +Questo blocco location fa riferimento al prefisso “/”, +da confrontare con l'URI della richiesta: +se la richiesta corrisponde, l'URI viene aggiunto al path specificato dalla +direttiva , +in questo caso cioe' a /data/www , +per definire sul file system locale il path al file richiesto. +Se i blocchi location che corrispondono sono piu' di uno, +nginx seleziona quello con il prefisso piu' lungo; +il blocco location dell'esempio riguarda il prefisso +piu' breve in assoluto, di lunghezza uno, quindi e' effettivamente usato +solo se tutti gli altri blocchi location non corrispondono. + + + +Tornando all'esempio, aggiungere un secondo blocco location: + +location /images/ { + root /data; +} + +In questo caso ci sara' corrispondenza con +le richieste che iniziano con /images/ +(anche location / corrisponde alla richiesta, +ma ha un prefisso piu' breve e quindi priorita' inferiore). +La configurazione risultante del blocco server risulta quindi: + +server { + location / { + root /data/www; + } + + location /images/ { + root /data; + } +} + +Tale configurazione e' effettivamente funzionante, +con il server in ascolto sulla porta standard 80 e accessibile +sulla macchina locale a http://localhost/ . +In risposta alle richieste di URI che iniziano con /images/ , +il server inviera' file presi dalla directory /data/images ; +ad esempio, in risposta ad una richiesta +http://localhost/images/example.png +nginx inviera' il file /data/images/example.png . +Se tale file non esiste, nginx inviera' una risposta che indica +l'errore 404. +Richieste di URI che non iniziano con /images/ +saranno mappate sulla directory /data/www ; +ad esempio, in risposta ad una richiesta +http://localhost/some/example.html +nginx inviera' il file /data/www/some/example.html . + + + +Per applicare la nuova configurazione, avviare nginx se e' spento; +se e' gia' attivo, inviare il segnale reload al processo master, +eseguendo: + +nginx -s reload + + + + + +Nel caso in cui qualcosa non vada come atteso, e' possibile cercare +di capire cosa e' successo verificandolo nei file access.log e +error.log, presenti nella directory /usr/local/nginx/logs o +/var/log/nginx . + + + +

+ + +

+ + +Uno degli usi piu' frequenti di nginx prevede la configurazione come proxy server, +vale a dire un server che riceve le richieste dai client, le passa ai server remoti, +riceve da essi le risposte, e le reinvia ai client. + + + +Di seguito si configura un semplice proxy server, il quale serve le richieste +di immagini con file da una directory locale, e invia invece tutte le altre +richieste a un ulteriore server web. +Nell'esempio, entrambi i server saranno definiti su una singola istanza di nginx.. + + + +Per iniziare, definire il server web aggiuntivo inserendo nel file di configurazione di +nginx un ulteriore blocco server con il contenuto seguente: + +server { + listen 8080; + root /data/up1; + + location / { + } +} + +Si tratta di un semplice server in ascolto sulla porta 8080 +(in precedenza la direttiva listen non e' stata specificata +in quanto e' stata usata la porta standard 80), che mappa tutte le +richieste sulla directory /data/up1 del file system locale. +Creare tale directory, e inserire in essa un file index.html . +Notare che la direttiva root e' posta nel +contesto server ; tale direttiva root e' usata +quando il blocco location scelto per servire una richiesta +non include una direttiva root propria. + + + +Procedere usando la configurazione del server della sezione precedente e +modificandola per farne un proxy server. +Nel primo blocco location, inserire la direttiva + +specificando come parametro il protocollo, il nome e la porta del server +web aggiuntivo (in questo caso http://localhost:8080 ): + +server { + location / { + proxy_pass http://localhost:8080; + } + + location /images/ { + root /data; + } +} + + + + +A questo punto modificare il secondo blocco location, che al momento +mappa le richieste con il prefisso /images/ sui file nella directory +/data/images , per fare in modo che risponda alle richieste con le +tipiche estensioni file delle immagini. +Il blocco location sara' il seguente: + +location ~ \.(gif|jpg|png)$ { + root /data/images; +} + +Il parametro e' una espressione regolare che corrisponde a tutti gli URI +che terminano con .gif, .jpg, o .png +(in ngnix le espressioni regolari normalmente iniziano con ~ ). +La richiesta corrispondente sara' mappata sulla directory /data/images . + + + +Per decidere quale blocco location debba servire una richiesta, +nginx per prima cosa verifica le direttive + +che riportano la specifica di un prefisso, registrando quella con il piu' lungo +prefisso che corrisponde, quindi verifica quelle con una espressione regolare; +se c'e' corrispondenza con una espressione regolare, nginx sceglie tale +location, altrimenti sceglie quella registrata in precedenza. + + + +Alla fine la configurazione risultante di un proxy server e' la seguente: + +server { + location / { + proxy_pass http://localhost:8080/; + } + + location ~ \.(gif|jpg|png)$ { + root /data/images; + } +} + +Tale server selezionera' le richieste che terminano in .gif, +.jpg o .png e le mappera' sulla directory +/data/images (aggiungendo l'URI al parametro della direttiva +root), mentre invece passera' tutte le altre richieste al web +server configurato in precedenza. + + + +Per applicare la nuova configurazione, inviare il segnale reload +ad nginx, come descritto nella sezione precedente. + + + +Ci sono molte more +direttive che possono essere usate nella configurazione di un proxy. + + +

+ + +

+ + +nginx puo' essere usato per dirigere le richieste ad uno o piu' server +FastCGI che eseguono applicazioni scritte con vari framework e linguaggi di +programmazione, ad esempio PHP. + + + +La configurazione piu' semplice di nginx che consente di lavorare con un server +FastCGI, richiede l'uso della direttiva + +al posto della direttiva proxy_pass, +e della direttiva +per impostare i parametri passati al server FastCGI. +Nel seguito si suppone che il server FastCGI sia accessibile a localhost:9000 . +Prendendo la configurazione di un proxy nella sezione precedente come base, +sostituire la direttiva proxy_pass con la direttiva fastcgi_pass +e cambiare il relativo parametro in localhost:9000 . +Nel caso del PHP, il parametro SCRIPT_FILENAME e' usato per determinare +il nome dello script, ed il parametro QUERY_STRING e' usato per +passare i parametri della richiesta. +La configurazione risulta quindi: + +server { + location / { + fastcgi_pass localhost:9000; + fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; + fastcgi_param QUERY_STRING $query_string; + } + + location ~ \.(gif|jpg|png)$ { + root /data/images; + } +} + +Tale configurazione realizza un server che inoltra tutte le richieste +(a parte quelle per immagini statiche) tramite il protocollo FastCGI +ad un server esterno che opera su +localhost:9000 . + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/control.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/control.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,282 @@ + + + + +

+ +

+ + +nginx puo' essere controllato tramite segnali. +L'ID del processo master e' scritto per default nel file +/usr/local/nginx/logs/nginx.pid. +E' possibile utilizzare un altro file utilizzando la direttiva +, definendola all'avvio +oppure in nginx.conf . +Il processo master riconosce i seguenti segnali: + + + + + + + + + + +

TERM, INT	arresto rapido
QUIT	arresto controllato
HUP	ricaricamento della configurazione, +allineamento ad una diversa zona oraria (solo per FreeBSD e Linux), +riavvio di nuovi processi worker con una nuova configurazione, +spegnimento controllato dei vecchi processi worker
USR1	riapertura dei file di log
USR2	aggiornamento del file eseguibile
WINCH	arresto controllato dei processi worker

+ + + + +E' anche possibile controllare ciascun processo worker, +per quanto cio' non sia richiesto. +I segnali riconosciuti sono: + + + + + + + + +

TERM, INT	arresto rapido
QUIT	arresto controllato
USR1	riapertura dei file di log
WINCH	chiusura anomala per debugging +(richiede ) +

+ + + +

+ + +

+ + +Per far rileggere la configurazione a nginx, bisogna inviare +un segnale HUP al processo master. +Tale processo per prima cosa verifica la validita' sintattica +della nuova configurazione, quindi tenta di applicarla, vale a dire +di aprire i file di log e i nuovi socket di ascolto. +In caso di fallimento, annulla i cambiamenti e continua a lavorare +con la vecchia configurazione. +Invece, in caso di successo, avvia nuovi processi worker e invia a +quelli vecchi appositi segnali per chiederne l'arresto controllato. +I vecchi processi chiudono i socket di ascolto, ma continuano il +servizio per i vecchi client. +Quanto tutti i vecchi client sono stati servizi, i vecchi +processi worker terminano. + + + +Di seguito si illustra con un esempio. +Si immagini che nginx sia in esecuzione su FreeBSD 4.x +e che il comando + +ps axw -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)' + +produca il seguente risultato: + + PID PPID USER %CPU VSZ WCHAN COMMAND +33126 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx +33127 33126 nobody 0.0 1380 kqread nginx: worker process (nginx) +33128 33126 nobody 0.0 1364 kqread nginx: worker process (nginx) +33129 33126 nobody 0.0 1364 kqread nginx: worker process (nginx) + + + + +Se al processo master si invia il segnale HUP, si ottiene: + + PID PPID USER %CPU VSZ WCHAN COMMAND +33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx +33129 33126 nobody 0.0 1380 kqread nginx: worker process is shutting down (nginx) +33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) +33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) +33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) + + + + +Uno dei vecchi processi worker con PID 33129 continua ad essere attivo; +dopo un po', esce: + + PID PPID USER %CPU VSZ WCHAN COMMAND +33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx +33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) +33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) +33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) + + + +

+ + +

+ + +Per poter ruotare i file di log, e' prima necessario cambiare loro il nome, +quindi bisogna inviare il segnale USR1 al processo master, +il quale provvede a riaprire tutti i file di log correnti e ad +assegnarli all'utente non privilegiato sotto i quali sono in +esecuzione i processi worker. +Dopo aver riaperto con successo i file, il processo master chiude tutti +i file aperti, ed invia un messaggio ai processi worker per chiedere loro +di riaprire i file; i processi worker provvedono quindi immediatamente +ad aprire i nuovi file ed a chiudere i vecchi. +Come risultato, i vecchi file sono quasi immediatamente disponibili per +eventuali attivita' successive, ad esempio per la compressione. + + +

+ + +

+ + +Per poter aggiornare l'eseguibile del server, prima e' necessario +porre il nuovo file al posto del vecchio; dopo, bisogna inviare al +processo master il segnale USR2. +Il processo master provvede a rinominare il file contenente il proprio +ID di processo, aggiungendo il suffisso .oldbin, ad +esempio /usr/local/nginx/logs/nginx.pid.oldbin, +quindi avvia un nuovo file eseguibile, che a sua volta fa partire i +propri processi worker: + + PID PPID USER %CPU VSZ WCHAN COMMAND +33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx +33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) +33135 33126 nobody 0.0 1380 kqread nginx: worker process (nginx) +33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) +36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx +36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) +36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) +36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) + + + + + + +A questo punto, sia i processi worker relativi al vecchio eseguibile, sia quelli +relativi al nuovo, accettano richieste. +Se al processo master e' inviato il segnale WINCH, tutti i relativi processi +worker ricevono a loro volta un segnale che chiede loro l'arresto controllato, +e quindi iniziano a spegnersi: + + PID PPID USER %CPU VSZ WCHAN COMMAND +33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx +33135 33126 nobody 0.0 1380 kqread nginx: worker process is shutting down (nginx) +36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx +36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) +36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) +36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) + + + + + +Quando su Linux si usa il metodo "rtsig", i nuovi processi potrebbero non +accettare connessioni anche dopo che al processo master vecchio e' stato +inviato il segnale WINCH. +In tal caso, bisogna continuare ad inviare il segnale USR1 al nuovo processo +master, sinche' i nuovi processi iniziano ad accettare connessioni. + + + + +In breve, i soli processi worker a processare le richieste saranno quelli nuovi: + + PID PPID USER %CPU VSZ WCHAN COMMAND +33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx +36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx +36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) +36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) +36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) + + + + +Si noti che il vecchio processo master non chiude i suoi socket di ascolto, +e che se necessario e' possibile chiedergli di riavviare i propri +processi worker. +Se per qualche ragione il nuovo file eseguibile non lavora correttamente, +e' possibile procedere in due modi: + + + + +inviare il segnale HUP al vecchio processo master. +Il vecchio processo master provvedera' ad avviare +nuovi processi worker, senza rileggere la configurazione. +A questo punto, tutti i nuovi processi possono essere fermati +in maniera controllata, inviando il segnale QUIT al nuovo +processo master. + + + + + +inviare il segnale TERM al nuovo processo master. +Tale processo inviare a sua volta un messaggio ai suoi processi +worker che causera' la loro chiusura immediata. +(Se per qualche ragione i nuovi processi non terminano, e' +possibile inviare loro il segnale KILL per forzarne la chiusura.) +Quando il nuovo processo master si e' chiuso, il vecchio processo +master provvedera' immediatamente ad avviare nuovi processi worker. + + + + + + + + +Se il nuovo processo master termina, allora in vecchio processo master +provvede a cancellare il suffisso .oldbin dal nome del file +contenente l'ID del processo. + + + +Se l'aggiornamento ha successo, al vecchio processo master dovrebbe +essere inviato il segnale QUIT, in maniera che rimangano solo i +processi nuovi: + + PID PPID USER %CPU VSZ WCHAN COMMAND +36264 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx +36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) +36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) +36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) + + + + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/debugging_log.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/debugging_log.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,84 @@ + + + + +

+ + +

+ + +Per poter abilitare il log di debug, +nginx deve essere stato configurato appositamente in +fase di compilazione: + + +./configure --with-debug ... + + +Dopo di cio', e' possibile configurare il livello di +debug tramite la direttiva +: + + +error_log /path/to/log debug; + + +La versione binaria di nginx per Windows e' sempre compilata +con tale supporto, per cui in questo caso e' sufficiente +configurare il livello di debug. + + + +Si tenga presente che ridefinire il log senza anche +specificare il livello di debug +causa la disabilitazione del log. +Nell'esempio che segue, la ridefinizione del log nel livello + +disabilita il log di debug per tale server: + +error_log /path/to/log debug; + +http { + server { + error_log /path/to/log; + ... + +Se ridefinire il log risulta necessario, per non +incorrere in questo problema bisogna indicare +esplicitamente il livello di debug: + +error_log /path/to/log debug; + +http { + server { + error_log /path/to/log debug; + ... + + + + +E' pure possibile abilitare il debug solo +per +indirizzi client specifici: + + +error_log /path/to/log; + +events { + debug_connection 192.168.1.1; + debug_connection 192.168.10.0/24; +} + + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/events.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/events.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,114 @@ + + + + +

+ +

+ + +nginx supporta diversi metodi di processo delle connessioni. +La disponibilita' di un particolare metodo dipende dalla piattaforma usata; +su piattaforme che supportano piu' di un metodo, nginx in genere +e' in grado di selezionare automaticamente il metodo piu' efficiente. +Comunque, se necessario, e' possibile scegliere esplicitamente il metodo +di processo delle connessioni tramite la direttiva +. + + + +I metodi di processo delle connessioni sono i seguenti: + + + + +select—metodo standard. +Il relativo modulo e' compilato automaticamente se la piattaforma non +rende possibile l'uso di metodi piu' efficienti. +E' possibile usare i parametri di configurazione +--with-select_module e +--without-select_module +per abilitare o disabilitare esplicitamente la compilazione di tale modulo. + + + + + +poll—metodo standard. +Il relativo modulo e' compilato automaticamente se la piattaforma non +rende possibile l'uso di metodi piu' efficienti. +E' possibile usare i parametri di configurazione +--with-poll_module e +--without-poll_module +per abilitare o disabilitare esplicitamente la compilazione di tale modulo. + + + + + +kqueue—metodo efficiente usato su +FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0, e Mac OS X. + + + + + +epoll—metodo efficiente usato su +Linux 2.6+. + +Alcune distribuzioni piu' vecchie, ad esempio SuSE 8.2, forniscono +patch che rendono possibile l'uso di questo modulo su kernel 2.4. + + + + + + +rtsig—real time signals, metodo efficiente usato su +Linux 2.2.19+. +Per default, la coda di eventi del sistema e' limitata a 1024 segnali; +su server particolarmente carichi puo' risultare necessario incrementare +tale limite, intervenendo sul parametro del kernel +/proc/sys/kernel/rtsig-max . +Comunque, a partire da Linux 2.6.6-mm2 tale parametro non e' piu' disponibile +e ciascun processo dispone della propria coda di eventi. +La dimensione di ciascuna coda e' definita da RLIMIT_SIGPENDING +e puo' essere modificata tramite il parametro +. + + + +In caso di overflow, nginx scarta del tutto la coda e passa all'uso del +metodo di processo poll sinche' la situazione non +torna normale. + + + + + +/dev/poll—metodo efficiente usato su +Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+, +e Tru64 UNIX 5.1A+. + + + + + +eventport—event ports, metodo efficiente usato su +Solaris 10. + + + + + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/hash.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/hash.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,54 @@ + + + + +

+ +

+ + +Per processare rapidamente insiemi di dati, quali ad esempio +nomi di server, valori relativi alla direttiva +, +MIME type, stringhe di nomi di header di richiesta, +ngnix usa tabelle di hash. +Durante l'avvio ed in seguito ad ogni rilettura della configurazione, +nginx seleziona la minore dimensione possibile delle tabelle +di hash, tale che la dimensione del bucket che memorizza le chiavi +con identico valore hash non superi il relativo parametro configurato +(hash bucket size). +La dimensione di una tabella e' espressa in bucket; tale dimensione +viene regolata continuamente, sinche' la dimensione non eccede il +valore configurato (hash max size). +Molti hash dispongono di specifiche direttive che consentono la modifica +di tali parametri; ad esempio, per l'hash dei nomi dei server esistono + +e . + + + +Il parametro hash bucket size e' allineato ad una dimensione +multipla di quella di una linea di cache del processore utilizzato; +nei moderni processori cio' riduce il numero di accessi alla memoria +e quindi il tempo necessario a ricercare la chiave di un hash. +Se la dimensione del bucket hash e' pari a quella di una linea di +cache, allora il numero di accessi alla memoria durante la ricerca di +una chiave sara' nel peggiore dei casi pari a due —uno per l'indirizzo +del bucket, l'altro durante la ricerca della chiave nel bucket. +Per tale ragione, se nginx mostra un messaggio che suggerisce +l'incremento o della dimensione massima dell'hash oppure della +dimensione del bucket hash, e' preferibile intervenire anzitutto +sul primo dei due parametri e non modificare per quanto possibile +il secondo. + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/http/configuring_https_servers.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/http/configuring_https_servers.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,521 @@ + + + + +

+ +

+ + +Per configurare un server HTTPS, bisogna configurare il parametro +ssl nel +socket in ascolto +del blocco , +e specificare dove sono i file del certificato del server e della relativa +chiave private: + + +server { + listen 443 ssl; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; + ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; + ssl_ciphers HIGH:!aNULL:!MD5; + ... +} + + +Il certificato del server e' pubblico: e' inviato a tutti i client che +si connettono al server; la chiave privata al contrario non e' pubblica, +e dovrebbe essere salvata in un file con restrizioni d'accesso, e +comunque non leggibile dal processo master di nginx. +In alternativa, la chiave privata puo' essere salvata nel medesimo file +del certificato: + + + ssl_certificate www.example.com.cert; + ssl_certificate_key www.example.com.cert; + + +pure in questo caso i diritti d'accesso al file dovrebbero essere ristretti. +Anche quando certificato e chiave privata sono salvati entrambi +in un unico file, solo il certificato e' inviato al client. + + + +Le direttive e + possono essere usate +per limitare l'uso alle sole versioni e cifrature forti di SSL/TLS nelle +connessioni. +nginx usa per default “ssl_protocols SSLv3 TLSv1” e +“ssl_ciphers HIGH:!aNULL:!MD5” sin dalla versione 1.0.5, +per cui una configurazione esplicita ha senso solo per le versioni di ngnix +piu' vecchie. Dalle versioni 1.1.13 e 1.0.12 nginx usa per default +“ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2”. + + + +La modalita' di cifratura CBC e' potenzialmente vulnerabile ad una serie +di attacchi, in particolare ad un attacco BEST (vedi +CVE-2011-3389). +La configurazione della cifratura puo' essere modificata in maniera da +utilizzare RC4-SHA: + + + ssl_ciphers RC4:HIGH:!aNULL:!MD5; + ssl_prefer_server_ciphers on; + + + +

+ + +

+ + +Le operazioni SSL utilizzano pesantemente la CPU. Su sistemi +multiprocessore e' bene avviare processi worker in numero almeno pari a +quello dei core. +L'operazione piu' gravosa per la CPU e' l'handshake SSL. +Ci sono due modi per minimizzare il numero di tali operazioni per client: +il primo consiste nell'abilitare connessioni keepalive per inviare diverse +richieste tramite un'unica connessione; il secondo prevede di riutilizzare +i parametri della sessione SSL in maniera tale da evitare l'handshake SSL +per connessioni parallele e susseguenti. +Le sessioni sono salvate in una cache di sessione SSL, condivisa fra i +worker e configurata dalla direttiva +. + +Un megabyte di cache contiene circa 4000 sessioni. Il timeout di default della +cache e' di 5 minuti; puo' essere aumentato intervenendo sulla direttiva +. +Segue una configurazione di esempio ottimizzata per un sistema multicore con +10 megabyte di cache di sessione condivisa: + + +worker_processes auto; + +http { + ssl_session_cache shared:SSL:10m; + ssl_session_timeout 10m; + + server { + listen 443 ssl; + server_name www.example.com; + keepalive_timeout 70; + + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; + ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; + ssl_ciphers HIGH:!aNULL:!MD5; + ... + + + +

+ + +

+ + +Capita talvolta che alcuni certificati server firmati da autorita' di +certificazione ben note siano tranquillamente accettati da alcuni browser, +ma mostrino invece problemi con altri. Cio' succede quando' l'autorita' +emittente ha firmato il certificato usandone uno intermedio che non e' +presente nell'elenco delle autorita' di certificazione distribuito con +uno specifico browser. +In tal caso l'autorita' fornisce un gruppo di certificati che dovrebbero +essere concatenati al certificato server firmato. +Il certificato server deve comparire prima dei certificati concatenati +nel file risultante: + + +$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt + + +Il file che ne deriva va usato con la direttiva +: + + +server { + listen 443 ssl; + server_name www.example.com; + ssl_certificate www.example.com.chained.crt; + ssl_certificate_key www.example.com.key; + ... +} + + +Se il certificato server ed il gruppo di certificati sono stati concatenati +nell'ordine sbagliato, nginx non riuscira' a partire e mostrera' il +seguente messaggio di errore: + + +SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed + (SSL: error:0B080074:x509 certificate routines: + X509_check_private_key:key values mismatch) + + +dato che nginx ha tentato di usare la chiave privata non con il certificato +server ma con il primo certificato del gruppo. + + + +Di solito i browser salvano i certificati intermedi che ricevono se sono +firmati da autorita' di certificazione riconosciute, per cui browser molto +usati potrebbero gia' avere i certificati intermedi richiesti, e quindi +non avere problemi anche quando ricevono un certificato privo della +relativa concatenazione di certificati. +Comunque, per assicurare che il server invii la concatenazione di certificati +completa, e' possibile usare da linea di comando il programma +openssl, ad esempio: + + +$ openssl s_client -connect www.godaddy.com:443 +... +Certificate chain + 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US + /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc + /OU=MIS Department/CN=www.GoDaddy.com + /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b) + i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. + /OU=http://certificates.godaddy.com/repository + /CN=Go Daddy Secure Certification Authority + /serialNumber=07969287 + 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. + /OU=http://certificates.godaddy.com/repository + /CN=Go Daddy Secure Certification Authority + /serialNumber=07969287 + i:/C=US/O=The Go Daddy Group, Inc. + /OU=Go Daddy Class 2 Certification Authority + 2 s:/C=US/O=The Go Daddy Group, Inc. + /OU=Go Daddy Class 2 Certification Authority + i:/L=ValiCert Validation Network/O=ValiCert, Inc. + /OU=ValiCert Class 2 Policy Validation Authority + /CN=http://www.valicert.com//emailAddress=info@valicert.com +... + + +In questo esempio, il soggetto (“s”, vale a dire "subject") +del certificato server #0 www.GoDaddy.com e' firmato da +un emittente (“i”, vale a dire "issuer") che a sua volta e' +il soggetto del certificato #1, il quale e' firmato da un emittente che e' +il soggetto del certificato #2, che e' finalmente firmato dalla autorita' +di certificazione ben nota ValiCert, Inc., il cui certificato e' +presente nella base dati precaricata del browser +("che al mercato mio padre compro'"). + + + +Se il gruppo di certificati non fosse stato aggiunto, sarebbe stato +visualizzato il solo certificato #0. + + +

+ + +

+ + +E' possibile configurare un singolo server che tratti sia richieste HTTP, +sia richieste HTTPS: + + +server { + listen 80; + listen 443 ssl; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; + ... +} + + + +Prima della versione 0.7.14, SSL non poteva essere abilitato +selettivamente per singoli socket in ascolto, come nell'esempio +precedente: SSL poteva solo essere abilitato per l'intero server, +usando la direttiva , +e rendendo quindi impossibile la configurazione di un server +unico per HTTP e HTTPS. +Il parametro ssl della direttiva + e' stato aggiunto +per risolvere questo problema. L'uso della direttiva + +e' pertanto sconsigliato nelle versioni recenti. + + + +

+ + +

+ + +Quando si configurano due o piu' server HTTPS in ascolto su un singolo +indirizzo IP, sorge spesso un problema: + + +server { + listen 443 ssl; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ... +} + +server { + listen 443 ssl; + server_name www.example.org; + ssl_certificate www.example.org.crt; + ... +} + + +Con questa configurazione un browser riceve il certificato del server di default, +vale a dire www.example.com, indipendentemente da quale sia +il nome del server richiesto. Cio' e' causato dal comportamento del protocollo +SSL: la connessione SSL si stabilisce prima che il browser invii una richiesta +HTTP, percio' quando nginx ancora non sa quale sara' il nome del server richiesto; +per tale ragione, non puo' fare altro che offrire il certificato del server di default. + + + +Il metodo classico per risolvere questo problema consiste nell'assegnare +un indirizzo IP distinto a ciascun server HTTPS: + + +server { + listen 192.168.1.1:443 ssl; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ... +} + +server { + listen 192.168.1.2:443 ssl; + server_name www.example.org; + ssl_certificate www.example.org.crt; + ... +} + + + + +

+ + +Ci sono altre maniere tramite cui condividere un singolo indirizzo IP +fra molti server HTTPS, tutte comunque non prive di problemi. +Ad esempio, e' possibile usare un certificato con diversi nomi di server +nel campo SubjectAltName, per esempio +www.example.com and www.example.org, +tuttavia la lunghezza del campo SubjectAltName e' limitata. + + + +Un'altra tecnica prevede l'uso di un certificato il cui nome e' definito con +caratteri jolly, per esempio *.example.org. +Un certificato con caratteri jolly va bene per tutti i sottodomini del +dominio specificato, ma per un solo livello: in questo caso ad esempio +verra' riconosciuta corrispondenza con www.example.org, +ma non con example.org e www.sub.example.org. +I due metodi mostrati possono essere combinati: nel campo SubjectAltName +un certificato puo' contenere sia nomi esatti sia nomi con caratteri jolly, +ad esempio example.org e *.example.org. + + + +Nel caso in cui si usi un certificato con nomi multipli, e' bene +indicare la posizione del relativo file e della chiave nel livello +http della configurazione, in maniera da avere una singola +copia in memoria da far ereditare a tutti i server: + + +ssl_certificate common.crt; +ssl_certificate_key common.key; + +server { + listen 443 ssl; + server_name www.example.com; + ... +} + +server { + listen 443 ssl; + server_name www.example.org; + ... +} + + + +

+ + +

+ + +Una soluzione piu' generale per l'uso di server HTTPS multipli su un singolo +indirizzo IP e' data dalla +estensione +TLS Server Name Indication (SNI, RFC 6066), che consente ad un +browser di indicare il nome del server richiesto durante l'handshake SSL e, +percio', permette al server di sapere quale certificato dovrebbe essere +usato durante la connessione. Purtroppo, SNI ha un supporto piuttosto +limitato nei browser; al momento e' supportato a partire dalle seguenti +versioni: + + + + + + +Opera 8.0; + + + +MSIE 7.0 (ma solo su Windows Vista o superiore); + + + +Firefox 2.0 e altri browser che usano Mozilla Platform rv:1.8.1; + + + +Safari 3.2.1 (la versione per Windows supporta SNI su Vista o superiore); + + + +Chrome (la versione per Windows supporta SNI su Vista o superiore). + + + + +Con SNI e' possibile passare solo nomi di dominio, tuttavia alcuni browser +potrebbero erroneamente consentire di passare come nome anche l'indirizzo +IP del server. +E' bene comunque non fare affidamento su questo comportamento. + + + + +Per poter usare SNI in nginx, e' necessario che sia supportato sia nella +libreria OpenSSL con cui il binario e' stato compilato, sia nella +libreria a cui e' linkato dinamicamente in esecuzione. +OpenSSL supporta SNI sin dalla versione 0.9.8f, a patto che sia stata +compilata con l'opzione di configurazione “--enable-tlsext”; +dalla versione 0.9.8j tale opzione e' abilitata per default. +Se nginx e' compilato con il supporto a SNI, allora l'esecuzione con +il parametro “-V” mostra: + + +$ nginx -V +... +TLS SNI support enabled +... + + +Di contro, se nginx e' stato compilato con il supporto a SNI, ma la libreria +OpenSSL a cui e' linkato dinamicamente ne e' priva, viene mostrato: + + +nginx was built with SNI support, however, now it is linked +dynamically to an OpenSSL library which has no tlsext support, +therefore SNI is not available + + + +

+ +

+ + +

+ + + + + +Il parametro “-V” mostra lo stato del supporto a SNI +dalla versione 0.8.21 e 0.7.62 in poi. + + + +Il parametro ssl della direttiva + +e' supportato +dalla versione 0.7.14 in poi; +prima della versione 0.8.21 poteva essere specificato solo +insieme al parametro default. + + + +SNI e' supportato +dalla versione 0.5.32 in poi. + + + +La cache condivisa di sessione SSL e' supportata +dalla versione 0.5.6 in poi. + + + + + + + + + +Versioni 0.7.65, 0.8.19 e successive: i protocolli SSL default sono SSLv2, TLSv1, +e TLSv1.2 (se supportati dalla libreria OpenSSL). + + + +Versioni 0.7.64, 0.8.18 e precedenti: i protocolli SSL default sono SSLv2, +SSLv3, e TLSv1. + + + + + + + + + +Versioni 1.0.5 e successive: i sistemi di cifratura SSL default sono +“HIGH:!aNULL:!MD5”. + + + +Versioni 0.7.65, 0.8.20 e successive: i sistemi di cifratura SSL default sono +“HIGH:!ADH:!MD5”. + + + +Versione 0.8.19: i sistemi di cifratura SSL default sono +“ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”. + + + +Versioni 0.7.64, 0.8.18 e precedenti: i sistemi di cifratura SSL default sono
+“ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”. + + + + + + +

+ + +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/http/request_processing.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/http/request_processing.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,302 @@ + + + + +

+ +

+ + +La prima cosa che nginx fa e' decidere quale server deve +processare la richiesta. Si consideri una semplice configurazione +in cui tutti i tre server virtuali sono in ascolto sulla porta *:80 : + +server { + listen 80; + server_name example.org www.example.org; + ... +} + +server { + listen 80; + server_name example.net www.example.net; + ... +} + +server { + listen 80; + server_name example.com www.example.com; + ... +} + + + + + +In questa configurazione nginx verifica solo il campo

Host

+dell'header di richiesta, per determinare a quale server la richiesta debba +essere assegnata. +Se il suo valore non corrisponde con quello di alcun nome di server, +oppure se la richiesta semplicemente non contiene tale campo dell'header, +allora nginx assegna la richiesta al server di default per la relativa porta. +Nella configurazione precedente, il server di default e' il primo—si +tratta del comportamento standard di nginx. +E' anche possibile indicare esplicitamente il server di default, tramite il +parametro default_server nella direttiva + : + +server { + listen 80 default_server; + server_name example.net www.example.net; + ... +} + + + +Il parametro default_server e' disponibile a partire dalla +versione 0.8.21 di nginx. +Nelle versioni precedenti bisogna usare invece il parametro +default. + +Si noti che il server di default e' una proprieta' della porta in ascolto, +e non del nome del server; l'argomento sara' ripreso in seguito. + + +

+ + +

+ + +Se si desidera che le richieste prive dell'header

Host

+non siano processate, e' possibile definire un server che si limita a scartarle: + +server { + listen 80; + server_name ""; + return 444; +} + +In questo caso il nome del server e' definito con una stringa vuota, +la quale corrispondera' a tutte le richieste prive del campo +

Host

dell'header; per chiudere la connessione nginx +restituisce il codice 444 (non standard). + +A partire dalla versione 0.8.48 quella descritta e' la configurazione +default per i nomi di server, per cui e' possibile omettere +server_name "". +Nelle versioni precedenti, come nome del server di default si utilizzava +l'hostname della macchina. + + + +

+ + +

+ + +Una configurazione piu' complessa prevede vari server virtuali +in ascolto su indirizzi differenti: + +server { + listen 192.168.1.1:80; + server_name example.org www.example.org; + ... +} + +server { + listen 192.168.1.1:80; + server_name example.net www.example.net; + ... +} + +server { + listen 192.168.1.2:80; + server_name example.com www.example.com; + ... +} + +In tale configurazione nginx dapprima confronta l'indirizzo IP +e la porta della richiesta con le direttive + dei blocchi +; +quindi, per ciascun blocco per cui c'e' corrispondenza, nginx confronta +il campo

Host

dell'header della richiesta con i +valori del blocco. +Se il nome del server non e' presente in alcun blocco, la richiesta +viene processata dal server di default. +Ad esempio, una richiesta per www.example.com +ricevuta sulla porta 192.168.1.1:80, sara' processata dal server di +default di 192.168.1.1:80, vale a dire dal primo server, in quanto non +c'e' alcun nome www.example.com definito per tale +combinazione di indirizzo e porta. + + + +Si precisa nuovamente che il server di default e' una proprieta' di +indirizzo e porta in ascolto, e che e' possibile definire server di +default differenti per combinazioni differenti di indirizzo e porta: + +server { + listen 192.168.1.1:80; + server_name example.org www.example.org; + ... +} + +server { + listen 192.168.1.1:80 default_server; + server_name example.net www.example.net; + ... +} + +server { + listen 192.168.1.2:80 default_server; + server_name example.com www.example.com; + ... +} + + + + +

+ + +

+ + +Nel seguito si analizza come nginx scelga la location per +processare una richiesta nel caso di un tipico, semplice sito PHP: + +server { + listen 80; + server_name example.org www.example.org; + root /data/www; + + location / { + index index.html index.php; + } + + location ~* \.(gif|jpg|png)$ { + expires 30d; + } + + location ~ \.php$ { + fastcgi_pass localhost:9000; + fastcgi_param SCRIPT_FILENAME + $document_root$fastcgi_script_name; + include fastcgi_params; + } +} + + + + + +Per prima cosa nginx individua fra tutte le location definite da una +stringa quella con il prefisso specifico piu' lungo (l'ordine con cui +sono elencate non e' rilevante); nella configurazione precedente il +solo prefisso definito e' “/”, che trova +corrispondenza in qualsiasi richiesta e che quindi verra' comunque +preso in considerazione, come ultima risorsa. +Successivamente, nginx analizza le location definite tramite una +espressione regolare, fermandosi appena ne individua una che +corrisponde (in questo caso l'ordine in cui sono inserite nel file +di configurazione e' rilevante in quanto nginx parte dalla prima e le +analizza una dopo l'altra). La prima location individuata fra quelle +definite come espressione regolare e' quella prescelta; se non ce n'e' +nessuna, nginx ripiega su quella individuata al passo precedente tramite +il prefisso. + + + + +Notare che tutti i tipi di location sono confrontati con il solo URI +della linea di richiesta, senza argomenti; +cio' e' dovuto al fatto che gli argomenti nella stringa di richiesta +possono essere inviati in vari modi, ad esempio: + +/index.php?user=john&page=1 +/index.php?page=1&user=john + +Inoltre, nella stringa di richiesta e' possibile scrivere qualsiasi cosa: + +/index.php?page=1&something+else&user=john + + + + + +Seguono alcuni esempi di processo di richieste in base alla +configurazione precedente: + + + +Una richiesta “/logo.gif” corrisponde al prefisso +di location “/”, ma anche all'espressione regolare +“\.(gif|jpg|png)$”, per cui si utilizzera' quest'ultima +corrispondenza in quanto, come spiegato in precedenza, le espressioni +regolari hanno sempre priorita' sulle stringhe fisse. +Usando la direttiva “root /data/www” la richiesta +e' mappata sul file /data/www/logo.gif , che quindi e' inviato +al client. + + + +Una richiesta “/index.php” corrisponde sia al prefisso +“/” sia all'espressione regolare +“\.(php)$”, per cui sara' processata da quest'ultima +sezione della configurazione, e la richiesta sara' inoltrata al server +FastCGI in ascolto su localhost:9000. +La direttiva + +imposta il parametro FastCGI +SCRIPT_FILENAME a “/data/www/index.php”, +ed il server FastCGI esegue il file. +La variabile $document_root contiene il valore della direttiva +, e la variabile +$fastcgi_script_name il valore della richiesta URI, vale a dire +“/index.php”. + + + +Una richiesta “/about.html” corrisponde al solo prefisso +“/”, per cui sara' processata da questa sezione. +La direttiva “root /data/www” mappa la richiesta sul file +/data/www/about.html, che e' inviato al client. + + + +Una richiesta “/” e' processata in maniera piuttosto +complessa. Corrisponde al solo prefisso “/”, per cui e' +processata dalla relativa sezione; la direttiva +, +in accordo ai propri parametri e alla direttiva +“root /data/www”, verifica la presenza di eventuali file index. +Se il file /data/www/index.html non esiste, ma esiste invece il +file /data/www/index.php , allora la direttiva esegue una +redirezione interna su “/index.php”, e nginx ricerca +nuovamente le location, come se si trattasse di una richiesta del client. +Come visto in precedenza, alla fine la richiesta rediretta e' processata +dal server FastCGI. + + + + + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/http/server_names.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/http/server_names.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,513 @@ + + + + +

+ + +

+ + +I nomi dei server, definiti usando la direttiva +, +determinano quale blocco + +viene usato per una data richiesta (per approfondire vedi +"”). + +I nomi possono essere definiti tramite una stringa determinata, +oppure con caratteri jolly, oppure ancora tramite espressioni regolari: + + +server { + listen 80; + server_name example.org www.example.org; + ... +} + +server { + listen 80; + server_name *.example.org; + ... +} + +server { + listen 80; + server_name mail.*; + ... +} + +server { + listen 80; + server_name ~^(?<user>.+)\.example\.net$; + ... +} + + + + +Nel corso della ricerca di un server virtuale name-based, se il nome corrisponde +a piu' di una delle definizioni, ad esempio sia a nomi definiti tramite +caratteri jolly che a nomi definiti tramite espressioni regolari, verra' scelta +la prima variante individuata, secondo il seguente ordine di precedenza decrescente: + + + +nome esatto + + + +fra quelli definiti con caratteri jolly, il piu' lungo nome che comincia per +asterisco, ad esempio “*.example.org” + + + +fra quelli definiti con caratteri jolly, il piu' lungo nome che termina per +asterisco, ad esempio “mail.*” + + + +fra quelli definiti come espressioni regolare, il primo corrispondente +(in base all'ordine con cui compaiono nel file di configurazione) + + + + + +

+ + +

+ + +Un nome con caratteri jolly puo' contenere un asterisco solo all'inizio +o alla fine del nome, e solo accanto ad un punto; ad esempio, i nomi +“www.*.example.org” +e “w*.example.org” non sono validi (pero' e' +possibile definirli tramite espressioni regolari, per esempio in questo +caso “~^www\..+\.example\.org$” e +“~^w.*\.example\.org$”). +Un asterisco puo' corrispondere a piu' parti di un nome: +“*.example.org” corrisponde non solo a +www.example.org ma anche a +www.sub.example.org. + + + +E' possibile definire un nome speciale nella forma +“.example.org”, che corrisponde sia al nome esatto +“example.org” sia al nome con caratteri jolly +“*.example.org”. + + +

+ + +

+ + +Le espressioni regolari usate da nginx sono compatibili con quelle usate +dal linguaggio di programmazione Perl (PCRE). +Per usare una espressione regolare, il nome del server deve iniziare con +il carattere tilde: + + +server_name ~^www\d+\.example\.net$; + + +altrimenti viene considerato e trattato come un nome esatto, oppure, +se l'espressione contiene un asterisco, come un nome con caratteri jolly +(e molto probabilmente come uno non valido). +E' importante non dimenticare i caratteri ancora “^” e +“$”: non sono necessari dal punto di vista sintattico, +ma lo sono da quello logico. +Si noti inoltre che i caratteri punto nei nomi di dominio sono definiti +facendoli precedere da “\”. +Una espressione regolare contenente i caratteri “{” e +“}”, deve essere racchiusa fra doppi apici: + + +server_name "~^(?<name>\w\d{1,3}+)\.example\.net$"; + + +altrimenti nginx non sara' in grado di avviarsi e mostrera' l'errore: + + +directive "server_name" is not terminated by ";" in ... + + +La sezione catturata di una espressione regolare che definisce un nome +puo' essere usata in seguito come una variabile: + + +server { + server_name ~^(www\.)?(?<domain>.+)$; + + location / { + root /sites/$domain; + } +} + + +La libreria PCRE supporta sezioni catturate di nomi tramite la seguente sintassi: + + + + + + + + + + + + + + + + + + +

?<nome>	Sintassi compatibile con Perl 5.10, supportata da PCRE-7.0 in poi
?'nome'	Sintassi compatibile con Perl 5.10, supportata da PCRE-7.0 in poi
?P<nome>	Sintassi compatibile con Python, supportata da PCRE-4.0 in poi

+ +Quando nginx non riesce ad avviarsi e mostra il seguente messaggio d'errore: + + +pcre_compile() failed: unrecognized character after (?< in ... + + +significa che la libreria PCRE e' troppo vecchia, per cui e' bene provare +ad usare invece la sintassi: +“?P<name>”. +E' possibile riferirsi a sezioni catturate anche usando cifre: + + +server { + server_name ~^(www\.)?(.+)$; + + location / { + root /sites/$2; + } +} + + +Comunque, tale uso dovrebbe essere limitato ai casi piu' semplici (come +ad esempio quello appena mostrato), dato che i riferimenti con cifra +possono essere sovrascritti facilmente. + + + +

+ + +

+ + +Alcuni nomi di server sono trattati in maniera speciale. + + + +Se si desidera che le richieste prive del campo

Host

+dell'header siano processato in un blocco + +che non e' quello di default, e' necessario specificare un nome vuoto: + + +server { + listen 80; + server_name example.org www.example.org ""; + ... +} + + + + + +Se in un blocco +non e' specificato alcun , +allora nginx usa il nome vuoto come nome del server. + +sino alla versione 0.8.48, in questi casi nginx usava l'hostname della +macchina come nome del server. + + + + +Se il nome del server e' definito come “$hostname” (0.9.4), +il nome del server effettivamente usato e' l'hostname della macchina. + + + +Se viene fatta una richiesta usando l'indirizzo IP invece di un nome di server, +il campo

Host

dell'header di richiesta conterra' l'indirizzo IP, +e la richiesta potra' essere processata usando l'indirizzo IP come nome del server: + + +server { + listen 80; + server_name example.org + www.example.org + "" + 192.168.1.1 + ; + ... +} + + + + +In molti esempi di configurazione di un server catch-all e' spesso possibile +notare l'uso di uno strano nome +“_”: + + +server { + listen 80 default_server; + server_name _; + return 444; +} + + +Tale nome non ha niente di speciale, si tratta di un nome qualsiasi, +scelto piu' o meno a caso fra quelli non validi come nome di dominio. +Altri esempi di nomi non validi che sono talvolta pure usati sono +“--” e “!@#”. + + + +Sino alla versione 0.6.25 nginx supportava il nome speciale +“*”, che e' stato spesso interpretato erroneamente +come un nome, non valido, per un server catch-all. +In effetti, non si e' mai trattato di un nome per un server catch-all o +di un nome con caratteri jolly: piuttosto, serviva a fornire la funzionalita' +attualmente affidata alla direttiva +. +Il nome speciale “*” e' attualmente sconsigliato, +ed e' considerato preferibile l'uso della direttiva +. +Si noti che non c'e' alcun modo di specificare un nome catch-all o un +server di default usando la direttiva +: +si tratta di una proprieta' della direttiva + +e non della direttiva + +Si faccia riferimento anche a +“”. +E' possibile definire server in ascolto sulle porte *:80 e *:8080, +e specificare che uno e' quello di default per la porta *:8080, +mentre l'altro e' quello di default per la porta *:80: + + +server { + listen 80; + listen 8080 default_server; + server_name example.net; + ... +} + +server { + listen 80 default_server; + listen 8080; + server_name example.org; + ... +} + + + + +

+ + +

+ + +I nomi esatti, i nomi con caratteri jolly che iniziano per asterisco, +ed i nomi con caratteri jolly che terminano per asterisco, +sono registrati in tre tabelle di hash collegate alle porte in ascolto. +Le dimensioni delle tabelle sono ottimizzate in fase di configurazione, +in maniera tale che i nomi possano essere recuperati con il minimo numero +di miss alla cache della CPU. +Dettagli su come configurare le tabelle di hash sono forniti in un +documento apposito. + + + +La prima tabella di hash consultata e' quella dei nomi esatti; +se non si trova il nome ricercato, si prosegue nella tabella di hash +dei nomi con caratteri jolly che iniziano per asterisco; +in caso di ulteriore riscontro negativo, si passa alla tabella di hash +dei nomi con caratteri jolly che finiscono per asterisco. + + + +La ricerca in una tabella di hash per nomi con caratteri jolly e' piu' lenta +della ricerca nella tabella relativa ai nomi esatti, dato che i nomi sono ricercati +per parti del dominio. +Si noti che il formato speciale “.example.org” e' salvato in una +tabella di hash di nomi con caratteri jolly, e non in quella dei nomi esatti. + + + +Le espressioni regolari sono testate in sequenza, per cui sono il metodo piu' +lento e sono non scalabili. + + + +Per queste ragioni, se possibile e' sempre meglio usare nomi esatti. +Ad esempio, se i nomi di server richiesti piu' di frequente sono +example.org e www.example.org, +e' piu' efficiente definirli in maniera esplicita: + + +server { + listen 80; + server_name example.org www.example.org *.example.org; + ... +} + + +che usare il formato piu' semplice: + + +server { + listen 80; + server_name .example.org; + ... +} + + + + +Se il numero di nomi di server definiti e' molto grande, +oppure se sono stati definiti nomi di server decisamente lunghi, +per la messa a punto e' possibile che sia necessario utilizzare +le direttive del livello http + +e . +Il valore di default della direttiva + +puo' essere pari a 32 o 64, oppure ad un altro valore, in base alla +dimensione della linea di cache della CPU. +Se il valore di default e' 32 ed il nome del server e' definito come +“too.long.server.name.example.org”, allora nginx non potra' +partire e sara' mostrato il seguente messaggio d'errore: + + +could not build the server_names_hash, +you should increase server_names_hash_bucket_size: 32 + + +In tal caso, il valore della direttiva dovrebbe essere aumentata sino alla +successiva potenza di due: + + +http { + server_names_hash_bucket_size 64; + ... + + +Se sono stati definiti molti nomi di server, potrebbe comparire un altro +messaggio di errore: + + +could not build the server_names_hash, +you should increase either server_names_hash_max_size: 512 +or server_names_hash_bucket_size: 32 + + +In tal caso, si provi prima a impostare + +ad un numero prossimo al numero dei nomi di server. +Solo nel caso in cui cio' non risultasse sufficiente, oppure se il tempo di avvio +di nginx fosse inaccetabilmente alto, si provi ad incrementare +. + + + +Se su una data porta in ascolto c'e' un unico server, allora nginx saltera' del tutto +la verifica dei nomi dei server (e non costituira' le tabelle di hash per la porta +in questione). +C'e' una eccezione: se un nome di server e' una espressione regolare con +sezioni catturate, allora nginx dovra' svolgere l'espressione regolare per recuperare +le sezioni catturate. + + +

+ + +

+ + + + + +Il nome di server speciale “$hostname” e' supportato +dalla versione 0.9.4 in poi. + + + +Il nome vuoto “” e' il valore di default per il nome dei server +dalla versione 0.8.48 in poi. + + + +Il riferimento tramite nome a sezioni catturate in un nome di server definito +tramite espressione regolare e' supportato dalla versione 0.8.25 in poi. + + + +Le sezioni catturate in un nome di server definito tramite espressione regolare +sono supportate dalla versione 0.7.40 in poi. + + + +Il nome di server vuoto “” e' supportato +dalla versione 0.7.12 in poi. + + + +La definizione di nomi di server e di espressioni regolari tramite caratteri jolly +e' supportata dalla versione 0.6.25 in poi. + + + +La definizione di nomi di server tramite espressioni regolari e' supportata +dalla versione 0.6.7 in poi. + + + +Il formato con caratteri jolly example.* e' supportato +dalla versione 0.6.0 in poi. + + + +Il formato speciale .example.org e' supportato +dalla versione 0.3.18 in poi. + + + +Il formato con caratteri jolly *.example.org e' supportato +dalla versione 0.1.13 in poi. + + + + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/index.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/index.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,74 @@ + + + + +

+ + +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/install.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/install.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,57 @@ + + + + +

+ +

+ + +nginx puo' essere installato in varie maniere, a seconda del sistema operativo. + + +

+ + +

+ + +Con Linux, e' possibile usare i pacchetti nginx binari, scaricabili da nginx.org. + + +

+ + +

+ + +Con FreeBSD, e' possibile installare nginx o tramite +pacchetti +binari oppure tramite ports. +Ports consente maggiore flessibilita', e permette di scegliere fra un gran numero di opzioni: +ports provvedera' a compilare nginx con le opzioni specificate, e ad installarlo. + + +

+ + +

+ + +Se e' richiesta qualche funzionalita' particolare e non disponibile con i pacchetti binari o con ports, +e' possibile compilare nginx a partire dai sorgenti. Per quanto maggiormente flessibile, +questo approccio per un principiante puo' risultare piu' complesso. +Per maggiori informazioni, fare riferimento a . + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/syntax.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/syntax.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,54 @@ + + + + +

+ +

+ + +Le dimensioni possono essere indicate in byte, kilobyte +(suffissi k e K), e megabyte +(suffissi m e M), ad esempio +“1024”, “8k”, “1m”. + + + +Gli intervalli di tempo possono essere specificati in millisecondi, +secondi, minuti, ore, giorni, e cosi' via, utilizzando i suffissi seguenti: + + + + + + + + + +

ms	millisecondi
s	secondi
m	minuti
h	ore
d	giorni
w	settimane
M	mesi, 30 giorni
y	anni, 365 giorni

+ + + +E' possibile combinare in un singolo valore piu' unita', specificandole +dalla piu' significativa alla meno significativa ed eventualmente +separandole con spazi. Ad esempio, “1h 30m” indica +lo stesso tempo di “90m” o “5400s”. +Un valore senza suffisso indica secondi, comunque e' sempre raccomandato +specificare un suffisso. + + + +Alcuni intervalli temporali possono essere specificati solo +con una risoluzione di secondi. + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/docs/windows.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/docs/windows.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,158 @@ + + + + +

+ +

+ + +La versione di nginx per Windows usa le API native Win32, e non il layer di +emulazione Cygwin. +Attualmente e' usato solo il metodo di connessione select, +per cui non e' possibile attendersi prestazioni e scalabilita' eccellenti; +per tale ragione, e anche per altre, quella per Windows e' +considerata una versione beta. +Al momento risultano implementate piu' o meno le stesse funzionalita' della +versione di nginx per UNIX, con l'eccezione del filtro XSLT, del filtro immagini, +del modulo GeoIP, e del linguaggio Perl embedded. + + + +Per installare nginx/Windows, e' bene scaricare +l'ultima distribuzione disponibile della versione mainline (), +che contiene le correzioni piu' recenti. +Bisogna scompattare la distribuzione, spostarsi nella directory +nginx- e lanciare nginx. +Segue un esempio in cui la directory e' sul drive C: : + + +cd c:\ +unzip nginx-.zip +cd nginx- +start nginx + + +Avviare l'utility a linea di comando tasklist +per vedere i processi nginx: + + +C:\nginx->tasklist /fi "imagename eq nginx.exe" + +Image Name PID Session Name Session# Mem Usage +=============== ======== ============== ========== ============ +nginx.exe 652 Console 0 2 780 K +nginx.exe 1332 Console 0 3 112 K + + +Uno dei due e' il processo master, l'altro il processo worker. +Se nginx non si avvia, verificarne la ragione nel file di log +degli errori logs\error.log ; +se tale file non e' stato creato, la ragione dovrebbe essere riportata +nel Windows Event Log. +Se viene mostrata una pagina di errore invece della pagina attesa, +verificarne la ragione nel solito file logs\error.log . + + + +nginx/Windows utilizza la directory in cui e' stato avviato come prefisso +per i path relativi della configurazione. +Nell'esempio precedente, il prefisso e' +C:\nginx-\ . +I path nei file di configurazione devono essere specificati usando gli +slash del formato UNIX: + + +access_log logs/site.log; +root C:/web/html; + + + + +nginx/Windows e' eseguito come una normale applicazione di console e +non come un servizio, e puo' essere gestito con i comandi seguenti: + + + + + + + + + + + + + + + + + + + + + + + +

nginx -s stop	arresto rapido
nginx -s quit	arresto controllato
nginx -s reload	+ricaricamento della configurazione, +con avvio di un nuovo processo worker con la nuova configurazione, +ed arresto controllato del vecchio processo worker. +
nginx -s reopen	riapertura dei file di log

+ + +

+ +

+ + + + +Nonostante sia possibile avviare diversi worker, in effetti +solo uno di essi esegue tutto il lavoro. + + + +Un worker puo' gestire non piu' di 1024 connessioni simultanee. + + + +La cache, ed altri moduli che richiedono il supporto alla memoria condivisa, +non funzionano su Windows Vista e versioni successive, in quanto su tali +versioni e' in uso la address space layout randomization. + + + + +

+ +

+ + + + +L'esecuzione come servizio. + + + +L'uso di I/O completion port come metodo di processo delle connessioni. + + + +L'uso di piu' thread worker all'interno di un singolo processo worker. + + + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/it/index.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/xml/it/index.xml Wed Nov 20 14:36:40 2013 +0400 @@ -0,0 +1,357 @@ + + + + +

+ + +

+ + +nginx [engine x] e' un server HTTP e reverse proxy, +nonche' un server mail proxy, scritto da +Igor Sysoev. +Per molto tempo e' stato usato principalmente per alcuni +siti russi ad alto carico, ad esempio +Yandex, +Mail.Ru, +VKontakte e +Rambler; +in base ai dati di Netcraft, nell'ottobre 2013 nginx +e' il server HTTP o reverse proxy del +15.08% +dei siti a maggiore carico. +Alcuni casi di successo sono: +Netflix, +Wordpress.com, +FastMail.FM. + + + +La documentazione ed i sorgenti sono distribuiti in base alla +licenza BSD con 2 clausole. + + +

+ + +

+ + + + + +Servizio di file statici e +index, +autoindexing; +cache dei descrittori dei file aperti; + + + +Reverse proxy accelerato +con cache; +semplice bilanciamento +di carico e load balancing; + + + +Supporto accelerato con cache di server +FastCGI, +uwsgi, SCGI, e +memcached; +semplice bilanciamento +di carico e load balancing; + + + +Architettura modulare. +Filtri per +gzip, +intervalli di byte, risposte a blocchi, +XSLT, +SSI, +e filtro per la +trasformazione d'immagini. +Inclusioni multiple di SSI in una stessa pagina possono essere +processate in parallelo se sono gestite da server proxy o FastCGI; + + + +Supporto a SSL e TLS SNI +. + + + + + +

+ + +

+ + + + + +server virtuali +name-based e IP-based; + + + +Supporto a connessioni +keep-alive +e pipelined; + + + +Configurazione flessibile; + + + +Caricamento di una nuova +configurazione e +aggiornamento dell'eseguibile senza interruzione di servizio ai client; + + + +Access log in vari +formati, log con buffer +, e veloce rotazione dei log; + + + +Redirezione +dei codici d'errore 3xx-5xx; + + + +Modulo di rewrite: +trasformazione delle URI +con uso di espressioni regolari; + + + +Esecuzione di funzioni differenti + a seconda dell' +indirizzo del client; + + + +Controllo d'accesso in base a +indirizzo IP del client, a + +password (HTTP Basic authentication), e al +risultato di una sottorichiesta; + + + +Validazione del +referer HTTP; + + + +Metodi PUT, DELETE, MKCOL, COPY, +e MOVE; + + + +Streaming +FLV e +MP4; + + + + +Limitazione della velocita' del flusso di risposta; + + + +Limitazione del numero di +connessioni o +richieste +simultanee da un dato indirizzo; + + + +Perl embedded. + + + + + +

+ + +

+ + + + + +Redirezione dell'utente verso server +IMAP +o +POP3 +tramite un server esterno di +autenticazione +HTTP; + + + +Autenticazione dell'utente tramite un server esterno di +autenticazione +e redirezione della connessione verso un server +SMTP; + + + +Metodi di autenticazione: + + + + +POP3: +USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5; + + + +IMAP: +LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5; + + + +SMTP: +AUTH LOGIN/PLAIN/CRAM-MD5; + + + + + + +supporto a +SSL; + + + +supporto a +STARTTLS +e STLS. + + + + + +

+ + +

+ + + + + +Un processo master e numerosi processi worker; +i processi worker girano con un utente non privilegiato; + + + +Supporto a +kqueue (FreeBSD 4.1+), +epoll (Linux 2.6+), segnali rt (Linux 2.2.19+), +/dev/poll (Solaris 7 11/99+), event ports (Solaris 10), +select, e poll; + + + +Supporto alle differenti funzionalita' di kqueue, fra cui EV_CLEAR, EV_DISABLE +(per disabilitare temporaneamente eventi), NOTE_LOWAT, EV_EOF, +numero di dati disponibili, codici d'errore; + + + +supporto a sendfile (FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+), +e sendfilev (Solaris 8 7/01+); + + + +File AIO +(FreeBSD 4.3+, Linux 2.6.22+); + + + +DIRECTIO +(FreeBSD 4.4+, Linux 2.4+, Solaris 2.6+, Mac OS X); + + + +supporto a +Accept-filters (FreeBSD 4.1+, NetBSD 5.0+) e TCP_DEFER_ACCEPT (Linux 2.4+); + + + +10000 connessioni HTTP keep-alive inattive richiedono circa 2.5M di memoria; + + + +Le operazioni di copia di dati risultano minime. + + + + + +

+ + +

+ + + + + +FreeBSD 3—10 / i386; FreeBSD 5—10 / amd64; + + + +Linux 2.2—3 / i386; Linux 2.6—3 / amd64; + + + +Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v; + + + +AIX 7.1 / powerpc; + + + +HP-UX 11.31 / ia64; + + + +Mac OS X / ppc, i386; + + + +Windows XP, Windows Server 2003. + + + + + +

+ +

diff -r 9f9a427a73eb -r 19129672444e xml/menu.xml --- a/xml/menu.xml Mon Nov 18 12:48:10 2013 +0400 +++ b/xml/menu.xml Wed Nov 20 14:36:40 2013 +0400 @@ -17,6 +17,7 @@ עברית 日本語 türkçe + italiano 新闻 @@ -49,6 +50,7 @@ עברית 日本語 türkçe + italiano news @@ -94,6 +96,7 @@ עברית 日本語 türkçe + italiano חדשות @@ -124,6 +127,7 @@ עברית 日本語 türkçe + italiano ニュース @@ -155,6 +159,7 @@ עברית 日本語 türkçe + italiano новости @@ -188,6 +193,7 @@ עברית 日本語 türkçe + italiano haberler @@ -209,4 +215,50 @@ + + + + english + русский + + + 简体中文 + עברית + 日本語 + türkçe + italiano + + + news + + + + + + + informazioni generali + download + + avvisi di sicurezza + documentazione + chiavi pgp + + faq + collegamenti + libri + supporto + donazioni + + + trac + wiki + twitter + nginx.com + + +