1. Creating a LocalTunnel on dotCloud

    tl;dr

    If you want to install LocalTunnel on dotCloud, use this repo: https://github.com/cyounkins/tunnel-on-dotcloud

    If you participate in a lot of hackathons or just want to expose a certain port on a development box to theInterwebs™, there’s a really useful app that performs all the ssh magic from one of the Twilio engineers, http://progrium.com/localtunnel/ . Installing this rubygem magically assigns an unused proxied subdomain from localtunnel.com so you can show off your wares.

    While extremely useful in the one-off hackathon world, it’s a bit problematic if your app connects to a number of external services. Each time you’re assigned a different proxied subdomain from localtunnel, you’ll have to log into aforementioned services and change the callback urls or update a mystical dns redirect entry - both undesirable behaviors… especially having done this several umpteen times. :)

    Having stumbled upon this dotCloud blog entry, http://blog.dotcloud.com/open-your-local-webapp-to-the-web-with-dotclo and walked the tutorial, the repo referenced didn’t actually have a working nginx.conf file to do the proxying - looks to be commented out and missing a few other directives. In any case, thank you Interwebs, here’s a working repo: https://github.com/cyounkins/tunnel-on-dotcloud

    As a note, make sure you kill any open ssh sessions in dotCloud. If you’re careless like me with a lot of tmux sessions open, you’ll often get “Warning: remote port forwarding failed for listen port 8042” which generally translates to “Close your other open ssh sessions”

  2. Getting uWSGI + init.d playing nicely on Ubuntu 11.10

    A few weeks ago, I wanted to install uWSGI on my Ubuntu 11.10 box for http://allb.us.  After having gone through the standard aptitude/pip installs to get uwsgi installed, I noticed after running the init.d scripts, absolutely nothing would happen. 

    zip. nada. zilch.

    No log file + no uwsgi process == a lot of sad pandas.

    After having searched stackoverflow, it was quite apparent that I wasn’t the only unlucky soul to encounter this error.  To debug the uwsgi init.d script, I used the trusty set -xv trick atop to see the omgwtfbbqs.

    Here’s a few things I realized:

    1. The configuration file in /etc/uwsgi/apps-enabled must contain one of the recognized uwsgi configuration file extensions.  Initially, I symlinked my configuration file from the apps-available directory as allbus.  It didn’t like that at all.  I renamed the symlink to allbus.xml.
    2. The start-stop-daemon in the init.d script is being passed the location to the pid file via —pid-file instead of being told to create the pid file via the —make-pid-file option.  Thus, you need to make sure your uwsgi configuration file contains a directive to create the file at the same location the init.d script is looking for it.  *Note*: Take a look at the <pidfile> configuration.

    Here’s a gist I created of the xml uwsgi configuration I used for my Django application. Hopefully it helps save someone from the hour I spent in startup script hell. Enjoy! :D