I just re-read my earlier post on using TightVNC to easily setup an SSH tunnel for sending VNC data over. I can’t believe I forgot to point out some additional points:

• You don’t need to make a separate VPN connection to your work network if your company has an externally facing host that is open to SSH connections and also has an internal IP address / NIC. In this case, you simply establish the SSH connection to this external host and rely on it to forward the VNC traffic over the work LAN to your target host. While this setup encrypts the VNC traffic over the public internet / WAN, it does leave it unencrypted within the work LAN. As a result, only do this if you trust your work LAN not to be snooping your VNC data. Here’s an example:

  vncviewer -via host.work.com  internalhost:10

  Here my externally accessible work machine has a hostname of “host.work.com” and the name of the internal machine running the VNC session, on display 10, is “internalhost”. Again, this works as long as “host.work.com” has an externally open port for SSH.

• You can also provide a different username for the SSH connection and TightVNC will use it just like a standard ssh command. For example, I could have done:

  vncviewer -via dave@host.work.com internalhost:10

  in the above if I’d been logged into my local machine under a user account which doesn’t exist on host.work.com. In this case, TightVNC will first prompt you for a password for the SSH connection and then, assuming it can establish the SSH tunnel with those credentials, prompt you for the VNC password. In fact, since specifying the “-via” option just causes TightVNC to setup a tunneling connection for you by running the /usr/bin/ssh command, you can even get it to use a non-standard SSH port with a little bit of a hack. Simply provide any options, such as a port specification, within a quoted string as the argument to the “-via” option like so:

  vncviewer -via "-p 2222 dave@host.work.com" internalhost:10

  Again, this will prompt you for the SSH password, and only if that’s succesfull will it prompt you for the VNC password required by display 10 on internalhost.

Over the weekend I moved e-mail service from one machine to another, and in the process, decided to limit client connections to the IMAPS protocol for security’s sake. Unfortunately, I found that this broke the default Squirrelmail configuration on CentOS 5.1. In this post I talk about what I discovered and point out the easy fix that got Squirrelmail working again.

Let’s start out by assuming you’re using the standard IMAP/POP3 server on your install of 5.1, that is, the software known as DoveCot. And let’s also assume, that for security reasons, you’ve customized its configuration such that it only accepts IMAPS connections. That is, IMAP over SSL, which means that all connections to read mail are encrypted between the client and the server thus limiting any eavesdropping as the traffic travels over your LAN, or even better, over the WAN/Internet. In this configuration, DoveCot is listening on TCP port 993 for connections and not port 143. (Most modern mail clients have no problems using IMAPS on port 993.)

In this situation, the default installation of Squirrelmail (version 1.4.8-4.0.1.el5.centos.2 as of this writing) doesn’t work and you’ll get a login error if you try to login. If you run the configuration test script, via a browser request to

http://localhost/<squirrelmail prefix>/src/configtest.php

you’ll see that it runs fine until it tries to connect to the IMAP server but then it will report a connection error on trying to access IMAP at port 143. I leave the <squirrelmail prefix> placeholder in because you might have already customized this in your /etc/httpd/conf.d/squirrelmail.conf script. It defaults to “squirrelmail”.

Your first attempt to fix this will be to run the standard, and documented, config.pl script provided by the authors of Squirrelmail. While this won’t be sufficient, you’ll want to do this anyway because it is the easiest way to correct the configuration file for Squirrelmail, which you’ll need to do at some point to get it talking IMAPS. Here are the steps:

cd /usr/share/squirrelmail/config
sudo config.pl

Once that starts, do the following:

1. If you don’t see any values shown for any of the options, its because the config program defaults to using light yellow for the config values and this doesn’t show up well on your white terminal background. Simply select the “C” option to toggle off the color settings and switch to black text.
2. Select option “2″ (Server Settings)
3. Select option “A” (Update IMAP Settings)
4. Select option “4″ (IMAP Server) and set it to the hostname of your IMAP server. If you’re running Squirrelmail on the same host as DoveCot, this should be “localhost”.
5. Select option “5″ (IMAP Port) and set this to “993″.
6. Select option “7″ (Secure IMAP (TLS)) and set this to “true”.  (It should be noted that Squirrelmail does not send a ‘STARTTLS’ command automatically, so you’ll need to have done step 5 to specify the dedicated SSL port.)
7. Select “S” (Save) to save your configuration.
8. Select “Q” (Quit) to exit the configuration tool.

Your Squirrelmail config file is now updated. But, if you try to login now, or run the configtest.php script again, you’ll find this didn’t fix the problem. Why not?

It turns out that the CentOS build of Squirrelmail has been customized so that the configuration file(s) being written to by the config.pl tool are in /etc/squirrelmail — which seems all well and good since it matches what you generally expect on a RedHat based system — the config files are in /etc. But the problem is that the PHP source that implements Squirrelmail has NOT been customized to read from that location!

The httpd conf file aliases running the PHP scripts out of /usr/share/squirrelmail and the starting index.php script assumes that it can read the configuration file via a relative file reference of “config/config.php”. Aha! Its reading the configuration file from /usr/share/squirrelmail/config/config.php which is not the one we just customized. You could copy the customized one over, but that would mean the next time you ran the config tool, you’d have to remember to re-copy this yet again and how likely is that? Let’s not try to fool ourselves. We need a different way.

The best answer I’ve come up with is to simply make a symbolic link to the /etc/squirrelmail dir, under the name config, from /usr/share/squirrelmail. But only AFTER renaming the existing config dir to something else. The rename is critical because the only location of the config.pl tool is in this directory. If you delete the directory, or overwrite it, you won’t be able to get to this script again.  That is bad.  The symbolic link fixes all the problems and enables future customizations of the Squirrelmail config to be picked up without any extra steps. Here’s the relevant commands to do this:

cd /usr/share/squirrelmail
mv config config.original
ln -s /etc/squirrelmail config

NOW you’ll find your Squirrelmail install working and connecting via IMAPS to your DoveCot server!

For awhile now, I’ve known that the protocol used by RealVNC isn’t very secure in that it sends passwords and content in cleartext over the network. This isn’t so bad when you’re accessing machines on your local LAN, but I’ve recently been in numerous situations where I needed to VNC to a machine over a WAN, meaning the Internet in my case. And each time I wanted to do this, I had to lookup what command line options I have to pass to SSH to allow it to forward the VNC protocol and ports. I don’t do this enough to remember it, just often enough for it to be a royal PITA that I don’t remember it.

This morning I got frustrated enough to do more research. It turns out that TightVNC makes this easy because it establishes its own SSH connection for you just by providing a simple option when you invoke the vncviewer command. Sooooo much easier!! Here’s an example of how I would connect to a VNC session running on a machine at work once I’ve connected to the work VPN:

vncviewer -via 192.168.1.190 :1

Basically, all you need to do is remember to put the “-via” option in and specify the host to SSH into. In my example above, I’m connecting to a VNC session on the same host I’m SSHing into. If instead I wanted to get to a VNC session on a different machine that’s on the same LAN as my remote SSH host, I’d do:

vncviewer -via 192.168.1.190 anotherHostOnSameLAN:10

It should be noted that you can’t easily have RealVNC installed at the same time as TightVNC since they both work via the same command ‘vncviewer’. So, on my Mac OSX box, I had to do the following to switch:

sudo port deactivate vnc
sudo port install tightvnc

Like I said, so much easier to use and for such little trouble! And supposedly TightVNC uses less bandwidth than RealVNC so it is a winner there too.

As of yesterday, Time Warner Austin has added an additional four new HD channels to the local cable lineup. As expected, these are all SDV (Switched Digital Video) which means that my Tivo can’t get them. Here’s the new lineup:

• TLC HD (channel 1615) — The Learning Channel in HD. Seems to be simulcast (showing the same shows at the same time) of the SD version of The Learning Channel.
• Discovery HD (channel 1618) — This is different than HD Discovery Theater, which still exists as channel 1617. This new one appears to be simulcast of the SD version of the Discovery channel.
• Animal Planet HD (channel 1622) — Just like regular Animal Planet but now in HD, by which it’s also a simulcast.
• Science HD (channel 1624) – And again, just an HD simulcast of the SD version of the channel.

Of course, these just make me want the TR (”tuning receiver”) device that will allow a Tivo to tune in SDV channels that much more. Get off your butt cable co’s and get this thing released!

BTW: Here’s a link to the official list of HD channels in Austin.