n.b.: I think we need a new subject header.
> Jason Ozolins wrote:
>> Umm, I think we're writing at cross purposes here... you don't do a
>> Solaris _upgrade_ to a running OS instance. Live upgrade,...but in
>> either cases, you aren't running services from the OS instance that
>> is being upgraded, which is the case I'm interested in. If I want
>> to (topical example) upgrade the Solaris telnet daemon on a running
>> system, I'll be installing a _patch_, not performing a package upgrade.
>
>
> Patches are (under the covers) simply collections of sparse
> packages; most of which require you to be running in single
> user mode so that all those running processes are in fact
> explicitly /not/ running.
**** WARNING : Herein Lies Preaching to the Choir ****
It is generally a really good idea to be in single user mode or at
least in a really quiet state. I have patched systems in full multi-user
mode ( init 3 ) but only after I toss out all users, lock them out to
keep them out, and shut down all network daemons, drop NFS mounts, kill
the power daemon as well as anything else remotely questionable. After
all of that I still get a very successful patch process as well as a
kernel update *BUT* you do need to touch /reconfigure and then reboot.
I do that under duress and only when there is no way to get access to
the console. Thankfully LOM makes that a silly old thing. Even four and
five year old PC gear can have the console redirected to TTYA.
In any case, what I am saying here is that you take your own server
stability into your own hands if you do not drop down to single user mode.
> When you install the telnet patch, patchadd simply[1] uses
> pkgadd to do an overwrite-install of the package containing
> a new telnetd binary[2].
cool .. I have no problem with that.
> If you do this on a system running multi-user, and are lucky,
don't do that. see above .
> telnetd will drop a core when the paging system can't find
> the backing store for the original executable. If you are
> unlucky, you will *think* you have fixed the security hole,
> but the daemon actually running on your system will still be
> wide open - at least until you manually restart the daemon.
drop to single user mode .. get on the console .. patch, reboot, smile
works for me and I blog about stuff like this too :
http://www.blastwave.org/dclarke/blog/?q=node/47
Dennis Clarke
_______________________________________________
opensolaris-discuss mailing list
[email protected]
