Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
Jeff, I am wondering about the logic in how the script identifies specific versions. It appears that you are looking at /etc/release to define this. This seems to limit some features of your script because I have a Solaris 10 update 1 system that has been updated to 05/08 (update 5) but /etc/release still reflects update 1 (updated using 05/08 patch bundle). I am using CPU caps but your tool doesn't recognize that I have that feature available. Since these features really come from the kernel version, would that be a better way to identify release version in your script; Just a thought. In the meantime I tricked the script to think I am on update 5 and I am getting better results. -= Kevin =- -Original Message- From: Jeff Victor [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 9:01 AM To: Young, Kevin Cc: zones-discuss@opensolaris.org Subject: Re: [zones-discuss] Zone Statistics: monitoring resource use of zones On Mon, Nov 10, 2008 at 11:21 AM, Young, Kevin [EMAIL PROTECTED] wrote: I am curious if you have plans to make it Solaris 10 compatible. I do all development on Solaris 10. The script makes an effort to distinguish between the different capabilities of the different Solaris 10 updates. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Victor Sent: Sunday, November 09, 2008 5:54 PM To: zones-discuss@opensolaris.org Subject: [zones-discuss] Zone Statistics: monitoring resource use of zones It has become clear that there is a need to monitor resource consumption of workloads in zones, and an easy method to compare consumption to resource controls. In order to understand how a software tool could fulfill this need, I created an OpenSolaris project and a prototype to get started. If this sounds interesting, you can find the project and Perl script at: http://opensolaris.org/os/project/zonestat/ . If you have any comments, or suggestions for improvement, please let me know on this e-mail list or via private e-mail. -- --JeffV ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
On Sun, Nov 16, 2008 at 10:58 PM, Mike Gerdts [EMAIL PROTECTED] wrote: On Sun, Nov 16, 2008 at 7:40 PM, Jeff Victor [EMAIL PROTECTED] wrote: To me, the clearest example would be a kstat, per zone, which provides the total amount of CPU time for all of the processes in each zone, since the zone booted. This would enable tools like zonestat to request the datum occasionally, in order to determine CPU time per quantum of elapsed time. zonestat shouldn't be needed to give this information. Of course. I guess I wasn't clear. I was trying to say the clearest example of a kstat that is needed is a kstat, per zone... That kstat could then be used by many *stat tools, including zonestat, prstat, etc. Per zone, project, and user data should be available that allows prstat to display this information. When I use prstat -mz or prstat -ma, I would expect the collected microstate accounting data would be used to populate the display. Other fine points about this include: - Currently prstat shows time decayed summaries in the bottom panel, even when microstate data is displayed at the top. Time decayed data is confusing, particularly when trying to correlate application events that last just several seconds to CPU consumption. Not only is it confusing, it can be very wrong, e.g. if there are many short-lived processes that come and go between the snapshots that prstat takes. That's why a kstat like the one described above is needed. --JeffV ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
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. 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. 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 example, is the feature not present or has it been removed or simply not 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. It sounds like you may be in a similar boat. What do you think? Cross-posting to security-discuss to get their feedback as well. g Jeff Victor wrote: Hi Kevin, I believe that you cannot patch your way from U1 to U5 - i.e. that the system is missing some functionality that would be there if you had applied the updates - but your point is still valid. I will look into the correctness of using patch levels to detect feature availability. On Mon, Nov 17, 2008 at 6:09 PM, Young, Kevin [EMAIL PROTECTED] wrote: Jeff, I am wondering about the logic in how the script identifies specific versions. It appears that you are looking at /etc/release to define this. This seems to limit some features of your script because I have a Solaris 10 update 1 system that has been updated to 05/08 (update 5) but /etc/release still reflects update 1 (updated using 05/08 patch bundle). I am using CPU caps but your tool doesn't recognize that I have that feature available. Since these features really come from the kernel version, would that be a better way to identify release version in your script; Just a thought. In the meantime I tricked the script to think I am on update 5 and I am getting better results. -= Kevin =- -Original Message- From: Jeff Victor [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 9:01 AM To: Young, Kevin Cc: zones-discuss@opensolaris.org Subject: Re: [zones-discuss] Zone Statistics: monitoring resource use of zones On Mon, Nov 10, 2008 at 11:21 AM, Young, Kevin [EMAIL PROTECTED] wrote: I am curious if you have plans to make it Solaris 10 compatible. I do all development on Solaris 10. The script makes an effort to distinguish between the different capabilities of the different Solaris 10 updates. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Victor Sent: Sunday, November 09, 2008 5:54 PM To: zones-discuss@opensolaris.org Subject: [zones-discuss] Zone Statistics: monitoring resource use of zones It has become clear that there is a need to monitor resource consumption of workloads in zones, and an easy method to compare consumption to resource controls. In order to understand how a software tool could fulfill this need, I created an OpenSolaris project and a prototype to get started. If this sounds interesting, you can find the project and Perl script at: http://opensolaris.org/os/project/zonestat/ . If you have any comments, or suggestions for improvement, please let me know on this e-mail list or via private e-mail. -- Glenn Brunette Distinguished Engineer Director, GSS Security Office Sun Microsystems, Inc. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
On Mon, Nov 17, 2008 at 7:44 PM, Jeff Victor [EMAIL PROTECTED] wrote:
Hi Kevin,
I believe that you cannot patch your way from U1 to U5 - i.e. that the
system is missing some functionality that would be there if you had
applied the updates - but your point is still valid. I will look into
the correctness of using patch levels to detect feature availability.
Huh? There are very few features delivered in Solaris updates that
aren't delivered via patches. So few that I can only think of one
time where it has made a difference (postgres version different
between updates). When really important features are released as new
packages genesis patches are delivered to deliver the feature. This
is how the U1 + patches system below has zfs on it even though zfs
didn't come out until U2.
All of the functionality that this script cares about for this comes
as part of the recommended patch set. Consider this system:
# cat /etc/release
Solaris 10 1/06 s10s_u1wos_19a SPARC
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 07 December 2005
# uname -rv
5.10 Generic_127111-09
That puts it somewhere in between U4 and U5 for kernel patches.
Because the recommended bundle was used, it puts it somewhere in
between for other aspects (e.g. libzonecfg, etc.) as well. Let's take
a look at the checks that zonestat does for updates:
356 # For zones with RAM caps (U4+), get current values for RAM
usage and Cap.
357 if ($update3) {
358open (RCAP, /usr/bin/svcs -H rcap|);
# svcs -H rcap
disabled May_03 svc:/system/rcap:default
Exists but disabled.
440 if ($update4) {
441open(PRCTL, /bin/prctl -Pi zone -n zone.cpu-cap $z|);
442while (PRCTL) {
Not at update 5's kernel and related patch set yet, so I wouldn't
expect that this would work. However, let's take a look at another
system that was installed with update 4 but has update 5+ patches.
# cat /etc/release
Solaris 10 8/07 s10s_u4wos_12b SPARC
Copyright 2007 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 August 2007
# uname -rv
5.10 Generic_137111-08
# prctl -Pi zone -n zone.cpu-cap
zone: 3:
zone.cpu-cap system 4294967295 inf deny -
--
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Statistics: monitoring resource use of zones
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. 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?) -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
