Felix Hanley's articles et al

timetrackr - simple time tracking

2012-04-03T14:00:00Z

A simple CLI time tracking utility.

Install

$ gem install timetrackr

Example

(with a Bash alias of ‘tt’)

start a task:

$ tt start something

…view durations:

$ tt
something *     0h  0m  4s

…have two running tasks:

$ tt start another-thing
$ tt log
2011-05-18   something *     22:11            0h  0m 30s
             another-thing * 22:11            0h  0m 15s

…start with a note:

$ tt start one-more with a note
$ tt log
2011-05-18   something *     22:11            0h  0m 45s
             another-thing * 22:11            0h  0m 30s
             one-more *      22:13            0h  0m 15s  with a note

…restrict some:

$ tt log something
2011-05-18   something *     22:11            0h  1m 00s

…exclude some:

$ tt log something -n another-thing
2011-05-18   something *     22:11            0h  1m 15s
             one-more *      22:13            0h  0m 45s  with a note

…stop one (or more):

$ tt stop something
$ tt
something       0h  1m 20s
another-thing * 0h  1m 30s
one-more *      0h  1m 15s

…and delete one:

$ tt clear something
another-thing * 0h  1m 45s
one-more *      0h  1m 30s

Source

From my Git repository or on GitHub.

Role based access (RBAC) for Rails

2011-03-10T13:00:00Z

The basics of a role based access control system using Ruby on Rails, CanCan and Devise.

Goals

This are often the requirements/desires I have with an authentication/authorisation system:

customisable
a variety of storage choices (DB, YAML etc.)
the ability to change access from within the application (think nice permission assignments

RBAC authorisation is reasonably common in larger projects and is well described in the Wikipedia article

We would like users to be assigned roles and roles enabling a number of permissions. A user may have a number of different roles meaning the permissions available for each of their roles is combined.

So we will be able to access a user’s permissions (using DataMapper) like so:

u = User.get(1)
u.roles.permissions.each {|perm|
  #...
}

Models

First of all, get devise and cancan installed and basically configured within your application. I won’t cover this here.

These are the models that we will eventually have and their corresponding relationships. These examples use DataMapper.

class User
  include DataMapper::Resource

  # devise setup
  devise :database_authenticatable, :registerable,
    :recoverable, :rememberable, :trackable, :validatable


  property :id, Serial
  property :email, String, :required => true, :unique => true, :format => :email_address
  property :active, Boolean
  # ...

  has n, :roles, :through => Resource
  # ...

  # for assignment of roles
  def role_ids=(ids)
    self.roles.clear
    ids.delete_if{|i| i.empty?}.each do |id|
      self.roles << Role.get(id)
    end
  end

  def has_role?(role_sym)
    roles.any? { |r| r.name.underscore.to_sym == role_sym }
  end

  def role?(role)
    return !!self.roles.first(:name => role.to_s.camelize)
  end
end

class Role
  include DataMapper::Resource

  property :id, Serial
  property :name, String
  property :description, Text
  # ...

  has n, :users, :through => Resource
  has n, :permissions, :through => Resource
end

We are using the anonymous join model Resource to link users and roles. We could quite easily make an actual model to hold extra information (for a history, perhaps).

There are a few extra methods in the User model to help with the assignment of roles. This is DataMapper’s way of overriding accessors and enables specific implementations.

CanCan setup

The permissions for many applications are closely tied to the application’s code. The checks are hard coded into the application. If this is the case there is no need to have the permissions taken from the database. The roles, yes, but the defining permissions will only ever change with the application code.

We can then put the permissions in a static file (YAML) in this case and have it read by the app when needed. CanCan’s ‘ability’ model is a good place to do this:

class Ability
  include CanCan::Ability

  @@permissions = nil

  def initialize(user)
    self.clear_aliased_actions

    alias_action :index, :show, :to => :read
    alias_action :new,          :to => :create
    alias_action :edit,         :to => :update
    alias_action :destroy,      :to => :delete

    user ||= User.new

    # super user can do everything
    if user.role? :super
      can :manage, :all
    else
      # edit update self
      can :read, User do |resource|
        resource == user
      end
      can :update, User do |resource|
        resource == user
      end
      # enables signup
      can :create, User

      user.roles.each do |role|
        if role.permissions
          role.permissions.each do |perm_name|
            unless Ability.permissions[perm_name].nil?
              can(Ability.permissions[perm_name]['action'].to_sym, Ability.permissions[perm_name]['subject_class'].constantize) do |subject|
                Ability.permissions[perm_name]['subject_id'].nil? ||
                  Ability.permissions[perm_name]['subject_id'] == subject.id
              end
            end
          end
        end
      end
    end
  end

  def self.permissions
    @@permissions ||= Ability.load_permissions
  end

  def self.load_permissions(file='permissions.yml')
    YAML.load_file("#{::Rails.root.to_s}/config/#{file}")
  end
end

This logic is up to you and your project but the above basic implementation does the following:

adds another action alias, modify
enables the super user to do everything
enables the authenticated user to modify (edit, destroy) themselves
creates a bunch of abilites taken from the YAML permissions file

You can then start using the action, subject and optional object paramaters with CanCan to check for permissions for which the CanCan documentation has many examples.

Initial Setup

We can then define a few roles to seed the database with for use later. Put this in db/seed.rb:

super_user = User.create(:email => 'super@example.com',
                         :firstname => 'Super',
                         :surname => 'User',
                         :password => 'password',
                         :password_confirmation => 'password',
                         :active => true,
                         :created_at => Time.now)
admin_user = User.create(:email => 'admin@example.com',
                         :firstname => 'Admin',
                         :surname => 'User',
                         :password => 'password',
                         :password_confirmation => 'password',
                         :active => true,
                         :created_at => Time.now)
user = User.create(:email => 'user@example.com',
                   :firstname => 'User',
                   :surname => 'User',
                   :password => 'password',
                   :password_confirmation => 'password',
                   :active => true,
                   :created_at => Time.now)

# create roles
super_role = Role.create(:name => 'super', :description => 'Super user')
admin_role = Role.create(:name => 'admin', :description => 'Admin user')
user_role  = Role.create(:name => 'user', :description => 'Normal user')

# get our permissions
permissions = YAML.load_file("#{::Rails.root.to_s}/config/permissions.yml")

# assign permissions
admin_role.permissions = permissions.collect{|n,p| n}
admin_role.save

# assign roles
super_user.roles << super_role
super_user.save
admin_user.roles << admin_role
admin_user.save
user.roles << user_role
user.save

The actual permissions seeded will be entirely up to you and your application but this sets up a few basics for one model.

Further

This also enables you to have a nice report of the roles and their permissions much like the following:

This can be created in the view something like this:

= form_tag({:controller => 'roles', :action => 'report'}, :method => 'post') do
  %table
    %tr
      %th= Role.human_attribute_name('permissions')
      - @roles.sort.each do |role|
        %th
          = role.name
          = hidden_field_tag "permissions[#{role.name}][]", ""
    - Ability.permissions.each do |pname, pdetails|
      %tr
        %td= pdetails['description']
        - @roles.sort.each do |role|
          %td
            = check_box_tag "permissions[#{role.name}][]", pname, role.permissions.include?(pname)
  %fieldset.actions
    = submit_tag 'Save'

Dynamic Permissions

It is quite possible that you may want to have dynamic permissions. For example, to assign permissions to specific object instances or perhaps in an application that accesses another service which changes.

If this is the case, you will need to have the permissions based in a dynamic datastore, most likely the same database. You would need to define a new model to store them and update the associations and CanCan logic to do authorisation checks.

tinydnsdyn - Dynamic DNS

2010-12-31T13:00:00Z

This is a basic dynamic client and server for the djbdns DNS server ‘tinydns’ by Dan Bernstein.

Requirements

Administrative access to a server running tinydns and hence daemontools or similar
Administrative access to a *nix box on you local network
Python (version 2!) installed on both client and server
An open port on the server’s firewall

Installation

To install the server code:

Copy script and all files onto your server (i.e. /etc/tinydnsdyn/)
The supplied ‘run’ script is tailored for debian/ubuntu and may need to be changed.
You can added dynamic DNS entries to your main data file or alternatively use a seperate file for dynamic entries. An existing entry in the tinydns data file should already exist. This script will NOT add one. Only those hosts listed (with prefixes ‘+’ and ‘=’) are able to update their entries.

For example:
```
+groucho.example.com:192.168.0.2:3360
+groucho.example.com:192.168.0.2
=groucho.example.com:192.168.0.2:60
+*.groucho.example.com:192.168.0.2:60
+*.groucho.example.com:192.168.0.2
```
will all get updated if the host groucho.example.com does a request.
Create a password file. This is of the format created by Apache’s htpasswd and consists of one user per line in the following format:
```
username:crypted hash:optional,list,of,domains
```
The script will run ‘make’ in the data directory. This enables you to concatenate your data files and whatever else before they are compiled. For instance, you may need to combine all your primary and seconary zones and then add the dynamic hosts before compiling.

An example Makefile is included with some ideas.
Start the service by symlinking this directory into your svscan directory (i.e. “ln $(pwd) /etc/service/” ).

The service operates over HTTP and should be reasonably close to the service operated by DynDns.com having the following request format:

http://username:password@yourdnsserver.com/?hostname=yourhostname&myip=optionaladdress

The only required parameter is the hostname you wish to change. This can be a comma separated list of hostnames to update. The IP address will be determined automatically if the ‘myip’ parameter is missing.

The response codes are taken from here (not all of them):

http://www.dyndns.com/developers/specs/return.html

The Python code is basic and inefficient but it should work. I take no responsibility for anything that may happen to any of your machines. That said, please let me know if there are any issues.

Source

It can be downloaded from my Git repository or from GitHub.

Webfonts with Nginx

2010-08-21T14:00:00Z

I just made some changes on my site to use webfonts for the main menu and any Lahu language sections of the site. I have chosen to serve the font files directly from my server as most of the other webfont servers don’t provide a good Unicode 5 version of any font required for Lahu display.

This does mean that I needed to update my Nginx mime types to serve the font files with the correct mime type. I added the following to my mime.types file in the Nginx config directory:

application/x-font-ttf                ttf;
font/opentype                         otf;
application/vnd.ms-fontobject         eot;

and reloaded Nginx. Now they are served correctly instead of ‘application/octet-stream’.

Logwatch, socklog and svlogd

2010-08-20T14:00:00Z

Runit is a great package that provides process supervision and can be used as a replacement for ‘sysvinit’. The author of the package has also made a syslogd replacement called socklog which works well with runit.

Logwatch is a collection of scripts that can be used to notify you of changes to your logs. Out of the box on a Debian machine, though, logwatch will not be able to read all the logs spat out by socklog. The default setup produces logs that have the log facility and level appended to the log entry and the hostname removed:

authpriv.info: Aug 21 20:45:44 sshd: pam_unix(sshd...

I recently had to modify Logwatch for some other reasons and thought I would post my existing scripts here for others to see also. These should be placed in the /etc/logwatch directory so they are not overwritten on package upgrades.

conf/logfiles/messages.conf

LogFile = 
Archive = 
LogFile = socklog/*/current
Archive = socklog/*/@*

*RemoveFacility
*ExpandRepeats
*RemoveService = talkd,telnetd,inetd,nfsd,/sbin/mingetty
*ApplyStdDate

conf/logfiles/syslog.conf

Logfile = 
Archive = 
LogFile = socklog/*/current
Archive = socklog/*/@*

*RemoveFacility
*ExpandRepeats
*RemoveService = talkd,telnetd,inetd,nfsd,/sbin/mingetty
*ApplyStdDate

conf/logfiles/secure.conf

LogFile = 
Archive = 
LogFile = socklog/auth/current
Archive = socklog/auth/@*

*RemoveFacility
*ExpandRepeats
*ApplyStdDate

conf/logfiles/maillog.conf

LogFile =
LogFile = socklog/mail/current
Archive =
Archive = socklog/mail/@*

*RemoveFacility

conf/logfiles/kernel.conf

LogFile = socklog/kern/current
Archive = socklog/kern/@*
*RemoveFacility
*ExpandRepeats
*ApplyStdDate

There may be others needed for your own system. All these configurations reference the script RemoveFacility does the bit of removing the facility and level from each log entry.

scripts/shared/removefacility

# removes the facility and level from logfiles generated by socklog
if ( $ENV{'LOGWATCH_DEBUG'} > 4 ) {
   print STDERR "DEBUG: Inside RemoveFacility\n";
}

while (defined($ThisLine = <STDIN>)) {
   $ThisLine =~ s/^[a-z]+.[a-z]+: //i;
   print $ThisLine;
}

and also the onlyhost script which is used to restrict entries by host but since the hostname is not even there we just return them all:

scripts/shared/onlyhost

use strict;

my $line;
while (defined($line = <STDIN>)) {
    print $line;
}