Is there a best practice for starting up a vncserver on a Leap42.1/KDE machine?
My Leap 42.1 machine is AMD graphics running radeon driver.
On my Leap 42.1 server, as a user I am able to start a vncserver from the user command line.
It starts up and reports what screen is assigned to the server, e.g myserver:2.
I am then able to access myserver:2 from another computer on my network(in my case a 13.2/KDE) using KRDC.
My legacy (e.g. 13.2/KDE) method was to enable xinitd.d /vnc.
My attempts to connect to the server started by that method yields a black screen.
I does seem that KRDC is connecting to something, but the display is just black.
Searching about Google, it seems the Arch folks are using a systemd service, not xinitd, to start the vncserver.
But I think sddm might not work via VNC. Try something else, kdm (like in 13.2) e.g.
And to be sure, enable remote administration in YaST->Network Services->“Remote Administration (VNC)” (which would actually also enable the xinitd service), I think there are some other settings necessary in /etc/sysconfig/displaymanager.
I have spent a couple not productive, but informative hours hacking around what does, might and does not work.
I believe my issues with ‘on-demand’ vnc sessions via /etc/xinetd.d/vnc are permissions related; I have fought that battle before but what worked in 13.2, running the vnc session as user=root, does not seem to work in 42.1, yet anyway.
The on-demand vnc sessions are meant to serve up a login greeter, so running as root should not be an issue.
As I indicated , I am able manually start a vnc server from a user Konsole, using ‘vncserver -geometry XxY’, I get a X Display # in response(e.g. :3) and am able to connect via KRDC on the appropriate port (e.g. 5903). The geometry spec seems to be ignored, but I do have functionality.
Both initiation methods end up calling Xvnc, which seems to be hard wired to start a KDE session running on a kdm display manager, but I don’t know how to reveal what dm is actually running - how to tell?
I need to move on to other things at the moment, will pick up from here later in week.
By the way, the sddm display manager does not support XDMCP, and it looks from on line discussion it won’t ever. So the session switch method to create an XDMCP login won’t work.
Yes, in that case, vncserver is serving the current session directly, no display manager is used.
Both initiation methods end up calling Xvnc, which seems to be hard wired to start a KDE session running on a kdm display manager
A KDE session does not run on the kdm display manager.
The display manager is the login screen, and is independent from the user session that’s started then.
All Xvnc does (when run as xinitd services or system service) is start an Xorg session with a login screen (display manager), and serves that via VNC.
but I don’t know how to reveal what dm is actually running - how to tell?
You should be able to tell from the looks.
Or have a look what DISPLAYMANAGER is set to in /etc/sysconfig/displaymanager.
As indicated, sddm is the default in a Leap KDE installation.
By the way, the sddm display manager does not support XDMCP, and it looks from on line discussion it won’t ever. So the session switch method to create an XDMCP login won’t work.
Yes, as I wrote sddm does not suppoprt XDMCP.
I don’t know if it will ever support it (hard to predict the future), but it is on their TODO list, and I think there even was a patch proposed already some time ago to add it (but that got rejected for reasons I don’t know/remember).
But again, kdm is still included, and there are other alternatives as well, e.g. lightdm.
Or you could also try xdm as a test, this is installed by default (as fallback).
Rather than count sheep, I shifted my strategy and decided to copy in the /etc/xinetd.d/vnc file from my 13.2 system, where it works well, to see if I can resolve what I think is a permissions issue on the Leap 42.1 system, where the distro /etc/xinetd.d/vnc setup includes a lot of certificate based enhancements.
No luck with that yet, KRDC still gets a black screen, but that may be because the Leap 42.1 dm is sddm, which may not work with Xvnc.
My next move will be to change my Leap 42.1 system to dm=kdm to see if that is the fix.
Might be a good idea, although the file shipped with the distribution should work.
But note that this is a config file, if you changed it it won’t get replaced by updates.
And your options might not be supported by the current Xvnc.
So it might be a good idea to post your actual content.
Btw, it might be a client problem too. I experienced something like you described in the past (with KRDC), adding “-Protocol3.3” to the Xvnc command line helped in my case (in the /etc/xinitd.d/vnc file). So you might try that too, although I don’t think that’s a problem with current versions.
My next move will be to change my Leap 42.1 system to dm=kdm to see if that is the fix.
But please note that kdm has to be installed too, it isn’t by default on Leap.
All good advice - yes I am aware that my changes won’t keep up with system updates.
I did install kdm, switched to it, rebooted the system, was greeted by kdm login screen, logged in as user1.
I then successfully got a new login screen on my remote machine, via KRDC, from the vnc1 service that started up by xinetd.d.
It of course crashed after login because I used user1 again; I had read that Plasma5 only supports one use (at the moment?) per machine, wondered when that would appear.
No problem, I had a user2 already on the machine, I am in and working as user 2.
As you appropriately point out, the stock xinetd.d/vnc should have worked, I will go back to that to verify before posting a lot of noise here.
This exercise provides a good experience lesson on the separation of duties between dm and desktop(Plasma5).
When they all have ‘unified themes and backgrounds’, it is hard to tell who is in charge at the moment.
That was the same with KDE4 already, at least later versions, and I think GNOME as well (but I’m not sure about that one).
Some people think we should change the display/login managers to not allow multiple logins for the same user at all, I personally think the desktops that don’t support it should present an error message instead (why should I not be able to run multiple IceWM sessions e.g., if it works?).
I seldom am running 2 GUI login’s, except perhaps when I am engaged in debug sessions like this.
I am frequently logged in via ssh and KRDC, getting most of my work done via ssh.
Conclusion: I am back to using the stock /etc/xinetd.d/vnc service definition file. All is running well. the vnc server started by this runs as user=vnc.
So the root cause of my issue was that dm=sddm does not support Xvnc.
I can certainly live with that as long as dm=kdm is available.
I am quite pleased overall with the ease I had in migrating the host machine from 13.2 to Leap 42.1.
I have been running Leap 42.1 on my laptop for a while, learning the quirks but gaining experience.
I have two more 13.2 machines to go; now that I have Autofs fully tuned up and VNC resolved they will be next up.
IMHO, Leap 42.1 is maturing very nicely.
Has some well documented limitations for some folks, but overall I find that major issues are being addressed with well documented work-arounds or updates.
Hi dcurtisfra Many thanks, interesting, in deed! Apparently the VNC server works only with gnome or icewm, according to the document. And the REALLY interesting part would be: How to start the server on booting the machine, as I do it nowadays on several machines running headless with 13.2… Kind regards raspu
The 64 $ question is, do you want to remotely access the Display Managers running on the headless servers or, would you prefer to to it the original X11 way (Managers running on the X11 Server {the user’s Client machine} and only the applications running on the X11 Client {the headless servers})?
If you want to have Display Managers running on the headless servers then, x0vncserver is started as part of the Display Manager (but, not SDDM).
If you want to do it in the original X11 way, then for each application to be displayed on the X11 Server (the user’s machine) the command is basically “ssh -X -C user@hostname command” – with some set-up needed with per user SSH keys and also SSH allowing the users on the Client machines to run the applications on the headless servers without having to type in a password each time an application is started.
<display on remote X server - Network/Internet - openSUSE Forums; and <http://codingdomain.com/linux/remote/x11/>
…thanx for your rply, but you are kinda funny man!
I have here boxes with 13.2, if I reboot them (once a month or so, otherwise always running) I can directly access the TigerVNC server running from my Linux/Win machines and have functional GUI (KDE). Everything else is no help at all…
So, is there a way to get a KDE (is it Plasma 5?) up and running in TigerVNC server with Tumbleweed or Leap?
If the boxes are running 13.2 then, the KDE is almost certainly “KDE4 Plasma” and the X11 Display Manager is almost certainly “KDM”.
KDM has no issues running the TigerVNC server – therefore, it works . . .
Tumbleweed and Leap 42.x run “KDE Plasma 5” by default and, the X11 Display Manager is “SDDM”.
SDDM doesn’t run the TigerVNC server.
[HR][/HR]This thread discusses the issue in depth and has a recipe which works: <Remote administration - Network/Internet - openSUSE Forums.
[HR][/HR]Bottom line: if you’re running KDE Plasma 5 (Tumbleweed and Leap 42.x) and, want to have VNC access then, you need to use one of these Display Managers:
