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] NFS server in zones
[EMAIL PROTECTED] writes: 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. I think we already have this as a potentially serious problem for non-global zones that are NFS clients of the global zone, don't we? Making it work right would involve either resolving the underlying deadlock or somehow identifying those self-mounts and doing a lofs mount from the global zone instead. I think the latter is what's done for TX, but it's in a very narrow usage case. The general case hasn't been solved. I don't think it's a special problem that's particular to allowing non-global zones to be NFS servers. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ 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: [appliances-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Thu, Feb 15, 2007 at 01:30:44PM -0800, [EMAIL PROTECTED] wrote: Luke Scharf wrote: Why not just run a userland NFS daemon in the zones -- and follow the existing security model? That makes all of the security model questions fall away -- and it also gets fault isolation. There's a slight performance penalty, but you're running a VM-ish environment anyway. Not entirely. Look at OpenAFS, which does just that. There are two issues: 1) You need an open-by-FID (fsid+inode) type of system call, which gets us back to the issue that no single filesystem should have separate sub-directories shared by different zones. 2) You need a bunch of system calls like open(2) but augmented with an argument specifying who to do the operation as. I blogged about (2) here: http://blogs.sun.com/nico/entry/building_filesystem_servers_in_user in the context of hostafs -- a user-land AFS server for serving non-AFS local filesystems. Normally OpenAFS gets around (1) and (2) by implementing the filesystem in user-land, not just the protocol. This means that there's no local access to AFS-shared filesystems. (Hmmm, much of ZFS runs in user-land, so perhaps one could run an all-user-land NFS+ZFS server, but, does anyone really want to build such a thing?) Of course, you still need an implementation of NFS in user-land... This thought did occur to me and if you take it to the logical conclusion, there is no way to restrict which directories or partitions a zone shares if they are accessible inside the zone. Well, this is true, but if you restrict access via an open-by-FID syscall (see (1) above) to filesystems owned only by the zone whence the call is made, then this problem goes away. In practice you can't have NFSv3 (or AFS) service without open-by-FID. For NFSv4 you can get by without it with some minor limitations. This presupposes that root in the zone has access to software to do this...but there have been programs around for over a decade that are standalone NFS clients, so I can't see why there isn't an NFS server equivalent. See above. With respect to performance, there isn't really any serious performance hit at all for applications running in a local zone. They interact directly with the kernel and disk, just like they would if they were running in the global zone. But we're talking about an NFS server in user-land -- surely there'd be a perf hit as compared to NFS service in kernel-land (if nothing else it may complicate server-side zero-copy, but then, you can't have that if you want crypto in the protocol, not without RDDP, IPsec-capable RNICs and channel binding to IPsec, but that's all a long story). Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [appliances-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Thu, Feb 15, 2007 at 03:58:38PM -0600, Nicolas Williams wrote: (Hmmm, much of ZFS runs in user-land, I meant that much ZFS code compiles and can run in user-land, not that it actually works that way in production. ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [appliances-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
On Thu, Feb 15, 2007 at 03:58:38PM -0600, Nicolas Williams wrote: Of course, you still need an implementation of NFS in user-land... Speaking of which, IIRC Sun had a Java NFSv4 server (written by Brent Callaghan, as I recall) that was used during development of the protocol, and there's a python implementation out there: http://www.citi.umich.edu/projects/nfsv4/pynfs/ Nico -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [appliances-discuss] Re: [nfs-discuss] Re: [sysadmin-discuss] NFS server in zones
Luke Scharf wrote: Why not just run a userland NFS daemon in the zones -- and follow the existing security model? That makes all of the security model questions fall away -- Would you clarify that? I don't know how NFS works, but it seems to me that the security enforcement components should be performed in the kernel where there is better protection. That doesn't preclude the rest from living in userland. -- 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
I think we already have this as a potentially serious problem for non-global zones that are NFS clients of the global zone, don't we? Making it work right would involve either resolving the underlying deadlock or somehow identifying those self-mounts and doing a lofs mount from the global zone instead. That's true although whether or not such a deadlock takes place today is defined by how the global zone administrator sets up their system. The capability to create the deadlock is in the hands of the global administrator. If non-global zones are allowed to share parts of their file system, there is a denial of service that can take place if another non-global zone ends up mounting that file system, putting the whole system at risk. That's not to say that I'm happy with the current situation - we should resolve the deadlock or as you suggest, translate those NFS mounts into an appropriate lofs mount. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
