Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Thu, 15 Feb 2007 06:19:10 +0100, Mahesh Siddheshwar [EMAIL PROTECTED] wrote: 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. The problem seen in 5065254 and what is seen commonly in the recent past is mainly due to the interaction between NFS, UFS and segmap driver**. This scenario, typically, is noticeable only under heavy load or on systems with a low segmapsize. Since ZFS does not use the segmap driver, this particular scenario should be averted. Currently the loopback mounted configuration is never tested. So I won't be surprised if we run into other loopings, but with some effort those should be tractable. Mahesh ** NFS tries to commit pages, which, on the NFS server requires UFS to obtain a segmap slot. Before you use the segmap slot, you need to free/destroy the previous mappings for the segmap slot, which happens to be a locked NFS page, the lock for which is currently owned by the commit thread which begun this process. There is one more scenario which I have not seen, but is theoretically possible -- where writing to a UFS file requires stealing a dirty NFS page which would in turn require writing to the server, which requires exclusive locking of the same UFS file. even if you leave this segmap issue aside, it is very likely you encounter different deadlocks, because this is an attempt to stack file systems that are not really stackable file systems and you'd run into issues similar to 4498652 / 4154394 --- frankB ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Robert Thurlow wrote: 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, In general we recommend not delegating devices into a zone since that opens up various security holes if the zone is compromised. For example, with access to a disk device, it is possible for the zone admin to crash the whole system. We only recommend delegating devices to zones that are trusted and only if it is necessary. However, delegated ZFS datasets don't have this issue. Jerry ___ 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 05:55:12PM -0800, Glenn Faden wrote: 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. Further, zones should not be able to share filesystems that aren't wholly owned by them -- whether the zone gets it by lofs mounting or by having its root directory as a sub-directory of a larger filesystem that has other sub-directories available to other zones or in the global zone. This to avoid issues with NFSv3 file handles for files in the same filesystem but outside the sharing zone being accessible through it. Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [appliances-discuss] Re: [zones-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Darren J Moffat wrote On 02/14/07 14:30,: 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. This has been one of my arguements for NFS services in a non-global zone. Besides the separated administrative domains that may be co-located using zones, the other preference that I have is that the services used in the global zone are minimal. I'd rather it be in a separate, non-user (non-service) oriented name service (authentication) domain. Thus any of the authentication and authorization that would need to be done has to be done at the name service level for the zone hosting the service(s). And I can host similar services in different zones for different authentication domains. For all the reasons running a service in a non-global zone is more secure. Steffen ___ 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
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] 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] 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
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] 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
[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
