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 more 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 firstname.lastname@example.org