Re: [zones-discuss] set physical=e1000g0
Thank you guys for your answers! Regarding this networking problem, I think I don't have time to investigate into it and I have decided to deploy on Solaris 10 instead. The changes in OpenSolaris is too overwhelming and even Sun cannot catch up with the documentation (for example, sparse zones is no supported in OpenSolaris but the OpenSolaris documentation advises using the inherit-pkg-dir). I'd prefer to wait for OpenSolaris features to be incorporated into the next version of Solaris 11. With respect to the issue you noted, it's not clear with the details you provided whether you will see a difference with Solaris 10. You need to provide more details of what you're trying to do. For example if you have only one physical interface, then creating an exclusive-IP zone is impossible without using OpenSolaris and its virtual NIC (VNIC) capability. Yes, at this time sparse-root zones are not supported in OpenSolaris however there is work underway on how best to support them in the future or perhaps better stated, how best to support the attributes of sparse-root zones that make them useful. The OpenSolaris documentatin advises about using inherit-pkg-dir because it reflects the older model but that doesn't mean the whole-root model isn't supported either. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] NTP client in non-global zone
What is best practice here?
Do not run {x}ntpd in the zones.
Actually there is a use-case for doing so - given that it's a
network-facing appliction, one might want to run xntpd in a non-global
zone for isolation reasons.
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] cannot negotiate hypervisor
I just jumpstarted a T2000 twice. Once with 118833-33 and once with 120011-14. The first time there was no problems with the November 2006 118833-33 but when I re-jumpstarted it with the 120011-14 8-07 release I ended up with multiple messages stating cannot negotiate hypervisor. I checked the internet for some message like that and found BUG 6459302 which stated State 11-Closed:Not Reproducible (Closed) Hate to say this but I just reproduced it. Does anyone know of a workaround or a fix for it? I believe you're confusing Zones (an OS-level virtualization technology) with Logical Domains (which is hypervisor-based) - the latter technology is what the above bug concerns itself with. A more appropriate mailing list would be [EMAIL PROTECTED] dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] netmask warning, misconfiguration
zoneadm: zone 'int-sagent-1-z1': WARNING: bge0:1: no matching subnet found in netmasks(4) for 172.20.46.188; using default of 255.255.0.0. but my /etc/netmasks (on both the global and local zone) looks good: What does the netmasks entry in /etc/nsswitch.conf say? A common issue is that a user changes their local /etc/netmasks file but their the switch says to use something like nis. (I also tried 172.20.0.0 on the theory that maybe it wanted me to set the netmask for the entire Class B, but no dice.) Actually, that's exactly what you should be using in your local /etc/netmasks entry. Although I do suggest that specifying the prefix length (such as /24) via zonecfg(1M) is the best solution. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] pidentd
Oh. I though that pidentd was supposed to resolve UIDs locally. That's one of the features of the protocol; it provides here's who *I* think the user is information back to the requester. Of course, that's why I thought IDENT was a fairly bogus mechanism since you're asking the remote system to report on its own users and someone who controls that machine can report whatever their heart desires. Or has the mechanism changed over the years? Has there been any work in the IETF, for example, to try and develop something more useful than identd? dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: nevada zone with NAT and NFS
At least some of the servers that I can't access are using NFSv3 It has been my experience that NFSv4 on Solaris 10 and NFSv3 on other hosts, including NetApp filers, cause all sorts of problems. Either you get No Directory or the directory/files are owned by nobody. I don't know about NetApp's NFS but the latter issue can usually be resolved by setting NFSMAPID_DOMAIN on the Solaris side to tell nfsmapid(1M) what NFSv4 domain to use. You'll want to restart svc:/network/nfs/mapid after making this change. dsc ___ 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
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] New zone, sysidtool:net isn't starting
FYI, you can also use create -b (blank) so you don't have to run remove-pkg-dir 4 times. Actually, the documented way to create a whole-root zone *is* to remove the default inherit-pkg-dir resources. The reason for this is create -b says to use a blank template - namely, no properties set and no resources defined. It doesn't mean create a whole-root zone and in the future, an empty template might not be the same as a whole-root zone. During the development of the project I suggested we introduce something like create -w or create -t SUNWwhole ;-) and perhaps it's time to consider that again. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [Fwd: Re: [zones-discuss] Re: zonemgr -s syntax]
My desire is to have zones be part of the core in Nevada, possibly by folding them right into SUNWcsu/SUNWcsr. There's also a related CR open 6421453 RFE: SUNWCzone should be available in SUNWCmreq and above Fixing is involves an examination of SUNWzoneu's dependencies and seeing what else needs to move along with the zone packages or what can be refactored in a different way. 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
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
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
[zones-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Erik, Here are my belated comments on the IP Instances design. There are two documents which describe the design si-interfaces - a high-level design focusing on the problem the project solves, and what the user-visible changes are A general comment that in both documents page numbers seem to be missing. Figures 1 and 2 - I think the pictures are a little misleading the second picture displays an example of two applications (web servers?) both binding to INADDR_ANY on port 80. Of course, that's also a very viable example for the current zones model. Perhaps a better example might be one of those applications designated as Internet facing and another might be Intranet-facing or Internal. Page 6, Section 4 - I'm not sure if this is the proper place for a discussion on security or if it warrants a separate section, but I think the document should discuss the security implications of a zone using a shared stack versus an exclusive stack. For example, I think including the table you had sent in private email some time ago which documented the various attack vectors and how each type of zone addresses the type of attack would be helpful in understanding the trade-offs. (I know some of this is headed to be discussed in Section 9 of the second document but it seems at least some of the discussion belongs here as well.) Page 6, Section 5 - In the second paragraph, you mention there are no planned layer two changes. Does that mean for the initial design that there will be no filtering done at that layer? Again, perhaps this merits discussion in a separate Security section but it's important to understand what sorts of capabilities a privileged user in an exclusive stack zone has versus one in a zone using the shared stack. Page 7, Section 6 - In #4, leveraging zonename(1) in this way does seem strange. I know we discussed at one time a command to retrieve and interpret the values of ZONE_ATTR_* kernel attributes although in this particular case, it seems the only one that makes sense from inside the zone itself is whether this zone is tied to an exclusive stack. What about using /sbin/netstrategy and smf_netstrategy() in /lib/svc/share/smf_include.sh for this purpose? Page 7, Section 7 - Given the recent discussion with a customer, would it make sense to make it clear here that there is a *single* shared IP and the project does not allow for islands of shared IP instances? Page 8, Section 9 - When does the enforcement of only allowing a physical property for exclusive IP zones? Does it occur when one tries to complete the addition of a net resource by specifying end subcommand? Or does it occur when verify is performed on the whole configuration (either the explicit command or the implicit verification that takes place prior to commit?) In the example given for the shared IP zone, I would specify add the /24 prefix length to the address parameter (it's not required but definitely encourage it) and also the missing end subcommand. In the example given for the exclusive IP zone, there is also a missing end subcommand. Page 9, Section 10 - BrandZ added their BRAND column after the existing PATH column but you're introducing it before. It seems the IP TYPE should follow both PATH and BRAND. Also, updating the output for first two list examples to account for the merge with BrandZ would be helpful. In the third example, the command listed is list -i but earlier -l is defined for this purpose. With respect to list -l, I'm not sure if this really belongs in zoneadm(1M) or somewhere else. In some ways, I'd rather see it as a new option to dladm(1M) instead. Will the list of link names printed be the ones actually registered with the kernel though zone_add_ifname() or the subset of those link names actually plumbed by the zone with the exclusive stack? I assume the former but please verify that. In this respect, it seems that list -l is printing one of that several pieces of zone runtime state which we don't currently print through zoneadm(1M) or any other command. The zones team has discussed in the past introducing a more general zoneadm status or zoneadm info facility but that's not yet designed. Another alternative is to begin supporting a list -o format in zoneadm(1M) and allow the link names to be a supported type there. Finally, in the case where multiple net resources have been specified with an exclusive IP zone, are the link names separated by whitespace? Page 9, Section 11 - As I mentioned earlier, zonename(1) seems the wrong interface for obtaining this information. What about using /sbin/netstrategy and smf_netstrategy()? Page 9, Section 12 - There should be some discussion of the packaging changes somewhere in one or both of the documents. In the particular case of IP Filter, is the proposal to move all of the contents of SUNWipfr into a non-hollow package? Page 15, Section 14 - This is more of a code review question but are the additional privileges
[zones-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Erik, One additional comment I meant to include is that I think it would be useful to add a paragraph on what is possible today with the current stack in terms of sharing a link versus what will be possible with IP instances (using separate physical NICs or VLANs) versus what will be possible once VNIC support is introduced. Once VNICs are available, there will be a lot more flexibility but until then, the use of IP instances will be limited by the physical hardware or the use of VLANs. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone management and security
I propose that zlogin be split into two different programs, one for console access and one for running programs and/or shell. A simple way to do this (and would be backward compatible) would be to create a hard link to zlogin, say 'zconsole' that when it is executed the program can test arg0 and automatically apply the -C functionality if it is called zconsole. This would allow better separation of duties and allow two different profiles in exec_attr to differentiate what zone administrators can do. There have been some discussion of using SMF authorizations with zones to provide this level of control. One CR of interest is 4963290 RFE: implement flexible zone administration that doesn't require uid=0 dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] traceroute to a zone creates extra hops
Fernando, I have two systems named fdo5 and fdoclt4. All the NICs in both systems are connected to the same switch. fdoclt4 has 3 zones in it. When I traceroute from fdo5 to any of the zones, the route has an extra hop (always 18.1.1.142). shouldn't this example resolve to 18.1.1.145 itself? Is there any way to correct problem? I believe you're seeing a side effect of the following bug 6426172 ICMP Destination unreachable from global zone instead non-global This issue is being resolved and there should be a fix in an upcoming Nevada build. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: core dump during zone install
libc.so.1`realfree+0x68(2a3f0, 871, 93ac8, 3a4d8, 0, d) libc.so.1`_free_unlocked+0xb0(ff1efa54, 0, 932f4, ff1efad4, ff1e8284, 2e460) libc.so.1`free+0x24(2e460, 1084, 93334, 0, ff1e8284, 1000) libcurses.so.1`delwin+0x80(0, 2df58, 2c068, fef03994, 0, 0) libcurses.so.1`delscreen+0x5c(29748, ff1f09b0, 0, 9, 0, 0) libcurses.so.1`initscr32+0x48(ff1ecc00, 1, ff1ecbc0, ff1efad4, 0, feefb240) sysidtty`start_curses+0x38(0, 0, 0, fef35aa8, 188b0, fef37124) sysidtty`form_create+0x24(fef20194, fef201b8, ff334104, 2, 5, 2) sysidtty`form_common+0x10(fef20194, fef201b8, ff334104, 2, fef1aa48, f000) sysidtty`do_get_password+0xb0(ff334104, 4, ffbfee98, 1c24c, ff3c5f94, fef35aa8) . . . You may be running into 6447019 sysident dumps core in _sply As for sysidcfg, I don't have one in the newly creted zones I fill all the info by hand on zlogin console Can you provide details on what your answers are for some of these questions? For example, which naming service service did you choose? Any particular locale? dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] improved zones/RM integration
Could we somehow work the zone name into this? It would be nice for
e.g. poolstat(1) observability. Otherwise the user experience is going
to be all about trying to work out what 'SUNWzone34' maps to, which
seems poor.
We need to have the name begin with SUNW or we could have collisions with
existing pools. I supposed instead of zone{id}, it could be SUNW{zonename}
although you lose the visibility that the pool is associated with a zone.
Maybe SUNWzone_{zonename}?
Or perhaps SUNWtemp_{zonename}?
dsc
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zones, upgrades, and vxvm
Christine, LU doesn't work for boxes with zones yet, afaik. zonepath on vxvm volumes won't work for upgrade from 3/05 (granted, upgrade from 3/05 with zones isn't supported anyway). I have no reason to think this would work with 1/06 Just to clarify that upgrade from 3/05 when zones are present is supported for standard upgrade. It's the LU piece that is under development. For VxVM and other file systems whose metadata isn't known from within the miniroot, upgrading a system with zones on such file systems will be an issue until that support is made available. dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
