Impact/managemnt of Solaris Patch Bundles to Cups (Ticket100711A)

[ed smith]

> ed smith wrote:
>
> > Greetings,
> >
> > What is your method for management of OS patches to Unix environments?
> > Whenever we apply patch bundles to our Solaris 10 systems, they often
> > times overlay the various CUPS utilities with native Solaris versions-
> > (lp, lpstat, cancel, enable, etc ) or change the links. The man pages get
> > stomped on as well. I currently manually repair this, using detailed
> > reference info. However, this is cumbersome. We have 200+ production
> > printers around the country, so impact is great if I miss something.
> > Surely others are faced with this same issue. What are the "best
> > practices" today?
> >
> > Thanks!
> > Ed Smith McQuay
>
> Well, what I did all the time I was responsible for Solaris boxes (2.52 up
> to 11) I firstly installed CUPS (and other things not native to Solaris) in
> a directory tree residing beneath /usr/local or /opt and secondly made a
> Perl script to fix the remaining issues after installing Solaris
> updates/patches.
>
> Helge
>
Greetings,

Thanks for the idea Helge, I am creating a quick-ref repository, but not a full install. This next question might be a Michael Sweet question, not sure. So far, from CUPS perspective, the dirs that I find impacted by Solaris patching are /usr/bin, /usr/sbin and /usr/share/man/man1, man1m, man5, and man7, most of which is core lp commands. I know cups keeps stuff in other directories, but these dont appear to get stomped on by Solaris patch bundles - as most of the other cups components are named or pathed in such a way that they don't overlap with Solaris print components, so they don't get overlayed. My question is- have I missed anything else ?

Thanks,
Ed Smith   McQuay