Gary Mills wrote:
I did a Live Upgrade on a Sun Ray server running Solaris 10 8/07 to
bring it up to Solaris 10 5/08. This was an X4100 with Sun Ray server
4.0. To begin, I created an alternate boot environment this way:
# lucreate -c firstlu -m /:c0t2d0s5:ufs -m /var:c0t2d0s7:ufs -n secndlu
Then, I upgraded it this way:
# luupgrade -u -n secndlu -s /net/SERVER/jump/S10_up508_x86_cd
The file /var/sadm/system/data/upgrade_cleanup on the alternate boot
environment lists files that need to be reviewed before activating
that BE. I was surprised to see these files listed:
/usr/dt/config/Xreset: existing file renamed to /usr/dt/config/Xreset~10
/usr/dt/config/Xsetup: existing file renamed to /usr/dt/config/Xsetup~10
/usr/dt/config/Xstartup: existing file renamed to /usr/dt/config/Xstartup~10
/usr/dt/config/sessionetc: existing file renamed to
/usr/dt/config/sessionetc~10
/a/etc/pam.conf default entries updated, please examine/update customized
entries
/a/etc/pam.conf updating pam_unix with default PAM entries please
examine/update any new entries
/a/etc/pam.conf updating entries to add kerberos, please examine/update any
new entries
The /etc/pam.conf file seemed to be correct, but the four files in
/usr/dt/config had reverted to their original form, with all of the
SUNWut sections removed. I had to rename them back to retain the Sun
Ray server changes. After this, I activated the new BE and rebooted
the server. Sun Ray services seemed to work normally afterwards.
I was pleased to see the new features of Solaris 10 5/08, including
Staroffice 8.
I'm concerned that Sun Ray server software is not well integrated with
the Solaris package and patch system, so that Live Upgrade doesn't
work in a more reliable manner. Manual changes should only be
necessary where the sysadmin has changed configuration files, not
where Sun-supplied software has done it. Can this situation be
improved?
Thanks for your feedback.
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.
I suspect that these types of warnings are going to be generated for any
layered product that updates system files, since by its nature
live_upgrade can't know about layered products, and the onus is upon
layered products to work properly with upgrades, not visa-versa. SRSS
does the right thing wrt /usr/dt/config/X{reset,setup,startup} but our
sessionetc file handling looks like a bug to me at this point. There's
probably also a SRSS documentation bug since I don't think we mention
that these warnings can be disregarded anywhere today.
-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
