Gary Mills wrote:
On Wed, Apr 23, 2008 at 12:40:56PM -0400, Bob Doolittle wrote:
In fact, the /usr/dt/config/X* file warnings are "red herrings". If you
had just booted the ABE you would have found that these files are
instrumented properly during SRSS startup and required no manual
intervention on your part. In order to protect against patches and user
modifications, a number of system files are instrumented by SRSS on
every software restart, using "utrepair" and the templates stored in
/opt/SUNWut/lib/prototype (it's interesting that the others didn't show
up in warnings - they must not have been impacted by this particular
upgrade). So the only real issue here seems to be
/usr/dt/config/sessionetc. This file is updated by utadm. We'll need
to look into this further.
Can I run `utadm -R /a' to update it in advance?
There's no such option - see the man page.
I've been looking into this further, and I am about to conclude that the
change made by utadm is superfluous. It's very old code dating back to
1999 and I don't think it's relevant today. It probably should simply
get removed. So I wouldn't worry about it. I notice that on my system
I've lost this utadm customization and the change has gone unnoticed for
months now.
OTOH, I tried my own LiveUpgrade from u4 to u5 last night, and there was
one more file flagged: /etc/init.d/dhcp. This also appears to be
modified by utadm (it attempts to limit the number of file descriptors
that dhcpd can utilize), and I haven't yet tracked down why and if the
change is still relevant. Did you get no warning about this file? Are
you using utadm -a or -A, or just -L? If the latter, I wouldn't expect
this file to be modified.
I have opened a defect report for our handling of these files - I
believe all relevant changes should be reapplied at SRSS startup to
overcome these patch/upgrade issues. It's not enough to just do it when
utadm is run, unless we're updating files that SRSS packages own and
control so we can do the appropriate things.
I could do that
for Jumpstart installs too. I do find the automatic update of those
system files at boot time a bit annoying.
Not at boot time - at SRSS start time. Every time you start SRSS. So,
you can apply a Solaris patch that overwrites one of these files but
doesn't require a reboot and just restart SRSS.
It interferes with our
configuration management system, for one thing. I have to identify
all of the changed files and copy them back to that system.
Why? It's automatic and shouldn't matter what state the original file
is in. It's OK if the file reverts or changes at any time as long as
SRSS gets restarted afterwards.
This is the nature of layered (or 3rd-party) products. Solaris doesn't
know about layered products, so if they touch any system files they need
to insure their changes are resilient to patches and upgrades. This is
how we maintain that resiliency.
The ideal would be if the /{usr,etc}/dt/config/X* files were replaced by
models similar to /{usr,etc}/dt/config/Xsession.d/ - a directory in
which people can deposit scripts all of which are to be executed at a
particular point in the dtlogin lifecycle. Then, customers and layered
products could simply deposit a script and it wouldn't cause merge
problems with OS patches and upgrades. We filed an RFE for this a while
back but dtlogin was already headed for EOL so it was never pursued.
There's no chance of it being pursued today, so close to it's actual end
of life (sometimes these things take longer than anticipated). gdm
(today's version, anyway) already follows a model similar to this, so
that's good news.
-Bob
Disclaimer: Opinions expressed in this mail are my own, and are not
necessarily shared by my employer
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
