setwave

I have a 256slice running on Slicehost. Over the weekend I tried to install the neat little gem, cheat. Why is it the simplest things never go as smoothly as planned? I issued the command ‘sudo gem install cheat’ and sat there waiting while it tried to bulk update my local gem repository. After about five minutes, I noticed it wasn’t updating like it normally does. In that time, my swap usage went through the roof, err a, I mean stack.

It turns out there’s a nasty memory leak in gem release 1.0.1 (I was a few point releases behind). No problem, I thought. I’ll simply update to gem version 1.2 which addresses a lot of the problems I was experiencing. Before doing this, I received an email from Slicehost support telling me I went way over my alloted swap usage. I replied back telling them my situation and promptly received an email from their support crew. And yet another reason why I love my Slice!

I thought I could simply perform a ‘sudo gem update –system’ and have it automatically bump my gem version to latest rev. Nope. It still tries to bulk update, first. So, now what? Another problem I’ve been experiencing with my Ubuntu slices: My local shell times out after a few minutes of inactivity. This is the kind of sheer madness ones grows accustomed to if you aren’t trying to perform long running tasks. Slicehost support was kind enough to point me to a fix for this problem. A few ssh_config tweaks later and everything seems to be all good.

Now, onto to the more pressing matter. It turns out every Gem release also has an incremental update version you can download and install directly without using gem to manage it for you. Outlined here, all you need to do is this:

1. Download the update version to your machine somewhere. (command: ‘wget http://rubyforge.org/frs/download.php/38844/rubygems-update-1.2.0.gem’)
2. From that same directory: ‘sudo gem install rubygems-update-1.2.0.gem’
3. Issue command: ‘sudo update_rubygems’
4. Clean up after yourself by removing the rubygems-update-1.2.0.gem package you just downloaded
5. Better living through Gems is just like it used to be!

Party on Interwebs…

Alright, I just successfully configured my domain to use google apps for email (phew.. the means one less thing I need to worry about!).

In a nutshell, the process went like this:

• I created a google apps account for my domain name. Really simple and free!
• Google needed to verify I owned the name. To do this, you can either copy and paste some code into your site or create a custom CNAME record with a code they give you. I elected to use the CNAME record. They say it takes them around 48hrs. to verify (it only took about 10 minutes, though). Once you’ve created the record be sure and click the button which tells them it’s ready to begin authenticating your site.
• After that, it was time to move on to my DNS settings. I ended up with these MX records:
  • name | data | auxillary
  • squabl.com. | ASPMX.L.GOOGLE.COM. | 1
  • squabl.com. | ALT1.ASPMX.L.GOOGLE.COM. | 5
  • squabl.com. | ALT2.ASPMX.L.GOOGLE.COM. | 5
  • squabl.com. | ASPMX2.GOOGLEMAIL.COM. | 10
  • squabl.com. | ASPMX3.GOOGLEMAIL.COM. | 10
  • squabl.com. | ASPMX4.GOOGLEMAIL.COM. | 10
  • squabl.com. | ASPMX5.GOOGLEMAIL.COM. | 10
• Slicehost has a nice tutorial here for help on this.
• Finally, I ended up with one more CNAME record:
  • name | data | auxillary
  • mail | gns.google.com. | 0

• Don’t forget to add “.” at the end of all the data entries or you’ll end up with your domain name concatenated to the end of each MX/CNAME record.

• While those changes were propagating I went back to google apps and enabled webmail. (There was another section where I had to confirm I entered the DNS settings so I could use my own subdomain to access GMail.)

• Lastly, I created a few users.
• Yayyyyyyyy!!!!

All this was fine and dandy. I was able to send and receive email directly from GMail using my domain without a problem. Now, I was completely amazed at this point that everything just worked. Now, the last piece to test was sending email directly from a rails app.

What I quickly discovered is my rails app didn’t send email directly out of the box using google apps. In other words, you’ll need to provide a work-around. The root of the problem is outlined here and has to do with the fact Google requires a special handshake using TLS – which isn’t supported by ActionMailer. The patch is to add a file to your lib directory and require it inside your environment files. Unfortunately, the site where the following code originated from is down:

Create the file lib/smtp_tls.rb…

require "openssl"
require "net/smtp"
Net::SMTP.class_eval do
  private
  def do_start(helodomain, user, secret, authtype)
    raise IOError, 'SMTP session already started' if @started
    check_auth_args user, secret, authtype if user or secret

    sock = timeout(@open_timeout) { TCPSocket.open(@address, @port) }
    @socket = Net::InternetMessageIO.new(sock)
    @socket.read_timeout = 60 #@read_timeout

    check_response(critical { recv_response() })
    do_helo(helodomain)

    raise 'openssl library not installed' unless defined?(OpenSSL)
    starttls
    ssl = OpenSSL::SSL::SSLSocket.new(sock)
    ssl.sync_close = true
    ssl.connect
    @socket = Net::InternetMessageIO.new(ssl)
    @socket.read_timeout = 60 #@read_timeout
    do_helo(helodomain)

    authenticate user, secret, authtype if user
    @started = true
  ensure
    unless @started
      # authentication failed, cancel connection.
      @socket.close if not @started and @socket and not @socket.closed?
      @socket = nil
    end
  end

  def do_helo(helodomain)
     begin
      if @esmtp
        ehlo helodomain
      else
        helo helodomain
      end
    rescue Net::ProtocolError
      if @esmtp
        @esmtp = false
        @error_occured = false
        retry
      end
      raise
    end
  end

  def starttls
    getok('STARTTLS')
  end

  def quit
    begin
      getok('QUIT')
    rescue EOFError
    rescue OpenSSL::SSL::SSLError
    end
  end
end

Add these settings to your environment file. (I needed to make a slight change from the original patch I discovered. The original patch had ActionMailer::Base.server_settings. Not sure if this is specific only to config/environments/production.rb because I added my change directly to config/environment.rb and ended up with this…

# config/environments/production.rb
require 'smtp_tls'
ActionMailer::Base.smtp_settings = {
  :address        => 'smtp.gmail.com',
  :port           => 587,
  :domain         => 'example.com',
  :authentication => :plain,
  :user_name      => 'mailer@example.com',
  :password       => ''
}

I just completed my migration of squabl.com. Say bye-bye Dreamhost, hello Slicehost! I must say, it’s love at first site. I’m going to post some notes about the setup and migration. All-in-all, I created the account, setup my VPS, and ported everything to the new hosting company while watching TV a few nights this week.

It looks like the site is performing way better then it did in it’s former home. (But this could be, no one knows it exists, really.) Dreamhost seemed neat at first, but the love affair didn’t last. I feel like I just wasted a few weeks trying to work around its limitations, horrible performance issues (fcgi in a shared environment with rails is painful), and recent billing issues. I mean, come on, I want to spend my time coding, wouldn’t you? Either way, I did learn some new things in the process.