Closed sync-by-unito[bot] closed 1 year ago
Wrong repo - @gbyrketosc seems like this is still syncing ood core stuff here.
➤ Jeff Ohrstrom commented:
what? I closed the ondemand duplicate and it closed this one too?
In any case - yea seems like in the shell script we can check what version it is and have a toggle for the same.
This problem also exists for CentOS 7 sites using the the official TurboVNC repo from https://turbovnc.org/pmwiki/uploads/Downloads/TurboVNC.repo
version 2..2.90 removed -nohttpd. I ran a
yum downgrade turbovnc-2.2.6-20210221.x86_64
on all my nodes, as that was the previously working version at our site. Is the OSC preference to remove the. TurboVNC repo and use the 2.2.5 turbovnc in the OSC repo, or ???
@azric At OSC we actually put turbovnc as a module via Lmod. The turbovnc RPM and the websockify RPM we provide are the only RPMs we don't use in house, we provide them for other sites who may not want to use something like Lmod to install that application. I don't want to go as far as recommending using the OSC RPMs simply because we don't test them heavily and I'm not even sure we document them in the official docs. If the OSC RPMs for TurboVNC work for you, that would be really good for us to know and we can work to more officially document those RPMs.
@treydock I followed the software requirements link along go (pre-ondemand RPM days) which has a pointed to the turbovnc website. From there, I installed the repo TurboVNC provides for their product. That has been working without problem until this update which took my nodes from TurboVNC 2.2.6 to the latest (2.2.90). I know turbovnc-2.2.6.x86_64.rpm works; it's possible we ran 2.2.5 (from turbovnc) at some point. I see from my notes that I added the TurboVNC repo to the compute nodes in May of 2017, which was probably TurboVNC 1.1 days, and have been happily updating 3-4 times/year since then (until yesterday).
Sorry I can't provide specific info about TurboVNC 2.2.5, Ric
We hit the same problem when using turbovnc 3.0 . We got this in the logs:
Setting VNC password...
Starting VNC server...
Could not start Xvnc.
Unrecognized option: -nohttpd
We have downgraded to turbovnc 2.7 to woarkaround the problem
Same problem here. On our RHEL7 servers turbovnc v3.0 breaks the remote desktop application with error Unrecognized option: -nohttpd
. A downgrade to turbovnc v2.2.7 fixes, at least temporarily, the problem.
Are there any plans from the OOD team to support turbovnc v3+? Perhaps the page listing the software requirements to run interactive apps (https://osc.github.io/ood-documentation/master/app-development/interactive/setup/software-requirements.html) should be modified clearly stating to not use turbovnc v3+?
I plan to have this patched in 2.1 our next release. We should be able to support all or most versions.
This was fixed in ood_core
and in fact backported to 2.0. Should anyone have any more issues, just open another ticket for the same.
Using the TurboVNC repo and pulling the 'turbovnc' package results in a version of TurboVNC on Rocky 8 (and I assume other RHEL 8 variants) which fails when called with -nohttpd, breaking the default bc_desktop app, thanks to its inclusion in vnc.rb - http server support has been dropped for newer versions of TurboVNC, though it will be supported in 2.2.x versions. (See release notes here: https://github.com/TurboVNC/turbovnc/releases/tag/3.0beta1)
Not sure what the most sustainable fix is, perhaps just mentioning this in the documentation at https://osc.github.io/ood-documentation/latest/app-development/interactive/setup/enable-reverse-proxy.html... This is really just a heads up - possible to continue with new installs using an older TurboVNC version just fine.
┆Issue is synchronized with this Asana task by Unito