You know, the whole time I had this feeling that this is way to hard which is not typical of an SRS install/upgrade. I should have checked the BUI after utinstall/reboot and I would have seen that everything was fine. Dang. Lesson learned. " ... trust the Force, Luke".
Art Sent from my iPhone On Dec 8, 2010, at 10:51 AM, Bob Doolittle <[email protected]> wrote: > 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
