Bug#627213: New virtual package(s) for different kinds of httpd (fastcgi etc)
On 31/05/2011 18:13, Jonathan Nieder wrote:
> Hi again,
>
> Jonathan Nieder wrote:
>> Jérémy Lal wrote:
>
>>> Some clarifications :
>>> * setting up the fastcgi process itself is specific for each case,
>>> so it's the responsibility of the "client" package to declare what it depends on
>>> (php5-cgi, libfcgi-ruby, ...).
>>> * most, if not all, servers provide a way to spawn the fastcgi process within the
>>> server, binding them to sockets and managing permissions, but httpd-fcgi should not mean that.
> [...]
>> Could you clarify this further?
>>
>> If I understand correctly, it is possible for a FastCGI application to
>> run on a different machine than the corresponding web server. Does
>> this mean each webapp would be responsible for launching the FastCGI
>> application by some privately determined means and should use
>>
>> Recommends: httpd-fastcgi
>>
>> to ensure people can view it? Is there some standardized
>> configuration file a FastCGI app can use to launch only when needed,
>> if the admin wants that (socket activation through xinetd-workalikes,
>> I guess), or does the server have to be involved in that case? And is
>> there some standardized configuration file a FastCGI app can use to
>> show up in the server, or does that require custom configuration?
>
> It was drawn to my attention that this does not seem to have much to do
> with introduction of the virtual package httpd-fcgi. Actually I
> respectfully disagree: a virtual package represents a standardized
> interface that multiple packages can rely on (for example "mailx"
> means when the package is installed, the mailx command can be used in
> the ways explained by POSIX), and the goal of the above questions was
> to figure out what that interface for httpd-fcgi is.
>
> One possible answer to these questions is: "no, there is no
> standardized configuration mechanism --- httpd-fcgi just means that
> the server allows running FastCGI apps by some means documented at
> /usr/share/doc/<server package name>/README.fastcgi, and some webapps
> will have their own README.fastcgi instead of setting anything up
> automatically". That would be fine --- I do not mean to suggest we
> should standardize on anything more if that's all there is.
Ok then, if you pardon me being verbose :
My usage (and i believe it's how it should be done) of fastcgi is like this :
* i setup a fastcgi daemon of the webapp using spawn-fcgi and runit.
On that server i have php5-cgi, redmine (ruby), and a C fastcgi program.
spawn-fcgi let you control wether you want a listening unix or net socket,
(optionally multiwatch let you spawn several instances listening on the /same/ socket).
* another server with httpd-fcgi is configured to use those fastcgi daemons as backends.
See for example the two files attached, where a unix socket is used, so both are on
the same server.
* for higher availability, spawning several instances listening on several sockets
is the way to go. I believe apache2+fcgid, nginx, lighttpd, cherokee all support
load-balancing between several fastcgi instances. (Using multiwatch being the poor
man's setup.)
So it should be up to the webapp to provide a way to launch the fastcgi daemon.
I did not use a simple initscript, since some daemons i use are unstable and need
monitoring (my C fcgi backend, but php, ruby happen to crash too). Note that if you
have the web server handle the fcgi backend, it spares you the need to launch it
and monitor it, with the downside of having to keep webserver and daemon on the same machine.
If the webapp wants automatic configuration of the httpd-fcgi server, then some
glue package is needed. I've been thinking about that for a while, it could be
actually very simple if it's limited to common use cases like configuring
cgi or fastcgi with a virtualhost config and/or an alias config. I have a bunch of
such cases in /usr/share/doc/redmine/examples.
Also since there is a policy for cgi apps, there should be a similar one for fcgi.
Jérémy
Reply to: