Tunneling VNC over SSH has several benefits. For one, if you are using a non-Mac version of VNC, your traffic is probably going over the network unencrypted. By default, the Mac VNC client encrypts keystrokes, including the login.

Another benefit of using VNC over SSH is that your client Mac may be behind a firewall, which you cannot reach directly. If there is some other host, like maybe the firewall itself, which you can SSH to, then you can use SSH port forwarding to “bounce” your VNC session off of that host and connect from there to your client Mac.

This procedure assumes that the remote Mac has SSH (“Remote Login” in Sharing Preferences) enabled, and you can login with it. Suppose that you want to connect to remote.host.com with VNC and your user account on that machine is remoteuser. Open Terminal, and issue the command:

Login at the prompt. Once you’ve logged in, your SSH tunnel is set up. Now simply connect to vnc://localhost:5901 (via Finder -> Go -> Connect to Server), and your VNC traffic will be automagically transported over a secure SSH tunnel to the remote host, and you should get a VNC login prompt.

If remote.host.com is behind a firewall that is preventing access via SSH, but you can access another host via SSH, and that host can access remote.host.com via SSH, then you can forward your traffic through the accessible host. Suppose that host is called dmz.host.com. Run:

Login to dmz.host.com, and now when you connect to vnc://localhost:5901, your network traffic will go through an SSH tunnel to dmz.host.com, and will be forwarded from there to remote.host.com. Isn’t SSH wonderful?

This site has been neglected for a little while — sorry about that. This summer was a whirlwind of adventure racing, consulting work, vacationing, and more work. This fall I started down the path of attaining the Apple Certified System Administrator certification, which has been time-consuming, on top of work and life. I wrote the first exam, then realized that I could get two-certs right away by writing the desktop support exam. So I did that, and now I have both the ACTC and ACSP certs.

Unfortunately, the Apple Consultants Network isn’t accepting any new members while system upgrades are taking place. The notice on their "Join" page says it will be closed until November — hopefully that doesn’t mean November ‘09! =)

I have 3 exams left to get the ACSA. I’ll be writing the Directory Services exam before the end of the month. I had hoped to have all of the exams done before the end of the year, but I don’t think I’ll have time for two in December. I’ll be writing at least one exam in January.

So, sorry again for the hanging threads on this blog. I know that some readers were looking forward to the completion of series of articles that I started, but re-creating the setups for those scenarios takes a lot of time that I just don’t have. The good news is that I’m learning the “proper” way to approach these things, so I might actually go back and revise some of the existing articles.

Then again, I have discovered that the documented way doesn’t always work, and I’ve actually referred back to my own articles here to solve issues that came up while following the textbook approach. I feel sorry for the instructors that teach the Apple courses — it must suck when the software chokes on the official procedure that they’re trying to teach! The best way, I suspect, is somewhere in between the official procedure, and the “hacks” that I’ve spelled out in my little tutorials. I’m toying with the idea of doing screencasts for some of this stuff. Stay tuned!

I just started getting back into Ruby on Rails, after a hiatus while I battled with Leopard server. I discovered that setting up my Rails development environment in Leopard wasn’t as perfectly straightforward as it was in Tiger.

I installed the binary distribution of MySQL, and proceeded to install the mysql ruby gem to connect to it. First, the build failed because it didn’t know where to look for the mysql client libraries, then it failed again because by default the Makefile tries building for both PPC and Intel architectures.

To make a long story short, the solution is to add an ARCHFLAGS environment variable specifiying your architecture, and to provide the path to mysql_config on the command line. For the former, add:


ARCHFLAGS="-arch i386"


To your /etc/bashrc (assuming you use the default shell, bash), and open a new terminal or run ‘bash’. If you’re on PPC architecture, change “i386″ to “ppc”. Then try the gem again with the path to mysql_config appended, like so:


sudo gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config


That is all on one line.

Kerberos and Single Sign-on in Leopard Server

It has been awhile since my last post of this series — sorry to keep you waiting. Kerberos on Mac OS X Server is a finicky thing, and it took me this long to get it working! Well, I did take a 3 week vacation, and was busy with other projects for at least 2 weeks … but it was a major pain in the ass to set up, and I’m not yet entirely satisfied.

To get straight to the point, the following procedure got kerberos with single sign-on up and running for me. Hopefully it will work for you too.

(more…)