Prev: Disable e1000 tcp checksum offloading T5220
Next: PCA: howto configure a Sun Online Account w/o
From: Martin Paul on 27 Nov 2009 06:53
Martin Paul wrote:
> After playing around and experimenting with Live Upgrade, I'm now
> planning the first LU of a production server.

Let me add a more concrete question as well:

Can anybody confirm whether an existing SRSS (Sun Ray Server)
installation will survive a Live Upgrade from e.g. 10 8/07 to 10 10/09?

I'm concerned because the SRSS installation made modifications to many
existing system files, like:

/etc/inet/inetd.conf
/etc/inet/services
/etc/syslog.conf
/etc/pam.conf
/etc/group
/etc/devlink.tab
/etc/minor_perm
/etc/name_to_major
/var/spool/cron/crontabs/root

So hearing from somebody who has done such an upgrade in the past would
be very helpful.

mp.
--
SysAdmin | Institute of Scientific Computing, University of Vienna
PCA | Analyze, download and install patches for Solaris
| http://www.par.univie.ac.at/solaris/pca/
From: Casper H.S. Dik on 27 Nov 2009 07:07
Martin Paul <map(a)par.univie.ac.at> writes:

>Can anybody confirm whether an existing SRSS (Sun Ray Server)
>installation will survive a Live Upgrade from e.g. 10 8/07 to 10 10/09?

I have on erunning at hom ean din the office; I run live-upgrade every
other two weeks. It works fine for me.

>I'm concerned because the SRSS installation made modifications to many
>existing system files, like:

> /etc/inet/inetd.conf
> /etc/inet/services
> /etc/syslog.conf
> /etc/pam.conf
> /etc/group
> /etc/devlink.tab
> /etc/minor_perm
> /etc/name_to_major
> /var/spool/cron/crontabs/root

Most will service and one of the SRSS startup scripts make sure that
pam.conf/inet.conf, etc are up-to-date.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: Gary Mills on 27 Nov 2009 08:25
In <4b0fa7ec$0$11610$3b214f66(a)usenet.univie.ac.at> Martin Paul <map(a)par.univie.ac.at> writes:

>After playing around and experimenting with Live Upgrade, I'm now
>planning the first LU of a production server.

We do this all the time. LU is the best thing Sun has ever produced.

>(2) The LU Sync takes place at the very end of booting the new BE. If a
>file is updated in the new BE during booting, changes will be lost
>(PREPEND and APPEND are only partly useful here). I'm especially
>concerned about the state of SMF services (/etc/svc/) here. I think it
>would have been better for the sync to happen at the end of the shutdown
>of the old BE or at beginning of the boot of the new BE. I will probably
>run my own syn process right before the "init 6" to overcome these
>problems - the only thing lost will be files written in the old BE
>during the shutdown.

In my experience, LU Sync is unreliable. I developed a test case that
demonstrated this with the OVERWRITE keyword, and submitted this in a
support case. The problem is that LU will often report incorrectly
that the file has changed in both boot environments. It will then
refuse to update the file on the new BE. Sun accepted my information
but said that they weren't going to pursue it. OVERWRITE is the one
that you want to work because you generally want the newest copy of
any file. It's telling that /etc/lu/synclist specifies APPEND for
log files instead of OVERWRITE. This works, but you get duplicated
copies of most of the lines with APPEND.

--
-Gary Mills- -Unix Group- -Computer and Network Services-
From: Tim Bradshaw on 27 Nov 2009 13:43
On 2009-11-27 13:25:47 +0000, Gary Mills <mills(a)cc.umanitoba.ca> said:

> We do this all the time. LU is the best thing Sun has ever produced.

I more-or-less agree with that, with the caveat that LU with ZFS root
is even cooler.

From: Tim Bradshaw on 27 Nov 2009 13:50
I don't really have anything useful to add (I use LU a lot for patching
and upgrade, but most of the machines I deal with do not have the
issues you have (no YP, nobody using calendars etc).

Two things I reckon might be useful:
1. Do stuff after you're up in the new BE, because then nothing will
change in the old BE unless you need to back out (obviously before
you're up multiuser in the new BE though). Something like bart could
be useful here: run it in the old BE and then on the old BE from the
new one to find stuff that has changed in the old BE (of course some
incantation of "find -newer" and a flag file can do most of the same
thing but bart is there and works.
2. If you can get to ZFS root, do so, because once you have ZFS root
you are in a different world, and one which is just much better in
almost all ways. ZFS root with LU is just blindingly good (it is Sun's
killer app if only they knew it).

--tim

First  |  Prev  | 
Pages: 1 2
Prev: Disable e1000 tcp checksum offloading T5220
Next: PCA: howto configure a Sun Online Account w/o