I'd agree with James, the update revision is sometimes a blurry picture,
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
ie pca -l missing
or the like, pca being a solaris patch automation tool from
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