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()  
> early
> 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  
> about
> it.

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?

Nick Kew
zones-discuss mailing list

Reply via email to