Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of rainer.jung@kippdata.de
 designates 195.227.30.149 as permitted sender)
Message-ID: <4ABA234F.3000002@kippdata.de>
Date: Wed, 23 Sep 2009 15:31:59 +0200
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: [mod_fcgid] How to share between vhosts (and extensions)
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Sorry for the long mail, especially in case all is well-known.

While looking for the right way to implement something like FCGIDGroup I
stumbled about something a bit strange in mod_fcgid.

When looking for an appropriate existing process to handle a request the
following data is used by mod_fcgid:

- inode
  inode num of the wrapper if one is used,
  of the request filename otherwise
- deviceid
  device id of the wrapper if one is used,
  of the request filename otherwise
- share_grp_id
  Always 0 if no wrapper is used,
  -1 for one of the auth wrappers,
  otherwise an incrementing id that is
  unique across each wrapper with the same path
  (but different vhosts or even only different extensions)
  ids between different paths can overlap
- virtualhost: the pointer (!) to
  r->server->server_hostname
- uid: retrieved via ap_run_get_suexec_identity
- gid: retrieved via ap_run_get_suexec_identity

If no process is found, a new one is created and carries the above data
coming from the request (and wrapper) which ran when it was created.

Going a bit through the history of mod_fcgid, it seems that share_grp_id
was added to support a directive FCGIWrapperGroup (sic!). Later the
directive was removed, and the id was automatically incremented to
ensure separation.

Again later there was a bug w.r.t. incomplete isolation of the default
env between vhosts, so virtualhost was added, but seems only necessary
for the non-wrapper case.

It seems there's some potential for improvement concerning sharing of
fastcgi applications.

1) Non-wrapper case

The applications are given by the filenames the requests resolve to. So
the most likely thing that could happen, is that someone wants to share
the process pools for those between vhosts. I guess for this it would be
enough to add FCGIDGroup. It would be optionally used once in vhosts to
set a symbolic name, which will be used to seperate the pools between
vhosts instead of the server_hostname. By choosing the same FCGIDGroup
in several vhosts, one can share the process pool.

2) Wrapper case

The wrapper is configured via its path name and the optional extension
it applies to. At the moment independent pools are used for different
vhosts, but also (!) for different extensions.

So if we would add FCGIDGroup to a vhost, it would stop the extension
separation. Another possibility would be, to apply FCGIDGroup only to
the non-wrapper case and add some syntax to FCGIWrapper to allow
expressing, which group it belongs to. Unfortunately that directive
already has two optional arguments, one can be detected, because it
starts with a dot, the other one is the fixed string "virtual". The
syntax might get ugly, if we need to safely distinguish three optional
arguments

Something like

FCGIDWrapper wrapperpath [groupname] [.extension] [+flag ...]

and the only flag implemented at the moment is "virtual".

Regards,

Rainer