Red Hat Bugzilla – Bug 857038
spice-x should be able to use already installed remote-viewer or usbclerk instance of different architecture
Last modified: 2016-02-10 15:21:06 EST
Description of problem: spice-x should be able to use already installed remote-viewer or usbclerk instance of different architecture Status quo is that when there are x64 versions of r-v and usbclerk installed and user wants to access the console from x32 IE, current versions will be reinstalled to x32 ones - and vice versa. Version-Release number of selected component (if applicable): rhevm-spice-client-x86-cab-3.1-4.el6.noarch How reproducible: always Steps to Reproduce: 1. in 64b Windows client, open 64b IE, go to the Portal, let it install r-v & usbclerk 2. close 64b IE, open 32b IE, go to the portal again, launch console 3. Actual results: spicex triggers r-v & usbclerk reinstallation to 32b versions Expected results: spicex launches already installed r-v & usbclerk Additional info:
(In reply to comment #0) > Description of problem: > spice-x should be able to use already installed remote-viewer or usbclerk > instance of different architecture Tbh, I don't understand why we have both 32bits and 64bits version of the client. If we would have only one version, that problem would be already simplified. However, the activex needs to be 32bits or 64bits, so we need two different cab files. The cab in turn install the client, so it needs to be somehow downloaded, and currently they come together in one go. It seems we could use conditionnal hooks for that, but it looks quite hard (hmm, badly documented), and will need cooperation with RHEVM to serve another file. I would propose we lower the priority of this enhancement and postpone it. It does not seem vital, as user is unlikely to switch 32bit vs 64bit, and the annoyance of downloading client twice is really minor. Given the technical difficulties and cooperation needed, and the fact that I am fighting to drop the CAB approach, I hope we can even forget about this request, unless we have hard founded customer demand.
Anyway, this is not such a good idea. Using 32 bit or 64 bit IE should give reliable results, and not depend on what you used first. Unless we have founded customer requirement for that, I would be opposed to that idea, unless we have a single 32bit client.
(In reply to comment #1) It seems we could > use conditionnal hooks for that, but it looks quite hard (hmm, badly > documented), and will need cooperation with RHEVM to serve another file. > > I would propose we lower the priority of this enhancement and postpone it. > It does not seem vital, as user is unlikely to switch 32bit vs 64bit, and > the annoyance of downloading client twice is really minor. Given the > technical difficulties and cooperation needed, and the fact that I am > fighting to drop the CAB approach, I realized one big Pro of CAB approach: if accompanied by RH software-signing-certificate distribution and the right Group Policy, it should provide updates of the client with least total pain. GPO+msi -only approach leaves the same manual pain like at installation at every client/usbclerk update. I'm just in the process of figuring out if it will work with usbclerk because I suspect that it's Administrator-privileges service nature could pose some problems - but that has to be tried and tested. The remedy to almost all problems could be to break the cab to separate activex 32b and activex64b, mingw-remote-viewer and usbclerk and download any of them if it is missing or outdated - that could also resolve bug 857087 and bug 865868. > I hope we can even forget about this > request, unless we have hard founded customer demand. fair enough, rhevm-3.1.0? --> rhevm-3.2.0?
(In reply to comment #1) > (In reply to comment #0) > > Description of problem: > > spice-x should be able to use already installed remote-viewer or usbclerk > > instance of different architecture > > Tbh, I don't understand why we have both 32bits and 64bits version of the > client. If we would have only one version, that problem would be already > simplified. > As we need to support x64 IE, x64 ActiveX seems a must. Are you sure 32bit client can be used in that case? In the past, when AX and client were CABed together (without an installer), they must have been the same arch, but just as you said, this req might be irrelevant anymore. > However, the activex needs to be 32bits or 64bits, so we need two different > cab files. The cab in turn install the client, so it needs to be somehow > downloaded, and currently they come together in one go. It seems we could > use conditionnal hooks for that, but it looks quite hard (hmm, badly > documented), and will need cooperation with RHEVM to serve another file. >
no, I am not sure the 32bits client is enough. I also don't know if the usbclerk 32 bits can work on a 64 bits machine.
The arch implications are: * 64b Windows requires 64b usbclerk * 64b IE seems to require 64b plugin/client * 32b client on 64b Windows works with 64b usbclerk In the end, it seems that "correct" packaging and cab delivery should be: * unchanged for 32b systems * 64b cab should contain 32b client & plugin in addition to 64b one * respective cab should be presented to the client based on _Windows_ arch, not IE arch
(In reply to comment #6) > The arch implications are: > * 64b Windows requires 64b usbclerk > * 64b IE seems to require 64b plugin/client > * 32b client on 64b Windows works with 64b usbclerk > > In the end, it seems that "correct" packaging and cab delivery should be: > * unchanged for 32b systems > * 64b cab should contain 32b client & plugin in addition to 64b one > * respective cab should be presented to the client based on _Windows_ > arch, not IE arch thanks for documenting this. I think your proposal is correct, and looks similar to what other windows application do. The installers will need to be updated to use different paths, so that 32b and 64b can be installed in parallel..
(In reply to comment #6) > * respective cab should be presented to the client based on _Windows_ > arch, not IE arch That suggests a change in RHEV-M. I'm not sure it's required. It should be possible to install both 32b and 64 on the same machine (also true for your suggestion). And than the only problem is installing the appropriate usbclerk (according to the Windows OS). Alternatively we can take usbclerk out of virt-viewer installer and make users download it separately. (In reply to comment #7) > The installers will need to be > updated to use different paths, so that 32b and 64b can be installed in > parallel.. I agree. There should be no problem installing both 32b and 64b on the same machine. (also there is a need for different registry entries, if they are not already different)
we'd love to have a solution in rhev-m 3.2.z timeframe as the users will immediately hit the problem with IE10 and 64bit Windows 8 where we detect IE as 32bit (which it is) and usbclerk doesn't work
I guess bug 918656 would solve this?
What about separation of usbclerk to a separate active-x plugin that would contain installers for both architectures, and keep current clsid's just for current spice-x and mingw-remote-viewer? That way, we could get rid of need to double install the same plugin on Windows 7 / 2008 clients because the client/activex plugin could have installscope=user and usbclerk plugin could have installscope=machine. This would require RHEV-M to add the third activex plugin to the portals of course.
(In reply to comment #11) > That way, we could get rid of need > to double install the same plugin on Windows 7 / 2008 clients because the > client/activex plugin could have installscope=user and usbclerk plugin could > have installscope=machine. > In addition, this change would fix the "usbclerk is not installed the first time and user can not trigger its installation from that time on" bug.
In RHEV-M 3.3 the spice client cab files do not install usbclerk. Instead usbclerk is installed separately with its own MSI files.
Created attachment 812960 [details] nsis: compare versions and install only if needed
This bug is currently attached to errata RHEA-2013:15512. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0034.html