Monthly Archives: December 2009

Contributing back

In my Redmine investigations that I’ve been writing about recently, I ran across an issue between a plugin and the latest version of Redmine. I really don’t know the first thing about about rails – I can read it, but I can’t always make sense of it, and I certainly don’t know the “expected” bits (some might call constraints, others I’ve heard call it “the magic”). So when I took the fix posted to the forums, slapped it up in a Github fork, and submitted a fork request – I had no idea if it would be wanted.

I’ve got to say that I’m incredibly gratified that it was accepted back into the main branch. All I really did was make it darned easy to pull in a patch someone else created, but even doing something simple like that I think made a difference.

I’m a bit more proud of the patches that I submitted to pyrrd (a real fix and some better doctests). Those were, honestly, harder – but really only because I found the Launchpad interface and Bzr to be harder to navigate and use than Git and Github. (I still assert that the best thing about Git is Github). Duncan (maintainer of pyrrd) prefers that system, so I created a branch there and submitted the patches. Didn’t quite do it 100% for him – I bundled two fixes into the same branch instead of a branch/fork per fix – but in the end he took them in and I think appreciated the help.

A little side light was helping out Ned with my writeup of using Hudson for python/django projects. Chris Heisel took it that one step farther and walked through using Hudson for Django projects as well. So I ended up contributing and seeding a bigger conversation with that too.

There have really been few projects that I’ve provided back to this year – it’s been a busy year at work, but much of it has been more people and process oriented rather than making code happen. Still, contributing back in whatever areas gives me a boost – and at the end of the year I like to look back and think that even in some small ways, I made something available for others.

What’s this coming year going to bring? Heh – who knows. I’ve got a few things rolling (at work and outside of work) that should prove to be really interesting. One is an open source monitoring project, although at the moment in the very, very early stages. The others I’ll have to leave off for talking about another time.

Redmine and a scrum board

After a few days of playing and working with Redmine and some plugins, here’s where I’ve ended up:

I tried the redmine scrumdashboard plugin (http://github.com/thus/redmine-scrumdashboard-plugin), but was never able to get it even functional. The whole thing stacktraced under 0.8.7 and I’m just too ill informed on rails to be able to effectively debug it. I did log it as an issue (http://github.com/thus/redmine-scrumdashboard-plugin/issues#issue/6) though.

While I was working with the backlog plugins, I found a few quirks. In one case, it wasn’t editing anything from the backlog tab in Redmine. That turned out to be an issue with a recent Redmine feature related to cross site forgery protection. There were a couple of posts in the plugin forum and some associated bugs at the bug tracker. On the forums,  Eric Doughty-Papassideris suggested a solution, so I forked up the github project and posted that fix for anyone to use. Even made a pull request back to the master project – don’t know if it’s 100% the right thing to do for the solution, but it does do the trick.

The backlog plugin, while working, did have a quirk that I never quite identified. I enabled the plugin and slapped in a bunch of issues, and one of them caused the plugin to render in a really odd way. I suspect it wasn’t defending well against stupid parameters, but I wasn’t ever able to figure out why the thing was rendering all whacked. I ended up deleting that example project, but on another it appeared to work correctly.

Of the two, the scrumdashboard plugin appears to be in a “quiet phase” – little commit activity and I suspect it’s running afoul of recent Redmine updates and features. Backlog seems to be keeping up better, so I expect that’s where we’ll focus our usage.

Update:

One thing that I found surprising – If you’re using Redmine with Mercurial, the redmine instance wants to have a mercurial repository *local* on that machine – you can’t point it at a remote mercurial repository and have it function correctly. It only wants to read off the local filesystem to do it’s work. That surprised me – as I was planning on having a separate machine for the repository originally to separate the concerns.

integrated project management for development

Ironically, the choices for an in-house integrated project management toolchain are, to my mind, significantly more limited than the straight up open-source market. I have been looking and watching several projects over the past months for something that I could use for my development team at work (i.e. behind a corporate firewall and not publicly available) to support a more open, transparent view of what was happening.

Trac, of course, is one I’ve used and really enjoy. Trac, however, doesn’t really support multiple projects in any integrated way – and we’ve got way more than one project. From the activity I’ve seen, it’s not about to any time soon. Variations on that theme include DrProject, and more recently Basie. They’re all interesting, but I didn’t see either DrProject or Basie as really ready for prime time and I wanted to be able to quickly grow beyond the basics. Two others that are obviously available are Redmine and Retrospectiva.

Ultimately, I’m heading down the road with Redmine for the following reasons:

  1. It’s a decent and clean user interface that has several years of polish now around it
  2. The system support plugins, and there’s several plugins that I really want to take advantage of
  3. Redmine and Trac appear to have the most active communities around them and driving them

The story cards and burn-down charts from Retrospectiva’s AgilePM addition were darned compelling. But ultimately it has a more limited set of folks focusing on that project, and I think I can achieve the same effects with plugins that are available from the Redmine community. Many of these are hosted on GitHub, and even more are in development or some middlin’ shape at the same site. And finally, I’d much rather deal with a partially implemented plugin than a partially implemented core system.

If I could host our development outside of the corporate firewall, I’d likely be looking at Bitbucket or Firefly for the work. I like Bitbucket partially because it’s all mercurial based, and I need to support some Microsoft based development. Git will work with enough effort, but I don’t want to go down the road of trying to explain all the detail needed there. I love the functionality in GitHub, and frankly think it’s a slightly better and more aggressively updated solution that BitBucket, but the git thing – while I’m happy enough with it – just sinks me otherwise because I know I’ll end up spending hours attempting to support it on a windows environment, and I just don’t want that hit. Firefly is ActiveState’s “let’s take and commercialize Trac by hosting it” – and they look like they’ve done a nice job of it. The agile methodology plugins and burn-down charts are pretty darn compelling.

It should be noted that I also took a pretty deep look at Launchpad. Even though it’s open sourced, it’s a damned complex thing to potentially integrate and build up for internal use, and its integration/collaboration features just haven’t been as compelling to me as the machinery that GitHub or Bitbucket provide. The “branch and request a pull” feature set that supports the massive branching and merging for features, bugfixes, etc. is just so much easier in Github or Bitbucket – and the wiki support to the other components is also far superior.

If you’re looking for something yourself, definitely keep an eye on the market and projects though. RIght now it’s just December 2009, and it’s clear there is a lot of effort, momentum, and a ton of good ideas that people are just begging to implement in this space. If I go to make this same decision in 6 months, there’s no guarantee that the landscape won’t have changed dramatically and a different solution would be better.

debugging Active Directory LDAP authentication in Redmine

What else does a geek do on Christmas eve? How about some ruby on rails debugging, especially when I don’t really know anything other than the basics of Ruby on Rails. :-)

So here’s what I’ve done and what I’ve learned, for the great search engine in the sky and the next time I find myself in this pickle.

I’ve installed Redmine on a CentOS box, which worked out really well. I cribbed the install notes from http://blog.itsmine.co.uk/2009/01/22/howto-install-subversion-and-redmine-on-centos5-rhel5/, which is a fantastic walk-through to the process.

So first is getting authentication working with Redmine. It includes a nice LDAPS:// based built-in mechanism, but there’s little detail around configuring it. The best is the wiki page RedmineLDAP on the Redmine wiki. If you’re doing LDAP authentication, you probably want LDAPS – otherwise you’re shipping passwords in clear over the wire. The default port of LDAPS on Active Directory is 636.

The other key thing you need to know is that even though you configure an LDAP connection in the redmine application (under http://YourRedmineHost/auth_sources/list), when you test it – it’ll test positive even if it isn’t binding into Active Directory and returning a result. Why? Now that another story – and one I don’t have clearly nailed.

To start, I enabled debugging in Redmine by editing /var/www/rails/redmine/config/environments/production.rb and inserting the line:

config.log_level = :debug

(the default, if you’re curious, is config.log_level = :info)

Restarted the service and now I’m getting a lot more detail. Turns out the LDAP authentication pieces really only trigger useful logging if the search mechanism that looks for the ID is successful. I found the ruby code doing the lifting at redmine/app/models/auth_source_ldap.rb – and starting adding in additional debugging methods. What I found was that the system wasn’t throwing any exceptions, but the result of a call to ldap_con.search() wasn’t returning any values.

What I haven’t been able to solve is why that search wasn’t returning any values.

Since I’m not super conversant on hacking on ruby (yet – I think I’m about to learn the hard way), I switched to a different tactic to see what was happening: tcpdump.

The command line to watch the LDAP protocol stream in plain-text as it flows is:

tcpdump -l -s 1024 -A -vv port 389

(you’ll need to run that as root, and turn of LDAPS so you can actually see the darned protocol). Wireshark would be a hell of a lot easier, but I’m doing this on a remote RHEL server and didn’t have a GUI to wrap into the darn thing. What I saw from that was a string embedded in the protocol noise:

LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece.

Why this wasn’t propagating an exception or error in Rails is not clear to me (which is why I think I’m about to learn more rails hacking, the hard way). I’ve tweaked things around to get different exceptions, but what it all amounts to is that I’m not yet getting a good/successful bind on LDAP from which I can do searches.

I’ve managed to get LDAP authentication working from python (and Django) within my environment, so I’m familiar with the proper base DN and some of the attributes that are available for use from our Active Directory – but so far, no love in the ruby world.

When you’re configuring the LDAP, the code is written so that Redmine has to have an account and password that will bind with LDAPS properly and be able to return search results. If you’re doing this against active directory, make sure you include the domain in the account you’re binding (i.e. YOURDOMAIN\youraccount). That made the difference in getting a successful bind to LDAP. Using the correct domain is what got me past the bind issue. The fact that it wasn’t successfully binding and not propogating an error seems like a bug – that’s been logged today as issue 4483

(by the way – the time when I want more screen real estate is when I have 5 terminal consoles and two different web browsers open debugging something like the redmine application)

More later… still debugging, but now I’m diving into using ruby script/console to interactively figure out this LDAP code in ruby.

UPDATE: So the final solution was all about having the right configuration entries in the fields to make it work. I ended up using ruby script/console to manually drive values until I had a success, and then the results were really clear as to what I needed to use.

For anyone else coming along and trying to same thing, here’s what worked for me (minus my password…) to learn what attributes were being passed back from LDAP:

ruby script/console
require 'net/ldap'
options = { :host => 'my.adhost.com', :port => 389, :encryption => nil, :method => :simple, :username => 'DOMAIN\jheck', :password => 'mypassword' }
ldap_conn = Net::LDAP.new options
ldap_conn.open { }
ldap_conn.auth('DOMAIN\jheck','mypassword')
ldap_conn.bind
filter = Net::LDAP::Filter.eq('sAMAccountName','jheck')
ldap_conn.search(:base => 'DC=MYDOMAIN1,DC=MYDOMAIN2', :filter => filter)

A related update/patch submitted to Redmine a few months ago is issue 4283 which solves a quandry I have about needing a separate account to authenticate through LDAP. I’ll be trying out that patch next monday.