execd: fcgi, per-child, cgid and maybe suexec

[Colm MacCarthaigh <co...@stdlib.net>]

By next week, I'm going to start another development branch, for
mod_execd. By now though, there seem to be a few different problems
which execd might be able to solve for us, so before code is written,
it's probably useful to share some design ideas.

Here's a list of currect vaguely exec()-related problems:

  1. fork() and exec() introduces instability to the
     multi-threaded MPMs on some platforms. mod_cgid solves this
     for CGI, but there are other places where we do exec(), so
     we need a more generic mod_execd.

  2. The per-child MPM needs a new process manager for managing the
     backend daemon that handles requests, and for getting requests
     to those backends. We need to manage things like how many
     instances to create, how many to keep spare, and so on.

  3. For fastcgi, we need to do practically the same thing. We need
     to start some backend daemons, decide how many to keep around,
     how many to have spare, and so on.

[2.] implies suexec-like capabilities, and I'd like to see chroot() too.
And when you think about it, there's no reason why we couldn't implement
the per-child functionality as a special-case reverse proxy, which I'll
try and explain in a minute.

O.k., back to 1 for a minute, lets say we have a function that looks
like;

	ap_exec_something(&fdset, envp, argv);

we take an environment and an argv, and execd goes and fork()'s and
exec's it, and we return a file descriptor set (stdin, stdout, stderr)
which we pass about using standard SCM_RIGHTS file-descriptor passing
trickery. That function problably needs a more complicated form along
the lines of;

	ap_exec_something(&fdset, envp, argv, unixd_ugid, chroot);

To allow for suexec/chroot functionality. The idea then is that we write
a provider for these functions for each targets, so that on multi-thread
unix, we use mod_execd, on pre-fork and win32 we use mod_exec (which
just does the platform standard command execution) and set about
replacing all of our own uses of exec() with these functions, and
encourage third party module authors to do the same. Does that make
sense?

For [3], we need to develop a process manager for kicking off daemon
processes, Rails processess, clisp, something else whatever, so we give
mod_execd the power to do this, and some simply monitoring functionality
to restart children when they die, and so on. Nothing major in
particular. Having it in the same code base means we can share the code
for high-uid'ing and chroot'ing and so on, which is useful.

Now, back to [2], suppose that instead of developing the per-child MPM,
we added a new propreitary proxy method, I'll call it "fdpass" for now,
we could probably get identical functionality to the per-child MPM just
using the same approach as our fast-cgi support. We would have the proxy
core code decide where to direct the request, but rather than proxy it
in the traditional sense - which involves double-reading/writing of
bytes, we send a small header with information about the request (maybe
even SSL state information if we could figure that one out) and then
pass the actual request fd to the backend httpd.

The backend-httpd would have been exec'd with a magic argument which
told it to listen on standard-input for the as-yet undeveloped
receive-fd protocol module.

The catches in all of the above are that mod_execd would need to run as
root, or we'd need a more generic suexec-like tool. And it's all quite
complicated too.

[1] and [3] on their own are simply enough, [2] is the crazy part.
Does any of this make any sense?

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Re: execd: fcgi, per-child, cgid and maybe suexec

[Jim Jagielski <ji...@jaguNET.com>]

Just this last one, and then that's it until mid-next-week :)

On Dec 29, 2005, at 5:47 PM, Colm MacCarthaigh wrote:

>
> [1] and [3] on their own are simply enough, [2] is the crazy part.
> Does any of this make any sense?
>

This all makes a lot of sense to me, in fact #2 kind of aligns
with something I was thinking about regarding how to
fit per-child into the proxy balancer stuff. In fact,
I think that having proxy balancer be the front
end to mod_execd allows for a lot of scaling
and control, but I haven't gone any further than
just thinking about it conceptually (something like
defining a worker execd://foo.com/process).

Yeah, we'll need something like apr_pass_fd/apr_grab_fd.

This reminds me: I know that the GSoC effort for perchild didn't
work out, but was *anything* done? I heard something about a
design framework being produced?

Re: execd: fcgi, per-child, cgid and maybe suexec

[Garrett Rooney <ro...@electricjellyfish.net>]

On 12/29/05, Colm MacCarthaigh <co...@stdlib.net> wrote:
>
> [1] and [3] on their own are simply enough, [2] is the crazy part.
> Does any of this make any sense?

I don't know enough about [2] to say if it's possible or not, but it
makes sense at first glance.  I'm highly in favor of [3], since it
means that Paul and I don't need to implement that part of it
ourselves as part of the fastcgi work, so go for it!  ;-)

-garrett