6/06 -> 11/06 with patches
in [Solaris]
|
From: Miroslav Zubcic on 24 Dec 2006 10:02 Lion-O wrote: >> I had thought that I could get from Solaris 10 6/06 to Solaris 10 11/06 >> (or equivalent functionality, at least) via patches. It seems not to be >> the case, since I don't have everything: >> >> bash-3.00# cat /etc/release >> Solaris 10 6/06 s10s_u2wos_09a SPARC >> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. >> Use is subject to license terms. >> Assembled 09 June 2006 > > Well, you assume wrong. I've got Solaris 10/x86 running for some time now and > got myself a service contract (for $120/yr; get access to *everything* on > SunSolve without the overhead of guided support (I can usually fix my own > problems ;))) and this is happening on my system: > > magi:/home/peter $ cat /etc/release > Solaris 10 3/05 s10_74L2a X86 > Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 22 January 2005 > magi:/home/peter $ man zfs | wc -l > Reformatting page. Please Wait... done > 1650 > > So; a 03/05 release with ZFS support, how do you like that? :-) Hmmm. # pkgchk -lP /usr/share/man/man1m/zfs.1m | grep SUNW SUNWman Do you have zpool and zfs commands? which zfs zpool > For some reason /etc/release isn't changed so you'll remain on that same pkgrm SUNWsolnm mount -F hsfs `lofiadm -a /export/software/iso/sol-10-u3-ga-x86-dvd.iso` /mnt cd /mnt/Solaris_10/Product pkgadd -d . SUNWsolnm Of course, if your system is really update #3. -- Man is something that shall be overcome. -- Friedrich Nietzsche
From: Alan Coopersmith on 29 Dec 2006 01:56 Rich Teer <rich.teer(a)rite-group.com> writes in comp.unix.solaris: |Thinking about it a bit more, isn't the rule something like patches |can only change existing packages, not install new ones? Yes, but rules can be broken when needed. -- Alan Coopersmith * alanc(a)alum.calberkeley.org * Alan.Coopersmith(a)Sun.COM http://blogs.sun.com/alanc/ * http://people.freedesktop.org/~alanc/ http://del.icio.us/alanc/ * http://www.csua.berkeley.edu/~alanc/ Working for, but definitely not speaking for, Sun Microsystems, Inc.
From: Rich Teer on 29 Dec 2006 10:24 On Fri, 29 Dec 2006, Alan Coopersmith wrote: > Rich Teer <rich.teer(a)rite-group.com> writes in comp.unix.solaris: > |Thinking about it a bit more, isn't the rule something like patches > |can only change existing packages, not install new ones? > > Yes, but rules can be broken when needed. Indeed; in fact, isn't that the first rule? :-) -- Rich Teer, SCNA, SCSA, SCSECA, OpenSolaris CAB member . * * . * .* . . * . .* President, * . . /\ ( . . * Rite Online Inc. . . / .\ . * . .*. / * \ . . . /* o \ . Voice: +1 (250) 979-1638 * '''||''' . URL: http://www.rite-group.com/rich ******************
From: Horst Scheuermann on 5 Jan 2007 07:57 "Daniel Rock" <v200651(a)deadcafe.de> writes: > But these are all Solaris 10 examples. I don't have a Solaris 8/9 system here > so I cannot check these. until Solaris 9 they had Mandatory Update Patchclusters, an upgrade in the same release was as simple a to install the recommended Patchcluster.
From: Tim Bradshaw on 5 Jan 2007 09:03
Rich Teer wrote: > So I think that although it's true that SOME (or even many) new > features become available in the form of patches, I don't think > ALL new features become available via patches. > I'd like to argue that, for patches that might get automatically applied (via PCA or whatever horror Sun want us to use this week) then it's generally rather undesirable that new features get introduced. It should be the case that it's mostly-safe to patch a production machine, in the sense that you only need to check that existing things have not been broken, not that new things have appeared. (A gratuitous example might be some new network daemon appearing, with default settings which were not safe. For instance if patches moved a system from one DHCP server to another, which used different configuration files and left the machine with some wide-open DHCP daemon. I'm sure Sun haven't done this particular thing and would not do so, but you get the idea.) Of course patches which won't get automagically dragged in are a different case. All this leads on to some notion of classifying patches etc in some principled way, which I'm not sure is really done, though I confess to not having checked recently. This would allow, for instance, patches which are very urgent (fixing critical public flaws) to be released with almost no testing (for instance, on the same day the vulnerability/exploit is discovered) and for people using automated patch tools to be able to say which patches they want, along the lines of: "I only want fully tested patches *unless* they fix security issues with severity greater than x in packages a,b,c..". (Again a gratuitous example of this: I'd rather take a patch for a critical sendmail vulnerability from Sun even if it had basically no testing than the alternative which is probably to build my own sendmail and doom myself to a life in torment.) I once had a fairly fully worked-out scheme for doing this, but I think I've lost the document that described it (it was almost literally the back of an envelope, I think actually the back of some course materials). --tim |