Re: [zones-discuss] Bridging at Zones.
On 8/25/2012 1:49 PM, Daniel Requena wrote: James, Thank you for you answer. I had never though about running more than one instance of Trill on the same machine... simnet links are new to me... a quick search on Google didn't give me much. Do you have any links about it? Try searching dladm simnet. You should get a bunch of hits, including this fairly practical one: http://www.c0t0d0s0.org/archives/7424-Simulating-the-cloud-a-practical-example..html He was simulating routers, but the process is the same. (And, in fact, simnet links were added during our bridging/TRILL project in order to test bridging and TRILL.) On that site, you'll also find links to a separate driver you can download and install called hxbt: http://www.c0t0d0s0.org/archives/6625-Less-known-Solaris-features-hxbt-or-WAN-emulation.html It looks like a variant of the hitbox driver we used to use at Sun for testing WAN-related behavior. There is no problem in running this simulation on the global zone... but the objective is to simulate a regular network running only regular bridges and then I would substitute bridges for Trill links (one by one). Can you see any problem doing that without virtualization? No problem. You just need a bunch of links to bridge together, and then you can set up arbitrary instances of regular bridges (with or without STP) and TRILL bridges. Simnet links are just point-to-point, so they're perhaps not too interesting if you're deeply concerned about details such as Appointed Forwarder operation or DR election, at least on those links, but you can use one or two real external Ethernet interfaces to probe those behaviors as well. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can not ping between zones and internal network
carlopmart wrote: On 09/07/2011 10:08 PM, Hung-Sheng Tsao (Lao Tsao 老曹) Ph.D. wrote: may be you need a defrouter I have setup default router using route (-p) command on zone system. Yes; that much was obvious from the netstat -nr output that you'd originally included. I don't know what that previous poster was on about. Do you refer to setup defroter under xml config zone's file?? maybe, but Can I do this using exclude as a ip-type option?? And I see something strange. If I put vnic on zone system in promiscous mode (using snoop), all works ok. Strange?? That sounds like a system bug. For some reason, the Ethernet interface is not properly receiving packets for the second MAC address that you've configured. That's something that should just be automatic, and the apparent fact that it's not doing that is a bug. Since this zone and the global zone are on the same subnet, one possible option here is to go with shared IP stack rather than exclusive. Or, as another possible work-around, you could put that interface into promiscuous mode at a pretty low level by configuring bridging and adding the global zone's interface to a bridge. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ERROR: the zonepath must be a ZFS dataset.
Hung-Sheng Tsao (Lao Tsao ??) Ph.D. wrote: current s10 zone user will not be unhappy when move to s11 1)there is no sparse zone in s11 (yet) 2)there is no v2v from s10 zone to s11 zone (yet) 3)zfs dataset requirement 4)people just does not like changes Given the changes in packaging and patching between S10 and S11 and (last I checked) lack of a direct upgrade path from one to the other, I'd be really surprised if the above issues were all that significant. In particular, the ZFS-based upgrade mechanism is substantially easier to use and works much better than what we had for S10. Forcing users to put zones on distinct ZFS datasets seems to me like a trivial matter that ends up simplifying and providing a lot of benefit. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Future directions of Zones?
Orvar Korvar wrote: There are speculations that future Microsoft Windows OS, will only be a kernel. And each program will be installed in an individual VM created for that program. Hence, the kernel would be minimalistic and not bloated. Can not something similar be done to Solaris? For instance, small Kernel, and everything installed in separate zones? This requires that Solaris Zones can be very minimilastic, they read the system files from the Kernel install, and write in it's own filesystem. Given that (in the current design) all non-global zones share a single system kernel, and VMs are definitely not in use, I don't see how moving functionality out into non-global zones will change kernel bloat one way or the other. Zones avoid the overhead of traditional VMs by not being actual VMs. Perhaps instead of Zones, you actually mean xVM/Xen. If so, then, yes, that might be possible. It's merely a matter of software (much would have to be written to proxy operations across VMs) and performance (just about all message-passing schemes I've seen were slower than non-message-based equivalents). Although possible, it's unclear to me whether any of that would be desirable. So, what problem is it you're solving here? -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] question about nfs_global_client_only /etc/system flag
Paul Fronberg wrote: What does nfs_global_client_only do? You don't want to use it. ;-} It was a hack that I added some years ago to allow non-global zones to 'borrow' the global zone's credentials when acting as an NFS client. It's intended to work *only* in a jumpstart environment, and nowhere else. If you use it in a running system, you're quite on your own. We've had to set this flag to get a kernel module (issuing a VOP_GETATTR) to work properly when accessing an NFS mounted partition in a non-global zone. The kernel modure appears to be running in the global zone and is issuing a cross-zone request to an NFS mount in a non-global zone. It sounds to me like your kernel module may need to be rewritten to understand zones. I don't think I can provide help with that, but perhaps Oracle can. I haven't been able to find much documentation about this. See section 5.2 of this document: http://arc.opensolaris.org/caselog/PSARC/2005/474/inception.materials/scratchzone-design.pdf It intentionally has no system documentation, because it's intended for internal use and thus may change behavior or disappear without warning -- even in a patch. Only things that are actually intended for use by users, administrators, or third party developers are included in the system documentation. The paperwork required to use that sort of interface within Sun: http://arc.opensolaris.org/caselog/PSARC/2005/474/final.materials/contract-01.txt -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
On 12/27/10 05:34, Orvar Korvar wrote: Ok, so virtual machines for x86 (VirtualBox, VMware, etc) does not necessarily give you additional security. Security by virtualization is a failure: http://www.serverwatch.com/tutorials/article.php/3905096/Use-Virtual-8086-Mode-to-Secure-Virtual-Servers.htm I wonder, how does the Solaris Zone VM model compare to these? Can you use the same type of exploit on Zones? Are Zones vulnerable to what he talks of, are Zones more secure? Or, are all VMs insecure, no matter what model? It's a completely different model. It doesn't actually run an OS instance on top of another instance, and Virtual 8086 Mode has nothing to do with it at all. Instead, you can think of zones as being like an extended UID plus chroot and networking features. In the same way that UIDs and PIDs keep processes separate, zone IDs keep the per zone processes and data separate. It's still a single instance of a kernel. Again, it's not multiple OSes run one atop another (as you see with VirtualBox, VMware, Xen, et cetera). All of the processes still run on the same system. (And that's why you can't have your zones at different kernel patch levels.) It's at least as secure as allowing multiple users in chroot jails on the same system, and actually more so, because of the way Least Privilege is used to prevent escalation. Even if a user gets ahold of a setuid binary, he can only make himself UID 0 inside the same zone, and he still can't touch the kernel. As for that article, I'm sure Oracle will have some sort of answer, but I'd just say this: all systems have bugs. Whether those bugs allow exploits or not -- and if so, what sorts of exploits -- is extremely difficult to determine. So, you have to keep the software up to date and make sure you're running on a platform that's actively maintained. If you're looking for a magic bullet, the answers are simple. For a single system, turn it off. For a network, you can always run with scissors. BTW, My original plan does not work. I have SunRay clients, which means I can not shutdown the global zone's NIC - because then the SunRay will stop function. I must somehow separate local zones traffic, from the global zone's traffic. I have no clue about SunRay (and I dunno who might), but I think the simplest configuration by far is to set up the shared IP stack model for your zones and assign each zone an address in the same subnet as the global zone. Implement any security you need at a higher level -- using IPsec, SSL, or other such protocols. Don't forget that with security, simple is usually better. Complex answers tend to be the ones that are hard to configure properly and thus are often done wrong. But good luck. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Security through virtualization is a failure:
On 12/27/10 08:15, Orvar Korvar wrote: Ok, thanks. So, Solaris zones are probably not susceptible to these kind of attacks, it seems. But I was considering running VirtualBox in each local zone and surf from the VirtualBox virtual machines. So, in that case, then you can exploit that attack in each local zone. But you could not access the other local zones, because of underlying Zone model? Unless there's a kernel module associated with VirtualBox, a user who breaks out of VirtualBox will still be in a process running in the non-global zone. Kernel modules are global to the system, and are installed (and read) only in the global zone. If one of those is corrupted, then all bets are off. Regarding my SunRay setup and Global zone. I think I just should do it simple, just like this picture: Figure 15-1. Zone 1 will be the global zone. And the rest of the zones, will be VirtualBox zones. Good so? http://docs.sun.com/app/docs/doc/821-1458/gdytf?a=view That's not quite what I'd call simple, but I guess it's a matter of taste. That uses VNICs and exclusive IP stack zones, which wasn't what I was describing in my previous message. Doing it that way means that you have to grant privileges to the zones such that they can manage the interfaces they have, and then you may need to set up security on top of that to keep them from managing them in ways you don't want, such as configuring the wrong IP address. Shared IP stack zones are simpler, at least to me, because the non-global zones are much more constrained in what they can do. For what it's worth, the global zone is usually considered separate from the rest of the zones. Including it as part of a picture like that only (in my opinion) clouds things rather than clarifies. If I were concerned about security at this level, I'd keep the global zone only on a private network. (But I'm usually not concerned about things like this. Either we're friends just sharing a box, or we're not. If we're not, then I'm going to set up secure protocols to talk; I'm not going to trust my data to any sort of partitioning scheme -- whether subnets, VLANs, VNICs or whatever.) -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] SunOS Hostname 5.10 Generic_138888-05 sun4u sparc SUNW, Sun-Fire-V890 supports IPv6
Sanjay Akula wrote: Hello Users, SunOS Hostname 5.10 Generic_13-05 sun4u sparc SUNW,Sun-Fire-V890 does supports IPv6. Hardware doesn't matter. Yes, Solaris 10 supports IPv6. IPv6 support was added many years ago -- Solaris 8, if I recall correctly. (You might try using networking-discuss instead of zones-discuss, since this is a networking question. Or maybe one of the S10 groups, like BigAdmin.) -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can I use 32-bits apps in zone on x64 OSOL?
Anton Pomozov wrote: Seapine TestTrack License Server compiled for 32-bit only. Or I need use xVM with PV 32-bit osol? 32-bit applications work fine on x64, whether inside a zone or not. Each process on x64 (and SPARC) can be either 32-bit or 64-bit and the system adapts as needed. The only question is whether this product has kernel modules. If it does, then you can't load 32-bit kernel modules into a 64-bit kernel (for much the same reason that you can't use 32-bit libraries with a 64-bit program). -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Possible to use zones for hardening? Security?
Orvar Korvar wrote: Ok, so it is impossible to shutdown internet connection to the global zone and surf only from the local zones. If I want to surf from the local zones, the global zone's NIC must be activated. I suspect a hacker will attack the global zone, instead of the local zone that I surf from. There's no need to assign any addresses to the global zone. I'm pretty sure there are others (Dan McDonald, probably) who have experimented with the sort of configuration you're describing. Are there any other ways to increase security instead of my original plan (shutting down the global zone and surf from local zones)? I am afraid the global zone will be attacked... If you set up the global zone having no interfaces (just lo0), and set up the non-global zones using the set ip-type=exclusive mechanism, the non-global zones will have networking that's completely independent of the global zone. You can't shut down the global zone, but you certainly can configure it so that it doesn't have any available networking interfaces. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone with virtual and physical networking or per UID/GID routing?
Hernan F wrote: The other option would be to use a Zone with physical networking, but zones won't let me mix physical and virtual networking (bridge one interface to the local LAN and use the physical to the Internet), or it didn't when I tried a few months ago. Is my only option to add a third NIC to the machine and have local traffic go through it? It would work but it's not pretty. What OpenSolaris version are you running? Is it the latest available? Have you tried using a vnic in a non-global zone with an exclusive IP stack instance? -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ZFS ARC cache issue
On 06/06/10 18:58, Brad Diggs wrote: Apps that attempt to acquire a large amount of data on startup can fail to start properly if ZFS does not free up the memory fast enough. I have observed this with Directory Server. Fast enough? The model I was expecting here was a bit more synchronous than that -- someone asks for memory, the memory subsystem asks ZFS to release some, and it does, which allows the request to be satisfied. I'd be interesting to know how time gets involved here at all. If it does, then I think that would make the ZFS ARC should use all of memory by default scheme fairly problematic, as it would just intermittently shoot down large processes. Or just more fundamentally: needing to tune this at all seems a bit like a bug to me. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ZFS ARC cache issue
Petr Benes wrote: add to /etc/system something like (value depends on your needs) * limit greedy ZFS to 4 GiB set zfs:zfs_arc_max = 4294967296 And yes, this has nothing to do with zones :-). That leaves unanswered the underlying question: why do you need to do this at all? Isn't the ZFS ARC supposed to release memory when the system is under pressure? Is that mechanism not working well in some cases ... ? -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ZFS ARC cache issue
Petr Benes wrote: That leaves unanswered the underlying question: why do you need to do this at all? Isn't the ZFS ARC supposed to release memory when the system is under pressure? Is that mechanism not working well in some cases ... ? http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017 ... Even if the ZFS ARC subsequently frees memory, the kernel cage does not shrink. It cannot shrink, because pages from the ZFS ARC were interspersed with other kernel pages, so the free space in the physical address range of the cage is fragmented when the ZFS pages are released. The remaining kernel pages cannot be moved to compress the cage, as kernel memory inside the cage is not relocatable. ... Sure ... but that refers specifically to DR-related issues, and that's not what the original poster complained about. His original message said that he was having trouble with a large application (Oracle Fusion) running on a system using ZFS. Does Fusion really need contiguous kernel memory (why?) or is there something else going on here? -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ZFS ARC cache issue
Ketan wrote: Let me know what command you want me to run on it for kstat /truss as per kstat zfs:0:zrcstats:size the size is approximately 40G Since there are a bunch of ways that the problem that Jason King was describing could manifest, I think the only way to do this would be to get the system in a state where Fusion consistently fails to run, and then start it up with: truss -fo /tmp/fusion.out fusion-command-and-args... You'd then have to grovel through the /tmp/fusion.out and find out what leads up to the failure and see if there's anything suspicious there. Since Fusion is Oracle and OpenSolaris and ZFS are Oracle, maybe there's another possibility. This could be one of those cases where that hoped-for synergy might kick in. ;-} -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?
On 05/28/10 04:57, Frank Batschulat (Home) wrote:
On Fri, 28 May 2010 10:43:22 +0200, eiji@oracle.com wrote:
Hi Frank,
getzoneid() can return a correct value even if it's called in a taskq thread
(kernel context) and/or in an interrupt handler (interrupt context)?
I suppose so, look its not doing anything earth shattering:
2496 getzoneid(void)
2497 {
2498 return (curproc-p_zone-zone_id);
2499 }
no locking involved, no allocations done, nothing considered
harmfull in an interrupt context or taskq thread.
only question is to what proc your taskq/interrupt thread will bind to.
It sounds like we might need more information about what the original
poster is attempting to do.
Interrupts themselves aren't features of non-global zones, so they're
not normally attributed to any particular zone. In theory, if there
were devices dedicated to individual zones, you could use the device's
state structure to find the zoneid associated.
If you just use getzoneid() in that context, you'll get the zoneid of
the zone whose thread happens to be pinned down by the interrupt. In
other words, it's an arbitrary and almost certainly wrong answer.
I think something's amiss if you're asking about zoneid outside the
context of direct system call processing. The answers there vary quite
a bit. For example, with STREAMS, the correct answer is to fetch the
cred_t attached to the dblk_t, and get the zoneid from the cred_t.
It's not unusual at all for interrupts and taskqs to do work on behalf
of many different zones, and for them to need to track this information
separately.
--
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Nero Linux in zones
On 4/11/2010 8:11 AM, Joerg Schilling wrote: valrh...@gmail.com valrh...@gmail.com wrote: So I reiterate my question: has anyone gotten Nero Linux to run in a Zone, and if so, what's the best way to set it up? Thanks! Nero does not work on Solaris because Nero does not support Solaris. Did you try to ask Udo Eberlein or Richard Lesser? But I don't have the impression that this discussion will bring us enywhere... Just try to describe _why_ you believe that you need Nero. Assuming that his original problem is that mkisofs and cdrecord are just too hard to use -- in comparison to the GUI-based features on other systems -- I have to agree with the previous poster. It's an important gap, even if the features in the tools we have are objectively better, and even if there are defects in the GUIs that others use. I just wouldn't focus too much on Nero. I think that's the wrong target. Macs are easier to use than that, and provide an object lesson in how it's possible to make UNIX highly usable by the masses. It might not be the fun part of development (at least I don't view it that way ;-}), but providing good UIs goes a long way to making users productive without forcing them to become grad students in each technical area. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zonecfg export Segmentation Fault (core dumped) with a modified crle path
On 4/2/2010 6:36 PM, Dr Lou wrote:
James, thank you for that thought - yes, I was headed to this same test:
A word first, on the environment: we have several 3rd-party (SunFreeware) and
custom-built libs, mostly in /usr/local/lib. This occasionally leads to what
I like to think of as 'white-knuckle computing...
Yeah, I can definitely understand that. I now work for a developer of
software that runs on Solaris (as well as other systems), and the
intersection between Solaris practices, our practices, and those of
other vendors with which we must coexist is fraught with peril.
With crle default path set to: Default Library Path (ELF): /lib:/usr/lib
# ldd /usr/sbin/zonecfg
- all dependencies are resolved, but ALL in /usr/lib, NONE in
/usr/local/lib
On the other hand, with Default Library Path (ELF):
/usr/local/lib:/lib:/usr/lib
# ldd /usr/sbin/zonecfg
libxml2.so.2 = /usr/local/lib/libxml2.so.2
libxml2.so.2 (SUNW_1.4) = (version not found)
…
libxml2.so.2 (SUNW_1.3) = (version not found)
...
libxml2.so.2 (SUNW_1.3) = (version not found)
(occurs twice)
Don't do that. Pulling libxml2 from somewhere else is going to be
highly toxic -- not just to zonecfg, but to large parts of the system
that now rely on XML, such as SMF. I doubt the system can boot that way.
ldd /usr/local/lib/libxml2.so shows that all dependencies are present - and
resolved - but many of them are the libs in /usr/local. This is no doubt the
source of the 'version not found' issue.
Wondering what is best solution?
1) Leave crle with default setting,
2) create a 'custom' crl(environment) for execution of selected binaries?
Here are some solutions, in roughly descending order of what I think is
goodness:
1. Use $ORIGIN when building the binaries to begin with. To do this,
you'll normally have something like -L/usr/local/lib as part of
the link process. Use instead '-R$ORIGIN/../lib' -L/usr/local/lib.
The $ORIGIN token expands to the invocation directory
(/usr/local/bin) and will work even if the software is installed in
some other directory. This is by far the best solution, and works
on many other systems (though not, I think, AIX).
2. Use a tool to fix the run paths in the binaries themselves so they
find the right library directories on their own. See:
http://blogs.sun.com/ali/entry/changing_elf_runpaths
3. Create a wrapper script (or special launcher program) that sets
LD_LIBRARY_PATH_{32,64} before running the binaries that need it.
This is the approach taken by most independent software vendors.
It's just plain horrible. The user quickly gets swamped in a sea
of conflicting paths. But this is life.
4. Have the user hack LD_LIBRARY_PATH into his environment. This is
what some vendors do. It's even worse. It means that the user is
even less likely to create a good set of paths.
Using crle makes some sense if the path you're adding is at the *END* of
the system paths -- that is, if you have some add-on libraries that do
not conflict with any system library -- and is roughly equivalent to and
slightly better then (4), but it's bad news if you try to override.
You could create a custom LD_CONFIG file, but then you're essentially
doing the same thing as LD_LIBRARY_PATH, and you might as well skip the
middleman.
--
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] zonecfg export Segmentation Fault (core dumped) with a modified crle path
Dr Lou wrote: - However, with this crle configuration: # crle -c /var/ld/ld.config -l /usr/local/lib:/lib:/usr/lib # zonecfg -z zone-pg84 export segfaults: Segmentation Fault (core dumped) What does ldd /usr/sbin/zonecfg say? -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] networking
Dombrowski, Neil wrote: My next question (which I think may have been partially answered already); it's obvious now that the global zone inherits the ngzones (non-global zones) routing information; is that a two-way street? If zone1 has a default route using 10.10.10.1 as it's gateway, and in the global zone I use a different router on the same network (10.10.10.5) as my default gateway, will that affect/interrupt zone1's routing table? I'll be experimenting a bit with this on my opensolaris box; hopefully it will match what solaris will do on our sparc servers. A shared-stack zone cannot modify the kernel's forwarding table. It inherits -- read-only -- the forwarding table that is established by the global zone. Actually, there's no real inheritance going on here. There's just one forwarding table. The non-global zone is permitted to view it, and all of its packets are delivered according to it, but only the global zone can modify it. The only special thing going on with Solaris Zones is that when the non-global zone uses the table, it ignores any entries that it's not permitted to use -- where permitted is defined as for the output physical interface identified by the route, there exists at least one IP address [logical interface] configured and marked 'up' for that zone. If you establish two default routes in the global zone, then the system will treat them as equivalent. Packets from the global zone may be sent to either router without distinction. That might not be what you want. In general, if you want isolation, then you want the exclusive IP stack zone model. The shared stack model was designed for a BSD-Jails-like environment, where you're consolidating numerous servers that were previously configured side-by-side on a single network. Shared doesn't work as well when the zones are mutually hostile. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Installing a specific dev release into a zone?
Tristan Ball wrote: I looked into this a little when I hit it, and basically it's a limitation of the opensolaris pkg commands. I'm going for memory here, but I think the list function returns only the lastest version from the repository, and refuses to find anything else regardless of arguments, while the search and install functions will find any version. Even if you could somehow specify the version desired, it's unclear to me (at least) how this could ever work reliably. Non-global zones don't have their own instance of the kernel; they share with the global zone. And there are _many_ consolidation private (read: undocumented and potentially changing rapidly) interfaces shared between the kernel and the user space libraries and applications delivered from ON. The only thing I know that's guaranteed to work is a matched set -- one build of ON's user-level and kernel-level components. Mixing them from different builds usually leads to tears, with or without Zones. Zones aren't the same thing as VMs. They're much lighter weight (a non-global zone is essentially the same as a UID or project in terms of kernel handling; it's not a layer in any sense), but there's a price to be paid in feature set for that lightness. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zlogin -C zone
dick hoogendijk wrote: I get very very frustrated. I installed a zone on my opensolaris b131 and all went well. The zone boots OK. Then it's time for the zlogin -C but no matter what, I always seem to choose the wrong keyboard and so all I get pressing F2 is OQ. This is on opensolaris-b131 That sounds like the usual sorts of problems that occur when the transport mechanism breaks up characters and causes delays that prevent the function key recognition code from properly decoding the sequence. Try Esc-2 instead of F2. (Robust function key logic usually doesn't misbehave like that, but not all logic is robust ...) -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones on shared storage - a warning
Frank Batschulat (Home) wrote: This just can't be an accident, there must be some coincidence and thus there's a good chance that these CHKSUM errors must have a common source, either in ZFS or in NFS ? One possible cause would be a lack of substantial exercise. The man page says: A regular file. The use of files as a backing store is strongly discouraged. It is designed primarily for experimental purposes, as the fault tolerance of a file is only as good as the file system of which it is a part. A file must be specified by a full path. Could it be that discouraged and experimental mean not tested as thoroughly as you might like, and certainly not a good idea in any sort of production environment? It sounds like a bug, sure, but the fix might be to remove the option. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Defaultrouter problem?
Stefano Pini wrote: The steps above configure perfectly all the 9 NGZ and they run well. The problem is on the Global Zone: the clients that use GZ to manage the system get diconnected regularly or sometimes can't connect! When that happens, trying traceroute to clients from GZ console seems that it uses a bad defrouter, the one on another vlan, not the right one!!! (for example 10.1.117.254 on bge17000 insted of 10.1.115.254 on bge15000) When you're in the global zone, all of those interfaces, subnets and default routes are the same. There's no special one reserved only for the global zone's use. The global zone can (and will!) use any of them. If they're not actually usable by the global zone, then you've got a problem. Possible solutions include: - Use exclusive stack zones instead. If you do that, though, you won't be able to have groups of zones sharing a single interface. (You could do something like this with VNICs, but not on S10, as S10 doesn't have those.) - Direct the traffic originating from the global zone using IP Filter. You could filter based on source address and use the on keyword to direct that traffic to go out via a particular interface, just as your desired default route would do (if it worked). - Stop using default routes, and use network specific routes. If the networks that the global zone must reach are distinct from the ones that the non-global zones must reach, then you should be able to come up with a set of routes that will direct traffic appropriately based on remote address. (A routing protocol may help.) - Modify your default routers so that they know how to deal with traffic from the global zone. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
Darren Reed wrote: Guys, In most parts of the source code, the zoneid is unsigned, except for where we use ALL_ZONES. Then in some places, we assign or expect -1 to be the zoneid, for example in what psh prints and expects to see. It would seem that we want the zoneid to be unsigned except for when its value is -1. This seems... like it could lead to confusion or other bad things. It looks to me like it's neither signed nor unsigned, but rather an opaque type. It supports only equality tests, not general arithmetic ones, so signedness doesn't seem to come into it. What kind of confusion are you expecting? -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
Darren Reed wrote: James Carlson wrote: What kind of confusion are you expecting? If it is an opaque type, then how does it get printed? You have to use one of the look-up functions to convert it to a string for printing. Zones are named, not numbered, even in the kernel. This was a key architectural decision made by (I think) Andy Tucker back when Kevlar was being designed. I wanted zoneids to be like UIDs, GIDs, and other UNIX IDs -- used as small integers everywhere, and converted to names when necessary by use of name services. Andy and the other kernel folks disagreed, and felt that strings were better, and integers would be allocated on the fly (non-permanently) and never used as zone identifiers, except in performance-sensitive (and entirely internal) contexts. As an unsigned integer for all values, except -1, or as a signed integer? I still think it's properly neither. Users can't reasonably do anything with those ephemeral numbers, so printing them (or using them in user interfaces) would be a mistake. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
Darren Reed wrote: On 18/09/09 10:44 AM, James Carlson wrote: Darren Reed wrote: As an unsigned integer for all values, except -1, or as a signed integer? I still think it's properly neither. Users can't reasonably do anything with those ephemeral numbers, so printing them (or using them in user interfaces) would be a mistake. Do a man snoop and search for the word zone. My argument wasn't that there were zero bugs in the OS. That keyword seems to me to be pretty clearly a defect in snoop. (And apparently a recent one; less than a year old.) It was that the zone IDs are inherently ephemeral, and were designed to be that way. They're not intended as any sort of administrative interface. The kernel assigns them arbitrarily as the zones are booting, and there's no guarantee at all that any particular number represents any zone over time. At best, they're useful in undocumented or volatile debug interfaces (such as in mdb). It's the zone names that are fixed and are intended as administrative interfaces. And that since you can't do any reasonable arithmetic comparisons between them (what does it mean for one zone ID to be less than another?), it doesn't really matter what a zoneid_t is inside. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?
John Leser wrote: Darren Reed wrote: Do a man snoop and search for the word zone. Oh, that was a bit of a let-down... Anyway, this seems to pose an interesting challenge to programs like snoop that want to encode zone ID information in output files. The zone ID numbers are essentially meaningless in a disk file - who knows what zone names they corresponded to at the time the capture was done. To be at all correct, IPNET headers have to encode the string literal for the zone name. Ugly. Not necessarily ... it's ok if IPNET headers have zone IDs in them, as long as all the tools that use them translate to and from string format when interacting with the user or transporting them externally (as in over a network or via a file). (I think you're right, though, that ideally the interface between kernel and user space should deal with strings, because there's no guarantee that a given zone ID that you see in an IPNET header will necessarily correspond to the named zone you get moments later with getzonenamebyid() -- because the ID might have been discarded by the kernel between those two events.) Yes, it does mean that some file formats are going to be a little less pretty than others. Also, zone IDs are more ephemeral than UIDs or GIDs, because if I log out and back in, I keep the same UID. If I halt and boot the same zone, it gets a new zone ID each time. Exactly. It's a different design. As I said before, when I was working on the old Kevlar team, I wanted a UID-like experience for these, because I _assumed_ that people would want to administer zone names centrally across many machines, and because it seemed to me that integers would be easier to encode and work with. The rest of the team, though, assumed differently: that if there was any coordination between machines, it would be on the basis of the assigned zone name, and that strings were just as easy to use. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] /export/home missing on non global zone
On Jul 5, 2009, at 5:39 AM, Anon Y Mous no-re...@opensolaris.org wrote: What I meant to say was that my OpenSolaris 2008.11 ipkg zones use / home for user directories instead of /export/home. I think it maybe has something to do with the automounter not being set up automatically in the zones? I know in the global zone in 2008.11, the /home directory is off limits because it's under the control of the automounter. You can control /home via /etc/auto_master. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can a non-global zone mount an NFS file system from its own global zone?
On Jun 29, 2009, at 2:58 PM, Nicolas Dorfsman n...@unikservice.eu wrote: Le 29 juin 09 à 18:37, John Lorenzon a écrit : The answer is no. 5065254 NFS/UFS deadlock when system is both NFS server and client We don't use UFS. ;-) That might not be enough to save you. The bug is a complicated (and rare) VM/FS/NFS deadlock. Best advice is just to avoid the situation. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Parallel mount question
On Jun 29, 2009, at 2:31 PM, Glenn Faden glenn.fa...@sun.com wrote: Steve Lawrence wrote: I think each zone's automounter is smart enough to use lofs instead of nfs for mounts from a non-global to a global zone. Please explain how this is possible. How can the automounter convert an nfs specification of a global zone pathname into a pathname which can be expressed using the non-global zone's lofs semantics? It'd have to be a helper out in the global zone that sets up the correct lofs mount. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review request: SUNWzoneint removal
Edward Pilatowicz writes: W3 says that we shouldn't (at least) ship compilation symlinks for private libraries. sure, it says that. and then the first NOTE says you can ship them to simplify compilation. i thought about removing these links, but then i looked at libzfs and libdtrace as my examples and those seem to have the convience compilation links as well. Not sure if you need usr/src/tools/abi/etc/exceptions entries in that case. Do you? IPS is a development project that is targeting the ON gate, but due to artifacts of the current development process, it is not currently based on the ON gate. hence i don't think that IPS needs a contract to access ON Consolidation Private interfaces. OK. i don't know where Caiman plans to integrate. i would guess ON (since the install gate is going away), but perhaps due to nostalgia we'll get a new install gate? ;) ;-} In that case, my comments are just: - The CR is stuck in Dispatched (nobody cares) state. It needs to be at least Fix Understood with an Evaluation included. - The ABI exceptions entry isn't present ... but I have no idea what state the ABI tools are actually in. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Running a 32 bit zone in Solaris 64 bit
Bernd Schemmer writes: I'm running OpenSolaris on a T61p with 64 Bit CPUs. Sometimes I need a 32 Bit OpenSolaris instance (e.g. to compile 32 Bit binaries without changing the make files). I can do this with either rebooting into 32 Bit or within a VirtualBox /QEMU virtual machine but it would be more elegant to use Zones for this task. Can this be done (I did not find a solution in the docs ...)? I'm not sure it makes sense. First of all, individual processes are either 32-bit or 64-bit. It's perfectly normal to run 32-bit processes on a 64-bit kernel, and to run them side-by-side with 64-bit processes. Secondly, it's the kernel itself that's uniquely either 32-bit or 64-bit on a given system. There's only one kernel for all of the zones, so there's no way to run a 32-bit kernel for just one zone. In fact, we generally build our 32-bit kernels and user space on 64-bit systems. Building there works fine; special 32-bit systems aren't needed (and aren't even possible with SPARC). What exactly are you trying to do, and why won't it work on a regular 64-bit kernel? Do you just want to limit the output of 'isainfo', or is there something more to it? -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Running a 32 bit zone in Solaris 64 bit
Bernd Schemmer writes: hat exactly are you trying to do, and why won't it work on a regular 64-bit kernel? Do you just want to limit the output of 'isainfo', or is there something more to it? Exactly -- ... The problem occured while I was creating a package for the new QEMU version. That package should contain the 64 bit binaries and the 32 bit binaries. The configure script for QEMU uses isainfo to decide what kind of binaries to build. I can simply change the configure script but then I've to do this for every new version or I can write a wrapper for isainfo (that's what I did). The first thing I'd recommend would be fixing the configure script so that it knows that amd64 i386 means that you can build *both* and not just one. Failing that, putting a wrapper on isainfo is what I'd recommend. If you want to get really fancy about it, you could create a file like this: cat /export/home/myisainfo EOF #!/bin/sh echo i386 EOF chmod +x /export/home/myisainfo mount -F lofs /export/home/myisainfo /usr/bin/isainfo For bonus points, you could add the 'lofs' mount to a zone's configuration so that it always reports i386. (And since it's 'mount', the trick will work with a sparse root zone.) -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Commands to create a zone with r/w /sbin/usr?
ольга крыжановская writes: 2009/5/22 James Carlson james.d.carl...@sun.com: If you're using S10 or SXCE, use man zonecfg and read the section on Whole Root Zones. The person who installed this machine did a rm -f -r /usr/share/man to conserve space. I am without manual pages and zonecfg does not support --man like the shell. Wow. He probably could have saved tons more space by applying rm -rf to /usr/lib as well. Man pages are a crucial part of the system, so I'd certainly recommend recovering them if at all possible. Furthermore, removing or altering files that are delivered by packaging simply is not supported. I don't see how what you're describing could be considered a supportable or even a reasonable administrative action. It looks much more like vandalism, and (if it were my system to manage) I'd treat it that way. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Commands to create a zone with r/w /sbin/usr?
bob netherton writes: zonecfg create starts off with /etc/zones/SUNWdefault.xml as your starting configuration and includes the set of inherit-pkg-dir directories that you describe. zonecfg create -b starts off with /etc/zones/SUNWblank.xml which is pretty much what it says, a blank configuration. With -b, it starts off with a blank configuration. That will have no inherited directories at all. The System V packaging code, though, knows only about the four special inherited directories (/lib, /platform, /sbin, and /usr). Those are the only ones that should be added and/or removed to change from whole root to sparse root. It's possible (though unlikely) that there could be things added to SUNWdefault.xml in the future that are intentionally not added to the blank template, and you'd thus end up with something not quite expected by using -b. (I'm pretty sure this issue was discussed during one of the original Zones packaging tools ARC cases.) (I just noticed that the man page says /bin instead of /usr. *sigh*) I'm trying to understand your caution against the use of -b not being supported. To me it seems more safe than relying on removing 4 fixed inherit-pkg-dirs which we might change in the future, although at this point certainly seems unlikely. Agreed; it is in fact very unlikely to change. And -b is currently equivalent. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] PS Re: Fwd: Live Upgrade and sparse root zones with their own /usr?
Elizabeth Schwartz writes: Although zonecfg allows you to remove one of these as an inherited directory, you should not do so. You should either follow the whole-root model or the sparse model; a subset of the sparse model is not tested and you might encounter unex- pected problems. I don't see /usr in that list. Good point. However the original issue about using a subset of the sparse stands. It's never tested and unlikely to work right. Am I just hosed? Do I need to rebuild my machines with whole-root zones? That's gonna eat up some space. If you need whole-root, then that's what you'll need to do. You may want to check out the ZFS clone features, as that'll save a significant amount of space. In some cases, you don't actually need whole-root. All you really need are some writable directories inside the inherited mount points. In those cases, you can set up lofs mounts to provide writable storage to the zone. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] PS Re: Fwd: Live Upgrade and sparse root zones with their own /usr?
Elizabeth Schwartz writes: PS was creating sparse zones with their own /usr directories a totally dumb idea? At the time we did it because we had apache stuff that was trying to poke into /usr and I wanted to allow the web developers to play with /usr if needed. But I'm worried that I've broken the model as far as getting this all to work. Ouch. The man page for zonecfg(1M) says: A sparse zone inherits the following directories: /lib /platform /sbin /bin Although zonecfg allows you to remove one of these as an inherited directory, you should not do so. You should either follow the whole-root model or the sparse model; a subset of the sparse model is not tested and you might encounter unex- pected problems. Basically, the two models that are fully tested and supported are sparse root and whole root. Sparse root inherits all of the directories as listed above. Whole root inherits none of them. You can augment those models by adding new things to inherit with a sparse root and by doing overlay mounts of directories that do *not* include packaged software (e.g., /usr/local can be made writable), but removing just some of the things on the sparse list will likely run you into upgrade trouble. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] high values for zones size in os2008.11
solarg writes:
# zfs list
NAME USED AVAIL REFER
MOUNTPOINT
rpool/zones/catalogue2/ROOT/zbe 4.49G 17.9G 7.47G legacy
rpool/zones/catalogue3/ROOT/zbe149M 17.9G 6.80G legacy
rpool/zones/test-drupal/ROOT/zbe 511M 17.9G 5.21G legacy
on another os2008.11 machine, i created a new zone, and don't notice
these high values:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool/export/catalogue4 4.07M 16.1G21K /export/catalogue4
rpool/export/catalogue4/ROOT 4.05M 16.1G18K legacy
rpool/export/catalogue4/ROOT/zbe 4.03M 16.1G 235M legacy
what is the meaning of REFER? can i gain more space?
REFER is documented on the zfs(1M) man page. It's the amount of
space accessible by the dataset and some or all of it may be shared
with another dataset. If you're interested in the amount of disk
space used, then the USED column is what you want.
At a guess, the difference between these two machines is that
'catalogue4' was likely created as a sparse-root zone, while
'catalogue2' was created as a whole-root zone. The clones of that
whole-root zone ('catalogue3' and 'test-drupal') use little disk
space, as most of it is 'referred' from 'catalogue2'.
This part of the output shows the relationships:
rpool/zones/catalogue2/ROOT/zbe4.52G 7.47G
rpool/zones/catalogue/ROOT/z...@catalogue2_snap
rpool/zones/catalogue2/ROOT/z...@test_drupal_snap358M 4.75G -
rpool/zones/catalogue2/ROOT/z...@catalogue3_snap85.2M 7.47G -
[...]
rpool/zones/catalogue3/ROOT/zbe 149M 6.66G
rpool/zones/catalogue2/ROOT/z...@catalogue3_snap
[...]
rpool/zones/test-drupal/ROOT/zbe511M 5.21G
rpool/zones/catalogue2/ROOT/z...@test_drupal_snap
--
James Carlson, Solaris Networking james.d.carl...@sun.com
Sun Microsystems / 35 Network Drive71.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] NTP client in non-global zone
Nicolas Dorfsman writes: Le 19 févr. 09 à 14:02, James Carlson a écrit : To expound on that a bit: non-global zones can have access to networks that the global zone cannot talk to. In these cases, it's possible for NTP to be configured to serve out time even if it can't manage the time on the system. The disable pll option in ntp.conf would be used to set up such a server. Idea is to have one particular non-globale zone setting the time for the whole machine. Yes; that's another way to run. And it's such a good idea that it's already supported and documented. ;-} -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] NTP client in non-global zone
Jeff Victor writes: On Thu, Feb 19, 2009 at 9:54 AM, Timothy Kennedy timothy.kenn...@sun.com wrote: Nicolas Dorfsman wrote: It would be a great idea to have a easy solution to give these privileges to a zone. in zonecfg for a given zone, set limitpriv=default,proc_lock_memory,proc_priocntl,sys_time David Comay has an interesting blog post on this that can be found here: http://blogs.sun.com/comay/entry/privilege_set_me_free that explains the reasons for permissions additional to sys_time. Here's another one: http://blogs.sun.com/JeffV/entry/shrink_wrap_security1 . You'd think I would have updated the FAQ by now... :-( I just updated it, but changed it to NTP client. I don't know NTP well enough to know if a zone can be an NTP *server*. If anyone knows Sun's position on this, I will add it to the FAQ. Being a server is easier than being a client. Clients have to adjust the local system time, or they're not doing anything useful. A server can broadcast the time without actually being in control of the local system time (disable pll). -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Making directories in /usr visible (from global zone) in non-global zone
Arun Gupta writes: Here is what I tried in my OS Virtual Box image: - created 2 zones (http://blogs.sun.com/arungupta/entry/totd_68_installing_zones_in) - installed GlassFish in /usr/glassfish How? If it's via SysV packages, then it sounds like those packages might not be Zones-compliant. If it's by some other means, such as an installation script that invokes 'cpio' or 'tar', then you're on your own. - created another zone In all the zones, /usr/glassfish is not visible. Manually created /usr/foo and even that's not visible in any of the zones. If you manually created that directory, then you should see it in the zones *if* those zones were created with /usr as an inherit-pkg-directory. You'll see it because /usr is (by default) a lofs mount to the global zone's /usr. That's the default, and you have to do something at zone creation time (either using -b for the zonecfg create subcommand or deleting the /usr IPD) to get independent zones. If you did remove that IPD in some way when you created the zone, then it sounds like the system is doing what you asked it to do. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Install zones, configure as DHCP client
Bill Walker writes: If you are really needing DHCP for some reason, I'll defer to others with more experience in those realms. The only supported way to do this today is to use exclusive stack instance zones (set ip-type = exclusive). It would be nice to have DHCP supported as an option for interface configuration via zoneadmd, and the DHCP client has the features necessary to make this work, but that feature hasn't been added to Zones. RFE 5005887 also covered this case, but it was closed out when the exclusive stack instance feature was integrated, and I don't think a new RFE was ever opened. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Install zones, configure as DHCP client
Arun Gupta writes: Can you explain what is exclusive stack instance mean in this context ? See the ip-type parameter in zonecfg(1M). Zones can be created using one of two different networking models. In the default shared model, the zones are just given IP addresses on links that are controlled by the global zone. The non-global zone has no control over its interfaces, and there's one instance of the IP stack shared between the non-global zone and the global zone. The interfaces are configured by zoneadmd using parameters provided by zonecfg. In the exclusive model, the global zone gives the non-global zone access to individual links, which can be VLANs or separate NICs. The non-global zone then independently plumbs its own IP stack on top of those links. The global zone has no control over the addresses that the non-global zone uses, and the non-global zone sets these. With an exclusive stack instance, the non-global zone is able to control most of the IP configuration aspects of the interface, including using DHCP to configure the address. (It's unable to supply its own kernel modules, though, because there's still only one kernel image on the system.) Will creating zones in a Virtual Box image qualify as that ? No. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Scratch Zone - purpose
Dr. Hung-Sheng Tsao (LaoTsao) writes: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6328286 Rob McDonald wrote: Hi All Can anyone explain what a scratch zone is or point me to a relevant document? In addition to the above CR, see: http://www.opensolaris.org/os/community/arc/caselog/2005/474/ A scratch zone is a mechanism that allows us to mount up a zone that exists in an alternate boot environment (a separate system root). The zone can't be booted (it's not known whether all of the bits, including configuration, inside are runnable on the current kernel), but it's possible to make processes enter the zone, and common directories (such as /usr and /lib) have lofs mounts from the running system to allow some limited work to be done. Scratch zones are used as part of the upgrade process. They're intentionally undocumented, because they're meant to be an internal design detail. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Adding a NIC to running zones
Jeff Victor writes: A NIC can be added to a running shared-IP zone by using the ifconfig command its zone parameter. Can an unplumbed NIC be added to a running exclusive-IP zone usnig the same method? (I don't have a system with enough NICs to test this.) No, because they're different objects. ifconfig controls IP interfaces, not NICs. To move a NIC into a running exclusive-IP-stack zone, use dladm. This should do the trick: dladm set-linkprop -t -p zone=myzone bge0 Note that -t is required. To make a permanent change, use zonecfg. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Moving /opt to inherited
David Smith writes: I have about a dozen zones on a system. During the creation of some of the early zones, I was wondering why my sparse zones were so large. I found out that the /opt area was being copied, so I updated the default template to make /opt an inherited directory for the remaining (about half) the zones on the system. Now I would like to covert the zones with full /opt directories to inherited. Can this be done fairly easily?What about patches which may have been applied which affect the /opt area on these zones? Would it be better to re-install these zones? Any advise you could recommend about best course of action would be appreciated. I'd reinstall the zones. We don't currently have a documented (or practical) way to change a directory from regular to inherited or vice-versa. As for the rest, packaging and patching understand how to deal with inherited directories, and inside a zone they skip over objects that are installed there (because the objects will have been installed in the global zone). I could be mistaken about this, but I *think* that the only tested configurations are the default 'sparse root' and -b 'whole root' ones; I don't know of any mix-n-match testing with inherited product directories, so you might be skating out onto a thinner section of the ice. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Moving /opt to inherited
Jerry Jelinek writes: patch to be applied to the zone. Inherit-pkg-dir is probably not the best way to save space here, unless the associated behavior is what you really want. It might be easier to simply delete the contents out of /opt inside the zone after it is installed if you want to save space. If you do that, then the packaging data will be out of sync. That may or may not matter for the patches you later need to install. I know that some folks keep /opt as inherited and then use lofs to create locally writable directories underneath (as in /opt/local), and others keep /opt local and then use lofs to copy selected things from the global zone. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] exclusive-ip zone and non-observability
Christine Tran writes: I am putting 2 applications that talk to each other on two non-global zones of type exclusive-ip. I do this for one reason only, that is to be able to observe traffic between the two applications for troubleshooting if and when things go wrong. Unfortunately, this will run afoul of security guidelines, which says one should not be able to observe anything from the outside. Encryption is just not in the picture right now. I'm trying to think of a way to make traffic observable from the global zone only, and obscured to everyone else outside the box. I thought of not cabling the interfaces and turning off ip_restrict_interzone_loopback, but that just backs me right into the corner of not being able to snoop anything on the lo0 channel. I don't have anything here that I can use, do I? Just making sure. Using the existing Clearview interfaces (integrated back in November for build 103; see CR 4085089), you should be able to snoop lo0 just fine. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.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] Zone Bandwidth
Jeff Victor writes: You didn't mention if your interest was in Solaris, OpenSolaris, or both. In the future, project Crossbow will provide virtual NICs (VNICs) which can be assigned per-zone, and IIRC the counters will all be broken out per-VNIC, again giving you what you want. But that's not even in OpenSolaris yet. Actually, Crossbow integrated into build 105 last Friday. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] zone p2v proposal
Jerry Jelinek writes:
1) SMF services that are not usable within a zone should be deleted or
disabled as necessary (for S8 and S9 we dealt with rc scripts
instead).
2) Network configuration must be adjusted depending on if the zone is
shared-stack or exclusive.
Depending on what the original archived server once did, it seems at
least possible that some of the changes that occur here could cause
damage to the services that the image will provide when run inside a
zone.
Can a user predict what these automatic changes will be? After
import, is there a log of the changes or adjustments made?
S10 has a number of new features over S8 and S9. How do these factor
in? For instance, what happens to the privileges required in order to
run the services contained in an archive? (The user might need to
configure the zone so that the right set of non-default privileges are
granted. Is there some new way to do this, or does the user need to
trouble-shoot failing services?)
-a {path} - specifies a path to an archive to unpack into the zone
-d {path} - specifies a path to a tree of files as the source for the
installation.
Just for clarification: does that '-d {path}' option point to a system
root? Could I use lumount to mount up an inactive BE and turn it
into a zone?
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.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] Update on attach and upgrades
Nicolas Dorfsman writes: Enterprise version of OpenSolaris ? Could anybody explain what does it mean ? It doesn't exist yet, so it's unlikely that a complete answer is available ... at least until something's announced by Sun. My guess would be at least an OpenSolaris distribution including the currently-missing enterprise features (likely something akin to jumpstart, flash archives, and SPARC) and an offer of contract-based support. Perhaps also more repositories. That's just my guess, though. Other than the eventual introduction of new features (the ones now missing in Indiana), I don't think it's something that would need to be discussed here, any more than any other entity offering to provide commercial support on existing open source code. (If what you might be expecting here is someone to take the code private somehow, then I very much doubt that.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] zone p2v proposal
Jerry Jelinek writes:
Can a user predict what these automatic changes will be? After
import, is there a log of the changes or adjustments made?
I assume you really mean which SMF services will be off, since
the other changes are listed here in the case?
Exactly.
We can describe which
SMF services will be deleted or disabled in general terms, but we
really want this to be driven by the pkg metadata itself. We'll probably
also have a list of some well-known 3rd party services that don't work
inside a zone, such as vxvm, which we'll turn off. As with the S8 and
S9 brands, there may need to be some manual tweaking of the services
as part of the p2v process, although we've generally had good results
with the S8 and S9 brands without a lot of manual work.
I can understand that some tweaking would end up being necessary, but
at least an outline of what's affected (if known) would probably be
good to include with the case materials.
There will also be a log file for this p2v process. I'll add that info to
the case.
OK.
S10 has a number of new features over S8 and S9. How do these factor
in? For instance, what happens to the privileges required in order to
run the services contained in an archive? (The user might need to
configure the zone so that the right set of non-default privileges are
granted. Is there some new way to do this, or does the user need to
trouble-shoot failing services?)
I am not planning on making any automated changes to the privileges available
to the zone. If this turns out to be an important issue, then we could
look at that as a possible future enhancement. The problem I see is that
we don't have any data to automatically drive which services and apps need
which privs.
Right; that's what I was getting at. We don't carry that sort of
metadata around in any convenient form.
I suppose it'd be possible to look through the SMF 'privileges' for
the services that are still enabled, and then attempt to union those
into the zone privileges ... but it's unclear if that's really the
right approach, particularly for services that might be aware enough
of zones to work in some other fashion when restricted by the
environment.
There are other things that work like this, such as ZFS delegations or
in network configuration, so there might be a broader issue here in
configuring the zone so that it can properly accept the archive. I'm
not saying that I think it's unusable, but rather that there may be
non-trivial cases here where a good bit is left to the user's
imagination.
(Then there are other cases, such as NL7C. You might possibly want to
use that if you're in the global zone, but since you can't use it in a
non-global zone, and since the web server itself is perfectly
serviceable _without_ NL7C, translating over means simply removing
that from the configuration. I'm guessing that sort of thing is a
manual operation.)
-a {path} - specifies a path to an archive to unpack into the zone
-d {path} - specifies a path to a tree of files as the source for the
installation.
Just for clarification: does that '-d {path}' option point to a system
root? Could I use lumount to mount up an inactive BE and turn it
into a zone?
Yes, -d points to a system root, so your idea of turning a BE
into a zone should work just fine.
OK; should point out that this is intended to be a system root. (I
know, it should be obvious, but since I had to ask anyway ...)
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.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] zone p2v proposal
Jerry Jelinek writes: Mike Gerdts wrote: This implies that the source system can be S8, S9, or S10. I don't see anywhere else in the proposal that explicitly states that S8 and S9 can be attached and upgraded, so I suspect I am reading my wishes into your words. That was not my intention. I'll reword this. The source system must be a S10 or above (something that zone update on attach will handle). Update on attach just means apply saved patches, if any are needed, right? Where possible, things will be disabled, but for SMF services delivered in hollow pkgs, those services must be removed due to the way the SMF dependencies are defined. Disabling those services doesn't work. V2P is What maps packages to SMF services? (I'm guessing it's a matter of seeing the manifests in a hollow package and then reading the manifests to determine what services they deliver, and disabling those. Is that right ... ?) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] zone p2v proposal
Nicolas Williams writes: On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote: I suppose it'd be possible to look through the SMF 'privileges' for the services that are still enabled, and then attempt to union those into the zone privileges ... but it's unclear if that's really the right approach, particularly for services that might be aware enough of zones to work in some other fashion when restricted by the environment. Shouldn't changes to privileges be backwards compatible? I can't quite tell if privilege names and semantics are intended to be Committed or not. I'm not sure what you're talking about here, but I'm not referring to any sort of version-related compatibility issue. I'm explicitly assuming that all such issues are dealt with by the upgrade-on-attach feature (and that we're not yet addressing the S10-in-a-zone-on-OSOL issue). Instead, I'm talking about the required privileges in order to enable a given service inside a non-global zone. If a service is defined to be run inside the zone (based on the archive presented), then someone or something must make sure that the required privileges are granted to the zone, or the service is going to fail. It's a zone configuration issue. Currently, there's a default set of privileges that are granted to non-global zones. It's possible to modify that set (up to a point) with 'limitpriv'. There are some that can never be granted, and if those are needed, then enabling the service just isn't going to work at all. (Unless, somehow, the service itself detects this case dynamically and falls back to some smaller set of zone-friendly features.) NGZs disabling themselves, and services that can be configured differently to run in zones either disabling themselves or changing their configuration (as in your NL7C example, though why shouldn't NL7C be available in NGZs?). I don't think anyone's bothered to make it zone-aware. The reason I mentioned that one is because it's an interesting example of an edge case: it could be in the archive being imported, but isn't actually required for normal operation, so you can ignore it if you don't know how to import it. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] zone p2v proposal
Jerry Jelinek writes: James Carlson wrote: Update on attach just means apply saved patches, if any are needed, right? Not really. We see what pkgs are out of sync, either because of the pkg version of because of patches applied to those pkgs, then we do something similar to uninstalling and reinstalling those pkgs into the zone, preserving the editable and volatile files. This causes those pkgs to be up-to-date with respect to the global zone, just as is the case when a zone is newly installed. Its a bit more complicated than that, but we never actually apply patches to the zone. The global zone files are already patched and that is the source of the files for the non-global zone. But you would _not_ do this across minor releases, so S9 installing on S10 won't be upgraded nor (presumably) would S10 installing on OpenSolaris/Nevada be upgraded at the package level. Is that correct? If so, then at least the administrative aspects of patching are relevant here: the result is as though the required patches were installed into the newly-attached zone, regardless of how it's implemented internally. (And just as patching doesn't work across minor releases, it doesn't work here.) I think answering that would answer the previous poster's question about the difference between doing an upgrade before flar creation and just importing a flar from S9: the former results in a native zone using this new functionality, while the latter results in a non-native brand without upgrade. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] zone p2v proposal
Jerry Jelinek writes: We can handle 'update on attach' from s10 to nv, although nv isn't an official release yet and something might happen which breaks this (maybe IPS?). We don't support 'update on attach' of s8 or s9, although I have played around with that and it kind of works. There are some other issues there which need to be looked at before we would support that. One thing we've considered, but which is not part of this proposal, is to use 'update on attach' to convert an S8 or S9 branded zone into a native zone running S10. There hasn't been any demand for that feature yet, so its not currently one we're working on. Perhaps it's not this project, but it'd be interesting to see where this feature set is headed. I would expect that since we support non-native brand zones, the user has to choose (somehow) whether he wants to have his imported zone become upgraded to the current system or whether he wants it to stay as-is. Since we (intentionally?) make branded zones available only for minor releases -- and not for individual KUs -- this means that the user should expect that he's forced into an upgrade of some sort that emulates patching when importing an S10 zone onto an S10 system. But should he expect this otherwise? When we differ by a minor release, there are two paths (as-is branded or upgrade to native), and it's not clear which gets used or should be used. Otherwise, if he's always forced into an upgrade, then that means branded zones eventually go away, doesn't it? Or does giving the user this sort of control open the possibility for different zones on an S10 system that run different S10 Updates? Obviously, I'm confused. :-/ Is that correct? If so, then at least the administrative aspects of patching are relevant here: the result is as though the required patches were installed into the newly-attached zone, regardless of how it's implemented internally. (And just as patching doesn't work across minor releases, it doesn't work here.) When crossing a minor release boundary (like s10 to nv) all of the pkg version numbers change, so patches aren't a factor. We see that there are new versions of the pkgs, so we know those pkgs need to be updated. I think that misses the point. I wasn't expecting upgrade on attach to do anything across a minor release boundary; I was expecting it to do what it does on S10, which (from a user's point of view, not an implementation view) is effectively upgrade the bits as though patches were added due to the differing patch levels of the source archive and the running machine. I'm surprised that it might do something different. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] zone p2v proposal
Jerry Jelinek writes: Since we (intentionally?) make branded zones available only for minor releases -- and not for individual KUs -- this means that the user should expect that he's forced into an upgrade of some sort that emulates patching when importing an S10 zone onto an S10 system. But should he expect this otherwise? When we differ by a minor release, there are two paths (as-is branded or upgrade to native), and it's not clear which gets used or should be used. When attaching a zone to a new system, the zone configuration's brand dictates the behavior. For solaris8 or solaris9 branded zones, nothing is done to the zone. For native-branded zones, either the zone is already in sync with the global zone (making it usable) or it is not in sync and you must use 'update on attach' to complete the migration. That's the key part I was missing -- the fact that native brand dictates the behavior. (Well, that and the word patch used in 2007/621. ;-}) I think we're in sync now. Or does giving the user this sort of control open the possibility for different zones on an S10 system that run different S10 Updates? We don't have a solaris10-brand at this time so the issue doesn't apply. Yep; understood. It sounds like you might be thinking of the following RFE: 646 Solaris 10 zones on OpenSolaris binary (supported) distributions Presumably, as a non-native zone, if such a thing existed, it would be expected to result in no upgrade-on-attach behavior. Right? I think that misses the point. I wasn't expecting upgrade on attach to do anything across a minor release boundary; I was expecting it to do what it does on S10, which (from a user's point of view, not an implementation view) is effectively upgrade the bits as though patches were added due to the differing patch levels of the source archive and the running machine. I'm surprised that it might do something different. Yes, it does that. I didn't mean to imply it did something different. update on attach always uses the same mechanism to update pkgs within the zone, whether the pkg varies by version number or by the patches applied to the pkg. OK. The surprise to me is that it doesn't seem to care about minor release. I guess that's obvious when the mechanism is explained, but it certainly wasn't obvious to me. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Update on attach and upgrades
Nicolas Dorfsman writes: I'm just really surprised to see OpenSolaris and Enterprise in the same idea. I thought...no, I'm sure Enterprise OpenSolaris is just called Solaris. I agree that what you're suggesting would seem simpler and more obvious (it does to me), but it's up to marketing to determine what those words actually mean, and I'm not in marketing. Fortunately, I don't think the issue has any substantial impact on opensolaris.org. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] DHCP client with shared ip interface in OpenSolaris 2008.11?
Michael Schmarck writes: In OpenSolaris 2008.11, is it possible to setup a non-global zone to be a DHCP client, when using shared IP interfaces? No. The support for that would need to be in zoneadmd, and it's not there currently. I implemented the necessary DHCP parts back in build 57 (DUID-based client identifiers), but the Zones part never made it. CR 5005887 was closed based on the exclusive IP stack instances project, though it didn't solve the problem for shared IP stack zones. Googling a bit around, I found a workaround at http://www.opensolaris.org/os/project/crossbow/faq/#ipinst_dhcpclient *How do I configure the non-global zone to be a DHCP client? This only works with exclusive stack instances, not shared. There's currently no way to do it with shared stack instances. I think there probably should be a way to do this, but now that 5005887 has shipped, we'd probably need to open a new RFE for it. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Zone Statistics: monitoring resource use of zones
Glenn Brunette writes: This actually hits on a similar request that I have (but for different reasons). I would like a stable interface from which I could tell the update revision of a system. We have no such thing. It's not clear to me how such a thing would work. Suppose someone installs only the KJP corresponding to U5 on a U4 system -- is that now U5 or U4 or U4++ or something else entirely? If that returns U5, then suppose someone installs a U5 patch not dependent on the KJP onto a U4 system. Is that still U4? What determines U5-ness? If it's dependent on the upgrade process itself, and none of the above would return the answer U5, then suppose someone installs all of the patches for U5 and then installs/removes packages to make the system equivalent to one that had been upgraded. Is that now U5 or is it still something else? Does it make any sense that you can have arbitrary (and improper) subsets of bits on the system and yet you're insisting on returning an effectively scalar result? I have a very large government customer who (as part of their security configuration hardening and assessment) process have a very real need to detect OS version and update levels so that they can determine which actions/checks to apply. You can get the OS version from uname and the list of patches installed from patchadd. assumptions about how the system was installed/maintained). For example, is the feature not present or has it been removed or simply not installed? Is there some difference between those things? That sounds like the realm of metaphysics to me ... if bits aren't present, the why question seems much less interesting. How can the system necessarily know what features _could_ potentially be installed but aren't there? Isn't that everything? If you've installed something and then removed it, would that be different from never having installed it in the first place? (If it is, doesn't that indicate a bug in the removal process?) Perhaps most importantly: how can you use that information? What would you do differently if something had once been installed that you wouldn't do if it had never been installed? Also, the existence of some features also can not be easily tested using automated tools without imposing a great burden on the tool developer. That sounds like a bug that should be fixed. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Zone Statistics: monitoring resource use of zones
Mike Gerdts writes: On Tue, Nov 18, 2008 at 11:30 AM, Enda O'Connor [EMAIL PROTECTED] wrote: To me they probably need a patch automation tool to tell them what is currently available in terms of patching, and they see what they need from that. Interface changes always have an associated ARC case ID with them, right? It depends. Many changes involving Project Private and Consolidation Private interfaces have no ARC involvement at all. For other projects, we review them even when there are *no* interface changes, because the projects have architectural features worth reviewing. ARC review isn't just about interfaces, and in some cases the consumer may want to know something more like is the fix for known problem Foobar installed? Why not make it so that the software that delivers an interface delivers some metadata that says that the interface specified in the ARC case is on the system. Any time a patch or installation delivers, removes, or deprecates a feature (interface) this metadata would get updated. A stable interface is then needed to query and update that metadata. If I read that correctly, the query could be something like: if isinstalled PSARC/2008/123; then ... fi If so, then that's a bit weird, but I guess it could be made to work. It's not clear to me whether that's as useful as providing domain specific feature tests. It'd be better to start with a clear set of requirements and work down to an implementation, I think. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] opensolaris zones cookbook
Mike Futerko writes: How to identify is it OpenSolaris or Nevada? I've just finished LU from snv_85 to snv_99 and wondering will my zones boot or not when I switch to snv_99? If you're using LU, then it's Nevada (Solaris Express). If you're using beadm and pkg to do your upgrades, then it's the OpenSolaris distribution. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Questions regarding Solaris containers
Challa, Narsimha Reddy (STSD-HYD) writes: 1. What are the supported versions of Solaris that support Containers concept? As per my search on this from Solaris 10 Update 4 or Update 5 onwards containers are supported. Am I right? I'm not quite sure what you mean by Containers; can you clarify? The Solaris Zones feature has been a part of Solaris 10 since the very first release, but we've added capabilities to it in several of the updates since then. 2. Can raw disks be exported to Solaris containers from global zone? Using zonecfg command we tried exporting devices (disk partitions/SVM volumes) to containers. Once they have been exported we are unable to see those in the /dev/dsk directory of the non global zone. Did you reboot the zone after setting up the export? Are there any log messages? What was the exact configuration used? (And have you contacted Sun's support group?) There are some known problems, such as CR 6632938, which makes a pattern like /dev/dsk/c2t1d0s* not work, but getting to the root of the problem will require details. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Somewhat unusual exclusive-IP type configuration needed
Joe Barbey writes: I would like to host a number of zones on a server, let's say an m4000, but I want those zones to be on a different subnet than the global. So far, no problem: use exclusive-IP. However, currently I don't have enough NICs to give one each to all zones. Use VLANs. It'll work if you give each exclusive IP instance a separate VLAN on an interface (or a small group of interfaces). One thought I had was a sort of mix of shared-IP and exclusive-IP. Give a couple of different zones the same NIC in exclusive-IP mode. I haven't tried it, but I'm fairly certain this won't work, as each zone will try to control the NIC itself. No, that won't work. We discussed it during the development of the IP Instances (exclusive stack) feature, but the project team considered it to be too complex at least for the initial version. Exclusive is just that: exclusive of all other zones on the system. My major concern is to get the global zone on one subnet, while the non-globals will be at least one other subnet, possibly others. Using shared-IP, I know we had routing issues. I can't remember if it was on the global side or the local, but I know there were issues. Perhaps this has been fixed in more recent releases? As long as you have distinct destinations for the traffic, that can be made to work with shared stack instances, but you're right that it's always been a bit problematic. It wasn't the design center for the original Kevlar/Zones project: all zones were expected to go on a common set of subnets. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Confirming Zone running Container
Moore, Joe writes: The other way that the global zone identity normally leaks through to the non-global zones is through the system's hostid. So if you compare the output of `/usr/bin/hostid` with `for e in $allglobalzones ; do ssh $e /usr/bin/hostid ; done`, you can easily see which global zone matches your local. Yet another way it leaks through, at least on systems with shared IP stacks, is in hardware addresses. Look at netstat -np. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] [osol-code] Zones take differenent logical interfaces after every reboot
Ben Rockwood writes: James Carlson wrote: Let me know if you my explanation is not clear . The part that's unclear is why this is a problem. What are you doing that depends on a logical interface name, and that needs to keep that name static? While I can't offer a particular reason, using the zone id for the logical interface instance would be pretty. Maybe. That sounds like something that could be discussed with the Clearview folks, though I think they're mostly addressing renaming at the datalink level and not way up at IP's level where logical interfaces reside. But what's the problem that the original poster was concerned about? Having more obvious names would be nicer, but you can get the zone name output in the global zone from ifconfig, so the unobvious names don't seem to constitute much of a problem ... just rather an annoyance. Of course, that argument dies as soon as you ask how to address zones with multiple virtual interfaces on a single physical NIC. You'd need some coherent naming scheme to keep them separate in that case. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] [smf-discuss] 6725004 - installing single-user-mode patches automatically
Enda O'Connor ( Sun Micro Systems Ireland) writes: alternate BE ), I have seen issues with compilers failing due to SUNWcsr and SUNWtoo getting out of sync, because user updated the live system. I think I understand that problem, and I don't think it has anything to do with a live update. The underlying problem there is that there's a hidden dependency built into the way /usr/bin/ld (in SUNWtoo) is constructed. It depends on a private version of libld.so.4 (in SUNWcsr) -- one that gets incremented occasionally. Thus, if you upgrade SUNWcsr, you must also upgrade SUNWtoo, even if you didn't want to, and even though the package dependency runs the other direction (SUNWtoo depends on SUNWcsr, not vice-versa). Since SUNWcsr is one of the common packages on which everyone depends, it's at high risk of being upgraded frequently. It'll be upgraded when someone installs a new package, or when someone upgrades an existing one, because it's a dependency. But the system doesn't seem to know that SUNWtoo is tightly bound to a special library version and must be upgraded as well. It's really a mutual dependency. I don't think we know how many of these sorts of special dependencies exist in ON. Except for the controlled environment of patches, we've always assumed synchronous delivery of everything built in ON as part of our design. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Creating users and SMF services in SVR4 packages with zones
Ralf Weber writes:
or your zone path when the package gets created inside a zone. So I
would rewrite your scripts as:
[...]
${BASEDIR}/usr/sbin/chroot ${BASEDIR} /usr/sbin/groupadd -g 27 mysql
${BASEDIR}/usr/sbin/chroot ${BASEDIR} /usr/sbin/useradd -u 27 -d /var/
lib/mysql -s /bin/false -G mysql mysql
I wouldn't. There's no guarantee at all that $BASEDIR refers to an
instance of the OS that can run at all with the current running
kernel.
In more detail: when you use chroot, the system reads *everything*
from the given base directory, including the system libraries. That
means you'll load up $BASEDIR/usr/sbin/groupadd and try to link in
$BASEDIR/lib/libc.so.1 (among many other things). That library makes
undocumented system calls that in turn depend on the exact rev of the
kernel.
What happens when you do that is arbitrary. It may work, as the
system call interface usually changes slowly, but it may not. It all
depends on the calls made by the application and the nature of the
user/kernel flag days that have passed between these two images.
(Note that Sun's ABI guarantee applies at the ABI level -- meaning the
documented system library interfaces -- and not at the system call
level.)
What you're suggesting isn't supported and can't be supported.
Instead of that, I'd suggest using nawk for now, and adding a call
record to CR 6387333. useradd/groupadd should know how to deal with
alternate roots.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.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] zoneadm confusion
Martin Englund writes: But at the same time, zoneadm boot thinks it is up: [EMAIL PROTECTED] # zoneadm -z jcp-mail-zn-mn-colo1 boot zoneadm: zone 'jcp-mail-zn-mn-colo1': zone is already booted If I try to halt the zone, it just hangs: [EMAIL PROTECTED] # zoneadm -z jcp-mail-zn-mn-colo1 halt ^C (after 10 minutes) Any clues to what is going on? Is there any chance that it's stuck trying to shut down? I'd first look for threads that appear to be stuck in mdb's ::threadlist -v output. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] zoneadm confusion
Martin Englund writes: I get over 10,000 lines of output from ::threadlist -v any hints on how to find the needle in the haystack? :) I usually do ::threadlist -v ! less and then search around in the output. The first suspects are zoneadmd and any longish-looking stacks. (There are more systematic ways to search for the offender, including locating the zone_t and finding out what it's blocked on, but looking at the stacks is often effective and quick.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] DSR
[I've removed the internal address from this reply.] Hidehiko Jono writes: I wonder Explicit-IP zones make this config running. But, Explicit-IP zones make no sense so that CU want to make about 20 zones on each server. You should not need to use exclusive IP stack instances in order to make this work. Ordinary shared stack instances will work fine. In fact, zones really have nothing to do with this. The only thing you need is a load balancer that supports the configuration desired. That's one of the claimed advantages for DSR -- the servers themselves are ordinary IP nodes, and need not know that DSR is going on. (Note that doing load balancing across multiple zones on the same machine, while possible, might not make operational sense.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Making zoneadm more like the other adms...
Darren Reed writes: 2) it would seem the next place worth going is: zoneadm subcommand [all options] 3) but what I'd rather do is: zoneadm subcommand zonename [all-options-except -z] You might want to review the CLIP specification and companion, as the above goal seems to be out of step -- options are supposed to go before the operand, not trailing after: http://opensolaris.org/os/community/arc/caselog/2006/062/spec-clip-html/ I'm not really a fan of CLIP, but I am a fan of consistency. To the degree we can manage it, we shouldn't have individual utilities striking out to explore new command line syntax territory. ...but just maybe that requires (2) to allow for -u. The other thing to say is that any string that is going to be successfully parsed by linuuid(3) is not going to be a normal zonename, therefore no -u is required for zonename to indicate that it is a uuid instead - the string can be passed to libuuid(3) and if it works, we move along. The only problem that poses if someone was expecting zoneadm blah uuid to fail on purpose - but I'd wager that more people would like it to just work than fail. I think that misses part of the point of the compatibility feature in -u. When you supply both -u and -z, we select the zone matching based on UUID first. If there is no such zone, then we select the zone matching based on name. This allows us to deal with the upgrade cases from S10 FCS where there was no UUID. In this new world without option introducers, such a situation would require the user (or script) to supply both the UUID and the zone on the command line, making the syntax a rather confusing: zoneadm subcommand [UUID] [name] I'm still really unclear on what problem we're solving. Is it just that zlogin has a command line that behaves like rlogin (needing no option to select host), and that zoneadm/zonecfg use an option to specify the same thing? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Will exclusive IP allow for TCP /etc/system settings?
Jim Nissen writes: No, asking simply because the Solaris tunables guide list both those TCP settings that are changed via ndd and other that are /etc/system. Customer's asking me if exclusive IP will allow for a NGZ to have its own /etc/system TCP tunables, or if they are global. /etc/system is still global because there's still only one system kernel. That's the essence of zones. /etc/system and ndd are unrelated, which is what confused me here. Except for a few cases where there are mirrored bits (and likely things that are actually bugs), you can't set ndd variables in /etc/system, and you can't set /etc/system variables via ndd, and this is by design. /etc/system works by scribbling on top of kernel storage named by symbols in the object files. It's essentially equivalent to /W in mdb during the boot process -- you're writing directly to a variable, and perhaps even one that's declared static by the original author. ndd is more programmatic. It opens the named device node (e.g, /dev/tcp) and issues an undocumented ioctl. The driver (and any STREAMS modules in between) then gets the ioctl and can decide to do anything it wants with it. Sometimes, it sets a variable somewhere, or perhaps modifies multiple variables. Other ndd ioctls cause other functions to be called, locks to be taken, and other work done. Unlike /etc/system, the possibilities are endless. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Zone with IP address from a different subnet
Steffen Weiberle writes: BTW, this only works for default routes. Static ones don't work. at least that is my/others' experience. That's not true. Default routes are not supposed to be special. They're just regular network routes that happen to have 0/0 as a destination. If you're seeing such a difference, then document it, and file a bug. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Zone with IP address from a different subnet
James Carlson writes: Steffen Weiberle writes: BTW, this only works for default routes. Static ones don't work. at least that is my/others' experience. That's not true. Default routes are not supposed to be special. They're just regular network routes that happen to have 0/0 as a destination. Eh ... nuts. I forgot about the special strangeness around default routes in zones. I still think it's not good, but you're right about that. :- -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] zoneadm boot error message
Ben Rockwood writes: I'm gonna bump this with hopes a developer will pick it up. I do not yet see a bug associated with this issue. You're talking about CR 6684810, which was fixed back in snv_88. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Zone with IP address from a different subnet
Alain Durand writes: and here are the routes seen from the zone : That doesn't look quite right; the route should be visible there because the next hop address is reachable. If needed I could use IP instances (I'm running Solaris 10 Update 5), but have only one physical ethernet interface, is that possible ? Yes, if you can configure a VLAN on this interface using dladm. (I'm guessing that 'vfe' isn't a GLDv3 driver, and thus you can't do that.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Zone with IP address from a different subnet
Alain Durand writes: I built the driver with GLDv3 : # dladm show-link vfe0type: non-vlan mtu: 1500 device: vfe0 What was your idea with a VLAN ? You can create VLANs on that device and place them into exclusive stack zones using zonecfg. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Zone with IP address from a different subnet
Alain Durand writes: Could you please elaborate a bit further ? I must admit I do not really understand what should be done. Something like this: # dladm create-vlan -l vfe0 -v 1 # zonecfg -z blue 'add net; set physical=vfe1000; end' -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Zone with IP address from a different subnet
Alain Durand writes: When the zone boots I get the following error : zoneadm: zone 'tournette': WARNING: skipping network interface 'vfe1000' which is used in the global zone.: Not owner [...] PS : On Solaris 10 Update 5 dladm cannot be used to create vlan's so I used ifconfig vfe1000 plumb up instead. Don't do that in the global zone. It creates the VLAN in the global zone and thus makes it impossible to assign it to the non-global zone. About all I can say at this point is (a) contact Sun's support group for S10 issues (yes, I saw your email address) and (b) this stuff works in current OpenSolaris. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] The quick dirty guide to zones on iSCSI LUNs
Peter Memishian writes: You're assuming the packets sent on this UDP socket all have the same destination and that routing does not change between transmissions. I'm not assuming that, just pointing out that in general there will not be a different source address in each packet, and that for a given destination we latch the source address for long periods of time. That is, one could read your original statement as a promise that we will repeat source address selection for each packet, which is not the case. (And yes, I realize this is an implementation detail. Source address selection algorithms for an unconnected and unbound UDP socket seems entirely like implementation-defined behavior to me.) What I said was this: If you don't explicitly bind a preferred address to use (most applications do not), then the kernel will choose an address for you. With UDP, this happens on a packet-by-packet basis. I don't see how anything you've said actually refutes that, except that you're focussing on packet-by-packet as a kernel implementation detail. The fact that we're caching information or that our cache is currently designed around a single source address per destination is unimportant: at the time each packet is sent, the validity of the cache information is checked, and it's discarded if it's wrong. You, as a user, *may* see the source address change if the destination changes or if anything about the routing used changes. Or if we just get a wild hair and decide to nuke the cache IRE out of spite. It's not predictable or guaranteed in any way, and thus behaves as though it's unstable on a packet-by-packet basis. I can't guarantee that something _will_ change (that doesn't make sense to me ... what if the result of all that effort is exactly the same answer?), but it's certainly the case that you have to expect that it may well change. Nothing really stops it. Strictly from a user's point of view (and not staring at the bowels of the implementation), there is *no* real difference between saying that we redo source address selection on every packet (on the one hand) and saying that we cache the results but throw away those results and get new ones when conditions change. Users can't really tell the difference between those two in any reliable way. The cache isn't a user-level feature. The original question here was about what sort of source selection behavior to expect, and what happens when the wrong routes are present when a TCP connection is attempted. As far as the user is concerned, the answers are (1) you must discard a TCP socket if it fails to connect and you're going to try again and (2) when you try again, you get another roll of the dice as far as forwarding and source selection is concerned. If something new is available, you may well end up using it. The fact that we cache and that our caching has limitations doesn't really enter into that discussion. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] The quick dirty guide to zones on iSCSI LUNs
Ellard Roush writes: James Carlson wrote: That point in time is as soon as your application can start. It need not have any dependencies at all. Here is the other point that needs to be clarified. This is not an application. Applications do not start until much later. We have to get the cluster formed and cluster services established before applications run. We probably have different definitions of that term. For networking, an application is something that uses the services provided by a transport or (for raw sockets) network layer protocol. I'm not talking about user applications; just things that use networking services in some way. Your program (whatever it is) should not need dependencies on networking in order to be successful. As I suggested before, it's sometimes helpful to listen to routing sockets (you can get hints there about when it might be a good time to shorten a retry timer, and thus make your program respond more quickly), but it's not really a dependency issue. The internal interfaces that we had to use are not well documented. Your explanation helps understand what is probably going on. It's hinted at in the documentation, but not as well-documented as it should be. man -s 3socket connect says: underlying transport provider. Generally, stream sockets can successfully connect() only once. Datagram sockets can use [..] ECONNREFUSED The attempt to connect was forcefully rejected. The calling program should close(2) the socket descriptor, and issue another socket(3SOCKET) call to obtain a new descriptor before attempting another connect() call. That generally is also true for most unsuccessful connect() calls and the advice under ECONNREFUSED is actually true for pretty much all failures. The exceptions are the non-failure failures -- EALREADY, EINPROGRESS, and EWOULDBLOCK. I think that issue is what the text is trying to dance around. You're partly connected (at least bound) after the real failures, and getting back to a clean state is easiest just by close() and trying again. The usual references (Stevens and others) have more detailed discussions. The underlying problem is that for much of the BSD world, the code *is* the documentation, so whatever sockets did, well, that's what they do. (For what it's worth, this isn't even one of the darker corners. Raw socket behavior, for example, varies in mysterious ways across OS platforms and even across releases of a given OS.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] The quick dirty guide to zones on iSCSI LUNs
Ellard Roush writes: Thanks for explaining about how the routing situation changes dynamically. However, we have been aware of that for a long time. Sun Cluster (SC) is a High Availability product. We have customers that want recovery to occur in less than 2 seconds. While we have not achieved that goal, we are working in that direction. This means that some operations MUST complete very quickly. A late completion of an operation is a failure. Understood. As a general principle, though, you cannot demand that other systems do anything you want at any other time. When networking is involved, other independent systems are involved. In other words, I think the focus is on the wrong level here. The whole deployment -- the routers, bridges, and other infrastructure included -- must be designed to meet your goal, not _just_ this one bit of Solaris software. (And once that's done, the state of routing in Solaris may or may not be at issue.) More specifically, when a quorum device is unreachable for substantial periods of time, the unreachable quorum device is in a failed state as far as we are concerned. This is true even when the device might be reachable 60 seconds from now. The administrator must configure a quorum device that can be reached reliably in a short time period. The solution is easy at this level: send a packet. If you get a sensible response, then that system is in fact reachable. If you don't get a sensible response within the time constraint that you've set for yourself, then it's not. That's really the only information available. The current SMF information does not even tell us when the Solaris routing software can even accept attempts to communicate. That's correct. As I've already outlined *it doesn't know* and (more importantly) *it cannot in principle know*. Or, if you prefer: it always accepts attempts to communicate. It just won't always be successful in those attempts. We already know that the attempts can fail. Before the routing software in Solaris is ready, all attempts to communicate will fail. We just want to know when it is safe to try. We are not asking for a dependency upon when a specific route is present. We know that is not possible. We have encountered problems when an attempt is made before the routing software is ready. We want to access the quorum device as soon as we can for quicker recovery, but no sooner than can be achieved reliably. There's just no general solution to the problem. If the only thing you care about is whether routing has established a route to somewhere, then (as I mentioned before) you can listen to a routing socket to observe the resulting RTM_ADD. I don't think that'll actually help you in your quest, but it's certainly doable and answers the immediate (and I think improperly formed) question of when routing software in Solaris is 'ready'. For some value of ready, at least. There is simply *NO WAY* that the system can tell you a priori whether an attempt to transmit a packet will actually result in that packet being sent from the system (ARP can still fail and Spanning Tree can disable ports silently) or whether delivery is possible. Only sending data can do that, and only then in retrospect. If you get an answer, then it must have worked. I strongly disagree that we should be offering any sort of routing is ready checkpoint or SMF dependency. It'd be misleading at best, and would result in a new class of unsolvable failure modes. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] The quick dirty guide to zones on iSCSI LUNs
roush writes: No, I have not encountered this problem. The targets mount just in time for my zones. But it sounds to me like a dependency on svc:/network/routing/route:default for cluster could help this along? CT Hi Christine, We have dependencies upon routing. However, this dependency only let's us know when initialization of routing started and does not tell us when things are ready. That's correct, though it's actually worse than that. Fundamentally, it's not possible to build such a dependency. There is no way to know whether you will ever receive any routing information from the other systems out on the network, or whether that information will ever be complete or even sufficient to perform the task you want to do. Ready makes no sense. As a simple (but by no means exclusive) example case that illustrates the problem, let's assume the following: - You're on the 192.168.0.0/24 network. This network using RIP-2 for routing. - There's a router located at 192.168.0.1. This router advertises the default route, because it connects to most of the rest of the networks in the area, and knows how to reach the (off-link) NAT to get to the wider Internet. - There's another router located at 192.168.0.2. This router advertises only a route to 10.0.0.0/24, because that's the only other interface it has. For simplicity, 192.168.0.2 is the only path to 10.0.0.0/24. - The router at 192.168.0.1 reaches 10.0.0.0/24 via 192.168.0.2. In other words, your local 192.168.0.0/24 network is also used for some internal transit traffic; it's not just a simple stub. Now suppose the server you want to reach is at 10.0.0.1. If 192.168.0.2 is down, you won't be able to get there because the only path is cut. A strictly dependency-based check, though would suggest that you *can* get there. After all, not only does routing come up on your local system, but you also hear a default route from 192.168.0.1. As far as dependency checking can go, you've got everything you need. Your packets, though, would end up errantly matching the default route, being sent via 192.168.0.1, and then either dropped silently, replied-to with ICMP Destination Unreachable, or perhaps even with a redirect to the unusable 192.168.0.2 router (because redirects stink as a routing protocol ;-}). In any event, you can't get there from here. In other words, by talking about such a dependency, I believe you're really asking the wrong question. The only dependency a networking application ought to have should be: is the networking stack initialized? And even that one (in a perfect world) ought to be a simple yes at all times. The right questions are: How do I set up a retry algorithm? Are there any ways to get hints for retries? If you're using TCP or SCTP, then the transport layer itself does the retries. You don't need to mess about with it; just let it do its job. At most, you need an application-layer retry, but that ought to be a fairly long timer: there's not much reason to pester a broken network with useless packets. For the second question, you can listen to a routing socket if you want. You'll get notified of routing changes, and these (particularly RTM_ADD) may well signal a good time to schedule another connection attempt. Any time the dependency lines on the graph extend outside the confines of the box, we need to be very careful. Networking is _not_ the same as system design, and SMF addresses only the latter. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] dhcp/zones
Caroline Carol writes: Can you please let me know if DHCP works on local zones NOW ??? It's worked for quite some time now. You need to set up your non-global zones using set ip-type=exclusive. Is there any patch that fix this problem ??? OpenSolaris doesn't have patches. What are you running? If you're using Solaris 10, you should be contacting Sun's support group instead. (I believe IP Instances went into Solaris 10 Update 4, but, unlike OpenSolaris, some Ethernet drivers are not supported, and you may need patches for others.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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 : Re: dhcp/zones
elkhaoul elkhaoul writes: Thanks for your answer. I am using Solaris 10 U4 8/07 That's not OpenSolaris. You should be contacting your local Sun support folks so that they're in the loop on what you're doing and can provide advice. And my interface is : ### dladm show-link ce0 type: legacymtu: 1500 device: ce0 ce1 type: legacymtu: 1500 device: ce1 Is this interface support exclusive IP ? With the right patches, yes. You need the patches for CRs 6616075 and 6606507, which I think are 137042-01 and 118777-12 for SPARC. But since you're not using OpenSolaris, you should be working with your local support folks on that rather than an OpenSolaris-related mailing list. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Lost network connectivity and NIC recognition
Anne Moore writes: I am definitely using OpenSolaris as that's what I downloaded and installed, (excuse me if it's not called 10). I was trying to find out which one you actually have. Solaris 10 and OpenSolaris are different entities. it sounds like you need some local support I feel sorry for you James. It appears you must put people down to feel better about yourself. Why not go to a shrink for help?! I wasn't trying to put you down at all. I'm sorry if it sounded that way in email. I was suggesting that if you have Solaris 10 (which it sounded to me like you did -- many Solaris 10 users errantly think they're using OpenSolaris, and I've never heard of an OpenSolaris user refer to his or her system as 10), then you ought to contact a local Sun support person. That's what support is for. Next time, ask a real engineer before you respond. Ah, well, time to turn in that worthless sheepskin, I guess. :-/ As for the unexpected results on sys-unconfig, did it ask you any questions at all on boot-up? If this really is OpenSolaris, which one is it exactly? There are multiple distributions, each with many different builds. Narrowing down the field seems like the first obvious step. Is it perhaps Indiana? If so, then you should be contacting that project team directly. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] How to configure Global/Local zone in seperate subnet and use seperate router
Mike Gerdts writes: On Tue, Mar 4, 2008 at 3:31 AM, Enda O'Connor [EMAIL PROTECTED] wrote: Hi For the ce driver you will need 137042-01 SPACR 137043-01 X86 which fix CR 6616075 ( ON Part ) as well as 118777-12 SPARC 118778-12 x86 which fix CR 6606507 the ce driver side. Keep in mind that to use exclusive IP's each zone will need its own physical network. That is if you have a network used only by the global zone and a different network shared by two or more non-global zones, you will need to have a physical network interface per non-global zone. Almost. You need a separate VLAN to assign for each zone. The exclusive IP feature allows you to put a VLAN into a zone, not the whole physical interface. The distinction is a bit confusing because the default VLAN for an interface is effectively ID zero -- no VLAN header at all, as long as no CoS bits are set -- and that can be placed into a non-global zone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] different MAC addresses
Caroline Carol writes: Is it possible to configure local zones with a differnt MAC address ? No. With the same MAC as in global, and in the same VLAN, spanning tree encounter problems in the Network I'm not sure I follow. In all cases, with respect to the Spanning Tree protocol, we're simply an end node. We don't (currently) bridge any packets, nor do we emit any BPDUs. Shared-stack (ordinary) zones use only alternate IP addresses. They're exactly equivalent to assigning multiple IP addresses per interface, as before you could zones with ifconfig's addif command. It's purely an IP concept, and link-layer issues aren't involved. Exclusive-stack zones allow zones to take possession of a VLAN, but even in that case, there's nothing that's different from a system without zones. In other words, you can create VLANs on a system with no zones configured at all (only the default global zone), and the network will be unable to tell the difference in the packets we send versus a system with non-global zones configured. As far as Spanning Tree is concerned, end nodes like us don't exist (because we cannot form L2 forwarding loops) and IP has nothing to do with the way in which bridging works, so how do zones cause problems? Or what problems do you specifically see? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] dhcp/zone
Robert Milkowski writes: Hello Zoram, Tuesday, December 11, 2007, 9:41:13 AM, you wrote: ZT IIRC, you need to have ip-type=exclusive to have DHCP work in a ZT non-global zone. Currently ce doesn't support exclusive IP stack, but I ZT remember seeing an RFE somewhere that'd allow exclusive/ce combo. ZT Perhaps this has already been fixed in Open Solaris, I'm not sure. IIRC someone from Sun wrote some time ago it won't rather happen (GLDv3 version of ce) - unfortunately. I think you're confusing two things. One is the conversion of 'ce' to GLDv3. That might or might not happen -- I know of at least one person who is quite interested in it, but I don't know whether the work will get done. Given the number of ... special ... features in that driver, it'd be an interesting job to say the least. The other is the support of the ioctls necessary for assignment of links to a zone, which is needed to support the exclusive IP stack feature, and the tweaks to zoneadmd to make it work. This *HAS* been done and is on a path for release. In S10 currently, the only framework that supports the feature is GLDv3, which is why the exclusive IP stack is tied to GLDv3 support. But non-GLDv3 drivers can also be modified (with some difficulty) to support the feature, and that's what's being done for 'ce.' -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] dhcp/zone
Ihsan Zaghmouth writes: James Carlson wrote: There is an interesting support issue for Trunking and/or Aggregation that needs to be addressed to support of ce and ge by GLDV3. Indeed. Solaris Trunking 1.3 does support ce and ge, unlike Solaris 10 Aggregation (dladm). Since dladm is the focus for future network administration among all the other features builtin for supporting IP-instances, where Aggregation is a sub function of, isn't it prudent to be strategic reason to push for the support of ce and ge by GLDV3 ? That'd be one good way to do it. The other way is via Clearview's UV shim layer, which will eventually make legacy DLPI devices appear to be GLDv3 drivers. I'd rather see these old drivers ported over to the new framework, but that's a cost/benefit analysis that others (partly the maintainers of the driver) need to make. (And, unfortunately, many of these old drivers are closed-source, so it's harder to find people to help out.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] exclusive-ip
Robert Smicinski writes: We have the same problem, none of our interfaces show up on ce's, bge's, qfe's or ge's on sparc. It does work on one of our x86 machines though. Maybe it's related to sparc? It's not SPARC that's the problem. The problem is that the IP Instances feature (exclusive-ip) currently supports only GLDv3 interfaces. Any interface implemented using GLDv3 will work, regardless of platform. ce, qfe, and ge are (or at least _were_) monolithic DLPI designs, not GLD-based. It's also pretty important to know that version matters here, so describe the system you're using. Quite a few changes have gone into OpenSolaris-based distributions that haven't gotten back (and may never get back) to S10. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] exclusive-ip
Robert Smicinski writes: I don't see that reference in the Sun What's New Solaris 10 8/07 Release: http://docs.sun.com/app/docs/doc/817-0547/6mgbdbsoa?l=ena=viewq=ip+instances I don't see a reference to the issue there, either. I think that's probably a documentation bug. The issue is with the design of the driver. If it uses GLDv3, then zoneadmd can issue a special new ioctl to move the link into the zone. If it doesn't use GLDv3, then that doesn't work. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Whole root or sparse one ?
elkhaoul elkhaoul writes: What's model is generally used to set up zone ? Whole root or sparse model ? Thanks a lot for your answer. You may need to provide more details to get a more coherent answer, but the _default_ for zonecfg is to create a sparse-root model zone. You have to delete the inherit-pkg-dir entries to create a whole root zone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] netmask warning, misconfiguration
Jordan Brown (Sun) writes: OTOH, I don't immediately understand how the example can work. It says that 128.32.*.* (except for the exclusions) gets a 24-bit netmask, but I don't see how that can be unambiguously determined. The example *seems* to want to explicitly specify a 28-bit netmask for several ranges and a 24-bit netmask for the rest, but how can it distinguish between requesting that 128.32.*.* is all 24-bit and requesting that 128.32.0.* is all 24-bit? (For that matter, why isn't it specifying that 128.001?.*.* is 24-bit?) It doesn't always work very well, which is why I generally recommend against /etc/netmasks. It may have been an ok interface 20 years ago, but with CIDR, it's mostly a defect looking for a place to happen. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Shared-ip routing and VNI interface
Paul Van Der Zwan writes: I'm having a problem figuring out why my ping replies never get sent. There's no way for any of your configured zones to transmit, so they don't. Vni is really not much different from lo0. You cannot transmit packets on vni -- it's just a place to hang a local IP address. That's why they say NOXMIT when you configure them. The global zone has 192.168.200.14 configured on bge0 You need to give your zones access to bge0 if you want them to transmit there. You give access by assigning an address on that interface. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] Shared-ip routing and VNI interface
Paul van der Zwan writes: service address=10.1.1.1 default gateway=192.168.1.254 zone1 on host1 has 192.168.1.1 on bge0 and 10.1.1.1 on vni0 zone1 on host2 has 192.168.1.2 on bge0 and 10.1.1.1 on vni0 That looks like a variant on the original design target for vni, so I'd expect it to work. The loadbalancer routes 10.1.1.1 traffic for session1 to 192.168.1.1 Would traffic from zone1 be able to go out to the internet using the default gateway 192.168.1.254 with a source of 10.1.1.1 or would the source become 192.168.1.1 ( even if the application binds to 10.1.1.1 ) ? Yes, it should be able to reach that router because the configuration of bge0 in the zone gives it access to that subnet. No, the system never alters a chosen source address. The only time we ever pick a source address is when the application itself has not chosen one -- either it hasn't called bind() at all, or it has called bind() and supplied an all-zeros address. Is there some documentation on the routing in Solaris 10 esp. in combination with zones ? Besides the man pages and docs.sun.com, there's some useful information in the FAQ: http://www.opensolaris.org/os/community/zones/faq/#cfg_io -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] b75 ip-instances bug?
John-Paul Drawneek writes: Network can ping the zones and global zone zones and global zone can't ping each other Unless there's some external router that forwards traffic between the zones, you won't be able to communicate between exclusive stack instance zones. That's sort of the point. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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] carry forward mount points from global to non-global zones
Sengor . writes: Something like this in zonecfg should do the trick: add fs set dir=/mnt set special=/mnt set type=lofs add options rw No, I wouldn't expect that to work. That'll export just the /mnt directory itself (read-write to the non-global zone!). Any sub-mounts that appear there will not be mirrored into the zone, because lofs doesn't cross mount points. There currently isn't a mechanism that will do exactly what the original poster asked. The individual mounts would need to be replicated in each zone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.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
