Nginx 0.6.31 ebuild for use with Gentoo and derivate distributions is
now available at the “connectical-contrib” overlay [1], with the
following improvements over the official Gentoo packaging:
- USE=python enables building Manlio’s WSGI module [2].
- USE=scgi enables building Manlio’s SCGI module (use with care!)
- USE=addition enables building the bundled “addition” module
- USE=perftools enables building the bundled Google perftools module
- USE=gzip-static enables building the bundled precompression module
The following patched are applied when building:
- Escaping of non-printable characters in log files [4].
- Use “X-Forwarded-Host” instead of “Host” when proxying requests [5]
- Fix stack overflow because of recursive calls [6]
Comments are welcome. Enjoy!
References
i don’t suppose you could add fancy-indexes could you, it would make my
life
easier
(and i really don’t suppose you could get ipv6 added could you Igor 
)
Kingsley
From: “Adrian P.” [email protected]
Sent: Wednesday, May 14, 2008 9:40 AM
To: [email protected]
Subject: [ANN] Enhanced Gentoo ebuilds for nginx 0.6.31
Adrian P. ha scritto:
The following patched are applied when building:
- Escaping of non-printable characters in log files [4].
- Use “X-Forwarded-Host” instead of “Host” when proxying requests [5]
- Fix stack overflow because of recursive calls [6]
Comments are welcome. Enjoy!
A few notes about my modules:
- The WSGI module is not a “first class” module for Nginx.
Usually you don’t want the WSGI module inside you primary
web server.
- The SCGI module is not yet usable, since all the SCGI applications
return the output response in the “parsed headers” format, and this
is not yet recognized by the module (instead, it expect the output
to
be a full HTTP 1.x response).
By the way, if someone is interested I’m starting to write a CGI module
(and, of course, in a very non orthodox way)!
Thanks for you work
Manlio P.
On Wed, May 14, 2008 at 09:51:11AM +0200, Manlio P. wrote:
By the way, if someone is interested I’m starting to write a CGI module
(and, of course, in a very non orthodox way)!
How do you want to implement it ? Forking entire worker it seems
overkill
for me: you need to close all connections or use FD_CLOEXEC for every
socket/etc.
I thought about special CGI manager, but it almost the same as proxying
to mini_httpd (mini_httpd).
I’m interested! The more back-end connectivity for nginx, the better!
Can you elaborate on why it is non orthodox?
Manlio P. wrote:
- The WSGI module is not a “first class” module for Nginx.
Thanks for you work
Manlio P.
–
Phillip B Oldham
The Activity People
[email protected] mailto:[email protected]
Policies
This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to
anyone.
This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.
Phillip B Oldham ha scritto:
By the way, if someone is interested I’m starting to write a CGI
module (and, of course, in a very non orthodox way)!
I’m interested! The more back-end connectivity for nginx, the better!
Can you elaborate on why it is non orthodox?
The goal is to write the less code as possible, so I’m trying to reuse
the existing upstream infrastructure.
This means that it is not possible to use pipes, but instead I will use
unix sockets.
I don’t know if this will be possible, but it is worth a try.
Manlio P.
On Wed, May 14, 2008 at 12:05:29PM +0400, Igor S. wrote:
On Wed, May 14, 2008 at 09:51:11AM +0200, Manlio P. wrote:
By the way, if someone is interested I’m starting to write a CGI module
(and, of course, in a very non orthodox way)!
How do you want to implement it ? Forking entire worker it seems overkill
for me: you need to close all connections or use FD_CLOEXEC for every
socket/etc.
… and possibly setuid/gid/etc. so the one to fork should probably be
the master process, not a worker. Otherwise (running all CGI as the
nginx user) it would be pretty limited.
I thought about special CGI manager, but it almost the same as proxying
to mini_httpd (mini_httpd).
I’m not plugging fcgiwrap again 
Best regards,
Grzegorz N.
Grzegorz N. ha scritto:
the master process, not a worker.
This is not possible.
Otherwise (running all CGI as the
nginx user) it would be pretty limited.
The solution, here, is having Nginx to call seteuid/setegid instead of
setuid/setgid in ngx_worker_process_init.
In this way the child process can call seteuid(0) to become root again,
and then, finally, setuid(xxx) to become the effective user for the CGI.
The problem, of course, is that an external module can call seteuid(0)
to become root, and this is not acceptable.
[…]
Manlio P.
On Wed, May 14, 2008 at 10:39:52AM +0200, Manlio P. wrote:
… and possibly setuid/gid/etc. so the one to fork should probably be
the master process, not a worker.
This is not possible.
Well, you could set up a bunch of pipes/sockets but it wouldn’t be
pretty 
The problem, of course, is that an external module can call seteuid(0)
to become root, and this is not acceptable.
An external module can already do whatever it wishes in the master
process so this shouldn’t be a big issue. However, this requires the
nginx master to run as root (which isn’t the case now AFAIK, if you use
ports > 1024). Of course, forking the master process changes nothing
here.
Best regards,
Grzegorz N.
On Wed, 14 May 2008 10:13:08 +0930
“Kingsley F.” [email protected] wrote:
i don’t suppose you could add fancy-indexes could you, it would make
my life easier
I forgot to mention it, but USE=fancyindex is supported as well 
Igor S. ha scritto:
On Wed, May 14, 2008 at 09:51:11AM +0200, Manlio P. wrote:
By the way, if someone is interested I’m starting to write a CGI module
(and, of course, in a very non orthodox way)!
How do you want to implement it ? Forking entire worker it seems overkill
for me: you need to close all connections or use FD_CLOEXEC for every
socket/etc.
Yes, this is one of the main problems.
But it is not stricly necessary to close all the opened connections.
The open syscall should return a file descriptor that is the lowest file
descriptor not currently open for that process, so maybe it is safe to
just close the first 256 descriptors.
Of course there should be a timer that make sure to close the child
process when it timeouts, to avoid a CGI program to stay alive for too
much time.
I thought about special CGI manager, but it almost the same as proxying
to mini_httpd (mini_httpd).
Right, it will always be the same as proxying to an external http
server, but the advantage is that all can be done without having to use
external servers.
Moreover, since I’m mainly a Python programmer, I will try to implement
special support for executing Python CGIs without having to to call
exec.
Manlio P.