Read below..

--- Calum Mackay <[EMAIL PROTECTED]> wrote:

> hi Octave, thanks much for the comments.
> However, I think there's a need to take a few steps back...
> The requirements you list are things that seems to me to be: once we 
> have decided that we want an NFS server in a zone, these are
> important 
> things that should be true of the delivered product.
> But I'm not yet seeing clear reasons for *why* we want an NFS server
> in 
> a zone. I'm certainly not saying that we don't want this, I just want
> to 
> fully understand the need for it.

There are many reasons that people would want this. To list a few: 
1. Consolidate different NFS sharing environments that have to be
2. Provide SA's with their own test jumpstart environment without
wasting a server per SA. This has come up as a project at two different
employers of mine.
3. Consolidate developer environments onto one system. Each zone may be
for different departments that need to NFS share their products. 
4. Consolidate NFS home directories and keep them separate per line of

I think you can see a pattern here. People want to consolidate
environments that normally require separate servers. There are many
applications of NFS and to require all NFS to be managed from the
global zone is backward. It prevents owners of a Zone from being able
to manage their own services. It's totally reasonable to keep
management of cpu, memory, networking, storage, etc up at the global
zone level. But it does not make sense for basic services, like NFS.

> > scrap projects. Probably the most common idea for having a zone NFS
> > server is for Jumpstart or home directories. As things stand today,
> > it's not doable. 
> Right, but these things are easily done (of course) using a server in
> the global zone: what advantages do we gain by putting the server in
> a 
> local zone?

Simple, NFS is a basic UNIX service. If you want to provide zones to
different groups within your business that have their own SA's, it's a
roadblock for projects. An SA who manages a zone has to contact the
global zone SA to make simple NFS changes. For a services based data
center this is a waste of time. It's understandable to require owners
of zones to request more cpu, memory, storage, etc. These are things
that need to be charged back for ROI. NFS is a basic service and should
be manageable from a zone. It's like requiring SSH access to be
controlled from the global zone.

> > I think the key requirements would be:
> > 
> > 1. Full NFS server functionality within a zone. So things like
> share,
> > /etc/dfs/dfstab, sharemgr, ZFS sharing, etc. should work in the
> same
> > manner as they do in the global zone.
> Yes, this would definitely be a delivery requirement for this
> project, 
> but it doesn't sound like a justification for it.
> > 2. Security. Separation of NFS namespace to insure proper security
> > between zones. 
> I'm not sure I quite understand this. Would you please expand?

Meaning that if a zone is compromised, the other NFS shares across the
machine should not be accessible or manageable. 

> > 3. Performance. NFS serving out of a zone should not be slower or
> less
> > scalable than NFS serving from the global zone.
> Indeed, this would be an important delivery requirement, of course.
> thanks again for your comments.
> cheers,
> calum.

Octave J. Orgeron
Solaris Systems Engineer
This message posted from opensolaris.org
zones-discuss mailing list

Reply via email to