Newsgroup: it.comp.os.linux.software
Titolo: nginx come alternativa a mod_rewrite

Sto spulciando tutta la documentazione che c'è sulla wiki di Nginx ma non 
trovo come tradurre questa regola particolare di mod_rewrite (Apache)
RewriteRule /foo/(.*) http:///$1.domain.tld/baa [P,L]
idee? il casino che non so risolvere è cambiare l'host che c'è dietro 
dinamicamente in base all'URL d'origine.
-- 
Vide

 dinamicamente in base all'URL d'origine.
La mia unica idea equivale ad incasinarti le idee :)
Prova a vedere in lighttpd, Varnish o pound, in quanto sono meglio 
documentati (o almeno per i primi due e` cosi`)
Enrico

 documentati (o almeno per i primi due e` cosi`)
Effettivamente non è troppo difficile che siano meglio documentati di nginx 
(e almeno adesso c'è la wiki, fino a un anno fa non c'era manco quella e 
dovevi andarti a leggere il codice fra un po'). Faccio ancora qualche prova 
oggi e se non riesco cambio con lighttpd che lo conosco meglio.
-- 
Vide

 dinamicamente in base all'URL d'origine.
Risolto! 
Apache:
RewriteRule /foo/(.*) http:///$1.domain.tld/baa [P,L]
Nginx:
location /foo {
         resolver 192.168.1.1;
         if ($uri ~* /foo/(.*)) {
          set $internal_host $1;
          proxy_pass http://$internal_host.domain.tld/baa;
         }
Poi tutti criticano Apache... una linea di conf si trasforma in 7 linee con 
nginx e con la stupida, inutile, cretina, idiota però *obbligatoria* 
direttiva "resolver" che non è altro che il SERVER DNS. Perchè cazzo non usi 
le funzionalità di sistema, russo delle balle???!?
PS probabilmente il "set" non è necessario, si può mettere il $1 nel 
proxy_pass.
-- 
Vide

 
Puoi impostare la direttiva resolver nel blocco http del file di 
configurazione, e non nella location.
Ciao  Manlio

 
Ti faccio notare che il flag P, nel mod_rewrite di Apache, non è proprio 
una felice scelta di design, dato che sta implicitamente usando mod_proxy, 
che non è un modulo banale.
Ciao  Manlio

 configurazione, e non nella location.
È la stessa cosa... il giorno che cambio l'IP del server DNS per un 
qualunque motivo mi devo ripassare pure le configurazioni degli nginx. È una 
stupidata quando esiste già /etc/resolv.conf [1] che fa la cosa
[1] sempre che non si tocchi nsswitch :)
-- 
Vide

 che non è un modulo banale.
Sì però è una figata perchè ti da la flessibilità delle regole di rewrite e 
allo stesso tempo ti fa da proxy.
-- 
Vide

 }
Ah, grazie per la forma più compatta. Non sapevo (e dalla doc sinceramente 
non si capisce o io non l'ho trovato) che qualunque espressione regolare 
ritorna un $n coi vari match. Avevo visto solo l'esempio con l'if per cui 
sono andato sul sicuro.
-- 
Vide

 sinceramente non si capisce o io non l'ho trovato)
http://wiki.nginx.org/NginxHttpCoreModule#location
...
Regular expression may contain captures (0.7.40), which can be used in 
other directives
...
Comunque si, il wiki non documenta tutte le direttive e in alcuni rari 
casi le informazioni non sono corrette.
Inoltre è più una guida di riferimento, quindi ci sono pochi esempi di 
utilizzo delle varie direttive.
Ciao  Manlio



Per chi ignora le basi della programmazione su unix è una stupidata.
Per chi le conosce a fondo, invece, è la cosa giusta da fare.

 
Se ti interessa, ecco la risposta dell'autore alla mia proposta di 
aggiungere supporto per /etc/resolv.conf:
It can be done, however, currently nginx can use only single nameserver
from the file.
Ciao  Manlio

 Per chi le conosce a fondo, invece, è la cosa giusta da fare.
Sentiamo quindi la spiegazione e come mai è il primo programma che funziona 
così che ho visto in tutta la mia vita *nixara. Sono realmente interessato.
-- 
Vide

 interessato.
perchè il resolver nativo delle libc
- non è non blocking
- non è asincrono
Quando lavori con codice pesantemente parallelo come ngix, usare codice 
dedicato alla risoluzione dei nomi che sia non blocking e asincrono è un 
_gran_ vantaggio.

 
Ma /etc/resolv.conf contiene semplicemente gli indirizzi dei nameserver 
di default.
Nginx continuerà ad usare il suo client DNS asincrono.
Ciao  Manlio

 gran vantaggio.
Soluzione corretta a lunghissimo raggio: migliorare le libc
Soluzione corretta a corto raggio: leggersi gli stessi file che leggono le 
libc (che è quello che potrebbe implementare)
Soluzione IMO non corretta: avere una configurazione nel programma che 
appartiene al sistema in *tutti* i sistemi di questo mondo. Si potrebbe 
considerare corretta per le primissime versioni del programma, ma nginx 
ormai è più che maturo.
-- 
Vide

 ormai è più che maturo.
E' una questione di punti di vista.
Io personalmente per una cosa del genere me ne sbatterei.
Ad esempio, su alcune macchine, i controlli sulle RBL per la posta io non 
li faccio fare al server SMTP ma ad un programma ad-hoc che utilizza 
direttamente gli IP dei DNS che ospitano le RBL.
Se si schianta il DNS, tutto continua a funzionare correttamente, piu 
velocemente ed in maniera migliore.

 velocemente ed in maniera migliore.
Ma in una soluzione ad-hoc tua puoi fare quel che ti pare, secondo le tue 
esigenze, ci mancherebbe altro! Però in un programma rilasciato al pubblico 
sarebbe interessante che cose così non ci fossero. Comunque per ora faccio 
servire il resolver, non è un gran problema, però il giorno che dovessi 
migrare da Apache per qualcosa di più snello sarebbe un motivo plausibile 
per non scegliere nginx.
-- 
Vide

 motivo plausibile per non scegliere nginx.
Il discorso è semplice:
se nginx va meglio di apache un motivo ci sarà. no ?
Tra questi c'è sicuramente anche un resolver interno.
Se proprio ti fa schifo, usa apache, lighttpd o quant'altro ti possa 
piacere.
Parallelamente, e se non puoi usare altro che nginx, visto che critichi 
così del software opensource, ho pronte due domande:
1) perchè non fai una patch e la mandi upstream ?
2) Se non sei in grado di scrivere la patch, perchè non contribuisci 
pagando qualcuno per scriverla e mandandola upstream ?
3) se non hai nessuno che la può scrivere, perchè non doni qualcosa al 
progetto, così magari ti aggiungono questa cosa ?
Nel mio mondo l'opensource funziona così.

 Nel mio mondo l'opensource funziona così.
Anche nel mio, ma fossi un utente vero e proprio di nginx sicuramente farei 
qualcosa, ma dato che lo sto provando per vedere se mi va bene per i miei 
scopi, non ha molto senso (per me e per la comunità nginx, perchè può darsi 
che abbiamo differenze di vedute, dovresti sapere perfettamente che perchè 
sia opensource non significa che accettino senza problemi le tue proposte o 
patch).
-- 
Vide

 non si capisce o io non l'ho trovato) 
La doc? Esiste una doc di Nginx, che non sia in russo, tolteco o urdu?
Alla fine, tranne che non debba gestire un'architettura corposa, Nginx
lo prendi e lo butti via per mancanza atavica di documentazione. E a
livello aziendale, se devi far gestire tante rule a un manipolo di
persone non troppo competenti, ti butterai su Sun Web Server.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo



infatti era quello che stavo per scrivere pure io.
Quei dati vengono letti solo in fase di startup, o di reload.


 persone non troppo competenti, ti butterai su Sun Web Server.
Per molte cose, il wiki da informazioni sufficienti.
Ciao  Manlio

 persone non troppo competenti, ti butterai su Sun Web Server.
Eh si, guarda.
Ci pensavo proprio ieri.
Tutte le aziende con cui collaboro sono migrate a Sun Web Server, perchè 
non lo devo fare anche io ? Sono miliardi le installazioni di Sun Web 
Server, qualunque cosa sia.
Ora che me l'hai consigliato, decisamente passerò il weekend insonne a 
sostituire tutti i web server che gestisco.

 non lo devo fare anche io ?
Intendimi ctrix all'acido citrico: sun ws non è un prodotto migliore
di nginx, bensì un prodotto che, una volta configurato, puoi far gestire
agli helpdesk.
La azienda X, che è subissata di richieste fa gestire queste richieste
a gente che non sa nemmeno cosa sia un reverse proxy.
