[SunHELP] solaris10: dumb question...

[velociraptor]

On 12/5/05, William Enestvedt <William.Enestvedt at jwu.edu> wrote:
> Andrew wrote:
> >
> > ...i already had patchcheck running smoothly, along with a cron
> > wrapper to fetch the latest .xref and run it [fri's at 11pm now] and
> > scripts to parse the report and fetch patches, remove
> > outdated patches, install the new patches...
> >
>    You have a script patch your servers on Friday nights at 11:00? What
> stones you have! I wouldn't dare do that unattended. :7)

smpatch will only install the patches "allowed" by policy.  By default,
that is non-kernel patches (e.g. patches not requiring a reboot).

One interesting thing I discovered (relative to a patching discussion
we had on this list a while back)--what is the downside of not being
in single-user mode when patching?

A quote from "Solaris Patching: Problems, Solutions, and Open
Issues" by Julie L. Baumler, 14 October 2003.  Paper #1281 in
the SANS Reading Room:

"Certain types of patchadd failure result in a missing
/var/sadm/pkg/*/pkginfo for one (or more) packages
without this file, the system becomes unmaintainable as
any patches or packages that depend on the affected
package cannot be added. [...]

Symptoms of the problem:
In Solaris 8, you get an error message when running
showrev -p:
showrev: /var/sadm/pkg/SUNWcsu/pkginfo - No such file or directory
[...]
The Sun support center told me that this happens as a result
of installing patches (particularly kernel patches) in anything
other than Single-User mode.  I and many other admins I know
regularly install patches on quiescent but non-single-user mode
systems and yet this problem is very rare.  All the systems where
I've seen this problem occur have a history of the patchadd process
having received a SIGINT or SIGKILL during patch installation -
patchadd traps these signals and backs out any partially installed
patches, but may not always restore the pkginfo file appropriately.
However, I have successfully used SIGINT to stop a running
patchadd process with no ill effects."

A work around is to copy the patch directories from a similarly
configured system, or to use the script included in the above
paper (I didn't attempt that.  My system with the issue is a dev
box, that will be going away soon, so an rsync from a similar
server was "good enough".)

So, if you start the patching process in multi-user mode, be
careful how you kill it.

=Nadine=