100% Working VNC Solution in 11.1... except one minor catch

English Network/Internet
1

Howdy all,

So I’ve done quite a bit of research, and thanks to a lot to this forum, other forums, a few websites, and copious amounts of trial and error, I’ve got a solution to get almost painlessly get VNC up and running on openSUSE 11.1. There’s one minor hitch, but that’s at the very end, and I’m hoping all of you will be able to suggest ways to fix it.

So, let’s dive right into Todd’s Guide to get VNC up and running on openSUSE 11.1.

  1. Login in as someone who is not root.
  2. YaST -> Software -> Software Management. Search for “vnc” and then make sure that “tightvnc” and “xorg-X11-Xvnc” are selected and up to date. I right-clicked both packages and selected “Update” from the context menu just to be sure.
  3. Restart.
  4. YaST -> Network Services -> Network Services (xinetd). Make sure all every service that has to do with VNC is off. Hit Finish. Now go back to YaST -> Network Services -> Network Services (xinetd) and turn on just the first VNC services (which would be vnc1 and vnchttpd1).
    4)YaST -> Network Services -> Remote Administration (VNC). Make sure that the radio button next to “Allow Remote Administration” is selected, but that “Open Port in Firewall” IS NOT SELECTED. (I know, I know, but keep reading.)
  5. YaST -> Security and Users -> Firewall. Go to the “Allowed Services” entry on the list to your left. Make sure that “External Zone” is selected. In the list provided, you may see a few entries that have to do with VNC. Delete all entries related to VNC. Hit Next, then click Finish.
  6. YaST -> Security and Users -> Firewall. Go back and make sure that this list is clear of all VNC items. Once it’s clear, under the drop-down box entitled “Service to Allow” you should see 3 things that have to do with VNC:
    -VNC
    -VNC Server
    -VNC mini-HTTP server
    Select only “VNC” and then click Add. The only allowed service should now be VNC. Hit Next, Hit Finish.
  7. Close out YaST, open up Terminal.
    6.1) Type vncserver.
    6.2) Set a password.
    6.3) I chose not to allow “view-only” mode, so I didn’t need to set a password.
    6.4) Once finished, you should be brought back to the Terminal.
  8. Type this:
mkdir ~/.vnc
  1. Then this:
vim ~/.vnc/xstartup
  1. In vim, write the following if you’re using KDE 3.x:
#!/bin/sh
/usr/bin/kde &

Or the following if you’re running KDE 4:

#!/bin/sh
/usr/bin/startkde
  1. Save and quit vim.
  2. Once back in Terminal, type
vim ~/bin/vncservice.sh
  1. And then type this:
#!/bin/sh
rm /tmp/.X11-unix/X*
vncserver :7 -depth 16 -geometry 1024x768
  1. Save and quit vim.
  2. Once back in Terminal, type the following
crontab -e
  1. This should bring up vim again (or whatever your editor is). Add the following line to your crontab
@reboot /home/YOUR_USER_NAME/bin/vncservice.sh

Of course, making sure to replace YOUR_USER_NAME with the user you’re currently logged in as right now.
16) Save and quit vim.
17) Close Terminal.
18) Restart.

After your server restarts, you should notice two things:

First, connecting to SERVER_IP:5901 works. Even though the radio button under YaST → Network Services → Remote Administration (VNC) → “Open Port in Firewall” IS NOT SELECTED, it still works. You can connect using a standard VNC client (I’m using JollyFastVNC from Mac OS 10.5), and you’ll be presented with a standard login screen just as if you were actually there at the keyboard/monitor/mouse. I’m not sure why this is working in the first place (shouldn’t the firewall be blocking this?) but that doesn’t seem to bother me so much. I can just go back and disable the service under YaST → Network Services → Network Services (xinetd). What bothers me is the fact that persistent sessions don’t seem to work… If you close out the JollyFastVNC window, and you’ll lose the connection and your session. You will be able to reconnect to the server, but you’ll be presented with the login screen again - you won’t actually be able to resume your session where you left off.

The second thing you’ll notice is that, connecting to to SERVER_IP:5907 works (as you would have expected), but this time, instead of being presented with the login screen a la :5901, you’ll first be asked for the password you set in step 6.2, and once supplied, you’ll automatically get kicked straight to a desktop (without any login screen). When the command “whoami” is issued on the Terminal, you’ll be told that you’re the same user who performed all of the above steps. Closing the JollyFastVNC window and then reconnecting will yield a persistent desktop (i.e.: if you open up a text editor and type something, after closing then reconnecting, you’ll find your desktop and text editor haven’t gone anywhere with all your work intact just as you left it.). While this is what I want, it’s not very secure, and won’t work in environments with more than one user.

Thanks to this forum, as well as the help of many others, I’ve gotten this far, but I’m stuck on the last step… How do I keep my persistent sessions (a la :5907), but still force those connecting via VNC to login via the login screen (a la :5901)?

I’m sure it must be an easy fix, I just don’t know how to go about it.

Sources:
VNC HOWTO - openSUSE
TightVNC (VNC Xvnc) on openSUSE as Client or Server (Remote Desktop Connections)
VNC in OpenSUSE 11 - openSUSE Forums
How to add another Gnome or KDE session at the login screen? - Ubuntu Forums
VNC Hell - openSUSE Forums

2 
How do I keep my persistent sessions (a la :5907), but still force those connecting via VNC to login via the login screen (a la :5901)?

The crontab :5907 process is started by a particular non-root user so you have to log is at that same user whereas the xinetd :5901 process is started by root as no particular user so you can log in as any valid user.

The xinetd process is designed to shut up the shop when the old client leaves and get ready for anyone at all, not just the previous client. If that didn’t happen, whoever came first would be the only client to be able to connect for eternity (or until the power failed and the computer reset).

The :5907 job is always the same client, only one client is valid, so it’s OK to leave the same screen connected. To switch that off for security you must log off and it will close pending the next reboot. That’s what happens with windows VNC servers – they’re set for a single password (which is tantamount to a single client I suppose).

I suppose you have to decide which mode suits you.

It looks like you’re using the KDE3 desktop because you made no mention of dbus-launch. Perhaps you should mention dbus-launch for the KDE4 users.
Reference: TightVNC Server Running as a Service

Regarding the firewall: when you open that “VNC” channel in SuSEfirewall2 it opens 100 ports – which series includes both 5901 and 5907 through.
Reference: Services that are Pre-Listed in the Firewall Allowed Services Module

3

Wow… that was a really informative response… Thank you!

So (just to make sure I understand), what you’re saying is that you can’t have it both ways, and that’s just the way VNC works? That you trade persistence for being able to log in as different users?

Is there a solution out there that will let me keep both persistence and the opportunity to log in as different users?

I’m basically looking for a solution that will be indistinguishable from physically interacting with the computer using the local keyboard/mouse/monitor.

In the physical world, I could at this very moment, walk half way across campus to this server, sit down, and log in as any user I wanted to. After logging in, I could then do some work, lock my workstation, and then walk away. If the monitor got unplugged and relocated while I was away, all I would have to do is find some new display, haul it back to the workstation, plug it in, unlock my workstation, and all of my work would still be there, waiting for me just the way it was when I left. I could then finish my work, log out as that user, and then log in as a different user to perform a different task… etc., etc.

Is there any way to achieve this with VNC over a network? I need something that isn’t going to cause me to lose all of my work if some hiccup in the network temporarily severs my connection.

The crontab :5907 process is started by a particular non-root user so you have to log is at that same user whereas the xinetd :5901 process is started by root as no particular user so you can log in as any valid user.

I see - and I thought maybe if I took the crontab entry out of the regular user, and stuck it under root’s crontab, that might fix things, but it apparently doesn’t… Trying to log on to the VNC server just results in an immediate “Connection closed.” message on the client.

4

Also, wow! You’re swerdna! You’re one of the top Google responses returned when searching for the terms VNC and openSUSE, and one of the first sources I found who actually got me anywhere…

This page of yours was beyond helpful when I first started out on this a few days ago:
TightVNC (VNC Xvnc) on openSUSE as Client or Server (Remote Desktop Connections)

Thank you! lol!

5

Is there any way to achieve this with VNC over a network? I need something that isn’t going to cause me to lose all of my work if some hiccup in the network temporarily severs my connection.

Scenario 1: Suppose you’re doing some task, normal fashion, on a workstation, not over a network. If you want the work to endure you save it from time to time. It’s the same as working over a network IMO.

Scenario 2: Connect to the server using your username by VNC in :5907 mode and save the work periodically. Same situation – saving the work locks it in storage on the foilesystem.

It doesn’t matter if the workstation goes down in the first scenario or if the network glitches in the second scenario. If you save the work from time to time it’s not a problem.

My wife works every night to a server in a town 100 miles away (Brisbane – Toowoomba). Saves stuff from time to time. Prints to their printers, etc. No problems – it’s identical to working at the physical screen, except the coffee’s better here.

Anyway, the limitations are the limitations, I suppose.

6

Great compliment/s, thanks, glad to help.