LibVNCServer 0.9.13 Released With Better Cross-Platform Coverage

[Zico]

@up I don't have much knowledge in this field.
However, not long ago I couldn't connect the client (using TigerVNC (TightVNC), NoVNC, mostly opensource licenses) to the server. Both in Wayland, dist. Ubuntu. After 1 sec of successful connection I was immediately disconnected. Only paid realVNC worked correctly (unfortunately none free). Under X.org I didn't have such problems.

[Terrablit]

I am trying avoid any solution which will require port forwarding or any similar intervention on the other end, due to users being very low knowledge level in that field.

There's 2 things people are generally looking for with stuff like this. Remote access and remote support. The main difference is whether you're sharing a desktop session or not.

Remote Access:
If you're connecting to office Windows computers with a separate session, RDP + VPN is probably your best bet. Set up a VPN (making sure to set the domain search for that connection) and people can RDP into their office computers without a lot of hassle. You can build out the RDP file for them. RDP sessions are limited without an RDP server and licenses, so this is really only useful for people connecting into their office machines from home, or 1-2 people connecting into a server in the office simultaneously. If you need more than 1-2 sessions on a computer, the legally available solutions require payment. I also haven't found non-paid solutions for RDP 2FA. It'd be great if those exist.

You could also do something with Guacamole (with or without VPN) that would do the RDP session for you. But you're probably going to have a worse experience doing RDP in a browser window as opposed to in a dedicated RDP client. Last I checked it didn't do keyboard capturing as well as I'd like.

Remote Support:
If you're providing remote support to people who are already in a Windows session and you want to *see their screen*, you'll either need to do the work to set up Remote Assistance in Windows, or use a solution based on VNC. If everyone you're connecting to uses the same LDAP/AD, Remote Assistance is probably the best approach. Its integration with Windows has a lot of advantages.

UltraVNC forums have a lot of stuff on remote support via VNC, but there's been a few different solutions made and it can be hard to figure out which is newest or "best". PCHelpware (UltraVNC) is probably the easiest solution for deploying an assembly for arbitrary remote support (meaning there's not already a support client installed). UltraVNC and TightVNC both have installable remote support options.

VNC fragmentation doesn't prevent the different flavors from interacting, but it *does* add a lot of useless noise and choice. I spent a few hours running down old-ass information to figure out which VNCs were best for this. We might extend our remote support at work to more clients, which meant I had to spend time figuring out what we could do.

Dream solution would be a deployable executable that connects to our proxy server, which would then put a request out via webhook to something like slack or discord. Arbitrary users could then accept the remote task with some type of built-in reaction (click the accept emoji), and it'd be assigned to them. A link would then be generated (and a ticket, if it's not already there) that'd open up a remote client on the tech's computer and possibly a voice/video channel for communications and connect to the open support request executable. On close, the deployed support app could ask if it's been resolved, and that answer could be posted back to the ticket. You could even get fancy with the executable, and have a service that builds different executables for different people (based on the login used for support request), and lets them pick open tickets or create new tickets. Even bett

There's a bunch of pieces already that do much of this, but it's still kind of roll-your-own stuff.There's a lot of remote support software "platforms" that build on top of VNC. Sometimes they add as many problems as they solve, though. If I were building one, I'd leave the VNC service running as manual and have a connection process that started the service and connected rather than leaving it always running.

Side note: having too many remote support solutions on a computer will kill productivity. I was zooming with somebody that had two VNC servers running and it was awful. If memory serves, it's got something to do with the mirror driver used to mirror input and graphics. I'm not sure if it even requires someone to be connected for this to happen.

[RussianNeuroMancer]

I don't think tiger provides a special encoding. After all you can use any client with TigerVNC and it still offers exceptional performance.

No, performance is actually worse with alternative clients. I verified that several times.

As for special encoding, I'll just put here quote from Readme:

TigerVNC supports a variant of Tight encoding that is greatly accelerated by the use of the libjpeg-turbo JPEG codec.

And I can assure you that it doesn't get enabled with Remmina as VNC client, for example.

[kpedersen]

Right so it looks like TigerVNC is basically TightVNC but with a more heavily optimised JPEG library. Perhaps the TightVNC client is also using that which is contributing to your noted better performance than other clients.

I just tried now and the performance difference is still negligible (it is possible that the bottleneck on my test is the slow internet performance in the UK).

[Zico]

(..)
There's a bunch of pieces already that do much of this, but it's still kind of roll-your-own stuff.There's a lot of remote support software "platforms" that build on top of VNC. Sometimes they add as many problems as they solve, though. If I were building one, I'd leave the VNC service running as manual and have a connection process that started the service and connected rather than leaving it always running.
(..)

I exactly needed VNC to work in LDAP. You described problem in details, but focused on Widows OS. Have you tried using VNC under linux (exactly from Wayland)?

[Terrablit]

I exactly needed VNC to work in LDAP. You described problem in details, but focused on Widows OS. Have you tried using VNC under linux (exactly from Wayland)?

LDAP + Linux + Wayland + VNC isn't something I've had to set up, myself. The Windows stuff I knew because I was looking to set up Windows support services and had no concern about integrating it with the local network. RealVNC (paid) has its own method for doing this, though I don't know if it works with Wayland. All my googling on LDAP + TigerVNC server suggests that the server can only use TLSPlain or X509Plain SecurityTypes. You've also got to enable and configure PAM for LDAP, and apparently most PAM modules assume root, so you might need to run the VNC server as root.

Relevant links:
PAM usage in TigerVNC: https://github.com/TigerVNC/tigervnc/issues/355
Using TigerVNC with LDAP via PAM: https://groups.google.com/forum/#!to...rs/dHaoiQyx0ZI
Archwiki has a better explanation of SecurityTypes and is generally a useful reference for most software: https://wiki.archlinux.org/index.php/TigerVNC
Using PAM + TOTP with TigerVNC for contrasting usage of PAM: https://turbovnc.org/Documentation/TOTP
Also check the PAMService parameter in the manpages: https://manpages.debian.org/unstable...onf.5x.en.html
pam_ldap man page: https://linux.die.net/man/5/pam_ldap

A lot of stuff I'm seeing seems to use pam through sshd to handle the login stuff. But I don't think it's necessary since you can set a PAMService? PAM config isn't something I'm very experienced with.
Not really seeing anything for servers other than RealVNC and TigerVNC. This type of stuff is where all that pointless VNC diversity causes a bit of a headache. But if you're using something that supports PAM, it's probably similar. I assume if I've said something wrong, someone will call me an idiot and give you a more complete answer. That's the beauty of FOSS.

I have absolutely no clue how Wayland fits into all this. The last time I explicitly set up a VNC server on Linux it was before Wayland was usable. These days I usually use xrdp because everyone else uses it and I'm lazy. So, try it and see what works. Then post an updated guide for the next sucker. Good luck.

[willbprog177]

Yay, maybe SpiritVNC - FLTK will be more stable now...

[Zico]

I have absolutely no clue how Wayland fits into all this. The last time I explicitly set up a VNC server on Linux it was before Wayland was usable. These days I usually use xrdp because everyone else uses it and I'm lazy. So, try it and see what works. Then post an updated guide for the next sucker. Good luck.

My question was that the free alternative to realVNC isn't reliable in Wayland. For me was too difficult to configure (e.g. TigerVNC)

[Terrablit]

My question was that the free alternative to realVNC isn't reliable in Wayland. For me was too difficult to configure (e.g. TigerVNC)

10 minutes of Googling suggests that the most common approach is to use an x-based environment on top of wayland, which loses a lot of the benefits of Wayland. And probably won't display native Wayland applications. However, it looks like gnome is working on using PipeWire and Gnome Remote Desktop as a means to satisfy this. You'll have to deal with a lot of limitations for a bit, but it looks like somebody's working on a solution at least. Even if I only found the GNOME one. Red Hat's always tackling stuff with enterprise concerns like this because of their customer base. After they've blazed the trail a bit, everyone should know a bit more about the implementation and start getting Wayland protocol extensions in place as well as libWayland code to fast track implementations.

As an upside, it looks like they're trying to bake in support for multiple protocols (VNC and RDP have had some work done, and people are discussing SPICE). And having it come with the DE is nice. As a downside, you can't easily use your own remote software unless there's a shim made to the two new APIs.

The two new APIs, org.gnome.Mutter.RemoteDesktop and org.gnome.Mutter.ScreenCast, expose a PipeWire stream containing the contents of the system’s screens. The new APIs can create full-screen streams, or streams for individual windows. Only the former has been implemented.

- from https://www.ctrl.blog/entry/wayland-...e-desktop.html

The upside of open, living software projects is that anyone can contribute, and people will add in the features they want eventually. The downside is that those contributions take time since most contributors work in their spare time. And, over time, stuff needs minor and/or major refactoring, which can leave you in the lurch without a suitable solution. Especially since catering to Linux's pathological need for pointless diversity results in protocols instead of libraries and other over-engineered stuff that is tedious to implement. There's always something broken in Linux. Often as a precursor to making something better.