RSS feed for InstantSpot site Blog of Dave

Naked Domains in Google App Engine with GoDaddy

Thu, 17 Dec 2009 03:11:47 GMT

I recently set up a new site (hikethecanyon.org) on the Google App Engine running OpenBlueDragon. By default when you set up a new site on GAE (Google App Engine), you choose an ID for your application, which must be unique on their system as it also serves as the hostname of the URL like this: http://[your ID].appspot.com. For those that would like to use a different domain name, Google App Engine has mechanisms for doing so. In the administration panel of your application, you can add a domain and then choose hostnames from that domain that the application should respond to. However, it makes no provisions for serving the "naked domain".

What does this mean? For my example of hikethecanyon.org, I originally set the site up with an id of hikethecanyon-org which was initially served as http://hikethecanyon-org.appspot.com. After adding the domain hikethecanyon.org, I was able to add the host "www" so that it would respond to http://www.hikethecanyon.org. However, since GAE doesn't support naked domains, I was unable to set it up to respond to http://hikethecanyon.org. I was able find a workaround using GoDaddy's domain forwarding functionality. While walking fellow CFML developer Paul Kukiel through the process today, he mentioned that someone should blog this, so here it is with screenshots along the way (edit - it appears that he decided to blog it himself as well!)

For my example, I am going to use a domain I have had sitting around doing nothing for a few years (j4n.org) and walk through the process with some screenshots and explanations along the way.

First, you need to create your application in the GAE dashboard and deploy your application. Many people have covered this topic in our community including Paul Kukiel and Aaron Lynch, so I will skip to the next step and assume that you have a running application on Google App Engine. As you can see below, I have set up an app with an ID of j4n-org that is answering on http://j4n-org.appspot.com which is just running a Mach-II skeleton application.

The next thing that we want to do is add the j4n.org domain to this application. When you go into the GAE dashboard, you will see that option under the "Application Settings" section labeled "Domain Setup"

On this page you will see a note that tells you that the domain you add must be set up for Google Apps, a service that allows all sorts of functionality, including email services and more. NOTE: You do not have to use any of those services, you simply need to sign up!

By clicking the link that says Sign up for Google Apps, you will be taken to a page like this:

Walk through the process filling out your personal information and you will come to a screen that looks like this:

For our example, we are going to choose to create a new CNAME record in DNS to prove to Google that we own the domain. By choosing that option

At this point we need to go to the GoDaddy DNS manager and create a host name google46353a9a2d07a035 and point it to google.com. You can see what that looks like below:

Once that record is in place we can go back to the Google Apps page and click the button labeled I've completed the steps above. If all goes well, you will see a page directing you through additional setup. For our purposes in this example, we are done with Google Apps for the time being. Now we want to go back to the GAE dashboard and tell it that we want to use the j4n.org domain.

When you enter that domain you should see a message that looks like this:

This will bring us back into the Google Apps control panel for the j4n.org domain and we can add hostnames to our application like this:

When you click add you will see an page like the one below instructing you to add another CNAME to GoDaddy for the host "www".

In the screen below you will see that we have successfully added the "www" host and while we were in there I went ahead and deleted the temporary CNAME that we had to create earlier to validate the ownership of the domain.

At this point we can actually reach our application with the address http://www.j4n.org as you see below:

While this is pretty cool and all, we still can't access our application with http://j4n.org. For this, we will count on GoDaddy to do the rest. Go back into the GoDaddy domain manager look for this link:

On the next page, you will want to fill out the field like you see before. However, before you do, click the "learn more" link in the bottom left corner. On that page there is a very important note: For your domain to forward, your domain's A record must be 64.202.189.170. If you note my DNS information above, that is not what the default parked domain IP is. I won't bore you with yet another screen shot, but make sure you alter your domain's A record. Now when we ping j4n.org we get a response from 64.202.189.170.

Once we enter in www.j4n.org you can see that our plan is going to work by hitting the "Preview" link to the right and seeing a snapshot of our app!

You will notice that we accepted the default settings which actually does a 301 redirect from http://j4n.org to http://www.j4n.org. This means that we will never actually see http://j4n.org in the address bar after the page has loaded. If you click on the advanced settings you can select "masking" which allows the url to remain in the address bar as http://j4n.org. Each option has its own advantages. Select what is right for your application and choose OK.

That is all you need to do! Now, a word of warning... we have all gotten spoiled by the seemingly instant DNS changes in recent years. You will find that when you make this forwarding change, you may need to wait up to half an hour or so before you can see the finished product (your mileage may vary).

Talking through some current issues with ColdFusion Event Gateways

Mon, 09 Nov 2009 16:28:07 GMT

Normally on my blog I attempt to throw out some tip, trick, or nugget of some sort. This time? Not so! I am currently trying to find a solution to a problem at hand and am brainstorming the best way to handle a few things. I am really just talking this out for my own benefit, but I would love to hear thoughts from others that have perhaps solved similar issues.

On a project that I am currently engaged in I am leveraging ColdFusion Event Gateways which work as a subscriber to a SonicMQ JMS server. My gateway instance listens for messages on the ESB (Enterprise Service Bus) on a particular destination name (topic/queue). When it receives a message, it parses the XML that it received, and plays traffic cop pushing data into various services that need it. I have this working flawlessly in my small development environment. However, I have a couple of complexities ahead of me that I am having difficulty coming up with a good solution.

Running in the cloud - Our production environment will have any number of CF instances, not clustered, but rather running as isolated applications with a load balancer directing the requests using sticky sessions. Our system will be bringing new instances on/off line as traffic traffic dictates. I have yet to solve the issue of how to set up my JMS Event Gateway in this environment. I definitely don't want 20 different listeners out there all doing the same work. I have considered the idea of having some sort of a support database where a listener can insert a row with a specific JMS message ID and when any other server picks up a message with that ID it will see that it is already being acted upon and it can safely ignore it. There are a couple of negatives that I can see right off the bat. First is that every single subscribed instance will have to pull in the same message and test to see whether or not it should be acted upon. It just seems like a little bit of redundancy that shouldn't be there. Secondly, there is a chance that two servers could pick up the same request within milliseconds of each other and both could end up doing the work. Duplicate processing could not only be wasteful, but could also create some data integrity issues.
Different environments have different settings (dynamic config) - Right now in our development phase, we have a single config file with setting specific to our development JMS server (credentials, domain, URL, Initial Context Factory, etc). However, soon I will need to have this process support a number of different environments: multiple dev environments, multiple integration environments, multiple QA environments, and eventually production. Ideally it would be wonderful if I could find some way to load a specific config into the event gateway at server init time, but as of today I have _NO_ idea how to solve this one. First, there is no real intrinsic indicator at the server level that lets it know what environment is currently running (yet anyway...) and secondly, ColdFusion event gateway architecture isn't conducive in any way to dynamically loading a specific config.

So now I am counting on you CFML community. Help me brain storm on this! Do you have any thoughts/ideas that might help me here?

Solving java.lang.SecurityException: Seed must be between 20 and 64 bytes. Only 8 bytes supplied.

Fri, 08 May 2009 14:24:00 GMT

Recently I have began working with JMS and ColdFusion, in which we are building a system that subscribes to an enterprise JMS server and picks up messages relevant to its needs and acts on them. I had my proof of concept working with the open source Apache ActiveMQ server and was very pleased with the results. However, in our production environment, the powers that be decided to use the very non-free SonicMQ server.

As I tried to convert the event gateway over to the SonicMQ server, it failed on initialization with the following exception:

javax.naming.NamingException [Root exception is java.lang.SecurityException: Seed must be between 20 and 64 bytes. Only 8 bytes supplied.]  at com.sonicsw.jndi.mfcontext.MFConnectionManager.connect(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFConnectionManager.<init>(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFConnectionManager.getManager(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFContext.<init>(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFContextFactory.getInitialContext(Unknown Source)  at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)  at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)  at javax.naming.InitialContext.init(InitialContext.java:223)  at javax.naming.InitialContext.<init>(InitialContext.java:197)  at examples.JMS.JMSConsumer.start(Unknown Source)  at examples.JMS.JMSGateway.startGateway(Unknown Source)  at coldfusion.eventgateway.GenericGateway.start(GenericGateway.java:118)  at coldfusion.eventgateway.EventServiceImpl$GatewayStarter.run(EventServiceImpl.java:1428)

In my research on this problem, I found several people reporting similar errors, each on CF8, and each talking to 3rd party tools. Eventually I found the solution through an email discussion between one of the developers in my company and an Adobe developer. Apparently in CF8, they added FIPS security, which disables the Sun JCE (encryption libraries). To solve this error, you need to add the following line to your java.args in your jvm.config file in JRun.

-Dcoldfusion.disablejsafe=true

Now restart your server and try again!

`c->xlib.lock' failed error on Java applications

Tue, 29 Jan 2008 21:16:00 GMT

I am currently using the Alpha 3 release of Ubuntu 8.04 Hardy Heron. Considering the fact that it is an alpha release, I tend to not get worked up over little errors that might occur. However, I have found one that I just couldn't get around. I use Aqua Data Studio for my database client and since loading Hardy Heron, I have been unable to run it.

When I would start it from a terminal, I would get a dump that looked like this:

#0 /usr/lib/libxcb-xlib.so.0 [0x90d00767] #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0x90d008b1] #2 /usr/lib/libX11.so.6(_XReply+0xfd) [0x9039429d] #3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x9063e8ce] #4 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x9061b067] #5 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x9061b318] #6 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0x9061b61f] #7 [0xb4cff3aa] #8 [0xb4cf7f0d] #9 [0xb4cf7f0d] #10 [0xb4cf5249] #11 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x637338d] #12 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x64fd168] #13 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x6373220] #14 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so(JVM_DoPrivileged+0x363) [0x63c90d3] #15 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb7d1096d] #16 [0xb4cff3aa] #17 [0xb4cf7da7] #18 [0xb4cf5249] #19 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x637338d] java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion 'c->xlib.lock' failed. Aborted (core dumped)

Considering the fact that I used the Ubuntu sun-java6-jdk package from the Ubuntu repository, I decided that I would try the self-extracting bin that is available on http://java.sun.com. After swapping to that JVM, I still received the same dump and abort. After doing a bit of searching, I came across a patch in one of the bug reporting forums that effectively patches your JVM and prevents this error from occurring. I ran the patch and now everything works as it should. If you are receiving this error, create a shell script with the following content and run it. Assuming that it runs successfully, you should then be able to open the Java application that was failing.

#!/bin/sh # S. Correia # 2007 11 21 # A simple script to patch the java library in order # to solve the problem with "Assertion 'c->xlib.lock' failed." # see bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 LIB_TO_PATCH=libmawt.so for f in 'find /usr/lib/jvm -name "$LIB_TO_PATCH"' do echo "Patching library $f" sudo sed -i 's/XINERAMA/FAKEEXTN/g' "$f" done

Big thanks to "S. Correia" for getting me back on my feet!

Installing the JRE plugin in Firefox on Ubuntu

Fri, 18 Jan 2008 13:59:00 GMT

I have now been using Ubuntu for about 2 years, and oddly enough one thing that has always evaded me is how to properly set up the JRE plugin in Firefox. It *seems* like that ought to be an easy process, but it is one of those annoying little things that just hasn't worked for me, although it has never been important enough for me to chase down.

Yesterday I had to do a Webex presentation that required the JRE plugin, so I decided it was time to hack my way through it. One thing that I was thinking my be a factor is that I use Swiftfox instead of Firefox. I decided to take that out of the equation just to make sure, so I went ahead and removed it. When running Firefox and hitting about:plugins in the address bar, I could clearly see that the Java plugin was not in the list. I looked in ~/.mozilla/plugins, and saw a libjavaplugin.so in there, but it was obviously not doing its job.

So, after a lot of floundering, here are the basic steps I took that got me going...

First, I completely uninstalled Firefox:
$ sudo apt-get --purge remove firefox
I then reinstalled it:
$ sudo apt-get install firefox
Next, I had previously installed the sun-java2-bin package, so I wanted to wipe all evidence of that and reinstall it. I did the following:
$ sudo apt-get --purge remove sun-java6-bin sun-java6-jre sun-java6-plugin
To reinistall it I did:
$ sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-plugin
After doing this I opened Firefox and put about:plugins and still didn't see the Java stuff. At this point, I went into my ~/.mozilla/plugins directory. From earlier attempts I had some libjavaplugin.so and libjavaplugin-[something I don't remember].so. I decided to kill those off:
$ sudo rm libjavaplugin*
At this point looking around I found a file /etc/alternatives/firefox-javaplugin.so that seemed like a decent candidate, so I did a symlink like this:
$ ln -s /etc/alternatives/firefox-javaplugin.so ./libjavaplugin.so

At this point I restarted the browser, hit about:plugins and was thrilled to see an entirely new section for Java!

Now, take the steps above with a grain of salt. I certainly don't want to infer that this is by any means the right way to get it working, but it is the series of steps that finally got it working for me. Hopefully someone else might get something out of it as well.

Grand Canyon... It's on!

Mon, 11 Jul 2005 05:00:00 GMT

My father and I decided that this was the year that we would hike the North Rim to the South Rim of the Grand Canyon. I know this seems crazy, but it is actually a paperwork challenge to be able to hike the Grand Canyon. There is an application process in which you have to fax your request in the 1st day of the month 6 months before the intended date of your trip with a detailed itinerary, including where you will be sleeping and when. We sent faxed our paperwork in and held our breath on the 1st of April, 6 months before we hoped to go in September. After no word for a month we finally contacted them, only to find out that we had been rejected. Discouraged, but not beaten, we laid out the calendar to see if there was another time that would work. We decided that November would be acceptable, albeit a little colder. It should be in the 60s in the bottom of the canyon though where we will spend the majority of our time. Once again, we laid out our itinerary and faxed in on July 1. My dad received a letter today dated July 6, 2005 telling him that they were sorry, but they were unable to accept out application. He spent a good hour walking around the house cussing and feeling terribly disappointed. A bit later my mom noticed there was another letter from the Grand Canyon dated July 7, 2005.

Dear Mr. Shuck, we have accepted your request to hike the Grand Canyon on the dates of November 1, 2 and 3, 2005. Enlcosed are your passes, which you will need to affix to your backpack and carry with you in the canyon. There is no need to stop by the back country headquarters before departing on the trail.

So in 3.5 months, I will be taking this in....