Open Sourcery

Nothing like some possitive feedback to keep you looking after your own projects, and the feedback on daemon-kit has been great so far. My TODO list is growing every day with more features that I need, and others need as well. I mostly add features to daemon-kit as I need them right away, for this reason the docs is still lacking and the support site hasn’t been setup yet.

However, I’ve setup the following channels for daemon-kit communication (and updated the README):

• daemon-kit@googlegroups.com
• #daemon-kit on Freenode

I’ll be doing my best to stay on top of these channels and garner more feedback from the community at large.

Today’s sprint was one of the very first things I planned, support for capistrano.

When generating a daemon, use the ‘-d’ flag to specify which deployer to use. Currently only capistrano is supported, but I’ve left the door open for anyone willing to add support for Vlad the Deployer.

$ daemon_kit /path/to/project -d capistrano

This will leave you with a Capfile, which you don’t need to edit, as well as config/deploy.rb and config/deploy/*.rb. The environment specific files in config/deploy is used by the capistrano-ext gem to support multistage deployments for testing your daemons. Shared configuration details go into config/deploy.rb. You need the following gems installed to leverage the deployment options:

• capistrano
• capistrano-ext

Capistrano is historically built around Rails applications, but I lifted the capistrano ‘deploy’ recipe from capistrano-2.5.5 and customized it to fit in with the requirements of daemons. Some steps have been removed, and some added. Here is the tasks available:

$ cap -T
cap deploy                     # Deploys your project.
cap deploy:check               # Test deployment dependencies.
cap deploy:cleanup             # Clean up old releases.
cap deploy:cold                # Deploys and starts a `cold' application.
cap deploy:copy_configs        # Copies any shared configuration files from :...
cap deploy:get_current_version # Get the current revision of the deployed code
cap deploy:pending             # Displays the commits since your last deploy.
cap deploy:pending:diff        # Displays the `diff' since your last deploy.
cap deploy:restart             # Restarts your application.
cap deploy:rollback            # Rolls back to a previous version and restarts.
cap deploy:rollback:code       # Rolls back to the previously deployed version.
cap deploy:setup               # Prepares one or more servers for deployment.
cap deploy:start               # Start the daemon processes.
cap deploy:stop                # Stop the daemon processes.
cap deploy:symlink             # Updates the symlink to the most recently dep...
cap deploy:update              # Copies your project and updates the symlink.
cap deploy:update_code         # Copies your project to the remote servers.
cap deploy:upload              # Copy files to the currently deployed version.
cap invoke                     # Invoke a single command on the remote servers.
cap multistage:prepare         # Stub out the staging config files.
cap production                 # Set the target stage to `production'.
cap shell                      # Begin an interactive Capistrano session.
cap staging                    # Set the target stage to `staging'.

Very close to the original recipes. I’ve still got to clean this up even further, and add some documentation on how to leverage capistrano for daemons, but for the time being this works very well. The recipe can be found in lib/daemon_kit/deployment/capistrano.rb if you have the urge to review it.

Heading towards 0.2, here are the main highlights:

• god & monit config file generation
• Improved rdoc’s and supplementary documentation files
• Finishing off some issues with error handlers
• Better logging

Daemon-kit has been getting a lot of TLC from me lately, and it’s not going to stop anytime soon. As I wander deeper and deeper into AMQP territory, I need to extend daemon-kit to cope with all kinds of new scenarios. One of those being unhandled exceptions.

The second thing I put on the TODO list was Rails-style exception handling. With version 0.1.6 there has been some progress made in that regard. Daemon-kit now sports a configurable safety net for dangerous code. By wrapping blocks of code in a “safety net”, unhandled exceptions are caught and logged, and optionally sent via email or to Hoptoad for review.

Hoptoad? In a Ruby daemon? Sure, inspiration came via these tweets.

And it only makes sense to do it. Now for some code:

safely do
  # do something silly
  silly.action!
end

safely is mixed into Object and can be used freely. It is important to note that you have to handle your daemon-specific applications on your own and rely on safely as a fall over mechanism.

To configure the safety net, you can edit your config/environment.rb file and add the following lines to the configure block:

  # for email notifications
  config.safety_net.handler = :mail
  config.safety_net.mail.recipients = ['you@gmail.com']
 
  # for hoptoad
  config.safety_net.handler = :hoptoad
  config.safety_net.hoptoad.api_key = 'your-hoptoad-key'

The documentation is very rough at the moment, but the files you want to explore are lib/daemon_kit/safety.rb and the error handlers in lib/daemon_kit/error_handlers.

NOTE: If you are upgrading from an earlier daemon-kit, please upgrade your daemons as well by running the following rake task in the root of your daemon projects:

$ rake daemon_kit:upgrade

In the coming days/weeks you can look forward to the following enhancements as well:

• Improved logging
• Improved backtrace cleanups
• Improved rdoc’s
• rack application generator (with rack-mount)

I’m patching things up as I go along, adding features as I need them (and stuff I recall from my first daemons). There is still a lot of things that need attention, but they’ll be addressed and hopefully daemon-kit grows to becoming the premier framework for writing daemon processes in our beloved Ruby.

Just thought I’d share this one to boost the available online information. Using String#crypt and man crypt you’ll come up with something similar to the gist below (extract from a project I’m busy working on).

module Linux
  class User
    class << self
      # Generate an MD5 salt string
      def salt
        seeds = ('a'..'z').to_a
        seeds.concat( ('A'..'Z').to_a )
        seeds.concat( (0..9).to_a )
        seeds.concat ['/', '.']
        seeds.compact!
 
        salt_string = '$1$'
        8.times { salt_string << seeds[ rand(seeds.size) ].to_s }
 
        salt_string
      end
 
      # Crypt a password suitable for use in shadow files
      def crypt( string )
        string.crypt( self.salt )
      end
    end
  end
end

And the spec

require File.dirname(__FILE__) + '/../spec_helper'
 
describe Linux::User do
  describe "generating shadow passwords" do
    it "should generate a salt for crypt" do
      salt = Linux::User.salt
      salt.length.should be(11)
      salt.should match(/^\$1\$[a-zA-Z0-9\.\/]{8}$/)
    end
 
    it "should generate a shadow password" do
      pass = Linux::User.crypt( 'secret' )
      pass.should match(/^\$1\$[a-zA-Z0-9\.\/]{8}\$[a-zA-Z0-9\.\/]{22}$/)
      pass.length.should be(34)
    end
  end
end

HTH