1 of 1 people found this helpful
Set the ‘versioncompabilitycheck’ in the appserver section of blasadmin to ‘build’, restart the appserver service and try again.
That seemed to work, at least to get the Console to identify that the appserver is a newer version.
Now it looks like we're running into a permissions issue
[21 Aug 2014 15:07:02,756] [Client-Connections-Thread-3] [WARN] [xxxx@xxxx:Anonymous:10.12.15.117] [Client] Cannot set impersonation credential, reverting to legacy user mapping: Access Denied Server.Read on servername
We've tried several locations for the installer - on the local filesystem, on a mounted/remote file system, in the depot fileserver - access denied everywhere. Where is the recommended location we put these packages where the clients can access them?
The installer should be accessible via a nsh path – eg //server1/blah/installers. the error below looks like the role does not have the Server.Read permission on the server object for ‘servername’.
I’m not sure if the installer needs read access to the server object, I thought it was just nsh access to the location.
I was able to get it working, the WARN message I posted really wasn't part of the issue it turns out. But it did inadvertently point me in the right direction
I was experimenting with various Server.Read permissions on the file servers where I had the Consoles installers. Nothing seemed to work, but did manage to hose up our BL depot/File Server briefly. Our app servers started failing to launch. I opened the console.log and saw these Java exceptions
Failed to get the Installer size com.bladelogic.om.infra.mfw.util.BlException: JNI fileExists '//servername/var/bmc/depot/Console//BBSACONSOLE85-SP1-B96-WIN64.exe' failed:: No authorization to access host //blgdev01.co.csgsystems.com/var/bmc/depot/Console//BBSACONSOLE85-SP1-B96-WIN64.exe
This exception was repeated four times - once for each 32/64 bit installer, and once for the *SP1* and *SP1-B96* file names. The B96 part caught my eye. We only had two installers, the ones from the EPD site, and they just contained the SP1 portion in the file name. I've never seen anything with the B96 portion. After fixing the damage I did to our depot FileServer I duplicated our installers and added the B96 in the file name. Now when the Console connected to the app server and detected a version mismatch, it downloaded and installed the correct client.
I'm not sure where the BBSACONSOLE85-SP1-B96-WIN64.exe and BBSACONSOLE85-SP1-B96-WIN32.exe files were supposed to come from, or why they were needed over BBSACONSOLE85-SP1*.exe, but it works now I guess.
I wish there was more logging to the console.log to have indicated the missing files sooner. If I hadn't messed up our File Server and had it throw exceptions when trying to read from it, I would never have known which file names it was expecting....
Anyway, thanks for your help Bill - much appreciated!
The installer will go down a list of possible file names – from a very specific name including the build number (eg Build 96 -> B96) to the majorminor only
1 of 1 people found this helpful
That was my understanding as well, but it would only recognize the installers once I added the BBSACONSOLE85-SP1-B96-WIN64.exe and BBSACONSOLE85-SP1-B96-WIN32.exe.
If I just left BBSACONSOLE85-SP1-WIN64.exe and BBSACONSOLE85-SP1-WIN32.exe, the download window would briefly appear showing "Downloading 0 bytes of unknown". Then it would disappear and the Console would be left in an unusable state. No errors were logged to the Java window (if launched with java.exe instead of javaw.exe) nor were any additional errors logged to the console.log except that the Console client disconnected.
so there are a few things here:
- the size check happens as 'Anonymous:USER' w/ the user you logged in as, if you are in more than one role. because it never prompts for the role before it tries to upgrade then it uses 'Anonymous'. so if the rsc files on the nsh location of the console installer file don't allow that access the size check fails.
- if your user is in multiple roles and your nsh client is configured to use a nsh proxy, then the process will hang waiting for a role selection that is not possible.
- if your nsh client is not setup to use the nsh proxy then the connection will happen as the OS user id connecting to the nsh url and the rsc files need to allow that.
- the upgrade service relies on local named pipes and if those are not allowed the upgrade will fail.
- i believe that if you have versioncompat set to build it will first look for a -Bxx named file. if that does not exist, i should roll to the next level up which would be from BBSACONSOLE85-SP1-B123-WIN64.exe to BBSACONSOLE85-SP1-WIN64.exe (for example). unfortunately 'Patch' named files are ignored by the upgrade service. and we don't release files w/ Bxx in the name.
the role selection issue is a defect that we are working to address. and we'll better document how this works on the associated docs page in the near future. and we're working to fix the issues w/ 'patch' in the name.