Using vnc between two linux computers

Motivation

I want to connect to my work computer from home, to the primary X session and continue working remotely.

Problem description

My work computer is the vnc server. My home computer (the client) is to use a vnc viewer such as krdc (KDE Remote Desktop Connection) to allow me to control the remote machine. An added layer of complexity arises from the firewall that I need to tunnel through to reach my machine at work.

Solution

Server side, I’ll use x11vnc to accomplish this. This is because x11vnc allows me to connect to the primary X session – I need this since I might already have applications running at work and would like to continue where I left off. If this is not a concern, you can use tightvnc or other vnc servers, but you will need to start a separate X session to connect to.

As an aside, vnc is a better solution than using ssh with X11 forwarding. This has to do with the dreaded dropped connection problem. If the connection is dropped when you’re working on an application forwarded through ssh, it is terminated. It may or may not cleanly exit, leading to potential issues with data loss/corruption. This really depends on the application in question. However, if you use vnc, if the connection is dropped, you just get disconnected. The application is still running remotely. All you need to do is reconnect. Besides, if the application is already running on the remote machine, ssh forwarding doesn’t really help.

Prerequisites

An ssh server running on the server is highly recommended so you can tunnel all communication to and from the vnc server securely. This, however is optional, strictly speaking.

Procedure

1) Install the x11vnc package on the server. The following command will install x11vnc on arch systems.

# pacman -S x11vnc

2) Set up a vnc password for authentication. This step is optional, but recommended as without a password, anyone can connect to the vnc server. The following command will store a vnc password in ~/.vnc/passwd.

# x11vnc -storepasswd

3) Open the first of two tunnels. The first tunnel is for ssh. The following command will open a tunnel from local port 2222 (or any other port of your choice) to remote port 22.

$ ssh -fNL 2222:<remote server>:22 <user>@<gateway>

4) Now, in a terminal, ssh into the remote server and start the x11vnc server. The -create flag will scan for X sessions you’re logged into and connect to it. If you aren’t logged in or if someone else is logged in at the remote machine, it’ll create a new session for you. This new session cannot be viewed by someone at the remote server console. The -usepw flag tells the server to use an authentication password. The first place this looks for the password is in ~/.vnc/passwd. The -noxdamage flag is a performance option that worked well for me. Note the port number x11vnc is listening on. Usually, this will be 5900.

$ ssh -p 2222 localhost

<remote>$ x11vnc -create -usepw -noxdamage

5) Now, open the second tunnel for your vnc client to connect to the x11vnc server at the port it’s listening on. In this case, I’ve assumed it’s 5900. The following command will open a tunnel from local port 5959 (or any other port of your choice) to remote port 5900.

$ ssh -fNL 5959:<remote server>:5900 <user>@<gateway>

6) Now, you’re ready to point your vnc viewer to localhost:5959 and commence your vnc session. Terminate the x11vnc server on the remote machine when done. If you log out, the server will automatically terminate.

Problems

If you connect to an already running X session, it remains visible remotely. Other than leaving your screen turned off, I haven’t come up with a better solution. However, if the remote machine is either at the login screen or if someone else is logged in, the new session is invisible to the remote user.

Performance is wickedly slow when compared to protocols like rdp (remote desktop from Windows). This seems to be the best vnc is capable of. I’ve heard good things about FreeNX and will play with it when I get the time. If you have any suggestions about improving the performance of vnc, do let me know in the comments!

EDIT: Clarifications, reordering of steps to be more logical.

Sharing a keyboard, mouse and clipboard between two computers

Motivation

I have two computers at home side by side and would like to share a keyboard and a mouse between them. As an added bonus, my solution will also allow me to share the clipboard between the two computers – I can copy some text from some program on one computer and paste it into another program on another computer!

Problem description

The server computer has a physical keyboard and mouse. It is located to the right of the client computer. The server’s keyboard and mouse needs to be used on the client.

Solution

The package I’ll use is called synergy. Since synergy sends unencrypted information back and forth, I’ll need to route it through an ssh tunnel so that no one can snoop on my key strokes and clipboard contents.

Prerequisites

An ssh server running on the host is needed to secure communication between the server and the client. While this is optional, it’s strongly recommended.

Procedure

1) Install synergy on both computers. Arch linux has synergy in its ‘extra’ repository.

# pacman -S synergy

2) Edit the /etc/synergy.conf file on both machines. This file specifies the physical layout of the screens to synergy. This way, The mouse will smoothly transition from one computer to another when it encounters the correct screen edge.

The contents of synergy.conf should look like this on both machines: (Replace ’server’ and ‘client’ by the correct IP addresses/hostnames)

section: screens
    server:
    client:
end
section: links
    server:
        left = client
    client:
        right = server
end
section: aliases
end

These files can also be saved in one’s home directory as ~/.synergy.conf

2) On the server, start the synergy server.

$ synergys

3) On the client, open an ssh tunnel to the server. Note that this is an optional, but strongly recommended step.

$ ssh -fNL 24800:server:24800 user@server

4) On the client again, start the synergy client. (If there’s no ssh tunnel, replace localhost by the server in the following command)

$ synergyc localhost

5) Now, I have a working setup with two computers sharing the same mouse and keyboard! The keyboard strokes are sent to the computer whose screen the mouse cursor is on.

Problems

If you designated KWin effects to corners of your screen, they will not work on the shared edge/corners. You may need to remap them to other screen edges and corners.

I’ve also seen that the mouse will sometimes appear on the client screen in the middle rather than the right edge when moving from the server. It’s a minor problem and doesn’t affect the experience much.

My Adventures With Arch Linux – Part II – Installation

This is Part II of a series on Arch Linux

First and foremost, if you have any data that you’ll regret losing, back it up. No, seriously!

This is not a step by step installation guide. It’s a bunch of notes regarding things to expect during the installation. Refer to the Beginner’s Guide for a more complete walkthrough of the installation process.

Backup!

This bears repeating. Back up all data on an external hard disk before you consider installing Arch. I’d suggest spending one week just making sure that everything you could possibly need is safely backed up. It’s better to be safe than sorry.

Download

Download the latest ISO from here. Consider using the torrent. It really doesn’t take much longer than a regular download. There is a choice between a ‘core’ ISO and an ‘ftp’ ISO. Choosing the core option gives you a bigger ISO with many of the core system packages already on the CD. This means no waiting time for downloading during the install. However, the packages are likely to be out-of-date. The ftp option gives you a smaller ISO and downloads the latest version of the core packages from an online repository. This is usually the better option. You also have a choice between a 32 bit and a 64 bit ISO. If you don’t know which one you want, go with the 32 bit option.

Read up

The Beginner’s Guide is a wealth of information that concerns the set up. Regardless of your experience with linux hitherto, consider reading it at least a couple of times before you install. It’s also available as a text file on the installer CD.

If you can, also read up on what module/firmware packages you’ll need to install for your wireless card, if you have one. It’ll help to know this when confirming the set of packages to install during the set up.

Network

You’ll need to be online to download packages from the arch repositories. If it’s a wired connection, there’s little you need to do to get the machine online. In fact, getting online is actually one of the first steps in the installer. If you have a wireless connection, consider downgrading the security on the network to WEP temporarily during the install. This vastly simplifies the process.

Regardless, here’s a quick setup to setting up a network:

$ ifconfig -a


If the prompt is shown as $, the command does not need root access. A # prompt indicates that you need to be root to run this command. During the setup, you ARE root; but this notation will come in handy for use later.

This will list all devices onboard the computer that can connect to a network. Note the <interface> for your wired/wireless card. Should you need to tell a wireless interface from a wired one, use the following command

# iwlist scan

This will list out a quick scan of all the wireless networks in the area. It will also list out the interfaces that support scanning (i.e., the wireless interfaces).

Now, bring up the interface with,

# ifconfig <interface> up

The next step only applies to wireless interfaces. Skip this if your connection is wired. This step will associate the interface with a wireless network using WEP. As I suggested before, consider downgrading the security on your network to WEP (if you’re using WPA/WPA2) at least temporarily.

$ iwconfig <interface> essid <essid> key <key>

The <essid> can be within quotes if you have spaces in your network name.

Now, the final step is common to both wired and wireless devices. This uses the dhcp cliend daemon to obtain an IP address for your computer.

# dhcpcd <interface>

Finally, you can test your connection by pinging a network address

$ ping google.com

You should see ping times being shown. Ctrl+C to stop the pinging.

Other commands that will come in handy are:

# dhcpcd -x <interface>

to stop the DHCP client daemon, and

# ifconfig <interface> down

to bring the interface down.

If you need to troubleshoot, use the beginner’s guide suggestions.

Partitions

This is a very important step during your install. If you have multiple hard disks, make sure you know which hard disk you’re about to wipe clean. Use the cfdisk utility to create the partitions. Don’t sweat about formatting them. The installer will take care of formatting them during the setup.  The following commands will come in handy while working with hard disks and partitions.

$ cat /etc/partitions

will list all the partitions you have.

$ ls -lF /dev/disk/by-uuid

will list the UUID’s of the partitions

# mkfs.ext4 /dev/sda1

will format the sda1 partition using the ext4 file system.

Consider creating at least the following partitions:

1. boot (about 128 MB is more than enough. ext2 is fine for this partition)
2. root (a 10 GB, ext4 partition is a good start)
3. swap (used for hibernating the machine. 10% more than the size of your RAM is good enough)
4. home (leave the rest of the hard disk to this partition. ext4 is a good choice)

Packages

As long as you install the base packages, you can always install any other packages you may need later. Don’t sweat it too much during the setup trying to decide which packages you need. If you have a wireless card, you may need to make sure you get the appropriate package for the module at this point. My Intel Pro Wireless 2915 card on my laptop needed the ipw2200 package, for example.

System Files

You’ll have a chance to go over key configuration files at the end of the install. You’ll likely find that you have very little you want to change at all at this point. You can always load ‘em up later and edit them to your heart’s content.

Reboot!

If all went well, you should be able to boot into your freshly installed Arch linux system. Your journey is far from over. In fact, it’s just beginning!

# reboot

KTorrent and the IP Filter Plugin

KDE’s powerhouse torrent application, KTorrent comes with a formidable set of plugins including an IP filter. Here’s how to get it working.

Launch KTorrent. Head to Settings > Configure KTorrent. Look for the Plugins options in the side bar. Under Plugins, select the IPFilterPlugin. A new set of options should appear in the side bar called IP Filter.

You should find the option to Use PeerGuardian filter already selected and a url filled in the IP filter file area. Under that, the status will inform you that it’s not loaded. There’s a Download/Convert button, but that won’t work either, giving you a cryptic error message about no IP’s found in level1.txt.

Here’s what the problem is: the splist.zip file hosted at bluetack.co.uk is no longer hotlinkable. Which means, the url doesn’t work. You need to manually get this file from here and use the file browser to load it. Now, the Download/Convert button should work properly and the status message will inform you that the plugin is Loaded and running. Congratulations, you are in P2P heaven.

You can uncheck the automatic update option since you may delete the splist.zip file from your hard disk. Otherwise, KTorrent will periodically check the location to see if there is an updated list available.

A proper workaround is to find an up to date list of blacklisted IP’s that KTorrent users can happily hotlink to and have it updated automatically. But for now, you’ll need to manually update the splist.zip file from the link above and load it into KTorrent. Does anyone know of a viable option to manually updating the file every few days?

My Adventures With Arch Linux – Part I – Motivation

This is Part I of a series on Arch Linux.

Before I begin, a disclaimer. Arch Linux is DEFINITELY not for people new to linux. For them, I’d whole-heartedly suggest using a user-friendly distro like Ubuntu just to get a feel for how things work in linux. Arch Linux is also not for people who don’t have the time or inclination to learn how their computer works. Frequently, you will need to dig into configuration files and sometimes, use trial and error to determine which settings work for you during the set up process.

On the plus side, if you are comfortable with editing config files by hand, if you seek a high degree of control over what your machine does or if you are just too curious to be discouraged at this point, walk right in. You don’t need to be a linux god to enjoy Arch Linux – I’ve never compiled a single package from source and I loved setting up Arch Linux on my laptop.

After reading this blog on FSDaily, I was eager to try out Arch linux. The two biggest things that appealed to me were the idea of a rolling release (I was getting tired of the release update breaking my Kubuntu every six months, effectively forcing me to reinstall everything) and the promise of a “pure” linux experience. On a minor note, I was also impressed by the assertion that Arch linux remained very up to date and was usually one of the first to release an updated version of a package.

A test install on virtualbox at work showed no glaring difficulties in using it as my main system. The live CD also had no issues. So, I decided to go ahead and wipe out Kubuntu Hardy and replace it with Arch Linux at work. I chose the KDE3 environment as KDE4 (at that time, 4.0.5) still had issues.

I was pleasantly surprised by how light and responsive the system was. There were no unnecessary daemons running and the memory usage at bootup was 109 MB. That was impressive by itself.

A week or more later, KDE 4.1.0 was released and Arch, with its customary speed, rolled it out and replaced my KDE3 install. This was probably not a very nice thing for Arch to do, but I had sufficient warning – the package manager told me exactly what it was going to do if I said yes.

KDE 4.1.0, if you haven’t heard already, is quite stable and mature, so I didn’t really mind losing my KDE3 install at the end of the day. If anything, it convinced me that the time was ripe to roll out the install on my home laptop.

My expectations were not so modest for the ‘home’ install. Everyone faults Kubuntu for providing one of the worst KDE experiences in the linux world. So, firstly, I wanted to see what a “pure” install of KDE was really like. Second, I expected the install to run very light on resources and thus, to be quick and responsive. (To be fair, the Kubuntu install really wasn’t all that heavy.) Third, I expected to see fewer bugs because of Kubuntu specific alteration of the KDE packages. Lastly, I wanted to have more control and knowledge of my system. I wanted to know where to fix things if something broke. Essentially, looking to advance my geek cred, I suppose.

The main reason for this series of posts is to archive my experience so that it may come in handy to someone else later on. The second reason is to be able to refer to it myself if I need to perform another install in the future.

Next up, Part II – The Installation