serve VGA screen via vncserver [KDE]?

English Network/Internet
1

Hi, I’ve opensuse tumbleweed and I’d like to attach vncserver to the VGA screen - to see over vnc what I have on normal monitor. Now when I run vncserver remotely over ssh, it creates separate KDE session, I can work normally with the computer over vnc, but I cannot continue what I left on the monitor, nor see the login screen when I power up the computer via wake on lan.

Is it possible to see via vnc what I have on monitor connected to remote pc (just like on windows)? I would prefer to run vncserver manually only when I need it (1. ssh me@mysusepc -L 5990:mysusepc:5900, 2. run vncserver on mysusepc, 3. vnc client connect to forwarded localhost:5990 and work, 4. kill the vncserver after all is done or shutdown computer). Thank you.

Btw. would you believe opensuse is currently the only distro that works with my AMD ryzen 5 2400G? I love it :wink:

2

There are x11vnc, x0vncerver and some others. x0vncserver is part of TigerVNC which is the default VNC server for openSUSE. This links describes how to share real screen among other: https://en.opensuse.org/VNC

3

Thank you, I have read that, but it is not very helpful, that’s why I’m asking here. I can launch x0vncserver (which serves actual screen on monitor) from Konsole in KDE GUI, when I am locally connected, then I see the real screen over vnc. But I cannot launch it later from remote ssh session, which is exactly what I’m after - I want to run x0vncserver manually and attach it to tty7 with GUI, but I don’t know how to do that. When I try to run x0vncserver from ssh, I get error: unable to open display “”.

4

Of course you need to set correct display, this is just standard X11 workflow that I assumed you are familiar with. Display depends on your DM, it is either :0 or :1 (GDM will launch second X server). Also note that at least GNOME defaults to Wayland today and Wayland cannot be forwarded at all.

You may need to also set correct XAUTHORITY variable if connection to display is refused, you can check its value in GUI session.

5

JFYI, there is a KDE application named krfb that allows you to share the screen via VNC e.g. Might be easier to use…

Support for Wayland is being worked on (in kwin and krfb), but I think it’s not in yet in the latest stable versions.

6

Your question was a good push for me to review current openSUSE documentation…

It looks like at least for LEAP 15 (and likely Tumbleweed) the architecture has radically changed, and I’m not sure for the better.
Bottom line to answer your question is that configurations don’t seem to be laid out in an easy to view configuration file like before, and now configurations are associated with individual User accounts.

The relevant documentation
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.vnc.html

But, I found that woefully insufficient… and the new architecture is immensely large and complex.
.I’ve not set up multiple configurations, so my “understandings” after the following install steps are part understanding, part speculation, part observation of the available info.

Probably the most important info I’d direct you to is the ending section of the xvnc MAN pages, but that may not make sense until you wade through the LEAP documentation, help file and earlier parts of the MAN pages. Wow. Nothing is that simple anymore unless you bend to just use defaults…

After identifying the likely design basics,
I recommend the following…

  1. Install Remote Administration (VNC) using YaST.
    It seems that xinetd (and an xorg x server) is no longer required and the YaST module integrates with firewalld opening up the VNC default VNC ports for the VNC client and Java web client.

  2. Test whether your VNC server is running, notice that you have to specify xvnc.socket. Unlike previous openSUSE, xinetd is no more. The king is dead, long live the king!(Well, not really. See below)

systemctl status xvnc.socket
  1. Now, I don’t yet see a way to list all existing VNC configurations, only that of 6 existing configurations that only 2 are enabled(one VNC client and one Java client). That’s not too helpful. Interestingly, you will also find the following xvnc service which at the moment I suspect is dynamically created.
/usr/lib/systemd/system/xvnc@.service

OK, now my current observations which are subject to change…

Whereas prior VNC servers were deployed by xorg xservers, now that’s not the case but optionally available. As a socket type service, VNC server is supposed to be actively listening but not actually running. When a client connects, VNC server manually starts up and negotiates a connection with the client. Since multiple VNC clients might connect simultaneously on the same initial port, a new port is negotiated for each client… Sort of how FTP secondary connections is done. Also, if you don’t want the xvnc app to have to start up on demand, supposedly it’s possible to install and run the xinetd as a service like previous VNC versions.

It seems that client configuration files are no longer supported (that I can find).
Instead, the new design seems to be based not on generic configurations but a configuration associated with each User (Boy, I bet that’ll go over well in larger deployments supporting many Users… Not!)
User authentication can be set up a number of different ways, it looks like openSUSE is likely set up to support configured system Users (because of the installed pam module).

So,
Based on my documentation read, that’s your likely road to configuring what you want…
Whether you use a Password file (I might recommend that so the VNC user might not automatically have full locally logged in permissions) or some other form of authentication, you’ll need to configure settings specific to that User.

Minor mention… The openSUSE documentation says that the web client uses Javascript. Unless something has changed and all other documentation is wrong, that is incorrect… The web browser client still uses Java, no Javascript.

Other minor technical thing to look at… Since xvnc now can be accessed both over the network and locally by sockets, I guess that both a network socket as well as Unix socket is now used? Or, something new?

As for your other question about X over ssh, I’m pretty sure nothing there has changed… It’s no longer supported in a default VNC now that VNC has deprecated xinetd somewhat… So, you’ll need to install xinetd for X over SSH.

HtH,
TSU

7

A few more VNC observations and speculation…

Deploying VNC by socket may be a workaround for Wayland… In theory, I’m thinking that the VNC might be able to present the network connection through a UNIX socket, thereby making Wayland believe that even remote network displays could be local displays (pure speculation, will need testing). But, it’s telling that an xorg xserver is no longer required.

Am thinking that new implementation using sockets might be a big performance boost.

But,
IMO it’s sad to see a step backward from the perspective of a Network Administrator, having to individually configure each and every User if defaults are not acceptable.

That is, unless I’m missing something which is very, very possible.

IMO,
TSU

8

I found that the ArchLinux Wiki for TigerVNC might provide answers, and step by step instructions for specific configurations…

https://wiki.archlinux.org/index.php/TigerVNC

In it,
You’ll find
https://wiki.archlinux.org/index.php/TigerVNC#Edit_the_optional_config_file

And the following
https://wiki.archlinux.org/index.php/TigerVNC#System_mode
which is more likely what you should create in /etc/systemd/system/ (copy the existing Unit file using the following command, then modify the display number in the file name)

cp /usr/lib/systemd/system/xvnc@.service /etc/systemd/system/xvnc@1.service

Instead of the system mode link I’m referring you to above, consider the User Mode and Multi-User mode configurations instead.

To my eye,
The above builds on how openSUSE has already set up vnc server.
You do also have the option to set up x0vncserver which is TigerVNC’s own, custom implementation that possibly simplifies but isn’t as versatile as running xvnc server… It’s not set up by default but the Arch Wiki describes how to do so.

Without actually setting up, it looks to me that following the above, a VNC client can specify a particular display number when connecting and a custom configuration will be applied.
Still bothers me a bit that there are supposedly 6 configurations that already exist (2 enabled and active), but no way I’ve yet found to activate or view those configurations.

HTH,
TSU

9

Wow, Mr. TSU, that’s hell of a reply! Thank you for your time and interest in my problem. I admire your knowledge. That will take some time to follow and try :wink:

I will follow the archwiki links, thank you for them, but I cannot get rid of feeling, that we are missing something really easy and following longer yet worse trail. Why when I log in locally, run x0vncserver from konsole, it CAN bind correctly to the VGA screen and then I can see the physical screen perfectly from remote, still I cannot specify this screen from another ssh session or tty? Maybe just the display numbers changed from :0 :1 to something new, just like eth0 has now a name machine specific (+non memorable) and king ifconfig, who ruled linux since year one, is dead. I still hope we just need to provide something like /dev/tty7 and done :
Btw. I have used OpenSUSE several years back and I loved those one click installs from firefox. But as soon as I wanted something, that was two-click in buntus, it appeared to be very complicated in opensuse. This seems to be fine example. Life isn’t easy, is it? :wink:

Thank you, correct display number (or name) is probably the core of the poodle, but which is that in the new KDE? I did not miss the warning in documentation “A machine can reliably accept VNC connections only if it uses a display manager that supports the XDMCP protocol. While gdm, lxdm, or lightdm support XDMCP, the KDE 5 default display manager sddm does not support it.”, yet I see it works, but only when I launch x0vncserver from the logged in KDE session.

Thanks for suggestion, trying it now, but I fail to launch that from another session same as x0vncserver. I will yet have to test it, how will it behave after restart. It told me, that it uses display “HDMI-3”, but it does not see this display name from another sessions.

10

Log into KDE session, check display (echo $DISPLAY) and try to use the same value when starting x0vncserver.

11

Thank you, I thought this will be solution, but it returns the usual “:0” :frowning: So display name is correct, but why is this :0 display not “visible” for x0vncserver when I try to start it from tty1 or ssh?

12

Copy-paste your exact command line and all its output.

13

Sorry if some (or even all) of this is something you already know. Just posting in case it helps.

First, if running SDDM, you would better off switching Display Manager, SDDM does not support VNC properly, yet.

Try LightDM or XDM.

When connecting to the remote machine, you should not connect to it and issue “vncserver” if you want to connect to a desktop that is already logged in, which is what I seem to understand you are trying to do.

Issuing “vncserver” on the remote will start a NEW login instance, spawn a NEW desktop, not the one that is currently running.

If already logged into the desktop on that remote machine, you do not want to issue the vncserver command. You could get a secure SSH-tunneled connection by opening a local terminal and using:

ssh -t -L 5900:localhost:5900 theLoggedInUser@xxx.xxx.xxx.xxx 'x11vnc -localhost -nolookup -nopw -display :0'

Note, of course, the VNC server should already be enabled on the remote machine when you set it up, and the ports should have been opened in the Firewall. If not, set it up, first. If connecting across the internet to a machine behind a router, you need to map the ports to that machine.

Then, you would open a second local terminal, and in there issue:

vncviewer

& in there supply:

localhost:0

I find the most times that wind up with confusing issues is issuing commands that should be local on the remote machine (ie: forget to log out after launching the vncserver) or issuing commands that should be issued on the remote server locally, instead, by mistake.

14

See the link I provided in my prior post to the Arch Wiki article on TigerVNC.
It describes how to deploy and configure x0vncserver, and describes using the default service configuration that declares using display :0. If you want to provide additional configurations, then you should copy the existing Unit file using my previous post’s instructions, and then modify however you wish which can include specifying VGA screen resolution.

TSU

15

Hi guys, thank you very much for support. I have read whatever you suggested, I swithed to lxde and finally I found that the trick is to use existing auth file of x server, which is visible via ps ax | grep auth, maybe it also works with kde, but it has large memory and ssd disk footprint, so I will stay with lxde for now I guess. So this command now connects me to existing lxde screen:

sudo x11vnc -localhost -display :0 -auth /run/lightdm/root/:0 -usepw

**