On 12/08/10 09:55, Art Peck wrote:
Just completed an upgrade from SRSS 4.1 + SRWC 2.2 to SRS 5.2 + SRWC 2.3 on
RHEL 5.4. To say the least, it did not go smoothly. What is usually about an
hour on Solaris servers took 8 hours on RHEL 5.4 do to a comedy of
errors/problems. So I have the following questions:
(1) I know changing the hostname is definitely not a recommended procedure, but
I can't see why you would not be able to change the IP address of the server.
However, nothing we did would convince SRSS that the server had a new IP
address. The admin BUI was especially impacted. Any thoughts?
Not by me, sorry.
(2) How DOES one determine if the installed version of GDM is appropriate. I
assume there is some form of the rpm command to give output similar to pkginfo?
This of course is a RHEL/Linux question, but it cost us some time trying to
figure it out, so I thought I'd ask. In the end we stuck with the installed
version rather than install the version in the release. Is this a bad thing? Is
the version in the release customized for SRSS? If so, what do we do now? can
we go back an install the released version or do we need to start completely
over (NOT!).
This isn't something anyone should worry about. If the version of GDM needs to
be replaced, the installer will take care of it. The version on RHEL is used
natively, it's only on SLES 10 that the Sun Ray version is utilized.
That's why there's no mention of this in the installation documentation:
http://wikis.sun.com/display/SRSS4dot2/START+HERE+to+Install+SRSS+%28Linux%29
If you really cared to check, you could run "rpm -q gdm". There's a "sunray"
suffix to the version string for the RPM we provide.
(3) Following a successful utinstall,is a complete run of utconfig, that is,
without options, required?
No. If you do try to run utconfig on a system that is already configured, then
after the standard preamble you will get a message like this:
WARNING: Sun Ray Datastore is enabled. This script may clobber the current
configuration.
Continue (y/[n])?
Note that the default is "no", since it's harmful to continue. You must have
not noticed this and overrode the default? It should be in the logs... On Linux the
utconfig logs are in /var/log/SUNWut.
harmful? really dumb?
Yes, probably.
OR do you just need utconfig -w to reconfigure the admin BUI with the location
of Tomcat?
Why did the location change? Normally you wouldn't need this, either. If you need to
change the location, it's best to do "utconfig -uw; utconfig -w" and
reconfigure it from scratch (there's not much configuration required for the web server).
I did a "complete" utconfig, without options, which complained about port
1660/1661 being in use which I completely understand but did not expect. We go around it,
but I don't see that you should really encounter that problem so I suspect we did not
want utconfig without options.
You didn't want utconfig at all :-(
(4) Same question as (3) but regarding utconfig -k.
Same answer. Upgrades should not require reconfiguration of *any* sort. There's
actually a special invocation of utconfig run *by the installer* after an
upgrade which takes care of any necessary data migration required by the new
version of SRS. Admins never need to do this.
(5) We did out own preservation of the Data Store contents by putting the
output of utuser/utdesktop/utresadm -o into files and reloading them later. I
was under the impression that utconfig would preserve these for us, but out
skepticism paid off since we wound up with an empty Data Store. We were able to
recover of course, but I would like to understand where we went wrong. Is this
a result of (3)??
Probably, yes, as the warning should have indicated.
(6) RFE: a pre-upgrade script that inspects the current installation and spells
out exactly what needs to be upgraded in the OS and current SRSS installation
prior to the SRS upgrade.
I have not encountered these problems in past upgrades. Is there something
fundementally different with SRS 5.2? Aside from what is in the Release Notes
that is.
Presumably you've not tried to reconfigure after an upgrade before. "That trick
never works..."
The bottom line is: you're trying way too hard here. utinstall should have been
sufficient. utconfig is not designed to be run twice, and tries to protect you
from doing so. Perhaps it doesn't try hard enough - I can think of no valid
reason to allow utconfig to continue if it detects an existing configuration.
It should perhaps require an explicit unconfiguration first, rather than
allowing you to override its warnings and continue down a path that's certain
to have issues (such as the port 1660 issue).
I also think the warning is a bit subtle, since it comes up after a somewhat
lengthy standard preamble and then gives a Continue prompt which looks similar
to the normal prompt (even though the default is changed).
-Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
