Bug#627213: New virtual package(s) for different kinds of httpd (fastcgi etc)
On 31/05/2011 19:28, Russ Allbery wrote:
> Jérémy Lal <jerry@edagames.com> writes:
>> On 31/05/2011 18:43, Russ Allbery wrote:
>
>>> So this implies to me that spawn-fcgi should provide the virtual
>>> package that scripts depend on, because this is the meaningful
>>> interface for CGI scripts that want to run in FastCGI mode. Whether
>>> that then hooks to a web server on the same system or a web server on
>>> some other system is up to the local administrator.
>
>> note that a cgi script cannot be directly used as a fastcgi backend.
>> fcgi-cgi [0] is the tool to do that. But it's much better to have
>> implemented fcgi interface in the script (which is usually dead simple).
>
> I was thinking of Perl scripts that use CGI::Fast, which automatically
> does that sort of mode switching, but yes, this is in general a good
> point.
>
>> So there are two virtual packages now : one for the fcgi server and one
>> for the backend. I'm not convinced trying to define an interface for
>> registering the backend is such a good idea, because the only experience
>> i have is with spawn-fcgi. AFAIK it's well designed and serves the
>> purpose perfectly. Upstream is not so active but there have been no bug
>> reports for a while now.
>
> The interface between the script and whatever spawns it is one of those
> things that we may need to leave undefined right now since Debian doesn't
> have a great handle on some of the policy issues around configuring CGI
> yet (such as what scripts should be configured to run by default).
>
>> For the fcgi server configuration, it is much more interesting to do
>> this, and an approach like dbconfig-common (probably much simpler
>> actually) might be good to have. It should deal with simple cgi
>> configuration too, at least on the supported httpd-fcgi servers.
>
> Yeah, that makes a lot of sense. We run into the standard web server
> configuration problem of trying not to make assumptions about the URL
> namespace that the local administrator wants to expose, though.
About the URL config : i believe asking the user which host:port/alias
covers most cases ?
I'll bash some tool for that (i actually really need one), anyone interested
is welcome, but right now i'm out of spare time.
> I personally would be happy to move forward with defining virtual packages
> in Policy for the backend that spawns the scripts and for the capability
> in the web server to talk to a FastCGI socket without hammering out all of
> the configuration details, since we're at that point moving into stuff
> that's underspecified in Debian as a whole anyway. I do think it would
> make sense to standardize in Policy, as part of the virtual package
> definitions, what path or directory should be used for the FastCGI sockets
> so that we at least have some sort of basic rendezvous set up to allow
> more automatic configuration later. But I haven't thought about it a lot.
For information, i'm currently using
/var/run/redmine/sockets/default/fcgi.socket-0
that is
/var/run/<package>/sockets/<instance_name>/<socket0, 1...>
Right now i'm missing a clear view of how the different httpd-fcgi expect
the several sockets to be named. apache2-mod-fcgid is difficult about that.
Let me bring in this discussion two related things to consider, to make sure
decisions now won't make them hard to implement later (please ignore this if
you consider it out of this bug report scope) :
1) running all those fcgi/cgi apps under www-data is often seen as a
security weakness, since one fcgi going wild could affect others.
I'm thinking naively of some www-data-<package> user or group, but i have
no experience here.
2) keep the possibility to easily run multiple, differently configured,
instances of the same fcgi app. (Hence the <instance_name> in the path above).
This is the webapp problem, but foreseeing isn't bad :)
Jérémy.
Reply to: