Case in point: today Google announced official support for CalDAV with Apple iCal. If you’ve followed my blog for any significant length of time you’ll recall that I used Google Calendar back around the VMworld 2008 timeframe, with iCal and CalDAV, to help coordinate vendor meetings and such. So, today, I decided that starting in January, I’d move all my calendaring to Google Calendar and manage it via CalDAV from iCal. So I go out to the Google Help site and look up the instructions for connecting iCal to Google Calendar via CalDAV.

Alas, the old instructions are gone; all that remains are new instructions that say “Use our new tool!” Hey, this is a nifty tool and all, but I’d prefer to do it manually. Where’s the information on doing it manually? Gone, apparently.

After far too long using Google to search for information on how to manually configure iCal to use CalDAV to talk to Google Calendar—and primarily getting results back that were from Google and had no such information—I finally stumbled across this page that described how to use Google Apps and CalDAV support with iCal. Piecing together bits of information from there and the previous time I configured iCal, I was able to make it work.

For the benefit of everyone else out there who prefers to do things the hard way, here’s the information you need to manually configure iCal to use CalDAV with Google Calendar.

1. In iCal, select iCal > Preferences… and then click on Accounts.
2. Click the + sign to add a new account.
3. Specify a description. For username, add your Google Calendar login information, like “username@gmail.com”, and put in your password.
4. Expand the “Server Options” section to expose the Account URL setting.
5. For Account URL, specify “https://www.google.com/calendar/dav/[Google Calendar ID]/user”. Note that it’s actually “/user” there at the end, not your user name. The Google Calendar ID in brackets is visible in Google Calendar by going to the settings for a calendar and looking toward the bottom of the Calendar Details tab. You’ll see some funky junk like “asdfjklasdfjklasdjklasdjkl@group.calendar.google.com” or similar. That’s the Google Calendar ID.
6. Click Add.

That should be it. Note that these instructions work for any calendar you create in Google Calendar, but they don’t work for Google Apps users. Google Apps users should follow the link above for information.

By the way, it’s also worth mentioning that CalDAV accounts like this are synced to your iPhone, too. Handy.

• More on my VMworld 2008 Schedule
• CentOS 5 Active Directory Integration Problem
• Semi-Automatic Account Maintenance
• Report of Logons from Security Logs
• Using Samba in Linux-AD Integration

The OmniGraffle update brings one feature that I have especially been anticipating: the ability to import Windows Metafile images in Visio diagrams. This extremely useful feature, first hinted at here back in March, will tremendously ease Visio compatibility and should open up lots of Visio shapes to be used in OmniGraffle that previously were not usable. I tested this functionality this morning on a complex NetApp-VMware-IBM BladeCenter diagram from a co-worker, and it works as advertised. Future tests will see how well this functionality works in bringing Visio stencils into OmniGraffle. This is a free upgrade for current OmniGraffle 5.0 customers.

The OmniFocus update brings this GTD application’s official 1.5 release, and with it synchronization with OmniFocus for iPhone. Now that both the Mac and iPhone versions support Bonjour sync—although this is not without its own travails—I find myself using them more and more. If you’ve been following the pre-release versions of OmniFocus (the so-called “sneaky peeks”) then you won’t find many new features in this official release, but users who have been waiting for the official release to upgrade are in for a real treat. As with OmniGraffle, this OmniFocus upgrade is a free upgrade for existing OmniFocus 1.x customers.

• OmniFocus for iPhone First Impressions
• Any iPhone App Recommendations?
• NetApp OmniGraffle Stencils
• The Adventures of OmniFocus Bonjour Sync
• OmniGraffle Just Keeps Getting Better

We finally gave up on that and instead I went with an OpenBSD box to which I could establish an SSH session and then tunnel traffic from there. That worked reasonably well, especially after I discovered the GNU Screen utility. Talk about a handy little tool! Anyway, I continued using the SSH gateway for quite some time and I had resigned myself to living with the limitations.

Then a co-worker from the office casually mentions that he’s set up a Linux-based OpenVPN server on another subnet in the lab (we have a range of different subnets for different engineers in the lab). He, too, is a Mac user, but still running Mac OS X 10.4 on an older 13″ PowerBook G4 and using the Tunnelblick OpenVPN client. I thought to myself, “Hey, this might actually work!”

Alas, some additional research indicated that Tunnelblick had some stability problems under Leopard, which I’m running on my MacBook Pro. Bummer! I continued to research the issue but didn’t bother trying to use the OpenVPN server until just a couple of weeks ago when I uncovered Viscosity.

Viscosity is a shareware, Leopard-only OpenVPN client. It supports Growl notifications (which I very much like) and operates as a simple menu icon that easily allows you to connect or disconnect individual connections. Owing partially to how OpenVPN works, Viscosity uses (and includes) a TUN/TAP driver for OS X and creates a new TUN/TAP interface for every connection. This makes routing much easier and much more logical, in my opinion.

I’m so pleased with OpenVPN thus far, in fact, that I’m going to be setting up my own OpenVPN server here at the house.

My experience thus far has been quite positive. If you are looking for a good OpenVPN client for your Mac, Viscosity would be an excellent choice. At only $9 for a license, it’s well worth it.

• GrowlCamino
• YAMB (Yet Another Mac Browser)
• Mac Bookmark Managers
• Preferred Mac OS X Applications
• Very Handy Add-On

Bluebear’s Kodiak!
Bluebear’s Kodiak, what’s all the fuss about…
Kodiak 0.02 coming out real soon…

That’s not to mention coverage by virtualization.com, Reuters.com, and numerous other bloggers, experts, and analysts.

But where is Bluebear headed with Kodiak? What is their vision? Well, I don’t speak for Bluebear, but I did want to share some insight I’d gathered during a conversation with one of the Kodiak developers. I was curious to know how VMware’s announcements of cross-platform vCenter Server and cross-platform VI Client at VMworld 2008 would affect Kodiak. Perhaps because of VMware’s market leadership, most people see Kodiak as only a cross-platform VI replacement. The truth is, according to my information, Kodiak’s true value lies elsewhere. While it can be viewed as a VI Client replacement, and while it does bring cross-platform functionality to the table, there’s more to it than just that. Thus, cross-platform support by VMware—while sorely needed for quite some time—shouldn’t really impact Kodiak all that much.

So what is the value of Kodiak beyond cross-platform support? Good question! Here’s a couple of points I gathered from of our conversation:

• Multi-hypervisor management: One stated goal for Kodiak has always been to provide the ability to manage multiple, different hypervisors—not only ESX and ESXi, but also Xen, VirtualBox, etc. This is an area that only Microsoft is dabbling in with SCVMM, which will manage Hyper-V and ESX (via VirtualCenter only). Kodiak can manage ESX directly or via VirtualCenter.
• Management via visualization: I don’t know if this is what drove Bluebear to use Adobe AIR or if it’s a result of using Adobe AIR, but the idea behind managing virtualization with Kodiak is more through visualization than anything else. Bluebear wants users to be able to respond quickly to potential issues by making it possible to see those potential issues instead of waiting for a notification or an e-mail that something’s wrong.

I’m sure that Bluebear has all sorts of super-secret stuff in the works that will further differentiate their product from VMware’s cross-platform VI Client, even though the two products aren’t intended to directly compete.

And, of course, this doesn’t take into account Bluebear’s hardware side, aka Koala, which doesn’t get nearly the same amount of attention as Kodiak. Personally, I’m kinda hoping that the Koala will end up affordable enough for me to pick one up, as I could surely use it to host various virtual servers at home for media streaming, home automation, etc. But I digress…

Anyway, I think I have a pile of beta invites for Kodiak, so if anyone is interested post a comment here and I’ll see what I can do. Then you can take a look at the product yourself—keeping in mind that it is a very early beta—and see what you think about the future of Kodiak.

• Kodiak Continues to Develop
• Bluebear and Kodiak
• VirtualCenter Patch Released
• Other VMworld 2008 Resources
• Mac RDP Client Wishlist

In addition, version 1.5 of OmniFocus for Mac (OF/Mac)—currently at RC2 status—will synchronize with OmniFocus for iPhone (OF/iPhone) via MobileMe, WebDAV, or Bonjour on local Wi-Fi. This weekend, version 1.1 of OF/iPhone finally got approved and pushed out to the App Store servers. The new version adds Bonjour sync over local Wi-Fi, meaning that it’s now possible to quickly and easily synchronize the OmniFocus database on my laptop with the OmniFocus database on my iPhone. Sweet! (Version 1.1 of OF/iPhone also improves performance and has a few other improvements as well.)

Unfortunately, in the late hours last night, I just couldn’t get things to work. No matter how hard I tried, OF/iPhone just wouldn’t synchronize with OF/Mac. It would see my laptop advertising via Bonjour, but wouldn’t synchronize. My first suspicion proved to be a good one: the IPFW firewall on my laptop. (I use a custom IPFW ruleset in addition to Little Snitch to control traffic moving into and out of my laptop.) I was able to confirm that the firewall was blocking the traffic with this command:

sudo ipfw show

Sure enough, I saw the default deny rule’s counters incrementing every time I tried to synchronize. With this command I quickly disabled the IPFW rules:

sudo ipfw flush

OK, that got me a bit farther, but OF/iPhone was still reporting an error. The error was different this time, though, so I was convinced that I had made some progress. Unsure of what could be wrong next, I tested a hunch and logged into the Squid proxy server that controls outbound HTTP/HTTPS traffic and checked the access logs. Bingo—OF/iPhone was hitting the proxy every time I tried to synchronize. But how to fix that? My network is configured such that the Cisco PIX firewall won’t allow any traffic out that doesn’t first go through the Squid proxy, so turning the proxy settings off on my iPhone would be a temporary fix at best. Nevertheless, to test my settings I disabled the proxy settings on the iPhone (under Settings > Wi-Fi and scroll all the way to the bottom). That did it—OF/iPhone was now able to synchronize with my laptop. Rather quickly, too, might I add, which is a definite improvement over the WebDAV setup I’d been using previously.

But I was still left with two problems: a) the firewall on my laptop was disabled; and b) the proxy settings on my iPhone were disabled. So I set out to fix those two issues.

Fixing the firewall should be easy, right? Just find out what port OF/Mac listens on and create a firewall rule to allow the traffic. It would be easy, except for the fact that the port on which OF/Mac listens changes every time the application launches. OmniGroup, if you’re listening: change this to a static port, PLEASE! Or at least provide some sort of hidden preference that would allow geeks like me to make it use a static port. As it stands right now, I had to use a rule that opens up a broad range of ports. That really, really stinks. OK, firewall issue resolved.

The proxy issue proves to be more challenging. There’s no way to configure the proxy to ignore the traffic; that has to be done client side. Unless the full-blown version of Mac OS X, there’s no option in the iPhone to ignore certain network ranges or certain DNS domains. But—and here’s the kicker—the iPhone does support automatic proxy configuration via a PAC file. So I create a very simple PAC file like this:

function FindProxyForURL(url, host)
{
 if (isInNet(host, “172.16.1.0″, “255.255.255.0″))
  {
  return “DIRECT”;
  }
 else
  {
  return “PROXY server.domain.com:3128″;
  }
}

The first round of testing didn’t go so well; the Apache HTTPd configuration on my server didn’t allow files with a .PAC extension. Oops! After fixing that problem, testing from my laptop went very well. A few seconds later, I had my iPhone reconfigured with the PAC file. And it worked! I was able to successfully synchronize OF/iPhone with OF/Mac while still maintaing access to Internet-based resources. And since the PIX firewall won’t allow traffic direct from the iPhone to the Internet, I know that the proxy is still involved in those connections. Reviewing the Squid proxy’s access logs also confirmed that the iPhone was not hitting the proxy during synchronization attempts.

Problem all solved, right? Well…not exactly. I left the PAC configuration on my laptop until this morning, when I fired up Adium. Bam! Adium throws an error message stating that it doesn’t support PAC files. I reconfigured my laptop back to my old configuration and testing the OF/iPhone-to-OF/Mac synchronization again, and it still worked. It appears that as long as the iPhone’s proxy configuration is correct, then the synchronization will work.

So, lessons learned:

• OF/Mac uses a dynamically assigned port on which it listens for synchronization requests. This means that users with an IPFW firewall configuration will have to open up a wide range of ports until OmniGroup gives us the option to statically assign a port. (Hint, hint…)
• HTTP proxy settings on the iPhone will interfere with OF/iPhone synchronization, but that can be solved with a PAC file as described above.

Other than this adventure, I am thus far quite pleased with the update to OF/iPhone. If you are unhappy with the earlier version—the most common complaint was speed, or lack thereof—you owe it to yourself to check out version 1.1. It’s much improved, in my opinion.

• OmniFocus for iPhone First Impressions
• OmniGraffle and OmniFocus Updates
• ipfw Rules for Bonjour
• Any iPhone App Recommendations?
• How Do Non-Geeks Fix Problems?

VirtueDesktops ceased development due to the introduction of Spaces in Leopard, but the developer—Tony Arnold—later unveiled that he would create an application to enhance Leopard’s Spaces. That application, Hyperspaces, is now available as a public preview.

I had high hopes for Hyperspaces, having worked extensively with VirtueDesktops. I was disappointed. I suppose I shouldn’t have expected so much, given that this is a preview of the 1.0 release. I had been hoping for a bezel pop-up similar to Quicksilver and VirtueDesktops, but instead we have a menu item and an attached pager. There’s no moving windows between desktops without reverting to the standard Spaces interface, and none of the very cool special effects that graced VirtueDesktops—like the cube effect—are present.

I strongly imagine that Tony will greatly enhance and expand the functionality of Hyperspaces over time. Until then, I’ll stick to Exposé.

• VirtueDesktops to Cease Development
• Leopard Upgrade
• Virtual Desktops on Mac OS X
• Very Handy Add-On
• Filling the Gap With a Trigger

Now, the next version of Mac OS X, version 10.6 code-named “Snow Leopard,” is said to be more evolutionary than revolutionary. Personally, I’d love to see Apple fully embrace ZFS as its file system of choice, and then throw away the goofy “flying through space” UI in Time Machine to embrace something like this. Of course, Apple can seriously turn up the UI polish, but this kind of approach makes sense and seems relatively easy to incorporate into the Finder interface.

So what do you think? Am I way out in left field here, or does anyone else think this seems like a good idea?

• Leopard Upgrade
• NetApp Suing Sun over ZFS
• Is Apple Doing Enough for Mac Security?
• Application Agnosticism
• Virtual Mac OS X

A number of things stand out after using this combination for a few days:

• I’m too cheap to pay for a MobileMe subscription, so I just setup a WebDAV site on my hosting package. It’s not the greatest in the world (I’d prefer to run WebDAV over SSL on the standard HTTPS port, for example), but it works. However, less technically inclined folks would have had a problem without a MobileMe subscription. I hear that Omni is planning on adding Bonjour syncing support, but I can’t imagine that will be anything other than Wi-Fi only.
• It takes quite a while to sync my iPhone after a day of working in OmniFocus on my MacBook Pro. This is even with a good 3G data connection. I don’t know that there’s anything that can be done about this, nor is this even anyone’s “fault”; it’s just an observation I’ve seen thus far.
• In an effort to stretch the battery out as long as possible, I generally keep Location Services turned off. This limits some of the location-aware functionality that OmniFocus for iPhone features. Since the release of the 2.1 firmware, my battery life has improved; perhaps I can turn on Location Services and not suffer too much of a battery hit. If anyone has any feedback on how much of a hit it is to keep Location Services turned on, I’d certainly appreciate it.
• I’m finding that my current set of contexts don’t necessarily translate well to the iPhone version. Currently my contexts are more for grouping similar tasks than by location or resource; I’m thinking I may need to move to more location-based contexts. I’m not yet sure how that will work or how I’ll integrate that with my workflow. Again, suggestions are more than welcome.

Overall, I’m pretty pleased with OmniFocus for iPhone. (In fact, I’m pretty pleased with my iPhone in general.) There’s always room for improvement, but given my experience with The Omni Group with applications like OmniGraffle and OmniOutliner I’m quite confident that the application will improve over time.

• Any iPhone App Recommendations?
• The Adventures of OmniFocus Bonjour Sync
• OmniGraffle and OmniFocus Updates
• iPhone Irony
• OmniGraffle Just Keeps Getting Better

I won’t go through the whole long features list here; just go read it for yourself from VMware’s site.

As soon as I’ve been able to download the new version and install it (which, at the rate of The Venetian’s Internet connection, may not be until next week), I’ll post more information.

• VMware Fusion 2.0 Beta 1
• Fusion 2.0 Beta 2 Available
• VMware Fusion Update Released
• Don’t Believe Me?
• Fusion Ship Date Announced

Concerns Over VMware Fusion 2.0 Beta 2 and Parallels Desktop:

VMware touts the updates to their newest beta release of VMware Fusion to be: More Seamless, Safer, More Mac-friendly, with More Tech-Pro Tools. Now is it safer, or did it cross the lines of “The Rules of Virtualization”.

In the post, the author proceeds to elaborate on the “3 Rules of Virtualization,” similar to Asimov’s Three Laws of Robotics. I’ll let you read the full article to get the idea, but basically the author is stating that virtualization should not cross “boundaries” between the guest operating systems and the host systems on which the virtualization solution is running.

In the data center, I’d agree with that. Products like VMware Infrastructure, Hyper-V, and XenServer should strictly adhere to the basic properties of virtualization; namely, encapsulation, partitioning, and isolation. Interaction between host and guest are strictly against the rules.

On the consumer side, though, where this article squarely hits—let’s be honest, VMware Fusion and Parallels are hardly enterprise data center products—I couldn’t disagree more. In fact, the blurring of lines, the removal of boundaries between virtualized and non-virtualized should continue. This is something I first suggested and advocated almost 2 years ago when I introduced the idea of “application agnosticism”. It was then, when VMware Fusion was still in beta and Parallels was in early release, that I suggested that the blurring of boundaries was exactly what needed to occur on the client/consumer side.

Virtualization makes many things possible. The discussions that led up to the introduction of application agnosticism centered around the future of the OS, where some believed that the future of computing revolved around the idea of a collection of VMs—an Internet browsing VM, a security VM that provided anti-virus/firewall/IPS functionality, a third VM for productivity applications, etc. Lots of geeks have setups similar to this on a smaller scale. But ordinary users aren’t geeks. They don’t understand “virtual machines” and all that jazz. They just want a computer that works. So for virtualization to succeed on the desktop, it has to disappear. It has to fade away into the background, to become unnoticed and invisible. And that’s exactly what VMware Fusion seeks to do, and it’s what is being added to version 6.5 of VMware Workstation. That’s exactly what Microsoft is doing with the technology acquired from Kidaro. They are making virtualization disappear into the background, so the users can focus on what they really want: getting stuff done.

Does the blurring of boundaries create problems? Certainly. So does connecting your computer to the Internet, but I don’t see people crying doom and gloom over that! We just install our anti-virus, update our anti-malware, turn on our multiple firewalls, and off we go. Why should it be any different with consumer-grade virtualization? It shouldn’t.

On the consumer side, virtualization won’t succeed until it becomes transparent. Just like in the recent film I, Robot, where the Three Laws of Robotics had to be broken in order to move forward, in the evolution of consumer/client/desktop virtualization the Three Laws of Virtualization are going to need to be broken before we can move forward.

• VMware Fusion 2.0 Beta 1
• A Few More Quick Thoughts on Fusion
• VM Portability
• Macintosh Virtualization Heating Up
• Application Agnosticism