On Thu, Apr 24, 2008 at 04:33:29PM -0400, Bob Doolittle wrote:
> 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.
> 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?
Yes, I got a warning but ignored that one. `ulimit -n 1024' is the
only addition.
> Are
> you using utadm -a or -A, or just -L? If the latter, I wouldn't expect
> this file to be modified.
I use `utadm -A subnetwork' repeatedly to add Sun Ray subnets. We
have one for each building.
> 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.
Okay, that sounds good.
> >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.
Mostly because I didn't know about that. After I install any product,
I run a check to see if it changed any files under control of our
configuration management system. If it has, I have to merge any
changes introduced by the product with our local changes. Otherwise,
the changes will be lost.
> 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.
Yes, that would be a better way to do it, by maintaining the
separation. I now understand why the dtlogin scripts are the way they
are. I look forward to running a new product.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
