Remote desktop access -- more experimentation.

Well, there certainly is no shortage of means to let you access and control a distant desktop from the comfort of your own desk as shown in this article.
As I had had some problems with xncviewer, particularly from KuruminNG (Dell), I decided to try one other app listed in this article. This was x11vnc.
First, I tried to access Foresight (on the Dell) from Ubuntu (on the Mac). The steps are very simple and are as follows:
1. Download/Install x11vnc on the remote desktop (Foresight-Dell). For this I used:

sudo conary update x11vnc=@fl:2-devel

2. Start up the remote server by typing this in a terminal
x11vnc -display :0
3. In the client (your own computer or Ubuntu-Mac in my case), type this
vncviewer 192.168.1.12:0
and almost immediately, Foresight's desktop appeared on the Mac. Note that sshd was NOT running on Foresight at the time and NO passwords at all were required. Absolutely nothing, very quick and problem-free.

Note that in Ubuntu, I needed to download xtightvncviewer (one of four suitable apps available) before vncviewer would work.
Really, this whole thing, including the downloads, installs and connections could easily be set up in less than 5 minutes.

Flushed with this success, I tried to see if I could control KuruminNG (Dell) from Ubuntu-Mac. Here the steps were:
1. Install x11vnc in Kurumin

sudo apt-get install x11vnc

2. In a Kurumin terminal, type

x11vnc -display :0

3. In Ubuntu-Mac, type

vncviewer 192.168.1.12:0

Once again, connection was almost immediate with no requests for passwords or anything else.

Now, the area where I had a problem with Kurumin before, controlling another Linux desktop from Kurumin as client. So, for this I tried:

1. Install x11vnc in Ubuntu-Mac

sudo apt-get install x11vnc

2. In Ubuntu type

x11vnc -display :0

3. In Kurumin type

vncviewer 192.168.1.1:0

For the third time, everything worked perfectly, absolutely no flaws whatsoever. However, there was a difference from the last two attempts, in that this time, after the third step in Kurumin (vncviewer), a window appeared in Ubuntu asking did I want to accept or refuse the request to control the desktop. Once I said yes, connection was immediate.

My conclusion based on this very brief and incomplete test is that x11vnc seems quite a marvelous app and well worth trying again.
One big difference from NXserver, is that the client sees exactly what is on the servers screen right now. Also, the clients cursor moves around the servers screen.

VNC in openSUSE 11.0

As I use KDE 4.1 in openSUSE, I used krfb to enable me to communicate with either Ubuntu or Foresight on the Dell.
krfb is available in the K-menu (the Gecko icon) and clicking on it sets krfb running and puts an icon in the panel.
Clicking on this icon opens the krfb dialog where you can create invitations.
For Ubuntu or Foresight (Dell) to connect to openSUSE (Mac), you just type (client)

vncviewer 192.168.1.x

After supplying the password, you'll be connected.
At times, however, I found that connection did not occur but gave a message that the connection was made but apparently broke.
A reboot followed by a retry gave a connection in the few times I tried this.
The quality of the connection was not good, however, in either direction as the windows on the remote desktop wouldn't move.

VNC from Ubuntu-mac (client) to Kurumin-dell (server)

I had this problem some time ago where I could not VNC from Ubuntu-mac (vino-server) to Kurumin-dell (krfb-kde4). Tried again today with the same negative result.
Then I thought that perhaps it was a kde thing so I tried with Sidux-mac (Kde 3.5.9) which also uses krfb. In Sidux, however, opening krfb results in a dialog box opening which allows you to create invitations. This gives you a password to pass on to the invitee which can then be used to complete the connection. Now I could connect from Kurumin (client) to Sidux (server) but not the other way around. This seems entirely because the krfb dialog doesn't open (although krfb does run) so invitations can't be created.

OK, so maybe it's a KDE4.1 thing. So, I changed session in Kurumin and changed to KDE 3.5.9. For this I had to install krfb (KDE 4.1 uses krfb-kde4). Now krfb does open a dialog box (but seemingly only from a terminal and not from Adept). This then allows creating invitations. So, I invited Sidux as client to connect to Kurumin server. Th connection was briefly made but then krfb crashed (I tried this several times, always with the same result). But, it was progress of a sort. I posted to the Kurumin forum which provides more details.

I got one reply from this post which didn't actually address the problem but recommended that instead of VNC, that I use NXServer to make these connections.
So, I thought I'd give it a try.
First I looked at the freenx home site and tried to install the package from here. But the instructions are poorly presented so I gave up.
Next I came across this blog which outlines an alternative (and more understandable install method) but this too failed for me during the make step.
Then I found this Ubuntu Community document which provides basically everything I needed.

So I set about setting up Kurumin-Dell as the server with Ubuntu-mac as the client and these are the steps:
1. Include the debs in /etc/apt/sources.list (note that I had to use the feisty repos as the freenx stuff seems to have been removed from the Gutsy repo)
2. Get the key, update and install freenx
3. Use these commands as shown in the guide

sudo nxserver --adduser
sudo nxserver --passwd
sudo nxserver --restart

4. NXserver appears to start but there's no indication of this if you run ps -e
5. Change the listening port as instructed in "Configure ssh"
6. Install nxclient on the client (Ubuntu-mac). Here there was a complaint about libstdc++2.10-glibc2.2_2.95.4-27. However, I found the deb for this here and I installed it. Thereafter the nxclient installed fine.
7.Now I tried to connect from the client to the server through NXserver by starting the client with

/usr/NX/bin/nxclient &

This opened up a small dialog box. Here I clicked the configure button where I entered the host IP (192.168.1.12 -- as the hostname didn't work for me) and the Key (8888) that I had already assigned in an earlier step. However, after adding the password, although a connection was made it broke almost immediately.
8. I googled around and found here that the answer is to add this line

AGENT_EXTRA_OPTIONS_X="-fp /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi"

to /etc/nxserver/node.conf on the server.
9. Now I could make the connection without problems.

One difference with VNC is that NXserver appears more like the RDP system to connect to Windows. This is because the while client can see clearly the server screen, the server user sees nothing of what the client user is doing.
Nevertheless, it does work well and is worth exploring further.

Tried VNC today.

I had planned to test this for some time but only got around to it today.
In summary, everything went very well and this is so easy to set up.
This is a useful summary which I used to set things up in Ubuntu and Foresight. However, it contains a lot more than you really need.
Essentially, you just enable Remote Desktop in System>Preferences>Remote Desktop. Now you must install a program to enable you to see the remote screen.
In Ubuntu, a choice of four (vnc-java, tightvnc-java, xtightvncviewer, xvnc4server) is given and I installed xvnc4Server.
I found out what I needed in Foresight by running
conary rq --path=/usr/bin/vncviewer
which gave me three programs. I installed the vnc program.
However, although it seems to be recommended to use the host name to connect to the remote computer, but this simply didn't work for me.
What did work was this

vncviewer 192.168.1.12:0

which includes the IP of the remote computer and the screen number.
Linux-to-Linux asks for a password of the remote computer and that computer than is given the choice of accepting or refusing to allow access.

Kurumin uses a GUI (Krdc) for these connections and provides a choice of either vnc (to a Linux box) or rdp (to a Windows machine).
Strangely, it worked fine when I connected to Margaret's computer (Windows XP) but doesn't work at all for connection to a Linux box. when I try in a terminal (I installed xvncviewer here too), a window labelled with the correct remote host-name opens but nothing appears in it. It's just black.
Strange.

rdesktop works also on both Ubuntu and Foresight and is already installed on both.
In contrast to the Linux-to-Linux connection, connecting Linux to Windows opens a login screen on the client, but no accept/refuse is presented on the Server. Indeed, the server goes back to the login screen and stays there when the client is working on Windows remotely.