You are currently browsing the daily archive for November 16, 2008.

Enabling security to my Hudson installation was a fairly straight-foward task although it did take a little trial and error to get it all straight. I chose to authenticate against our existing LDAP directory. One of the things that caught me off guard at first was the ‘User search base’ and ‘Group search base’. These settings are Relative Distinguished Names (ou=People), not the full Distinguished Name (ou=People,dc=crashingdaily,dc=com). Not a big deal; in fact I could have (should have, but I like to tinker) just left these fields empty and Hudson would have figured it out on its own.

Here is my almost final configuration (my final configuration makes use of StartTLS for a secure connection to the LDAP server – more on that in a later post).


The Manager DN is an account that has read-only search permissions. This is required because our LDAP directory is not searchable with anonymous binds.

The LDAP group configuration took me a bit more effort and debugging. I have an HudsonAdmin LDAP group in my directory. The DN for it is cn=HudsonAdmin,ou=Groups,dc=crashingdaily,dc=com

To get this work I had to upgrade to the 1.261 release which adds uniqueMember, memberUid to the existing member in the search filter (my HudsonAdmin group has ‘uniqueMember’ entries). Incidentally, one of the things I love about Hudson is when I run into a bug or missing feature I can usually count on it be addressed in a newer release – and upgrading to a new release is quick and painless.

A not-so-obvious aspect to the configuration is that, when adding an LDAP group, Hudson wants the group name in all uppercase and with ‘ROLE_‘ prefixed to it. So, ‘cn=HudsonAdmin,...‘ becomes ‘ROLE_HUDSONADMIN‘. I did find this requirement documented after a little Google searching, it’s just not spelled out in the admin form’s help.

Tip: When screwing around with your Hudson Authorization, make frequent backups of the working $HUDSON_HOME/config.xml so if you make a mistake and lock yourself out you can restore a working configuration from backup, reload Hudson and be back in business. The Hudson documentation does include a note about recovering from a lockout by setting useSecurity to false in the config.xml file but I find that doing that causes a loss of all your security settings and you’ll have to re-enter all the LDAP values and Authorization settings.


Hudson rocks. I mean, holy shit, this is one nice software package. I’m just starting my first foray into continuous integration (CI) and haven’t compared Hudson to other CI software but so far Hudson is so feature rich and easy to use that I don’t see a need to evaluate others.

Hudson has a clean user administration interface but happily obliges me if I want to manually tinker with the XML-format configuration files – something I had to do several times after repeatedly locking myself out trying to get the security settings correct. Editing the configuration files also comes in handy for making bulk changes across a dozen of job settings – for example, adding Jabber notification or renaming projects.

The formal documentation is a little on the light side but the GUI interface and layout of the configuration files is intuitive enough that I usually didn’t need to RTFM. The active support forum helped fill in many knowledge gaps and a little experimentation on my own has so far solved the rest.

Overall, I’m really amazed and thrilled how seamlessly it works with our existing build and testing system which consists of hobbled together shell scripts wrapping other Perl scripts and Ant tasks. I’ll be adding Selenium tests for our web components in the future.

I’ve hit a few, small stumbling blocks – nothing insurmountable – incorporating Hudson into my project and I’ll be posting about some of those. Still, I’m very excited about the prospects of having Hudson help me solve some long standing frustrations on this project, even those that aren’t really a component of continuous integration.


November 2008
« Oct   Jan »