If you’re anything like me, then your life is an endless stream of screwing stuff up, then jumping through uncountable scads of hoops trying to fix it before anyone notices.

The latest humiliation came when I overestimated the driving power of my trusty old 19” CTX monitor, while running OS X. Many may not realize that when your monitor doesn’t just come out and tell your computer what resolutions it supports, your computer will do its best to destroy your monitor, and with it whatever admin street cred you’ve spent the last 20 years building up.

Futzing around with my OSX86 installation, I decided that my resolution looked a little dodgy: The circles looked like eggs. Instead of checking whether 1280x1024 is 4:3 (it ain’t, it’s 5:4), I decided to go for a resolution with easier math involved. So, bringing up the display preferences, I clicked on 1600x1200, and was greeted by a strange, unearthly buzzing sound that was probably the death-rattle of my monitor’s flyback as it choked on the new resolution.

Now, OS X is generally pretty good about not letting you screw yourself, but sometimes you can fall through the cracks. There’s no ‘confirm this setting’ dialog for changing monitor resolutions, for example; you break it, you bought it. Apple software knows what Apple hardware can handle, and generally leaves it in a working state. But when you’ve got, erm, let’s just call it ‘third-party hardware’ running OS X, things aren’t always quite so foolproof.

So, with a buzzing monitor, and no way to undo my screw-up, I decided to go about setting the resolution remotely. It’s doable, but it requires a couple of conditions before it’ll work:

• Remote SSH logins enabled


• A working Internet connection


• Nerves of freakin’ steel and nothing to lose!

Ok, maybe not that last one. There’s precious little to do with crocodiles or bungy jumping.

Basically, what you want to do is a) Get a running VNC server for your out-of-range desktop; b) connect to it from the working machine using a VNC client; and d) change the resolution to something that works, douche.

Ok, here’s how to do it, step-by-step. First, open an SSH session from another computer to your patient. The easiest way is to open Terminal and hit Cmd-Shift-K, which will bring up the Rendez-jour ‘Connect to server’ dialog. Just browse to the ailing computer, and click connect. If you’re on a Windows computer or don’t feel like screwing around with Bonjourvous, then connect as you normally would.

Once you’re in, grab two copies of OSX-Vnc; one for the machine you’re sitting at, and one for the patient like so:

[patient:~ dumbguy$] curl http://belnet.dl.sourceforge.net/sourceforge/osxvnc/OSXvnc1.71.dmg > osxvnc.dmg

This will save the remote file into a DMG disk image. You can then mount the disk image by typing:

[patient:~ dumbguy$] open osxvnc.dmg

If all went well, the disk image is now available in the patient’s Finder. You can find the image’s mount-point in your SSH session by typing ‘mount’ and pressing enter. You’ll get a list that looks like this:

/dev/disk0s1 on /Volumes/Untitled (local, read-only)

automount -nsl [171] on /Network (automounted)

automount -fstab [176] on /automount/Servers (automounted)

automount -static [176] on /automount/static (automounted) /dev/disk1s5 on /Volumes/NO NAME (local)

/dev/disk2s2 on /Volumes/DUMBGUY’S IPOD (local, nodev, nosuid)

/dev/disk3s2 on /Volumes/OSXvnc (local, nodev, nosuid, read-only, journaled, mounted by dumbguy)

That last one looks good, so we’ll just go there for the VNC software by typing:

[patient:~ dumbguy$] cd /Volumes/OSXvnc

[patient:~ dumbguy$] ls -la

drwxr-xr-x 5 dumbguy dumbguy 170 Feb 1 2006 OSXvnc.app

As we see, inside this directory is an application bundle called ‘OSXvnc.app’, which is actually a directory, as such things are in OS X. Let’s change into that directory, where we’ll find a command-line VNC server, and crank ‘er up.

[patient:~ dumbguy$] cd OSXvnc.app



[patient:~ dumbguy$] ls -la

drwxr-xr-x 5 dumbguy dumbguy 170 Feb 1 2006 .

drwxr-xr-x 4 dumbguy dumbguy 238 Feb 1 2006 ..

drwxr-xr-x 6 dumbguy dumbguy 204 Feb 1 2006 Contents

lrwxr-xr-x 1 dumbguy dumbguy 28 Feb 1 2006 OSXvnc-server -> Contents/MacOS/OSXvnc-server

lrwxr-xr-x 1 dumbguy dumbguy 26 Feb 1 2006 storepasswd -> Contents/MacOS/storepasswd



[patient:~ dumbguy$] ./OSXvnc-server

--- lots snipped ---

2006-08-03 23:18:49.696 OSXvnc-server[312] IPv6: Started Listener Thread on port 5900

2006-08-03 23:18:49.697 OSXvnc-server[312] Started Listener Thread on port 5900

Don’t forget that ‘./’ at the beginning, or OS X won’t find the file. So, now we’ve got a working VNC server on our patient. All we need now is a working VNC client to connect to it, we’re all ready to go! I was a bit peeved to find out that OSXvnc is just the server software, and therefore a second download was needed. All bepeevedness was gone, however, when I discovered that the excellently written, if disappointingly named, VNC client for OS X, Chicken of the VNC, has a new version out.

At this point, all you need to do is open up CotVNC, point it at your patient using the port number spit out above, and badda-bing, you’ve got a ginormous VNC window showing all those pixels that your POS old monitor couldn’t handle. Just click on another resolution in the still-visible display preferences (and do try to keep it reasonable this time...), and you’re back in business.

Notes

This should also work on Linux, but you may have to use something like xhost to get the SSH session authenticated with your X server. OS X doesn’t sandbox the window server like X-Window System does.

You’re SOL if any of the following are true:

• The patient is running Windows


• You didn’t enable remote SSH logins on the patient


• You don’t have a working Internet connection


• The patient is in a private subnet, and you’re not in it with him

If you’ve got a firewall running on the patient that allows SSH but not VNC (port 5900 is standard), you can create an SSH tunnel for VNC packets like so:

ssh -L 13900:127.0.0.1:5900 patient.local

Where 13900 is a random open port on your working machine, 5900 is the VNC port on the patient, and patient.local is the address of the busted machine. You can then point your VNC client to 127.0.0.1, port 13900 and it’ll all be forwarded to the patient’s VNC server.

If you’re on an internal network, and not connected directly to the Internet (e.g., behind a DSL router), it’s always a good idea to enable SSH connections. SSH is a fairly secure protocol, and you never know when it’ll come in handy. The technique describe in this article could be useful for other situations as well:

• Your laptop display dies or, as is the case with a lot of Powerbook G4s, won’t come out of sleep mode. You’ve got documents open, and resetting the machine would cause data loss.


• You want to see what your other machine is doing, but you’re too lazy to get up and walk to the other room. But you’re not, it seems, too lazy to type the 30 or so commands needed to get a VNC server running.

To anyone who finds this article looking for command line utilities to quickly change a Mac’s resolution, leave a comment if you find something.