Bug#627213: New virtual package(s) for different kinds of httpd (fastcgi etc)
Jérémy Lal <jerry@edagames.com> writes:
> 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).
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.
> * 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.
The implication of this to me is that httpd-fcgi should be provided by web
servers that listen to FastCGI sockets but do *not* necessarily actually
spawn FastCGI servers, that there should be another metapackage (possibly
just fcgi?) provided by packages like spawn-fcgi that provide facilities
to actually run the scripts, and that the packages that provide both (such
as libapache2-mod-fastcgi) should provide both. Then spawn-fcgi would
Recommend httpd-fcgi (but not Depend, since it may be on a different
host), and the actual FastCGI applications would Depend on fcgi (or
whatever we call the virtual package).
Does that make sense?
That still doesn't take care of some of the details of the interface, such
as how scripts register themselves to be started by whatever package
provides the fcgi virtual package, but it gets us closer.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: