openSuSE 13.2 - xinetd - vncserver - xdmcp not working?

I have two nearly identical desktop/servers. One is running openSuSE 13.1 & KDE 4.14, the other is running openSuSE 13.2 & KDE 4.14.

On the 13.1 machine, I implemented remote sessions more or less following these instructions: (I did use the YAST xinetd widget to turn on xinetd and set up the vnc servers.)

I followed the same instructions on my 13.2 machine. Xinetd is running – vncviewer will log into the vncserver, but kdm does not run. I have searched the internet to see if anyone has hints for a working xinetd/vnc server on 13.2, but haven’t found any. I have found a couple of other posts indicating a user is having issues with xinetd/vnc server on openSuSE 13.2.

It may be that I have made an error in my setup on the 13.2 machine, but I have re-checked a few times and don’t see one, both the 13.1 machine and the 13.2 machine seem to be set up the same relative to xinetd, etc.

Vnc is working just fine on the 13.2 machine – I have implemented a workaround that starts a few servers (x0vncserver, a vncserver with icewm, a vncserver with xfce). I would rather have the xinetd/xdmcp system working so that I can select the desktop when I start up the remote and xinetd is a little cleaner than running from a bash script.

Anyone have a working xinetd/xdmcp system on 13.2? Anyone know of bugs, or configuration changes that require different setup steps on 13.2 from those on 13.1?

I haven’t tried to setup what I think you are describing, but is there any difference using VNC instead (especially since you say it’s working fine on your Server now). You would initiate/run each session using its own display id.

The alternative for anyone who wants additional isolation and security would simply run each session using virtualization (like VBox).
It would seem to me that you could also run each session in its own chroot/systemd-nspawn/LXC/Docker/other Linux container, the main reason in this case is to designate and configure a different networking interface for each running instance.



– thank you for your interest and taking the time to reply to my post. I’m posting a lengthy reply to sort of explain the functionality I am trying to achieve, which is a bit different from just worrying about whether xinetd/xdmcp are working or not, per my original post – especially as I implemented that as a workaround for defects in the “Winswitch/Xpra” software relative to openSuSE.

I do have a functional workaround, just as you describe. But, openSuSE and YAST are set up with the xinetd tool, which is a preferable approach. The problem does not seem to be with xinetd, since I do get a working VNC remote instance, but the problem is I do not get a kdm (xdm, whatever) login screen. So, two issues I am trying to solve:

(1) the xinetd session is persistent, available on demand and cleans up after itself.
(2) xdmcp using kdm allows selection of a desktop on startup.

Why is this important? It turns out this is a very easy way to utilize multiple desktops on the same computer, in the same session. As you point out, we can use vbox, but that requires separate installs and divides up the cpu resources.

I stumbled on this by accident – I was using a very nice remote session front end called Winswitch – and it allows the selection of any desktop installed on the server at runtime. This turned out to be a really useful tool, separate from remote computing. I can have windowed desktop session via localhost vnc that are running several different desktops, all accessing my exact same user space. So, for instance, if I would like to test out Enlightenment, I have a full Englightenment session running on my desktop – I can, for instance, put it on Desktop 2 or in a separate KDE Activity. And simultaneously, I can have XFCE and iceWM. This is very useful for getting to know desktop environments without committing to actually use them – because they are all running in my normal KDE 4.14 session.

I would just stick with Winswitch, because it is a great front end for VNC/NX/RDP/Xpra and runs on Linux/Windows/OSX (and beta on Android). However, the developer does not support openSuSE. I’m trying to figure out the python code and find the problem. Winswitch does a great job of serving VNC desktop sessions from my 13.1 server, but it has some authentication issue on my 13.2 server. And then in contrast, my Winswitch will provide Xpra sessions from my 13.2 server, but will not provide VNC desktop sessions. So, I lose functionality when I upgrade from 13.1 to 13.2. Xpra, in case anyone is curious, is a system that allows the server to send individual applications from the server as windows in the client desktop. And my usage goes something like this: my server is way faster than my lowly remote netbook, so if accessing my 13.1 server, I might launch an iceWM desktop remotely, then launch LibreOffice on that desktop and prepare a document. So, I have a bash file “menu” in xterm that allows me to press “l” to launch LibreOffice. If I am using my 13.2 server, I can accomplish the exact same thing – I launch the server application “xterm” via Winswitch/Xpra, run the bash menu, press “l” and LibreOffice will open in a window on my netbook, but it is actually running on the server. I am achieving the same results on both the 13.1 and 13.2 server.

So, where I got all interest in xinted was the discovery that I would not be able to run “xfce”, “icewm”, “lxde” desktops on top of my kde desktop once I upgrade my server to 13.2 due to the above limitation in the Winswitch/Xpra implementation on openSuSE. I then set up the xinetd server on my 13.1 server – it works fine and I thought, “problem solved!” But, when I tried to implement the same thing on my 13.2 server, xinetd vnc did not serve up the kdm login – therefore, I cannot select the desktop at runtime.

Therefore, I did the same workaround that you suggest – I have a batch file that launches two or three vnc session at login, with different desktops. So, if I want icewm I access localhost:1 and if I want xfce I access localhost:2. But, the issue here is that it does not “clean up” on close. So, the batch file has to start out by “vncserver -kill :2” and “vncserver -kill 3:” before launching the sessions, because otherwise I end up with a lot of dead sessions and ever higher port number, 5, 6 , 7, etc. – because vncserver will launch on the next free port.

Don’t know if anyone is interested in or cares about any of this detail, but there are practical applications.

Which brings me back to the practical question – anyone know if xinetd/xdmcp is actually working in 13.2? Are there different setup steps than on 13.1? Because, it’s a useful tool to have a vncserver session that allows choosing the desktop at login.

Or, you know, alternatively, anyone know how to fix the Winswitch incompatibility with openSuSE? Because when they work, Winswitch/Xpra are fantastic tools, making each computer both a client and server via Avahi and Bonjour. It’s just frustrating to “almost” have this awesome capability, but having to implement “workarounds” that are much less awesome.

Before exploring how to address specific issues,

  1. I’d recommend you try one of the pre-packaged Winswitch downloads from the download page
  • You can try the Fedora rpm, rpms from Fedora often will run on openSUSE
  • The generic Java client looks like it might work, albeit with the usual Java overhead.
  1. If you’re installing from source, you should describe exactly your steps and any issues you run into.

More generally,
Although I haven’t looked for multi-display VNC managers for awhile, it’s probably pretty easy to create a web page that does this using the web java client API. AFAIK, all VNC clients should also have native options to specify display options to switch between running VNC instances (and yes, if you don’t shut down a VNC instance, it continues to run even if the remote connection is broken).

In other words, I don’t think that choice of the various remote management/desktop protocols should have any special capabilities over another and xdmcp is just one way of managing remote connections.



Thank you for alternatives. Yes, I have lots of working alternatives. Winswitch – it partially works and I have some dialog with developer on the winswitch email list, but unfortunately, there are some differences in openSuSE from the linux platforms on which Winswitch works properly. But interestingly, although Winswitch will launch xpra application sessions on 13.2, it will not launch desktop sessions. I’m actually studying the python code to try and figure out why this difference occurs between my 13.1 and 13.2 openSuSE installs.

Ironically, I started trying to set up the xinetd vncservers precisely because I could not get Winswitch to offer desktop sessions from my openSuSE 13.2 install as had been possible from my openSuSE 13.1 install. (There seems to be a change between [my? everyone’s?] 13.1 and 13.2 configurations which causes the winswitch authentication to fail – the desktop vnc sessions open and then immediately close. The other irony is that I cannot get winswitch application sessions to run from my 13.1 server (only full vnc desktop sessions), while my 13.2 server will provide xpra application sessions, but not full vnc desktop session.)

The main thing I was pursuing in this thread was to see if I could get xinetd working on my 13.2 server, since it WAS working fine on my 13.1 server. Then, for no apparent reason, it has now stopped working on my 13.1 server. Very odd, since the setup has not changed (except something rewrote my kdm config file and set XCMCP false, but fixing that did not re-enable my 13.1 xinetd vnc servers.) Oddly, xinetd vncservers would not launch in vncviewer, but I had ever higher numbers of “ghost” vnc sessions that I could not clear (eg., vncserver -kill :2 would not work, but vncserver :2 would report an existing session.)

So finally, I disabled xinetd, rebooted and it cleared all the ghost sessions. I’m stuck with my other “work around” which is to launch a few vncservers via script on login, eg. “vncserver -kill :2” to make sure port 5902 is available, then “vncserver :2 -name icewm” to restart that server (I rewrote ~/.vnc/xstartup to launch a different desktop depending on the name parameter, but while I found “icewm-session” will start icewm and “startxfce” will start xfce, “lx-session” and “startlxde” did not launch lxde.)

The difference between an xdmcp login screen and starting specific desktops is that the xinetd sessions are persistent, so if I logout of the vnviewer session (as opposed to just closing the window), the vncserver remains accessible. Whereas if I logout from the icewm session started as above, then the session is closed. (I can restart it by logging into a running x0vncserver session, but that’s cumbersome.)

In any event, I have given up on xinetd for the time being as it must be above my paygrade – now I can’t make it run on either of my servers. So, yeah, I have the alternatives running, just not quite the solution I wanted.

Or, really, I would most like to fix Winswitch so it fully functions on all my computers. As noted, I can retrieve full vnc sessions from my 13.1 computers, I can retrieve and run xpra application sessions from my 13.2 computers – but I can’t do both from either the 13.1 or 13.2 openSuSE installs.