mod_cgi for nginx - anyone?

[mike]

On Feb 7, 2009, at 2:57 AM, Igor Sysoev <is at rambler-co.ru> wrote:

> On Sat, Feb 07, 2009 at 02:33:09AM -0800, mike wrote:
>
>> On Sat, Feb 7, 2009 at 2:16 AM, Igor Sysoev <is at rambler-co.ru> wrote:
>>
>>> nginx is not general purpose server, it's rather highload server.
>>> CGI is not compatible with highload: if you run Apache/CGI, then CGI
>>> will became bottleneck much earlier than Apache.
>>>
>>> There are two ways to implement CGI inside nginx:
>>>
>>> 1) simple one: just fork()ing worker process that has received a  
>>> request
>>> for CGI and exec() a CGI program. It's simple enough, but has a lot
>>> of overhead. Besides CGI programs will run with worker privilege  
>>> only.
>>
>> and it requires the CGI program to be modified, yeah?
>
> No.

Got any urls for examples then?


>
>
>>> 2) complex way: to run a special CGI manager (probably with root  
>>> privilege
>>> as master process) and to pass it requests/sockets using Unix  
>>> domain sockets.
>>> Then the manager can fork/exec CGI programs with required privileges
>>> and with minimal overhead to nginx workers.
>>>
>>> The second way will require some time to program, but the outcome  
>>> will
>>> be much similar like just proxying to mini_httpd
>>> ( http://acme.com/software/mini_httpd/ ).
>>
>> this is like starting out with something like php-fpm, and morphing
>> into a small httpd?
>
> No, the special CGI manager is a nginx process that fork()ed by  
> master nginx
> process (like worker processes). The communication protocol between
> workers and the manager is not HTTP: a worker starts to handle a  
> request,
> then it sees that the request should be handled by CGI, something like
>
>      location /mailman/ {
>           cgi_script  ...;
>           cgi_user    ...;
>           ...
>      }
>
> and pass the request and client socket to the manager.
>
>>> BTW, it seems that using Apache with several worker processes  
>>> (2-5) for
>>> bugzilla, mailman, etc. will not consume much CPU/memory: look top.
>>
>> I'm just looking at it from simplifying the system administration.
>>
>> I know it is not the most performant, those tools are not my  
>> preferred
>> ones, I just have to support hosting them right now...
>
> I understand this, but currently nginx has more priority tasks.
>

Sure. So it isn't impossible if someone else was hired to do it. I was  
wondering if there was a technical reason for it.

On a different note, I've paid someone to implement mod_auth_gss (more  
or less) into nginx. So it might support kerberos tickets and single  
sign on soon (at least SPNEGO)


>
> -- 
> Igor Sysoev
> http://sysoev.ru/en/
>