No value for `$wm` working

[jmakov]

First time TurboVNC user, so I might be missing sth: using Debian 12, I installed sudo apt install kde-plasma-desktop. I tried the following values for $wm in /etc/turbovncserver.conf: "kde", "1-kde-plasma-standard", "plasma5". When starting /opt/TurboVNC/bin/vncserver, this would be in the log file:

26/02/2024 11:54:04 New desktop size: 1240 x 900
26/02/2024 11:54:04 New screen layout:
26/02/2024 11:54:04   0x00000040 (output 0x00000040): 1240x900+0+0
26/02/2024 11:54:04 Maximum clipboard transfer size: 1048576 bytes
26/02/2024 11:54:04 VNC extension running!
xstartup.turbovnc: Creating new session bus instance:
xstartup.turbovnc:   unix:path=/tmp/dbus-wwbDCJperH,guid=32b58b22f08a767eda20de0965dc6dcd
xstartup.turbovnc: Executing 1-kde-plasma-standard
/opt/TurboVNC/bin/xstartup.turbovnc: 209: exec: 1-kde-plasma-standard: not found
Killing Xvnc process ID 808213

Would welcome any hint. Also there seems to be an option to run the remote desktop via a browser. In the docs it looks like the same port is being used. If multiple users would want to connect to 1 headless machine, how would one change the port so that everybody can locally bind their port via SSH and use the local browser?

[dcommander]

First time TurboVNC user, so I might be missing sth: using Debian 12, I installed sudo apt install kde-plasma-desktop. I tried the following values for $wm in /etc/turbovncserver.conf: "kde", "1-kde-plasma-standard", "plasma5". When starting /opt/TurboVNC/bin/vncserver, this would be in the log file:

The value of -wm or $wm should correspond to a session desktop file under /usr/share/xsessions, without the .desktop file extension. 1-kde-plasma-standard is the correct value for RHEL 7, and plasma5 is the correct value for SuSE, but I doubt that either is correct for Debian. Just look under /usr/share/xsessions and see what Debian calls its KDE Plasma session desktop file.

Would welcome any hint. Also there seems to be an option to run the remote desktop via a browser. In the docs it looks like the same port is being used. If multiple users would want to connect to 1 headless machine, how would one change the port so that everybody can locally bind their port via SSH and use the local browser?

No, the port used for the built-in web server is 5800 + the TurboVNC session's display number. So if a user's TurboVNC session is using Display :1, then their RFB port would be 5901, and their HTTP port would be 5801. If a user's TurboVNC session is using Display :2, then their RFB port would be 5902, and their HTTP port would be 5802.

[dcommander]

Note that starting the TurboVNC Server with -novnc is really just a convenience method. All it does is start a simple Python HTTP server on the aforementioned HTTP port and point the HTTP server to a noVNC installation that you specify (so you can use whatever version of noVNC you want.) The vncserver script then prints out a URL that the user can copy/paste into their browser. That URL will connect to the Python HTTP server running on the aforementioned HTTP port, and it will pass appropriate arguments to noVNC to make it connect to the TurboVNC Server running on the aforementioned RFB port. The Python HTTP server is managed along with the TurboVNC session, so it will be started and stopped whenever the session is started and stopped. However, you could also choose to install a shared Apache HTTP server and use that to serve up noVNC to your users. It doesn't actually matter if multiple users share the same HTTP port, because HTTP is only used to deliver the noVNC web application to the users' browsers. What matters is that each user has a separate RFB port. The RFB port is what you would want to tunnel through SSH, if you choose to use SSH.

Note also that the TurboVNC Viewer has a built-in session manager, which:

• uses SSH to automatically start a TurboVNC session if one isn't already running under the user's account,
• uses SSH to list any running TurboVNC sessions under the user's account and allows them to pick the session to which to connect,
• automatically starts TurboVNC sessions with secure defaults, including SSH tunneling and one-time password authentication, and
• uses one-time passwords, passed to the TurboVNC Viewer through the SSH connection, to implement single-sign-on authentication with TurboVNC sessions (so once the user authenticates with SSH, they don't have to re-authenticate with the TurboVNC session.)

TurboVNC is like a Swiss Army knife, so there are about 1000 other valid ways to set it up, but using the TurboVNC Session Manager is generally the easiest for new users, since it frees them from having to manually manage display numbers and SSH tunnels and VNC passwords and such. The TurboVNC Session Manager requires that users install the TurboVNC Viewer. It won't work in a browser. However, since the TurboVNC Viewer has an embedded SSH client, a separate SSH client is not required in order to use the TurboVNC Session Manager. I'm just mentioning this because you mentioned SSH.

[jmakov]

Thank you for the quick response. For Debian 12 and KDE the answer was plasma. Regarding SSH the only thing that works for me is SSHing manually, starting the server manually, binding the port locally and starting vncviewer. Everything else results in Bad auth or unknown host (if e.g. I use the hostname from ~/.ssh/config).

[dcommander]

See my reply under the other issue.