[zones-discuss] zwho command?
Is there such a thing as a command I can run in the global zone which will tell me who is logged into my non-global zones? Peter This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
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. 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? 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? 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. ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
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] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Calum Mackay wrote: hi Octave, thanks much for the comments. 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? Minimizing architectural change. Imagine a site with multiple NFS servers 'owned' by different business units. Each BU manages its own NFS servers. In my fictitious example, an X4500 has enough disk space, storage bandwidth and network bandwidth to replace all of the NFS servers. But the BU's are not willing to cede control of their NFS servers to one management entity. If containers could be NFS servers, they could 'map' one existing NFS server into one new NFS-container and each BU could continue to manage theirs. If. -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
So could we all agree that: An NFS Server in a zone means that the namespace it exports is restricted to that zone only. By that i mean no global zone access to that namespace, nor would that namespace be re-exported within another NFS Server zone instance ? btw: Team NFS is acutely aware of the desire to plop an NFS Server in a zone. Robert. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Robert Gordon wrote: So could we all agree that: An NFS Server in a zone means that the namespace it exports is restricted to that zone only. By that i mean no global zone access to that namespace, Unless I misunderstand you, we have no choice - the global zone's namespace is separate from a non-global zone's namespace. The only way to change that is to use a network-based directory service. This is a key design point of zones. -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
It sounds like we're saying that NFS is just a basic system service that we want to provide from our already existing - and independently-managed - zones, rather than setting up zones specifically to provide separate NFS services (with the various exceptions e.g. Jumpstart testing). That seems to make a lot of sense. Thanks much for enumerating your reasons for us, Octave Jeff, that's exactly what I was looking for. As Tom says, what remains, perhaps, is to define exactly how things should look, and behave, and I seem to be hearing: generally as it would in the global zone. Obviously, there are subtleties to be worked through, here. cheers, c. ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] NFS server in zones
And here is a link to the bug which is tracking NFS in zones: http://bugs.opensolaris.org/view_bug.do?bug_id=4964859 Note that the description sucks right now as far as OpenSolaris is concerned. I'll get the relevant comments back into the description. BTW: I crossposted to all of the discussion groups to get as much feedback as possible. I'm willing to pull back to just the nfs-discuss group and point the other groups to it. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Feb 14, 2007, at 12:47 PM, Jeff Victor wrote: Robert Gordon wrote: So could we all agree that: An NFS Server in a zone means that the namespace it exports is restricted to that zone only. By that i mean no global zone access to that namespace, Unless I misunderstand you, we have no choice - the global zone's namespace is separate from a non-global zone's namespace. The only way to change that is to use a network-based directory service. This is a key design point of zones. so lets say /export/z1 is the root of zone1; and it contains a directory that is called export. Zone1 exports it's /export, which is in reality the global zones /export/z1/export. I'm asserting that the global zone will not be allowed to NFS export anything below /export/z1; I'd even go further and say that any user in the global zone would not have access to /export/z1. (but then i am also an advocate that if there is something shared, solaris should disallow local access to that share point (and below) period... :) ) Robert.. PS; should we move the discussion to just nfs-discuss (or zones- discuss) rather than continue to cross-post ? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Robert Gordon wrote: So could we all agree that: An NFS Server in a zone means that the namespace it exports is restricted to that zone only. By that i mean no global zone access to that namespace, nor would that namespace be re-exported within another NFS Server zone instance ? I have some trouble parsing that, but my perception of the desired behaviour is: - a zone can only export resources that are within that zone (i.e. everything below it's zonepath), - a resource exported from a zone, may not at the same time be exported from the global zone; i.e. if zone a exports /export/foo then /zones/a/root/export/foo may not be exported by the global zone) - zone A and zone B may both export their own /export/foo since those are two distinct resources. -- Menno Lageman http://blogs.sun.com/menno Sun Microsystems ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Robert Gordon wrote: ... I'd even go further and say that any user in the global zone would not have access to /export/z1. ... This is already the case. The mode on the final zonepath directory must be 700. This is set when zoneadm installs the zone and verified when you do normal zone administration such as booting the zone. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [appliances-discuss] Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Menno Lageman wrote: Robert Gordon wrote: So could we all agree that: An NFS Server in a zone means that the namespace it exports is restricted to that zone only. By that i mean no global zone access to that namespace, nor would that namespace be re-exported within another NFS Server zone instance ? I have some trouble parsing that, but my perception of the desired behaviour is: - a zone can only export resources that are within that zone (i.e. everything below it's zonepath), - a resource exported from a zone, may not at the same time be exported from the global zone; i.e. if zone a exports /export/foo then /zones/a/root/export/foo may not be exported by the global zone) - zone A and zone B may both export their own /export/foo since those are two distinct resources. and also that the NFSMAPID_DOMAIN may be different for each zone. and all security modes are available to all zones, in particular each zone that is an NFS server maybe in a different Kerberos REALM. -- Darren J Moffat ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Wed, Feb 14, 2007 at 01:11:06PM -0600, Robert Gordon wrote: so lets say /export/z1 is the root of zone1; and it contains a directory that is called export. Zone1 exports it's /export, which is in reality the global zones /export/z1/export. I'm asserting that the global zone will not be allowed to NFS export anything below /export/z1; Yes, when zones are allowed to manage their exports then the global zone has to get out of their way. Upgrade consideration: when we ship zoned NFS service, what happens, on upgrade, to existing global zone shares in zoned areas? I'd even go further and say that any user in the global zone would not have access to /export/z1. [...] But if we resolve loopback NFS mount issues then any zone could access any other zone's NFS shares provided they have logical or physical connectivity between them. So why not allow global zone access then, mediated, perhaps, by NFSv4-style ID mapping? Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] NFS server in zones
Nicolas Williams wrote: I'd even go further and say that any user in the global zone would not have access to /export/z1. [...] But if we resolve loopback NFS mount issues then any zone could access any other zone's NFS shares provided they have logical or physical connectivity between them. So why not allow global zone access then, mediated, perhaps, by NFSv4-style ID mapping? Nico What about the case where the customer wants to administer the zone they purchased and they do not want the global zone admins to have local access to their data? I'd say make it simple - in order to get access, you must be able to mount the export and abide both by the share level machine access rules and either the UID mapping (NFSv3) or ID mapping (NFSv4) rules. Let the owner of the zone explicitly control the access to their data. ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Calum Mackay wrote: It sounds like we're saying that NFS is just a basic system service that we want to provide from our already existing - and independently-managed - zones, rather than setting up zones specifically to provide separate NFS services (with the various exceptions e.g. Jumpstart testing). That seems to make a lot of sense. I tend to agree, and the basic server consolidation target just makes sense. I want to pretend a zone is the box I used to have and not have to bump my nose on a funny behaviour or exceptions. However, there are some wrinkles: 1) I think there are a variety of use cases that may have disjoint requirements from consolidation, and I want to hear about them, too. One example we had awhile back - SAS shares some of its data via NFS, and loses this ability in a zone. Do they need anything different? 2) Since NFS is mostly an in-kernel service, unlike something like Apache, if you have some kind of issue with NFS stability, you lose the whole box, not just the zone. This lack of fault isolation isn't always something that people are aware of. Does this change anything for your use case? 2) Due to the above, it seems like the global zone admin should have a knob to turn to enable or disable the ability of a zone to share out files via NFS. Do people agree? 2.5) Is this related to whether the global zone can share a resource? 3) I know we've talked about a zone not being able to share stuff outside of its namespace, but I wonder if we should further restrict this to sharing storage that's fully administered in the zone, e.g. you can't share a filesystem you got via lofs, but you can share from a /dev/dsk/cxtxdx or a zpool that had been fully delegated to you. Opinions? 4) A bug currently prevents a client instance and a server instance from being safe to use on the same box (apologies, can't quote the bugid from here). How likely, in your use case, is it that this will be a problem, i.e. will your boxes be in the position where a zone needs data shared from another zone as opposed to a separate server? Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] NFS server in zones
Tom Haynes wrote: What about the case where the customer wants to administer the zone they purchased and they do not want the global zone admins to have local access to their data? Well, there is a tradition in Zones of making the global zone substantially more equal than others. Remember that the global zone admin can observe network traffic from local zones and can access any files in local zones. Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
[EMAIL PROTECTED] wrote: 4) A bug currently prevents a client instance and a server instance from being safe to use on the same box (apologies, can't quote the bugid from here). How likely, in your use case, is it that this will be a problem, i.e. will your boxes be in the position where a zone needs data shared from another zone as opposed to a separate server? Ah, I remembered the RE who owns it, and found the bugid - it's: 5065254 NFS/UFS deadlock when system is both NFS server and client RT ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Recommendations for utilizing global zones
Are there any pros/cons to using a global zone to host a service/app just as you do on the local zones (i.e. the global zone serves as just another host with the added responsibility of managing local zones)? Are there any pros/cons to using the global zone only as an administrative zone, serving no other purpose but to manage local zones? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Trusted Exensions already includes this functionality, although the implementation is not exactly what is being requested in this thread. In the case of Trusted Extensions, the global zone administrator determines which labeled zone directories may be exported via NFS. There is unique dfstab fiile for each labeled zone, but these files are not only visible and managed from the global zone. When a zone is booted (or made ready) its unique dfstab files is processed by the zoneadm daemon (in the global zone) and the appropriate directories are shared. When the zone is halted, the entries in the zone's dfstab are unshared. The MLS policy is automatically enforced in the kernel. Remote NFS clients must dominate the the zone's label to do read-only mounts of the labeled zone's exports. Label equality is required for remote read-write mounts. Although the implementation is probably adequate for current customers moving from Trusted Solaris 8, it has several limitations. For example, as Darren pointed out, secure NFS using Kerberos doesn't work well because we don't yet have a multilevel KDC. Another issue is that the labeled zone automounters can't use LOFS to mount directories exported from other zones running on the same host as themselves. Using NFS to mount a locally exported filesystem may cause a deadlock. There is a bug recorded about this for UFS, but I don't know if it has been seen with ZFS exports. If you have specific issues about Trusted Extensions, you should use the security-discuss forum instead of zone-discuss or nfs-discuss. --Glenn Josh Fisher wrote: Our company is a current consumer of Trusted Solaris 8 and we will be converting to Solaris 10 with TX. For the conversion to be final however we must wait for the Common Criteria EAL4+ CAPP, RBAC, and LSPP release of Solaris 10 with TX. We are currently using Solaris 10 Update 3 for testing. In Trusted Solaris 8 our data is seperated into clearances which range from unclass to Secret with compartments. Some of the classified data is shared out to other classified systems. In Solaris 10 with TX we will seperate our clearances with labeled zones. This is our reason nfs server functionality is needed in zones in Solaris 10 with TX. We will have classified data which only resides in a labeled zone which will need to be shared out to other systems with the same clearance. If any of this is confusing I will try to explain better if need be. Thanks. This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Wed, Feb 14, 2007 at 03:27:30PM -0600, Robert Gordon wrote: There maybe a conflicting security requirement here. Lets say I'm SA of the zone and i have exported /export/foo with krb5i (since my foo really needs tight security :) ) to a limited set of clients. Then along comes Mr Global SA and exports it with auth_sys to any old nfs client.. seems like that might be an issue ? Clearly if a zone is in charge of its exports then there should be no trivial way for a g-z admin to interfere short of using zlogin to interfere from within that zone. The interesting question is: how this works on upgrade where the g-z had shares inside a zone. Do we move these shares into the zone, or do we have a concept of zones that delegate sharing power to the g-z? ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Recommendations for utilizing global zones
In addition, if you can run that ssh service in the global zone on an interface on an admin network. I try to give the global zone an interface on the admin network only with public interfaces reserved for non-global zones only. John Clingan Sun Microsystems Sent from mobile phone. -Original Message- From: Brad Diggs [EMAIL PROTECTED] Subj: Re: [zones-discuss] Recommendations for utilizing global zones Date: Wed Feb 14, 2007 2:10 pm Size: 2K To: Brad Bowling [EMAIL PROTECTED] cc: zones-discuss@opensolaris.org The biggest problem with running a service in the global zone is that if compromised, it may be used to get privileged access to the non-global zones as well. IMHO if you plan to deploy non-global zones you are best off (from a security perspective) to run only the minimum necessary services (ssh) and install only the minimum number of software packages in the global zone. My global zone typically only runs ssh and has less than 200 packages. If a non-global zones require SUNW packages, then I make the non-global zone a whole root zone (e.g. don't read-only mount/inherit /usr, /lib, /sbin, and /platform from the global zone). Otherwise I just create sparse root zones. The biggest problem with this methodology is that you have to manually determine the package dependencies when installing SUNW packages in your non-global zone. One day Sun will resolve this issue and get package dependencies automagicly resolved like apt/yum/pkg-get works today. Until then its still a manual process. Having said that, the software/service that you may want to run may be available via the Blastwave package repository. In that case install a sparse zone and use pkg-get to install the desired software from blastwave.org. On this topic, I have made it very convenient in the Zone Manager to install any Blastwave package with -G pkg when creating or modifying a non-global zone. For example, you can create and install a sparse root non-global zone called z1 and install mysql5 from Blastwave with the following command: # zonemgr -a add -n z1 -z /zones -P pw \ -I â192.168.0.10|hme0|24|z1â -G mysql5 \ -C /etc/nsswitch.conf -C /etc/resolv.conf More info on the Zone Manager available here: http://opensolaris.org/os/project/zonemgr/ Regards, Brad On Wed, 2007-02-14 at 12:36 -0800, Brad Bowling wrote: Are there any pros/cons to using a global zone to host a service/app just as you do on the local zones (i.e. the global zone serves as just another host with the added responsibility of managing local zones)? Are there any pros/cons to using the global zone only as an administrative zone, serving no other purpose but to manage local zones? ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] NFS server in zones
Tom Haynes wrote: What about the case where the customer wants to administer the zone they purchased and they do not want the global zone admins to have local access to their data? That would violate basics of the zones model. The global zone admin has complete access to all devices attached to the system. How would you prevent the GZ admin from halting the zone, manually mounting the non-global zone's disk partitions into the global zone, and accessing the data? Preventing the global zone from accessing certain hardware components would open a very large can of worms. -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Robert Gordon wrote: On Feb 14, 2007, at 3:17 PM, Edward Pilatowicz wrote: this all makes logical sense to me. i would refine your second point though because it doesn't take into account lofs mounts. ex, if i have /export/foo in the global zone and then in zonecfg i configure a filesystem resource such that this directory is also lofs mounted in the zone at /export/foo, then who should be able to export the filesystem? it seems to me that both the local zone and the global zone should be able to export it (or not export it) independantly. ed There maybe a conflicting security requirement here. Lets say I'm SA of the zone and i have exported /export/foo with krb5i (since my foo really needs tight security :) ) to a limited set of clients. Then along comes Mr Global SA and exports it with auth_sys to any old nfs client.. seems like that might be an issue ? Seems like you need Solaris Trusted Extensions. :-) But in the end, a sufficiently-privileged user in the global zone can do anything. -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] NFS server in zones
2) Lack of requirements - we don't know what people want. In addition to the requirements already stated by others, another crucial one is a resolution of the infamous NFS/VM deadlock. There have been numerous bugs filed over the years concerning it but I believe the current one is 5065254 NFS/UFS deadlock when system is both NFS server and client If non-global zones are going to be NFS servers, then fixing this is a requirement. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Re: Re: guidance for beginner
[EMAIL PROTECTED] wrote: Excellent results were obtained! managed to create 5 zones on on T2k and another 4 on a 2nd T2k. Error msgs (as described) on one, no error messages on the other. And all the zones behaved perfectly. Gratifying. Thanx to everyone who contributed... It seems there is a plan to add some dedicated RH AS 3.8 boxes to the network, but I see from the zonemgr docs that it is possible to create some virtual Centos machines, on a T2k. What would we the fastest way to do this? I do have a CentOS-3.8-server-i386.iso to hand. Can I use that somehow? Well, you might have a problem there, seeing that the iso image has binaries for an x86/x64 computer and the T2k isn't. ;-) -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: Re: Re: guidance for beginner
However, there a good shot you can run those RH 3.8 services in zones natively (depending on the service). FWIW, I am working with customers running many more than 5 zones on a T2K. John Clingan Sun Microsystems Sent from mobile phone. -Original Message- From: Jeff Victor [EMAIL PROTECTED] Subj: Re: [zones-discuss] Re: Re: Re: guidance for beginner Date: Wed Feb 14, 2007 3:46 pm Size: 1K To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: zones-discuss@opensolaris.org [EMAIL PROTECTED] wrote: Excellent results were obtained! managed to create 5 zones on on T2k and another 4 on a 2nd T2k. Error msgs (as described) on one, no error messages on the other. And all the zones behaved perfectly. Gratifying. Thanx to everyone who contributed... It seems there is a plan to add some dedicated RH AS 3.8 boxes to the network, but I see from the zonemgr docs that it is possible to create some virtual Centos machines, on a T2k. What would we the fastest way to do this? I do have a CentOS-3.8-server-i386.iso to hand. Can I use that somehow? Well, you might have a problem there, seeing that the iso image has binaries for an x86/x64 computer and the T2k isn't. ;-) -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Hi, --- [EMAIL PROTECTED] wrote: 1) I think there are a variety of use cases that may have disjoint requirements from consolidation, and I want to hear about them, too. One example we had awhile back - SAS shares some of its data via NFS, and loses this ability in a zone. Do they need anything different? 2) Since NFS is mostly an in-kernel service, unlike something like Apache, if you have some kind of issue with NFS stability, you lose the whole box, not just the zone. This lack of fault isolation isn't always something that people are aware of. Does this change anything for your use case? This is a great point and shows that there has to be some reorg of the NFS framework. I don't know if that means we need a pseudo instance of the kernel modules for each zone. Or if we have to break it up into components that should be unique to each zone and ones that should be common. 2) Due to the above, it seems like the global zone admin should have a knob to turn to enable or disable the ability of a zone to share out files via NFS. Do people agree? I agree there is should be knob. Perhaps something in zonecfg like: add service set type=nfs end That would enable the zone to be an nfs server. What do you think? 2.5) Is this related to whether the global zone can share a resource? 3) I know we've talked about a zone not being able to share stuff outside of its namespace, but I wonder if we should further restrict this to sharing storage that's fully administered in the zone, e.g. you can't share a filesystem you got via lofs, but you can share from a /dev/dsk/cxtxdx or a zpool that had been fully delegated to you. Opinions? This might be useful for higher levels of security. Not sure how we would go about that, but it's definitely an interesting idea that I'm sure some gov. agency would love:) 4) A bug currently prevents a client instance and a server instance from being safe to use on the same box (apologies, can't quote the bugid from here). How likely, in your use case, is it that this will be a problem, i.e. will your boxes be in the position where a zone needs data shared from another zone as opposed to a separate server? I can definitely see situations where one zone is a server for another zone. One wacky idea would be a N1GE master zone sharing it's grid shares to execution nodes that could be anywhere on the network or even on the same box! Rob T ___ nfs-discuss mailing list [EMAIL PROTECTED] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com [EMAIL PROTECTED] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Hi Robert, Excellent point! I think this is a good example of why the same physical path can't be shared from a zone and the global zone at the same time. Perhaps excluding any zonepaths from being shared at the global zone is desirable if the nfs switch for that zone is turned on? Octave --- Robert Gordon [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 3:17 PM, Edward Pilatowicz wrote: On Wed, Feb 14, 2007 at 08:26:48PM +0100, Menno Lageman wrote: Robert Gordon wrote: So could we all agree that: An NFS Server in a zone means that the namespace it exports is restricted to that zone only. By that i mean no global zone access to that namespace, nor would that namespace be re-exported within another NFS Server zone instance ? I have some trouble parsing that, but my perception of the desired behaviour is: - a zone can only export resources that are within that zone (i.e. everything below it's zonepath), - a resource exported from a zone, may not at the same time be exported from the global zone; i.e. if zone a exports /export/foo then /zones/a/root/export/foo may not be exported by the global zone) - zone A and zone B may both export their own /export/foo since those are two distinct resources. this all makes logical sense to me. i would refine your second point though because it doesn't take into account lofs mounts. ex, if i have /export/foo in the global zone and then in zonecfg i configure a filesystem resource such that this directory is also lofs mounted in the zone at /export/foo, then who should be able to export the filesystem? it seems to me that both the local zone and the global zone should be able to export it (or not export it) independantly. ed There maybe a conflicting security requirement here. Lets say I'm SA of the zone and i have exported /export/foo with krb5i (since my foo really needs tight security :) ) to a limited set of clients. Then along comes Mr Global SA and exports it with auth_sys to any old nfs client.. seems like that might be an issue ? Robert. ___ zones-discuss mailing list zones-discuss@opensolaris.org *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com [EMAIL PROTECTED] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [appliances-discuss] Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Robert Gordon wrote: it seems to me that both the local zone and the global zone should be able to export it (or not export it) independantly. ed There maybe a conflicting security requirement here. Lets say I'm SA of the zone and i have exported /export/foo with krb5i (since my foo really needs tight security :) ) to a limited set of clients. Then along comes Mr Global SA and exports it with auth_sys to any old nfs client.. seems like that might be an issue ? Exactly why this should not be allowed. Only a single NFS server should ever be exporting a given local file system. Even it it isn't krb5 vs sys it could be two different krb5 realms and different NFSMAPID_DOMAINS. It can be either the global or local zone but not both at the same time. If a zone has been delegated the ability to be an NFS server (which IMO should NOT be the default - just like today with IP stack instances) then the global zone must not be able to share out the zones filesystems. -- Darren J Moffat ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Octave Orgeron wrote: Hi Robert, Excellent point! I think this is a good example of why the same physical path can't be shared from a zone and the global zone at the same time. Perhaps excluding any zonepaths from being shared at the global zone is desirable if the nfs switch for that zone is turned on? Do you think that such a switch should be per-zone or per-device/share? Octave --- Robert Gordon [EMAIL PROTECTED] wrote: On Feb 14, 2007, at 3:17 PM, Edward Pilatowicz wrote: There maybe a conflicting security requirement here. Lets say I'm SA of the zone and i have exported /export/foo with krb5i (since my foo really needs tight security :) ) to a limited set of clients. Then along comes Mr Global SA and exports it with auth_sys to any old nfs client.. seems like that might be an issue ? -- -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [appliances-discuss] Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Edward Pilatowicz wrote: On Thu, Feb 15, 2007 at 12:28:40AM +, Darren J Moffat wrote: Nicolas Williams wrote: On Wed, Feb 14, 2007 at 03:27:30PM -0600, Robert Gordon wrote: There maybe a conflicting security requirement here. Lets say I'm SA of the zone and i have exported /export/foo with krb5i (since my foo really needs tight security :) ) to a limited set of clients. Then along comes Mr Global SA and exports it with auth_sys to any old nfs client.. seems like that might be an issue ? Clearly if a zone is in charge of its exports then there should be no trivial way for a g-z admin to interfere short of using zlogin to interfere from within that zone. The interesting question is: how this works on upgrade where the g-z had shares inside a zone. Do we move these shares into the zone, or do we have a concept of zones that delegate sharing power to the g-z? delegation just like stack instances and ZFS. except lofs doesn't work like zfs or stack instances. What does lofs have to do with sharing over NFS ? with lofs the global zone SA can share any global zone file or directory with as many zones as he wants to. I read the statement as the g-z admin sharing with AUTH_SYS when the local zone admin shared with one of the kerberos mechs. share was implying NFS I thought not share between local zones on the same system with lofs. if the local zone SA has sensitive data that they don't want other zones to have access to they shouldn't put it into a shared location. and in the end any zone SA must trust their global zone SA. (since the global zone SA could always just cd into any zone on the system, tar up whatever they want, and distribute it to whoever they want.) You must always trust your global zone SA to some extent. If this really is about different sensitivity levels of data in each zone then using Trusted Extensions sounds like it might be the correct approach - this is exactly what it was designed for. -- Darren J Moffat ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
[EMAIL PROTECTED] wrote: I tend to agree, and the basic server consolidation target just makes sense. I want to pretend a zone is the box I used to have and not have to bump my nose on a funny behaviour or exceptions. However, there are some wrinkles: 2) Due to the above, it seems like the global zone admin should have a knob to turn to enable or disable the ability of a zone to share out files via NFS. Do people agree? For Trusted Extensions we generally don't want policy decsions, like what can be shared, to be made outside of the global zone. Therefore, a knob seems like a good idea. 3) I know we've talked about a zone not being able to share stuff outside of its namespace, but I wonder if we should further restrict this to sharing storage that's fully administered in the zone, e.g. you can't share a filesystem you got via lofs, but you can share from a /dev/dsk/cxtxdx or a zpool that had been fully delegated to you. Opinions? This seems like a good idea. Of course the zone's root directory is a special kind of lofs mount that is established during zone_create, so directories in that filesystem should be sharable. Even if the zone is created using zfs, the dataset's root is not in the zone. 4) A bug currently prevents a client instance and a server instance from being safe to use on the same box (apologies, can't quote the bugid from here). How likely, in your use case, is it that this will be a problem, i.e. will your boxes be in the position where a zone needs data shared from another zone as opposed to a separate server? This is a must fix. In TX we want to automount between labeled zones on the same machine. It seems to work with ZFS. Is the deadlock specific to UFS/NFS? --Glenn ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Feb 14, 2007, at 3:17 PM, Edward Pilatowicz wrote: i would refine your second point though because it doesn't take into account lofs mounts. ex, if i have /export/foo in the global zone and then in zonecfg i configure a filesystem resource such that this directory is also lofs mounted in the zone at /export/foo, then who should be able to export the filesystem? it seems to me that both the local zone and the global zone should be able to export it (or not export it) independantly. I disagree - I think a filesystem should have an owner, and the owner should have sole control over sharing. If the global zone needs to share the data, it should take over ownership, and from outside this should be visible as the data moving between servers. In a related area, and to address an earlier question I raised, I don't think getting a filesystem via a lofs mount should entitle you to share it - you should have device access delegated to your zone in order to do that. Zones folks may disagree. Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Octave Orgeron wrote: --- [EMAIL PROTECTED] wrote: 2) Since NFS is mostly an in-kernel service, unlike something like Apache, if you have some kind of issue with NFS stability, you lose the whole box, not just the zone. This lack of fault isolation isn't always something that people are aware of. Does this change anything for your use case? This is a great point and shows that there has to be some reorg of the NFS framework. I don't know if that means we need a pseudo instance of the kernel modules for each zone. Or if we have to break it up into components that should be unique to each zone and ones that should be common. I don't think we can go there - a service in the kernel which panics takes out all zones, and there's just nothing we can do about that (beyond minimizing panics as we try to do anyway). I think we need to set expectations that fault isolation is not as strong for this service. Sun has other virtualization solutions that would work better for real fault isolation. 2) Due to the above, it seems like the global zone admin should have a knob to turn to enable or disable the ability of a zone to share out files via NFS. Do people agree? I agree there is should be knob. Perhaps something in zonecfg like: add service set type=nfs end That would enable the zone to be an nfs server. What do you think? Yes, I had a setting like this in mind, as opposed to something that includes a path to a resource that may be shared. Rob T ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Robert Thurlow wrote: Glenn Faden wrote: 4) A bug currently prevents a client instance and a server instance from being safe to use on the same box (apologies, can't quote the bugid from here). How likely, in your use case, is it that this will be a problem, i.e. will your boxes be in the position where a zone needs data shared from another zone as opposed to a separate server? This is a must fix. In TX we want to automount between labeled zones on the same machine. It seems to work with ZFS. Is the deadlock specific to UFS/NFS? Good question! I don't expect that it is, but perhaps ZFS's use of the ARC would insulate it. Maybe Mahesh would know. Reading through 5065254 and related CRs it seems to be all about UFS; the various ways that ufs_write (and perhaps other ops) can grab various resources *before* a uiomove which can pagefault. ZFS looks structured quite a bit differently, and it has a call to zfs_prefault_write which should reduce the probability of issues with write significantly (but doesn't prevent the pages from being paged out between the pre-fault and a uiomove down the road). Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
