On 31/05/2011 18:43, Russ Allbery wrote: > Jérémy Lal <je...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
