Hi, 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 seperate. 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 business. 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 http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com [EMAIL PROTECTED] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* This message posted from opensolaris.org _______________________________________________ zones-discuss mailing list firstname.lastname@example.org