Category: PC Tweakage

In the process of setting up a new PC for my mother, I finally figured out how to get remote desktop sharing in Kubuntu Hardy working. You’d think the bog-standard (and default) krfb would work, but it crashed every time. Come to find out, after much searching, the solution boils down to this…

Shoot krfb in the head, use vnc4server and x11vnc.

Use synaptic or apt-get to install those and all their dependencies on the remote machine (i.e., the one that will become my mother’s PC). While you’re at it, uninstall krfb: good riddance.

Run vncpasswd and feed in an appropriate password that you’ll use to authorize yourself to the vnc session.

Log out, restart X (with Ctrl-Alt-Backspace, perhaps), log back in again to get all the X11 infrastructure up to speed.

On your local machine (i.e., mine), use SSH to sign in to the remote box:

ssh -p unusual-port -L 5900:localhost:5900 remote.PC.ip.addr

The -L creates a tunnel from your local machine’s port 5900 to the remote machine’s port 5900, through the authorized SSH session.

I use an unusual port because running SSH on port 22 on an internet-facing machine (even behind a firewall router) is just plain dumb. I doubt the unusual port provides much protection, but it should shake off a few script kiddies.

[Update: Just in case you regard shared-key authorization and a nonstandard port as evidence of clinical paranoia, read that. One of the comments notes that using a nonstandard port gets rid of all the low-speed zombies…]

Incidentally, the firewall router must forward the unusual port directly to the PC’s local IP address, which requires a bit of tweakage all by itself; that depends on which router you have. Word to the wise: do not use DHCP to get the PC’s IP address. Think about it.

That PC is also set up with my RSA keys, so that the kiddies can’t brute-force a username / password login attack. And, yes, I regenerated the keys after the Debian goof.

This is still on my LAN, so I use a dotted quad IP address (being too lazy to tweak /etc/hosts for a temporary machine), but you can use the host name maintained by DynDNS or their ilk for a truly remote box. See this post for the straight dope on making that work.

Then fire up a remote-desktop client like, for example, krdc on your local PC, with the “remote desktop” address aimed at:

localhost:5900

That’s the local end of the SSH tunnel to the remote PC. It won’t work if you aim it at the remote machine’s IP address, because it’s not watching for incoming connections (nor is the router forwarding them).

Type in the password and shazam you should see whatever’s appearing on the remote desktop. Mouse & keyboard control should work just fine, too. Word to the wise: make sure your local monitor is bigger than the remote monitor; while you can scroll around or scale what you see, that’s icky.

It should be obvious that you cannot “switch users” to a different X console on the remote box and expect it to work. I tried it, just for grins, and it doesn’t. You could probably tunnel another session in through port 5901 (or 5900 + whatever the X11 console might be), but I haven’t tried that.

Last year I set my mother up with Verizon’s cheapest DSL service: 768 kb/s down and 16 kb/s up, all for a whopping 15 bucks plus tax a month. Yes, that’s 16 kb/s: slower than old-school dial-up modems. Sheesh & similar remarks. So all this fancy remote-desktop GUI stuff won’t work for diddly with the PC in her apartment.

SSH and the command line rule!

For some unknown reason, Kubuntu 8.04 doesn’t create a /dev/scanner link while it’s figuring out all the SCSI devices. I wanted to make the link sort of generic for any scanner that I might plug in, but I had to settle for a unique udev match.

The scanner popped out of udev as /dev/sg5 this time and

udevinfo --query=all --attribute-walk --name=/dev/sg5

emits this useful chunk:

looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:05:05.0/host4/target4:0:2/4:0:2:0':
    KERNELS=="4:0:2:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""
    ATTRS{device_blocked}=="0"
    ATTRS{type}=="3"
    ATTRS{scsi_level}=="3"
    ATTRS{vendor}=="HP      "
    ATTRS{model}=="C7670A          "
    ATTRS{rev}=="3945"
    ATTRS{state}=="running"
    ATTRS{timeout}=="0"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0x656"
    ATTRS{iodone_cnt}=="0x656"
    ATTRS{ioerr_cnt}=="0x2"
    ATTRS{modalias}=="scsi:t-0x03"
    ATTRS{evt_media_change}=="0"
    ATTRS{queue_depth}=="2"
    ATTRS{queue_type}=="none"

Plucking the readable bits out produces this stanza for/etc/udev/rules.d/60-symlinks.rules

#-- hack to create /dev/scanner
SUBSYSTEMS=="scsi", ATTRS{vendor}=="HP", ATTRS{model}=="C7670A", SYMLINK+="scanner"

Then you can use that to fire up xsane thusly:

sane hp:/dev/scanner

With that in hand, edit GIMP’s ~/.gimp-whatever/menurc and ~/.gimp-whatever/pluginrc to replace sg5 (or whatever) with scanner.

Works like a champ…

The straight dope on writing udev rules is at http://www.reactivated.net/writing_udev_rules.html

Memo to self: there’s got to be a way to make this generic, perhaps by piggybacking on whatever udev stanza assigns the scanner group to that /dev/sg? device.

Update: make sure you’re in the scanner group

sudo usermod -a -G scanner username

Of course I do remote admin for my mother’s PC, which means I must know its IP address, which means it’s running ddclient and updating an entry at dyndns.

The setup seems straightforward. In /etc/ddclient.conf you find:

# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

pid=/var/run/ddclient.pid
daemon=3600
protocol=dyndns2
ssl=yes
use=web web=checkip.dyndns.com
use=web web=checkip.dyndns.com/, web-skip="IP Address"
syslog=yes
server=members.dyndns.org
login=your-own-id-here
password='make-up-your-own'
hostname-at-dyndns

[Update: Something about checkip changed enough that the old line didn’t work. The web-skip made it work again. ]

But, as the comment in that file shows, that’s not where you configure ddclient in (K)Ubuntu. You actually tweak the entries in /etc/default/ddclient so the right answer pops out when ddclient gets reconfigured by something or another.

It’s not clear to me how ddclient figures out when to update the DNS entry (when an update is “necessary”), so I also force an update by putting this in /etc/rc.local:

ddclient -force

Actually, I added that tweak when I was setting up another, slightly newer, PC for her and managed to fire off ddclient from my network. That aimed the DNS entry at my IP address and, had I not already been signed into her system, would have locked me until her ddclient grabbed it back.

I hate it when that happens.

Memo to self: make sure the defaults match the current configuration.