I’m one of the many people who will be using VNC to do remote assistance for a relative using Windows.

There are a number of tutorials out there. Most of them fail because they require the ability to VNC in to the remote system, which won’t work in my case because the remote Windows box is behind a firewall/router that I can’t configure. There are also several reverse approaches out there, where the user needing assistance initiates the connection. The first of these I say was Gina Trapani’s approach at Geek to Live, which uses UltraVNC on both ends. This is almost the solution I want, except that it requires Windows on my end as well. It also assumes that I’m at a fixed location.

In the comments, I came across Fazal Majid’s response. He had the same requirements as I do, and links to his source where he built a customized VNC server that targets a fixed IP address. Fazal’s approach matches my needs exactly.
But then I ran into the problem of the last step: the reverse SSH tunnel from my known server (which gets hard-coded into the executable) to my notebook running Chicken of the VNC.
Building reverse SSH tunnels is really not that difficult. But when I created the setup, I was able to make it work from a Linux machine and from a Cygwin terminal under Windows, but it mysteriously failed under Mac OS. Using lots of -v flags, I kept seeing the service for the port on the Mac side refusing the connection from the tunnel. The ssh debug looked like:

debug1: remote forward success for: listen 5900, connect localhost:5500
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 131072 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 5900, originator ::1 port 60475
debug1: channel 0: new [::1]
debug1: confirm forwarded-tcpip
debug3: channel 0: waiting for connection
debug1: channel 0: not connected: Connection refused
debug2: channel 0: zombie
debug2: channel 0: garbage collecting
It turns out that this means the tunnel doesn’t even see the service. After wasting time with firewall tests and a lot of other false leads, I finally noticed the [::1] notation in there. Yup, that’s an IPv6 address. The solution is to make sure the ssh tunnel is using IPv4. For reference, the command that works is:

ssh -nNT4 -R 5500:localhost:5500 -l my_username myhost.com

Why do they have to be so damn difficult?

I’ve been working on upgrading my grandmother’s machine from a five or six year-old eMachine PII/300 running Windows 98 to a brand new Compaq deal I got at CompUSA along with a monitor and printer. The machine is reasonably fast, and, after I uninstalled all the crap that it came with and threw on some more reasonable software, I’m nearly at the point where it works the way she can use it.

Frustration 1. Moving files from one machine to another. I knew I wasn’t going to be able to use the network, as the old machine doesn’t have ethernet. New machine has no floppy. I could have uploaded all of the files via modem (probably get about 2 kB/sec), but that would have been painful. Easy, though, I’d use my USB memory key. Except that Win98 doesn’t natively support USB keys. Download the drivers… discover that they all want Win98SE, and won’t install. Grind teeth. Outcome: Success — finally had to use a USB CDR I had at home, since it at least had drivers on CD for Win98.

Frustration 2. Printer failure. The HP Deskjet 3915 just sits there flashing its light. Figure it’s a driver problem, so download 8MB of updates (over that mighty 2kB/sec connection). Still, nothing. Paper manual says that I should read documentation on CD. Documentation on CD says that I should consult the error code provided by the HP software. HP software says everything is fine. CD documentation’s best suggestion is to reboot. Windows thinks the driver is fine; HP thinks the printer is fine. The printer queue says it’s printing. Nothing ever happens. Reinstall drivers. Repeat. Outcome: still unsolved. Next step — call HP tech support. Oh, joy.

Frustration 3. Importing old mail from Netscape 4.8 to Thunderbird. Importing address book was simple — worked beautifully. But for old email, no such luck. There’s a tool “Wizard” for importing mail. But it doesn’t allow you to point it at files, it wants you to pick the profile. But it doesn’t see any profiles. I try putting the Netscape 4.8 user directories in all of the reasonable places (no, really. I tried all of them), but it never sees them. Documentation doesn’t yield any help. Try other directories. Try copying mail files directly into the appropriate directory in Thunderbird’s profile to no avail. Outcome: gave up.

This is probably obvious to everyone in the universe but me, but I was having a problem where my outbound email was being scanned by sa-exim, in addition to the desired scanning of incoming email.

The trick is in setting your SAEximRunCond in sa-exim.conf correctly. This is probably documented somewhere, but I totally missed it. In any case, assuming you want to skip scanning of email originating in your local network (e.g., IP address of 10.3.2.0/24) and that you changed the secret SA-Do-Not-Run header’s name to SA-Do-Not-Think-Of-Running, you would use the following line in your sa-exim.conf:

SAEximRunCond: ${if and {{def:sender_host_address} {!eq {${mask:$sender_host_add
ress/24}}{10.3.2.0/24}} {!eq {$h_X-SA-Do-Not-Think-Of-Running:}{Yes}} } {1}{0}}


Voila, outbound emails are no longer checked. Of course, if you are sending spam, please do not make the above change, but instead please swallow whole six to ten large, unpeeled pineapples.

So, courtesy of the DWP, the Meier Quagg was without power for about 7.5 hours today. It’s not clear what was wrong. The other side of the street had power, as did several parallel streets nearby, but this side of Meier was out, as were patches of Venice like the Oakwood.
Anyway, when the power came back up, most of the servers came back with it. Intervention was required for the Golem, Pylonhead, and Sekhmet. Sekhmet was the worst. I only got the “LI” of LILO, which says that the /boot/boot.b file was bad, or the drive geometry was hosed.

So I tried my trusty Debian rescue disk. Typed rescue root=/dev/hda1 at the boot: prompt. The boot failed with a complaint that /dev/hda1 was an MSDOS partition. uh-oh… MSDOS?

Of course, it turns out that I was using the wrong rescue disk. I was using a Woody ISO, and I had upgraded the machine to Sarge — and EXT3, which evidently was not compiled into the rescue disk. When I finally tried the correct rescue disk, it came up neatly, repaired the journals, and gave me my precious root prompt.

I did the LILO replacement trick (lilo -u /dev/hda; lilo), popped out the CD, rebooted, and held my breath. Then I decided to breathe. It’s my second fastest server, but it’s still a four-plus-year-old Dell Optiplex. In any case, it came up cleanly and there was much rejoicing.

Now it’s just a matter of waiting for the mail secondary to forward on all the queued up spam.

There have been other articles on this, but I wanted to post my own approach, just because it’s such an ugly — yet effective — hack.

I wanted PHP 4 and PHP 5 to both live happily on my Windows 2k machine, and work under Apache 1.3x. Install them in c:\php4 and c:\php5, and there you go. It’s easy to create an httpd.conf that takes a define, and figures out which PHP to load based upon that define.

But then both PHPs want to use the same php.ini file, specifically, c:\WINNT\php.ini. This is only a problem when you’re using PHP extensions, because one version will try to load the wrong ones. There are registry tricks, supposedly, and environment variable tricks to get different .ini files going, depending on version. None of ’em worked for me.

So I opened up vim, and edited my php4ts.dll, and replaced the “php.ini” string with “ph4.ini”. Now I happily have two PHP installs, each with its own .ini file, and everything is copacetic — except for all that software that breaks the newly enforced reference rules. But that’s another story.