[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#627213: New virtual package(s) for different kinds of httpd (fastcgi etc)



On 31/05/2011 18:43, Russ Allbery wrote:
> 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.

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).

 
>> * 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 makes perfect sense, and is accurate.
I hadn't such a clear view on the situation.


> 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.

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.
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.

Jérémy.


[0]
http://redmine.lighttpd.net/projects/utilities






Reply to: