synatic|blog by Benedikt Deicke

... and messed it up.

Last week I’ve been giving a talk (in german) about the project I did during my internship at the Human Computer Interaction Research Center at the university of applied sciences Fulda. This was the first talk I gave (not counting those I had to do in school and for university) and of course it ended up a little awkward. I didn’t intend to do a live demo at the end but somehow I changed my mind during the presentation. Of course nothing worked like expected … ;-) Lessons learned for next time. If you’d like to see the disaster yourself there is a video available.

I got my thesis’ topic last week and will start to write it within the next few days. I decided to write it using TeX as all my attempts to write large documents in OpenOffice.org caused very bad headaches. The TeX approach fits my needs much better and I can use GIT much more effectively to manage the changes to the documents. With TeX I could even apply patches to the document … how cool is that? :-) Just imagine sending the document to someone else for proofreading and getting back a patch that can be instantly applied without having to search every passage that had misspelled words in it. Maybe I’ll post some links that helped me getting into all the TeX stuff in the near future.

During the last week I built a new design for both the blog and the website. The website isn’t finished yet but today I decided to update the blog’s design. I hope you like it as much as I do.

Additionally I updated the underlaying Mephisto Blog and added Sven Fuchs’ Paged Article Lists Plugin.

Andreas Wolff recently released RSpactor, a (up to now) command line tool similar to autotest. Nevertheless it differs from autotest in two points. First it’s focused on RSpec and secondly it’s using Mac OS’ FSEvents to monitor file changes. According to this it only runs on Mac OS. To get it running on Linux you’ll have to change RSpactor’s Listener class to use Linux’ equivalent to FSEvents called inotify. Luckily there’s a gem called RInotify which introduces a simple class to access the inotify events within ruby. I rewrote the Listeners class yesterday to get it running on my Linux notebook:

   1  # inotify_listener.rb
   2  
   3  class Listener
   4  
   5    def initialize(&block)
   6      require 'rinotify'
   7      begin
   8        @spec_run_time = Time.now
   9        @watching      = {}
  10  
  11        notify = RInotify.new
  12        Dir.glob(File.join(Dir.pwd, '**')).each do |dir|
  13          watch_desc = notify.add_watch(dir, RInotify::MODIFY | RInotify::CREATE | RInotify::DELETE)
  14          @watching[watch_desc] = dir
  15        end
  16  
  17        while true do
  18          changed_files = []
  19          notify.each_event do |event|
  20            changed_files << build_path_from_event(event)
  21          end
  22          changed_files.uniq!
  23          unless changed_files.empty?
  24            @spec_run_time = Time.now
  25            yield changed_files
  26          end
  27          sleep(5)
  28        end
  29      rescue Interrupt
  30        @watching.each_key { |key| notify.rm_watch(key) }
  31      end
  32    end
  33  
  34    def build_path_from_event(event)
  35      File.join(@watching[event.watch_descriptor], event.name || '')
  36    end
  37  
  38  end

To get it running you simply have to install the RInotify gem and change one line in bin/rspactor:

   1  # from
   2  require File.join(File.dirname(__FILE__), '..', 'lib', 'listener')
   3  # to
   4  require File.join(File.dirname(__FILE__), '..', 'lib', 'inotify_listener')

That’s it! RSpactor should be running on Linux now and consuming much less CPU than autotest.

(You might also want to change the system()-call in lib/resulting.rb as it’s currently using growl to notify you about the test results.)

Typing SSH passwords again and again can be a real pain. For example: Lately I started to use Capistrano to deploy my rails applications. If I want to set up the maintenance-page on the server I’ll type cap deploy:web:disable which of course prompts me for the SSH password. Then I want to deploy my application with cap deploy and again will be prompted for the password. Finally I have to cap deploy:web:enable to remove the maintenance page which – as mindful readers might have guessed already – prompts for the password. This was just one reason for me to set up SSH authentication keys. At first I was a little worried that setting it up might be a bit complicated. Luckily I was disabused. If you want to switch to key based authentication too follow these simple steps:

Key generation

The first thing you need is – of course – a pair of keys: your private key and the associated public key. To generate both fire up our favorite shell (for me it’s bash) and type:

   1  ssh-keygen

This will generate both keys and ask you where to store it. Usually the default would be something like ~/.ssh/id_rsa. Simply accept the default by pressing return. Next you’ll have to enter a password for your key and confirm it. Afterwards you’ve to tell the server to accept your key on authentication. Do so by uploading the public key to the server.

   1  scp ~/.ssh/id_rsa.pub yourserver.com:~/.ssh/authenticated_keys2

If you want to add multiple keys, be sure to append it to the authenticated_keys2 file and don’t overwrite it.

First login

That’s all you have to do to switch to key based SSH authentication. Try to log in as usual by typing:

   1  ssh yourserver.com

This will prompt you for your key’s password and log you in to your server afterwards. “But wait! I’m still having to type my password every time I want to log in!” you shout, and you’re right – up to now. What you need to do is running ssh-agent, adding your key and typing your password. ssh-agent will then ask for the password and store it until you shut it down. You’ll have to do this everytime you open up a new shell or put the commands into your i.e. ~/.bash_profile. Quite comfortable but we can do better.

Keychain

There is a nice little tool called keychain that will smooth the process a little for you. It’s originally developed by the Gentoo people but it’s available on other linux distributions (as well as Mac OS X), too. Simply install it by typing your system’s equivalent to

   1  # Gentoo
   2  emerge keychain
   3  # Debian
   4  aptitude install keychain

and it’ll be available in no time. To set it up you need to put these two lines in our ~/.bash_profile:

   1  keychain ~/.ssh/id_rsa
   2  source ~/.keychain/$HOSTNAME-sh

That’s it. The first time you open up a shell keychain will start ssh-agent, prompt you for your keys password and remember the running ssh-agent for all new shells. On your next SSH authentication no more password typing is required. Wasn’t complicated at all, was it?

Update: Thanks to Michael for pointing out that the public key file is named id_rsa.pub instead of id_rsa. Fixed it.