Another thing to be aware of is that the two Passenger instances won’t be able to share framework code with each other. Suppose that your 4 applications use the following Rails frameworks:
App 1: Rails 1.2.6 — allocated to Passenger instance A
App 2: Rails 1.2.6 — allocated to Passenger instance B
App 3: Rails 2.0.2 — allocated to Passenger instance A
App 4: Rails 2.1.0 — allocated to Passenger instance B

Although app 1 and app 2 use the same Rails framework, they won’t be able to share the framework memory with each other because they’re running on different Passenger instances.

But if your Apache’s only job is to use serve Passenger-powered applications, then you don’t need to sandbox is to an unprivileged user. Passenger supports privilege lowering out-of-the-box. In that case I’d just run Apache as root so that Passenger can lower the privilege of a Rails application to its corresponding owner.

The key point to understand is:

concurrency at the network layer != concurrency at the application layer

Tying those two together is a common mistake I see people making
(I don’t see a lot of writings on it, either).

All HTTP clients are always “slow” in relation to nginx $app_server;
especially those with slow upstreams. Slow clients hog up $app_server
processes by making them wait on I/O (making HTTP requests, keepalive
sockets, lingering close…).

nginx fully buffers a request before sending it to $app_server; this
means $app_server spends less time (almost none) waiting on network I/O.
So despite the extra data copy; $app_server resources are better used
doing application processing.

This problem actually applies less to mongrel than it does to Apache
because mongrel does I/O to clients asynchronously and independently of
the actual application processing. Reducing I/O time for Mongrels is
still a win because lightweight green threads are still heavier than the
accounting structures that nginx uses to manage sockets.

Apache has mpm_event which should fix things and nullify the benefits
nginx provides, but I’m not sure if it ever matured to the point of
usability. Converting an existing codebase like Apache to use events +
non-blocking I/O is a huge task and a single broken module can ruin your
day (the same way that C extensions like mysql can break Ruby threading).

and?

chmod 777 /home …

And yes, we have an automated way of setting up another Apache installation. It’s a script which asks the user what his domain name is, then setup a few Apache startup scripts and an Apache config file. It’s automatically assigned to a random port number.

is /home always by default root : root /home/$_youruser

@toppic hax !! dude