On 3 Oct 2008, at 22:37, Jordan Brown wrote:
> Nick is trying to isolate virtual systems, not users. I've seen this
> problem on my personal hosting providers - my CGI scripts run as the
> same user as everybody else's, in the same file system. We'd
> better all
> trust each other. That's OK for cheesy little personal sites, but not
> so good for real businesses.
Exactly. That's the target market for this development. Though even
so if instead of CGI you used PHP or other in-process scripting, with
even less protection than your CGI enjoys.
> It's quite possible that the IP address alone is enough to determine
> which zone the server should run in, in which case you could
> probably do
> the zone_enter before the listen(). Even without that, the host name
> (HTTP "Host:" header) is enough, so you could do the zone_enter()
> in HTTP processing.
There's no zone_enter in HTTP processing. Just dispatch to a worker
that entered a zone at server startup.
> I agree with Dan that the savings here are questionable over simply
> running separate Apaches in each zone. You'd save on all-zone-global
> data (which might be COW pages that never get written) but that's
Indeed, it may be that I'm chasing something of very little value,
though it should be added that Apache can have a very big memory
footprint when in-process bloat like PHP is added. But I'm also
interested in whether a global dispatcher can be harnessed to
drive virtual servers even when there's only one public IP address.
> (Note, incidentally, that the picture might be different for a Java
> server, where the Java byte code for the application and a bunch of
> overhead objects might well fall into that sharable bucket.)
Would that apply to similar bytecode like Python, which is commonly
run in-process in Apache?
zones-discuss mailing list