nick created GUACAMOLE-1935:
-------------------------------
Summary: Solidify compatibility with UltraVNC's MSLogonII
Key: GUACAMOLE-1935
URL: https://issues.apache.org/jira/browse/GUACAMOLE-1935
Project: Guacamole
Issue Type: Improvement
Components: VNC
Affects Versions: 1.5.4
Reporter: nick
UltraVNC's MSLogonII uses Microsoft domain authentication as the security
protocol for opening a VNC connection. [Support for this protocol was only
added to libvncserver in
v0.9.14|https://github.com/LibVNC/libvncserver/commit/f8333e3] (the latest
version as of writing this), however, as far as I can tell, all of the Red
Hat-based distros recommended for running Guacamole (Fedora, CentOS, Enterprise
Linux) [only have packages with v0.9.13 of
libvncserver|https://pkgs.org/search/?q=libvncserver]. I am running Guacamole
1.5.4 on RockyLinux 9.
What would be the best way to overcome this?
Updating the packages for those distros to v0.9.14 is probably the best plan,
but I imagine this would take a fair while to ensure the update doesn’t cause
problems for other applications that use libvncserver.
Building libvncserver v0.9.14 from source would probably be the
simplest/fastest workaround but unfortunately this didn’t work for me. Even
after trying to move all the necessary library and shared object files to the
same locations as they are when libvncserver is installed via the package
manager (DNF), I was getting still getting an error in journalctl: – “VNC
connection failed: authentication rejected”. I’m not sure why this didn’t work
but I suspect there is something about the way the package manager installs the
library that I missed when doing it from source.
The way I solved it was to rebuild the [libvncserver source RPM for my
distro|https://dl.fedoraproject.org/pub/epel/9/Everything/source/tree/Packages/l/].
Inside the libvncserver .tar.gz file I added in JUST the extra lines of code
from that libvncserver commit (changes to rfbproto .c and .h files) to avoid
causing any problems with Guacamole, or interfering with any of the
patches/specfile inside that RPM. This worked! But it seems like a bit of a
dirty way to do it, so I thought I’d share this and see if anyone has a better
idea/method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
