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
