Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
Mike, Mike Gerdts wrote: On Mon, Nov 17, 2008 at 8:05 PM, Glenn Brunette [EMAIL PROTECTED] wrote: Jeff, 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. This seems to be another case for feature-based meta packages. http://mgerdts.blogspot.com/2008/03/solaris-wish-list-feature-based-meta.html I describe it for the simplicity of installing software, but with a bit of thought it could be possible to extend it to this use as well. Very similiar indeed. While this may work with the big items that qualify as features, I am not sure if this would be stretching the metaphor a bit for smaller components, but you and I are definitely thinking in a similar vein. In a past life working on JASS, we were told to not test for patch or update levels but rather to test whether a specific feature is present, and while I understand the merits of this methodology, it does not always provide a complete solution (without making significant assumptions about how the system was installed/maintained). For As a very heavy user of JASS, this methodology is appreciated. It has made the software continue to be quite useful long after Sun stopped providing updates. (Any news on open sourcing it?) Thank you! As far as news on JASS, all that I can say for now is stay tuned. There is a lot of discussion happening on this front these days, and I hope we will have some news to share soon. g ___ 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 wrote: When really important features are released as new packages genesis patches are delivered to deliver the feature. Sometimes, but not always. In fact, I'd have to say usually not. The Genesis technique is not without its problems, and is considered controversial. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
Hi I'd agree with James, the update revision is sometimes a blurry picture, ie cat /etc/release will tell me that my system is 1/06 ( update 1 if I remember correctly ) but if I have applied the latest jumbo kernel patch 137137-09 I essentially have a lot of the u6 functionality ( a lot but not all .. ) so is the system u1 or u6? I tend to say it's u1 patched to u6 kernel, so as to give some idea of the start point and current point, but other than cat /etc/release ( the starting point ) uname -a to give current KU level and ls -tr1 /var/sadm/patch to see patches applied besides current KU plus patchadd -p to just get every patch including patches that are part of the update build. So sometimes an update might be meaningless, ie I can have an x86 FCS system ( from cat /etc/release ) but it has grub,zfs and all the latest zones functionality, just by adding 137137-09, plus the near 30 patches requires to get that on board. 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. ie pca -l missing or the like, pca being a solaris patch automation tool from http://www.par.univie.ac.at/solaris/pca/ Enda On 11/18/08 13:58, James Carlson wrote: 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. -- Enda O'Connor x19781 Software Product Engineering Patch System Test : Ireland : x19781/353-1-8199718 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
On Tue, Nov 18, 2008 at 11:30 AM, Enda O'Connor [EMAIL PROTECTED] wrote: So sometimes an update might be meaningless, ie I can have an x86 FCS system ( from cat /etc/release ) but it has grub,zfs and all the latest zones functionality, just by adding 137137-09, plus the near 30 patches requires to get that on board. 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? 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. The important (worthy of marketing or release notes attention) could get a corresponding feature-based meta package, allowing administrators to easily install the feature. http://mgerdts.blogspot.com/2008/03/solaris-wish-list-feature-based-meta.html A nice extension on that would be a means to for software to register as a consumer of the interface. Perhaps that is just a soft dependency in the packaging software. Another thought would be to add dtrace probes at the entry points to the interfaces so that a interface watch daemon could track interface users (e.g. by using process contract decorations). -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Issue with zone upgrade on attach
Christophe Dupre wrote: Hello, we're having an issue migrating a zone from one server to another. Server A has Solaris 10 x86 05/08 and hosts zone X (spare-root zone). Server B has just been acquired and installed with Solaris 10 x86 10/08 and hosts a number of zones created locally. We would like to move zone X from A to B. We have done a 'zoneadm -z X detach' on A, then did a tar of the zonepath to send it to server B. On server B, we created a zfs /zones/X where we untarred the zone. Then: zonecfg -z X create -a /zones/X zoneadm -z X attach -u This gives: zoneadm: zone 'X': ERROR: attempt to downgrade package SUNWcsr, the source had patch 125098-14 which is not installed on this system From what I can tell, 125098-14 was part of 05/08, not a patch we added to the system after initial setup, and not something we can download. Does anyone have a solution for this ? How can I migrate my zone ? This is bug: 6743776 zone update on attach should ignore all special patches This is escalated and a patch is being developed. The workaround is in the bug report (the workaround is actually the fix). It updates the /usr/lib/brand/native/bad_patches file. You can manually do this as well. Jerry ___ 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] Issue with zone upgrade on attach
Thanks Jerry for the quick reply. I am making progress, but no cigar (yet). Now I have: zoneadm: zone 'X': ERROR: attempt to downgrade package SUNWgtar, the source had patches but this system does not It does not give me a patch number, so I can't add it to the bad_patches file. Or maybe it does ? Is there a list of patches I should add to bad_patches for this to work ? The workaround mentions an attached file, but I don't see it. Thanks, Christophe Dupre -Original Message- From: Jerry Jelinek [mailto:[EMAIL PROTECTED] Sent: Tue 2008-11-18 13:58 To: Christophe Dupre Cc: zones-discuss Subject: Re: [zones-discuss] Issue with zone upgrade on attach Christophe Dupre wrote: Hello, we're having an issue migrating a zone from one server to another. Server A has Solaris 10 x86 05/08 and hosts zone X (spare-root zone). Server B has just been acquired and installed with Solaris 10 x86 10/08 and hosts a number of zones created locally. We would like to move zone X from A to B. We have done a 'zoneadm -z X detach' on A, then did a tar of the zonepath to send it to server B. On server B, we created a zfs /zones/X where we untarred the zone. Then: zonecfg -z X create -a /zones/X zoneadm -z X attach -u This gives: zoneadm: zone 'X': ERROR: attempt to downgrade package SUNWcsr, the source had patch 125098-14 which is not installed on this system From what I can tell, 125098-14 was part of 05/08, not a patch we added to the system after initial setup, and not something we can download. Does anyone have a solution for this ? How can I migrate my zone ? This is bug: 6743776 zone update on attach should ignore all special patches This is escalated and a patch is being developed. The workaround is in the bug report (the workaround is actually the fix). It updates the /usr/lib/brand/native/bad_patches file. You can manually do this as well. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Issue with zone upgrade on attach
Hi Christophe In the zone being attached: zonepath/root/var/sadm/pkg/SUNWgtar/pkginfo file there should be an entry for PATCHLIST= could I see this, and also the one from the target system's global zones pkginfo. Enda Christophe Dupre wrote: Thanks Jerry for the quick reply. I am making progress, but no cigar (yet). Now I have: zoneadm: zone 'X': ERROR: attempt to downgrade package SUNWgtar, the source had patches but this system does not It does not give me a patch number, so I can't add it to the bad_patches file. Or maybe it does ? Is there a list of patches I should add to bad_patches for this to work ? The workaround mentions an attached file, but I don't see it. Thanks, Christophe Dupre -Original Message- From: Jerry Jelinek [mailto:[EMAIL PROTECTED] Sent: Tue 2008-11-18 13:58 To: Christophe Dupre Cc: zones-discuss Subject: Re: [zones-discuss] Issue with zone upgrade on attach Christophe Dupre wrote: Hello, we're having an issue migrating a zone from one server to another. Server A has Solaris 10 x86 05/08 and hosts zone X (spare-root zone). Server B has just been acquired and installed with Solaris 10 x86 10/08 and hosts a number of zones created locally. We would like to move zone X from A to B. We have done a 'zoneadm -z X detach' on A, then did a tar of the zonepath to send it to server B. On server B, we created a zfs /zones/X where we untarred the zone. Then: zonecfg -z X create -a /zones/X zoneadm -z X attach -u This gives: zoneadm: zone 'X': ERROR: attempt to downgrade package SUNWcsr, the source had patch 125098-14 which is not installed on this system From what I can tell, 125098-14 was part of 05/08, not a patch we added to the system after initial setup, and not something we can download. Does anyone have a solution for this ? How can I migrate my zone ? This is bug: 6743776 zone update on attach should ignore all special patches This is escalated and a patch is being developed. The workaround is in the bug report (the workaround is actually the fix). It updates the /usr/lib/brand/native/bad_patches file. You can manually do this as well. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Issue with zone upgrade on attach
Christophe Dupre wrote: Thanks Jerry for the quick reply. I am making progress, but no cigar (yet). Now I have: zoneadm: zone 'X': ERROR: attempt to downgrade package SUNWgtar, the source had patches but this system does not It does not give me a patch number, so I can't add it to the bad_patches file. Or maybe it does ? Is there a list of patches I should add to bad_patches for this to work ? The workaround mentions an attached file, but I don't see it. We will be improving some of the error messages for update on attach so that you get better info on this sort of thing. However, this might not be a bad patch problem. What were the patches for this pkg on the original system? I think if you get the data Enda requested then we can tell if there is another troublesome 'special' patch or just a missing patch. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Issue with zone upgrade on attach
From the global zone: PATCHLIST= From zone being attached: PATCHLIST=139100-01 So I guess I need to install 139100-01 in the new server's global zone ? That makes sense - the original server was 05/08 but had received a recommended cluster in early october, so it is probable that it received some patches that were not rolled into 10/08. Hopefully, the error messages will be improved to provide a hint of what the problem is. Enda O'Connor wrote: Hi Christophe In the zone being attached: zonepath/root/var/sadm/pkg/SUNWgtar/pkginfo file there should be an entry for PATCHLIST= could I see this, and also the one from the target system's global zones pkginfo. Enda Christophe Dupre wrote: Thanks Jerry for the quick reply. I am making progress, but no cigar (yet). Now I have: zoneadm: zone 'X': ERROR: attempt to downgrade package SUNWgtar, the source had patches but this system does not It does not give me a patch number, so I can't add it to the bad_patches file. Or maybe it does ? Is there a list of patches I should add to bad_patches for this to work ? The workaround mentions an attached file, but I don't see it. Thanks, Christophe Dupre -Original Message- From: Jerry Jelinek [mailto:[EMAIL PROTECTED] Sent: Tue 2008-11-18 13:58 To: Christophe Dupre Cc: zones-discuss Subject: Re: [zones-discuss] Issue with zone upgrade on attach Christophe Dupre wrote: Hello, we're having an issue migrating a zone from one server to another. Server A has Solaris 10 x86 05/08 and hosts zone X (spare-root zone). Server B has just been acquired and installed with Solaris 10 x86 10/08 and hosts a number of zones created locally. We would like to move zone X from A to B. We have done a 'zoneadm -z X detach' on A, then did a tar of the zonepath to send it to server B. On server B, we created a zfs /zones/X where we untarred the zone. Then: zonecfg -z X create -a /zones/X zoneadm -z X attach -u This gives: zoneadm: zone 'X': ERROR: attempt to downgrade package SUNWcsr, the source had patch 125098-14 which is not installed on this system From what I can tell, 125098-14 was part of 05/08, not a patch we added to the system after initial setup, and not something we can download. Does anyone have a solution for this ? How can I migrate my zone ? This is bug: 6743776 zone update on attach should ignore all special patches This is escalated and a patch is being developed. The workaround is in the bug report (the workaround is actually the fix). It updates the /usr/lib/brand/native/bad_patches file. You can manually do this as well. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
