Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
If we want any form of internal consistency, wouldn't we also need to change were we assign datalink names from zonecfg to dladm? Thus no more 'net' resource in zonecfg for exclusive-IP zones, but instead some dladm set-zone zoneA bge1 Only having dladm show it, and not be able to affect it, seems quite inconsistent. As Dan pointed out, there are already other commands such as ifconfig(1M) and mount(1M) which manipulate or observe resources assigned to a zones so using dladm(1M) wouldn't be that inconsistent. I think the objection is around adding a resource-specific option to zoneadm list. Rather than waiting for the info command, what about introducing a -o format option instead where datalinks or something like that can be used to indicate you wish to select the data links of each zone as the information to be printed? dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
Erik Nordmark writes: James Carlson wrote: I don't think that argument works on two counts. First, exclusive-IP behavior does not offer complete IP isolation, because you can't (for instance) install your own copy of Firewall-1 or Cisco VPN into a non-global exclusive-IP zone. Agreed you can't do that. But how does that make IP packets leak between different exclusive-IP zones? It doesn't make the packets leak. It makes the administrative activities leak. Perhaps we have a different definition of what IP isolation means? To me the critical property is that there is no IP packet leakage. I don't think it's the only property. Some things do still require global zone administration. Second, ps shows processes that the user in the global zone cannot 'administer' by way of kill(2), so they are at least as isolated as IP instances, but they're still of interest to global zone administrators who want a global view of the system. I tried the kill and AFAICT root in the global zone can kill a process in a non-global zone: OK. I must be misremembering this. I thought the restriction was more complex than that. All that said, I think making ifconfig list the interfaces present in exclusive-IP zones, given the design of ifconfig, would be prohibitively difficult. It'd have no access to the DLPI nodes, which is where it gets some of its information, and the ioctls it uses for tunnels and the like won't work well if the zones have independent control of the interfaces. (It'd work for now, but I think it'd end up representing more confusion with Clearview, as there'd be no easy way to coordinate interface names across multiple zones, so ifta_lifr_name would be ambiguous.) I agree it would be a pain to implement. zone_enter() would be one way. But the key thing to me is the consistency between where things can be observed and where they can be modified. We already have RFEs filed against other utilities because they don't show non-global zone activity (see, for example, CR 6369726). I think the lines here are pretty blurry. In some usage models, the global zone administrator owns everything. Even if he can't directly control things from the global zone (and must log into the non-global zone to turn services on and off), he wants to see a view of the system that includes everything. In other usage models, the global zone administrator just provides infrastructure and has no business looking at non-global zones. And we've had requests to lock down the global zone so it can't look where it shouldn't. Given that there are some networking things that must be administered in the global zone alone even when exclusive stack instances are in use, it doesn't seem unreasonable to me to say that the administrator of the global zone should be able to list related information without entering the non-global zone. -- James Carlson, KISS Network[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: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
[EMAIL PROTECTED] wrote: If we want any form of internal consistency, wouldn't we also need to change were we assign datalink names from zonecfg to dladm? Thus no more 'net' resource in zonecfg for exclusive-IP zones, but instead some dladm set-zone zoneA bge1 Only having dladm show it, and not be able to affect it, seems quite inconsistent. As Dan pointed out, there are already other commands such as ifconfig(1M) and mount(1M) which manipulate or observe resources assigned to a zones so using dladm(1M) wouldn't be that inconsistent. Yes, but those provide for manipulation (aka change) and observability in the same place. Rather than waiting for the info command, what about introducing a -o format option instead where datalinks or something like that can be used to indicate you wish to select the data links of each zone as the information to be printed? Wouldn't this set a precedent that other things be available as -o? E.g. -o uuid, -o brand, ... Only introducing '-o datalinks' and never introducing any other -o specifiers bit instead moveingto an info subcommand for subsequent ones seems odd. If you commit to adding other -o specifiers in short order, then I can see the benefit of introducing '-o datalinks' as part of IP Instances. If not, then this seems like a dead end to me. Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
Erik Nordmark writes: James Carlson wrote: Erik Nordmark writes: But the key thing to me is the consistency between where things can be observed and where they can be modified. We already have RFEs filed against other utilities because they don't show non-global zone activity (see, for example, CR 6369726). I think the lines here are pretty blurry. In some usage models, the global zone administrator owns everything. Even if he can't directly control things from the global zone (and must log into the non-global zone to turn services on and off), he wants to see a view of the system that includes everything. Do you have an example of that? I'm not sure I understand the question. Is CR 6369726 a suitable example? If not, then what are you asking? Given that there are some networking things that must be administered in the global zone alone even when exclusive stack instances are in use, it doesn't seem unreasonable to me to say that the administrator of the global zone should be able to list related information without entering the non-global zone. ifconfig displays network interface names used by IP and IP addresses and related information. zoneadm list -l displays the datalink names assigned to an exclusive-IP zone. Are you saying that the datalink names are insufficient for the administration the global zone would need to do for the exlusive-IP zone? Yes, if the administrator of the global zone needs to know what networks are involved in order to make a change. For example, if the administrator of the global zone has Firewall-1 installed, he's going to need to configure IP details in the global zone. I don't see how he can do that if he doesn't have access to them. There are things external to the system (such a firewalls) that might need to be configured with IP addresses, and I can see the same thing being true for the global zone (e.g. the global zone might run a firewall in front of the non-global zone down the road). Right. But I don't see that particular type of configuration as an argument for being able to do ifconfig -a in the global zone and see the non-global information, any more than there being a requirement for a router outside the system being able to do ifconfig -a and see the IP configuration of other systems on the network. It depends on the administrator's mental model for the system. Seeing IP addresses for other systems on the same network would not be a rational thing to expect out of ifconfig. Seeing IP addresses configured inside the very same box on the very same running kernel, though, may well be a rational expectation. Thus I am trying to understand what the architectural or design principle is that makes you conclude that showing IP address configuration for exclusive-IP zones in ifconfig in the global zone. The design principle is that we have different tools for different tasks, and those tools are expected to give you a coherent view of the system. I do expect to use the resource control commands to control resources that I'm going to delegate to zones. I do expect to be able to view mount points and devices in use on the local system using tools designed for those purposes, regardless of what zone is involved. I don't expect to use one tool to list datalinks and IP interfaces when they're in my local zone (dladm, ifconfig) and a completely different tool when they're in the same system but in some other zone. That's not the model we had been using, which is why ifconfig currently does show interfaces in non-global zones, even though you can't use those interfaces in the global zone. The exception is where zonecfg sets up boundary conditions for a given zone, and thus must take on tasks from other subsystems, but even in those cases, I expect the 'native' (non-zones) tools to work as well with those resources as with ones in the global zone. In fact, I don't see what it has to do with zoneadm. The question is whether there's a single global view of the resources on the system. If the answer is no, then I suspect we'll end up needing to find a way to provide that view, because that hasn't been a broadly accepted answer in the past. -- James Carlson, KISS Network[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: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
As Dan pointed out, there are already other commands such as ifconfig(1M) and mount(1M) which manipulate or observe resources assigned to a zones so using dladm(1M) wouldn't be that inconsistent. Yes, but those provide for manipulation (aka change) and observability in the same place. However, dladm(1M) is still the place (from the global zone) where such datalinks are instantiated, right? For example, isn't that the method in which VNICs are created is through dladm? Or aggregated links? Rather than waiting for the info command, what about introducing a -o format option instead where datalinks or something like that can be used to indicate you wish to select the data links of each zone as the information to be printed? Wouldn't this set a precedent that other things be available as -o? E.g. -o uuid, -o brand, ... Yes, it would. Only introducing '-o datalinks' and never introducing any other -o specifiers bit instead moveingto an info subcommand for subsequent ones seems odd. If you commit to adding other -o specifiers in short order, then I can see the benefit of introducing '-o datalinks' as part of IP Instances. If not, then this seems like a dead end to me. Although there isn't an approved case on this yet, I believe there has been some general agreement that such an option may be useful (especially since the default list -v output is getting rather wide). Can we hold off on introducing the list -l functionality from this design until we can resolve how to deal with the more general observability issue? Perhaps either through a zoneadm info or a zoneadm list -o mechanism? dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
I tried the kill and AFAICT root in the global zone can kill a process in a non-global zone: OK. I must be misremembering this. I thought the restriction was more complex than that. Within the global zone, the ability to kill a process in a non-global zone is controlled by the proc_zone privilege. Normally, only a user with all privileges will have this ability unless modified via RBAC. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
[EMAIL PROTECTED] writes: I tried the kill and AFAICT root in the global zone can kill a process in a non-global zone: OK. I must be misremembering this. I thought the restriction was more complex than that. Within the global zone, the ability to kill a process in a non-global zone is controlled by the proc_zone privilege. Normally, only a user with all privileges will have this ability unless modified via RBAC. Thanks. ;-} I _knew_ it wasn't as simple as killing a process in the global zone. -- James Carlson, KISS Network[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: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
James Carlson wrote: In some usage models, the global zone administrator owns everything. Even if he can't directly control things from the global zone (and must log into the non-global zone to turn services on and off), he wants to see a view of the system that includes everything. Do you have an example of that? I'm not sure I understand the question. Is CR 6369726 a suitable example? If not, then what are you asking? Sorry, I misread want as need in the sense of being a show-stopper. For example, if the administrator of the global zone has Firewall-1 installed, he's going to need to configure IP details in the global zone. I don't see how he can do that if he doesn't have access to them. Sure. But that is analogous to the external firewall. We could decide that we want zones/containers/domains on the same system to be different, but I think there is value in following a network model for network components. After all the network is the computer(tm) ;-) It depends on the administrator's mental model for the system. Agreed. My point is that the model for an exclusive-IP zone is different in important aspects than the shared-IP zones. We could try to hide this by pretending that (parts of) ifconfig behavior is the same, but I'm far from certain that is a good idea. But the suggestion (made at PSARC) to use dladm to both - assign datalink names to zones and - observe them (in e.g. show-link) is one which satisfies the consistency between manipulation and observation. (And zonecfg can specify things as well; dladm can be used to manipulate and observe the running state.) Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re:[crossbow-discuss]Design review of IP Instances part of Crossbow
From: James Carlson [EMAIL PROTECTED] Erik Nordmark writes: It depends on the administrator's mental model for the system. Agreed. My point is that the model for an exclusive-IP zone is different in important aspects than the shared-IP zones. And in other important aspects it's the same: it's still a single shared kernel and a single set of hardware resources. For that reason, I don't believe it's entirely wrong for users to want to be able to answer questions such as what addresses are being used by this node? ... Anyway, as I said at the beginning, I think making ifconfig work this way would be very hard to do, and likely would not work well. Though users often think of ifconfig as the sole way to interact with networking interfaces (because that's the way it works everywhere but Solaris), I don't think that's reasonably doable here, even if it's something that might be wanted. So how would you propose a system administrator, in the global zone, bring together all of the network addresses configured for his machine? Does this now require zlogin and a loop through all of the zones that are currently booted? Will this be too hard for those that want to do it? Thinking on this, would it be nice if there was some special command line switch for the likes of netstat/ifconfig and others that caused them to iterate through all of the present stack instances and report on them? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
- Original Message - From: Erik Nordmark [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Could ifconfig be modified to report all network interfaces that are assigned to a zone? I assume you mean in the global zone; ifconfig -a inside a zone (global or not) does report all the network interfaces that are configured. Yes I do, and more specifically, I was referring to the shared stack model, not the exclusive stack model. I can't see any reason why or for ifconfig, in the global zone, should report on interfaces that belong to other zones where they are using the exclusive zone model. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
Jeff Victor wrote: Here's one reason: consistency. All users in the GZ can see some inforamtion about non-global zones (e.g. ps). Privileged GZ users can see all info about non-global zones, and need to do so in order to manage them. But the exclusive-IP behavior is quite different from the shared-IP behavior; it offers complete IP isolation between different zones/IP instances. The argument that it should have consistent behavior could also be used to argue that it shouldn't offer IP isolation. I'm sure that isn't the type of consistency we desire. I am not certain that observation of exclusive-IP-instances from the GZ should be the default, but it should be possible. They can be observed from the global zone using zoneadm list -l instead of ifconfig -a, which is used for the shared-IP zones. (And if the global admin wants to look deeper than that output, then for both the exclusive and shared cases things behave the same in that e.g. netstat in the global zone does not report information for other zones.) Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
Darren Reed wrote: - Original Message - From: Erik Nordmark [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Could ifconfig be modified to report all network interfaces that are assigned to a zone? I assume you mean in the global zone; ifconfig -a inside a zone (global or not) does report all the network interfaces that are configured. Yes I do, and more specifically, I was referring to the shared stack model, not the exclusive stack model. OK. IP Instances doesn't change that part. Erik I can't see any reason why or for ifconfig, in the global zone, should report on interfaces that belong to other zones where they are using the exclusive zone model. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Eric Enright wrote: I'd like to express interest in this as well. Just last week I came across the need for this, and was disappointed to learn that it (or something similar) is not there. Would zoneadm list -l as specified (with example output) in http://www.opensolaris.org/os/project/crossbow/Docs/si-interfaces.pdf be sufficient? Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Eric Enright wrote: I just subscribed to this alias, apologies if I'm missing anything from this thread... Some of this was discussed a few months back. I'd like to express interest in this as well. Just last week I came across the need for this, and was disappointed to learn that it (or something similar) is not there. Did you look at the description of 'zoneadm list -l' in the si-interfaces.pdf? The next code drop will include that functionality, and it was added in response to a request for better observability on the crossbow-discuss list. Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
[EMAIL PROTECTED] wrote: Could ifconfig be modified to report all network interfaces that are assigned to a zone? I assume you mean in the global zone; ifconfig -a inside a zone (global or not) does report all the network interfaces that are configured. But that would be quite odd. The reason is that ifconfig in the global is not involved in configuring IP for the exclusive-IP zones; that is done by ifconfig running inside the exclusive-IP zones. This is by design different than the IP configuration for the shared-IP zones; those are both configurable as well as observable using ifconfig in the global zone. Furthermore, since the primary purpose of IP Instances is IP-level isolation (between different zones that are connected to different LANs or different VLANs), the design is to have no IP-level sharing. Having ifconfig leak information from non-global zones to the global zone might at least make it appear that some leakage is possible. Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Erik Nordmark wrote: Dan Price wrote: 'list -i' religiously follows this idiosyncratic approach ;-) We have a plan to add 'zoneadm info' or some such to display all the runtime attributes of running zones. Hopefully we'll get to that in the next 12 months or so. I'd request that you hold off on adding list -l until we design 'info'. The problem is that we have requests from the users of IP Instances (folks that have used the bits on opensolaris.org) to have a way of displaying which datalink names are assigned to which running zones. Could ifconfig be modified to report all network interfaces that are assigned to a zone? There is also another tool I hacked up earlier in the year called ifgrep that you could do ifgrep -z global or whatever with... Is it worth doing something more worthwhile with that? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
On Fri 03 Nov 2006 at 04:57PM, Erik Nordmark wrote: Dan Price wrote: 'list -i' religiously follows this idiosyncratic approach ;-) We have a plan to add 'zoneadm info' or some such to display all the runtime attributes of running zones. Hopefully we'll get to that in the next 12 months or so. I'd request that you hold off on adding list -l until we design 'info'. The problem is that we have requests from the users of IP Instances (folks that have used the bits on opensolaris.org) to have a way of displaying which datalink names are assigned to which running zones. If you start work on 'zonadm info' in 12 moths when would you expect to have it integrated? By get to it I mean have it finished -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
With regard to the third bullet, please see my concerns above about the introduction of list -l. I think this should be part of a general zone status/health facility or perhaps something that dladm(1M) can print about the link names and how their assignment zone-wise. Displaying the zone with dladm show-link seems a nice approach to me. Which project is planning on making GLDv3 zone aware? IP Instances isn't. Dunno. My comment was about the overall user experience, not about which project does what. -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Peter Memishian wrote: With regard to the third bullet, please see my concerns above about the introduction of list -l. I think this should be part of a general zone status/health facility or perhaps something that dladm(1M) can print about the link names and how their assignment zone-wise. Displaying the zone with dladm show-link seems a nice approach to me. Which project is planning on making GLDv3 zone aware? IP Instances isn't. Dunno. My comment was about the overall user experience, not about which project does what. Having layer N or subsystem X, which isn't otherwise aware of virtualization, be the place to look for how virtualization is set up seems quite odd to me. Thus if instead of using zonecfg to configure the boundary of the zone, things were spread across different commands (use dladm to assign link names to zones, use some zpool command to assign pools to zones, use zfs commands to assign zfs filesystems to zones), the I can see the point. But given that zonecfg is used to specify the boundary of the zone (which link names, which pools, which file systems), it seems very unnatural that in order to look at what assignment was made one would have to use separate commands (be they dladm/pooladm/zfs). It seems natural to be able to look at that using a zone* command. Note that zoneadm list is a bit idiosyncratic. It displays some things that are properties of the running state of the zone, which can not be found elsewhere (the zoneid and the state), but zoneadm list also displays a bunch of properties of the zones that are fixed (the uuid, brand, zonepath, etc) do not change as zoneadm manipulates the zone. 'list -i' religiously follows this idiosyncratic approach ;-) Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
On Fri 03 Nov 2006 at 09:42AM, Erik Nordmark wrote: Thus if instead of using zonecfg to configure the boundary of the zone, things were spread across different commands (use dladm to assign link names to zones, use some zpool command to assign pools to zones, use zfs commands to assign zfs filesystems to zones), the I can see the point. This is not correct. Several major commands let you alter the boundary of the zone at runtime, by design. The difference between these commands and zonecfg is that only zonecfg lets you do that persistently. But given that zonecfg is used to specify the boundary of the zone (which link names, which pools, which file systems), it seems very unnatural that in order to look at what assignment was made one would have to use separate commands (be they dladm/pooladm/zfs). It seems natural to be able to look at that using a zone* command. You can priocntl a zone, you can mount things into it, you can ifconfig things into it, you can use poolbind to alter its pool binding, etc. This is by design. Note that zoneadm list is a bit idiosyncratic. It displays some things that are properties of the running state of the zone, which can not be found elsewhere (the zoneid and the state), but zoneadm list also displays a bunch of properties of the zones that are fixed (the uuid, brand, zonepath, etc) do not change as zoneadm manipulates the zone. 'list -i' religiously follows this idiosyncratic approach ;-) We have a plan to add 'zoneadm info' or some such to display all the runtime attributes of running zones. Hopefully we'll get to that in the next 12 months or so. I'd request that you hold off on adding list -l until we design 'info'. It's up to the network experts to decide whether dladm -z or some such should exist to provide zone scoping. The design principal is: If 'zone' is an important property of the object being managed, then it should be considered for display, since administrators may need to be aware of that information, or may need an easy way to get it. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Dan Price wrote: 'list -i' religiously follows this idiosyncratic approach ;-) We have a plan to add 'zoneadm info' or some such to display all the runtime attributes of running zones. Hopefully we'll get to that in the next 12 months or so. I'd request that you hold off on adding list -l until we design 'info'. The problem is that we have requests from the users of IP Instances (folks that have used the bits on opensolaris.org) to have a way of displaying which datalink names are assigned to which running zones. If you start work on 'zonadm info' in 12 moths when would you expect to have it integrated? It's up to the network experts to decide whether dladm -z or some such should exist to provide zone scoping. The design principal is: If 'zone' is an important property of the object being managed, then it should be considered for display, since administrators may need to be aware of that information, or may need an easy way to get it. But it isn't dladm that manages the assignment of datalink names to the zones. It is configured in zonecfg and the implementation uses devfs/devnames. Thus dladm is not a natural place. Erik ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
With regard to the third bullet, please see my concerns above about the introduction of list -l. I think this should be part of a general zone status/health facility or perhaps something that dladm(1M) can print about the link names and how their assignment zone-wise. Displaying the zone with dladm show-link seems a nice approach to me. -- meem ___ zones-discuss mailing list zones-discuss@opensolaris.org
