Yast Remote Admin (VNC) module - multiple issues/questions

English Network/Internet
1

Hi,

KDE desktop.

I want to access a LEAP 42.3 box in the LAN (ethernet, CAT5) from another box (oS 13.2) in the same LAN. I don’t want to allow remote connection outside the LAN. I want a full remote desktop to run software in the LEAP box from the oS 13.2 box, if possible with copy/paste between boxes.

LEAP box:

There’s a VNC module in Yast that AFAIU allow activation of a VNC server. In this module I can select “Allow remote admin”, with or without “session management”, but the Firewall configuration in the same dialog say the firewall is disabled. However the Firewall module say it is being executed. Why?

The LEAP box ethernet interface is configured as external zone (it was unassigned at first). I did include VNC on the firewall allowed services, but the VNC module still say firewall is disabled. I haven’t yet try to connect with a client.

After selecting any of the two “Allow remote admin etc…” on exiting the module the LEAP box drop to the first terminal (ALT+CTRL+F1). The graphics (ALT+CTRL+F1) terminal is just a black screen with a blinking cursor IIRC. All others except F1 are pure black, no cursor. I can log to root, but “reboot” does nothing, and appear to freeze the terminal. “reboot -h now” works after maybe 20-30 seconds. Then the box powers up normally to KDE.

This drop to terminal also happened on the first run of the module after it installed a xorg-x11 package that pulled a number of dependencies:

>rpm -qa --last | grep “19 Set 2017”
proxymngr-1.0.4-4.1.x86_64 Ter 19 Set 2017 19:06:10 -03
xwud-1.0.4-14.1.x86_64 Ter 19 Set 2017 19:06:09 -03
xwininfo-1.1.3-10.1.x86_64 Ter 19 Set 2017 19:06:09 -03
xtrap-1.0.2-14.2.x86_64 Ter 19 Set 2017 19:06:09 -03
xprehashprinterlist-1.0.1-14.1.x86_64 Ter 19 Set 2017 19:06:09 -03
xplsprinters-1.0.1-14.1.x86_64 Ter 19 Set 2017 19:06:09 -03
xfsinfo-1.0.5-7.1.x86_64 Ter 19 Set 2017 19:06:09 -03
xf86dga-1.0.3-14.1.x86_64 Ter 19 Set 2017 19:06:09 -03
xdpyinfo-1.3.2-4.3.x86_64 Ter 19 Set 2017 19:06:09 -03
showfont-1.0.5-6.1.x86_64 Ter 19 Set 2017 19:06:09 -03
libXprintUtil1-1.0.1-15.3.x86_64 Ter 19 Set 2017 19:06:09 -03
lbxproxy-1.0.3-10.1.x86_64 Ter 19 Set 2017 19:06:09 -03
fstobdf-1.0.6-6.1.x86_64 Ter 19 Set 2017 19:06:09 -03
fslsfonts-1.0.5-6.1.x86_64 Ter 19 Set 2017 19:06:09 -03
xwd-1.0.6-10.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xvinfo-1.1.3-4.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xvidtune-1.0.3-12.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xstdcmap-1.0.3-10.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xsm-1.0.3-10.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xsetpointer-1.0.1-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xsetmode-1.0.0-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xscope-1.4.1-6.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xrx-1.0.4-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xrestop-0.4-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xrefresh-1.0.5-8.3.x86_64 Ter 19 Set 2017 19:06:08 -03
xpr-1.0.4-14.1.x86_64 Ter 19 Set 2017 19:06:08 -03
xmore-1.0.2-14.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xman-1.1.4-6.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xmag-1.0.6-4.2.x86_64 Ter 19 Set 2017 19:06:07 -03
xlsfonts-1.0.5-4.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xlsclients-1.1.3-9.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xlsatoms-1.1.2-4.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xlogo-1.0.4-13.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xload-1.1.2-10.2.x86_64 Ter 19 Set 2017 19:06:07 -03
xkill-1.0.4-9.2.x86_64 Ter 19 Set 2017 19:06:07 -03
xkbutils-1.0.4-10.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xkbprint-1.0.4-4.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xkbevd-1.1.4-4.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xinput-1.6.1-10.1.x86_64 Ter 19 Set 2017 19:06:07 -03
xgc-1.0.5-6.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xgamma-1.0.6-4.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xfwp-1.0.3-10.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xfs-1.1.4-8.2.x86_64 Ter 19 Set 2017 19:06:06 -03
xfontsel-1.0.5-9.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xfindproxy-1.0.4-6.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xfd-1.1.2-9.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xeyes-1.1.1-13.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xev-1.2.2-4.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xedit-1.2.2-6.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xditview-1.0.4-6.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xdbedizzy-1.1.0-14.1.x86_64 Ter 19 Set 2017 19:06:06 -03
xcursorgen-1.0.6-6.1.x86_64 Ter 19 Set 2017 19:06:05 -03
xcompmgr-1.1.7-6.1.x86_64 Ter 19 Set 2017 19:06:05 -03
xcmsdb-1.0.5-6.1.x86_64 Ter 19 Set 2017 19:06:05 -03
xclock-1.0.7-9.1.x86_64 Ter 19 Set 2017 19:06:05 -03
xclipboard-1.1.3-10.2.x86_64 Ter 19 Set 2017 19:06:05 -03
xcalc-1.0.6-6.2.x86_64 Ter 19 Set 2017 19:06:05 -03
xbiff-1.0.3-12.1.x86_64 Ter 19 Set 2017 19:06:05 -03
xbacklight-1.2.1-8.1.x86_64 Ter 19 Set 2017 19:06:05 -03
x11perf-1.6.0-4.1.x86_64 Ter 19 Set 2017 19:06:05 -03
viewres-1.0.4-9.1.x86_64 Ter 19 Set 2017 19:06:05 -03
twm-1.0.9-6.2.x86_64 Ter 19 Set 2017 19:06:05 -03
smproxy-1.0.6-6.1.x86_64 Ter 19 Set 2017 19:06:05 -03
rstart-1.0.5-8.1.x86_64 Ter 19 Set 2017 19:06:05 -03
rendercheck-1.5-4.1.x86_64 Ter 19 Set 2017 19:06:04 -03
oclock-1.0.3-14.1.x86_64 Ter 19 Set 2017 19:06:04 -03
mkcomposecache-1.2.1-12.1.x86_64 Ter 19 Set 2017 19:06:04 -03
listres-1.0.3-13.1.x86_64 Ter 19 Set 2017 19:06:04 -03
libXxf86dga1-1.1.4-8.3.x86_64 Ter 19 Set 2017 19:06:04 -03
libXTrap6-1.0.1-12.3.x86_64 Ter 19 Set 2017 19:06:04 -03
libXp6-1.0.3-4.3.x86_64 Ter 19 Set 2017 19:06:04 -03
liblbxutil1-1.1.0-15.3.x86_64 Ter 19 Set 2017 19:06:04 -03
libFS6-1.0.7-4.3.x86_64 Ter 19 Set 2017 19:06:04 -03
libdmx1-1.1.3-8.3.x86_64 Ter 19 Set 2017 19:06:04 -03
ico-1.0.4-12.1.x86_64 Ter 19 Set 2017 19:06:04 -03
fonttosfnt-1.0.4-14.1.x86_64 Ter 19 Set 2017 19:06:04 -03
editres-1.0.6-11.1.x86_64 Ter 19 Set 2017 19:06:04 -03
bitmap-1.0.8-6.1.x86_64 Ter 19 Set 2017 19:06:04 -03
xorg-x11-7.6_1-19.3.noarch Ter 19 Set 2017 19:06:03 -03
xorg-scripts-1.0.1-15.1.noarch Ter 19 Set 2017 19:06:03 -03
xcursor-themes-1.0.4-9.1.noarch Ter 19 Set 2017 19:06:03 -03
beforelight-1.0.5-12.1.x86_64 Ter 19 Set 2017 19:06:03 -03
bdftopcf-1.0.5-4.3.x86_64 Ter 19 Set 2017 19:06:03 -03
appres-1.0.4-9.1.x86_64 Ter 19 Set 2017 19:06:03 -03

I’d like to use oS native VNC server instead of installing another one, if that makes sense.

So, my issues/questions are:

LEAP box:

  1. Is the “firewall disabled” info on VNC module relevant? I haven’t installed a client in the other box yet (see below).

  2. Any way to fix this drop-to-terminal thing, or is it worth a bug report?

  3. Is there a better/safer way to set the server for LAN user, using another program, perhaps?

oS 13.2 box:

  1. What client should I use? There are a number of clients in oS 13.2 repos, like GTK-vnc, novnc, etc. Or another one?

Thanks,

Bruno

2

Make sure TigerVNC and x11VNC are installed on both machines.

By far the best method, IMHO, is to use that combination and to do so through SSH, so it is completely secure. You do not have to turn Remote Administration (VNC) on in Yast. I have it turned off on my machines and I am connecting just fine.

All you need to know is a login name and the related password on the other PC, you do not have to open any Ports in an external router if you are staying within the LAN, so leaving those closed will give you tighter security.

To access one machine from the other, the User on the machine you are accessing should be logged in. (It can be done without the User logged in, but an additional step is required, and I do not want to confuse the instructions here.)

Now, on the machine you want to use to access the other, open a terminal and issue:

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

Where YourUser is the signed-in user on the machine you want to access and the xxx.xxx… is the LAN IP address of that remote machine.

This creates a secure SSH connection to that machine and ties it to your localhost on the machine you are connecting from.

You will see some minor errors mentioned, ignore them.

Now, open a second terminal window, not the same one you did the above. In that second terminal, issue:

vncviewer

A little dialogue window will pop up.

In the VNC server box, enter:

localhost:0

then click on the Connect button.

You might notice that there is a message that the connection is not secure … ignore that. It actually is secure because the connection is in an SSH tunnel.

3

I’d highly recommend reading and following the community openSUSE documentation on this topic

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

Looks like it’s undergone a radical re-write recently, IMO with mixed results. Some important details like the vnc server configuration file is a bit more prominent now, but it’s less clear exactly how the vnc server is set up and can be modified… And it’s different than how it was set up for many years up to a few ago.

Unless you have a reason to configure persistent session management, I’d recommend you set that aside at first.
More importantly, you should know that when you install using the YaST Remote Administration module, the “One Time VNC Session” configuration is set up by default.

I do not recommend installing VNC by any other way, otherwise you will not be guaranteed to have a known standard configuration when you post in these Forums, and additionally I feel strongly that setting up vnc server to use /etc/xinetd.d/vnc is better than allowing clients to try to pass display variables.

I’ve set up a few 42.3 VNC servers and haven’t seen the problems you’re describing.
Did you update your system before you tried to run the YaST Remote Administration module? Run the following if you haven’t already…

zypper update

TSU

4

I am running the setup I showed.

I have never had any problems, have used this for a long time.

I am currently using it in my own network connecting flawlessly, quickly, and securely back and forth between PCs running 13.1, 42.1, 42.2, and 42.3, no issues, quick and slick.

Connections are not persistent, and this is a widely-used method (even covered in the openSUSE documentation).

5

I’m sure your setup can run fine, and it has many of the characteristics how I used to set up VNC for many years.

Just saying… There’s nothing necessarily bad about running your own system the old way if you feel comfortable with it, but there is a better, more “enterprise” way to do it today that’s more modular and is centrally managed from the VNC Server.

And, if you have problems with your setup,
Deviating from standard documentation means that you’ll have to be very detailed in your description(or provide a reference for what you did)
but if your setup is consistent with known documentation, then it’s a known scenario.

TSU

6

… which it is.
https://en.opensuse.org/SDB:VNC_usage#Using_ssh_to_establish_a_secure_VNC_session

7

Fraser and TSU, thank you for your insight and links.

On further thought I may have jumped the gun, so to speak, orienting my question by VNC, when it should have been more generic in terms of what I’m trying to accomplish.

The LEAP (server) and the 13.2 (client) boxes are in the same room. The LEAP box dual-boot with w10, so, ideally, both OSes would use the same server protocol so there is only one client application. Also the connection should be simple (like for lazy people like me :P). Since w10 is in the equation I thought of rdp, which led to KDE’s implementation of. I’m aware that it’s no big deal to install a vnc server in windows, I just tend to try the native solutions first. And krfb/krdc have simple, easy to use GUIs.

The SDB linked by Fraser warns that

As of SuSE11.0 and 11.1 the KDE apps krfb and krdc are broken. In particular krfb does not serve up a valid rendering of the display and it is badly corrupted with false color blocks and dual images. KRDC will often crash and lock up regardless of what type of server it is connecting to. Both problems have been reported but there appears to be very little activity happening to get these tools repaired… See below on how to use x11vnc to establish a VNC connection to a live remote desktop for some alternate methods.

This appear to have changed somewhat since 11.x, since I could connect to krfb on LEAP with krdc on oS 12.3 using vnc, but not using rdp (some issue with authentication a bit over my head).

The issues with krfb/krdc were mouse lag/jumping and constant high bandwidth usage at approx 10.5 MB/s (85 Mb/s), probably capped by the server (configured for LAN) as the LAN is gigabit.

Another thing that occurred to me is if I’m not complicating issues unnecessarily. The LEAP box currently is connected to a 1280 x 1024 monitor, and the client have two 1920 x 1200 screens, and using vnc, even in the full screen scaled mode I get a letterboxed remote desktop, and I’d like it to be true fullscreen on the second monitor, so I could get more real state to run the server applications (windows-only structural analysis software, basically).

Since X is a server, wouldn’t it be possible to start a desktop session directed at the client screen? The server local monitor need not be connected to the user’s session, cloning the display. I’m not sure I’m being clear here.

What do you think?

Indeed I have, earlier the same day. Only three packages if memory serves. KDE updater (or whatever the name is) is active.

Thank you,

8

P.S.: Perhaps nomachine is an option. And the arch wiki is an interesting read too.

9

You could also check out Teamviewer. It has both Linux and Windows versions, and can be set to allow connections like you want.

It is free for non-commercial use, but quite powerfull.

… and, yes, several people here use it, as well.

10

Any User can use whatever might work as long as the setup is described in detail when/if you ask for help.

I’d still recommend the current openSUSE docs in this case (IMO openSUSE docs on this topic are fairly good).
The referenced SDB was originally created in 2010, and describes how things had to be set up then.
But, that is then and today there have been improvements which you might or might not want to take advantage of (AFAIK hardly any VNC “old way” doesn’t still work).

An important concept to notice in the SDB is that a main purpose was to set up a specific type of connection… Shared Desktop, for instance as a Help Desk tool so that the local User can see what the remote Admin is doing on the machine. If you want this kind of connection, it’s called “Persistent Connections” in the openSUSE docs. For simply connecting to a remote machine and <not> sharing a Desktop, you would use the much simpler “One-time VNC Sessions”

As for encrypting the connection,
As the openSUSE docs describe, today this is supposed to happen automatically and is default unless there is a missing or faulty configuration.
Sure, you can still wrap the VNC session in SSH if you wish, but only if you wish to do so.

As for performance…
I haven’t had to test VNC over a low bandwidth connection for many, many years so I can’t be sure how well it works today but I’m
unaware that the VNC internal graphics architecture has changed since early development.
When I did run VNC over telco dialup (yes, that long ago), several things were noticeable…

  • I had to drop down to 16-bit color
  • I had to run VGA (640x480)

And so, in those days I preferred connecting specifically to MSWindows machines over slow links using rdp protocol apps because

  • System graphics were integrated into the OS in those days. Today, this is the default in Linux as well.
  • Perhaps related to the kernel mode graphics, the data stream was much less, perhaps also related to caching and use of differential rendering which AFAIK is still not implemented in VNC today.

The reason why I described the above is that although much likely has changed over time, some or many of those rdp “advantages” may still exist. Then again, if you have enough bandwidth and with today’s much more powerful machines those differences might not show up so often. And even the rdp advantages I described would be apparent only when connecting to a MSWindows machine.

Bottom line is that there may not be a “one size fits all” answer to your situation, you may have to test various remote Desktop apps.

And don’t overlook passing X over SSH, I find that to be very, very performant connecting to Linux today. On openSUSE, all you need to do is to install the VNC Remote Administration server using YaST and you’ll be all set up to accept X over SSH connections. If you’re connecting to a Windows box, of course SSH isn’t native, but you could install a special X server (but I’d generally recommend an rdp app instead).

HTH,
TSU

11

Even I face similar problem with VNC in my set up. I found following workaround

  1. Enable ssh service in your server machine and permit in the firewall.
  2. Using your client, login to server thr’
ssh user@server
  1. After successful login, type
vncserver

.
4. Prompt will show the port (5901 or 5902 or…)
5. Using any of VNC viewer software, type

server:5901

..... U will be able to access  server thru client.
12

Not sure what you mean, but if you have firewall enabled and interface belongs to restricted zone, then port won’t be opened for incoming connection. You can do it manually later of course. Sounds like a bug.

Note that by default VNC server that is enabled will use public key authentication.

  1. Any way to fix this drop-to-terminal thing, or is it worth a bug report?

I do not see it with lightdm and XFCE.

  1. Is there a better/safer way to set the server for LAN user, using another program, perhaps?

SSH?

13

… which, of course, is done using this method::wink:
https://forums.opensuse.org/showthread.php/527237-Yast-Remote-Admin-(VNC)-module-multiple-issues-questions?p=2838747#post2838747

14

I’ve also experienced this issue on multiple openSUSE Leap and Tumbleweed installs.

The problem is…

Whenever you enable remote access via Yast it crashes the xserver - this is a bug which needs fixing!

15

You’ll have to be very specific about how you’re set up and invoke your VNC Server,
When I review this Forum thread, I count <at least> 3 main ways described.
Every described way can work, but if there is any problem, that problem will be unique to that specific setup.

If your x server crashes, would it be because contention, ie an x server is already running using same resources when you invoke another?
It’s why in my posts, I described reading and following the Community Documentation, because when you install using the YaST Remote Administration module, it’s a particular setup that sets up VNC in a specific way. If you then go your own way and do something that doesn’t conflict, then it should still work… else… possible problems.

TSU

16

What he means is that when you go into Yast and enable remote admin, then click ok (or whatever, I’m not going to try it again), your desktop immediately crashes, and you find yourself at run-level two (or three – I didn’t test my network).

17

Never seen that, personally.
Would likely be uniquely specific to a particular system which would make it difficult for others to help.
Most likely if something caused something so major as a complete crash happens, then the User should boot up, and when a terminal console can be launched (can be a windowed console), run the following which will display the system log entries of the previous session just before the crash

journalctl -rb -1

TSU

18

You need to change your Display Manager from SDDM. If using Plasma, install and switch to KDM.

19

Reported as bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=1080305