Chrome blame: you don't think they mean Flash, do they?

Page 8 of the Google Chrome comic is about "placing blame where blame belongs".

There's a bit of intensity in this topic. I'm left with the sense that Google engineers are upset with a common plug-in, an its tendency to wreck browsers.

You don't suppose they mean Flash?

I'm looking forward to Chrome. In a world of Chrome/Safari/iPhone/Web Kit, IE 6/7/8, and Firefox 3 even the most clueless web app vendors have got to start thinking about standards.

As a Web Kit user I'm also grateful for the automated QA the open source Web Kit platform is getting.

Thanks Google!

Update: After the comic slipped out ahead of time, Google put out an emergency blog post pre-announcement. It will be out in beta tomorrow for Windows, Mac and Linux to follow but no timelines given.

Migrating a domain with related Google Apps and hosting files to a new service

A year ago I wrote about adding adding Google Apps services to our existing mnspecialhockey.org domain. Back then Lunarpages managed most of my domains and sites, but I fired them recently.

Now I'm migrating my domains and hosted files to DreamHost, including mnspecialhockey.org. I was worried about that one. How do you migrate Google Apps?

Briefly, if you know the sequence to follow, the answer is -- very easily.

I've not only migrated mnspecialhockey.org, I've also added a new subdomain, files.mnspecialhockey.org to hold files (something Google doesn't really do) and I've restored the news.mnspecialhockey.org subdomain for our blogger blog (Lunarpages broke that).

The hardest part for me was understanding how things work. Once I knew that, I knew what to avoid and what to do. Understanding took a couple of days and help from DreamHost tech support; execution took minutes. (See migrating my domains and hosted files for the steps involved in switching the domain itself.)

To understand how the magic happens you have to know what 3 entities do:

1. The registrar (Tucows, will be DreamHost): maintains the relationship between the domain names we type (mnspecialhockey.org) and the IP address of the name server you are using.
   
2. The nameserver owner (DreamHost): routes all kinds of requests for web pages and services
   
3. The web site provider (also DreamHost): provides file services, http and ftp, etc
   
4. Google Apps for a domain: provides google apps (available only to person who can provide domain ownership)

Next you have to know two key things:

1. You can do whatever you want to the DreamHost DNS settings, but until you tell your registrar to use the ns1.dreamhost.com nameserver nothing will happen. So you can get everything ready at DreamHost, the turn it on by switching nameservers at your registrar. You can switch back to Lunarpages just as easily. It doesn't matter whether DreamHost or Tucows or Network Solutions or eNom or GoDaddy is the registrar.
2. For a request for "calendar.mnspecialhockey.org" to work you need to do two things:
   a. set up a rule in your nameserver provider's DNS to route all traffic for calendar.mnspecialhockey.org to ghs.google.com. This is done by a CNAME (below)
   b. in your Google Apps you need to setup a custom name that exactly matches the name you created in the CNAME.
   

Ok, so that's complicated. Let's walk through an actual transaction.

When I enter "calendar.mnspecialhockey.org" in my browser, the Internet's DNS system first "asks" where to route the request. The registrar for mnspecialhockey.org knows to send all domain traffic DreamHost nameservers - because I told it to use those nameservers.

So the requests go to the DreamHost nameserver. As we see in this picture of DreamHost's nameserver the subdomain request is then routed through a CNAME to Google (ghs.google.com).

So the request for calendar.mnspecialhockey.org effectively goes to Google. On the other hand fubar.mnspecialhockey.org, for example, would have to be handled by DreamHost.

When Google gets this transaction it sees it's a request for "calendar.mnspecialhockey.org". It matches this request against the custom URL I assigned my Google Apps calendar through my Google Apps Dashboard, and it renders the correct calendar.

Ok, if you understand all of the above then you're ready to understand how I migrated mnspecialhockey.org, and its related Google Apps services, from Lunarpages to DreamHost. You may also see why Google Apps are so loosely related -- they are really only bound together at the DNS level.

In this case everything was already setup on the Google Apps side, including using Google's now obsolete Page Creator to manage our web pages.

I just had to setup the DNS at DH so it had the right CNAME settings to direct traffic and handle mail. These are totally generic, the traffic gets routed to the right Google Apps because of the matching domain names, not because of anything special in this table.

1. I used DreamHost's "fully host domain at Google Apps" first. That created almost all the CNAME and MX (mail exchange, see DNS record types) settings in the above image.
   
2. I manually added the CNAME entry of "news.mnspecialhockey.org". I'd made a corresponding change in a Blogger blog, publishing it to "news.mnspecialhockey.org".
3. I changed the nameserver settings at my registrar (Tucows at the moment) to the ns1.dreamhost.com, etc settings.

That was it. Everything worked as before, except that Lunarpages had broken things and couldn't fix them. So now it really worked.

I wanted one more thing though. I wanted a place to store files -- something Google Apps does very poorly.

That was easy too. At DreamHost I created a subdomain of files.mnspecialhockey.org.

I configured that subdomain so anyone entering "www.files.mnspecialhockey.org" would go to "files.mnspecialhockey.org" (a DH configuration setting).

So now I had my files section -- with FTP services too.
It took a while to understand this, and a bit of time to write it up, but not time at all to do it. DreamHost tech support was very helpful, though they did have to correct themselves a couple of times.

Bento Mobile? FileMaker feels the heat

From the official FileMaker forum, after dozens of fervent pleas for an iPhone version of Bento and/or FileMaker Mobile:

Re: iphone Bento Mobile? - Other suggestions - Bento Forums

... Thank you for your post.

Hearing you loud and clear! Please give us more credit. There have been a lot of users who have requested an iPhone solution, and I have also forwarded your post to our Development and Marketing departments for consideration...

So I'm not the only guy waiting impatiently for iPhone Bento and/or a resurrected iPhone version of FileMaker Mobile to appear. Definitely get the impression it's just a matter of time.

The DreamHost migration: moving the first domain

[Update: if you enter my promo code on signing up with DreamHost, you get $50 off your 1st year fee. The code is: KATEVA.]

I'm continuing the process of moving my Tucows/Lunarpages domains and files to DreamHost. In a prior post I described how to obtain a transfer authorization code.

Now I can describe the details of how I moved the first domain and files. Naturally I discovered a bug in DreamHost's process -- I hope they can fix things up. I'll describe the sequence I think one is supposed to follow, I actually did things a bit out of order (see below).

With my next domain transfer I'll get to validate this sequence. I'll call the domain I moved "myDomain.com".

Key Principles

1. You can setup "myDomain.com" with companion Google Apps at DreamHost before you make any DNS changes.
2. Changing DNS settings for "myDomain.com" at the old registrar will direct traffic to the files you've put on DreamHost. I use OpenDNSfor our home network; it picked up the DNS settings changes within minutes.
   
3. The registrar transfer is a separate, slower process.
   

There are 3 phases to the file and domain migration:

Phase I

a. setup domain hosting at DreamHost. The interative form creates a directory for file ftp and creates the Google App services, it provides a link to configure them. [2]
b. setup companion Google Apps and email (same as one would with any Google App setup)
c. collect all email redirections or email accounts from old domain, recreate them in new domain. (note email stores will be lost, I don't know of a way around that)
d. collect all subdomains and remap those

Phase II

From the domain control panel (http://manage.opensrs.net in this case [1])

a. set domain DNS settings to use DreamHost
b. Get domain transfer authorization code (Lunarpages quickly sent me a password - had an old lunarpages pw for manage.opensrs.net)
c. Change all contacts, admin, technical, etc to email address you control - preferably unrelated to your domains. (This is where I found the Dreamhost bug -- their web page says they'll send confirmation email to admin contact, they sent it to technical contact -- which was Lunarpages, not me!)

Phase III

a. Go to DreamHost and request domain transfer, entering the network authorization code from Phase II.

What I actually did

I did things somewhat backwards. I requested the domain tranfer first. That gave me a link that took me to the create a hosting setup, then I finally changed the DNS codes. It worked, the sequence phasing is not too strict. The problem was the DreamHost bug as noted above.

[1] I ran into another LunarPages glitch. They use Tucows for domain registration, hence opensrs.net. In theory the Tucows pw should be my LunarPages pw. It wasn't -- it was an old pw. I guess there's no propagation of changes! As usual LunarPages tech support was able to fix the problem, but this is typical of their challenges. They're very disorganized and prone to glitches.

[2] When I first started loading files from my primary LunarPages domain, I copied them into my temporary "dreamhosters" directory. I thought when I switched my domains the primary would point to this folder. Wrong -- that was how things worked at Lunarpages. At DreamHost every domain gets its own folder; that folder is created from the "Add domain" step described in Phase I. If you want to see how a domain looks before you bring it "live" by switching the DNS settings over to DreamHost, you "mirror" it into the dreamhosters directory and access it using a dreamhosters URL. It took me some effort to grok this. Of course now I had all my files in the wrong directory, but I used the DreamHost net2ftp web ftp tool to move them.

Tethering: buying a 3G phone just to tether?

Shortly after Pogue wrote about using the Nokia E71 tethering service, another blogger chimes in

A Glimpse of Our Tethering Future - Inside iPhone Blog

... I'm doing this using a prepaid AT&T GoPhone account that I picked up at the AT&T Mobility Store that's half a block from my office in Manhattan. Andy Abramson, a friend who writes the blog VoIPWatch and runs the Nokia Blogger Relations Program, told me that using a 3G phone in conjunction with a GoPhone account was not only possible, but cheap in comparison with what I would pay for AT&T wireless data services delivered on a 3G-compatible ExpressCard plugged into my MacBook Pro...

I have an unused Nokia 3G phone at home. I wonder if there's a tethering solution for it? The GoPhone angle is interesting.

I wonder if the tethering solution on the Nokia E71 is really approved by AT&T ...

In any case, I need a tethering solution. I gather I'm not alone! I suspect that sooner or later Apple will sell a solution with the iPhone and it will cost at least $30/month to use it with AT&T.

The DreamHost migration: getting a transfer authorization code

[Update: if you enter my promo code on signing up with DreamHost, you get $50 off your 1st year fee. The code is: KATEVA.]

To begin migrating my domains from LunarPages to DreamHost, I need to obtain a "transfer authorization code" from the current registrar (which is, in this case, TuCows opensrs.net -- not Lunarpages).

I'm starting out with the simplest parked domain, then gradually moving up the ladder until I migrate my primary domain -- which is actually managed by Network Solutions. For that one I may simply change the DNS settings and wait to see how DreamHost works out over time.

I found this reference to be very helpful: Obtaining An Authorization Code (Auth Code) from Various Registrars.

Unfortunately, but not surprisingly, my Lunarpages un/pw isn't working with opensrs.net. So I'll have to see if I can get Lunarpages support to fix that. Once that's fixed it appears I can obtain the "TAC" and then complete the form that will migrate it to the DreamHost registrar.

And so on down the line ...

DreamHost: a better Google Apps choice than Google?

[Update: if you enter my promo code on signing up with DreamHost, you get $50 off your 1st year fee (max discount). The code is: KATEVA.]

Lunarpages finally pushed me over the brink.

I suspect Lunarpages is discovering the limits of an outsourcing strategy. I've seen more than one company make that mistake.

The good news is that I'm discovering greener grass at DreamHost, such as WebDav support, full control over DNS CNAME and email MX configuration, SSH/Telnet support and robust Google Apps integration.

As I've noted in prior posts, Google Apps works tolerably well when you do register your domain and sign up for the services at the same time. Google hands off the registrar function to eNom or Go Daddy and everything works. The downsides are you don't have unified management of your domains and you're limited to what Google offers. Meaning no real file management.

On other hand, Google Apps can be pretty frustrating when you try to use a domain held by, say, Lunarpages. The MX and CNAME configuration is complex, and when something breaks there's no-one who owns the problem.

From what I see of DreamHost, it looks like the best of both worlds. Every domain, even the throwaway "dreamhoster" domain I'm using for initial setup, can have a companion Google Apps service. So you get consolidated domain ownership through DreamHost (they're a registrar as well as a hosting service), Google Apps functionality, and file services.

I'll update this post as I learn more during my upcoming domain migrations.

Update 8/30/08:

There are two ways to configure your companion Google Apps with Dreamhost

1. optimal: In this case domain_name.com and www.domain_name.com resolve to the files you host at DreamHost. Calendar, docs, mail, sites, and start map via CNAME to ghs.google.com. You can't change these CNAME values. You can add new ones, but these are fixed.
   
2. Google Apps only: domain_name.com and www.domain_name.com resolve as controlled by Google Apps; there's no real role for DreamHost file hosting. DreamHost assigns fixed, non-editable, CNAME values for calendar, docs, sites, start and www and configures email for Google Apps. Unlike Google's usual Google Apps registrars (eNom for example), you can't change these settings. So if you prefer "wiki" to sites there will still be a CNAME for sites.