Hi Nic,

I have the feeling you are on the wrong track, if you want to start and 
maintain a apache server from the global zone and then fork worker procs 
into the zones.
This is not intended and also not needed - and here is why:

Security:

 From the zones point of view, it cannot see the global or other zones. 
The concept is isolation of process which is fully achieved and wanted.
Solaris has a important security feature other unixes do not have: least 
privileges.In Solaris you don't need to run the server as root with full 
power.
Option 1: Start the main apache process directly with a normal user 
webservd and give him the necessary privilege to open the port 80: 
net_privaddr
Option 2: Start it with the user root, but take away all privileges that 
root normally has (you spare a user).
This is the security feature that you really want.

Availability/Maintainability

By having to startup apache in every zone completely on its own makes 
the apache instances more available.
e.g. you could patch/start/stop one version of your own apache in one 
zone, but not the others.

Lightweightness

Infact zones are full of it.
The system maintains only one pagecache (like every other kernel 
resource). If you use sparse zones, files on the lofs are mapped against 
the same vnode, speeding up the start of processes and saving memory.
In a zone many os services are not needed and therefore not started - 
again saving memory and perhaps cpu.

Away from the defaults you can:

disable unneeded service instances in a zone.
make the zone more secure.
start apache with a restricted set of privileges.

You can always start and stop apache instances in a zone from the global 
zone:
zlogin <zone> svcadm <cmd> apache2

Regards,

Konstantin





Nick Kew schrieb:
> I can find plenty of documentation for using zones, but none
> for programming with them.  The best I can get is the .h files
> (undocumented), and random snippets from googling.
>
> In the Apache webserver community, we have a lot of demand from
> hosting companies and their users for better separation of
> different users and virtual hosts - for example, strong protection
> of a user's database access from other users of a (physical) host.
>
> I'm looking at a virtualised version of the server based on zones.
> The basic idea is that apache will run in different zones, which
> are then protected from each other.  At the same time, it should
> be lighter-weight than a full-blown virtualbox, with code and
> static non-sensitive data (configuration read at startup) shared,
> but all per-request data private.
>
> In normal operation, copy-on-write gives us this model for free.
> Does copy-on-write work across a zone_enter()?
>
> Currently the Apache httpd model includes:
> * Server starts up, reads general configuration, loads modules, etc.
> * Apache forks one or worker children, each with one or more threads.
> * Worker processes drop privileges before accepting connections from
>    the 'net.
> * There's no association between workers and hosts or users.  Workers
>    are shared between all users.
>
> In the past, we've had some efforts to improve separation, based on
> worker children running under different user IDs.  See for example
> the perchild MPM at apache.org.  There's a lot of demand for
> perchild-like solutions, but no really satisfactory solution.
>
>
> My proposal is to provide an option whereby worker children perform
> a zone_enter before accepting connections or reading application-
> sensitive data.  This of course assumes apache is started up in the
> root zone.  Each zone will be the home for one or more virtualhost.
> It should be possible for zones to have different sizes (numbers of
> worker threads) and bandwidths (through crossbow), and other
> customisations.  But the primary purpose - and I believe a huge
> selling-point - is the increased security of this virtualisation.
>
> Is there anywhere I can get the programmer documentation to get
> started on this work, beyond dabbling blindly with examples found
> on the 'net?
>
>   

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to