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

[Jérémy Lal]

About running webapps as differents user/group, note that it's been
discusses some time ago :
http://lists.debian.org/debian-webapps/2010/05/msg1.html

Jérémy.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jérémy Lal]

A word about /var/run for sockets : since it's a tmpfs, folders are not
kept, so it's up to the fastcgi backend to create them.
Unfortunately, that doesn't work when spawning is done by the httpd-fcgi server 
:
lighttpd, given a "socket => /var/run/myapp/socket" option, does not create
/var/run/myapp.

Jérémy.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jérémy Lal]

On 31/05/2011 19:28, Russ Allbery wrote:
> Jérémy Lal  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//sockets//

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- 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  in the path 
above).
   This is the webapp problem, but foreseeing isn't bad :)

Jérémy.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Jérémy Lal  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.

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.

-- 
Russ Allbery (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jérémy Lal]

On 31/05/2011 18:43, Russ Allbery wrote:
> Jérémy Lal  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

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

[Russ Allbery]

Jérémy Lal  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 (r...@debian.org)   



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jérémy Lal]

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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Jonathan Nieder  writes:

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

Well, "fine" in some sense (we have a few things like that now), but
definitely less than ideal, and I'd rather not introduce a new case like
that.  One of the points of Debian Policy, and Debian packaging in
general, is to integrate things.  I really hate to see us throw up our
hands and say "the end-user has to integrate it themselves."

I'm wholeheartedly in favor of adding these new virtual packages, but I do
think we should take the opportunity to specify an interface that
providers of that virtual package implement, and that FastCGI scripts (and
the other cases listed) can depend on.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jonathan Nieder]

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

Sorry for the lack of clarity.

Cheers,
Jonathan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jonathan Nieder]

Hi Jérémy,

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.
>   It should only mean the web server can talk to an existing fastcgi process.
>   The way to spawn it is specific to the "client" package (spawn-fcgi being a 
> common tool
>   to achieve that task, but is only a possibility among others)

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?

I'm asking these things because gitweb can be used as a CGI or fastcgi
script but it was never packaged to set the latter up automatically.
Currently gitweb uses

Depends: apache2 | httpd | lynx-cur
Suggests: httpd-cgi | libcgi-fast-perl

documents setup as a CGI script at /usr/share/doc/git/README.Debian,
and puts a conffile for autoconfiguration at /etc/apache2/conf.d/gitweb.
It would be nice if these dependencies could be simplified and some
autoconfiguration magic added for people to use FastCGI just as easily
if they want it.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jérémy Lal]

On 30/05/2011 15:57, Bill Allombert wrote:
> On Wed, May 18, 2011 at 08:18:13PM +0200, Jan Hauke Rahm wrote:
>> Package: debian-policy
>> Version: 3.9.2.0
>> Severity: wishlist
>>
>> On Wed, May 18, 2011 at 07:55:33PM +0200, Jérémy Lal wrote:
>>> On 18/05/2011 19:38, Russ Allbery wrote:
 Anton Martchukov  writes:

> I wanted to install MoinMoin wiki (python-moinmoin) using
> FastCGI on nginx web server (nginx-full), but python-moinmoin
> brings Apache web server into the system due to its
> dependencies:

> python-moinmoin depends on libapache2-mod-wsgi | httpd-cgi

> nginx-full provides httpd

> I would submit a bug report on any of those packages, but 
> it does not appear clear to me:

> 1. Virtual package httpd-cgi is this only plain CGI or also
> can be FactCGI too? In case with nginx, it does not support
> plain old CGI, but does support FastCGI (plus SCGI and WSGI).

> 2. libapache2-mod-wsgi is not the only WSGI web server
> available. 

> 3. moinmoin is not limited to WCGI and CGI and also can
> be run with built-in web server, FastCGI, SCGI and AJP.

> The bottom line is that we are probably missing a bunch of
> virtual packages like:

> httpd-fastcgi
> httpd-wsgi
> httpd-scgi
> httpd-ajp
>>>
>>> +1
>>> especially for the distinction between httpd-fcgi and httpd-cgi.
>>> Note that "fcgi" name is more used than "fastcgi" in packages names.
>>>
 httpd-wsgi has already been requested.  See #588497.  So far, no one seems
 to have run into a practical requirement for the others, although if you
 have some cases where we'd use them (as opposed to just a theoretical
 need), please do file a debian-policy bug about that.
>>>
>>> I have the feeling it is a good idea to enforce web servers to declare their
>>> abilities like that. Today many webapps can run through fcgi, whether they 
>>> are
>>> in php, ruby, c... but they can't state that fact in their control fields.
>>> Instead, i've seen some of them depend on apache2, whereas they can run with
>>> any other httpd-fcgi (example: roundcube-core)
>>> Trouble is i'm not good at argumenting this in a bug report.
>>
>> I think you've made yourself clear. Let's just open the bug with this
>> mail to track what's already been said.
> 
> So what it is the list of packages that would provide fastcgi ?

those servers support fcgi, please add more if any :
apache2
lighttpd
nginx
cherokee

Note that lighttpd, nginx, cherokee can talk to fastcgi processes
(through unix or net sockets), while apache2 needs libapache2-mod-fcgid to do 
that.

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.
  It should only mean the web server can talk to an existing fastcgi process.
  The way to spawn it is specific to the "client" package (spawn-fcgi being a 
common tool
  to achieve that task, but is only a possibility among others)


* debian policy 11.5.5 would need an update then ?

--
Jérémy.








-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bill Allombert]

On Wed, May 18, 2011 at 08:18:13PM +0200, Jan Hauke Rahm wrote:
> Package: debian-policy
> Version: 3.9.2.0
> Severity: wishlist
> 
> On Wed, May 18, 2011 at 07:55:33PM +0200, Jérémy Lal wrote:
> > On 18/05/2011 19:38, Russ Allbery wrote:
> > > Anton Martchukov  writes:
> > > 
> > >> I wanted to install MoinMoin wiki (python-moinmoin) using
> > >> FastCGI on nginx web server (nginx-full), but python-moinmoin
> > >> brings Apache web server into the system due to its
> > >> dependencies:
> > > 
> > >> python-moinmoin depends on libapache2-mod-wsgi | httpd-cgi
> > > 
> > >> nginx-full provides httpd
> > > 
> > >> I would submit a bug report on any of those packages, but 
> > >> it does not appear clear to me:
> > > 
> > >> 1. Virtual package httpd-cgi is this only plain CGI or also
> > >> can be FactCGI too? In case with nginx, it does not support
> > >> plain old CGI, but does support FastCGI (plus SCGI and WSGI).
> > > 
> > >> 2. libapache2-mod-wsgi is not the only WSGI web server
> > >> available. 
> > > 
> > >> 3. moinmoin is not limited to WCGI and CGI and also can
> > >> be run with built-in web server, FastCGI, SCGI and AJP.
> > > 
> > >> The bottom line is that we are probably missing a bunch of
> > >> virtual packages like:
> > > 
> > >> httpd-fastcgi
> > >> httpd-wsgi
> > >> httpd-scgi
> > >> httpd-ajp
> > 
> > +1
> > especially for the distinction between httpd-fcgi and httpd-cgi.
> > Note that "fcgi" name is more used than "fastcgi" in packages names.
> > 
> > > httpd-wsgi has already been requested.  See #588497.  So far, no one seems
> > > to have run into a practical requirement for the others, although if you
> > > have some cases where we'd use them (as opposed to just a theoretical
> > > need), please do file a debian-policy bug about that.
> > 
> > I have the feeling it is a good idea to enforce web servers to declare their
> > abilities like that. Today many webapps can run through fcgi, whether they 
> > are
> > in php, ruby, c... but they can't state that fact in their control fields.
> > Instead, i've seen some of them depend on apache2, whereas they can run with
> > any other httpd-fcgi (example: roundcube-core)
> > Trouble is i'm not good at argumenting this in a bug report.
> 
> I think you've made yourself clear. Let's just open the bug with this
> mail to track what's already been said.

So what it is the list of packages that would provide fastcgi ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jan Hauke Rahm]

Package: debian-policy
Version: 3.9.2.0
Severity: wishlist

On Wed, May 18, 2011 at 07:55:33PM +0200, Jérémy Lal wrote:
> On 18/05/2011 19:38, Russ Allbery wrote:
> > Anton Martchukov  writes:
> > 
> >> I wanted to install MoinMoin wiki (python-moinmoin) using
> >> FastCGI on nginx web server (nginx-full), but python-moinmoin
> >> brings Apache web server into the system due to its
> >> dependencies:
> > 
> >> python-moinmoin depends on libapache2-mod-wsgi | httpd-cgi
> > 
> >> nginx-full provides httpd
> > 
> >> I would submit a bug report on any of those packages, but 
> >> it does not appear clear to me:
> > 
> >> 1. Virtual package httpd-cgi is this only plain CGI or also
> >> can be FactCGI too? In case with nginx, it does not support
> >> plain old CGI, but does support FastCGI (plus SCGI and WSGI).
> > 
> >> 2. libapache2-mod-wsgi is not the only WSGI web server
> >> available. 
> > 
> >> 3. moinmoin is not limited to WCGI and CGI and also can
> >> be run with built-in web server, FastCGI, SCGI and AJP.
> > 
> >> The bottom line is that we are probably missing a bunch of
> >> virtual packages like:
> > 
> >> httpd-fastcgi
> >> httpd-wsgi
> >> httpd-scgi
> >> httpd-ajp
> 
> +1
> especially for the distinction between httpd-fcgi and httpd-cgi.
> Note that "fcgi" name is more used than "fastcgi" in packages names.
> 
> > httpd-wsgi has already been requested.  See #588497.  So far, no one seems
> > to have run into a practical requirement for the others, although if you
> > have some cases where we'd use them (as opposed to just a theoretical
> > need), please do file a debian-policy bug about that.
> 
> I have the feeling it is a good idea to enforce web servers to declare their
> abilities like that. Today many webapps can run through fcgi, whether they are
> in php, ruby, c... but they can't state that fact in their control fields.
> Instead, i've seen some of them depend on apache2, whereas they can run with
> any other httpd-fcgi (example: roundcube-core)
> Trouble is i'm not good at argumenting this in a bug report.

I think you've made yourself clear. Let's just open the bug with this
mail to track what's already been said.

Hauke

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature