Project

General

Profile

Feature #1816

fastcgi prepend_docroot variable

Added by matthijs almost 9 years ago. Updated almost 9 years ago.

Status:
Wontfix
Priority:
Normal
Assignee:
-
Category:
mod_fastcgi
Target version:
-
Start date:
2008-11-07
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

I'm currently trying to get my lighttpd running chrooted using evhost and fastcgi processes that are running outside of the chroot. This doesn't seem to be possible using the current mod_fastcgi.

Assume I'm running lighttpd chrooted into "/www". Under there, I have "htdocs/www", "htdocs/mail", etc, which contain the htdocs for www.domain.com, mail.domain.com. etc. The evhost pattern here is "htdocs/%3", so the document root is dependent on the subdomain requested.

To enable fastcgi (in particular php) for all of these hosts, I need to pass a modified document root through fastcgi (ie, /www needs to be prepended). mod_fastcgi has a "docroot" option, but that completely overrides the document root. In the example above, I would need to set the "docroot" option to /www/htdocs/www or /www/htdocs/mail, depending on the subdomain requested. However, this means I need multiple fastcgi declarations, one for each subdomain. This completely removes the point of using evhost and also requires me to manually configure every subdomain (instead of being able to add subdomains without reconfiguring lighttpd).

To solve these problems, I propose adding a "prepend_docroot" variable. This setting is similar to the current "docroot" setting, but preserves the original docroot, making it the fix-all setting for accessing non-chrooted fastcgi instances while chrooted.

Would it makes sense to implement this? From looking at the sources, it doesn't look like too much work either?

History

#1 Updated by hoffie almost 9 years ago

Personally, I don't think such a change would go into 1.4 and 1.5 also supports this in mod_proxy_core...

#2 Updated by matthijs almost 9 years ago

Personally, I don't think such a change would go into 1.4 and 1.5 also supports this in mod_proxy_core...

Considering that mod_proxy_core can indeed do this kind of stuff in a far more flexible way, I'll just settle for running without chroot and re-evaluate when 1.5 is released.

I guess this report can be closed, then?

#3 Updated by stbuehler almost 9 years ago

  • Status changed from New to Wontfix

Also available in: Atom