VNC in OpenSUSE 11

English Network/Internet
21

The remote desktop button in YaST does not work. Disable that to prevent xinetd.d from starting vncserver. Choose an account which will not be used except as remote desktop; this account will be shared. Run vncserver for that account with the correct colour depth and geometry for you MSWindows laptop. You can do this with the cron service for a daily setup when your SuSE box starts up from the BIOS settings. vncserver creates a new directory $HOME/.vnc with an xstartup file which gives a twm xwindow and an open xterm. Replace this file for a more complete desktop. Linux krdc and vncviewer should now work and the tightvnc windows viewer will now perform correctly. Open ports 5801 and 5901 in your firewall and become concered about security and ssh tunnelling when you have this all working.

My recipes for the settings are:

for crontab:

10 07 * * * /usr/bin/vncserver -depth 24 -geometry 1280x800 &

for xstartup:

#!/bin/sh

#xrdb $HOME/.Xresources
#xsetroot -solid grey
#xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
#twm &

unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc

-x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
-r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
startx &

good luck

22

OK, I’m quite a noob too. I tried all I found here, to no effect.
I’m using UltraVNC. The only way it got past the initial screen was to set UltraVNC to use 256 colours. In all other situation, the client started for a few seconds and then collapsed.
In 256 colours the speed is veeeeery bad.
Maybe someone finds a way out of this situation…

23

Really? You tried what I suggested in post#4 above:
VNC in OpenSUSE 11 - openSUSE Forums

Don’t forget to open your firewall to port#22, 5900, and 5901, 5901 etc … if you are using those ports.

24

sorry, I cannot do THAT, I don’t have another PC running suse 10… Just a shitty XP…
If it makes you happy, I’ll give it another go with the rest of the stuff

25

Hi,

I can verify that if you drop the “-SecurityTypes None” section in the /etc/xinetd.d/vnc file as well as change the -depth from 16 to 24, that it indeed starts working again with tightvnc again.

Pete :slight_smile:

26

I am happy to post for my first time a solution. Simple as it is. My Vnc client on openSUSE 11.0 with KDE did not work where 10.2->10.3 did. After hours of studying my options…

install tsclient (GNOME) using yast or probably the click once installer from the download page.
then
at a console window start it by typing tsclient [enter]

use the GUI to configure it; in the Protocol pulldown select VNC no need to worry about protocolfile. Note the client hostname is the computer your connecting from.

27

OK… I’m no expert, but after several hours of mucking around, I think I have the recipe worked out:

  1. when you migrate from OpenSuse 10.3 to OpenSuse 11.1 (probably 11.0 to), the standard set-up for running a vncserver from xinetd will break. This is because in OpenSuse 11.1 Xvnc (which is what is run from xinetd) chokes on the argument “-SecurityTypes None”. (Whereas, it its accepted in 10.3)

To fix this problem, just delete the whole argument. Edit the file vnc in /etc/xinetd.d to look something like:
############################
service vnc1
{
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = -noreset -inetd -once -query localhost -geometry 1150x900 -depth 24
type = UNLISTED
port = 5901
}
############################
(note the -depth 24… discussion coming up)

  1. We are not done yet. OpenSuse 11.1 seems to be very fragile in terms of communications to the clients I use. In my case, I use tightVNC and UltraVNC on Windows XP Professional and Vista Home Premium Systems, over my local 100mbits home network. In many cases below I got erratic behaviour. I would get the OpenSuse splash screen, but the client would close when I logged in. In other cases the client would fail to connect, or appear to hang.

Color Bit Depth:

  • If you set the bit depth to 16 in the vnc xinetd.d file, then the client must choose “8 bit color” or “256 colors”. Otherwise the client will drop.
  • If you set the bit depth to 24, then you can deselect the “8 bit color” (TightVNC) or select “full colors” (ultraVNC)

Encodings and Options:

  • The supported encodings seem very limited.
  • “Tight” works, and may be you best bet as a default
  • “Hextile” does not work! (I think this the default encoding for some vnc clients, so be careful)
  • UltraVNC: The “Use DSM Plug-in” must be unchecked. Its not supported on Xvnc OpenSuse 11.1 server
  • Don’t use “auto” options setting (UltraVNC) or select a “default connection profile” (TightVNC). Most of the time when I tried this things ended badly. I thought the client and server are supposed to be able to negotiate options, but it absolutely does not work… at least for me. Set all your client options manually.

Since I set my server color depth to 24 bit,and I’m on a local 100 mbit/s network. The following options work reliably for me and give a good quality remote display:

UltraVNC:
-uncheck “Use DSMPlugin”

  • select “Tight” encoding
  • select “Full Colors”
  • I have all 4 options checked:
    • Use CopyRect encoding
    • Use cache encoding
    • Zip/Tight Compression (6)
    • Jpeg (Tight) quality (6)

TightVNC

  • select “Tight” encoding
  • unselect "Use 8 bit color
  • select “Custom Compression Level”, Allow JPEG Compression, and “Allow CopyRect encoding”
  1. X11 Video Card Drivers - BEWARE!
  • I tried installing Nvidia X11 and kernel module packages for my video card, and it broke Xvnc. (I did the install from YAST package management from the Nvidia supported repository… nothing fancy). Uninstalling the packages corrected the problem

Notes:

I’ve played around with the 4 CopyRect/cache/zip/Jpeg options, and you seem to be able to vary them to meet your needs without problems.

Also the following encodings seem to work, at least in UltraVNC: ZRLE, ULTRA (selecting UltraVNC’s “ultra” quick option worked for me), ZYWRLE.
Encodings that don’t work: RAW, HEXTILE, maybe others…

I tried a couple of Xvnc arguments (like -deferUpdate), and it cause the server to stop working properly)

I hope this helps. Finally… truth in advertising… I know very little about Linux, and even less about VNC. I figured the above out my trial and error, and reading man pages, etc. So if I’m saying some stupid or obvious things, forgive me. And if people have more information to add, please do so!

Cheers,

Bill Bourne
billb@bashd.ca

28

I probably know less about vnc than you, as I am a user who rarely looks at the code/config behind the gui.

My experience is x11vnc/tightvnc works ( “out of the box” ) with openSUSE-11.1 with KDE-3.5.10. But x11vnc as a server on openSUSE-11.1 KDE4.1.3 has problems and only works if physically started locally, but can not be started remotely from an ssh session.

I don’t think that correlates with your findings but we are talking different vnc apps and that could be part of the reason.

29

Good point… I’m using KDE 4 on my server.

30

Hello,

I have had a similar situation to clauded
> I can remote login with ssh but no go with VNC (on port 5901).

However the Server in question is a 10.3 using KDE
the vnc server is the Suse default Xvnc
the viewer is the latest TightVNC for Windows.
SSH runs perfectly. [P22 or alternative port.]
VNC tunnels correctly on the lab network or from inside the remote network.

However using the Putty SSH Tunnel AND TightVNC over the Internet through the Routers,
VNC says it has opened a connection and connects for a second but then immediately disconnects.
I have tried emulating this in my lab using a

LabPC → DSLLabCiscoRouter → labSuseServer and this all works perfectly as a tunnel (Internal Network)

Using a VNC direct (VNC port forwarding/little security) this works Direct VNC
LabPC → DSLLabCiscoRouter–> Internet → DSLRemoteCiscoRouter → RemoteSuseServer

However trying the same SSH Tunnel setup using the same lab PCs:
LabPC → ISDN → Internet → DSLLabCiscoRouter → labSuseServer

gives the above mentioned problem.
And of course the remote Server gives the same problem.
(Basically the same setup)
SSH runs smoothly (port forwarding only on alternative SSH port through remote Router).

Could anyone explain this or suggest a workaround.
Colour Depth or other parameters etc ?

Thank you

31

You help me, review which is the port in the client software, I was using 5900, after I change everything work fine (Opensuse 11)

32

Greetings All,

I too have had some issues in opensuse 11 AND 11.1 with VNC. I have done a bit of playing around with it, and seem to have narrowed down the issue somewhat, and have a working solution. For me the issue is lack of a mouse cursor when I use KRDC/KDE4 (older version is not in 11.1) when going from an 11.1 to an 11 machine. When I was going from 11.1 to 10.3 it worked fine. Note too that I am not using the KDE4 desktop environ as I think it is not ready for prime time and has too dam many crashes and bugs. I’m using KDE 3.5 on both systems.

Perform these steps on the system you want to host your desktop from (assumes that xorg-x11-Xvnc, tightvnc, LibVNCServer are on if you are running opensuse 11)

  1. Setup and secure openssh and allow it’s port through your firewall. 22 is default, but you can change that if you want. This is the ONLY PORT YOU WILL NEED OPEN TO THE OUTSIDE WORLD! We are going to tunnel VNC (not a secure protocol by default) through openssh. This will secure it pretty well. Note that you WILL NOT need to play with turning on remote administration or anything like that in YaST, just allow SSH through the firewall.

  2. Fire up a terminal and type ‘vncserver’ and hit enter. Set your passwords, and once the vncserver starts running you will see something like this:
    vncserver

"New ‘X’ desktop is <your system’s name>:1

Starting applications specified in /home/<username>/.vnc/xstartup
Log file is /home/<username>/.vnc/<your system’s name>:1.log"

Note that this will be running on port 5901 and 5801 as a java applet that you can connect to with a web browser… If you saw a :2 above it would be ports 5902 and 5802, and so on… :slight_smile:

  1. Kill the vncserver process by typing ‘vncserver -kill :1’ at the prompt. Note that ‘:1’ is the port that your display is running on. The message in step 2 above tells you this.

  2. Now open your text editor of choice and edit /home/<username>/.vnc/xstartup in accordance with how you want your desktop to be. For me, I want the entire KDE3 desktop envirion instead of the default ‘twm’ (I have a pretty fast connection to the internet), so I comment out everything and put in ‘/usr/bin/startkde3 &’ to launch that. SAVE THE FILE IF YOU CHANGED IT! :slight_smile:

  3. Back at the prompt, type ‘vncserver’ again to launch vnc and have it running. You can exit your openssh session if you want.

Perform these steps on the system you want to connect to your remote desktop with:

  1. Fire up a terminal and ssh in to the system running ‘vncserver’ including the command line options that will tunnel your vnc server through ssh over port 22… Here is the command for that assuming that you saw a :1 after your system name when you ran vncserver:

ssh -L 5901:127.0.0.1:5901 -L 5801:127.0.0.1:5801 <IP to ssh to>
The -L options above basically tell openssh to forward the ports from the system you have running vncserver over the secured openssh protocol to your local computer.

  1. Now you can use your web browser to connect to the desktop by putting ‘http://127.0.0.1:5801’ in the address bar! It takes a bit to load… Set ‘Options/Encoding’ to hextile, put in your password and click on ‘OK’ to connect. You can also use ‘vncviewer’ from a terminal to connect. To do that enter in ‘vncviewer’ and enter 127.0.0.1:5901 in the ‘VNC Server’ box that opens. Note that you can change options of your connection by hitting the F8 key in vncviewer.

With either of the connection methods above, I have a cursor that shows in vnc. If I use KDRC/KDE4 to connect, I have no mouse cursor. I can see the desktop though. Buggy. Ick. In KRDC/KDE4 showing the local cursor helps a little but for dark backgrounds it becomes invisible, so not a good solution for me.

Hope this helps someone.

tele2win

33

I know this is a bit of an old thread, but I wanted to pipe in a bit on my experiences with VNC to SUSE from OS X. CotVNC turned out to be agonizingly slow, so I ended up trying out the Enterprise edition viewer from RealVNC. Runs blazingly fast. I would try Tight or Ultra viewers if I knew where to find OS X ports.

34

Here’s what I’d like to know:

How does one prevent openSUSE from automatically logging in and starting KDE under the account that “will not be used except as remote desktop”?

Right now, using this set up (which, by the way, has been the most successful of all the ones I’ve tried to-date), after connecting to my server with my VNC client, instead of giving me a login prompt (like it should and did back in 10.3), I’m now automatically kicked straight to a desktop owned by the same account that has the xstartup script mentioned above in it’s $HOME directory. So if there’s a user named billy, the server skips the login screen and kicks me straight to billy’s KDE desktop.

How do I stop this from happening? I still want to be able to pick which user and which window manager I log in with… How do I instruct VNC/openSUSE to greet me with the Login Window, and not some user’s desktop?

35

PS: God, I hope all of this stuff with VNC gets resolved in 11.2…

Compared to the way VNC worked in 10.3 (literally clicking 3 buttons), trying to get VNC up and running properly in 11.1 is just horrendous.

36

I don’t think I would use the term horrendous. It is disappointing it does not work the same in some ways.

But for what I do with openSUSE-11.1 on KDE-3.5.10 (via konsole commands) it works the same.

If you feel really strong about this, then a good way to try and influence 11.2 to ensure that vnc works the way you like, is to get involved in the later alpha releases, and in the early beta releases. Any later than that and the chance of influencing things are much less.

37

Hmmm… Going from a set-up time of minutes to a set-up time of hours is a pretty huge drop in my book… And I’m still not finished. Horrendous might be a strong word, but after considering the amount of frustration I (and apparently many others) have gone through even to get this far, I’d say it’s justified.

What bothers me is how a regression like this got past the alpha stage… I remember downloading a snapshot late into the 11.1 beta cycle, and although I didn’t put the build through it’s paces, I can almost swear I remember using VNC at least once, and having no problems with it at the time…

I’m not sure, but either way, I’m willing to bet someone’s already aware of the problem, if not already working on a fix… Having an entire (reasonably popular) service break in one release is bound to get someone’s attention before the next release.

As for the auto login problem, I would welcome any suggestions. Any ideas?

38

I can partly explain why.

The reason why is there were insufficient volunteers to alpha test and beta test.

Also, vnc DOES work from konsole for openSUSE-11.1 for KDE-3.5.10. I know that BECAUSE that is the method I use (from konsole). To be 100% certain it would work, I tested that for myself in the alpha and beta releases of 11.1, to ensure I could then install 11.1 on my mother’s PC (where she lives in a different continent), and then access it via vnc a continent away. If vnc is important to one, then IMHO one needs to do that sort of testing. Completely relying on others in an operating system where one pays no money, makes no sense to me. If one has a critical function, then they should test it BEFORE in the alpha/beta.

So I tested that narrow aspect of vnc, and it worked, and it still works. I did not need to spend hours.

Since I do not know ANYTHING about the other methods of using vnc, as a volunteer, I was not going to even attempt to look at those.

I’m sorry to read of your problems. I’m sorry to read of the problems of others. But really, what openSUSE needs is volunteers willing to spend the HOURS during the alpha / beta cycle, testing, writing bug reports, supporting the dev’s in testing the dev’s patches, … spending hours in the POST GM release cycle is the wrong time.

Again, for those reading this thread, PLEASE note that for basic konsole commanding with KDE-3.5.10, vnc DOES WORK the SAME as before with openSUSE-10.1, 10.2, 10.3, 11.0. I use that every week, to take over the desktop of a PC in a different continent.

39

I can understand your exasperation oldcpu, but I must take issue with several sections of your post.

In the first place you tell us that we need to spend more hours in the beta stage, yet you yourself admit to not wishing to bother except where it directly impacts your needs.

In the second: Some of us just weren’t around for that part of the development. Myself included, so we have no choice but to rely on those that were.

Thirdly: However much you protest, the fact is that trying to remote control SuSE 11+ via VNC is horrendous, and I for one am having trouble understanding why it hasn’t been fixed yet.

Finally: Free, unpaid for, whatever. This distro has until now had a first rate reputation, and I use OpenSuSE as an example of how Open Source software works for both individuals and industry. It is also kind of an ambassador for Novell’s SLES which is the way I usually go when I’ve shown that OpenSuSE works to fulfill most of a company’s needs.

BTW I have yet to find a solution to this problem and I’m using KDE 4.xx and 3.xx on different machines.

40

OK, … your points are noted.

And while your points are noted, I take issue with your points.

OK, why should I do more? I am not paid for this. Its a hobby, and I try to contribute. What better to contribute in than areas that help myself the most ? Those are also the areas I know best and they are the areas where my contribution is likely the best. Can you explain why I should test areas that I know nothing about ? Especially since I am not paid for doing this? Especially since I have a family, I have other hobbies … ie believe it or not, I have a life.

Fair enough. No one said you were around before. Rather I stated one reason was there were insufficient volunteers. Why do you take issue with me when I was speaking in general and I did NOT specifically point at you. IMHO that is a totally unfair observation on your part, directed specifically at me. And I take issue with YOU for that.

If vnc is so horrendous, why have I been able to maintain my mother’s PC on openSUSE-11.1 since the start of this year. It works good for me. I have done many kernel updates on her PC, a continent away. I have trained her many times on her PC, a continent away. Does that read like horrendous to you? It does NOT to me.

Now does that mean there are no problems with vnc? No, it does not. Vnc has problems on openSUSE. Vnc on openSUSE does not work across different desktops like it should. Horrendous? No. Badly need in need of testing before being released? Yes. Very much so. vnc needs testers to sort those problems IN ADVANCE. And while we are on that topic, note the time spent typing posts on forums like this can at times be better spent testing a new release. Have you downloaded 11.2 milestone 3 yet to test ? How about milestone 2 ? Milestone 1 ?

Point noted. But why is that an issue with me ?? I don’t own openSUSE. I don’t own Novell. I am a volunteer. Yet you state you take issue with me.

Again, thats unfair. You used my post as a lever, and then unfairly slanted comments at me. Hence I take issue with YOU.

I take issue with your posting style.

Anyway, if you wish to do something about this, NOW is a good time to test 11.2 to ensure the aspects that you consider horrendous in 11.1 are not repeated in 11.2.